Datenbankverfügbarkeit ist einer der wichtigsten Aspekte der Anwendungsarchitektur. Während das Verhindern von Ausfallzeiten im Rechenzentrum eine Selbstverständlichkeit ist, wird es irgendwann jedem passieren. Selbst die besten Rechenzentren werden hin und wieder komplett ausfallen. Zum Beispiel die Amazon AWS-Ausfälle vom 26.08.13 und 13.09.13. Die wichtige Frage ist, ob dies für Ihre Anwendung akzeptabel ist. Die meisten Anwendungen können hin und wieder eine gewisse Ausfallzeit tolerieren, bestimmte Anwendungen erfordern jedoch eine Betriebszeit von nahezu 100 %, und die Datenbankarchitektur dieser Anwendungen erfordert einen bewussteren Designansatz. Die Latenzen zwischen den Rechenzentren sind in der Regel ziemlich groß, daher muss das Design Ihrer MongoDB-Hosting-Bereitstellung sorgfältig durchdacht werden.
MongoDB-Verfügbarkeitsziele
- Ihre Datenbank sollte aktiv und beschreibbar sein, selbst wenn ein komplettes Rechenzentrum ausfällt.
- Ihr Datenbank-Failover sollte im Falle eines Server-/Rechenzentrumsausfalls automatisch erfolgen.
- Ein Ausfall eines einzelnen Servers sollte nicht dazu führen, dass der primäre Server zu einem anderen Rechenzentrum wechselt.
Rechenzentrumsdesign
Um unsere Ziele zu erreichen, haben wir drei Rechenzentrumsdesigns mit einem 4+1-Replikatsatz entwickelt:
- Rechenzentrum 1: Primär (Priorität 10), Sekundär 0 (Primär 9)
- Rechenzentrum 2: Sekundär 1 (Priorität 8), Sekundär 2 (Priorität 7)
- Rechenzentrum 3: Schiedsrichter
Wir platzieren zwei Vollmitglieder in jedem der ersten beiden Rechenzentren und einen Schiedsrichter im dritten Rechenzentrum. Wir haben auch die Priorität für jeden Server konfiguriert, damit wir steuern können, welches Mitglied im Falle eines Serverausfalls ein primäres Mitglied wird.
Diese Geo- Verteilte Architektur:
- Wenn Sie eine schreibintensive Anwendung haben, werden die Secondaries in einem anderen Rechenzentrum aufgrund der größeren Latenz immer hinterherhinken. Wenn einige Daten von entscheidender Bedeutung sind, möchten Sie möglicherweise einen MongoDB-Schreibschutz von „Majority“ verwenden, um sicherzustellen, dass alle Knoten die Daten festschreiben.
- Bei den Builds der MongoDB-Community ist SSL nicht aktiviert. Möglicherweise möchten Sie einen Build mit aktiviertem SSL erstellen oder MongoDB DBaaS bei ScaleGrid verwenden, damit der Datenfluss zwischen Regionen verschlüsselt wird.
Amazon AWS/EC2-Verfügbarkeit
Wenn Sie MongoDB auf AWS bereitstellen, entspricht jedes Rechenzentrum in diesem Bild einer Amazon-Region und nicht einer Verfügbarkeitszone. Amazon bietet keine Verfügbarkeitsgarantien in einer einzelnen Verfügbarkeitszone, SLAs gelten für die gesamte Region. Wenn Sie verfügbarkeitszonenübergreifend bereitstellen, beträgt Ihr SLA 99,95 %, was immer noch ein großartiges SLA ist – wenn jedoch eine ganze Region ausfällt, wird Ihre Datenbank ausfallen. Außerdem haben bestimmte AWS-Regionen nur zwei Verfügbarkeitszonen, daher muss besonders darauf geachtet werden, den dritten Knoten in einer anderen Region zu platzieren, damit eine Ausfallzeit einer einzelnen Region nicht die gesamte Datenbank zum Absturz bringt.
Kostengünstigere Verfügbarkeit in allen Regionen
Eine einfachere Version derselben Architektur verwendet nur drei Server und platziert nur eine Replik in jedem Rechenzentrum. Der Nachteil dieses Ansatzes besteht darin, dass der Ausfall eines einzelnen Servers dazu führt, dass der primäre Server zwischen Rechenzentren verschoben wird. Diese Architektur kostet jedoch weniger als die erste Architektur. Abhängig von Ihrem Szenario könnte es für Sie funktionieren.
Es gibt viele Möglichkeiten, mit MongoDB eine hohe Betriebszeit zu erreichen, und dies ist genau die Art und Weise, die für unsere Anforderungen geeignet ist. Wenn Sie andere interessante Architekturen haben, senden Sie uns bitte eine E-Mail an [email protected]. Wir würden gerne Ihre Meinung hören!
