Zagadnienia dotyczące sieci dla wdrożeń w chmurze Azure Local

Dotyczy: Azure Local 2311.2 i nowsze

W tym artykule omówiono sposób projektowania i planowania sieci systemu lokalnego platformy Azure 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 Azure Local Sizer, w którym można zdefiniować profil, taki jak liczba maszyn wirtualnych, rozmiar maszyn wirtualnych i sposób ich wykorzystania, takie jak Azure Virtual Desktop, SQL Server lub AKS.

Zgodnie z opisem w artykule Wymagania dotyczące komputera lokalnego platformy Azure maksymalna liczba maszyn obsługiwanych w wystąpieniu lokalnym platformy Azure wynosi 16. Po zakończeniu planowania pojemności roboczej powinieneś mieć dobre rozeznanie co do liczby węzłów potrzebnych do uruchamiania obciążeń roboczych 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 w magazynie. Aby obsługiwać ruch danych magazynowych, 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ą trzech lub mniej węzłów: możesz wybrać konfiguracje bez przełącznika lub z przełącznikiem dla łączności przechowywania.

• Jeśli planujesz przeskalowanie na więcej niż trzy węzły: musisz użyć przełącznika fizycznego dla ruchu sieciowego pamięci masowej. 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órą firma Microsoft nie weryfikuje aktywnie w ramach swojego cyklu tworzenia oprogramowania dla 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 czterema węzłami wymagają fizycznego przełącznika dla ruchu w sieci przechowywania danych.
Wymagania skalowania poziomego	Jeśli zamierzasz rozszerzać klaster przy użyciu orkiestratora, musisz użyć przełącznika fizycznego dla ruchu sieciowego przechowywania.

Krok 2: Określ łączność pamięci masowej klastra

Zgodnie z opisem w Wymagania dotyczące sieci fizycznej, usługa Azure Local obsługuje dwa rodzaje łączności dla ruchu sieciowego pamięci masowej.

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

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 z wykorzystaniem przełącznika sieciowego do przechowywania.

Jeśli klastry mają mniej niż trzy węzły, decyzja dotycząca łączności przechowywania wpływa na liczbę i typ zamierzeń sieciowych, 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 danych w magazynie dla komunikacji wschód-zachód przy użyciu kabli krosowych nie ma łączności północ-południe i jest całkowicie odizolowany od reszty 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 do przechowywania, możesz zgrupować cały ruch sieciowy, w tym przechowywanie, w jednym działaniu sieciowym, które jest również znane 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 pamięci	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 pamięci masowej bez przełączników z 1 lub 2 węzłami można wdrożyć przy użyciu portalu Azure lub szablonów usługi Resource Manager. Klastry magazynowe bez przełączników z 3 węzłami można wdrażać tylko przy użyciu szablonów Resource Manager. Operacje skalowania poziomego 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 cele sieciowe są wymagane w przypadku korzystania z konfiguracji bezprzełącznikowej pamięci masowej.
Przełącznik sieciowy do przechowywania danych	Jeśli zamierzasz rozszerzać klaster przy użyciu orkiestratora, musisz użyć przełącznika fizycznego dla ruchu sieciowego dla magazynowania. 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 przechowywania 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 połączenia przechowywania.

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

Zamiar sieci: Grupuj cały ruch

Usługa Network ATC konfiguruje unikatową intencję obejmującą zarządzanie, obliczenia i ruch sieciowy pamięci. Karty sieciowe przypisane do tego celu 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ę stosowanie co najmniej dwóch portów karty sieciowej w celu zapewnienia wysokiej dostępności.

• Wymagane są interfejsy sieciowe o przepustowości co najmniej 10 Gb/s do obsługi ruchu RDMA dla przechowywania.

Intencja sieci: zarządzanie grupami i ruch obliczeniowy

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

Tej opcji można użyć zarówno w przypadku łączności pamięci masowej z przełącznikiem, jak i bez przełącznika, jeśli:

• Co najmniej dwa porty karty sieciowej są dostępne dla każdego celu, aby zapewnić wysoką dostępność.

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

• Co najmniej 10 Gb/s interfejsy sieciowe są wymagane do obsługi ruchu RDMA dla pamięci masowej.

Intencja sieci: grupowanie ruchu obliczeniowego i przechowywania

Usługa Network ATC konfiguruje dwie intencje. Pierwszy cel obejmuje ruch sieciowy związany z obliczeniami i przechowywaniem danych, a drugi cel 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 danych magazynowych, gdyż te same porty są współdzielone z ruchem obliczeniowym, który potrzebuje komunikacji między północą a południem. 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ę użycie co najmniej dwóch portów adaptera sieciowego, aby zapewnić wysoką dostępność.

• Co najmniej 10 Gb/s interfejsy sieciowe są rekomendowane do celów obliczeniowych i magazynowania, aby obsługiwać ruch 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 pamięci masowej z przełącznikiem, jak i bez przełącznika, jeśli przeznaczenie pamięci masowej różni się od innych przeznaczeń.

• 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.

• Aby zapewnić wysoką dostępność, użyj co najmniej dwóch portów karty sieciowej dla każdego celu.

• Co najmniej 10 Gb/s interfejsy sieciowe są zalecane w celu obsługi zadań obliczeniowych i magazynowania danych, aby wspierać ruch 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 lokalnej instancji Azure należy zdefiniować zakres kolejnych adresów IP dla usług infrastruktury wdrażanych 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ć ciągłych 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.
4	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 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. Jednak jeśli wymagania dotyczące sieci przewidują użycie określonej VLAN zarządzania dla sieci infrastrukturalnej, należy ją skonfigurować na fizycznych adapterach sieciowych, które planujesz używać do przesyłania ruchu zarządzania.

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 konfigurowany jest identyfikator sieci VLAN 44 na fizycznej karcie sieciowej NIC1.

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 portalu Azure, ponieważ wiąże się to z ryzykiem zerwania łączności między węzłami a platformą Azure, jeśli VLAN-y na przełączniku fizycznym nie są prawidłowo kierowane.

Identyfikator VLAN dla zarządzania na przełączniku wirtualnym

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 Network ATC do tworzenia i konfigurowania przełączników wirtualnych i wirtualnych kart sieciowych na potrzeby zarządzania, obliczeń i przeznaczeń magazynowych. Domyślnie, gdy usługa Network ATC tworzy przełącznik wirtualny na potrzeby zamiarów, używa konkretnej 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 wpisaną do portalu podczas wdrażania. Ten ciąg musi również odpowiadać nazwie wirtualnej karty sieciowej używanej do zarządzania, jak opisano w następnym kroku.

W poniższym przykładzie pokazano, jak utworzyć przełącznik wirtualny za pomocą PowerShell przy użyciu zalecanej konwencji nazewnictwa $IntentName. Lista nazw kart sieciowych to zestawienie fizycznych kart sieciowych, które planujesz używać do obsługi zarządzania i przetwarzania ruchu sieciowego.

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

Uwaga

Po wdrożeniu lokalnej instancji Azure nie jest możliwa zmiana nazwy intencji zarządzania ani nazwy przełącznika wirtualnego. Należy użyć tej samej nazwy intencji i nazwy przełącznika wirtualnego, jeśli musisz zaktualizować lub ponownie utworzyć intencję po wdrożeniu.

2. Skonfiguruj wirtualną kartę sieciową zarządzania, używając 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 oraz wirtualnej karty sieciowej musi używać vManagement($intentname).
• Ta nazwa jest rozróżnialna ze względu na wielkość liter.
• $Intentname może być dowolnym ciągiem, ale musi być tą samą nazwą używaną dla przełącznika wirtualnego. Upewnij się, że podczas definiowania nazwy intencji używasz tego samego ciągu w portalu Azure.

Aby zaktualizować nazwę wirtualnej karty sieciowej używanej do 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 VLAN można przypisać adres IP i bramy do wirtualnej karty sieciowej zarządzającej. W ten sposób można zweryfikować, czy ma łączność z innymi węzłami, 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. Odwołanie się do fizycznych kart sieciowych w celu 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 obsługi obliczeniowej nadal musimy wybrać fizyczne karty sieciowe używane do realizacji tej intencji.

Uwaga

Nie wybieraj wirtualnej karty sieciowej do celów związanych z siecią.

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.
4	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 przechowywania

Domyślnie usługa network ATC automatycznie przypisze adresy IP i sieci VLAN do przechowywania z poniższej tabeli.

Adapter pamięci masowej	Adres IP i podsieć	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 ARM i należy określić następujące parametry w swoim 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 ramach parametru "storageAdapterIPInfo" w szablonie ARM musisz także określić parametry "ipv4Address" oraz "subnetMask" dla każdego węzła i każdej karty sieciowej, używając własnych adresów IP i maski 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 lokalnego wystąpienia Azure z dwoma węzłami i przełącznikiem sieciowym do przechowywania danych, w którym adresy IP magazynu są dostosowane wdrożenie z 2 węzłami i niestandardowymi adresami IP magazynu

Przypisanie adresu IP węzła i klastra

W przypadku instancji lokalnej Azure masz dwie opcje przypisania adresów IP dla węzłów maszyn oraz 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 Arc i kontroler sieci, nadal korzystają ze statycznych adresów IP z puli adresów IP używanych do 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 oraz skonfigurowanych serwerów DNS we wszystkich fizycznych kartach 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, co oznacza, że zakres adresów IP wykorzystywanych do 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 do przypisywania adresów IP hosta, musisz wstępnie utworzyć wirtualny przełącznik zespołu osadzonego (SET) i wirtualną kartę sieciową zarządzania zgodnie z opisem powyżej, aby tylko wirtualna karta sieciowa zarządzania uzyskiwała 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żywaj rezerwacji DHCP dla węzłów tak często, jak to możliwe.
4	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ądczej.

Zagadnienia dotyczące serwera DNS

Wdrożenia lokalne platformy Azure oparte na usłudze Active Directory wymagają serwera DNS, który może rozpoznać domenę lokalną i internetowe publiczne punkty końcowe. 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 w płaszczyźnie sterowania mostka zasobów Azure oraz płaszczyzna sterowania AKS będą korzystać z tych samych serwerów DNS do rozpoznawania nazw. Po zakończeniu wdrażania zmiana adresów IP serwerów DNS nie jest wspierana i aktualizacja adresów w całym stosie platformy Azure będzie niemożliwa.

Serwery DNS używane na potrzeby usługi Azure Local muszą być zewnętrzne i operacyjne przed wdrożeniem. Uruchamianie ich jako lokalnych maszyn wirtualnych platformy Azure nie jest obsługiwane.

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łaszczyzna sterowania maszynami wirtualnymi w Azure Resource Bridge i płaszczyzna sterowania w Azure Kubernetes Service (AKS) będą używać serwerów DNS skonfigurowanych na zakres adresów IP infrastruktury.
4	Zmiana serwerów DNS po wdrożeniu nie jest obsługiwana. Przed wykonaniem wdrożenia lokalnego platformy Azure upewnij się, że planujesz strategię DNS.
5	Podczas definiowania tablicy wielu serwerów DNS w szablonie usługi ARM dla sieci infrastruktury upewnij się, że każda wartość znajduje się w cudzysłowie "" i oddzielona przecinkami, jak w poniższym przykładzie.
6	Nie jest obsługiwane uruchamianie serwerów DNS używanych przez infrastrukturę lokalną platformy Azure na maszynach wirtualnych uruchomionych w wystąpieniu lokalnym platformy Azure.

"dnsServers": [
                        "10.250.16.124",
                        "10.250.17.232",
                        "10.250.18.107"
                    ]

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 serwera proxy bez uwierzytelnienia. 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 do maszyny wirtualnej Arc Resource Bridge oraz usługi 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.
4	Automatyczna konfiguracja serwera proxy maszyny wirtualnej Arc Resource Bridge i AKS jest dokonywana przez orchestratora 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	Konfigurację zapory należy wykonać przed zarejestrowaniem węzłów w usłudze Azure Arc.
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ą określane przez typ ruchu sieciowego (zarządzanie, obliczeniowy i magazynowanie), z którym są używane. Podczas przeglądania Katalogu Windows Server, certyfikacja systemu Windows Server 2022 wskazuje, dla którego ruchu sieciowego są kwalifikowane adaptery.

Przed zakupem maszyny dla Azure Lokalnie musisz mieć co najmniej jedną kartę kwalifikowaną do zarządzania, obliczeń i przechowywania, ponieważ wszystkie trzy typy ruchu są wymagane na 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:

• VLAN-y magazynowe: ustaw tę wartość na wymagane VLAN-y dla magazynowania.
• Jumbo Pakiety: definiuje rozmiar jumbo pakietów.
• Network Direct: ustaw tę wartość na FALSE, jeśli chcesz wyłączyć funkcję RDMA dla kart sieciowych.
• Network Direct Technology: ustaw tę wartość na RoCEv2 lub iWarp.
• Priorytety ruchu mostkowania centrów 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 przez Azure Local przy użyciu Katalogu Windows Server.
4	Podczas akceptowania wartości domyślnych Network ATC automatycznie konfiguruje adresy IP i sieci VLAN adaptera sieciowego magazynowego. Jest to znane jako automatyczna konfiguracja adresu IP dla magazynu. W niektórych przypadkach Storage Auto IP nie jest obsługiwany i należy zadeklarować każdy adres IP adaptera sieciowego magazynu przy użyciu szablonów usługi Resource Manager.

Następne kroki

• Informacje o lokalnym wdrożeniu platformy Azure.