Vapor-native Clusters
In a Vapor-native deployment, Vapor runs the OVN databases itself. A single central is a complete deployment; a cluster of three or more keeps working when a host is lost.
This page covers forming that cluster and adding hosts to it. Activation itself is covered in Activating the Virtual Network.
How many centrals
The OVN databases are replicated with RAFT, which needs a majority of members to agree before it accepts a write.
| Centrals | Tolerates | Notes |
|---|---|---|
| 1 | nothing | Fully functional. Losing the host stops the deployment |
| 2 | nothing | Worse than one. Either host failing removes the majority |
| 3 | one failure | The smallest useful cluster |
| 5 | two failures | For larger deployments |
Use an odd number. Adding a second central to a single-central deployment makes availability worse, not better, until you add a third.
Hosts that only run workloads do not need to be centrals. A deployment of three centrals and twenty chassis is normal.
Forming the cluster
Exactly one central starts the cluster; every other central joins the one that did.
The first central
In the activation wizard choose Vapor-native, role Central, and Bootstrap a new cluster. Apply.
Afterwards the OVN status card reports the host as holding the databases, and the cluster page shows it as the only member.
Adding a central
Each additional central authenticates to an existing one with a join token. On the central, use Mint join token on the OVN status card. The token is shown once — only its digest is stored, so it cannot be recovered afterwards. By default it is valid for one hour and one use.
On the host being added, run the wizard with Vapor-native, role Central, Join an existing cluster, then:
- enter the existing central's address (port 7770 is assumed if you omit it),
- paste the token,
- press Exchange token with central.
Vapor contacts the central, and on success fills in the database addresses and the cluster address to join. You do not have to copy those by hand.
Then continue through preflight and apply.
Why the exchange happens on the host, not in your browser
Your browser is served by one Vapor host and the central is another, usually with a self-signed certificate. The joining host performs the exchange itself, which is also why Skip TLS verification for this exchange is offered — a first join normally needs it. Turn it off once the central presents a certificate the joining host trusts.
Adding a chassis
A chassis needs only the database addresses, not membership. You can supply them directly, or use a join token the same way to have them filled in for you.
Replacing existing databases
Forming or joining a cluster replaces this host's OVN database files. If the host already has them, Vapor refuses until you tick Allow this host's OVN databases to be replaced.
Take that seriously on a host that has been running standalone: its northbound database is the entire logical configuration — every switch, router, ACL and load balancer. Vapor moves the existing files aside rather than deleting them, with a timestamped suffix in /var/lib/ovn, but back them up before you proceed.
A host that is already a healthy cluster member does not need this, and re-applying does not disturb its databases.
How a cluster is addressed
Once a cluster exists, Vapor stores every member's address rather than one:
tcp:10.0.0.1:6641,tcp:10.0.0.2:6641,tcp:10.0.0.3:6641This is deliberate. OVSDB clients talk only to the current leader, so a single stored address stops working the moment leadership moves to another member — which is precisely the event a cluster exists to survive. With every member listed, the client finds the leader itself.
Re-applying activation on a member refreshes the list, which is how a newly added host appears in the others' configuration.
Checking cluster health
The cluster view reports each database separately, with the local server's role, the current term and the full membership. A healthy three-node cluster shows three members for both databases and one leader.
Leadership moving between members is normal. It happens when a host restarts and after any brief loss of contact, and the deployment stays usable throughout.
Two things that are not faults:
- Zero tunnel ports on a host with no logical ports. OVN builds tunnels on demand.
- A member reporting
follower. Only one member is the leader at a time.
Ports to allow between centrals
| Port | Purpose |
|---|---|
| 6641 | Northbound database, clients |
| 6642 | Southbound database, clients (chassis connect here) |
| 6643 | Northbound cluster replication |
| 6644 | Southbound cluster replication |
| 6081/UDP | Geneve tunnels between chassis |
Centrals need all of these between one another. A chassis needs 6642 to the centrals and Geneve to the other chassis.
Surviving a reboot
Vapor writes the cluster parameters where the OVN service units read them and lets systemd own the database processes, so a central comes back after a reboot without intervention. If Vapor cannot enable those units it says so in the log: the databases are running, but they will not return on their own.