Назад | Перейти на главную страницу

Keepalived: NAT VIP для внутренней сети не используется?

Я создаю проверочный балансировщик нагрузки с CentOS 7 и keepalived.

Я взял руководство по администрированию балансировщика нагрузки Red Hat в качестве справочника и реализовал балансировщик нагрузки с NAT с двумя узлами, который передает трафик между общедоступной и частной сетями. Для этого балансировщик нагрузки имеет 2 виртуальных IP-адреса: один для клиентского трафика в общедоступной сети; и один для обеспечения аварийного переключения для ответного трафика в частной сети.

2 балансировщика нагрузки (lb1 и lb2) отправляют трафик на 2 хоста, на которых запущен apache (fe1 и fe2) во внутренней сети. lb1 - главный, lb2 - резервный.

Схема выглядит следующим образом:

Балансировщик нагрузки работает и отключается, как и ожидалось, когда один из директоров выходит из строя.

Что меня беспокоит, так это то, что входящий трафик на реальных серверах исходит не с внутреннего VIP (10.10.33.254), а с реальных адресов хостов балансировщика нагрузки (10.10.33.2 и 10.10.33.3). Пинг с реальных серверов также проходит через реальные IP-адреса, а не через внутренний VIP, несмотря на то, что он установлен для них в качестве шлюза по умолчанию.

Traceroute (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 

(фунт1 ниже, фунт2 активен):

[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 {
        acassen@firewall.loc
        failover@firewall.loc
        sysadmin@firewall.loc
    }
    notification_email_from Alexandre.Cassen@firewall.loc
    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
        }
        }
    }
}

Я думаю, вам следует попробовать ввод из внешней сети в VIP для перепроверки, я вижу, что с конфигурацией все в порядке. Причина, по которой вы видите IP-адрес в traceroute, связана с его характером.

Я почти уверен, что в этом случае вы действительно используете VIP. Причина, по которой вы видите собственный IP-адрес, просто связана с характером traceroute. Каждый переход разработан таким образом, чтобы устройство генерировало ошибку ICMP, которую система всегда будет отправлять, используя первичный адрес своего адаптера.