RHOSO (Red Hat OpenStack Services on OpenShift) 18 là deployment model mới cho OpenStack — control plane chạy như OpenShift pods thay vì dedicated controller VMs, trong khi data plane (compute nodes) vẫn là bare-metal RHEL với Libvirt/KVM và OVN. Đây là architectural shift lớn nhất của Red Hat OpenStack Platform kể từ khi bỏ TripleO.

Kiến trúc

Control Plane (OpenShift Pods)             Data Plane (Bare-Metal RHEL)
┌─────────────────────────┐          ┌──────────────────────────┐
│ Keystone, Nova API,     │          │ Nova Compute + OVN agent │
│ Neutron, Glance, Cinder │          │ Libvirt/KVM hypervisor   │
│ (OpenShift pods)        │ ◄──────► │ (EDPM nodes)             │
│                         │ Ansible  │                          │
│ Galera + RabbitMQ       │ Operator │ Bare-metal performance   │
│ (K8s StatefulSets)      │          │ Native L2 networking     │
└─────────────────────────┘          └──────────────────────────┘
  • Control plane: Chạy trên RHOCP 4.18+ qua Kubernetes Operators và Custom Resources (CRDs)
  • Data plane: Quản lý bởi OpenStackDataPlane Operator dùng Ansible để provision bare-metal nodes
  • HA: Kế thừa từ OpenShift scheduling/replicas + Galera/RabbitMQ Operators + OpenShift routing
  • Network: OVN-native (không configurable sang OVS như Kolla-Ansible)
  • Upgrade: Declarative qua OLM (Operator Lifecycle Manager) — CR update thay vì imperative playbooks

So sánh với Kolla-Ansible

FeatureKolla-AnsibleRHOSO 18
Control planeDocker containers trên bare-metal/VMsOpenShift pods
OrchestrationAnsible + Docker/PodmanKubernetes Operators
Network backendOVS hoặc OVNOVN-only
ConfigurationYAML globals.ymlCustom Resources (CRDs)
HAKeepalived + HAProxyOpenShift self-healing
Upgradekolla-ansible upgradeOLM + CR updates
Kubernetes requiredKhôngRHOCP 4.18+
Vendor supportCommunity + tự supportRed Hat subscription

NIC Assignment Patterns

RHOSO 18 yêu cầu tách traffic thành 2 nhóm logical:

Control Group (bond0 — LACP 802.3ad):

  • ctlplane (native/PXE), storage (VLAN 20, MTU 9000), internalapi (VLAN 30)

Data Group (OVS bridge br-ex):

  • tenant (VLAN 40, MTU 9000 — GENEVE encapsulation), provider (VLAN 100)
  • Physical NIC enslaved to br-exmust have NO IP (nếu không → asymmetric routing)

VLAN Design cho RHOSO Lab

NetworkVLANMTUPurpose
ctlplanenative1500PXE boot, OCP cluster provisioning
storage209000Cinder iSCSI / Ceph OSD replication
internalapi301500OpenStack service API calls (internal)
tenant409000Tenant VM overlay (GENEVE encapsulation)
provider1001500External/provider network (direct L2)

MTU 9000 trên storage và tenant là mandatory — GENEVE header overhead (50 bytes) + Ceph/storage throughput yêu cầu jumbo frames end-to-end.

Production Readiness Checklist

SeverityCheck
🔴 CriticalLACP bonding trên tất cả production nodes (single NIC = SPOF)
🔴 CriticalJumbo frames (MTU 9000) end-to-end trên physical switches
🔴 CriticalOVS bridge slave NIC must have no IP
🔴 CriticalHard anti-affinity requires ≥3 compute nodes cho 3-node DB clusters
🟡 Importantetcd cluster cho Patroni DCS must run on ≥3 OCP nodes
🟡 ImportantBarbican must be deployed HA (not single-node)
🟡 ImportantMasakari requires IPMI credentials for host fencing (không chỉ ping)
🔵 DesignSeparate storage nodes nếu adopt Ceph (Phase 2)
🔵 DesignOCP cluster sizing: 3 nodes minimum; 5+ nodes for production HA

Connections

Sources