Post to Twitter |
Comments (5) |
Views (7081) |
This best practice was requested by a comment on a previous blog posting. With Provisioning Services, we are able to use a single image for hundreds of XenApp target servers. Making a change to the image is a big deal because every XenApp server will use the new image after a reboot (of course this is also a huge benefit). How do we keep control over these images and make sure you don't break your entire environment with a new update?
Truthfully, it is a fairly straight forward process, but just like all processes, you need to follow them if you want things to go smoothly. High-level process overview is in the following figure:
These are all logical systems, meaning that they could be virtual servers, physical servers, different volumes on the same storage infrastructure. The recommended process is as follows:
- When you have a valid vDisk on your production Provisioning Services server, make a copy of it and store it in your library. The library is just that, a location where you keep the current and old revisions of vDisk images.
- When you need to make an update, copy the vDisk from your library to your test environment Provisioning Services server.
- Make your changes in the test environment. When the changes are done, update the revision number and filename of the vDisk. Copy the vDisk back into your library and to the production Provisioning Services server.
- Tell the production Provisioning Services server to auto-update vDisks. This is actually a really cool feature. The auto-update process will automatically update the vDisk file of all affected target devices upon next reboot. How can you tell which target device will be updated? By the Class information. Each target device and vDisk file has a Class field. The class fields are the link for auto-updates. Provisioning Services will look to see if there are any vDisks with a higher revision number (which there is as we just updated the vDisk and incremented the revision number). Provisioning Services then checks the Class of the vDisk. Any target device with the same Class will receive the new vDisk upon next reboot. This is a great way to simplify the management of your XenApp farms.
Ok, so we updated our XenApp servers with a new vDisk, but what happens if there is a problem with the vDisk updates? Have you ever installed a hotfix to find out it broke other things? I bet so. If you followed the process outlined above, you have a build in rollback feature by doing the following:
- You make a copy of the previous vDisk image from your library to the Production Provisioning Services server.
- You increment the revision number on the old vDisk image to a number that is higher than the updated vDisk image.
- You implement the auto-update feature of Provisioning Services
- Reboot the XenApp servers
As you can see, the processes for updates and rollbacks are very similar and it works great. Stay tuned for more best practices regarding Provisioning Services and XenApp.
- vDisk Type
- vDisk Cache
- Active Directory
- Application Integration
- Application Streaming Cache
- System-level settings: Page file, drive remapping and multiple drives
- Image Management
- Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
- Plus more if we get some good ideas on other areas of focus.
By the way, if you haven't done so already, take a look at the Provisioning Services for XenApp TechTalk presented by yours truly. I'm a little biased, but I think it is a good one.
Daniel - Sr. Architect - Worldwide Consulting Solutions
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf
Comments (5)
May 01, 2009
Anonymous says:
Hello, The Classes and Version is pretty cool but it's pretty finicky. I'...Hello,
The Classes and Version is pretty cool but it's pretty finicky. I've had some success with it but if you design your collections around what vDisk are used it is pretty each to drag a drop the new vDisk to the collect and ALL of the machine are automatically updated on the next reboot. If there is a problems, simply drag and drop the previous version onto the collection. It's pretty simple straight forward. The only drawback is if you need to schedule the vDisk change (say, swap out in the middle of the night) you would have to script it (which isn't too bad).
Joe
May 11, 2009
Rob Montgomery says:
Hi all, For conveniently using the best practices described above without...Hi all,
For conveniently using the best practices described above without involving extra budgeting I have recently switched to using iSCSI SAN solution. I was going to take some of the old PC out of production and balance, however, a colleague suggested giving them a second life by turning them into network storages.
So basically, I dosnloaded StarWind Server iSCSI application, installed it onto 3 of the PCs and in a couple of moments I had additional network space extended for using with Xen.
Thanks
Jul 01
Anonymous says:
One aspect that appears to missing from guide is what to do aroound antivirus an...One aspect that appears to missing from guide is what to do aroound antivirus and signatire updates. What would be the recommended approach to securing the platform/environment with a read only image?
Neil
Jul 02
Anonymous says:
I agree with the previous post; this seems to be a big unknown at this point as ...I agree with the previous post; this seems to be a big unknown at this point as a lot of the available documentation and online resources do not cover much related to this area.
Anonymous replies:
Jul 27
Jason Conomos says:
Hi there, I have been dealing with PVS since Version 4 and do really like...Hi there,
I have been dealing with PVS since Version 4 and do really like the product (mostly in Xendesktop implementations however).
In relation to the questions about Anti Virus updates. I just installed the anti-virus client on the servers/workstations and let them update. The updates are never that big (say a few meg at most during the course of the month). If the servers or workstations rebooted, they would just pull down the files again. Again it is only a few MB so there is minimal network load.
On Patch Tuesday we would then as part of the patch deployment updated the image with new patches and update the AV definitions.
Cheers
Jase
Add Comment