Zagadnienia dotyczące sieci dla wdrożeń w chmurze usługi Azure Stack HCI w wersji 23H2

Dotyczy: Azure Stack HCI, wersja 23H2

W tym artykule omówiono sposób projektowania i planowania sieci systemowej usługi Azure Stack HCI w wersji 23H2 na potrzeby wdrożenia w chmurze. Przed kontynuowaniem zapoznaj się z różnymi wzorcami sieci rozwiązania Azure Stack HCI i dostępnymi konfiguracjami.

Struktura projektowania sieci

Na poniższym diagramie przedstawiono różne decyzje i kroki definiujące strukturę projektowania sieci dla systemu Azure Stack HCI — rozmiar klastra, łączność magazynu klastra, intencje ruchu sieciowego, łączność zarządzania i konfiguracja karty sieciowej. Każda decyzja projektowa włącza lub zezwala na opcje projektowania dostępne w kolejnych krokach:

Krok 1. Określanie rozmiaru klastra

Aby określić rozmiar systemu Azure Stack HCI, użyj narzędzia azure Stack HCI sizer, w którym można zdefiniować profil, taki jak liczba maszyn wirtualnych, rozmiar maszyn wirtualnych i użycie obciążenia maszyn wirtualnych, takich jak azure Virtual Desktop, SQL Server lub AKS.

Zgodnie z opisem w artykule Azure Stack HCI system server requirements (Wymagania dotyczące serwera systemowego usługi Azure Stack HCI) maksymalna liczba serwerów obsługiwanych w systemie Azure Stack HCI wynosi 16. Po zakończeniu planowania pojemności obciążenia należy dobrze zrozumieć liczbę węzłów serwera wymaganych do uruchamiania obciążeń w infrastrukturze.

• Jeśli obciążenia wymagają co najmniej czterech węzłów: nie można wdrożyć i użyć konfiguracji bez przełącznika dla ruchu sieciowego magazynu. Aby obsługiwać ruch magazynu, należy dołączyć przełącznik fizyczny z obsługą zdalnego bezpośredniego dostępu do pamięci (RDMA). Aby uzyskać więcej informacji na temat architektury sieci klastra usługi Azure Stack HCI, zobacz Omówienie wzorców referencyjnych sieci.

• Jeśli obciążenia wymagają co najmniej trzech węzłów: możesz wybrać konfiguracje bez przełącznika lub przełącznika na potrzeby łączności z magazynem.

• Jeśli planujesz skalowanie w poziomie później do więcej niż trzech węzłów: musisz użyć przełącznika fizycznego dla ruchu sieciowego magazynu. Każda operacja skalowania w poziomie dla wdrożeń bez przełączników wymaga ręcznej konfiguracji okablowania sieci między węzłami, które firma Microsoft nie waliduje aktywnie w ramach cyklu tworzenia oprogramowania dla usługi Azure Stack HCI.

Poniżej przedstawiono podsumowanie zagadnień dotyczących decyzji o rozmiarze klastra:

Decyzja	Kwestie do rozważenia
Rozmiar klastra (liczba węzłów na klaster)	Konfiguracja bez przełącznika za pośrednictwem szablonów Azure Portal lub Azure Resource Manager jest dostępna tylko dla klastrów 1, 2 lub 3 węzłów. Klastry z co najmniej 4 węzłami wymagają przełącznika fizycznego dla ruchu sieciowego magazynu.
Wymagania dotyczące skalowania w poziomie	Jeśli zamierzasz skalować klaster w poziomie przy użyciu orkiestratora, musisz użyć przełącznika fizycznego dla ruchu sieciowego magazynu.

Krok 2. Określanie łączności magazynu klastra

Zgodnie z opisem w temacie Wymagania dotyczące sieci fizycznej usługa Azure Stack HCI obsługuje dwa typy łączności dla ruchu sieciowego magazynu:

• Użyj przełącznika sieci fizycznej, aby obsłużyć ruch.
• Bezpośrednie łączenie węzłów między nimi za pomocą sieci krzyżowej lub kabli światłowodowych dla ruchu magazynu.

Zalety i wady każdej opcji zostały opisane w powyższym artykule.

Jak wspomniano wcześniej, można zdecydować tylko między dwiema opcjami, gdy rozmiar klastra wynosi co najmniej trzy węzły. Każdy klaster z co najmniej czterema węzłami jest automatycznie wdrażany przy użyciu przełącznika sieciowego dla magazynu.

