Layer 2 based anycast - Kind like GLBP - Research

Thu Jul 1 18:04:17 UTC 2021

I'm looking for solutions do deploy some type of selective high
availability and load balance based on the glue between Layer 2 and Layer 3
(ARP or ND).

And I'm coming here to ask help to avoid reinventing the wheel.

I know VRRP / Heartbeat, and their downside is the Active/Passive
characteristic.
 -> But this project demands something that allows-me to have Active/Active
deployments.
I know GLBP, and it almost fits on the needed requirements.
 -> Except by his load-balancing methods that do not allow-me define
priority and affinity between server nodes and clients.

The basic ideia is something like Cisco GLBP with steroids:
 - Multiple server nodes of same service running on a common bus and
answering the "L2 anycast requests" of the clients that are on the same bus
and same subnet.
 - Some type of signaling between the multiple nodes making known the
status of the other nodes, their load. Maybe complementary information like
"which node is serving which client?"
 - Resource Pools and Client Pools, and the crossing between then based on
priorities and affinities (Here is the Gotcha!).
    - I want to be able to say "Node X will priorly serve clients A, E, G,
and T. Node Y will serve priorly clients B, C D, F. And node Z will server
everyone else."

Answering suggestions in advance:
(I discussed that with some friends and based on those talks I will try to
predict some suggestions that we already considered.)
- No, unfortunately tradicional L3 anycast will not fit on the
requirements. Servers and clients to be at the same bus, on the same
subnet. No L3 hops between then.
- No, the use of some type of connection broker in L2 does not satisfy one
of the requirements. Beyond the load balance, that this approach will
address, the high availability in case on L2 segregation is also needed.

My v0 draft of idea was using GLBP, and L2 Firewall rules dynamically
adjusted, based on the Master-Status, to allow and block L2
communications between each of those nodes and lists of client pools.
(Actually, I'm coming back to this idea again... Since I still don't have
any other better idea until now.)

I friend Suggested that EVPN could help-me, but I must confess that is a
hard topic to me.
Unless it can be used depending exclusively on software (no special
hardware required), it won't fit.

--
Douglas Fernando Fischer
Engº de Controle e Automação
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210701/7152dd8c/attachment.html>