Multiple ports for High Availability virtual-server

Feature requests
21

Sorry if I’m missing something here, but according to the keepalived man page:

A virtual_server can be a declaration of one of **<IPADDR> [<PORT>]** , **fwmark <INTEGER>** or **group <STRING>**

But the conf-node name, even if it may be an arbitrary string, will be transformed into keepalived.conf like this:

virtual_server {{ vserver }} {{ vserver_config.port }} {

The doc says keepalived expects an IP and optionally a port for this mode (and maybe you could use a name that resolves to an IP instead, but that is IMO a hack). Currently the config forces you to use an IP as the node name (and no port) if you don’t want to use fwmark. So we can only have one virtual-server for one IP even if keepalived accepts multiple IP:port servers. And yes, you can do multiple ports with fwmark, but not translate those to other port numbers afaik.

The way I see it there are some possible fixes:
Make the virtual-server node name arbitrary by definition and move address into the config object, alternatively in addition move port under the address node. Or use addr:port as the node name and deprecate the port node. Then when rendering the addr:port string, simply replace ':' by ' '.

set high-availability virtual-server my_first_server address 1.2.3.4 port 80
set high-availability virtual-server 1.2.3.4:80

is transformed into keepalived.conf:

virtual_server 1.2.3.4 80 { }

WIthout port number:

set high-availability virtual-server my_first_server address 1.2.3.4
set high-availability virtual-server 1.2.3.4

is transformed into keepalived.conf:

virtual_server 1.2.3.4 { }

or specify explicitly what type of virtual server we have

set high-availability virtual-server addr_port 1.2.3.4:80
set high-availability virtual-server fwmark 111
set high-availability virtual-server group my_group

(added the group option here even if it not currently supported).

alternatively, implicit type by parsing node names as ip:port, integer or string.

set high-availability virtual-server 1.2.3.4:80 real-server 5.6.7.8 port 8080
set high-availability virtual-server 111 real-server 5.6.7.8
set high-availability virtual-server my_group ...

No redundant arbitrary node names in these cases, perhaps add a description node instead.

22

From my point of view and some summary, it should be like this
(requires CLI migration)

set high-availability virtual-server my_first_server address 203.0.113.1
set high-availability virtual-server my_first_server port 80
set high-availability virtual-server my_first_server real-server 192.0.2.11 port '8881'
set high-availability virtual-server my_first_server real-server 192.0.2.12 port '8882'

set high-availability virtual-server my_second_server address 203.0.113.1
set high-availability virtual-server my_second_server port 443
set high-availability virtual-server my_second_server real-server 192.0.2.111 port '8883'
set high-availability virtual-server my_second_server real-server 192.0.2.112 port '8883'

That should be translated into a config.

# Vserver my_first_server
virtual_server 203.0.113.1 80 {
    delay_loop 10
    lb_algo sh
    lb_kind NAT
    persistence_timeout 180
    protocol TCP
    real_server 192.0.2.11 8881 {
        weight 1
        TCP_CHECK {
        }
    }
    real_server 192.0.2.12 8882 {
        weight 1
        TCP_CHECK {
        }
    }
}

# Vserver my_second_server
virtual_server 203.0.113.1 443 {
    delay_loop 10
    lb_algo sh
    lb_kind NAT
    persistence_timeout 180
    protocol TCP
    real_server 192.0.2.111 8883 {
        weight 1
        TCP_CHECK {
        }
    }
    real_server 192.0.2.112 8883 {
        weight 1
        TCP_CHECK {
        }
    }
}

Is it makes sense for your case?

I have created a feature request T5341

23

That should work nicely. Then I guess it’s necessary with some config validation, in case the user specifies both address, port and fwmark (and perhaps group some time in the future), since the mode is exclusive. Also, whether port should be allowed if fwmark is set.

My last examples of having the mode (either implicitly or explicitly) after the main node makes it impossible to enter invalid configuration and requires less validation logic since address, port and fwmark (and group) will be part of the path and can be removed from the config object altogether. Not having an arbitrary name as part of the path also enforces uniqueness of the virtual servers (not possible to declare identical virtual servers with different names)

That said, either option will work and for me it does not matter which gets chosen.

24

Will be available in the next rolling release.
Could you check it?