Настроить VRRP для кластера серверов BareMetal

VRRP (Virtual Router Redundancy Protocol) — это сетевой протокол, предназначенный для повышения отказоустойчивости маршрутизаторов, выполняющих роль шлюза по умолчанию.

Отказоустойчивость достигается за счет объединения в группу двух и более маршрутизаторов в один виртуальный маршрутизатор, который выступает шлюзом по умолчанию для обслуживаемых сегментов сети. Протокол VRRP позволяет создать виртуальный IP-адрес и передавать его между участниками группы, за счет чего повышается доступность шлюза.

В данном руководстве приводится пример организации на серверах BareMetal высокодоступной конфигурации прокси-сервера, в которой функции проксирования симметрично настроены на двух и более узлах HAProxy, а за формирование и передачу виртуального IP-адреса между этими узлами отвечает сервис Keepalived.

Схема решенияСхема решения

В зоне доступности ru-central1-m вы настроите окружение из двух приватных подсетей subnet-m3 и subnet-m4, созданных соответственно в пулах серверов ru-central1-m3 и ru-central1-m4. Эти подсети вы объедините в виртуальный фрагмент сети (VRF) vrrp-vrf.

В подсети subnet-m3 вы создадите два сервера BareMetal — master-server-m3 и backup-server-m3, которые соответственно будут выполнять роли MASTER и BACKUP в VRRP-группе. На двух этих серверах вы запустите сервис Keepalived и настроите с его помощью виртуальный IP-адрес для группы серверов в пуле ru-central1-m3.

В подсети subnet-m4 в пуле серверов ru-central1-m4 вы создадите сервер BareMetal client-server-m4, который будет выступать в качестве клиента при использовании виртуального IP-адреса, созданного в пуле ru-central1-m3.

Данное решение позволяет продемонстрировать комплексную работу клиентского изолированного VRF с маршрутизацией уровня L3 сетевой модели OSI между пулами серверов ru-central1-m3 и ru-central1-m4, а также работу широковещательного протокола VRRP на уровне L2 в пуле серверов ru-central1-m3.

Чтобы настроить отказоустойчивый кластер серверов BareMetal с использованием VRRP:

1. Подготовьте облако к работе.
2. Создайте виртуальный сетевой сегмент.
3. Создайте приватные подсети.
4. Арендуйте серверы BareMetal.
5. Настройте Keepalived на серверах пула ru-central1-m3.
6. Убедитесь в работоспособности решения.

Если созданные ресурсы вам больше не нужны, удалите их.

Перед началом работыПеред началом работы

Зарегистрируйтесь в Yandex Cloud и создайте платежный аккаунт:

1. Перейдите в консоль управления, затем войдите в Yandex Cloud или зарегистрируйтесь.
2. На странице Yandex Cloud Billing убедитесь, что у вас подключен платежный аккаунт, и он находится в статусе ACTIVE или TRIAL_ACTIVE. Если платежного аккаунта нет, создайте его и привяжите к нему облако.

Если у вас есть активный платежный аккаунт, вы можете создать или выбрать каталог, в котором будет работать ваша инфраструктура, на странице облака.

Подробнее об облаках и каталогах.

Создайте виртуальный сетевой сегментСоздайте виртуальный сетевой сегмент

Чтобы связать несколько приватных подсетей на уровне L3 сетевой модели OSI, их необходимо объединить в виртуальный фрагмент сети (VRF).

Создайте новый VRF:

Создайте приватные подсетиСоздайте приватные подсети

Создайте две приватные подсети в разных пулах серверов и добавьте их в созданный ранее виртуальный фрагмент сети:

Арендуйте серверы BareMetalАрендуйте серверы BareMetal

На открывшейся странице со списком серверов BareMetal отобразится информация обо всех созданных серверах. В поле Публичный адрес таблицы скопируйте публичные IP-адреса серверов — они понадобятся для подключения к серверам по SSH.

Настройте Keepalived на серверах пула ru-central1-m3Настройте Keepalived на серверах пула ru-central1-m3

На этом этапе вы установите, настроите и запустите сервис Keepalived на серверах, созданных в пуле ru-central1-m3.

