Stack configuration and cluster joining
The main functions of the configuration subsystem are:
-
managing, distributing, and persisting SGC Stack configuration
-
performing the cluster-join procedure.
Below are details of the cluster-join procedure (which is part of SGC Node initialization) and a basic description of the JMX MBeans exposed by the configuration subsystem that may be of use when developing custom management tools.
|
SGC_HOME
In the following instructions, |
Cluster-join procedure
During startup, if the SGC cluster already exists, a node instance initiates a cluster-join procedure. The configuration system loads a locally persisted configuration and compares its version vector against the current cluster configuration.
| IF | THEN |
|---|---|
Versions are equal, or the local version is stale. |
The SGC node uses the cluster configuration state. It joins the cluster and instantiates a cluster-wide and per-node state. |
The local version is greater. |
The local instance first instantiates all configuration objects which are not present in the cluster. Then it updates all configuration objects which are defined both in the cluster and in the local configuration. Finally, it deletes all configuration objects which are not present in the local configuration. |
There is a version conflict. |
The node aborts the cluster-join procedure, outputs a failure log message, and aborts start up. |
Version conflict reconciliation
The local node stores a copy of the configuration in the SGC_HOME/var/sgc.dat file in the SS7 SGC node working directory. This is an XML file containing the entire cluster configuration as last known by that node. The usual approach to configuration reconciliation is for the node to join the cluster and use the current cluster configuration to initialize (dropping its local state).
|
To force this behaviour, remove or rename the SGC_HOME/var/sgc.dat file containing persisted configuration.
|
|
|
Configuration backup
After each configuration change a new version of |
Factory MBeans for configuration objects
The SS7 SGC Stack is built around a configuration subsystem that plays a central role in managing the lifecycle of all configuration objects in SGC. SS7 SGC configuration is exposed through a set of JMX MBeans on each node. The configuration subsystem exposes a set of "factory" MBeans that are responsible for creating configuration objects of a certain type.
Each factory MBean exposes either one or two create- operations used to create new configuration objects (a create operation that accepts more parameters allows for defining optional configuration object attributes during creation). The creation of a configuration object results in the creation of an MBean representing the state of that configuration object. Attributes can be modified directly through that MBean, which also exposes a remove operation that allows removal of the configuration object (and associated MBeans).
|
|
Command-Line Management Console
These processes are abstracted away by the Command-Line Management Console and exposed as a set of CRUD commands. |
Configuration MBean naming
SGC Configuration MBean names use the common domain SGC and a set of properties:
-
type— represents a subsystem / layer (general,m3ua,sccp, orsnmp) -
category— represents the name of the factory in the subsystem -
id— represents that instance of the processing object.
For example, the cluster node factory MBean has the name SGC:type=general,category=node, which exposes the create-node operation. Invoking the create-node operation creates a processing object representing a node in the cluster with the object name SGC:type=general,category=node,id=NODE_NAME. The id property is set based on the oname (object name) parameter of the create-node operation.
Most GUI-based JMX-Management tools represent the naming space as a tree of MBean objects, like this:
|
|
There is a single special MBean object named SGC:type=general,category=parameters that is neither a factory MBean nor a processing object. This MBean stores cluster-wide system parameters.
|
