Share via

Überlegungen zur Anwendungsplattform für unternehmenskritische Workloads in Azure

  • Artikel

Azure bietet viele Computedienste zum Hosten von hochverfügbaren Anwendungen. Die Dienste unterscheiden sich in ihrer Funktionalität und Komplexität. Es wird empfohlen, dienste basierend auf Folgenden auszuwählen:

  • Nicht funktionale Anforderungen an Zuverlässigkeit, Verfügbarkeit, Leistung und Sicherheit.
  • Entscheidungsfaktoren wie Skalierbarkeit, Kosten, Bedienbarkeit und Komplexität.

Die Wahl einer Anwendungshostingplattform ist eine wichtige Entscheidung, die sich auf alle anderen Entwurfsbereiche auswirkt. Ältere oder proprietäre Entwicklungssoftware kann beispielsweise nicht in PaaS-Diensten oder Containeranwendungen ausgeführt werden. Diese Einschränkung würde Ihre Wahl der Computeplattform beeinflussen.

Eine unternehmenskritische Anwendung kann mehr als einen Computedienst verwenden, um mehrere zusammengesetzte Workloads und Microservices mit jeweils unterschiedlichen Anforderungen zu unterstützen.

Dieser Entwurfsbereich enthält Empfehlungen im Zusammenhang mit Computeauswahl, Entwurf und Konfigurationsoptionen. Außerdem wird empfohlen, sich mit der Entscheidungsstruktur compute vertraut zu machen.

Wichtig

Dieser Artikel ist Teil der unternehmenskritischen Workloadreihe von Azure Well-Architected Framework . Wenn Sie mit dieser Reihe nicht vertraut sind, empfehlen wir Ihnen, mit Was ist eine unternehmenskritische Workload zu beginnen?

Globale Verteilung von Plattformressourcen

Ein typisches Muster für eine unternehmenskritische Workload umfasst globale Ressourcen und regionale Ressourcen.

Azure-Dienste, die nicht auf eine bestimmte Azure-Region beschränkt sind, werden als globale Ressourcen bereitgestellt oder konfiguriert. Einige Anwendungsfälle umfassen das Verteilen von Datenverkehr über mehrere Regionen, das Speichern des permanenten Zustands für eine ganze Anwendung und das Zwischenspeichern globaler statischer Daten. Wenn Sie sowohl eine Architektur mit Skalierungseinheiten als auch eine globale Verteilung berücksichtigen müssen, sollten Sie überlegen, wie Ressourcen optimal über Azure-Regionen verteilt oder repliziert werden.

Andere Ressourcen werden regional bereitgestellt. Diese Ressourcen, die als Teil eines Bereitstellungsstempels bereitgestellt werden, entsprechen in der Regel einer Skalierungseinheit. Eine Region kann jedoch mehr als einen Stempel haben, und ein Stempel kann mehr als eine Einheit aufweisen. Die Zuverlässigkeit regionaler Ressourcen ist von entscheidender Bedeutung, da sie für die Ausführung der Standard Workload verantwortlich sind.

Die folgende Abbildung zeigt den allgemeinen Entwurf. Ein Benutzer greift über einen zentralen globalen Einstiegspunkt auf die Anwendung zu, der Anforderungen dann an einen geeigneten regionalen Bereitstellungsstempel umleitet:

Diagramm, das eine unternehmenskritische Architektur zeigt.

Die unternehmenskritische Entwurfsmethodik erfordert eine Bereitstellung in mehreren Regionen. Dieses Modell stellt die regionale Fehlertoleranz sicher, sodass die Anwendung auch dann verfügbar bleibt, wenn eine ganze Region ausfällt. Wenn Sie eine Anwendung mit mehreren Regionen entwerfen, sollten Sie verschiedene Bereitstellungsstrategien wie Aktiv/Aktiv und Aktiv/Passiv zusammen mit den Anwendungsanforderungen in Betracht ziehen, da bei jedem Ansatz erhebliche Nachteile bestehen. Für unternehmenskritische Workloads wird dringend das Aktiv/Aktiv-Modell empfohlen.

Nicht jede Workload unterstützt oder erfordert die gleichzeitige Ausführung mehrerer Regionen. Sie sollten bestimmte Anwendungsanforderungen gegen Kompromisse abwägen, um eine optimale Entwurfsentscheidung zu bestimmen. Für bestimmte Anwendungsszenarien mit niedrigeren Zuverlässigkeitszielen kann aktiv/passiv oder Sharding geeignete Alternativen sein.

Verfügbarkeitszonen können hochverfügbare regionale Bereitstellungen in verschiedenen Rechenzentren innerhalb einer Region bereitstellen. Fast alle Azure-Dienste sind entweder in einer zonenalen Konfiguration verfügbar, in der der Dienst an eine bestimmte Zone delegiert wird, oder in einer zonenredundanten Konfiguration, bei der die Plattform automatisch sicherstellt, dass der Dienst zonenübergreifend ist und einem Zonenausfall standhalten kann. Diese Konfigurationen bieten Fehlertoleranz bis zur Rechenzentrumsebene.

Überlegungen zum Entwurf

  • Regionale und zonale Fähigkeiten. Nicht alle Dienste und Funktionen sind in jeder Azure-Region verfügbar. Diese Überlegung kann sich auf die von Ihnen ausgewählten Regionen auswirken. Außerdem sind Verfügbarkeitszonen nicht in jeder Region verfügbar.

  • Regionale Paare. Azure-Regionen werden in regionsbezogene Paare gruppiert, die aus zwei Regionen in einer einzelnen Geografie bestehen. Einige Azure-Dienste verwenden regionspaare, um geschäftskontinuität sicherzustellen und ein Maß an Schutz vor Datenverlust zu bieten. Beispielsweise repliziert Azure Georedundanter Speicher (GRS) Daten automatisch in eine sekundäre gekoppelte Region, um sicherzustellen, dass die Daten dauerhaft sind, wenn die primäre Region nicht wiederhergestellt werden kann. Wenn ein Ausfall mehrere Azure-Regionen betrifft, wird mindestens eine Region in jedem Paar für die Wiederherstellung priorisiert.

  • Datenkonsistenz. Erwägen Sie bei Konsistenzproblemen die Verwendung eines global verteilten Datenspeichers, einer gestempelten regionalen Architektur und einer teilweise aktiven/aktiven Bereitstellung. Bei einer Teilbereitstellung sind einige Komponenten in allen Regionen aktiv, während andere sich zentral innerhalb der primären Region befinden.

  • Sichere Bereitstellung. Das SDP-Framework (Azure Safe Deployment Practice) stellt sicher, dass alle Code- und Konfigurationsänderungen (geplante Wartung) für die Azure-Plattform einem stufenweisen Rollout unterzogen werden. Die Integrität wird während der Freigabe auf Beeinträchtigungen analysiert. Nach erfolgreichem Abschluss der Canary- und Pilotphasen werden Plattformupdates über regionsübergreifende Paare serialisiert, sodass nur eine Region in jedem Paar zu einem bestimmten Zeitpunkt aktualisiert wird.

  • Plattformkapazität. Wie jeder Cloudanbieter verfügt Auch Azure über endliche Ressourcen. Die Nichtverfügbarkeit kann das Ergebnis von Kapazitätseinschränkungen in Regionen sein. Wenn es zu einem regionalen Ausfall kommt, steigt die Nachfrage nach Ressourcen, wenn die Workload versucht, innerhalb der gekoppelten Region wiederherzustellen. Der Ausfall kann zu einem Kapazitätsproblem führen, bei dem das Angebot vorübergehend nicht der Nachfrage entspricht.

Entwurfsempfehlungen

  • Stellen Sie Ihre Lösung in mindestens zwei Azure-Regionen bereit, um sich vor regionalen Ausfällen zu schützen. Stellen Sie sie in Regionen bereit, die über die Funktionen und Merkmale verfügen, die für die Workload erforderlich sind. Die Funktionen sollten Leistungs- und Verfügbarkeitsziele erfüllen und gleichzeitig die Anforderungen an die Datenresidenz und -aufbewahrung erfüllen.

    Beispielsweise können einige Datenkonformitätsanforderungen die Anzahl der verfügbaren Regionen einschränken und möglicherweise Entwurfskompromittierungen erzwingen. In solchen Fällen wird dringend empfohlen, zusätzliche Investitionen in betriebsbereite Wrapper hinzuzufügen, um Fehler vorherzusagen, zu erkennen und darauf zu reagieren. Angenommen, Sie sind auf eine Geografie mit zwei Regionen beschränkt, und nur eine dieser Regionen unterstützt Verfügbarkeitszonen (3 + 1 Rechenzentrumsmodell). Erstellen Sie ein sekundäres Bereitstellungsmuster mithilfe der Fehlerdomänenisolation, damit beide Regionen in einer aktiven Konfiguration bereitgestellt werden können, und stellen Sie sicher, dass die primäre Region mehrere Bereitstellungsstempel enthält.

    Wenn die geeigneten Azure-Regionen nicht alle Funktionen bieten, die Sie benötigen, sollten Sie darauf vorbereitet sein, die Konsistenz regionaler Bereitstellungsstempel zu gefährden, um die geografische Verteilung zu priorisieren und die Zuverlässigkeit zu maximieren. Wenn nur eine einzelne Azure-Region geeignet ist, stellen Sie mehrere Bereitstellungsstempel (regionale Skalierungseinheiten) in der ausgewählten Region bereit, um einige Risiken zu minimieren, und verwenden Sie Verfügbarkeitszonen, um Fehlertoleranz auf Rechenzentrumsebene bereitzustellen. Eine solche erhebliche Kompromittierung bei der geografischen Verteilung schränkt jedoch die erreichbare zusammengesetzte SLA und die Gesamtsicherheit erheblich ein.

    Wichtig

    Für Szenarien, die auf eine SLO abzielen, die größer oder gleich 99,99 % ist, wird empfohlen, mindestens drei Bereitstellungsregionen zu verwenden, um die zusammengesetzte SLA und die Gesamtzulässigkeit zu maximieren. Berechnen Sie die zusammengesetzte SLA für alle Benutzerflows. Stellen Sie sicher, dass die zusammengesetzte SLA an Geschäftszielen ausgerichtet ist.

  • Entwerfen Sie für hochskalige Anwendungsszenarien mit beträchtlichem Datenverkehrsvolumen die Lösung so, dass sie über mehrere Regionen hinweg skaliert wird, um potenzielle Kapazitätseinschränkungen innerhalb einer einzelnen Region zu bewältigen. Zusätzliche regionale Bereitstellungsstempel erreichen eine höhere zusammengesetzte SLA. Die Verwendung globaler Ressourcen schränkt die Erhöhung der zusammengesetzten SLA ein, die Sie erreichen, indem Sie weitere Regionen hinzufügen.

  • Definieren und überprüfen Sie Ihre RPO-Ziele (Recovery Point Objectives) und Recovery Time Objectives (RTO).

  • Priorisieren Sie innerhalb einer einzelnen Geografie die Verwendung regionaler Paare, um von serialisierten SDP-Rollouts für geplante Wartung und regionale Priorisierung für ungeplante Wartungen zu profitieren.

  • Geografische Zuordnung von Azure-Ressourcen mit Benutzern, um die Netzwerklatenz zu minimieren und die End-to-End-Leistung zu maximieren.

  • Richten Sie die aktuelle Dienstverfügbarkeit an Produktroadmaps aus, wenn Sie Bereitstellungsregionen auswählen. Einige Dienste sind möglicherweise nicht sofort in jeder Region verfügbar.

Containerisierung

Ein Container enthält Anwendungscode und die zugehörigen Konfigurationsdateien, Bibliotheken und Abhängigkeiten, die die Anwendung ausführen muss. Die Containerisierung stellt eine Abstraktionsebene für Anwendungscode und dessen Abhängigkeiten bereit und schafft eine Trennung von der zugrunde liegenden Hostingplattform. Das einzelne Softwarepaket ist hochgradig portabel und kann konsistent über verschiedene Infrastrukturplattformen und Cloudanbieter hinweg ausgeführt werden. Entwickler müssen code nicht umschreiben und können Anwendungen schneller und zuverlässiger bereitstellen.

Wichtig

Es wird empfohlen, Container für unternehmenskritische Anwendungspakete zu verwenden. Sie verbessern die Infrastrukturnutzung, da Sie mehrere Container in derselben virtualisierten Infrastruktur hosten können. Da die gesamte Software im Container enthalten ist, können Sie die Anwendung unabhängig von Laufzeiten oder Bibliotheksversionen über verschiedene Betriebssysteme hinweg verschieben. Die Verwaltung ist auch bei Containern einfacher als bei herkömmlichem virtualisiertem Hosting.

Unternehmenskritische Anwendungen müssen schnell skaliert werden, um Leistungsengpässe zu vermeiden. Da Containerimages vorkonfiguriert sind, können Sie den Start nur während des Bootstrappings der Anwendung einschränken, was eine schnelle Skalierbarkeit bietet.

Überlegungen zum Entwurf

  • Überwachung: Für die Überwachung von Diensten kann es schwierig sein, auf Anwendungen zuzugreifen, die sich in Containern befinden. In der Regel benötigen Sie Software von Drittanbietern, um Containerzustandsindikatoren wie CPU- oder RAM-Auslastung zu erfassen und zu speichern.

  • Sicherheit. Der Betriebssystemkernkern der Hostingplattform wird über mehrere Container hinweg gemeinsam genutzt, sodass ein einzelner Angriffspunkt entsteht. Das Risiko des Host-VM-Zugriffs ist jedoch begrenzt, da Container vom zugrunde liegenden Betriebssystem isoliert sind.

  • Zustand Obwohl es möglich ist, Daten im Dateisystem eines ausgeführten Containers zu speichern, werden die Daten nicht beibehalten, wenn der Container neu erstellt wird. Speichern Sie stattdessen Daten, indem Sie externen Speicher einbinden oder eine externe Datenbank verwenden.

Entwurfsempfehlungen

  • Containerisieren aller Anwendungskomponenten. Verwenden Sie Containerimages als primäres Modell für Anwendungsbereitstellungspakete.

  • Priorisieren Sie Linux-basierte Containerruntimes nach Möglichkeit. Die Images sind schlanker, und neue Features für Linux-Knoten/Container werden häufig veröffentlicht.

  • Machen Sie Container unveränderlich und ersetzbar mit kurzen Lebenszyklen.

  • Stellen Sie sicher, dass Sie alle relevanten Protokolle und Metriken aus dem Container, containerhost und dem zugrunde liegenden Cluster sammeln. Senden Sie die gesammelten Protokolle und Metriken zur weiteren Verarbeitung und Analyse an eine einheitliche Datensenke.

  • Containerimages in Azure Container Registry speichern. Verwenden Sie die Georeplikation , um Containerimages in allen Regionen zu replizieren. Aktivieren Sie Microsoft Defender für Containerregistrierungen, um die Überprüfung auf Sicherheitsrisiken für Containerimages bereitzustellen. Stellen Sie sicher, dass der Zugriff auf die Registrierung durch Microsoft Entra ID verwaltet wird.

Containerhosting und -orchestrierung

Mehrere Azure-Anwendungsplattformen können Container effektiv hosten. Es gibt Vor- und Nachteile, die mit jeder dieser Plattformen verbunden sind. Vergleichen Sie die Optionen im Kontext Ihrer Geschäftsanforderungen. Optimieren Sie jedoch immer Zuverlässigkeit, Skalierbarkeit und Leistung. Weitere Informationen und Beispiele finden Sie in diesen Artikeln:

Wichtig

Azure Kubernetes Service (AKS) und Azure Container Apps sollten je nach Ihren Anforderungen die erste Wahl für die Containerverwaltung sein. Obwohl Azure App Service kein Orchestrator ist, ist es als reibungsarme Containerplattform dennoch eine praktikable Alternative zu AKS.

Entwurfsüberlegungen und Empfehlungen für Azure Kubernetes Service

AKS, ein verwalteter Kubernetes-Dienst, ermöglicht eine schnelle Clusterbereitstellung ohne komplexe Clusterverwaltungsaktivitäten und bietet einen Featuresatz, der erweiterte Netzwerk- und Identitätsfunktionen umfasst. Eine vollständige Reihe von Empfehlungen finden Sie unter Azure Well-Architected Framework Review – AKS.

Wichtig

Es gibt einige grundlegende Konfigurationsentscheidungen, die Sie nicht ändern können, ohne den AKS-Cluster erneut bereitzustellen. Beispiele hierfür sind die Auswahl zwischen öffentlichen und privaten AKS-Clustern, das Aktivieren von Azure-Netzwerkrichtlinien, Microsoft Entra Integration und die Verwendung verwalteter Identitäten für AKS anstelle von Dienstprinzipalen.

Zuverlässigkeit

AKS verwaltet die native Kubernetes-Steuerungsebene. Wenn die Steuerungsebene nicht verfügbar ist, kommt es zu Ausfallzeiten für die Workload. Nutzen Sie die Zuverlässigkeitsfeatures von AKS:

  • Stellen Sie AKS-Cluster in verschiedenen Azure-Regionen als Skalierungseinheit bereit, um die Zuverlässigkeit und Verfügbarkeit zu maximieren. Verwenden Sie Verfügbarkeitszonen , um die Resilienz innerhalb einer Azure-Region zu maximieren, indem Sie AKS-Steuerungsebene und Agentknoten auf physisch getrennte Rechenzentren verteilen. Wenn die Colocationlatenz jedoch ein Problem darstellt, können Sie die AKS-Bereitstellung innerhalb einer einzelnen Zone durchführen oder Näherungsplatzierungsgruppen verwenden, um die Latenz zwischen Knoten zu minimieren.

  • Verwenden Sie die AKS-Betriebszeit-SLA für Produktionscluster, um die Verfügbarkeitsgarantien für Kubernetes-API-Endpunkte zu maximieren.

