Geodenmuster

Stellen Sie eine Sammlung von Back-End-Diensten für eine Gruppe von geografischen Knoten bereit, von denen jeweils die Clientanforderungen einer beliebigen Region verarbeitet werden können. Dieser Active-Active-Ansatz verteilt die Anfragenverarbeitung auf der ganzen Welt, um die Latenz zu verringern und die Verfügbarkeit zu erhöhen.

Acht Geoden werden auf einer Weltkarte verteilt: zwei in Nordamerika, zwei in Asien und jeweils eins in Südamerika, Europa, dem südlichen Afrika und Australien. Die Legende unterscheidet Geodes von Rechenzentren, dargestellt als blaue Punkte, und Edge-Standorte, die als orangefarbene Punkte angezeigt werden. Gepunktete Netzwerkleitungen verbinden Standorte über Kontinente und Ozeane hinweg und bilden ein globales Netzwerk um die Geoden.

Kontext und Problem

Viele groß angelegte Dienste stehen bei geografischer Verfügbarkeit und Skalierung vor Herausforderungen. Klassische Designs bringen die Daten häufig zur Computeressource, indem Daten auf einem Remote-SQL-Server gespeichert werden, der auch die Daten verarbeitet. Sie verlassen sich auf die Skalierung, um wachstum zu bewältigen.

Der klassische Ansatz kann die folgenden Probleme verursachen:

• Benutzer in entfernten Regionen können, wenn sie eine Verbindung mit dem Hostingendpunkt herstellen, von Netzwerklatenz betroffen sein.
• Nachfragespitzen können Dienste in einer einzelnen Region überwältigen.
• Die Bereitstellung von Kopien der Anwendungsinfrastruktur in mehreren Regionen für einen Dienst rund um die Uhr kann die Komplexität erhöhen und die Kosten steigern.

Cloudinfrastruktur unterstützt globales Routing und geografische Datenreplikation. Um die Latenz für eine geografisch verteilte Benutzerbasis zu verringern, können Sie die Computeressourcen bei den regionalen Datenreplikaten platzieren, die sie verarbeiten. Beim Geode-Muster wird die Rechenleistung zu den Daten gebracht.

Lösung

Stellen Sie den Dienst an mehreren geografischen Standorten bereit. Jede Bereitstellung wird als Geode bezeichnet. Verwenden Sie einen globalen Routingdienst, um Anfragen gemäß Routingrichtlinien und Zustandsprüfungen zu verteilen. Jeder Geode greift auf einen geo-replizierten Datenspeicher zu.

Konfigurieren Sie die Datenebene so, dass jeder Geoknoten dieselben Anwendungsvorgänge innerhalb der eventuellen Konsistenzanforderungen der Workload bedienen kann. Geoknoten können unterschiedliche Versionen eines Elements überwachen, während die Replikation ausgeführt wird. Die Anwendung muss Replikationsverzögerungen und gleichzeitige Schreibvorgänge berücksichtigen, insbesondere, wenn Anfragen zwischen Geoknoten verschoben werden.

Beispielsweise kann ein Azure Cosmos DB for NoSQL-Konto, das mit mehreren Schreibregionen konfiguriert ist, Lese- und Schreibvorgänge in der Region der einzelnen Geoknoten bereitstellen. Azure Cosmos DB Multi-Region-Schreibvorgänge replizieren Daten asynchron.

In einer Architektur mit Bereitstellungsstempel dient jeder Stempel einer zugewiesenen Teilmenge von Benutzern oder Mandanten. In einer Geode-Architektur kann jede Geode dieselben Anwendungsoperationen für jeden Benutzer ausführen und auf die für diese Vorgänge benötigten Daten zugreifen. Beide Muster verwenden mehrere Bereitstellungen; wählen Sie zwischen ihnen basierend auf der Eignung der Anfrage und der Datenplatzierung aus.

Jede Geode enthält eine Einstiegskomponente, die auf einen Stapel von Verarbeitungskomponenten verweist. Pfeile verbinden den Verarbeitungsstapel mit drei unterstützenden Komponenten und einer Datenbank. Die Verbindungen zwischen der Verarbeitung und der Datenbank sind bidirektional in Geodes B, C und D und zeigen auf die Datenbank in Geode A. Eine dicke graue Replikations-Backplane verläuft am unteren Rand, mit Pfeilen nach oben zu jeder Datenbank und einem Rückpfeil von Geode A. Kettensymbole markieren Geodes A und B als Paar und Geodes C und D als gekoppelt.

