Delen via

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, gaat 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 architectuur voor een bedrijfskritieke toepassing wordt Azure Front Door gekozen vanwege de SLA (High Uptime Service Level Agreement) en een uitgebreide functieset:

  • Verkeer routeren naar meerdere regio's, in een actief-actief- of actief-passiefmodel
  • 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

Zie Uw webtoepassing versnellen en beveiligen met Azure Front Door voor meer informatie over de mogelijkheden van Azure Front Door.

Azure Front Door is ontworpen om de grootste tolerantie en beschikbaarheid te bieden voor niet alleen onze externe klanten, maar ook voor meerdere eigenschappen in Microsoft. De mogelijkheden van Azure Front Door zijn meer dan voldoende om te voldoen aan de meeste bedrijfsvereisten, maar met elk gedistribueerd systeem verwacht u fouten. Geen onderdeel of systeem is onfeilbaar. Microsoft biedt een toonaangevende SLA (Service Level Agreement) voor Azure Front Door. Zelfs als een provider een SLA met 100% uptime biedt, garandeert dat geen volledige afwezigheid van downtime. SLA's bieden doorgaans servicetegoeden in het geval van een storing.

Als de bedrijfsvereisten een hogere samengestelde SLO of nul downtime in geval van een storing eisen, moet u vertrouwen op meerdere alternatieve paden voor inkomend verkeer. Veel grote organisaties en hoogwaardige webeigenschappen gebruiken deze aanpak om de hoogst mogelijke beschikbaarheid te garanderen en de prestaties van de levering te optimaliseren. Het nastreven van een hogere SLO brengt echter aanzienlijke kosten, operationele overhead met zich mee en kan onbedoeld 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.

Een benadering is het definiëren van een secundair pad, met alternatieve service(s), wat het primaire pad wordt wanneer Azure Front Door niet beschikbaar is. Functiepariteit met Azure 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.

Er bestaan meerdere strategieën voor het bereiken van hoge beschikbaarheid in webworkloads. De aanpak die hier wordt beschreven, biedt een eenvoudige, handmatige 'break glass-oplossing' waarmee u snel een failover kunt uitvoeren tijdens een storing en naadloos verkeer kunt herstellen naar Azure Front Door zodra de servicestatus is bevestigd.

In dit artikel worden enkele strategieën beschreven voor wereldwijde routering met behulp van Azure Traffic Manager om verkeer naar een alternatieve router te leiden in situaties waarin Azure Front Door niet beschikbaar is.

Methode

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

Diagram waarin Traffic Manager aanvragen omleidt naar Azure Front Door of naar een andere service en vervolgens naar de oorspronkelijke server.

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. Voor een bedrijfskritieke architectuur raden we u aan de gewogen routeringsmethode te gebruiken, die eenvoudig kan worden geconfigureerd om een deel van uw verkeer naar verschillende eindpunten te verzenden. Normaal gesproken worden in normale bewerkingen 100% van uw verkeer omgeleid via Azure Front Door.

    U wordt aangeraden de eindpuntbewaking van Traffic Manager uit te schakelen. U moet procedures hebben om te detecteren wanneer uw primaire verkeerspad niet beschikbaar is en om te reageren door te schakelen tussen verkeer om het secundaire pad te gebruiken.

    U kunt ook overwegen een ander globaal verkeersrouteringssysteem te gebruiken. Traffic Manager werkt echter goed voor veel situaties.

  2. U hebt twee toegangsbeheerobjectpaden:

    • Azure Front Door biedt het primaire pad. Bij normale bewerkingen worden alle of het grootste deel van uw toepassingsverkeer verwerkt en gerouteerd.

    • Een andere router wordt gebruikt als back-up voor Azure Front Door. Verkeer stroomt 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 waar mogelijk systeemeigen Azure-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 Azure 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 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.

  • Opportuniteitskosten: Het ontwerpen en implementeren van redundante toegangswegen vereist een aanzienlijke technische investering, wat uiteindelijk ten koste gaat van de ontwikkeling 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 met een toonaangevende SLA, maar verkeerbeheer heeft extra maatregelen nodig om 100% beschikbaarheid te bieden. 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 krijgen in de mogelijkheden en functies van Azure Front Door die u gebruikt en vertrouwt als u ook een andere service gaat gebruiken. 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 geeft uit 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 geen WAF te gebruiken voor uw alternatieve toegangsbeheerpad. Deze benadering kan worden beschouwd ter ondersteuning van het betrouwbaarheidsdoel van de toepassing. Dit is echter geen goede beveiligingspraktijk en we raden dit 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.

Aanvullende overwegingen voor hoge beschikbaarheid

Wanneer u een bedrijfskritieke webarchitectuur ontwerpt, zijn er veel factoren die van invloed kunnen zijn op de beschikbaarheid en prestaties van uw toepassing. Veel van deze factoren gaan verder dan de configuratie en mogelijkheden van Azure Front Door en hebben in plaats daarvan betrekking op het algehele ecosysteem- en oplossingsontwerp.

Domeinnamen en DNS

Uw bedrijfskritieke toepassing moet aangepaste domeinnamen gebruiken om te bepalen hoe verkeer naar uw toepassing stroomt en afhankelijkheden van één provider te verminderen. Houd rekening met de volgende punten bij het plannen van uw DNS-benadering:

  • DNS-service: Het is 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.

  • DNS-resolvers: U wordt aangeraden meerdere DNS-resolvers te gebruiken om de algehele tolerantie nog verder te verhogen.

  • Apex-domeinen: U gebruikt een CNAME om uw domeinnaam te laten verwijzen naar uw Traffic Manager-domeinnaam. Met DNS-standaarden kunt u geen CNAME maken in de apex (of hoofdmap) van een domein. We raden u aan uw DNS-domein op Azure DNS te hosten en aliasrecords te gebruiken om naar uw Traffic Manager-profiel te verwijzen.

  • 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 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. Azure Front Door reageert alleen op geldig HTTP-verkeer, wat ook helpt 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 origins 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 zou een handmatig te activeren proces kunnen vereisen 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.

Gezondheidsmodellering

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 ingangspad, moet uw gezondheidsmodel weerspiegelen dat het systeem nog steeds operationeel is, maar in een verminderde status draait.

Neem deze vragen op in het ontwerp van uw gezondheidsmodel.

  • Hoe controleren de verschillende onderdelen van uw oplossing de status van downstreamonderdelen?
  • Wanneer moeten statusmonitors overwegen dat downstreamonderdelen ongezond zijn?
  • 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?

Gezondheidsmonitoring

Er zijn meerdere wereldwijde taakverdelingsoplossingen waarmee u kunt overschakelen naar een secundair platform als er een storing optreedt. Azure Traffic Manager is in de meeste gevallen geschikt.

Wanneer u Traffic Manager gebruikt met Azure Front Door, moet u uw eigen bewakingsoplossing van derden of aangepaste bewakingsoplossing hebben om te detecteren wanneer Azure Front Door niet beschikbaar is en uw reactieprocessen te initiëren. Omdat Azure Front Door een wereldwijd gedistribueerd systeem is dat gebruikmaakt van anycast-netwerken, is het belangrijk om connectiviteitscontroles uit te voeren vanuit dezelfde geografische regio's als uw clients.

Belangrijk

Voor globale workloads waarvoor statusvalidatie van meerdere geografische gebieden is vereist, raden we u aan om Traffic Manager-eindpuntbewaking uit te schakelen en in plaats daarvan handmatige failoverprocedures te gebruiken.

U moet ook voorbereid zijn om uw reactieprocedures handmatig te activeren als uw bewakingssystemen deze niet detecteren.

Antwoordprocedures

Als uw bewakingssystemen detecteren dat Azure Front Door niet beschikbaar is, moet u Traffic Manager opnieuw configureren om al uw verkeer via uw alternatieve pad te leiden met behulp van een van deze methoden:

Belangrijk

Het omleiden van al het verkeer via het secundaire pad is een kortetermijnoplossing die bedrijfscontinuïteit mogelijk maakt tijdens een voortdurende storing. Nadat de storing is opgelost, herstelt u de normale activiteiten via Azure Front Door zodra dat uitvoerbaar is.

Meerdere factoren zijn van invloed op de tijdsduur waarop de storing uw netwerkverkeer beïnvloedt, waaronder:

  • De levensduur (TTL) van uw DNS-records.
  • Welk bewakingssysteem (Traffic Manager of uw eigen aangepaste bewaking) detecteert eerst de storing.
  • Hoe vaak u statuscontroles uitvoert.
  • Hoeveel mislukte gezondheidscontroles moeten worden teruggegeven 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.

Hint

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

Raadpleeg: Missiekritiek ontwerpgebied: Gezondheidsmodellering

Tolerante herconfiguratieprocessen

Wanneer u van plan bent een oplossing te gebruiken met een redundant toegangspad, 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.

Wanneer u uw failoverstrategie plant, neemt u geen afhankelijkheid van één hulpprogramma, zoals Azure Portal, voor het geval de connectiviteit wordt onderbroken. Meer informatie over het gebruik van hulpprogramma's zoals de Azure CLI, Azure PowerShell of REST API's om eventuele herconfiguratiestappen uit te voeren, zoals het opnieuw omleiden van uw verkeer. Zie Antwoordprocedures voor voorbeelden van opdrachten die u kunt opnemen in failoverscripts.

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: Missiekritiek ontwerpgebied: Implementatie zonder downtime

Voortdurende 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? Is het secundaire pad gereed om productieverkeer te ontvangen met minimale of geen waarschuwing?
  • Zijn beide paden adequaat beveiligd om te voorkomen dat kwetsbaarheden worden blootgesteld of geopend wanneer u zich in een verzwakte toestand bevindt?

Raadpleeg: Missiekritiek ontwerpgebied: Voortdurende 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 multi-ingangsoplossing, kunt u de beschikbaarheid juist verslechteren. 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.

Bijdragers

Dit artikel wordt onderhouden door Microsoft. Het is oorspronkelijk geschreven door de volgende inzenders.

Hoofdauteurs:

  • Dave Burkhardt | Hoofd programmamanager, Azure Front Door
  • John Downs | Principal Software Engineer, Azure Patterns & Practices
  • Akhil Karmalkar | Principal Program Manager, Azure Front Door
  • Priyanka Wilkins | Principal Content Developer, Azure Patterns & Practices

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

Bekijk de volgende artikelen in deze reeks voor specifieke richtlijnen over deze scenario's:

Missiekritieke wereldwijde HTTP-ingang

Bedrijfskritieke wereldwijde contentlevering

  • Last updated on