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 an application requester (AR) to an application server (AS), when the communications line is down, users on the AR do not have access to the AS 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 an AS that handles many AR jobs is down, none of the ARs can complete their requests. In the case of the Spiffy Corporation network, if a regional center is down, none of the application 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. Figure 1. Alternative network paths

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 AS allows the requesting dealership to obtain information that is needed to do their work. In the first figure, some ARs 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 AS is available.

Another alternative might be if one of the larger area dealerships also acted as an AS for other dealerships. As shown in the second figure, an end node is only an AS 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. Figure 2. Alternate application server

 

Parent topic:

Data availability and protection

 

Related reference

Vary Configuration (VRYCFG) command
Work with Configuration Status (WRKCFGSTS) command