|
|
During the installation of Citrix MetaFrame XP Presentation Server, and in addition to the already available RDP, the ICA protocol is established to allow communication with ICA clients. Applying a new mechanism that requires a separate protocol allows the grouping of multiple MetaFrame servers with specific management functionalities (such as server features, user information, sessions, applications, and licenses). Both new Citrix protocols and their corresponding system components make up a MetaFrame server. This is why the two protocols are given a thorough examination in the following section.
Citrix developed the ICA protocol to allow the remote presentation of and interaction with applications by providing multiple protocol channels. On a server, ICA separates the application logic from the user interface. In most cases, ICA only sends graphics elements to the client by using predefined protocol channels. On the client side, a user is able to see the graphics elements of the user interface. Each user interface interaction with mouse or keyboard is then transmitted to the server, again using certain protocol channels. As a rule of thumb, this communication requires between 10 kilobits per second (Kbps) and 20 Kbps of networking bandwidth. Additional functionalities that are based on the transmission of multimedia data streams or on the redirection of client resources are integrated into the ICA protocol by using specific virtual channels. Comparable to RDP virtual channels, ICA virtual channels are used to extend the supported feature set of the ICA protocol.
The network packets within the ICA protocol consist of one command and the optional data that follows. The data can be compressed and encrypted (using DES or RSA algorithms). The ICA protocol is highly optimized for the transmission of GDI system calls and can thus be also used for relatively slow network connections.
The features of the ICA protocol are summarized in the following list:
Transparent support of standard Windows-based applications and DOS applications for almost any client platform.
High performance for different network bandwidths, especially for slow connections between MetaFrame servers and ICA clients. This is achieved through strong compression algorithms applied to the ICA data stream.
Minimal requirements for client platforms.
Data encryption meeting the requirements of different security levels.
Integration of local and remote clipboards for clients using a Windows operating system.
Redirection of the client file system. This allows the use of client drives on MetaFrame servers (drive mapping).
Redirection of client standard ports. This allows the use of devices physically connected to individual clients from the MetaFrame server (port redirection).
Redirection of audio data streams between server and clients, allowing the playback of sound and music.
Caching of bitmaps for the acceleration of the graphical output on the client side.
In the past, the comparison between the two protocols, RDP and ICA, played a significant role in determining whether to acquire and use the Citrix products. Today, the protocols and most of their basic features are quite similar. This is why a direct feature comparison is no longer popular. The same is largely true for the bandwidth requirements of both protocols when their core functionalities are used. The algorithms for the compression of the data streams between terminal servers or MetaFrame servers and their clients produce much the same network bandwidth. However, if the existing functionalities of the complete solutions provided by Microsoft on one side and Citrix on the other are compared, it becomes very obvious why the Citrix MetaFrame XP Presentation Server extensions are used in so many terminal server environments.
Table 9.1 shows the comparison of the functionalities and features of the Microsoft and Citrix solutions. Some of the listed items will be described in more detail later in this book.
| Note |
It is a requirement, of course, that some of the functionalities listed in Table 9.1 must be supported explicitly by their corresponding communication protocol (for example, bandwidth control, published applications, or seamless windows). However, it is also true that the capabilities of both protocols have not hit any natural limits so far. This means that there is abundant room for additional functionality. The “virtual channels” that are available for both RDP and ICA serve as a technical basis to extend the functionality of the communication protocols. |
Besides the communication between the MetaFrame server and its clients over the ICA protocol, a mechanism is needed for communication between MetaFrame servers. Citrix introduced the Independent Management Architecture (IMA) to address this need. IMA consists of the following two components:
A central IMA database (IMA data store), used to store MetaFrame server configuration information. This configuration information contains load-balancing rules, security settings, printer configurations, published application settings, and available licenses.
The IMA protocol for the exchange of variable parameters between the MetaFrame servers. These parameters contain the current load, the logged on users, the existing sessions, and the licenses in use.
The IMA service is executed on each MetaFrame server, providing IMA communication with the IMA database and with the other MetaFrame servers. Additionally, the Management Console for MetaFrame XP is able to exchange information and control commands through the IMA service.
With the help of IMA, individual MetaFrame servers can be united to create large farms with hundreds of servers. Such server farms allow the central configuration and the control of all nodes involved. The servers of the farm do not need to be at the same physical location; they can be completely distributed with regard to location. An important prerequisite for a distributed environment is an adequate network connection between the individual locations. It is also possible that multiple MetaFrame server farms can be managed within one Windows domain. A method that has not stood the test of time is the establishment of a MetaFrame server farm spanning multiple domains of an Active Directory directory service—even if it is possible from a technical standpoint. The management of authorizations and the communication paths during user logons tend to become very complex and therefore are inefficient in such an environment.
To be able to segment larger farms into smaller units, Citrix introduced the concepts of zones. Zones help to solve the problem of the over-proportional growth of communication overhead between individual servers as soon as a critical farm size is reached. The delegation of administrative tasks is also much easier within zones, as compared to a single farm.
Another alternative that is being considered in many large MetaFrame projects is, of course, the creation of more than one server farm. This allows a completely independent configuration and tuning of each farm. But common changes that must be applied to all farms have to be done separately on each farm. It should also be considered that a user needs one valid license for each farm to which he or she connects. Still, this multi-farm option is feasible when the server farms are set up at different physical locations and the users log on to the MetaFrame server farm that is closest to their physical locations or meets their requirements best. In such a scenario, it might well happen that central file, print, and directory services are provided from a location that is remote to some of the MetaFrame server farms.
The required network bandwidth of the IMA communication within a server farm is a function that depends on the number of servers, the number of published applications, the number of users, and the number of managed printer drivers. A MetaFrame server farm can be divided into multiple zones, as introduced in the preceding section. Using zones helps to influence the function parameters of the IMA communication overhead that is related to the size of a server farm. A server farm with properly dimensioned zones can include many more servers than a farm without zones; this is because each zone can easily contain several hundreds of servers, at which point it is recommended to create a new zone. In most cases, because of organizational reasons, numerous published applications or many managed printer drivers, new zones will be created before the limit of several hundreds of servers is reached.
| Caution |
The official Citrix documentation of server farms and zones does not indicate any number of servers as a fixed technical limit. However, experience with large MetaFrame project has indicated that very high numbers of servers, published applications and managed printer drivers in one zone substantially increases the probability that one or more components involved will show behavioral signs of saturation. This often results in unacceptable response times of the MetaFrame environment. The scalability of MetaFrame servers and the resulting numbers of servers in farms and zones will be discussed in more detail in Chapter 10. |
If multiple MetaFrame servers are grouped into a farm, an initial zone is created automatically in this farm. An administrator can create a new zone in the farm and assign servers to it. During their operation, all MetaFrame servers monitor different local parameters of a global relevance. The related global information contains events such as starting up and shutting down a server, logging on and logging off users, connecting and disconnecting sessions, modifications in the published applications settings, and changes in the load conditions. An additional monitoring task keeps track of the used licenses. All resulting dynamic information is sent to a central instance within the zone—to the Zone Data Collector (ZDC). The ZDC keeps most of the communication inside the zone. Only ZDCs are able to establish a communication beyond zone boundaries and synchronize their information with other ZDCs. That is why server farms with different zones are defined primarily by their ZDCs.
But which server within a zone plays the role of a ZDC? The solution is rather simple: Predefined system events such as the startup of a new server or the shutdown of the ZDC initiate an election if there is more than one MetaFrame server in the farm. This automatic election determines which server will be the ZDC. The election criteria are as follows:
The newest software version represents the highest priority during the election of a new ZDC. This is why the newest version of Citrix MetaFrame XP Presentation Server always automatically becomes the ZDC when it is installed in an existing zone.
If the newest software version is installed on more than one server, the preference for the election of the ZDC can be assigned manually. This is done in the Management Console for MetaFrame XP. (See also Chapter 10.)
If the preference is the same for more than one server, a random number generated when the MetaFrame server is installed determines which server will be elected to be the ZDC.
The load of the ZDC grows as the zone grows. If the difference in the average load of the ZDC compared to the other MetaFrame servers of the farm is so significant that user sessions on the ZDC are affected negatively, it is recommended that a dedicated ZDC to be created. To do this, the selected MetaFrame server is configured so user sessions are not started; this server then receives the highest preference to become a ZDC. Additionally, it is very important that the newest version of the Citrix MetaFrame XP Presentation Server software is always installed first on the dedicated ZDC. This also includes Feature Releases and Service Packs.
Whereas the ZDCs are responsible for the management of dynamic information within the zones, the IMA database stores the more static configuration information of a MetaFrame server farm. Changes in the static configuration can be applied by using the Management Console for MetaFrame XP. (See also Chapter 10.) The initial configuration can be found in the associated IMA database right after the installation of the first MetaFrame server of a server farm. The IMA database can be installed on one of the following database platforms: Microsoft Access (Microsoft Jet Engine), Microsoft SQL Server 2000 Desktop Engine (MSDE), Microsoft SQL Server 2000, Microsoft SQL Server 7 SP2 or later, Oracle 7.3.4 or later, and IBM DB2 7.2 FixPak 5 or later.
A MetaFrame server can access the IMA database server in a direct or an indirect manner. The second mode means that a MetaFrame server provides the access to the IMA database by using another MetaFrame server. In this configuration, one dedicated MetaFrame server takes over the role of a gateway to the database platform. If the IMA database is implemented using Microsoft Access, the indirect access is mandatory and not an option. The option of the indirect access is also recommended for MSDE because MSDE allows only five concurrent open database connections. All other database platforms allow both the direct and the indirect access option. As a rule, the direct access method is preferable because of performance and stability reasons.
| Note |
The Citrix MetaFrame XP Presentation Server installation routine will create the Microsoft Access database automatically. To create a blank database in the right format for the other platforms, these platforms must already be available and the appropriate database setup routines must be executed before the MetaFrame installation is started. |
During the startup phase of a MetaFrame server, the server accesses the IMA database using the IMA service. The MetaFrame server loads its individual configuration information, but it ignores the information that belongs to the other servers. After this initial contact, the MetaFrame server checks the IMA database every 30 minutes for any change of its configuration settings. The interval is configurable via the registry to accommodate larger farms. If changes occur, they are transmitted to the MetaFrame server.
Each MetaFrame server caches its individual configuration information in a local database named Local Host Cache (LHC). The LHC increases the performance substantially during read operations to the required data because no network communication to the IMA database is needed. The LHC is also responsible for maintaining proper MetaFrame server functionality even if the connection to the IMA database has been cut off. This is the case as long as the loss of connection to the IMA database does not exceed 96 hours. This time span is hard-coded in the product and cannot be changed. If no connection can be established to the IMA database during this time, after 96 hours the locally cached licenses are deactivated and users can no longer log on to this MetaFrame server.
| Tip |
The Local Host Cache of a MetaFrame server can be manually synchronized with the IMA database by using the Dsmaint refreshlhc command. |
Independent Computing Architecture (ICA) and Independent Management Architecture (IMA) can both be found on each MetaFrame server. An interesting topic is the combined functionality of these two components. This includes which ports of the TCP/IP protocol are being used for the ICA and IMA communication.
|
Description of the Communication Channel |
TCP/IP Port(s) |
|---|---|
|
Citrix XML service providing published application information after a client request. (Port can be changed during installation, from the Management Console for MetaFrame XP, or by using the Ctxxmlss command.) |
80 (TCP) |
|
Communication between MetaFrame servers and Microsoft SQL Server or Oracle server. |
139, 443, 1433 |
|
Citrix SSL Relay to forward ICA data streams over Secure Socket Layer. |
443 (TCP) |
|
ICA communication between MetaFrame servers and their clients. (Port can be changed by using the Icaport command.) |
1494 (TCP) |
|
Communication of older ICA clients with the ICA browser service. |
1604 (UDP) |
|
IMA communication between the IMA services on the MetaFrame servers and the Zone Data Collectors. (Port can be changed by using the Imaport command.) |
2512 (TCP) |
|
IMA communication between the IMA services and the Management Console for MetaFrame XP. (Port can be changed by using the Imaport command.) |
2513 (TCP) |
Figure 9-3 shows the results of combining the information about the concept of Independent Computing Architecture, Independent Management Architecture, and the associated communication channels.
|
|
