What are the NFM-P redundancy functions?

Overview
Figure 17-3: NFM-P redundancy role-change functions
NFM-P redundancy role-change functions
Server activity switches

The standby server initiates an automatic server activity switch when it cannot communicate with the primary server. An NFM-P administrator can perform a manual server activity switch, which is typically a planned server maintenance or test operation.

Note: For security reasons, you cannot use an NFM-P GUI or XML API client to perform a server activity switch.

Figure 17-4: Server and database roles before server activity switch
Server and database roles before server activity switch

The NFM-P raises alarms when a server activity switch is initiated. During the activity switch, the main servers do not process SNMP traps, attempt to synchronize NEs, or collect statistics. Auxiliary servers process outstanding requests, but do not communicate with a main server.

Figure 17-5: Server and database roles after server activity switch
Server and database roles after server activity switch

After a server activity switch:

Database switchovers

An NFM-P administrator directs a main server to initiate a database switchover.

Figure 17-6: Server and database roles before database switchover
Server and database roles before database switchover
Figure 17-7: Server and database roles after database switchover
Server and database roles after database switchover

The following occurs after a successful database switchover:

When a database switchover fails, the primary and standby database roles do not change. No automatic database realignment occurs as a result of a switchover.

Database failovers

The main database failover function is enabled by default. A failover occurs when a main server cannot communicate with the primary database, but can communicate with the standby database and the managed NEs. When this happens, the main server directs the standby database to become the primary database.

A database failover occurs only if the following conditions are true.

Figure 17-8: Server and database roles before database failover
Server and database roles before database failover
Figure 17-9: Server and database roles after database failover
Server and database roles after database failover

When a database failover fails, the primary server tries again to communicate with the primary database. If the primary database remains unavailable, the primary server tries again to initiate a failover.

Note: During a database failover, a network management outage occurs; the GUI clients can monitor the failover, but cannot perform configuration activities.

Note: After a successful failover, database redundancy is not available until the new primary database is reinstantiated as the standby database on the former primary database station. See Re-establishing database redundancy for more information.

Re-establishing database redundancy

After a failover, the former primary database is no longer part of the redundant configuration. To re-establish database redundancy, you must reinstantiate the former primary database as the new standby database. You can do this only when the failed database station is restored to full operation and has a functional proxy port. See How do I reinstantiate the main database from the client GUI? and How do I reinstantiate the main database from a CLI? for information about how to reinstantiate a database.

Figure 17-10: Server and database roles after database reinstantiation
Server and database roles after database reinstantiation
Automatic database reinstantiation

You can configure the NFM-P to automatically reinstantiate the former primary database as the new standby database. Automatic database reinstantiation occurs only in the event of a database failover. When the function is enabled, the NFM-P attempts an automatic reinstantiation every 60 minutes by default. You can enable automatic database reinstantiation during a main server installation or upgrade. See the NSP Installation and Upgrade Guide for information about enabling and configuring automatic database reinstantiation.

Automatic database realignment

In a redundant NFM-P system that is geographically dispersed, the primary main server and database may be in separate LANs or WANs after an activity switch or failover. The network latency that this introduces can affect NFM-P system performance. Automatic database realignment is an optional mechanism that attempts to ensure that each main server uses the local database.

The database with which a main server tries to align itself is called the preferred database of the main server. An operator enables automatic database realignment and specifies the preferred database during NFM-P server installation, or during server configuration after installation.

Note: For automatic database alignment to work, you must enable it and specify a preferred database on each main server in a redundant NFM-P system.

When a primary server starts, it verifies that the primary database is the preferred database. If the primary database is not the preferred database, the server performs a database switchover to reverse the primary and standby database roles. If the switchover is successful, the main servers and databases in the NFM-P system are aligned. If the switchover fails, each database reverts to the former role, and the main server generates an alarm about the failed switchover.

When you perform a database switchover and automatic database realignment is enabled, the primary server does not attempt database realignment. A switchover is a manual operation that is considered to be a purposeful act.

