In the previous Provisioning Services High Availability Considerations blog, I briefly spoke about using Provisioning Services 5.1 with read-only shared access to a SAN LUN(s). Now I will provide a step-by-step overview of how to implement this feature.

Let's start with pre-requisites that I mentioned in my last blog:

• You need to install Microsoft iSCSI initiator on all Provisioning Services servers that access the SAN.
• Private Image mode is not supported.
• If cache is located on server disk, a separate shared storage location that has read-write access is needed for write cache files.

Steps on the SAN:

You will need to create a volume on the SAN interface front end and then set access type for the volume to read/write, later you will make the volume read-only through NTFS attributes. In my example, I will use NetApp, your case might be different. The storage devices are called iSCSI targets and the clients are called iSCSI initiators.
 
Make sure it is online:

Now we move to the Provisioning Services server:

Initially, you will need to use iSCSI Initiator to login to the SAN volume on only one of the Provisioning Services server while in read/write mode. If you are using Windows Server 2008 the iSCSI software Initiator and components are built into the OS, if using Windows Server 2003 iSCSI software Initiator is available as a download package from the Microsoft website. In my example I am using Windows Server 2008, so I just enabled the service from the Admin tools.

 
Depending on your settings you may get a UAC warning, go ahead and approve. The iSCSI Initiator is our Provisioning Services server; under the general tab you will see the Initiator Name that you will need to provide as "Initiator" to your SAN. 

Go back to your SAN and add the "Initiator Name" to Initiator group:

Back to your Provisioning Services server, from the iSCSI Initiator Properties you need to go to the Discovery tab and add the portal by specifying the IP address to the iSCSI target:
When the LUN first appears on Windows you will have an uninitialized volume, therefore you have to switch it Online and let it get initialized. Next step you need to do is format the volume:Once you formatted the volume and assigned a drive letter/mount point, next step you will copy all the vDisk image files (.vhd) and associated properties files (.pvp) to the volume, no need to copy the Lock files. Before you copy the files, make sure all properties for the vDisks that will reside on the volume are set correctly (including High Availability).
Next step is to make the volume read-only. You can use diskpart.exe, verify the volume number, select it and then set the attribute to read-only. In case you want to verify if it was set correctly you can type "detail volume" and verify that "Read-only" is set to "Yes".

Now you will log off from the volume on that one Provisioning Services server, from the iSCSI Initiator click on "Details" and then" Log off..."

In case you get an error message about the volume being in use, go to Disk Manager and switch that disk Offline.You will log on to the target again and make the volume a persistent target.  You must log off and then re-login to the volume to get NTFS on the server to re-read the volume attributes, so that it will recognize the volume as read-only. Making the volume a persistent target will ensure the volume is accessible when the server reboots: 

Just mount the iSCSI volume on all the other Provisioning Services servers; it is now safe since the volume is set to read-only. Also, in order to facilitate your job, have all servers to mount the volume using the same drive letter or mount point; if not you will need to adjust that from the Provisioning Services Console. You should be all set after creating a store and pointing the Path to the SAN volume and adding the vDisk to the pool. Don't forget if you are using Difference disk mode you must enter a default write cache path for the store that does not point to the read-only SAN volume, this also applies if you are going to use write cache on the PVS server (cache on server disk).

You might be thinking, what if I am using a NetApp array as the back-end storage attached via Fibre Channel? There is no reason why this should not work since the LUN appears as a drive to Windows, so Provisioning Services should have no problem using it. When using Fibre Channel the iSCSI initiator is not required, so vendor specific software for the FC device should be used.

If you want more details about this subject, I encourage you to watch this TechTalk session called:  "Simplifying Implementation of Provisioning Services"

"Elisabeth Teixeira - Principal Engineer - Worldwide Technical Readiness

Follow me on Twitter: http://www.twitter.com/lizteixeira

Follow me in the Blogs: http://community.citrix.com/blogs/citrite/elisabetht

If you're thinking about implementing Provisioning Services (even if you haven't had a chance to look at the new features yet), investing one hour in this TechTalk will save you that much and more during implementation. This TechTalk will help you to understand how simple it is to implement Provisioning Services and in particular how the new features can make your job easier.

