[ovs-dev] [PATCH ovn v2 01/13] ovn-architecture: Add documentation for OVN interconnection feature.
hzhou at ovn.org
Wed Oct 30 21:12:41 UTC 2019
Signed-off-by: Han Zhou <hzhou at ovn.org>
ovn-architecture.7.xml | 107 ++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 106 insertions(+), 1 deletion(-)
diff --git a/ovn-architecture.7.xml b/ovn-architecture.7.xml
index 7966b65..56b2167 100644
@@ -1246,7 +1246,14 @@
<dfn>Distributed gateway ports</dfn> are logical router patch ports
that directly connect distributed logical routers to logical
- switches with localnet ports.
+ switches with external connection.
+ There are two types of external connections. Firstly, connection to
+ physical network through a localnet port. Secondly, connection to
+ another OVN deployment, which will be introduced in section "OVN
+ Deployments Interconnection".
@@ -1801,6 +1808,104 @@
+ <h2>OVN Deployments Interconnection (TODO)</h2>
+ It is not uncommon for an operator to deploy multiple OVN clusters, for
+ two main reasons. Firstly, an operator may prefer to deploy one OVN
+ cluster for each availability zone, e.g. in different physical regions,
+ to avoid single point of failure. Secondly, there is always an upper limit
+ for a single OVN control plane to scale.
+ Although the control planes of the different availability zone (AZ)s are
+ independent from each other, the workloads from different AZs may need
+ to communicate across the zones. The OVN interconnection feature provides
+ a native way to interconnect different AZs by L3 routing through transit
+ overlay networks between logical routers of different AZs.
+ A global OVN Interconnection Northbound database is introduced for the
+ operator (probably through CMS systems) to configure transit logical
+ switches that connect logical routers from different AZs. A transit
+ switch is similar as a regular logical switch, but it is used for
+ interconnection purpose only. Typically, each transit switch can be used
+ to connect all logical routers that belong to same tenant across all AZs.
+ A dedicated daemon process <code>ovn-ic</code>, OVN interconnection
+ controller, in each AZ will consume this data and populate corresponding
+ logical switches to their own northbound databases for each AZ, so that
+ logical routers can be connected to the transit switch by creating
+ patch port pairs in their northbound databases. Any router ports
+ connected to the transit switches are considered interconnection ports,
+ which will be exchanged between AZs.
+ Physically, when workloads in from different AZs communicate, packets
+ need to go through multiple hops: source chassis, source gateway,
+ destination gateway and destination chassis. All these hops are connected
+ through tunnels so that the packets never leave overlay networks.
+ A distributed gateway port is required to connect the logical router to a
+ transit switch, with a gateway chassis specified, so that the traffic can
+ be forwarded through the gateway chassis.
+ A global OVN Interconnection Southbound database is introduced for
+ exchanging control plane information between the AZs. The data in
+ this database is populated and consumed by the <code>ovn-ic</code>,
+ of each AZ. The main information in this database includes:
+ Datapath bindings for transit switches, which mainly contains the tunnel
+ keys generated for each transit switch. Separate key ranges are reserved
+ for transit switches so that they will never conflict with any tunnel
+ keys locally assigned for datapaths within each AZ.
+ Availability zones, which are registerd by <code>ovn-ic</code>
+ from each AZ.
+ Gateways. Each AZ specifies chassises that are supposed to work
+ as interconnection gateways, and the <code>ovn-ic</code> will
+ populate this information to the interconnection southbound DB.
+ The <code>ovn-ic</code> from all the other AZs will learn the
+ gateways and populate to their own southbound DB as a chassis.
+ Port bindings for logical switch ports created on the transit switch.
+ Each AZ maintains their logical router to transit switch connections
+ independently, but <code>ovn-ic</code> automatically populates
+ local port bindings on transit switches to the global interconnection
+ southbound DB, and learns remote port bindings from other AZs back
+ to its own northbound and southbound DBs, so that logical flows
+ can be produced and then translated to OVS flows locally, which finally
+ enables data plane communication.
+ The tunnel keys for transit switch datapaths and related port bindings
+ must be agreed across all AZs. This is ensured by generating and storing
+ the keys in the global interconnection southbound database. Any
+ <code>ovn-ic</code> from any AZ can allocate the key, but race conditions
+ are solved by enforcing unique index for the column in the database.
+ Once each AZ's NB and SB databases are populated with interconnection
+ switches and ports, and agreed upon the tunnel keys, data plane
+ communication between the AZs are established.
<h2>Native OVN services for external logical ports</h2>
More information about the dev