Skalierbarkeit

Berücksichtigen Sie AKS-Skalierungslimits, z. B. die Anzahl der Knoten, Knotenpools pro Cluster und Cluster pro Abonnement.

Isolation

Grenzen zwischen der von der Workload verwendeten Infrastruktur und den Systemtools beibehalten. Die gemeinsame Nutzung der Infrastruktur kann zu einer hohen Ressourcenauslastung und zu Szenarios mit lärmintensiven Nachbarn führen.

  • Verwenden Sie separate Knotenpools für System- und Workloaddienste. Dedizierte Knotenpools für Workloadkomponenten sollten auf den Anforderungen für spezialisierte Infrastrukturressourcen wie GPU-VMs mit hohem Arbeitsspeicher basieren. Um unnötigen Verwaltungsaufwand zu reduzieren, vermeiden Sie im Allgemeinen die Bereitstellung einer großen Anzahl von Knotenpools.

  • Verwenden Sie Taints und Toleranzen , um dedizierte Knoten bereitzustellen und ressourcenintensive Anwendungen zu begrenzen.

  • Bewerten Sie anwendungsaffine und Antiaffinitätsanforderungen, und konfigurieren Sie die entsprechende Colocation von Containern auf Knoten.

Sicherheit

Standard-Kubernetes erfordert eine erhebliche Konfiguration, um einen geeigneten Sicherheitsstatus für unternehmenskritische Szenarien sicherzustellen. AKS behandelt verschiedene Sicherheitsrisiken sofort. Zu den Features gehören private Cluster, Überwachung und Anmeldung bei Log Analytics, feste Knotenimages und verwaltete Identitäten.

  • Wenden Sie den Konfigurationsleitfaden in der AKS-Sicherheitsbaseline an.

  • Verwenden Sie AKS-Features für die Verwaltung von Clusteridentitäten und -zugriffen, um den Betriebsaufwand zu reduzieren und eine konsistente Zugriffsverwaltung anzuwenden.

  • Verwenden Sie verwaltete Identitäten anstelle von Dienstprinzipalen, um die Verwaltung und Rotation von Anmeldeinformationen zu vermeiden. Sie können verwaltete Identitäten auf Clusterebene hinzufügen. Auf Podebene können Sie verwaltete Identitäten über Microsoft Entra Workload ID verwenden.

  • Verwenden Sie Microsoft Entra Integration für die zentrale Kontoverwaltung und Kennwörter, die Anwendungszugriffsverwaltung und den erweiterten Identitätsschutz. Verwenden Sie Kubernetes RBAC mit Microsoft Entra ID für die geringsten Berechtigungen, und minimieren Sie das Gewähren von Administratorrechten, um den Zugriff auf Konfiguration und Geheimnisse zu schützen. Beschränken Sie außerdem den Zugriff auf die Kubernetes-Clusterkonfigurationsdatei mithilfe der rollenbasierten Zugriffssteuerung in Azure. Beschränken Sie den Zugriff auf Aktionen, die Container ausführen können, stellen Sie die geringste Anzahl von Berechtigungen bereit, und vermeiden Sie die Verwendung der Stammberechtigungsausweitung.

Upgrades

Cluster und Knoten müssen regelmäßig aktualisiert werden. AKS unterstützt Kubernetes-Versionen in Übereinstimmung mit dem Releasezyklus nativer Kubernetes.

  • Abonnieren Sie die öffentliche AKS-Roadmap und die Versionshinweise auf GitHub, um über bevorstehende Änderungen, Verbesserungen und, was am wichtigsten ist, Kubernetes-Versionsversionen und -veraltet zu halten.

  • Wenden Sie die Anleitungen in der AKS-Checkliste an, um die Übereinstimmung mit bewährten Methoden sicherzustellen.

  • Beachten Sie die verschiedenen Methoden, die von AKS zum Aktualisieren von Knoten und/oder Clustern unterstützt werden. Diese Methoden können manuell oder automatisiert sein. Sie können geplante Wartung verwenden, um Wartungsfenster für diese Vorgänge zu definieren. Neue Images werden wöchentlich veröffentlicht. AKS unterstützt auch kanäle für das automatische Upgrade von AKS-Clustern auf neuere Versionen von Kubernetes und/oder neueren Knotenimages, wenn diese verfügbar sind.

Netzwerk

Bewerten Sie die Netzwerk-Plug-Ins, die am besten zu Ihrem Anwendungsfall passen. Bestimmen Sie, ob Sie eine präzise Steuerung des Datenverkehrs zwischen Pods benötigen. Azure unterstützt kubenet, Azure CNI und Bring Your Own CNI für bestimmte Anwendungsfälle.

Priorisieren Sie die Verwendung von Azure CNI nach der Bewertung der Netzwerkanforderungen und der Größe des Clusters. Azure CNI ermöglicht die Verwendung von Azure - oder Calico-Netzwerkrichtlinien zum Steuern des Datenverkehrs innerhalb des Clusters.

Überwachung

Ihre Überwachungstools sollten in der Lage sein, Protokolle und Metriken von ausgeführten Pods zu erfassen. Sie sollten auch Informationen aus der Kubernetes-Metrik-API sammeln, um die Integrität ausgeführter Ressourcen und Workloads zu überwachen.

  • Verwenden Sie Azure Monitor und Application Insights, um Metriken, Protokolle und Diagnose aus AKS-Ressourcen für die Problembehandlung zu sammeln.

  • Aktivieren und überprüfen Sie Kubernetes-Ressourcenprotokolle.

  • Konfigurieren Sie Prometheus-Metriken in Azure Monitor. Container Insights in Monitor bietet Onboarding, ermöglicht standardmäßige Überwachungsfunktionen und ermöglicht erweiterte Funktionen über die integrierte Prometheus-Unterstützung.

