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.
|
Benefits
|
Concerns
|
|
|
Single Farm
|
|
|
|
Multiple Farms
|
|
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
|
Population
|
Operating System
|
Memory
|
Processor
|
|
Finance
|
Hosted
|
50
|
XP
|
1GB RAM
|
1vCPU
|
|
Marketing
|
Streamed to Desktop
|
25
|
XP
|
N/A
|
N/A
|
|
HR
|
Hosted
|
125
|
Vista
|
2GB RAM
|
1vCPU
|
|
Engineering
|
Streamed to Desktop
|
200
|
Vista
|
N/A
|
N/A
|
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