Redbook - Pano System on Citrix XenDesktop - Pano Logic

TABLE OF CONTENTS 

XenDesktop Components 2 

Basic Architecture 2 

Hypervisor 2 

Connection Brokers 3 

DVM Provisioning and Management Tools 3 

Platform Tools in DVMs 4 

Load Balancing Tools 4 

Provisioning and Managing DVMs 4 

Scalability and Redundancy on XenDesktop 5 

<strong>Pano</strong> Controller Scalability and Redundancy 5 

XenDesktop Controller Scalability 5 

Load Balancing with NetScaler 6 

Sample Architectures on XenDesktop 7 

25-Seat Deployment 7 

1,000-Seat Deployment 10 

10,000-Seat Deployment 13 

<strong>Pano</strong> Remote with XenDesktop 15 

What Happens When a User Logs In 16 

Differences on XenDesktop 17 

More Information 18 

<strong>Pano</strong> Logic® offers a cross-platform desktop virtualization 

system combining a unique zero client endpoint with 

centralized management tools designed specifically for the 

tasks of deploying and managing virtual desktops. 

This redbook covers the basic architecture for deploying a 

<strong>Pano</strong> <strong>System</strong> on the Citrix® XenDesktop® 5 platform, 

explaining how it integrates with different components 

included in XenDesktop. 

Overviews of different architecture, scalability and 

availability configurations for both XenDesktop and <strong>Pano</strong> 

<strong>System</strong> components are discussed, along with detailed 

sample deployment architectures for 25-, 1,000- and 

10,000-seat deployments. To clarify deployment 

requirements, the interaction between <strong>Pano</strong> Controller and 

the XenDesktop Controller during login and connection 

brokering is covered, followed by <strong>Pano</strong> deployment 

differences and limitations specific to XenDesktop. 

This redbook assumes that you are familiar with the 

operation of XenDesktop and with the basic structure and 

operation of the <strong>Pano</strong> <strong>System</strong>. It does not replace the 

installation instructions in the XenDesktop documentation 

and the <strong>Pano</strong> Logic online help. 

It provides platform-specific details that supplement the 

more general <strong>Pano</strong> deployment planning and infrastructure 

sizing guidance provided by the Deployment Architecture 

Overview <strong>Redbook</strong>, Infrastructure Sizing <strong>Redbook</strong>, and the 

Remote Deployment <strong>Redbook</strong> 

PANO LOGIC: REDBOOK PAGE 1

NetScaler 

(optional) 

DEPLOYING PANO SYSTEM ON CITRIX XENDESKTOP 

This section describes the various Citrix XenDesktop 4 or 5 components and describes 

how they function in a <strong>Pano</strong> <strong>System</strong> deployment. 

BASIC ARCHITECTURE 

Figure 1: 

Diagram of <strong>Pano</strong> 

<strong>System</strong> and 

XenDesktop 

components 

The diagram below illustrates the system architecture when using <strong>Pano</strong> <strong>System</strong> and 

XenDesktop together. 

DHCP 

Network and Data Center 

Active Directory 

File Server 

DNS 

Network 

Services 

<strong>Pano</strong> 

Zero 

Client 

Windows XP/7 Operating <strong>System</strong> 


Direct Service 

<strong>Pano</strong> Maestro 

XenServer 

Tools 


VDA 

Redundancy / 

Management 

Desktop 

Virtual 

Machine 

User 

Locations 

<strong>Pano</strong> Controller – ZCC 

XenDesktop Controller 

Connection 

Brokering 

Citrix Desktop Studio 

Citrix Provisioning Services & 

Machine Creation Services 

DVM 

Provisioning 

Citrix XenServer / VMware ESX 

Hypervisor 

HYPERVISOR 

Hypervisor software allows multiple virtual machines to run concurrently on shared server 

hardware. Hypervisors are used both to host desktop virtual machines (DVMs) running on 

desktop servers and to host system VMs like <strong>Pano</strong> Controller or XenDesktop Controller on 

infrastructure servers. Currently, the XenServer® 5.6 (included with XenDesktop) and 

VMware® vSphere ESX 4.1 hypervisors are supported by the <strong>Pano</strong> <strong>System</strong> 4.5 on 

XenDesktop, although XenDesktop also supports the Microsoft Hyper-V hypervisor. 

Both XenServer and ESX are type 1 or bare metal hypervisors that require no underlying 

host operating system (OS). They interact directly with the server hardware rather than 

relying on the host OS driver stack. Because of this, you need to be sure that your server 

hardware, including RAID controllers and network interface cards, are on the hardware 

compatibility list for your selected hypervisor. 



CONNECTION BROKERS 

XenDesktop Controller (also called the Desktop Delivery Controller, or DDC, in 

XenDesktop 4) functions as the connection broker for the entire system. <strong>Pano</strong> Controller 

connects to a single XenDesktop Controller interface, potentially creating a scalability limit 

or single point of failure. A load balancer can be used to present a single interface to 

multiple XenDesktop Controllers. More information is provided in the “Scalability and 

Redundancy on XenDesktop” section on page 5. 

DVM PROVISIONING AND MANAGEMENT TOOLS 

When using the <strong>Pano</strong> <strong>System</strong> with XenDesktop, Desktop Studio is used to perform DVM 

management and provisioning activities. <strong>Pano</strong> Controller will not cause any DVMs to be 

created, nor will it attempt to keep a certain number of DVMs powered on. These 

provisioning and power-management functions are all performed by these components 

along with XenDesktop Controller. In addition, Citrix Provisioning Services or Machine 

Creation Services can be used to provide automatic provisioning services. 

Citrix Provisioning Services (PVS) is optional, but is commonly used to efficiently 

provision DVMs in a XenDesktop deployment. PVS enables you to stream a single 

desktop image to create multiple virtual desktops on one or more servers in a data center. 

This can greatly reduce the amount of storage required compared to other methods of 

creating virtual desktop or DVM images. PVS is generally recommended for larger 

deployments. 

Machine Creation Services (MCS) is an alternate DVM provisioning service introduced 

with XenDesktop 5. MCS is required for both Pooled and Dedicated desktop virtual 

machine types, while PVS is required for Streamed DVMs. Because MCS doesn’t offer 

the same level of RAM-based read caching as PVS does, Citrix indicates that it can end 

up using as much as 50% more IOPS than PVS – however this might not be an issue 

except for very large deployments. 

Table 1: Virtual Machine Types Supported in XenDesktop 

DVM Type Required Provisioning Service Supported with <strong>Pano</strong>s? 

Pooled Machine Creation Services Yes 

Dedicated Machine Creation Services Yes 

Existing None Yes 

Physical None No 

Streamed Citrix Provisioning Services Yes 

Table 1 lists the different desktop virtual machine types supported by XenDesktop, which 

provisioning service (PVS or MCS) is required. The only XenDesktop machine type not 

supported by the <strong>Pano</strong> <strong>System</strong> is Physical, which is used to manage user desktops 

hosted on dedicated blade PCs rather than in shared VDI servers. 



XenDesktop also includes a Profile Management tool (not covered in this redbook) that 

can manage user personalization settings, which can optionally be controlled by Active 

Directory Group Policy Objects. 

PLATFORM TOOLS IN DVMS 

All Desktop Virtual Machines (DVMs), of which you will typically have many in your 

deployment, will need to have both the <strong>Pano</strong> Direct Service (PDS) software and platformspecific 

add-ins or tool software installed directly in the Windows® operating system. 

XenDesktop allows you to create and manage pools of DVMs. Each DVM must have the 

XenDesktop Virtual Desktop Agent and XenServer Tools software installed. These 

platform-specific software components are required in order for the XenDesktop Controller 

to manage the state of the DVM. Without these tools installed, the XenDesktop Controller 

will consider the DVM to be unavailable. 

If Citrix PVS is used, the desktop images managed by PVS must include the following 

components: XenServer Tools, XenDesktop Virtual Desktop Agent and <strong>Pano</strong> Direct 

Service (discussed below). As indicated in the setup instructions in the online help, you 

must install these components in the correct order: (1) XenServer Tools, (2) then 

XenDesktop Virtual Desktop Agent and (3) finally <strong>Pano</strong> Direct Service. 

If you are using the DVMs on a VMware vSphere ESX hypervisor, you’ll need to install 

VMware Tools into the DVM rather than XenServer Tools. 

LOAD BALANCING TOOLS 

When multiple instances of the XenDesktop Controller are required, you will need to use a 

load balancer, such as Citrix NetScaler® VPX or MPX, to provide a single, loadbalanced 

interface to which <strong>Pano</strong> Controller can connect. More information is provided in 

the “Scalability and Redundancy on XenDesktop” section on page 5. 

PROVISIONING AND MANAGING DVMS 

DVM provisioning is set up and controlled via the Desktop Studio rather than in <strong>Pano</strong> 

Controller. On the Citrix XenDesktop platform, only a single platform-specific DVM 

collection (the “Citrix XenDesktop” DVM collection type) is used within <strong>Pano</strong> Controller. 

Device-based DVM collections are not supported under XenDesktop. 

Note that one other limitation of the <strong>Pano</strong> <strong>System</strong> on XenDesktop is the interoperability 

between the DVMs used with the <strong>Pano</strong> <strong>System</strong> and the XenDesktop DVMs used with 

other HDX/ICA®-based clients (such as a thin client). See “Differences on XenDesktop” 

on page 17 for more information. 

Note: If you intend to use or are currently using Citrix Provisioning Services to autoprovision 

virtual desktops, you don’t need to perform all the steps outlined below. For 

details about automated provisioning on XenDesktop, see “Prepare for Automated 

Provisioning on XenDesktop” in the online help. 

To set up DVMs on XenDesktop, it is recommended that you use Citrix Desktop Studio to 

create a new DVM from scratch (for information about this and other Citrix operations, see 

the Citrix documentation). Then install Windows XP or Windows 7 and configure hardware 

acceleration in the operating system. Next, install XenServer Tools and then the 

XenDesktop Virtual Desktop Agent. Next, install XenServer Tools (or VMware tools if 

running on VMware vSphere ESX) and then the XenDesktop Virtual Desktop Agent, 

followed by the <strong>Pano</strong> Direct Service. Depending on the Machine Type you will need to 

install the <strong>Pano</strong> Direct Service software in the Master VM (Pooled or Permanent), in the 

individual VM (Existing) or vDisk (Streamed). 



Security Settings on XenDesktop 

Deploying <strong>Pano</strong>s on the XenDesktop platform requires some specialized steps to 

