Hálózati referenciaminták áttekintése az Azure Local lokálisan szétszórt üzemelő példányaihoz

Ez a cikk áttekintést nyújt az Azure Local nem összesített üzemelő példányainak hálózati referenciamintáiról. Ebben az útmutatóban megismerheti a levél-gerinc szövet architektúrát, az állványok közötti forgalom áramlását, valamint azt, hogy a külső kapcsolatok hogyan kezelhetők a szolgáltatás levélkapcsolóival.

Mi az a nem összesített üzembe helyezés?

Szeparált telepítés esetén a számítási kapacitás és a tárolás egymástól elkülönül. A tárolót egy külső tárolóhálózat (SAN), például Fibre Channel (FC) vagy iSCSI biztosítja az egyes kiszolgálócsomópontokon belüli helyi lemezek helyett. Ez az elkülönítés lehetővé teszi, hogy a számítás, a tárolás és a hálózat egymástól függetlenül skálázható legyen – állványokat adhat hozzá saját levélkapcsolópárokkal a nagyobb számítási kapacitás érdekében, bővítheti a SAN-t több tárhelyhez, vagy gerinckapcsolókat adhat hozzá az állványok közötti sávszélesség növeléséhez.

A szétválasztott telepítés egycsomópontos vagy többcsomópontos rendszerekből áll (fürtönként legfeljebb 64 csomóponttal), a következő jellemzőkkel rendelkeznek:

Note

Nem minden feloszlott üzembe helyezés több állványra terjed ki. Ha a szétválasztott fürt továbbra is egyállványos marad, és nem igényel nagy léptékű SDN-t, használhatja az egyszerűbb egyállványos topológiát egy két switchből álló HSRP-párral.

• Legalább két service leaf hálózati kapcsoló a külső kapcsolathoz.
• Legalább két gerinchálózati kapcsoló a rackek közötti átjáráshoz.
• Állványonként legalább két levél (állvány tetején) hálózati kapcsoló.
• Kiszolgálónként legalább négy hálózati adapterport – két port a felügyeleti és számítási szándékhoz, valamint két port a fürthálózatokhoz. A szétválasztott üzembe helyezések esetén a fürthálózatok különálló portokat használnak hálózati ATC-szándék nélkül, és az üzembe helyezés során automatikusan konfigurálják magukat.
• A Fibre Channel (FC) SAN-konfigurációiban a tárolási forgalom teljes egészében az FC-hálón fut, az Ethernet-hálózattól elkülönítve.
• Az iSCSI SAN-konfigurációkban a tárolási forgalom dedikált Ethernet-adaptereken és dedikált iSCSI-tárolóhálón fut.

Támogatott, nem összesített hálózati referenciaminták

Az alábbi hálózati referenciaminták érhetők el a szétválasztott telepítésekhez:

Tárolókapcsolat	Hálózat biztonsági mentése	Referenciaminta
Fiber Channel SAN	Nincs dedikált biztonsági mentési hálózat	Szálcsatornás bontási minta biztonsági mentési hálózat nélkül
Fiber Channel SAN	Dedikált biztonsági mentési hálózat	Szálcsatornás bontási minta biztonsági mentési hálózattal
iSCSI SAN	Nem kötelező vendégalapú biztonsági mentési hálózat (üzembe helyezés után hozzáadva)	iSCSI 6-NIC szétválasztott kialakítás

Miért érdemes levél-gerinc (Clos) topológiát használni?

A hagyományos, két switchből álló kialakítás (egy pár Top of Rack, azaz ToR switch) kis klaszterek esetén megfelelően működik, de nem skálázódik jól. Több állvány 64 csomópontján:

• Portkorlátok – Egy állvány tetején (TOR) lévő kapcsoló körülbelül 48 porttal rendelkezik, és nem tud 64 vagy több csomópontot csatlakoztatni.
• Meghibásodási hatás – Ha egy kapcsoló meghibásodik, a fürt fele elveszíti a kapcsolatot.
• Sávszélességbeli szűk keresztmetszet – Az összes állványközi forgalom egyetlen pár felkapcsolaton keresztül halad.

A levél-gerinc (Clos) topológia ezeket a problémákat egy dedikált gerincréteg hozzáadásával oldja meg, amely összekapcsolja az összes állványt. Minden állvány saját levélkapcsolópárt kap. Minden levélkapcsoló csatlakozik a megosztott gerinckapcsolókhoz. A rackek közötti forgalom a következőképpen alakul: Leaf → Spine → Leaf - soha nem haladja meg a három ugrást.

Gondolj rá úgy, mint egy autópálya-rendszer:

Hálózati koncepció	Autópálya-analógia
Levélkapcsolók (állvány tetején)	Helyi utak, amelyek közvetlenül a házhoz (szerverekhez) csatlakoznak.
Gerinckapcsolók	Autópálya-csomópontok, amelyek összekötik az összes helyi utat.
Nodes	Házak, ahol emberek (számítási feladatok) élnek.
Virtuális útválasztás és továbbítás (VRF)	Különítse el azokat az autópálya-rendszereket, amelyek nem osztanak meg kijáratokat (forgalomelkülönítés).
Virtuális bővíthető LAN (VXLAN)	Alagutak, amelyek lehetővé teszik, hogy a helyi utak átterjednek az autópályákon.
Szolgáltatási levél	A határ-ellenőrzőpont, ahol a forgalom belép vagy kilép az autópálya-rendszerből.

Túljelentkezés

A levél-gerinc réteget úgy tervezték, hogy legalább 2:1 túltelődési arányt (levél lefelé irányuló sávszélesség a levél-gerinc uplink sávszélességhez képest) biztosítson normál műveletek alatt.

Tip

Mi a túljelentkezés? A 2:1 arány azt jelenti, hogy az egyes leveleken a kiszolgáló felé irányuló teljes sávszélesség kétszer akkora, mint a gerincekhez való felfelé irányuló kapcsolódások sávszélessége. Ha például egy levél 48 × 25 GbE gazdagépportot (összesen 1200 Gbps) és 4 × 100 GbE-os gerinckiemelést (400 Gbps), az arány 3:1. Normál körülmények között nem minden kiszolgáló továbbít teljes sebességgel egyidejűleg, ezért a közepes túljelentkezés elfogadható.

A gerinc meghibásodása vagy a karbantartási időszak során a tényleges túljelentkezés 4:1-re nőhet. Ebben az időszakban a nagy kelet–nyugati (rackek közötti) forgalmat bonyolító munkaterhelések csökkent átviteli teljesítményt tapasztalhatnak, amíg a spine réteg teljes kapacitása helyre nem áll.

A torlódás kockázatának csökkentése és a rugalmasság javítása érdekében horizontálisan skálázza a gerincréteget a környezet növekedésével. A gerinckapcsolók hozzáadása növeli az összesített levél-gerinc sávszélességet, és több Equal-Cost többutas (ECMP) elérési utat ad hozzá, ami növeli a teljesítményt és a hibatűrést is.

A háló működése

A levél-gerinc háló három rétegre épül: az alapréteg, amely a kapcsolók közötti útválasztást biztosítja, az átfedő réteg a VLAN-ok állványok közötti kiterjesztésére, valamint a Virtual Routing and Forwarding (VRF) szegmentáció a forgalomtípusok elkülönítéséhez.

Aláfedés – eBGP-útválasztás kapcsolók között

Az alréteg az irányított 3. rétegű hálózat, amely az összes levél- és gerinckapcsolót összeköti. Külső Border Gateway Protocolt (eBGP) használ számozatlan interfészekkel (RFC 5549), ami azt jelenti, hogy minden kapcsoló-kapcsoló link IPv6 kapcsolati helyi címeket használ BGP peeringhez, nem pedig manuálisan hozzárendelt /30 vagy /31 alhálózatokat. Minden állvány egyedi BGP autonóm rendszerszámot (ASN) kap. Equal-Cost Multipath (ECMP) elosztja a forgalmat az összes elérhető gerinchálózati útvonal között.

Note

A BGP számozatlan használata javasolt, de a /31 pont-pont alhálózatok használata is támogatott. A működési beállítások alapján válasszon bármelyik metódust.

Az aláfedés az alapértelmezett virtuális útválasztási és továbbítási (VRF) példányban (a globális útválasztási táblában) fut, de csak infrastruktúraként kezeli – csak visszacsatolási címeket és BGP-társútvonalakat tartalmaz. Nincs alapértelmezett útvonal (0.0.0.0/0) beszúrva az alaprétegbe, és a terhelési előtagok nem szivárognak bele. Minden számítási feladat forgalmát dedikált átfedéses VRF-ekben izoláljuk, mindegyik a saját VXLAN hálózati azonosítójára (VNI) van leképezve. Az underlay hálózat soha nem látja a bérlők vagy a fürtök IP-címeit – azok a hálózati szövetbe való belépés előtt VXLAN-alagutakba vannak kapszulázva.

Ez az elkülönítés a kritikus biztonsági határ. Ha egy hibás konfigurációs vagy hibás útvonalhirdetés egy átfedésben lévő VRF-ben fordul elő, az nem befolyásolhatja az aláfedést vagy más VRF-eket – ezeket alapvetően a VXLAN-beágyazás választja el egymástól.

Overlay – VXLAN EVPN a VLAN-ok rackszekrények közötti kiterjesztéséhez

Az Azure Local megköveteli, hogy bizonyos VLAN-ok, például a felügyeleti és számítási VLAN-ok, minden rackben rendelkezésre álljanak. Mivel a VLAN-ok olyan 2. rétegbeli szegmensek, amelyek hagyományosan nem képesek átfogni az irányított határokat, a Virtual Extensible LAN (VXLAN) ezt úgy oldja meg, hogy a 2. rétegbeli kereteket a 3. rétegbeli csomagokba csomagolja. Minden VLAN egy egyedi VXLAN hálózati azonosítóra (VNI) van leképezve, és ez a VLAN-leképezés minden rack esetében egységes.

Az Ethernet virtuális magánhálózat (EVPN) egy BGP-alapú vezérlősík, amely minden olyan kapcsolót tájékoztat, ahol az egyes MAC- és IP-címek élnek – a hálózat elárasztása nélkül.

Szegmentálás – VRF-k a forgalomelkülönítéshez

A VRF-példányok minden switchen elkülönített útválasztási tartományokat hoznak létre – mintha több láthatatlan switch osztozna ugyanazon a hardveren. A különböző forgalomtípusok – a felügyeleti, a számítási-/fürtforgalom és a bérlői munkaterhelések forgalma – külön VRF-ekbe kerülnek, hogy az egyik tartományban előforduló útválasztási hiba ne legyen hatással a többire.

Note

Az elkülönítési követelményektől függően minden fürt a saját VRF-jében helyezhető el. Ez további hardverek nélkül teszi lehetővé a több-bérlős működést.

Számítási csomópont és szolgáltatási csomópont

Nem minden levélkapcsolónak ugyanaz a szerepe. A háló kétféle levélkapcsolóval rendelkezik, amelyek különböző felelősségi körökkel bírnak:

Funkció	Számítási levél	Szolgáltatási levél
Virtuális bővíthető LAN (VXLAN) leállítása helyi kiszolgálók esetén	Yes	Yes
Anycast átjáró munkaterhelés VLAN-jaihoz	Yes	Yes
Gerinchálózat kapcsolatok	Yes	Yes
Adatközponti magkapcsolat (külső BGP)	No	Igen
Útvonalszivárgás a VRF-k között	No	Igen
Tűzfal/ terheléselosztó melléklet	No	Igen

Számítási levélkapcsolók

A számítási levélkapcsolók a gazdagép élei. Leállítja a virtuális bővíthető LAN-t (VXLAN) a helyileg csatlakoztatott kiszolgálókhoz, biztosítják a fürt számítási feladatátirányítási és -továbbítási (VRF) példányainak bármilyen küldési átjáróját, és részt vesznek a hálóalrétegben. Nem csatlakoznak az adatközpont magjához, és nem végeznek útvonal szivárogtatást a külső hálózatok felé.

Szolgáltatáslevél kapcsolók

A szolgáltatási leveles csomópár a klaszterhálózat és az adatközpont gerinchálózata közötti dedikált határ. Mivel a szolgáltatási levélpár több virtuális útválasztás és továbbítás (VRF) esetében is részt vesz, ez a természetes integrációs pont a következők számára:

• Útvonalszivárgás – a VRF-k közötti útvonalak ellenőrzött importálása az észak-déli forgalom számára.
• Tűzfalak és terheléselosztók – közvetlenül a szolgáltatás levélportjaihoz csatlakoznak szervizberendezésként.
• VXLAN-végződtetés – az overlay forgalom kapszulázása és dekapszulázása a külső kapcsolódás biztosításához.

Important

Az adatközpont maghálózata (felsőbb rétegbeli útválasztók, tűzfalak, internet) nem csatlakozik közvetlenül a gerinckapcsolókhoz. Minden külső kapcsolat a szolgáltatási levélpáron van központosítva. Ez a gerinc réteget külső függőségek nélküli, teljes mértékben átviteli rétegként tartja.

A külső kapcsolatok szolgáltatáslapon való központosítása a következő előnyöket nyújtja:

• Gerinc stabilitása – Az alapvető hálózatkarbantartás (tűzfalfrissítések, útválasztó-csere) nem befolyásolja a gerincszövetet.
• Egyszerű módosítások – A gerinckonfiguráció módosítása nélkül adhat hozzá vagy távolíthat el külső kapcsolatokat.
• Csökkentett robbanási sugár – A szolgáltatási levél útválasztása vagy szabályzata helytelen konfigurálása csak a külső kapcsolatot érinti, a belső hálót nem.

SDN-szempontok a szétválasztott üzemeltetési megoldások esetében

A szoftveralapú hálózatkezelés (SDN) támogatása az Azure helyi architektúrájától és üzembehelyezési típusától függően változik. A diszaggregált telepítésekben az SDN logikai hálózatokat (LNET-eket) külső SDN-infrastruktúra támogatja a Microsoft SDN-verem helyett.

Az alábbi táblázat a 2604-es verziójú Azure Local-architektúrák SDN-támogatását foglalja össze:

Helyi Azure-architektúra	Helyi Azure-verzió	Csomópontok száma	SDN által támogatott konfiguráció
Hyperconverged	2604	1–16	Microsoft SDN LNET-ek és NSG-k
Hiperkonvergens hibrid (S2D + SAN csatolás)	2604	1–16	Microsoft SDN LNET-ek és NSG-k
Szétszedve	2604	1–64	A külső SDN LNET-ek támogatottak.

Note

A nem összesített üzemelő példányok esetében az SDN logikai hálózatokat nem a Microsoft SDN hálózati vezérlőn, hanem a külső hálózati hálón (levél-gerinc kapcsolókon) kell konfigurálni. Ennek megfelelően tervezze meg a VXLAN EVPN átfedési tervét a szükséges logikai hálózatok támogatásához.

AKS logikai hálózati útválasztás és VRF-kialakítás

Amikor logikai hálózatokat (LNET-eket) hoz létre az Azure Kubernetes Service (AKS) számára az Azure Local-on, az AKS LNET-nek 3. rétegbeli elérhetőséggel (látóvonallal) kell rendelkeznie a felügyeleti LNET-en futó fürtcsomópontokhoz. Az AKS ezt az elérési utat használja a Kubernetes API-kiszolgálóval és a felügyeleti hálózaton üzemeltetett egyéb infrastruktúra-szolgáltatásokkal való kommunikációhoz. Ha az AKS LNET nem éri el a felügyeleti LNET-et, az AKS üzembe helyezése és üzemeltetése meghiúsul. Ez a követelmény az AKS-hez tartozik– a virtuális gépek (VM) LNET-jei nem igénylik a felügyeleti hálózat elérését.

1. lehetőség: Önálló VRF

Az Azure Local 2604-es verziója esetében az egyik módszer az infrastruktúra LNET-jeinek (felügyelet, számítás) és az AKS LNET-ek egyetlen VRF-ben való elhelyezése a levél-gerinc hálón. Egyetlen VRF biztosítja, hogy minden LNET ugyanazt az útválasztási táblát használja, így a felügyelet és az AKS-hálózatok közötti elérhetőség automatikus – nincs szükség további konfigurációra.

A VXLAN EVPN szimmetrikus IRB-vel az AKS és a felügyeleti LNET-ek közötti alhálózati forgalom ugyanabban a VRF-ben helyileg lesz irányítva a számítási levél (VTEP) szintjén. A csomagok a Compute Leaf → Spine → Compute Leaf (3 ugrás) útvonalon haladnak át. A szerverlevél kapcsolói nem vesznek részt ebben a kelet-nyugati irányú forgalomban, ami optimális késleltetést biztosít, és elkerüli a szűk keresztmetszetet a szolgáltatási levélrétegnél.

2. lehetőség: VRF-k elkülönítése útvonalszivárgással

Ha a környezet külön VRF-eket igényel a különböző számítási feladatokhoz vagy bérlőkhöz – például a szabályozási elkülönítési követelményeknek való megfeleléshez –, a szolgáltatáslevél-kapcsolók útvonalszivárgását kell konfigurálnia, hogy lehetővé tegye a VRF-k közötti szükséges forgalmat. Az AKS LNET-et üzemeltető VRF-nek legalább importálnia kell a felügyeleti LNET-előtagokat, a felügyeleti VRF-nek pedig importálnia kell az AKS LNET-előtagokat. A kiszivárgott útvonalak nélkül a VRF-alapú kommunikáció meghiúsul, és az AKS nem éri el az infrastruktúra-szolgáltatásokat.

Mivel az útvonalszivárgás a szolgáltatási levélkapcsolókon van konfigurálva, a VRF-alapú forgalomnak át kell haladnia a szolgáltatási levélszinten. A csomag útvonala a Compute Leaf → Spine → Service Leaf → Spine → Compute Leaf (5 ugrás) lesz, szemben az egyetlen VRF 3 ugrásos útvonalával. Ez az extra bejárás késést okoz, és a levélkapcsolók potenciális szűk keresztmetszetekké válnak az AKS és a felügyeleti rendszerek közötti kommunikációban.

Important

Az útvonalszivárgás közös elérhetőséget biztosít az egyébként izolált VRF-k között. Csak a menedzsment számára szükséges konkrét előtagokat tegyük elérhetővé az AKS-kommunikáció során. Kerülje az alapértelmezett útvonalak vagy a széles körű összegzések kiszivárgását, mivel ez a művelet aláássa a különálló VRF-k elkülönítési előnyeit.

Azonos állványú forgalom optimalizálása

Az 1. lehetőségben (3 ugrás) és a 2. lehetőségben leírt ugrások (5 ugrás) a legrosszabb esetet jelölik– amikor az AKS számítási feladat és az elérni kívánt felügyeleti csomópont különböző számítási levélkapcsolókon (különböző állványokon) található.

Ha az AKS számítási feladat és a célkezelő csomópont ugyanazon az állványon található (mindkettő ugyanahhoz a számítási kapcsolólevél-párhoz csatlakozik), a kapcsolólevél helyi integrált útválasztást és áthidalást (IRB) hajt végre. A forgalom nem halad át a gerincen , és egyetlen ugrással fejeződik be. Ez egy VXLAN EVPN szimmetrikus IRB tulajdonsága: minden levélkapcsoló egy teljesen működőképes VTEP, amely képes irányítani a forgalmat a helyileg példányosított VRF-ekben lévő bármely alhálózat között.

Az alábbi táblázat összefoglalja az egyes forgatókönyvek ugrásainak tényleges számát:

Scenario	Útválasztási útvonal	Ugrások száma
Ugyanaz az állvány, ugyanaz a VRF	Helyi IRB a számítási levélen	Egy ugrás
Keresztállvány, ugyanaz a VRF (Opció 1)	Compute Leaf → Gerinc → Compute Leaf	Három ugrás
Kereszttartó, különálló VRF-ek (2. lehetőség)	Számítási levél → Gerinc → Szolgáltatási levél → Gerinc → Számítási levél	Öt ugrás

Tip

Ha az AKS-számítási feladatok többsége elsősorban ugyanazon az állványon lévő felügyeleti szolgáltatásokkal kommunikál, a tényleges késés kisebb, mint a többállványos legrosszabb eset. Gondolja át a számítási feladatok elhelyezését és a rekesz-affinitást a VRF-terv teljesítményhatásának kiértékelésekor.

A levél- és gerincszövetre vonatkozó követelmények

Ez a szakasz a közepes (17-32 csomópont) és a nagyméretű (33-64 csomópont) üzembe helyezésekhez szükséges további kapcsolóképességek leírását tartalmazza, amelyek egy levél-gerinc Clos hálózatot használnak Virtuálisan Kiterjeszthető LAN (VXLAN) Ethernet Virtuális Magánhálózat (EVPN) átfedéssel, több-bérlős virtuális útválasztási és továbbítási (VRF) izolációval, valamint szolgáltatásintegrációval tűzfalak vagy terheléselosztók használatával. Ezek a követelmények additívak – az Azure Local kapcsolókra vonatkozó alapvető követelmények továbbra is érvényesek.

Category	Követelmények
Alávetítés	Külső határátjáró protokoll (eBGP) számozatlan (RFC 5549) az IPv6 link-local szállítás használatával az IPv4 hálózati réteg elérhetőségi információihoz (NLRI)
	Loopback-alapú társviszony létesítés (kapcsolónként egy loopback)
	Állványonkénti egyedi autonóm rendszerszám (ASN)
	Equal-Cost Többutas (ECMP): legalább 16 út, ajánlott 64 út
	Kétirányú továbbítás észlelése (BFD) a szubszekundumos BGP-feladatátvételhez
Átfedés	Virtuális bővíthető LAN (VXLAN) (RFC 7348) többprotokollos BGP (MP-BGP) Ethernet Virtuális Magánhálózat (EVPN) (RFC 8365)
	Az EVPN 2. és 5. útvonaltípusának támogatása
	Anycast átjáró VLAN-onként
	Címfeloldási protokoll /Szomszédfelderítés (ARP/ND) letiltása
	Konzisztens VLAN-VNI-leképezés
	Szimmetrikus Integrált Útválasztás és Áthidalás (IRB) VLAN-ok közötti útválasztáshoz egy Virtuális Útválasztási és Továbbítási (VRF) példányon belül
Szegmentálás	VRF-támogatás a 3. rétegbeli VXLAN hálózati azonosítóval (L3VNI)
	Route-target importálása és exportálása szabályozott útvonal-szivárgáshoz
	VRF-tudatos alapértelmezett útválasztás
	Skálázás a számítási kapacitás/fürt, a felügyelet és az egyidejű több bérlői VRF támogatására
