On Mon, Mar 4, 2019 at 5:34 AM Lucas Alvares Gomes <[email protected]> wrote:
> Hi, > > On Sat, Mar 2, 2019 at 1:52 AM Han Zhou <[email protected]> wrote: > > > > On Thu, Feb 28, 2019 at 9:58 AM Daniel Alvarez Sanchez > > <[email protected]> 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 > > > [email protected] > > > 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 ? > > Cheers, > Lucas > Hello, I'm chiming in here because I think Daniel was prompted to start this thread based on a related feature request that I made against the OpenStack OVN component. Transport Zones is a better name for this feature in my opinion, and that is incidentally the name for this feature in VMWare NSX-T. As far as I can tell, they are not claiming it to be a trademark, and it's a fairly generic term. Having a default transport zone makes a lot of sense to me if we consider the introduction of transport zones into an existing environment. If existing chassis are not assigned to any transport zone, I think to most users it would be expected behavior that chassis assigned to a new transport zone would be separate. However, treating the default TZ as a separate TZ doesn't address a central hub-and-spoke network where each chassis forms tunnels to other chassis in the same TZ, and also forms tunnels with nodes at the central site, but doesn't form tunnels with chassis in other specific TZs. In this alternative, a chassis without a TZ forms tunnels with all other chassis. A chassis with a specific TZ forms tunnels within that TZ and with chassis with no TZ specified. That allows network functions such as gateways to be centralized for all TZs. Perhaps an ideal solution would allow a chassis to be a member of more than one TZ? That would allow flexibility, but may be more difficult to implement. -- Dan Sneddon
_______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
