Настройка keepalived centos 7

Обновлено: 07.07.2024

Keepalived + LVS-DR развертывание / настройка балансировки нагрузки - высокая доступность -Centos7

Быстрая навигация

1. Обзор Keepalived

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

2. Принцип работы Keepalived

  • Keepalived определяет состояние каждого узла сервера
  • Узлы сервера вышли из строя или работают сбои, Keepalived удалит отказавшие узлы из кластерной системы.
  • После восстановления отказавшего узла Keepalived добавит его в кластерную систему.
  • Все работы выполняются автоматически без ручного вмешательства

проблема

Подготовьте три сервера Linux, два в качестве веб-серверов, и разверните программное обеспечение высокой доступности Keepalived, а один - в качестве клиентского хоста для выполнения следующих функций:

  • Используйте Keepalived для достижения высокой доступности веб-сервера
  • IP-адреса веб-сервера: 192.168.4.100 и 192.168.4.200 соответственно.
  • Плавающий VIP-адрес веб-сервера - 192.168.4.80.
  • Клиент получает доступ к веб-странице, обращаясь к VIP-адресу.

Программа

развернуть

Шаг 1. Настройте сетевое окружение

Настройка сетевых параметров сервера Web1 / Web2, настройка веб-сервисов Обратите внимание на имя хоста

Настроить сетевые параметры прокси-хоста

Шаг 2. Установите программное обеспечение Keepalived

Примечание. Два веб-сервера выполняют одну и ту же операцию.

Шаг 3. Разверните службу Keepalived

модифицировать web1 Файл конфигурации Server Keepalived

модифицировать web2 Файл конфигурации Server Keepalived (перечислены только отличия от Web1. Остальные такие же)

Начать обслуживание

Start keepalived автоматически добавит Необходимо удалить правило отбрасываемого брандмауэра!

контрольная работа

Войдите на два веб-сервера для просмотра информации VIP.

проверка

проблема

Используйте Keepalived для обеспечения функций высокой доступности для планировщика LVS, предотвращения отказа единой точки планировщика и предоставления пользователям веб-служб:

  • Настоящий IP-адрес планировщика LVS1 - 192.168.4.5.
  • Настоящий IP-адрес планировщика LVS2 - 192.168.4.6.
  • VIP-адрес сервера - 192.168.4.15.
  • Реальные адреса веб-сервера: 192.168.4.100 и 192.168.4.200 соответственно.
  • При использовании алгоритма взвешенного циклического планирования реальные веб-серверы имеют разные веса.

Программа

  • Используются пять виртуальных машин: одна в качестве клиентского хоста, две в качестве планировщика LVS и две в качестве реального сервера.Структура среды экспериментальной топологии показана на рисунке 2, а базовая конфигурация среды показана в таблице 2.

развернуть

Шаг 1. Настройте сетевое окружение

Установите сетевые параметры сервера Web1

Затем настройте VIP-адрес для web1
нота : Маска подсети должна быть 32 (то есть все 255) Сетевой адрес совпадает с IP-адресом, а широковещательный адрес совпадает с IP-адресом.

нота : Здесь, поскольку web1 также настроен с тем же VIP-адресом, что и планировщик, конфликт адресов определенно произойдет по умолчанию.
Основная цель написания этих четырех строк - получить доступ к пакету данных 192.168.4.15. Ответит только планировщик, и никакой другой хост не ответит.

Перезапустите сетевые службы, настройте брандмауэр и SELinux.

Web2 настроен, как указано выше . (IP 192.168.4.200/24)

Настройте сетевые параметры прокси-хоста (без конфигурации VIP, автоматическая настройка с помощью keepalvied)

Настройте сетевые параметры хоста proxy2 (без конфигурации VIP, автоматическая настройка с помощью keepalvied)

Шаг 2. Настройте фоновую веб-службу

Установите программное обеспечение, настройте веб-страницы (хосты web1 и web2) и запустите веб-службы

Шаг 3. Планировщик устанавливает программное обеспечение Keepalived и ipvsadm

установить программное обеспечение

