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

Reply via email to