Tag Archives: Azure

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

PVS vs MCS – Part 7: Summary


As Q said in the final episode of Star Trek: The Next Generation, “All good things must come to an end” and after 6 previous blogs focusing on deciding between Provisioning Services and Machine Creation Services, it is time to end.

As I explained, over the past 5 years, improvements were made to Provisioning Services and Machine Creation Services.  While Provisioning Services simplified deployment and maintenance, Machine Creation Services improved performance and delivery capabilities.

Five years ago, if someone had to decide between the two, most likely the answer would be Provisioning Services.  But now in 2016, because of the overall improvements in both solutions, the decision will mostly focus on a few core concepts explained in the previous blogs:

Five years ago, I created a decision tree helping you select the most appropriate solution.  Developing these previous six blogs helped me do the same thing based on the latest advancements.

CompareDid I miss any criteria?  Let me know

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

 

 

PVS vs MCS – Part 1: Resource Delivery Options


This is part of a series comparing Provisioning Services and Machine Creation Services

Five years ago, Citrix released Machine Creation Services.  As a way to help admins decide between Provisioning Services and Machine Creation Services, I created a decision tree, breaking the decision across multiple requirements.

A lot has changed.

Provisioning Services changed.

Machine Creation Services changed.

You know what didn’t change?  Homer, Marge, Bart, Lisa and Maggie Simpson.

You know what else hasn’t changed? The decision tree.  It is old. It is outdated. It is no longer useful.

So my recommendation to you: STOP USING IT!

I want to look at the PVS vs MCS debate again based on the current technology.

I first want to look at the type of resources each platform can deliver.

Both imaging platforms are able to deliver virtual RDS and VDI workloads to XenServer, Hyper-V and vSphere.  The difference between the two lies in the ability to support physical and cloud-hosted workloads.

Provisioning Services, because it relies on network streaming of the master image, is able to deliver the image to virtual and physical endpoints. Imagine if you were in a school computer lab where every 45 minutes the class changed and the endpoint had to run an entirely new suite of software.  With Provisioning Services, we can quickly re-provision physical endpoints with the speed of a reboot.

Machine Creation Services, on the other hand, requires virtualization.  It communicates with the underlying hypervisor and deploys new virtual machines based off of a master image.  Not only does this approach allow one to run on XenServer, Hyper-V and vSphere, but it also allows Machine Creation Services to deploy virtual machines to the Microsoft Azure and Amazon AWS clouds.

If I put this into a simple to understand table, we would get the following:

PVS 1

Provisioning Services bridges the gap between the physical and virtual world.

Machine Creation Services bridges the gap between the on-premises and cloud world.

But of course, the similarities/differences are far greater than what type of resources each method delivers.  And we will get into more in future blogs.

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