Шаг 4. Разверните Keepalived для достижения высокой доступности планировщика режима LVS-DR

Планировщик LVS1 устанавливает Keepalived и запускает службу.(в 192.168.4.5 Операция хоста)

Настройки планировщика LVS2 Keepalived(в 192.168.4.6 Операция хоста)

Шаг пятый: клиентский тест

Некоторые друзья сказали, что руководство по LVS недостаточно подробное . Хорошо. Позвольте мне подробно рассказать .

Интеллектуальная рекомендация

совместный запрос mysql с тремя таблицами (таблица сотрудников, таблица отделов, таблица зарплат)

1. Краткое изложение проблемы: (внизу есть инструкция по созданию таблицы, копирование можно непосредственно практиковать с помощью (mysql)) Найдите отделы, в которых есть хотя бы один сотрудник. Отоб.


[Загрузчик классов обучения JVM] Третий день пользовательского контента, связанного с загрузчиком классов


IP, сеанс и cookie

date

10.12.2019

directory

CentOS, Linux

comments

комментариев 6

В этой статье мы рассмотрим настройку отказоустойчивой конфигурации из двух прокси серверов squid для доступа пользователей в Интернет из корпоративной сети с простой балансировкой нагрузки через Round Robin DNS. Для построения отказоустойчивой конфигурации мы создадим HA-кластер с помощью keepalived.

  • Проверка состояния серверов;
  • Автоматическое переключение ресурсов в случае отказа сервера;

Принципы работы протокола VRRP

В первую очередь нужно рассмотреть теорию и основные определения протокола VRRP.

Общий алгоритм работы:

Важно. Для работы серверов в режиме multicast, сетевое оборудование должно поддерживать передачу multicast трафика.

Установка и настройка keepalived на CentOS

настройка отказоустойчивого балансировщика нагрузки с плавающим IP адресом с помощью keepalived

У каждого Linux сервера есть два физических сетевых интерфейса: eth1 с белым IP адресом и доступом в Интернет, и eth0 в локальной сети.

В качестве виртуальных IP адресов, которые будут автоматически переключаться между серверами в случае сбоев используются:
192.168.2.101
192.168.2.102

Установить пакет keepalived нужно на обоих серверах, командой:

yum install keepalived

После завершения установки на обоих серверах правим конфигурационный файл

Цветом выделены строки с отличающимися параметрами:

на сервере proxy-serv01на сервере proxy-serv02
keepalived - конфиг master сервера
keepalived - конфиг backup сервера

Разберем опции более подробно:

Если текущая сетевая конфигурация не позволяет использовать multicast, в keepalived есть возможность использовать unicast, т.е. передавать VRRP пакеты напрямую серверам, которые задаются списком. Чтобы использовать unicast, понадобятся опции:

Таким образом, наша конфигурация определяет два VRRP экземпляра, proxy_ip1 и proxy_ip2. При штатной работе, сервер proxy-serv01 будет MASTER для виртуального IP 192.168.2.101 и BACKUP для 192.168.2.102, а сервер proxy-serv02 наоборот, будет MASTER для виртуального IP 192.168.2.102, и BACKUP для 192.168.2.101.

Если на сервере активирован файрвол, то нужно добавить разрешающие правила для multicast траффика и vrrp протокола с помощью iptables:

iptables -A INPUT -i eth0 -d 224.0.0.0/8 -j ACCEPT
iptables -A INPUT -p vrrp -i eth0 -j ACCEPT

Активируем автозагрузки и запустим службу keepalived на обоих серверах:

systemctl enable keepalived
systemctl start keepalived

После запуска службы keepalived, виртуальные IP будут присвоены интерфейсам из конфигурационного файла. Посмотрим текущие IP адреса на интерфейсе eth0 серверов:

На сервере proxy-serv01:

ip a show eth0 master keepalived

На сервере proxy-serv02:

ip a show eth0 backup keepalived

Keepalived: отслеживание состояния приложений и интерфейсов

Благодаря протоколу VRRP штатно обеспечивается мониторинг состояния сервера, например, при полном физическом отказе сервера, или сетевого порта на сервере или коммутаторе. Однако, возможны и другие проблемные ситуации:

