Condividi tramite


Baseline di migrazione delle zone di disponibilità di Azure

Questo articolo illustra come valutare l'idoneità della zona di disponibilità dell'applicazione ai fini della migrazione dalla zona non di disponibilità al supporto della zona di disponibilità. Verranno illustrati i passaggi necessari per determinare in che modo è possibile sfruttare il supporto della zona di disponibilità in linea con i requisiti dell'applicazione e dell'area. Per informazioni più dettagliate sulle zone di disponibilità e sulle aree che le supportano, vedere Che cosa sono le aree di Azure e le zone di disponibilità.

Quando si creano carichi di lavoro affidabili, è possibile scegliere almeno una delle configurazioni della zona di disponibilità seguenti:

  • A zona. Una configurazione di zona fornisce una zona di disponibilità specifica e selezionata automaticamente.

  • Con ridondanza della zona. Una configurazione con ridondanza della zona fornisce risorse replicate o distribuite automaticamente tra zone.

Oltre alle due opzioni della zona di disponibilità, zonale e con ridondanza della zona, Azure offre servizi globali, ovvero disponibili a livello globale indipendentemente dall'area. Poiché questi servizi sono sempre disponibili in più aree, sono resilienti alle interruzioni a livello di area e di zona.

Per informazioni sui servizi di Azure che supportano le zone di disponibilità, vedere Servizio di zona di disponibilità e supporto a livello di area.

Nota

Quando non si seleziona una configurazione della zona per la risorsa, zonale o con ridondanza della zona, la risorsa e i relativi componenti secondari non saranno resilienti per la zona e potranno disattivarsi durante un'interruzione di zona in tale area.

Considerazioni sulla migrazione al supporto della zona di disponibilità

Esistono diversi modi possibili per creare un'applicazione Azure affidabile con zone di disponibilità che soddisfano i contratti di servizio e gli obiettivi di affidabilità. Seguire la procedura seguente per scegliere l'approccio appropriato per le proprie esigenze in base a considerazioni tecniche e normative, funzionalità del servizio, residenza dei dati, requisiti di conformità e latenza.

Passaggio 1: Verificare se l'area di Azure supporta le zone di disponibilità

In questo primo passaggio è necessario convalidare che l'area di Azure selezionata supporti le zone di disponibilità e i servizi di Azure necessari per l'applicazione.

Se l'area supporta le zone di disponibilità, è consigliabile configurare il carico di lavoro per le zone di disponibilità. Se l'area non supporta le zone di disponibilità, è necessario seguire le linee guida di Spostamento risorse di Azure per eseguire la migrazione a un'area che offre supporto per la zona di disponibilità.

Nota

Per alcuni servizi, le zone di disponibilità possono essere configurate solo durante la distribuzione. Se si desidera includere zone di disponibilità per i servizi esistenti, potrebbe essere necessario effettuare la ridistribuzione. Vedere la documentazione specifica del servizio in Panoramica della migrazione della zona di disponibilità per i prodotti e i servizi di Microsoft Azure.

Passaggio 2: Verificare la disponibilità di prodotti e SKU nell'area di Azure

In questo passaggio si verifica che i servizi e gli SKU di Azure necessari siano disponibili nelle zone di disponibilità dell'area di Azure selezionata.

Per verificare il supporto a livello di area dei servizi, vedere Prodotti disponibili in base all'area.

Per elencare gli SKU di macchina virtuale disponibili in base all'area e alla zona di Azure, vedere Controllare la disponibilità degli SKU della macchina virtuale.

Se l'area non supporta i servizi e gli SKU richiesti dall'applicazione, è necessario tornare al Passaggio 1: Controllare la disponibilità del prodotto nell'area di Azure per trovare una nuova area che supporti i servizi e gli SKU richiesti dall'applicazione. È consigliabile configurare il carico di lavoro con ridondanza della zona.

Per la disponibilità elevata di zona delle macchine virtuali IaaS di Azure, usare Set di scalabilità di macchine virtuali (VMSS) Flex per distribuire le macchine virtuali tra più zone di disponibilità.

Passaggio 3: Considerare i requisiti dell'applicazione

In questo passaggio finale si determinerà, in base ai requisiti dell'applicazione, il tipo di supporto della zona di disponibilità più adatto per l'applicazione.

Di seguito sono riportate tre domande importanti che consentono di scegliere la distribuzione corretta della zona di disponibilità:

L'applicazione include componenti sensibili alla latenza?

Le zone di disponibilità di Azure all'interno della stessa area di Azure sono connesse da una rete a prestazioni elevate con una latenza andata/ritorno inferiore a 2 ms.

