Network redundancy considerations for a distributed relational database
Network redundancy provides different ways for users on the distributed relational database network to access a relational database on the network.
If there is only one communications path from a client to a server, when the communications line is down, users on the client do not have access to the server relational database. For this reason, network redundancy considerations are important to the distributed relational database administrator for the Spiffy Corporation. For example, consider service booking or customer parts purchasing issues for a dealership. When a customer is waiting for service or to purchase a part, the service clerk needs access to all authorized tables of enterprise information to schedule work or sell parts.
If the local system is down, no work can be done. If the local system is running but a request to a remote system is needed to process work and the remote system is down, the request cannot be handled. In the Spiffy Corporation example, this might mean that a dealership cannot request parts information from a regional inventory center. Also, if a server that handles many client jobs is down, none of the clients can complete their requests. In the case of the Spiffy Corporation network, if a regional center is down, none of the servers it supports can order parts.
Providing the region's dealerships with access to regional inventory data is important to the Spiffy Corporation distributed relational database administrator. Providing paths through the network to data can be addressed in several ways. The original network configuration for the Spiffy Corporation linked the end node dealerships to their respective network node regional centers.
An alternative for some dealerships might be a switched-line connection to a different regional center. If the local regional center is unavailable to the network, access to another server allows the requesting dealership to obtain information that is needed to do their work. In the first figure, some clients served by the MP000 system establish links to the KC000 system, which can be used whenever the MP000 system is unavailable. The Vary Configuration (VRYCFG) or Work with Configuration Status (WRKCFGSTS) command can be used by a system operator or distributed relational database administrator to vary the line on when needed and vary the line off when the primary server is available.
Another alternative might be if one of the larger area dealerships also acted as a server for other dealerships. As shown in the second figure, an end node is only a server to other end nodes through its network node. In the first figure, if the link to Minneapolis is down, none of the dealerships can query another (end node) for inventory. The configuration illustrated above can be changed so that one of the dealerships is configured as an APPN network node, and lines to that dealership from other area dealerships are set up.