Используйте приведенную ниже инструкцию, чтобы настроить оба сервера — master-server-m3 и backup-server-m3.

1. Подключитесь к серверу по SSH, использовав сохраненный на предыдущем шаге публичный IP-адрес этого сервера.

2. Установите сервис Keepalived, выполнив команду:

   sudo apt update && sudo apt install keepalived -y
   

3. Посмотрите список сетевых интерфейсов сервера:

   ip a
   

   Результат:

   ...
   5: etx2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
       link/ether 00:02:c9:35:fd:31 brd ff:ff:ff:ff:ff:ff
       altname enp6s0d1
       inet 172.28.1.2/24 metric 100 brd 172.28.1.255 scope global dynamic etx2
          valid_lft 3512sec preferred_lft 3512sec
       inet6 fe80::202:c9ff:fe35:fd31/64 scope link
          valid_lft forever preferred_lft forever
   

   В выводе команды найдите интерфейс с IP-адресом, относящимся к диапазону 172.28.1.0/24, назначенному приватной подсети subnet-m3. В примере выше это интерфейс с идентификатором etx2. Идентификатор интерфейса понадобится далее, при настройке Keepalived.

4. Создайте файл конфигурации Keepalived:

   sudo nano /etc/keepalived/keepalived.conf
   

5. Добавьте в созданный файл следующую конфигурацию:

   Master

   Backup

   vrrp_instance M3_1 {
       state MASTER
       interface etx2
       virtual_router_id 51
       priority 100
       advert_int 1
   
       authentication {
           auth_type PASS
           auth_pass hGoVjTjSYQq3Epm
       }
   
       virtual_ipaddress {
           172.28.1.254
       }
   
       preempt
   }
   

   vrrp_instance M3_2 {
       state BACKUP
       interface etx2
       virtual_router_id 51
       priority 90
       advert_int 1
   
       authentication {
           auth_type PASS
           auth_pass hGoVjTjSYQq3Epm
       }
   
       virtual_ipaddress {
           172.28.1.254
       }
   
       preempt
   }
   

   Где:

   • vrrp_instance — имя виртуального маршрутизатора:

     • для сервера с ролью MASTER — M3_1
     • для сервера с ролью BACKUP — M3_2

   • state — состояние сервера: MASTER или BACKUP.

   • interface — идентификатор сетевого интерфейса, на котором будет работать виртуальный IP-адрес. В примере выше — etx2.

   • virtual_router_id — уникальный идентификатор VRRP для группы виртуальных маршрутизаторов. Значение должно совпадать для всех серверов в группе.

   • priority — приоритет, позволяющий определить основной и резервный узлы. Установка приоритета на уровне 100 делает сервер основным узлом, на 90 — резервным.

   • advert_int — интервал объявления состояния в секундах.

   • authentication — секция с настройками аутентификации для обеспечения безопасности. Содержимое секции должно совпадать для всех серверов в группе.

   • virtual_ipaddress — виртуальный IP-адрес, который будет управляться этим узлом. Виртуальный IP-адрес:

     • должен относиться к диапазону CIDR, заданному для виртуальной подсети, в которой создана группа северов;
     • должен быть не занят;
     • должен совпадать для всех серверов в группе.

   • preempt — позволяет серверу перейти в состояние MASTER, если его приоритет оказывается выше чем у текущего мастера в группе.

6. Перезапустите сервис Keepalived:

   systemctl restart keepalived.service
   

