Keepalived настройка високої доступності і плаваючих IP адрес в CentOS 7

У цій статті ми розглянемо настройку відмовостійкої конфігурації з двох проксі серверів squid для доступу користувачів в Інтернет з корпоративної мережі з простою балансуванням навантаження через Round Robin DNS. Для побудови відмовостійкої конфігурації ми створимо HA-кластер за допомогою keepalived.

HA-кластер - це група серверів із закладеною надмірністю, яка створюється з метою мінімізації часу простою додатки, в разі апаратних або програмних проблем одного з членів групи. Виходячи з цього визначення, для роботи HA-кластера необхідно реалізувати наступне:

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

Обидві ці завдання дозволяє виконати keepalived. Keepalived - системний демон на Linux системах, що дозволяє організувати відмовостійкість сервісу та балансування навантаження. Відмовостійкість досягається за рахунок "плаваючого» IP адреси, який переключається на резервний сервер у разі відмови основного. Для автоматичного перемикання IP адреси між серверами keepalived використовується протокол VRRP (Virtual Router Redundancy Protocol), він стандартизований, описаний в RFC (https://www.ietf.org/rfc/rfc2338.txt).

зміст:

  • Принципи роботи протоколу VRRP
  • Установка і настройка keepalived на CentOS
  • Keepalived: відстеження стану додатків і інтерфейсів
  • Keepalived: тестування перемикання при відмові

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

В першу чергу потрібно розглянути теорію і основні визначення протоколу VRRP.

  • VIP - Virtual IP, віртуальний IP адреса, який може автоматично перемикатися між серверами в разі збоїв;
  • Master - сервер, на якому в даний момент активний VIP;
  • Backup - сервера на які переключиться VIP, в разі збою майстра;
  • VRID - Virtual Router ID, сервера об'єднані загальним віртуальним IP (VIP) утворюють так званий віртуальний роутер, унікальний ідентифікатор якого, приймає значення від 1 до 255. Сервер може одночасно перебувати в кількох VRID, при цьому для кожної VRID повинні використовуватися унікальні віртуальні IP адреси.

Загальний алгоритм роботи:

  • Master сервер із заданим інтервалом відправляє VRRP пакети на зарезервований адресу multicast (многоадресной) розсилки 224.0.0.18, а все slave сервера слухають цю адресу. Multicast розсилка - це коли відправник один, а одержувачів може бути багато.
    важливо. Для роботи серверів в режимі multicast, мережеве обладнання повинно підтримувати передачу multicast трафіка.
  • Якщо Slave сервер не отримує пакети, він починає процедуру вибору Master і якщо він переходить в стан Master за пріоритетом, то активує VIP і отруює gratuitous ARP. Gratuitous ARP - це особливий вид ARP відповіді, який оновлює MAC таблицю на підключених комутаторах, щоб проінформувати про зміну власника віртуального IP адреси і mac адреси для перенаправлення трафіку.

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

Встановлення та налаштування будемо проводити на прикладі серверів proxy-serv01 і proxy-serv02 на Centos 7 з встановленим Squid. У нашій схемі ми будемо використовувати найпростіший спосіб розподілу (балансування) навантаження - Round Robin DNS. Цей спосіб передбачає, що для одного імені в DNS реєструється кілька IP адрес, і клієнти, при запиті отримують по черзі спочатку одну адресу, а потім другий. Тому нам знадобиться два віртуальних IP адреси, які будуть зареєстровані в DNS на одне ім'я і на які в підсумку будуть звертатися клієнти. Схема мережі:

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

В якості реальних IP адрес серверів використовуються:
192.168.2.251 - для proxy-server01
192.168.2.252 - для proxy-server02

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

важливо. При налаштуванні VRRP, як адресу для віртуального IP не використовується реальну адресу сервера, так як, в разі збою, його адреса переміститься на сусідній, і при відновленні, він виявиться ізольованим від мережі. Справа в тому, щоб повернути свою адресу, потрібно відправити в мережу VRRP пакет, але не буде IP адреси, з якого це можливо зробити.

Встановити пакет keepalived потрібно на обох серверах, командою:

yum install keepalived

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

/etc/keepalived/keepalived.conf

Кольором виділені рядки з відмінними параметрами:

на сервері proxy-serv01на сервері proxy-serv02

Розберемо опції більш докладно:

  • vrrp_instance - секція, яка визначає екземпляр VRRP;
  • state - початковий стан при запуску;
  • interface - інтерфейс, на якому буде працювати VRRP;
  • virtual_router_id - унікальний ідентифікатор VRRP примірника, повинен збігатися на всіх серверах;
  • priority - задає пріоритет при виборі MASTER, сервер з великим пріоритетом стає MASTER;
  • virtual_ipaddress - блок віртуальних IP адрес, які будуть активні на сервері в стані MASTER. Повинні збігатися на всіх серверах всередині VRRP примірника.
Примітка. Можна зустріти безліч прикладів, в яких під час налаштування VRRP використовується опція authentication. Однак в документації keepalived згадується про те, що аутентифікація була видалена з VRRPv2 в специфікації RFC3768 (https://tools.ietf.org/html/rfc3768) в 2004 році, так як не забезпечувала реальної безпеки. Рекомендується уникати використання цієї опції.

Якщо поточна мережева конфігурація не дозволяє використовувати multicast, в keepalived є можливість використовувати unicast, тобто передавати VRRP пакети безпосередньо серверів, які задаються списком. Щоб використовувати unicast, знадобляться опції:

  • unicast_src_ip - адреса джерело для VRRP пакетів;
  • unicast_peer - блок IP адрес серверів, на які будуть розсилатися VRPP пакети.

Таким чином, наша конфігурація визначає два 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 серверів:

ip a show eth0

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

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

Keepalived: відстеження стану додатків і інтерфейсів

Завдяки протоколу VRRP штатно забезпечується моніторинг стану сервера, наприклад, при повному фізичному відмову сервера, або мережевого порту на сервері або комутаторі. Однак, можливі й інші проблемні ситуації:

  • помилка в роботі служби проксі сервера - клієнти, які потраплять на віртуальний адреса цього сервера, будуть отримувати повідомлення в браузері з помилкою, що проксі сервер недоступний;
  • відмова в роботі другого інтерфейсу в інтернет - клієнти, які потраплять на віртуальний адреса цього сервера, будуть отримувати повідомлення в браузері з помилкою, що не вдалося встановити з'єднання.

Для обробки перерахованих вище ситуацій, скористаємося наступними опціями:

  • track_interface - моніторинг стану інтерфейсів, переводить VRRP екземпляр в стан FAULT, якщо один з перерахованих інтерфейсів знаходиться в стані DOWN;
  • track_script - моніторинг з використанням скрипта, який повинен повертати 0 якщо перевірка завершилася успішно, 1 - якщо перевірка завершилася з помилкою.

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

track_interface eth1

Директива track_script запускає скрипт з параметрами, визначеними в блоці vrrp_script, який має такий вигляд:

vrrp_script script interval - періодичність запуску скрипта, за замовчуванням 1 секунда fall - кількість разів, яке скрипт повернувся не нульове значення, при якому перейти в стан FAULT rise - кількість разів, яке скрипт повернув нульове значення, при якому вийти зі стану FAULT timeout - час очікування, поки скрипт поверне результат, після якого повернути нульове значення. weight - значення, на яке буде зменшений пріоритет сервера, в разі переходу в стан FAULT. За умовчанням 0, що означає, що сервер перейде в стан FAULT, після невдалого виконання скрипта за кількість разів, певне параметром fall.

Налаштуємо моніторинг роботи Squid. Перевірити, що процес активний, можна командою:

squid -k check

створимо vrrp_script, з параметрами періодичності виконання кожні 3 секунди. Цей блок визначається за межами блоків vrrp_instance.

vrrp_script chk_squid_service script "/ usr / sbin / squid -k check" interval 3

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

track_script chk_squid_service

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

Ви можете додати додаткові дії при зміні стану сервера.

Якщо Squid налаштований на прийом підключень з будь-якого інтерфейсу, тобто http_port 0.0.0.0:3128, то при перемиканні віртуального IP адреси, ніяких проблем не виникне, Squid буде приймати підключення на нову адресу. Але, якщо налаштовані конкретні IP адреси, наприклад:

http_port 192.168.2.101:3128 http_port 192.168.2.102:3128

то Squid не знатиме про те, що в системі з'явився новий адресу, на якому потрібно слухати запити від клієнтів. Для обробки подібних ситуацій, коли потрібно скористатися додатковими функціями при перемиканні віртуального IP адреси, в keepalived закладена можливість виконання скрипта при настанні події зміни стану сервера, наприклад, з MASTER на BACKUP, або навпаки. Реалізується опцією:

notify "шлях до виконуваного файлу"

Keepalived: тестування перемикання при відмові

Після настройки віртуальних IP, перевіримо, наскільки коректно відбувається обробка збоїв. Перша перевірка - імітація збою одного з серверів. Відключимо від мережі внутрішній мережевий інтерфейс eth0 сервера proxy-serv01, при цьому він перестане відправляти VRRP пакети і сервер proxy-serv02 повинен активувати у себе віртуальний IP адреса 192.168.2.101. Результат перевіримо командою:

ip a show eth0

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

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

Як і очікувалося, сервер proxy-serv02 активував у себе віртуальний IP адреса 192.168.2.101. Подивимося, що при цьому відбувалося в логах, командою:

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

на сервері proxy-serv01на сервері proxy-serv02
Keepalived_vrrp [xxxxx]: Kernel is reporting: interface eth0 DOWN Keepalived_vrrp [xxxxx]: VRRP_Instance (proxy_ip1) Entering FAULT STATE Keepalived_vrrp [xxxxx]: VRRP_Instance (proxy_ip1) removing protocol VIPs. Keepalived_vrrp [xxxxx]: VRRP_Instance (proxy_ip1) Now in FAULT state
Keepalived_vrrp [xxxxx]: VRRP_Instance (proxy_ip1) Transition to MASTER STATE
Keepalived отримує сигнал, що інтерфейс eth0 знаходиться в стані DOWN, і переводить VRRP екземпляр proxy_ip1 в стан FAULT, звільняючи віртуальні IP адреси.Keepalived переводить VRRP екземпляр proxy_ip1 в стан MASTER, активує адресу 192.168.2.101 на інтерфейсі eth0 і відправляє gratuitous ARP.

І перевіримо, що після включення в мережу інтерфейсу eth0 на сервері proxy-serv01, віртуальний IP 192.168.2.101 переключиться назад.

на сервері proxy-serv01на сервері proxy-serv02
Keepalived_vrrp [xxxxx]: VRRP_Instance (proxy_ip1) forcing a new MASTER election Keepalived_vrrp [xxxxx]: VRRP_Instance (proxy_ip1) Transition to MASTER STATE Keepalived_vrrp [xxxxx]: VRRP_Instance (proxy_ip1) Entering MASTER STATE Keepalived_vrrp [xxxxx]: VRRP_Instance (proxy_ip1) setting protocol VIPs. Keepalived_vrrp [xxxxx]: Sending gratuitous ARP on eth0 for 192.168.2.101
Keepalived_vrrp [xxxxx]: VRRP_Instance (proxy_ip1) Received advert with higher priority 255, ours 100 Keepalived_vrrp [xxxxx]: VRRP_Instance (proxy_ip1) Entering BACKUP STATE Keepalived_vrrp [xxxxx]: VRRP_Instance (proxy_ip1) removing protocol VIPs.
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_vrrp [xxxxx]: Kernel is reporting: interface eth1 DOWN Keepalived_vrrp [xxxxx]: VRRP_Instance (proxy_ip1) Entering FAULT STATE Keepalived_vrrp [xxxxx]: VRRP_Instance (proxy_ip1) removing protocol VIPs. Keepalived_vrrp [xxxxx]: VRRP_Instance (proxy_ip1) Now in FAULT state
Keepalived_vrrp [xxxxx]: VRRP_Instance (proxy_ip1) Transition to MASTER STATE Keepalived_vrrp [xxxxx]: VRRP_Instance (proxy_ip1) Entering MASTER STATE Keepalived_vrrp [xxxxx]: VRRP_Instance (proxy_ip1) setting protocol VIPs. Keepalived_vrrp [xxxxx]: Sending gratuitous ARP on eth0 for 192.168.2.101
Keepalived отримує сигнал, що інтерфейс eth1 знаходиться в стані DOWN, і переводить VRRP екземпляр proxy_ip1 в стан FAULT, звільняючи віртуальні IP адреси.Keepalived переводить VRRP екземпляр proxy_ip1 в стан MASTER, активує адресу 192.168.2.101 на інтерфейсі eth0 і відправляє gratuitous ARP.
Третя перевірка - імітація збою роботи служби проксі Squid, для цього вручну залишимо службу командою: systemctl stop squid Результат перевірки проконтролюємо по логам.
на сервері proxy-serv01на сервері proxy-serv02
Keepalived_vrrp [xxxxx]: VRRP_Script (chk_squid_service) failed Keepalived_vrrp [xxxxx]: VRRP_Instance (proxy_ip1) Entering FAULT STATE Keepalived_vrrp [xxxxx]: VRRP_Instance (proxy_ip1) removing protocol VIPs. Keepalived_vrrp [xxxxx]: VRRP_Instance (proxy_ip1) Now in FAULT state
Keepalived_vrrp [xxxxx]: VRRP_Instance (proxy_ip1) Transition to MASTER STATE Keepalived_vrrp [xxxxx]: VRRP_Instance (proxy_ip1) Entering MASTER STATE Keepalived_vrrp [xxxxx]: VRRP_Instance (proxy_ip1) setting protocol VIPs. Keepalived_vrrp [xxxxx]: Sending gratuitous ARP on eth0 for 192.168.2.101
Скрипт перевірки активності служби проксі squid завершується з помилкою. Keepalived переводить VRRP екземпляр proxy_ip1 в стан FAULT, звільняючи віртуальні IP адреси.Keepalived переводить VRRP екземпляр proxy_ip1 в стан MASTER, активує адресу 192.168.2.101 на інтерфейсі eth0 і відправляє gratuitous ARP.
Всі три перевірки пройдено успішно, keepalived налаштований коректно. У продовженні цієї статті буде зроблена настройка HA-кластера за допомогою Pacemaker, і розглянута специфіка кожного з цих інструментів.
Підсумковий конфігураційний файл /etc/keepalived/keepalived.conf для сервера proxy-serv01:
vrrp_script chk_squid_service script "/ usr / sbin / squid -k check" interval 3 vrrp_instance proxy_ip1 state MASTER interface eth0 virtual_router_id 1 priority 255 virtual_ipaddress 192.168.2.101/24 dev eth0 label eth0: 1 track_interface eth1 track_script chk_squid_service  vrrp_instance proxy_ip2 state BACKUP interface eth0 virtual_router_id 2 priority 100 virtual_ipaddress 192.168.2.102/24 dev eth0 label eth0: 2 track_interface eth1 track_script chk_squid_service 
Підсумковий конфігураційний файл /etc/keepalived/keepalived.conf для сервера proxy-serv02:
vrrp_script chk_squid_service script "/ usr / sbin / squid -k check" interval 3 vrrp_instance proxy_ip1 state BACKUP interface eth0 virtual_router_id 1 priority 100 virtual_ipaddress 192.168.2.101/24 dev eth0 label eth0: 1 track_interface eth1 track_script chk_squid_service  vrrp_instance proxy_ip2 state MASTER interface eth0 virtual_router_id 2 priority 255 virtual_ipaddress 192.168.2.102/24 dev eth0 label eth0: 2 track_interface eth1 track_script chk_squid_service 












Категорія