Global routningsredundans för verksamhetskritiska webbprogram

Verksamhetskritiska system strävar efter att minimera enskilda felpunkter genom att skapa redundans- och självåterställningsfunktioner i lösningen så mycket som möjligt. Alla enhetliga startpunkter i systemet kan betraktas som en felpunkt. Om den här komponenten upplever ett avbrott går hela systemet offline för användaren. När du väljer en routningstjänst är det viktigt att tänka på tillförlitligheten för själva tjänsten.

I arkitekturen för ett verksamhetskritiskt program väljs Azure Front Door på grund av sina serviceavtal på hög drifttid (SLA) och en omfattande funktionsuppsättning:

• Dirigera trafik till flera regioner i en aktiv-aktiv modell
• Transparent failover med TCP anycast
• Hantera statiskt innehåll från gränsnoder med hjälp av integrerade nätverk för innehållsleverans (CDN)
• Blockera obehörig åtkomst med integrerad brandvägg för webbprogram

Mer information om Funktionerna i Azure Front Door finns i Accelerera och skydda ditt webbprogram med Azure Front Door.

Azure Front Door är utformat för att ge största möjliga motståndskraft och tillgänglighet, inte bara för våra externa kunder, utan också för flera tjänster inom Microsoft. Azure Front Door-funktioner är mer än tillräckliga för att uppfylla de flesta affärskrav, men med alla distribuerade system kan du räkna med problem. Ingen komponent eller system är ofelbar. Microsoft erbjuder ett branschledande serviceavtal (SLA) för Azure Front Door. Även om en annan leverantör erbjuder ett serviceavtal med 100% drifttid är det viktigt att observera att det inte är en garanti för noll driftstopp och att serviceavtal vanligtvis tillhandahåller tjänstkrediter i händelse av ett avbrott.

Om affärskraven kräver ett högre sammansatt SLO eller drift utan avbrott i händelse av ett avbrott, måste du förlita dig på flera alternativa ingångsvägar för trafiken. Många stora organisationer och högprofilerade webbegenskaper använder den här metoden för att säkerställa högsta möjliga tillgänglighet och för att optimera leveransprestanda. Strävan efter ett högre servicenivåmål medför dock betydande kostnader, driftkostnader och kan sänka din övergripande tillförlitlighet. Överväg noggrant de kompromisser och potentiella problem som den alternativa stigen kan medföra i andra komponenter som ingår i den kritiska banan. Även när effekten av otillgänglighet är betydande kan komplexiteten uppväga fördelarna.

En metod är att definiera en sekundär sökväg, med alternativa tjänster, som endast aktiveras när Azure Front Door inte är tillgängligt. Funktionsparitet med Azure Front Door bör inte behandlas som ett hårt krav. Prioritera funktioner du absolut behöver för att säkerställa affärsverksamhetens kontinuitet, även om de potentiellt körs med en begränsad omfattning.

I den här artikeln beskrivs några strategier för global routning med Azure Traffic Manager som alternativ router i situationer där Azure Front Door inte är tillgängligt.

Tillvägagångssätt

Det här arkitekturdiagrammet visar en generell metod med flera redundanta trafikvägar.

Med den här metoden kommer vi att introducera flera komponenter och ge vägledning som gör betydande ändringar i samband med leveransen av dina webbprogram:

1. Azure Traffic Manager dirigerar trafik till Azure Front Door eller till den alternativa tjänst som du har valt.

   Azure Traffic Manager är en DNS-baserad global lastbalanserare. Domänens CNAME-post pekar på Traffic Manager, som avgör målet baserat på hur du konfigurerar dess routningsmetod.

   Traffic Manager kan automatiskt växla trafik till alternativa sökvägar om en väg inte är tillgänglig, eller så kan du också växla trafik manuellt om du behöver. Mer information finns i Hälsoövervakning.

   Viktigt!

   Den här lösningen minskar riskerna med avbrott i Azure Front Door eller andra leverantörer, men den är känslig för Avbrott i Azure Traffic Manager som en global felpunkt. Mer information finns i Tillgänglighet för Azure Traffic Manager.

   Du kan också överväga att använda ett annat globalt trafikroutningssystem, till exempel en global lastbalanserare. Traffic Manager fungerar dock bra i många situationer.

2. Du har två ingresssökvägar:

   • Azure Front Door tillhandahåller den primära sökvägen och processerna och dirigerar all programtrafik.

   • En annan router används som en säkerhetskopia för Azure Front Door. Trafiken flödar bara genom denna sekundära väg om Front Door inte är tillgänglig.

   Vilken tjänst du väljer för den sekundära routern beror på många faktorer. Du kan välja att använda Azure-inbyggda tjänster eller tjänster från tredje part. I de här artiklarna tillhandahåller vi azure-inbyggda alternativ där det är möjligt för att undvika att lägga till ytterligare driftskomplexitet i lösningen. Om du använder tjänster från tredje part måste du använda flera kontrollplan för att hantera din lösning.

3. Dina ursprungsprogramservrar måste vara redo att acceptera trafik från någon av tjänsterna. Överväg hur du skyddar trafik till ditt ursprung och vilka ansvarsområden Azure Front Door och andra överordnade tjänster tillhandahåller. Se till att ditt program kan hantera trafik från den sökväg som trafiken flödar genom.

Avvägningar

Även om den här åtgärdsstrategin kan göra programmet tillgängligt under plattformsavbrott, finns det några betydande kompromisser. Du bör väga de potentiella fördelarna mot kända kostnader och fatta ett välgrundat beslut om huruvida fördelarna är värda dessa kostnader.

• Ekonomisk kostnad: När du distribuerar flera redundanta sökvägar till ditt program måste du överväga kostnaden för att distribuera och köra resurserna. Vi tillhandahåller två exempelscenarier för olika användningsfall, som var och en har en annan kostnadsprofil.

• Driftkomplexitet: Varje gång du lägger till ytterligare komponenter i din lösning ökar du dina hanteringskostnader. Ändringar i en komponent kan påverka andra komponenter.

  Anta att du bestämmer dig för att använda nya funktioner i Azure Front Door. Du måste kontrollera om din alternativa trafiksökväg också ger en motsvarande funktion, och om inte, måste du bestämma hur du ska hantera skillnaden i beteende mellan de två trafikvägarna. I verkliga program kan dessa komplexiteter ha höga kostnader och kan utgöra en stor risk för systemets stabilitet.

• Prestanda: Den här designen kräver ytterligare CNAME-sökningar under namnmatchningen. I de flesta program är detta inte något större problem, men du bör utvärdera om programmets prestanda påverkas genom att införa ytterligare lager i din ingresssökväg.

• Affärsmöjlighetskostnad: Att utforma och implementera redundanta ingressvägar kräver en betydande teknisk investering, vilket i slutändan medför en möjlighetskostnad för funktionsutveckling och andra plattformsförbättringar.

Tillgänglighet för Azure Traffic Manager

Azure Traffic Manager är en tillförlitlig tjänst med ett branschledande serviceavtal, men trafikhanteringen behöver extra åtgärder för att tillhandahålla 100% tillgänglighet. Om Traffic Manager inte är tillgängligt kanske användarna inte kan komma åt ditt program, även om Både Azure Front Door och den alternativa tjänsten är tillgängliga. Det är viktigt att planera hur din lösning ska fortsätta att fungera under dessa omständigheter.

Traffic Manager returnerar cachebara DNS-svar. Om time to live (TTL) på dina DNS-poster tillåter cachelagring är korta avbrott i Traffic Manager kanske inte ett problem. Det beror på att underordnade DNS-matchare kan ha cachelagrat ett tidigare svar. Du bör planera för långvariga avbrott. Du kan välja att konfigurera om DNS-servrarna manuellt för att dirigera användare till Azure Front Door om Traffic Manager inte är tillgängligt.

Trafikroutningens konsekvens

Det är viktigt att förstå funktionerna och funktionerna i Azure Front Door som du använder och förlitar dig på om du även ska använda en annan tjänst. När du väljer den alternativa tjänsten bestämmer du de minsta funktioner som du behöver och utelämnar andra funktioner när lösningen är i ett degraderat läge.

När du planerar en alternativ trafikväg bör du tänka på följande viktiga frågor:

• Använder du Cachelagringsfunktionerna i Azure Front Door? Kan dina ursprungsservrar hänga med i trafiken om cachelagring inte är tillgänglig?
• Använder du Azure Front Door-regelmotorn för att utföra anpassad routningslogik eller för att skriva om begäranden?
• Använder du webbapplikationsbrandväggen Azure Front Door (WAF) för att skydda dina applikationer?
• Begränsar du trafik baserat på IP-adress eller geografi?
• Vem utfärdar och hanterade dina TLS-certifikat?
• Hur begränsar du åtkomsten till dina ursprungsprogramservrar för att säkerställa att den kommer via Azure Front Door? Använder du Private Link eller förlitar du dig på offentliga IP-adresser med tjänsttaggar och identifierarhuvuden?
• Accepterar dina programservrar trafik från någon annan plats än Azure Front Door? Om de gör det, vilka protokoll accepterar de?
• Använder dina klienter Azure Front Door HTTP/2-stöd?

