Planowanie integracji sieci dla usługi Azure Stack Hub

Ten artykuł zawiera informacje o infrastrukturze sieciowej usługi Azure Stack Hub, które ułatwiają podjęcie decyzji o tym, jak najlepiej zintegrować usługę Azure Stack Hub z istniejącym środowiskiem sieciowym.

Notatka

Aby rozpoznać zewnętrzne nazwy DNS z usługi Azure Stack Hub (na przykład www.bing.com), należy podać serwery DNS, do których mają być przekazywane żądania 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ć Azure Stack Hub z siecią, potrzebne są łącza z przełączników Top-of-Rack (ToR) do najbliższego przełącznika lub routera, który w tym artykule jest określany jako Border. Przełączniki z górnej części szafy można podłączyć do jednego lub pary routerów brzegowych. ToR jest wstępnie skonfigurowany przez nasze narzędzie automatyzacji. Oczekuje co najmniej jednego połączenia między tor i obramowaniem w przypadku korzystania z routingu BGP i co najmniej dwóch połączeń (jeden na toR) między tor i obramowaniem w przypadku korzystania z routingu statycznego, z maksymalnie czterema połączeniami w obu opcjach routingu. Te połączenia są ograniczone do modułów SFP+ lub SFP28 i muszą mieć minimalną prędkość co najmniej jednego GB. Aby uzyskać dostępność, zapoznaj się z dostawcą sprzętu producenta oryginalnego sprzętu (OEM). Na poniższym diagramie przedstawiono zalecany projekt:

Alokacja przepustowości

Usługa Azure Stack Hub jest tworzona przy użyciu technologii klastra trybu failover systemu Windows Server 2019 i technologii Spaces Direct. Aby zapewnić, że komunikacja magazynowa Spaces Direct może spełniać wymagania dotyczące wydajności i skali wymaganej przez rozwiązanie, część konfiguracji sieci fizycznej usługi Azure Stack Hub jest skonfigurowana do stosowania separacji ruchu i gwarancji przepustowości. Konfiguracja sieci używa klas ruchu do oddzielenia komunikacji Spaces Direct opartej na RDMA od korzystania z sieci przez infrastrukturę Azure Stack Hub i/lub dzierżawców. Aby dostosować się do bieżących najlepszych rozwiązań zdefiniowanych dla systemu Windows Server 2019, usługa Azure Stack Hub zmienia się, aby używać dodatkowej klasy ruchu lub priorytetu, aby dodatkowo oddzielić komunikację serwera z serwerem w celu obsługi komunikacji z klastrem trybu failover. Ta nowa definicja klasy ruchu jest 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 i na hoście lub serwerach usługi Azure Stack Hub. Należy pamiętać, że zmiany nie są wymagane na urządzeniach granicznych sieci 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 rezultacie komunikaty kontroli klastra trybu failover są zakłócane. Należy pamiętać, że komunikacja klastra przełączania awaryjnego jest krytycznym elementem infrastruktury Azure Stack Hub. W przypadku długotrwałego zakłócenia może prowadzić do niestabilności w usługach przechowywania Direct Spaces lub innych usługach, co ostatecznie wpłynie na stabilność obciążeń dzierżawców lub użytkowników końcowych.

Sieci logiczne

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

W poniższej tabeli przedstawiono sieci logiczne i skojarzone zakresy podsieci IPv4, które musisz uwzględnić w planowaniu.