synchronize the security permissions in <strong>Pano</strong> Controller with those used by XenDesktop. 

On the Access tab in <strong>Pano</strong> Controller (only visible when creating or editing a DVM 

collection), specify the accounts which are to have access to the DVMs. The simplest 

approach is to specify a security group that includes all domain users, such as the default 

Domain Users group. Even though all users would be entitled within <strong>Pano</strong> Controller, the 

user entitlements defined in XenDesktop will still be used to implement more specific userto-desktop 

mappings. Thus, if an account is entitled in <strong>Pano</strong> Controller but not in 

XenDesktop, the user will be prevented from connecting to a desktop. 

For larger deployments on the Citrix platform, it may be necessary to use optional 

XenDesktop components and configurations to provide both scalability and redundancy to 

improve availability. 

PANO CONTROLLER SCALABILITY AND REDUNDANCY 

If you are deploying over 500 seats, a <strong>Pano</strong> Controller group that combines two or more 

<strong>Pano</strong> Controller instances to provide scalability in a master/slave configuration will be 

required. 

If you also want to provide redundancy or failover capabilities in the event of server 

hardware or software failure, two <strong>Pano</strong> Controller instances need to be installed on two 

different physical servers and configured as primary (active) and secondary (passive), and 

a third <strong>Pano</strong> Controller instance would also be added and configured as a slave. Table 2 

provides a summary of scalability with additional <strong>Pano</strong> Controller instances. 

Table 2: Scalability Group Requirements for Scalability and Redundancy 

<strong>Pano</strong> Controller Configuration 

# of <strong>Pano</strong> 

Controllers 

Redundant 

Single 1 No 500 

Scalability Group 2 No 1,000 

Failover Group 2 Yes 500 

Failover Group with Scalability 3 Yes 1,000 

Max. Clients 

or DVMs 

In this configuration, all three instances of <strong>Pano</strong> Controller belong to the same <strong>Pano</strong> 

Controller group; connection brokering logic is made highly available by implementing an 

active/passive, two-node failover cluster using the two <strong>Pano</strong> Controller instances. <strong>Pano</strong> 

Controller also displays login screens to the <strong>Pano</strong> clients. In this configuration, <strong>Pano</strong> login 

screens are active across all available <strong>Pano</strong> Controller nodes, up to three nodes. To 

complement this multiplication of <strong>Pano</strong> Controller resources, an equivalent increase in 

XenDesktop instances along with a load-balancing front-end is required, as explained in 

the next section. 

XENDESKTOP CONTROLLER SCALABILITY 

Larger <strong>Pano</strong> deployments on XenDesktop will need to use multiple instances of the 

XenDesktop Controller. <strong>Pano</strong> Controller connects to XenDesktop Controller via a single 

API or interface which must be capable of servicing the required number of broker 

requests during <strong>Pano</strong> client logins. 


Login UI / 

Login Credentials 





If you have a very large and active deployment, the number of connection broker requests 

might overload a single XenDesktop Controller instance, thereby resulting in unacceptable 

response times and a degraded user experience. 

Figure 2: 

Load balancing 

on XenDesktop 

using Citrix 

NetScaler 

<strong>Pano</strong> Session 

Desktop Servers 

Windows 

<strong>Pano</strong> Direct Service 

XenServer/ESX 

Brokered 

Connection 

Connection Brokering 

to other <strong>Pano</strong> DVMs 

<strong>Pano</strong> Controller 

XenServer/ESX 

Infrastructure Server 


Login Credentials 

XenServer/ESX 

Infrastructure Server 


Group 

NetScaler VPX 

XenServer/ESX 

Infrastructure Servers 

The exact number of users that can be supported by each Desktop Controller instance will 

be dependent on the server hardware used to host the Controllers and the acceptable 

delays during the login and connection brokering process. These delays only apply up to 

the point where the <strong>Pano</strong> client is directly connected to a <strong>Pano</strong> DVM. Once the user 

session reaches that point (documented in the “What Happens When a User Logs In” 

section on page 16), the Desktop Controller is no longer involved. 

Running the Desktop Controllers as virtual machines on a shared server that is also 

supporting other infrastructure components – such as <strong>Pano</strong> Controller or a provisioning 

tool – will also lower the number of concurrent client logins it can support. To optimize 

scalability you can dedicate a physical server solely to run several XenDesktop Controller 

instance – however, grouping multiple instances on one physical server can create a 

single point of failure and potentially limit availability. 

LOAD BALANCING WITH NETSCALER 

The use of multiple XenDesktop Controller instances is supported with <strong>Pano</strong>s, but some 

form of load balancer is needed to provide a single interface to which <strong>Pano</strong> Controller can 

connect. Citrix NetScaler is recommended as a load balancer to connect a single <strong>Pano</strong> 

Controller instance (or group) to multiple Controller instances. NetScaler can load balance 

requests to multiple XenDesktop Controller instances installed on the same physical 

server. But to improve availability in the event of a server failure, as well as to minimize 

the number of required Controller instances, it is also possible to locate them on physically 

separate servers. 



NetScaler is available as either a VPX virtual appliance or as an MPX hardware appliance 

with preinstalled software. Licensing costs for both types of appliances are based on the 

number of NetScaler servers and bandwidth tiers. The amount of traffic in the form of XML 

