N2CUG Scaling

Overview

The N2CUG platform is designed to allow for flexible and simple scaling in order to achieve required availability and performance levels. Each logical component of N2CUG may have multiple instances present in any given solution. The sections below provide instructions on how these instances should be integrated into the N2CUG 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.

There are no special requirements for having multiple GUI nodes.

SVC Nodes

At least two SVC nodes should be present, with each able to take the projected full load of call 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 calls during both day-to-day activities and maintenance windows.

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

API Nodes

If BSS/OSS continuity is required, multiple API nodes may be used in an active/active setup. These can be loadshared to as required by your IP infrastructure, but note that requests to an API should be sticky in order to preserve user sessions.

DB Nodes

If multiple DB instances are used within an N2CUG platform, the one key rule is that there must always be only a single N2CUG 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 N2CUG database, to be used by the API 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 N2CUG 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 N2CUG 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.