Notices
Copyright © 2014-2019 Metaswitch Networks. All rights reserved
This manual is issued on a controlled basis to a specific person on the understanding that no part of the Metaswitch Networks product code or documentation (including this manual) will be copied or distributed without prior agreement in writing from Metaswitch Networks.
Metaswitch Networks reserves the right to, without notice, modify or revise all or part of this document and/or change product features or specifications and shall not be responsible for any loss, cost, or damage, including consequential damage, caused by reliance on these materials.
Metaswitch and the Metaswitch logo are trademarks of Metaswitch Networks. Other brands and products referenced herein are the trademarks or registered trademarks of their respective holders.
Configure the Sh Cache Microservice
Configuring ShCM via the Config Data Store
In common with all the other VMs in a Sentinel deployment, ShCM is configured by uploading yaml configuration files to the Config Data Store (CDS). The uploaded config is detected by the initconf
process on the ShCM nodes, which pulls down the config and applies it automatically.
The CDS is provided by the TSN cluster, which also provides the Cassandra used by ShCM (and other node types).
The yaml files provided to the CDS describe the whole solution, consisting of nodes of various types, and how they interconnect. Thus the config data can describe the pooled cluster of TSN nodes, which ShCM uses to store its Cassandra data, and another part of the data describes the SAS node, which ShCM can use to log traces to.
Documentation on how to write the YAML configuration files and SDF for ShCM, and how to upload them to CDS along with a Rhino license, can be found on the Bootstrap and initial configuration
page in the ShCM Install Guide, linked here.
Differences to previous ShCM deployments
Prior to the Sentinel 3.1 release, ShCM was shipped with its own specific configurer
tool, which performed multiple tasks:
-
configure ShCM properties (via a
shcm.properties
file) -
configure Diameter (via a
DiameterConfiguration.xml
file) -
install the Rhino licence file
-
provide a way to run an arbitrary set of rhino-console commands
With the exception of the last stage, these features are all now provided by the CDS upload process.
Notices
Copyright © 2014-2019 Metaswitch Networks. All rights reserved
This manual is issued on a controlled basis to a specific person on the understanding that no part of the Metaswitch Networks product code or documentation (including this manual) will be copied or distributed without prior agreement in writing from Metaswitch Networks.
Metaswitch Networks reserves the right to, without notice, modify or revise all or part of this document and/or change product features or specifications and shall not be responsible for any loss, cost, or damage, including consequential damage, caused by reliance on these materials.
Metaswitch and the Metaswitch logo are trademarks of Metaswitch Networks. Other brands and products referenced herein are the trademarks or registered trademarks of their respective holders.
Configure the Sh Cache Microservice RA
Sh Cache Microservice configuration
The Sh Cache Microservice resource adaptor has configuration properties related to:
-
The Sh Cache Microservice to connect to — hosts and ports
The Sh Cache Microservice instance to connect to
These configuration options define the host the resource adaptor entity should connect to …
Name | Type | Default | Description |
---|---|---|---|
|
|
|
Whether to use a proxy server. When using a proxy server, all connections are routed through the proxy server. The request URL for messages, as determined by the server URL below, is not affected by this setting. |
|
|
|
The hostname of the proxy server. |
|
|
|
The port of the proxy server. |
|
|
The URL for the Sh Cache Microservice. |
|
|
|
|
The number of threads to use for processing HTTP requests and responses. |
|
|
|
The connect timeout in seconds. |
|
|
|
The idle timeout in seconds. 0 means no timeout. |
|
|
|
The request timeout in seconds. |
|
|
|
Whether to use HTTP keep-alive. |
|
|
|
HTTP keep-alive timeout in seconds. |
|
|
|
HTTP connection pool size. The pool size per thread is this number divided by http.ioThreads, rounded up. Therefore the actual max pool size could be slightly bigger than this configured value. |
|
|
The URL that notifications from Sh Cache Microservice will be sent to. This hostname must be able to be resolved by ShCM hosts. |
|
|
|
|
Port to listen on for notifications. |
|
|
|
Required when running multiple cluster nodes on the same host. If true, the RA will automatically add an offset to the notification port number so that each ShCM RA instance gets a different port number. |
|
|
|
Required when running multiple cluster nodes on the same host. If http.notificationPortOffsetEnabled is enabled, the ShCM RA’s port will be calculated as Port + (NodeID - PortOffset). Typically the PortOffset value used is the lowest NodeID in the cluster. So if http.notificationPort is 8089, the lowest NodeID is 101, this value is configured to 101, and the cluster has nodes 101, 102 and 103, the SIP ports used will be 8089, 8090 and 8091 respectively. |
|
|
|
Specify notification server bind addresses for each node in the cluster. A comma-separated list of |
|
|
|
Subscription expiry time in seconds. |
|
|
|
Enable the notification server to receive HTTP notifications for UE Reachability For IP |
|
|
|
Enables logging in netty used by vert.x. For debugging purposes only, don’t use in production! |