Infrastruktur eines MongoDB Replica Sets

Die Konfiguration eines Replica Sets im vorherigen Kapitel fokussierte auf Software – Members, Prioritäten, Read Preferences. Aber Software läuft auf Hardware, und die physische Infrastruktur bestimmt fundamental, wie robust und performant ein Replica Set ist. Ein perfekt konfiguriertes Set auf schlechter Hardware oder mit mangelhafter Netzwerk-Architektur wird enttäuschen. Umgekehrt kann exzellente Infrastruktur suboptimale Konfiguration teilweise kompensieren.

Infrastruktur-Planung für Replica Sets muss mehrere Dimensionen berücksichtigen: geografische Verteilung für Disaster Recovery, Netzwerk-Latenz und Bandbreite für effiziente Replikation, Hardware-Dimensionierung für Performance, und Sicherheit auf allen Ebenen. Diese Entscheidungen sind nicht nachträglich korrigierbar ohne signifikanten Aufwand – ein Rechenzentrum zu verlagern oder die Netzwerk-Topologie umzubauen ist teuer und riskant. Die initiale Planung sollte deshalb gründlich sein.

20.1 Physische Topologie: Einzelstandort versus geografische Verteilung

Die grundlegendste Infrastruktur-Entscheidung ist, wo Members physisch laufen. Die einfachste Variante ist ein Einzelstandort-Setup: Alle drei (oder mehr) Nodes des Replica Sets befinden sich im selben Rechenzentrum, oft im selben Rack, manchmal sogar als VMs auf denselben physischen Hosts. Diese Topologie minimiert Latenz und Komplexität. Die Netzwerk-Verbindung zwischen Nodes ist schnell – Sub-Millisekunde typischerweise. Configuration und Troubleshooting sind simpel, weil alles lokal ist.

Der fundamentale Nachteil: Keine Resilienz gegen Standort-Ausfälle. Fällt das Rechenzentrum aus – durch Stromausfall, Netzwerk-Trennung, Brand, Naturkatastrophe – ist das gesamte Replica Set nicht verfügbar. Für viele Anwendungen ist dies akzeptabel. Ein internes Tool, das einige Stunden Downtime verkraften kann, braucht keine Multi-Datacenter-Architektur. Aber für kritische Produktionssysteme, wo Uptime nicht verhandelbar ist, ist Einzelstandort ein inakzeptables Risiko.

Geografisch verteilte Setups platzieren Members in verschiedenen Rechenzentren. Die minimale Variante: Zwei Datacenters. Das Primary-Datacenter hostet den Primary und einen Secondary. Das Backup-Datacenter hostet einen Secondary (oder Arbiter). Fällt das Primary-Datacenter aus, bleibt der Secondary im Backup-Datacenter verfügbar, kann aber nicht zum Primary werden, weil keine Mehrheit existiert (ein Node kann sich nicht selbst wählen). Das Set ist read-only bis das Primary-Datacenter zurückkommt.

Für echte Hochverfügbarkeit braucht es drei Datacenters oder eine clevere Arbiter-Platzierung. Ein klassisches Setup: Primary-DC mit Primary + Secondary, Backup-DC mit Secondary, und ein dritter Mini-DC (oder Cloud-Region) mit Arbiter. Bei Ausfall des Primary-DC können Backup-DC und Arbiter eine Election durchführen (2 von 3 Stimmen), und der Secondary im Backup-DC wird Primary. Die Anwendung bleibt verfügbar, wenn auch mit eingeschränkter Redundanz (nur ein Daten-Node statt zwei).

Die Herausforderungen geografisch verteilter Setups sind Latenz und Bandbreite. Wide Area Networks (WANs) sind langsamer als lokale. Die Latenz zwischen Datacenters ist typischerweise 10-100 ms, abhängig von Distanz und Routing. Diese Latenz betrifft Replikation – jede Operation muss über das WAN zu entfernten Secondaries. Mit writeConcern: { w: "majority" } wartet der Write, bis eine Mehrheit bestätigt hat, was WAN-Roundtrip bedeutet. Ein Write, der lokal 5 ms dauert, könnte mit WAN-Replikation 50 ms dauern.

