Configuring HP DCE Cells
Integrating DCE Services with MC/ServiceGuard
exported to the name space, the name space entry will also identify every IP address on the node as providing the service associated with that entry.
While it is possible to edit the contents of the binding vector before using it to register endpoints or add entries in the name space, few, if any, DCE server programs actually edit the binding vector. In addition, the DCE runtime does not
In an MC/ServiceGuard environment, these characteristics might be problematic. Suppose a node had several packages running on it, each based on a DCE service and each with its own IP address. The DCE servers in each package would not only register endpoints using their own IP address, but will also include the IP address of all the other packages configured on the node at the time the server started up. Since all the DCE core services cache IP addresses and store them in their internal databases, the result is a potentially large number of invalid entries, adversely affecting performance, causing the generation of a large number of misleading log messages, and potentially causing the failure of the DCE infrastructure. These considerations and their affects do not preclude the use of MC/ServiceGuard with DCE by any means; they do, however, require that system administrators be particularly careful when planning, configuring, and operating a
Through an environment variable, the DCE runtime provides the means to restrict the IP addresses identified by the rpc_server_use_* routines. Used correctly, this variable can alleviate the adverse effects of the characteristics noted above.
Planning for a
Planning for a package that includes one or more DCE servers is primarily a process of identifying the disk and network resources necessary for the operation of the server. The planning process should follow the steps outlined in Managing MC/ServiceGuard. Especially
Planning and Configuring HP DCE 1.7 |