Archive

Posts Tagged ‘Flexcast’

Simplified VDI Architecture – #Citrix, #XenDesktop

This is a great start of a blog series from Citrix!

There’s a perception that VDI is complicated.  I’m far from being a rocket scientist, and I’ve managed to implement many successful VDI projects over the past ten years.  I truly believe that VDI is one of those things that is only as complicated as you make it.

It’s like saying that driving is complicated.  You’d have to be crazy [or very brave] to take your first lesson in Manhattan…during rush hour.  That’s why your driving instructor starts you off on a quiet street.  You need to know your boundaries.  Being successful with VDI is the same – keep things simple to start with and slowly increase complexity at your own pace, when you’re ready for it.

This raises the question – what’s the quiet street equivalent of a beginner’s VDI architecture?  It might not be the most optimized and efficient solution, but it would be quick to implement, do the job well and wouldn’t require specialist knowledge or skills.  I’ve been thinking about this a lot lately, and I’d like to share my thoughts.

There’s a lot to consider, so I’m going to break this up over four different blog posts:

  1. Simplified VDI Architecture – Introduction & FlexCast
  2. Simplified VDI Architecture – Storage
  3. Simplified VDI Architecture – Provisioning
  4. Simplified VDI Architecture – Reference Architecture

Martin Zugec will be helping me out with this blog series and will be referring to his experience on actual customer projects that followed many of these recommendations.

XenDesktop or VDI in a Box?

First up, you need to make a decision on VDI in a Box or XenDesktop.  VDI in a Box is easier to setup but does have some limitations.  Check out Allen Furmanski’s excellent blog post for guidance on how to make this decision.  I’m going to concentrate on XenDesktop for this post.

FlexCast

Although each FlexCast model has its own unique advantages, each additional model included adds complexity to the overall project.  There is a great table in the Virtual Desktop Handbook (FlexCast Model Selection – Table 11) that provides guidance on the capabilities of each model.  The main thing to note is that all scenarios, apart from offline, can be accommodated using the Hosted VDI model (XenDesktop), either with or without a Personal vDisk.  It may not be the optimal selection in every instance, but it is almost always a viable solution.

There are a number of reasons why I think that XenDesktop is simpler than XenApp, including:

  1. Desktop applications are developed to run on desktop operating systems such as Windows XP or Windows 7.  There aren’t many developers that test their applications on Windows Server 2003 or 2008.  Therefore, you’re far less likely to run into application issues with XenDesktop than you are with XenApp.  Even if your applications run okay on 2008 with XenApp, you’re probably going to have issues getting support from the application vendors.
  2. Hosting applications on multi-user operating systems can introduce additional application compatibility challenges.  Users may share the same configuration files and registry hives, especially if the applications are not multi-user aware.  This means that one user may change a setting that affects all other users of that server.  There are a ton of tips and tricks to get these apps working correctly but we want to keep things simple and choosing XenDesktop helps us achieve this goal.
  3. As multiple users are hosted on the same operating system, it is important that XenApp desktops are locked down to prevent security breaches and misconfiguration that could impact all users sharing the environment. Typically, this results in an extremely controlled and restricted user experience, hindering user satisfaction and acceptance.
  4. With XenApp desktops, a single user can consume a disproportionate amount of resources, impacting the performance of other users sharing the same XenApp server.  XenDesktop, on the other hand, allows vCPU and RAM assignments to be controlled on a per-user basis.  For this reason, I strongly recommend that heavy users are hosted on XenDesktop rather than XenApp.
  5. With XenDesktop, it is possible to provide users with fully personalized desktops.  This includes the ability for users to install their own applications.
  6. Unlike XenApp, XenDesktop supports generic USB redirection:

I’m a huge fan of Remote PC, especially when you consider just how simple it is to deploy.  However, there are some things Remote PC just can’t do, including:

  • You don’t have the flexibility to quickly provision or de-provision desktops based on business demands.
  • Image management is more complicated than a virtual desktop because you can’t use MCS and PVS can be challenging with desktops outside of the data center
  • You need to have a good connection between your XenDesktop Controllers and the physical desktops.  Something not always available for WAN users.

Regardless, Remote PC is a great solution in many scenarios.  Consider deploying Remote PC at the very start of your project.  It allows you to realize immediate value while you’re designing and implementing your full VDI solution.

If XenDesktop is so much simpler why do so many projects still standardize on XenApp?  It all comes down to cost – XenApp offers significantly higher levels of scalability than XenDesktop (some sources quote 300% more users).  Let’s take a look at this in more detail.

Processor

The Virtual Desktop Handbook provides us with guidelines on processor requirements for both XenApp and XenDesktop (Processor Requirements by Workload – Table 22):

If processor is the bottleneck, we can estimate the scalability of XenApp and XenDesktop for a fairly typical server configuration (2×8 cores):

As you can see, XenApp offers between 17% (heavy user) and 28% (light user) more users than XenDesktop – but nowhere near 300%!  Let’s put this into context, if you had 1,000 concurrent normal users, you would need seven physical servers for ‘XenDesktop: Windows 7’ and six physical servers for ‘XenApp: 2008 R2’.  Is one additional server per ~1,000 users enough to justify the additional complexity of XenApp?