7. Посмотрите журнал логов сервиса Keepalived, чтобы убедиться, что сервис запущен:

   sudo journalctl -u keepalived.service
   

   Результат:

   Master

   Backup

   systemd[1]: keepalived.service - Keepalive Daemon (LVS and VRRP) was skipped because of an unmet condition check (ConditionFileNotEmpty=/etc/keepalived/keepalived.conf).
   systemd[1]: Starting keepalived.service - Keepalive Daemon (LVS and VRRP)...
   Keepalived[4045]: Starting Keepalived v2.2.8 (04/04,2023), git commit v2.2.7-154-g292b299e+
   Keepalived[4045]: Running on Linux 6.8.0-53-generic #55-Ubuntu SMP PREEMPT_DYNAMIC Fri Jan 17 15:37:52 UTC 2025 (built for Linux 6.8.0)
   Keepalived[4045]: Command line: '/usr/sbin/keepalived' '--dont-fork'
   Keepalived[4045]: Configuration file /etc/keepalived/keepalived.conf
   Keepalived[4045]: NOTICE: setting config option max_auto_priority should result in better keepalived performance
   Keepalived[4045]: Starting VRRP child process, pid=4046
   Keepalived_vrrp[4046]: (/etc/keepalived/keepalived.conf: Line 10) Truncating auth_pass to 8 characters
   Keepalived[4045]: Startup complete
   systemd[1]: Started keepalived.service - Keepalive Daemon (LVS and VRRP).
   Keepalived_vrrp[4046]: (M3_1) Entering BACKUP STATE (init)
   Keepalived_vrrp[4046]: (M3_1) Entering MASTER STATE
   

   systemd[1]: keepalived.service - Keepalive Daemon (LVS and VRRP) was skipped because of an unmet condition check (ConditionFileNotEmpty=/etc/keepalived/keepalived.conf).
   systemd[1]: Starting keepalived.service - Keepalive Daemon (LVS and VRRP)...
   Keepalived[2751]: Starting Keepalived v2.2.8 (04/04,2023), git commit v2.2.7-154-g292b299e+
   Keepalived[2751]: Running on Linux 6.8.0-53-generic #55-Ubuntu SMP PREEMPT_DYNAMIC Fri Jan 17 15:37:52 UTC 2025 (built for Linux 6.8.0)
   Keepalived[2751]: Command line: '/usr/sbin/keepalived' '--dont-fork'
   Keepalived[2751]: Configuration file /etc/keepalived/keepalived.conf
   Keepalived[2751]: NOTICE: setting config option max_auto_priority should result in better keepalived performance
   Keepalived[2751]: Starting VRRP child process, pid=2752
   Keepalived_vrrp[2752]: (/etc/keepalived/keepalived.conf: Line 10) Truncating auth_pass to 8 characters
   Keepalived[2751]: Startup complete
   Keepalived_vrrp[2752]: (M3_2) Entering BACKUP STATE (init)
   

Убедитесь в работоспособности решенияУбедитесь в работоспособности решения

1. Убедитесь, что виртуальный IP-адрес был добавлен к сетевому интерфейсу сервера с ролью Master:

   1. Подключитесь по SSH к серверу master-server-m3.

   2. Посмотрите конфигурацию сетевого интерфейса, назначенного приватной подсети subnet-m3.

      ip a
      

      Результат:

      ...
      5: etx2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
          link/ether 00:02:c9:35:fd:31 brd ff:ff:ff:ff:ff:ff
          altname enp6s0d1
          inet 172.28.1.2/24 metric 100 brd 172.28.1.255 scope global dynamic etx2
          valid_lft 3575sec preferred_lft 3575sec
          inet 172.28.1.254/32 scope global etx2
          valid_lft forever preferred_lft forever
          inet6 fe80::202:c9ff:fe35:fd31/64 scope link
          valid_lft forever preferred_lft forever
      

      Сетевой интерфейс получил дополнительный виртуальный IP-адрес, который был задан в настройках Keepalived — 172.28.1.254/32.

2. С помощью ICMP-запросов из приватной подсети subnet-m4 убедитесь в доступности виртуального IP-адреса, расположенного в приватной подсети subnet-m3:

   1. Подключитесь по SSH к серверу client-server-m4.

   2. Выполните команду:

      ping 172.28.1.254 -s 1024 -c 5
      

      Результат:

      PING 172.28.1.254 (172.28.1.254) 1024(1052) bytes of data.
      1032 bytes from 172.28.1.254: icmp_seq=1 ttl=62 time=0.211 ms
      1032 bytes from 172.28.1.254: icmp_seq=2 ttl=62 time=0.242 ms
      1032 bytes from 172.28.1.254: icmp_seq=3 ttl=62 time=0.264 ms
      1032 bytes from 172.28.1.254: icmp_seq=4 ttl=62 time=0.312 ms
      1032 bytes from 172.28.1.254: icmp_seq=5 ttl=62 time=0.273 ms
      
      --- 172.28.1.254 ping statistics ---
      5 packets transmitted, 5 received, 0% packet loss, time 4117ms
      rtt min/avg/max/mdev = 0.211/0.260/0.312/0.033 ms
      

      Использованная команда отправляет и получает пакеты увеличенного размера: все пакеты были доставлены без потерь.

