VMware Mirage design and architecture details

Posted by on February 4, 2013 in Mirage, VMware | 2 comments

With VMware purchasing Mirage almost a year ago there is still little information on the use and design of Mirage available. So through working with VMware Mirage and reading documentation I have complied details about how to design a new Mirage environment. As of the time I wrote this post there is limited design details available in the Mirage administration PDF from VMware.

Mirage architecture options:

The Mirage application has a fairly simple architecture compared to many enterprise applications and tools. There are really two main options for designing the Mirage layout. You can either implement a standalone Mirage server or build a Mirage server cluster. You have the options to install the Mirage Management server and console on a separate server or one of the Mirage servers in a small design.

 

Mirage server requirements:

Each Mirage management server that you build will need the following minimum requirements.

  • 16GB of Memory
  • 2 CPU
  • Minimum of 146GB of store (does not include storage for desktop CVD’s)
  • 2 Gigabit Network interfaces

Mirage standalone server:

The simplest install for Mirage would be a standalone Mirage server. This type of design uses a single Windows server to host the mirage functions. It could also host the Mirage console or that could be installed on a separate server or workstation to manage the Mirage install. For this type of install Mirage can use nearly any type of storage that you can connect to from a Windows server. Options listed below. The main drawback in using a single server design is redundancy, if the server is a VM you can rely on vSphere HA for added protection. But this will not protect you from a OS failure. Also you are limited to the number of endpoints that you can server from a single server. The default maximum is 1500 endpoints per Mirage server, this can be lowered if necessary.

  • Direct Attached Storage (DAS).
  • Storage Area Network (SAN) connected through iSCSI or Fiber Channel (FC).
  • Network Attached Storage (NAS) connected through iSCSI, Fiber Channel (FC), or CIFS network share.

 

Mirage clustered server:

To provide a highly available and scalable Mirage design you are able to deploy Mirage serves in a clustered design. The Mirage cluster might not be what some consider a true cluster, the Mirage servers share the Single Instance Storage (SIS) volume(s) that will house your images and backups. But the cluster design requires the Mirage Servers to sit behind a Load Balancer.

Each Mirage Server is capable of supporting up to 1500 CVD’s depending on its resources. If you have a large endpoint environment that is more than 1500 you will need to deploy Mirage in a cluster design. But I consider a cluster deployment design a necessity for any company that will be deploying Mirage as their endpoint management tool. I don’t think you can afford to accept the risk of a single server failure taking down your tool.

Voila_Capture11

 

How much storage do I need?

Earlier in this post I covered the amount of storage that was required for the Mirage server itself and the cache. But how much storage is required for the Single Instance Storage (SIS) that stores the Mirage images and CVD backups of endpoints?

According to the VMware documentation and what is being said publicly by VMware they estimate 10-15GB per endpoint that will be centralized. Now this estimate could be affected by many factors that are unique to your environment, such as the number of parent images you will provide and the amount of unique user data your users have.

Now you may choose to not centralize your users data and profiles with mirage if you already have a method to handle part or all of this. The amount of space required for Mirage to centralize your users could be reduced based on choices here. From what I have seen most endpoints that would be centralized with Mirage typically would not have their users profiles being managed with any 3rd party tool and are most likely just stored on the endpoint.

Another thing to consider is that you do not need to have just one SIS and probably should not. This decision should come down to providing resiliency and choices about distributing your workloads across multiple SIS volumes for performance reasons. Depending on what your underlying storage infrastructure that the SIS volumes will be sitting on this may or may not be an issue for you. But non the less should be considered in your design to make sure you are meeting your requirements and managing risks.

 

What kind of storage do I need?

To make it simple Mirage does not require any type of crazy fast storage. The real challenge here is to balance the need for capacity since you are potentially storing hundreds or maybe thousands of backups from your endpoints. To read more about the types of storage that can be used and some base testing that I did you can read my post on Mirage Storage Requirements.

 

How does Mirage work with remote offices?

A common question about Mirage is how is this going to perform in remote offices? The truth is that it does perform very well in a distributed model. The former Wanova company that created Mirage invested a lot of time and knowledge into making Mirage WAN friendly.

With  that in mind there are some scenarios that you will be pushing large amounts of data and would benefit from a local cache point in the remote location. The most common scenario for this is a OS upgrade, for example a Windows 7 deployment. In this case you are pushing out a new base layer and this is more data than the typical individual endpoint syncs. For each endpoint upgrade they are grabbing the entire base layer.

To make this process faster and less stressful on your WAN, Mirage offers something called a branch reflector. The branch reflector is a local cache point that stores a copy of the layers needed for this type of upgrade. The branch reflector is typically one of the endpoints in the remote location that has enough local storage to house the data needed for this type of upgrade. You are able to configure the reflector to accept local requests from multiple local networks if your remote location has multiple networks locally.

  branch

Interested in other VMware Mirage topics refer to my Mirage Series.

 

About Brian Suhr

Brian is a VCDX5-DCV and a Sr. Tech Marketing Engineer at Nutanix and owner of this website. He is active in the VMware community and helps lead the Chicago VMUG group. Specializing in VDI and Cloud project designs. Awarded VMware vExpert status 6 years for 2016 - 2011. VCP3, VCP5, VCP5-Iaas, VCP-Cloud, VCAP-DTD, VCAP5-DCD, VCAP5-DCA, VCA-DT, VCP5-DT, Cisco UCS Design

2 Comments

  1. Nice article Brian. I have question in regards to Mirage server failure.

    What happens of we implement a single mirage server and it’s down. What is the impact to end users/ mirage clients?

    Cheers!!

    • If you only use a single Mirage server and it goes down, you would not be able to push images to any desktops. Also desktops being managed already by Mirage would continue to try and sync changes.

      I would recommend using at least 2 Mirage servers depending on your deployment size. You can load balance them.

Trackbacks/Pingbacks

  1. VMware Mirage how to series - Virtualization Tips - [...] VMware Mirage use cases Wanova and Mirage history Mirage definitions of features and parts What are main Mirage features …
  2. Horizon Mirage – Failed to authenticate device | Virtually Virtuoso - […] Mirage Design and Architecture Detail - http://www.virtualizetips.com/2013/02/04/vmware-mirage-design-details/ […]

Leave a Reply

%d bloggers like this: