Many enterprise IT departments that make the move to implement virtualization for the first time are struck by...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
the fact that they now need shared storage. Perhaps they never have had the need for shared storage before (after all, direct attached storage, or DASD, works just fine) or perhaps they didn’t realize how critical shared storage is to a virtual infrastructure (welcome to virtualization – you need shared storage).
More on virtualization in health care
Finding the right storage for server virtualization implementations
For health record storage, SAN technology offers speed, flexibility
Tips for thin provisioning storage in a health care setting
Discuss virtualization in health care with others at Health IT Exchange
This two-part series explores the different shared storage options available for virtual infrastructure and then provides the pros and cons for each.
Why you need shared storage for your virtual infrastructure
It's entirely possible to use any version of vSphere (ESXi) without shared storage, but you won’t be able to take advantage of most of the benefits that you are likely expecting to receive out of your virtual infrastructure platform. Listed below are just some of the vSphere features that require shared storage:
- vMotion – one of the best known vSphere features that allows you to move a running virtual machine (VM) from one host to another with no downtime. Shared storage is required because the VM’s virtual disk actually stayed on the shared storage the whole time (which both hosts need access to) and only the memory contents is moved.
- Distributed Resource Scheduler (DRS) – uses vMotion to automatically move VMs from one host to another, with no downtime, when a VM isn't getting the CPU or memory resources that it needs from the host. While this technically isn’t "load balancing," the end results are the same and the VMs perform well because they are automatically given the resources as needed, assuming those resources are available.
- vSphere High Availability (HA) – automatically restarts virtual machines on a good host when there is a physical server failure. While VMs do have to reboot, the downtime for the end user is simply the time it takes the VMs to restart -- much less than if they were restarted manually. HA requires shared storage because the VMs remain on the shared storage (which all hosts need access to) the whole time.
In addition to these advanced features, shared storage provides many admin options that will be beneficial down the road.
There are many shared storage options available
When researching shared storage options for your virtual infrastructure, it can be difficult to make an "apples to apples" comparison. Here's a detailed look at some of these options:
- Hardware-based Storage Attached Network (SAN) – a SAN is a dedicated network that serves up data at the block level. Block level data storage serves data just as it is stored on a local hard drive – at the block level. Storage area networks work to provide access to disk arrays available to multiple physical servers so that those physical servers think that the disks are local to the operating system (OS). Almost all SANs still use SCSI but have a “mapping layer” on top, with the most popular such layers being Internet SCSI (iSCSI) and Fibre Channel (FC). A hardware-based SAN would use a dedicated disk array that is typically made up of proprietary components and with a proprietary design. Hardware-based SANs vary dramatically in size. This is evident in the fact that SAN arrays can be purchased for between $500 (for the home lab or small business) and over $1M (for large enterprises).
With virtualization comes the need to become educated on the various shared storage options that can be used with a virtual infrastructure and how they can help.
- Software-based SAN – software-based SANs are similar in concept to hardware-based SANs but instead of using proprietary hardware, they run on top of existing physical Intel/AMD servers. Software-based SANs could involve a new operating system installed on your physical server (Linux + SAN software) or they might run on top of an existing OS (just like any other Windows application). All the software-based SANs I have ever seen use iSCSI.
- Hardware-based Network Attached Storage (NAS) – contrary to a SAN that serves data at the block level, the NAS serves actual files -- not just blocks of a file. Servers connected to a NAS see a file system (versus servers connected to a SAN that see a SCSI LUN). A NAS connects to servers using an existing network, likely TCP/IP. A hardware-based dedicated NAS uses an appliance/array that has proprietary components, software and design. Like SANs, NASs come in a wide range of sizes and costs.
- Software-based NAS - like a hardware-based NAS, a software-based NAS serves files via a file system. But instead of using a proprietary hardware appliance, software-based NAS installs on an existing Intel/AMD server and either has its own OS or runs as an application in the existing OS.
How do you choose a shared storage system?
If you are using server virtualization in your data center, you need shared storage. Here are 5 key actions to take when choosing a shared storage system:
- Choose compatible shared storage. Look for solutions that are on your virtualization vendor’s hardware compatibility list. A SAN or NAS that isn’t on your vendor’s list may work, but it may perform poorly or could have problems in the future. If using VMware vSphere, look for SAN or NAS listed on the VMware Compatibility Guide. If using Microsoft Hyper-V, ensure that your SAN or NAS is in the Windows Server Catalog
- Understand your requirements. Before talking to vendors about what shared storage solution to buy, first understand your needs. You should know how much total storage you will need, your growth rate, the number of I/Os per second (or IOPS) required by your servers and applications and the number of servers that will use the shared storage. All of this information will be needed to choose an appropriately sized SAN or NAS.
- Research the options for shared storage. There will likely be many vendors, each with numerous options that are compatible with your hypervisor -- in fact, more vendors than you will really want to research. While you may be pushed to the biggest of the vendors (EMC & NetApp), it's a good idea to consider all the options, including solutions from vendors who may not seem familiar. Examples of these vendors might include Compellent (Dell), Nexenta, Drobo, Lefthand (HP), Starwind and Datacore.
- Consider SAN versus NAS. Part two of this series will provide more information on SAN versus NAS, but being able to tell your vendors what you are looking for will help to narrow your shared storage options and select a solution faster.
- Evaluate carefully. Don’t select a SAN or NAS without doing hands-on evaluation. That evaluation may include having a hardware-based SAN/NAS at your location that you can try yourself, for a week or more. Or, you could use the same hardware at a vendor's site or VMUG. Evaluating software-based NAS/SAN is very easy as they can be loaded on commodity hardware or run as a virtual machine.
Still having trouble understanding the differences between SAN versus NAS, iSCSI versus FC and whether to go with NFS? Learn everything you need to know in part two of this series.
David Davis is a contributing writer and author of the best-selling VMware vSphere video training library from Train Signal. He has written hundreds of virtualization articles on the Web, is a vExpert, VCP, VCAP-DCA, and CCIE #9369 with more than 18 years of enterprise IT experience. His personal website is VMwareVideos.com. Let us know what you think about the story; email email@example.com or contact @SearchHealthIT on Twitter.