Bearbeiten

Freigeben über


Unternehmenskritischer Basisplan mit App Service

Azure App Service
Azure Front Door
Azure Cache for Redis
Azure App Configuration
Azure Monitor

In diesem Artikel wird beschrieben, wie Sie unternehmenskritische Webanwendungen mithilfe von Azure App Service bereitstellen. Die Architektur verwendet das zuverlässige Web-App-Muster als Ausgangspunkt. Verwenden Sie diese Architektur, wenn Sie über eine ältere Workload verfügen und plattform as a Service (PaaS)-Dienste übernehmen möchten.

zuverlässiges Web-App-Muster für .NET enthält Anleitungen zum Aktualisieren oder Replatieren von Web-Apps, die Sie in die Cloud verschieben. Dieser Ansatz hilft Ihnen, die erforderlichen Codeänderungen zu minimieren und ein SLO -Ziel (Service Level Objective, SLO) von 99,9%. Unternehmenskritische Workloads weisen hohe Zuverlässigkeits- und Verfügbarkeitsanforderungen auf. Um ein SLO von 99,95%, 99,99%oder höher zu erreichen, müssen Sie zusätzliche missionskritische Entwurfsmuster und Betriebskraft anwenden. In diesem Artikel werden die wichtigsten technischen Bereiche und die Einführung und Implementierung von unternehmenskritischen Entwurfspraktiken beschrieben.

Anmerkung

Die Anleitung in diesem Artikel basiert auf der Designmethodik und den bewährten Methoden in der reihe Well-Architected Framework mission-critical workload.

In den folgenden Abschnitten wird beschrieben, wie:

  • Überprüfen Sie eine vorhandene Workload, um ihre Komponenten, Benutzer- und Systemflüsse sowie Verfügbarkeits- und Skalierbarkeitsanforderungen zu verstehen.
  • Entwickeln und implementieren Sie eine Skalierungseinheitsarchitektur, um die End-to-End-Skalierbarkeit durch Abteilung zu optimieren und den Prozess des Hinzufügens und Entfernens von Kapazität zu standardisieren.
  • Implementieren Sie zustandslose, kurzlebige Skalierungseinheiten oder Bereitstellungsstempel, um Skalierbarkeit und Bereitstellungsstempel ohne Ausfallzeiten zu ermöglichen.
  • Bestimmen Sie, ob Sie die Workload in Komponenten aufteilen können, um sich auf skalierbarkeit vorzubereiten. Einzelne Komponenten sind für Skalierbarkeit und Entkoppelung von Abläufen erforderlich.
  • Bereiten Sie sich auf globale Verteilung vor, indem Sie eine Workload in mehreren Azure-Regionen bereitstellen, um die Nähe zum Kunden zu verbessern und sich auf potenzielle regionale Ausfälle vorzubereiten.
  • Decouple-Komponenten und Implementieren einer ereignisgesteuerten Architektur.

Architektur

Im folgenden Diagramm werden die vorherigen Überlegungen auf das zuverlässige Web-App-Musterangewendet.

Ein Diagramm, das das zuverlässige Web-App-Muster mit angewendeter Skalierungseinheit zeigt. Laden Sie eine Visio-Datei dieser Architektur herunter.

Das rote Feld stellt eine Skalierungseinheit mit Diensten dar, die zusammen skaliert werden. Um sie effektiv zu skalieren, optimieren Sie die Größe, SKU und verfügbare IP-Adressen jedes Diensts. Die maximale Anzahl von Anforderungen, die azure App-Konfiguration bereitstellt, korreliert beispielsweise mit der Anzahl der Anforderungen pro Sekunde, die eine Skalierungseinheit bereitstellt. Wenn Sie einer Region mehr Kapazität hinzufügen, müssen Sie auch weitere einzelne Skalierungseinheiten hinzufügen.

Diese einzelnen Skalierungseinheiten haben keine Abhängigkeiten voneinander und kommunizieren nur mit gemeinsamen Diensten außerhalb der einzelnen Skalierungseinheit. Sie können diese Skalierungseinheiten in einer blaugrünen Bereitstellung verwenden, indem Sie neue Skalierungseinheiten einführen, überprüfen, dass sie ordnungsgemäß funktionieren und den Produktionsverkehr schrittweise auf sie verschieben.

In diesem Szenario betrachten wir Skalierungseinheiten als temporär, wodurch die Rolloutprozesse optimiert und Skalierbarkeit innerhalb und regionenübergreifend bereitgestellt wird. Wenn Sie diesen Ansatz anwenden, sollten Sie Daten nur in der Datenbank speichern, da die Datenbank in den sekundären Bereich repliziert wird. Wenn Sie Daten in der Skalierungseinheit speichern müssen, sollten Sie azure Cache für Redis für die Speicherung in der Skalierungseinheit verwenden. Wenn eine Skalierungseinheit abgebrochen werden muss, kann die Aktualisierung des Caches die Latenz erhöhen, führt aber nicht zu Ausfällen.

Application Insights wird von der Skalierungseinheit ausgeschlossen. Schließen Sie Dienste aus, die Daten speichern oder überwachen. Trennen Sie sie in ihre eigene Ressourcengruppe mit ihrem eigenen Lebenszyklus.

Wenn Sie eine Skalierungseinheit ersetzen oder eine neue bereitstellen, behalten Sie historische Daten bei, und verwenden Sie eine Instanz für jede Region.

Weitere Informationen finden Sie unter Anwendungsdesign von unternehmenskritischen Workloads in Azure.

Komponenten

Diese Architektur verwendet die folgenden Komponenten.

Alternativen

Im zuverlässigen Web-App-Muster können Sie:

  • Azure Kubernetes Service (AKS) anstelle von App Service verwenden. Diese Option eignet sich gut für komplexe Workloads mit einer großen Anzahl von Microservices. AKS bietet mehr Kontrolle über die zugrunde liegende Infrastruktur und ermöglicht komplexe Multitier-Setups.
  • Containerisieren Sie die Workload. Der App-Dienst unterstützt containerisierung, in diesem Beispiel wird die Workload jedoch nicht containerisiert. Verwenden Sie Container, um Zuverlässigkeit und Portabilität zu erhöhen.

Weitere Informationen finden Sie unter Überlegungen zur Anwendungsplattform für unternehmenskritische Workloads in Azure.

Überlegungen zur hohen Verfügbarkeit

Unabhängig von der von Ihnen gewählten Anwendungsplattform empfehlen wir, die Verwendung von Verfügbarkeitszonen für Produktionsworkloads zu priorisieren.

Verfügbarkeitsgruppen Bereitstellungen über mehrere Fehler- und Updatedomänen innerhalb eines Rechenzentrums verteilt. Verfügbarkeitszonen Bereitstellungen in einzelnen Rechenzentren innerhalb einer Azure-Region verteilen. Verfügbarkeitszonen werden häufig priorisiert, aber welche Strategie Sie verwenden, hängt von Ihrer Arbeitsauslastung ab. Beispielsweise können Latenzsensible oder Chatty-Workloads von der Priorisierung von Verfügbarkeitssätzen profitieren. Wenn Sie die Workload über Verfügbarkeitszonen verteilen, kann die Latenz und die Kosten für den zonenübergreifenden Datenverkehr erhöht werden. Wenn Sie Verfügbarkeitszonen verwenden, stellen Sie sicher, dass alle Dienste in einer Skalierungseinheit diese unterstützen. Alle Dienste in den zuverlässigen Web-App-Mustern unterstützen Verfügbarkeitszonen.

Auswählen der Datenplattform

Die von Ihnen ausgewählte Datenbankplattform wirkt sich auf die allgemeine Workloadarchitektur aus, insbesondere die Unterstützung der aktiven oder passiven Konfiguration der Plattform. Das zuverlässige Web-App-Muster verwendet Azure SQL, das aktiv-aktive Bereitstellungen nicht nativ unterstützt, die Schreibvorgänge in mehr als einer Instanz aufweisen. In dieser Konfiguration ist die Datenplattform auf eine aktiv-passive Strategie beschränkt. Eine (partielle) aktive Strategie auf Anwendungsebene ist möglich, wenn in allen Regionen schreibgeschützte Replikate vorhanden sind und Sie nur in eine einzelne Region schreiben.

Ein Diagramm, das die Architektur mit azure SQL-Datenbank zeigt, die in den einzelnen Regionen repliziert wurde.

Mehrere Datenbanken sind in komplexen Architekturen üblich, z. B. Microservices-Architekturen, die über eine Datenbank für jeden Dienst verfügen. Mehrere Datenbanken ermöglichen die Einführung einer mehrfach primären Schreibdatenbank wie Azure Cosmos DB, wodurch hohe Verfügbarkeit und niedrige Latenz verbessert werden. Die regionsübergreifende Latenz kann Einschränkungen schaffen. Es ist von entscheidender Bedeutung, nicht funktionsfreie Anforderungen und Faktoren wie Konsistenz, Operierbarkeit, Kosten und Komplexität zu berücksichtigen. Ermöglichen Sie einzelnen Diensten, separate Datenspeicher und spezielle Datentechnologien zu verwenden, um ihre individuellen Anforderungen zu erfüllen. Weitere Informationen finden Sie unter Überlegungen zur Datenplattform für unternehmenskritische Workloads in Azure.

Definieren eines Integritätsmodells

In komplexen mehrstufigen Workloads, die sich auf mehrere Rechenzentren und geografische Regionen verteilen, müssen Sie ein Integritätsmodell definieren.

So definieren Sie ein Integritätsmodell:

  • Definieren von Benutzer- und Systemflüssen
  • Angeben und Verstehen der Abhängigkeiten zwischen den Diensten
  • Verstehen der Auswirkung, dass Ausfälle oder Leistungsbeeinträchtigungen auf einem der Dienste auf die gesamtlasten Auswirkungen haben können
  • Überwachen und visualisieren Sie die Kundenerfahrung, um eine ordnungsgemäße Überwachung zu ermöglichen und manuelle und automatisierte Aktionen zu verbessern.

Ein Diagramm, das zeigt, wie ein Ausfall einer App-Konfiguration Ausfälle für andere Dienste erstellt.

Das vorherige Diagramm zeigt, wie ein Ausfall oder eine Beeinträchtigung einer einzelnen Komponente, z. B. app-Konfiguration, eine potenzielle Leistungsbeeinträchtigung für den Kunden verursachen kann. Wenn Sie Komponenten in Skalierungseinheiten trennen, können Sie das Senden des Datenverkehrs an den betroffenen Teil der Anwendung beenden, z. B. eine betroffene Skalierungseinheit oder die gesamte Region.

Die Kriterien für die Bestimmung der Integrität einer Skalierungseinheit werden im Integritätsmodell definiert. Dieses Modell wird dann mit dem Integritätsendpunkt der Skalierungseinheit verbunden, wodurch der globale Lastenausgleich den Integritätsstatus einer Skalierungseinheit abfragen und diese Informationen für Routingentscheidungen verwenden kann.

Weitere Informationen finden Sie unter Health Modeling and observability of mission-critical workloads on Azure.

Sicherheit und Netzwerk

Unternehmenskritische Workloads weisen strenge Netzwerk- und Sicherheitsanforderungen auf. Wenden Sie die Sorgfalt insbesondere auf Workloads an, die aus einer lokalen Umgebung migriert wurden, da nicht alle etablierten lokalen Sicherheitspraktiken in eine Cloudumgebung übersetzt werden. Es wird empfohlen, die Sicherheitsanforderungen während der Anwendungsmigration neu zu bewerten.

Die Identität ist häufig der primäre Sicherheitsperimeter für cloudeigene Muster. Unternehmenskunden benötigen möglicherweise umfangreichere Sicherheitsmaßnahmen. Um ihre Netzwerksicherheitsanforderungen zu erfüllen, können Azure PaaS-Dienste Azure Private Link verwenden, um das Netzwerk als Sicherheitsperimeter zu implementieren. Mit privatem Link können Sie sicherstellen, dass nur über ein virtuelles Netzwerk auf Dienste zugegriffen werden kann. Auf alle Dienste kann dann nur über private Endpunkte zugegriffen werden. Das folgende Diagramm zeigt, wie der einzige öffentliche internetorientierte Endpunkt Azure Front Door ist.

Ein Diagramm, das die internetgerichteten Endpunkte in dieser Architektur zeigt.

Damit das zuverlässige Web-App-Muster ein Netzwerk als Sicherheitsperimeter einrichten kann, muss folgendes verwendet werden:

  • Privater Link für alle Dienste, die sie unterstützen.
  • Azure Front Door Premium als einziger öffentlicher Endpunkt mit Internetzugriff.
  • Sprungfelder für den Zugriff auf Dienste über Azure Bastion.
  • Selbst gehostete Build-Agents, die auf die Dienste zugreifen können.

Eine weitere häufige Netzwerkanforderung für unternehmenskritische Anwendungen besteht darin, den Datenverkehr einzuschränken, um Datenexfiltration zu verhindern. Beschränken Sie den Ausgehenden Datenverkehr, indem Sie eine Azure-Firewall über ein geeignetes Firewallgerät weiterleiten. Filtern Sie dann den Datenverkehr mithilfe des Geräts. Die unternehmenskritische Azure-Basisarchitektur mit Netzwerksteuerelementen verwendet eine Firewall und einen privaten Link.

Bereitstellung und Tests

Ausfallzeiten, die durch fehlerhafte Freigaben oder menschliche Fehler verursacht werden, können ein Problem für eine Workload sein, die immer verfügbar sein muss. Hier sind einige wichtige Bereiche, die Sie berücksichtigen sollten:

  • Bereitstellungen ohne Ausfallzeiten
  • Ephemerale blaugrüne Bereitstellungen
  • Lebenszyklusanalyse einzelner und gruppierter Komponenten
  • Kontinuierliche Überprüfung

Bereitstellungen ohne Ausfallzeiten für unternehmenskritische Workloads von entscheidender Bedeutung sind. Eine Workload, die immer ausgeführt werden muss, kann kein Wartungsfenster zum Bereitstellen neuerer Versionen haben. Um diese Einschränkung zu umgehen, folgt die unternehmenskritische Azure-Architektur dem Muster für Bereitstellungen ohne Ausfallzeiten. Änderungen werden als neue Skalierungseinheiten oder Stempel eingeführt, die end to enden, bevor der Datenverkehr inkrementell an sie weitergeleitet wird. Nachdem der gesamte Datenverkehr an den neuen Stempel weitergeleitet wurde, werden die alten Stempel deaktiviert und entfernt.

Weitere Informationen finden Sie unter Bereitstellung und Tests für unternehmenskritische Workloads in Azure.

Nächste Schritte