Тъй като високата наличност е от първостепенно значение в днешната бизнес реалност, един от най-често срещаните сценарии, с които потребителите трябва да се справят, е как да се гарантира, че базата данни винаги ще бъде достъпна за приложението.
Всеки доставчик на услуги има наследствен риск от прекъсване на услугата, поради което една от стъпките, които могат да бъдат предприети, е да се разчита на множество доставчици за облекчаване на риска и допълнително съкращаване.
Доставчиците на облачни услуги не се различават – те могат да се провалят и трябва да планирате това предварително. Какви опции са налични за MariaDB Cluster? Нека да го разгледаме в тази публикация в блога.
Клъстериране на бази данни MariaDB в многооблачни среди
Ако SLA, предложен от един доставчик на облачни услуги, не е достатъчен, винаги има опция за създаване на сайт за аварийно възстановяване извън този доставчик. Благодарение на това, когато някой от доставчиците на облачни услуги изпита известно влошаване на услугата, винаги можете да преминете към друг доставчик и да поддържате базата си данни актуална и достъпна.
Един от проблемите, които са типични за многооблачни настройки, е латентността на мрежата, която е неизбежна, ако говорим за по-големи разстояния или като цяло за множество географски разделени местоположения. Скоростта на светлината е доста висока, но е ограничена, всеки скок, всеки рутер също добавя известно забавяне в мрежовата инфраструктура.
MariaDB Cluster работи чудесно в мрежи с ниска латентност. Това е клъстер, базиран на кворум, където е необходима бърза комуникация между всички възли, за да се поддържат гладките операции. Увеличаването на латентността на мрежата ще повлияе на клъстерните операции, особено на производителността на записите. Има няколко начина за справяне с този проблем.
Първо имаме опция да използваме отделни клъстери, свързани с помощта на асинхронни връзки за репликация. Това ни позволява почти да забравим за латентността, тъй като асинхронната репликация е значително по-подходяща за работа в среди с висока латентност.
Друга опция е, че като се имат предвид мрежите с ниска латентност между центровете за данни, все пак може да е напълно добре да стартирате MariaDB Cluster, обхващащ няколко центъра за данни. В крайна сметка множество центрове за данни не винаги означават огромни разстояния в географски план – можете също да използвате множество доставчици, разположени в рамките на един и същи градски район, свързани с бързи мрежи с ниска латентност. Тогава ще говорим за увеличаване на латентността до най-много десетки милисекунди, определено не стотици. Всичко зависи от приложението, но такова увеличение може да е приемливо.
Асинхронна репликация между MariaDB клъстери
Нека да разгледаме набързо асинхронния подход. Идеята е проста - два клъстера, свързани помежду си с помощта на асинхронна репликация.
Това идва с няколко ограничения. Като за начало трябва да решите дали искате да използвате мулти-мастер или бихте изпратили целия трафик само към един център за данни. Бихме препоръчали да стоите далеч от писане и в двата центъра за данни и от използването на главен - главен репликация. Това може да доведе до сериозни проблеми, ако не внимавате.
Ако решите да използвате активно - пасивна настройка, вероятно бихте искали да внедрите някакъв вид базирано на DNS маршрутизиране за запис, за да сте сигурни, че вашите сървъри на приложения винаги ще се свързват към набор от прокси сървъри, разположени в активния център за данни. Това може да бъде постигнато или чрез буквално въвеждане в DNS, което ще бъде променено, когато се изисква преминаване при отказ, или може да се направи чрез някакво решение за откриване на услуга като Consul или etcd.
Основният недостатък на средата, изградена с помощта на асинхронна репликация, е липсата на способност за справяне с разделянето на мрежата между центровете за данни. Това е наследено от репликацията - без значение какво искате да свържете с репликацията (единични възли, MariaDB клъстери), няма начин да заобиколите факта, че репликацията не е наясно с кворума. Няма механизъм за проследяване на състоянието на възлите и разбиране на картината на високо ниво на цялата топология. В резултат на това, когато връзката между два центъра за данни изпадне, вие се оказвате с два отделни MariaDB клъстера, които не са свързани и които са готови да приемат трафик. Потребителят трябва да определи какво да прави в такъв случай. Възможно е да се внедрят допълнителни инструменти, които да наблюдават състоянието на базите данни отвън (т.е. от третия център за данни) и след това да предприемат действия (или да не предприемат действия) въз основа на тази информация. Възможно е също така да се разпределят инструменти, които биха споделяли инфраструктурата с бази данни, но биха били наясно с клъстерите и биха могли да проследяват състоянието на свързаността на центъра за данни и да се използват като източник на истина за скриптовете, които ще управляват средата. Например, ClusterControl може да бъде разгърнат в клъстер с три възела, възел на център за данни, който използва RAFT протокол, за да осигури кворума. Ако възел загуби връзката с останалата част от клъстера, може да се предположи, че центърът за данни е претърпял мрежово разделяне.
Multi-DC MariaDB клъстери
Алтернатива на асинхронната репликация може да бъде изцяло решение за MariaDB Cluster, което обхваща множество центрове за данни.
Както е посочено в началото на този блог, MariaDB Cluster, точно като всеки Базираният на Galera клъстер ще бъде засегнат от високата латентност. Като се има предвид това, напълно приемливо е да го стартирате в среди с „не толкова висока“ латентност и да очаквате да се държи правилно, осигурявайки приемлива производителност. Всичко зависи от пропускателната способност и дизайна на мрежата, разстоянието между центровете за данни и изискванията на приложението. Такъв подход ще работи чудесно, особено ако използваме сегменти за разграничаване на отделни центрове за данни. Той позволява на MariaDB Cluster да оптимизира своята вътрешноклъстерна свързаност и да намали до минимум трафика между DC.
Основното предимство на тази настройка е, че тя разчита на MariaDB Cluster за справяне с неуспехите. Ако използвате три центъра за данни, вие сте доста защитени от ситуацията с разделен мозък - докато има мнозинство, то ще продължи да работи. Не се изисква да имате пълноценен възел в третия център за данни - можете да използвате и Galera Arbitrator, демон, който действа като част от клъстера, но не е необходимо да обработва никакви операции с база данни. Той се свързва с възлите, участва в изчисляването на кворума и може да се използва за препредаване на трафика, ако директната връзка между двата центъра за данни не работи.
В този случай целият процес на отказ може да бъде описан като:дефинирайте всички възли в балансиращите устройства (всички, ако центровете за данни са близо един до друг, в друг случай може да искате да добавите някакъв приоритет за възли, разположени по-близо до балансира на натоварването) и това е почти всичко. MariaDB Cluster възлите, които формират мнозинството, ще бъдат достъпни чрез всеки прокси сървър.
Разгръщане на мулти-облачен MariaDB клъстер с помощта на ClusterControl
Нека да разгледаме две опции, които можете да използвате за разгръщане на клъстери MariaDB с няколко облака с помощта на ClusterControl. Моля, имайте предвид, че ClusterControl изисква SSH свързаност към всички възли, които ще управлява, така че от вас зависи да осигурите мрежова свързаност в множество центрове за данни или облачни доставчици. Докато връзката е налице, можем да продължим с два метода.
Разгръщане на MariaDB клъстери с помощта на асинхронна репликация
ClusterControl може да ви помогне да разположите два клъстера, свързани с помощта на асинхронна репликация. Когато разполагате с единичен MariaDB Cluster, искате да сте сигурни, че един от възлите има активирани двоични регистрационни файлове. Това ще ви позволи да използвате този възел като главен за втория клъстер, който ще създадем скоро.
След като двоичният дневник е активиран, можем да използваме задание Създаване на подчинен клъстер за да стартирате съветника за внедряване.
Можем или да предаваме данните директно от главния или можете да използвате такъв на резервните копия за предоставяне на данните.
След това ще ви бъде представен стандартен съветник за внедряване на клъстер, където трябва да преминете Подробности за SSH свързване.
Ще бъдете помолени да изберете и доставчика и версията на базите данни като поиска паролата за root потребителя.
Накрая ще бъдете помолени да дефинирате възли, които искате да добавите към клъстер и сте готови.
Когато бъде внедрен, ще го видите в списъка на клъстерите в Потребителски интерфейс на ClusterControl.
Разгръщане на мулти-облачен MariaDB клъстер
Както споменахме по-рано, друга опция за разгръщане на MariaDB Cluster би била използването на отделни сегменти при добавяне на възли към клъстера. В потребителския интерфейс на ClusterControl ще намерите опция за „Добавяне на възел“:
Когато го използвате, ще ви бъде представен следния екран:
Сегментът по подразбиране е 0, така че искате да го промените на различна стойност .
След като възлите са добавени, можете да проверите в кой сегмент се намират, като погледнете раздела Общ преглед:
Заключение
Надяваме се, че този кратък блог ви даде по-добро разбиране на опциите, които имате за внедряване на клъстер в няколко облака на MariaDB и как те могат да бъдат използвани, за да се гарантира висока наличност на вашата инфраструктура на базата данни.
