The design of a XenApp infrastructure is a complex task that requires a good knowledge of XenApp components. Taking the right decisions in the design phase may also greatly help system administrators to expand XenApp farms for satisfying new business requirements or to improve the user experience.
In this chapter you will learn:
The key components of a XenApp infrastructure
How those components work together
The best practices by Citrix and some suggestions from my experience to design an architecture that respects initial requirements and is scalable for new needs
How to implement Provisioning Services to deploy new session host servers
How to run a load test using Citrix Load Testing
A XenApp infrastructure is composed of two main elements:
Regardless of your farm size, it is recommended to have at least one server dedicated to infrastructure services.
XenApp 6.5 introduces a new server mode, session-only, for servers that only host published applications as shown in the following screenshot:
You can run your XenApp farm on physical servers or on virtual servers.
Citrix supports XenApp running on the following hypervisors:
My suggestion is to deploy your farm in a virtual environment; the use of a virtual environment makes possible to deploy new servers in minutes, without the need of buying physical hardware. In the design phase, this means you may choose to split the components on different servers and you may count on the high-availability features of the hypervisor. When the farm is in production, this means you may more easily deploy new servers to fulfill new business requirements or to improve performances.
A XenApp farm requires some infrastructure components that run on servers deployed with the controller role. Depending on the size of your farm, you may choose to install all these components on the same server or to scale them on different servers.
The data store is the repository for all the static information of your farm (farm, servers and applications configurations, administrative accounts, and so on).
Each session-host server in your farm needs a constant connection to the data store. When the Independent Management Architecture (IMA) service starts, it queries the data store and stores the farm configuration in the local host cache (LHC). Every 30 minutes, the IMA service then contacts the data store to ensure that its LHC is consistent.
If you deploy your session-host servers specifying the session-only mode, you may reduce the data store load and make the startup and join processes faster, as they require less data during the join and sync process.
Note
Refer to Citrix Knowledge Base (http://support.citrix.com/article/CTX114501) for the list of supported databases by different Citrix products.
During the setup wizard, you are asked to choose a database. You can choose New database to install a local instance of SQL Server Express or Existing Microsoft SQL Server database to use a database server already present on your network.
The free SQL Server Express is suitable for small (< 100 servers) farms, while for bigger farms I strongly suggest the use of an enterprise-level database server, possibly in a high availability configuration (such as Microsoft Cluster, Oracle RAC). If the data store is unavailable you can't make changes to the configuration of your farm; moreover if servers reboot, the IMA service won't start and they will no longer publish applications.
In both the cases you should not install other components on the servers that run your database.
XenApp does not usually require much storage for the database. A typical storage requirement is as follows:
Number of servers |
Number of applications |
Database size |
---|---|---|
10 |
50 |
50 MB |
100 |
250 |
140 MB |
1000 |
1000 |
500 MB |
The data collector manages all the dynamic information of your farm (active and disconnected sessions, server loads, and so on). It also performs resolutions, that is, when a user requires an application, the data collector finds the least loaded server that can run that application.
It is, therefore, a key component in the application startup process. A slowness in the resolution process increases the overall time a user has to wait before the requested application is launched.
You need one data collector for each zone in your farm. A zone is a configurable grouping of XenApp servers; a farm requires at least one zone and all your servers must belong to a zone.
The main purpose to configure zones is to create a hierarchical structure to efficiently distribute changes:
Servers in a zone notify changes to the data collector of that zone using high-speed links (LAN)
The data collector then replicates those changes to data collectors of the other zones, usually through slow-speed links (WAN)
Zones are useful in a geographically distributed topology; for example, when your company has more than one site connected with WAN links. Zones are not necessary to divide servers in the same site. I worked with XenApp farms with more than 500 servers in one zone.
Citrix recommends keeping the number of zones in your farm to a minimum with one being optimal. Every time a dynamic event occurs, indeed the data collector of that zone must forward the event to the data collectors of the other zones: this replication consumes CPU and bandwidth.
The following figure is a flowchart by Citrix that helps to decide how many zones you need to deploy:
Data collector stores the entire event in the RAM memory. Its consumption depends on the farm size (number of servers, applications, and so on) and usage (number of active sessions and so on). However, this is usually not significant; for example, a data collector in a large farm (about 500 servers) I administer, uses an average of 250 MB of memory. Similarly, CPU usage is not significant. It may increase only if you create several zones in your farm but this is a discouraged practice. Anyhow, I strongly suggest you to dedicate one server to act as the zone data collector; if the data collector is running on a server that also publishes applications, it may experience resource contention and the resolution process may slow down.
Farms choose the data collector for each zone with an election between all the servers in the zone that can run the component (session-host only servers are excluded). XenApp administrators may change the election preference for each server to statically choose which server will be the data collector for the zone. The following screenshot displays the election preference options for the data collector:
Set the election preference to Most Preferred only on the dedicated server to be sure it will be chosen as the data collector during the election process.
If the data collector becomes unavailable, a new election is performed. You may also consider to define the backup server (a second dedicated server or a server running rarely used applications) setting its election preference to Preferred. The other servers in the farm should keep the default value (Default Preference).
The XML Broker is a component used by the Web Interface to retrieve information about the published applications. When a user logs on to the Web Interface, it displays the list of applications retrieved from the XML service to the user. When the user selects an application, the XML Broker responds with the address of a server running that application.
As the XML Broker works closely with the data collector, it is recommended that you install the XML Broker on the same server running the data collector component. If you add more XML Broker servers, you can configure the Web Interface or add an external load balancer (for example, a Citrix NetScaler) to balance the requests between them. The following screenshot displays the option of selecting an XML Broker server for load balancing:
The license server stores and manages Citrix licenses. The first time a user connects to a XenApp server, the server checks out a license for the user. Subsequent connections of the same user share the same license.
A single license server is enough for farms with thousands of servers and users; you could install a second license server in your farm but the two servers cannot share licenses. Because the license server is contacted when the user connects to a XenApp server, slow responses may increase the login time. You should place the license service on a dedicated server or, in case of small farms, on a server that doesn't publish applications. The license server process is single-threaded so multiple processors do not increase its performance.
If the license server is not available, all the servers in your farm enter a grace period of 720 hours; during this period users are still allowed to connect. This means that you usually don't need a high-availability solution for your license server. If a server fault occurs, you can install a new license server during the 30 days of the grace period or power on a second license server you prepared and kept turned off (cold standby).
The Web Interface provides users access to the published application through a web browser. It's an application running on IIS 7 Web Server and developed in Java/.NET.
A single Web Interface, running on a Dual Core Xeon Server, can handle up to 7 to 8 requests per second. You should expect many connections to the Web Interface when the users arrive at work in the morning or after lunch, so size your Web Interface server based on the number of users you expect will log on at the same time.
A tip to provide high availability and load balancing for this component is to deploy two Web Interface servers and balance the incoming connections using an external HTTP load balancer, as shown in the following diagram:
Session host servers publish and run the applications in your farm. Correctly sizing these servers is one of the most critical tasks during the design of your infrastructure; if you underestimate the servers, users will eventually complain about application slowness or worse, some users won't be able to run them at all. If you overestimate them, your boss will probably complain about the cost of the project.
The number of servers you need and their hardware configuration depends on the number of users and applications, but even more on the kind of the applications and how you deliver them to the users. My suggestion is to set up a test farm and to use it to verify the load each application produces. Later in this chapter you'll learn how to use Citrix EdgeSight for Load Testing to simulate real users.
Citrix XenApp supports five ways to deliver applications to the users. Each method has pros and cons and the choice of one or another highly changes the resource requirements of the session host servers. The methods are explained in the following sections:
Applications are installed on the server. When a user launches an application, it runs on the server. Session host servers, therefore, require sufficient resources (CPU and RAM) for the applications, while user devices may be lightweight devices (thin clients, tablets, and smartphones). No offline access is possible.
Applications are put in profiles and stored on a file or web server. When a user launches an application, this streams to the server where the execution takes place. Session host servers still require sufficient resources (CPU and RAM) for the applications, while user devices don't. No offline access is possible.
Applications are put in profiles and stored on a file or web server. When a user launches an application, this streams to the user device. This device must have enough resources to run the application and must run Windows OS. Applications are cached on the user device, so offline access is possible.
Applications are put in profiles and stored on a file or web server. When a user launches an application, XenApp tries to stream it to the user device. If this is not possible – the device runs an unsupported OS – the application is streamed to the server. This is a more versatile method, but session host servers still require sufficient resources to run the applications in the backup mode.
The traditional and most common method to deliver applications is to install them on the session host servers. Two strategies available for placing applications on servers are: siloed and nonsiloed.
In this approach applications are installed on small groups of servers; you could even have servers running a single application. Applications are usually grouped by their use, for example, all the applications used by the Financial department are installed on the same servers, while the applications used by the HR department are installed on different servers.
This approach is sometimes required if your applications have different hardware requirements or may cause conflicts if installed on the same server. Some application vendors, moreover, don't consider a different licensing if their applications are published through XenApp. So if you pay license fees simply counting the number of installations, you may reduce the cost of installing them on a small number of servers.
In this approach all the applications are installed on all the servers. This approach is more efficient as it reduces the number of required servers and it may also improve the user experience because it allows users to share the same server session with different applications. If you're using Provisioning Services, a nonsiloed approach also helps you to reduce the number of different vDisks you have to create and maintain.
My suggestion is to use the nonsiloed approach when possible. Later in this book you'll learn that, with worker groups, you will still be able to logically group applications on servers even with this approach.
The Provisioning Services infrastructure allows computers to be provisioned from a single shared image. This technology is widely used in XenDesktop, the desktop virtualization product by Citrix. System administrators prepare a small pool of images and, using Provisioning Services, deploy them to the users. Provisioning Services also becomes very helpful in a XenApp infrastructure, when you need to deploy several session host servers.
The use of this technology offers many benefits. With Provisioning Services, system administrators create and maintain a small number of images (or a single image if all the applications are installed on all the servers) for their servers. If a new application has to be published or an update for an installed application is available, the administrator only has to modify the "master" image and when servers reboot, the change will be deployed on every farm. Server consistency is so assured that there's no risk that some of your servers weren't updated or still run the older version of the application. You may also perform a test of the new image assigning it to a couple of test servers and, if everything is ok, deploy it to the production servers.
If something goes wrong (the updated application doesn't work, an installed patch conflicts with some other component, and so on) and you kept the previous version of the image, a rollback is very easy. Just assign the old image to your servers and reboot them.
Provisioning Services also help to reduce storage costs. The image is streamed via network from a central repository; a local storage is usually required for runtime data caching, but in some scenarios you can remove it entirely.
The use of Provisioning Services certainly requires some more effort during the installation phase, but from my experience I suggest you to consider using this feature if your farm has more than 5 to 10 servers. The time you spend to deploy the Provisioning Services infrastructure is less than the time you would spend for the daily tasks to maintain your farm. In the following sections, you will learn the key concepts of this technology; for a real implementation, please refer to the Citrix documentation.
The Provisioning Services infrastructure is composed by several components.
At a minimum, you need:
A license server; it could be the same license server in your XenApp farm.
A database; you can place Provisioning Services database on the same database server that hosts your farm's data store.
One or more Provisioning Servers; these run stream services, the software used to stream virtual images to provisioned servers.
A store, where the images of your servers are saved. You can place the store on the Provisioning Servers or on an external file server.
The following diagram displays the Provisioning Services infrastructure:
A Provisioning Services infrastructure is logically divided into a hierarchy of items.
When you install your first Provisioning Server (PVS), a new farm is created. Do not confuse this farm with the farm of your XenApp infrastructure; they don't share configurations or items. A Provisioning Services farm may serve more XenApp and XenDesktop farms.
A farm contains three major components:
Sites
Views
Stores
Provisioning Services sites allow administrators to logically group items that belong to the same physical site (for example, all the resources located in the headquarters or in a branch office). You need at least one site, which is created when you install your first Provisioning Server. Administrators may create different sites to delegate administrative tasks. You can indeed create accounts that can only administer items in a given site.
A site contains some elements, the most important of them are:
A target device belongs to one device collection. Views provide an alternative method for grouping and managing target devices; a target device may indeed belong to different views. You can create views at farm level or at site level; a view at site level may only contain devices from the same site, while views at farm level may contain all the target devices in that farm.
You can perform some administrative tasks at view level, so views become useful with a large number of target devices. For example, you can reboot all the session host servers that publish an application adding them to a view and issuing the Restart... command at the view folder.
A store is a storage location where you save your vDisks. It may be a local hard disk or a network share.
vDisks are disk image files. They consist of a .vhd
file (contains the data of the virtual disk), any properties files (.pvp
, contain disk geometry, and configuration), and, if applicable, a chain of differencing disks (.avhd
).
vDisks may be configured in the following two modes:
In shared image mode, target devices can only read the content of the vDisk. Write requests can be cached in four different ways as follows:
In cache on device hard drive option, write requests are cached on a local hard drive of the target. This is the most common setup, as it frees up the Provisioning Server and doesn't require a large amount of RAM memory. Target servers must have a local hard drive.
In cache in device RAM option, write requests are cached in the target device's memory. This is the fastest method for caching but consumes memory of the target device, reducing the total memory available for running applications.
In cache on a server option, write requests are handled by the Provisioning Server and cached on a temporary file; in the Store properties you can set the location of these files. This method should be used only if the target device doesn't have a local storage because it increases the network usage and the Provisioning Server load.
All the previous options are volatile; write cache is lost when the target device reboots. With the cache on a server persistent option, you can set the cache file to be persistent: Provisioning Server creates a cache file for each target device and doesn't clean it if the target reboots. A drawback is that any changes to the original vDisk invalidate all the cache files.
Note
Invalid cache files are not automatically deleted. Remember to periodically check if any exist and manually delete them to free some space.
The following screenshot displays the different ways of caching write requests to disks:
When a target device boots, it first needs a bootstrap program, a small software that runs before the operating system. Provisioning Services use a particular bootstrap program to set up the streaming session with a Provisioning Server. Through this session the target device is then able to receive the assigned vDisk and boot the operating system.
Provisioning Services supports three ways to send the bootstrap program to a target device:
The most common configuration is the use of a DHCP server. You can configure an existing DHCP server in your network or use the DHCP server provided with the Provisioning Server.
The boot process in this scenario is performed in the following three steps:
The target device requests an IP address from the DHCP server. The response includes the scope options 66 and 67 with the name and the location of the bootstrap file.
Using Trivial File Transfer Protocol (TFTP), the target device requests the bootstrap file from the Provisioning Server. This downloads it to the target.
The target device establishes a stream session with the Provisioning Server and boots the assigned vDisk.
As an alternative to network booting, you can use Citrix Boot Device Manager to create a bootstrap file on a USB flash device or a CDROM.
Begin by building a XenApp master server. A best practice is to choose the session-host only mode during the XenApp installation. Join the server to your farm or use the wizard to create a new farm if this is the first server you deploy. Install all the needed applications and publish them to your users.
Launch the Citrix XenApp Server Role Manager, select Edit Configuration | Prepare this server for imaging and provisioning as shown in the following screenshot:
Choose to remove the server from the farm but don't choose to clear the database location unless you plan to create an Active Directory policy to configure it.
Now, install the Provisioning Services Target Device software. At the end of the setup, the Imaging Wizard should start automatically. If not, run it from the Provisioning Services folder in the Start menu.
First, you need to connect to your PVS farm; enter the name (or the IP address) of one of the servers in your farm and the network port. If you're running the wizard with a user that can administer the farm, choose to use the Windows credentials, otherwise enter the appropriate credentials.
PVS can configure and manage Windows licensing. Choose the licensing method (none, KMS, or MAK) you deployed in your infrastructure.
The Imaging Wizard can create a new vDisk for you; as an alternative, if you've previously created an empty vDisk, you can choose it.
The final step is to create a target device in your PVS farm that corresponds to the server you're running the wizard on. Select the name of the device, the MAC address associated with the NIC you chose during the installation of the target device software, and the collection to add the device to.
Review the information, then click on Finish to start the conversion process. After some minutes your vDisk will be ready to use; just remember to change the access mode to Standard image before booting new servers with it.
You can manually create new session host servers (for example, from the vSphere client if you're on a VMware infrastructure) or use the Streamed VM Setup wizard from the PVS console to create your servers at once. The wizard supports XenServer, Microsoft Hyper-V, and VMware vSphere.
If you need to modify the vDisk, make a copy, change the mode to Private, and assign it to a server. Boot the server, perform the changes, and before shutting it down, remember to launch the Prepare server again for the imaging and provisioning wizard.
Citrix offers a complete solution to perform load tests in XenApp and XenDesktop environments: Citrix EdgeSight for Load Testing.
This product is available on the Citrix website; at the moment I'm writing the latest version, 3.8.1.
Note
You need a valid XenApp license to download and run the product. It's included in the Enterprise or Platinum version
Using EdgeSight for Load Testing, you are able to simulate real user sessions to analyze how your farm performs with different loads; it's a very helpful tool to correctly design your infrastructure.
EdgeSight for Load Testing has two components:
The following screenshot displays the EdgeSight for Load Testing components:
You need to change the remote desktop services configuration on the session host servers on which load tests will be applied, using the Remote Desktop Session Host Configuration tool.
It's very common to use the Citrix Web Interface to provide users a portal where they may view and run their applications. If you want to test this component with EdgeSight, you need to install on the server an optional component named Web Interface Support that hosts the Web Interface, included in the EdgeSight for Load Testing setup package.
Using this component, simulated users will be able to log on to the Web Interface, retrieve the published application you want to test, and run it.
You may install both Controller and Launcher on the same test machine, or you may install Launcher on dedicated servers. If you need to simulate a large number of users, the second scenario is preferable; if the test machine is under high load, test results may be mistaken.
The system requirements are as follows:
2 GHz or faster CPU
1 GB RAM
1 GB of free disk space
Windows Vista, Windows 7, or Windows Server 2003, 2008, or 2008 R2
The Launcher requires ICA Client, version 10 or later for testing XenApp systems and version 12 or later for testing XenDesktop systems.
The Controller must be able to connect to Launchers on port TCP/18747 and to connect to your license server (default port is TCP/27000).
Before being able to run any tests, you need to configure your license server. When a test is performed, the Controller checks for a valid XenApp Enterprise or Platinum license. If a license is found, you can run as many users as required.
Open the Controller, in the toolbar you can find a button to open the Licensing Server Configuration dialog, enter the address and the port number of your license server and click on OK.
A script is a single part of a test; it defines the following:
The actions (instructions) that will be performed
The users that will perform the actions
Where (connections) the actions will be performed
How many users and how long the test will last (load)
To create a new script, select Test – Add script....
In your script, you need to define how users will connect to your XenApp infrastructure.
Right-click on the Connections node and select Add connection...; enter the name of the Launcher server from which connections will begin.
If you want to connect to a published desktop, select Server and enter the server name in the Connect To field.
If you prefer to launch an application through the Citrix Web Interface, select Web Interface and click on the Browse... button.
Insert the address of the server that hosts the Web Interface. You usually don't need to change the port number (80 is the default) or Login and Application Page addresses (you selected those addresses when you installed the Web Interface Support component). Enter the account details of a user that could connect and click on Search.
In the Applications tab, you should see all the applications published for that user, select the application your script will test and click on Select.
For each connection you created, you have to define virtual users. Virtual users are used by Launchers to perform the test. You have to create the users, (usually in your Active Directory) and enable them to connect to your farm, and launch the application(s) you want to test.
If you named your test users like:
testuser1
testuser2
testuser3, and so on
with the same password, the Add Users to Connection dialog helps you to add them at one time. Enter the number of the users to be added in the Count field, then type the base
username in the Username field and tick the # checkbox.
Complete the Password and Domain fields and click on OK, EdgeSight will add all the users for you as shown in the following screenshot:
The load defines how long a test will last, how many users will execute it, and at what rate users connect to the server.
If you select the Concurrency checkbox, the system attempts to maintain a given number of virtual users during the test, ramping their count between the start and end values.
If you select the Rate checkbox, the system attempts to create new virtual users at the rate specified.
The easiest way to define the actions virtual users will perform is to record them during an interactive session.
You may select the user that will connect to the server by left-clicking on the user's icon or let the system choose the first user for you.
Select the Instructions folder and click on the Record Test button. The recording session begins and EdgeSight records all the commands you enter. The session ends when you close the connection or if you click on Stop/Cancel Test button in the main toolbar. If you stop a recording, you can restart it by clicking on the Continue button, while if you cancel it, no instructions are saved.
At the end of the recording, instructions are listed in the Instructions folder.
You can change the recorded instructions or add new ones. Instructions are keyboard/mouse commands or even complex Jscript scripts. You can also group instructions in folders and add breakpoints for debugging.
A XenApp infrastructure is made by several components: data store, data collectors, XML brokers, license servers, Web Interface servers, and session-host servers. All contribute to the correct working of the solution. In this chapter, you learned how to correctly size them based on your business requirements.
If you need to deploy several session-host servers, you may consider using Citrix Provisioning Services. With this tool, you can create a master image of your server and use it to provision as many servers as you need. Day-by-day management is also made easier; updates, patches, and changes have to be applied to the master image only.
Even if guidelines and best practices exist, nothing is better than a real test. With EdgeSight for Load Testing, Citrix offers a complete test suite to simulate real loads on a XenApp farm.