LLC and Application Redundancy

Description

Applications developed using SwitchKit must often be deployed in a redundant fashion, to allow for application and host computer failures. You can accomplish application redundancy by starting multiple, identical copies of an application, preferably on seperate host computers. Each of these applications must be capable of independently carrying out the other applications functions.

The LLC supports redundant applications by allowing distinct processes to register as redundant applications. This construct is named the Redundant Application Pool (RAP). The LLC assists redundant applications by designating one process to be the primary application for a particular RAP.

The LLC monitors all applications that are members of a RAP, so that one and only one of these applications is the primary application. If the primary application should fail, the LLC designates another of these applications to be the primary application.

Rules of RAP

The following table shows the general rules of SwitchKit Application Redundancy.

Tasks of the LLC

The following list explains the tasks of the LLC regarding redundant application settings. The LLC

• maintains RAPs.

• maintains at most one primary app within each RAP.

• adds applications to a RAP as specified in the sk_registerAsRedundantApp() call from the application.

• determines which application is primary in the RAP.

• notifies the application of its redundancy status upon entering the RAP.

• notifies all members of a RAP about any status change of member applications.

• removes an application from all RAPs if disconnected or not responding.

• allows an application to force itself to be primary in a RAP.

• allows an application to remove itself from a RAP.

Tasks of the Redundant Application

The following list explains the responsibility of applications that are members of a RAP.

• Upon indication that an application is the primary application, it must take control of all resources belonging to the application.

• Upon indication that an application is a secondary application, it must relinquish control of all resources belonging to the application.

• The primary and secondary applications are responsible for sharing information among themselves, so that the state of the application is maintained and known across all members of the RAP. This means that if the primary application of a RAP receives resources (such as a channel or active call) it should notify all secondary applications. This is necessary because if something should happen to the primary application, the secondary application that takes over must have sufficient information to continue processing all active calls, without any loss of service or resources.

RAPs and Redundant LLCs

In a system setup with redundant LLCs, the redundant RAP information is not shared between the active and standby LLCs. All registration messages and calls are saved within the SwitchKit API in the application's process space. When the connection to the active LLC is lost, the SwitchKit API attempts to connect to the redundant LLC. Upon successful connection, the SwitchKit API resends any previously sent redundant application registration messages. This approach keeps the time where no primary application is selected to a minimum.

When an LLC switchover occurs, it is possible that the primary application can become secondary, based on the order of the applications re-registration as initiated by the SwitchKit API. If this occurs, the previously secondary application will also be told that it is now primary.

If the application wishes to correct this situation, the new primary application must send a ReselectPrimaryApp message to the LLC indicating that it wishes to be made secondary. The LLC then selects another primary application from the registered applications (if another application exists).

Response Values

The following table shows the Status field values for the redundant application support: