Following our launch of the new 13G-based XC series platform, I present our product architectures for the VDI-specific use cases. Of the platforms available, this use case is focused on the extremely powerful 1U XC630 with Haswell CPUs and 2133MHz RAM. We offer these appliances on both Server 2012 R2 Hyper-V and vSphere 5.5 U2 with Citrix XenDesktop, VMware Horizon View, or Dell vWorkspace.  All platform architectures have been optimized, configured for best performance and documented.

Platforms

We have three platforms to choose from optimized around cost and performance, all being ultimately flexible should specific parameters need to change. The A5 model is the most cost effective leveraging 8-core CPUs, 256GB RAM 2 x 200GB SSDs for performance and 4 x 1TB HDDs for capacity.  For POCs, small deployments or light application virtualization, this platform is well suited. The B5 model steps up the performance by adding four cores per socket, increasing the RAM density to 384GB and doubling the performance tier to 2 x 400GB SSDs. This platform will provide the best bang for the buck on medium density deployments of light or medium level workloads. The B7 is the top of the line offering 16-core CPUs and a higher capacity tier of 6 x 1TB HDDs. For deployments requiring maximum density of knowledge or power user workloads, this is the platform for you.

At 1U with dual CPUs, 24 DIMM slots and 10 drive bays…loads of potential and flexibility!

Solution Architecture

Utilizing 3 platform hardware configurations, we are offering 3 VDI solutions on 2 hypervisors. Lots of flexibility and many options. 3 node cluster minimum is required with every node containing a Nutanix Controller VM (CVM) to handle all IO. The SATADOM is present for boot responsibilities to host the hypervisor as well as initial setup of the Nutanix Home area. The SSDs and NL SAS disks are passed through directly to each CVM which straddle the hypervisor and hardware. Every CVM contributes its directly-attached disks to the storage pool which is stretched across all nodes in the Nutanix Distributed File System (NDFS) cluster. NDFS is not dependent on the hypervisor for HA or clustering. Hyper-V cluster storage pools will present SMB version 3 to the hosts and vSphere clusters will be presented with NFS. Containers can be created within the storage pool to logically separate VMs based on function. These containers also provide isolation of configurable storage characteristics in the form of dedupe and compression. In other words, you can enable compression on your management VMs within their dedicated container, but not on your VDI desktops, also within their own container. The namespace is presented to the cluster in the form of \\NDFS_Cluster_name\container_name.

The first solution I’ll cover is Dell’s Wyse vWorkspace which supports either 2012 R2 Hyper-V or vSphere 5.5. For small deployments or POCs we offer this solution in a “floating mgmt” architecture which combines the vWorkspace infrastructure management roles and VDI desktops or shared session VMs. vWorkspace and Hyper-V enables a special technology for non-persistent/ shared image desktops called Hyper-V Catalyst which includes 2 components: HyperCache and HyperDeploy. Hyper-V Catalyst provides some incredible performance boosts and requires that the vWorkspace infrastructure components communicate directly with the hyper-V hypervisor. This also means that vWorkspace does not require SCVMM to perform provisioning tasks for non-persistent desktops!

• HyperCache – Provides virtual desktop performance enhancement by caching parent VHDs in host RAM. Read requests are satisfied from cache including requests from all subsequent child VMs.
• HyperDeploy – Provides instant cloning of parent VHDs massively diminishing virtual desktop pool deployment times.

You’ll notice the HyperCache components included on the Hyper-V architectures below. 3 to 6 hosts in the floating management model, depicted below with management, desktops and RDSH VMs logically separated only from a storage container perspective by function. The recommendation of 3-7 RDSH VMs is based our work optimizing around NUMA boundaries. I’ll dive deeper into that in an upcoming post. The B7 platform is used in the architectures below.

Above ~1000 users we recommend the traditional distributed management architecture to enable more predictable scaling and performance of both the compute and management hosts. The same basic architecture is the same and scales to the full extent supported by the hypervisor, is this case Hyper-V which supports up to 64 hosts. NDFS does not have a scaling limitation so several hypervisor clusters can be built within a single contiguous NDFS namespace. Our recommendation is to then build independent Failover Clusters for compute and management discretely so they can scale up or out independently.

The architecture below depicts a B7 build on Hyper-V applicable to Citrix XenDesktop or Wyse vWorkspace.

This architecture is relatively similar for Wyse vWorkspace or VMware Horizon View on vSphere 5.5 U2 but fewer total compute hosts per HA cluster, 32 total. For vWorkspace, Hyper-V Catalyst is not present in this scenario so vCenter is required to perform desktop provisioning tasks.

For the storage containers, the best practice of less is more still stands. If you don’t need a particular feature don’t enable it, as it will consume additional resources. Deduplication is always recommended on the performance tier since the primary OpLog lives on SSD and will always benefit. Dedupe or compression on the capacity tier is not recommended, of course you absolutely need it. And if you do prepare to increase each CVM RAM allocation to 32GB.

Network Architecture

As a hyperconverged appliance, the network architecture leverages the converged model. A pair of 10Gb NICs minimum in  each node handle all traffic for the hypervisor, guests and storage operations between CVMs. Remember that the storage of all VMs is kept local to the host to which the VM resides, so the only traffic that will traverse the network is LAN and replication. There is no need to isolate storage protocol traffic when using Nutanix. 

Hyper-V and vSphere are functionally similar. For Hyper-V there are 2 vSwitches per host, 1 external that aggregates all of the services of the host management OS as well as the vNICs for the connected VMs. The 10Gb NICs are connected to a LBFO team configured in Dynamic Mode. The CVM alone connects to a private internal vSwitch so it can communicate with the hypervisor.

In vSphere it’s the same story but with the concept of Port Groups and vMotion.

We have tested the various configurations per our standard processes and documented the performance results which can be found in the link below. These docs will be updated as we validate additional configurations.

Product Architectures for 13G XC launch:

http://bit.ly/DellXCLib 

Resources:

About Wyse vWorkspace HyperCache

About Wyse vWorkspace HyperDeploy

SJbWUYl4LRCwFNcatHuG

Hyperconverged Web-scale Software Defined Storage (SDS) solutions are white hot right now and Nutanix is leading the pack with their ability to support all major hypervisors (vSphere, Hyper-V and KVM) while providing nearly unlimited scale. Dell partnering with Nutanix was an obvious mutually beneficial choice for the reasons above plus supplying a much more robust server platform. Dell also provides a global reach for services and support as well as solving other challenges such as hypervisors installed in the factory.

Nutanix operates below the hypervisor layer so as a result requires a lot of tightly coupled interaction with the hardware directly. Many competing platforms in this space sit above the hypervisor so require vSphere, for example, to provide access to storage and HA but they are also limited by the hypervisor’s limitations (scale).  Nutanix uses its own algorithm for clustering and doesn’t rely on a common transactional database which can cause additional challenges when building solutions that span multiple sites. Because of this the Nutanix Distributed Filesystem (NDFS) supports no known limits of scale. There are current Nutanix installations in the thousands of nodes across a contiguous namespace and now you can build them on Dell hardware.

Along with the Dell XC720xd appliances, we have released a number of complementary workload Product Architectures to help customers and partners build solutions using these new platforms. I’ll discuss the primary architectural elements below.

Wyse Datacenter Appliance Architecture for Citrix

Wyse Datacenter Appliance Architecture for VMware

Wyse Datacenter Appliance Architecture for vWorkspace

Nutanix Architecture

Three nodes minimum are required for NDFS to achieve quorum so that is the minimum solution buy in, then storage and compute capacity can be increased incrementally beyond by adding one or more nodes to an existing cluster. The Nutanix architecture uses a Controller VM (CVM) on each host which participates in the NDFS cluster and manages the hard disks local to its own host. Each host requires two tiers of storage: high performance/ SSD and capacity/ HDD. The CVM manages the reads/writes on each host and automatically tiers the IO across these disks. A key value proposition of the Nutanix model is data locality which means that the data for a given VM running on a given host is stored locally on that host as apposed to having reads and writes crossing the network. This model scales indefinitely in a linear block manner where you simply buy and add capacity as you need it. Nutanix creates a storage pool that is distributed across all hosts in the cluster and presents this pool back to the hypervisor as NFS or SMB.

