Балансування навантаження з Pacemaker і IPaddr (Active/Active cluster)


Хочу розповісти вам ще про один спосіб балансування навантаження.
Про Pacemaker і IPaddr (ресурс-агент) і встановлення для Active/Passive кластера сказано вже досить багато, але інформації щодо організації повноцінного Active/Active кластера, використовуючи цей модуль я знайшов вкрай мало. Спробую виправити цю ситуацію.
Для початку розповім детальніше ніж такий метод балансування примітний:
  • Відсутність зовнішнього балансувальника — На всіх ноди в кластері настроюється один загальний віртуальну IP-адресу. Усі запити надсилаються на нього. Ноди відповідають на запити на цю адресу випадково і за домовленістю між ссобой.
  • Висока доступність — Якщо одна нода падає її обов'язки підхоплює інша.
  • Простота налаштування — Настройка здійснюється в 3-5 команд.
Ввідні дані
Давайте подивимося на картинку на початку статті, ми побачимо наступні пристрої:
  • Gateway IP: 192.168.100.1
  • HostA IP: 192.168.100.101
  • HostB IP: 192.168.100.102
  • HostC IP: 192.168.100.103
Клієнти будуть звертатися на зовнішній адресу нашого шлюзу, той буде перенаправляти всі запити на віртуальний IP 192.168.100.100, який буде налаштований на всіх трьох ноди нашого кластера.
Підготовка
Для початку нам потрібно переконатися в тому, що всі наші ноди можуть звертатися один до одного по single hostname, для надійності краще відразу додати адреси нод
/etc/hosts
:
192.168.100.101 hostA
192.168.100.102 hostB
192.168.100.103 hostC

Встановимо всі необхідні пакети:
yum install pcs pacemaker corosync #CentOS, RHEL
apt-get install pcs pacemaker corosync #Ubuntu, Debian

При установці pcs створює користувача
hacluster
, давайте задамо йому пароль:
echo CHANGEME | passwd --stdin hacluster 

Далі операції виконуються на одному вузлі.
Налаштовуємо аутентифікацію:
pcs cluster auth HostA HostB HostC -u hacluster -p CHANGEME --force 

Створюємо і запускаємо кластер «Cluster» з трьох вузлів:
pcs cluster setup ----force name Cluster hostA hostB hostC
pcs cluster start --all

Дивимося результат:
pcs cluster status

висновок
Cluster Status:
Last updated: Thu Jan 19 12:11:49 2017
Last change: Tue Jan 17 21:19:05 2017 by hacluster via crmd on hostA
Stack: corosync
Current DC: hostA (version 1.1.14-70404b0) - partition with quorum
3 nodes and 0 resources configured
Online: [ hostA hostB hostC ]

PCSD Status:
hostA: Online
hostB: Online
hostC: Online

Деякі кроки були запозичені з статті Lelik13a, спасибі йому за це.
У нашому конкретному випадку ні кворум ні stonith нашому кластеру не потрібно, так що сміливо відключаємо і те і інше:
pcs property set no-quorum-policy=ignore
pcs property set stonith-enabled=false

В подальшому, якщо у вас з'являться ресурси для яких це необхідно, ви можете звернутися до статті Silvar.
Пара слів про MAC-адреси
Перш ніж ми приступимо, нам потрібно розуміти, що на всіх наших ноди буде налаштований однаковий IP і однаковий mac-адресу, за запитом на який вони будуть по черзі давати відповіді.
Проблема в тому, що кожен комутатор працює таким чином, що під час роботи він складає свою таблицю комутації, в якій кожен mac-адресу зв'язується з певним фізичним портом. Таблиця комутації складається автоматично, і служить для розвантаження мережі від "непотрібних" L2-пакетів.
Так от, якщо mac-адреса є в таблиці комутації, то пакети будуть відправлятися тільки в один порт за яким і закріплений цей самий mac-адресу.
На жаль, нам це не підходить і нам необхідно впевнитися в тому, що б всі наші хости в кластері одночасно "бачили" всі ці пакети. В іншому випадку ця схема працювати не буде.
Для початку нам потрібно упевнитися в тому, що використовуваний нами mac-адресу multicast-адресою. Тобто знаходиться в діапазоні
01:00:5E:00:00:00
01:00:5E:7F:FF:FF
. Отримавши пакет для такої адреси наш комутатор буде передавати його в усі інші порти, крім порту джерела. Крім того, деякі керовані комутатори дозволяють налаштувати і визначити кілька портів для конткретного MAC-адреси.
Також вам, ймовірно, доведеться відключити функцію Dynamic ARP Inspection, якщо вона підтримується вашим комутатором, так як вона може стати причиною блокування arp-відповіді від ваших хостів.
Налаштування IPaddr-ресурсу
Ось ми і дісталися до самого цікавого.
На даний момент існує дві версії IPaddr з підтримкою клонування:
  • IPaddr2 (
    ocf:heartbeat:IPaddr2
    ) — Стандартний ресурс-агент для створення і роботи віртуального IP-адреси. Як правило встановлюється разом зі стандартним пакетом
    resource-agents
    .
  • IPaddr3 (
    ocf:percona:IPaddr3
    ) — Поліпшена версія IPaddr2 від Percona.
    У цю версію включені виправлення орієнтовані на роботу саме в режимі clone.
    Потрібна окрема установка.
Для установки IPaadr3 виконайте ці команди на кожному хості:
curl --create-dirs -o /usr/lib/ocf/resource.d/percona/IPaddr3 \
https://raw.githubusercontent.com/percona/percona-pacemaker-agents/master/agents/IPaddr3
chmod u+x /usr/lib/ocf/resource.d/percona/IPaddr

Далі операції виконуються на одному вузлі.
Створимо ресурс для нашого віртуального IP-адреси:
pcs resource create ClusterIP ocf:percona:IPaddr3 \
params ip="192.168.100.100" cidr_netmask="24" nic="eth0" clusterip_hash="sourceip-sourceport" \
op monitor interval="10s"

clusterip_hash — тут потрібно вказати бажаний тип розподілу запитів.
Всього може бути три варіанти:
  • sourceip
    — розподіл тільки за IP-адресою джерела, це гарантує, що всі запити від одного джерела завжди будуть потрапляти на один і той самий хост.
  • sourceip-sourceport
    — розподіл IP-адреси джерела і вихідного порту. Кожне нове з'єднання буде потрапляти на новий хост. Оптимальний варіант.
  • sourceip-sourceport-destport
    — розподіл за IP-адресою джерела вихідному порту і порту призначення. Забезпечує найкращий розподіл, актуально якщо у вас працює кілька сервісів на різних портах.
Для IPaddr2 обов'язково потрібно вказати параметр
mac=01:00:5E:XX:XX:XX
з mac-адресою з multicast-діапазону. IPaddr3 встановлює його автоматично.
Тепер склонируем наш ресурс:
pcs resource clone ClusterIP \
meta clone-max=3 clone-node-max=3 globally-unique=true

Це дія створить таке правило в
iptables
:
правило
Chain INPUT (policy ACCEPT)
target prot opt source destination 
all -- anywhere 192.168.100.100 CLUSTERIP hashmode=sourceip-sourceport clustermac=01:00:5E:21:E3:0B total_nodes=3 local_node=1 hash_init=0

Як ви можете помітити, тут використовується модуль
CLUSTERIP
.
він Працює наступним чином:
На три ноди приходять всі пакети, але всі три Linux-ядра знають скільки нод отримує пакети, всі три ядра нумерують одержувані пакети по единному правилом, і, знаючи, скільки всього нод і номер своєї ноди, кожен сервер обробляє тільки свою частину пакетів, інші пакети сервером ігноруються — їх обробляють інші сервера.
Детальніше про це написана в цій статье.
Давайте ще раз подивимося на наш кластер:
pcs cluster status

висновок
Cluster Status:
Cluster name: cluster
Last updated: Tue Jan 24 19:38:41 2017
Last change: Tue Jan 24 19:25:44 2017 by hacluster via crmd on hostA

Stack: corosync
Current DC: hostA (version 1.1.14-70404b0) - partition with quorum
3 nodes and 0 resources configured
Online: [ hostA hostB hostC ]

Full list of resources:

Clone Set: ClusterIP-clone [ClusterIP-test] (unique)
ClusterIP:0 (ocf:percona:IPaddr3): Started hostA
ClusterIP:1 (ocf:percona:IPaddr3): Started hostB
ClusterIP:2 (ocf:percona:IPaddr3): Started hostC

PCSD Status:
hostA: Online
hostB: Online
hostC: Online

IP-адреси успішно запустилися. Спробуємо звернутися до них ззовні.
Якщо все працює як треба, то на цьому налаштування можна вважати закінченою.
Посилання
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.