Topics below are the basis for an upcoming TechTalk:
• How are the partitions resized when you build a vDisk with multiple physical/logical drives?
• How does the Offline Database Support work? What features would be enabled in case I can't connect to the Provisioning Services database?
• How can I take advantage of the User Assigned Virtual Disks? Does it work with all vDisk modes?
• How do I configure a LUN to be accessed by multiple PVS Servers without using a network share?
• How can I benefit from the Enhanced Logging to verify what is going on behind the scenes and troubleshoot my environment?

Register now for this TechTalk on Thursday, August 27th at 1PM Eastern standard time.

Elisabeth Teixeira - Principal Engineer - Worldwide Technical Readiness

You can follow me at http://twitter.com/lizteixeira
You can read my blogs at http://community.citrix.com/blogs/citrite/elisabetht

Provisioning Services High Availability Considerations - Part 4

In the previous Provisioning Services High Availability Considerations blog, I spoke about placing your vDisks on a Network Attached Storage (NAS). Now I will talk about placing your vDisks on a Storage Area Network (SAN).

Placing your vDisks on a Storage Area Network (SAN) - iSCSI

Using a SAN to store the vDisks and access it by means of the iSCSI protocol provides a reliable way with good performance at a moderate cost to purchase, implement and maintain. This solution will provide highest levels of reliability.

What should we consider with this solution?

• Requires software to manage the storage array.
• iSCSI Initiator and MultiPath software must be installed and configured on each PVS; iSCSI Target software must be installed and configured on the File Server(s).
• A Cluster or Parallel File System is required to ensure the integrity of the partition/LUN containing the vDisks.
• I/O for vDisk input (loading from the share) and vDisk output (delivering to the Targed Devices) is handled by the same network link.

What are the recommendations?

• NIC - teaming should be used to increase the reliability and the I/O between the Provisioning Servers, File Server and Target Devices.

Dedicated NIC - teams should be used for loading the vDisks and for delivering the vDisks to the Target Devices.

Placing your vDisks on a Storage Area Network (SAN) - Fibre Channel

Using a SAN to store the vDisks and access it by means of Fibre Channel provides a very reliable way with the highest levels of performance and reliability at highest cost. This solution will provide high degree of scalability to support increasing number of Target Devices.

What should we consider with this solution?

• Additional Hardware (HBAs) required for every Provisioning Server.
• Requires software to manage the storage array.
• A Cluster or Parallel File System is required to ensure the integrity of the partition/LUN containing the vDisks.

What are the recommendations?  NIC - teaming should be used to increase the reliability and to I/O between the PVS Servers and the Target Devices.

Normally using a SAN for vDisk storage with Provisioning Services requires that a shared file system be placed in front of the SAN to coordinate multiple server access to the NTFS formatted LUN(s).  Using Provisioning Services 5.1 you can use a SAN without a shared file system in some instances (you can have "read-only" vDisk storage). The desired boot modes for PVS target devices are important when using this feature since Provisioning Services only allows read-only shared access to the SAN LUN(s). Let's see what are the main considerations when using this new feature:

• You need to install Microsoft iSCSI initiator on all PVS servers that access the SAN.
• It is only for Standard Image mode, Private Image mode is not supported.
• If cache is located on server disk, a separate shared storage location that has read-write access is needed for write cache files.

I encourage you to attend this TechTalk session called:  "Simplifying Implementation of Provisioning Services"

Hope to see you there on Thursday, August 27, 2009 at 1:00PM eastern time.

Elisabeth Teixeira - Principal Engineer - Worldwide Technical Readiness
Follow me on Twitter: http://www.twitter.com/lizteixeira
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/elisabetht

Provisioning Services High Availability Considerations - Part 3

In the previous Provisioning Services High Availability Considerations blog, I spoke about placing your vDisks on a Windows Network Share (CIFS). Now I will talk about placing your vDisks on a Network Attached Storage (NAS).

Placing your vDisks on a Network Attached Storage (NAS)

Using a single Network Attached Storage (NAS) to store the vDisks is an easy way of implementing a central vDisk store at moderate cost. This solution will enhanced reliability and give you a greater degree of scalability to support an increasing number of Target Devices.

