Tag Archives: design considerations

PVS or MCS – What’s Your Decision Going to Be


Note: This blog is in reference to Citrix XenDesktop 5.0 ONLY.

Note: The following link contains the  latest discussion between PVS and MCS (https://virtualfeller.com/2016/05/17/pvs-vs-mcs-part-1-resource-delivery-options/)

The decision between using Provisioning Services or Machine Creation Services is based on many things, with a few being discussed previously:

  1. Big Picture
  2. Operations
  3. Resource Requirements

Let’s say you’ve gone through these discussions and are still trying to determine what approach you should take. Personally, I like to use decision trees, like the following:

By answering these questions, you will get a better idea of what is most appropriate:

  1. Hosted VDI Desktops Only: Larger enterprise environments are often more complex, in terms of end user requirements. The complex user requirements cannot be completely met with Hosted VDI desktops, which require the organization to expand into different options. Using Provisioning Services for these architectures is recommended due to the ability to deliver images more than Hosted VDI desktops.
  2. Dedicated VDI Desktops: If there is a user requirement for dedicated desktops, there is an increased recommendation to use Machine Creation Services or to use installed images.
  3. Large Boot/Logon Storms: Boot and logon storms create massive IO activity on the storage infrastructure, requiring greater levels of IOPS. For larger deployments with a large boot/logon storm, Provisioning Services is recommended due to IOPS savings.
  4. Blade PCs: Certain users require the performance of a Blade PC, while still secure within the data center. Because Blade PCs are standalone hardware devices, Machine Creation Services cannot be used.
  5. SAN: Provisioning Services has the flexibility to work with and without a SAN infrastructure. However, Machine Creation Services becomes more challenging without a shared storage infrastructure, like a SAN. If a shared storage solution is not in scope or is too costly for the environment, Provisioning Services is a better option.
  6. Change Control Processes: Maintaining Provisioning Services desktop images requires proper processes depending on the type of update required (hotfix versus network driver update). Smaller environments will most likely not have processes in place. Maintaining a Machine Creation Services image is often seen as easier.

What did you come up with? Surprised? Or is it what you expected? If you want the full breakdown on deciding between the two options, then please refer to the recently released version of the “Planning Guide: Desktop Image Delivery” which was recently added to the XenDesktop Design Handbook.

If you are new to the handbook, then I suggest you read about it from Thomas’s blog discussing how to get the handbook for offline use.

Daniel – Lead Architect
XenDesktop Design Handbook

Advertisements

XenDesktop 5 Scalability – Site Capacity


When we last looked at XenDesktop 5 scalability, we really focused on the user experience in that users should not be required to wait longer than 2.5 seconds before the system responded to an authentication or launch request. We said that if the controller got very busy due to logon storms, we could add additional controllers to help lower the overall load and get us back to that 2.5 second goal. But guess what? The 2.5 second goal might require that we look at other aspects of the XenDesktop 5 architecture beyond the controllers. We already looked at the maximum size of a XenDesktop controller, so th next thing to look at is how big can a XenDesktop 5 site become?

We can keep adding controllers, but won’t we eventually hit a site limit? If the controllers “talk” to the SQL Database for pretty much every transaction, we want to make sure that the database server is designed appropriately to support the storms. We could easily run into an instance where the controllers are functioning well below thresholds, but the user experience is still poor. We need to take a look to see if we allocated enough resources to make sure that the SQL database is not bogged down.

The SQL Database is the heart of a XenDesktop 5 site. Here’s the good news… Databases are built for transactional type processes, and that is what XenDesktop 5 is using the SQL Database for. We should be able to see some crazy scalability numbers and with testing being conducted, we are.

For example, I’ve seen one test that simulated 20,000 logon connections in 13 minutes (25 new requests per second). An 8 core, 16GB RAM dedicated SQL Server consumed 32% CPU utilization. This is a fairly sizable logon storm. Even if you extrapolated this out, you should be able to get an insane size of a single XenDesktop site. I haven’t seen anything in production at this size yet on XenDesktop 5, but things are looking very promising.

As you would expect, once you are running, you need to monitor the database server (especially if you are sharing this database with other database or services). At a high level, focus on the standard items:

  • CPU
  • Memory
  • Disk

If you need to drill down more, due to performance issues, this is when you need to be looking closer at the SQL Server metrics:

  • Buffer manager
  • Memory manager
  • Statistics

Daniel – Lead Architect
XenDesktop Design Handbook

PVS or MCS – We Talking About IOPS Again


Deciding between PVS and MCS is a tough decision for many organizations. Although MCS is limited in that it can only do virtual machines, it does appear to be easier to setup than PVS. In fact, MCS just works while PVS requires another server and configuration of bootstrap processes like TFTP/PXE. So it sounds like we should be using MCS for everything. Right? Not so fast. We need to look at the resource requirements, beyond servers, as this might negate the benefit of easier setup/configuration.

If you’ve gone through the other two discussions so far, we focused on the Big Picture of your environment and the operational model. This time, we are focusing on resource requirements.

First, we know that using PVS will require, at least, 2 additional servers (remember I’m including fault tolerance). MCS doesn’t require any extra hardware besides the hypervisor. Now let’s look at storage requirements, and with storage I’m talking about IOPS, our favorite topic.

If you look at PVS, we do all reads from one location and do all of our writes on another location. Because of this, we can optimize the systems. We know that on the PVS server, we allocate enough RAM so the reads happen in RAM and not disk, thus greatly reducing read IOPS.

MCS is different. The reads and writes happen on the same storage. This is a big deal. Look at the graph below.

We know that during desktop startup, we have a huge amount of read IOPS, during logon, it is evenly split, and during the steady state (working), the ratio moves towards writes. Most people are concerned with the boot and logon storms. Because these are more read intensive, you would think that PVS would be the better option for large boot/logon storms as we cache the vDisk in PVS RAM. This line of thinking is correct.

Now before people say, “Hey, my SAN can cache”. You are correct. Of course there are SAN caching solutions, but these cost money. With PVS, it is just part of the Windows operating system. Because of this, we can see a MCS implementation generating more IOPS than a PVS implementation. How much more? I’ve seen as much as 1.5X more IOPS. For deployments with 50 desktops, this might not be a big deal, but what if you are talking about 20,000 desktops?

Some might be thinking about using XenServer IntelliCache to bring these more inline. This has a potential to help lower MCS IOPS requirements, but the products aren’t integrated yet, so I’ve got no data points to share.

But regardless, you need to take the resource requirements into consideration before making your PVS/MCS decision.

Daniel – Lead Architect
XenDesktop Design Handbook

XenDesktop 5 Scalability – XenDesktop Controller Capacity


Think about the architecture of XenDesktop 5. One of the core components responsible for an acceptable user experience during the initial authentication and launch of the virtual desktop are the controllers. If these controllers get overloaded, it will take users longer to launch their virtual desktops. What is acceptable is based on the users and their requirements. But for this example let’s say when we hit the icon for the virtual desktop we expect a response within 2 seconds. How many controllers do I need for 5,000, 10,000, 15,000 or even 20,000 users? It really boils down to the logon storm and the controller hardware. The more powerful your hardware is; the greater of a storm a single controller can tolerate.

But what is the bottleneck when you need to add a new Controller? CPU is the easy one. How heavily loaded are the CPUs. As the utilization increases, the time it takes to handle logon requests will slow down to a point where users notice. So what about the user experience? We want to make sure the system responds to user requests in a timely manner. How long are your users willing to wait for enumerations or launches? I typically see 2 to 2.5 seconds is a safe estimate. I suggest you track the following metrics:

Citrix XML Service

  • Enumerate Resources (Avg Transaction Time)
  • Launch Get Address (Avg Transaction Time)
  • Get Logon Ticket (Avg Transaction Time)

As this reaches your own threshold, it is time to think about adding a new controller, which will help offload the controller.

Adding a new controller to XenDesktop 5 is much easier than previous versions. In XenDesktop 5, each controller is identical (unlike XenDesktop 4 where we did all sorts of crazy things to get the most desktops per farm). So as your CPU increases and your response times slow, add a new controller into the site and the load is distributed evenly.

Estimates are always good, but as with all estimates, your own experiences will vary:

  • In one test, a single controller with 8 CPU cores was able to support 10,000 logons in the course of roughly 15 minutes (roughly 11 simulated users per second) averaging about 50-60% CPU utilization.
  • In another test, a single controller with 2 vCPUs was able to support 1,250 logons (roughly 40 users per minute) resulted in an average of 12% CPU utilization.

So what does this all mean? For XenDesktop controllers, the scalability is better than what we saw in XenDesktop 4. And because we are not constrained by a master controller like we were in XenDesktop 4, our XenDesktop 5 sites can be even larger than before.

But this isn’t the end of planning your capacity with XenDesktop 5. There is still much to discuss so stay tuned for more.

Daniel – Lead Architect
XenDesktop Design Handbook

PVS or MCS – Operations Is Important


As we continue to decide between using Provisioning Services or Machine Creation Services in an environment, we need to go beyond the Big Picture factor explained in a previous blog. The second thing we should look at is the operational aspect of the solution. Operational models are rather boring. Who cares about supporting the environment? Well, the users will care and so will you.

First, both models require you to have an operational model in place so you can maintain the base desktop images. We all know Windows 7 Service Pack 1 is coming. How will you update your virtual desktops? This is what the operational model should define.

With Machine Creation Services, the update model is fairly easy. You start your master VM. You install the updates. You shut down. And you use Desktop Studio to push the updates out to all of your pooled desktops.

Provisioning Services is a little different. With PVS you will want to make a copy of the vDisk image. You need to put it into Private Image mode. You need to boot and install the updates. Turn it back into standard image mode, and then run the update command within the console. It doesn’t sound too daunting and it really isn’t. The challenge comes into play when you have updates that impact the connectivity to the Provisioning Services server.

Think about what happens for a moment. You need to update your image. The update impacts the network connection, disabling it for a moment before enabling it again. This is really no big deal unless you NEED the network to continue processing desktop operations. With a PVS streamed desktop, if the network fails, the desktop pauses until the network is restored. If the update disables the network, the desktop pauses. The update will NEVER continue because the desktop is paused.

These types of updates can be done with Provisioning Services, but it requires the team to follow proper processes to prevent issues. Just another consideration to take into account when deciding between PVS and MCS. Stay tuned for more.

Daniel – Lead Architect
XenDesktop Design Handbook

Provisioning Services or Machine Creation Services… Big Picture Matters


Note: this is the first part in a multi-part discussion on PVS and MCS

Since XenDesktop 5 came out, one of the biggest questions flying around is, “Should I use Provisioning Services (PVS) or Machine Creation Services (MCS)?” Both options work and both options provide single image management, but what is the right answer?  Is it shocking that this question is the wrong question to ask?

What you should be asking is “What is my desktop virtualization solution going to look like?” Are we only doing Hosted VDI desktops? Do we need Local VMs? Are Hosted Shared Desktops in the mix? (Note: look at the Citrix FlexCast site for a description of each option). Each organization’s desktop transformation roadmap plays an important role in picking the right option. The following diagram was taken from the XenDesktop 5 Reference Architecture, which can be found in the XenDesktop Design Handbook.

One thing you should be able to see is that if you select Machine Creation Services, you can only do the Hosted VDI desktop model on a hypervisor (XenServer, Hyper-V or vSphere) in the data center ONLY. That means no Blade PCs. It means no Hosted Shared Desktops. It means no streamed VHDs. If this is your roadmap, then Machine Creation Services is still a viable option, but the decision cannot be made yet. You still need to look at a few other considerations like SAN requirements, storm impacts, imaging team expertise, etc. before you can make a proper decision, which will be discussed in future blogs.

But what if your design calls for some of these other FlexCast options? Then Provisioning Services will definitely play a major role. However, there still might be a need for a mixed imaging solution based on a few other decision factors. For example, what if you need a desktop where users have complete control of the desktop to install applications or make operating system-level changes that are not captured in profile management tools? I can still do Existing, Physical, Dedicated and Streamed desktops. However, would you use PVS for this (streamed desktops)? It does work, but you probably won’t go with this option. In my experience, using a private desktop model with Provisioning Services is not efficient. It requires complete copies of the base image, configured for private (read/write) mode. You still have to manage these images in a 1:1 fashion (or use an enterprise desktop management tool). You are essentially adding too many layers where other options might be a better fit.

Why not use an Existing, Physical or Dedicated desktop, which relies on either installed images or MCS? If I go with installed images, I need to either install them one-by-one or use cloning solutions like SysPrep. If I use MCS, unique identities are built into the solution. MCS makes the deployment easier than the Existing or Physical desktop model, but they both work. What does this all mean? If you use multiple FlexCast options with private desktops, you will end up using [PVS + (MCS or Installed)]

You don’t want to focus on which technology to use, you want to focus on the overall architecture, which will help guide your decision. But the decision is based on more than the big picture. You need to stay tuned for more on this topic as this isn’t the end yet. We still need to dive deeper into the Hosted VDI Desktop model only scenario to align our business requirements with the appropriate solution.

Daniel – Lead Architect
XenDesktop Design Handbook

Planning the XenDesktop 5 Database


With XenApp and previous versions of XenDesktop, the database was just the storage repository for static information. We really didn’t spend much time thinking about the impact of the database on production environments. The databases were small. They databases didn’t have a big impact on the underlying system. So what about XenDesktop 5’s SQL Database? Let me just say that the database is now the King.

What happens if you don’t plan your database appropriately? How about this:

  1. You run out of disk space
  2. You have a XenDesktop environment that fails
  3. You have poor enumerating and launching performance

I’m not trying to be an alarmist, but I want to make sure that everyone doing a XenDesktop 5 design spends enough time focusing on the importance of the SQL database instead of brushing it aside like we all did in previous versions.

Let me give you some stats to help you understand how the database might impact you. First, you must understand that the database contains all of the information about the XenDesktop site. It knows who is logged in, where, how long, resources in use, desktop states, etc. Anytime something changes within the site, the database is updated. Plus, in order to validate that the previous information is correct, there is a constant heartbeat within the environment. This helps provide a better fault tolerant infrastructure. But this comes at a price. Let’s run through a few examples:

  1. A XenDesktop site with 20,000 defined desktops will consume 250MB of space within the database.

This isn’t very large and shouldn’t bother us too much… right? True, the database is small, but what about the transaction log?

  1. Ten defined desktops in a site are idle for 24 hours will consume 14.5MB of space in the transaction log

Now that is interesting. Multiply this by 20,000 desktops and your transaction log for 24 hours (idle) is 29GB!!!! Hopefully that caught your attention. But all is not lost. You can use the “Simple Recovery Method” in your database configuration to keep the file small, but you do lose the ability to do SQL Mirroring. If you want to mirror, just do more frequent full backups of your database, which will also help to keep the transaction log small.

The point is you don’t want to be caught off guard with a SQL Server out of disk space. You can manage the transaction log, but you have to be smart about it.

If you want to know more, check out the Planning Guide: SQL Database in the XenDesktop Design Handbook. This is a great article you want to be aware of.

Daniel – Lead Architect