Globale routeringredundantie voor bedrijfskritieke webtoepassingen

Belangrijk

Het ontwerpen van redundantie-implementaties die te maken hebben met wereldwijde platformstoringen voor een bedrijfskritieke architectuur kan complex en kostbaar zijn. Vanwege de mogelijke problemen die zich met dit ontwerp kunnen voordoen, moet u zorgvuldig rekening houden met de compromissen.

In de meeste gevallen hebt u de architectuur die in dit artikel wordt beschreven, niet nodig.

Bedrijfskritieke systemen streven ernaar om single points of failure te minimaliseren door redundantie en zelfherstelmogelijkheden in de oplossing zoveel mogelijk te bouwen. Elk geïntegreerd toegangspunt van het systeem kan worden beschouwd als een storingspunt. Als dit onderdeel een storing ondervindt, is het hele systeem offline voor de gebruiker. Bij het kiezen van een routeringsservice is het belangrijk om rekening te houden met de betrouwbaarheid van de service zelf.

In de basislijnarchitectuur voor een bedrijfskritieke toepassing is Azure Front Door gekozen vanwege de SLA's (High Uptime Service Level Agreements) en een uitgebreide functieset:

• Verkeer routeren naar meerdere regio's in een actief-actief model
• Transparante failover met TCP anycast
• Statische inhoud van edge-knooppunten leveren met behulp van geïntegreerde CDN's (Content Delivery Networks)
• Onbevoegde toegang blokkeren met geïntegreerde Web Application Firewall

Front Door is ontworpen om de grootst mogelijke tolerantie en beschikbaarheid te bieden voor niet alleen onze externe klanten, maar ook voor meerdere eigenschappen in Microsoft. Zie Uw webtoepassing versnellen en beveiligen met Azure Front Door voor meer informatie over de mogelijkheden van Front Door.

Front Door-mogelijkheden zijn meer dan voldoende om te voldoen aan de meeste bedrijfsvereisten, maar verwacht een gedistribueerd systeem fouten. Als voor de bedrijfsvereisten een hogere samengestelde SLO- of nultijd is vereist in het geval van een storing, moet u vertrouwen op een alternatief pad voor inkomend verkeer. Het streven naar een hogere SLO wordt echter geleverd met aanzienlijke kosten, operationele overhead en kan uw algehele betrouwbaarheid verlagen. Houd zorgvuldig rekening met de compromissen en potentiële problemen die het alternatieve pad kan introduceren in andere onderdelen die zich op het kritieke pad bevinden. Zelfs wanneer de impact van onbeschikbaarheid aanzienlijk is, kan de complexiteit opwegen tegen het voordeel.

Eén benadering is het definiëren van een secundair pad, met alternatieve service(s), die alleen actief wordt wanneer Azure Front Door niet beschikbaar is. Functiepariteit met Front Door mag niet worden behandeld als een harde vereiste. Prioriteit geven aan functies die u absoluut nodig hebt voor bedrijfscontinuïteitsdoeleinden, zelfs in een beperkte capaciteit.

Een andere benadering is het gebruik van technologie van derden voor wereldwijde routering. Voor deze aanpak is een actieve implementatie met meerdere clouds met stempels vereist die worden gehost in twee of meer cloudproviders. Hoewel Azure effectief kan worden geïntegreerd met andere cloudplatforms, wordt deze aanpak niet aanbevolen vanwege operationele complexiteit op de verschillende cloudplatforms.

In dit artikel worden enkele strategieën beschreven voor globale routering met behulp van Azure Traffic Manager als alternatieve router in situaties waarin Azure Front Door niet beschikbaar is.

Methode

In dit architectuurdiagram ziet u een algemene benadering met meerdere redundante verkeerspaden.

Met deze aanpak introduceren we verschillende onderdelen en bieden we richtlijnen die belangrijke wijzigingen aanbrengen die betrekking hebben op de levering van uw webtoepassing(en):

1. Azure Traffic Manager leidt verkeer naar Azure Front Door of naar de alternatieve service die u hebt geselecteerd.

   Azure Traffic Manager is een globale load balancer op basis van DNS. De CNAME-record van uw domein verwijst naar Traffic Manager, waarmee de bestemming wordt bepaald op basis van de manier waarop u de routeringsmethode configureert. Door prioriteitsroutering te gebruiken, wordt de verkeersstroom standaard via Azure Front Door uitgevoerd. Traffic Manager kan automatisch overschakelen naar uw alternatieve pad als Azure Front Door niet beschikbaar is.

   Belangrijk

   Deze oplossing beperkt de risico's die zijn verbonden aan Azure Front Door-storingen, maar is vatbaar voor storingen in Azure Traffic Manager als een wereldwijd storingspunt.

   U kunt ook overwegen een ander globaal verkeersrouteringssysteem te gebruiken, zoals een globale load balancer. Traffic Manager werkt echter goed voor veel situaties.

2. U hebt twee toegangsbeheerobjectpaden:

   • Azure Front Door biedt het primaire pad en de processen en routeert al uw toepassingsverkeer.

   • Een andere router wordt gebruikt als back-up voor Azure Front Door. Verkeer loopt alleen via dit secundaire pad als Front Door niet beschikbaar is.

   De specifieke service die u voor de secundaire router selecteert, is afhankelijk van veel factoren. U kunt ervoor kiezen om systeemeigen Azure-services of services van derden te gebruiken. In deze artikelen bieden we azure-systeemeigen opties om te voorkomen dat er extra operationele complexiteit aan de oplossing wordt toegevoegd. Als u services van derden gebruikt, moet u meerdere besturingsvlakken gebruiken om uw oplossing te beheren.

3. Uw oorspronkelijke toepassingsservers moeten gereed zijn om verkeer van beide services te accepteren. Bedenk hoe u verkeer naar uw oorsprong beveiligt en welke verantwoordelijkheden Front Door en andere upstream-services bieden. Zorg ervoor dat uw toepassing verkeer kan verwerken vanaf het pad dat uw verkeer doorloopt.

Compromissen

Hoewel deze risicobeperkingsstrategie ervoor kan zorgen dat de toepassing beschikbaar is tijdens platformstoringen, zijn er enkele belangrijke compromissen. U moet de potentiële voordelen tegen bekende kosten wegen en een weloverwogen beslissing nemen over de vraag of de voordelen deze kosten waard zijn.

• Financiële kosten: wanneer u meerdere redundante paden naar uw toepassing implementeert, moet u rekening houden met de kosten voor het implementeren en uitvoeren van de resources. We bieden twee voorbeeldscenario's voor verschillende use cases, die elk een ander kostenprofiel hebben.

• Operationele complexiteit: telkens wanneer u extra onderdelen aan uw oplossing toevoegt, verhoogt u uw beheeroverhead. Elke wijziging in het ene onderdeel kan van invloed zijn op andere onderdelen.

  Stel dat u besluit om de nieuwe mogelijkheden van Azure Front Door te gebruiken. U moet controleren of uw alternatieve verkeerspad ook een equivalente mogelijkheid biedt. Zo niet, dan moet u bepalen hoe u het verschil in gedrag tussen de twee verkeerspaden kunt afhandelen. In echte toepassingen kunnen deze complexiteiten hoge kosten hebben en kan dit een groot risico vormen voor de stabiliteit van uw systeem.

• Prestaties: voor dit ontwerp zijn extra CNAME-zoekopdrachten vereist tijdens de naamomzetting. In de meeste toepassingen is dit geen belangrijk probleem, maar u moet evalueren of de prestaties van uw toepassing worden beïnvloed door extra lagen in uw toegangspad te introduceren.

• Verkoopkanskosten: het ontwerpen en implementeren van redundante toegangsbeheerpaden vereist een aanzienlijke technische investering, wat uiteindelijk een verkoopkans kost voor het ontwikkelen van functies en andere platformverbeteringen.

Waarschuwing

