Monthly Archives: October 2013

Uncategorized

Sizing XenDesktop 7 App Edition VMs

Leave a comment

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 Follow @djfeller

Advertisements
Uncategorized

Just the Apps

Leave a comment

We get so excited with the thought of VDI, we often forget to take a step back and focus on what we are trying to do. Here is a recent example…

We need to find a way to get an application to our users. Our first problem is that many of our users are not local, which makes installation a challenge. The second problem is that many users want to use the application on non-traditional devices (tablets) because it is more convenient. We’ve heard that VDI can help us with this. What will it take?

First, this is a good question, but unfortunately, the person has already decided on a solution without understanding what is possible. I can’t blame the person for already believing that VDI is the right answer because the marketing teams that are focused on VDI have done a great job blanketing us with the VDI message. And unless you are knowledgeable about the functionality with different products, you might miss the nuances and buy something you weren’t expecting.

If I were to make a recommendation with this particular customer, I would steer them to XenDesktop 7 App Edition (for those of us who have been around for some time, I’m referring to XenApp), which basically delivers an application to a user instead of the entire desktop. This solution aligns closely with what the user needs.

But what will it take for 500 users? Not much… just three physical servers using two Intel Xeon E5-2690 @2.9GHz with 192 GB of RAM.

Of course many will think this is all theoretical. But to prove this isn’t simply fairytales and unicorns, we built, tested and validated this Design guide to mobilize windows apps in the Citrix Solutions Lab (I will provide more gory details in a future blog).

When we go through the numbers and incorporate it into our 5-layer conceptual model, we get the following (Read about the XenDesktop 7 blueprint to better understand the 5-layer architecture).

This solution gets you the following:

  1. Delivery of almost any Windows-based application to any endpoint to any location without requiring the application to be rewritten for the numerous types of endpoint device types and form factors.
  2. Traffic is protected within SSL as it crosses over public network connections with NetScaler Gateway
  3. An environment, capable of supporting 500 concurrent users, with only 21 virtual servers (Note that VDI would require over 500 virtual machines).
  4. Most importantly, the entire environment is using standard local storage. There is nothing special about the local storage as each physical server includes (8) 300GB SAS drives spinning at 15,000 RPMs configured with RAID 10.

Of course this is just conceptual, so what does the physical architecture look like?

  • 3 physical servers required to support 500 users, with each RDS host supporting roughly 50 users. If more users are required, another server is added resembling the “Server 3” config. We don’t have to worry about scaling the Access and Control layer components for some time as they have low utilization.
  • Three different VLANs for DMZ, VM, and Management traffic. I know some of you will point out the risk with putting the NetScaler Gateway VPX on internal servers and having the VLAN for that VM go to the DMZ. Depending on the size and complexity of your infrastructure, this might be a non-issue as long as you have the proper configuration and lockdown procedures.
  • Access Layer and Control Layer configured with N+1 availability in that if one component fails, a secondary component is available to take over the load.

When trying to decide what to do in your own environment, remember to look before you leap.

If you want to read the entire design, check out the Design guide to mobilize windows apps

Daniel – Lead Architect

Follow @djfeller

Uncategorized

It all comes down to the hardware layer in the XenDesktop 7 blueprint

Leave a comment

Sometimes, the things we learn early in life teach us the basic fundamentals we need in the future. Many of us probably had toys like this growing up or have them for our own kids.

Of course there are some out there who will say that they can get the square peg into the round hole if the beat the hell out of it. This is true, but you waste a lot of energy as well as probably damaging the peg and hole.

This simple concept of properly matching objects together fits with the final layer of the XenDesktop 7 blueprint.

So far, the blueprint has been mostly conceptual. The hardware layer takes the conceptual and turns it into physical. The hardware layer has us think about the storage fabric, server footprint and VM allocations.

But just like the block toy, we have the same situation occurring within the hardware layer. We need to properly match hardware technologies together.

Think about storage fabric and server footprint for a moment.

With storage fabric, I can choose either local, direct attached or centralized storage, while server footprint lets me opt for either rack mounted servers or blade servers. These two decisions, although separate, are tightly coupled, just like our block toy.

The type of storage fabric you select will have a dramatic impact on the server footprint, and the server footprint you select will also have an impact of the storage fabric.

Let’s say you want to go with blade servers for some reason. Although at first glance it would seem like I can go with either local or centralized storage, this is not truly the case. Due to the physical space limitations with blade servers, I will most likely only be able to support two disk spindles per blade. So although I could use local storage for desktop virtualization when using blade servers, I’m trying to force a square peg into a round hole.

What if we go with rack mounted servers (round peg) and centralized storage (square hole)?

Guess what? You can fit a round peg into a square hole, but you have unused space. It doesn’t fit perfectly. And that is exactly what we have with rack mounted servers with centralized storage. You can do it. It does work. But it typically isn’t the optimal solution, whereas local storage with rack mounted servers seems like a much better fit.

Depending on what you choose might impact the hardware you are capable of running. For example, if you chose local storage, you will have problems trying to run your environment with blade servers. Why? Because you only get 2 disk spindles. Not enough to handle the storage requirements for a virtual desktop solution (unless you add on storage optimization technologies.)

These two decisions helps us adding details to our architecture:

Blueprint

Of course the next part of the hardware layer is to start calculating how many physical servers you need and how much storage is required, which is a discussion for another time. But for now, we have the framework for our complete solution.

Uncategorized

Control layer in the XenDesktop 7 Blueprint

Leave a comment

Control, control, you must learn control! – Yoda

The control layer is about creating a single, cohesive foundation for the solution that supports the user-layers (users, access and resources).

091113_1305_Doyouhaveyo1.png

You can NOT do the control layer if you haven’t defined your user layer, access layer and resource layer. The control layer of the XenDesktop 7 blueprint is subdivided into

  1. Access Controllers – responsible for providing the connectivity to the resources as defined by the Access Layer
  2. Desktop Controllers – manage and maintain the virtualized resources for the environment
  3. Infrastructure Controllers – standard infrastructure components

The point of the control layer is to define what and how many servers/devices you need to support the user layers. This is based on the size of the user groups as well as the overall design for those user groups.

The first part of the control layer focuses on the access controllers, which should not be confused with the access layer. The access layer defines the access policies, which are associated with each user group. The access controllers are the devices that allows you to implement those policies. If all of your users are local and you do not require a remote access policy, then there you will not require a NetScaler Gateway access controller.

The second part is on the desktop delivery controllers. The delivery controllers make sure you are assigned to the right resource. They make sure the resource is ready. And they make sure the resources are updated appropriately. With XenDesktop 7, this bucket of controllers was reduced in size. You will no longer see XenApp controllers (zone data collectors) because the “XenApp servers” in XenDesktop 7 utilize the same framework. This means XenDesktop users and XenApp users rely on the same desktop delivery controller!

And finally, the last part of the control layer deals with the other components, the supporting cast of characters which includes database servers, licensing server and hypervisor controller servers (vCenter, SCVMM, XenServer) Note: XenServer doesn’t really have a dedicated controller like vSphere and Hyper-V.

When we update the conceptual architecture to now include our control layer, you get the following:

As you see, almost everything begins with 2 instances so that we have some level of fault tolerance in that if one instance fails, we have a second instance to handle the load. Licensing only has 1 instance because there is a built in 30 day grace period, so who cares if it fails. You got 30 days to get licensing running again before users notice.
Daniel – Lead Architect

Follow @djfeller