Performing a server activity switch when automatic database realignment is enabled triggers a database switchover.

Redundancy function summary
Table 17-1: Redundancy functions, main server

Function

Notes

Automatic server activity switch

An automatic activity switch occurs when the primary server cannot communicate with the standby server, and involves the following sequence of events.

  • The standby server cannot communicate with the primary server within 60 seconds, or the primary server cannot communicate with the managed network.

  • The standby server performs an activity switch to become the new primary server. The activity switch occurs only if the standby server can communicate with the managed network.

  • If automatic database realignment is enabled, the new primary server attempts a database switchover.

  • The new primary server connects to the primary database and manages the network.

  • The new primary server and the auxiliary servers synchronize the outstanding request information.

During an activity switch, each browser client and XML API client loses connectivity with the primary main server.

During an activity switch, a main server does not process SNMP traps from the network, and no NE re-synchronizations occur. The auxiliary servers continue to process outstanding requests, and synchronize the request information with the new primary server after the activity switch.

When the communication failure is resolved, you must re-open each browser client, and redirect each XML API client to the new primary main server.

Manual server activity switch

A manual activity switch is typically performed for maintenance or testing during a scheduled period of low activity, and involves the following sequence of events.

  • An NFM-P administrator initiates the activity switch on the primary server.

  • The standby server performs an activity switch to become the new primary server.

  • The new primary server connects to the primary database and manages the network.

  • The new primary server and the auxiliary servers synchronize the request information.

  • If automatic database realignment is enabled, the new primary server attempts a database switchover.

Table 17-2: Redundancy functions, main database

Function

Notes

Database switchover

A database switchover is a manual operation that reverses the primary and standby database roles, for example, for primary database maintenance, or to realign database roles with database stations after a server activity switch.

A switchover can occur only when the primary and standby databases are functioning correctly and can communicate with each other.

A database switchover involves the following sequence of events.

  • An NFM-P administrator initiates the switchover on a primary or standby server.

  • The main server asks each auxiliary server to release all database connections. The switchover fails if all database connections are not released within 15 minutes.

  • The main server directs the standby database to become the primary database.

  • The main server fully synchronizes information with the new primary database.

See How do I perform a main database switchover using the NFM-P client GUI? for information about performing a database switchover.

No automatic database realignment occurs after a database switchover.

Database failover

A database failover is an automatic operation that changes the standby database into a primary database when the original primary database is unreachable, for example, because of a power disruption on the primary database station.

A database failover involves the following sequence of events.

  • No main server can communicate with the primary database within a period that is 2 min by default.

  • The primary main server directs the standby database to become the primary database.

  • If automatic database realignment is enabled and the primary server and database are not aligned, the primary server performs an activity switch.

  • The primary server directs each auxiliary server to connect to the new primary database.

  • The main server restarts after a failover.

When the primary server detects a communication failure with the primary or standby database:

  • The GUI clients are informed that the database is not reachable.

  • A network management outage begins; the GUI clients can monitor the failover, but cannot perform configuration activities.

After the cause of the communication failure is resolved, the GUI clients are notified that the database is reachable, and the network management outage ends.

After the failover, you must reinstantiate the former primary database as the new standby database to restore database redundancy.

Note: If automatic database reinstantiation is enabled, the NFM-P automatically attempts to reinstantiate the former primary database.

Re-establishing database redundancy

Re-establishing database redundancy after a database failure requires database reinstantiation to replicate the current primary database as the standby database.

After a failover, the former primary database is not available for redundancy until an operator or the automatic database reinstantiation function reinstantiates it as the new standby database.

See How do I reinstantiate the main database from the client GUI? and How do I reinstantiate the main database from a CLI? for information about re-establishing database redundancy after a failover.

The following conditions must be met before you can re-establish database redundancy.

  • The failover completes successfully.

  • The station that contains the former primary database is operational.

  • The former primary database proxy port is configured and in service.