Having introduced OVN, this article will delve into the reference architecture of the OVN plugin in OpenStack.
Table of Contents
Topology
The reference architecture divides OVN components into four distinct categories, each with different responsibilities.
Controller Node
Controller node primarily provides the following functions:
- 1 Management Interface
- Identity Service (Keystone)
- Image Service (Glance)
- Network Management via OVN ML2 Mechanism Driver (Control Plane)
- Compute Resource Management (Nova control plane)
Database Node
Database node is mainly responsible for OVN-related databases, including the following components:
- 1 Management Interface
- ovn-northd
- OVN northbound database
- OVN southbound database
Compute Node
Compute node includes the following components:
- 2-3 interfaces, providing for management, overlay, and provider networks
- Nova-compute
- Hypervisor (KVM)
- ovn-controller
- ovs-vswitchd
- ovsdb-server and OVS local configuration (conf.db) database
- ovn-metadata-agent
Gateway Node
Gateway node includes the following components:
- 3 interfaces, providing for management, overlay, and provider networks
- ovn-controller
- ovs-vswitchd
- ovsdb-server and OVS local configuration (conf.db) database
Physical Deployment
The physical layout can refer to the official documentation diagram, which roughly illustrates the minimum requirements for each component.
Virtual Deployment
The official documentation diagram describes which processes run within each component; these are only those closely related to OVN, and other services such as Keystone are not listed above.
Note that this is only the official reference architecture; in practice, you can run some components on the same node when the number of nodes is not large.
OVN-integrated OpenStack Networking
The default OpenStack networking architecture roughly looks like this:
When using networking-ovn, all traffic flows are fully distributed, going directly from compute node to compute node without passing through a network node, thus reducing latency and potential bottlenecks.
Network traffic requiring SNAT (without floating IP) will need to go through the gateway node. When you have multiple gateway nodes, OVN’s built-in HA ensures that network connectivity remains unaffected if one node goes down.
The deployment method for floating IPs is further divided into the following two types:
Centralized Floating IPs
Under this architecture, all north-south traffic through the router will pass through the gateway node, and compute nodes do not need external network connectivity.
Distributed Floating IPs (DVR)
Under this architecture, north-south floating IP traffic will go directly from the compute node through a specific provider network bridge. In this scenario, compute nodes require external network connectivity.
Each compute node includes the following components:
At the same time, you can have multiple different provider bridges connected to different provider networks.
Summary
That's roughly the complete networking architecture provided by OVN when used with OpenStack Networking. In the next section, we'll quickly compare the differences between using OVN and OVS within OpenStack.
Copyright Notice: All articles in this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.