I get this question a lot. Maybe not as much as ‘Should I Virtualize PVS?‘ or ‘How many users/VMs can I get on a box?’, but I get this question quite a bit. And I felt like it was time to address this since I see our customers, partners and even our own Consultants attempting to isolate the PVS streaming traffic onto its own network without even having a valid reason to do so! This is also one of those “best practices” that has evolved over time in my opinion…what I mean by that is we might have recommended one thing 5 years ago but we’re recommending something else today. Allow me to explain.
Similar to what I did in my last article where I discussed fixed versus dynamic vDisks for PVS, let’s first examine what our public documentation says about this so-called best practice. Our oldest technote on this matter was written in 2008 and it pretty much states that it’s a best practice for “several reasons” including “performance, growth and troubleshooting”. Fair enough…let’s come back to that in a minute and dissect each of those reasons one by one. Another article authored in 2011 details how to set up a multi-homed VM to separate ICA traffic from PVS and other traffic. But it never goes into WHY one might want to do so or if it’s a best practice. Maybe our latest and greatest XA+XD best practices whitepaper will provide us with all the answers (and this whitepaper is quite excellent by the way…if you haven’t read it already, you better get on it!). At the bottom of page 50 we state: “Separate the PVS streaming traffic onto a dedicated network for large deployments or in situations where the network is saturated”. OK, that makes a little more sense. But I still don’t understand why everyone seems to think they fall into this category or that this should always be done. In fact, I contend that isolating or segmenting the PVS streaming traffic onto it’s own network can be more trouble than it’s worth and should only be done in special situations. There I said it – it’s not a best practice in my opinion and the rule should be to consolidate and keep it simple…the exception should be to isolate the streaming traffic! Why?
We used to recommend this (i.e. back in the 2006-2007 days after we acquired Ardence) because everyone was running 100 Mb networks back then! So isolating the streaming traffic for performance reasons or to alleviate network congestion made a bit more sense. Fast-forward to today and I’d estimate that over half of the customers I run into are running 10 Gb networks in their data center (and the others who are still running 1 Gb already have upgrade projects underway). And on some PVS deployments that I’ve done lately with UCS, for example, where we might “contain” traffic in the chassis, we’ll have even more bandwidth to play with than 10 Gb! It’s insane how much throughput we have now at our disposal…so if you think segmenting the streaming traffic onto a different network in these situations is going to boost your performance, you’re wrong.
Other experts might say to do this for reliability. Why? Because PVS streaming traffic is UDP-based and if a switch or network gets congested, it might be the first thing it drops. We already talked about congestion above, but let me reiterate – if you are running a 10 Gb network, you will have a hard time saturating your network with PVS unless you are doing thousands and thousands of streams! And I’ve seen a lot of production PVS implementations…we only have a few customers that fall into this category. But back to segmenting the streaming traffic for reliability purposes – let’s say there is congestion during a logon storm – is our streaming traffic really doomed since we use UDP? Nope. We actually don’t use “just” UDP – the smart folks over at Ardence developed a custom transport protocol for PVS. And one of the enhancements they added in compared to straight UDP was reliability! That’s why you’ll see things like “retries” if something goes awry…this mitigates some of the concerns related to using UDP on a congested network.
Maybe you’re doing it to ease troubleshooting? While that might make it a bit easier for our Escalation engineers (or your in-house PVS SMEs) to analyze a Wireshark trace and see the streaming traffic without doing much of anything, we can simply use capture filters in Wireshark to see exactly what we want. It’s pretty straight-forward. So I don’t think segmenting the streaming traffic to ease troubleshooting is a great reason to do it either.
Other folks might say to segment the PVS traffic to alleviate issues related to PXE, DHCP or TFTP. With proper network design and manageable broadcast domains, many of the DHCP issues can be mitigated. And I still find many customers and partners don’t know about our swiss army knife – BDM! Instead of dealing with “fun” PXE traffic and trying desperately to load balance TFTP, simply boot from an ISO with BDM and you’ll eliminate a lot of the networking complexity associated with PVS deployments.
I should also point out that I’ve seen Consultants attempt to isolate the streaming traffic in large environments (with good intentions), but it really didn’t buy them much at the end of the day with their customer’s networking setup. When we originally recommended this ~5 years ago, we lived in a predominantly “physical world” (physical servers, NICs, switches, etc.). And segmenting the PVS streaming traffic onto a physically separate team of NICs and physical switches was a bit easier and might have made more sense. But now we live in a “virtual world” where many of these networking components are shared or even virtualized (vNICs and vSwitches, shared backplanes, etc.). So I have to ask…how much are you really gaining by segmenting the streaming traffic onto a different VLAN if it’s all going through the same physical switch(es)?! Probably not a whole lot. It’s important to understand that just because you are using separate VLANs doesn’t mean that switch contention will go away – you’re probably still hitting the same physical switch (especially in most blade architectures I see out there).
Now that I’ve “hated” on stream traffic isolation, let me give you one reason why it might make sense – security. The separation of traffic (whether it’s at the VLAN level or physical) reduces the possibility of someone getting into that precious streaming traffic and messing with it. Because theoretically, if you can intercept the UDP-based streaming traffic and inject packets, you are fiddling with the PVS client’s disk blocks. And if someone really knew what they were doing, you could even change ACLs and whatnot on target devices. But this should be “internal” traffic behind a firewall or two anyway, so it’s a risk some customers are willing to take (do all of you encrypt your XML traffic from WI to XML on the internal network?…no…maybe only 5% of you do max!). However, if you do choose to isolate the streaming traffic for security reasons, we recommend that it’s a non-routed network.
With all that being said, I’ve done about 50 PVS implementations and only 3 customers that I can think of separated the streaming traffic on an isolated network because they had a security requirement to do so. I asked another one of my colleagues based in Europe and he said he can think of only 2 customers out of ~30 PVS implementations.
I should also note that I’m talking about isolating the PVS streaming traffic from other “data” traffic only – we still recommend separate networks for management and storage (if you’re using NFS or iSCSI). In fact, this setup (3 networks) is what our System II Testing team in the UK uses to test our products in-house! We simply combine PVS traffic and “production” VM traffic on the same network and have 2 other separate networks for mgmt and storage (XS host management and NFS in our case, respectively). This, to me, is further evidence supporting my claim that separating PVS streaming traffic is no longer a best practice for the vast majority of our deployments.
So there you have it – I presented my case for why isolating the PVS streaming traffic from other data traffic probably doesn’t make sense anymore. Don’t get me wrong – there may be special situations where it’s required or might be beneficial (business or security requirement, Hyper-V deployment with emulated and accelerated NICs, truly large environment, limited bandwidth, etc.), but I really believe those are the exceptions to the rule and we should be keeping our PVS designs simple going forward.
I hope you found this article useful and it makes deploying PVS easier for you in the future. Do you vehemently disagree with me and always isolate your streaming traffic? Drop me a comment below – I’d love to hear from you. Or have you always said the heck with Citrix best practices and consolidated your PVS traffic with other data traffic because you’re smarter than the average bear? I’d also love to hear from you.
Shout-outs: I’d like to personally thank Chris Gilbert from our System II team for sharing their testing setup with me. I’d also like to thank Dimitrios Samorgiannidis (“D-Man”) for making me write this article after talking about this “best practice” over a few cocktails in Istanbul. 😉
Cheers, Nick
Nick Rintalan
Senior Architect, Citrix Consulting
