Hälsomodellering för verksamhetskritiska arbetsbelastningar

Övervakning av program och infrastruktur är en viktig del av alla infrastrukturdistributioner. För en verksamhetskritisk arbetsbelastning är övervakning en viktig del av implementeringen. Övervakning av programmets hälsa och viktiga mått för Azure-resurser hjälper dig att förstå om miljön fungerar som förväntat.

För att fullt ut förstå dessa mått och utvärdera den övergripande hälsan för en arbetsbelastning krävs en holistisk förståelse av alla data som övervakas. En hälsomodell kan hjälpa till med utvärderingen av den övergripande hälsostatusen genom att visa en tydlig indikation på hälsotillståndet för arbetsbelastningen i stället för råmått. Statusen visas ofta som "trafikljus"-indikatorer som röd, grön eller gul. En representation av en hälsomodell med tydliga indikatorer gör det intuitivt för en operatör att förstå arbetsbelastningens övergripande hälsa och snabbt svara på problem som uppstår.

Hälsomodellering kan utökas till följande operativa uppgifter för den verksamhetskritiska distributionen:

• Program Hälsotjänst – Programkomponent i beräkningsklustret som tillhandahåller ett API för att fastställa hälsotillståndet för en stämpel.

• Övervakning – Insamling av prestanda- och programräknare som utvärderar programmets och infrastrukturens hälsa och prestanda.

• Aviseringar – Åtgärdsbara aviseringar om problem eller avbrott i infrastrukturen och programmet.

• Felanalys – Uppdelning och analys av eventuella fel, inklusive dokumentation om rotorsaken.

Dessa uppgifter utgör en omfattande hälsomodell för den verksamhetskritiska infrastrukturen. Utvecklingen av en hälsomodell kan och bör vara en omfattande och integrerad del av alla verksamhetskritiska implementeringar.

Mer information finns i Hälsomodellering och observerbarhet för verksamhetskritiska arbetsbelastningar i Azure.

Applikationshälsotjänst

Applikationshälsotjänsten (HealthService) är en programkomponent som residerar tillsammans med Katalogtjänsten (CatalogService) och Bakgrundsprocessorn (BackgroundProcessor) inom beräkningsklustret. HealthService tillhandahåller ett REST-API för Azure Front Door för att anropa för att fastställa hälsotillståndet för en stämpel. HealthService är en komplex komponent som återspeglar beroendens tillstånd, förutom dess egna.

När beräkningsklustret är nere svarar inte hälsotjänsten. När tjänsterna är igång utför den regelbundna kontroller mot följande komponenter i infrastrukturen:

• Den försöker göra en fråga mot Azure Cosmos DB.

• Den försöker skicka ett meddelande till Event Hubs. Bakgrundsarbetaren filtrerar bort meddelandet.

• Den letar upp en tillståndsfil i lagringskontot. Den här filen kan användas för att inaktivera en region, även om de andra kontrollerna fortfarande fungerar korrekt. Den här filen kan användas för att kommunicera med andra processer. Om stämpeln till exempel ska tömmas i underhållssyfte kan filen tas bort för att tvinga fram ett feltillstånd och dirigera om trafiken.

• Den frågar hälsomodellen för att avgöra om alla driftsmått ligger inom de förutbestämda tröskelvärdena. När hälsomodellen anger att stämpeln är ofrisk ska trafiken inte dirigeras till stämpeln, även om övriga tester från HealthService ger ett positivt resultat. Hälsomodellen tar en mer fullständig vy över hälsostatusen i beräkningen.

Alla hälsokontrollresultat cachelagras i minnet under ett konfigurerbart antal sekunder, som standard 10. Den här åtgärden lägger potentiellt till en liten svarstid vid identifiering av avbrott, men det säkerställer att inte alla HealthService-frågor kräver serverdelsanrop, vilket minskar belastningen på klustret och underordnade tjänster.

