Thanks Dan for chiming in and others as well for your feedback! I also thought of having separate OVN deployments but that introduces the drawbacks that Han pointed out adding - maybe a lot of - burden to the CMS. Separate zones in the same OVN deployment will add minimal changes (at deployment size to define the zones and when selecting the nodes to schedule a gateway are the only ones I can think of).
For the particular case of OpenStack, the overlapping TZs won't be of much help I guess as there's no notion of overlapping failure domains. However, if you see value for OVN itself or other CMS's, I think it's not too expensive to have (I'm possibly being naive here). That said, I think that Han's suggestion of establishing tunnels dynamically is *great*! It will improve scalability and will be more efficient generally (even if OpenStack is not using Availability Zones), reducing traffic and processing and avoiding deployer/ops to configure each node. The Transport/Availability zone concept will be then implemented at the CMS layer which makes sense to me (in the OpenStack case, just scheduling gateways). Only concern, as Han said, would be the latency between the time the port gets bound and it becomes available from other hypervisors (especially in the case of the encrypted tunnels). If we could have some figures before making the decision, it'd be great but my vote goes for this approach :) Han++ Thanks all, Daniel On Wed, Mar 6, 2019 at 11:27 AM Dan Sneddon <dsned...@redhat.com> wrote: > > > > On Tue, Mar 5, 2019 at 9:40 PM Han Zhou <zhou...@gmail.com> wrote: >> >> On Tue, Mar 5, 2019 at 7:24 PM Ben Pfaff <b...@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. >> >> 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 >> >> Daniel or other folks please comment if there are other benefit of >> creating zones. >> >> Thanks, >> Han > > > The original discussion came about when I was consulting with a very large > bank who were considering network designs for an application cloud. In that > case, all chassis were in a single site, and the desire was to be able to > separate groups of chassis into trust zones with no East-West communication > between zones. Of course this same result can be handled via network > segregation and firewalling, but zones would provide an additional layer of > security enforcement. In their case, the choice due to policy was to have > separate flow controllers and software routers in each zone rather than rely > on firewalls alone, but this increased the hardware footprint. > > When I discovered that there was no way to prevent tunnels from being formed > between all chassis, that became an obvious problem for edge scenarios. To me > that is the more pressing issue, which dynamic tunnels would solve. However, > the ability to have separate transit zones would also be a useful feature, in > my opinion. > > -- > Dan Sneddon > _______________________________________________ > discuss mailing list > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss _______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