Die Bandbreite muss ausreichend sein für kontinuierliche Oplog-Replikation. Ein hochfrequentes System mit Gigabytes Writes pro Stunde braucht entsprechend Bandbreite. Ist die WAN-Verbindung zu langsam, baut sich Replication Lag auf. Secondaries im entfernten DC fallen zurück, was die Robustheit untergräbt – genau das, was man mit Geo-Verteilung erreichen wollte.

Die Kosten sind nicht trivial. Bandbreite zwischen Datacenters kostet, besonders bei hohem Volumen. Cloud-Provider berechnen Egress-Traffic. Ein Set mit 100 GB täglichem Write-Volumen, das zu einem entfernten DC repliziert, kann signifikante monatliche Netzwerk-Kosten verursachen. Diese müssen gegen den Wert von Geo-Redundanz abgewogen werden.

20.2 Netzwerk-Architektur: Latenz, Bandbreite und Sicherheit

Netzwerk ist das Rückgrat eines Replica Sets. Members kommunizieren kontinuierlich: Heartbeats alle 2 Sekunden, Oplog-Replikation kontinuierlich, Election-Messages bei Bedarf. Schlechtes Netzwerk führt zu Problemen, die schwer zu debuggen sind – sporadische Elections, Replication Lag, Connection Timeouts.

Die Latenz zwischen Members sollte niedrig und stabil sein. Innerhalb eines Datacenters ist Sub-Millisekunde normal. Über WANs steigt es auf 10-100 ms. MongoDB toleriert dies, aber es gibt Limits. Über 100 ms Latenz wird problematisch – Elections dauern länger, Replikation hinkt hinterher, und die Gefahr von Timeouts steigt. Transatlantische oder transpacifische Deployments (150-300 ms Latenz) sind möglich, erfordern aber aggressives Tuning von Timeouts und Careful Design von Write Concerns.

Jitter – Variabilität in Latenz – ist oft schlimmer als hohe aber stabile Latenz. Wenn die Verbindung normalerweise 20 ms hat, aber sporadisch auf 200 ms springt, verwirrt dies MongoDBs Heartbeat-Logik. Ein Member könnte als down markiert werden, nur um Sekunden später wieder da zu sein. Dies triggert unnötige Elections und destabilisiert das Set.

Die Bandbreite muss für Peak-Load dimensioniert sein, nicht für Average. Ein System mit durchschnittlich 10 MB/s Writes könnte Spitzen von 100 MB/s haben. Die WAN-Verbindung muss diese Spitzen handhaben, sonst baut sich Lag auf. Monitoring der Netzwerk-Utilization ist kritisch – ein Link, der konstant über 80% ausgelastet ist, ist ein Bottleneck.

MongoDB nutzt standardmäßig Port 27017 für Client-Verbindungen und Inter-Member-Kommunikation. In Firewall-geschützten Umgebungen müssen diese Ports explizit geöffnet werden. Für geografisch verteilte Setups läuft Member-zu-Member-Kommunikation idealerweise über private Netzwerke oder VPNs, nicht über das öffentliche Internet. Selbst mit TLS/SSL-Verschlüsselung ist ein privates Netzwerk sicherer und oft performanter.

TLS/SSL für MongoDB-Verbindungen ist nicht optional in Produktion. Die Konfiguration erfolgt in mongod.conf:

net:
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/mongodb.pem
    CAFile: /etc/ssl/ca.pem

Jeder Member braucht ein Zertifikat, signiert von einer gemeinsamen CA. Clients und Members validieren diese Zertifikate bei Verbindungsaufbau. Dies schützt gegen Man-in-the-Middle-Angriffe und stellt sicher, dass nur autorisierte Nodes dem Set beitreten.

20.3 Hardware-Dimensionierung: CPU, RAM und Storage

Die Hardware-Anforderungen eines Replica-Set-Members hängen stark von der Workload ab. Ein Read-heavy System mit großem Dataset braucht viel RAM. Ein Write-heavy System braucht schnellen Storage und starke CPU. Ein Analytics-Workload braucht alles. Generische Empfehlungen sind schwierig, aber einige Prinzipien gelten universell.

