Вопросы Теги

Что-то вроде VRRP/keepalived без влияния MAC-адреса? (RHEL 8) [закрыто]

Я хочу настроить кластер (из двух систем) с VIP, как это делает keepalived. В другом контексте, у меня уже есть keepalived, который хорошо работает. Однако наша сетевая команда сказала мне не вводить никаких новых MAC-адресов VRRP, поскольку это может конфликтовать с некоторыми из их собственных конфигураций VRRP.

Я также не хочу добавлять обратный прокси для этой цели. Наличие единой точки отказа, подобной этой, уничтожит цель создания VIP в первую очередь.

Есть ли способ настроить keepalived на использование конструкций уровня 3 или другой инструмент, который делал бы то же самое, не спускаясь на уровень 2?

Я понимаю, что одной из причин виртуального MAC-адреса является разрешение ARP. Кратковременные перебои в работе из-за смены MAC-адресов были бы нежелательны, но допустимы в моем сценарии.

0
задан 5 June 2021 в 02:41
1 ответ

Примеры ниже предполагают IPv4, с конфигурацией, подобной базовому примеру Red Hat здесь: узел с адресом 192.168.122.101/24, другой с адресом 192.168.122.102/24, используя VRRP instance VI_1 и VRRP VIP 192.168.122.200/24.

Это уже не будет соответствовать VRRP, потому что RFC 5798 говорит об использовании MAC-адреса VRRP в ответах ARP.

В любом случае, вы можете настроить keepalived, чтобы соответствовать политике, установленной вашей сетевой командой.

  • не используйте опцию use_vmac в конфигурации экземпляра VRRP

    чтобы предотвратить использование source Virtual Router MAC адресов типа 00:00:5E:00:01:XX.

    • можно просто удалить опцию use_vmac,

      Клиенты не будут иметь больших проблем после failover, потому что каждый раз, когда узел keepalived становится master для VRRP адреса, он начинает с объявления своего (VIP) адреса с помощью 5 DAD ARP запросов для беспричинных ARP запросов (pacemaker/corosync ведет себя так же в этом отношении), и сделает это снова 10s позже. Захват объявления изменится, например, с:

      00:00:5e:00:01:33 > ff:ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), длина 42: Request who-has 192.168.122.200 (ff:ff:ff:ff:ff:ff:ff) tell 192.168.122.200, длина 28

      to:

      56:24:20:bf:2a:37 > ff:ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.122.200 (ff:ff:ff:ff:ff:ff:ff:ff) tell 192.168.122.200, length 28

      Таким образом, вместо того, чтобы коммутатор(ы) заметил(и), что другой порт должен использоваться для достижения того же MAC адреса и обновил(и) свою базу данных пересылки, IPv4 клиенты заметят, что другой MAC адрес должен использоваться для достижения того же IPv4 адреса и обновят свои ARP таблицы.

    • или, если это действительно необходимо, замените его на use_ipvlan (ценой двух дополнительных IPv4-адресов!),

      для того же эффекта (и точно такого же перехвата по проводу, как в последнем примере выше).

      Это может понадобиться только в том случае, если конфигурация кластера опирается на дополнительный виртуальный интерфейс, созданный keepalived на каждом узле, и необходимо избежать тщательной реконфигурации. Интерфейс ipvlan ведет себя так же, как интерфейс macvlan, за исключением того, что он будет использовать MAC-адрес из своего родительского интерфейса (и внутренне обрабатывает, как IP-пакеты должны быть мультиплексированы на нужный интерфейс).

      На IPv4 эта опция требует использования дополнительного IPv4 адреса на ней. Этот адрес не должен быть адресом VRRP и не должен быть IP-адресом родительского интерфейса (иначе могут возникнуть проблемы с маршрутизацией), поэтому если он находится на том же интерфейсе/LAN, что и конфигурация сети системы, кластеру из 2 узлов теперь, вероятно, потребуется 5 адресов вместо 3: два исходных адреса, определенных системой, 2 дополнительных ipvlan адреса и адрес VRRP.

      Например, один сервер будет использовать в дополнение к своему оригинальному адресу 192.168.122.101, настроенному системой: 

      use_ipvlan vip0 192.168.122.103

      а другой в дополнение к своему 192.168.122.102:

      use_ipvlan vip0 192.168.122.104

      Я бы избегал этого варианта, если бы у меня был выбор.

  • использовать unicast_peer блок

    для предотвращения использования IPv4 VRRP многоадресного адреса 224.0.0.18 и соответствующего destination VRRP MAC многоадресного адреса 01:00:5E:00:00:12.

    Это также требует отключения strict_mode, если он установлен (или если vrrp_strict установлен в блоке global_defs), и не поддерживает use_ipvlan, описанный выше (ни use_vmac). check_unicast_src также может быть включен для защиты от ошибки конфигурации третьей системы, а не для какой-либо безопасности.

    Например, узел с адресом 192.168.122.101 может использовать:

    vrrp_instance VI_1 {
 ...
 strict_mode off
 check_unicast_src
 unicast_peer {
 192.168.122.102
 }
}

    и узел с 192.168.200.102:

    vrrp_instance VI_1 {
 ...
 strict_mode off
 check_unicast_src
 unicast_peer {
 192.168.122.101
 }
}

    Когда это сделано, только одноадресный трафик будет использоваться keepalived.

    Обратите внимание, что удаление strict_mode может изменить поведение брандмауэра, выполняемое keepalived.

1
ответ дан 28 July 2021 в 14:06

Теги

Похожие вопросы