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.
In the following instructions,
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.
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.
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.
After each configuration change a new version of
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
SGC Configuration MBean names use the common domain
SGC and a set of properties:
type— represents a subsystem / layer (
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
id property is set based on the
oname (object name) parameter of the
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.