Using Group Entries to Help Balance Server Workloads
When a client queries CDS for a server binding, the request includes the name of the entry to look in for the binding. When only one server offers the client's requested service, CDS will return the same binding for every client request for this service. While this model works fine for limited client requests, it can cause service bottlenecks when many client requests converge on one server. Applications can avoid bottlenecks by providing multiple servers to service large numbers of client requests. Server entry names alone don't provide a convenient way to distribute client requests evenly among multiple servers because you'd have to explicitly direct each client to a particular server. So CDS provides group entries as a convenient mechanism for distributing the client load across multiple servers.
A CDS group entry gathers related servers together under a common group name. Group entries contain members which are generally pointers to server entries but members can point to other group entries, too. When a client requests a binding from a group entry, CDS returns, at random, one of the pointers contained in the group entry. If the entry picked at random is another group entry, CDS doesn't return that. Instead CDS goes to that group and picks another random member, continuing until a server entry is returned. This model requires that any group member can service the client request. The following figure shows how a group entry contains members that point to other groups and to server entries.
Possible Mappings of a Group
Now, let's see how group entries help balance a workload. Consider an organization with twelve identical laser printers equally spread among three departments. The following group entry examples show how each group entry name returns any one of the four printers assigned to its own department.
Group entry name: /.:/admin/finance/accts_payable_printers
/.:/admin/finance/accts_payable/laser_10
/.:/admin/finance/accts_payable/laser_11
/.:/admin/finance/accts_payable/laser_12
/.:/admin/finance/accts_payable/laser_13
Group entry name: /.:/admin/finance/accts_receivable_printers
/.:/admin/finance/accts_receivable/laser_10
/.:/admin/finance/accts_receivable/laser_11
/.:/admin/finance/accts_receivable/laser_12
/.:/admin/finance/accts_receivable/laser_13
Group entry name: /.:/admin/finance/payroll_printers
/.:/admin/finance/payroll/laser_10
/.:/admin/finance/payroll/laser_11
/.:/admin/finance/payroll/laser_12
/.:/admin/finance/payroll/laser_13
You could temporarily make one department's printers available to another group by adding its group name to the group entry of the other group as shown in the next group entry example.
Group entry name: /.:/admin/finance/accts_payable_printers
/.:/admin/finance/accts_payable/laser_10
/.:/admin/finance/accts_payable/laser_11
/.:/admin/finance/accts_payable/laser_12
/.:/admin/finance/accts_payable/laser_13
/.:/admin/finance/accts_receivable_printers
The configuration in the preceding example means the clients in accounts payable can use the printers in accounts receivable 20% of the time. You could offer a higher percentage of use by adding server entry names rather than the group name. The next group entry example shows a situation where the clients in accounts payable can use the printers in accounts receivable 50% of the time. One caveat; do not try to increase the percentage of use by including a group name multiple times because you'll get an error.
Group entry name: /.:/admin/finance/accts_payable_printers
/.:/admin/finance/accts_payable/laser_10
/.:/admin/finance/accts_payable/laser_11
/.:/admin/finance/accts_payable/laser_12
/.:/admin/finance/accts_payable/laser_13
/.:/admin/finance/accts_receivable/laser_10
/.:/admin/finance/accts_receivable/laser_11
/.:/admin/finance/accts_receivable/laser_12
/.:/admin/finance/accts_receivable/laser_13
Although application servers can manage their own group entries in CDS, you may find it more convenient (and more straightforward) to manually add, remove, or change server information in a group entry. Like managing server entries, there are several methods for managing group entries in CDS:
· Group entry names can be hard coded into an application. You can change group entry information in the source code but you need to recompile and rerun the application before the entry names take effect.
· Group entry names can be passed to an application through environment variables or arguments. These are more convenient methods than recompiling but you might need to restart an application to use either method.
· Group entry names can be directly managed in CDS by using the DCE control program's rpcgroup object. This manual method does not require recompiling or restarting applications.
The next topics discuss how to use the rpcgroup object to manually manage group entries in CDS.
More:
Creating a New Group Entry in CDS
Adding a Member to a Group Entry in CDS
Viewing the Members of a Group Entry
Importing Binding Information from a Group Entry in CDS
Removing Members from a Group Entry in CDS
Deleting a Group Entry from CDS