Modifica

Applicazione Web multilivello creata per la disponibilità elevata e il ripristino di emergenza

Azure
Azure Arc
SQL Server
Windows

Questo scenario di esempio è applicabile a qualsiasi settore che deve eseguire la distribuzione di applicazioni resilienti multilivello create per la disponibilità elevata e il ripristino di emergenza. In questo scenario, l'applicazione è costituita da tre livelli.

  • Livello Web: il livello più alto che include l'interfaccia utente. Questo livello analizza le interazioni dell'utente e passa le azioni al livello successivo per l'elaborazione.
  • Livello Business: elabora le interazioni degli utenti e prende decisioni logiche sui passaggi successivi. Questo livello connette il livello Web al livello dati.
  • Livello dati: archivia i dati dell'applicazione. In genere viene usato un database, l'archiviazione di oggetti o l'archiviazione file.

Scenari applicativi comuni includono eventuali applicazioni di importanza cruciale in esecuzione su Windows o Linux. Può trattarsi di un'applicazione commerciale, ad esempio SAP e SharePoint, o di un'applicazione line-of-business personalizzata.

Potenziali casi d'uso

Gli altri casi d'uso pertinenti includono:

  • Distribuzione di applicazioni altamente resilienti, come SAP e SharePoint
  • Progettazione di un piano di continuità aziendale e ripristino di emergenza per applicazioni line-of-business
  • Configurare il ripristino di emergenza ed eseguire esercitazioni correlate per motivi di conformità

Architettura

Diagram showing the architecture overview of a highly resilient multitier web application.

Scaricare un file di Visio di questa architettura.

Workflow

  • Distribuire le macchine virtuali in ogni livello tra due zone di disponibilità in aree che supportano le zone. In altre aree, distribuire le macchine virtuali in ogni livello all'interno di un set di disponibilità.
  • Il livello di database può essere configurato per l'uso dei gruppi di disponibilità AlwaysOn. Con questa configurazione di SQL Server, una replica primaria di lettura/scrittura all'interno di un gruppo di disponibilità è configurata con fino a otto repliche secondarie di sola lettura. Se si verifica un problema con la replica primaria, il gruppo di disponibilità esegue il failover dell'attività di lettura/scrittura primaria in una delle repliche secondarie, consentendo all'applicazione di rimanere disponibile. Per altre informazioni, vedere Panoramica di Gruppi di disponibilità AlwaysOn (SQL Server).
  • Per scenari di ripristino di emergenza, è possibile configurare la replica nativa asincrona SQL Always On nell'area di destinazione usata per il ripristino di emergenza. È anche possibile configurare la replica di Azure Site Recovery nell'area di destinazione se la frequenza di modifica dei dati rientra nei limiti supportati di Azure Site Recovery.
  • Gli utenti accedono al livello Web ASP.NET front-end dall'endpoint di Gestione traffico.
  • Gestione traffico reindirizza il traffico all'endpoint IP pubblico primario nell'area di origine primaria.
  • L'indirizzo IP pubblico reindirizza la chiamata a una delle istanze di VM a livello web con un servizio di bilanciamento del carico pubblico. Tutte le istanze VM a livello Web si trovano in un'unica subnet.
  • Dalla VM a livello Web ogni chiamata viene instradata a una delle istanze VM nel livello business attraverso un servizio di bilanciamento del carico interno per l'elaborazione. Tutte le VM a livello business si trovano in una subnet separata.
  • L'operazione viene elaborata nel livello business e l'applicazione ASP.NET si connette al cluster Microsoft SQL Server in un livello back-end tramite un servizio di bilanciamento del carico interno di Azure. Le istanze di SQL Server di back-end si trovano in una subnet separata.
  • L'endpoint secondario di gestione traffico è configurato come indirizzo IP pubblico nell'area di destinazione usata per il ripristino di emergenza.
  • In caso di interruzione di un'area primaria, richiamare il failover di Azure Site Recovery per attivare l'applicazione nell'area di destinazione.
  • L'endpoint di gestione traffico reindirizza automaticamente il traffico dei client all'indirizzo IP pubblico nell'area di destinazione.

Componenti

  • I set di disponibilità assicurano che le in Azure le macchine virtuali vengano distribuite tra più nodi hardware isolati in un cluster. Se si verifica un errore hardware o software all'interno di Azure, solo un subset delle macchine virtuali viene interessato e l'intera soluzione rimane disponibile e operativa.
  • Le zone di disponibilità proteggono le applicazioni e i dati dai guasti del data center. Le zone di disponibilità sono località fisiche separate all'interno di un'area di Azure. Ogni zona è costituita da uno o più data center dotati di impianti indipendenti per l'alimentazione, il raffreddamento e la connettività di rete.
  • Azure Site Recovery (ASR) consente di replicare le macchine virtuali in un'altra area di Azure per esigenze di continuità aziendale e ripristino di emergenza. È possibile condurre esercitazioni periodiche sul ripristino di emergenza per assicurarsi di soddisfare le esigenze di conformità. La VM verrà replicata con le impostazioni specificate nell'area selezionata in modo da consentire il ripristino delle applicazioni in caso di interruzioni nell'area di origine.
  • Gestione traffico di Azure è un servizio di bilanciamento del carico basato su DNS che distribuisce il traffico in modo ottimale ai servizi nelle aree globali di Azure, offrendo al tempo stesso disponibilità e velocità di risposta elevate.
  • Azure Load Balancer distribuisce il traffico in ingresso in base a regole e probe di integrità definiti. Un servizio di bilanciamento del carico offre bassa latenza e velocità effettiva elevata, aumentando le prestazioni fino a milioni di flussi per tutte le applicazioni TCP e UDP. In questo scenario viene usato un servizio di bilanciamento del carico pubblico per distribuire il traffico client nel livello Web. Questo scenario usa un servizio di bilanciamento del carico interno per distribuire il traffico dal livello business al cluster SQL Server di back-end.

Alternative

  • Windows può essere sostituito da altri sistemi operativi, perché l'infrastruttura non dipende dal sistema operativo.
  • SQL Server per Linux può sostituire l'archivio dati di back-end.
  • Il database può essere sostituito da qualsiasi applicazione di database standard disponibile.

Dettagli dello scenario

Questo scenario dimostra un'applicazione multilivello che usa ASP.NET e Microsoft SQL Server. Nelle aree di Azure che supportano le zone di disponibilità, è possibile distribuire le macchine virtuali (VM) in un'area di origine tra le zone di disponibilità e replicare le macchine virtuali nell'area di destinazione usata per il ripristino di emergenza. Nelle aree di Azure che non supportano le zone di disponibilità, è possibile distribuire le macchine virtuali nell'ambito di una zona di disponibilità e replicare le macchine virtuali nell'area di destinazione.

Per instradare il traffico tra le aree, è necessario un servizio di bilanciamento del carico globale. Le due principali offerte di Azure disponibili sono:

  • Frontdoor di Azure
  • Gestione traffico di Azure

Nella scelta di un servizio di bilanciamento del carico, valutare i requisiti e il set di funzionalità delle due offerte. Quanto velocemente si vuole eseguire il failover? Si è in grado di sostenere il sovraccarico della gestione TLS? Sono presenti vincoli dell'organizzazione relativi ai costi?

Frontdoor offre funzionalità di livello 7, tra cui offload SSL, routing basato sul percorso, failover rapido, memorizzazione nella cache e altre funzionalità che consentono di migliorare le prestazioni e la disponibilità elevata delle applicazioni. È possibile che si riscontrino tempi di trasferimento dei pacchetti più rapidi perché l'esecuzione dell'onboarding dell'infrastruttura nella rete di Azure è più veloce.

Frontdoor aggiunge un nuovo hop, pertanto sono state aggiunte operazioni di sicurezza. Se l'architettura è conforme ai requisiti normativi, potrebbero esserci restrizioni relative al punto di terminazione TLS aggiuntivo del traffico. I pacchetti di crittografia TLS selezionati da Frontdoor devono soddisfare lo standard di sicurezza dell'organizzazione. Inoltre, Frontdoor prevede che i servizi back-end usino i certificati usati da Microsoft.

Un ulteriore elemento da prendere in considerazione è il costo. L'architettura deve trarre vantaggio dal set di funzionalità completo (non solo dal failover) per giustificare il costo aggiuntivo.

Gestione traffico è un servizio di bilanciamento del carico basato su DNS. Questo servizio consente di effettuare il failover e il bilanciamento solo a livello di DNS. Per questo motivo, non può eseguire il failover con la velocità di Frontdoor, a causa di problemi comuni relativi alla memorizzazione nella cache DNS e ai sistemi che non rispettano la durata (TTL) DNS.

Se necessario, è possibile combinare entrambi i servizi di bilanciamento del carico. Ad esempio, nel caso in cui si voglia effettuare il failover basato su DNS ma anche aggiungere un'esperienza POP davanti all'infrastruttura gestita dal traffico.

Questa architettura usa Gestione traffico perché è un servizio leggero. A scopo illustrativo, la tempistica di failover è sufficiente.

Considerazioni

Scalabilità

È possibile aggiungere o rimuovere le macchine virtuali in ogni livello in base ai requisiti di ridimensionamento. Poiché questo scenario usa servizi di bilanciamento del carico, è possibile aggiungere altre macchine virtuali a un livello senza influire sul tempo di attività dell'applicazione.

Per altri argomenti relativi alla scalabilità, vedere l'elenco di controllo per l'efficienza delle prestazioni nel Centro architetture di Azure.

Sicurezza

Tutto il traffico di rete virtuale nel livello applicazione front-end è protetto da gruppi di sicurezza di rete. Le regole limitano il flusso del traffico in modo che solo le istanze di macchina virtuale a livello applicazione front-end possano accedere al livello di database di backend. Non è consentito il traffico Internet in uscita dal livello business o di database. Per ridurre la superficie di attacco, non sono aperte porte di gestione remota diretta. Per altre informazioni, vedere Gruppi di sicurezza di rete di Azure.

Per indicazioni generali sulla progettazione di scenari sicuri, vedere la documentazione sulla sicurezza di Azure.

Prezzi

Per la configurazione del ripristino di emergenza per macchine virtuali di Azure con Azure Site Recovery verranno regolarmente applicati gli addebiti seguenti.

  • Costo della licenza di Azure Site Recovery per ogni VM.
  • Costi per l'uscita dei dati in rete per replicare le modifiche ai dati dai dischi della macchina virtuale di origine in un'altra area di Azure. Azure Site Recovery usa funzionalità di compressione incorporata per ridurre i requisiti di trasferimento dei dati di circa il 50%.
  • Costi di archiviazione nel sito di ripristino. Ciò equivale in genere allo spazio di archiviazione dell'area di origine oltre a qualsiasi spazio di archiviazione aggiuntivo necessario per mantenere i punti di ripristino come snapshot per il ripristino.

È stato fornito un calcolatore dei costi di esempio per la configurazione del ripristino di emergenza per un'applicazione a tre livelli usando sei macchine virtuali. Nel calcolatore dei costi sono preconfigurati tutti i servizi. Per verificare la variazione dei prezzi per un determinato caso d'uso, modificare le variabili appropriate per stimare il costo.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

Passaggi successivi

Per altre architetture di riferimento per disponibilità elevata e ripristino di emergenza, vedere: