By John Kramer, Consultant at VMware
I’ve recently been working on a customer engagement, getting them ready to deploy VMware’s Horizon Mirage to 12,000 endpoints worldwide. The main use case this customer had in mind was backup and recovery of existing endpoints and new endpoint provisioning.
During the initial phase of a Mirage project, the unique data from each endpoint is “centralized” into the data center to provide protection for the user’s data and application personality. With so many endpoints to protect, it’s key that we test our assumptions with a pilot program.
Getting off the ground
We begin by building the pilot infrastructure as close to the production configuration as possible. In this case, that included six Mirage Cluster servers, one Mirage Management server, an EMC Isilon Storage array, and the customer’s existing F5 load balancer. (Note that each Mirage implementation will be unique, as will combined use cases—migration, image deployment, and backup/recovery, for example. More variables and considerations would come into play if more than backup/recovery was needed.)
For this particular pilot we selected 200 endpoints from as many branch office locations as possible. I would normally recommend a much smaller pilot with 50–100 endpoints, but this customer needed to centralize global endpoints to a single US-based datacenter, so we needed a larger data set to test the various network configurations worldwide.
While implementing a single, centralized Mirage cluster is ideal, there are situations in which supporting multiple mirage clusters is the best solution. These include when data privacy regulations require data to be kept in specific countries or regions, when wide area network bandwidth is insufficient to support Mirage operations, and when the customer requires separation of Mirage management responsibilities for different endpoints.
Once the infrastructure is setup we build a functional test plan, which we will use to validate decisions we made when the customer purchased the servers, storage, and infrastructure to support Mirage. Then we extrapolate the data to make sure there will be enough bandwidth, time, and disk space to support the full centralization.
A pilot phase can also help with smaller roll-outs by ensuring resources are utilized as efficiently as possible. Here are the key components of our Mirage pilot.
Average CVD Size
This is the amount of unique data, after deduplication is taken into account, that has to go over the network for an endpoint to be considered “protected” (since Mirage only centralizes data that’s not duplicated on another endpoint). By multiplying the average CVD size by the number of endpoints in an office, we can estimate the amount of data that will need to be centralized from each site.
The next thing we need to know is how much bandwidth is available from each site to transfer that data. That, along with the average CVD size, allows us to calculate the total amount of time for centralization, as well as the amount of network bandwidth required to complete centralization. This helps us determine if expectations need to be reset with the customer and/or if we need to implement some form of Quality of Service (QoS) to rate-limit Mirage traffic over the network so it does not compete with other high-priority traffic.
The average CVD also helps us calculate how much total storage space will be necessary (average CVD size times the number of endpoints that need to be backed up). We also make sure there is sufficient storage array IOPS for Mirage to utilize during the centralization phase.
The early stage of the pilot is also an important opportunity to bring together the various teams that will be affected—server, storage, network, desktop, helpdesk—and start discussions about gathering performance stats from each groups during the pilot to validate the planned architecture. This way we make sure everyone understands how the roll-out will affect their team and what their roles and responsibilities will be. Good communication with these groups is important throughout the pilot to ensure you’re gathering the data needed to help you validate your design or make adjustments when necessary.
After testing the key components during the centralization phase, we work with the customer to build a base layer from which new endpoints will be provisioned. A new endpoint will usually arrive from the manufacturer with a corporate image that’s out of date. When that new endpoint comes onto the network, we add it to the Mirage system, which scans the system, determines which updates are missing, then uses the base layer to send the updates to the new endpoint being provisioned.
This process will also make use of the Branch Reflector, if one is available on the LAN. Branch reflectors are used to reduce the amount of data that needs to be sent to a remote location for base layer provisioning and update operations.
One big advantage of Mirage is that it’s designed to be as hands-off as possible, saving IT time. A great example happened the week after we rolled out the pilot to the customer’s Indianapolis office. An employee’s hard drive failed, and it just happened to be one that was included in the pilot. We were able to restore that endpoint, including all his user applications and data, like nothing ever happened within the day.
We were able to restore that endpoint like nothing ever happened within the day.
Under their old system, it would have taken much longer then a day to get the end users applications and data recovered—assuming they even had a valid backup. Not surprisingly, the customer and the employee were very happy with the results—and we were happy that Mirage clearly proved the value of the system, during the first week of pilot!
This highlights one final benefit of a pilot program: It gives you the opportunity to reiterate the value of the investment and strengthen buy-in even further. So whether you are working on a project involving 2,000, 10,000, or 20,000 endpoints, I recommend starting with a pilot. It will save you time, effort, and money in the long run.
John Kramer is a Consultant for VMware focusing on End-User-Computing (EUC) solutions. He works in the field providing real-world design guidance and hands-on implementation skills for VMware Horizon Mirage, Horizon View, and Horizon Workspace solutions for Fortune 500 businesses, government entities, and academics across the United States and Canada.