ovn/ovn-architecture.7.xml

   1 <?xml version="1.0" encoding="utf-8"?>
   2 <manpage program="ovn-architecture" section="7" title="OVN Architecture">
   3   <h1>Name</h1>
   4   <p>ovn-architecture -- Open Virtual Network architecture</p>
   5
   6   <h1>Description</h1>
   7
   8   <p>
   9     OVN, the Open Virtual Network, is a system to support virtual network
  10     abstraction.  OVN complements the existing capabilities of OVS to add
  11     native support for virtual network abstractions, such as virtual L2 and L3
  12     overlays and security groups.  Services such as DHCP are also desirable
  13     features.  Just like OVS, OVN's design goal is to have a production-quality
  14     implementation that can operate at significant scale.
  15   </p>
  16
  17   <p>
  18     An OVN deployment consists of several components:
  19   </p>
  20
  21   <ul>
  22     <li>
  23       <p>
  24         A <dfn>Cloud Management System</dfn> (<dfn>CMS</dfn>), which is
  25         OVN's ultimate client (via its users and administrators).  OVN
  26         integration requires installing a CMS-specific plugin and
  27         related software (see below).  OVN initially targets OpenStack
  28         as CMS.
  29       </p>
  30
  31       <p>
  32         We generally speak of ``the'' CMS, but one can imagine scenarios in
  33         which multiple CMSes manage different parts of an OVN deployment.
  34       </p>
  35     </li>
  36
  37     <li>
  38       An OVN Database physical or virtual node (or, eventually, cluster)
  39       installed in a central location.
  40     </li>
  41
  42     <li>
  43       One or more (usually many) <dfn>hypervisors</dfn>.  Hypervisors must run
  44       Open vSwitch and implement the interface described in
  45       <code>IntegrationGuide.md</code> in the OVS source tree.  Any hypervisor
  46       platform supported by Open vSwitch is acceptable.
  47     </li>
  48
  49     <li>
  50       <p>
  51         Zero or more <dfn>gateways</dfn>.  A gateway extends a tunnel-based
  52         logical network into a physical network by bidirectionally forwarding
  53         packets between tunnels and a physical Ethernet port.  This allows
  54         non-virtualized machines to participate in logical networks.  A gateway
  55         may be a physical host, a virtual machine, or an ASIC-based hardware
  56         switch that supports the <code>vtep</code>(5) schema.  (Support for the
  57         latter will come later in OVN implementation.)
  58       </p>
  59
  60       <p>
  61         Hypervisors and gateways are together called <dfn>transport node</dfn>
  62         or <dfn>chassis</dfn>.
  63       </p>
  64     </li>
  65   </ul>
  66
  67   <p>
  68     The diagram below shows how the major components of OVN and related
  69     software interact.  Starting at the top of the diagram, we have:
  70   </p>
  71
  72   <ul>
  73     <li>
  74       The Cloud Management System, as defined above.
  75     </li>
  76
  77     <li>
  78       <p>
  79         The <dfn>OVN/CMS Plugin</dfn> is the component of the CMS that
  80         interfaces to OVN.  In OpenStack, this is a Neutron plugin.
  81         The plugin's main purpose is to translate the CMS's notion of logical
  82         network configuration, stored in the CMS's configuration database in a
  83         CMS-specific format, into an intermediate representation understood by
  84         OVN.
  85       </p>
  86
  87       <p>
  88         This component is necessarily CMS-specific, so a new plugin needs to be
  89         developed for each CMS that is integrated with OVN.  All of the
  90         components below this one in the diagram are CMS-independent.
  91       </p>
  92     </li>
  93
  94     <li>
  95       <p>
  96         The <dfn>OVN Northbound Database</dfn> receives the intermediate
  97         representation of logical network configuration passed down by the
  98         OVN/CMS Plugin.  The database schema is meant to be ``impedance
  99         matched'' with the concepts used in a CMS, so that it directly supports
 100         notions of logical switches, routers, ACLs, and so on.  See
 101         <code>ovs-nb</code>(5) for details.
 102       </p>
 103
 104       <p>
 105         The OVN Northbound Database has only two clients: the OVN/CMS Plugin
 106         above it and <code>ovn-nbd</code> below it.
 107       </p>
 108     </li>
 109
 110     <li>
 111       <code>ovn-nbd</code>(8) connects to the OVN Northbound Database above it
 112       and the OVN Database below it.  It translates the logical network
 113       configuration in terms of conventional network concepts, taken from the
 114       OVN Northbound Database, into logical datapath flows in the OVN Database
 115       below it.
 116     </li>
 117
 118     <li>
 119       <p>
 120         The <dfn>OVN Database</dfn> is the center of the system.  Its clients
 121         are <code>ovn-nbd</code>(8) above it and <code>ovn-controller</code>(8)
 122         on every transport node below it.
 123       </p>
 124
 125       <p>
 126         The OVN Database contains three kinds of data: <dfn>Physical
 127         Network</dfn> (PN) tables that specify how to reach hypervisor and
 128         other nodes, <dfn>Logical Network</dfn> (LN) tables that describe the
 129         logical network in terms of ``logical datapath flows,'' and
 130         <dfn>Binding</dfn> tables that link logical network components'
 131         locations to the physical network.  The hypervisors populate the PN and
 132         Binding tables, whereas <code>ovn-nbd</code>(8) populates the LN
 133         tables.
 134       </p>
 135
 136       <p>
 137         OVN Database performance must scale with the number of transport nodes.
 138         This will likely require some work on <code>ovsdb-server</code>(1) as
 139         we encounter bottlenecks.  Clustering for availability may be needed.
 140       </p>
 141     </li>
 142   </ul>
 143
 144   <p>
 145     The remaining components are replicated onto each hypervisor:
 146   </p>
 147
 148   <ul>
 149     <li>
 150       <code>ovn-controller</code>(8) is OVN's agent on each hypervisor and
 151       software gateway.  Northbound, it connects to the OVN Database to learn
 152       about OVN configuration and status and to populate the PN and <code>Bindings</code>
 153       tables with the hypervisor's status.  Southbound, it connects to
 154       <code>ovs-vswitchd</code>(8) as an OpenFlow controller, for control over
 155       network traffic, and to the local <code>ovsdb-server</code>(1) to allow
 156       it to monitor and control Open vSwitch configuration.
 157     </li>
 158
 159     <li>
 160       <code>ovs-vswitchd</code>(8) and <code>ovsdb-server</code>(1) are
 161       conventional components of Open vSwitch.
 162     </li>
 163   </ul>
 164
 165   <pre fixed="yes">
 166                                   CMS
 167                                    |
 168                                    |
 169                        +-----------|-----------+
 170                        |           |           |
 171                        |     OVN/CMS Plugin    |
 172                        |           |           |
 173                        |           |           |
 174                        |   OVN Northbound DB   |
 175                        |           |           |
 176                        |           |           |
 177                        |        ovn-nbd        |
 178                        |           |           |
 179                        +-----------|-----------+
 180                                    |
 181                                    |
 182                                 +------+
 183                                 |OVN DB|
 184                                 +------+
 185                                    |
 186                                    |
 187                 +------------------+------------------+
 188                 |                  |                  |
 189  HV 1           |                  |    HV n          |
 190 +---------------|---------------+  .  +---------------|---------------+
 191 |               |               |  .  |               |               |
 192 |        ovn-controller         |  .  |        ovn-controller         |
 193 |         |          |          |  .  |         |          |          |
 194 |         |          |          |     |         |          |          |
 195 |  ovs-vswitchd   ovsdb-server  |     |  ovs-vswitchd   ovsdb-server  |
 196 |                               |     |                               |
 197 +-------------------------------+     +-------------------------------+
 198   </pre>
 199
 200   <h3>Life Cycle of a VIF</h3>
 201
 202   <p>
 203     Tables and their schemas presented in isolation are difficult to
 204     understand.  Here's an example.
 205   </p>
 206
 207   <p>
 208     The steps in this example refer often to details of the OVN and OVN
 209     Northbound database schemas.  Please see <code>ovn</code>(5) and
 210     <code>ovn-nb</code>(5), respectively, for the full story on these
 211     databases.
 212   </p>
 213
 214   <ol>
 215     <li>
 216       A VIF's life cycle begins when a CMS administrator creates a new VIF
 217       using the CMS user interface or API and adds it to a switch (one
 218       implemented by OVN as a logical switch).  The CMS updates its own
 219       configuration.  This includes associating unique, persistent identifier
 220       <var>vif-id</var> and Ethernet address <var>mac</var> with the VIF.
 221     </li>
 222
 223     <li>
 224       The CMS plugin updates the OVN Northbound database to include the new
 225       VIF, by adding a row to the <code>Logical_Port</code> table.  In the new
 226       row, <code>name</code> is <var>vif-id</var>, <code>mac</code> is
 227       <var>mac</var>, <code>switch</code> points to the OVN logical switch's
 228       Logical_Switch record, and other columns are initialized appropriately.
 229     </li>
 230
 231     <li>
 232       <code>ovs-nbd</code> receives the OVN Northbound database update.  In
 233       turn, it makes the corresponding updates to the OVN database, by adding
 234       rows to the OVN database <code>Pipeline</code> table to reflect the new
 235       port, e.g. add a flow to recognize that packets destined to the new
 236       port's MAC address should be delivered to it, and update the flow that
 237       delivers broadcast and multicast packets to include the new port.
 238     </li>
 239
 240     <li>
 241       On every hypervisor, <code>ovn-controller</code> receives the
 242       <code>Pipeline</code> table updates that <code>ovs-nbd</code> made in the
 243       previous step.  As long as the VM that owns the VIF is powered off,
 244       <code>ovn-controller</code> cannot do much; it cannot, for example,
 245       arrange to send packets to or receive packets from the VIF, because the
 246       VIF does not actually exist anywhere.
 247     </li>
 248
 249     <li>
 250       Eventually, a user powers on the VM that owns the VIF.  On the hypervisor
 251       where the VM is powered on, the integration between the hypervisor and
 252       Open vSwitch (described in <code>IntegrationGuide.md</code>) adds the VIF
 253       to the OVN integration bridge and stores <var>vif-id</var> in
 254       <code>external-ids</code>:<code>iface-id</code> to indicate that the
 255       interface is an instantiation of the new VIF.  (None of this code is new
 256       in OVN; this is pre-existing integration work that has already been done
 257       on hypervisors that support OVS.)
 258     </li>
 259
 260     <li>
 261       On the hypervisor where the VM is powered on, <code>ovn-controller</code>
 262       notices <code>external-ids</code>:<code>iface-id</code> in the new
 263       Interface.  In response, it updates the local hypervisor's OpenFlow
 264       tables so that packets to and from the VIF are properly handled.
 265       Afterward, it updates the <code>Bindings</code> table in the OVN DB,
 266       adding a row that links the logical port from
 267       <code>external-ids</code>:<code>iface-id</code> to the hypervisor.
 268     </li>
 269
 270     <li>
 271       Some CMS systems, including OpenStack, fully start a VM only when its
 272       networking is ready.  To support this, <code>ovn-nbd</code> notices the
 273       new row in the <code>Bindings</code> table, and pushes this upward by
 274       updating the <ref column="up" table="Logical_Port" db="OVN_NB"/> column
 275       in the OVN Northbound database's <ref table="Logical_Port" db="OVN_NB"/>
 276       table to indicate that the VIF is now up.  The CMS, if it uses this
 277       feature, can then react by allowing the VM's execution to proceed.
 278     </li>
 279
 280     <li>
 281       On every hypervisor but the one where the VIF resides,
 282       <code>ovn-controller</code> notices the new row in the
 283       <code>Bindings</code> table.  This provides <code>ovn-controller</code>
 284       the physical location of the logical port, so each instance updates the
 285       OpenFlow tables of its switch (based on logical datapath flows in the OVN
 286       DB <code>Pipeline</code> table) so that packets to and from the VIF can
 287       be properly handled via tunnels.
 288     </li>
 289
 290     <li>
 291       Eventually, a user powers off the VM that owns the VIF.  On the
 292       hypervisor where the VM was powered on, the VIF is deleted from the OVN
 293       integration bridge.
 294     </li>
 295
 296     <li>
 297       On the hypervisor where the VM was powered on,
 298       <code>ovn-controller</code> notices that the VIF was deleted.  In
 299       response, it removes the logical port's row from the
 300       <code>Bindings</code> table.
 301     </li>
 302
 303     <li>
 304       On every hypervisor, <code>ovn-controller</code> notices the row removed
 305       from the <code>Bindings</code> table.  This means that
 306       <code>ovn-controller</code> no longer knows the physical location of the
 307       logical port, so each instance updates its OpenFlow table to reflect
 308       that.
 309     </li>
 310
 311     <li>
 312       Eventually, when the VIF (or its entire VM) is no longer needed by
 313       anyone, an administrator deletes the VIF using the CMS user interface or
 314       API.  The CMS updates its own configuration.
 315     </li>
 316
 317     <li>
 318       The CMS plugin removes the VIF from the OVN Northbound database,
 319       by deleting its row in the <code>Logical_Port</code> table.
 320     </li>
 321
 322     <li>
 323       <code>ovs-nbd</code> receives the OVN Northbound update and in turn
 324       updates the OVN database accordingly, by removing or updating the
 325       rows from the OVN database <code>Pipeline</code> table that were related
 326       to the now-destroyed VIF.
 327     </li>
 328
 329     <li>
 330       On every hypervisor, <code>ovn-controller</code> receives the
 331       <code>Pipeline</code> table updates that <code>ovs-nbd</code> made in the
 332       previous step.  <code>ovn-controller</code> updates OpenFlow tables to
 333       reflect the update, although there may not be much to do, since the VIF
 334       had already become unreachable when it was removed from the
 335       <code>Bindings</code> table in a previous step.
 336     </li>
 337   </ol>
 338
 339 </manpage>