Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo articolo descrive il supporto per l'affidabilità in Istanze di Azure Container, che offre un modo semplice per eseguire contenitori Linux o Windows in Azure, senza la necessità di gestire macchine virtuali o adottare un servizio più complesso di livello superiore.
Quando si usa Azure, l'affidabilità è una responsabilità condivisa. Microsoft offre una gamma di funzionalità per supportare la resilienza e il ripristino. L'utente è responsabile della comprensione del funzionamento di tali funzionalità all'interno di tutti i servizi usati e della selezione delle funzionalità necessarie per soddisfare gli obiettivi aziendali e gli obiettivi di tempo di attività.
Questo articolo descrive come rendere resilienti istanze di Azure Container a un'ampia gamma di potenziali interruzioni e problemi, tra cui errori temporanei, interruzioni della zona di disponibilità e interruzioni dell'area. Vengono evidenziate alcune informazioni chiave sull'accordo sul livello di servizio (SLA) delle Azure Container Instances.
Raccomandazioni per la distribuzione di produzione per l'affidabilità
Per aumentare l'affidabilità delle applicazioni di produzione basate su Istanze di Container, è consigliabile eseguire le azioni seguenti:
- Eseguire le applicazioni in più zone di disponibilità.
- Valutare se eseguire anche gruppi di contenitori separati in più aree.
- Usare probe di liveness per rilevare e riavviare automaticamente i contenitori non integri.
- Usare sonde di disponibilità per attendere che i contenitori siano pronti prima di ricevere traffico.
- Usare gli aggiornamenti in sequenza per applicare progressivamente le modifiche se si usano NGroups. Questo approccio riduce la probabilità di tempi di inattività a causa degli aggiornamenti.
- Esaminare le procedure consigliate e le considerazioni per Container Instances.
Panoramica dell'architettura di affidabilità
Per utilizzare le Istanze di Contenitore, distribuisci il gruppo di contenitori. Un gruppo di contenitori contiene uno o più contenitori. Ogni contenitore viene creato da un'immagine del contenitore archiviata in un registro, ad esempio Registro Azure Container.
Tutti i contenitori in un gruppo di contenitori vengono distribuiti insieme come singola unità logica e condividono la stessa infrastruttura fisica.
Il diagramma seguente illustra la relazione tra gruppi di contenitori, contenitori e immagini.
L'immagine mostra due contenitori all'interno di una sezione del gruppo di contenitori. Due linee tratteggiate collegano i contenitori a due sezioni dell'immagine nella sezione del Registro di sistema.
Istanze di Container offre le funzionalità seguenti per gestire i gruppi di contenitori:
NGroups (anteprima) offre un set di funzionalità per gestire più gruppi di contenitori correlati. Quando si crea un NGroup, si definisce il numero di gruppi di contenitori da creare. Istanze di Contenitore offre funzionalità come le implementazioni automatizzate degli aggiornamenti e la distribuzione di gruppi di contenitori tra zone di disponibilità.
Pool di standby crea un gruppo di contenitori con pre-provisioning che possono essere utilizzati in risposta al traffico in entrata. I pool di standby sono progettati per ottimizzare la creazione di gruppi di contenitori e non sono progettati per aumentare la resilienza.
Resilienza a errori temporanei
Gli errori temporanei sono errori brevi e intermittenti nei componenti. Si verificano spesso in un ambiente distribuito come il cloud e fanno parte delle normali operazioni. Gli errori temporanei si correggono dopo un breve periodo di tempo. È importante che le applicazioni possano gestire gli errori temporanei, in genere ritentando le richieste interessate.
Tutte le applicazioni ospitate nel cloud devono seguire le indicazioni sulla gestione degli errori temporanei di Azure quando comunicano con qualsiasi API, database e altri componenti ospitati nel cloud. Per altre informazioni, vedere Raccomandazioni per la gestione degli errori temporanei.
In genere, gli SDK forniti da Microsoft gestiscono gli errori temporanei. Poiché si ospitano applicazioni personalizzate in Istanze di Container, eseguire le operazioni necessarie per ridurre la probabilità di errori temporanei:
Eseguire più gruppi di contenitori per carichi di lavoro importanti per assicurarsi che un errore in un contenitore o in un gruppo di contenitori non influisca sull'intera applicazione.
Costruire il codice dell'applicazione in modo che sia resiliente agli errori temporanei nei servizi a cui si connettono, ad esempio usando politiche di tentativi ripetuti con strategie di backoff.
Per altre informazioni su altri errori che possono verificarsi in fase di esecuzione e su come rispondere, vedere Problemi durante il runtime del gruppo di contenitori.
Resilienza ai guasti delle zone di disponibilità
Le zone di disponibilità sono gruppi di data center separati fisicamente all'interno di un'area di Azure. In caso di guasto in una zona, i servizi possono passare a una delle zone restanti.
Istanze di Contenitori supporta le zone di disponibilità in modi diversi, a seconda di come distribuisci i tuoi gruppi di contenitori:
Gruppi di contenitori creati manualmente: Un singolo gruppo di contenitori è una risorsa di zona , il che significa che può essere distribuito in una singola zona di disponibilità selezionata. Tutti i contenitori all'interno del gruppo vengono distribuiti nella stessa zona di disponibilità. Se la zona di disponibilità presenta un'interruzione, il gruppo di contenitori e tutti i relativi contenitori potrebbero riscontrare tempi di inattività.
Il diagramma seguente mostra un gruppo di contenitori distribuito manualmente nella zona di disponibilità 1:
L'immagine mostra tre zone di disponibilità: Zona di disponibilità 1, Zona di disponibilità 2 e Zona di disponibilità 3. Un gruppo di contenitori nella zona di disponibilità 1 include due contenitori.
Annotazioni
Per assicurarsi che l'applicazione continui a essere eseguita quando si verifica un'interruzione di una singola zona nell'area, è consigliabile creare almeno due gruppi di contenitori in due zone di disponibilità diverse.
Se non si specificano zone di disponibilità da usare per il gruppo di contenitori, verrà considerato come non zonale o regionale, il che significa che potrebbe essere posizionato in qualsiasi zona di disponibilità all'interno della regione o all'interno della stessa zona. Se una zona di disponibilità nell'area presenta un problema, il gruppo di contenitori potrebbe riscontrare tempi di inattività.
NGroups: Quando si distribuisce un NGroup, è possibile specificare una o più zone in cui distribuirlo. Se si distribuisce un NGroup in due o più zone, si tratta di un NGroup con ridondanza della zona e un'interruzione di una zona di disponibilità causa solo problemi per i gruppi di contenitori all'interno della zona interessata.
Il diagramma seguente mostra un NGroup distribuito in tre zone di disponibilità:
L'immagine mostra tre zone di disponibilità. Ogni zona di disponibilità include un gruppo di contenitori e due contenitori. Un rettangolo con etichetta NGroupdesiredCount=3, zones=1,2,3 si estende su tutte e tre le zone di disponibilità.
Se non si specificano zone di disponibilità da utilizzare per il proprio NGroup, esso è considerato non zonale e potrebbe subire tempi di inattività se si verifica un problema in qualsiasi zona di disponibilità nella regione.
Pool di standby: Quando si distribuisce un pool di standby, è possibile specificare facoltativamente una o più zone. La piattaforma potrebbe richiedere contenitori tra le zone selezionate.
Tuttavia, i pool di standby non supportano la ridondanza o la resilienza della zona perché non esiste alcuna garanzia che i contenitori siano stati creati in più zone. Se si verifica un'interruzione della zona, è possibile che tutti i contenitori della piscina possano essere collocati nella zona interessata.
Poiché i pool di standby non sono progettati per supportare la resilienza agli errori di zona, questa guida non descrive il comportamento dettagliato dei pool di standby con zone di disponibilità.
Importante
I pool di standby non sono progettati per essere resilienti per la zona. Non dovrebbero essere usati per carichi di lavoro che richiedono resilienza ai guasti zonali.
Supporto di area
Le distribuzioni dei gruppi di contenitori di zona sono supportate in tutte le aree con zone di disponibilità.
Requisiti
Le distribuzioni di zona sono disponibili per i gruppi di contenitori Linux e Windows Server 2019.
Per selezionare una zona di disponibilità, è necessario usare lo SKU Standard. I gruppi di contenitori di zona non sono disponibili con lo SKU Riservato.
Considerazioni
I contenitori spot non supportano le zone di disponibilità e sono sempre nonzonali.
Costo
Non sono previsti costi aggiuntivi per configurare le zone di disponibilità per un gruppo di contenitori.
Configurare il supporto delle zone di disponibilità
Creare gruppi di contenitori con il supporto della zona di disponibilità. L'approccio usato per configurare le zone di disponibilità dipende dalla modalità di creazione di gruppi di contenitori.
Gruppi di contenitori creati manualmente: Per creare un gruppo di contenitori di zona in una zona specifica, è possibile usare uno dei metodi seguenti:
NGroups: è possibile distribuire un NGroup con ridondanza della zona usando un modello di ARM e specificando più zone. Per ulteriori informazioni, vedere NGroups with zones sample.
Pool di standby: È possibile distribuire un pool di standby che usa le zone di disponibilità specificando una o più zone durante la creazione o l'aggiornamento del pool. Tuttavia, i contenitori potrebbero non essere creati in più zone. I pool di standby non devono essere usati per i carichi di lavoro che richiedono resilienza agli errori di zona. Per altre informazioni, vedere Creare un pool di standby per Container Instances.
Abilitare il supporto della zona di disponibilità per le risorse esistenti. L'approccio usato per configurare le zone di disponibilità dipende dalla modalità di creazione di gruppi di contenitori.
Gruppi di contenitori creati manualmente: Non è possibile abilitare le zone di disponibilità in un gruppo di contenitori non a livello di zona esistente. È necessario eliminare il gruppo di contenitori e creare un gruppo di contenitori di zona.
NGroups: Non è possibile abilitare le zone di disponibilità in un NGroup non di zona esistente. È necessario eliminare il NGroup e creare un NGroup con ridondanza della zona.
Pool di standby: Non è possibile abilitare le zone di disponibilità in un pool di standby non di zona esistente. È necessario eliminare il gruppo di contenitori e creare un nuovo pool di standby che usa più zone di disponibilità.
Spostare gruppi di contenitori tra zone o disabilitare il supporto della zona di disponibilità. L'approccio usato per modificare le zone di disponibilità dipende dalla modalità di creazione di gruppi di contenitori.
Gruppi di contenitori creati manualmente: Per modificare la zona di disponibilità di un gruppo di contenitori, è necessario eliminare il gruppo di contenitori e creare un altro gruppo di contenitori con la nuova zona di disponibilità. Per informazioni su come eliminare il gruppo di contenitori, vedere le risorse seguenti:
NGroups: È possibile aggiungere zone a un NGroup, ma non è possibile rimuovere le zone.
Pool di standby: È possibile aggiungere zone a un pool di standby, ma non è possibile rimuovere le zone.
Distribuzione dei gruppi di contenitori
Il modo in cui i gruppi di contenitori vengono distribuiti tra zone di disponibilità dipende dalla modalità di distribuzione dei gruppi di contenitori.
Gruppi di contenitori creati manualmente: Si è responsabili della distribuzione manuale dei gruppi di contenitori creati in più zone di disponibilità.
NGroups: Durante le operazioni di scalabilità orizzontale, NGroups elimina in modo casuale le istanze, che potrebbero non mantenere una distribuzione tra le zone di disponibilità. Le operazioni di scalabilità orizzontale tentano di ribilanciare la distribuzione tra le zone.
Pool di standby: Un pool di standby può creare contenitori in una qualsiasi delle zone di disponibilità configurate nel pool. Tuttavia, i contenitori potrebbero non essere creati in più zone. I pool di standby non devono essere usati per i carichi di lavoro che richiedono resilienza agli errori di zona.
Pianificazione e gestione della capacità
Per prepararsi a un guasto in una zona di disponibilità, prendere in considerazione il provisioning eccessivo del numero di gruppi di contenitori distribuiti. Questo approccio consente alla soluzione di tollerare alcune perdite di capacità e continuare a funzionare senza riduzione delle prestazioni. Per altre informazioni, vedere Gestire la capacità usando l'overprovisioning.
L'approccio usato per effettuare l'overprovisioning dei gruppi di contenitori dipende dalla modalità di distribuzione dei gruppi di contenitori.
Gruppi di contenitori creati manualmente: Si è responsabili della pianificazione della capacità dei gruppi di contenitori creati manualmente, inclusa la pianificazione del numero di gruppi di contenitori da distribuire in ogni zona.
NGroup: valutare di eseguire il provisioning eccessivo della capacità del NGroup per tollerare la perdita di una zona.
Pool di standby: I pool di standby non sono progettati per essere resilienti ai guasti di zona. È consigliabile usare più pool di standby in zone diverse o usare NGroups.
Comportamento quando tutte le zone sono integre
Questa sezione descrive cosa aspettarsi quando le risorse di Istanze di Container sono configurate per il supporto della zona di disponibilità e tutte le zone di disponibilità sono operative.
Instradamento del traffico tra zone: Sei responsabile dell'instradamento del traffico ai tuoi contenitori. Ad esempio, è possibile usare Azure Application Gateway come gateway e bilanciatore di carico per i gruppi di contenitori.
Se si usano NGroups o pool di standby, si è responsabili del bilanciamento del carico tra i contenitori. È anche necessario configurare il sistema di routing del traffico per rilevare l'integrità di ogni gruppo di contenitori e reindirizzare il traffico a un gruppo alternativo quando necessario.
Replica dei dati tra zone: i contenitori e i gruppi di contenitori sono senza stato. È possibile collegare una condivisione file personalizzata o connettersi ai database o ad altri servizi di archiviazione dall'interno delle applicazioni. Sei responsabile di garantire che le condivisioni di file e i servizi di archiviazione siano zone resistenti. Esaminare le guide all'affidabilità per ogni servizio per comprendere come rendere resiliente ogni zona del componente.
Comportamento durante un errore di zona
Questa sezione descrive cosa aspettarsi quando le risorse di Istanze di Contenitore sono configurate per il supporto della zona di disponibilità e si verifica un'interruzione della zona di disponibilità.
Rilevamento e risposta: La responsabilità del rilevamento degli errori di zona e della risposta associata dipende dalla modalità di distribuzione dei gruppi di contenitori.
Gruppi di contenitori creati manualmente: È necessario rilevare la perdita di una zona di disponibilità e avviare un failover in un gruppo di contenitori secondario creato in un'altra zona di disponibilità.
NGroups: La piattaforma Istanze di Container è responsabile del rilevamento di un errore in una zona di disponibilità e della risposta.
Tuttavia, si è responsabili di garantire che il traffico venga instradato ai contenitori in una zona integra.
Pool di standby: la piattaforma Istanze di Container non garantisce una risposta ai guasti di zona per i pool di standby. I pool di standby non devono essere usati per i carichi di lavoro che richiedono resilienza agli errori di zona.
- Notifica: Microsoft non invia automaticamente una notifica quando una zona è inattiva. È tuttavia possibile usare Integrità dei servizi di Azure per comprendere l'integrità complessiva del servizio, inclusi eventuali errori di zona, ed è possibile configurare gli avvisi di integrità dei servizi per notificare eventuali problemi.
Richieste attive: Se una zona ha esito negativo, è probabile che tutti i contenitori in esecuzione in tale zona vengano interrotti, incluse le operazioni attive che gestiscono
Perdita di dati prevista: Poiché i contenitori e i gruppi di contenitori sono senza stato, non è prevista alcuna perdita di dati da un errore di zona. Tuttavia, si è responsabili di garantire che ogni componente del carico di lavoro sia resiliente alla zona, inclusi i servizi di archiviazione e i database.
Tempo di inattività previsto: Il tempo di inattività previsto da un errore di zona dipende dalla modalità di distribuzione dei gruppi di contenitori.
Gruppi di contenitori creati manualmente: Per i gruppi di contenitori di zona, quando una zona non è disponibile, il gruppo di contenitori e i relativi contenitori non sono disponibili fino al ripristino della zona di disponibilità.
NGroups: Per gli NGroups, se una zona diventa inattiva, l'applicazione rimane disponibile perché i gruppi di contenitori rimanenti all'interno degli NGroups continuano a funzionare in altre zone. Non è previsto alcun tempo di inattività.
Pool di standby: I pool di standby non forniscono resilienza di zona. Se tutti i gruppi di contenitori nel pool di standby si trovano in una singola zona, è possibile che tutti i gruppi di contenitori e i relativi contenitori non siano disponibili fino al ripristino della zona di disponibilità.
Reindirizzamento del traffico: Poiché si è responsabili dell'instradamento del traffico ai container, si è anche responsabili del reindirizzamento del traffico se un gruppo di container non funziona a causa di un'interruzione in una zona di disponibilità.
Ripristino della zona
Dopo il ripristino della zona, la piattaforma Azure riavvia automaticamente i gruppi di contenitori arrestati. Non è richiesto alcun intervento da parte del cliente.
Verifica dei guasti di zona
Non è possibile simulare un'interruzione della zona di disponibilità che contiene il gruppo di contenitori. Tuttavia, è possibile configurare manualmente gateway upstream o servizi di bilanciamento del carico per reindirizzare il traffico a un gruppo di contenitori diverso in una zona di disponibilità diversa.
Resilienza agli errori a livello di area
Container Instances è un servizio a singola regione. Se l'area non è più disponibile, anche i gruppi di contenitori e i relativi contenitori non sono disponibili.
Soluzioni personalizzate in più aree per la resilienza
Facoltativamente, è possibile distribuire gruppi di contenitori separati in più aree. Si è responsabili della distribuzione e della configurazione dei gruppi di contenitori in ogni area. È anche necessario configurare il bilanciamento del carico usando un servizio come Gestione traffico di Azure o Frontdoor di Azure. L'utente è responsabile della sincronizzazione dei dati, del failover e del failback.
Contratto di servizio
Il contratto di servizio per i servizi di Azure descrive la disponibilità prevista di ogni servizio e le condizioni che la soluzione deve soddisfare per raggiungere tale aspettativa di disponibilità. Per altre informazioni, vedere Contratti di servizio per Servizi online.