Работа keepalived и прочих утилит для обеспечения отказоустойчивости при помощи vIP в среде EVPN + базовая конфигурация

09 Oct 2020 - somovis

Share on:

Работа keepalived и прочих утилит для обеспечения отказоустойчивости при помощи vIP в среде EVPN + базовая конфигурация

Проблема:

  1. keepalived с настройками по умолчанию использует secondary ip address на физическом интерфейсе в качестве virtual IP, как следствие, наследует MAC-адрес физического интерфейса;
  2. Поскольку EVPN изучает MAC-адреса на control plane и их распространение в сети передачи данных происходит по BGP, то для каждого сетеобразующего устройства каждый MAC-адрес будет являться уникальным маршрутом;
  3. Как следствие, при переключении vIP с srv1 на srv2, которые находятся за разными ESI или за разными ESI разных VTEP - произойдет изучение на control plane, а поскольку, у одинакового IP (vIP) адреса будут разные MAC-адреса (наследование от физического интерфейса) - произойдёт анонс двух разных маршрутов. В следствии чего, есть лишь 50% шанс, что данный адрес будет доступен. При переключении vIP обратно будет то же самое.
  4. Работоспособность будет восстановлена после истечения тайм-аута для данного адреса в ARP/EVPN ARP таблицах.

Решение:

  1. По возможности использовать L3 и балансировку (резервирование) средствами маршрутизации;
  2. Если нет возможности использовать L3 и необходимо резервирование L2, то потребуется перейти на виртуальные интерфейсы MACVLAN VEPA mode (так же возможна работа и в BRIDGE mode, но не тестировалось). Варианты работы с MACVLAN интерфейсом:
    1. VRRP с виртуальным IP-адресом и MAC-адресом (должны быть одинаковыми на всех srv в рамках группы резервирования;
    2. Или использовать статическую конфигурацию при помощи скриптов (например, это можно сделать в связке с pacemaker). Виртуальный IP-адрес и MAC-адрес должны быть одинаковыми на всех srv в рамках группы резервирования.

Реализация для работы с keepalived по шагам:

  1. Если сервис в виртуальной машине, то потребуется на конкретном NIC в гипервизоре для виртуальной машины понизить уровень безопасности, а точнее, требуется включить:
    • promiscuous mode;
    • MAC address changes;
    • forged transmits.
  2. Требуется обновить ядро и ПО до следующих версий:
    • kernel >= 3.2;
    • keepalived >= 2.0.16 (для RHEL7 >= 1.3.5).
  3. Включить promisc на физическом интерфейсе в guest OS/BMS:
    • ifconfig promisc;
    • ip link set promisc on;
    • echo PROMISC=yes >> /etc/sysconfig/network-scripts/ifcfg-.
  4. Подгрузить модуль VMAC в ядро:
    • modprobe vmac;
    • echo "vmac" > /etc/modules-load.d/vmac.conf.
  5. Поменять параметры sysctl в /etc/sysctl.conf для необходимой работы с ARP: Хочу заметить, что в строке net.ipv4.conf.vrrp/50 указывается интерфейс, наследуемый из virtual_router_id в конфигурации keepalived далее, при этом, если конфигурация keepalived ранее не была выполнена, то параметр net.ipv4.conf.vrrp/50.rp_filter = 0 необходимо применить после конфигурации keepalived и его старта. 
     net.ipv4.conf.all.arp_ignore = 1
 net.ipv4.conf.all.arp_announce = 2
 net.ipv4.conf.all.rp_filter = 0
 net.ipv4.conf.ens192.rp_filter = 0
 net.ipv4.conf.vrrp/50.rp_filter = 0

    Для более детального понимания каждого параметра рекомендую ознакомится с документацией по ссылке - www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

  6. Поменять параметры keevpalived в /etc/keepalived/test.cfg, дополнительно опишу часть важных параметров:
    1. state BACKUP - запускает сервис в состоянии backup, далее, после обмена контрольных сообщений с priority, выбирается MASTER;
    2. interface - ассоциируем физический интерфейс;
    3. virtual_router_id - virtual router ID :) Так же важно, что без явного указания имени виртуального интерфейса он будет создан автоматически в виде: vrrp. +;
    4. priority - приоритет конкретного инстанса keepalived в рамках виртуальной группы (virtual_router_id). MASTER в виртуальной группе выбирается по верхнему приоритету среди всех инстансов;
    5. use_vmac - позволяет использовать VRRP с virtual MAC. Опционально можно указать имя виртуального интерфейса. *По умолчанию интерфейс MACVLAN находится в режиме VEPA, который отфильтровывает полученные пакеты, MAC-адрес источника которых совпадает с адресом интерфейса MACVLAN. Настройка интерфейса MACVLAN в private mode не будет фильтровать по исходному MAC-адресу. В качестве альтернативы вы можете указать vmac_xmit_base, который будет вызывать передачу и прием сообщений VRRP на базовом интерфейсе, в то время как ARP будет работать с интерфейсом vmac;
    6. advert_int - интервал обмена служебными сообщениями, так же выполняет роль keepalive сообщений;
    7. nopreempt - с этой опцией при появлении в виртуальной группе инстанса с более высоким приоритетом позволяет не отдавать тому инстансу состояние MASTER. Полезно при высокой нагрузке для предотвращения потери пакетов, но маршрутизация к vIP может быть не оптимальной;
    8. virtual_ipaddress - собственно virtual IP;
    9. unicast_src_ip - указываем unicast source address физического интерфейса, с которого хотим отправлять служебные пакеты. Без указания данного параметра в некоторых конфигурациях наблюдалась потеря пакетов;
    10. unicast_peer - для большей предсказуемости рекомендуется указывать unicast IP адреса всех инстансов keepalived в конкретной виртуальной группе. 
       vrrp_instance test  {
state BACKUP
interface ens192
virtual_router_id 50
priority 50
use_vmac
vmac_xmit_base
advert_int 1
nopreempt
virtual_ipaddress {
    10.50.50.50
}
unicast_src_ip 10.50.50.51
unicast_peer { 
    10.50.50.52
}
 }

      Для более детального понимания каждого параметра рекомендую ознакомится с документацией по ссылке - Note on using VRRP with Virtual MAC address

  7. Что если используются разные адресные семейства на интерфейсе: Если у вас в ОС используются настройки сети по умолчанию и включен IPv6 (во многих дистрибутивах он включен по умолчанию), а на том srv, на MACVLAN интерфейсе которого на текущий момент времени нету IPv4 адреса (состояние keepalived backup), но есть IPv6 адрес, то vmac адрес MACVLAN интерфейса с разных srv будет виден в сети за разными ES (или разными VTEP и разными ES). Отсюда будут возникать события MACMOVE/duplicate MAC, что недопустимо в среде EVPN (да и не только с EVPN, по хорошему). Чтобы избежать проблем, если у вас не используется IPv6, то проще отключить его на srv с keepalived, но если используется, то нужно использовать тот же самый принцип с одинаковым IPv6 адресом на MACVLAN интерфейсе разных srv в пределах виртуальной группы, как и с IPv4 адресом.

Проверить работоспособность возможно переключая состояния инстансов keepalived, но не рекомендуется делать это чаще 5 раз за 3 минуты, иначе данный MAC может быть автоматически заблокировано на 5 минут, так как это является стандартным параметром некоторых производителей с целью предотвращения MAC-move/MAC-duplicate в сети передачи данных средствами EVPN.

Ссылки

1. www.kernel.org/doc/Documentation/networking/ip-sysctl.txt ↩
2. Note on using VRRP with Virtual MAC address ↩

Tags: keepalived evpn vip