Statusmodellering voor bedrijfskritieke workloads

De bewaking van toepassingen en infrastructuur is een belangrijk onderdeel van elke infrastructuurimplementatie. Voor een bedrijfskritieke workload is bewaking een essentieel onderdeel van de implementatie. Door toepassingsstatus en belangrijke metrische gegevens van Azure-resources te bewaken, kunt u zien of de omgeving werkt zoals verwacht.

Om deze metrische gegevens volledig te begrijpen en de algehele status van een workload te evalueren, is een holistisch begrip van alle bewaakte gegevens vereist. Een statusmodel kan helpen bij de evaluatie van de algehele status door een duidelijke indicatie weer te geven van de status van de workload in plaats van onbewerkte metrische gegevens. De status wordt vaak weergegeven als 'verkeerslichtindicatoren', zoals rood, groen of geel. Weergave van een statusmodel met duidelijke indicatoren maakt het intuïtief voor een operator om de algehele status van de workload te begrijpen en snel te reageren op problemen die zich voordoen.

Statusmodellering kan worden uitgebreid naar de volgende operationele taken voor de bedrijfskritieke implementatie:

• Application Health Service : toepassingsonderdeel op het rekencluster dat een API biedt om de status van een stempel te bepalen.

• Bewaking : verzameling van prestatie- en toepassingstellers die de status en prestaties van de toepassing en infrastructuur evalueren.

• Waarschuwingen: bruikbare waarschuwingen voor problemen of storingen in de infrastructuur en toepassing.

• Foutanalyse - Uitsplitsing en analyse van eventuele fouten, inclusief documentatie over de hoofdoorzaak.

Deze taken vormen een uitgebreid statusmodel voor de bedrijfskritieke infrastructuur. De ontwikkeling van een gezondheidsmodel kan en moet een volledig en integraal onderdeel zijn van elke bedrijfskritieke implementatie.

Zie Statusmodellering en waarneembaarheid van bedrijfskritieke workloads in Azure voor meer informatie.

Application Health Service

Application Health Service (HealthService) is een toepassingsonderdeel dat zich in het rekencluster bevindt met de catalogusservice (CatalogService) en de achtergrondprocessor (BackgroundProcessor). HealthService biedt een REST API voor Azure Front Door om de status van een stempel te bepalen. HealthService is een complex onderdeel dat de status van afhankelijkheden weerspiegelt, naast de eigen.

Wanneer het rekencluster niet beschikbaar is, reageert de health-service niet. Wanneer de services actief zijn, worden periodieke controles uitgevoerd op de volgende onderdelen in de infrastructuur:

• Er wordt geprobeerd een query uit te voeren op Azure Cosmos DB.

• Er wordt geprobeerd een bericht naar Event Hubs te verzenden. Het bericht wordt uitgefilterd door de achtergrondmedewerker.

• Er wordt een statusbestand in het opslagaccount gezocht. Dit bestand kan worden gebruikt om een regio uit te schakelen, zelfs als de andere controles nog steeds correct werken. Dit bestand kan worden gebruikt om te communiceren met andere processen. Als de stempel bijvoorbeeld moet worden verwijderd voor onderhoudsdoeleinden, kan het bestand worden verwijderd om een beschadigde status af te dwingen en verkeer om te leiden.

• Er wordt een query uitgevoerd op het statusmodel om te bepalen of alle operationele metrische gegevens binnen de vooraf vastgestelde drempelwaarden vallen. Wanneer het statusmodel aangeeft dat de stempel beschadigd is, mag het verkeer niet worden doorgestuurd naar de stempel, ook al worden de andere tests die de HealthService uitvoert, met succes geretourneerd. Het statusmodel bekijkt een vollediger overzicht van de status.

Alle statuscontroleresultaten worden gedurende een configureerbaar aantal seconden in de cache opgeslagen in de cache, standaard 10. Deze bewerking voegt mogelijk een kleine latentie toe bij het detecteren van storingen, maar zorgt ervoor dat niet elke HealthService-query back-end-aanroepen vereist, waardoor de belasting van het cluster en downstreamservices wordt verminderd.

Dit cachepatroon is belangrijk, omdat het aantal HealthService-query's aanzienlijk toeneemt bij het gebruik van een globale router, zoals Azure Front Door: Elk edge-knooppunt in elk Azure-datacenter dat aanvragen verwerkt, roept Health Service aan om te bepalen of deze een functionele back-endverbinding heeft. Het opslaan van de resultaten vermindert extra clusterbelasting die wordt gegenereerd door statuscontroles.

Configuration

De HealthService en de CatalogService hebben configuratie-instellingen die gemeenschappelijk zijn tussen de onderdelen, met uitzondering van de volgende instellingen die uitsluitend door de HealthService worden gebruikt:

Instelling	Waarde
HealthServiceCacheDurationSeconds	Hiermee bepaalt u de verlooptijd van de geheugencache in seconden.
HealthServiceStorageConnectionString	Verbinding maken tekenreeks voor het opslagaccount waar het statusbestand aanwezig moet zijn.
HealthServiceBlobContainerName	Opslagcontainer waarin het statusbestand aanwezig moet zijn.
HealthServiceBlobName	Naam van het statusbestand: statuscontrole zoekt naar dit bestand.
HealthServiceOverallTimeoutSeconds	Time-out voor de hele controle: de standaardwaarde is 3 seconden. Als de controle niet binnen dit interval is voltooid, rapporteert de service een slechte status.

Implementatie

Alle controles worden asynchroon en parallel uitgevoerd. Als een van beide mislukt, wordt het hele stempel beschouwd als niet beschikbaar.

Controleer of de resultaten in de cache worden opgeslagen in het geheugen, met behulp van de standaard, niet-gedistribueerde ASP.NET Core MemoryCache. De verlooptijd van de cache wordt beheerd door SysConfig.HealthServiceCacheDurationSeconds en is standaard ingesteld op 10 seconden.

Notitie

De SysConfig.HealthServiceCacheDurationSeconds configuratie-instelling vermindert de extra belasting die wordt gegenereerd door statuscontroles, omdat niet elke aanvraag leidt tot downstream-aanroep van de afhankelijke services.

In de volgende tabel worden de statuscontroles voor de onderdelen in de infrastructuur weergegeven:

Onderdeel	Statuscontrole
Blob van opslagaccount	De blobcontrole dient momenteel twee doeleinden: 1. Test of het mogelijk is om Blob Storage te bereiken. Het opslagaccount wordt gebruikt door andere onderdelen in de stempel en wordt beschouwd als een kritieke resource. 2. Schakel een regio handmatig uit door het statusbestand te verwijderen. Er is een ontwerpbeslissing genomen dat de controle alleen zou zoeken naar een aanwezigheid van een statusbestand in de opgegeven blobcontainer. De inhoud van het bestand wordt niet verwerkt. Er is een mogelijkheid om een geavanceerder systeem in te stellen dat de inhoud van het bestand leest en een andere status retourneert op basis van de inhoud van het bestand. Voorbeelden van inhoud zijn IN ORDE, BESCHADIGD en ONDERHOUD. Als u het statusbestand verwijdert, wordt de stempel uitgeschakeld. Zorg ervoor dat het statusbestand aanwezig is na het implementeren van de toepassing. Het ontbreken van het statusbestand zorgt ervoor dat de service altijd reageert met SLECHTE STATUS. Front Door herkent de back-end niet als beschikbaar. Het bestand wordt gemaakt door Terraform en moet aanwezig zijn na de implementatie van de infrastructuur.
Event Hub	Event Hubs-statusrapportage wordt verwerkt door de EventHubProducerService. Deze service rapporteert in orde als het een nieuw bericht naar Event Hubs kan verzenden. Voor het filteren heeft dit bericht een identificatie-eigenschap toegevoegd: HEALTHCHECK=TRUE dit bericht wordt genegeerd aan het ontvangende einde. De AlwaysOn.BackgroundProcessor.EventHubProcessorService.ProcessEventHandlerAsync() configuratie-instelling controleert op de HEALTHCHECK eigenschap.
Azure Cosmos DB	Azure Cosmos DB-statusrapportage wordt verwerkt door de CosmosDbServicestatusrapportage, die in orde is als dit het volgende is: 1. Kan verbinding maken met de Azure Cosmos DB-database en een query uitvoeren. 2. Kan een testdocument naar de database schrijven. Het testdocument heeft een korte Time-to-Live-set. Azure Cosmos DB verwijdert het automatisch. HealthService voert twee afzonderlijke tests uit. Als Azure Cosmos DB zich in een status bevindt waarin leesbewerkingen en schrijfbewerkingen niet werken, zorgen de twee tests ervoor dat er een waarschuwing wordt geactiveerd.

Azure Cosmos DB-query's

Voor de alleen-lezenquery wordt de volgende query gebruikt, die geen gegevens ophaalt en geen groot effect heeft op de algehele belasting:

SELECT GetCurrentDateTime ()

De schrijfquery maakt een dummy ItemRating met minimale inhoud:

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);

Bewaking

Azure Log Analytics wordt gebruikt als het centrale archief voor logboeken en metrische gegevens voor alle toepassings- en infrastructuuronderdelen. Azure-toepassing Insights wordt gebruikt voor alle bewakingsgegevens van toepassingen. Elke stempel in de infrastructuur heeft een toegewezen Log Analytics-werkruimte en een Application Insights-exemplaar. Er wordt een afzonderlijke Log Analytics-werkruimte gebruikt voor de wereldwijd gedeelde resources, zoals Front Door en Azure Cosmos DB.

Alle stempels worden kortstondige en continu vervangen door elke nieuwe release. De Log Analytics-werkruimten per stempel worden geïmplementeerd als een globale resource in een afzonderlijke bewakingsresourcegroep als de Log Analytics-resources. Deze resources delen niet de levenscyclus van een stempel.

Zie Unified Data Sink voor gecorreleerde analyse voor meer informatie.

Bewaking: gegevensbronnen

• Diagnostische instellingen: alle Azure-services die worden gebruikt voor Azure Mission-Critical, zijn geconfigureerd voor het verzenden van alle diagnostische gegevens, inclusief logboeken en metrische gegevens naar de implementatiespecifieke (globale of stempel) Log Analytics-werkruimte. Dit proces gebeurt automatisch als onderdeel van de Terraform-implementatie. Nieuwe opties worden automatisch geïdentificeerd en toegevoegd als onderdeel van terraform apply.

• Kubernetes-bewaking: Diagnostische instellingen worden gebruikt voor het verzenden van AKS-logboeken en metrische gegevens naar Log Analytics. AKS is geconfigureerd voor het gebruik van Container Insights. Container Insights implementeert de OMSAgentForLinus via een Kubernetes DaemonSet op elk knooppunt in de AKS-clusters. De OMSAgentForLinux kan extra logboeken en metrische gegevens verzamelen vanuit het Kubernetes-cluster en deze verzenden naar de bijbehorende Log Analytics-werkruimte. Deze extra logboeken en metrische gegevens bevatten gedetailleerdere gegevens over pods, implementaties, services en de algehele clusterstatus. Voor meer inzichten uit de verschillende onderdelen, zoals inkomend-nginx, certificaatbeheer en andere onderdelen die zijn geïmplementeerd in Kubernetes naast de bedrijfskritieke workload, is het mogelijk om Prometheus-scraping te gebruiken. Prometheus-scraping configureert de OMSAgentForLinux om prometheus-metrische gegevens van verschillende eindpunten in het cluster te scrapen.

• Application Insights-telemetrie: Application Insights wordt gebruikt om telemetriegegevens van de toepassing te verzamelen. De code is geïnstrueerd om gegevens te verzamelen over de prestaties van de toepassing met de Application Insights SDK. Kritieke informatie, zoals de resulterende statuscode en de duur van afhankelijkheidsaanroepen en tellers voor niet-verwerkte uitzonderingen, worden verzameld. Deze informatie wordt gebruikt in het statusmodel en is beschikbaar voor waarschuwingen en probleemoplossing.

Bewaking: Application Insights-beschikbaarheidstests

Om de beschikbaarheid van de afzonderlijke stempels en de algehele oplossing vanuit een extern oogpunt te bewaken, worden Application Insights-beschikbaarheidstests op twee plaatsen ingesteld:

• Regionale beschikbaarheidstests: Deze tests worden ingesteld in de regionale Application Insights-exemplaren en worden gebruikt om de beschikbaarheid van de stempels te bewaken. Deze tests richten zich rechtstreeks op de clusters en de statische opslagaccounts van de stempels. Als u de ingangspunten van de clusters rechtstreeks wilt aanroepen, moeten aanvragen de juiste Front Door ID-header hebben, anders worden ze geweigerd door de ingangscontroller.

• Wereldwijde beschikbaarheidstest: deze tests worden ingesteld in het globale Application Insights-exemplaar en worden gebruikt om de beschikbaarheid van de algehele oplossing te bewaken door Front Door te pingen. Er worden twee tests gebruikt: een om een API-aanroep te testen op basis van de CatalogService en één om de startpagina van de website te testen.

Bewaking: query's

Azure Mission-Critical maakt gebruik van verschillende KQL-query's (Kusto-querytaal) om aangepaste query's als functies te implementeren om gegevens op te halen uit Log Analytics. Deze query's worden opgeslagen als afzonderlijke bestanden in onze codeopslagplaats, gescheiden voor wereldwijde implementaties en stempelimplementaties. Ze worden automatisch geïmporteerd en toegepast via Terraform als onderdeel van elke pijplijnuitvoering van de infrastructuur.

Deze benadering scheidt de querylogica van de visualisatielaag. De Log Analytics-query's worden rechtstreeks vanuit code aangeroepen, bijvoorbeeld vanuit de HealthService-API. Een ander voorbeeld is van een visualisatieprogramma, zoals Azure Dashboards, Monitor Workbooks of Grafana.

Bewaking: Visualisatie

Voor het visualiseren van de resultaten van onze Log Analytics-statusquery's hebben we Grafana gebruikt in onze referentie-implementatie. Grafana wordt gebruikt om de resultaten van Log Analytics-query's weer te geven en bevat geen logica zelf. De Grafana-stack maakt geen deel uit van de implementatielevenscyclus van de oplossing, maar wordt afzonderlijk uitgebracht.

Zie Visualisatie voor meer informatie.

Waarschuwingen

Waarschuwingen vormen een belangrijk onderdeel van de algehele operationele strategie. Proactieve bewaking, zoals het gebruik van dashboards, moet worden gebruikt met waarschuwingen die onmiddellijk aandacht vestigen op problemen.

Deze waarschuwingen vormen een uitbreiding van het statusmodel door de operator te waarschuwen voor een wijziging in de status, ofwel om de status verslechterd/geel of beschadigd/rood te maken. Door de waarschuwing in te stellen op het hoofdknooppunt van het statusmodel, is de operator onmiddellijk op de hoogte van elk bedrijfsniveau dat van invloed is op de status van de oplossing: dit hoofdknooppunt wordt immers geel of rood als een van de onderliggende gebruikersstromen of resources gele of rode metrische gegevens rapporteert. De operator kan de aandacht vestigen op de visualisatie van het statusmodel voor probleemoplossing.

Zie Automatische reactie op incidenten voor meer informatie.

Foutanalyse

Het opstellen van de foutanalyse is meestal een theoretische planningsoefening. Deze theoretische oefening moet worden gebruikt als invoer voor de geautomatiseerde foutinjecties die deel uitmaken van het continue validatieproces. Door de hier gedefinieerde foutmodi te simuleren, kunnen we de tolerantie van de oplossing valideren op basis van deze fouten om ervoor te zorgen dat ze geen storingen tot stand brengen.