Geoden verfügen über die folgenden Merkmale:

• Jede Geode besteht aus einer Sammlung von Ressourcentypen, die häufig in einer Bereitstellungsvorlage definiert sind.
• Jede Geode enthält die regionalen Ressourcen, die für die Bearbeitung von Anfragen erforderlich sind, ohne von der Anwendungsebene einer anderen Geode abhängig zu sein. Gemeinsames Routing und Datendienste können weiterhin in der Architektur vorhanden sein.
• Geoden werden lose über globales Routing und eine Replikations-Backplane gekoppelt. Die Routingebene leitet Anfragen an verfügbare Geoden weiter, und die Datenebene repliziert Aktualisierungen zwischen diesen. Die Anwendung benötigt weiterhin ein geeignetes Konsistenzmodell und eine Konfliktbehandlungsstrategie.

Das Geoknoten-Muster wird in Big Data-Architekturen genutzt, für die Standardhardware zum Verarbeiten der Daten verwendet wird, die sich auf demselben Computer befinden. MapReduce wird genutzt, um die Ergebnisse übergreifend für die Computer zusammenzufassen. Eine weitere Verwendung ist Near-Edge-Computing, was die Rechenleistung näher an den Netzwerkrand bringt, um die Reaktionszeit zu reduzieren.

Wählen Sie die Anzahl und Platzierung von Geoknoten entsprechend den regionalen Ausfällen aus, die Ihre Workload tolerieren muss. Die Verfügbarkeit hängt von funktionsfähigen gemeinsam genutzten Abhängigkeiten und ausreichender Compute- und Datenbankkapazität in den überlebenden Geoden ab, um umgeleiteten Datenverkehr zu verarbeiten.

Probleme und Überlegungen

Verwenden Sie die folgenden Verfahren und Technologien, um dieses Muster zu implementieren:

• Verwenden Sie DevOps-Methoden und -Tools, um identische Geoknoten über Regionen oder Instanzen hinweg zu erstellen und bereitzustellen.
• Nutzen Sie automatische Skalierung, um Computeressourcen und Datenbankdurchsatz innerhalb der einzelnen Geoknoten zu skalieren, vorbehaltlich freigegebener Backplane-Einschränkungen.
• Für eine HTTP-API-Implementierung bietet Azure Front Door Datenverkehrsbeschleunigung über das Edgenetzwerk und geteilte TCP-Verbindungen.
• Verwenden Sie einen geo-replizierten Datenspeicher, um die Datenkonsistenz sicherzustellen. Konfigurieren Sie für das Multi-Region-Schreiben-Beispiel von Cosmos DB das regionale Routing des SDK so, dass jede Geode aus ihrer lokalen Datenbankregion liest und in sie schreibt und konfigurierte Fallbackregionen verwenden kann.
• Erwägen Sie nutzungsbasiertes Computing, um die Kapazitätskosten im Leerlauf zu reduzieren, wenn sich die Lasten zwischen Geoknoten ändern. Bei dieser Strategie könnten viele Geoknoten mit geringem zusätzlichen Investitionsaufwand bereitgestellt werden. Einsparungen hängen von der Arbeitsauslastung und dem Hostingplan ab.
• Azure API Management ist optional. Platzieren Sie sie vor der Funktions-App des einzelnen Geoknotens, wenn Sie API-Verwaltungsfunktionen benötigen, wie z. B. die Ratenbegrenzung.

Beachten Sie die folgenden Punkte bei der Entscheidung, wie dieses Muster implementiert werden soll:

• Wählen Sie eine Konsistenzstufe aus, die Ihre Leseanforderungen erfüllt, wenn Anfragen zwischen Geoden verschoben werden.

  Geben Sie bei Azure Cosmos DB-Sitzungskonsistenz das Sitzungstoken an den Client zurück, und sorgen Sie dafür, dass der Client es bei nachfolgenden Leseanforderungen mitsendet, sodass die Garantie für das Lesen der eigenen Schreibvorgänge beim Routing an einen anderen Geoknoten erhalten bleibt. In Mehrregionen-Schreibkonten verwenden Sie diese freigegebenen Token nur für Leseanforderungen.

  Wählen Sie eine Konfliktlösungsrichtlinie für gleichzeitige Schreibvorgänge aus.

