What is an NSP auxiliary database?

Description

An NSP auxiliary database provides additional statistics data storage, and is required for advanced storage and retrieval for functions such as NSP Analytics. An auxiliary database is deployed on one station, or as a cluster of three or more stations, depending on the scale requirements.

Auxiliary database deployment also supports geographically redundant, or geo-redundant, deployment using functionally identical auxiliary database clusters in separate data centers.

An NSP operator uses a RESTCONF API call to return the auxiliary database status, as described in How do I check the auxiliary database status?.

Auxiliary database fault tolerance

The following provide auxiliary database fault tolerance:

• hardware redundancy, in a multi-station cluster

• geographically redundant clusters; see Geo-redundant deployment

• data replication among the stations in a multi-station cluster, and between clusters in a geo-redundant deployment

• manual and scheduled database backups

Hardware redundancy

If enough members of an auxiliary database cluster fail, the cluster is considered to be failed, and an alarm is raised. When a geo-redundant cluster fails, the local NSP cluster initiates an auxiliary database switchover, and the standby cluster assumes the primary role.

In order for a cluster to be considered failed, the number of unavailable cluster members varies by the cluster size:

• one-member cluster—one

• three-or-more-member cluster—two

Geo-redundant deployment

Auxiliary database deployment supports geo-redundancy, in which an auxiliary database cluster is deployed in each data center of a DR NSP deployment.

The auxiliary database cluster that has the primary role processes transactions and replicates the data to the standby cluster every 30 minutes.

In the event that the primary auxiliary database cluster is unreachable, the standby cluster initiates a database failover and assumes the primary role. The failover function is independent of NFM-P or NSP system redundancy functions, and is non-revertive. How do I perform an auxiliary database switchover? describes how to switch the auxiliary database cluster roles in a DR deployment, which may be required after a failover to restore the initial primary and standby cluster roles.

For more information about auxiliary database redundancy, see Auxiliary database geographic redundancy.

Note: During some internal operations, the status of one or more standby cluster members may be UNREACHABLE temporarily, and is no cause for concern.

Backups and restores

An auxiliary database backup operation backs up the database data on each auxiliary database station in the primary cluster. Scheduled backups are strongly recommended.

Note: Scheduled auxiliary database backups are disabled by default.

See How do I schedule auxiliary database backups? and How do I perform an auxiliary database backup? for information.

Although an auxiliary database may be distributed among multiple stations, a database restore operation is initiated on one station, and automatically replicates the restored data among the other stations, as required.

See How do I restore an auxiliary database? for information.

Fault detection

To detect a database failure or a connectivity loss, the local NFM-P main server or NSP cluster monitors each station in the primary auxiliary database cluster. If a failure is detected, the NSP raises one of the following major or critical alarms, which are not self-clearing unless otherwise noted:

• cluster member unavailable

• database unavailable

• for geo-redundancy:

  • database proxy down (self-clearing)

  • primary cluster unreachable

  • cluster copy failure

  • activation failure

  • activation triggered.

  • standby cluster unreachable

Note: The geo-redundancy alarms are NSP alarms, so are not reported by the NFM-P. The alarm information is available to subscribers of the Kafka FAULT topic, and to RESTCONF API clients, but not to NFM-P XML API clients.