Governance

Verwenden Sie Richtlinien, um zentralisierte Sicherheitsvorkehrungen konsistent auf AKS-Cluster anzuwenden. Wenden Sie Richtlinienzuweisungen in einem Abonnementbereich oder höher an, um die Konsistenz zwischen Entwicklungsteams zu fördern.

  • Steuern Sie mithilfe von Azure Policy, welche Funktionen Pods gewährt werden und ob die Ausführung einer Richtlinie widerspricht. Dieser Zugriff wird durch integrierte Richtlinien definiert, die durch das Azure Policy-Add-On für AKS bereitgestellt werden.

  • Erstellen Sie mithilfe von Azure Policy eine konsistente Zuverlässigkeits- und Sicherheitsbaseline für AKS-Cluster- und Podkonfigurationen.

  • Verwenden Sie das Azure Policy Add-On für AKS, um Podfunktionen wie Stammberechtigungen zu steuern und Pods zu verbieten, die nicht der Richtlinie entsprechen.

Hinweis

Wenn Sie die Bereitstellung in einer Azure-Zielzone durchführen, sollten die Azure-Richtlinien, die Ihnen helfen, eine konsistente Zuverlässigkeit und Sicherheit sicherzustellen, von der Implementierung der Zielzone bereitgestellt werden.

Die unternehmenskritischen Referenzimplementierungen bieten eine Reihe von Basisrichtlinien, um empfohlene Zuverlässigkeits- und Sicherheitskonfigurationen zu fördern.

Entwurfsüberlegungen und Empfehlungen für Azure App Service

Für web- und API-basierte Workloadszenarien kann App Service eine praktikable Alternative zu AKS sein. Es bietet eine reibungsarme Containerplattform ohne die Komplexität von Kubernetes. Eine vollständige Reihe von Empfehlungen finden Sie unter Zuverlässigkeitsüberlegungen für App Service und operationale Exzellenz für App Service.

Zuverlässigkeit

Erwägen Sie die Verwendung von TCP- und SNAT-Ports. TCP-Verbindungen werden für alle ausgehenden Verbindungen verwendet. SNAT-Ports werden für ausgehende Verbindungen mit öffentlichen IP-Adressen verwendet. Die SNAT-Portauslastung ist ein häufiges Fehlerszenario. Sie sollten dieses Problem vorausschauend durch Auslastungstests erkennen, während Sie Azure-Diagnose zum Überwachen von Ports verwenden. Wenn SNAT-Fehler auftreten, müssen Sie entweder auf mehr oder größere Worker skalieren oder Codierungsmethoden implementieren, um SNAT-Ports beizubehalten und wiederzuverwenden. Beispiele für Programmierpraktiken, die Sie verwenden können, sind Verbindungspools und das verzögerte Laden von Ressourcen.

Die TCP-Portauslastung ist ein weiteres Fehlerszenario. Dies tritt auf, wenn die Summe der ausgehenden Verbindungen von einem bestimmten Worker die Kapazität überschreitet. Die Anzahl der verfügbaren TCP-Ports hängt von der Größe des Workers ab. Empfehlungen finden Sie unter TCP- und SNAT-Ports.

Skalierbarkeit

Planen Sie zukünftige Skalierbarkeitsanforderungen und Anwendungswachstum, damit Sie von Anfang an geeignete Empfehlungen anwenden können. Auf diese Weise können Sie technische Migrationsschulden vermeiden, wenn die Lösung wächst.

  • Aktivieren Sie die automatische Skalierung, um sicherzustellen, dass angemessene Ressourcen für Dienstanforderungen verfügbar sind. Bewerten Sie die Skalierung pro App für Hosting mit hoher Dichte auf App Service.

  • Beachten Sie, dass App Service einen standardmäßigen, weichen Grenzwert für Instanzen pro App Service Plan aufweist.

  • Wenden Sie Regeln für die automatische Skalierung an. Ein App Service Plan wird skaliert, wenn eine Regel innerhalb des Profils erfüllt ist, aber nur dann skaliert, wenn alle Regeln innerhalb des Profils erfüllt sind. Verwenden Sie eine Kombination aus Horizontal- und Horizontalskalierungsregeln, um sicherzustellen, dass die automatische Skalierung Maßnahmen ergreifen kann, um sowohl horizontal als auch horizontal hochskaliert zu werden. Verstehen des Verhaltens mehrerer Skalierungsregeln in einem einzelnen Profil.

  • Beachten Sie, dass Sie die Skalierung pro App auf der Ebene des App Service-Plans aktivieren können, damit eine Anwendung unabhängig vom App Service Plan skalieren kann, der sie hostet. Apps werden verfügbaren Knoten über einen Best-Effort-Ansatz für eine gleichmäßige Verteilung zugeordnet. Obwohl eine gleichmäßige Verteilung nicht garantiert wird, stellt die Plattform sicher, dass zwei Instanzen derselben App nicht auf demselben instance gehostet werden.

Überwachung

Überwachen Sie das Anwendungsverhalten, und erhalten Sie Zugriff auf relevante Protokolle und Metriken, um sicherzustellen, dass Ihre Anwendung wie erwartet funktioniert.

  • Sie können die Diagnoseprotokollierung verwenden, um Protokolle auf Anwendungsebene und Plattformebene in Log Analytics, Azure Storage oder einem Drittanbietertool über Azure Event Hubs zu erfassen.

  • Die Überwachung der Anwendungsleistung mit Application Insights bietet umfassende Einblicke in die Anwendungsleistung.

  • Unternehmenskritische Anwendungen müssen in der Lage sein, sich selbst zu heilen, wenn Fehler auftreten. Aktivieren Sie die automatische Reparatur , um fehlerhafte Worker automatisch zu recyceln.

  • Sie müssen geeignete Integritätsprüfungen verwenden, um alle kritischen Downstreamabhängigkeiten zu bewerten, um die allgemeine Integrität sicherzustellen. Es wird dringend empfohlen, die Integritätsprüfung zu aktivieren, um nicht reaktionsfähige Mitarbeiter zu identifizieren.

Bereitstellung

Um das Standardlimit für Instanzen pro App Service Plan zu umgehen, stellen Sie App Service Pläne in mehreren Skalierungseinheiten in einer einzelnen Region bereit. Stellen Sie App Service Pläne in einer Verfügbarkeitszonenkonfiguration bereit, um sicherzustellen, dass Workerknoten auf Zonen innerhalb einer Region verteilt sind. Erwägen Sie, ein Supportticket zu öffnen, um die maximale Anzahl von Workern auf das Doppelte der instance Anzahl zu erhöhen, die Sie für die normale Spitzenlast benötigen.

Containerregistrierung

Containerregistrierungen hosten Images, die in Containerruntimeumgebungen wie AKS bereitgestellt werden. Sie müssen Ihre Containerregistrierungen für unternehmenskritische Workloads sorgfältig konfigurieren. Ein Ausfall sollte keine Verzögerungen beim Pullen von Images verursachen, insbesondere bei Skalierungsvorgängen. Die folgenden Überlegungen und Empfehlungen konzentrieren sich auf Azure Container Registry und untersuchen die Kompromisse, die mit zentralisierten und Verbundbereitstellungsmodellen verbunden sind.

Überlegungen zum Entwurf

  • Format: Erwägen Sie die Verwendung einer Containerregistrierung, die auf dem von Docker bereitgestellten Format und standards für Push- und Pullvorgänge basiert. Diese Lösungen sind kompatibel und größtenteils austauschbar.

  • Bereitstellungsmodell. Sie können die Containerregistrierung als zentralisierten Dienst bereitstellen, der von mehreren Anwendungen in Ihrem organization genutzt wird. Alternativ können Sie sie als dedizierte Komponente für eine bestimmte Anwendungsworkload bereitstellen.

  • Öffentliche Register. Containerimages werden in Docker Hub oder anderen öffentlichen Registrierungen gespeichert, die außerhalb von Azure und einem bestimmten virtuellen Netzwerk vorhanden sind. Dies ist nicht unbedingt ein Problem, kann aber zu verschiedenen Problemen führen, die im Zusammenhang mit der Dienstverfügbarkeit, Drosselung und Datenexfiltration stehen. In einigen Anwendungsszenarien müssen Sie öffentliche Containerimages in einer privaten Containerregistrierung replizieren, um ausgehenden Datenverkehr zu begrenzen, die Verfügbarkeit zu erhöhen oder eine potenzielle Drosselung zu vermeiden.

Entwurfsempfehlungen

  • Verwenden Sie Containerregistrierungsinstanzen, die für die Anwendungsworkload dediziert sind. Vermeiden Sie das Erstellen einer Abhängigkeit von einem zentralisierten Dienst, es sei denn, die Anforderungen an die Verfügbarkeit und Zuverlässigkeit der Organisation sind vollständig auf die Anwendung abgestimmt.

    Im empfohlenen Kernarchitekturmuster sind Containerregistrierungen globale Ressourcen, die langlebig sind. Erwägen Sie die Verwendung einer einzelnen globalen Containerregistrierung pro Umgebung. Verwenden Sie beispielsweise eine globale Produktionsregistrierung.

  • Stellen Sie sicher, dass die SLA für die öffentliche Registrierung ihren Zuverlässigkeits- und Sicherheitszielen entspricht. Beachten Sie besondere Drosselungsgrenzwerte für Anwendungsfälle, die von Docker Hub abhängen.

  • Priorisieren sie Azure Container Registry zum Hosten von Containerimages.

Entwurfsüberlegungen und Empfehlungen für Azure Container Registry

Dieser native Dienst bietet eine Reihe von Features, einschließlich Georeplikation, Microsoft Entra Authentifizierung, automatisiertes Erstellen von Containern und Patchen über Container Registry-Aufgaben.

Zuverlässigkeit

Konfigurieren Sie die Georeplikation in allen Bereitstellungsregionen, um regionale Abhängigkeiten zu entfernen und die Latenzzeit zu optimieren. Container Registry unterstützt Hochverfügbarkeit durch Georeplikation in mehrere konfigurierte Regionen und bietet Resilienz bei regionalen Ausfällen. Wenn eine Region nicht mehr verfügbar ist, verarbeiten die anderen Regionen weiterhin Imageanforderungen. Wenn die Region wieder online ist, stellt Container Registry die Wiederherstellung und Replikation von Änderungen daran her. Diese Funktion ermöglicht auch die Colocation der Registrierung in jeder konfigurierten Region, wodurch die Netzwerkwartezeit und die Kosten regionsübergreifender Datenübertragungen reduziert werden.

In Azure-Regionen, die Unterstützung für Verfügbarkeitszonen bieten, unterstützt die Premium-Containerregistrierungsebene Zonenredundanz , um Schutz vor Zonenausfällen zu bieten. Der Premium-Tarif unterstützt auch private Endpunkte , um nicht autorisierten Zugriff auf die Registrierung zu verhindern, was zu Zuverlässigkeitsproblemen führen kann.

Hosten Sie Images in der Nähe der verbrauchenden Computeressourcen innerhalb derselben Azure-Regionen.

Bildsperren

Bilder können gelöscht werden, z. B. aufgrund eines manuellen Fehlers. Container Registry unterstützt das Sperren einer Imageversion oder eines Repositorys , um Änderungen oder Löschungen zu verhindern. Wenn eine zuvor bereitgestellte Imageversion geändert wird, können Bereitstellungen mit derselben Version vor und nach der Änderung unterschiedliche Ergebnisse liefern.

Wenn Sie die Container Registry-instance vor dem Löschen schützen möchten, verwenden Sie Ressourcensperren.

Markierte Bilder

Getaggede Container Registry-Images sind standardmäßig veränderlich, was bedeutet, dass dasselbe Tag für mehrere Images verwendet werden kann, die an die Registrierung gepusht werden. In Produktionsszenarien kann dies zu unvorhersehbarem Verhalten führen, das sich auf die Betriebszeit der Anwendung auswirken kann.

Identitäts- und Zugriffsverwaltung

Verwenden Sie Microsoft Entra integrierte Authentifizierung, um Images per Push zu übertragen und zu pullen, anstatt sich auf Zugriffsschlüssel zu verlassen. Um die Sicherheit zu erhöhen, deaktivieren Sie die Verwendung des Administratorzugriffsschlüssels vollständig.

Serverloses Computing

Serverloses Computing stellt Ressourcen nach Bedarf bereit und entfällt die Notwendigkeit, die Infrastruktur zu verwalten. Der Cloudanbieter stellt automatisch die Ressourcen bereit, skaliert und verwaltet sie, die zum Ausführen des bereitgestellten Anwendungscodes erforderlich sind. Azure bietet mehrere serverlose Computeplattformen:

  • Azure Functions. Wenn Sie Azure Functions verwenden, wird die Anwendungslogik als unterschiedliche Codeblöcke oder Funktionen implementiert, die als Reaktion auf Ereignisse wie eine HTTP-Anforderung oder Warteschlangennachricht ausgeführt werden. Jede Funktion wird nach Bedarf skaliert, um die Nachfrage zu erfüllen.

  • Azur Logic Apps. Logic Apps eignet sich am besten zum Erstellen und Ausführen automatisierter Workflows, die verschiedene Apps, Datenquellen, Dienste und Systeme integrieren. Wie Azure Functions verwendet Logic Apps integrierte Trigger für die ereignisgesteuerte Verarbeitung. Anstatt jedoch Anwendungscode bereitzustellen, können Sie Logik-Apps mithilfe einer grafischen Benutzeroberfläche erstellen, die Codeblöcke wie Bedingungen und Schleifen unterstützt.

  • Azure API Management: Sie können API Management verwenden, um APIs mit erweiterter Sicherheit zu veröffentlichen, zu transformieren, zu verwalten und zu überwachen, indem Sie die Nutzungsebene verwenden.

  • Power Apps und Power Automate. Diese Tools bieten eine Low-Code- oder No-Code-Entwicklungsumgebung mit einfacher Workflowlogik und Integrationen, die über Verbindungen in einer Benutzeroberfläche konfigurierbar sind.

Für unternehmenskritische Anwendungen bieten serverlose Technologien vereinfachte Entwicklungs- und Betriebsabläufe, die für einfache Geschäftsanwendungen nützlich sein können. Diese Einfachheit geht jedoch auf Kosten von Flexibilität in Bezug auf Skalierbarkeit, Zuverlässigkeit und Leistung, und dies ist für die meisten unternehmenskritischen Anwendungsszenarien nicht praktikabel.

Die folgenden Abschnitte enthalten Entwurfsüberlegungen und Empfehlungen für die Verwendung von Azure Functions und Logic Apps als alternative Plattformen für nicht kritische Workflowszenarien.

Entwurfsüberlegungen und Empfehlungen für Azure Functions

Unternehmenskritische Workloads weisen kritische und nicht kritische Systemflüsse auf. Azure Functions ist eine praktikable Wahl für Flows, die nicht die gleichen strengen Geschäftsanforderungen wie kritische Systemflüsse haben. Es eignet sich gut für ereignisgesteuerte Flows mit kurzlebigen Prozessen, da Funktionen unterschiedliche Vorgänge ausführen, die so schnell wie möglich ausgeführt werden.

Wählen Sie eine Azure Functions Hostingoption aus, die für die Zuverlässigkeitsebene der Anwendung geeignet ist. Wir empfehlen den Premium-Plan, da sie compute-instance Größe konfigurieren können. Der Dedicated-Plan ist die am wenigsten serverlose Option. Es ermöglicht die automatische Skalierung, aber diese Skalierungsvorgänge sind langsamer als die der anderen Pläne. Es wird empfohlen, den Premium-Plan zu verwenden, um die Zuverlässigkeit und Leistung zu maximieren.

Es gibt einige Sicherheitsüberlegungen. Wenn Sie einen HTTP-Trigger verwenden, um einen externen Endpunkt verfügbar zu machen, verwenden Sie eine Web Application Firewall (WAF), um den HTTP-Endpunkt vor gängigen externen Angriffsvektoren zu schützen.

Es wird empfohlen, private Endpunkte zum Einschränken des Zugriffs auf private virtuelle Netzwerke zu verwenden. Sie können auch Risiken der Datenexfiltration minimieren, z. B. böswillige Administratorszenarien.

Sie müssen Codescantools für Azure Functions Code verwenden und diese Tools in CI/CD-Pipelines integrieren.

Entwurfsüberlegungen und Empfehlungen für Azure Logic Apps

Wie Azure Functions verwendet Logic Apps integrierte Trigger für die ereignisgesteuerte Verarbeitung. Anstatt jedoch Anwendungscode bereitzustellen, können Sie Logik-Apps mithilfe einer grafischen Benutzeroberfläche erstellen, die Blöcke wie Bedingungen, Schleifen und andere Konstrukte unterstützt.

Es stehen mehrere Bereitstellungsmodi zur Verfügung. Wir empfehlen den Standardmodus, um eine Bereitstellung mit einem einzelnen Mandanten sicherzustellen und verrauschte Nachbarszenarien zu vermeiden. In diesem Modus wird die logic Apps-Runtime für containerisierte Einzelmandanten verwendet, die auf Azure Functions basiert. In diesem Modus kann die Logik-App über mehrere zustandsbehaftete und zustandslose Workflows verfügen. Sie sollten sich der Konfigurationsgrenzwerte bewusst sein.

Eingeschränkte Migrationen über IaaS

Viele Anwendungen, die über lokale Bereitstellungen verfügen, verwenden Virtualisierungstechnologien und redundante Hardware, um unternehmenskritische Zuverlässigkeit zu bieten. Die Modernisierung wird häufig durch Geschäftseinschränkungen behindert, die eine vollständige Ausrichtung auf das cloudnative Basisarchitekturmuster (North Star) verhindern, das für unternehmenskritische Workloads empfohlen wird. Aus diesem Grund verfolgen viele Anwendungen einen gestaffelten Ansatz, wobei erste Cloudbereitstellungen Virtualisierung und Azure Virtual Machines als primäres Anwendungshostingmodell verwenden. Die Verwendung von virtuellen IaaS-Computern kann in bestimmten Szenarien erforderlich sein:

  • Verfügbare PaaS-Dienste bieten nicht die erforderliche Leistung oder Steuerungsebene.
  • Die Workload erfordert Betriebssystemzugriff, bestimmte Treiber oder Netzwerk- und Systemkonfigurationen.
  • Die Workload unterstützt die Ausführung in Containern nicht.
  • Es gibt keine Anbieterunterstützung für Workloads von Drittanbietern.

In diesem Abschnitt werden die besten Möglichkeiten zum Verwenden von Azure Virtual Machines und zugehörigen Diensten behandelt, um die Zuverlässigkeit der Anwendungsplattform zu maximieren. Es werden wichtige Aspekte der unternehmenskritischen Entwurfsmethodik hervorgehoben, die cloudnative und IaaS-Migrationsszenarien transponiert.

Überlegungen zum Entwurf

  • Die Betriebskosten für die Verwendung virtueller IaaS-Computer sind aufgrund der Verwaltungsanforderungen der virtuellen Computer und der Betriebssysteme erheblich höher als die Kosten für die Verwendung von PaaS-Diensten. Die Verwaltung virtueller Computer erfordert den häufigen Rollout von Softwarepaketen und Updates.

  • Azure bietet Funktionen, um die Verfügbarkeit virtueller Computer zu erhöhen:

    • Verfügbarkeitsgruppen können zum Schutz vor Netzwerk-, Datenträger- und Stromausfällen beitragen, indem virtuelle Computer über Fehlerdomänen und Updatedomänen verteilt werden.
    • Verfügbarkeitszonen können Ihnen dabei helfen, ein noch höheres Maß an Zuverlässigkeit zu erzielen, indem VMs auf physisch getrennte Rechenzentren innerhalb einer Region verteilt werden.
    • Virtual Machine Scale Sets Funktionen zum automatischen Skalieren der Anzahl virtueller Computer in einer Gruppe bereitstellen. Sie bieten auch Funktionen zum Überwachen instance Integrität und zum automatischen Reparieren fehlerhafter Instanzen.

Entwurfsempfehlungen

Wichtig

Verwenden Sie nach Möglichkeit PaaS-Dienste und -Container, um die Betriebskomplexität und die Kosten zu reduzieren. Verwenden Sie virtuelle IaaS-Computer nur bei Bedarf.

  • Vm-SKU-Größen mit der richtigen Größe , um eine effektive Ressourcennutzung sicherzustellen.

  • Stellen Sie drei oder mehr virtuelle Computer über Verfügbarkeitszonen hinweg bereit, um Fehlertoleranz auf Rechenzentrumsebene zu erreichen.

    • Wenn Sie kommerzielle Standardsoftware bereitstellen, wenden Sie sich an den Softwarehersteller, und testen Sie angemessen, bevor Sie die Software in der Produktion bereitstellen.

  • Verwenden Sie für Workloads, die nicht über Verfügbarkeitszonen hinweg bereitgestellt werden können, Verfügbarkeitsgruppen , die drei oder mehr VMs enthalten.

    • Berücksichtigen Sie Verfügbarkeitssätze nur, wenn Verfügbarkeitszonen die Workloadanforderungen nicht erfüllen, z. B. für chatzige Workloads mit geringen Latenzanforderungen.

  • Priorisieren Sie die Verwendung von Virtual Machine Scale Sets für Skalierbarkeit und Zonenredundanz. Dieser Punkt ist besonders wichtig für Workloads mit unterschiedlichen Auslastungen. Beispielsweise, wenn die Anzahl der aktiven Benutzer oder Anforderungen pro Sekunde eine unterschiedliche Auslastung aufweist.

  • Greifen Sie nicht direkt auf einzelne virtuelle Computer zu. Verwenden Sie nach Möglichkeit Lastenausgleichsmodule vor ihnen.

  • Stellen Sie zum Schutz vor regionalen Ausfällen virtuelle Anwendungscomputer in mehreren Azure-Regionen bereit.

  • Für Workloads, die aktiv/aktiv-Bereitstellungen in mehreren Regionen nicht unterstützen, sollten Sie die Implementierung von Aktiv/Passiv-Bereitstellungen in Erwägung ziehen, indem Sie virtuelle Standby-Computer mit Warm/Warm für regionales Failover verwenden.

  • Verwenden Sie Standardbilder aus Azure Marketplace anstelle von benutzerdefinierten Images, die verwaltet werden müssen.

  • Implementieren Sie automatisierte Prozesse zum Bereitstellen und Rollout von Änderungen auf virtuellen Computern, ohne manuelle Eingriffe. Weitere Informationen finden Sie unter IaaS-Überlegungen im Entwurfsbereich Operative Prozeduren .

  • Implementieren Sie Chaosexperimente, um Anwendungsfehler in VM-Komponenten einzuschleusen, und beobachten Sie die Fehlerminderung. Weitere Informationen finden Sie unter Fortlaufende Validierung und Tests.

  • Überwachen Sie virtuelle Computer, und stellen Sie sicher, dass Diagnoseprotokolle und Metriken in einer einheitlichen Datensenke erfasst werden.

  • Implementieren Sie ggf. Sicherheitspraktiken für unternehmenskritische Anwendungsszenarien und die bewährten Sicherheitsmethoden für IaaS-Workloads in Azure.

Nächster Schritt

Überprüfen Sie die Überlegungen für die Datenplattform.

Datenplattform