Ontwerp voor herstel na noodgevallen
Met Virtual WAN kunt u al uw wereldwijde implementaties aggregeren, verbinden, centraal beheren en beveiligen. Uw wereldwijde implementaties kunnen bestaan uit alle combinaties van verschillende vertakkingen, Point-of-Presence (PoP), privégebruikers, kantoren, virtuele Azure-netwerken en andere implementaties met meerdere clouds. 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, worden 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.
Connectiviteitsopties voor netwerk als een service van Virtual WAN
Virtual WAN ondersteunt de volgende opties voor back-endconnectiviteit:
- Externe gebruikersconnectiviteit
- Branch/Office/SD-WAN/Site-to-site VPN
- Privéconnectiviteit (persoonlijke ExpressRoute-peering)
Voor elk van deze connectiviteitsopties implementeert Virtual WAN afzonderlijke set gateway-exemplaren binnen een virtuele hub.
Inherent is Virtual WAN ontworpen om hoogwaardige hoogwaardige netwerkaggregatieoplossing te bieden. Voor hoge beschikbaarheid instantieert 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 clientconnectiviteit worden 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. De twee exemplaren bieden twee onafhankelijke tunneleindpunten voor het tot stand brengen van site-naar-site-VPN-connectiviteit vanuit uw vertakkingen. Als u hoge beschikbaarheid wilt maximaliseren, raadpleegt u de selectie van Azure-paden tussen meerdere internetproviders.
Het maximaliseren van de hoge beschikbaarheid van uw netwerkarchitectuur is een belangrijke eerste stap voor BCDR (Bedrijfscontinuïteit en Herstel na noodgevallen). 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.
Noodherstelontwerp
Een noodgeval kan op elk gewenst moment en overal worden getroffen. Er kan zich een noodgeval voordoen in een cloudproviderregio of in een netwerk van een serviceprovider of in een on-premises netwerk. Regionale impact van een cloud- of netwerkservice vanwege 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 elk van de afhankelijkheid.
Ongeacht of u uw bedrijfskritieke toepassingen uitvoert in een Azure-regio, on-premises of ergens anders, kunt u een andere Azure-regio gebruiken als uw failoversite. De volgende artikelen hebben betrekking op herstel na noodgevallen vanuit toepassingen en perspectieven voor front-endtoegang:
Uitdagingen bij het gebruik van redundante connectiviteit
Wanneer u dezelfde set netwerken met meerdere verbindingen verbindt, introduceert u parallelle paden tussen de netwerken. Parallelle paden, wanneer ze niet goed zijn ontworpen, kunnen 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 verdeelt, 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.
Toegang tot netwerkredundantie
De meeste SD-WAN-services (beheerde oplossingen of anderszins) bieden netwerkconnectiviteit via meerdere transporttypen (bijvoorbeeld internetbreedband, MPLS, LTE). Als u wilt beschermen tegen transportnetwerkfouten, kiest u connectiviteit via meer dan één transportnetwerk. Voor een scenario voor thuisgebruikers kunt u overwegen om een mobiel netwerk te gebruiken als back-up voor breedbandnetwerkconnectiviteit.
Als de netwerkverbinding via een ander transporttype niet mogelijk is, kiest u de netwerkverbinding via meer dan één serviceprovider. Als u connectiviteit 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 behulp van punt-naar-site-VPN tussen een eindapparaat en een netwerk. Na een netwerkfout zou het eindapparaat worden neergestort en wordt geprobeerd de VPN-tunnel opnieuw tot stand te brengen. Daarom moet uw ontwerp voor herstel na noodgeval voor punt-naar-site-VPN de hersteltijd minimaliseren na een storing. De volgende netwerkredundantie helpt de hersteltijd te minimaliseren. Afhankelijk van hoe kritiek de verbindingen zijn, kunt u een of meer van deze opties kiezen.
- Toegang tot netwerkredundantie (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 verspreid zijn over meerdere regio's, kunt u virtuele hub implementeren met punt-naar-site-gateway in elk van uw 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 stippellijnen geven de stand-by-back-upverbindingen weer. Het globale VWAN-profiel voor punt-naar-site selecteert primaire en back-upverbindingen op basis van de netwerkprestaties. Zie Een globaal profiel voor VPN-clients voor gebruikers downloaden voor meer informatie over globaal profiel.
Overwegingen voor site-naar-site-VPN
Laten we eens kijken naar de voorbeeld-naar-site-VPN-verbinding die wordt weergegeven in het volgende diagram voor onze discussie. Als u een site-naar-site-VPN-verbinding wilt tot stand brengen met actieve tunnels met hoge beschikbaarheid, raadpleegt u zelfstudie: Een site-naar-site-verbinding maken met behulp van Azure Virtual WAN.
Notitie
Voor een eenvoudig begrip van de concepten die in de sectie worden besproken, herhalen we niet de bespreking van de functie voor hoge beschikbaarheid van site-naar-site-VPN-gateway waarmee u twee tunnels kunt maken naar twee verschillende eindpunten voor elke VPN-koppeling die u configureert. Tijdens 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 vertakkingssite, kunt u parallelle VPN-koppelingen naar een VPN-gateway configureren vanaf parallelle CPE-apparaten op de vertakkingssite. Als u zich verder wilt beschermen tegen netwerkfouten van een last-mile-serviceprovider naar het filiaal, kunt u verschillende VPN-koppelingen configureren via een ander netwerk van serviceproviders. In het volgende diagram ziet u meerdere VPN-koppelingen die afkomstig zijn van twee verschillende CPU's van een vertakkingssite die op dezelfde VPN-gateway eindigen.
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, verdeelt de VPN-gateway standaard het verkeer over de parallelle koppelingen. De taakverdeling van verkeer is afhankelijk van ECMP (Equal Cost Multi-Path) per stroom.
Topologie voor meerdere hubs met meerdere koppelingen
Topologie met meerdere koppelingen beschermt tegen CPE-apparaatfouten en een netwerkfout van de serviceprovider op de locatie van de on-premises vertakking. Ter bescherming tegen uitvaltijd van een vpn-gateway voor virtuele hubs zou multi-hub-topologie met meerdere koppelingen 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, omdat de latentie tussen de hubs binnen Azure-regio's onbelangrijk is, kunt u alle site-naar-site-VPN-verbindingen tussen de on-premises en de twee virtuele hubs in actief-actief-status gebruiken door de spoke-VNets over de hubs te spreiden. In de topologie loopt verkeer tussen on-premises en een virtueel spoke-netwerk standaard rechtstreeks door de virtuele hub waarnaar het virtuele spoke-netwerk is verbonden tijdens de gestage status en wordt een andere virtuele hub alleen tijdens een foutstatus gebruikt als back-up. Verkeer zou door de rechtstreeks verbonden hub in de gestage toestand gaan, omdat de BGP-routes die door de rechtstreeks verbonden hub worden geadverteerd, een korter AS-pad zouden hebben in vergelijking met de back-uphub.
De topologie met meerdere hubs met meerdere koppelingen zou bedrijfscontinuïteit beschermen en bieden tegen de meeste foutscenario's. Als een onherstelbare fout echter de hele Azure-regio uitvalt, hebt u een topologie met meerdere regio's voor meerdere regio's nodig om bestand te zijn tegen de fout.
Topologie voor meerdere regio's met meerdere koppelingen
Topologie met meerdere regio's voor meerdere koppelingen beschermt tegen zelfs een onherstelbare fout van een hele regio, naast de beveiligingen die worden geboden door de multi-hub topologie met meerdere koppelingen die we eerder hebben besproken. In het volgende diagram ziet u de topologie met meerdere regio's met meerdere koppelingen. 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 één aanzienlijk verschil tussen het hebben van redundante hubs binnen een regio versus 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 servicebronnen 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-up.
Als uw on-premises vertakkingslocaties verspreid zijn over twee of meer Azure-regio's, is de topologie met meerdere regio's met meerdere regio's effectiever bij het spreiden van de belasting en het verkrijgen van een betere netwerkervaring tijdens de stabiele status. In het volgende diagram ziet u de topologie met meerdere regio's met vertakkingen in verschillende regio's. In dit 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 dit artikel worden beschreven, evenzeer van toepassing op ExpressRoute-gateways die zijn gemaakt in een virtuele hub. Het gebruik van een redundante virtuele hub binnen de regio, zoals wordt weergegeven in het volgende diagram, is de enige topologieverbetering die wordt aanbevolen voor overwegingen met betrekking tot kleine tot middelgrote on-premises netwerken.
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 het ontwerp voor herstel na noodgevallen van Virtual WAN. De volgende artikelen hebben betrekking op herstel na noodgevallen vanuit toepassingen en perspectieven voor front-endtoegang:
Als u een punt-naar-site-verbinding met Virtual WAN wilt maken, raadpleegt u de zelfstudie: Een gebruikers-VPN-verbinding maken met behulp van Azure Virtual WAN. Als u een site-naar-site-verbinding met Virtual WAN wilt maken, raadpleegt u de zelfstudie: Een site-naar-site-verbinding maken met behulp van Azure Virtual WAN. Als u een ExpressRoute-circuit wilt koppelen aan Virtual WAN, raadpleegt u de zelfstudie: Een ExpressRoute-koppeling maken met behulp van Azure Virtual WAN.