The 411 on VDI – Virtual Desktop Infrastructure

VDI Brief

As the use of Hyper-Convergence technology spreads throughout the industry, desktop virtualization has followed in this lead because HCI is a great platform for execution. Three of the main VDI players at this time would be Citrix, VMWare, and Microsoft. What is great about VDI, is that you are not necessarily tied to one specific vendor. For Example, your broker could be provided by Citrix, while the backend infrastructure could be provided by Microsoft, or VMWare. One thing to know about VDI is what it is not. It is not just the virtualization of desktops. It’s essentially a whole infrastructure based on supplying the desktop experience to the end user without necessarily having a desktop. This is not without complications though. Since there is no real ‘local’ processing of data and graphics, the network & server infrastructure have to be resilient enough to handle the amount of data that will pass over to each end user. One important thing to realize is that if there is a network issue between the end user & the VDI infrastructure, your user’s most likely won’t be able to work. Remember, users that are currently in your organization that have a desktop or laptop could conceivably still work locally. That being said, there needs to be a way for the end user to connect to all these resources. This is done by means of the Connection/Session Broker.

From the client side, the Connection broker is basically the means that allows a client (Thin Client, Desktop, etc) to connect to an available VM in a VDI environment. When a user logs into the Connection broker, the user will be redirected to an available VM (Session) via RDP or some other protocol based on credentials. This VM can be either a persistent, or nonpersistent VM.

Being Nonpersistent

If the session is nonpersistent, once the user is done working and has logged out, this session is released. The VM will essentially be reset back to its initial state, and put back into a pool of other nonpersistent sessions to be used by the same user or another that has the same type connection profile. On the plus side, a pool of 100 VM’s can be used by any users at any time. On the minus side, a user’s specific data, or application(s) cannot be stored on this VM because it will be reset once the user logs out. Just like most standard desktop deployments, in VDI there is usually a ‘Gold’ image. This image is what each VM in the nonpersistent pool is based on. You can look at each of these VM’s as clones of the base image.

Wanting to be Persistent

If a user is assigned to a persistent session, it will not be put back into the pool for others to use. This session will not be reset, and will basically will be this user’s own personal VM. Applications that were installed will stay installed, and data saved in this VM will still be there the next time this user logs in. From a management standpoint, this creates an issue in handling required resources as each nonpersistent VM can be unique in requirements. Another downside to persistent sessions is that there is no ‘backup’ session. Unlike nonpersistent sessions there is no pool of other sessions to draw upon. If for whatever reason the VM fails, it will have to be re-created from a base image which will mean all local data in that VM will be lost.

Not Just the Broker

Let’s not forget that the Broker is just managing the client access part of VDI. There is still some magic going on in the backend. The platform in which all these sessions are managed whether it be Hyper-V, VMWare, Citrix should be able to host all the VM’s needed for your users at any given time. It should also be able to manage these ‘pool’ of sessions and make sure there are enough VM’s available for the broker to connect to in order to provide seamless integration for a good user experience. While that does conceivably take care of the session’s themselves there is also a concern of how to deliver applications when needed. That would be where application virtualization comes in. This should provide seamless availability for applications for each VM. In a nonpersistent environment, you do not want to have to install applications every time a user logs in. Care should be taken on which applications can be virtualized as performance may suffer if resources are not properly allocated on those sessions. If resources are not necessarily available or performance is not what is expected, then a persistent VM for the user may want to be considered. Another option for resource driven applications be it CPU, or Video would be to look at HDI.  HDI (Hosted Desktop Infrastructure) will remove some of the restrictions/overhead with typical hypervisor/virtualization configurations and allow a more of a dedicated computer experience.

All in all VDI is a good solution for production, lab, and remote access environments if enough resources are available. Careful planning needs to be done to try and facilitate all Server, Network, and Storage needs and cover as many specific applications needs as possible prior to deployment.

 

Steve Rainess

Author Bio: Steven Rainess is a Solutions Architect for CCSI. He has 25 plus years experience in the IT industry. For most of these years he has been a consultant as a Subject Matter Expert in Systems, and Networking area, as well as, some Project Management and Development work. His work has covered many verticals including Financial, Education, Broadcasting, and Software Development.

The post The 411 on VDI – Virtual Desktop Infrastructure appeared first on CCSI.



This is a Security Bloggers Network syndicated blog post authored by Steven Rainess. Read the original post at: CCSI