Ein modellbasierender Ansatz, wie ihn die EMC mit der Smarts-Software verfolgt, soll beim Monitoring helfen: Ziel ist eine ganzheitliche Analyse von Speicher- und IP-Netzen, technikübergreifend und plattformunabhängig. Grundlage ist das so genannte Common Information Model, das Komponenten, Verbindungen, Verhaltensweisen und Interaktionen zwischen den verschiedenen Ebenen eines Netzwerks abbildet und die Beziehungen zwischen Netz, Applikationen und Geschäftsprozessen verdeutlichen soll.
Kein Unternehmen kann sich heute mehr Systemstillstände leisten, Datenverluste erst recht nicht. Die Verwaltung von Informationskapital spielt eine immer wichtigere Rolle, denn trotz Datenwachstums und sinkender IT-Budgets müssen Services und Informationen stets verfügbar sein. Fallen IT-Komponenten aus, beeinflusst dies unmittelbar die Geschäftstätigkeit und die Profitabilität des Unternehmens. Um gegen Ausfälle und Verluste gerüstet zu sein, sind eine automatisierte, netzwerkübergreifende Überwachung und Verwaltung der Speicherressourcen notwendig. Mit intelligentem Ressourcenmanagement spannen Unternehmen ein regelrechtes Sicherheitsnetz für den reibungslosen Produktivbetrieb – und zwar sowohl für die LAN-Infrastruktur als auch für den Storage-Bereich. Ursachen für Probleme und deren Auswirkungen werden automatisch in beiden Netzwerken identifiziert, bevor die Infrastruktur Schaden nimmt und wichtige Geschäftsprozesse beeinträchtigt oder sogar lahm gelegt werden.
Heute gängige SAN-, NAS- oder IP-Netzwerke stellen Administratoren abhängig von Komplexität und Umfang vor große Herausforderungen. Versagt auch nur eine Komponente des Netzwerks ihren Dienst, kann sich dies auf alle Teile der IT-Landschaft auswirken. Was jedoch ganz allgemein wie in jedem anderen Arbeitsbereich gilt, ist auch für Netzwerk- und Storage-Administratoren eine Binsenweisheit: Ist die Ursache eines Problems erst einmal identifiziert, ist die Behebung meist nur noch Formsache. In komplexen Infrastrukturen beeinflusst jedoch ein Bauteil viele andere, und so kommt es durch entsprechende Kausalketten häufig vor, dass eine Vielzahl an Komponenten lahmgelegt ist, obwohl vielleicht nur ein Gerät tatsächlich ausgefallen ist.
Es kann sich dabei um ausgefallene Hardware- oder Softwarekomponenten, eine Fehlkonfiguration, eine "Verstopfung" im Netz oder schlicht ein loses Verbindungskabel drehen. Die Auswirkungen einer solchen Störung können jedoch so gravierend sein, dass sie die Geschäftstätigkeit des Unternehmens bedrohen.
Eine Netzwerkinfrastruktur ist durchaus vergleichbar mit einem Patienten, der wegen bestimmter Beschwerden zum Arzt geht: Magen-, Kopf- oder Rückenschmerzen, Schwindelgefühl, Übelkeit oder Hautreizungen. Der Arzt kennt die Organe und Körperfunktionen eines Menschen und deren Zusammenhänge ganz genau und kann auf Basis dieses Wissens die unterschiedlichen Symptomen diagnostizieren und daraus auf eine bestimmte Erkrankung schließen. Liegen unterschiedliche Erkrankungen vor, so priorisiert der Arzt diese zudem nach Bedeutung und Schwere. Eine Schramme am Schienbein ist dabei sicher nicht so gravierend wie eine Lungenentzündung, daher wird der Arzt zuerst um die Lungenentzündung kümmern und sich danach der Schramme widmen. Administratoren müssen – ähnlich wie der Arzt – ebenfalls in der Lage sein, eine Reihe von Symptomen, die ein Netzwerkproblem hervorruft, zu analysieren, auf die eigentliche Ursache einzuschränken und zu priorisieren. Nur so können sie das Problem gezielt angehen und innerhalb kürzester Zeit abstellen, also einen wesentlichen Aspekt ihrer Arbeit berücksichtigen.
Die Schwierigkeit liegt jedoch darin, aus den oft dutzenden oder gar hunderten Fehlermeldungen,
die bei einer Störung auf der Managementkonsole erscheinen, diejenige herauszufiltern, die die
tatsächliche Ursache des Problems anzeigt. Studien zufolge verbringen Administratoren 80 bis 90
Prozent der Ausfallzeit damit, die Flut an Meldungen zu analysieren und die eigentliche Ursache zu
suchen. Wer sich manuell an die Ursachenforschung macht, vergeudet also wertvolle Zeit und
riskiert, dass sich der Fehler negativ auf andere Netzwerkbereiche und schlussendlich auch auf das
Geschäft des Unternehmens auswirkt. Oft ist es zudem schier unmöglich, per Hand die Warnungen aus
Speichernetzen, IP-Netzen und Applikations-Domains überhaupt miteinander in Beziehung zu setzen und
ihre Ursache zu lokalisieren. Komplexe IT-Umgebungen, wie sie speziell bei
Telekommunikationsunternehmen, Finanzinstituten oder Behörden vorkommen, sollten deshalb permanent
automatisch überwacht und auf Fehler analysiert werden.
Unterschiedliche Softwarelösungen, so genannte Event-Manager, verfolgen dabei unterschiedliche
Analyseansätze. Dabei beschränken sich die meisten darauf, den Administratoren schlicht mehr und
mehr Daten über Vorkommnisse im Netz auszugeben. In Zeiten des Informationsüberflusses ist dies
allerdings nicht hilfreich. Zudem führen die Informationen im Normalfall nicht zur Ursache eines
Problems. Anwender solcher Systeme sind daher dazu übergegangen, selbstständig bestimmte Regeln
aufzustellen und zu programmieren, die die mangelnde Intelligenz der Event-Manager ausgleichen
sollen.
In diesen Regeln stellen sie eine Reihe von Symptomen zusammen und folgern daraus bestimmte
Ursachen, um diese dann abzustellen. Dies funktioniert gut, wenn die Infrastruktur nicht allzu groß
ist und sich kaum verändert. Sobald das Netzwerk jedoch wächst oder sich stetig verändert, wie
beispielsweise bei großen Banken oder Telekom-Providern üblich, stößt die regelbasierende
Ursachenforschung schnell an Grenzen, da die Regeln bei einer Veränderung jedes Mal neu geschrieben
oder manuell angepasst werden müssen. Dies bedeutet hohe Kosten und nur geringe Verlässlichkeit und
Genauigkeit.
Abhilfe soll hier ein modellbasierender Ansatz leisten, wie ihn die Smarts-Software verfolgt.
Diese ermöglicht eine ganzheitliche Analyse von Speicher- und IP-Netzen, technikübergreifend und
plattformunabhängig. Grundlage ist das hauseigene so genannte Common Information Model, das alle
Komponenten, Verbindungen, Verhaltensweisen und Interaktionen zwischen den verschiedenen Ebenen
eines Netzwerkes abbildet und die Beziehungen zwischen Netzwerk, Applikationen und
Geschäftsprozessen deutlich macht. In einer Datenbank sind dazu alle heute gängigen
Netzwerkkomponenten und ihre Eigenschaften erfasst. Bestimmten Bausteinen sind bestimmte
Verhaltensweisen, Beziehungen zu anderen Geräten und Services im Netzwerk sowie auch mögliche
Ausfallszenarien zugeordnet. Ähnlich wie der Arzt den menschlichen Körper kennt, "weiß" auch die
Software, wie sich die Komponenten im Netz verhalten, wenn sie "gesund" sind und wenn Störungen
auftreten.
Per Discovery-Funktion wird die vorliegende Netzwerkinfrastruktur erkannt und mit der Datenbank
abgeglichen. Die so entstehende individuelle Netzwerkstruktur ist im patentierten Codebook
abgelegt. Im laufenden Betrieb wiederholt sich dies kontinuierlich. Änderungen in der Topologie
erkennt das System automatisch. Ebenfalls im Codebook erfasst werden Informationen über
möglicherweise auftretende Störungen im Netzwerk. Jedes Problem in der Infrastruktur hat eine
bestimmte Signatur, die sich aus den Symptomen zusammensetzt, die es auslöst – sowohl in der
tatsächlich betroffenen Komponente als auch in den damit verbundenen Netzwerkbausteinen.
Anhand der Signatur lässt sich ein Problem folglich sofort erkennen. Diese Signaturen sind im
Codebuch abgelegt und werden ebenfalls laufend aktualisiert. Auf Grundlage der kontinuierlichen
Analyse der aktuellen Netzdaten in Verbindung mit den in der Datenbank gespeicherten Informationen
erkennt die Software sofort, wenn im Netzwerk bestimmte Störungen auftreten und identifiziert ihre
Ursache. Die Basis dieser auf dem Codebook basierenden Korrelation ist einfach: Tritt im Netzwerk
ein Problem auf, werden dessen Symptome mit den im Codebook gespeicherten Signaturen abgeglichen
und die Ursache so lokalisiert.
Vielbeschäftigten Administratoren wird so eine Reihe von wichtigen Arbeitsschritten abgenommen.
Aus der Vielzahl gemeldeter Symptome eines Netzwerkproblems analysiert Smarts die Ursache heraus
und priorisiert diese anhand ihrer möglichen Auswirkungen auf das Netzwerk oder die
Geschäftsprozesse. So ist beispielsweise denkbar, dass der Defekt einer Host-Bus-Adapter-Karte oder
eines Switch-Ports im SAN-Umfeld den Mail-Server der Marketing-Abteilung lahm zu legen vermag. Dies
hätte unmittelbaren Einfluss auf aktuelle Storage-intensive Kampagnen oder an diesem Tage
anstehende Kunden-Mailings. An anderer Stelle taucht gleichzeitig ein Problem auf, das die
nächtlichen Backup-Vorgänge des Unternehmens beeinflussen würde. Anhand von festgelegten Service
Levels erkennt die Software, welche Störung in diesem Falle die größeren Schäden zur Folge hat und
zuerst behoben werden muss. An dieser Stelle greift wieder der Vergleich mit der ärztlichen
Diagnose – wenn auch auf einer etwas anderen Ebene: Der verantwortliche Administrator kann die
entsprechenden Maßnahmen sofort einleiten und die Behebung der Störung an die entsprechenden Teams
delegieren, ohne dass mehrere Abteilungen gleichzeitig daran arbeiten müssen.