Planowanie integracji sieci dla usługi Azure Stack Hub

Ten artykuł zawiera informacje o infrastrukturze sieci usługi Azure Stack Hub, które pomogą Ci zdecydować, jak najlepiej zintegrować usługę Azure Stack Hub z istniejącym środowiskiem sieciowym.

Uwaga

Aby rozpoznawać zewnętrzne nazwy DNS z usługi Azure Stack Hub (na przykład www.bing.com), należy udostępnić serwery DNS do przekazywania żądań DNS. Aby uzyskać więcej informacji na temat wymagań dns usługi Azure Stack Hub, zobacz Integracja centrum danych usługi Azure Stack Hub — DNS.

Projekt sieci fizycznej

Rozwiązanie Azure Stack Hub wymaga odpornej i wysoce dostępnej infrastruktury fizycznej do obsługi jej operacji i usług. Aby zintegrować usługę Azure Stack Hub z siecią, wymagane są pasma z przełączników top-of-Rack (ToR) do najbliższego przełącznika lub routera, który w tej dokumentacji jest określany jako Obramowanie. Zakresy ściągnięcia można połączyć z jedną lub parą obramowań. ToR jest wstępnie skonfigurowany przez nasze narzędzie automatyzacji, oczekuje co najmniej jednego połączenia między tor i obramowaniem podczas korzystania z routingu BGP i co najmniej dwóch połączeń (jeden na toR) między tor i obramowaniem podczas korzystania z routingu statycznego, z maksymalnie czterema połączeniami w obu opcjach routingu. Te połączenia są ograniczone do nośników SFP+ lub SFP28 i co najmniej jednej szybkości GB. Aby uzyskać dostępność, skontaktuj się z dostawcą sprzętu producenta oryginalnego sprzętu (OEM). Na poniższym diagramie przedstawiono zalecany projekt:

Recommended Azure Stack network design

Alokacja przepustowości

Usługa Azure Stack Hub jest tworzona przy użyciu technologii Windows Server 2019 Failover Cluster and Spaces Direct. Część konfiguracji sieci fizycznej usługi Azure Stack Hub jest wykonywana w celu wykorzystania gwarancji separacji ruchu i przepustowości w celu zapewnienia, że komunikacja magazynu bezpośredniego miejsc do magazynowania może spełniać wymagania dotyczące wydajności i skalowania wymaganego rozwiązania. Konfiguracja sieci używa klas ruchu do oddzielania bezpośredniej komunikacji opartej na funkcji RDMA miejsc od komunikacji sieciowej przez infrastrukturę i/lub dzierżawę usługi Azure Stack Hub. Aby dostosować się do bieżących najlepszych rozwiązań zdefiniowanych dla serwera Windows Server 2019, usługa Azure Stack Hub zmienia się na użycie dodatkowej klasy ruchu lub priorytetu w celu dalszego oddzielenia komunikacji między serwerami w celu obsługi komunikacji z klastrem trybu failover. Ta nowa definicja klasy ruchu zostanie skonfigurowana do zarezerwowania 2% dostępnej przepustowości fizycznej. Ta konfiguracja rezerwacji ruchu i przepustowości jest realizowana przez zmianę przełączników top-of-rack (ToR) rozwiązania Azure Stack Hub oraz na hoście lub serwerach usługi Azure Stack Hub. Należy pamiętać, że zmiany nie są wymagane na urządzeniach sieciowych obramowania klienta. Te zmiany zapewniają lepszą odporność komunikacji klastra trybu failover i mają na celu uniknięcie sytuacji, w których przepustowość sieci jest w pełni zużywana, a w wyniku tego komunikaty sterowania klastrem trybu failover są zakłócane. Należy pamiętać, że komunikacja klastra trybu failover jest krytycznym składnikiem infrastruktury usługi Azure Stack Hub i w przypadku zakłócenia przez długi czas może prowadzić do niestabilności usług magazynu bezpośrednich miejsc do magazynowania lub innych usług, które ostatecznie wpłyną na stabilność obciążenia dzierżawy lub użytkownika końcowego.

Uwaga

Opisane zmiany są dodawane na poziomie hosta systemu Usługi Azure Stack Hub w wersji 2008. Skontaktuj się z OEM, aby zorganizować wprowadzanie wymaganych zmian w przełącznikach sieciowych ToR. Tę zmianę tor można wykonać przed aktualizacją do wersji 2008 lub po aktualizacji do wersji 2008. Aby poprawić komunikację klastra trybu failover, wymagana jest zmiana konfiguracji przełączników ToR.

Sieci logiczne

Sieci logiczne reprezentują abstrakcję podstawowej infrastruktury sieci fizycznej. Są one używane do organizowania i upraszczania przypisań sieciowych dla hostów, maszyn wirtualnych i usług. W ramach tworzenia sieci logicznej lokacje sieciowe są tworzone w celu zdefiniowania wirtualnych sieci lokalnych (VLAN), podsieci IP i par podsieci IP/sieci VLAN skojarzonych z siecią logiczną w każdej lokalizacji fizycznej.

W poniższej tabeli przedstawiono sieci logiczne i skojarzone zakresy podsieci IPv4, dla których należy zaplanować:

Sieć logiczna Opis Rozmiar
Publiczny adres VIP Usługa Azure Stack Hub używa łącznie 31 adresów z tej sieci, a pozostałe są używane przez maszyny wirtualne dzierżawy. Z 31 adresów 8 publicznych adresów IP jest używanych dla małego zestawu usług Azure Stack Hub. Jeśli planujesz używać App Service i dostawców zasobów SQL, są używane kolejne 7 adresów. Pozostałe 16 adresów IP jest zarezerwowanych dla przyszłych usług platformy Azure. /26 (62 hosty) — /22 (hosty 1022)

Zalecane = /24 (254 hosty)
Przełączanie infrastruktury Adresy IP typu punkt-punkt na potrzeby routingu, dedykowane interfejsy zarządzania przełącznikami i adresy sprzężenia zwrotnego przypisane do przełącznika. /26
Infrastruktura Używany do komunikacji między składnikami wewnętrznymi usługi Azure Stack Hub. /24
Prywatne Służy do obsługi sieci magazynu, prywatnych adresów VIP, kontenerów infrastruktury i innych funkcji wewnętrznych. Aby uzyskać więcej informacji, zapoznaj się z sekcją Sieć prywatna w tym artykule. /20
Kontroler zarządzania płytą główną Służy do komunikowania się z kontrolerami BMC na hostach fizycznych. /26

Uwaga

Alert w portalu przypomni operatorowi uruchomienie polecenia cmdlet PEP Set-AzsPrivateNetwork w celu dodania nowego miejsca na prywatny adres IP /20. Aby uzyskać więcej informacji i wskazówki dotyczące wybierania /20 prywatnej przestrzeni IP, zobacz sekcję Sieć prywatna w tym artykule.

Infrastruktura sieciowa

Infrastruktura sieciowa usługi Azure Stack Hub składa się z kilku sieci logicznych skonfigurowanych na przełącznikach. Na poniższym diagramie przedstawiono te sieci logiczne i sposób ich integracji z przełącznikami tor (top-of-rack), kontrolerem zarządzania płytą główną (BMC) i przełącznikami granicznymi (sieć klienta).

Logical network diagram and switch connections

Sieć BMC

Ta sieć jest przeznaczona do łączenia wszystkich kontrolerów zarządzania płytą główną (nazywanych również procesorami BMC lub procesorami usług) z siecią zarządzania. Przykłady obejmują: iDRAC, iLO, iBMC itd. Tylko jedno konto BMC służy do komunikowania się z dowolnym węzłem kontrolera BMC. Jeśli jest obecny, host cyklu życia sprzętu (HLH) znajduje się w tej sieci i może zapewnić oprogramowanie specyficzne dla producenta OEM do konserwacji sprzętu lub monitorowania.

HLH hostuje również maszynę wirtualną wdrażania (DVM). DvM jest używany podczas wdrażania usługi Azure Stack Hub i jest usuwany po zakończeniu wdrażania. DvM wymaga dostępu do Internetu w scenariuszach wdrażania połączonych w celu testowania, weryfikowania i uzyskiwania dostępu do wielu składników. Te składniki mogą znajdować się wewnątrz i poza siecią firmową (na przykład NTP, DNS i Azure). Aby uzyskać więcej informacji na temat wymagań dotyczących łączności, zobacz sekcję NAT w temacie Integracja zapory usługi Azure Stack Hub.

Sieć prywatna

