-
Hintergrund der Erfindung
-
Storage
Area Netzwerke sind dedizierte Netzwerke, die es Ermöglichen,
daß mehrere
auf Servern laufende Anwendungen auf Daten zugreifen können, die
in vereinigten, gemeinsam genutzten Speicher-Infrastrukturen gespeichert
sind. Unternehmen entwickeln zunehmend große Storage Area Netzwerke (SANs),
um Skalenvorteile oder Massenproduktionsvorteile (Economies of Scale)
zu erzielen, und planen massive geschäftskritische Migrationsprozesse
zu diesen neuen Umgebungen und führen diese
Prozesse aus.
-
SANs
von Unternehmen unterstützen
zunehmend die meisten geschäftskritischen
Anwendungen der Unternehmen. Diese SANs werden immer größer und
komplexer. Eine typische SAN-Umgebung
in einem Fortune 500-Unternehmen kann ein paar Hundert Server und
mehrere zehn Switches und Speichergeräte verschiedener Typen aufweisen.
Außerdem
werden diese SAN-Umgebungen
in erheblichem Maße
geändert
und erweitert. Gemäß einer jüngsten Gartner-Umfrage
wachsen große
SANs jährlich
um etwa 40% an.
-
Diese
große
Größe und die
Wachstumsrate von SANs führen
dazu, daß die
SANs immer komplexer werden. Die Anzahl von Komponenten und Verbindungen,
die mit der Datenübertragung
von einer vorgegebenen Anwendung zu einer oder mehrerer Dateneinheiten
(LUNs, die in einem oder mehreren gemeinsam verwendeten Speichergeräten verwendet
werden) des SANs in Beziehung stehen können, können mit der Größe des SANs
exponentiell zunehmen.
-
Diese
Komplexität
in Kombination mit der Heterogenität der verschiedenen SAN-Geräte führt zu einem
hohen Risikopo tential und zu einer hohen Ineffizienz. Um Änderungen
des SANs (die aufgrund des natürlichen
Wachstums des SANs häufig
auftreten) vorzunehmen, benötigen
Gruppen von SAN-Managern eine lange Zeit, und die Änderungen
sind fehleranfällig.
Beispielsweise ist in vielen Unternehmen für eine routinemäßige Änderung
(z.B. zum Hinzufügen
eines neuen Servers zu einem SAN) eine Zeitdauer von ein bis zwei
Wochen erforderlich, und in einem hohen Prozentanteil dieses Änderungsprozesses
(manchmal bis zu 30–40%)
tritt während
des Änderungsprozesses
mindestens ein Fehler auf. Schätzungsweise
sind etwa 80% der Betriebsunterbrechungsereignisse in Unternehmen
ein Ergebnis eines mit einer Infrastrukturänderung in Beziehung stehenden
Ereignisses.
-
Einer
der Hauptgründe
für diese
Probleme in SANs ergibt sich durch die Tatsache, daß Anwendungen
und Dateneinheiten (LUNs), d.h. die Endpunkte von SAN-Datenflüssen, eine
relativ strikte exklusive Zugriffsbeziehung haben. D.h., für jede Anwendung auf
einem mit einem SAN verbundenen Host- oder Zentralrechner ist typischerweise
ein Zugriff (häufig ein
exklusiver Zugriff) nur auf einige spezifische SAN-Dateneinheiten (LUNs)
erforderlich. Daher muß in
einem Storage Area Netzwerk jeder Quellenendpunkt (Anwendung auf
einem Host- oder Zentralrechner) typischerweise immer nur (und häufig ausschließlich) mit
einer spezifischen kleinen Anzahl von Ziel-Endpunkten (LUNs auf
Speichergeräten)
wechselwirken.
-
Diese
Zugriffsbeziehung und ihre zugeordnete Zugriffscharakteristik müssen jedoch
tatsächlich durch
Installieren oder Einrichten mehrerer verschiedenartiger zugeordneter
Geräte
realisiert werden. Hierfür
sind verschiedene Arbeitsmaßnahmen
erforderlich, die mehrere physische und logische Basis-Installationsarbeiten
(manchmal mehrere Zehn pro logischer Änderung) beinhalten, die an
verschiedenen Orten und bezüglich
verschiedenen Gerätetypen
mit einer perfekten wechselseitigen Konsistenz ausgeführt werden
müssen.
-
Gegenwärtig existieren
keine geeigneten technologischen Lösungen zum Unterstützen von SAN-Administratoren
bei der Einrichtung der End-to-End-Konsistenz von SAN-Zuständen und Änderungsarbeiten
bezüglich
den Anwendungsdatenanforderungen. Tatsache ist, daß SAN-Administratoren
gegenwärtig
auf manuelle Verfahren, auf auf Arbeitsblättern basierende Information
und auf empirische Methoden zurückgreifen
müssen.
-
Für eine derartige
zu entwickelnde Technologie müssen
erhebliche Probleme gelöst
werden. Diese Probleme stehen unter anderem in Beziehung mit der
exponentiellen Anzahl potentieller Zugriffspfade von Anwendungsservern
zu Datenspeichergeräten, dem
hohen Grad der Heterogenität
zwischen SAN-Geräten, der
verteilten Struktur des erforderlichen konsistenten momentanen Zustands
und der Tatsache, daß verschiedenartige
Ereignisse auftreten können
und jedes Ereignis sich im Prinzip auf eine beliebige Anzahl von
Datenflüssen
von Anwendungen zu Dateneinheiten auswirken kann.
-
Daher
besteht Bedarf für
eine Lösung
des Problems der Validierung des End-to-End-SAN-Zustands und von
SAN-Zustandänderungsereignissen.
-
Kurze Beschreibung der
Erfindung
-
Erfindungsgemäß werden
ein Verfahren und ein System zum Validieren eines logischen Zugriffspfades
in einem Storage Area Netzwerk bereitgestellt. Erfindungsgemäß wird die
Definition einer SAN-Zugriffspfad-Policy unterstützt, die darstellt, welche
logischen Zugriffspfade von einer Anwendung zu einer Daten-LUN nicht
existieren sollten oder existieren sollten und welches die End-to-End-Attribute
jedes dieser Pfade sind. Es wird ein SAN-spezifischer, graph-basierter
Validierungsalgorithmus ausgeführt,
der auf Information basiert, die von den über das SAN verteilten Geräten unter
Verwendung verschiedenartiger nicht-störender oder nichtbetriebsunterbrechender
Mechanismen erfaßt
werden. Erfindungsgemäß können Nichtübereinstimmungen
tatsächlicher
logischer Zugriffspfade bezüglich
der durch die Policy bestimmten Soll-Zugriffspfade identifiziert
werden. Meldungen über
Nichtübereinstimmungen
können
unter Verwendung verschieden artiger Einrichtungen oder Verfahren
zusammen mit relevanter Kontextinformation an einen gewünschten Empfänger übertragen
werden.
-
Gemäß einem
anderen Aspekt der Erfindung wird die Korrektheit und die Auswirkung
eines beliebigen Typs eines SAN-Ereignisses
validiert, das den SAN-Zustand beeinflussen kann. Es wird Information über Ereignisse
erfaßt,
entweder unmittelbar nachdem sie aufgetreten sind, oder in einigen
Fällen
bevor sie auftreten, und ihre Auswirkung auf einen beliebigen logischen
SAN-Zugriffspfad und die Übereinstimmung
mit der logischen Zugriffspfad-Policy wird unter Verwendung SAN-spezifischer,
graph-basierter Algorithmen analysiert. Im Fall identifizierter
Nichtübereinstimmungen
wird Information zusammen mit Kontextinformation übertragen,
wenn das Ereignis bereits aufgetreten ist, oder es wird verhindert,
daß das
Ereignis auftritt, wenn es noch nicht aufgetreten ist.
-
Durch
die vorliegende Erfindung werden verschiedene wichtige Vorteile
erzielt:
- • Erfindungsgemäß werden
alle wichtigen Eigenschaften logischer End-to-End-Zugriffspfade
erfaßt
und es wird dazu beigetragen, sie zu erzwingen.
- • Der
größte Teil
der zugrunde liegenden Komplexität
wird abstrahiert.
- • Erfindungsgemäß können alle
geplanten und nicht geplanten Typen von SAN-Änderungsereignissen gehandhabt
werden.
- • Erfindungsgemäß sind viele
der gegenwärtig
mit SAN-Änderungsprozessen
in Beziehung stehenden Probleme vermeidbar, die sich durch Inkonsistenzfehler
ergeben.
- • Erfindungsgemäß können viele
Probleme erfaßt werden,
unmittelbar nachdem sie aufgetreten sind, und es kann geeigneten
Personen wichtige Kontextinformation über diese Probleme zur Verfügung gestellt
werden, so daß sie
schnell korrigiert werden können.
- • Erfindungsgemäß können der
Zeitaufwand und Ressourcen, die gegenwärtig zum Ausführen von SAN-Änderungen
erforderlich sind, wesentlich reduziert werden.
- • Die
Erfindung kann als Basis für
einen strukturierten, geeignet konstruierten SAN-Änderungs-Lebenszyklusprozeß verwendet
werden.
- • Die
Erfindung kann als Basis für
eine besser kontrollierte, besser genutzte, zuverlässigere
und sicherere SAN-Umgebung dienen.
-
Aus
der Perspektive von Unternehmen hat die vorliegende technologische
Erfindung ein großes Potential
hinsichtlich der Senkung von Betriebskosten, die gegenwärtig in
SAN-Änderungsprozesse
und Problemkorrektur investiert werden, um Betriebsunterbrechungs-
oder Ausfallrisiken aufgrund von SAN-Infrastrukturfehlern und Störungen zu
reduzieren, die gegenwärtig
völlig
normal sind, und um ein weiteres SAN-Wachstum und SAN-Änderungen zu ermöglichen,
um die Anforderungen der Unternehmen zu unterstützen und die wesentlichen ökonomischen
Vorteile zu erzielen, die durch geeignet konstruierte und betreibbare
große
SANs bereitgestellt werden können.
-
Gemäß einem
Aspekt der vorliegenden Erfindung weist ein Verfahren zum Validieren
eines Zustands eines Storage Area Netzwerkes (SAN) das Definieren
einer SAN-Zugriffspfad-Policy
auf, die logische SAN-Zugriffspfade darstellt, wobei die logischen
SAN-Zugriffspfade eine End-to-End-Zugriffsbeziehung zwischen einer
Anwendung auf einem Server und auf Speichergeräten im SAN gespeicherten Daten-LUNs
definieren und logische Zugriffspfadattribute mit Attributwerten
aufweisen. Das Verfahren weist ferner das Erfassen von Konfigurationsinformation
von Geräten
des SAN, das Standardisieren oder Normieren von Formaten der Konfigurationsinformation
und das Beheben jeglicher Konflikte sowie das Verarbeiten der erfaßten Konfigurationsinformation
zum Identifizieren der logischen SAN-Zugriffspfade auf. Durch das
Verfahren werden dann die zugeordneten Attributwerte berechnet,
die identifizierten logischen SAN-Zugriffspfade und die berechneten
Attributwerte mit der SAN-Zugriffspfad-Policy verglichen, um jegliche
Diskrepanzen oder Nichtübereinstimmungen
der logischen Pfade zu identifizieren.
-
Gemäß einem
anderen Aspekt der vorliegenden Erfindung weist ein Verfahren zum
Validieren eines Zustandänderungsereignisses
eines Storage Area Netzwerks (SAN) die Schritte auf: Definieren
einer SAN-Zugriffspfad-Policy, die logische SAN-Zugriffspfade darstellt,
Definieren eines SAN-Zustands basierend auf logischen SAN-Zugriffspfaden
und den logischen Zugriffspfaden zugeordneten Attributwerten, Erzeugen
von SAN-Ereignis-Beschreibungsinformation und Vergleichen der SAN-Ereignis-Beschreibungsinformation
mit dem SAN-Zustand, um Diskrepanzen oder Nichtübereinstimmungen logischer
Pfade zu identifizieren.
-
Gemäß einem
noch anderen Aspekt der vorliegenden Erfindung weist ein Storage
Area Netzwerk- (SAN) Validations-Manager
eine Policy Engine auf, die eine SAN-Zugriffspfad-Policy speichert,
die logische SAN-Zugriffspfade darstellt, wobei die logischen SAN-Zugriffspfade
eine End-to-End-Zugriffsbeziehung
zwischen einer Anwendung auf einem Server und Daten-LUNs definieren,
die auf Speichervorrichtungen im SAN gespeichert sind, und logische Zugriffspfadattribute
mit Attributwerten aufweisen. Der SAN-Validations-Manager weist
ferner eine Validierungsmaschine auf, die Konfigurationsinformation von
Geräten
des SAN erfaßt,
Formate der Konfigurationsinformation standardisiert und jegliche
Konflikte behebt. Die Validierungsmaschine verarbeitet außerdem die
erfaßte
Konfigurationsinformation, um logische SAN-Zugriffspfade zu identifizieren,
und berechnet die zugeordneten Attributwerte und vergleicht die
identifizierten logischen SAN-Zugriffspfade
und die berechneten Attributwerte mit der SAN-Zugriffspfad-Policy, um jegliche Diskrepanzen oder
Nichtübereinstimmungen
logischer Zugriffspfade zu identifizieren.
-
Vorteilhafte
Ausführungsformen
der Erfindung können
eines oder mehrere der folgenden Merkmale aufweisen.
-
Der
SAN-Validierungsprozeß kann
ferner das Identifizieren einer Nichtübereinstimmung eines logischen
Zugriffspfades aufweisen, wenn mindestens ein identifizierter logischer
SAN-Zugriffspfad nicht mit der SAN-Zugriffspfad-Policy übereinstimmt, und
das Definieren einer SAN-Informationsgabe-Policy zum Informieren eines Benutzers über Nichtübereinstimmungen
von SAN-Zugriffspfaden. Das Informieren eines Benutzers kann das Übertragen
einer Nichtübereinstimmungsinformation
enthaltenden Meldung an den Benutzer aufweisen, wobei die Meldung
eine E-Mail-, eine Grafiktext- und/oder eine SNMP-Meldung ist. Das
Verfahren kann ferner das Identifizieren partieller logischer Zugriffspfade
und das Vergleichen logischer Zugriffspfadwerte der partiellen Zugriffspfade
mit der SAN-Zugriffspfad-Policy aufweisen.
-
Die
Konfigurationsinformation kann Geräteeigenschaften enthalten,
die aus einer Server-ID, einer Server-Port-Konfiguration, einer Switch-Port-Konfiguration,
einer Switch-ID, einem Switch-IP und einer Domain-ID ausgewählt werden, eine
Gruppeneinteilung von Geräten,
eine Zoneneinteilung von Geräten,
eine Speichergerät-ID,
LUNs von Speichergeräten
und LUN-Maskierungen (Maskings). Attribute logischer Zugriffspfade
können
Attribute aufweisen, die aus einem Redundanzpegel, einem Redundanztyp,
der Anzahl von Hops, der Anzahl zugewiesener Ports, einer Bandbreite,
der Kompa- tibilität
von Komponenten, Nachbarschaftsbeschränkungen und dem Typ der Komponentenauthentifizierung
ausgewählt
werden. Das Verfahren kann ferner Benutzerdefinitionen verwenden,
um mindestens zwei logische Zugriffspfade zu gruppieren, die mindestens
einen logischen Pfadattributwert gemeinsam verwenden oder innerhalb
eines Bereichs vordefinierter logischer Pfadattributwerte liegen.
Das Erfassen von Konfigurationsinformation kann das Abfragen eines
SAN-Gerät-API,
das Simulieren einer CLI-Session durch ein SAN-Gerät und das
Kommunizieren mit einem SAN-Gerät
unter Verwendung eines CIM- oder SNMP-Protokolls aufweisen.
-
Das
Verfahren kann ferner ein Änderungsereignis
durch Erfassen von SAN-Ereignis-Beschreibungsinformation und das Verarbeiten
der SAN-Ereignis-Beschreibungsinformation zum Identifizieren logischer
SAN-Zugriffspfade aufweisen, die Attributwerte aufweisen, die nicht
der SAN-Zugriffspfad-Policy
entsprechen, wodurch ein geänderter
Zustand des SANs identifiziert wird.
-
Ein
SAN-Änderungsereignis
kann eine fehlerhafte Änderung
in einer SAN-Gerätekonfiguration, eine
geplante Änderung
in einer SAN-Gerätekonfiguration
und/oder ein Gerätefehler
sein. Die SAN-Ereignis-Beschreibungsinformation kann durch mindestens
eines der folgenden Verfahren erhalten werden: Abfragen, Trapping
nach Auftreten eines Ereignisses, durch eine direkte Eingabe durch
einen Administrator, Zuführen
eines eine beabsichtigte Änderung
anzeigenden Eingangssignals von einem Provisioning System, Abfangen
eines Änderungsbefehls vor
dem Auftreten eines Ereignisses.
-
Weitere
Merkmale und Vorteile der vorliegenden Erfindung werden anhand der
folgenden Beschreibung bevorzugter Ausführungsformen und der Patentansprüche deutlich.
-
Kurze Beschreibung der
Zeichnungen
-
Die
folgenden Figuren zeigen bestimmte exemplarische Ausführungsformen
der Erfindung, in denen ähnliche
Bezugszeichen ähnliche
Elemente bezeichnen. Die dargestellten Ausführungsformen dienen lediglich
zur Erläuterung
der Erfindung und sollen die Erfindung nicht einschränken.
-
1 zeigt
ein schematisches Diagramm eines exemplarischen Storage Area Netzwerks
(SAN) mit physikalischen Verbindungen und einem erfindungsgemäßen SAN-Validations-Manager;
-
2 zeigt
ein schematisches Diagramm eines komplexen kleinen bis mittelgroßen SAN;
-
3 zeigt
zwei exemplarische logische Zugriffspfade zwischen einem Server
und einem anderen Server, wobei der Zugriffspfad einer Zugriffs-Policy
entspricht;
-
4 zeigt
ein schematisches problemorientiertes Ablaufdiagramm zum Validieren
eines Zustands eines SAN;
-
5 zeigt
eine Bildschirmkonsole des SAN-Validierungs-Managers von 1;
-
6 zeigt
eine Auswahl eines nichtübereinstimmenden
Pfades in einer Pfadlistentabelle und eine topologische Ansicht;
-
7 zeigt
ein schematisches problemorientiertes Ablaufdiagramm zum Validieren
eines Ereignisses in einem SAN; und
-
8 zeigt
ein exemplarisches Nichtübereinstimmungs-Bildschirmfenster
des SAN-Validations-Managers von 1.
-
Ausführliche Beschreibung der Erfindung
-
Ein
Storage Area Netzwerk (SAN) ist ein Netzwerk, das ermöglicht,
daß mehrere
Anwendungen auf mehreren Servern auf Daten zugreifen (Daten lesen
und schreiben) können,
die auf mehreren gemeinsam genutzten Speichergeräten gespeichert sind. Ein SAN
besteht aus miteinander verbundenen speziellen SAN-Geräten (z.B.
aus verschiedenartigen Switches) und basiert auf mehreren möglichen speziellen Übertragungsprotokollen
(z.B. Fibre Channel und iScsi). Jeder Server ist über eine
oder mehrere spezielle Netzwerkkarten (z.B. HBA) mit einem SAN verbunden.
Anwendungsdaten sind auf den Speichergeräten in als LUNs bezeichneten
Speichereinheiten gespeichert.
-
1 zeigt
eine topologische Ansicht eines exemplarischen Storage Area Netzwerks
(SAN) 10 mit mehreren SAN-Peripheriegeräten, wie beispielsweise Servern 102, 104, 106, 108, 110, 112,
Switches 122, 124, 126 und Anwendungsdatenspeichergeräten 132, 134.
Die Speichergeräte
können
beispielsweise Plattenlaufwerke, z.B. RAID-Geräte, Bandlaufwerke oder andersartige
Massenspeichergeräte
sein. Die physikalischen Verbindungspfade zwischen verschiedenen
SAN-Peripheriegeräten sind
durch durchgezogene Linien dargestellt. Die Speichergeräte 132, 134 können weiter
unterteilt werden in Datenspeicherbereiche mit einer eindeutigen
LUN (Logical Unit Number) 131, 133, 135.
-
Vorhandene
SANs in mittleren und großen Unternehmen,
wie beispielsweise in 2 dargestellt, weisen gegenwärtig jeweils
mehrere hundert bis mehrere tausend verbundene Server, mehrere zehn
bis mehrere hundert Switches und mehrere zehn bis mehrere hundert
Speichergeräte
auf. Außerdem
wachsen diese Umgebungen weiterhin rapide an, in einigen Fällen verdoppeln
sie sich innerhalb eines Jahres. In derartigen Umgebungen kann die Vernetzung
von Geräten
und Verbindungen außerordentlich
komplex sein, und es existieren exponentiell viele physikalische
Routen zwischen jeder Anwendung und jeder LUN in einem Speichergerät.
-
Gemäß 3 können Daten
zwischen einer Anwendung 106 und gespeicherten LUNs, z.B.
der LUN 135, auf irgendeiner der vorhandenen physikalischen
Routen nur dann fließen,
wenn alle Komponenten entlang dieser Route so eingestellt sind,
daß sie
ermöglichen,
daß diese
Anwendung auf dem Server mit der entsprechenden LUN kommunizieren kann.
Insbesondere kann jedes SAN-Gerät
derart eingestellt sein, daß Verkehrsflüsse durch
dieses Gerät
nur zu spezifischen Endpunkte logisch begrenzt sind (unter Verwendung
verschiedener Verfahren in Abhängigkeit
von dem Gerätetyp
und vom Verkäufer).
Beispielsweise unterstützt
jeder Switch typischerweise die Definition verschiedener Typen von Zonen,
die Sätze
von Geräteports
sind, zwischen denen Daten über
diesen Switch fließen
können.
Speichergeräte
unterstützen
typischerweise LUN-Masking, wodurch Einschränkungen bezüglich Servern auferlegt werden,
die auf eine LUN zugreifen können. Ähnlicherweise
unterstützen
HBAs typischerweise Typen von LUN-Maskings, die einschränken, auf
welche LUNs von diesem Server zugegriffen werden kann.
-
Daher
müssen
für einen
End-to-End-Datenfluß von
einer spezifischen Anwendung zu einer spezifischen LUN sowohl physikalische
Bedingungen (es muß mindestens
ein physikalischer Pfad zwischen dem entsprechenden Server und dem
entsprechenden Speicher vorhanden sein), als auch verschiedene logische
Bedingungen in allen Geräten entlang
dieser Route erfüllt
sein (die Zoneneinteilung in jedem Switch und das LUN- Masking an der HBA und
dem Speichergerät
sollten auf eine Weise gesetzt sein, gemäß der der Datenverkehr zwischen diesen
Endpunkten nicht deaktiviert oder unterbrochen wird).
-
In
Zusammenhang mit der vorliegenden Erfindung bezeichnet der Ausdruck
logischer Zugriffspfad einen logischen Kanal zwischen einer vorgegebenen
Anwendung und einer vorgegebenen LUN, entlang dem Daten fließen können. D.h.,
ein logischer Zugriffspfad ist eine Folge von Komponenten über einen
HBA, die bei einer spezifischen Anwendung auf einem spezifischen
Server beginnen, und eine Folge aus einer Anzahl (von einem oder
mehr) Switches und physikalischen Verbindungen, die zu einem Speichercontroller
und einem Speichergerät führt, das
eine spezifische LUN aufweist, so daß der logische Zustand (Konfigurationszustand)
jeder Komponente entlang des Weges in dieser Folge (z.B. des HBA,
des Speichercontrollers und jedes der Switches) derart gesetzt wird,
daß der
Datenfluß zwischen
dieser spezifischen Anwendung und der spezifischen LUN entlang der
spezifischen Folge nicht unterbrochen wird.
-
3 zeigt
einen logischen Pfad zwischen zwei Endpunkten, die im vorliegenden
Beispiel durch den Server 106 und die LUN 135 gebildet
werden. Für
jeden dieser logischen Zugriffspfade muß nicht nur die physikalische
Konnektivität
vorhanden sein, sondern auch die logische Einrichtung jeder der
2 HBAs, die Zoneneinteilung in jedem der Switches und das LUN-Masking
am Speichergerät
müssen alle
derart gesetzt sein, daß Datenflüsse zwischen den
beiden Endpunkten entlang diesen logischen Kanälen ermöglicht werden. Beispielsweise
muß die Zoneneinteilung
des Switch 122 derart definiert sein, daß der dem
Server 106 entsprechende Port und der dem Speichergerät der LUN 135 entsprechende
Port in der gleichen Zone liegen.
-
Logische
Zugriffspfade können
zugeordnete Pfadattribute aufweisen, die als spezifische Merkmale
oder Eigenschaften betrachtet werden können, die jeden logischen End-to-End-Zugriffspfad charakterisieren.
Wie nachstehend ausführlich
beschrieben wird, stellen diese Pfadattribute spezifische Eigenschaften
des logischen Zugriffspfades dar und beschreiben beispielsweise
Aspekte der Verfügbarkeit, des
Leistungsvermögens
und der Sicherheit jedes vorgegebenen logischen End-to-End-Kanals.
D.h., wie nachstehend beschrieben wird, kann für einen spezifischen logischen
Zugriffspfad ein bestimmter Wert für jedes der definierten Attribute
berechnet werden (wobei der Wert einen bestimmten Eigenschaftswert
für diesen
spezifischen logischen Zugriffspfad darstellt.
-
Die
Berechnung eines bestimmten Attributwertes für einen bestimmten logischen
Zugriffspfad kann auf Information basieren, die mit der Folge verbundener
Komponenten in Beziehung steht, sowie auf Information über die
Typen und inneren Konfigurationszustände einer beliebigen Anzahl
von Komponenten, die in diesem logischen Zugriffspfad angeordnet
sind. Diese berechneten Werte (an Stelle einiger untergeordneten
Eigenschaften einer physikalischen Verbindung oder des einen oder
anderen Geräts)
stellen die Eigenschaften des End-to-End-Datenflusses zwischen einer
Anwendung und ihren zugeordneten Daten dar (d.h. Aspekte, die mit
dem End-to-End-Verfügbarkeitsgrad,
der End-to-End-Performance und der End-to-End-Sicherheit in Beziehung
stehen und Datenflüsse
entlang dieses logischen Zugriffspfades charakterisieren). Aus diesem Grunde
spielen diese hergeleiteten Eigenschaftswerte des abstrakten logischen
Zugriffspfades eine wichtige Rolle aus der Perspektive einer Anwendung
(und damit eines Unternehmens).
-
Gemäß einer
Ausführungsform
können
logische Zugriffspfade in einem SAN bestimmt und validiert werden.
Durch den Validierungsprozeß werden die
logischen Zugriffspfade identifiziert, die in einem spezifischen
SAN-Zustand vorhanden sind, wird der Wert jedes Attributs für jeden
der vorhandenen Zugriffspfade berechnet, und werden die identifizierten Zugriffspfade
und die berechneten Attributwerte mit vorgegebenen Bedingungen verglichen,
die gemäß einer
vorgegebenen logischen Zugriffspfad-Policy spezifiziert sind.
-
4 zeigt
ein exemplarisches Prozeßablaufdiagramm
zum Darstellen des Validierungsprozesses 400. In einem
er sten Schritt 402 des Prozesses 400 wird eine
logische Zugriffspfad-Policy definiert. Die Policy wird durch eine
Policy-Datenstruktur dargestellt, die durch das den Validierungsprozeß ausführende System
z.B. in der Policy Engine 16 des SAN-Managers 12 (1 und 3)
gespeichert wird. Die Policy (d.h. der Zustand der Policy-Datenstruktur)
wird nur durch geeignet autorisierte Personen definiert (und/oder
aktualisiert). Die Policy weist eine Liste logischer Zugriffspfade
auf, die vorhanden sein müssen,
und für
jeden Zugriffspfad den Wert, den jedes Attribut haben sollte. Diese
Liste ist exklusiv, d.h., daß jeder
logische Zugriffspfad, der nicht in der Liste aufgeführt ist,
nicht existieren sollte. Jeder logische Zugriffspfad in der Policy
ist durch seine beiden Endpunkte definiert: Anwendung/Server-ID
und Daten/LUN-ID. In der Policy können Werte für jeden Zugriffspfad
für jedes
der folgenden Attribute definiert werden (die Definition für jedes
dieser Attribute, und die Weise, wie jedes der Attribute berechnet
wird, wird nachstehend beschrieben): Redundanzpegel, Redundanztyp,
Anzahl von Hops, Anzahl zugewiesener Ports, Bandbreite, Kompatibilität von Komponenten,
Nachbarschaftseinschränkungen
und Typ der Komponentenauthentifizierung. Die logische Zugriffspfad-Policy kann durch
einen autorisierten Administrator direkt festgelegt oder (durch
eine autorisierte Person) von einer externen Quelle importiert werden.
Erforderliche Attributwerte in der Policy können durch den autorisierten
Administrator für
jeden einzelnen Zugriffspfad oder für eine (benutzerdefinierte)
Gruppe von Zugriffspfaden gesetzt werden. Das Setzen eines bestimmten
Attributwertes für
eine Gruppe logischer Zugriffspfade beinhaltet, daß jeder logische
Zugriffspfad der Gruppe den bestimmten Attributwert oder einen Attributwert
in einem vorgegebenen Bereich um den vorgegebenen Attributwert aufweisen
muß. Die
logische Zugriffspfad-Policy kann erforderliche Korrespondenzbeziehungen
zwischen verschiedenen Zugriffspfaden reflektieren, z.B. im Fall
von mehreren clusterförmig
angeordneten Servern, mehreren miteinander in Beziehung stehenden
unabhängigen
SAN- Umgebungen an
verschiedenen physischen Orten für
Disaster Recovery- (DR) Anwendungen und in anderen Fällen.
-
In
Schritt 404 des Prozesses 400 wird Zustandinformation
von den SAN-Geräts
erfaßt
oder abgerufen, die später
verwendet wird, um zu bestimmen, welche Zugriffspfade tatsächlich existieren,
und die Attributwerte für
jeden Zugriffspfad zu berechnen. Konfigurations- und Verbindungsinformation
wird von allen Typen von SAN-Geräten,
d.h. von Servern, Switches und LUNs erfaßt. Die von jedem Gerät erfaßt Information
kann einen Gerätestatus,
Geräteigenschaften,
physikalische Konnektivitätsinformation
des Geräts
und einen logischen Konfigurationszustand des Geräts aufweisen.
Diese Information kann durch verschiedene Gerätetypen in verschiedenen Formaten
bereitgestellt werden. Außerdem
sind zum Abrufen dieser Informationselemente von den verschiedenen
Gerätetypen
möglicherweise
verschiedene Verfahren erforderlich. Durch den Validierungsprozeß wird diese
Information unter Verwendung einer Kombination aus Abrufverfahren
für jeden
Gerätetyp
erhalten, wobei z.B. Gerät-APIs
verwendet werden, CLI-Sessions simuliert werden, CIM-Standardprotokolle
und SNMP-Protokolle verwendet werden.
-
In
Schritt 406 des Prozesses 400 wird die erfaßte Information
standardisiert, um Diskrepanzen zwischen von verschiedenen Quellen
erhaltener, miteinander in Beziehung stehender Information zu eliminieren.
Die Grobinformation kann in verschiedenen Formaten dargestellt werden
und verschiedene Semantiken aufweisen, so daß die Information standardisiert
wird, um den relevanten Status und physikalische und logische Zustandinformation
von jedem Gerät
einheitlich darzustellen.
-
Inhaltliche
Diskrepanzen in der standardisierten Information können sich
aus mehreren Gründen
ergeben, z.B. aus geringen Zeitverzögerungen, die in Verbindung
mit dem Empfang von Information von verschiedenen verteilten Geräten und
verschiedenen Komplexitäts-
und Zuverlässigkeitsgraden verschiedener
Gerätetypen
auftreten. Solche Diskrepanzen können
beispielsweise darin bestehen, daß zwei verschiedene Geräte die Eigenschaften
ihrer wechselseitigen Verbindung auf verschiedene, inkonsistente
Weise beurteilen. Solche Diskrepanzen werden durch einen Validierungsprozeß basierend auf
dem Zeitpunkt behoben und gelöst,
zu dem bestimmte Informationselemente erhalten werden (wobei z.B.
spätere
Information gegenüber
früherer
Information, durch die ein Konflikt verursacht wird, bevorzugt wird),
und basierend auf relativen Gewichten, die auf geschätzten Zuverlässigkeitsgraden
spezifischer zu analysierender Geräte basieren.
-
Im
nächsten
Schritt 408 werden die logischen Zugriffspfade identifiziert,
so daß eine
abstrakte Graphdarstellung des SAN konstruiert werden kann. Die
Verbindungs- und Konfigurationszustandinformation von jedem der
Geräte
kann in einem zusammengesetzten oder gemeinsamen Prozeß verwendet
werden, um eine abstrakte Graphdarstellung des Netzwerks zu erzeugen,
die die logischen Zugriffspfade im SAN darstellt. Jedes SAN-Gerät kann als
Knoten im Graph dargestellt werden. Endknoten stellen Anwendungen/Server
(Quellenendpunkte) und Speicher/LUNs (Zielendpunkte) dar. Im ersten Teil
der Konstruktion des abstrakten Graphen stellt jeder Rand zwischen
Knoten eine vorhandene physikalische Verbindung zwischen dem SAN-Gerät (oder zwischen
einem SAN-Gerät
und einem SAN-Endpunkt)
dar. Im nächsten
Teil der Konstruktion werden Ränder
eliminiert, wenn logische Einschränkungen (die beispielsweise
durch eine Gerätekonfiguration definiert
sind) vorhanden sind, die Datenflüsse auf dieser Verbindung unterbrechen.
Durch diese iterative Konstruktion wird ein abstrakter Graph erhalten,
in dem ein logischer Zugriffspfad zwischen einer Anwendung auf einem
Server und einer LUN auf einem Speichergerät dann und nur dann existiert,
wenn im abstrakten Graph ein Pfad zwischen den entsprechenden Endknoten
existiert. Zum Verbessern der Prozeßeffizienz wird der Iterationsschritt
zum Eliminieren (Beschneiden) von Graphrändern basierend auf logischen
Einschränkungen,
die durch die Gerätekonfigurationseinstellung
erhalten werden, in einer Reihenfolge ausgeführt, gemäß der gewährleistet wird, daß die Ränder so
früh wie
möglich
und in einem möglichst hohen
Maß beschnitten
werden (wodurch die Komplexität
reduziert wird). Zu diesem Zweck werden SAN-Symantiken verwendet,
um die Folge zu bestimmen, in der Geräteeinschränkungen berücksichtigt werden. Beispielsweise
kann eine LUN-Masking-Einschränkung bezüglich eines
Geräts,
das den größten Teil
des potentiellen Datenflusses entlang der physikalischen Pfade einschränkt, verwendet
werden, um den Graphen zu beschneiden, bevor eine Zoneneinteilungs-Einschränkung bezüglich eines
anderen Geräts
berücksichtigt
wird, das eine geringere Anzahl von Datenflüssen einschränkt.
-
In
Schritt 410 des Prozesses 400 werden Attributwerte
für jeden
der existierenden logischen Zugriffspfade gemäß den in der logischen Zugriffspfad-Policy
spezifizierten Attribut-Sollwerten berechnet. Die Attributwerte
bezeichnen unter anderem: einen Redundanzpegel, einen Redundanztyp,
die Anzahl von Hops, die Anzahl zugewiesener Ports, die Kompatibilität von Komponenten,
Nachbarschaftseinschränkungen
und einen Authentifizierungstyp.
-
Die
Attributwerte werden basierend auf dem konstruierten abstrakten
Graphen und der SAN-Geräteinformation
auf die folgenden Weisen berechnet. Der "Redundanzpegel"-Attributwert wird durch Bestimmen der
Anzahl von unabhängigen,
d.h. durch kein verbundenes Zwischen-Gerät verlaufenden, Graphpfaden
zwischen den vorgegebenen Endpunkten berechnet. Der verwendete Algorithmus
ist eine Adaption bekannter Graphalgorithmen für dieses spezifische Problem,
z.B. BFS und Graph Coloring, und wird auf eine problemorientierte
Weise verwendet, die typische SAN-Topologieeigenschaften (wie vorstehend
beschrieben) für
eine optimierte Ausführungszeit
reflektiert. Der erhaltene Algorithmus ist sehr effizient und hat
eine Rechenkomplexität
von O (D2).
-
Das "Redundanztyp"-Attribut wird basierend auf
den Eigenschaften oder Kenngrößen der
Komponenten der Geräte
in unabhängigen
Pfaden berechnet (z.B. in Abhängigkeit
davon, ob alle Zwischenpfad-Geräte
verschiedenen SAN-Unternehmensstandorten zugeordnet sind). Das "Anzahl von Hops"-Attribut eines logischen
Zugriffspfades bezeichnet die Anzahl von Zwischenknoten im konstruierten
abstrakten Graph. Das "Anzahl
zugewiesener Ports"-Attribut
für einen
vorgegebenen Zugriffspfad wird basierend auf Portzuweisungsinformation
bestimmt, die von den dem abstrakten Graph entsprechenden Geräten erhalten
wird. Das "Bandbreite"-Attribut wird basierend
auf den Leistungscharakteristiken aller Geräte und Verbindungen berechnet,
die dem abstrakten Graph zugeordnet sind, und auf bestimmten End-to-End-Leistungscharakteristiken,
die auf dem logischen Zugriffspfad erreicht werden können. Das "Kompatibilität von Komponenten"-Attribut wird basierend
auf dem Gerätetyp,
Modellen, der Firmware-Version und ähnlicher Information für jedes Gerät entlang
des Pfades berechnet und reflektiert potentielle Kompatibilitätskonflikte
entlang eines logischen Zugriffspfades. Das "Nachbarschaftseinschränkungen"-Attribut basiert
auf einer Untersuchung aller anderen logischen Zugriffspfade, die
Geräte
in einem vorgegebenen Zugriffspfad kreuzen, und reflektiert potentielle,
mit Sicherheitsaspekten in Beziehung stehende Anfälligkeiten
(z.B. ob eine anfällige
Web-Anwendung einen logischen Zugriffspfad aufweist, der einen Switch
aufweist, der auch auf dem logischen Zugriffspfad einer sehr sensitiven
internen Finanzanwendung liegt). Das "Authentifizierungstyp"-Attribut reflektiert
den Typ von Mechanismen (ID-basierte
Mechanismen, geheimnis-basierte Mechanismen, Verschlüsselungsfunktion
oder auf einer Zustandssignatur basierende Mechanismen), die verfügbar sein
können,
um Server und Geräte
entlang des logischen Zugriffspfad zu authentifizieren, und reflektieren
einen Sicherheitsgrad, die beispielsweise potentiellen Betrugsangriffen
zugeordnet sind.
-
Die
berechneten logischen Zugriffspfade und ihre berechneten Attribute
werden für
den durch die logische Zugriffspfad-Policy definierten Soll-Zustand berechnet.
Im folgenden Schritt 412 prüft der Prozeß 400,
ob eine Nichtübereinstimmung
aufgetreten ist. Eine Nichtübereinstimmung
bezeichnet jegliche Diskrepanz zwischen dem berechneten Zustand
und der gewünschten
Anforderung oder Bedingung. Insbesondere können drei Typen von Nichtübereinstimmungen
auftre ten: 1. Ein logischer Zugriffspfad zwischen einer Anwendung
und einer LUN müßte existieren,
existiert jedoch nicht. 2. Ein logischer Zugriffspfad darf nicht
existieren (d.h., er ist in der logischen Zugriffspfad-Policy nicht
spezifiziert), existiert jedoch. 3. Ein logischer Zugriffspfad muß existieren
und existiert auch, aber mindestens einer seiner berechneten Attributwerte
unterscheidet sich vom gemäß der logischen
Zugriffspfad-Policy spezifizierten, entsprechenden Sollwert.
-
Außer den
vorstehend beschriebenen Elementen kann eine Policy auch anzeigen,
daß niemals partielle
logische Zugriffspfade existieren dürfen. Die Definition eines
partiellen logischen Zugriffspfad ist derjenigen eines logischen
Zugriffspfads ähnlich,
er beginnt jedoch nicht an einer Anwendung auf einem Server oder
endet nicht an einer LUN auf einem Speichergerät, was bei logischen Zugriffspfaden
immer der Fall ist. Beispielsweise stellt ein Switch, der mit einem
Speichergerät
verbunden ist und derart in Zonen unterteilt ist, daß ein Fluß von einem
bestimmten Server zu einer LUN auf diesem Gerät ermöglicht wird, wobei jedoch ein
derartiger Server keinen Fluß zum
Switch erzeugen kann, einen partiellen Zugriffspfad dar. Partielle
Zugriffspfade existieren häufig
in SANs infolge von Fehlern, als Überbleibsel von Migrationsprozessen
und Änderungen
und aus anderen Gründen
und stellen im allgemeinen eine Gefahr für Unterbrechungen und für die Sicherheit
dar, und durch partielle Zugriffspfade können Ressourcen verschwendet
und kann die Komplexität
erhöht
werden. Zum Identifizieren eines partiellen logischen Zugriffspfades
wird eine analoge Verarbeitung zum Identifizieren logischer Zugriffspfade
(wie vorstehend beschrieben) verwendet, und ein partieller Zugriffspfad wird
im abstrakten Graph als Pfad dargestellt, der an einem Knoten beginnt
oder endet, der selbst kein Endknoten ist.
-
Wenn
im Prozeß 400 in
Schritt 412 eine Nichtübereinstimmung
erfaßt
wird, werden Details der erfaßten
Nichtübereinstimmung
(die vorstehend erwähnten
drei Nichtübereinstimmungstypen
oder ein erfaßter
partieller logischer Zugriffs pfad) einem Nichtübereinstimmungsspeicher hinzugefügt (wie durch
das Bezugszeichen 18 in den 1 und 3 dargestellt
ist). Jede Nichtübereinstimmung
und ihre Kontextdetailinformation werden einem vorgegebenen Empfänger basierend
auf einer vorgegebenen Informationsgabe-Policy mitgeteilt (z.B.
basierend darauf, welche Anwendungen betroffen sind, welcher Nichtübereinstimmungstyp
vorliegt, usw.) (Schritt 314). Die Mitteilung kann durch
mehrere Kommunikationsverfahren übertragen
werden, z.B. durch Erzeugen einer E-Mail, eine SNMP-Meldung, usw. Durch
den Prozeß 400 kann
eine graphische Darstellung der logischen Zugriffspfade bereitgestellt
werden, können
Nichtübereinstimmungen
hervorgehoben dargestellt werden und können Konnektivitätdetails
bis herab zum Geräte-Level
bereitgestellt werden (Schritt 416).
-
Gemäß 5 werden
die logischen Zugriffspfade durch einen SAN-Validations-Manager 12 überwacht
und validiert, der über
Kommunikationskanäle,
z.B. über
Internet- oder Intranet-Verbindungen, mit SAN-Peripheriegeräten kommuniziert,
wie in den 1 und 3 durch
gestrichelte Linien für
exemplarische Geräte
dargestellt ist. Der SAN-Zugriffspfad-Manager 12 fragt über diese
Kommunikationskanäle
die SAN-Peripheriegeräte und Geräte ab und erzeugt
SAN-Konfigurationsinformation und stellt eine topologische Ansicht
z.B. auf dem Monitor 14 dar. Der SAN-Zugriffspfad-Manager 12 kann
außerdem
Detailinformation über
jedes der SAN-Geräte und
Pfade erzeugen. Beispielsweise kann, wie in 5 dargestellt
ist, eine Detailinformation eines Switch durch Anklicken eines auf
einer topologischen Karte des SAN auf dem Monitor 14 dargestellten,
entsprechenden Switch-Elements erhalten werden. Ähnlicherweise können LUN-Eigenschaften, LUN-Masken, Portattribute
und Zonenattribute visuell dargestellt werden. Außerdem können in
einer Änderungsliste Änderungen
von Gerätekonfiguration dargestellt
werden. Der Zugriffspfad-Manager 12 kann durch Software
auf einer Serveranwendung implementiert werden, die z.B. auf einem
Linux- oder Windows®-Betriebssystem läuft.
-
6 zeigt
einen nichtübereinstimmenden logischen
Pfad in einer Pfadlistentabelle, der ausgewählt und in einer topologischen
Ansicht dargestellt werden kann. Nach der Auswahl eines logischen
Pfades in der Pfadlistentabelle werden durch Anklicken eines Änderungslistenfeldes
alle Änderungen
dargestellt, die im SAN aufgetreten sind und mit dem ausgewählten logischen
Pfad in Beziehung stehen. Diese Änderungen
beinhalten alle physischen Operationen und Konfigurationsänderungen,
die bezüglich Geräten ausgeführt wurden,
die dem ausgewählten logischen
Pfad zugeordnet sind, alle Elemente, die durch diese Operationen
betroffen sind, z.B. der logische Pfad, der erscheint und verschwindet,
und Änderungen
des relevanten autorisierten logischen Pfades.
-
Der
Zustand des SAN kann sich aus verschiedenen Gründen häufig ändern, z.B. aufgrund des natürlichen
Wachstums, aufgrund von Migrationsprozessen des Unternehmens, Konsolidierungsprozessen
des Unternehmens, Technologie-Upgrades, Infrastrukturarchitekturänderungen,
Komponentenstörungen,
usw. Jedes individuelle SAN-Ereignis, das einen lokalen Aspekt des
SAN ändert
(z.B. den Zustand eines bestimmten SAN-Geräts oder einer bestimmten Verbindung
modifiziert), kann eine beliebige Anzahl logischer Zugriffspfade
auf verschiedene Weisen beeinflussen.
-
Gemäß 7 wird
in einem Prozeß 700
zum Validieren von SAN-Ereignissen die Auswirkung jeder Änderung
auf einen logischen Zugriffspfad analysiert und die Übereinstimmung
mit der entsprechenden Policy bestimmt. Eine derartige Analyse kann verwendet
werden, um die Auswirkung eines beliebigen Ereignis zu bestimmen,
nachdem es aufgetreten ist, oder die erwartete Auswirkung vorherzusagen, bevor
das Ereignis auftritt.
-
Die
Schritte 702 bis 714 des Prozesses 700 sind
mit den Schritten 402 bis 414 des in 4 dargestellten
Prozesses identisch. Wenn im Prozeß 700 keine Verletzung
einer Zugriffspfad-Policy erfaßt wird,
wird in Schritt 716 ein gültiger SAN-Zustand erhalten.
Anschließend
wird im Prozeß 700 in
Schritt 718 alle relevante Information über ein indi viduelles SAN-Änderungsereignis
bereitgestellt. Diese Information beinhaltet den Ereignistyp (z.B.
Gerät aktiviert oder
deaktiviert, Verbindung aktiviert oder deaktiviert, neues Gerät hinzugefügt, Geräte-Firmware-Update, Änderung
der Geräte-Zoneneinteilung, Änderung des
Geräte-LUN-Masking
und ähnliche),
das beeinflußte
Gerät oder
die beeinflußte
Verbindung (Switch, HBA, Server, Speichergerät, Verbindung, usw.), mit dem
Ereignistyp in Beziehung stehende spezifische Parameter (z.B. Spezifizierung
neuer Zoneneinteilungsinformation, verbundene Ports einer neuen
Verbindung, Aktualisierungsstand neuer Firmware) sowie den Zeitpunkt
des Auftretens des Ereignisses.
-
Diese
Information über
Ereignisse, die im SAN auftreten, werden von SAN-Geräten auf
zwei mögliche
Weisen erhalten. 1. Durch periodisches Abfragen jedes Geräts (mit
einer einstellbaren Häufigkeit),
um alle Zustandänderungen
seit der letzten Abfrage zu bestimmen; 2. Durch Trapping, getriggert durch
eine spezifische Zustandänderung
an spezifischen Geräten,
wobei entsprechende Ereignisinformation übertragen wird.
-
Außerdem kann
in verschiedenen Fällen
Ereignisinformation erhalten werden, während das Ereignis bevorsteht,
und bevor es tatsächlich
aufgetreten ist. Beispielsweise können, wenn das Ereignis beispielsweise
Teil eines geplanten Änderungsprozesses
ist, Details darüber
erfaßt
werden, bevor der Prozeß ausgeführt wird,
und basierend auf Validierungsprozeßergebnissen kann das Ereignis
später ausgeführt, annulliert
oder modifiziert werden, um eine Übereinstimmung mit der logischen
Zugriffspfad-Policy zu gewährleisten.
-
In
diesen Fällen
kann eine apriori-Ereignisinformation (wie vorstehend erwähnt) auf
mehrere Weisen erhalten werden. Diese Information kann durch einen
SAN-Administrator als Detailinformation über eine vorgesehene Änderung
direkt bereitgestellt werden. Die Information kann auch durch eine
Wechselwirkung mit einem externen Modul bereitgestellt werden, das
für ein
SAN-Geräte-Provisioning
verantwortlich ist (z.B. eine durch EMC Corp. für diesen Zweck entwickelte Software),
das Detailinformation über
eine vorgesehene Änderung
mitteilen kann, bevor sie abgerufen wird. Schließlich kann die Information
von abgefangenem Verkehr (der z.B. von einer SAN-Management-Konsole
erhalten wird), Analysieren der Inhalte eines fliegenden (On-the-Fly) Änderungsbefehls
zum Extrahieren der relevanten Information (und möglicherweise
Blockieren des Änderungsbefehls,
bis der Analyseprozeß abgeschlossen ist)
extrahiert werden.
-
Information über jedes
individuelle SAN-Ereignis (apriori- oder postpriori-Ereignisinformation, wie
vorstehend beschrieben) wird als Eingangsinformation zum Bestimmen
einer Auswirkung auf alle logischen SAN-Zugriffspfade und ihrer Übereinstimmung
mit der logischen Zugriffspfad-Policy verwendet (im Fall einer apriori-Ereignisinformation
bezieht sich die Analyse auf einen simulierten SAN-Zustand, und
im Fall einer postpriori-Ereignisinformation bezieht sich die Analyse
auf einen tatsächlichen SAN-Zustand)
(Schritt 720). Jedes einzelne lokale Änderungsereignis kann mehrere
logische Zugriffspfade löschen,
eine beliebige Anzahl neuer logischer Zugriffspfade erzeugen oder
eine beliebige Anzahl von Attributwerten für eine beliebige Anzahl von
Zugriffspfaden ändern.
Die Analyse der Auswirkung eines Änderungsereignisses auf die
logischen Zugriffspfade entspricht dem vorstehend beschriebenen
Prozeß zum
Validieren logischer Zugriffspfade. Insbesondere wird der den letzten
SAN-Zustand darstellende abstrakte Graph auf folgende Weise erweitert, so
daß er
die neue SAN-Ereignisinformation widerspiegelt. Ereignisse des Typs "Gerät aktiviert
oder deaktiviert", "Verbindung aktiviert
oder deaktiviert" werden
als Knoten oder Ränder
dargestellt, die jeweils hinzugefügt oder gelöscht werden. Logische Zustandänderungen,
wie beispielsweise eine neue Zoneneinteilung oder neue LUN-Msking-Zustände, werden
durch Hinzufügen
neuer Ränder
oder Löschen
vorhandener Ränder
gemäß der vorstehend beschriebenen
Logik dargestellt.
-
Der
erhaltene abstrakte Graph wird als Basis für eine Analyse logischer Zugriffspfad-Attributwerte verwendet,
die der im SAN-Validierungsprozeß beschriebenen Analyse gleicht. Ähnlicherweise
werden in Schritt 722 die Ergebnisse dieser Analyse mit
der logischen Zugriffspfad-Policy verglichen, Nichtübereinstimmungen
identifiziert, und geeignete Meldungen erzeugt. Die Änderungsereignisinformation
wird in einem SAN-Änderungsspeicher
gespeichert. Änderungsinformation
mit ihrer entsprechenden Auswirkung auf einen logischen SAN-Zugriffspfad kann
graphisch oder tabellarisch mit geeigneten Drill-Down-Fähigkeiten
zum Geräte-Level
dargestellt werden. Durch die Effizienz des SAN-Ereignis-Validierungsprozesses
und die damit in Beziehung stehende Optimierung wird ermöglicht,
daß dieser
Prozeß für jedes
Ereignis auch in Umgebungen, in denen SAN-Änderungsereignisse sehr häufig auftreten, ausgeführt und
schnell abgeschlossen werden kann.
-
Der
vorstehend beschriebene SAN-Ereignis-Validierungsprozeß kann durch
Hinzufügen
eines SAN-Änderungsplanspeichers
erweitert werden, der Vorspezifizikationen geplanter Aufgaben und
ihre zugeordneten individuellen geplanten SAN-Änderungsereignisse enthält. Ein
derartiger Änderungsplan kann
für viele
Zwecke nützlich
sein. Er kann vorübergehende
Nichtübereinstimmungen
für eine
begrenzte Zeitdauer während
der Ausführung
einer vollständigen
Aufgabe zulassen (z.B. ohne daß eine
Mitteilung über
die Nichtübereinstimmung
erzeugt wird). Typische Aufgaben, z.B. das Hinzufügen eines
neuen Anwendungsservers (und damit eines oder mehrerer logischer
Zugriffspfade) zum SAN kann zahlreiche, manchmal 10–20 einzelne Änderungsereignisse beinhalten,
die jeweils häufig
eine vorübergehende Nichtübereinstimmung
logischer Zugriffspfade verursachen (wobei dieser Zustand behoben
sein sollte, wenn die Aufgabe vollständig abgeschlossen ist). In vielen
Fällen
kann es dagegen wünschenswert
sein, die Korrespondenz zwischen tatsächlichen Ereignissen und den
im Änderungsplan
spezifizierten Ereignissen festzulegen und jegliche Abweichungen
durch eine geeignete Mitteilung zu identifizieren, die anzeigt,
ob diese Abweichungen auch eine Nichtübereinstimmung logischer Zugriffspfade
verursacht haben. Diese Fähigkeit
in Kombination mit den anderen beschriebenen Vali dierungsprozessen
trägt dazu
bei, die Kontrolle eines beliebigen SAN-Änderungsprozesses zu verbessern,
seine Effizienz zu erhöhen und
sein Risikopotential zu vermindern.
-
Gemäß einem
anderen Aspekt der vorliegenden Erfindung kann die Authentifizierung
von Komponenten in logischen SAN-Zugriffspfaden
auf verschiedene Weisen verbessert werden. Durch eine strenge Authentifizierung
können
Versuche von Tätern
vereitelt werden, zu "betrügen" – zu veranlassen, daß ein Gerät sich für ein anderes
ausgibt – um
einen nicht autorisierten Zugriff zu Daten zu erhalten, indem ein
nicht autorisierter logischer Zugriffspfad erzeugt und genutzt wird.
-
Ein
verbesserter Authentisierungsprozeß weist die folgenden Schritte
auf:
- • Eine
Schlüssel-
(Initiation Key) Verteilungsphase, in der jedes SAN-Gerät zuverlässig eine
zugeordnete, global eindeutige Identifizierung und ein entsprechendes
Authentisierungsmaterial aufweist (eine derartige Verteilung kann
als Teil des Schlüsselmanagement-Lebenszyklus des
logischen SAN-Zugriffspfades nach Erfordernis wiederholt werden).
- • Als
Reaktion auf vorgegebene Ereignisumstände (z.B. einen Konfigurationsänderungsversuch) wird
ein geeigneter Authentisierungsprozeß getriggert. In Abhängigkeit
vom betreffenden Gerätetyp
und den Ereignisumständen
werden ein oder mehrere Authentisierungsmechanismen verwendet, um
zu entscheiden, daß ein
Gerät,
das eine (global eindeutige) Identifizierung anfordert, tatsächlich dieses
authentische Gerät
ist. Die für
diese Authentisierung verwendeten Mechanismen können eines oder mehrere der
folgenden Elemente aufweisen: ein statisches Geheimnis, ein dynamisches
einmaliges Geheimnis, einen kryptografischen öffentlichen/privaten Schlüssel, einen
Konfigurationszustand, ein Verhaltensmusterprofil.
-
Der
Authentisierungsprozeß kann
ferner das Bereitstellen eines sicheren und authentischen Kanals
zwischen Geräten aufweisen,
nachdem die Validierung der Geräte-Authentisierung
erfolgreich abgeschlossen ist, wobei der Authentisierungsprozeß in Verbindung
mit beliebigen Typen von Storage Area Netzwerk-Protokollen funktioniert,
wie beispielsweise Fibre-Channel, iScsi und Infiniband.
-
Um
die Integrität
und die Sicherheit der logischen SAN-Zugriffspfade weiter zu verbessern,
kann an jedem der mit dem SAN verbundenen Server ein leichtgewichtiger
residenter Software-Agent bereitgestellt werden. Jeder Agent wechselwirkt über einen herkömmlichen
sicheren Kanal mit dem SAN-Validierungsprozeß. Durch
dieses Verfahren wird mit einer hohen Wahrscheinlichkeit die Integrität des Agenten auch
hinsichtlich Versuchen, seine Identität zu modifizieren, zu fälschen oder
nachzubilden, gewährleistet.
Der Agent ist für
eine Zugriffsverkehrüberwachung,
eine Verarbeitung logischer SAN-Zugriffspfade und Authentisierungsfunktionen
verantwortlich, ohne daß das
Leistungsvermögen
des Servers herabgesetzt wird.
-
Das
Verfahren und das System weisen durch Software ausgeführte Prozesse
auf, die:
- • Die
Konsistenz bestimmter Datenmeldungen zwischen den Servern und den
SANs gewährleisten
und gegebenenfalls eine geeignete Alarmierungs/Blockieroperation
ausführen.
- • Die
Authentisierung/Integrität
von Anwendungsmodulen auf dem entsprechenden Server unter Verwendung
von Zustand und Verhaltensinformation bereitstellen.
- • Die
Konsistenz zwischen einer Anwendungsdatenzugriffs-Policy und einem
tatsächlichen
Zugriff in einem bestimmten Anwendungsausführungszustand und einem bestimmten
Zugriffswechselwirkungsdatenzustand erzwingen.
- • Die
Authentisierung des Servers und seiner Module für das zentrale Authentisierungssteuerungsmodul
unterstützen.
- • Die
Selbstintegrität
und den Selbstschutz hinsichtlich arglistiger Versuche, die Serversicherheit zu
durchbrechen, gewährleisten.
-
Die
vorliegende Erfindung wurde vorstehend in Verbindung mit bevorzugten
Ausführungsformen dargestellt
und ausführlich
beschrieben, für
Fachleute ist jedoch ersichtlich, daß verschiedenartige Modifikationen
und Verbesserungen vorgenommen werden können. Daher ist der Schutzumfang
der vorliegenden Erfindung ausschließlich durch die beigefügten Patentansprüche beschränkt.
-
Zusammenfassung
-
Durch
die vorliegende Erfindung wird ein Verfahren und ein System zum
Validieren logischer Zugriffspfade in einem Storage Area Netzwerk
bereitgestellt. Erfindungsgemäß wird die
Definition einer SAN-Zugriffspfad-Policy unterstützt, die darstellt, welche
logischen Zugriffspfade von Anwendungen zu Daten-LUNs nicht existieren
sollten oder existieren sollten, und welche End-to-End-Attribute
jedem Zugriffspfad zugeordnet sein sollten. Erfindungsgemäß wird ein
SAN-spezifischer,
graph-basierter Validierungsalgorithmus basierend auf Information
ausgeführt,
die unter Verwendung verschiedener nicht-störender oder nicht-betriebsunterbrechender Mechanismen
von im SAN verteilten Geräten
automatisch erfaßt
wird. Erfindungsgemäß können Nichtübereinstimmungen
tatsächlicher
logischer Zugriffspfade bezüglich
den durch die Policy bestimmten Soll-Zugriffspfaden identifiziert
werden. Erfindungsgemäß können Meldungen über Nichtübereinstimmungen
in Kombination mit relevanter Kontextinformation unter Verwendungen
verschiedener Einrichtungen oder Verfahren an einen geeigneten Empfänger übertragen
werden.