Shared storage isn't absolutely necessary in a VMware environment, but it certainly makes life easier, with benefits in the areas of migration, availability, backup and server performance. In this video, Howard Marks, founder and chief scientist for DeepStorage.net, drills into the reasons why shared storage is so important to VMware-based servers. Watch the video or read the transcript on VMware shared storage below.
Big companies over the past 15 or 20 years have shifted from direct-attached storage [DAS] -- that is, disk drives attached to the servers -- to storage area networks, where you have one common set of disks that's connected to multiple servers. Now, Fibre Channel has been the traditional mechanism to do that, and it has been both arcane and expensive. [Small and medium-sized businesses] and [small and medium-sized enterprises] who recognize that cost is important, and who also have a fixed set of IT personnel with a fixed set of skill sets, have realized while [they] may need to buy one-third more disk drives to distribute disk drives across the servers instead of having shared storage, [they] don't have to hire a $120,000 dedicated storage administrator -- and $10,000 of disk drives is cheaper than a $120,000-a-year administrator. DAS is cheaper; it doesn't require any special storage skills other than knowing that RAID 5 is not better than RAID 1 because it has a higher number.
More on VMware shared storage
VMware provides advanced shared storage options
Shared storage considerations for virtual infrastructures
Microsoft has, over the past several generations of Exchange, redesigned Exchange so that it is no longer nearly as beneficial to run Exchange on shared storage. Exchange can now replicate its own data so you can have high availability with two servers with direct-attached storage. In part, Microsoft realized people only have so much money to run their email system, and if Exchange costs a lot, people are going to stop running Exchange and they're going to use Gmail for their employees. …
However, many of the features that [will most] drive you to a hypervisor -- the things that are going to make your management life easier -- require shared storage. Many of us started virtualizing simply to save money on hardware. [We say], "If I run VMware, I can run these seven servers, each of which only has six users because there's the one that the controller's office uses and the MRO [multiregion operation] application -- [the one] the guys that fix the machines in the plant use." Most organizations have a relatively large number of what we like to call "crapplications." They're important, but they're not huge. They're not widely dispersed; they're just important for the narrow focus that they're run in. [For example], the accounting folks won't let you turn off the accounting system that they used to use, just in case someone needs to look at historical data. And so, you now have a server running a 10-year-old version of an accounting package under Windows NT4 because it is a 10-year-old version of an accounting package and it won't run under Windows 2008. Virtualizing was a good solution for that.
Once we started virtualizing those applications, however, you start to discover that [shared storage] makes life easier. If we discover that I need to put more memory in a … physical server, I need to schedule downtime. I need to tell the users I'm going to schedule downtime, the server is going to go down, I'm going to put more memory in it. Being the conservative kind of guy I am … I schedule a four-hour maintenance window, because if I schedule the 15 minutes that it's actually going to take, something will go wrong. If you schedule four hours, it will take 15 minutes. If you schedule 15 minutes, it will take four hours.
With vMotion, I can say, "Well, at 9 o'clock I'm going to vMotion all of these servers off that host. Then I'm going to turn the host off, I'm going to put more memory in it, I'm going to turn it back on, and I'm going to vMotion servers back to the host." How much downtime? None. But, vMotion requires the host the server is running on now or the host the desktops are running on now, and the host the desktops are going to be running on after I move them -- both [share] the same disk. So, shared storage [isn't done to simplify things and get higher utilization]. Shared storage becomes a requirement to get this kind of benefit.
I've worked in a lot of organizations where they've built all sorts of funky clusters so that a server can go down and their application won't fail, but they're trying to protect themselves against hardware failures. Well, if I'm running VMware and a host goes down, VMware HA will spool those servers or those desktops back up across my other hosts. I don't need to do something like synchronize the directories for the Web server and make sure that users always make changes on the primary server and replicate their changes to the other three servers that are in the load-balanced cluster. I can just make that a high-availability system.
Finally, having the right shared storage can vastly improve your backup performance and can vastly reduce the storage and performance impact of things like cloning a new server, because you can offload those functions to the storage array through the VMware array application APIs, VAAI.