API calls that passes from <strong>Pano</strong> Controller to the XenDesktop Controller instances is fairly 

small, making it practical to license NetScaler in its lowest bandwidth tier to reduce costs. 

Figure 3: 

Sample architecture 

for a 25-seat 

deployment on 

Citrix XenDesktop 

This section details three sample architectures for a <strong>Pano</strong> <strong>System</strong> deployed on Citrix 

XenDesktop in 25-, 500- and 1,000-seat deployment sizes. It provides guidelines on the 

hardware and software requirements for the different deployment sizes, along with 

information about Citrix platform software components and configurations 

These sample architectures are based on typical 1U or 2U servers equipped with dual, 

quad-core Intel® Nehalem or Westmere CPUs, 32-72 GB of RAM each (depending on the 

deployment size), a 50% mix of Windows XP and Windows 7 users, combined light task 

worker and heavy knowledge worker workloads and a duty cycle of concurrently active 

DVMs of 75%. Deployments with higher duty cycles, a greater proportion of Windows 7 

DVMs or a user mix favoring heavy workloads will require additional server and storage 

resources. 

25-SEAT DEPLOYMENT 

This section provides information on sample architectures for a basic (25-seat) <strong>Pano</strong> 

<strong>System</strong> deployment on Citrix XenDesktop. 

Users' 

Location 

25 


Zero 

Clients 

Domain 

DHCP 

Servers 

Directory Services 

1 – 2 Infrastructure Servers 



XenServer/ESX Hypervisor 

Data Center 

1 Desktop Server 

Windows XP/7 DVMs 


Direct 

Service 


VDA 

XenServer 

Tools 


100 Mbps / 

1 Gbps 

Edge Switch 

100 Mbps Edge Network 1 Gbps Core Network 

Core Switch 

Management 

Workstation 

Hardware Sizing and Architecture 

This section provides general guidelines for sizing and architecture configuration for the 

server and storage infrastructure to help ensure a successful 25-seat <strong>Pano</strong> <strong>System</strong> 

deployment. 

For a 25-seat deployment, typically one desktop server will be needed to host the DVMs. 

Depending on the load on the desktop server, a separate infrastructure server may be 

needed for <strong>Pano</strong> Controller and XenDesktop Controller. 



Given that the storage needs for this size deployment are fairly modest (at 15 - 20 GB per 

DVM image), direct-attached storage using enterprise-class drives configured as a RAID 5 

or RAID 6 volume internal to the desktop server may be the most cost-effective approach. 

However using this sort of internal server storage, rather than shared storage like a 

storage area network (SAN), means that if a user needs to access a specific DVM image 

(like a permanently assigned user-based DVM) and the server containing it is down, the 

DVM is effectively inaccessible. 

In addition to the risks from internal or direct-attached storage, the processing performed 

by a single desktop server also represents a single point of failure – if the server should go 

offline, access to all of the DVMs would be interrupted. 

Likewise, the infrastructure server represents another single point of failure – if it were to 

be offline, user logins would be blocked, although users already connected to their DVMs 

would be able to continue working until they needed to log in again or connect to another 

DVM. Both of these availability risks can be mitigated by adding redundant infrastructure 

and desktop servers, but the hardware and software costs involved might not be workable 

for a deployment of this small size. 

Table 3: Summary of Hardware Needed for a Sample 25-Seat Deployment 

Component Amount Description 

Desktop Servers 1 

Dual, quad-core Intel Westmere CPUs (E5620 or 

better), and 32-48 GB of RAM. Server hosts 

XenServer or ESX hypervisor software and 

Windows DVMs. 

Infrastructure 

Server 

Storage 

1 

Raw 

Capacity: 

0.9 TB 

Min. IOPS: 

1,040 

Server hosts <strong>Pano</strong> Controller, XenDesktop 

Controller and supporting XenServer or ESX 

hypervisors. Can be hosted on the same desktop 

server as the DVMs, rather than a separate 

server, if user workloads are light. (See the 

Deployment Architecture Overview <strong>Redbook</strong> for 

information on evaluating user workloads.) 

Allows 15 GB per DVM, an average of 1.5 DVMs 

per user, plus 50 GB overhead for <strong>Pano</strong> 

Controller and XenDesktop VMs, plus limit of 

80% capacity utilization and less 20% RAID 

overhead. 

Requires at least six 15K RPM SAS drives or 

eight 10K RPM drives, based on allocation of 40 

IOPS/DVM. Use direct-attached storage internal 

to servers rather than a shared SAN/NAS unless 

deploying multiple servers for redundancy. 

Networking 

1 100 Mbps/1 Gbps switch for edge network 

1 1 Gbps segment in the core network 

Management 


1 

Windows workstation needed to configure and 

manage the <strong>Pano</strong> <strong>System</strong> and platform. Also 

hosts the Desktop Studio software. 

<strong>Pano</strong> <strong>System</strong> Configuration 

One instance of <strong>Pano</strong> Controller is sufficient for this deployment size, unless you want to 

configure the system for future scalability or current redundancy. 



Because of this small deployment size typically <strong>Pano</strong> Maestro is not required although it 

might be used as a remote management front-end to multiple small deployments each 

with just one or two <strong>Pano</strong> Controllers. 

Platform Considerations and Configuration 

This 25-seat configuration requires only a single Citrix XenDesktop Controller connected 

to a single <strong>Pano</strong> Controller instance. 

In most cases, Citrix Provisioning Services, which are used for storage de-duplication 

across many standard DVM images, can typically be omitted, as well. This is due to the 

fact that the storage requirements for 25 DVM images, plus any other DVM templates, 

aren’t enough to warrant the added complexity and cost of an added Citrix Provisioning 

Services server. 

Table 4: Summary of Software Needed for a Sample 25-Seat Deployment 

Component Number Description 

<strong>Pano</strong> Controller VM 1 or 2 

Only one is required, unless you use a <strong>Pano</strong> 

Controller group. (You should install additional 

<strong>Pano</strong> Controller instances on separate servers 

to protect against server failure.) 

XenServer/ESX 

Hypervisor 

1 or 2 

Only one is required, unless you want to 

configure a <strong>Pano</strong> Controller group for 

redundancy. (For redundancy, install additional 

<strong>Pano</strong> Controller instances on separate servers.) 

XenDesktop Controller 1 

Can be hosted on the same desktop server as 

the DVMs and <strong>Pano</strong> Controller. 

Machine Creation 

Services (MCS) 

Citrix Provisioning 

Services 

NetScaler 

1 

optional 

n/a 

Required for Pooled or Dedicated desktops. 

XenDesktop 5 only. 

Image cloning is not recommended at this 

deployment size. 

Not used with only a single XenDesktop 

Controller instance. 


NetScaler 

10 Gbps SAN Backbone 

SAN Array 

RAID RAID 

SAN Array 

RAID RAID 

SAN Array 

RAID RAID 


1,000-SEAT DEPLOYMENT 

Figure 5: 

Sample architecture for a 

1,000-seat deployment on 

Citrix XenDesktop 

Users' Location 

1,000 <strong>Pano</strong> Zero Clients 

This section provides information on sample architectures for 1,000-seat <strong>Pano</strong> <strong>System</strong> 

deployments on Citrix XenDesktop. 

DHCP 

Domain 

Servers 


2–4 Infrastructure Servers 


Controller 

Provisioning Server 


Services (XD5, optional) 


Services (optional) 

Data Center 

100 Mbps 

LAN 

100 Mbps / 

1 Gbps 

Edge 

Switches 

1 Gbps Edge Network 






1 Gbps Core Network 



Scalability 

Group 


Core Switch 

30–40 Desktop Servers 


<strong>Pano</strong> Direct 

Service 


VDA 

XenServer 

Tools 


Management 



For a 1,000-seat deployment, typically at least 30 to 40 desktop servers, depending on 

user workloads, will be needed to host the DVMs (see the Deployment Architecture 

Overview <strong>Redbook</strong> for information on evaluating user workloads). Two to four 

infrastructure servers are also required. 

Shared storage in the form of a SAN or NAS is typically essential for deployments of this 

size. Shared storage is needed to ensure that DVM images remain available in the event 

of a desktop server failure – something which is much more likely with up to 40 servers. It 

is also typically required to provide the high level of IOPS (30,000 to 50,000) needed for 

up to 1,000 active DVMs. 


Because we’re deploying over 500 seats, we are required to use a <strong>Pano</strong> Controller group 

that combines at least two <strong>Pano</strong> Controller instances to provide scalability in a 

master/slave configuration. 

If we also want to provide redundancy or failover capabilities in the event of server 



a third <strong>Pano</strong> Controller instance would be added and configured as a slave. 



Table 7: Summary of Hardware Needed for a Sample 1,000-Seat Deployment 


Desktop Servers 30-40 

Each with dual, quad-core Intel Westmere CPUs 

(E5620 or better) and 48-72 GB of RAM. Servers 

host XenServer or ESX hypervisor software and 

Windows DVMs. 


Servers 

Storage 

2-4 

Raw 

Capacity: 33 

TB 

Min. IOPS: 

40,000 

Deploy multiple <strong>Pano</strong> Controller instances in a 

<strong>Pano</strong> Controller group for scalability. Infrastructure 

servers host <strong>Pano</strong> Controller, XenDesktop 

Controller, the required supporting XenServer or 

ESX hypervisor and, optionally, Citrix Provisioning 

Services and NetScaler VPX. 


per user, plus 50 GB overhead for <strong>Pano</strong> Controller 

and XenDesktop VMs, with a limit of 80% capacity 

utilization and less the 20% RAID overhead. 

Requires SAN/NAS with at least 221 15K RPM 

SAS drives or 285 10K RPM drives, based on an 

allocation of 40 IOPS/DVM. 

Networking 

6-7 100 Mbps/1 Gbps switches for edge networks 

4-6 1 Gbps segments for the core network 

Management 


1 

Windows workstation is required to configure and 




Controller group and integration with XenDesktop Controller is made highly available by 

implementing an active/passive, two-node failover cluster using the two <strong>Pano</strong> Controller 

instances. <strong>Pano</strong> Controller is responsible for the initial connection to <strong>Pano</strong> Zero Clients 

and the display of login screens on the clients. 


This section discusses Citrix-specific factors that you should consider for 1,000-seat 

deployments. 

Creating DVM Templates 

You can optionally deploy Citrix Provisioning Services alongside Machine Creation 

Services to enables you to use a single DVM image template to create multiple DVM 

