Die unbequeme Realität
Eine bekannte Szene in Unternehmensrechenzentren: Jemand öffnet NetBox in einem Meeting zur Kapazitätsplanung, um den freien Rack-Platz zu zeigen. Die Zahlen sehen gut aus, reichlich Platz für das neue Deployment. Dann erwähnt jemand aus dem Betrieb, dass die Server, die letzten Monat eingebaut wurden, nie erfasst worden sind.
Das ist ein Architekturproblem, kein Prozessproblem.
Manuelle IPAM/DCIM-Updates skalieren nicht, und das war nie anders. Sobald Sie sich darauf verlassen, dass Menschen das Inventar nach jeder Änderung nachtragen, haben Sie akzeptiert, dass Ihre Informationsquelle innerhalb von Wochen von der Realität abweicht. Manchmal innerhalb von Tagen.
In regulierten Branchen ist diese Abweichung ein Compliance-Risiko und nicht bloß ein Ärgernis. Auditoren akzeptieren „wir gehen davon aus, dass das stimmt" nicht als Dokumentation.
Was tatsächlich funktioniert
Bessere Verfahren lösen es nicht, disziplinierteres Personal auch nicht. Der Ausweg besteht darin, zu akzeptieren, dass Infrastrukturkomponenten ihren eigenen Zustand längst kennen, und Pipelines zu bauen, die ihn automatisch einsammeln.
Ihre Switches wissen, welche MAC-Adressen an welchen Ports hängen. VMware vSphere kennt jede VM, ihre Ressourcenzuweisung und den Host, auf dem sie läuft. Proxmox führt sein eigenes Inventar in Echtzeit. Die Daten sind schon da. Sie fließen nur nicht dorthin, wo Sie sie brauchen.
Die Architektur ist einfach genug:
Quellsysteme (Switches, Hypervisoren, Hardware) → Extraktionsschicht → Transformation und Validierung → Zielsysteme (Source of Truth, DCIM)
Das Konzept ist der leichte Teil. Die Arbeit steckt in den Details: Konflikte behandeln, historische Daten verwalten, das Ganze idempotent halten und Audit-Trails aufbauen, die Compliance-Anforderungen standhalten.
Ein praktischer Umsetzungsweg
Wo die Daten liegen
Verschiedene Komponenten geben ihre Daten unterschiedlich heraus.
Netzwerk-Switches (Juniper, Cisco, Arista) liefern LLDP/CDP-Nachbarschaftsinformationen, MAC-Adresstabellen und Interface-Statistiken über NETCONF, REST-APIs oder SSH/NAPALM. Damit wissen Sie, was physisch wo angeschlossen ist.
VMware vSphere stellt sein komplettes Inventar über pyVmomi oder die REST-API bereit: VMs, Hosts, Cluster, Datastores und die Beziehungen dazwischen.
Proxmox hat eine saubere REST-API für VM- und Container-Inventar, inklusive Ressourcenzuweisung und Node-Platzierung.
Hardware-Management-Interfaces (iLO, iDRAC, IPMI) liefern Seriennummern, Modellinformationen und Health-Status direkt vom Blech.
Prefect für die Orchestrierung
Cron-Jobs und selbstgebaute Scheduler nutze ich dafür nicht mehr. Prefect gibt Infrastruktur-Pipelines, was sie wirklich brauchen: Abhängigkeiten zwischen Tasks, automatische Retries mit Backoff, brauchbares Logging und eine UI, in der man sieht, was passiert ist.
Ein typischer Flow hat sechs Stufen:
- Extract: den aktuellen Zustand aus jedem Quellsystem abholen
- Transform: in ein gemeinsames Schema normalisieren, Namenskonventionen auflösen
- Validate: auf Konflikte, unmögliche Zustände und Datenqualitätsprobleme prüfen
- Diff: gegen den aktuellen IPAM/DCIM-Zustand vergleichen und finden, was sich geändert hat
- Apply: die Zielsysteme aktualisieren, mit vollständigem Audit-Log
- Verify: bestätigen, dass die Änderungen angekommen sind
Niemals blind überschreiben. Der Diff-Schritt fängt die Fälle ab, in denen automatisch erhobene Daten einem manuellen Eintrag widersprechen, der einen geplanten künftigen Zustand oder ein bewusstes Override abbildet.
Konfliktlösung ist der schwierige Teil
Was passiert, wenn die Pipeline einen Server in Rack A findet und NetBox Rack B sagt?
Hier zählt die Business-Logik mehr als der Code, und es gibt vier vernünftige Optionen. Der Quelle vertrauen, also gewinnen die automatisch erhobenen Daten und der manuelle Eintrag wird korrigiert. Dem Ziel vertrauen, also wird nichts überschrieben und ein Mensch schaut darüber. Nach Zeitstempel gehen und das jüngste Update gewinnen lassen. Oder Ihre Quellen nach Konfidenz bewerten und entsprechend gewichten.
In der Praxis nutze ich eine Mischform. Quellen mit hoher Konfidenz wie Switch-Port-Mappings und Hypervisor-Inventar überschreiben automatisch. Daten mit geringerer Konfidenz wie IP-Zuweisungen und Custom Fields werden zur Prüfung markiert.
Audit-Trails
Jeder Pipeline-Lauf erzeugt Vorher-Nachher-Snapshots, eine Änderungszuordnung, die zeigt, welche Quelle welches Update ausgelöst hat, Zeitstempel passend zum Meldezeitpunkt des Quellsystems und ein Rollback für den gesamten Batch.
Dieser Nachweis verändert, was Sie sagen können, wenn jemand fragt, woher Sie wissen, dass ein Rack-Diagramm stimmt. Die Dokumentation wird planmäßig gegen Live-Daten der Switches abgeglichen, und das Audit-Log zeigt es.
Technologieentscheidungen, die zählen
Python ist weiterhin die praktische Wahl für Infrastruktur-Automatisierung. Es gibt Bibliotheken für jedes Quellsystem, Betriebsteams können den Code lesen, und es funktioniert mit Ansible ebenso wie allein.
Als Zwischenspeicher PostgreSQL oder DuckDB, je nach Größenordnung. DuckDB ist sehr gut, wenn Sie schwere Transformationen fahren, bevor Sie ins Ziel-IPAM/DCIM schreiben.
NetBox ist der De-facto-Standard für IPAM/DCIM. Es hat eine vollständige REST-API, GraphQL-Support und ein Datenmodell, das für netzwerkzentrierte Infrastruktur sichtbar durchdacht wurde.
Nautobot ist die Alternative, die man kennen sollte. Es wurde 2021 von NetBox geforkt und hat sich in Richtung Automatisierungsausführung bewegt: ein Jobs-Framework, ein App-Ökosystem und GraphQL von Anfang an eingebaut statt später ergänzt. Wenn Ihre Source of Truth auch die Automatisierung ausführen soll, ändert das die Rechnung. Wenn Sie vor allem saubere Dokumentation mit der größten Community dahinter wollen, ist NetBox die sicherere Wahl.
dcTrack ist stark im physischen Rechenzentrumsbetrieb: Rack-Elevations, Stromketten, Kapazitätsplanung. Eine Netzwerk-Source-of-Truth (NetBox oder Nautobot) plus dcTrack für Physik und Strom deckt die meisten Anforderungen im Unternehmensumfeld ab.
Wie das in der Praxis aussieht
Organisationen, die das umsetzen, landen typischerweise bei Dokumentation, die aktuell bleibt, weil die Drift von der Pipeline gefunden wird und nicht während eines Incidents. Die manuelle Abstimmung entfällt weitgehend, und die Zeit, die in das Gegenprüfen von Systemen ging, fließt zurück in Engineering-Arbeit. Audits werden leichter, weil die Pipeline ein vollständiges Änderungsprotokoll führt. Und die Incident Response wird schneller: „Was hängt an diesem Switch-Port?" ist dann eine Abfrage und keine Ermittlung.
Der Einstieg
Wenn Sie schon wissen, dass die Genauigkeit Ihres IPAM/DCIM ein Problem ist, fangen Sie klein an. Nehmen Sie eine Quelle; Netzwerk-Switches sind meist die Stelle mit dem höchsten Nutzen. Bauen Sie die Extraktion und bringen Sie Daten in einen Staging-Bereich. Validieren Sie manuell und prüfen Sie Stichproben gegen die physische Realität. Dann setzen Sie den Sync um, zunächst als reines Reporting, bevor Sie Schreibzugriffe freigeben. Weitere Quellen kommen einzeln dazu.
Tag eins muss nicht perfekt sein. Wichtig ist, die Pipeline-Architektur zu etablieren, denn sie ist es, die kontinuierliche Verbesserung möglich macht.