MATRIXX Engine Topology
The main components of a MATRIXX Engine include the processing, publishing, and checkpointing servers and the engine shared storage. The servers can be physical servers or virtualized software servers.
Server Enclosure
A hardware server enclosure is the chassis that handles the non-computing services for MATRIXX Engine, such as power supplies, cooling fans, Ethernet interconnect fabrics, and administration tools. It has servers, network connections, switches, and load balancers. The server enclosure is identified by an alpha-numeric ID that is unique to the data site.
MATRIXX Engine Servers
Each MATRIXX Engine utilizes Linux servers at its core. Each server has a copy of the MATRIXX software.
Each server has its own Solid State Drive (SSD) for transaction logging. This isolates the workload of each server from that of other servers. The ratio of logical servers to physical servers is one-to-one for high availability scenarios.
Parallel-MATRIXX Clusters
The MATRIXX Engine processing server and publishing server sets are configured to work seamlessly together in Parallel-MATRIXX™ clusters. Clustering is an industry-standard approach for scalability and high availability of mission critical, transactional processing. The Parallel-MATRIXX technology enables each server in the cluster to run an identical copy of the software, including business logic and a copy of the in-memory database data. In traditional clusters, servers must negotiate for ownership of specific pieces of data, and only one server at a time can have write access to the data. In Parallel-MATRIXX clusters, the in-memory databases in the cluster are all transactionally synchronized, so they are atomic clones of each other. When the business logic in one server updates a piece of data, it is updated in the databases on every server simultaneously. The Parallel-MATRIXX technology makes this possible and every server is free to access and update any data in the database at any time, without having to lock or negotiate for ownership of the data.
In addition, if a server fails for any reason, it can be removed temporarily from the cluster. It does not require a heavyweight fail-over process to migrate ownership of a server data because the other servers already have the same data. Once the server is repaired or replaced, it synchronizes with the other servers and rejoins the cluster. Servers can also be dynamically removed and added to MATRIXX Engines for online maintenance and hardware upgrades.
Shared Storage
MATRIXX Engines support full ACID (atomicity, consistency, isolation, durability)-compliant transaction processing, including complete synchronous replication of all transactions across the active processing servers in the cluster and duplicate asynchronous logging of all transactions to durable disks. Transactions from each processing server are replicated to all other processing servers in the cluster and logged to the local SSDs. In addition, a publishing server logs the transactions from the processing servers to the shared storage. The redundancy of the logs helps ensure that all events processed are successfully published and that the transaction log files can survive the failure of any server.
The storage subsystem has two sets of redundant network switches that connect to off-node systems so data can be integrated with enterprise systems and saved off-engine for disaster recovery purposes.
Event Streaming
For information about the MATRIXX Event Streaming hardware topology, see the discussion about implementing Event Streaming in MATRIXX Event Streaming.