☰

Keepalived：内部网络的 NAT VIP 未使用吗？

tag-icon • tag-icon linux redhat keepalived load-balance
Keepalived：内部网络的 NAT VIP 未使用吗？

我正在使用 CentOS 7 和 keepalived 构建概念验证负载均衡器。

我参考了 Red Hat 的负载均衡器管理指南，实现了一个带有 2 个节点的 NAT 负载均衡器，用于在公网和私网之间传输流量。为此，负载均衡器有 2 个 VIP：一个用于客户端流量，位于公网；另一个用于确保响应流量的故障转移，位于私网。

2 个负载均衡器（lb1 和 lb2）正在向内部网络上运行 apache 的 2 个主机（fe1 和 fe2）发送流量。lb1 是主主机，lb2 是备份主机。

示意图如下：

聚类图

负载均衡器正常工作，并且当其中一个控制器发生故障时按预期进行故障转移。

让我感到烦恼的是，真实服务器上的传入流量不是来自内部 VIP（10.10.33.254），而是来自负载均衡器主机的真实地址（10.10.33.2 和 10.10.33.3）。尽管内部 VIP 被设置为真实服务器的默认网关，但真实服务器的 Ping 也通过真实 IP 地址，而不是内部 VIP。

跟踪路由（lb1 为活动状态）：

[root@rsfe2 ~]# tracepath www.google.com
1:  rsfe2                                                 0.081ms pmtu 1500
1:  10.10.33.2                                            0.385ms 
1:  10.10.33.2                                            0.385ms 
2:  no reply
3:  192.168.1.1                                           1.552ms

（lb1 向下，lb2 处于活动状态）：

[root@rsfe2 ~]# tracepath www.google.com
1:  rsfe2                                                 0.065ms pmtu 1500
1:  10.10.33.3                                            0.463ms 
1:  10.10.33.3                                            0.462ms 
2:  no reply
3:  192.168.1.1                                           2.394ms

路由表：

[root@rsfe2 ~]# ip route
default via 10.10.33.254 dev enp0s8  proto static  metric 1024 
10.10.33.0/24 dev enp0s8  proto kernel  scope link  src 10.10.33.12

尽管存在这种明显的异常，从客户端的角度来看，从一个负载均衡器到另一个负载均衡器的故障转移按预期进行，这似乎是由于来自幸存的负载均衡器的免费 ARP。

看起来内部 VIP 除了用于 ARP 公告之外没有用于任何其他用途（最终没有往返于它的流量）。

我应该担心这个吗，或者它是否按预期工作？

我的keepalived.conf内容：

global_defs {
    notification_email {
        [email protected]
        [email protected]
        [email protected]
    }
    notification_email_from [email protected]
    router_id LVS_DEVEL
}

vrrp_sync_group VG1 {
    group {
        RH_EXT
        RH_INT
    }
}

vrrp_script check_haproxy {
    script "/bin/pkill -0 -F /var/run/haproxy.pid"
    interval 1
    fall 1
    rise 5
}

vrrp_instance RH_EXT {
    state MASTER
    interface enp0s3
    virtual_router_id 50
    priority 101
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass password123
    }
    virtual_ipaddress {
        192.168.10.80
    }

    track_script {
        check_haproxy
    }

    track_interface {
        enp0s3
    }
}

vrrp_instance RH_INT {
    state MASTER
    interface enp0s8
    virtual_router_id 2
    priority 101
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass password123
    }

    virtual_ipaddress {
        10.10.33.254
    }

    track_script {
        check_haproxy
    }

    track_interface {
        enp0s8
    }
}

virtual_server 192.168.10.80 80 {
    lb_algo rr
    lb_kind NAT

    real_server 10.10.33.11 80 {
        HTTP_GET {
                url {
            path /check.html
        }
        }
    }
    real_server 10.10.33.12 80 {
        HTTP_GET {
                url {
            path /check.html
        }
        }
    }
}

答案1

我相当确定您在这种情况下确实在使用 VIP。您看到本机 IP 的原因仅仅是由于 traceroute 的性质。每个跳跃都设计为让设备生成 ICMP 错误，系统将始终使用其适配器的主地址发送该错误。

答案2

我认为你应该尝试从外部网络输入 VIP 进行复查，我认为配置没有问题。你在 traceroute 中看到 IP 的原因在于它的性质。

相关内容