First, let’s define what I mean by a stretched vSphere cluster. I am talking about a vSphere  (HA / DRS) cluster where some hosts exist in one physical datacenter and some hosts exist in another physical datacenter. These datacenters can be geographically separated or even on the same campus. Some of the challenges will be the same regardless of the geographic location.

To keep things simple, let’s look at a scenario where the cluster is stretched across two different datacenters on the same campus. This is a scenario that I see attempted quite often.

This cluster is stretched across two datacenters. For this example let’s assume that each datacenter has an IP-based storage array that is accessible to all the hosts in the cluster and the link between the two datacenters is Layer 2. This means that all of the hosts in the cluster are Layer 2 adjacent. At first glance, this configuration may be desirable because of its perceived elegance and simplicity. Let’s take a look at the perceived functionality.

• If either datacenter has a failure, the VM’s should be restarted on the other datacenter’s hosts via High Availability (HA).
• No need for manual intervention or something like Site Recovery Manager

Unfortunately, perceived functionality and actual functionality differ in this scenario. Let’s take a look at an HA failover scenario from a storage perspective first.

• If virtual machines failed over from hosts in one datacenter to hosts in another datacenter, the storage will still be accessed from the originating datacenter.
• This will cause storage that is not local to the datacenter to be accessed by hosts that are local to the datacenter as shown in the diagram below.

This situation is not ideal in most cases. Especially if the datacenter is completely isolated. Then the storage cannot be accessed anyway. Let’s take a look at what happens when one datacenter loses communication with the other datacenter, but not with the datacenter’s local hosts. This is depicted in the diagram below.

• Prior to vSphere 5.0, if the link between the datacenters went down or some other communication disruption happened at this location in the network, each set of hosts would think that the others were down. This is a problem because each datacenter would attempt to bring the other datacenter’s virtual machines up. This is known as a split-brain scenario.
• As of vSphere 5.0, each datacenter would create its own Network Partition from an HA perspective and proceed to operate as two independent clusters (although with some limitations) until connectivity was restored between the datacenters.
• However, this scenario is still not ideal due to the storage access.

So what can be done? Well, beyond VM to Host affinity rules, if the sites are truly to be active / standby (with the standby site perhaps running lower priority VM’s), the cluster should be split into two different clusters. Perhaps even different vCenter instances (one for each site) if Site Recovery Manager (SRM) will be used to automate the failover process. If there is a use case for a single cluster, then external technology needs to be used. Specifically, the storage access problem can be addressed by using a technology like VPlex from EMC. In short, VPlex allows one to have a distributed (across two datacenters) virtual volume that can be used for a datastore in the vSphere cluster. This is depicted in the diagram below.

A detailed explanation of VPlex is beyond the scope of this post. At a high level, the distributed volume can be accessed by all the hosts in the stretched cluster. VPlex is capable of keeping track of which virtual machines should be running on the local storage that backs the distributed virtual volume. In the case of a complete site failure, VPlex can determine that the virtual machines should be restarted on the underlying storage that is local to the other datacenter’s hosts.

Technology is bringing us closer to location aware clusters. However, we are not quite there yet for a number of use cases as external equipment and functionality tradeoffs need to be considered. If you have the technology and can live with the functionality tradeoffs, then stretched clusters may work for your infrastructure. The simple design choice for many continues to be separate clusters.

My role at TBL allows me to examine many virtual infrastructures. One of the common challenges that I see in many of these infrastructures is resource allocation after they have been running for a while. Workloads were virtualized quickly without proper capacity planning and by the team I am called in to assess the infrastructure, resources are strained in the environment. This point may come quickly if proper capacity planning is not performed up front. However, ongoing capacity planning must be performed periodically as moves, adds, and changes occur in the virtual infrastructure. Below are a few general recommendations for proper capacity planning:

• Plan for performance, then capacity for production workloads – I have seen the opposite happen too many times to count. The storage capacity is planned for, but not the storage performance. Look at all workloads that will be virtualized. Measure the peak IOPS that will be required. Plan to fulfill the IOPS requirements, then add disks if necessary to meet the capacity requirements. This general approach will ensure a solid performance foundation.
• Plan for peaks, not just averages – If you plan for averages, the environment may run OK until a performance spike is encountered. Then, performance may suffer for a critical workload. Think about things like month-end processing, student enrollment, or sales peaks. These times are when the environment needs the resources the most. Plan for the peaks accordingly.
• Don’t forget about overhead – In a virtual infrastructure, there are some files and associated overhead required by the system to run the virtual workloads. These files may not seem like much by themselves, but in aggregate, they can add up to a lot. An example of something to plan for might be virtual machine swap files. In a vSphere infrastructure the virtual machine swap file size is the difference between the assigned memory and reserved memory for a virtual machine.

