NSP deployment

NSP deployment types

An NSP deployment in a data center consists of the following, as outlined in NSP system architecture:

Production deployment

Figure 1-1, NSP system, production deployment shows an example three-node NSP cluster and a number of external RPM-based components. Depending on the specified NSP deployment profile and installation options, a cluster may have additional nodes.

Figure 1-1: NSP system, production deployment
NSP system, production deployment
Lab deployment

A one-node NSP cluster is used in a lab deployment, as shown in Figure 1-2, NSP system, lab deployment.

Figure 1-2: NSP system, lab deployment
NSP system, lab deployment
NSP system redundancy

The NSP components support standalone and redundant deployment as well as High Availability (HA) deployment of NSP services in a fault-tolerant multi-node NSP cluster called an enhanced cluster. HA is achieved using Kubernetes pod replicas. NSP service HA ensures minimal downtime in the event of a primary instance failure, and avoids a system switchover to the redundant NSP data center.

A NSP deployment can include the NFM-P and WS-NOC , which also support redundant deployment. When a NSP deployment includes the NFM-P or WS-NOC , each system must use the same redundancy model—standalone or redundant; mixed redundancy models are not supported.

Note: A redundant NSP deployment supports classic HA and fast-HA WS-NOC deployment; see the NSP 23.11 Release Notice for compatibility information.

In a redundant deployment of NSP that includes the NFM-P and WS-NOC , the primary NSP cluster operates independently of the primary NFM-P and WS-NOC ; if the NSP cluster undergoes an activity switch, the new primary cluster connects to the primary NFM-P and WS-NOC . Similarly, if the NFM-P or WS-NOC undergoes an activity switch, the primary NSP cluster connects to the new primary NFM-P or WS-NOC .

Figure 1-3, Redundant NSP deployment including NFM-P and WS-NOC shows a fully redundant NSP deployment that includes the NFM-P and WS-NOC .

Figure 1-3: Redundant NSP deployment including NFM-P and WS-NOC
Redundant NSP deployment including NFM-P and WS-NOC
VSR-NRC redundancy

The VSR-NRC also supports redundant deployment. A standalone NSP can be deployed with a standalone or redundant VSR-NRC. When NSP is installed with a redundant VSR-NRC, if the communication channel between NSP and primary VSR-NRC fails, then the NSP switches communication to the standby VSR-NRC.

In a DR deployment of NSP, a redundant deployment of VSR-NRC is required. The primary NSP will communicate to NEs through the primary VSR-NRC, but if the communication channel to primary VSR-NRC fails, then the primary NSP can switch to the standby VSR-NRC.

Figure 1-4: Redundant NSP deployment with redundant VSR-NRC
Redundant NSP deployment with redundant VSR-NRC

When an activity switch takes place between redundant NSP clusters, the new active NSP cluster communicates with IP NEs through its corresponding VSR-NRC instance.

MDM redundancy and HA

The MDM is deployed within the NSP cluster. In an NSP cluster, a maximum of two MDM pods can be deployed on each node within the cluster (eg. a 3 node cluster can deploy a maximum of 6 MDM pods). In a redundant NSP cluster deployment, each NSP cluster will have the same number of nodes and MDM instances.

In a NSP cluster, the MDM pods are deployed in a N+M deployment (where N+M equals the number of nodes in the cluster), with N active MDM instances and M standby instances. If an active MDM instance fails, a standby MDM instance in the active cluster will take over management of the nodes that were managed by the failed MDM instance. When the failed instance recovers, it becomes a standby instance (it will not automatically revert to active). When more than M active MDM instances fail, a manual activity switch to the standby NSP cluster will be required. Each NSP cluster must have the same N+M configuration of MDM.