Ingresso HTTP globale cruciale

Le applicazioni cruciali devono mantenere un elevato livello di tempo di attività, anche quando i componenti di rete non sono disponibili o degradati. Quando si progettano traffico Web in ingresso, routing e sicurezza, è possibile valutare la possibilità di combinare più servizi di Azure per ottenere un livello di disponibilità superiore ed evitare di avere un singolo punto di errore.

Se si decide di adottare questo approccio, sarà necessario implementare un percorso di rete separato per i server applicazioni e ogni percorso deve essere configurato e testato separatamente. È necessario considerare attentamente le implicazioni complete di questo approccio.

Questo articolo descrive un approccio per supportare l'ingresso globale del traffico HTTP tramite Frontdoor di Azure e gateway applicazione di Azure. Questo approccio può soddisfare le proprie esigenze se la soluzione richiede:

• Frontdoor di Azure per il routing globale del traffico. Ciò potrebbe significare che sono presenti più istanze dell'applicazione in aree di Azure separate o che tutti gli utenti globali vengono usati da una singola area.
• Web application firewall (WAF) per proteggere l'applicazione, indipendentemente dal percorso seguito dal traffico per raggiungere i server di origine.

La memorizzazione nella cache nella rete perimetrale non è una parte critica del recapito dell'applicazione. Se la memorizzazione nella cache è importante, vedere Distribuzione di contenuti globali cruciali per un approccio alternativo.

Nota

Questo caso d'uso fa parte di una strategia di progettazione complessiva che copre un approccio alternativo quando Frontdoor di Azure non è disponibile. Per informazioni sul contesto e sulle considerazioni, vedere Applicazioni Web globali cruciali.

Approccio

Questa soluzione di bilanciamento del carico basata su DNS usa più profili di Gestione traffico di Azure per monitorare Frontdoor di Azure. Nel caso improbabile di un problema di disponibilità, Gestione traffico reindirizza il traffico attraverso gateway applicazione.

La soluzione include i componenti seguenti:

• Gestione traffico che usa la modalità di routing prioritario ha due endpoint. Per impostazione predefinita, Gestione traffico invia richieste tramite Frontdoor di Azure. Se Frontdoor di Azure non è disponibile, un secondo profilo di Gestione traffico determina dove indirizzare la richiesta. Il secondo profilo è descritto di seguito.

• Frontdoor di Azure elabora e instrada la maggior parte del traffico dell'applicazione. Frontdoor di Azure instrada il traffico al server applicazioni di origine appropriato e fornisce il percorso primario all'applicazione. Il WAF di Frontdoor di Azure protegge l'applicazione da minacce comuni alla sicurezza. Se Frontdoor di Azure non è disponibile, il traffico viene reindirizzato automaticamente attraverso il percorso secondario.

• Gestione traffico che usa la modalità di routing delle prestazioni ha un endpoint per ogni istanza di gateway applicazione. Gestione traffico invia richieste all'istanza di gateway applicazione con le migliori prestazioni dalla posizione del client.

• gateway applicazione viene distribuito in ogni area e invia il traffico ai server di origine all'interno di tale area. gateway applicazione WAF protegge qualsiasi traffico che scorre attraverso il percorso secondario.

• I server applicazioni di origine devono essere pronti per accettare il traffico sia da Frontdoor di Azure che da gateway applicazione di Azure, in qualsiasi momento.

Considerazioni

Le sezioni seguenti descrivono alcune considerazioni importanti per questo tipo di architettura. È anche consigliabile esaminare le applicazioni Web globali cruciali per altre importanti considerazioni e compromessi quando si usa Frontdoor di Azure in una soluzione cruciale.

Configurazione di Gestione traffico

Questo approccio usa profili annidati di Gestione traffico per ottenere il routing basato su priorità e basato sulle prestazioni insieme per il percorso di traffico alternativo dell'applicazione. In uno scenario semplice con un'origine in una singola area, potrebbe essere necessario un singolo profilo di Gestione traffico configurato per l'uso del routing basato su priorità.

Distribuzione a livello di area

Frontdoor di Azure è un servizio globale, mentre gateway applicazione è un servizio a livello di area.

I punti di presenza di Frontdoor di Azure vengono distribuiti a livello globale e le connessioni TCP e TLS terminano al punto di presenza più vicino al client. Questo comportamento migliora le prestazioni dell'applicazione. Al contrario, quando i client si connettono a gateway applicazione, le connessioni TCP e TLS terminano al gateway applicazione che riceve la richiesta, indipendentemente dalla posizione in cui è stato originato il traffico.

Connessioni dai client

Come servizio multi-tenant globale, Frontdoor di Azure offre una protezione intrinseca contro un'ampia gamma di minacce. Frontdoor di Azure accetta solo traffico HTTP e HTTPS valido e non accetta il traffico su altri protocolli. Microsoft gestisce gli indirizzi IP pubblici usati da Frontdoor di Azure per le connessioni in ingresso. A causa di queste caratteristiche, Frontdoor di Azure può contribuire a proteggere l'origine da vari tipi di attacco e le origini possono essere configurate per l'uso della connettività collegamento privato.

Al contrario, gateway applicazione è un servizio con connessione Internet con un indirizzo IP pubblico dedicato. È necessario proteggere i server di rete e di origine da diversi tipi di attacco. Per altre informazioni, vedere Sicurezza dell'origine.

collegamento privato connessioni ai server di origine

