Wolfgang Sollbach
Storage Area Networks Hohe Datenverfügbarkeit durch Speichernetzwerke
An imprint of Pearson Education München • Boston • San Francisco • Harlow, England Don Mills, Ontario • Sydney • Mexico City Madrid • Amsterdam
Die Deutsche Bibliothek - CIP-Einheitsaufnahme Ein Titeldatensatz für diese Publikation ist bei Der Deutschen Bibliothek erhältlich.
Die Informationen in diesem Produkt werden ohne Rücksicht auf einen eventuellen Patentschutz veröffentlicht. Warennamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt. Bei der Zusammenstellung von Texten und Abbildungen wurde mit größter Sorgfalt vorgegangen. Trotzdem können Fehler nicht vollständig ausgeschlossen werden. Verlag, Herausgeber und Autoren können für fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Für Verbesserungsvorschläge und Hinweise auf Fehler sind Verlag und Herausgeber dankbar. Alle Rechte vorbehalten, auch die der fotomechanischen Wiedergabe und der Speicherung in elektronischen Medien. Die gewerbliche Nutzung der in diesem Produkt gezeigten Modelle und Arbeiten ist nicht zulässig. Fast alle Hardware- und Softwarebezeichnungen, die in diesem Buch erwähnt werden, sind gleichzeitig auch eingetragene Warenzeichen oder sollten als solche betrachtet werden. Umwelthinweis: Dieses Buch wurde auf chlorfrei gebleichtem Papier gedruckt. Die Einschrumpffolie zum Schutz vor Verschmutzung ist aus umweltfreundlichem und recyclingfähigem PE-Material. Copyright ©2002
10 9 8 7 6 5 4 3 2 1 04 03 02 01 ISBN 3-8273-1871-8 © 2002 by Addison-Wesley Verlag, ein Imprint der Pearson Education Deutschland GmbH, Martin-Kollar-Straße 1012, D-81829 München/Germany Alle Rechte vorbehalten Einbandgestaltung: atelier für gestaltung, niesner & huber, Wuppertal Lektorat: Rolf Pakendorf,
[email protected] Korrektorat: Brigitta Keul, München Herstellung: Anna Plenk,
[email protected] Satz: reemers publishing services gmbh, Krefeld, www.reemers.de Druck und Verarbeitung: Freiburger Graphische Betriebe, Freiburg Printed in Germany
Für Petra
Inhaltsverzeichnis 1
2
Vorwort
13
Der Weg zu SAN und NAS
17
1.1 Hochverfügbarkeit
18
1.1.1
Host-Komponenten
18
1.1.2
Komponenten des I/O-Subsystems
21
1.2 Storage Area Networks
22
1.3 Network Attached Storage
24
SAN – Grundlegende Basis-Technologien
27
2.1 Anschluss von Storage Devices über das SCSI-Protokoll
27
2.1.1
Device-Administration unter Solaris 2.x
2.2 Einführung in Netzwerk-Technologien 2.2.1
Standardisierungskomitees
52
2.2.2
Netzwerk-Kommunikation
52
2.2.3
Das ISO/OSI-Referenz-Modell
54
2.2.4
Das Internet-Protokoll
67
2.2.5
Das Network File System – NFS
2.3 Einführung in die Fibre Channel-Technologie
3
29 52
73 77
2.3.1
Überblick und Anwendung
77
2.3.2
Technologievergleich
84
2.3.3
Fibre Channel-Ebenen
86
2.3.4
Fibre Channel-Serviceklassen und -Topologien
102
SAN Connectivity-Topologien
117
3.1 Die Kapazitätserweiterungs-Topologie
120
3.1.1
Kapazitätserweiterungs-Topologie in Non Fibre Channel-Umgebungen
120
3.1.2
Kapazitätserweiterungs-Topologie in Fibre Channel-Umgebungen
124
3.2 Storage-Konsolidierungs-Topologie 3.2.1 3.2.2
129
Storage-Konsolidierungs-Topologie in Non Fibre Channel-Umgebungen
129
Storage-Konsolidierungs-Topologie in Fibre Channel-Umgebungen
132
7
Inhaltsverzeichnis
3.3 Distanz-Topologie
4
3.3.1
Fibre Channel FC-AL-Distanz-Topologie
3.3.2
FC-SW-Distanz-Topologie
SAN – Hardware-Komponenten
145
4.1 Hochverfügbare Cluster-Systeme
145
4.1.1
Hewlett-Packards MetroCluster ServiceGuard Hardware-Konfiguration
145
4.1.2
Sun Enterprise Cluster-HA
160 161
4.2.1
Basisbausteine
162
4.2.2
Eigenschaften und Komponenten hochverfügbarer Speichersysteme
188
Highend Fibre Channel Storage Arrays
208
4.2.3
211
4.3.1
Fibre Channel-Hubs und Multiplexer
211
4.3.2
Hochverfügbare Fibre Channel-Switches
215
Hochverfügbare NAS-Hardware-Komponenten
253
5.1 Architektur hochverfügbaren NAS
258
5.2 Aufbau und Funktion der Control Station
263
5.3 Aufbau und Funktion eines File-Servers
267
5.4 NAS-Applikationen
270
5.4.1
8
139 141
4.3 Connectivity-Hardware
6
138
3.4 Gemischte Topologien
4.2 Hochverfügbare Speichersysteme
5
137
Windows NT oder Windows 2000Serverkonsolidierung
270
5.4.2
Internet als NAS-Applikation
272
5.4.3
NAS-Backup-Applikation
275
5.4.4
Networked Storage als NAS-Applikation
276
Hochverfügbare SAN – Software-Komponenten
277
6.1 Hochverfügbare Cluster-Software
277
6.1.1
Was ist ein Cluster?
277
6.1.2
Cluster-Software-Implementierung unter HP-MC/ ServiceGuard
278
6.1.3
Cluster-Software-Implementierung für Sun mit Veritas Cluster Server (VCS)
313
6.1.4
Bemerkungen zu HP MetroCluster/ServiceGuard und Veritas Cluster Server (VCS)
346
Inhaltsverzeichnis
6.2 Hochverfügbare Software für SAN Storage Arrays 6.2.1
7
Konfiguration der Storage Devices
347 350
6.2.2
Software Business Continuity-Komponenten
383
6.2.3
Software Disaster Recovery-Komponenten
399
6.2.4
Status-Meldungen von SymCLI-Kommandos
408
SAN und NAS – Unterstützte File-Systeme
413
7.1 Disk/Device-Verwaltung unter MS Windows NT
413
7.1.1 7.1.2
Grundbegriffe für die Disk-Administration: Partitions
413
Grundbegriffe für die Disk-Administration: Volume Set und Stripe Set
414
7.2 Dateisysteme unter WIN NT
415
7.2.1
Die Symmetrix Manager Control Utility
415
7.2.2
Dateisystemvorbereitungen in einer Cluster-Umgebung
418
Dateisystemvorbereitung – Übertragung von Volume Set-Informationen
419
Dateisystem – Vorbereitungen bei einem Single Server
420
Kopieren von Daten mit flexible Mirror oder remote Mirror im 2-Knoten-Cluster
421
Restore von Daten mit flexible Mirror oder Disaster Recovery im 2-Knoten-Cluster
423
Kopieren von Daten mit flexible Mirror oder remote Mirror bei einem Single Server
424
Restore von Daten von flexible Mirror oder remote Mirror bei einem Single Server
426
Probleme beim Softwareeinsatz im NT-Umfeld
426
7.2.3 7.2.4 7.2.5 7.2.6 7.2.7 7.2.8 7.2.9
7.3 Logical Volume-Manager HP-UX
428
7.3.1
Logical Volume-Manager: Übersicht
428
7.3.2
Anlegen einer Volume-Gruppe
430
7.3.3
LVM-Volume-Gruppen Kommandos
431
7.3.4
Weitere Befehle des LVM
433
7.3.5
Backup von LVM-Datenträgern
434
7.3.6
Multipathing unter LVM
435
7.3.7
Striping unter LVM
435
7.3.8
Dateisysteme und flexible/remote mirrors unter HP-UX
437
9
Inhaltsverzeichnis
7.4 Logical Volume-Manager IBM-AIX Logical Volume-Manager: Übersicht
445
7.4.2
Erzeugung einer Volume-Gruppe
445
7.4.3
Erzeugung von Logical Volumes
447
7.4.4
Erzeugung eines Dateisystems
448
7.4.5
Weitere Befehle des LVM
448
7.4.6
Striping im AIX-LVM
449
7.4.7
Dateisysteme und flexible/remote mirrors unter AIX 450
7.4.8
LVM und flexible Mirrors in einer Dual-Server-Umgebung
450
AIX-LVM und Nutzung der flexible Mirrors bei nur einem Server
451
Kopieren von Daten mit flexible oder remote Mirror in einer Dual-Server-Umgebung
452
Restore von Daten mit flexible oder remote Mirror in einer Dual-Server-Umgebung
453
Kopieren von Daten mit flexible/remote Mirror in einer Single-Server-Konfiguration
455
Restore von Daten mit flexible/remote Mirror in einer Single-Server-Konfiguration
457
7.4.9 7.4.10 7.4.11 7.4.12 7.4.13
7.5 Volumes und Dateisysteme unter Sun Solaris
458
7.5.1
Solstice DiskSuite: Überblick
458
7.5.2
Erzeugung eines Concatenated Volume
458
7.5.3
Erzeugung eines Concatenated Volume mit UFS Logging
459
7.5.4
Erzeugung eines Striped Volume
460
7.5.5
Erzeugung eines Striped Volume mit UFS Logging
461
7.5.6
Erzeugung eines Dateisystems
461
7.6 EMC Foundation Suite von Veritas (FS)
462
7.7 Veritas Volume-Manager: Übersicht
462
7.7.1
10
445
7.4.1
Erzeugung einer Disk Group
464
7.7.2
Import/Deport einer Disk Group
464
7.7.3
Erzeugung einer Subdisk
464
7.7.4
Erzeugung eines Plexes
465
7.7.5
Erzeugung eines Volumes
466
7.7.6
Erzeugung eines Dateisystems
467
7.7.7
Veritas Volume-Manager: Übersicht der Kommandos 467
7.7.8
Kommandos für Disk Groups Operationen
468
7.7.9
Kommandos für Disk Operationen
468
Inhaltsverzeichnis
7.7.10
Kommandos für Subdisk Operationen
469
7.7.11
Kommandos für Plex-Operationen
469
7.7.12
Volume-Operationen
470
7.7.13
Dateisysteme und flexible/remote mirrors unter Veritas
470
7.7.14
VxVM und flexible Mirrors in einer Dual-Server-Umgebung
470
7.7.15
VxVM-Dateisysteme und flexible Mirrors in einer Single-Server-Umgebung
474
2
8
7.8 EMC s TimeFinder Toolkit (VRTSvxtf) – TimeFinder-Integration in Veritas Volume-Manager
478
Administration unternehmensweiter Speichernetzwerke
481
8.1 Die Administration von Storage Arrays
482
8.1.1
Einführung in das ECC
8.2 SAN-Monitoring mithilfe des ECC, Resource View und Resource Availability 8.2.1
489
ECC Monitoring Tools
489
8.2.2
Monitoring mit der Resource View
502
8.2.3
Monitoring und Administration der RessourcenVerfügbarkeit – Resource Availability
505
8.3 SAN-Konfiguration und -Steuerung
509
8.3.1
Einschränkung zugreifbarer Devices – Volume Logix
509
8.3.2
Steuerung und Konfiguration von Remote Mirrors – der SRDF-Manager
511
Steuerung und Konfiguration von Flexible Mirrors – der TimeFinder Manager
512
8.3.3
8.4 SAN-Tuning
9
483
513
8.4.1
Dynamisches Pfad-Failover und Multipathing – PowerPath
513
8.4.2
Oracle-Datenbank-Monitoring und Tuning – Der DB-Tuner
514
8.5 SAN-Planung
516
Ausblick
519
Bibliographie
525
Stichwortverzeichnis
531
11
Vorwort
Auf meinem bisherigen 16-jährigen beruflichen Weg habe ich mich als angestellter oder freier Unternehmensberater hauptsächlich der Architektur, dem Design und der Performance der Datenbank-Management-Systeme CA-Ingres, Adaptive Server Enterprise (Sybase), Oracle, Informix und Microsoft SQLServer gewidmet. Wie kommt ein »Datenbankspezialist« auf die Idee, ein Buch über ein Thema zu schreiben, das wie kein zweites hardware- und netzwerkorientiert ist? Ist dies nicht ein Räubern in fremden Gründen? Das ist es nicht. Als Datenbank-Mensch, der sich insbesondere auch um das Laufzeitverhalten »seiner« Datenbankapplikationen bemüht, ist man gezwungen, sich Gedanken über die physikalische Speicherung der Daten, über I/O-Verhalten und Verteilung von Daten über physikalische Devices zu machen. Man ist gezwungen, hochverfügbare Lösungen zu entwickeln, die auf Basis der State-of-The-Art oder Best-of-Breed hochverfügbarer Hardware und Software funktionieren. Daher ist man gezwungen, sich notabene mit den Themen zu beschäftigen, die Inhalt dieses Buches sind. Dieses Buch Storage Area Networks – Hohe Datenverfügbarkeit durch Speichernetzwerke beabsichtigt, die Hardware- und Software-Bausteine der zurzeit aufregendsten Themen in der Informations-Technologie zu beschreiben, SAN und NAS, Storage Area Networks und Network Attached Storage. Das Client-/Server-Computing der 90er Jahre des 20. Jahrhunderts führte – in Verbindung mit dem Wachstum des Internets – zu einer gigantischen Explosion der gespeicherten Datenmenge. In den klassischen Client-/Server-IT-Landschaften führte dies zu erheblichen Problemen hinsichtlich der Verfügbarkeit der benötigten Kapazitäten und – vor allem – bezüglich der Administrierbarkeit der Systeme. Die Notwendigkeit zur Vereinfachung der Administration der Client-/Server-IT-Landschaften führte in den letzten Jahren zur Rezentralisation auf mainframe-ähnliche Open Systems-Serversysteme. Dieser Trend in Kombination mit den Erfordernissen, eine Unmenge von Daten zwischen den Anwendern unterschiedlicher Serversysteme und Server-Applikationen zu teilen, führte zur Implementierung von Storage Area Networks zwischen mehreren Serversystemen und an diese über Fibre Channel angeschlossene Storage Arrays.
13
Das unglaublich gewachsene Interesse am Internet führte zu einem ungeahnten Massenspeicherbedarf der Internetprovider und der Unternehmen im eBusiness, um den Plattenplatzbedarf der Milliarden Internetbenutzer befriedigen zu können. Video on Demand und Storage on Demand sind die Initiatoren von Network Attached Storage, der Anwendern heterogener IT-Umgebungen dieselben Daten über unterschiedliche Dateisysteme und Mount-Mechanismen über das Netz verfügbar macht. SAN und NAS haben sich in jüngster Vergangenheit als die Speicher-Technologie entwickelt, die sämtliche Arten von geschäftskritischen Applikationen nahezu aller Branchen optimal unterstützen. Geschäftskritische Applikationen müssen einem 24 Stunden pro Tag/7 Tage pro Woche hochverfügbaren Betrieb genügen. Daher müssen auch SAN- und NAS-Technologien dem Hochverfügbarkeitsaspekt Rechnung tragen. Dieses Buch schaut hinter die Kulissen der Implementierung von SAN und NAS unter besonderer Berücksichtigung der Hochverfügbarkeit der Lösung. SAN und NAS liefern nicht nur Speicherkapazität, ihr Hauptaugenmerk ist das der Sicherheit. Das erste Kapitel beschreibt die »historische Entwicklung« hin zu SAN und NAS. Es zeigt die Entwicklung von Host- und I/O-Subsystemen für hochverfügbare Systeme auf und beschreibt den Aufbau von Storage Area Networks und Network Attached Storage mithilfe dieser Komponenten. Kapitel zwei beschreibt die grundlegenden Technologien für die Entwicklung von Storage Area Networks. Nach einer Einführung in den Anschluss von Speicher Devices in Open Systems-Umgebungen mithilfe der SCSI-Protokolle (Small Computer Systems Interface) wird eine Einführung in die Grundlagen der Netzwerk-Technologien gegeben, die die Basis für Network Attached Storage-Systeme bildet. Letztendlich wird die Fibre Channel-Technologie dargestellt, die die Infrastruktur der heute gängigen SAN- und NAS-Lösungen liefert. Kapitel drei beschreibt die Connectivity-Topologien in Storage Area Networks. Diese Topologien werden verwendet, um jede denkbare Form eines Storage-Attachments zu implementieren. Die Kapazitätserweiterungs-Topologie beschreibt, wie ein Server durch Anschluss mehrerer Storage Arrays seine Speicherkapazitäten erweitern kann. Die Konsolidierungs-Topologie beschreibt einen Rezentralisierungs-Prozess, in dem mehrere Server ihren Storage auf ein gemeinsam genutztes Storage Array konsolidieren. Die Distanz-Topologie zeigt den Weg zu einer Disaster Recovery-Hochverfügbarkeitslösung auf, die remote gespiegelte Speicherkapazitäten an hochverfügbare Cluster-Server verbindet. In Distanz-Topologien kann jeglicher Single-Point-of-Failure des Gesamtsystems vermieden werden. Kapitel vier ist den wesentlichen Hardware-Komponenten hochverfügbarer SAN-Umgebungen gewidmet. Auf Serverseite werden clustered Server am Beispiel von Hewlett-Packards MetroCluster ServiceGuard und Sun Enterprise Cluster HA und deren Komponenten zum Attachment an Speichersys-
14
teme, die Host-Bus-Adapter, dargestellt. Anschließend widmet sich das Kapitel der Beschreibung hochverfügbarer Storage Arrays. Das Kapitel schließt ab mit der Darstellung von Fibre Channel-Hubs, Multiplexers und Switches. Diese stellen die Connectivity-Hardware eines Fibre Channel-basierten Storage Area Networks dar. Kapitel fünf stellt die Hardware hochverfügbaren Network Attached Storages (NAS) dar. NAS-Systeme bestehen aus den in Kapitel vier dargestellten hochverfügbaren Storage Arrays, die mit entsprechendem ConnectivityEquipment mit File und Media Servern und Control Stations zur Administration des NAS kombiniert werden. Kapitel sechs beschreibt die Software-Komponenten der SAN- und NASUmgebungen. Diese bestehen serverseitig aus Cluster-Server-Software, die anhand der Beispiele von Hewlett-Packards MetroCluster ServiceGuard und Veritas Cluster-Server dargestellt werden. Weiter werden die Softwarekomponenten der Storage-Subsysteme beschrieben, die für die Storage Arrays Business Continuity und Disaster Recovery-Konfigurationen einrichten und administrieren und die ein benutzertransparentes Failover und Failback in Fehlersituationen ermöglichen. Kapitel sieben beschreibt, welche gängigen Dateisysteme in SAN- und NASUmgebungen eingesetzt werden und wie diese die in Kapitel sechs beschriebenen Storage-Softwarekomponenten unterstützen und implementieren. Kapitel acht beschreibt die Software, die wesentlich zum Siegeszug von SAN und NAS beigetragen hat, die Administrations-Software zur Verwaltung unternehmensweiter Speichernetzwerke. Die Kapitel sechs, sieben und acht beschreiben die Softwarekomponenten anhand der Produktpalette des Marktführers in SAN- und NAS-Storage-Technologien – EMC2. Die ausführliche Beschreibung ist auf diese Produkte beschränkt, die vergleichbaren Produkte des Mitbewerbs von EMC2 werden jedoch ebenfalls erwähnt. Kapitel neun beschließt das Buch mit einem Ausblick auf die weitere Entwicklung im SAN- und NAS-Umfeld, wie sie für eine nähere Zukunft voraussehbar ist. Das Buch erhebt nicht den Anspruch auf Vollständigkeit. Die Auswahl der Inhalte entspringt meiner subjektiven Sicht der Dinge. Dennoch denke ich, dass dieses Buch einen Überblick über dieses beeindruckende Thema der derzeitigen IT-Landschaft liefert. Wenn dieser Eindruck auch vom Leser bestätigt wird, dann hat es sich gelohnt, dieses Buch zu schreiben. Im Laufe dieses Buches werden eine Vielzahl von Firmen-, Produkt- und Methodennamen verwendet, deren Eigentümer zu nennen ich mich stets bemüht habe. Sämtliche Produkt-, Firmen- und Methodennamen sind Warenzeichen oder eingetragene Warenzeichen ihrer Eigentümer.
15
Ich möchte dieses Vorwort mit den üblichen Danksagungen abschließen. Ich danke all meinen Kollegen und Freunden, die mich zu diesem Buch ermuntert haben und die Entstehung des Buches aktiv verfolgt haben. Insbesondere möchte ich hier Günter Rühlicke, Joachim Neisius und Ralph Comes nennen, die mir – bewusst oder unbewusst – eine Vielzahl wertvoller Hinweise gegeben haben, die in dieses Buch eingeflossen sind. Die Fehler in diesem Buch sind jedoch meine und nur auf mein beschränktes Verständnis der wertvollen Hinweise und Erläuterungen von Zusammenhängen durch Andere zurückzuführen. Ich danke der EMC2 Computer GmbH, die mir als externem Consultant die Möglichkeit gegeben hat, Projekterfahrung in diesem komplexen Umfeld zu gewinnen, ohne die ich niemals den Mut besessen hätte, dieses Buch auch nur zu beginnen. Ich danke meinem Verleger und hier insbesondere Rolf Pakendorf für die unglaubliche Geduld mit einem Autor, der aufgrund seiner abgeschiedenen Heimstatt im Münsterland – aus Münchner Weltstadtsicht – am Ende der belebten Welt nur selten greifbar war. Ich wünsche ihm besonders viel Erfolg mit diesem Buch – er hat daran beständig gearbeitet. Letztendlich danke ich dem Menschen, der in unzähligen Stunden aus meinen flüchtig hingeworfenen Skizzen Abbildungen machte, die in das Buch eingepflegt werden konnten, und der mich auch bei den Rechercheaufgaben für dieses Buch unermüdlich unterstützt hat, meiner Lebensgefährtin Petra Schmiedle. Sie hat für dieses Buch Entbehrungen und Einschränkungen ihres und unseres gemeinsamen Lebens hinnehmen müssen, die nicht selbstverständlich sind. Coesfeld
16
Wolfgang Sollbach
1
Der Weg zu SAN und NAS
Während die Problematik der Verfügbarmachung großer Speicherkapazitäten im Highend-Host-Umfeld stets gelöst werden musste, ist diese in den Open Systems-Umgebungen, die seit den 80er Jahren die mittlere Datentechnik bestimmen, eine Herausforderung, die sich erst mit dem Wachstum dedizierter Anwendungen und mit der Rezentralisierung von Client-/ServerSystemumgebungen markant bemerkbar macht. Beide Entwicklungstendenzen sind zentrale Themen in der IT-Umgebung der letzten Jahre und der nahen Zukunft. Die schiere Datenmenge, die im heutigen IT-Umfeld bereits eines Mittelstandsunternehmens bewältigt werden muss, ist ein Motor für die Investition in Speichersysteme, die allein diese Datenmenge bewältigen können. Ein weiterer Grund für die Entwicklung hin zu Storage Area Networks (SAN) sind die gesteigerten Anforderungen an die Verfügbarkeit der gespeicherten Daten. Während die Träume der 80er Jahre vom »Netzwerk als System« sich in der Zwischenzeit insofern erfüllt haben, als die technische Entwicklung einen solchen »globalen« Client-/Server-Ansatz ermöglichen würde, hat allein die Problematik der Administration einer verteilten Umgebung bereits zu den im ersten Absatz erwähnten Rezentralisierungstendenzen geführt. Weiter kann heute kaum eine Anwendung noch mit »betriebsarmen Zeiten« operieren, zu denen Wartungsarbeiten, Datensicherungen etc. durchgeführt werden können. Letztlich führt die Globalisierung dazu, dass heute sieben Tage pro Woche und 24 Stunden pro Tag auf die Daten zugegriffen werden muss. Ausfallzeiten aufgrund von Problemen mit Speichermedien oder Teilkomponentenausfall sind nicht finanzierbar. Der Leser möge sich allein vorstellen, wie lange eine Großbank z.B. auf die Verfügbarkeit eines ihrer Aktien- oder Devisenhandelssysteme verzichten könnte. Aktien- und Devisenhandel geschieht weltweit. Zu jedem gegebenen Zeitpunkt innerhalb der 24 Stunden eines Tages wird an irgendeiner Börse auf dieser Welt gehandelt. Geht man davon aus, dass in einer großen deutschen Bank täglich Handelsvolumina von mehreren Milliarden Euro bewegt werden, kann man hochrechnen, was allein ein Stillstand von einer einzigen Minute kosten würde. Doch neben einer solchen kaufmännischen Unmöglichkeit eines Produktionsstillstandes gibt es klare gesetzliche Vorschriften, wie groß die maximale Ausfallzeit eines solchen Systems sein darf. So schreiben die Mindestanforderungen für Handelssysteme (MaH) eine maximale Ausfallzeit von zwölf Minuten/Monat vor. Heutige Anwendungen, die auch nur im entferntesten Kontakt zur Öffentlichkeit besitzen, müssen hochverfügbar sein. SAN-Umgebungen werden heute vor allem aus dem Hochverfügbarkeitsaspekt betrieben.
17
1 Der Weg zu SAN und NAS
Network Attached Storage (NAS) dagegen verwendet die Speicherkapazitäten der SAN-Umgebungen, um sie über multiple File-Server einer großen Server- oder Client-Anzahl über öffentliche und private Netzwerke zur Verfügung zu stellen. Hier wird das Hauptaugenmerk nicht auf möglichst schnellen Zugriff auf die gespeicherten Daten oder auf die Gewährleistung deren Verfügbarkeit gelegt, sondern im Wesentlichen darauf geachtet, dass bei Bedarf einer Vielzahl von Benutzern die Daten »gleichzeitig« verfügbar gemacht werden können. Klassische Anwendungen solcher NAS-Umgebungen sind z.B. Internetprovider, die »Content on Demand« oder »Video on Demand« anbieten. Weitere Nutzer dieser Technologien sind die Unternehmen, die via Enterprise-Portale sowohl Unternehmensmitarbeitern als auch Kunden einen dedizierten Zugriff auf die Daten des Unternehmens gewähren. Beispiele hierfür sind z.B. Versicherungsgesellschaften, die sowohl ihren Vertretern, als auch den Maklern und den potentiellen Kunden eine Internet-gestützte Auswahl von Verträgen ermöglichen. Weitere Beispiele mögen Buchungssysteme von Fluggesellschaften und Deutscher Bahn AG sein. NAS-Umgebungen charakterisieren sich durch die Unterstützung einer Vielzahl von Dateisystemen und Datenformaten, speichern diese Daten jedoch auf Storage Arrays in SAN-Umgebungen und nutzen daher auch deren Hochverfügbarkeitspotential. Im Folgenden soll der Weg zu heutigen hochverfügbaren SAN- und NASUmgebungen dargestellt werden.
1.1
Hochverfügbarkeit
1.1.1
Host-Komponenten
Das generelle Ziel einer hochverfügbaren Hardwareumgebung ist es, das System für seine Benutzer zu einem möglichst hohen Prozentsatz der Gesamtzeit verfügbar zu machen. Dieses Ziel wurde in Open Systems auf unterschiedliche Arten zu erreichen gesucht. Dieser Abschnitt soll eine Entwicklungslinie der Realisierung von High Availability (Hochverfügbarkeit) aufzeigen. Im vierten Kapitel dieses Buches wird dezidiert auf die Hochverfügbarkeitskomponenten heutiger SAN-Umgebungen eingegangen. In Systemen der mittleren Datentechnik in den 80er Jahren des 20. Jahrhunderts war in der Regel der Prozessor nicht auf einem einzigen Board implementiert, sondern in mehreren Systemkarten realisiert. Hier wurde zur Steigerung der Verfügbarkeit ein Instruction Retry implementiert, um bei fehlerhaften Instruktionen zu verhindern, dass der Prozessor mit einem Instruction-Fehler abstürzte. Diese Technologie wurde durch die beständige Miniaturisierung abgelöst, die die Prozessoren auf einer einzigen Karte technisch verfügbar machte. Zur Steigerung der Prozessorverfügbarkeit einer solchen Prozessorkarte wurde die Komponentenverfügbarkeit erhöht. Dies
18
Hochverfügbarkeit
bedeutete: Je weniger Komponenten ein System enthielt, desto weniger mögliche Fehlerquellen waren vorhanden. Die Reduktion der Anzahl der Prozessorboards auf z.B. eines verringerte die Anzahl der Boards, die durch einen Instruction Fault abstürzen konnten und damit eine geringere Verfügbarkeit des Komplettsystems bewirken konnten. Mit wachsender Miniaturisierungsrate der Hardwarebestandteile, konnten gegebene Hardware-Funktionalitäten auf immer weniger Boards im Computer-Chassis reduziert werden. Doch auch die Steigerung der Komponentenverfügbarkeit durch Verringerung der Anzahl potentiell fehlerhafter Komponenten machte ein Rechnersystem noch nicht zu einem hochverfügbaren. Auch Systeme mit hoher Komponentenverfügbarkeit konnten Komponentenfehler nicht ausschließen. Hochverfügbare Systeme sind Rechnersysteme, die Komponentenfehler umgehen können, die im Produktivbetrieb repariert und wieder in Betrieb genommen werden können. Die wünschenswerteste Lösung gegen Komponentenfehler ist Fehlertoleranz. Diese wird durch ein Höchstmaß an Redundanz der Komponenten erreicht. Das heißt, Prozessoren, Hauptspeicherboards, Busse, Platten-Controller, I/O-Subsystem, Stromversorgung, sprich sämtliche Komponenten des Computersystems sind doppelt vorhanden und im Normalfall produktiv. Fällt nun eine dieser Komponenten aufgrund eines Fehlers aus, so wird ihre Funktion durch ihren verbleibenden »Zwilling« übernommen. Die Gesamt-Performance reduziert sich zwar, der Betrieb des Systems läuft jedoch nahezu unterbrechungsfrei weiter; nahezu daher, weil natürlich bei Ausfall eines Prozessors eine Anwendung, die gerade von dem ausgefallenen Prozessor bedient wurde, mit einem Systemfehler unterbrochen würde, jedoch ohne Unterbrechung neu gestartet und dann eben von dem verbleibenden Prozessor verarbeitet werden könnte. Die ausgefallene Komponente kann nun ausgetauscht werden und ohne Unterbrechung des Betriebs eingebunden werden. Fehlertoleranz durch Komponentenredundanz lässt sich auf zwei Arten realisieren. Die N+1-Redundanz fügt eine zusätzliche Komponente zu einer Gruppe von Komponenten hinzu. Dieses Spare Part kann für jede andere Komponente dieser Gruppe einspringen, die ausfällt. So kann beispielsweise eine Reihe von Kühlungs-Gebläsen oder Power Supplies mit der Erweiterung um ein solches Spare Part den Ausfall jeder dieser Einheiten unterbrechungsfrei überstehen. Dieser Ansatz zur Steigerung der Verfügbarkeit ist ebenfalls für Stromkonverter und -regulatoren sinnvoll. Diese Komponenten sind auch – im Vergleich zu den übrigen Komponenten eines Computersystems – low cost-Komponenten, sodass die Realisierung dieser Form der Komponentenredundanz bereits sehr früh in Systemen der mittleren Datentechnik zur Steigerung der Systemverfügbarkeit angewendet wurde. Die zweite Form der Redundanz ist die 1 für 1-Hardware-Redundanz in aktiven elektronischen Komponenten. Um sich gegen den Ausfall einer aktiven Komponente, z.B. eines Job-Prozessors oder eines Hauptspeicher-Boards, zu schützen, ist ein Ansatz einer inaktiven Standby-Komponente nicht ausrei-
19
1 Der Weg zu SAN und NAS
chend. Damit eine solche Spare-Komponente ohne Verlust der Datenintegrität und des Systemstatus unverzüglich bei Ausfall der Komponente verfügbar ist, die sie absichern soll, muss sie die gleichen Instruktionen ausführen und die gleichen Daten verarbeiten wie dieses Original. Die zusätzlichen Kosten einer solchen wirklich fehlertoleranten Lösung sind für viele Umgebungen notwendig, jedoch nicht unerheblich. Daher wurde in der mittleren Datentechnik diese Lösung in aller Regel lediglich für Plattenspeicher, jedoch nicht für Hostkomponenten implementiert. Bei Hostkomponenten führte ein Ausfall einer der Komponenten 왘 Job Prozessor, 왘 Hauptspeichermodul, 왘 I/O-Prozessor, 왘 Datenbus, 왘 Systembus,
stets zu einem Systemfehler, d.h. Absturz des Komplettsystems. Eine höhere Verfügbarkeit dieser Systeme wurde dadurch erreicht, dass bei einem solchen Absturz die betroffene Komponente dekonfiguriert werden konnte und das System daraufhin sofort wieder angefahren werden konnte. Dabei sind jedoch einige Restriktionen zu beachten: Ein Neustart bei ausgefallener I/O-Komponente ist nur dann möglich, wenn noch Zugriff auf eine BootPlatte besteht. Der Neustart ist ebenfalls abhängig von der Konfiguration des I/O-Subsystems, einem evtl. vorhandenen Disk Mirroring und Dual Porting-Konfigurationen etc. Die Geschwindigkeit des Neustarts ist ebenfalls abhängig vom Recovery des Dateisystems der Platten und dem Recovery der Anwendungsdatenbanken. Die Entwicklung der Hochverfügbarkeitsansätze für Platten-Subsysteme werden im nächsten Unterabschnitt dargestellt. Die Auswirkungen auf Betriebssystem- und Anwendungssystemumgebung beleuchtet dieses Buch im Anschluss an die Darstellungen der Hardware-Komponenten moderner SAN-Umgebungen und die Erläuterung der darin eingesetzten Basis-Technologie-Komponenten. Die Hostkomponenten heutiger SAN-Umgebungen verwenden in der Regel eine modifizierte Form einer 1 für 1-Hardware-Redundanz, indem sie identische Hostkomponenten zu einem Cluster zusammenfassen. Innerhalb des Clusters können sämtliche Hosts die Platten des jeweils anderen Hosts sehen, für den sie den Backup darstellen. Über Heartbeat-Platten oder Netze wird von der Cluster-Software beständig geprüft, ob ein Host noch »lebt«. Kommt es zu einem virulenten Komponentenausfall, so schwenkt die Ausführung der auf dem ausgefallenen Host anhängigen Anwendungen auf den Backup-Host. Hier entfällt das Warten auf die zeitaufwändige Dekonfiguration der ausgefallenen Komponente und den Neustart des Hostsystems mit der Überprüfung der Dateisysteme und dem Neustart der Anwendungen. Was jedoch im Gegensatz zu einer tatsächlichen 1 für 1-Hardware-
20
Hochverfügbarkeit
Redundanz nicht erreicht wird, ist eine totale Fehlertoleranz. Auch in Cluster-Umgebungen stürzen bei Komponentenfehlern die Anwendungen dieser Komponenten ab, müssen neugestartet werden und auf ein Recovery evtl. beteiligter Datenbank-Management-Systeme warten. Das Zusammenwirken von Hardware- und Softwarekomponenten einer Cluster-Umgebung wird in einem späteren Kapitel dieses Buches dargestellt.
1.1.2
Komponenten des I/O-Subsystems
Wie bereits erwähnt ist Hochverfügbarkeit ein Merkmal von Komplettsystemen, nicht allein von Prozessoren. Für sämtliche Nicht-Prozessor-Hardware-Komponenten eines DV-Systems gelten die gleichen Prinzipien wie für die Prozessorkomponenten. Multiple Komponenten können einen Backup für den Ausfall von Systemkomponenten darstellen. Als erster Ansatz zur Minimierung der Verwundbarkeit eines Platten-Subsystems wurde Disk Mirroring implementiert. Dabei werden die Daten Controller- oder Softwaregesteuert auf zwei identische Magnetplatten geschrieben. Fällt eine Platte aus, wird ihre Funktion ohne Daten- oder Systemverlust von ihrem »Spiegel« übernommen. Die defekte Platte kann im laufenden Betrieb ausgetauscht und vom aktiven Spiegel aus wieder synchronisiert werden.
• RAID 1 – 1:1 Kopie lokaler Spiegel
Abbildung 1.1: Absicherungsmöglichkeiten für Magnetplatten
• RAID S – Daten-Platten (3) + Parity-Platte (1)
• RAID-R – Daten-Platten (7) + Parity-Platte (1)
• RDM – Remote Spiegel lokaler Platten In den 80er und frühen 90er Jahren war Disk Mirroring auf lokale Platten eines Hosts beschränkt, d.h. die Platten waren über einen internen I/O-Bus mit dem Hauptspeicher und dem Prozessor eines Rechnersystems verbunden. Als Erweiterung dieses Ansatzes wurden Magnetplatten-Subsysteme entwickelt, an die mehrere Computersysteme der gleichen Hardwarearchitektur angeschlossen werden konnten. Über eine Dual Porting-Funktionalität konnten die Magnetplatten eines solchen gespiegelten MagnetplattenSubsystems an mehrere Hosts angeschlossen werden, sodass beim Ausfall eines Hosts dessen Platten von dem zweiten übernommen und mit dem zweiten Host nach Start der Applikationen des ausgefallenen Hosts dessen Funktionen weitergeführt werden konnten. Die Hochverfügbarkeits-Hard21
1 Der Weg zu SAN und NAS
waremerkmale dieser Subsysteme schlossen eine Online-Diagnose des Magnetplatten-Subsystems, eine Online-Reparatur ausgefallener Komponenten sowie eine komplette Hardware-Redundanz sämtlicher Komponenten des Magnetplatten-Subsystems ein. Heutige Disk Arrays bieten über eine große Anzahl unterschiedlicher HostBus-Adapter die Möglichkeit, eine Vielzahl von Hosts unterschiedlicher Architektur anzuschließen. Weiter werden außer kompletten Spiegeln ganzer Platten auch weitere Sicherheitsverfahren aus den RAID-Standards (Redundant Array of Inexpensive Disks) unterstützt, die es ermöglichen, auch ohne komplette Disk-Spiegel den Inhalt einer ausgefallenen Platte durch ParityInformationen auf anderen Platten wiederherstellen zu können. Aufbau und Funktionalität solcher Disk Arrays und zu Grunde liegende Standards werden im Unterkapitel »Storage Arrays« des Kapitels »SANHardware-Komponenten« beschrieben.
1.2 Abbildung 1.2: Primäre SAN-Komponenten – Host (Host-Bus-Adapter) und hochverfügbares Storage Array
Storage Area Networks S tora ge Arra y Front-End
S tora ge Arra y Globa l S ha re d Me mory
To p Hig h
S tora ge Arra y Ba ck-End To p Low
Ho s t A Ca c h e S lo ts
Dis k Dire c to r
Ch a n n e l Dire c to r
P ort A P ort B
P roze s s or B P owe rP C750 266 MHz
P roze s s or B P owe rP C750 266 MHz
P ort C P ort D
P ort A P ort B P roze s s or A P owe rP C750 266 MHz
Tra c k Ta b le
P roze s s or A P owe rP C750 266 MHz
S ta tu s u n d Ko m m u n ika Tra c k Ta b le tio n s-Mailb o xe s
40 MB/S e k Ultra S CS I-Bus
P ort C P ort D
High Me mory
Ho s t B
DA (DiskAd a p te r)
Low Me mory Bo tto m Low
Bo tto m Hig h
Die in den vorigen Abschnitten dargestellten Komponenten bilden die grundlegenden Bausteine von Storage Area Networks. Über hochverfügbare Host- und I/O-Subsystemkomponenten in Cluster-Umgebungen werden Hardwareausfälle möglichst unterbrechungsfrei umgangen. Über eine entsprechende Konfiguration der Netzwerk- und Hochverfügbarkeits-Software
22
Storage Area Networks
(vgl. Kapitel »SAN-Softwarekomponenten«) wird ein benutzertransparentes Failover auf Backupkomponenten gewährleistet, wenn eine der primären Komponenten ausfallen sollte. Dennoch lässt die bisherige Betrachtung einige Details außen vor, bei deren Berücksichtigung noch gravierende Mängel einer Hochverfügbarkeitslösung, die lediglich auf den oben dargestellten Momenten aufbaut, hervortreten lässt. So ist bei den oben angeführten Verfahren der Anschluss der Hosts an ihre I/O-Subsysteme über Host-Adapter unterschiedlicher Technologien wie z.B. den Anschluss über parallele Schnittstellen (Centronics Host-Bus-Adapter), SCSI (Small Computer Systems Interface) oder auch Fibre Channel-Adapter realisiert (vgl. Kapitel zwei »SAN – Grundlegende Basis-Technologien«). Sämtliche Anschlussmöglichkeiten (außer eingeschränkt Fibre Channel) beschränken jedoch die räumliche Distanz zwischen dem Host und »seinen« Platten in den verwendeten Storage Arrays auf wenige Meter bis wenige hundert Meter. Eine lokal so eingegrenzte Hochverfügbarkeitslösung kann zwar ausreichen, im System selbst technisch aufgetretene Ausfälle zu kompensieren, ist jedoch auf keinen Fall geeignet, Totalverluste der Systemumgebung abzufangen. Allein schon der Gedanke an einen lokalen Stromausfall erhellt das Problem. Ist ein Rechenzentrum nicht mit einer Notstromversorgung ausgestattet (was natürlich sämtliche hochverfügbaren Rechenzentren sind), so führt ein Stromausfall trotz implementierter Hochverfügbarkeit zu einem Totalverlust der Anwendungen. Gegen Stromausfall sind die Rechenzentren zwar in der Regel geschützt. Wie steht es jedoch mit Ereignissen wie Wasserschäden, Feuer oder Naturkatastrophen wie z.B. einem Erdbeben? Rechenzentren, deren Hochverfügbarkeits-Architektur auf eine so enge Lokalität wie die beschriebene beschränkt ist, können aus solchen Szenarien nicht unbeschadet hervorgehen. Dennoch werden auch solche Umgebungen, die lokal lediglich mehrere Hosts an ein oder mehrere Storage Arrays binden, bereits als SAN oder Storage Area Networks bezeichnet. Dieses Buch beschränkt jedoch die Definition des SAN nicht allein darauf, dass mehrere Hostsysteme über ihre Host-Bus-Adapter Zugriff auf ein und dasselbe Storage Array besitzen und auch evtl. via Redundanzen der Hardware lokale Ausfallsicherheit bieten. Storage Area Networks im Sinne dieses Buches kombinieren die oben beschriebenen Hochverfügbarkeitskomponenten mit einer Netzwerkkomponente. Eine Host- und I/O-SubsystemUmgebung wird von einer identischen Umgebung gesichert, die sich bei Verwendung einer Fibre Channel Campus-Lösung bis zu 60 Kilometer, bei Verwendung von Telefon-Protokollen auch Tausende Kilometer entfernt befinden kann. Für die Implementierung einer solchen Technologie ist zur Gewährleistung einer hohen Bandbreite die Fibre Channel-Technologie einzusetzen. Als SAN bezeichnen wir somit ein hochverfügbares Speichernetzwerk, dessen Komponenten nicht auf engem Raum lokalisiert sind und daher auch oben beschriebene Katastrophen-Szenarien absichern können. In diesem Buch befassen wir uns mit dem Aufbau, der Administration und den technologischen Grundlagen der Hardware- und Softwarekomponenten solcher Storage Area Networks.
23
1 Der Weg zu SAN und NAS Abbildung 1.3: SAN-Definition diesem Buch gemäß
Lokale Hosts
Lokales Storage Array
Remote Storage Array
Remote Hosts
Campus (60 km) oder Distance Solutions
1.3
Network Attached Storage
In einer in heutigen Unternehmen weit verbreiteten verteilten Anwendungsumgebung werden die Anwendungsdaten auf einer Vielzahl von Servern gespeichert und ihren Client-Rechnern über Netzwerk zur Verfügung gestellt. Jeder der Server ist dabei für die Verwaltung seiner eigenen Daten verantwortlich. Das heißt, jeder Server wird lokal verwaltet, es werden lokale Datensicherungen betrieben, Benutzer- und Netzwerkadministration erfolgen ebenfalls lokal. Eine solche Umgebung bedeutet für das Unternehmen stets einen hohen Administrationsaufwand und damit verbunden hohe Administrationskosten. Dies führt dazu, dass über die Konsolidierung dieser Services nachgedacht und überlegt werden muss, ob sich durch die Zentralisierung einzelner Komponenten dieses Netzwerks nicht Kostenreduzierungen ergeben und Synergieeffekte mit der zentralen Datenverarbeitung des Unternehmens erzielt werden können. Network Attached Storage (NAS) stellt eine solche Konsolidierung dar. FileServer machen bei NAS Dateien und Dateisysteme über IP-Netzwerke verfügbar. Dabei wird auf zentralisierte Storage Devices zugegriffen. Diese Devices sind genau die I/O-Subsysteme, die auch in SAN-Lösungen eingesetzt werden. Dadurch können auch in NAS-Umgebungen die Hochverfügbarkeitslösungen der SANs eingesetzt und genutzt werden. Die FileServer bieten effizientes Daten-Sharing zu deutlich reduzierten Verwaltungs-
24
Network Attached Storage
aufwendungen, da die Zentralisierung der Datenhaltung zu einer zentralen Administration genutzt werden kann. Die Clients und Applikations-Server greifen über unterschiedliche Netzwerkmedien und Netzwerk-Protokolle auf die in den Storage Devices gespeicherten Informationen zu. So werden beispielsweise NFS- und CIFS-Protokolle unterstützt, die sowohl Unix-Servern über NFS, als auch Microsoft Windows NT-Servern über CIFS/SMB den simultanen Zugriff auf die gleichen Dateien ermöglichen. Ein NAS ist aus drei wesentlichen Bestandteilen aufgebaut: 왘 redundant konfigurierbaren File-Servern, in der Regel Standard-PCs mit
einem auf I/O-Belange reduzierten Betriebssystem. Diese stellen quasi einen hoch performanten I/O-Kanal zwischen I/O-Subsystem (den Storage Devices) und den über das Netzwerk angeschlossenen Clients (Network Attached Clients, daher auch die Bezeichnung als Network Attached Storage) dar; 왘 einem ebenfalls redundant ausgelegten Management-Prozessor, eben-
falls ein Standard-PC mit der Funktion der Konfiguration und des zentralen Managements der NAS-Umgebung sowie der Möglichkeit der unterbrechungsfreien Online-Wartung der File-Server und der Storage Devices; 왘 den Storage Devices. Hierbei handelt es sich um die gleichen Disk Arrays,
die das I/O-Subsystem moderner SAN-Umgebungen ausmachen. Diese Storage Devices werden auch für NAS-Umgebungen zu SANs konfiguriert, um die Hochverfügbarkeit der Fileservices zu gewährleisten. Abbildung 1.4: Komponenten des Network Attached Storage
LAN
Network SNSD
Heterogene Server Storage Array
Heterogene Clients/ Hosts
DataMover
Memory
Disk
Disk
Channel
SCSI
Adapter
Director
Director
Adapter
Disk
Disk
Adapter
Director
Disk Adapter
Disk Director
Disk
Disk
Adapter
Director
Channel Director
Channel Director
SCSI Adapter
SCSI Adapter
Channel
SCSI
Director
Adapter
Band
ControlStation
Dateisysteme:
Netzwerkschnittstellen:
Netzwerkprotokolle:
- UxFS
- Ethernet
- TCP/IP und UDP/IP
- FDDI
Dateizugriffsprotokolle: - Sun NFS V2 & V3
Dateiübertragung: - FTP / TFTP
- CIFS
- ATM
25
1 Der Weg zu SAN und NAS
Damit ist Network Attached Storage eindeutig nicht als Alternative zu einem Storage Area Network zu sehen. Network Attached Storage als Lieferant der Kapazitäten, die zur Unterstützung von klassischen kaufmännischen Anwendungen (z.B. unseres Handelssystems vom Anfang dieses Kapitels), lieferte alleine schon nicht die benötigte I/O-Bandbreite von vielen Megabytes pro Sek., die diese Anwendungen benötigen, abgesehen von allen weiteren bekannten Problemen mit Netzwerken. Network Attached Storage eignet sich jedoch hervorragend dafür, einer Vielzahl von Clients Fileservices zukommen zu lassen, was für Anwendungen wie Internetportale und Video-on-Demand und für die Dienstleistungen eines Internetproviders unabdingbar ist. Da diese Anwendungen ebenfalls dem Hochverfügbarkeitsanspruch unterliegen, werden die Storage Devices des NAS ebenfalls in das unternehmensweite SAN eingebunden und seine Fileservices so redundant als möglich angeboten. Die Kombination aus Network Attached Storage und Storage Area Network bildet das Speichernetz heutiger Unternehmen, ein Speichernetz, das als »unternehmensweites Speichernetzwerk« die hohe Verfügbarkeit der IT-Umgebung eines Unternehmens garantiert. Ein solches unternehmensweites Speichernetzwerk wird in Abbildung 1.5 dargestellt: Abbildung 1.5: Enterprise Storage Networks
Enterprise Communications Network
Database and Applications Hosts/Servers
File Services
NAS-Server Network Attached Storage
Switch Fibre Channel Director
Enterprise Storage Network
Storage Array Enterprise Storage
Dieses Buch behandelt sämtliche Komponenten moderner Enterprise Storage Networks. Das folgende Kapitel betrachtet die wesentlichen BasisTechnologien, die für den Aufbau solcher Speichernetze eingesetzt werden.
26
2
SAN – Grundlegende Basis-Technologien
2.1
Anschluss von Storage Devices über das SCSI-Protokoll
Storage Devices in SAN-Umgebungen werden je nach dem Host, von dem aus sie genutzt werden sollen, auf unterschiedliche Art und Weise angeschlossen. Klassische Host-Umgebungen wie in S/390-Systemarchitekturen von IBM kommunizieren mit ihren Speichermedien über blockorientierte Parallelschnittstellen. Das hierbei hauptsächlich verwendete Protokoll ist das HiPPI (High Performance Parallel Interface). Der parallele Anschluss der Storage Devices bedeutet jedoch, dass einige Einschränkungen in Kauf genommen werden müssen.
Interface
Ports
Maximale Entfernung
MB/ Sek
Kabeltyp
Hosts
Parallel
4
Ca. 160 m
4,5
Parallel Kupfer
Mainframe
ESCON
2/4
3 km ohne Repeater
17
Glasfaser 62,5 µ
Mainframe
4
25 m (FWD) 19 m (UWD)
20 40
Parallel Kupfer
Open Systems
SCSI
Fibre Channel
2 4.x
300 m / 500 m
100
Glasfaser 62,5 µ / 50 µ
Open Systems
Fibre Channel
8/2 5.x
300 m / 500 m
100
Glasfaser 62,5 µ / 50 µ
Open Systems
Abbildung 2.1: Interface-Technologien für StorageAnschluss im SAN
So kann das extern angeschlossene Storage-System maximal 160 Meter vom Host entfernt verkabelt werden. Das physikalische Verbindungsmedium ist ein paralleles Kupferkabel. Je Port eines verwendeten parallelen Host-Bus-
27
2 SAN – Grundlegende Basis-Technologien
Adapters (HBA) und des über diesen angeschlossenen parallelen Systemadapters am Storage-System kann eine maximale Übertragungsbandbreite von 4,5 MB/Sek. erzielt werden. Diese Einschränkungen führten schon relativ früh in Host-Umgebungen zu Überlegungen, wie Transportmechanismen über Glasfaserkabel implementiert werden können, die die restriktivsten Einschränkungen (maximale Entfernung und geringe Übertragungsbandbreite) der parallelen AnschlussTechnologien überwinden helfen. Seitens IBM wurde dazu das ESCON-Protokoll (Enterprise Systems Connection) entwickelt und für hochverfügbare Host-/Storage-Umgebungen eingesetzt. Dieses Glasfaser-Protokoll erweiterte die maximale Distanz zwischen Host und Storage-System auf drei Kilometer (ohne Repeater) und steigerte die Übertragungsbandbreite auf 17 MB/Sek. Die klassischen Anschlusstechniken bei internen und externen Geräten in Open Systems-Umgebungen basieren auf dem SCSI-Protokoll (Small Computer System Interface). Die beiden gängigsten Protokoll-Sets des SCSI-Protokolls sind Fast Wide Differential SCSI (FWD) und Ultra Wide Differential SCSI (UWD). Beide Techniken basieren auf paralleler Kupferverkabelung als physikalischem Transportmedium. Ein über FWD angeschlossenes Gerät darf maximal 25 Meter von seinem Host entfernt sein, UWD erlaubt eine noch geringere Distanz von nur maximal 19 Metern. Die Übertragungsbandbreite je Port eines HBAs respektive eines SCSI-Systemadapters beim angeschlossenen Storage Device beträgt jedoch mit 20 MB/Sek. (FWD) und 40 MB/Sek. (UWD) ein Vielfaches der parallelen Anschlusstechniken der MainframeUmgebungen und schlägt auch die ESCON-Bandbreite um maximal mehr als das Doppelte. Auch in Open Systems-Umgebungen wurden Implementierungen der Glasfaser-Technologie als Schnittstellentechnik für Storage-Systeme gesucht. Da die Standardisierungstendenzen in Open Systems-Umgebungen stets stärker ausgeprägt waren als in klassischen Mainframe-Umgebungen, wurde hier mit dem Fibre Channel-Protokollstack ein ANSI-Standard (American National Standards Institute, vergleichbar dem deutschen DIN – Deutsches Institut für Normierung) entwickelt, der heute von der kompletten Computerindustrie als der Schnittstellenstandard der Zukunft akzeptiert und implementiert wird. Im Folgenden wird ein Hauptaugenmerk auf den gängigen Anschluss von Speichersystemen über das SCSI-Protokoll gelegt. Als Beispiel für die Adressierung, Einrichtung und Administration von SCSI Storage Devices soll die SCSI Device-Administration unter Solaris 2.x von SUN Microsystems dargestellt werden. Weiter wird – als Beispiel für die Lösung der Distanzprobleme von über SCSI angeschlossenen Peripheriegeräten – ein Überblick über Netzwerk-Technologien gegeben, bevor mit der Darstellung der Fibre Channel-Standard-Implementierung die Schnittstellen-Technologie dargestellt wird, die sämtliche in Open Systems- und Mainframe-Umgebungen
28
Anschluss von Storage Devices über das SCSI-Protokoll
verwendeten Interface-Protokolle unterstützt und mit den Vorzügen von Netzwerken – große Distanz, beliebige Anzahl von Netzknoten und leichte Administrierbarkeit – verbindet.
2.1.1 2.1.1.1
Device-Administration unter Solaris 2.x Erstellen und Verwalten von Special Files – Character Devices für Magnetbänder, -platten, Disketten und CD-ROMs unter Solaris
Unter Solaris wie auch unter sämtlichen anderen Unix-Derivaten werden zwei Arten von Datenmedien unterschieden: 왘 »Cooked« Files, als Dateien, die auf einer Magnetplatten-Partition liegen,
die ein Dateisystem (Filesystem) enthält und 왘 »Raw« Files, auch als raw devices oder Special Files bezeichnet, die einer
Magnetplattenpartition entsprechen, die kein Dateisystem enthält, oder die lediglich ein Gerät repräsentieren, das seitens des Betriebssystems »gekannt« wird. Diese Datenmedien, auch Devices oder (externe) Speichermedien genannt, werden in aller Regel über das SCSI-Interface angeschlossen. Die Adressierung der Medien erfolgt über so genannte Special Files. Diese folgen in ihrer Benennung einer so genannten CTL-Mimik. Ein Device, z.B. eine Magnetplatte, erhält eine Adresse, die im Wesentlichen aus drei Bestandteilen aufgebaut ist: 왘 dem Controller, über den die Platte ansprechbar ist. Bei diesem Controller
handelt es sich um einen Host-Bus-Adapter. Ein SCSI-Controller bietet bis zu acht Anschlussmöglichkeiten/Adressen (Ports) für Devices, wovon eine Adresse für den Controller selbst vorgesehen ist. 왘 Diese Ports bezeichnen das Target, an dem Devices, z.B. Magnetplatten
angeschlossen werden. FWD und UWD-Controller besitzen standardisiert vier Targets, an denen externe Geräte wie Storage-Systeme oder Magnetband-Bibliotheken (Tape Roboter) angeschlossen werden können. 왘 Die LUN (Logical Unit Number) bezeichnet das physikalische Gerät, das
an das Target angeschlossen ist. Die LUN wird – bei 0 beginnend – hochgezählt. In gängigen Implementierungen werden maximal acht physikalische Devices (Magnetplatten, LUNs) an ein SCSI-Target angeschlossen.
29
2 SAN – Grundlegende Basis-Technologien
Eine Magnetplatte kann also anhand Ihrer Adresse eindeutig lokalisiert werden. Die Magnetplatte mit der Adresse c0t2d4 ist gemäß der CLT-Mimik also die fünfte Platte (d4) am dritten Port oder Target (t2) des ersten SCSI-Controllers (c0) im Host. Die Position des Controllers wird durch den Slot am Backpanel des Hosts definiert, in den das Controller-Board gesteckt wird.
2.1.1.2
Das Konzept der Special Files
Folgendes Beispiel verdeutlicht das Konzept der Special Files unter Solaris. Es soll die erste Partition einer Magnetplatte beschreiben, die auf dem Target 3 des ersten SCSI-Busses liegt. Dateityp
Verzeichniseintrag
Kommando zum Erstellen des Special Files
symbolic link
/dev/sd0a zeigt auf
# /usr/ucb/ucblinks
symbolic link
/dev/dsk/c0t3d0s0 zeigt auf
# disks # tapes # ports # devlinks
Special File
/devices/sbus@1,f8000000/
# /drvconfig
esp@0,8f00000/sd@3,0:a Tab. 2.1: Das Konzept der Special Files
2.1.1.3
Special Files im Verzeichnissystem
Die Special Files stehen in den Hierarchieebenen unter dem Verzeichnis /devices. Die Hierarchie unterhalb des Verzeichnisses /devices reflektiert das Hardware-Layout des Solaris-Computers. Special Files werden während des Boot-Vorgangs angelegt, wenn ein Device zum ersten Male erkannt wird. Hierzu wird beim Boot ein SCSI-Scan durchgeführt. Der Boot-Prozess überprüft dabei sämtliche Controller-Slots, ob an diesen SCSI-Host-Bus-Adapter angeschlossen sind und ob an deren Targets Devices hängen. Ein solcher SCSI-Scan sieht dabei sämtliche hostintern angeschlossene Devices, jedoch auch sämtliche Devices, die über ein Target eines Host-Bus-Adapters an einen SCSI-Systemadapter eines externen Storage Arrays angeschlossen sind. Das Ergebnis eines solchen SCSI-Scans kann z.B. wie folgt aussehen:
30
Anschluss von Storage Devices über das SCSI-Protokoll Device --------------------Name --------------------/dev/rdsk/c0t0d0s2 /dev/rdsk/c0t1d0s2 /dev/rdsk/c0t2d0s2 /dev/rdsk/c1t0d0s2 /dev/rdsk/c1t1d0s2 /dev/rdsk/c1t2d0s2 /dev/rdsk/c2t17d0s2 /dev/rdsk/c2t17d1s2 /dev/rdsk/c2t17d2s2 /dev/rdsk/c2t17d3s2 /dev/rdsk/c2t17d4s2 /dev/rdsk/c2t17d5s2 /dev/rdsk/c2t17d6s2 /dev/rdsk/c2t17d7s2 /dev/rdsk/c2t17d8s2 /dev/rdsk/c2t17d9s2 /dev/rdsk/c2t17d10s2 /dev/rdsk/c2t17d11s2 /dev/rdsk/c2t17d12s2 /dev/rdsk/c2t17d13s2 /dev/rdsk/c2t17d14s2 /dev/rdsk/c2t17d15s2 /dev/rdsk/c2t17d16s2 /dev/rdsk/c2t17d17s2 /dev/rdsk/c2t17d18s2 /dev/rdsk/c2t17d19s2 /dev/rdsk/c2t17d240s2 /dev/rdsk/c2t17d241s2 /dev/rdsk/c3t18d0s2 /dev/rdsk/c3t18d1s2 /dev/rdsk/c3t18d2s2 /dev/rdsk/c3t18d3s2 /dev/rdsk/c3t18d4s2 /dev/rdsk/c3t18d5s2 /dev/rdsk/c3t18d6s2 /dev/rdsk/c3t18d7s2 /dev/rdsk/c3t18d8s2 /dev/rdsk/c3t18d9s2 /dev/rdsk/c3t18d10s2 /dev/rdsk/c3t18d11s2 /dev/rdsk/c3t18d12s2 /dev/rdsk/c3t18d13s2 /dev/rdsk/c3t18d14s2 /dev/rdsk/c3t18d15s2 /dev/rdsk/c3t18d16s2 /dev/rdsk/c3t18d17s2 /dev/rdsk/c3t18d18s2 /dev/rdsk/c3t18d19s2 /dev/rdsk/c3t18d240s2 /dev/rdsk/c3t18d241s2 /dev/rdsk/c4t33d0s2 /dev/rdsk/c4t33d1s2
Product -------Type -------SEAGATE SEAGATE FUJITSU FUJITSU FUJITSU SEAGATE R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 GK GK R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 GK GK R2 R2
--------------------Vendor ID --------------------ST318203L SUN18G ST318203L SUN18G MAG3182L SUN18G MAG3182L SUN18G MAG3182L SUN18G ST318203L SUN18G EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX EMC SYMMETRIX
Device -------------------------------Rev Ser Num Cap (KB) -------------------------------034A 0013E672 17689266 034A 0013E610 17689266 1111 00135481 17689266 1111 00135488 17689266 1111 00135488 17689266 034A 0013E718 17689266 5265 62009000 8838720 5265 6200A000 8838720 5265 6200B000 8838720 5265 6200C000 8838720 5265 6200D000 8838720 5265 6200E000 8838720 5265 62016000 8838720 5265 62017000 8838720 5265 62018000 8838720 5265 62019000 8838720 5265 6201A000 8838720 5265 6201B000 8838720 5265 6201C000 8838720 5265 6201D000 8838720 5265 6201E000 8838720 5265 6201F000 8838720 5265 62020000 8838720 5265 62021000 8838720 5265 62022000 8838720 5265 62023000 8838720 5265 62014000 2880 5265 62015000 2880 5265 62009000 8838720 5265 6200A000 8838720 5265 6200B000 8838720 5265 6200C000 8838720 5265 6200D000 8838720 5265 6200E000 8838720 5265 62016000 8838720 5265 62017000 8838720 5265 62018000 8838720 5265 62019000 8838720 5265 6201A000 8838720 5265 6201B000 8838720 5265 6201C000 8838720 5265 6201D000 8838720 5265 6201E000 8838720 5265 6201F000 8838720 5265 62020000 8838720 5265 62021000 8838720 5265 62022000 8838720 5265 62023000 8838720 5265 62014000 2880 5265 62015000 2880 5265 99009000 8838720 5265 9900A000 8838720
31
2 SAN – Grundlegende Basis-Technologien
Dabei stellen die ersten sechs angezeigten Magnetplatten die hostintern angeschlossenen Platten dar. Sämtliche anderen Platten befinden sich in einem Storage Array – hier einem Symmetrix-System des Herstellers EMC2, das im SAN verfügbar ist. Es gibt jedoch ebenfalls Kommandos, um ein Special File quasi manuell durch den Systemadministrator erstellen zu lassen. Um BSD- oder System V-Gewohnheiten eines Administrators gerecht zu werden, existieren im Verzeichnis /dev zwei symbolische Links auf jedes Special File. 왘 Ein Name für das Special File im BSD-Stil
Beispiel: /dev/sd0a
(symbolic link)
왘 Ein Name für das Special File im System V-Stil
Beispiel: /dev/dsk/c0t3d0s0
(symbolic link)
Beide symbolische Links zeigen auf das gleiche Special File /devices/sbus@1,f8000000/esp0,800000/sd@3,0:a
2.1.1.4
Manuelles Erstellen von Special Files
Mit dem Kommando # drvconfig
werden innerhalb der Verzeichnishierarchie unterhalb /devices die Special Files und die Verzeichnisstruktur für sämtliche erkannte Geräte erstellt. Beispiel: # drvconfig
2.1.1.5
Erstellen von symbolischen Links im Unix-System V-Stil
Abhängig von der Art des Gerätes können mit unterschiedlichen Kommandos symbolische Links auf die Special Files dieser Geräte im System V-Stil erstellt werden. Folgende Kommandos existieren dazu: # disks # tapes
32
Das Kommando # disks erstellt symbolische Links zu Special Files, die für den Zugriff auf Platten verwendet werden. Das Kommando # tapes erstellt symbolische Links zu Special Files, die für den Zugriff auf Bandlaufwerke verwendet werden.
Anschluss von Storage Devices über das SCSI-Protokoll
# ports # devlinks
2.1.1.6
Das Kommando # ports erstellt symbolische Links zu Special Files, die für den Zugriff auf Ports (IPC) verwendet werden. Das Kommando # devlinks erstellt symbolische Links zu sämtlichen anderen Special Files, die in der /etc/devlink.tab beschrieben und eingetragen sind.
Erstellen von symbolischen Links im BSD-Stil
Zur Unterstützung von zu SunOS 4.x kompatiblen Device-Namen werden mithilfe des Kommandos # ucblinks
symbolische Links im BSD-Stil auf die symbolischen Links im System V-Stil erzeugt. Beispiel: # /usr/ucb/ucblinks
Scanning /devices/ directory tree ... Scanning /dev/ directory tree ...
2.1.1.7
Erstellen von Special Files und symbolischen Links während des Boot-Vorgangs
Wird bei dem Boot-Kommando die Option -r verwendet, so werden für sämtliche vom Boot erkannten Geräte die Special Files und symbolischen Links erstellt. In einigen Fällen ist es nach diesem Re-Boot zur Rekonfiguration notwendig, zur Erstellung weiterer kompatibler Namen das Kommando # /usr/ucb/ucblinks
auszuführen. Beispiel: ok boot -r
Die Option -r rekonfiguriert das System. Dabei werden sämtliche angeschlossenen Geräte erkannt.
33
2 SAN – Grundlegende Basis-Technologien
2.1.1.8
SCSI-Namen der Special Files
Special Files für Magnetband-Laufwerke Bis zu sieben SCSI-Bandlaufwerke können an einen SCSI-Controller angeschlossen werden. Die Special Files und deren korrespondierende symbolische Links werden in einem der folgenden Wege erstellt: 왘 boot -r Rekonfigurations-Boot, nachdem das Bandlaufwerk installiert
wurde 왘 Durch die Kommandos # drvconfig und # tapes
Für das erste angeschlossene Bandlaufwerk (z.B. an SCSI Target vier angeschlossen) werden folgende Special Files und symbolische Links erstellt: 왘 Special Files
/devices/sbus@1,f8000000/esp@0,f800000 /st@4,0:[
][n] 왘 Symbolic Link][n] Abhängig vom Namen, über den auf das Magnetband zugegriffen wird, werden unterschiedliche Densities verwendet. Folgende Densities sind verfügbar: Density (Abkürzung) lAngabe des Gerätenamens, auf den sich der mt-Befehl Dateien /sbus@1,f8000000/esp@0,800000/sd@1,0 1. c0t1d1 <MAXTOR-MXT-1246X-X1.1 cyl 1876 alt zwei hd 15 sec 86 > /sbus@1,f8000000/esp@0,800000/sd@1,1 c0t3d0: configured with capacity 2.30 GB AVAILABLE DISK SELECTIONS: 2. c0t3d0 <MICROP-4130-10MA Mar1f0-TNOF cyl 3998 alt zwei hd 9 sec 228> /sbus@1, f8000000/esp@0,800000/sd@3,0 3. c0t3d1 <SUN0424 cyl 1151 alt zwei hd 9 sec 80> /sbus@1,f8000000/esp@0,800000/sd@3,1 Specify disk (enter ist number): 1 selecting c0t1d1 FORMAT MENU: disk - select a disk type - select (define) a disk type partition - select (define) a partition table current - describe the current disk format - format and analyze the disk repair - repair a defective sector label - write label to the disk analyze - surface analysis defect - defect list management backup - search for backup labels verify - read and display labels save - save new disk/partition definitions inquiry - show vendor, product and revision volname - set 8-character-Volume name quit Das Format-Menü wird nach Auswahl der zu bearbeitenden Platte angezeigt, kann jedoch während der Bearbeitung jederzeit wieder durch Eingabe des ? angezeigt werden. /sbus@1,f8000000/esp@0,800000/sd@1,0 1. c0t1d1 <MAXTOR-MXT-1246X-X1.1 cyl 1876 alt zwei hd 15 sec 86 > /sbus@1,f8000000/esp@0,800000/sd@1,1 c0t3d0: configured with capacity 2.30 GB AVAILABLE DISK SELECTIONS: 2. c0t3d0 <MICROP-4130-10MA Mar1f0-TNOF cyl 3998 alt zwei hd 9 sec 228> /sbus@1, f8000000/esp@0,800000/sd@3,0 3. c0t3d1 <SUN0424 cyl 1151 alt zwei hd 9 sec 80> /sbus@1,f8000000/esp@0,800000/sd@3,1 Specify disk (enter its number): 3 selecting c0t3d1 type Die Datei format.dat enthält Festplattenbeschreibungen. Mithilfe des Kommandos type können diese angezeigt, ausgewählt oder über den Punkt »other« neu von Hand eingegeben werden. Dafür sind ausführliche Festplatten-Konfigurations-Informationen notwendig. Handelt es sich bei der neu einzutragenden Platte um eine SCSI-2-Festplatte, so kann über den Punkt »Auto configure« eine automatische Konfiguration der Platte in der Datei format.dat erfolgen, die die Konfigurations-Informationen aus der Firmware der Festplatte in die format.dat einträgt. partition Mit dem Menüpunkt partition kann eine Festplatte in bis zu acht logische Platten aufgeteilt werden. Eine solche Solaris-Partition wird als slice bezeichnet. Die Slices werden von Slice 0 bis Slice 7 durchnummeriert. Die Standard-Verwendung der einzelnen Slices zeigt folgende Auflistung: slice 0 slice 1 ascii name = <MAXTOR-MXT-1680S-H2.4 cyl 1876 alt zwei hd 15 sec 86> pcyl = 1878 ncyl = 1876 acyl =2 nhead = 15 nsect = 86 Part Tag Flag Cylinders Size Blocks 0 root wm 0 – 111 70.55MB (112/0/0) 1 Swap wu 112 – 188 48.50MB (77/0/0) 2 backup wm 0 – 1875 1.15GB (1876/0/0) 3 wm 189 – 268 50.39MB (80/0/0) 4 wm 269 – 359 57.32MB (91/0/0) 5 wm 360 – 1269 573.19MB (910/0/0) 6 usr wm 1270 – 1746 300.45MB (477/0/0) 7 home wm 1747 – 1874 80.62MB (128/0/0) format> Beispiel # format Folgendes Beispiel des format-Kommandos zeigt, wie die Partition sechs der Platte c0t3d0 (c0t3d0s6) erweitert und die Partition sieben (c0t3d0s7) verkleinert wird. Dabei lässt sich z.B. die Plattenbezeichnung c0t3d0s7 wie folgt lesen: c0 mtu 1500 inet 173.173.2.1 netmask fffff00 broadcast 173.173.2.255 ether 7:0:19:d:da:de. Dieses die Bezeichnung der Partition, auf die das Filesystem zum Export durch NFS gemountet wird. Als Beispiel also: # ls –lL /dev/dsk/c2t1d0s4 ist der Name, der im zweiten Schritt identifiziert wurde, für unser Beispiel also # hahbsetup c0t1d3s0 also beispielsweise # prtvtoc /dev/dsk/c0t1d3s0 erzeugt werden. Die IP-Adresse der ServiceGruppe wird seitens VCS beim Start des Services konfiguriert, nicht durch das Betriebssystem beim Boot des Cluster-Systems. Abbildung 6.24 stellt die Worksheet-Informationen für die Service-Gruppen-Konfiguration unseres Beispieles dar. 왘 Der VCS-Konfigurationsfile wird wieder auf die read only-Berechtigung]]] online –RA <#|ALL> [-sid <SymmID>][-noprompt][-v] offline –RA <#|ALL> [-sid <SymmID>][-noprompt][-v] release [-sid <SymmID>][-noprompt][-lockn #][-force] remove [-sid <SymmID>][-noprompt] show [-applications <AppID>][-hostname ] sync [-sid <SymmID>][-rdf|-bcv|-local|-dirsts] verify [-sid <SymmID>][-v] pd [-h][-offline] -g [-sid <SymmID>] dev [-h][-offline] pd [-h][-offline][-sid <SymmID>] dev <SymDevName> [-h][-offline] -g pd [-h][-offline] -g [-sid <SymmID>] dev [-h][-offline][-sid <SymmID>][-v] [-h][-offline] pd [-h][-offline][-sid <SymmID>] dev <SymDevName> oder <SymDevName> explizit an eine mit bezeichnete Devicegruppe. Das bedeutet, dass das Gatekeeper Device lediglich für Kommandos, die diese Devicegruppe betreffen, verwendet wird. Zur Identifikation des Gatekeeper Devices beim Assoziieren kann entweder der Physical Device-Name des Gatekeepers, also der Pfad, unter dem das Gatekeeper Device beim Server erkannt wird (CTL) angesprochen werden und muss dann mit dem eingegeben werden oder der Symmetrix Device-Name <SymDevName> des Gatekeepers verwendet werden. Dabei handelt es sich um eine hexadezimale Nummer des Devices, die innerhalb eines Storage Arrays eindeutig ist. Wird ein Device von mehreren Hosts gesehen, also in jeder hochverfügbaren Cluster-Umgebung, können sich die physikalischen Namen des Devices auf den unterschiedlichen Hosts unterscheiden. Werden Operationen für Failover/FailbackSzenarien automatisiert, so empfiehlt sich stets die Verwendung des Symmetrix Device-Names, da dieser grundsätzlich gleich ist, unabhängig davon, von welchem Server aus er gesehen wird.][-c ][-h] -type PREFETCH [-i ][-c ][-sid <SymmID>] [-DA <#|ALL>][-CA <#|ALL>] [-DIR <#|ALL>] -type CACHE [-i ][-c ][-sid <SymmID>] [-EA <#|ALL>][-RA <#|ALL>][-SA <#|ALL>] -type DISK [-i ][-c ][-sid <SymmID>] [-disk ,,] –type BACKEND [-i ][-c ] –g DgName [-ld ] –type BACKEND [-i ][-c ] –pd –type BACKEND [-i ][-c ][-sid <SymmID>] –dev SymDevName -type MEMIO [-i ][-c ] -g [-ld ] -type MEMIO [-i ][-c ] -pd -type MEMIO [-i ][-c ][-sid <SymmID>] -dev <SymDevName> –type DMSP [-i ][-c ] –g DgName [-ld ] –type DMSP [-i ][-c ] –pd PdevName –type DMSP [-i ][-c ][-sid <SymmID>] –dev <SymmdevName> [-h][-force] [-bcv|-nobcv][-force] [-h] [-f ] [-ftype STD|R1BCV|STD-BCV|STD-R1BCV] [-h] [-f ][-sid <SymmID>] [-rdf][-delete] [-h] [-f ] [-type REGULAR|RDF1|RDF2] [-h] [-f ] [-h][-v][-sid <SymmID>][-offline] [-h] [-h][-offline] [-h][-offline] pd [] –g [-h][-offline][-sid <SymmID>] dev <SymDevName> [] –g [-h][-offline][-sid <SymmID>] [-SA <#|ALL>][-P #][-RDFG #][pd|dev][-CAP #][-N #] [-RANGE <SymDevStart>:<SymDevEnd>] –g [-h][-offline][noprompt] [] –g [-h][-offline][-v][-resv] –g [-h][-offset][-force][-rename] –g [-h][-offset][-force][-rename] [-SA <#|ALL>][-P #][-RDFG #][-CAP #] [-N #][-RANGE <SymDevStart>:<SymDevEnd>] –g [-noprompt][-bcv] [ […]] [-noprompt][-bcv] [ […]] relabel –g [-noprompt][-bcv] [ […]] remove –g [-h][-offline][-force] rename –g [-h][-offline] rmall –g [-h][-offset][-force][-SA<#|ALL>] [-P #][-CAP #][-N #] [-RANGE <SymDevStart>: <SymDevEnd>] rw-enable –g [-h][-offline][-noprompt][-SA <#|ALL>] [-P #][-bcv][ [ [-h][-offline] write-disable –g [-h][-offline][-noprompt] [-SA <#|ALL>][-P #][-bcv][[ in eine andere Devicegruppe . in die DeviceGruppe . pd [] [-h][-offline][-sid <SymmID>] -g [-rdf][-RDFG ][-bcv] dev <SymDevName> [] [-h][-offline][-sid <SymmID>] pd –g [-SA <#|ALL>][-P #][-CAP #][-N #][-R1|-NOR1] [-RANGE <SymDevStart>:<SymdevEnd>] [-h][-offline][-sid <SymmID>] dev –g [-rdf][-RDFG ][-bcv][-SA <#|ALL>] [-P #][-CAP #][-N #][-R1|-NOR1] [-RANGE <SymDevStart>:<SymdevEnd>] [-h][-offline] -g [-force] pd [-h][-offline][-sid <SymmID>] –g [-force][-rdf][-bcv] dev <SymDevName> [-h][-offline] -g [-force][-rdf][-bcv] ld [-h][-offline][-sid <SymmID>][-v][-resv] [-i ][-c ] pd [-h][-offline][-sid <SymmID>][-v][-resv] [-i ][-c ][dev] [-h][-offline] -g [-force][-rdf][-bcv] ld [-rename] [-h][-offline] -g [-force][-rename] pd [-h][-offline][-sid <SymmID>] -g [-force][-rdf][-bcv] dev <SymdevName> [-rename] [-force][-rdf][-bcv][-rename][-SA <#|ALL>] [-P #][-CAP #][-N #][-R1|-NOR1] [-RANGE <SyDevStart>:<SydevEnd>] [-h][-offline] -g [-force][-rdf][-bcv] [-SA <#|ALL>][-P #][-CAP #] [-N #][-R1|-NOR1] [-RANGE <SymDevStart>:<SymdevEnd>] oder seinem Symmetrix Device-Namen <SymDevName> einer Device-Gruppe zu. Hier sei nochmals auf die Vorteile der Operation mit Symmetrix Device-Namen verwiesen. In Cluster-Umgebungen und Umgebungen mit Device-Gruppen, die viele Devices enthalten, werden Operationen mit flexible Mirrors sehr häufig gescripted, um die Wiederverwendbarkeit der Konfiguration zu gewährleisten. Daher empfiehlt sich aufgrund der Eindeutigkeit des Symmetrix Device-Namens unabhängig vom Server, der die Devices einbindet, die Verwendung der Symmetrix Device-Namen als die optimale Wahl.. Als logischer Device-Name wird bei BCVs gerne ein sprechender Name für die Business Continuance-Funktion des BCVs verwendet, der anzeigt, wofür das BCV als flexible Mirror verwendet wird, wenn es von seinem produktiven Standard-Device getrennt wurde. Dies kann als Device für Datensicherung über einen Backup Host sein, kann jedoch auch ein Data Warehouse sein, das mit aktuellen Daten aus der Produktion über den flexible Mirror beliefert werden soll. Beim disassociate des BCVs kann dieses auch über den LdevName identifiziert werden. in eine andere . in eine andere . des BCVs. Diese Option ist sinnvoll, da die BCVs evtl. für ihre vorige Funktion sprechende Namen erhalten haben, die sie in der neuen Device-Gruppe sinnvollerweise nicht mehr besitzen sollten, da in der neuen Device-Gruppe aller Wahrscheinlichkeit nach auch eine neue Funktion der BCVs vorgesehen ist. spezifizierte Device StatusInformationen aus. attach [-h][-v][-rdf][-bcv][-i ][-c ] ([ [BCV pd ]]..) attach [-h][-v][-rdf][-bcv][-i ][-c ] ([[BCV dev <SymDevName>]]..) attach [-h][-v][-rdf][-bcv][-i ][-c ] ([ [BCV ld ]]..) –f attach -sid <SymmID> [-v][-i ][-c ] [-force][-symforce] –g detach [-h][-v][-rdf][-bcv][-i ][-c ] ([[BCV pd ]]..) detach [-h][-v][-rdf][-bcv][-i ][-c ] ([[BCV dev <SymDevName>]]..) # symmir –g detach [-h][-v][-rdf][-bcv][-i ][-c ] <[LdevName [BCV ld LdevName]]>..) –f detach -sid <SymmID> [-v][-i ][-c ] [-force][-symforce] # symmir –g cancel [-v][-rdf][-bcv][-i ][-c ] ([ [BCV pd ]]..) cancel [-v][-rdf][-bcv][-i ][-c ] ([[BCV dev <SymDevName>]]..) cancel [-v][-rdf][-bcv][-i ][-c ] ([ [BCV ld ]]..) –f cancel -sid <SymmID> [-v][-i ] [-c ] [-force][-symforce] # symmir -g establish [-h][-v][-noprompt][-rdf][-i ][-c ] [-force][-symforce][-bcv][-full][-exact|-opt] ([ [BCV pd ]]..) establish [-h][-v][-noprompt][-rdf][-i ][-c ] [-force][-symforce][-bcv][-full][-exact|-opt] ([ [BCV dev <SymDevName>]]..) establish [-h][-v][-noprompt][-rdf][-i ][-c ] [-force][-symforce][-bcv][-full][-exact|-opt] ([ [BCV ld ]]..) –f establish -sid <SymmID> [-v][-i ][-c ] [-force][-symforce][-full][-reverse][-noprompt] # symmir -g restore [-h][-v][-noprompt][-rdf][-i ][-c ] [-force][-symforce][-bcv][-full][-exact|-opt] [-remote][-bypass][-not-ready] ([[BCV pd ]]..)][-c ] [-force][-symforce][-bcv][-full][-exact|-opt] [-remote][-bypass][-not-ready] ([ [BCV dev <SymDevName>]]..) symmir -g restore [-h][-v][-noprompt][-rdf][-i ][-c ] [-force][-symforce][-bcv][-full][-exact|-opt] [-remote][-bypass][-not-ready] ([]]..) –f restore -sid <SymmID> [-v][-i ][-c ] [-force][-symforce][-full][-reverse][-noprompt] [-remote][-bypass][-not-ready] symmir –g split [-h][-v][-noprompt][-rdf][-i ][-c ] [-force][-symforce][-bcv][-diff][-remote][-bypass] [-not-ready][-instant] [ [ ..]] –f split -sid <SymmID> [-v][-i ][-c ] [-force][-symforce][-diff][-reverse][-noprompt] [-remote][-bypass][-instant][-not-ready] symmir –g query [-h][-v][-rdf][-bcv][-i ][-c ] [-offline][-attach|-multi [-bg]] [ [ 