Affidabilità in DNS di Azure

Questo articolo contiene informazioni dettagliate sul ripristino di emergenza tra aree e sul supporto della continuità aziendale per DNS di Azure.

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.

La soluzione di failover DNS di Azure per il ripristino di emergenza usa il meccanismo DNS standard per eseguire il failover nel sito di backup. L'opzione manuale tramite DNS di Azure funziona meglio quando viene usata in combinazione con l'approccio di standby a freddo o la luce pilota.

Poiché il server DNS si trova all'esterno del failover o della zona di emergenza, è isolato da qualsiasi tempo di inattività. È possibile progettare uno scenario di failover semplice, purché l'operatore abbia connettività di rete durante l'emergenza e possa fare il capovolgimento. Se la soluzione viene inserita in uno script, è necessario assicurarsi che anche il server o il servizio che esegue lo script sia isolato dal problema che interessa l'ambiente di produzione. Inoltre, una durata TTL bassa per la zona impedisce la memorizzazione nella cache del resolver in lunghi periodi di tempo, consentendo al cliente di accedere al sito all'interno dell'RTO. Per uno standby sporadico e una luce pilota, poiché è possibile che sia necessaria una certa prewarming e altre attività amministrative, è consigliabile anche dare tempo sufficiente prima di fare il capovolgimento.

Per informazioni su come creare una zona DNS privata di Azure usando il portale di Azure, vedere Avvio rapido: Creare una zona DNS privata di Azure usando il portale di Azure.

Per creare un sistema di risoluzione privato DNS di Azure usando portale di Azure, vedere Avvio rapido: Creare un sistema di risoluzione privato DNS di Azure usando il portale di Azure.

Ripristino di emergenza nell'area geografica in più aree

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 di DNS di Azure.

Configurare il ripristino di emergenza e il rilevamento di interruzioni

La soluzione di failover manuale di DNS di Azure per il ripristino di emergenza usa il meccanismo DNS standard per eseguire il failover nel sito di backup. L'opzione manuale tramite DNS di Azure risulta più efficace quando è usata in combinazione con l'approccio con luce pilota o cold standby.

Figura: Failover manuale con DNS di Azure

La soluzione si basa sui presupposti seguenti:

• L'endpoint primario e quello secondario hanno indirizzi IP statici che non cambiano di frequente. Ad esempio, per il sito primario l'indirizzo IP è 100.168.124.44 e per quello secondario l'indirizzo IP è 100.168.124.43.
• È presente una zona DNS di Azure per entrambi i siti, primario e secondario. Ad esempio, per il sito primario l'endpoint è prod.contoso.com e per il sito di backup l'endpoint è dr.contoso.com. È inoltre presente un record DNS per l'applicazione principale noto come www.contoso.com.
• Il valore TTL è pari o inferiore al valore RTO (Recovery Time Objective, obiettivo del tempo di ripristino) del contratto di servizio impostato nell'organizzazione. Se, ad esempio, un'azienda imposta 60 minuti come RTO della risposta di emergenza dell'applicazione, la durata TTL deve essere inferiore a 60 minuti, preferibilmente il più possibile inferiore a questo valore. È possibile configurare DNS di Azure per il failover manuale come indicato di seguito:
  • Creare una zona DNS
  • Creare record di zona DNS
  • Aggiornare il record CNAME

1. Creare una zona DNS, ad esempio www.contoso.com, come illustrato di seguito:

   

   Figura: Creare una zona DNS in Azure

2. All'interno di questa zona, creare tre record (ad esempio, www.contoso.com, prod.contoso.com e dr.consoto.com) come illustrato di seguito.

   

   Figura: Creare record di zona DNS in Azure

   In questo scenario, il sito www.contoso.com ha una durata TTL pari a 30 minuti, molto inferiore al valore RTO, e punta al sito di produzione prod.contoso.com. Questa è la configurazione durante le normali attività aziendali. La durata TTL di prod.contoso.com e dr.contoso.com è stata impostata su 300 secondi, ovvero 5 minuti. È possibile usare un servizio di monitoraggio di Azure, ad esempio Monitoraggio di Azure o app Azure Insights o qualsiasi soluzione di monitoraggio dei partner, ad esempio Dynatrace. È anche possibile usare soluzioni aziendali che possono monitorare o rilevare errori a livello di applicazione o infrastruttura virtuale.

3. Dopo aver rilevato un errore, modificare il valore del record in modo che punti a dr.contoso.com, come illustrato di seguito:

   

   Figura: Aggiornare il record CNAME in Azure

   Per un intervallo di 30 minuti, durante il quale quasi tutti i resolver aggiorneranno il file di zona memorizzato nella cache, le query inviate a www.contoso.com saranno reindirizzate a dr.contoso.com. Per modificare il valore di CNAME è anche possibile usare il seguente comando dell'interfaccia della riga di comando di Azure:

     az network dns record-set cname set-record \
     --resource-group 123 \
     --zone-name contoso.com \
     --record-set-name www \
     --cname dr.contoso.com
   

   Questo passaggio può essere eseguito manualmente o tramite automazione. Per la modifica manuale è possibile usare la console o l'interfaccia della riga di comando di Azure. Per l'automazione dell'aggiornamento di CNAME, in modo da evitare l'intervento manuale, è possibile usare l'API e l'SDK di Azure. L'automazione può essere compilata tramite funzioni di Azure o all'interno di un'applicazione di monitoraggio di terze parti o anche in locale.

Passaggi successivi

• Affidabilità in Azure
• Altre informazioni su Gestione traffico di Azure.
• Altre informazioni su DNS di Azure.