images on one or more desktop servers. This can greatly reduce the amount of storage 

required compared to other methods of creating DVM images and is typically most useful 

in deployments with 1,000 or more DVMs. 



Table 8: Summary of Software Needed for a Sample 1,000-Seat Deployment 



Two required for a <strong>Pano</strong> Controller scalability 

group; add one more for a failover group. (For 

redundancy, install additional <strong>Pano</strong> Controller 

instances on separate servers.) 

XenServer/ESX 

Hypervisor 

32-44 

One per server is required for both desktop and 

infrastructure servers. 

XenDesktop Controller 1 or 2 

For scalability, should be hosted on different 

servers than the DVMs and <strong>Pano</strong> Controller. 

Additional redundant Controller instances will 

be needed if you use a <strong>Pano</strong> Controller group 

or use multiple servers for higher availability. 


Services (PVS) 



1 

1 

Image cloning is optionally recommended at 

this deployment size to conserve storage 

space. 


(XenDesktop 5 only) 

NetScaler 1 

Required to load balance connections from 

<strong>Pano</strong> Controller VMs to multiple XenDesktop 

Controller instances. 

XenDesktop Controller Redundancy and NetScaler 

Deployments of this size may require more than one XenDesktop Controller. Multiple 

Controller instances can both increase performance or scalability and improve availability, 

when the Controllers are installed on different physical servers. If more than one 

XenDesktop Controller instance is deployed, a load balancer like NetScaler will also be 

needed so that <strong>Pano</strong> Controller can connect to all of them. See “Scalability and 

Redundancy on XenDesktop” on page 5 for information about XenDesktop Controller and 

NetScaler. 


NetScaler 

10 Gbps 

SAN Backbone 

SAN Array 

RAID RAID 

SAN Array 

RAID RAID 

SAN Array 

RAID RAID 


10,000-SEAT DEPLOYMENT 

Figure 5: 

Sample architecture for a 

10,000-seat deployment 

on Citrix XenDesktop 

Users' Location 

10,000 <strong>Pano</strong> Zero Clients 

This section provides information on sample architectures for 10,000-seat <strong>Pano</strong> <strong>System</strong> 

deployments on Citrix XenDesktop. 

DHCP 

Domain 

Servers 


20–40 Infrastructure Servers 



10 Provisioning Servers 


Services (XD5, optional) 


Services (optional) 

Data Center 

100 Mbps 

LAN 

100 Mbps / 

1 Gbps 

Edge 

Switches 

1 Gbps Edge Network 

<strong>Pano</strong> Controllers 

<strong>Pano</strong> Controllers 




1 Gbps Core Network 



Scalability 

Groups 


Core Switch 

300–400 Desktop Servers 


<strong>Pano</strong> Direct 

Service 


VDA 

XenServer 

Tools 


Management 



For a 10,000-seat deployment, typically at least 300 to 400 desktop servers, depending on 

user workloads, will be needed to host the DVMs (see the Deployment Architecture 

Overview <strong>Redbook</strong> for information on evaluating user workloads). Two to four 

infrastructure servers are also required. 

Shared storage in the form of a SAN or NAS is typically essential for deployments of this 

size. Shared storage is needed to ensure that DVM images remain available in the event 

of a desktop server failure – something which is much more likely with up to 400 servers. 

It is also typically required to provide the high level of IOPS (300,000 to 500,000) needed 

for up to 10,000 active DVMs. 


Because we’re deploying over 500 seats, we are required to use a <strong>Pano</strong> Controller group 

that combines at least two <strong>Pano</strong> Controller instances to provide scalability in a 

master/slave configuration. 

If we also want to provide redundancy or failover capabilities in the event of server 



a third <strong>Pano</strong> Controller instance would be added and configured as a slave. 



Table 7: Summary of Hardware Needed for a Sample 10,000-Seat Deployment 


Desktop Servers 300-400 

Each with dual, quad-core Intel Westmere CPUs 

(E5620 or better) and 48-72 GB of RAM. Servers 

host XenServer or ESX hypervisor software and 

Windows DVMs. 


Servers 

Storage 

20-40 

Raw 

Capacity: 

330 TB 

Min. IOPS: 

400,000 

Deploy multiple <strong>Pano</strong> Controller instances in a 

<strong>Pano</strong> Controller group for scalability. Infrastructure 

servers host <strong>Pano</strong> Controller, XenDesktop 

Controller, the required supporting XenServer or 

ESX hypervisor and, optionally, Citrix Provisioning 

Services and NetScaler VPX. 


per user, plus 50 GB overhead for <strong>Pano</strong> Controller 

and XenDesktop VMs, with a limit of 80% capacity 

utilization and less the 20% RAID overhead. 

Requires SAN/NAS with at least 221 15K RPM 

SAS drives or 285 10K RPM drives, based on an 

allocation of 40 IOPS/DVM. 

Networking 

60-70 100 Mbps/1 Gbps switches for edge networks 

4-6 1 Gbps segments for the core network 

Management 


1 

Windows workstation is required to configure and 




Controller group and integration with XenDesktop Controller is made highly available by 

implementing an active/passive, two-node failover cluster using the two <strong>Pano</strong> Controller 

instances. <strong>Pano</strong> Controller is responsible for the initial connection to <strong>Pano</strong> Zero Clients 

