Considerazioni sulla piattaforma applicativa per carichi di lavoro cruciali

Un'area di progettazione chiave di qualsiasi architettura cruciale è la piattaforma applicativa. La piattaforma fa riferimento ai componenti dell'infrastruttura e ai servizi di Azure di cui è necessario eseguire il provisioning per supportare l'applicazione. Ecco alcune raccomandazioni generali.

• Progettare in livelli. Scegliere il set corretto di servizi, la relativa configurazione e le dipendenze specifiche dell'applicazione. Questo approccio a più livelli consente di creare la segmentazione logica e fisica. È utile per definire ruoli e funzioni e assegnare privilegi appropriati e strategie di distribuzione. Questo approccio aumenta infine l'affidabilità del sistema.

• Un'applicazione mission-critical deve essere altamente affidabile e resistente ai data center e agli errori a livello di area. La creazione di ridondanza a livello di zona e a livello di area in una configurazione attiva-attiva è la strategia principale. Quando si scelgono i servizi di Azure per la piattaforma dell'applicazione, prendere in considerazione i modelli di supporto e distribuzione e distribuzione e operativi zone di disponibilità per l'uso di più aree di Azure.

• Usare un'architettura basata su unità di scala per gestire un carico maggiore. Le unità di scala consentono di raggruppare logicamente le risorse e un'unità può essere ridimensionata indipendentemente da altre unità o servizi nell'architettura. Usare il modello di capacità e le prestazioni previste per definire i limiti, il numero e la scala di base di ogni unità.

In questa architettura, la piattaforma dell'applicazione è costituita da risorse globali, di distribuzione e regionali. Il provisioning delle risorse a livello di area viene effettuato come parte di un timbro di distribuzione. Ogni stamp equivale a un'unità di scala e, nel caso in cui non sia integro, può essere completamente sostituito.

Le risorse in ogni livello hanno caratteristiche distinte. Per altre informazioni, vedere Modello di architettura di un carico di lavoro mission-critical tipico.

Caratteristiche	Considerazioni
Durata	Qual è la durata prevista della risorsa, rispetto ad altre risorse nella soluzione? La risorsa deve durare più a lungo o condividere la durata con l'intero sistema o l'area oppure deve essere temporanea?
Stato	Quale impatto avrà lo stato persistente a questo livello sull'affidabilità o sulla gestibilità?
Copertura	La risorsa deve essere distribuita a livello globale? La risorsa può comunicare con altre risorse, a livello globale o in aree?
Dipendenze	Qual è la dipendenza da altre risorse, a livello globale o in altre aree?
Limiti di scalabilità	Qual è la velocità effettiva prevista per tale risorsa a tale livello? Quanto scala viene fornita dalla risorsa per soddisfare tale domanda?
Disponibilità/ripristino di emergenza	Qual è l'impatto sulla disponibilità o sull'emergenza a questo livello? Causerebbe un'interruzione sistemica o solo una capacità localizzata o un problema di disponibilità?

Risorse globali

Alcune risorse in questa architettura vengono condivise dalle risorse distribuite nelle aree. In questa architettura vengono usate per distribuire il traffico tra più aree, archiviare lo stato permanente per l'intera applicazione e memorizzare nella cache i dati statici globali.

Caratteristiche	Considerazioni sul livello
Durata	Queste risorse dovrebbero vivere a lungo. La loro durata dura tutta la vita del sistema o più a lungo. Spesso le risorse vengono gestite con aggiornamenti del piano di controllo e dati sul posto, presupponendo che supportino operazioni di aggiornamento senza tempi di inattività.
Stato	Poiché queste risorse esistono per almeno la durata del sistema, questo livello è spesso responsabile dell'archiviazione dello stato globale e con replica geografica.
Copertura	Le risorse devono essere distribuite a livello globale. È consigliabile che queste risorse comunichino con risorse regionali o altre con bassa latenza e la coerenza desiderata.
Dipendenze	Le risorse devono evitare dipendenze dalle risorse a livello di area perché la mancata disponibilità può essere causa di un errore globale. Ad esempio, i certificati o i segreti conservati in un singolo insieme di credenziali potrebbero avere un impatto globale se si verifica un errore a livello di area in cui si trova l'insieme di credenziali.
Limiti di scalabilità	Spesso queste risorse sono istanze singleton nel sistema e, di conseguenza, devono essere in grado di ridimensionare in modo che possano gestire la velocità effettiva del sistema nel suo complesso.
Disponibilità/ripristino di emergenza	Poiché le risorse regionali e di stamp possono utilizzare risorse globali o di fronte a esse, è fondamentale che le risorse globali siano configurate con disponibilità elevata e ripristino di emergenza per l'integrità dell'intero sistema.

