Das Netzwerk-Team plant, eine Port-Gruppe auf einen neuen verteilten Switch zu verschieben. Auf dem Papier ist es eine routinemäßige Konfigurationsänderung in vCenter. In der Praxis fragt jemand aus dem Betrieb: „Welche Anwendungen laufen auf dieser Port-Gruppe?“ Der Virtualisierungs-Administrator öffnet die Konsole und beginnt, virtuelle Maschinen durchzugehen. Der Netzwerk-Ingenieur ermittelt, welche Uplinks und Leaf-Switches den Traffic tragen. Die Service- Eigentümer erfahren von der Änderung, wenn etwas nicht mehr reagiert.
Warum das virtuelle Netzwerk normalerweise in der CMDB fehlt
Eine klassische CMDB erfasst Server, Anwendungen und physische Netzwerkgeräte. Das virtuelle Netzwerk liegt dazwischen und ändert sich häufig: Port-Gruppen erscheinen mit neuen Projekten, VLANs werden neu gruppiert, Hosts erhalten neue Uplinks. Manuelle Aufzeichnungen können mit einer solchen Schicht nicht Schritt halten, und automatische Discovery speichert sie oft nur als Attribut einer virtuellen Maschine und nicht als eigenständiges Element mit Beziehungen.
Das Ergebnis ist eine Lücke in der Abhängigkeitskarte. Die Auswirkung einer Änderung wird auf den Servern berechnet, aber nicht auf dem Netzwerk, das sie verbindet. Und Netzwerkänderungen gehören zu denen, die die meisten Dienste auf einmal treffen.
Wie Stilla damit umgeht
In Stilla sind virtuelle Switches und Port-Gruppen eigenständige CMDB-Elemente mit ihren Beziehungen:
- Virtuelle Switches – verteilt und standardmäßig, verknüpft mit den Hosts, die sie verwenden.
- Port-Gruppen und VLANs – welcher Switch sie verwenden, welches VLAN sie tragen und welche virtuellen Maschinen und VMkernel-Adapter mit ihnen verbunden sind.
- Host-Uplinks – welche physischen Netzwerkadapter den Traffic tragen und in welche Leaf-Switches.
Die Abhängigkeitskarte läuft daher ohne Unterbrechung vom Business-Service über die Anwendung und die virtuelle Maschine bis hin zur Port-Gruppe, zum Uplink und zum physischen Switch. Die Auswirkungsberechnung für eine Änderung oder einen Ausfall verwendet denselben Graphen wie alles andere im Produkt – Incidents, Changes, Patch-Pläne und Überwachungssituationen.
Disks gehören zum Server, gemeinsame Disks sind eigenständige Elemente
Wir haben den Speicher auf dieselbe Weise organisiert. Die Disks einer virtuellen Maschine werden im Server-Inventar erfasst, wo sie natürlich hingehören, und während der Discovery werden sie automatisch mit dem Datastore verknüpft, auf dem sie liegen. Nur eine Disk mit einem eigenen Leben ist ein eigenständiges CMDB-Element: eine gemeinsame Disk eines Clusters oder eine RDM-Disk, die direkt vom Array abgebildet wird. Dies verhindert, dass die Karte durch Tausende von Elementen ohne Informationswert wächst, während sie immer noch zeigt, welche Server und Dienste von einem bestimmten Datastore oder LUN abhängen.
Die Datenqualitätsprüfung „Disks und Speicher“ markiert Inkonsistenzen – zum Beispiel eine Disk ohne Verbindung zu einem Datastore oder eine gemeinsame Disk, die nur von einem Cluster-Knoten sichtbar ist.
Was dies für den Betrieb bedeutet
Das nächste Mal, wenn das Netzwerk-Team eine Port-Gruppe verschieben möchte, erstellt es eine Änderung und bevor sie zur Genehmigung geht, zeigt Stilla:
- welche virtuellen Maschinen und VMkernel-Adapter von der Port-Gruppe abhängen,
- welche Uplinks und Leaf-Switches den Traffic tragen,
- welche Anwendungen und Business-Services betroffen sind und ob Redundanz sie schützt,
- welche Service-Eigentümer vom Ausfall betroffen sind und wann ihre Wartungsfenster sind.
Service-Eigentümer genehmigen den Ausfall mit der konkreten Auswirkung in der Hand, nicht mit einer generischen „Netzwerk-Wartung“-Benachrichtigung. Und wenn nach der Änderung etwas schiefgeht, werden Überwachungssituationen mit der Änderung abgeglichen, die sie wahrscheinlich verursacht hat, dank derselben Topologie.
Wie man die Daten in die CMDB bekommt
Das virtuelle Netzwerk kann über die Discovery-API in Stilla geladen werden – einschließlich der Übereinstimmung mit vorhandenen Elementen, der vollständigen Synchronisierung und der Stilllegung dessen, was nicht mehr in vCenter existiert – oder durch Import von CSV- und Excel-Dateien. Ein Connector, der die Daten automatisch aus vCenter sammelt, ist in Vorbereitung.
Eine Karte, die am Server endet, beantwortet nur die halbe Frage. Eine Karte, die bis zum physischen Switch reicht, ermöglicht es Ihnen, Netzwerkänderungen mit einem ruhigen Gefühl zu planen.
Stilla Standard
Für Organisationen, die eine zuverlässige CMDB und verwaltete ITSM-Prozesse wünschen.