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.

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. Per questo motivo, anche i concorrenti di Microsoft consigliano di usare più percorsi di ingresso per carichi di lavoro cruciali.

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 il 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ò può significare che sono presenti più istanze dell'applicazione in aree di Azure separate o che tutti gli utenti globali provengono 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 nel perimetro di rete non è una parte fondamentale del recapito dell'applicazione. Se la memorizzazione nella cache è importante, vedere Distribuzione di contenuti globali cruciali per un approccio alternativo.

Annotazioni

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.

Avvicinarsi

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

La soluzione include i componenti seguenti:

• Gestore del traffico che usa la modalità di routing con priorità 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 di sicurezza comuni. Se Frontdoor di Azure non è disponibile, il traffico viene reindirizzato automaticamente attraverso il percorso secondario.

• Traffic Manager che utilizza la modalità di instradamento delle prestazioni ha un endpoint per ogni istanza di Application Gateway. Il Traffic Manager invia richieste all'istanza del Application Gateway con le migliori prestazioni dalla posizione del client.

• Gateway di Application viene distribuito in ogni regione e invia traffico ai server di origine all'interno di tale regione. Il WAF del gateway di applicazione protegge qualsiasi traffico che passa attraverso il percorso secondario.

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

Considerazioni

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

Configurazione del Gestore del 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

Azure Front Door è un servizio globale, mentre Application Gateway è un servizio regionale.

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 al gateway applicazione, le connessioni TCP e TLS terminano nel gateway applicazione che riceve la richiesta, indipendentemente dalla posizione in cui è stato originato il traffico.

Connessioni da clienti

Come servizio multi-tenant globale, Frontdoor di Azure offre una protezione intrinseca da diverse 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, Azure Front Door può contribuire a proteggere l'origine da vari tipi di attacco e le origini possono essere configurate per l'uso della connettività Private Link.

Al contrario, Application Gateway è un servizio rivolto verso l'esterno 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.

Connessioni di collegamento privato ai server di origine

Azure Front Door Premium offre connettività privata alle tue origini, riducendo così l'area esposta su Internet della tua soluzione.

Quando si usa Private Link per connettersi alle origini, valutare la possibilità di distribuire un endpoint privato nella rete virtuale e configurare Application Gateway per usare l'endpoint privato come back-end per l'applicazione.

Scalabilità

Quando si distribuisce Application Gateway, le risorse di calcolo dedicate vengono distribuite automaticamente per supportare il funzionamento dell'istanza di Application Gateway. Se grandi quantità di traffico arrivano in modo imprevisto al gateway applicazione, è possibile osservare problemi di prestazioni o affidabilità.

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

Memorizzazione nella cache

Se si usano le funzionalità di memorizzazione nella cache di Azure Front Door, è importante tenere presente che, dopo che il traffico passa al percorso alternativo e utilizza Application Gateway, il contenuto non viene più servito dalle cache di Azure Front Door.

Se dipendi dal caching per la tua soluzione, consulta Distribuzione di contenuti globali mission-critical per un approccio alternativo che utilizza una rete alternativa di distribuzione dei contenuti (CDN) come fallback ad Azure Front Door.

In alternativa, se si utilizza il caching ma non è una parte essenziale della strategia di distribuzione dell'applicazione, valutare se è possibile scalare le istanze o le origini per gestire l'aumento del carico causato dal maggior numero di mancate corrispondenze nella cache durante un failover.

Svantaggi

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 Azure Front Door che l'Azure Application Gateway offrono funzionalità simili.

Tuttavia, esistono compromessi:

• Complessità operativa. Quando si usa una di queste funzionalità, è necessario configurarli sia in Azure Front Door che nell'Application Gateway. Ad esempio, se si apporta una modifica di configurazione al Front Door WAF di Azure, è necessario applicare anche la stessa modifica di configurazione all'Application Gateway WAF. La complessità operativa diventa molto più elevata quando è necessario riconfigurare e testare due sistemi separati.

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

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

  Azure Front Door e Application Gateway 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 Application Gateway in ogni area in cui si ha un server di origine. Poiché ogni istanza dell'Application Gateway viene fatturata separatamente, il costo può diventare elevato quando le origini sono distribuite in diverse regioni.

  Se il costo è un fattore significativo per la tua soluzione, consulta Distribuzione di contenuti globali di importanza critica per un approccio alternativo che utilizza una rete per la distribuzione di contenuti alternativa (CDN) come fallback ad Azure Front Door. 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 dell'Application Gateway per la tua 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à del gateway applicazione e riducendo i costi. È possibile considerare 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: Azure Front Door e Application Gateway offrono entrambe funzionalità WAF. Se si espongono i servizi dell'applicazione direttamente a Internet, potrebbe non essere possibile proteggere l'applicazione con un WAF.
  • TLS offload: Azure Front Door e Gateway Applicazione terminano entrambi le connessioni TLS. I servizi dell'applicazione devono essere configurati per terminare le connessioni TLS.
  • Instradamento: Sia Azure Front Door che Application Gateway eseguono il routing attraverso più origini o backend, incluso il routing basato sul percorso, e supportano regole di instradamento complesse. Se i servizi dell'applicazione vengono esposti direttamente a Internet, non è possibile eseguire il routing del traffico.

Avvertimento

Se si considera l'esposizione diretta dell'applicazione 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.

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
• Priyanka Wilkins | Sviluppatore di contenuti principale

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

Passaggi successivi

Esaminare lo scenario di distribuzione di contenuti globale per capire se si applica alla soluzione.