Brandvägg för webbaserade program (WAF)

Om du använder Azure Front Door WAF för att skydda ditt program bör du tänka på vad som händer om trafiken inte går via Azure Front Door.

Om din alternativa sökväg även innehåller en WAF kan du överväga följande frågor:

• Kan den konfigureras på samma sätt som din Azure Front Door WAF?
• Behöver den justeras och testas oberoende av varandra för att minska sannolikheten för falska positiva identifieringar?

Överväg kompromissen med att acceptera trafik från Internet utan några kontroller. Om en angripare upptäcker en oskyddad sekundär trafiksökväg till ditt program kan de skicka skadlig trafik via den sekundära sökvägen även när den primära sökvägen innehåller en WAF.

Det är bäst att skydda alla sökvägar till dina programservrar.

Ytterligare överväganden för hög tillgänglighet

När du utformar en verksamhetskritisk webbarkitektur finns det många faktorer som kan påverka programmets tillgänglighet och prestanda. Många av dessa faktorer går utöver Konfiguration och funktioner för Azure Front Door och relaterar i stället till det övergripande ekosystemet och lösningsdesignen.

Domännamn och DNS

Ditt verksamhetskritiska program bör använda anpassade domännamn för att styra hur trafiken flödar till ditt program och minska beroenden på en enskild provider.

Det är också en bra idé att använda en högkvalitativ och elastisk DNS-tjänst för ditt domännamn, till exempel Azure DNS. Om domännamnets DNS-servrar inte är tillgängliga kan användarna inte nå din tjänst.

Vi rekommenderar att du använder flera DNS-resolver för att öka den totala motståndskraften ytterligare.

CNAME-länkning

Lösningar som kombinerar Traffic Manager, Azure Front Door och andra tjänster använder en DNS CNAME-matchningsprocess i flera lager, även kallad CNAME-länkning. När du till exempel löser din egen anpassade domän kan du se fem eller fler CNAME-poster innan en IP-adress returneras.

Att lägga till ytterligare länkar till en CNAME-kedja kan påverka prestanda för DNS-namnmatchning. DNS-svar cachelagras dock vanligtvis, vilket minskar prestandapåverkan.

TLS-certifikat

För ett verksamhetskritiskt program rekommenderar vi att du etablerar och använder dina egna TLS-certifikat i stället för de hanterade certifikat som tillhandahålls av Azure Front Door. Du minskar antalet potentiella problem med den här komplexa arkitekturen.

Här är några fördelar:

• För att utfärda och förnya hanterade TLS-certifikat verifierar Azure Front Door ditt ägarskap för domänen. Domänverifieringsprocessen förutsätter att domänens CNAME-poster pekar direkt på Azure Front Door. Men det antagandet är ofta inte korrekt. Att utfärda och förnya hanterade TLS-certifikat på Azure Front Door kanske inte fungerar smidigt och du ökar risken för avbrott på grund av TLS-certifikatproblem.

• Även om dina andra tjänster tillhandahåller hanterade TLS-certifikat kanske de inte kan verifiera domänägarskapet.

• Om varje tjänst hämtar sina egna hanterade TLS-certifikat oberoende av varandra kan det finnas problem. Användare kanske till exempel inte förväntar sig att se olika TLS-certifikat som utfärdats av olika myndigheter, eller med olika utgångsdatum eller tumavtryck.

Det finns dock ytterligare åtgärder som rör förnyelse och uppdatering av dina certifikat innan de upphör att gälla.

Ursprungssäkerhet

När du konfigurerar ditt ursprung för att endast acceptera trafik via Azure Front Door får du skydd mot layer 3- och layer 4 DDoS-attacker. Azure Front Door svarar bara på giltig HTTP-trafik, vilket också bidrar till att minska din exponering för många protokollbaserade hot. Om du ändrar arkitekturen för att tillåta alternativa ingressvägar måste du utvärdera om du oavsiktligt har ökat ditt ursprungs exponering för hot.

