схема базы данных OVN_Southbound (OVN_Southbound database schema)
Имя (Name)
ovn-sb - OVN_Southbound database schema
This database holds logical and physical configuration and state
for the Open Virtual Network (OVN) system to support virtual
network abstraction. For an introduction to OVN, please see
ovn-architecture(7).
The OVN Southbound database sits at the center of the OVN
architecture. It is the one component that speaks both southbound
directly to all the hypervisors and gateways, via
ovn-controller/ovn-controller-vtep, and northbound to the Cloud
Management System, via ovn-northd:
Database Structure
The OVN Southbound database contains classes of data with
different properties, as described in the sections below.
Physical network
Physical network tables contain information about the chassis
nodes in the system. This contains all the information necessary
to wire the overlay, such as IP addresses, supported tunnel
types, and security keys.
The amount of physical network data is small (O(n) in the number
of chassis) and it changes infrequently, so it can be replicated
to every chassis.
The Chassis and Encap tables are the physical network tables.
Logical Network
Logical network tables contain the topology of logical switches
and routers, ACLs, firewall rules, and everything needed to
describe how packets traverse a logical network, represented as
logical datapath flows (see Logical Datapath Flows, below).
Logical network data may be large (O(n) in the number of logical
ports, ACL rules, etc.). Thus, to improve scaling, each chassis
should receive only data related to logical networks in which
that chassis participates.
The logical network data is ultimately controlled by the cloud
management system (CMS) running northbound of OVN. That CMS
determines the entire OVN logical configuration and therefore the
logical network data at any given time is a deterministic
function of the CMS's configuration, although that happens
indirectly via the OVN_Northbound database and ovn-northd.
Logical network data is likely to change more quickly than
physical network data. This is especially true in a container
environment where containers are created and destroyed (and
therefore added to and deleted from logical switches) quickly.
The Logical_Flow, Multicast_Group, Address_Group, DHCP_Options,
DHCPv6_Options, and DNS tables contain logical network data.
Logical-physical bindings
These tables link logical and physical components. They show the
current placement of logical components (such as VMs and VIFs)
onto chassis, and map logical entities to the values that
represent them in tunnel encapsulations.
These tables change frequently, at least every time a VM powers
up or down or migrates, and especially quickly in a container
environment. The amount of data per VM (or VIF) is small.
Each chassis is authoritative about the VMs and VIFs that it
hosts at any given time and can efficiently flood that state to a
central location, so the consistency needs are minimal.
The Port_Binding and Datapath_Binding tables contain binding
data.
MAC bindings
The MAC_Binding table tracks the bindings from IP addresses to
Ethernet addresses that are dynamically discovered using ARP (for
IPv4) and neighbor discovery (for IPv6). Usually, IP-to-MAC
bindings for virtual machines are statically populated into the
Port_Binding table, so MAC_Binding is primarily used to discover
bindings on physical networks.
Common Columns
Some tables contain a special column named external_ids. This
column has the same form and purpose each place that it appears,
so we describe it here to save space later.
external_ids: map of string-string pairs
Key-value pairs for use by the software that
manages the OVN Southbound database rather than by
ovn-controller/ovn-controller-vtep. In particular,
ovn-northd can use key-value pairs in this column
to relate entities in the southbound database to
higher-level entities (such as entities in the OVN
Northbound database). Individual key-value pairs in
this column may be documented in some cases to aid
in understanding and troubleshooting, but the
reader should not mistake such documentation as
comprehensive.
