[ClusterLabs] [RFC] LoadSharingIP agent idea, xt_cluster/IPv6/nftables (Was: Support for xt_cluster)

[Jan Pokorný]

On 19/12/19 10:18 -0600, Ken Gaillot wrote:
> On Thu, 2019-12-19 at 15:01 +0000, Marcus Vinicius wrote:
>> Is there any intention to abandon CLUSTERIP
> 
> yes
> 
>>  in favor of xt_cluster.ko? 
> 
> no
> 
> :)
> 
> A recent thread about this:
> https://lists.clusterlabs.org/pipermail/users/2019-December/026663.html
> 
> resulted in a change to allow IPaddr2 clones to continue working on
> newer systems if "iptables-legacy" is available:
> https://github.com/ClusterLabs/resource-agents/pull/1439

Note also a closer look later in that thread:
https://lists.clusterlabs.org/pipermail/users/2019-December/026671.html

that eventually, on the side axis, led to an updated man page
(coming to iptables v1.8.5 or so):
https://git.netfilter.org/iptables/commit/?id=37ff0d667d346dd455e08f52a785685185f01b15

so there are no doubts about where this is headed, and shall call
for action where the risk is imminent, as also mentioned:

> tl;dr Cloned IPaddr2 is supported only on platforms that support
> CLUSTERIP, and can be considered deprecated since CLUSTERIP itself is
> deprecated. A pull request with an xt_cluster implementation would be
> very welcome, as it's a low priority for available developers.

Good news is that sinking the support for that in would be rather
non-intrusive from the operational perspective, since xt_cluster
(aliased also as ipt_cluster, for that matter) was around with
Linux kernels as old as 2.6.30[*1] -- of course, YMMV.

Another good news regarding possible future decline from
iptables/xtables as such in the face of nftables -- technology that
is itself around in the Linux kernel for ages, since Linux 3.13 in
particular[*2] -- slowly getting prefered, I think, is that you can
manually rewrite the respective firewall rules using xt_cluster
extension statically (hence right in the agent) even if you lack
iptables-legacy at those very cluster machines.
All you need is a side (not necessarily local) installation of
iptables with iptables-translate (comes with iptables-nft package
in a fairly recent Fedora) command working so that you can yield the
right incantation of the nft tool controlling said nftables,
see examples of that:
https://git.netfilter.org/iptables/tree/extensions/libxt_cluster.txlate?h=v1.8.4

Capturing generalizations of the intention-to-exact-recipe translation
logic in the agent itself would then be the best way to proceed, since
that way, no dependency on "transitional legacy stuff"
(read: unnecessary code cruft in the agent when supported in parallel)
would be needed, yay!

* * *

So, any takers? :-)

Of course, as discussed before, this overhaul would deserve a strict
separation of the function in question under a dedicated agent like
LoadSharingIP, letting the equivalent one in IPaddr2 agent and based
on something practically deprecated on arrival slowly die out.
Existing agent is pretty complex even without that semantically
overriding piggy-backing already -- no more gravity boosting like
that, please (not to speak of its naming that simply won't "click").

Also note there are missing puzzles regarding IPv6 support, still:
https://lists.clusterlabs.org/pipermail/users/2019-December/026710.html


[*1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0269ea4937343536ec7e85649932bc8c9686ea78
[*2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=96518518cc417bb0a8c80b9fb736202e28acdf96

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20200102/28c0ff82/attachment.sig>