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 Computecluster ausgefallen ist, reagiert der Integritätsdienst 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. Die Nachricht wird vom Hintergrundworker herausgefiltert.

• 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 Zwischenspeicherungsmuster ist wichtig, da die Anzahl von HealthService-Abfragen bei Verwendung eines globalen Routers wie Azure Front Door erheblich zunimmt: Jeder Edgeknoten in jedem Azure-Rechenzentrum, das Anforderungen verarbeitet, ruft den Integritätsdienst auf, um zu ermitteln, ob eine funktionierende Back-End-Verbindung besteht. 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. Nach dieser Datei wird von der Integritätsprüfung gesucht.
HealthServiceOverallTimeoutSeconds	Timeout für die gesamte Überprüfung (Standardwert: drei 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.

Die Ergebnisse werden im Arbeitsspeicher zwischengespeichert. Hierzu wird der standardmäßige, nicht verteilte Cachespeicher (MemoryCache) von ASP.NET Core verwendet. Der Cacheablauf wird durch SysConfig.HealthServiceCacheDurationSeconds gesteuert und ist standardmäßig auf zehn Sekunden festgelegt.

Hinweis

Die Konfigurationseinstellung SysConfig.HealthServiceCacheDurationSeconds verringert die zusätzliche Last, die durch Integritätsprüfungen entsteht, da nicht jede Anforderung einen nachgelagerten Aufruf der abhängigen Dienste nach sich zieht.

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. Manuelles Deaktivieren einer Region durch Löschen der Statusdatei Die Überprüfung wurde so gestaltet, dass nur die Anwesenheit einer Statusdatei im angegebenen Blobcontainer überprüft wird. 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. Wenn die Statusdatei entfernt wird, wird der Stempel deaktiviert. Vergewissern Sie sich nach dem Bereitstellen der Anwendung, dass die Integritätsdatei vorhanden ist. Andernfalls gibt der Dienst immer FEHLERHAFT zurück. Front Door erkennt nicht, dass das Back-End verfügbar ist. Die Datei wird von Terraform erstellt und muss nach der Infrastrukturbereitstellung vorhanden sein.
Event Hub	Die Integritätsberichterstellung für Event Hubs wird von EventHubProducerService durchgeführt. 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	Die Integritätsberichterstellung für Azure Cosmos DB wird von CosmosDbService durchgeführt. Dieser Dienst meldet einen fehlerfreien Zustand, wenn Folgendes erfüllt 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. Für das Testdokument ist eine kurze Gültigkeitsdauer festgelegt, und es wird automatisch von Azure Cosmos DB entfernt. 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 apply hinzugefü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 detailliertere Daten zu Pods, Bereitstellungen und Diensten sowie zur allgemeinen Clusterintegrität. 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-Telemetriedaten: Application Insights wird verwendet, um Telemetriedaten aus der Anwendung zu sammeln. Der Code wurde instrumentiert, um mit dem Application Insights SDK Daten zur Leistung der Anwendung 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. Wenn Sie die Eingangsdatenpunkte der Cluster direkt aufrufen möchten, müssen die Anforderungen über den korrekten Front Door-ID-Header verfügen. Andernfalls werden sie vom Eingangsdatencontroller abgelehnt.

• 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

Zur Visualisierung der Ergebnisse unserer Log Analytics-Integritätsabfragen wird in unserer Referenzimplementierung Grafana verwendet. Grafana wird zum Anzeigen der Ergebnisse von Log Analytics-Abfragen genutzt und enthält selbst keinerlei Logik. Der Grafana-Stapel ist nicht Teil des Bereitstellungslebenszyklus der Lösung, sondern wird separat veröffentlicht.

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. Durch die Simulation der hier definierten Fehlermodi können wir die Resilienz der Lösung gegenüber diesen Fehlern überprüfen, um sicherzustellen, dass sie nicht zu Ausfällen führen.

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

Dienst	Risiko	Auswirkungen/Behandlung/Kommentar	Outage
Microsoft Entra ID	Microsoft Entra ID ist nicht mehr verfügbar.	Derzeit gibt es keine Behandlungsmöglichkeit. Ein Ansatz mit mehreren Regionen hilft nicht gegen Ausfälle, da es sich um einen globalen Dienst handelt. 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. Es wird erwartet, dass vorhandene, ausgeführte Komponenten weiter ausgeführt werden können, wenn Probleme mit Microsoft Entra ID auftreten. Neue Pods oder AKS-Knoten können wahrscheinlich nicht erzeugt werden. 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 mehr verfügbar ist, ist die DNS-Auflösung für Benutzeranforderungen sowie zwischen verschiedenen Komponenten der Anwendung wahrscheinlich nicht erfolgreich. Derzeit gibt es keine Behandlungsmöglichkeit für dieses Szenario. Ein Ansatz mit mehreren Regionen hilft nicht gegen Ausfälle, da es sich um einen globalen Dienst handelt. 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, kommt es 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. Die Website funktioniert zwar weiterhin, aufgrund von TLS/SSL-Zertifikatfehlern können Benutzer jedoch nicht 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 weitere Schreibanforderungen mit dem Fehler „Partitionsschlüssel hat 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 können Docker-Images während des DNS-Failovers einige Minuten lang nicht von AKS-Knoten gepullt werden.	No
Azure Container Registry	Gelöschte Images	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.	No
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.	No
Azure Kubernetes Service	Bei der Verarbeitung einer Anforderung wird der Anwendungspod beendet.	Dies könnte dazu führen, dass Endbenutzer mit Fehlern und einer schlechten Benutzererfahrung konfrontiert werden. 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.	Vorgänge zum Hoch-/Aufskalieren sind nicht erfolgreich. Bereits vorhandene Knoten und deren Betrieb sollten davon jedoch nicht betroffen sein. Im Idealfall wird Datenverkehr zum Lastenausgleich automatisch in andere Regionen verlagert.	No
Azure Kubernetes Service	Abonnement erreicht CPU-Kernkontingent für das Hinzufügen neuer Knoten.	Vorgänge zum Hoch-/Aufskalieren sind nicht erfolgreich. Bereits vorhandene Knoten und deren Betrieb sollten davon jedoch nicht betroffen sein. Im Idealfall wird Datenverkehr zum Lastenausgleich automatisch in andere Regionen verlagert.	No
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. Eine übermäßige Auslastung führt letztendlich zu einem Fehler.	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 eines oder mehrere dieser Repositorys oder Images nicht verfügbar sind, können neue Instanzen auf neuen Knoten (wo das Image noch nicht zwischengespeichert ist) möglicherweise nicht gestartet werden. Mögliche Abhilfe: In einigen Szenarien kann es sinnvoll sein, Container-Images von Drittanbietern in die Containerregistrierung pro Lösung zu importieren. Dies fügt zusätzliche Komplexität hinzu 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 werden in die Warteschlange eingereiht. 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.	No
Speicherkonto	Das Speicherkonto kann vom Worker nicht mehr für die Erstellung von Event Hubs-Prüfpunkten verwendet werden.	Der Stempel verarbeitet keine Nachrichten von Event Hubs. Das Speicherkonto wird auch von HealthService verwendet. Probleme mit dem Speicher sollten von HealthService erkannt werden, und der Stempel sollte aus der Rotation entfernt werden. Es ist damit zu rechnen, dass weitere Dienste im Stempel ebenfalls betroffen sind.	Nein
Speicherkonto	Probleme für statische Website	Wenn bei der Bereitstellung der statischen Website Probleme auftreten, sollte dieser Fehler von Front Door erkannt werden. Es wird kein Datenverkehr 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 Starten neuer Pods ruft der AKS-CSI-Treiber alle Geheimnisse aus Key Vault ab, und es tritt ein Fehler auf. Pods können nicht gestartet werden. Derzeit wird alle fünf Minuten ein automatisches Update ausgeführt. Das Update ist nicht erfolgreich. 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	Für Key Vault gilt ein Grenzwert von 1.000 Vorgängen pro zehn 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 Sollte durch die automatisierte Bereitstellung (automatische Behandlung der Konfiguration durch die Pipeline) und durch Blau-Grün-Rollouts von Updates behandelt werden.	Nein
Anwendung	Abgelaufene Anmeldeinformationen (Stempelressource)	Wenn beispielsweise das Event Hub-SAS-Token oder der Speicherkontoschlüssel geändert wurde, ohne es bzw. ihn ordnungsgemäß in Key Vault zu aktualisieren, sodass es bzw. er von den Pods verwendet werden kann, tritt für die entsprechende Anwendungskomponente ein Fehler auf. 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 beispielsweise der Azure Cosmos DB-API-Schlüssel geändert wurde, ohne ihn ordnungsgemäß in allen stempelbezogenen Key Vault-Instanzen zu aktualisieren, damit sie von den Pods verwendet werden können, tritt für die entsprechenden Anwendungskomponenten ein Fehler auf. 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.	Vollzugriff
Virtuelles Netzwerk	Subnetz-IP-Adressraum erschöpft	Wenn der IP-Adressraum in einem Subnetz erschöpft ist, können keine Aufskalierungsvorgänge wie das Erstellen neuer AKS-Knoten oder -Pods ausgeführt werden. Dies führt nicht zu einem Ausfall, kann jedoch die Leistung beeinträchtigen und die Benutzererfahrung beeinträchtigen. 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, sodass jeder Pod mehr Datenverkehr bewältigen kann, wodurch die Notwendigkeit einer horizontalen 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