Ridondanza del routing globale per applicazioni Web mission-critical

I sistemi mission-critical si sforzano di ridurre al minimo i singoli punti di errore creando il più possibile funzionalità di ridondanza e riparazione automatica nella soluzione. Qualsiasi punto di ingresso unificato del sistema può essere considerato un punto di errore. Se si verifica un'interruzione di questo componente, l'intero sistema sarà offline per l'utente. Quando si sceglie un servizio di routing, è importante considerare l'affidabilità del servizio stesso.

Nell'architettura di base per un'applicazione cruciale, Frontdoor di Azure è stato scelto per i contratti di servizio con tempo di attività elevato e un set di funzionalità avanzato:

• Instradare il traffico verso più regioni in un modello attivo-attivo
• Failover trasparente con TCP anycast
• Distribuisci contenuti statici dai nodi perimetrali utilizzando reti per la distribuzione di contenuti (CDN) integrate
• Blocca l'accesso non autorizzato con il firewall integrato per applicazioni web

Per altre informazioni sulle funzionalità di Frontdoor di Azure, vedere Accelerare e proteggere l'applicazione Web con Frontdoor di Azure.

Frontdoor di Azure è progettato per offrire la massima resilienza e disponibilità non solo per i clienti esterni, ma anche per più proprietà in Microsoft. Le funzionalità di Frontdoor di Azure sono più che sufficienti per soddisfare la maggior parte dei requisiti aziendali, tuttavia, con qualsiasi sistema distribuito, prevedere errori. Nessun componente o sistema è infallibile. Microsoft offre un contratto di servizio leader del settore per Frontdoor di Azure. Anche se un altro provider offre un contratto di servizio di 100% tempo di attività, è importante notare che non è una garanzia di tempo di inattività zero e che i contratti di servizio in genere forniscono crediti di servizio in caso di interruzione del servizio.

Se i requisiti aziendali richiedono un contratto di servizio composito più elevato o zero tempi di inattività in caso di interruzione, sarà necessario fare affidamento su più percorsi di ingresso del traffico alternativi. Molte organizzazioni di grandi dimensioni e proprietà Web di alto profilo utilizzano questo approccio per garantire la massima disponibilità possibile e ottimizzare le prestazioni di consegna. Tuttavia, il perseguimento di uno SLO più elevato comporta costi significativi, spese operative e può ridurre l'affidabilità complessiva. Considerare attentamente i compromessi e i potenziali problemi che il percorso alternativo potrebbe introdurre in altri componenti che si trovano sul percorso critico. Anche quando l'impatto dell'indisponibilità è significativo, la complessità potrebbe superare i benefici.

Un approccio consiste nel definire un percorso secondario, con servizi alternativi, che diventa attivo solo quando Frontdoor di Azure non è disponibile. La parità di funzionalità con Frontdoor di Azure non deve essere considerata un requisito rigido. Dai priorità alle funzionalità di cui hai assolutamente bisogno ai fini della continuità aziendale, anche potenzialmente in esecuzione con una capacità limitata.

Questo articolo descrive alcune strategie per il routing globale usando Gestione traffico di Azure come router alternativo in situazioni in cui Frontdoor di Azure non è disponibile.

Avvicinarsi

Questo diagramma dell'architettura mostra un approccio generale con più percorsi di traffico ridondanti.

Con questo approccio, introdurremo diversi componenti e forniremo indicazioni che apporteranno modifiche significative associate alla distribuzione delle tue applicazioni web:

1. Gestione traffico di Azure indirizza il traffico a Frontdoor di Azure o al servizio alternativo selezionato.

   Gestione traffico di Azure è un servizio di bilanciamento del carico globale basato su DNS. Il record CNAME del dominio punta a Gestione traffico, che determina la destinazione in base alla configurazione del metodo di routing. L'uso del routing prioritario farà sì che il traffico passi attraverso Frontdoor di Azure per impostazione predefinita. Gestione traffico può passare automaticamente il traffico al percorso alternativo se Frontdoor di Azure non è disponibile.

   Importante

   Questa soluzione attenua i rischi associati alle interruzioni in Frontdoor di Azure o in altri provider, ma è suscettibile alle interruzioni di Gestione traffico di Azure come punto di errore globale. Per altre informazioni, vedere Disponibilità di Gestione traffico di Azure.

   È inoltre possibile prendere in considerazione l'utilizzo di un sistema di routing del traffico globale diverso, ad esempio un sistema di bilanciamento del carico globale. Tuttavia, Gestione traffico funziona bene per molte situazioni.

2. Sono disponibili due percorsi di ingresso:

   • Frontdoor di Azure fornisce il percorso primario ed elabora e instrada tutto il traffico dell'applicazione.

   • Un altro router viene usato come backup per Frontdoor di Azure. Il traffico passa attraverso questo percorso secondario solo se Frontdoor non è disponibile.

   Il servizio specifico selezionato per il router secondario dipende da molti fattori. È possibile scegliere di usare servizi nativi di Azure o servizi di terze parti. In questi articoli vengono fornite opzioni native di Azure, ove possibile, per evitare di aggiungere ulteriore complessità operativa alla soluzione. Se si usano servizi di terze parti, è necessario usare più piani di controllo per gestire la soluzione.

3. I server delle applicazioni di origine devono essere pronti ad accettare il traffico da entrambi i servizi. Considerare il modo in cui si protegge il traffico verso l'origine e le responsabilità fornite da Frontdoor di Azure e altri servizi upstream. Assicurati che l'applicazione sia in grado di gestire il traffico da qualsiasi percorso attraverso.

Svantaggi

Sebbene questa strategia di mitigazione possa rendere l'applicazione disponibile durante le interruzioni della piattaforma, esistono alcuni compromessi significativi. È necessario valutare i potenziali benefici rispetto ai costi noti e prendere una decisione informata sul fatto che i benefici valgano tali costi.

• Costo finanziario: quando si distribuiscono più percorsi ridondanti nell'applicazione, è necessario considerare il costo della distribuzione e dell'esecuzione delle risorse. Forniamo due scenari di esempio per diversi casi d'uso, ognuno dei quali ha un profilo di costo diverso.

• Complessità operativa: ogni volta che si aggiungono ulteriori componenti alla soluzione, si aumenta il sovraccarico di gestione. Qualsiasi modifica apportata a un componente potrebbe influire su altri componenti.

  Si supponga di decidere di usare le nuove funzionalità di Frontdoor di Azure. È necessario verificare se il percorso di traffico alternativo fornisce anche una funzionalità equivalente e, in caso contrario, è necessario decidere come gestire la differenza di comportamento tra i due percorsi di traffico. Nelle applicazioni del mondo reale, queste complessità possono avere un costo elevato e rappresentare un grave rischio per la stabilità del sistema.

• Prestazioni: questa progettazione richiede ricerche CNAME aggiuntive durante la risoluzione dei nomi. Nella maggior parte delle applicazioni, questo non è un problema significativo, ma è necessario valutare se le prestazioni dell'applicazione sono influenzate dall'introduzione di livelli aggiuntivi nel percorso di ingresso.

• Costo opportunità: La progettazione e l'implementazione di percorsi di ingresso ridondanti richiede un investimento ingegneristico significativo, che in ultima analisi comporta un costo opportunità per lo sviluppo di funzionalità e altri miglioramenti della piattaforma.

Disponibilità di Gestione traffico di Azure

Gestione traffico di Azure è un servizio affidabile con un contratto di servizio leader del settore, ma nessun servizio di gestione del traffico può garantire una disponibilità del 100%. Se Gestione traffico non è disponibile, gli utenti potrebbero non essere in grado di accedere all'applicazione, anche se Frontdoor di Azure e il servizio alternativo sono entrambi disponibili. È importante pianificare il modo in cui la soluzione continuerà a funzionare in queste circostanze.

Gestione traffico restituisce risposte DNS memorizzabili nella cache. Se la durata (TTL) nei record DNS consente la memorizzazione nella cache, le brevi interruzioni di Gestione traffico potrebbero non essere un problema. Ciò è dovuto al fatto che i resolver DNS downstream potrebbero aver memorizzato nella cache una risposta precedente. È necessario pianificare interruzioni prolungate. È possibile scegliere di riconfigurare manualmente i server DNS per indirizzare gli utenti a Frontdoor di Azure se Gestione traffico non è disponibile.

Coerenza del routing del traffico

