Keepalived: многоадресная и одноадресная рассылка
Я планирую развернуть несколько keepalived маршрутизаторы для поддержки плавающих IP-адресов для различных кластеров базы данных. План состоит в том, чтобы развернуть отдельный VRRP instance на каждом кластере локально в соответствии с этим руководством, поэтому будет только два VRRP маршрутизаторы / экземпляры на каждом кластере.
keepalived пакет, доступный из репозитория CentOS 6x, является 1.2.7, и кажется, что одноадресная передача не была частью основного keepalived кодовая база до версии 1.2.8.
Q1. Интересно, умножится ли VRRP маршрутизаторы могут заполнять сеть многоадресной рекламой и вызывать проблемы с производительностью? Вы бы порекомендовали использовать одноадресную передачу в этом случае? Однако я заметил следующее предупреждение, относящееся к одноадресной передаче ( Ref.):
vrrp: отключить проверку работоспособности TTL для варианта использования одноадресной рассылки. Для защиты от любого внедрения пакета VRRP обеспечивает проверку работоспособности через заголовок IP TTL. Этот TTL ДОЛЖЕН быть равен 255 и означает, что отправитель и получатель подключены к одному и тому же сегменту Ethernet. Теперь с расширением одноадресной передачи эта защита ДОЛЖНА быть отключена, так как реклама VRRP будет в основном проходить через разные сегменты сети.!!! ВНИМАНИЕ!!! При использовании VRRP в случае использования одноадресной рассылки для защиты от внедрения любых пакетов рекомендуется использовать метод аутентификации IPSEC-AH, в противном случае вы будете подвержены потенциальным злоумышленникам!
Q2. Почему другие серверы в сети, которые не являются членами vrrp.mcast.net Группа многоадресной рассылки все еще получает рекламу VRRP?
# netstat -g
IPv6/IPv4 Group Memberships
Interface RefCnt Group
--------------- ------ ---------------------
lo 1 all-systems.mcast.net
eth0 1 all-systems.mcast.net
eth1 1 all-systems.mcast.net
lo 1 ff02::1
eth0 1 ff02::1:ff33:2440
eth0 1 ff02::1
eth1 1 ff02::1:ff90:4d5b
eth1 1 ff02::1
-
# tcpdump -i eth1 -c 2 host vrrp.mcast.net
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
20:30:46.241228 IP 172.16.0.70 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 3, prio 1, authtype simple, intvl 1s, length 20
20:30:47.241372 IP 172.16.0.70 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 3, prio 1, authtype simple, intvl 1s, length 20
2 packets captured
2 packets received by filter
0 packets dropped by kernel
Я думаю, что другой подход заключается в развертывании только одной пары VRRP маршрутизаторы и поддерживать VIP для всех кластеров БД.
1 ответ
Вопрос 1.Интересно, могут ли несколько маршрутизаторов VRRP наполнить сеть многоадресной рекламой и вызвать проблемы с производительностью? Порекомендуете ли вы использовать одноадресную рассылку в этом случае?
Никакое вменяемое количество VRRP-маршрутизаторов не должно вызывать проблем, даже если реклама выходит каждую секунду, это всего лишь один широковещательный пакет. Я бы не рекомендовал использовать одноадресную рассылку, поскольку она делает настройку VRRP более хрупкой, чем должна быть. Каждый раз, когда вам нужно перенастроить IP-адрес узла, вам придется обновлять конфигурацию других узлов, что может привести к простою. Тем не менее, я бы рекомендовал использовать IPSEC-AH даже в многоадресной среде, если вам не нужна совместимость с оборудованием, которое не поддерживает этот тип аутентификации (имейте в виду, что аутентификация PASS бесполезна с точки зрения безопасности, IPSEC-AH — единственная безопасная аутентификация). тип).
В2. Почему другие серверы в сети, не являющиеся членами группы многоадресной рассылки vrrp.mcast.net, по-прежнему получают рекламу VRRP?
Многоадресный трафик, попадающий в широковещательный домен (хосты, соседние с L2), передается на все интерфейсы, если только ваше сетевое оборудование не настроено на поддержку многоадресной рассылки и не учитывает запросы IGMP от ваших узлов. Часто по умолчанию сетевое оборудование не выполняет отслеживание IGMP и, следовательно, просто передает весь многоадресный трафик. Учитывая, что это всего лишь несколько пакетов в секунду, я бы не стал слишком волноваться. Принятие политики белого списка для вашего брандмауэра поможет вам изолировать нежелательный трафик, и с его помощью можно будет управлять VRRP/AH+VRRP/IGMPv3.