In Part 1 of this two-part series, I laid out the virtual desktop infrastructure (VDI) challenges placed on contemporary and common WAN environments. I also outlined the reasons why VDI presents new challenges to the WAN and WAN engineers. In this second part, I will give you some techniques of ways to monitor and troubleshoot VDI over WAN and also give you practical solutions you can implement today without tearing out your existing WAN.
Know your WAN utilization before implementing VDI over WAN
If you have assessed your WAN as ready for VDI, then create utilization baselines a month or two before your full VDI deployment. You can do this by taking snapshots of your WAN utilization for specific periods. Generate a report for an entire month, a weekly report for each week that same month and a daily report for a typical week. The reports will serve as your comparative baseline when you have VDI performance issues and others ask if the WAN was the cause. Overlay your current utilization report for a given period on top of your baseline and see if there are any anomalies.
If you have the budget and resources, look to implement an intelligent network utilization monitor such as Riverbed Cascade or SolarWinds Orion. Both will capture baselines and perform comparisons as part of their normal operations.
Get a network analyzer
Utilization charts as mentioned above are useful to find potential hotspots, but they won't bring you to a final conclusion. If you don't already have one, implement a network analyzer that captures traffic flow at the protocol and session level. This will allow you to find the culprits that are monopolizing your bandwidth and even tell you what they might be doing. If you do this, remember the following:
- Past-time is as good as real-time: Don't be satisfied with just capturing information for the last 5 minutes. Make sure you allow your analyzer to keep detailed information for at least a week.
- Who did what? Knowing which device/user was causing the flooding is useful, but make sure you track the ports so that you can trace the usage to a particular application.
- Speed up your WAN monitoring system: Don't be cheap when giving your monitoring system resources. You need it to be fast to expedite your diagnosis and find the offenders. There is a reason why police officers learn to drive fast.
Rethink your WAN threshold tolerance
WAN engineers often look for tabletops or plateaus that indicate oversubscribed WAN lines. Unfortunately, typical WAN utilization graphs show the average across a sampling period. Hence, if your sampling period is 1 minute and the line was maxed out for only 15 of those seconds, you won' t see that the line reached 100% utilization even though the VDI users may have had a frozen screen for the entire 15 seconds.
For proper VDI monitoring, you should either use shorter sampling periods -- I recommend 15 seconds -- or redefine your acceptable bandwidth peak.
Leverage WAN optimization for VDI over WAN
If you read the first article, you would think I was contradicting myself after writing an entire section titled, "WAN optimization won't come to the rescue." This statement is still true. WAN optimization won't be your savior but will still benefit the environment. Below are reasons to consider WAN optimization:
- Reduction of bandwidth reduces contention, therefore opening more of the WAN throughput for VDI traffic.
- Some WAN optimization devices, such as the Riverbed Steelhead, provide prioritization and allow you to reserve the bandwidth you need.
- More WAN optimization devices now support compression and caching of VDI protocols such as ICA and RDP. In fact, Riverbed recently announced it would even support Teradici PC-over-IP optimization in an upcoming release.
Implement bandwidth limits for VDI over WAN traffic
A tactic rarely implemented in VDI environments is the use of bandwidth limits. One of the fears is how it might affect the quality of the desktop and the user's satisfaction. However, allowing uncapped sessions has great potential of affecting the performance of all users except for the one that maxed out the line.
The applications that can cause flooding are not limited to video playback and other graphics-intensive apps. Even something as simple as an online game on Yahoo can eat up much of your bandwidth. Try playing some of those Flash games online and see what they do to your ICA or PC-over-IP protocol traffic. The reason you'll see the transmit rate reach well above 500 Kbps is due to the fact that the compiled Flash code, though small, acts like video rendering in VDI.
To offset any fears of too low a cap, start with a cap of 1/3 your WAN line speed -- for example, approximately 500 Kbps on a T1 -- and work your way down from there. At the very least, you have now prevented a single user from becoming a bandwidth hog.
Revisit your QoS design
VDI is such a game changer that you will have to review your network QoS design. You likely have Voice over IP (VoIP) and Video over IP in the highest available class of service with critical business applications below them -- such as ERP and email, etc. Below that you'll probably push down non-critical applications such as Web traffic. VDI deserves a higher priority than even the critical business applications or at least should be classified as a higher priority. The reason for this is that VDI traffic directly impacts the user’s perception of the performance of his or her applications.
Contemporary, non-virtualized applications are usually designed to assume distance between the app and the server and use techniques such as local caching and session state management. One example of this is Outlook. Outlook once required a direct and fast connection to the Exchange server. By default, Outlook now utilizes the OST (offline, local database) and then uses background synchronization, which hides any network latencies from the user for most Outlook operations.
However, VDI requires an acknowledgement and response for almost every user operation that creates a higher dependency on network performance. In fact, latency has an even more dramatic effect on VDI than it does for VoIP because it uses TCP and not UDP, which is designed to accept and account for packet loss, jitter and drops.
Review your QoS design to accommodate for VDI over WAN
WAN engineers have new challenges when the CIO decides to put VDI on the network. They have to be more responsive and exercise deeper inspection and control of their networks. If you think VoIP created new demands that required changes in the way we design and manage our networks, wait to see what VDI will do on the network. It is more demanding and directly impacts the user's perception of IT infrastructure performance. These techniques will hopefully prepare you for these new demands and challenges created by VDI.