In this video we'll look at the architecture and we design an
environment with App Volumes. As a reminder this video is a supplement to
the full content available within the reference architecture available on techzone.vmware.com
Let's start by looking at the components. What makes up an App Volumes environment.
So first thing is we have an app volumes agent which
gets installed onto the virtual desktop or the RDSH server.
It will connect at either boot time or at logon time and connect and talk to the App Volumes Manager.
Now we want more than App Volumes Manager for redundancy and for
scale so we're going to front those with a load balancer. That App Volumes Manager
will integrate into our Active Directory for entitlements but it will
also store information on a SQL database. It will then obviously
communicate with stuff like Virtual Center and optionally vSphere hosts
directly and it will then look at those entitlements understand who's entitled
to what and who's connecting on what desktop and then attach the relevant
appstack volumes and the writable volumes. Now app stack volumes and writable
volumes are really virtual disks with either applications inside or the
ability for users to do and store content such as user installed applications.
But the goal is to get them to attach to the machine with the app volumes agent
When we look at multi-site architecture, the recommended architecture is to
create separate instances and an instance of app volumes is defined by
the database. So a separate instance of app volumes with their own separate
database per site. Now obviously that then presents a couple of challenges
First one, if there's no link between the databases no replication there we need
to get entitlements from site 1 over to site 2. So there are several methods of
doing this. First we would say is use Active Directory groups and reduce down
the overhead of doing this. But we've also got this script and there's a
blog linked here that tells you how to do this. And very very recently we've
released a fling that will replicate entitlements from one place to another
Te other thing we need to think of is how you get those appstacks with my
installed applications in them from site 1 to site 2 or vice versa. So to do this
we're going to use Storage Groups. So in the diagram here I've created two
storage groups, one per site. And a storage group will look at anything
that resides on one disk or data store within the storage group and make sure
then it exists in all the disks within that storage group. Now what we can do is
use a very low cost, something like an NFS datastore, that sits in the middle
As long as one host, one vSphere host, from each site can see that datastore and we
then expand our storage groups to sit in it then anything will go from site 1
to 2 and make its way down to 3. Then we can flag it as
non-detachable so nothing will ever try and attach the
version of the disk that sits on this. Then if we extend over storage group 2
we've now got a way of automatically replicating our appstacks from one site
to another
The other object I drew in the very first slide is writable volumes. And I
think you need to understand when is the right time to use them. They are virtual
disks that we're going to allow users to make changes in and we need to be
conscious of what data might be in there and then how we protect that, how we back
it up. So there is a backup mechanism in the GUI so we can schedule that or
manually do that but it's really going to create a copy the virtual disk onto another
data store. We need to then take that, back it up,
maybe replicate it a second site if we want to provide disaster recovery
Now ultimately what we end up with is a user service that looks like this.
If we're dealing with appstacks and writable volumes we're really looking at an
active/passive service, for that user, from their perspective. And that's down
to really the writable volumes. You notice in the diagram that my appstacks
could be active in both sites. We talked about how you replicate them from site
1 to site 2. We also talked about how you replicate the entitlements to those
appstacks from site 1 to site 2. So they could be active active.
The writable volume though, has user data. It can really only exist in one place at one time
so it would have to be active in one place and possibly replicated and ready at the
point in time in site 2.
For further detail on architecting App Volumes please look at the relevant
sections of the reference architecture document on techzone.vmware.com