Post to Twitter |
Comments (5) |
Views (7493) |
The whole concept of a standard image used across multiple end points is a great idea. Think about it, 1 image for hundreds/thousands of servers. Talk about simplicity. I only have to make updates once and every server has the same update. Every server is identical. This makes scaling up the environment easy. Of course there are some challenges, as many of you have pointed out after my very first blog posting where we spoke about vDisk type. That challenge is that the "write cache" is destroyed upon server reboot.
For the most part, this is a good thing. Those changes gives each XenApp server a personality. I don't want my XenApp server to have personalities. Its kind of like running Microsoft Word one day and it is using United States English and then the next day it uses United Kingdom English. This little personality change doesn't seem to be a big deal, but it is. For example, I like my words to use the letter Z. I believe you spell color without the letter U. I believe neighborhood is spelled without the letter U too. Of course this is a simple change for a user, but we shouldn't make our users do this. But there are some changes on XenApp servers which are valuable (many of you have pointed them out to me) like event logs and performance metrics.
So how do I use a standard image but still allow these important items to remain persistent across server reboots? Some of you have raised good points on this, especially around the use of differential disks, but the problem with differential disks is that the differential cache will go away if the base vDisk is changed. So, differential disks do not really help us out that much. What we can do instead, which again some of you alluded to, is to use a local disk.
Now I bet some of you have alarms going off in your head and are thinking, "Hey, I thought the benefit of Provisioning Services is that I don't need local disk". Well, you are 100% correct, that is one of the benefits, but there are more like standardization and synchronization but will leave that for a marketing-type blog. But with standard images you do lose some items like persistent storage of event logs, metric databases, etc. But if we allocate a local disk to the server, we can redirect the storage of the persistent data. BTW, this works when XenApp is virtualized on XenServer and when XenApp is on bare-metal.
You do this by doing the following:
- Your virtual machine must have 2 virtual disks assigned. Remember if you want to do XenMotion, the second virtual disk must be on shared storage. How large you might ask? For XenApp, a 4GB partition is a good starting recommendation, but with most decisions, it depends.
- Build XenApp on the first disk and format the second disk NTFS so it shows up in your system (use basic disk and not dynamic).
- Change the storage paths of your persistent databases, event logs and anything else to the second virtual disk.
- Build your vDisk from the C drive, but not the second drive. When done, shut down the virtual machine.
- Detach the OS virtual disk from the virtual machine, but leave the second virtual disk attached.
- Clone the virtual machine including the virtual disk.
- Now stream the vDisk image to this new virtual machine. Your event log should be stored on the virtual disk instead of within the write cache.
So now we are using a base vDisk for our image and still allowing persistent data storage. And what's more, you can also use that persistent disk to be the write cache storage location as well. Just tell Provisioning Services to store the write cache on local storage, and the persistent disk will hold that information for the server's session.
My list is now empty, but will post new topics as they come in. Feel free to tweet me some ideas on Twitter.
- 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 - Lead 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 08, 2009
Nico Van Meurs says:
Hi Daniel, Thanks for the article once again! I have a nice topic to add t...Hi Daniel,
Thanks for the article once again!
I have a nice topic to add to your list: Networking.
Do you recommend to use a deticated VLAN for streaming traffic? Do you recommend teaming of your NIC's on the Provisioning Server. What about when you use XenServer to host your XenApp servers, do you recommend bonding of the interfaces? When using dedicated VLAN's how do you recommend handling DHCP?
I know the XenDesktop Best Practices guide states some info on networking, but I would like to know your thoughts about this in a XenApp environment.
Thanks!
Nico van Meurs
May 09, 2009
Ron Kupferschmied says:
Hello Daniel, Great series of articles! I second Nico's request - Recommende...Hello Daniel,
Great series of articles!
I second Nico's request -
Recommended networking with/without XenServer is a most needed topic.
Also could be nice: Recommended workloads to provision except XenApp. (What should or shouldn't be provisioned)
Thanks!
May 11, 2009
Rob Montgomery says:
Hello Daniel, What would you say about using iSCSI based storage SAN for ...Hello Daniel,
What would you say about using iSCSI based storage SAN for sharing the files or targets across multiple clients?
Thanks,
Rob
Jul 29
Anonymous says:
I'm using ESX rather then XenServer but my issue shouldn't be any different with...I'm using ESX rather then XenServer but my issue shouldn't be any different with the different hypervisor. I followed these procedures but encounter the following problem:
After I create the vDisk and assign it to a new VM with provisioning server (this new vm also has a virtual disk attached to it like the source image did), when the PvS VM comes up, it doesn't have a signature on the second virtual disk (f
that I added. I presume this is because its identity is different from the one that was on the original source VM. So it doesn't see the F: drive so it can't save Event Logs.
When I go to Disk Manager and write the signature, I can create the F: drive, but of course, every time I reboot the server, the signature is gone because this is not a private vdisk.
So this appears to be a limitation with the Windows OS immediately identifying the second drive. Has anyone else seen this and discovered a solution?
Jul 30
Daniel Feller says:
Only time when I've seen the OS not recognize the new drives is if the drives ha...Only time when I've seen the OS not recognize the new drives is if the drives have not been NTFS formatted yet. If u just allocate space without formatting, Windows doesn't know what to do with it and waits until you go into drive management to initialize the drive. I typically create my drive, format it, then clone the drive. This ensures the remaining clones also are formatted. When windows boots, it should see the drive.
Daniel - Lead Architect
Anonymous replies:
Add Comment