Affidabilità nelle App contenitore di Azure
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à sono gruppi di data center separati fisicamente all'interno di ogni area di Azure. In caso di errore di una zona, i servizi possono eseguire il failover in una delle zone rimanenti.
Per altre informazioni sulle zone di disponibilità in Azure, vedere Che cosa sono le zone 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 di aree che supportano le zone di disponibilità, vedere Aree di Azure con zone di disponibilità.
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 zone di disponibilità abilitate
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:
- Spostarsi sul 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.
- Selezionare 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 la panoramica dell'architettura di networking.
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.
Tecniche di distribuzione sicura
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.
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 e continuità aziendale tra aree
Il ripristino di emergenza si occupa del ripristino in caso di eventi a impatto elevato, come disastri 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 a un piano di ripristino di emergenza, vedere Raccomandazioni per la progettazione di una strategia di ripristino di emergenza.
Nell'ambito del ripristino di emergenza, Microsoft usa il modello di responsabilità condivisa. In un modello basato sulla responsabilità condivisa, Microsoft garantisce che l'infrastruttura di base e i servizi della piattaforma siano disponibili. Allo stesso tempo, molti servizi di Azure non replicano automaticamente i dati o eseguono il fallback da un'area in cui si è verificato un errore per effettuare la replica incrociata in un'altra area abilitata. Per questi servizi, si è responsabili 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 (Piattaforma distribuita come servizio) di Azure forniscono funzionalità e indicazioni per supportare il ripristino di emergenza ed è possibile usare funzionalità specifiche del servizio per supportare il ripristino rapido e sviluppare il 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.
Materiale sussidiario
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