|
Posted: 1/26/2012
Persistent-versus-Non-persitent-VDI
If you are just starting to get into VDI I think this blog is important
for you to read and understand. If you are experienced with VDI I
would love to get youor feedback on this topic. Often when I talk
to prospective customers this is where I need to start because,
quite frankly, if you are only getting information from the major
VDI
vendors about what architecture you should use to meet your
requirements, you are probably being steered in one direction without
enough emphasis addressing your actual requriements . Often early
discussions are solely on what broker or storage you will use but there
are more fundamental questions than that for what basic architectures
you must be able to support. I wanted to write this blog as a
primer for this discussion and I am hoping to spread awareness of the
differences between the persistenent and non-persistent VDI models so
that organizations looking at VDI or ones that have issues with their
current implementation will understand the alternatives and be able to
architect the right solution for their organization.
One of the most important architectural considerations you will need to
make in VDI is whether to use a persistent, non-persistent or mixed
model for your desktops. If using a persistent model, a user
will be assigned a desktop and they will always use that
desktop. The work they do on "their" desktop is saved on
"their" desktop. This approach pretty much matches the
physical desktop world. A non-persistent desktop is more like
a typing pool. The user connects to the connection broker and
they select a "pool" of desktops. They are then allocated one
of the desktops from the pool which they use during that session.
If they log off, when they return they get a different
desktop from the pool.
Each of these architectures have benefits and drawbacks depending on the
requirements of a particular use case. It is likely that
you will want to use both architectures in your environment
unless you are only implementing for one or two use cases.
Non-Persistent Approach
The non-persistent desktop architecture is marketed heavily
by VMware and Citrix. VMware has their linked clone
technology with View Composer and Citrix uses Provisioning Services with
XenDesktop. This model is excellent for minimizing the
storage usage and manageability of the operating system.
The technologies are slightly different which I will explain
here.
VMware View Composer
In the VMware model you create a gold image called a Parent virtual
machine, take a snapshot of that VM, then deploy
desktops from the snapshot. Composer then creates a replica from the snapshot
(a thin provisioned version of the Parent VM) on each datastore that
you
spread the desktops across. You are able to have a single
replica or multiple replicas but most designs will use multiple to
spread out the IO, and reduce risk by having more redundancy.
Then the desktop is created as a linked clone which is
implemented with a delta disk "linked" to the replica disk. The
delta disk is where all the
change that happens to the desktop are stored. This architecture is illustrated in the
following diagrams. Note, View has several required and optional disks. A disposable
disk can be used to store the page file and temporary windows files.
If used this data is removed after every reboot.
View uses the Internal disk to hold the Windows Active
Directory machine password. This ensures that the desktop
does not lose its domain trust when the desktop is recomposed (the OS update process).
 
There is also an optional "persistent disk". The persistent
disk is assigned a drive letter at the pool level which is normally the
D: drive. Files stored on the persistent disk are not removed
during a recompose or refresh operation. You can also
redirect the windows profiles automatically to the persistent disk.
If we actually look at these files we will see that they are all pretty
small. The next two illustrations show the view of the files
from vCenter and the datastore. File A is the delta disk of the
linked clone where changes are stored. Remember the
underlying OS disk is a read only copy so this is similar to a
snapshot. It will grow substantially over time and if a Recompose is
performed this disk is cleared. The B file is the disposable disk for
the page and temp files. This file is cleared every reboot.
The C file is the user data disk or "persistent disk".
This file is thin provisioned and grows over time.
As an aside isnt it funny VMware marketing changed the name to
the User Data Disk to the Persistent Disk but in the technology it
never changes. The last file D is the internal disk which is very
small and
does not grow.

If you look at the same files on the actual vmfs volume you see that
the vcenter client combines some files together to simplify the view.