Jeśli klastry mają mniej niż trzy węzły, decyzja o łączności magazynu wpływa na liczbę i typ intencji sieci, które można zdefiniować w następnym kroku.

Na przykład w przypadku konfiguracji bez przełączników należy zdefiniować dwie intencje ruchu sieciowego. Ruch magazynu dla komunikacji wschód-zachód przy użyciu kabli crossover nie ma łączności północno-południowej i jest całkowicie odizolowany od pozostałej części infrastruktury sieciowej. Oznacza to, że należy zdefiniować drugą intencję sieci na potrzeby zarządzania łącznością wychodzącą i obciążeń obliczeniowych.

Chociaż można zdefiniować każdą intencję sieci z tylko jednym fizycznym portem karty sieciowej, nie zapewnia to żadnej odporności na uszkodzenia. W związku z tym zawsze zalecamy używanie co najmniej dwóch fizycznych portów sieciowych dla każdej intencji sieciowej. Jeśli zdecydujesz się użyć przełącznika sieciowego do magazynowania, możesz zgrupować cały ruch sieciowy, w tym magazyn w jednej intencji sieciowej, który jest również znany jako hiperkonwergentna lub w pełni konwergentna konfiguracja sieci hosta.

Poniżej przedstawiono podsumowanie zagadnień dotyczących decyzji o łączności z magazynem klastra:

Decyzja	Kwestie do rozważenia
Brak przełącznika dla magazynu	Konfiguracja bez przełącznika za pośrednictwem wdrożenia szablonu Azure Portal lub Resource Manager jest obsługiwana tylko w przypadku klastrów 1, 2 lub 3 węzłów. Klastry bez przełącznika magazynu 1 lub 2 węzłów można wdrożyć przy użyciu szablonów Azure Portal lub Resource Manager. Klastry bez przełączników magazynu z 3 węzłami można wdrażać tylko przy użyciu szablonów Resource Manager. Operacje skalowania w poziomie nie są obsługiwane w przypadku wdrożeń bez przełączników. Każda zmiana liczby węzłów po wdrożeniu wymaga ręcznej konfiguracji. Co najmniej 2 intencje sieciowe są wymagane w przypadku korzystania z konfiguracji bez przełącznika magazynu.
Przełącznik sieciowy dla magazynu	Jeśli zamierzasz skalować klaster w poziomie przy użyciu orkiestratora, musisz użyć przełącznika fizycznego dla ruchu sieciowego magazynu. Tej architektury można używać z dowolną liczbą węzłów z zakresu od 1 do 16. Mimo że nie jest wymuszana, można użyć jednej intencji dla wszystkich typów ruchu sieciowego (zarządzanie, obliczenia i magazyn)

Na poniższym diagramie przedstawiono podsumowanie dostępnych opcji łączności magazynu dla różnych wdrożeń:

Krok 3. Określanie intencji ruchu sieciowego

W przypadku usługi Azure Stack HCI wszystkie wdrożenia korzystają z usługi Network ATC dla konfiguracji sieci hosta. Intencje sieci są konfigurowane automatycznie podczas wdrażania rozwiązania Azure Stack HCI za pośrednictwem Azure Portal. Aby dowiedzieć się więcej na temat intencji sieci i sposobu ich rozwiązywania, zobacz Typowe polecenia usługi ATC sieci.

W tej sekcji opisano konsekwencje decyzji projektowej dotyczącej intencji ruchu sieciowego oraz wpływ na następny krok struktury. W przypadku wdrożeń w chmurze można wybrać między czterema opcjami grupowania ruchu sieciowego w co najmniej jedną intencję. Dostępne opcje zależą od liczby węzłów w klastrze i używanego typu łączności magazynu.

Dostępne opcje intencji sieci zostały omówione w poniższych sekcjach.

Intencja sieci: grupowanie całego ruchu

Usługa Network ATC konfiguruje unikatową intencję obejmującą zarządzanie, obliczenia i ruch sieciowy magazynu. Karty sieciowe przypisane do tej intencji współdzielą przepustowość i przepływność dla całego ruchu sieciowego.

• Ta opcja wymaga przełącznika fizycznego dla ruchu magazynu. Jeśli potrzebujesz architektury bez przełącznika, nie możesz użyć tego typu intencji. Azure Portal automatycznie filtruje tę opcję, jeśli wybierzesz konfigurację bez przełącznika na potrzeby łączności z magazynem.

