MATRIXX Domain Architecture
A customer domain is a set of subscribers that co-exist with a single homogeneous pricing configuration. It provides pricing and configuration separation from other potential MATRIXX environments in their own domains, such as in multi-tenancy or testing situations. You can build a customer domain upon one or more sub-domains. The simplest MATRIXX Engine deployment is a single engine chain implementing one customer domain (one customer sub-domain).
MATRIXX Engines
A MATRIXX Engine environment can include an active, a standby, and (optionally) a second standby engine. A MATRIXX Engine must have at least one backup engine, called the standby engine or high availability (HA) peer. A MATRIXX Engine and its configured standby peers together form an engine chain, which work together for disaster-recovery purposes. If one engine fails, one of the standby(s) takes over.
Figure 1 shows an overview of the major MATRIXX components. This diagram does not include the optional event streaming feature. For a MATRIXX architecture diagram that includes event streaming, see the discussion about event streaming overview in MATRIXX Event Streaming.
Different engine chains can be set up to run subsets of your subscriber base if you implement multiple customer sub-domains. In this scenario, each engine chain represents a customer sub-domain and is associated with a specific customer sub-domain ID. A customer sub-domain is a physical separation of subscribers, for scalability, into separate engine chains where all subscribers belong to a single customer domain and share the same homogenous pricing configuration.
When subscribers are homed in separate engine chains (in customer sub-domains), a Route Cache Controller service and a Route Cache is required in the traffic-routing layer of the MATRIXX environment. For more information, see the discussion about MATRIXX Route Cache Controller.
MATRIXX Engine Architecture
Figure 2 shows the core components of the MATRIXX TRA layer and engine architecture. The MATRIXX TRA layer is configured in HA pairs. It includes a TRA-RT-(SI/DR), TRA-SI, or TRA-DR HA pair to route network traffic (Diameter and SubMan MDC messages, for example) to the appropriate engine and its TRA-PROC. It can also include a SIGTRAN Network Enabler to accept and route CAP traffic. The processing servers in the engine perform event-transaction processing on the type of traffic received from the TRA layer, and then send their transaction logs to the publishing servers. This diagram also shows the TRA-PUB HA pair on the publishing servers. Event records generated by MATRIXX Engine can be (optionally) loaded from the publishing servers into the Event Repository.
The processing servers, publishing servers, shared storage, and event repository are described in more detail in the sections that follow.