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.
No comments:
Post a Comment