Databastillgänglighet är en av de viktigaste aspekterna av applikationsarkitektur. Även om det är givet att förhindra driftstopp av datacenter, kommer det att hända alla så småningom. Även de bäst drivna datacentren kommer att gå ner totalt då och då. Till exempel Amazon AWS-avbrott den 26/8/13 och 9/13/13. Den viktiga frågan att ställa är om detta är acceptabelt för din ansökan? De flesta applikationer kan tolerera lite driftstopp då och då, men vissa applikationer kräver nästan 100 % drifttid och databasarkitekturen för dessa applikationer kräver en mer medveten designstrategi. Latenserna mellan datacentren tenderar att vara ganska stora, så noggrann eftertanke måste läggas på utformningen av din MongoDB-värdinstallation.
MongoDB Upptidsmål
- Din databas bör vara uppe och skrivbar, även om ett komplett datacenter går ner.
- Din databasväxling bör vara automatisk i händelse av server-/datacenterfel.
- Ett enskilt serverfel bör inte få den primära att byta till ett annat datacenter.
Design av datacenter
För att uppfylla våra mål kom vi fram till tre datacenterdesigner med 4+1 replikauppsättning:
- Datacenter 1: Primär (Prioritet 10), Sekundär 0 (Primär 9)
- Datacenter 2: Sekundär 1 (Prioritet 8), Sekundär 2 (Prioritet 7)
- Datacenter 3: Skiljedomare
Vi placerar två fullvärdiga medlemmar i vart och ett av de första två datacentren och en medlare i det tredje datacentret. Vi har också konfigurerat prioriteten för varje server så att vi kan kontrollera vilken medlem som blir primär vid serverfel.
Det finns ett par nackdelar med denna geo- distribuerad arkitektur:
- Om du har en skrivtung applikation kommer sekundärerna i ett annat datacenter alltid att släpa efter på grund av den större latensen. Om vissa data är avgörande, kanske du vill använda en MongoDB-skrivproblem av "Majority" för att se till att alla noder committerar data.
- MongoDB-gemenskapsbyggen har inte SSL aktiverat. Du kanske vill skapa en build med SSL aktiverat eller använda MongoDB DBaaS på ScaleGrid så att data som flödar över regioner krypteras.
Amazon AWS / EC2 Tillgänglighet
Om du distribuerar MongoDB på AWS, motsvarar varje datacenter på den här bilden en Amazon-region och inte en tillgänglighetszon. Amazon tillhandahåller inte tillgänglighetsgarantier i en enda tillgänglighetszon, SLA är för hela regionen. Om du distribuerar över tillgänglighetszoner är din SLA 99,95 % vilket fortfarande är en bra SLA – men om en hel region går ner kommer din databas att gå ner. Dessutom har vissa AWS-regioner bara två tillgänglighetszoner, så särskild uppmärksamhet måste ägnas åt att placera den tredje noden i en annan region så att en enskild regions driftstopp inte tar ner hela databasen.
Lägre kostnadstillgänglighet över geografiska områden
En enklare version av samma arkitektur använder endast tre servrar och placerar endast en replik i varje datacenter. Nackdelen med detta tillvägagångssätt är att ett enda serverfel kommer att få den primära att flytta över datacenter. Denna arkitektur kostar dock mindre än den första arkitekturen. Beroende på ditt scenario kan det fungera för dig.
Det finns många sätt att uppnå hög drifttid med MongoDB, och detta är precis det sätt som fungerar för våra behov. Om du har andra intressanta arkitekturer, vänligen maila oss på [email protected]. Vi vill gärna höra dina tankar!