You can see from the figure below that the CVM engages directly with the SCSI controller through which it accesses the disks local to the host it resides. Since Nutanix sits below the hypervisor and handles its own clustering and data HA, it is not dependent upon the hypervisor to provide any features nor is it limited by any related limitations.

From a storage management and feature perspective, Nutanix provides two tiers of optional deduplication performed locally on each host (SSD and HDD individually), compression, tunable replication (number of copies of each write spread across disparate nodes in the cluster) and data locality (keeps data local to the node the VM lives on). Within a storage pool, containers are created to logically group VMs stored within the namespace and enable specific storage features such as replication factor and dedupe. Best practice says that a single storage pool spread across all disks is sufficient but multiple containers can be used. The image below shows an example large scale XC-based cluster with a single storage pool and multiple containers.

While the Nutanix architecture can theoretically scale indefinitely, practicality might dictate that you design your clusters around the boundaries of the hypervisors, 32 nodes for vSphere, 64 nodes for Hyper-v. The decision to do this will be more financially impactful if you separate your resources along the lines of compute and management in distinct SDS clusters. You could also, optionally, install many maximum node hypervisor clusters within a single very large, contiguous Nutanix namespace, which is fully supported. I’ll discuss the former option below as part of our recommended pod architecture.

Dell XC720xd platforms

For our phase 1 launch we have five platforms to offer that vary in CPU, RAM and size/ quantity of disks. Each appliance is 2U, based on the 3.5” 12-gen PowerEdge R720XD and supports from 5 to 12 total disks, each a mix of SSD and HDD. The A5 platform is the smallest with a pair of 6-core CPUs, 200GB SSDs and a recommended 256GB RAM. The B5 and B7 models are almost identical except for the 8-core CPU on the B5 and the 10-core CPU on the B7. The C5 and C7 boast a slightly higher clocked 10-core CPU with doubled SSD densities and 4-5x more in the capacity tier. The suggested workloads are specific with the first three targeted at VDI customers. If greater capacity is required, the C5 and C7 models work very well for this purpose too.

For workload to platform sizing guidance, we make the following recommendations:

Here is a view of the 12G-based platform representing the A5-B7 models. The C5 and C7 would add additional disks in the second disk bay. The two disks in the rear flexbay are 160GB SSDs configured in RAID1 via PERC used to host the hypervisor and CVM, these disks do not participate in the storage pool. The six disks in front are controlled by the CVM directly via the LSI controller and contribute to the distributed storage pool across all nodes.

Dell XC Pod Architecture

This being a 10Gb hyperconverged architecture, the leaf/ spine network model is recommended. We do recommend a 1Gb switch stack for iDRAC/ IPMI traffic and build the leaf layer from 10Gb Force10 parts. The S4810 is shown in the graphic below which is recommended for SFP+ based platforms or the S4820T can be used for 10GBase-T.

In our XC series product architecture, the compute, management and storage layers, typically all separated, are combined here into a single appliance. For solutions based on vWorkspace under 10 nodes, we recommend a “floating management” architecture which allows the server infrastructure VMs to move between hosts also being used for desktop VMs or RDSH sessions. You’ll notice in the graphics below that compute and management are combined into a single hypervisor cluster which hosts both of these functions.

Hyper-V is shown below which means the CVMs present the SMBv3 protocol to the storage pool. We recommend three basic containers to separate infrastructure mgmt, desktop VMs and RDSH VMs. We recommend the following feature attributes based on these three containers (It is not supported to enable compression and deduplication on the same container):

You’ll notice that I’ve included the resource requirements for the Nutanix CVMs (8 x vCPUs, 32GB vRAM). The vRAM allocation can vary depending on the features you enable within your SDS cluster. 32GB is required, for example, if you intend to enable both SSD and HDD deduplication. If you only require SSD deduplication and leave the HDD tier turned off, you can reduce your CVM vRAM allocation to 16GB. We highly recommend that you disable any features that you do not need or do not intend to use!

For vWorkspace solutions over 1000 users or solutions based on VMware Horizon or Citrix XenDesktop, we recommend separating the infrastructure management in all cases. This allows management infrastructure to run in its own dedicated hypervisor cluster while providing very clear and predictable compute capacity for the compute cluster. The graphic below depicts a 1000-6000 user architecture based on vWorkspace on Hyper-V. Notice that the SMB namespace is stretched across both of the discrete compute and management infrastructure clusters, each scaling independently. You could optionally build dedicated SDS clusters for compute and management if you desire, but remember the three node minimum, which would raise your minimum build to 6 nodes in this scenario.

XenDesktop on vSphere, up to 32 nodes max per cluster, supporting around 2500 users in this architecture:

Horizon View on vSphere, up to 32 nodes max per cluster. supporting around 1700 users in this architecture:

Network Architecture

Following the leaf/ spine model, each node should connect 2 x 10Gb ports to a leaf switch which are then fully mesh connected to an upstream set of spine switches.

On each host there are two virtual switches: one for external access to the LAN and internode communication and one private internal vSwitch used for the CVM alone. On Hyper-V the two NICs are configured in a LBFO team on each host with all management OS vNICs connected to it.

vSphere follows the same basic model except for port groups configured for the VM type and VMKernel ports configured for host functions:

Performance results

The tables below summarize the user densities observed for each platform during our testing. Please refer to the product architectures linked at the beginning of this post for the detailed performance results for each solution.

Resources:

http://en.community.dell.com/dell-blogs/direct2dell/b/direct2dell/archive/2014/11/05/dell-world-two-questions-cloud-client-computing

http://blogs.citrix.com/2014/11/07/dell-launches-new-appliance-solution-for-desktop-virtualization/

http://blogs.citrix.com/2014/11/10/xendesktop-technologies-introduced-as-a-new-dell-wyse-datacenter-appliance-architecture/

http://blogs.vmware.com/euc/2014/11/vmware-horizon-6-dell-xc-delivering-new-economics-simplicity-desktop-application-virtualization.html

http://stevenpoitras.com/the-nutanix-bible/

http://www.dell.com/us/business/p/dell-xc-series/pd

Peter Fine here from Dell CCC Solution Engineering, where we just finished an extensive refresh for our XenApp recommendation within the Dell Wyse Datacenter for Citrix solution architecture.  Although not called “XenApp” in XenDesktop versions 7 and 7.1 of the product, the name has returned officially for version 7.5. XenApp is still architecturally linked to XenDesktop from a management infrastructure perspective but can also be deployed as a standalone architecture from a compute perspective. The best part of all now is flexibility. Start with XenApp or start with XenDesktop then seamlessly integrate the other at a later time with no disruption to your environment. All XenApp really is now, is a Windows Server OS running the Citrix Virtual Delivery Agent (VDA). That’s it! XenDesktop on the other hand = a Windows desktop OS running the VDA.

Architecture

The logical architecture depicted below displays the relationship with the two use cases outlined in red. All of the infrastructure that controls the brokering, licensing, etc is the same between them. This simplification of architecture comes as a result of XenApp shifting from the legacy Independent Management Architecture (IMA) to XenDesktop’s Flexcast Management Architecture (FMA). It just makes sense and we are very happy to see Citrix make this move. You can read more about the individual service components of XenDesktop/ XenApp here.

Expanding the architectural view to include the physical and communication elements, XenApp fits quite nicely with XenDesktop and compliments any VDI deployment. For simplicity, I recommend using compute hosts dedicated to XenApp and XenDesktop, respectively, for simpler scaling and sizing. Below you can see the physical management and compute hosts on the far left side with each of their respective components considered within. Management will remain the same regardless of what type of compute host you ultimately deploy but there are several different deployment options. Tier 1 and tier 2 storage are comprehended the same way when XenApp is in play, which can make use of local or shared disk depending on your requirements. XenApp also integrates nicely with PVS which can be used for deployment and easy scale out scenarios.  I have another post queued up for PVS sizing in XenDesktop.

From a stack view perspective, XenApp fits seamlessly into an existing XenDesktop architecture or can be deployed into a dedicated stack. Below is a view of a Dell Wyse Datacenter stack tailored for XenApp running on either vSphere or Hyper-v using local disks for Tier 1. XenDesktop slips easily into the compute layer here with our optimized host configuration. Be mindful of the upper scale utilizing a single management stack as 10K users and above is generally considered very large for a single farm. The important point to note is that the network, mgmt and storage layers are completely interchangeable between XenDesktop and XenApp. Only the host config in the compute layer changes slightly for XenApp enabled hosts based on our optimized configuration.

