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:
- 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.
- Traffic is protected within SSL as it crosses over public network connections with NetScaler Gateway
- An environment, capable of supporting 500 concurrent users, with only 21 virtual servers (Note that VDI would require over 500 virtual machines).
- 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
How many of you have migrated to Windows 7? If the company you work for has, I bet there are a host of applications that are not compatible with Windows 7 (although Win7 is much better at app compatibility than Vista). So what options do you have? . Let’s say your application worked fine with Windows XP, does that mean your users need XP and Windows 7 desktops? Unfortunately, I’ve seen too many people end up with multiple desktops at their desk. Not sure about you, but it seems like a waste to have two desktops for a simple issue as application compatibility
No. The user can still use Windows 7 and with a little Citrix-Magic in the backend, you can merge everything together.
First, let’s get the application working. We know it works on Windows XP, but let’s see if it works on Windows Server 2003 with XenApp. If it does we can get better scalability by having many users share the XenApp server instead of allocating many Windows XP virtual desktops. Just so you know, this is what I call Hosted Applications: applications that run remotely on a XenApp server.
If the application doesn’t’ work on Windows 2003, you can go down the VM-Hosted Application path. This uses a Windows XP operating system to run the applications. But the user will not see the Windows XP desktop, they only se the application. So when the user is on a Windows 7 desktop, they can still get to their XP-based applications seamlessly, which is critical. You know how confusing it is to have two start menus?
What does the user see is an important question. The user will see, if using Citrix Receiver, application icons for all of their applications in the start menu. Launching an application could either launch a local app, a hosted app, a VM-hosted app or maybe even an App-V app. The user won’t know, and that is how it should be.
Debating on which path to take? Think of it this way:
- XenApp option gives you much better scalability and the majority of application work
- VM-Hosted Apps should work for every application that worked on a physical Windows XP desktop
I recently posted a blog focusing on the resource requirements for hosted VM-based virtual desktops. These are realistic numbers and should make you wonder if the hosted VM-based virtual desktop is the most appropriate solution for all four user categories. What I found interesting was I had another blog identified as a follow-up talking about if the hosted VM-based desktop model made sense for all of the defined user groups when I started to receive emails, blog comments and twitter comments expressing the same concerns. This is great! That means many more people realizing that desktop virtualization does not always mean the hosted VM-based desktop model.
Let me explain further. As a refresher, we typically break down users into one of four groups defined as follows:
|Light||One or two applications no browser-based activity|
|Normal||Multiple applications with limited browser-based activity|
|Power||Many simultaneous applications with extensive browser-based activity and Internet-based applications.|
|Heavy||Few applications but have heavy system resource requirements. Data processing, compiling, or graphics manipulation are common applications.|
Of course as you move up the levels so too do the requirements for the hosted VM-based virtual desktop. But does it really make sense to have our light users running on the hosted VM-based desktop model? For light users, we typically define the following in terms of resource allocation:
|User Group||Operating System||vCPU Allocation||Memory Allocation||Avg IOPS (Steady State)||Estimate Users/Core|
|Light||Windows XP||1||768MB-1 GB||3-5||10-12|
|Windows 7||1||1-1.5 GB||4-6||8-10|
Is this crazy? Why does a user who only runs 1 or 2 applications, which are most likely line-of-business applications, require a hosted vm-based desktop environment? If you then go back to our high-level recommendations on application integration, you will see that many line-of-business applications are better served as applications virtualized on XenApp. This isn’t because desktops can’t run the applications; it is because many line-of-business applications are complex, have many dependencies, require extensive configurations. Hosting these applications on XenApp is something that has been successful for years and virtual desktops do not change that fact.
Many of the issues we’ve seen with organizations running hosted shared desktops in the past is that it doesn’t look or feel like the desktop OS. That was then, this is now. Windows 2008 can look like Windows 7. Challenge solved.
Many organizations struggle to justify transforming their desktop environment due to the costs associated. I agree, there is a cost, but the cost can be significantly reduced if you don’t go in blindly. If we use the hosted shared desktop model for our light user loads, we can save. Think about it this way, every light user will need 1-1.5GB of RAM for their hosted VM-based desktop session. Of that amount roughly 768MB of that will be just for the OS. Why does each one of the users require a full-fledged desktop OS? If we share the desktop across 100 users, we save almost 8GB of RAM. It doesn’t sound like much but what about 1000 users or more? And we haven’t even begun to discuss the impact on storage for these users.
So far we are only looking at the OS requirements; what about the application RAM requirements? Because the resources are completely shared, if the application requires 200MB to run, a large percentage of that amount can be shared across all users, helping to reduce the overall RAM requirements (and many Line-of-business applications I’ve seen, including the dependencies, need way more than 200MB of RAM).
So what is my point in all of this? Just because you are looking at virtual desktops, it doesn’t mean that you must put all of your users onto the same type of virtual desktop. Align the technology you implement with the user requirements.
Daniel – Lead Architect
A customer asked me, in fact many customers have asked me this question, “I’ve got a XenApp environment and I want to add virtual desktops for my users. What is the best way to integrate the applications?” My response, “It depends”.
And like all things in the IT world, most decisions do depend on many factors like:
- Are the applications used by many users?
- Are there a lot of dependencies?
- Are we dealing with legacy or new applications (16bit, 32bit, 64bit)?
- Do these applications need to be available offline?
This is only a few questions that should be part of your application integration portion of the virtual desktop design. If we go back to the example where an organization has most of the applications hosted on XenApp and they implement virtual desktops would they keep the applications on XenApp or move? If you keep all of the applications where they are, and you provide your users with a Windows 7 virtual desktop, then why do they need this Windows 7 virtual desktop if all it is, is a nice front-end to the applications? If you wanted to give your users a virtual desktop, you might be better off with a Hosted Shared Desktop made to look like Windows 7.
However, most organizations are not to this point with XenApp. Many have a few applications on XenApp and a massive number of the end points. This is where the analysis questions come into play. The first thing I like to do is create a high-level categorization of the applications to get started. I’ve been using the following for a few years now and it provides a great way to begin.
||Common apps needed by all users||Unique custom built apps
Uncertified Terminal Services support
|Have heavy system requirements||Large, complex apps with many moving parts and dependencies
|Example||Microsoft Office (Word, Excel, PowerPoint, Outlook), Adobe Acrobat||CAD/CAM, data processing||Epic, Cerner, SAP|
|Primary Delivery Method||Installed on Desktop||Virtualized on Desktop||Virtualized on Desktop||Installed on Server|
|Alternative Delivery Method||Virtualized on Desktop||Installed on Server
Installed on Desktop
|Installed on Server|
To go further, you need to align user requirements with application characteristics. This is where I suggest you read the Application Integration Planning Guide that was just added to the XenDesktop Design Handbook. BTW, the handbook now supports offline syncing. Check it out. Once you select “Enable Offline”, go into your “ToGo Kits” and download the tool. Now you don’t have to go back to the site. Just launch the app and sync. Cool
Daniel – Lead Architect
I just got done watching Mary Shelley’s Frankenstein the other day. You know how the story goes. Victor Frankenstein putting pieces together to create something new. It works, but it is not what Victor expected. In fact, it is so horrible that it scares everyone and destroys all who stand in its way.
I also just got done having a discussion around virtual desktops. In this discussion, an organization using XenApp is asking the $1,000,000 question “How can I add virtual desktops to my XenApp implementation?”
It is actually quite easy, you create a virtual desktop, install Citrix Receiver, and away you go. Great, right? If we just add pieces together without thinking about things properly, we might end up with our own Frankenstein in the data center. Let me ask you a question. If you go down this route, then why in the world do you need a desktop if all of your applications are running as hosted XenApp applications?
Virtual desktops are going to allow us to get broader adoption of the virtualization solution throughout the organization. Applications are only part of the entire solution. Users are more comfortable working in a desktop environment, so let’s give it to them. But how?
- First, the integration is not hard, it just requires a proper analysis and design of your overall goals (this is the most common thing to do with a system design).
- Second, we need to align our users needs with the solution (remember, one size does not fit all).
- Third, we need to create an solution that is optimized and functional.
This is a great architectural discussion, which I’m sure you will get something out of. The only caveat is you have to be registered for Synergy Berlin and attend the session SYN320 – Add virtual desktops to your XenApp implementation the easy way!
Hope to see you in Berlin
Daniel – Lead Architect