• Co najmniej dwa porty karty sieciowej są zalecane w celu zapewnienia wysokiej dostępności.

• Co najmniej 10 Gb/s interfejsy sieciowe są wymagane do obsługi ruchu RDMA dla magazynu.

Intencja sieci: zarządzanie grupami i ruch obliczeniowy

Usługa Network ATC konfiguruje dwie intencje. Pierwsza intencja obejmuje ruch sieciowy związany z zarządzaniem i obliczeniami, a druga intencja obejmuje tylko ruch sieciowy magazynu. Każda intencja musi mieć inny zestaw portów karty sieciowej.

Tej opcji można użyć zarówno w przypadku łączności magazynu przełączonego, jak i bez przełącznika, jeśli:

• Co najmniej dwa porty karty sieciowej są dostępne dla każdej intencji w celu zapewnienia wysokiej dostępności.

• Przełącznik fizyczny jest używany dla funkcji RDMA, jeśli używasz przełącznika sieciowego do przechowywania.

• Co najmniej 10 Gb/s interfejsy sieciowe są wymagane do obsługi ruchu RDMA dla magazynu.

Intencja sieci: grupowanie ruchu obliczeniowego i magazynu

Usługa Network ATC konfiguruje dwie intencje. Pierwsza intencja obejmuje ruch sieciowy obliczeniowy i magazynowy, a druga intencja obejmuje tylko ruch sieciowy zarządzania. Każda intencja musi używać innego zestawu portów karty sieciowej.

• Ta opcja wymaga przełącznika fizycznego dla ruchu magazynu co te same porty są współużytkowane z ruchem obliczeniowym, co wymaga komunikacji między północą a południem. Jeśli potrzebujesz konfiguracji bez przełącznika, nie możesz użyć tego typu intencji. Azure Portal automatycznie filtruje tę opcję, jeśli wybierzesz konfigurację bez przełącznika na potrzeby łączności z magazynem.

• Ta opcja wymaga przełącznika fizycznego dla funkcji RDMA.

• Co najmniej dwa porty karty sieciowej są zalecane w celu zapewnienia wysokiej dostępności.

• Interfejsy sieciowe o przepustowości co najmniej 10 Gb/s są zalecane dla intencji obliczeniowej i magazynu do obsługi ruchu RDMA.

• Nawet jeśli intencja zarządzania jest zadeklarowana bez intencji obliczeniowej, usługa Network ATC tworzy przełącznik wirtualny Switch Embedded Teaming (SET), aby zapewnić wysoką dostępność sieci zarządzania.

Intencja sieci: konfiguracja niestandardowa

Zdefiniuj maksymalnie trzy intencje przy użyciu własnej konfiguracji, o ile co najmniej jedna z intencji obejmuje ruch zarządzania. Zalecamy użycie tej opcji, jeśli potrzebujesz drugiej intencji obliczeniowej. Scenariusze dotyczące tego drugiego wymagania dotyczącego intencji obliczeniowej obejmują ruch magazynu zdalnego, ruch kopii zapasowych maszyn wirtualnych lub oddzielną intencję obliczeniową dla różnych typów obciążeń.

• Użyj tej opcji zarówno w przypadku łączności magazynu przełączonego, jak i bez przełącznika, jeśli intencja magazynu różni się od innych intencji.

• Użyj tej opcji, jeśli jest wymagana inna intencja obliczeniowa lub gdy chcesz w pełni oddzielić różne typy ruchu przez różne karty sieciowe.

• Użyj co najmniej dwóch portów karty sieciowej dla każdej intencji, aby zapewnić wysoką dostępność.

• Interfejsy sieciowe o przepustowości co najmniej 10 Gb/s są zalecane dla intencji obliczeniowej i magazynu do obsługi ruchu RDMA.

Na poniższym diagramie przedstawiono podsumowanie opcji intencji sieci dostępnych dla różnych wdrożeń:

Krok 4. Określanie łączności sieciowej zarządzania

W tym kroku zdefiniujesz przestrzeń adresową podsieci infrastruktury, sposób przypisania tych adresów do klastra, a jeśli istnieją jakiekolwiek wymagania dotyczące serwera proxy lub identyfikatora sieci VLAN dla węzłów dla łączności wychodzącej z Internetem i innych usług intranetowych, takich jak system nazw domen (DNS) lub usługi Active Directory.

