Best Practices For Provisioing Services VHD Storage?
We currently have this architecture:
- 2 PVS servers
- 1 File server
The PVS servers connect to the VHD images on a single mapped network drive on the file server.
We have been experiencing network latency issues which I believe are due to the file server. I will have to shut down all of the VDAs in order to reboot the file server. This is a single point of failure for us. Bad News Bears...
This brings me to the question(s):
What is a best practice for ensuring fast and redundant VHD access for the PVS servers?
I have heard of placing a VHD on one PVS server and then replicating that to an identical folder on the other PVS servers. That way, there is less network activity. Is this something you guys do? What about replication file servers? Problems with either of those options?
I want to make sure my next architecture change is ready for 2017 and beyond (i.e.- new versions of XenDesktop and PVS)
- 2 PVS servers
- 1 File server
The PVS servers connect to the VHD images on a single mapped network drive on the file server.
We have been experiencing network latency issues which I believe are due to the file server. I will have to shut down all of the VDAs in order to reboot the file server. This is a single point of failure for us. Bad News Bears...
This brings me to the question(s):
What is a best practice for ensuring fast and redundant VHD access for the PVS servers?
I have heard of placing a VHD on one PVS server and then replicating that to an identical folder on the other PVS servers. That way, there is less network activity. Is this something you guys do? What about replication file servers? Problems with either of those options?
I want to make sure my next architecture change is ready for 2017 and beyond (i.e.- new versions of XenDesktop and PVS)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
@Cliff - At this time, we will continue to use Windows Server 2012 Datacenter for all server deployments. Are you saying that my best option is to deploy shared storage through file servers rather than put the VHD files on the PVS servers with replication?
@Carl - The robocopy script is manual, correct? I assume you prefer that to eliminate DFS-R as a possible point of failure...
So, how does that look once it is in place? You take one VHD, put it into maintenance mode, update the image, robocopy and then put into production on each PVS server?
@Carl - The robocopy script is manual, correct? I assume you prefer that to eliminate DFS-R as a possible point of failure...
So, how does that look once it is in place? You take one VHD, put it into maintenance mode, update the image, robocopy and then put into production on each PVS server?
Yes, robocopy script is manual.
Create a maintenance version, make changes, promote to test, test the changes, promote to production and run robocopy script. Script will only copy over the new or changed files which for versions, will be very small files. Exclude *.lok files and the WriteCache folder.
Create a maintenance version, make changes, promote to test, test the changes, promote to production and run robocopy script. Script will only copy over the new or changed files which for versions, will be very small files. Exclude *.lok files and the WriteCache folder.
ASKER
Sounds good. I searched your site for anything covering robocopy and didn't find it. Know of a good reference article for this?
Yes, your best option is shared storage. Replication itself introduces challenges in sync, proper lose balancing, and often increases administrative cost and other failure opportunities. I've ever seen a successful deployment survive real world ROI and DR analyses.
ASKER
@Carl - I don't think that document is the right one. I didn't see anything about robocopy, PVS or Citrix.
I thought I had posted this link but it looks like it didn't make it from my phone.
http://vhorizon.co.uk/robocopy-script-to-replicate-citrix-pvs-vdisk-store/
http://vhorizon.co.uk/robocopy-script-to-replicate-citrix-pvs-vdisk-store/
ASKER
That tool looks awesome, but if I'm reading the article right, it doesn't support intra-site replication.
I have a single farm, single site and two stores. From what I'm reading, the tool only works if I'm transferring to another site.
I have a single farm, single site and two stores. From what I'm reading, the tool only works if I'm transferring to another site.
Using the tool, administrators can easily replicate a vDisk (or vDisks) from one PVS server to all other servers in the same site, and all PVS servers in another farm and site (including the export and import of vDisks and versions).
ASKER
Well, that seems to be conflicting information. It doesn't support intra-site replication, but it replicates from one PVS server to all others in the same site...
I'll give it a try on a non-production vhd and see how it goes.
I'll give it a try on a non-production vhd and see how it goes.
ASKER
After making sure that I have mclipssnapin added to powershell, I still get "PCS Powershell Snap-In Not Found".
I am trying to run the GUI of the replication tool.
I am trying to run the GUI of the replication tool.
If you are running 64-bit PoSH, did you add both the 32-bit and 64-bit DLLs
ASKER
Yes, 32 and 64 bit are registered and the transacted installs completed successfully.
I can't run the GUI of the new tool powershell but the MCLI commands work so I'm pretty sure that the PVS snapin is working.
If I run the GUI command from the command prompt, I just get a notepad file that opens.
I can't run the GUI of the new tool powershell but the MCLI commands work so I'm pretty sure that the PVS snapin is working.
If I run the GUI command from the command prompt, I just get a notepad file that opens.
I had no problem after following the directions in the script's help text.
ASKER
Ya, I've tried it every which way and still get "PVS Powershell Snap-In Not Found". I'm going to get with Citrix Support and see if there's a problem with my PVS install... I'll get back to you.
ASKER
@Cliff
@Carl
I got a reply from Samuel Breslow, the tool's maker, and he said that I need to be using PVS 7.7 or newer. I'll be upgrading PVS later this year. In the meantime, I'm exploring your recommendations for placing a copy of the vhd on each pvs server and then use robocopy.
Yes, your best option is shared storageBy shared storage, are you talking about a FC SAN kind of storage or using a file server that holds the vhd file(s) and is used by both PVS servers?
@Carl
I got a reply from Samuel Breslow, the tool's maker, and he said that I need to be using PVS 7.7 or newer. I'll be upgrading PVS later this year. In the meantime, I'm exploring your recommendations for placing a copy of the vhd on each pvs server and then use robocopy.
You can install the 7.7 or later console on any prior 7.x PVS server to get the new PowerShell stuff.
http://carlwebster.com/using-new-citrix-provisioning-services-powershell-pvs-7-0-7-1-7-6-7-6-ltsr/
Shared Storage can be CIFS/SMB, FC, iSCSI, NFS, NAS or similar storage tech that allows Windows to see a common storage are or drive.
http://carlwebster.com/using-new-citrix-provisioning-services-powershell-pvs-7-0-7-1-7-6-7-6-ltsr/
Shared Storage can be CIFS/SMB, FC, iSCSI, NFS, NAS or similar storage tech that allows Windows to see a common storage are or drive.
ASKER
Carl, this brings up a side question...
Should I just upgrade to a higher PVS version?
I was reading [url="https://www.citrix.com/blogs/2016/01/14/7-6-7-7-or-7-8-ltsr-to-the-rescue/"]this[/url] and Nick suggests going with 7.6 LTSR (although that was back in early '16), but what about all those cool features that came out later?!
Should I just upgrade to a higher PVS version?
I was reading [url="https://www.citrix.com/blogs/2016/01/14/7-6-7-7-or-7-8-ltsr-to-the-rescue/"]this[/url] and Nick suggests going with 7.6 LTSR (although that was back in early '16), but what about all those cool features that came out later?!
Regardless though, multiple fine servers is not an inexpensive endeavor. Nor is using a fike server at all for multiple compute nodes. Fast disks, caches, no 2008/R2 licenses...you can't skimp. Or performance will just suck, and it probably isn't just the network at fault.