Affidabilità in Gestione traffico di Azure
Questo articolo contiene raccomandazioni specifiche per l'affidabilità per Gestione traffico di Azure, nonché il ripristino di emergenza tra aree e il supporto della continuità aziendale per Gestione traffico di Azure.
Per una panoramica più dettagliata dei principi di affidabilità in Azure, vedere Affidabilità di Azure.
Raccomandazioni relative all'affidabilità
Questa sezione contiene raccomandazioni per ottenere resilienza e disponibilità. Ogni raccomandazione rientra in una delle due categorie seguenti:
Gli elementi di integrità riguardano aree come gli elementi di configurazione e la corretta funzione dei componenti principali che costituiscono il carico di lavoro di Azure, ad esempio le impostazioni di configurazione delle risorse di Azure, le dipendenze da altri servizi e così via.
Gli elementi di rischio riguardano aree quali requisiti di disponibilità e ripristino, test, monitoraggio, distribuzione e altri elementi che, se lasciati non risolti, aumentano le probabilità di problemi nell'ambiente.
Matrice di priorità delle raccomandazioni per l'affidabilità
Ogni raccomandazione è contrassegnata in base alla matrice di priorità seguente:
| Immagine | Priorità | Descrizione |
|---|---|---|
|
Fortemente | Correzione immediata necessaria. |
|
Medio | Correzione entro 3-6 mesi. |
|
Basso | Deve essere esaminato. |
Riepilogo delle raccomandazioni per l'affidabilità
Disponibilità
Gestione traffico Stato monitoraggio deve essere online
Monitorare lo stato deve essere online per fornire il failover per il carico di lavoro dell'applicazione. Se l'integrità del Gestione traffico visualizza uno stato Danneggiato, lo stato di uno o più endpoint può essere danneggiato.
Per altre informazioni Gestione traffico il monitoraggio degli endpoint, vedere monitoraggio degli endpoint Gestione traffico.
Per risolvere i problemi relativi a uno stato danneggiato in Gestione traffico di Azure, vedere Risoluzione dei problemi relativi allo stato danneggiato in Gestione traffico di Azure.
I profili di Gestione traffico devono avere più di un endpoint
Quando si configura Gestione traffico di Azure, è necessario effettuare il provisioning di almeno due endpoint per eseguire il failover del carico di lavoro in un'altra istanza.
Per informazioni sui tipi di endpoint Gestione traffico, vedere Gestione traffico endpoint.
Efficienza del sistema
Il valore TTL dei profili utente deve essere espresso in 60 secondi
Quando il client effettua una richiesta a Gestione traffico di Azure, riceverà una risposta più o meno recente a seconda della durata (TTL). La riduzione del valore TTL significa che, in caso di failover, il client verrà instradato più velocemente a un endpoint funzionante. Configurare TTL su 60 secondi per instradare il traffico a un endpoint integro il più rapidamente possibile.
Per altre informazioni sulla configurazione del TTL DNS, vedere Configurare la durata (TTL) DNS.
Ripristino di emergenza
Configurare almeno un endpoint all'interno di un'altra area
I profili devono avere più di un endpoint per garantire la disponibilità in caso di errore di uno degli endpoint. È inoltre consigliabile che gli endpoint si trovino in aree diverse.
Per informazioni sui tipi di endpoint Gestione traffico, vedere Gestione traffico endpoint.
Assicurarsi che l'endpoint sia configurato su "(Tutto il mondo)" per i profili geografici
Per il routing geografico, il traffico viene instradato agli endpoint in base alle aree definite. Se si verificano errori in un'area, non vi sono failover predefiniti. Avere un endpoint in cui il raggruppamento a livello di area è configurato su "Tutto (Mondo)" per i profili geografici eviterà il traffico nero e garantirà che il servizio rimanga disponibile.
Per informazioni su come aggiungere e configurare un endpoint, vedere Aggiungere, disabilitare, abilitare, eliminare o spostare gli endpoint.
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 tali servizi, l'utente ha la responsabilità di configurare un piano di ripristino di emergenza che funzioni per i propri carichi 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.
Gestione traffico di Azure è un servizio di bilanciamento del carico del traffico basato su DNS che consente di distribuire il traffico alle applicazioni pubbliche tra aree di Azure globali. Gestione traffico fornisce anche agli endpoint pubblici disponibilità elevata e velocità di risposta rapida.
Gestione traffico usa DNS per indirizzare le richieste client all'endpoint di servizio appropriato in base a un metodo di routing del traffico. Gestione traffico fornisce anche il monitoraggio dell'integrità per ogni endpoint. L'endpoint può essere qualsiasi servizio con connessione Internet ospitato all'interno o all'esterno di Azure. Gestione traffico offre diversi metodi di routing del traffico e opzioni di monitoraggio degli endpoint per soddisfare le diverse esigenze delle applicazioni e i modelli di failover automatico. Gestione traffico è resiliente agli errori, incluso l'errore di un'intera area di Azure.
Ripristino di emergenza nell'area geografica in più aree
DNS è uno dei meccanismi più efficienti per deviare il traffico di rete. DNS è efficiente perché DNS è spesso globale ed esterno al data center. DNS è inoltre isolato da eventuali errori a livello di zona o di disponibilità (AZ).
Per configurare un'architettura di ripristino di emergenza è possibile adottare due diverse strategie:
Uso di un meccanismo di distribuzione per replicare le istanze, i dati e le configurazioni tra l'ambiente primario e quello di standby. Questo tipo di ripristino di emergenza può essere eseguito in modo nativo tramiteAzure Site Recovery, vedere la documentazione di Azure Site Recovery tramite appliance/servizi partner di Microsoft Azure, ad esempio Veritas o NetApp.
Sviluppo di una soluzione per deviare il traffico Web o di rete dal sito primario a quello di standby. Questo tipo di ripristino di emergenza può essere ottenuto tramite DNS di Azure, Gestione traffico di Azure(DNS) o servizi di bilanciamento del carico globale di terze parti.
Questo articolo è incentrato in particolare sulla pianificazione del ripristino di emergenza Gestione traffico di Azure.
Rilevamento, notifica e gestione di interruzioni
Durante un'emergenza, l'endpoint primario viene sottoposto a sondaggio tramite probe, lo stato diventa danneggiato e il sito di ripristino di emergenza rimane Online. Per impostazione predefinita, tutto il traffico viene inviato all'endpoint primario (con priorità più elevata). Se l'endpoint primario risulta danneggiato, Gestione traffico indirizza il traffico verso il secondo endpoint purché rimanga integro. È possibile configurare più endpoint all'interno di Gestione traffico che possono fungere da endpoint di failover aggiuntivi o come servizi di bilanciamento del carico che condividono il carico tra endpoint.
Configurare il ripristino di emergenza e il rilevamento di interruzioni
Se si hanno architetture complesse e più set di risorse in grado di eseguire la stessa funzione, è possibile configurare Gestione traffico di Azure (basato su DNS) per controllare l'integrità delle risorse e indirizzare il traffico dalla risorsa non integra a quella integra.
Nell'esempio seguente l'area primaria e quella secondaria presentano una distribuzione completa. Questa distribuzione include i servizi cloud e un database sincronizzato.
Figura: Failover automatico con Gestione traffico di Azure
Tuttavia, solo l'area primaria gestisce attivamente le richieste di rete degli utenti. Quella secondaria si attiva solo quando nell'area primaria si verifica un'interruzione del servizio. In questo caso tutte le richieste di rete vengono reindirizzate all'area secondaria. Poiché il backup del database è quasi istantaneo, entrambi i servizi di bilanciamento del carico hanno indirizzi IP di cui può essere controllata l'integrità e le istanze sono sempre in esecuzione, questa topologia offre una buona opzione per una configurazione con basso RTO e failover senza intervento manuale. L'area di failover secondaria deve essere pronta ad attivarsi immediatamente in caso di problemi con quella primaria.
Questo scenario è ideale per l'uso di Gestione traffico di Azure con probe incorporati per vari tipi di controlli di integrità, inclusi HTTP/HTTPS e TCP. Gestione traffico di Azure include anche un motore regole che può essere configurato per il failover quando si verifica un errore, come descritto di seguito. Si consideri la soluzione seguente che prevede l'uso di Gestione traffico:
- Il cliente ha un endpoint di Area 1, denominato prod.contoso.com, con indirizzo IP statico 100.168.124.44 e un endpoint di Area 2, denominato dr.contoso.com, con indirizzo IP statico 100.168.124.43.
- Ognuno di questi ambienti è gestito tramite una proprietà pubblica come servizio di bilanciamento del carico. Quest'ultimo può essere configurato con un endpoint basato su DNS o un nome di dominio completo (FQDN), come illustrato in precedenza.
- Tutte le istanze in Area 2 vengono replicate quasi in tempo reale con Area 1. Inoltre, le immagini del computer sono aggiornate e tutti i dati di software/configurazione vengono patchati e sono in linea con l'area 1.
- La scalabilità automatica è preconfigurata in anticipo.
Per configurare il failover con Gestione traffico di Azure:
Creare un nuovo profilo di Gestione traffico di Azure Creare un nuovo profilo di Gestione traffico di Azure con il nome contoso123 e selezionare il metodo Routing come Priorità. Se si ha già un gruppo di risorse da associare al profilo, è possibile selezionarlo, altrimenti crearne uno nuovo.
Figura - Creare un profilo di Gestione traffico
Creare endpoint all'interno del profilo di Gestione traffico
In questo passaggio si creano endpoint che puntano ai siti di produzione e di ripristino di emergenza. In questo caso, scegliere un endpoint esterno come Tipo, ma se la risorsa è ospitata in Azure, è possibile scegliere anche Endpoint Azure. Se si sceglie Endpoint Azure, selezionare come Risorsa di destinazione un servizio App o un IP pubblico allocato da Azure. La priorità è impostata su 1 perché è il servizio primario per l'area 1. Con una procedura analoga, creare l'endpoint di ripristino di emergenza anche all'interno di Gestione traffico.
Figura: Creare endpoint di ripristino di emergenza
Definire la configurazione per il controllo di integrità e il failover
In questo passaggio si imposta la durata TTL di DNS su 10 secondi, un valore che viene rispettato dalla maggior parte dei resolver ricorsivi con connessione Internet. Questa configurazione indica che nessun resolver DNS memorizzerà le informazioni nella cache per più di 10 secondi.
Per le impostazioni di monitoraggio degli endpoint, il percorso è impostato sulla radice (o /), ma è possibile personalizzare le impostazioni degli endpoint in modo da valutare un percorso, ad esempio prod.contoso.com/index.
Come protocollo di sondaggio nell'esempio seguente è impostato HTTPS, ma è possibile scegliere anche HTTP o TCP. La scelta del protocollo dipende dall'applicazione finale. L'intervallo di sondaggio è impostato su 10 secondi, in modo da consentire un'individuazione rapida tramite probe, e come valore di retry è impostato 3. Di conseguenza, Gestione traffico eseguirà il failover al secondo endpoint se tre intervalli consecutivi registrano un errore.
La formula seguente definisce il tempo totale per un failover automatizzato:
Time for failover = TTL + Retry * Probing intervalIn questo caso, il valore è 10 + 3 * 10 = 40 secondi (max).
Se il valore di retry è impostato su 1 e la durata TTL su 10 secondi, il tempo per il failover sarà 10 + 1 * 10 = 20 secondi.
Impostare il valore di retry su un valore maggiore di 1 per evitare l'esecuzione del failover a causa di falsi positivi o problemi di rete irrilevanti.
Figura: Definire la configurazione per il controllo di integrità e il failover
Passaggi successivi
Altre informazioni su Gestione traffico di Azure.
Altre informazioni su DNS di Azure.