CPU: MongoDB ist multi-threaded und nutzt moderne Multi-Core-Prozessoren gut. WiredTiger parallelisiert Reads und Writes effizient. Für typische Workloads reichen 8-16 Cores. Mehr Cores helfen bei extrem hoher Concurrency, aber der Benefit flacht ab. Ein 64-Core-Monster ist selten nötig. Wichtiger als Core-Count ist Clock-Speed – MongoDB profitiert von schnellen Cores mehr als von vielen langsamen.

RAM: Dies ist oft der limitierende Faktor. WiredTiger’s Cache hält das Working Set im RAM. Queries, die im Cache bedient werden, sind Größenordnungen schneller als solche, die zu Disk gehen. Die Faustregel: Der Cache sollte das Working Set komplett halten können. Für eine 100-GB-Datenbank, wo 20 GB häufig abgefragt werden, sollten mindestens 20 GB Cache verfügbar sein. WiredTiger nutzt standardmäßig 50% des RAM minus 1 GB, also wären 42 GB RAM nötig (50% = 21 GB, minus 1 GB = 20 GB für Working Set, plus OS und andere Prozesse).

Mehr RAM ist fast immer besser. Ein Server mit 64 GB RAM kann ein 30 GB Working Set komfortabel halten, mit Puffer für Spitzen. Zu wenig RAM führt zu Disk I/O, was Latenz dramatisch erhöht. Ein Query, der in 5 ms aus RAM bedient wird, kann 50-500 ms dauern, wenn er zu Disk muss (abhängig von HDD vs. SSD).

Storage: SSDs sind für moderne MongoDB-Deployments praktisch Pflicht. HDDs sind zu langsam für Random I/O, das MongoDB intensiv nutzt. NVMe SSDs sind ideal – sie bieten Sub-Millisekunde-Latenz und Hunderttausende IOPS. SATA SSDs sind ein Budget-Kompromiss, deutlich besser als HDDs, aber langsamer als NVMe.

Die Speicherkapazität sollte für Datenwachstum dimensioniert sein. Eine Datenbank, die aktuell 200 GB groß ist und 10% monatlich wächst, braucht in einem Jahr 200 GB * 1.10^12 ≈ 630 GB. Dazu kommt Overhead für Oplog, Indizes, Journal und temporäre Dateien. Eine 1-TB-SSD wäre angemessen dimensioniert.

Das Dateisystem sollte XFS sein, wie in Kapitel 11 diskutiert. Mit noatime Mount-Option und periodischem fstrim für SSDs. Diese Details scheinen trivial, haben aber messbaren Performance-Impact.

20.4 Betriebssystem und Tuning

Linux ist die bevorzugte Plattform für produktive MongoDB-Deployments. Ubuntu LTS, RedHat Enterprise Linux oder CentOS sind bewährte Wahl. Windows funktioniert, wird aber seltener in Produktion gesehen und erreicht typischerweise nicht die Performance von Linux.

Transparent Huge Pages (THP) sollten deaktiviert werden. MongoDB und THP vertragen sich nicht gut – THP führt zu unvorhersehbaren Latenz-Spikes. Die Deaktivierung erfolgt beim Boot:

# /etc/rc.local oder systemd service
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

NUMA (Non-Uniform Memory Access) sollte für MongoDB deaktiviert oder korrekt konfiguriert werden. Auf NUMA-Systemen kann MongoDB suboptimal performen, wenn der mongod-Prozess auf Memory zugreift, das nicht zum lokalen NUMA-Node gehört. Die Lösung ist entweder NUMA im BIOS deaktivieren oder mongod mit numactl starten:

numactl --interleave=all mongod --config /etc/mongod.conf

File Descriptors müssen erhöht werden. MongoDB öffnet viele Dateien und Sockets gleichzeitig. Der Linux-Default (typischerweise 1024) ist zu niedrig. In /etc/security/limits.conf:

Diese Limits erlauben dem mongodb-User, bis zu 64.000 Files und Prozesse zu öffnen – ausreichend für große Deployments.

20.5 Sicherheit: Defense in Depth

Sicherheit für Replica Sets erfordert mehrere Schichten. Netzwerk-Segmentierung, Authentifizierung, Autorisierung, Verschlüsselung und Auditing arbeiten zusammen, um Daten zu schützen.

