keepalived 没有检测到虚拟的丢失 IP
我用 keepalived 在两个虚拟机之间切换浮动IP地址。
在VM. 1:
在VM. 2:
它基本上工作正常,在一个例外:每次何时 systemd 更新 (它在控制下工作 Ubuntu 18.04), 它重新启动其网络组件,这导致删除浮动IP地址,因为它未在系统中配置。 自两份副本以来 keepalived 您仍然可以互相ping,它们都不会看到任何糟糕,并且它们都不会对它作出反应,因此浮动IP地址保持断开。
我发现您可以使用这样一个简单的脚本检查IP地址:
但我不确定这是一种工作方法。
如果我理解正确,如果在VM1上配置此脚本,则会发生以下情况:
VM1 失败 IP 由于重启 systemd
keepalived 在VM1上检测丢失 IP
Keepalived 开关
状态和停止广播数据包 vrrp
Keepalived 在 VM2 检测损失 keepalived 在 VM1 并安装浮动IP地址
在这一刻 IP 再次开放 VM2, 但 VM1 将留在这种状态,因为 IP 永远不会出现在 VM1. 如果一个 VM2 将不建造 (出于任何原因), VM1 因为她仍然存在,不会把她带走
状态。
如何保证浮动IP地址始终在其中一个虚拟机上处于活动状态?
进一步测试:
我试图放置浮动IP地址,而不是检查它是否在某个主机上处于活动状态 check_script:
在节点上设置此脚本 2 导致以下内容:
移动 IP 对比赛 1 供测试用
结 2 发现了一个损失 IP 并改变了它
到
结 1 忽略了国家的变化并保持了
结果: IP 它保持不变。
在节点上设置脚本 1 导致以下内容:
移动 IP 对比赛 1
结 1 发现了一个损失 IP 并改变了它
到
结 2 检测到节点上的状态的更改 1 并改变了S.
到
, 定制浮动 IP 对比赛 2
好吧 ...
我不得不重新开始 keepalived 在 node1, 停止在节点之间的ping pong中的游戏。
/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 个回复
奔跑吧少年
赞同来自:
https://github.com/acassen/keepalived/issues/836
.
一个较新的版本 keepalived 不可用的B. 18.04, 而不是试图备份,我们决定留下来 ubuntu 16.04 等到直到 ubuntu 20.04 对于我们的服务器使用 keepalived.
奔跑吧少年
赞同来自:
https://www.keepalived.org/changelog.html
删除监控 VIP / eVIP 并且转换到备份 VIP / eVIP 删除,通过配置跟踪选项解锁。
小姐请别说爱
赞同来自:
我没有一个系统,我可以轻松测试,获得它,所以 YMMV, 但
可能足以覆盖它。 否则状态检查
对于“活跃”以外的国家应该做到这一点。
顺便说一下,不应该用状态“备份”配置一个节点,而不是用作“master”?
窦买办
赞同来自:
/etc/netplan/01-netcfg.yaml
:
因此,在加载或重新配置时 systemd 浮动IP地址位于主节点上。 如果发生故障,它会通过辅助节点通过 keepalived. 如果主节点返回答案,则通过在辅助节点上支持活动来释放IP地址。
事实上,这不是一个解决方案,但我尚未更好地看到任何东西。
刷新
虽然这种解决方法工作,但他有一些副作用。 重新启动界面上存在的浮动IP地址两次:
它似乎受到任何工作的影响,但它担心我。 结果,我得到了
https://serverfault.com/a/956219/38644
并重新安装虚拟机 Ubuntu 16.04.
</broadcast,multicast,up,lower_up>
裸奔
赞同来自:
你 IP wr
把它放在 cronjob, 从每分钟开始或 5 分钟