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.
Aplikacje o wysokich wymaganiach dotyczących dostępności lub odzyskiwania po awarii często wymagają wdrożenia w więcej niż jednym regionie świadczenia usługi Azure. W takich przypadkach sieci wirtualne typu "spoke" w różnych regionach muszą się ze sobą komunikować. Jednym ze sposobów włączenia tej komunikacji jest sparowanie wszystkich wymaganych szprych sieci wirtualnych ze sobą. Jednak takie podejście spowoduje pominięcie wszystkich centralnych wirtualnych urządzeń sieciowych (NVAs), takich jak zapory w węzłach. Alternatywą jest użycie tras zdefiniowanych przez użytkownika (UDR) w podsieciach, w których wdrażane są urządzenia NVA koncentratora, ale utrzymanie tras zdefiniowanych przez użytkownika może być trudne. Usługa Azure Route Server oferuje dynamiczną alternatywę, która automatycznie dostosowuje się do zmian topologii bez konieczności ręcznej interwencji.
Topologia
Na poniższym diagramie przedstawiono architekturę dwóch regionów, w której topologia koncentrator-szprychy istnieje w każdym regionie, a sieci wirtualne koncentratora są połączone globalnym peeringiem sieci wirtualnych.
NVA w każdym regionie poznaje prefiksy lokalnych sieci wirtualnych w topologii hub-and-spoke za pośrednictwem Azure Route Server i udostępnia je NVA w innym regionie przy użyciu protokołu BGP. Aby uniknąć pętli routingu, ważne jest, aby ustanowić tę komunikację między NVAs przy użyciu technologii tunelowania, takiej jak IPsec lub Virtual eXtensible LAN (VXLAN).
Aby umożliwić usłudze Azure Route Server ogłaszanie prefiksów sieci wirtualnych ramion lokalnym urządzeniom WUS i implementowanie poznanych tras z powrotem do tych sieci, konieczne jest użycie ustawienia Użyj bramy zdalnej sieci wirtualnej lub serwera tras do połączenia równorzędnego między sieciami wirtualnymi ramion a siecią wirtualną koncentratora.
Urządzenia NVAs ogłaszają trasy, które poznają z regionu zdalnego, do lokalnego serwera tras, który następnie konfiguruje te trasy w lokalnych sieciach wirtualnych z rozgałęzieniami, odpowiednio przyciągając ruch. W przypadkach, gdy w tym samym regionie istnieje wiele urządzeń NVA (serwer tras obsługuje do ośmiu węzłów BGP), prefiksowanie ścieżki AS może być używane do preferowania jednego z urządzeń NVA w stosunku do pozostałych, skutecznie ustanawiając topologię urządzenia NVA aktywnego/rezerwowego.
Ważne
Aby upewnić się, że lokalny serwer tras może uczyć się tras anonsowanych przez NVA z regionu zdalnego, NVA musi usunąć numer systemu autonomicznego (ASN) 65515 ze ścieżki AS tras. Ta technika jest czasami określana jako "nadpisanie AS" lub "przepisywanie ścieżki AS" w niektórych platformach BGP. W przeciwnym razie mechanizm zapobiegania pętli w protokole BGP uniemożliwi lokalnemu serwerowi tras nauczenie się tych tras, ponieważ zabrania uczenia się tras, które już zawierają lokalny ASN.
ExpressRoute
Projekt z wieloma regionami można połączyć z usługą ExpressRoute lub bramami sieci VPN. Na poniższym diagramie przedstawiono topologię obejmującą bramę usługi ExpressRoute połączoną z siecią lokalną w jednym z regionów świadczenia usługi Azure. W takim przypadku sieć nakładkowa nad obwodem ExpressRoute pomaga uprościć sieć, dzięki czemu prefiksy lokalne pojawiają się w Azure tylko jako rozgłaszane przez urządzenie NVA (a nie z bramy ExpressRoute).
Projektowanie bez nakładek
Tunele międzyregionalne pomiędzy NVAs są wymagane, ponieważ w przeciwnym razie zostanie utworzona pętla routingu. Na przykład patrząc na NVA w regionie 1:
- Urządzenie NVA w regionie 1 uczy się prefiksów z regionu 2 i przekazuje je do serwera tras w regionie 1.
- Serwer tras w regionie 1 doda trasy dla tych prefiksów we wszystkich podsieciach w regionie 1, z wirtualnym urządzeniem sieciowym (NVA) w regionie 1 jako następnym przeskokiem.
- W przypadku ruchu z regionu 1 do regionu 2, gdy urządzenie WUS w regionie 1 wysyła ruch do innego urządzenia WUS, jego własna podsieć dziedziczy również trasy zaprogramowane przez serwer tras, które wskazują na siebie (urządzenie WUS). Pakiet jest zwracany do urządzenia NVA i powstaje pętla routingu.
Jeśli trasy definiowane przez użytkownika są opcją, możesz wyłączyć propagację tras BGP we wszystkich podsieciach wirtualnych urządzeń sieciowych (NVAs) i skonfigurować statyczne trasy definiowane przez użytkownika zamiast nakładki, aby platforma Azure mogła przekazywać ruch do zdalnych sieci wirtualnych typu spoke.
Treści powiązane
- Dowiedz się więcej o obsłudze usługi Azure Route Server dla usługi ExpressRoute i sieci VPN platformy Azure.
- Dowiedz się, jak skonfigurować komunikację równorzędną między usługą Azure Route Server a wirtualnym urządzeniem sieciowym.