Mar 08 2015

How to Recover Linked Clone Desktops in a DR Site

Disaster Recovery for Horizon View has always been a hot topic. To this date VMware still doesn’t provide an official methodology to protect virtual desktops. Equally, VMware Site Recovery Manager does not support Linked Clone desktops created by Horizon View Composer. Conversely, Full Clone desktops can be protected using native storage replication or vSphere host-based replication.

Nutanix provides native asynchronous and synchronous VM-Centric replication, automatically registering and powering on desktops with the destination vCenter, making them available for use in the recovery site. When the recovery event is over Nutanix applies all VM block changes back to the primary site and re-initiate the workload. The video below I published a while back and demonstrates the workflow with ‘Full Clone’ desktops.

 

Disaster Recovery – Failover and Failback with Nutanix

 

However, most Horizon View deployments are currently using Linked Clones desktops provisioned with View Composer. Linked Clone desktops can be of non-persistent (aka floating) and persistent types. For the non-persistent type no protection to the virtual machine is required and there are multiple ways to enable protection and replication of user data and profiles. Back in 2010 I wrote an article entitled VMware View Disaster Recovery Scenarios & Options and the options available at the time are still pretty much unchanged.

What many administrators realized is that while using Linked Cloning many desktops cannot be simply dismantled, refreshed or recomposed due to user installed applications, files not saved to correct locations, log retention policies etc. Often times I hear administrators telling me they like the Linked Cloning management capabilities, but in practice desktops cannot be destroyed.

To this date I have not seen a solution that will properly backup and replicate Linked Clone desktops with full understanding of View Composer intricacies, including replica disk paths, vmx and datastore paths, internal and non-attached disks, etc.

 

Well, I have been working directly with the ingenious Nutanix engineering team and I am happy to announce that your problems are over. :-)

 

Nutanix 4.1 (GA) has a complete understanding of the Horizon View Composer intricacies and is able to backup/restore and replicate Linked Clone desktops to a recovery site. Additionally, when in recovery mode it is possible to power on those desktops (Nutanix automatically register VMs with vCenter in the recovery site) and make use of them. When the recovery event is over all changes are replicated back to the primary site and life returns to normal.

Desktops are not the only resources needed when in recovery mode; you will also need Connection and Security Servers, Active Directory, SQL or Oracle Databases. All components, if not already available in the recovery site, can be replicated and made available for use. Please note, that DNS name resolution and IP translations for Connection and Security Servers must remain the same to allow desktop agents to communicate properly. For this reason it is suggested use of stretch layer 2 technologies.

 

There are couple guidelines to be observed.

 

  1. Limit Linked Clone desktop pools to a maximum of 50 desktops and ensure desktops are member of a unique Nutanix Consistency Group and Protection Domain. Multiple backup and retention schedules may be created. (Nutanix is working to increase the 50 desktops per PD limitation)
  2. Before executing a ‘planned’ recovery the administrator must disable Horizon View desktop pools to avoid automatic power-on of desktops that may prevent them from being migrated to the recovery site.
  3. When in recovery mode users can access desktops and the Connection Broker is able to execute power operations. However, in recovery mode no View Composer operations such as Refresh and Recompose can be executed. Once the desktops are migrated back to the primary site all operations are once again available.
  4. Nutanix will soon release a best practices guide.

 

Truthfully, it is that simple to provide backup/restore and recovery capabilities to Horizon View Linked Clone or Full Clone desktops with Nutanix.

 

This article was first published by Andre Leibovici (@andreleibovici) at myvirtualcloud.net.

Permanent link to this article: http://myvirtualcloud.net/?p=6948

Mar 02 2015

Linked Clones with Shadow Cloning VS. Full Clones w/ Native VAAI Cloning?

A recent discussion with one of the engineers prompted me to write this article. It’s no secret that one of the most important Nutanix features for VDI deployments is Shadow Clones.

Shadow Clones drastically improves VDI performance and end-user experience. I discussed Shadow Clones in the past. However, before explaining how Shadow Clones work let’s recap how VMware View Linked Clones and XenDesktop MCS work.

 

To deploy linked clone desktops the administrator first creates a Parent virtual machine. After the Parent VM is assigned to the desktop pool or catalog a clone of this VM is created. This clone is called Replica in Horizon View and is used by all desktops as single source for the OS drive; in many cases creating a hot spot on the system.

shadow_clones_explain_04

The Nutanix Shadow Clones allow for distributed caching of a particular disk or VM data, which are in a ‘multi-reader’ scenario. This will work in any scenario, which may be a multi-reader scenario (eg. deployment servers, repositories, etc.).

Data or I/O locality is critical for the highest possible VM performance and a key structure of the Nutanix File System (NDFS). With Shadow Clones the NDFS will monitor disk access trends. When all of the requests are read I/O, the disk, in our case the replica, will be marked as immutable. Once the disk has been marked as immutable the disk will then be cached locally by each Nutanix node making read requests to it. In the background, when that happens every CVM gets the map of where the immutable disk blocks are. If the disk data is local to the node great, if not it will automatically retrieve the data, without relying on the original CVM maintaining the replica disk, thus eliminating any possible service degradation due to multiple access request to the original CVM to copy the data.

This method allows VMs on each node to read the replica disk locally from the Nutanix Extended Cache (SSD and RAM). In the VDI case, this means each node can cache the replica disk and all read requests would be served locally, drastically improving end-user experience.

 

VM data will only be migrated when there is a read I/O request as to not flood the network and allow for efficient cache utilization. In the case where the replica disk is modified the Shadow Clones will be dropped and the process will start over.

Shadow Clones is great with Linked Clones!

 

Nutanix also offers data duplication avoidance mechanism (de-duplication is the marketing term here) using VMware VAAI API and Intelligent cloning techniques where only metadata is operated. Josh Odgers wrote a good article explaining Cloning VMs – Why less (I/O & throughput) is better!

Intelligent clone are much faster because there is no need to duplicate a VM; the intelligent cloning process simply creates pointers back to the original file (which remains Read Only) and only uses I/O & capacity when new data is created. The size of the VM being cloned is irrelevant.

Intelligent Cloning is great with Full Clones!

 

The last concept to understand is the Nutanix In-Memory Performance Block De-Duplication. Nutanix has a de-duplication engine built into the stack that works real-time for data stored in DRAM and Flash.

CC_Pools

Content Cache (Dynamic Read cache)

The Nutanix Content Cache is a de-duplicated read cache that spans both the Nutanix Controller VM memory and SSDs. Upon a read request of data not in the cache the data will be placed in to the single-touch pool of the content cache which completely sits in memory where it will use LRU (Least Recently Used) until it is ejected from the cache. Any subsequent read request will “move” (no data is actually moved, just cache metadata) the data into the memory portion of the multi-touch pool, which consists of both memory and SSD.

From here there are two LRU cycles, one for the in-memory piece upon which eviction will move the data to the SSD section of the multi-touch pool where a new LRU counter is assigned. Any read request for data in the multi-touch pool will cause the data to go to the peak of the multi-touch pool where it will be given a new LRU counter.

Extent Cache (In-memory read cache)

The Extent Cache is an in-memory read cache that is completely in the CVM’s memory. The Extent Cache will store non-fingerprinted extents for containers where fingerprinting and de-dupe is disabled. I wrote a nice article a while back (CBRC-like Functionality For Any VDI Solution with Nutanix) explaining how de-duplicated data blocks help to improve and accelerate user experience in VDI deployments.

 

Analysis and Conclusion

I wrote this introduction to provide a baseline for a simple question – What are the advantages and trade-offs between using Linked Clones with Shadow Cloning VS. Full Clones with native VAAI Cloning?

For the Nutanix stack Native Cloning using VAAI is better than Linked Cloning (even if the latter has the Shadow Clone optimization enabled). In the VAAI case Nutanix is fully aware of the common parent – and doesn’t have to rely on heuristics on when to allow caching of the common parent from multiple nodes. An important point is that Linked Cloning technology was designed to support cloning even if the storage vendor doesn’t have native VAAI support for cloning.

It is generally better to use the native cloning support from the storage array rather than build it as a layer on top. From a performance, change tracking, de-fragmentation and coalescing perspectives it is better to deploy VDI using native Full Clones desktops instead of Linked Clones; for both persistent or non-persistent use cases.

The trade-off is that many organizations use Linked Clones as a way to manage base images and deployments. If you are using this model you may continue to use it, but whenever possible you should prefer the Nutanix native cloning.

 

This article was first published by Andre Leibovici (@andreleibovici) at myvirtualcloud.net.

 

Permanent link to this article: http://myvirtualcloud.net/?p=6937

Mar 02 2015

Call for Action Top vBlog 2015 > United We Scale-Out

Just like other years Eric Siebert is doing an awesome work, spending his own personal time to create the vSphere-Land Top virtualization bloggers List. myvirtualcloud.net (this blog) has finished in 14th place for the last two years, coming down from the 17th and 39th the years before. In all truth, all bloggers are doing an excellent job, using their personal time to contribute and share experiences and challenges with the community.

As the datacenter technology tides are changing I have also changed my blogging content, moving from discussions centered around EUC and evangelizing on Horizon View and vSphere, to a more broad datacenter infrastructure focus on web-scale and scale-out architectures, most specifically focusing Nutanix technologies. However, I have not been shy on few topics of my interested that not necessarily represent the views and opinions of my employer, including:

 

 

Eric Siebert has officially opened the pools for this year’s vSphere-Land Top bloggers List (read his introduction blog here).

 

If you are into Scale-Out Architectures,
If you like EUC,
If you like this blog,
If you like my articles,
If you like Nutanix,
If you like VMware,
Please consider voting for this blog.

So what are you waiting for, head on over and reward the best bloggers for their hard work and dedication by letting them know that you appreciate them.

Click the button below to initiate voting

This article was first published by Andre Leibovici (@andreleibovici) at myvirtualcloud.net.

Permanent link to this article: http://myvirtualcloud.net/?p=6920

Older posts «

» Newer posts