[ovs-discuss] OVN: availability zones concept
Daniel Alvarez Sanchez
dalvarez at redhat.com
Wed Mar 6 13:17:30 UTC 2019
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++
On Wed, Mar 6, 2019 at 11:27 AM Dan Sneddon <dsneddon at redhat.com> wrote:
> On Tue, Mar 5, 2019 at 9:40 PM Han Zhou <zhouhan at gmail.com> wrote:
>> On Tue, Mar 5, 2019 at 7:24 PM Ben Pfaff <blp at 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
>> 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:
>> Daniel or other folks please comment if there are other benefit of
>> creating zones.
> 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
> discuss at openvswitch.org
More information about the discuss