продовжуємо
Продовжуємо створення кластера, розпочате першої частини.
На цей раз я розповім про настройку кластера.
Минулого разу ми закінчили на тому, що почалася синхронізація DRBD.
Якщо ми як Primary сервера для обох ресурсів вибрали один і той же сервер, то після завершення синхронізації повинні в / proc / drbd побачити приблизно таку картину:
Найцікавіше поле тут ds: UpToDate / UpToDate. що означає що і локальна та дистанційна копія актуальні.
Після цього переведемо ресурси в secondary режим - далі ними буде керувати кластер:
Отже, менеджер кластера.
Pacemaker використовує інфраструктуру Corosync для взаємодії між вузлами кластера, тому для початку потрібно буде налаштувати її.
Corosync має досить широкий функціонал і кілька режимів для підтримки зв'язку між нодамі (unicast, multicast, broadcast), має підтримку RRP (Redundant Ring Protocol), яка дозволяє використовувати кілька різних шляхів для спілкування між нодамі кластера для мінімізації ризику отримати Split-brain, то є ситуації, коли зв'язок між нодамі повністю пропадає, і вони обидві вважають що сусід помер. В результаті обидві Ноди переходять в робочий режим і починається хаос :)
Тому ми будемо використовувати як реплікаційний, так і зовнішній інтерфейси для забезпечення зв'язності кластера.
Приступимо до налаштування
Його потрібно покласти під ім'ям / etc / corosync / authkey на обидва сервера.
Далі створимо конфиг, він повинен бути ідентичний на обох нодах:
Все, можна запускати Pacemaker (він запустить Corosync попередньо).
Вся настройка Pacemaker відбувається через утиліту crm. причому запускати її можна на будь-якому сервері в кластері - він автоматично оновить конфігурацію на всіх нодах після зміни.
Подивимося поточний статус:
Якщо все приблизно так, то зв'язок встановлена і Ноди один одного бачать.
Тепер нам знадобляться ресурси для управління SCST.
Я свого часу знайшов їх десь на просторах інтернету, модифікував під свої потреби і виклав на Github.
- SCSTLun - управляє створенням пристроїв
- SCSTTarget - управляє створенням iSCSI таргет
Це, по суті, звичайні bash-скрипти, що реалізують нескладний API Pacemaker.
Покласти їх слід в /usr/lib/ocf/resource.d/heartbeat. щоб менеджер кластера їх побачив.
Далі запускаємо crm і входимо в режим настройки:
Наведу приклад конфігурації:
Загальні настройки кластера
Вони знаходяться в самому низу. З важливих тут no-quorum-policy = «ignore» і expected-quorum-votes = «2» - у нас кластер з 2 серверів і кворуму тут бути не може ну ніяк, тому ігноруємо його.
Ще є спеціальні ресурси, наприклад DRBD (ocf: linbit: drbd), які мають режими Master / Slave.
При переході Ноди в активний режим менеджер кластера буде переводити ресурс в режим майстер і навпаки. DRBD при цьому буде переключатися з Secondary в Primary. Для нього ми вказуємо ім'я ресурсу і шлях до конфіга DRBD (напевно, його можна опустити, точно не пам'ятаю).
Далі йдуть наші самописние ресурси.
Для ocf: heartbeat: SCSTLun ми вказуємо IQN таргета, в який він буде доданий, ім'я пристрою. номер LUN -а (у таргета обов'язково повинен бути LUN 0, інакше у деяких ініціаторів зносить дах), шлях до експортованого пристрою і обробник (handler).
На обработчике потрібно зупинитися докладніше - це спосіб, яким SCST буде працювати з нашим пристроєм.
З цікавих це:- disk - по суті це просто прямий кидок SCSI команд від ініціатора до SCSI пристрою, найпростіший режим, але працює тільки з реальними SCSI пристроями, нам не підходить, тому що експортуємо DRBD-пристрій
- vdisk_blockio - відкриває пристрій як блочне, обходячи page-cache операційної системи. Використовується, якщо не потрібно кешувати введення-виведення
- vdisk_fileio - відкриває пристрій як файл, дозволяючи використовувати page-cache операційної системи, найпродуктивніший режим, його і виберемо
У vdisk_fileio є важливий параметр, що впливає на швидкість - nv_cache = 1. він прописаний жорстко в SCSTLun.
Цей параметр говорить SCST ігнорувати команди ініціатора для скидання кешу на пристрій. Потенційно, це може привести до втрати даних в разі аварійного відключення сховища тому ініціатор думатиме, що дані на диску, а вони ще в пам'яті. Так що використовуйте на свій страх і ризик.
Після цього можна подивитися поточну ситуацію:
Ми бачимо, що ресурси в неактивному стані, DRBD в режимі Slave (Secondary).
Тепер можна спробувати їх активувати:
Якщо все так, то можна себе привітати - кластер запущений!
Кожна група ресурсів запущена на своєму сервері, як це зазначено в конфіги директивою location.
Для підтвердження можна подивитися лог ядра - dmesg - туди DRBD і SCST виводять свою діагностику.
Кінець другої частини
У третій, заключній, частині я покажу як налаштувати сервера ESXi на оптимальну роботу з цим кластером.
1. У кожної нормальної ресурсу є API-команда Monitor, яку Pacemaker використовує для перевірки стану ресурсу. Її виклик активується параметрів monitor у ресурсу, можна задати дію при помилку. За замовчуванням кластер рестарту ресурс, але можна поставити режим standby. який викличе міграцію всіх ресурсів зі збою Ноди. Можна вказати кількість помилок перезапуску, після яких пройде міграція.
Перед запуском кластера я систему дуже довго мучив, і стабільність софтової частини мене більш ніж влаштувала, тому я поки не став активувати цей режим - якщо комусь це потрібно, то робиться це за дві секунди.
Взагалі, у Pacemaker дуже багато можливостей - зацікавлені можуть заглянути в документацію, це не тема одного або навіть декількох статей.
Що таке «перевірка по шатдаун» не зрозумів. Так, і drbd живе в ядрі, його kill -9 не візьмеш.
2. Якого роду тести, наприклад? Мережа висмикувати, харчування однієї з нод вирубувалося, свитч один вирубувався. Все відпрацьовував як треба.
І ще, так як практично весь робочий софт знаходиться в ядрі (SCST, DRBD), то його збій приведе до краху ядра (особливо якщо включити додатково panic_on_oops) і нода, по суті, буде мертва, що виявить друга нода.
Перекидання IP-шника для ESXi проходить гладко, таймаут Corosync за замовчуванням - 4 секунди, таймаут iSCSI в ESXi - 10 секунд.
Так що все проходить дуже швидко і практично непомітно для ВМ.
1. Хм. On-fail = standby? Коли я пробував, - він працював зовсім не так, як треба. Не пам'ятаю правда що саме було не так. І пророкувати ваги, тобто планувати роботу кластера за вагами - толком не виходить. У підсумку ваги ми стали міняти правилом яке дивилося на параметр для саморобного ocf ресурсу.
Перевіркою по shutdown - в даному контексті, це коли перевірка працездатності ресурсів кластера безпосередньо не проводиться, а вважається, що ресурс завжди доступний - поки нода жива. Нода померла - значить ресурс не доступний.
2. Дивіться, гіпотетично, у вас відвалюється DRBD на одній з нод.
По-перше, цілком можливо що вся pacemaker нода не піде у ребут по kernel panic відразу.
По-друге, навіть якщо це так - це що ж, добре навантажена виртуалка 4 секунди буде висіти чекаючи доступ до диска?
DRBD додали таки в ядро? Ну треба ж. Кльово.
3. Чи були за час використання подібної схеми в production збої у вас, коли одна з нод з тих чи інших причин падала? Стандартно чи відпрацьовував перемикання кластера і чи не було проблем на віртуалкою в ESXi?
Поясню своє питання - подібні схеми здатні жити роками поки, в якийсь момент не опиниться, що вони не працюють.
1. На даний момент він працює так, як написано в документації - якщо падає хоч один ресурс, то всі ресурси переїжджають на запасну ноду.
Я взагалі-то і не надаю сервіс - я роблю високодоступних сховище для свого ж vSphere кластера, не більше того.
Я розумію, що можна багато чого навертеть і додати ще пару дев'яток до доступності, але мені вистачає і того, що є :)
А надання сервісу і всі інші параметри (стан дисків, масивів, DRBD, мережі і т.п.) у мене моніторяться окремо Zabbix-му і якщо щось відбувається не передбачене конфіг кластера, то я буду реагувати вже сам.
Щодо STONITH я думав (на основі IPMI), але вирішив, що це надмірно.
А третю witness-ноду так, сенс зробити має, тільки ось в Pacemaker немає простого сбособа додати просто ноду-свідка.
Можна зробити третьої ноді standby = on, але на ній повинні бути всі ті ж ресурси (DRBD по крайней мере), тому що кластер буде їх намагатися моніторити. Другий спосіб - не запускати взагалі Pacemaker, а залишити тільки Corosync, але я не впевнений що це гарна ідея, потрібно перевіряти. Але швидше за все цей спосіб самий оптимальний.
2. Що значить - відвалюється? Глюк в софті? Тоді ядро піде в резет відразу, це налаштовується в sysctl (kernel.panic)
По-друге, навіть якщо це так - це що ж, добре навантажена виртуалка 4 секунди буде висіти чекаючи доступ до диска?
А в чому проблема? У всіх поширених осях таймаут на I / O до диска набагато вище (в Лінуксі хвилина, в винде теж начебто) і його завжди можна задерти при необхідності.
Я спеціально робив виртуалку, яка щодуху писала на диск і вбивав активну ноду по харчуванню - ніякої лайки з боку гостьової ОС не було, все продовжувало працювати як треба.
DRBD додали таки в ядро? Ну треба ж. Кльово.
Так, додали, але це нічого не змінює.
Модулем воно або в ядро інтегровано - різниці з точки зору роботи ніякої.
Я, як видно, збираю його модулем тому в ядрі старіша версія.
3. Чи були за час використання подібної схеми в production збої у вас, коли одна з нод з тих чи інших причин падала?
Стандартно чи відпрацьовував перемикання кластера і чи не було проблем на віртуалкою в ESXi?
Ні, тьху тьху, все працює поки чітко. Але перед продакшеном я, як писав вище, всяке симулював і вело воно себе передбачувано.
Поясню своє питання - подібні схеми здатні жити роками поки, в якийсь момент не опиниться, що вони не працюють.
Я згоден, що в моїй конфігурації не все передбачено, але для конкретно моїх вимог цього більш ніж достатньо.
І я постарався поведінку кластера перевірити у всіх більш-менш реальних ситуаціях.
я реалізував по іншому, маємо freebsd + zfs + carp і два ідентичних сервера, все це справа працює як майстер слейв, при відвалі майстра піднімається слейв, злий забирає з майстра снепшот і накочує собі зберігаючи дерево снепшот, при призначення слейв майстром, накатка снепшот припиняється , і можна в зворотному порядку хильнути.
Я ZFS люблю всією душею (особливо за клони-снапшоти і контрольні суми), юзаю його будинку, але по продуктивності він до звичайних рейдів не дотягує, плавали, знаємо. А якщо відключити в ньому все плюшки, що знижують продуктивність, то він виходить нічим не краще традиційних методів - чудес не буває.
на 6Гб контролері прекрасно себе почуває.
Наведіть будь ласка тести вашого рішення (запис, читання, рендомная запис)
на 6Гб контролері прекрасно себе почуває.
Наведіть будь ласка тести вашого рішення (запис, читання, рендомная запис)
При чому тут контролер абсолютно не ясно, особливо в плані ZFS, якому контролер взагалі протипоказаний.
Тестів ZFS у мене під рукою немає, можу поганяти вільне поки сховище з RAID10 масивами на LSI 9271, але там ніяких сюрпризів, я думаю, не буде.
Consequently, many ZFS and Linux MD RAID users, such as me, look for non-RAID controllers that are simply reliable, fast, cheap, and otherwise come with no bells and whistles. Most motherboards have up to 4 or 6 onboard ports (be sure to always enable AHCI mode in the BIOS as it is the best designed hardware interface that a chip can present to the OS to enable maximum performance)
(С) blog.zorinaq.com/?e=10
Наведіть хоча б порівняльний синтетичний тест, що не dd. А припустимо інсерти пару мільйонів рядків. Якщо Вам цікаво можу свої дані привести. Мене почали мінусувати просто так, забавно. Критика і свою думку вже не вітається?
Я можу потестировать через fio, але який у цьому сенс? Щоб порівнювати свідчення потрібно мати ідентичні із залізною точки зору системи, щоб це порівняння було справедливим. Я можу потестировать бекенд SCST_NULLIO безвідносно дискової підсистеми, але тоді незрозуміло що ми міряємо.
де я згадував що використовую рейд? мій контролер не працює в режимі рейду, а всього лише дає мені потрібну швидкість. Причому так включений як зазначено в одній з Ваших посилань. Може ви просто не вмієте готувати raidz? На скільки мені відомо один з Російських cdn використовують в такому ж режимі як і я і витримують серйозні навантаження.
Що міряти та операції в секунду що ще.
Я вам казав приведи ВАши цифри по тестах своєї системи, припустимо підключіть лун і туди базу розгорніть, припустимо я тестував розгорнув туди базу ДіаСофт, поруч з навантаженим Луном розмістив інкрементні бекапи postgres,
де я згадував що використовую рейд? мій контролер не працює в режимі рейду, а всього лише дає мені потрібну швидкість
У чому різниця між контролером, «що дає потрібну швидкість» і просто прямим підключенням дисків до контролера на материнській платі або ще десь?
Може ви просто не вмієте готувати raidz?
Може і не вмію, тут є якась секретна магія, поділіться?
Що міряти та операції в секунду що ще.
Де? На скількох дисках? На 2, 5, 7, 10, 30? На якому рівні RAID? Або може на SSD? Яке відношення записи \ читання?
Невже незрозуміло що факторів, що впливають на результат, дуже багато. У мене кілька різних сховищ з різними дисковими системами і різними технологіями підключення (iSCSI 1Gb / 10Gb, FC) і результати у всіх дуже різні.
raidz зібраний з 16 дисків по 2ТБ +1 диск для Спера + кеши на двох ssd. Без додаткового контролера ніяк не обійтися і плюс додаткові налаштування. Ось так я готую zfs для продакшена.
Міряти саме на пулі zpool iostat. З приводу каналу говорив же, мабуть не уважно читали гігабітні порти зібрані в lacp.
Тим самим складом, що резервує канал ще. Якщо ви використовуєте zfs в linux тоді до Вас питань більше немає.