Affidabilità nelle app di Azure Container
Questo articolo descrive il supporto per l'affidabilità nelle app Azure Container e illustra sia la resilienza a livello di area con le zone di disponibilità che la resilienza tra aree con il ripristino di emergenza. Per una panoramica più dettagliata dell'affidabilità in Azure, vedere Affidabilità di Azure.
Supporto della zona di disponibilità
Le zone di disponibilità di Azure sono almeno tre gruppi di data center separati fisicamente all'interno di ogni area di Azure. I data center all'interno di ogni zona sono dotati di energia, raffreddamento e infrastruttura di rete indipendenti. In caso di errore della zona locale, le zone di disponibilità sono progettate in modo che se l'unica zona è interessata, i servizi regionali, la capacità e la disponibilità elevata sono supportati dalle due zone rimanenti.
Gli errori possono variare da errori software e hardware a eventi come terremoti, inondazioni e incendi. La tolleranza agli errori si ottiene con ridondanza e isolamento logico dei servizi di Azure. Per informazioni più dettagliate sulle zone di disponibilità in Azure, vedere Aree e zone di disponibilità.
I servizi abilitati per le zone di disponibilità di Azure sono progettati per offrire il giusto livello di affidabilità e flessibilità. Possono essere configurati in due modi. Possono essere ridondanti della zona, con replica automatica tra zone o zone, con istanze aggiunte a una zona specifica. È anche possibile combinare questi approcci. Per altre informazioni sull'architettura zonale e con ridondanza della zona, vedere Consigli per l'uso di zone e aree di disponibilità.
App Azure Container usa le zone di disponibilità nelle aree in cui sono disponibili per fornire protezione a disponibilità elevata per le applicazioni e i dati dagli errori del data center.
Abilitando la funzionalità di ridondanza della zona delle app contenitore, le repliche vengono distribuite automaticamente tra le zone dell'area. Il traffico viene bilanciato tra le repliche. Se si verifica un'interruzione della zona, il traffico viene indirizzato automaticamente alle repliche nelle zone rimanenti.
Nota
Non è previsto alcun costo aggiuntivo per l'abilitazione della ridondanza della zona, ma offre solo vantaggi quando si dispone di 2 o più repliche, con 3 o più elementi ideali perché la maggior parte delle aree che supportano la ridondanza della zona ha 3 zone.
Prerequisiti
App Azure Container offre lo stesso supporto per l'affidabilità indipendentemente dal tipo di piano.
App Azure Container usa le zone di disponibilità nelle aree in cui sono disponibili. Per un elenco delle aree che supportano le zone di disponibilità, vedere Servizio di zona di disponibilità e supporto a livello di area.
Miglioramenti del contratto di servizio
Non sono previsti contratti di servizio aumentati per le app contenitore di Azure. Per altre informazioni sui contratti di servizio delle app Azure Container, vedere Contratto di servizio per le app Azure Container.
Creare una risorsa con la zona di disponibilità abilitata
Configurare la ridondanza della zona nell'ambiente App contenitore
Per sfruttare i vantaggi delle zone di disponibilità, è necessario abilitare la ridondanza della zona quando si crea un ambiente app contenitore. L'ambiente deve includere una rete virtuale con una subnet disponibile. Per garantire una corretta distribuzione delle repliche, impostare il numero minimo di repliche dell'app su tre.
Abilitare la ridondanza della zona tramite il portale di Azure
Per creare un'app contenitore in un ambiente con ridondanza della zona abilitata usando il portale di Azure:
- Passare al portale di Azure.
- Cercare App contenitore nella casella di ricerca superiore.
- Selezionare App contenitore.
- Selezionare Crea nuovo nel campo Ambiente app contenitore per aprire il pannello Crea ambiente app contenitore.
- Immettere il nome dell'ambiente.
- Selezionare Abilitato per il campo Ridondanza della zona.
La ridondanza della zona richiede una rete virtuale con una subnet dell'infrastruttura. È possibile scegliere una rete virtuale esistente o crearne una nuova. Quando si crea una nuova rete virtuale, è possibile accettare i valori forniti o personalizzare le impostazioni.
- Selezionare la scheda Rete.
- Per assegnare un nome di rete virtuale personalizzato, selezionare Crea nuovo nel campo Rete virtuale.
- Per assegnare un nome di subnet dell'infrastruttura personalizzata, selezionare Crea nuovo nel campo Subnet infrastruttura.
- È possibile selezionare Interno o Esterno per l'INDIRIZZO IP virtuale.
- Seleziona Crea.
Abilitare la ridondanza della zona con l'interfaccia della riga di comando di Azure
Creare una rete virtuale e una subnet dell'infrastruttura da includere con l'ambiente App contenitore.
Quando si usano questi comandi, sostituire con i <PLACEHOLDERS> valori.
Nota
L'ambiente Solo consumo richiede una subnet dedicata con un intervallo CIDR di /23 o superiore. L'ambiente dei profili di carico di lavoro richiede una subnet dedicata con un intervallo CIDR di /27 o superiore. Per altre informazioni sul dimensionamento delle subnet, vedere panoramica dell'architettura di rete.
az network vnet create \
--resource-group <RESOURCE_GROUP_NAME> \
--name <VNET_NAME> \
--location <LOCATION> \
--address-prefix 10.0.0.0/16
az network vnet subnet create \
--resource-group <RESOURCE_GROUP_NAME> \
--vnet-name <VNET_NAME> \
--name infrastructure \
--address-prefixes 10.0.0.0/21
Eseguire quindi una query per l'ID subnet dell'infrastruttura.
INFRASTRUCTURE_SUBNET=`az network vnet subnet show --resource-group <RESOURCE_GROUP_NAME> --vnet-name <VNET_NAME> --name infrastructure --query "id" -o tsv | tr -d '[:space:]'`
Creare infine l'ambiente con il --zone-redundant parametro . Il percorso deve essere lo stesso percorso usato durante la creazione della rete virtuale.
az containerapp env create \
--name <CONTAINER_APP_ENV_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--location "<LOCATION>" \
--infrastructure-subnet-resource-id $INFRASTRUCTURE_SUBNET \
--zone-redundant
Verificare la ridondanza della zona con l'interfaccia della riga di comando di Azure
Nota
Il portale di Azure non mostra se la ridondanza della zona è abilitata.
Usare il comando per verificare che la az container app env show ridondanza della zona sia abilitata per l'ambiente App contenitore.
az containerapp env show \
--name <CONTAINER_APP_ENV_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--subscription <SUBSCRIPTION_ID>
Il comando restituisce una risposta JSON. Verificare che la risposta contenga "zoneRedundant": true.
Cassaforte tecniche di distribuzione
Quando si configura la ridondanza della zona nell'app contenitore, le repliche vengono distribuite automaticamente tra le zone nell'area. Dopo la distribuzione delle repliche, il traffico viene bilanciato tra di essi. Se si verifica un'interruzione della zona, il traffico instrada automaticamente alle repliche nella zona rimanente.
È comunque consigliabile usare tecniche di distribuzione sicure, ad esempio la distribuzione blu-verde. App Azure Container non fornisce aggiornamenti o distribuzioni mono-zona alla volta.
Se è stata abilitata l'affinità di sessione e una zona diventa inattiva, i client per tale zona vengono instradati a nuove repliche perché le repliche precedenti non sono più disponibili. Qualsiasi stato associato alle repliche precedenti viene perso.
Ridistribuzione e migrazione della zona di disponibilità
Per sfruttare i vantaggi delle zone di disponibilità, abilitare la ridondanza della zona durante la creazione dell'ambiente App contenitore. L'ambiente deve includere una rete virtuale con una subnet disponibile. Non è possibile eseguire la migrazione di un ambiente app contenitore esistente dal supporto della zona di non disponibilità al supporto della zona di disponibilità.
Ripristino di emergenza tra aree e continuità aziendale
Il ripristino di emergenza riguarda il ripristino da eventi ad alto impatto, ad esempio calamità naturali o distribuzioni non riuscite che comportano tempi di inattività e perdita di dati. Indipendentemente dalla causa, il miglior rimedio per un'emergenza è un piano di ripristino ben definito e testato e una progettazione di applicazioni che supporta attivamente tale ripristino. Prima di iniziare a pensare alla creazione del piano di ripristino di emergenza, vedere Consigli per la progettazione di una strategia di ripristino di emergenza.
Per quanto riguarda il ripristino di emergenza, Microsoft usa il modello di responsabilità condivisa. In un modello di responsabilità condivisa, Microsoft garantisce che siano disponibili l'infrastruttura di base e i servizi della piattaforma. Allo stesso tempo, molti servizi di Azure non replicano automaticamente i dati o non eseguono il fallback da un'area non riuscita per eseguire la replica incrociata in un'altra area abilitata. Per questi servizi, l'utente è responsabile della configurazione di un piano di ripristino di emergenza che funziona per il carico di lavoro. La maggior parte dei servizi eseguiti nelle offerte PaaS (Platform as a Service) di Azure offre funzionalità e linee guida per supportare il ripristino di emergenza ed è possibile usare funzionalità specifiche del servizio per supportare il ripristino rapido per lo sviluppo del piano di ripristino di emergenza.
Nel caso improbabile di un'interruzione completa dell'area, è possibile usare una delle due strategie seguenti:
Ripristino manuale: distribuire manualmente in una nuova area o attendere il ripristino dell'area e quindi ridistribuire manualmente tutti gli ambienti e le app.
Ripristino resiliente: distribuire prima le app contenitore in più aree. Usare quindi Frontdoor di Azure o Gestione traffico di Azure per gestire le richieste in ingresso, indirizzando il traffico all'area primaria. Quindi, in caso di interruzione, è possibile reindirizzare il traffico dall'area interessata. Per altre informazioni, vedere Replica tra aree in Azure.
Nota
Indipendentemente dalla strategia scelta, assicurarsi che i file di configurazione della distribuzione siano nel controllo del codice sorgente in modo da poter ridistribuire facilmente, se necessario.
Altre indicazioni
Le risorse seguenti consentono di creare un piano di ripristino di emergenza personalizzato:
- Ripristino di emergenza e in caso di errori per le applicazioni Azure
- Indicazioni tecniche sulla resilienza di Azure