N2SIP Scaling

Overview

The N2SIP platform is designed to allow for flexible and simple scaling in order to achieve required availability and performance levels. Each logical component of N2SIP may have multiple instances present in any given solution. The sections below provide instructions on how these instances should be integrated into the N2SIP platform as a whole.

GUI Nodes

As many GUI nodes as required may be used. The load on such nodes is normally very light, so multiple nodes are generally only used to provide redundancy and business continuity.

When multiple GUI nodes are used, a single node must be nominated as the primary node for all provisioning, replicating to all other GUI (and SVC) nodes. When the primary GUI node is out of service, a replicated GUI node may be used instead.

Note that in addition to the information in the database, announcement files are stored on disk and replicated as required.

SVC Nodes

At least two SVC nodes should be present, with each able to take the projected full load of traffic. This allows maintenance of one node at a time while still providing service. It is expected that the signalling network will perform the appropriate loadsharing of traffic during both day-to-day activities and maintenance windows.

Note that each session, once started, must be affined to a single SVC node in order to hold the transaction state; this is not shared between SVC nodes.

DB Nodes

If multiple DB instances are used within an N2SIP platform, the one key rule is that there must always be only a single N2SIP database that is used for provisioning and updates, and that any other database becomes a replica of the master database and may only be used for queries.

When multiple DB instances are used, they are generally deployed as:

• a single warm-failover replica N2SIP database, to be used by the GUI node(s) if the primary database becomes unavailable, and
• a single replica database for each SVC node for runtime queries.

However, these general recommendations are not firm requirements; as long as there is a single master N2SIP database for any changes, the remaining nodes can use any database for queries (even the master).

If more than one DB node is used, replication must be configured to keep synchronicity between the primary N2SIP database and every other replica database used by API and/or SVC nodes. Such replication can be done in whatever manner is normally used by your existing IT infrastructure for PostgreSQL databases.