Anton Portas hat in der letzten Episode eine elegante Methode gefunden Daten aus mehreren Excel-Tabellen in i-doit zu importieren und auf diesem Weg die Daten zu konsolidieren. Nun hat er die Daten zwar in i-doit vorliegen, aber was hilft es? Die Aktualität ist unklar. Soll er tatsächlich die Konfiguration jedes einzelnen Objektes manuell überprüfen um alte Fehler zu korrigieren?

Er berät sich mit Max Admin, dem Projektleiter des CMDB-Projekts: Welche Datenquellen können sie noch anzapfen um aktuelle Daten zu erhalten? Alle bisher zur Dokumentation verwendeten Dateien wurden händisch gepflegt. Die Aktualität ist daher abhängig von der Konsequenz der jeweiligen KollegInnen, garantiert ist nichts. Solche ungesicherten Informationen möchten sie nicht als neue Referenz präsentieren.

Sie überlegen jene Systeme zu befragen, die viele Informationen über aktive Geräte im Netzwerk halten. DNS-Server sind diesbezüglich ein Schatz. Ebenso kommt auf die Liste der möglichen Datenquellen der Verzeichnisdienst, in ihrem Fall ein Active Directory (AD). Auch AD-Server sind ein Informationsschatz, das Directory hat die Aufbauorganisation abgebildet, ebenso Lokationen und Mitarbeiterdaten. Dazu kommt, dass die Daten jener Computer, die sich im Netzwerk befinden, vorliegen und mit weiteren Daten verknüpft sind. Doch wie sieht es mit der vermeintlich simplen Anforderung aus Hardware-Daten zu sammeln, zum Beispiel Seriennummern? Und wie sieht es mit der Aktualität der, im AD teilweise manuell gepflegten Daten aus?

Eine kurze Prüfung zeigt, dass es auch hier, wie bereits in den Excel Tabellen, vor veralteten Daten nur so wimmelt. Computer, die es schon lange nicht mehr gibt, Mitarbeiter, die bereits lange aus dem Unternehmen ausgetreten sind, alle sind sie noch hier!

Das Team entscheidet sich mit Netzwerk-Discovery zu experimentieren um einen garantiert aktuellen Status zu erhalten. Sie wollen sozusagen eine saubere Baseline zu definieren.

Discovery

Beim Vorgang des Discovery wird die aktuelle Konfiguration direkt aus den physischen und logischen Netzwerkelementen zur Laufzeit (“jetzt”) abgezogen. Dazu werden Zugriffsrechte zur Firmware bzw. zum Betriebssystem benötigt, um diese Daten auch zuverlässig auslesen zu können. Da jeder Gerätehersteller seine eigene Logik der Datenhaltung innerhalb der Firmware entwickelt hat, ist es nötig, diese Geräte auch unterschiedlich anzusprechen um ihnen ihre Konfiguration zu entlocken. Eine Discovery Software macht genau das.

Je mehr Hersteller- und Geräte-Dialekte sie “spricht”, um so sorgenfreier ist das Leben des Administrators. Die Menge an Details die ein Netzwerk-Scan liefert, sind manuell auch nicht annähernd zu erheben, geschweige denn aktuell zu halten. Die nach dem Netzwerk-Scan einheitlich in einer Datenbank vorliegenden Daten werden anschließend über eine Datenschnittstelle in die CMDB eingespielt, um dort Objekte anzulegen, oder sie zu aktualisieren. Aktueller geht nicht mehr.

Da für i-doit eine JDisc Schnittstelle existiert, ist es naheliegend, dass sich Max und Anton mit diesem Werkzeug auseinander setzen. JDisc basiert auf Windows und bringt eine eigene Datenbank mit, daher ist eine eigene virtuelle Maschine angebracht.

Anton macht sich einen Plan, was er erreichen will:

  • Er möchte jene Objekte, die gerade im Fokus seines Teilprojekts sind, auf den aktuellen Stand bringen. Das ist vorerst Server-Hardware.
  • Er möchte die Objekte, deren Daten überarbeitet wurden, als “heute aktuell” kennzeichnen.
  • Dann möchte er den Kollegen das Ergebnis präsentieren und sich mit ihnen darauf einigen., wer und wie die Daten in der CMDB aktuell gehalten werden.

Den dritten Punkt ersucht er den Projektleiter zu übernehmen. Der kennt sein Team am besten und weiß, wie man so eine Vereinbarung treffen kann.

Beim CSV-Import musste Anton mehr Daten importieren, als ihm lieb war. Nun möchte er sich wieder auf seinen Zuständigkeitsbereich konzentrieren und tatsächlich nur Server-Hardware aktualisieren. Doch beim ersten Durchlauf von JDisc wird ihm klar: Hier werden auch eine Menge Objekte identifiziert, die nichts mit seinem Projektfokus zu tun haben.

Er muss sich also intensiver mit der Konfiguration auseinander setzen um seinen Fokus zu bewahren. Die Möglichkeit der Einschränkung auf IP-Ranges war schnell herausgefunden. Anton legt sich eine Gruppe für das Core-LAN an. Auch hier entdeckt er jede Menge andere, logische, physische, und noch unbekannte Elemente, für die er noch keine Passwörter hinterlegt hatte. Er identifiziert die Möglichkeit, in JDisc dynamische Gruppen zu bilden. Diese werden durch Eingabe von Mustern gebildet. Mit ein wenig Nachdenken und Probieren findet er die passende Zusammenstellung der Hostnamen, um eine Gruppe mit ausschließlich Server-Hardware zu bilden. Hoffentlich haben sich alle Kollegen an die übliche Namensgebung gehalten?

Nun geht Anton an die Konfiguration der Schnittstelle in i-doit und findet mehrere Möglichkeiten, das Verhalten beim Import zu beeinflussen. Er entscheidet, nach welcher Regel neue Objekte angelegt oder bereits bestehende aktualisiert werden.

Ein Hit ist das Umklassifizieren der Objekte. Stimmen mehrere Attribute überein, wird aus dem “Import Objekt” nun die richtige Objektklasse “Server”. Damit fällt ein weiterer manueller Schritt weg.

Der Status des Teilprojektes kann aufgenommen werden:

 

  • Daten aus den bisherigen Dokumentations-Dateien wurden importiert.
  • Es gibt eine “good practice”, wie er Altdaten übernehmen kann.
  • Redundanzen in den bisherigen Dokumentations-Dateien können aufgelöst werden, die Daten werden in i-doit konsolidiert.
  • Die Aktualität der Datensätze wurde nun einmalig sichergestellt.
  • Einem regelmäßigen Update mittels Discovery steht technisch nichts im Wege.

Zu einem späteren Zeitpunkt möchte er mit dem Projektleiter darüber nachdenken, ob das Discovery des Netzwerkes regelmäßig stattfinden soll, oder ob Änderungen manuell durchzuführen sind.

Nun wird es an der Zeit den KollegInnen ein klares Signal geben: Diese Datensätze hat er bearbeitet. Um diese Datensätze kümmert er sich in Zukunft!

Hier stellt Anton fest, dass i-doit bereits alles unter der Haube mitliefert. Jeder Datensatz hat sein Erstellungsdatum und das letzte Aktualisierungsdatum eingebrannt. Im Logbuch ist sogar nachvollziehbar, wann welche Änderung durchgeführt wurde, selbst die Datenquelle wird notiert. Die Anwender können unterscheiden, welche Daten manuell, per CSV-Import oder mittels JDisc-Schnittstelle geändert wurden. Damit er das Änderungsdatum sofort sehen kann, erweitert er die Listenansicht seiner Objekttypen um das Feld Änderungsdatum. Einen weiteren Trick hat er in der Online Demo gefunden: Mit Hilfe einer dynamischen Gruppe sieht er alle geänderten Objekte des aktuellen Tages. Eine große Hilfe, vor allem wenn durch den Importvorgang Objekte umklassifiziert wurden.

Seinen Stempel drückt er den Servern auch noch auf: Mit Hilfe der Massenänderung trägt er in alle Server noch seinen Namen als Administrator ein.

Für heute ist Anton zufrieden!

Conclusio

Auch Discovery benötigt einen Tool-Champion. Dieser kann die Software den eigenen Bedürfnissen sehr genau anpassen. Punktgenaue Ergebnisse können erzielt werden. In dieser Projektphase Zeit zu investieren, hilft später, wenn es eng wird.

Share This