MATRIXX Engine Architecture
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, referred to as 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. Should one engine fail, one of the standby(s) take over. For information about what happens when an active engine fails, see the discussion about disaster recovery.
MATRIXX Engines
Figure 1 shows an overview of the major MATRIXX Digital Commerce components. This diagram does not include optional event streaming feature. For a MATRIXX Digital Commerce architecture diagram that includes event streaming, see the discussion about event streaming overview in Event Streaming.
The simplest MATRIXX Engine deployment is a single engine chain implementing one customer domain (one customer sub-domain). A customer domain is a set of subscribers that co-exists with a single homogenous pricing configuration.
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 blades 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 blades. This diagram also shows the TRA-PUB HA pair on the publishing blades. Event records generated by MATRIXX Engine can be (optionally) loaded from the publishing blades into the Event Repository.
The processing blades, publishing blades, shared storage, and event repository are described in more detail in the sections that follow.