Hybridní prostředí, kde je část databázové infrastruktury umístěna on-prem a část je umístěna ve veřejném cloudu, nejsou neobvyklá. Důvody pro použití takového nastavení mohou být různé – škálovatelnost, flexibilita, vysoká dostupnost, zotavení po havárii. Jak toto nastavení správně implementovat? To může být náročné, protože musíte zvážit několik kusů skládačky, které do sebe musí zapadnout. Účelem tohoto blogu je poskytnout vám určitý přehled o tom, jak takové nastavení může vypadat.
Připojení
Nezacházíme zde do podrobností, protože existuje mnoho způsobů, jak nastavit konektivitu mezi místním nastavením a veřejným cloudem. Bude to záviset na infrastruktuře, kterou máte, veřejném cloudu, který chcete používat, a mnoha dalších faktorech. Škála možností může začít u směrovačů s podporou BGP, přes hardwarovou VPN, softwarovou VPN až po tunely SSH jako způsob dočasného připojení vaší sítě k instancím ve veřejném cloudu. Co je důležité, ať už budete dělat cokoli, konečným výsledkem by mělo být úplné a transparentní připojení z vaší místní sítě k instancím umístěným ve veřejném cloudu.
Úvahy o vysoké dostupnosti
Replikace MySQL je skvělý způsob, jak budovat vysoce dostupné systémy, ale přináší značná omezení. Hlavní věc, kterou je třeba vzít v úvahu, je spisovatel - můžete mít pouze jedno místo, kam můžete posílat své záznamy - mistr. Bez ohledu na to, jak chcete celé prostředí navrhnout, musíte pečlivě zvážit umístění předlohy. S největší pravděpodobností chcete, aby to bylo součástí prostředí, které obsahuje hostitele aplikace. Podívejme se na následující nastavení:
Máme vlastní nastavení se třemi uzly MySQL a dvěma dalšími podřízenými zařízeními Nachází se ve veřejném cloudu a funguje jako prostředek pro obnovu po havárii pro společnost, je zcela jasné, že zapisovatelný uzel by měl být umístěn společně s hostiteli aplikace v privátní části cloudu. Chceme, aby byla latence u připojení, na kterých záleží nejvíce, co nejnižší.
Tento druh návrhu se zaměřuje na dostupnost databází – pokud uzly umístěné na prem nebudou dostupné, hostitelé aplikace se mohou připojit ke vzdálené části nastavení – uzly databáze se nacházejí ve veřejném cloudu. V ideálním případě byste k tomu použili nějaký druh proxy - ProxySQL je jedním z řešení, které může sledovat topologii a podle potřeby překonfigurovat na základě existujícího replikačního řetězce.
Chcete-li uvažovat spíše o nastavení typu active-active, kde máte aplikační uzly jak soukromé, tak veřejné, musíte udělat určité kompromisy, protože zápisy budou muset být přenášeny přes WAN, z veřejného do privátního cloudu (nebo naopak, pokud je vaše hlavní místo, kde působíte, ve veřejném cloudu).
ProxySQL je opět proxy server. Co je skvělé, ProxySQL lze nakonfigurovat jako ProxySQL Cluster, což zajišťuje, že změny konfigurace zavedené v jednom uzlu budou replikovány na zbývající uzly ProxySQL.
Ošetření poruch
Podívejme se na několik scénářů selhání. Před čímkoli musíme mít na paměti, že asynchronní replikace MySQL nepodporuje clustery, takže rozdělení sítě je něco, co musí být řešeno ručně – bude na uživateli, aby se rozhodl a přepnul přepínač na podporu jednoho z otroci v prostředí, které je k dispozici. Je také na uživateli, aby zajistil, že se prostředí, které ztratilo síťovou konektivitu, bude chovat tak, jak má, a nebude dále fungovat.
Pokud soukromá část cloudu přestane být dostupná, jak jsme již zmínili, bude k povýšení jednoho z otroků na nového pána vyžadován ruční zásah. Poté bude provoz všech zbývajících webových aplikačních serverů umístěných ve veřejném cloudu pomocí místního ProxySQL přesměrován na nový hlavní server a všechny zbývající podřízené servery. Na druhou stranu, vzhledem k tomu, že jsme ztratili tři z pěti uzlů MySQL, chceme škálovat nastavení veřejného cloudu – ClusterControl vám může pomoci efektivně přidávat další uzly do vašeho clusteru.
Dalším scénářem může být, že se zapisovač zhroutil, zatímco konektivita mezi naším místním nastavením a veřejným cloudem funguje dobře.
V takovém scénáři chceme povýšit jednoho z otroků na nového pána. V závislosti na požadavcích můžeme také chtít, aby byl nový master povýšen mezi uzly v dané části prostředí. ClusterControl má schopnost přidat na bílou listinu nebo černou listinu uzlů pro převzetí služeb při selhání, což zajišťuje, že máte plnou kontrolu nad procesem převzetí služeb při selhání a že si můžete vybrat, které uzly by měly být považovány za kandidáty na nový hlavní server a v jakém pořadí.
Doufáme, že vám tento blog poskytl určitou představu o tom, jak funguje nastavení hybridního cloudu pro replikaci MySQL a jak vás může ochránit v případě selhání databáze nebo sítě.