È importante comprendere le funzionalità e le funzionalità di Frontdoor di Azure che si usano e su cui si fa affidamento se si intende usare anche un altro servizio. Quando si sceglie il servizio alternativo, decidere le funzionalità minime necessarie e omettere le altre funzionalità quando la soluzione è in modalità degradata.

Quando si pianifica un percorso di traffico alternativo, ecco alcune domande chiave da considerare:

• Si usano le funzionalità di memorizzazione nella cache di Frontdoor di Azure? Se la memorizzazione nella cache non è disponibile, i server di origine sono in grado di tenere il passo con il traffico?
• Si usa il motore regole di Frontdoor di Azure per eseguire la logica di routing personalizzata o per riscrivere le richieste?
• Si usa il Web application firewall (WAF) di Frontdoor di Azure per proteggere le applicazioni?
• Limitate il traffico in base all'indirizzo IP o all'area geografica?
• Chi emette e gestisce i tuoi certificati TLS?
• Come si limita l'accesso ai server applicazioni di origine per assicurarsi che passi attraverso Frontdoor di Azure? Si usa il collegamento privato o ci si affida a indirizzi IP pubblici con tag di servizio e intestazioni di identificazione?
• I server applicazioni accettano traffico da qualsiasi posizione diversa da Frontdoor di Azure? Se lo fanno, quali protocolli accettano?
• I client usano il supporto HTTP/2 di Frontdoor di Azure?

Firewall per applicazioni Web (WAF)

Se si usa il WAF di Frontdoor di Azure per proteggere l'applicazione, considerare cosa accade se il traffico non passa attraverso Frontdoor di Azure.

Se il percorso alternativo fornisce anche un WAF, prendere in considerazione le domande seguenti:

• Può essere configurato allo stesso modo del WAF di Frontdoor di Azure?
• Deve essere regolato e testato in modo indipendente, per ridurre la probabilità di rilevamenti di falsi positivi?

Considera il compromesso nell'accettare il traffico da Internet senza alcun controllo. Se un utente malintenzionato individua un percorso di traffico secondario non protetto per l'applicazione, potrebbe inviare traffico dannoso attraverso il percorso secondario anche quando il percorso primario include un WAF.

È consigliabile proteggere tutti i percorsi dei server delle applicazioni.

Considerazioni aggiuntive per l'alta disponibilità

Quando si progetta un'architettura Web mission-critical, ci sono molti fattori che possono influire sulla disponibilità e sulle prestazioni dell'applicazione. Molti di questi fattori vanno oltre la configurazione e le funzionalità di Frontdoor di Azure e sono invece correlati all'ecosistema generale e alla progettazione della soluzione.

Nomi a dominio e DNS

L'applicazione mission-critical deve utilizzare un nome di dominio personalizzato. Potrai controllare il flusso del traffico verso la tua applicazione e ridurre le dipendenze da un singolo provider.

È anche consigliabile usare un servizio DNS resiliente e di alta qualità per il nome di dominio, ad esempio DNS di Azure. Se i server DNS del tuo nome di dominio non sono disponibili, gli utenti non possono contattare il tuo servizio.

È consigliabile usare più resolver DNS per aumentare ulteriormente la resilienza complessiva.

Concatenamento CNAME

Le soluzioni che combinano Gestione traffico, Frontdoor di Azure e altri servizi usano un processo di risoluzione CNAME DNS a più livelli, noto anche come concatenamento CNAME. Ad esempio, quando si risolve il proprio dominio personalizzato, è possibile che vengano visualizzati cinque o più record CNAME prima che venga restituito un indirizzo IP.

L'aggiunta di ulteriori collegamenti a una catena CNAME può influire sulle prestazioni della risoluzione dei nomi DNS. Tuttavia, le risposte DNS vengono in genere memorizzate nella cache, il che riduce l'impatto sulle prestazioni.

Certificati TLS

Per un'applicazione cruciale, è consigliabile effettuare il provisioning e usare i propri certificati TLS anziché i certificati gestiti forniti da Frontdoor di Azure. Ridurrai il numero di potenziali problemi con questa complessa architettura.

Ecco alcuni vantaggi:

