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

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

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

Keepalived config:

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.

1 ответ

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

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

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

Чтобы завершить это, вы должны иметь дело с проблемой ARP. Как правило, добавление

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

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

Другие вопросы по тегам