Storage Area Network (SAN)

Storage Area Network (SAN) Technologie, Konzepte und Einsatz komplexer Speicherumgebungen von Björn Robbe erweitert, überarbeitet Storage Area Network (SAN) Robbe schnell und portofrei erhältlich bei beck-shop.de DIE FACHBUCHHANDLUNG Hanser München 2004 Verlag C.H. Beck im Internet: www.beck.de ISBN 978 3 446 22597 8 Inhaltsverzeichnis: Storage Area Network (SAN) Robbe

Kapitel 9 SAN-Management Ein SAN ermöglicht zumindest theoretisch ein Zusammenschalten von 15,6 Millionen Ports. Diese doch recht stattliche Summe ermöglicht auch den größten Unternehmen einen Aufbau eines schnellen und umfassenden Speichernetzwerkes. Diese Größenordnung wird nur erreicht, wenn in einem Fabric auch Loops verwendet werden. In einer reinen Umgebung aus Switched und Point to Point -Verbindungen wird eine Größenordnung von rund 64.000 Ports erreicht. Diese 64.000 Ports wollen aber auch verwaltet werden. Selbst wenn man von nur 300 oder 400 Ports ausgeht, bedeutet das in der Regel um die 100 Server. Und auch ein SAN hat seine Tücken. 9.1 End to End-Management Betrachtet man das SAN Management, liegt die wohl größte Herausforderung in dem Fakt, daß hier ein äußerst komplexes Netzwerk zum Zusammenschluß von diversen Speichersubsystemen mit verschiedenartigsten Servern genutzt wird. Denn der einzigartige Vorteil eines SAN ergibt sich erst aus diesem Fakt. Und alle Systeme in einem SAN stehen in einer physikalischen und logischen Beziehung zueinander. Entsprechend gibt es verschiedene Aufgaben, die das Management eines SANs übernehmen muß.

178 9 SAN-Management Folgende Variationen lassen sich unter anderem bestimmen: Applikationsmanagement Clustermanagement Datenmanagement Fehlermanagement Konfigurationsmanagement Netzwerkmanagement Performancemanagement Ressourcenmanagement Sicherheitsmanagement... Die komplette Datenbewegung in einem SAN muß gesteuert werden. Ein End to End -Management ist für einen effektiven Datenverkehr notwendig. Daher lassen sich die einzelnen Managementaufgaben hierarchisch in fünf Schichten einordnen. Tabelle 9.1: Schichten des SAN-Managements Nr. Schicht Funktionen 5 Applikationsmanagement Ressourcenoptimierung über die unterschiedlichen Geschäftsprozesse Failover/Failback/Clustermanagement Lastverteilung 4 Datenmanagement Backup & Restore Datenbewegungen File Management Hierarchisches Speichermanagement 3 Ressourcenmanagement Inventar-/Kapazitäts- und Kapitalmanagement Monitoring & Reporting 2 Netzwerkmanagement Fehlermanagement Speicheraufteilung (Disk-, Tape-Pooling) Konfigurationsmanagement Performancemanagement 1 Gerätemanagement SAN Hardware Management Ein End to End -Management in der hier aufgezeigten Form gibt es als Softwaretool noch nicht. Jedoch gibt es für alle einzelnen Bereiche separate Module. Die Bemühungen der Softwarehersteller gehen dahin, diese Tools so ineinander zu verzahnen, daß sich daraus ein komplettes Management für alle in einem SAN befindlichen Komponenten ergibt.

9.1 End to End-Management 179 9.1.1 Applikationsmanagement Dieser Level enthält das globale Unternehmensmanagement. Hier sind die Lösungen der kompletten IT-Landschaft des Unternehmens und deren Integration in ein SAN wiederzufinden. Das unternehmensweite Applikations- und Systemmanagement befindet sich an oberster Stelle der Hierarchie und ermöglicht eine umfassende Sicht auf alle Netzwerkressourcen inklusive Fabric, Speichersubsysteme, Server und Applikationen. 9.1.2 Datenmanagement Datenmanagement behandelt im wesentlichen die Qualität und die Sicherheit der Daten. Das beinhaltet die Verfügbarkeit der Daten ebenso wie den Zugriff auf die Daten oder die Performance, mit denen die Daten den Applikationen zur Verfügung gestellt werden sollen. Weitere Themenbereiche des Datenmanagements sind Backup und Restore sowie Archivierung der Daten. Das sogenannte Data Movement, also die Datenmigration auf verschiedene Medien inkl. eines hierarchischen Speichermanagements, ist ebenso in dieser Ebene angesiedelt. Um diesen Punkt zu komplettieren, stellen Funktionen wie die sogenannte Real Time Copy (synchrone Datenspiegelung) oder Point in Time Copy (FlashCopy oder Snapshot) wichtige Bereiche des Datenmanagements dar. 9.1.3 Ressourcenmanagement Das Ressourcenmanagement behandelt wie könnte es anders sein die Ressourcen, die dem SAN zur Verfügung stehen. Wie können die in einem SAN befindlichen Ressourcen effektiv von allen genutzt werden. Typische Themenbereiche sind Disk Pooling Tape Pooling Tape Sharing Space Management Just in Time Storage Basis für solche Forderungen ist z. B. eine Speicherkonsolidierung und ein automatisches Management des vorhandenen Speichers. Die freien Kapazitäten im SAN werden dann der Anwendung bedarfsgerecht zugeordnet. Dies wiederum setzt voraus, daß die kompletten Ressourcen in dem Fabric automatisch gesteuert werden können, idealerweise von einer Konsole aus. In bezug auf Data Sharing stellt diese Schicht Lösungen für ein SAN File System zur Verfügung, welches den verschiedenen Betriebssystemen wie z. B. NT

