Design för haveriberedskap

  • Artikel

Virtual WAN kan du aggregera, ansluta, centralt hantera och skydda alla dina globala distributioner. Dina globala distributioner kan innehålla alla kombinationer av olika grenar, PoP (Point-of-Presence), privata användare, kontor, virtuella Azure-nätverk och andra distributioner med flera moln. Du kan använda SD-WAN, plats-till-plats-VPN, punkt-till-plats-VPN och ExpressRoute för att ansluta dina olika platser till en virtuell hubb. Om du har flera virtuella hubbar skulle alla hubbar anslutas i fullständigt nät i en standarddistribution Virtual WAN.

I den här artikeln ska vi titta på hur du skapar olika typer av anslutningsalternativ för nätverk som en tjänst som Virtual WAN stöder för haveriberedskap.

Anslutningsalternativ för nätverk som en tjänst för Virtual WAN

Virtual WAN stöder följande alternativ för serverdelsanslutning:

  • Fjärranvändaranslutning
  • Branch/Office/SD-WAN/Plats-till-plats-VPN
  • Privat anslutning (privat ExpressRoute-peering)

För vart och ett av dessa anslutningsalternativ distribuerar Virtual WAN en separat uppsättning gatewayinstanser i en virtuell hubb.

I sig är Virtual WAN utformat för att erbjuda nätverksaggregeringslösning i carrier-klass. För hög tillgänglighet instansierar Virtual WAN flera instanser när var och en av dessa olika typer av gatewayer distribueras med i en Virtual WAN hubb. Mer information om hög ExpressRoute-tillgänglighet finns i Designa för hög tillgänglighet med ExpressRoute.

Med punkt-till-plats-VPN-gatewayen är det minsta antalet distribuerade instanser två. Med punkt-till-plats-VPN-gatewayen väljer du den aggregerade dataflödeskapaciteten för punkt-till-plats-gatewayer och flera instanser etableras automatiskt åt dig. Du väljer den aggregerade kapaciteten baserat på antalet klienter eller användare som du tänker ansluta till den virtuella hubben. Från klientanslutningsperspektivet döljs punkt-till-plats-VPN-gatewayinstanserna bakom gatewayens fullständigt kvalificerade domännamn (FQDN).

För VPN-gatewayen för plats-till-plats distribueras två instanser av gatewayen i en virtuell hubb. Varje gatewayinstans distribueras med en egen uppsättning offentliga och privata IP-adresser. Följande skärmbild visar de IP-adresser som är associerade med de två instanserna av en exempelkonfiguration av VPN-gatewayen för plats-till-plats. Med andra ord tillhandahåller de två instanserna två oberoende tunnelslutpunkter för att upprätta PLATS-till-plats-VPN-anslutning från dina grenar. Information om hur du maximerar hög tillgänglighet finns i Val av Azure-sökväg mellan flera ISP-länkar.

Skärmbild som visar ett exempel på en V P N-gatewaykonfiguration för plats-till-plats.

Att maximera hög tillgänglighet för din nätverksarkitektur är ett viktigt första steg för affärskontinuitet och haveriberedskap (BCDR). I resten av den här artikeln, som vi nämnde tidigare, ska vi gå längre än hög tillgänglighet och diskutera hur du skapar ditt Virtual WAN anslutningsnätverk för BCDR.

Behov av haveriberedskapsdesign

Katastrofen kan inträffa när som helst, var som helst. En katastrof kan inträffa i en molnleverantörs regioner eller nätverk, i ett tjänstleverantörsnätverk eller i ett lokalt nätverk. Regionala effekter av en moln- eller nätverkstjänst på grund av vissa faktorer som naturlig katastrof, mänskliga fel, krig, terrorism, felkonfiguration är svåra att utesluta. Så för kontinuiteten i dina affärskritiska program måste du ha en design för haveriberedskap. För en omfattande haveriberedskapsdesign måste du identifiera alla beroenden som eventuellt kan misslyckas i din kommunikationsväg från slutpunkt till slutpunkt och skapa redundans som inte överlappar varandra för vart och ett av beroendena.

Oavsett om du kör verksamhetskritiska program i en Azure-region, lokalt eller någon annanstans, kan du använda en annan Azure-region som redundanswebbplats. Följande artiklar beskriver haveriberedskap från program och klientdelsåtkomstperspektiv:

Utmaningar med att använda redundant anslutning

När du ansluter samma uppsättning nätverk med fler än en anslutning introducerar du parallella sökvägar mellan nätverken. Parallella sökvägar, när de inte är korrekt konstruerade, kan leda till asymmetrisk routning. Om du har tillståndskänsliga entiteter (till exempel NAT, brandvägg) i sökvägen kan asymmetrisk routning blockera trafikflödet. Vanligtvis kommer du inte att ha eller stöta på tillståndskänsliga entiteter som NAT eller brandväggar över privata anslutningar. Därför blockerar inte asymmetrisk routning över privat anslutning nödvändigtvis trafikflödet.

