Integritätsmodellierung für unternehmenskritische Workloads

Die Überwachung von Anwendungen und Infrastruktur ist ein wichtiger Teil jeder Infrastrukturbereitstellung. Bei unternehmenskritischen Workloads ist die Überwachung ein wichtiger Teil der Bereitstellung. Die Überwachung der Anwendungsintegrität und der Schlüsselmetriken von Azure-Ressourcen gibt Aufschluss darüber, ob die Umgebung wie erwartet funktioniert.

Um diese Metriken vollständig verstehen und die allgemeine Integrität einer Workload bewerten zu können, ist ein ganzheitliches Verständnis aller überwachten Daten erforderlich. Ein Integritätsmodell kann bei der Auswertung des allgemeinen Integritätsstatus helfen, indem anstelle roher Metriken ein klarer Indikator für die Integrität der Workload angezeigt wird. Der Status wird häufig in Form einer Ampel (also rot, grün oder gelb) dargestellt. Durch die Darstellung eines Integritätsmodells mit klaren Indikatoren können Operatoren intuitiv die allgemeine Integrität der Workload erfassen und schnell auf ggf. auftretende Probleme reagieren.

Die Integritätsmodellierung kann auf die folgenden operativen Aufgaben für die unternehmenskritische Bereitstellung erweitert werden:

• Anwendungsintegritätsdienst: Anwendungskomponente im Computecluster, die eine API zur Bestimmung der Integrität eines Stempels bereitstellt

• Überwachung: Sammlung von Leistungs- und Anwendungsindikatoren zur Auswertung der Integrität und Leistung der Anwendung und Infrastruktur

• Warnungen: Aussagekräftige Warnungen zu Problemen oder Ausfällen in der Infrastruktur und Anwendung

• Fehleranalyse: Aufschlüsselung und Analyse aller Fehler, einschließlich Dokumentation der Grundursache

Diese Aufgaben bilden ein umfassendes Integritätsmodell für die unternehmenskritische Infrastruktur. Die Entwicklung eines Integritätsmodells kann und sollte ausführlich und ein integraler Bestandteil jeder unternehmenskritischen Bereitstellung sein.

Weitere Informationen finden Sie unter Integritätsmodellierung und Einblick für unternehmenskritische Workloads in Azure.

Anwendungsintegritätsdienst

Der Anwendungsintegritätsdienst (HealthService) ist eine Anwendungskomponente, die sich zusammen mit dem Katalogdienst (CatalogService) und dem Hintergrundprozessor (BackgroundProcessor) innerhalb des Computeclusters befindet. HealthService stellt eine REST-API bereit, die von Azure Front Door aufgerufen werden kann, um die Integrität eines Stempels zu ermitteln. HealthService ist eine komplexe Komponente, die neben dem eigenen Zustand auch den Zustand von Abhängigkeiten widerspiegelt.

Wenn der Compute-Cluster ausfällt, reagiert der Gesundheitsdienst nicht. Bei ordnungsgemäßer Ausführung der Dienste führt der Dienst regelmäßige Überprüfungen für die folgenden Komponenten in der Infrastruktur durch:

• Er versucht, eine Abfrage für Azure Cosmos DB auszuführen.

• Es versucht, eine Nachricht an Event Hubs zu senden. Der Hintergrundmitarbeiter filtert die Nachricht aus.

• Er sucht nach einer Statusdatei im Speicherkonto. Diese Datei kann verwendet werden, um eine Region zu deaktivieren, auch wenn die anderen Überprüfungen ordnungsgemäß ausgeführt werden. Außerdem kann diese Datei verwendet werden, um mit anderen Prozessen zu kommunizieren. Wenn also beispielsweise der Stempel für Wartungsarbeiten geräumt werden muss, kann die Datei gelöscht werden, um einen fehlerhaften Zustand zu generieren und Datenverkehr umzuleiten.

• Er fragt das Integritätsmodell ab, um zu ermitteln, ob sich alle operativen Metriken innerhalb der vordefinierten Schwellenwerte befinden. Wenn das Integritätsmodell angibt, dass der Stempel fehlerhaft ist, sollte kein Datenverkehr an den Stempel weitergeleitet werden, auch wenn die anderen Tests, die von HealthService durchgeführt wurden, erfolgreich waren. Im Rahmen des Integritätsmodells wird der Integritätsstatus umfassender betrachtet.

Alle Ergebnisse der Integritätsprüfung werden standardmäßig zehn Sekunden lang im Arbeitsspeicher zwischengespeichert. (Die Dauer ist allerdings konfigurierbar.) Dies hat ggf. eine kurze Wartezeit bei der Erkennung von Ausfällen zur Folge, sorgt jedoch dafür, dass nicht für jede HealthService-Abfrage Back-End-Aufrufe erforderlich sind, was den Cluster und die nachgelagerten Dienste entlastet.

Dieses Caching-Muster ist wichtig, da die Anzahl der HealthService-Abfragen bei der Verwendung eines globalen Routers wie Azure Front Door erheblich zunimmt: Jeder Edgeknoten in jedem Azure-Datacenter, die Anforderungen bereitstellen, ruft den Health Service auf, um festzustellen, ob es über eine funktionale Backend-Verbindung verfügt. Die Zwischenspeicherung der Ergebnisse verringert die zusätzliche Last für den Cluster, die durch Integritätsprüfungen entsteht.

Konfiguration

HealthService und CatalogService verfügen über gemeinsame Konfigurationseinstellungen. Die folgenden Einstellungen werden allerdings ausschließlich von HealthService verwendet:

Einstellung	Wert
HealthServiceCacheDurationSeconds	Steuert die Ablaufzeit des Cachespeichers in Sekunden.
HealthServiceStorageConnectionString	Verbindungszeichenfolge für das Speicherkonto, in dem die Statusdatei vorhanden sein sollte.
HealthServiceBlobContainerName	Speichercontainer, in dem die Statusdatei vorhanden sein sollte.
HealthServiceBlobName	Name der Statusdatei – Gesundheitsprüfung sucht nach dieser Datei.
HealthServiceOverallTimeoutSeconds	Timeout für die gesamte Prüfung – standardmäßig 3 Sekunden. Wenn die Überprüfung nicht innerhalb dieses Intervalls abgeschlossen wird, meldet der Dienst einen Fehler.

Implementierung

Alle Überprüfungen werden asynchron und parallel ausgeführt. Tritt bei einer der Überprüfungen ein Fehler auf, wird der gesamte Stempel als nicht verfügbar betrachtet.

Prüfergebnisse werden zwischenspeichernd im In-Memory gespeichert, unter Verwendung des standardmäßigen, nicht verteilten ASP.NET Core MemoryCache. SysConfig.HealthServiceCacheDurationSeconds steuert die Cache-Ablaufzeit. Die Standardeinstellung beträgt 10 Sekunden.

Hinweis

Die SysConfig.HealthServiceCacheDurationSeconds Konfigurationseinstellung reduziert die zusätzliche Belastung, die durch Integritätsprüfungen generiert wird, da nicht jede Anforderung zu einem nachgelagerten Aufruf der abhängigen Dienste führt.

Die folgende Tabelle enthält Details zu den Integritätsprüfungen für die Komponenten in der Infrastruktur:

Komponente	Integritätsprüfung
Speicherkontoblob	Die Blobprüfung hat derzeit zwei Funktionen: 1. Testen der Erreichbarkeit von Blob Storage. Das Speicherkonto wird von anderen Komponenten im Stempel verwendet und gilt als kritische Ressource. 2. Deaktivieren Sie einen Bereich manuell, indem Sie die Statusdatei löschen. Es wurde eine Entwurfsentscheidung getroffen, dass die Prüfung nur nach einem Vorhandensein einer Zustandsdatei im angegebenen BLOB-Container suchen würde. Der Inhalt der Datei wird nicht verarbeitet. Es besteht die Möglichkeit, ein komplexeres System einzurichten, das den Inhalt der Datei liest und basierend auf dem Inhalt der Datei verschiedene Statuswerte zurückgibt. Beispiele für einen derartigen Inhalt wären FEHLERFREI, FEHLERHAFT und WARTUNG. Entfernen der Statusdatei deaktiviert den Stempel. Vergewissern Sie sich nach dem Bereitstellen der Anwendung, dass die Integritätsdatei vorhanden ist. Fehlt die Zustandsdatei, reagiert der Dienst immer mit UNHEALTHY. Front Door erkennt das Backend nicht als verfügbar. Terraform erstellt die Datei, und diese sollte nach der Infrastrukturbereitstellung vorhanden sein.
Event Hub	Event Hubs Health Reporting liefert den EventHubProducerService. Dieser Dienst meldet einen fehlerfreien Zustand, wenn eine neue Nachricht an Event Hubs gesendet werden kann. Für die Filterung wird dieser Nachricht eine identifizierende Eigenschaft hinzugefügt: HEALTHCHECK=TRUE Die Nachricht wird auf der Empfangsseite ignoriert. Die Konfigurationseinstellung AlwaysOn.BackgroundProcessor.EventHubProcessorService.ProcessEventHandlerAsync() dient zur Überprüfung auf die Eigenschaft HEALTHCHECK.
Azure Cosmos DB	Azure Cosmos DB Health Reporting behandelt das CosmosDbService, das den Zustand meldet, wenn es gesund ist: 1. Er kann eine Verbindung mit der Azure Cosmos DB-Datenbank herstellen und eine Abfrage ausführen. 2. Er kann ein Testdokument in die Datenbank schreiben. Das Testdokument hat eine kurze Time-to-Live. Azure Cosmos DB entfernt sie automatisch. HealthService führt zwei separate Integritätstests aus. Wenn sich Azure Cosmos DB in einem Zustand befindet, in dem Lesevorgänge funktionieren, Schreibvorgänge aber nicht, sorgen die beiden Integritätstests dafür, dass eine Warnung ausgelöst wird.

