Virtuální síť v CMDB: od port group po leaf přepínač

Síťový tým plánuje přesun port group na nový distribuovaný switch. Na papíře jde o rutinní úpravu konfigurace ve vCenter. V praxi se ale zeptá někdo z provozu: „Které aplikace na té port group běží?“ Správce virtualizace otevře konzoli a začne procházet virtuální stroje. Síťař zjišťuje, přes které uplinky a leaf přepínače vede provoz. Vlastníci služeb se o změně dozvědí, až když jim něco přestane odpovídat.

Proč virtuální síť v CMDB obvykle chybí

Klasická CMDB eviduje servery, aplikace a fyzické síťové prvky. Virtuální síť stojí mezi nimi a mění se často: port groupy vznikají s novými projekty, VLAN se přeskupují, hostitelé dostávají nové uplinky. Ruční evidence takové vrstvy nevydrží a automatická discovery ji často ukládá jen jako atribut virtuálního stroje, ne jako samostatnou položku s vazbami.

Výsledkem je mezera v mapě závislostí. Dopad změny se spočítá na serverech, ale ne na síti, která je spojuje. A právě síťové změny patří k těm, které zasáhnou nejvíc služeb najednou.

Jak to řeší Stilla

Ve Stille jsou virtuální switche a port groupy samostatné položky CMDB se svými vazbami:

• Virtuální switche – distribuované i standardní, s vazbou na hostitele, kteří je používají.
• Port groupy a VLAN – na kterém switchi jsou, jakou VLAN nesou a které virtuální stroje a VMkernel adaptéry jsou k nim připojené.
• Uplinky hostitelů – přes které fyzické síťové karty a do kterých leaf přepínačů vede provoz.

Mapa závislostí tak vede bez přerušení od business služby přes aplikaci a virtuální stroj až po port group, uplink a fyzický přepínač. Výpočet dopadu změny nebo výpadku používá stejný graf jako všechno ostatní v produktu – incident, změna, plán patchování i situace z monitoringu.

Disky patří k serveru, sdílené disky jsou samostatné položky

Podobně jsme uspořádali úložiště. Disky virtuálního stroje evidujeme v inventáři serveru, kam přirozeně patří, a při discovery je automaticky propojíme s datastorem, na kterém leží. Samostatnou položkou CMDB je jen disk, který má vlastní život: sdílený disk clusteru nebo RDM disk namapovaný přímo z pole. Díky tomu mapa neroste o tisíce položek bez informační hodnoty a přitom ukazuje, které servery a služby závisí na konkrétním datastoru nebo LUNu.

Kontrola kvality dat „Disky a úložiště“ upozorní na nesoulad – například disk bez vazby na datastore nebo sdílený disk, který vidí jen jeden uzel clusteru.

Co to znamená pro provoz

Když síťový tým příště plánuje přesun port group, založí změnu a Stilla ještě před odesláním ke schválení ukáže:

• které virtuální stroje a VMkernel adaptéry na port group visí,
• přes které uplinky a leaf přepínače vede provoz,
• které aplikace a business služby budou zasažené a zda je chrání redundance,
• kterých vlastníků služeb se odstávka týká a kdy mají servisní okno.

Vlastníci služeb schvalují odstávku s konkrétním dopadem v ruce, ne s obecným oznámením „údržba sítě“. A když se po změně něco pokazí, situace z monitoringu se díky stejné topologii přiřadí ke změně, která ji pravděpodobně způsobila.

Jak data do CMDB dostat

Virtuální síť lze do Stilly nahrát přes discovery API – včetně párování na existující položky, úplné synchronizace a vyřazení toho, co už ve vCenter neexistuje – nebo importem z CSV a Excelu. Konektor, který bude data z vCenter sbírat automaticky, připravujeme.

Mapa, která končí u serveru, odpoví jen na polovinu otázky. Mapa, která vede až k fyzickému přepínači, dovolí plánovat změny v síti s klidnou hlavou.