Architecting a Citrix Virtualization solution-Design:Operating System Provisioning design

Lets refresh where we are! We are discussing  about architecting a Citrix environment from Architects perspective. There are 2 parts to it:

  1)    Assessment

  2)    Design

Assessment is further divided into

·   User Community

·   Operating System Delievery

·   Application Delivery

·   Server Virtualization

·   Infrastructure

·   Security and personalization

·   Operation and Support

·   Conceptual Architecture

Design is further divided into

·   Application Delievery design

·   Desktop Delivery design

·   Operating System Provisioning design

·   Virtualization Infrastructure Design

·   Access Design

·   Delivery Optimization

In this blog, we will discuss design of Operating System Provisioning .

In order to properly design an operating system provisioning solution that scales and performs as needed, hardware specifications, high availability options and cache storage must be defined.

Citrix Provisioning Services can deliver a vDisk containing an operating system at startup to an endpoint such as a hosted desktop, blade PC or streamed desktop. The same vDisk can be used across multiple layers of physical and virtual devices, thus allowing a single vDisk to be used for thousands of endpoints, if necessary.

Operating System Provisioning Design Scenario

A Citrix Certified Integration Architect has been given the task of designing a solution for delivering the operating systems to users in a company with two branch offices.

During the assessment, the architect documented the following information:

• There are two offices, one in Pittsburgh, Pennsylvania, USA and one in Rio de Janeiro, Brazil.
• There are 300 users in Pittsburgh and 200 users in Rio de Janeiro.
• All users report to work and log on at 8:00 a.m. in their respective timezones
• A XenApp server farm with a Citrix License server and SQL Server exist at the Pittsburgh site.
• A single Web Interface server is used to provide users with applications. It is a single point of failure. When it fails, users are left without access to their applications until it is brought back online.
• Each user has a 32-bit PC running Windows XP, but a directive has been issued to move all users to Windows 7.
• Antivirus software is installed on all systems.
• Users can currently install software on their systems, but this practice must be eliminated as it causes many problems.
• There are four business units in the company and each business unit accesses a different set of applications through the Web Interface.
• The manager in each business unit must be able to install applications and save their operating system and application customizations.
• Users must have fast, reliable access to their operating system and their applications. This is especially important for the business units that directly interface with customers and the engineers.

An architect can use the information gathered during an assessment and the information in the following topics to assist in designing an operating system provisioning solution.

Provisioning Services Design

Provisioning Services is used to provide the operating system to the users. Designing the Provisioning Services layer requires an understanding of the organizational environment and user locations.

Provisioning Services Operating System

The operating system (32-bit or 64-bit) on the Provisioning Services system can have a profound impact on the capacity of the entire environment. For example, systems running the 64-bit version of Windows Server can support higher amounts of memory, which can be allocated to server subsystems. However, an organization may not have implemented 64-bit servers yet, and all their provisioned servers could be configured with the 32-bit version of Windows Server. In this scenario, servers running Provisioning Services are the exception.

Provisioning Services servers can benefit from the increased system-level allocations. 64-bit systems provide higher physical memory, but they also provide higher kernel memory, which increases the amount of system cache. Any recently accessed blocks of a vDisk are stored initially in the system cache and then in general memory. More vDisk blocks stored in memory allows Provisioning Services to perform more local reads instead of accessing the shared storage. This reduces read times for future access of the same blocks--a common occurrence when hundreds of users are accessing the same vDisk. To take advantage of this increased system cache, vDisks should generally not be stored on CIFS servers.

Capacity Planning

Assessing the right amount of hardware required for the environment is crucial for creating the lowest cost solution while providing acceptable performance for the user. Adding unneeded hardware increases the overall hardware, support and power costs.

Additionally, an architect should take into account the geography of users when determining hardware needed for simultaneous startups. If users are in different time zones and connecting at different times, scalability in the farm can be increased. However, designing for peak demand is recommended. If the Provisioning Services server is not scaling appropriately when virtualized, it might be advisable to host Provisioning Services from a physical server.

Provisioning Services is not designed for streaming to physical devices over WAN connections.

High Availability

High availability (HA) in a Provisioning Services environment refers to a configuration in which at least one server in a site is configured as a backup should the primary server running Provisioning Services fail for any reason. If the connection between a target device and a Provisioning Services server is lost and HA is enabled, the connection will fail over to the secondary server.

