This section of the manual covers the installation, basic configuration, and control of the SGC component of OCSS7.
The Rhino-side component of OCSS7, the TCAP stack, is automatically installed with CGIN and has no special installation procedure or requirements beyond those of Rhino and CGIN. Information on configuring the TCAP stack component can be found in TCAP Stack configuration. |
Checking prerequisites
Before installing OCSS7, make sure you have the required:
-
operating system, with
lksctp-tools
installed, and
Before attempting a production installation please also see Network Architecture Planning.
Configuring network features
Before installing OCSS7, please configure the following network features:
Feature | What to configure |
---|---|
IP address |
Make sure the system has an IPv4 or IPv6 address and is visible on the network. |
Host names |
Make sure that the system can resolve |
Firewall |
Ensure that any firewall installed is configured to permit OCSS7 related traffic. The rules required will depend on the Hazelcast network configuration chosen. See the OCSS7 manual section Hazelcast cluster configuration and the Hazelcast 3.7 Reference Manual section Setting Up Clusters for more details on Hazelcast network configurations. In its default configuration the SGC uses multicast UDP to discover other cluster members:
Additionally, Hazelcast uses TCP to form connections between cluster members. By default it listens on all available network interfaces for incoming TCP connections. This uses ports in the range TCP is also used for intra-node communication (comm switch) and SGC to TCAP stack communication. The ports and addresses for these are user configurable and described in General Configuration. SCTP is used by M3UA assocations. See M3UA Configuration. |
IPv6 considerations
When using IPv6 addressing, remember to configure the PREFER_IPV4 property in the SGC_HOME/config/sgcenv file. For details, please see Configuring SGC_HOME/config/sgcenv.
|
User process tuning
Ensure that the user that OCSS7 will be running under has a soft limit of no less than 4096 user processes.
The number of permitted user processes may be determined at runtime using the ulimit command; for example
ulimit -Su This value may be changed by editing
It may also be necessary to increase the hard limit:
|
SCTP tuning
For optimal performance, tune these kernel parameters:
Parameter | Recommended value | What it specifies |
---|---|---|
|
|
Default receive buffer size (in bytes) |
|
|
Default send buffer size (in bytes) |
|
|
Maximum receive buffer size (in bytes) This value limits the |
|
|
Maximum send buffer size (in bytes) This value limits the |
|
|
Minimum retransmission timeout (in ms) This should be greater than the |
|
|
Delayed acknowledgement (SACK) timeout (in ms) Should be lower than the retransmission timeout of the remote SCTP endpoints. |
|
|
SCTP heartbeat interval (in ms) |
Kernel parameters can be changed
|
SGC Installation
To install OCSS7: unpack and configure then create additional nodes.
Recommended Installation Structure
In order to upgrade the SGC cluster in the future using the automated upgrade tool the SGC should be installed following a certain file structure.
The SGC package should be unpacked in the location corresponding to:
$BASE_DIR/cluster_name/node_name/
This results in the following structure:
$BASE_DIR/cluster_name/node_name/ocss7-3.0.0.0/...
A symbolic link current
should be created such that:
$BASE_DIR/cluster_name/node_name/current -> ocss7-3.0.0.0
$BASE_DIR
may be any location.
For example, /home/sentinel/ocss7/
All customizable configuration file locations (sgcenv
, SGC.properties
, hazelcast.xml
, sgc.dat
) must meet the following requirements:
-
Must be specified using a relative path, not an absolute path.
-
The path provided must be wholly located within the SGC installation directory or a sub-directory thereof.
-
Symbolic links are not permitted.
-
Paths that step outside of the SGC installation directory are not permitted.
Examples:
-
config/SGC.properties
— OK, a relative path -
../ocss7-3.0.0.0/config/SGC.properties
— not permitted, leaves the installation directory -
obfuscated/path/config/SGC.properties
wherepath
is a symbolic link — not permitted -
/home/ocss7/cluster/node/ocss7-3.0.0.0/config/SGC.properties
— absolute paths are not permitted
The default location for the named configuration files meets these requirements.
Orca does not support customization of the location of any other configuration files, including config/log4j.xml
.
Log files themselves may be located anywhere on the filesystem.
If the SGC installation structure does not meet these requirements it may not be possible to perform an automated online upgrade. In this case a manual online upgrade may be performed instead. |
Unpack and configure
SGC_HOME
The following instructions use |
To begin the SGC installation and create the first node:
1 |
Unpack the SGC archive file
Run: unzip ocss7-package-VERSION.zip (replacing This creates the distribution directory, |
---|---|
2 |
Make sure that the |
3 |
Configure basic cluster / node information
If your installation will use more than a single node in a SGC cluster, then:
If you are planning to use more than one SGC cluster in the same local network then:
|
Creating additional nodes
After installing the first SGC node in a cluster, you can add more nodes by either:
-
copying the installation directory of an existing node, and changing the
ss7.instance
property inSGC_HOME/config/SGC.properties
to a value unique among all the other nodes in the cluster.
or
-
repeating the installation steps for another node,
-
setting the
ss7.instance
property inSGC_HOME/config/SGC.properties
to a value unique among all other nodes in the cluster, -
setting the
hazelcast.group
inSGC_HOME/config/SGC.properties
to the value chosen as cluster name, and -
repeating any other installation customization steps.
Layout of the SGC installation
A typical SGC installation contains these subdirectories:
Directory | Contents |
---|---|
|
(SGC installation directory)
|
|
SGC management scripts |
|
command line interface installation, including start scripts, configuration, and logs |
|
configuration files which may be edited by the user as required |
|
supplementary documentation included as a convenience, such as SNMP MIB files |
|
Java libraries used by the SGC |
|
third-party software licenses |
|
log output from the SGC |
|
persisted cluster configuration ( |
Running the SGC
SGC operations
JAVA_HOME
The SGC script expects the |
The SGC is started and stopped using the SGC_HOME/bin/sgc
script.
The sgc
script runs SGC under a watchdog: if the SGC process exits for an unrecognized reason it is automatically restarted. Output from the SGC and from the watchdog script is redirected into a startup log file. The startup log files are in SGC_HOME/logs
directory and are named startup.<startup-time>
. If startup fails for any reason, details about the failure should be available in the startup file.
The sgc script is configured in SGC_HOME/config/sgcenv
. The sgcenv
file contains JVM parameters which cannot be provided in the SGC.properties file.
The sgc
script can be run with the following arguments:
Command argument | Optional arguments | Description |
---|---|---|
|
|
Starts the SGC using the configuration from
|
|
|
Stops the SGC. Without the |
|
|
Equivalent of |
|
|
Runs the SGC in test mode. In test mode, SGC runs in the foreground; and logging is configured in |
|
|
Runs the SGC in foreground mode. SGC is not demonized. |
|
Prints the status of SGC and returns one of these LSB-compatible exit codes:
|
For example:
Start SGC |
|
---|---|
Stop SGC |
|
Check SGC status |
|
Configuring SGC_HOME/config/sgcenv
The SGC_HOME/config/sgcenv
file contains configuration parameters for the sgc
script. The following settings are supported:
Variable name | Descriptions | Valid Values | Default |
---|---|---|---|
|
Location of the JVM home directory. |
||
|
Host that SGC should bind to in order to listen for incoming JMX connections. |
IPv4 or IPv6 address |
|
|
Port where SGC binds for incoming JMX connections. It is not recommended to use a port in the emphemeral range as these are used for short-lived TCP connections and may result in the SGC failing to start if the port is in use by another application. The emphemeral port range may be queried with |
|
|
|
Whether or not the JMX connection should be secured with SSL/TLS. For details, please see Securing the SGC JMX management connection with SSL/TLS. |
|
|
|
Whether or not the SGC should require a trusted client certificate for an SSL/TLS-secured JMX connection. For details, please see Securing the SGC JMX management connection with SSL/TLS. |
||
|
Path to the configuration file with properties used to secure the JMX management connection. For details, please see Securing the SGC JMX management connection with SSL/TLS. |
||
|
Password used during generation of the key store and trust store used to secure the JMX management connection. For details, please see Securing the SGC JMX management connection with SSL/TLS. |
|
|
|
Maximum size of the JVM heap space. For details, please see Configuring the Java Heap. |
||
|
Initial size of the JVM heap space. |
||
|
The size (minimum and maximum) of the JVM new generation. |
|
|
|
Full override of default garbage collections settings. |
||
|
Additional JVM parameters. Modifications should add to the existing |
||
|
The log4j configuration file to be used in normal mode (start/restart/foreground). |
||
|
The log4j configuration file to be used in test mode. |
||
|
Location of the SGC properties file. |
||
|
Whether or not the watchdog is enabled. Disabling the watchdog may be required if the SGC is run under the control of some other HA systems. |
|
|
|
Enables additional script information. |
|
|
|
Prefers using IPv4 protocol. Set value to |
|
|
|
On NUMA architecture machines, this parameter allows selecting specific CPU and memory bindings for SGC. |
||
|
On non-NUMA architecture machines, this parameter may be used to set SGC affinity to specific CPUs. |
JMX Connector configuration variables
|
Configuring the Java Heap
The Java Virtual Machine’s MAX_HEAP_SIZE
must be appropriately configured for the SGC. If insufficient heap is configured, then the result may be:
-
Frequent and/or prolonged garbage collections, which may have a negative impact on the SGC’s performance.
-
SGC restarts caused by the JVM throwing
OutOfMemoryError
.
The main factors affecting the selection of an appropriate value are:
-
The base SGC requires a certain amount of heap.
-
The size of the configuration MML.
-
The configured maximum concurrent TCAP transactions (
sgc.tcap.maxTransactions
)
MAX_HEAP_SIZE
is no longer dependent on the number of connected TCAP peers or migrated prefixes.
Recommendations
Factor | Recommendation |
---|---|
Base SGC |
1024MB This value allows for an SGC configured for 1 million The amount required is platform and JVM dependent.
An estimation of the base SGC requirements may be obtained by loading a minimal MML configuration into a test SGC, and then using the |
Configuration MML Size |
Variable Each As each configuration differs substantially it is not possible to provide generic guidelines.
An estimation of a configuration’s minimum requirements may be obtained by loading the full MML configuration into a test SGC, and then using the |
Maximum concurrent TCAP transactions |
1 million transactions requires no additional heap allowance as this is included in the base SGC figure above. 10 million transactions requires approximately 250MB additional heap. 100 million transactions requires approximately 2.5GB additional heap. The maximum number of concurrent TCAP transactions is configured in |
Installing SGC as a service
To install SGC as a service, perform the following operations as user root
:
1 |
Copy # copy $SGC_HOME/bin/sgcd /etc/init.d |
---|---|
2 |
Grant execute permissions to # chmod a+x /etc/init.d/sgcd |
3 |
Create the file SGC=/opt/sgc/PC1-1/PC1/current/bin/sgc SGCUSER=sgc |
4 |
Activate the service using the standard RedHat command: # chkconfig --add sgcd |