Hur flödar trafiken genom din alternativa sökväg om du använder Private Link för att ansluta från Azure Front Door till ursprungsservern? Kan du använda privata IP-adresser för att komma åt ditt ursprung eller måste du använda offentliga IP-adresser?

Om ditt ursprung använder Azure Front Door-tjänsttaggen och X-Azure-FDID-huvudet för att verifiera att trafiken har flödat via Azure Front Door kan du överväga hur ditt ursprung kan konfigureras om för att verifiera att trafiken har flödat genom någon av dina giltiga sökvägar. Du måste testa att du inte av misstag har öppnat ditt ursprung för trafik via andra sökvägar, inklusive från andra kunders Azure Front Door-profiler.

När du planerar säkerheten för den ursprungliga infrastrukturen kontrollerar du om den alternativa trafikvägen är beroende av upprättandet av dedikerade offentliga IP-adresser. sv-SE: Detta kan behöva en manuellt startad process för att aktivera säkerhetskopieringsvägen.

Om det finns dedikerade offentliga IP-adresser bör du överväga om du ska implementera Azure DDoS Protection för att minska risken för överbelastningsattacker mot ditt ursprung. Tänk också på om du behöver implementera Azure Firewall eller en annan brandvägg som kan skydda dig mot en mängd olika nätverkshot. Du kan också behöva fler strategier för intrångsidentifiering. Dessa kontroller kan vara viktiga element i en mer komplex arkitektur med flera vägar.

Hälsomodellering

Verksamhetskritisk designmetodik kräver en systemhälsomodell som ger dig övergripande observerbarhet för lösningen och dess komponenter. När du använder flera ingresssökvägar för trafik måste du övervaka hälsotillståndet för varje sökväg. Om trafiken omdirigeras till den sekundära ingressvägen bör hälsomodellen avbilda att systemet fortfarande fungerar men att det körs i ett nedsatt tillstånd.

Ta med dessa frågor i din hälsomodelldesign:

• Hur övervakar de olika komponenterna i lösningen hälsotillståndet för underordnade komponenter?
• När bör hälsoövervakare betrakta underordnade komponenter som inte felfria?
• Hur lång tid tar det innan ett avbrott upptäcks?
• Hur lång tid tar det för trafik att dirigeras via en alternativ sökväg när ett avbrott har identifierats?

Hälsoövervakning

Det finns flera globala belastningsutjämningslösningar som gör att du kan övervaka hälsotillståndet för Azure Front Door och utlösa en automatisk redundansväxling till en säkerhetskopieringsplattform om ett avbrott inträffar. Azure Traffic Manager passar i de flesta fall.

När du använder Traffic Manager konfigurerar du slutpunktsövervakning för att övervaka underordnade tjänster genom att ange vilken URL som ska kontrolleras, hur ofta url:en ska kontrolleras och när den underordnade tjänsten ska övervägas som inte felfri baserat på avsökningssvar. Ju kortare intervallet mellan kontroller är, desto kortare tid tar det för Traffic Manager att dirigera trafik via en alternativ sökväg för att nå ursprungsservern. Du bör konfigurera Traffic Manager för att övervaka hälsotillståndet för din Azure Front Door-slutpunkt. Läs bästa praxis för arkitektur i Azure Traffic Manager för att lära dig mer om hur Traffic Manager-konfigurationen påverkar din övergripande arkitektur.

Förlita dig inte enbart på Traffic Managers slutpunktsövervakning. Det är också lämpligt att ha ett sekundärt övervakningssystem som kan kräva lösningar från tredje part eller anpassad övervakning. Eftersom Azure Front Door är ett globalt distribuerat system som använder anycast-nätverk är det viktigt att utföra anslutningskontroller inom samma geografiska regioner som dina klienter.

Du bör också vara beredd att utlösa dina svarsprocedurer manuellt om dina övervakningssystem inte identifierar det.

Svarsförfaranden

Om dina övervakningssystem upptäcker att Azure Front Door inte är tillgängligt behöver du Traffic Manager för att omdirigera trafik via den alternativa sökvägen med någon av följande metoder:

• Om Traffic Manager:s hälsoavsökningar identifierar avbrottet: Traffic Manager växlar automatiskt till den sekundära slutpunkten, så länge profilen har konfigurerats för att använda prioritetsdirigering.

• Om du använder anpassade övervakningsverktyg eller övervakningsverktyg från tredje part: Du kan skapa automatiserade svarsplaner som programmässigt konfigurerar om Traffic Manager för att inaktivera slutpunkten med någon av följande metoder:

  • Azure CLI
  • Azure PowerShell
  • Azure REST API

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

  Mer information finns i az network traffic-manager endpoint update.

• Om du identifierar avbrottet manuellt: Inaktivera slutpunkten manuellt i Traffic Manager-profilen. Detaljerade steg finns i Lägga till, inaktivera, aktivera, ta bort eller flytta slutpunkter.

Flera faktorer påverkar hur lång tid avbrottet påverkar trafiken, inklusive:

• Livstid (TTL) för dina DNS-poster.
• Vilket övervakningssystem (Traffic Manager eller din egen anpassade övervakning) identifierar först avbrottet.
• Hur ofta du kör hälsokontroller.
• Hur många misslyckade hälsokontroller måste returneras innan trafiken omdirigeras.
• Hur länge klienter och överordnade DNS-servrar cachelagrar Traffic Manager DNS-svar för.

Du måste också avgöra vilka av dessa faktorer som ligger inom din kontroll och om överordnade tjänster utanför din kontroll kan påverka användarupplevelsen. Även om du till exempel använder låg TTL på dina DNS-poster kan överordnade DNS-cacheminnen fortfarande hantera inaktuella svar längre än de borde. Det här beteendet kan förvärra effekterna av ett avbrott eller få det att verka som om ditt program inte är tillgängligt, även om Traffic Manager redan har bytt till att skicka begäranden till den alternativa trafikvägen.

Se: Verksamhetskritiskt designområde: Hälsomodellering

Distribution med noll stilleståndstid

När du planerar att använda en lösning med redundant ingresssökväg bör du också planera för hur du distribuerar eller konfigurerar dina tjänster när de degraderas. För de flesta Azure-tjänster gäller serviceavtal för drifttiden för själva tjänsten och inte för hanteringsåtgärder eller distributioner. Fundera på om dina distributions- och konfigurationsprocesser måste göras motståndskraftiga mot avbrott i tjänsten.

Du bör också överväga antalet oberoende kontrollplan som du behöver interagera med för att hantera din lösning. När du använder Azure-tjänster tillhandahåller Azure Resource Manager ett enhetligt och konsekvent kontrollplan. Men om du använder en tjänst från tredje part för att dirigera trafik kan du behöva använda ett separat kontrollplan för att konfigurera tjänsten, vilket ger ytterligare driftskomplexitet.

Se även: Verksamhetskritiskt designområde: Avbrottsfri distribution

Kontinuerlig validering

För en verksamhetskritisk lösning måste dina testmetoder verifiera att din lösning uppfyller dina krav oavsett vilken väg programtrafiken flödar genom. Överväg varje del av lösningen och hur du testar den för varje typ av avbrott.

Se till att testprocesserna innehåller följande element:

• Kan du kontrollera att trafiken omdirigeras korrekt via den alternativa sökvägen när den primära sökvägen inte är tillgänglig?
• Kan båda vägarna stödja den nivå av produktionstrafik som du förväntar dig?
• Är båda sökvägarna tillräckligt säkra för att undvika att öppna eller exponera sårbarheter när du är i ett degraderat tillstånd?

Se: Verksamhetskritiskt designområde: Kontinuerlig validering

Vanliga scenarier

Här är vanliga scenarier där den här designen kan användas:

• Global innehållsleverans gäller ofta för statisk innehållsleverans, media och storskaliga e-handelsprogram. I det här scenariot är cachelagring en viktig del av lösningsarkitekturen, och cachefel kan leda till avsevärt försämrad prestanda eller tillförlitlighet.

• Global HTTP-ingress gäller ofta för verksamhetskritiska dynamiska program och API:er. I det här scenariot är det grundläggande kravet att dirigera trafik till ursprungsservern på ett tillförlitligt och effektivt sätt. Ofta är en WAF en viktig säkerhetskontroll som används i dessa lösningar.

Bidragsgivare

Den här artikeln underhålls av Microsoft. Texten skrevs ursprungligen av följande bidragsgivare.

Huvudsakliga författare:

• Dave Burkhardt - Sverige | Huvudansvarig programchef, Azure Front Door
• John Downs | Principal Software Engineer, Azure Patterns &Practices
• Priyanka Wilkins | Huvudinnehållsutvecklare, Azure-mönster och metoder

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

I nästa artiklar i den här serien finns specifik vägledning om dessa scenarier:

Relaterade resurser

• Metodtips för arkitektur för Azure Front Door
• Metodtips för arkitektur för Azure Traffic Manager