Wymagania dotyczące sieci hosta dla usługi Azure Stack HCI
Dotyczy: Azure Stack HCI, wersje 23H2 i 22H2
W tym temacie omówiono zagadnienia i wymagania dotyczące sieci hosta dla rozwiązania Azure Stack HCI. Aby uzyskać informacje na temat architektur centrów danych i połączeń fizycznych między serwerami, zobacz Wymagania dotyczące sieci fizycznej.
Aby uzyskać informacje na temat upraszczania sieci hostów przy użyciu usługi Network ATC, zobacz Upraszczanie sieci hostów za pomocą usługi Network ATC.
Typy ruchu sieciowego
Ruch sieciowy rozwiązania Azure Stack HCI można sklasyfikować według zamierzonego celu:
- Ruch związany z zarządzaniem: Ruch do lub spoza klastra lokalnego. Na przykład ruch repliki magazynu lub ruch używany przez administratora do zarządzania klastrem, takich jak pulpit zdalny, Windows Admin Center, Active Directory itp.
- Ruch obliczeniowy: Ruch pochodzący z maszyny wirtualnej lub kierowany do maszyny wirtualnej.
- Ruch magazynu: Ruch przy użyciu bloku komunikatów serwera (SMB), na przykład Bezpośrednie miejsca do magazynowania lub migracji na żywo opartej na protokole SMB. Ten ruch jest ruchem warstwy 2 i nie jest routingowy.
Ważne
Replika magazynu używa ruchu SMB opartego na funkcji RDMA. Ten i kierunkowy charakter ruchu (Północ-Południe) sprawia, że jest ściśle dopasowany do ruchu "zarządzania" wymienionego powyżej, podobnie jak w przypadku tradycyjnego udziału plików.
Wybieranie karty sieciowej
Karty sieciowe są kwalifikowane przez typy ruchu sieciowego (patrz powyżej), z którymi są obsługiwane. Podczas przeglądania wykazu systemu Windows Server certyfikacja systemu Windows Server 2022 wskazuje teraz co najmniej jedną z następujących ról. 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. Następnie można użyć usługi Network ATC , aby skonfigurować karty dla odpowiednich typów ruchu.
Aby uzyskać więcej informacji na temat tego kwalifikacji kart interfejsu sieciowego opartego na rolach, zobacz ten link.
Ważne
Używanie adaptera spoza kwalifikowanego typu ruchu nie jest obsługiwane.
Poziom | Rola zarządzania | Rola obliczeniowa | Rola magazynu |
---|---|---|---|
Rozróżnienie oparte na rolach | Zarządzanie | Compute Standard | Storage Standard |
Maksymalna nagroda | Nie dotyczy | Compute Premium | Storage Premium |
Uwaga
Najwyższe kwalifikacje dla każdej karty w naszym ekosystemie będą zawierać kwalifikacje do zarządzania, obliczeń w warstwie Premium i magazynu Premium .
Wymagania dotyczące sterowników
Sterowniki skrzynki odbiorczej nie są obsługiwane do użycia z rozwiązaniem Azure Stack HCI. Aby określić, czy karta używa sterownika skrzynki odbiorczej, uruchom następujące polecenie cmdlet. Adapter używa sterownika skrzynki odbiorczej, jeśli właściwość DriverProvider to Microsoft.
Get-NetAdapter -Name <AdapterName> | Select *Driver*
Omówienie kluczowych możliwości karty sieciowej
Ważne możliwości karty sieciowej używane przez rozwiązanie Azure Stack HCI obejmują:
- Dynamiczna kolejka maszyny wirtualnej (dynamic VMMQ lub d.VMMQ)
- Zdalny bezpośredni dostęp do pamięci (RDMA)
- RdMA gościa
- Przełącznik osadzone tworzenia zespołu (SET)
Dynamiczny program VMMQ
Wszystkie karty sieciowe z kwalifikacjami obliczeniowymi (Premium) obsługują dynamiczną usługę VMMQ. Dynamiczna funkcja VMMQ wymaga użycia tworzenia zespołu osadzonego przełącznika.
Odpowiednie typy ruchu: obliczenia
Wymagane certyfikaty: Obliczenia (Premium)
Dynamic VMMQ to inteligentna technologia po stronie odbieranej. Opiera się ona na poprzednikach kolejki maszyn wirtualnych (VMQ), wirtualnego skalowania po stronie odbierającej (vRSS) i VMMQ, aby zapewnić trzy podstawowe ulepszenia:
- Optymalizuje wydajność hosta przy użyciu mniejszej liczby rdzeni procesora CPU.
- Automatyczne dostrajanie przetwarzania ruchu sieciowego do rdzeni procesora CPU, co umożliwia maszynom wirtualnym spełnianie i utrzymywanie oczekiwanej przepływności.
- Umożliwia "bursty" obciążeń odbieranie oczekiwanej ilości ruchu.
Aby uzyskać więcej informacji na temat dynamicznego programu VMMQ, zobacz wpis w blogu Syntetyczne przyspieszenia.
Dostęp RDMA
RDMA to odciążanie stosu sieciowego do karty sieciowej. Umożliwia to obejście ruchu magazynu SMB w celu obejścia systemu operacyjnego do przetwarzania.
Funkcja RDMA umożliwia korzystanie z sieci o wysokiej przepływności i małych opóźnieniach przy użyciu minimalnych zasobów procesora CPU hosta. Te zasoby procesora CPU hosta mogą być następnie używane do uruchamiania dodatkowych maszyn wirtualnych lub kontenerów.
Odpowiednie typy ruchu: magazyn hosta
Wymagane certyfikaty: Storage (Standardowa)
Wszystkie karty z kwalifikacjami magazynu (Standard) lub Storage (Premium) obsługują funkcję RDMA po stronie hosta. Aby uzyskać więcej informacji na temat korzystania z funkcji RDMA z obciążeniami gościa, zobacz sekcję "RdMA gościa" w dalszej części tego artykułu.
Usługa Azure Stack HCI obsługuje funkcję RDMA z implementacjami protokołów IWARMA (Internet Wide Area RDMA) lub RDMA over Converged Ethernet (RoCE).
Ważne
Karty RDMA działają tylko z innymi kartami RDMA, które implementują ten sam protokół RDMA (iWARP lub RoCE).
Nie wszystkie karty sieciowe od dostawców obsługują funkcję RDMA. W poniższej tabeli wymieniono tych dostawców (w kolejności alfabetycznej), które oferują certyfikowane karty RDMA. Jednak na tej liście nie ma dostawców sprzętu, którzy również obsługują funkcję RDMA. Zobacz Katalog systemu Windows Server , aby znaleźć karty z kwalifikacją Magazynu (Standardowa) lub Storage (Premium), które wymagają obsługi FUNKCJI RDMA.
Uwaga
Rozwiązanie InfiniBand (IB) nie jest obsługiwane w usłudze Azure Stack HCI.
Dostawca karty sieciowej | Iwarp | Roce |
---|---|---|
Broadcom | Nie | Tak |
Intel | Tak | Tak (niektóre modele) |
Marvell (Qlogic) | Tak | Tak |
Nvidia | Nie | Tak |
Aby uzyskać więcej informacji na temat wdrażania funkcji RDMA dla hosta, zdecydowanie zalecamy użycie usługi Network ATC. Aby uzyskać informacje na temat wdrażania ręcznego, zobacz repozytorium GitHub sieci SDN.
Iwarp
System iWARP korzysta z protokołu TCP (Transmission Control Protocol) i można go opcjonalnie ulepszyć przy użyciu kontroli przepływu opartego na priorytetach (PFC) i rozszerzonej usługi transmisji (ETS).
Użyj iWARP, jeśli:
- Nie masz doświadczenia w zarządzaniu sieciami RDMA.
- Nie zarządzasz przełącznikami top-of-rack (ToR) lub nie zarządzasz nimi.
- Po wdrożeniu nie będziesz zarządzać rozwiązaniem.
- Masz już wdrożenia korzystające z protokołu iWARP.
- Nie masz pewności, która opcja ma być wybrana.
Roce
Usługa RoCE używa protokołu UDP (User Datagram Protocol) i wymaga od PFC i ETS zapewnienia niezawodności.
Użyj roCE, jeśli:
- Masz już wdrożenia z roCE w centrum danych.
- Dobrze zarządzasz wymaganiami dotyczącymi sieci DCB.
RdMA gościa
Funkcja RDMA gościa umożliwia wykonywanie obciążeń SMB dla maszyn wirtualnych w celu uzyskania tych samych korzyści związanych z używaniem funkcji RDMA na hostach.
Odpowiednie typy ruchu: Magazyn oparty na gościu
Wymagane certyfikaty: Obliczenia (Premium)
Podstawowe korzyści wynikające z używania funkcji RDMA gościa to:
- Odciążanie procesora CPU do karty sieciowej na potrzeby przetwarzania ruchu sieciowego.
- Bardzo małe opóźnienie.
- Wysoka przepływność.
Aby uzyskać więcej informacji, pobierz dokument z repozytorium GitHub SDN.
Przełącznik osadzone tworzenia zespołu (SET)
SET to technologia tworzenia zespołu oparta na oprogramowaniu, która została dołączona do systemu operacyjnego Windows Server od Windows Server 2016. SET to jedyna technologia tworzenia zespołu obsługiwana przez usługę Azure Stack HCI. Zestaw działa dobrze w przypadku ruchu obliczeniowego, magazynu i zarządzania i obsługuje maksymalnie osiem kart w tym samym zespole.
Odpowiednie typy ruchu: obliczenia, magazyn i zarządzanie
Wymagane certyfikaty: Obliczenia (w warstwie Standardowa) lub obliczenia (Premium)
SET to jedyna technologia tworzenia zespołu obsługiwana przez usługę Azure Stack HCI. Zestaw działa dobrze w przypadku ruchu obliczeniowego, magazynu i zarządzania.
Ważne
Usługa Azure Stack HCI nie obsługuje tworzenia zespołu kart interfejsu sieciowego ze starszym równoważeniem obciążenia/trybem failover (LBFO). Aby uzyskać więcej informacji na temat LBFO w usłudze Azure Stack HCI, zobacz wpis w blogu Teaming in Azure Stack HCI (Tworzenie zespołu w usłudze Azure Stack HCI ).
ZESTAW jest ważny dla usługi Azure Stack HCI, ponieważ jest to jedyna technologia tworzenia zespołu, która umożliwia:
- Tworzenie zespołu kart RDMA (w razie potrzeby).
- RdMA gościa.
- Dynamiczny program VMMQ.
- Inne kluczowe funkcje rozwiązania Azure Stack HCI (zobacz Tworzenie zespołu w usłudze Azure Stack HCI).
Funkcja SET wymaga użycia kart symetrycznych (identycznych). Symetryczne karty sieciowe to te, które mają takie same cechy:
- producent (dostawca)
- model (wersja)
- szybkość (przepływność)
- konfiguracja
W wersji 22H2 usługa Network ATC automatycznie wykryje i poinformuje o tym, czy wybrane karty są asymetryczne. Najprostszym sposobem ręcznego identyfikowania, czy karty są symetryczne, jest to, czy szybkość i opisy interfejsu są dokładnie zgodne. Mogą one odejść tylko w numerze wymienionym w opisie. Get-NetAdapterAdvancedProperty
Użyj polecenia cmdlet , aby upewnić się, że zgłoszona konfiguracja zawiera te same wartości właściwości.
Zapoznaj się z poniższą tabelą, aby zapoznać się z przykładem opisów interfejsu, które odbiegają tylko od liczb (#):
Nazwa | Opis interfejsu | Szybkość łącza |
---|---|---|
NIC1 | Karta sieciowa nr 1 | 25 Gb/s |
NIC2 | Karta sieciowa #2 | 25 Gb/s |
NIC3 | Karta sieciowa #3 | 25 Gb/s |
NIC4 | Karta sieciowa #4 | 25 Gb/s |
Uwaga
Funkcja SET obsługuje tylko konfigurację niezależną od przełącznika przy użyciu algorytmów równoważenia obciążenia dynamicznego lub portu funkcji Hyper-V. Aby uzyskać najlepszą wydajność, zaleca się używanie portu funkcji Hyper-V na wszystkich kartach sieciowych, które działają z szybkością co najmniej 10 Gb/s. Usługa ATC sieci sprawia, że wszystkie wymagane konfiguracje zestawu.
Zagadnienia dotyczące ruchu RDMA
W przypadku zaimplementowania usługi DCB należy upewnić się, że konfiguracja PFC i ETS jest prawidłowo implementowana na każdym porcie sieciowym, w tym przełącznikach sieciowych. Funkcja DCB jest wymagana w przypadku modelu RoCE i opcjonalnego dla systemu iWARP.
Aby uzyskać szczegółowe informacje na temat wdrażania funkcji RDMA, pobierz dokument z repozytorium GitHub SDN.
Implementacje usługi Azure Stack HCI oparte na protokole RoCE wymagają konfiguracji trzech klas ruchu PFC, w tym domyślnej klasy ruchu w sieci szkieletowej i wszystkich hostach.
Klaster ruchu
Ta klasa ruchu zapewnia wystarczającą przepustowość zarezerwowaną dla pulsów klastra:
- Wymagany: Tak
- Włączono funkcję PFC: Nie
- Zalecany priorytet ruchu: Priorytet 7
- Zalecana rezerwacja przepustowości:
- 10 GbE lub niższe sieci RDMA = 2 procent
- 25 GbE lub wyższe sieci RDMA = 1 procent
RdMA traffic Class (Klasa ruchu RDMA)
Ta klasa ruchu zapewnia wystarczającą przepustowość zarezerwowaną dla bezstratnej komunikacji RDMA przy użyciu protokołu SMB Direct:
- Wymagany: Tak
- Włączono funkcję PFC: Tak
- Zalecany priorytet ruchu: priorytet 3 lub 4
- Zalecana rezerwacja przepustowości: 50 procent
Domyślna klasa ruchu
Ta klasa ruchu prowadzi cały inny ruch, który nie jest zdefiniowany w klastrze lub klasach ruchu RDMA, w tym ruchu maszyny wirtualnej i ruchu zarządzania:
- Wymagane: domyślnie (żadna konfiguracja nie jest wymagana na hoście)
- Sterowanie przepływem (PFC)-enabled: Nie
- Zalecana klasa ruchu: domyślnie (priorytet 0)
- Zalecana rezerwacja przepustowości: domyślnie (nie jest wymagana żadna konfiguracja hosta)
Modele ruchu magazynu
Protokół SMB zapewnia wiele korzyści, ponieważ protokół magazynu dla usługi Azure Stack HCI, w tym protokół SMB Multichannel. Funkcja SMB Multichannel nie została omówiona w tym artykule, ale ważne jest, aby zrozumieć, że ruch jest multipleksowany przez każdy możliwy link, którego może używać funkcja SMB Multichannel.
Uwaga
Zalecamy używanie wielu podsieci i sieci VLAN do oddzielania ruchu magazynu w usłudze Azure Stack HCI.
Rozważmy poniższy przykład klastra z czterema węzłami. Każdy serwer ma dwa porty magazynu (po lewej i prawej stronie). Ponieważ każda karta znajduje się w tej samej podsieci i sieci VLAN, protokół SMB Multichannel rozłoży połączenia na wszystkie dostępne łącza. W związku z tym port po lewej stronie pierwszego serwera (192.168.1.1) spowoduje połączenie z portem po lewej stronie na drugim serwerze (192.168.1.2). Port po prawej stronie pierwszego serwera (192.168.1.12) połączy się z portem po prawej stronie na drugim serwerze. Podobne połączenia są ustanawiane dla trzeciego i czwartego serwera.
Jednak powoduje to niepotrzebne połączenia i powoduje przeciążenie w połączeniu (grupa agregacji linków z wieloma obudowami lub MC-LAG), która łączy przełączniki ToR (oznaczone Xs). Zobacz następujący diagram:
Zalecaną metodą jest użycie oddzielnych podsieci i sieci VLAN dla każdego zestawu kart sieciowych. Na poniższym diagramie porty po prawej stronie używają teraz podsieci 192.168.2.x /24 i sieci VLAN2. Dzięki temu ruch na portach po lewej stronie pozostanie na tor1, a ruch na portach po prawej stronie pozostanie na tor2.
Alokacja przepustowości ruchu
W poniższej tabeli przedstawiono przykładowe alokacje przepustowości różnych typów ruchu przy użyciu typowych szybkości kart w usłudze Azure Stack HCI. Należy pamiętać, że jest to przykład rozwiązania konwergentnego, w którym wszystkie typy ruchu (obliczenia, magazyn i zarządzanie) działają na tych samych kartach fizycznych i są tworzone zespoły przy użyciu zestawu.
Ponieważ ten przypadek użycia stanowi najwięcej ograniczeń, reprezentuje dobry punkt odniesienia. Jednak biorąc pod uwagę permutacje liczby kart i szybkości, należy to uznać za przykład, a nie wymaganie obsługi.
W tym przykładzie przyjmuje się następujące założenia:
Istnieją dwie karty na zespół.
Ruch warstwy magistrali magazynu (SBL), udostępnionego woluminu klastra (CSV) i funkcji Hyper-V (migracja na żywo):
- Użyj tych samych kart fizycznych.
- Użyj protokołu SMB.
Protokół SMB otrzymuje alokację przepustowości o 50 procent przy użyciu funkcji DCB.
- SBL/CSV jest najwyższym priorytetem ruchu i otrzymuje 70 procent rezerwacji przepustowości protokołu SMB.
- Migracja na żywo (LM) jest ograniczona przy użyciu
Set-SMBBandwidthLimit
polecenia cmdlet i odbiera 29 procent pozostałej przepustowości.Jeśli dostępna przepustowość migracji na żywo wynosi >= 5 Gb/s, a karty sieciowe są w stanie obsługiwać, użyj funkcji RDMA. Aby to zrobić, użyj następującego polecenia cmdlet:
Set-VMHost -VirtualMachineMigrationPerformanceOption SMB
Jeśli dostępna przepustowość migracji na żywo wynosi < 5 Gb/s, użyj kompresji, aby skrócić czas zaciemnienia. Aby to zrobić, użyj następującego polecenia cmdlet:
Set-VMHost -VirtualMachineMigrationPerformanceOption Compression
Jeśli używasz funkcji RDMA dla ruchu migracji na żywo, upewnij się, że ruch migracji na żywo nie może korzystać z całej przepustowości przydzielonej do klasy ruchu RDMA przy użyciu limitu przepustowości protokołu SMB. Należy zachować ostrożność, ponieważ to polecenie cmdlet przyjmuje wpis w bajtach na sekundę (Bps), natomiast karty sieciowe są wymienione w bitach na sekundę (bps). Użyj następującego polecenia cmdlet, aby ustawić limit przepustowości 6 Gb/s, na przykład:
Set-SMBBandwidthLimit -Category LiveMigration -BytesPerSecond 750MB
Uwaga
W tym przykładzie 750 MB/s odpowiada 6 Gb/s.
Oto przykładowa tabela alokacji przepustowości:
Szybkość karty sieciowej | Zespół przepustowości | Rezerwacja przepustowości protokołu SMB** | SBL/CSV % | Przepustowość SBL/CSV | Procent migracji na żywo | Maksymalna przepustowość migracji na żywo | % pulsu | Przepustowość pulsu |
---|---|---|---|---|---|---|---|---|
10 Gb/s | 20 Gb/s | 10 Gb/s | 70% | 7 Gb/s | ** | 200 Mb/s | ||
25 Gb/s | 50 Gb/s | 25 Gb/s | 70% | 17,5 Gb/s | 29% | 7,25 Gb/s | 1% | 250 Mb/s |
40 Gb/s | 80 Gb/s | 40 Gb/s | 70% | 28 Gb/s | 29% | 11,6 Gb/s | 1% | 400 Mb/s |
50 Gb/s | 100 Gb/s | 50 Gb/s | 70% | 35 Gb/s | 29% | 14,5 Gb/s | 1% | 500 Mb/s |
100 Gb/s | 200 Gb/s | 100 Gb/s | 70% | 70 Gb/s | 29% | 29 Gb/s | 1% | 1 Gb/s |
200 Gb/s | 400 Gb/s | 200 Gb/s | 70% | 140 Gb/s | 29% | 58 Gb/s | 1% | 2 Gb/s |
* Użyj kompresji, a nie RDMA, ponieważ alokacja przepustowości dla ruchu migracji na żywo wynosi <5 Gb/s.
** 50 procent to przykładowa rezerwacja przepustowości.
Klastry rozproszone
Klastry rozproszone zapewniają odzyskiwanie po awarii obejmujące wiele centrów danych. W najprostszej formie rozproszony sieć klastra rozwiązania Azure Stack HCI wygląda następująco:
Wymagania dotyczące klastra rozproszonego
Klastry rozproszone mają następujące wymagania i cechy:
Funkcja RDMA jest ograniczona do jednej lokacji i nie jest obsługiwana w różnych lokacjach lub podsieciach.
Serwery w tej samej lokacji muszą znajdować się w tym samym stojaku i granicy warstwy 2.
Komunikacja między lokacjami musi przekraczać granicę warstwy 3; topologie rozproszone warstwy 2 nie są obsługiwane.
Ma wystarczającą przepustowość, aby uruchamiać obciążenia w innej lokacji. W przypadku przejścia w tryb failover witryna alternatywna będzie musiała uruchomić cały ruch. Zalecamy aprowizowania lokacji na poziomie 50% ich dostępnej pojemności sieciowej. Nie jest to jednak wymagane, jeśli można tolerować niższą wydajność podczas pracy w trybie failover.
Replikacja między lokacjami (ruch północny/południowy) może używać tych samych fizycznych kart sieciowych co magazyn lokalny (ruch wschodni/zachodni). Jeśli używasz tych samych kart fizycznych, te karty muszą być zespołem z zestawem. Karty muszą również mieć dodatkowe wirtualne karty sieciowe aprowizowane dla ruchu routingowego między lokacjami.
Karty używane do komunikacji między lokacjami:
Może to być sieć wirtualna lub fizyczna (vNIC hosta). Jeśli karty są wirtualne, musisz aprowizować jedną kartę wirtualną w własnej podsieci i sieci VLAN na fizyczną kartę sieciową.
Musi znajdować się we własnej podsieci i sieci VLAN, która może kierować między lokacjami.
Funkcja RDMA musi być wyłączona
Disable-NetAdapterRDMA
przy użyciu polecenia cmdlet . Zalecamy jawne wymaganie, aby replika magazynu korzystałaSet-SRNetworkConstraint
z określonych interfejsów przy użyciu polecenia cmdlet .Musi spełniać wszelkie dodatkowe wymagania dotyczące repliki magazynu.
Przykład klastra rozproszonego
W poniższym przykładzie przedstawiono konfigurację klastra rozproszonego. Aby upewnić się, że określona wirtualna karta sieciowa jest mapowana na określoną kartę fizyczną, użyj polecenia cmdlet Set-VMNetworkAdapterTeammapping .
Poniżej przedstawiono szczegóły przykładowej konfiguracji rozproszonego klastra.
Uwaga
Dokładna konfiguracja, w tym nazwy kart sieciowych, adresy IP i sieci VLAN, może być inna niż pokazana. Jest to używane tylko jako konfiguracja referencyjna, którą można dostosować do środowiska.
SiteA — replikacja lokalna, włączona funkcja RDMA, bez routingu między lokacjami
Nazwa węzła | Nazwa sieci wirtualnej | Fizyczna karta sieciowa (mapowana) | Sieci vlan | Adres IP i podsieć | Zakres ruchu |
---|---|---|---|---|---|
NodeA1 | vSMB01 | pNIC01 | 711 | 192.168.1.1/24 | Tylko lokacja lokalna |
NodeA2 | vSMB01 | pNIC01 | 711 | 192.168.1.2/24 | Tylko lokacja lokalna |
NodeA1 | vSMB02 | pNIC02 | 712 | 192.168.2.1/24 | Tylko lokacja lokalna |
NodeA2 | vSMB02 | pNIC02 | 712 | 192.168.2.2/24 | Tylko lokacja lokalna |
SiteB — replikacja lokalna, włączona funkcja RDMA, bez routingu między lokacjami
Nazwa węzła | Nazwa sieci wirtualnej | Fizyczna karta sieciowa (mapowana) | Sieci vlan | Adres IP i podsieć | Zakres ruchu |
---|---|---|---|---|---|
WęzełB1 | vSMB01 | pNIC01 | 711 | 192.168.1.1/24 | Tylko lokacja lokalna |
WęzełB2 | vSMB01 | pNIC01 | 711 | 192.168.1.2/24 | Tylko lokacja lokalna |
WęzełB1 | vSMB02 | pNIC02 | 712 | 192.168.2.1/24 | Tylko lokacja lokalna |
WęzełB2 | vSMB02 | pNIC02 | 712 | 192.168.2.2/24 | Tylko lokacja lokalna |
SiteA — replikacja rozproszony, wyłączona funkcja RDMA, routing między lokacjami
Nazwa węzła | Nazwa sieci wirtualnej | Fizyczna karta sieciowa (mapowana) | Adres IP i podsieć | Zakres ruchu |
---|---|---|---|---|
NodeA1 | Stretch1 | pNIC01 | 173.0.0.1/8 | Routing między lokacjami |
NodeA2 | Stretch1 | pNIC01 | 173.0.0.2/8 | Routing między lokacjami |
NodeA1 | Stretch2 | pNIC02 | 174.0.0.1/8 | Routing między lokacjami |
NodeA2 | Stretch2 | pNIC02 | 174.0.0.2/8 | Routing między lokacjami |
SiteB — replikacja rozproszony, wyłączona funkcja RDMA, routing między lokacjami
Nazwa węzła | Nazwa sieci wirtualnej | Fizyczna karta sieciowa (mapowana) | Adres IP i podsieć | Zakres ruchu |
---|---|---|---|---|
WęzełB1 | Stretch1 | pNIC01 | 175.0.0.1/8 | Routing między lokacjami |
WęzełB2 | Stretch1 | pNIC01 | 175.0.0.2/8 | Routing między lokacjami |
WęzełB1 | Stretch2 | pNIC02 | 176.0.0.1/8 | Routing między lokacjami |
WęzełB2 | Stretch2 | pNIC02 | 176.0.0.2/8 | Routing między lokacjami |
Następne kroki
- Dowiedz się więcej o wymaganiach dotyczących przełącznika sieciowego i sieci fizycznej. Zobacz Wymagania dotyczące sieci fizycznej.
- Dowiedz się, jak uprościć sieć hosta przy użyciu usługi Network ATC. Zobacz Upraszczanie sieci hostów za pomocą usługi NETWORK ATC.
- Podstawy pracy w klastrze trybu failover.
- Zobacz Wdrażanie przy użyciu Azure Portal.
- Zobacz Wdrażanie przy użyciu szablonu usługi ARM.
Opinia
https://aka.ms/ContentUserFeedback.
Już wkrótce: w ciągu 2024 r. będziemy stopniowo usuwać problemy z usługą GitHub jako mechanizm opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź:Prześlij i wyświetl opinię dla