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

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

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

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

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

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

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

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

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

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

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

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

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

Як віртуальних 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
keepalived - конфиг master сервера keepalived - конфиг backup сервера

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

  • vrrp_instance <ім'я> – секція, яка визначає екземпляр VRRP;
  • state – початковий стан при запуску;
  • interface <назва інтефейс> – інтерфейс, на якому буде працювати VRRP;
  • virtual_router_id <число від 0 до 255> – унікальний ідентифікатор VRRP примірника, повинен збігатися на всіх серверах;
  • пріоритет <число від 0 до 255> – задає пріоритет при виборі MASTER, сервер з великим пріоритетом стає MASTER;
  • virtual_ipaddress – блок віртуальних IP адрес, які будуть активні на сервері в стані MASTER. Повинні збігатися на всіх серверах всередині VRRP примірника.

Примітка. Можна зустріти безліч прикладів, в яких під час налаштування VRRP використовується опція автентифікація. Однак в документації підтримується згадується про те, що аутентифікація була видалена з 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:

ip a show eth0 майстер підтримував

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

ip a show eth0 резервна копія збережена

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:

keepalived - стан ВНИЗ

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

keepalived - держава вгору

Як і очікувалося, сервер 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.

VRRP вводить стан несправностіVRRP_Instance Перехід до MASTER STATE

І перевіримо, що після включення в мережу інтерфейсу 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
}
}

Leave a Reply

Your email address will not be published. Required fields are marked *