Кластер Corosync + Pacemaker: де ламається відмовостійкість
Відмовостійкий кластер на Corosync і Pacemaker виглядає надійним рівно до першого реального збою. Найчастіше вузол не падає повністю — він залишається в мережі, ресурс вважається запущеним, а застосунок не відповідає.
Якщо перевірка відстежує лише наявність процесу й запускається раз на хвилину, тихий збій виявляється через десять хвилин простою, коли частину запитів уже втрачено безповоротно.
Втрата кворуму — друга за частотою причина аварій під час налаштування відмовостійкого кластера. На двох вузлах без окремого кворум-пристрою кожна половина після обриву зв'язку вважає себе легітимною, і обидві продовжують керувати спільними ресурсами.
Лікується це кворум-диском або коректною політикою очікування, а неуважне налаштування обертається подвійним записом у базу й розходженням даних, яке розбирати довше, ніж сам кластер.
Помилкове перемикання виникає там, де час запуску ресурсу більший за встановлений тайм-аут. База або черга піднімається довше, ніж чекає Pacemaker, ресурс позначається як збійний і переїжджає на сусідній вузол, де історія повторюється. Кластер починає ганяти сервіс по колу, а навантаження на вцілілих вузлах лише зростає.
І останнє — ручне відновлення сервісу під навантаженням. Якщо ізоляцію вузла не налаштовано, під час розщеплення залишається гасити половину кластера руками й звіряти дані рядок за рядком. Правильно зібраний кластер такі сценарії відпрацьовує сам — розбираємо, як це закривається.
Що дає керована відмовостійкість: ефект у цифрах
Кластер із двох-трьох вузлів з кворумом переживає відмову вузла без ручного втручання: менеджер ресурсів помічає втрату за секунди й піднімає сервіс на живому вузлі.
Час відновлення сервісу вимірюється тут не годинами чергового розбору, а десятками секунд — за умови, що залежності та порядок запуску описані в конфігурації, а не відновлюються з пам'яті.
Частка відмов, що переходять в автоматику, — головна метрика впровадження.
Поки перемикання роблять руками, кожен інцидент тримає сервіс недоступним до приходу інженера; після налаштування Pacemaker відмова диска, мережі або процесу закривається сама, і заявка в чергову зміну не відкривається взагалі.
Простій сервісу перестає залежати від того, хто з команди на зв'язку і як швидко він прочитає повідомлення.
Навантаження на чергову зміну падає відповідно: нічні виклики залишаються лише на сценарії, які справді потребують рішення, — не на перезапуск ресурсу й не на ручне переведення сервісу на інший вузол.
Окремо вимірюємо хибні спрацювання. Кворум, інтервали перевірок і політики відновлення підбираються так, щоб кластер не перемикався на короткій деградації мережі: інакше автоматика шкодить сильніше, ніж допомагає.
Відмовостійкість linux — це баланс між швидкістю реакції та стійкістю до короткочасних збоїв, і у звіті ми показуємо обидва числа.
Способи організації відмовостійкості: порівняння підходів
Схему відмовостійкості обирають за трьома вхідними: скільки вузлів у розпорядженні, чи є спільне сховище і на скількох майданчиках розміщено сервери. Від них залежить, як кластер набирає кворум і чим ізолює вузол, що втратив зв'язок з іншими.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Два вузли зі спільним сховищем | Пара серверів і спільний дисковий масив | Кворум із двох голосів нестабільний: потрібен третій голос або надійна ізоляція, інакше розділення мережі дає дві активні копії |
| Три вузли й більше | Сервіс без спільного сховища, реплікація на рівні застосунку | Більше заліза й точок відмови; частина сервісів усе одно потребує плаваючої адреси |
| Дві рознесені майданчики | Вимога пережити відмову цілого майданчика | Затримка між майданчиками обмежує синхронну реплікацію; під час розриву зв'язку кворум дістається одній стороні, другу виводять вручну |
| Один вузол із холодним резервом | Некритичні сервіси й рідкі вікна простою | Відновлення руками, простій вимірюється годинами, стан даних відстає |
Вибір зводиться до компромісу: чим менше вузлів, тим гостріше питання кворуму, чим далі майданчики, тим дорожча синхронність. Для двох вузлів без спільного сховища третій голос або зовнішній арбітр — не ускладнення, а умова коректного автоматичного відновлення.
Далі розбираємо, як це збирається: конфігурація кворуму, політики ізоляції та порядок запуску ресурсів — ті місця, де схема або тримає відмову, або розвалюється сама.
Етапи налаштування: від аудиту до передачі в експлуатацію
Аудит інфраструктури починається з інвентаризації: які сервіси мають переживати відмову вузла, які в них залежності, де проходить службовий трафік і що вже налаштовано в частині кворуму та fencing.
Без цієї картини кластер збирають за шаблоном, і перший же реальний збій викриває, що критичний ресурс запускався без обмежень порядку. Далі робота йде кроками — від схеми до передачі.
Послідовність робіт
- Обстеження. Фіксуємо склад вузлів, спільних томів і мережевих сегментів, збираємо вимоги до часу відновлення для кожного сервісу.
- Проєктування схеми. Визначаємо топологію, кількість кілець зв'язку, наявність кворум-пристрою, склад ресурсів і правила їх розміщення по вузлах.
- Підготовка вузлів. Синхронізація часу, службова мережа, автентифікація між вузлами, розмітка спільних сховищ — база, на якій кластер поводиться передбачувано.
- Налаштування Corosync і Pacemaker. Ресурси, групи, обмеження порядку запуску, політики відновлення, fencing-агент під конкретну інфраструктуру.
- Перевірка перемикань. Проганяємо планову міграцію, відмову вузла, обрив каналу зв'язку та втрату кворуму — до того, як це станеться в бою.
- Регламенти й документація. Схема кластера, карта ресурсів, порядок штатного обслуговування вузла, сценарії діагностики.
- Передача в експлуатацію. Розбираємо з командою поведінку кластера на стенді, показуємо, як читати стан і що робити під час спрацювання fencing.
Конфігурації, схеми й регламенти: комплект передачі
Кластер передається не як «робоча система, яку краще не чіпати», а як комплект: конфігурації, схеми й регламенти, за якими чергова зміна та ваш інженер діють без нас. Нижче — що фізично залишається у вас у репозиторії та внутрішній базі знань.
- Конфігурації кластера в системі контролю версій: параметри Corosync, описи ресурсів Pacemaker, правила кворуму й тайм-аути — з історією змін і позначкою, чому обрано кожен параметр.
- Політики доступу: ролі адміністраторів і чергових, права на перезапуск ресурсів, редагування конфігурації та ручне виведення вузла в обслуговування.
- Схема відмовостійкості: які вузли, диски й мережеві шляхи резервують одне одного, де точку відмови залишено свідомо, як кластер поводиться під час втрати кворуму.
- Інструкція для чергової зміни: покрокові дії під час типових подій — вузол не повернувся після перезавантаження, ресурс переїхав не туди, стани вузлів розійшлися.
- План відновлення: порядок підйому кластера з нуля, повернення конфігурації з репозиторію, перевірка цілісності даних після аварійного перемикання.
- Регламент перевірок: планові навчання з вимкненням вузла, контроль спрацювання захисних механізмів, оновлення схем після змін в інфраструктурі.
- Журнал рішень: які сценарії відпрацьовано на навчаннях, які обмеження залишилися і що свідомо винесено за межі налаштування.
Кейс: як скоротили простій під час відмови вузла
Замовник — сервіс із безперервним потоком заявок: три вузли, репліка бази, балансувальник. Відмовостійкість формально була — ресурси описано в Pacemaker, служба синхронізації стежила за доступністю вузлів.
Але перемикання залишалося ручним: черговий помічав відмову за моніторингом, піднімав сервіс на вцілілому вузлі й уже потім розбирався з причиною.
Заміри за пів року до переробки: середній час простою під час відмови вузла — 47 хвилин, із них близько десяти йшло на виявлення, решта — на ручні кроки з перевіркою стану бази.
Керівник зміни витрачав на відновлення сервісу приблизно годину, і частина відмов припадала на години пік, коли кожна хвилина простою видна клієнтам.
Що змінили
Зібрали ресурси в керовану групу з жорстким порядком запуску — спочатку база, потім застосунок, — і налаштували кворум на трьох вузлах.
Додали ізоляцію вузла, що відмовив: той, хто втратив зв'язок з іншими, відключається від спільних ресурсів раніше, ніж другий вузол почне роботу, тому розщеплення не виникає.
Окремо обмежили кількість перезапусків і заборонили автоматичне зворотне перенесення, щоб ресурси не «гуляли» між вузлами.
Після переведення схеми в автоматичний режим середній час відновлення сервісу — близько 25 секунд: дві-три на виявлення, решта на передачу ресурсів і підйом застосунку.
За дев'ять місяців жодна відмова вузла не потребувала ручного втручання, а планові перевірки — почергова перезагрузка вузлів у непікові вікна — проходять без втрати заявок.
Відмова вузла з інциденту перетворилася на штатну подію, про яку команда дізнається з журналу, а не від клієнтів.
Чим відрізняється кластер із двох вузлів від трьох?
Кворум — це арифметика голосів, і від неї залежить уся логіка відмови. У кластері з трьох вузлів більшість — два голоси: втрата однієї машини залишає кластер робочим, ресурси переїжджають на живі вузли.
У парі вузлів строгої більшості немає, тому Corosync використовує окремий режим голосування, де вузол довіряє партнерові, поки бачить його.
Ціна такої економії — розщеплення кластера. Якщо рветься канал між двома вузлами, кожна сторона вважає партнера таким, що впав, і піднімає сервіс на себе.
Для бази даних або спільного тому це розходження даних і ручний розбір, тому примусова ізоляція вузла тут не опція, а умова запуску.
Третій вузол не зобов'язаний нести навантаження: у ролі арбітра він лише бере участь у голосуванні, тому вимоги до нього мінімальні. Проміжний варіант — винести вирішальний голос на окремий хост: він розпізнає розщеплення, але не прийме сервіси під час відмови основної машини.
Супровід зростає разом із кількістю вузлів: три машини — три набори оновлень, ключів і точок моніторингу, зате менше ручних розборів після збоїв.
Двовузловий кластер простіше обслуговувати, але він потребує дисципліни: окремий канал зв'язку між вузлами, робочий пристрій ізоляції, регулярні навчання з відмов.
Типова помилка — обирати за принципом «менше машин, менше клопоту», не перевіривши, чи переживе пара вузлів розрив зв'язку. Зворотна помилка — три вузли, завантажені майже до межі: після відмови одного решта не витягують трафік. Рахувати варто не машини, а відмови, які сервіс зобов'язаний переживати.
Технічні сумніви: розбираємо часті запитання
Запитання, які найчастіше уточнюють до старту: від відповідей залежить схема мережі та склад вузлів. Нижче — поведінка системи в аварійних сценаріях.
Що станеться, якщо вузли перестануть бачити один одного?
Кластер втрачає кворум і зупиняє ресурси на ізольованій частині — сервіс залишається на боці більшості. Другим каналом налаштовуємо контроль живучості, а механізм ізоляції примусово вимикає відрізаний вузол до того, як він віддасть ресурс. Без ізоляції сама кворум-політика сенсу не має.
Чи можна обійтися без спільного сховища?
Так. Реплікацію даних бере на себе сервіс — репліка бази або розподілене сховище, — а кластер керує роллю та плаваючою адресою. Налаштовуємо порядок запуску, перевірку готовності та заборону піднімати копію на вузлі із застарілими даними. Спільний том потрібен там, де застосунок не вміє реплікацію.
Як переконатися, що перемикання справді працює?
Проганяємо штатну міграцію, жорстке вимкнення активного вузла, обрив каналу та падіння самого сервісу.
Фіксуємо час перемикання, цілісність даних і поведінку під час повернення вузла — саме повернення найчастіше дає нестабільну схему: ресурс піднімається на вузлі без актуальної копії.
Обговоримо задачу: що уточнимо перед початком робіт
Щоб оцінка спиралася на факти, а не на припущення, розбір задачі починаємо з вхідних щодо інфраструктури та сервісів.
Нам потрібні не загальні слова, а конкретика: скільки вузлів планується, які сервіси мають переживати відмову вузла, за який час перемикання зобов'язане вкладатися. За цими даними ми рахуємо обсяг робіт і склад кластера Corosync + Pacemaker.
Що уточнюємо на першій розмові:
- склад сервісів: що переводимо в кластер, що зобов'язане працювати без перерви, а що допускає короткий простій;
- кількість вузлів і топологія: розподіл по стійках і зонах, окремий інтерфейс під службовий трафік;
- ізоляція вузла, що відмовив: керовані блоки живлення, контролери віддаленого керування або засоби гіпервізора — без неї кворум не рятує від розділення;
- сховище: дисковий масив, реплікація на рівні блокового пристрою або розподілена файлова система;
- вимоги до перемикання: цільовий час відновлення сервісу та допустима втрата даних;
- поточний стан: дистрибутив і актуальна гілка, схема мережі, моніторинг, доступи, вікна для робіт.
Список не обов'язково готувати заздалегідь — частина відповідей знайдеться прямо в розмові. Опишіть задачу, і ми повернемося з оцінкою, схемою кластера та планом впровадження за етапами: з точками перевірки, порядком запуску ресурсів і порядком відкату.