So we got pretty deep here in the file structure but it is a good way
to illustrate what you can do with View Composer. You see
that to start with (BTW this is a brand new desktop) the linked clone
uses very little storage above the size of the replica which is not
even shown here. The many caching type files which include
the disposable disk, the delta disk and the persistent disk will all
grow over time and the growth can be substantial. When you
recompose or refresh the desktop the delta disk and disposable disk are
both cleared and lose whatever changes they contained.
Often when I talk to prospective customers they think having the
persistent
disk means that they have a persistent desktop but this is certainly
not the case because files are definitely lost from the "C:" drive on a
recompose action. The profile and files placed on the D:
drive persist but this is not everything as I will discuss
later. Also, remember that on a persistent desktop you and many
software developers expect the computer name, MAC address, volume
serial number, and disk signature to not change and if they do strange
things can happen with applications.
Still View composer is a very elegant solution to managing a shared
non-persistent infrastructure implemented in a simple and
straightforward manner that works reliably.
Citrix Provisioning Services
Citrix also has a method to create space efficient desktops where the
OS image can be managed centrally. Their solution is called
Citrix Provisioning Services (PVS) which is
technology they acquired when they
purchased Ardence at the end of 2006. When this technology
was originally developed we used it to manage images for Citrix
MetaFrame servers. It was a fantastic way to ease image management for large Citrix farms.
The technology is fairly similar to View Composer's linked
clones but it is implemented in a way
that does not requirie SAN storage and it can be used for virtual or
physical desktops.
Like View Composer PVS uses a cache file
to capture the changes to the underlying OS when running in "Standard"
mode. There is also a
"Private" mode which allows you to save changes to a vDisk in the disk
itself. This is normally used to update or change a vDisk.
Generally the way you work with PVS is that you use two vDisk
images for a build. One is in standard mode streaming to the
desktops and you use the other to update for a new revision.
You then have to either keep the two in sync or make clones
each time you want to do an update. Once you update the
image you swap. Frankly for VDI I think this is a bit tedious
compared to other solutions but the ability to use either local storage
or SAN storage is great for us architects. You can even use
local storage in a PVS Farm but you have to keep the local images in sync
or you will have problems.
What about Apps?For
the non-persistent desktop alternatives apps are generally deployed in
one of two ways. Either they are streaming to the desktop or they
are included in the base image. For streaming, organizations
generally use App-V or ThinApp. Of course XenApp can
always be used as well to provide applications to physical and VDI
desktops.
Citrix does have their own application streaming product and
there are several others on the market but ThinApp and App-V are
certainly used the most. Both of these are very good products.
Back in the day at RapidApp we worked with SoftGrid (now App-V)
on most Citrix MetaFrame implementations because it was the best way to
manage applications for a large server farm. With App-V you have
streaming servers that stream virtualized applications to desktops. The
desktop has a client with a large cache. You can either load the
whole application at run time or pre-cache the application out to the
desktops. App-V has a concept of "sequencing" an application where it
figures out the files that are needed first when you run the
application and it streams those down to the desktop first when the
application is launched speeding up launch times significantly.
ThinApp works slightly differently in that they
encapsulate the streaming file into an executable that can be either
run from a file server or copied locally to the desktop and run.
One last thing that's very cool about these products is that they
isolate the applications from each other by default which allows you to
run conflicting applications side by side. One drawback to that
is that if you want applications to integrate with each other you have
to know that in advance and define it in the build. Another
benefit of app streaming is that it provides dynamic assignment of
application to users as they log on. This allows the desktops
to be generic with customization on logon.
On the negative
side,
app streaming technologies have trouble with applications that include
kernel mode drivers, printer drivers or early start services because
they are themselves services and they have to wait for Windows to load,
so they can be loaded and stream down the application. Note this
is not a drawback of XenApp unless of course you want to manage XenApp
with application streaming. What this negative means to
you as an architect is that there are about 15-25% of applications you
will have to build into your base image because you won't be able to
virtualize them. Then, because not all applications will be used
by all desktops you will have to build different images for different
groups that require different applications. What I normally see
is about 1 image for every 100 desktops in an environment. This could
certainly be more or less depending on your requirements. Of
course the problme with this is now you have manage and patch many
images that have lots of overlap in the applications they have
installed.
Good Use Cases
So now we have reviewed the non-persistent model. If I were to
characterize the main benefits and drawbacks to the model I would
define the following:
- Benefits
- Very High
Availability - If a host or storage fails, users can simply logon to
another desktop. There are still parts of the environment that if
they fail, can cause an outage, but it will be rare.
- Good
Manageability - Management of the OS is good. Modification to
central images are deployed to many desktops. If applications are
the same for all, app manageability is also excellent. If apps
must be different, manageability depends on the ability to virtualize
the applications.
- Minimal Storage Footprint - Both Composer and PVS
provide greatly reduced storage requirements. PVS can even be
used with local storage on the PVS servers.
- Fast Deployment of
Simple Apps - Using app streaming applications can be deployed very
quickly to all of the desktops in the environment. However for
apps that are not simple this becomes harder and may require creating
and deploying new OS images.
- Very Fast Deployment of New Desktops - in this model desktops can be deployed very quickly as the OS is already created.
- Simple
Desktop Refresh - to get a desktop back to the standard state you just
reboot it. The desktop is then reset back to its original state.
This is great for student labs, many classroom use cases,
kiosks, and training facilities.
- Drawbacks
- Application Incompatibility
- there will be some percentage of applications
that cannot be delivered with app streaming and a smaller percentage
that will not work at all with the non-persistent model due
to the way they are installed or the way they implement licensing
checks.
- No User Installed Apps - If you need the flexibility of
users installing applications you cannot provide that with the
non-persistent model.
- Image Sprawl - For environments
with different types of users with different application requirements
you will have to build several to many images to provide applications
to the end users. The more images you need the more work it takes
to patch and update the images.
- Issues with User Confidence -
in this architecture I often here about instances where users have
saved files to their C: drive which are lost on a recompose. You
can consider this a training issue but it does point out that
non-persistent desktops may not meet the needs of our users.
So
given the benefits and drawbacks where does it make sense to utilize
this model. I think the most successful implementation of the
non-persistent model is for environments that require the utmost in
availability that are also fairly simple in their application needs.
The classic use case is the large call center. What if I
have 600 - 1000 desktops that all have the same set of applications and
must be available 18 to 24 hours a day. This model is perfect for
that. What about the manufacturing floor or warehouse.
Possibly for retail outlets or small branch offices.
Certainly classrooms, training rooms, and student labs. The real
key I think is that the application are either the same for everyone or
they can be delivered using application streaming. To reiterate
the good use cases in a bullet list:
- Call Center
- Classroom, Student Lab, Training Room
- Library
- Task Worker
- Kiosks
Note:
I want to remind everyone that I do work for Unidesk but I try very
hard to be impartial here. I was an independent consultant for 15
years and I am not really able to change my colors from that
experieince. I believe in telling the truth as a vendor
because if I lie you will find out anyway and we will both be worse off
for it. Anyway, I do want to point out that Unidesk also
provisions non-persistent desktops. I will show how Unidesk works
in the persistent model discussion which is our bread and butter but
remember that you can use us for both.
Persistent Approach
Now we move on to the persistent desktop model. The key to this
model is that it should be the same as a physical desktop based on what
administrators can provide to users. So the ability to make users
administrators if required. The ability to install applications,
printers, toolbars, utilities, whatever.
The most common way
to provide a persistent virtual desktop is to provide a full clone
virtual machine. All virtual desktop brokers provide the
ability to create full clone virtual machines in an automated way.
However, once the machine is created it stands on its own.
The question then becomes how do I manage that desktop. You
could of course use the same technologies you use on physical machines.
For example to manage applications and Operating Systems patching
deploy SCCM, Kace, Landesk, Altirs, etc.
But
what about storage?
Here certainly if you deploy 1000 desktops of Windows 7 and they
each have 25 GB of storage you will be using 25 TB of storage.
Even if this is thin provisioned storage you will likely be
upwards of 15 TB of storage. Remember also, this needs to
be high performance storage not SATA storage. One option
organizations use to lessen this requirement is deduplication.
This can be a good solution but be careful there are risks to
post processing deduplication if you get low on available storage or
overcommit too much and nothing is worse in VDI than running
out of storage.
Citrix Personal vDiskLast year Citrix
bought RingCube to obtain their vDisk technology which allows you to
build persistent desktops and still use PVS. This technology is close
to its first release from Citrix as part of XenDesktop. What the
Personal vDisk does is create one persistent layer on top of the PVS
image for each desktop. In this layer you can allow users to
install application but you could also use SCCM to install applications
here. Users can use local profiles and install applications and
those will be persistent with this technology. That said for most
folks using this architecture will also require multiple base OS images
to deploy different sets of centrally managed departmental applications.
UnideskI
think you will find that Unidesk is a fairly unique product.
Unidesk is not only a persistent desktop model provider but it
allows the flexibility of providing both persistent and non-persistent
desktops using the same OS layers and Application layers. I think
the key to the Unidesk product is flexibility. You will be able
to create a centrally managed virtual desktop solution that allows you
to decide what users are able to do and whether you want to deploy an
application centrally, managed by IT or installed by the user.
The
Unidesk architecture is built around the concept of layers. First
you provision an OS layer by creating a gold image VM and importing
that VM into Unidesk. During the import all the files are copied
from the VM to the Unidesk Master CachePoint. The Master
CachePoint acts as the library for all OS layers and Application
layers. After you have built your OS layer you use it to build
application layers. An application layer is built by creating (an
automated process) an Installation Machine, logging into the machine
and installing the application. Once you have your layers created
you can create desktops from these building blocks. Unidesk desktops
are created with a small boot disk which is used to capture all of the
boot files for Windows. This includes drivers, and early start
service files as well as the pagefile. Anything required prior to
loading the Unidesk Windows drivers. Unidesk desktops boot from
the boot drive then when all the Unidesk drivers are loaded the rest of
the OS is loaded from the CachePoint. The majority of the Windows
OS and all the applications reside on the shared storage provided by
the CachePoint. CachePoints mount storage on vSphere datastores.

