Management ownership
hub-dc is the active hub. hub-dr should remain passive until a controlled activation drill. The recorded placement model no longer treats hub-dr as a managed cluster on hub-dc.
Fleet topology
Cluster roles and placement model
The OCP fleet is intentionally small and role-specific: one active hub, one passive restore hub, one active workload cluster, and one standby workload cluster.
DC
hub-dcactive management hub
spoke-dcactive workload cluster
ACM placement, GitOps, OADP, service mesh, app onboarding
DR
hub-drpassive management restore hub
spoke-drworkload standby
Cluster inventory
Role matrix
| Cluster | Role | Current posture | Primary concerns |
|---|---|---|---|
hub-dc | Active management hub | ACM/MCE, OADP, GitOps, RHACS, LVMS retained. | ACM backup freshness before drill. |
hub-dr | Passive restore hub | Restore-ready hub with local GitOps app and no active restore ownership. | ACM/MCE image mirror or pre-pull readiness. |
spoke-dc | Active workload cluster | ODF on localblock, OSSM 3 healthy, no demo app workloads currently present. | App onboarding, mesh opt-in, and workload policy readiness. |
spoke-dr | Platform standby | ODF compact LVMS topology, OSSM 3 healthy, RHOAI operator installed without user AI workloads. | Decision 2026-05-07: platform standby. App workloads activate via runbook-driven DR drill, not active-active mirroring. |
Model
Operational boundaries
Workload placement
spoke-dc is active. spoke-dr is platform standby (decision 2026-05-07): platform services stay ready but no application workloads run in normal operation. App-side DR is a deliberate runbook activation, not a hot mirror.
Traffic and platform
OSSM 3 is installed on both spokes. Workload routing and telemetry remain app onboarding work, not platform installation work.
External boundaries
External systems are documented here only when they directly support OpenShift operations, such as external Vault for secrets, MinIO for backup/object storage, GitOps source control, identity, or edge ingress.