Controleer het netwerkverwijzingspatroon voor opslag zonder drie knooppunten, dubbele TOR, netwerkverwijzingspatroon voor dubbele koppeling voor Azure Local
Van toepassing op: Azure Local 2311.2 en hoger
In dit artikel vindt u meer informatie over de opslag zonder drie knooppunten met twee TOR L3-switches en twee netwerkreferentiepatronen voor volledige mesh-koppelingen die u kunt gebruiken om uw lokale Azure-oplossing te implementeren.
Notitie
De referentiepatronen voor 3 knooppunten die in dit artikel worden beschreven, zijn getest en gevalideerd door Microsoft. Zie Voor meer informatie over netwerkpatronen zonder twee knooppunten, patronen voor lokale netwerkimplementaties in Azure.
Scenario's
Scenario's voor dit netwerkpatroon zijn laboratoria, fabrieken, filialen en datacenters.
Overweeg dit patroon te implementeren wanneer u op zoek bent naar een kostenefficiënte oplossing met fouttolerantie voor alle netwerkonderdelen. SDN L3-services worden volledig ondersteund op dit patroon. Routeringsservices zoals Border Gateway Protocol (BGP) kunnen rechtstreeks op de TOR-switches worden geconfigureerd als ze L3-services ondersteunen. Voor netwerkbeveiligingsfuncties zoals microsegmentatie of QoS is geen extra configuratie van het firewallapparaat vereist, omdat ze worden geïmplementeerd op de laag van de virtuele netwerkadapter.
Onderdelen van fysieke connectiviteit
Zoals u in het bovenstaande diagram kunt zien, heeft dit patroon de volgende fysieke netwerkonderdelen:
Voor northbound- en zuidkomende communicatie vereist het Lokale Azure-exemplaar twee TOR-switches in de MLAG-configuratie (Multi-Chassis Link Aggregation Group).
Twee netwerkkaarten die virtuele SET-switch gebruiken om beheer- en rekenverkeer te verwerken, verbonden met de TOR-switches. Elke NIC is verbonden met een andere TOR.
Vier RDMA-NIC's op elk knooppunt in een full-mesh dubbele koppelingsconfiguratie voor oost-West-verkeer voor de opslag. Elk knooppunt in het systeem heeft een redundante verbinding met twee paden naar het andere knooppunt in het systeem.
Netwerken | Beheer en rekenkracht | Storage |
---|---|---|
Snelheid van koppeling | Ten minste 1 GBps. 10 GBps aanbevolen | Ten minste 10 GBps |
Interfacetype | RJ45, SFP+ of SFP28 | SFP+ of SFP28 |
Poorten en aggregatie | Twee gekoppelde poorten | Vier zelfstandige poorten |
Logische netwerken
Zoals wordt geïllustreerd in het onderstaande diagram, heeft dit patroon de volgende onderdelen van het logische netwerk:
VLAN van knooppuntconnectnetwerken voor SMB-verkeer (opslag en livemigratie)
Het op intentie gebaseerde opslagverkeer bestaat uit zes afzonderlijke subnetten die RDMA-verkeer ondersteunen. Elke interface is toegewezen aan een afzonderlijk knooppuntverbindingsnetwerk. Dit verkeer is alleen bedoeld om tussen de drie knooppunten te reizen. Opslagverkeer op deze subnetten wordt geïsoleerd zonder verbinding met andere resources.
Elk paar opslagadapters tussen de knooppunten werkt in verschillende IP-subnetten. Als u een switchloze configuratie wilt inschakelen, ondersteunt elk verbonden knooppunt hetzelfde overeenkomende subnet van de buurman.
Bij het implementeren van drie knooppunten in een switchloze configuratie heeft Network ATC de volgende vereisten:
Ondersteunt slechts één VLAN voor alle IP-subnetten die worden gebruikt voor opslagconnectiviteit.
StorageAutoIP
parameter moet worden ingesteld op onwaar,Switchless
parameter moet worden ingesteld op waar en u bent verantwoordelijk voor het opgeven van de IP-adressen in de ARM-sjabloon die wordt gebruikt voor het implementeren van het lokale Azure-exemplaar vanuit Azure.Voor Azure Local versie 23H2-cloudimplementaties:
Schakelbare opslagsystemen uitschalen worden niet ondersteund.
Het is alleen mogelijk om dit scenario met drie knooppunten te implementeren met behulp van ARM-sjablonen.
Zie Implementeren via een Azure Resource Manager-implementatiesjabloon voor meer informatie.
Beheer-VLAN
Alle fysieke rekenhosts moeten toegang hebben tot het logische beheernetwerk. Voor planning van IP-adressen moet aan elke host ten minste één IP-adres zijn toegewezen vanuit het logische beheernetwerk.
Een DHCP-server kan automatisch IP-adressen toewijzen voor het beheernetwerk of u kunt handmatig statische IP-adressen toewijzen. Wanneer DHCP de voorkeursmethode voor IP-toewijzing is, worden DHCP-reserveringen zonder vervaldatum aanbevolen.
Zie overwegingen voor DHCP-netwerk voor cloudimplementatie voor meer informatie.
Het beheernetwerk ondersteunt twee verschillende VLAN-configuraties voor verkeer: systeemeigen en getagd:
Systeemeigen VLAN voor beheernetwerk vereist niet dat u een VLAN-id opgeeft.
Voor het gelabelde VLAN voor het beheernetwerk is VLAN-id-configuratie vereist op de fysieke netwerkadapters of de virtuele netwerkadapter voor beheer voordat u de knooppunten in Azure Arc registreert.
Fysieke switchpoorten moeten correct worden geconfigureerd om de VLAN-id op de beheeradapters te accepteren.
Als de intentie beheer- en rekenverkeerstypen bevat, moeten de fysieke switchpoorten worden geconfigureerd in de trunk-modus om alle VLAN's te accepteren die vereist zijn voor beheer- en rekenworkloads.
Het beheernetwerk ondersteunt verkeer dat door de beheerder wordt gebruikt voor het beheer van het systeem, waaronder Extern bureaublad, Windows-beheercentrum en Active Directory.
Zie Overwegingen voor het beheer van VLAN-netwerken voor meer informatie.
VLAN's berekenen
In sommige scenario's hoeft u geen SDN Virtual Networks te gebruiken met VXLAN-inkapseling. In plaats daarvan kunt u traditionele VLAN's gebruiken om hun tenantworkloads te isoleren. Deze VLAN's moeten worden geconfigureerd op de TOR-switchespoort in de trunk-modus. Wanneer u nieuwe virtuele machines verbindt met deze VLAN's, wordt de bijbehorende VLAN-tag gedefinieerd op de virtuele netwerkadapter.
HNV Provider Address (PA) netwerk
Het HNV PA-netwerk (Hyper-V Network Virtualization Provider Address) fungeert als het onderliggende fysieke netwerk voor tenantverkeer oost-west (intern) tenantverkeer, noord-zuid (extern-intern) tenantverkeer en om BGP-peeringgegevens uit te wisselen met het fysieke netwerk. Dit netwerk is alleen vereist wanneer er behoefte is aan het implementeren van virtuele netwerken met VXLAN-inkapseling voor een extra isolatielaag en netwerk multitenancy.
Zie Een software-gedefinieerde netwerkinfrastructuur plannen voor meer informatie.
Atc-intenties voor netwerken
Voor switchloze patronen voor opslag met drie knooppunten worden twee netwerk-ATC-intenties gemaakt. De eerste intentie is voor beheer- en rekennetwerkverkeer en de tweede intentie is voor opslagverkeer.
Beheer- en rekenintentie
- Intentietype: Beheer en compute
- In tentmodus: clustermodus
- Teaming: Ja. pNIC01- en pNIC02-team.
- Standaardbeheer-VLAN: geconfigureerde VLAN voor beheeradapters wordt niet gewijzigd.
- PA en reken-VLAN's en vNIC's: Netwerk-ATC is transparant voor PA vNICs en VLAN's of reken-VM vNICs en VLAN's.
Opslagintentie
Intentietype: Opslag
In tentmodus: clustermodus
Teaming: Nee. RDMA-NIC's maken gebruik van SMB meerdere kanalen om tolerantie en bandbreedteaggregatie te bieden.
Standaard-VLAN's: één VLAN voor alle subnetten.
Automatisch IP-adres van opslag: onwaar. Dit patroon vereist handmatige IP-configuratie of IP-definitie van ARM-sjabloon.
Zes subnetten vereist (door de gebruiker gedefinieerd):
- Opslagnetwerk 1: 10.0.1.0/24 –
Node1 -> Node2
- Opslagnetwerk 2: 10.0.2.0/24 –
Node1 -> Node2
- Opslagnetwerk 3: 10.0.3.0/24 –
Node2 -> Node3
- Opslagnetwerk 4: 10.0.4.0/24 –
Node1 -> Node3
- Opslagnetwerk 5: 10.0.5.0/24 –
Node1 -> Node3
- Opslagnetwerk 6: 10.0.6.0/24 –
Node2 -> Node3
- Opslagnetwerk 1: 10.0.1.0/24 –
Zie Hostnetwerken implementeren met Network ATC voor meer informatie.
Voorbeeld van configuratie van opslagintentienetwerken met ARM-sjabloon
U kunt de ARM-sjabloon gebruiken voor opslagwisselloos met drie knooppunten, dubbele TOR en dubbele koppeling.
"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.5.3",
"subnetMask": "255.255.255.0"
}
]
},
{
"name": "StorageNetwork2",
"networkAdapterName": "SMB2",
"vlanId": "711",
"storageAdapterIPInfo": [
{
"physicalNode": "Node1",
"ipv4Address": "10.0.2.1",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node2",
"ipv4Address": "10.0.2.2",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node3",
"ipv4Address": "10.0.4.3",
"subnetMask": "255.255.255.0"
}
]
},
{
"name": "StorageNetwork3",
"networkAdapterName": "SMB3",
"vlanId": "711",
"storageAdapterIPInfo": [
{
"physicalNode": "Node1",
"ipv4Address": "10.0.5.1",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node2",
"ipv4Address": "10.0.3.2",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node3",
"ipv4Address": "10.0.3.3",
"subnetMask": "255.255.255.0"
}
]
},
{
"name": "StorageNetwork4",
"networkAdapterName": "SMB4",
"vlanId": "711",
"storageAdapterIPInfo": [
{
"physicalNode": "Node1",
"ipv4Address": "10.0.4.2",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node2",
"ipv4Address": "10.0.6.1",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node3",
"ipv4Address": "10.0.6.3",
"subnetMask": "255.255.255.0"
}
]
}
]
},