Creare servizi per le applicazioni resilienti
Per l'organizzazione è necessario soddisfare i requisiti di ripristino, mantenendo allo stesso tempo costi e complessità al minimo.
In questa unità si apprenderà come i cluster di ridondanza geografica e disponibilità consentono di creare resilienza nelle applicazioni. Verranno presentati gli elementi interessati nei failover e nei failback per le applicazioni. Entro la fine dell'unità, si apprenderà anche come e perché implementare una strategia di monitoraggio e notifica.
Aggiungere la ridondanza geografica per le applicazioni
È necessario essere in grado di mantenere in esecuzione le applicazioni, indipendentemente da quanto accade nell'infrastruttura in cui vengono ospitate. Calamità naturali e altri problemi possono fare sì che un'intera area geografica resti senza alimentazione o accesso a Internet. Per rispondere a questi problemi in modo normale e mantenere in esecuzione le applicazioni, è necessario assicurarsi che la ridondanza geografica sia disponibile. Tuttavia, uno sbaglio può essere fatale.
È possibile usare Azure per applicare la ridondanza geografica alle applicazioni locali. Il vantaggio di eseguire un'infrastruttura ridondante per le applicazioni in Azure è che non si è responsabili della gestione e della protezione di una posizione fisica (insieme ai costi associati).
Con Azure è possibile aggiungere ridondanza alle applicazioni con aree che possono trovarsi anche dall'altra parte del mondo, senza gestire alcuna attività di manutenzione. Con la manutenzione viene eseguita automaticamente, si ottiene ridondanza geografica in modo semplice e conveniente.
Usando una connessione VPN da sito a sito, è possibile estendere la rete locale a una rete virtuale che esegue una replica dell'infrastruttura in un'area diversa all'interno di Azure. È possibile usare Gestione traffico di Azure per monitorare l'integrità della rete locale. Se si verifica un problema nell'ambiente locale, è possibile usare l'infrastruttura di replica in Azure, che si trova in un'area geografica diversa.
Analogamente, è possibile configurare la ridondanza geografica per le applicazioni in esecuzione all'interno di Azure. Ad esempio, se le applicazioni vengono eseguite in un gruppo di macchine virtuali di Azure in una rete virtuale, è possibile replicare la stessa configurazione in un'altra area per la ridondanza geografica.
Tramite il peering di reti virtuali è possibile connettere due reti virtuali separate, che vengono considerate una sola. Il traffico per queste due reti non passa attraverso la rete Internet pubblica o un gateway. Le risorse possono connettersi direttamente ad altre risorse come se si trovassero nella stessa rete.
In questo caso, Gestione traffico esamina le due aree monitorando l'integrità di ogni endpoint. Se si verifica un problema nell'area primaria, Gestione traffico reindirizza la domanda all'area secondaria.
Aggiungere cluster a disponibilità elevata
Il clustering a disponibilità elevata assicura che i carichi di lavoro restino disponibili e in esecuzione con tempo di inattività minimo. È possibile usare cluster a disponibilità elevata in uno di questi tipi di architettura:
Architettura attiva-attiva: consente di distribuire e bilanciare il carico della domanda tra più nodi, ad esempio due macchine virtuali di Azure identiche. Queste macchine virtuali di Azure possono essere eseguite insieme e condividere la richiesta. È anche possibile distribuire la richiesta a questi nodi in base a metodi di routing diversi.
Il diagramma seguente mostra un esempio generale di un cluster attivo-attivo.
Architettura attiva-passiva: è possibile eseguire macchine virtuali di Azure in cui un nodo è attivo e in uso, mentre l'altro è passivo e non in uso. Il nodo passivo verrà usato solo quando si verifica un errore nel nodo attivo.
In uno scenario attivo, i nodi vengono eseguiti simultaneamente. In questo scenario si hanno più costi fissi su base giornaliera, se i computer hanno le stesse specifiche di quelli in un cluster attivo-passivo.
I cluster attivo-passivo possono essere più convenienti rispetto ai cluster attivo-attivo. Poiché il nodo passivo non gestisce attivamente le richieste degli utenti, è possibile che i costi di licenza software e i costi delle risorse siano inferiori. Tuttavia, poiché in un cluster attivo-passivo viene eseguito solo il nodo attivo, non si ha la stessa flessibilità per soddisfare le oscillazioni della domanda.
Risorse come i set di disponibilità di Azure consentono di ottenere disponibilità elevata tramite più nodi. Se si verifica un problema in un computer, ad esempio errori hardware o interruzioni di rete, può essere disponibile un altro computer per garantire l'operatività.
È anche possibile usare set di scalabilità di macchine virtuali di Azure per creare un cluster attivo-attivo ed eseguire i computer che funzionano per aumentare o ridurre le prestazioni in risposta diretta alla richiesta. Anche Azure Load Balancer, tramite le regole delle porte a disponibilità elevata, consente di ottenere il clustering attivo-attivo o attivo-passivo per i computer.
Failover e failback delle applicazioni
L'organizzazione ha un'infrastruttura per le applicazioni in esecuzione in locale. È necessario assicurarsi che l'organizzazione soddisfi i requisiti di conformità e raggiunga gli obiettivi di continuità aziendale. Usando Azure Site Recovery e Gestione traffico insieme, è possibile eseguire il failover in Azure e quindi eseguire il failback per mantenere le applicazioni in esecuzione.
Se si verifica un errore, è possibile reindirizzare senza problemi il traffico del client a un'infrastruttura creata automaticamente in Azure. Usare Gestione traffico per creare un profilo e impostare il metodo di routing prioritario. È quindi necessario creare due endpoint, uno per l'ambiente locale e l'altro per l'ambiente che si vuole configurare in Azure.
Poiché in genere si esegue un ambiente locale e se ne desidera un altro in Azure per il failover, è possibile impostare due priorità:
- Priorità 1 per l'ambiente locale
- Priorità 2 per l'ambiente in Azure
Questa priorità definisce il modo in cui Gestione traffico sa come instradare il traffico tra i due ambienti. Gestione traffico continua a instradare il traffico all'ambiente locale fino a quando non rileva che l'endpoint non è più integro. In questo caso, Gestione traffico instrada il traffico al secondo ambiente, in Azure.
Azure Site Recovery avvia l'esecuzione delle macchine virtuali in Azure solo se viene attivato un failover. Se si verifica un'emergenza, è possibile usare Azure Site Recovery per avviare un failover dall'ambiente locale all'ambiente di Azure.
Gestione traffico consente di impostare la frequenza di probe per monitorare gli endpoint. È possibile configurare Gestione traffico per monitorare l'integrità degli endpoint ogni 30 secondi per i probe normali e fino a intervalli di 10 secondi per i probe più veloci.
Al termine di un failover, i client vengono indirizzati in modo trasparente al nuovo endpoint in Azure. Dopo aver risolto il problema che ha causato il failover, è possibile usare Azure Site Recovery per eseguire nuovamente il failback nell'ambiente locale. Gestione traffico continua a verificare l'integrità dell'endpoint locale. Quando Gestione traffico identifica che l'endpoint è di nuovo integro, reindirizza il traffico di nuovo all'ambiente locale.