In questa architettura, le risorse a livello globale sono Frontdoor di Azure, Azure Cosmos DB, Registro Azure Container e Azure Log Analytics per l'archiviazione di log e metriche da altre risorse a livello globale.

In questa progettazione sono disponibili altre risorse fondamentali, ad esempio Microsoft Entra ID e DNS di Azure. Sono stati omessi in questa immagine per brevità.

Servizio di bilanciamento del carico globale

Frontdoor di Azure viene usato come unico punto di ingresso per il traffico degli utenti. Azure garantisce che Frontdoor di Azure distribuirà il contenuto richiesto senza errori il 99,99% del tempo. Per altri dettagli, vedere Limiti del servizio Frontdoor. Se Frontdoor non è più disponibile, l'utente finale visualizzerà il sistema come inattivo.

L'istanza di Frontdoor invia il traffico ai servizi back-end configurati, ad esempio il cluster di calcolo che ospita l'API e l'applicazione a pagina singola front-end. Le configurazioni non corretta del back-end in Frontdoor possono causare interruzioni. Per evitare interruzioni a causa di configurazioni errate, è consigliabile testare ampiamente le impostazioni di Frontdoor.

Un altro errore comune può derivare da certificati TLS non configurati correttamente o mancanti, che possono impedire agli utenti di usare il front-end o frontdoor che comunica con il back-end. La mitigazione potrebbe richiedere un intervento manuale. Ad esempio, è possibile scegliere di eseguire il rollback alla configurazione precedente e rilasciare nuovamente il certificato, se possibile. Indipendentemente dalla mancata disponibilità, mentre le modifiche diventano effettive. È consigliabile usare i certificati gestiti offerti da Frontdoor per ridurre il sovraccarico operativo, ad esempio la gestione della scadenza.

Frontdoor offre molte funzionalità aggiuntive oltre al routing globale del traffico. Una funzionalità importante è web application firewall (WAF), perché Frontdoor è in grado di controllare il traffico che passa attraverso. Se configurata in modalità prevenzione , blocca il traffico sospetto prima di raggiungere anche uno dei back-end.

Per informazioni sulle funzionalità di Frontdoor, vedere Domande frequenti su Frontdoor di Azure.

Per altre considerazioni sulla distribuzione globale del traffico, vedere Linee guida critiche per Misson in Well-architected Framework: Routing globale.

Registro Container

Registro Azure Container viene usato per archiviare artefatti OCI (Open Container Initiative), in particolare grafici helm e immagini del contenitore. Non partecipa al flusso della richiesta ed è accessibile solo periodicamente. Il registro contenitori deve esistere prima della distribuzione delle risorse stamp e non deve dipendere dalle risorse a livello di area.

Abilitare la ridondanza della zona e la replica geografica dei registri in modo che l'accesso in fase di esecuzione alle immagini sia veloce e resiliente agli errori. In caso di indisponibilità, l'istanza può quindi eseguire il failover nelle aree di replica e le richieste vengono reindirizzate automaticamente a un'altra area. Attendere errori temporanei nelle immagini di pull fino al completamento del failover.

Gli errori possono verificarsi anche se le immagini vengono eliminate inavvertitamente, i nuovi nodi di calcolo non potranno eseguire il pull delle immagini, ma i nodi esistenti possono comunque usare immagini memorizzate nella cache. La strategia principale per il ripristino di emergenza è la ridistribuzione. Gli artefatti in un registro contenitori possono essere rigenerati dalle pipeline. Il registro contenitori deve essere in grado di resistere a molte connessioni simultanee per supportare tutte le distribuzioni.

È consigliabile usare lo SKU Premium per abilitare la replica geografica. La funzionalità di ridondanza della zona garantisce resilienza e disponibilità elevata all'interno di un'area specifica. In caso di interruzione a livello di area, le repliche in altre aree sono ancora disponibili per le operazioni del piano dati. Con questo SKU è possibile limitare l'accesso alle immagini tramite endpoint privati.