Przed rozpoczęciem wdrażania należy zaplanować i zdefiniować następujące składniki podsieci infrastruktury, aby można było przewidzieć wymagania dotyczące routingu, zapory lub podsieci.

Sterowniki kart sieciowych

Po zainstalowaniu systemu operacyjnego i przed skonfigurowaniem sieci w węzłach należy upewnić się, że karty sieciowe mają najnowszy sterownik dostarczony przez producenta OEM lub dostawcę interfejsu sieciowego. W przypadku korzystania z domyślnych sterowników firmy Microsoft ważne możliwości kart sieciowych mogą nie być udostępniane.

Pula adresów IP zarządzania

Podczas początkowego wdrażania systemu Azure Stack HCI należy zdefiniować zakres adresów IP kolejnych adresów IP dla usług infrastruktury wdrożonych domyślnie.

Aby zapewnić, że zakres ma wystarczającą liczbę adresów IP dla bieżących i przyszłych usług infrastruktury, należy użyć zakresu co najmniej sześciu kolejnych dostępnych adresów IP. Te adresy są używane dla — adresu IP klastra, maszyny wirtualnej mostka zasobów platformy Azure i jej składników.

Jeśli przewidujesz uruchamianie innych usług w sieci infrastruktury, zalecamy przypisanie dodatkowego buforu adresów IP infrastruktury do puli. Istnieje możliwość dodania innych pul adresów IP po wdrożeniu dla sieci infrastruktury przy użyciu programu PowerShell, jeśli rozmiar zaplanowanej puli zostanie wyczerpany.

Podczas definiowania puli adresów IP dla podsieci infrastruktury podczas wdrażania należy spełnić następujące warunki:

#	Warunek
1	Zakres adresów IP musi używać kolejnych adresów IP, a wszystkie adresy IP muszą być dostępne w tym zakresie.
2	Zakres adresów IP nie może zawierać adresów IP zarządzania węzłami klastra, ale musi znajdować się w tej samej podsieci co węzły.
3	Brama domyślna zdefiniowana dla puli adresów IP zarządzania musi zapewniać łączność wychodzącą z Internetem.
4	Serwery DNS muszą zapewnić rozpoznawanie nazw w usłudze Active Directory i Internecie.

Identyfikator sieci VLAN zarządzania

Zalecamy, aby podsieć zarządzania klastra usługi Azure HCI używała domyślnej sieci VLAN, która w większości przypadków jest zadeklarowana jako identyfikator sieci VLAN 0. Jeśli jednak wymagania sieciowe dotyczą używania określonej sieci VLAN zarządzania dla sieci infrastruktury, należy ją skonfigurować na fizycznych kartach sieciowych, które mają być używane do zarządzania ruchem.

Jeśli planujesz używać dwóch fizycznych kart sieciowych do zarządzania, musisz ustawić sieć VLAN na obu kartach. Należy to zrobić w ramach konfiguracji uruchamiania serwerów i przed zarejestrowaniem ich w usłudze Azure Arc, aby upewnić się, że węzły zostały pomyślnie zarejestrowane przy użyciu tej sieci VLAN.

Aby ustawić identyfikator sieci VLAN na fizycznych kartach sieciowych, użyj następującego polecenia programu PowerShell:

W tym przykładzie skonfigurowaliśmy identyfikator sieci VLAN 44 na fizycznej karcie NIC1sieciowej .

Set-NetAdapter -Name "NIC1" -VlanID 44

Po ustawieniu identyfikatora sieci VLAN i skonfigurowaniu adresów IP węzłów na fizycznych kartach sieciowych koordynator odczytuje tę wartość identyfikatora sieci VLAN z fizycznej karty sieciowej używanej do zarządzania i przechowuje ją, aby można było jej użyć dla maszyny wirtualnej mostka zasobów platformy Azure lub dowolnej innej maszyny wirtualnej infrastruktury wymaganej podczas wdrażania. Nie można ustawić identyfikatora sieci VLAN zarządzania podczas wdrażania w chmurze z Azure Portal, ponieważ wiąże się to z ryzykiem przerwania łączności między węzłami a platformą Azure, jeśli sieci VLAN przełącznika fizycznego nie są prawidłowo kierowane.

Identyfikator sieci VLAN zarządzania za pomocą przełącznika wirtualnego

