Post to Twitter |
Comments (4) |
Views (2352) |
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
Comments (4)
Sep 17
Anonymous says:
When using read-only SAN, how does one accomplish and update to the vDisk withou...When using read-only SAN, how does one accomplish and update to the vDisk without affecting currently logged on users?
Sep 17
Elisabeth Teixeira says:
When using a read-only store not only must you shut down all devices using ...When using a read-only store not only must you shut down all devices using all vDisks on the store (SAN LUN), you MUST also disconnect all servers except one from the SAN LUN. You do this by logging off using the iSCSI Initiator front end, or dismounting the SAN LUN disk in the MS Disk Manager. Once all servers have been disconnected, it is then permissible to move the SAN LUN into read-write mode to do the update. If you do not disconnect all servers (except one), the SAN LUN NTFS Volume will likely be corrupted and you will lose it's file system and any vDisks stored on it. NTFS will not tolerate multiple servers accessing the same LUN in read-write mode. Even if you are not actively making changes from the other servers. This is a limitation of NTFS.
Sep 18
Stephane Quevillon says:
Given the process described above to update the vDisks, it makes this feature vi...Given the process described above to update the vDisks, it makes this feature virtually impossible to use on a production envrionment. Unless you can offer a solution where one can update vDisks without taking out the entire PVS stores, I don't see how useful this really is. Perhaps you can discuss the value of this feature in a real-world setting?
In researching this exact problem, I came across on Citrix white paper that suggests the use of a cluster file system to enale read/write access from multiple PVS servers to a common LUN. I have set this up in my lab and it works really well. Does anyone have data on how cluster file systems affect the performance of PVS?
Sep 21
Anonymous says:
This was exactly my point, it is useless in a real-world scenario (as Stephane m...This was exactly my point, it is useless in a real-world scenario (as Stephane mentioned below).
Add Comment