Typically
there is one CachePoint deployed per vSphere host and all of the
desktop deployed on that host are deployed to that CachePoint.
The CachePoint will only host an OS or Application layer if one
of its desktops is using that layer. The Master CachePoint is
responsible for distributing the layers to the downstream CachePoints
as necessary when a desktop is configured with the layer.
Most
of the layers are shared amongst desktops. This sharing of layers
provides native dedupe for application files because the layers are
stored on the CachePoint just once for all the desktops that use that
CachePoint. This also helps to keep the most used layer and OS
blocks HOT on hybrid storage which decreases IO latency.
One
layer is not shared on the CachePoints and that is the Desktop
Personalization Layer. This layer is where all the changes happen
for a Unidesk Desktop. Any file or registry setting saved or
changed by a user is stored here. If the file initially is stored
within an App layer or the OS but is written to by the desktop, then
that file is first copied to the Personalization Layer then written to.
Then on the desktop the Unidesk file system filter driver always
looks in the Personalization Layer first to find files and therefore it
will always find the edited version of a file stored there first.
The
key to this architecture for persistent desktops is that the
Personalization layer is never cleared. You can update any layer
underneath this layer but any files or registry settings added to the
personalization layer remain after these updates are applied.
This allows for user installed applications, as well as the use
of local profiles. The idea here is that you get a desktop, it's
always yours, if allowed you can install applications, printers,
network shares, whatever on your desktop and those changes will persist
including updates to the centrally deployed OS's and Applications.
But the system can deploy most applications whether or not they
have kernel drivers, printer drivers or services associated with them.
The key here is flexibility with manageability.
Unidesk Non-PersistentEarlier
I mentioned that Unidesk can also provide non-persistent desktops.
This is done by taking a snapshot of the desktop after Microsoft
mini-setup runs and on logoff or a reboot bringing the machine back to
that snapshot. In many ways the desktop behaves like a persistent
desktop, its name never changes, its MAC and volume serial number also
remain the same so for licensing it looks more like a persistent
desktop with benefits.
Persistent as Non-Persistent One
last thing we should review in the persistent versus non-persistent
discussions that there will be application requirements you may have
that will force you to use persistent desktops even for use cases where
non-persistent would be best. A good example of this is an
application that licenses in a way that requires the license to be
installed on the desktop. This would include licensing to a
computer name, MAC address, or volume serial number on the boot disk.
When you must provide these types of applications but prefer not
to save changes on the desktops you can use mandatory roaming profiles
with a locked down desktop which will clear profile changes on exit
or Unidesk non-persistent desktops which are mostly
persistent except we toss the changes to the desktop on logout or
reboot.
Good Use Cases
What are the good use cases for the persistent model. Again, first
it is good to describe the main benefits and drawbacks of this
model:
- Benefits
- Manageability - This
depends a lot on the chosen provisioning platform. If you use
full clones you need other tools for OS and application
management. If you use Unidesk, management of the OS and
Applications is excellent.
- Availability is good but not
as good as the NP model. Compared to physical desktops it is much
easier to keep users working using virtual desktops which support
VMware HA, and snapshots. If you use Unidesk you get automated
backups, and automated snapshots with repair. Some way to backup
and recover persistent desktops is a requirement because unlike the NP
model they do have important files and applications installed on the
desktop.
- Deployment of any Application - one of the big
advantages of the persistent model is that it supports installation of
any application because persistent desktops work like physical
desktops. Also, it's up to you whether you allow user installed
apps or not just like physical desktops.
- Fast Desktop
Deployment - as with all virtual desktops its very easy and quick to
create a desktop. Normally less than 15 minutes.
- Application
Compatibility - this is where the persistent model
shines. Many applications expect a persistent model. Also,
you will not have driver or service issues with a persistent desktop.
- User Installed Apps - If you need the flexibility of users installing
applications this model provides that in all its versions.
- Drawbacks
- Availability
while good, is not as good as the NP model because users do have a
particular desktop and something can happen to that desktop. The
"something happening" risk can be lowered with a product like
Unidesk which takes periodic snapshots and offers repair or by backing
up the desktops or taking a snapshot prior to a big change. The
snapshot approach is not scalable though.
- High Storage Usage -
If you don't implement a complimentary technology like storage
deduplication or Unidesk you will need a significant storage footprint
for persistent desktops and don't forget they need to be backed up as
well which can also increase secondary the storage you use for backups.
Now
that we have outlined the benefits of the persistent model what are the
good use cases. Here the reality is that, due the flexibility these
desktop give you and the fact that they universally support what you
want to do on the desktop, persistent desktops are good for most use
cases except those that require extremely high availability or those
where you do not ever want files saved from one logon to the next. If I were
to make a list I would probably point out:
- Developers
- Office staff /knowledge workers
- Professional workers like lawyers and writers
- Healthcare workers
- Engineers and Architects (as long as there is no 3D modeling requirement)
- Student Virtual Desktop
One I find particularly interesting is the Student Virtual Desktop.
In this design a student is provided a virtual desktop of their
own when they start school. They are then provided applications
they need for the classes they are taking that semester. They can
access the desktop from their own computer, tablet or any station
around campus. This seems to me like a great way to show students that IT is innovating to make their lives easier.
Putting It All TogetherSo
this is a blog I am supposed to espouse a position and here it is.
Unless you are using VDI for a single use case you will require
the flexibility of providing
both persistent and non-persistent desktops in your environment.
You will have requirements that are best met with both models so
you need to plan for how you will provide both types of virtual
desktops.
I know of companies that have been very successful
using one of the major brokers from VMware, Citrix, Leostream or Quest
along with desktop management applications like SCCM to manage their
persistent desktops. The organizations that have been successful
already use these tools for large numbers of physical desktops so they
are just extending that model to their virtual implementation.
However, they have a significant number of IT resources trained to
work with these tools and normally a whole department dedicated to
them. If you do this with more than say 100 desktops consider
deduplication for your storage otherwise it becomes prohibitively
expensive even if the desktops are thin provisioned.
Lastly
consider an approach based on VDI products made from the ground up for
virtual desktops. Citrix or Unidesk can help you provide an
environment that allows management of persistent and
non-persistent desktops using the same technology. Citrix
XenDesktop with the Personal vDisk and Unidesk with its Composite
Virtualization and CacheCloud environment. I am partial to
Unidesk but I work there. I think it betters Citrix for ease of
use, recoverability, application management, storage reduction, and OS
image management. That said, you should look at both products and
decide which woud be better for your organization.
|
|