73 Managing Nodes and Clusters in ECE

Learn how to manage nodes and clusters in Oracle Communications Billing and Revenue Management Elastic Charging Engine (ECE).

Topics in this document:

Adding Nodes

Use the Elastic Charging Controller (ECC) addNode command to add nodes. The addNode command adds an entry for the node in the topology file.

  1. On the driver machine, go to the ECE_home/bin directory.

  2. Start Elastic Charging Controller (ECC).

    ./ecc
  3. Run the ECC addNode command.

    addNode node_name role host_name host_ip JMX_port start_CohMgt JVM_tuning_file

    where:

    • start_CohMgt specifies if the node is a JMX-management-enabled node, which runs a driver machine. Enter true or false.

    • JVM_tuning_file is the JVM tuning file that contains the tuning profile for the node. This file specifies the number of threads, memory, and heap size. Create this file in the ECE_home/config directory by copying, renaming, and editing the defaultTuningProfile.properties file. See "Configuring JVM Tuning Parameters".

  4. Run the ECC start command to start the new node.

Removing Nodes

Use Elastic Charging Controller (ECC) removeNode command to remove nodes. The removeNode command removes the entry for the node from the topology file.

  1. On the driver machine, path to the /oceceserver/bin directory.

  2. Start Elastic Charging Controller (ECC).

    ./ecc
    
  3. Run the ECC stop command to stop the node.

  4. Run the ECC removeNode command.

Configuring Cluster Quorum Policy

The cluster quorum policy specifies the minimum number of cluster members that must remain in the cluster, without causing data loss, when the cluster service is terminating suspect members. This ensures that a cluster always contains a sufficient number of cluster members to operate successfully.

A member is considered suspect if it does not respond to network communications and is in imminent danger of being disconnected from the cluster.

You specify the required minimum by setting the timeout-survivor-quorum value, which can be calculated using this formula:

timeout-survivor-quorum = (NumberofHosts – 1) * NumberECSperHost

where:

  • NumberofHosts is the number of ECE hosts in your Coherence cluster.

  • NumberECSperHost is the number of ECE Charging Servers (ECSs) per host.

For example, if your ECE system contains 8 ECE VM hosts with 4 ECSs per VM host, you would set timeout-survivor-quorum to 28 [that is, (8 – 1) * 4)].

To configure the cluster quorum policy for ECE:

  1. Open the ECE_home/config/charging-coherence-override-environment.xml file in a text editor, where environment is dev for your test or development servers, or prod for your production servers.

  2. Set the <timeout-survivor-quorum> element to the minimum number of cluster members in a cluster when the cluster service is terminating suspect members:

    <cluster-quorum-policy>
       <timeout-survivor-quorum>value</timeout-survivor-quorum>        
    </cluster-quorum-policy>
  3. Save and close the file.

Adding Diameter Gateway Nodes for Online Charging

The ECE installer adds a single instance of a Diameter Gateway node (diameterGateway1) to your topology. By default, this single node listens to all network interfaces for Diameter messages.

When adding Diameter Gateway nodes:

  • In an ECE production environment, use two Diameter Gateway node instances per machine to allow for failover and additional nodes as needed to handle the expected throughput for your system.

  • For a development installation on a single machine, the minimum configuration is three charging server nodes and two Diameter Gateway node instances to allow for failover. Server redundancy is a minimum requirement of ECE installations.

To add Diameter Gateway nodes:

  1. Access the ECE configuration MBeans in a JMX editor, such as JConsole. See "Accessing ECE Configuration MBeans".

  2. Expand the ECE Configuration node.

  3. Expand charging.diameterGatewayConfigurations.

  4. Expand Operations.

  5. Select addDiameterGatewayConfiguration.

  6. In the name field, enter a name for the Diameter Gateway node.

  7. Click the addDiameterGatewayConfiguration button.

    You have created a Diameter Gateway node.

    (Optional) To fully configure the Diameter Gateway node now, specify values for all Diameter Gateway node configuration properties. See "Configuring Diameter Gateway Nodes". Alternatively, first create multiple nodes, and later configure them.

  8. Open the ECE_home/config/eceTopology.conf file.

  9. Add a row for the Diameter Gateway node instance.

  10. For that row, enter the following information:

    • Name of the JVM process for the node instance.

      Enter the name used when the node instance was created in the JMX editor.

    • Role of the JVM process for the node instance.

      Enter the role diameterGateway.

    • Host name of the physical server machine on which the node resides.

    • JVM tuning file that contains the tuning profile for the node.

  11. Save the file.

Configuring Diameter Gateway Nodes

For each Diameter Gateway node, you must configure connection and performance options.

To configure Diameter Gateway nodes:

  1. Access the ECE configuration MBeans in a JMX editor, such as JConsole. See "Accessing ECE Configuration MBeans".

  2. Expand the ECE Configuration node.

  3. Expand charging.diameterGatewayConfigurations.Instance_Name, where Instance_Name is the name of the instance to configure.

  4. Expand Attributes.

  5. Specify values for all the attributes required to configure the instance.

    See Table 73-1 for attribute descriptions and default values.

  6. Change directory to the ECE_home/bin directory.

  7. Start the Elastic Charging Controller:

    ./ecc
  8. Do one of the following:

    • If the Diameter Gateway instance is not running, start it.

      The instance reads its configuration information by name at startup.

    • If the Diameter Gateway instance is running, stop and restart it.

Table 73-1 Diameter Gateway Node Configuration Attributes and Values

Attribute Name Default Value Description

name

"diameterGateway1"

The name of the Diameter Gateway instance.

Name Diameter Gateway node instances consistently and uniquely (for example, diameterGateway1, diameterGateway2, and so on.

If you change the name of an existing instance, you must update the name in the ECE_home/config/eceTopology.conf file.

clusterName

"cluster1"

The cluster name of the Diameter Gateway instance.

ECE uses both name and clusterName to identify a Diameter Gateway instance. You must specify a different clusterName if you are configuring Diameter Gateway nodes with the same name.

Note: Ensure that this clusterName matches the clusterName in the ECE_home/config/charging-coherence-override-secure-prod.xml file.

diameterTrafficHost

""

The network interface (on the physical or virtual host computer that is running the Diameter Gateway node instance) that the Diameter Gateway node binds to and listens on for Diameter messages.

The value can either an IP address or a host name.

The value can also be an empty string (the default). In that case, the Diameter Gateway instance listens for Diameter messages on all network interfaces available on the server.

diameterTrafficPort

"3868"

The port (on the physical host computer that is running the Diameter Gateway node instance) the Diameter Gateway instance listens on for handling Diameter messages.

When adding new Diameter Gateway instances, choose a port number that is not in use by another application.

When multiple Diameter Gateway instances run on the same physical host computer, each instance must use a different port number.

diameterTrafficHostSctp

""

When SCTP is used, the network interface (on the physical or virtual host computer that is running the Diameter Gateway node instance) that the Diameter Gateway node binds to and listens on for Diameter messages (sent from Diameter clients).

The value can be either an SCTP IP address or host name or multiple SCTP IP addresses or host names.

The value can also be an empty string (the default). In that case, SCTP transport is disabled.

For a multihoming system, multiple IP addresses can be specified separated with a semi colon (;).

For example:

10.240.179.147;10.240.182.149

To use this configuration, your operating system must have SCTP support. Verify that your operating system has SCTP support. If not, install the SCTP system package for your operating system version.

sctpMaxInStream

""

The maximum number of incoming streams allowed per association. Valid range is 0 to 65535.

sctpMaxOutStream

""

The maximum number of outgoing streams allowed per association. Valid range is 0 to 65535.

sctpReceiveBufferSize

""

The buffer size for receiving data (in bytes). Valid range is 0 to 2147483647.

This attribute determines the SCTP receiver window size. You can increase or decrease the size based on your requirement. For example, you can increase the size for high-volume connections or decrease the size if you want to limit the incoming data backlog.

sctpSendBufferSize

""

The buffer size for sending data (in bytes). Valid range is 0 to 2147483647.

This attribute determines the maximum amount of data that can be sent in a single transaction. You can increase or decrease the size based on your requirement.

originHost

No default value

Setting a value for this field is mandatory.

The Origin-Host attribute-value pair (AVP) to be sent in the Diameter request. This is a unique identifier that you assign your Diameter Gateway server on its host. It can be any string value.

originRealm

No default value

Setting a value for this field is mandatory.

The Origin-Realm AVP to be sent by the Diameter Gateway in outgoing Diameter requests. This is the signaling realm (domain) that you assign your Diameter Gateway server.

You must set the same the origin realm value for all Diameter Gateway instances in the same ECE topology.

loopback

"false"

Specifies the loopback setting for performance testing.

Valid values are:

  • True specifies that the Diameter Gateway instance does not send the credit-control request to ECE. Instead, the Diameter Gateway instance returns the success result code to the network element.

  • False specifies that the Diameter Gateway instance sends the credit-control request to ECE.

ioThreadPoolSize

"10"

The number of threads used by the network I/O thread pool.

Valid values are greater than zero and up to any number the system resources allow.

responseTimeout

"10"

The maximum duration in seconds that the Diameter Gateway instance waits for a response from the Diameter client. If the Diameter Gateway instance does not receive a response from the Diameter client within the specified duration, the Diameter Gateway instance stops waiting for a response and removes the notification from the JMS queue.

Valid values are greater than zero and up to any number the system resources allow.

requestProcessorThreadPoolSize

"10"

The number of threads used by the request-processor thread pool.

The request-processor thread pool is a Diameter Gateway thread pool that is dedicated to processing Diameter requests handed off to it from the I/O thread pool.

Valid values are greater than zero and up to any number the system resources allow.

requestProcessorBatchSize

"10"

The batch size of the Diameter requests handed off by the network I/O thread pool to the request-processor thread pool.

Valid values are greater than zero and up to any number the system resources allow.

watchDogInterval

"30"

The duration in seconds that the Diameter Gateway instance waits before it issues a Device-Watchdog-Request message (DWR).

notificationThreadPoolSize

"10"

The number of threads used by the Diameter Gateway instance to process notification messages.

Valid values are greater than zero and up to any number the system resources allow. Tune this value to the expected workload in the deployed environment.

maxNotificationCommitSize

"100"

The maximum number of dequeued notification messages from the JMS topic that can remain uncommitted.

If the number of dequeued notification messages from the JMS topic exceeds this number, the Diameter Gateway instance stops reading messages until the read messages are committed.

ccFailover

"FAILOVER_SUPPORTED"

Indicates if the Diameter Gateway instance is operating in a cluster that supports failover.

Valid values are:

  • "FAILOVER_SUPPORTED"

  • "FAILOVER_NOT_SUPPORTED"

The value set here is the value the Diameter Gateway instance sends for the CC-Session-Failover AVP in all credit-control answers (CCAs) that the instance produces.

For more information, see Diameter Credit-Control Application standard at:

https://tools.ietf.org/html/rfc4006#section-8.4

creditControlFailureHandling

"RETRY_AND_TERMINATE"

Indicates how the Diameter client should proceed if a CCA is not received prior to the Tx timeout.

Valid values are:

  • "TERMINATE"

  • "CONTINUE"

  • "RETRY_AND_TERMINATE"

The value set here is the value the Diameter Gateway instance sends for the Credit-Control-Failure-Handling AVP in all CCAs that the instance produces.

For more information, see Diameter Credit-Control Application standard at:

https://tools.ietf.org/html/rfc4006#section-8.14

directDebitingFailureHandling

"TERMINATE_OR_BUFFER"

Indicates how the Diameter client should proceed if a Direct Debit CCA is not received prior to the Tx timeout.

Valid values are:

  • "TERMINATE_OR_BUFFER"

  • "CONTINUE"

The value set here is the value the Diameter Gateway instance sends for the Direct-Debiting-Failure-Handling AVP in all credit-control answers (CCAs) that it produces.

For more information, see Diameter Credit-Control Application standard at:

https://tools.ietf.org/html/rfc4006#section-8.15

Adding RADIUS Gateway Nodes

During ECE installation, if you specify that RADIUS Gateway must be started when ECE is started, the ECE installer adds a single RADIUS Gateway node (radiusGateway1) to your topology file).

When adding RADIUS Gateway nodes:

  • In a production system, use two RADIUS Gateway nodes to allow for failover and additional nodes as needed to handle the expected throughput for your system.

  • For a development system, the minimum configuration is two RADIUS Gateway nodes to allow for failover.

To add RADIUS Gateway nodes:

  1. Log on to the driver machine.

  2. Go to the ECE_home/bin directory.

  3. Start the Elastic Charging Controller:

    ./ecc
  4. Access the ECE configuration MBeans in a JMX editor, such as JConsole. See "Accessing ECE Configuration MBeans".

  5. Expand the ECE Configuration node.

  6. Expand charging.radiusGatewayConfigurations.

  7. Expand Operations.

  8. Select addRadiusGatewayConfiguration.

  9. In the method's name field, enter a name for the RADIUS Gateway node.

  10. Click the addRadiusGatewayConfiguration button.

    You have created a RADIUS Gateway node.

  11. Open the ECE_home/config/eceTopology.conf file.

  12. Add a row for the RADIUS Gateway node instance.

  13. For that row, enter the following information:

    • Name of the JVM process for the node instance.

      Enter the name used when the node instance was created in the JMX editor.

    • Role of the JVM process for the node instance.

      Enter the role radiusGateway.

    • Host name of the physical server machine on which the node resides.

    • JVM tuning file that contains the tuning profile for the node.

  14. Save the file.

Configuring RADIUS Gateway Nodes

You must configure each RADIUS Gateway node to communicate with your network and to perform optimally.

To configure RADIUS Gateway nodes:

  1. Access the ECE configuration MBeans in a JMX editor, such as JConsole. See "Accessing ECE Configuration MBeans".

  2. Expand the ECE Configuration node.

  3. Expand charging.radiusGatewayConfigurations.Instance_Name, where Instance_Name is the name of the instance to configure.

  4. Expand Attributes.

  5. Specify values for all the attributes required to configure the instance.

    See Table 73-2 for attribute descriptions and default values.

  6. Change directory to the ECE_home/bin directory.

  7. Start the Elastic Charging Controller:

    ./ecc
  8. Do one of the following:

    • If the RADIUS Gateway instance is not running, start it.

      The instance reads its configuration information by name at startup.

    • If the RADIUS Gateway instance is running, stop and restart it.

Table 73-2 RADIUS Gateway Node Configuration Attributes and Values

Attribute Name Default Value Description

name

"radiusGateway1"

The name of the RADIUS Gateway instance.

Name RADIUS Gateway node instances consistently and uniquely (for example, radiusGateway1, radiusGateway2, and so on).

If you change the name of an existing instance, you must update the name in the ECE_home/config/eceTopology.conf file.

wallet

"opt/wallet"

The path to the Oracle wallet file containing the SSL trusted certificates and the BRM root key for RADIUS Gateway. When RADIUS Gateway is started, the BRM root key in the Oracle wallet file is stored in memory.

queueSize

"8"

The number of incoming requests that can be simultaneously processed by the RADIUS server.

avpName

"Service-Type"

The name of the attribute value pair (AVP) that is used to determine the service type during authentication. This is used in conjunction with vendorId.

vendorId

"0"

The vendor ID of the AVP that you configured to determine the service type. This is used in conjunction with avpName.

enableRetransmissionChecks

"true"

Enables or disables duplicate packet detection (enabled by default). RADIUS Gateway uses this feature to identify duplicate requests from RADIUS clients by validating them against the requests stored in the ECE cache.

Note: You must restart RADIUS Gateway after enabling or disabling the duplicate packet detection feature.

timeToLive

"30000"

The expiration time (in milliseconds) for the RADIUS requests stored in the ECE cache.

radiusTrafficPort

authorization port= "1812"

accounting port= "1813"

The number assigned to the port on which RADIUS Gateway listens. Add one radiusTrafficPort entry for each port on which you want RADIUS Gateway to listen.

ioThreadPoolSize

"16"

The number of threads that determines the maximum number of simultaneous processes that RADIUS Gateway can handle. You can increase the number of threads to increase the server performance.

Many factors impact the number of threads required, such as the cache size of each CPU, memory size, and swap size. Systems can handle as many as eight threads per CPU. On production systems, set these values higher.

sharedSecret

"e59VPnxr1o5+FGW97w/aMA=="

The common password shared between RADIUS Gateway and Network Access Server (NAS). It is used by the RADIUS protocol for security. Each RADIUS Gateway instance must have a unique password in encrypted format.

noOfChallenges

"1"

The maximum number of challenges that can be sent to RADIUS clients when Challenge-Handshake Authentication Protocol (CHAP) is used for authentication. A random number within this value is chosen during authentication to carry out the number of challenges for a given authentication session.

If the password is authenticated successfully, the challenge process begins. If any of the challenge responses fail in authentication, an Access-Reject is sent. Upon all successful authentication, an Access-Accept message is sent.

id

"21", "4", and "5"

The unique identifier of the Extensible Authentication Protocol (EAP) type used for authentication.

name

"TTLS" and "MD5"

The EAP type used for authentication. The following types are supported: TTLS and MD5.

priority

"1", "2", and "3"

The priority set for the EAP type. 1 is the highest priority.