Als u niet voorzichtig bent met het ontwerpen en implementeren van een complexe oplossing voor hoge beschikbaarheid, kunt u uw beschikbaarheid erger maken. Als u het aantal onderdelen in uw architectuur verhoogt, neemt het aantal storingspunten toe. Dit betekent ook dat u een hoger niveau van operationele complexiteit hebt. Wanneer u extra onderdelen toevoegt, moet elke wijziging die u aanbrengt zorgvuldig worden gecontroleerd om te begrijpen hoe dit van invloed is op uw algehele oplossing.

Beschikbaarheid van Azure Traffic Manager

Azure Traffic Manager is een betrouwbare service, maar de service level agreement garandeert geen beschikbaarheid van 100%. Als Traffic Manager niet beschikbaar is, hebben uw gebruikers mogelijk geen toegang tot uw toepassing, zelfs als Azure Front Door en uw alternatieve service beide beschikbaar zijn. Het is belangrijk om te plannen hoe uw oplossing onder deze omstandigheden blijft werken.

Traffic Manager retourneert dns-antwoorden die in de cache kunnen worden opgeslagen. Als time-to-live (TTL) op uw DNS-records caching toestaat, zijn korte onderbrekingen van Traffic Manager mogelijk geen probleem. Dat komt doordat downstream-DNS-resolvers mogelijk een eerder antwoord in de cache hebben opgeslagen. U moet plannen voor langdurige storingen. U kunt ervoor kiezen om uw DNS-servers handmatig opnieuw te configureren om gebruikers naar Azure Front Door te leiden als Traffic Manager niet beschikbaar is.

Consistentie van verkeersroutering

Het is belangrijk om inzicht te hebben in de mogelijkheden en functies van Azure Front Door die u gebruikt en vertrouwt. Wanneer u de alternatieve service kiest, bepaalt u de minimale mogelijkheden die u nodig hebt en laat u andere functies weg wanneer uw oplossing zich in een gedegradeerde modus bevindt.

Bij het plannen van een alternatief verkeerspad moet u rekening houden met enkele belangrijke vragen:

• Gebruikt u de cachefuncties van Azure Front Door? Als caching niet beschikbaar is, kunnen uw oorspronkelijke servers uw verkeer bijhouden?
• Gebruikt u de Azure Front Door-regelengine om aangepaste routeringslogica uit te voeren of om aanvragen opnieuw te schrijven?
• Gebruikt u de Azure Front Door Web Application Firewall (WAF) om uw toepassingen te beveiligen?
• Beperkt u verkeer op basis van IP-adres of geografie?
• Wie ondervindt en beheert uw TLS-certificaten?
• Hoe beperkt u de toegang tot uw oorspronkelijke toepassingsservers om ervoor te zorgen dat deze via Azure Front Door wordt geleverd? Gebruikt u Private Link of vertrouwt u op openbare IP-adressen met servicetags en id-headers?
• Accepteren uw toepassingsservers verkeer vanaf een andere locatie dan Azure Front Door? Als dat het gebeurt, welke protocollen accepteren ze?
• Gebruiken uw clients de HTTP/2-ondersteuning van Azure Front Door?

Web Application Firewall (WAF)

Als u WAF van Azure Front Door gebruikt om uw toepassing te beveiligen, kunt u overwegen wat er gebeurt als het verkeer niet via Azure Front Door gaat.

Als uw alternatieve pad ook een WAF biedt, kunt u de volgende vragen overwegen:

• Kan deze op dezelfde manier worden geconfigureerd als uw Azure Front Door WAF?
• Moet het onafhankelijk worden afgestemd en getest om de kans op fout-positieve detecties te verminderen?

Waarschuwing

U kunt ervoor kiezen om WAF niet te gebruiken voor uw alternatieve toegangsbeheerpad. Deze benadering kan worden beschouwd ter ondersteuning van het betrouwbaarheidsdoel van de toepassing. Dit is echter geen goede gewoonte en we raden het niet aan.

Overweeg het compromis bij het accepteren van verkeer van internet zonder controles. Als een aanvaller een onbeveiligd secundair verkeerspad naar uw toepassing detecteert, kan dit schadelijk verkeer via uw secundaire pad verzenden, zelfs wanneer het primaire pad een WAF bevat.