Per altri dettagli, vedere Procedure consigliate per Registro Azure Container.

Database

È consigliabile archiviare tutti gli stati a livello globale in un database separato da indicatori internazionali. Creare la ridondanza distribuendo il database tra aree. Per i carichi di lavoro cruciali, la sincronizzazione dei dati tra aree deve essere la principale preoccupazione. Inoltre, in caso di errore, le richieste di scrittura nel database devono essere ancora funzionanti.

La replica dei dati in una configurazione attiva-attiva è fortemente consigliata. L'applicazione deve essere in grado di connettersi immediatamente a un'altra area. Tutte le istanze devono essere in grado di gestire le richieste di lettura e scrittura.

Per altre informazioni, vedere Piattaforma dati per carichi di lavoro cruciali.

Monitoraggio globale

Azure Log Analytics viene usato per archiviare i log di diagnostica da tutte le risorse globali. È consigliabile limitare la quota giornaliera nell'archiviazione in particolare in ambienti usati per i test di carico. Impostare anche i criteri di conservazione. Queste restrizioni impediranno qualsiasi eccedenza che si verifica archiviando i dati non necessari oltre un limite.

Considerazioni sui servizi di base

È probabile che il sistema usi altri servizi critici della piattaforma che possono causare rischi per l'intero sistema, ad esempio DNS di Azure e Microsoft Entra ID. DNS di Azure garantisce il contratto di servizio di disponibilità del 100% per le richieste DNS valide. Microsoft Entra garantisce almeno il tempo di attività del 99,99%. È comunque necessario essere consapevoli dell'impatto in caso di errore.

L'assunzione di una dipendenza rigida dai servizi fondamentali è inevitabile perché molti servizi di Azure dipendono da essi. Se non sono disponibili, si prevede un'interruzione nel sistema. Ad esempio:

• Frontdoor di Azure usa DNS di Azure per raggiungere il back-end e altri servizi globali.
• Registro Azure Container usa DNS di Azure per eseguire il failover delle richieste in un'altra area.

In entrambi i casi, entrambi i servizi di Azure saranno interessati se DNS di Azure non è disponibile. La risoluzione dei nomi per le richieste degli utenti da Frontdoor avrà esito negativo; Le immagini Docker non verranno estratte dal Registro di sistema. L'uso di un servizio DNS esterno come backup non riduce il rischio perché molti servizi di Azure non consentono tale configurazione e si basano su DNS interno. Aspettatevi un'interruzione completa.

Analogamente, Microsoft Entra ID viene usato per le operazioni del piano di controllo, ad esempio la creazione di nuovi nodi del servizio Azure Kubernetes, il pull di immagini dal Registro Container o l'accesso a Key Vault all'avvio del pod. Se Microsoft Entra ID non è disponibile, i componenti esistenti non devono essere interessati, ma le prestazioni complessive potrebbero essere ridotte. I nuovi pod o nodi del servizio Azure Kubernetes non saranno funzionali. Pertanto, nel caso in cui le operazioni di aumento del numero di istanze siano necessarie durante questo periodo, si prevede una riduzione dell'esperienza utente.

Risorse stamp di distribuzione a livello di area

In questa architettura, il timbro di distribuzione distribuisce il carico di lavoro e effettua il provisioning delle risorse che partecipano al completamento delle transazioni aziendali. Un timbro corrisponde in genere a una distribuzione in un'area di Azure. Anche se un'area può avere più di un timbro.

