Firstly let me apologise for the shameless plugs I will make, I work as technical presales and as such have a reasonably good knowledge of a small set of products and selling them puts the bread (my friends will know the irony of this statement) on the table. SO my solutions will always be built on theses products.
The fortunate thing about my situation is that the products I sell and use are the best on the market so I have no hesitation in recommending them.
I have been asked several times recently about how to us VMware SRM to protect desktops in a VDI environment.
My answer is always the same. If you need to recover the desktop then you are doing it all wrong. In this post I will go in to how DR of a desktop environment can be achieved in a painless and efficient way.
The key to all this is also the biggest liberator of the desktop environment namely Persistence. To be more precise the lack of it.
When you fully separate the key functions of a desktop you free it from the shackles of persistence and allow it to wander through the world of virtualisation un hindered.
Back to reality. What I mean is a desktop has three main layer (a virtual one leastwise) App and Data, Persona and OS.
In many cases when I talk to customers they are not aware that we have the ability to do things differently in a VDI deployment.
App/Data – Many of todays apps are web based so they have been freed already. Legacy apps can be virtualised, remoted or (in my opinion the best and kindest way) replaced.
Persona – VMware Horizon has built in persona management that allows us to take all that personal customisation and information out of the desktop itself. There are also some excellent third party tools such as ProfileUnity from LiquidWare Labs that will do an excellent job of helping us in our journey to VDI Nirvana.
OS – This is what VDI is here for to deliver the OS and if we are just delivering the OS on a virtual desktop we really start to realise the benefits, namely that we can create or destroy the desktop at will because there is nothing except the s in the VDI image that we care about.
Leveraging VMware Horizon for Desktop DR
Horizon’s VDI component (the software previously known as View) has some built in resilience features that lend themselves to giving us a disaster proof (well resistant so as not to tempt fate) solution.
The connection broker can be part of a group, we can have replicas as part of the base configuration. So at the most basic level we have the resilience we require out of the box.
We have two basic ways to deploy this in a DR scenario :-
Active – Active
In the active-active scenario we will have connection brokers at both sites ( assuming a two site setup) serving requests.
In the event of a failure the working site simply continues to service the requests.
Ok I glossed over the networking, we would need some load balancing in the equation, something like an F5 appliance would do the job and its Horizon savvy. More about this in a later post.
Active – Passive
So less complex (potentially from a network perspective), but just as efficacious. The secondary site is on standby with the desktop pools set up but not enabled. In the event of a failure we enable said pools, do some manual DNS changes and hey presto.
In both these scenarios the users get disconnected from there desktop. When they try and reconnect they simply login and get a new one from the new pool.
Horizon 6 has enhanced these abilities with its Cloud Pod architecture making this DR design just that bit simpler.
Protecting the ‘Other Stuff’
These designs (well overviews) all require that the persistent stuff (stuff is a well know technical term) is replicated and protected. This is where SRM is a very useful tool.
In almost all cases we will need to recover production applications, indeed that’s why we are recovering the desktops, so make these servers part of that recovery.
Identity servers (AD or similar) will usually be protected using the built in mechanisms, this may also be true of Mail, DNS and DHCP but theses can be protected using server recovery mechanisms.