• Definieren Sie die Ausfallmodi, die die Workload tolerieren muss, einschließlich regionaler Ausfälle und gemeinsam genutzter Abhängigkeitsfehler. Dimensionieren Sie die Geoknoten für umgeleitete Spitzenlasten.

• Testen Sie regionales Failover und die Wiederherstellung unter repräsentativer Last in einer kontrollierten Umgebung. Gemeinsame Abhängigkeitsfehler und Failback einschließen.

• Wählen Sie aus, ob Daten lokal in jeder Region verarbeitet oder Aggregationen in einer Geode berechnet und die Ergebnisse global repliziert werden sollen. Der Azure Cosmos DB Change Feed Processor bietet diese feingranulare Steuerung mithilfe seines Konzepts des Leasecontainers und LeaseContainerPrefix ebenso in der entsprechenden Azure Functions-Bindung. Jeder Ansatz ist mit anderen Vor- und Nachteilen verbunden.

• Geodes können mithilfe des Azure Cosmos DB Änderungsfeeds und einer Echtzeitkommunikationsplattform wie SignalR zusammenarbeiten. Sie können mit Remotebenutzern über andere Geoden in einem Gittermuster kommunizieren, ohne die Standorte dieser Benutzer zu kennen oder berücksichtigen zu müssen.

• Verfolgen Sie Komponenten derselben Anfrage nach, wie sie asynchron auf verschiedenen Instanzen oder geodes ausgeführt werden. Überwachen Sie freigegebene Abhängigkeiten sowie regionale Ressourcen, damit Sie zusammenhängende Ausfälle identifizieren können. Sowohl Azure Front Door als auch Azure Cosmos DB können in Log Analytics integriert werden, und Azure Functions können Application Insights für die Anwendungsüberwachung verwenden.

• Schützen Sie die Eingangspunkte auf jeder Ebene der verteilten Bereitstellung.

  • Beschränken Sie Azure Cosmos DB Zugriff auf die Funktions-Apps.
  • Konfigurieren Sie bei den Ursprüngen öffentlicher Funktionen hinter Azure Front Door Zugriffsbeschränkungen, die das AzureFrontDoor.Backend-Diensttag und einen X-Azure-FDID-Headerfilter kombinieren, der Ihrer Front Door-Profil-ID in derselben Zulassungsregel entspricht. Lehnen Sie nicht übereinstimmende Anfragen ab.

  Trennen Sie die API-Aufruferauthentifizierung von diesen Ursprungszugriffssteuerelementen.

• Stellen Sie sicher, dass jeder Geoknoten von Key Vault aus auf die Geheimnisse zugreifen kann, die er benötigt, und koordinieren Sie die Bereitstellung und Rotation für freigegebene Geheimnisse.

• Die Leistung hängt von der Anzahl der Geoden und dem Computehostingmodell ab, das für die API der einzelnen Geode verwendet wird. Sie müssen die Kostendifferenz zwischen dem Hinzufügen von Geoden und der Erhöhung der Kapazität der einzelnen Geode auswerten.

• Verwenden Sie zonenredundante Ressourcen, sofern unterstützt, um die Auswirkungen von Ausfällen von Verfügbarkeitszonen innerhalb der Region der einzelnen Geoknoten zu verringern. Wählen Sie Regionen basierend auf Latenz, Datenresidenz, Dienstverfügbarkeit und Wiederherstellungsanforderungen aus.

• Verwenden Sie die Entscheidungsstruktur für den Lastenausgleich, um ein Front-End für Ihre API auszuwählen.

• Konfigurieren Sie bei Front Door die Auswahl des Ursprungs so, dass sie dem Active-Active-Design entspricht. Weisen Sie gleichzeitig aktive Geodes die gleiche Priorität zu, und konfigurieren Sie dann Latenzempfindlichkeit und Gewichtungen.

Wann dieses Muster verwenden

Verwenden Sie dieses Muster in folgenden Szenarien:

• Sie benötigen eine hochskalierbare Plattform für Benutzer, die über eine breite geografische Region verteilt sind.
• Ihr Workload muss während der in Ihrem Fehlermodell enthaltenen regionalen Ausfälle weiterhin kritische Anfragen verarbeiten.

