Modellazione dell'integrità per carichi di lavoro cruciali
Il monitoraggio delle applicazioni e dell'infrastruttura è una parte importante di qualsiasi distribuzione dell'infrastruttura. Per un carico di lavoro cruciale, il monitoraggio è una parte fondamentale della distribuzione. Il monitoraggio dell'integrità delle applicazioni e delle metriche chiave delle risorse di Azure consente di comprendere se l'ambiente funziona come previsto.
Per comprendere appieno queste metriche e valutare l'integrità complessiva di un carico di lavoro, è necessaria una comprensione olistica di tutti i dati monitorati. Un modello di integrità può essere utile per valutare lo stato di integrità complessivo visualizzando un'indicazione chiara dell'integrità del carico di lavoro anziché delle metriche non elaborate. Lo stato viene spesso presentato come indicatori di "semaforo", ad esempio rosso, verde o giallo. La rappresentazione di un modello di integrità con indicatori chiari rende intuitivo per un operatore comprendere l'integrità complessiva del carico di lavoro e rispondere rapidamente ai problemi che si verificano.
La modellazione dell'integrità può essere espansa nelle attività operative seguenti per la distribuzione mission-critical:
Application Servizio integrità: componente dell'applicazione nel cluster di calcolo che fornisce un'API per determinare l'integrità di un timbro.
Monitoraggio : raccolta di contatori delle prestazioni e delle applicazioni che valutano l'integrità e le prestazioni dell'applicazione e dell'infrastruttura.
Avvisi: avvisi interattivi di problemi o interruzioni nell'infrastruttura e nell'applicazione.
Analisi degli errori: scomposizione e analisi di eventuali errori, inclusa la documentazione della causa radice.
Queste attività costituiscono un modello di integrità completo per l'infrastruttura mission-critical. Lo sviluppo di un modello di integrità può e deve essere parte integrante di qualsiasi distribuzione mission-critical.
Per altre informazioni, vedere Modellazione dell'integrità e osservabilità dei carichi di lavoro cruciali in Azure.
Servizio integrità dell'applicazione
L'applicazione Servizio integrità (HealthService) è un componente dell'applicazione che risiede con il servizio catalogo (CatalogService) e il processore in background (BackgroundProcessor) all'interno del cluster di calcolo. HealthService fornisce un'API REST per Frontdoor di Azure da chiamare per determinare l'integrità di un timbro. HealthService è un componente complesso che riflette lo stato delle dipendenze, oltre al proprio.
Quando il cluster di calcolo è inattivo, il servizio integrità non risponderà. Quando i servizi sono operativi, esegue controlli periodici sui componenti seguenti nell'infrastruttura:
Tenta di eseguire una query su Azure Cosmos DB.
Tenta di inviare un messaggio a Hub eventi. Il messaggio viene filtrato in base al ruolo di lavoro in background.
Cerca un file di stato nell'account di archiviazione. Questo file può essere usato per disattivare un'area, anche se gli altri controlli funzionano correttamente. Questo file può essere usato per comunicare con altri processi. Ad esempio, se il timbro deve essere liberato a scopo di manutenzione, il file potrebbe essere eliminato per forzare uno stato non integro e reindirizzare il traffico.
Esegue una query sul modello di integrità per determinare se tutte le metriche operative sono entro le soglie predeterminate. Quando il modello di integrità indica che lo stamp non è integro, il traffico non deve essere instradato al timbro anche se gli altri test eseguiti da HealthService restituiscono correttamente. Il modello di integrità prende in considerazione una visualizzazione più completa dello stato di integrità.
Tutti i risultati del controllo integrità vengono memorizzati nella cache per un numero configurabile di secondi, per impostazione predefinita 10. Questa operazione aggiunge potenzialmente una latenza ridotta nel rilevamento delle interruzioni, ma garantisce che non tutte le query di HealthService richiedano chiamate back-end, riducendo così il carico sul cluster e sui servizi downstream.
Questo modello di memorizzazione nella cache è importante perché il numero di query HealthService cresce in modo significativo quando si usa un router globale come Frontdoor di Azure: ogni nodo perimetrale in ogni data center di Azure che gestisce le richieste chiamerà il Servizio integrità per determinare se ha una connessione back-end funzionale. La memorizzazione nella cache dei risultati riduce il carico aggiuntivo del cluster generato dai controlli di integrità.
Impostazione
HealthService e CatalogService hanno impostazioni di configurazione comuni tra i componenti, ad eccezione delle impostazioni seguenti usate esclusivamente da HealthService:
| Impostazione | Valore |
|---|---|
HealthServiceCacheDurationSeconds |
Controlla l'ora di scadenza della cache di memoria, in secondi. |
HealthServiceStorageConnectionString |
Stringa di connessione per l'account di archiviazione in cui deve essere presente il file di stato. |
HealthServiceBlobContainerName |
Contenitore di archiviazione in cui deve essere presente il file di stato. |
HealthServiceBlobName |
Nome del file di stato: il controllo integrità cercherà questo file. |
HealthServiceOverallTimeoutSeconds |
Timeout per l'intero controllo: il valore predefinito è 3 secondi. Se il controllo non viene completato in questo intervallo, il servizio segnala che non è integro. |
Implementazione
Tutti i controlli vengono eseguiti in modo asincrono e in parallelo. Se uno di essi ha esito negativo, l'intero timbro verrà considerato non disponibile.
I risultati del controllo vengono memorizzati nella cache in memoria, usando lo standard ASP.NET Core MemoryCache. La scadenza della cache è controllata da SysConfig.HealthServiceCacheDurationSeconds ed è impostata su 10 secondi per impostazione predefinita.
Nota
L'impostazione SysConfig.HealthServiceCacheDurationSeconds di configurazione riduce il carico aggiuntivo generato dai controlli di integrità perché non tutte le richieste genereranno chiamate downstream ai servizi dipendenti.
Nella tabella seguente vengono descritti in dettaglio i controlli di integrità per i componenti nell'infrastruttura:
| Componente | Controllo integrità |
|---|---|
| BLOB dell'account di archiviazione | Il controllo BLOB attualmente serve due scopi: 1. Verificare se è possibile raggiungere l'archiviazione BLOB. L'account di archiviazione viene usato da altri componenti nel timbro ed è considerato una risorsa critica. 2. Disattivare manualmente un'area eliminando il file di stato. È stata presa una decisione di progettazione che il controllo cerca solo una presenza di un file di stato nel contenitore BLOB specificato. Il contenuto del file non viene elaborato. È possibile configurare un sistema più sofisticato che legge il contenuto del file e restituisce uno stato diverso in base al contenuto del file. Esempi di contenuto sono INTEGRO, NON INTEGRO e MANUTENZIONE. La rimozione del file di stato disabiliterà il timbro. Verificare che il file di integrità sia presente dopo la distribuzione dell'applicazione. L'assenza del file di integrità causerà sempre la risposta del servizio con UNHEALTHY. Frontdoor non riconoscerà il back-end come disponibile. Il file viene creato da Terraform e deve essere presente dopo la distribuzione dell'infrastruttura. |
| Hub eventi | La creazione di report sull'integrità EventHubProducerServicedi Hub eventi viene gestita da . Questo servizio segnala l'integrità se è in grado di inviare un nuovo messaggio a Hub eventi. Per il filtro, al messaggio è stata aggiunta una proprietà di identificazione: HEALTHCHECK=TRUE questo messaggio viene ignorato alla fine della ricezione. L'impostazione AlwaysOn.BackgroundProcessor.EventHubProcessorService.ProcessEventHandlerAsync() di configurazione controlla la HEALTHCHECK proprietà . |
| Azure Cosmos DB | La creazione di report sull'integrità di Azure Cosmos DB viene gestita da , che segnala l'integrità CosmosDbServicese è: 1. È possibile connettersi al database Azure Cosmos DB ed eseguire una query. 2. È possibile scrivere un documento di test nel database. Il documento di test include un breve set time-to-live, Azure Cosmos DB lo rimuove automaticamente. HealthService esegue due probe separati. Se Azure Cosmos DB è in uno stato in cui le letture e le scritture non funzionano, i due probe assicurano che venga attivato un avviso. |
Query di Azure Cosmos DB
Per la query di sola lettura, viene usata la query seguente, che non recupera dati e non ha un effetto elevato sul carico complessivo:
SELECT GetCurrentDateTime ()
La query di scrittura crea un fittizio ItemRating con contenuto minimo:
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);
Monitoraggio
Azure Log Analytics viene usato come archivio centrale per log e metriche per tutti i componenti dell'applicazione e dell'infrastruttura. app Azure lication Insights viene usato per tutti i dati di monitoraggio delle applicazioni. Ogni stamp nell'infrastruttura ha un'area di lavoro Log Analytics dedicata e un'istanza di Application Insights. Un'area di lavoro Log Analytics separata viene usata per le risorse condivise a livello globale, ad esempio Frontdoor e Azure Cosmos DB.
Tutti i francobolli sono di breve durata e continuamente sostituiti con ogni nuova versione. Le aree di lavoro Log Analytics per stamp vengono distribuite come risorsa globale in un gruppo di risorse di monitoraggio separato come risorse di Log Analytics. Queste risorse non condividono il ciclo di vita di un timbro.
Per altre informazioni, vedere Sink di dati unificato per l'analisi correlata.
Monitoraggio: origini dati
Impostazioni di diagnostica: tutti i servizi di Azure usati per Azure Mission-Critical sono configurati per inviare tutti i dati di diagnostica, inclusi i log e le metriche all'area di lavoro Log Analytics specifica (globale o stamp). Questo processo viene eseguito automaticamente come parte della distribuzione di Terraform. Le nuove opzioni verranno identificate automaticamente e aggiunte come parte di
terraform apply.Monitoraggio di Kubernetes: le impostazioni di diagnostica vengono usate per inviare log e metriche di servizio Azure Kubernetes (servizio Azure Kubernetes) a Log Analytics. Il servizio Azure Kubernetes è configurato per l'uso di Informazioni dettagliate sui contenitori. Container Insights distribuisce OMSAgentForLinus tramite un DaemonSet kubernetes in ogni nodo nei cluster del servizio Azure Kubernetes. OMSAgentForLinux è in grado di raccogliere log e metriche aggiuntivi dall'interno del cluster Kubernetes e di inviarli all'area di lavoro Log Analytics corrispondente. Questi log e metriche aggiuntivi contengono dati più granulari su pod, distribuzioni, servizi e integrità complessiva del cluster. Per ottenere altre informazioni dettagliate dai vari componenti, ad esempio in ingresso-nginx, cert-manager e altri componenti distribuiti in Kubernetes accanto al carico di lavoro mission-critical, è possibile usare lo scraping prometheus. Prometheus scraping configura OMSAgentForLinux per raschiare le metriche di Prometheus da vari endpoint all'interno del cluster.
Telemetria di Application Insights: Application Insights viene usato per raccogliere dati di telemetria dall'applicazione. Il codice è stato instrumentato per raccogliere dati sulle prestazioni dell'applicazione con Application Insights SDK. Vengono raccolte informazioni critiche, ad esempio il codice di stato risultante e la durata delle chiamate e dei contatori delle dipendenze per le eccezioni non gestite. Queste informazioni vengono usate nel modello di integrità ed è disponibile per avvisi e risoluzione dei problemi.
Monitoraggio: test di disponibilità di Application Insights
Per monitorare la disponibilità dei singoli timbri e la soluzione complessiva da un punto di vista esterno, i test di disponibilità di Application Insights vengono configurati in due posizioni:
Test di disponibilità a livello di area: questi test vengono configurati nelle istanze di Application Insights a livello di area e vengono usati per monitorare la disponibilità dei francobolli. Questi test sono destinati direttamente ai cluster e agli account di archiviazione statici dei francobolli. Per chiamare direttamente i punti di ingresso dei cluster, le richieste devono portare l'intestazione dell'ID frontdoor corretta, altrimenti vengono rifiutati dal controller di ingresso.
Test di disponibilità globale: questi test vengono configurati nell'istanza globale di Application Insights e vengono usati per monitorare la disponibilità della soluzione complessiva eseguendo il ping di Frontdoor. Vengono usati due test: uno per testare una chiamata API a CatalogService e una per testare la home page del sito Web.
Monitoraggio: query
Azure Mission-Critical usa query di Linguaggio di query Kusto (KQL) diverse per implementare query personalizzate come funzioni per recuperare i dati da Log Analytics. Queste query vengono archiviate come singoli file nel repository di codice, separate per le distribuzioni globali e stamp. Vengono importati e applicati automaticamente tramite Terraform come parte di ogni esecuzione della pipeline dell'infrastruttura.
Questo approccio separa la logica di query dal livello di visualizzazione. Le query di Log Analytics vengono chiamate direttamente dal codice, ad esempio dall'API HealthService. Un altro esempio è quello di uno strumento di visualizzazione, ad esempio Dashboard di Azure, Monitoraggio cartelle di lavoro o Grafana.
Monitoraggio: visualizzazione
Per visualizzare i risultati delle query sull'integrità di Log Analytics, è stato usato Grafana nell'implementazione di riferimento. Grafana viene usato per visualizzare i risultati delle query di Log Analytics e non contiene alcuna logica stessa. Lo stack Grafana non fa parte del ciclo di vita della distribuzione della soluzione, ma rilasciato separatamente.
Per altre informazioni, vedere Visualizzazione.
Creazione di avvisi
Gli avvisi sono una parte importante della strategia operativa complessiva. È consigliabile usare il monitoraggio proattivo, ad esempio l'uso dei dashboard, con avvisi che generano un'attenzione immediata ai problemi.
Questi avvisi costituiscono un'estensione del modello di integrità, avvisando l'operatore a una modifica dello stato di integrità, allo stato danneggiato/giallo o allo stato non integro/rosso. Impostando l'avviso sul nodo radice del modello di integrità, l'operatore è immediatamente a conoscenza di qualsiasi livello aziendale che influisce sullo stato della soluzione: dopo tutto, questo nodo radice diventa giallo o rosso se uno dei flussi utente o delle risorse sottostanti segnala le metriche gialle o rosse. L'operatore può indirizzare l'attenzione alla visualizzazione modello di integrità per la risoluzione dei problemi.
Per altre informazioni, vedere Risposta automatica agli eventi imprevisti.
Analisi degli errori
La composizione dell'analisi degli errori è principalmente un esercizio teorico di pianificazione. Questo esercizio teorico deve essere usato come input per gli inserimenti automatici di errori che fanno parte del processo di convalida continua. Simulando le modalità di errore definite qui, è possibile convalidare la resilienza della soluzione rispetto a questi errori per assicurarsi che non provocheranno interruzioni.
La tabella seguente elenca i casi di errore di esempio dei vari componenti dell'implementazione di riferimento Mission-Critical di Azure.
| Service | Rischio | Impatto/Mitigazione/Commento | Outage |
|---|---|---|---|
| Microsoft Entra ID | Microsoft Entra ID diventa non disponibile. | Attualmente non è possibile eseguire alcuna mitigazione. Un approccio in più aree non riduce le interruzioni perché è un servizio globale. Questo servizio è una dipendenza rigida. Microsoft Entra ID viene usato per operazioni del piano di controllo come la creazione di nuovi nodi del servizio Azure Kubernetes, il pull delle immagini del contenitore da Registro Azure Container o l'accesso a Key Vault all'avvio del pod. È previsto che i componenti esistenti in esecuzione siano in grado di continuare a essere in esecuzione quando si verificano problemi con Microsoft Entra ID. È probabile che nuovi pod o nodi del servizio Azure Kubernetes non siano in grado di generare. Durante questo periodo di tempo sono necessarie operazioni di scalabilità, potrebbe comportare una riduzione dell'esperienza utente e potenzialmente interruzioni. | Parziale |
| DNS Azure | DNS di Azure diventa non disponibile e la risoluzione DNS non riesce. | Se DNS di Azure non è più disponibile, la risoluzione DNS per le richieste utente e tra componenti diversi dell'applicazione avrà probabilmente esito negativo. Attualmente non è possibile applicare alcuna mitigazione per questo scenario. Un approccio in più aree non riduce le interruzioni perché è un servizio globale. DNS di Azure è una dipendenza rigida. I servizi DNS esterni come backup non sono utili, poiché tutti i componenti PaaS usati si basano su DNS di Azure. Ignorare il DNS passando all'indirizzo IP non è un'opzione. I servizi di Azure non hanno indirizzi IP statici e garantiti. | Completo |
| Frontdoor | Interruzione generale di Frontdoor. | Se Frontdoor si arresta completamente, non c'è alcuna mitigazione. Questo servizio è una dipendenza rigida. | Sì |
| Frontdoor | Errori di configurazione routing/front-end/back-end. | Può verificarsi a causa di mancata corrispondenza nella configurazione durante la distribuzione. Deve essere intercettata nelle fasi di test. La configurazione front-end con DNS è specifica per ogni ambiente. Mitigazione: il rollback alla configurazione precedente dovrebbe risolvere la maggior parte dei problemi. Man mano che le modifiche richiedono un paio di minuti in Frontdoor per la distribuzione, causerà un'interruzione. | Completo |
| Frontdoor | Il certificato TLS/SSL gestito viene eliminato. | Può verificarsi a causa di mancata corrispondenza nella configurazione durante la distribuzione. Deve essere intercettata nelle fasi di test. Tecnicamente il sito funziona ancora, ma gli errori del certificato TLS/SSL impediranno agli utenti di accedervi. Mitigazione: il nuovo rilascio del certificato può richiedere circa 20 minuti, oltre alla correzione e alla ripetizione dell'esecuzione della pipeline. | Completo |
| Azure Cosmos DB | Database/raccolta rinominato. | Può verificarsi a causa di mancata corrispondenza nella configurazione durante la distribuzione: Terraform sovrascrive l'intero database, con conseguente perdita di dati. È possibile evitare la perdita di dati usando blocchi a livello di database/raccolta. L'applicazione non sarà in grado di accedere ai dati. La configurazione dell'app deve essere aggiornata e i pod sono stati riavviati. | Sì |
| Azure Cosmos DB | Interruzione a livello di area | Azure Mission-Critical include scritture in più aree abilitate. Se si verifica un errore in una lettura o scrittura, il client ritenta l'operazione corrente. Tutte le operazioni future vengono indirizzate in modo permanente all'area successiva in ordine di preferenza. Nel caso in cui l'elenco delle preferenze abbia una voce (o fosse vuota), ma l'account dispone di altre aree disponibili, verrà instradato all'area successiva nell'elenco di account. | No |
| Azure Cosmos DB | Limitazione estesa a causa della mancanza di UR. | A seconda del numero di UR e del bilanciamento del carico impiegato a livello di Frontdoor, alcuni timbri potrebbero essere eseguiti ad accesso frequente nell'utilizzo di Azure Cosmos DB, mentre altri stamp possono gestire più richieste. Mitigazione: migliore distribuzione del carico o più UR. | No |
| Azure Cosmos DB | Partizione completa | Il limite di dimensioni partizioni logiche di Azure Cosmos DB è di 20 GB. Se i dati per una chiave di partizione all'interno di un contenitore raggiungono queste dimensioni, le richieste di scrittura aggiuntive avranno esito negativo con l'errore "La chiave di partizione ha raggiunto le dimensioni massime". | Parziale (scritture db disabilitate) |
| Registro Azure Container | Interruzione a livello di area | Il registro contenitori usa Gestione traffico per eseguire il failover tra aree di replica. Qualsiasi richiesta deve essere reindirizzata automaticamente a un'altra area. Nel peggiore dei casi, le immagini Docker non possono essere estratte per alcuni minuti dai nodi del servizio Azure Kubernetes mentre si verifica il failover DNS. | No |
| Registro Azure Container | Immagini eliminate | Nessuna immagine può essere estratta. Questa interruzione deve influire solo sui nodi appena generati/riavviati. I nodi esistenti devono avere le immagini memorizzate nella cache. **Mitigazione: se è stata rilevata una nuova esecuzione rapida delle pipeline di compilazione più recenti, è necessario ripristinare le immagini nel Registro di sistema. | No |
| Registro Azure Container | Limitazione | La limitazione può ritardare le operazioni di aumento del numero di istanze, con conseguente riduzione temporanea delle prestazioni. Mitigazione: Azure Mission-Critical usa lo SKU Premium che fornisce 10.000 operazioni di lettura al minuto. Le immagini del contenitore sono ottimizzate e hanno solo un numero ridotto di livelli. ImagePullPolicy è impostato su IfNotPresent per usare prima le versioni memorizzate nella cache locale. Commento: il pull di un'immagine del contenitore è costituito da più operazioni di lettura, a seconda del numero di livelli. Il numero di operazioni di lettura al minuto è limitato e dipende dalle dimensioni dello SKU del Registro Azure Container. | No |
| Servizio Azure Kubernetes | L'aggiornamento del cluster non riesce | Gli aggiornamenti del nodo del servizio Azure Kubernetes devono essere eseguiti in momenti diversi tra gli indicatori. se un aggiornamento non riesce, l'altro cluster non deve essere interessato. Gli aggiornamenti del cluster devono essere distribuiti in sequenza tra i nodi per impedire che tutti i nodi diventino non disponibili. | No |
| Servizio Azure Kubernetes | Il pod dell'applicazione viene terminato durante la gestione della richiesta. | Ciò potrebbe causare errori e un'esperienza utente scarsa. Mitigazione: Kubernetes per impostazione predefinita rimuove i pod in modo normale. I pod vengono rimossi prima dai servizi e il carico di lavoro riceve un SIGTERM con un periodo di tolleranza per completare le richieste aperte e scrivere i dati prima di terminare. Il codice dell'applicazione deve comprendere SIGTERM e il periodo di tolleranza potrebbe essere necessario modificare se il carico di lavoro richiede più tempo per l'arresto. | No |
| Servizio Azure Kubernetes | Capacità di calcolo non disponibile nell'area per aggiungere altri nodi. | Le operazioni di aumento/aumento delle prestazioni avranno esito negativo, ma non dovrebbero influire sui nodi esistenti e sulla relativa operazione. Idealmente, il traffico dovrebbe essere spostato automaticamente in altre aree per il bilanciamento del carico. | No |
| Servizio Azure Kubernetes | La sottoscrizione raggiunge la quota di core CPU per aggiungere nuovi nodi. | Le operazioni di aumento/aumento delle prestazioni avranno esito negativo, ma non dovrebbero influire sui nodi esistenti e sulla relativa operazione. Idealmente, il traffico dovrebbe essere spostato automaticamente in altre aree per il bilanciamento del carico. | No |
| Servizio Azure Kubernetes | I certificati TLS/SSL non possono essere rilasciati/rinnovati. | Il cluster dovrebbe segnalare il non integro verso Frontdoor e il traffico dovrebbe passare ad altri francobolli. Mitigazione: analizzare la causa radice del problema o del rinnovo. | No |
| Servizio Azure Kubernetes | Quando le richieste o i limiti delle risorse vengono configurati in modo non corretto, i pod possono raggiungere il 100% dell'utilizzo della CPU e le richieste non riuscite. Il meccanismo di ripetizione dei tentativi dell'applicazione deve essere in grado di ripristinare le richieste non riuscite. I tentativi potrebbero causare una durata più lunga della richiesta, senza visualizzare l'errore al client. Un carico eccessivo causerà un errore. | No (se il carico non è eccessivo) | |
| Servizio Azure Kubernetes | Immagini del contenitore di terze parti/Registro di sistema non disponibile | Alcuni componenti come cert-manager e ingress-nginx richiedono il download di immagini del contenitore e grafici Helm da registri contenitori esterni (traffico in uscita). Nel caso in cui uno o più di questi repository o immagini non siano disponibili, le nuove istanze nei nuovi nodi (in cui l'immagine non è già memorizzata nella cache) potrebbero non essere in grado di avviare. Possibile mitigazione: in alcuni scenari potrebbe essere utile importare immagini di contenitori di terze parti nel registro contenitori per soluzione. In questo modo si aggiunge una maggiore complessità e deve essere pianificata e operativa attentamente. | Parzialmente (durante le operazioni di scalabilità e aggiornamento/aggiornamento) |
| Hub eventi | I messaggi non possono essere inviati a Hub eventi | Stamp diventa inutilizzabile per le operazioni di scrittura. Il servizio integrità dovrebbe rilevare automaticamente questo e rimuovere il timbro dalla rotazione. | No |
| Hub eventi | I messaggi non possono essere letti da BackgroundProcessor | I messaggi verranno accodato. I messaggi non devono andare persi perché sono persistenti. Attualmente, questo errore non è coperto dal Servizio integrità. Per rilevare gli errori nella lettura dei messaggi, è necessario che sia presente un monitoraggio o un avviso sul ruolo di lavoro. Mitigazione: il timbro deve essere disabilitato manualmente fino a quando il problema non viene risolto. | No |
| Account di archiviazione | L'account di archiviazione diventa inutilizzabile dal ruolo di lavoro per il controllo di Hub eventi | Stamp non elabora i messaggi da Hub eventi. L'account di archiviazione viene usato anche da HealthService. Dovrebbero essere rilevati problemi di archiviazione da HealthService e il timbro deve essere estratto dalla rotazione. Ci si può aspettare che altri servizi nel timbro saranno interessati simultaneamente. | No |
| Account di archiviazione | Il sito Web statico rileva problemi. | Se la gestione del sito Web statico rileva problemi, questo errore deve essere rilevato da Frontdoor. Il traffico non verrà inviato a questo account di archiviazione. La memorizzazione nella cache in Frontdoor può anche alleviare questo problema. | No |
| Insieme di credenziali delle chiavi di | Key Vault non disponibile per GetSecret le operazioni. |
All'inizio dei nuovi pod, il driver CSI del servizio Azure Kubernetes recupera tutti i segreti da Key Vault e non riesce. Non sarà possibile avviare i pod. È attualmente disponibile un aggiornamento automatico ogni 5 minuti. L'aggiornamento avrà esito negativo. Gli errori dovrebbero essere visualizzati ma kubectl describe pod il pod continua a funzionare. |
No |
| Insieme di credenziali delle chiavi di | Key Vault non disponibile per GetSecret le operazioni o SetSecret . |
Non è possibile eseguire nuove distribuzioni. Attualmente, questo errore potrebbe causare l'arresto dell'intera pipeline di distribuzione, anche se è interessata solo un'area. | No |
| Insieme di credenziali delle chiavi di | Limitazione dell'insieme di credenziali delle chiavi | Key Vault ha un limite di 1000 operazioni per 10 secondi. A causa dell'aggiornamento automatico dei segreti, si potrebbe in teoria raggiungere questo limite se si disponeva di molte (migliaia) di pod in un timbro. Possibile mitigazione: ridurre ulteriormente la frequenza di aggiornamento o disattivarla completamente. | No |
| Applicazione | Errore di configurazione | Stringa di connessione o segreti non corretti inseriti nell'app. Deve essere mitigato dalla distribuzione automatica (la pipeline gestisce automaticamente la configurazione) e dall'implementazione blu-verde degli aggiornamenti. | No |
| Applicazione | Credenziali scadute (risorsa stamp) | Se ad esempio il token di firma di accesso condiviso dell'hub eventi o la chiave dell'account di archiviazione sono stati modificati senza aggiornarli correttamente in Key Vault in modo che i pod possano usarli, il rispettivo componente dell'applicazione avrà esito negativo. Questo errore dovrebbe quindi influire sul Servizio integrità e il timbro deve essere estratto automaticamente dalla rotazione. Mitigazione: usare l'autenticazione basata su ID Di Microsoft Entra per tutti i servizi che lo supportano. Il servizio Azure Kubernetes richiede che i pod eseguano l'autenticazione usando ID dei carichi di lavoro di Microsoft Entra (anteprima). L'uso dell'identità pod è stato considerato nell'implementazione di riferimento. È stato rilevato che l'identità dei pod non era abbastanza stabile attualmente ed è stata decisa contro l'uso per l'architettura di riferimento corrente. L'identità dei pod potrebbe essere una soluzione in futuro. | No |
| Applicazione | Credenziali scadute (risorsa condivisa a livello globale) | Se, ad esempio, la chiave API di Azure Cosmos DB è stata modificata senza aggiornarla correttamente in tutti gli insiemi di credenziali delle chiavi per consentire ai pod di usarli, i rispettivi componenti dell'applicazione avranno esito negativo. Questo errore comporta l'arresto di tutti gli indicatori contemporaneamente e un'interruzione a livello di carico di lavoro. Per un modo possibile per aggirare la necessità di chiavi e segreti tramite l'autenticazione di Microsoft Entra, vedere l'elemento precedente. | Completo |
| Rete virtuale | Spazio indirizzi IP subnet esaurito | Se lo spazio degli indirizzi IP in una subnet è esaurito, non possono verificarsi operazioni di aumento del numero di istanze, ad esempio la creazione di nuovi nodi o pod del servizio Azure Kubernetes. Non causerà un'interruzione, ma potrebbe ridurre le prestazioni e influire sull'esperienza utente. Mitigazione: aumentare lo spazio IP ,se possibile. Se non si tratta di un'opzione, può essere utile aumentare le risorse per nodo (SKU di macchine virtuali di dimensioni maggiori) o per pod (più CPU/memoria), in modo che ogni pod possa gestire più traffico, riducendo così la necessità di aumentare il numero di istanze. | No |
Passaggi successivi
Distribuire l'implementazione di riferimento per ottenere una conoscenza completa delle risorse e della relativa configurazione usata in questa architettura.