Caratteristiche	Considerazioni
Durata	Si prevede che le risorse abbiano un breve intervallo di vita (temporaneo) con la finalità che possono essere aggiunte e rimosse in modo dinamico, mentre le risorse a livello di area al di fuori dello stamp continuano a essere persistenti. La natura temporanea è necessaria per offrire maggiore resilienza, scalabilità e prossimità agli utenti.
Stato	Poiché i francobolli sono temporanei e possono essere distrutti in qualsiasi momento, un timbro deve essere senza stato il più possibile.
Copertura	Può comunicare con risorse internazionali e globali. Tuttavia, è consigliabile evitare la comunicazione con altre aree o altri francobolli. In questa architettura non è necessario distribuire queste risorse a livello globale.
Dipendenze	Le risorse stamp devono essere indipendenti. Ovvero, non devono basarsi su altri francobolli o componenti in altre aree. Si prevede che abbiano dipendenze internazionali e globali. Il componente condiviso principale è il livello del database e il registro contenitori. Questo componente richiede la sincronizzazione in fase di esecuzione.
Limiti di scalabilità	La velocità effettiva viene stabilita tramite test. La velocità effettiva del timbro complessivo è limitata alla risorsa con meno prestazioni. La velocità effettiva stamp deve tenere conto dell'elevato livello di domanda stimato e di qualsiasi failover a causa di un altro timbro nell'area che non è più disponibile.
Disponibilità/ripristino di emergenza	A causa della natura temporanea dei francobolli, il ripristino di emergenza viene eseguito ridistribuendo il timbro. Se le risorse si trovano in uno stato non integro, il timbro, nel suo complesso, può essere eliminato e ridistribuibile.

In questa architettura le risorse stamp sono servizio Azure Kubernetes, Hub eventi di Azure, Azure Key Vault e Archiviazione BLOB di Azure.

Unità di scala

Un timbro può anche essere considerato come un'unità di scala (SU). Tutti i componenti e i servizi all'interno di un determinato stamp vengono configurati e testati per gestire le richieste in un determinato intervallo. Ecco un esempio di unità di scala usata nell'implementazione.

Ogni unità di scala viene distribuita in un'area di Azure e quindi gestisce principalmente il traffico proveniente da quella determinata area (anche se può assumere il traffico da altre aree quando necessario). Questa distribuzione geografica causerà probabilmente modelli di carico e orari di ufficio che possono variare da un'area all'area e, di conseguenza, ogni unità di streaming è progettata per aumentare o ridurre le prestazioni in caso di inattività.

È possibile distribuire un nuovo stamp per la scalabilità. All'interno di un timbro, le singole risorse possono anche essere unità di scala.

Ecco alcune considerazioni sulla scalabilità e sulla disponibilità quando si scelgono i servizi di Azure in un'unità:

• Valutare le relazioni di capacità tra tutte le risorse in un'unità di scala. Ad esempio, per gestire 100 richieste in ingresso, sarebbero necessari 5 pod controller in ingresso e 3 pod del servizio catalogo e 1000 UR in Azure Cosmos DB. Pertanto, quando si esegue la scalabilità automatica dei pod in ingresso, si prevede il ridimensionamento del servizio di catalogo e delle UR di Azure Cosmos DB in base a tali intervalli.

• Test di carico dei servizi per determinare un intervallo entro il quale verranno gestite le richieste. In base ai risultati, configurare le istanze minime e massime e le metriche di destinazione. Quando viene raggiunta la destinazione, è possibile scegliere di automatizzare il ridimensionamento dell'intera unità.

• Esaminare i limiti e le quote di scalabilità delle sottoscrizioni di Azure per supportare la capacità e il modello di costo impostati dai requisiti aziendali. Controllare anche i limiti dei singoli servizi in considerazione. Poiché le unità vengono in genere distribuite insieme, tenere conto dei limiti delle risorse della sottoscrizione necessari per le distribuzioni canary. Per altre informazioni, vedere Limiti dei servizi di Azure.

• Scegliere i servizi che supportano le zone di disponibilità per creare la ridondanza. Ciò potrebbe limitare le scelte tecnologico. Per informazioni dettagliate, vedere zone di disponibilità.

Per altre considerazioni sulle dimensioni di un'unità e sulla combinazione di risorse, vedere Linee guida critiche per Misson in Framework ben progettato: architettura di unità di scala.

Cluster di calcolo

Per inserire in contenitori il carico di lavoro, ogni stamp deve eseguire un cluster di calcolo. In questa architettura viene scelto servizio Azure Kubernetes (servizio Azure Kubernetes) perché Kubernetes è la piattaforma di calcolo più diffusa per le applicazioni moderne in contenitori.

La durata del cluster del servizio Azure Kubernetes è associata alla natura temporanea del timbro. Il cluster è senza stato e non dispone di volumi permanenti. Usa dischi temporanei del sistema operativo anziché dischi gestiti perché non devono ricevere manutenzione a livello di applicazione o di sistema.