Netzwerk-Segmentierung: MongoDB-Server sollten in einem privaten Netzwerk oder VLAN laufen, unerreichbar vom öffentlichen Internet. Nur Application-Server haben Zugriff. Firewall-Regeln erzwingen dies. Auf einem Linux-Server mit iptables:

# Erlaube nur spezifische IPs auf Port 27017
iptables -A INPUT -p tcp -s 10.0.1.0/24 --dport 27017 -j ACCEPT
iptables -A INPUT -p tcp --dport 27017 -j DROP

Dies erlaubt nur dem 10.0.1.0/24 Subnet (typischerweise App-Server) Zugriff auf MongoDB. Alle anderen Anfragen werden gedroppt.

Authentifizierung: MongoDB-Instanzen sollten immer mit Authentifizierung laufen. Die Konfiguration in mongod.conf:

security:
  authorization: enabled
  keyFile: /etc/mongodb-keyfile

Der keyFile ist eine shared secret zwischen allen Members des Replica Sets. Jeder Member muss denselben Key haben. Der Key ist eine Datei mit mindestens 6 Zeichen, typischerweise 1024 Bytes Random-Data:

openssl rand -base64 756 > /etc/mongodb-keyfile
chmod 400 /etc/mongodb-keyfile
chown mongodb:mongodb /etc/mongodb-keyfile

Dieser Key muss auf alle Members kopiert werden. Mit dem Key können sich Members untereinander authentifizieren – ohne den korrekten Key kann ein Node dem Set nicht beitreten.

Autorisierung: Role-Based Access Control (RBAC) definiert, was authentifizierte User tun dürfen. Für Application-User sollte das Principle of Least Privilege gelten – nur die minimal notwendigen Rechte. Ein Web-App-User braucht readWrite auf der App-Datenbank, aber keine Rechte auf admin oder andere Datenbanken.

Verschlüsselung: TLS/SSL für Network-Encryption wurde bereits erwähnt. Zusätzlich sollte Encryption-at-Rest aktiviert werden. MongoDB Enterprise unterstützt native Encryption-at-Rest:

security:
  enableEncryption: true
  encryptionKeyFile: /etc/mongodb-encryption-key

Oder man nutzt Filesystem-Level-Encryption wie LUKS unter Linux. Dies verschlüsselt das gesamte Volume, auf dem MongoDB-Daten liegen.

Auditing: Für Compliance-intensive Umgebungen ist Audit-Logging kritisch. MongoDB Enterprise unterstützt umfassendes Auditing:

auditLog:
  destination: file
  format: JSON
  path: /var/log/mongodb/audit.log
  filter: '{ atype: { $in: [ "authenticate", "createUser", "dropDatabase" ] } }'

Dies loggt alle Authentication-Events, User-Erstellung und Database-Drops. Die Logs sind forensisch wertvoll bei Security-Incidents.

20.6 Monitoring: Proaktive Überwachung statt reaktive Feuerlöschung

Monitoring eines Replica Sets ist nicht optional. Ohne Monitoring weiß man erst von Problemen, wenn die Anwendung kaputt ist. Mit Monitoring sieht man Probleme bevor sie kritisch werden – Replication Lag steigt, Disk füllt sich, CPU hitzt auf.

MongoDB bietet mehrere Monitoring-Ansätze. db.serverStatus() in der Shell gibt momentane Metriken:

db.serverStatus()

Dies returned ein riesiges Dokument mit hunderten Metriken: Connections, Operations pro Sekunde, Cursor-Counts, Memory-Nutzung, Network I/O. Für Ad-hoc-Debugging ist dies wertvoll, aber nicht für kontinuierliches Monitoring.

MongoDB Ops Manager (on-prem) oder Cloud Manager / Atlas (cloud) sind MongoDBs eigene Monitoring-Lösungen. Sie sammeln Metriken kontinuierlich, visualisieren sie in Dashboards und können Alerts triggern. Für Teams, die primär MongoDB verwenden, sind diese Tools oft die beste Wahl – sie sind spezifisch für MongoDB designed und verstehen deren Metriken nativ.

