You understand the business drivers, the VDI project is ready to be kicked off, but where is this environment going to live? Your company’s private cloud performs great and there is excess capacity. It may seem like the clear choice, but internal clouds are built for 80 percent of applications, and VDI is not one of them.
VDI has very specific requirements, and you can’t risk the responsiveness of your production IT environment by saturating all the hardware resources when VDI work volume fluctuates. Even if you upgrade your storage array’s performance, you’ll find your network cannot handle the increase in data transfer. After you upgrade your network throughput, you’ll need additional storage capacity, and so on and so forth. This resource contention can have significant impact:
- Storage: Your storage solution can have a tremendous impact on the VDI end user. Storage costs are falling, however you still have to sacrifice capacity for performance. Storage performance is most frequently measured in Input/Output Operations per second (IOPS), however at the same time it is one of the least understood metrics in technology today. IOPS generally refer to how quickly data can be written to or retrieved from a storage array. This gets complicated very quickly and is only part of the answer. What you should really care about is how long it takes for the data to get to the application (and therefore to the user that requested it). In short, to get meaningful IOPS you also need to factor in latency. Add to this unpredictable user behavior and the fact that automated tasks can run (ex. anti-virus scanning) and work volume can fluctuate, and your future storage needs become a mystery. Before deploying VDI on your existing storage array, just consider that it may not be cheap (or possible), to right-size the array after the initial deployment. You can read more on Dizzion’s Storage services here.
- Network: The network requirements for a VDI deployment are often underestimated, and chances are your existing production environment was not architected with VDI in mind. VDI is chatty, as there is a lot of backend communication generated during boot and login events, application launch events, file share servers (if folder redirection is being used), and backup traffic. Isolating this network traffic will result in a better user experience. You should also consider if users will connect over a wireless network as there can be substantial variation in signal quality and available bandwidth.
By architecting and deploying a VDI-specific environment, you can easily prevent these inconsistencies. Your end users will receive quick application load time and will be able to make crystal clear calls with their softphone. They will be able to quickly and easily consume high definition images, large PDFs and video. It will be as if the desktop was running locally on their end-point device.
And that’s the whole point of a VDI – to perform as though you weren’t using one. So while keeping your VDI in a private cloud may make sense at first, in the end if your users notice a difference you’re not capitalizing on the capabilities a best-in-breed VDI deployment can provide.