Blog Archives

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

About these ads

Just the Apps


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

Blueprint for Accessing your desktops and apps


Based on the XenDesktop 7 Blueprint, we have already created a definition of our user layer. The next step is to define how users will access their environment. Just like a house, you have doors and locks. In order to gain entry, you have to have the right keys for the right door.

Defining the access layer is basically focusing on the required access policies for internal vs. external users. What’s an access policy? It is simply defining the following 4 items:

  • Authentication point: Where do users first enter their credentials. Typically, this is either StoreFront or NetScaler Gateway.
  • Authentication policy: How many and what type of authentication must users provide before access is granted. Username, password, RADIUS, etc.
  • Session policy: Will different devices receive different levels of access? Some people want to provide a different access experience based on their device being either mobile (iOS, Android or Microsoft tablets and phones) or non-mobile (such as Windows, Mac®, Linux). In order to do this, the NetScaler Gateway must be able to determine the endpoint device type. This is accomplished by using the following expressions:
    • Mobile Devices: The expression is set to “REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver” which is given a higher priority than the non-Mobile device policy to ensure mobile devices are matched while non-Mobile devices are not.
    • Non-Mobile Devices: The expression is set to “ns_true” which signifies that it should apply to all traffic that is sent to it.
  • Session profile: What network connection will users be granted: Full VPN or ICA Proxy. Full VPN provides the endpoint with full access to the internal network while ICA Proxy only allows the ICA protocol access.

As you can imagine, there are many options for these 4 items, but here is what most people use

Users connecting from… Local, trusted network Remote, untrusted network
Authentication Point StoreFront NetScaler Gateway
Authentication Policy Simple authentication

(username and password)

Multi-factor authentication

(username, password and token)

Session Policy Not applicable Mobile and Non-Mobile
Session Profile Not applicable ICA Proxy

And with this, our diagram continues to evolve

We have now included the following:

  • User group location
  • User group end point device
  • Full Access layer communication
  • NetScaler added as an Access Controller in the Control Layer

Stay tuned for the Resource Layer…
Daniel – Lead Architect

Do you have your XenDesktop 7 Blueprint?


Here is a little secret… Most XenDesktop environments are extremely similar. In fact, if you ignore the numerous hardware combinations out there, the similarities increase greatly.

You have user groups (some internal and some external) that need access to some type of resource, whether it be a desktop or an application, which is supported on a standard set of controlling components all running on some type of hardware combination.

So why is desktop virtualization so complex? Because we made it that way by believing that every deployment must start from scratch.

Think about if you were going to have a house built. You would start with a high-level blueprint. The first thing you do is figure out what type of house you want built: a rambler, split level, 2-story, etc., but it will have the same fundamental components (HVAC, electrical, plumbing, framing, roofing, etc). However, the first things you think about shouldn’t be the electrical wiring. It would be insane to start here because you don’t even know where the walls are going to be located that will contain the wires. So tell me why when doing desktop virtualization do people start with storage or servers?

This is why we have a XenDesktop 7 blueprint. To guide you on your way towards creating a desktop virtualization solution, every XenDesktop 7 solution has 5 parts:

1. User Layer – Defines the unique user groups and overall requirements.

2. Access Layer – Defines how each user group will gain access to their resources with a focus on secure access policies and desktop/application stores.

3. Resource Layer – Defines the virtual desktops and applications assigned to each user group

4. Control Layer – Defines the underlying infrastructure required to support all users accessing their resources

5. Hardware Layer – Defines the physical implementation of the overall solution

This is the framework to understand how all layers build upon the previous layer. When you begin to develop your solution’s conceptual architecture, it begins to resemble the following:

As we work through the layers in future blogs, we will see how this structure will take shape and what decisions you really need to make.

Stay tuned…
Daniel – Lead Architect

True or False: Citrix Provisioning Services requires PXE


Test your Citrix knowledge…

True or False: Citrix Provisioning Services requires PXE

Answer: False

When using Provisioning Services, which is an optional component of XenDesktop, the target device utilizes a bootstrap file, which initializes the Provisioning Services stream. The target device must be able to obtain that bootstrap file, or else the stream will never begin.

Unfortunately, I still hear people saying that the only way to accomplish this is with PXE, which is incorrect.

Provisioning Services has a few different options for delivering the bootstrap file (these have been the most common approaches for many years):

  1. The DHCP Method:
    Target device boots and sends DHCP discover broadcast
    DHCP server responds with a client IP, Option 66 & 67
    Target device uses the IP and contacts the server identified in Option 66 requesting the file from option 67.
    The PVS server sends the requests bootstrap file via TFTP to the target device.
  2. The PXE Method:
    Target device boots and sends DHCP discover broadcast with Option 60 PXE Client
    DHCP server responds with IP
    PVS Servers, which are running PXE Services, respond with Boot Server
    Client uses the IP and picks one of the PVS responses and requests more information
    PVS responds with boot server/file name information
    Target device contacts the boot server and requests the file name.
    The PVS server sends the requests bootstrap file via TFTP to the target device.
  3. The Local Method: An local file is created with the Boot Device Manager, a component of Provisioning Services. The local file is the bootstrap file, which tells the target how to contact the Provisioning Services farm. It is assigned to each target device either as an ISO attached to the target deices DVD drive, a USB drive, or as a small attached virtual hard disk drive.

It is a pretty good mix of organizations opting for DHCP or Local, much less using the PXE method. Both work, but DHCP and PXE requires more integration with your current environment than the Local method.

Daniel – Lead Architect

Follow

Get every new post delivered to your Inbox.

Join 467 other followers