• Per emettere e rinnovare i certificati TLS gestiti, Frontdoor di Azure verifica la proprietà del dominio. Il processo di verifica del dominio presuppone che i record CNAME del dominio puntino direttamente a Frontdoor di Azure. Ma questa ipotesi spesso non è corretta. L'emissione e il rinnovo dei certificati TLS gestiti in Frontdoor di Azure potrebbero non funzionare correttamente e aumentare il rischio di interruzioni dovute a problemi relativi ai certificati TLS.

• Anche se gli altri servizi forniscono certificati TLS gestiti, potrebbero non essere in grado di verificare la proprietà del dominio.

• Se ogni servizio ottiene i propri certificati TLS gestiti in modo indipendente, potrebbero verificarsi problemi. Ad esempio, gli utenti potrebbero non aspettarsi di vedere certificati TLS diversi emessi da autorità diverse o con date di scadenza o identificazioni personali diverse.

Tuttavia, ci saranno ulteriori operazioni relative al rinnovo e all'aggiornamento dei certificati prima della loro scadenza.

Sicurezza dell'origine

Quando si configura l'origine in modo che accetti solo il traffico tramite Frontdoor di Azure, si ottiene la protezione contro gli attacchi DDoS di livello 3 e 4. Frontdoor di Azure risponde solo al traffico HTTP valido, che consente anche di ridurre l'esposizione a molte minacce basate su protocollo. Se si modifica l'architettura per consentire percorsi di ingresso alternativi, è necessario valutare se l'esposizione dell'origine alle minacce è stata aumentata accidentalmente.

Se si usa il collegamento privato per connettersi da Frontdoor di Azure al server di origine, in che modo il traffico passa attraverso il percorso alternativo? È possibile utilizzare indirizzi IP privati per accedere alle origini o è necessario utilizzare indirizzi IP pubblici?

Se l'origine usa il tag del servizio Frontdoor di Azure e l'intestazione X-Azure-FDID per verificare che il traffico sia passato attraverso Frontdoor di Azure, valutare come riconfigurare le origini per verificare che il traffico sia passato attraverso uno dei percorsi validi. È necessario verificare di non aver aperto accidentalmente l'origine al traffico attraverso altri percorsi, inclusi i profili di Frontdoor di Azure di altri clienti.

Quando si pianifica la sicurezza dell'origine, verificare se il percorso del traffico alternativo si basa sul provisioning di indirizzi IP pubblici dedicati. Potrebbe essere necessario un processo attivato manualmente per portare online il percorso di backup.

Se sono presenti indirizzi IP pubblici dedicati, valutare se è necessario implementare Protezione DDoS di Azure per ridurre il rischio di attacchi Denial of Service contro le origini. Inoltre, considerare se è necessario implementare Firewall di Azure o un altro firewall in grado di proteggerti da una varietà di minacce di rete. Potresti anche aver bisogno di più strategie di rilevamento delle intrusioni. Questi controlli possono essere elementi importanti in un'architettura multi-percorso più complessa.

Modellazione della salute

La metodologia di progettazione mission-critical richiede un modello di integrità del sistema che offra l'osservabilità complessiva della soluzione e dei relativi componenti. Quando si utilizzano più percorsi di ingresso del traffico, è necessario monitorare l'integrità di ogni percorso. Se il traffico viene reindirizzato al percorso di ingresso secondario, il modello di integrità deve riflettere il fatto che il sistema è ancora operativo ma che è in esecuzione in uno stato danneggiato.

Includi queste domande nella progettazione del tuo modello di salute:

• In che modo i diversi componenti della soluzione monitorano l'integrità dei componenti a valle?
• Quando i monitoraggi dello stato devono considerare i componenti downstream come non integri?
• Quanto tempo ci vuole per rilevare un'interruzione?
• Dopo il rilevamento di un'interruzione, quanto tempo è necessario per instradare il traffico attraverso un percorso alternativo?

Sono disponibili più soluzioni di bilanciamento del carico globale che consentono di monitorare l'integrità di Frontdoor di Azure e attivare un failover automatico in una piattaforma di backup in caso di interruzione. Gestione traffico di Azure è adatto nella maggior parte dei casi. Con Gestione traffico è possibile configurare il monitoraggio degli endpoint per monitorare i servizi downstream specificando l'URL da controllare, la frequenza con cui controllare tale URL e quando considerare il servizio downstream non integro in base alle risposte del probe. In generale, minore è l'intervallo tra i controlli, minore è il tempo necessario a Gestione traffico per indirizzare il traffico attraverso un percorso alternativo per raggiungere il server di origine.

