On Thu, Feb 28, 2019 at 9:58 AM Daniel Alvarez Sanchez <dalva...@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 > disc...@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. Thanks, Han _______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
