WarEagle 10 Geschrieben 17. März 2008 Melden Teilen Geschrieben 17. März 2008 Hallo Allerseits, Kürzlich hab ich nettes Projekt ausgefaßt, umfassend kann man es globales Netzwerk Inventar bezeichnen. Mir persönlich gefällt der Ansatz der der CMDB sehr gut, nur glaub ich nicht, das unsere Firma schon reif dafür ist drum hab ich zwei Fragen, vielleicht könnt ihr mir da ein paar tipps geben: 1) gibt es ein gutes Discoverytool, das ohne Agents auskommt und gut zu konfigurieren ist? Es geht um > 100 Subnetze, >500 Server >50 WAN-Devices. Clients & LAN Devices sind nicht im Focus 2) Wie kann ich sichergehen, das ich beim Aufbau des Objektmodells nicht an der Idee einer CMDB vorbeiarbeite? Danke schon mal im Voraus, Oli Zitieren Link zu diesem Kommentar
phoenixcp 10 Geschrieben 17. März 2008 Melden Teilen Geschrieben 17. März 2008 gibt es ein gutes Discoverytool, das ohne Agents auskommt und gut zu konfigurieren ist? Es geht um > 100 Subnetze, >500 Server >50 WAN-Devices. Clients & LAN Devices sind nicht im Focus Was verstehst du unter einem Discoverytool? Was genau willst du denn inventarisieren / erfassen? Wie kann ich sichergehen, das ich beim Aufbau des Objektmodells nicht an der Idee einer CMDB vorbeiarbeite? Willst du eher selber was bauen? Hast du dir schon einen Überblick über die am Markt befindlichen Werkzeuge gemacht? Habt ihr evtl. schon sowas in der Art im Einsatz, was man entsprechend erweitern könnte? Habt ihr evtl. schonmal die Einführung einer "richtigen" Lösung für Assetmanagement nachgedacht? Zitieren Link zu diesem Kommentar
pillendreher 10 Geschrieben 17. März 2008 Melden Teilen Geschrieben 17. März 2008 Hallo, wir haben unsere eigene (S)CMDB geschrieben. Dafür haben wir unsere bestehenden Datenbanken angezapft (McAffee Console, Softwareverteilung, HP SIM, usw.). Den Rest bekommen wir mit WMI Abfragen und evtl. noch händischem Nachtragen von Informationen. Gruß Pille Zitieren Link zu diesem Kommentar
WarEagle 10 Geschrieben 17. März 2008 Autor Melden Teilen Geschrieben 17. März 2008 Also mir hats ca. ein Jahr gekostet mal die ganzen Hintergründe zu verstehen, aber ich versuche das ganze auf den Punkt zu bringen: @phoenixcp Also mein Job ist System- & Netzwerkmonitoring, da jeder seine Devices auf eingene Art & Weise verwaltet, würde ich das Wissen über die gesamte Infrastruktur als "lückenhaft" bezeichen ;) Mir gehts beim Discovery Primär um Backend Geräte: Also -Router, -Firewalls, -Coreswitches, -WAN-Optimierer und -zentrale Server (AD, MSX, CMS, DMS, etc.) Als Infos für den Anfang reichen mir IP & DNS. Fein aber nicht notwendig Port-Bezeichnungen, -Verbindungen. Also nichts, was sich nicht über SNMP erfahren ließe (Communities sind "großteils" bekannt). Die Krönung wären noch die Subnetze aus den Routing Tables. (Sollte auch noch mit SNMP klappen). Output sollte so flexibel sein, das die Daten vergleichbar und migrierbar sind (SQL, CSV, TXT) Unsere Firma hat sich schon mit viel Geld eine ITIL und eine Monitoring/SM "Bauchlandung" geleistet, darum kann ich an das Thema nur sehr vorsichtig (= kleine Schritte, große Wirkung) herangehen. Also in diesem Fall selber bauen. Wir haben schon eine Client-AssetMgmt Lösung im Haus, die passiert leider nur auf Agents bzw. deckt nicht alle Anforderungen ab (zB Subnetz-Verwaltung etc). Ich sehe diese Projekt als Vorbereitung für eine "richtige" CMDB. Von mir aus als eine InventrarDB mit Abhängikeiten. Die Größenordnungen in denen sich CMDB-Projekte bewegen sind zZ "Out-of-Scope", allerdings will ich mir keinesfalls den Weg richtung CMDB verbauen. @Pillendreher Genau das ist eine weitere Variante. Kein volles Discovery sondern alle vorhanden Quellen anzapfen. Hast Du ein paar Tipps dazu bzw. wie gut es funktioniert hat? Zitieren Link zu diesem Kommentar
WarEagle 10 Geschrieben 25. März 2008 Autor Melden Teilen Geschrieben 25. März 2008 Einmal versuch ich noch das Thema aufzuwerfen ;) Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.