Documentation/topics/ovn-news-2.8.rst

   1 ..
   2       Licensed under the Apache License, Version 2.0 (the "License"); you may
   3       not use this file except in compliance with the License. You may obtain
   4       a copy of the License at
   5
   6           http://www.apache.org/licenses/LICENSE-2.0
   7
   8       Unless required by applicable law or agreed to in writing, software
   9       distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
  10       WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
  11       License for the specific language governing permissions and limitations
  12       under the License.
  13
  14       Convention for heading levels in Open vSwitch documentation:
  15
  16       =======  Heading 0 (reserved for the title in a document)
  17       -------  Heading 1
  18       ~~~~~~~  Heading 2
  19       +++++++  Heading 3
  20       '''''''  Heading 4
  21
  22       Avoid deeper levels because they do not render well.
  23
  24 ===============================
  25 What's New with OVS and OVN 2.8
  26 ===============================
  27
  28 This document is about what was added in Open vSwitch 2.8, which was released
  29 at the end of August 2017, concentrating on the new features in OVN.  It also
  30 covers some of what is coming up in Open vSwitch and OVN 2.9, which is due to
  31 be released in February 2018.  OVN has many features, and this document does
  32 not cover every new or enhanced feature (but contributions are welcome).
  33
  34 This document assumes a basic familiarity with Open vSwitch, OVN, and their
  35 associated tools.  For more information, please refer to the Open vSwitch and
  36 OVN documentation, such as the ``ovn-architecture``\(7) manpage.
  37
  38 Debugging and Troubleshooting
  39 -----------------------------
  40
  41 Before version 2.8, Open vSwitch command-line tools were far more painful to
  42 use than they needed to be.  This section covers the improvements made to the
  43 CLI in the 2.8 release.
  44
  45 User-Hostile UUIDs
  46 ~~~~~~~~~~~~~~~~~~
  47
  48 The OVN CLI, through ``ovn-nbctl``, ``ovn-nbctl``, and ``ovn-trace``, used
  49 full-length UUIDs almost everywhere.  It didn't even provide any assistance
  50 with completion, etc., which in practice meant always cutting and pasting UUIDs
  51 from one command or window to another.  This problem wasn't limited to the
  52 places where one would expect to have to see or use a UUID, either.  In many
  53 places where one would expect to be able to use a network, router, or port
  54 name, a UUID was required instead.  In many places where one would want to see
  55 a name, the UUID was displayed instead.  More than anything else, these
  56 shortcomings made the CLI user-hostile.
  57
  58 There was an underlying problem that the southbound database didn't actually
  59 contain all the information needed to provide a decent user interface.  In some
  60 cases, for example, the human-friendly names that one would want to use for
  61 entities simply weren't part of the database.  These names weren't necessary
  62 for correctness, only for usability.
  63
  64 OVN 2.8 eased many of these problems.  Most parts of the CLI now allow the user
  65 to abbreviate UUIDs, as long as the abbreviations are unique within the
  66 database.  Some parts of the CLI where full-length UUIDs make output hard to
  67 read now abbreviate them themselves.  Perhaps more importantly, in many places
  68 the OVN CLI now displays and accepts human-friendly names for networks,
  69 routers, ports, and other entities.  In the places where the names were not
  70 previously available, OVN (through ``ovn-northd``) now copies the names into
  71 the southbound database.
  72
  73 The CLIs for layers below OVN, at the OpenFlow and datapath layers with
  74 ``ovs-ofctl`` and ``ovs-dpctl``, respectively, had some similar problems in
  75 which numbers were used for entities that had human-friendly names.  Open
  76 vSwitch 2.8 also solves some of those problems.  Other than that, the most
  77 notable enhancement in this area was the ``--no-stats`` option to ``ovs-ofctl
  78 dump-flows``, which made that command's output more readable for the cases
  79 where per-flow statistics were not interesting to the reader.
  80
  81 Connections Between Levels
  82 ~~~~~~~~~~~~~~~~~~~~~~~~~~
  83
  84 OVN and Open vSwitch work almost like a stack of compilers: the OVN Neutron
  85 plugin translates Neutron configuration into OVN northbound configuration,
  86 which ``ovn-northd`` translates into logical flows, which ``ovn-controller``
  87 translates into OpenFlow flows, which ``ovs-vswitchd`` translates into datapath
  88 flows.  For debugging and troubleshooting it is often necessary to understand
  89 exactly how these translations work.  The relationship from a logical flow to
  90 its OpenFlow flows, or in the other direction, from an OpenFlow flow back to
  91 the logical flow that produced it, was often of particular interest, but OVN
  92 didn't provide good tools for the job.
  93
  94 OVN 2.8 added some new features that ease these jobs.  ``ovn-sbctl lflow-list``
  95 has a new option ``--ovs`` that lists the OpenFlow flows on a particular
  96 chassis that were generated from the logical flows that it lists.
  97 ``ovn-trace`` also added a similar ``--ovs`` option that applies to the logical
  98 flows it traces.
  99
 100 In the other direction, OVN 2.8 added a new utility ``ovn-detrace`` that, given
 101 an Open vSwitch trace of OpenFlow flows, annotates it with the logical flows
 102 that yielded those OpenFlow flows.
 103
 104 Distributed Firewall
 105 ~~~~~~~~~~~~~~~~~~~~
 106
 107 OVN supports a distributed firewall with stateful connection tracking to ensure
 108 that only packets for established connections, or those that the configuration
 109 explicitly allows, can ingress a given VM or container.  Neutron uses this
 110 feature by default.  Most packets in an OpenStack environment pass through it
 111 twice, once after egress from the packet's source VM and once before ingress
 112 into its destination VM.  Before OVN 2.8, the ``ovn-trace`` program, which
 113 shows the path of a packet through an OVN logical network, did not support the
 114 logical firewall, which in practice made it almost useless for Neutron.
 115
 116 In OVN 2.8, ``ovn-trace`` adds support for the logical firewall.  By default it
 117 assumes that packets are part of an established connection, which is usually
 118 what the user wants as part of the trace.  It also accepts command-line options
 119 to override that assumption, which allows the user to discover the treatment of
 120 packets that the firewall should drop.
 121
 122 At the next level deeper, prior to Open vSwitch 2.8, the OpenFlow tracing
 123 command ``ofproto/trace`` also supported neither the connection tracking
 124 feature underlying the OVN distributed firewall nor the "recirculation" feature
 125 that accompanied it.  This meant that, even if the user tried to look deeper
 126 into the distributed firewall mechanism, he or she would encounter a further
 127 roadblock.  Open vSwitch 2.8 added support for both of these features as well.
 128
 129 Summary Display
 130 ~~~~~~~~~~~~~~~
 131
 132 ``ovn-nbctl show`` and ``ovn-sbctl show``, for showing an overview of the OVN
 133 configuration, didn't show a lot of important information.  OVN adds some more
 134 useful information here.
 135
 136 DNS, and IPAM
 137 -------------
 138
 139 OVN 2.8 adds a built-in DNS server designed for assigning names to VMs and
 140 containers within an OVN logical network.  DNS names are assigned using records
 141 in the OVN northbound database and, like other OVN features, translated into
 142 logical flows at the OVN southbound layer.  DNS requests directed to the OVN
 143 DNS server never leave the hypervisor from which the request is sent; instead,
 144 OVN processes and replies to the request from its ``ovn-controller`` local
 145 agent.  The OVN DNS server is not a general-purpose DNS server and cannot be
 146 used for that purpose.
 147
 148 OVN includes simple built-in support for IP address management (IPAM), in which
 149 OVN assigns IP addresses to VMs or containers from a pool or pools of IP
 150 addresses delegated to it by the administrator.  Before OVN 2.8, OVN IPAM only
 151 supported IPv4 addresses; OVN 2.8 adds support for IPv6.  OVN 2.8 also enhances
 152 the address pool support to allow specific addresses to be excluded.  Neutron
 153 assigns IP addresses itself and does not use OVN IPAM.
 154
 155 High Availability
 156 -----------------
 157
 158 As a distributed system, in OVN a lot can go wrong.  As OVN advances, it adds
 159 redundancy in places where currently a single failure could disrupt the
 160 functioning of the system as a whole.  OVN 2.8 adds two new kinds of high
 161 availability.
 162
 163 ovn-northd HA
 164 ~~~~~~~~~~~~~
 165
 166 The ``ovn-northd`` program sits between the OVN northbound and southbound
 167 databases and translates from a logical network configuration into logical
 168 flows.  If ``ovn-northd`` itself or the host on which it runs fails, then
 169 updates to the OVN northbound configuration will not propagate to the
 170 hypervisors and the OVN configuration freezes in place until ``ovn-northd``
 171 restarts.
 172
 173 OVN 2.8 adds support for active-backup HA to ``ovn-northd``.  When more than
 174 one ``ovn-northd`` instance runs, it uses an OVSDB locking feature to
 175 automatically choose a single active instance.  When that instance dies or
 176 becomes nonresponsive, the OVSDB server automatically choose one of the
 177 remaining instance(s) to take over.
 178
 179 L3 Gateway HA
 180 ~~~~~~~~~~~~~
 181
 182 In OVN 2.8, multiple chassis may now be specified for L3 gateways.  When more
 183 than one chassis is specified, OVN manages high availability for that gateway.
 184 Each hypervisor uses the BFD protocol to keep track of the gateway nodes that
 185 are currently up.  At any given time, a hypervisor uses the highest-priority
 186 gateway node that is currently up.
 187
 188 OVSDB
 189 -----
 190
 191 The OVN architecture relies heavily on OVSDB, the Open vSwitch database, for
 192 hosting the northbound and southbound databases.  OVSDB was originally selected
 193 for this purpose because it was already used in Open vSwitch for configuring
 194 OVS itself and, thus, it was well integrated with OVS and well supported in C
 195 and Python, the two languages that are used in Open vSwitch.
 196
 197 OVSDB was well designed for its original purpose of configuring Open vSwitch.
 198 It supports ACID transactions, has a small, efficient server, a flexible schema
 199 system, and good support for troubleshooting and debugging.  However, it lacked
 200 several features that are important for OVN but not for Open vSwitch.  As OVN
 201 advances, these missing features have become more and more of a problem.  One
 202 option would be to switch to a different database that already has many of
 203 these features, but despite a careful search, no ideal existing database was
 204 identified, so the project chose instead to improve OVSDB where necessary to
 205 bring it up to speed.  The following sections talk more about recent and future
 206 improvements.
 207
 208 High Availability
 209 ~~~~~~~~~~~~~~~~~
 210
 211 When ``ovsdb-server`` was only used for OVS configuration, high availability
 212 was not important.  ``ovsdb-server`` was capable of restarting itself
 213 automatically if it crashed, and if the whole system went down then Open
 214 vSwitch itself was dead too, so the database server's failure was not
 215 important.
 216
 217 In contrast, the northbound and southbound databases are centralized components
 218 of a distributed system, so it is important that they not be a single point of
 219 failure for the system as a whole.  In released versions of OVN,
 220 ``ovsdb-server`` supports only "active-backup replication" across a pair of
 221 servers.  This means that if one server goes down, the other can pick it back
 222 up approximately where the other one left off.  The servers do not have
 223 built-in support for deciding at any given time which is the active and which
 224 the backup, so the administrator must configure an external agent to do this
 225 management.
 226
 227 Active-backup replication is not entirely satisfactory, for multiple reasons.
 228 Replication is only approximate.  Configuring the external agent requires extra
 229 work.  There is no benefit from the backup server except when the active server
 230 fails.  At most two servers can be used.
 231
 232 A new form of high availability for OVSDB is under development for the OVN 2.9
 233 release, based on the Raft algorithm for distributed consensus.  Whereas
 234 replication uses two servers, clustering using Raft requires three or more
 235 (typically an odd number) and continues functioning as long as more than half
 236 of the servers are up.  The clustering implementation is built into
 237 ``ovsdb-server`` and does not require an external agent.  Clustering preserves
 238 the ACID properties of the database, so that a transaction that commits is
 239 guaranteed to persist.  Finally, reads (which are the bulk of the OVN workload)
 240 scale with the size of the cluster, so that adding more servers should improve
 241 performance as the number of hypervisors in an OVN deployment increases.  As of
 242 this writing, OVSDB support for clustering is undergoing development and early
 243 deployment testing.
 244
 245 RBAC security
 246 ~~~~~~~~~~~~~
 247
 248 Until Open vSwitch 2.8, ``ovsdb-server`` had little support for access control
 249 within a database.  If an OVSDB client could modify the database at all, it
 250 could make arbitrary changes.  This was sufficient for most uses case to that
 251 point.
 252
 253 Hypervisors in an OVN deployment need access to the OVN southbound database.
 254 Most of their access is reads, to find out about the OVN configuration.
 255 Hypervisors do need some write access to the southbound database, primarily to
 256 let the other hypervisors know what VMs and containers they are running and how
 257 to reach them.  Thus, OVN gives all of the hypervisors in the OVN deployment
 258 write access to the OVN southbound database.  This is fine when all is well,
 259 but if any of the hypervisors were compromised then they could disrupt the
 260 entire OVN deployment by corrupting the database.
 261
 262 The OVN developers considered a few ways to solve this problem.  One way would
 263 be to introduce a new central service (perhaps in ``ovn-northd``) that provided
 264 only the kinds of writes that the hypervisors legitimately need, and then grant
 265 hypervisors direct access to the southbound database only for reads.  But
 266 ultimately the developers decided to introduce a new form of more access
 267 control for OVSDB, called the OVSDB RBAC (role-based access control) feature.
 268 OVSDB RBAC allows for granular enough control over access that hypervisors can
 269 be granted only the ability to add, modify, and delete the records that relate
 270 to themselves, preventing them from corrupting the database as a whole.
 271
 272 Further Directions
 273 ------------------
 274
 275 For more information about new features in OVN and Open vSwitch, please refer
 276 to the NEWS file distributed with the source tree.  If you have questions about
 277 Open vSwitch or OVN features, please feel free to write to the Open vSwitch
 278 discussion mailing list at ovs-discuss@openvswitch.org.