Tekintse át az Azure Stack HCI három csomópontos, kapcsoló nélküli, kettős TOR és kettős kapcsolatú üzembehelyezési hálózati referenciamintáját
> A következőkre vonatkozik: Azure Stack HCI, 23H2-es és újabb verzió
Ebben a cikkben megismerheti a háromcsomópontos, két TOR L3 kapcsolóval és két teljes hálós kapcsolati hálózati referenciamintával rendelkező háromcsomópontos tárolókapcsolót, amellyel üzembe helyezheti az Azure Stack HCI-megoldást.
Megjegyzés
A cikkben ismertetett háromcsomópontos kapcsoló nélküli hálózati referenciamintákat a Microsoft tesztelte és ellenőrizte. A kétcsomópontos kapcsoló nélküli hálózati mintákkal kapcsolatos információkért tekintse meg az Azure Stack HCI hálózati üzembehelyezési mintáit ismertető cikket.
Forgatókönyvek
Ehhez a hálózati mintához tartoznak a laboratóriumok, a gyárak, a fiókirodák és az adatközpontok.
Érdemes lehet ezt a mintát implementálni, ha olyan költséghatékony megoldást keres, amely hibatűréssel rendelkezik az összes hálózati összetevőben. Az SDN L3-szolgáltatások teljes mértékben támogatottak ebben a mintában. Az útválasztási szolgáltatások, például a Border Gateway Protocol (BGP) közvetlenül konfigurálhatók a TOR kapcsolókon, ha támogatják az L3-szolgáltatásokat. Az olyan hálózati biztonsági funkciók, mint a mikroszegmentálás vagy a QoS, nem igényelnek további konfigurációt a tűzfaleszközhöz, mivel a virtuális hálózati adapter rétegében vannak implementálva.
Fizikai kapcsolati összetevők
A fenti ábrán látható módon ez a minta a következő fizikai hálózati összetevőket tartalmazza:
Az északi és a déli kommunikációhoz az Azure Stack HCI-fürtnek két TOR-kapcsolóra van szüksége a többvázlatos kapcsolati aggregációs csoport (MLAG) konfigurációjában.
A SET virtuális kapcsolót használó két hálózati kártya kezeli a tor kapcsolókhoz csatlakoztatott felügyeleti és számítási forgalmat. Minden hálózati adapter egy másik TOR-hez csatlakozik.
Négy RDMA hálózati adapter minden csomóponton egy teljes hálós kettős kapcsolatú konfigurációban a tároló forgalmának East-West érdekében. A fürt minden csomópontja redundáns kapcsolattal rendelkezik, amely a fürt másik csomópontjának két útvonalával rendelkezik.
| Hálózatok | Felügyelet és számítás | Tárolás |
|---|---|---|
| Kapcsolat sebessége | Legalább 1 GBps. 10 GBps ajánlott | Legalább 10 GBps |
| Interfész típusa | RJ45, SFP+ vagy SFP28 | SFP+ vagy SFP28 |
| Portok és összesítés | Két összevonási port | Négy különálló port |
Logical networks
Az alábbi ábrán látható módon ez a minta a következő logikai hálózati összetevőket tartalmazza:
Csomópontok összekapcsolása hálózatok VLAN-nal az SMB-forgalomhoz (tárolás és élő migrálás)
A Storage szándékalapú forgalma hat különálló alhálózatból áll, amelyek támogatják az RDMA-forgalmat. Minden adapter külön csomópont-összekapcsolási hálózathoz van osztva. Ez a forgalom csak a három csomópont közötti közlekedésre szolgál. Ezeken az alhálózatokon a tárforgalom el van különítve, és nem kapcsolódik más erőforrásokhoz.
A csomópontok közötti tárolóadapterpárok különböző IP-alhálózatokon működnek. A kapcsoló nélküli konfiguráció engedélyezéséhez minden csatlakoztatott csomópont ugyanazt az alhálózatot támogatja, mint a szomszédja.
Ha három csomópontot helyez üzembe egy kapcsoló nélküli konfigurációban, a hálózati ATC a következő követelményekkel rendelkezik:
Csak egyetlen VLAN-t támogat a tárolókapcsolathoz használt összes IP-alhálózathoz.
StorageAutoIPA paramétert false (hamis) értékre kell állítani,Switchlessa paramétert true (igaz) értékre kell állítani, és Önnek kell megadnia az Azure Stack HCI-fürt Azure-ból történő üzembe helyezéséhez használt ARM-sablon IP-címeit.Az Azure Stack HCI 23H2-es felhőbeli üzemelő példányai esetén:
A tárolókapcsoló nélküli fürtök vertikális felskálázása nem támogatott.
Ezt a háromcsomópontos forgatókönyvet csak ARM-sablonokkal lehet üzembe helyezni.
További információ: Üzembe helyezés az Azure Resource Manager üzembe helyezési sablonon keresztül.
Felügyeleti VLAN
Minden fizikai számítási gazdagépnek hozzá kell férnie a felügyeleti logikai hálózathoz. Ip-címtervezési célokból minden gazdagépnek rendelkeznie kell legalább egy, a felügyeleti logikai hálózatból hozzárendelt IP-címmel.
A DHCP-kiszolgáló automatikusan hozzárendelhet IP-címeket a felügyeleti hálózathoz, vagy manuálisan is hozzárendelhet statikus IP-címeket. Ha a DHCP az előnyben részesített IP-hozzárendelési módszer, a lejárat nélküli DHCP-foglalások használata javasolt.
További információ: DHCP-hálózatokkal kapcsolatos szempontok a felhőbeli üzembe helyezéshez.
A felügyeleti hálózat két különböző VLAN-konfigurációt támogat a forgalomhoz – natív és címkézett:
A felügyeleti hálózat natív VLAN-azonosítója nem követeli meg, hogy VLAN-azonosítót adjon meg.
A felügyeleti hálózat címkézett VLAN-jának használatához vLAN-azonosító-konfigurációra van szükség a fizikai hálózati adaptereken vagy a felügyeleti virtuális hálózati adapteren, mielőtt regisztrálja a csomópontokat az Azure Arcban.
A fizikai kapcsolóportokat megfelelően kell konfigurálni, hogy elfogadják a VLAN-azonosítót a felügyeleti adaptereken.
Ha a szándék felügyeleti és számítási forgalomtípusokat is tartalmaz, a fizikai kapcsolóportokat csomagtartó módban kell konfigurálni a felügyeleti és számítási számítási feladatokhoz szükséges összes VLAN elfogadásához.
A felügyeleti hálózat támogatja a rendszergazda által a fürt felügyeletére használt forgalmat, beleértve a távoli asztalt, a Windows Admin Center és az Active Directoryt.
További információ: Felügyeleti VLAN-hálózatokkal kapcsolatos szempontok.
Számítási VLAN-k
Bizonyos esetekben nem kell SDN virtuális hálózatokat VXLAN-beágyazással használnia. Ehelyett a hagyományos VLAN-okkal elkülönítheti a bérlői számítási feladatokat. Ezeket a VLAN-okat a TOR kapcsolók portján kell konfigurálni törzs módban. Amikor új virtuális gépeket csatlakoztat ezekhez a VLAN-okhoz, a megfelelő VLAN-címke van definiálva a virtuális hálózati adapteren.
HNV-szolgáltatói cím (PA) hálózat
A Hyper-V hálózatvirtualizálási szolgáltatói cím (HNV PA) hálózat szolgál alapul szolgáló fizikai hálózatként East-West (belső-belső) bérlői forgalomhoz, North-South (külső-belső) bérlői forgalomhoz, valamint bGP társviszony-létesítési információk cseréjéhez a fizikai hálózattal. Erre a hálózatra csak akkor van szükség, ha VXLAN-beágyazással kell üzembe helyezni virtuális hálózatokat egy további elkülönítési és hálózati több-bérlős réteghez.
További információ: Szoftveralapú hálózati infrastruktúra tervezése.
Hálózati ATC-szándékok
Három csomópontos, kapcsoló nélküli tárolási mintákhoz két hálózati ATC-szándék jön létre. Az első szándék a felügyeleti és számítási hálózati forgalom, a második pedig a tárolási forgalom.
Felügyeleti és számítási szándék
- Szándék típusa: Felügyelet és számítás
- Szándék mód: Fürt mód
- Összevonás: Igen. pNIC01 és pNIC02 csapat.
- Alapértelmezett felügyeleti VLAN: A felügyeleti adapterekhez konfigurált VLAN nincs módosítva.
- PA- és számítási VLAN-k és vNIC-k: A hálózati ATC transzparens a pa vNI-k és VLAN-k, illetve a számítási virtuális gépek virtuális hálózati adapterei és VLAN-jai számára.
Tárolási szándék
Szándék típusa: Storage
Szándék mód: Fürt mód
Összevonás: Nem. Az RDMA hálózati adapterek többcsatornás SMB-vel biztosítják a rugalmasságot és a sávszélesség-összesítést.
Alapértelmezett VLAN-k: egyetlen VLAN az összes alhálózathoz.
Tárterület automatikus IP-címe: Hamis. Ehhez a mintához manuális IP-konfiguráció vagy ARM-sablon IP-definíciója szükséges.
Hat alhálózat szükséges (felhasználó definiálva):
- 1. tárolóhálózat: 10.0.1.0/24 –
Node1 -> Node2 - 2. tárolóhálózat: 10.0.2.0/24 –
Node1 -> Node2 - 3. tárolóhálózat: 10.0.3.0/24 –
Node2 -> Node3 - Storage Network 4: 10.0.4.0/24 –
Node1 -> Node3 - Tárolóhálózat 5: 10.0.5.0/24 –
Node1 -> Node3 - Storage Network 6: 10.0.6.0/24 –
Node2 -> Node3
- 1. tárolóhálózat: 10.0.1.0/24 –
További információ: Gazdagéphálózat üzembe helyezése hálózati ATC-vel.
ARM-sablon – Tárolási szándékú hálózatok konfigurációs példája
Az ARM-sablont három csomópontos, kapcsoló nélküli, kettős TOR és kettős kapcsolat tárolására használhatja.
"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"
}
]
}
]
},
Visszajelzés
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ: https://aka.ms/ContentUserFeedback.
Visszajelzés küldése és megtekintése a következőhöz: