N2VS Scaling

Overview

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

GUI nodes consist of static stateless HTTP browser SPA content. Normally a load balancer across two GUI nodes is appropriate for a N2VS deployment.

API Nodes

As many API nodes as required may be used. API nodes support HTTP REST endpoints for the N2VS GUI and other 3rd party BSS integrations. The load on such nodes is normally very light, so multiple nodes are generally only used to provide redundancy and business continuity.

When multiple API nodes are used load balancing can be used to select the API node to use. Due to requirements on authentication, sticky HTTP sessions should be used to ensure that session cookies are maintained across multiple requests.

SVC Nodes

At least two SVC nodes should be present, with each able to take the projected full load of voucher query and redemption traffic. This allows maintenance of one node at a time while still providing service. Each request to a service node is stateless, so load balancing across all SVC nodes can be performed by reverse proxy load balancers.

Note that the service node queue-processor is designed to run on each service node.

DB Nodes

Voucher Database

The voucher database is a MongoDB database instance, and will require at least two data nodes and at least one additional arbiter node. The MongoDB database instance can be scaled as required for data storage requirements.

SMF Database

The SMF database is a PostgreSQL database and will have a primary instance. A second “warm standby” instance is also recommended to maintain a replicated copy of the primary instance. The standard N2VS N-Squared installation will use a repmgr deployment for automated failover between the two instances.

Note that the SMF database does not store vouchers. The SMF database instances do not require significant resources.