[ovs-discuss] OVN: availability zones concept

Fri Mar 22 17:16:16 UTC 2019

On Fri, Mar 22, 2019 at 4:36 AM Daniel Alvarez <dalvarez at redhat.com> wrote:
>
>
>
>
> > On 22 Mar 2019, at 13:22, Lucas Alvares Gomes <lucasagomes at gmail.com> wrote:
> >
> > Hi,
> >
> > Getting back to this topic because we do have people (read clients)
> > interested in this work for their Telco/Edge computing uses cases as a
> > way to preventing each edge site to try to create tunnels with every
> > node on every site.
> >
> > Also, another request we saw which this feature would help is related
> > to security where people want to create "trust zones" and prevent
> > computes in a more secure zone to communicate with a less secure zone.
> >
> > As Dan Sneddon pointed out in this thread, it's possible to use
> > firewalls to workaround these problems but the approach is not ideal
> > (and may result in negative consequences) because each Chassis in OVN
> > will still try again and again to form the tunnel mesh with every
> > other Chassis but it will fail/timeout over and over.
> >
> > Regarding to the approach to implement this I see we have a couple
> > ideas floating around:
> >
> > 1. Explicit setting the transport zone(s) in the OpenVSwitch table for
> > the Chassis.
> >
> > 2. Dynamically creating tunnels between Chassis that are logically
> > connected with each other.
> >
> > 3. Creating the tunnels on demand when the first packet is going
> > to/from a Chassis (although Ben has stated that he is not pushing for
> > this).
> >
> > So, while every approach has their pos/cons, personally (and also by
> > talking to some work colleagues), I think that 1. is probably the
> > best/most straight forward way to go with this because since it's
> > explicit it is also the easiest to troubleshoot/monitor what's going
> > on with the network. The approach 2. and 3., while very interesting
> > from an engineering point of view, might not be so interesting for
> > folks responsible for monitoring the network because it leaves the
> > compute nodes in some "unknown" state (is there a tunnel between
> > Chassis A and B ? no/yes/not yet ?).

Lucas, I support you moving forward with 1), because:
a) it is more simple and straightforward, yet the configuration on
chassis won't (shouldn't) create compatibility issue
b) it doesn't conflict with further optimization with 2) or 3) on top
of it when needed in the future

P.S. Just a comment on the troubleshooting concerns. It seems to me 2)
doesn't necessarily increase difficulty of trouble-shooting: if lport
A and lport B cannot communicate, the first step to check should
always be making sure the logical datapath allows them to talk,
regardless of the approaches, and if the answer is yes, you know the
tunnel is expected between the chassises. For monitoring, tunnels do
not have states unless BFD is enabled (for GW HA), so maybe checking
on BFD failure status itself is sufficient.