W niektórych scenariuszach istnieje wymóg utworzenia przełącznika wirtualnego przed rozpoczęciem wdrażania.

Uwaga

Przed utworzeniem przełącznika wirtualnego upewnij się, że włączono rolę Hype-V. Aby uzyskać więcej informacji, zobacz Instalowanie wymaganej roli systemu Windows.

Jeśli wymagana jest konfiguracja przełącznika wirtualnego i musisz użyć określonego identyfikatora sieci VLAN, wykonaj następujące kroki:

1. Twórca przełącznik wirtualny z zalecaną konwencją nazewnictwa

Wdrożenia rozwiązania Azure Stack HCI opierają się na usłudze Network ATC do tworzenia i konfigurowania przełączników wirtualnych i wirtualnych kart sieciowych na potrzeby zarządzania, obliczeń i intencji magazynu. Domyślnie gdy usługa Network ATC tworzy przełącznik wirtualny dla intencji, używa określonej nazwy przełącznika wirtualnego.

Mimo że nie jest to wymagane, zalecamy nazewnictwo przełączników wirtualnych z tą samą konwencją nazewnictwa. Zalecana nazwa przełączników wirtualnych jest następująca:

• Nazwa przełącznika wirtualnego: "ConvergedSwitch($IntentName)", gdzie $IntentName może być dowolny ciąg. Ten ciąg powinien być zgodny z nazwą wirtualnej karty sieciowej do zarządzania zgodnie z opisem w następnym kroku.

W poniższym przykładzie pokazano, jak utworzyć przełącznik wirtualny przy użyciu programu PowerShell przy użyciu zalecanej konwencji nazewnictwa z opisem $IntentName przeznaczenia przełącznika wirtualnego. Lista nazw kart sieciowych to lista fizycznych kart sieciowych, które mają być używane do zarządzania i obliczeniowego ruchu sieciowego:

$IntentName = "MgmtCompute"
New-VMSwitch -Name "ConvergedSwitch($IntentName)" -NetAdapterName "NIC1","NIC2" -EnableEmbeddedTeaming $true -AllowManagementOS $false

2. Konfigurowanie wirtualnej karty sieciowej zarządzania przy użyciu wymaganej konwencji nazewnictwa usługi Network ATC dla wszystkich węzłów

Po skonfigurowaniu przełącznika wirtualnego należy utworzyć wirtualną kartę sieciową zarządzania. Nazwa wirtualnej karty sieciowej używanej dla ruchu zarządzania musi używać następującej konwencji nazewnictwa:

• Nazwa karty sieciowej i wirtualnej karty sieciowej: vManagement($intentname).
• W nazwie jest uwzględniana wielkość liter.
• $Intentname może być dowolnym ciągiem, ale musi mieć taką samą nazwę jak w przypadku przełącznika wirtualnego.

Aby zaktualizować nazwę wirtualnej karty sieciowej zarządzania, użyj następującego polecenia:

$IntentName = "MgmtCompute"
Add-VMNetworkAdapter -ManagementOS -SwitchName "ConvergedSwitch($IntentName)" -Name "vManagement($IntentName)"

#NetAdapter needs to be renamed because during creation, Hyper-V adds the string "vEthernet " to the beginning of the name

Rename-NetAdapter -Name "vEthernet (vManagement($IntentName))" -NewName "vManagement($IntentName)"

3. Skonfiguruj identyfikator sieci VLAN do zarządzania wirtualną kartą sieciową dla wszystkich węzłów

Po utworzeniu przełącznika wirtualnego i wirtualnej karty sieciowej zarządzania można określić wymagany identyfikator sieci VLAN dla tej karty. Chociaż istnieją różne opcje przypisywania identyfikatora sieci VLAN do wirtualnej karty sieciowej, jedyną obsługiwaną opcją jest użycie Set-VMNetworkAdapterIsolation polecenia .

Po skonfigurowaniu wymaganego identyfikatora sieci VLAN można przypisać adres IP i bramy do wirtualnej karty sieciowej zarządzania, aby sprawdzić, czy ma łączność z innymi węzłami, systemem DNS, usługą Active Directory i Internetem.

W poniższym przykładzie pokazano, jak skonfigurować wirtualną kartę sieciową zarządzania do używania identyfikatora sieci VLAN 8 zamiast domyślnego:

