Skip to content

How we are scaling Crusoe cloud using OVN interconnect approach#

Numan Siddique, Crusoe; Ketan Supanekar, Crusoe

  • Why: Crusoe is an AI-cloud operator re-architecting its OVN control plane — and it's led by Numan Siddique, OVN's longtime maintainer. A production AI-cloud at the point where the central Southbound DB becomes the bottleneck is a rare, candid data point.
  • What: The current OVN-relay architecture and its bottlenecks, a re-architecture modeled on OVN-Kubernetes Interconnect, and an evaluation of control-plane backing stores — k8s api-server/etcd with custom CRDs vs. NATS KV — with the chosen option and rationale. The talk explicitly asks the community whether the central OVN SB DB can be replaced by api-server/etcd or NATS KV. (from abstract only)
  • How: Moving from relayed central OVSDB to the ovn-kubernetes-style Interconnect decomposition (per-zone local state, IC database at the top), and re-homing control-plane persistence on a different storage substrate.
  • Where applicable: Crusoe-specific production constraints, but the SB-DB bottleneck and the storage-backend question generalize to any large single-tenant-scale OVN cloud. Watch for whether the community adopts the experimental backend.