Virtualizing Provisioning Server (PVS)?

Technorati Tags: Virtualization,cloud Desktops,cloud computing,VDI

I have deployed environments in which the PVS servers where physical and I have deployed environments where they were virtual, so of course either is a valid approach.  It got me thinking however,when might a physical PVS server be more appropriate than a virtual one?

Virtual Desktop Infrastructure (VDI) creates hotspots on your SAN infrastructure if you are not careful.  This is quite easy to do if you focus to much on space and not enough on throughput.  For example; you may not need a lot of drives in order to provide space for your virtual desktops because a single drive has high storage capacity.  This is especially true if you are using PVS server. 

Keep in mind though that in environments that scale, Citrix recommends that the PVS cache is stored on local drives to the desktop.  With virtual desktops  this offloads the caching IO to the LUN storing the virtual machines.  Each drive in a SAN can only provide so much IOPS (Input/Output Operations Per Second) so although the number of drives may meet the storage requirement it may be inadequate for the throughput.  Storage virtualization does deal with this is some respects by aggregating the underlying spindles but it  limits visibility.

If you have not properly planned and designed your environment “you may be putting to many eggs (or vms) in your (LUN) basket”. 

In environments designed for scale, separating the image streaming PVS servers from the virtual cluster will provide better scalability and a better VM to PVS server ratio.  If you are designing your environment to be modular you may want the PVS servers segregated to ensure that the delivery of images can be provided to multiple virtual clusters.   

Even though your physical PVS server will likely still store the vDisks on a SAN attached volume, deploying a physical server with a separate SAN  attached LUN allows you greater visibility and greater flexibility if you need to move it. 

All of this can be configured in virtual hardware (using Pass through LUNs) however it stands to reason that if you are going to scale the PVS server to 1000’s of desktops you may not want the network paths, I/O and Storage paths to be shared within the virtual desktop infrastructure.  In addition you have the option of redirecting the PVS cache to solid state drives on the PVS server if it is physical.

While either approach is valid, the decision on when the PVS server should be physical is related to scale.  This is not an absolute though, as we know that virtualizing provides better linear scale than an application installed natively on a server.  It is also a question of control and visibility on the load that is generated on the PVS server.  The last factor is the assurance of performance by not forcing the PVS server to share network and storage paths with the virtual desktop instances.

A Layer 2 Cloud

I attended an interesting datacenter design course which opened my eyes to what might be possible with cloud computing. It was based around redesigning the datacenter and allowing Layer 2 network traffic further up the network stack in order to build a datacenter based on virtualization. Essentially designing a datacenter for virtualization vs. incorporating virtualization into a datacenter.

It is typical that a datacenter has three network layers; access, edge and core switching and routing. This ensures that traffic engineering is applied before our data is sent over our long haul networks. Layer 2 traffic is often restricted to access switches and unlikely to proliferate to the edge or core tiers. Core virtualization technologies however are Layer 2; VMotion for example.

A datacenter designed for virtualization allow Layer 2 much further up the traditional network stack and also flattens the old 3 tier system using embedded virtualization in the switches and routers. Consider multiple physical switches being combined to form a single logical switch or multiple virtual routers inside a single physical router. The traditional tiered network architecture approach is leveled in favour of flexibility, speed and to deliver core virtualization technologies across broader distances.

A lot of the difficulty in integrating Cloud services has to-do with a lack of standards at the demarcation points between where the Cloud provider service starts and where internal IT organizations end. This leads to the mentality of breaking off a portion of your IT environment for the cloud and tethering it back to your organization in some shape or form. But consider if the Cloud provider essentially provided a layer 2 service that allowed you to create a virtual switch that spanned from one end of the country to the other. Now the ability to create storage fabrics and do long distance VMotion become available at a fraction of the cost of architecting the environment internally. A Layer 2 service allows the network engineering to remain under the control of the internal IT organization with less complexity.

The cloud becomes an virtual private circuit that links to either public or private virtual infrastructure. While all this exists currently, it is complex, expensive and not designed with virtualization in mind. Is this that far away? Large players have been developing and acquiring technology to deliver a complete model of x86 virtualization and integrated networking services; Juniper has recently acquired Altor Networks, VMware is pouring development and resources into the vShield product line, CISCO continues to expand its commitment to embedded virtualization.

While the focus is still around virtualizing traditional networking tiers, the blending of network services and x86 virtualization is happening at a dizzying pace. A integrated model may enable a more simplistic way to incorporate Cloud services without the inherit security concerns that limit adoption. It will allow IT organizations to extend their datacenter in a much more seamless way using existing standards rather than the confusing array of options now available.

Setting Up Citrix Profile Manager

In a VDI environment Citrix Profile Manager is installed on the virtual desktop instance.  The installation is simple and straight forward and is a matter of clicking next at the default screens.

 

There are two ways of controlling Profile Manager; through the AD or through local INI files.  The local INI files are not recommended for production so we will run through the installation using the Active Directory template. 

You need to ensure you have setup a share location with the correct permissions for the profiles.  Microsoft recommends the following:

NTFS Permissions for Roaming Profile Parent Folder

User Account	Minimum Permissions Required
Creator Owner	Full Control, Subfolders and Files Only
Administrator	Full Control (Microsoft actually recommends none but it simplifies things if you give admins full control)
Security group of users needing to put data on share	List Folder/Read Data, Create Folders/Append Data - This Folder Only
Everyone	No permissions
Local System	Full Control, This Folder, Subfolders and Files

Share level (SMB) Permissions for Roaming Profile Share

User Account	Minimum Permissions Required
Everyone	No permissions
Security group of users needing to put data on share	Full Control

Once you have the share setup you are ready to import the ADM template.  By default it is copied into the installation directory of the Citrix Profile Manager (within the virtual desktop instance).  From your AD server run the Group Policy Object Manager Console (Note: this console is not  installed by default but can be downloaded from Microsoft). Browse to your XenDesktop OU and create a new GPO Object.

Right click the new GPO Object and select Edit to bring up the Group Policy Object Editor. Browse to the Administrative Templates under Computer Configuration.

Click Add/Remove Templates and browse to the XenDesktop ADM template.

Once you have imported the template you can browse to the Classic Administrator Templates\Citrix\Profile Management. At a minimum to get everything working you will need to configure the following:

1. Enable Profile Management

2. Processed Groups (Your XenDesktop AD Group)

3. Process logons of admins (optional)

4. Path to user store (your profile directory)

There are many other settings you can use to tweak how profiles act in your environment but this base set of steps should get you up in running.