Set-VMNetworkAdapterIsolation -ManagementOS -VMNetworkAdapterName "vManagement($IntentName)" -AllowUntaggedTraffic $true -IsolationMode Vlan -DefaultIsolationID

4. Odwoływanie się do fizycznych kart sieciowych dla intencji zarządzania podczas wdrażania

Mimo że nowo utworzona wirtualna karta sieciowa jest wyświetlana jako dostępna podczas wdrażania za pośrednictwem Azure Portal, należy pamiętać, że konfiguracja sieci jest oparta na usłudze Network ATC. Oznacza to, że podczas konfigurowania zarządzania lub intencji zarządzania i obliczeń nadal musimy wybrać fizyczne karty sieciowe używane do tej intencji.

Uwaga

Nie wybieraj wirtualnej karty sieciowej dla intencji sieciowej.

Ta sama logika dotyczy szablonów usługi Azure Resource Manager. Należy określić fizyczne karty sieciowe, które mają być używane dla intencji sieciowych, a nigdy wirtualne karty sieciowe.

Poniżej przedstawiono podsumowanie zagadnień dotyczących identyfikatora sieci VLAN:

#	Zagadnienia do rozważenia
1	Przed zarejestrowaniem serwerów w usłudze Azure Arc należy określić identyfikator sieci VLAN na fizycznej karcie sieciowej do zarządzania.
2	Przed zarejestrowaniem serwerów w usłudze Azure Arc należy wykonać określone kroki, jeśli przełącznik wirtualny jest wymagany.
3	Identyfikator sieci VLAN zarządzania jest przenoszony z konfiguracji hosta do maszyn wirtualnych infrastruktury podczas wdrażania.
4	Brak parametru wejściowego identyfikatora sieci VLAN dla wdrożenia Azure Portal ani wdrożenia szablonu Resource Manager.

Przypisanie adresu IP węzła i klastra

W przypadku systemu Azure Stack HCI masz dwie opcje przypisywania adresów IP dla węzłów serwera i adresu IP klastra.

• Obsługiwane są zarówno protokoły statyczne, jak i protokół DHCP (Dynamic Host Configuration Protocol).

• Odpowiednie przypisanie adresu IP węzła jest kluczem do zarządzania cyklem życia klastra. Przed zarejestrowaniem węzłów w usłudze Azure Arc należy wybrać opcje statyczne i DHCP.

• Maszyny wirtualne i usługi infrastruktury, takie jak mostek zasobów usługi Arc i kontroler sieci, nadal korzystają ze statycznych adresów IP z puli adresów IP zarządzania. Oznacza to, że nawet jeśli zdecydujesz się użyć protokołu DHCP do przypisania adresów IP do węzłów i adresu IP klastra, pula adresów IP zarządzania jest nadal wymagana.

W poniższych sekcjach omówiono implikacje poszczególnych opcji.

Przypisanie statycznego adresu IP

Jeśli statyczne adresy IP są używane dla węzłów, pula adresów IP zarządzania służy do uzyskiwania dostępnego adresu IP i przypisywania go do adresu IP klastra automatycznie podczas wdrażania.

Ważne jest, aby używać adresów IP zarządzania dla węzłów, które nie są częścią zakresu adresów IP zdefiniowanego dla puli adresów IP zarządzania. Adresy IP węzła serwera muszą znajdować się w tej samej podsieci zdefiniowanego zakresu adresów IP.

Zalecamy przypisanie tylko jednego adresu IP zarządzania dla bramy domyślnej i skonfigurowanych serwerów DNS dla wszystkich fizycznych kart sieciowych węzła. Dzięki temu adres IP nie ulegnie zmianie po utworzeniu intencji sieci zarządzania. Gwarantuje to również, że węzły zachowają łączność wychodzącą podczas procesu wdrażania, w tym podczas rejestracji usługi Azure Arc.

Aby uniknąć problemów z routingiem i określić, który adres IP będzie używany do łączności wychodzącej i rejestracji usługi Arc, Azure Portal sprawdza, czy skonfigurowano więcej niż jedną bramę domyślną.

Jeśli podczas konfiguracji systemu operacyjnego utworzono przełącznik wirtualny i wirtualną kartę sieciową zarządzania, adres IP zarządzania węzła musi zostać przypisany do tej wirtualnej karty sieciowej.

Przypisanie adresu IP PROTOKOŁU DHCP