Per aumentare l'affidabilità, il cluster è configurato per l'uso di tutte e tre le zone di disponibilità in una determinata area. Ciò consente al cluster di usare il contratto di servizio Tempo di attività del servizio Azure Kubernetes che garantisce la disponibilità del contratto di servizio del 99,95% del piano di controllo del servizio Azure Kubernetes.

Anche altri fattori, ad esempio limiti di scalabilità, capacità di calcolo, quota di sottoscrizione possono influire sull'affidabilità. Se non sono stati raggiunti limiti o capacità sufficienti, le operazioni di scalabilità orizzontale e scalabilità orizzontale avranno esito negativo, ma il calcolo esistente dovrebbe funzionare.

La scalabilità automatica del cluster è abilitata per consentire ai pool di nodi di aumentare automaticamente il numero di istanze , se necessario, migliorando così l'affidabilità. Quando si usano più pool di nodi, tutti i pool di nodi devono essere ridimensionati automaticamente.

A livello di pod, horizontal pod autoscaler (HPA) ridimensiona i pod in base a cpu, memoria o metriche personalizzate configurate. Testare di carico i componenti del carico di lavoro per stabilire una linea di base per i valori di scalabilità automatica e HPA.

Il cluster è configurato anche per gli aggiornamenti automatici dell'immagine del nodo e per la scalabilità appropriata durante tali aggiornamenti. Questa scalabilità consente un tempo di inattività pari a zero durante l'esecuzione degli aggiornamenti. Se il cluster in un timbro non riesce durante un aggiornamento, gli altri cluster in altri indicatori non devono essere interessati, ma gli aggiornamenti tra i francobolli devono verificarsi in momenti diversi per mantenere la disponibilità. Inoltre, gli aggiornamenti del cluster vengono automaticamente distribuiti tra i nodi in modo che non siano disponibili contemporaneamente.

