Hi Han, I have started with reviewing the patches, but with skimming them faster so that I get the complete picture. So you might see some review comments now :)
Thanks Numan On Thu, Oct 31, 2019 at 2:44 AM Han Zhou <[email protected]> wrote: > > Signed-off-by: Han Zhou <[email protected]> > --- > 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 > --- a/ovn-architecture.7.xml > +++ b/ovn-architecture.7.xml > @@ -1246,7 +1246,14 @@ > <p> > <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. > + </p> > + > + <p> > + 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". > </p> > > <p> > @@ -1801,6 +1808,104 @@ > </li> > </ol> > > + <h2>OVN Deployments Interconnection (TODO)</h2> > + > + <p> > + 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. > + </p> > + > + <p> > + 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. > + </p> > + > + <p> > + 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 s/as a/to 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. > + </p> > + > + <p> > + 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. > + </p> > + > + <p> > + 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. > + </p> > + > + <p> > + 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: > + </p> > + > + <ul> > + <li> > + 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. > + </li> > + <li> > + Availability zones, which are registerd by <code>ovn-ic</code> > + from each AZ. > + </li> > + <li> > + 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. > + </li> > + <li> > + 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. > + </li> > + </ul> > + > + <p> > + 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. > + </p> > + > + <p> > + 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. > + </p> > + > <h2>Native OVN services for external logical ports</h2> > > <p> > -- > 2.1.0 > > _______________________________________________ > dev mailing list > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
