N2ACD Scaling

Overview

The N2ACD platform is designed to allow for flexible and simple scaling in order to achieve required availability and performance levels. Each logical component of N2ACD may have multiple instances present in any given solution. The sections below provide instructions on how these instances should be integrated into the N2ACD 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 N2ACD platform, the one key rule is that there must always be only a single 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 database, to be used if the primary database becomes unavailable, and
• a single replica database for each SVC for runtime queries.

However, these general recommendations are not firm requirements; as long as there is a single master 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 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.

REP Nodes

Multiple REP nodes may be used if BSS/OSS continuity is required for reporting, although this is unusual. If more than one REP node is used, requests may be loadshared between any of the REP nodes as required; there are no sessions used for reporting queries.

RDB Nodes

The implementation of multiple RDB nodes follows a similar pattern to that of multiple DB nodes. Again, there must only be one master database that ingests all data, and then as many replica databases as required. Any of the databases may be used or queries.

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

MIG Nodes

No scaling should be required for MIG nodes, as they are only used as a once-off processor for data migration.