A DR NSP deployment consists of identical active and standby NSP clusters and ancillary components in separate, geographically distributed data centers, or “sites”. One cluster has what is called the active role, and processes all client requests.

The standby NSP cluster in a DR deployment operates in warm standby mode. If a cluster failure is detected on the active site, the standby automatically initializes and fully assumes the active role.

The following NSP DR functions swap the active and standby NSP cluster roles:

• failover—automatic DR role change initiated by the standby NSP cluster when a cluster failure is suspected on the active site

• switchover—manual DR operation that switches the NSP cluster roles

Note: Nokia strongly recommends that all components of a cluster site in a DR deployment be in the same physical facility. An NSP administrator can align the NSP component roles, as required.

NSP Role Manager

The nsp-role-manager pod runs the Role Manager service in each NSP cluster in a DR deployment. The Role Manager monitors communication between the clusters, and triggers a failover if communication fails.

The Role Manager has the following operation modes:

• standalone: The Role Manager sets the cluster mode to 'active' at initialization time, and does nothing more.

• DR: The Role Manager negotiates the local role with the DR peer, determining which cluster will run in 'active' and which in 'standby' mode.

The Role Manager uses the configuration in the dr section of the NSP configuration file to identify the local and peer sites.

The redundant nsp-role-manager agents exchange an application-level HTTPS check every ten seconds. If the agent on the standby cluster does not receive a response after 12 attempts, that is, approximately two minutes, the standby cluster is promoted to active.

Split-brain

When communication between the NSP clusters fails, each NSP cluster assumes the active role, creating a split-brain scenario. A two-minute loss of communication between the active and standby NSP clusters may trigger a failover.

After communication in a split-brain scenario is restored, the NSP cluster with the higher uptime value assumes the active role, and the peer cluster assumes the standby role. The assumption is that the cluster running for the longer time was the active cluster at the time of the loss. In such a scenario, the clients continue to communicate with the same active cluster.

When the oldest role manager restarts during a split brain situation, resolution of the split brain resembles a failover.

Autonomous System Manager

The nspos-asm-app pod runs the ASM (Autonomous System Manager) service within each NSP cluster in a DR deployment.

The ASM service monitors the following NSP base services in a DR deployment:

• ZooKeeper

• Kafka

• PostgreSQL

• nspos-tomcat

• nsp-tomcat

• Keycloak

• prometheus-server

• nfs-server, if deployed

If any base service in a DR deployment is unavailable for more than three minutes, or two instances of a service in an HA+DR deployment are unavailable for more than three minutes:

• a failover occurs; consequently, the peer NSP cluster assumes the active role

• an alarm is raised against the service or containing pod to indicate that the service or pod is down

  Note: Such an alarm may not be generated because of a base service disruption, depending on the circumstances.

• a major ActivitySwitch alarm is raised against the former active site, which is now the standby site

The following are the alarms that the NSP raises against the NmsSystem object in response to such a failure:

• ActivitySwitch—severity Major

• NspApplicationPodDown—severity Critical

Note: If you clear an alarm while the failure condition is still present, the NSP does not raise the alarm again.

The following example describes an alarm condition in a simple DR deployment.

1. An nspOS service at the active site fails.

2. A failover occurs; the standby site consequently assumes the active role.

3. A major ActivitySwitch alarm is raised against the former active site, which is now the standby site.

DR for integrated components

A DR NSP deployment can include NFM-P and WS-NOC. NFM-P can be standalone or redundant; however, WS-NOC must be redundant. For example, if a DR deployment includes classic mediation, the NFM-P can be standalone and WS-NOC is redundant.

The following figure shows a simple NSP DR deployment.

Figure 8-1: NSP DR deployment with integrated NFM-P