Parent folderOpen Confluence

RWS Architecture article

ADR-005 Datacenter Services baseline and external load balancing approach

Clusters as a Service needs a minimal, dependable baseline with limited dependencies. ADR-006 constrains the external load-balancing vendor; this ADR defines the full Datacenter Se

  1. Typeadr
  2. Statusaccepted
  3. Domainplatform
On this page
  1. Context and Problem Statement
  2. Decision Drivers
  3. Considered Options
  4. Decision Outcome
  5. Baseline Services
  6. Datacenter Services Profiles
  7. NetScaler BLX on OpenShift Virtualization (Constraints)
  8. Governance and Operations
  9. Positive Consequences
  10. Negative Consequences
  11. Next Decision Trigger
  12. Pros and Cons of the Options

Context and Problem Statement

Clusters as a Service needs a minimal, dependable baseline with limited dependencies. ADR-006 constrains the external load-balancing vendor; this ADR defines the full Datacenter Services baseline (datacenter infrastructure management, secrets, identity and access management/identity governance and administration, monitoring, Git) alongside the external load-balancing approach.

Decision Drivers

Considered Options

  1. NetScaler BLX on OpenShift Virtualization.
  2. Dedicated appliances (e.g., F5 BIG-IP).
  3. Platform-native or alternate vendor LB (e.g., Avi, NGINX).

Decision Outcome

Chosen option: NetScaler BLX on OpenShift Virtualization with the baseline services below.

This ADR defines the Clusters as a Service baseline as ABB→SBB pairs: DCIM → netbox, Secrets Management → openbao, Federated Authentication (part of smart-access) → keycloak, IGA → midpoint, Firmware → HPE OneView, Git → gitlab, Registry → Red Hat Quay, and External Load Balancing → NetScaler BLX.

Platform observability is provided via Security Operations Center implemented with the Security Operations Center (per cluster).

Baseline Services

Datacenter Services baseline aligned to vendor documentation (see Links and References).

Datacenter Services Profiles

  • Internal profile: shared control services (identity, secrets, source control, observability, and automation control plane integrations).
  • External profile: edge-facing shared services that interact with upstream/downstream networks, including the tiered Red Hat Quay registry ingress/egress path and external ADC integration.
  • Target-state design supports both profiles as per-site Clusters as a Service clusters under the same governance model.
  • Transitional rollout implementation activates both profiles in Location B only; Location A remains the ACI-scoped OpenShift AI lane and does not run Datacenter Services capabilities such as openbao, keycloak, or red-hat-quay during this phase.

NetScaler BLX on OpenShift Virtualization (Constraints)

  • Licensing must cover the BLX virtual form factor in OpenShift Virtualization.
  • High-availability model (active/standby or clustering) must be validated for OpenShift Virtualization.
  • Network attachment model must be defined (e.g., Multus, SR-IOV, or VLAN trunking).
  • Upgrade workflow for BLX images and the virtualization layer must be documented.

Governance and Operations

  • Import into Advanced Cluster Management (ACM) is mandatory before production cutover.
  • Policy, identity, and audit controls are enforced consistently across both Datacenter Services profiles.

Intent reference: topic-datacenter-rollout-intent.

Positive Consequences

Negative Consequences

  • Adds BLX operational overhead.
  • Requires clear service ownership.

Next Decision Trigger

  • Decision owner: Platform Architecture.
  • Revalidate this accepted baseline at each phase-gate review, including BLX high-availability evidence, network attachment validation, and day-2 operational ownership coverage.
  • If any baseline service enters sustained exception mode or required evidence fails, raise an amendment or superseding ADR instead of changing this ADR lifecycle state.
  • Record exceptions with owner, expiry, and mitigation path; review unresolved exceptions by 2026-03-15.

Pros and Cons of the Options

Option 1 – NetScaler BLX on OpenShift Virtualization (chosen)

  • Good: Complies with procurement constraints.
  • Bad: Adds virtualization overhead.

Option 2 – Dedicated appliances (e.g., F5 BIG-IP)

  • Good: Operational separation.
  • Bad: Diverges from consolidation.

Option 3 – Alternate vendor or platform-native LB (e.g., Avi, NGINX)

  • Good: Potentially simpler lifecycle.
  • Bad: Fails procurement constraints.

Links and References