De volgende tabel bevat voorbeeldfouten van de verschillende onderdelen van de Azure Mission-Critical-referentie-implementatie.

Service	Risico	Impact/risicobeperking/opmerking	Uitval
Microsoft Entra-id	Microsoft Entra-id is niet meer beschikbaar.	Momenteel is er geen oplossing mogelijk. Een benadering voor meerdere regio's vermindert geen storingen omdat het een wereldwijde service is. Deze service is een harde afhankelijkheid. Microsoft Entra-id wordt gebruikt voor besturingsvlakbewerkingen, zoals het maken van nieuwe AKS-knooppunten, het ophalen van containerinstallatiekopieën uit ACR of voor toegang tot Key Vault bij het opstarten van pods. Er wordt verwacht dat bestaande, actieve onderdelen kunnen blijven werken wanneer Microsoft Entra ID problemen ondervindt. Het is waarschijnlijk dat nieuwe pods of AKS-knooppunten niet kunnen spawn. In schaalbewerkingen zijn gedurende deze tijd vereist, kan dit leiden tot een verminderde gebruikerservaring en mogelijk tot storingen.	Gedeeltelijke
Azure DNS	Azure DNS wordt niet meer beschikbaar en DNS-omzetting mislukt.	Als Azure DNS niet meer beschikbaar is, zal de DNS-omzetting voor gebruikersaanvragen en tussen verschillende onderdelen van de toepassing waarschijnlijk mislukken. Momenteel is er geen mogelijke beperking voor dit scenario. Een benadering voor meerdere regio's vermindert geen storingen omdat het een wereldwijde service is. Azure DNS is een harde afhankelijkheid. Externe DNS-services als back-up zouden niet helpen, omdat alle PaaS-onderdelen die worden gebruikt, afhankelijk zijn van Azure DNS. Dns omzeilen door over te schakelen naar IP is geen optie. Azure-services hebben geen statische, gegarandeerde IP-adressen.	Volledig
Voordeur	Algemene Storing van Front Door.	Als Front Door helemaal uitvalt, is er geen beperking. Deze service is een harde afhankelijkheid.	Ja
Voordeur	Routerings-/front-end-/back-endconfiguratiefouten.	Dit kan gebeuren als gevolg van niet-overeenkomende configuratie bij het implementeren. Moet worden betrapt in testfasen. Front-endconfiguratie met DNS is specifiek voor elke omgeving. Risicobeperking: Terugdraaien naar de vorige configuratie moet de meeste problemen oplossen. Omdat het enkele minuten duurt voordat wijzigingen in Front Door zijn geïmplementeerd, leidt dit tot een storing.	Volledig
Voordeur	Het beheerde TLS/SSL-certificaat wordt verwijderd.	Dit kan gebeuren als gevolg van niet-overeenkomende configuratie bij het implementeren. Moet worden betrapt in testfasen. Technisch gezien zou de site nog steeds werken, maar TLS/SSL-certificaatfouten verhinderen dat gebruikers er toegang toe hebben. Risicobeperking: het opnieuw uitgeven van het certificaat kan ongeveer 20 minuten duren, plus het herstellen en opnieuw uitvoeren van de pijplijn.	Volledig
Azure Cosmos DB	De naam van de database/verzameling wordt gewijzigd.	Dit kan gebeuren als gevolg van niet-overeenkomende configuratie bij het implementeren: Terraform overschrijft de hele database, wat kan leiden tot gegevensverlies. Gegevensverlies kan worden voorkomen door vergrendelingen op database-/verzamelingsniveau te gebruiken. De toepassing heeft geen toegang tot gegevens. App-configuratie moet worden bijgewerkt en pods opnieuw worden opgestart.	Ja
Azure Cosmos DB	Regionale storing	Azure Mission-Critical heeft schrijfbewerkingen voor meerdere regio's ingeschakeld. Als er een fout optreedt bij een lees- of schrijfbewerking, probeert de client de huidige bewerking opnieuw uit te voeren. Alle toekomstige bewerkingen worden permanent gerouteerd naar de volgende regio in volgorde van voorkeur. Als de voorkeurslijst één vermelding had (of leeg was), maar het account andere regio's beschikbaar heeft, wordt deze doorgestuurd naar de volgende regio in de lijst met accounts.	Nee
Azure Cosmos DB	Uitgebreide beperking vanwege gebrek aan RU's.	Afhankelijk van het aantal RU's en de taakverdeling die op front Door-niveau wordt gebruikt, kunnen bepaalde stempels dynamisch worden uitgevoerd op azure Cosmos DB-gebruik, terwijl andere stempels meer aanvragen kunnen verwerken. Risicobeperking: Betere belastingverdeling of meer RU's.	Nee
Azure Cosmos DB	Partitie volledig	De groottelimiet voor logische partities in Azure Cosmos DB is 20 GB. Als gegevens voor een partitiesleutel binnen een container deze grootte bereiken, mislukken aanvullende schrijfaanvragen met de fout 'Partitiesleutel bereikt maximale grootte'.	Gedeeltelijk (DB-schrijfbewerkingen uitgeschakeld)
Azure Container Registry	Regionale storing	Containerregister maakt gebruik van Traffic Manager om een failover uit te schakelen tussen replicaregio's. Elke aanvraag moet automatisch worden omgeleid naar een andere regio. In het slechtste geval kunnen Docker-installatiekopieën gedurende een paar minuten niet worden opgehaald door AKS-knooppunten terwijl dns-failover plaatsvindt.	Nee
Azure Container Registry	Afbeelding(en) verwijderd	Er kunnen geen afbeeldingen worden opgehaald. Deze storing mag alleen van invloed zijn op nieuw geladen/opnieuw opgestarte knooppunten. Bestaande knooppunten moeten de afbeeldingen in de cache hebben opgeslagen. **Risicobeperking: als wordt gedetecteerd dat de nieuwste build-pijplijnen snel opnieuw worden uitgevoerd, moeten de installatiekopieën weer in het register worden opgenomen.	Nee
Azure Container Registry	Beperking	Beperking kan uitschalen vertragen, wat kan leiden tot een tijdelijk gedegradeerde prestaties. Risicobeperking: Azure Mission-Critical maakt gebruik van de Premium SKU die 10.000 leesbewerkingen per minuut biedt. Containerinstallatiekopieën zijn geoptimaliseerd en hebben slechts kleine aantallen lagen. ImagePullPolicy is ingesteld op IfNotPresent om eerst lokaal opgeslagen versies te gebruiken. Opmerking: het ophalen van een containerinstallatiekopie bestaat uit meerdere leesbewerkingen, afhankelijk van het aantal lagen. Het aantal leesbewerkingen per minuut is beperkt en is afhankelijk van de grootte van de ACR-SKU.	Nee
Azure Kubernetes Service	Clusterupgrade mislukt	AKS Node-upgrades moeten op verschillende tijdstippen worden uitgevoerd op de stempels. Als de ene upgrade mislukt, moet het andere cluster niet worden beïnvloed. Clusterupgrades moeten op rollende wijze worden geïmplementeerd op de knooppunten om te voorkomen dat alle knooppunten niet meer beschikbaar zijn.	Nee
Azure Kubernetes Service	Toepassingspod wordt gedood bij het verwerken van een aanvraag.	Dit kan leiden tot fouten van eindgebruikers en slechte gebruikerservaring. Risicobeperking: Kubernetes verwijdert standaard pods op een elegante manier. Pods worden eerst verwijderd uit services en de workload ontvangt een SIGTERM met een respijtperiode om openstaande aanvragen te voltooien en gegevens te schrijven voordat ze worden beëindigd. De toepassingscode moet sigTERM begrijpen en de respijtperiode moet mogelijk worden aangepast als de workload langer duurt om af te sluiten.	Nee
Azure Kubernetes Service	Rekencapaciteit is niet beschikbaar in de regio om meer knooppunten toe te voegen.	Omhoog/uitschalen mislukt, maar dit moet geen invloed hebben op bestaande knooppunten en de bijbehorende bewerking. In het ideale geval moet verkeer automatisch worden verplaatst naar andere regio's voor taakverdeling.	Nee
Azure Kubernetes Service	Het abonnement bereikt het CPU-kernquotum om nieuwe knooppunten toe te voegen.	Omhoog/uitschalen mislukt, maar dit moet geen invloed hebben op bestaande knooppunten en de bijbehorende bewerking. In het ideale geval moet verkeer automatisch worden verplaatst naar andere regio's voor taakverdeling.	Nee
Azure Kubernetes Service	We kunnen TLS/SSL-certificaten versleutelen niet verlenen/vernieuwen.	Het cluster moet niet in orde zijn in de richting van Front Door en verkeer moet worden verplaatst naar andere stempels. Risicobeperking: onderzoek de hoofdoorzaak van een probleem/vernieuwingsfout.	Nee
Azure Kubernetes Service	Wanneer resourceaanvragen/limieten onjuist zijn geconfigureerd, kunnen pods 100% CPU-gebruik bereiken en mislukte aanvragen. Het mechanisme voor opnieuw proberen van toepassingen moet mislukte aanvragen kunnen herstellen. Nieuwe pogingen kunnen een langere aanvraagduur veroorzaken, zonder dat de fout aan de client wordt weergegeven. Overmatige belasting veroorzaakt uiteindelijk een storing.	Nee (als de belasting niet overmatig is)
Azure Kubernetes Service	Containerinstallatiekopieën van derden/register niet beschikbaar	Voor sommige onderdelen, zoals certificaatbeheer en inkomend verkeer, moeten containerinstallatiekopieën en helm-grafieken worden gedownload vanuit externe containerregisters (uitgaand verkeer). Als een of meer van deze opslagplaatsen of installatiekopieën niet beschikbaar zijn, kunnen nieuwe exemplaren op nieuwe knooppunten (waarbij de installatiekopieën nog niet in de cache zijn opgeslagen) mogelijk niet worden gestart. Mogelijke beperking: in sommige scenario's kan het zinvol zijn om containerinstallatiekopieën van derden te importeren in het containerregister per oplossing. Dit voegt extra complexiteit toe en moet zorgvuldig worden gepland en operationeel worden gemaakt.	Gedeeltelijk (tijdens schaal- en update-/upgradebewerkingen)
Event Hub	Berichten kunnen niet worden verzonden naar de Event Hubs	Stempel wordt onbruikbaar voor schrijfbewerkingen. Health Service moet dit automatisch detecteren en het stempel uit de rotatie halen.	Nee
Event Hub	Berichten kunnen niet worden gelezen door de BackgroundProcessor	Berichten worden in de wachtrij geplaatst. Berichten mogen niet verloren gaan omdat ze behouden blijven. Deze fout wordt momenteel niet gedekt door de Health Service. Er moet bewaking/waarschuwingen worden uitgevoerd op de werkrol om fouten in het lezen van berichten te detecteren. Beperking: De stempel moet handmatig worden uitgeschakeld totdat het probleem is opgelost.	Nee
Opslagaccount	Opslagaccount wordt onbruikbaar door de werkrol voor Event Hubs-controlepunten	Met stempel worden berichten van de Event Hubs niet verwerkt. Het opslagaccount wordt ook gebruikt door de HealthService. Er moeten problemen met de opslag worden gedetecteerd door de HealthService en de stempel moet uit de rotatie worden gehaald. Er kan worden verwacht dat andere services in de stempel gelijktijdig worden beïnvloed.	Nee
Opslagaccount	Statische website ondervindt problemen.	Als het leveren van de statische website problemen ondervindt, moet deze fout worden gedetecteerd door Front Door. Verkeer wordt niet naar dit opslagaccount verzonden. Caching bij Front Door kan dit probleem ook verhelpen.	Nee
Sleutelkluis	Key Vault is niet beschikbaar voor GetSecret bewerkingen.	Aan het begin van nieuwe pods haalt het AKS CSI-stuurprogramma alle geheimen op uit Key Vault en mislukt het. Pods kunnen niet worden gestart. Er is momenteel elke 5 minuten een automatische update. De update mislukt. Fouten moeten worden weergegeven, kubectl describe pod maar de pod blijft werken.	Nee
Sleutelkluis	Key Vault is niet beschikbaar voor GetSecret of SetSecret bewerkingen.	Nieuwe implementaties kunnen niet worden uitgevoerd. Op dit moment kan deze fout ertoe leiden dat de hele implementatiepijplijn wordt gestopt, zelfs als er slechts één regio wordt beïnvloed.	Nee
Sleutelkluis	Beperking van Key Vault	Key Vault heeft een limiet van 1000 bewerkingen per 10 seconden. Vanwege de automatische update van geheimen, kunt u in theorie deze limiet bereiken als u veel (duizenden) pods in een stempel had. Mogelijke beperking: verlaag de updatefrequentie nog verder of schakel deze volledig uit.	Nee
Toepassing	Onjuiste configuratie	Onjuiste verbindingsreeks s of geheimen die zijn geïnjecteerd in de app. Moet worden verzacht door geautomatiseerde implementatie (pijplijn verwerkt configuratie automatisch) en blauwgroene implementatie van updates.	Nee
Toepassing	Verlopen referenties (stempelresource)	Als bijvoorbeeld het SAS-token of de sleutel van het opslagaccount van de Event Hub is gewijzigd zonder deze correct bij te werken in Key Vault, zodat de pods deze kunnen gebruiken, mislukt het respectieve toepassingsonderdeel. Deze fout moet vervolgens van invloed zijn op de Health Service en de stempel moet automatisch uit de rotatie worden gehaald. Risicobeperking: gebruik verificatie op basis van Microsoft Entra ID voor alle services die dit ondersteunen. AKS vereist dat pods worden geverifieerd met behulp van Microsoft Entra Workload-ID (preview). Het gebruik van Pod Identity werd overwogen in de referentie-implementatie. Er is vastgesteld dat Pod Identity momenteel niet stabiel genoeg was en werd besloten om te worden gebruikt voor de huidige referentiearchitectuur. Pod-identiteit kan in de toekomst een oplossing zijn.	Nee
Toepassing	Verlopen referenties (globaal gedeelde resource)	Als de Azure Cosmos DB-API-sleutel bijvoorbeeld is gewijzigd zonder de sleutelkluis correct bij te werken, zodat de pods deze kunnen gebruiken, mislukken de respectieve toepassingsonderdelen. Met deze fout worden alle stempels tegelijkertijd omlaag gestempeld en is er sprake van een storing in de hele workload. Zie het vorige item voor een mogelijke manier om de noodzaak van sleutels en geheimen met Microsoft Entra-verificatie te omzeilen.	Volledig
Virtueel netwerk	Ip-adresruimte van subnet uitgeput	Als de IP-adresruimte op een subnet is uitgeput, kunnen er geen uitschaalbewerkingen plaatsvinden, zoals het maken van nieuwe AKS-knooppunten of pods. Dit leidt niet tot een storing, maar kan de prestaties verminderen en de gebruikerservaring beïnvloeden. Risicobeperking: vergroot de IP-ruimte (indien mogelijk). Als dit geen optie is, kan het helpen om de resources per knooppunt (grotere VM-SKU's) of per pod (meer CPU/geheugen) te verhogen, zodat elke pod meer verkeer kan verwerken, waardoor de behoefte aan uitschalen wordt verminderd.	Nee

Volgende stappen

Implementeer de referentie-implementatie om volledig inzicht te krijgen in de resources en de configuratie die in deze architectuur wordt gebruikt.

Implementatie: Bedrijfskritiek online