Alcuni componenti, ad esempio cert-manager e ingress-nginx, richiedono immagini del contenitore da registri contenitori esterni. Se tali repository o immagini non sono disponibili, le nuove istanze nei nuovi nodi (in cui l'immagine non è memorizzata nella cache) potrebbero non essere in grado di avviare. Questo rischio può essere risolto importando queste immagini nel Registro Azure Container dell'ambiente.

L'osservabilità è fondamentale in questa architettura perché i francobolli sono temporanei. Le impostazioni di diagnostica sono configurate per archiviare tutti i dati di log e metrica in un'area di lavoro Log Analytics a livello di area. Inoltre, Azure Kubernetes Container Insights è abilitato tramite un agente OMS nel cluster. Questo agente consente al cluster di inviare dati di monitoraggio all'area di lavoro Log Analytics.

Per altre considerazioni sul cluster di calcolo, vedere Linee guida critiche per Misson in Framework ben progettato: Orchestrazione dei contenitori e Kubernetes.

Insieme di credenziali delle chiavi di

Azure Key Vault viene usato per archiviare segreti globali, ad esempio stringa di connessione al database e contrassegnare i segreti, ad esempio Hub eventi stringa di connessione.

Questa architettura usa un driver CSI dell'archivio segreti nel cluster di calcolo per ottenere segreti da Key Vault. I segreti sono necessari quando vengono generati nuovi pod. Se Key Vault non è disponibile, i nuovi pod potrebbero non iniziare. Di conseguenza, potrebbe verificarsi un'interruzione; Le operazioni di scalabilità orizzontale possono essere interessate, gli aggiornamenti possono avere esito negativo, non è possibile eseguire nuove distribuzioni.

Key Vault prevede un limite per il numero di operazioni. A causa dell'aggiornamento automatico dei segreti, è possibile raggiungere il limite se sono presenti molti pod. È possibile scegliere di ridurre la frequenza degli aggiornamenti per evitare questa situazione.

Per altre considerazioni sulla gestione dei segreti, vedere Linee guida critiche per Misson in Framework ben progettato: Protezione dell'integrità dei dati.

Hub eventi

L'unico servizio con stato nel timbro è il broker di messaggi, Hub eventi di Azure, che archivia le richieste per un breve periodo. Il broker serve la necessità di buffering e messaggistica affidabile. Le richieste elaborate vengono rese persistenti nel database globale.

In questa architettura viene usato lo SKU Standard e la ridondanza della zona è abilitata per la disponibilità elevata.

L'integrità di Hub eventi viene verificata dal componente HealthService in esecuzione nel cluster di calcolo. Esegue controlli periodici su varie risorse. Ciò è utile per rilevare condizioni non integre. Ad esempio, se i messaggi non possono essere inviati all'hub eventi, lo stamp non sarà utilizzabile per qualsiasi operazione di scrittura. HealthService dovrebbe rilevare automaticamente questa condizione e segnalare lo stato non integro a Frontdoor, che rimuoverà il timbro dalla rotazione.

Per la scalabilità, è consigliabile abilitare l'aumento automatico.

Per altre informazioni, vedere Servizi di messaggistica per carichi di lavoro cruciali.

Per altre considerazioni sulla messaggistica, vedere Linee guida critiche per Misson in Framework ben progettato: Messaggistica asincrona.

Account di archiviazione

In questa architettura viene effettuato il provisioning di due account di archiviazione. Entrambi gli account vengono distribuiti in modalità con ridondanza della zona.

Un account viene usato per il checkpoint di Hub eventi. Se questo account non risponde, il timbro non sarà in grado di elaborare i messaggi da Hub eventi e potrebbe anche influire su altri servizi nel timbro. Questa condizione viene controllata periodicamente da HealthService, uno dei componenti dell'applicazione in esecuzione nel cluster di calcolo.

L'altro viene usato per ospitare l'applicazione a pagina singola dell'interfaccia utente. Se la gestione del sito Web statico presenta problemi, Frontdoor rileverà il problema e non invierà traffico a questo account di archiviazione. Durante questo periodo, Frontdoor può usare contenuto memorizzato nella cache.

Per altre informazioni sul ripristino, vedere Ripristino di emergenza e failover dell'account di archiviazione.

Risorse a livello di area

Un sistema può disporre di risorse distribuite nell'area, ma con una maggiore disponibilità delle risorse stamp. In questa architettura, i dati di osservabilità per le risorse stamp vengono archiviati negli archivi dati a livello di area.

Caratteristiche	Considerazione
Durata	Le risorse condividono la durata dell'area ed escono dalle risorse stamp.
Stato	Lo stato archiviato in un'area non può superare la durata dell'area. Se lo stato deve essere condiviso tra aree, è consigliabile usare un archivio dati globale.
Copertura	Le risorse non devono essere distribuite a livello globale. È consigliabile evitare la comunicazione diretta con altre aree a tutti i costi.
Dipendenze	Le risorse possono avere dipendenze dalle risorse globali, ma non dalle risorse stamp perché gli stamp sono destinati a essere di breve durata.
Limiti di scalabilità	Determinare il limite di scalabilità delle risorse regionali combinando tutti i francobolli all'interno dell'area.

Monitoraggio dei dati per le risorse stamp

La distribuzione delle risorse di monitoraggio è un esempio tipico per le risorse a livello di area. In questa architettura ogni area ha una singola area di lavoro Log Analytics configurata per archiviare tutti i dati di log e metrica generati dalle risorse stamp. Poiché le risorse regionali hanno una disponibilità elevata delle risorse stamp, i dati sono disponibili anche quando il timbro viene eliminato.

Azure Log Analytics e app Azure lication Insights vengono usati per archiviare log e metriche dalla piattaforma. È consigliabile limitare la quota giornaliera nell'archiviazione in particolare in ambienti usati per i test di carico. Impostare anche i criteri di conservazione per archiviare tutti i dati. Queste restrizioni impediranno qualsiasi eccedenza che si verifica archiviando i dati non necessari oltre un limite.

Analogamente, Application Insights viene distribuito anche come risorsa a livello di area per raccogliere tutti i dati di monitoraggio delle applicazioni.

Per consigli sulla progettazione sul monitoraggio, vedere Linee guida critiche per Misson in Framework ben progettato: Modellazione dell'integrità.

Passaggi successivi

Distribuire l'implementazione di riferimento per ottenere una conoscenza completa delle risorse e della relativa configurazione usata in questa architettura.

Implementazione: Mission-Critical Online