Ta sieć /20 (4096 adresów IP) jest prywatna w regionie usługi Azure Stack Hub (nie jest kierowana poza urządzenia przełącznika granicznego systemu Azure Stack Hub) i jest podzielona na wiele podsieci. Oto kilka przykładów:

  • sieć Storage: sieć /25 (128 adresów IP) używana do obsługi ruchu magazynu bezpośrednich miejsc i bloku komunikatów serwera (SMB) i migracji na żywo maszyny wirtualnej.
  • Wewnętrzna wirtualna sieć IP: sieć /25 przeznaczona dla adresów VIP tylko wewnętrznych dla programowego modułu równoważenia obciążenia.
  • Sieć kontenerów: sieć /23 (512 adresów IP) dedykowana dla ruchu tylko wewnętrznego między kontenerami z uruchomionymi usługami infrastruktury.

System Azure Stack Hub wymaga dodatkowej wewnętrznej przestrzeni IP /20. Ta sieć będzie prywatna dla systemu Azure Stack Hub (nie wykracza poza urządzenia przełącznika granicznego systemu Azure Stack Hub) i może zostać ponownie użyta w wielu systemach usługi Azure Stack Hub w centrum danych. Sieć jest prywatna dla usługi Azure Stack, ale nie może nakładać się na inne sieci w centrum danych. Prywatna przestrzeń IP /20 jest podzielona na wiele sieci, które umożliwiają uruchamianie infrastruktury usługi Azure Stack Hub w kontenerach. Ponadto ta nowa prywatna przestrzeń ADRESÓW IP umożliwia ciągłe wysiłki w celu zmniejszenia wymaganego routingu przestrzeni ADRESÓW IP przed wdrożeniem. Celem uruchomienia infrastruktury usługi Azure Stack Hub w kontenerach jest zoptymalizowanie wykorzystania i zwiększenie wydajności. Ponadto /20 prywatna przestrzeń IP jest również używana do umożliwienia bieżących wysiłków, które zmniejszy wymagane przestrzeń routingu IP przed wdrożeniem. Aby uzyskać wskazówki dotyczące prywatnej przestrzeni ADRESÓW IP, zalecamy stosowanie specyfikacji RFC 1918.

W przypadku systemów wdrożonych przed 1910 r. ta podsieć /20 będzie dodatkową siecią, która zostanie wprowadzona do systemów po aktualizacji do wersji 1910. Dodatkową sieć należy udostępnić systemowi za pomocą polecenia cmdlet Set-AzsPrivateNetwork PEP.

Uwaga

Dane wejściowe /20 służą jako warunek wstępny do następnej aktualizacji usługi Azure Stack Hub po 1910 roku. Po następnej aktualizacji usługi Azure Stack Hub po wersji 1910 i próbie jej zainstalowania aktualizacja zakończy się niepowodzeniem, jeśli dane wejściowe /20 nie zostały ukończone zgodnie z opisem w krokach korygowania w następujący sposób. Alert będzie obecny w portalu administratora do czasu ukończenia powyższych kroków korygowania. Zapoznaj się z artykułem Dotyczącym integracji sieci centrum danych , aby dowiedzieć się, w jaki sposób będzie używane nowe miejsce prywatne.

Kroki korygowania: Aby skorygować problem, postępuj zgodnie z instrukcjami, aby otworzyć sesję PEP. Przygotuj prywatny wewnętrzny zakres adresów IP o rozmiarze /20 i uruchom następujące polecenie cmdlet w sesji PEP przy użyciu następującego przykładu: Set-AzsPrivateNetwork -UserSubnet 10.87.0.0/20. Jeśli operacja zostanie wykonana pomyślnie, zostanie wyświetlony komunikat Azs Internal Network range added to the config (Zakres sieci wewnętrznej Azs dodany do konfiguracji). Po pomyślnym zakończeniu alert zostanie zamknięty w portalu administratora. System usługi Azure Stack Hub może teraz zostać zaktualizowany do następnej wersji.

Sieć infrastruktury usługi Azure Stack Hub

Ta sieć /24 jest przeznaczona dla wewnętrznych składników usługi Azure Stack Hub, dzięki czemu mogą komunikować się i wymieniać między sobą dane. Ta podsieć może być routingu zewnętrznego rozwiązania Usługi Azure Stack Hub do centrum danych. Nie zalecamy używania adresów IP routingu publicznego lub internetowego w tej podsieci. Ta sieć jest anonsowana do obramowania, ale większość jej adresów IP jest chroniona przez listy Access Control (ACL). Adresy IP dozwolone do uzyskania dostępu znajdują się w małym zakresie odpowiadającym rozmiarowi sieci /27 i usługom hosta, takich jak uprzywilejowany punkt końcowy (PEP) i kopia zapasowa usługi Azure Stack Hub.

Sieć publicznych adresów VIP

