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中的游戏。
已邀请:

奔跑吧少年

赞同来自:

我们遇到了这个问题,并决定这是一个问题 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 分钟

要回复问题请先登录注册