Men om du belastningsutjämning trafik över geo-redundant parallella sökvägar, skulle du uppleva inkonsekventa nätverksprestanda på grund av skillnaden i fysiska sökvägen för parallella anslutningar. Därför måste vi överväga prestanda för nätverkstrafik både under stabilt tillstånd (icke-feltillstånd) och ett feltillstånd som en del av vår haveriberedskapsdesign.

Åtkomst till nätverksredundans

De flesta SD-WAN-tjänster (hanterade lösningar eller på annat sätt) ger dig nätverksanslutning via flera transporttyper (till exempel Internetbredband, MPLS, LTE). För att skydda mot transportnätverksfel väljer du anslutning framför fler än ett transportnät. I ett scenario med hemanvändare kan du överväga att använda mobilt nätverk som en reserv för bredbandsanslutning.

Om det inte går att ansluta via en annan transporttyp väljer du nätverksanslutning via fler än en tjänstleverantör. Om du får anslutning via fler än en tjänstleverantör ser du till att tjänstleverantörerna underhåller icke-överlappande oberoende åtkomstnätverk.

Överväganden för fjärranvändares anslutning

Fjärranvändaranslutning upprättas med punkt-till-plats-VPN mellan en slutenhet till ett nätverk. Efter ett nätverksfel skulle slutenheten släppa och försöka estabilisha VPN-tunneln igen. För punkt-till-plats-VPN bör därför din design för haveriberedskap sträva efter att minimera återställningstiden efter ett fel. Följande nätverksredundans skulle bidra till att minimera återställningstiden. Beroende på hur kritiska anslutningarna är kan du välja några eller alla av dessa alternativ.

  • Åtkomst till nätverksredundans (beskrivs ovan).
  • Hantera redundant virtuell hubb för punkt-till-plats-VPN-avslutning. När du har flera virtuella hubbar med punkt-till-plats-gatewayer tillhandahåller VWAN en global profil som visar alla punkt-till-plats-slutpunkter. Med den globala profilen kan dina slutenheter ansluta till den närmast tillgängliga virtuella hubben som erbjuder bästa nätverksprestanda. Om alla dina Azure-distributioner finns i en enda region och de slutenheter som ansluter ligger nära regionen kan du ha redundanta virtuella hubbar i regionen. Om distributionen och slutenheterna är spridda över flera regioner kan du distribuera en virtuell hubb med punkt-till-plats-gateway i var och en av dina valda regioner. Virtual WAN har en inbyggd trafikhanterare som väljer den bästa hubben för fjärranvändaranslutning automatiskt.

Följande diagram visar begreppet hantera redundant virtuell hubb med respektive punkt-till-plats-gateway inom en region.

Diagram över punkt-till-plats-aggregering med flera hubbar.

I diagrammet ovan visar de helgröna linjerna de primära PUNKT-till-plats-VPN-anslutningarna och de streckade gula linjerna visar reservanslutningarna som står bredvid. Den globala VWAN-profilen för punkt-till-plats väljer primära anslutningar och säkerhetskopieringsanslutningar baserat på nätverkets prestanda. Mer information om global profil finns i Ladda ned en global profil för VPN-användarklienter .

Överväganden för plats-till-plats-VPN

Låt oss ta en titt på den exempelanslutning för plats-till-plats-VPN som visas i följande diagram för vår diskussion. Information om hur du upprättar en VPN-anslutning från plats till plats med aktiva-aktiva tunnlar med hög tillgänglighet finns i Självstudie: Skapa en plats-till-plats-anslutning med Azure Virtual WAN.

Diagram över hur du ansluter en lokal gren till virtuellt wan via plats-till-plats V P N.

Anteckning

För att få en enkel förståelse för de begrepp som beskrivs i avsnittet upprepar vi inte diskussionen om funktionen för hög tillgänglighet i VPN-gatewayen för plats-till-plats som gör att du kan skapa två tunnlar till två olika slutpunkter för varje VPN-länk som du konfigurerar. När du distribuerar någon av de föreslagna arkitekturerna i avsnittet bör du dock komma ihåg att konfigurera två tunnlar för var och en av de länkar som du upprättar.

För att skydda mot fel i VPN Customer Premises Equipment (CPE) på en grenplats kan du konfigurera parallella VPN-länkar till en VPN-gateway från parallella CPE-enheter på grenplatsen. För att skydda mot nätverksfel hos en sista mil-tjänstleverantör till avdelningskontoret kan du konfigurera olika VPN-länkar över olika tjänstleverantörsnätverk. Följande diagram visar flera VPN-länkar som kommer från två olika processorer på en grenplats som avslutas på samma VPN-gateway.

Diagram över redundanta V P N-anslutningar från plats till plats till en grenplats.

