Installation eines MongoDB Sharded Cluster (Config Server + Shards + mongos)

Ein Sharded Cluster für den Fall, dass Datenmenge oder Schreiblast ein einzelnes Replica Set übersteigt: ein Config-Server-Replica-Set mit drei Mitgliedern, zwei oder drei Shard-Replica-Sets und zwei mongos-Router; interne Authentifizierung per Keyfile, Autorisierung, sh.addShard, Wahl des Shard Key, Sharding einer Collection, Balancer und Prüfung der Verteilung. Ergebnis ist ein horizontal skalierbarer Cluster, mit dem sich Anwendungen nur über die mongos verbinden. Passen die Daten auf einen einzelnen Server, ist eine Replica-Set-Installation einfacher und ausreichend.

Topologie: 3 Config Server + 2×3 Shard-Mitglieder + 2 mongos (mindestens 11 Server; für Tests weniger)

Vor dem Start

• Alle Server haben dasselbe, aktuelle Betriebssystem; die Zeit wird per NTP (chrony) synchronisiert. Zeitabweichungen zwischen Mitgliedern führen zu Problemen mit Sessions und Oplog.
• RAM und CPU entsprechen den Werten im Formular (der WiredTiger-Cache wird aus diesem Wert berechnet). Swap ist eingerichtet, aber klein.
• Das Datenverzeichnis (…) liegt auf einer eigenen Platte/LV, ist mit XFS formatiert, mit noatime eingehängt und in der fstab dauerhaft eingetragen. ext4 mit WiredTiger kann Performanceprobleme verursachen.
• Jeder Servername wird von allen Servern und von den Anwendungsservern aufgelöst (DNS oder /etc/hosts). In der Replica-Set-Konfiguration werden Namen verwendet, keine IPs.
• Zwischen den Servern sind die Ports …, …, … offen; das Anwendungsnetz erreicht diese Ports. Die Ports werden von keinem anderen Dienst belegt.
• Die Server erreichen repo.mongodb.org und pgp.mongodb.com per HTTPS, oder ein interner Mirror ist eingerichtet.
• Weder das mongodb-Paket des Betriebssystems noch eine alte MongoDB-Installation ist vorhanden.
• Vom ersten Server aus funktioniert scp zu den anderen als root (oder als Benutzer mit sudo-Rechten), um das Keyfile zu kopieren. Andernfalls übertrage die Datei manuell auf sicherem Weg.
• Du bist mit root- oder sudo-Rechten angemeldet; Wartungsfenster und ein Plan mit Server-Snapshot (Rückfallebene) stehen bereit.
• Der Shard Key wurde gemeinsam mit dem Anwendungsteam festgelegt: Filterfeld der häufigsten Abfragen, hohe Kardinalität, gleichmäßige Werteverteilung. Der Shard Key lässt sich später mit reshardCollection ändern, das ist aber aufwendig.

Phasen der Anleitung

• Vorbereitung des Betriebssystems (alle Server) — Hostname: … · Hostname: … · Hostname: … · Hostname: … · Hostname: … · Systemaktualisierung und benötigte Tools …
• Installation der MongoDB-Software — MongoDB-…-Repository hinzufügen · MongoDB-…-Repository hinzufügen · MongoDB-Serversoftware installieren (Config Server und Shards) · mongos und mongosh installieren (Router) · Datenverzeichnis vorbereiten · SELinux-Richtlinie, Labels und Ports …
• Keyfile (clusterinterne Authentifizierung) — Keyfile erzeugen · Keyfile auf alle Server kopieren · Berechtigungen des Keyfiles
• Config-Server-Replica-Set — mongod.conf (Config Server): … · mongod starten · rs.initiate (Config Server)
• Shard A (Replica Set shardA) — mongod.conf (Shard A): … · mongod starten · rs.initiate (Shard A) · Shard-lokaler Administrator (Shard A)
• Shard B (Replica Set shardB) — mongod.conf (Shard B): … · mongod starten · rs.initiate (Shard B) · Shard-lokaler Administrator (Shard B)
• Shard C (Replica Set shardC) — mongod.conf (Shard C): … · mongod starten · rs.initiate (Shard C) · Shard-lokaler Administrator (Shard C)
• mongos (Router) — mongos.conf: … · systemd-Dienst für mongos · mongos starten · Cluster-Administrator anlegen · Shards hinzufügen (sh.addShard) · Anwendungsbenutzer anlegen
• Shard Key und Sharding der Collection — Shard Key wählen (Entscheidungsschritt) · Collection sharden · Status des Balancers · Zeitfenster des Balancers
• Überprüfung — Cluster-Status · Verteilungstest · Status des Config-Server-Replica-Set · Verbindungszeichenfolge der Anwendung
• Nach der Installation — Log-Rotation · Sicherungsstrategie · Überwachung