A: Not every IT environment is large enough to need a SAN. Some businesses don't have the budget to afford one or the in-house experience to use one effectively. However, almost every environment that plans a move to virtualization also desires that move to include high availability for VMs.
This use case is one of the primary reasons for the release of VMware's vSphere Storage Appliance. This appliance is intended to be a collection of either two or three ESXi hosts that store their VMs within locally attached storage. Using built-in replication, VMs created atop one host are automatically available atop other hosts as well. This replication enables VMware's high availability functionality to migrate VMs from a failed host to a working host, without the need for shared storage on a SAN.
Q: What are the important limitations in the VMware vSphere Storage Appliance?
A: With the release of vSphere 5.0, VMware also quietly released a product called the vSphere Storage Appliance (VSA). This product intends to provide failover capabilities for VMs, but without requiring shared SAN storage. It's intended for use by smaller IT environments that either can't afford a SAN or lack the experience to use one effectively.
Although the VSA can indeed enable a high availability-like experience atop locally attached storage via its built-in replication, it does so with some significant costs. Consider the following limitations carefully:
· The VSA doesn't support memory overcommit.
· The VSA, once installed, prohibits adding additional storage to a VSA cluster.
· The VSA creates a useable partition that's equivalent to the amount of disk space in the server that contains the least quantity of disk space.
· The VSA isn't intended to be installed onto existing ESXi hosts; it prefers a "green field" installation onto essentially unconfigured hardware. ESXi hosts can't run VMs before creating the VSA cluster.
· The VSA, in combination with VMware's RAID requirements for locally attached storage, requires a 75 percent storage overhead for redundancy. This requirement means only 25 percent of deployed storage is actually available for use.
· The VSA can be configured in a two- or three-server configuration that, once installed, can't be altered.
· VMware suggests you don't run vCenter Server within VSA as a VM because the loss of a datastore could prevent access to the VSA Manager. As a result, an additional and separate physical computer or VM is required to run vCenter Server and the VSA Manager.
· The VSA reserves 33 percent of CPU and memory resources on a three-host cluster and 50 percent of CPU and memory resources on a two-host cluster for high availability admission control.
Q: Can I install VMware vSphere Storage Appliance without EVC Enabled?
A: VMware's vSphere Storage Appliance (VSA) is a new product, released at the same time as vSphere 5.0, that's intended to provide an alternative virtual infrastructure for IT environments that don't have a SAN. As an appliance, VMware recommends installing this product onto hosts that are essentially unconfigured.
One component of the VSA's installation checks to see if each host can be a part of the same cluster that has VMware Enhanced vMotion Compatibility (EVC) turned on. Although this verification is extremely important for production environments, EVC isn't supported when evaluating the VSA's software atop VMware Workstation. As a result, a slight hack is required to disable the EVC verification.
To disable the EVC check, navigate to C:\Program Files\VMware\Infrastructure\tomcat\webapps\VSAManager\WEB-INF\classes and open the file titled dev.properties. Modify the line evc.config=true to evc.config=false.
Q: Can I migrate services from my Windows Server x cluster to a Windows Server 2012 R2 cluster?
A: Microsoft provides an n-2 cluster migration support. This means the migration of clustered services is supported from two versions back.
This means that for a Windows Server 2012 R2 target, cluster then services can be migrated from Windows Server 2012 clusters (n-1) and from Windows Server 2008 R2 clusters (n-2). It's important to note that migrating cluster services doesn't copy storage--when migrating services, the cluster storage is moved from one cluster to another. Only the resource configurations, which are effectively registry values, are moved from the source to the target cluster.
If you have an older cluster, for example Windows Server 2003 R2, and want to move to Windows Server 2012 R2, then one option is to stand up a temporary Windows Server 2008 R2 cluster and use that as an interim hop for the migration of services to Windows Server 2012 R2.
