NexTool Solutions

Ein Inventar beantwortet die Frage „Was habe ich?“. Eine CMDB beantwortet die Frage „Was fällt mit aus, wenn das hier ausfällt?“. Die Brücke zwischen beiden ist im GLPI nicht der Reiter Verbindungen, wie viele annehmen - es ist die Auswirkungsanalyse, und genau dort bleiben die meisten CMDB-Projekte stecken. Dieser Leitfaden zeigt die vier Beziehungsmechanismen, die GLPI bietet, welcher für welchen Fall passt, und die Abfragen, mit denen wir im Betrieb die blinde CMDB aufspüren.

Inventar vs. CMDB: der Unterschied, der die Reaktion auf Störungen verändert

Inventar ist Stammdatenpflege: Marke, Modell, Seriennummer, Garantie, Verantwortlicher. Es ist Anlagenverwaltung, und hier fangen alle an - mit dem automatischen Inventar des GLPI Agent erfassen Sie Hunderte von Assets in wenigen Tagen. Die CMDB kommt danach: die Beziehungsebene, die mitten in einer Störung die entscheidende Frage beantwortet - wenn dieser Switch ausfällt, welche Server, Dienste und Anwender stehen dann ebenfalls still?

Der häufige strategische Fehler: die CMDB als „detaillierteres Inventar“ zu behandeln und für alles Beziehungen pflegen zu wollen. Das skaliert nicht, und niemand hält es aktuell. Eine gute CMDB ist schlank: nur die kritischen CIs und die Abhängigkeiten, die Sie tatsächlich in einer Auswirkungsanalyse verwenden würden.

Die vier Beziehungsmechanismen im GLPI

GLPI hat kein einzelnes „Beziehungsfeld“ - es hat vier verschiedene Mechanismen, jeder in seiner eigenen Tabelle, und die Wahl des falschen ist die Wurzel der meisten CMDBs, die nicht funktionieren. Im Betrieb ist der Irrtum Nummer 1, alles im Reiter Verbindungen aufzubauen in der Annahme, das sei die CMDB, und später festzustellen, dass die Auswirkungsanalyse leer ist.

Verbindungen und Netzwerkports modellieren physische Verknüpfungen. Anwendungen gruppieren die Infrastruktur eines Dienstes. Und die Auswirkungsanalyse - als einzige gerichtet - ist der Abhängigkeitsgraph, der wirklich beantwortet, „was mit ausfällt“. Alle vier existieren nebeneinander; die Verwirrung entsteht, wenn man erwartet, dass einer die Arbeit eines anderen übernimmt.

Modellieren Sie den Dienst als CI: Anwendungen (Appliances)

Der Schritt, der in den meisten Inventaren fehlt, ist, dem Dienst eine Existenz zu geben. „E-Mail“, „ERP“, „Kundenportal“ sind keine Hardware - es sind Dienste, die auf Hardware laufen. Im GLPI ist das richtige Objekt dafür die Anwendung (Appliances, Menü Assets), verfügbar seit GLPI 9.5. Eine Anwendung ist ein logisches CI, mit dem Sie die Elemente verknüpfen, die sie tragen:

1. Legen Sie die Anwendung an (z. B. „E-Mail-Dienst“).
2. Verknüpfen Sie auf dem Reiter der zugeordneten Elemente die unterstützenden CIs: den Server, den Core-Switch, den Storage, die Internetanbindung. Das wird in glpi_appliances_items gespeichert.
3. Erfassen Sie den technisch Verantwortlichen, den Supportvertrag und den Lieferanten direkt in der Anwendung.

Ab dann existiert der Dienst als abfragbares Objekt: Sie öffnen „E-Mail-Dienst“ und sehen die Liste der tragenden Infrastruktur, ohne vom Gedächtnis einzelner Personen abhängig zu sein.

Die echte CMDB: die Auswirkungsanalyse

Infrastruktur in einer Anwendung zu gruppieren, sagt, wer was trägt, berechnet aber nicht den Auswirkungsradius eines Ausfalls. Das ist Aufgabe des Reiters Auswirkungsanalyse (vorhanden seit GLPI 9.4), der einen gerichteten Abhängigkeitsgraphen zeichnet und in glpi_impactrelations gespeichert wird. Jede Kante hat Quelle und Ziel: itemtype_source, items_id_source wirkt sich aus auf itemtype_impacted, items_id_impacted.

Die Richtung ist das Detail, das Kenner von denen unterscheidet, die nur Kästchen verschoben haben. Eine Kante vom Switch zum Server bedeutet „der Switch wirkt sich auf den Server aus“. Fällt der Switch aus, folgen Sie den Pfeilen vorwärts und sehen alles, was mit ausfällt. Der häufige Fehler ist, den Pfeil umgekehrt zu zeichnen - den Server als Ursache für Auswirkungen auf den Switch zu verknüpfen -, und dann bleibt die Auswirkungsanalyse des ausgefallenen Switches leer, ausgerechnet wenn Sie sie am dringendsten brauchen. Modellieren Sie immer in Richtung des Abhängigkeitsflusses: von der Basisinfrastruktur zum Dienst an der Spitze.