180 9 SAN-Management oder Unix ermöglicht, auf die gleichen Daten zuzugreifen (True Data Sharing). Solche Lösungen erweitern das Standard File System und sind unentbehrlich z. B. für Backup-Lösungen in heterogenen SANs. 9.1.4 Netzwerkmanagement Die Aufgabe dieser Schicht ist die Steuerung der Links zwischen den Geräten. Darunter fällt z. B. das Zoning, eine Funktion, die noch eingehender in diesem und dem nächsten Kapitel behandelt wird. Weitere Funktionen betreffen die Performance, mit der die Daten durch das SAN geroutet werden können. Das Auffinden von Netzwerkfehlern ist eine ebenso zentrale Aufgabe des Netzwerkmanagements. Dazu ist es notwendig, ein Monitoring über den Datenverkehr im kompletten SAN durchführen zu können. Um den administrativen Aufwand entsprechend klein halten zu können, muß dies von einem zentralen Punkt aus geschehen können. Das Netzwerkmanagement unterscheidet zwischen der physikalischen und der logischen Sicht auf das SAN. Physikalische SAN-Sicht Die physikalische SAN-Sicht identifiziert die installierten SAN-Komponenten. Diese werden in vier Klassen eingeteilt: End-Benutzer/Clients Server Speichergeräte, Speichersubsysteme Netzwerkkomponenten Die Clients sind in der Regel über das LAN an die Server angeschlossen. Es gibt aber auch Ausnahmen, bei denen die Clients direkt z. B. über eine Bridge mit dem SAN verbunden sind und so auch direkt auf Speichersubsysteme zugreifen können. Die Netzwerkkomponenten verbinden in der Regel die Server mit den Speichersubsystemen. Logische SAN-Sicht Die logische SAN-Sicht ist ein Blick auf die Beziehungen zwischen den einzelnen Systemen und Komponenten im SAN. Diese logische Sicht ist nicht von der physikalischen Sicht abhängig und spielt in dem Management eine entscheidende Rolle. Verschiedene Komponenten können so gruppiert und zu einem logischen Entity zusammengefügt werden. Letztlich fußt der größte Teil des Netzwerkmanagements auf der logischen Sicht, denn hierin liegt ja der Vorteil eines SAN. Nicht physikalisch, sondern logisch werden Kapazitäten den Servern zugeordnet, womit diese den Servern physikalisch zur Verfügung stehen.

9.1 End to End-Management 181 9.1.5 Gerätemanagement Diese Managementschicht erlaubt Einstellungen auf den Geräten. Dazu ist es notwendig, daß auf den Komponenten eine Software läuft. Will man z. B. den Port eines Managed Hubs von einer entfernten Konsole aus in den Bypass-Mode setzen (ihn also abschalten), benötigt man ein Managementprotokoll wie etwa SNMP, um die Kommandos von der Konsole zu dem Hub zu befördern (Abbildung 9.1). SNMP Hub Management Agent Microprozessor auf den Komponenten Portkontrolle Portstatus Lüfterstatus Netzteilstatus Abbildung 9.1: Gerätemanagement Ein Agent auf dem Hub setzte das Kommando in eine Instruktion um, damit der Port physikalisch abgeschaltet wird. Die diversen Hersteller der verschiedenen Komponenten in einem SAN bieten jeweils nur proprietäre Software an. Inband Management Die Kommunikation zwischen der Konsole und den Komponenten kann z. B. über das SES-SCSI (SCSI Enclosure Service)-Protokoll realisiert werden. Hier macht man sich zunutze, daß bereits eine physikalische (Fibre Channel)-Verbindung zwischen der Konsole und den Komponenten existiert. Somit wird die Fibre- Channel-Topologie ausgenutzt (darum Inband), um den in unserem Beispiel aufgeführten Hub anzusprechen. Es ist natürlich auch möglich, SNMP-Kommandos über Fibre Channel abzusetzen, jedoch für Inband wird meistens das SES-SCSI- Protokoll verwendet. Der Vorteil dabei ist, daß kein weiteres Netzwerk (LAN)

182 9 SAN-Management benötigt wird. Zudem wird auf diese Weise eine wesentliche Vereinfachung in dem gesamten Management erreicht. Wird z. B. ein Switch angesprochen, kann dieser aufgrund seiner integrierten Möglichkeiten gleichzeitig alle angeschlossenen Server, Subsysteme und Netzwerkkomponenten abfragen und eine detaillierte Auflistung aller Ports in das SAN zurückliefern. Was auf der einen Seite die Stärke des Inband Managements ist, wirkt sich gleichzeitig als größte Schwachstelle aus. Aufgrund der Tatsache, daß die Konsole nicht über ein externes Netz mit den einzelnen Komponenten verbunden ist, ergibt sich die theoretische Möglichkeit, daß ein SAN nicht mehr gesteuert werden kann. Spätestens wenn die Funktionalität des SANs selber, d. h. ein Datentransport in dem Netz nicht mehr möglich ist, kann das SAN nicht mehr gesteuert, kontrolliert und gewartet werden. Das hat zur Folge, daß eine Fehlerbehebung innerhalb des SANs nicht mehr möglich ist, was wiederum eine Downtime der kompletten Infrastruktur zur Folge haben kann. Out of Band Management Um einen solchen Single Point of Failure zu umgehen, wird das Out of Band Management eingesetzt. Dabei werden diese Daten über ein LAN (z. B. TCP/IP) über ein Ethernet zu den jeweiligen Komponenten befördert. Die Kommandos werden über SNMP, Telnet (Commandline Interface) oder HTTP abgesetzt. Neben einem herkömmlichen LAN lassen sich viele Netzwerkkomponenten auch über die serielle Schnittstelle RS232 anschließen. Ein weiterer Vorteil von Out of Band ist, daß sich hier unternehmensweite Managementplattformen einbinden lassen, die ebenfalls SNMP benutzen. Der Nachteil gegenüber dem Inband Management ist, daß hier die Fibre-Channel-Funktionen, die von vornherein automatisch ablaufen, nicht genutzt werden können. 9.2 SAN-Phänomene Ein Storage Area Network verhält sich gänzlich anders als z. B. eine dedizierte SCSI-Verbindung. Daher hier ein kleiner Ausflug zu Dingen, die einem IT- Administrator in einem SAN widerfahren, und wie man sich vor Dateninkonsistenzen oder Datenverlust schützt. Stattet man 100 Server mit Fibre Channel Adaptern aus und schließt diese über eine entsprechende Anzahl von Switches an verschiedenen Festplatten-Subsystemen an, so ergibt sich für den Systemadministrator ein erstaunliches Bild. Alle Systeme sehen alle Festplatten aller Subsysteme. Ein Phänomen, das man bei SCSI in dieser Form nicht kennt und das unter Umständen zu Datenverlusten führen kann. Das nachfolgende Beispiel beschreibt das Problem:

9.2 SAN-Phänomene 183 Nur einmal angenommen, auf dem Subsystem A liegt eine ORACLE-Datenbank für eine SAP R/3-Applikation eines UNIX-Systems. Subsystem B enthält den Plattenplatz des NT Mail-Servers. Wird der NT-Server neu gebootet, führt er auch in einem SAN, d. h. über Fibre Channel eine Art SCSI-Reset aus. Das veranlaßt alle angeschlossenen Subsysteme (und die darin befindlichen logischen Festplatten = LUN = Logical Unit Number), sich mit ihrer zugewiesenen Adresse zu melden, damit der Server die LUNs der Subsysteme richtig ansprechen kann. Da Fibre Channel aber jede Adresse jedes LUNs in dem SAN zurückmeldet, kann der NT-Server dementsprechend auch die Festplatten des UNIX-Systems sehen. Diese UNIX-formatierten Festplatten erkennt NT jedoch nur als unformatierte Festplatten, da NT das UNIX-Format bekanntlich nicht lesen kann. Freundlich, wie das NT-System ist, macht es den Systemadministrator darauf aufmerksam, daß da unformatierte Festplatten im Zugriff sind und ob man diese denn nicht formatieren soll. Da die Plattenkapazität des Mail-Servers gemäß Murphy s Gesetz sowieso am Ende ist, stimmt der Systemadministrator dem Formatieren zu, und damit ist die ORACLE-Datenbank verloren und die SAP R/3-Anwendung crashed. Noch ein Phänomen ist in einem SAN zu beobachten und sollte bei der Einrichtung Berücksichtigung finden. Besitzt ein Server z. B. drei Fibre Channel Adapter und werden alle drei Adapter zum Anschluß an einen Switch genutzt, der wiederum über vier Fibre-Channel-Kanäle mit dem Subsystem verbunden ist, ergeben sich für Server und Subsystem zwölf verschiedene Pfade, um miteinander zu kommunizieren. In diesem Beispiel kann der Server alle LUNs über alle Pfade sehen und gleichzeitig über die verschiedenen Pfade darauf zugreifen. Ohne spezielle Software betrachtet der Server ein LUN jedoch über jeden Pfad separat, in dem Beispiel also als zwölf verschiedene LUNs. Dies kann zu Dateninkonsistenz führen. Zudem muß hier darauf geachtet werden, daß die Anzahl der Pfade die größtmögliche Anzahl an Pfaden, die das Subsystem verwalten kann, nicht überschreitet. Um die Sicherheit in einem SAN zu garantieren und letztendlich die geschilderten Tücken auszuschalten, gibt es im wesentlichen drei verschiedene Vorgehensweisen, die sich aus den logischen Schichten eines SANs ergeben. Entweder sorgt das Subsystem für die Datensicherheit, oder diese Aufgabe wird von der Netzinfrastruktur (Switch) bzw. als dritte Alternative von den Servern übernommen. Ist das Subsystem für die Datensicherheit verantwortlich, nutzt der Administrator Tools, die von einem RAID-System zur Verfügung gestellt werden, um das RAID-System zu konfigurieren. Ist es korrekt eingerichtet, bestimmt das RAID- System, welcher Host auf welches LUN zugreifen darf. Das Verfahren nennt sich RAID-based Mapping und hat den Vorteil eines zentralen Managements. Dieser Vorteil ist aber schon wieder hinfällig, wenn aus Kapazitätsgründen mehrere verschiedene RAID-Systeme eingesetzt werden müssen. Ist der Switch für Datenintegrität verantwortlich, spricht man von Fabric Zoning. Dabei gibt es zwei verschiedene Arten des Zonings, auf die in Abschnitt 9.3 gesondert eingegangen wird.

184 9 SAN-Management Letztlich gibt es das Host-based Mapping, wobei der Server hier für die Konsistenz der Daten verantwortlich zeichnet. Treiber des Fibre Channel Adapters wei- sen einer SCSI-ID die physikalischen Devices und die LUNs zu. Spezielle Software verhindert dabei einen Zugriff anderer Systeme auf das Device bzw. die LUNs. Diese Mapping-Verfahren setzen jedoch ein unintelligentes Subsystem voraus. Unintelligent bedeutet, daß ein Subsystem über keine eigene Logik in Form eines vorgeschalteten Rechners oder Controllers verfügt, der die Daten innerhalb des Subsystems steuert und verwaltet. 9.2.1 LUN-Affinität Um die Besonderheit von Fibre Channel im Umgang mit LUNs (Logical Unit Number) zu verstehen, soll erst einmal in groben Zügen das Verhalten bzw. die Zuordnung von LUNs bei SCSI erläutert werden. In einer SCSI-Umgebung gehören die LUNs zu einem oder mehreren SCSI-Ports unabhängig davon, welche Hosts an diesem Port angeschlossen sind. Wenn mehrere Hosts an einem SCSI-Port angeschlossen sind (Daisy-Chained), hat jeder der angeschlossenen Hosts Zugriff auf die gleichen LUNs. Anders ausgedrückt bedeutet dies, daß die einzelnen LUNs nur dann bestimmten Hosts zugeordnet werden können, wenn dem Host ein dedizierter SCSI-Port in dem Subsystem zugeordnet ist. Alle anderen LUNs werden verdeckt oder maskiert (darum spricht man auch von LUN-Masking ), so daß auf diese LUNs nicht zugegriffen werden kann. Zusammenfassend läßt sich festhalten, daß ein oder mehrere LUNs einem oder mehreren SCSI-Ports in dem Subsystem zugeordnet werden. Abbildung 9.2 soll dies verdeutlichen. Host 1 Subsystem LUNs Host 2 SCSI-Port 1 Host 3 Host 4 SCSI-Port 2 Host 5 Abbildung 9.2: SCSI-LUN-Masking

9.2 SAN-Phänomene 185 Die Hosts 1 bis 4 haben alle Zugriff auf die oberen LUNs, während die unteren LUNs Host 5 allein zur Verfügung stehen. Werden Hosts über SCSI an ein Subsystem angeschlossen, läßt SCSI jede Kombination aus 16 Initiatoren (Hosts) und Targets zu. Je nach Betriebssystem werden bis zu 8, 32 oder 64 LUNs, pro Target unterstützt. So setzt sich die SCSI ID aus der Kombination von Target und LUN zusammen. Die nachfolgende Tabelle stellt die möglichen SCSI IDs dar. Tabelle 9.2: SCSI IDs Target LUN 1 LUN 2 LUN 3 LUN 4 LUN 5 LUN 6 LUN 7 LUN 8 00 00 01 02 03 04 05 06 07 01 00 01 02 03 04 05 06 07 02 00 01 02 03 04 05 06 07 03 00 01 02 03 04 05 06 07 04 00 01 02 03 04 05 06 07 05 00 01 02 03 04 05 06 07 06 00 01 02 03 04 05 06 07 07 00 01 02 03 04 05 06 07 08 00 01 02 03 04 05 06 07 09 00 01 02 03 04 05 06 07 0a 00 01 02 03 04 05 06 07 0b 00 01 02 03 04 05 06 07 0c 00 01 02 03 04 05 06 07 0d 00 01 02 03 04 05 06 07 0e 00 01 02 03 04 05 06 07 0f 00 01 02 03 04 05 06 07 9.2.2 Fibre Channel-LUNs Im Gegensatz zu SCSI haben Fibre Channel-LUNs eine Zugehörigkeit zu dem Fibre Channel Adapter in dem Host. Diese LUN-Zuweisung erfolgt über den WWPN (World Wide Port Name) des Hosts. Die Infrastruktur zwischen Server und Subsystem ist völlig transparent, d. h. das Fabric mit seinen (unter Umständen mehreren) Switches ist für die Hosts und für das Subsystem nicht zu sehen. Ist das Subsystem in einen Fabric eingebunden, können für einen Zugriff auf die LUNs sofern die Architektur des Subsystems dies zuläßt alle Ports genutzt werden, die mit dem Switch verbunden sind. Anders ausgedrückt: Wenn ein einzelner Host über einen Switch an ein Subsystem angeschlossen wird, kann er mehrere HBA (Host Bus Adapter) in dem Subsystem nutzen, um auf die gleichen LUNs zuzugreifen. Das bedeutet auch, daß mehrere Hosts, die über den gleichen HBA in dem

186 9 SAN-Management Subsystem auf ihre LUNs zugreifen können, dennoch anders als bei SCSI nur ihre eigenen LUNs sehen. Hat letztlich ein Host mehrere Möglichkeiten, über verschiedene Pfade auf eine LUN im Subsystem zuzugreifen, erscheinen dem Host mehrere gleiche LUNs, die er über die einzelnen Pfade erkennt. Ohne zusätzliche Software kann der Host nicht unterscheiden, ob diese gleichen LUNs die- selben sind, doch über verschiedene Pfade erreicht wurden. Fibre Channel kann gemäß Standard bis zu 264 LUNs pro Adapter verwalten. Diese Größe wird jedoch von den Betriebssystemen zur Zeit nicht verwaltet. Sie können bis zu 256 LUNs pro Adapter verwalten. Host 1 Host 2 Subsystem FC-Port 1 LUNs Host 3 Switch Klasse "A" Klasse "C" Host 4 FC-Port 2 Host 5 Klasse "B" Abbildung 9.3: Fibre Channel LUNs LUNs, auf die ein Hosts zugreifen kann, werden als Klasse bezeichnet. In der Graphik wird die Klasse A, bestehend aus vier LUNs, dem Host 2 zugeordnet. Auf die Klasse C können die Hosts 1, 4 und 5 zugreifen. Dabei besteht die Klasse C aus zwei LUNs der Klasse A und zwei LUNs der Klasse B. LUNs können also mehreren Hosts gleichzeitig zugeordnet werden. Zudem greifen alle Hosts in Abbildung 9.3 über zwei verschiedene Pfade (über FC-Port 1 und FC-Port 2) auf die LUNs zu. Das heißt: Ist die Architektur des Subsystems in der Lage, andere Pfade zum gleichen LUN zur Verfügung zu stellen, werden diese von dem Host erkannt und auch genutzt. Das Erkennen der verschiedenen Pfade einerseits und das Bestimmen, ob es sich bei dem LUN um ein und denselben handelt, setzt jedoch wie bereits mehrfach erwähnt eine besondere Multipathing Software voraus. Wird diese Software nicht eingesetzt, erkennt der Server über die unterschiedlichen Pfade jeweils eine LUN, die obwohl es sich real nur um eine LUN handelt nichts miteinander gemein haben. Zugriffe über verschiedene Pfade führen dann unter Umständen zu Dateninkonsistenz.

9.3 Zoning 187 9.3 Zoning Zoning ist ein Management-Instrument für ein SAN. Diese Management- Funktionen können nur in einem Fabric vorgenommen werden. Der Grund dafür ist die mangelnde Intelligenz und die physikalische Struktur einer Fibre Channel Arbitrated Loop. Zoning teilt wie der Name schon sagt das Fabric in Zonen oder Bereiche auf. So kann man wie in Abbildung 9.4 dargestellt z. B. Bereiche für die NT- und UNIX-Welten schaffen. Test-, Entwicklungs-, Integrationsund Konsolidierungssysteme lassen sich obwohl sie die gleiche Infrastruktur nutzen und auf dem gleichen Betriebssystem laufen auf diese Art von der Produktionsumgebung abgrenzen. Sollte der nächste I Love You -Virus mal wieder die Firewall überwunden haben, läßt sich das Desaster je nach Einstellung des SANs auf nur wenige Server begrenzen. NT NT NT-Zone SUN Solaris SUN Solaris NT Switch 1 Switch 2 UNIX-Zone 2 Daten- Daten- SUN Solaris bank bank Switch 3 Switch 4 UNIX-Zone 1 Daten- Daten- bank bank IBM AIX IBM AIX IBM AIX IBM AIX Abbildung 9.4: Zoning Sinn und Zweck dieser Einteilerei ist es, komplexe SANs übersichtlich und einfach zu gestalten. Zudem können so unternehmenskritischen Anwendungen ent- sprechende Performance-Garantien zugesichert werden, und dem Thema Sicherheit kommt man mit dem Zoning in besonderem Maße nach. Das Zoning ist eine Art Daten-Verkehrsleitsystem, erlaubt also eine feinere Segmentierung des SANs. Genauer betrachtet, werden mehrere sendende Ports (Server) fest mit mehreren empfangenden Ports (Subsystemen) logisch oder physikalisch verbunden. Alle Mitglieder einer Gruppe oder eines Bereichs (z. B. innerhalb der UNIX Zone 1) können beliebig miteinander kommunizieren. Alle anderen Teilnehmer des SANs bleiben außen vor, bekommen von der Kommunikation nichts mit. Es ist auch möglich, daß einzelne Mitglieder zwei oder mehreren Grup-

