Home > Blogs > VMware Consulting Blog > Tag Archives: Horizon Mirage

Tag Archives: Horizon Mirage

Horizon Mirage 4.4: Game Changer for Mobile Workforce Backup and Recovery

John KramerBy John Kramer, Consultant at VMware

I am excited to share what I think is a game changing feature of the new release of Horizon Mirage: its ability to do remote backup and recovery in the cloud. This provides a huge boost in both ease of use and security of end user data on your corporate endpoints.

Previously, using Mirage off network required some form of VPN access to connect to the Mirage servers in the data center, but new enhancements mean that’s no longer the case. With Horizon Mirage 4.4, VMware introduces the Mirage Edge Gateway. Thanks to collaboration between the Mirage development team, the VMware Light House program, and VMware Professional Services, our behind-the-scenes efforts have brought this new feature to all Mirage customers with this release.

This new feature is something I have been asking product management to consider for a while now, as more and more people no longer use VPN to access corporate resources. It’s a pain to constantly log into VPN—a complaint I’ve heard often in my years supporting sales reps who say that the VPN just gets in the way of getting their jobs done.

How Does It Work?
The Mirage Edge Gateway sits in the DMZ of the enterprise network and allows a Mirage client to securely sync with the Mirage servers in the data center whenever a laptop has an active Internet connection.

Deployment is simple. The diagram below gives you an overview of how to put all the pieces together. Most companies have an external firewall and the Mirage Edge Gateway simply sits in the DMZ and proxies Mirage traffic back to the Mirage Cluster that sits on the corporate network.

Mirage Edge Implementation Architecture

There is one main difference between an on-network and off-network Mirage client connection: when off network, all Mirage traffic is directed to the Mirage Edge Gateway during which time the Mirage client will prompt the end user for credentials.

This added layer of security is based on Active Directory or LDAP credentials and a security token is granted for a specific amount of time that a network administrator determines. This means the end user could be prompted for a password once a week, twice a month, or whatever a security team deems appropriate.

Using a security token means end user credentials are not stored or cached and end users aren’t constantly bombarded with prompts for credentials to accomplish a Mirage sync. (I do recommend a longer timeout value versus a shorter timeout because you want to make sure the endpoints are backed up at the end of the day.)

Mirage on Site with Customers

A few customers recently told me that they have remote workers who rarely or never come into the office. In one particular customer’s case, a third of its workforce is completely mobile—meaning 4000 mobile end points. Before Mirage, those mobile workers said they would rather come into the office than log into the VPN.

This is why the Mirage Edge Gateway is such a genius solution. Not only does the Mirage solution allow remote users to protect the data on their endpoints, but also they don’t need to be at the office or on the VPN for backups to take place.

With the addition of the Mirage Edge gateway, Mirage can completely replace cloud-based backup solutions like CrashPlan, Mozy, and Carbonite, with the benefit of allowing IT to securely control the solution in the corporate data center

Commercial cloud-based backup solutions don’t typically offer the image management and layer management features that are included out of the box with Mirage. Furthermore, while Mirage secures mobile workforce data in your corporate data center, it allows both IT and end users flexibility when they need to recover data. For example end users can recover deleted files or previous versions of files directly from Windows Explorer by right clicking a file or folder.

Mirage Edge in Windows Explorer

 

Mirage also makes a great solution for migrating user data when it comes time for a lease refresh of old endpoints to new hardware. If you’re still running Windows XP, Mirage can help reduce the effort around a Windows 7 migration.

With its remote backup and recovery in the cloud, Mirage means ease of use for remote users and a more secure solution for IT. The only problem now is that those remote users may never head into the office.


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. Read more from John at his blog: www.eucpractice.com

Help Your Mirage Implementation Soar with a Pilot Program

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.

Network Bandwidth

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.

Storage Sizing

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.

Communication

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 MirageHorizon View, and Horizon Workspace solutions for Fortune 500 businesses, government entities, and academics across the United States and Canada.