WoodITWork.com

This post is the third in the series: Designing a Virtual Infrastructure that Scales.

In Part 2, Speak to the people, I went through some communication ideas to involve more people in the information gathering stage to ultimately be able to put together a better infrastructure

In this post I’m tackling the things you need to be thinking about when you consider VDI.

So…VDI, the promised solution to all your IT needs. No PCs on desks, thin clients, zero clients, happy clients, automated provisioning, stateless VMs, thin apps, streaming.

VDI is certainly a very different way of delivering IT to clients, it can be seen as terminal services on steroids, using some of the benefits of shared resources but allowing separation when you need it.

Why is VDI any different from just having VM workstations which people connect to?

True, there isn’t really a difference from a virtual hosting environment but I like to distinguish between VDI and VM workstations in two ways. First, there is a broker involved that abstracts the connection between the client and the actual workstation. Clients may still be either connected to a single workstation or one in a pool of workstations and also possibly be directed to a different one each time. What makes a broker important is it allows you to manage and also change the workstation a client connects to without having to change anything on the client and so forms another abstraction layer between clients and VMs. Brokers may also allow a more efficient protocol to be used rather than RDP, such as Citrix ICA/HDX or VMware/Teradici PCoIP. The second aspect that can make VDI different to VM workstations (although not entirely essential) is the concept of dynamic workstations, where workstations are in some way built automatically, either through some scripting or a separate application that puts together the VMs and delivers it to the broker to be ready to use by clients.

This is actually quite hard, despite what all the vendors will tell you. It is a complete game changer to automatically create VM workstations and have them delivered to users. You have a number of challenges to overcome. The VM needs to be stateless, it cannot hold any client custom data as next time they connect they could be directed to another workstation, so you need some profile management solution. You need to decide how many common images you can maintain. If a group of users use the same apps they can use a common image. How many common images can you use? Fewer means less to manage but may constrain what apps your clients can use. Throw in other solutions to fix this this such as terminal services for apps and app virtualisation by streaming or packaging and you can see you’re looking at a completely different way of delivering your apps onto your workstations.

You may have to change the way you do anti-virus, inventory scans, software compliance checks, software deployment, patching, etc.  There are also challenges with performance and availability once you start sharing resources.

So, under no illusion should you be thinking VDI is a quick, easy and cheap solution, especially if you are going to be using pools of workstations. Doing VDI properly means you need to be able to change the way you currently do things.

Ask yourself some questions:

• Do you actually need VDI at all?
• Why do you need virtual workstations?
• What are your business drivers for this?
• Do you need full VDI or just some of it or just some VM workstations?
• Do you need remote access, automated deployment, different support, consolidation?
• Will VDI be cheaper / more expensive / the same?
• Are you doing VDI just because everyone else is?
• Is Windows 7 a driver for doing things differently?

So, let’s assume you do need VDI and can justify the time, effort and expense to put it in place. What are the challenges with scaling your virtual infrastructure specific to VDI?

VDI is first of all a numbers game. Think of how many servers you have or plan to virtualise? Do you have some figure in mind or been given a target of a percentage of virtual servers you want to get to? Looking forward do you already have or foresee a target for virtual workstations?

At the moment, you will almost certainly have less servers than workstations. Your company may have 5 to 6 times as many workstations as servers or even more. If you have 1000 servers and have or plan to virtualise 50%, that’s 500. If you have 6000 workstations and you plan to virtualise 50% that is 3000. Just simple maths tells you that in order to do this you will need a huge increase in your virtual hosting environment.

Yes you may say that servers are generally more resource intensive and that is often true but workstations are now requiring more and more. Windows 7 can immediately double the CPU and memory footprint per VM compared to XP. You could easily be looking at 2-4 Gb memory per VM workstation, that kind of resource is more like the resources you give to many of your VM servers. So, your VDI environment is probably going to land up being way bigger than your server hosting environment.

Often you don’t have a plan to create 1000 virtual servers in a month but a VDI project can easily require very large numbers in a short time. You don’t have the luxury of time to trend your resource utilisation and see what you may need. You have a budget allocated and need to ensure you can meet expectations. I told you it was hard!

Servers vs Workstations

Think of the difference between servers and workstations.

First of all servers generally have applications installed that are optimised to be efficient. They may be resource intensive but they are doing a lot. Many hours of development time have gone in to make your database server software, email software, web software, CRM software etc. pretty efficient. Servers also have predictable workloads that are pretty constant. You don’t normally have resource spikes that you can’t explain. You can model the performance required for your VM server quite accurately.

Contrast that with the applications you typically install on a desktop. Some may be efficient but many aren’t simply because they never really had to be when you weren’t sharing resources. Some applications you have to run may have been developed 10 years ago by a temp and are now critical to your business. It may have a memory leak or require a JVM as old as time. Some apps grab all available CPU or memory just in case they need it. The applications you may need on workstations are often not written with efficiency in mind. The workload running on a workstation is not as predictable as a server. Your clients may be using different applications at different times of the day and not in the same order. They may do a lot of browsing to buy Christmas presents on horrible flash sites that grab huge chunks of memory.

What do I need?

What you can and should be doing is trying as hard as you can to find out what your real workstation resource requirements are. If you already have a set of apps that you know your VDI clients will use, install them on a single VM or even physical workstation. Use Perfmon in log to file mode or some other fancy performance tool to have a close look at what the resource use is. Chart CPU / Memory / IOPS / Network for as long as you can. Best to even run it on 10 workstations. You can use your tool or even import the data into Excel and have a good at your resources over a week or a month and see exactly what your requirements are. This may help you also spot the resource hogs that you can work on now to reduce your requirements. Once you have your performance figures you can calculate what you need by scaling out rather than just guessing on figures.

Have a look at my previous post, How slim is your OS build? VDI’s biggest loser! for some information on making your OS more efficient.

When scaling out especially for VDI don’t attempt to squeeze your underlying hosts too much otherwise you will tip over the edge and affect performance. As VDI is not as cheap as you may be lead to believe, working out the costs you may be tempted to run every host at 100% to get maximum utilisation. In theory this is a good idea but due to the unpredictable workloads for workstations you can very easily find yourself running out of resources across every single host. An AV definition file update could cause extra CPU load or a software package update can create excess IOPS. This spread across your whole VDI environment can cause devastating affects and cause every single VM to slow down for possibly hours until the backlog is cleared. A very public, client facing, “VDI doesn’t work!” problem.

Who does what?

Another complication that happens with VDI is working out the boundaries of who does what.

Server people have historically been the people that look after the virtual hosting environment because they are the people who virtualised servers first. Now all of a sudden you have a massive workstation hosting environment managed by a server team who don’t really know about workstations. Server people do however think they know everything! This can causes problems often by simple lack of communication:

“Our VMs are running slow”

“You didnt’ tell us you were going to roll out a new version of xyz. That has brought down the whole environment including some of our servers which were on shared hosts”.

“We didn’t know we needed to let you know every little thing we were doing, normally we just go ahead and apply updates..leave us alone!”

Troubleshooting by finger pointing isn’t a good start!

Whoever looks after your virtual hosting environment needs to work far more closely with the people that manage your VDI workstations and pass on your years of server hosting experience to them. Workstation people aren’t used to doing IOPS calculations,  randomizing AV scans and working out how to solve boot storms.

VDI is also very client facing. If your server is running a little slow, your client may not really notice print jobs taking longer to process or emails being delivered with a small delay. If there’s a millisecond delay with screen refresh or mouse movements on your VDI workstations, someone is going to be picking up the phone to moan and that doesn’t look good for your VDI environment.

VDI is a big step and mustn’t be taken lightly. Do your benchmarking, be generous with your resource calculations. Ask the difficult questions, ensure your environment if big enough and plan that you can add extra capacity when you need to.

In Part 4, we’ll talk more about what questions you should be asking to design your infrastructure.