Use Cases

There are a number of use cases for XenApp which ultimately relies on Windows Server’s RDSH role (terminal services). The age-old and most obvious use case is for hosted shared sessions, i.e. many users logging into and sharing the same Windows Server instance via RDP. This is useful for managing access to legacy apps, providing a remote access/ VPN alternative, or controlling access to an environment through which can only be accessed via the XenApp servers. The next step up naturally extends to application virtualization where instead of multiple users being presented with and working from a full desktop, they simply launch the applications they need to use from another device. These virtualized apps, of course, consume a full shared session on the backend even though the user only interacts with a single application. Either scenario can now be deployed easily via Delivery Groups in Citrix Studio.

XenApp also compliments full XenDesktop VDI through the use of application off-load. It is entirely viable to load every application a user might need within their desktop VM, but this comes at a performance and management cost. Every VDI user on a given compute host will have a percentage of allocated resources consumed by running these applications which all have to be kept up to date and patched unless part of the base image. Leveraging XenApp with XenDesktop provides the ability to off-load applications and their loads from the VDI sessions to the XenApp hosts. Let XenApp absorb those burdens for the applications that make sense. Now instead of running MS Office in every VM, run it from XenApp and publish it to your VDI users. Patch it in one place, shrink your gold images for XenDesktop and free up resources for other more intensive non-XenApp friendly apps you really need to run locally. Best of all, your users won’t be able to tell the difference!

Optimization

We performed a number of tests to identify the optimal configuration for XenApp. There are a number of ways to go here: physical, virtual, or PVS streamed to physical/ virtual using a variety of caching options. There are also a number of ways in which XenApp can be optimized. Citrix wrote a very good blog article covering many of these optimization options, of which most we confirmed. The one outlier turned out to be NUMA where we really didn’t see much difference with it turned on or off. We ran through the following test scenarios using the core DWD architecture with LoginVSI light and medium workloads for both vSphere and Hyper-V:

• Virtual XenApp server optimization on both vSphere and Hyper-V to discover the right mix of vCPUs, oversubscription, RAM and total number of VMs per host
• Physical Windows 2012 R2 host running XenApp
• The performance impact and benefit of NUMA enabled to keep the RAM accessed by a CPU local to its adjacent DIMM bank.
• The performance impact of various provisioning mechanisms for VMs: MCS, PVS write cache to disk, PVS write cache to RAM
• The performance impact of an increased user idle time to simulate a less than 80+% concurrency of user activity on any given host.

To identify the best XenApp VM config we tried a number of configurations including a mix of 1.5x CPU core oversubscription, fewer very beefy VMs and many less beefy VMs. Important to note here that we based on this on the 10-core Ivy Bridge part E5-2690v2 that features hyperthreading and Turbo boost. These things matter! The highest density and best user experience came with 6 x VMs each outfitted with 5 x vCPUs and 16GB RAM.  Of the delivery methods we tried (outlined in the table below), Hyper-V netted the best results regardless of provisioning methodology. We did not get a better density between PVS caching methods but PVS cache in RAM completely removed any IOPS generated against the local disk. I’ll got more into PVS caching methods and results in another post.

Interestingly, of all the scenarios we tested, the native Server 2012 R2 + XenApp combination performed the poorest. PVS streamed to a physical host is another matter entirely, but unfortunately we did not test that scenario. We also saw no benefit from enabling NUMA. There was a time when a CPU accessing an adjacent CPU’s remote memory banks across the interconnect paths hampered performance, but given the current architecture in Ivy Bridge and its fat QPIs, this doesn’t appear to be a problem any longer.

The “Dell Light” workload below was adjusted to account for less than 80% user concurrency where we typically plan for in traditional VDI. Citrix observed that XenApp users in the real world tend to not work all at the same time. Less users working concurrently means freed resources and opportunity to run more total users on a given compute host.

