Allocating users and applications to servers. The administrator can assign users to home servers in a way that spreads the load across this set of servers. Similarly, the administrator can spread applications (databases) across a set of servers, and create replicas when necessary, to spread the application load across a set of servers.
Setting the maximum number of users for a server. Through a Notes.ini setting, Server_MaxUsers, the administrator can specify the maximum number of user sessions allowed on a server. When the server reaches this limit, it rejects requests for additional sessions until the number of sessions again falls below the Server_MaxUsers value.
These techniques work on any Domino server, whether or not it is part of a Domino cluster. While these techniques are generally effective, they are somewhat static and coarse grained. The real advantages come when you use Domino clusters for workload balancing.
In Domino clustering, server workload balancing allows heavily used servers to pass requests to other cluster servers. This form of workload balancing is dynamic, fine-grained, and generally transparent to the user, which means that work can be evenly distributed across the servers in the cluster. Clusters let you grow your system as the number of users you support increases. You can distribute user accounts across clusters and balance additional workloads to optimize system performance. You can create multiple database replicas to maximize data availability and move users to other servers or clusters as you plan for future growth.
Overview of workload balancing in Domino clusters
The Domino server and Notes client work together to provide workload balancing. When running as part of a cluster, the Domino server constantly monitors its own workload. To measure the workload, the Cluster Manager process on the server monitors the average response time of a representative set of server operations initiated by Notes clients (network time is not considered). The Cluster Manager also polls all the other servers in the cluster to determine their workload. When the workload on a server exceeds a certain level designated by the administrator, the server becomes "busy," and the Domino server rejects subsequent database open requests until the workload falls back below the specified level.
When the cluster-aware client (Notes R4 or later) tries to access a database on a busy server, it receives an error code indicating the server is busy. The client then contacts the Cluster Manager on one of the servers in the cluster. (Whenever the client accesses a server that is a member of a cluster, it stores a list of servers in the cluster in a persistent cache.) The Cluster Manager uses the Cluster Database Directory (CLDBDIR) to determine which other servers in the cluster have replicas of the database being requested, and then selects the least heavily loaded of these servers to handle the client request. The client then reissues the open request to this server. Note that this target server could be the same as the original server. On this second request, the open will succeed even if the target server is busy.
Figure1 . Workload balancing animation
Similar to failover, an icon for the new database will appear in the workspace, either stacked on top of the original icon or in a free area on the same workspace page as the original icon.
Workload balancing can be triggered in a wide variety of situations, such as:
A user double-clicks on a database icon in the workspace.
A user tries to launch a doclink, view link, or database link that is connected to a server that is busy.
A user activates a field, action, or button that contains an @Command (FileOpenDatabase) formula and the specified server is busy.
A Lotus Script routine issues a DB.OPENWITHFAILOVER call to open a database on a server that is busy.
An agent written in Java issues an openDatabase method with the failover parameter set to true for a database on a server that is busy.
A C API program issues an NSFDbOpenExtended call to open a database on a server that is busy.
Distribution of databases in the cluster
In a cluster, the distribution of users and databases takes on a new importance. When a server in the cluster fails, user requests are automatically redirected to other servers in the cluster. Ideally, this load should be spread equally across all other servers in the cluster. However, this can only happen when replicas of the databases on the failed server are spread roughly equally across the other servers in the cluster.
An example can illustrate this best. Suppose you have 1200 mail users that you want to put on a cluster with four servers. To start, you will probably allocate 300 users to each server. Now, to give these users high availability to their mail databases, you want to create a replica of each user's mail file on another server in the cluster. You might take all users on Server 1 and put a replica of their mail file on Server 2. This is not a good idea. If Server 1 fails, all 300 of its users will be redirected to Server 2. Servers 3 and 4 will not absorb any of this failover loads, because the necessary databases are only available on Server 2.
Clearly, a better approach is to spread the replicas for Server 1's users across the other three servers. If these are spread evenly -- that is, 100 of Server 1's users on Server 2, 100 on Server 3, and 100 on Server 4 -- a failure of Server 1 should result in a roughly equal increase in workload for the other three servers in the cluster.
Figure 2. Mail user distribution across four servers
The server availability index
As mentioned above, each server in a cluster periodically determines its own workload, based on the average response time of requests recently processed by the server. The workload on the server is expressed as the server availability index, which is a value between 0 and 100, where 100 indicates a lightly loaded server (fast response times), and 0 is a heavily loaded server (slow response times). Despite the fact that the server availability index is a number between 0 and 100, it is not a percentage. Some people think that a server availability index of, say 85, means that the server is 85% available. This is not the case -- in fact, it is far from it.
The actual formula for determining the availability index is not described anywhere in the Notes publications. What I am about to tell you is accurate for the Notes 4.5 and 4.6 releases,
but may change in future releases. The server availability index is closely related to a common performance metric called the expansion factor. The expansion factor is simply the ratio of the response time for a function under the current load to the response time for this same function in an optimum (light load) condition. So, for example, if the system currently takes 3 seconds to perform a database open, but could perform the same database open in .3 seconds under optimum conditions, the expansion factor for this operation is 10. The expansion factor for a set of operations can be computed as a simple weighted average. To compute the server availability index, the Domino server computes the expansion factor for a representative set of Notes RPC transactions over a recent time interval (roughly the last minute). The server availability index is then set to 100 minus this expansion factor.
Server availability index formula
Remember that the server availability index only considers the response time as measured at the server, which is typically only a small portion of the overall response time as seen by clients. In particular, the network time between the client and server often accounts for a significant portion of client response time. So a server availability index of 90 does not indicate that the response time as seen by clients is ten times the optimal value -- only that the server processing of this request took ten times longer than the optimal value.
The server availability threshold
Now that you know how Domino measures server load, you are ready to configure the server to indicate when it is busy. This is done with a Notes.ini setting called Server_Availability_Threshold. When Domino recalculates the server availability index (approximately once a minute), it checks to see if the index is below the server availability threshold. If the server availability index is less than the server availability threshold, the server is marked as busy. In other words, the server availability threshold specifies the lowest value of the server availability index for which the server should be considered to be available.
To set the server availability threshold, edit the Notes.ini file for the server and add the following:
Server_Availability_Threshold=
Or you can set the threshold from the Domino server console with the command:
Set Config Server_Availability_Threshold=
When set from the server console, the new threshold value takes effect immediately. When set by editing Notes.ini, the new threshold value takes effect the next time the server is started.
The default value for the server availability threshold is 0, which means load balancing is effectively disabled. Specifying a threshold value of 100 puts the server into the busy state regardless of its actual availability.
Setting the maximum number of users on a server
You can also balance the workload in a cluster by using the Server_MaxUsers setting. This setting specifies the maximum number of active users allowed on a server at one time. When the server reaches this limit, the server goes into the MAXUSERS state and rejects any additional requests until the number of active users falls below the Server_MaxUsers limit. When Domino rejects an access request because of a MAXUSERS state, the Cluster Manager attempts to redirect the request to another cluster server that contains the appropriate replica. If no other server is available, Domino rejects the access request and displays an explanatory message.
Note The Server_MaxUsers setting does not affect replication. Replication occurs even when a server is in a MAXUSERS state.
From the Domino Administrator
1. Click the Configuration tab.
2. In the Task pane, expand Server, and then click Configurations.
3. Do one of the following:
•If a Configuration Settings document already exists for the server you want, select that document, and then click Edit Configuration.
•If a Configuration Settings document does not already exist for the server you want, click Add Configuration, and add the name of the server in the "Group or Server name" field on the Basics tab.
4. Click the NOTES.INI Settings tab.
5. Click Set/Modify Parameters.
6. In the Item field, select or enter SERVER_MAXUSERS.
7. In the Value field, enter the maximum number of users you want to access the server at the same time.
8. Click Add, and then click OK.
9. Click Save & Close.
