Обмен технологиями

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Архитектура высокой доступности в кластере lvs предназначена только для обеспечения высокой доступности планировщика.

Реализуйте основной и резервный планировщики на базе vrrp.

Высокодоступная архитектура высокой доступности

Основной планировщик и резервный планировщик (может быть несколько планировщиков резервного копирования)

При нормальной работе планировщика оборудование находится в полном резерве (режиме ожидания). Он не участвует в работе кластера. Только при выходе из строя основного планировщика работу основного планировщика возьмет на себя резервный. После восстановления работы основного планировщика мастер продолжит выполнять функции входа в кластер. , а резервная копия продолжит находиться в избыточном состоянии (в зависимости от приоритета).

Keepalive основан на протоколе vrrp для реализации решения высокой доступности LVS.

1. Адрес многоадресной рассылки:

Связь 224.0.0.18 осуществляется на основе адреса многоадресной рассылки. Первичное и вторичное устройства отправляют сообщения, чтобы определить, жив ли другой абонент.

2. Определить позиции первичного и вторичного в зависимости от приоритета.

3. Аварийное переключение: если основная машина зависает, резервная машина продолжит работу. Когда главная машина восстановится, резервная машина продолжит ждать.

4. Переключение между первичным и вторичным — это переключение VIP-адреса.

Keepalive появляется специально для LVS, но не является эксклюзивным для LVS.

основной модуль: основной модуль поддержки активности, отвечающий за запуск и обслуживание основного процесса, а также загрузку файлов глобальной конфигурации.

Модуль vrrp: модуль, реализующий протокол vrrp, который является основным функциональным модулем.

Модуль проверки: отвечает за проверку работоспособности, а также может проверять состояние реального сервера в фоновом режиме.

Основываясь на эксперименте с режимом DR, описанном в предыдущей главе, мы добавляем некоторые конфигурации. На этот раз используются два планировщика: основной и резервный.

Сначала установите Keepalive в планировщике

yum -y install keepalived

После завершения установки

Давайте изменим файл Keepalived.conf.

[root@test1 ~]# vim /etc/keepalived/keepalived.conf
   notification_email_from [email protected]
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id LVS_01
   vrrp_skip_check_adv_addr
   vrrp_strict
   vrrp_garp_interval 0
   vrrp_gna_interval 0
   vrrp_iptables
}
 
vrrp_instance VI_1 {
    state MASTER
    interface ens33
    virtual_router_id 51
    priority 120
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.124.100
    }
}
 
virtual_server 192.168.124.100 80 {
    delay_loop 6
    lb_algo rr
    lb_kind DR
    persistence_timeout 50
    protocol TCP
 
    real_server 192.168.124.40 80 {
        weight 1
            TCP_CHECK {
            connect_port 80
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
 
    real_server 192.168.124.50 80 {
                                                                     9,1           36%

Скопируйте файл конфигурации из первого планировщика во второй планировщик.

scp root@192.168.233.10:/etc/keepallved/keepallved.conf
/etc/keepallved

Затем измените конфигурацию

Приоритет первичного и вторичного

Добавьте опцию iptables

Таким образом, доступ к правилам поддержки активности не будет остановлен в таблице правил ipetables.

[root@localhost ~]# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.124.100:80 rr persistent 50
  -> 192.168.124.40:80            Route   1      0          0
  -> 192.168.124.50:80            Route   1      0          0

Проверьте это

Затем перезапустите все

Посмотрите на результаты клиентов

Давайте сначала выключим основной планировщик

stsemctl stop keepalived.servers

Планировщик резервного копирования берет на себя работу мастера и продолжает работать.

Это VIP-адрес, который был загружен в подготовленный планировщик. Клиент обращается к нему.

Могу еще получить доступ

---

Подведем итог

Keepalived в основном состоит из трех модулей: core (основной модуль, отвечающий за запуск основного процесса, обслуживание, а также загрузку и анализ файлов глобальной конфигурации), check (модуль проверки работоспособности) и vrrp (реализация протокола vrrp).

Принцип работы Keepalived основан на протоколе VRRP. Несколько серверов, обеспечивающих одинаковые функции, объединяются в группу серверов, имеющую главный и несколько резервных копий. На ведущем устройстве есть VIP, который предоставляет услуги внешнему миру (этот VIP-маршрут по умолчанию для других компьютеров в локальной сети, где расположен сервер). Главный сервер будет отправлять многоадресную рассылку. Когда резервное копирование не может получить пакет VRRP, оно будет отправлено. подумает, что мастер не работает, а затем в соответствии с приоритетом уровня VRRP выберет резервную копию, которая станет новым мастером.

При настройке LVS + Keepalived обычно необходимо установить соответствующее программное обеспечение (например, ipvsadm, Keepalived) на главный и резервный узлы и настроить файл Keepalived.conf. Например, в файле конфигурации главного узла необходимо указать состояние (state) master, сетевой интерфейс (interface), идентификатор виртуального маршрута (virtual_router_id), приоритет (priority), интервал объявления (advert_int), данные аутентификации. (аутентификация) и виртуальный IP-адрес (virtual_ipaddress) и т.д. конфигурация резервного узла аналогична, но статус резервный и приоритет обычно ниже, чем у главного.

После завершения настройки перезапустите службу поддержки активности, чтобы обеспечить балансировку нагрузки с высокой доступностью. При выходе из строя главного узла VIP автоматически переключится на резервный узел, чтобы обеспечить нормальный доступ к сервису, после восстановления главного узла он снова будет служить основным узлом нагрузки; Кроме того, реальный сервер (rs) также может быть настроен соответствующим образом. Например, при использовании модели DR для связи lo необходимо настроить как VIP на сетевой карте rs.

Таким образом, комбинация LVS + Keepalived позволяет достичь следующих целей: клиент обращается к сервису через VIP, и запрос будет распределяться по правилам конфигурации, при выходе из строя главного узла балансировки нагрузки он может автоматически переключиться на резервный; узел, чтобы гарантировать, что служба работает нормально; при определенном rs. При сбое узла узел может быть автоматически удален и снова добавлен в кластер после восстановления.

В реальных приложениях необходимо обратить внимание на соответствующие вопросы, например, IP-адрес, настроенный virtual_ipaddress в файле конфигурации Keepalived, должен находиться в том же сегменте сети, чем выше значение приоритета, тем больше вероятность того, что узел станет главным; node; чем меньше значение advert_int, тем выше вероятность отправки узлом сообщений VRRP. Чем выше частота. В то же время для обеспечения стабильности и эффективной работы всей системы также необходимо учитывать такие факторы, как сетевое окружение и производительность сервера.