High Availability, Resiliency, Shared Storage, Blob Store Groups, Node Coordination, and Failure Recovery: Configuration, Design Choices, and Tradeoffs

1. Active-active application tier, single-writer database contract

Nexus application nodes can all accept client traffic, but the database is not an active-active set of independent writers. A supported PostgreSQL HA service may have replicas and automatic failover, yet Nexus still connects through a coherent writable endpoint. This preserves transactional ordering for repository/security/configuration metadata.

2. Local versus shared blob storage

The storage layer should be close enough to the application/database to meet latency and throughput requirements. “Shared” is not equivalent to “fast enough.”

3. Multi-AZ versus multi-region

A production cloud HA design can distribute application nodes across multiple availability zones/failure domains within one region, with a managed multi-AZ PostgreSQL service and regional shared object storage. Current Sonatype HA requirements do not support stretching one HA cluster across regions. Cross-region continuity belongs to DR/federation patterns.

4. Availability versus consistency

Artifact repositories are systems of record. Serving stale or divergent metadata merely to stay “green” can be worse than a short controlled outage. When the shared database or blob layer loses correctness, the safe response may be to stop writes/read-only/fail closed rather than let nodes invent divergent state.

5. Sticky sessions: do not cargo-cult them

Normal application HA should not assume session persistence unless the current deployment behavior requires it. Sonatype’s current rolling-upgrade guidance specifically requires sticky sessions on the load balancer during zero-downtime upgrades because UI behavior can differ while nodes run temporarily in mixed versions. That is a documented special case, not proof that every package-client request needs affinity forever.

6. Group blob stores: capacity tool, not availability magic

Group blob stores are Pro-only. Two current fill policies are important:

• Round Robin: writes alternate across members; it does not choose the “least loaded” member and does not mirror the same blob to every member.
• Write to First: writes target the first writable member, useful for controlled storage migration/capacity redirection.

Current UI health marks a group unhealthy when any member is unreachable. A group can be useful operationally, but you must separately reason about member failure, content placement, backup, and recovery.

7. Blob redundancy versus backup

flowchart LR
N[Nexus cluster] --> S[Shared blob service]
S --> R[Provider redundancy / replicas]
N --> DB[(PostgreSQL HA)]
DB --> DR[DB backup / PITR]
S --> BK[Blob backup / versioned recovery copy]
DEL[Accidental deletion or corruption] --> S
DEL --> DB
R -. may replicate bad change .-> X[Same logical damage]
BK --> REC[Point-in-time recovery]
DR --> REC

Infrastructure redundancy can faithfully replicate a bad delete. Recovery history must be independent enough to return to a known-good consistency point.

8. Cost versus RTO

Adding failure domains reduces some outage risks but increases infrastructure, testing, operational, and database/storage costs. Define service objectives first:

9. Worked decision scenario

Team: 4,000 developers, release builds must keep resolving artifacts through one application-node/AZ failure; a 5-minute DB failover is acceptable; accidental deletion must be recoverable to the prior 30-minute checkpoint.

Reasoned design: Pro HA application nodes across at least two failure domains in one region; managed supported PostgreSQL HA endpoint; shared regional object storage; redundant load-balancer service; independent DB/blob backup aligned to 30-minute RPO. A group blob store is optional and only added for a concrete capacity/migration requirement.

10. Configuration ownership table

Knowledge check

Summary and next step

HA design is a controlled balance: active Nexus nodes improve application availability, but PostgreSQL keeps one coherent writer contract, blobs remain shared state, and redundancy cannot replace backup.

Lesson 4 diagnoses the most dangerous ways an HA design can look redundant while still being incorrect or fragile.

Official references and version notes

• Sonatype: High Availability Deployment — current Pro-only clustered application model.
• Sonatype: Requirements for High Availability — same-version nodes, single-region scope, load balancer, shared blob storage, and external PostgreSQL requirements.
• Sonatype: Manual High Availability Deployment — clustered mode, shared storage, and per-node operational state.
• Sonatype: Validating Your HA Deployment — node status, system information, and per-node support evidence.
• Sonatype: Status API — read/writable status endpoints and their monitoring limitations.
• Sonatype: Nodes API — Pro cluster-node inventory and node identities.
• Sonatype: System Requirements — Java 21, PostgreSQL guidance, supported providers, and the explicit pgpool/load-balancing restriction.
• Sonatype: Blob Stores — shared/object storage behavior, health indicators, and group blob-store semantics.
• Sonatype: Storage Planning — group blob stores, storage layout tradeoffs, and performance implications.
• Sonatype: Nexus Repository Professional Features — HA, cloud blob stores, and group blob-store licensing boundaries.
• Sonatype: Rolling Upgrades in High Availability — mixed-version limits, sticky-session requirement during rolling upgrades, schema-finalization behavior, and restore-based rollback after finalization.
• Sonatype: Prepare a Backup — recovery-set consistency across database/configuration and blob content.
• Sonatype: Cross-Region Disaster Recovery — a separate DR pattern rather than an extension of a single-region HA cluster.