Frontdoor di Azure Premium offre collegamento privato connettività alle origini, riducendo la superficie di attacco internet pubblica della soluzione.

Se si usa collegamento privato per connettersi alle origini, è consigliabile distribuire un endpoint privato nella rete virtuale e configurare gateway applicazione per usare l'endpoint privato come back-end per l'applicazione.

Scalabilità

Quando si distribuiscono gateway applicazione, si distribuiscono risorse di calcolo dedicate per la soluzione. Se grandi quantità di traffico arrivano all'gateway applicazione in modo imprevisto, è possibile osservare problemi di prestazioni o affidabilità.

Per attenuare questo rischio, valutare come ridimensionare l'istanza di gateway applicazione. Usare la scalabilità automatica o assicurarsi di averla ridimensionata manualmente per gestire la quantità di traffico che si potrebbe ricevere dopo il failover.

Memorizzazione nella cache

Se si usano le funzionalità di memorizzazione nella cache di Frontdoor di Azure, è importante tenere presente che dopo che il traffico passa al percorso alternativo e usa gateway applicazione, il contenuto non viene più gestito dalle cache di Frontdoor di Azure.

Se si dipende dalla memorizzazione nella cache per la soluzione, vedere Distribuzione di contenuti globali cruciali per un approccio alternativo che usa una rete CDN partner come fallback in Frontdoor di Azure.

In alternativa, se si usa la memorizzazione nella cache ma non è una parte essenziale della strategia di distribuzione dell'applicazione, valutare se è possibile aumentare o aumentare le istanze delle origini in modo da gestire l'aumento del carico causato dal maggior numero di mancati riscontri nella cache durante un failover.

Compromessi

Questo tipo di architettura è più utile se si vuole che il percorso di traffico alternativo usi funzionalità come le regole di elaborazione delle richieste, un WAF e l'offload TLS. Sia Frontdoor di Azure che gateway applicazione offrono funzionalità simili.

Esistono tuttavia compromessi:

• Complessità operativa. Quando si usa una di queste funzionalità, è necessario configurarle sia in Frontdoor di Azure che in gateway applicazione. Ad esempio, se si apporta una modifica di configurazione al WAF di Frontdoor di Azure, è necessario applicare anche la stessa modifica di configurazione al gateway applicazione WAF. La complessità operativa diventa molto più elevata quando è necessario riconfigurare e testare due sistemi distinti.

• Parità delle caratteristiche. Anche se esistono analogie tra le funzionalità offerte da Frontdoor di Azure e gateway applicazione, molte funzionalità non hanno parità esatta. Tenere presente queste differenze, perché potrebbero influire sul modo in cui l'applicazione viene distribuita in base al percorso di traffico che segue.

  gateway applicazione non fornisce la memorizzazione nella cache. Per altre informazioni su questa differenza, vedere Memorizzazione nella cache.

  Frontdoor di Azure e gateway applicazione sono prodotti distinti e hanno casi d'uso diversi. In particolare, i due prodotti sono diversi nel modo in cui vengono distribuiti nelle aree di Azure. Assicurarsi di comprendere i dettagli di ogni prodotto e come usarli.

• Costo. In genere è necessario distribuire un'istanza di gateway applicazione in ogni area in cui si ha un'origine. Poiché ogni istanza di gateway applicazione viene fatturata separatamente, il costo può diventare elevato quando sono state distribuite origini in diverse aree.

  Se il costo è un fattore significativo per la soluzione, vedere Distribuzione di contenuti globali cruciali per un approccio alternativo che usa una rete per la distribuzione di contenuti partner come fallback a Frontdoor di Azure. Alcune reti CDN fatturano il traffico in base al consumo, quindi questo approccio potrebbe risultare più conveniente. Tuttavia, è possibile perdere alcuni degli altri vantaggi dell'uso di gateway applicazione per la soluzione.

  In alternativa, è possibile valutare la possibilità di distribuire un'architettura alternativa in cui Gestione traffico può instradare il traffico direttamente ai servizi dell'applicazione PaaS (Platform as a Service), evitando la necessità di gateway applicazione e riducendo i costi. È possibile prendere in considerazione questo approccio se si usa un servizio come Servizio app di Azure o App Azure Container per la soluzione. Tuttavia, se si segue questo approccio, esistono diversi compromessi importanti da considerare:

  • WAF: Frontdoor di Azure e gateway applicazione offrono entrambe funzionalità WAF. Se si espongono i servizi dell'applicazione direttamente a Internet, potrebbe non essere possibile proteggere l'applicazione con un WAF.
  • Offload TLS: Frontdoor di Azure e gateway applicazione entrambe terminano le connessioni TLS. I servizi dell'applicazione devono essere configurati per terminare le connessioni TLS.
  • Routing: Sia Frontdoor di Azure che gateway applicazione eseguire il routing tra più origini o back-end, incluso il routing basato sul percorso, e supportano regole di routing complesse. Se i servizi dell'applicazione vengono esposti direttamente a Internet, non è possibile eseguire il routing del traffico.

Avviso

Se si considera di esporre l'applicazione direttamente a Internet, creare un modello di minaccia completo e assicurarsi che l'architettura soddisfi i requisiti di sicurezza, prestazioni e resilienza.

Se si usano macchine virtuali per ospitare la soluzione, non è consigliabile esporre le macchine virtuali a Internet.

Passaggi successivi

Esaminare lo scenario di recapito del contenuto globale per comprendere se si applica alla soluzione.