Я создаю проверочный балансировщик нагрузки с 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, которую система всегда будет отправлять, используя первичный адрес своего адаптера.