Tag Archives: netapp

InTechWeTrust episode 32 – Netapp, containers, AWS and more

I recently attended the tech.unplugged event in London (my thoughts on it are here) and the London VMUG the following day, and was in the right place at the right time to take part in the InTechWeTrust podcast, episode 32. For those not familiar with this podcast it’s run by a prominent team of bloggers who have a background in enterprise infrastructure and has been going since last September. You can listen to the podcast directly via the player below or your usual choice of subscription (iTunes etc) – just head on over to the InTechWeTrust website for all the links.

Make sure you listen to the last 15 mins with EMEA CTO Joe Baguley – very interesting.

InTechWeTrust Episode 32 – Containers, Project Photon/Lightwave, AWS, Netapp, CoHo Data + more!

I’d like to use this blogpost to follow up on some of the topics discussed and my contributions.

...on ‘containers’. Sometimes I find myself speaking on a topic of which I’m by no means an expert – I try to avoid it as I’m all about facts, impartiality (as far as that’s possible) and I’m a believer that your reputation is sacrosanct (not just in the bloggersphere) but you can’t learn without getting out of your comfort zone. I’m not a developer. I have limited knowledge and minimal hands-on experience of containers. I have an understanding on where they fit into an overall architecture, who’s getting value from them, and at least an inkling of their potential but I’m clearly no expert. My comments about Docker building a platform (with an implied degree of vendor lock-in) vs Rocket’s ‘more open’ ambitions largely came from reading this blogpost from Rocket, this great Reddit thread discussing what it means, plus a good summary from GigaOm. Clearly this still needs to play out – the stakes are high and it’s going to be an interesting ride!
If anyone can point me to other resources with more information I’d be very grateful!

…on Photon/Lightwave/Photon. This was discussed with Joe Baguley after I’d left the podcast but the interesting soundbites for me were ‘a new direction for VMware’, the fact that containers are seen to be the boundary between VMware and Pivotal (hence why Photon/Lightwave are VMware yet Lattice is Pivotal), and the idea that containers may become embedded in vSphere itself. Interesting times!

…on Netapp. There’s been a recurring discussion about Netapp on the last few episodes and a good Linked-In discussion. I was a Netapp user for over five years (and I’ve written quite a few Netapp blogposts) and while I’ve not kept an eye on their latest releases I’ve always felt they weren’t vocal enough in the social media space, especially since Vaughn Stewart jumped ship to Pure Storage. This has improved with Nick Howell’s useful DatacentreDude blog and podcast but I still don’t see enough innovation. Flash, tiering, and scale out have all been addressed but never in a convincing way – the gravity of the core ONTAP OS seems all consuming. This would seem to be borne out in their upcoming layoffsAgain, happy to be educated otherwise!

…AWS finances. They’re now available – plenty of articles to digest. As predicted it made the mainstream BBC news, Simon Wardly waded in, and there’s a good Business Insider article with a great quote;

Amazon? The online bookstore that turned into a kind of Best Buy/Wal-Mart online? A giant of enterprise computing? No way.

 

Netapp ONTAP 8.2 and SnapManager compatibility

Summary: Running SnapDrive or SnapManager on Windows 2003? You might have some decisions to make….

Netapp recently announced that ONTAP 8.2 will bring with it a new licencing model which impacts the SnapDrive and SnapManager suites. Unfortunately this could have significant impact on companies currently using those products so you need to be familiar with the changes. In KB7010074 (NOW access required) it clearly states that current versions (when running on Windows) don’t work with ONTAP 8.2;

Because of changes in the licensing infrastructure in Data ONTAP 8.2, the license-list-info ZAPI call used by the current versions of SnapDrive for Windows and the SnapManager products is no longer supported in Data ONTAP 8.2. As a result, the current releases of these products will not work with Data ONTAP 8.2.

 The SnapManager products mentioned below do not support ONTAP 8.2.

  • SnapDrive for Windows 6.X and below
  • SnapManager® for Exchange 6.X and below
  • Single Mailbox Recovery® 6.X and below
  • SnapManager for SQL® 6.X and below
  • SnapManager for SharePoint® 7.x and below
  • SnapManager for Hyper-V 1®.x

Unfortunately there is no workaround and we need to wait for future versions of SnapManager and SnapDrive to be released sometime in 2013 (according to the KB article) before we get ONTAP 8.2 compatibility. I’ve no major issue with this situation as ONTAP 8.2 was only released a few days ago for Cluster mode and isn’t even released yet for 7 mode customers.

If you’re using Windows 2003 with any of the above products however this could be a big deal. SnapDrive 6.5 (the latest as of June 2013) only supports Windows 2008 and newer so it’s a reasonably assumption that the newer releases will have similar requirements. Until now you could still use SnapDrive 6.4 if you needed backwards compatibility with older versions of Windows – I suspect Windows 2003 is still plentiful in many enterprises (as well as my own). Now though you have a hard choice – either upgrade the relevant Windows 2003 servers, stop using the Snap products, or accept that you can’t upgrade ONTAP to the 8.2 release.

Personally I have a bunch of physical clusters all running Windows 2003 and hosting mission critical SQL databases and if these dependencies don’t change I’ll have to accelerate a project to upgrade them all in the next year or so, something that currently has no budget. Software dependencies aren’t unique to Netapp nor are Netapp really at fault – upgrading software is part of infrastructure sustainability and Windows 2003 is ten years old.

Lesson for the day: Running old software brings with it a risk.