During my deep dive into the design cues of the desktop processing accelerator for my last blog post on delivery applications, I noticed that redundancy does not seem to be a priority for some customers. In fact, even for large implementations with 2,000+ users, infrastructure components are not always implemented fault tolerance. Therefore, I will write several blog posts dedicated to redundancy in virtual desktop environments. In this first issue, I will focus on the delivery of desktop layer.
Let's take a look at what the accelerator tells us about the redundancy options chosen by customers.
Chart 1 - Number of desktop delivery controllers (XenDesktop Brokers) by site,% of projects
in 17% of accelerator projects, one controller to deliver a desktop is implemented.
Why is this bad?
If there is a failure of this system, users can not connect or re-connect to any virtual desktop (existing sessions are not affected). One could say that there is a workaround to ensure fault tolerance, even with a single controller, activating the HA-mode virtual desktop agent as described in the following article eDocs. But this has two major drawbacks:
- This only works with dedicated desktops, where the correspondence between the user and the Virtual Desktop Agent is known
- users need to be provided with a custom ICA file, which is used when the controller is down. This procedure is not very intuitive and management of hundreds of files ICA is a maintenance nightmare.
Therefore, the best practice is to implement a minimum of two controllers per site XenDesktop, regardless of the size of the environment.
The second point on this matter, I would argue, is the redundancy of the Microsoft SQL database
Figure 2 -. Tolerance level fault for SQL DB, by% of projects
in 33% of all accelerator projects has no fault tolerance been implemented, and in 15% of projects the fault tolerance is low (VM-level HA)
What is the problem here
in XenDesktop, all information is stored on the database.?; The controllers communicate only with the database and not with each other. A controller may be disconnected or turned off without affecting other controllers in the site. However, this means that the database provides a single point of failure. If the database server fails, existing connections to virtual desktops will continue to operate until the user either disconnects or logs out of their virtual desktop; new connections can not be established if the database server is unavailable.
Therefore, our best practice is to implement clustering either SQL or SQL Mirroring, to ensure automatic failover and continuous service. While HA VM level can be considered a fault tolerant solution, one of its major drawbacks is that it starts when the entire SQL server fails (ie blue screen), but not so "right" SQL service fails. Additionally, the SQL service is until the automatic restart of SQL Server is completed. More information about this subject can be found here eDocs - XenDesktop planning HA ..
The next topic and last, I want to emphasize here is saving the SQL database XenDesktop
Chart 3 - backup SQL database, by% of projects
in 12% of the projects of the accelerator, the SQL database are not saved.
Why is this a problem, and do I save my DB if I use SQL clustering?
As previously DB SQL is an essential part of every XenDesktop infrastructure that must be protected and treated with care. While consolidation or SQL data base mirroring helps keeping the service if one server fails, it does not protect against logical errors. So in order to be able to recover if a fix or SQL script damage the contents of the DB, we need a recent backup. Citrix best practice is to do a full backup every day and keep the backup for six months following the Grandfather-Father-Son principle.
Another positive side effect of saving the DB is that it shrinks to zero transaction logs and prevents SQL server running out of disk space. Further information can be found here :. XenDesktop 5 transaction log database Growing Overly
For more information on high availability / fault tolerance of the delivery office layer, please refer to the following guides:
- high availability for XenDesktop
- How to implement high availability in XenDesktop 5
If you are about to launch a XenDesktop project and you want to speed up your decision making process, create a project in the office processing accelerator and benefit from the input of your peers.
0 Komentar