3. Убедитесь в корректной работе балансировщика Keepalived:

   1. Подключитесь по SSH к серверу client-server-m4.

   2. В отдельном окне терминала подключитесь по SSH к серверу master-server-m3.

      Расположите окна терминала так, чтобы одновременно видеть содержимое обоих окон.

   3. В окне терминала с сессией подключения к серверу client-server-m4 повторно запустите утилиту ping без ограничения на количество повторений:

      ping 172.28.1.254 -s 1024
      

      В процессе выполнения этого опроса в окне терминала с открытой сессией подключения к серверу master-server-m3 остановите сервис Keepalived, выполнив команду:

      sudo systemctl stop keepalived
      

      В момент остановки сервиса наблюдайте за окном терминала с сессией подключения к client-server-m4. Результатом корректной работы процесса по передаче виртуального IP-адреса должно быть практически бесшовное переключение ICMP-запросов на резервный хост, при этом выполнение команды ping не должно прерваться.

      Примечание

      Допускается минимальная потеря пакетов (1-3), что обусловлено срабатыванием таймера выбора нового MASTER в группе и передаче ему виртуального адреса.

      Результат:

      PING 172.28.1.254 (172.28.1.254) 1024(1052) bytes of data.
      1032 bytes from 172.28.1.254: icmp_seq=1 ttl=62 time=0.249 ms
      ...
      1032 bytes from 172.28.1.254: icmp_seq=56 ttl=62 time=0.224 ms
      1032 bytes from 172.28.1.254: icmp_seq=57 ttl=62 time=0.314 ms
      1032 bytes from 172.28.1.254: icmp_seq=58 ttl=62 time=0.278 ms
      ^C
      --- 172.28.1.254 ping statistics ---
      58 packets transmitted, 55 received, 5.17241% packet loss, time 58368ms
      rtt min/avg/max/mdev = 0.185/0.271/0.326/0.035 ms
      

   4. В окне терминала с открытой сессией подключения к серверу master-server-m3 запустите сервис Keepalived, выполнив команду:

      sudo systemctl start keepalived
      

4. Проверьте журнал логов сервиса Keepalived на сервере с ролью BACKUP:

   1. Подключитесь по SSH к серверу backup-server-m3.

   2. Посмотрите журнал логов сервиса Keepalived:

      sudo journalctl -u keepalived.service
      

      Результат:

      ...
      # регистрация события о переключении на MASTER в момент остановки сервиса на исходном основном узле
      Feb 19 07:08:07 backup-server-m3 Keepalived_vrrp[2752]: (M3_2) Entering MASTER STATE
      
      # регистрация события о переключении на BACKUP при восстановлении работы сервиса на исходном основном узле
      Feb 19 07:08:31 backup-server-m3 Keepalived_vrrp[2752]: (M3_2) Master received advert from 172.28.1.2 with higher priority 100, ours 90
      Feb 19 07:08:31 backup-server-m3 Keepalived_vrrp[2752]: (M3_2) Entering BACKUP STATE
      ...
      

      Как видно из журнала работы сервиса и добавленных в него комментариев, после остановки сервиса Keepalived на сервере master-server-m3, роль основного узла перешла к серверу backup-server-m3. После восстановления работоспособности сервиса на сервере master-server-m3 роль основного узла была ему возвращена, а сервер backup-server-m3 вновь стал резервным.

Как удалить созданные ресурсыКак удалить созданные ресурсы

Удалить сервер BareMetal нельзя. Вместо этого можно отказаться от продления аренды сервера.

Чтобы перестать платить за созданные ресурсы, откажитесь от продления аренды созданных ранее серверов BareMetal.