The world is rapidly evolving: John sites several recent milestones
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
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment