From patchwork Mon Oct 21 00:51:07 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Han Zhou X-Patchwork-Id: 1180134 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=openvswitch.org (client-ip=140.211.169.12; helo=mail.linuxfoundation.org; envelope-from=ovs-dev-bounces@openvswitch.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=ovn.org Received: from mail.linuxfoundation.org (mail.linuxfoundation.org [140.211.169.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 46xJ951BWNz9sPZ for ; Mon, 21 Oct 2019 11:55:53 +1100 (AEDT) Received: from mail.linux-foundation.org (localhost [127.0.0.1]) by mail.linuxfoundation.org (Postfix) with ESMTP id 3B920C87; Mon, 21 Oct 2019 00:51:50 +0000 (UTC) X-Original-To: dev@openvswitch.org Delivered-To: ovs-dev@mail.linuxfoundation.org Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8FD42C75 for ; Mon, 21 Oct 2019 00:51:47 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from relay11.mail.gandi.net (relay11.mail.gandi.net [217.70.178.231]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 99127831 for ; Mon, 21 Oct 2019 00:51:46 +0000 (UTC) Received: from localhost.localdomain.localdomain (unknown [216.113.160.71]) (Authenticated sender: hzhou@ovn.org) by relay11.mail.gandi.net (Postfix) with ESMTPSA id 19BE1100004; Mon, 21 Oct 2019 00:51:43 +0000 (UTC) From: Han Zhou To: dev@openvswitch.org Date: Sun, 20 Oct 2019 17:51:07 -0700 Message-Id: <1571619079-75503-8-git-send-email-hzhou@ovn.org> X-Mailer: git-send-email 2.1.0 In-Reply-To: <1571619079-75503-1-git-send-email-hzhou@ovn.org> References: <1571619079-75503-1-git-send-email-hzhou@ovn.org> X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Han Zhou Subject: [ovs-dev] [PATCH ovn 07/19] ovn-architecture: Add documentation for OVN interconnection feature. X-BeenThere: ovs-dev@openvswitch.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: ovs-dev-bounces@openvswitch.org Errors-To: ovs-dev-bounces@openvswitch.org Signed-off-by: Han Zhou --- 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 @@

Distributed gateway ports 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 @@ +

OVN Deployments Interconnection (TODO)

+ +

+ 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 ovn-ic, 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 ovn-ic, + 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 ovn-ic + from each AZ. +
    • +
  • + Gateways. Each AZ specifies chassises that are supposed to work + as interconnection gateways, and the ovn-ic will + populate this information to the interconnection southbound DB. + The ovn-ic 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 ovn-ic 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 + ovn-ic 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. +

+

Native OVN services for external logical ports