Jeśli adresy IP węzłów są uzyskiwane z serwera DHCP, dynamiczny adres IP jest również używany dla adresu IP klastra. Maszyny wirtualne i usługi infrastruktury nadal wymagają statycznych adresów IP i oznacza to, że zakres adresów puli adresów IP zarządzania musi zostać wykluczony z zakresu DHCP używanego dla węzłów i adresu IP klastra.

Jeśli na przykład zakres adresów IP zarządzania jest zdefiniowany jako 192.168.1.20/24 do 192.168.1.30/24 dla statycznych adresów IP infrastruktury, zakres DHCP zdefiniowany dla podsieci 192.168.1.0/24 musi mieć wykluczenie równoważne puli adresów IP zarządzania, aby uniknąć konfliktów adresów IP z usługami infrastruktury. Zalecamy również używanie rezerwacji DHCP dla adresów IP węzłów.

Proces definiowania adresu IP zarządzania po utworzeniu intencji zarządzania obejmuje użycie adresu MAC pierwszej fizycznej karty sieciowej wybranej dla intencji sieciowej. Ten adres MAC jest następnie przypisywany do wirtualnej karty sieciowej utworzonej do celów zarządzania. Oznacza to, że adres IP uzyskany przez pierwszą fizyczną kartę sieciową z serwera DHCP jest tym samym adresem IP, którego wirtualna karta sieciowa używa jako adresu IP zarządzania. Dlatego ważne jest utworzenie rezerwacji DHCP dla adresu IP węzła.

Zagadnienia dotyczące adresu IP węzła klastra

Poniżej przedstawiono podsumowanie zagadnień dotyczących adresów IP:

#	Zagadnienia do rozważenia
1	Adresy IP węzłów muszą znajdować się w tej samej podsieci zdefiniowanego zakresu puli adresów IP zarządzania, niezależnie od tego, czy są adresami statycznymi, czy dynamicznymi.
2	Pula adresów IP zarządzania nie może zawierać adresów IP węzłów. Używaj wykluczeń DHCP, gdy jest używane dynamiczne przypisywanie adresów IP.
3	Używaj rezerwacji DHCP dla węzłów, jak najwięcej.
4	Adresy DHCP są obsługiwane tylko w przypadku adresów IP węzła i adresu IP klastra. Usługi infrastruktury używają statycznych adresów IP z puli zarządzania.
5	Adres MAC z pierwszej fizycznej karty sieciowej jest przypisywany do wirtualnej karty sieciowej zarządzania po utworzeniu intencji sieci zarządzania.

Wymagania dotyczące serwera proxy

Serwer proxy najprawdopodobniej jest wymagany do uzyskania dostępu do Internetu w ramach infrastruktury lokalnej. Rozwiązanie Azure Stack HCI obsługuje tylko nieuwierzytelnione konfiguracje serwera proxy. Ponieważ dostęp do Internetu jest wymagany do rejestrowania węzłów w usłudze Azure Arc, konfiguracja serwera proxy musi być ustawiona jako część konfiguracji systemu operacyjnego przed zarejestrowaniem węzłów serwera. Aby uzyskać więcej informacji, zobacz Konfigurowanie ustawień serwera proxy.

System operacyjny Azure Stack HCI ma trzy różne usługi (WinInet, WinHTTP i zmienne środowiskowe), które wymagają tej samej konfiguracji serwera proxy, aby upewnić się, że wszystkie składniki systemu operacyjnego mogą uzyskiwać dostęp do Internetu. Ta sama konfiguracja serwera proxy używana dla węzłów jest automatycznie przenoszona na maszynę wirtualną mostka zasobów usługi Arc i usługę AKS, zapewniając dostęp do Internetu podczas wdrażania.

Poniżej przedstawiono podsumowanie zagadnień dotyczących konfiguracji serwera proxy:

#	Kwestie do rozważenia
1	Przed zarejestrowaniem węzłów w usłudze Azure Arc należy ukończyć konfigurację serwera proxy.
2	Tę samą konfigurację serwera proxy należy zastosować dla zmiennych środowiskowych WinINET, WinHTTP i .
3	Kontroler środowiska gwarantuje, że konfiguracja serwera proxy jest spójna we wszystkich składnikach serwera proxy.
4	Konfiguracja serwera proxy maszyny wirtualnej mostka zasobów usługi Arc i usługi AKS jest wykonywana automatycznie przez koordynatora podczas wdrażania.
5	Obsługiwane są tylko nieuwierzytelnione serwery proxy.

