Ridondanza globale del routing per applicazioni Web cruciali

I sistemi cruciali si sforzano di ridurre al minimo i singoli punti di errore creando funzionalità di ridondanza e riparazione automatica nella soluzione il più possibile. Qualsiasi punto di ingresso unificato del sistema può essere considerato un punto di guasto. Se questo componente si verifica un'interruzione, 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 a causa dei contratti di servizio con tempo di attività elevato e di un set di funzionalità avanzato:

• Instradare il traffico a più aree in un modello attivo-attivo
• Failover trasparente tramite anycast TCP
• Gestire il contenuto statico dai nodi perimetrali usando reti di distribuzione di contenuti integrate (CDN)
• Bloccare l'accesso non autorizzato con web application firewall integrato

Frontdoor è progettato per offrire la massima resilienza e disponibilità non solo per i clienti esterni, ma anche per più proprietà in Microsoft. Per altre informazioni sulle funzionalità di Frontdoor, vedere Accelerare e proteggere l'applicazione Web con Frontdoor di Azure.

Le funzionalità di Frontdoor sono più che sufficienti per soddisfare la maggior parte dei requisiti aziendali, tuttavia, con qualsiasi sistema distribuito, si prevede un errore. Se i requisiti aziendali richiedono un valore SLO composito superiore o un tempo di inattività zero in caso di interruzione, è necessario basarsi su un percorso di ingresso del traffico alternativo. Tuttavia, la ricerca di un SLO più elevato comporta costi significativi, sovraccarico operativo 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 nel percorso critico. Anche quando l'impatto dell'indisponibilità è significativo, la complessità potrebbe superare il vantaggio.

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 non deve essere considerata come un requisito rigido. Classificare in ordine di priorità le funzionalità necessarie per la continuità aziendale, anche potenzialmente in esecuzione in una capacità limitata.

Un altro approccio consiste nell'usare la tecnologia di terze parti per il routing globale. Questo approccio richiederà una distribuzione attiva-attiva multicloud con stamp ospitati in due o più provider di servizi cloud. Anche se Azure può essere integrato in modo efficace con altre piattaforme cloud, questo approccio non è consigliato a causa della complessità operativa nelle diverse piattaforme cloud.

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.

Approccio

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

Con questo approccio verranno introdotti diversi componenti e verranno fornite indicazioni che apportano modifiche significative associate al recapito delle applicazioni Web:

1. Gestione traffico di Azure indirizza il traffico verso 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 modalità di configurazione del metodo di routing. L'uso del routing con priorità renderà il flusso del traffico 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 riduce i rischi associati alle interruzioni di Frontdoor di Azure, ma è soggetta a Gestione traffico di Azure interruzioni come punto di guasto globale.

   È anche possibile prendere in considerazione l'uso di un sistema di routing del traffico globale diverso, ad esempio un servizio 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 e i processi principali e indirizza tutto il traffico dell'applicazione.

   • Un altro router viene usato come backup per Frontdoor di Azure. Il traffico passa solo attraverso questo percorso secondario 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 per evitare di aggiungere complessità operative aggiuntive alla soluzione. Se si usano servizi di terze parti, è necessario usare più piani di controllo per gestire la soluzione.

3. I server applicazioni di origine devono essere pronti per accettare il traffico da entrambi i servizi. Valutare come proteggere il traffico verso l'origine e quali responsabilità vengono fornite da Frontdoor e da altri servizi upstream. Assicurarsi che l'applicazione possa gestire il traffico da qualsiasi percorso in cui il traffico passa.

Svantaggi

Anche se questa strategia di mitigazione può rendere disponibile l'applicazione durante le interruzioni della piattaforma, esistono alcuni compromessi significativi. È consigliabile valutare i potenziali vantaggi rispetto ai costi noti e prendere una decisione informata sulla pena di tali costi.

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

• Complessità operativa: ogni volta che si aggiungono componenti aggiuntivi 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 del traffico alternativo offre anche una funzionalità equivalente e, in caso contrario, è necessario decidere come gestire la differenza di comportamento tra i due percorsi di traffico. Nelle applicazioni reali, queste complessità possono avere un costo elevato e possono presentare un rischio importante 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 è consigliabile 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 richiedono un notevole investimento di progettazione, che in definitiva comporta un costo di opportunità per lo sviluppo di funzionalità e altri miglioramenti della piattaforma.