Du kan konfigurera upp till fyra länkar till en grenplats från en VIRTUELL HUB VPN-gateway. När du konfigurerar en länk till en grenplats kan du identifiera tjänstleverantören och dataflödeshastigheten som är associerad med länken. När du konfigurerar parallella länkar mellan en grenplats och en virtuell hubb skulle VPN-gatewayen som standard belastningsutjäxla trafik över de parallella länkarna. Belastningsutjämningen av trafiken skulle ske enligt Equal-Cost ECMP (Multi-Path) per flöde.

Topologi med flera länkar skyddar mot CPE-enhetsfel och ett nätverksfel för tjänstleverantören på den lokala grenplatsen. För att skydda mot avbrott i en VPN-gateway för virtuell hubb skulle dessutom multi-hubbtopologi med flera länkar vara till hjälp. Följande diagram visar topologin, där flera virtuella hubbar konfigureras under en Virtual WAN-instans i en region:

Diagram över plats-till-plats-V P N-anslutningar med flera hubbar till en grenplats.

Eftersom svarstiden mellan hubbarna mellan hubbarna är obetydlig i topologin ovan kan du använda alla PLATS-till-plats-VPN-anslutningar mellan den lokala miljön och de två virtuella hubbarna i aktivt-aktivt tillstånd genom att sprida ut de virtuella ekernätverken över hubbarna. I topologin går trafik mellan lokalt och ett virtuellt ekernätverk som standard direkt genom den virtuella hubb som det virtuella ekernätverket är anslutet till under stabilt tillstånd och använder en annan virtuell hubb som en säkerhetskopia endast under ett feltillstånd. Trafiken skulle passera genom den direktanslutna hubben i stabilt tillstånd, eftersom BGP-vägarna som annonseras av den direktanslutna hubben skulle ha kortare AS-sökväg jämfört med säkerhetskopieringshubben.

Topologin för flera hubbar skulle skydda och ge affärskontinuitet mot de flesta felscenarier. Men om ett oåterkalleligt fel tar bort hela Azure-regionen behöver du "topologi med flera regioner med flera länkar" för att klara felet.

Topologi med flera länkar i flera regioner skyddar mot även oåterkalleliga fel i en hel region, förutom de skydd som erbjuds av multilänktopologin med flera hubbar som vi tidigare diskuterat. Följande diagram visar topologin för flera regioner med flera länkar. De virtuella hubbarna i en annan region kan konfigureras under samma Virtual WAN instans.

Diagram över plats-till-plats-V P N-anslutningar för flera regioner till en grenplats.

Ur en trafiktekniska synvinkel måste du ta hänsyn till en betydande skillnad mellan att ha redundanta hubbar i en region jämfört med att ha säkerhetskopieringshubben i en annan region. Skillnaden är svarstiden som uppstår från det fysiska avståndet mellan de primära och sekundära regionerna. Därför kanske du vill distribuera dina steady-state-tjänstresurser i den region som är närmast dina gren-/slutanvändare och använda fjärrregionen enbart för säkerhetskopiering.

Om dina lokala grenplatser är spridda över två eller flera Azure-regioner skulle topologin för flera regioner med flera länkar vara effektivare för att sprida belastningen och få bättre nätverksupplevelse under det stadiga tillståndet. Följande diagram visar topologi för flera regioner med flera länkar med grenar i olika regioner. I ett sådant scenario skulle topologin dessutom ge effektiv haveriberedskap för affärskontinuitet (BCDR).

Diagram över plats-till-plats-V P N-anslutningar mellan flera regioner till flera grenplatser.

Överväganden för ExpressRoute

Överväganden för haveriberedskap för privat ExpressRoute-peering beskrivs i Designa för haveriberedskap med privat ExpressRoute-peering. Enligt beskrivningen i artikeln gäller de begrepp som beskrivs i den artikeln på samma sätt för ExpressRoute-gatewayer som skapats i en virtuell hubb. Att använda en redundant virtuell hubb i regionen, som du ser i följande diagram, är den enda topologiförbättring som rekommenderas för små till medelstora lokala nätverksöverväganden.

Diagram över Expresss Route-anslutning med flera hubbar.

I diagrammet ovan avslutas ExpressRoute 2 på en separat ExpressRoute-gateway inom en andra virtuell hubb i regionen.

Nästa steg

I den här artikeln har vi diskuterat Virtual WAN haveriberedskapsdesign. Följande artiklar beskriver haveriberedskap från program och klientdelsåtkomstperspektiv:

Information om hur du skapar en punkt-till-plats-anslutning till Virtual WAN finns i Självstudie: Skapa en VPN-anslutning för användare med Azure Virtual WAN. Information om hur du skapar en plats-till-plats-anslutning till Virtual WAN finns i Självstudie: Skapa en plats-till-plats-anslutning med Azure Virtual WAN. Information om hur du associerar en ExpressRoute-krets med Virtual WAN finns i Självstudie: Skapa en ExpressRoute-association med Hjälp av Azure Virtual WAN.