С помощью этого руководства вы настроите отказоустойчивый кластер из двух
по схеме «активный/резервный» с помощью виртуального IP и сервиса Keepalived, реализующего функциональность протокола VRRP.Сервис Keepalived выбирает основным узлом Master виртуальную машину, у которой указан наибольший приоритет. Вторая машина становится резервным узлом Backup. Если Master-узел выходит из строя, Backup-узел становится активным и продолжает предоставлять услуги. Схема отказоустойчивого кластера представлена ниже.
Вы будете использовать следующие сервисы:
VPC — изолированная виртуальная сеть для создания безопасной инфраструктуры.
«Подсети» — сервис, позволяющий создавать подсети для размещения в них облачных ресурсов.
«Виртуальные машины» — сервис, в рамках которого предоставляется виртуальная машина.
«Публичные IP» — сервис для организации доступа виртуальных машин в интернет.
«Группы безопасности» — сервис для контроля трафика виртуальных машин.
«Виртуальные IP» — сервис для инфраструктурной поддержки отказоустойчивых решений.
Шаги:
Если вы уже зарегистрированы, войдите под своей учетной записью.
Создайте VPC-сеть с названием VPC-1.
Убедитесь, что на странице сервиса Evolution VPC отображается VPC-сеть VPC-1 в статусе «Создана».
Создайте подсеть со следующими параметрами:
Название — subnet-1.
VPC — VPC-1.
Зона доступности — ru.AZ-1.
Адрес — 10.0.0.0/24.
DNS-серверы — 8.8.8.8.
Создайте подсеть со следующими параметрами:
Название — subnet-2.
VPC — VPC-1.
Зона доступности — ru.AZ-1.
Адрес — 10.1.1.0/24.
Убедитесь, что на странице сервиса «Подсети» отображаются подсети subnet-1, subnet-2 в статусе «Создана».
Создайте три виртуальных машины:
две для Master и Backup-узлов;
одну для клиента, с которого будут отправляться запросы на виртуальный IP.
Создайте виртуальную машину со следующими параметрами:
Название — vrrp_master.
Зона доступности — ru.AZ-1.
Образ — Публичные → Ubuntu 22.04.
Гарантированная доля vCPU — 10%.
vCPU — 1.
RAM — 1.
Сетевой интерфейс — выберите тип Подсеть с публичным IP.
VPC — VPC-1.
Подсеть — 10.0.0.0/24 (subnet-1).
Внутренний IP — Автоматически.
Публичный IP — оставьте Арендовать новый или выберите IP-адрес из списка арендованных.
Группы безопасности — SSH-access_ru.AZ-1.
Метод аутентификации — Пароль.
Пароль — задайте пароль пользователя.
Имя хоста — vrrp_master.
Создайте виртуальную машину со следующими параметрами:
Название — vrrp_backup.
Зона доступности — ru.AZ-1.
Образ — Публичные → Ubuntu 22.04.
Гарантированная доля vCPU — 10%.
vCPU — 1.
RAM — 1.
Сетевой интерфейс — выберите тип Подсеть с публичным IP.
VPC — VPC-1.
Подсеть — 10.0.0.0/24 (subnet-1).
Внутренний IP — Автоматически.
Публичный IP — оставьте Арендовать новый или выберите IP-адрес из списка арендованных.
Группы безопасности — SSH-access_ru.AZ-1.
Метод аутентификации — Пароль.
Пароль — задайте пароль пользователя.
Имя хоста — vrrp_backup.
Создайте виртуальную машину со следующими параметрами:
Название — client.
Зона доступности — ru.AZ-1.
Образ — Публичные → Ubuntu 22.04.
Гарантированная доля vCPU — 10%.
vCPU — 1.
RAM — 1.
Сетевой интерфейс — выберите тип Подсеть.
VPC — VPC-1.
Подсеть — 10.1.1.0/24 (subnet-2).
Внутренний IP — Автоматически.
Группы безопасности — SSH-access_ru.AZ-1.
Метод аутентификации — Пароль.
Пароль — задайте пароль пользователя.
Имя хоста — client.
Убедитесь, что в личном кабинете на странице сервиса «Виртуальные машины» отображаются виртуальные машины vrrp_master, vrrp_backup, client в статусе «Запущена».
Проверьте, что в сервисе «Подсети» в параметрах сетевых интерфейсов виртуальных машин vrrp_master и vrrp_backup включена опция Проверка адреса источника/назначения.
На интерфейсах виртуальных машин vrrp_master и vrrp_backup необходимо разрешить входящий трафик из подсети этих интерфейсов с помощью правил групп безопасности, иначе пакеты протокола VRRP будут заблокированы. Оба интерфейса будут считать себя Master-узлом и отвечать на ARP-запросы, что приведет к неработоспособности схемы.
Перейдите в сервис сервис «Группы безопасности».
Откройте группу безопасности SSH-access_ru.AZ-1.
Создайте правила для входящего трафика с параметрами:
Протокол | Тип источника | Источник |
|---|---|---|
Любой | IP-адрес | 10.0.0.0/24 |
Любой | IP-адрес | 10.1.0.0/24 |
Создайте виртуальный IP со следующими параметрами:
Название — vip-1.
Тип подсети — Virtualization.
Опция — Маршрутизируемая подсеть.
VPC — VPC-1.
Подсеть — 10.0.0.0/24 (subnet-1).
Виртуальный IP-адрес — 10.0.0.100.
Интерфейсы виртуальных машин — интерфейсы vrrp_master и vrrp_backup.
Убедитесь, что на странице сервиса «Виртуальные IP» отображается виртуальный IP vip-1 в статусе «Создан».
Настройте Keepalived на виртуальных машинах vrrp_master и vrrp_backup, выполнив инструкцию для каждой виртуальной машины.
Команды приведены для виртуальных машин с ОС семейства Debian/Ubuntu.
Подключитесь через серийную консоль к виртуальной машине.
Установите сервис Keepalived, выполнив команду:
sudo apt update && sudo apt install keepalived -y
Узнайте название сетевого интерфейса:
Выполните команду:
ip address
Результат:
...2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc fq_codel state UP group default qlen 1000link/ether fa:16:3e:98:c2:75 brd ff:ff:ff:ff:ff:ffinet 10.0.0.4/24 metric 100 brd 10.0.0.255 scope global dynamic enp3s0valid_lft 42159sec preferred_lft 42159secinet6 fe80::f816:3eff:fe98:c275/64 scope linkvalid_lft forever preferred_lft forever
Найдите интерфейс из диапазона 10.0.0.0/24, принадлежащего подсети subnet-1. В примере выше название сетевого интерфейса enp3s0, оно понадобится далее.
Создайте конфигурационный файл:
sudo nano /etc/keepalived/keepalived.conf
В конфигурационном файле укажите параметры:
vrrp_instance VRRP1 {state MASTERinterface <interface_name>virtual_router_id 1priority 100advert_int 1virtual_ipaddress {10.0.0.100}preempt}
Где:
vrrp_instance — определяет название виртуального маршрутизатора.
state — устанавливает состояние виртуальной машины: MASTER или BACKUP.
interface — определяет сетевой интерфейс, на котором будет работать виртуальный IP-адрес.
<interface_name> — название сетевого интерфейса виртуальной машины из шага 4.
virtual_router_id — идентификатор VRRP для группы виртуальных маршрутизаторов. Должен совпадать для всех виртуальных машин в группе.
priority — приоритет, по которому определяется Master и Backup-узел.
advert_int — интервал обновления в секундах.
virtual_ipaddress — виртуальный IP-адрес.
Конфигурационный файл содержит минимальный набор параметров, необходимых для работы сервиса. Вы можете указать дополнительные параметры. Подробнее — в документации Keepalived.
Перезапустите сервис Keepalived:
sudo systemctl restart keepalived.service
Проверьте статус сервиса Keepalived:
sudo systemctl status keepalived.service
Результат:
keepalived.service - Keepalive Daemon (LVS and VRRP)Loaded: loaded (/lib/systemd/system/keepalived.service; enabled; vendor preset: enabled)Active: active (running) since Wed 2026-01-21 15:20:40 MSK; 1min 36s agoMain PID: 647 (keepalived)Tasks: 2 (limit: 1009)Memory: 5.2MCPU: 19msCGroup: /system.slice/keepalived.service├─647 /usr/sbin/keepalived --dont-fork└─704 /usr/sbin/keepalived --dont-forkJan 21 15:20:40 vrrp-master Keepalived[647]: Starting VRRP child process, pid=704Jan 21 15:20:40 vrrp-master systemd[1]: keepalived.service: Got notification message from from PID 703, but reception only permitted for main PID 649Jan 21 15:20:40 vrrp-master Keepalived[647]: Startup completeJan 21 15:20:40 vrrp-master systemd[1]: Started Keepalive Daemon (LVS and VRRP).Jan 21 15:20:40 vrrp-master Keepalived_vrrp[704]: (VRRP1) Entering BACKUP STATE (init)Jan 21 15:20:40 vrrp-master Keepalived_vrrp[704]: (VRRP1) received lower priority (90) advert from 10.0.0.5 - discardingJan 21 15:20:41 vrrp-master Keepalived_vrrp[704]: (VRRP1) received lower priority (90) advert from 10.0.0.5 - discardingJan 21 15:20:42 vrrp-master Keepalived_vrrp[704]: (VRRP1) received lower priority (90) advert from 10.0.0.5 - discardingJan 21 15:20:43 vrrp-master Keepalived_vrrp[704]: (VRRP1) received lower priority (90) advert from 10.0.0.5 - discardingJan 21 15:20:44 vrrp-master Keepalived_vrrp[704]: (VRRP1) Entering MASTER STATE
В облаке Evolution пакеты, адресованные виртуальному IP, получает только Master-узел.
В разных окнах браузера подключитесь через серийную консоль к виртуальным машинам vrrp_master, vrrp_backup и client.
На виртуальных машинах vrrp_master и vrrp_backup запустите утилиту tcpdump командой:
sudo tcpdump -i <interface_name> icmp -n
Где <interface_name> — название сетевого интерфейса виртуальной машины.
На виртуальной машине client выполните команду:
ping 10.0.0.100
Убедитесь, что на виртуальную машину client приходят ответы от виртуального IP:
PING 10.0.0.100 (10.0.0.100) 56(84) bytes of data.64 bytes from 10.0.0.100: icmp_seq=83 ttl=63 time=4052 ms64 bytes from 10.0.0.100: icmp_seq=84 ttl=63 time=3028 ms
Проверьте результат tcpdump на виртуальных машинах vrrp_master и vrrp_backup — пакеты будут приходить только на vrrp_master:
tcpdump: verbose output suppressed, use -v[v]... for full protocol decodelistening on enp3s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes15:55:42.635419 IP 10.1.1.4 > 10.0.0.100: ICMP echo request, id 1, seq 170, length 6415:55:42.635445 IP 10.0.0.100 > 10.1.1.4: ICMP echo reply, id 1, seq 170, length 6415:55:43.636478 IP 10.1.1.4 > 10.0.0.100: ICMP echo request, id 1, seq 171, length 6415:55:43.636513 IP 10.0.0.100 > 10.1.1.4: ICMP echo reply, id 1, seq 171, length 64
Смоделируйте отказ vrrp_master, перезагрузив ее. Во время перезагрузки пакеты должны приходить на vrrp_backup:
tcpdump: verbose output suppressed, use -v[v]... for full protocol decodelistening on enp3s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes15:56:32.901976 IP 10.0.0.100 > 10.1.1.4: ICMP echo reply, id 1, seq 220, length 6415:56:33.903862 IP 10.1.1.4 > 10.0.0.100: ICMP echo request, id 1, seq 221, length 6415:56:33.903893 IP 10.0.0.100 > 10.1.1.4: ICMP echo reply, id 1, seq 221, length 6415:56:34.905772 IP 10.1.1.4 > 10.0.0.100: ICMP echo request, id 1, seq 222, length 64
Несколько пакетов может быть потеряно из-за таймера, по которому выбирается новый Master-узел, и передачи виртуального IP узлу.
Дождитесь перезагрузки vrrp_master.
На виртуальной машине vrrp_backup выполните команду:
sudo systemctl status keepalived.service
В результате вы увидите, что на некоторое время vrrp_backup стал Master-узлом, а потом сменил статус обратно на Backup:
...Jan 21 15:28:03 vrrp-backup Keepalived_vrrp[706]: (VRRP1) Entering BACKUP STATEJan 21 15:56:23 vrrp-backup Keepalived_vrrp[706]: (VRRP1) Entering MASTER STATEJan 21 15:56:44 vrrp-backup Keepalived_vrrp[706]: (VRRP1) Master received advert from 10.0.0.4 with higher priority 100, ours 90Jan 21 15:56:44 vrrp-backup Keepalived_vrrp[706]: (VRRP1) Entering BACKUP STATE
Если виртуальным машинам vrrp_master и vrrp_backup больше не требуется доступ в интернет, отвяжите публичные IP от виртуальных машин и откажитесь от аренды, чтобы остановить тарификацию.
Вы настроили отказоустойчивый кластер из двух виртуальных машин с помощью виртуального IP, сервиса Keepalived и протокола VRRP.