Zagadnienia dotyczące sieci dla wdrożeń w chmurze platformy Azure w wersji lokalnej 23H2

Dotyczy: Azure Local, wersja 23H2

W tym artykule omówiono sposób projektowania i planowania lokalnej sieci systemu Platformy Azure w wersji 23H2 na potrzeby wdrażania w chmurze. Przed kontynuowaniem zapoznaj się z różnymi lokalnymi wzorcami sieci platformy Azure i dostępnymi konfiguracjami.

Struktura projektowania sieci

Na poniższym diagramie przedstawiono różne decyzje i kroki, które definiują strukturę projektowania sieci dla wystąpienia lokalnego platformy Azure — rozmiar klastra, łączność magazynu klastra, intencje ruchu sieciowego, łączność zarządzania i konfigurację 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 ułatwić określenie rozmiaru wystąpienia lokalnego platformy Azure, użyj narzędzia do tworzenia rozmiaru lokalnego platformy Azure, 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 Wymagania dotyczące komputera systemowego platformy Azure maksymalna liczba maszyn obsługiwanych w wystąpieniu lokalnym platformy Azure wynosi 16. Po zakończeniu planowania pojemności obciążenia należy dobrze zrozumieć liczbę węzłów maszyn 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 wystąpienia lokalnego platformy Azure, 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 dla łączności magazynu.

• 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 jest aktywnie weryfikowana w ramach cyklu tworzenia oprogramowania dla usługi Azure Local.

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

Decyzja	Kwestie wymagające rozważenia
Rozmiar klastra (liczba węzłów na klaster)	Konfiguracja bez przełączania za pośrednictwem witryny Azure Portal lub szablonów usługi 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 Local 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 światłowodowych dla ruchu magazynu.

Zalety i wady każdej opcji są udokumentowane w artykule połączonym powyżej.

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 dotycząca łą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 we wschodniej części zachodu przy użyciu krzyżowych 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ążeniami obliczeniowymi.

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 portów sieci fizycznej dla każdej intencji sieci. Jeśli zdecydujesz się użyć przełącznika sieciowego dla magazynu, 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 magazynu klastra:

Decyzja	Kwestie wymagające rozważenia
Brak przełącznika dla magazynu	Konfiguracja bez przełączników za pośrednictwem witryny Azure Portal lub wdrożenia szablonu usługi Resource Manager jest obsługiwana tylko dla klastrów 1, 2 lub 3 węzłów. Klastry bez przełączników magazynu 1 lub 2 węzłów można wdrożyć przy użyciu witryny Azure Portal lub szablonów usługi Resource Manager. Klastry bez przełączników magazynu z 3 węzłami można wdrażać tylko przy użyciu szablonów usługi 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 opcji łączności magazynu dostępnych dla różnych wdrożeń:

Krok 3. Określanie intencji ruchu sieciowego

W przypadku usługi Azure Local wszystkie wdrożenia korzystają z usługi Network ATC dla konfiguracji sieci hosta. Intencje sieciowe są konfigurowane automatycznie podczas wdrażania usługi Azure Local za pośrednictwem witryny Azure Portal. Aby dowiedzieć się więcej o intencjach sieci i sposobach ich rozwiązywania, zobacz Typowe polecenia usługi ATC sieci.

W tej sekcji wyjaśniono implikacje decyzji projektowej dla 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: Grupuj cały ruch

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. Witryna Azure Portal automatycznie filtruje tę opcję, jeśli wybierzesz konfigurację bez przełącznika na potrzeby łączności z magazynem.

• Zaleca się zapewnienie wysokiej dostępności co najmniej dwóch portów karty sieciowej.

• 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 zarządzania i obliczeń, 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 magazynowania.

• 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 obliczeniowy i sieciowy magazynu, 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, który jest współużytkowany z ruchem obliczeniowym, co wymaga komunikacji północno-południowej. Jeśli potrzebujesz konfiguracji bez przełącznika, nie możesz użyć tego typu intencji. Witryna 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.

• Zaleca się zapewnienie wysokiej dostępności co najmniej dwóch portów karty sieciowej.

• Co najmniej 10 Gb/s interfejsy sieciowe 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, gdy wymagana jest 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ść.

• Co najmniej 10 Gb/s interfejsy sieciowe 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 zarządzania i łączności sieciowej magazynu

W tym kroku zdefiniujesz przestrzeń adresową podsieci infrastruktury, sposób przypisania tych adresów do klastra oraz czy 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ć wszelkie 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. Ważne możliwości kart sieciowych mogą nie być dostępne podczas korzystania z domyślnych sterowników firmy Microsoft.

Pula adresów IP zarządzania

Podczas początkowego wdrażania wystąpienia lokalnego platformy Azure 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 uruchomienie 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:

#	Stan
1	Zakres adresów IP musi używać kolejnych adresów IP, a wszystkie adresy IP muszą być dostępne w tym zakresie. Nie można zmienić tego zakresu adresów IP po wdrożeniu.
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.
100	Serwery DNS muszą zapewnić rozpoznawanie nazw za pomocą usługi Active Directory i Internetu.
5	Adresy IP zarządzania wymagają wychodzącego dostępu do Internetu.

Identyfikator sieci VLAN zarządzania

Zalecamy, aby podsieć zarządzania wystąpienia lokalnego platformy Azure 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 dotyczące sieci mają używać określonej sieci VLAN zarządzania dla sieci infrastruktury, należy ją skonfigurować na fizycznych kartach sieciowych, które mają być używane do obsługi ruchu związanego z zarządzaniem.

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 maszyn 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 przechowywania jej, 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 witryny 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. Tworzenie przełącznika wirtualnego z zalecaną konwencją nazewnictwa

Wdrożenia lokalne platformy Azure 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.

Zalecamy nazywanie nazw przełączników wirtualnych tą samą konwencją nazewnictwa. Zalecana nazwa przełączników wirtualnych jest następująca:

"ConvergedSwitch($IntentName)", gdzie $IntentName musi być zgodna z nazwą intencji wpisana do portalu podczas wdrażania. Ten ciąg musi być również zgodny z nazwą wirtualnej karty sieciowej używanej do zarządzania zgodnie z opisem w następnym kroku.

W poniższym przykładzie pokazano, jak utworzyć przełącznik wirtualny za pomocą programu PowerShell przy użyciu zalecanej konwencji nazewnictwa z $IntentNameprogramem . 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 $true

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

Po utworzeniu przełącznika wirtualnego i skojarzonej karty sieciowej zarządzania upewnij się, że nazwa karty sieciowej jest zgodna ze standardami nazewnictwa usługi Network ATC.

W szczególności nazwa wirtualnej karty sieciowej używanej do zarządzania ruchem musi używać następujących konwencji:

• Nazwa karty sieciowej i wirtualnej karty sieciowej musi używać .vManagement($intentname)
• W tej nazwie jest uwzględniana wielkość liter.
• $Intentname może być dowolnym ciągiem, ale musi być tą samą nazwą używaną dla przełącznika wirtualnego. Podczas definiowania nazwy intencji upewnij się, że używasz tego samego ciągu w witrynie Mgmt Azure Portal.

Aby zaktualizować nazwę wirtualnej karty sieciowej zarządzania, użyj następujących poleceń:

$IntentName = "MgmtCompute"

#Rename VMNetworkAdapter for management because during creation, Hyper-V uses the vSwitch name for the virtual network adapter.
Rename-VmNetworkAdapter -ManagementOS -Name "ConvergedSwitch(MgmtCompute)" -NewName "vManagement(MgmtCompute)"

#Rename NetAdapter because during creation, Hyper-V adds the string “vEthernet” to the beginning of the name.
Rename-NetAdapter -Name "vEthernet (ConvergedSwitch(MgmtCompute))" -NewName "vManagement(MgmtCompute)"

3. Konfigurowanie identyfikatora 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 8 sieci VLAN zamiast domyślnego:

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