Для обработки перечисленных выше ситуаций, воспользуемся следующими опциями:

Обновим конфигурацию, добавим мониторинг интерфейса eth1 (по умолчанию, VRRP экземпляр будет проверять интерфейс, к которому он привязан, т.е. в текущей конфигурации eth0):

Директива track_script запускает скрипт с параметрами, определенными в блоке vrrp_script, который имеет следующий формат:

Настроим мониторинг работы Squid. Проверить, что процесс активен, можно командой:

Создадим vrrp_script, с параметрами периодичности выполнения каждые 3 секунды. Этот блок определяется за пределами блоков vrrp_instance.

Добавим наш скрипт в мониторинг, внутри обоих блоков vrrp_instance:

Теперь при ошибке в работе службы прокси Squid, виртуальный IP адрес переключится на другой сервер.

Вы можете добавить дополнительные действия при изменении состояния сервера.

то Squid не узнает о том, что в системе появился новый адрес, на котором нужно слушать запросы от клиентов. Для обработки подобных ситуаций, когда нужно выполнить дополнительные действия при переключении виртуального IP адреса, в keepalived заложена возможность выполнения скрипта при наступлении события изменения состояния сервера, например, с MASTER на BACKUP, или наоборот. Реализуется опцией:

Keepalived: тестирование переключения при отказе

На сервере proxy-serv01:

keepalived - state DOWN

На сервере proxy-serv02:

keepalived - state up

Как и ожидалось, сервер proxy-serv02 активировал у себя виртуальный IP адрес 192.168.2.101. Посмотрим, что при этом происходило в логах, командой:

cat /var/log/messages | grep -i keepalived

на сервере proxy-serv01на сервере proxy-serv02
Keepalived получает сигнал, что интерфейс eth0 находится в состоянии DOWN, и переводит VRRP экземпляр proxy_ip1 в состояние FAULT, освобождая виртуальные IP адреса.Keepalived переводит VRRP экземпляр proxy_ip1 в состояние MASTER, активирует адрес 192.168.2.101 на интерфейсе eth0 и отправляет gratuitous ARP.

VRRP Entering FAULT STATE
VRRP_Instance Transition to MASTER STATE

И проверим, что после включения в сеть интерфейса eth0 на сервере proxy-serv01, виртуальный IP 192.168.2.101 переключится обратно.

на сервере proxy-serv01на сервере proxy-serv02
Keepalived получает сигнал о восстановлении интерфейса eth0 и начинает новые выборы MASTER для VRRP экземпляра proxy_ip1. После перехода в состояние MASTER, активирует адрес 192.168.2.101 на интерфейсе eth0 и отправляет gratuitous ARP.Keepalived получает пакет с большим приоритетом для VRRP экземпляра proxy_ip1 и переводит proxy_ip1 в состояние BACKUP и освобождает виртуальные IP адреса.

Вторая проверка – имитация сбоя интерфейса внешний сети, для этого отключим от сети внешний сетевой интерфейс eth1 сервера proxy-serv01. Результат проверки проконтролируем по логам.

на сервере proxy-serv01на сервере proxy-serv02
Keepalived получает сигнал, что интерфейс eth1 находится в состоянии DOWN, и переводит VRRP экземпляр proxy_ip1 в состояние FAULT, освобождая виртуальные IP адреса.Keepalived переводит VRRP экземпляр proxy_ip1 в состояние MASTER, активирует адрес 192.168.2.101 на интерфейсе eth0 и отправляет gratuitous ARP.

Keepalived Now in FAULT state

на сервере proxy-serv01на сервере proxy-serv02
Скрипт проверки активности службы прокси squid завершается с ошибкой. Keepalived переводит VRRP экземпляр proxy_ip1 в состояние FAULT, освобождая виртуальные IP адреса.Keepalived переводит VRRP экземпляр proxy_ip1 в состояние MASTER, активирует адрес 192.168.2.101 на интерфейсе eth0 и отправляет gratuitous ARP.

Все три проверки пройдены успешно, keepalived настроен корректно. В продолжении этой статьи будет произведена настройка HA-кластера с помощью Pacemaker, и рассмотрена специфика каждого из этих инструментов.


Этом цикле статей «Идеальный www кластер», я хочу передать базовые основы построения высокодоступного и высокопроизводительного www решения для нагруженных web проектов для неподготовленного администратора.
Статья будет содержать пошаговую инструкцию и подойдет любому человеку кто освоил силу copy-paste
Ошибки найденые вами, помогут в работе и мне и тем кто будет читать эту статью позже! Так что любые улучшение и правки приветствуются!

Хочу отметить, что эта инструкция родилась в процессе миграции web-систем компании Acronis в высокодоступный кластер. Надеюсь мои заметки будут полезны и для Вас!.

В процессе экспертизы и проведенных мною исследований, она доказала свое право на жизнь и благополучно служит нам верой и правдой день ото дня.

На frontend мы будем использоваться связку из двух службы:

keepalived — реализации протокола VRRP (Virtual Router Redundancy Protocol) для Linux. Демон keepalived следит за работоспособностью машин и в случае обнаружения сбоя — исключает сбойный сервер из списка активных серверов, делегируя его адреса другому серверу.

  • Обслуживание статических запросов, индексных файлов, автоматическое создание списка файлов, кэш дескрипторов открытых файлов;
  • Акселерированное обратное проксирование с кэшированием, простое распределение нагрузки и отказоустойчивость;
  • Акселерированная поддержка FastCGI, uwsgi, SCGI и memcached серверов с кэшированием, простое распределение нагрузки и отказоустойчивость;
  • Модульность, фильтры, в том числе сжатие (gzip), byte-ranges (докачка), chunked ответы, XSLT-фильтр, SSI-фильтр, преобразование изображений; несколько подзапросов на одной странице, обрабатываемые в SSI-фильтре через прокси или FastCGI, выполняются параллельно;
  • Поддержка SSL и расширения TLS SNI.


Важно! Для приведенного ниже решения, у нас должно быть 2 сетевых интерфейса на каждой из нод keepalived
мы должны точно указать нашу маску и понимать где в нашей сети находится broadcast, если этого не сделать, то будем очень долго пытаться понять почему у нас все работает не так как мы хотим!

То есть в моей публичной сети, маска /29 и значит мой broadcast x.x.x.55, если бы была сеть /24, то можно было бы указать x.x.x.255
Если это перепутать, то вы отгребете кучу проблем

Теперь можно попеременно выключать сервера, опускать интерфейсы, дергать провода итд
У нас в сети всегда будут присутствовать оба этих адреса и на них будет отвечать наш nginx


Favorite

Добавить в избранное

Главное меню » Операционная система CentOS » Балансировка нагрузки с HAProxy, Nginx и Keepalived в Linux (CentOS)

Настройка балансировщика нагрузки в Linux с помощью Nginx, HAProxy и Keepalived

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

Что такое балансировка нагрузки?

Обработка трафика на одном сервере

В этом примере, если веб-сервер не работает, веб-запрос пользователя не может быть доступен в режиме реального времени. Кроме того, если число пользователей запрашивает одну и ту же веб-страницу одновременно, то обслуживание веб-запроса пользователя одним веб-сервером может быть медленным процессом. Следовательно, балансировщики нагрузки используются для повышения производительности сервера, обеспечения резервного копирования и предотвращения сбоев.

В этой статье мы собираемся настроить балансировщик нагрузки для веб-сервера с помощью Nginx, HAProxy и Keepalived. Ниже показан пример того, как выглядят серверы с балансировщиками нагрузки.

Балансировка нагрузки с HAProxy, Nginx и Keepalived в Linux

Использование балансировки нагрузки для эффективной обработки высокого трафика

Итак, что такое Nginx, Haproxy и Keepalived?

nginx

HAProxy

Функция Haproxy заключается в пересылке веб-запроса от конечного пользователя к одному из доступных веб-серверов. Он может использовать различные алгоритмы балансировки нагрузки как Round Robin, Least Connections и т. д.

Keepalived

Что делать, если haproxy балансировки нагрузки упадет?

Keepalived является программой с открытым исходным кодом, которая поддерживает балансировку нагрузки и высокую доступность. Это в основном программное обеспечение маршрутизации и обеспечивает два типа балансировки нагрузки:

  • Уровень 4 (транспортный уровень)
  • Уровень 7 (прикладной уровень)

Keepalived может выполнять следующие функции:

  • Проверка работоспособности (работают ли серверы или нет)
  • Реализует третий уровень (виртуальных избыточность протокола маршрутизации) для балансировки нагрузки, отказоустойчивости

Keepalived использования для VIP (виртуальный IP-адрес) как плавающий IP, который плавает между мастером балансировки нагрузки и резервного копирования балансировки нагрузки и используется для переключения между ними. Если главный балансировщик нагрузки отключается, то резервный балансировщик нагрузки используется для пересылки веб-запроса.

Давайте перейдем к моделированию того, как высокая доступность и балансировка нагрузки поддерживается для веб-серверов.

Настройка балансировщика нагрузки в Linux с помощью Nginx, HAProxy и Keepalived

Настройка балансировщика нагрузки в Linux с помощью Nginx, HAProxy и Keepalived

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

Мы использовали CentOS в качестве дистрибутива Linux в этой статье. Вы можете использовать другие дистрибутивы Linux, но мы не можем гарантировать, что все команды (особенно установочные) будут работать в других дистрибутивах.

Требования к настройке подсистемы балансировки нагрузки

4 сервера с установленной системой CentOS (минимальная установка достаточно для этого учебника)

  • 2 CentOS для установки с nginx
  • 2 CentOS для настройки с HAProxy и Keepalived

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

Шаг 1: Настройка веб-серверов с Nginx

В этой части мы будем использовать две системы CentOS в качестве веб-сервера. Сначала нужно установить Nginx на них.

Для этого добавьте репозиторий, содержащий nginx, и установите его оттуда:

После установки nginx запустите службу Nginx:

Включите службу nginx после каждой загрузки:

Проверка статуса сервиса nginx:

Разрешите веб-трафик в nginx, который по умолчанию блокируется брандмауэром CentOS.

Повторите описанные выше шаги и на веб-сервере второго CentOS.

Теперь обратите внимание на следующие шаги.

Веб-файлы для nginx находится в каталоге /usr/share/nginx/html. Изменение содержимого индекса.html-файл только для идентификации веб-серверов.

Для первого веб-сервера:

Для второго веб-сервера:

Если вы находитесь на виртуальной машине, лучше установить и настроить Nginx на одной системе, а затем клонировать систему. После этого можно перенастроить вторую систему. Экономит время и уменьшает число ошибок.

или в терминале, curl Local_IP_Address. Пример здесь:

Вы получите такой выход:

Балансировка нагрузки с HAProxy, Nginx и Keepalived в Linux

Шаг 2: Настройка балансировщиков нагрузки с HAProxy

В двух других системах для установки HAProxy используйте следующие команды:

Файл конфигурации HAProxy находится в каталоге /etc/haproxy. Перейдите в каталог и создайте резервную копию файла перед редактированием.

Создайте новый файл haproxy.cfg и откройте файл с помощью любого редактора, который Вам нравится.

Теперь вставьте следующие строки в файл:

Теперь включите и запустите службу HAProxy.

Проверка состояния HAProxy:

или в терминале, используйте команду $ curl LoadBalancer_IP_Address

curl два раза, и вы увидите различные выходы для команды curl. Это происходит из-за того, что ответ поступает от разных веб-серверов (по одному за раз), для вашего запроса в подсистеме балансировки нагрузки.

Выходные данные будут выглядеть следующим образом:

Балансировка нагрузки с HAProxy, Nginx и Keepalived в Linux

Шаг 3: Настройка высокой доступности с Keepalived

Keepalived должен быть установлен в обеих системах haproxy load balancer CentOS (которые мы только что настроили выше). Один действует как главный (основной балансировщик нагрузки), а другой действует как резервный балансировщик нагрузки.

В обеих системах выполните следующую команду:

Конфигурационный файл Keepalived находится на файле /etc/keepalived/keepalived.conf . Создайте резервную копию исходного файла поддержки.conf и используйте следующую конфигурацию в новом файле keepalived .conf.

Вставьте следующие строки в файл конфигурации (не забудьте изменить адреса электронной почты):

Виртуальные IP-адреса могут быть любым реальным IP внутри вашей сети. Около диапазона IP-адреса Loadbalancer. Здесь, IP балансировщика нагрузки являются: 10.13.211.194 & 10.13.211.120, и VIP является 10.13.211.10

Отредактируйте файл конфигурации в соответствии с системным предположением. Позаботьтесь о главной и резервной конфигурации. Сохраните файл и запустите и включите процесс Keepalived:

Просмотр состояния Keepalived:

Если вы находитесь на виртуальной машине, лучше установить и настроить Haproxy и Keepalived на одной системе, а затем клонировать систему. После этого можно перенастроить вторую систему. Это экономит время и уменьшает количество ошибок.

Теперь, чтобы проверить состояние балансировщика нагрузки высокой доступности, перейдите к терминалу и нажмите:

Нажмите ctrl+c , чтобы остановить запущенный терминал.

Выходные данные будут выглядеть следующим образом:

Балансировка нагрузки с HAProxy, Nginx и Keepalived в Linux

Мы надеемся, что этот учебник помог вам настроить балансировщик нагрузки в Linux с высокой доступностью. Конечно, это была простая настройка, но она определенно дает представление о балансировке нагрузки и обработке высокой доступности.

Если у вас есть вопросы или предложения, пожалуйста, оставьте комментарий ниже

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

keepalived — реа­ли­за­ции про­то­ко­ла VRRP (Virtual Router Redundancy Protocol) для Linux. Демон keepalived сле­дит за рабо­то­спо­соб­но­стью машин и в слу­чае обна­ру­же­ния сбоя — исклю­ча­ет сбой­ный сер­вер из спис­ка актив­ных сер­ве­ров, деле­ги­руя его адре­са дру­го­му серверу.

VRRP - про­то­кол резер­ви­ро­ва­ния вир­ту­аль­ных марш­ру­ти­за­то­ров, пред­на­зна­чен для повы­ше­ния отка­зо­устой­чи­во­сти сер­ви­сов по сети или орга­ни­за­ции балан­си­ров­ки нагруз­ки меж­ду узла­ми. Отка­зо­устой­чи­вость дости­га­ет­ся объ­еди­не­ни­ем несколь­ких узлов один вир­ту­аль­ным адре­сом, кото­рый пере­на­зна­ча­ет­ся сле­ду­ю­ще­му узлу, при отка­зе основ­но­го узла.

1.Установка Keepalived

Уста­нав­ли­ва­ем keepalived на тех сер­ве­рах меж­ду кото­ры­ми дол­жен пере­клю­чать­ся наш вир­ту­аль­ный IP адрес:
yum install keepalived
добав­ля­ем в автозагрузку
chkconfig keepalived on

Вклю­ча­ем марш­ру­ти­за­цию паке­тов на обо­их балансерах

nano /etc/sysctl.conf

net.ipv4.ip_forward=1

sysctl -p

2.Настройка конфигурационного файлов MasterБалансера

Настрой­ка кон­фи­гу­ра­ци­он­но­го фай­ла Master-балан­се­ра

Созда­ём бэкап конфига:
cp /etc/keepalived/keepalived.conf /etc/keepalived/keepalived.c bakup
редак­ти­ру­ем его:

nano /etc/keepalived/keepalived.conf

! Configuration File for keepalived

global_defs notification_email mid@test.t
>
notification_email_from Andrey@test.t
smtp_server localhost
smtp_connect_timeout 30
! Имен­ное обо­зна­че­ние дан­но­го сервера
router_id centos1
>

! Ука­зы­ва­ем VRRP istance (экзем­пляр). Напри­мер даем ему имя VI_1
vrrp_instance VI_1 !Ста­тус сер­ве­ра в VRRP instance. Может быть MASTER или BACKUP
state MASTER

!State master или backup озна­ча­ет режим в кото­ром запус­ка­ет­ся демон keepalived
!Ука­зы­ва­ем интер­фейс к кото­ро­му будет при­вя­зан VRRP instance
interface eth0
!Ука­зы­ва­ем про­из­воль­но зна­че­ние в интер­ва­ле от 1 до 255, для того что­бы одна­знач­но опре­де­лить instance сре­ди других,
!кото­рые могут быть запу­ще­ны на хосте. Дол­жен быть оди­на­ков на всех хостах в instance.
virtual_router_id 51
! При­о­ри­тет хоста. Тот хост, кото­рый име­ет боль­ший при­о­ри­тет, будет являть­ся MASTER . По-умол­ча­нию зна­че­ние рав­но 100.
priority 100
! Ука­зы­ва­ем вре­мя в секун­дах меж­ду VRRP запро­са­ми меж­ду хоста­ми в instance. ! По-умол­ча­нию 1 секунда.
advert_int 4
!Метод аутен­ти­фи­ка­ции. AH - ipsec Authentication Header PASS - пароль в откры­том виде. AH более без­опа­сен и реко­мен­ду­ет­ся исполь­зо­вать его,
!но в неко­то­рых реа­ли­за­ци­ях keepalived AH метод может не рабо­тать, тогда необ­хо­ди­мо исполь­зо­вать PASS .
authentication auth_type PASS
auth_pass 1111
>

! Указ­ва­ем общий вир­ту­аль­ный ip-адрес для чле­нов VRRP instance. Можем ука­зать како­му интер­фей­су он будет назна­чен, а так же с
! помо­щью дирек­ти­вы "label" ука­зать для него описание.

virtual_ipaddress 192.168.1.158 dev eth0 label eth0:vip
>
>

3.Настройка конфигурационного файла Backup-балансера

Отли­чия лишь в том, что мы изме­ня­ем state уста­нав­ли­вая BACKUP и пони­жа­ем при­о­ри­тет до 90priority 90 кон­фиг ниже:

cat /etc/keepalived/keepalived.conf
! Configuration File for keepalivedglobal_defs notification_email mid@test.t
>
notification_email_from Andrey@test.t
smtp_server localhost
smtp_connect_timeout 30
! Имен­ное обо­зна­че­ние дан­но­го сервера
router_id centos1
>! Ука­зы­ва­ем VRRP istance (экзем­пляр). Напри­мер даем ему имя VI_1
vrrp_instance VI_1 !Ста­тус сер­ве­ра в VRRP instance. Может быть MASTER или BACKUP
state BACKUP !Ука­зы­ва­ем интер­фейс к кото­ро­му будет при­вя­зан VRRP instance
interface eth0
!Ука­зы­ва­ем про­из­воль­но зна­че­ние в интер­ва­ле от 1 до 255,
!для того что­бы одна­знач­но опре­де­лить instance сре­ди других,
!кото­рые могут быть запу­ще­ны на хосте.
!Дол­жен быть оди­на­ков на всех хостах в instance.
virtual_router_id 51
! При­о­ри­тет хоста. Тот хост, кото­рый име­ет боль­ший приоритет,
! будет являть­ся MASTER . По-умол­ча­нию зна­че­ние рав­но 100.
priority 90
! Ука­зы­ва­ем вре­мя в секун­дах меж­ду VRRP запро­са­ми меж­ду хоста­ми в instance.
! По-умол­ча­нию 1 секунда.
advert_int 4
!Метод аутен­ти­фи­ка­ции. AH - ipsec Authentication Header
! PASS - пароль в откры­том виде.
! AH более без­опа­сен и реко­мен­ду­ет­ся исполь­зо­вать его,
!но в неко­то­рых реа­ли­за­ци­ях keepalived AH метод может не работать,
!тогда необ­хо­ди­мо исполь­зо­вать PASS .
authentication auth_type PASS
auth_pass 1111
>! Указ­ва­ем общий вир­ту­аль­ный ip-адрес для чле­нов VRRP instance.
! Можем ука­зать како­му интер­фей­су он будет назна­чен, а так же с
! помо­щью дирек­ти­вы "label" ука­зать для него описание.virtual_ipaddress 192.168.1.158 dev eth0 label eth0:vip
>
>

4.Проверка

и про­ве­ря­ем на масте­ре:

eth0:vip Link encap:Ethernet HWaddr 08:00:27: F5 :22: AE
inet addr:192.168.1.158 Bcast:0.0.0.0 Mask:255.255.255.255
UP BROADCAST RUNNING MULTICAST MTU :1500 Metric:1

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU :65536 Metric:1
RX packets:54 errors:0 dropped:0 overruns:0 frame:0
TX packets:54 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:6657 (6.5 KiB) TX bytes:6657 (6.5 KiB)

на backup:

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU :65536 Metric:1
RX packets:130 errors:0 dropped:0 overruns:0 frame:0
TX packets:130 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:21943 (21.4 KiB) TX bytes:21943 (21.4 KiB)

кла­дём сете­вой интер­фейс на мастере:
[root@centos

eth0:vip Link encap:Ethernet HWaddr 08:00:27: B2 :29: FF
inet addr:192.168.1.158 Bcast:0.0.0.0 Mask:255.255.255.255
UP BROADCAST RUNNING MULTICAST MTU :1500 Metric:1

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU :65536 Metric:1
RX packets:130 errors:0 dropped:0 overruns:0 frame:0
TX packets:130 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:21943 (21.4 KiB) TX bytes:21943 (21.4 KiB)

как видим, всё ОК вир­ту­аль­ный ip 192.168.1.158 успеш­но переназначается

Обновим версию keepalived.

на CENTOS 6 может воз­ник­нут сле­ду­ю­щая ошибка:

[spoiler]
process.c:41: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘realtime_priority_set’
process.c:49: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘priority_set’
process.c: In function ‘set_process_priority’:
process.c:79: error: ‘priority_set’ undeclared (first use in this function)
process.c:79: error: (Each undeclared identifier is reported only once
process.c:79: error: for each function it appears in.)
process.c:79: error: ‘true’ undeclared (first use in this function)
process.c: In function ‘reset_process_priority’:
process.c:91: error: ‘priority_set’ undeclared (first use in this function)
process.c:91: error: ‘false’ undeclared (first use in this function)
process.c: In function ‘reset_process_priorities’:
process.c:141: error: ‘realtime_priority_set’ undeclared (first use in this function)
process.c:150: error: ‘false’ undeclared (first use in this function)
process.c:164: error: ‘priority_set’ undeclared (first use in this function)
make[2]: *** [process.o] Error 1
make[2]: Leaving directory `/opt/keepalived-2.0.7/keepalived/core'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/opt/keepalived-2.0.7/keepalived'
make: *** [all-recursive] Error 1 Для её исправ­ле­ния откры­ва­ем файл:
vim keepalived/core/process.c

про­ве­ря­ем теку­щую версию:
[root@centos

меня­ем бинар­ни­ки ста­рые на новый собран­ный, для нача­ла переименуем/usr/sbin/keepalived /usr/local/sbin/keepalived
mv /usr/sbin/keepalived /usr/sbin/keepalived.bkp

mv /usr/local/sbin/keepalived /usr/local/sbin/keepalived.bkp

cp /opt/keepalived-2.0.7/bin/keepalived /usr/sbin/keepalived
cp /opt/keepalived-2.0.7/bin/keepalived /usr/local/sbin/keepalived

Про­ве­ря­ем, как видим, всё ок:

Config options: LVS VRRP VRRP_AUTH OLD_CHKSUM_COMPAT FIB_ROUTING

System options: PIPE2 SIGNALFD INOTIFY_INIT1 VSYSLOG NET_LINUX_IF_H_COLLISION LIBIPTC_LINUX_NET_IF_H_COLLISION VRRP_VMAC SOCK_NONBLOCK SOCK_CLOEXEC GLOB_BRACE SO_MARK SCHED_RT SCHED_RESET_ON_FORK

Читайте также: