Привіт, Хабре! Представляю вашій увазі переклад статті автора Andrew Beekhof.
Багато людей віддають перевагу кластерам, що складаються з двох вузлів, тому що вони здаються концептуально простішими, крім того ще й на 33% дешевшими ніж їхні три-вузлові побратими. Хоча цілком реально зібрати хороший кластер із двох вузлів, у більшості випадків, через невраховані сценарії, така конфігурація створить безліч неочевидних проблем.
Першим кроком до створення будь-якої системи високої доступності є пошук та спроба усунення окремих точок відмови, часто скорочено званими SPoF (Single point of failure).
Варто мати на увазі, що у будь-якій системі неможливо усунути всі можливі ризики простою. Це випливає хоча б з того факту, що типовим захистом від ризику є введення певної надмірності, що призводить до збільшення складності системи та появи нових точок відмови. Тому ми спочатку йдемо на компроміс і зосереджуємося на подіях пов'язаних з окремими точками відмови, а не на ланцюжках пов'язаних і, отже, менш ймовірних подій.
Враховуючи компроміси, ми не тільки шукаємо SPoF, але також підбиваємо баланс ризиків та наслідків, в результаті висновок що є критичним, а що ні може відрізнятися для кожного розгортання.
Не всім потрібні альтернативні постачальники електроенергії із незалежними лініями електропередачі. Хоча параноя окупилася принаймні одного клієнта, коли їх моніторинг виявив несправний трансформатор. Замовник дзвонив телефоном, намагаючись попередити енергетичну компанію, допоки несправний трансформатор не вибухнув.
Природною відправною точкою є у системі більше одного вузла. Однак, перш ніж система зможе перемістити сервіси на вузол, що залишився в живих після збою, в загальному випадку, необхідно переконатися, що сервіси, що переміщуються, не активні в якомусь іншому місці.
У двовузлового кластера немає недоліків, якщо в результаті збою обидва вузли обслуговують один і той самий статичний веб-сайт. Однак все змінюється, якщо в результаті обидві сторони незалежно керують спільною чергою завдань або надають некоординований доступ на запис до реплікованої бази даних або загальної файлової системи.
Тому, щоб запобігти пошкодженню даних внаслідок відмови одного вузла – ми покладаємося на те, що називається «відмежування» (Fencing).
Принцип відмежування
В основі принципу відмежування лежить питання: чи може конкуруючий вузол спричинити пошкодження даних? У випадку, якщо пошкодження даних є ймовірним сценарієм – гарним рішенням буде ізоляція вузла як від запитів, так і від постійного сховища. Найбільш поширений підхід до відмежування - відключення несправних вузлів.
Є дві категорії методів відмежування, які я назву прямими и непрямими, але однаково їх можна назвати активними и пасивними. Прямі методи включають дії з боку однорангових вузлів, що вижили, такі як взаємодія з пристроєм IPMI (Intelligent Platform Management Interface — інтерфейс для віддаленого моніторингу та управління фізичним станом сервера) або iLO (механізм управління серверами в умовах відсутності фізичного доступу до них), в той час як непрямі методи покладаються на вузол, що відмовив, щоб якимось чином розпізнати, що він знаходиться в нездоровому стані (або, принаймні, заважає решті членів відновлюватися) і сигналізувати про необхідність відключення вузла, що відмовив.
Кворум допомагає у разі використання як прямих так і непрямих методів.
Пряме відмежування
У разі прямого відмежування ми можемо використовувати кворум для запобігання перегонам відмежування у разі збою мережі.
Маючи в своєму розпорядженні концепцію кворуму, в системі достатньо інформації (навіть без підключення до своїх партнерів), щоб вузли автоматично знали, чи слід їм ініціювати відмежування та/або відновлення.
Без кворуму обидві сторони мережного поділу справедливо припускають, що інша сторона мертва, і прагнуть відмежувати іншого. У гіршому випадку обом сторонам вдається відключити весь кластер. Альтернативний сценарій - deathmatch, нескінченний цикл вузлів, що з'являються, не бачать своїх бенкетів, що перезавантажують їх і ініціюють відновлення тільки для перезавантаження, коли їх бенкет проходить за тією ж логікою.
Проблема з відмежуванням полягає в тому, що найчастіше використовувані пристрої стають недоступними через ті самі події відмови, на які ми хочемо орієнтуватися для відновлення. Більшість карток IPMI та iLO встановлені на хостах, які вони контролюють, і, за замовчуванням, використовують ту саму мережу, через яку цільові вузли вважають, що інші вузли знаходяться в офлайні.
На жаль, особливості роботи пристроїв IPMI та iLo рідко розглядаються в момент покупки обладнання.
Непряме відмежування
Кворум також важливий для управління непрямими відмежуваннями, якщо все зроблено правильно, кворум може дозволити тим, хто вижив, припустити, що втрачені вузли через певний період часу перейдуть у безпечний стан.
При такому налаштуванні таймер hardware watchdog скидається кожні N секунд, якщо кворум не втрачено. Якщо таймер (зазвичай кілька кратних N) спливає, то пристрій виконує ungraceful відключення живлення (не shutdown).
Цей підхід є дуже ефективним, але без кворуму для його управління недостатньо інформації всередині кластера. Нелегко визначити різницю між відключенням мережі та відмовою вузла-партнера. Причина, через яку це має значення, полягає в тому, що без можливості розрізняти два випадки ви змушені вибирати однаковий режим поведінки в обох випадках.
Проблема з вибором одного режиму полягає в тому, що не існує способу дій, який максимально збільшував би доступність і запобігав втраті даних.
- Якщо ви вирішите припустити, що вузол-партнер активний, але насправді стався збій, кластер зайво зупинить служби, які мали б працювати для компенсації втрати служб вузла-партнера, що впав.
- Якщо ви вирішите припустити, що вузол не працює, але це був просто збій мережі і насправді віддалений вузол функціонує, то, у кращому випадку, ви підписуєтеся на деяке майбутнє ручне звіряння результуючих наборів даних.
Незалежно від того, яку евристику ви використовуєте, тривіально створити збій, який або змусить обидві сторони працювати, або змусить кластер відключити вузли, що вижили. Невикористання кворуму справді позбавляє кластер одного з найпотужніших інструментів у його арсеналі.
Якщо немає іншої альтернативи, найкращим підходом пожертвуватиме доступністю (тут автор відсилає до CAP-теореми). Висока доступність пошкоджених даних нікому не допомагає, і вивірка вручну різних наборів даних також не приносить задоволення.
Кворум
Кворум звучить чудово, правда?
Єдиний недолік полягає в тому, що для того, щоб мати його в кластері з членами N, вам потрібно щоб залишалося з'єднання між N / 2 + 1 ваших вузлів. Що неможливо у кластері з двома вузлами після збою одного вузла.
Що зрештою підводить нас до фундаментальної проблеми із двома вузлами:
кворум не має сенсу у двох вузлових кластерах, і без цього неможливо надійно визначити курс дій, який максимально збільшує доступність та запобігає втраті даних.
Навіть у системі з двох вузлів, з'єднаних крос-кабелем, неможливо остаточно провести різницю між відключенням мережі та відмовою іншого вузла. Відключення одного кінця (ймовірність якого, безумовно, пропорційна відстані між вузлами) буде достатньо, щоб спростувати будь-яке припущення, що працездатність каналу дорівнює здоров'ю вузла-партнера.
Примушуємо працювати кластер із двох вузлів
Іноді клієнт не може або не бажає докуповувати третій вузол і ми змушені шукати альтернативу.
Варіант 1 - Дублюючий метод відмежування
Пристрій iLO або IPMI вузла являє собою точку відмови, оскільки, у разі збою, що залишилися живими не можуть використовувати його для переведення вузла в безпечний стан. У кластері з 3 або більше вузлів ми можемо пом'якшити це обчисленням кворуму та використанням hardware watchdog (механізм непрямого відмежування, як було обговорено раніше). У випадку з двома вузлами ми натомість повинні використовувати мережні перемикачі живлення (power distribution units або PDUs).
Після збою той, хто вижив, спочатку намагається зв'язатися з основним пристроєм відмежування (вбудованим iLO або IPMI). Якщо це вдалося, відновлення продовжується як завжди. Тільки у разі збою пристрою iLO/IPMI відбувається звернення до PDU, якщо звернення успішне, відновлення може продовжуватися.
Обов'язково помістіть PDU в мережу, відмінну від трафіку кластера, інакше одиночний збій у мережі заблокує доступ як до пристроїв відмежування, так і заблокує відновлення служб.
Тут Ви можете запитати – чи не є PDU єдиною точкою відмови? На що відповідь, звичайно, є.
Якщо цей ризик значимий для вас — ви не самотні: підключіть обидва вузли до двох PDU і вкажіть кластерне програмне забезпечення використовувати обидва при включенні та вимкненні вузлів. Тепер кластер залишається активним, якщо один PDU вмирає, і для блокування відновлення буде потрібно другий збій або іншого PDU, або IPMI.
Варіант 2 - Додавання арбітра
У деяких сценаріях, хоча технічно можливий метод дублюючого відмежування, він є політично складним. Багатьом компаніям подобається мати певний поділ між адміністраторами і власниками додатків, і мережеві адміністратори, що піклуються про безпеку, не завжди з ентузіазмом ставляться до передачі будь-кому параметрів доступу до PDU.
У цьому випадку альтернативою, що рекомендується, є створення нейтральної третьої сторони, яка може доповнити розрахунок кворуму.
У разі збою вузол повинен мати можливість бачити ефір свого партнера чи арбітра, щоб відновити сервіси. Арбітр також включає функцію розриву зв'язку, якщо обидва вузли можуть бачити арбітра, але не бачать один одного.
Ця опція повинна використовуватися в парі з непрямим методом відмежування, таким як hardware watchdog таймер, який налаштований на гасіння машини, якщо вона втрачає з'єднання зі своїм вузлом-партнером та арбітром. Таким чином, той, хто вижив, може з достатньою впевненістю припустити, що його вузол-партнер буде в безпечному стані після закінчення терміну дії hardware watchdog таймера.
Практична різниця між арбітром і третім вузлом полягає в тому, що арбітр вимагає набагато менше ресурсів для своєї роботи і потенційно може обслуговувати більше одного кластера.
Варіант 3 - Людський фактор
Останній підхід полягає в тому, щоб ті, хто вижив, продовжували виконувати будь-які служби, які вони вже виконували, але не запускати нові, поки або проблема не вирішиться сама (відновлення мережі, перезавантаження вузла), або людина не візьме на себе відповідальність за ручне підтвердження того, що інша сторона мертва.
Бонусна опція
Я вже сказав, що ви можете додати третій вузол?
Дві стійки
Заради аргументу, давайте уявімо, що я переконав вас у перевагах третього вузла, тепер ми повинні розглянути фізичне розташування вузлів. Якщо вони розміщені (і одержують харчування) у тій же стійці, це також являє собою SPoF, і таку, яка не може бути вирішена шляхом додавання другої стійки.
Якщо це дивно, подумайте, що станеться, якщо стійка з двома вузлами вийде з ладу, і як вузол, що вижив, розрізнятиме цей випадок і збій мережі.
Коротка відповідь: це неможливо, і ми знову маємо справу з усіма проблемами у випадку двох вузлів. Або вижив:
- ігнорує кворум і неправильно намагається ініціювати відновлення під час перебоїв у роботі мережі (можливість завершення відмежування - це окрема історія і залежить від того, чи задіяний PDU і чи вони поділяють потужність з будь-якої зі стійок), або
- поважає кворум і передчасно відключає себе, коли його вузол-партнер зазнає невдачі
У будь-якому випадку, дві стійки не кращі за одну, і вузли повинні або отримувати незалежні джерела живлення, або розподілятися по трьох (або більше, залежно від того, скільки у вас вузлів) стояків.
Два дата-центри
На цей момент читачі, які більше не схильні до ризику, можуть подумати про відновлення після аварії. Що відбувається, коли астероїд потрапляє в один центр обробки даних з нашими трьома вузлами, розподіленими за трьома різними стійками? Очевидно, що Bad Things, але в залежності від ваших потреб додавання другого дата-центру може бути недостатньо.
Якщо все зроблено правильно, другий дата-центр надає вам (і це розумно) актуальну та узгоджену копію ваших сервісів та їх даних. Однак, як і в сценаріях з двома вузлами та двома стійками, у системі недостатньо інформації для забезпечення максимальної доступності та запобігання пошкодженню (або розбіжності наборів даних). Навіть за наявності трьох вузлів (або стійок) їх розподіл тільки по двох центрах обробки даних залишає систему нездатною надійно прийняти правильне рішення у випадку (тепер набагато ймовірнішого) події, яку обидві сторони не можуть пов'язати.
Це не означає, що рішення із двома дата-центрами ніколи не підходить. Компанії нерідко хочуть, щоб людина була в курсі, перш ніж зробити винятковий крок у разі переходу на резервний дата-центр. Просто майте на увазі, що якщо ви хочете автоматизувати збій, вам знадобиться або третій дата-центр, щоб кворум мав сенс (безпосередньо або через арбітра), або ви знайдете спосіб надійно відключити весь дата-центр.
Джерело: habr.com