Szolgáltatásintegráció (szolgáltatáslevél)	Dedikált szolgáltatási levélpár adatközponti magokhoz és szervizberendezésekhez
	Külső BGP-társviszony-létesítés az adatközpont magjában szolgáltatáslevélen keresztül (nem gerincekkel)
	VRF-útvonal kiszivárgása a szolgáltatás VRF-be vagy abból
	Szolgáltatásláncolás/forgalomirányítás támogatása tűzfalon/terheléselosztón keresztül
Szolgáltatásminőség (QoS)	Portonként legalább négy hardversor
	802.1p szolgáltatási osztály (CoS) besorolása/megjelölése
	Továbbfejlesztett átviteli kijelölés (ETS) (802.1Qaz) sávszélesség-foglalás a Weighted Round-Robin (WRR) módszer használatával
	Data Center Bridging Capability Exchange (DCBX) Type-Length-Value (TLV) hirdetés a Link Layer Discovery Protocol (LLDP) használatával
	A prioritási folyamatvezérlés (PFC) nem kötelező (az iSCSI-hez nem szükséges)
iSCSI-tároló	iSCSI VLAN-támogatás (címkézett 802.1Q) és statikus útválasztási képesség a tárolóforgalom elkülönítéséhez
	Többutas I/O (MPIO) kompatibilis (nincs szükség Link Aggregation Control Protocol (LACP) protokollra az iSCSI-hivatkozásokon)
Magas rendelkezésre állás	Multi-Chassis Link Aggregation (MLAG) / Virtual Port Channel (vPC) kettős otthonú gazdagépekhez
	Border Gateway Protocol (BGP) kíméletes újraindítás / folyamatos útválasztás
	ajánlott In-Service szoftverfrissítés (ISSU)
Scale	MAC-tábla ≥16 000
	ARP/ND ≥8 000
	VNI-méretezés ≥1000
	VRF skála ≥16
	Kombinált IPv4+ EVPN-útvonalak ≥10 000
	Ternary Content-Addressable Memory (TCAM) / Hozzáférés-vezérlési lista (ACL) kapacitása elegendő a QoS-besoroláshoz és a biztonsági ACL-ekhez

Tűzfalkövetelmények

Az Azure Local rendszeres kapcsolatot igényel az Azure-hoz. Ha a szervezet kimenő tűzfala korlátozott, akkor a kimenő végpontokra, valamint a belső szabályokra és portokra vonatkozó tűzfalkövetelményeket kell tartalmaznia. Az Azure Local Core-összetevőkhöz kötelező és ajánlott végpontok tartoznak, amelyek közé tartozik a rendszer létrehozása, a regisztráció és a számlázás, a Microsoft Update és a felhőbeli tanúsító.

Tekintse meg a végpontok teljes listájának tűzfalkövetelményeit . Mindenképpen vegye fel ezeket a szükséges URL-címeket az engedélyezett listára. A szükséges hálózati portokat meg kell nyitni az összes gép között mind a helyszíneken belül, mind a helyszínek között (átfeszített klaszterek esetén).

Az Azure Local connectivity validator of the Environment Checker tool, az üzembe helyezés során alapértelmezés szerint ellenőrzi a kimenő kapcsolat követelményét. Emellett önállóan is futtathatja a Környezetellenőrzés eszközt az üzembe helyezés előtt, alatt vagy után a környezet kimenő kapcsolatának kiértékeléséhez.

Az ajánlott eljárás az, hogy egy adatfájl minden releváns végpontja elérhető a környezet ellenőrző eszközével. Ugyanez a fájl a tűzfaladminisztrátorsal is megosztható a szükséges portok és URL-címek megnyitásához.

További információ: Tűzfalkövetelmények.

Következő lépések

• Válasszon ki egy nem összesített hálózati mintát , amelyet áttekinthet.