For the second time in two days I find myself drawn to comment on a Storagebod related post.
The subject today is Tony Asaro's rant on one of StorageBod's recent posts denegrating virtualisation.
Now let's get things clear - I like HDS's implementation of virtualisation. I've deployed it, I'd recommend it again, but some of Tony's comments are way off base.
"The cost per GB for your DMX FATA and SATA drives is much higher than using other tiered storage solutions." - yes, but UVM ain't free - there's a licence charge. When you virtualise an array, you're not paying for just JBOD, you're paying for extra stuff like the controllers. Also on the USP array you have to reserve out ports for virtualisation; if you connect the storage together through a fabric then you'll be taking up fabric ports too. The point is, the cost of HDS virtualisation means there's a break even point in the TBs of storage - from my experience, that was a big number.
"Storagebod does not want to have applications span multiple storage systems but other IT professionals are open to doing this. And storage virtualization is a powerful technology to enable this. That is the point of any virtualization technology - to overcome the physical limitations of IT infrastructure." - there are very good reasons for not spanning arrays with applications, like ensuring replicated storage is consistent, for instance. Whilst virtualisation allows a virtual array to grow in size to almost limitless amounts (247PB in USP V) it also means there's a concentration of risk; multiple components to fail, multiple places where data can be pinned in cache when things go wrong. In fact, placing data on lower availability arrays will increase risk.
"That may be true for Storagebod but that is not my experience in most data centers. We are shifting from transactional data being the “big space-hogs” to unstructured data consuming the lion’s share." - this may be true, but USP LUN-based virtualisation isn't going to help here. Overlaying file-level granularity data migration onto LUN-based arrays would require a particularly complicated scheme for ensuring data for migration was concentrated onto exactly the right LUNs so they could be moved to another tier. Anyway, why put unstructured data on expensive enterprise arrays?
I think we all expected Tony would have something better to talk about than technology HDS brought to the market 4+ years ago. We need to hear something new, something game-changing (oh and not me-too stuff like HDS putting SSDs into their arrays).
Tomorrow I *promise* I'll talk about something else.
Wednesday, 3 December 2008
2 Days, 2 Bod Posts
Subscribe to:
Post Comments (Atom)
Posts
1 comment:
I appreciate the feedback. Athough I think “rant” is a bit extreme. Since I am half-Japanese and half-Italian I am a bit conflicted about it myself. My Japanese relatives may agree with you that it was a rant but my Italian relatives would consider it delicate and low-key. And since I am a New Yorker – we are inherently obnoxious. Oh well.
One thing I think it is important to point out – and whether it is on my HDS blog, my contemplatingit.com blog and other blogs that I write – there will be different audiences with varying levels of exposure and experiences. Some end users have implemented and/or researched these solutions but others have not. In some cases they have considered them but put them on the shelf. I specifically have brought up issues in some of my recent blogs that I feel are important in an economic downturn. And I don’t assume that everyone has expertise in them. Issues like storage virtualization, intelligent tiering, data de-duplication, etc. – it isn’t an issue of newness but value to the end user. So yes – I will be talking about stuff that adds value – even if it is not new.
As for your three points:
1. As we all know each situation is different. Consider a simple but not uncommon environment in the HDS world – a data center with a USP-V and an AMS that they already have on the floor. Consider a data center with a USP-V and another storage system – a 3rd-party solution or even an HDS system - that is coming off of maintenance – why not just use it as a lower tier? There are a number of variations that are valid and worth considering.
2. Great points. But again there are situations where this is a reasonable approach. Additionally, I did bring up the point in my “rant” that you could also tier by application. Now I understand that this easier said in done – but it is something to consider as a strategy going forward.
3. I agree and disagree with you on a couple of points. There is a ton of unstructured data on expensive enterprise arrays – however - I agree that there are better and more appropriate storage systems to store it. But the reality is that email with attachments, Microsoft file servers, Unix and Linux file servers, SharePoint, video, scanned images, audio, photos, etc – all being stored on SAN-attached Tier One storage.
The other point you made about the USP-V LUN virtualization and file abstraction is true but there are relatively easy ways to implement this. I will use just one example that I think is pretty straightforward. Let’s say you have a bunch of Microsoft file servers attached to your existing USP-V because that is what you had at first but over time you acquired an AMS or a CLARiiON. You could move the entire volume from the USP-V to the AMS or CLARiiON virtualized behind it. Now why not just do a one time data migration versus doing tiering? There are a number of reasons – including transparency – the tiering can be done online and in the background without disrupting the business. Additionally, there may be data protection solutions in place that you want to preserve. You may be using the USP-V TrueCopy or Universal Replicator to replicate those volumes to your DR site. Also you may want to have the ability to move the volume to another storage system as needed. And you may be virtualizing the USP-V and AMS or CLARiiON for other purposes.
Rant on brother!
Post a Comment