L'approccio consigliato per ottenere la disponibilità elevata, se la bassa latenza non è un requisito rigoroso, consiste nel configurare il carico di lavoro con una distribuzione con ridondanza della zona.

Per i componenti critici dell'applicazione che richiedono prossimità fisica e bassa latenza, ad esempio giochi, simulazione di progettazione e trading ad alta frequenza (HFT), è consigliabile configurare una distribuzione di zona. Il set di scalabilità di macchine virtuali Flex fornisce risorse di calcolo allineate alla zona insieme ai dischi di archiviazione collegati.

Il codice dell'applicazione è in grado di gestire un modello distribuito?

Per un modello di microservizi distribuiti e a seconda dell'applicazione, è possibile scambiare dati tra microservizi tra zone. Questo scambio continuo di dati tramite le API potrebbe influire sulle prestazioni. Per migliorare le prestazioni e mantenere un'architettura affidabile, è possibile scegliere la distribuzione a livello di zona.

Con una distribuzione a livello di zona, è necessario:

  1. Identificare le risorse o i servizi sensibili alla latenza nell'architettura.

  2. Verificare che le risorse o i servizi sensibili alla latenza supportino la distribuzione a livello di zona.

  3. Individuare le risorse o i servizi sensibili alla latenza nella stessa zona. Altri servizi nell'architettura potrebbero continuare a rimanere ridondanti nella zona.

  4. Replicare i servizi di zona sensibili alla latenza in più zone di disponibilità per garantire la resilienza della zona.

  5. Bilanciare il carico tra più distribuzioni di zona con un bilanciamento del carico standard o globale.

Se il servizio di Azure supporta le zone di disponibilità, è consigliabile usare la ridondanza della zona distribuendo i nodi tra le zone per ottenere un contratto di servizio con tempi di attività più elevati e la protezione dalle interruzioni di zona.

Per un'applicazione a 3 livelli è importante comprendere i livelli di applicazione, business e dati, nonché il relativo stato (con stato o senza) per effettuare progettazioni in linea con le procedure consigliate e le indicazioni in base al tipo di carico di lavoro.

Per carichi di lavoro specializzati in Azure come illustrato di seguito, vedere le rispettive linee guida e procedure consigliate per l'architettura della zona di destinazione.

Si vuole ottenere continuità aziendale e ripristino di emergenza nella stessa area di Azure a causa di requisiti di conformità, residenza dei dati o governance?

Per ottenere la continuità aziendale e il ripristino di emergenza all'interno della stessa area e quando non è presente alcuna coppia regionale, è consigliabile configurare il carico di lavoro con ridondanza della zona. Un approccio ad area singola è applicabile anche a determinati settori con requisiti rigorosi di residenza e governance dei dati all'interno della stessa area di Azure. Per informazioni su come eseguire la replica, il failover e il failback delle macchine virtuali di Azure da una zona di disponibilità a un'altra, nella stessa area di Azure, vedere Abilitare il ripristino di emergenza di macchine virtuali di Azure tra zone di disponibilità.

Se sono necessarie più aree o se l'area di Azure non supporta le zone di disponibilità, è consigliabile usare coppie di aree. Le coppie regionali si trovano a circa 160 chilometri di distanza e offrono protezione da guasti a livello regionale come incendi, inondazioni, terremoti e altre calamità naturali o impreviste. Per altre informazioni, vedere Replica tra aree in Azure: continuità aziendale e ripristino di emergenza.

Nota

Esistono scenari in cui una combinazione di servizi a livello di zona, con ridondanza della zona e globali è ottimale per soddisfare i requisiti aziendali e tecnici.

Altri punti da considerare

  • Per informazioni sul test delle applicazioni per la disponibilità e la resilienza, vedere Test delle applicazioni per la disponibilità e la resilienza.

  • Ogni data center in un'area viene assegnato a una zona fisica. Le zone fisiche vengono mappate alle zone logiche nella sottoscrizione di Azure. Le sottoscrizioni di Azure vengono assegnate automaticamente a questo mapping quando vengono create. È possibile usare l'API REST ARM dedicata, listLocations, e impostare la versione dell'API su 2022-12-01 per elencare il mapping della zona logica alla zona fisica per la sottoscrizione. Queste informazioni sono importanti per i componenti critici delle applicazioni che richiedono la condivisione della posizione con le risorse di Azure classificate come servizi strategici che potrebbero non essere disponibili in tutte le zone fisiche.

Passaggi successivi