Dostupnost databáze je jedním z nejdůležitějších aspektů architektury aplikací. I když je prevence výpadků datového centra samozřejmostí, nakonec se to stane každému. I ta nejlépe provozovaná datová centra se každou chvíli úplně zhroutí. Například výpadky Amazon AWS 26. 8. 2013 a 13. 9. 2013. Důležitou otázkou je, zda je to přijatelné pro vaši aplikaci? Většina aplikací občas toleruje nějaký výpadek, nicméně některé aplikace vyžadují téměř 100% dostupnost a databázová architektura těchto aplikací vyžaduje promyšlenější návrhový přístup. Latence mezi datovými centry bývají poměrně velké, takže je třeba pečlivě zvážit návrh nasazení vašeho hostingu MongoDB.
Cíle provozuschopnosti MongoDB
- Vaše databáze by měla být funkční a zapisovatelná, i když dojde k výpadku celého datového centra.
- Vaše databázové selhání by mělo být automatické v případě selhání serveru/datového centra.
- Selhání jednoho serveru by nemělo způsobit přepnutí primárního do jiného datového centra.
Návrh datového centra
Abychom splnili naše cíle, přišli jsme se třemi návrhy datových center s použitím sady replik 4+1:
- Datové centrum 1: Primární (Priorita 10), Sekundární 0 (Primární 9)
- Datové centrum 2: Sekundární 1 (Priorita 8), Sekundární 2 (Priorita 7)
- Datové centrum 3: arbitr
Do každého z prvních dvou datových center umisťujeme dva řádné členy a do třetího datového centra rozhodce. Také jsme nakonfigurovali prioritu pro každý server, abychom mohli řídit, který člen se stane primárním v případě selhání serveru.
Tato zeměpisná poloha má několik nevýhod distribuovaná architektura:
- Pokud máte aplikaci s velkým množstvím zápisu, sekundární servery v jiném datovém centru budou vždy zaostávat kvůli větší latenci. Pokud jsou některá data klíčová, možná budete chtít použít starost o zápis MongoDB „Většina“, abyste se ujistili, že data odevzdávají všechny uzly.
- Sestavení komunity MongoDB nemají povoleno SSL. Možná budete chtít vytvořit sestavení s povoleným SSL nebo použít MongoDB DBaaS na ScaleGrid, aby data proudící napříč regiony byla šifrována.
Dostupnost Amazon AWS / EC2
Pokud nasazujete MongoDB na AWS, každé datové centrum na tomto obrázku odpovídá oblasti Amazonie, nikoli zóně dostupnosti. Amazon neposkytuje záruky dostupnosti v jedné zóně dostupnosti, SLA jsou pro celý region. Pokud nasadíte napříč zónami dostupnosti, vaše SLA je 99,95 %, což je stále skvělá SLA – pokud však dojde k výpadku celého regionu, dojde k výpadku i vaší databáze. Některé oblasti AWS mají také pouze dvě zóny dostupnosti, takže je třeba věnovat zvláštní pozornost umístění třetího uzlu v jiné oblasti, aby výpadek v jedné oblasti nesnížil celou databázi.
Dostupnost s nižšími náklady v různých zeměpisných oblastech
Jednodušší verze stejné architektury využívá pouze tři servery a do každého datového centra umísťuje pouze jednu repliku. Nevýhodou tohoto přístupu je, že selhání jediného serveru způsobí přesun primárního mezi datovými centry. Tato architektura však stojí méně než první architektura. V závislosti na vašem scénáři vám to může fungovat.
Existuje mnoho způsobů, jak dosáhnout vysoké dostupnosti s MongoDB, a toto je právě způsob, který vyhovuje našim potřebám. Pokud máte další zajímavé architektury, napište nám na adresu [email protected]. Rádi bychom slyšeli váš názor!