Ridondanza del routing globale per applicazioni Web mission-critical

Importante

La progettazione di implementazioni di ridondanza che gestiscono le interruzioni della piattaforma globale per un'architettura mission-critical può essere complessa e costosa. A causa dei potenziali problemi che potrebbero sorgere con questo progetto, considerare attentamente i compromessi.

Nella maggior parte delle situazioni, non è necessaria l'architettura descritta in questo articolo.

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 questo componente subisce un'interruzione, l'intero sistema va offline per l'utente. Quando si sceglie un servizio di routing, è importante considerare l'affidabilità del servizio stesso.

Nell'architettura per un'applicazione cruciale, Frontdoor di Azure viene scelto a causa del contratto di servizio con tempo di attività elevato e di un set di funzionalità avanzato:

• Instradare il traffico a più regioni, in un modello attivo-attivo o attivo-passivo
• 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 provider offre un SLA di uptime al 100%, questo non garantisce un'assenza totale di downtime. Gli SLA forniscono in genere crediti di servizio in caso di interruzioni.

Se i requisiti aziendali richiedono un SLO composito più elevato o un tempo di inattività zero in caso di interruzione, è necessario basarsi su più percorsi di ingresso del traffico alternativo. 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, la ricerca di un SLO più elevato comporta costi significativi, sovraccarico operativo e può inavvertitamente 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 i benefici.

Un approccio consiste nel definire un percorso secondario, con servizi alternativi, che diventa il percorso primario 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.

Esistono più strategie per ottenere la disponibilità elevata nei carichi di lavoro Web. L'approccio dettagliato qui offre una semplice e manuale "soluzione break glass" che consente di eseguire rapidamente il failover durante un'interruzione e ripristinare facilmente il traffico verso Frontdoor di Azure dopo la conferma dell'integrità del servizio.

Questo articolo descrive alcune strategie per il routing globale usando Gestione traffico di Azure per indirizzare il traffico a un 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. Per un'architettura mission-critical, è consigliabile usare il metodo di routing ponderato , che può essere facilmente configurato per inviare parte o tutto il traffico a endpoint diversi. In genere, nelle normali operazioni, 100% del traffico vengono indirizzati attraverso Frontdoor di Azure.

   Consigliamo di disabilitare il monitoraggio degli endpoint di Gestione del traffico. È necessario disporre di procedure per rilevare quando il percorso del traffico primario non è disponibile e rispondere deviando il traffico verso il percorso secondario.

   È anche possibile prendere in considerazione l'uso di un sistema di routing del traffico globale diverso. Tuttavia, Gestione traffico funziona bene per molte situazioni.

2. Sono disponibili due percorsi di ingresso:

   • Azure Front Door fornisce il percorso primario. Nelle normali operazioni, elabora e instrada tutto o la maggior parte del traffico dell'applicazione.

   • Un altro router viene usato come backup per Frontdoor di Azure. Il traffico passa 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, 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 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.

Avvertimento

Se non si presta attenzione al modo in cui si progetta e si implementa una soluzione complessa a disponibilità elevata, è possibile peggiorare la disponibilità. L'aumento del numero di componenti nell'architettura aumenta il numero di punti di errore. Significa anche che hai un livello più elevato di complessità operativa. Quando si aggiungono componenti aggiuntivi, ogni modifica apportata deve essere esaminata attentamente per comprendere in che modo influisce sulla soluzione complessiva.

Disponibilità di Gestione traffico di Azure

Gestione traffico di Azure è un servizio affidabile con un contratto di servizio leader del settore, ma la gestione del traffico richiede misure aggiuntive per offrire 100% disponibilità. 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?

Avvertimento

È possibile scegliere di non usare un WAF per il percorso di ingresso alternativo. Questo approccio può essere considerato per supportare l'obiettivo di affidabilità dell'applicazione. Tuttavia, questa non è una buona pratica di sicurezza e non è consigliata.

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 usare nomi di dominio personalizzati per controllare il flusso del traffico verso l'applicazione e ridurre le dipendenze da un singolo provider. Quando si pianifica l'approccio DNS, tenere presente quanto segue:

• Servizio DNS: È 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 tuo nome di dominio non sono disponibili, gli utenti non possono contattare il tuo servizio.

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

• Domini Apex: Si usa un CNAME per indirizzare il nome di dominio verso il nome di dominio del Gestore del traffico. Gli standard DNS non consentono di creare un CNAME al vertice (o alla radice) di un dominio. È consigliabile ospitare il dominio DNS su Azure DNS e usare i record alias per puntare al profilo di Gestione Traffico.

• Concatenamento CNAME: Le soluzioni che combinano Gestione traffico, Frontdoor di Azure e altri servizi usano un processo di risoluzione CNAME DNS a più livelli, detto anche 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. Si riduce il numero di potenziali problemi con questa architettura complessa.

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.

Esistono tuttavia 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 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. Valutare anche se è necessario implementare Firewall di Azure o un altro firewall in grado di proteggere l'utente da varie 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?

Monitoraggio della salute

Esistono più soluzioni di bilanciamento del carico globale che consentono di passare a una piattaforma secondaria in caso di interruzione. Gestione traffico di Azure è adatto nella maggior parte dei casi.

Quando si usa Gestione traffico con Frontdoor di Azure, è necessario avere la propria soluzione di monitoraggio di terze parti o personalizzata per rilevare quando Frontdoor di Azure non è disponibile e avviare i processi di risposta. Poiché Frontdoor di Azure è un sistema distribuito a livello globale che usa la rete anycast, è importante eseguire controlli di connettività dalle stesse aree geografiche dei client.

Importante

Per i carichi di lavoro globali che richiedono la convalida dell'integrità da più aree geografiche, è consigliabile disabilitare il monitoraggio degli endpoint di Traffic Manager e usare invece procedure di failover manuali.

È anche necessario essere pronti per attivare manualmente le procedure di risposta se i sistemi di monitoraggio non lo rilevano.

Procedure di risposta

Se i sistemi di monitoraggio rilevano che Frontdoor di Azure non è disponibile, è necessario riconfigurare Gestione traffico per indirizzare tutto il traffico attraverso il percorso alternativo usando uno di questi approcci:

• Se si rileva manualmente l'interruzione: Disabilitare manualmente l'endpoint nel profilo di Gestione traffico. Per i passaggi dettagliati, vedere Aggiungere, disabilitare, abilitare, eliminare o spostare gli endpoint.

• Creare strumenti di monitoraggio personalizzati o usare strumenti di monitoraggio di terze parti: È possibile precreare piani di risposta automatizzati che riconfigurano a livello di codice Gestione traffico per disabilitare l'endpoint usando uno di questi approcci:

  CLI di Azure

  az network traffic-manager endpoint update \
      --resource-group MyRG \
      --profile-name MyProfile \
      --name MyEndpoint \
      --type externalEndpoints \
      --endpoint-status Disabled
  

  Per altre informazioni, vedere az network traffic-manager endpoint update.

  Azure PowerShell

  Disable-AzTrafficManagerEndpoint `
      -ResourceGroupName MyRG `
      -ProfileName MyProfile `
      -Name MyEndpoint `
      -Type ExternalEndpoints
  

  Per altre informazioni, vedere Uso di PowerShell per gestire Gestione traffico.

  API REST di Azure

  Usare l'API Endpoint - Aggiornamento per disabilitare l'endpoint.

Importante

Il reindirizzamento di tutto il traffico attraverso il percorso secondario è una soluzione a breve termine che consente la continuità aziendale durante un'interruzione in corso. Dopo aver risolto l'interruzione, ripristinare le normali operazioni tramite Frontdoor di Azure non appena possibile.

Più fattori influenzano la quantità di tempo in cui l'interruzione influisce sul traffico, tra cui:

• Il tempo di vita (TTL) sui record DNS.
• Quale sistema di monitoraggio (Gestione traffico o monitoraggio personalizzato) rileva prima l'interruzione.
• Frequenza con cui esegui i controlli di integrità.
• Numero di controlli di integrità non riusciti che devono essere restituiti prima che il traffico venga reindirizzato.
• 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.

Suggerimento

Le soluzioni mission-critical richiedono approcci di failover automatizzati, ove possibile. I processi di failover manuali sono considerati troppo lenti per consentire all'applicazione di rimanere reattivi.

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

Processi di riconfigurazione resilienti

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

Quando si pianifica la strategia di failover, non assumere una dipendenza da un singolo strumento, ad esempio il portale di Azure, nel caso in cui la connettività venga interrotta. Informazioni su come usare strumenti come l'interfaccia della riga di comando di Azure, Azure PowerShell o le API REST per eseguire qualsiasi procedura di riconfigurazione, ad esempio il reindirizzamento del traffico. Per visualizzare i comandi di esempio che è possibile includere negli script di failover, vedere Procedure di risposta.

È 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.

Avvertimento

L'uso di più piani di controllo introduce complessità e rischi per la soluzione. Ogni punto di differenza aumenta la probabilità che qualcuno perda accidentalmente un'impostazione di configurazione o applichi configurazioni diverse a componenti ridondanti. Assicurati che le tue procedure operative mitighino questo rischio.

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? Il percorso secondario è pronto per ricevere il traffico di produzione senza preavviso?
• 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.

Avvertimento

Se non si presta attenzione al modo in cui si progetta e si implementa una soluzione complessa multi-ingresso, è possibile peggiorare la disponibilità. L'aumento del numero di componenti nell'architettura aumenta il numero di punti di errore. Significa anche che hai un livello più elevato di complessità operativa. Quando si aggiungono componenti aggiuntivi, ogni modifica apportata deve essere esaminata attentamente per comprendere in che modo influisce sulla soluzione complessiva.

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
• Akhil Karmalkar | Principal Program Manager, Frontdoor di Azure
• Priyanka Wilkins | Principale sviluppatore di contenuti, Modelli e procedure di Azure

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

Passaggi successivi

Vedere gli articoli successivi di questa serie per indicazioni specifiche su questi scenari:

Ingresso HTTP globale critico per la missione

Distribuzione di contenuti globali cruciali

" output is necessary.)

• Procedure consigliate per l'architettura per Frontdoor di Azure
• Procedure consigliate per l'architettura per Gestione traffico di Azure