Tag Archives: Sizing

Sizing XenApp Azure VMs


When we size XenApp virtual machines for an on-premises deployment, we often talk about larger servers and NUMA. But what about sizing XenApp instances if we host in Azure?

Azure has an extensive library of instances, with each instance providing different amounts of CPU, RAM, storage and GPU options. If we run the same scalability test across many of these types of Azure instances, we end up with the following density numbers.

Azure-Density

If we simply use these results as our guide, most of us would select the D13v2 instance as it gives us the greatest density. However, with cloud deployments, we need to did a little deeper.

Each Azure instance has a cost per hour. We need to divide this cost by the number of users the instance supports from our scalability testing. This gives us a price per user per hour

Azure-Costs

Quickly, we see that the A and D series instances cost the most, leading us to look at the Dv2 series as the cheapest option. Within the Dv2 series of instances, the D2v2 has a slight edge over other Dv2 instances. Take a look at D13v2. The price per user per hour is very close to the D2v2 instance, with only a difference of 2 cents per user per hour.

In an on-premises deployment, most of us would go with the larger sized instances (like the D13v2 instance) as this would cost less because we must include the costs of the Windows OS license; but in Azure, the cost of the Windows OS license is included in the instance cost per hour.

In addition, in an on-premises deployment, most of us keep all instances powered on at all times; but in a cloud deployment, we want to power off instances when not in use and power on when needed to help us keep costs low. Let’s see what happens to our costs when we scale up our Azure D2v2 and D13v2 instances with 1,000 users.

Azure-Scaleup

During scale-up, every time we power on a new Azure instance, we incur the full cost of the instance, regardless of the number of users. Because the D2v2 instances are smaller, we have more of them (67 in total), but the cost increases with a new instance powering on is smaller than the D13v2 (18 instances). As we continue to scale up to 1,000 users, the difference in costs over 24 hours between the D13v2 and D2v2 becomes greater.

But what about scaling down? In an effort to reduce costs, we want to power off idle instances (instances with no users). This gets even more interesting with XenApp because we cannot move user sessions between instances; we must wait for all users to log off of the instance before we can safely power off the instance. Unfortunately, users who log off are randomly distributed across all instances; preventing us from simply powering off enough to bring our total capacity down to 100 users.

What if in our 1,000 user scenario, most users (900 of them) would log off at 5PM. How many instances could we be able to power off because they are idle?

Azure-scaledown

Because we have so many D2v2 instances to support 1,000 users (67 of them in total), when 900 users randomly log off, we would be able to power off 15 instances, on average because they have no users. But with the D13v2 instances, we only need 18 instances to support 1,000 users. When we randomly log off 900 users, each one of the 18 instances still has active sessions, preventing us from shutting down any instances.

The savings with the smaller D2v2 instances quickly adds up.

Azure-costsperyear

Over the course of 1 year, by using the smaller D2v2 instances, our Azure compute costs are over $40,000 lower than the larger D13v2 instances even though D13v2 has almost 4x the scalability of the D2v2.

When planning a cloud XenApp deployment, we must focus on cost and not size.

Daniel (Follow on Twitter @djfeller)
Citrix XenApp and XenDesktop 7.15 VDI Handbook
XenApp Best Practices
XenApp Video

 

 

Advertisements

Sizing Windows 2016, Windows 2012 and Windows 10 Virtual Machines


It has been almost one year since Windows Server 2016 was released at Microsoft Ignite. Are the virtual machine sizing recommendations for Windows Server 2012R2 applicable to Windows Server 2016? And since we are talking about sizing virtual machines for XenApp and XenDesktop, it might be a good time to revisit Windows 10.

Let’s first look at virtual CPU allocation recommendations: Continue reading Sizing Windows 2016, Windows 2012 and Windows 10 Virtual Machines

XenServer PVS Accelerator Cache Sizing


How large should we make our PVS Accelerator cache? Too large and we waste resources. Too small and we lose the performance.

Let’s take a step back and recall our best practice for sizing the RAM on Provisioning Services.  We would typically say allocate 2GB of RAM for each vDisk image the server provides.  This simple recommendation gives the PVS server enough RAM to cache portions of the image in Windows system cache, which reduces local read IO. So for a PVS server delivering

  • 1 image:  we would allocate 2GB of RAM (plus 4GB more for the PVS server itself)
  • 2 images:  we would allocate 4GB of RAM (plus 4GB more for the PVS server itself)
  • 4 images:  we would allocate 8GB of RAM (plus 4GB more for the PVS server itself)

Easy.

Let’s now focus on the XenServer portion of PVS Accelerator. If we use RAM as our PVS Accelerator cache, how many GB should we allocate?

Continue reading XenServer PVS Accelerator Cache Sizing

Sizing XenApp Windows 2012R2 Virtual Machines


I guess I’m not done yet.

Last week, I posted the latest recommendations on sizing Windows 10 and Windows 7 virtual machines for a XenDesktop environment.  I received a few replies from people asking for any updates regarding Windows 2012R2.