Ongoing capacity planning is needed as well to maintain a virtual infrastructure. This is where tools like vCenter Capacity IQ can help. Capacity IQ is capable of performing ongoing capacity planning, reporting, what-if scenarios and more. For example, if you want to see at what point you need to add more capacity in your infrastructure, Capacity IQ can model that based on your deployment patterns in the past. This is a very powerful analytic tool that can help you stay ahead of your capacity needs.

If we can plan from the beginning and utilize intelligent ongoing planning for capacity, then we can move from a reactive stance to a proactive stance while still being able to provide innovation quickly for the business. That’s a powerful combination. If you have questions about capacity planning, please feel free to contact me.

What if you could consolidate your branch office services with your router? That is exactly what the Cisco UCS Express is meant to do. The UCS Express is a Services-Ready Engine (SRE) module that works in Integrated Services Router Generation 2 (ISR G2) routers. This module is a server that you can run VMware ESXi on to provide branch office services. Here is an example of an ISR G2 device:

The slots you see at the bottom of the device is where the SRE UCS Express modules are located. A UCS Express module is seen below.

Here are a couple of the highlights of this architecture:

• (1) or (2) 500 GB drive options are available (hot swap hard drive)
• (1) or (2) Core CPU’s are available
• 4 or 8GB of RAM available
• iSCSI Initiator Hardware offload if you need to connect to an external iSCSI device
• There is direct SRE to LAN connectivity which reduces cabling
• Maintenance is covered under SMARTnet

This architecture provides all that a branch office may need by virtualizing several branch office services onto the SRE UCS Express Module. The ESXi instance can be managed centrally by your existing vCenter installation. This gives you the benefits of local service access and centralized management while reducing the equipment needs at the branch office. Pretty slick.

If you would like to discuss how this architecture might be able to help your organization or want further technical details, please feel free to contact me.

Memory Reclamation

• Transparent Page Sharing (TPS)
• Think of this as deduplication for memory. Identical pages of memory are shared with many VM’s instead of provisioning a copy of that same page to all VM’s. This can have a tremendous impact on the amount of RAM used on a given host if there are many identical pages.
• Balooning
• This method increases the memory pressure inside the guest so that memory that is not being used can be reclaimed. If the hypervisor were to just start taking memory pages from guests, the guest Operating Systems would not react positively to that. So, balooning is a way to place artificial pressure on the guest VM so that the VM pages unused memory to disk. Then, the hypervisor can reclaim that memory without disrupting the guest OS.
• Memory compression
• This method attempts to compress memory pages that would normally be swapped out via hypervisor swapping. This is preferable to swapping as there can be a performance impact when memory is swapped to disk.
• Hypervisor swapping
• This is the last resort for memory management. The memory pages are swapped to disk. New in vSphere 5 is the support for swapping these memory pages to SSD’s. This increases the performance when swapping is needed.

As you can see there are many memory management techniques in vSphere that allow greater consolidation ratios. The hypervisor in the virtual infrastructure does much more than just host guest VM images. There is a lot going on under the hood to consider before choosing a specific hypervisor to serve as the foundation for your infrastructure. Feel free to contact me if you would like to discuss any of the “under the hood” features of vSphere.

Well, not yet, but VMware is sure working hard to make this a reality. I have been discussing with clients and colleagues why the traditional desktop model does not make sense for “today’s” end user for quite a few “todays.” VMware calls a user-centric approach to computing End User Computing. End users need access to their applications and information on any device from anywhere. They should not know or care about the nuances of the Operating System. This sounds like a lofty goal, but it is becoming a reality more and more every year.

If we look at the last decade (or even further into the 90’s), we have seen the Operating System itself have the spotlight. New “Operating System” features were actually marketed towards end users.

• The latest OS supports more RAM!
• The latest OS supports 64-bit computing!
• The latest OS supports Solid State Flash Drives!
• The latest OS can take advantage of a USB drive to cache your file searches and access! (What?)

I can’t think of one real end user (IT folks don’t count, sorry) that cares about any of the above. Operating System, you had your chance in the spotlight. It’s time to fade into the background where you belong. End users care about their applications to get work and play done. Operating Systems just get in the way of delivering those applications more often than not.

Virtual Desktop Infrastructure certainly eases the pain of managing the Operating System for the IT Administrator while still giving the end user a computing experience that they are accustomed to. For some end users the desktop that they are accustomed to will be adequate. For some users, IT needs to deliver a computing experience beyond what they are accustomed to. No start menus, no shortcuts, no c: drive, d: drive, etc. What I’m talking about is an end user experience where the applications take front and center on any device from anywhere. This is exactly the type of technology that VMware has been working on and was previewed at VMworld 2011. They are calling it Project Appblast.

Imagine being able to launch any application (including Windows Applications) using nothing more than an HTML-5 compliant browser. Below is a technical preview of this exciting project from VMware.

The desktop PC and Operating System’s days are numbered. Bring on the apps.