The net of this study shows that the hypervisor and XenApp VM configuration matter more than the delivery mechanism. MCS and PVS ultimately netted the same performance results but PVS can be used to solve other specific problems if you have them (IOPS).

* CPU % for ESX Hosts was adjusted to account for the fact that Intel E5-2600v2 series processors with the Turbo Boost feature enabled will exceed the ESXi host CPU metrics of 100% utilization. With E5-2690v2 CPUs the rated 100% in ESXi is 60000 MHz of usage, while actual usage with Turbo has been seen to reach 67000 MHz in some cases. The Adjusted CPU % Usage is based on 100% = 66000 MHz usage and is used in all charts for ESXi to account for Turbo Boost. Windows Hyper-V metrics by comparison do not report usage in MHz, so only the reported CPU % usage is used in those cases.

** The “Dell Light” workload is a modified VSI workload to represent a significantly lighter type of user. In this case the workload was modified to produce about 50% idle time.

†Avg IOPS observed on disk is 0 because it is offloaded to RAM.

Summary of configuration recommendations:

• Enable Hyper-Threading and Turbo for oversubscribed performance gains.
• NUMA did not show to have a tremendous impact enabled or disabled.
• 1.5x CPU oversubscription per host produced excellent results. 20 physical cores x 1.5 oversubscription netting 30 logical vCPUs assigned to VMs.
• Virtual XenApp servers outperform dedicated physical hosts with no hypervisor so we recommend virtualized XenApp instances.
• Using 10-Core Ivy Bridge CPUs, we recommend running 6 x XenApp VMs per host, each VM assigned 5 x vCPUs and 16GB RAM.
• PVS cache in RAM (with HD overflow) will reduce the user IO generated to disk almost nothing but may require greater RAM densities on the compute hosts. 256GB is a safe high water mark using PVS cache in RAM based on a 21GB cache per XenApp VM.

Resources:

Dell Wyse Datacenter for Citrix – Reference Architecture

XenApp/ XenDesktop Core Concepts

Citrix Blogs – XenApp Scalability

Citrix currently has 4 flavors of XenApp (XA) being actively sold on the open market: XenApp Fundamentals for server 2008, XenApp 5 for Server 2003, XenApp 5 for Server 2008, and XenApp 6 for Server 2008 R2. For the most part these all look and feel the same from an end user experience perspective. The value for XenApp in my environment is twofold: managing legacy “problem” applications centrally and providing a secure remote access alternative to traditional VPN for my users. While it’s tempting to jump straight to XA6, my first objective prevents this as many of my problem business applications won’t run on Server 2008 R2 (Windows 7) nor on a 64-bit OS. 

Another tool in the Citrix arsenal is application streaming which is the new, and only, version of application isolation. Streaming is available on Advanced, Enterprise, and Platinum versions of XA and there is a special installation method to enable this on Advanced. Streaming is similar to VMware’s ThinApp product where apps are built (profiled) separately on a workstation but published through Citrix. Another advantage is that you can stream directly to the client which will use the client’s hardware resources to run the app taking the load off of the server. Some published limitations exist for streamed apps, however, that include anything requiring special drivers or certain .NET apps.

Planning and design

Unlike XA Fundamentals, the full version of the product contains several roles which can all be distributed depending on your environment. The basic server functions in a XA farm are infrastructure servers and application publishing servers. Infrastructure servers handle the functions not related to directly presenting applications to end users. These roles include licensing, data store, zone data collector, web interface, and XML service broker. These roles are well documented and all relate to farm communication and user application presentation. Best practice is to have at least one infrastructure server that will not publish apps to your users and then at least one publishing server. This design model scales easily depending on the size of your organization and performance requirements.

My deployment will consist of 5 servers, all server 2008 R1 x86, all VMs, running on a highly-available ESX4 cluster. 1 x infrastructure server, 3 x publishing servers, and 1 Citrix Secure Gateway (CSG) server. My infrastructure server will host all core roles including the Web Interface (WI) to publish the PNAgent config.xml. Given the size of my organization I have no need to house the data store in a full blown SQL server so I will use the local SQL Express option. Even smaller organizations can use an Access database as well.