Azure Cosmos DB-Abfragen

Für die schreibgeschützte Abfrage wird die folgende Abfrage verwendet. Sie ruft keine Daten ab und wirkt sich kaum auf die Gesamtlast aus:

SELECT GetCurrentDateTime ()

Die Schreibabfrage erstellt eine Dummy-Elementbewertung (ItemRating) mit minimalem Inhalt:

var testRating = new ItemRating()
{
    Id = Guid.NewGuid(),
    CatalogItemId = Guid.NewGuid(), // Create some random (=non-existing) item id
    CreationDate = DateTime.UtcNow,
    Rating = 1,
    TimeToLive = 10 // will be auto-deleted after 10sec
};

await AddNewRatingAsync(testRating);

Überwachung

Azure Log Analytics wird als zentraler Speicher für Protokolle und Metriken für alle Anwendungs- und Infrastrukturkomponenten verwendet. Azure Application Insights wird für alle Anwendungsüberwachungsdaten genutzt. Jeder Stempel in der Infrastruktur verfügt über einen dedizierten Log Analytics-Arbeitsbereich und über eine dedizierte Application Insights-Instanz. Für die global freigegebenen Ressourcen wie Front Door und Azure Cosmos DB wird ein separater Log Analytics-Arbeitsbereich verwendet.

Alle Stempel sind kurzlebig und werden kontinuierlich bei jedem neuen Release ersetzt. Die stempelspezifischen Log Analytics-Arbeitsbereiche werden wie die Log Analytics-Ressourcen des Stempels als globale Ressource in einer separaten Überwachungsressourcengruppe bereitgestellt. Diese Ressourcen haben nicht den gleichen Lebenszyklus wie ein Stempel.

Weitere Informationen finden Sie unter Einheitliche Datensenke für korrelierte Analysen.

Überwachung: Datenquellen

• Diagnoseeinstellungen: Alle Azure-Dienste, die für das unternehmenskritische Azure-Framework verwendet werden, werden so konfiguriert, dass alle ihre Diagnosedaten – einschließlich Protokolle und Metriken – an den bereitstellungsspezifischen (globalen oder stempelbezogenen) Log Analytics-Arbeitsbereich gesendet werden. Dies wird automatisch im Rahmen der Terraform-Bereitstellung durchgeführt. Neue Optionen werden automatisch identifiziert und als Teil von terraform applyhinzugefügt.

• Kubernetes-Überwachung: Diagnoseeinstellungen werden verwendet, um AKS-Protokolle (Azure Kubernetes Service) und -Metriken an die Protokollanalyse zu senden. AKS wird für die Verwendung von Container Insights konfiguriert. Container Insights stellt den OMS-Agent für Linux (OMSAgentForLinux) über ein Kubernetes-DaemonSet auf jedem Knoten in den AKS-Clustern bereit. Der OMS-Agent für Linux kann zusätzliche Protokolle und Metriken aus dem Kubernetes-Cluster sammeln und sendet sie an den entsprechenden Log Analytics-Arbeitsbereich. Diese zusätzlichen Protokolle und Metriken enthalten präzisere Daten zu Pods, Bereitstellungen, Diensten und der allgemeinen Cluster-Gesundheit. Um weitere Erkenntnisse aus den verschiedenen Komponenten wie „ingress-nginx“, „cert-manager“ und anderen Komponenten zu gewinnen, die neben der unternehmenskritischen Workload in Kubernetes bereitgestellt werden, kann Prometheus-Scraping verwendet werden. Prometheus-Scraping konfiguriert den OMS-Agent für Linux, um mittels Scraping Prometheus-Metriken von verschiedenen Endpunkten innerhalb des Clusters zu erfassen.

