VMware VSAN features and realities
A comprehensive collection of articles, videos and more, hand-picked by our editors
Unless you have been on a deserted island, you have heard about VMware's Virtual SAN. After VMware pushed the beta form heavily for a few months, it launched the general availability form with the release of vSphere 5.5 Update 1.
Some VMware admins may see Virtual SAN (VSAN) as an opportunity to dump their aging storage area network (SAN), while other companies will run VSAN in their test and development environments first to gauge performance, reliability and usability.
Before you jump in with both feet and start moving all your company's most critical data to VSAN, there are a few things that you need to watch out for when implementing VSAN:
Many people assume VMware VSAN allows you to simply take the servers you have, utilize the local hard disk (HD) for storing virtual machines (VMs), somehow bond all those disks together as a single virtual storage pool, add advanced functionality, and get rid of your SAN.
But first, there are a number of requirements that you should be aware of. For example, each server will need at least one traditional spinning disk, one solid-state disk (SSD) and an additional source to boot VMware ESXi. That additional source could be a USB key (either plugged into the server or embedded on the server motherboard) or the server could be PXE -booted with ESXi.
To start, the two physical disks in the server (the HD and SSD) must be blank. That means they cannot contain VMs or be used to run ESXi.
This means you cannot simply take a physical server running ESXi on a physical disk (which may or may not have local VMs stored on it), add an SSD to the server and simply deploy VSAN. Typically, there will be some downtime for an existing host to deploy VSAN (unless the host happens to have one SSD and one HD that are already unallocated on a running server, which isn't very common).
Fortunately, with vMotion and storage vMotion, it's very easy to move VMs off an existing host, perform the changes, and then migrate the VMs and virtual disks back to the host and new VSAN data store. VM disk files may or may not be stored on the same host when moved into VSAN, as VSAN has no data locality controls (which VMware says is a good thing, by the way).
In addition to the SSD and HD requirements, you'll also need a SAS or SATA Host Bus Adapter (HBA), or RAID controller that is set up in non-RAID (pass through) mode. A host must also have at least 6 GB of RAM and it must be managed by vCenter and be part of a virtual SAN cluster. A GB Ethernet adapter is also required, but 10 GB is recommended.
I recommend only using VSAN with hardware on the VSAN compatibility list.
Not all VSAN nodes are required to contribute storage. Thus, you could have a minimum of three VSAN nodes with storage in a cluster and, let's say, a fourth node that contributes no storage.
In many cases, your existing environment may not support the VSAN requirements, or the server you have might not meet the compatibility requirements. In some cases, it may be less expensive to purchase new hardware than it would be to upgrade your existing hardware to make it VSAN-compatible.
VMware now offers a certification program for VSAN-compatible server clusters. These VSAN Ready Nodes are an ideal approach for companies that want to deploy VSAN, but don't want to mess with modifying their existing server configuration. In that case, they could purchase a VSAN Ready Node cluster and simply migrate off their existing servers and SAN to the VSAN Ready cluster.
While VSAN beta was free, some people will be disappointed to find that the general availability (GA) form of VSAN is not free and is not included with vSphere. VSAN costs $2,495 per processor and VSAN for desktop virtualization costs $50 per user. Those considering VSAN should compare the cost of purchasing and maintaining VSAN to the cost of upgrading storage hardware.
VSAN storage limitations
Another limitation that might not be clear for users is that VSAN can only be used to store vSphere VMs.
Physical servers may still share storage with vSphere hosts on your existing SAN, but with VSAN, only vSphere VMs will be able to use the storage. You could virtualize those physical servers to take advantage of the VSAN storage, but there is probably a reason those servers aren't virtualized.
Anyone looking to deploy VSAN and replace their existing SAN should also consider training requirements. There will be VMware education courses, books and video training. Administering VSAN will likely be much easier than administering most existing SANs; however, there is still important knowledge users must learn before using VSAN in a production data center.
David Davis asks:
What has been the most difficult part of switching to VSAN GA?
0 ResponsesJoin the Discussion