Für heterogene Umgebungen, wo MongoDB nur eine von vielen Technologien ist, bieten sich generische Monitoring-Stacks an. Prometheus mit MongoDB Exporter sammelt Metriken und Grafana visualisiert sie. Alertmanager kann Alerts zu PagerDuty oder Slack schicken. Diese Kombination ist Open-Source und integriert mit beliebigen Systemen.

Replication Lag: Die Differenz zwischen Primary’s Oplog-Position und Secondaries’. Lag über 10 Sekunden ist ein Warnsignal, über 60 Sekunden kritisch. Ursachen können unterdimensionierte Hardware, langsames Netzwerk oder extreme Write-Last sein.

Oplog Window: Wie lange dauert es, bis das Oplog sich füllt. Ein 24-Stunden-Window bedeutet, ein Secondary kann 24 Stunden offline sein und noch aufholen. Unter 12 Stunden ist riskant – ein längerer Ausfall erfordert Full Resync.

Connections: Anzahl offener Verbindungen. MongoDB hat Limits (Default typischerweise 65536), und Connection-Leaks in Anwendungen können diese erschöpfen. Monitoring zeigt, ob Connections steigen ohne zu fallen.

Disk Space: Selbsterklärend, aber kritisch. Ein volles Filesystem stoppt MongoDB hart. Monitoring mit Alert bei 80% Nutzung gibt Zeit zu reagieren.

CPU und RAM: Sustained hohe CPU (>80%) deutet auf undersized Hardware oder ineffiziente Queries. RAM-Nutzung nahe Limit führt zu Swapping, was Performance killt.

Ein typisches Monitoring-Setup pollt diese Metriken jede Minute, visualisiert Trends und alertet bei Anomalien. Das Ziel: Probleme sehen bevor sie die Anwendung beeinträchtigen.

20.7 Backup-Strategie: Redundanz ist kein Backup

Ein Replica Set repliziert Daten, aber Replikation ist kein Backup. Löscht eine Applikation versehentlich eine Collection, repliziert diese Deletion zu allen Members. Innerhalb von Sekunden ist die Collection überall weg. Ein Backup ist eine zeitpunktbezogene Kopie, die vor logischen Fehlern schützt.

Backups sollten von einem Secondary genommen werden, um den Primary nicht zu belasten. mongodump ist das klassische Tool:

mongodump --host secondary.example.com:27017 \
          --out /backups/mongodb-$(date +%Y%m%d)

Dies exportiert alle Datenbanken als BSON-Files. Der Restore erfolgt mit mongorestore. Diese Methode ist simpel, funktioniert, aber langsam bei großen Datenbanken (hunderte GB dauern Stunden).

Schneller sind Filesystem-Level-Snapshots. Auf LVM oder Cloud-Block-Storage kann man den Secondary stoppen (oder in read-only versetzen), Snapshot ziehen, Secondary wieder starten. Der Snapshot ist ein point-in-time Image des Dateisystems, sofort wiederherstellbar.

MongoDB Atlas bietet Continuous Backups – kontinuierliche Oplog-basierte Backups mit Point-in-Time-Recovery. Man kann zu jedem beliebigen Zeitpunkt der letzten X Tage zurückkehren. Dies ist Gold-Standard, erfordert aber Atlas oder selbst-gebaute Infrastruktur.

Die Backup-Retention sollte Policy-basiert sein. Tägliche Backups für 7 Tage, wöchentliche für 4 Wochen, monatliche für 12 Monate ist eine typische Retention. Backups müssen geografisch getrennt gelagert werden – im anderen Datacenter oder Cloud-Region. Ein Feuer im Datacenter, das Produktion und Backups zerstört, ist der Super-GAU.

Die Infrastruktur eines Replica Sets ist komplex und multi-dimensional. Geografische Topologie, Netzwerk-Architektur, Hardware-Specs, OS-Tuning, Security und Monitoring müssen alle aufeinander abgestimmt sein. Eine Schwachstelle – langsames WAN, unterdimensionierter RAM, fehlende Firewalls – untergräbt das gesamte System. Die Planung sollte gründlich sein, aber auch pragmatisch. Perfekt ist der Feind von gut genug. Ein solides, gut überwachtes Setup ist besser als ein theoretisch perfektes, das nie fertig wird.

20 Infrastruktur eines MongoDB Replica Sets