Ontwerp voor herstel na noodgevallen
met Virtual WAN kunt u al uw wereldwijde implementaties samenvoegen, verbinden, centraal beheren en beveiligen. Uw globale implementaties kunnen combinaties van verschillende vertakkingen, Point-of-Presence (PoP), privégebruikers, kantoren, virtuele Azure-netwerken en andere implementaties met meerdere clouds omvatten. U kunt SD-WAN, site-naar-site-VPN, punt-naar-site-VPN en ExpressRoute gebruiken om uw verschillende sites te verbinden met een virtuele hub. Als u meerdere virtuele hubs hebt, zijn alle hubs in volledige mesh verbonden in een standaard Virtual WAN-implementatie.
In dit artikel gaan we kijken hoe u verschillende typen netwerk-as-a-service-connectiviteitsopties kunt ontwerpen die Virtual WAN ondersteunt voor herstel na noodgevallen.
Netwerk-as-a-service-connectiviteitsopties van Virtual WAN
Virtual WAN ondersteunt de volgende back-endconnectiviteitsopties:
- Externe gebruikersconnectiviteit
- Branch/Office/SD-WAN/Site-to-site VPN
- Privéconnectiviteit (persoonlijke ExpressRoute-peering)
Voor elk van deze connectiviteitsopties implementeert Virtual WAN een afzonderlijke set gateway-exemplaren binnen een virtuele hub.
Inherent is Virtual WAN ontworpen om een hoogwaardige netwerkaggregatieoplossing te bieden. Voor hoge beschikbaarheid maakt Virtual WAN meerdere exemplaren wanneer elk van deze verschillende typen gateways wordt geïmplementeerd in een Virtual WAN hub. Zie Ontwerpen voor hoge beschikbaarheid met ExpressRoute voor meer informatie over hoge beschikbaarheid van ExpressRoute.
Met de punt-naar-site-VPN-gateway is het minimale aantal geïmplementeerde exemplaren twee. Met de punt-naar-site-VPN-gateway kiest u de geaggregeerde doorvoercapaciteit van punt-naar-site-gateways en worden meerdere exemplaren automatisch voor u ingericht. U kiest de geaggregeerde capaciteit op basis van het aantal clients of gebruikers dat u wilt verbinden met de virtuele hub. Vanuit het perspectief van de clientconnectiviteit zijn de punt-naar-site VPN-gateway-exemplaren verborgen achter de FQDN (Fully Qualified Domain Name) van de gateway.
Voor de site-naar-site-VPN-gateway worden twee exemplaren van de gateway geïmplementeerd in een virtuele hub. Elk gateway-exemplaar wordt geïmplementeerd met een eigen set openbare en privé-IP-adressen. In de volgende schermopname ziet u de IP-adressen die zijn gekoppeld aan de twee exemplaren van een voorbeeldconfiguratie van een site-naar-site-VPN-gateway. Met andere woorden, de twee exemplaren bieden twee onafhankelijke tunneleindpunten voor het tot stand brengen van site-naar-site-VPN-connectiviteit vanuit uw vertakkingen. Zie Azure-padselectie via meerdere internetproviders om maximale beschikbaarheid te maximaliseren.
Het maximaliseren van de hoge beschikbaarheid van uw netwerkarchitectuur is een belangrijke eerste stap voor bedrijfscontinuïteit en herstel na noodgevallen (BCDR). In de rest van dit artikel, zoals eerder vermeld, gaan we verder dan hoge beschikbaarheid en bespreken we hoe u uw Virtual WAN-connectiviteitsnetwerk voor BCDR kunt ontwerpen.
Ontwerp voor herstel na noodgeval nodig
Het noodgeval kan op elk moment en overal toeslaan. Een noodgeval kan optreden in regio's of netwerken van een cloudprovider, binnen een netwerk van een serviceprovider of binnen een on-premises netwerk. Regionale impact van een cloud- of netwerkservice als gevolg van bepaalde factoren, zoals natuurlijke rampen, menselijke fouten, oorlog, terrorisme, onjuiste configuratie, zijn moeilijk uit te sluiten. Voor de continuïteit van uw bedrijfskritieke toepassingen moet u dus een ontwerp voor herstel na noodgevallen hebben. Voor een uitgebreid ontwerp voor herstel na noodgevallen moet u alle afhankelijkheden identificeren die mogelijk mislukken in uw end-to-end-communicatiepad en niet-overlappende redundantie maken voor elke afhankelijkheid.
Ongeacht of u uw bedrijfskritieke toepassingen uitvoert in een Azure-regio, on-premises of ergens anders, kunt u een andere Azure-regio als failoversite gebruiken. De volgende artikelen hebben betrekking op herstel na noodgevallen vanuit toepassingen en front-endtoegangsperspectieven:
Uitdagingen bij het gebruik van redundante connectiviteit
Wanneer u dezelfde set netwerken verbindt met behulp van meer dan één verbinding, introduceert u parallelle paden tussen de netwerken. Parallelle paden kunnen, wanneer ze niet goed zijn ontworpen, leiden tot asymmetrische routering. Als u stateful entiteiten (bijvoorbeeld NAT, firewall) in het pad hebt, kan asymmetrische routering de verkeersstroom blokkeren. Normaal gesproken hebt u via privéconnectiviteit geen stateful entiteiten zoals NAT of firewalls. Daarom blokkeert asymmetrische routering via privéconnectiviteit niet noodzakelijkerwijs de verkeersstroom.
Als u echter verkeer over geografisch redundante parallelle paden balanceert, ondervindt u inconsistente netwerkprestaties vanwege het verschil in het fysieke pad van de parallelle verbindingen. Daarom moeten we rekening houden met de prestaties van netwerkverkeer, zowel tijdens de stabiele status (niet-foutstatus) als een foutstatus als onderdeel van ons ontwerp voor herstel na noodgevallen.
Netwerkredundantie openen
De meeste SD-WAN-services (beheerde oplossingen of anderszins) bieden u netwerkconnectiviteit via meerdere transporttypen (bijvoorbeeld internet breedband, MPLS, LTE). Als u zich wilt beschermen tegen fouten in het transportnetwerk, kiest u connectiviteit via meer dan één transportnetwerk. Voor een thuisgebruikersscenario kunt u overwegen een mobiel netwerk te gebruiken als back-up voor breedbandnetwerkconnectiviteit.
Als netwerkverbinding via een ander transporttype niet mogelijk is, kiest u netwerkconnectiviteit via meer dan één serviceprovider. Als u verbinding krijgt via meer dan één serviceprovider, moet u ervoor zorgen dat de serviceproviders niet-overlappende onafhankelijke toegangsnetwerken onderhouden.
Overwegingen voor externe gebruikersconnectiviteit
Externe gebruikersconnectiviteit wordt tot stand gebracht met punt-naar-site-VPN tussen een eindapparaat en een netwerk. Na een netwerkfout zou het eindapparaat vallen en proberen de VPN-tunnel opnieuw te stabiliseren. Daarom moet uw ontwerp voor herstel na noodgeval voor punt-naar-site-VPN erop gericht zijn om de hersteltijd na een fout te minimaliseren. De volgende netwerkredundantie helpt de hersteltijd te minimaliseren. Afhankelijk van hoe kritiek de verbindingen zijn, kunt u een of meer van deze opties kiezen.
- Netwerkredundantie openen (hierboven besproken).
- Redundante virtuele hub beheren voor punt-naar-site-VPN-beëindiging. Wanneer u meerdere virtuele hubs met punt-naar-site-gateways hebt, biedt VWAN een globaal profiel met alle punt-naar-site-eindpunten. Met het globale profiel kunnen uw eindapparaten verbinding maken met de dichtstbijzijnde beschikbare virtuele hub die de beste netwerkprestaties biedt. Als al uw Azure-implementaties zich in één regio bevinden en de eindapparaten die verbinding maken zich dicht bij de regio bevinden, kunt u redundante virtuele hubs in de regio hebben. Als uw implementatie- en eindapparaten zijn verdeeld over meerdere regio's, kunt u een virtuele hub met punt-naar-site-gateway implementeren in elk van de geselecteerde regio's. Virtual WAN heeft een ingebouwde Traffic Manager die automatisch de beste hub voor externe gebruikersconnectiviteit selecteert.
In het volgende diagram ziet u het concept van het beheren van redundante virtuele hubs met hun respectieve punt-naar-site-gateway binnen een regio.
In het bovenstaande diagram tonen de ononderbroken groene lijnen de primaire punt-naar-site-VPN-verbindingen en de gele stippellijnen de stand-by-back-upverbindingen. Het globale VWAN-profiel voor punt-naar-site selecteert primaire en back-upverbindingen op basis van de netwerkprestaties. Zie Download a global profile for User VPN clients (Een globaal profiel downloaden voor VPN-clients voor gebruikers) voor meer informatie over het globale profiel.
Overwegingen voor site-naar-site-VPN
Laten we eens kijken naar het voorbeeld van een site-naar-site-VPN-verbinding die wordt weergegeven in het volgende diagram voor onze discussie. Zie Zelfstudie: Een site-naar-site-verbinding maken met Azure Virtual WAN om een site-naar-site-VPN-verbinding tot stand te brengen met hoog beschikbare actief-actief-tunnels.
Notitie
Voor een eenvoudig begrip van de concepten die in de sectie worden besproken, herhalen we de discussie over de functie voor hoge beschikbaarheid van site-naar-site-VPN-gateway waarmee u twee tunnels naar twee verschillende eindpunten kunt maken voor elke VPN-koppeling die u configureert. Bij het implementeren van een van de voorgestelde architectuur in de sectie moet u echter twee tunnels configureren voor elke koppeling die u tot stand brengt.
Topologie met meerdere koppelingen
Ter bescherming tegen storingen van VPN Customer Premises Equipment (CPE) op een filiaalsite, kunt u parallelle VPN-koppelingen naar een VPN-gateway configureren vanaf parallelle CPE-apparaten op de vertakkingssite. Ter bescherming tegen netwerkstoringen van een last-mile serviceprovider naar het filiaal, kunt u verschillende VPN-koppelingen configureren via een ander serviceprovidernetwerk. In het volgende diagram ziet u meerdere VPN-koppelingen die afkomstig zijn van twee verschillende CPEs van een vertakkingssite die eindigen op dezelfde VPN-gateway.
U kunt maximaal vier koppelingen naar een vertakkingssite configureren vanuit een VPN-gateway van een virtuele hub. Tijdens het configureren van een koppeling naar een vertakkingssite kunt u de serviceprovider en de doorvoersnelheid identificeren die aan de koppeling is gekoppeld. Wanneer u parallelle koppelingen tussen een vertakkingssite en een virtuele hub configureert, zou de VPN-gateway het verkeer standaard verdelen over de parallelle koppelingen. De taakverdeling van verkeer is afhankelijk van Equal-Cost ECMP (Multi-Path) per stroom.
Multi-hub-topologie met meerdere koppelingen
Multi-link-topologie beschermt tegen CPE-apparaatfouten en een netwerkfout van een serviceprovider op de on-premises vertakkingslocatie. Ter bescherming tegen uitvaltijd van een VPN-gateway voor virtuele hubs zou multi-hub topologie met meerdere hubs bovendien helpen. In het volgende diagram ziet u de topologie, waarin meerdere virtuele hubs zijn geconfigureerd onder een Virtual WAN-exemplaar binnen een regio:
In de bovenstaande topologie kunt u, omdat latentie binnen azure-regio's over de verbinding tussen de hubs onbeduidend is, alle site-naar-site-VPN-verbindingen tussen de on-premises en de twee virtuele hubs in de status actief-actief gebruiken door de spoke-VNets over de hubs te spreiden. In de topologie gaat het verkeer tussen on-premises en een spoke-VNET standaard rechtstreeks via de virtuele hub waarmee het spoke-VNET is verbonden tijdens de steady-state en gebruikt een andere virtuele hub alleen als back-up tijdens een foutstatus. Verkeer doorkruist de rechtstreeks verbonden hub in de stabiele status, omdat de BGP-routes die door de rechtstreeks verbonden hub worden geadverteerd, een korter AS-pad hebben in vergelijking met de back-uphub.
De multi-hub topologie met meerdere koppelingen beschermt en biedt bedrijfscontinuïteit tegen de meeste foutscenario's. Als een catastrofale fout echter de hele Azure-regio onderneemt, hebt u 'multi-region multi-link topologie' nodig om de fout te weerstaan.
Topologie voor meerdere regio's met meerdere koppelingen
Topologie met meerdere regio's met meerdere koppelingen beschermt tegen zelfs een catastrofale fout van een hele regio, naast de beveiligingen die worden geboden door de multi-hub-multi-link-topologie die we eerder hebben besproken. In het volgende diagram ziet u de multi-region multi-link topologie. De virtuele hubs in verschillende regio's kunnen worden geconfigureerd onder hetzelfde Virtual WAN exemplaar.
Vanuit het oogpunt van traffic engineering moet u rekening houden met een aanzienlijk verschil tussen het hebben van redundante hubs binnen een regio en het hebben van de back-uphub in een andere regio. Het verschil is de latentie die het gevolg is van de fysieke afstand tussen de primaire en secundaire regio's. Daarom kunt u uw serviceresources met een stabiele status implementeren in de regio die zich het dichtst bij uw vertakking/eindgebruikers bevindt en de externe regio uitsluitend gebruiken voor back-ups.
Als uw on-premises vertakkingslocaties zijn verdeeld over twee of meer Azure-regio's, zou de multi-regio's multi-link topologie effectiever zijn bij het spreiden van de belasting en het verkrijgen van een betere netwerkervaring tijdens de stabiele status. In het volgende diagram ziet u de multi-link topologie met meerdere regio's met vertakkingen in verschillende regio's. In een dergelijk scenario biedt de topologie bovendien effectieve BCDR (Business Continuity Disaster Recovery).
Overwegingen voor ExpressRoute
Overwegingen voor herstel na noodgevallen voor persoonlijke ExpressRoute-peering worden besproken in Ontwerpen voor herstel na noodgevallen met persoonlijke ExpressRoute-peering. Zoals vermeld in het artikel, zijn de concepten die in dat artikel worden beschreven, ook van toepassing op ExpressRoute-gateways die in een virtuele hub zijn gemaakt. Het gebruik van een redundante virtuele hub binnen de regio, zoals weergegeven in het volgende diagram, is de enige topologieverbetering die wordt aanbevolen voor kleine tot middelgrote on-premises netwerkoverwegingen.
In het bovenstaande diagram wordt ExpressRoute 2 beëindigd op een afzonderlijke ExpressRoute-gateway binnen een tweede virtuele hub binnen de regio.
Volgende stappen
In dit artikel hebben we het gehad over Virtual WAN ontwerp voor herstel na noodgevallen. De volgende artikelen hebben betrekking op herstel na noodgevallen vanuit toepassingen en front-endtoegangsperspectieven:
Als u een punt-naar-site-verbinding met Virtual WAN wilt maken, raadpleegt u Zelfstudie: een VPN-verbinding voor gebruikers maken met behulp van Azure Virtual WAN. Zie Zelfstudie: Een site-naar-site-verbinding maken met Azure Virtual WAN om een site-naar-site-verbinding te maken met Virtual WAN. Als u een ExpressRoute-circuit wilt koppelen aan Virtual WAN, raadpleegt u Zelfstudie: Een ExpressRoute-koppeling maken met behulp van Azure Virtual WAN.