Sieć logiczna	Opis	Rozmiar
Publiczny VIP	Usługa Azure Stack Hub używa łącznie 31 adresów z tej sieci, a pozostałe są używane przez dzierżawione VM-y. 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ć usługi App Service i dostawców zasobów SQL, są używane kolejne 7 adresów. Pozostałe 16 adresów IP są zarezerwowane dla przyszłych usług platformy Azure.	/26 (62 hostów) — /22 (1022 hostów) Zalecane = /24 (254 hostów)
Infrastruktura przełącznikowa	Adresy IP typu punkt-punkt, na potrzeby routingu, dedykowane interfejsy zarządzania przełącznikami oraz adresy loopback przypisane do przełącznika.	/26
Infrastruktura	Używany do komunikacji składników wewnętrznych usługi Azure Stack Hub.	/24
Prywatny	Wykorzystanie dla sieci pamięci masowej, prywatnych VIP-ów, kontenerów infrastruktury i innych funkcji wewnętrznych. Aby uzyskać więcej informacji, zapoznaj się z sekcją sieci prywatnej w tym artykule.	/20
BMC	Służy do komunikowania się z BMC na hostach fizycznych.	/26

Notatka

Alert w portalu przypomina operatorowi uruchomienie polecenia cmdlet PEP Set-AzsPrivateNetwork, aby dodać nową prywatną przestrzeń IP /20. Aby uzyskać więcej informacji i wskazówek dotyczących wybierania /20 prywatnej przestrzeni IP, sprawdź sekcję Private network 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 oraz ich integrację z przełącznikami top-of-rack (TOR), kontrolerem zarządzania płytą główną (BMC) i przełącznikami brzegowymi (sieć klienta).

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 to: iDRAC, iLO, iBMC itd. Tylko jedno konto BMC służy do komunikowania się z dowolnym węzłem BMC. Jeśli istnieje, 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, aby przetestować, zweryfikować i uzyskać dostęp 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 integracji zapory Azure Stack Hub.

Sieć prywatna

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

• sieć magazynu: sieć /25 (128 adresów IP) używana do obsługi korzystania z Spaces Direct, ruchu pamięci masowej SMB (Server Message Block) i migracji na żywo maszyn wirtualnych.
• wewnętrzna sieć wirtualna IP: sieć /25 dedykowana tylko wewnętrznym adresom VIP dla programowego modułu równoważenia obciążenia.
• Sieć kontenerowa: sieć /23 (512 adresów IP) przeznaczona dla ruchu tylko wewnętrznego między kontenerami z uruchomionymi usługami infrastruktury.

System Azure Stack Hub wymaga dodatkowej przestrzeni adresowej /20 dla prywatnych, wewnętrznych adresów IP. Ta sieć jest prywatna dla systemu Azure Stack Hub (nie wykracza poza urządzenia przełącznika granicznego systemu Azure Stack Hub) i może być 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 dalsze działania na rzecz zmniejszenia wymaganej adresowalnej przestrzeni IP przed wdrożeniem. Celem uruchomienia infrastruktury usługi Azure Stack Hub w kontenerach jest zoptymalizowanie wykorzystania i zwiększenie wydajności. Ponadto zakres prywatnych adresów IP /20 jest również używany do wspierania bieżących działań zmierzających do zmniejszenia wymaganej przestrzeni routowalnych adresów IP przed wdrożeniem. Aby uzyskać wskazówki dotyczące prywatnej przestrzeni IP, zobacz RFC 1918.

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ć routowalna zewnętrznie z Azure Stack Hub do twojego centrum danych. Nie zalecamy używania publicznych lub internetowych routingowych adresów IP w tej podsieci. Ta sieć jest reklamowana do granicy, ale większość jej adresów IP jest chroniona przez zasady kontroli dostępu (ACL). Adresy IP dozwolone do uzyskania dostępu znajdują się w małym zakresie, co odpowiada rozmiarowi sieci /27 i usługom hosta, takim jak uprzywilejowany punkt końcowy (PEP) i kopii zapasowej usługi Azure Stack Hub.

Publiczna sieć VIP

Sieć publiczna VIP jest przypisywana do kontrolera sieci w Azure Stack. Nie jest to sieć logiczna na przełączniku. SLB używa puli adresów i przypisuje sieci /32 dla obciążeń użytkowników. W tabeli routingu przełącznika adresy IP /32 są anonsowane jako dostępna trasa za pośrednictwem protokołu BGP. Ta sieć zawiera zewnętrzne lub publiczne adresy IP. Infrastruktura Azure Stack Hub rezerwuje pierwsze 31 adresów z tej publicznej sieci adresów VIP, podczas gdy pozostała część jest wykorzystywana przez dzierżawców. Rozmiar sieci w tej podsieci może wahać się od co najmniej /26 (64 hostów) do maksymalnej liczby /22 (1022 hostów). Zalecamy zaplanowanie sieci o prefiksie /24.

Nawiązywanie połączenia z sieciami lokalnymi

Usługa Azure Stack Hub używa sieci wirtualnych dla 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 publicznej sieci adresów VIP.
• Użyj bramy sieciowej wirtualnej lub wirtualnego urządzenia sieciowego (NVA).

Gdy tunel VPN typu S2S jest używany do łączenia zasobów z sieciami lokalnymi, może wystąpić sytuacja, w której zasób ma również przypisany publiczny adres IP i nie będzie już osiągalny za pośrednictwem tego publicznego adresu IP. Jeśli źródło próbuje uzyskać dostęp do publicznego adresu IP i znajduje się w tym samym zakresie podsieci zdefiniowanym w trasach bramy sieci lokalnej (brama sieci wirtualnej) lub w trasach zdefiniowanych przez użytkownika dla rozwiązań NVA (wirtualne urządzenie sieciowe), Azure Stack Hub próbuje przesyłać ruch wychodzący z powrotem do źródła przez tunel S2S na podstawie skonfigurowanych reguł routingu. Ruch powrotny używa prywatnego adresu IP maszyny wirtualnej, zamiast być przetwarzany jako publiczny adres IP przez NAT.

Istnieją dwa rozwiązania tego problemu:

• Kierowanie ruchu kierowanego do publicznej sieci VIP do Internetu.
• Dodaj urządzenie NAT do translacji dowolnych adresów IP podsieci zdefiniowanych w bramie sieci lokalnej, kierowanych do publicznej sieci VIP.

Przełączanie sieci infrastruktury

Ta sieć /26 jest podsiecią zawierającą routowalne punkt-punkt IP /30 podsieci (dwa adresy IP hosta) oraz adresy zwrotne, które są dedykowane /32 podsieciom do zarządzania przełącznikiem w paśmie oraz identyfikatora routera BGP. Ten zakres adresów IP musi być routowalny poza rozwiązaniem Azure Stack Hub do centrum danych. Mogą to być prywatne lub publiczne adresy IP.

Sieć zarządzania przełącznikami

Ta sieć /29 (sześć adresów IP hosta) jest dedykowana 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. Oblicza się to na podstawie wcześniej wspomnianej sieci infrastruktury przełączników.

Dozwolone sieci

Arkusz instalacyjny zawiera pole umożliwiające operatorowi zmianę niektórych list kontroli dostępu, aby umożliwić dostęp do interfejsów zarządzania urządzeniami sieciowymi i hosta zarządzania cyklem życia sprzętu (HLH) z zakresu sieci zaufanego centrum danych. Po zmianie listy kontroli dostępu operator może zezwolić na to, aby maszyny wirtualne przesiadkowe w określonym zakresie sieci miały dostęp do interfejsu zarządzania przełącznikiem i systemu operacyjnego HLH. Operator może podać jedną lub wiele podsieci do tej listy; jeśli pole pozostanie puste, domyślnie odmawia dostępu. Ta nowa funkcja eliminuje konieczność ręcznej interwencji po wdrożeniu, co było wcześniej opisywane w Modyfikowanie określonych ustawień w konfiguracji przełącznika w usłudze Azure Stack Hub.

Następne kroki

• Routing ruchu sieci wirtualnej
• Dowiedz się więcej o planowaniu sieci: łączność przygraniczna