High availability is beneficial to an environment containing Provisioning Services because it enables automatic failover to an alternate Provisioning Services server in the event that an active connection is lost. High availability is supported for various storage options such as Local, SAN, NAS and Windows file shares.

Providing High Availability

Providing high availability to the Provisioning Services component of XenDesktop can be accomplished using several different configurations and options. The following table lists options for configuring the vDisk store, with benefits, negatives and general recommendations.

The recommendations in the following table can apply to most, but not all, environments. Architects should consider all data collected during the assessment before creating a design.

  

Option	Benefits	Drawbacks	Recommendations
Local vDisks: using the local hard disk subsystem of Provisioning Services to store vDisks	No additional cost; easy to implement and maintain	vDisks must be manually synchronized between servers running Provisioning Services; I/O performance depends on the capabilities of the hard drive subsystem; does not take advantage of built-in Windows file caching       Local vDisks are not recommended because of increased administrator overhead and potential for failure	Use NIC teaming to increase the reliability and I/O between Provisioning Services servers and the target devices.
Windows Network Share:  using a single Windows network share (CIFS) to store vDisks	Minimal cost; easy to implement and maintain; HA can be enabled for Provisioning Services	No redundancy for file server outages; I/O performance less than NAS, iSCSI or Fibre Channel SAN; limited scalability for additional target devices	Use NIC teaming to increase the reliability and I/O between Provisioning Services servers, file server and the target devices; use dedicated NICs when possible for loading and delivering vDisks to target devices.
Networked Attached Storage (NAS): using a single NAS to store vDisks	Moderate cost; easy to implement and maintain; enhanced reliability; increased scalability for target devices	Higher cost than Windows network share; no redundancy for NAS outages; requires software to manage storage array; I/O performance less than iSCSI or Fibre Channel SAN; RAID arrays require additional configuration	Use NIC teaming to increase the reliability and I/O between Provisioning Services servers, file server and the target devices; use dedicated NICs when possible for loading and delivering vDisks to target devices.
Storage Area Networ    k (SAN) - iSCSI: using a SAN to store vDisks and accessing it with the iSCSI protocol; implements a central vDisks store	Moderate cost; highly reliable; highly scalable	Higher cost than Windows network share or NAS; requires software to manage storage array and to implement an iSCSI SAN; I/O performance less than Fibre Channel SAN        Requires a cluster or parallel file system to ensure integrity of LUNs containing vDisks;	Use NIC teaming to increase the reliability and I/O between Provisioning Services servers, file server and the target devices; use dedicated NICs when possible for loading and delivering vDisks to target devices.
SAN - Fibre Channel: using a SAN to store vDisks and accessing them with a Fibre Channel; implements central vDisks store	Highest levels of performance and reliability; highly scalable	Most expensive solution to purchase, implement and maintain; additional hardware required      Requires a cluster or parallel file system to ensure integrity of LUNs containing vDisks;	Use NIC teaming to increase the reliability and I/O between Provisioning Services servers and the target devices.

For more information, see the CTX119286 "Provisioning Services High Availability Considerations" Knowledge Base article on the www.citrix.com web site.

High Availability Decisions

The following table contains a decision matrix for configuring High Availability in a Provisioning Services implementation. Each solution discussed is rated on a 1 to 5 scale, with 1 representing the least benefit and 5 the most benefit.

The following ratings can apply to most, but not all, environments. Architects and organizations should fully evaluate each potential solution before making a decision during the design phase.

    

	Cost	Ease of Use	Performance	Reliability	Scalability
Local vDisks	5	4	3	3	2
Windows File Share	4	5	2	1	1
NAS	3	3	3	3	3
iSCSI SAN	2	2	4	5	5
Fibre Channel SAN		1	1       5	5	5

Ask the Architect

Does the environment have a large number of sites? If so, several considerations may play a key factor in the high availability design. To find out more, view the "Design a Distributed Provisioning Services Environment" video on the www.citrix.com/tv web site.

vDisk Placement

Placement of the vDisk can impact the functionality and speed of Provisioning Services because each server within the farm must access the appropriate vDisk and stream portions of the vDisk to the target devices as needed. Two options exist for the vDisk storage location:

• Shared storage, which uses an enterprise storage solution to host the vDisk images
• Local storage, which stores the vDisks locally on the Provisioning Services server

Bootstrap Redundancy

In a Citrix virtualization environment, the Trivial File Transfer Protocol (TFTP) service is used to deliver the Provisioning Services bootstrap. The bootstrap file contains a list of as many as four available Provisioning Services servers that it can contact in order to boot as well as various configuration settings. The name of the bootstrap file and location is delivered by the DHCP server upon request by the target devices through DHCP options 66 (Boot Server Host Name) and 67 (Bootfile Name).

For more information on bootstrap redundancy, see Citrix Knowledge Base article CTX120760.

Redundancy Options

 

TFTP Servers

Because of current limitations regarding how the NetScaler system load balances TFTP servers, the NetScaler MIP and SNIP addresses are set as the default gateway on the TFTP servers. Therefore, all communication between the TFTP servers and the TFTP clients are handled by the NetScaler system, and stand alone TFTP servers must be used instead of the built-in TFTP service on a Provisioning Services server.

For more information on TFTP servers, see Citrix Knowledge Base article CTX116337.

Device Collections

In a Citrix virtualization environment containing Provisioning Services, administrators can group target devices into different folders called device collections. With hundreds or thousands of devices existing in some environments, device collections are useful because they help organize the defined target devices by purpose, role and configuration.

Initially, a single vDisk may be used for several groups of users across different business units. However, additional target device settings may be required based on future business and technical needs. The recommended process for configuring device collections includes the following steps:

1. Create a device collection for each business unit.
2. Create a template target device within each device collection.
3. Configure the template target device with the appropriate class, vDisk assignment and personalization settings.
4. Set the template target device for the device collection.

Setting a template for the collection will make all other target devices within the collection take on the same parameters and settings, helping to guarantee consistency within the business unit.

File Caching

Provisioning Services acts like a network switch. All traffic between the vDisk and the Provisioning Services client passes through Provisioning Services regardless of where the vDisk resides.

The operating system offers file caching and can improve vDisk deployment efficiency by caching file read data at the block-level. However, if a single target device is booted from a shared vDisk, then subsequent clients do not require disk read I/O to perform a similar operation. The operating system caching mechanism only caches the blocks that were accessed, not the whole vDisk file. The file read data stays in the cache until it is forced to make space for other data. Therefore, if the Provisioning Services server is optimized for file caching and has the largest vDisk cache possible, then streaming the vDisk is faster because it does not come from the disk (HDD) and is instead accessed from the cache (RAM).

Hosting Provisioning Services on a Windows 2008 server allows for greater file cache because operating system limitations have been significantly increased between Windows 2008 and 2003. By using Windows Server 2008 and allocating additional RAM to the server, more of the vDisk file can reside within the cache, optimizing vDisk delivery.

Network Optimization

Provisioning Services should be optimized with several different configurations. General recommendations include:

• Disable Large Send Offload
• Disable Checksum Offloading on Network Adapter
• Disable Spanning Tree or Enable PortFast
• Maximize the System Cache

Additional information on these optimizations is located in the CVE-400 Engineering a Citrix Virtualization Solution course, Module 5: Provisioning Services Integration.

Other network recommendations for optimizing the server hosting Provisioning Services include the following:

• Ensure the network is at least 1Gb. 1Gb NICs should be used to ensure enough bandwidth.
• Use logical locations. Because significant traffic exists between Provisioning Services and the XenDesktop hosting infrastructure, such as XenServer, it is best practice to locate these components logically near to each other to limit the number of hops required. This is mandatory in a WAN scenario.

From the Architect

Provisioning Services network drivers and stack are unique and do not function properly with every type of NIC. This is why the architect should ensure that the network is optimized.

Provisioning Services Database

Microsoft SQL Server is the only supported configuration database for Provisioning Services.

Provisioning Services (version 5.1 or later) contains an Offline Database Support option, which allows Provisioning Services to use a snapshot of the configuration database in the event that connection to the database is lost. The option is disabled by default, but recommended for use in a production environment. Offline database support can only be enabled by farm administrators and is not recommended for evaluation environments or during unplanned farm configurations to ensure proper database connectivity.

If database connection is lost, regardless of whether Offline Database Support is enabled, the following items remain unavailable:

• Auto Add target devices
• User groups
• Auto Update or Incremental vDisk updates
• vDisk creation
• Active Directory password changes
• Stream Process setup

For more information on configuring SQL server, see Citrix Knowledge Base article CTX114501 and Microsoft TechNet article 190202.

vDisk Type