Sieć publicznych adresów VIP jest przypisana do kontrolera sieci w usłudze Azure Stack. Nie jest to sieć logiczna na przełączniku. SLB używa puli adresów i przypisuje /32 sieci dla obciążeń dzierżawy. W tabeli routingu przełącznika te adresy IP /32 są anonsowane jako dostępna trasa za pośrednictwem protokołu BGP. Ta sieć zawiera adresy IP dostępne zewnętrznie lub publiczne. Infrastruktura usługi Azure Stack Hub rezerwuje pierwsze 31 adresów z tej publicznej sieci VIP, podczas gdy pozostałe są używane przez maszyny wirtualne dzierżawy. Rozmiar sieci w tej podsieci może mieścić się w zakresie od co najmniej /26 (64 hostów) do maksymalnie /22 (1022 hostów). Zalecamy zaplanowanie sieci /24.

Nawiązywanie połączenia z sieciami lokalnymi

Usługa Azure Stack Hub używa sieci wirtualnych do obsługi zasobów klientów, takich jak maszyny wirtualne, moduły równoważenia obciążenia i inne.

Istnieje kilka różnych opcji nawiązywania połączenia z zasobów wewnątrz sieci wirtualnej z zasobami lokalnymi/firmowymi:

  • Użyj publicznych adresów IP z sieci publicznych adresów VIP.
  • Użyj bramy Virtual Network lub wirtualnego urządzenia sieciowego (WUS).

Gdy tunel S2S sieci VPN jest używany do łączenia zasobów z sieciami lokalnymi lub z nich, może wystąpić scenariusz, w którym zasób ma również przypisany publiczny adres IP i nie jest już dostępny za pośrednictwem tego publicznego adresu IP. Jeśli źródło próbuje uzyskać dostęp do publicznego adresu IP należy do tego samego zakresu podsieci zdefiniowanego w trasach bramy sieci lokalnej (Virtual Network Gateway) lub trasie zdefiniowanej przez użytkownika dla rozwiązań WUS, usługa Azure Stack Hub próbuje kierować ruch wychodzący z powrotem do źródła za pośrednictwem tunelu S2S na podstawie skonfigurowanych reguł routingu. Ruch powrotny używa prywatnego adresu IP maszyny wirtualnej, a nie źródłowego adresu NATed jako publicznego adresu IP:

Route traffic

Istnieją dwa rozwiązania tego problemu:

  • Kierowanie ruchu kierowanego do publicznej sieci VIP do Internetu.
  • Dodaj urządzenie translatora adresów sieciowych do translatora adresów SIECIowych dowolnego adresu IP podsieci zdefiniowanego w bramie sieci lokalnej skierowanej do sieci publicznych adresów VIP.

Route traffic solution

Przełączanie sieci infrastruktury

Ta sieć /26 jest podsiecią, która zawiera routingowy adres IP /30 (dwa adresy IP hosta) i sprzężenia zwrotne, które są dedykowane /32 podsieci do zarządzania przełącznikiem w pasmie i identyfikator routera BGP. Ten zakres adresów IP musi być routingiem poza rozwiązaniem usługi Azure Stack Hub do centrum danych. Mogą to być prywatne lub publiczne adresy IP.

Przełączanie sieci zarządzania

Ta sieć /29 (sześć adresów IP hosta) jest przeznaczona do łączenia portów zarządzania przełączników. Umożliwia dostęp poza pasmem na potrzeby wdrażania, zarządzania i rozwiązywania problemów. Jest on obliczany na podstawie sieci infrastruktury przełącznika wymienionej powyżej.

Dozwolone sieci

Arkusz wdrażania zawiera pole umożliwiające operatorowi zmianę listy kontroli dostępu (ACL) w celu umożliwienia dostępu do interfejsów zarządzania urządzeniami sieciowymi i hosta cyklu życia sprzętu (HLH) z zaufanego zakresu sieci centrum danych. Po zmianie listy kontroli dostępu operator może zezwolić swoim maszynom wirtualnym serwera przesiadkowego zarządzania w określonym zakresie sieci na dostęp do interfejsu zarządzania przełącznikiem, systemu OPERACYJNEGO HLH i kontrolera BMC HLH. Operator może podać jedną lub wiele podsieci do tej listy, jeśli pole pozostanie puste, będzie domyślnie blokować dostęp. Ta nowa funkcja zastępuje potrzebę ręcznej interwencji po wdrożeniu, ponieważ została opisana w temacie Modyfikowanie określonych ustawień w konfiguracji przełącznika usługi Azure Stack Hub.

Następne kroki