| ... | Table of Content |
| ... | Preface |
| ... | About This Book |
| 1 | Overview and History |
| 2 | Installation |
| 3 | Licensing |
| 4 | Configuration |
| 5 | Client Software |
| 6 | Application Installation |
| 7 | System Administration |
| 8 | Network Planning |
| 9 | Printing |
| 10 | User Environment |
| 11 | Virtualization |
| 12 | RDS Internals |
| 13 | Remoting Protocol Details |
| 14 | Security |
| 15 | Registry Settings |
| 16 | Server Sizing |
| 17 | Resource Management |
| 18 | Testing and Quality Assurance |
| 19 | RDS Scripting |
| 20 | RDS for Developers |
| ... | About |
| ... | Benny's Biography |
| ... | Presentations 2009, 2008, 2007, 2006, 2005, 2004 and earlier |
Posted by Benny Tritsch on August 3, 2008
[Server Sizing] [Requirements] [Scaling Up or Out] [Hardware Selection] [64 Bit]
Read in this lesson...
Before you are able to properly size a terminal server environment, you first need to define the requirements in terms of user capacity, applications, and system availability. These requirements are your starting point when calculating your server hardware resources. Adequately adjusting the hardware capacity relies heavily on the number and type of applications on the terminal server. The users, who can be grouped into different categories, are important as well. A user's working profile may range from simple data input using just one application to simultaneous use of several, resource-intensive applications.
When analyzing requirements, the following questions need to be answered: What is the maximum number of users that a server can handle? How many applications can be installed per server? How can applications and users best be distributed over several servers? To find the answers, unfortunately, requires an in-depth investigation into the available server resources, user categories, and preferred applications. Ideally, we would have a table with the number of potential users in one column and the matching server configuration right next to it. However, individual user requirements and application characteristics are so different that it is impossible to create such a table without reducing the complexity of the underlying calculation model significantly.
Every calculation model for server dimensions in multi-user environments is based on ideal assumptions. Previous experience with terminal server projects has taught us that there is no universally applicable formula to calculate the resources needed. For this reason, the calculation models produce rough estimates only. It will never be possible to accurately predict to the megahertz or the megabyte the necessary CPU clock speed and memory requirement – except for ideal, rather artificial reference environments.
Despite these limitations, the following sections describe criteria that may help you when planning the required capacity of your terminal server environment.
How do we categorize the users in the multiple-user environment? This question has prompted much controversy since the introduction of terminal servers. However, there is a commonly accepted distinction between three user types:
Naturally, these categories do not fully describe all users. In many user groups, not all users work simultaneously or continuously with the computer system. It may even be necessary to take users with a system administrator role into consideration when looking at resource consumption. Overall, this means that many more users can work with the system than planned. The distinguishing feature is the typical length of time the application is in use, which differentiates the part-time user from the full-time user. On average, a significantly higher number of part-time users can work with the system than pure full-time users. This is why the number of concurrent users at given times is by far more important to know than the number of named users that may eventually log in.
Unfortunately, the behavior of part-time users is a lot less predictable than that of full-time users. All the part-time users could want to work with a certain application at the same time, at month's end, for instance. In this case, they behave like full-time users. The terminal server environment should not reach its point of saturation precisely at that time, of course.
Typical 32-bit applications behave very differently from one another. An average user working with PowerPoint puts substantially more load on a terminal server than the average Word user, mainly because PowerPoint produces much more graphical output, which the RDP protocol caching mechanism cannot support so easily. Word, however, is used primarily to enter character strings, which can be optimized through the Glyph cache. The categories of applications listed in the following are a far better real-world representation.
A more precise differentiation requires calculating a base value for resources used by each application at and just after startup. This base value includes the time span and processor load for the first instance of the application and for each additional instance – before any user interaction whatsoever. This initial estimate says a lot about what will happen if numerous users try to work with an application at the same time, such as at the beginning of the workday. At the very least, memory is later occupied even if a user is no longer working with the application.
The second key parameter is the additional processor and memory resources used when users are working with the particular application. This value depends on the user data that the application loads. For Word or PowerPoint, exceptional circumstances could generate additional data volume per user as high as 100 MB. The processor load also increases, but the higher load quickly dissipates in most applications.
To obtain a realistic estimate of the memory needed in a terminal server environment, we need to examine the application set, that is, all the applications combined. This will tell us the required maximum memory if every user launched every available application. The first number indicates the memory required for the applications without loaded user data only. The second calculation includes the loaded user data. Although both values are more or less theoretical, they do reveal both ends of the spectrum. It can never get any worse!
If you want similar values for processor and network load, you need to invest in extensive load testing, which is discussed in a separate chapter of this book.
Let’s imagine you successfully analyzed both user and application requirements when planning a new terminal server environment. The only thing you need to address now is the sizing of the server hardware. At the first glance, this seems not to be a big challenge. Servers used in standard terminal server environments include the following hardware components, which all can be extended within certain limits
In the following we want to organize diverse server configurations into four base categories. Only the low-end server has one individual network card, which is used to communicate with clients and back-end servers. All other server categories have two or more network cards.
Unfortunately, servers do not scale linearly as memory and processors are added. Tests show that doubling the processor cores does not double overall capacity. This is valid for all types of processors that function with terminal servers. The overall performance of the selected processor configuration depends on two other factors; clock speed and second level cache. The second level cache is a memory space located directly on the processor. By caching, it eliminates rather slow main memory accesses. The larger the cache, the lower the number of memory accesses needed.
What about main memory? Even the 32-bit version of Windows Server 2008 enables access to more than four GB of memory. Yet terminal servers with four or more processor cores may show saturation behavior after occupying just over two GB of physical memory. This is not a problem of direct access to available main memory; the limits are the result of system-internal memory management. Related factors are the available free page table entries in kernel memory and the limited size of the registry database containing system and user configuration data. If any of these factors pushes the terminal server environment to its resource limit, the whole system becomes unusable. As a result, adding processors and physical memory make little sense. Therefore, individual terminal servers are rarely configured for more than 200 simultaneous users. This is why limits on 32-bit memory management have the greatest impact on the overall performance of systems utilizing large server platforms.
Windows Server 2008 removed such memory restrictions or increased the range substantially, making it highly unlikely that the free page table entries would restrict access to memory. The potential size of the registry database in main memory was also increased. Nonetheless, initial tests on large 32-bit server platforms still demonstrate limits in managing large numbers of simultaneous user sessions.
Since the 32-bit edition of Windows Server 2008 tends to use resources of very large servers poorly, the trend has been toward smaller server platforms using a maximum of four processors and four to eight GB of main memory. This trend is supported by two technologies that proved to be useful in terminal server environments.
Doubling the number of server processors usually more than
doubles the price of the hardware platform. This means for large
servers that the only potential savings lie in the price of the
operating system license and automated installation of the terminal
server environment.
The bottom line is that one-processor systems are generally too
small and eight-processor systems are too large for use in terminal
server environments. Naturally, there are always exceptions, if
special requirements or conditions apply.
| Read in this chapter... | |
| 8 | Server Sizing and Scalability |
| 8.1 | Finding Out About Requirements |
| 8.2 | Scaling Up or Scaling Out? |
| 8.3 | Selecting the Right Hardware |
| 8.4 | Is 64-Bit the Solution? |