and the display of login screens on the clients. 


This section discusses Citrix-specific factors that you should consider for 10,000-seat 

deployments. 

Creating DVM Templates 

You can optionally deploy Citrix Provisioning Services alongside Machine Creation 

Services, to enables you to use a single DVM image template to create multiple DVM 

images on one or more desktop servers. This can greatly reduce the amount of storage 

required compared to other methods of creating DVM images and is typically most useful 

in deployments with 10,000 or more DVMs. 



Table 8: Summary of Software Needed for a Sample 10,000-Seat Deployment 



Two required for a <strong>Pano</strong> Controller scalability 

group; add one more for a failover group. (For 

redundancy, install additional <strong>Pano</strong> Controller 

instances on separate servers.) 

XenServer/ESX 

Hypervisor 

30-50 

One per server is required for both desktop and 

infrastructure servers. 

XenDesktop Controller 10 or 20 

For scalability, should be hosted on different 

servers than the DVMs and <strong>Pano</strong> Controller. 

Additional redundant Controller instances will 

be needed if you use a <strong>Pano</strong> Controller group 

or use multiple servers for higher availability. 


Services (PVS) 



10 

10 

Image cloning is optionally recommended at 

this deployment size to conserve storage 

space. 


(XenDesktop 5 only) 

NetScaler 1 

Required to load balance connections from 

<strong>Pano</strong> Controller VMs to multiple XenDesktop 

Controller instances. 

XenDesktop Controller Redundancy and NetScaler 

Deployments of this size may require more than one XenDesktop Controller. Multiple 

Controller instances can both increase performance or scalability and improve availability, 

when the Controllers are installed on different physical servers. If more than one 

XenDesktop Controller instance is deployed, a load balancer like NetScaler will also be 

needed so that <strong>Pano</strong> Controller can connect to all of them. See “Scalability and 

Redundancy on XenDesktop” on page 5 for information about XenDesktop Controller and 

NetScaler. 

<strong>Pano</strong> Remote is supported when using XenDesktop with the same functionality as on 

other virtualization platforms (except as noted under the “Differences on XenDesktop” 

section on page 17). <strong>Pano</strong> Remote uses the Microsoft Remote Desktop Protocol (RDP) to 

connect to virtual desktops and <strong>Pano</strong> Gateway. <strong>Pano</strong> Remote does not support Citrix 

HDX, ICA or the Citrix Access Gateway. 

Please see the online help on <strong>Pano</strong> Remote for specifications and instructions on how to 

install and configure <strong>Pano</strong> Gateway on Windows Server® Remote Desktop Services. 



This section describes the system workflow that occurs when an end user logs into the 

system using a <strong>Pano</strong> Zero Client. 

Figure 6: 

Login process of 

<strong>Pano</strong> Zero Client 

deployed on Citrix 



Zero Client 

1 

2 

DHCP Server 


3 

9 

8 

7 

4 

Active Directory 

<strong>Pano</strong> Direct Service 

Windows DVM 



6 

5 


Database 

This workflow assumes that the setup steps detailed in the online help have been 

completed and that the system architecture matches one of the descriptions above. 

1. DHCP – the <strong>Pano</strong> Zero Client connects to a DHCP server, receiving an IP 

address along with the address for the <strong>Pano</strong> Controller VM (provided the vendor 

class option has been configured in the DHCP server). 

2. Login Screen – depending on the selected <strong>Pano</strong> client discovery method, the 

<strong>Pano</strong> client contacts <strong>Pano</strong> Controller, which causes the <strong>Pano</strong> Zero Client to 

display a login screen. To log in, the end user enters their user name and 

password into the fields provided on-screen and presses the Login button (or the 

Enter key.) 

3. Credential Validation – the user credentials are transmitted by the <strong>Pano</strong> Zero 

Client to <strong>Pano</strong> Controller. <strong>Pano</strong> Controller submits these credentials to the 

directory service and receives validation (or rejection) from the directory service. 

4. Queries XenDesktop Connection Broker – upon successful authentication, 

<strong>Pano</strong> Controller queries the XenDesktop Controller by passing the user 

credentials to it. 

5. Credential Validation by XenDesktop – the XenDesktop Controller also 

validates the user credentials with the directory service. 

6. DVM Lookup – all associations between users and DVMs are managed by 

XenDesktop rather than <strong>Pano</strong> Controller. Because of this, the XenDesktop 

Controller checks its database for the list of DVMs to which the user is entitled. 

7. Determine specific DVM – the XenDesktop Controller returns a list of Desktop 

Groups to <strong>Pano</strong> Controller. If the user is entitled to multiple Desktop Groups, 

<strong>Pano</strong> Controller will automatically connect the user to the desktop most recently 

accessed. (If instead of clicking the Login button, the user clicks the Options 

button in Step (2), the user will be prompted to select the desired specific 

desktop from a list of available desktops.) 



8. Transfer of Control – <strong>Pano</strong> Controller next checks on the status of the <strong>Pano</strong> 

Direct Service running in the target DVM and ensures that it is ready to connect. 

Once ready, <strong>Pano</strong> Controller facilitates the connection between the <strong>Pano</strong> Zero 

Client and the <strong>Pano</strong> Direct Service on the appropriate DVM and steps aside – 

this is called a Transfer of Control. 

9. Session Established – the user is now connected to their desktop and all 

