Bedrijfskritiek globaal HTTP-inkomend verkeer

Bedrijfskritieke toepassingen moeten een hoge uptime handhaven, zelfs wanneer netwerkonderdelen niet beschikbaar of gedegradeerd zijn. Wanneer u inkomend webverkeer, routering en beveiliging ontwerpt, kunt u overwegen om meerdere Azure-services te combineren om een hoger beschikbaarheidsniveau te bereiken en om te voorkomen dat er een Single Point of Failure is.

Als u besluit deze methode te gebruiken, moet u een afzonderlijk netwerkpad naar uw toepassingsservers implementeren en moet elk pad afzonderlijk worden geconfigureerd en getest. U moet de volledige gevolgen van deze aanpak zorgvuldig overwegen.

In dit artikel wordt een benadering beschreven voor het ondersteunen van inkomend HTTP-verkeer via Azure Front Door en Azure Application Gateway. Deze aanpak kan aan uw behoeften voldoen als uw oplossing het volgende nodig heeft:

• Azure Front Door voor wereldwijde verkeersroutering. Dit kan betekenen dat u meerdere exemplaren van uw toepassing in afzonderlijke Azure-regio's hebt, of dat u alle globale gebruikers uit één regio kunt bedienen.
• Web Application Firewall (WAF) om uw toepassing te beveiligen, ongeacht het pad dat uw verkeer volgt om uw oorspronkelijke servers te bereiken.

Caching aan de netwerkrand is geen essentieel onderdeel van de levering van uw toepassing. Als caching belangrijk is, raadpleegt u Mission-critical global content delivery voor een alternatieve benadering.

Notitie

Deze use-case maakt deel uit van een algemene ontwerpstrategie die een alternatieve benadering omvat wanneer Azure Front Door niet beschikbaar is. Zie Bedrijfskritieke wereldwijde webtoepassingen voor informatie over de context en overwegingen.

Methode

Deze op DNS gebaseerde taakverdelingsoplossing maakt gebruik van meerdere Azure Traffic Manager-profielen om Azure Front Door te bewaken. In het onwaarschijnlijke geval van een beschikbaarheidsprobleem leidt Traffic Manager verkeer om via Application Gateway.

De oplossing bevat de volgende onderdelen:

• Traffic Manager met prioriteitsrouteringsmodus heeft twee eindpunten. Traffic Manager verzendt standaard aanvragen via Azure Front Door. Als Azure Front Door niet beschikbaar is, bepaalt een tweede Traffic Manager-profiel waar de aanvraag moet worden doorgestuurd. Het tweede profiel wordt hieronder beschreven.

• Azure Front Door verwerkt en routeert het grootste deel van uw toepassingsverkeer. Azure Front Door routeert verkeer naar de juiste oorspronkelijke toepassingsserver en biedt het primaire pad naar uw toepassing. De WAF van Azure Front Door beschermt uw toepassing tegen veelvoorkomende beveiligingsrisico's. Als Azure Front Door niet beschikbaar is, wordt verkeer automatisch omgeleid via het secundaire pad.

• Traffic Manager met de routeringsmodus voor prestaties heeft een eindpunt voor elk Application Gateway exemplaar. Deze Traffic Manager verzendt aanvragen naar het Application Gateway-exemplaar met de beste prestaties vanaf de locatie van de client.

• Application Gateway wordt geïmplementeerd in elke regio en verzendt verkeer naar de oorspronkelijke servers in die regio. De WAF van Application Gateway beveiligt al het verkeer dat via het secundaire pad stroomt.

• Uw oorspronkelijke toepassingsservers moeten op elk gewenst moment gereed zijn voor het accepteren van verkeer van zowel Azure Front Door als Azure Application Gateway.

Overwegingen

In de volgende secties worden enkele belangrijke overwegingen voor dit type architectuur beschreven. U moet ook bedrijfskritieke wereldwijde webtoepassingen bekijken voor andere belangrijke overwegingen en compromissen wanneer u Azure Front Door gebruikt in een bedrijfskritieke oplossing.

Configuratie van Traffic Manager

Deze benadering maakt gebruik van geneste Traffic Manager-profielen om routering op basis van prioriteit en prestaties te realiseren voor het alternatieve verkeerspad van uw toepassing. In een eenvoudig scenario met een oorsprong in één regio hebt u mogelijk slechts één Traffic Manager-profiel nodig dat is geconfigureerd voor het gebruik van routering op basis van prioriteit.

Regionale distributie

Azure Front Door is een wereldwijde service, terwijl Application Gateway een regionale service is.

De aanwezigheidspunten van Azure Front Door worden wereldwijd geïmplementeerd en TCP- en TLS-verbindingen worden beëindigd op het dichtstbijzijnde aanwezigheidspunt van de client. Dit gedrag verbetert de prestaties van uw toepassing. Wanneer clients daarentegen verbinding maken met Application Gateway, worden hun TCP- en TLS-verbindingen beëindigd op de Application Gateway die de aanvraag ontvangt, ongeacht waar het verkeer vandaan komt.

Verbindingen van clients

Azure Front Door is een wereldwijde multitenant-service en biedt inherente bescherming tegen verschillende bedreigingen. Azure Front Door accepteert alleen geldig HTTP- en HTTPS-verkeer en accepteert geen verkeer op andere protocollen. Microsoft beheert de openbare IP-adressen die Azure Front Door gebruikt voor de binnenkomende verbindingen. Vanwege deze kenmerken kan Azure Front Door helpen uw oorsprong te beschermen tegen verschillende aanvalstypen en kunnen uw origins worden geconfigureerd voor het gebruik van Private Link connectiviteit.

Application Gateway daarentegen is een internetgerichte service met een toegewezen openbaar IP-adres. U moet uw netwerk- en oorspronkelijke servers beschermen tegen verschillende aanvalstypen. Zie Origin-beveiliging voor meer informatie.

Private Link verbindingen met oorspronkelijke servers

Azure Front Door Premium biedt Private Link connectiviteit met uw origins, waardoor de openbare internetgerichte oppervlakte van uw oplossing wordt verkleind.

Als u Private Link gebruikt om verbinding te maken met uw origins, kunt u een privé-eindpunt implementeren in uw virtuele netwerk en Application Gateway configureren om het privé-eindpunt te gebruiken als back-end voor uw toepassing.

Schalen

Wanneer u Application Gateway implementeert, implementeert u toegewezen rekenresources voor uw oplossing. Als er onverwacht grote hoeveelheden verkeer op uw Application Gateway aankomen, kunt u prestatie- of betrouwbaarheidsproblemen ondervinden.

Als u dit risico wilt beperken, moet u overwegen hoe u uw Application Gateway exemplaar schaalt. Gebruik automatische schaalaanpassing of zorg ervoor dat u deze handmatig hebt geschaald om de hoeveelheid verkeer te verwerken die u mogelijk ontvangt na een failover.

Caching

Als u de cachefuncties van Azure Front Door gebruikt, is het belangrijk om er rekening mee te houden dat nadat uw verkeer naar het alternatieve pad is overgeschakeld en Application Gateway gebruikt, inhoud niet meer wordt geleverd vanuit de Azure Front Door-caches.

Als u afhankelijk bent van caching voor uw oplossing, raadpleegt u Bedrijfskritieke wereldwijde contentlevering voor een alternatieve benadering die gebruikmaakt van een partner-CDN als terugval naar Azure Front Door.

Als u caching gebruikt, maar dit geen essentieel onderdeel is van uw strategie voor toepassingslevering, kunt u ook overwegen of u uw origins kunt uitschalen of omhoog kunt schalen om de verhoogde belasting aan te kunnen die is veroorzaakt door het hogere aantal cachemissers tijdens een failover.

Compromissen

