Introduction

Purpose and scope

Resilient configuration of SIP Cluster that provides optimal configuration and distribution of SIP signalling/media servers, better resources utilization of the service provider's servers/network. Also opens a possibility for zero-downtime upgrades in the future. 

Collaborators

Business Department

• Andriy Zhylenko

Development Department

• Andrey Kosachenko
• Unknown User (psv)

Testing and Support Departments

Definitions, acronyms and abbreviation

• Site - a named group of servers logically combined by administrator of the system.
• Single-site configuration - an installation of PortaSwitch where all servers are assigned to the same single site.
• Multi-site configuration - an installation of PortaSwitch servers that is dispersed across two or more sites. Strictly speaking this term has a broad meaning since it doesn't define a principle according to which servers are dispersed across sites (geographical distribution, some kind of logical distribution like "a group of servers in DMZ" or "a group of servers with fiber interconnection", whatsoever).

• Geo-redundant configuration - a multi-site configuration where each site is constituted by a group of servers from a remote collocation (in this regard "geo-redundant configuration" is one of possible "multi-site"  configurations).

• VIP address - a predefined and roaming IP address managed by a cluster exclusively. In case of failover cluster relocates it from a failed node to another one. Cluster guarantees that this address is active at one node only at any given moment of time. 

References

1. https://docs.portaone.com/DevelDocs/Specifications/GeoRedundancy
2. http://portaone.com/portaswitch/redundancy/
3. TT#415864
4. TT#437944

Overview

Whilst single-site configuration of SIP Cluster provides a decent level of redundancy (components are either duplicated like dispatching nodes or have multiple instances like processing nodes) service providers may still want to have multiple geographically dispersed sites. The rationale behind it is simple and straightforward: service providers want to keep providing the service without disruption to end-users if one of the sites goes down entirely (network abruptions, disasters, massive power outages, etc.).

Additionally service providers want to keep providing the service of high quality taking into account available resources (servers) and their location. For instance for the sake of traffic flow optimization and possible delays minimization in geo-redundant configurations it makes sense to configure a network in such a way that subscriber is provided the service on the server/site closest to him and only redirected to another one if the local one is unavailable for some reason.

When it comes to building multi-site SIP Clusters there are several configurations possible (for the sake of simplicity a configuration with two sites main and secondary is considered):

• Single SIP Cluster dispersed over several sites.

This is a SIP Cluster having it's nodes on both sites so all nodes belong to the same single cluster. There are two possible variations though.

1. • "Active-Standby" - services are provided by nodes located on the main site only. Whenever a main site goes down nodes from a secondary site are activated and keep providing the service until the main site is back again. If sites are not geographically distributed then a single VIP address is required only (cluster moves the VIP address between sites depending on their availability)

• • "Active-Active" - services are provided by all nodes located on all sites. Whenever main site goes down nodes from a secondary site take over and keep providing the service (this comes at cost of additional load)  until the main site is back again. Whenever secondary site is down the service is provided by nodes located on the main site (again at cost of additional load).

• Independent SIP Clusters: one cluster per site

This is a configuration where there are two SIP Clusters configured (one per site). SIP Clusters perform independently and know nothing about each other. This is the simplest possible configuration unless "Active-Standby" flavor is required.

Obviously specific multi-site configurations may suite better in different situations. However supporting all possible variations significantly complicates a configuration and understanding. Finally different flavors of multi-site cluster configurations may require special care during upgrades which is essential since upgrade is a potential cause of service outage. So a configuration of independent SIP Clusters (single SIP Cluster per site) using "Active-Active" schema is the optimal one

Specifiations

Create "Business requirements"  Create "Design requirements"

Testing plan

Feature integration guide