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 and RKE2 Kafka client readiness. |
spoke-dr | Workload standby | ODF compact LVMS topology, OSSM 3 healthy, RHOAI operator installed without user AI workloads. | Define whether standby becomes app-ready hot mirror. |
Model
Operational boundaries
Workload placement
spoke-dc is active. spoke-dr is standby with platform services, not currently a full app mirror. That distinction matters before any application DR statement is made.
Traffic and platform
OSSM 3 is installed on both spokes. Workload routing and telemetry remain app onboarding work, not platform installation work.
Data dependencies
AMQ/Kafka has been retired from OCP spokes. Future app Kafka consumption should use RKE2 Kafka once DNS and app-specific credentials are ready.