THE DAILY DIGEST

The daily edition.

Essential reading from Rocket Enterprise. Straight to the source.

Archived edition
DAILY EDITION1 story· 3 min read
IN FOCUS

One PAC SOR Can—and Usually Should—Have Multiple Redis Endpoints

Enterprise Server 12.0 permits one logical SOR per PAC, but that SOR can define multiple Redis Sentinel or Cluster endpoints. High availability also depends on client retries, TLS material on every member region, and reinstalling the PAC after configuration changes. [1] [2] [3]

Read the full briefing

One PAC SOR Can—and Usually Should—Have Multiple Redis Endpoints

Scope: Rocket Enterprise Developer / Enterprise Server 12.0 for Eclipse on UNIX, PACs using Redis Sentinel or Redis Cluster as the PAC Scale-Out Repository (PSOR).

A Performance and Availability Cluster operates as one logical entity, but its shared system and configuration state depends on a PSOR. Rocket allows exactly one logical SOR per PAC; that does not mean one Redis endpoint. The SOR definition can contain multiple Redis Sentinel or Cluster connection paths, which Rocket explicitly says can help support high availability. Scale-Out Repositories documents each path as a server name and port and lets administrators add further nodes with the + control.

The ESCWA configuration sequence is:

  1. Go to Operation > SORs > +Add.
  2. Name the PSOR, select Redis, and enter one or more host:port connection paths.
  3. Go to Operation > Groups > PACs, create the PAC, and select that PSOR.
  4. Install the PAC definition to its member regions.

The full workflow is in Configuring PACs and SORs. That page adds two operational nuances. Rocket recommends at least three regions, with each on a Directory Server hosted on separate hardware, to reduce single points of failure. Also, whenever the PAC, any SOR, or any SOR Model changes, reinstall the PAC so every member region receives synchronized configuration.

Connection redundancy and retry behavior are different layers. Configuring Redis Cluster supports an MFREDIS_CONFIG file containing:

RD_RETRY_INTERVAL=2000
RD_RETRY_ATTEMPTS=1

Those are the documented defaults: wait 2,000 milliseconds before retrying, and make one attempt to perform the last failed request. Multiple endpoints help the client discover or reach the Redis service; retry settings govern what happens after a request fails. They should not be treated as interchangeable availability controls.

TLS adds a region-wide prerequisite. When the Redis SOR is TLS-enabled, every Enterprise Server region in the PAC must have the Certificate Authority, certificate, and private-key file paths configured in Advanced Region Properties. Defining TLS only on the SOR connection is therefore incomplete.

Finally, PAC support itself requires a NoSQL SOR to maintain PAC integrity. Rocket certifies Redis and Oracle Coherence, and identifies Redis Cluster as the distributed Redis option designed for performance, scalability, and availability in Performance Availability Clusters (PACs) Requirements.

Takeaway: Keep one logical PSOR per PAC, but configure multiple Redis Sentinel or Cluster endpoints, deliberate retry values, TLS material on every region, and reinstall the PAC after configuration changes.

Rocket Enterprise Developer / Enterprise Server 12.0 for Eclipse (UNIX); PAC with Redis SOR
Documentation references
That’s the briefing.You’ve reached the end of this edition.
More editions

From the archive

View all
Nov 2

BMS TYPE Controls Whether You Build a Map, a DSECT, or Both

Nov 2

MLDAP ESM Caching: Two Parameters Turn It On, Rule-Set Caching Needs an Explicit Opt-In, and Updates Flush It

Nov 2

DBFH Recovery Is an Inspection-First Operation