Много често се срещат бази данни, разпределени в множество географски местоположения. Един сценарий за извършване на този тип настройка е за възстановяване след бедствие, където вашият център за данни в готовност се намира на място, различно от основния ви център за данни. Може също така да се изисква базите данни да са разположени по-близо до потребителите.
Основното предизвикателство за постигане на тази настройка е чрез проектиране на базата данни по начин, който намалява вероятността от проблеми, свързани с разделянето на мрежата.
MariaDB Cluster може да бъде добър избор за изграждане на такава среда по няколко причини. Бихме искали да ги обсъдим тук и също така да поговорим малко за това как може да изглежда една такава среда.
Защо да използвате MariaDB Cluster за гео-разпределени среди?
Първата причина е, че MariaDB Cluster може да поддържа множество писатели. Това прави маршрутизирането на запис по-лесно за проектиране - просто пишете до локалните възли на MariaDB. Разбира се, като се има предвид синхронна репликация, забавянето влияе върху производителността на запис и може да видите, че записите ви стават по-бавни, ако разпространите своя клъстер твърде далеч географски. В крайна сметка не можете да пренебрегнете законите на физиката и те казват, поне засега, че дори скоростта на светлината във връзките с влакна е ограничена. Всички рутери, добавени отгоре, също ще увеличат латентността, дори само с няколко милисекунди.
Второ, обработка на забавяне в MariaDB Cluster. Асинхронната репликация е обект на забавяне на репликацията - подчинените може да не са актуални с данните, ако се мъчат да приложат всички промени навреме. В MariaDB Cluster това е различно - контролът на потока е механизъм, който има за цел да поддържа клъстера в синхрон. Е, почти - в някои крайни случаи все още можете да наблюдавате изоставане. Тук говорим обикновено за милисекунди, най-много няколко секунди, докато в небето за асинхронна репликация е ограничението.
Трето, сегменти. По подразбиране MariaDB CLuster използва всички за цялата комуникация и всеки набор за запис се изпраща от възела до всички други възли в клъстера. Това поведение може да се промени с помощта на сегменти. Сегментите позволяват на потребителите да разделят MariaDB клъстери на няколко части. Всеки сегмент може да съдържа множество възли и избира един от тях като релеен възел. Такива възли получават набори за запис от други сегменти и ги преразпределят между възлите на MariaDB, локални за сегмента. В резултат на това, както можете да видите на диаграмата по-горе, е възможно да се намали трафикът за репликация, преминаващ през WAN три пъти - само две „реплика“ на потока за репликация се изпращат през WAN:едно на център за данни в сравнение с едно на подчинен в асинхронна репликация.
И накрая, където MariaDB Cluster наистина блести, е обработката на мрежовото разделяне. MariaDB Cluster постоянно следи състоянието на възлите в клъстера. Всеки възел се опитва да се свърже със своите партньори и да обменя състоянието на клъстера. Ако подмножество от възли не е достъпно, MariaDB се опитва да препрати комуникацията, така че ако има начин да се достигне до тези възли, те ще бъдат достигнати.
Пример може да се види на диаграмата по-горе:DC 1 загуби връзката с DC2, но DC2 и DC3 могат да се свържат. В този случай един от възлите в DC3 ще се използва за предаване на данни от DC1 към DC2, като се гарантира, че комуникацията в клъстера може да се поддържа.
MariaDB е в състояние да предприема действия въз основа на състоянието на клъстера. Той реализира кворум - повечето от възлите трябва да са налични, за да може клъстерът да работи. Ако възелът се изключи от клъстера и не може да достигне до друг възел, той ще престане да работи.
Както може да се види на диаграмата по-горе, има частична загуба на мрежовата комуникация в DC1 и засегнатият възел се премахва от клъстера, като се гарантира, че приложението няма да има достъп до остарели данни.
Това е вярно и в по-голям мащаб. DC1 прекъсна цялата си комуникация. В резултат на това целият център за данни е премахнат от клъстера и нито един от неговите възли няма да обслужва трафика. Останалата част от клъстера поддържа мнозинство (6 от 9 възли са налични) и се преконфигурира, за да запази връзката между DC 2 и DC3. В диаграмата по-горе предположихме, че записващият удря възела в DC2, но моля, имайте предвид, че MariaDB може да работи с множество записващи.
Проектиране на географски разпределен MariaDB клъстер
Прегледахме някои от функциите, които правят MariaDB Cluster подходящ за гео-разпределени среди, нека сега да се съсредоточим малко върху дизайна. В началото нека обясним с каква среда работим. Ще използваме три отдалечени центъра за данни, свързани чрез Wide Area Network (WAN). Всеки център за данни ще получава записи от локални сървъри на приложения. Четенията също ще бъдат само локални. Това има за цел да избегне ненужния трафик, пресичащ WAN.
За да направим този блог по-малко сложен, няма да навлизаме в подробности как трябва да изглежда връзката. Предполагаме някаква правилно конфигурирана, сигурна връзка във всички центрове за данни. VPN или други инструменти могат да се използват за прилагане на това.
Ще използваме MaxScale като балансиращо натоварване. MaxScale ще бъде разгърнат локално във всеки център за данни. Той също така ще насочва трафика само към локалните възли. Отдалечените възли винаги могат да се добавят ръчно и ние ще обясним случаите, в които това може да е добро решение. Приложенията могат да бъдат конфигурирани да се свързват към един от локалните възли на MaxScale, като се използва алгоритъм за кръгова система. Можем също да използваме Keepalived и Virtual IP, за да насочим трафика към единичния възел MaxScale, стига един възел на MaxScale да може да обработва целия трафик.
Друго възможно решение е да разпределите MaxScale с възли на приложението и да конфигурирате приложението да се свързва с прокси сървъра на локалния хост. Този подход работи доста добре при допускането, че е малко вероятно MaxScale да не е наличен, но приложението ще работи добре на същия възел. Обикновено това, което виждаме, е или повреда на възел, или повреда на мрежата, което би засегнало както MaxScale, така и приложението едновременно.
Диаграмата по-горе показва версията на средата, където MaxScale формира прокси ферми - всички прокси възли с една и съща конфигурация, балансирани на натоварването с помощта на Keepalived или просто кръгово обединяване от приложението във всички възли на MaxScale. MaxScale е конфигуриран да разпределя натоварването между всички възли на MariaDB в локалния център за данни. Един от тези възли ще бъде избран като възел за изпращане на записите, докато SELECT ще бъдат разпределени между всички възли. Наличието на един специален възел за записване в център за данни помага за намаляване на броя на възможните конфликти при сертифициране, което обикновено води до по-добра производителност. За да намалим това още повече, ще трябва да започнем да изпращаме трафика през WAN връзката, което не е идеално, тъй като използването на честотната лента значително ще се увеличи. В момента, с наличните сегменти, само две копия от набора за запис се изпращат през центровете за данни – по едно на DC.
Заключение
Както можете да видите, MariaDB Cluster може лесно да се използва за създаване на гео-разпределени клъстери, които могат да работят дори по целия свят. Ограничаващият фактор ще бъде латентността на мрежата. Ако е твърде високо, може да се наложи да обмислите използването на отделни MariaDB клъстери, свързани с помощта на асинхронна репликация.