• Application Insights-Datenüberwachung: Application Insights wird verwendet, um Überwachungsdaten aus der Anwendung zu sammeln. Der Code wird instrumentiert, um Daten zur Leistung der Anwendung mit dem Application Insights SDK zu sammeln. Wichtige Informationen wie der resultierende Statuscode und die Dauer von Abhängigkeitsaufrufen sowie Zähler für Ausnahmefehler werden gesammelt. Diese Informationen werden im Integritätsmodell verwendet und stehen für Warnungen und für die Problembehandlung zur Verfügung.

Überwachung: Application Insights-Verfügbarkeitstests

Um die Verfügbarkeit der einzelnen Stempel und der Gesamtlösung von außen zu überwachen, werden an zwei Stellen Application Insights-Verfügbarkeitstests eingerichtet:

• Regionale Verfügbarkeitstests: Diese Tests werden in den regionalen Application Insights-Instanzen eingerichtet und verwendet, um die Verfügbarkeit der Stempel zu überwachen. Diese Tests sind direkt auf die Cluster und die statischen Speicherkonten der Stempel ausgerichtet. Um die Eingangspunkte der Cluster direkt aufzurufen, müssen Anforderungen den richtigen Front Door ID-Header tragen, andernfalls lehnt der Eingangscontroller die Aufrufe ab.

• Globale Verfügbarkeitstests: Diese Tests werden in der globalen Application Insights-Instanz eingerichtet und verwendet, um die Verfügbarkeit der Gesamtlösung durch Pingen von Front Door zu überwachen. Es werden zwei Tests verwendet: einer zum Testen eines API-Aufrufs für CatalogService und einer zum Testen der Startseite der Website.

Überwachung: Abfragen

Das unternehmenskritische Azure-Framework verwendet verschiedene Abfragen in der Kusto-Abfragesprache (Kusto Query Language, KQL), um benutzerdefinierte Abfragen als Funktionen zum Abrufen von Daten aus Log Analytics zu implementieren. Diese Abfragen werden als einzelne Dateien in unserem Coderepository gespeichert und nach globalen Bereitstellungen und Stempelbereitstellungen getrennt. Sie werden importiert und automatisch über Terraform als Teil jeder Infrastrukturpipeline angewendet.

Durch diesen Ansatz wird die Abfragelogik von der Visualisierungsebene getrennt. Die Log Analytics-Abfragen werden direkt über Code aufgerufen (beispielsweise über die HealthService-API). Weitere Beispiele wären ein Visualisierungstool wie Azure-Dashboards, Monitor-Arbeitsmappen oder Grafana.

Überwachung: Visualisierung

Wir verwenden Grafana, um die Ergebnisse unserer Log Analytics Abfragen zum Zustand in unserer Referenzimplementierung zu visualisieren. Grafana zeigt die Ergebnisse von Log Analytics-Abfragen an und enthält keine Logik selbst. Wir veröffentlichen den Grafana-Stapel separat vom Bereitstellungslebenszyklus der Lösung.

Weitere Informationen finden Sie unter Visualisierung.

Warnungen

Warnungen sind ein wichtiger Teil der allgemeinen Betriebsstrategie. Eine proaktive Überwachung wie die Verwendung von Dashboards sollte mit Warnungen kombiniert werden, die umgehend auf Probleme aufmerksam machen.

Diese Warnungen stellen eine Erweiterung des Integritätsmodells dar, indem sie den Operator auf eine Änderung des Integritätszustands (in einen beeinträchtigten/gelben Zustand oder in einen fehlerhaften/roten Zustand) aufmerksam machen. Durch Festlegen der Warnung auf den Stammknoten des Integritätsmodells wird der Operator sofort über geschäftliche Auswirkungen auf den Zustand der Lösung informiert, da dieser Stammknoten gelb oder rot wird, wenn einer der zugrunde liegenden Benutzerabläufe oder eine der zugrunde liegenden Ressourcen gelbe oder rote Metriken meldet. Der Operator kann die Visualisierung des Integritätsmodells für die Problembehandlung heranziehen.

Weitere Informationen finden Sie unter Automatisierte Reaktion auf Vorfälle.