What should we consider with this solution?

• No redundancy for NAS outages (all PVS Target Devices stop responding).
• Requires software to manage the storage array. RAID arrays must be configured on the storage array and assigned to each PVS Server.
• I/O for vDisk input (loading from the share) and vDisk output (delivering to the Targed Devices) is handled by the same network link. This affects the overall performance of the solution.

What are the recommendations?

• Network Interface Card (NIC) - Teaming should be used to increase the reliability and the I/O between PVS Servers, File Server and Target Devices.
• Where feasible dedicated NICs should be used for loading the vDisks and for delivering the vDisks to the Target Devices.
  
  
  
  Elisabeth Teixeira. Follow me on Twitter:http://twitter.com/lizteixeira

In the previous Provisioning Services High Availability Considerations blog, I spoke about placing your vDisks Local on the Provisioning Server. Now I will talk about placing your vDisks on a Windows Network Share.

Placing your vDisks on a Windows Network Share (CIFS)

Using a single Windows Network share (CIFS) to store the vDisks is a very easy way of implementing a central vDisk store at minimal cost.

What should we consider with this solution?

• There is no redundancy for file server outages (all PVS Target Devices stop responding).
• Limited scalability to support a increasing number of Target Devices.
• I/O for vDisk input (loading from the share) and vDisk output (delivering to the Targed Devices) is handled by the same network link. This affects the overall performance of the solution.

What are the recommendations?

• Network Interface Card (NIC) - Teaming should be used to increase the reliability and the I/O between PVS Servers, File Server and Target Devices.
• Where feasible dedicated NICs should be used for loading the vDisks and for delivering the vDisks to the Target Devices.
  

The following diagram outlines a basic Provisioning Services + Windows File Share (CIFS) architecture:

Elisabeth Teixeira.

Follow me on Twitter:http://twitter.com/lizteixeira

I have been working with Provisioning Services (PVS) for a while and one of the questions that keep coming up is around Provisioning Services High Availability (HA).

What is HA? Maintaining access to a service or resource is probably the best explanation for this type of functionality.

What does HA provide? Within the context of the Provisioning Services resource, we are referring to the target devices ability to maintain an active connection to a vDisk. This is different to redundancy, which I will cover in another topic. This ability manifests itself in the customers' expectation for the target device to maintain constant uptime. What we have seen in the latest release is instant availability (first error move to next PVS server providing vDisk) as opposed to failover if the system doesn't recover itself.

Types of HA: There are many ways of doing it, they all work, but which one is right for you? That depends. Let's take a look at the location of your vDisks.

Placing your vDisks Local on the Provisioning Server - "Distributed Store":

Using the local hard disk subsystem of the Provisioning Server to store the vDisks provides the easiest way of implementing vDisk High Availability without additional cost.
What should we consider with this solution?

• Although it is easy to implement and maintain vDisks need to be manually synchronized between the PVS Servers.
• I/O performance depends on the capabilities of the hard drive subsystem (usually equal to NAS).

What are the recommendations?  Network Interface Card (NIC) - Teaming should be used to increase the reliability and to I/O between PVS Servers and Target Devices. You can also add more PVS streaming servers and heavier reliance on load-balancing.

You might be thinking about the vDisk lock files. Would failover work properly redirecting the target device to another server without a vDisk access failure? Yes, vDisk locks should not be a problem. Let's say you are using the vDisk in Private Image mode, the lock file holds the information of the Target Device accessing it.  If it fails from Server 1 to Server 2, Server 2 should not have an associated lock file yet because no other vDisk has accessed it. It will then create a new one.  If it fails back over to Server 1 from Server 2, the lock file will have the Target Device information and re-connect it.  If you are using the vDisk in Standard Image mode the lock files should not prevent any read only access.

Now you might be concerned about the write cache. Server Side caching is not supported, unless the cache is re-directed to a share.  If cache is being stored on the Server's local drive and becomes unavailable after failover, the Target Device will eventually blue screen when it tries to access needed information on the cache file.

Elisabeth Teixeira.

Follow me on Twitter: http://twitter.com/lizteixeira