Det här cachelagringsmönstret är viktigt eftersom antalet HealthService-frågor ökar avsevärt när du använder en global router som Azure Front Door: Varje gränsnod i varje Azure-datacenter som hanterar begäranden anropar hälsotjänsten för att avgöra om den har en funktionell serverdelsanslutning. Cachelagring av resultaten minskar extra klusterbelastning som genereras av hälsokontroller.

Konfiguration

HealthService och CatalogService har konfigurationsinställningar som är gemensamma mellan komponenterna, förutom följande inställningar som uteslutande används av HealthService:

Inställning	Värde
HealthServiceCacheDurationSeconds	Styr förfallotiden för minnescachen i sekunder.
HealthServiceStorageConnectionString	Anslutningssträng för lagringskontot där statusfilen ska finnas.
HealthServiceBlobContainerName	Lagringscontainer där statusfilen ska finnas.
HealthServiceBlobName	Namnet på statusfilen – hälsokontrollen söker efter den här filen.
HealthServiceOverallTimeoutSeconds	Timeout för hela kontrollen – standardvärdet är 3 sekunder. Om kontrollen inte slutförs i det här intervallet rapporterar tjänsten feltillstånd.

Implementering

Alla kontroller utförs asynkront och parallellt. Om någon av dem misslyckas anses hela stämpeln vara otillgänglig.

Kontrollera att resultaten cachelagras i minnet med hjälp av standard, icke-distribuerad ASP.NET Core MemoryCache. SysConfig.HealthServiceCacheDurationSeconds kontrollerar cache förfallodatum. Standardinställningen är 10 sekunder.

Kommentar

Konfigurationsinställningen SysConfig.HealthServiceCacheDurationSeconds minskar den extra belastning som genereras av hälsokontroller eftersom inte alla begäranden resulterar i nedströmsanrop till de beroende tjänsterna.

Följande tabell beskriver hälsokontrollerna för komponenterna i infrastrukturen:

Komponent	Hälsokontroll
Lagringskontoblob	Blobkontrollen har för närvarande två syften: 1. Testa om det är möjligt att nå Blob Storage. Lagringskontot används av andra komponenter i stämpeln och anses vara en kritisk resurs. 2. "Inaktivera" en region manuellt genom att ta bort tillståndsfilen. Ett designbeslut fattades om att kontrollen bara skulle söka efter en tillståndsfil i den angivna blobcontainern. Innehållet i filen bearbetas inte. Det finns en möjlighet att konfigurera ett mer avancerat system som läser innehållet i filen och returnerar olika status baserat på innehållet i filen. Exempel på innehåll är HEALTHY, UNHEALTHY och MAINTENANCE. Borttagning av tillståndsfilen inaktiverar stämpeln. Kontrollera att hälsofilen finns när du har distribuerat programmet. Frånvaro av hälsofilen gör att tjänsten alltid svarar med UNHEALTHY. Front Door känner inte igen backend som tillgängligt. Terraform skapar filen och ska finnas efter infrastrukturutplaceringen.
Event Hub	Hälsorapporteringen för Event Hubs hanterar EventHubProducerService. Den här tjänsten rapporterar som hälsosam om den kan skicka ett nytt meddelande till Event Hubs. För filtrering har det här meddelandet en identifierande egenskap som lagts till: HEALTHCHECK=TRUE Det här meddelandet ignoreras på mottagarsidan. Inställningen för AlwaysOn.BackgroundProcessor.EventHubProcessorService.ProcessEventHandlerAsync() kontrollerar efter egenskapen HEALTHCHECK.
Azure Cosmos DB	Azure Cosmos DB-hälsorapportering hanterar CosmosDbService, som rapporterar att det är hälsosamt om det är: 1. Det går att ansluta till Azure Cosmos DB-databasen och utföra en fråga. 2. Det går att skriva ett testdokument till databasen. Testdokumentet har en kort livstid inställd. Azure Cosmos DB tar bort det automatiskt. HealthService utför två separata sonderingar. Om Azure Cosmos DB är i ett tillstånd där läsningar fungerar och skrivningar inte gör det, garanterar de två kontrollerna att en avisering utlöses.

