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

Keepalived + LVS не работает с других хостов, но работает с localhost на LB

У меня установлен keepalived + LVS Я пытаюсь приступить к работе

Клиенты, LB и реальные серверы находятся в одной подсети.

Конфигурация Keepalived:

global_defs {
    notification_email {
        admin@example.com
    }
    notification_email_from admin@example.com
    smtp_server 127.0.0.1
    smtp_connect_timeout 30
    router_id ukld5p500x
}

vrrp_instance some_service {
    state             MASTER
    interface         em1
    virtual_router_id 100
    priority          100
    virtual_ipaddress {
        10.0.0.75
    }

    track_script {
        chk_fail
    }
}

virtual_server 10.0.0.75 58563 {
    delay_loop      10
    lb_algo     rr
    lb_kind     DR

    protocol        TCP

    real_server 10.0.0.70 58563 {
        weight          1
        TCP_CHECK {
            connect_timeout 3   
            connect_port    58563
        }
    }

    ... more real_servers ...

}

Итак, если я установлю lb_type в nat, тогда я могу подключиться от самого LB к VIP / порту, и все будет проходить, но не с внешнего хоста (клиента). Если я установил lb_type на DR, то ни LB, подключающийся к самому себе, ни внешний клиент не смогут подключиться.

sys.net.ipv4.ip_forward установлен в 1, и есть только один настроенный атм LB.

Не знаю, ответили ли вы на этот вопрос с тех пор, как он очень старый, но DR (прямая маршрутизация) сильно отличается от NAT. NAT заставляет балансировщик нагрузки (LB) действовать как маршрутизатор, передавая пакет реальному серверу, а реальный сервер передает его обратно LB для доставки обратно клиенту.

С DR LB - всего лишь псевдопосредник. Когда пакет поступает на VIP, который есть у LB, он решает, на какой RS (настоящий сервер) его отправить, и переписывает заголовок пакета, изменив MAC-адрес. Затем он передает пакет обратно коммутатору, и коммутатор доставляет его RS с совпадающим MAC-адресом.

Затем вам нужно обманом заставить свой RS принять пакет, предназначенный для его интерфейса. Обычно это делается путем добавления VIP к адаптеру обратной связи и присвоения ему сетевой маски 255.255.255.255. Ваш сервисный демон также должен быть настроен для прослушивания этого VIP (в apache вы просто добавляете дополнительную строку Listen x.x.x.x: 80).

В довершение всего, вам нужно решить проблему ARP. Обычно добавление

net.ipv4.conf.eth0.arp_announce = 2
net.ipv4.conf.eth0.arp_ignore = 1

в ваш sysctl.conf позаботится об этом