Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Usługa ExpressRoute została zaprojektowana pod kątem wysokiej dostępności, aby zapewnić prywatną łączność sieciową klasy operatora z zasobami firmy Microsoft. Innymi słowy, w ścieżce usługi ExpressRoute w sieci firmy Microsoft nie ma jednego punktu awarii. Aby zapoznać się z zagadnieniami dotyczącymi projektowania w celu zmaksymalizowania dostępności obwodu usługi ExpressRoute, zobacz Projektowanie pod kątem wysokiej dostępności za pomocą usługi ExpressRoute i dobrze zaprojektowanej platformy
Jednak biorąc pod uwagę popularną maksymę Murphy'ego — jeśli coś może pójść nie tak, to pójdzie, w tym artykule skupimy się na rozwiązaniach, które wykraczają poza awarie mogące być rozwiązywane jednym obwodem ExpressRoute. Przyjrzymy się zagadnieniom dotyczącym architektury sieci w celu utworzenia niezawodnej łączności sieciowej zaplecza na potrzeby odzyskiwania po awarii przy użyciu geograficznie nadmiarowych obwodów usługi ExpressRoute.
Uwaga
Pojęcia opisane w tym artykule mają zastosowanie również w przypadku utworzenia obwodu usługi ExpressRoute w usłudze Virtual WAN lub poza nim.
Potrzeba rozwiązania zapewniającego redundancję w łączności
Są sytuacje, w których lokalizacja peeringu usługi ExpressRoute lub cała usługa regionalna ulega pogorszeniu. Główną przyczyną takiej regionalnej awarii szerokiej usługi są naturalne katastrofy. W związku z tym ważne jest zaplanowanie odzyskiwania po awarii dla ciągłości działania i aplikacji o znaczeniu krytycznym.
Uwaga
Jeśli musisz zaimplementować projekt odzyskiwania po awarii w sytuacji wrażliwej na czas, na przykład w celu zachowania ciągłości działania podczas klęski żywiołowej, należy wziąć pod uwagę następujące czynniki:
- Ten dokument zawiera wskazówki dotyczące implementowania niezawodnej strategii odzyskiwania po awarii dla wielu obwodów usługi ExpressRoute skonfigurowanych za pośrednictwem różnych lokalizacji peeringowych. W tym scenariuszu przyjęto założenie, że masz wystarczający czas i zasoby do skonfigurowania obwodów usługi ExpressRoute.
- Jeśli musisz szybko skonfigurować projekt odzyskiwania po awarii dla pojedynczego obwodu usługi ExpressRoute, który nie jest geograficznie nadmiarowy, możesz użyć następujących alternatyw:
- Użyj sieci VPN typu site-to-site jako rozwiązania zapasowego dla ruchu prywatnego peeringu.
- Użyj łączności internetowej jako rozwiązania zapasowego dla ruchu peeringu Microsoft.
Bez względu na to, czy uruchamiasz aplikacje o znaczeniu krytycznym w regionie świadczenia usługi Azure, czy lokalnie, czy w dowolnym innym miejscu, możesz użyć innego regionu platformy Azure jako witryny trybu failover. Następujące artykuły omawiają odzyskiwanie danych po awarii z perspektyw aplikacji i dostępu do interfejsu użytkownika.
- Odzyskiwanie po awarii w skali przedsiębiorstwa
- Odzyskiwanie po awarii protokołu SMB za pomocą usługi Azure Site Recovery
Jeśli korzystasz z łączności usługi ExpressRoute między siecią lokalną a firmą Microsoft, należy rozważyć następujące kwestie, aby zaplanować odzyskiwanie po awarii za pośrednictwem usługi ExpressRoute:
- używanie geograficznie nadmiarowych obwodów usługi ExpressRoute
- korzystanie z różnych sieci dostawców usług dla różnych obwodów ExpressRoute
- projektowanie każdego obwodu usługi ExpressRoute pod kątem wysokiej dostępności
- kończenie różnych obwodów usługi ExpressRoute w innej lokalizacji w sieci klienta
- używanie bram sieci wirtualnej ExpressRoute świadomych stref dostępności
Wyzwania związane z używaniem wielu obwodów usługi ExpressRoute
Gdy łączysz ten sam zestaw sieci przy użyciu więcej niż jednego połączenia, wprowadzasz równoległe ścieżki między sieciami. Ścieżki równoległe, jeśli nie są prawidłowo zaprojektowane, mogą prowadzić do routingu asymetrycznego. Jeśli masz komponenty stanowe, na przykład translator adresów sieciowych lub zaporę na trasie, asymetryczne trasowanie może blokować przepływ ruchu. Zazwyczaj za pośrednictwem ścieżki komunikacji równorzędnej usługi ExpressRoute nie napotykasz elementów stanowych, takich jak NAT lub zapory. W związku z tym routing asymetryczny przez prywatne równoległe połączenie ExpressRoute nie musi blokować przepływu ruchu.
Jeśli jednak rozkładasz ruch między geograficznie nadmiarowymi ścieżkami równoległymi, niezależnie od tego, czy masz podmioty stanowe, czy nie, doświadczysz niespójnego działania sieci. Te georedundantne ścieżki równoległe mogą przechodzić przez to samo metro lub inne metro znajdujące się na stronie dostawców według lokalizacji.
Nadmiar z obwodami usługi ExpressRoute w tym samym obszarze metropolitalnym
Wiele metra ma dwie lokalizacje usługi ExpressRoute. Przykładem może być Amsterdam i Amsterdam2. Podczas projektowania nadmiarowości można zbudować dwie równoległe ścieżki do Azure, przy czym obie lokalizacje znajdują się w tym samym obszarze metropolitalnym. To zadanie można wykonać z tym samym dostawcą lub wybrać pracę z innym dostawcą usług, aby zwiększyć odporność. Kolejną zaletą tego projektu jest to, że w przypadku przejścia aplikacji w tryb failover opóźnienie między aplikacjami lokalnymi a firmą Microsoft pozostaje w przybliżeniu takie samo. Jeśli jednak wystąpi klęska żywiołowa, taka jak trzęsienie ziemi, łączność dla obu ścieżek może nie być już dostępna.
Nadmiarowość obwodów usługi ExpressRoute w różnych miastach
W przypadku korzystania z różnych linii metra na potrzeby nadmiarowości, należy wybrać lokalizację pomocniczą w tym samym regionie geopolitycznym. Aby wybrać lokalizację poza regionem geograficznym, należy użyć jednostki SKU Premium dla obu obwodów w ścieżkach równoległych. Zaletą tej konfiguracji jest prawdopodobieństwo wystąpienia klęski żywiołowej powodującej awarię obu łączy jest niższe, ale kosztem zwiększonego opóźnienia.
Uwaga
Włączenie systemu BFD w obwodach usługi ExpressRoute pomoże w szybszym wykrywaniu błędów połączenia między urządzeniami microsoft Enterprise Edge (MSEE) i routerami brzegowymi klienta/partnera. Jednak ogólne przełączenie awaryjne i przejście do lokalizacji zapasowej może potrwać do 180 sekund w przypadku niektórych awarii, co może spowodować zwiększone opóźnienie lub pogorszenie wydajności w tym czasie.
W tym artykule omówiono sposób rozwiązywania problemów, z którymi można się zmierzyć podczas konfigurowania ścieżek geograficznie nadmiarowych.
Zagadnienia dotyczące małych i średnich sieci lokalnych
Rozważmy przykładowa sieć zilustrowana na poniższym diagramie. W tym przykładzie łączność geograficznie nadmiarowa usługi ExpressRoute jest ustanawiana między lokalizacją lokalną firmy Contoso a siecią wirtualną firmy Contoso w regionie świadczenia usługi Azure. Na diagramie niebieska linia wskazuje preferowaną ścieżkę (za pośrednictwem usługi ExpressRoute 1), a kropkowana reprezentuje ścieżkę autonomiczną (za pośrednictwem usługi ExpressRoute 2).
Jeśli domyślnie ogłaszasz trasy identycznie na wszystkich ścieżkach usługi ExpressRoute, Azure równoważy ruch kierowany do lokalnych zasobów we wszystkich ścieżkach usługi ExpressRoute przy użyciu routingu ECMP (Equal-cost multi-path).
Jednak w przypadku geograficznie rozproszonych obwodów usługi ExpressRoute należy wziąć pod uwagę różną wydajność sieci z różnymi ścieżkami sieciowymi (szczególnie w przypadku opóźnienia sieci). Aby uzyskać bardziej spójną wydajność sieci podczas normalnego działania, warto wybrać obwód usługi ExpressRoute, który oferuje minimalne opóźnienie.
Możesz mieć wpływ na platformę Azure, aby preferować jeden obwód usługi ExpressRoute nad innym przy użyciu jednej z następujących technik (wymienionych w kolejności skuteczności):
- anonsowanie bardziej szczegółowej trasy w preferowanym obwodzie usługi ExpressRoute w porównaniu z innymi obwodami usługi ExpressRoute
- Konfigurowanie większej wagi połączenia w połączeniu, które łączy sieć wirtualną z preferowanym obwodem usługi ExpressRoute
- anonsowanie tras w mniej preferowanym obwodzie usługi ExpressRoute z dłuższą ścieżką AS (ścieżka AS prepend)
Bardziej szczegółowa trasa
Na poniższym diagramie przedstawiono wpływ na wybór ścieżki usługi ExpressRoute przy użyciu bardziej szczegółowego anonsu trasy. W przedstawionym przykładzie lokalny zakres adresów IP /24 firmy Contoso jest anonsowany jako dwa zakresy adresów /25 za pośrednictwem preferowanej ścieżki (ExpressRoute 1) i jako /24 za pośrednictwem ścieżki zapasowej (ExpressRoute 2).
Ponieważ /25 jest bardziej szczegółowe, w porównaniu do /24, platforma Azure wyśle ruch kierowany do 10.1.11.0/24 za pośrednictwem usługi ExpressRoute 1 w normalnym stanie. Jeśli obie połączenia usługi ExpressRoute 1 spadną, sieć wirtualna zobaczy anons trasy 10.1.11.0/24 tylko za pośrednictwem usługi ExpressRoute 2; w związku z tym obwód rezerwowy jest używany w tym stanie awarii.
Waga połączenia
Poniższy zrzut ekranu przedstawia konfigurowanie wagi połączenia usługi ExpressRoute za pośrednictwem witryny Azure Portal.
Na poniższym diagramie przedstawiono wpływ na wybór ścieżki usługi ExpressRoute przy użyciu wagi połączenia. Domyślna waga połączenia to 0. W poniższym przykładzie waga połączenia dla usługi ExpressRoute 1 jest skonfigurowana jako 100. Gdy sieć wirtualna odbiera prefiks trasy anonsowany za pośrednictwem więcej niż jednego obwodu usługi ExpressRoute, sieć wirtualna preferuje połączenie z najwyższą wagą.
Jeśli obie połączenia usługi ExpressRoute 1 zostaną zerwane, wtedy sieć wirtualna zobaczy anons trasy 10.1.11.0/24 tylko za pośrednictwem usługi ExpressRoute 2; dlatego obwód rezerwowy jest używany w tym stanie awarii.
Dodawanie prefiksu ścieżki AS
Na poniższym diagramie przedstawiono wpływ na wybór trasy usługi ExpressRoute przy użyciu manipulacji kolejnością ścieżki AS. Na diagramie anons trasy za pośrednictwem usługi ExpressRoute 1 wskazuje domyślne zachowanie protokołu eBGP. W anonsie trasy za pośrednictwem usługi ExpressRoute 2 numer ASN sieci lokalnej jest dodatkowo dołączany do ścieżki AS trasy. Gdy ta sama trasa jest odbierana za pośrednictwem wielu obwodów usługi ExpressRoute, zgodnie z procesem wyboru trasy eBGP sieć wirtualna preferuje trasę z najkrótszą ścieżką AS.
Jeśli obie połączenia usługi ExpressRoute 1 spadną, sieć wirtualna zobaczy anons trasy 10.1.11.0/24 tylko za pośrednictwem usługi ExpressRoute 2. W związku z tym dłuższa ścieżka AS stałaby się nieistotna. W związku z tym obwód rezerwowy będzie używany w tym stanie awarii.
Korzystając z dowolnej z technik, jeśli masz wpływ na platformę Azure, aby preferować jedną z usług ExpressRoute przez inne, musisz również upewnić się, że sieć lokalna preferuje również tę samą ścieżkę usługi ExpressRoute dla ruchu powiązanego z platformą Azure, aby uniknąć przepływów asymetrycznych. Zazwyczaj wartość preferencji lokalnej jest wykorzystywana do wpływania na sieć lokalną na miejscu, aby preferować jeden obwód usługi ExpressRoute nad innymi. Preferencja lokalna to wewnętrzna metryka protokołu BGP (iBGP). Trasa protokołu BGP o najwyższej wartości preferencji lokalnej jest preferowana.
Ważne
W przypadku korzystania z niektórych obwodów usługi ExpressRoute jako rezerwowych należy aktywnie nimi zarządzać i okresowo testować działanie w trybie awaryjnym.
Duża rozproszona sieć przedsiębiorstwa
Jeśli masz dużą rozproszoną sieć przedsiębiorstwa, prawdopodobnie masz wiele obwodów usługi ExpressRoute. W tej sekcji zobaczymy, jak zaprojektować odzyskiwanie po awarii przy użyciu aktywnych obwodów usługi ExpressRoute bez konieczności używania innych obwodów rezerwowych.
Rozważmy przykład przedstawiony na poniższym diagramie. W tym przykładzie firma Contoso ma dwa miejscowe ośrodki połączone z dwoma wdrożeniami IaaS w dwóch różnych regionach Azure za pośrednictwem obwodów ExpressRoute znajdujących się w dwóch różnych punktach wymiany.
Sposób zaprojektowania architektury odzyskiwania po awarii ma wpływ na sposób kierowania ruchu między regionami i lokalizacjami (region1/region2 do lokalizacji2/lokalizacji1). Rozważmy dwie różne architektury katastrof, które inaczej kierują ruchem między regionami-lokalizacjami.
Scenariusz 1
W pierwszym scenariuszu zaprojektujmy odzyskiwanie po awarii, tak aby cały ruch między regionem świadczenia usługi Azure i siecią lokalną przepływał przez lokalny obwód usługi ExpressRoute w stanie stałym. Jeśli lokalny obwód usługi ExpressRoute ulegnie awarii, zdalny obwód usługi ExpressRoute jest używany dla wszystkich przepływów ruchu między platformą Azure i siecią lokalną.
Scenariusz 1 przedstawiono na poniższym diagramie. Na diagramie zielone linie wskazują ścieżki przepływu ruchu między sieciami VNet1 i lokalnymi. Niebieskie linie wskazują ścieżki przepływu ruchu między sieciami VNet2 i lokalnymi. Linie stałe wskazują żądaną ścieżkę w stanie ustalonym, a linie przerywane wskazują ścieżkę ruchu w przypadku awarii odpowiedniego obwodu usługi ExpressRoute, który obsługuje przepływ ruchu w stanie ustalonym.
Scenariusz można zaprojektować, wykorzystując wagę połączenia w celu wpłynięcia na sieci wirtualne, aby preferowały połączenie z lokalną lokalizacją peeringu ExpressRoute dla ruchu kierowanego do sieci lokalnych. Aby ukończyć rozwiązanie, należy zapewnić symetryczny przepływ ruchu zwrotnego. Możesz użyć preferencji lokalnych w sesji iBGP między routerami BGP (na których obwody usługi ExpressRoute są przerywane po stronie lokalnej), aby preferować obwód usługi ExpressRoute. Rozwiązanie zostało zilustrowane na poniższym diagramie.
Scenariusz 2
Scenariusz 2 przedstawiono na poniższym diagramie. Na diagramie zielone linie wskazują ścieżki przepływu ruchu między sieciami VNet1 i lokalnymi. Niebieskie linie wskazują ścieżki przepływu ruchu między sieciami VNet2 i lokalnymi. Na diagramie, stałe linie pokazują, że cały ruch między sieciami wirtualnymi a lokalizacjami na miejscu przepływa normalnie przez szkielet firmy Microsoft. Przepływa on przez połączenia między lokalizacjami na miejscu jedynie w przypadku awarii, co jest przedstawione jako kropkowane linie na diagramie usługi ExpressRoute.
Rozwiązanie zostało zilustrowane na poniższym diagramie. Jak pokazano, możesz zaprojektować scenariusz przy użyciu bardziej szczegółowej trasy (Opcja 1) lub dodania prefiksu do ścieżki AS (Opcja 2), aby wpłynąć na wybór trasy wirtualnej sieci. Aby wpłynąć na wybór tras sieci lokalnych dla ruchu powiązanego z platformą Azure, należy skonfigurować wzajemne połączenia między lokalizacją lokalną jako mniej preferowaną. Sposób konfigurowania połączenia wzajemnego w preferowany sposób zależy od protokołu routingu używanego w sieci lokalnej. Możesz używać preferencji lokalnych przy użyciu iBGP lub metryk z IGP (OSPF lub IS-IS).
Ważne
Kiedy jeden lub więcej obwodów usługi ExpressRoute jest połączonych z wieloma sieciami wirtualnymi, ruch między sieciami wirtualnymi może być kierowany za pośrednictwem usługi ExpressRoute. Nie jest to jednak zalecane. Aby włączyć łączność sieci wirtualnej z siecią wirtualną, skonfiguruj peering sieci wirtualnych.
Następne kroki
W tym artykule omówiono sposób projektowania odzyskiwania po awarii łączności prywatnej komunikacji równorzędnej obwodu usługi ExpressRoute. Następujący artykuł dotyczy odzyskiwania po awarii z perspektywy aplikacji i dostępu do frontendu.