> >
> > If there's no objection from people in this thread (specially Han and
> > Ben) I would be more than happy in helping implementing this feature.
> My vote doesn’t count much because that’s the approach I originally proposed in the first email of this thread but having thought about everything thrown here, I’m inclined to go ahead with it. It doesn’t do any harm if not used and brings the value we need for the commented use case.
>
> Thanks a lot Lucas for volunteering!
>
>
> >
> > Cheers,
> > Lucas
> >
> >> On Thu, Mar 7, 2019 at 6:54 PM Ben Pfaff <blp at ovn.org> wrote:
> >>
> >>> On Wed, Mar 06, 2019 at 10:32:29PM -0800, Han Zhou wrote:
> >>>> On Wed, Mar 6, 2019 at 9:06 AM Ben Pfaff <blp at ovn.org> wrote:
> >>>>
> >>>>> On Tue, Mar 05, 2019 at 09:39:37PM -0800, Han Zhou wrote:
> >>>>>> On Tue, Mar 5, 2019 at 7:24 PM Ben Pfaff <blp at ovn.org> wrote:
> >>>>>> What's the effective difference between an OVN deployment with 3 zones,
> >>>>>> and a collection of 3 OVN deployments?  Is it simply that the 3-zone
> >>>>>> deployment shares databases?  Is that a significant advantage?
> >>>>>
> >>>>> Hi Ben, based on the discussions there are two cases:
> >>>>>
> >>>>> For completely separated zones (no overlapping) v.s. separate OVN
> >>>>> deployments, the difference is that separate OVN deployments requires
> >>>>> some sort of federation at a higher layer, so that a single CMS can
> >>>>> operate multiple OVN deployments. Of course separate zones in same OVN
> >>>>> still requires changes in CMS to operate but the change may be smaller
> >>>>> in some cases.
> >>>>>
> >>>>> For overlapping zones v.s. separate OVN deployments, the difference is
> >>>>> more obvious. Separate OVN deployments doesn't allow overlapping.
> >>>>> Overlapping zones allows sharing gateways between different groups of
> >>>>> hypervisors.
> >>>>
> >>>> OK.  The difference is obvious in the case where there is overlap.
> >>>>
> >>>>> If the purpose is only reducing tunnel mesh size, I think it may be
> >>>>> better to avoid the zone concept but instead create tunnels (and bfd
> >>>>> sessions) on-demand, as discussed here:
> >>>>> https://mail.openvswitch.org/pipermail/ovs-discuss/2019-March/048281.html
> >>>>
> >>>> Except in cases where we have BFD sessions, it is possible to entirely
> >>>> avoid having explicitly defined tunnels, since the tunnels can be
> >>>> defined in the flow table.  The ovs-fields(7) manpage describes these
> >>>> under "flow-based tunnels" in the TUNNEL FIELDS section.  Naively, doing
> >>>> it this way would require, on each hypervisor, a few OpenFlow flows per
> >>>> remote chassis, as opposed to one port per remote chassis.  That
> >>>> probably scales better.  If necessary, it could be made to scale better
> >>>> than that by using send-to-controller actions to add flows for tunnels
> >>>> as packets arrive for them or as packets need to go through them.
> >>>
> >>> Thanks Ben for the pointer. I have to admit I was not aware of these
> >>> different ways of using tunnels. The documentation is very clear, and
> >>> now I understand what OVN currently uses is "Intermediate models",
> >>> i.e. partially flow-based - remote-ips are port based while keys are
> >>> flow based.
> >>
> >> Thanks for the documentation fixes!
> >>
> >>> While purely flow-based tunnel is attractive in terms of flexibility,
> >>> it seems not fit very well for OVN use case because we do need BFD
> >>> sessions.
> >>
> >> I think that OVN only uses BFD for a few of its ports--only for gateways
> >> with HA, right?  Those could continue to have ports.
> >>
> >>> For the "send-to-controller", i.e. reactively set up flows when
> >>> packets arrives, I hope it is not really needed for solving the tunnel
> >>> scaling problem, since it introduces data plane latency which could be
> >>> a bigger problem. (But I am not sure if reactive mode in general is a
> >>> good idea - it might be a reasonable trade-off for solving the scale
> >>> problem of each HV pre-installing flows for all related datapaths in a
> >>> full-mesh alike scenario. Anyway, not directly related to current
> >>> topic).
> >>
> >> It would introduce data plane latency for the first packet to go to or
> >> from a particular hypervisor.  After that there would be no further
> >> additional latency.  It would probably not be noticeable.
> >>
> >> Let me be clear that I am not pushing this solution.  It will complicate
> >> things, and I do not like unnecessary complication.  I am just pointing
> >> out that is possible.
> >>
> >>> So I would propose to keep the current partially flow-based tunnel
> >>> usage in OVN and optimize the tunnel setup only between peers that are
> >>> logically connected, if this satisfies the scaling goal of OVN users.
> >>> Even with this optimization, we may need to make it as a configurable
> >>> option, since in small scale use cases users may in practice prefer
> >>> the original behavior to avoid the latency of tunnel setup.
> >>
> >> OK.
> >> _______________________________________________
> >> discuss mailing list
> >> discuss at openvswitch.org
> >> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
> > _______________________________________________
> > discuss mailing list
> > discuss at openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
> _______________________________________________
> discuss mailing list
> discuss at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss