This document covers configuring the Sh Cache Microservice and Sh Cache Microservice Resource Adapter

Topics

This document includes the following topics:

Topic Explains…​

Configuring the Sh Cache Microservice

how to install and configure the Sh Cache Microservice

Configuring the Sh Cache Microservice RA

how to deploy and configure the Sh Cache Microservice RA

Sh Cache Microservice Configuration

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.

Sh Cache Microservice RA Configuration

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:

  1. 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

proxy.enabled

Boolean

False

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.

proxy.host

String

localhost

The hostname of the proxy server.

proxy.port

Integer

4140

The port of the proxy server.

serverURL

String

http://localhost:8088/shcache/v1

The URL for the Sh Cache Microservice.

http.ioThreads

Integer

2

The number of threads to use for processing HTTP requests and responses.

http.connectTimeout

Integer

5s

The connect timeout in seconds.

http.idleTimeout

Integer

0s

The idle timeout in seconds. 0 means no timeout.

http.requestTimeout

Integer

5s

The request timeout in seconds.

http.keepAlive

Boolean

True

Whether to use HTTP keep-alive.

http.keepAliveTimeout

Integer

60s

HTTP keep-alive timeout in seconds.

http.maxPoolSize

Integer

5

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.

http.notificationURL

String

http://localhost:8089

The URL that notifications from Sh Cache Microservice will be sent to. This hostname must be able to be resolved by ShCM hosts.

http.notificationPort

Integer

8089

Port to listen on for notifications.

http.notificationPortOffsetEnabled

Boolean

false

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.

http.notificationPortOffsetBase

Integer

101

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.

http.notificationBindAddresses

String

""

Specify notification server bind addresses for each node in the cluster. A comma-separated list of {node}host:port elements, for example "{101}10.0.0.1:8100,{102}10.0.0.2:8100". Overrides the http.notificationPort property. If undefined then the server binds to all interfaces on http.notificationPort.

subscriptionExpiryTime

Integer

3600

Subscription expiry time in seconds.

notificationServerEnabled

Boolean

true

Enable the notification server to receive HTTP notifications for UE Reachability For IP

netty.logging.enabled

Boolean

false

Enables logging in netty used by vert.x. For debugging purposes only, don’t use in production!