Storage Nation

This is a series of posts covering the subject of Storage Management.  Previous posts: The Four Pillars of Storage Management Four Pillars: Service Four Pillars: The Service Catalogue Four Pillars – Service: Chargeback In the previous article I discussed the subject of Billing and Chargeback.  This entry discusses some of the issues raised in that post as additional considerations.

This is part of a series of posts with video recorded at the HP Blades Day in Houston, February 2010.  Previous posts: HP Blades Day – Lab Session: Clip 1 HP Blades Day – Lab Session: Clip 2 This is another post for the hardware geek in you.  James Singer discusses fans; air moving devices is you’re familiar with the IBM lingo.  You’d think fans weren’t that important, but in the C7000 chassis, they are super efficient.  In fact, they were designed with the assistance of model aeroplane experts.  A quick word of warning; this clip is a little noisy towards the end, when James demonstrates the fan’s power. Enjoy! Click here to view the embedded video

I love the late evening banter on Twitter, where a conversation between a number of individuals turns into a personal rant from yours truly.  Tonight’s subject – performance management of Microsoft Exchange and overconfiguration of storage for email. Some 4 years ago, I was working for a large investment bank (which may now be defunct) and I did the storage configuration and testing for the new Exchange deployment.  Having been called in at the last minute, I had to take the storage configuration provided by the previous experts and the vendor.  This consisted of a DMX1000-P2 (performance model) and using only the fastest 50% of the drives.  As the pre-deployment testing progressed, all MSFT Exchange servers were installed, configured and loaded with the Jetstress software to test performance.  Unsurprisingly, as the setup had been so hideously over-configured, the  testing concluded with flying colours.  As I checked out the configuration of the individual servers, I found wide variations in their setup; HBAs at 1Gb/s rather than 2 (with HBAs on the same servers running at different speeds); drivers and firmware that were inconsistent; differences in the host logical volume layout.  Despite all this, the configuration worked flawlessly, even with all of the intended production servers running stress loading at the same time. This isn’t the only over-configured Exchange implementation I’ve seen; another springs to mind that used 300GB drives as 146GB models.  I’ve also seen the same attention given to Notes.  In that instance, however, common sense prevailed and it became clear very quickly that each Notes server could be more heavily loaded with data and that there was no need to short-stroke the drives to achieve the desired throughput. Performance/capacity logic was applied and the configuration streamlined

A little discussion on Twitter between myself, @BasRaayman, @UltraSub and @esignoretti got me thinking about the evolution of VPLEX and the whole caching thing.  It’s something I mentioned on one of my previous VPLEX posts and it could have significant impact on designing and implementing VPLEX solutions.  Here’s the conundrum. First of all, be aware that VPLEX is a write-through device.  That means it doesn’t keep I/O in cache and confirm write-completion to the host; it waits until the data is secured on disk before confirming the write success.  One the one hand this is a positive thing; the VPLEX clusters contain no data in cache that could become stale or in the event of a failure, not written to disk.  In VPLEX-Metro where synchronous cross-site writes are permitted, it also makes sense from a simplicity point of view; everything is on physical disk before the host I/O is confirmed as successful, so there’s no recovery issues to worry about. However, write through in a heterogenous environment might not be so good.  Performance is directly connected to the storage layer.  Storage design has to continue as before and two layers of complexity now have to be considered in order to assure best performance

This is a series of posts covering the subject of Storage Management.  In this post, I’ll be discussing one of the four foundations, Service and what exactly that means. My Four Pillars of Storage Management are defined in this initial post

You may have assumed from my previous post on VPLEX that I am negative towards the concept of storage federation.  That couldn’t be further from the truth.  In fact, ever since I was involved in deploying ESX onto enterprise storage infrastructure (some 4 years ago), I’ve been waiting for the day true federation would arrive.  Here’s why. Static Configurations Think back to the time before server virtualisation (yes, there was one).  Physically static servers failed over to other physically static servers located in remote data centres.  Once deployed, servers very rarely moved unless there were major physical data centre issues or an upgrade was being performed.  In fact, even when server upgrades occurred, it was typical to acquire a new server and rebuild the application and data on that new hardware to remove any issues with new server drivers, hardware firmware and so on

Those of you with relatively good memories will remember last year’s announcement from Hitachi/HDS, which at the time promised more than it delivered.  In fact, the anagram posed by Claus Mikkelsen on his blog and used as part of the press release was “REGRADES OUR CLASSY TREATS” and should have translated to “STORAGE ARRAYS CLUSTERED”  my tongue-in-cheek alternative was “A DREARY STORAGE CLUSTER” (who could have imagined such a serendipidous alternative).  With EMC’s new release of VPLEX, it’s deja-vu all over again…. With the usual EMC fanfare, VPLEX has been heralded as “ a new storage platform “.

Despite my doubts about its usefulness, on my recent holiday in the US I purchased a shiny new iPad.  OK, over the last few week’s I’ve talked about how I couldn’t see the point of the platform, but two things conspired against me; (a) I love technology (although I stop short of calling myself a geek) and (b) reverse peer pressure from my family goading me about my inability to walk past technology without acquiring it, tipped me over the edge.

I case you didn’t know, I’ve been on holiday since the beginning of April.  I was expecting (after two weeks of rest and relaxation) to be heading off to a new and potentially challenging piece of work.  Unfortunately that work is no longer there.  Not only is the work not there but neither am I – I’m still in the US with my family and can’t travel due to the restrictions in place on aircraft after the volcano eruption in Iceland. In the space of less than a week, I’ve had to put contingency plans into place for both work and pleasure.  We’re lucky; we hadn’t left to go to the airport and so have managed to stay in our accommodation in San Diego.  A two week holiday will simply turn into three; school will have to wait for my wife and children. As for work, I already have some contingency plans in place and things will work out.  But who could have thought such as “simple” natural phenomena could have ramifications for the whole world? The People Problem For the UK and most of Europe the last two weeks have been Easter holiday time (I believe this overlapped the US Easter holiday too).  Quite rightly people have been enjoying time away, but now without the ability to get back home and the fact that more people are away than usual, the lack of key personnel will be causing problems.  None of these are insurmountable if: Key staff can be contacted while away – not disturbed, mind you but contacted in an emergency.  Even with tools as simple as a Blackberry or iPhone, decisions can be made and confirmed via phone, SMS or email

After posting my blog on increasing storage utilization with Dynamic Provisioning , I visited a very large customer who was in the process of implementing thin provisioning from different vendors. Our Dynamic Provisioning on the USP V was the first to go live. Thin provisioning from other vendors were still undergoing evaluation.