Unfortunately, when we discuss Windows 2012R2 and XenApp, the recommendations are not as straightforward as Windows 10 and Windows 7.

  1. Because Windows 2012R2 will do session virtualization (where many users share the same VM but get a separate session) it makes sizing CPU and RAM more difficult.
  2. Because we can publish multiple resources from the same VM, we can have a mix of light, medium and heavy users on the same VM at the same time.
  3. Because each VM will host multiple users, our VMs will be sized larger when compared to Windows 10 and Windows 7. To size correctly, we need to align our recommendations with the nuances of the hardware.

Let’s take a look at the latest recommendations before we go into more detail.

Win12RwSizingvCPU

For vCPU, you notice it is based on NUMA.  What is NUMA?  I recommend you read these two blogs by Nick Rintalan.

  1. An intro to NUMA
  2. A Discussion about Cluster on Die

To summarize, you get the best physical server density when you have the same number of vCPU for your XenApp VMs with either the number of cores within a NUMA node or 1/2 of a NUMA node.  If you go with 1/2 of a NUMA node, then you will just have two times as many VMs.

Cluster on Die is a little more complex as newer hardware chips don’t have equal sized NUMA nodes across cores.  Cluster on Die is a BIOS option that balances cores equally by creating clusters of cores.

RAM

Sizing RAM is also a little different than when comparing it to Windows 10 and Windows 7. With session virtualization, like XenApp, all users share the same OS instance. Users also share the same application instances. The OS and app instances only consume RAM once. That is a huge reduction in overall RAM usage, which is why the RAM recommendations are significantly lower than the desktop OS.

Of course, the amount of RAM you allocate is going to be based on the specifics of your applications.

PVS RAM Cache

Just like with Windows 10 and Windows 7 recommendations, the PVS RAM cache is extremely valuable in a Windows 2012R2 XenApp environment.  With PVS RAM Cache, we see huge reductions in IOPS for Windows 2012R2.

Daniel (Follow on Twitter @djfeller)
XenApp Advanced Concept Guide
XenApp Best Practices
XenApp Videos

Sizing Windows 10 and Windows 7 Virtual Machines


After reviewing all of the scalability tests we conducted over the past few months, I thought it was time to revisit the recommendations for sizing Windows 10 virtual machines.  I also reached out to Nick Rintalan to see if this is in line with what is currently being recommended for production environments (if you disagree, blame him 🙂 ).

Win10Sizing

A few things you will notice

  1. Windows 7 and Windows 10 recommendations are similar.  Microsoft’s resource allocation for both operating systems are similar.  The Windows 10 and Windows 10 scalability tests resulted in similar numbers.
  2. Density – Experience: For some of the recommendations, there are 2 numbers. The first is if you are more concerned with server density and the second is if you are more concerned with the user experience.  What I find curious is if you have a heavy workload, are you as concerned with server density?
  3. PVS RAM Cache: Using the RAM cache will drastically reduce storage IOPS.  This will be critical to providing a good user experience and will be taken from the total allocated RAM.  The RAM column takes the RAM Cache numbers into account.
  4. Hypervisor: There is no hypervisor identified.  Testing showed minor differences between XenServer, Hyper-V and vSphere.

Daniel (Follow on Twitter @djfeller)
XenApp Advanced Concepts Guide
XenApp Best Practices
XenApp Videos

Sizing XenDesktop 7 App Edition VMs


In the Mobilizing Windows applications for 500 users design guide, we made the recommendation to allocate 8vCPUs for each virtual XenDesktop 7 App Edition host (formerly known as XenApp). Spreading this out across a server with two Intel Xeon E5-2690 @2.9GHz processors and 192 GB of RAM, we were yielding about 200 users per physical server and roughly 50 users per virtual server.

Of course, the design guide is the end result of a lot of testing by the Citrix Solutions Lab. During the tests, we had the Solutions Lab compare many (and I mean many) different configurations where they changed the number of vCPU, RAM size, and RAM allocation (dynamic/static) as well as a few other things. We ended up with the following:

A few interesting things:

  1. Dynamic vs static RAM in Hyper-V appeared to have little, if any, impact on overall scalability. The only time when the RAM allocation had a negative impact was when not enough RAM was allocated (no surprise there).
  2. The 8vCPU and the 4vCPU configurations resulted in very similar user concurrency levels. Get ready… The battle is about to begin as to whether we should use 8 or 4 vCPU. (Is anyone else besides me having flashbacks to 2009?)

A few years ago, we debated about using 2vCPU or 4vCPU for XenApp 5 virtual machines. A few years later, the debate is resurfacing but this time, the numbers have doubled: 4 or 8. Here is what you should be thinking about… VMs are getting bigger because the hardware is getting faster, RAM is getting cheaper and the hypervisors are getting better (Nick Rintalan provided a pretty good overview on some of the reasoning for this during his discussion on NUMA cores in his XenApp Scalability v2013 Part 2 blog). The whole point is that none of this is new. It has been going on for a long time and will continue to do so.

The hypervisor helped us reduce our physical footprint by allowing us to better utilize our physical hardware. Now, with better technology, we are able to reduce our virtual footprint because the technology is able to support larger VM sizes.

Daniel – Lead Architect