Verksamhetskritisk global HTTP-ingress

Verksamhetskritiska program måste upprätthålla en hög drifttid, även när nätverkskomponenter är otillgängliga eller degraderade. När du utformar inkommande webbtrafik, routning och säkerhet kan du överväga att kombinera flera Azure-tjänster för att uppnå en högre tillgänglighetsnivå och undvika att ha en enda felpunkt.

Om du bestämmer dig för att använda den här metoden måste du implementera en separat nätverkssökväg till dina programservrar, och varje sökväg måste konfigureras och testas separat. Du måste noga överväga de fullständiga konsekvenserna av den här metoden.

Den här artikeln beskriver en metod för att stödja global HTTP-trafik ingress via Azure Front Door och Azure Application Gateway. Den här metoden kan passa dina behov om din lösning behöver:

• Azure Front Door för global trafikroutning. Det kan innebära att du har flera instanser av ditt program i separata Azure-regioner eller att du betjänar alla globala användare från en enda region.
• Brandvägg för webbprogram (WAF) för att skydda ditt program, oavsett vilken väg trafiken följer för att nå ursprungsservrarna.

Cachelagring vid nätverksgränsen är inte en viktig del av programleveransen. Om cachelagring är viktigt, se Verksamhetskritisk global innehållsleverans för en alternativ metod.

Anteckning

Det här användningsfallet är en del av en övergripande designstrategi som omfattar en alternativ metod när Azure Front Door inte är tillgänglig. Information om kontext och överväganden finns i Verksamhetskritiska globala webbprogram.

Metod

Den här DNS-baserade belastningsutjämningslösningen använder flera Azure Traffic Manager-profiler för att övervaka Azure Front Door. I det osannolika fallet med ett tillgänglighetsproblem omdirigerar Traffic Manager trafik via Application Gateway.

Lösningen innehåller följande komponenter:

• Traffic Manager som använder prioritetsroutningsläge har två slutpunkter. Som standard skickar Traffic Manager begäranden via Azure Front Door. Om Azure Front Door inte är tillgängligt avgör en andra Traffic Manager-profil var begäran ska dirigeras. Den andra profilen beskrivs nedan.

• Azure Front Door bearbetar och dirigerar merparten av din programtrafik. Azure Front Door dirigerar trafik till lämplig ursprungsprogramserver och tillhandahåller den primära sökvägen till ditt program. Azure Front Door WAF skyddar ditt program mot vanliga säkerhetshot. Om Azure Front Door inte är tillgängligt omdirigeras trafiken automatiskt via den sekundära sökvägen.

• Traffic Manager som använder prestandaroutningsläget har en slutpunkt för varje Application Gateway instans. Den här Traffic Manager skickar begäranden till Application Gateway-instansen med bästa prestanda från klientens plats.

• Application Gateway distribueras till varje region och skickar trafik till ursprungsservrarna i den regionen. Application Gateway waf skyddar all trafik som flödar genom den sekundära sökvägen.

• Dina ursprungliga programservrar måste vara redo att ta emot trafik från både Azure Front Door och Azure Application Gateway när som helst.

Överväganden

I följande avsnitt beskrivs några viktiga överväganden för den här typen av arkitektur. Du bör också granska verksamhetskritiska globala webbprogram för andra viktiga överväganden och kompromisser när du använder Azure Front Door i en verksamhetskritisk lösning.

Konfigurera Traffic Manager

Den här metoden använder kapslade Traffic Manager-profiler för att uppnå både prioritetsbaserad och prestandabaserad routning tillsammans för programmets alternativa trafikväg. I ett enkelt scenario med ett ursprung i en enda region kanske du bara behöver en enda Traffic Manager-profil konfigurerad för att använda prioritetsbaserad routning.

Regional distribution

Azure Front Door är en global tjänst, medan Application Gateway är en regional tjänst.

Azure Front Door-närvaropunkter distribueras globalt och TCP- och TLS-anslutningar avslutas vid den plats där klienten är närmast. Det här beteendet förbättrar programmets prestanda. När klienter däremot ansluter till Application Gateway avslutas deras TCP- och TLS-anslutningar på den Application Gateway som tar emot begäran, oavsett var trafiken härstammar.

Anslutningar från klienter

Som en global tjänst för flera klientorganisationer ger Azure Front Door ett inbyggt skydd mot en mängd olika hot. Azure Front Door accepterar endast giltig HTTP- och HTTPS-trafik och accepterar inte trafik i andra protokoll. Microsoft hanterar de offentliga IP-adresser som Azure Front Door använder för sina inkommande anslutningar. På grund av dessa egenskaper kan Azure Front Door hjälpa till att skydda ditt ursprung mot olika attacktyper, och ditt ursprung kan konfigureras för att använda Private Link anslutning.

Däremot är Application Gateway en internetuppkopplad tjänst med en dedikerad offentlig IP-adress. Du måste skydda dina nätverks- och ursprungsservrar mot en mängd olika attacktyper. Mer information finns i Ursprungssäkerhet.

