|
|
If Citrix MetaFrame XP is intended for use in a large corporate environment, the issue of maximum scalability is bound to arise. It is important to bear the following point in mind when considering the details given later in this section: all extension products offered by Citrix for Windows Server 2003 are offered with the aim of increasing the scalability of terminal servers. Citrix products can therefore help achieve a scale among servers, clients, printers, and users in a farm that would otherwise be impossible to accomplish. The mechanisms employed in achieving this aim range from highly specialized load-balancing mechanisms and bandwidth control for multimedia data and print data streams to concepts for published applications, seamless windows, and the Program Neighborhood.
However, even Citrix products have their limits, mostly caused by the communication between clients, IMA services, zone data collectors, and the IMA database. Knowing and respecting these limits has proved useful during many a project. The details given in the following paragraphs should therefore be considered rough guidelines concerning the scalability of a MetaFrame farm.
When we speak of scalability here, often the only statements that can be made are relative ones made on the basis of sample implementations or extrapolations. It is vital that reference values be defined in order for this issue to be properly considered. Such reference values include specific statements about the acceptable response times in relation to certain occurrences. This means that an administrator or an architect of a future MetaFrame environment must consider the permissible times for a server to restart, for load-balancing information to be identified, for an application to be published, and for certain information to be opened to the Management Console for MetaFrame XP. Only then can the earlier mentioned relative statements truly be viewed in relation to the requirements. To round off the topic, extensive load tests should ideally follow to verify the forecasts made.
| Important |
With its products, Citrix is positioned primarily in the environment of companies above a certain size. Individual MetaFrame servers do not play as central a role as larger server farms do. The following points do not, therefore, relate to the bandwidth of the ICA protocol, the number of user sessions on individual servers, or the launch times of applications. For these parameters, the difference between an unmodified terminal server with RDP protocol and a MetaFrame server with ICA protocol is minimal. The relevant values and scalability factors were described in detail in Chapter 3 and Chapter 5. The points in the following section will be interesting to readers who want to build larger environments with MetaFrame servers. |
The maximum number of servers in a farm or a zone is determined by certain factors. First of all, there is a limit, set by Citrix, of 512 servers per zone. While it is possible to increase this limit by modifying the registry database, it is not advisable to do so. This is because it is not advisable to have more than a couple of hundred servers per zone that all communicate with their zone data collector and to which they transmit all of their information.
If there are several zones in a farm, the respective zone data collectors are in constant communication with each other. According to Citrix, this usually results in less than 1 kilobyte of data transfer for certain events, such as publishing an application, making a connection, ending a connection, reconnecting, and logging off a user. If printer drivers are replicated as well, the volume of data passing to the zone data collectors and moving between the zones naturally increases.
The Management Console for MetaFrame XP reads all of the data from the IMA database that it displays. The response time for displaying the various information also depends very much on the number of servers involved. In very large server farms, it might – depending on the number of published applications and the printer configuration – take longer than usual for all of the required data to be made available.
Where there is already a large farm with a lot of applications published on all servers, a further bottleneck arises if a new server is added. This new server must be added to all of the published applications, which means accessing the IMA database every time. If this is done manually using the Management Console for MetaFrame XP, there is no apparent direct impact. However, if an automation script is used that publishes the applications via Citrix’s MFCOM interface, it will result in considerably longer script runtimes, depending on the size of the farm.
Extreme scalability is a feature of the load-balancing mechanism of the Citrix MetaFrame XP Presentation Server and its predecessors. Even with a very large number of clients and servers in a farm, a client is always assigned quickly to the server with the greatest amount of free capacity. In this respect it is very unlikely to come up against any limitations in real production environments with fewer than 1,000 servers.
Having looked at the number of servers in a MetaFrame farm, we will now consider the published applications and the replicated printer drivers.
| Note |
Citrix improves the scalability of its products with each new generation. The numbers cited in the following paragraph should therefore be viewed with caution, as they represent a moment in time in a test environment. In particular, the introduction of the Feature Release 3 for MetaFrame XP, which corresponds to the current version of MetaFrame XP for Windows Server 2003, has implemented major improvements in IMA database access. |
The more information a MetaFrame server requires from the IMA database, the longer it and the respective IMA service will take to start up. Problems arose in two different test scenarios. In one test there were 50 published applications and 500 servers. Another test involved up to 1,500 published applications and 140 servers. When the servers were started up during the tests, all of the required information from the IMA database was competing to be read. When the MetaFrame servers were started up simultaneously, in the first test scenario the initial SQL database server with two CPUs achieved a state of saturation with 100 percent processor load over a long period. Only when an eight-way system and sufficient main memory were employed did the situation improve. In this case, the network was the limiting factor.
In the second test scenario, it was impossible to start up the servers simultaneously. Here, the servers had to be started up successively to achieve acceptable times. Also, by the end of the second test scenario, the time delays in publishing additional applications from the Management Console for MetaFrame XP had increased considerably. But the system did remain fully functioning.
Naturally, the results of the two tests should be viewed only in correlation with the hardware employed and cannot be directly transferred to a general context. However, the results do highlight a certain tendency in terms of the dimensions of MetaFrame environments. If a company really wants to operate several hundred servers with more than 1,000 published applications in a single farm, major problems could be expected in performing certain administrative tasks. It is therefore advisable to segment the farm and the applications into smaller units.
Another critical parameter is the return of the list of published applications if a client requests it. Tests show that the time required depends on the number of published applications, not on the number of servers. Only when the number of applications goes beyond 1000 will the response time exceed 2 seconds. What is certainly a problem here, however, is a scenario where a very large number of users almost simultaneously requests information on all the published applications they are entitled to. This might occur, for example, if all of a company’s employees start work at the same time and log on via the Program Neighborhood. If all of the queries go through the same MetaFrame server, saturation problems are very likely to arise.
The replication of print drivers is another aspect that can reach its limitations in large environments. A single queue for the driver replication should have no more than 1,500 entries. The number of entries is calculated by multiplying the number of servers with the number of drivers. So if a farm consists of 100 servers, there should be no more than 15 printer drivers in the queue. The sheer volume of data required for transmitting the drivers themselves makes it unwise to replicate printer drivers during the core working hours of the users.
| Note |
The number of replicated printer drivers influences the startup times of the IMA service. The same is true if many different license numbers in the IMA database need to be supplied. All of this information needs to be transmitted when the MetaFrame server starts up, and therefore the transmission leads to delays. |
Finally, the following formula is a means of calculating the total approximate volume of data in kilobytes that a MetaFrame server receives from the IMA database when it is starting up.
IMA data = 402 + 6.82*(servers-1) In this formula, the variable »servers« represents the number of MetaFrame servers in the farm
|
|