VMware vSphere 5 Architecture
The architecting and deploying VMware vSphere 5 can be and are
the subject of entire books, this discussion is not meant to be a
comprehensive approach to the subject. It is designed to give you
enough information to set up the environment properly and to consider
which features of the VMware vSphere platform you should take advantage
of in your VMware View design.
VMware View 5 is supported on virtual
infrastructure 4 SP 2 and up. vSphere 5 has been designed to enhance
the VMware View platform by adding additional capabilities tuned for
Virtual Desktop Infrastructure. For example, VMware vSphere 5 supports
solid-state drives, which enables you to offload storage I/O as part of
your VMware View design. Indeed, one of the keys to a successful and
scalable virtual desktop design is to understand the benefits of
caching certain components of the architecture and what technology is available
to do so. Using SSD drives in ESXi is a good example of taking
advantage of the capability to cache to deliver good performance.
In addition, vSphere 5 introduced support for
3D graphics provided through the CPU or a supported 3D graphics cards
installed in the vSphere 5 host.
VMware vSphere 5
To deploy View, you first need to deploy your
vSphere infrastructure. When you are planning the deployment, you
should consider the technology that has been designed into the platform
to aid in installation and configuration. As an example, say you are
deploying a large VDI environment that will consist of 30–40 ESXi
hosts. Your strategy may be to deploy vCenter, deploy one ESXi host as
a configuration template, and then use a combination of Auto Deploy and
host profiles to ensure the environment is built to proper
specification.
Planning a vSphere infrastructure starts with
understanding the basic building blocks and key considerations. Virtual
infrastructure involves the components described in the following
sections.
VMware ESXi
With vSphere 5, VMware has moved completely
to ESXi. ESXi has replaced the ESX native installation and comes in two
installation options: embedded or installable mode. ESXi is a
stripped-down version that removes many of the components included in
the Console OS to provide a more purpose-driven and secure hypervisor
platform. The original Console OS has been replaced with the direct
console user interface (DCUI), which reduces the configuration required
at the console to eliminate much of the software that was provided with
ESX native. You would think that this would reduce the number of
features available on ESXi versus ESX native. ESXi and ESX native have
feature parity, and as of vSphere 5, there is no longer an ESX native
option.
ESXi is an operating system, and like all
operating systems, it has a hardware compatibility list. Although the
number of devices has increased dramatically as virtualization has
become mainstream, it still is a good idea to verify that any hardware
you will purchase for the environment is supported by VMware.
In deploying vSphere, you need to consider
SAN, networking, and physical server requirements. It is a best
practice to separate out the different layers of traffic that make up
a virtual environment. At a base level, you have management, VMotion,
and virtual machine traffic. In addition to these common traffic types,
you also have VMware FT and storage VMotion, or sVMotion as it is
sometimes called. In addition to segregation requirements, you also
need to ensure that every network path is fully redundant within your
vSphere platform.
You should follow some general guidelines for
sizing virtual desktops on today’s enterprise servers. For a truly
redundant and low-risk environment, you could load all the ESXi servers
at 50% utilization of CPU and memory. This is a judgment call, however,
because architecting at 50% utilization is expensive and, it could be
argued, somewhat overkill. To use a simple example, if you have a
two-node cluster and you expect to run 100 virtual desktops, you would
run 50 desktops on each in an active–active configuration. If you lose
a host, you could run with no performance impact while replacing the
failed server. This capability makes the architecture both resilient
and low risk.
You also need to consider the level
of VMware high availability (HA) that is required in your virtual
desktop environment. As you consolidate the desktops onto a virtual
environment, the underlying virtual infrastructure should be more fault
tolerant. This does not necessarily mean that you need to consider the
desktop highly available. For example, in a physical world you often
treat desktops as disposable, so you essentially redirect critical data
to file servers and don’t typically back them up. In a virtual
environment, you can apply the same concept using a better set of
tools, such as Persona Manager. The supporting infrastructure or
vSphere environment should be highly available and more fault tolerant
because as the environment scales, the criticality of the service
increases.
