Назад | Перейти на главную страницу

keepalived не продвигает РЕЗЕРВНОЕ КОПИРОВАНИЕ на МАСТЕР в конфигурации с несколькими экземплярами

Я пытаюсь настроить поддержку активности нескольких экземпляров, чтобы управлять парой серверов tarantool, управляющей репликой, и настраивать виртуальные IP-адреса. Само состояние сервера управляется вне поддержки активности. Keepalived должен управлять только VIP: он должен установить VIP1 на dummy1 iface в случае, если сервер находится в состоянии master, и VIP2 на том же dummy1 iface в случае, если сервер находится в состоянии реплики, и гарантировать, что один и тот же VIP не установлен на двух серверах в случае неправильной конфигурации. Серверы находятся в центрах обработки данных с отложенным доступом, поэтому многоадресная рассылка невозможна. Роли выделенного сервера отсутствуют, оба сервера могут быть ведущими или репликами в исходном состоянии, поэтому я использую BACKUP-BACKUP с равным приоритетом конфигурации. Вот мой конфиг:

global_defs {
  enable_script_security # 1)
  dynamic_interfaces
}

vrrp_script chk_trntl_db1_pri {
  script "/bin/sh -c '/usr/bin/echo lua box.info.status | /usr/bin/tarantool -p 11011 | /usr/bin/grep -q primary'"
  interval 1
  fall 3
  rise 2
}

vrrp_script chk_trntl_db1_rpl {
  script "/bin/sh -c '/usr/bin/echo lua box.info.status | /usr/bin/tarantool -p 11011 | /usr/bin/grep -q connected'"
  interval 1
  fall 3
  rise 2
}

vrrp_instance TRNTL_DB1_PRI {
  interface eth0
  state BACKUP # 3)
  nopreempt # 4)
  virtual_router_id 03
  priority 100
  advert_int 1
  authentication {
    auth_type PASS # TODO: test AH method
    auth_pass XXXXXX
  }
  unicast_src_ip 10.161.133.20
  unicast_peer {
    10.161.133.19
  }
  virtual_ipaddress {
    10.161.133.21/32 dev dummy1
  }
  track_script {
    chk_trntl_db1_pri
  }
}

vrrp_instance TRNTL_DB1_RPL {
  interface eth0
  state BACKUP # 3)
  nopreempt # 4)
  virtual_router_id 04
  priority 100
  advert_int 1
  authentication {
    auth_type PASS
    auth_pass XXXXXX
  }
  unicast_src_ip 10.161.133.20
  unicast_peer {
    10.161.133.19
  }
  virtual_ipaddress {
    10.161.133.22/32 dev dummy1
  }
  track_script {
    chk_trntl_db1_rpl
  }
}

Конфигурация пары отличается только unicast_src_ip и unicast_peer - они противоположны. Вы можете заметить, что virtual_router_id уникален для каждого экземпляра.

Я обнаружил, что keepalived никогда не будет переводить экземпляр BACKUP в состояние MASTER и устанавливать VIP в случае наличия более одного экземпляра. Ни TRNTL_DB1_PRI, ни TRNTL_DB1_PRI, даже соответствующие скрипты не выполняются все время с самого начала, и экземпляр остается в состоянии BACKUP.

Вот тестовый пример: тарантоол SERVER1 находится в состоянии master, TRNTL_DB1_RPL экземпляр закомментирован (конфигурация одного экземпляра для тестирования),chk_trntl_db1_pri возвращает 0, TRNTL_DB1_PRI становится BACKUP, получает тайм-аут объявления и повышается до MASTER, устанавливается VIP. В то же время тарантул SERVER2 находится в состоянии реплики, chk_trntl_db1_pri возвращает 1, TRNTL_DB1_RPL поэтому находится в состоянии ОТКАЗ - как и ожидалось. Но поскольку tarantool находится в состоянии реплики, chk_trntl_db1_rpl возвращает 0, экземпляр TRNTL_DB1_RPL становится BACKUP и остается в этом состоянии навсегда, даже если он не получает никаких рекламных объявлений от другого узла для его virtual_router_id. Я даже отключил поддержку активности SERVER1, чтобы предотвратить отправку каких-либо рекламных объявлений - нет, TRNTL_DB1_RPL останется в состоянии РЕЗЕРВНОЕ КОПИРОВАНИЕ. Вот журналы:

Starting LVS and VRRP High Availability Monitor...
Starting Keepalived v2.0.7 (08/23,2018)
Running on Linux 3.10.0-862.3.2.el7.x86_64 #1 SMP Mon May 21 23:36:36 UTC 2018 (built for Linux 3.10.0)
Command line: '/usr/sbin/keepalived' '-D'
Opening file '/etc/keepalived/keepalived.conf'.
Starting VRRP child process, pid=14851
Registering Kernel netlink reflector
Registering Kernel netlink command channel 
LVS and VRRP High Availability Monitor. 
Opening file '/etc/keepalived/keepalived.conf'.
Assigned address 10.255.160.193 for interface eth0
Assigned address fe80::21a:4aff:fe16:12a for interface eth0
Registering gratuitous ARP shared channel 
(TRNTL_DB1_PRI) removing VIPs.
(TRENT_DB1_RPL) removing VIPs.
VRRP sockpool: [ifindex(2), proto(112), unicast(1), fd(8,9)]
Script `chk_trntl_db1_pri` now returning 1
VRRP_Script(chk_trntl_db1_pri) failed (exited with status 1)
(TRNTL_DB1_PRI) Entering FAULT STATE
VRRP_Script(chk_trntl_db1_rpl) succeeded
(TRNTL_DB1_RPL) Entering BACKUP STATE

Если я добавлю TRENT_DB1_RPL в конфигурацию SERVER1 он не будет продвигать TRNTL_DB1_PRI в состояние MASTER и оставаться в состоянии BACKUP просто TRNTL_DB1_RPL делает на СЕРВЕРЕ2.

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

Похоже, что даже VIP-адреса установлены на одном интерфейсе и проверяют сценарии, проверяющие один и тот же демон, это два разных независимых экземпляра, если virtual_router_id разные, и они должны работать вместе.

Итак, я что-то неправильно понимаю или это ошибка в keepalived?

ОБНОВЛЕНИЕ: исправлено в 2.0.16. После сборки текущей версии из исходников VRRP работает точно так, как ожидалось.

keepalived keepalive