U kunt het beste alle paden naar uw toepassingsservers beveiligen.

Domeinnamen en DNS

Uw bedrijfskritieke toepassing moet een aangepaste domeinnaam gebruiken. U bepaalt hoe verkeer naar uw toepassing stroomt en u vermindert de afhankelijkheden van één provider.

Het is ook een goede gewoonte om een hoogwaardige en tolerante DNS-service te gebruiken voor uw domeinnaam, zoals Azure DNS. Als de DNS-servers van uw domeinnaam niet beschikbaar zijn, kunnen gebruikers uw service niet bereiken.

Het is raadzaam om meerdere DNS-resolvers te gebruiken om de algehele tolerantie nog verder te verbeteren.

CNAME-keten

Oplossingen die Traffic Manager, Azure Front Door en andere services combineren, maken gebruik van een DNS CNAME-omzettingsproces met meerdere lagen, ook wel CNAME-ketening genoemd. Wanneer u bijvoorbeeld uw eigen aangepaste domein oplost, ziet u mogelijk vijf of meer CNAME-records voordat een IP-adres wordt geretourneerd.

Het toevoegen van extra koppelingen aan een CNAME-keten kan van invloed zijn op de prestaties van DNS-naamomzetting. DNS-antwoorden worden echter meestal in de cache opgeslagen, wat de gevolgen voor de prestaties vermindert.

TLS-certificaten

Voor een bedrijfskritieke toepassing is het raadzaam om uw eigen TLS-certificaten in te richten en te gebruiken in plaats van de beheerde certificaten die worden geleverd door Azure Front Door. U vermindert het aantal potentiële problemen met deze complexe architectuur.

Hier volgen enkele voordelen:

• Als u beheerde TLS-certificaten wilt uitgeven en vernieuwen, verifieert Azure Front Door uw eigendom van het domein. Bij het verificatieproces van het domein wordt ervan uitgegaan dat de CNAME-records van uw domein rechtstreeks naar Azure Front Door verwijzen. Maar die veronderstelling is vaak niet juist. Het uitgeven en vernieuwen van beheerde TLS-certificaten in Azure Front Door werkt mogelijk niet soepel en u verhoogt het risico op storingen vanwege PROBLEMEN met TLS-certificaten.

• Zelfs als uw andere services beheerde TLS-certificaten bieden, kunnen ze mogelijk het eigendom van het domein niet verifiëren.

• Als elke service onafhankelijk van elkaar hun eigen beheerde TLS-certificaten krijgt, kunnen er problemen zijn. Gebruikers verwachten bijvoorbeeld geen verschillende TLS-certificaten te zien die zijn uitgegeven door verschillende autoriteiten of met verschillende vervaldatums of vingerafdrukken.

Er zijn echter aanvullende bewerkingen met betrekking tot het vernieuwen en bijwerken van uw certificaten voordat ze verlopen.

Oorsprongbeveiliging

Wanneer u uw oorsprong configureert om alleen verkeer te accepteren via Azure Front Door, krijgt u bescherming tegen DDoS-aanvallen van laag 3 en laag 4. Omdat Azure Front Door alleen reageert op geldig HTTP-verkeer, is het ook handig om uw blootstelling aan veel op protocollen gebaseerde bedreigingen te verminderen. Als u uw architectuur wijzigt om alternatieve toegangsbeheerpaden toe te staan, moet u evalueren of u per ongeluk de blootstelling van uw oorsprong aan bedreigingen hebt verhoogd.

Als u Private Link gebruikt om vanuit Azure Front Door verbinding te maken met uw oorspronkelijke server, hoe loopt het verkeer via uw alternatieve pad? Kunt u privé-IP-adressen gebruiken voor toegang tot uw origins of moet u openbare IP-adressen gebruiken?

Als uw oorsprong gebruikmaakt van de Azure Front Door-servicetag en de X-Azure-FDID-header om te controleren of het verkeer via Azure Front Door is gestroomd, kunt u overwegen hoe uw oorsprongen opnieuw kunnen worden geconfigureerd om te controleren of het verkeer via een van uw geldige paden is gestroomd. U moet testen of u uw oorsprong niet per ongeluk hebt geopend voor verkeer via andere paden, waaronder van azure Front Door-profielen van andere klanten.

Wanneer u uw oorsprongbeveiliging plant, controleert u of het alternatieve verkeerspad afhankelijk is van het inrichten van toegewezen openbare IP-adressen. Dit kan een handmatig geactiveerd proces nodig hebben om het back-uppad online te brengen.

Als er toegewezen openbare IP-adressen zijn, kunt u overwegen of u Azure DDoS Protection moet implementeren om het risico op Denial of Service-aanvallen tegen uw oorsprong te verminderen. Overweeg ook of u Azure Firewall of een andere firewall moet implementeren die u kan beschermen tegen verschillende netwerkbedreigingen. Mogelijk hebt u ook meer strategieën voor inbraakdetectie nodig. Deze besturingselementen kunnen belangrijke elementen zijn in een complexere architectuur met meerdere paden.

Statusmodellering

Bedrijfskritieke ontwerpmethodologie vereist een systeemstatusmodel dat u algehele waarneembaarheid van de oplossing en de bijbehorende onderdelen biedt. Wanneer u meerdere paden voor inkomend verkeer gebruikt, moet u de status van elk pad bewaken. Als uw verkeer wordt omgeleid naar het secundaire toegangspad, moet uw statusmodel overeenkomen met het feit dat het systeem nog steeds operationeel is, maar dat het wordt uitgevoerd in een gedegradeerde status.

Neem deze vragen op in het ontwerp van uw statusmodel:

• Hoe controleren de verschillende onderdelen van uw oplossing de status van downstreamonderdelen?
• Wanneer moeten statusmonitors overwegen om downstreamonderdelen niet in orde te maken?
• Hoe lang duurt het voordat een storing is gedetecteerd?
• Hoe lang duurt het voordat verkeer wordt gerouteerd via een alternatief pad nadat er een storing is gedetecteerd?

Er zijn meerdere wereldwijde taakverdelingsoplossingen waarmee u de status van Azure Front Door kunt bewaken en een automatische failover naar een back-upplatform kunt activeren als er een storing optreedt. Azure Traffic Manager is in de meeste gevallen geschikt. Met Traffic Manager configureert u eindpuntbewaking om downstreamservices te bewaken door op te geven welke URL moet worden gecontroleerd, hoe vaak die URL moet worden gecontroleerd en wanneer de downstreamservice beschadigd moet worden gezien op basis van testreacties. Over het algemeen, hoe korter het interval tussen controles, hoe minder tijd het duurt voor Traffic Manager om verkeer door te leiden via een alternatief pad om uw oorspronkelijke server te bereiken.

Als Front Door niet beschikbaar is, hebben meerdere factoren invloed op de hoeveelheid tijd die de storing op uw verkeer heeft, waaronder:

• De time to live (TTL) op uw DNS-records.
• Hoe vaak Traffic Manager de statuscontroles uitvoert.
• Hoeveel mislukte tests Traffic Manager is geconfigureerd om te zien voordat het verkeer wordt omgeleid.
• Hoe lang clients en upstream DNS-servers de DNS-antwoorden van Traffic Manager opslaan.

U moet ook bepalen welke van deze factoren binnen uw beheer vallen en of upstream-services die buiten uw beheer vallen, invloed kunnen hebben op de gebruikerservaring. Zelfs als u een lage TTL op uw DNS-records gebruikt, kunnen upstream-DNS-caches nog steeds verouderde antwoorden leveren die langer duren dan nodig is. Dit gedrag kan de gevolgen van een storing verergeren of ervoor zorgen dat uw toepassing niet beschikbaar is, zelfs als Traffic Manager al is overgeschakeld naar het verzenden van aanvragen naar het alternatieve verkeerspad.

Tip

