Bearbeiten

Webanwendung in zwei Regionen mit Table Storage-Failover

Azure Front Door
Azure App Service
Azure-Funktionen
Azure Table Storage
Azure Cache for Redis

Lösungsmöglichkeiten

Dieser Artikel ist ein Lösungsvorschlag. Wenn Sie möchten, dass wir diesen Artikel um weitere Informationen ergänzen, z. B. potenzielle Anwendungsfälle, alternative Dienste, Überlegungen zur Implementierung oder Preisempfehlungen, lassen Sie es uns über Feedback auf GitHub wissen.

Diese Architektur bietet eine Hochverfügbarkeitslösung für eine Webanwendung, die große Datenmengen verwendet. Eine sekundäre Region dient als Standby für die primäre Region, wodurch die Verfügbarkeit verbessert wird. Die primäre Region sendet ihre Daten an die sekundäre Region und nutzt dazu die integrierten Replikationsfunktionen von Azure Storage.

Daten werden in Tabellen in Azure Table Storage gespeichert. Wie bei jedem Azure Storage-Dienst werden Table Storage-Daten synchron dreimal in der primären Region repliziert. Damit sie für den Standbymodus verfügbar sind, werden sie außerdem dreimal asynchron in die sekundäre Region repliziert. Informationen zur Azure Storage-Replikation finden Sie unter Azure Storage-Redundanz.

Die Architektur enthält einen Cache für die Tabellen, um die Zugriffslast zu reduzieren und die Anwendungsreaktion zu verbessern.

Hinweis

Unter bestimmten Umständen sind für Ihre Anwendung möglicherweise mehrere Speicherkonten erforderlich. Weitere Informationen finden Sie unter Überlegungen.

Mögliche Anwendungsfälle

Die Architektur kann für jede Anwendung geeignet sein, die große Datenmengen verwendet, die immer verfügbar sein müssen. Beispiele hierfür sind Apps, die für Folgendes verwendet werden:

  • Nachverfolgen des Ausgaben- und Einkaufsverhaltens von Kunden.
  • Wettervorhersage.
  • Anbieten oder Implementieren intelligenter Verkehrssysteme oder Verwenden von intelligenter Technologie zur Verkehrsüberwachung.
  • Analyse von Fertigungsdaten im Internet der Dinge (IoT).
  • Anzeigen von Daten intelligenter Verbrauchsmesser oder Verwenden intelligenter Technologie zum Überwachen von Verbrauchsdaten.

Architektur

Architektur eines robusten Systems, das ein Failover in eine Standbyregion ausführen kann.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Datenfluss

  1. Der Client authentifiziert sich bei Microsoft Entra ID und erhält Zugriff auf Webanwendungen, die in Azure App Service gehostet werden.
  2. Mithilfe von Azure Front Door, einer Firewall und einem Layer-7-Lastenausgleich wird der Benutzerdatenverkehr bei einem regionalen Ausfall auf die Standbyregion umgeschaltet.
  3. Azure App Service hostet Websites und Web-APIs mit REST-Unterstützung. AJAX-Anwendungen, die die APIs nutzen, werden in Browserclients ausgeführt.
  4. Funktions-Apps zur Verarbeitung von Hintergrundaufgaben werden von Web-APIs delegiert. Die Aufgaben sind in Azure Queue Storage Warteschlangen eingereiht.
  5. Die von Azure Functions gehosteten Funktions-Apps führen die Hintergrundaufgaben aus, die durch die Nachrichten in der Warteschlange ausgelöst werden.
  6. Tabellendaten für die Funktions-Apps sind in Azure Cache for Redis zwischengespeichert. Dadurch wird die Datenbankaktivität ausgelagert und eine schnellere Verarbeitung in den Funktions-Apps und Web-Apps erreicht.
  7. Azure Table Storage enthält die von den Webanwendungen verwendeten Daten.
  8. Table Storage unterstützt die synchrone Replikation von Daten über Verfügbarkeitszonen in der Region hinweg, um Ausfälle von Rechenzentren abzumildern. Ferner wird asynchrone Replikation zum Replizieren von Daten in verschiedene Azure-Regionen verwendet, um regionale Ausfälle zu entschärfen und die Anwendungsverfügbarkeit zu verbessern.

