keepalived

keepalived 没有检测到虚拟的丢失 IP

我用 keepalived 在两个虚拟机之间切换浮动IP地址。



        /etc/keepalived/keepalived.conf

在VM. 1:

vrrp_instance VI_1 {

        state MASTER

        interface ens160

        virtual_router_id 101

        priority 150

        advert_int 1

        authentication {

                auth_type PASS

                auth_pass secret

        }

        virtual_ipaddress {

                1.2.3.4

        }

}



        /etc/keepalived/keepalived.conf

在VM. 2:

vrrp_instance VI_1 {

        state MASTER

        interface ens160

        virtual_router_id 101

        priority 100

        advert_int 1

        authentication {

                auth_type PASS

                auth_pass secret

        }

        virtual_ipaddress {

                1.2.3.4

        }

}

它基本上工作正常，在一个例外：每次何时 systemd 更新 (它在控制下工作 Ubuntu 18.04), 它重新启动其网络组件，这导致删除浮动IP地址，因为它未在系统中配置。自两份副本以来 keepalived 您仍然可以互相ping，它们都不会看到任何糟糕，并且它们都不会对它作出反应，因此浮动IP地址保持断开。

我发现您可以使用这样一个简单的脚本检查IP地址：

vrrp_script chk_proxyip {

        script "/sbin/ip addr |/bin/grep 1.2.3.4"

}



vrrp_instance VI_1 {

        # [...]

        track_script {

                chk_proxyip

        }

}

但我不确定这是一种工作方法。

如果我理解正确，如果在VM1上配置此脚本，则会发生以下情况：

VM1 失败 IP 由于重启 systemd

keepalived 在VM1上检测丢失 IP

Keepalived 开关



          FAULT

状态和停止广播数据包 vrrp

Keepalived 在 VM2 检测损失 keepalived 在 VM1 并安装浮动IP地址

在这一刻 IP 再次开放 VM2, 但 VM1 将留在这种状态，因为 IP 永远不会出现在 VM1. 如果一个 VM2 将不建造 (出于任何原因), VM1 因为她仍然存在，不会把她带走



        FAULT

状态。

如何保证浮动IP地址始终在其中一个虚拟机上处于活动状态？

进一步测试：

我试图放置浮动IP地址，而不是检查它是否在某个主机上处于活动状态 check_script:

vrrp_script chk_proxyip {

        script "/bin/ping -c 1 -w 1 1.2.3.4"

        interval 2

}

在节点上设置此脚本 2 导致以下内容：

移动 IP 对比赛 1 供测试用

结 2 发现了一个损失 IP 并改变了它



          BACKUP

到



          FAULT

结 1 忽略了国家的变化并保持了



          MASTER

结果： IP 它保持不变。

在节点上设置脚本 1 导致以下内容：

移动 IP 对比赛 1

结 1 发现了一个损失 IP 并改变了它



          MASTER

到



          FAULT

结 2 检测到节点上的状态的更改 1 并改变了S.



          BACKUP

到



          MASTER

, 定制浮动 IP 对比赛 2

好吧 ...

Feb 13 10:11:26 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Transition to MASTER STATE

Feb 13 10:11:27 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering MASTER STATE

Feb 13 10:11:29 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Received advert with higher priority 150, ours 100

Feb 13 10:11:29 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering BACKUP STATE

Feb 13 10:11:32 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Transition to MASTER STATE

Feb 13 10:11:33 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering MASTER STATE

Feb 13 10:11:36 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Received advert with higher priority 150, ours 100

Feb 13 10:11:36 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering BACKUP STATE

Feb 13 10:11:38 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Transition to MASTER STATE

Feb 13 10:11:39 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering MASTER STATE

Feb 13 10:11:41 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Received advert with higher priority 150, ours 100

Feb 13 10:11:41 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering BACKUP STATE

Feb 13 10:11:44 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Transition to MASTER STATE

