The daily edition.

Scope and Architectural Overview

This article covers Scale-Out Repository (SOR) configuration and operational mechanics in Rocket Enterprise Developer / Enterprise Server 12.0 for Linux/UNIX.

In cloud, container, and multi-host deployments, a Performance and Availability Cluster (PAC) allows multiple enterprise server regions to operate as a single, horizontally scalable cluster. To ensure that transactions executing on any region access consistent data, regions must decouple state from local instances. Rather than relying on local disk queues or inter-region networking, a PAC externalizes shared system and application data to an external NoSQL data store known as a Scale-Out Repository (SOR).

Within this architecture, Redis is certified by Rocket Software as an enterprise-grade SOR backend, supporting sub-millisecond memory access, clustering, automated failover, and TLS encryption.

The Two-Tier Data Separation: PSOR vs. Application SOR

A PAC categorizes cluster state into two distinct repository tiers documented in PAC Scale-Out Repository (PSOR) and PAC and SOR Environment Variables:

1. PAC Scale-Out Repository (PSOR):
   • Every PAC requires exactly one mandatory PSOR.
   • It stores shared system configuration, active region states, and cluster coordination metadata required by all member regions.
   • In configuration syntax, the PSOR is explicitly designated by appending the TMP flag (##TMP#).
2. User Data SORs:
   • Up to nine distinct SOR instances can be configured per cluster (indexed from ES_SCALE_OUT_REPOS_1 through ES_SCALE_OUT_REPOS_9).
   • Secondary SORs are dedicated to holding application data, allowing administrators to partition workload traffic across different Redis instances based on queue volume or latency profiles.

Selective Queue Routing via SOR Models

Enterprise Server does not blindly broadcast all queue traffic to Redis. Instead, administrators define granular SOR Models directly in the SOR connection string or through Enterprise Server Common Web Administration (ESCWA).

A model definition matches queue names using pattern-matching rules:

=<ResourceType>=<model>[:<model>][#<ResourceType>=<model>[:<model>]]

• ResourceType: Supports Temporary Storage (TS, names up to 16 bytes) and Transient Data (TD, names up to 4 characters).
• Wildcard Syntax:
  • *: Matches any sequence of characters (e.g., TS=A* routes all TSQs beginning with A).
  • +: Matches exactly one character. Missing trailing characters are automatically padded with + (e.g., specifying TD=A expands to A+++).
  • :: Delimits multiple pattern expressions within the same resource type.
  • x'<hex>': Matches binary hexadecimal prefixes. The character byte 2B acts as a generic wildcard (e.g., x'AA2BAA' matches x'AAAAAA', x'AABBAA', and x'AACCAA').

Any TSQ or TDQ whose name does not match an active SOR Model rule continues to be stored locally on its originating enterprise server region instance.

Configuration Workflow and Environment Variables

Every enterprise server region joining a PAC must declare its cluster membership and identical SOR definitions:

# Define cluster membership
export ES_PAC=MYPAC

# Define the mandatory PSOR using Redis
export ES_SCALE_OUT_REPOS_1=RedisLocal=redis,127.0.0.1:12345##TMP#TD=AC*:TD*:RTDQ:SOR1#TS=A*:B+A:NRQSOR1

# Optional secondary SOR for additional application queues
export ES_SCALE_OUT_REPOS_2=RedisLocal2=redis,127.0.0.1:67891##TD=ATD#TS=T*R2:R*R2

In the primary definition above:

• RedisLocal: Name identifying the Redis master.
• redis: Denotes the SOR engine type (use redis_TLS for encrypted transport).
• 127.0.0.1:12345: Target Redis IP address and port.
• ##TMP#: Flags this repository as the mandatory PSOR.
• TD=...#TS=...: Route models directing specific transient and temporary storage queues to this Redis repository.

High Availability with Redis Sentinel

In enterprise production deployments, Redis resilience is achieved using Redis Sentinel, detailed in Redis Requirements and Configuration as a Scale-Out Repository.

The deployment architecture requires:

1. One Redis master node (e.g., on port 6741).
2. One or more Redis replicas (configured with replicaof <master-ip> <master-port>).
3. An odd number of Redis Sentinels (typically three, e.g., on ports 6800, 6801, 6802) to form a Byzantine fault-tolerant quorum.

In the PAC configuration, the sorName must match the uppercase Redis master name (MY_MASTER) defined in sentinel.conf, followed by all Sentinel addresses:

export ES_SCALE_OUT_REPOS_1=MY_MASTER=redis,127.0.0.1:6800,127.0.0.1:6801,127.0.0.1:6802##TMP

Enterprise Server connects to the Sentinels to query the current active master and automatically updates its client connection pool when Sentinel elects a new master during a failover event.

Client Communication and Security Controls

1. Low-Level Tuning via MFREDIS_CONFIG

Communication between the Enterprise Server runtime and Redis can be tuned by pointing the MFREDIS_CONFIG environment variable to a configuration file containing:

• RD_KEEPALIVE_INTERVAL: TCP keepalive frequency in seconds (default is 15).
• RD_RETRY_INTERVAL: Delay in milliseconds before retrying a failed Redis operation (default is 2000 ms).
• RD_RETRY_ATTEMPTS: Maximum retry count before raising an operational failure (default is 1).
• RD_LUA_LOG: Controls server-side Lua execution logging (ON or OFF, default OFF; requires Redis --log-level warning or higher).

2. TLS Encryption

When transmitting sensitive data across untrusted networks, set sorType to redis_TLS:

export ES_SCALE_OUT_REPOS_1=MySOR=redis_TLS,127.0.0.1:6379##TMP#

Each member region must then specify the certificate authority, client certificate, and private key using ES_RTLS_CERT_AUTH_FILEPATH, ES_RTLS_CERT_FILEPATH, and ES_RTLS_PRIVATE_KEY_FILEPATH (or through the Advanced Region Properties page in ESCWA).

Important Prerequisites and Operational Nuances

• Non-Recoverable Queue Restriction: A Scale-Out Repository is architecturally limited to storing non-recoverable TS and TD queues. Recoverable queues cannot be routed to an SOR because their commit, backout, and syncpoint semantics require traditional transactional logging managed through local recoverable resource managers.
• PSOR Cardinality and Homogeneity: Every region within a PAC must define exactly one PSOR (##TMP#), and every member region must point to the identical PSOR backend. Attempting to start regions with differing PSOR definitions causes cluster split-brain conditions.
• Case Sensitivity in Sentinel Master Identification: When using Redis Sentinel, the sorName parameter must strictly match the uppercase name configured in the Sentinel monitor directives (sentinel monitor MY_MASTER ...).

Documentation Takeaway

In Rocket Enterprise Server PAC environments, Redis acts as a certified Scale-Out Repository that externalizes cluster state through a single mandatory PSOR for system metadata and up to eight secondary SORs for non-recoverable TS/TD queues; queue routing is determined by SOR Model patterns, high availability is maintained by coupling Sentinel quorums with uppercase master names in the connection string, and client resilience is managed through MFREDIS_CONFIG.