Why DBAs should care about storage virtualization

Vendor hype aside, storage virtualization is really expensive technology that few shops really use.  Don’t get me wrong, I love the technology, but seriously, it’s expensive.  And that’s just the hardware/software – try hiring somebody with storage virtualization experience – hoo, boy.  But something is coming that’s changing the game, redefining what storage virtualization means.

When I speak at user groups, I usually ask for a show of hands to see how many database administrators are running production SQL Servers in virtual environments like VMware ESX and Windows 2008 Hyper-V.  Lately I’ve seen about a third of the group raising their hands.

VMware ESX 3.5 added a feature called Storage VMotion that enables sysadmins to move a server’s hard drives from one array to another.

In real time.  No reboot or downtime required.

Without telling you.

That specific feature isn’t usually lumped in as “storage virtualization”, but for all practical purposes, that’s what it is – or at least a light version of storage virtualization.  It enables fast, fluid change in datacenter storage.

And since more and more database servers are getting virtualized, DBAs need to understand how storage virtualization affects their storage planning, performance tuning and budgeting.

At this fall’s SSWUG SQL Server Virtual Conference, I’ve got a session to explain this very topic.  In an hour, you’ll learn why you care about this new feature in VMware (and from other vendors), what it can do for you as a DBA, and what you need to look out for.

Previous Post
When will you use SQL Server 2008 in production?
Next Post
Leaving Caroline Collective

2 Comments. Leave new

  • Hhhmm, that is cool. I have seen live SQL instances get vmotioned in the middle of transactions but it still left a single point of failure at the disk.

    So this could be like a poor man’s SRDF and VMotion across the WAN? http://www.emc.com/products/detail/software/srdf-asynchronous.htm

  • That was my first thought too, but it only works for really small arrays and really fast WANs – it’s not really efficient for that kind of thing. It’s designed more for moving individual machines from one storage tier to another. There’s no concept of keeping snapshots in sync the way you can with some storage virtualization products or replication products.

    The other problem with using it for disaster-planning role swaps is that when it’s role swap time, you would want to VMotion all of your critical production stuff across the WAN. It’d take forever.


Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.