In my second post about errors redundancy I would discuss landmarks peer office processing accelerator - storage Provisioning layer. A major aspect of this layer is the provision of services (WPV) technology, which is used to desktop image delivery by the majority of organizations using the accelerator (as shown below):
(in case you're not familiar with PVS yet, check out our Provisioning services product Overview)
Let's take a look at what the accelerator tells us the redundancy options chosen in the real world implementations.
Chart 1 - Number of Provisioning Servers by site
In 19% of projects, the sites are set work with one PVS server.
Why is this bad?
If there is a failure of this system, all active target devices in this site will stop responding (a popup will be displayed indicating that the system is paused until the connection has been restored). Furthermore, no inactive target can be started. One could say that the target devices could switch to online PVS server to another site in the same farm. Unfortunately this is a common mistake.
PVS has been architected so that a site in a farm represents a data center. Furthermore, it is assumed that there is a low bandwidth WAN connection between the data centers. Since the release of a vDisk is intense enough bandwidth that you want to stream across a WAN connection (although it works technically). Therefore, a site is also a tilt limiting and target devices will never automatically switch sites.
This is why it is highly recommended to implement at least two Provisioning Servers by site and to enable load balancing algorithm (no. Failover if a vDisk is provided by a single server only)
Chart 2 - redundant database
in 31% of projects no fault tolerance has been implemented and in 19% of projects, low fault tolerance (VM-level HA).
What is the problem here?
All of a PVS farm configuration data is stored in the farm database. An active connection to the database is necessary for normal functioning of PVS because PVS servers no information cached locally by default. So if the connection DB is down assets target devices will continue to function, but neither new targets can be started or active targets can be failed over to another server. Also no management function are available.
To mitigate this risk, PVS offers a feature called "Offline Support Database". This option PVS use a snapshot of the database if the connection to the database is lost. This option is disabled by default and is only recommended for use with a stable farm running in production. It is not recommended when running an evaluation environment or when reconfiguring farm components 'on the fly'. However, this option is not a safety net, since the features, options, and the following processes remain unavailable when the database connection is lost, regardless of whether the option Offline Support Database is enabled:
- peripheral targets automatically add
- updates vDisk
- creation vDisk
- Directory active password changes
- Stream Process startup
- update Service image
- management functions; PowerShell, MCLI, SoapServer and console
Therefore, it is best practice to implement either SQL or SQL Mirroring Clustering to ensure automatic failover and continuous service. Although HA VM level can be considered a fault tolerant solution, its major drawback is that it is triggered if the entire SQL server fails (ie blue screen), but if not "just" the 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 in eDocs - Managing high implementations available
. Figure 3 - Backup SQL DB, by% of projects
In 10% of projects, the PVS DB are not saved.
Why is this a problem, and do I save my DB if I use SQL clustering?
As with all Citrix products DB is a vital piece of infrastructure that must be protected and treated with care. Although consolidation or the DB 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, you need to have 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.
If you are about to launch a project for XenDesktop and you want to speed up your decision-making, create a project in the office processing accelerator and benefit from the input of your peers.
0 Komentar