Azure Cosmos DB-frågor

För skrivskyddad fråga används följande fråga, som inte hämtar några data och inte påverkar den totala belastningen nämnvärt.

SELECT GetCurrentDateTime ()

Skrivfrågan skapar en dummy ItemRating med minimalt innehåll:

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

Övervakning

Azure Log Analytics används som det centrala arkivet för loggar och mått för alla program- och infrastrukturkomponenter. Azure Application Insights används för alla programövervakningsdata. Varje stämpel i infrastrukturen har en dedikerad Log Analytics-arbetsyta och Application Insights-instans. En separat Log Analytics-arbetsyta används för globalt delade resurser som Front Door och Azure Cosmos DB.

Alla stämplar är kortlivade och ersätts kontinuerligt med varje ny version. Log Analytics-arbetsytorna för varje stämpel distribueras som en global resurs i en separat övervakningsresursgrupp jämställd med stämpelresurser för Log Analytics. Dessa resurser delar inte livscykeln för en stämpel.

Mer information finns i Enhetlig datamottagare för korrelerad analys.

Övervakning: Datakällor

• Diagnostikinställningar: Alla Azure-tjänster som används för Azure Mission-Critical är konfigurerade för att skicka alla diagnostikdata, inklusive loggar och mått till den distributionsspecifika (globala eller stämpel) Log Analytics-arbetsytan. Den här processen sker automatiskt som en del av Terraform-distributionen. Nya alternativ identifieras automatiskt och läggs till som en del av terraform apply.

• Kubernetes-övervakning: Diagnostikinställningar används för att skicka Loggar och mått för Azure Kubernetes Service (AKS) till Log Analytics. AKS har konfigurerats för att använda Container Insights. Container Insights distribuerar OMSAgentForLinus via en Kubernetes DaemonSet på varje nod i AKS-klustren. OMSAgentForLinux kan samla in extra loggar och mått inifrån Kubernetes-klustret och skicka dem till motsvarande Log Analytics-arbetsyta. Dessa extra loggar och mått innehåller mer detaljerade data om poddar, distributioner, tjänster och övergripande klusterhälsa. Om du vill få mer insikter från de olika komponenterna, till exempel ingress-nginx, cert-manager och andra komponenter som distribuerats till Kubernetes bredvid den verksamhetskritiska arbetsbelastningen, är det möjligt att använda Prometheus-skrapning. Prometheus-skrapning konfigurerar OMSAgentForLinux för att skrapa Prometheus-mått från olika slutpunkter i klustret.

• Application Insights-dataövervakning: Application Insights används för att samla in övervakningsdata från programmet. Koden instrumenteras för att samla in data om programmets prestanda med Application Insights SDK. Viktig information, till exempel den resulterande statuskoden och varaktigheten för beroendeanrop och räknare för ohanterade undantag samlas in. Den här informationen används i hälsomodellen och är tillgänglig för aviseringar och felsökning.

Övervakning: Application Insights-tillgänglighetstester

För att övervaka tillgängligheten för enskilda stämplar och den övergripande lösningen utifrån , konfigureras Application Insights-tillgänglighetstester på två platser:

• Regionala tillgänglighetstester: Dessa tester konfigureras i de regionala Application Insights-instanserna och används för att övervaka tillgängligheten för stämplarna. Dessa tester riktar sig direkt till klustren och statiska lagringskonton för stämplarna. För att anropa ingresspunkterna i klustren direkt måste begäranden ha rätt Front Door-ID-huvud, annars avvisar ingresskontrollanten anropen.

• Globalt tillgänglighetstest: Dessa tester konfigureras i den globala Application Insights-instansen och används för att övervaka tillgängligheten för den övergripande lösningen genom att pinga Front Door. Två tester används: Ett för att testa ett API-anrop mot CatalogService och ett för att testa webbplatsens startsida.

Övervakning: Frågor

Azure Mission-Critical använder olika KQL-frågor (Kusto-frågespråk) för att implementera anpassade frågor som funktioner för att hämta data från Log Analytics. Dessa frågor lagras som enskilda filer i vår kodlagringsplats, avgränsade för globala distributioner och stämpeldistributioner. De importeras och tillämpas automatiskt via Terraform som en del av varje infrastrukturpipelinekörning.

Den här metoden skiljer frågelogik från visualiseringsskiktet. Log Analytics-frågorna anropas direkt från kod, till exempel från HealthService-API:et. Ett annat exempel är från ett visualiseringsverktyg som Azure Instrumentpaneler, Monitor-arbetsböcker eller Grafana.

Övervakning: Visualisering

Vi använder Grafana för att visualisera resultatet av våra Log Analytics-hälsofrågor i vår referensimplementering. Grafana visar resultatet av Log Analytics-frågor och innehåller ingen egen logik. Vi släpper Grafana-stacken separat från lösningens distributionslivscykel.

Mer information finns i Visualisering.

Aviseringar

Aviseringar är en viktig del av den övergripande driftsstrategin. Proaktiv övervakning, till exempel användning av instrumentpaneler, bör användas med aviseringar som ger omedelbar uppmärksamhet åt problem.

Dessa aviseringar utgör ett tillägg till hälsomodellen genom att avisera operatorn om en ändring i hälsotillståndet, antingen till degraderat/gult tillstånd eller till felfritt/rött tillstånd. Genom att ställa in aviseringen på rotnoden i hälsomodellen är operatorn omedelbart medveten om alla affärsnivåer som påverkar lösningens tillstånd: Rotnoden blir trots allt gul eller röd om någon av de underliggande användarflödena eller resurserna rapporterar gula eller röda mått. Operatorn kan rikta sin uppmärksamhet mot visualiseringen Hälsomodell för felsökning.

Mer information finns i Automatiserad incidenthantering.

Felanalys

Att skapa felanalysen är främst en teoretisk planeringsövning. Den här teoretiska övningen ska användas som indata för automatiserade felinmatningar som ingår i den kontinuerliga valideringsprocessen. Genom att simulera de fellägen som definieras här kan vi verifiera lösningens återhämtning mot dessa fel för att minimera avbrott.

I följande tabell visas exempel på felfall för de olika komponenterna i referensimplementeringen för Azure Mission-Critical.

Tjänst	Risk	Påverkan/Åtgärder/Kommentar	Avbrott
Microsoft Entra ID	Microsoft Entra-ID blir otillgängligt.	För närvarande finns ingen möjlig åtgärd på plats. En metod för flera regioner minskar inte några avbrott eftersom det är en global tjänst. Den här tjänsten är ett hårt beroende. Microsoft Entra-ID används för kontrollplansåtgärder som att skapa nya AKS-noder, hämta containeravbildningar från ACR eller för att få åtkomst till Key Vault vid poddstart. Befintliga komponenter som körs bör kunna fortsätta köras när Microsoft Entra ID har problem. Det är troligt att nya poddar eller AKS-noder inte kan uppstå. Vid skalningsåtgärder som krävs under den här tiden kan det leda till en minskad användarupplevelse och potentiellt till avbrott.	Delvis
Azure DNS	Azure DNS blir otillgängligt och DNS-matchningen misslyckas.	Om Azure DNS blir otillgängligt misslyckas DNS-matchningen för användarbegäranden och mellan olika komponenter i programmet. För närvarande finns ingen möjlig åtgärd för det här scenariot. En metod för flera regioner minskar inte några avbrott eftersom det är en global tjänst. Azure DNS är ett hårt beroende. Externa DNS-tjänster som säkerhetskopiering skulle inte hjälpa, eftersom alla PaaS-komponenter som används förlitar sig på Azure DNS. Att kringgå DNS genom att växla till IP är inte ett alternativ. Azure-tjänster har inte statiska, garanterade IP-adresser.	Fullständig
Ytterdörr	Allmänt frontdörrsavbrott.	Om Front Door går ner helt, finns det ingen åtgärd. Den här tjänsten är ett hårt beroende.	Ja
Ytterdörr	Konfigurationsfel för routning/frontend/backend.	Kan inträffa på grund av matchningsfel i konfigurationen vid distribution. Bör fångas under testfaserna. Klientdelskonfiguration med DNS är specifik för varje miljö. Åtgärd: Återställning till tidigare konfiguration bör åtgärda de flesta problem.. Eftersom ändringar tar ett par minuter att distribueras i Front Door, resulterar detta i ett avbrott.	Fullständig
Ytterdörr	Hanterat TLS/SSL-certifikat tas bort.	Kan inträffa på grund av matchningsfel i konfigurationen vid distribution. Bör upptäckas i testfaser. Tekniskt sett skulle webbplatsen fortfarande fungera, men TLS/SSL-certifikatfel hindrar användare från att komma åt den. Åtgärd: Det kan ta cirka 20 minuter att utfärda certifikatet igen, samt att åtgärda och köra pipelinen igen..	Fullständig
Azure Cosmos DB	Databasen/samlingen har bytt namn.	Kan inträffa på grund av matchningsfel i konfigurationen vid distribution – Terraform skulle skriva över hela databasen, vilket kan leda till dataförlust. Dataförlust kan förhindras med hjälp av lås på databas-/insamlingsnivå. Programmet kan inte komma åt några data. Appkonfigurationen måste uppdateras och poddar startas om.	Ja
Azure Cosmos DB	Regionalt avbrott	Azure Mission-Critical har skrivningar i flera regioner aktiverade. Om det uppstår ett fel vid läsning eller skrivning försöker klienten utföra den aktuella åtgärden igen. Alla framtida åtgärder dirigeras permanent till nästa region i prioritetsordning. Om inställningslistan hade en post (eller var tom) men kontot har andra tillgängliga regioner dirigeras den till nästa region i kontolistan.	Nej
Azure Cosmos DB	Omfattande begränsning på grund av brist på resursenheter (RU:er).	Beroende på antalet RU:er och belastningsutjämningen som används vid Front Door kan vissa servrar ha hög resursanvändning i Azure Cosmos DB, medan andra servrar kan hantera fler förfrågningar. Åtgärd: Bättre belastningsfördelning eller fler RU:er.	Nej
Azure Cosmos DB	Partitionen är full	Storleksgränsen för logisk partition i Azure Cosmos DB är 20 GB. Om data för en partitionsnyckel i en container når den här storleken misslyckas extra skrivbegäranden med felet "Partitionsnyckeln har nått maximal storlek".	Partiell (DB-skrivningar inaktiverade)
Azure Container Registry	Regionalt avbrott	Containerregistret använder Traffic Manager för att växla över mellan replikaområden. Alla begäranden bör omdirigeras automatiskt till en annan region. I värsta fall hämtar AKS-noder inte Docker-avbildningar under flera minuter medan DNS-omkoppling sker.	Nej
Azure Container Registry	Bild eller bilder borttagna	Inga bilder kan hämtas. Det här avbrottet bör endast påverka nyligen skapade/omstartade noder. Befintliga noder bör ha avbildningarna cachelagrade. Åtgärd: Om det snabbt upptäcks kan omstart av de senaste kompilationspipelines få tillbaka avbildningarna i registret.	Nej
Azure Container Registry	Strypning	Strömbegränsning kan fördröja skalningsoperationer vilket kan leda till tillfälligt försämrad prestanda. Åtgärd: Azure Mission-Critical använder Premium SKU som tillhandahåller 10 000 läsåtgärder per minut. Containeravbildningar är optimerade och har bara ett litet antal lager. ImagePullPolicy är inställt på IfNotPresent för att använda lokalt cachelagrade versioner först. Kommentar: Att hämta en containeravbildning består av flera läsåtgärder, beroende på antalet lager. Antalet läsåtgärder per minut är begränsat och beror på ACR SKU-storleken.	Nej
Azure Kubernetes Service	Klusteruppgradering misslyckas	AKS Node-uppgraderingar bör ske vid olika tidpunkter mellan stämplarna. Om en uppgradering misslyckas ska det andra klustret inte påverkas. Klusteruppgraderingar bör distribueras löpande över noderna för att förhindra att alla noder blir otillgängliga.	Nej
Azure Kubernetes Service	Applikationspoden stoppas när den hanterar en begäran.	Det här resultatet kan leda till att slutanvändare får fel och dålig användarupplevelse. Åtgärd: Kubernetes tar som standard bort poddar på ett graciöst sätt. Poddar tas först bort från tjänster och arbetsbelastningen får en SIGTERM med en respitperiod för att avsluta pågående förfrågningar och skriva data innan de stängs ner. Programkoden måste förstå SIGTERM och respitperioden kan behöva justeras om arbetsbelastningen tar längre tid att stänga av.	Nej
Azure Kubernetes Service	Beräkningskapaciteten är inte tillgänglig i regionen för att lägga till fler noder.	Skalning upp/ut misslyckas, men det bör inte påverka befintliga noder och deras funktion. Helst bör trafiken flyttas automatiskt till andra regioner för belastningsutjämning.	Nej
Azure Kubernetes Service	Prenumerationen når CPU-kärnkvoten för att lägga till nya noder.	Skalning upp/ut misslyckas, men det bör inte påverka befintliga noder och deras funktion. Helst bör trafiken flyttas automatiskt till andra regioner för belastningsutjämning.	Nej
Azure Kubernetes Service	Let's Encrypt TLS/SSL-certifikat kan inte utfärdas/förnyas.	Klustret bör rapportera felfritt mot Front Door och trafiken bör övergå till andra stämplar. Åtgärd: Utred rotorsaken till problemet eller försök åtgärda felet.	Nej
Azure Kubernetes Service	När resursbegäranden/-gränser har konfigurerats felaktigt kan poddar nå 100 % processoranvändning och felbegäranden. Mekanismen för återförsök av program bör kunna återställa misslyckade begäranden. Återförsök kan orsaka en längre svarstid för begäran, utan att felet synliggörs för kunden. Överdriven belastning orsakar till slut fel.	Nej (om belastningen inte är för hög)
Azure Kubernetes Service	Containeravbildningar från tredje part/register är inte tillgängliga	Vissa komponenter som cert-manager och ingress-nginx kräver nedladdning av containeravbildningar och helm-diagram från externa containerregister (utgående trafik). Om en eller flera av dessa lagringsplatser eller bilder inte är tillgängliga kan det hända att nya instanser på nya noder (där avbildningen inte redan är cachelagrad) inte kan starta. Möjlig åtgärd: I vissa scenarier kan det vara bra att importera tredjeparts-containerbilder till det lösningsspecifika containerregistret. Det här scenariot ger extra komplexitet och bör planeras och operationaliseras noggrant.	Delvis (under skalnings- och uppdaterings-/uppgraderingsåtgärder)
Event Hub	Meddelanden kan inte skickas till Händelsehubbar	Stämpeln blir oanvändbar för skrivoperationer. Hälsotjänsten bör automatiskt identifiera detta och ta bort stämpeln från rotationen.	Nej
Event Hub	Meddelanden kan inte läsas av BackgroundProcessor	Meddelanden köar. Meddelanden bör inte gå förlorade eftersom de är beständiga. Det här felet omfattas för närvarande inte av Hälsotjänst. Det bör finnas övervakning/aviseringar på plats för arbetaren för att identifiera fel vid läsning av meddelanden. Åtgärd: Stämpeln ska inaktiveras manuellt tills problemet har åtgärdats.	Nej
Lagringskonto	Lagringskontot blir oanvändbart för arbetaren när det gäller kontrollpunktsprocessen i Event Hubs.	Stamp bearbetar inte meddelanden från Event Hubs. Lagringskontot används också av HealthService. HealthService identifierar lagringsproblem och bör ta bort stämpeln från rotationen. Det kan förväntas att andra tjänster i stämpeln påverkas samtidigt.	Nej
Lagringskonto	Statisk webbplats stöter på problem.	Om den statiska webbplatsen stöter på problem identifierar Front Door det här felet. Trafik skickas inte till det här lagringskontot. Cachelagring på Front Door kan också lindra det här problemet.	Nej
Key Vault	Key Vault är inte tillgängligt för GetSecret åtgärder.	I början av nya poddar hämtar AKS CSI-drivrutinen alla hemligheter från Key Vault men processen misslyckas. Poddar kan inte starta. Det finns en automatisk uppdatering var 5:e minut. Uppdateringen misslyckas. Fel bör visas i kubectl describe pod men podden fortsätter att fungera.	Nej
Key Vault	Key Vault är inte tillgängligt för GetSecret eller SetSecret operationer.	Det går inte att köra nya distributioner. Det här felet kan för närvarande leda till att hela distributionspipelinen stoppas, även om endast en region påverkas.	Nej
Key Vault	Hantering av gränsvärden för Key Vault	Key Vault har en gräns på 1 000 åtgärder per 10 sekunder. På grund av den automatiska uppdateringen av hemligheter kan du i teorin nå den här gränsen om du hade många (tusentals) poddar i en stämpel. Möjlig åtgärd: Minska uppdateringsfrekvensen ytterligare eller inaktivera den helt.	Nej
Applikation	Felaktig konfiguration	Felaktiga anslutningssträng eller hemligheter som matas in i appen. Mildras av automatisk distribution (pipeline hanterar konfiguration automatiskt) och blågrön lansering av uppdateringar.	Nej
Applikation	Utgångna autentiseringsuppgifter (stämpelresurs)	Om till exempel SAS-token eller lagringskontonyckeln för händelsehubben ändrades utan att de uppdaterades korrekt i Key Vault så att poddarna kan använda dem, misslyckas respektive programkomponent. Det här felet bör sedan påverka Vårdtjänsten, och stämpeln ska automatiskt tas ur rotation. Åtgärd: Använd Microsoft Entra ID-baserad autentisering för alla tjänster som stöder det. AKS kräver att poddar autentiserar sig med Microsoft Entra-arbetsbelastnings-ID (förhandsversion). Användning av poddidentitet övervägdes i referensimplementeringen. Det konstaterades att Pod Identity för närvarande inte var tillräckligt stabil och det beslutades att den inte skulle användas för den aktuella referensarkitekturen. Poddidentitet kan vara en lösning i framtiden.	Nej
Applikation	Utgångna autentiseringsuppgifter (globalt delad resurs)	Om till exempel Azure Cosmos DB API-nyckeln ändrades utan att uppdatera den korrekt i alla stämpelnyckelvalv så att poddarna kan använda dem, misslyckas respektive programkomponenter. Det här felet skulle få alla systemkomponenter att stängas av samtidigt och orsaka ett systemutbrott. En möjlig väg runt behovet av nycklar och hemligheter med Microsoft Entra-autentisering finns i föregående objekt.	Fullständig
Virtuellt nätverk	Ip-adressutrymmet för undernätet är slut	Om IP-adressutrymmet i ett undernät är uttömt kan inga utskalningsåtgärder, till exempel att skapa nya AKS-noder eller poddar, ske. Ett avbrott inträffar inte men kan minska prestandan för användarupplevelsen. Åtgärd: öka IP-utrymmet (om möjligt). Om det inte är ett alternativ kan det bidra till att öka resurserna per nod (större VM-SKU:er) eller per podd (mer CPU/minne), så att varje podd kan hantera mer trafik, vilket minskar behovet av utskalning.	Nej

Nästa steg

Distribuera referensimplementeringen för att få en fullständig förståelse för de resurser och deras konfiguration som används i den här arkitekturen.

Implementering: Verksamhetskritisk onlinefunktion