Ein Hinweis aus der Praxis: Der Graph wird im Browser gerendert und wird bei Hunderten von Knoten langsam. Versuchen Sie nicht, den gesamten Bestand abzubilden. Nutzen Sie die geschäftliche Kritikalität (Dropdown Kritikalität, unter Einrichtung > Dropdowns), um die kritischen CIs zu kennzeichnen, und nehmen Sie nur diese in den Graphen auf. Eine überladene CMDB ist eine aufgegebene CMDB.

Diagnose-SQL: die blinde CMDB aufspüren

Zu Beginn eines Betriebsvertrags führen wir, noch bevor wir über Prozesse sprechen, eine Abdeckungsprüfung durch: Welche kritischen CIs sind im Inventar, aber in keiner Auswirkungsbeziehung? Das sind die Stellen, an denen die Auswirkungsanalyse lügt und „nichts betroffen“ meldet, obwohl in Wahrheit niemand modelliert hat. Die Abfrage listet die Computer ohne jede Kante - weder als Quelle noch als Ziel:

-- Computadores sem NENHUMA relacao de impacto:
-- existem no inventario, mas sao invisiveis para a analise de impacto.
SELECT c.id, c.name
FROM glpi_computers c
LEFT JOIN glpi_impactrelations r
       ON (r.itemtype_source   = 'Computer' AND r.items_id_source   = c.id)
       OR (r.itemtype_impacted = 'Computer' AND r.items_id_impacted = c.id)
WHERE c.is_deleted = 0
  AND r.id IS NULL
ORDER BY c.name;

Und die Gegenseite: Welche CIs gruppiert ein als Anwendung modellierter Dienst? Nützlich, um zu prüfen, ob der „E-Mail-Dienst“ wirklich auf den richtigen Server und Switch zeigt, bevor Sie sich in einer nächtlichen Störung darauf verlassen:

-- Itens que sustentam um Aplicativo (servico) especifico:
SELECT ai.itemtype, ai.items_id
FROM glpi_appliances_items ai
INNER JOIN glpi_appliances a ON a.id = ai.appliances_id
WHERE a.name = 'Servico de E-mail';

Wir führen diese beiden Abfragen direkt auf der Datenbank aus (über einen schreibgeschützten SQL-Client), nie per LIKE in der Oberfläche, weil wir die genaue Zahl verwaister Elemente brauchen, um den Modellierungsaufwand abzuschätzen.

Automatische Erkennung baut die CMDB nicht für Sie

Es lohnt sich, eine Erwartung auszuräumen, die in jedem Projekt auftaucht: Das Netzwerkinventar per SNMP erkennt die physischen Verbindungen - wenn der GLPI Agent die Switches per SNMP abfragt und LLDP/CDP aktiv ist, werden die Netzwerkports zwischen Switch und Host automatisch in glpi_networkports_networkports befüllt. Das ist hervorragend, und Sie sollten es nicht von Hand machen. Die logische Abhängigkeit eines Dienstes - „die E-Mail hängt von diesem Server ab“ - erkennt jedoch kein Protokoll. Der Agent weiß nicht, dass jener Exchange-Prozess Ihr kritischer E-Mail-Dienst ist. Diese Ebene ist immer eine menschliche Entscheidung, und genau sie macht aus einem Inventar eine CMDB.

Halten Sie den Graphen aktuell, sonst lügt er

Eine veraltete CMDB ist schlimmer als keine CMDB: Sie erzeugt falsches Vertrauen. Sie tauschen einen Switch, vergessen, die Beziehung zu aktualisieren, und beim nächsten Ausfall zeigt die Auswirkungsanalyse auf ein Gerät, das gar nicht mehr existiert. Koppeln Sie die Pflege des Graphen an den Change-Management-Prozess - jede Änderung an einem kritischen CI muss vor dem Abschluss ihre Auswirkungsbeziehungen überprüfen. Ohne diese Disziplin veraltet der Graph innerhalb von Wochen. Es ist dasselbe Prinzip wie bei der Wissensdatenbank: Beziehungen, die niemand pflegt, werden zu Rauschen.

Sie brauchen im GLPI eine CMDB, die eine echte Auswirkungsanalyse trägt, mit einem Graphen, der auf den richtigen CIs modelliert und zusammen mit den Änderungen gepflegt wird? Lernen Sie den GLPI-Betrieb von NexTool kennen.

Geprüft vom Team der NexTool Solutions.