[ovs-discuss] OVN: availability zones concept

Lucas Alvares Gomes lucasagomes at gmail.com
Mon Mar 4 13:19:56 UTC 2019


On Sat, Mar 2, 2019 at 1:52 AM Han Zhou <zhouhan at gmail.com> wrote:
> On Thu, Feb 28, 2019 at 9:58 AM Daniel Alvarez Sanchez
> <dalvarez at redhat.com> wrote:
> >
> > Hi folks,
> >
> > Just wanted to throw an idea here about introducing availability zones
> > (AZ) concept in OVN and get implementation ideas. From a CMS
> > perspective, it makes sense to be able to implement some sort of
> > logical division of resources into failure domains to maximize their
> > availability.
> >
> > In this sense, establishing a full mesh of Geneve tunnels is not
> > needed (and possibly undesired when strict firewalls are used between
> > AZs) as L2 connectivity will be constrained to the AZ boundaries.
> >
> > A possibility would be to let the deployer of the CMS set a key on the
> > OpenvSwitch table of the local OVS instance like
> > 'external_ids:ovn_az=<int>' and if it's set, ovn-controller will
> > register itself as a Chassis with the same external ID and establish
> > tunnels to those Chassis within the same AZ, otherwise it'll keep the
> > current behavior.
> >
> > It'll be responsibility of the CMS to schedule gateway ports in the
> > right AZ as well to provide L3 AZ awareness.
> >
> > Does that make sense? Thoughts?
> >
> > Thanks a lot!!
> > Daniel
> > _______________________________________________
> > discuss mailing list
> > discuss at openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
> This sounds like a good idea to me. Just a concern for the name "AZ".
> The feature seems to be quite useful to optimize at scale when you
> know there are different groups of chassises (and gateways) would
> never need to communicate with each other. However, it doesn't sound
> like availability zone concept, since it is managed by a single
> control plane, which means they are not independently availability
> zones. I'd call it TZ (transport zone), or maybe just cell. However, I
> like the idea and it seems not hard to be implemented.

I agree with Han here, the idea is sound but the name seems a bit off.
I specially liked the "transport zone" (TZs) suggested by Han here. So
+1 to that name :D

Quick question. Should we have a default TZ for the chassis/gateways
that doesn't have that key set ? For example, if we have 9 chassis
where three of them have the TZ key set to 1, three others setting TZ
to 2 and remainder three left with no TZ key set. That should result
in 3 different zones right ? I wanna clarify that because I don't
think we should create a mash with all Chassis for those who doesn't
have the TZ set, instead, if it's omitted ovn-controller could
consider them to be part of a "default" TZ of some sort.

What you think ? Is that aligned with your idea ?


More information about the discuss mailing list