Provisioning Services contains three options for vDisk type: private, standard and differential. The following table identifies each vDisk type has benefits and its drawbacks in a Citrix virtualization environment containing XenDesktop:

vDisk Type	Benefits	Drawbacks
Private Image: each target device has its own vDisk. The vDisk is configured with read/write permissions and all changes are stored within the vDisk for future use.	User has full personalization of the environment because all changes are stored.	Cost of storage and support is increased. Each vDisk takes on a completely different personality based on user behavior, complicating the support effort. Private images can require large amounts of disk space.
Standard Image: several devices share the same base vDisk image. The disk is read-only and target device changes are stored in a write cache file. Upon reboot, the write cache is destroyed, resulting in the target device starting with the same base image each time. Standard images are recommended.	Server reverts to a consistent, optimized and approved state after each reboot. Storage requirements are reduced.	User-installed applications are not retained, resulting in potential user frustration. Application or system-level automatic updates will start after each reboot unless functionality is disabled at the operating system and application level.
Differential Image: several devices share the same base vDisk image. The vDisk is read-only and the target device changes are stored in a differential cache file. Upon reboot, the differential cache is kept and reused by the device after reboot.      Differential images are not recommended.	User has greater levels of system personalization because changes are not discarded after reboot.	Once the base vDisk is modified, the differential image is destroyed and the user must rebuild their personalizations into the target device, which can cause confusion.      This is a major drawback.

vDisk Design Considerations

Design considerations when choosing the vDisk type include the following items:

• For the majority of XenDesktop use cases, a standard image is recommended. Standard images simplify maintenance and support of the images as well as use the least amount of disk space.
• A proper application analysis is critical for identifying all required applications.
• It is recommended to have a process in place to allow users the ability to request new applications for their environment.
• Even though a standard image is recommended for the majority of XenDesktop users, some users will need a private image. Private image users are usually a small subset of all users who have unique and changing requirements. For these users, it can be easier to create private images with the understanding that maintenance of their image will require extra time.
• When considering fixed or dynamic images (.VHD files), be aware that fixed images require more storage space and dynamic images can result in performance overhead.

Write-Cache Placement

When designing a Provisioning Services environment, architects must plan for the placement of write caches. Write-cache placement is important because the size could affect server and target device performance, scalability and overall cost.

Using a standard (read-only) vDisk image allows many desktops or servers to utilize the same vDisk image at the same time. Because the vDisk is read-only, a record of the changes between target device reboots are stored in the write cache. Each target device has its own write cache. Depending on target device activity and the environment, the write cache could grow to a large size. For example, the types of applications used, user workflow and reboot frequency could all impact the size of the write cache.

Organizations should perform an analysis to determine the expected cache file size in their environment before implementing a solution. In a pilot or proof of concept environment, configure the write cache for placement on the Provisioning Services server and ask several different types of users to work on their provisioned desktops. After several days of heavy use, look at the size of each of the cache files on the Provisioning Services server, which will provide a rough estimate of how large the cache files can grow in the production environment. Scalability testing is also recommended to determine the number of target devices that can be supported by a single Provisioning Services server.

A write cache can be placed on the target device RAM, target device local storage, target device shared storage, Provisioning Services local storage or Provisioning Services shared storage. Architects should consider that write caches located on a Provisioning Services server that experiences failure will be lost. Therefore, write caches should generally be placed on the target device or on shared storage.

Write-Cache Placement Design

Design considerations and recommendations for write-cache placement include the following:

• In an environment containing virtual desktops, the write-cache should be fast, giving users a local desktop feel in a virtual desktop.
• The write-cache solution must be dynamic to accommodate a wide range of possibilities, given the different needs of users, especially in a virtual desktop environment.
• Write-cache placement should not affect the high availability options designed to protect virtual desktop users from disruptions.

Virtual desktops delivered with Provisioning Services are best suited for target device shared storage. This storage option frees up Provisioning Services by not having to process write requests and does not limit the RAM of the target device.

• In an enterprise deployment, storing the write-cache locally on the Provisioning Services server is not recommended, as it reduces scalability.
• Using RAM cache is not recommended. RAM is expensive and can be better utilized elsewhere.
• Provisioned workstations should be restarted frequently--daily if possible.

A graceful shutdown or restart is required to clear the cache file. Turning off the machine or forcing a shutdown does not delete the cache file. XenDesktop allows configuration of logoff behavior so the process can be automated.