Private Link anslutningar till ursprungsservrar

Azure Front Door Premium ger Private Link anslutning till ditt ursprung, vilket minskar den offentliga internetuppkopplade ytan i din lösning.

Om du använder Private Link för att ansluta till ditt ursprung bör du överväga att distribuera en privat slutpunkt till ditt virtuella nätverk och konfigurera Application Gateway att använda den privata slutpunkten som serverdel för ditt program.

Skalning

När du distribuerar Application Gateway distribuerar du dedikerade beräkningsresurser för din lösning. Om stora mängder trafik anländer till din Application Gateway oväntat kan du observera prestanda- eller tillförlitlighetsproblem.

Du kan minska den här risken genom att tänka på hur du skalar din Application Gateway-instans. Använd antingen autoskalning eller se till att du har skalat den manuellt för att hantera mängden trafik som du kan få när du har växlat över.

Cachelagring

Om du använder cachelagringsfunktionerna i Azure Front Door är det viktigt att vara medveten om att när trafiken växlar till den alternativa sökvägen och använder Application Gateway hanteras inte längre innehåll från Azure Front Door-cacheminnena.

Om du är beroende av cachelagring för din lösning läser du Verksamhetskritisk global innehållsleverans för en alternativ metod som använder en partner-CDN som reserv för Azure Front Door.

Om du använder cachelagring men det inte är en viktig del av din strategi för programleverans kan du överväga om du kan skala ut eller skala upp ditt ursprung för att hantera den ökade belastning som orsakades av det högre antalet cachemissar under en redundansväxling.

Avvägningar

Den här typen av arkitektur är mest användbar om du vill att din alternativa trafiksökväg ska använda funktioner som regler för bearbetning av begäranden, en WAF- och TLS-avlastning. Både Azure Front Door och Application Gateway har liknande funktioner.

Det finns dock kompromisser:

• Driftskomplexitet. När du använder någon av dessa funktioner måste du konfigurera dem på både Azure Front Door och Application Gateway. Om du till exempel gör en konfigurationsändring av din Azure Front Door WAF måste du tillämpa samma konfigurationsändring på din Application Gateway WAF också. Din driftskomplexitet blir mycket högre när du behöver konfigurera om och testa två separata system.

• Funktionsparitet. Det finns likheter mellan de funktioner som Azure Front Door och Application Gateway erbjuder, men många funktioner har inte exakt paritet. Tänk på dessa skillnader eftersom de kan påverka hur programmet levereras baserat på den trafikväg som det följer.

  Application Gateway tillhandahåller inte cachelagring. Mer information om den här skillnaden finns i Cachelagring.

  Azure Front Door och Application Gateway är distinkta produkter och har olika användningsfall. I synnerhet skiljer sig de två produkterna åt i hur de distribueras till Azure-regioner. Se till att du förstår informationen om varje produkt och hur du använder dem.

• Kostnad. Du behöver vanligtvis distribuera en Application Gateway instans till varje region där du har ett ursprung. Eftersom varje Application Gateway instans debiteras separat kan kostnaden bli hög när du har ursprung som distribuerats till flera regioner.

  Om kostnaden är en viktig faktor för din lösning, se Verksamhetskritisk global innehållsleverans för en alternativ metod som använder ett partnernätverk för innehållsleverans (CDN) som en återställning till Azure Front Door. Vissa CDN-fakturering för trafik på förbrukningsbasis, så den här metoden kan vara mer kostnadseffektiv. Du kan dock förlora några av de andra fördelarna med att använda Application Gateway för din lösning.

  Alternativt kan du överväga att distribuera en alternativ arkitektur där Traffic Manager kan dirigera trafik direkt till PaaS-programtjänster (plattform som en tjänst), undvika behovet av Application Gateway och minska dina kostnader. Du kan överväga den här metoden om du använder en tjänst som Azure App Service eller Azure Container Apps för din lösning. Men om du följer den här metoden finns det flera viktiga kompromisser att tänka på:

  • WAF: Både Azure Front Door och Application Gateway tillhandahåller WAF-funktioner. Om du exponerar dina programtjänster direkt på Internet kanske du inte kan skydda ditt program med en WAF.
  • TLS-avlastning: Både Azure Front Door och Application Gateway avsluta TLS-anslutningar. Dina programtjänster måste konfigureras för att avsluta TLS-anslutningar.
  • Routning: Både Azure Front Door och Application Gateway utföra routning över flera ursprung eller serverdelar, inklusive sökvägsbaserad routning, och de stöder komplexa routningsregler. Om dina programtjänster exponeras direkt mot Internet kan du inte utföra trafikroutning.

Varning

Om du överväger att exponera ditt program direkt för Internet skapar du en grundlig hotmodell och ser till att arkitekturen uppfyller kraven på säkerhet, prestanda och återhämtning.

Om du använder virtuella datorer som värd för din lösning bör du inte exponera de virtuella datorerna för Internet.

Nästa steg

Granska det globala innehållsleveransscenariot för att förstå om det gäller din lösning.