Engine Configuration
You can use the configuration parameters in create_config.py to identify the domain and customer sub-domains in your configuration, including identifying the engines, clusters, servers, IP addresses, multi-cast information, and network interfaces.
Engine Configuration Parameters lists information required to configure an engine.
| Parameter | Description | Default Value |
|---|---|---|
| Domain ID | A numeric ID for the domain of your MATRIXX environment. A domain provides complete pricing and configuration separation from other potential MATRIXX environments in their own domains, such as in multi-tenancy or testing situations. create_config.info question: What is your domain ID? A domain is identified by a positive integer from 1-64. |
1 |
| Domain Description | One or two words describing the
domain. create_config.info question: Domain 1:What is the description for this domain? |
Domain 1 |
| Sub-Domain IDs | A numeric ID for each sub-domain in your MATRIXX environment. A customer sub-domain is a subscriber-base segment (or shard) that is processed by a given engine chain. Customer sub-domains are implemented for engine scalability. A customer sub-domain is a single logical entity that represents the associated data definitions and pricing that the MATRIXX Engine uses to perform online charging system (OCS) processing for a set of subscribers. Note: Each engine must have at least one customer sub-domain
specified (even if you do not implement multiple customer
sub-domains in your MATRIXX environment).
create_config.info question: Domain 1:What are your sub-domain IDs? A customer sub-domain is identified by a positive integer from 1–64. |
1 |
| Sub-Domain Description | One or two words describing the sub-domain. This question is
asked for each sub-domain identified.
create_config.info question: Domain 1:SubDomain 1:What is the description for this sub-domain? |
SubDomain 1 |
| MATRIXX Engine IDs | A numeric ID for each
engine in the sub-domain, listed with semi-colons. This question is
asked when configuring each sub-domain. Each engine must have a
unique ID across the entire domain, not just across a sub-domain.
create_config.info question: Domain 1:SubDomain 1: What are the engine IDs for this sub-domain? |
1 Enter 1;2 for a sub-domain containing two engines. |
| MATRIXX Engine Description | One or two words
describing the first engine identified, which resides in the Main
site. If the installation has multiple engines, the script prompts
the user for this information again for each engine, after
configuring the rest of the information for the first engine. create_config.info question: Engine 1:What is the description for this engine? |
Engine 1 |
| MATRIXX Engine Site ID | The site IDs to assign to the Engine ID.
create_config.info question: Engine 1:What is the site ID for this engine? |
Main |
| Cluster IDs | A numeric ID for each
cluster that is unique to an engine. Each engine must contain one
processing cluster and one publishing cluster. create_config.info question: Engine 1:What are your cluster IDs? |
1 |
| Cluster Type | The operation
performed by the cluster: processing or publishing. create_config.info question: Engine 1:Cluster 1:What is the type of this cluster? |
processing |
| External Diameter Virtual Service Address | The IP address and port for the Traffic Routing Agent virtual server handling Diameter packets to and from the engine.
create_config.info question: Engine 1:Cluster 1:What is the external diameter virtual service address used on this cluster? |
127.0.0.1:3868 |
| MDC Gateway Virtual Service Address | The IP address and port for the Traffic Routing Agent virtual server handling customer management traffic. This value
must match the value configured for the Traffic Routing Agent. create_config.info question: Engine 1:Cluster 1:What is the mdc gateway virtual service address used on this cluster? |
127.0.0.1:4060 |
| Internal MDC Virtual Service Address | The IP address and port for the Traffic Routing Agent virtual server handling MDC-based replay traffic (used in
disaster-recovery engine chain configurations). This value must
match the value configured for the Traffic Routing Agent. This virtual server routes replay messages that come from the
MDC Gateway. create_config.info question: Engine 1:Cluster 1: What is the internal mdc virtual service address used on this cluster? |
127.0.0.1:4061 |
| Cluster: Logical Server IDs | A relative number to identify the total
number of logical servers in the first cluster. For example, if this
is a processing cluster that has 3 servers, enter, "1;2;3". Do not
accept the default (1), which results in only one
server in the cluster. create_config.info question: Engine 1:Cluster 1: What are your logical blade IDs? |
1 |
| Cluster: Server IDs | Each logical server must be mapped to a
server ID, defined in the engine configuration section. The script
will list the possible values entered and the user must enter one
for each logical server. create_config.info question: Engine 1:Cluster 1:LogicalBlade 1:What is the server ID? |
1;2;3... |
| Publishing Server(s): Logical server VIP interface | Each logical publishing server must specify the interface for the publishing cluster
VIP to use. create_config.info question: Engine 2:Cluster 2:LogicalBlade 1:What interface do you want to use for the publishing VIP blade publishing interface? |
eth0 |
| Publishing Server(s): VIP address | Each logical publishing server must specify the address for the publishing cluster VIP
to use. create_config.info question: Engine 1:Cluster 2: What address do you want to use for the publishing VIP blade? |
127.0.0.1 |
| Shared Memory Setting | Each logical publishing server requires shared memory for its
databases. create_config.info question: Engine 2:Cluster 2:LogicalBlade 1:What is the shared memory size in MB on publishing server to use? |
2500 |
| Publishing Cluster: Logical Server Address | You must specify a VIP address for the publishing server cluster. Create this VIP address (VipData1) for nfs-mounting the shared storage from procesing and checkpointing clusters. You
can run the configure_vip.py -C vip script on engine and server servers to confirm that the VIP address is not already being used.create_config.info question: Engine 1:Cluster 2:LogicalBlade 1:What address do you want to use for the publishing VIP blade? |
N/A |
| Port Numbers | For each logical server in a cluster, the
script prompts the user to set port numbers for communications
across the cluster. Accepting the defaults is recommended for all
ports except the Cluster Management CLI, which is dependent on the
Traffic Routing Agent configuration value. The recommended value is 4800, which is NOT
the default value. create_config.info question: Do you want to specify port numbers on a global basis (y/n)? |
For the list of ports that need to be set, see the discussion about port configuration. |
| Peer Connect Timeout | For each processing cluster, specify the peer connect timeout value. This is the
amount of time to wait when one processing server cannot communicate
with the other processing server and determines it has failed.
create_config.info question: What is the peer connect timeout value (in seconds) in dual blade mode do you want to use? |
300 |
| Cluster Management Virtual Service Address | Each cluster requires
a cluster control VS for routing Cluster Manager monitoring and control traffic to the appropriate node. The
answer must be the address of a cluster management virtual server in
the VIP_address:port format. Cluster Manager validates the answer to this question. create_config.info question: Engine 1:Cluster 1:What is the cluster management virtual service address used on this cluster? |
This value is dependent on site configuration. |
| Shared Directory Location | The log directory location. All engines can share the same
directory or each engine can specify a different engine.
create_config.info question: Do you want to use the same directory for archiving transaction log files and checkpoints on all Engines (y/n)? If you answer yes (y) to specify the same directory for all engines, you must answer the following location to identify the directory. create_config.info question: What directory do you want to use for archiving transaction log files and checkpoints? If you answer no (n) to specify a different directory for each engine, you must answer the following question for each engine to identify the directory (where "e" specifies the engine number). create_config.info question: Engine e:What directory do you want to use for archiving transaction log files and checkpoints? |
y |
| Virtual Servers | The processing and publishing clusters require the following
virtual servers (VS):
|
No Default Values |
| Load Balancer IDs | An alphanumeric ID that is unique to the load balancer. Two load
balancer IDs are required: LB1 for the processing cluster, and
LB1_PUB for the publishing cluster. create_config.info question: Site HP6_sd1:W What are your load balancer IDs? |
LB1;LB_PUB |
| HTTP Price Controller Port | The port used by the HTTP Price Controller REST service. This service must be running before you can load a pricing compilation onto an engine using My MATRIXX.. create_config.info question: What port number do you want to use for the HTTP Price Controller? |
4044 |
Standby Engine Publishing Cluster Restart
You can use the pub_restart_for_last_standby_engine_enabled SED line to avoid a standby engine processing cluster shutdown when the publishing cluster is down and the standby engine is the last engine in a chain. For example, in a two-engine chain, (E1–>E2), the second (standby) engine (E2) processing cluster does not shut down when the publishing cluster goes down.
Similarly, pub_restart_for_last_standby_engine_disabled disables this feature.