RAM

For RAM, the Virtual Desktop Handbook table (Memory Requirements by Workload – Table 23) shows us that ‘XenDesktop: Windows 7’ requires significantly…

Continue reading here!

//Richard

Designing a virtual desktop environment? – #XenDesktop, #Citrix

This is a good blog post by Niraj Patel.

Questions: How do you successfully design a virtual desktop solution for 1,000 users?  How about 10,000 users?  What about 50,000 users?  What are the questions you should be asking?  Most importantly, where do you start?

Answer: Hire Citrix Consulting for your next virtual desktop project!  OK, that is one right answer, but not the only way to do it.  The successful way to design a virtual desktop environment is to follow a modular approach using the 5 layers defined within the Citrix Virtual Desktop Handbook.  Breaking apart a virtual desktop project into different layers provides a modular approach that reduces risks and increase chances for your project’s success no matter how larger you’re planned deployment is.  What are the 5 layers and some examples of the decisions are defined within them?

  1. User Layer:  Recommended end-points and the required user functionality.
  2. Access Layer:  How the user will connect to their desktop hosted in the desktop layer.  Decisions for local vs. remote access, firewalls and SSL-VPN communications are addressed within this layer.
  3. Desktop Layer:  The desktop layer contains the user’s virtual desktop and is subdivided into three components; image, applications, and personalization.  Decisions related to FlexCast model, application requirements, policy, and profile design are addressed in this layer.
  4. Control Layer:  Within the control layer decisions surrounding the management and maintenance of the overall solution are addressed.  The control layer is comprised of access controllers, desktop controllers and infrastructure controllers.  Access controllers support the access layer, desktop controllers support the desktop layer, and infrastructure controllers provide the underlying support for each component within the architecture.
  5. Hardware Layer:  The hardware layer contains the physical devices required to support the entire solution, and includes servers, processors, memory and storage devices.

Want to know how to get started?  Try the Citrix Project Accelerator.  Input criteria around your business requirements, technical expertise, end user requirements, applications, etc. to get started on your architecture based on the 5 layer model.

Lastly, don’t forget to come see SYN318…

Continue reading here!

//Richard

Demystifying Citrix Excalibur Architecture – via @kbaggerman

A great blog post by Kees Baggerman! 🙂

For all XenApp admins and consultants out there Project Avalon will bring a big change as we are used to having XenApp servers running on the (what seemed to be) everlasting Citrix Independent Management Architecture and we’re heading to Citrix FlexCast Management Architecture (already included in XenDesktop at this moment) and will be included in the Citrix Excalibur Architecture.

IMA

When looking up IMA in the eDocs you’ll find:

Independent Management Architecture (IMA) is the underlying architecture used in XenApp for configuring, monitoring, and operating all XenApp functions. The IMA data store stores all XenApp configurations.

Basically IMA exists to manage the XenApp or Presentation Server farms by enabling the communications between servers. As stated it transfers information about all XenApp functions like licenses, policies, sessions and server loads. All management tooling within these versions of Citrix’s PS/XA rely on this service for information.

According to Communication ports used by Citrix Technologies IMA uses the following ports:

Ports Source Prot. Comment
2512 Common Citrix Communication Ports TCP Independent Management Architecture (IMA)
2513 Access Gateway 5.0 Controller administration TCP IMA-based Communication

As we can see IMA uses 2512 (by default) to communicate with other servers and the Access Gateway Controller uses 2513 (by default) for IMA-based communication. The port IMA uses can be changed or queried via the commandline tool IMAPORT.

Brian Madden did a blogpost way back in 2007 but it’s definition of IMA is still current:

Independent Management Architecture is:

  • A data store, which is a database for storing MetaFrame XP server configuration information, such as published applications, total licenses, load balancing configuration, MetaFrame XP security rights, and printer configuration.
  • A protocol for transferring the ever-changing background information between MetaFrame XP servers, including server load, current users and connections, and licenses in use
FMA

With the introduction of XenDesktop we got a new architecture called Flexcast Management Architecture. This new architecture has got an agent-based setup where we can install the operating system including the basic applications that need to be installed and after that we can install an agent. This agent registers itself to a controller and is offered through StoreFront to the end user.

This will be delivered by two different types of agents, one to support Windows Server OS’s and one for Windows Desktop OS’s.

Andrew Wood did an article on Excalibur and used this diagram to explain the architecture:

Citrix FlexCast Management ArchitectureCitrix FlexCast Management Architecture

  • Receiver provides users with self-service access to published resources.
  • StoreFront authenticates users to site(s) hosting resources and manages stores of desktops and applications that users access – Web Interface as a platform is essentially resting, but it will cease to be.
  • Studio is a single management console that enables you to configure and manage your deployment, a dramatic reduction over the 23 consoles you could well have today. Studio provides various wizards to guide you through the process of setting up an environment, creating workloads to host applications and desktops, and assigning applications and desktops to users.
  • Delivery Controller distributes applications and desktops, manages user access, and optimizes…

Continue reading here!

//Richard

%d bloggers like this: