Здравей, Хабр! Представям ви превода на статията автора Andrew Beekhof.
Много хора предпочитат кластери, съставени от два възела, тъй като те изглеждат концептуално по-прости и са с 33% по-евтини от своите тривъзлови събратя. Въпреки че е напълно възможно да се събере добър кластер от два възела, в повечето случаи, поради непредвидени сценарии, такава конфигурация ще създаде много неочевидни проблеми.
Първата стъпка към създаването на всяка система с висока наличност е идентифицирането и опитът за отстраняване на отделни точки на отказ, често наричани SPoF (едничка точка на отказ).
Важно е да имате предвид, че в любая система не може да се премахнат всички възможни рискове от престой. Това произтича поне от факта, че типичната защита от риск е въвеждането на известна излишност, което води до увеличаване на сложността на системата и появата на нови точки на отказ. Следователно, ние първоначално правим компромис и се фокусираме върху събития, свързани с отделни точки на отказ, а не върху взаимосвързани вериги и следователно все по-малко вероятни събития.
Имайки предвид компромисите, ние не само търсим 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.
В този случай препоръчителната алтернатива е създаването на неутрална трета страна, която да може да допълни изчисляването на кворума.
При отказ възелът трябва да има възможност да вижда етерния сигнал на своя партньор или арбитъра, за да възстанови услугите. Арбитърът също включва функция за прекъсване на връзката, ако и двата възела могат да виждат арбитъра, но не виждат един друг.
Тази опция трябва да се използва в комбинация с косвен метод за разделяне, като хардуерен таймер за наблюдение, който е настроен да изгаси машината, ако тя загуби връзка със своя партньор-възел и арбитър. По този начин, оцелелият може с достатъчна сигурност да предположи, че неговият партньор-възел ще бъде в безопасно състояние след изтичането на времето на хардуерния таймер за наблюдение.
Практическото различие между арбитъра и третия възел е, че арбитърът изисква много по-малко ресурси за своята работа и потенциално може да обслужва повече от един клъстер.
Опция 3 – Човешкият фактор
Последният подход е да се позволи на оцелелите да продължат да изпълняват всякакви услуги, които вече вършат, но да не стартират нови, докато или проблемът не се реши сам (възстановяване на мрежата, рестартиране на възела), или човек не поеме отговорност за ръчно потвърждение, че другата страна е мъртва.
Бонус опция
Вече казах ли, че можете да добавите трети възел?
Две рафтове
За аргумента, да предположим, че убедих вас в предимствата на третия възел, сега трябва да разгледаме физическото разположение на възлите. Ако те са разположени (и получават електричество) в същия рафт, това също представлява SPoF, и такъв, който не може да се реши, като се добави втори рафт.
Ако това е изненадващо, помислете какво ще се случи, ако рафтът с двата възла се провали и как оцелелият възел ще различава този случай от срив в мрежата.
Краткият отговор: това е невъзможно, и отново имаме всички проблеми, свързани с двата възла. Или оцелелият:
- игнорира кворума и неправилно се опитва да инициира възстановяване по време на мрежови прекъсвания (възможността за завършване на отделянето е отделна история и зависи от това дали PDU е ангажиран и дали те споделят мощност с някой от рафтовете), или
- уважава кворума и преждевременно се изключва, когато неговият партньор-възел се провали.
Във всеки случай, две рафтове не са по-добри от един, и възлите трябва или да получават независими източници на енергия, или да се разпределят между три (или повече, в зависимост от броя на вашите възли) рафта.
Два дата центъра
В този момент читателите, които вече не са склонни към риск, могат да помислят за възстановяване след инцидент. Какво ще се случи, ако астероид удари един от дата центровете ни с нашите три възла, разпределени по три различни рафта? Очевидно ще има лоши неща, но в зависимост от вашите нужди, добавянето на втори дата център може да не е достатъчно.
Ако всичко е направено правилно, вторият дата център предоставя на вас (което е разумно) актуална и консистентна копия на вашите услуги и техните данни. Въпреки това, както при сценарии с два узла и две рафтове, системата няма достатъчно информация, за да осигури максимална наличност и предотврати повреда (или несъответствие на набори от данни). Дори с три узла (или рафта), тяхното разпределение само в два дата центъра оставя системата неспособна да вземе надеждно правилно решение в случай на (сега много по-вероятно) събитие, което двете страни не могат да свържат.
Това не означава, че решение с два дата центъра никога не е подходящо. Компаниите често искат човек да бъде информиран, преди да предприемат изключителна стъпка за преминаване към резервен дата център. Просто имайте предвид, че ако искате да автоматизирате отказ, ще ви е необходим или трети дата център, за да има кворум (директно или чрез арбитър), или ще трябва да намерите начин надеждно да изключите целия дата център.
Източник: habr.com