188 9 SAN-Management pen zugeordnet sind. Heterogene Speicher-Subsysteme z. B. findet man häufig in den Schnittstellen mehrerer Zonen. Das wiederum bringt den Vorteil mit sich, daß sich solche Subsysteme, da mehreren Abteilungen oder Kostenstellen zugeordnet, wesentlich schneller amortisieren können. Zoning ist die Möglichkeit eines sehr effektiven Managements des Fabrics. Der Switch ist für die Verwaltung, Steuerung und das Handling zuständig. Dazu ist der Switch mit einer besonderen Software ausgerüstet. Betreibt man Switches eines Herstellers (oder besser: Anbieters), hat man zudem den Vorteil, daß sich alle Switches des gesamten Fabrics von einem zentralen Punkt aus managen lassen. Das verringert den administrativen Aufwand. Die Software-Tools der unterschiedlichen Anbieter sind selbstverständlich mit unterschiedlichen Funktionen sowie unterschiedlich komfortabel ausgestattet, so daß dies den Einsatz von Switches verschiedener Anbieter fast ausschließt, auch wenn diese in einem SAN technisch zu betreiben wären. Zudem besteht hinsichtlich nur eines Anbieters die Gewißheit, daß beide Arten des Zonings (logisch und physikalisch) umsetzbar sind. Dies sind auch die einzigen Punkte, die für einen Fabric-Aufbau mit Systemkomponenten nur eines Anbieters sprechen. Es gibt wie gesagt zwei Formen des Zonings: Hardware Zoning (physikalisches Zoning) Software Zoning (logisches Zoning) 9.3.1 Hardware Zoning Eine Möglichkeit, das SAN in verschiedene Bereiche einzuteilen, wird über Hardwareeinstellungen erreicht. Hardware Zoning basiert auf der physikalischen Port ID des Switches. Dabei können drei Varianten eingestellt werden: 1. One to One 2. One to Many 3. Many to Many One to One bedeutet, daß ein Port in dem Switch (z. B. Port 3) mit einem anderen Port (z. B. Port 7) verbunden wird. Alle Frames, die an Port 3 ankommen, können nur nach Port 7 weitergeleitet werden und umgekehrt. Dazu wird in dem Crossbar Switch der entsprechende Switchpoint 3/7 aktiviert, und alle anderen Switchpoints werden ausgeschaltet, so daß sie gar nicht aktivierbar sind. One to Many hat zur Folge, daß Port 3 die ankommenden Frames an mehrere andere Ports (z. B. Ports 6, 7 und 8) weiterleiten kann. Umgekehrt müssen sich die Ports 6, 7 und 8 die Bandbreite von Port 3 teilen, so daß sie effektiv nur noch 33,3 MB/sec zur Verfügung haben. Real steht den einzelnen Ports sehr wohl eine Bandbreite von 100 MB/sec für die Datenübertragung zur Verfügung. Ist Port 3

9.3 Zoning 189 jedoch durch die Class-1 -Kommunikation mit Port 7 belegt, muß Port 6 so lange warten, bis 3 wieder verfügbar ist. In einer solchen Umgebung zahlt es sich dann aus, wenn der Switch in der Lage ist, möglichst viele Frames zwischenzuspeichern. In einer Class-2 -Verbindung ist es hingegen Port 3 möglich, mit den Ports 6 und 7 gleichzeitig zu kommunizieren. Many to Many ist somit selbsterklärend. In dem Beispiel könnten nur die Ports 1 und 3 ihre Frames an die Ports 6, 7, und 8 bzw. umgekehrt weiterleiten. Es ist auf diese Art möglich, mehrere unterschiedliche Bereiche zu kreieren. Jeder Port in einem Fabric läßt sich anhand einer Nummer bestimmen. Diese Nummer setzt sich aus der Switch-Nummer (Domain ID) und der Port-Nummer auf den Switch zusammen. Eine solche Nummer könnte 2/12 lauten und beschreibt damit Port Nummer 12 des Switches 2. An dem Switch wird nun eingestellt, welche (eingehenden) Ports mit welchen (ausgehenden) Ports kommunizieren dürfen. So könnte eine Definition des 16-Port-Switches Nr. 2 festlegen, daß Port 2/3, 2/6, 2/7, 2/8 und 2/12 innerhalb eines Bereiches sind. Ist an dem Port 2/12 z. B. ein Festplattenturm angeschlossen, wäre das eine One to Many -Variante, denn nur die Geräte an den Ports 3, 6, 7 und 8 haben Zugriff auf die Daten dieser Festplatten. Da die Switchpoints beim Hardware Zoning ausgeschaltet werden der Switch demnach keine Möglichkeit mehr besitzt, die Frames versehentlich an einen falschen Port als den zugeteilten weiterzuleiten, ist diese Methode die sicherste und die restriktivste Variante des Zonings. Der Nachteil des Hardware Zonings ist, daß diese restriktive Art der Einschränkung in großen und komplexen Fabrics nicht mehr zu handhaben ist. Ein Beispiel: Server A ist über Switch 2 Port 3 mit dem Subsystem B (an Port 7 des Switches angeschlossen) verbunden, das Hardware Zoning ist eingerichtet. Um die Ausfallsicherheit einer Applikation zu erhöhen, soll Server A in einen anderen Brandabschnitt verlegt werden. Dazu wird der Server von Port 3 des Switches 2 abgezogen und in dem anderen Brandabschnitt an Switch 1 Port 4 angeschlossen. Die beiden Switches wiederum sind jeweils über ihren Port 9 miteinander verbunden. Somit ist zwar eine physikalische Verbindung zwischen Server A (Port 1/4; 1/9; 2;9, 2/7) bis zum Subsystem B gegeben, ein Zugriff auf die Platten des Subsystems wäre dennoch nicht möglich, da das Hardware Zoning nur alle Systeme von Port 2/3 auf das Subsystem zugreifen läßt. Um diese Kommunikation zwischen Server A und Subsystem B wiederherzustellen, muß das Hardware Zoning bei beiden Switches neu aufgesetzt werden. Die wesentliche Funktion der Flexibilität innerhalb eines SANs ist damit nicht mehr gegeben. Ein anderes Beispiel soll die relative Einschränkung des SANs durch das Hardware Zoning fundamentieren. In einem kleinen SAN sind über einen 16-Port-Switch insgesamt 11 Server mit 5 Subsystemen verbunden. Somit sind alle Ports des Switches belegt. Für ein Business-Warehouse-Projekt sollen drei weitere Server und eine Tape Library in das SAN integriert werden. Dazu wird ein zusätzlicher Switch benötigt. Zudem sollen in dem Projekt zwei der bestehenden Server ebenfalls auf

