Introduction to OVN
20 Apr 2015I have written about OVN when it was just introduced, you can read that post here
In the meantime i was fortunate enough to be able to join the efforts of OVN and contribute to the OVN integration with Openstack.
In this post i will mostly describe the architecture, as i see it, of OVN, and focus mainly on the high level. Things are of course dynamic at this stage, but we can already get a good sense of how connectivity with VM’s and containers (and containers inside a VM) is going to happen.
If you want to experiment with the current code and Openstack integration, make sure you read the following great post by Russell Bryant, which is describing the current state of the integration and some nice getting started tips.
We welcome any contribution, feel free to stop by IRC in #Openstack-neutron-ovn.
The following diagram depicts the high level architecture of OVN
As you can see from the diagram an OVN DB is installed in a centralized location, this will be in the future a cluster and can be either virtual or physical.
A daemon called ovn-northd runs in this centralized location, its job is to translate between the logical network elements configured by the CMS to the Northbound DB and model them to the Southbound DB tables, which holds the physical/infrastructure bindings and the logical flows which enable the logical connectivity.
In my eyes, this is a key point in the design, there are two DB’s which abstract the logical network configuration in terms of conventional network concepts, from the way they are actually achieved (using Openflow flows) and configured in the physical network.
OVN Northbound DB
This DB has two clients, the CMS which translate its own notion of logical networking configuration into the OVN model (Basically this means that if we take Openstack Neutron for example, it translate neutron networks/ports/security groups into logical switches/logical ports/ACL’s), And the ovn-northd which translate this DB into the Southbound DB model.
The Northbound DB describe the logical network in conventional network concepts and describe only virtual elements and the connectivity between them: logical switches, logical ports that connect to these switches and logical routers which connects between different logical switches. There are also ACL’s which we can attach to logical switches and configure them for specific logical ports.
Logical ports can represent VM’s, containers and there is also an extended design to address the use case of containers running inside a VM (I will describe this in the next post)
It is important to note that the communication between the ovn-northd and the CMS is bidirectional, for example ovn-northd can update the CMS when a port operational status is up, indicating all needed hooks and configuration took place (This is usefull in the Neutron case as Neutron needs to indicate to Nova when a port is ready after deploying a VM)
OVN Southbound DB
The southbound DB has three kinds of elements, the physical network objects and the way traffic is exchanged between them (overlay network, tunnels, encapsulation), the logical network in terms of logical datapath flows (openflow compliant) and the binding tables which links logical network locations to the physical network.
The ovn-northd daemon populate the logical datapath flows, while the ovn-controller (OVN agent in the hypervisor) populate the physical elements and the bindings.
ovn-controller uses the DB information and connects to the local OpenVSwitch as an Openflow controller to actually configure the needed flows for correct connectivity and also as an OVSDB manager to read the local configurations
This is a quick high level overview of the important components in OVN for anyone that is new.
In the next posts i am going to drill more into the design, describe the openstack integration model, L2 Gateways, containers networking in OVN and much more..
Stay tuned!
Tags: OVN · OVS · Openstack ← Previous Post: DPDK Design Tips (Part 1 - RSS) Next Post: Containers Support In OVN →