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

keepalived - случайные перевыборы

Мы настроили 3 запущенных сервера оставайся живым . Мы начали замечать случайные перевыборы, которые мы не можем объяснить, поэтому я пришел сюда за советом.

Вот наша конфигурация:

МАСТЕР:

global_defs {
  notification_email {
    webops@example.com
  }
  notification_email_from keepalived@hostname
  smtp_server example.com:587
  smtp_connect_timeout 30
  router_id some_rate
}


vrrp_script chk_nginx {
  script "killall -0 nginx"
  interval 2
  weight 2
}

vrrp_instance VIP_61 {
  interface bond0
  virtual_router_id 61
  state MASTER
  priority 100
  advert_int 1
  authentication {
    auth_type PASS
    auth_pass PASSWORD
  }
  virtual_ipaddress {
    X.X.X.X
    X.X.X.X
    X.X.X.X
  }
  track_script {
    chk_nginx
  }
}

РЕЗЕРВНОЕ КОПИРОВАНИЕ1:

global_defs {
  notification_email {
    webops@example.com
  }
  notification_email_from keepalived@hostname
  smtp_server example.com:587
  smtp_connect_timeout 30
  router_id some_rate
}


vrrp_script chk_nginx {
  script "killall -0 nginx"
  interval 2
  weight 2
}

vrrp_instance VIP_61 {
  interface bond0
  virtual_router_id 61
  state MASTER
  priority 99
  advert_int 1
  authentication {
    auth_type PASS
    auth_pass PASSWORD
  }
  virtual_ipaddress {
    X.X.X.X
    X.X.X.X
    X.X.X.X
  }
  track_script {
    chk_nginx
  }
}

BACKUP2:

    global_defs {
      notification_email {
        webops@example.com
      }
      notification_email_from keepalived@hostname
      smtp_server example.com:587
      smtp_connect_timeout 30
      router_id some_rate
    }


vrrp_script chk_nginx {
  script "killall -0 nginx"
  interval 2
  weight 2
}

vrrp_instance VIP_61 {
  interface bond0
  virtual_router_id 61
  state MASTER
  priority 98
  advert_int 1
  authentication {
    auth_type PASS
    auth_pass PASSWORD
  }
  virtual_ipaddress {
    X.X.X.X
    X.X.X.X
    X.X.X.X
  }
  track_script {
    chk_nginx
  }
}

Время от времени я вижу, как это происходит (в журналах):

МАСТЕР:

Jan  6 18:30:15 lb-public01 Keepalived_vrrp[24380]: VRRP_Instance(VIP_61) Received lower prio advert, forcing new election
Jan  6 18:30:16 lb-public01 Keepalived_vrrp[24380]: VRRP_Instance(VIP_61) Received lower prio advert, forcing new election
Jan  6 18:32:37 lb-public01 Keepalived_vrrp[24380]: VRRP_Instance(VIP_61) Received lower prio advert, forcing new election

РЕЗЕРВНОЕ КОПИРОВАНИЕ1:

Jan  6 18:30:16 lb-public02 Keepalived_vrrp[26235]: VRRP_Instance(VIP_61) Transition to MASTER STATE
Jan  6 18:30:16 lb-public02 Keepalived_vrrp[26235]: VRRP_Instance(VIP_61) Received higher prio advert
Jan  6 18:30:16 lb-public02 Keepalived_vrrp[26235]: VRRP_Instance(VIP_61) Entering BACKUP STATE
Jan  6 18:32:37 lb-public02 Keepalived_vrrp[26235]: VRRP_Instance(VIP_61) forcing a new MASTER election
Jan  6 18:32:38 lb-public02 Keepalived_vrrp[26235]: VRRP_Instance(VIP_61) Transition to MASTER STATE
Jan  6 18:32:38 lb-public02 Keepalived_vrrp[26235]: VRRP_Instance(VIP_61) Received higher prio advert
Jan  6 18:32:38 lb-public02 Keepalived_vrrp[26235]: VRRP_Instance(VIP_61) Entering BACKUP STATE

BACKUP2:

Jan  6 18:32:36 lb-public03 Keepalived_vrrp[14255]: VRRP_Script(chk_nginx) succeeded
Jan  6 18:32:37 lb-public03 Keepalived_vrrp[14255]: VRRP_Instance(VIP_61) Transition to MASTER STATE
Jan  6 18:32:37 lb-public03 Keepalived_vrrp[14255]: VRRP_Instance(VIP_61) Received higher prio advert
Jan  6 18:32:37 lb-public03 Keepalived_vrrp[14255]: VRRP_Instance(VIP_61) Entering BACKUP STATE

Таким образом, МАСТЕР получает рекламу НИЖНЕГО ПРИОМИНАЛА, и начинаются НОВЫЕ выборы. ЗАЧЕМ ? Похоже, что BACKUP переходит в состояние MASTER на короткий период времени (на основе журналов), а затем не возвращается в состояние BACKUP. Я совершенно не понимаю, почему это происходит на самом деле, поэтому любые подсказки будут более чем приветствоваться.

Кроме того, я обнаружил, что есть одноадресный патч в keepalived, однако мне не ясно, поддерживает ли он более 1 одноадресного узла - в нашем случае у нас есть кластер из 3 машин, поэтому нам нужно более 1 одноадресного узла.

Любые подсказки по этим вопросам были бы чрезвычайно признательны!

Проблема в том, что вы используете состояние по умолчанию MASTER для узлов резервного копирования. Они должны указать BACKUP.

  vrrp_instance VIP_61 {
      interface bond0
      virtual_router_id 61
      state BACKUP
      priority 98
      ...

Надеюсь, это решит вашу загадку.