Dela via

Design för haveriberedskap

  • Artikel

Med Virtual WAN kan du aggregera, ansluta, centralt hantera och skydda alla dina globala distributioner. Dina globala distributioner kan omfatta alla kombinationer av olika grenar, PoP (Point-of-Presence), privata användare, kontor, virtuella Azure-nätverk och andra distributioner i 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 vara anslutna i fullständigt nät i en virtuell WAN-standarddistribution.

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 Network-as-a-service för Virtual WAN

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

  • Fjärranvändaranslutning
  • Branch/Office/SD-WAN/Site-to-site VPN
  • Privat anslutning (privat ExpressRoute-peering)

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

Virtual WAN är till sin natur utformat för att erbjuda nätverksaggregeringslösning med hög tillgänglighet i transportföretagsklass. 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 tillgänglighet för ExpressRoute 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 enligt antalet klienter eller användare som du tänker ansluta till den virtuella hubben. Från klientanslutningsperspektivet döljs vpn-gatewayinstanserna för punkt-till-plats bakom gatewayens fullständigt kvalificerade domännamn (FQDN).

För plats-till-plats-VPN-gatewayen distribueras två instanser av gatewayen i en virtuell hubb. Var och en av gatewayinstanserna distribueras med en egen uppsättning offentliga och privata IP-adresser. De två instanserna tillhandahåller 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.

Att maximera hög tillgänglighet för nätverksarkitekturen är ett viktigt första steg för BCDR (Business Continuity and Disaster Recovery). I resten av den här artikeln, som tidigare nämnts, går vi längre än hög tillgänglighet och diskuterar 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. Haveri kan inträffa i en molnleverantörs regioner eller ett 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 kommunikationsvägen från slutpunkt till slutpunkt och skapa redundans som inte överlappar varandra för vart och ett av beroendena.

Oavsett om du kör dina verksamhetskritiska program i en Azure-region, lokalt eller någon annanstans, kan du använda en annan Azure-region som redundanswebbplats. Följande artiklar behandlar 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 arkitekterade, 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 asymmetrisk routning över privata anslutningar inte 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 fysisk sökväg 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 design för haveriberedskap.

Åtkomst till nätverksredundans

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

Om nätverksanslutning över en annan transporttyp inte är möjlig väljer du nätverksanslutning via mer än en tjänstleverantör. Om du får anslutning via fler än en tjänstleverantörer kontrollerar du att tjänstleverantörerna underhåller icke-överlappande oberoende åtkomstnätverk.

Anslutningsöverväganden för fjärranvändare

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 återupprätta VPN-tunneln. 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ärmaste 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 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 hantering av redundant virtuell hubb med respektive punkt-till-plats-gateway i en region.

Diagram över punkt-till-plats-sammansättning för flera hubbar.

I diagrammet ovan visar de fasta gröna linjerna de primära VPN-anslutningarna punkt-till-plats och de streckade gula linjerna visar stand-by-back-up-anslutningarna. Den globala VWAN-profilen för punkt-till-plats väljer primära anslutningar och säkerhetskopieringsanslutningar baserat på nätverksprestanda. Mer information om global profil finns i Ladda ned en global profil för VPN-användarklienter .

Vpn-överväganden för plats-till-plats

Låt oss ta en titt på den exempel på plats-till-plats VPN-anslutning som visas i följande diagram för vår diskussion. Information om hur du upprättar en plats-till-plats-VPN-anslutning med aktiva och 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.

Kommentar

För enkel förståelse av de begrepp som beskrivs i avsnittet upprepar vi inte diskussionen om funktionen med hög tillgänglighet för plats-till-plats VPN-gateway som gör att du kan skapa två tunnlar till två olika slutpunkter för varje VPN-länk som du konfigurerar. Men när du distribuerar någon av de föreslagna arkitekturerna i avsnittet, kom 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 avdelningsplats 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 tjänstleverantör på sista milen 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 CPE:er för 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 VPN-gateway för virtuell hubb. När du konfigurerar en länk till en grenwebbplats kan du identifiera tjänstleverantören och den dataflödeshastighet 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 lastbalanseras trafik över de parallella länkarna. Belastningsutjämningen för trafiken skulle vara enligt ECMP (Equal-Cost 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 eventuella driftstopp för en VPN-gateway för virtuell hubb skulle topologi med flera hubbar med flera länkar dessutom 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 V P N-anslutningar för flera hubbar till en grenplats.

I topologin ovan kan du använda alla VPN-anslutningar för plats-till-plats mellan de lokala och de två virtuella hubbarna i aktivt-aktivt tillstånd genom att sprida de virtuella ekernätverken mellan 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 konstant tillstånd och använder en annan virtuell hubb som en säkerhetskopia endast under ett feltillstånd. Trafiken skulle passera genom den direkt anslutna 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 för flera regioner med flera länkar" för att klara felet.

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

Diagram över V P N-anslutningar mellan regioner till en grenplats.

Ur trafiktekniksynpunkt 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 beror på 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 din gren/slutanvändare och använda fjärrregionen enbart för säkerhetskopiering.

Om dina lokala grenplatser är utspridda i två eller flera Azure-regioner skulle topologin för flera regioner med flera länkar vara effektivare när det gäller att sprida belastningen och få bättre nätverksupplevelse under stabilt tillstånd. 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 tillhandahålla effektiv haveriberedskap för affärskontinuitet (BCDR).

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

ExpressRoute-överväganden

Överväganden för haveriberedskap för privat ExpressRoute-peering beskrivs i Designa för haveriberedskap med privat ExpressRoute-peering. Som anges i artikeln gäller begreppen som beskrivs i den artikeln lika 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 Express 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 diskuterade vi designen för haveriberedskap för Virtual WAN. Följande artiklar behandlar 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.