Hello,
While I'm configuring my 2 routers in master/backup configuration for my
home gateway, I am wondering what if I add some more routers to the cluster.
TL;DR: How do a backup node know which node is master?
My concern is about the routing alteration for the backup nodes. Indeed,
even if they are backup, it's preferable in some cases that they still
can access to the internet (for syspatch, package upgrade for instance).
So after reading some literature on various blogs and sites (for
instance this[0], which was originally about using DHCP with 2 nodes),
the idea is to let ifstated alter routes when the carp interface state
changes and use the master node as a gateway.
So let's say that the nodes have an IP address 192.168.0.254 on a carp
interface carp1 to the LAN, plus a IP address 192.168.0.X on the
physical interface.
With 2 nodes, this is easy. If you're backup, then you know exactly who
is master and you can alter your default route to the IP address of the
master 192.168.0.X (because of course, it would be pointless for a
backup node to try to reach 192.168.0.254).
With 3 or more nodes, this becomes a bit of a challenge, because you
can't hardcode the identity of the master. For instance, if we have 3
nodes, with node1 being initially master, if the master role goes from
node1 to node2 for some reason, I don't know a way for node3 to know
about this by only using carp properties. We can imagine solutions that
I will explain, but I find them quite ugly and disproportionate for that
only purpose and I'm not sure if they are safe to use in production or not.
So the main question: is there a (simple) way for a carp member to be
notified when the master role switches to another node?
Solution 1: Deploy a script which triggers, when the node becomes
master, a broadcast of the node name or whatever useful piece of
identity. Also deploy a script that listens to those broadcast messages.
This wouldn't be such a pain do create and ifstated would be really
useful for that. But to cover the case of a node being added to the
cluster, the nodes should also broadcast at add time a request to get
the information. This begins to be a bit complex and adds a lot of
corner cases that I'm afraid to manage.
Solution 2: When a node become backup, instead of adding only one
default route, add multiple default route on multipath. I'm not used to
handle mutipath mechanism so I'm not even sure that would work the way I
want.
Solution 3: This one is fun. In addition of configuring carp1 which
regroups all nodes, configure one carp for each subset of nodes
containing all nodes but one. For instance, with 3 nodes :
- carp101 (192.168.0.101) defined on node2 and node3
- carp102 (192.168.0.102) defined on node1 and node3
- carp103 (192.168.0.103) defined on node1 and node2
So in backup mode, node1 gateway becomes 192.168.0.101, node2 gateway
becomes 192.168.0.102 and node3 gateway becomes 192.168.0.103. I'm
afraid that this solution creates too much network disturbance with a
high number of nodes.
These are the only solution that came to my mind.
What solution do you think is best (including some I didn't think about)?
Thanks for reading.
Guy
[0]: https://sites.google.com/site/bsdstuff/dhcarp
