Global routningsredundans för verksamhetskritiska webbprogram

Viktigt!

Att utforma redundansimplementeringar som hanterar globala plattformsfel för en verksamhetskritisk arkitektur kan vara komplext och kostsamt. På grund av de potentiella problem som kan uppstå med den här designen bör du noga överväga kompromisserna.

I de flesta fall behöver du inte arkitekturen som beskrivs i den här artikeln.

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 får ett avbrott kommer hela systemet att vara offline till 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 baslinjearkitekturen för ett verksamhetskritiskt program valdes Azure Front Door på grund av dess serviceavtal på hög drifttid (SLA) och en omfattande funktionsuppsättning:

• Dirigera trafik till flera regioner i en aktiv-aktiv modell
• Transparent redundans 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

Front Door är utformat för att ge största möjliga återhämtning och tillgänglighet för inte bara våra externa kunder, utan även för flera egenskaper i Microsoft. Mer information om Front Door-funktioner finns i Accelerera och skydda din webbapp med Azure Front Door.

Front Door-funktioner är mer än tillräckligt för att uppfylla de flesta affärskrav, men med ett distribuerat system kan du förvänta dig fel. Om affärskraven kräver en högre sammansatt SLO eller noll nertid vid ett avbrott måste du förlita dig på en alternativ väg för trafik ingress. 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 sökvägen kan medföra i andra komponenter som är på den kritiska vägen. Ä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 Front Door bör inte behandlas som ett hårt krav. Prioritera funktioner som du absolut behöver för affärskontinuitetsändamål, även potentiellt körs i en begränsad kapacitet.

En annan metod är att använda teknik från tredje part för global routning. Den här metoden kräver en aktiv-aktiv distribution med flera moln med stämplar som hanteras av två eller flera molnleverantörer. Även om Azure effektivt kan integreras med andra molnplattformar rekommenderas inte den här metoden på grund av driftskomplexitet på de olika molnplattformarna.

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.

Metod

Det här arkitekturdiagrammet visar en allmän metod med flera redundanta trafiksökvä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. Om du använder prioritetsroutning kommer trafik att flöda via Azure Front Door som standard. Traffic Manager kan automatiskt växla trafik till den alternativa sökvägen om Azure Front Door inte är tillgängligt.

   Viktigt!

   Den här lösningen minskar riskerna i samband med avbrott i Azure Front Door, men den är känslig för avbrott i Azure Traffic Manager som en global felpunkt.

   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 den här sekundära sökvägen 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 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. Fundera på hur du skyddar trafiken till ditt ursprung och vilka ansvarsområden 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 de nya funktionerna 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: Utformning och implementering av 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.

Varning

Om du inte är försiktig med hur du utformar och implementerar en komplex lösning med hög tillgänglighet kan du faktiskt göra din tillgänglighet sämre. Om du ökar antalet komponenter i arkitekturen ökar antalet felpunkter. Det innebär också att du har en högre nivå av driftskomplexitet. När du lägger till extra komponenter måste varje ändring du gör granskas noggrant för att förstå hur den påverkar din övergripande lösning.

Tillgänglighet för Azure Traffic Manager

Azure Traffic Manager är en tillförlitlig tjänst, men serviceavtalet garanterar inte 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.

Konsekvens för trafikroutning

Det är viktigt att förstå funktionerna och funktionerna i Azure Front Door som du använder och förlitar dig på. 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 Brandväggen för Azure Front Door-webbprogram (WAF) för att skydda dina program?
• 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?

Varning

Du kan välja att inte använda WAF för din alternativa ingresssökväg. Den här metoden kan övervägas för att stödja programmets tillförlitlighetsmål. Detta är dock inte en bra idé och vi rekommenderar det inte.

Ö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.

Domännamn och DNS

Ditt verksamhetskritiska program bör använda ett anpassat domännamn. Du får kontroll över hur trafiken flödar till ditt program och du minskar beroendena för 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-matchare 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 kommer att minska 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 kommer dock att finnas 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. Eftersom Azure Front Door endast svarar på giltig HTTP-trafik hjälper det också 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 ursprungssäkerheten kontrollerar du om den alternativa trafiksökvägen är beroende av etablering av dedikerade offentliga IP-adresser. Detta kan behöva en manuellt utlöst process för att aktivera säkerhetskopieringssökvä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 ingresssökvägen bör hälsomodellen återspegla det faktum att systemet fortfarande fungerar men att det körs i ett degraderat 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?

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. Med 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 du ska tänka på att nedströmstjänsten inte är 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.

Om Front Door inte är tillgängligt påverkar flera faktorer hur lång tid avbrottet påverkar trafiken, inklusive:

• Tid att leva (TTL) på dina DNS-poster.
• Hur ofta Traffic Manager kör sina hälsokontroller.
• Hur många misslyckade avsökningar Traffic Manager har konfigurerats för att se 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.

Dricks

Verksamhetskritiska lösningar kräver automatiserade redundansmetoder där det är möjligt. Manuella redundansprocesser anses vara långsamma för att programmet ska förbli dynamiskt.

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.

Varning

Användningen av flera kontrollplan medför komplexitet och risk för din lösning. Varje skillnad ökar sannolikheten för att någon av misstag missar en konfigurationsinställning eller tillämpar olika konfigurationer på redundanta komponenter. Se till att dina operativa procedurer minskar den här risken.

Se: Verksamhetskritiskt designområde: Distribution med noll stilleståndstid

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 sökvägarna stödja den produktionstrafiknivå som du förväntar dig att få?
• Ä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.

Varning

Om du inte är försiktig med hur du utformar och implementerar en komplex lösning med flera ingresser kan du faktiskt göra din tillgänglighet sämre. Om du ökar antalet komponenter i arkitekturen ökar antalet felpunkter. Det innebär också att du har en högre nivå av driftskomplexitet. När du lägger till extra komponenter måste varje ändring du gör granskas noggrant för att förstå hur den påverkar din övergripande lösning.

Nästa steg

Granska scenarierna för global HTTP-ingress och global innehållsleverans för att förstå om de gäller för din lösning.