190 9 SAN-Management die neue Tape Library zurückgreifen können. Um dies zu ermöglichen, muß das komplette Hardware Zoning reorganisiert werden, was zur Folge hat, daß für diese Zeit aus sicherheitstechnischen Gründen alle Anwendungen nicht auf die Systeme zugreifen sollten. Neben den administrativen Aufwendungen kommen dann noch Kosten für Systemausfall hinzu. 9.3.2 Software Zoning In Unternehmen mit vielen Servern, Subsystemen und entsprechend komplexen SAN-Strukturen birgt das Hardware Zoning aufgrund seiner enormen Sicherheit zwar Vorteile, wird jedoch wegen der mangelnden Flexibilität und des damit verbundenen administrativen Mehraufwands kaum Anwendung finden. Das Software Zoning verhält sich grundlegend anders als das Hardware Zoning, erzielt aber dennoch die gleiche Wirkung. Ein großer Vorteil des Software Zonings ist, daß man relative Zonen schafft und nicht absolute wie beim Hardware Zoning. Relative Bereiche behalten auch dann ihre Wirkung, wenn man die Struktur des SANs verändert (siehe Beispiel). Software Zoning wird mit dem Simple Name Server implementiert und läuft auf dem Switch. An einzelne Zonen können Namen wie NT-, Unix-, Test- oder z. B. Konsolidierungszone vergeben werden. Ausgangsbasis ist dabei der WWN (World Wide Name) des Knotens bzw. des Ports. Die Zoning Software in dem Switch erlaubt die Zuweisung von symbolischen Namen für die einzelnen Zonen und die einzelnen Mitglieder der verschiedenen Zonen. Dabei können einzelne Mitglieder durchaus verschiedenen Zonen angehören. Der World Wide Name des Knotens (sowie auch des Ports) wird durch eine 8 Byte (64 Bit) lange Adresse als hexadezimale Zahl dargestellt, die in Kolonnen (z. B. 10:00:06:60:7b:00:00:8a) aufgeteilt wird. Wird eine Zone kreiert, die nur aus dem WWN des Knotens besteht, werden alle dazugehörigen Ports auf diesem Knoten automatisch dieser Zone zugeordnet. Wird hingegen der WWPN zur Definition der Zone herangezogen, ist nur der Port Mitglied der Zone. So ist es denkbar, daß einem Knoten mit sechs verschiedenen Ports jedem einzelnen Port eine separate Zone zugeordnet wird. Es lassen sich für die gleichen Teilnehmer mehrere Zonen gleichzeitig kreieren bzw. konfigurieren. Jedoch kann immer nur eine der Konfigurationen aktiv sein. Ein Wechsel zwischen den unterschiedlichen Zonen kann ohne Downtime geschehen. Das Beispiel aus dem Hardware Zoning wurde mit Software Zoning wie folgt ablaufen: Server A mit dem WWPN 10:00:06:60:7b:00:00:8a ist über Switch 2 Port 3 mit dem Subsystem B (WWPN 10:00:06:67:41:00:09:fa an Port 7 des Switches 2 angeschlossen) verbunden. Beide Systeme sind Mitglieder derselben Zone Produktion. Um die Ausfallsicherheit einer Applikation zu erhöhen, soll Server A in einen anderen Brandabschnitt verlegt werden. Dazu wird der Server von Port 3 des Switches 2 abgezogen und im anderen Brandabschnitt an Switch 1 Port 4 angeschlossen. Die beiden Switches sind ihrerseits jeweils über

9.4 Automatisches SAN-Management 191 Port 9 miteinander verbunden. Somit ist eine physikalische Verbindung zwischen dem Server A (Port 1/4; 1/9; 2;9, 2/7) und dem Subsystem B gegeben, und die Teilnehmer der Zone können weiterhin miteinander kommunizieren. Es ist keine Neukonfiguration der Zone notwendig. Auch ein Software Zoning mit fest definierten Ports ist möglich. Das ergibt vor allem dann einen Sinn, wenn gezielt Mitglieder des Fabric und Mitglieder einer Public-Loop angesprochen werden sollen. Aus der Praxis: Es gibt zwei Punkte beim Zoning, auf die zu achten ist: 1. Das aufgeführte Beispiel ist reine Theorie und funktioniert nur aus Sicht der Switches. In der Praxis sollte niemand versuchen, einem Server die Pfade wegzuziehen, um die Kabel an einem Switch wieder aufzustecken. Auf die dadurch entstehende Problematik gehe ich in Kapitel 10 näher ein. 2. Einige Adapter puffern die WWPNs zwischen. Dies hat zur Folge, dass die Adapter auch dann noch mit dem Subsystem reden können, wenn man es ihnen via Software Zoning verboten hat. Voraussetzung ist natürlich, dass der Sever einmal ohne Zoning mit dem Subsystem kommuniziert haben muß. D. h. kennt der Adapter die WWPN der Gegenstelle, kann er nach wie vor Daten dahin übertragen, denn das Software Zoning unterbindet lediglich die Anfragen der Server, z. B. ob die Adresse XYZ im SAN verfügbar ist. Darf der Server aufgrund der Zoningeinstellung nicht mit dieser Adresse kommunizieren, ist es also notwendig, dem Adapter diese Informationen entweder durch einen Reboot bei Windows-Servern oder durch ein remove device bei UNIX-Servern wieder zu entziehen. Neuerdings hat Brocade dem Unterwandern des Zonings durch das Zwischenpufferrn der WWPNs einen Riegel vorgeschoben, indem der Switch den Header in dem Frame ausliest. Anhand der Destination ID und der Source ID kann der Switch erkennen, welcher Server Daten an welches Subsystem senden will. Existiert dafür keine passende Regel in dem Zoning, werden die Frames gedroppt. 9.4 Automatisches SAN-Management Ein SAN nimmt dem Administrator wesentliche Management-Aufgaben ab. Einige dieser Management-Funktionen wurden schon eingehender in den vorangegangenen Kapiteln erläutert. Hier sollen nochmals die automatischen Management-Funktionen und ihre Auswirkungen bzw. ihr Nutzen im Überblick erläutert werden. Alle automatischen Funktionen basieren im wesentlichen auf

192 9 SAN-Management zwei Funktionen. Das ist zum einen der Login-Prozeß, begründet in dem Fibre Channel-Protokoll, und zum anderen der Simple Name Server, der von einem Switch zur Verfügung gestellt wird. Mit diesen beiden Grundfunktionen können weitere Funktionen abgebildet werden, wie z. B.: Automatisches Entdecken neuer Ports (Automatic Port Discovery); Automatisches Entdecken neuer Adressen (FC-AL)(Automatic Address Discovery); Automatische Pfad-Auswahl (Dynamic Path Selection); Gleichmäßige Lastverteilung (Load Balancing); Automatisches Umschalten im Fehlerfall (Automatic Path Failover). 9.4.1 Automatisches Entdecken neuer Ports Wird ein Server eingeschaltet, versucht der Fibre Channel Host Bus Adapter, in dem Server sofort einen Login-Prozeß durchzuführen. Dazu überträgt der Adapter seine Daten an eine fest definierte Adresse in dem Switch. Zudem trägt er in dem Header an Stelle seiner 24-Bit-Adresse lauter Nullen ein, so daß die Gegenstelle erkennt, daß es sich dabei um einen neuen Teilnehmer in dem SAN handelt. Der Switch wiederum trägt alle wichtigen Daten in die Matrix des Simple Name Servers ein, vergibt eine neue 24-Bit-Port ID und leitet diese Daten automatisch an alle anderen angeschlossenen Switches in dem Fabric weiter. Zwei Dinge sind geschehen: Da der Port jetzt eine Port ID besitzt, kann er mit jedem anderen Port im Fabric kommunizieren. Und die Port ID so wie alle dazugehörigen Daten wie z. B. WWN und WWPN ist allen Switches im Fabric bekannt. Ein Beispiel: Wie bei dem Zoning erläutert, soll Server A (WWPN 10:00:06:60:7b:00:00:8a) in einen anderen Brandabschnitt verlegt werden. Die 24-Bit-Adresse des Ports ist 001/002/000. Im dem anderen Brandabschnitt wird der Server an Switch 1 Port 4 angeschlossen. Beide Switches wiederum sind jeweils über ihren Port 9 miteinander verbunden. Der Server wird an seinem neuen Standort eingeschaltet, und der Host Bus Adapter startet sofort seinen Login-Prozeß. An seine alte Port ID kann sich der Adapter nicht mehr erinnern, da er ausgeschaltet wurde und keinen batteriegepufferten Speicher für solche Informationen besitzt. Folglich sendet der Adapter an Switch 1 seinen WWPN (10:00: 06:60:7b:00:00:8a) und die Port ID 000/000/000. Der DNS erkennt anhand der WWPN, daß dieser einen Eintrag für die Port ID 001/002/000 besitzt. Da sowohl der WWPN als auch die Port ID einzigartig sind, kann somit ausgeschlossen werden, daß es sich um einen anderen Server handelt. Zudem wurde Switch 1 bereits darüber informiert, daß der Server mit der Port ID 001/002/000 nicht mehr erreichbar ist (State Change Notification). Dem Port wird jetzt die neue Port ID 000/003/000 zugewiesen. Zudem werden die Daten des DNS wiederum an alle Switches im Fabric übertragen, so

9.4 Automatisches SAN-Management 193 daß auch Switch 2 erkennt, daß der ehemals an Port 3 befindliche Teilnehmer jetzt über Switch 1 erreicht werden kann. Würde man Server A in dem Beispiel nicht vom Strom trennen müssen, da er z. B. nur aus Performance-Gründen von Switch 2 an Switch 1 umgesteckt wird, würde der Port des Servers A ein Login mit seiner alten Port ID durchführen. Auch in diesem Fall erkennt Switch 1, daß Server A zuvor mit an Switch 2 angeschlossen war und nimmt die gleichen Änderungen wie oben vor. 9.4.2 Automatisches Entdecken neuer Adressen Der Unterschied im Entdecken neuer Ports und dem neuer Adressen liegt im Protokoll begründet. Fibre Channel Arbitrated Loop entdeckt neue Adressen, Fibre Channel Protokoll neue Ports. Beides ist im Grunde jedoch das Gleiche. Wird Server A in einer Fibre Channel Arbitrated Loop neu gestartet, gibt der Adapter sofort ein LIP(F7,F7) aus. Der Loop-Initialisierungsprozeß unterbricht jede andere Kommunikation, und den Teilnehmern der Loop wird eine neue Adresse zugewiesen. 9.4.3 Automatische Pfad-Auswahl Die automatische Pfadauswahl (Abbildung 9.5) wird über den DNS generiert. Server Port 004 Switch 1 Domain 000 Port 003 Pfad 2 Switch 3 Domain 002 Pfad 5 Port 003 Port 001 Port 002 Port 002 Port 001 Pfad 1 Pfad 4 Pfad 5 Pfad 3 Pfad 4 Pfad 4 Pfad 2 Pfad 4 Pfad 1 Pfad 5 Switch 2 Port 001 Port Domain 001 002 Port 003 Port 002 Pfad 5 Port 001 Pfad 3 Port 003 Switch 4 Port 007 Domain 003 Subsystem Abbildung 9.5: Automatische Pfadauswahl

194 9 SAN-Management Der Distributed Name Server besitzt alle Informationen, an welchem Port welchen Switches welche Port ID zu finden ist. Anhand dieser Einträge lassen sich alle Pfade zum einzelnen Port definieren. Je nach Classes of Service (z. B. Class-2) ist zudem ein Wechseln zwischen den verschiedenen Pfaden möglich. Für Switch 1 ergeben sich fünf Pfade, auf denen er Switch 4 erreichen kann. Alle fünf möglichen Pfade sind in dem jeweiligen DNS aller Switches verzeichnet. Die Einträge in dem Distributed Name Server sind in Tabelle 9.3 dargestellt. Tabelle 9.3: DNS-Tabelle Switch Domain Port angeschl. Port ID 1 000 001 001/001/000 1 000 002 003/002/000 1 000 003 002/001/000 1 000 004 000/004/000 2 001 001 000/001/000 2 001 002 002/002/000 2 001 003 003/001/000 3 002 001 000/003/000 3 002 002 001/002/000 3 002 003 003/003/000 4 003 001 001/003/000 4 003 002 000/002/000 4 003 003 002/003/000 4 003 007 003/007/000 Fakt ist, daß das Subsystem mit der Port ID 003/007/000 nur über die Domain 003, d. h. Switch 4, erreicht werden kann. Switch 4 wiederum ist aus Sicht von Switch 1 über verschiedene Pfade nämlich direkt oder über Switch 2 bzw. Switch 3 zu erreichen. Diese Vorgehensweise ist relativ komplex, schützt aber gleichzeitig vor einem ungewollten Ausfall durch die Infrastruktur. In diesem kleinen Beispiel mußten beide verbleibenden Switches (2, 3) und zusätzlich ein Link (Pfad 1) zeitgleich ausfallen, damit Switch 1 nicht mehr mit Switch 4 kommunizieren kann. Die Unwahrscheinlichkeit dieser Tatsache macht das System entsprechend sicher. 9.4.4 Lastverteilung Der DNS sorgt für eine gleichmäßige Lastverteilung innerhalb des Fabrics. Das bedeutet bezogen auf Abbildung 9.5 nicht zwangsläufig, daß die einzelnen Frames einmal über Switch 2, dann über Switch 3 und anschließend direkt an Switch

9.4 Automatisches SAN-Management 195 4übertragen werden, obwohl dies theoretisch möglich wäre. Vielmehr wird versucht, die einzelnen Frames auf dem schnellsten Weg zum Empfänger zu bringen. Ist der direkte Link blockiert bzw. defekt ein Umweg über die Switches 2 bzw. 3 somit notwendig, wird der Switch mit der höchsten Prioritat, die zum richtigen Empfänger führt, genutzt (in dem Beispiel Switch 2). Ist dieser Switch jedoch in der Weiterleitung der Frames dahingehend eingeschränkt, daß die benötigten Ports durch anderen Datenverkehr blockiert sind (denkbar hierfür wäre z. B., daß ein an Switch 2 angeschlossener Server auf ein weiteres, an Switch 4 angeschlossenes Subsystem zugreift), werden die Frames automatisch über Switch 3 geroutet. Das hat zur Folge, daß das Fabric relativ gleichmäßig ausgelastet wird, sofern nicht Zoning-Einschränkungen dem entgegenstehen. Dieses Vorgehen funktioniert theoretisch auch in einer Class-1-Verbindung, hier jedoch nur während des Aufbaus der Verbindung. Ist der Link erst einmal etabliert, wird die Bandbreite ohnehin garantiert, und die benutzten Ports stehen anderen Teilnehmern für die Datenübertragung nicht mehr zur Verfügung. 9.4.5 Automatisches Umschalten im Fehlerfall Die Funktion FSPF erstellt eine Routing-Tabelle, aus der alle möglichen Pfade in direkter Abhängigkeit ermittelt werden. Fällt nun ein Pfad aus, werden die Frames über einen der verbleibenden Pfade übertragen. Um dies zu ermöglichen, muß der jeweilige Port erkennen können, daß seine Verbindung nicht mehr besteht. Die Fibre Channel Level 0 und 1 stellen die hierfür notwendigen Strukturen zur Verfügung. Jeder Port besitzt einen Schwellendetektor, welcher ermit- telt, ob der Port ein gültiges Signal empfängt (FC-0). Selbst wenn keine Daten in dem Fabric übertragen werden, sendet und empfängt jeder Port Fill Words, um eine Synchronisation der einzelnen Teilnehmer zu ermöglichen (FC-1). Erkennt nun der Port eines Switches, daß eine bestehende Verbindung zu einem Server unterbrochen wurde der Port empfängt kein gültiges Signal, also auch keine Fill Words mehr, wird dieser Zustand des Ports in dem SNS des Switches eingetragen. Der Distributed Name Server sorgt dafür, daß alle Simple Name Server in einem Fabric die gleichen Informationen besitzen. Fällt in unserem Beispiel (Abbildung 9.5) der Port 003/002/000 an Switch 4 oder die Verbindung dorthin aus, erhalten alle Switches in dem Fabric davon Kenntnis. Das ist notwendig, da sich diese Information auch auf die Lastverteilung und andere Eigenschaften von Fibre Channel auswirkt. Solche Eigenschaften und Funktionen sind z. B. Data Striping oder Multipathing, die im Fibre Channel Level 3 eingestellt werden können. Würde aus Unkenntnis darüber, daß besagter Port des Switches 4 ausgefallen ist, versucht, eine Verbindung zu Switch 4 aufzubauen, um hierüber Daten von Switch 1 weiterleiten zu können, wird Zeit vergeudet und unnötiger Datenverkehr in dem Fabric generiert.