By Don Wiggins on January 14, 2016 21:39
As I plow through my current design, I took some time to review the evolution of the scope and key principles then decided to take a fresh look through the pages and ponder “what are the keys to a good VDI design?”
To start, one of the basics is segregated hardware (storage/compute) and getting to a pod based architecture. So, something that can be placed into your current datacenter so it can be isolated and scaled without being constrained by other workloads like the server infrastructure. This lowers the risk of your VDI environment impacting other workloads. Sometimes there are only so many levels of separation you can achieve given hardware resources and for me, Hyper-Converged Infrastructure has offered a great capability to move my VDI workload onto its own. The idea with this that I love is your design can be created in building blocks. Maybe they are 200 user blocks that can scale to 2,000. This offers you a flexibility that was, at minimum, hard to achieve years back.
I keep using the term VDI, but think about the surrounding components of the EUC eco-system in your design. There are many integration points, changes to software delivery, and profile delivery decisions that can have a huge impact on your VDI implementation. Ensure you keep the core services required for VDI close to your VDI implementation. As well, realize that with application virtualization and profile management, the shares and disk pools for which those packages and profiles reside will most likely experience an uptick in resource usage. Ensure that you have the proper performance to handle that uptick and consider placing those shares on storage pools within the VDI pod.
From my experience, the four most painful integration pieces of a VDI implementation can be; Active Directory, anti-virus, network/firewall/load-balancing, and application delivery.
In the case of Active Directory, validate the environment and document precise requirements. From Sites and Services, to Group Policy, to OU structure, to groups, and permissions.
In the case of anti-virus, most vendors make very precise instructions on the best practice and configuration steps to implement their product in the type of VDI environment you are creating. Document not only the procedure but also the workflow as well. In the case of security, most people will want to understand what is going on to ensure that data is secured.
For networking in general, understand your audience and provide some useful documentation on firewall rules, trunk port requirements, and work closely with the load balancing team to ensure that you have the documented configuration in place. There are often times several load balancing schemes that can be used in a VMware View implementation, for example.
Saving the best for last. Application delivery can downright kill a VDI project before you onboard your first user. Having 2,000 desktops at the push of a button does nothing without careful thought into and good solutions of how to deliver applications to the user base compliantly. One of the first things you want to ensure is you have a discovery of the applications that will be included with the solution as well as the licensing model in use. Be prepared to look at many options of how you will deliver the application based on licensing constraints. That will narrow you down to your options. The second is to see if the vendor will support any method of application virtualization, most likely not. From there, attempt to figure a LOE and weigh that with chance of success. Many people have their own thoughts on this, but I will share mine here. To me, if every user uses it, and licensing permits, it goes within the base image. As simple as that.
Of course a design cannot be talked about without the fun part, math. There are many tools out there nowadays to help do your math for you. I am a huge fan of that, trust me, but verify. Even if you loosely run the numbers against a vendor tool, I suggest you do. I have found in some instances a vendor tool did not incorporate any of the infrastructure of the View environment, the vCenter, A/V scanning appliances, monitoring tools, application capture machines, parent machines, and anything not a virtual desktop. So do yourself a favor and trust but verify, even if you are doing it the old fashioned way. Remember the peak is the biggest piece to plan for and I do not have enough space in this blog to go into that.
Storage, storage, storage. This used to be the hardest part and it still can be. The new technologies have made things much easier with the advent of hot caching and the lowering price of SSD’s. Some things do not change though. Look at your growth rate. Thin Provisioning is all great until you realize you are out of space and are 200% overprovisioned. I/O is still a huge deal. Try to remember, Replica = reads, clones = writes. You can move those pieces around to the best storage if you still need to. Also, be ready for the Replica to get read like Harry Potter and think really hard about putting on SSD’s if you haven’t already planned it. Another thing to remember, ThinApps are similar to Linked Clone Replica’s. Not nearly as taxing but a consideration if you are streaming ThinApp packages. Another piece, that in a pod based design doesn’t often come into play, but if you are integrating your VDI environment into your current storage solution. Think long and hard about the throughput you will need during peak usage. It goes without saying you at least need to have your VDI storage separated as much as logically possible.
The last point I will touch on use profile management. This is often a solution owned by the VDI team and understood by no one else. Documentation is the key to breaking this down. Ensure end to end that the requirements, shares, permissions, and configurations are documented. I would also look at how this will need to integrate into your VDI A/V solution. There will most likely be some additional exemptions that will need to be added to your policy.
The first VDI design I did I pretty much comprised linked clone desktops, storage I/O, VM’s to core, memory, and networking. Pretty standard stuff. The issues I found with this is that VDI is more complex than the stress it puts on the underlying hardware and network. Often times I would have an Appendix that had more information than the design and at that point I realized it was time to adapt my design. I look for my VDI designs now to be a EUC Bible for the organization. If I am hit by a bus, my disciples can go forth providing VDI to the masses. If a new security administrator is hired, they can explain the reasoning of the A/V configuration. If/when the firewall team blows away the firewall configuration, they hand them a simple spreadsheet with every rule required.
Wrapping up, much like many technologies available today, the level of integration and ever evolving complexity makes it a necessity to provide an encompassing design document that can offer soup to nuts standup and integration. Getting the big picture of the design included with will provide a one stop shop to answers for the many questions you will get while working with numerous teams as well as provide a historical reference and guide to expansion/recreation.