Bedrijfskritieke oplossingen vereisen waar mogelijk geautomatiseerde failover-benaderingen. Handmatige failoverprocessen worden als traag beschouwd om ervoor te zorgen dat de toepassing responsief blijft.

Raadpleeg: Bedrijfskritiek ontwerpgebied: Statusmodellering

Implementatie zonder downtime

Wanneer u van plan bent om een oplossing te gebruiken met redundant toegangsbeheerpad, moet u ook plannen hoe u uw services implementeert of configureert wanneer deze worden gedegradeerd. Voor de meeste Azure-services zijn SLA's van toepassing op de uptime van de service zelf en niet op beheerbewerkingen of implementaties. Overweeg of uw implementatie- en configuratieprocessen tolerant moeten worden gemaakt voor servicestoringen.

U moet ook rekening houden met het aantal onafhankelijke besturingsvlakken waarmee u moet communiceren om uw oplossing te beheren. Wanneer u Azure-services gebruikt, biedt Azure Resource Manager een geïntegreerd en consistent besturingsvlak. Als u echter een service van derden gebruikt om verkeer te routeren, moet u mogelijk een afzonderlijk besturingsvlak gebruiken om de service te configureren, wat verdere operationele complexiteit introduceert.

Waarschuwing

Het gebruik van meerdere besturingsvlakken introduceert complexiteit en risico voor uw oplossing. Elk verschil verhoogt de kans dat iemand per ongeluk een configuratie-instelling mist of verschillende configuraties toepast op redundante onderdelen. Zorg ervoor dat uw operationele procedures dit risico beperken.

Raadpleeg: Bedrijfskritiek ontwerpgebied: Implementatie zonder downtime

Continue validatie

Voor een bedrijfskritieke oplossing moeten uw testprocedures controleren of uw oplossing voldoet aan uw vereisten, ongeacht het pad dat uw toepassingsverkeer doorloopt. Houd rekening met elk deel van de oplossing en hoe u deze test voor elk type storing.

Zorg ervoor dat uw testprocessen de volgende elementen bevatten:

• Kunt u controleren of verkeer correct wordt omgeleid via het alternatieve pad wanneer het primaire pad niet beschikbaar is?
• Kunnen beide paden het productieverkeer ondersteunen dat u verwacht te ontvangen?
• Zijn beide paden adequaat beveiligd, om te voorkomen dat beveiligingsproblemen worden geopend of weergegeven wanneer u een gedegradeerde status hebt?

Raadpleeg: Bedrijfskritiek ontwerpgebied: Continue validatie

Algemene scenario's

Hier volgen veelvoorkomende scenario's waarin dit ontwerp kan worden gebruikt:

• Wereldwijde contentlevering is doorgaans van toepassing op statische contentlevering , media en grootschalige eCommerce-toepassingen. In dit scenario is caching een essentieel onderdeel van de oplossingsarchitectuur en fouten in de cache kunnen leiden tot aanzienlijk verslechterde prestaties of betrouwbaarheid.

• Globale HTTP-inkomend verkeer is doorgaans van toepassing op bedrijfskritieke dynamische toepassingen en API's. In dit scenario is de kernvereiste het routeren van verkeer naar de oorspronkelijke server betrouwbaar en efficiënt. Vaak is een WAF een belangrijk beveiligingsbeheer dat in deze oplossingen wordt gebruikt.

Waarschuwing

Als u niet voorzichtig bent met het ontwerpen en implementeren van een complexe oplossing voor inkomend verkeer, kunt u uw beschikbaarheid erger maken. Als u het aantal onderdelen in uw architectuur verhoogt, neemt het aantal storingspunten toe. Dit betekent ook dat u een hoger niveau van operationele complexiteit hebt. Wanneer u extra onderdelen toevoegt, moet elke wijziging die u aanbrengt zorgvuldig worden gecontroleerd om te begrijpen hoe dit van invloed is op uw algehele oplossing.

Volgende stappen

Bekijk de globale HTTP-scenario's voor inkomend verkeer en globale contentlevering om te begrijpen of deze van toepassing zijn op uw oplossing.