Databasetilgængelighed er et af de vigtigste aspekter af applikationsarkitektur. Selvom det er givet at forhindre nedetid i datacentre, vil det ske for alle i sidste ende. Selv de bedst drevne datacentre kommer til at gå helt ned i ny og næ. For eksempel Amazon AWS-udfald af 8/26/13 og 9/13/13. Det vigtige spørgsmål at stille er, om dette er acceptabelt for din ansøgning? De fleste applikationer kan tåle en vis nedetid i ny og næ, dog kræver visse applikationer tæt på 100 % oppetid, og databasearkitekturen for disse applikationer kræver en mere bevidst designtilgang. Latenser mellem datacentrene har tendens til at være ret store, så der skal tænkes omhyggeligt ind i designet af din MongoDB-hostingimplementering.
MongoDB-oppetidsmål
- Din database skal være op og skrivbar, selvom et komplet datacenter går ned.
- Din database-failover bør være automatisk i tilfælde af server-/datacenterfejl.
- En enkelt serverfejl bør ikke få den primære til at skifte til et andet datacenter.
Datacenterdesign
For at opfylde vores mål kom vi med tre datacenterdesigns ved hjælp af 4+1 replikasæt:
- 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: Dommer
Vi placerer to fuldgyldige medlemmer i hvert af de to første datacentre og en dommer i det tredje datacenter. Vi har også konfigureret prioriteten for hver server, så vi kan kontrollere, hvilket medlem der bliver primært i tilfælde af serverfejl.
Der er et par ulemper ved denne geo- distribueret arkitektur:
- Hvis du har en skrivetung applikation, vil sekundærerne i et andet datacenter altid sakke bagud på grund af den større latenstid. Hvis nogle data er afgørende, vil du måske bruge en MongoDB-skrivebekymring af "Majority" for at sikre, at alle noder begår dataene.
- MongoDB-fællesskabsbygningerne har ikke SSL aktiveret. Du vil måske lave en build med SSL aktiveret eller bruge MongoDB DBaaS på ScaleGrid, så data, der flyder på tværs af regioner, er krypteret.
Amazon AWS / EC2 tilgængelighed
Hvis du implementerer MongoDB på AWS, svarer hvert datacenter på dette billede til en Amazon-region og ikke til en tilgængelighedszone. Amazon giver ikke tilgængelighedsgarantier i en enkelt tilgængelighedszone, SLA'er er for hele regionen. Hvis du implementerer på tværs af tilgængelighedszoner, er din SLA 99,95 %, hvilket stadig er en fantastisk SLA – men hvis en hel region går ned, vil din database gå ned. Desuden har visse AWS-regioner kun to tilgængelighedszoner, så der skal lægges særlig vægt på at placere den tredje node i en anden region, så en enkelt regions nedetid ikke bringer hele databasen ned.
Lavere pristilgængelighed på tværs af geografiske områder
En enklere version af den samme arkitektur bruger kun tre servere og placerer kun én replika i hvert datacenter. Ulempen ved denne tilgang er, at en enkelt serverfejl vil få den primære til at flytte på tværs af datacentre. Denne arkitektur koster dog mindre end den første arkitektur. Afhængigt af dit scenarie, kan det muligvis fungere for dig.
Der er mange måder at opnå høj oppetid på med MongoDB, og det er netop den måde, der fungerer for vores behov. Hvis du har andre interessante arkitekturer, bedes du kontakte os på [email protected]. Vi vil meget gerne høre dine tanker!