Wymagania dotyczące zapory

Obecnie wymagane jest otwarcie kilku internetowych punktów końcowych w zaporach, aby upewnić się, że usługa Azure Stack HCI i jej składniki mogą pomyślnie nawiązać z nimi połączenie. Aby uzyskać szczegółową listę wymaganych punktów końcowych, zobacz Wymagania dotyczące zapory.

Przed zarejestrowaniem węzłów w usłudze Azure Arc należy przeprowadzić konfigurację zapory. Możesz użyć autonomicznej wersji narzędzia do sprawdzania środowiska, aby sprawdzić, czy zapory nie blokują ruchu wysyłanego do tych punktów końcowych. Aby uzyskać więcej informacji, zobacz Narzędzie do sprawdzania środowiska rozwiązania Azure Stack HCI w celu oceny gotowości wdrożenia dla rozwiązania Azure Stack HCI.

Poniżej przedstawiono podsumowanie zagadnień dotyczących zapory:

#	Kwestie do rozważenia
1	Przed zarejestrowaniem węzłów w usłudze Azure Arc należy przeprowadzić konfigurację zapory.
2	Moduł sprawdzania środowiska w trybie autonomicznym może służyć do weryfikowania konfiguracji zapory.

Krok 5. Określanie konfiguracji karty sieciowej

Karty sieciowe są kwalifikowane przez typ ruchu sieciowego (zarządzanie, obliczenia i magazyn), z którymi są używane. Podczas przeglądania wykazu systemu Windows Server certyfikat systemu Windows Server 2022 wskazuje, dla którego ruchu sieciowego karty są kwalifikowane.

Przed zakupem serwera usługi Azure Stack HCI musisz mieć co najmniej jedną kartę, która jest kwalifikowana do zarządzania, obliczeń i magazynu, ponieważ wszystkie trzy typy ruchu są wymagane w usłudze Azure Stack HCI. Wdrożenie w chmurze opiera się na usłudze Network ATC w celu skonfigurowania kart sieciowych dla odpowiednich typów ruchu, dlatego ważne jest używanie obsługiwanych kart sieciowych.

Wartości domyślne używane przez usługę Network ATC są udokumentowane w temacie Ustawienia sieci klastra. Zalecamy używanie wartości domyślnych. W tym przypadku następujące opcje można przesłonić przy użyciu Azure Portal lub szablonów Resource Manager w razie potrzeby:

• Sieci VLAN magazynu: ustaw tę wartość na wymagane sieci VLAN na potrzeby magazynu.
• Pakiety Jumbo: definiuje rozmiar pakietów jumbo.
• Funkcja Direct sieci: ustaw tę wartość na wartość false, jeśli chcesz wyłączyć funkcję RDMA dla kart sieciowych.
• Technologia bezpośrednich sieci: ustaw tę wartość na RoCEv2 lub iWarp.
• Priorytety ruchu Mostkowanie centrum danych (DCB): ustaw priorytety, które spełniają Twoje wymagania. Zdecydowanie zalecamy używanie domyślnych wartości DCB, ponieważ są one weryfikowane przez firmę Microsoft i klientów.

Poniżej przedstawiono podsumowanie zagadnień dotyczących konfiguracji karty sieciowej:

#	Kwestie do rozważenia
1	Użyj możliwie jak największej ilości domyślnych konfiguracji.
2	Przełączniki fizyczne muszą być skonfigurowane zgodnie z konfiguracją karty sieciowej. Zobacz Wymagania dotyczące sieci fizycznej dla usługi Azure Stack HCI.
3	Upewnij się, że karty sieciowe są obsługiwane w usłudze Azure Stack HCI przy użyciu wykazu systemu Windows Server.
4	Po zaakceptowaniu wartości domyślnych usługa Network ATC automatycznie konfiguruje adresy IP i sieci VLAN karty sieciowej magazynu. Jest to nazywane konfiguracją automatycznego adresu IP magazynu. W niektórych przypadkach automatyczny adres IP magazynu nie jest obsługiwany i należy zadeklarować każdy adres IP karty sieciowej magazynu przy użyciu szablonów Resource Manager.

Następne kroki

• Informacje o wdrożeniu rozwiązania Azure Stack HCI w wersji 23H2.