Изпълнението на клъстер Galera в хибриден облак трябва да се състои от поне два различни географски сайта, свързващи хостове в локалния или частния облак с тези в публичния облак. Независимо дали използвате нечуплив частен облак или публични облачни платформи, възстановяването при бедствия (DR) наистина е ключов проблем. Тук не става въпрос за копиране на вашите данни в сайт за архивиране и възможността да ги възстановите, а за непрекъснатост на бизнеса и колко бързо можете да възстановите услугите, когато настъпи бедствие.
В тази публикация в блога ще разгледаме различни начини за проектиране на вашите клъстери Galera за устойчивост на грешки в хибридна облачна среда.
Активна-Активна настройка
Galera Cluster трябва да работи с общо нечетен брой възли в клъстер и обикновено започва с 3 възела. Това е така, защото Galera Cluster използва кворум за автоматично определяне на основния компонент, където повечето свързани възли трябва да могат да обслужват клъстера наведнъж, в случай на разделяне на клъстер.
За настройка на хибриден облак с активна и активна настройка, Galera изисква поне 3 различни сайта, образуващи клъстер Galera в WAN. Като цяло ще ви е необходим трети сайт, който да действа като арбитър, да гласува за кворум и да запази „основния компонент“, ако някой от сайтовете е недостъпен. Това може да бъде настроено като минимум клъстер с 3 възела на 3 различни сайта (1 възел на сайт), подобно на следната диаграма:
Въпреки това, за целите на производителността и надеждността, се препоръчва да имате 7 -клъстер на възли, както е показано на следната диаграма:
Това се счита за най-добрата топология за поддръжка на активна-активна настройка, при която DR сайтът трябва да бъде достъпен почти веднага, без никаква намеса. И двата сайта могат да получават четения/записвания по всяко време, при условие че клъстерът е в кворума.
Въпреки това е много скъпо да имате 3 сайта и 7 възела на базата данни (седмият възел може да бъде заменен с garbd, тъй като е много малко вероятно да се използва за обслужване на данни на клиентите/приложенията). Това обикновено не е популярно внедряване в началото на проекта поради огромните първоначални разходи и колко чувствителна комуникацията и репликацията на групата Galera към латентността на мрежата.
Активно-пасивна настройка
При активна-пасивна конфигурация са необходими поне 2 сайта и само един сайт е активен в даден момент, известен като основен сайт и възлите на вторичния сайт само копират данни, идващи от основния сървър/клъстер. За Galera Cluster можем да използваме или MySQL асинхронна репликация (главен-подчинен репликация), или можем също да използваме виртуално синхронната репликация на Galera с известна настройка, за да намалим нейната репликация на набор за запис, за да действа като асинхронна репликация.
Вторичният сайт трябва да бъде защитен срещу случайни записвания, като се използва флагът само за четене, защитна стена на приложението, обратен прокси или каквито и да било други средства, тъй като потокът от данни винаги идва от основния към вторичния сайт, освен ако при отказ е инициирало и популяризирало вторичния сайт като основен.
Използване на асинхронна репликация
Доброто нещо за асинхронната репликация е, че репликацията не оказва влияние върху изходния сървър/клъстер, но е позволено да изостава от главния. Тази настройка ще направи основния и DR сайт независими един от друг, слабо свързани с асинхронна репликация. Това може да бъде настроено като минимум клъстер с 4 възела на 2 различни сайта, подобно на следната диаграма:
Един от възлите на Galera в сайта на DR ще бъде подчинен, който се репликира от един от възлите на Galera (главен) в основния сайт. И двата сайта трябва да произвеждат двоични регистрационни файлове с GTID и log_slave_updates са активирани - актуализациите, които идват от потока за асинхронна репликация, ще бъдат приложени към другите възли в клъстера. Въпреки това, за производствена употреба, препоръчваме да имате два комплекта клъстери на двата сайта, както е показано на следната диаграма:
Като има два отделни клъстера, те ще бъдат слабо свързани и няма да се влияят един на друг, напр. повреда на клъстера на основния сайт няма да засегне сайта на DR. По отношение на производителността забавянето на WAN няма да повлияе на актуализациите на активния клъстер. Те се изпращат асинхронно към сайта за архивиране. Клъстерът DR може потенциално да работи на по-малки екземпляри в обществена облачна среда, стига да могат да бъдат в крак с основния клъстер. Инстанциите могат да бъдат надстроени, ако е необходимо. Приложенията трябва да изпращат записи до основния сайт, а вторичният сайт трябва да бъде настроен да работи в режим само за четене. Сайтът за аварийно възстановяване може да се използва за други цели, като архивиране на база данни, архивиране на двоични регистрационни файлове и отчитане или обработка на аналитични заявки (OLAP).
От друга страна, има вероятност от загуба на данни по време на отказ/резервиране, ако подчинението е изоставало. Ето защо се препоръчва да активирате полусинхронна репликация, за да намалите риска от загуба на данни. Имайте предвид, че използването на полусинхронна репликация все още не осигурява силни гаранции срещу загуба на данни, в сравнение с виртуално синхронната репликация на Galera. Прочетете внимателно това ръководство за MySQL, например следните изречения:
"При полусинхронна репликация, ако източникът се срине и се извърши превключване към реплика, неуспешният източник не трябва да се използва повторно като източник на репликация и трябва да бъде отхвърлен. Може да има транзакции, които са били не се потвърждава от нито една реплика, които следователно не са били записани преди отказ."
Процесът на отказ е доста лесен. За да популяризирате сайта за аварийно възстановяване, просто изключете флага само за четене и започнете да насочвате приложението към възлите на базата данни в сайта на DR. Резервната стратегия обаче е малко сложна и изисква известен опит в подреждането на данните на двата сайта, превключването на ролята главен/подчинен на клъстер и пренасочване на потока на подчинената репликация към обратния начин.
Използване на репликация на Galera
За активно-пасивна настройка можем да поставим по-голямата част от възлите, разположени в основния сайт, докато по-малката част от възлите се намират в сайта за аварийно възстановяване, както е показано на следващата екранна снимка за 3- възел Galera Cluster:
Ако основният сайт не работи, клъстерът ще се провали, тъй като е извън кворума. Възелът Galera на сайта за аварийно възстановяване (db3-dr) ще трябва да бъде стартиран ръчно като основен компонент на един възел. След като основният сайт се върне отново, и двата възела на основния сайт (db1-prod и db2-prod) трябва да се присъединят отново към galera3, за да се синхронизират. Наличието на доста голям gcache би трябвало да помогне за намаляване на риска от SST през WAN. Тази архитектура е лесна за настройка и администриране и е много рентабилна.
Преминаването при отказ е ръчно, тъй като администраторът трябва да популяризира единичния възел като основен компонент (bootstrap db3-dr или използвайте set pc.bootstrap=1 в параметъра wsrep_provider_options. Междувременно ще има престой . Производителността може да е проблем, тъй като DR сайтът ще работи с по-малък брой възли (тъй като сайтът за DR винаги е малцинство), за да изпълнява цялото натоварване. Възможно е да е възможно да се мащабира с повече възли след превключване към DR сайт, но се пазете от допълнителното натоварване.
Обърнете внимание, че Galera Cluster е чувствителен към мрежата поради практически синхронния си характер. Колкото по-далеч са възлите на Galera в даден клъстер, толкова по-висока е латентността и способността му за запис за разпространение и сертифициране на наборите за запис. Освен това, ако свързаността не е стабилна, лесно може да се случи разделяне на клъстери, което би могло да задейства синхронизиране на клъстер на възлите за свързване. В някои случаи това може да доведе до нестабилност на клъстера. Това изисква малко настройка на параметрите на Galera, както е показано в тази публикация в блога, Разгръщане на хибридна инфраструктурна среда за Percona XtraDB клъстер.
Последни мисли
Galera Cluster е страхотна технология, която може да бъде внедрена по различни начини – един клъстер, разпънат в множество сайтове, множество клъстери, поддържани в синхрон чрез асинхронна репликация, смес от синхронна и асинхронна репликация и т.н. Действителното решение ще бъде продиктувано от фактори като WAN латентност, евентуална спрямо силна последователност на данните и бюджет.