Disponibilità di Gestione traffico di Azure

Gestione traffico di Azure è un servizio affidabile, ma il contratto di servizio non garantisce la 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 funzionamento della soluzione in queste circostanze.

Gestione traffico restituisce risposte DNS memorizzabili nella cache. Se la durata (TTL) nei record DNS consente la memorizzazione nella cache, 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. È consigliabile 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 usate e basate su . Quando si sceglie il servizio alternativo, decidere le funzionalità minime necessarie e omettere altre funzionalità quando la soluzione è in modalità danneggiata.

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 possono mantenere il proprio 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?
• Si limita il traffico in base all'indirizzo IP o all'area geografica?
• Chi rilascia e gestisce i certificati TLS?
• Come si limita l'accesso ai server applicazioni di origine per assicurarsi che provenga da Frontdoor di Azure? Si usano collegamento privato oppure si fa affidamento su indirizzi IP pubblici con tag di servizio e intestazioni di identificatore?
• I server applicazioni accettano il 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?

Web application firewall (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 nello stesso modo del WAF di Frontdoor di Azure?
• È necessario ottimizzare e testare in modo indipendente, per ridurre la probabilità di rilevamenti di falsi positivi?

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

È consigliabile proteggere tutti i percorsi dei server applicazioni.

Nomi di dominio e DNS

L'applicazione mission-critical deve usare un nome di dominio personalizzato. Si controlla il flusso del traffico verso l'applicazione e si riducono le dipendenze da un singolo provider.

È anche consigliabile usare un servizio DNS di alta qualità e resiliente per il nome di dominio, ad esempio DNS di Azure. Se i server DNS del nome di dominio non sono disponibili, gli utenti non possono raggiungere il 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 multi-layer, detto anche concatenamento CNAME. Ad esempio, quando si risolve il proprio dominio personalizzato, potrebbero essere visualizzati cinque o più record CNAME prima che venga restituito un indirizzo IP.

L'aggiunta di collegamenti aggiuntivi a una catena CNAME può influire sulle prestazioni di risoluzione dei nomi DNS. Tuttavia, le risposte DNS vengono in genere memorizzate nella cache, riducendo così 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. Si ridurrà il numero di potenziali problemi con questa architettura complessa.

Ecco alcuni vantaggi:

• Per rilasciare 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 questo presupposto spesso non è corretto. L'emissione e il rinnovo di certificati TLS gestiti in Frontdoor di Azure potrebbero non funzionare senza problemi e aumentare il rischio di interruzioni a causa di problemi di certificato 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 visualizzare certificati TLS diversi emessi da autorità diverse o con date di scadenza o identificazioni personali diverse.

Tuttavia, ci saranno altre operazioni correlate al rinnovo e all'aggiornamento dei certificati prima della scadenza.

Sicurezza dell'origine

Quando si configura l'origine in modo che accetti solo il traffico tramite Frontdoor di Azure, si ottiene protezione dagli attacchi DDoS di livello 3 e di livello 4. Poiché Frontdoor di Azure risponde solo al traffico HTTP valido, 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 è stata accidentalmente aumentata l'esposizione dell'origine alle minacce.

Se si usa collegamento privato per connettersi da Frontdoor di Azure al server di origine, in che modo il traffico passa attraverso il percorso alternativo? È possibile usare indirizzi IP privati per accedere alle origini o usare 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 stato propagato attraverso Frontdoor di Azure, valutare come le origini possono essere riconfigurate per verificare che il traffico sia stato propagato attraverso uno dei percorsi validi. È necessario verificare che l'origine non sia stata aperta accidentalmente al traffico attraverso altri percorsi, inclusi i profili 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 implementare protezione DDoS di Azure per ridurre il rischio di attacchi Denial of Service alle origini. Valutare anche se è necessario implementare Firewall di Azure o un altro firewall in grado di proteggersi da diverse minacce di rete. Potrebbero essere necessarie anche altre strategie di rilevamento delle intrusioni. Questi controlli possono essere elementi importanti in un'architettura multi-percorso più complessa.

Modellazione per l'integrità

La metodologia di progettazione cruciale richiede un modello di integrità del sistema che offre un'osservabilità complessiva della soluzione e dei relativi componenti. Quando si usano 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.

Includere queste domande nella progettazione del modello di integrità:

• In che modo i diversi componenti della soluzione monitorano l'integrità dei componenti downstream?
• Quando i monitoraggi di integrità devono considerare i componenti downstream non integri?
• Quanto tempo è necessario per rilevare un'interruzione?
• Dopo che è stata rilevata un'interruzione, quanto tempo è necessario che il traffico venga instradato attraverso un percorso alternativo?

Esistono 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, più breve è l'intervallo tra i controlli, minore è il tempo necessario per Gestione traffico indirizzare il traffico attraverso un percorso alternativo per raggiungere il server di origine.

Se Frontdoor non è disponibile, più fattori influenzano la quantità di tempo in cui l'interruzione influisce sul traffico, tra cui:

• Durata (TTL) nei record DNS.
• Frequenza con cui Gestione traffico esegue i controlli di integrità.
• Numero di probe non riusciti Gestione traffico configurati per visualizzare prima di reindirizzare il traffico.
• Per quanto tempo i client e i server DNS upstream memorizzano nella cache le risposte DNS Gestione traffico.

È anche necessario determinare quali di questi fattori si trovano all'interno del controllo e se i servizi upstream oltre il controllo potrebbero influire sull'esperienza utente. Ad esempio, anche se si usa una TTL bassa nei record DNS, le cache DNS upstream potrebbero comunque servire risposte non aggiornate per più tempo di quanto dovrebbero. Questo comportamento potrebbe esacerbare gli effetti di un'interruzione o rendere l'applicazione non disponibile, anche quando Gestione traffico è già passato all'invio di richieste al percorso di traffico alternativo.

Fare riferimento a: Area di progettazione cruciale: Modellazione dell'integrità

Distribuzione senza tempi di inattività

Quando si pianifica come gestire una soluzione con un percorso di ingresso ridondante, è consigliabile pianificare anche come distribuire o configurare i servizi quando sono degradati. 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.

È anche consigliabile 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 offre un piano di controllo unificato e coerente. Tuttavia, se si usa un servizio di terze parti per instradare il traffico, potrebbe essere necessario usare un piano di controllo separato per configurare il servizio, che introduce ulteriore complessità operativa.

Fare riferimento a: Area di progettazione cruciale: Distribuzione senza tempi di inattività

Convalida continua

Per una soluzione cruciale, le procedure di test devono verificare che la soluzione soddisfi i requisiti indipendentemente dal percorso attraverso il quale il traffico dell'applicazione passa. Prendere in considerazione ogni parte della soluzione e come testarla per ogni tipo di interruzione.

Assicurarsi che i 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 si prevede di ricevere?
• Entrambi i percorsi sono adeguatamente protetti, per evitare di aprire o esporre vulnerabilità quando si è in uno stato danneggiato?

Fare riferimento a: Area di progettazione cruciale: Convalida continua

Scenari comuni

Ecco alcuni scenari comuni in cui è possibile usare questa progettazione:

• La distribuzione di contenuti globali si applica comunemente alle applicazioni di distribuzione di contenuti statici, supporti e e-commerce su larga scala. In questo scenario, la memorizzazione nella cache è una parte fondamentale dell'architettura della soluzione e gli errori nella cache possono causare prestazioni o affidabilità significativamente ridotte.

• In genere, l'ingresso HTTP globale si applica alle API e alle applicazioni dinamiche cruciali. In questo scenario, il requisito principale consiste nel instradare il traffico al server di origine in modo affidabile ed efficiente. Spesso, un WAF è un importante controllo di sicurezza usato in queste soluzioni.

Passaggi successivi

Esaminare gli scenari globali di ingresso HTTP e distribuzione di contenuti globali per comprendere se si applicano alla soluzione.