Re: [PATCH] netfilter: xtables: add cluster match

[Patrick McHardy <kaber@trash.net>]

Pablo Neira Ayuso wrote:
> Patrick McHardy wrote:
>>> A possible solution (that thinking it well, I don't like too much yet)
>>> would be to convert this to a HASHMARK target that will store the result
>>> of the hash in the skbuff mark, but the problem is that it would require
>>> a reserved space for hashmarks since they may clash with other
>>> user-defined marks.
>> That sounds a bit like a premature optimization. What I don't get
>> is why you don't simply set cluster-total-nodes to one when two
>> are down or remove the rule entirely.
> 
> Indeed, but in practise existing failover daemons (at least those
> free/opensource that I know) doesn't show that "intelligent" behaviour
> since they initially (according to the configuration file) assign the
> resources to each node, and if one node fails, it assigns the
> corresponding resources to another sane node (ie. the daemon runs a
> script with the corresponding iptables rules).
> 
> Re-adjusting cluster-total-nodes and cluster-local-nodes options (eg. if
> one cluster node goes down and there are only two nodes alive, change
> the rule-set to have only two nodes) seems indeed the natural way to go
> since the alive cluster nodes would share the workload that the failing
> node has left. However, as said, existing failover daemons only select
> one new master to recover what a failing node was doing, thus, only one
> runs the script to inject the states into the kernel.
> 
> Therefore AFAICS, without the /proc interface, I would need one iptables
> rule per cluster-local-node handled, and so it's still the possible
> sub-optimal situation when one or several node fails.

OK, that explains why you want to handle it this way. I don't want
to merge the proc file part though, so until the daemons get smarter,
people will have to use multiple rules.

BTW, I recently looked into TIPC, its incredibly easy to use since
it deals with dead-node dectection etc internally and all you need
to do is exchange a few messages. Might be quite easy to write a
smarter failover daemon.