4. Przywoływanie 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 witryny 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 ma zastosowanie do szablonów usługi Azure Resource Manager. Należy określić fizyczne karty sieciowe, które mają być używane dla intencji sieciowych i nigdy nie są to wirtualne karty sieciowe.

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

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

Niestandardowe adresy IP dla magazynu

Domyślnie usługa NETWORK ATC automatycznie przypisze adresy IP i sieci VLAN do magazynu z poniższej tabeli:

Adapter magazynu	Adres IP i podsieć	Sieć VLAN
pNIC1	10.71.1.x	711
pNIC2	10.71.2.x	712
pNIC3	10.71.3.x	713

Jeśli jednak wymagania dotyczące wdrażania nie pasują do tych domyślnych adresów IP i sieci VLAN, możesz użyć własnych adresów IP, podsieci i sieci VLAN do magazynowania. Ta funkcja jest dostępna tylko podczas wdrażania klastrów przy użyciu szablonów usługi ARM i należy określić następujące parametry w szablonie.

• enableStorageAutoIP: ten parametr, jeśli nie zostanie określony, ma wartość true. Aby włączyć niestandardowe adresy IP magazynu podczas wdrażania, ten parametr musi być ustawiony na wartość false.
• storageAdapterIPInfo: ten parametr ma zależność z parametrem "enableStorageAutoIP" i jest zawsze wymagany, gdy parametr automatycznego adresu IP magazynu ma wartość false. W parametrze "storageAdapterIPInfo" w szablonie usługi ARM należy również określić parametry "ipv4Address" i "subnetMask" dla każdego węzła i karty sieciowej z własnymi adresami IP i maską podsieci.
• vlanId: zgodnie z powyższym opisem w tabeli ten parametr będzie używać domyślnych sieci VLAN usługi NETWORK ATC, jeśli nie trzeba ich zmieniać. Jeśli jednak te domyślne sieci VLAN nie działają w sieci, możesz określić własne identyfikatory sieci VLAN dla każdej sieci magazynowej.

Poniższy szablon usługi ARM zawiera przykład dwóch węzłów lokalnego wystąpienia platformy Azure z przełącznikiem sieciowym dla magazynu, w którym adresy IP magazynu są dostosowane 2 węzły wdrożenia z niestandardowymi adresami IP magazynu

Przypisanie adresu IP węzła i klastra

W przypadku wystąpienia lokalnego platformy Azure masz dwie opcje przypisywania adresów IP dla węzłów maszyny i adresu IP klastra.

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

• Prawidłowe przypisanie adresu IP węzła jest kluczem do zarządzania cyklem życia klastra. Przed zarejestrowaniem węzłów w usłudze Azure Arc zdecyduj między opcjami statycznych 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 każdej opcji.

Przypisanie statycznego adresu IP

Jeśli statyczne adresy IP są używane dla węzłów, pula adresów IP zarządzania jest używana 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łów maszyny 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 zmieni się 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 na potrzeby łączności wychodzącej i rejestracji usługi Arc, witryna 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 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.

Logika walidacji sieci używana podczas wdrażania w chmurze zakończy się niepowodzeniem, jeśli wykryje wiele fizycznych interfejsów sieciowych, które mają bramę domyślną w konfiguracji. Jeśli musisz użyć protokołu DHCP dla przypisań adresów IP hosta, musisz wstępnie utworzyć przełącznik wirtualny SET (przełącznik osadzony tworzenie zespołu) i wirtualną kartę sieciową zarządzania zgodnie z powyższym opisem, więc tylko wirtualna karta sieciowa zarządzania uzyskuje adres IP z serwera DHCP.

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

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

#	Kwestie wymagające 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ą statyczne, czy dynamiczne.
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 przypisanie adresu IP.
3	Użyj rezerwacji DHCP dla węzłów, jak najwięcej.
100	Adresy DHCP są obsługiwane tylko w przypadku adresów IP węzłów 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.

Zagadnienia dotyczące serwerów DNS

Wdrożenia lokalne platformy Azure oparte na usłudze Active Directory wymagają serwera DNS, który może rozpoznać domenę lokalną i publiczne punkty końcowe Internetu. W ramach wdrożenia wymagane jest zdefiniowanie tych samych serwerów DNS dla zakresu adresów IP infrastruktury skonfigurowanych w węzłach. Maszyna wirtualna płaszczyzny sterowania mostka zasobów platformy Azure oraz płaszczyzna sterowania AKS będą korzystać z tych samych serwerów DNS do rozpoznawania nazw. Po zakończeniu wdrażania nie jest obsługiwane zmienianie adresów IP serwerów DNS i nie będzie możliwe zaktualizowanie adresów w stosie platformy Azure.

Poniżej przedstawiono podsumowanie zagadnień dotyczących adresów serwerów DNS

#	Kwestie wymagające rozważenia
1	Serwery DNS we wszystkich węzłach klastra muszą być takie same.
2	Serwery DNS dla zakresu adresów IP infrastruktury muszą być takie same jak w przypadku węzłów.
3	Płaszczyzny sterowania maszyn wirtualnych Azure Resource Bridge oraz Azure Kubernetes Service (AKS) używają serwerów DNS skonfigurowanych w zakresie adresów IP infrastruktury.
100	Zmiana serwerów DNS po wdrożeniu nie jest obsługiwana. Przed wykonaniem wdrożenia lokalnego platformy Azure upewnij się, że planujesz strategię DNS.

Wymagania dotyczące serwera proxy

Serwer proxy najprawdopodobniej jest wymagany do uzyskania dostępu do Internetu w ramach infrastruktury lokalnej. Usługa Azure Local obsługuje tylko konfiguracje nieuwierzytelnionego serwera proxy. Biorąc pod uwagę, że dostęp do Internetu jest wymagany do zarejestrowania węzłów w usłudze Azure Arc, konfiguracja serwera proxy musi być ustawiona jako część konfiguracji systemu operacyjnego przed zarejestrowaniem węzłów maszyny. 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 im dostęp do Internetu podczas wdrażania.

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

#	Kwestie wymagające 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	Moduł sprawdzania środowiska gwarantuje, że konfiguracja serwera proxy jest spójna we wszystkich składnikach serwera proxy.
100	Konfiguracja serwera proxy maszyny wirtualnej mostka zasobów usługi Arc i usługi AKS jest automatycznie wykonywana przez koordynatora podczas wdrażania.
5	Obsługiwane są tylko nieuwierzytelnione serwery proxy.

Wymagania dotyczące zapory

Obecnie musisz otworzyć kilka internetowych punktów końcowych w zaporach, aby upewnić się, że platforma Azure Lokalna 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 wykonać 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 lokalnego platformy Azure, aby ocenić gotowość wdrożenia dla usługi Azure Local.

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

#	Kwestie wymagające rozważenia
1	Przed zarejestrowaniem węzłów w usłudze Azure Arc należy wykonać 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 certyfikacja systemu Windows Server 2022 wskazuje, dla którego ruchu sieciowego są kwalifikowane karty.

Przed zakupem maszyny dla usługi Azure Local musisz mieć co najmniej jedną kartę, która jest kwalifikowana do zarządzania, obliczeń i magazynu, ponieważ wszystkie trzy typy ruchu są wymagane na platformie Azure Lokalnie. 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, aby używać obsługiwanych kart sieciowych.

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

• 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 false, jeśli chcesz wyłączyć funkcję RDMA dla kart sieciowych.
• Technologia Network Direct: ustaw tę wartość na RoCEv2 lub iWarp.
• Priorytety ruchu Mostkowanie centrum danych (DCB): ustaw priorytety, które pasują do Twoich wymagań. 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 wymagające 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 Local.
3	Upewnij się, że karty sieciowe są obsługiwane dla platformy Azure Lokalnie przy użyciu wykazu systemu Windows Server.
100	Podczas akceptowania 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 usługi Resource Manager.

Następne kroki

• Informacje o lokalnym wdrożeniu platformy Azure w wersji 23H2.