Gyakorlati OOB hálózati tervezés adatközpontokhoz: Miért verhetetlen gyakran az egyszerű architektúra a komplex overlay szövetekkel szemben?

A modern adatközponti környezetekben az infrastruktúra megbízhatósága fontosabb, mint a hálózati funkciók összetettsége. Ahogy a vállalatok a felhőalapú platformok, az automatizált infrastruktúra-kezelés és az elosztott alkalmazásarchitektúrák felé térnek át, a sávon kívüli (OOB) hálózatok a működési rugalmasság kritikus elemévé váltak. Az OOB hálózat elsődleges célja egyszerű: független felügyeleti hozzáférést biztosítani az éles hálózati hibák esetén. Amikor az OOB hálózatok meghibásodnak, az infrastrukturális csapatok elveszítik a kritikus rendszerek távoli helyreállításának lehetőségét, így a logikai kiesések fizikai adatközponti incidensekké válnak.

Tartalomjegyzék

• 1. rész: Miért kell a sávon kívüli hálózatoknak valóban sávon kívülieknek maradniuk?
• 2. rész: A két legnagyobb OOB tervezési hiba
• 3. rész: A gyakorlati OOB hálózattervezés alapelvei
• 4. rész: OOB szövet topológia tervezése
• 5. rész: Szerverkezelő hálózatok
• 6. rész: Biztonsági és vészhelyzeti hozzáférés-tervezés
• 7. rész: Adatközpont-infrastruktúra beszerzési stratégiája
• FAQ

1. rész: Miért kell a sávon kívüli hálózatoknak valóban sávon kívülieknek maradniuk?

Az OOB hálózatok katasztrófa utáni helyreállítási kommunikációs csatornákként működnek az infrastruktúra-menedzsment számára. Általában a következőkre használják őket:

• Kapcsoló és router menedzsment
• Szerver firmware helyreállítás
• Konzolhozzáférési hibaelhárítás
• Infrastruktúra felügyelet

Ha a helyszíni kapcsolat az éles hálózat elérhetőségétől függ, a teljes helyreállítási stratégia megbízhatatlanná válik. A valódi helyszíni hálózattervezés megköveteli:

• Fizikai hálózati izoláció
• Független útvonalak
• Dedikált biztonsági hozzáférési szabályzatok

Sok vállalati csapat túl későn jön rá, hogy a rosszul megtervezett felügyeleti hálózatok jelentősen növelhetik a leállás utáni helyreállítás költségeit.

2. rész: A két legnagyobb OOB tervezési hiba

Sávon belüli kezelési kockázatok

Egyes szervezetek úgy próbálják csökkenteni a költségeket, hogy éles infrastruktúrát használnak a felügyeleti forgalom VLAN-on vagy VRF szegmentáláson keresztüli továbbítására. A logikai elkülönítés azonban nem elegendő.

Ha az éles infrastruktúra útvonalhibákat, áthidaló fahurkokat vagy hardverhibákat tapasztal, a felügyeleti hozzáférés teljesen megszűnhet.

Ezáltal az egyszerű távoli karbantartási feladatokból sürgős helyszíni látogatások válhatnak.

OOB hálózatok túltervezése VXLAN-nal

A sávon belüli kezeléssel járó kockázatok elkerülése érdekében egyes csapatok túlkompenzálnak azzal, hogy OOB hálózatokat építenek fejlett overlay szövetek, például VXLAN és EVPN használatával.

Bár ezek a technológiák hatékonyak termelési környezetekben, szükségtelen bonyolultságot okoznak a felügyeleti hálózatokban.

Az OOB hálózatoknak inkább infrastruktúra-biztonsági rendszerekként, mint nagy teljesítményű adatátviteli rendszerekként kell működniük.

3. rész: A gyakorlati OOB hálózattervezés alapelvei

A felhőplatform-mérnökök és az MSP-csapatok számára az üzemen kívüli tervezés prioritásai egyértelműek: a helyreállíthatóságnak és a működési egyszerűségnek felül kell múlnia a jövőbeli high-tech bővítést.

1. Valódi fizikai elszigeteltség
2. Egyszerű hálózati tervezés
3. Biztonságos független hozzáférés

Példa CLI parancs a szoftververzió ellenőrzésére:

switch# show version

4. rész: OOB szövet topológia tervezése

Az ajánlott hardverplatformok közé tartoznak a vállalati hálózati kapcsolók.

Példák vállalati platformokra:

• Cisco hivatalos weboldala
• Cisco Catalyst kapcsolósorozat

A globális vállalatok gyakran előnyben részesítik a megbízható adatközponti hálózati hardverek beszerzését megbízható infrastruktúra-beszállítóktól, akik szállításra kész készletet tartanak fenn. A vállalati hardverbeszerzéssel kapcsolatos információkat itt tekintheti meg: Router-Switch vállalati hálózati hardverleltár

5. rész: Szerverkezelő hálózatok

Az elterjedt szerverfelügyeleti technológiák közé tartoznak a hardveres BMC felügyeleti interfészek.

• Hewlett Packard Enterprise iLO menedzsment rendszerek
• Dell DRAC interfészek
• IPMI szabványok

Az ajánlott gyakorlatok közé tartoznak a dedikált felügyeleti alhálózatok és a szigorú hozzáférés-vezérlési szabályzatok.

6. rész: Biztonsági és vészhelyzeti hozzáférés-tervezés

Az ajánlott biztonsági mechanizmusok a következők:

• Nulla megbízhatóságú hitelesítési modellek
• Többfaktoros hitelesítés
• Munkamenet-naplózás

Sok vállalat LTE-alapú biztonsági konzol-kapcsolatot és vészhelyzeti üvegtöréses VPN-hozzáférést is alkalmaz.

7. rész: Adatközpont-infrastruktúra beszerzési stratégiája

Az infrastruktúra beszerzésének megbízhatósága ugyanolyan fontos, mint a hálózattervezés.

A vállalati csapatok gyakran használnak ár-összehasonlító platformokat: IT-Price hálózati hardver árképzési eszköz

A globális IT-csapatok gyakran olyan beszerzési partnerekre támaszkodnak, akik gyors logisztikát és nagyvállalati hardverkészleteket biztosítanak.

FAQ

1. kérdés: Miért kellene az OOB-hálózatoknak egyszerűnek maradniuk?

Mivel a komplexitás növeli a meghibásodási tartományokat és a helyreállítás nehézségét katasztrófa esetén.

2. kérdés: Érdemes VXLAN-t használni OOB hálózatokhoz?

Általában nem. Az OOB hálózatok a megbízhatóságot és a determinisztikus viselkedést helyezik előtérbe a fejlett hálózati funkciókkal szemben.

3. kérdés: Melyik hardver a legjobb az OOB-kapcsoláshoz?

A vállalati szintű 1G/10G switchek hosszú életciklusú gyártói támogatással általában elegendőek.

4. kérdés: Integrálni kell a BMC menedzsmentet a hálózati OOB-ba?

Ez a biztonsági szabályzatoktól függ, de a szigorú szegmentálás ajánlott.