Se Frontdoor di Azure non è disponibile, diversi fattori influiscono sulla quantità di tempo in cui l'interruzione influisce sul traffico, tra cui:

• Il tempo di vita (TTL) sui record DNS.
• Frequenza con cui Gestione traffico esegue i controlli di integrità.
• Numero di probe non riusciti configurati per la visualizzazione da parte di Gestione traffico prima di reindirizzare il traffico.
• Per quanto tempo i client e i server DNS upstream memorizzano nella cache le risposte DNS di Gestione traffico.

È inoltre necessario determinare quali di questi fattori sono sotto il proprio controllo e se i servizi upstream al di fuori del controllo possono influire sull'esperienza utente. Ad esempio, anche se si utilizza un TTL basso per i record DNS, le cache DNS upstream potrebbero comunque fornire risposte obsolete più a lungo del dovuto. Questo comportamento potrebbe esacerbare gli effetti di un'interruzione o far sembrare che l'applicazione non sia disponibile, anche quando Gestione traffico è già passato all'invio di richieste al percorso di traffico alternativo.

Fare riferimento a: Area di progettazione mission-critical: Modellazione sanitaria

Distribuzione senza tempi di inattività

Quando si pianifica come gestire una soluzione con percorso di ingresso ridondante, è necessario pianificare anche la modalità di distribuzione o configurazione dei servizi quando sono danneggiati. Per la maggior parte dei servizi di Azure, i contratti di servizio si applicano al tempo di attività del servizio stesso e non alle operazioni di gestione o alle distribuzioni. Valutare se i processi di distribuzione e configurazione devono essere resi resilienti alle interruzioni del servizio.

È inoltre necessario considerare il numero di piani di controllo indipendenti con cui è necessario interagire per gestire la soluzione. Quando si usano i servizi di Azure, Azure Resource Manager fornisce un piano di controllo unificato e coerente. Tuttavia, se si utilizza un servizio di terze parti per instradare il traffico, potrebbe essere necessario utilizzare un piano di controllo separato per configurare il servizio, il che introduce ulteriore complessità operativa.

Fare riferimento a: Area di progettazione mission-critical: Distribuzione senza tempi di inattività

Convalida continua

Per una soluzione mission-critical, le procedure di test devono verificare che la soluzione soddisfi i requisiti indipendentemente dal percorso attraverso il quale scorre il traffico dell'applicazione. Considerare ogni parte della soluzione e il modo in cui viene testata per ogni tipo di interruzione.

Assicurati che i tuoi processi di test includano questi elementi:

• È possibile verificare che il traffico venga reindirizzato correttamente attraverso il percorso alternativo quando il percorso primario non è disponibile?
• Entrambi i percorsi possono supportare il livello di traffico di produzione che prevedi di ricevere?
• Entrambi i percorsi sono adeguatamente protetti, per evitare di aprire o esporre vulnerabilità quando ci si trova in uno stato degradato?

Fare riferimento a: Area di progettazione mission-critical: Convalida continua

Scenari comuni

Di seguito sono riportati gli scenari comuni in cui è possibile utilizzare questa progettazione:

• La distribuzione di contenuti globali si applica in genere alla distribuzione di contenuti statici, ai contenuti multimediali e alle applicazioni di e-commerce su larga scala. In questo scenario, la memorizzazione nella cache è una parte fondamentale dell'architettura della soluzione e gli errori di memorizzazione nella cache possono comportare una riduzione significativa delle prestazioni o dell'affidabilità.

• L'ingresso HTTP globale si applica in genere alle applicazioni dinamiche e alle API mission-critical. In questo scenario, il requisito principale è quello di instradare il traffico al server di origine in modo affidabile ed efficiente. Spesso, un WAF è un importante controllo di sicurezza utilizzato in queste soluzioni.

Contributori

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

Autori principali:

• Dave Burkhardt | Principal Program Manager, Frontdoor di Azure
• John Downs | Principal Software Engineer, Azure Patterns & Practices
• Priyanka Wilkins | Principale sviluppatore di contenuti, Modelli e procedure di Azure

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

Esaminare gli scenari di ingresso HTTP globale e di distribuzione del contenuto globale per comprendere se si applicano alla soluzione.