Fehleranalyse

Die Erstellung der Fehleranalyse ist in erster Linie eine theoretische Planungsaufgabe. Diese theoretische Aufgabe sollte als Eingabe für die automatisierten Fehlereinschleusungen verwendet werden, die Teil des kontinuierlichen Überprüfungsprozesses sind. Indem wir die hier definierten Fehlermodi simulieren, können wir die Ausfallsicherheit der Lösung anhand dieser Fehler überprüfen, um Ausfälle zu minimieren.

Die folgende Tabelle enthält Beispielfehler der verschiedenen Komponenten der Referenzimplementierung des unternehmenskritischen Azure-Frameworks:

Dienst	Risiko	Auswirkung/Minderung/Kommentar	Outage
Microsoft Entra ID	Microsoft Entra ID ist nicht mehr verfügbar.	Derzeit gibt es keine Behandlungsmöglichkeit. Ein Ansatz mit mehreren Regionen entschärft keine Ausfälle, da es sich um einen globalen Dienst geht. Dieser Dienst ist eine feste Abhängigkeit. Microsoft Entra ID wird für Steuerungsebenenvorgänge wie das Erstellen neuer AKS-Knoten, das Pullen von Containerimages aus ACR oder das Zugreifen auf Key Vault beim Podstart verwendet. Vorhandene, ausgeführte Komponenten sollten weiterhin ausgeführt werden können, wenn Probleme mit der Microsoft Entra-ID auftreten. Es ist wahrscheinlich, dass neue Pods oder AKS-Knoten nicht spawnen können. Wenn während dieser Zeit Skalierungsvorgänge erforderlich sind, kommt es möglicherweise zu einer Beeinträchtigung der Benutzererfahrung und ggf. zu Ausfällen.	Partial
Azure DNS	Azure DNS ist nicht mehr verfügbar, und die DNS-Auflösung ist nicht erfolgreich.	Wenn Azure DNS nicht verfügbar ist, schlägt die DNS-Auflösung für Benutzeranforderungen und zwischen verschiedenen Komponenten der Anwendung fehl. Derzeit gibt es keine Behandlungsmöglichkeit für dieses Szenario. Ein Ansatz mit mehreren Regionen entschärft keine Ausfälle, da es sich um einen globalen Dienst geht. Azure DNS ist eine feste Abhängigkeit. Die Verwendung externer DNS-Dienste als Ausweichlösung hilft nicht, da alle verwendeten PaaS-Komponenten auf Azure DNS basieren. Die Umgehung von DNS durch Umstellung auf IP-Adressen ist keine Option. Azure-Dienste verfügen nicht über statische, garantierte IP-Adressen.	Vollständig
Front Door	Allgemeiner Front Door-Ausfall	Wenn Front Door vollständig ausfällt, gibt es keine Schadensbegrenzung. Dieser Dienst ist eine feste Abhängigkeit.	Ja
Front Door	Fehler im Zusammenhang mit der Routing-, Front-End- oder Back-End-Konfiguration	Dieses Problem kann durch Konfigurationskonflikte bei der Bereitstellung verursacht werden. Sollte beim Testen beseitigt werden. Die Front-End-Konfiguration mit DNS ist jeweils umgebungsspezifisch. Behandlung: Die meisten Probleme sollten sich durch ein Rollback zu einer früheren Konfiguration beheben lassen. Da die Bereitstellung von Änderungen in Front Door einige Minuten dauert, führt dies zu einem Ausfall.	Vollständig
Front Door	Verwaltetes TLS/SSL-Zertifikat wird gelöscht.	Dieses Problem kann durch Konfigurationskonflikte bei der Bereitstellung verursacht werden. Sollte beim Testen beseitigt werden. Technisch würde die Website weiterhin funktionieren, aber TLS/SSL-Zertifikatfehler verhindern, dass Benutzer darauf zugreifen. Behandlung: Die erneute Ausgabe des Zertifikats kann rund 20 Minuten dauern, zuzüglich Reparatur und erneuter Ausführung der Pipeline.	Vollständig
Azure Cosmos DB	Datenbank/Auflistung wird umbenannt.	Dieses Problem kann durch Konfigurationskonflikte bei der Bereitstellung verursacht werden. Terraform würde die gesamte Datenbank überschreiben, was zu Datenverlusten führen kann. Datenverluste können durch Sperrungen auf Datenbank-/Auflistungsebene verhindert werden. Die Anwendung kann nicht auf Daten zugreifen. Die App-Konfiguration muss aktualisiert und Pods müssen neu gestartet werden.	Ja
Azure Cosmos DB	Regionaler Ausfall	Für das unternehmenskritische Azure-Framework sind Schreibvorgänge in mehreren Regionen aktiviert. Wenn bei einem Lese- oder Schreibvorgang ein Fehler auftritt, wiederholt der Client den aktuellen Vorgang. Alle zukünftigen Vorgänge werden dauerhaft gemäß der bevorzugten Reihenfolge an die nächste Region weitergeleitet. Wenn die Präferenzliste nur einen einzelnen Eintrag enthält (oder leer war), für das Konto jedoch weitere Regionen verfügbar sind, werden die Vorgänge an die nächste Region in der Liste der Konten weitergeleitet.	Nein
Azure Cosmos DB	Umfangreiche Drosselung aufgrund fehlender RUs	Abhängig von der RU-Anzahl und dem Lastenausgleich auf Front Door-Ebene sind bestimmte Stempel bei der Azure Cosmos DB-Nutzung möglicherweise stark ausgelastet, während andere Stempel mehr Anforderungen bewältigen können. Behandlung: Bessere Lastverteilung oder mehr RUs	Nein
Azure Cosmos DB	Partition voll	Die Größenbeschränkung für logische Azure Cosmos DB-Partitionen beträgt 20 GB. Wenn Daten für einen Partitionsschlüssel innerhalb eines Containers diese Größe erreichen, schlagen zusätzliche Schreibanforderungen mit dem Fehler "Partitionsschlüssel hat die maximale Größe erreicht" fehl.	Teilweise (DB-Schreibvorgänge deaktiviert)
Azure Container Registry	Regionaler Ausfall	Die Containerregistrierung verwendet Traffic Manager für Failover zwischen Replikatregionen. Jede Anforderung sollte automatisch in eine andere Region umgeleitet werden. Im schlimmsten Fall rufen AKS-Knoten Docker-Images einige Minuten lang nicht ab, während das DNS-Failover auftritt.	Nein
Azure Container Registry	Bild oder Bilder gelöscht	Es können keine Images gepullt werden. Dieser Ausfall wirkt sich in der Regel nur auf neu erzeugte bzw. auf neu gestartete Knoten aus. Vorhandene Knoten sollten über zwischengespeicherte Images verfügen. **Behandlung: Wenn nach der Erkennung schnell die neuesten Buildpipelines erneut ausgeführt werden, sollten die Images wieder in der Registrierung verfügbar sein.	Nein
Azure Container Registry	Drosselung	Die Drosselung kann Scale-out-Vorgänge verzögern, was zu einer vorübergehenden Leistungseinbuße führen kann. Schadensbegrenzung: Azure Mission-Critical verwendet die Premium-SKU, die 10.000 Lesevorgänge pro Minute bereitstellt. Container-Images sind optimiert und haben nur eine geringe Anzahl von Layern. ImagePullPolicy ist auf IfNotPresent festgelegt, um zuerst lokal zwischengespeicherte Versionen zu verwenden. Kommentar: Das Pullen eines Container-Images besteht aus mehreren Lesevorgängen, abhängig von der Anzahl der Ebenen. Die Anzahl der Lesevorgänge pro Minute ist begrenzt und hängt von der ACR-SKU-Größe ab.	Nein
Azure Kubernetes Service	Clusterupgradefehler	AKS-Knotenupgrades sollten zu unterschiedlichen Zeiten für die Stempel durchgeführt werden. Ein nicht erfolgreiches Upgrade sollte keine Auswirkungen auf den anderen Cluster haben. Clusterupgrades sollten nach und nach für die Knoten bereitgestellt werden, um zu verhindern, dass alle Knoten nicht mehr verfügbar sind.	Nein
Azure Kubernetes Service	Bei der Verarbeitung einer Anforderung wird der Anwendungspod beendet.	Dieses Ergebnis könnte dazu führen, dass Endbenutzer Fehler und schlechte Benutzererfahrung aufweisen. Schadensbegrenzung: Kubernetes entfernt Pods standardmäßig auf elegante Weise. Pods werden zuerst aus den Diensten entfernt und die Workload erhält ein SIGTERM mit einer Nachfrist, um offene Anfragen abzuschließen und Daten zu schreiben, bevor sie beendet wird. Der Anwendungscode muss SIGTERM verstehen, und die Kulanzfrist muss möglicherweise angepasst werden, wenn das Herunterfahren der Workload länger dauert.	Nein
Azure Kubernetes Service	In der Region steht nicht genügend Computekapazität zur Verfügung, um weitere Knoten hinzuzufügen.	Das vertikale hochskalieren von Operationen schlägt fehl, sollte aber keine Auswirkungen auf bestehende Knoten und deren Betrieb haben. Im Idealfall wird Datenverkehr zum Lastenausgleich automatisch in andere Regionen verlagert.	Nein
Azure Kubernetes Service	Abonnement erreicht CPU-Kernkontingent für das Hinzufügen neuer Knoten.	Das vertikale hochskalieren von Operationen schlägt fehl, sollte aber keine Auswirkungen auf bestehende Knoten und deren Betrieb haben. Im Idealfall wird Datenverkehr zum Lastenausgleich automatisch in andere Regionen verlagert.	Nein
Azure Kubernetes Service	TLS/SSL-Zertifikate von Let‘s Encrypt können nicht ausgestellt/verlängert werden.	Der Cluster sollte Front Door einen fehlerhaften Zustand melden, und der Datenverkehr sollte auf andere Stempel verlagert werden. Behandlung: Untersuchen Sie die Grundursache des Ausstellungs-/Verlängerungsfehlers.	Nein
Azure Kubernetes Service	Wenn Ressourcenanforderungen/-grenzwerte falsch konfiguriert sind, können Pods eine CPU-Auslastung von 100 Prozent erreichen und keine Anforderungen mehr verarbeiten. Nicht erfolgreiche Anforderungen sollten durch den Wiederholungsmechanismus der Anwendung nachgeholt werden können. Wiederholungen können zu einer längeren Anforderungsdauer führen, ohne dass der Client auf den Fehler aufmerksam wird. Übermäßige Belastung führt schließlich zu einem Ausfall.	Nein (bei nicht übermäßiger Belastung)
Azure Kubernetes Service	Containerimages von Drittanbietern oder Registrierung nicht verfügbar	Einige Komponenten wie cert-manager und ingress-nginx erfordern das Herunterladen von Container-Images und Helm-Charts von externen Containerregistrierungen (ausgehender Datenverkehr). Falls mindestens eins dieser Repositorys oder Bilder nicht verfügbar ist, können neue Instanzen auf neuen Knoten (in denen das Bild noch nicht zwischengespeichert ist) möglicherweise nicht gestartet werden. Mögliche Behebung: In einigen Szenarien könnte es Sinn ergeben, Container Images von Drittanbietern in die Container Registry pro Lösung zu importieren. Dieses Szenario erhöht zusätzliche Komplexität und sollte sorgfältig geplant und operationalisiert werden.	Teilweise (während Skalierungs- und Aktualisierungs- bzw. Upgradevorgängen)
Event Hub	Nachrichten können nicht an Event Hubs gesendet werden.	Der Stempel kann nicht mehr für Schreibvorgänge verwendet werden. Der Integritätsdienst sollte dieses Problem automatisch erkennen und den Stempel aus der Rotation entfernen.	Nein
Event Hub	Nachrichten können von BackgroundProcessor nicht gelesen werden.	Nachrichten stehen in der Warteschlange. Nachrichten sollten nicht verloren gehen, da sie gespeichert werden. Dieser Fehler wird derzeit nicht vom Integritätsdienst abgedeckt. Es sollte eine Überwachung/Warnung für den Worker vorhanden sein, um Fehler beim Lesen von Nachrichten zu erkennen. Behandlung: Der Stempel sollte manuell deaktiviert werden, bis das Problem behoben wurde.	Nein
Speicherkonto	Das Speicherkonto kann vom Worker nicht mehr für die Erstellung von Event Hubs-Prüfpunkten verwendet werden.	Stamp verarbeitet keine Nachrichten von den Event Hubs. Das Speicherkonto wird auch von HealthService verwendet. Der HealthService erkennt Storage-Probleme und sollte die Stamp aus der Rotation nehmen. Es kann erwartet werden, dass andere Dienste im Stempel gleichzeitig betroffen sind.	Nein
Speicherkonto	Probleme für statische Website	Wenn bei der statischen Website Probleme auftreten, erkennt Front Door diesen Fehler. Der Datenverkehr wird nicht an dieses Speicherkonto gesendet. Dieses Problem kann auch durch Zwischenspeichern in Front Door entschärft werden.	Nein
Schlüsseltresor	Key Vault für Vorgänge vom Typ GetSecret nicht verfügbar	Beim Start neuer Pods holt der AKS CSI-Treiber alle Secrets aus dem Key Vault und schlägt fehl. Die Pods können nicht gestartet werden. Derzeit wird alle fünf Minuten ein automatisches Update ausgeführt. Das Update schlägt fehl. In kubectl describe pod sollten Fehler angezeigt werden, der Pod funktioniert aber weiterhin.	Nein
Schlüsseltresor	Key Vault für Vorgänge vom Typ GetSecret oder SetSecret nicht verfügbar	Neue Bereitstellungen können nicht ausgeführt werden. Dieser Fehler führt derzeit ggf. dazu, dass die gesamte Bereitstellungspipeline beendet wird, auch wenn nur eine einzelne Region betroffen ist.	Nein
Schlüsseltresor	Key Vault-Drosselung	Key Vault hat eine Grenze von 1.000 Vorgängen pro 10 Sekunden. Aufgrund der automatischen Aktualisierung von Geheimnissen kann dieser Grenzwert theoretisch erreicht werden, wenn ein Stempel zahlreiche (tausende) Pods enthält. Behandlungsmöglichkeit: Verringern Sie die Häufigkeit der Aktualisierung noch weiter, oder deaktivieren Sie sie vollständig.	Nein
Anwendung	Fehlkonfiguration	Einfügung falscher Verbindungszeichenfolgen oder Geheimnisse in die App Entschärft durch automatisierte Bereitstellung (Pipeline übernimmt die Konfiguration automatisch) und blaugrüner Rollout von Updates.	Nein
Anwendung	Abgelaufene Anmeldeinformationen (Stempelressource)	Wenn beispielsweise das EVENT Hub SAS-Token oder speicherkontoschlüssel geändert wurde, ohne sie ordnungsgemäß im Key Vault zu aktualisieren, damit die Pods sie verwenden können, schlägt die entsprechende Anwendungskomponente fehl. Dieser Fehler wirkt sich dann voraussichtlich auf den Integritätsdienst aus, und der Stempel sollte automatisch aus der Rotation entfernt werden. Entschärfung: Verwenden Sie die Microsoft Entra ID-basierte Authentifizierung für alle Dienste, die sie unterstützen. AKS erfordert Pods zum Authentifizieren mithilfe von Microsoft Entra Workload ID (Vorschau). Es wurde überlegt, die Podidentität in der Referenzimplementierung einzusetzen. Die Podidentität ist derzeit jedoch nicht stabil genug, und es wurde beschlossen, sie für die aktuelle Referenzarchitektur nicht zu verwenden. Die Podidentität kann ggf. später einmal eine Lösung sein.	Nein
Anwendung	Abgelaufene Anmeldeinformationen (global freigegebene Ressource)	Wenn der Azure Cosmos DB-API-Schlüssel beispielsweise geändert wurde, ohne eine ordnungsgemäße Aktualisierung in allen Key Vaults vorzunehmen, damit die Pods ihn verwenden können, schlagen die entsprechenden Anwendungskomponenten fehl. Dieser Fehler würde dazu führen, dass alle Stempel gleichzeitig ausfallen, und hätte einen workloadweiten Ausfall zur Folge. Informationen zu einer möglichen Umgehung der erforderlichen Verwendung von Schlüsseln und Geheimnissen mithilfe der Microsoft Entra-Authentifizierung finden Sie im vorherigen Element.	Vollständig
Virtuelles Netzwerk	Subnetz-IP-Adressraum erschöpft	Wenn der IP-Adressraum in einem Subnetz erschöpft ist, können keine Skalierungsvorgänge ausgeführt werden, z. B. das Erstellen neuer AKS-Knoten oder Pods. Ein Ausfall tritt nicht auf, aber die Leistung kann beeinträchtigt werden und dadurch die Benutzererfahrung beeinflussen. Abhilfe: Vergrößern Sie den IP-Bereich (falls möglich). Wenn dies keine Option ist, kann es hilfreich sein, die Ressourcen pro Knoten (größere VM-SKUs) oder pro Pod (mehr CPU/Arbeitsspeicher) zu erhöhen, damit jeder Pod mehr Datenverkehr verarbeiten kann, wodurch der Bedarf an Skalierung verringert wird.	Nein

Nächste Schritte

Stellen Sie die Referenzimplementierung bereit, um ein umfassendes Verständnis der Ressourcen und ihrer Konfiguration in dieser Architektur zu erhalten.

Implementierung: Mission-Critical Online