Keepalived в кольцевой архитектуре, или другой лучший подход

У меня есть три балансировщика нагрузки (LB1, LB2, LB3) и планирую использовать кольцевую архитектуру для активно-активной настройки, например

LB1    LB2    LB3
IP1    IP2    IP3

Идея как ниже:

  1. Если LB1 не удалось, IP1 будет переведен в IP2
  2. Если LB2 не удалось, IP2 будет переведен в IP3
  3. Если LB3 не удалось, IP3 будет переведен в IP1

Распространена ли вышеуказанная настройка? Есть потенциальная проблема?

Или какая-нибудь лучшая рекомендация для установки трех узлов?

Источник

1 ответ

Решение

Активно-активный сценарий возможен с использованием keepalived. Вам нужно настроить несколько vrrp_instanceтакие как:

vrrp_sync_group G1 {   # must be before vrrp_instance declaration 
  group {
    vserver1
  }
  group {
    vserver2
  }
}

# The primary server 
vrrp_instance vserver1 {
    interface eth0
    state MASTER
    virtual_router_id 1
    priority 100
    advert_int 3
    authentication {
      auth_type PASS
      auth_pass mypass
    }
    virtual_ipaddress {
        VIP1/24   # default CIDR mask is /32 
    }
}

# The backup server
vrrp_instance vserver2 {
    interface eth0
    state backup
    virtual_router_id 2
    priority 50
    advert_int 3
    authentication {
      auth_type PASS
      auth_pass mypapas
    }
    virtual_ipaddress {
        VIP2/24   # default CIDR mask is /32 
    }
}

Важный момент иметь похожий конфиг на 2-м узле, но с разными state а также priority, В показанном примере вам нужно изменить эти строки, чтобы сделать другой узел MASTER для VIP2 и BACKUP для VIP1. По умолчанию у каждой машины будет свой VIP, и в случае сбоя оба VIP будут назначены оставшейся машине.

Конечно, это можно сделать аналогично для 3 машин. Вам нужно определить три vrrp_instanceс вместо двух.

Источник
Другие вопросы по тегам