Здравей, Хабър! Представям ви превод на статия автора Andrew Beekhof.
Много хора предпочитат клъстери, състоящи се от два възела, защото изглеждат концептуално по-прости, а и са с 33% по-евтини от техните три-възлови колеги. Въпреки че е напълно възможно да се събере добър клъстер от два възела, в повечето случаи, заради неотчетени сценарии, такава конфигурация ще създаде множество неочевидни проблеми.
Първата стъпка към създаването на всяка система с висока наличност е идентифицирането и опитите за премахване на отделни точки на отказ, често съкратено наричани SPoF (точка на отказ).
Струва си да се има предвид, че в която и да е система е невъзможно да се елиминират всички възможни рискове от прекъсване. Това произтича поне от факта, че типичната защита срещу риск е въвеждането на известна излишност, което води до увеличаване на сложността на системата и появата на нови точки на отказ. Затова първоначално правим компромис и се фокусираме върху събития, свързани с отделни точки на отказ, а не на свързани вериги, които са следователно все по-малко вероятни.
С оглед на компромисите, ние не само търсим SPoF, но също така изчисляваме баланса между рисковете и последиците, в резултат на което заключението за това, какво е критично и какво не, може да варира за всяко разгръщане.
Не на всекиму са необходими алтернативни доставчици на електрическа енергия с независими линии за електрически доставки. Докато параноята се изплати поне за един клиент, когато тяхното наблюдение открива неизправен трансформатор. Клиентът е звънял по телефона, опитвайки се да предупреди електрическата компания, докато неизправният трансформатор не се е взривил.
Естествената отправна точка е системата да има повече от един възел. Въпреки това, преди системата да може да премести услугите на оцелелия след повреда възел, в общия случай е необходимо да се уверите, че преместваните услуги не са активни на друго място.
Два-възловият клъстер няма недостатъци, ако след повреда и двата възела обслужват един и същ статичен уебсайт. Обаче всичко се променя, ако двете страни независимо управляват обща опашка от задачи или предоставят некординиран достъп за запис до реплицирана база данни или обща файлова система.
Следователно, за да предотвратим повреда на данните в резултат на отказ на един възел – ние разчитаме на това, което се нарича „отделяне“ (fencing).
Принцип на отделяне
В основата на принципа на отделяне стои въпросът: може ли конкурентен възел да причини повреда на данните? В случай, че повредата на данните е вероятен сценарий – добро решение би било изолирането на възела от входящите заявки, както и от постоянното хранилище. Най-разпространеният подход за отделяне е изключването на неизправни възли.
Има две категории методи на отделяне, които ще нарека преки и непреки, но в равна степен могат да бъдат наречени активни и пасивни. Преките методи включват действия от страна на оцелелите равноправни възли, като взаимодействие с устройството IPMI (Intelligent Platform Management Interface — интерфейс за дистанционно наблюдение и управление на физическото състояние на сървъра) или iLO (механизъм за управление на сървъри при липса на физически достъп до тях), докато непреките методи разчитат на отказалия се възел, за да разбере, че е в нездравословно състояние (или, поне, пречи на другите членове да се възстановят) и да сигнализира за необходимостта от изключване на отказалия се възел.
Кворумът помага как при използване на преки, така и на непреки методи.
Пряко отделяне
При пряко отделяне можем да използваме кворум, за да предотвратим конфликти на отделянето в случай на мрежов отказ.
С концепцията за кворум в системата има достатъчно информация (дори без свързване с партньорите си), така че възлите автоматично да знаят дали да инициират отделяне и/или възстановяване.
Без кворум и двете страни на мрежовото разделение справедливо предполагат, че другата страна е мъртва и ще се стремят да отделят другия. В най-лошия случай и на двете страни успяват да изключат целия кластер. Алтернативният сценарий е deathmatch, безкраен цикъл на възли, които се появяват, не виждат своите пиери, рестартират ги и инициират възстановяване само за да се рестартират, когато техният пир минава по същата логика.
Проблемата с отбалансирането е, че най-използваните устройства стават недостъпни поради същите откази, на които се надяваме да се фокусираме за възстановяване. Повечето IPMI и iLO карти са инсталирани на хостовете, които контролират, и по подразбиране използват една и съща мрежа, което кара целевите възли да смятат, че останалите възли са офлайн.
За съжаление, особеностите в работата на IPMI и iLO устройства рядко се вземат предвид по време на покупката на оборудване.
Косвено отбалансиране
Кворумът също е важен за управление на косвеното отбалансиране, ако всичко е направено правилно, кворумът може да позволи на оцелелите да предположат, че изгубените възли след определен период от време ще преминат в безопасно състояние.
При такава настройка таймерът на hardware watchdog се нулира на всеки N секунди, ако кворумът не е загубен. Ако таймерът (обикновено кратен на N) изтече, устройството извършва неправилно изключване на захранването (не shutdown).
Този подход е много ефективен, но без кворум за управление не е достатъчно информация в кластерa. Трудно е да се определи разликата между отказ на мрежата и отказ на партньорски възел. Причината, поради която това е важно, е, че без способността да разграничавате тези два случая, вие сте принудени да изберете един и същи режим на поведение и в двете ситуации.
Проблемът с избора на един режим е, че няма начин на действие, който да максимизира наличността и да предотвратява загубата на данни.
- Ако решите да предположите, че партньорският възел е активен, но наистина е настъпил отказ, кластерът излишно ще спре услугите, които трябва да работят за компенсация на загубата на услугите на падналия партньорски възел.
- Ако решите да предположите, че възелът не работи, но това е само отказ на мрежата и всъщност отдалеченият възел функционира, то в най-добрия случай се ангажирате с ръчна проверка на набора от данни в бъдеще.
Независимо от хевристиката, която използвате, е тривиално да създадете отказ, който или ще накара двете страни да работят, или ще принуди кластера да изключи оцелелите възли. Неизползването на кворум наистина лишава кластера от един от най-мощните инструменти в неговия арсенал.
Ако няма друга алтернатива, най-добрият подход е да се жертва достъпността (тук авторът се позовава на 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.
В този случай препоръчителната алтернатива е създаването на неутрална трета страна, която може да допълни изчисляването на кворума.
При отказ възелът трябва да има възможност да вижда ефера на партньора си или арбитъра, за да възстанови услугите. Арбитърът също включва функция за разкъсване на връзката, ако и двата възела могат да виждат арбитъра, но не виждат един друг.
Тази опция трябва да се използва в комбинация с индиректен метод на разединяване, такъв като хардуерен watchdog таймер, който е настроен да изключва машината, ако загуби връзка с партньорския си възел и арбитъра. По този начин оцелелият може с достатъчна увереност да предположи, че неговият партньорски възел ще бъде в безопасно състояние след изтичането на времето на хардуерния watchdog таймер.
Практическата разлика между арбитъра и третия възел е, че арбитърът изисква много по-малко ресурси за функционирането си и потенциално може да обслужва повече от един клъстер.
Опция 3 — Хуманен фактор
Последният подход е оцелелите да продължат да изпълняват всички услуги, които вече са извършвали, но да не стартират нови, докато или проблемът не се разреши сам (възстановяване на мрежата, рестартиране на възела), или човек не поеме отговорност за ръчно потвърждаване на факта, че другата страна е мъртва.
Бонус опция
Още ли казвах, че можете да добавите трети възел?
Две рафтове
В името на аргумента, нека предположим, че съм ви убедил в предимствата на третия възел, сега трябва да разгледаме физическото разположение на възлите. Ако те са разположени (и са захранвани) в същия рафт, това също представлява SPoF, и такъв, който не може да бъде решен просто чрез добавяне на втори рафт.
Ако това е учудващо, помислете какво ще стане, ако рафтът с два възела се провали, и как оцелелият възел ще различи този случай от мрежовия срив.
Краткият отговор: това е невъзможно, и отново имаме работа с всички проблеми при два възела. Или оцелелият:
- игнорира кворума и неправилно се опитва да иницира възстановяване по време на мрежови прекъсвания (възможността за завършване на разделянето — това е отделна история и зависи от това дали PDU е включен и дали споделят захранването с някой от рафтовете), или
- уважава кворума и преждевременно се изключва, когато партньорският му възел претърпи провал
Във всеки случай, две рафтове не са по-добри от един, и възлите трябва или да получават независими източници на захранване, или да бъдат разпределени в три (или повече, в зависимост от броя на възлите) рафта.
Два дата центъра
На този етап читателите, които вече не са склонни към риск, може да започнат да мислят за възстановяване след авария. Какво се случва, когато астероид удари един дата център с нашите три възла, разпределени в три различни рафта? Очевидно, лоши неща, но в зависимост от вашите нужди, добавянето на втори дата център може да е недостатъчно.
Ако всичко е направено правилно, вторият дата център предоставя на вас (и това е разумно) актуално и последователно копие на вашите услуги и техните данни. Въпреки това, както и в сценарии с два възела и две рафтове, системата няма достатъчно информация, за да осигури максимална наличност и да предотврати повреда (или несъответствия в наборите от данни). Дори и с три възела (или рафтове), тяхното разпределение само в два центъра за данни оставя системата неспособна надеждно да взема правилни решения в случай на (сега много по-вероятно) събитие, свързано с двете страни.
Това не означава, че решението с два дата центъра никога не е подходящо. Компаниите често искат човек да бъде информиран, преди да предприеме изключителна стъпка при преминаване към резервен дата център. Просто имайте предвид, че ако искате да автоматизирате отказа, ще ви трябва или трети дата център, за да има кворум (директно или чрез арбитър), или ще трябва да намерите начин надеждно да изключите целия дата център.
Източник: habr.com
