Vzhledem k tomu, že vysoká dostupnost je v dnešní obchodní realitě prvořadá, je jedním z nejčastějších scénářů, se kterými se uživatelé musí vypořádat, jak zajistit, aby databáze byla pro aplikaci vždy dostupná.
Každý poskytovatel služeb přichází s zděděným rizikem narušení služby, a proto je jedním z kroků, které lze podniknout, spolehnout se na více poskytovatelů, kteří zmírní riziko a další nadbytečnost.
Poskytovatelé cloudových služeb se neliší – mohou selhat a měli byste to naplánovat předem. Jaké možnosti jsou pro MariaDB Cluster k dispozici? Pojďme se na to podívat v tomto příspěvku na blogu.
Shlukování databáze MariaDB v prostředí s více cloudy
Pokud SLA navržená jedním poskytovatelem cloudových služeb nestačí, vždy existuje možnost vytvořit web pro obnovu po havárii mimo tohoto poskytovatele. Díky tomu, kdykoli dojde u některého z cloudových poskytovatelů k nějakému zhoršení služeb, můžete vždy přejít k jinému poskytovateli a udržovat svou databázi v provozu a dostupnou.
Jedním z problémů, které jsou typické pro nastavení s více cloudy, je latence sítě, které se nelze vyhnout, pokud mluvíme o větších vzdálenostech nebo obecně o více geograficky oddělených místech. Rychlost světla je poměrně vysoká, ale je konečná, každý skok, každý router také přidává určitou latenci do síťové infrastruktury.
MariaDB Cluster funguje skvěle v sítích s nízkou latencí. Jde o klastr založený na kvoru, kde je pro udržení plynulosti operací vyžadována rychlá komunikace mezi všemi uzly. Zvýšení latence sítě ovlivní operace clusteru, zejména výkon zápisu. Tento problém lze řešit několika způsoby.
Nejprve máme možnost použít samostatné clustery propojené pomocí asynchronních replikačních odkazů. To nám umožňuje téměř zapomenout na latenci, protože asynchronní replikace je výrazně vhodnější pro práci v prostředích s vysokou latencí.
Další možností je, že vzhledem k sítím s nízkou latencí mezi datovými centry může být stále úplně v pořádku provozovat klastr MariaDB zahrnující několik datových center. Koneckonců, více datových center nemusí vždy znamenat velké vzdálenosti z geografického hlediska – můžete také využít více poskytovatelů umístěných ve stejné metropolitní oblasti, propojených rychlými sítěmi s nízkou latencí. Pak budeme mluvit o zvýšení latence maximálně na desítky milisekund, rozhodně ne stovky. Vše závisí na aplikaci, ale takové zvýšení může být přijatelné.
Asynchronní replikace mezi clustery MariaDB
Pojďme se rychle podívat na asynchronní přístup. Myšlenka je jednoduchá – dva clustery vzájemně propojené pomocí asynchronní replikace.
To má několik omezení. Pro začátek se musíte rozhodnout, zda chcete používat multi-master nebo byste veškerý provoz posílali pouze do jednoho datového centra. Doporučujeme vyhnout se zápisu do obou datových center a používání replikace master - master. Pokud nebudete opatrní, může to vést k vážným problémům.
Pokud se rozhodnete použít aktivní - pasivní nastavení, pravděpodobně budete chtít implementovat nějaký druh směrování založeného na DNS pro zápisy, abyste zajistili, že se vaše aplikační servery budou vždy připojovat k sadě proxy umístěné v aktivním datovém centru. Toho lze dosáhnout buď doslova záznamem DNS, který by se změnil, když je vyžadováno převzetí služeb při selhání, nebo to lze provést pomocí nějakého druhu řešení pro zjišťování služeb, jako je Consul nebo etcd.
Hlavní nevýhodou prostředí vytvořeného pomocí asynchronní replikace je nedostatečná schopnost vypořádat se s rozdělením sítě mezi datovými centry. To je zděděno z replikace – bez ohledu na to, co chcete propojit s replikací (jednotlivé uzly, MariaDB Clusters), neexistuje způsob, jak obejít skutečnost, že replikace nezná kvorum. Neexistuje žádný mechanismus pro sledování stavu uzlů a pochopení obrazu celé topologie na vysoké úrovni. Výsledkem je, že kdykoli dojde k výpadku spojení mezi dvěma datovými centry, skončíte se dvěma samostatnými clustery MariaDB, které nejsou propojeny a které jsou oba připraveny přijímat provoz. Bude na uživateli, aby určil, co má v takovém případě dělat. Je možné implementovat další nástroje, které by monitorovaly stav databází zvenčí (tj. ze třetího datacentra) a na základě těchto informací pak prováděly akce (nebo neprováděly akce). Je také možné uspořádat nástroje, které by sdílely infrastrukturu s databázemi, ale byly by klastrové a mohly by sledovat stav připojení datového centra a mohly by být použity jako zdroj pravdy pro skripty, které by spravovaly prostředí. ClusterControl lze například nasadit v clusteru se třemi uzly, uzel na datové centrum, který k zajištění kvora používá protokol RAFT. Pokud uzel ztratí konektivitu se zbytkem clusteru, lze předpokládat, že v datovém centru došlo k rozdělení sítě.
Multi-DC MariaDB clustery
Alternativou k asynchronní replikaci by mohlo být řešení all-MariaDB Cluster, které pokrývá více datových center.
Jak bylo uvedeno na začátku tohoto blogu, MariaDB Cluster, stejně jako každý Klastr založený na Galeře bude ovlivněn vysokou latencí. Přesto je naprosto přijatelné jej spouštět v prostředí „ne tak vysoké“ latence a očekávat, že se bude chovat správně a bude poskytovat přijatelný výkon. Vše závisí na propustnosti a designu sítě, vzdálenosti mezi datovými centry a požadavcích aplikace. Takový přístup bude fungovat skvěle, zejména pokud použijeme segmenty k odlišení samostatných datových center. Umožňuje MariaDB Cluster optimalizovat své intraklastrové připojení a snížit provoz mezi DC na minimum.
Hlavní výhodou tohoto nastavení je, že při řešení selhání spoléhá na cluster MariaDB. Pokud používáte tři datová centra, jste do značné míry chráněni proti situaci rozděleného mozku – dokud bude většina, bude fungovat i nadále. Není nutné mít plnohodnotný uzel ve třetím datacentru - můžete také použít Galera Arbitrator, démona, který funguje jako součást clusteru, ale nemusí obsluhovat žádné databázové operace. Připojuje se k uzlům, podílí se na výpočtu kvora a může být použit k přenosu provozu, pokud přímé spojení mezi dvěma datovými centry nefunguje.
V takovém případě lze celý proces převzetí služeb při selhání popsat takto:definujte všechny uzly v nástrojích pro vyrovnávání zatížení (všechny, pokud jsou datová centra blízko sebe, v jiném případě můžete chtít přidat určitou prioritu pro uzly umístěné blíže k load balanceru) a to je skoro vše. Uzly klastru MariaDB, které tvoří většinu, budou dosažitelné prostřednictvím jakéhokoli proxy.
Nasazení multicloudového klastru MariaDB pomocí ClusterControl
Pojďme se podívat na dvě možnosti, které můžete použít k nasazení multicloudových clusterů MariaDB pomocí ClusterControl. Mějte prosím na paměti, že ClusterControl vyžaduje připojení SSH ke všem uzlům, které bude spravovat, takže bude na vás, abyste zajistili síťové připojení napříč více datovými centry nebo cloudovými poskytovateli. Dokud existuje konektivita, můžeme postupovat dvěma způsoby.
Nasazení klastrů MariaDB pomocí asynchronní replikace
ClusterControl vám může pomoci nasadit dva clustery propojené pomocí asynchronní replikace. Když máte nasazený jeden klastr MariaDB, chcete se ujistit, že jeden z uzlů má povolené binární protokoly. To vám umožní použít tento uzel jako hlavní pro druhý cluster, který brzy vytvoříme.
Jakmile bude binární protokol povolen, můžeme použít úlohu Create Slave Cluster spustíte průvodce nasazením.
Data můžeme streamovat přímo z hlavního serveru nebo můžete použít jeden záloh pro poskytování dat.
Poté se vám zobrazí standardní průvodce nasazením clusteru, kterým musíte projít Podrobnosti o připojení SSH.
Budete také požádáni, abyste vybrali dodavatele a verzi databází s dotazem na heslo pro uživatele root.
Nakonec budete požádáni o definování uzlů, které chcete přidat do cluster a vše je připraveno.
Po nasazení se zobrazí na seznamu clusterů v Uživatelské rozhraní ClusterControl.
Nasazení Multi-Cloud MariaDB Cluster
Jak jsme již zmínili, další možností nasazení clusteru MariaDB by bylo použití samostatných segmentů při přidávání uzlů do clusteru. V uživatelském rozhraní ClusterControl najdete možnost „Add Node“:
Když jej použijete, zobrazí se vám následující obrazovka:
Výchozí segment je 0, takže jej chcete změnit na jinou hodnotu .
Po přidání uzlů můžete zkontrolovat, ve kterém segmentu se nacházejí, na kartě Přehled:
Závěr
Doufáme, že vám tento krátký blog pomohl lépe porozumět možnostem, které máte pro nasazení clusteru MariaDB s více cloudy, a jak je lze využít k zajištění vysoké dostupnosti vaší databázové infrastruktury.