Granska nätverksreferensmönstret för distributionsnätverk med tre noder med tre noder, dubbla TOR och nätverksreferenser för en länk för Azure Local
Gäller för: Azure Local 2311.2 och senare
I den här artikeln får du lära dig mer om lagring med tre noder utan växel med två TOR L3-växlar och ett fullständigt nätverksreferensmönster med enkel länk som du kan använda för att distribuera din lokala Azure-lösning.
Kommentar
De växellösa nätverksreferensmönstren med 3 noder som beskrivs i den här artikeln har testats och verifierats av Microsoft. Information om nätverksmönster utan två noder finns i Distributionsmönster för lokala Azure-nätverk.
Scenarier
Scenarier för det här nätverksmönstret är laboratorier, fabriker, butiker, offentliga sektorer och myndigheter.
Överväg att implementera det här mönstret när du letar efter en kostnadseffektiv lösning som har feltolerans för alla nätverkskomponenter. L3-tjänster (Software Defined Network) (SDN) stöds fullt ut i det här mönstret. Routningstjänster som BGP (Border Gateway Protocol) kan konfigureras direkt på TOR-växlarna om de stöder L3-tjänster. Nätverkssäkerhetsfunktioner som mikrosegmentering eller tjänstkvalitet (QoS) kräver inte extra konfiguration av brandväggsenheten, eftersom de implementeras på ett virtuellt nätverkskortlager.
Fysiska anslutningskomponenter
Som du ser i diagrammet ovan har det här mönstret följande fysiska nätverkskomponenter:
- För norrgående och södergående kommunikation kräver Azure Local-instansen två TOR-växlar i MLAG-konfiguration (multi-chassi link aggregation group).
- Två nätverkskort som använder den virtuella SET-växeln för att hantera hanterings- och beräkningstrafik, anslutna till TOR-växlarna. Varje nätverkskort är anslutet till en annan TOR.
- Två RDMA-nätverkskort på varje nod i en enkellänkskonfiguration med fullständigt nät för trafik mellan öst och väst för lagringen.
Kommentar
För den här konfigurationen finns det ingen redundant nätverksanslutning mellan noderna.
Nätverk | Hantering och beräkning | Storage |
---|---|---|
Länkhastighet | Minst 1 GBIT/s. 10 GBIT/s rekommenderas | Minst 10 GBIT/s |
Gränssnittstyp | RJ45, SFP+ eller SFP28 | SFP+ eller SFP28 |
Portar och sammansättning | Två teamindelade portar | Två fristående portar |
Logiska nätverk
Som du ser i diagrammet nedan har det här mönstret följande logiska nätverkskomponenter:
Nodanslutningsnätverk VLAN för SMB-trafik (lagring och direktmigrering)
Avsiktsbaserad lagringstrafik består av tre enskilda undernät som stöder RDMA-trafik. Varje gränssnitt är dedikerat till ett separat nodanslutningsnätverk. Den här trafiken är endast avsedd att färdas mellan de tre noderna. Lagringstrafiken på dessa undernät är isolerad utan anslutning till andra resurser.
Varje par med lagringskort mellan noderna fungerar i olika IP-undernät. För att aktivera en växellös konfiguration stöder varje ansluten nod samma matchande undernät för grannen.
När du distribuerar en växellös konfiguration med tre noder har Network ATC följande krav:
Stöder endast ett enda VLAN för alla IP-undernät som används för lagringsanslutning.
StorageAutoIP
parametern måste vara inställd på false,Switchless
parametern måste vara inställd på true och du är ansvarig för att ange IP-adresser för ARM-mallen som används för att distribuera den lokala Azure-instansen från Azure.För azure local- och version 23H2-molndistributioner:
Utskalning av växellösa lagringssystem stöds inte.
Det går bara att distribuera det här scenariot med tre noder med hjälp av ARM-mallar.
Mer information finns i Distribuera via Azure Resource Manager-distributionsmall.
VLAN för hantering
Alla fysiska beräkningsvärdar måste ha åtkomst till det logiska hanteringsnätverket. I planeringssyfte för IP-adresser måste varje värd ha minst en IP-adress tilldelad från det logiska hanteringsnätverket.
En DHCP-server kan automatiskt tilldela IP-adresser för hanteringsnätverket, eller så kan du tilldela statiska IP-adresser manuellt. När DHCP är den föredragna IP-tilldelningsmetoden rekommenderas DHCP-reservationer utan förfallodatum.
Mer information finns i ÖVERVÄGANDEN för DHCP-nätverk för molndistribution.
Hanteringsnätverket stöder två olika VLAN-konfigurationer för trafik – intern och taggad. Följande överväganden gäller för varje konfiguration:
Internt VLAN för hanteringsnätverk kräver inte att du anger ett VLAN-ID.
Taggat VLAN för hanteringsnätverk kräver VLAN ID-konfiguration på de fysiska nätverkskorten eller det virtuella nätverkskortet för hantering innan noderna registreras i Azure Arc.
Fysiska växelportar måste konfigureras korrekt för att acceptera VLAN-ID:t på hanteringskorten.
Om avsikten innehåller trafiktyper för hantering och beräkning måste de fysiska växelportarna konfigureras i trunkläge för att acceptera alla VLAN som krävs för hanterings- och beräkningsarbetsbelastningar.
Hanteringsnätverket stöder trafik som används av administratören för hantering av systemet, inklusive Fjärrskrivbord, Windows Administrationscenter och Active Directory.
Mer information finns i Hantering av VLAN-nätverksöverväganden.
Beräknings-VLAN
I vissa scenarier behöver du inte använda SDN Virtual Networks med VXLAN-inkapsling. I stället kan du använda traditionella VLAN för att isolera sina klientarbetsbelastningar. Dessa VLAN måste konfigureras på TOR-växlar porten i trunkläge. När du ansluter nya virtuella datorer till dessa VLAN definieras motsvarande VLAN-tagg på det virtuella nätverkskortet.
PA-nätverk (HNV Provider Address)
HNV PA-nätverket (Hyper-V Network Virtualization Provider Address) fungerar som det underliggande fysiska nätverket för klienttrafik mellan öst och väst (intern) klientorganisation, klienttrafik från nord-syd (extern-intern) och för att utbyta BGP-peeringinformation med det fysiska nätverket. Det här nätverket krävs bara när det finns ett behov av att distribuera virtuella nätverk med hjälp av VXLAN-inkapsling för ett extra lager av isolering och nätverks multitenancy.
Mer information finns i Planera en programvarudefinierad nätverksinfrastruktur.
Atc-avsikter för nätverk
För växlingslösa mönster för lagring med tre noder skapas två network ATC-avsikter. Den första avsikten är för hantering och beräkning av nätverkstrafik, och den andra avsikten är för lagringstrafik.
Avsikt att hantera och beräkna
- Avsiktstyp: Hantering och beräkning
- I tältläge: Klusterläge
- Teamindelning: Ja. pNIC01- och pNIC02-team
- VLAN för standardhantering: Konfigurerat VLAN för hanteringskort ändras inte.
- PA- och beräknings-VLAN och virtuella nätverkskort: Nätverks-ATC är transparent för PA vNICs och VLAN eller beräknings-VM vNICs och VLAN.
Lagrings avsikt
Avsiktstyp: Lagring
I tältläge: Klusterläge
Teamindelning: Nej. RDMA-nätverkskort använder SMB Multichannel för att tillhandahålla återhämtning och bandbreddsaggregering.
Standard-VLAN: enskilt VLAN för alla undernät
Automatisk IP-adress för lagring: False. Det här mönstret kräver manuell IP-konfiguration eller IP-definition för ARM-mallar.
Tre undernät krävs (användardefinierade):
- Lagringsnätverk 1: 10.0.1.0/24 –
Node1 -> Node2
- Lagringsnätverk 2: 10.0.2.0/24 –
Node1 -> Node2
- Lagringsnätverk 3: 10.0.3.0/24 –
Node2 -> Node3
- Lagringsnätverk 1: 10.0.1.0/24 –
Mer information finns i Distribuera värdnätverk med Network ATC.
Exempel på nätverkskonfiguration för ARM-mall för lagrings avsikt
Du kan använda ARM-mallen för växlingslös lagring med 3 noder, dubbel TOR och enkel länk.
Här är ett kodfragment från mallen:
"storageNetworkList": {
"value": [
{
"name": "StorageNetwork1",
"networkAdapterName": "SMB1",
"vlanId": "711",
"storageAdapterIPInfo": [
{
"physicalNode": "Node1",
"ipv4Address": "10.0.1.1",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node2",
"ipv4Address": "10.0.1.2",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node3",
"ipv4Address": "10.0.2.1",
"subnetMask": "255.255.255.0"
}
]
},
{
"name": "StorageNetwork2",
"networkAdapterName": "SMB2",
"vlanId": "711",
"storageAdapterIPInfo": [
{
"physicalNode": "Node1",
"ipv4Address": "10.0.2.2",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node2",
"ipv4Address": "10.0.3.1",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node3",
"ipv4Address": "10.0.3.2",
"subnetMask": "255.255.255.0"
}
]
}
]
},