Komponenten

  • Microsoft Entra ID ist ein mehrmandantenfähiger Identitäts- und Zugriffsverwaltungsdienst, der mit einem lokalen Verzeichnis synchronisiert werden kann.
  • Azure DNS ist ein Hochverfügbarkeits-Hostingdienst für DNS-Domänen, der für Apps schnelle DNS-Abfragen und schnelle Updates von DNS-Einträgen bereitstellt. Die Verwaltung von Azure DNS ähnelt der Verwaltung anderer Azure-Dienste und verwendet die gleichen Anmeldeinformationen, APIs, Tools und Abrechnungsverfahren.
  • Azure Front Door ist ein sicheres Content Delivery Network (CDN) und ein Lastenausgleich mit sofortigem Failover. Es wird am Edge nahe an den Benutzern betrieben und beschleunigt die Inhaltsbereitstellung, während Apps, APIs und Websites vor Cyberbedrohungen geschützt werden.
  • Azure App Service ist ein vollständig verwalteter Dienst zum Erstellen, Bereitstellen und Skalieren von Web-Apps. Sie können Apps mit .NET, .NET Core, Node.js, Java, Python oder PHP erstellen. Die Apps können in Containern oder unter Windows oder Linux ausgeführt werden. Bei einer Mainframemigration können die Front-End-Bildschirme oder Weboberflächen als HTTP-basierte REST-APIs programmiert werden. Sie können getrennt werden und zustandslos sein, um ein auf Microservices basierendes System zu orchestrieren. Weitere Informationen zu Web-APIs finden Sie unter RESTful-Web-API-Design.
  • Azure Functions stellt eine Umgebung zum Ausführen kleiner Codeteile bereit, die als Funktionen bezeichnet werden, ohne dass eine Anwendungsinfrastruktur eingerichtet werden muss. Sie können damit Massendaten verarbeiten, Systeme integrieren, mit IoT arbeiten und einfache APIs und Microservices erstellen. Mit Microservices können Sie Server erstellen, die eine Verbindung mit Azure-Diensten herstellen und immer auf dem neuesten Stand sind.
  • Bei Azure Storage handelt es sich um eine Reihe hochgradig skalierbarer und sicherer Clouddienste für Daten, Apps und Workloads. Dazu gehören Azure Files, Azure Table Storage und Azure Queue Storage. Azure Files ist häufig ein effektives Tool für die Migration von Mainframeworkloads.
  • Azure Queue Storage stellt einfache, kostengünstige und stabile Nachrichtenwarteschlangen für große Workloads zur Verfügung.
  • Azure Table Storage ist ein NoSQL-Schlüssel-Wert-Speicher für die schnelle Entwicklung, der sehr umfangreiche halbstrukturierte Datasets verwendet. Die Tabellen sind schemalos und passen sich an geänderte Anforderungen an. Der Zugriff ist für viele Arten von Anwendungen schnell und kostengünstig und in der Regel preiswerter als andere Arten von schlüsselbasiertem Speicher.
  • Azure Cache for Redis ist ein vollständig verwalteter In-Memory-Cachedienst und Nachrichtenbroker für die gemeinsame Nutzung von Daten und Zuständen durch Computeressourcen. Er umfasst sowohl die Open-Source-Lösung Redis als auch ein kommerzielles Produkt von Redis Labs als verwaltete Dienste. Sie können die Leistung von Anwendungen zur Onlinetransaktionsverarbeitung mit hohem Durchsatz verbessern, indem Sie sie so gestalten, dass sie skalierbar sind und einen In-Memory-Datenspeicher wie Azure Cache for Redis nutzen.

Alternativen

  • Azure Traffic Manager leitet auf der Grundlage der von Ihnen gewählten Routingmethoden für Datenverkehr eingehende DNS-Anforderungen über die globalen Azure-Regionen hinweg weiter. Er bietet darüber hinaus automatisches Failover und Leistungsrouting.
  • Azure Content Delivery Network speichert statische Inhalte auf Edgeservern zwischen, um eine schnelle Reaktion zu ermöglichen, und verwendet Netzwerkoptimierungen, um die Reaktion für dynamische Inhalte zu beschleunigen. Content Delivery Network ist besonders bei einer globalen Benutzerbasis nützlich.
  • Azure Kubernetes Service (AKS) ist ein vollständig verwalteter Kubernetes-Dienst für die Bereitstellung und Verwaltung von containerisierten Anwendungen. Damit können Sie eine Microservicearchitektur implementieren, deren Komponenten bei Bedarf unabhängig voneinander skaliert werden.
  • Azure Container Instances bietet eine schnelle und einfache Möglichkeit zum Ausführen von Aufgaben, ohne die Infrastruktur verwalten zu müssen. Dies ist nützlich während der Entwicklung oder beim Ausführen ungeplanter Aufgaben.
  • Azure Service Bus ist ein zuverlässiger Cloudmessagingdienst für einfache Hybridintegrationen. Er kann in dieser Architektur anstelle von Queue Storage verwendet werden. Weitere Informationen finden sie unter Storage-Warteschlangen und Service Bus-Warteschlangen – Vergleich und Gegenüberstellung.

Überlegungen

  • Es bestehen Leistungsgrenzen für Table Storage, die durch Hinzufügen von Speicherkonten überwunden werden können. Die folgenden Umstände erfordern möglicherweise zusätzliche Konten:

    • Implementieren von Mehrinstanzenfähigkeit zum Unterstützen mehrerer Kunden
    • Unterstützen von Kunden mit höheren Transaktionsraten
    • Unterstützen von Kunden mit großen Datasets
    • Beschleunigen des Datenzugriffs durch Verteilen von Daten auf mehrere Speicherkonten
    • Aufteilen von Daten in heiße, kalte und Archivebenen
    • Erstellen von Kopien von Daten zu Sicherungs- und Berichterstellungszwecken

    Weitere Informationen finden Sie unter Skalierbarkeits- und Leistungsziele für Table Storage.

  • Table Storage-Replikation ist in einigen Azure-Regionen nicht verfügbar.

  • Die Daten in einer sekundären Region haben Eventualkonsistenz, was bedeutet, dass es eine Verzögerung zwischen dem Zeitpunkt, zu dem ein Update in einer primären Region erfolgt, und dem Zeitpunkt gibt, zu dem es in der sekundären Region sichtbar wird. Da die Replikation von der primären Region zur sekundären Region asynchron ist, können Daten verloren gehen, wenn die primäre Region ausfällt und nicht wiederhergestellt wird. Derzeit gibt es keine Vereinbarung zum Servicelevel (SLA) darüber, wie lange die Replikation von Daten zur sekundären Region dauert. Weitere Informationen finden Sie unter Azure Storage-Redundanz.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

  • Nabil Siddiqui | Cloud Solution Architect – Digitale und Anwendungsinnovationen

Nächste Schritte