session traffic flows directly from the <strong>Pano</strong> Direct Service to the <strong>Pano</strong> Zero 

Client. <strong>Pano</strong> Controller and the XenDesktop Controller are no longer directly 

involved in the <strong>Pano</strong> session. 

<strong>Pano</strong> <strong>System</strong> 4.5 has a number of important differences and limitations when running on 

the Citrix XenDesktop platform: 

1. PDP rather than HDX Protocol: The <strong>Pano</strong> <strong>System</strong> does not use the Citrix HDX 

protocol. Instead, the <strong>Pano</strong> Direct Protocol (PDP) is used to connect a <strong>Pano</strong> Zero 

Client to a DVM. In order to establish this connection, the <strong>Pano</strong> Direct Service 

must be installed and running on the DVM. Simply installing the XenDesktop 

Virtual Desktop Agent is not sufficient. See “Provisioning and Managing DVMS” 

on page 4 for more information. 

2. No Roaming between <strong>Pano</strong>s and HDX Clients: There is limited interoperability 

between <strong>Pano</strong> Direct and Citrix HDX. For example, you cannot roam between 

<strong>Pano</strong> Zero Clients and HDX clients. Accessing the same DVM from <strong>Pano</strong> Zero 

Clients and HDX clients is not supported. 

3. Isolate HDX-<strong>Pano</strong> Desktops: You must maintain isolation between desktops 

that will be accessed using <strong>Pano</strong> Zero Clients and desktops that will be accessed 

using HDX clients. You can do this by configuring distinct desktop groups: those 

for use with <strong>Pano</strong> clients and those for use with ICA-HDX clients. 

4. PDS Installation Order: On Windows 7, when you install the <strong>Pano</strong> Direct 

Service, the login process using HDX will be disabled. The <strong>Pano</strong> Direct Service 

installer must be run after XenServer Tools and the XenDesktop Virtual Desktop 

Agent are installed. If you need to upgrade either of these Xen components, you 

must first uninstall the <strong>Pano</strong> Direct Service. After upgrading the Xen 

components, reinstall the <strong>Pano</strong> Direct Service. 

5. XenDesktop DVM Collection Required: When integrated with XenDesktop, one 

and only one DVM collection of type “XenDesktop” can be configured in <strong>Pano</strong> 

Controller. No additional DVM collections can be configured. This means that you 

will not be able to use device-based collections as part of a <strong>Pano</strong> <strong>System</strong> 

deployment on XenDesktop. 

6. <strong>Pano</strong> Options Dialog Limited: Because DVMs are managed by XenDesktop, 

end users are not able to restart, reset or trash a DVM from the Options dialog, 

which is part of the standard <strong>Pano</strong> Logic login screen. 

7. Two-factor Authentication Devices Not Supported: Smart card, biometric or 

other USB authentication devices are not supported 



More information can be found in these resources: 

• For detailed information on setting up and managing the <strong>Pano</strong> <strong>System</strong>, consult 

the online help available at help.panologic.com and the support knowledgebase 

in the <strong>Pano</strong> Logic Customer Center at support.panologic.com. 

• Specifications for the <strong>Pano</strong> <strong>System</strong> can be found in the <strong>Pano</strong> <strong>System</strong> Data Sheet 

at www.panologic.com/datasheet/panosystem. 

• Information on XenDesktop and trial software downloads can be found on the 

Citrix website at www.citrix/xendesktop. 

• Detailed capacity planning advice for server, storage, and network hardware can 

be found in the Infrastructure Sizing <strong>Redbook</strong> at 

www.panologic.com/redbook/infrastructure. 

• General information on <strong>Pano</strong> deployment planning, platform choices, scalability 

and redundancy options, best practices and sample architectures for 25-, 1,000-, 

and 10,000-seat deployments can be found in the Deployment Architecture 

Overview <strong>Redbook</strong> at www.panologic.com/redbook/overview. 

• Information on deployment planning for remote locations, such as branch offices, 

distributed facilities and mobile workers, can be found in the Remote 

Deployments <strong>Redbook</strong> at www.panologic.com/redbook/remote. 

To obtain a <strong>Pano</strong> <strong>System</strong> Starter Kit, visit store.panologic.com, email 

sales@panologic.com or call 650-454-8940/877-677-PANO. 

<strong>Pano</strong> Logic, Inc. 

2000 Seaport Blvd, Suite 200 

Redwood City, CA 94063 

This document was released in November 2011 and is specific to the features and capabilities of 

<strong>Pano</strong> <strong>System</strong> 5.0 [RB-PSCX-110211] 

© Copyright 2011 <strong>Pano</strong> Logic, Inc. 

<strong>Pano</strong>, <strong>Pano</strong> Logic, <strong>Pano</strong> Button, <strong>Pano</strong> Direct Protocol, and <strong>Pano</strong> Direct Technology are registered 

trademarks of <strong>Pano</strong> Logic, Inc. 

<strong>Pano</strong> Device, <strong>Pano</strong> Gateway, <strong>Pano</strong> Controller, <strong>Pano</strong> Remote, <strong>Pano</strong> Direct Service and <strong>Pano</strong> <strong>System</strong> 

are trademarks of <strong>Pano</strong> Logic, Inc.

Redbook - Pano System on Citrix XenDesktop - Pano Logic

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?