Dieses Muster ist in den folgenden Szenarien möglicherweise nicht geeignet:

• Ihre Architektur schränkt Daten oder Benutzer auf bestimmte Bereitstellungen ein, um z. B. regionale Anforderungen an die Datenresidenz zu erfüllen. Erwägen Sie Bereitstellungsstempel mit datenbasiertem Routing, wenn nur einige Bereitstellungen einen bestimmten Benutzer unterstützen können.
• Ihre Workload kann ihre Anforderungen in einer einzelnen Region erfüllen. Erwägen Sie zonenredundante Bereitstellungen, bei denen diese unterstützt werden, und bewerten Sie die regionale Notfallwiederherstellung separat.
• Der Sitzungszustand oder die Datenabhängigkeiten Ihrer Anwendung binden Anforderungen an eine Region. Vorhandene Anwendungen benötigen möglicherweise Änderungen an der Zustandsverwaltung, Datenreplikation und Bereitstellungsautomatisierung, bevor ihre regionalen Bereitstellungen dieselben Abläufe unterstützen können.
• Ihre Verfügbarkeits- und Latenzanforderungen rechtfertigen nicht die Geoverteilung, z. B. wenn sich die meisten Benutzer und Daten in einer Region befinden.

Arbeitslastgestaltung

Ein Architekt sollte evaluieren, wie das Geode-Muster im Design seiner Workloads verwendet werden kann, um die Ziele und Prinzipien zu erreichen, die in den Azure Well-Architected Framework-Säulen behandelt werden. Beispiele:

Säule	So unterstützt dieses Muster die Säulenziele
Zuverlässigkeitsdesignentscheidungen tragen dazu bei, dass Ihre Workload ausfallsicher wird und dass sie nach einem Ausfall wieder in einen voll funktionsfähigen Zustand zurückkehrt.	Regionale Bereitstellungen und Datenreplikation können Ihrem Workload helfen, einen oder mehrere regionale Ausfälle zu tolerieren. - RE:05 Redundanz - Regionen und Verfügbarkeitszonen
Performance Efficiency hilft Ihrem Workload durch Optimierungen bei Skalierung, Daten und Code, die Anforderungen effizient zu erfüllen .	Die lokale Verarbeitung und der Datenzugriff können die Anforderungslatenz für eine verteilte Benutzerbasis reduzieren. Dadurch wird die Latenz reduziert, da der Datenverkehr über weite Strecken entfällt und die Infrastruktur nur von Benutzern gemeinsam genutzt wird, die derzeit denselben Geoknoten verwenden. - PE:03 Dienste auswählen

Berücksichtigen Sie wie bei jeder Designentscheidung alle Kompromisse im Hinblick auf die Ziele der anderen Säulen, die mit diesem Muster eingeführt werden könnten.

Examples

• Active Directory Domain Services (AD DS) in Windows Server veranschaulicht eine partielle Variante dieses Musters. Schreibbare Domänencontroller verwenden die Multimasterreplikation für die Verzeichnispartitionen, die sie hosten. Für bestimmte Vorgänge ist ein festgelegter Flexible Single Master Operations (FSMO)-Rolleninhaber erforderlich, sodass Domänencontroller nicht für jeden Vorgang austauschbar sind.

• Die folgenden Azure-Dienste veranschaulichen die geografische Austauschbarkeit von Anforderungen:

  • Azure Cosmos DB für NoSQL: Bei aktivierten Mehrregionenschreibvorgängen enthält jede konfigurierte Region alle Datenpartitionen eines Containers und kann Lese- und Schreibvorgänge bereitstellen. Diese regionalen Datenbereitstellungen veranschaulichen die Geoknoten für dieses Konto.
  • Azure Managed Redis: Bei aktiver Georeplikation kann jede verknüpfte regionale Instanz Lese- und Schreibvorgänge für denselben logischen Cache akzeptieren.
  • Azure Front Door: Jeder Point of Presence von Front Door kann jede Anforderung bedienen. Diese Edge-Standorte veranschaulichen geografisch austauschbare HTTP-Anforderungshandler.

Nächster Schritt

Überprüfen Sie die AKS-Baseline für Multiregion-Cluster mit entsprechenden Hinweisen zu aktiv-aktiver regionaler Computebereitstellung und globalem Routing.