Feb 13 10:11:45 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering MASTER STATE

Feb 13 10:11:47 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Received advert with higher priority 150, ours 100

...

我不得不重新开始 keepalived 在 node1, 停止在节点之间的ping pong中的游戏。

已邀请:

5 个回复

奔跑吧少年

赞同来自:

我们遇到了这个问题，并决定这是一个问题 systemd-networkd 在 ubuntu 18.04, 现在使用它 netplan. 一个较新的版本 keepalived 它应该解决它，因为它可以检测到删除浮动IP地址，导致紧急切换，参见
https://github.com/acassen/keepalived/issues/836
.

一个较新的版本 keepalived 不可用的B. 18.04, 而不是试图备份，我们决定留下来 ubuntu 16.04 等到直到 ubuntu 20.04 对于我们的服务器使用 keepalived.

奔跑吧少年

赞同来自:

这个问题是固定的 keepalived 2.0.0 经过 26.05.2018, 厘米。
https://www.keepalived.org/changelog.html

删除监控 VIP / eVIP 并且转换到备份 VIP / eVIP 删除，通过配置跟踪选项解锁。

小姐请别说爱

赞同来自:

我认为你的共享方法很好，但你需要重新考虑测试条件。困扰你的状态是重启是否 systemd 网络基础设施 (无论您是谁的间接后果 VIP), 所以这就是你需要检查的东西。

我没有一个系统，我可以轻松测试，获得它，所以 YMMV, 但



          systemctl is-active network.service

可能足以覆盖它。否则状态检查



          systemctl show network.service | grep 'ActiveState'

对于“活跃”以外的国家应该做到这一点。

顺便说一下，不应该用状态“备份”配置一个节点，而不是用作“master”？

窦买办

赞同来自:

作为解决方法，我将浮动IP地址配置为主节点上的可选IP地址。 (优先级更高)

/etc/netplan/01-netcfg.yaml

:

network:

    version: 2

    renderer: networkd

    ethernets:

        ens160:

            addresses: [ 1.2.3.5/24, 1.2.3.4/24 ]

            gateway4: 1.2.3.254

            nameservers:

                    search: [ example.com ]

                    addresses:

                            - "1.2.3.40"

因此，在加载或重新配置时 systemd 浮动IP地址位于主节点上。如果发生故障，它会通过辅助节点通过 keepalived. 如果主节点返回答案，则通过在辅助节点上支持活动来释放IP地址。

事实上，这不是一个解决方案，但我尚未更好地看到任何东西。

刷新

虽然这种解决方法工作，但他有一些副作用。重新启动界面上存在的浮动IP地址两次：

2: ens160: <broadcast,multicast,up,lower_up> mtu 1500 qdisc fq_codel state UP group default qlen 1000

        link/ether 00:50:56:a3:d7:d1 brd ff:ff:ff:ff:ff:ff

        inet 1.2.3.5/24 brd 1.2.3.255 scope global ens160

              valid_lft forever preferred_lft forever

        inet 1.2.3.4/32 scope global ens160

              valid_lft forever preferred_lft forever

        inet 1.2.3.4/24 brd 1.2.3.255 scope global secondary ens160

              valid_lft forever preferred_lft forever

它似乎受到任何工作的影响，但它担心我。结果，我得到了
https://serverfault.com/a/956219/38644
并重新安装虚拟机 Ubuntu 16.04.
</broadcast,multicast,up,lower_up>

裸奔

赞同来自:

我想你可以检查 ping 在浮动IP地址，然后在失败时，重新启动服务 keepalived 在所有节点上

你 IP wr

把它放在 cronjob, 从每分钟开始或 5 分钟

要回复问题请先登录或注册

keepalived 没有检测到虚拟的丢失 IP

5 个回复

发起人

相关问题

问题状态

keepalived 没有检测到虚拟的丢失 IP

与内容相关的链接

5 个回复

发起人

相关问题

问题状态