Dit type architectuur is het handigst als u wilt dat uw alternatieve verkeerspad functies gebruikt, zoals regels voor aanvraagverwerking, een WAF en TLS-offload. Zowel Azure Front Door als Application Gateway bieden vergelijkbare mogelijkheden.

Er zijn echter compromissen:

• Operationele complexiteit. Wanneer u een van deze functies gebruikt, moet u deze configureren op zowel Azure Front Door als Application Gateway. Als u bijvoorbeeld een configuratiewijziging aanbrengt in uw Azure Front Door WAF, moet u dezelfde configuratiewijziging ook toepassen op uw Application Gateway WAF. Uw operationele complexiteit wordt veel complexer wanneer u twee afzonderlijke systemen opnieuw moet configureren en testen.

• Functiepariteit. Hoewel er overeenkomsten zijn tussen de functies die Azure Front Door en Application Gateway bieden, hebben veel functies geen exacte pariteit. Houd rekening met deze verschillen, omdat ze van invloed kunnen zijn op de manier waarop de toepassing wordt geleverd op basis van het verkeerspad dat deze volgt.

  Application Gateway biedt geen caching. Zie Opslaan in cache voor meer informatie over dit verschil.

  Azure Front Door en Application Gateway zijn verschillende producten en hebben verschillende use cases. De twee producten verschillen met name in de manier waarop ze worden geïmplementeerd in Azure-regio's. Zorg ervoor dat u de details van elk product begrijpt en hoe u deze gebruikt.

• Kosten. Doorgaans moet u een Application Gateway-exemplaar implementeren in elke regio waar u een oorsprong hebt. Omdat elk Application Gateway exemplaar afzonderlijk wordt gefactureerd, kunnen de kosten hoog worden wanneer u origins in verschillende regio's hebt geïmplementeerd.

  Als de kosten een belangrijke factor zijn voor uw oplossing, raadpleegt u Bedrijfskritieke wereldwijde contentlevering voor een alternatieve benadering die gebruikmaakt van een Partner Content Delivery Network (CDN) als een terugval naar Azure Front Door. Sommige CDN's factureren verkeer op basis van verbruik, dus deze benadering is mogelijk rendabeler. U kunt echter enkele van de andere voordelen van het gebruik van Application Gateway voor uw oplossing verliezen.

  U kunt ook een alternatieve architectuur implementeren waarbij Traffic Manager verkeer rechtstreeks naar PaaS-toepassingsservices (Platform as a Service) kan routeren, waardoor de noodzaak van Application Gateway wordt vermeden en uw kosten worden verminderd. U kunt deze benadering overwegen als u een service zoals Azure App Service of Azure Container Apps voor uw oplossing gebruikt. Als u deze benadering volgt, zijn er echter enkele belangrijke afwegingen die u moet overwegen:

  • WAF: Azure Front Door en Application Gateway bieden beide WAF-mogelijkheden. Als u uw toepassingsservices rechtstreeks op internet beschikbaar maakt, kunt u uw toepassing mogelijk niet beveiligen met een WAF.
  • TLS-offload: Azure Front Door en Application Gateway beide TLS-verbindingen beëindigen. Uw toepassingsservices moeten worden geconfigureerd om TLS-verbindingen te beëindigen.
  • Routering: Zowel Azure Front Door als Application Gateway routering uitvoeren in meerdere origins of back-ends, inclusief padgebaseerde routering, en ze ondersteunen complexe routeringsregels. Als uw toepassingsservices rechtstreeks beschikbaar zijn op internet, kunt u geen verkeersroutering uitvoeren.

Waarschuwing

Als u overweegt om uw toepassing rechtstreeks aan internet beschikbaar te maken, maakt u een grondig bedreigingsmodel en zorgt u ervoor dat de architectuur voldoet aan uw beveiligings-, prestatie- en tolerantievereisten.

Als u virtuele machines gebruikt om uw oplossing te hosten, moet u de virtuele machines niet beschikbaar maken voor internet.

Volgende stappen

Bekijk het globale scenario voor de levering van inhoud om te begrijpen of dit van toepassing is op uw oplossing.