My 3 publishing servers will be configured in dual-mode to host both published and streamed apps. 2 of the servers will host identical applications so connections can be load-balanced while the third will be used to host a business application that can only be used with Office 2003. I plan to stream these 2 apps together but I also want to be able to publish these apps externally via a web interface.

My CSG server will be configured to run the gateway and WI for external users to connect to. It will  be configured in a single-hop DMZ design. Dual-hop would separate the CSG from the WI on different servers in different DMZs but I don’t have a need to do that now. The firewall will need to be configured to allow the CSG server to talk to each of the publishers via TCP/1494 (ICA), TCP/2598 (session reliability), and TCP/80 for the XML service (optionally configured to use HTTPS). The CSG will also need to be able to talk to the infrastructure server on TCP/80 for XML/ STA (Secure Ticket Authority) services. There is no need to open anything further to the infrastructure server.

Here is the logical architecture for my deployment:

Infrastructure Server Installation

There are plenty of walk-throughs that take you step-by-step through the install process, check out http://www.dabcc.com for some good ones. I want to discuss some of the less documented gotchas that I ran across during my build-out. One of my big complaints with XA5 is the handling of pre-requisites. While this is much improved in XA6, XA5 is pretty painful in this regard depending on which components you install. There are 3 main roles that will be needed on the infrastructure server: terminal services, application server, and web server. My TS licensing is hosted on another server so I only need to install the actual TS component. Please note that EVERY XA server that you turn up, including the infrastructure server, requires terminal services to be installed. Even though your infrastructure server will not be publishing apps, it will be fully capable of doing so. XA cannot be installed without the TS role installed first!

Each component of the XA setup wizard will prompt you for the role services that it needs for the install to complete, but you will have to restart the wizard each time if you are missing anything.  To save you the trouble ensure that the following IIS role services are installed before you launch setup (make sure to also enable Windows Authentication under security, not shown):

Optionally add the COM+ Network Access role service to the Application Server role if you want to be able to remotely manage your server from the Access Management Console (AMC):

You will also need the latest x86 JRE installed for the licensing server component. Important to note is that you will need the x86 JRE even on an x64 server!

If you plan to use SQL Express for the data store, go ahead and get this ready now as well because the setup wizard will not do it for you. Run SetupSqlExpressForCPS.cmd in DVDRoot\Support\SqlExpress_2005_SP2. It will instal SQL Express 2005 SP2 and create a database called CITRIX_METAFRAME that the XA setup will look for if you choose the SQL Express installation option. Citrix strongly recommends that you do not install SQL Server on your XA server, only Access or SQL Express.

With those pieces installed you should be good to kick off the XA installer. XA5 doesn’t really break out individual roles like “XML broker” or “zone data collector”, much of it is implied. Such as the first server in a farm automatically becomes the XML broker, STA, and zone data collector. All servers will run the XML Service but only the XML broker will be running IIS which can share the same port. Any of the servers are capable of becoming the Zone Data Collector, controlled via election preferences, which is controlled in the Advanced Configuration tool. If you are installing Advanced Edition and plan to use Application Streaming, you must run the Platinum Edition installer! The server edition will be changed later in the AMC.

Select the Application Virtualization option next which will launch the installer for all common components. On your infrastructure server enable all options, for you publishers all you need is the Access Management Console and XenApp:

Here is why you run the Platinum installer with the intention of ultimately running Advanced Edition, the Advanced installer does not have this option available:

Each component will install separately and can be upgraded individually. This will provide you with the base install. There are 2 additional categories of installables after the base install: hotfixes and feature packs (FP). Hotfixes are provided per OS platform and are installed sequentially, each requiring a reboot. The feature pack, currently FP3 for XA5, includes upgrades to individual server components installed individually, such as the AMC, License server, plugins, Secure Gateway, and WI. Install your required hotfixes then upgrade the individual components included in the FP. You may not need everything in the pack. For Server 2008 R1 x86 I have the following hotfixes installed on each server in my farm. There will eventually be a hotfix rollup that bundles these but not as of this writing. I installed these in order:

XAE500W2K8005.msp
XAE500W2K8017.msp
XAE500W2K8018.msp
XAE500W2K8030.msp
XAE500W2K8042.msp
XAE500W2K8049.msp

Don’t forget to also upgrade the online and offline plugins on all XA servers! 

