MultiBird on L2 - A crazy idea for Fail Over y and Load Balancing

[Douglas Fischer]

Yep Ondrej!

This L2/L3 redundancy layer would not be addressed by the Bird itself...
Would be a solution composed by Bird(or even other Engines) and some other
tools.

I brought this suggestion here because I believe that here are the most
interested in this possible solution.


Perhaps one of the few things that could be done in Bird to help this
scalability solution is to add some support to Multi-Bird.

As it is done today, each instance of Bird does not even know that it is
part of a "cluster", so, for example, when making a query via API to know
information about Peers, it is necessary to make this query to several
servers, merge that data and then use that information.

Reminding that this optimization would serve both models "connection
forwarded in the same box" and "distributed in L2/L3".

Em ter., 19 de jan. de 2021 às 18:35, Ondrej Zajicek <santiago at crfreenet.org>
escreveu:

> On Tue, Jan 19, 2021 at 09:17:57AM -0300, Douglas Fischer wrote:
> > I was studying the concepts of multi-bird for large environments of IXPs.
> >
> > And, beyond the extra complexity that it brings to the environment, one
> of
> > the weak points I saw was the fact that all the Bird instances are at the
> > same box(vm, container, etc...).
> >
> > A friend mentioned that some tests were made with a LoadBalancer
> > redirecting the post-nated connections to other boxes.
> > But even in that scenario, that load balancer would be a
> > single-point-of-failure/bottleneck.
> >
> > So I was remembering Cisco GLBP and Heart-Beat protocol.
> > Those protocols inform different Mac-Addresses to the same IPv4/IPv6
> > Address, based on the source of the ARP/ND query.
> > Making a load-balance/fail-over based on the glue between layer2 and
> layer3.
> > P.S.: Several scenarios uses that concept. Corosync, Windows Cluster,
> Orale
> > RAC, etc...
> >
> > Considering that concept, and joining it with multibird:
> >  Would be possible to create groups of sources and assigning different
> > priorities to those groups on each instance of Bird.
> >  In this case, each Bird instance could run on a different box, or even
> on
> > a different site.
>
> Hi
>
> That is an interesting idea. Seems like it is something that could be
> done outside of BIRD, just by firewall tricks with ARP (at least with
> static balancing). Perhaps something as simple as dropping ARP requests
> (on each route server) from clients outside of allowed subset of clients.
>
> But personally, if i had to run multiple multi-BIRD  setup on multiple
> servers, i would just assign them different IPs and announce the
> appropriate server IP to each group of users (instead of trying to
> pretend it is one IP / one server). It can be even done preemptively -
> have one RS IP for each say 64 clients, and then assign multiple IPs
> to real route servers according to needs and resources.
>
> --
> Elen sila lumenn' omentielvo
>
> Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
> OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
> "To err is human -- to blame it on a computer is even more so."
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20210122/5f3ef824/attachment.htm>