Monday, February 10, 2014
VMware Horizon Mirage: Endpoint Protection and Disaster Recovery; Presented by John Dodge, Stephane Asselin and Shlomo Wygodny
Rumour has it that during the final stages of the agreement with VMware, the owner of Wanova lost his laptop. Normally this would have been catastrophic given the circumstances. In a perfect example of eating their own dog food, Wanova was able to restore his laptop with everything intact in less than an hour using the Mirage System Recovery option.
Mirage System Recovery is smart enough to bring down key pieces to get the user up and running quickly while all the data continues to trickle down. This minimal configuration is referred to as "the minimum working set" required to get the system funtional.
With Mirage the System Recovery Scenario looks as follows
1) Install Mirage (that is if the IT group has not supplied a laptop with Mirage installed)
2) Assign Central Virtual Desktop Image and have the Mirage agent pull down the pieces.
3) The desktop reboots to the new working set to complete the process
In addition Mirage can also be used to initiate a Desktop Repair. To provide an example let's look at the recovery of files.
1) User installs an app that wipes My Documents
2) The system administrator restores snapshot from the central console "No troubleshooting required" (Note: it is important to note that only the files that have changed are sent as a comparison is always done first to identify the deltas before sending the files.)
There are three options to repairing endpoints in Mirage.
1) Restore Snapshot - repair using good files and settings from Snapshot
2) Enforce Base Layer - the mirage agent roles back any changes to the standard base layer within the Central Virtual Desktop.
3) A bare metal option which allows a small Windows 7 image which has the Mirage agent to be booted from a USB drive or PXE booted from the network to pull down the assigned Central Virtual Desktop (CVD) from the datacenter to the endpoint.
In some cases the Disaster Recovery value that Mirage brings is core to a customers decision to integrating the technology.
- Posted using BlogPress from my iPad
VMware Horizon Mirage Design, John Dodge, Stephane Asselin and Shlomo Wygodny
1) 2010 the year the non windows applications exceeded windows application driven by the smart phone and tablet market.
2) There are 250 million dropbox users world wide.
3) 52% of employees carry more than one device
VMware's new End-User Computing Vision is: "Software Defined Workspace at the Speed of Life"
VMware's strategy is to plan for the convergence of traditional Windows Management and Delivery, Windows on Mobile and Mobile Management and Delivery in general. In addition EUC is extending to the machine space; for example the Tesla is a smart phone you can drive. John provides the example of Tesla changing the software in order disable a certain feature related to suspension.
John mentions that AirWatch was VMware's largest acquisition to date. VMware now finds itself in the leading quadrant of mobile.
Conversations shifts to Mirage: Mirage provides several capabilities and operates on the notion of layers. Fundamentally there is an IT management layer involving the Base, Application and Driver layers. The other layer can be though of as the user layer such as the Machine identify, user profile and non IT installed applications. Typically the IT management layer is the layer that gets pushed, the user layer gets pulled.
Typically in the datacenter you have a cluster of stateless mirage servers that are load balanced. Mirage supports NAS and DASD however a production implementation requires NAS.
All the administrative work happens through the Mirage console. Mirage is flexible and allows delivery of applications through a mirage layer, SCCM or App-V for example.
Mirage Server runs on Windows Server 2008 R2 and requires a database which is a required component.
Mirage Client is a lightweight client which can be silently installed. Mirage will make use of the VSS so requires 10 GB locally for the installation; 5 GB for the install and additional space to download an initial image for example. Mirage will throttle transfers based on how active the user is on the endpoint. In the next release you will be able to turn the user throttling capability off however you should be aware that it will impact user activity.
1) There is a Max. 1500 Endpoints per server physical or virtual
2) Max 20,000 Central Virtual Desktops (CVD) per Mirage Cluster
3) Deploy N+1 Mirage Servers to avoid single points of failure
4) VMware recommends Two gigabit Ethernet on the server
Replication in a typical environment is estimated 15 kbps per endpoint and approx. 150 MB per 24 hour period. This will vary considerably from client to client.
Behind the scenes Mirage Storage is a Single Instance Store in which:
1) Mirage stores CVDs, 1000 per volume is VMware's guideline
2) File and binary (chunks) are de-duped depending on file type (Mirage is smart enough to understand database files for examples)
Each Mirage server has a Local Cache which caches endpoint synchronization data. Typically there is one per Mirage Server and 100 GB of space is recommended. This cache is dedicated per server however it only benefits data which is uploaded.
On an End User PC the following layers can fall under Mirage Management
1) User Personalization Layer
2) Machine Identity Layer
3) Mirage Application layer
4) Base Layer
5) Driver Library
All this layering is done using native Windows APIs.
When deploying Mirage, the first step in the process is to build a reference machine. To do this you would add an agent, create a good base image and then centralize it. You would put everything you expect to but in a single base layer. Traditionally this is the most static parts of the desktop image. This image is then replicated up to the datacenter.
Once we have this image we create a Base Layer by applying Base Layer Rules. Once we have applied the Base Layer rules it is considered a CVD. Once we have this we can assign or deploy the base layer to our endpoints. The easiest way to distribute this base layer is to have clean endpoints.
To distribute the base layer you create Mirage groups. You can create a dynamic group by adding rules based on naming conventions for example "vdi". Every endpoint that boots with a vanilla OS and the Mirage Agent and the acronym in the name will join this collection and receive the CVD.
Before Mirage sends any data the endpoint is analyze to ensure only the delta is sent. Mirage intelligently merges Base Layer changes into the End Point using native Windows native API. To the OS it feels like an application installation. These changes can be stacked to schedule the reboot to happen on a monthly basis.
Most endpoints today have disk encryption; as Mirage works from within the OS, Mirage does not notice the encryption unless a Windows XP to 7 Upgrade is attempted. In some cases you may have to decrypt before the upgrade however Mirage has worked with many mainstream encryption software to provide full support in addition to Microsoft Endpoint Encryption Software.
Creating Application Layers is very flexible and allows you to combine applications in a single layer or have a single application layer per application. If you create a single layer then you are testing all these interdependencies. Mirage Application layers do not provide application virtualization so to the OS the application(s) are natively installed. You can combine ThinApp and Mirage Layers to get the best of both worlds.
A Driver library is used to enable a single base layer which can be applied on multiple physical devices. Drivers are combined with the base layer to deal with different vendor desktops; HP, Dell etc.
One common use case for Mirage is for a Windows XP to 7 Migration. The first phase of this process is to push the base layer components down to the XP endpoint. Before the migration is done an optional pre-deployment snapshot is done to provide a fallback point in case. This snapshot is stored on the Mirage Server. Once that is done a reboot is done which is referred to as a "pivot". What is being done is the swapping out of the XP files with the Windows 7 OS files in addition to joining the desktop to the domain to complete the migration. The benefit of this approach is that an in-place migration is done and the end user impact is minimized. While times will vary a typical migration can take from 30 - 50 minutes.
Great information today from @VirtualStef and the team
- Posted using BlogPress from my iPad
- Posted using BlogPress from my iPad
Monday, January 27, 2014
The benefit of infrastructure innovation to VMware Horizon View
Virtual Desktops are expensive to deploy from a storage perspective. With the advancements in deduplication technology the footprint of a virtual desktop deployment on storage has been dramatically reduced. The issue is no longer the cost of ‘space’ alone. Deduplication removes the ‘like’ blocks and stores just one copy and references the dependent data to reduce the amount stored. In a virtual desktop environment that consists of 100s if not 1000s of copies of a Windows desktop operating system the consolidation of storage is very high. However, the IO required for a single VM can also be high; in production VMs have been observed to require 25 – 100 IOPs per virtual desktop. While the storage footprint is small the performance requirement is extremely high. The performance footprint of a virtual desktop environment can vastly exceed the performance demanded of all but a very few high performance high demand enterprise software solutions such as Oracle, SQL and large Microsoft Exchange environments.
View Storage Accelerator
VMware has introduced several technologies that increase performance while reducing cost. VMware implemented View Storage Acceleration (VSA) which is a form of local host caching. When a virtual machine is deployed a digest file is created which references the most common blocks of the VMs operating system. In operation the digest file is used to pull the requested blocks into memory on the ESXi host. This reduces the read requests that are serviced by the storage system by introducing a host based cache.
vSphere Flash Read Cache
vSphere 5.5 introduced the capability of pooling locally installed SSDs on the vSphere hosts into a logical cache accelerator that all read intensive VMs can benefit from. The vSphere Flash Read Cache aggregates all read requests so that they are cached locally on an SSD drive vs. in memory as is the case with VSA. This creates a separate caching layer across all hosts (provided they have local SSDs installed) to accelerate performance. While not specifically designed for virtual desktop environments, it will enhance any read activity across the virtual desktop compute cluster.
View Composer, Stateless Desktops and Storage Reclaim
VMware Horizon View enables the deployment of a stateless desktop. A stateless desktop essentially redirects the writes so that the majority of the desktop is read only. A stateless desktop is a much cheaper desktop to deliver and manage operationally. This is because it is not customized to an individual user and makes use of View Composer linked clone technology. Composer enables a large number of desktops to use very little space. The decoupling between the user and desktop and use of Composer allows more flexible deployment options. Stateless desktops can make use of local Solid State Drives on the ESXi host to deploy the OS disk of the VM. The benefits have been somewhat difficult to realize though as operationally the OS disk must be recreated to reclaim unused space and reduce the size of the tree.
VMware View 5.3 introduced a reclaim process that allows this to be done automatically and to take place outside production times. This enables a linked clone tree to be deployed for an extensive period of time and reduces the manual operational process of reclaiming space. In a virtual desktop environment the predominant use of stateless desktops dramatically reduces the cost of the solution.
vSAN
VMware has entered the storage virtualization market with the release of VMware vSAN. A vSAN allows the customer to completely segregate the virtual desktop environment onto a SAN that is built using local SSD and Host Hard drives (HHDs) that are collected and presented logically as a single shared storage environment. Segregation or separation of the virtual desktop environment provides the benefit of isolating the View requirements on a distinct set of physical resources so that there is no overlap at the hypervisor or storage levels for production enterprise workloads. The benefits of this approach are many:
1. Predictive hardware performance
2. No risk of virtual desktop performance impacting general Storage performance
3. Scalable, building block approach to deployment
4. Centralized Storage through logical SAN presentation
5. Native vSphere HA enabled through point (4)
6. Reducing the cost of storage while still providing all the benefits of a SAN
The solution is based on Micro Converged Infrastructure in which a physical server with local SSDs and HHDs runs the vSphere ESXi and a storage controller as shown in figure 1. For storage controllers that support pass through, vSAN takes complete control of the SSDs and HHDs attached to the storage controller. RAID0 mode is used for storage controllers that do not support pass through . This essentially creates a single drive RAID0 set using the storage controller which requires you to manually mark the SSDs within vSphere.
Figure 1: vSAN logical diagram
VMware recently announced the bundling of vSAN as part of VMware Horizon Suite. VMware Horizon Suite includes View, Workspace and Mirage and now vSAN as well. The innovation and combination of technologies at the infrastructure layer provide additional value over and above what is incorporated into the VMware Horizon View software delivering compelling value to VMware’s customers.
