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

Как настроить резервные IP-адреса для обеспечения высокой доступности с помощью Hetzner Online

У меня есть кластер из 3 узлов Ubuntu, работающих на виртуальных машинах в лаборатории, и я хочу запустить его в производство. Hetzner Online hetzner.de предлагает несколько недорогих выделенных серверов, поэтому я арендовал 3 машины, подключенные к гигабитному коммутатору.

Я намерен создать HA-Setup с двумя keepalived перед двумя серверами HAProxy. Keepalived настроен с VIP внутри моей настройки. К сожалению, с Hetzner это не работает. Однако они предоставляют систему, называемую IP-адресом переключения при отказе, где можно переключиться с помощью сценария на другой сервер: http://wiki.hetzner.de/index.php/Failover_Skript

Моя конфигурация для keepalived выглядит так:

vrrp_script chk_haproxy {
        script "killall -0 haproxy"     # cheaper than pidof
        interval 2                      # check every 2 seconds
        weight 2                        # add 2 points of prio if OK
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101
    virtual_ipaddress {
        192.168.56.101/24 # this is the shared IP I was using
      }
    track_script {
        chk_haproxy
    }
}

Так как же их Failover Script вписался в это?

Похоже, проблема не только у меня, просто решение не так очевидно. https://www.howtoforge.com/community/threads/hetzner-to-stop-support-for-high-availability-setups.19988/

Поскольку это старый ответ, я не уверен, что вы все еще ищете ответ. Но я наткнулся на это в поисках лучшего способа сделать это.

Hetzner назначает резервный IP-адрес выделенному серверу не для того, чтобы разрешить его настройку на сервере, а для маршрутизации трафика на исходный IP-адрес сервера. Следовательно, можно ничего не менять на вашем сервере и вручную переключать IP в их интерфейсе администратора. Тем не мение; это не подходящее решение для большинства, так как я не хотел бы вставать с постели для ручного переключения. Это должно быть сделано автоматически, а затем уведомить администратора о том, что отработка отказа выполнена. Может быть, даже с небольшим отчетом о проблемах, которые система видела и почему произошел сбой.

Keepalived может сделать это за вас, единственное, что требуется, - это настроить keepalived для запуска сценария при отказе. Но если нет IP-адреса для аварийного переключения, как мы можем тогда переключиться?

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

После сбоя Keepalived вы приказываете ему запустить сценарий от Hetzner, чтобы также переключить внешний IP-адрес, используя: notify

Пример:

vrrp_script chk_haproxy {
        script "killall -0 haproxy"     # cheaper than pidof
        interval 2                      # check every 2 seconds
        weight 2                        # add 2 points of prio if OK
}

vrrp_instance VI_1 {
    state MASTER
    interface enp0s31f6.4000
    virtual_router_id 51
    priority 101
    virtual_ipaddress {
        192.168.100.3/24 # this is the shared IP I was using
      }
    track_script {
        chk_haproxy
    }
    notify /usr/sbin/hetzner_failoverIP.sh database set $THIS_SERVER_IP
}

Конечно, сценарий Hetzner можно настроить, чтобы он стал намного умнее, например, выбрав IP-адрес сервера.

Следует отметить обратную сторону: внешний IP-адрес занимает от 40 до 60 секунд. Для меня минимум 40 секунд и максимум 1 минута - это слишком долго.

Другой вариант - использовать экземпляры облака Hetzner для включения высокой доступности без использования IP-адреса аварийного переключения и приведенного выше сценария. В облаке есть еще одно решение: Облачный плавающий IP.

Этот вариант обойдется вам примерно в 8,50 евро в месяц за:

два облачных экземпляра (1 базовый ЦП, 2 ГБ памяти и 20 ТБ трафика каждый)
два облачных плавающих IP-адреса

Затем используйте keepalived для управления облачным плавающим IP-адресом (раздел virtual_ipaddress) и HAProxy для отправки всего трафика на выделенные серверы. Затем HAProxy выполнит проверку работоспособности, и вам не нужно беспокоиться о:

Переключение IP с помощью Hetzner API
От 40 до 60 секунд дополнительного простоя

Стоит отметить, что облачные серверы Hetzner не поддерживаю внутренняя сеть. Но это не обязательно, если вы используете их таким образом, и это не требует дополнительных затрат, так как внутренний трафик бесплатный. В целях безопасности защитите балансировщики нагрузки (облачные экземпляры Keepalived + HAProxy) с помощью SELinux / AppArmor и Firewalld. Используйте зашифрованный трафик между двумя кластерами (облако <-> Выделенный) для предотвращения перехвата пакетов. Я также хотел бы зашифровать трафик между вашими выделенными серверами, даже если вы используете частную VLAN, трафик по-прежнему отправляется через тот же сетевой адаптер. Что нужно иметь в виду.

Использованные источники: