Citrix Provisioning Services 6.1 servers provided virtual desktop deployment and
The decision to implement either physical servers or virtual servers for these components should be based on your specific requirements.
PVS Server Networking
Each PVS server was deployed with 2 NICs, one for management and another for streaming:
• A 1Gbps NIC assigned to the Management VLAN was used for server to server communication
• A 9Gbps NIC assigned to a VDA PXE VLAN was used for streaming network traffic.
The TFTP service was configured to run on this NIC on all PVS servers
Figure 18: PVS Host Network Configuration
Each PVS server was configured for optimum performance for the scale deployed. To support 2K desktops per farm, the following calculations and PVS server network and advanced settings were implemented:
VMs = Ports * Threads
Ports Configured 6910-6960 (50 ports) Threads per Port = 16
Total Threads = 50*16 = 800
Other PVS Server settings configured for improved performance:
Buffers per Thread = 32 Buffers Device Booting = 1000 devices
Remote Concurrent I/O Limit = 24 Transactions
PVS Farm
Each PVS farm was comprised of three servers supporting two Modular Blocks (2020 virtual desktop VMs) per farm or 700-800 streams per PVS server. Each PVS Farm was configured with a shared vDisk store on a dedicated PVS File Server for the vDisk storage.
The below diagram shows the PVS farm structure.
Figure 19: PVS for VDI Farm Structure
The configuration for the PVS farm for each Modular Block as shown on the diagram:
• Site: <Environment Name>
o Servers (each server was configured identically)
Log events to the severs Windows Event Log – Enabled
Stores - <shared storage path>
Options – Active Directory password updates (30 Days) – Enabled
Logging – Logging level was set to “Info”
o vDisk Pool
o vDisk Update Management (not configured) o Device Collection
<Modular Block 1>
<Modular Block 1> – Remote Users
<Modular Block 2>
<Modular Block 2> – Remote Users o Views (not configured)
• Storage
o Shared Storage
Site: <Environment Name>
Servers: Host1, Host2, and Host3 Enabled
Path: <path to shared storage>
• Boot Strap Settings were configured on each PVS server to load balance boot process to all servers in the PVS farm
In this configuration, if one of the PVS farm hosts failed, the remaining PVS servers will still be able to support the 2 Blocks.
There were two vDisks in each PVS farm, one for the Datacenter virtual desktops and one Remote Access virtual desktops with additional configuration.
The configuration for the vDisk for the virtual desktops is as follows:
• vDisk Details
o Name: <image name>
o Size: 40GB
o Mode: Cache on Device Hard Drive
• vDisk settings
• General
o Access mode: Standard Image (multi-device, read-only access) o Cache Type: Cache on device hard drive
o Enable Active Directory machine account password management – Enabled
o Enable streaming of this vDisk – Enabled
• Identification: (default values)
• Auto update: Not configured
PVS XenDesktop Setup Wizard was deployed to create virtual desktop VMs and used a Template from SCVMM to create the virtual desktops VMs. Special registry settings were applied to optimize the VM creation process.
When using the PVS XenDesktop Setup Wizard to deploy the virtual desktops, the following settings were used to reduce the time required:
[HKEY_CURRENT_USER\Software\Citrix\ProvisioningServices\VdiWizard\Max_VM_CREATE_T HREADS_PER_HYPERVISOR] set to “2” (This specifies two VM creations per Hyper-V Host to set only two write operations per Cluster Shared Volume LUN per host)
Sizing Considerations:
• Two PVS servers are required to support two Modular Blocks. The third PVS server should be added to the PVS farm for resiliency.
• A centralized Windows File Share vDisk store should be stored on a shared NetApp iSCSI LUN to allow for best vDisks read performance both during deployment and the boot processes.
Design Considerations:
• The number of servers in the PVS farm is based on the number of VMs that a specific PVS server configuration can support and the number of the VMs the total PVS farm needs to stream, plus one for resiliency, in case of a host failure.
• Having a DNS entry for the Windows file server or storage system hosting the PVS store is a requirement, because an IP address cannot be used to point to a storage location.
• Consider using Windows File Share for shared vDisk store to get the benefit of Windows share caching technology. This will help improve storage performance
• Consider using KMS setting with PVS vDisks if the image contains Microsoft Windows 7 or later and Office 2010 or later, which are activated using Microsoft KMS Volume Licensing method.
PVS File Servers
Each PVS farm was configured with a shared vDisk store configured to connect to a dedicated Windows File Server share, which was a shared NetApp iSCSI LUN. Dedicated PVS File Servers with dedicated iSCSI LUN were configured for each PVS farm to provide the required performance. This reduces storage contention or file locking of the vDisks among the PVS farms.
PVS SQL
The SQL Database should be designed to allow for host redundancy.
User Profile Management
The user accounts were created and organized based on a per-Modular Block design. Profile management was then configured based on that design. This allowed for better overall management of the user accounts and policies associated with those accounts.
Citrix User Profile Manager 4.1 was leveraged for user profiles. Each block was configured with a dedicated network share for profile storage and was placed on a CIFS share located on a NetApp FAS 3240. The user setting for profile management was assigned by Group Policy Objects (GPO), which aligned configurations specific to each modular block. Profiles for this project were configured as follows:
• Desktops without Personal vDisk: Streamed – enable delete cache on logoff
• Desktops with Personal vDisk: Streamed – Disable delete cache on logoff Design Considerations:
• Ensure that the GPO with the UPM .adm file has the appropriate settings.
• For this environment, separate CIFS shares and a separate UPM settings GPO was used for each of the five Modular Blocks.
• Consider validating storage performance and protocol selection for user profiles to match the environment requirements. In the test environment, iSCSI LUNs shared as Windows File Shares were chosen to meet performance requirements.
Multi-Site Infrastructure
Figure 20: Multi-site Infrastructure
The multi-site design with remote access was implemented with the intention of replicating the production environment of an Enterprise-level organization. The organization would have infrastructures comprised of a back-end Datacenter and geographically remote business locations that required access to resources in the Datacenter. We also took providing access for telecommuters into account. This was accomplished by including a Datacenter, two Branch Offices, and a Remote Access entry point for telecommuters.
Branch Offices
Branch offices were designed with segregated LAN and WAN networks. The WAN was created with both routers and firewalls on either side to emulate a production environment. The branch locations leveraged either a Branch Repeater VPX running as a VM on XenServer or a physical Branch repeater 8820 appliance. Both of these branch office types connect to a Branch Repeater VPX appliance set in the central Datacenter.
Remote Access Users
With the increase of mobile work styles and devices used in organizations, remote access users are becoming more commonplace. Using a Netscaler Access Gateway Enterprise Edition, a separate network over a simulated WAN connection linked users to the XenDesktop environment. These connections leveraged an ICA proxy configuration rather