[Advanced only] Once installation is complete and all desired components are updated, launch the AMC, run the discovery process, navigate to your server and set the server edition to Advanced. This will allow proper licensing to work and make your publishers streaming capable:

Repeat this process on all XA servers and you’ll be ready to start installing and publishing apps. The first time you run the AMC it will run discovery on the environment, uncheck the Password Manager piece or you will get errors, unless you installed single-sign on with Platinum. The very next thing you should do is create the XenApp Services Site that clients using the online plugin will connect to. Under the Citrix Web Interface Console, right-click the XA Services Site and click create site. Once the PNAgent site is set up, right click it in the WI Console for a number of configuration options. I chose to enable pass-through authentication and made it the default, as well as enabled dual-mode for resource types, for starters. Publishing apps is fairly self-explanatory. Install the on/offline plugins on your client’s PCs and when they are granted access to applications they will see them either in the plugin, the start menu, desktop, or all three.

Citrix Secure Gateway

Both the Citrix Access Gateway (CAG) and Secure Gateway solutions accomplish the same thing, the difference being that the CAG is an appliance (not free) and the CSG (free) runs on a Windows server. The installation process is similar although you can skip right to the latest versions of both the WI and CSG. You will need a valid SSL cert on this server as it will be public facing and accepting only secure connections. When you generate your Cert request (CSR) make sure to choose at least 2048-bits as most CAs are requiring this as a minimum now. This will generate a 256-bit certificate for your site.

My goal was to provide an HTTP redirect to the gateway, so clients can connect to http, as well as host the WI on a TCP port not opened to the world. By default the WI will install into the default IIS site bound to TCP/80. I created a new site, bound to tcp/8080, where the WI would live. I left a single page in the default site that performs a simple redirect to tcp/443. The CSG is the only service that should be listening on this port. Run the WI installer first and create your XenApp Web Site in the new IIS site with port 8080. Once your new certificate is installed on your server you can run the CSG Configuration Wizard. It should find your new cert. Most of the defaults in the configuration wizard can be accepted. You will need to specify your STA server (infrastructure), as well as specify where the WI lives. If you follow my example you will need to tell the CSG that the WI is installed on the same server on TCP/8080.

Make sure to set up your WI site properly with your farm info and the appropriate secure access method. Direct is the simplest unless you’re using NAT between your DMZ and inside networks in which case you’d use gateway alternate or gateway translated. Customize your WI appearance how you like and assuming all firewall changes are in place you should now be able to access the WI externally.

At a high-level that’s it for my architecture. Citrix is a deep well and there are obviously a ton of other options and features that one could deploy. Another consideration worth pondering is user profiles. Citrix recommends using roaming TS profiles centrally stored on NAS or SAN to ensure a consistent user experience. This is easily enforced via GPO which I have employed and it works well. In combination with folder redirection this provides a very solid solution for managing your Citrix resources.

While it is ok to mix x86 and x64 servers in your XA farm, consider the implications this will have on program installations and user profiles. Published apps are defined via paths to their executables so if these paths are not the same on all of your servers you will have to make special concessions (c:\program files vs c:\program files (x86)). There are also additional differences in appdata folders used by some applications for x64 or x86 platforms. Many have had luck using the Flex Kit for managing profiles in these environments.

Although not cheap, XenApp 5 provides a very slick application delivery solution. XA5 Advanced costs in the neighborhood of $250/CCU and you also need to buy TS CALs as well. Enterprise and Platinum Editions increase costs significantly. The basic RemoteApp functionality baked into Server 2008 works well but at the sacrifice of granular presentation management, detailed performance tuning, and easy scalability. Citrix doesn’t care how many servers you put in your farm or what roles you run where, it’s all about the CCU licenses. Citrix and Microsoft have a very cohesive relationship going way back so XenApp will integrate seamlessly into your environment. One thing to watch out for is XenApp component changes to your servers after installation. I’ve noticed some finicky behavior specifically with regard to the license server component and having to reinstall it to get it working correctly again. 

Resources:

Application Streaming with XenApp Advanced

XenApp 5 Installation Guide

Citrix Secure Gateway Admin Guide

Web Interface 5.0.1 Admin Guide