VMware Horizon Mirage Performance Catcha

It has been some time since my last post.  Have been really busy however I always make a point to at least do a meaningful post a month.  Since VMworld is also round the corner, there will be many updates from all other bloggers around the world.

Recently was doing a Proof of Concept (POC) for Horizon Mirage and was questioned on the time to centralize an end device was too long.

Here's what happen:
A simple centralize of endpoint took as long as 140mins in one setup and 52mins in another which could not have been shorter since the endpoint is plain OS image about 40GB in size.

Setup 1
First setup that took 140mins where the Horizon Mirage Server is a VM on a standalone ESXi server with local disk with two 500GB 7.2RPM SATA disks extended into one datastore.

Setup 2
The Horizon Mirage server was installed on a physical server with 500GB 7.2RPM SATA Disks on Raid 1.  This took 52mins.

Separately, my colleague did a test as well in our office network which is connected via switches and the time taken was never more than 52mins.  This got us into question.
We did a meet up with the customer this time round and find out how the was Mirage Server and the end device connect to the network.  Here is what happen.  The customer has the end device connected on a switch which is daisy chained from a core switch which Horizon Mirage Server is connected on in both setup physical and virtual Horizon Mirage server.

This was applied to both setup.  The results difference was140mins and 52mins between virtual and physical Horizon Mirage server respectively.  Do note in a virtual environment local disk was used.  I have not test if this may be faster in a SAN environment.

From setup 1 and 2, we can see that physical Mirage server seems to be performing much better than a virtual machine.

From the above diagram, you can see that the 1GE core switch bandwidth is shared among 4 x 48 ports switches.  This limit the bandwidth even though Horizon Mirage does duplication and compression, the transfer speed would be greatly affected.  The total time in this setup took 52mins to centralize one device on a physical Mirage server.


Taking Setup 2, we connect the end device directly to the core switch where Horizon Mirage server is connected to and the time to centralize was brought down from 52mins to 44mins.

From the above two setup, duplication in Horizon Mirage is performed making use of CPU cycle and writing to disk may also be affected if the Horizon Mirage server is a VM as there is a hypervisor layer.  This could have added to the longer time from 52mins to 140mins.

There is another portion which was overlooked by many.

Remember during the installation of the Horizon Mirage Server as show below from my previous post on Horizon Mirage Installation:

The path of the network cache folder, which by default points to your Horizon Mirage installation path.  However if this is located on a separate disk e.g. SSD, the performance can greatly improved.  As common data heavily read from this cache.

This works just like a front-end cache on a storage before data is destage to the disk.  For network cache to work, it would be good to centralize a couple of end devices with the same image so that most common blocks will be located in the Network cache drive.

At a later stage when centralizing a end device with similar OS type you would see greater performance improvement since uncommon blocks will only be send and the response of the disk will also be much faster comparing to a shared disk.

Hope this give you a better in sight on the things to look out for when planning for Horizon Mirage setup.

Comments

zahir said…
Great Article Bro!
Unknown said…
Good job bro! your setup & test lab results highlighted considerable facts to help other colleagues before we prepare POC for mirage. I personally thanks for knowing this kinda practical results by reading in few minutes but which you spent a lot of your time and kindly sharing with us.
I also have same opinion here for the
"The path of the network cache folder" if we use SSD or better storage for the network cache path, I also believe that the performance will be definitely improved for sure!

Popular posts from this blog

Why VMware or Why Not after Broadcom?

VMware Certifications Updates

Aria Operations Management Packs End of Life