Databasebeschikbaarheid is een van de belangrijkste aspecten van applicatiearchitectuur. Hoewel het voorkomen van downtime van datacenters een gegeven is, zal het uiteindelijk iedereen overkomen. Zelfs de best gerunde datacenters gaan zo nu en dan volledig plat. Bijvoorbeeld de Amazon AWS-storingen van 26-8-13 en 13-9-13. De belangrijke vraag om te stellen is of dit acceptabel is voor uw toepassing? De meeste applicaties kunnen af en toe wat downtime tolereren, maar bepaalde applicaties vereisen bijna 100% uptime en de database-architectuur van deze applicaties vereist een meer bewuste ontwerpaanpak. De vertragingen tussen de datacenters zijn meestal vrij groot, dus er moet goed nagedacht worden over het ontwerp van uw MongoDB-hostingimplementatie.
MongoDB Uptime-doelen
- Uw database moet up-and-schrijfbaar zijn, zelfs als een compleet datacenter uitvalt.
- Uw database-failover zou automatisch moeten zijn in het geval van een server-/datacenterstoring.
- Een enkele serverstoring mag er niet toe leiden dat de primaire server overschakelt naar een ander datacenter.
Datacenterontwerp
Om onze doelen te bereiken, hebben we drie datacenterontwerpen bedacht met 4+1 replicaset:
- Datacenter 1: Primair (Prioriteit 10), Secundair 0 (Primair 9)
- Datacenter 2: Secundair 1 (Prioriteit 8), Secundair 2 (Prioriteit 7)
- Datacenter 3: Arbiter
We plaatsen twee volwaardige leden in elk van de eerste twee datacenters en een arbiter in het derde datacenter. We hebben ook de prioriteit voor elke server geconfigureerd, zodat we kunnen bepalen welk lid primair wordt in het geval van een serverstoring.
Er zijn een aantal nadelen aan deze geografische gedistribueerde architectuur:
- Als je een schrijfzware applicatie hebt, zullen de secondaries in een ander datacenter altijd achterblijven vanwege de grotere latentie. Als sommige gegevens cruciaal zijn, wilt u misschien een MongoDB-schrijfprobleem van "Meerderheid" gebruiken om ervoor te zorgen dat alle knooppunten de gegevens vastleggen.
- De MongoDB-communitybuilds hebben SSL niet ingeschakeld. Misschien wilt u een build maken met SSL ingeschakeld of de MongoDB DBaaS op ScaleGrid gebruiken, zodat gegevens die tussen regio's stromen, worden versleuteld.
Beschikbaarheid Amazon AWS / EC2
Als je MongoDB op AWS implementeert, komt elk datacenter op deze afbeelding overeen met een Amazon-regio en niet met een beschikbaarheidszone. Amazon biedt geen beschikbaarheidsgaranties in een enkele beschikbaarheidszone, SLA's zijn voor de hele regio. Als je in verschillende beschikbaarheidszones implementeert, is je SLA 99,95%, wat nog steeds een geweldige SLA is, maar als een hele regio uitvalt, gaat je database kapot. Ook hebben bepaalde AWS-regio's slechts twee beschikbaarheidszones, dus er moet speciale aandacht worden besteed aan het plaatsen van het derde knooppunt in een andere regio, zodat een downtime van een enkele regio niet de hele database naar beneden haalt.
Beschikbaarheid van lagere kosten in alle regio's
Een eenvoudigere versie van dezelfde architectuur gebruikt slechts drie servers en plaatst slechts één replica in elk datacenter. Het nadeel van deze aanpak is dat een enkele serverstoring ervoor zorgt dat de primaire server zich tussen datacenters verplaatst. Deze architectuur kost echter minder dan de eerste architectuur. Afhankelijk van uw scenario, kan het voor u werken.
Er zijn veel manieren om een hoge uptime te bereiken met MongoDB, en dit is precies de manier die voor onze behoeften werkt. Als je andere interessante architecturen hebt, stuur dan een e-mail naar [email protected]. We horen graag uw mening!