Instances configuration

Instances are defined in the network.yml file. To start, add at the end of the file a new configuration block called 'instances:'.

Let’s have a look at the example of instances configuration block below. Here a part of the configuration details is intentionally skipped for simplicity, in order to just create a first, superficial understanding:

Instances are defined as a list of elements, where each element corresponds to an individual instance, regardless of its type. Each element requires the following parameters to be configured:

Once a list of instances is configured, apply these changes and then push to all the other nodes:

While the changes are being applied, it will be noticeable that the number of generated configuration files increases, compared to what the system has had before. This is because the ngcpcfg framework generates specialized configuration for each single instance using the same base templates.

The system will also add a new service with a specific instance name and it will set this service in the active state by default, if not explicitly defined as 'inactive'.

For example, if the 'kamailio-lb' instance has been defined with a name 'A' and a host 'sp1', then:

The status of the new instance can be checked using the command:

Each instance always has to be reachable independently, regardless of the node/location it currently takes. Due to that, each instance has dedicated floating IP address(es) that is/are migratable between cluster node pairs.

This floating IP address will always stick to its instance and therefore will provide IP connectivity to it.

Here is a list of the interface types to be defined for each instance:

As mentioned before each instance has a paramater called 'host' to define on which node the instance should has to be run by default.

In a normal state, the system will always try to run the instance on the specified node. In case the specified node is down (for any reason, e.g. maintenance), then the instance will be automatically migrated to the pair node. When the default node is back to normal state, then the instance is migrated back together with the floating IP address belonging to it.

On the node where the instance has to be run (or could be run in case of failover), the interface(s) with the same name and subnetwork must be defined.

This means that, if for example a kamailio-proxy instance with the interface 'neth1' and IP 192.168.1.1 is defined, then on any node that it could possibly run on, an interface with the name 'neth1' and with the including subnet must be defined. For example the sub-network '192.168.1.0/24' would fit this demand.

As shown in the Instances Interfaces table, certain instances could require more than one interface. However, the same interface can be used for two or more types of connections. This mainly depends on the network topology and on the system administrator decision (how to define/interconnect these instance elements).

It is important to define the following parameters for each instance interface:

An example on how a definition of the 'instance_lb_1' can look like after adding the interfaces:

In a standard Sipwise C5 system, all the services are working in immovable, predefined order. What that means is that there is no possibility to set a specific kamailio-proxy to work with a specific kamailio-lb. The stack will be always: Lb→Proxy→Sems-b2b, regardless of whether this is a PRO or Carrier grade setup.

A decision was made to give more flexibility in this regard:

This opens up completely new capabilities for the Sipwise C5 system, because it gives a possibility to create a dedicated path for call flow/routing, meaning that it’s possible to define which specific LB, Proxy and Sems-b2b instances are engaged into processing of the SIP call.

The list of connections between instances that can be defined:

By default, instances will automatically try to connect between each other, looking for other instances running on the same node.

The concept of instance connections is also applied in the scope of the NoSQL / SQL databases backend usage, and makes it configurable from a dedicated block of instances called 'databases:'. The setup is able to define connections towards NoSQL and SQL using the configuration based on instances (network.yml), therefore pointing to the desired databases a particular instance must be connected with.

It is important that if instances are enabled templating will try to collect proper values for:

from the:

Which then will be used to build up configuration files for instances as well as the /etc/hosts file, which will contain a list of name translations for the databases. This allows to have host records for connections towards nosql/sql databases, including the local one. Using that approach, the NoSQL database (KeyDB) and the SQL database (Maria DB) can be listening on the internal IP addresses (not on the loopback interfaces) and at the same time not use floating IP addresses, and still be reachable by the instances.

If the database connections are not defined, the Active/Active setup with instances will still work. Hence configuration of the databases is not absolutely a must.

A list of the connections towards databases that can be defined:

This is a list of options/parameters which build up instance connections to other instances/hosts:

Here is an example, how the databases connections for the new kamailio-lb instance can be configured:

When the most important/required steps of the configuration are done and all those migrated standard services are not doing any significant work, they can be safely moved into the offline mode by executing the following commands: