Je velmi běžné vidět databáze distribuované na více geografických místech. Jedním ze scénářů pro provedení tohoto typu nastavení je zotavení po havárii, kdy je vaše záložní datové centrum umístěno na jiném místě než vaše hlavní datové centrum. Může být také požadováno, aby byly databáze umístěny blíže uživatelům.
Hlavním problémem k dosažení tohoto nastavení je navržení databáze způsobem, který snižuje možnost problémů souvisejících s dělením sítě.
MariaDB Cluster může být dobrou volbou pro vytvoření takového prostředí z několika důvodů. Rádi bychom je zde probrali a také něco málo o tom, jak takové prostředí může vypadat.
Proč používat MariaDB Cluster pro geograficky distribuovaná prostředí?
Prvním důvodem je, že MariaDB Cluster může podporovat více autorů. To usnadňuje navrhování způsobu směrování zápisu – stačí napsat do místních uzlů MariaDB. Vzhledem k synchronní replikaci má latence samozřejmě dopad na výkon zápisu a můžete vidět, že se vaše zápisy zpomalují, pokud svůj cluster geograficky rozložíte příliš daleko. Koneckonců nemůžete ignorovat fyzikální zákony a ty říkají, přinejmenším od nynějška, že i rychlost světla ve vláknových spojích je omezená. Jakékoli routery přidané navíc také zvýší latenci, i když jen o několik milisekund.
Za druhé, zpracování zpoždění v MariaDB Cluster. Asynchronní replikace je předmětem zpoždění replikace – podřízené jednotky nemusí mít aktuální data, pokud mají potíže s aplikací všech změn včas. V MariaDB Cluster je to jiné - řízení toku je mechanismus, který má udržovat cluster v synchronizaci. No, skoro - v některých okrajových případech můžete stále pozorovat zpoždění. Hovoříme zde obvykle o milisekundách, maximálně pár sekundách, zatímco na nebi asynchronní replikace je limit.
Za třetí, segmenty. Ve výchozím nastavení MariaDB CLuster používá vše pro veškerou komunikaci a každou sadu zápisů posílá uzel všem ostatním uzlům v clusteru. Toto chování lze změnit pomocí segmentů. Segmenty umožňují uživatelům rozdělit clustery MariaDB na několik částí. Každý segment může obsahovat více uzlů a zvolí jeden z nich jako přenosový uzel. Takové uzly přijímají sady zápisů z jiných segmentů a přerozdělují je mezi uzly MariaDB, které jsou v daném segmentu místní. V důsledku toho, jak můžete vidět na výše uvedeném diagramu, je možné snížit replikační provoz jdoucí přes WAN třikrát – přes WAN se odesílají pouze dvě „repliky“ replikačního toku:jedna na datové centrum ve srovnání s jednou na slave v asynchronní replikaci.
Konečně, kde MariaDB Cluster skutečně září, je zpracování síťového rozdělení. MariaDB Cluster neustále monitoruje stav uzlů v clusteru. Každý uzel se pokouší spojit se svými partnery a vyměnit si stav clusteru. Pokud není podmnožina uzlů dosažitelná, MariaDB se pokusí přenést komunikaci, takže pokud existuje způsob, jak se k těmto uzlům dostat, budou dosaženy.
Příklad je vidět na výše uvedeném diagramu:DC 1 ztratil připojení s DC2, ale DC2 a DC3 lze připojit. V tomto případě bude jeden z uzlů v DC3 použit k přenosu dat z DC1 do DC2, což zajistí, že komunikace uvnitř clusteru bude zachována.
MariaDB je schopna provádět akce na základě stavu clusteru. Implementuje kvorum - většina uzlů musí být k dispozici, aby mohl cluster fungovat. Pokud se uzel odpojí od clusteru a nemůže dosáhnout žádného jiného uzlu, přestane fungovat.
Jak je vidět na obrázku výše, došlo k částečné ztrátě síťové komunikace v DC1 a postižený uzel je odstraněn z clusteru, což zajišťuje, že aplikace nebude přistupovat k zastaralým datům.
To platí i ve větším měřítku. DC1 přerušila veškerou komunikaci. V důsledku toho bylo z clusteru odstraněno celé datové centrum a žádný z jeho uzlů nebude obsluhovat provoz. Zbytek clusteru si udržel většinu (6 z 9 uzlů je k dispozici) a sám se překonfiguroval, aby zachoval spojení mezi DC 2 a DC3. Ve výše uvedeném diagramu jsme předpokládali, že zapisovač zasáhne uzel v DC2, ale mějte prosím na paměti, že MariaDB může běžet s více zapisovači.
Návrh geograficky distribuovaného klastru MariaDB
Prošli jsme některé funkce, díky kterým se MariaDB Cluster dobře hodí pro geograficky distribuovaná prostředí, pojďme se nyní trochu zaměřit na design. Na začátku si vysvětlíme, s jakým prostředím pracujeme. Využijeme tři vzdálená datová centra, propojená přes Wide Area Network (WAN). Každé datové centrum bude přijímat zápisy z lokálních aplikačních serverů. Čtení bude také pouze místní. To má zabránit zbytečnému provozu protínajícímu WAN.
Aby byl tento blog méně komplikovaný, nebudeme zabíhat do podrobností o tom, jak by připojení mělo vypadat. Předpokládáme nějaký druh správně nakonfigurovaného zabezpečeného připojení napříč všemi datovými centry. K implementaci lze použít VPN nebo jiné nástroje.
Použijeme MaxScale jako loadbalancer. MaxScale bude nasazen lokálně v každém datovém centru. Bude také směrovat provoz pouze do místních uzlů. Vzdálené uzly lze vždy přidat ručně a vysvětlíme případy, kdy by to mohlo být dobré řešení. Aplikace lze nakonfigurovat tak, aby se připojovaly k jednomu z místních uzlů MaxScale pomocí algoritmu round-robin. Ke směrování provozu do jediného uzlu MaxScale můžeme také použít Keepalived a Virtual IP, pokud by jediný uzel MaxScale byl schopen zvládnout veškerý provoz.
Dalším možným řešením je spojit MaxScale s aplikačními uzly a nakonfigurovat aplikaci pro připojení k proxy na localhost. Tento přístup funguje docela dobře za předpokladu, že je nepravděpodobné, že MaxScale nebude k dispozici, přesto by aplikace fungovala na stejném uzlu. Typicky to, co vidíme, je buď selhání uzlu, nebo selhání sítě, což by ovlivnilo MaxScale i aplikaci současně.
Výše uvedený diagram ukazuje verzi prostředí, kde MaxScale tvoří proxy farmy - všechny proxy uzly se stejnou konfigurací, zátěž vyvážená pomocí Keepalived, nebo jednoduše kruhová komunikace z aplikace napříč všemi uzly MaxScale. MaxScale je nakonfigurován tak, aby rozložil pracovní zátěž mezi všechny uzly MariaDB v místním datovém centru. Jeden z těchto uzlů by byl vybrán jako uzel pro odesílání zápisů, zatímco SELECTy by byly distribuovány mezi všechny uzly. Mít jeden vyhrazený zapisovací uzel v datovém centru pomáhá snížit počet možných konfliktů certifikace, což obvykle vede k lepšímu výkonu. Abychom to ještě více snížili, museli bychom začít posílat provoz přes připojení WAN, což není ideální, protože by se výrazně zvýšilo využití šířky pásma. Právě teď, když jsou segmenty na místě, se přes datová centra odesílají pouze dvě kopie sady zápisů – jedna na DC.
Závěr
Jak můžete vidět, MariaDB Cluster lze snadno použít k vytvoření geograficky distribuovaných clusterů, které mohou fungovat i po celém světě. Limitujícím faktorem bude latence sítě. Pokud je příliš vysoká, možná budete muset zvážit použití samostatných clusterů MariaDB připojených pomocí asynchronní replikace.