Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Artikel werden die erforderlichen Informationen zum Bereitstellen eines MongoDB-Clusters in Azure Kubernetes Service (AKS) erläutert. Außerdem bietet er eine Übersicht über die Bereitstellungsstrategie.
Wichtig
Open-Source-Software wird überall in AKS-Dokumenten und -Beispielen erwähnt. Software, die Sie bereitstellen, ist von AKS-Vereinbarungen zum Servicelevel, der eingeschränkten Garantie und dem Azure-Support ausgeschlossen. Wenn Sie Open-Source-Technologie zusammen mit AKS nutzen, nutzen Sie die Supportoptionen, die von den jeweiligen Communitys und Projektbetreuenden angeboten werden, um einen Plan zu entwickeln.
Microsoft übernimmt die Verantwortung für die Erstellung der Open-Source-Pakete, die wir in AKS bereitstellen. Diese Verantwortung schließt den vollständigen Besitz des Build-, Scan-, Signatur-, Validierungs- und Hotfixprozesses sowie die Kontrolle über die Binärdateien in Containerimages ein. Weitere Informationen finden Sie unter Sicherheitsrisikomanagement für AKS und AKS-Supportabdeckung.
Was ist MongoDB?
MongoDB ist ein beliebtes NoSQL-Datenbankverwaltungssystem, das für große Mengen unstrukturierter Daten konzipiert ist. Im Gegensatz zu herkömmlichen relationalen Datenbanken, die Tabellen und Zeilen verwenden, verwendet MongoDB einen flexiblen, dokumentorientierten Ansatz.
Hinweis
MongoDB Community Edition ist keine Open-Source-Software. Sie wird unter der serverseitigen öffentlichen Lizenz mit "Quelle verfügbar" lizenziert.
MongoDB-Shardcluster
Ein MongoDB-Shardcluster verarbeitet große Datasets und hohen Durchsatz, indem Daten server- oder shardübergreifend verteilt werden. Diese Architektur ermöglicht die horizontale Skalierung, die für Anwendungen mit wachsenden Daten- und Leistungsanforderungen unerlässlich ist.
Hier finden Sie eine Aufschlüsselung der wichtigsten Komponenten und Informationen zu ihrer Funktionsweise:
- Shards: einzelne MongoDB-Instanzen, die Teilmengen der Daten enthalten, werden als Shards bezeichnet. Jeder Shard ist eine Replikatgruppe oder eine Gruppe von MongoDB-Instanzen, die Daten untereinander replizieren. Replikate gewährleisten Hochverfügbarkeit und Fehlertoleranz.
- Konfigurationsserver: Server, auf denen Metadaten und Konfigurationseinstellungen für den Shardcluster gespeichert sind, werden als Konfigurationsserver bezeichnet. Sie überwachen die Datenverteilungs- und Routinginformationen des Clusters. In einem Cluster gibt es normalerweise drei Konfigurationsserver, um Redundanz bereitzustellen.
- Mongos-Instanzen:Mongos ist ein Routingdienst, der Clientanforderungen an den entsprechenden Shard weiterleitet. Dies fungiert als Vermittler zwischen dem Client und den Shards. Eine Instanz von Mongos verwaltet das Abfragerouting und aggregiert Ergebnisse aus Shards.
- Shard-Schlüssel: Wenn Daten über Shards verteilt werden, basiert sie auf einem Shardschlüssel, bei dem es sich entweder um ein einzelnes indiziertes Feld oder mehrere Felder in den Dokumenten handelt. Der Shardschlüssel bestimmt, wie Daten zwischen den Shards partitioniert werden. Ein sinnvoll ausgewählter Shardschlüssel stellt eine gleichmäßige Datenverteilung und effiziente Abfrage sicher.
- Datenverteilung: Daten werden basierend auf dem Shardschlüssel auf die Shards verteilt. Diese Verteilung hilft dabei, die Last auszugleichen und große Datasets effektiv zu verwalten. MongoDB verwendet je nach Shardschlüssel eine bereichsbasierte oder hashbasierte Shardingstrategie.
- Hochverfügbarkeit: Jeder Shard ist eine Replikatgruppe, d. h., er repliziert seine Daten knotenübergreifend. Mit diesem Setup wird sichergestellt, dass Daten auch dann verfügbar bleiben, wenn bei mindestens einem Knoten ein Fehler auftritt.
Percona-Operator für MongoDB
Percona Operator for MongoDB ist ein Open-Source-Tool, das Percona entwickelt hat. Es automatisiert die Bereitstellung, Verwaltung und Skalierung von MongoDB-Clustern in Kubernetes-Umgebungen. Es vereinfacht Vorgänge durch die Behandlung von Aufgaben wie Bereitstellung, Skalierung, Sicherung und Wiederherstellung. Die Verarbeitung all dieser Aufgaben trägt dazu bei, Hochverfügbarkeit und hohe Leistung von MongoDB-Clustern sicherzustellen.
Der Operator verwendet Kubernetes-CRDs (Custom Resource Definitions), um MongoDB-Konfigurationen deklarativ zu verwalten, Failover und Warnungen zu behandeln und die Überwachung zu gewährleisten. Das Ergebnis sind ein reduzierter Verwaltungsaufwand und einheitliche Verwaltungspraktiken. Percona Operator verbessert die Effizienz und Zuverlässigkeit von MongoDB-Bereitstellungen, insbesondere in cloudnativen Anwendungen. Er ist ideal für Entwicklungs-, Test- und Produktionsszenarien geeignet.
MongoDB-Lösungsübersicht
Der Ziel der vorgeschlagenen Lösung ist Folgendes:
- Sicherstellen, dass der MongoDB-Cluster große Datasets und Vorgänge mit hohem Durchsatz effektiv verarbeiten kann.
- Erhalten von Hochverfügbarkeit und Fehlertoleranz.
Die Lösung erreicht dieses Ziel mithilfe von Replikatsätzen, Antiaffinitätsregeln und der richtigen Ressourcenzuordnung.
Bereitstellungsstrategie
Die MongoDB-Bereitstellungsstrategie besteht aus den folgenden Komponenten:
- Shardcluster, um die shardübergreifende Verteilung von Daten zu ermöglichen und somit die Skalierbarkeit und Leistung zu verbessern
- Konfigurationsserver werden von einer Replikatgruppe mit drei Membern verwaltet, um Fehlertoleranz und Hochverfügbarkeit zu gewährleisten. Antiaffinitätsregeln verteilen diese Server über mehrere Fehlerdomänen.
- Drei Mongos-Instanzen sind verfügbarkeitszonenübergreifend verteilt werden intern im Cluster für Lastenausgleiche bereitgestellt. Sie bieten Lastenausgleich und Resilienz zum Weiterleiten von Clientanforderungen.
Beitragende
Microsoft pflegt diesen Artikel. Die folgenden Mitwirkenden haben es ursprünglich geschrieben:
- Ketan Chawda | Senior Customer Engineer
- Naveed Kharadi | Customer Experience Engineer
- Nelly Kiboi | Servicetechnikerin
- Saverio Proto | Principal Customer Experience Engineer
- Don High | Leitender Kundeningenieur
- LaBrina Loving | Hauptingenieurin für Dienstleistungen
- Ken Kilty | Leitender TPM
- Russell de Pina | Leiter TPM
- Colin Mixon | Produktmanager
- Erin Schaffer | Inhaltsentwickler 2
- Carol Smith | Senior Content Developer