Хей Хабр! Представям на вашето внимание превода на статията от Андрю Бийкхоф.
Много хора предпочитат клъстери с два възела, защото те изглеждат концептуално по-прости и също така с 33% по-евтини от своите колеги с три възела. Въпреки че е възможно да се събере добър клъстер с два възела, в повечето случаи, поради неотчетени сценарии, тази конфигурация ще създаде много неочевидни проблеми.
Първата стъпка в създаването на всяка система с висока достъпност е да се намерят и опитат да се елиминират отделни точки на повреда, често наричани SPoF (единична точка на отказ).
Струва си да се има предвид, че във всяка система е невъзможно да се премахнат всички възможни рискове от прекъсване. Това произтича най-малкото от факта, че типична защита срещу риска е въвеждането на известна излишност, което води до увеличаване на сложността на системата и появата на нови точки на повреда. Следователно ние първоначално правим компромис и се фокусираме върху събития, свързани с отделни точки на повреда, а не върху вериги от свързани и следователно все по-малко вероятни събития.
Имайки предвид компромисите, ние не само търсим SPoF, но и балансираме рисковете и последствията, което води до заключението кое е критично и кое не може да се различава за всяко внедряване.
Не всеки има нужда от алтернативни доставчици на електроенергия с независими преносни линии. Въпреки че параноята се отплати за поне един клиент, когато техният мониторинг установи дефектен трансформатор. Клиентът се обаждаше по телефона, опитвайки се да предупреди енергийната компания, докато дефектният трансформатор не избухна.
Естествената отправна точка е да имате повече от един възел в системата. Въпреки това, преди системата да може да премести услуги към оцелял възел, обикновено трябва да се гарантира, че услугите, които се преместват, не са активни другаде.
Няма недостатък на клъстер с два възела, ако и двата възела обслужват един и същ статичен уебсайт в резултат на повреда. Нещата обаче се променят, ако и двете страни в крайна сметка управляват независимо споделена опашка от задачи или предоставят некоординиран достъп за запис до репликирана база данни или споделена файлова система.
Следователно, за да предотвратим повреда на данните в резултат на повреда на един възел - ние разчитаме на нещо, наречено "разграничаване" (фехтовка).
Принципът на дистанциране
Принципът на фехтовка се основава на въпроса: може ли конкуриращ се възел да причини повреда на данните? В случай, че повредата на данните е вероятен сценарий, изолирането на възела както от входящите заявки, така и от постоянното хранилище е добро решение. Най-често срещаният подход за защита е да се изключат повредени възли.
Има две категории методи за дистанциране, които ще назова директен и непряк, но те еднакво могат да бъдат наречени активен и пасивен. Директните методи включват действия от оцелели партньори, като взаимодействие с IPMI (Intelligent Platform Management Interface - интерфейс за дистанционно наблюдение и управление на физическото състояние на сървър) или iLO (механизъм за управление на сървъри при липса на физически достъп до тях ), докато индиректните методи разчитат на неуспешния възел, за да разпознаят по някакъв начин, че е в нездравословно състояние (или поне да попречат на останалите членове да се възстановят) и да сигнализират относно необходимостта от изключване на неуспешния възел.
Кворумът помага в случай на използване на директни и косвени методи.
Директно дистанциране
В случай на директно ограждане, можем да използваме кворум, за да предотвратим състезания по ограждане в случай на повреда в мрежата.
С концепцията за кворум на място има достатъчно информация в системата (дори и без да са свързани с партньорите си), за да могат възлите автоматично да знаят дали трябва да инициират прекъсване на връзката и/или възстановяване.
Без кворум и двете страни на мрежовото разделение правилно приемат, че другата страна е мъртва и ще се опитат да разединят другата. В най-лошия случай и двете страни успяват да изключат целия клъстер. Алтернативен сценарий е Deathmatch, безкраен цикъл от възли, които се появяват, не виждат своите партньори, рестартират ги и започват възстановяване само за да се рестартират, когато техният партньор премине през същата логика.
Проблемът с фехтовката е, че най-често използваните устройства стават недостъпни поради същите събития на повреда, които искаме да насочим за възстановяване. Повечето IPMI и iLO карти са инсталирани на хостовете, които контролират, и по подразбиране използват същата мрежа, което кара целевите хостове да приемат, че останалите хостове са офлайн.
За съжаление характеристиките на устройствата IPMI и iLo рядко се вземат предвид при закупуване на оборудване.
Индиректно дистанциране
Кворумът също е важен за управлението на индиректното ограждане, ако се направи правилно, кворумът може да позволи на оцелелите да приемат, че изгубените възли ще преминат в безопасно състояние след определен период от време.
С тази настройка хардуерният таймер за наблюдение се нулира на всеки N секунди, освен ако не се загуби кворум. Ако таймерът (обикновено няколко кратни на N) изтече, тогава устройството извършва неудобно изключване (не изключване).
Този подход е много ефективен, но без кворум няма достатъчно информация в рамките на клъстера, за да го управлява. Не е лесно да се направи разлика между прекъсване на мрежата и повреда на възел. Причината това да има значение е, че без способността да правите разлика между двата случая, вие сте принудени да изберете едно и също поведение и в двата случая.
Проблемът с избора на един режим е, че няма курс на действие, който да увеличи максимално достъпността и да предотврати загубата на данни.
- Ако решите да приемете, че партньорски възел работи, но всъщност се е провалил, клъстерът ненужно ще спре услугите, които трябва да работят, за да компенсира загубата на услуги от повредения партньорски възел.
- Ако решите да приемете, че възелът не работи, но това е просто прекъсване на мрежата и всъщност отдалеченият възел работи, тогава в най-добрия случай се абонирате за някакво бъдещо ръчно съгласуване на наборите от резултати.
Без значение каква евристика използвате, тривиално е да създадете грешка, която или ще накара и двете страни да работят, или ще принуди клъстера да изключи оцелелите възли. Неизползването на кворум наистина лишава клъстера от един от най-мощните инструменти в неговия арсенал.
Ако няма друга алтернатива, най-добрият подход е да се жертва достъпността (тук авторът се позовава на теоремата за CAP). Високата наличност на повредени данни не помага на никого, а ръчното съгласуване на различни набори от данни също не е забавно.
Кворум
Кворумът звучи страхотно, нали?
Единственият недостатък е, че за да го имате в клъстер с N членове, трябва да имате връзка между N / 2 + 1 от вашите възли. Което не е възможно в клъстер с два възела, след като един възел се повреди.
Което в крайна сметка ни води до основния проблем с два възела:
Кворумът е безсмислен в два клъстера на възли и без него не е възможно надеждно да се определи курс на действие, който увеличава наличността и предотвратява загубата на данни
Дори в система от два възела, свързани с кръстосан кабел, не е възможно окончателно да се направи разлика между прекъсване на мрежата и повреда на друг възел. Изключването на единия край (чиято вероятност със сигурност е пропорционална на разстоянието между възлите) ще бъде достатъчно, за да опровергае всяко предположение, че здравето на връзката е равно на здравето на партньорския възел.
Правим работа на клъстер от два възела
Понякога клиентът не може или не иска да закупи трети възел и ние сме принудени да търсим алтернатива.
Вариант 1 - Дублиран метод за разграничаване
Устройството iLO или IPMI на възела представлява точка на повреда, тъй като, ако се повреди, оцелелите не могат да го използват, за да приведат възела в безопасно състояние. В клъстер от 3 или повече възли можем да смекчим това чрез изчисляване на кворума и използване на хардуерен пазач (индиректен механизъм за ограждане, както беше обсъдено по-рано). В случай на два възела, вместо това трябва да използваме мрежови превключватели за захранване (разпределителни блокове за захранване или PDU).
След неуспех, оцелелият първо се опитва да комуникира с основното защитно устройство (вграден iLO или IPMI). Ако е успешно, възстановяването продължава както обикновено. Само ако устройството iLO / IPMI се повреди, се осъществява достъп до PDU, ако достъпът е успешен, възстановяването може да продължи.
Уверете се, че сте поставили PDU в мрежа, която е отделна от трафика на клъстера, в противен случай единична повреда в мрежата ще блокира достъпа както до защитните устройства, така и ще блокира възстановяването на услугата.
В този момент може би се питате - PDU не е ли единствена точка на повреда? На което отговорът е, разбира се.
Ако този риск е значителен за вас, не сте сами: свържете двата възела към два PDU и кажете на софтуера на клъстера да използва и двата, когато включва и изключва захранването на възлите. Сега клъстерът остава активен, ако един PDU умре и ще е необходима втора повреда на другия PDU или на IPMI устройството, за да блокира възстановяването.
Вариант 2 - Добавяне на арбитър
В някои сценарии, докато техниката на излишно дистанциране е технически възможна, тя е политически трудна. Много компании обичат да имат известно разделение между администраторите и собствениците на приложения, а мрежовите администратори, загрижени за сигурността, не винаги са ентусиазирани да предават PDU параметри за достъп на никого.
В този случай препоръчителната алтернатива е да се създаде неутрална трета страна, която може да допълни изчисляването на кворума.
В случай на повреда, възелът трябва да може да вижда ефира на своя партньор или арбитър, за да възстанови услугите. Арбитърът също включва функция за прекъсване на връзката, ако и двата възела могат да видят арбитъра, но не могат да се виждат един друг.
Тази опция трябва да се използва заедно с метод за непряко ограждане, като например хардуерен таймер за наблюдение, който е конфигуриран да изключва машина, ако тя загуби връзка със своя равнопоставен възел и арбитър. По този начин оцелелият може да приеме с разумна сигурност, че неговият равнопоставен възел ще бъде в защитено състояние след изтичане на таймера за хардуерен пазач.
Практическата разлика между арбитър и трети възел е, че арбитърът изисква много по-малко ресурси за работа и потенциално може да обслужва повече от един клъстер.
Вариант 3 - Човешки фактор
Последният подход е оцелелите да продължат да изпълняват всички услуги, които вече са изпълнявали, но да не стартират нови, докато или проблемът не се реши сам (възстановяване на мрежата, рестартиране на възел), или човек поеме отговорност за ръчно потвърждаване, че другата страна е мъртъв.
Бонус опция
Споменах ли, че можете да добавите трети възел?
две стелажи
В името на спора, нека се преструваме, че съм ви убедил в предимствата на третия възел, сега трябва да разгледаме физическото разположение на възлите. Ако са поставени (и захранвани) в една и съща стойка, това също е SPoF и не може да бъде решен чрез добавяне на втора стойка.
Ако това е изненадващо, помислете какво би се случило, ако стелаж с два възела се повреди и как оцелелият възел ще направи разлика между този случай и повредата на мрежата.
Краткият отговор е, че това не е възможно и отново имаме работа с всички проблеми в случай на два възела. Или оцелял:
- игнорира кворума и неправилно се опитва да инициира възстановяване по време на прекъсване на мрежата (възможността за завършване на ограждането е различна история и зависи от това дали PDU е включен и дали те споделят захранване с някоя от стелажите), или
- зачита кворума и се самоизключва преждевременно, когато неговият равнопоставен възел се повреди
Във всеки случай два стелажа не са по-добри от един и възлите трябва или да получат независими захранвания, или да бъдат разпределени в три (или повече, в зависимост от това колко възли имате) стелажи.
Два центъра за данни
До този момент читателите, които вече не са склонни към риск, могат да обмислят възстановяване след бедствие. Какво се случва, когато астероид удари същия център за данни с нашите три възела, разпределени в три различни шкафа? Очевидно лоши неща, но в зависимост от вашите нужди добавянето на втори център за данни може да не е достатъчно.
Ако е направено правилно, вторият център за данни ви предоставя (и това е разумно) актуално и последователно копие на вашите услуги и техните данни. Въпреки това, както в сценариите с XNUMX възела и XNUMX стелажа, няма достатъчно информация в системата, за да се осигури максимална наличност и да се предотврати повреда (или разминаване в набора от данни). Дори и с три възела (или стелажи), разпределянето им между само два центъра за данни оставя системата неспособна да вземе надеждно правилното решение в случай на (сега много по-вероятно) събитие, което и двете страни не могат да комуникират.
Това не означава, че решение с два центъра за данни никога не е добра идея. Компаниите често искат човек да е наясно, преди да предприеме изключителната стъпка да се премести в резервен център за данни. Само имайте предвид, че ако искате да автоматизирате повредата, ще ви трябва или трети център за данни, за да има смисъл кворумът (директно или чрез арбитър), или ще намерите начин надеждно да изключите целия център за данни.
Източник: www.habr.com