Tuesday, August 5, 2014

Architecting a Citrix Virtualization solution-Design: Desktop Delivery design

Lets refresh where we are! We are discussing  about architecting a Citrix environment from Architects perspective. There are 2 parts to it:

  1)    Assessment
  2)    Design

Assessment is further divided into

Design is further divided into
·   Desktop Delivery design
·   Operating System Provisioning design
·   Virtualization Infrastructure Design
·   Access Design
·   Delivery Optimization
In this blog, we will discuss design of Desktop Delivery.

Designing an enterprise-level desktop delivery solution must take into account users, applications, desktop and the underlying infrastructure design. Architects should be focused on aligning the technical solution to the organization's challenges, and on providing users with the best operating environment based on their needs. Most users require process-focused applications, while certain users require a more dynamic environment allowing them to create and customize their work environment as needed.
Virtual desktop delivery is an initiative with the goal of simplifying, securing and delivering optimized desktops. Virtual desktops can be a significant departure from the way an organization currently manages and delivers desktops. Citrix XenDesktop provides an approach for creating, building and delivering virtual desktops by virtualizing a standard desktop into different layers. However, in order to create an optimal desktop delivery environment, a thorough design must be completed

Desktop Delivery Design Scenario
A Citrix Certified Integration Architect has been given the task of designing a solution for delivering the desktops to employees at a company. This design is a part of a project that will result in a complete virtualization solution for the company using Citrix products.
The company wants to be able to easily update the operating systems and applications on the employees endpoints whenever necessary without having to touch every endpoint.
During the assessment the architect documented the following information:
  • All employees in the division are located in New York City, New York.
  • 50 employees conduct surveys and are members of the Conductors Active Directory group.
  • 150 employees enter data and are members of the Data Entry Active Directory group.
  • 25 employees analyze survey data and are members of the Analysts Active Directory group.
  • 15 employees are managers and are members of the Managers Active Directory group.
  • All employees currently have assigned endpoints running Windows XP.
  • The Conductors require Windows 7, MS Office 2007 and SurveyU 2007 software.
  • The Data Entry group requires Windows 7, MS Office 2007 and DataCapturer 2007 software.
  • The Analysts require Windows 7, MS Office 2007 and SurveyEvaluator software.
  • The Managers require Windows 7 and MS Office 2007 software.
  • Both the Analysts and Managers groups require the ability to install the software.
  • All employees save data during their work day, which must be accessible at a later time.
  • Only Analysts and Managers have access to printers.
  • Conductors and Data Entry groups are only allowed to access their endpoints from 8:30 am through 5:00 pm.
  • Analysts and Managers require 24/7 access to their desktops.
An architect can use the information gathered during an assessment and the information in the following topics to assist in designing an desktop delivery solution.

Desktop Delivery Controller
It is important for architects to be aware of the design considerations for the Desktop Delivery Controller (DDC). The DDC is an essential part of the XenDesktop infrastructure, delivering and controlling access to virtual desktops, including the following tasks the DDC performs during session initialization:
  • User authentication
  • Virtual machine power management
  • Session policy decisions
  • License enforcement
Following session initialization, the DDC performs standard monitoring and maintenance tasks only, allowing it to handle thousands of desktops at the same time. However, a best practice is to configure at least two DDCs per XenDesktop farm for fault tolerance and redundancy.
The initial DDC installed is the default farm master for the XenDesktop farm. The farm master serves as the data collector, performs desktop resolution operations during launches, and manages the host infrastructure. When there are multiple servers in a farm, it is often desirable to separate the functions of controller and data collector by delegating these functions to different servers. Other DDC servers in the farm can better perform the additional duties, allowing the farm master to concentrate on its role.
For more information about separating DDC roles, see the CTX117477 Knowledge Base article on the www.citrix.com web site.
Farm Design
A XenDesktop farm functions as a single administrative entity and virtual desktops are defined, grouped and associated with users. Citrix policies enable the architect and administrators to refine the environment and improve the overall desktop delivery experience.
Scalabilty of the farm is dependent on the number of simultaneous logon requests in conjunction with the hardware of the DDC, not total user load. An architect typically recommends that a client implement a specific number of farms (for example, 2: 1 for production and 1 for testing/development).
Additional considerations include the following:
  • The processing power of the DDC can be a limiting factor for scalability. The most stress for the DDC is during peak connection times such as when many users log on in the morning to begin work. Once the DDC has brokered the connection to the virtual desktop, the endpoint client then establishes a connection to the brokered virtual desktop. In this situation, the delivery controller is no longer in the line of traffic and the demand on its resources are diminished, allowing for scalability.
  • With multiple datacenters, each datacenter will need their own farm, for scalability reasons
  • XenDesktop contains farms, but does not contain zones.
Ask the Architect
How should a XenDesktop farm be designed to allow a single instance to serve many organizations (multi-tenancy)? To find out more, view the "Use XenDesktop in Multi-Tenancy Models" video on the www.citrix.com/tv web site.

Farm Design Decisions
When creating the farm design, an architect typically makes decisions regarding the following items:
  • The delivery protocol (ICA) is able to overcome many of the latency/bandwidth limitations of the WAN link. Less than optimal communication with the data will disrupt the user's acceptance of the solution. For that reason, over WAN links, the applications should be logically near the data.
  • At least two DDCs are recommended for fault tolerance and redundancy.
  • The XenDesktop farm is attached to the domain. It is possible to have multiple farms in the same domain.
  • Virtual desktops can use the same time zone or multiple time zones based on their location. Users logon time is a consideration when designing the solution.
  • Multiple virtual desktop groups may need to be created, depending on the size of the organization, to achieve greater scalability and stability. The configuration is completed using the Delivery Services Console.
  • The decision to use a single farm or multiple farms is a common design decision that affects XenDesktop administration, infrastructure and users. A single farm creates a single administration environment, but multiple farms can optimize the environment with geographically-dispersed datacenters. For large environments, the best practice is to use multiple farms.
     Single Farm
  • A single farm solution allows XenDesktop administrators to manage the XenDesktop farm from a single centralized console.
  • With a single URL, users connect to the XenDesktop farm and are presented with a list of available resources. No additional hardware/software is required in order to provide a single access point for the users.
  • DDC communication must be able to cross WAN links to keep the farm in sync. Also, the master controller must be able to communicate with XenServer resource polls in each location. Delays in communication can impact the accuracy in virtual desktop status changes.
  • With a single XenDesktop farm, there is potential for users to connect to a hosted desktop in a different location. Although ICA is optimized for the WAN lniks, the backend data is not. This might result in application performance degradation as data is copied from a remote site to the hosted desktop. This can be mitigated by creating different desktop groups for users based on their preferred location, but it adds complexity to the farm.
     Multiple Farms
  • A user, regardless of their location, always connects to the most  
      proper change control processes, this risk can be easily mitigated.
From the Architect
How scalable is a XenDesktop farm? It depends. Only after proper and thorough scalability testing can an organization determine that. For more information, see the "How Big Can My XenDesktop Farm Be?" article on the http://community.citrix.com web site.

Virtual Machine Specifications
Determining the specifications for each group of hosted desktops requires a proper balance between performance and allocation. User groups only need certain amounts of resources in order to be productive. Providing too many resources results in under-utilized hardware while allocating too few resources results in underperforming systems. For each unique user group, architects should determine the following:
  • Desktop count: Identify the number of virtual desktops a particular user group requires.
  • Memory Allocation: Identify the amount of RAM allocated for the particular hosted desktop.
  • Process Allocation: Identify the number of virtual CPUs allocated for a particular guest. In some circumstances, a single virtual CPU for each hosted desktop is enough processing power because the performance of a server CPU is much greater than a physical desktop's CPU. However, most desktop operating systems cannot support that much CPU.
The following table provides an example of virtual machine specifications.
     User Group
        Desktop Type
     Operating System
      1GB RAM
      Streamed to Desktop
      2GB RAM      
     Streamed to Desktop
Virtual Desktop Groups
In a typical architecture for XenDesktop, users are separated into virtual desktop groups, usually by their job function. The majority of users might be a part of a 'Pooled Users' group. Certain users may fit into the 'Assigned Users' group. While many different types of virtual desktop groups can be created, for the purposes of this section we will use Pooled Users and Assigned Users as an example.
For each group, an architect should make recommendations such as the target device, assignment type, logoff behavior, idle workstation time and peak time count.

From the Architect

All users should be considered part of the pooled users group, unless there is a valid reason to provide them with an assigned desktop.
Virtual Desktop Group Decisions
When designing for pooled users and assigned users, architects should make decisions on the following topics:
  • Operating system
  • Associated virtual desktop group
  • User group location
  • Special requirements
  • User permissions
  • Virtual CPU
  • RAM
  • vDisk boot order
Collected data on the percentage of remote users, total number of users, and number of concurrent users aids in the decision-making process for pooled user design

Virtual Desktop Group Design
Contrasting pooled and assigned users, the Pooled Users group leverages one identical image hosted on a Provisioning Server. The Pooled Users group is helpful for task users or users who do not require workstation customization or the ability to install applications. Pooled users can use profile management and folder redirection to save their documents and settings.
The assigned users group supports users who require customization, the ability to install applications and need applications to move seamlessly between computers. One use case would be a developer who develops .NET applications using Microsoft Visual Studio.

Ask the Architect

How can a large XenDesktop implementation be simplified? To find out more, view the "Simplify the XenDesktop Design" and "Align a XenDesktop POD with Domains" videos on the www.citrix.com/tv web site.
Pooled Users Group
When designing a user group for pooled users, architects should acknowledge that pooled users do not require a completely customizable workstation.
Pooled users will likely share the same desktop image. Examples of strong candidates for the Pooled User group would be a call center agent or a bank teller, because personalized settings would not be required and they could be provided with a generic desktop.
From an architectural standpoint, pooled images also require fewer resources, because the resources are reused often.
Pooled User group benefits
Pooled User group drawbacks
Administrators can provide a standard desktop image.
Users have limited ability to customize their workstation.
Standard desktop images require fewer resources and are easier to manage.
Users do not own a particular virtual machine. System-level settings are not preserved.

Assigned Users Group
Another user group for desktop virtualization is Assigned Users. Assigned Users have an assigned workstation and the ability to customize it and install or uninstall applications as necessary, and all their settings are saved for use in future sessions.
Typical users that are part of the Assigned Users group include engineers and developers. Each of these user types, depending on the organization, may have a requirements for a single, dedicated desktop that is accessible from multiple locations. When designing for assigned users, architects should take into account the resources that must be dedicated to this group (hardware, storage space) and the need for the user to access the desktop from any location.
Benefits of Assigned Users group
Assigned Users group drawbacks
Users can fully customize their workstations.
Assigned users require additional resources, such as storage.
Users can install and remove software on their own.
Assigned user images are more time consuming for administrators to manage.
Profile Design
Design considerations for profiles in a desktop delivery environment include the following:
  • Ensure the desktop is considered in profile design.
  • Local profiles can work in a desktop delivery environment.
  • For XenDesktop, mandatory profiles are generally the best option. Mandatory profiles are the easiest to configure, unless roaming profiles are already set up.

Policies Design
Policies for a desktop virtualization environment are applied at the virtual desktop level, originating from XenDesktop. Policies can be applied to all desktops or a particular Active Directory group. Common policies include:
  • Bandwidth/session limits (example: turn off desktop wallpaper)
  • Bandwidth/speedscreen (example: high compression or low quality image)
  • Client devices/resources/audio
  • Client devices/resources/drives/optimize (example: connect client drives at logon)
  • Printing (example: autocreate all printers, print job routing enabled for third party only, UPD unless available)
  • User workspace
  • Time zones
  • Security/encryption (example: RC5 128-bit)

No comments:

Post a Comment

Featured Post

Amazon Route 53

Amazon Route 53 is a highly available and scalable Domain Name System (DNS) web service.Route 53  perform three main functions in any...