Windows Server 2008 R2 Service Pack 1: Microsoft Dynamic Memory

As promised, this week we’ll go through the improvements in Windows Server 2008 R2 Service Pack 1 with respect to “Dynamic Memory”. For the more technically-minded among you, I encourage you to bust out your reading glasses, and head over to read the epic six-part blog miniseries Jeff Woolsey penned recently.

Finished? Good.

Now that your eyeballs have glazed over from the technical wizardry, it’s time to focus on a high-level why Dynamic Memory makes sense for your business, and how it integrates well with RemoteFX and Microsoft’s Virtual Desktop Infrastructure VDI platform.

For businesses looking to move beyond the cycle of hardware upgrades, broken machines and increasingly quick obsolescence, Microsoft has two VDI routes. The first is the traditional Remote Desktop Services (RDS) route: for task-based workers who need four nines of uptime and a small set of predictable programs, this is a proven cost-reducer. What about your high-end staff who:

a) work on powerful machines
b) demand custom applications
c) don’t wish to be “stuck” in a locked-down environment?

The answer is the second VDI route: leveraging RemoteFX to provide graphical excellence, and Dynamic Memory to ensure performance remains as high as possible. Unlike the task-worker-focused RDS solution, where memory per-staff-member can be averaged across an entire server, traditional VDI solutions tend to dedicate memory for each machine they service. If you have 500 users in an RDS environment, with 64gb of memory, it will be spread amongst them all, and put back into the pool when it is unused. If you have 50 high-performing staff in a VDI pool, in the past, with each using up to 4gb of memory for particular tasks, you’d need servers with 100-200gb of memory. There goes your budget for hardware for the next two years…

Dynamic Memory solves this case by setting a minimum and maximum memory allocation. Instead of saying that all virtual workstations need 4gb of memory, you can start the allocation at a relatively Scroogish 512mb, and then allow it to scale up to 4gb if necessary. Thus, your 50 users begin by using 25gb of memory, and you could easily get away with a mere 64gb of memory on the server itself.

Of course, you’re next thinking: what happens if every user begins to use 2gb of memory, and you break through the 64gb barrier? The answer explains the difference between “Dynamic Memory” and the alternate solution, “Memory Overcommit”, that many other virtualization providers have been promoting for years.

Memory overcommit simply looks for areas of memory that are similar and caches them. In an x86 environment, this frequently provided large performance gains as many virtual workstations might share the same address space. As desktops have upgraded to x64 bit computing, security concerns have forced the operating system to randomize the memory space, reducing the performance gains to a low amount. At the same time, when client workstations begin to run low on disk space, Memory Overcommit (having no knowledge of the types of memory inside each client workstation) will begin to page memory to the much slower disk subsystem. This reduces in dramatically lower performance for client workstations across the board: even workstations that aren’t performing high-memory intensive tasks may see their performance suffer.

By contrast, Dynamic Memory *is* aware of which client workstations are increasing their memory utilization. If a client with 512mb of memory needs to use 1gb of memory, the client operating itself pages the request “to disk”. Because the request is going “to disk”, the host server can choose whether to store those requests in memory (fast) or to move them to an actual physical disk (slow). As long as the server has free memory, it’ll use the faster method, resulting in increased performance. But if the server is out of memory, the virtual workstations who are causing the stress will be the ones who are forced to page to disk, ensuring that workers who keep their memory utilization low won’t see any decrease in performance.

This is exactly the reaction you’d expect, and mirrors the real-world. If a person uses their physical machine to run a computationally intensive task (some photo manipulation filters, perhaps) it will slow their machine down, but others won’t be affected. Now in the virtual world, we can recreate that equally fair system. Best of all, with RemoteFX, many of the graphically intense actions can be offloaded to a built-in graphics card, ensuring that even if a workstation is using relatively little *memory*, but is using more than their fair share of processor cycles on a task, other staff won’t be affected.

The best part is the cost-performance and the ability to scale. Instead of supporting 50 high-end workstations, with 50 different types of memory, 50 different graphics cards and thousands of different ways for the machines to fail, you can use existing legacy hardware, with fairly underpowered specifications, to merely connect to the VDI server itself. If your machine breaks, you can log into another and immediately begin working with no downtime. In the past, each stick of memory you purchased for a workstation was unused while the machine was off, or the staff member was out on vacation. Now, by consolidating the memory in the server, you can make a strong argument for when your server is over 80% utilization, that you need to purchase more memory.

If you’re interested in moving your highest performers into a highly-productive virtual environment, get in touch with New Signature to see how we can save you money *and* increase reliability and performance.