Storage Area Networks Network Attached Storage. Hohe Datenverfügbarkeit durch Speichernetzwerke

Wolfgang Sollbach Storage Area Networks Hohe Datenverfügbarkeit durch Speichernetzwerke An imprint of Pearson Educati...

Author: Wolfgang Sollbach

210 downloads 2377 Views 6MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

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


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


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


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


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


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 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


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


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


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


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.


# 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.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

/dev/rmt/0[][n] Abhängig vom Namen, über den auf das Magnetband zugegriffen wird, werden unterschiedliche Densities verwendet. Folgende Densities sind verfügbar: Density (Abkürzung) l

Bedeutung LOW (niedrig)

m

MEDIUM (mittel)

h

HIGH (hoch)

Tab. 2.2: Magnetband-Densities unter Solaris

Wird keine Density angegeben, schreibt ein Bandlaufwerk in seiner »präferierten Density«. Die präferierte Density ist stets die höchste Density, die von dem Bandlaufwerk unterstützt wird. Soll ein Magnetband auf einer Bandstation gelesen werden, die eine andere Density unterstützt als die der Bandstation, auf der es erzeugt wird, so muss diese spezielle Density während des Schreibens des Bandes angegeben werden. Mit dem Buchstaben n am Ende der Datei (symbolischer Link), über die das Bandlaufwerk angesprochen wird, wird das Magnetband nach dem Beschreiben nicht zurückgespult ( n = No Rewind).

34


Folgende Beispiele beschreiben, wie auf das erste Magnetband-Laufwerk, das am System angeschlossen ist, zugegriffen werden kann: /dev/rmt/0

Standard Density und Zurückspulen

/dev/rmt/0n

Standard Density und nicht Zurückspulen

/dev/rmt/0h

Hohe Density und Zurückspulen

/dev/rmt/0hn

Hohe Density und nicht Zurückspulen

Zur Verwaltung von Magnetband-Stationen kann das Tape-Control-Kommando # mt verwendet werden. Optionen zum mt-Kommando -f Angabe des Gerätenamens, auf den sich der mt-Befehl

beziehen soll eof, weof

Schreibt auf die aktuelle Position des Magnetbandes eine EOF-Marke (Dateiende)

eom

Vorspulen bis ans Ende des verwendeten Bereiches auf dem Magnetband, um hinter diesem Ende weitere Daten zu schreiben

erase

Löschen des gesamten Magnetband-Inhaltes

fsf

Vorspulen des Magnetbandes um die Dateien

offline

Auswerfen des Magnetbandes und Offline-Setzen des Magnetband-Laufwerkes nach Zurückspulen des Magnetbandes zur BOT-Marke

rewind

Zurückspulen des Magnetbandes zur BOT-Marke (Begin of Tape)

status

Anzeigen der Zustands-Informationen (Status) des Magnetband-Laufwerkes

Beispiel (Statusabfrage) # mt -f /dev/rmt/1 status

Archive DDS Data Cartridge tape drive: sense key(0x6)= unit attention residual= 0 file no= 0 block no= 0

2.1.1.9

retries= 0

Special Files für Floppy-Laufwerke

SPARC-Stations werden mit einem Floppy-Laufwerk ausgeliefert. Die folgenden Special Files und symbolischen Links werden für das Floppy-Laufwerk angelegt:

35

2 SAN – Grundlegende Basis-Technologien 왘 Special Files

Block Device: /devices/fd@1,f7200000:c Character Device: /devices/fd@1,f7200000:c,raw 왘 Symbolic Link

Zum Block Device: /dev/diskette Zum Character Device: /dev/rdiskette Zum Formatieren einer Floppy-Disk wird das Kommando # fdformat

verwendet. Disketten werden beim Formatieren standardmäßig auf 1,44 MByte Kapazität formatiert. Dabei wird die Oberfläche der Diskette auf Bad Blocks untersucht und diese ausgetragen. Auf der Diskette bereits vorhandene Daten gehen durch das Formatieren verloren. Optionen zum fdformat-Kommando

36

- D

(Simple Density) Es formatiert eine 3,5"-Diskette auf lediglich 720 KBytes Kapazität. Eine 5,25"-Diskette wird auf 320 KBytes formatiert.

- E

(Extended Density) Es formatiert eine Diskette auf 2,88 MByte Kapazität, wenn das Floppy-Laufwerk diese Density unterstützt.

- H

Es formatiert eine 3,5"-Diskette mit 1,44 MByte, auch wenn das Floppy-Laufwerk, in dem die Diskette liegt, eine extended density unterstützt.

- U

(Unmount) Es hängt die zu formatierende Diskette vor dem Formatieren aus dem Dateisystem aus.

- b

Hier wird ein Name (Label) für das Laufwerk vergeben. Wird eine Diskette für DOS formatiert (t-Option), darf das Label maximal acht Zeichen, für ufs-Dateisysteme lediglich elf Zeichen lang sein.

- e

(Eject) Die Diskette wird nach dem Formatieren aus dem Diskettenschacht ausgeworfen.

- f

(Force) Hier wird die Diskette sofort formatiert ohne Acknowledgement-Rückfrage.

- q

(Quit) Hier wird die Diskette ohne Ausgabe von Meldungen zum Formatierungsvorgang formatiert.


- t dos

Die Diskette für MS-DOS wird formatiert.

- v

(Verbose) Ausführliche zusätzliche Oberflächenüberprüfung der Diskette nach Bad Blocks (Hardwarefehler).

- x

Lediglich Erstellung eines Labels für die Diskette, jedoch ohne diese zu formatieren.

Beispiel Kommando # fdformat # fdformat -Hvt dos

Formatting 1,44 MBytes in /vol/dev/rdiskette0/unlabeled Press return to start formatting floppy. ......................................................................................................................... # Durch dieses fdformat wird eine Diskette im Standard-Diskettenlaufwerk mit einer Kapazität von 1,44 MBytes formatiert, obwohl das Laufwerk die extended density von 2,88 MBytes unterstützen würde. Die Diskette wird für DOS formatiert und beim Formatieren einer zusätzlichen ausführlichen Oberflächenuntersuchung nach Bad Blocks unterzogen.

2.1.1.10

Special Files für Magnetplatten

Bis zu sieben SCSI-Disks können an einem SCSI-Controller angeschlossen werden. Die Special Files und die mit diesen korrespondierenden symbolischen Links für Magnetplatten können auf eine der folgenden Weisen erstellt werden: 왘 boot

-r Rekonfigurations-Boot, nachdem die Magnetplatte installiert wurde

왘 Durch die Kommandos # drvconfig und # disks

Für die erste Partition einer Platte (z.B. an SCSI Target 3 angeschlossen) werden folgende Special Files und symbolische Links erstellt: 왘 Special Files

Block Device: /devices/sbus@1,f8000000/esp@0,f800000 /sd@3,0:a Character Device: /devices/sbus@1,f8000000/esp@0,f800000 /sd@3,0:a,raw 왘 Symbolic Link

Zum Block Device: /dev/dsk/c0t3d0s0 Zum Character Device: /dev/rdsk/c0t3d0s0

37


Dabei wird die Namenskonvention für die Benennung der MagnetplattenGeräte wie folgt definiert: c0

Controller Nummer: 0

t3

SCSI-Bus Target-Nummer: 3

d0

Nummer der Magnetplatte, die an das Target angeschlossen ist: 0

s0

Slice (Partition) Nummer: 0 (repräsentiert Partition »a« unter SunOS 4.x)

Zum Formatieren einer Magnetplatte wird das Formattool # format

verwendet.

Das Konzept des Partitioning Beim Formattool kann mit dem Kommando partition die Festplatte in logische Platten gegliedert werden. 왘 Eine Partition ist ein physikalischer und zusammenhängender Teil der

Magnetplatte. 왘 Eine Partition kann für Swap Space oder für ein Dateisystem verwendet

werden. 왘 Verwendete Partitions auf einer Platte dürfen sich nicht überlappen. 왘 Vorzüge des Partitioning sind: 왘 Performance 왘 Unterschiedliche Dateisysteme auf unterschiedlichen Partitions kön-

nen dedizierte Zugriffsschutzmechanismen und Datensicherungen ermöglichen. 왘 Sicherheit

Eine Partition kann verwendet werden für 왘 Ein Dateisystem 왘 Swap Space 왘 ein raw Device, das z.B. für Datenbanksysteme die Umgehung der Sola-

ris I/O-Mechanismen ermöglicht

38


Regeln für das Partitioning 왘 Unter Solaris kann eine Magnetplatte in maximal acht Partitions unter-

gliedert werden. 왘 Einige Partitions können überlappen. Dennoch dürfen Partitions, die

verwendet werden, nicht überlappen. 왘 Standardmäßig überzieht eine Partition die komplette Platte. Diese kann

nur verwendet werden, wenn keine der anderen Partitions der Platte verwendet wird. Auf Partitions wird über Special Files zugegriffen. Je nach Art des Zugriffs wird in dem entsprechenden Kommando entweder das Special File oder das Character Device angesprochen. Verglichen mit Magnetplatten, auf denen die Partitions nicht genutzt werden, besitzt Partitioning folgende Vorteile: Performance Liegt ein Dateisystem lediglich auf einem zusammenhängenden (contiguous) Teil der Platte und nicht auf der gesamten Platte, liegen die Datenblöcke einer Datei näher beieinander und sind daher vom Controller schneller zu finden. Dedizierter Zugriff Jedes Dateisystem kann mit unterschiedlichen Zugriffsrechten eingehängt werden (mount-Kommando). Für unterschiedliche Dateisysteme können nun auch dedizierte Backup-Strategien entwickelt werden. Sicherheit Ein Software- oder Hardwarefehler betrifft lediglich das Dateisystem oder die Partition, auf dem/der er auftritt. Nachteile des Partitioning 왘 Limitierung des Dateisystems

Ein Dateisystem ist auf eine Partition limitiert. Unter Solaris ist die maximale Größe der Partition die Größe der gesamten Platte. Daher ist die maximale Größe eines Dateisystems auch die Größe einer Festplatte. 왘 Dateisystem ist nicht vergrößerbar/verkleinerbar

Die Größe eines Dateisystems kann nicht verändert werden.

39


Default Partition-Tabelle von Solaris Bei einer Standalone-Installation ist das Standard-Partition-Layout wie folgt: /

/dev/dsk/c0t3d0s0

/usr

/dev/dsk/c0t3d0s6

<Swap>

/dev/dsk/c0t3d0s1

Backup

/dev/dsk/c0t3d0s2 (über die komplette Platte)

Die Partitions s3, s4, s5 und s7 sind standardmäßig nicht definiert.

Partitioning unter Solaris Entspricht die Standard-Partition-Tabelle nicht den Anforderungen einer Installation, so ist es erforderlich, die Größe und Lokation der Partitions auf der Platte zu verändern. Dafür müssen folgende Schritte unternommen werden: 1. # dmesg

Herausfinden, welche Magnetplatten an das System angeschlossen sind

2. # prtvtoc

Anzeige der aktuellen Partition-Tabelle der Platte, um zu entscheiden, wie diese geändert werden soll

3. # format

Veränderung der Lokation und der Größe von einer oder mehreren Partitions

Informationen über Magnetplatten – das dmesg-Kommando Um zu sehen, welche Magnetplatten am System angeschlossen sind, wird das Kommando # dmesg

verwendet. Es zeigt die Meldungen an, die das System zum Boot-Zeitpunkt angelegt hat (dmesg = display messages). Beispiel # dmesg: # dmesg

SunOS Release 5.5 Version Generic [Unix(R) System V Release 4.0] Copyright © 1983-1995, SUN Microsystems, Inc. mem = 32768K (0x2000000) avail mem = 30621696 Ethernet address = 8:0:20:f:fa:de root nexus ) SUNW, SUN 4-75 sbus0 at root: obio 0xf8000000 dma0 at sbus0: SBus slot 0 0x400000 esp0 at sbus0: SBus slot 0 0x800000 SBus level 3 sparc ipl 3 sd3 at esp0: target 3 lun 0

40


sd3 is /sbus@1,f8000000/esp@0,800000/sd@3,0 <SUN0424 cyl 1151 alt zwei hd 9 sec 80> root on /sbus@1,f8000000/esp@0,800000/sd@3,0:a fstype ufs Swap on Swapfs fstype Swapfs size 27868K zs0 at root: obio 0xf1000000 sparc ipl 12 zs0 is /zs@1,f1000000 zs1 at root: obio 0xf0000000 sparc ipl 12 zs1 is /zs@1,f0000000 cgsix0 at sbus0: SBus slot zwei 0x0 SBus level 5 sparc ipl 7 cgsix0 is /sbus@1, f8000000/cgsix@2,0 cgsix0: screen 1280x1024, double buffered, vier M mappable, rev6 le0 at sbus0: SBus slot 0 0xc00000 SBus level vier sparc ipl 5 le0 is /sbus@1,f8000000/le@0,c00000 dump on /dev/dsk/c0t3d0s1 size 65868K audio0 at root: obio 0xf7201000 sparc ipl 13 audio0 is /audio@1,f7201000 fd0 at root: obio 0xf7200000 sparc ipl 11 fd0 is /fd@1, f7200000 sbusmem0 at sbus0: SBus slot 0 0x0 sbusmem0 is /sbus@1,f8000000/sbusmem@0,0 sbusmem1 at sbus0: SBus slot 1 0x0 sbusmem1 is /sbus@1,f8000000/sbusmem@1,0 sbusmem2 at sbus0: SBus slot zwei 0x0 sbusmem2 is /sbus@1,f8000000/sbusmem@2,0 sbusmem3 at sbus0: SBus slot 3 0x0 sbusmem3 is /sbus@1,f8000000/sbusmem@3,0

Anzeigen der Partition-Tabelle – Das prtvtoc-Kommando Als Entscheidungshilfe für die Änderungen der Partition-Tabelle kann mit dem Kommando # prtvtoc [ Name des raw Device ]

die aktuell verwendete Partition-Tabelle angezeigt werden. Dabei gibt die Option Name des Raw Devices den Character Special File der Platte an (Partiton 2), deren Partition-Tabelle angezeigt werden soll. Beispiel # prtvtoc # prtvtoc /dev/rdsk/c0t3d0s2

* /dev/rdsk/c0t3d0s2 partition map * * Dimensions: * 512 bytes/sector * 80 sectors/track * 9 tracks/cylinder * 720 sectors/cylinder * 2500 cylinders

41


* 1151 accessible cylinders * * Flags: * 1: unmountable, read-write * 10: read-only * 00: mountable, read-write * * Unallocated space: * First Sector Last * Sector Count Sector * 828720 4294930576 791999 * * First Sector *Partition Tag Flags Sector 0 2 00 0 1 3 01 61920 2 5 00 0 3 6 00 193680 4 0 00 0 5 6 00 234720 6 4 00 357840 7 8 00 747360

Last Count 61920 131760 828720 41040 0 123120 389520

Mount Sector 61919 193679 828719 234719 0 357839 747359 81360

Directory /

/export /opt /usr 828719/ export/home

Die Konfiguration von Festplatten – Das Solaris-Formattool Das Solaris-Formattool erlaubt menügesteuert sämtliche Operationen, die für die Konfiguration von Festplatten durchgeführt werden müssen. Diese Operationen sind: 왘 Anzeigen einer existierenden Partition-Tabelle, Änderung einer Parti-

tion-Tabelle, Speicherung der Partition-Tabelle unter einem Namen 왘 Informationen zur ausgewählten Festplatte 왘 Formatieren der Festplatte 왘 Reparieren von entdeckten Bad Blocks 왘 Labeln einer Festplatte 왘 Anzeigen und Ändern der Bad Block-Liste einer Festplatte 왘 Überprüfen des Backup-Bereichs der Festplatte 왘 Überprüfen und Anzeige der Hardwaredaten einer Festplatte 왘 Sichern von Partition-Tabellen von Magnetplatten 왘 Ermittlung und Ausgabe des Herstellernamens und Typs einer Magnet-

platte 왘 Erstellen eines Volume-Namens

42


Durch den Aufruf des Formattools werden alle systemweit bekannten Magnetplatten durchnummeriert angegeben. Durch Anwahl der Nummer kann die jeweilig zu bearbeitende Festplatte ausgewählt werden. Beispiel format-Kommando # format

Searching for disks...done c0t1d0: configured with capacity of 1.15GB AVAILABLE DISK SELECTIONS: 0. c0t1d0 /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.

43


Menüpunkte des Format-Tools disk zeigt die Platten-Auswahlmaske an, die auch beim Aufruf des Formattools angezeigt wird. Es wird verwendet, um innerhalb des Formattools die zu bearbeitende Festplatte zu wechseln. Beispiel disk: disk

Searching for disks...done c0t1d0: configured with capacity of 1.15GB AVAILABLE DISK SELECTIONS: 0. c0t1d0 /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

44

Die Partition 0 enthält das root-Dateisystem. Dieses enthält die beim Boot benötigten Dateien. Partition 1 wird als Swap-Partition für die Verwendung durch Benutzer gesperrt. In diesen Plattenbereich werden Memorypages laufender Prozesse ausgelagert, falls die Hauptspeicheranforderungen der Prozesse den physikalischen Hauptspeicher übersteigen.


slice 2

Diese Backup-Partition enthält kein Dateisystem. Als virtuelle Partition überspannt sie die komplette Festplatte. Slice zwei wird lediglich für die Systemsicherung verwendet.

slice 3

Diese Partition wird auf Server-Rechnern gern für das /export-Dateisystem verwendet, das die Dateien enthält, die für (diskless) Clients exportiert werden.

slice 4

Partition 4 wird auf Servern bevorzugt für die Swap-Area von diskless Clients verwendet und dann mit dem mountKommando in der Regel unter export/Swap eingehängt.

slice 5

Partition 5 enthält in der Regel das Dateisystem /opt, das optionale Software (z.B. Office-Software, Datenbank-Software etc.) enthält.

slice 6

Partition sechs wird üblicherweise für das Filesystem /usr verwendet, das wesentliche Betriebssystemdateien und systemnahe Software (z.B. vi, make etc.) enthält.

slice 7

Serverseitig wird Partition 7 häufig für das Dateisystem /export/home verwendet, das die initial working directories (Home-Verzeichnisse) der Anwender (auch der Anwender auf den Clients) enthält.

Diese Partitionierung ist nicht bindend. Vor allem muss nicht jede Platte eine Partition für root, Swap, besitzen. Eine neue Festplatte kann völlig von einer Partition ausgefüllt werden. Sämtliche andere Partitionen können dann auf 0 gesetzt werden. Es empfiehlt sich jedoch, dafür die Slices 0-3 nicht zu verwenden. Für die Partitionierung verzweigt das Formattool in ein eigenes Untermenü. partition format> PARTITION MENU: - change ‘0’ partition 0 - change ‘1’ partition 1 - change ‘2’ partition 2 - change ‘3’ partition 3 - change ‘4’ partition 4 - change ‘5’ partition 5 - change ‘6’ partition 6 - change ‘7’ partition 7 - select a predefined table select - modify a predefined partition table modify - name the current table name - display the current table print - write partition map and label to disk label quit partition> 0,1,2,3,4,5,6,7

45


Durch Eingabe einer Partitionsnummer (0-7) kann eine Partition ausgewählt werden. Die momentane Konfiguration der Partition wird angezeigt und kann geändert werden. Die Partition-ID (Tag, vgl. prtvtoc-Kommando) muss ausgewählt werden. Sie enthält Kennzeichen für die Verwendung der Partition. Es stehen zur Auswahl: 왘 boot 왘 root 왘 Swap 왘 usr 왘 backup 왘 var 왘 home 왘 alternates 왘 unassigned

Eine Partition wird als unassigned angelegt, wenn sie mit keiner der anderen Verwendungen gefüllt werden soll. Das nun zu wählende Flag definiert die Zugriffsart auf die Partition. Folgende Zugriffsarten stehen zur Verfügung: Flag

Long-Name

Bedeutung

wm

write mountable

Kann mit mount-Kommando eingehängt werden, Schreib- und Lesezugriff

wu

write unmountable

Kann mit mount-Kommando nicht eingehängt werden, Schreib- und Lesezugriff

rm

read mountable

Kann mit mount-Kommando eingehängt werden, lediglich Lesezugriff

ru

read unmountable

Kann mit mount-Kommando nicht eingehängt werden, lediglich Lesezugriff.

Tab. 2.3: Partition-Zugriffsarten unter Solaris

Gewöhnlicherweise sollen auf Partitionen Dateisysteme angelegt werden. Diese Partitions werden in der Regel mit der Zugriffsart wm angelegt. Weiter geht es in der Konfiguration der Partition mit dem Zylinder, an dem die Partition beginnen soll und der Anzahl der Blöcke, Zylinder oder MegaBytes, die die Partition als Größe erhalten soll.

46


Hierbei können die Partitions überlappen. Dieses führt bei verwendeten Partitions zu ungeahnten Fehlern. Partitions sollten so konfiguriert werden, dass sie nicht überlappen. Die weiteren Kommandos im Partitioning-Untermenü des Formattools sind: select

Anzeige vorhandener Partition-Tabellen zur Auswahl einer bestimmten gewünschten Tabelle.

modify

Nachdem mit dem select eine Partition-Tabelle ausgewählt wurde, wird diese hier verändert. Im Wahlpunkt Free Hog Partition wird die Nummer der Partition angegeben, der der überschüssige Plattenplatz hinzugefügt werden soll. Ansonsten wird die Größe der jeweiligen Partition angegeben. Mit der Angabe eines Namens der Partition-Tabelle kann diese modifizierte Tabelle als Datei gespeichert werden (und ist damit für ein weiteres select-Kommando verfügbar). Wird bei der Schlussabfrage Ready to label disk, continue ? die Antwort »y« gegeben, so wird die Festplatte gemäß dieser Partition-Tabelle aufgeteilt. Wird die Frage mit »n« verneint, so wird lediglich die Partition-Tabelle erzeugt.

name

speichert die aktuelle Partition-Tabelle unter dem Namen ab, der nach Aufruf des name-Kommandos eingegeben wird.

print

druckt die aktuelle Aufteilung der Festplatte auf StandardOutput aus.

print partition> Current partition table (original): Total disk cylinders available: 1876 + zwei (reserved cylinders) Part Tag Flag Cylinders Size 0 root wm 0 – 111 70.55MB 1 Swap wu 112 – 188 48.50MB 2 backup wm 0 – 1875 1.15GB 3 wm 189 – 268 50.39MB 4 wm 269 – 359 57.32MB 5 wm 360 – 1269 573.19MB 6 usr wm 1270 – 1746 300.45MB 7 home wm 1747 – 1874 80.62MB

Blocks (112/0/0) (77/0/0) (1876/0/0) (80/0/0) (91/0/0) (910/0/0) (477/0/0) (128/0/0)

label

Label teilt die Festplatte nach der konfigurierten PartitionTabelle auf.

quit

beendet das Partitioning-Untermenü des Formattools.

47


Weitere Menüpunkte des Formattools analyze

untersucht die Festplatte auf Zuverlässigkeit (Bad Block Detection). Test-Möglichkeiten werden in einem Untermenü zur Auswahl angeboten.

backup

überprüft die Existenz der Backup-Partition. Diese stellt eine virtuelle Partition dar, die unter dem Namen backup auf Partition zwei angelegt wird und die komplette Festplatte überspannt.

current

gibt Informationen über die aktuell ausgewählte Festplatte, wie Hersteller, Hardwaredaten und Special File, über die die Platte angesprochen wird.

defect

zeigt an und ändert die Liste der bekannten Bad Blocks der Platte. Es wird ein eigenes defect-Untermenü angezeigt, über das mit der Funktion primary die Liste der vom HardwareFormat herstellerseitig bekannten Bad Blocks ausgewählt und über print angezeigt werden kann. In der Firmware neuerer Festplatten verwalten diese ihre Bad Blocks selbstständig.

format

überprüft die Oberfläche von Festplatten auf Bad Blocks, die seit der Hardwareformatierung durch Transport oder Verschleiß hinzugekommen sind. Danach wird beim Software-Formatieren der Platte diese mit einem Bitmuster beschrieben (entweder Low Values oder High Values). Die Funktion format des Formattools dient dieser Software-Formatierung der Festplatte. Da die Platte beim Formatieren komplett beschrieben wird, ist die Dauer des Formatierens abhängig von der Größe und Zugriffsgeschwindigkeit dieser Festplatte. Evtl. auf der Platte befindliche Daten werden durch das Formatieren gelöscht.

format> format Ready to format. Formatting cannot be interrupted. Continue? y Beginning format. The current time is April 19 17:30:12 1998 Formatting ... done Verifying media ... pass 0 – pattern = 0xc6dec6de 1875/14/2 pass 1 – pattern = 0x6db6db6d 1875/14/2 Total of 0 defective blocks repaired. format> Anschließend muss mit der Formattool-Funktion partition diese formatierte Platte partitioniert werden.

48


inquiry

gibt Herstellername und Typ der ausgewählten Festplatte aus.

label

schreibt die Partition-Tabelle und sämtliche weitere mit dem Formattool durchgeführte Konfigurationsänderungen der Festplatte in das Platten-Label (VTOC). Dieses kann mit dem Kommando prtvtoc angezeigt werden.

quit

beendet das Solaris-Formattool.

repair

untersucht einen systemseitig entdeckten Bad Block und versucht diesen zu reparieren.

save

sichert eine Partition-Tabelle und die Konfigurationsdaten der aktuellen Festplatte in eine Datei.

volname

vergibt an die Platte einen achtstelligen Namen.

verify

zeigt die Partitionierung und die Hardwaredaten der Festplatte an.

format> verify Primary label contents: Volume name = 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

esp0 (Controller)

t3

target number (Target 3 auf diesem SCSI-Controller)

d0

disk number (erste Festplatte auf diesem Target)

s7

Slice sieben (Partition Nummer 7)

49


# format

Searching for disks ... done AVAILABLE DISK SELECTIONS: 0. c0t3d0 <SUN0424 cyl 1151 alt zwei hd 9 sec 80> /sbus@l,f8000000/ esp@O,800000/sd@3,0 Specify disk (enter its number): 0 selecting c0t3d0 [disk formatted] 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 format> partition PARTITION MENU: 0 - change ‘0' partition 1 - change ‘1' partition 2 - change '2' partition 3 - change ‘3' partition 4 - change ‘4' partition 5 - change '5' partition 6 - change ‘6' partition 7 - change ‘7' partition select - select a predefined table modify - modify a predefined partition table name - name the current table print - display the current table label - write partition map and label to the disk quit partition> print Current partition table (original sd3): Total disk cylinders available: 1151 + zwei (reserved cylinders) Part Tag Flag Cylinders Size Blocks 0 root wm 0-85 30.23MB (86/0/0) 1 Swap wu 86-268 64.34MB (183/0/0) 2 backup wm 0- 1150 404.65MB (1151/0/0)

50


3 wm 269-325 20.04MB 4 unassigned wm 0 0 5 wm 326-496 60.12MB 6 usr wm 497- 1037 190.20MB 7 home wm 1038- 1150 39.73MB partition> 6 Part Tag Flag Cylinders Size Blocks 6 usr wm 497 – 1037190.20MB (541/0/0) Enter partition id tag[usr]: ? Expecting one of the following: (abbreviations ok): unassigned boot root Swap usr backup var home alternates usr Enter partition id tag [usr]: Enter partition permision flags [wm]: ? Expecting one of the following: (abbreviations ok): wm - read-write, mountable wu - read-write, unmountable rm - read-only, mountable ru - read-only, unmountable Enter partition permission flags[wml:wm Enter new starting cyl[497]: 497 Enter partition size[389520b, 541c, 190.20mb]: 600c 7 partition> Part Tag Flag Cylinders Size 7 home wm 1038 – 1150 39.73MB Enter partition id tag [home]: home Enter partition permission flags[wml: wm Enter new starting cyl[10381: 1087 Enter partition size[81360b, 113c, 39.73mb]: 64c partition> print Current partition table (unnamed): Part Tag Flag Cylinders Size 0 root wm 0-85 30.23MB 1 Swap wu 86-268 64.34MB 2 backup wm 0-1150 404.65MB 3 wm 269-325 20.04MB 4 unassigned wm 0-0 0.00 MB 5 wm 326-496 60.12MB 6 usr wm 497-1086 214.53MB 7 home wm 1087-1150 22.50MB partition> label Ready to label disk, continue? y partition> quit format> quit

(57/0/0) (0/0/0) (171/0/0) (541/0/0) (113/0/0)

Blocks (113/0/0)

Blocks (86/0/0) (183/0/0) (1151/0/0) (57/0/0) (0/0/0) (171/0/0) (600/0/0) (64/0/0)

51


2.2

Einführung in NetzwerkTechnologien

2.2.1

Standardisierungskomitees

왘 EIA – Electronic Industries Association (EIA), Organisation US-amerika-

nischer Hersteller aus der Elektronik-Industrie 왘 CCITT – Comité Consultatif International Télégraphique et Téléphoni-

que. Ein Komitee innerhalb der Internationalen TelekommunikationsUnion (ITU). Das CCITT besteht hauptsächlich aus Herstellern aus der Telekommunikationsbranche. 왘 ISO – International Standards Organization (ISO). Die ISO ist eine welt-

weit operierende (freiwillige) Vereinigung der führenden Standardisierungsorganisationen aller Mitgliedsländer (z.B. DIN, ANSI etc.). Die ISO vertritt die Anwenderinteressen. 왘 ANSI – Das American National Standards Institute (ANSI) ist vergleich-

bar mit der deutschen DIN. Es ist der Vertreter der USA in der ISO. 왘 FIPS – Federal Information Processing Standards (FIPS) sind Standards

der US-Regierungsbehörden. Das National Bureau of Standards (NBS) ist für FIPS zuständig. 왘 FTSC – Das Federal Telecommunications Standards Committee (FTSC)

entwickelt gemeinsam mit dem NBS Daten-Kommunikations-Standards für FIPS. Es steht in enger Kooperation mit CCITT, ANSI, ISO und EIA. 왘 IEEE – Das Institute of Electrical and Electronics Engineers (vergleichbar

mit der deutschen VDE) ist die US-amerikanische Vereinigung von Elektronik-Ingenieuren und -Handelsgesellschaften. Die Standardisierungs-Organisationen wurden in den sechziger und siebziger Jahren gegründet, um einheitliche elektronische/elektrische Verbindungen, die Terminologie, Protokolle und Methoden zur Vereinheitlichung verschiedener Hardware-Hersteller zu ermöglichen.

2.2.2

Netzwerk-Kommunikation

Die Kommunikation über Netzwerke besteht aus dem Senden von Daten vom Computer zum empfangenden Rechner. Dieser komplexe Prozess muss in diskrete Teilfunktionen untergliedert werden:

52

Einführung in Netzwerk-Technologien 왘 Erkennen der Daten 왘 Aufsplitten der Daten in verwaltbare Stücke 왘 Hinzufügen von Informationen zu jedem Stück hinsichtlich: 왘 Lokation der Daten, d.h. wohin gehört dieses Stück im Gesamtzusam-

menhang der übertragenen Daten 왘 Empfängererkennung, d.h. an wen werden diese Daten gesendet 왘 Hinzufügen von Informationen für zeitgerechtes Senden (Timing) und

Fehlererkennung und -behandlung 왘 Physikalisches Versenden und Übertragen der Daten auf einem physika-

lischen Netzwerk Das Netzwerk-Betriebssystem folgt strikt einem Set von Prozeduren, um jede dieser Teilfunktionen durchzuführen. Diese Verhaltensregeln werden als Protokoll bezeichnet. Daten-Kommunikations-Protokolle sind somit Standardprozeduren, die den Betrieb von Datenkommunikations-Endgeräten ermöglichen. Generell erfüllen Protokolle zwei Funktionen: 왘 Aufbau einer Verbindung zwischen Sender und Empfänger 왘 Zuverlässige Übertragung der Informationen

Es existiert heute eine Vielzahl von Protokollen, teilweise durch Standardisierungsgremien (z.B. IEEE 802.3, ISO/OSI), und teilweise durch Hersteller (z.B. IBM/SNA, IBM SNA/RJE) definiert. Zwischen den Kommunikations-Protokollen existieren eine Vielzahl von Unterschieden. So verwenden z.B. einige Protokolle lediglich ein einziges Zeichen zu Beginn einer Übertragung zur Synchronisation von Sender und Empfänger, andere wiederum eine Vielzahl von Synchronisationszeichen. Selbst bei gleicher Anzahl von Synchronisations-Zeichen verwenden doch einige Hersteller unterschiedliche Synchronisationszeichen. Im Unix-Umfeld existieren im Wesentlichen zwei Protokoll-Standards: 왘 Das ISO/OSI Referenz-Modell 왘 Das Projekt 802

Dabei stellt das Projekt 802 der IEEE eine Modifikation des ISO/OSI-Referenz-Modells dar. Beide Kommunikations-Protokoll-Familien benutzen diverse Ebenen oder Layer, die die unterschiedlichen Funktionen und Operationen definieren. Jede Ebene ist als unabhängig von den anderen Ebenen gestaltet, die Funktion einer Ebene ist jedoch auf den korrekten Ablauf der Operationen der vorausgehenden Ebene angewiesen.

53


2.2.3 2.2.3.1

Das ISO/OSI-Referenz-Modell Hinführung

Das OSI-Referenz-Modell verfolgt die Kooperation zwischen Datenkommunikations-Systemen unterschiedlicher Architektur und unterschiedlicher Hersteller. Dies beinhaltet: 왘 Koordination von Aktivitäten wie Interprozess-Kommunikation 왘 Daten-Speicherung 왘 Prozess- und Ressourcen-Verwaltung 왘 Sicherheit und Integrität 왘 Unterstützung von Anwendungsprogrammen

Dabei definiert die OSI 1978 ein System als eine Menge von einem oder mehreren Rechneranlagen, der zu diesen gehörenden Software, den Peripheriegeräten, menschlichen Einflussfaktoren, Prozessen, Anforderungen an den InformationsTransfer usw., das ein atomares, autonomes Ganzes formt, das in der Lage ist, Informationsverarbeitung und -Transfer zu gewährleisten. Die Open System Interconnection (OSI) definiert somit: Das Netzwerk als System Ein »Open System« ist ein System, das die OSI-Standards in der Kommunikation zu anderen Systemen einhält. Ein Applikations-Prozess ist ein Element innerhalb eines Systems, das Informationsverarbeitung für eine bestimmte Benutzeranwendung betreibt. Dabei kann der Applikations-Prozess manuell (eine Verkäuferin an der Scanner-Kasse), maschinell (ein laufendes Programm auf einer Client-Workstation, das auf Daten einer Server-Datenbank zugreift) oder physikalisch (ein Prozesssteuerungs-Programm auf einem Prozessleitrechner in einem Kernkraftwerk) sein. Das OSI-Referenz-Modell ist unabhängig von der internen Verarbeitung eines jeden offenen Systems. Den Austausch von Informationen zwischen offenen Systemen regelt es jedoch restriktiv. Das Modell adressiert sowohl terrestrische Telekommunikations-Geräte als auch extraterrestrische Telekommunikations-Einrichtungen (Satellitenübertragungen). Das OSI-Modell hat sieben Schichten. Folgende Prinzipien haben zu der Siebenschichtigkeit geführt: 왘 Eine neue Schicht sollte dort entstehen, wo ein neuer Abstraktionsgrad

benötigt wird. 왘 Jede Schicht sollte eine genau definierte Funktion erfüllen.

54

Einführung in Netzwerk-Technologien 왘 Bei der Funktionswahl sollte man die Definition international genormter

Protokolle im Auge behalten. 왘 Die Grenzen zwischen den einzelnen Ebenen/Schichten sollten so ge-

wählt werden, dass der Informationsfluss über die Schnittstellen möglichst gering ist. 왘 Die Anzahl an Schichten sollte so groß sein, dass keine Notwendigkeit

dafür besteht, verschiedene Funktionen auf dieselbe Schicht zu packen, und so klein, dass die gesamte Architektur nicht unhandlich wird.1

2.2.3.2

Das Schichten-Konzept des OSI-ReferenzModells

Schichtenbildung ist die grundlegende Strukturmethode des OSI-ReferenzModells. Jedes System, das dem OSI-Modell entspricht, besteht aus einem geordneten Set von Subsystemen, mit gruppierten logisch definierten und zusammengehörigen Funktionen. Im OSI-Modell existieren sieben Ebenen: Ebene

Bedeutung(Funktion)

Ebene 1

Physikalische Ebene (Bitübertragungsschicht)

Ebene 2

Daten-Verbindungs-Ebene (Sicherungsschicht)

Ebene 3

Netzwerk-Ebene (Vermittlungsschicht)

Ebene 4

Transport-Ebene (Transportschicht)

Ebene 5

Sessions-Ebene (Sitzungsschicht)

Ebene 6

Präsentations-Ebene (Darstellungsschicht)

Ebene 7

Applikations-Ebene (Anwendungsschicht)

Tab. 2.4: Die Ebenen des ISO/OSI-Referenz-Modells

Die physikalische Ebene (Bitübertragungsschicht) Die Bitübertragungsschicht (physical layer) beschäftigt sich mit der Übertragung von rohen Bits über einen Kommunikationskanal. Entwicklungstechnisch muss hier sichergestellt werden, dass, wenn die eine Seite ein Bit mit der Wertigkeit 1 schickt, dieses Bit von der anderen Seite auch als Bit mit der Wertigkeit 1 empfangen wird und nicht als Bit mit der Wertigkeit 0. Typische Fragen, die hierbei auftauchen, sind: 왘 Wie viel Volt sollten einer logischen 1 entsprechen und wie viel einer 0? 왘 Wie viele Mikrosekunden Übertragungszeit soll ein Bit dauern? 왘 Soll die Übertragung in beide Richtungen gleichzeitig erfolgen? 왘 Wie kommt die Verbindung zustande?

1.

Tanenbaum, Andrew S., Computernetzwerke, 3. Aufl., München, 2000, S. 45.

55

2 SAN – Grundlegende Basis-Technologien 왘 Wie wird die Verbindung aufgelöst? 왘 Wie viele Pins hat die Endsystemverbindung und wofür werden diese

verwendet? Die Fragen der Entwicklung beschäftigen sich hier weitgehend mit mechanischen, elektrischen und durchführungstechnischen Schnittstellen und mit dem physikalischen Übertragungsmedium, das sich unterhalb der Bitübertragungsschicht befindet. Die Entwicklung dieser Schicht kann man ruhigen Gewissens als Aufgabe eines Elektroingenieurs bezeichnen. Die Bitübertragungsschicht wird hardwareseitig durch Netzwerk-Controller, Verbindungshardware (Transceiver) und Übertragungskabel bestimmt.2 Im LAN-Umfeld werden Ethernet-Umgebungen (IEEE 802.3 mit CarrierSense Multiple Access with Collision Detection CSMA/CD) oder Token Ring-Umgebungen (IEEE 802.5 mit Token Passing-Protokoll) eingesetzt. Im MAN-Umfeld (Metropolitan Area Network) werden typischerweise FDDI-Medien verwendet. WANs (Wide Area Networks) verwenden in der Regel öffentliche Netze der lokalen PTT-Gesellschaften (X.25, ISDN, ADSL, MODEM). Gängige Übertragungsmedien sind: 왘 Twisted Pair-Kabel (verdrilltes Leitungspaar, Telefonkabel) 왘 Basisband-Koaxialkabel 왘 Breitband-Koaxialkabel 왘 Lichtwellenleiter 왘 Mikrowellenübertragung 왘 Kommunikationssatelliten 왘 Ethernet-Controller 왘 Transceiver und Transceiver-Kabel

Die Daten-Verbindungs-Ebene (Sicherungsschicht) Die wichtigste Aufgabe der Sicherungsschicht (Data Link Layer) ist es, die übertragenen Rohdaten in eine Datenreihe zu verwandeln, die ohne Übertragungsfehler an die Vermittlungsschicht weitergegeben wird. Dies wird dadurch erreicht, dass der Sender die Eingangsdaten in Datenübertragungsrahmen (Data Frames) – typisch sind einige hundert Bytes – aufteilt, diese sequentiell überträgt und die vom Empfänger erzeugten Quittungsrahmen (acknowledgement frames) verarbeiten muss.

2.

56

Vgl. Tanenbaum, a.a.O., S. 46.

Einführung in Netzwerk-Technologien

Da die Bitübertragungsschicht lediglich einen Bit-Strom annimmt und absendet, ohne sich um die Bedeutung der Struktur der Bits zu scheren, ist es Sache der Sicherungsschicht, Rahmengrenzen einzufügen und zu erkennen. Dies kann dadurch erreicht werden, dass am Anfang und Ende eines Rahmens spezielle Bitmuster gesetzt werden. Es ist darauf zu achten, dass diese Bitmuster nicht auch unerkannt im Datenteil des Rahmens vorkommen und die Übertragung daher stören könnten. Eine Bündelstörung in der Übertragungsleitung kann einen Data Frame gänzlich zerstören. In diesem Fall muss die Software auf dem Data Link Layer der Quellmaschine veranlasst werden, den Datenrahmen erneut zu übertragen. Wird ein Rahmen mehrfach übertragen, besteht die Gefahr der Frame Duplication – eine Mehrfachübertragung des gleichen Rahmens. Ein Rahmenduplikat könnte zum Beispiel gesendet werden, wenn das Acknowledgement des Empfängers zerstört ist. Die Sicherungsschicht muss also beschädigte, verlorengegangene und duplizierte Data Frames erkennen und verwalten. Weiter muss die Sicherungsschicht auf die Datenüberschwemmung reagieren, falls ein Sender schneller ist als sein Empfänger. Daher benötigt die Sicherungsschicht eine Regelung, die dem Sender freie Pufferkapazitäten des Empfängers mitteilt. Diese Regelung des Datenflusses und eine Fehlerbehandlung im Fall der Datenüberschwemmung werden von der Sicherungsschicht übernommen. Wenn die Übertragungsleitung in beide Richtungen zu verwenden ist, muss der Quittungsrahmen des Empfängers mit dem Senderahmen des Senders um die Leitungskapazität der Bitübertragungsebene konkurrieren. Diese Problematik wird von der Sicherungsebene durch den Piggy Back-Transfer gelöst.3

Protokolle des Data Link Layers Der Data Link Layer wird von den Protokollen der MAC-Teilschicht im Netzwerk definiert. 왘 LAPB (Link Access Procedure Broadband für X.25) 왘 LAPD (Link Access Procedure Digital für ISDN) 왘 ETHERNET Version 2 왘 ETHERNET IEEE 802.3 왘 Token Ring IEEE 802.5 왘 Token Bus IEEE 802.4

3.

Vgl. Tanenbaum, a.a.O., S. 46 f.

57


Das Protokoll der MAC-Teilschicht bei IEEE 802.3 Abbildung 2.2: Das Protokoll der MAC-Teilschicht bei IEEE 802.3

Präambel 7 Bytes

1

Zieladresse

Quelladresse

2

Daten

0-46 Prüfsumme

Bit 2 oder 6 Bytes 2 oder 6 Bytes Bits 0-1500 Bytes Bits 4 Bytes

Jeder Rahmen unter IEEE 802.3 beginnt mit einer Präambel von sieben Bytes, die jeweils die Bitfolge 10101010 enthalten. Die Manchester-Kodierung dieser Bitfolge erzeugt für die Dauer von 5,6 Mikrosekunden eine 10MHz-Schwingung, wodurch sich der Taktgeber des Empfängers mit dem des Senders synchronisieren kann. Als Nächstes folgt ein Byte zur Markierung des Rahmenstarts mit der Bitfolge 10101011, um den Anfang des Rahmens zu markieren. Die Norm lässt für Startadresse und Zieladresse zwei oder sechs Bytes Länge zu. Das Zehn-MHz-Breitband Thick Ethernet verwendet jedoch nur sechs Bytes lange Adressen. Das High Bit der Zieladresse (Bit 47) ist von der Wertigkeit 0 für normale Adressen und der Wertigkeit 1 für Gruppenadressen. Durch eine Gruppenadressierung können mehrere Ziele Daten von einer einzigen Adresse empfangen. Wird ein Data Frame an eine Gruppenadresse geschickt, so empfangen ihn alle Endgeräte der Gruppe. Das Senden an eine Gruppe von Endgeräten wird Multicasting genannt. Die Adresse, die nur aus Einsen besteht, ist für ein Senden an alle Endstationen reserviert, das Broadcasting. Ein Frame, der im Feld der Zieladresse lediglich Einsen enthält, wird an alle Stationen im Netzwerk geschickt und durch sämtliche Bridges weitergeleitet. Weiter kann Bit 46 zur Unterscheidung von lokalen und globalen Adressen verwendet werden. Lokale Adressen werden vom Netzwerk-Administrator vergeben und haben außerhalb des LAN keine Bedeutung. Globale Adressen hingegen werden von der IEEE vergeben, um sicherzustellen, dass nirgendwo auf der ganzen Erde zwei Stationen die gleiche globale Adresse haben (da 48-2 = 46 Bits zur Verfügung stehen, gibt es ungefähr 7x1013 Adressen). Dadurch kann eine Station jede andere Station exakt durch die richtige 48-Bit-Nummer adressieren. Das Finden des Ziels ist Aufgabe der Vermittlungsschicht. Das Feld Länge gibt an, wie viele Bytes das Datenfeld enthält, wobei dieser Wert zwischen 0 und 1.500 liegen kann. Ein Datenfeld von 0 Bytes Länge ist zwar legal, würde jedoch im Zusammenhang mit dem Trash-Management der Bitübertragungsebene zu einem Problem führen. Ein Transceiver schneidet nämlich stets den aktuellen Rahmen ab, wenn er eine Kollision auf dem Datenübertragungsmedium feststellt, weswegen dort häufig einzelne nicht terminierte Bitfolgen und Bruchteile von Rahmen übertragen werden. Um eine Unterscheidung zwischen diesem Müll und gültigen Data Frames zu ermöglichen, definiert IEEE 802.3, dass ein gültiger Rahmen von der Zieladresse bis zur Prüfsumme mindestens 64 Bytes lang sein muss.

58


Falls der Datenteil eines Frames kleiner als 46 Bytes ist, füllt das PAD-Feld den Rahmen bis zum Minimum auf. Ein weiterer Grund für die minimale Rahmenlänge ist, zu verhindern, dass eine Station die Übertragung eines kurzen Rahmens beendet, bevor sein erstes Bit überhaupt das andere Ende des Kabels erreicht hat, wo er dann evtl. mit einem anderen Data Frame kollidiert. Das letzte Feld ist die Prüfsumme. Dabei handelt es sich um einen 32-BitHashcode der Daten. Ändern sich die Bits aufgrund von Problemen in der Bitübertragungsschicht, ist diese Prüfsumme höchstwahrscheinlich falsch, sodass der Fehler entdeckt wird. Beim Prüfsummenalgorithmus handelt es sich um eine zyklische Redundanzprüfung.4

Protokolle in lokalen Netzwerken5 왘 Persistentes (ständiges) CSMA 왘 Non-persistentes (unterbrochenes) CSMA 왘 p-ständiges CSMA 왘 CSMA mit Kollisionserkennung

Persistentes CSMA Protokolle, bei denen Stationen einen Träger (Carrier) abhören und je nach dessen Zustand handeln, heißen Trägererkennungs-Protokolle (carrier sense protocols). Das erste Trägererkennungs-Protokoll ist das 1-ständige CSMA (1-persistent Carrier Sense Multiple Access). Will ein Endgerät Daten übertragen, so hört es zunächst den Träger ab, ob bereits jemand überträgt. Ist der Kanal besetzt, wartet das Endgerät, bis er frei ist. Entdeckt das Endgerät einen freien Carrier, wird der Datenframe übertragen. Kommt es zu einer Kollision, wartet das Endgerät eine zufällige Zeitspanne und beginnt den Prozess von Neuem. Das Protokoll heißt 1-ständig, da das Endgerät mit einer Wahrscheinlichkeit von 1 sendet, wenn der Kanal frei ist. Unterbrochenes (Non-persistentes) CSMA Bei non-persistentem CSMA wird bewusst der Versuch unternommen, das Netzwerk auf Kosten der Geschwindigkeit bei der Einzelstation sozialer und geschwindigkeitsoptimiert für die Summe der Endgeräte des LAN zu nutzen. Vor dem Senden überprüft eine Station den Kanal. Wenn keine weitere Station sendet, beginnt das Endgerät mit dem Senden. Ist der Carrier jedoch bereits belegt, lauscht die Endstation nicht ununterbrochen auf den Carrier, 4. 5.

Vgl. Tanenbaum, a.a.O., S. 204 ff. Vgl. Tanenbaum, a.a.O., S. 268 ff.

59


um das Ende des Sendens zu erwarten und danach sofort selbst zu senden, sondern wartet einen zufälligen Zeitraum und wiederholt dann den Vorgang. Dieser Algorithmus führt zu besserer Kanalauslastung und längeren Wartezeiten als das persistente CSMA. p-ständiges CSMA p-ständiges CSMA gehört zu den getakteten Kanal-Protokollen und überprüft den Carrier, wenn es senden will. Ist der Kanal frei, sendet das Endgerät mit einer Wahrscheinlichkeit von p. Mit einer Wahrscheinlichkeit von q = 1-p wartet die sendende Station auf den nächsten Slot. Ist auch dieser Slot frei, wird entweder gesendet oder gewartet, wiederum mit den Wahrscheinlichkeiten q und p. Dieser Vorgang wiederholt sich, bis der letzte Data Frame übertragen ist oder ein anderes Endgerät zu senden begonnen hat. Daraufhin wird wie bei einer Kollision reagiert, d.h. ein zufälliger Zeitraum wird gewartet, danach beginnt der Prozess von Neuem. CSMA mit Kollisionserkennung Die CSMA-Protokolle sind eine Verbesserung zuvor entwickelter ALOHAProtokolle, weil 왘 keine Station sendet, wenn der Kanal als belegt erkannt wird; 왘 die Übertragung abgebrochen wird, sobald eine Kollision erkannt wird.

Wenn zwei Endgeräte den Kanal als frei erkennen und gleichzeitig zu senden beginnen, erkennen beide nahezu sofort die Kollision. Statt nun die Übertragung der ohnehin zerstörten Data Frames zu beenden, sollten sie die Übertragung abbrechen, sobald eine Kollision entdeckt wurde. Eine solche sofortige Übertragungsbeendigung bei beschädigten Rahmen spart Zeit und Kanalauslastung. Dieses Protokoll Carrier Sense Multiple Access with Collision Detection (CSMA/CD) wird in den Ethernet-Implementierungen in der MAC-Teilschicht verwendet. CSMA/CD ist im Ethernet-Controller implementiert.

Die Vermittlungsschicht (Network Layer)6 Die wesentliche Funktion der Vermittlungsschicht ist die optimale Wegeplanung vom Sender zum Empfänger. Sie steuert den Subnet-Betrieb. Dabei ist die wichtigste Tätigkeit die Auswahl der Paketleitwege vom Ursprungszum Bestimmungsort. Die Leitwege können auf statischen Tabellen aufgebaut sein, die im Netzwerk fest verdrahtet sind und sich nur selten ändern. Sie können jedoch auch vor Beginn einer Übertragung dynamisch ermittelt werden. Letztlich könnten sie auch für jedes gesendete Paket hochdynamisch ermittelt werden, um so eine optimale Netzauslastung zu gewährleisten.

6.

60



Befinden sich zu viele Pakete gleichzeitig im Subnet, kommt es zu Engpässen. Der Network Layer muss auch solche Staus auflösen und steuern können. Die Vermittlungsschicht beinhaltet in der Regel auch eine Accounting-Funktion, um Kosten der Subnet-Nutzung abzurechnen. Es können auch Probleme entstehen, wenn ein Paket auf seinem Weg zum Bestimmungsort von einem Netzwerk zu einem anderen reisen muss. Es könnte zum Beispiel sein, dass die Adressierung beim zweiten Netzwerk anders ist als beim ersten. Das zweite Netzwerk könnte das Paket ablehnen, weil es z.B. zu groß ist. Weiter könnten die Protokolle der beiden Netzwerke verschieden sein. Sämtliche Probleme dieser Art müssen von der Vermittlungsschicht erkannt und behoben werden, um heterogene Netzwerke miteinander kommunizieren zu lassen. Bei Broadcasting-Netzwerken ist das Problem der Leitwegbestimmung einfach. Daher ist dort die Vermittlungsschicht lediglich leicht oder gar nicht implementiert. Wesentliche Protokolle der Netzwerkschicht sind: 왘 IP (Internet Protocol) vgl. Abschnitt TCP/IP 왘 IPX (Novell) 왘 CLNP (OSI)

Die Transportschicht (Transport Layer)7 Die Transportschicht übernimmt die Daten von der Sitzungsschicht, zerlegt sie, falls nötig, in kleinere Einheiten, gibt diese danach an die Vermittlungsschicht weiter und sorgt dafür, dass alle Teile richtig am anderen Ende ankommen. Dies muss effizient und so implementiert werden, dass die Sitzungsschicht transparent vor Änderungen der Hardware-Technologie verborgen und so geschützt wird. Normalerweise baut die Transportschicht für jede von der Sitzungsschicht benötigte Transportverbindung eine eigene Netzwerkverbindung auf. Wenn die Transportverbindung jedoch einen hohen Durchsatz erfordert, könnte die Transportschicht auch mehrere Netzwerkverbindungen aufbauen und die Daten zur Erhöhung des Durchsatzes auf diese Verbindungen verteilen. Die Transportschicht könnte auf der anderen Seite mehrere Transportverbindungen auf einer Netzwerkverbindung zusammenfassen, wenn der Aufbau oder die Aufrechterhaltung einer Netzwerkverbindung eine Kostenfrage darstellt. In jedem dieser Fälle ist die Transportschicht dafür verantwortlich, die Mehrfachnutzung für die Sitzungsschicht transparent zu machen.

7.


61


Die Transportschicht bestimmt ebenfalls die Art des Dienstes, der der Sitzungsschicht und damit letztendlich dem Netzwerkbenutzer zur Verfügung gestellt wird. Die gebräuchlichste Art der Transportverbindung ist eine fehlerfreie Standleitung (Point-to-Point-Channel), in der Nachrichten in der Sendereihenfolge übertragen werden. Die Art des Dienstes wird zum Zeitpunkt des Verbindungsaufbaus gewählt. Die Transportschicht ist eine echte Ende-Ende- oder Ursprung-zu-Ziel-Verbindung, d.h. die Transportschicht der Sendermaschine kommuniziert direkt mit der Transportschicht der Empfängermaschine. Dabei werden die Nachrichtenköpfe und Steuernachrichten der Transportschicht verwendet. In den niedrigeren Schichten bestehen diese Protokolle zwischen den unmittelbaren Nachbarn im Netz, jedoch nicht unbedingt zwischen Sender und Empfänger. So gibt es den Unterschied zwischen geketteten (pointered) Schichten (Schicht 1 bis 3) und den Ende-Ende-Schichten (Schicht 4 bis 7). Im Multiprogramming-Betrieb können viele Verbindungen zum und vom Server aufgebaut werden. Daher ist es notwendig zu identifizieren, zu welcher Verbindung welche Nachricht gehört. Dies erfolgt im Transport-Header, der den Daten der Transportschicht vorangestellt wird. Außer der Regel der Mehrfachnutzung eines Kanals durch mehrere Nachrichtenströme muss die Transportschicht sich auch noch um den Aufbau und die Auflösung von Verbindungen durch das Netzwerk kümmern. Eine Art Benennungsalgorithmus ist nötig, damit ein Prozess auf einer Maschine die Möglichkeit hat, zu beschreiben, mit wem er kommunizieren will. Weiter muss ein Regulativ für den Informationsfluss vorhanden sein, damit ein schneller Sender nicht einen langsamen Empfänger überholen kann. Als Protokolle der Transportschicht werden eingesetzt: 왘 TCP, UDP (vgl. TCP/IP-Abschnitt) 왘 SPX(Novell) 왘 TP-0 bis TP-4 (OSI)

Das Transmission Control Protocol (TCP) verwendet Dienste, die verbindungsorientiert arbeiten. Dabei wird jedes ankommende Paket quittiert. Durch das Acknowledgement weiß der Sender, welche Pakete beim Empfänger angekommen sind. Das User Datagram Protocol (UDP) verzichtet auf das Acknowledgement der empfangenen Pakete durch den Empfänger. Dadurch bezeichnet man UDP als unreliable service.

62


Die Adressierung der Nachricht zur Verbindung an den Server im Transport-Header erfolgt über die Port-Nummer des Prozesses. Über solche Sockets kommunizieren wesentliche Client-/Server-Applikationen, z.B. Datenbank-Applikationen mit relationalen Datenbank-Management-Systemen wie CA-Ingres, Adaptive Server Enterprise (Sybase) oder Microsoft SQLServer. Die Port-Nummer und der verwendete Dienst werden unter Unix-Betriebssystemen in /etc/services eingetragen.

Die Sitzungsschicht (Session Layer)8 Der Session Layer ermöglicht es Anwendern verschiedener Computer, Sitzungen zu vereinbaren, in denen – wie auch bei der Transportschicht – normaler Datentransfer vonstatten gehen kann, jedoch auch zusätzliche Dienste angeboten werden, wie z.B. die Vermittlung zum Time-Sharing eines entfernten Rechners (virtuelles Terminal, virtueller Prozess, virtueller Prozeduraufruf). Einer der verwendeten Dienste ist die Dialogsteuerung. Es gibt Sitzungen, bei denen der Verkehr in beide Richtungen gleichzeitig möglich ist, und auch solche, bei denen der Verkehr lediglich in eine Richtung möglich ist. Bei einer unidirektionalen Sitzung definiert die Sichtungsschicht, wer der beiden Teilnehmer gerade mit seiner Sendung an der Reihe ist. Ein ähnlicher Dienst ist das Token-Management. Bei manchen Protokollen ist es von grundlegender Bedeutung, dass nicht beide Seiten gleichzeitig dieselbe Operation einleiten. Von der Sitzungsschicht bereitgestellte Tokens, die ausgetauscht werden können, regeln diese Problemstelle, denn nur die Seite, die gerade über das Token verfügt, darf die fragliche Operation ausführen. Ein weiterer Sitzungsdienst ist die Synchronisierung. Die Sitzungsschicht liefert dabei Checkpoints für lange Datenübertragungen, auf denen bei einem Absturz der Empfängerseite nach deren Wiederanlauf wiederaufgesetzt werden kann, statt die komplette Übertragung wiederholen zu müssen. In der Sitzungsschicht werden häufig Remote Procedure Calls zur Client-/ Server-Kommunikation verwendet. RPCs werden im Wesentlichen in physikalischen »remote«-Umgebungen eingesetzt, d.h. die Client-Anwendung läuft auf einem physikalisch anderen Rechner als die Server-Anwendung. Remote Procedure Calls sind gekennzeichnet durch: 왘 Aufruf der Serverfunktionen aus einer Client-Applikation 왘 Direkten Funktionsaufruf im Datenstrom 왘 Verwendung von Stubs

8.


63


Dabei ruft der RPC das remote Programm auf mit: 왘 Programmnummer 왘 Versionsnummer 왘 Prozedurnummer

Dies erfolgt im direkten Funktionsaufruf im Datenstrom, d.h. die Nachricht besteht aus dem Aufruf der remote-Funktion und der Übergabe sämtlicher benötigter Argumente. Die Sitzungsschicht des Servers wandelt die Ergebnisse in eine Nachricht um und übergibt sie der Sitzungsschicht des Clients. Stubs sind Runtime Libraries mit Methoden zur Erstellung von Nachrichten für das Netzwerk-Interface und den Server, die den Funktionsaufruf in den verständlichen Datenstrom umwandeln. Diese Datenbasis sowie das Mapping der Prozesse auf Ports übernimmt in der Sitzungsschicht der Portmapper. Dieser muss vor sämtlichen anderen RPC-Servern gestartet werden. Der Portmapper ist selbst ein RPC-Server mit der Port-ID 111. Sämtliche andere RPC-Server registrieren sich beim Portmapper mit ihrer eigenen Port-ID. RPC-Clients holen sich in der Datenbasis des Portmappers die Port-ID des Servers, mit dem sie kommunizieren wollen, und bauen dann eine Ende-Ende-Verbindung zu diesem RPC-Server auf. Dienste, die der Portmapper verfügbar macht, sind unter Unix mit dem Kommando rcpinfo abzufragen. Der Dienstname wird auf die Port-ID mit der Datei /etc/rpc gemapped. Diese Dienstnamen können beim RPC-Aufruf auch anstelle der Programmnummer verwendet werden. Beispiele für rcpinfo rpcinfo -p LUEGFIX

liefert für den Server LUEGFIX: program

Programmnummer jedes momentan registrierten Dienstes

vers

Versionsnummer jedes momentan registrierten Dienstes

proto

Protokollname (udp oder tcp) jedes momentan registrierten Dienstes

port

Port-ID eines jeden momentan registrierten Dienstes

service

Programmname jedes momentan registrierten Dienstes

Die Darstellungsschicht (Presentation Layer)9 Der Presentation Layer stellt im Wesentlichen bereits eine funktionale Schicht für Anwendungsfunktionen dar. Er führt diverse Funktionen durch, deren häufiges Auftreten eine standardisierte Lösung rechtfertigen, anstatt 9.

64



es dem Anwendungsentwickler zu überlassen, die funktionalen Probleme dieser Ebene zu lösen. Die bisher betrachteten fünf Ebenen des ISO/OSIModells sind auf die korrekte binäre Übertragung von Strings zu den jeweiligen Ebenen bedacht. Die Darstellungsschicht hat dagegen auch für die Syntax der übertragenen Informationen und die Semantik der übertragenen Informationen eine Schlüsselfunktion inne. Ein typisches Beispiel für Dienste der Präsentationsebene des ISO/OSIModells ist die standardisierte Kodierung der zu übertragenden Informationen. Anwenderprogramme tauschen keine Informationen in Form beliebiger Binär-Zeichenketten aus, sondern strukturierte Daten wie Namen, Orte, Zahlen, Gleitkommazahlen, Termindaten, Geldbeträge etc. Diese Attribute sind durch strukturierte Datentypen beschrieben, eben Zeichenketten, ganze Zahlen, Gleitkommazahlen oder zusammengesetzte abstrakte Datentypen, die ihrerseits aus weniger komplexen Datentypen zusammengesetzt sind. Weiter existieren von der Hardware-Architektur abhängige Unterschiede in der Kodierung von Zeichen und Zahlen, z.B. am weitesten verbreitet im PCUmfeld und im Bereich der mittleren Datentechnik der ASCII-Code oder im Mainframe-Umfeld der IBM-Welt der EBCDIC-Code. Um nun solch heterogene Hardware- und Code-Architekturen miteinander kommunizieren zu lassen, übernimmt die Darstellungsebene die Aufgabe, die auszutauschenden Informationen nochmals in einen für beide verständlichen Netzwerkcode XDR zu konvertieren. Hierbei werden die Code-Basisdatenstrukturen in XDR-Datenstrukturen und umgekehrt transferiert. Auf Basis von XDR oder RCP funktioniert z.B. NFS (Network-Filesystem) von SUN, das von nahezu jedem anderen Hersteller der Unix-Umgebung heute adaptiert wurde. Als zusätzliche Funktionen des Presentation Layer sind also zu nennen: 왘 Konvertierung heterogener Codetabellen (ASCII, EBCDIC) in eine Stan-

dard-Netz-Codetabelle durch XDR 왘 Durchführung von Datenkomprimierung 왘 Verschlüsselung und Kryptographie der zu übertragenden Informa-

tionen

Die Anwendungsschicht10 Der Application Layer, die Anwendungsebene der ISO/OSI-Netzwerkarchitektur, besteht aus »Myriaden« häufig benötigter Protokolle. Erwähnt seien hierbei allein die Hunderte von nicht kompatiblen Bildschirmarten. Zu erwähnen ist dabei die leidige Terminaleinstellung für die Verwendung von Anwendungsprogrammen und die Anwendung von Datenbankwerkzeugen unterschiedlicher Datenbankhersteller. Mit welchen Funktionstasten kann in welchem Werkzeug gelöscht, eingefügt, gespeichert oder das Dienstprogramm verlassen werden? 10. Vgl. Tanenbaum, a.a.O., S. 50.

65


Diese Probleme können durch die Definition eines virtuellen Terminals im Netzwerk gelöst werden, das sämtliche Funktionen aller verfügbaren realen Terminals aufeinander mapped. Die Software für virtuelle Terminals befindet sich in der Anwendungsschicht. Weiter bedient die Anwendungsschicht den Dateitransfer, indem Inkompatibilitäten hinsichtlich Dateinamen, Textdarstellung etc. beseitigt werden. Ebenfalls werden in der Anwendungsschicht im Wesentlichen die Dienste der elektronischen Post, der Remote-Funktionsaufrufe (Remote Job Entry), der Abfrage entfernter Verzeichnisse etc. durchgeführt. Die von der Anwendungsschicht verwendeten/unterstützten Protokolle sind in Unix-Umgebungen im Wesentlichen: 왘 SMTP (Simple Mail Transfer Protocol) 왘 FTP (File Transfer Protocol) 왘 TELNET (Remote Terminal Protocol) 왘 NFS (Network File System) 왘 SNMP (Simple Network Management Protocol)

Somit stellt die Anwendungsschicht die von den Anwendern direkt aufzurufenden Dienste zur Verfügung. Dienste werden unterschieden in: RPC-Dienste

NIS, NIS+, rstatd (remote statistics), mount-demon, lock-manager

Nicht-RPC-Dienste

rlogin, rcp, rsh, mail, ftp, telnet, rwho, nfsd-demon

RPC-Dienste werden über feste Programm- und dynamische Port-Nummern identifiziert, nicht-RPC-Dienste verwenden lediglich eine feste PortNummer.

Die Datenübertragung im OSI-Modell11 Die Datenübertragung im ISO/OSI-Modell lässt sich wie folgt beschreiben. Der Senderprozess gibt die zu übertragenden Daten an die Anwendungsschicht, die den Daten den Anwendungs-Header (AH – Anwendungsnachrichten-Kopfdaten) hinzufügt. Der vorangestellte Anwendungs-Header und die zu übertragenden Daten werden nun als Einheit an die Darstellungsebene weitergegeben. Nach der Transformation inkompatibler Daten- und Codetypen stellt die Darstellungsebene der Einheit aus Anwendungs-Header und Daten noch den Presentation-Header (PH) voran und übergibt nun diese Einheit an die nächst niedrige Schicht, die Sitzungsschicht. Diese fügt nach Durchführung ihrer Funktionen den Session-Header (SH) vorne an und übergibt alles an die Transportebene. Diese führt ihre Aufgaben durch und fügt den Transport-Header (TH) hinzu. Die Vermittlungsschicht addiert den Network-Header (NH), die Sicherungsschicht fügt den Data11. Vgl. Tanenbaum, a.a.O., S. 50 ff.

66


Link-Header (DH) an den Beginn der Einheit und den Data-Link-Trailer (DT) an das Ende der Einheit hinzu. Diese komplette Einheit wird vom Physical Layer, der Bitübertragungsschicht, an den Empfänger übertragen und dann von Ebene zu Ebene nach oben gereicht, wobei die jeweilige Empfängerebene die entsprechenden Trailer und Header der gleichen Senderebene liest und beachtet. So ist es implementiert, dass obwohl physikalisch die Kommunikation zwischen Sender und Empfänger stets vertikal über sämtliche Ebenen des Netzwerk-Modells erfolgt, scheinbar doch jede Ebene des Senders sich mit der ihr entsprechenden Ebene des Empfängers direkt austauscht.

2.2.4 2.2.4.1

Das Internet-Protokoll Einführung in das Internet-Protokoll

TCP/IP beinhaltet in aller Regel folgende kernel-basierende Protokolle: 왘 ARP – Address Resolution Protocol

Das ARP wird dazu verwendet, eine Internetadresse einer physikalischen Hardwareadresse (Ethernet-Adresse) zuzuordnen. 왘 RARP – Reverse Address Resolution Protocol

Das RARP wird von einem Diskless Client verwendet, um zum Systemstart seine Internetadresse zu erhalten. 왘 Ein Diskless Client sendet in das Netz eine Anforderung, die seine

eigene Ethernet-Adresse enthält. Der Server antwortet, indem er dem Client dessen Internetadresse an seine Ethernet-Adresse schickt. 왘 IP – Internet Protocol

Das Internet Protocol bietet den verbindungslosen Austausch von Datagrammen zwischen Hosts. Dabei bedeutet verbindungsloser Dienst, dass das Protokoll jedes Datagramm als eigenständige Einheit behandelt. Jedes IP-Datagramm enthält die Adresse seines Senders und die seines Empfängers, einige KontrollInformationen (Headers) sowie die zu übertragenden Daten. IP kann Pakete in falscher Reihenfolge schicken, Pakete verlieren und auch Pakete doppelt übertragen. IP definiert zwar ein exaktes Format der Daten, in dem diese durch das Netzwerk verschickt werden, garantiert jedoch nicht die akurate Auslieferung versendeter Daten. 왘 ICMP – Internet Control Message Protocol

Das ICMP betreibt in »Partnerschaft« mit IP die Fehlerbehandlung und das Versenden/Empfangen von Control-Messages. Gateways und Hosts verwenden ICMP, um sich gegenseitig Probleme beim Übertragen von Datagrammen mitzuteilen. ICMP ermöglicht weiter einem Host zu testen, ob ein Empfänger erreichbar ist und ob er antwortet.

67

2 SAN – Grundlegende Basis-Technologien 왘 TCP – Transmission Control Protocol

TCP definiert eine zuverlässige, am Datenstrom orientierte Prozess-zuProzess-Kommunikation. TCP ist ein verbindungsbasierendes Protokoll. Es benötigt eine Verbindung zwischen zwei Computern, bevor es Daten überträgt. Nachdem eine Verbindung aufgebaut wurde, bietet TCP einen Byte-Strom in beide Richtungen zwischen zwei kommunizierenden Prozessen. Die Nachrichten von TCPs enthalten eine Protokoll-Port-Nummer, die dem Sender ermöglicht, zwischen unterschiedlichen Protokollen auf dem entfernten Rechner zu unterscheiden. Weiter verwendet TCP einen Checksummen-Algorithmus, um sicherzustellen, dass die Daten korrekt beim Empfänger angekommen sind. TCP verwendet IP, um Informationen über ein Netzwerk zu verteilen. 왘 UDP – User Datagram Protocol

UDP definiert eine auf Datagrammen basierende Kommunikation zwischen einem Prozess auf einem sendenden Host und einem Prozess auf einem empfangenden Host. UDP ist ein verbindungsloses Transport-Protokoll. Seine Nachrichten beinhalten eine Protokoll-Port-Nummer, die dem Sender die Unterscheidung zwischen unterschiedlichen Programmen des Remote-Rechners erlaubt. UDP verwendet in der Regel ebenfalls einen ChecksummenAlgorithmus, um die korrekte Ablieferung gesendeter Datagramme zu gewährleisten. UDP verwendet ebenfalls IP, um Informationen über ein Netzwerk zu verschicken.

2.2.4.2

Internetadressen (IP-Adressen)

Internet Protocol-Adressen werden verwendet, um Computersysteme innerhalb von TCP/IP-Netzwerken zu adressieren. Daher muss jede IP-Adresse, die einem Computersystem zugewiesen wird, innerhalb des Netzwerks eindeutig sein, eine IP-Adresse besteht stets aus zwei Teilen: 왘 Netzwerk 왘 Host

Jeder der beiden Bestandteile der IP-Adresse eines Rechners kann unterschiedlich lang sein, die komplette IP-Adresse hat jedoch in der zurzeit gültigen Version 5 des Internet-Protokolls eine fixe Länge von vier Bytes. Da die Adressteile in ihrer Länge variieren können, werden die Netzwerk- und die Hostadresse durch die Konvention der Adressklassen identifiziert. CLASS A-Adressen: Class A verwendet das erste Byte als Netzwerkadresse, die folgenden drei Bytes als Hostadresse. Dabei wird das höchste Bit des ersten Bytes auf 0 gesetzt. Dadurch beschränkt sich der Adressbereich auf Werte zwischen 0 und 127. Beispiel einer CLASS A-Adresse: 119.110.2.3

68


CLASS B-Adressen: Class B verwendet die ersten beiden Bytes für die Netzwerkadresse, die beiden hinteren Bytes als Hostadresse. Dabei werden die beiden höchsten Bits des ersten Bytes auf 1 und 0 gesetzt. Dies resultiert in einem Adressbereich von 128 bis 191. Beispiel einer CLASS B-Adresse: 190.100.2.3 CLASS C-Adressen: Class C verwendet die ersten drei Bytes als Netzwerkadresse, das letzte Byte als Hostadresse. Hier werden die beiden höchsten Bits des ersten Bytes jeweils auf 1 gesetzt, das dritthöchste Bit des ersten Bytes wird auf 0 gesetzt. Dies resultiert in einem Adressbereich von 192 bis 223. Beispiel einer CLASS C-Adresse: 221.31.3.1 Die maximale Anzahl von Netzwerken oder Rechnern innerhalb eines Netzwerks kann anhand der Adressklasse und damit anhand der IP-Adresse ermittelt werden. CLASS A:

Maximal 16.777.214 Rechner je Netzwerk bei maximal 127 Netzwerken

CLASS B:

Maximal 16.128 Netzwerke mit je maximal 65.534 Rechnern

CLASS C:

Maximal 2.015.775 Netzwerke mit je maximal 254 Rechnern

2.2.4.3

IP-Broadcast-Adressen

IP Broadcast-Adressen werden dazu verwendet, Mitteilungen an sämtliche Hosts eines Netzwerks zur gleichen Zeit zu versenden. Das Format einer IP Broadcast-Adresse besteht aus dem Netzwerk-Teil der IPAdresse gefolgt von lauter 1 (neuer Standard) oder lauter 0 (alter Standard). Verwendet ein Rechner z.B. die IP-Adresse 131.100.4.1 (CLASS B-Adresse), so lautet die Broadcast-Adresse entweder 131.100.255.255 (neuer Standard) oder 131.100.0.0 (alter Standard).

2.2.4.4

Subnetting

Subnets werden dazu verwendet, mehre physikalische Netzwerke zu einem logischen Netzwerk zusammenzufassen. Ein in Subnets untergliedertes Netzwerk wird durch eine Internet-Netzadresse adressiert. Innerhalb des aus Subnets zusammengesetzten Netzwerks definieren einige Bits der Hostadresse das individuelle Subnet. Dies bezeichnet man als die Netmask des Subnets. Je nachdem, wie die Netmask gesetzt ist, werden die Bits des Hostadressenteils der IP-Adresse in zwei Teile untergliedert:

69

2 SAN – Grundlegende Basis-Technologien 왘 Subnet 왘 Host

Verwendet ein Rechner beispielsweise die IP-Adresse 165.131.2.1 (CLASS BAdresse) und die Netmask 255.255.255.0, so wird die IP-Adresse wie folgt interpretiert: Netzwerkadresse:

165.131

Subnetadresse:

2

Rechneradresse:

1 (Hostadresse im Subnet)

Im Folgenden soll exemplarisch am Betriebssystem Solaris (2.x) von Sun das Setup von TCP/IP in Unix-Umgebungen dargestellt werden.

2.2.4.5

TCP/IP-Setup – Solaris 2.x

Auf Solaris-Systemen kann die TCP/IP-Konfiguration während der Systeminstallation systemunterstützt erfolgen oder nach der Installation des Systems »manuell«. Dazu müssen folgende Schritte (Aufgaben) durchgeführt werden: 왘 Falls der Hostname nicht bereits gesetzt ist, muss er mit dem Kommando

hostname gesetzt werden. 왘 Durch Editieren mit dem Texteditor vi oder mithilfe des admintool müs-

sen Hostname und IP-Adresse in /etc/hosts eingetragen werden. 왘 Mit ifconfig muss die Netzwerk-Schnittstelle konfiguriert werden.

Name des Ethernet-Controllers Für Sun-Systeme ist eine Vielzahl von Ethernet-Controllern verfügbar. Für Workstations sind LANCE Ethernet-Controller am häufigsten. Die Abkürzung des Devices für diesen Typ Ethernet-Controller ist le0 für den ersten Controller, le1 für den zweiten usw.

Kommandos für das TCP/IP-Setup # hostname

Das Kommando hostname wird verwendet, um den Rechnernamen anzuzeigen und zu setzen.

# ifconfig

Das Kommando ifconfig wird verwendet, um die IPAdresse, die IP-Broadcast-Adresse und die Netmask eines Ethernet-Controllers zu setzen.

Wird TCP/IP während des Boot-Prozesses konfiguriert, so werden diese beiden Kommandos in einem der Startup-Scripts ausgeführt (vgl. unten: Start von TCP/IP während des Boot-Prozesses). Das Kommando hostname wird verwendet, um den Rechnernamen des Systems anzuzeigen oder zu setzen:

70


# hostname

maestria # hostname lucifer # hostname

lucifer Das Kommando ifconfig wird verwendet, um die Konfiguration einer Schnittstelle anzuzeigen oder eine Schnittstelle (Controller) komplett zu konfigurieren. Syntax: ifconfig interface [IP-Adresse netmask Subnet-Maske broadcast BroadcastAdresse if-Status] Dabei haben die Optionen des Kommandos folgende Bedeutung: interface

Name der Schnittstelle (in der Regel Ethernet-Controller), z.B. le0 für den ersten LANCE Ethernet-Controller.

IP-Adresse

IP-Adresse, die für die Schnittstelle eingetragen (konfiguriert) werden soll. Beispiel: 191.113.3.1

netmask

Netzmaske, die für die Schnittstelle verwendet werden soll. »+« Subnet-Maske bedeutet, dass der Wert für die Netmask aus der Datei /etc/netmasks genommen wird. Beispiel: 255.255.255.0

broadcast

Die für die Schnittstelle zu setzende Broadcast-Adresse. »+«Broadcast-bedeutet, dass der Wert für die Netmask aus der Datei /etc/netmasks Adresse genommen wird. Beispiel: 165.101.2.255

if-Status

Status des Interfaces (Schnittstelle). Es werden die beiden Status up und down unterstützt.

Beispiel für ifconfig: Setzen der IP-Adresse, der Netmask und der Broadcast-Adresse für den Ethernet-Controller le0 # ifconfig le0 173.173.2.1 netmask 255.255.255.0 broadcast 173.173.2.255 up

Anzeigen der aktuellen Konfiguration des Ethernet-Controllers le0 # ifconfig le0

le0: flags=863 mtu 1500 inet 173.173.2.1 netmask fffff00 broadcast 173.173.2.255 ether 7:0:19:d:da:de

71


Relevante Dateien für das TCP/IP-Setup Folgende Dateien sind beim Setup von TCP/IP bedeutsam: /etc/hosts

Enthält die IP-Adressen und Hostnamen sämtlicher bekannter Hosts inklusive des Systems selbst.

/etc/networks

Enthält die Netzwerkadressen und Netzwerknamen sämtlicher bekannter Netzwerke inklusive des eigenen Netzwerks. Diese Einträge sind optional.

/etc/netmasks

Enthält die Netzwerkadresse und Subnet-Maske (netmask) des betrachteten Rechners. Diese Einträge sind optional. Ist eine Netmask in dieser Datei definiert, so kann sie bei dem Kommando ifconfig mit der Option netmask + verwendet werden. Weiter kann die Broadcast-Adresse, vergleichbar mit der Netmask, bei dem Kommando ifconfig mit der Option broadcast + verwendet werden.

/etc/hostname.le0 Enthält den Hostnamen des betrachteten Rechners. Dieser Eintrag wird vom Kommando hostname verwendet, um zum Boot-Zeitpunkt den Hostnamen des Rechners zu setzen. Die Datei /etc/hostname.lex muss für jeden EthernetController erstellt werden und sollte während des Boots konfiguriert werden. /etc/nodename

Enthält den »ersten« Hostnamen des Systems. Dieser Eintrag definiert den Knotennamen auf Rechnersystemen mit mehr als einer Schnittstelle (Controllern) und daher mehreren Hostnamen.

Beispiele: Einträge in /etc/hosts # cat /etc/hosts

127.0.0.1 173.173.2.1 173.173.2.2 173.173.3.1 173.173.3.2 173.173.4.1

localhost maestria troubadix miraculix automatix gutemine

Einträge in /etc/networks # cat /etc/networks

netz2 netz3 netz4

72

173.173.2 173.173.3 173.173.4


Einträge in /etc/netmasks # cat /etc/netmasks

170.170.0.0

255.255.255.0

Einträge in /etc/hostname.le0 # cat /etc/hostname.le0

maestria

Start von TCP/IP während des Boot-Prozesses Die Kommandos hostname und ifconfig werden verwendet, um TCP/IP während des Boot-Prozesses zu starten. Um den korrekten Hostnamen, die IPAdresse und die Netzmaske zu erhalten, wird auf die Dateien etc/hostname.le0 etc/hosts etc/netmasks zugegriffen. Diese Funktionen werden in folgenden Startup-Scripts aufgerufen: /etc/rcS.d/S30rootusr.sh /etc/rc2.d/S72inetsvc

Der Internet-Daemon »inetd« inetd ist der Listener-Dienst für fast alle Internetdienste. Eine Listener-Prozess »horcht«, ob Dienste angefordert werden und reagiert auf diese Anforderung. Beim Start von inetd liest dieser die Konfigurationsdatei /etc/inetd.conf und öffnet ein Socket für jeden spezifizierten Service. Erhält inetd einen Connection Request auf einem dieser Sockets, gibt er den Request an den Server weiter, der in der Konfigurationsdatei für die Ausführung der Anforderung eingetragen ist.

2.2.5 2.2.5.1

Das Network File System – NFS Einführung

NFS ist ein TCP/IP-basierender Dienst in Unix-Umgebungen, um Dateien in heterogenen Hardware-, Betriebssystem- und Netzwerkumgebungen gemeinsam zu nutzen. Als solcher ist NFS wesentlicher Bestandteil eines Network Attached Storage (NAS)-Systems in Open Systems-Umgebungen. Die gemeinsame Nutzung wird dabei durch das Einhängen (mount) eines Dateisystems oder eines Verzeichnisses eines entfernten Rechners auf dem lokalen Rechner erreicht. Auf diesem lokalen Rechner können die Dateien nun gelesen und geschrieben werden, als ob sie lokale Dateien wären.

73


Das entfernte Dateisystem oder Verzeichnis muss zuvor auf dem jeweiligen Rechner exportiert werden. NFS basiert auf einem Client-/Server-Architekturansatz. Ein Client montiert (mount) ein von einem Server exportiertes Dateisystem. Dieser Server kann eben das auch tun, sodass jeder Rechner im Netz gleichzeitig sowohl NFS-Client als auch NFS-Server sein kann.

2.2.5.2

NFS-Setup während der Installation

왘 Ein NFS-Client kann nach der Installation remote Dateisysteme oder Ver-

zeichnisse ohne weitere Aktivität einhängen (mount). 왘 Ein NFS-Server wird automatisch als solcher konfiguriert, wenn eine In-

stallation vom Typ »Server« durchgeführt wird.

2.2.5.3

NFS-Setup nach der Installation

Nach der Installation eines Rechners sind keine weiteren Schritte zu unternehmen, wenn dieser lediglich als NFS-Client funktionieren soll. Soll der Rechner jedoch ein NFS-Server werden, so sind folgende Schritte durchzuführen: # vi /etc/dfs/dfstab

Editieren der Datei /etc/dfs/dfstab. Eintragen der Verzeichnisse, die von diesem Server exportiert werden sollen # /etc/init.d/nfs.server start

Start der NFS-Server-Daemons mit dem Kommando /etc/init.d/nfs.server start. Existiert eine Datei /etc/dfs/dfstab mit Einträgen darin, müssen die NFSDaemons gestartet werden, um diese Verzeichnisse exportieren zu können.

2.2.5.4

NFS-Server Daemons

Folgende NFS-Server-Daemons müssen gestartet werden:

74

rpcbind

Der Daemon rpcbind wird für sämtliche auf Remote-ProcedureCall basierenden Dienstprogramme benötigt. Er mappt RPC-Programmnummern auf TCP- oder UDP-Port-Nummern.

mountd

Der Mount-Daemon mountd bearbeitet die Mount-Anforderungen der NFS-Clients an diesen NFS-Server.

nfsd

Der NFS-Daemon nfsd bearbeitet die Anforderungen von NFSClients an Dateien innerhalb eines gemounteten Dateisystems. Standardmäßig wird ein Daemon gestartet, der selbst wiederum bis zu 16 Threads via Respawn starten kann, um die einkommenden Anforderungen an das mounted Dateisystem zu erfüllen. Diese Daemons können udp- und tcp-Anforderungen bearbeiten (NFS-Protokoll-Versionen 2 und 3).


2.2.5.5

Benötigte NFS-Server-Dateien

Auf dem NFS-Server werden zwei Dateien für den Export von Dateisystemen benötigt. Export-Tabelle

Die Datei /etc/dfs/dfstab wird als »Export-Tabelle« bezeichnet. Sie enthält share-Kommandos für jedes Dateisystem oder Verzeichnis, das exportiert werden soll. Zusätzlich enthält sie über Exportoptionen Zugriffsbeschränkungen oder Zugriffserweiterungen für die exportierten Dateisysteme.

Export-Protokoll

Die Datei /etc/dfs/sharetab wird als »Export-Protokoll« bezeichnet und enthält einen Eintrag je Dateisystem und Verzeichnis, das im aktuellen Zeitpunkt exportiert wurde.

2.2.5.6

Exportieren von Dateisystemen

Nur NFS-Server können Dateisysteme exportieren. Um ein Dateisystem zu exportieren, müssen folgende Schritte gemacht werden: 왘 Eintragen der neu zu exportierenden Dateisysteme in die Datei /etc/dfs/

dfstab 왘 Ausführen des Kommandos shareall. Dieses Kommando trägt die neu

zu exportierenden Dateisysteme in das Export-Protokoll /etc/dfs/sharetab ein. Beispiel: # vi /etc/dfs/dfstab

... share -F nfs -o rw=sun2 /home # shareall

2.2.5.7

Löschen einer Export-Instruktion

Um eine Export-Instruktion zu löschen, also ein Dateisystem oder ein Verzeichnis aus der Liste der zu exportierenden Dateisysteme/Verzeichnisse zu entfernen, sind folgende Schritte einzuhalten: 왘 Löschen des betreffenden Dateisystems in der Datei /etc/dfs/dfstab 왘 Ausführen des Kommandos # unshare -F nfs . Dieses

Kommando löscht das Dateisystem aus dem Export-Protokoll /etc/dfs/ sharetab. Im folgenden Beispiel sollen Export-Instruktionen für das Dateisystem /home gelöscht werden:

75


# vi /etc/dfs/dfstab

... share -F nfs -o rw=sun2 /home (Löschen dieses Eintrags) # unshare -F nfs /home

2.2.5.8

Client-Dateien

Auf einem NFS-Client werden zwei Dateien für das Einhängen von Dateisystemen verwendet: Mount-Tabelle

Die Datei /etc/vfstab wird als »Mount-Tabelle« bezeichnet. Sie enthält für jedes Dateisystem oder Verzeichnis, das eingehängt werden soll, je einen Eintrag. Es können auch die Mount-Optionen verwendet werden.

Mount-Protokoll Die Datei /etc/mnttab wird als »Mount-Protokoll« bezeichnet. Sie enthält für jedes Dateisystem und jedes Verzeichnis, das aktuell eingehängt ist, einen Eintrag.

2.2.5.9

Einhängen von Verzeichnissen

Um ein Dateisystem oder ein Verzeichnis auf einem Client einzuhängen (mount), ist wie folgt vorzugehen: 왘 Eintragen des zu mountenden Dateisystems und des Mountpoints in die

Datei /etc/vfstab 왘 Erstellen des Mountpoints 왘 Ausführen des Kommandos # mountall. Ist der Mount erfolgreich, wird

durch dieses Kommando das Dateisystem in das Mount-Protokoll /etc/ mnttab eingetragen. Folgendes Beispiel zeigt, wie das Dateisystem /home des NFS-Servers fridolin als /home-fridolin auf dem lokalen NFS-Client eingehängt wird. # vi /etc/vfstab

#device device mount FS fsck mount mount #to mount to fsck point type pass at boot options ... fridolin:/home -/home-fridolin nfs -yes rw # mkdir /home-fridolin # mountall

76

Einführung in die Fibre Channel-Technologie

2.2.5.10

Anzeigen von Export- und MountInformationen

Mit dem Kommando # showmount -e <System> können Informationen über die exportierten Dateisysteme des Systems angezeigt werden. Mit dem Kommando # mount können Informationen über die im lokalen System eingehängten Dateisysteme angezeigt werden.

2.3


2.3.1

Überblick und Anwendung

Fibre Channel stellt eine serielle Datentransfer-Schnittstelle dar, die über Glasfaser und/oder über Kupferkabel operiert. Dabei gewährleistet Fibre Channel eine Datenübertragungsrate von bis zu 100 MB pro Sek. pro Port. Weiter bietet Fibre Channel eine logische Punkt-zu-Punkt-Verbindung zwischen einem Hostcomputer und einem Storage Device. Fibre Channel ist ein von der ANSI Fibre Channel Group standardisierter Protokoll-Stack, der mit der Zielsetzung entwickelt wurde, dass Kanäle und Netzwerke in der Lage sein sollen, das gleiche Kabel zu verwenden. Diese Zielsetzung ist vor allem vor dem Hintergrund sinnvoll, dass IT-Systeme beständig zwei oder mehr Schnittstellen unterstützen. Es sollte gelingen, Port und Medien zu teilen und dadurch Hardwarekosten und Größe des IT-Systems einzusparen, da Schnittstellenkomponenten wegfallen können. Der Fibre Channel Standard Stack standardisiert ausgesprochen ambitionierte Zielsetzungen: 왘 Übertragungsperformance von 133 Megabits/Sek. bis vier Gigabits/Sek. 왘 Unterstützung von Entfernungen bis zu zehn Kilometern zwischen den

Fibre Channel Devices 왘 Verwendung kleiner Konnektoren 왘 Distanzunabhängiger hoher Ausnutzungsgrad der Übertragungsband-

breite 왘 Einfachere Connectivity als mit existierenden Multidrop-Kabeln 왘 Breit angelegte Verfügbarkeit insbesondere der Standardkomponenten

77

2 SAN – Grundlegende Basis-Technologien 왘 Unterstützung multipler Preis-/Leistungs-Modelle für die Implementie-

rung in kleinen bis hin zu Supercomputern 왘 Fähigkeit zur gleichzeitigen Nutzung multipler Interface Command Sets

wie IP (Internet Protokoll), SCSI, IPI, HiPPI-FP und Audio/Video Netzwerk- und I/O-Protokolle, wie z.B. SCSI-Kommandos werden auf die ihnen entsprechenden Konstrukte der Fibre Channel-Umgebung gemapped und dann, wie in layered Netzwerken gewohnt, gekapselt und in Fibre Channel-Frames transportiert. Dabei ist Fibre Channel ein Channel-/Netzwerk-Standard, durch den die geforderten Netzwerkfeatures der Connectivity, der höheren Distanz und des Protokoll-Multiplexing erfüllt werden. Dadurch ist ein Hochgeschwindigkeitstransfer multipler Protokolle über das gleiche Kabel möglich. Eine Kommunikation von bis zu 1.062,5 MegaBaud im Full-Duplex-Modus ist heute realistisch. Weiter unterstützt Fibre Channel traditionelle Kanalfunktionalitäten wie Einfachheit, wiederholbare Performance und garantierte Sicherheit bei der Übertragung. Fibre Channel arbeitet darüber hinaus als generischer Transportmechanismus. Die physikalischen Verbindungen zwischen zwei Fibre Channel Devices (z.B. Host via Host-Bus-Adapter und Storage Device über Host-Adapter oder ChannelAdapter, siehe zur Erläuterung die entsprechenden Abschnitte in Kapitel 4 dieses Buches) werden über ein Multi-Mode-Glasfaserkabel aufgebaut. Dieses erlaubt einen Abstand von bis zu 500 m zwischen den beiden Devices. Abbildung 2.3 zeigt den Querschnitt eines Glasfaserkabels und dessen Aufbau. Abbildung 2.3: Fibre Channel-Kabel

Dämpfungsmaterial Kern 9/50/62,5 µm Durchmesser

Mantel 125 µm Durchmesser Schutzhülle 2,5 mm Durchmesser

Umhüllung 250 µm Durchmesser

Wellenlängen: Kurzwelle 780-850 nm Langwelle 1300-1550 nm sichtbares Licht 490-750 nm

78


Die Fibre Channel-Architektur repräsentiert eine wahrhafte Channel-/Netzwerk-Integration mit einer aktiven, intelligenten Verbindung zwischen Devices. Die Übertragung ist vom Kontroll-Protokoll isoliert, sodass die von den ANSI Fibre Channel-Standards definierten drei Topologien zur Verbindung von Fibre Channel Devices Point-to-Point, Arbitrated Loop und Switched Fabric verwendet werden können, um die bestimmten Anforderungen einer Unternehmens-Anwendung zu realisieren. Diese Topologien werden im Folgenden kurz, in Kapitel 3 dieses Buches in Detail, beschrieben. Point-to-Point-Topologien stellen eine einfache Verbindung zwischen zwei Devices dar. Dabei wird z.B. ein Host über einen Fibre Channel-Host-BusAdapter an einen Fibre Channel-Host-Adapter eines Storage Arrays angeschlossen. Dieser Host sieht nun sämtliche Platten innerhalb des Storage Arrays, die über diesen Host-Adapter sichtbar sind. In der Point-to-PointTopologie ist jedoch das Storage Array nur an diesen einen Host angeschlossen. Die Point-to-Point-Topologie implementiert damit lediglich klassische SCSI-Anschlusstechniken von Storage Devices über Fibre Channel-Technologien. Vorteil der Point-to-Point-Topologie gegenüber der SCSI-Anschlusstechnik ist die gesteigerte Bandbreite und die gesteigerte Distanz der Glasfaser-Technologie gegenüber SCSI. Fibre Channel Arbitrated Loop (FC-AL) ist ursprünglich eine »Daisy Chain« von zwei bis 126 Fibre Channel-Geräten in einer Loop-Konfiguration, die über so genannte L-Ports miteinander verbunden werden. FC-AL ist eine kostengünstige Lösung, da keine Switching Devices benötigt werden. FCAL ist eine gute Wahl für kleine bis mittelgroße Konfigurationen. Die FC-AL Loop kann an eine Switched Fabric angeschlossen werden, sodass auch das Hineinwachsen in eine Switched Fabric-Umgebung möglich ist. Problematisch ist bei der Implementierung der Arbitrated Loop als »Daisy Chain«, dass bei Ausfall eines Geräts innerhalb der Loop die Devices der Loop nicht mehr verfügbar sind. Werden I/O-Requests von einem Host an ein Storage Device gesendet, so wandert der Fibre Channel-Frame dieses I/Os durch die komplette Loop. Dies bewirkt, dass die komplette Bandbreite der Fibre Channel Loop nur von diesem Host genutzt wird. De facto stellt dies eine Teilung der Bandbreite der Fibre Channel-Ports der Loop durch die Anzahl der angeschlossenen Devices dar. Weiter führt die Erweiterung der Loop um zusätzliche Devices zu einer chaotischen Verkabelung, d.h. sowohl seitens der Verkabelung als auch der Konfigurations- und Verwaltungsaufgaben ist die Arbitrated Loop ausgesprochen anspruchsvoll. Effizienz und physikalischer Aufbau der Loop können dadurch verbessert werden, indem ein oder mehrere Fibre Channel-Hubs in die Loop integriert werden. Die Probleme der »Daisy Chain« bei Ausfall eines Hubs sind dann lediglich auf die Devices beschränkt, die an diesen Hub angeschlossen sind. Ebenfalls gewinnt die physikalische Verkabelung über Hubs deutlich an Übersichtlichkeit.

79


Die Fibre Channel Switched Fabric (FC-SW) Topologie verwendet ein oder mehrere Switching Devices, über die mehrere Knoten dynamisch miteinander verbunden werden können. Die Knoten der Fabric sind auch hier z.B. wieder Hosts und Storage Arrays. Abbildung 2.4: Fibre ChannelTopologien

•

Punkt-zu-Punkt – einzelne Verbindung

•

Arbitrated Loop – Begrenzte Skalierbarkeit – Geteilte Bandbreite – Möglichkeit eines „single point of failure”

•

Switched Fabric

Hub

S witche d Fa bric

– „Dynamic Virtual Circuits” – Redundante Komponenten, „auto failover” – „Hot plugable, upgradeable”

Die Fibre Channel-Standards verwenden den Begriff des »Knotens«, um jedes Gerät zu charakterisieren, das über Fibre Channel an ein oder mehrere andere Geräte angeschlossen ist. Jedes Fibre Channel-Gerät besitzt zumindest einen Port, über den dieses Gerät an einen Port eines anderen Knoten verbunden wird. Die Fabric ist als allein stehendes Gerät selbst zu verwalten. Die einzelnen Knoten bedürfen keines Managements, sie werden seitens des Switches verwaltet. Dies vereinfacht die Implementierung einer Fabric erheblich. Innerhalb eines Fibre Channel Storage Area Network existieren folgende Ports, die das jeweilige Device an die Fibre Channel-Umgebung anschließt. Port

Funktion und Verwendung

N-Port

Port eines Knotens außerhalb einer »Fabric«

F-Port

Port an einem »Switch«, der eine Punkt-zu-Punkt-Verbindung zu einem N-Port herstellen kann

NL-Port

Port, der an einer »Arbitrated Loop« betrieben werden kann (mit einem Fabric Login)

Tab. 2.5: Fibre Channel-Ports im SAN

80


Port

Funktion und Verwendung

FL-Port

Port an einem »Switch«, der in einer »Arbitrated Loop« betrieben werden kann

E-Port

Stellt die Verbindung zu einem anderen »Switch« her

G-Port

Kann als F-Port oder E-Port eingesetzt werden

GL-Port

Kann als F-Port, FL-Port oder E-Port eingesetzt werden

Private Loop

Es wird nur das unterste Byte der Adresse verwendet. Kann in einer »Quick Loop« am Switch verwendet werden.

Public Loop

Loop mit einem Anschluss an eine »Switched Fabric«

Tab. 2.5: Fibre Channel-Ports im SAN (Forts.)

Die Verbindung der Devices innerhalb eines SANs anhand dieser Ports kann man sich wie in Abbildung 2.5 vorstellen. Abbildung 2.5: Fibre Channel-Ports im SAN

E-Port

Host E-Port

F-Port N-Port

Switch

Host

FL-Port

Switch

Hub

F-Port Public Loop

Hub

NL-Ports N-Port

Host Private Loop

NL

Host

Host

Storage Array Die Interoperabilität in Fibre Channel-Umgebungen wird durch zwei unabhängige Laboratorien gewährleistet. Das Interoperability Laboratory (IOL) an der University of New Hampshire entwickelt Test Suites für HardwareHersteller, um die Übereinstimmung der Produkte mit den Fibre ChannelStandards sicherzustellen. Das Computational Science and Engineering Laboratory an der University of Minnesota ist auf die Entwicklung der Funktionalität und der Ausweitung von Fibre Channel-basierten Applikationen fokussiert. Für Speichermedien ist Fibre Channel die Anschluss-Technologie der Zukunft. Als solche wurde Fibre Channel von den führenden Computerund Speicherherstellern angenommen und für unternehmensweite Speicher-

81


architekturen implementiert. Fibre Channel eliminiert die Entfernungs-, Bandbreiten-, Skalierbarkeits- und Zuverlässigkeitsgrenzen eines herkömmlichen SCSI-Anschlusses. Fibre Channel wird schon heute als Standard-Magnetplatten-Schnittstelle angeboten. Führende RAID-Anbieter (Redundant Array of Inexpensive Disks) liefern heute schon voll in Fibre Channel-Technologie ausgelegte Storage Arrays. In Zukunft wird kein RAID-Hersteller als ernsthafter Anbieter in Auswahlverfahren involviert werden, wenn er keine Fibre Channel-Technologie anbietet. In SANs als Speichernetzwerk hinter den Serversystemen werden ein oder mehrere Server mit einem oder mehreren dieser Speichersysteme verbunden. Jedes dieser Speichersysteme kann ein RAID Storage Array, ein Magnetband-Datensicherungssystem, eine Magnetbandbibliothek, eine CDROM-Bibliothek oder ein JBOD-System (Just a Bunch Of Disks) sein. Fibre Channel-Netzwerke sind robust und zuverlässig. Die Vorzüge eines auf Fibre Channel-Produkten basierenden SAN sind: 왘 Zwischen den Servern geteilte Speicherkapazität 왘 Unabhängige Skalierbarkeit von Server- und Speicherkapazitäten 왘 Hohe Performance 왘 Robuste Datenintegrität und -zuverlässigkeit 왘 Schneller Datenzugriff und schnelle Datensicherung

In einem Fibre Channel-Netzwerk können auch herkömmliche Speichersysteme mithilfe einer Fibre-Channel-to-SCSI-Bridge eingebunden werden. Das Internet-Protokoll IP wird für die Server-to-Server- und die Client-to-Server-Kommunikation verwendet. Speichernetzwerke arbeiten sowohl mit Speicher- (SCSI) als auch mit Netzwerk (IP)-Protokollen. Server und Arbeitsplatzrechner verwenden das Fibre Channel-Netzwerk für einen geteilten Zugriff auf das gleiche Speichersystem oder sogar das gleiche Speichergerät (die gleiche Magnetplatte). Fibre Channel-Produkte ermöglichen in der unternehmensweiten Datenverarbeitung eine neue Performance-Ebene mit einer zuverlässigen ÜbertragungsBandbreite von über 90 MB/Sek. für Filetransfers und über 10.000 I/Os pro Sek. für geschäftskritische Datenbank-Applikationsumgebungen. Diese Vorzüge machen Fibre Channel zum führenden Connectivity-Standard für den Zugriff auf Speichersysteme. Jedoch nicht nur für die Schnittstelle zum Speichersystem, sondern auch für die Netzwerk-Technologie bietet Fibre Channel den Unternehmen erweiterte Performance und Zuverlässigkeit. Die Vielzahl von Netzwerkapplikationen für die Verwendung der Fibre Channel-Technologie umfasst (vgl. hierzu das Kapitel »SAN- und NAS-Anwendungen«): 왘 Unternehmensweites »Rund-um-die-Uhr« Backbone 왘 Hochperformantes CAD/CAE-Netzwerk (Computer Aided Design/Com-

puter Aided Engineering)

82

Einführung in die Fibre Channel-Technologie 왘 Filmanimation und Post-Production-Projekte 왘 Hochperformantes Netzwerk für bildverarbeitende Applikationen

Fibre Channel wurde von der Computerindustrie für IT-Anwendungen entwickelt. Seine Entwicklung zielte auf die Beseitigung der Performance-Barrieren herkömmlicher LANs. Zu den Performance steigernden Eigenschaften von Fibre Channel gegenüber LAN-Technologien zählen: 왘 Bestätigte Ankunft von Frames. Dadurch wird die Zuverlässigkeit des

Protokollstacks erhöht. Es bietet sich jedoch auch die Möglichkeit, den Protokollstack zu umgehen und damit die Performance der Übertragung zu steigern. 왘 Vollständige Unterstützung der »Self Discovery« traditioneller Netz-

werke. Fibre Channel unterstützt ARP, RARP und weitere Protokolle für das »Self Discovery«. 왘 Unterstützung dedizierter Punkt-zu-Punkt-Verbindungen mit fester, ga-

rantierter Bandbreite. Weiter werden auch Loops mit geteilter Bandbreite sowie Switches mit skalierbarer Bandbreite unterstützt. 왘 Unterstützung verbindungsorientierter virtueller Netzwerke mit einem

vollständigen Connection-Service oder einer fraktionierten Bandbreite. Dadurch wird die benötigte Zuverlässigkeit der Verbindung für unternehmenskritische Datensicherungen oder andere relevante Anwendungen garantiert. 왘 Optionale Nutzung virtueller oder realer Netzwerke 왘 Augenblicklicher Aufbau der Verbindung. Der Verbindungsaufbau dau-

ert dank Verwendung des Fibre Channel-Protokolls in dafür verbesserter Hardware lediglich Mikrosekunden. 왘 Verbindungsorientierte und verbindungslose Dienste mit extrem niedri-

gen Latenzzeiten. 왘 Automatisches »Self Discovery« und Selbst-Konfiguration der Fibre

Channel-Topologien. 왘 Unterstützung für zeitsynchrone Anwendungen wie Video durch Ver-

wendung von virtuellen Circuits mit fraktionaler Bandbreite. 왘 Durch die Verwendung von Frames variabler Länge von 0-2 KB werden

effiziente Transfers mit niedriger Latenz und hoher Bandbreite gewährleistet. Fibre Channel ist effizient bei Protokollframes von weniger als 100 Bytes wie auch bei Massentransfers mit maximalen Framegrößen. Heutige IT-Umgebungen sind geprägt von intensiver Netzwerknutzung. Diese Netzwerke müssen standardbasiert die heterogenen proprietären Hardwareumgebungen eines Unternehmens miteinander verbinden. Aus verteilter Datenverarbeitung und aus Parallelprozessing resultieren eine ansteigende Prozess-zu-Prozess-Kommunikation und gesteigerte Speicheranforderungen.

83


Die verarbeiteten und zu speichernden Daten müssen schnell zwischen den unterschiedlichen Systemen transportiert und von diesen geteilt werden. Dies ist die Ursache für die Forderung nach hoher Bandbreite und geringer Latenz, die durch Fibre Channel bedient werden kann. Fibre Channel ist für vernetzte IT-Umgebungen interessant, da seine standardbasierte Ausrichtung auf Open Systems die Endanwender von proprietären, vertikal integrierten Lösungen eines alleinigen Anbieters »befreien« kann. Mittels Fibre Channel können diese Anwender heute die jeweils beste Lösung auf dem Markt nahtlos in ihr IT-Netz integrieren. Fibre Channel ist als Netzwerk-Technologie die Lösung für die technologischen und kaufmännischen Anforderungen moderner Client-/Server-Implementierungen. Nur Fibre Channel bietet die Zuverlässigkeit, die Skalierbarkeit, den hohen Durchsatz und die niedrigen Latenzzeiten, die die in der heutigen IT benötigte große Bandbreite der technologischen und kaufmännischen Anforderungen abdeckt.

2.3.2

Technologievergleich

Fibre Channel wurde entwickelt, um die Performance-Grenzen existierender produktiver LANs und Kanäle zu durchbrechen. Die LAN-Technologie bietet heute zwar eine mehr oder weniger skalierbare Gigabit-Transfer-Technologie. Fibre Channel implementiert hingegen zusätzlich dazu eine Flow Control, eine einfache Verwaltung und eine herausragende Zuverlässigkeit, wie man sie bisher nur von Kanälen kannte. Damit ist Fibre Channel von der Computerindustrie daraufhin ausgerichtet, die Vorteile von Netzwerken und Kanälen miteinander zu verbinden. Gigabit Ethernet ist eine Erweiterung existierender LAN-Fähigkeiten für einen Transport großer Bandbreite. Es ermöglicht einen gemeinsamen Rahmen vom Arbeitsplatzrechner bis zum Backbone. Hier unterscheidet sich Fibre Channel jedoch, indem es den Gigabit-Transportservice unabhängig von den gängigen Netzwerk-Protokollen anbietet. Dabei geht Fibre Channel also über die Möglichkeiten des Gigabit-Ethernet hinaus, indem es in einer Technologie den gemeinsamen Rahmen für Speicher, Netzwerk, Audio und Video und den puren Transfer großer Datenmengen bietet. ATM wurde als Wide Area Network mit der Möglichkeit für Dienste mit fraktionaler Bandbreite geschaffen, um den gewohnten Netzwerk-Service anzubieten. Das Feature der fraktionalen Bandbreite mit garantiertem Service (Zuverlässigkeit) ist insbesondere für Audioübertragungen und Videoon-Demand unabdingbar. Für diese Anwendungen bietet ein Class 4 Fibre Channel jedoch nicht nur die fraktionale Bandbreite mit garantierter Auslieferung der Frames, sondern auch noch den Gigabit-Transfer. Fraktionale Bandbreite mit höherer Performance ist der Vorteil von Class 4 Fibre Channel gegenüber ATM-Netzen.

84


Channel Hohe Leistung Kurze Distanz Verbindung innerhalb eines Systems Statische Konfiguration Geringer ProtokollOverhead

Fibre Channel Hohe Leistung Große Distanz Verbindung mehrerer Systeme Dynamische Konfiguration Geringer Protokoll-Overhead

Netzwerk Geringe Leistung Große Distanz Verbindung mehrerer Systeme Dynamische Konfiguration Großer ProtokollOverhead

Abbildung 2.6: Vergleich Channel : Fibre Channel : Netzwerk

Aus kommerzieller Sicht bietet Fibre Channel gegenüber allen vergleichbaren Technologien eine interessante Alternative, da es sowohl für Netzwerkfunktionalitäten, als auch für klassische Kanalfunktionalitäten wie den Anschluss von Speicher eingesetzt werden kann. Folgende Tabelle stellt nochmals die Alternativen Fibre Channel, Gigabit-Ethernet und ATM gegenüber. Parameter

Fibre Channel

Gigabit Ethernet ATM

Technologie, Anwendung

Massenspeicher, Netzwerk, Video, Cluster

Netzwerk

Netzwerk, Video

Topologien

Punkt-zu-Punkt, Arbitrated Loop/ Hub, Switched

Punkt-zu-Punkt, Hub, Switched

Switched

Baud-Rate

1,06 Gb/Sek

1,25 Gb/Sek

622 Mb/Sek

Skalierbarkeit zu höheren BaudRaten

2,12 Gb/Sek, 4,24 Gb/Sek

Nicht definiert

2,48 Gb/Sek

Garantierte Übertragung

Ja

Nein

Nein

Möglicher KonsistenzDaten-Verlust

Nur bei Class 3-Services

Ja

Ja

Framegröße

Variabel, 0-2 Kb

Variabel, 0-1,5 Kb Fix, 53 Bytes

Flow Control

Credit Based

Rate Based

Rate Based

Tab. 2.6: Technologievergleich Fibre Channel, Gigabit-Ethernet, ATM

85


Parameter

Fibre Channel

Gigabit Ethernet ATM

Physikalisches Übertragungsmedium

Kupferkabel, Glasfaser



Unterstützte Protokolle

Netzwerk, SCSI, Video

Netzwerk

Netzwerk, Video

Tab. 2.6: Technologievergleich Fibre Channel, Gigabit-Ethernet, ATM (Forts.)

2.3.3

Fibre Channel-Ebenen

Fibre Channel ist in voneinander unabhängige Ebenen strukturiert. Die in Abbildung 2.7 dargestellten Ebenen definieren das physikalische Übertragungsmedium und die Übertragungsraten, das Kodierungsschema, das Framing-Protokoll und die Flow Control, die allgemeinen Dienste sowie die Protokollschnittstellen zu den Anwendungen der oberen Ebene.

2.3.3.1 Abbildung 2.7: Die Fibre ChannelEbenen

FC-4

Die physikalischen Fibre Channel-Ebenen Multimedia Audio Video

Channels IPI SCSI HiPPI SBCCS

Networks IP 802.2

Signaling Layer FC-3

Common Services

FC-2

Framing Protocol/Flow Control

FC-1

Encode/Decode 10/20 bit media independent interface Serializer/Deserializer Serializer/Deserializer Serial media independent interface

FC-0

Multi Mode fiber - Single Mode fiber - Copper 133 Mbps 266 Mbps 531 Mbps 1,06 Gbps 2,12 Gbps 4,25 Gbps

Physical Layer

86


Die drei Fibre Channel-Ebenen der physikalischen Ebene beschreiben wir folgendermaßen: FC-0

deckt die physikalischen Charakteristika der Schnittstellen und Medien ab, wie Kabel, Konnektoren, Treiber (ECL, LEDs, Kurzwellen-Laser, Langwellen-Laser), Transmitter und Receiver.

FC-1

definiert das acht-Bit/10-Bit-Kodierungs-/Dekodierungs- und Übertragungs-Protokoll, das zur Integration der Daten in die Clock-Informationen dient, die für serielle Übertragungstechniken erforderlich sind.

FC-2

definiert die Regeln für das Signal-Protokoll und beschreibt die Übertragung von Daten-Frames, Frame-Folgen und Datenaustausch.

Die drei unteren Ebenen der Fibre Channel-Architektur, auch als FC-PH bezeichnet, wurden erstmals im Januar 1993 der Öffentlichkeit vorgestellt. Der zweite öffentliche Ausblick begann im Oktober 1993, der Standard wurde im November 1994 festgeschrieben.

Fibre Channel physical layer – Ebene FC-0 Auf der untersten Ebene, FC-0, wird die physikalische Verbindung (physical link) des Kanals spezifiziert. Fibre Channel operiert über verschiedene physikalische Medien und mit unterschiedlichen Datenübertragungsraten. Der Impetus von Fibre Channel, unterschiedliche Verkabelungs- und Protokollwelten verbinden zu wollen, um der Verbindungs-Standard der Zukunft zu werden, bewirkt, dass ein Maximum an Flexibilität auf der untersten Ebene der physikalischen Übertragung erreicht wird. Existierende Verkabelungen und eine Vielzahl existierender Technologien können verwendet werden, um die Anforderungen z.B. eines Storage Area Networks erfüllen zu können. Beispielsweise könnte mit einem Single Mode-Glasfaserkabel die Distanz zwischen zwei Lokationen eines Unternehmens überwunden werden. Innerhalb der Gebäude könnte via Multi Mode-Glasfaser die vertikale Verteilung erfolgen, über die mit einer Kupfer-Drop-Verkabelung die einzelnen Arbeitsplatzsysteme einer Client-/Server-Umgebung angeschlossen sein könnten. Für kurze Entfernungen kann Fibre Channel auch Twinax-Kupferkabel verwenden. Eine effektive Übertragungsrate von 100 MB/Sek. bei einer Leitungsgeschwindigkeit von 1,0625 Gbaud ist gewährleistet. Steigerungen der Leitungsgeschwindigkeit über Glasfaserkabel bis zu 2,125 und 4,25 Gbaud sind bereits freigegeben. Tabelle 2.7 gibt mögliche Übertragungsgeschwindigkeiten, Übertragungsmedien, Übertragungsdistanzen und Transmitter wieder. Aus diesen ergibt sich die Nomenklatur für die Bezeichnung der gängigen Übertragungsmedien in einem Fibre ChannelNetzwerk.

87


Kriterium ÜbertragungsGeschwindigkeit

ÜbertragungsMedium

ÜbertragungsDistanz

Transmitter

Bezeichnung

Bedeutung

400

400 MB/Sek.

200

200 MB/Sek.

100

100 MB/Sek.

50

50 MB/Sek.

25

25 MB/Sek.

12,5

12,5 MB/Sek.

SM

Single Mode-Glasfaserkabel

M5

50/125 Multi Mode-Glasfaserkabel

M6

62,5/125 Multi-Mode-Glasfaserkabel

MI

Miniatur-Kabel, Kupferkabel

TV

Video Kabel, Kupferkabel

TP

Twisted Pair, Kupferkabel

TW

Twinax, Kupferkabel

L

Long: Entfernungen > zwei km

I

Intermediate: Entfernungen von 100 m – zwei km

S

Short: Entfernungen < 100 m

LL

Long Wave Laser (Langwellenlaser) (1.300 bis 1.550 ηm)

SL

Short Wave Laser (Kurzwellenlaser) (780 bis 850 ηm)

SN

Short Wave Laser (Kurzwellenlaser ohne Open Fibre Control) (780 bis 850 ηm)

LE

Long Wave LED (Langwellen-LED) (1.300 bis 1.550 ηm)

EL

Electrical

Tab. 2.7: Nomenklatur-Parameter in der physikalischen Ebene von Fibre Channel

88


Aus der Kombination der Kriterienbezeichnungen, jeweils durch Bindestrich getrennt, ergibt sich die Benennung der Implementierungen der physikalischen Ebene FC-0 im Fibre Channel-Netz. Als Beispiel mögen die beiden gängigsten Implementierungen dienen: 100-TW-S-EL:

100 MB/Sek. (Übertragungsgeschwindigkeit) – TW (TwinaxKupferkabel Übertragungsmedium) – S (Short Übertragungsdistanz) – EL (Electrical Transmitter)

100-M5-I-SL:

100 MB/Sek. (Übertragungsgeschwindigkeit) – M5 (50/125 Multi Mode-Glasfaserkabel Übertragungsmedium) – I (Intermediate Übertragungsdistanz) – SL (KurzwellenLaser-Transmitter)

Es existieren drei Konnektor-Typen. Glasfaser-Konnektoren sind in aller Regel zweifache SC-Stecker. Kupfer-Steckverbindungen werden mit Standard-DB-9-Konnektoren oder den neueren HSSDC-Konnektoren realisiert. Fibre Channel-Produkte können eine on-board-Kupfer- oder GlasfaserSchnittstelle oder ein medienunabhängiges Interface besitzen. Folgende medienunabhängige Schnittstellen sind verfügbar: Abbildung 2.8: Fibre ChannelKonnectoren

Kupfer DB9-Stecker

Gigabit Interface Converter

Kupfer HSSC-Stecker

Gigabaud Link Module

Zweifach SC FibreOptic-Stecker

Media Interface-Adapter

왘 Gigabaud Link Module (GLM) beinhalten die Serializer-/Deserializer-

Funktion (SERDES) und bieten eine 20-Bit-Parallelschnittstelle zur Fibre Channel-Kodierung/-Dekodierung- und Kontrolllogik. Gigabaud-LinkModule werden vor allem zur Vorkonfiguration der Fibre Channel-Produkte vor der Auslieferung an den Kunden verwendet. Sie sind jedoch auch beim Kunden austauschbar und erweiterbar.

89

2 SAN – Grundlegende Basis-Technologien 왘 Gigabit Interface Konverter (GBIC) bieten eine serielle Schnittstelle zur

SERDES-Funktion. Gigabit Interface Konverter können im laufenden Betrieb von Fibre Channel-Geräten ein- und ausgebaut werden (hot repair). Damit werden sie insbesondere in Multi-Port-Geräten wie Switches und Hubs (vgl. Abschnitt SAN-Hardware) verwendet, indem einzelne Ports ausgetauscht und rekonfiguriert werden, ohne den Betrieb der anderen Ports einzuschränken. 왘 Media Interface Adapter (MIA) ermöglichen die Konvertierung von Kup-

fer-DB-9-Konnectoren zu Multi Mode-Glasfaser. Die Fähigkeit, optische Transceiver zu unterstützen, wird durch definierte Stecker-Pins in der DB-9-Schnittstelle realisiert.

Fibre Channel physical layer – Ebene FC-1 Die Fibre Channel-Ebene FC-1 stellt das Übertragungs-Protokoll (Transmission Protocol) der Fibre Channel-Architektur dar. In FC-1 werden die herausragenden Übertragungscharakteristika eines DC-balancierten 8Bit/10BitKodierungsschemas für Clock Recovery, Byte-Synchronisation und Kodierung/Dekodierung verwendet. Abbildung 2.9: Fibre ChannelTransmissionProtokoll

Byte Clock

Control-Byte

Paralleles Datenbyte

A

B

C

D

E

F

G

5 Bytes/6 Bytes-Funktionen

H

K

3 Bytes/4 Bytes-Funktionen

Disparity Control

a

b

c

d

e

i

f

g

h

j

10-Bit Byte zum Serializer oder zum Schnittstellenmodul des Übertragungsmediums

Dieser balancierte Code wurde von IBM entwickelt, bietet eine ausreichende Übertragungsdichte für ein einfaches Clock Recovery und erlaubt ein kostengünstiges Komponentendesign. Ein benanntes eindeutiges Sonderzeichen (Kommazeichen) gewährleistet eine korrekte Byte- und Wortaus-

90


richtung. Weitere Vorzüge dieses Codes sind seine praktische Möglichkeit der Fehlererkennung und seine einfache, logische Implementierung für die Kodierung und Dekodierung. In diesem Code-Schema werden acht interne Bits (also ein Byte) als eine 10-Bit-Gruppe übertragen. Obige Abbildung visualisiert das 8Bit/10Bit-Fibre Channel-Übertragungs-Protokoll.

Fibre Channel physical layer – Ebene FC-2 Die Fibre Channel-Ebene FC-2 definiert das Framing-Protokoll und die Flow Control. Durch das Framing- und Signaling-Protokoll der Ebene FC-2 wird die zuverlässige Kommunikation über Fibre Channel gewährleistet. Dabei definiert FC-2 einen Datentransport-Mechanismus, der unabhängig von den Protokollen der oberen Ebenen der Fibre Channel-Architektur ist. Fibre Channel FC-2 ist eigenständig konfigurierbar und unterstützt Punkt-zuPunkt-, Arbitrated Loop- und Switched Fabric-Geräteumgebungen. Geräte werden über Ports in ein Fibre Channel-Netzwerk – z.B. ein SAN – eingebunden. Ein Endgerät im Fibre Channel-Netzwerk wird als Knoten (Node) bezeichnet. Ein N-Port ist ein Port auf einem Knoten, also einem Server, einer Workstation oder einem Storage Array. Ist der Port an eine Arbitrated Loop angeschlossen, so wird er zum NL-Port. Die Datenkommunikation zwischen zwei Knoten erfolgt über einen Fibre Channel-Link durch die miteinander verbundenen Ports der Knoten. Jeder Knoten enthält ein ASIC (Link Controller) mit einer on board Fibre Channel Link Control Facility. Diese überwacht und steuert die logische und physische Kontrolle über den Link. Die Link Control Facility bietet eine logische Schnittstelle zum Rest des Endgeräts. Sie bietet die komplette Verarbeitung des Fibre Channel-Protokolls. Jeder Fibre Channel-Port kann als Urheber (Quell-Port) oder Responder (ZielPort) oder beides agieren und enthält daher sowohl einen Transmitter als auch einen Receiver. Jeder Port im Fibre Channel besitzt einen eindeutigen Namen, der ihn als N-Port oder NL-Port identifiziert. Dank dieser bidirektionalen Konstruktion eines Ports verdoppelt ein Full Duplex-Datenfluss die Bandbreite von Fibre Channel. FC-2 bietet einen kompletten Funktionssatz zusätzlich zur Definition der Framing-Struktur. Diese Funktionen sind: 왘 Ein robuster 32-Bit-CRC (Cyclic Redundancy Check) dient der Entde-

ckung von Übertragungsfehlern. Über diesen CRC wird die Datenintegrität der Fibre Channel-Kommunikation gewährleistet. 왘 Unterschiedliche Dienstklassen bieten und verwalten das Circuit Swit-

ching, Frame Switching, die Datagram Services und virtuelle Circuits fraktionaler Bandbreite innerhalb einer Switched Fabric-Umgebung. Class 1 ist dabei eine wahre Circuit Switched-Verbindung; Class 2 ist ein verbindungsloser Frame Switched Link, der jedoch eine garantierte Auslieferung eines Frames beim Empfänger sowie die Empfangsbestätigung vom Empfänger bietet. Dagegen ist Class 3 ein verbindungsloser Dienst,

91


der nicht auf eine Empfangsbestätigung wartet und daher auch einen Datenverlust beinhalten kann, wenn die Verbindung zwischen Quell- und Ziel-Port unterbrochen wird. Ein Intermix erlaubt simultan verbindungslosen und Class 1 Circuit Switched-Verbindungs-Kommunikationsverkehr. Class 4 unterstützt virtuelle Circuits mit fraktionaler Bandbreite. Class 6 stellt einen Simplex-Verbindungsdienst dar mit Multicast und Preemption. Die Service-Klassen von FC-2 werden später noch detailliert dargestellt. 왘 Angebot von Konstrukten zur Unterstützung effizienten Multiplexings

für Operationen. 왘 Ein Flow Control-Schema mit der Fähigkeit einer garantierten Ausliefe-

rung der Frames an den Empfängerport. Die Flow Control ist Buffer-toBuffer und/oder Node-to-Node für verbindungslose Dienste sowie Nodeto-Node für an Class 1, Class 4 und Class 6 verbindungsorientierte Dienste. 왘 Eine Menge generischer Funktionen, die von mehreren Protokollen der

oberen Ebenen der Fibre Channel-Architektur gemeinsam genutzt werden. 왘 Ein integriertes Protokoll zur Unterstützung der Verwaltung und Über-

wachung der Verbindung, Kontrolle der Fibre Channel-Konfiguration, Wiederherstellung der Betriebsfunktionalität nach einem Fehlerfall und zur Wiederherstellung der Link- und Port-Status-Informationen. 왘 Optionale Header, die für Netzwerk-Routing über Fibre Channel ver-

wendet werden können. 왘 Integration von Kontroll-Informationen im Header, um Hardware-Rou-

ting unterstützen zu können. 왘 Implementierung eines Prozesses zur Segmentierung und Reassemblie-

rung von Daten. Die nachfolgende Abbildung stellt die Struktur des Fibre Channel Framings, Sequencings und des Austausches von Frames über FC-2 dar. Die Struktur des Framing- und Signaling-Protokolls von FC-2 wird durch vier Bausteine definiert: 1. Ordered Set: Der Ordered Set besteht aus vier Zeichen à zehn Bit. Er stellt eine Kombination aus Datenzeichen und Sonderzeichen dar, die für diverse Low Level Link-Funktionen wie Frame-Begrenzung und Signalsteuerung zwischen den zwei Enden eines Links verwendet werden. Diese Signalsteuerung ist für die Reinitialisierung des Links nach einem Stromausfall und für diverse Basis-Recovery-Aktionen verantwortlich.

92


4 Bytes Start des Frame

24 Bytes Header

2.112 Bytes Nutzdaten 64 Bytes optionaler Header

2.048 Bytes Nutzdaten

4 Bytes 4 Bytes CRC Ende des FehlerFrames Check

Fibre Channel Frame

Frame Frame

...

Frame Frame Frame Frame

...

Frame Frame

S E Q U E N Z S E Q U E N Z

Abbildung 2.10: Fibre Channel Framing, Sequencing und Exchange

E X C H A N G E

2. Frame: Ein Frame ist die kleinste, unteilbare Einheit, also das atomare Datenpaket, das über den Link versendet wird. Das Framing-Protokoll und die Frame-Struktur sind in Abbildung 2.10 dargestellt. Die Adressierung des Frames erfolgt über den Frame-Header. Frames sind für die Protokolle der oberen Ebenen des Fibre Channel-Protokoll-Stacks nicht sichtbar und bestehen aus folgenden Feldern: 왘 Start des Frames. Dieser Delimiter eines Frames ist ein Ordered Set. 왘 Frame Header (definiert durch FC-2) 왘 Optionale Header (definiert durch FC-2) 왘 Nutzdaten variabler Länge, die Anwendungsdaten der oberen Ebe-

nen der Fibre Channel-Architektur enthalten (Länge zwischen 0 und 2.112 Bytes) 왘 32-Bit-CRC (Cyclic Redundancy Check) zur Fehlererkennung 왘 End of Frame. Auch dieser Frame Delimiter ist ein Ordered Set.

Jeder Frame oder jede Gruppe von Frames kann als Teil des Flow Control-Schemas vom Empfänger bestätigt werden. Zusätzlich sind noch die Meldungen »Link Busy« und »Delivery Reject« definiert, die benötigt werden, wenn eine Übertragung eines Frames nicht erfolgreich durchgeführt werden konnte.

93


3. Sequenz: In Fibre Channel werden keine Begrenzungen der Größe von Transfers zwischen Applikationen definiert (in LANs ist die Netzwerk-Software sensitiv für die maximale Frame- oder Paketgröße, die übertragen werden kann). Framegrößen sind für die Anwendungen, die Fibre Channel verwenden, transparent, da die Übertragungseinheit, die Anwendungen kennen, eine Datenstruktur einer oberen Ebene des Fibre Channel-Protokoll-Stacks darstellt. Diese Datenstruktur ist die Sequenz. Eine Sequenz wird aus mehreren logisch zusammenhängenden Frames einer Operation aufgebaut, die in die gleiche Richtung des Links fließen. Es ist die Aufgabe der Ebene FC-2, die Sequenzen in die Framegrößen aufzubrechen, die zwischen den kommunizierenden Ports und zwischen den Ports und der Fabric definiert wurden. So wird beispielsweise eine logische Einheit von Daten, die durch ein Protokoll der oberen Ebenen generiert wurde, in eine einzige Sequenz, bestehend aus einem oder mehreren Frames, zusammengefasst und auf der Empfängerseite als solche disassembliert. Daher stellt die Sequenz auch die kleinste Einheit dar, die im Falle des Verbindungsverlustes nach dem Re-Start des Links wiederhergestellt werden kann. Wird ein Übertragungsfehler festgestellt, so identifiziert Fibre Channel die Sequenz als fehlerhaft und erlaubt es, dass diese Sequenz und die auf die defekte Sequenz folgenden Sequenzen erneut übertragen werden können. Jede Sequenz wird von dem Initiator der Sequenz (Anwendung der oberen Fibre Channel-Ebene) eindeutig über den Sequenz-Identifier (SEQ-ID) identifiziert. Auch wird jeder Frame der Sequenz eindeutig mit einem Sequence Count (SEQ-CNT) durchnummeriert. 4. Exchange: Ein Exchange wird aus einer oder mehreren nicht unbedingt direkt aufeinander folgenden Sequenzen einer einzelnen Operation innerhalb einer Anwendung einer höheren Fibre Channel-Protokollebene aufgebaut. So kann eine Operation beispielsweise aus mehreren Phasen bestehen – das erste Kommando soll einige Daten lesen, die ihm direkt folgen und abgeschlossen wird die Operation durch den Completion-Status, also den Zustand, der festhält, ob die Daten erfolgreich gelesen wurden oder nicht. Jede Phase der Operation – Kommando, Daten und Completion-Status – stellt eine eigenständige Sequenz dar, kann jedoch zu einem Exchange zusammengefasst werden. Innerhalb eines Exchange kann zu einem gegebenen Zeitpunkt auf dem Link jeweils nur eine Sequenz fließen – Sequenzen unterschiedlicher Exchanges können dagegen gleichzeitig über den Link fließen. Dies stellt eine Art des Multiplexings dar, die von Fibre Channel unterstützt wird. Der Exchange wird eindeutig von jedem partizipierenden N-Port identifiziert.

94


Abhängig von der Fibre Channel-Implementierung wird dem Exchange durch den die Übertragung über den Link initiierenden N-Port (Initiator der ersten Sequenz) eine Originator Exchange ID (OX-ID) zugewiesen. Der empfangende N-Port (Adressat der ersten Sequenz) weist dem Exchange eine ebenfalls implementierungsabhängige Resender Exchange ID (RX-ID) zu. Die Exchange IDs werden im Frame Header übertragen und von den N-Ports lokal für die Administration des Exchanges verwendet.

Die oberen Fibre Channel-Ebenen Fibre Channel stellt einen Transport-Service zur schnellen und zuverlässigen Übertragung von Daten dar. Dabei ist er so skalierbar, dass die Transferanforderungen nahezu jeder Anwendung erfüllt werden können. Die generischen Dienste der Fibre Channel-Ebene FC-3 erweitern mit dem ULP-Mapping (Upper Layer Protocol) der Fibre Channel-Ebene FC-4 die Funktionalität von Fibre Channel und bieten die allen Anwendungen gemeinen Implementierungen für deren Interoperabilität.

Fibre Channel upper layer – Ebene FC-3 Die Fibre Channel-Ebene FC-3 definiert die generischen Dienste des Fibre Channel-Protokoll-Stacks. Einige der Services sind unverzichtbar für die Fibre Channel-Protokolle, andere sind optionale Erweiterungen der grundlegenden Protokolle. Fibre Channel Services werden im Wesentlichen in switched Fibre Channel-Topologien benötigt. Die Verwaltungsfunktionen der Fibre Channel-Endgeräte werden durch dedizierte Server innerhalb eines Switches gehandhabt und müssen daher nicht auf jedem Knoten administriert und initiiert werden. Dies resultiert in einem einfacheren, leichter zu administrierenden System. Mehrere Switches können über ihre E-Ports (Expansion Port) zu einer Fabric zusammengeschaltet werden. Die Server-Funktionen der Fabric können zentralisiert auf einem Switch der Fabric oder dezentralisiert (verteilt) über sämtliche Switches der Fabric angeboten werden. Jeder Server wird über eine Fabric-weit bekannte, eindeutige, von Fibre Channel reservierte Adresse identifiziert. Während die Server extern als N-Port-Adressen erscheinen, können sie Fabric-intern implementiert sein. Das Protokoll sämtlicher Dienste ist das Fibre Channel Common Transport Protocol (FC-CT). Dieses ist für Fabric-Typ und -Topologie transparent. Die Server unterstützen sämtliche Service-Klassen. Die Fibre Channel-Dienste und deren Funktionen werden in Tabelle 2.8 kurz dargestellt und im Folgenden erläutert:

95


Dienst

Funktion

Login-Server (essentiell erforderlich)

왘 Erkennen der für den Betrieb erforderlichen

Fabric/Switch-Controller (essentiell erforderlich)

왘 Unterstützt Initialisierung und Konfiguration

Charakteristika/Parameter der beteiligten Knoten 왘 N-Port-Adresszuweisung (via WWN – World Wide Name) des Switches/der Fabric 왘 Administration des Routings 왘 Von der Fabric optional unterstützte Dienste

Name-Server (optional)

왘 Übersetzungsdienst für die N-Ports (über-

Management-Server (optional)

왘 Konfigurations-Management 왘 Performance-Management Fehlerbehand-

setzt IDs von – weltweit eindeutigen IEEE-Adressen – IP-Adressen – symbolischen Namen)

lung 왘 Benutzerdefinierte Diagnosen 왘 Accounting

Time-Server (optional)

왘 Management von Expiration Timern 왘 Zeit-Synchronisation

Alias-Server (optional)

왘 Hunt Group-Management 왘 Multicast Group-Management

Quality of Service-Server (optional)

왘 Management des Class 4 Quality of Service

Class 6 Multicast-Server (optional)

왘 Management der Class 6 Multicast Group

Tab. 2.8: Fibre-Channel-Dienste/Server-Funktionen

Login-Server Der Login-Server ist eine Switch-interne logische Einheit, die die LoginRequests an den Switch empfängt und auf sie reagiert. Weiter weist der Login-Server dem N-Port des Knotens, der das Login initiiert, seine Adresse zu oder bestätigt diesem seine Adresse. Weiter kann der Login-Server einen Proxy-Agent darstellen, um einen Name-Server mit den Login-Attributen des N-Ports zu versorgen. Fabric/Switch-Controller Ein Fabric/Switch-Controller bietet sowohl unabdingbar erforderliche als auch optionale Dienste. Obligatorische Dienste sind die Initialisierung, die Konfiguration und das Routing-Management. Optionale Dienste sind Dienste, bei denen die Fabric assistiert. Name-Server Die primäre Funktion des Name-Servers besteht darin, sämtlichen Knoten, die an die Fabric angeschlossen sind, die Möglichkeit zu eröffnen, andere Knoten, deren Attribute und N-Port Identifier zu erkennen. Ein Knoten96


name ist eine acht Byte lange (64-Bit) weltweit eindeutige IEEE-Adresse (WWN – World Wide Name, vergleichbar einer MAC-Adresse). Er kann jedoch auch lokal vergeben werden. Die N-Port Identifier werden vom Name-Server zugewiesen (optional auch vom Login-Server), sobald ein Knoten sich beim Login-Server der Fabric anmeldet.

Server

Storage

Storage

Workstation

Workstation

Abbildung 2.11: Der Name-Server als Verzeichnisdienst eines Fibre Channel-Netzwerks

Server

FC-AL Hub

Arbitrated Loop

Fabric

Server

Workstation

Storage

Server

Nach diesem Zeitpunkt kann ein Knoten (oder sein N-Port) die Beziehung zwischen dem Knoten und seinen zugewiesenen N-Ports registrieren. Weiter bietet der Name-Server die Übersetzung für IP-Adressen, die Protokolle der oberen Ebenen sowie die Dienstklassen, die unterstützt werden. Der Name-Server funktioniert also als Directory-Service des Fibre ChannelNetzwerks für die Attribute: 왘 Native Port Identifier, 왘 Port-Typ, 왘 Port-Name, 왘 Knoten-Name, 왘 Serviceklassen.

Management-Server Fibre Channel hat das in der DV-Industrie allgemein akzeptierte Simple Network Management Protocol (SNMP) für seinen Management-Service adaptiert. Die Daten der Management Information Base (MIB) werden jedem Fibre Channel-Knoten, FC-AL-Hub und jeder FC-SW Fabric zugeordnet.

97


SNMP wird verwendet, diese MIB-Daten zu überwachen und zu modifizieren. Als Transportmechanismus kann SNMP über FC-PH das IP-Protokoll verwenden (konventionelle Anwendung von SNMP). Eine generische Lösung wird ebenfalls angewendet, in der SNMP den FC-CT über FC-PH als Transportmechanismus verwendet, wodurch auf IP verzichtet werden kann (Performance-Aspekte, vor allem für Anschluss von Storage Devices in SAN und remote SAN-Hochverfügbarkeits-Umgebungen). Dies ermöglicht eine konsolidierte Verwaltung von Fibre Channel-Netzwerken, die aus Computersystemen und deren Peripherie bestehen. Time-Server Der Time-Server verwaltet sämtliche Timer (Taktgeber) innerhalb des Fibre Channel-Systems. Er übernimmt die Takt-Synchronisation aller Switch-Elemente und versieht sämtliche Messages zwischen den Komponenten mit Zeitstempeln. Alias-Server Der Alias-Server wird zum Aufbau von Hunt Groups und Multicast Groups verwendet. Als Hunt Group bezeichnet man eine Gruppierung mehrerer Server über jeweils einen N-Port eines ihrer Host-Bus-Adapters (z.B. FC-Adapter) zu nur einem F-Port in der Fibre Channel-Fabric. Der Fibre Channel-Switch »begibt sich auf die Jagd« nach dem ersten freien Port auf dem Switch, wenn andere Clients oder Server mit dem betreffenden Server verbunden werden. Dies ist vergleichbar mit dem Auffinden des ersten verfügbaren Auskunftsplatzes beim Anruf einer Telefonauskunft. Das Ergebnis der Hunt Group ist eine bessere Serverauslastung und ein ausgeglicheneres Antwortzeitverhalten für die Clients. Der Alias-Server verwaltet die Registrierung und Deregistrierung von Aliasen. Die Weitervermittlung (Routing) der Frames ist Aufgabe der Fabric. Eine Multicast Group ist eine Gruppe von N-Ports, die Frames eines N-Ports erhalten, der zur gleichen Gruppe gehört. Der Frame des sendenden NPorts wird an sämtliche andere N-Ports der Multicast Group repliziert. Dabei wird der Class 3-Service verwendet. Jede Multicast Group besitzt ihre eigene Alias-Identifikation (MG-ID). Ein einzelner N-Port kann sich simultan bei mehreren Multicast Groups registrieren, ein N-Port kann also eine Liste von N-Ports als Mitglied einer oder mehrerer Multicast Groups registrieren. Eine Hunt Group ist eine Gruppe von N-Ports unter einer alleinigen Kontrolleinheit. Jede Hunt Group wird mit einer Alias-Identifikation (HG-ID) assoziiert. Eine Hunt Group verwendet für sämtliche Mitglieder der Gruppe daher nur eine Alias-Adresse. Die Fabric adressiert den ersten verfügbaren N-Port innerhalb der Hunt Group als Empfänger für die Serviceklasse. In der Serviceklasse Class 1 ermöglichen die Hunt Groups die Auswahl genau eines verfügbaren N-Ports für eine dedizierte Verbindung. In Class 2 oder Class 3 können Hunt Group-Mitglieder über mehrere verfügbare Ports verteilt werden. Dadurch wird die Übertragungsbandbreite erhöht und/oder die Latenzzeiten verringert. 98

Einführung in die Fibre Channel-Technologie Abbildung 2.12: Alias-Server Hunt Group

Server

N-Port F-Port

Server

N-Port

Server

N-Port

Server

Switch (Fabric) N-Port

Quality of Service-Server Der Quality of Service-Server wird verwendet, um die gewünschte Dienstqualität der Class 4-Services über virtuelle Kanäle aufzubauen. Der Quality of Service-Server ist ein Modul der Fabric zum Aufbau und zur Aufrechterhaltung der Parameter der Dienstqualität aktiver und ruhender virtueller Kanäle (VC, Virtual Circuits). Er ist unabdingbar für Class 4-Services. Quality of Service-Parameter sind: 왘 garantierte minimale Übertragungsbandbreite eines Virtual Circuits, 왘 garantierte maximale Übertragungs-Verzögerung zwischen beiden End-

punkten eines Virtual Circuits. Außer Aufbau und Aufrechterhaltung der Quality of Service-Parameter ist der Quality of Service-Server verantwortlich für die Administration des Auf- und Abbaus einer Class 4-Kanalverbindung. Er stellt basierend auf den verfügbaren Ressourcen und der aktuellen Auslastung sicher, dass die angeforderte Quality of Service gewährleistet ist. Ist sie dies nicht, kommt keine Verbindung über den virtuellen Kanal zustande.

99


Multicast-Server Der Multicast-Server ist ein optionaler Bestandteil einer Fabric, der die Antworten sämtlicher Empfänger-N-Ports einer Class 6-Multicast-Gruppe verwaltet. Nachdem alle Antworten der Empfänger-N-Ports beim Multicast-Server eingegangen sind, sendet dieser ein einziges Acknowledge an den Sender-N-Port in der Multicast-Gruppe. Class 6 Multicasting bietet ein zuverlässiges dienstbasiertes Multicasting über dedizierte Verbindungen. Der zu replizierende Frame wird an den Multicast-Server gesendet. Dieser führt die Replikation und Versendung an die N-Ports der Zielgeräte über separate, dedizierte Verbindungen durch die Fabric aus. Die Fabric ist für die Auslieferung dieser Frames an die N-Ports der Zielgeräte verantwortlich. Der Frame Header eines jeden Frames enthält daher die N-Port IDs sämtlicher Mitglieder der Multicast-Gruppe. Diese wird vom Class 6 Multicast-Server für Replikation und Verteilung der Frames verwendet. Ein NPort wird Mitglied der Multicast-Gruppe, sobald die Verbindung aufgebaut wird. Nach Abbruch der Verbindung wird dem N-Port die Mitgliedschaft in der Multicast-Gruppe entzogen. Abbildung 2.13 gibt die Nutzung der Dienste der Fibre Channel-Ebene FC-3 in der Reihenfolge ihrer Involvierung wieder. Abbildung 2.13: Switch-Initialisierung mit FC-3-Services

4. Process Login über SCSI

2. F-Login WWN und FC-4 Typ (SCSI)

Login-Server

HBA WWN Host

1. LIP Loop Initialisation Process

3. Name-Server Login Host erhält Liste der verfügbaren Empfänger-Ports

Name-Server

Switched Fabric Host erhält Devices, die für ihn bestimmt sind

FA WWN

Login History Table Storage Device

Die Switched Fabric implementiert über die Fibre Channel-Ebene FC-3 einen Login-Serverdienst und einen Name-Serverdienst. Beide besitzen eine Adresse, die allen Knoten bekannt ist (FF FF FC und FF FF FE), die über ihre N-Ports an einen F-Port der Fabric angeschlossen werden.

100


Beim Login an den Switch respektive zum Login-Server der Fabric, werden die WWN und das Übertragungs-Protokoll (Protokoll der Fibre ChannelEbene FC-4, in diesem Falle SCSI) übermittelt. Der Login-Server vergibt für den Knoten eine ID, die bei allen zukünftigen Übertragungen als Adresse verwendet wird. Beim Login an den Switch respektive zum Name-Server der Fabric, erhält der Einwahlknoten die für ihn zur Verfügung stehenden Empfängerports. Zum Storage Device, z.B. einem hochverfügbaren Disk Array oder einem Bandroboter, wird über einen N-Port eines Fibre Channel-Adapters (FA) des Storage Devices ein Process Login über das SCSI-Protokoll durchgeführt. Der Host-Bus-Adapter (HBA) wird in die »Login History Table« eingetragen und erhält die für ihn zur Verfügung stehenden Devices. Die Verwendung der Login History Table zur selektiven Maskierung/Demaskierung für den Host über die WWN/den Port des Switches sichtbarer Devices stellt keine Implementierung eines Standarddienstes von FC-3 dar. Hierbei handelt es sich um einen optionalen, von der Fabric unterstützten Service des Fabric/ Switch-Controller-Dienstes. Wie insbesondere der Zugriff auf Storage Devices über ein Fibre Channel-Switch/eine Switched Fabric administriert und reglementiert werden kann, wird in einem späteren Abschnitt dieses Buches detailliert erläutert.

Fibre Channel upper layer – Ebene FC-4 Die Fibre Channel-Ebene FC-4 dient dem Upper Layer Protocol Mapping (ULP Mapping). FC-4 definiert damit die Fibre Channel-InteroperabilitätsImplementierung für Standard-Protokoll, Audio/Video oder Applikationen wie Real-Time Computing. Jede Fibre Channel-Implementierung wird in einem eigenständigen FC-4-Dokument spezifiziert. Fibre Channel erlaubt es, sowohl Netzwerk- als auch Kanal-Protokolle aufeinander folgend über dieselbe physikalische Schnittstelle zu transportieren. Folgende Protokolle sind als FC-4-Protokolle zurzeit spezifiziert oder vorgesehen: 왘 Small Computer System Interface (SCSI) 왘 Internet Protocol (IP) 왘 Intelligent Peripheral Interface (IPI) 왘 High Performance Parallel Interface (HiPPI) Framing Protocol 왘 Link Encapsulation (FC-LE) unter Verwendung des International Stan-

dards IS8802.2 (entspricht IEEE 802.2) 왘 Single Byte Command Set Mapping (SBCS) zur Implementierung von

ESCON (Enterprise Systems Connection) und Block-MultiplexingSchnittstellen 왘 Audio Video Fast File Transfer und Real Time Stream Transfer 왘 Real-Time, embedded Avionics

101


FC-4 mapped diese Protokolle auf den physikalischen FC-PH-Standard und den Signalstandard. Über die Mapping-Regeln beschreibt ein spezifisches FC-4-Protokoll, wie ULP-Prozesse vom gleichen FC-4-Typ untereinander operieren. Ein Netzwerkbeispiel eines aktiven ULP-Prozesses ist der Transfer eines IEEE-Datenpaketes 802.2 von einem Fibre Channel-Knoten zum anderen. Ein Channel-Beispiel eines aktiven ULP-Prozesses ist eine SCSIOperation zwischen einem Kanal und einem Magnetplattenlaufwerk auf einem Storage Device. Die Fibre Channel-Implementierung erfolgt hardwareseitig, um einen größeren Durchsatz zu erreichen. Typischerweise folgen Kanal-Protokolle einem Kommando-Daten-Status-Paradigma. Jede dieser Informationskategorien besitzt unterschiedliche Attribute und erfordert eine Verarbeitung, die getrennt von der jeweils anderer Informationskategorien vollzogen wird. Dennoch ist die Verarbeitung jeder Kategorie einheitlich für sämtliche Protokolltypen. Die einheitliche Definition dieser Informationskategorien erlaubt auch eine einheitliche Implementierung in der Hardware. Dank der Hardware-Implementierung des ULP-Mappings werden CPU-Zyklen für die I/O-Verarbeitung eingespart, wodurch Server, Workstations und Speichersysteme effizienter genutzt werden.

2.3.4

Fibre Channel-Serviceklassen und -Topologien

Fibre Channel bietet fünf unterschiedliche Serviceklassen: 왘 Class 1 – Acknowledged Connection-Dienst 왘 Class 2 – Acknowledged Connectionless-Dienst 왘 Class 3 – Unacknowledged Connectionless-Dienst 왘 Class 4 – Fractional Bandwith Connection-Oriented-Dienst 왘 Class 5 – Uni-Directional Connection-Dienst

Fibre Channel verbindet Knoten über drei physikalische Topologien, die Varianten besitzen können. Diese Topologien sind: 왘 Point-to-Point 왘 Loop 왘 Switched

Eine Punkt-zu-Punkt-Topologie verbindet lediglich zwei Endgeräte über Fibre Channel, z.B. einen Fibre Channel-Host-Bus-Adapter (HBA) mit einem Fibre Channel Systemadapter eines Storage Arrays. Diese Topologie unterscheidet sich lediglich im Anschlussmedium von klassischerweise über SCSI angeschlossenen Speichergeräten.

102


Host

Storage Array

Abbildung 2.14: Fibre ChannelPoint-to-PointTopologie

Da eine Punkt-zu-Punkt-Verbindung keine Fabric involviert, wird auch kein Fabric-Port benötigt. Auf beiden Knoten wird jeweils über einen N-Port (HBA und Fibre Channel-Systemadapter) die Verbindung aufgebaut. Die Point-To-Point-Topologie stellt also eine Verbindung zweier N-Ports mit einer dedizierten Bandbreite dar. Loops, die an ein unternehmensweites Fibre Channel SAN angeschlossen sind, bezeichnet man als Public Loops. Eine isolierte Fibre Channel Arbitrated Loop bezeichnet man als Private Loop. Eine Loop kann als Daisy Chain von zwei bis 127 Knoten konfiguriert werden, in aller Regel werden jedoch Fibre Channel-Hubs für den Anschluss der Knoten an die Loop eingesetzt. Den Baustein, der die Verbindung multipler N-Ports ermöglicht, bezeichnet man als eine Fabric. Diese wird von einem oder mehreren Fibre ChannelSwitches gebildet. Die Fibre Channel Arbitrated Loop-Topologie wird als FC-AL, die Topologie mit Fabric Switches als FC-SW bezeichnet. Durch die Kombination der Fibre Channel-Serviceklassen mit den unterschiedlichen Möglichkeiten dieser physikalischen Topologien eröffnen sich eine Vielzahl von Konfigurationsund Tuning-Varianten, die insbesondere für SAN- und NAS-Umgebungen mit bisher über SCSI, ESCON, IPI oder HiPPI angeschlossenen Speichersystemen Performance- und Handlings-Verbesserungen der Größenordnungen ermöglichen.

103


2.3.4.1

Fibre Channel-Switched Fabric (FC-SW)

Die primäre Funktion eines Switches ist das Empfangen und Weiterleiten (Routing) von (Data-) Frames eines Quellknotens zu einem Zielknoten. Abbildung 2.15: Fibre ChannelSwitched Fabric (FC-SW)

Hosts

Storage Arrays

Switch (Fabric) Jeder Knoten besitzt eine eindeutige Fibre Channel-Adresse, seinen World Wide Name (WWN). Über diese WWN oder über die Port-IDs wird das Routing durchgeführt (vgl. dazu den Abschnitt Fibre Channel-Switches in Kapitel 4). Für die einzelnen Knoten ist die komplette Topologie, die interne Struktur des Switches sowie die Auswahl des Routing-Pfads innerhalb des Switches transparent. Der Switch ermöglicht eine unkomplizierte Administration der kompletten Topologie. Jeder Knoten der Topologie muss lediglich eine Point-to-Point-Verbindung zum Switch administrieren. Die Administration der kompletten Topologie, des Routings und der möglichen Verbindungen erfolgt zentral in dem Switch. Dabei werden einfachste RoutingAlgorithmen verwendet. Jeder Knoten stellt die WWN des Zielknotens in den Header des Frames, direkt vor die zu übertragenden Nutzdaten. Wird beim Fabric Login diese WWN als »falsch« erkannt, so weist der Switch das Login zurück. Kann der Switch aus irgendeinem Grunde einen Datenframe nicht an der Empfänger-WWN platzieren, so gibt er dem Sender ein »Busy«Acknowledgement, sodass dieser den Frame einfach wiederholen muss. Fibre Channel-Switches erscheinen gegenüber den Knoten eines Fibre Channel-Netzes als die individuelle Verbindungseinheit des jeweiligen Knotens, d.h. die Ports des Switches werden von den Knoten als die Stellen gesehen,

104


an denen die einzelnen Knoten physikalisch miteinander verbunden werden können. Dies bedeutet, dass die Punkt-zu-Punkt-Verbindung zwischen einem N-Port des Knotens und einem F-Port des Switches aufgebaut werden muss. Die Kommunikation der Knoten untereinander über den Switch ist nach Fibre Channel-Standards aufgebaut. Während der Initialisierung meldet sich der Knoten beim Login-Server an, erkennt über diesen automatisch die Topologie, über die er an das Fibre Channel-Netzwerk angeschlossen ist und operiert gemäß dieser Topologie. Der Switch ist dafür verantwortlich, dass die Frames gemäß der gewählten Serviceklasse übertragen werden. Abbildung 2.16: Fibre Channel-Ports in einer FC-SWTopologie

E-Port

Host E-Port

F-Port N-Port

Switch

Host

FL-Port

Switch

Hub

F-Port

Public Loop

Hub

NL-Ports N-Port

Host Private Loop

NL

Host

Host

Storage Array Abbildung 2.16 der Fibre Channel-Ports in der FC-SW-Topologie zeigt, dass die einzige etwas komplexere Aktivität bei der Administration der Topologie darin besteht, die geeignete Art des Ports für die Punkt-zu-Punkt-Verbindung eines Knotens an den Switch zu definieren. Dabei werden sämtliche Beschränkungen, wie z.B. Einschränkungen der Distanz zwischen mehreren Knoten, durch die Wahl der geeigneten Medien und Komponenten des FCSW-Netzwerks überwunden, sodass die Anforderung einer jeden Applikation erfüllt wird. Externe, nicht zu einer Arbitrated Loop zusammengefasste, Fibre ChannelGeräte werden mit jeweils einem N-Port an einen F-Port des Switches angeschlossen. Arbitrated Loops werden über einen NL-Port an einen FL-Port des Switches verbunden. Switches werden untereinander über jeweils einen E-Port zu einer Fabric zusammengebunden. Jede Verbindung zwischen einem N-Port/NL-Port und einem F-Port/FL-Port stellt eine Full DuplexVerbindung zur garantierten Fibre Channel-Bandbreite von 100 MB/Sek. dar. Dank der Möglichkeit der Erweiterung eines Switches zu einer Fabric ist eine FC-SW-Topologie absolut skalierbar. Müssen weitere Knoten angeschlossen werden und ist kein weiterer freier Port am Switch vorhanden,

105


wird die Fabric lediglich um einen Switch erweitert. Die hinzugekommenen Knoten werden mit garantierter Bandbreite über die entsprechenden Ports der erweiterten Fabric bedient. Während der Initialisierung des neuen Switches werden die Pfade und die Adresszuweisung zwischen den Switches in der Fabric automatisch determiniert. Zu jedem Zeitpunkt können Knoten an den Switch angeschlossen oder aus dem Switch entfernt werden. Bei Anschluss eines Knotens meldet sich dieser automatisch beim Switch an und tauscht mit diesem die Operations-Parameter aus. Während des Logins erben die N-Ports die Adresse des korrespondierenden F-Ports beim Switch. NL-Ports erben die oberen 16 Bits des korrespondierenden FL-Ports beim Switch und können bis zu 126 Adressen für die Loop-Mitglieder zuweisen. Dafür werden die unteren acht Bits der Fibre Channel-Adresse des FL-Ports verwendet. Fibre Channel-Switches, die sowohl connectionless als auch verbindungsorientiertes Switching anbieten, sind tatsächlich zwei separate Switches in einem Gerät. Serviceklasse 1 und 6 werden durch einen Circuit Switch realisiert, die Serviceklassen 2, 3 und 4 werden durch einen Frame Switch implementiert. Durch diese einzigartige Fibre Channel-Eigenschaft werden Applikationen die Features beider Switching-Technologien zur Auswahl angeboten. Die Verwendung beider Switch-Technologien ist nicht erforderlich. Es gibt dedizierte Circuit Switches oder dedizierte Frame Switches. Im Frame-Switching Modus wird die Bandbreite dynamisch auf einer Link-fürLink-Basis verteilt. Basierend auf einem adaptiven Routing innerhalb des Switches werden die individuellen Frames zwischen den Switch-Ports unabhängig voneinander geswitched. Während des Frame-Switchings wird Speicherkapazität des Switches benötigt, um eine Link-Level-Kontrolle zwischen dem Switch und dem angeschlossenen N-Port, dem NL-Port oder dem E-Port zu gewährleisten. Zukünftig können über Inter Working Units (IWU) E-Ports an ein WAN angeschlossen werden. Dies ist das Ergebnis eines Joint-Ventures der USamerikanischen und japanischen Fibre Channel-Industrien in den vergangenen Jahren.

2.3.4.2

Fibre Channel-Arbitrated Loop (FC-AL)

Unter der gemeinsamen Bezeichnung FC-AL fasst man die klassischen Loop- und Hub-Topologien zusammen. Die Fibre Channel-Loop bietet eine Möglichkeit, mit der mehrere Devices mit überschaubaren Kosten eine Fibre Channel-Gigabit-Bandbreite teilen können. Die Knoten teilen sich den Zugriff auf die Loop, besitzen jedoch die volle Gigabit-Bandbreite von Fibre Channel zu dem Zeitpunkt, zu dem sie untereinander eine logische Punkt-zu-Punkt-Verbindung aufbauen. Wie oben bereits erwähnt verbindet die Loop-Topologie bis zu 127 Fibre Chan-

106


nel-Ports in einem Daisy-Chain-Mechanismus. Von den maximal 127 Ports kann lediglich einer dazu verwendet werden, die komplette Loop an einen Switch anzuschließen. Abbildung 2.17: Fibre Channel-LoopTopologie

B

B Bypass Mode

I

T

Initiator (HostComputer)

Target (Storage Subsystem)

B Private Loop Direct Attach

B 126 Node Maximum

Das Arbitration Schema von FC-AL wird wie folgt definiert: Die Knoten einer Loop fordern die Control der Loop durch ein Fibre Channel-Signal an. Dieses wird als primitive bezeichnet. Wird dieses Signal von der Loop mit der Adresse des sendenden Knotens zurückgegeben, so besitzt dieser Knoten die Kontrolle über die Loop. Fordern zu einem gegebenen Zeitpunkt zwei oder mehr Knoten oder der Switch-NL-Port die Kontrolle über die Loop an, so wird die Loop-Control an die niedrigste der beteiligten Knotenadressen vergeben. Besitzt ein Knoten oder Switch-Port die Loop-Control, öffnet er eine Full Duplex-, eine Punkt-zu-Punkt-Verbindung zu einem zweiten Knoten oder den FL-Port an einem Switch. Jede Fibre Channel-Serviceklasse kann zur Kommunikation verwendet werden, die meisten Loop-Applikationen verwenden jedoch einen Class 3-Service. Wird die Loop-Control freigegeben, findet ein erneuter Arbitration-Zyklus statt. Innerhalb der Loop wird Fairness dadurch garantiert, dass jeder Knoten gleiche Zugriffsrechte auf die Loop besitzt. Die Loop ist selbstkonfigurierend und kann ohne oder mit einem Switch operieren. Jeder Knoten oder Switch-Port in der Loop erkennt selbstständig seine Umgebung und bedarf zum Betrieb in der Fibre Channel-Umgebung keiner eingreifenden externen Administration. Eine isolierte, nicht über

107


einen NL-Port an einen FL-Port eines Switches angeschlossene, Loop wird als Private Loop bezeichnet. Ist eine Loop via NL-Port/FL-Port an einen Switch angeschlossen, wird sie als Public Loop bezeichnet. Ein Knoten gibt ähnlich einem Token Passing-Netzwerk Frames automatisch an den nächsten Knoten der Loop weiter. Sobald jedoch dieser Knoten eine temporäre Verbindung zu einem anderen Knoten nach dem oben beschriebenen Arbitration-Schema aufgebaut hat, wird der nicht auslieferungsfähige Frame vom Vorgängerknoten so lange für den Zielknoten reserviert, bis zu diesem eine Verbindung aufgebaut werden konnte. Die Knoten der Loop überwachen die Inbound-Line auf Primitive-Signale, die an den jeweiligen Knoten adressiert sind. Wird ein solches Primitive erhalten, das den Aufbau der Verbindung zu einem anderen Knoten ermöglicht, werden sämtliche empfangenen Frames als für diesen anderen Knoten »reserviert« betrachtet und intern an diesen Knoten weitergeleitet. Dieser Mechanismus bietet eine einfache und zuverlässige Kommunikation innerhalb einer Loop. Die Loop kann durch eine Knoten-zu-Knoten-Verkabelung aufgebaut werden. Dies führt dazu, dass jeder einzelne Knoten ein Single Point of Failure für die komplette Loop sein kann. Fällt ein Knoten aus oder wird er auch nur geregelt heruntergefahren, hinterlässt er die komplette Loop als inoperabel. Dies wird durch Port-Bypass-Schaltkreise (PBCs) zum physikalischen Anschluss eines Gerätes an die Loop eingeschränkt. Fibre Channel (FC-AL)Storage Arrays haben auf ihrer Backplane eine Loop implementiert. Die PBCs werden entweder in das Backplane eines Fibre Channel-SpeicherDevices integriert oder über ein externes Device – den Hub – angeschlossen. Dies definiert die Fibre Channel-Hub-Topologie. Abbildung 2.18: Fibre Channel-HubTopologie

Host

Storage Array

Hub (Loop) 108


Der PBC erkennt automatisch das Vorhandensein eines Knotens und fügt diesen in die Loop ein. Ähnlich verhält es sich bei der Entdeckung und Behandlung eines Knotens, der entweder ausgefallen ist oder gezielt heruntergefahren wurde. Der PBC erkennt den ausgefallenen Knoten automatisch als »ausgefallen« und entfernt ihn aus der Loop. Der PBC öffnet die Loop, um entweder einen aktiven Knoten in sie einzubinden, oder er schließt die Loop, sobald ein aktiver Knoten ausfällt oder heruntergefahren wird. Hubs bieten somit auch die Möglichkeit, Knoten während des aktiven Betriebs der Loop in diese zu integrieren oder aus ihr zu entfernen. In FC-AL Storage Arrays können Festplatten im laufenden Betrieb aus den Arrays aus- und eingebaut werden. Diese Hot-Swap-Features machen Fibre Channel-Storage-Management zu einer tragenden Technologie für Storage Area Networks und Network Attached Storage. Fibre Channel (FC-AL) wird in der Zukunft wahrscheinlich SCSI als Standard-Magnetplattenschnittstelle ablösen. Hubs implementieren eine physikalische Sternverkabelung der Fibre Channel Devices der Loop. Diese ist vergleichbar der strukturierten Verkabelung für LANs. Hubs können miteinander verbunden (stacked) werden. Dadurch können auch mit Hubs Loops von bis zu 127 Geräten gebildet werden. Eine Loop stellt ein Netzwerk mit einer geteilten Bandbreite dar. Die einzelnen NL-Ports der Loop verwenden das Arbitration-Schema, um den Zugriff und die Kontrolle auf den Knoten zu erhalten. Nachdem ein NL-Port die Loop-Control erhalten hat, baut er eine logische Punkt-zu-Punkt-Verbindung zu einem anderen NL-Port auf. Daher ist zu einem gegebenen Zeitpunkt stets nur eine Bandbreite von 100 MB/Sek. in der gesamten Loop verfügbar, da es zu diesem Zeitpunkt nur eine logische Punkt-zu-Punkt-Verbindung zwischen zwei NL-Ports geben kann, unabhängig von der tatsächlichen Anzahl der Geräte in der Loop.

2.3.4.3

Fibre Channel-Serviceklassen

Fibre Channel deckt über eine oder mehrere Serviceklassen in Switches und einzelnen Knoten die Anforderungen einer breiten Anzahl von Applikationen ab. Für das Aufsetzen und die Administration der Serviceklassen ist kein manueller Eingriff eines Administrators notwendig, da die Serviceklassen beim Fibre Channel-Login in die Switches und Knoten determiniert werden, die zwischen dem jeweiligen Sender- und Empfängerknoten verwendet werden können. Folgende Serviceklassen werden von Fibre Channel unterstützt:

109


Credit-Based Flow Control

Auslieferung der Frames

Geeignet für welche Applikationen

Class 1 Acknowledged Connection Service

Knoten-zu-Kno- Zuverlässig ten nach Aufund dediziert bau der Verbindung

Große Dateien und Dienste, die die komplette Übertragungsbandbreite benötigen (Full Bandwidth Service)

Class 2 Acknowledged Connection Service

Buffer-to-Buffer Zuverlässig und Knoten-zu- und MultiKnoten plexed

Cluster, Netzwerkapplikationen, Online Transaction Processing (OLTP)

Class 3 Unacknowledged Connection Service

Buffer-to-Buffer Datagramm und Multiplexed

Speichersysteme, Netzwerksysteme, Rundfunk (Broadcast), Multicast

Class 4 Fractional Band-width ConnectionOriented Service

Buffer-to-Buffer Zuverlässig mit und Knoten-zu- garantierter Knoten Servicequalität

Real-Time-Systeme (z.B. Luftraumüberwachung, Prozesssteuerungssysteme) und Real-Time Audio und Video (Audio on Demand, Video on Demand)

Class 6 Uni-Directional Connection Service

Knoten-zu-Knoten nach Aufbau der Verbindung

Zuverlässig und dediziert, unterstützt von MulticastServern

Videoverteilung (One to Many), Datenreplikationen

Tab. 2.9: Fibre Channel-Serviceklassen

Class 1: Acknowledged Connection Service Class 1 bietet einen wirklich verbindungsorientierten Dienst. Dies resultiert in Circuit Switched-Verbindungen mit einer dedizierten Übertragungsbandbreite. Der Vorteil von Fibre Channel Class 1 gegenüber verbindungsorientierten Netzwerkdiensten besteht in der Geschwindigkeit des Verbindungsauf- und -abbaus binnen Mikrosekunden. Beim Verbindungsaufbau wird durch einen Switch ein End-to-End-Pfad zwischen den kommunizierenden Geräten (Fibre Channel-Knoten) aufgebaut. Der einzige Overhead, den Class 1 erfordert, ist der Auf- und Abbau von Verbindungen. Daher eignet sich Class 1 insbesondere zum Datentransfer großer Datenmengen. Der Dienst des Fibre Channel Class 1 bietet eine Empfangsbestätigung des Empfängerknotens zur Gewährleistung der garantierten Auslieferung von Fibre Channel-Frames an den Empfänger. Weiter bietet Fibre Channel Class 1 ebenfalls eine garantierte Auslieferung bei voll ausgenutzter Übertragungs-

110


bandbreite für Anwendungen wie Datensicherung und -wiederherstellung von über Fibre Channel angeschlossenen Speichermedien oder auch Übertragung von Bilddateien aus Speichermedien. Hosts und Workstations

Switch

Storage Arrays und Tape Libraries

Abbildung 2.19: Fibre Channel Class 1 – Service mit dedizierter Bandbreite

Einige Anwendungen verwenden die Eigenschaft der garantierten Auslieferung, um Daten schnell und zuverlässig ohne den Overhead eines Netzwerkes übertragen zu können. »Camp on« ist eine Fähigkeit der Class 1-Services, die es einem Switch ermöglicht, einen aktiven Port zu überwachen und – so dieser Port für eine weitere Verbindung benötigt wird – in einer Warteschlange für noch aufzubauende Verbindungen zu halten. Sobald der aktive Port frei wird, baut der Switch die in der Warteschlange ruhende Verbindung zu diesem Port auf. Durch diesen Dienst eines Switches wird die Dauer des Verbindungsaufbaus reduziert, da der Sender-N-Port nicht ein »Busy« vom Switch geschickt bekommt und sich daher nicht um eine Wiederholung des Verbindungsaufbaus bemühen muss. »Stacked Connect« ermöglicht einem Sender-N-Port, bei einem Switch eine Anzahl aufeinander folgender Verbindungsanforderungen in einer Warteschlange zu platzieren. Auch durch dieses Feature wird der Overhead des Verbindungsaufbaus reduziert und damit der Service des Switches effizienter genutzt. Eine Variation des Class 1-Services ist der so genannte Buffered Service. Dieser wird dazu verwendet, zwei Fibre Channel-Ports zu verbinden, die mit unterschiedlicher Geschwindigkeit operieren.

111


Eine weitere Form des Class 1-Services ist der Dedicated Simplex Service. Normalerweise sind Class 1-Verbindungen stets bidirektional. Im Falle des Dedicated Simplex Service erfolgt die Kommunikation jedoch dediziert in nur eine Richtung. Durch diese Variante wird eine Trennung von sendendem und empfangendem Switching ermöglicht. Dies wird für Applikationen genutzt, bei denen ein Knoten simultan Daten zu einem zweiten Knoten überträgt und Übertragungen eines dritten Knoten empfängt.

Class 2: Acknowledged Connectionless Service Class 2 ist ein verbindungsunabhängiger Dienst. Jeder Fibre Channel-Frame wird unabhängig von einem anderen geswitched. Auch hier wird der Empfang dadurch garantiert, dass der sendende Knoten dem Empfang vom Empfänger durch ein Acknowledgement bestätigt bekommt. Abbildung 2.20: Der Service Fibre Channel Class 2 – niedrige Latenzzeiten bei garantierter Auslieferung

Host

Loop

Switch

Hub

Der Pfad zwischen den beiden miteinander verbundenen Endgeräten ist nicht dediziert. Der Switch multiplexed den Übertragungsverkehr zwischen den N-Ports und den NL-Ports, ohne einen dedizierten Pfad durch den Switch vorzugeben. Die Credit-Based Flow-Control des Class 2-Services eliminiert die Übertragungsengpässe, die in vielen verbindungsunabhängigen Netzwerken vorgefunden werden. Wird ein Zielport als »belegt« vorgefunden, so wird an den sendenden N-Port ein »Busy« zurückgesendet. Dieser kann dann seinen Frame nochmals versenden. Auf diesem Wege kann im Arbitration-Zyklus keine Übertragung verloren gehen, nur weil zu einem gegebenen Zeitpunkt der Switch mit der Übertragung eines anderen Frames

112


beschäftigt war. Die sehr niedrigen Frame-Latenzzeiten machen Class 2-Services geeignet für kürzere Datentransfers, wie sie in den meisten kaufmännischen Applikationen verwendet werden.

Class 3: Unacknowledged Connectionless Service Class 3 stellt – ähnlich wie Class 2 – einen verbindungsunabhängigen Dienst dar. Der entscheidende Unterschied zum Service Class 2 ist, dass die Empfangsbestätigung für einen übertragenen Frame nicht erfolgt. Dieser unacknowledged Transfer wird im Wesentlichen für Broadcasting und Multicasting in Netzwerken und für Massenspeicher-Interfaces in Fibre Channel Arbitrated Loops verwendet. Die Transfersicherheit wird hier von der Arbitrated Loop gewährleistet, die eine logische Punkt-zu-Punkt-Verbindung zwischen den beteiligten Knoten aufbaut und darüber zuverlässig die Daten von und zu den Storage-Systemen überträgt.

Host

Loop Public Loop NL-Port Attach

B

B Bypass Mode

B

T

Initiator (HostComputer)

B Private Loop Direct Attach

Abbildung 2.21: Der Service Fibre Channel Class 3 – Unacknowledged Service für Networking und FC-AL Storage-Systeme

B

Target (Storage Subsystem)

126 Node Maximum

Switch

Die Class 3 Arbitrated Loop-Transfers werden ebenfalls für IP-Netzwerke verwendet. Einige Netzwerkapplikationen verwenden hier die logischen Punkt-zu-Punkt-Verbindungen ohne Einbeziehung des Overheads eines Netzwerk-Protokolls. Dies geschieht, um den Vorteil der garantierten Auslieferung der Frames durch Fibre Channel zu nutzen.

113


Class 4: Fractional Bandwidth Acknowledged ConnectionOriented Service Class 4 stellt einen verbindungsorientierten Dienst mit geteilter Bandbreite dar. Für eine vorhersehbare Dienstqualität (QoS) werden virtuelle Verbindungen mit Bandbreitenreservierung aufgebaut. Eine Class 4-Verbindung ist bidirektional. In jede Übertragungsrichtung ist ein Virtual Circuit (VC) operational. Die bidirektionale Verbindung unterstützt für jeden VC einen unterschiedlichen Set von QoS-Parametern. Abbildung 2.22: Der Service Fibre Channel Class 4 – Unterstützung von Real-TimeAnwendungen

LuftraumÜberwachung

VideoServer

Video-DistributionNetzwerk

Host Switch (Fabric) Diese Quality-of-Service-Parameter beinhalten eine garantierte Übertragungsbandbreite und – abhängig von dieser – eine garantierte Delay-Zeit von Übertragungsbeginn und Übertragungsende. Im Switch ist die QoSFacilitator-Funktion (QoSF) implementiert, die den benötigten QoS für jeden VC verwaltet und aufrechterhält. Ein Knoten kann bis zu 256 gleichzeitige Class 4-Verbindungen reservieren. Das Aufsetzen der QoS-Parameter und der Verbindungsaufbau sind separate Funktionen des Class 4-Dienstes. Ist eine Class 4-Verbindung aktiv, betreibt der Switch ein »Frame Pacing« vom Quellknoten zum Zielknoten. »Pacing« stellt dabei den Mechanismus dar, mit dem der Switch die verfügbare Bandbreite pro VC reguliert. Die Kontrolle auf dieser Ebene sorgt dafür, dass der Switch für den gleichzeitigen Übertragungsbetrieb der Knoten verantwortlich ist, und sie garantiert jedem sendenden Knoten, dass der Empfängerknoten für ihn verfügbar ist.

114


Der Switch multiplexed Frames unterschiedlicher VCs zwischen gleichen und unterschiedlichen Knotenpaaren einer Verbindung. Daher muss Class 4 sicherstellen, dass die Frames beim korrekten Empfängerknoten in der richtigen Reihenfolge ankommen. Die Flow-Control des Class 4-Services ist daher eine End-to-End-Flow-Control mit garantierter Auslieferung der Frames. Der Class 4-Service ist daher die geeignete Wahl für zeitkritische RealTime-Applikationen und Applikationen wie Video-on-Demand.

Class 6: Uni-Directional Connection Service With Multicast And Preemption Class 6 vergleichbar mit dem Dienst Fibre Channel Class 1 und bietet einen verbindungsorientierten, uni-direktionalen Dienst mit zuverlässigem Multicasting und Preemption. Dadurch ist der Class 6-Service geeignet für VideoBroadcating- und Real-Time-Applikationen mit hohem Datentransferbedarf. LuftraumÜberwachung

VideoServer

Abbildung 2.23: Fibre Channel Class 6 – Dedizierte One-to-ManyDienste

Netz von Radar-Bildschirmen

Video-DistributionNetzwerk

Real Time Sensor, bspw. Radar

Switch (Fabric)

Fibre Channel unterstützt einen optionalen Intermix-Modus. Intermix erlaubt die Reservierung einer kompletten Fibre Channel-Übertragungsbandbreite für eine dedizierte Class 1-Verbindung. Weiter erlaubt der Intermix-Modus einen verbindungslosen Verkehr innerhalb des Switches während inaktiver Class 1-Übertragungen, um die Verbindung (den Link) dieser Übertragung mit anderen Übertragungen zu teilen. Eine ideale Anwendung für den Intermix-Modus ist das Verbinden multipler großer Dateitransfers während Komplett-Datensicherungen. Während eines laufenden Class 1-Dateitransfers kann eine Class 2- oder Class 3-Message an den Backup-Server verschickt

115


werden, um den nächsten Transfer anzustoßen. Nach Abschluss des ersten Transfers kann dann der zweite automatisch beginnen. Dadurch wird die Effizienz eines Fibre Channel Backup-Systems besser ausgenutzt. Die in diesem Kapitel dargestellten Basis-Technologien stellen die Grundlage der heutigen SAN- und NAS-Implementierungen dar. Im folgenden Kapitel sollen – basierend auf diesen Basis-Technologien – die typischen SAN-Topologien und deren Verwendung dargestellt werden.

116

3

SAN ConnectivityTopologien

Die gemeinsame Nutzung von Speicherkapazitäten durch unterschiedliche Rechner folgt den Anforderungen dedizierter Kundenanwendungen. Diese dedizierten Anwendungen führten dazu, dass SAN-Lösungen in speziellen Topologien realisiert wurden, die Storage Area Networks charakterisieren. Die Reinformen dieser Topologien lösen folgende Anforderungen: 왘 Erweiterung der Speicherkapazität einzelner Server 왘 Zusammenführen der Speicherkapazität mehrerer Server 왘 Zentrale Speicherverwaltung an einem anderen Ort als dem Standort ei-

nes oder mehrerer Server Zur Erweiterung der Speicherkapazität wurde die KapazitätserweiterungsTopologie implementiert. Diese dient dazu, einem Server mehr Magnetplattenspeicher zur Verfügung zu stellen, als technisch serverintern anschließbar ist. Abbildung 3.1: SAN-KapazitätserweiterungsTopologie

Fibre ChannelSwitch

Storage Array 1 NT-Server

Storage Array 2

Storage Array 3

Storage Array 4

117

3 SAN Connectivity-Topologien

Die Kapazitätserweiterungs-Topologie ist sowohl in herkömmlichen Device-Connectivity-Technologien (z.B. SCSI), als auch in der Fibre Channel-Technologie via FC-AL oder FC-SW wie im Beispiel der Abbildung 3.1 realisierbar. Weiter kann die Kapazitätserweiterung auch durch eine gemischte Anschluss-Technologie realisiert werden. Die Zusammenführung der Speicherkapazität mehrerer Server wird durch die Storage-Konsolidierungs-Topologie realisiert. Diese Topologie wurde basierend auf Rezentralisierungsanforderungen entwickelt, mit denen zumindest der Massenspeicher zentral administriert werden kann, wenn auch die Serverleistungen weiterhin dezentral zur Verfügung gestellt werden. Abbildung 3.2: Speicher-Konsolidierungs-Topologie

Fibre ChannelSwitch

NT-Server 1

Sun-Server 2

Storage Array HP-Server 3

IBM-Server 4

Auch für die Speicher-Konsolidierungs-Topologie können herkömmliche Anschluss-Techniken, die Fibre Channel-Technologie und gemischte Technologien eingesetzt werden. Hierbei ist zu beachten, dass die Speicher-Konsolidierungs-Topologie auch dazu verwendet werden kann, heterogene Serverlandschaften mit heterogenen Betriebssystemen und Unterstützung ebenso heterogener Dateisysteme an ein und dasselbe Speicher-Gerät anzuschließen. Dies deutet schon auf eine wesentliche Eigenschaft eines intelligenten Storage Arrays hin – die Unterstützung unterschiedlicher Dateisysteme. Die zentrale Speicherverwaltung an einem anderen Ort als dem Standort eines oder mehrerer Server definiert auf den ersten Blick eine klassische FileServer-Funktionalität. Ein oder mehrere Server teilen sich ihren Massenspeicher und stellen die von ihnen verwalteten Dateien über ein Netzwerk zur Verfügung. Dies ist eine klassische Network Attached Storage (NAS)-Anwendung und soll erst in einem späteren Abschnitt erläutert werden.

118

In SAN-Umgebungen, die als Alternative des Direct Attached Storage-Speichersysteme über das Storage Area Network an ihre Server anschließt, definiert die zentrale Speicherverwaltung an einem anderen Ort als dem Standort eines oder mehrerer Server die Verwendung von Fibre Channel als Anschluss-Technologie. Jede herkömmliche Anschlusstechnik scheitert hier an der Barriere der Verkabelungsdistanz. Wie bereits in Abschnitt 2.1. dargestellt, sind sämtliche herkömmlichen Anschlusstechniken auf Kabellängen von wenigen Metern beschränkt. Lediglich Fibre Channel kann hier größere Distanzen von bis zu 60 km zwischen Server und Massenspeicher (über Nutzung von Telefon-Protokollen auch darüber hinaus) überwinden. Die Distanz-Topologie ist die Topologie der Wahl, wenn die Anwendung Hochverfügbarkeitsanforderungen an die Speichersysteme stellt.

Seite A Server Aktiver Zugriffspfad

Seite B Server

Storage Array 1

Remote Spiegel

Recovery Zugriffspfad

Aktiver Zugriffspfad

Recovery Zugriffspfad

Lokaler Lokale Spiegel Quelle

Abbildung 3.3: Distanz-Topologie

Privates Fibre Channel

Storage Array 2

Lokaler Lokale Spiegel Quelle

Remote Spiegel

Klassisches Identifizierungsmuster einer solchen Distanz-Topologie sind die bereits optisch erkennbaren Hochverfügbarkeitsmerkmale, die sich aus der Redundanz der eingesetzten Systembausteine ergeben. Auf beiden Seiten der Distanz-Topologie befinden sind (gleichartig dimensionierte) Server. Diese sind aus dem Hochverfügbarkeitsaspekt über zwei Pfade mit jeweils einem lokalen Storage Array verbunden. Von den beiden Pfaden ist jeweils einer aktiv, der zweite stellt lediglich ein Recovery dar, auf das zurückgegriffen wird, wenn der aktive Zugriffspfad ausfällt. Intelligente Connectivity-Software und Hardware kann hier über beide Zugriffspfade einen Lastausgleich erzielen. Die Storage Arrays können über Fibre Channel-Adapter oder auch herkömmlich, z.B. über SCSI-Adapter, an die Server angeschlossen werden. Die gestrichelte Linie (- - -) stellt eine Verbindung eines Servers mit dem

119


jeweils anderen Storage Array dar. Diese geschieht sinnvollerweise über einen Fibre Channel-Adapter und dient dazu, dass der jeweilige Server auf die remote Spiegel »seiner« lokalen Quellplatten zugreifen kann, falls sein »lokales« Storage Array im Katastrophenfall komplett ausfällt. Innerhalb der Storage Arrays wird eine lokale Quellplatte auf eine lokale Spiegelplatte kopiert, die im Falle des Ausfalls der lokalen Quelle an deren Stelle tritt. Zusätzlich existiert für die lokale Quelle im jeweils anderen Storage Array ein remote Spiegel, ebenfalls eine 1:1-Kopie der lokalen Quellplatte. Über entsprechende Controller der beiden Storage Arrays werden diese remote Spiegel idealerweise ohne Ausnutzung der I/O-Kanäle der angeschlossenen Server gepflegt. Eine solche Topologie für einen Katastrophenfall in einer hochverfügbaren Systemumgebung lässt sich sinnvollerweise nur über Distanzen realisieren, die über die herkömmlicher Anschlusstechniken hinausgehen.

3.1

Die KapazitätserweiterungsTopologie

Die Kapazitätserweiterungs-Topologie soll im Folgenden sowohl unter Einsatz klassischer Anschlusstechniken als auch unter Verwendung der Fibre Channel-Technologie dargestellt werden. Letztlich kann eine Kapazitätserweiterung eines Servers auch durch einen Mix von Connectivity-Technologien erreicht werden. Dieser Aspekt wird ebenfalls behandelt.

3.1.1

Kapazitätserweiterungs-Topologie in Non Fibre Channel-Umgebungen

Ein Non Fibre Channel-Anschluss von Speichersystemen erfolgt über die klassischen Anschlusstechniken des Parallelanschlusses (z.B. über Centronics-Parallelschnittstellen), SCSI (Small Computer Systems Interface) oder ESCON (Enterprise Storage Connectivity). Dabei werden Speichersysteme über entsprechende Adapter mit dem Server verbunden. Der klassische Ansatz für eine Kapazitätserweiterung durch Anschluss mehrerer externer Storage Arrays soll am Beispiel eines Anschlusses über SCSI erläutert werden: Am Serverrechner können über vier Ports eines Standard-SCSI-Host-BusAdapters (SCSI-HBA) maximal vier externe SCSI-Devices angeschlossen werden. Um ein Storage Array an einen HBA-Port anschließen zu können, muss das Storage Array ebenfalls über einen SCSI-Front-End-Controller verfügen. SCSI-Systemadapter (SA) besitzen ebenfalls vier Ports, über die jeweils eine direkte Verbindung zu einem SCSI-HBA-Port eines Serversystems geführt werden kann. In der dargestellten Kapazitätserweiterung (vgl. Abb. 3.4) werden die vier HBA-Ports des Servers mit je einem SA-Port von

120

Die Kapazitätserweiterungs-Topologie

vier Storage Arrays verbunden. Der dargestellte NT-Server kann nun sämtliche Magnetplatten sehen und nutzen, die über den jeweiligen SA des Storage Arrays zugreifbar sind (zum Aufbau hochverfügbarer Storage Arrays vgl. Kapitel 4.2.).

S A

Storage Array 1

S A

Storage Array 2

S A

Storage Array 3

S A

Storage Array 4

Abbildung 3.4: Kapazitätserweiterung – Direct Attached SCSI

Port A

NT-Server

S C S I H B A

Port B

Port C

Port D

Hochverfügbar wird eine solche Direct Attached SCSI-Kapazitätserweiterungskonfiguration dadurch, dass sowohl auf Serverseite als auch bei den Storage Arrays die Komponentenredundanz eingeführt wird. Bei Verwendung zweier Host-Bus-Adapter und zweier Systemadapter je Storage Array ist es möglich, jedes Storage Array und damit auch jede für den Server sichtbare Magnetplatte im Storage Array über zwei Pfade anzusprechen. Dieses Dual Pathing oder Dual Porting der Storage Devices ist jedoch mit einigen Problemen verbunden. Dazu soll noch einmal auf die Controller-Target-LUN-Mimik (vgl. Kapitel 2.1.) der Benennung von SCSIDevices zurückgekommen werden. In unserem obigen Beispiel erreichen wir jede Platte in den Storage Arrays über zwei Controller. Sei der obere Host-Bus-Adapter der Controller 0, der untere Controller 1, weiter sei Port A das jeweilige Target 0, Port B das Target 1, Port C das Target 2 und Port D das Target 3 des jeweiligen Controllers, so sind die Magnetplatten der Storage Arrays unter folgenden physikalischen Devicenamen für das Serversystem sichtbar (vgl. Tab. 3.1).

121

3 SAN Connectivity-Topologien Abbildung 3.5: Kapazitätserweiterung – Hochverfügbares Direct Attached SCSI

S A

Storage Array 1

Port A S C S I H B A

S A

Port B Port C

S A

Storage Array 2 Port D

S A

Port A

S A

NT-Server

S C S I H B A

Storage Array 3

Port B S A

Port C S A

Port D

Storage Array 4 S A

HBA

Port

Storage Array

Physikalische Devicenamen

Oben

A

1

c0t0d0 c0t0d1 c0t0d2 ... c0t0d(n-1) c0t0dn

B

2


C

3


Tab. 3.1: Hochverfügbares Direct Attached SCSI – Physikalische Devicenamen

122


HBA

Unten

Port

Storage Array


D

4


A

1


B

2


C

3


D

4


Tab. 3.1: Hochverfügbares Direct Attached SCSI – Physikalische Devicenamen (Forts.)

Werden die Magnetplatten über Volume-Management-Software nun zu Devicegruppen zusammengeführt, muss sichergestellt werden, dass zum Boot-Zeitpunkt stets über korrekte Pfade zugegriffen wird. Weiter muss darauf geachtet werden, dass jeglicher Anwendung beide Zugriffspfade bekannt gemacht werden, da sonst trotz hardwareseitiger Redundanz im Falle eines HBA- oder SA-Ausfalls die Software den zweiten Pfad nicht nutzen kann. Zu diesem Zweck wurde Storage Management-Software wie z.B. DMP (dynamic multipathing) von Veritas oder Powerpath von EMC2 entwickelt, die die Nutzung beider Pfade durch die Anwendungen gewährleistet (vgl. Kapitel 5).

123


3.1.2

Kapazitätserweiterungs-Topologie in Fibre Channel-Umgebungen

Die Kapazitätserweiterungs-Topologie in Fibre Channel-Umgebungen entspricht der in Non Fibre Channel-Umgebungen insoweit, als auch hier über einen einzigen Fibre Channel-Host-Bus-Adapter eine Vielzahl von Storage Arrays über entsprechende Fibre Channel-System-Adapter angeschlossen werden können. Die Kapazitätserweiterung in Fibre Channel-Umgebungen kann sowohl über Arbitrated Loop als auch über Switched Fabric realisiert werden.

3.1.2.1

Kapazitätserweiterung in FC-AL-Umgebungen

Abbildung 3.6 zeigt die typische Kapazitätserweiterungs-Topologie in einer Fibre Channel Arbitrated Loop (FC-AL)-Umgebung. Der Fibre ChannelHost-Bus-Adapter (FC-HBA) eines Servers ist über einen seiner beiden Fibre Channel-N-Ports an einen NL-Port eines FC-AL-Hubs angeschlossen. Abbildung 3.6: Kapazitätserweiterung in FC-ALUmgebungen

F A

Storage Array 1

F A

Storage Array 2

F A

Storage Array 3

F A

Storage Array 4

Port A

NT-Server

F C H B A

FC-AL HUB

Port B

Dieser ist wiederum über einen oder mehrere NL-Ports an jeweils einen von zwei N-Ports eines Fibre Channel-Systemadapters (FA) der Storage Arrays angeschlossen. In der Topologie der Abbildung 3.6 sieht der Host nun über seinen Fibre Channel-HBA sämtliche Magnetplatten der Storage Arrays, auf die über den jeweiligen FA zugegriffen werden kann. Auch in dieser Topolo-

124


gie wird lediglich eine reine Kapazitätserweiterung betrieben. Hochverfügbarkeit ist durch die Häufung der Single Points of Failure (FC-HBA, FC-ALHub, FA je Storage Array) nicht gewährleistet. Eine Hochverfügbarkeit in der FC-AL-Kapazitätserweiterungs-Topologie stellt sich wie folgt dar: F A

Storage Array 1

Port A F C H B A

F A

FC-AL HUB

Abbildung 3.7: Hochverfügbare Kapazitätserweiterung in einer FC-AL-Umgebung

F A

Port B

Storage Array 2 F A

NT-Server

F A F C H B A

Storage Array 3

Port A FC-AL HUB

Port B

F A

F A

Storage Array 4 F A

Bei Verwendung zweier Fibre Channel-Host-Bus-Adapter und zwei Fibre Channel-Systemadapter je Storage Array ist es auch in der FC-AL-Umgebung möglich, jedes Storage Array und damit auch jede für den Server sichtbare Magnetplatte im Storage Array über zwei Pfade anzusprechen. Die oben beschriebene Problematik gilt auch für die Fibre Channel-Umgebung. In unserem obigen Beispiel erreichen wir jede Platte in den Storage Arrays über zwei Controller. Sei der obere Host-Bus-Adapter der Controller 0, der untere Controller 1, so können nun jedoch nicht mehr so einfach die einzelnen Devices benannt werden. Hier gibt nun die Reihenfolge der Hub-NLPorts zu den Fibre Channel-Systemadaptern der Storage Arrays das Kriterium der Wahl für die Target-Bezeichnung vor. Auch in Fibre Channel-Umgebungen wird durch Dynamic Multipathing Software wie DMP von Veritas, Powerpath von EMC2 oder mithilfe der PV Links unter HP-UX die Hochverfügbarkeit der Magnetplatten der Storage Arrays für die Anwendungen sichergestellt. Hier wird host-basiert die Hochverfügbarkeit bei Verlust eines Hubs, FC-HBAs oder FAs sichergestellt.

125


HBA

Port

Oben

Storage Array


1


2


3


4


Hub oben NL-Port-A

Hub oben NL-Port-B

Hub oben NL-Port-C

Hub oben NL-Port-D

Unten

1


2


3


Hub unten NL-Port-A

Hub unten NL-Port-B

Hub unten NL-Port-C

Tab. 3.2: Hochverfügbares FC-AL – physikalische Dateinamen

126


HBA

Port

Storage Array


4


Hub unten NL-Port-D

Tab. 3.2: Hochverfügbares FC-AL – physikalische Dateinamen (Forts.)

3.1.2.2

Kapazitätserweiterung in FC-SWUmgebungen

Das logische Konzept der Kapazitätserweiterungs-Topologie in einer Switched Fabric Fibre Channel-Umgebung wird durch die »fan-in-rate« beschrieben. Das »in« bezieht sich dabei auf die Anzahl der Storage Arrays, die über den Switch von nur einem Fibre Channel-Host-Bus-Adapter erreicht werden können.

Port A

NT-Server

F C H B A

FCSwitch

F A

Storage Array 1

F A

Storage Array 2

F A

Storage Array 3

F A

Storage Array 4

Abbildung 3.8: Kapazitätserweiterung in einer FC-SW-Umgebung

Port B

Abbildung 3.8 zeigt die typische Kapazitätserweiterungs-Topologie in einer Fibre Channel-Switched Fabric (FC-SW)-Umgebung mit einer Fan-in-Rate von 4. Der Fibre Channel-Host-Bus-Adapter (FC-HBA) eines Servers ist über einen seiner beiden Fibre Channel-N-Ports an einen F-Port eines FC-SW Fabric Switches angeschlossen. Über vier F-Ports dieses Switches werden die vier Fibre Channel-Systemadapter der Storage Arrays mit jeweils einem ihrer N-Ports verbunden. In der Topologie der Abbildung 3.8 sieht der Host 127


nun über seinen Fibre Channel-HBA sämtliche Magnetplatten der Storage Arrays, auf die über den jeweiligen FA zugegriffen werden kann. Auch in dieser Topologie wird lediglich eine reine Kapazitätserweiterung betrieben. Hochverfügbarkeit ist durch die Häufung der Single Points of Failure (FCHBA, FA je Storage Array) nicht gewährleistet. Der Switch als Single Point of Failure wurde hier nicht erwähnt, da hochverfügbare Fibre Channel-Switches die benötigte Hardwareredundanz mit der entsprechenden Switchimplementierten Software bieten. Dennoch kann auch ein kompletter Switch als redundantes System eingebunden werden. Eine Hochverfügbarkeit in der FC-SW-Kapazitätserweiterungs-Topologie (mit nur einem hochverfügbaren Switch) stellt sich wie folgt dar: Abbildung 3.9: Hochverfügbare Kapazitätserweiterung in einer FC-SW-Umgebung

F A

Storage Array 1

Port A F C H B A

FCSwitch Port B

F A

F A

Storage Array 2 F A

NT-Server

F A F C H B A

Port A

Port B

Storage Array 3 F A

F A

Storage Array 4 F A

Hier sind wiederum serverseitig zwei Fibre Channel-HBAs über einen Fibre Channel-Switch mit den vier Storage Arrays verbunden. Jedes der Storage Arrays besitzt zwei Fibre Channel-Systemadapter, die über den Switch vom Host angesteuert werden. Die Namensgebung für die Devices, die der Host sieht, ist in der Switched Fabric-Umgebung bestimmt durch das Zoning beim Switch und evtl. durch eine Software, die die Sichtbarkeit der Devices auf den Storage Arrays für einzelne Hosts einschränkt. Auf das Zoning und die Einschränkung des Devicezugriffs soll weiter unten und in Kapitel 4 eingegangen werden.

128

Storage-Konsolidierungs-Topologie

3.2

Storage-KonsolidierungsTopologie

3.2.1

Storage-Konsolidierungs-Topologie in Non Fibre Channel-Umgebungen

Die Storage-Konsolidierungs-Topologie dient dazu, unter mehreren Servern, die evtl. sogar unterschiedliche Betriebssysteme mit unterschiedlichen Dateisystemen unterstützen, ein gemeinsames Speichergerät zu teilen. Damit ist die Konsolidierungs-Topologie eine Topologie, mit der Rezentralisierungskonzepte für Server-Storage implementiert werden können. In einer Non Fibre Channel-Umgebung ist eine Konsolidierungs-Topologie durch den direkten Anschluss der Hosts über Host-Bus-Adapter an Systemadapter eines Storage Arrays realisierbar. Bei Verwendung des SCSI-Interface-Standards ist es denkbar, dass bis zu vier Server über jeweils einen Port ihres SCSI-Host-Bus-Adapters an jeweils einen der vier Ports eines SCSISystemadapters eines Storage Arrays angeschlossen werden.

NT-Server

IBM-Server

Sun-Server

HP-Server

SC SI HB A

SC SI HB A

SC SI HB A

SC SI HB A

Abbildung 3.10: KonsolidierungsTopologie in Non Fibre-Umgebungen

Port A Port B Port C Port D


Port A Port B Port C

Storage S A

Array 1

Port D


Die generelle Problematik der Konsolidierungs-Topologie besteht darin, dass jeder Server, der über einen Systemadapter des Storage Arrays an dieses angeschlossen wird, in der Lage ist, alle Magnetplatten des Storage Arrays zu sehen, die über diesen Systemadapter sichtbar sind. Für Abbil-

129


dung 3.10 bedeutet das, dass die vier angeschlossenen Server alle Devices des Storage Arrays sehen. Hier muss nun sichergestellt werden, dass der Zugriff auf die Platten unter den Servern eingeschränkt wird, sodass ein Direct Attached Storage ermöglicht wird. Das Sharing der Devices wäre tödlich, die Konsistenz der Dateisysteme wäre nicht zu gewährleisten. Dieses Problem kann dadurch umgangen werden, dass das Storage Array mit jeweils einem Systemadapter pro angeschlossenem Serversystem versehen wird. Diese Systemadapter müssen auf unterschiedlichen Bussen des Storage Arrays liegen. Die Magnetplatten des Storage Arrays sollten dann auf eine gleiche Anzahl von Disk-Adaptern verteilt werden, die jeweils nur an den Bus gebunden werden, auf dem auch der jeweilige Systemadapter des Servers liegt. Dadurch wird sichergestellt, dass ein Server tatsächlich lediglich »seine« Platten sieht und nicht auch Platten eines anderen Hosts. Der interne Aufbau eines Storage Arrays wird in Kapitel 4.2. detailliert beschrieben. Hier soll eine solche Konfiguration lediglich skizziert werden. Diese Implementierung einer klassischen Konsolidierungs-Topologie soll als »sicher« referenziert werden, da durch sie sichergestellt wird, dass die Server sicher nur die Magnetplatten erkennen, die auf dem Storage Array für sie bereitgestellt werden. Abbildung 3.11: Sichere Konsolidierungs-Topologie in Non Fibre-Umgebungen

NT-Server

SC SI HB A


S A

IBM-Server

SC SI HB A


S A

Storage

S Sun-Server

SC SI HB A


A

Array 1

S A

HP-Server

SC SI HB A


Der Hochverfügbarkeitsansatz für eine sichere Non Fibre-Konsolidierung erfordert nun schon auf Seiten des Storage Arrays nahezu einen Vollausbau der Systemadapter. In Abbildung 3.12 wird aus Gründen der Übersichtlichkeit lediglich eine Konsolidierung mit zwei Serversystemen dargestellt. In dieser Topologie ist darauf zu achten, dass die Systemadapter des Storage

130


Arrays, über die die beiden Pfade des jeweiligen Servers verbunden werden, Storage Array-intern auf dem gleichen Bus liegen, auf dem auch der DiskAdapter der Magnetplatten liegen muss. In einer solchen hochverfügbaren Konfiguration wird wie unter der Kapazitätserweiterungs-Topologie jede Magnetplatte für den Server doppelt sichtbar, d.h. eine Magnetplatte ist über zwei Controller-Target-LUNs erreichbar. Hier muss wieder mit entsprechender server-basierter Software sichergestellt werden, dass die Platte konsistent von den Applikationen adressiert wird. Intelligente server-basierte Software kann auch hier wiederum ein Load-Balancing, d.h. eine ausgeglichene Verteilung der I/O-Last, bewirken. Betrachtet man abschließend sämtliche Non Fibre-Topologien, so könnte man auf den ersten Blick davon ausgehen, dass auch mit herkömmlichen Anschlusstechniken Storage Area Networks implementiert werden können. Betrachtet man lediglich das erreichte Ziel, so lassen sich definitiv einige Anforderungen von SANs auch mit herkömmlichen Technologien realisieren. Die Erweiterung der Speicherkapazität eines Serversystems über die Kapazitätserweiterungs-Topologie erfüllt sicherlich die Mengenanforderungen eines großen Teils der Anwendungen, für die auch SAN-Lösungen angedacht werden. Rezentralisierungsstrategien können – was den zentralen Speicherplatz anbelangt – sicher auch mit der Konsolidierungs-Topologie der Non Fibre-Umgebung angegangen werden. Sogar groß angelegte Backup-Lösungen, die bei klassischer Anschlusstechnik server-basiert implementiert werden, können mit direktem Anschluss von Tape-Robotern/ Tape-Libraries realisiert werden, solange auf den beteiligten Servern noch ein SCSI-Slot frei ist. Dennoch sind Non Fibre-Umgebungen eng verbunden mit dem Begriff des »Direct Attachment« der Storage Devices. Direct Attachment heißt, externe Host-Bus-Adapter werden tatsächlich dafür verwendet, die Speichersysteme, seien es Storage Arrays, seien es Tape-Libraries oder Ähnliches, direkt an den Server anzuschließen. Wo ist das N des SAN-Begriffes? Hier fehlt tatsächlich alles, was ein Storage Network definiert. Jeder Host sieht nur »seine« Magnetplatten, diese sind z.B. über SCSI direkt an ihn angeschlossen. Ein »Teilen« eines Storage Arrays findet nicht statt. Ebenfalls fehlt bei klassischen Anschlusstechniken alles das, was das A des SAN-Begriffes definieren könnte. Wie bitte kann hier die Area definiert werden? Die klassische Storage Area wird vorgegeben von der maximalen Kabellänge zwischen Server-HBA und Storage Array-SA. Diese beträgt jedoch nur mehrere Meter. Kapazitätserweiterungs- und Konsolidierungs-Topologien in Non Fibre-Umgebungen erfordern die lokale Gruppierung der Server und »ihres« Speichers in einem Raum. Client-/Server-Speicherkonsolidierungen sind mit klassischen Anschlusstechniken nicht realisierbar.

131

3 SAN Connectivity-Topologien Abbildung 3.12: HochverfügbarkeitsKonsolidierungsTopologie in Non Fibre ChannelUmgebungen

SC SI H B A

NT-Server


SC SI H B A


SC SI H B A

AIX-Server


SC SI H B A

S A S A S A S A

Storage Array 1


Die klassischen Ansätze der Kapazitätserweiterungs- und der Konsolidierungs-Topologie definieren kein SAN – sie sollten nur dargestellt werden, um dem Vorwurf der Unvollständigkeit zu entgehen. Fibre Channel-Topologien sind es, in denen Storage Area Networks definiert und implementiert werden.

3.2.2

Storage-Konsolidierungs-Topologie in Fibre Channel-Umgebungen

Die Storage-Konsolidierungs-Topologie in Fibre Channel-Umgebungen dient ebenfalls dazu, Rezentralisierungs-Anforderungen für die Speichermedien zu erfüllen. Die folgenden Abschnitte beschreiben die Realisierung der Konsolidierung unter Einsatz von FC-AL- und FC-SW-Technologien.

3.2.2.1

Speicherkonsolidierung in FC-ALUmgebungen

Diese Konsolidierungs-Topologie liefert die Möglichkeit, über den Speicher unterschiedliche Server zu verbinden. Die Konsolidierungs-Topologie wird bei vielen Windows-NT-Anwendungsumgebungen erforderlich, bei denen eine Vielzahl kleiner Server mit geringer Speicherkapazität auf ein Storage

132


Array mit großer Speicherkapazität über FC-AL zugreifen. Dies erweitert die Anzahl der Server-Verbindungen an das Storage Array, das evtl. lediglich mit einem Fibre Channel-Systemadapter ausgestattet ist.

NT-Server

IBM-Server

Sun-Server

HP-Server

F C HB A

F C HB A

F C HB A

F C HB A

Abbildung 3.13: Speicherkonsolidierung in FC-ALUmgebungen

Port A

Port B

Port A

Port B

Port A

Storage FC-AL HUB

F A

Array 1

Port B

Port A

Port B

Der Fibre Channel-Host-Bus-Adapter (FC-HBA) eines jeden Servers ist über einen seiner beiden Fibre Channel-N-Ports an einen NL-Port eines FC-ALHubs angeschlossen. Dieser ist wiederum über einen oder mehrere NL-Ports an jeweils einen von zwei N-Ports eines Fibre Channel-Systemadapters (FA) des Storage Arrays angeschlossen. In der Topologie der Abbildung 3.13 sieht jeder Host nun über seinen Fibre Channel-HBA sämtliche Magnetplatten des Storage Arrays, auf die über den FA zugegriffen werden können. In dieser Topologie wird lediglich eine reine Speicherkonsolidierung betrieben. Hochverfügbarkeit ist durch die Häufung der Single Points of Failure (FCHBA, FC-AL-Hub, FA des Storage Arrays) nicht gewährleistet. Eine Hochverfügbarkeit in der FC-AL-Speicherkonsolidierungs-Topologie stellt sich wie folgt dar: Bei Verwendung zweier Fibre Channel-Host-Bus-Adapter je Server und zweier Fibre Channel-Systemadapter im Storage Array ist es auch in der FCAL-Umgebung möglich, ein Storage Array und damit auch jede für den jeweiligen Server sichtbare Magnetplatte im Storage Array über zwei Pfade anzusprechen. In unserem Beispiel der Abbildung 3.14 erreichen wir jede Platte im Storage Array über zwei Controller. Ist der obere Host-Bus-Adapter der Controller 0, der untere Controller 1, so können auch bei der Konsolidierungs-Topologie nicht mehr einfach die einzelnen Devices benannt werden. Hier gibt nun die Reihenfolge der Hub-NL-Ports den Fibre Channel-Systemadaptern des Storage Arrays das Kriterium der Wahl für die Target-Bezeichnung vor. 133

3 SAN Connectivity-Topologien Abbildung 3.14: Hochverfügbare Storage-Konsolidierung in einer FC-AL-Umgebung

F C H B A

Port A

Port B

FC-AL HUB

NT-Server

F A

F C H B A

Port A

Port B

Storage

F C H B A

Port A

Array 1

F C H B A

Port A

Port B

FC-AL HUB

AIX- Server

F A

Port B

Ohne FC-AL-Hub wäre die Storage-Konsolidierung der Abbildung 3.14 nur zu realisieren, wenn vier Verbindungen zwischen Server und Storage Array zur Verfügung stünden. Die HBA-Konfiguration entspräche der in der Abbildung gezeigten. Port A beider Host-Bus-Adapter des NT-Servers müssten mit Port A der beiden Fibre Channel-Adapter des Storage Arrays verbunden werden. Port A beider Host-Bus-Adapter des AIX-Servers müssten an Port B der beiden Fibre Channel-Adapter des Storage Arrays angeschlossen werden. Beide Fibre Channel-Adapter des Storage Arrays wären damit komplett belegt. Weitere Host-Connections erforderten weitere FAAdapter im Storage Array. Mit obiger FC-AL-Konfiguration werden die vier Server-/Storage-Verbindungen durch Einbindung der beiden FC-AL-Hubs auf zwei Verbindungen reduziert. Diese Konfiguration ist vor allem dann sinnvoll, wenn die zu konsolidierenden Server geringe I/O-Bandbreitenanforderungen besitzen. Für diese Server wäre die volle Bandbreite einer Fibre Channel-Verbindung eindeutig überdimensioniert. In der dargestellten hochverfügbaren FC-ALKonfiguration teilen sich die beiden Server die Bandbreite zweier Fibre Channel-Verbindungen. Es werden sowohl Cluster- als auch Non Cluster-Konfigurationen unterstützt. Durch server-basierte Lockmechanismen können in Cluster-Umgebungen die Applikationen für den normalen und den Failover-Betrieb auf die gleichen Magnetplatten zugreifen. Non Cluster-Applikationen teilen

134


sich Mengen von Magnetplatten auf dem Storage Array, die Kapazität des Storage Arrays sowie die Bandbreite der Fibre Channel-Verbindungen zwischen Server und Storage Array. Dazu wird wiederum eine host-basierte Kanal-Failover- und Kanal-LoadBalancing- und Dynamic Multipathing-Software wie DMP von Veritas, Powerpath von EMC2 oder PV-Links unter HP-UX benötigt, die die Hochverfügbarkeit der Magnetplatten der Storage Arrays für die Anwendungen sicherstellt. Hier wird host-basiert die Hochverfügbarkeit bei Verlust eines Hubs, FC-HBAs oder FAs sichergestellt, das Management der Konfiguration wird vereinfacht, deren Zuverlässigkeit wird erhöht und die Applikationsperformance durch dynamische Nutzung beider Pfade wird gesteigert.

3.2.2.2

Speicherkonsolidierung in FC-SWUmgebungen

Das logische Konzept der Konsolidierungs-Topologie in einer Switched Fabric-Umgebung wird durch die »Fan-Out-Rate« beschrieben.

NT-Server

IBM-Server

Sun-Server

HP-Server

F C HB A

F C HB A

F C HB A

F C HB A

Abbildung 3.15: Storage-Konsolidierung in einer FC-SW-Umgebung

Port A

Port B

FCSwitch

Port A

Port B

Port A

Storage F A

Array 1

Port B

Port A

Port B

Dabei definiert das »Out« den Weg aus dem Storage Array heraus. Eine FanOut-Rate von 2 bedeutet, dass über einen Fibre Channel-Port des Storage Arrays zwei Fibre Channel-Ports an Hosts erreicht werden. In Abbildung 3.15 ist eine fan-out-rate von 4 dargestellt. Ein Fibre ChannelPort eines Storage Arrays wird von vier Server-Connections geteilt. Der Fibre Channel-Host-Bus-Adapter (FC-HBA) eines jeden Servers ist über einen seiner beiden Fibre Channel-N-Ports an einen F-Port eines FC-SW Fabric-Swit-

135


ches angeschlossen. Über einen F-Port dieses Switches wird der Fibre Channel-Systemadapter des Storage Arrays mit einem N-Port verbunden. In der Topologie der Abbildung 3.15 sieht jeder Host nun über seinen Fibre Channel-HBA sämtliche Magnetplatten des Storage Arrays, auf die über den FA zugegriffen werden können. Auch in dieser Topologie wird lediglich eine reine Storage-Konsolidierung betrieben. Eine Hochverfügbarkeit ist durch die Häufung der Single Points of Failure (FC-HBA, FA des Storage Arrays) nicht gewährleistet. Der Switch als Single Point of Failure wurde hier nicht erwähnt, da hochverfügbare Fibre Channel-Switches die benötigte Hardwareredundanz mit der entsprechenden Switch-implementierten Software bieten. Dennoch kann auch ein kompletter Switch als redundantes System eingebunden werden. Eine Hochverfügbarkeit in der FC-SW Storage-Konsolidierungs-Topologie (mit nur einem hochverfügbaren Switch) wird in der Abbildung 3.16 dargestellt. Abbildung 3.16: Hochverfügbare Speicherkonsolidierung in einer FC-SW-Umgebung

F C H B A

NT-Server

Port A

Port B

FCSwitch

F A

F C H B A

Port A

Port B

Storage

F C H B A

Port A

Array 1

F C H B A

Port A

Port B

AIX-Server

F A

Port B

Hier sind wiederum serverseitig zwei Fibre Channel-HBAs über einen Fibre Channel-Switch mit dem Storage Array verbunden. Das Storage Array besitzt zwei Fibre Channel-Systemadapter, die vom Host über den Switch angesteuert werden. Die Namensgebung der Devices, die der Host sieht, ist in der Switched Fabric-Umgebung bestimmt durch das Zoning beim Switch und evtl. durch eine Software, die die Sichtbarkeit der Devices auf den Storage Arrays für einzelne Hosts einschränkt. Auf das Zoning und die Einschränkung des Devicezugriffs soll weiter unten und in Kapitel 4 eingegangen werden. Auch in der Hochverfügbarkeitslösung der Speicherkonsolidierung existiert eine fan-out-rate von 4, dennoch werden hier von Seiten

136

Distanz-Topologie

des Storage Arrays zwei Ports benötigt. Auch hier wird über eine host-basierte Kanal-Failover- und Kanal-Load-Balancing-und Dynamic Multipathing-Software wie DMP von Veritas, Powerpath von EMC2 oder über PV-Links unter HP-UX die Hochverfügbarkeit der Magnetplatten der Storage Arrays für die Anwendungen host-basiert sichergestellt, das Management der Konfiguration wird vereinfacht, deren Zuverlässigkeit wird erhöht und die Applikationsperformance durch dynamische Nutzung jeweils beider Host-Pfade wird gesteigert.

3.3

Distanz-Topologie

Die Distanz-Topologie ist mit herkömmlichen Anschlusstechniken für Storage nicht realisierbar. Sie verwendet sowohl kurz- als auch langwellige Glasfaser-Verbindungen, um die maximale Distanz zwischen Serversystemen und Storage Arrays auszudehnen. Der Zugriff multipler Server Connections über langwellige Glasfaserverbindungen auf multiple Storage Arrays erhöht die Verfügbarkeit der Storage-Umgebung, da hier ein Komplettausfall eines Storage Arrays als Single Point of Failure ausgeschaltet werden kann. Abbildung 3.17: Distanz-Topologie FC-AL

Port A

NT-Server

F C H B A

FC-AL HUB

F A

Port B

Storage Array 1

FC-AL HUB Kurzwellige Glasfaser (durchgezogene Linie) Langwellige Glasfaser (unterbrochene Linie)

137


Aus Gründen des Verfügbarkeits- und Ressource-Managements wird in Rechenzentrum-Topologien eine langwellige Glasfaser verwendet, um ESCON-HBAs und Systemadapter (auf Seiten des Storage Arrays) zu terminieren und dann eine ESCON-zu-ESCON-Verbindung zwischen dem ESCON-Systemadapter eines lokalen Storage Arrays und dem ESCON-Systemadapter eines Remote Storage Arrays zu implementieren. Fibre Channel kann auf ähnliche Weise implementiert werden, indem die Server-/StorageVerbindungen lokal über eine Verbindungsschaltung (z.B. über einen Hub oder einen Switch) realisiert werden und langwellige/Single Mode-Glasfaser Hub-to-Hub (lokaler Hub zu remote Hub) oder Switch-to-Switch implementiert wird. Fibre Channel-Geräte sind in aller Regel für kurzwellige Laser mit Multi Mode-Glasfaserkabeln realisiert. Dies beschränkt ihren Einsatz auf Server-/Storage-Distanzen von bis zu 500 Metern. Langwellige Laser mit Single Mode-Glasfaserkabel erlauben Server-/Storage-Distanzen bis zu zehn Kilometern. Diese Technologie wird dazu verwendet, komplette auf Fibre Channel basierte Katastrophen-RecoverySysteme aufzubauen, die einen lokalen Server-/Storage-Verbund durch einen remote Server-/Storage-Verbund absichern.

3.3.1

Fibre Channel FC-AL-Distanz-Topologie

In einer klassischen Implementierung der FC-AL-Distanz-Topologie (vgl. Abbildung 3.17) werden Server und Storage an unterschiedlichen Lokationen gehalten. Der Server realisiert seine Server-/Storage-Verbindungen über eine kurzwellige Laserverbindung zu einem lokalen Hub. Der Server verbindet einen N-Port seines Fibre Channel-HBAs mit einem NL-Port des lokalen Hubs. Dieser wird über einen weiteren NL-Port durch eine langwellige Laserverbindung an einen NL-Port eines remote Hubs angeschlossen. Von einem NL-Port des remote Hubs wird dann die tatsächliche Verbindung an einen N-Port des Fibre Channel-Systemadapters des remote stehenden Storage Arrays verkabelt. Hochverfügbar ist diese Storage Connectivity jedoch nicht. Jeder Ausfall eines FC-HBA, eines FC-AL-Hubs oder eines FA sowie einer Longwave Fibre Channel-Verbindung zwischen den beiden Hubs führt zum Stopp der Anwendungen des Servers. Eine wie in Abbildung 3.17 dargestellte hochverfügbare FC-AL-DistanzTopologie stellt – zumindest was die Connectivity-Sicherheit anbelangt – ein Disaster-Recovery-fähiges Konzept dar. Fällt ein FC-HBA aus, so kann der zweite FC-HBA des Hosts die Aufgabe übernehmen. Fällt ein FC-AL-Hub aus, so werden sämtliche Verbindungen des zweiten FC-AL-Hubs genutzt, fällt ein FA aus, so werden die Verbindungen über den zweiten FA genutzt. Absolute Disaster-Toleranz bedingt jedoch auch den Ersatz sämtlicher Systemkomponenten – also auch den Ersatz von Server-System und Storage Array – durch eine Recovery-Komponente. Am Ende dieses Kapitels soll

138

Distanz-Topologie

eine solche disastertolerante Topologie dargestellt werden. Zuvor jedoch sollen noch eine FC-SW-Distanz-Topologie und gemischte Topologien dargestellt werden. F C H B A

NT-Server

3.3.2

Port B

FC-AL HUB

F C H B A

Port A

F C H B A

Port A

F C H B A

Port A

AIX-Server

Abbildung 3.18: Hochverfügbare FC-AL-DistanzTopologie

Port A

FC-AL HUB

F A

Remote

Port B

Storage Port B

FC-AL HUB

Port B

FC-AL HUB

F A

Array 1

durchgezogene Linien = kurzwelliges Fibre unterbrochene Linien = langwelliges Fibre

FC-SW-Distanz-Topologie

Die Fibre Channel Switched Fabric Distanz-Topologie erfordert eine Langwellen-Laser-Switch-To-Switch-Verbindung zweier Fibre Channel-E-Ports mit zwei Switches. Diese beiden Switches bilden die Fabric. Ein N-Port des Fibre Channel-Host-Bus-Adapters (Port A) wird an einen F-Port des lokalen Switches mit Kurzwellen-Glasfaser angeschlossen. Der lokale und der remote Switch bilden die Fabric. Beide Switches sind untereinander mit E-Ports über Langwellen-Glasfaser zur Fabric zusammengeschlossen. An einen F-Port des remote Switches wird ein N-Port des Fibre Channel-Systemadapters des Storage Arrays über Kurzwellen-Glasfaser angeschlossen. Unter dem Hochverfügbarkeitsaspekt wohnen dem obigen Beispiel der FC-SW-Distanz-Topologie im Host-Bus-Adapter und dem Fibre ChannelSystemadapter wieder vermeidbare Single Points of Failure inne, die durch die hinlänglich bekannte Konfigurationserweiterung auf redundante Komponenten beider Seiten vermieden werden kann.

139

3 SAN Connectivity-Topologien Abbildung 3.19: FC-SW-DistanzTopologie

FCSwitch

FCSwitch

Port A

NT-Server

F C H B A

F A

Port B

Abbildung 3.20: Hochverfügbare FC-SW-DistanzTopologie

F C

B

Port A FCSwitch

FCSwitch

Port B

A

F

NT-Server F

A

Port A

C H B

C

Storage Port A

H B

Port B

F

A

A

AIX-Server F

Port A

C H B A

durchgezogene Linien Port B

= kurzwelliges Fibre unterbrochene Linie = langwelliges Fibre

140

Remote

Port B

A

F

Array 1

Kurzwellige Glasfaser (durchgezogene Linien) Langwellige Glasfaser (unterbrochene Linie)

H

Storage

Array 1

Gemischte Topologien

Hier sind serverseitig zwei Fibre Channel-HBAs über einen Fibre ChannelSwitch mit dem Storage Array verbunden. Das Storage Array besitzt zwei Fibre Channel-Systemadapter, die über den Switch vom Host angesteuert werden. Auch hier wird über eine host-basierte Kanal-Failover- und KanalLoad-Balancing- und Dynamic Multipathing-Software wie DMP von Veritas, Powerpath von EMC2 oder über PV-Links unter HP-UX die Hochverfügbarkeit der Magnetplatten der Storage Arrays für die Anwendungen host-basiert sichergestellt, das Management der Konfiguration wird vereinfacht, deren Zuverlässigkeit wird erhöht und die Applikationsperformance durch dynamische Nutzung jeweils beider Host-Pfade wird gesteigert. Jedoch auch für die hier dargestellte Hochverfügbarkeitslösung gilt wieder, dass kein Totalausfall eines Serversystems oder des Storage Arrays abgedeckt ist.

3.4

Gemischte Topologien Abbildung 3.21: Gemischte Topologie

Port A

NT-Server

SC SI HB A

Port B Port C

S A

Port D

Port A

IBM-Server

F C HB A

FC-AL HUB FCSwitch

F A

Port B

Port A

Sun-Server

F C HB A

Storage Array

F A

Port B

Auf den zurückliegenden Seiten wurden die reinen Formen von Kapazitätserweiterungs-, Konsolidierungs- und Distanz-Topologien für Storage Area Networks erläutert. Sie wurden anhand von Implementierungsbeispielen für klassische SCSI-, sowie FC-AL- und FC-SW-Fibre Channel-Anschlüssen dargestellt. Natürlich lassen sich sämtliche Topologien mit entsprechendem Mix von Host-Bus-Adaptern, Systemadaptern und Fibre Channel-Hubs und

141


Switches mischen. So können Devices eines Storage Arrays direkt über SCSI an einen SCSI-Host-Bus-Adapter angeschlossen werden, andere Devices eines Arrays über Hub einer FC-AL-Verbindung adressiert werden, wiederum andere über eine Fibre Channel-Switched Fabric angeschlossen werden. Abbildung 3.22 soll eine kleine Auswahl der Kombinationsmöglichkeiten für klassische und Fibre Channel-Anschlüsse von Storage Devices vermitteln. Abbildung 3.22: Hochverfügbare gemischte Topologie

NT-Server

S A

SC SI HB A SC SI HB A

IBM-Server

F C HB A F C HB A

S A FC-AL HUB

FC-AL HUB

F A

Storage

F A

Array

F A Sun-Server

F C HB A F C HB A

F A

In Abbildung 3.22 erkennt der NT-Server über Port A seines SCSI-Host-Busses sämtliche Magnetplatten, die für den SCSI-Systemadapter des Storage Arrays sichtbar sind. Der IBM-Server implementiert eine Kapazitätserweiterung, indem von Port A seines Fibre Channel-Host-Bus-Adapters über den FC-AL-Hub der Port A des ersten und der Port B des zweiten Fibre ChannelSystemadapters des Storage Arrays angeschlossen werden. Dadurch kann der IBM-Server sämtliche Magnetplatten innerhalb des Storage Arrays adressieren, die über die beiden Fibre Channel-Systemadapter sichtbar sind. Der Sun-Server wird in einer Distanz-Topologie über zwei Switches, die über E-Port zur Fabric zusammengeschlossen sind, an Port A des Fibre ChannelSystemadapters des Storage Arrays angeschlossen. In dieser Konstellation kann es zu Konflikten zwischen dem IBM-Server und dem Sun-Server daher kommen, da beide über den zweiten Fibre Channel-Systemadapter des Storage Arrays die gleichen Magnetplatten sehen können. Per definitionem sieht ein Host-Bus-Adapter eines Servers alle Magnetplatten im Storage Array, die für den Systemadapter sichtbar sind, über dessen Ports der Server angeschlossen ist. Hier muss softwareseitig server-basiert sichergestellt werden,

142

Gemischte Topologien

dass jeder Server lediglich »seine« Magnetplatten sieht und diese ihm bei jedem Boot-Vorgang wieder in der richtigen Reihenfolge zur Verfügung gestellt werden. Eine hochverfügbare gemischte Topologie wäre – ausgehend von der oben angedachten Konstellation – wie folgt zu realisieren: F C H B A

AIX-Server F C H B A

F C H B A


Abbildung 3.23: Hochverfügbare SAN-Topologie

F C H B A

F A

F A

F A

Local

Remote

Storage

Storage

Array

Array

F A


F C H B A


Für die hochverfügbare gemischte Topologie gelten sämtliche Anmerkungen, die zu sämtlichen Spielarten der reinen Topologien bereits gemacht wurden. Summarisch kann hier festgestellt werden, dass sämtliche betrachtete Topologien Hochverfügbarkeit lediglich für die Verbindung zwischen Host (Server) und Speichermedium (Storage Array) realisiert haben. Tatsächliche SAN-Topologien sind lediglich über Fibre Channel realisierbar. Dabei kommt es nicht darauf an, ob FC-AL oder FC-SW eingesetzt wird. Shared Usage der Verbindungen und der Speichermedien für mehrere Hosts ist lediglich mit Fibre Channel realisierbar. Einzelne Anforderungen an SANs wie Speicherkapazitätserweiterung für einzelne Server und Speicherkonsolidierung für mehrere Server sind zwar mit SCSI- oder Parallelanschluss des/der Storage Devices realisierbar, eine tatsächliche gemeinsame Nutzung der Medien benötigt jedoch den Einsatz von Fibre Channel. Daher werden in den folgenden Abschnitten, die die wesentlichen Hard- und Softwarebausteine von Storage Area Networks zum Inhalt haben, zwar hin und wieder noch einige Sätze zur Integration klassischer Peripherie-Protokolle und Controller fallen, der Schwerpunkt wird jedoch eindeutig auf Fibre Channel gelegt. Abschließend zur Darstellung der für die Anwendung entwickelten SAN-Topologien sei eine Topologie eines tatsächlich hochverfügbaren SANs vorgestellt, der neben der höchstverfügbaren Verbindungs-

143


Topologie – der Distanz-Topologie – auch die wesentlichen Bausteine des SANs – Server und Storage Devices – an beiden Lokationen redundant hält, sodass tatsächlich sämtliche Single Points of Failure ausgeschlossen werden können, sogar der Ausfall eines gesamten Rechenzentrums. Diese SANTopologie ist es, deren Bausteine für den Rest des Buches zusammengetragen und dargestellt werden. In dieser Topologie sind zwei identisch ausgestattete Rechenzentren über langwellige Glasfaser in einer Campus-Distanz-Topologie zusammengeschlossen. Ein Server sowie ein Failover-Server sind jeweils über DualPathing mit einem Storage Array angeschlossen. Das Remote Storage Array ist eine identische Kopie des Local Storage Arrays, d.h. die Platten des lokalen Storage Arrays werden auf dem Remote Storage Array gespiegelt. Auch der Switch kann noch redundant gedacht werden, sodass jede Komponente, sogar komplette Server, ausfallen können – sie haben zumindest einen redundanten Partner, der ihre Funktionen übernehmen kann. Aufbau und Funktion solcher SANs werden im folgenden Abschnitt erläutert.

144

4

SAN – HardwareKomponenten

Im Folgenden werden die generellen Bausteine eines Storage Area Networks beschrieben. Dabei handelt es sich um 왘 Host-Komponenten des SAN 왘 Storage-Komponenten des SAN 왘 Fibre Channel-Hubs und Switching-Hubs 왘 Fibre Channel Fabric Switches 왘 Fibre Channel-to-SCSI Bridges.

Je nach gewählter SAN-Topologie werden diese Komponenten zum Aufbau des SANs herangezogen.

4.1

Hochverfügbare ClusterSysteme

4.1.1

Hewlett-Packards MetroCluster ServiceGuard Hardware-Konfiguration

MetroCluster ServiceGuard (MC/ServiceGuard) ermöglicht hochverfügbare Cluster von HP9000/800-Computern. Ein solcher hochverfügbarer Cluster erlaubt Diensten und Applikationen einen unterbrechungsfreien Betrieb, auch wenn eine Hardware- oder Softwarekomponente ausfallen sollte. Hochverfügbare Systeme schützen die Anwender sowhl vor Softwarefehlern als auch vor Fehlern in Hardware-Komponenten wie SPU (System Processing Unit), Magnetplatte(n) oder LAN/Netzwerkbausteinen. Realisiert wird diese Hochverfügbarkeit durch Redundanz der Systemkomponenten – ist eine Hardwarekomponente fehlerhaft, so wird deren Funktion automatisch von der redundanten Komponente übernommen. MC/ServiceGuard und andere hochverfügbare Subsysteme (z.B. Storage Arrays) übernehmen die Koordination zwischen den redundanten Komponenten. Ein MetroCluster ServiceGuard Cluster besteht aus untereinander vernetzten gruppierten HP9000/800-Servern. Diese werden als Cluster-Knoten bezeichnet. Jeder dieser Cluster-Knoten besteht aus eigenständigen redun-

145

4 SAN – Hardware-Komponenten

danten Hardware- und Softwarekomponenten. Diese Redundanz stellt sicher, dass es auf dem Cluster-Knoten keinen Single Point of Failure gibt, der die Services oder Applikationen, die dieser Knoten hostet, signifikant unterbrechen könnte. Applikationen und Dienste (individuelle Prozesse unter HP-UX) werden zu Packages gruppiert. Fällt nun ein kompletter Cluster-Knoten oder auch nur ein einzelner Dienst, ein Netzwerk oder eine andere Ressource aus, so kann MC/ServiceGuard automatisch die Kontrolle der Packages des Clusters oder des vom Komponentenausfall betroffenen Packages auf einen anderen Knoten innerhalb des Clusters übertragen. Dadurch bleiben die Dienste und Applikationen bei minimaler Unterbrechung verfügbar. Abbildung 4.1 zeigt eine typische MC/ServiceGuard-Konfiguration mit zwei Cluster-Knoten. Beide Cluster-Knoten stellen jeweils eine SPU dar. Der Knoten A betreibt die Applikationen und Dienste des Packages 1, Knoten B die von Package 2. Mit jedem Package ist – auf einem Storage Array – eine Magnetplattengruppe assoziiert, die sowohl die Produktivdaten des Packages enthalten als auch jeweils einen Spiegel dieser Produktivdaten. Beide Cluster-Knoten haben physikalisch den Zugriff auf die Disk Groups beider Packages, jedoch hat jeder Knoten zu einem gegebenen Zeitpunkt nur Zugriff auf die Disks des Packages, das er aktuell betreibt (die Disks des jeweils anderen Packages bleiben im Status »Not Ready To Host«). Der Knoten A hat also direkten Zugriff auf die Disk Group des Packages 1, Knoten B auf die Disk Group des Packages 2. Abbildung 4.1: MetroCluster – Typische Konfiguration mit zwei Knoten

Package 1 HP-Server ClusterKnoten A

F C H B A

F C H B A

FC-Switch Disk Group Package 1

F A

Local Storage

Package 2 HP-Server ClusterKnoten B

F C H B A

F C H B A

146

Disk Group Package 2 Array

F A

Hochverfügbare Cluster-Systeme

In der Regel sind die Magnetplatten der Disk Groups noch lokal gespiegelt, sodass die Daten auch bei Verlust einer Platte redundant vorhanden sind. Zusätzliche Redundanzen befinden sich auf der HBA-Ebene, auf der Systemadapter-Ebene und innerhalb des Storage Arrays. Hier nutzen sämtliche DiskAdapter (Magnetplattencontroller) und sämtliche Systemadapter redundante Busse. Je nach Architektur des Storage Arrays werden die Magnetplatten Dual Ported an zwei Disk-Adapter angeschlossen oder die Platten eines Disk-Adapters sind Dual-Initiated über ungenutzte Ports des Disk-Adapters an ungenutzte Ports eines zweiten Disk-Adapters angeschlossen, sodass sowohl Systemadapter als auch Busse und Disk-Adapter redundant vorgehalten werden. Aufbau und Funktion eines solchen hochverfügbaren Storage Arrays werden später in diesem Kapitel dargestellt. Die oben beschriebene Package-Konfiguration des MC/ServiceGuard bietet ein Maximum an Redundanz wie auch ein Optimum an Performance, da sowohl die Host-Bus-Adapter als auch die Systemadapter, Datenbusse und Disk-Adapter für die beiden Packages voneinander getrennt liegen; auch über die redundanten Komponenten, evtl. durch host-basierte Software, kann eine Lastverteilung vorgenommen werden. Auch Netzwerk-Hardware wird für MC/ServiceGuard redundant verkabelt. Jeder Cluster-Knoten bietet und nutzt redundante LAN-Schnittstellen. MC/ ServiceGuard verwendet die TCP/IP-Netzwerkdienste für eine zuverlässige Kommunikation zwischen den Knoten des Clusters. Diese beinhaltet auch die Übertragung von heartbeat messages – periodischen Signalen jedes aktiven Cluster-Knotens, die dem Cluster seine Funktionsfähigkeit anzeigen. Weitere TCP/IP-Dienste werden für unterschiedliche Kommunikationsarten zwischen den Cluster-Knoten verwendet. Diese sowie eine ausführliche Darstellung der Heartbeat-Funktionalität werden später erörtert. Unter normalen Bedingungen überwacht MC/ServiceGuard lediglich die Funktionalität sämtlicher Cluster-Komponenten. Die Packages laufen störungsfrei auf ihren jeweiligen Cluster-Knoten. Ein Cluster-Knoten wird als aktiver Knoten bezeichnet, solange er fehlerfrei in einem MC/ServiceGuardCluster läuft. Bei der Erstellung eines Packages wird definiert, welcher Cluster-Knoten dieses Package bevorzugt betreiben soll. Dieser Knoten ist der Primary Node für den Betrieb des Packages. Weiter werden ein oder mehrere Adoptive Nodes definiert. Ein Adoptive Node ist ein Cluster-Knoten, der bei Ausfall des Primary Nodes des Packages, sei es aufgrund eines Netzwerkfehlers oder eines Fehlers einer anderen Cluster-Komponente, von MC/ServiceGuard die Kontrolle über das Package transferiert bekommt. Nach dem Transfer verbleibt das Package typischerweise solange unter Kontrolle des Adoptive Nodes, wie dieser läuft. Die Konfiguration ermöglicht aber auch, die Kontrolle an den Primary Node zurückzugeben, sobald die Fehlerursache behoben und dieser wieder aktiv ist. Alternativ zu automatischer Voreinstellung des Failover/Failback-Vorganges über die Konfiguration von MC/ServiceGuard kann die Kontrolle am Package zu gegebenem Zeitpunkt jedoch auch manuell an den Primary Node rückübertragen werden.

147

4 SAN – Hardware-Komponenten Abbildung 4.2: MetroCluster – Zwei-KnotenKonfiguration nach Failover

F

Package 1

C H


B

HP-Server

A

Cluster-

F

Knoten A F

A

C H B

Local

A

Storage Package

F

2

C

Package 1 HP-Server


H B A

F A

ClusterKnoten B F C H B A

Bei der Darstellung der Cluster-Umgebung und des Failovers in obigen Beispielen wurden absichtlich lediglich die Komponenten des Clusters dargestellt, die aus den bisherigen Kapiteln des Buches vertraut sind. Interessant ist dabei die Durchgängigkeit des Redundanzgedankens für die komplette Systemumgebung. So werden z.B. auch die Stromanschlüsse für sämtliche Komponenten redundant vorgehalten. Die Komponenten werden an so viele unabhängige Stromkreise angeschlossen, dass auch in der Stromversorgung ein Single Point of Failure ausgeschlossen wird. Jeder Stromkreis sollte von einem UPS (uninterruptable power supply) abgesichert werden, der die Stromversorgung einer Cluster-Komponente solange sicherstellt, bis der Cluster den Package-Switch abgeschlossen hat.

4.1.1.1

Redundanz von Cluster-Komponenten

Die Hochverfügbarkeit in der Cluster-Umgebung definiert sich durch ein Höchstmaß an Redundanz der Komponenten. Diese Redundanz eliminiert Single Points of Failure. Generell gilt die Aussage, dass je mehr Redundanz im Cluster implementiert ist, desto sicherer ist der Zugriff auf die Applikationen, Daten und Dienste beim Ausfall einzelner Komponenten. Zusätzlich zur Redundanz der Hardware-Komponenten muss auch die eingesetzte Software die Hochverfügbarkeitslösung unterstützen. Sie muss den Transfer der Applikationskontrolle auf eine andere SPU oder ein anderes Netzwerk bei Ausfall einer Cluster-Komponente ermöglichen und automatisieren. MC/ServiceGuard bietet diese Unterstützung für folgende Situationen:

148

Hochverfügbare Cluster-Systeme 왘 Im Falle eines LAN-Fehlers schaltet MC/ServiceGuard auf ein Standby-

LAN um oder transferiert die Kontrolle über die Applikation (das Package) auf einen Standby-Cluster-Knoten. 왘 Im Falle eines SPU-Fehlers (Knoten-Fehler) wird die Kontrolle am Pack-

age automatisch auf eine laufende SPU übertragen. Dieser Failover geschieht nicht unbemerkbar für den Anwender des betroffenen Packages. Der Standby-Knoten muss das Package starten, die Magnetplatten des betroffenen Packages in sein Dateisystem einhängen und den Benutzerzugriff ermöglichen. Bei Ausfall einer CPU wird die Applikation für den Anwender »abstürzen«; sie ist jedoch in kürzester Zeit auf dem StandbyKnoten wieder verfügbar. 왘 Bei Ausfall einer jeden anderen überwachten Ressource, z.B. eines

Switch-Ports, eines Systemadapter-Ports, eines Host-Bus-Adapter-Ports oder eines Disk-Adapters kann das Package auf einen anderen ClusterKnoten übertragen werden, der die gleiche Ressource über einen anderen Pfad erreicht. 왘 Softwarefehler führen zu einem Re-Start des Packages auf dem gleichen

oder einem Standby-Knoten. Auch hier gilt wieder, dass im Cluster die Downtime der Applikation minimiert ist. Die Funktion des kontrollierten und automatisierten Anwendungs- und Dienstetransfers auf einen Adoptive Node wird auch für geplante Ausfallzeiten, z.B. Wartungs-Zeitfenster oder Software- und Hardware-Upgrades, genutzt. MC/ServiceGuard unterstützt Cluster mit maximal 16 Cluster-Knoten. Fast/ Wide SCSI-Magnetplatten oder Storage Arrays können über einen Shared Bus an bis zu vier Cluster-Knoten gleichzeitig angeschlossen werden. Storage Arrays, die unabhängige Busse anbieten oder über Fibre Channel angeschlossen werden, können für das Failover von sämtlichen 16 Cluster-Knoten konfiguriert werden. Unabhängig von der Anschlusstechnik für die Magnetplatten können Applikationen auf beliebig viele Cluster-Knoten geschwenkt werden, wenn diese lokale Kopien der ausführbaren Programme dieser Applikationen besitzen.

4.1.1.2

Redundanz von Netzwerk-Komponenten

Um Single Points of Failure für den Betrieb des Netzwerks auszuschließen, muss jedes Subnet, das von einem Cluster-Knoten erreichbar ist, redundante Netzwerk-Schnittstellen besitzen. Gegen Kabelfehler ist eine redundante Verkabelung erforderlich. Jede Netzwerk-Karte wird über ein eigenes Kabel angeschlossen. Die Kabel – und damit auch die Netzwerk-Karten – werden über einen Hub oder eine Bridge miteinander verbunden. In FDDI-Netzwerken wird jede Netzwerk-Karte mit einem unterschiedlichen Concentrator verkabelt. Eine solche Netzwerkkonfiguration, die die physikalischen Kabel über eine Bridge, einen Concentrator oder einen Switch miteinander verbindet, wird als Bridged Net bezeichnet.

149


In einem Bridged Net werden den Netzwerk-Schnittstellen die IP-Adressen zugewiesen. Eine Schnittstelle, der eine IP-Adresse zugewiesen ist, wird als primäres Interface bezeichnet, eine Schnittstelle, der keine IP-Adresse zugeordnet wurde, als Standby Interface. Auf die Standby Interfaces wird seitens MC/ServiceGuard geschwenkt, sobald das primäre Netzwerk-Interface einen Fehler aufweist. Wird ein Fehler des primären Interfaces entdeckt, schwenkt MC/ServiceGuard die IP-Adresse mit sämtlichen aktuellen Verbindungen von der fehlerhaften Schnittstellenkarte auf eine fehlerfreie Standby-Schnittstellenkarte.

Redundante Ethernet-Konfiguration Abbildung 4.3 zeigt die Verwendung redundanter Netzwerk-Komponenten in einer Cluster-Umgebung, die über ein Ethernet-Netzwerk kommuniziert. Token Ring-Netzwerke werden auf ähnliche Weise konfiguriert. Abbildung 4.3: MetroCluster – Redundante Ethernet-Konfiguration

Subnet A

Subnet A S t a n d b y

P r i m a r y

L A N

D e d I z I e r t e r

H e a r t b e a t

H e a r t b e a t

H e a r t b e a t

u n d

L A N

u n d

D a t e n

L A N

D a t e n


F C H B A

F C H B A

FC-Switch Disk Group Package 1 F A

Local Storage


F C H B A


F A

F C H B A

Subnet B

Beide Cluster-Knoten sind über die primäre (obere) LAN-Schnittstellenkarte an das primäre LAN angeschlossen. Über das primäre LAN werden sowohl Heartbeat- als auch Anwendungs-Informationen gesendet. Subnet B wird über eine eigene LAN-Schnittstellenkarte (mitte) angeschlossen. Auf Subnet B werden lediglich Heartbeat-Informationen versendet. Ein Standby LAN, wie auch das primäre LAN zu Subnet A gehörend, wird über Standby LAN-Schnittstellenkarten (unten) angeschlossen. Um eine absolute Hochverfügbarkeit zu erreichen, werden das primäre LAN und das Standby LAN über einen Hub miteinander verbunden (in Abbildung 4.3 nicht dargestellt). In diesem redundanten Daten/Heartbeat-Subnet (Subnet A) hat jeder Clus-

150


ter-Knoten seine eigene IP-Adresse. Kommt es zu einem Fehler der primären AN-Karte eines Knotens, so schwenkt MC/ServiceGuard auf die Standby LAN-Schnittstellenkarte desselben Knotens. Eine redundante Heartbeat-Kommunikation wird dadurch gewährleistet, dass neben einem dedizierten Heartbeat-LAN Heartbeat-Informationen auch über den primären LAN und den Standby LAN versandt werden. Im obigen Beispiel ist für das dedizierte Heartbeat-LAN kein lokales Switching notwendig, da über das jeweilige Subnet ein redundanter Heartbeat-Pfad existiert. Kommt es zu einer Heartbeat-Ungereimtheit auf dem primären LAN, so sorgt die Diagnose des ausgewählten Heartbeat-LANs dafür, dass es zu keiner fehlerhaften Übertragung kommen kann. Jeder Cluster-Knoten besitzt seine eigene IP-Adresse für den entsprechenden Heartbeat-LAN.

Redundante FDDI-Verbindungen FDDI ist ein glasfaser-basiertes Hochgeschwindigkeits-Verbindungs-Medium. Bei der Verwendung von FDDI können redundante Konfigurationen dadurch aufgebaut werden, dass in einer Stern-Topologie sämtliche ClusterKnoten zu jeweils zwei Concentrators verbunden werden. Diese sind wiederum an zwei Router angeschlossen, die mit den Client-Netzwerken außerhalb des Clusters kommunizieren. Bei dieser Konfiguration sind für jeden Knoten des Clusters zwei FDDI-Karten notwendig. Die Konzentratoren werden untereinander durch die Ports A und B mit Zweifachverkabelung über Kreuz verbunden. Die Router müssen so konfiguriert sein, dass sie an beide Konzentratoren Netzwerk-Packages schicken können.

C l i e n t N e t z w e r k e

Port B

Port A

Router

Concentrator

Port A

Port B

F Package C 1 H B A HP-Server ClusterKnoten A F C H B A

FC-Switch

Disk Group Package 1

Abbildung 4.4: MetroCluster FDDI-Konfiguration

F A

Local Storage

Port B

Port A

Router

Concentrator

Port A

Port B

F Package C 2 H B A HP-Server ClusterKnoten B F C H B A


F A

151


Fibre Channel-Switched-Konfigurationen Fibre Channel-Switched-Konfigurationen wurden bereits in sämtlichen hier gezeigten Beispielen vorausgesetzt. Bisher wurde jedoch die Hochverfügbarkeit dadurch bedingt untergraben, als in dem verwendeten Switch noch immer ein Single Point of Failure vorhanden war. Der Ausfall des kompletten Switches war trotz redundanter Switch-Komponenten innerhalb des Switches nicht abgedeckt. MC/ServiceGuard-Cluster von vier bis maximal acht Cluster-Knoten können Fibre Channel-Switches verwenden, um zwischen den Cluster-Knoten redundante Netzwerk-Pfade aufzubauen. Abbildung 4.5: MetroCluster SwitchedKonfiguration





FC HB A


FC HB A

F A

FC HB A FC HB A

FC HB A FC HB A

Local Storage Disk Group Package 2 Array

FC-Switch F A

FC HB A FC HB A

In einer solchen Topologie mit zwei Switches müssen sämtliche primären Pfade (Pfade vom oberen HBA eines jeden Servers) in den einen Switch gehen, sämtliche Standby-Pfade (Pfade vom unteren HBA eines jeden Servers) über den zweiten Switch laufen. Kommt es zu einem Fehler auf einer der Primärverbindungen, findet auf dem Host ein lokaler Schwenk auf den Standby-Host-Bus-Adapter statt und der Standby-Switch wird verwendet.

Verwendung serieller RS232 Heartbeat-Verbindungen MC/ServiceGuard unterstützt die Verwendung einer seriellen RS232-Verbindung für eine dedizierte Heartbeat-Kommunikation. Serielle HeartbeatVerbindungen werden dabei lediglich von Clustern unterstützt, die aus zwei Cluster-Knoten bestehen.

152


Subnet A

Subnet A

S t a n d b y

P r I m a r y

L A N

L A N

H e a r t b e a t

H e a r t b e a t

u n d

u n d

D a t e n

D a t e n Subnet B


F C H B A

F C H B A


Abbildung 4.6: MetroCluster – Dedizierte serielle Heartbeat-Leitung

F A

Local Storage


F C H B A


F A

F C H B A

Dedizierte serielle Heartbeat-Leitung

Eine dedizierte serielle Heartbeat-Leitung wird als redundante Low-Cost Heartbeat-Schnittstelle ausgewählt. Bei der Konfiguration einer seriellen Heartbeat-Leitung sendet MC/ServiceGuard die Heartbeat-Informationen kontinuierlich sowohl auf den Standby-LAN für Heartbeat und Daten als auch auf die überwachte RS232-Leitung. Dies bedeutet jedoch auch, dass bei Wahl einer seriellen Heartbeat-Leitung zumindest ein weiteres LAN-Interface vorhanden sein muss, um die Heartbeat-Informationen zu transportieren. Die serielle Leitung dient lediglich dazu, vor einem verzögerten Transport der Heartbeat-Informationen bei Netzüberlastung zu schützen. Sie verhindert jedoch keinen Verlust des Netzwerks und kann auf Netzwerkfehler nicht reagieren, da MC/ServiceGuard zwingend TCP/IP zur Kommunikation zwischen den Cluster-Knoten benötigt. Wenn die primäre und sekundäre Netzwerkkarte auf einem einzigen Cluster-Knoten ausfallen, sorgt die serielle Heartbeat-Leitung dafür, dass der Netzwerkstatus der beiden defekten Karten geprüft werden kann und der komplette Knoten mit dem Fehler der »Bad Network Connections« auf den zweiten Knoten geschwenkt wird. Auf diesem werden dann sämtliche in Produktion befindlichen Packages betrieben.

4.1.1.3

Redundanter Plattenspeicher

Jeder Knoten eines Clusters besitzt seine eigene Root-Platte. Darüber hinaus ist er jedoch physikalisch an diverse andere Magnetplatten so angeschlossen, dass mehr als ein Knoten auf die Daten und Programme zugreifen kann, die zu den Packages zusammengefasst wurden, die der Knoten betreiben soll und kann. Dieser Zugriff wird bei MC/ServiceGuard durch den HP/UX-LVM

153


(Logical Volume-Manager) gewährleistet.1 Eine Gruppe von MagnetplattenVolumes, die zu einem Package gehören, können zu einem gegebenen Zeitpunkt lediglich von einem Cluster-Knoten aktiv betrieben werden (Magnetplatten-Volumes sind Read/Write Enabled für diesen Cluster-Knoten). Sobald jedoch bei einem vom Cluster bemerkten Fehler das Package auf einen Standby-Cluster-Knoten geschwenkt wird, kann diese VolumeGruppe von diesem Adoptive Node aktiviert werden. Sämtliche Magnetplatten einer Volume-Gruppe, die zu einem dedizierten Package gehören, müssen daher sowohl mit ihrem Primären Knoten als auch mit sämtlichen Adoptive Nodes dieses Packages verbunden sein. Die Hochverfügbarkeit der Magnetplatten wird durch RAID-Technologien oder durch SoftwareMirroring gewährleistet.

Disk-Interface-Karten Magnetplatten-Interface-Karten sind die Hardwarebestandteile, die in den bisherigen Kapiteln als Host-Bus-Adapter (HBA) referenziert wurden. MC/ ServiceGuard unterstützt folgende Anschlussmöglichkeiten und Disk-Interface-Karten für Platten, die an einen oder mehrere Knoten (Shared Data Disks) angeschlossen werden: 왘 Single-ended SCSI 왘 Fast/Wide SCSI 왘 Fibre Channel

Es werden seitens MC/ServiceGuard nicht sämtliche auf dem Markt verfügbare SCSI-Platten unterstützt. Ebenfalls nicht alle verfügbaren Disk-Interface-Karten werden unterstützt. Für die Überprüfung der unterstützten Konfigurationen vgl. die jeweils aktuelle Dokumentation von Hewlett-Packard zu HP 9000 Servers Configuration. Externe Shared Fast/Wide SCSI-Busse müssen mit in-line-Terminatoren für Platten auf einem Shared Bus ausgestattet sein. Bei Planung und Zuweisung der SCSI-Bus-Prioritäten muss berücksichtigt werden, dass ein Host einen Bus, der von mehreren Knoten geteilt wird, abhängig von der SCSI-Adresse dominieren kann, die die Disk-InterfaceKarte eines jeden Knotens auf dem Shared Bus zugewiesen bekommen hat. Sämtliche SCSI-Adressen inklusive sämtlicher Adressen aller Interface Karten müssen eindeutig für alle Devices auf dem Shared Bus sein.

1.

154

Abhängig vom Betriebssystem eines Cluster-Knoten werden unterschiedliche VolumeManager für diese Funktionalität eingesetzt. HP/UX verwendet den LVM, Tru64-Unix und AIX einen vergleichbaren, unter Solaris sowie bei den beiden davor genannten wird jedoch auch sehr häufig der Veritas Volume-Manager VxVM verwendet. Vgl. hierzu das Kapitel über SAN-Softwarekomponenten weiter unten.


Daten-Absicherung Für die Gewährleistung der Hochverfügbarkeit des kompletten MetroClusters müssen auch die Magnetplatten vor Ausfall abgesichert werden. Dazu unterstützt MC/ServiceGuard mit 왘 Plattenspiegelung (Disk Mirroring) und 왘 Disk Arrays mit RAID-Level und PV-Link-Unterstützung

zwei Verfahren, die die Daten auf Magnetplatten absichern.

Plattenspiegelung Die Plattenspiegelung für die Volumes, die für MC/ServiceGuard-Packages verwendet werden, ist die beste Form der Absicherung der PackageInformationen. Dabei bietet MC/ServiceGuard selbst keine Möglichkeit, die Daten auf den Magnetplatten zu schützen. Diese Funktion übernimmt mit MirrorDisk/UX von HP ein Softwareprodukt, das in enger Abstimmung mit dem LVM arbeitet. Bei der Konfiguration der logischen Volumes mithilfe von MirrorDisk/UX wird seitens MirrorDisk/UX gewährleistet, dass sämtliche Magnetplatten eines gespiegelten Platten-Sets die exakt identischen Daten enthalten. Fällt eine Magnetplatte aus, hält MirrorDisk/UX automatisch die Daten über den zweiten Spiegel verfügbar. Eine Spiegelung auf eine dritte Magnetplatte kann für Online-Datensicherungen oder für ein noch höheres Level an Hochverfügbarkeit verwendet werden. Um sich gegen Ausfälle des SCSI-Busses zu schützen, muss jede Platte über zwei SCSI-Busse verfügbar sein. Dies kann dadurch erreicht werden, dass z.B. das Original der Platte an einem anderen SCSI-Bus angeschlossen wird als sein Spiegel. Während es zwar sinnvoll ist, jedoch in einer Cluster-Umgebung nicht unbedingt notwendig, die Root-Disk eines Cluster-Knotens zu spiegeln, ist es absolut unerlässlich, die Daten- und Programm-Platten eines Packages zu spiegeln. Kommt es zu einem Fehler der Root-Disk einer SPU des Clusters, so übernimmt automatisch die zweite SPU die Kontrolle über sämtliche Applikationen der ersten. Ist jedoch eine ungespiegelte Datenplatte von einem Fehler betroffen, so ist jede von den Daten dieser Platte abhängige Applikation solange nicht verfügbar, bis das Problem mit dieser Platte beseitigt wurde. Selbst dann ist nicht unbedingt sichergestellt, dass die Daten auf dieser Magnetplatte bis zum Zeitpunkt des Fehlers wiederhergestellt werden können.

Disk Arrays mit RAID-Levels und PV-Links Eine alternative Methode zur Gewährleistung der Platten-Protection ist der Einsatz von Storage Arrays mit RAID-Level und PV-Link-Unterstützung. Dabei bieten die Storage Arrays mit RAID 1 (Disk Mirroring) und RAID 5 (Disk Striping mit Parity) zwei Verfahren zur (redundanten) Absicherung der Magnetplatten (vgl. Abschnitt 4.3. Hochverfügbare Speichersysteme).

155


Diese Storage Array-interne Absicherung der Magnetplatten muss kombiniert werden mit zwei Pfaden vom Cluster-Knoten zum Storage Array, es müssen also seitens des Cluster-Knotens zwei Disk-Interface-Karten auf die Magnetplatten des Storage Arrays zugreifen können. Weiter müssen diese über zwei Systemadapter des Storage Arrays sichtbar sein, sodass weder auf Cluster-Knoten-, noch auf Storage Array-Seite ein Single-point-of-Failure existiert. Die softwareseitige Unterstützung alternativer Links zwischen Cluster-Knoten und Storage Array und damit die Ausnutzung der Redundanz von Disk-Interface-Karten und Systemadaptern wird durch das PV-Links-Feature des Logical Volume-Managers übernommen.

Monitoring von Magnetplatten durch ein Event Monitoring-System Der Zustand der abgesicherten Platten innerhalb des Clusters kann auch durch ein Event Monitoring-System oder System-Administrations-System überwacht werden. Dies kann z.B. der EMS HA-Monitor (HP), Patrol (BMC), Maestro (IBM ), ECC (EMC2) oder Tivoli (IBM) sein. Der Monitor kann einen Plattenfehler oder ein Package-Failover zu einer Zielapplikation wie z.B. ClusterView (HP) oder den oben genannten System-Administrations-Systemen melden. Diese übernehmen dann die Steuerung automatisierter Reaktions-Prozesse auf den jeweiligen Fehler. Abbildung 4.7: MetroCluster – Gespiegelte Platten


SC SI H B A

SC SI H B A

Root Disk

Mirror Disk Group Package 2

S A


Mirror Root Disk

Local Storage


SC SI H B A

SC SI H B A

156

Array


Root Disk

S A

Mirror Root Disk

Mirror Disk Group Package 1


Abbildung 4.8 zeigt eine hochverfügbare MC/Service-Guard Storage ArrayKonfiguration mit zwei Cluster-Knoten. Jeder Knoten besitzt eine gespiegelte Root-Disk und ein Package, für das er den Primär-Knoten darstellt. Die Ressourcen sind auf die beiden Knoten so verteilt, dass jeder den Adoptive Node für das Package des jeweils anderen Knoten darstellt. Jedem Package ist eine Disk Group assoziiert. Die Volumes dieser Disk Group sind im Storage Array gespiegelt. Dabei ist darauf zu achten, dass die Spiegel-Volumes einer Disk Group stets auf dem jeweils anderen Interface als ihre Original-Volumes konfiguriert sind. Diese Konfiguration eliminiert Single Points of Failure und gewährleistet, dass bei einem Bus-Fehler entweder das Original-Volume oder das Spiegel-Volume verfügbar ist.

ESCON

S CS I

FIBRE

FIBRE

Abbildung 4.8: Architektur eines hochverfügbaren Storage Arrays

Top-High Top-Low Bottom-High

Ca c h e Bottom-Low

DD

DD

DD

DD

Root-Disk-Begrenzungen auf Shared Bussen Die IODC-Firmware von Hewlett-Packard unterstützt nicht, dass zwei oder mehr Knoten eines Clusters zum gleichen Zeitpunkt von ein und demselben SCSI-Bus booten. Daher ist es absolut notwendig, dass nicht mehr als eine Root-Disk eines Clusters an einem einzigen SCSI-Bus konfiguriert wird. Dies wird im obigen Beispiel gewährleistet. Jede Root-Disk hängt an einem eigenständigen SCSI-Controller und an einem SCSI-Bus. Ein Spiegel der Root-Disk eines Cluster-Knotens kann auf demselben SCSIBus konfiguriert werden wie die originale Root-Disk eines anderen ClusterKnotens. Um in einem solchen Falle die Verfügbarkeit des Gesamtsystems zu verhindern, müssten gleichzeitig drei Fehler auf den beteiligten Primär-

157


und Adoptive-Knoten eintreten. Knoten B müsste seine originale Root-Disk verlieren und von seinem Spiegel gerade booten, während Knoten A gerade während des Boot-Vorgangs von Knoten B ebenfalls von seiner originalen Root-Disk rebooten müsste. Das scheint ein tragbares Risiko zu sein. In Abbildung 4.8 ist jedoch auch dieses Risiko ausgeschlossen, da die MirrorRoot-Disks auf anderen SCSI-Bussen liegen als sämtliche Original-RootDisks. Eine Platte innerhalb eines Storage Arrays kann nicht als Root-Disk verwendet werden, wenn das Storage Array an einem Shared Bus angeschlossen ist. Für solche Funktionalitäten sollte das Storage Array stets allein an einem Host-Bus-Adapter angeschlossen werden.

4.1.1.4

Größere Cluster

MC/ServiceGuard unterstützt Cluster von bis zu 16 Knoten. Ein Cluster aus 16 Cluster-Knoten erfordert, dass die SPUs über Ethernet miteinander verbunden sind. Verbindungen der Cluster-Knoten über FDDI oder Fibre Channel reduzieren die maximale Anzahl der von MC/ServiceGuard unterstützten Cluster-Knoten auf acht. Bei einer Cluster-Konfiguration von 16 Cluster-Knoten können nicht sämtliche Cluster-Funktionalitäten auf die Weise angeboten werden, wie sie in den obigen Abschnitten erläutert wurden. So können z.B. bei Shared Fast/Wide SCSI-Bussen lediglich vier Cluster-Knoten an den gleichen Shared SCSI-Bus angeschlossen werden (4-Port SCSI Limit). Dieses Limit ist ebenfalls durch die sinnvolle Auslastung des einzelnen SCSI-Busses und durch die Limitierung der Kabellänge auf wenige Meter gegeben. Dennoch können auch in einer solchen-Umgebung bis zu 16 Knoten als administrative Einheit konfiguriert werden. Untergruppierungen von vier Knoten können dann an unterschiedliche SCSI-Busse angeschlossen werden, die Direct Attached zu ihren jeweils unterschiedlichen Massenspeichergeräten über Fast/Wide SCSI verbunden sind. Beim direkten Anschluss von Storage Arrays über F/W SCSI (Fast/Wide SCSI) existiert dieses Limit auf vier Knoten nicht, da es sich hierbei nicht um Shared Busse handelt. Jeder Host (Cluster-Knoten) kann über einen Port eines SCSI-Systemadapters des Storage Arrays angeschlossen werden. Hier ist die Grenze eher theoretischer Art und wird durch die maximale Anzahl der seitens des Storage Arrays unterstützten 4-Port SCSI-Systemadapter gebildet. Jeder Cluster-Knoten kann bei MC/ServiceGuard über zwei F/W SCSI-Busse Direct Attached an das Storage Array angeschlossen werden. Über PV-Links werden diese beiden Busse für Kanal-Failover verwendet, bieten also die Multipathing-Fähigkeit für Hochverfügbarkeit an. In einer solchen – Storage Array getriebenen – Cluster-Umgebung können Packages für das Failover über sämtliche 16 Cluster-Knoten konfiguriert und betrieben werden. Ebenfalls könnte die Begrenzung auf maximal acht unterstützte ClusterKnoten für Fibre Channel-SAN-Konfigurationen überdacht werden. Auch hier wäre in einer SAN-Konfiguration einer FC-SW-Umgebung die Anzahl

158


der Hosts innerhalb eines Clusters und die Anzahl der Verbindungen an Storage Arrays lediglich limitiert durch die Anzahl der Ports der eingesetzten Fabric und der Ports an Fibre Channel-Systemadaptern der im SAN beteiligten Storage Arrays. Dennoch – MC/ServiceGuard behält die Limitierung auf acht Cluster-Knoten bei. Bei Betrachtung der Leitungskapazitäten der dann eingesetzten Fibre Channel-Host-Bus-Adapter, Switches und Fibre ChannelSystemadapter in den Storage Arrays erscheint diese Einschränkung eher durch die Leistungsgrenzen der I/O-Prozessoren der Hostsysteme sinnvoll als durch die Möglichkeiten des SAN.

Das Active/Standby-Modell Unter MC/ServiceGuard können Cluster auch so konfiguriert werden, dass quasi ein Cluster-Knoten der Adoptive Knoten sämtlicher anderer Knoten ist. Diese anderen Knoten sind die Primären Knoten der jeweiligen Packages. Der Standby- oder Backup-Knoten ist mit einer entsprechenden Anzahl von Shared Bussen ausgestattet, die es ermöglichen, diesen Knoten mit sämtlichen Storage Devices der Primären Knoten zu verbinden. Fällt einer der Knoten aus, so kann problemlos auf den Backup-Knoten geschwenkt werden. Eine solche Konfiguration kann eindeutig einen singulären Fehler einer Cluster-Komponente ausgleichen und damit ein Hochverfügbarkeits-Szenario implementieren. Der Nachteil des Active/Standby-Modells liegt jedoch auf der Hand – es kann keine Doppelfehler abfangen, bei denen ein Fehler den Backup-Knoten selbst betrifft. Fällt gleichzeitig der SCSI-Kanal eines Cluster-Knotens sowie der entsprechende Kanal des Backup-Knotens aus, so ist ein Package-Switching nicht mehr möglich. Die Möglichkeit von MC/ServiceGuard, innerhalb eines Clusters mehrere Knoten als Adoptive Knoten eines Packages zu definieren, bietet daher ein größeres Maß an Ausfallsicherheit als die Konfiguration eines dedizierten Standby- oder Backup-Knotens.

Point-to-Point-Verbindungen zu Speichergeräten Point-to-Point-Verbindungen zu Storage Devices für eine große Anzahl von Hosts ohne Verwendung eines Shared SCSI-Busses, z.B. für einen 8-Knoten MC/ServiceGuard-Cluster, werden durch die Anzahl der verfügbaren Ports des Storage Devices – in der Regel ein Storage Array – definiert. So können z.B. leistungsfähige Storage Arrays bis zu 14 Systemadapter für den HostAnschluss verfügbar machen. Je nach Adapter-Anschluss-Technologie (vgl. Kapitel 2), können z.B. je Systemadapter zwei Ports (Fibre Channel-Systemadapter) oder vier Ports (F/W SCSI-Systemadapter) für den direkten Anschluss des Storage Arrays an unterschiedliche Knoten verfügbar gemacht werden. In einer hochverfügbaren Cluster-Umgebung könnten somit bei Verwendung der Fibre Channel-Technologie 14 Cluster-Knoten mit jeweils zwei Pfaden Direct Attached an das Storage Array angeschlossen werden. Jeder der 28 verfügbaren Kanäle wäre ein dedizierter Bus, es existierte kein Daisy-Chaining, die komplette Bandbreite eines jeden Busses könnte ausgenutzt werden.

159


Ob eine solche Point-to-Point-Verbindung der Storage Devices jedoch einer aktiven SAN-Umgebung vorzuziehen wäre, mag der Leser entscheiden. Die Storage Arrays – dies machen jedoch die letzten Unterkapitel immer deutlicher – sind die tragenden Bausteine für hochverfügbare ClusterUmgebungen.

4.1.2

Sun Enterprise Cluster-HA

Dieser Abschnitt soll vertiefen, dass die Cluster-Technologie zur Gewährleistung der Hochverfügbarkeit von Anwendungen und Geschäftsfunktionen auch bei dem zweiten führenden Hersteller von OpenSystems-Hochleistungs-Serversystemen als evident erkannt und implementiert wurde. Sun bietet mit seiner Produktfamilie der Sun Enterprise Cluster-HA Clusterkonfigurationen für Cluster mit zwei Knoten an, bei denen der eine Knoten der Failover-Knoten eines Produktivknotens ist. Dabei besteht die Sun Enterprise Cluster-HA aus folgenden Komponenten: Sun Enterprise Cluster-HA 1.3 왘 Jeweils zwei cluster-fähige Knoten 왘 HA Cluster Foundation Package 왘 1 Basis-Softwarepaket inklusive HA-NFS 왘 ein optionales Daten-Service-Modul sowie 왘 ein SunService HA Support-Paket

Solstice HA Software 왘 Cluster-Management-Software 왘 Fehler-Erkennung und Recovery-Software 왘 Sun HA-Basis-Software 왘 HA-NFS

Daten-Service-Module 왘 Informix Online 왘 Oracle 왘 Sybase Adaptive Server Enterprise 왘 Internet Services

SunService HA-Support-Paket 왘 Installation und Beratung 왘 Training 왘 Gewährleistung

160

Hochverfügbare Speichersysteme

Die Aufzählung der Basiskomponenten im Gegensatz zur ausführlichen Darstellung der MetroCluster ServiceGuard-Architektur seitens HewlettPackard mag den Eindruck erwecken, der Autor will die HA-Cluster-Produkte des einen Herstellers denen des anderen Herstellers vorziehen. Dieser Eindruck trügt. Dennoch wird auch seitens der selbst durch Sun stark reduzierten Marketing-Unterstützung der eigenen HA-Produkte deutlich, dass Sun hier anscheinend ein größeres Merkmal auf die Leistungsfähigkeit der Server-Systeme gelegt hat als auf deren Cluster-Integration. Dies verhindert jedoch nicht, dass Sun-Systeme auch zu größeren Clustern mit vergleichbarer Leistungsfähigkeit zur MC/ServiceGuard-Architektur zusammengefasst werden. Das geschieht jedoch in der Praxis weniger durch Nutzung der Sun Enterprise Cluster-HA, sondern durch Verwendung der Sun Server-Systeme als Cluster-Knoten vor allem in Veritas Cluster-ServerCluster-Umgebungen. Diese wiederum bestehen aus den redundant und hochverfügbar konfigurierten Standard-Komponenten von z.B. Sun Enterprise-Systemen und den entsprechenden Veritas-Softwareprodukten (Veritas Cluster-Server VCS und Veritas Volume-Manager VxVM), die im Abschnitt der SAN-Softwarekomponenten einen ebenso großen Raum einnehmen werden wie MC/ServiceGuard als Beispiel für Cluster-Software. Im Folgenden soll jetzt die Server-Seite in Richtung der Storage Seite verlassen werden.

4.2


Hochverfügbare Speichersysteme sind die Basisbausteine von Storage Area Networks und Network Attached Storage. Sie zeichnen sich dadurch aus, dass sämtliche Systemkomponenten redundant und ausfallsicher zusammengestellt sind. In aller Regel können solche Speichersysteme von ihrem jeweiligen Hersteller gar nicht mit einem potentiellen Single Point of Failure erworben werden, Konfigurationen ohne Komponentenredundanz werden von den entsprechenden Hardwarearchitekten der Hersteller abgelehnt. Diese Speichersysteme unterstützen eine Vielzahl von Anschluss-Technologien. Werden die Server über Fibre Channel an die Speichersysteme angeschlossen, so können diese zu hochverfügbaren Storage Area Networks zusammengeschlossen werden. Werden die Storage-Systeme über Netzwerk-Protokolle welcher Art auch immer von den Servern erreicht, so kann über sie ein hochverfügbares Netzwerk von Network Attached Storage aufgebaut werden. Dieser Abschnitt des Buches stellt die Hardware-Komponenten solcher hochverfügbaren Speichersysteme vor.

161


4.2.1

Basisbausteine

Ein hochverfügbares Speichersystem besteht in der Regel aus einem FrontEnd-System, über das die Verbindung zwischen Speichersystem (Storage Array) und Server hergestellt wird. Die physikalischen Magnetplatten werden von den Disk Directoren (Magnetplatten-Controllern) des Back-End-Systems des Storage Arrays verwaltet und kontrolliert. Das Bindeglied zwischen Front-End und Back-End des Storage Arrays stellt der Cache dar. Dieser Cache ist über sämtliche Storage Array-internen Busse erreichbar. Jede Operation innerhalb des Storage Arrays läuft über den Cache. Abbildung 4.9: Front-End/Cache/ Back-End-Aufbau eines hochverfügbaren Storage Arrays

Front-End

Globa l S ha re d Me mory To p-Hig h

Ba ck-End Top-Low


Dis k Dire c to r


P ort A P ort B

P roze s s or B bs pw. P owe rP C750 266 MHz

P roze s s or B, bs pw. P owe rP C750 266 MHz

P ort C P ort D

P ort A P ort B P roze s s or A, bs pw. P owe rP C750 266 MHz

P roze s s or A, bs pw. P owe rP C750 266 MHz

Tra c k Ta b le S ta tu s u n d Ko m m u n ika Tra c k Ta b le tio n s -Ma ilb 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-High

In den Abbildungen 4.8 und 4.9 wird der redundante Aufbau des Storage Arrays sichtbar. Jeder Channel Director des Front-End-Systems besteht aus zwei Prozessoren. Jeder dieser Prozessoren stellt einen der in den bisherigen Abschnitten des Buches ständig erwähnten Systemadapters dar. Jeder Disk Director besteht ebenfalls aus zwei Prozessoren. Jeder dieser beiden Prozessoren ist ein eigenständiger Disk-Adapter. Die beiden Prozessoren stellen sicher, dass über sie sämtliche Bereiche des Global Shared Memory (Cache) erreicht werden.

162


Front-End Channel Directors unterstützen unterschiedliche Protokolle und Anschluss-Technologien. Diese sind mit den unterschiedlichsten Leistungsmerkmalen und Einschränkungen ausgestattet. Je nachdem, welche Anwendung durch das Storage Array unterstützt werden soll, werden die unterschiedlichen Konfigurationen des Front-End-Systems mit den unterschiedlichen Channel Director-Typen gewählt. Aufbau und Funktion der Front-End/Cache/Back-End-Komponenten des hochverfügbaren Storage Arrays werden in den folgenden Abschnitten erläutert.

4.2.1.1

Front-End-Konfiguration Front End

Ho s t A Ch a n n e l Dire c to r

P roze s s or B, bs pw. P owe rP C750 266 MHz

In te rfa c e

Ma xim a le En tfe rn u n g

MB/ Sek

Ka b e ltyp

Ho s ts

P a ra lle l

4

Ca . 160 m

4,5

P a ra lle l Kupfe r

Ma infra me

ES CON

2/4

3 km ohne Re pe a te r

17

Gla s fa s e r 62,5 µ

Ma infra me

4

25 m (FWD) 19 m (UWD)

20 40

P a ra lle l Kupfe r

Ope n S ys te ms

S CS I

P roze s s or A, bs pw. P owe rP C750 266 MHz

P o rts

Fibre Cha nne l

2 4.x

300 m/ 500 m

100

Gla s fa s e r 62,5 µ / 50 µ

Ope n S ys te ms

Fibre Cha nne l

8/2 5.x

300 m/ 500 m

100

Gla s fa s e r 62,5 µ / 50 µ

Ope n S ys te ms

Abbildung 4.10: Channel Director Interface-Technologien

Ho s t B

Hochverfügbare Storage Arrays zeichnen sich dadurch aus, dass sie in ihrer Front-End-Konfiguration eine Vielfalt von Anschluss-Technologien unterstützen, über die sie einen UnShared Channel zum jeweiligen Hostsystem gewährleisten. So bieten moderne SAN-fähige Storage Arrays in aller Regel folgende Channel Directors zum Anschluss von Serversystemen an: 왘 SCSI Channel Directors zum Direct Attached-Anschluss sämtlicher gän-

gigen Open Systems-Hosts 왘 Parallele Channel Directors zum Anschluss von Hosts aus der Main-

frame-Welt

163

4 SAN – Hardware-Komponenten 왘 ESCON Channel Directors zum Anschluss von Hosts aus der Main-

frame-Welt über ein IBM-eigenes Glasfaser-Protokoll, jedoch auch zum Aufbau mehrerer SANs über mit ESCON verbundene hochverfügbare Storage Arrays und natürlich 왘 Fibre Channel Directors zum Anschluss von Open Systems und Main-

frame-Hosts über Fibre Channel-Protokoll und zum Aufbau von Hochleistungs-SANs.

SCSI System-Adapter Abbildung 4.11: SCSI Front-End DirectorKonfiguration

S CS I

S CS I

S CS I

S CS I

Top-High

Top-Low

Bottom-High

Ca c h e Bottom-Low

SCSI System-Adapter stellen die klassische Anschluss-Technologie von Open Systems an Storage Arrays dar. Ein SCSI-Channel Director besteht aus zwei SCSI-Systemadaptern. Jeder dieser Systemadapter besitzt normalerweise vier externe Ports, über die Ports der externen SCSI-Host-Bus-Adapter von Open Systems-Hosts angeschlossen werden. Von diesen vier externen Ports können – je nach Hersteller des Storage Arrays – sämtliche Ports zum Anschluss von Hosts oder nur zwei der vier Ports verwendet werden. Die beiden übrigen werden dazu verwendet, auf die zwei aktiven Ports eines anderen SCSI-Systemadapters auf einem zweiten Channel Director durchzuschleifen, der – bei Ausfall des Systemadapters – dann auch sämtliche Host-Verbindungen des ausgefallenen Systemadapters übernimmt. Dieses

164


Funktionsprinzip wird als Dual Initiation eines Kanalprozessors bezeichnet und später in diesem Kapitel beimDual-Initiated Disk-Adapter genauer beschrieben. Wie aus Abbildung 4.11 ersichtlich, wird jeder SCSI-Channel Director an zwei interne Busse des Storage Arrays angeschlossen und sieht entweder über den Top-High- und Bottom-Low-Bus oder über den Bottom-High- und Top-Low-Bus den kompletten Cache des Storage Arrays. Der SCSI-Channel Director kann nun sämtliche physikalischen Magnetplatten adressieren, die über die gleichen internen Busse an den Cache des Storage Arrays angeschlossen sind.

Parallele System-Adapter Parallele (Centronix) System-Adapter stellen die klassische AnschlussTechnologie von Mainframe-Hostsystemen an Storage Arrays dar. Ein Parallel-Channel Director besteht aus zwei Centronix-Systemadaptern. Jeder Parallel-Channel Director besitzt vier externe Ports (zwei Bus- und zwei TagPorts), über die die Ports von externen Mainframe-Parallel Host-Bus-Adaptern angeschlossen werden. Auch parallele Channel Directors werden, wie oben schon für die SCSISystemadapter beschrieben, an zwei interne Busse des Storage Arrays angeschlossen und sehen entweder über den Top-High- und den Bottom-Low-Bus oder über den Bottom-High- und den Top-Low-Bus den kompletten Cache des Storage Arrays. Der parallele Channel Director kann nun sämtliche physikalischen Magnetplatten adressieren, die über die gleichen internen Busse an den Cache des Storage Arrays angeschlossen sind.

ESCON System-Adapter Das ESCON-Protokoll (Enterprise Systems Connection) wurde seitens IBM als herstellereigener Standard für hochverfügbare Host-/Storage-Verbindungen auf Glasfaserbasis entwickelt. Dieses Glasfaser-Protokoll erweitert die maximale Distanz zwischen Host und Storage-System auf drei km (ohne Repeater) und steigert die Übertragungsbandbreite auf 17 MB/Sek. Daher wird der Anschluss von Mainframe-Hostsystemen in Glasfaser-Umgebungen bevorzugt über ESCON Host-Bus-Adapter und ESCON Directors auf Storage Seite durchgeführt. Auch die ESCON Channel Directors werden, wie oben für die SCSI-Systemadapter und Parallele Channel Directors beschrieben, an zwei interne Busse des Storage Arrays angeschlossen und sehen entweder über den Top-Highund den Bottom-Low-Bus oder über den Bottom-High- und den Top-LowBus den kompletten Cache des Storage Arrays. Der ESCON Channel Director kann nun sämtliche physikalischen Magnetplatten adressieren, die über die gleichen internen Busse an den Cache des Storage Arrays angeschlossen sind.

165

4 SAN – Hardware-Komponenten Abbildung 4.12: ESCON Front-End DirectorKonfiguration ES CON

ES CON

ES CON- ES CONRLD RLD

ES CONRLD

ES CONRLD

ES CON

ES CON

Top-High

Top-Low

Bottom-High

Ca c h e

Ca c h e

Bottom-Low



ESCON wird bevorzugt in Mainframe-Umgebungen jedoch auch für den Aufbau hochverfügbarer Storage Area Networks eingesetzt, bei denen die Magnetplatten eines lokalen Storage Arrays auf einem Remote Storage Array gespiegelt werden. Werden für diese Funktionalität ESCON Remote Link Directors (ESCON RLD) verwendet, so erfolgt die Verbindung von einem Storage Array zum andern. Die Spiegelung der Platten erfolgt Cache-gesteuert und basiert auf dem Remote Link Director. Host-Ressourcen werden dabei nicht benötigt. Die Bandbreite der Spiegelungs-Kommunikation entspricht der vollen ESCON-Bandbreite von 17 MB/Sek. je Director-Port. Werden zwei ESCON Remote Link Directors auf beiden Storage Arrays mit jeweils vier Ports eingesetzt, ergibt sich daraus eine Bandbreite von 136 MB/Sek. für den Datentransfer vom lokalen zum Remote Storage Array.

Fibre Channel-System-Adapter Fibre Channel Directors unterstützen je Kanal-Schnittstelle (Port) die komplette Übertragungsbandbreite von 100 MB/Sek. für den Datentransfer vom Serversystem zum Storage Array oder – in einer FC-SW-Umgebung – vom Switch-Port zum Fibre Channel Director-Port. Auch die Fibre Channel Directors werden, wie oben schon für die SCSI-Systemadapter sowie die parallelen Channel Directors und die ESCON Channel Directors beschrieben, an zwei interne Busse des Storage Arrays angeschlossen und sehen entweder über den Top-High- und den Bottom-Low-Bus oder über den Bottom-High- und den Top-Low-Bus den kompletten Cache des

166

Hochverfügbare Speichersysteme Abbildung 4.13: Fibre Channel Front-End DirectorKonfiguration FIBRE FIBRE CHANNEL CHANNEL

FIBRE FIBRE CHANNEL CHANNEL RLD RLD

FIBRE FIBRE CHANNEL CHANNEL RLD RLD

FIBRE FIBRE CHANNEL CHANNEL

Top-High

Top-Low

Bottom-High

Ca c h e

Ca c h e

Bottom-Low



Storage Arrays. Der Fibre Channel Director kann nun sämtliche physikalischen Magnetplatten adressieren, die über die gleichen internen Busse an den Cache des Storage Arrays angeschlossen sind. Fibre Channel wird bevorzugt in Open Systems-Umgebungen eingesetzt, jedoch auch für den Aufbau hochverfügbarer Storage Area Networks, bei denen die Magnetplatten eines lokalen Storage Arrays auf einem Remote Storage Array gespiegelt werden. Werden für diese Funktionalität Fibre Channel Remote Link Directors (FIBRE CHANNEL-RLD) verwendet, so erfolgt die Verbindung von einem Storage Array zum andern. Die Spiegelung der Platten erfolgt Cache-gesteuert und basiert auf einem Remote Link Director. Host-Ressourcen werden dabei nicht benötigt. Die Bandbreite der Spiegelungs-Kommunikation entspricht der vollen Fibre Channel-Bandbreite von 100 MB/Sek. je Director-Port. Werden zwei Fibre Channel Remote Link Directors auf beiden Storage Arrays mit jeweils zwei Ports eingesetzt, ergibt sich daraus eine Bandbreite von 400 MB/Sek. für den Datentransfer vom lokalen zum Remote Storage Array. In der Regel besteht ein Fibre Channel Director aus zwei Karten – einem Director Board und einem Adapter Board. Sämtliche Director-Karten können in hochverfügbaren Storage Arrays in der Regel in sämtliche Slots für Directors eingebaut werden, sie sind also gegeneinander austauschbar. Die Storage Arrays können auch mit Channel Directors unterschiedlicher Verbindungs-Technologien gemischt betrieben werden.

167

4 SAN – Hardware-Komponenten Abbildung 4.14: Aufbau eines Fibre Channel Front-End Directors

Tachyon Chip

A

B

M I D P L A N E

ADAPTER

Tachyon Chip

Prozessor B

Prozessor A

DIRECTOR

T O P H I G H

B O T T O M L O W

Das Director Board eines Fibre Channel Directors enthält in der Regel folgende Bausteine: 왘 Zwei ANSI-kompatible Fibre Channel-Interfaces mit einer Bandbreite

von jeweils 1 GigaBit zum Adapter-Port. 왘 Zwei Prozessor-Chips – z.B. HP Tachyon, die die Fibre Channel Encode/

Decode des Fibre Channel-Layers FC-1 und die Framing-Protokoll-Funktion des Fibre Channel-Layers FC-2 übernehmen. Wird der Fibre Channel Director in einer Arbitrated Loop-Topologie betrieben, so übernehmen diese Chips auch noch die benötigte Repeater-Funktion. 왘 Zwei Mikroprozessoren (z.B. Power PC 750, 266 MHz), die die vom Ser-

ver kommenden Kommandos und Daten verarbeiten und den Zugriff auf den Cache verwalten. Wird das Storage Array auf der Back-End-Seite nicht in Fibre Channel-Technologie, sondern rein SCSI-basiert betrieben, so erfolgt durch diese Prozessoren ebenfalls das Fibre Channel für das SCSI-Protokoll-Mapping sowie die Unterstüzung der oberen Fibre Channel-Protokoll-Ebenen. Das Adapter Board stellt die Schnittstelle zwischen dem Director Board des Storage Arrays und dem Host-Kanal dar, d.h. einem Fibre Channel-N-Port auf einem Fibre Channel-Host-Bus-Adapter eines Serverrechners oder dem F-Port eines Switches in einer FC-SW-Umgebung oder einem weiteren NLPort in einer FC-AL-Umgebung.

168


Der Adapter ist also das tatsächliche Kanal-Interface des Storage Arrays und bietet damit die Funktion des Fibre Channel Layers FC-0. Jeder Adapter besitzt zwei Transceiver-Schnittstellen für Fibre Channel-Ports, je Fibre Channel Director werden also zwei Fibre Channel-Ports angeboten. Die Adapter-Karte wird am Backplane des Storage Arrays genau gegenüber seinem Director Board eingesteckt. In Abbildung 4.14 werden die Verbindungen und Datenpfade eines Fibre Channel Kanal-Directors dargestellt. Zwei Server/Host-Kanäle werden an das Adapter Board angeschlossen. Dieses befindet sich am Backplane des Storage Arrays. Die Director-Karte auf der anderen Seite des zentralen Midplane des Storage Arrays besitzt einen Fibre Channel auf jeder Hälfte der Karte. Die A- und die B-Seite des Director Boards operieren vollkommen unabhängig voneinander. Sie routen die Host-Kommandos und -Daten über den Cache zu den internen Systembussen. Sowohl der Cache als auch die Channel Directors übernehmen die Storage-Control-Funktionen. Das tatsächliche Speichern der Informationen auf den Magnetplatten wird von den Disk Directors des Back-Ends des Storage Arrays übernommen.

Dual-Pathing Front-End-Konfiguration Front-End



Abbildung 4.15: Dual-PathingKonfiguration

Ba ck-End

Top-Low Ca c h e S lo ts

Dis k Dire c to r

P ort A P ort B



Ho s t

P ort C P ort D


P ort A P ort B Tra c k Ta b le Ch a n n e l Dire c to r

Status und Ko m m u n ikaTra c k Ta b le tio n s- Ma ilb o xe s


40 MB/S e kUltraS CS I-Bus

P ort C

P roze s s or B P owe rP C750

P ort D

266 MHz

High Me mory P roze s s or A

DA (Dis kAd a p te r)

Low Me mory

P owe rP C750 266 MHz

Bo tto m-High Bo tto m-Low

Abbildung 4.15 zeigt eine typische Konfiguration für das Dual-Pathing eines Hosts auf seine Storage Devices. Der Host ist über zwei Channel Directors an das Storage Array angeschlossen. Über die beiden B-Prozessoren der Channel Directors werden die Top-High/Bottom-Low-Systembusse erreicht, über die beiden A-Prozessoren der Channel Directors die Bottom-High/Top-

169


Low-Systembusse. Fällt einer der Prozessoren oder ein kompletter Channel Director aus, so kann über die Kanäle des zweiten Channel Directors auf dieselbe Back-End-Konfiguration zugegriffen werden.

4.2.1.2

Back-End-Konfiguration

SAN-fähige hochverfügbare Storage Arrays werden zurzeit in drei gängigen Back-End-Konfigurationen angeboten: 왘 Klassische SCSI-Back-End-Konfigurationen, bei denen SCSI Disk-Adap-

ter über vier SCSI-Ports bis zu acht physikalische Magnetplatten je Port administrieren 왘 FC-AL Back-End-Konfigurationen, bei denen die physikalischen Mag-

netplatten in der Regel in zwei Arbitrated Loop Daisy-Chains angesteuert werden 왘 FC-SW Back-End-Konfigurationen mit internen Fibre Channel-Switches,

über die Fibre Channel Disk Directors die physikalischen Fibre ChannelMagnetplatten administrieren Auf der Back-End-Seite der Storage Arrays werden heute die Leistungs- und Funktionalitätswettbewerbe der Storage Array-Hersteller ausgetragen. Dabei weisen die Anbieter der SCSI-Back-End-Architekturen zu Recht darauf hin, dass Fibre Channel-Magnetplatten heutzutage noch unverhältnismäßig teuer sind und von wesentlich weniger unabhängigen Lieferanten zur Verfügung gestellt werden als Standard-SCSI-Platten. Weiter wird hier darauf hingewiesen, dass bei einer ausreichenden Anzahl konfigurierter SCSI-Disk-Adapter die SCSI-Bandbreite durchaus ausreichend ist, damit das Back-End des Storage Arrays nicht zum Performance-Flaschenhals des Gesamtsystems gerät. Dem halten vor allem die Hersteller der FC-SW Back-End-Konfigurationen entgegen, dass gerade in Storage Area Networks der Datendurchsatz das wesentliche K.O.-Kriterium für Storage Arrays sei und man doch idealerweise die überlegene Bandbreite von Fibre Channel durchgängig auf FrontEnd und Back-End des Storage Arrays implementieren sollte. Die Hersteller der Storage Arrays mit einem auf FC-AL basierenden Back-End beteiligen sich in aller Regel nicht an dieser Technologiediskussion. Das mag vor allem daran liegen, dass aufgrund des Daisy-Chainings der Magnetplatten in der FC-AL-Architektur die 100 MB/Sek. Bandbreite jeweils nur für eine aktuelle Verbindung gelten, während die übrigen Devices solange warten müssen, bis die Arbitration wieder an sie geht. Hier ist die Bandbreite des Fibre Channels also geteilt zwischen sämtlichen Magnetplatten, die sich in der Loop befinden. Es ist daher auch nicht unbedingt ein Bandbreiten- und PerformanceVorteil gegenüber einer rein SCSI basierten Back-EndKonfiguration zu erwarten. Auf FC-AL basierende Back-End Storage Arrays befinden sich daher auch im Wesentlichen im Low-End und im mittleren Größenbereich der SAN Storage Arrays.

170


Der Technologiewettstreit findet im Top-Leistungsbereich mit EMC2 und Hitachi (Hewlett-Packard als dritter »eigenständiger« Anbieter von Highend-Storage Arrays vermarktet aktuell lediglich Hitachi-Systeme) zwischen nur zwei Herstellern statt. Er soll in diesem Buch nicht entschieden werden. Allein von der installierten Basis her ist das SCSI-Back-End die heute am weitesten verbreitete Technologie. Je mehr sich jedoch Fibre Channel als das Protokoll der Wahl zum Anschluss der Hosts an die Front-Ends der Storage Arrays durchsetzen wird und je leichter die Back-End-Geräte (Magnetplatten) in Fibre Channel-Technologie verfügbar werden, umso eher wird sich wohl das Fibre Channel Back-End bei beiden Massenspeicherherstellern durchsetzen.

SCSI Back-End-Konfiguration Für die SCSI Back-End-Konfiguration soll zunächst nochmals an die komplette Architekur eines hochverfügbaren Storage Arrays erinnert werden.

ESCON

SCSI

FIBRE

FIBRE

Abbildung 4.16: Architektur hochverfügbarer Storage Arrays mit SCSI-Back-End


Cache

Bottom-Low

DD

DD

DD

DD

Wie in der Darstellung der Front-End-Seite der Storage Arrays immer wieder aufgezeigt, werden die Channel Directors des Front-Ends über den Cache an zwei interne Systembusse angeschlossen. Die Kombination ist stets Top-High/Bottom-Low oder Bottom-High/Top-Low. Sollen nun von einem Server, der über einen Channel Director mit dem Storage Array verbunden ist, Magnetplatten »gesehen« werden, so müssen diese von einem Disk Director (DD) kontrolliert werden, der mit denselben internen System-

171


bussen des Storage Arrays verbunden ist. So können die Hosts, die über den SCSI Channel Director an das Storage Array angeschlossen sind, sämtliche Magnetplatten »sehen«, deren Disk Directors an die Bottom-High/Top-LowSystembusse angeschlossen sind – in Abbildung 4.16 also die Magnetplatten des zweiten Disk Directors von links und die des äußersten rechten Disk Directors. Die Disk Directors besitzen als SCSI-Controller vier Ports, über die je Port bis zu acht physikalische Magnetplatten angeschlossen werden können. Dies sind klassische Standard-SCSI-Platten von 18 GB bis 182 GB Kapazität je Platte. Bei Konfigurationen von bis zu acht Disk Directors je Storage Array können solche Storage Arrays bis zu 256 physikalische Magnetplatten mit einer Gesamtkapazität von mehreren TeraByte aufnehmen. Können mehr als acht Disk Directors für das Storage Array konfiguriert werden, steigt entsprechend die Anzahl zu verbauender Magnetplatten und die Gesamtkapazität des Storage Arrays an. Geht man von der Verwendung von Ultra Wide Differential Disk Directors mit einer Übertragungsbandbreite von 40 MB/Sek. je Port aus, so teilen sich acht physikalische Magnetplatten in diese Bandbreite. Durch einfaches Rechnen käme man schnell zu dem Schluss, dass Fibre Channel Back-Ends mit 100 MB/Sek. je Port diesen durchschnittlich 5 MB/Sek. je Magnetplatte überlegen sein müssten. Diese Einschätzung wäre jedoch etwas zu schnell getroffen. Die Bandbreite der FC-SW Back-Ends wird ebenfalls nur für eine durch den internen Switch begrenzte Anzahl von Ports erreicht. Die einzelne Magnetplatte erhält auch im FC-SW-Back-End nur selten die komplette Fibre Channel-Bandbreite. Weiter wird die benötigte Bandbreite für Disk-I/O im Wesentlichen durch das Caching-Verhalten des Storage Arrays bestimmt, Parameter, die für eine Entscheidung über den Einsatz unterschiedlicher Technologien erst noch untersucht werden müssen. Jeder SCSI Disk-Director ist über das Global Shared Memory an zwei interne Systembusse angeschlossen. Dabei ist ein solcher Back-End Director ebenso aufgebaut wie der entsprechende SCSI Front-End Channel Director. Er besteht aus zwei Prozessoren, die den Bus-Traffic und das auf Magnetplatten bezogene Cache-Management betreiben. Das De-Staging von Informationen der Magnetplatten aus dem Cache auf die Platte wird vom Disk Director durchgeführt. Jeder dieser beiden Prozessoren verfügt über vier SCSI-Ports zum Anschluss von maximal acht Magnetplatten je Port. Von diesen vier Ports werden jedoch lediglich der jeweilige C- und D-Port zum Anschluss von Platten verwendet. Die Ports A und B bleiben für Hochverfügbarkeitszwecke ungenutzt (siehe dazu den Abschnitt Hochverfügbare Dual-Initiated Disk-Adapter dieses Kapitels). Damit stehen für jeden Disk Director vier Ultra-SCSI-Ports mit jeweils 40 MB/Sek. Bandbreite zur Verfügung.

172


Globa l S ha re d Me mory

Abbildung 4.17: SCSI Disk DirectorKonfiguration

Ba ck-End To p-Low

Ca c h e S lo ts

Dis k Dire c to r

P ort A P ort B


P ort C P ort D

P ort A P ort B Tra c k Ta b le


S ta tu s u n d Ko m m u n ika Tra c k Ta b le tio n s -Ma ilb o xe s


P ort C P ort D

High Me mory DA (DiskAd a p te r)

Low Me mory Bo tto m-High

Fibre Channel-Back-End-Konfiguration Fibre Channel Back-End-Konfigurationen sind sowohl in FC-AL-Topologie, als auch in FC-SW-Topologie verfügbar. Dabei werden die FC-AL-Systeme im Wesentlichen im Low-End Storage-Umfeld eingesetzt. FC-SW Back-End Storage Arrays konkurrieren mit klassischen SCSI-Systemen um die Führung im High-End-Bereich. Beide Klassen von Storage Arrays bieten volle Fibre Channel-Architektur – sowohl für Front-End Channel Directors als auch für die Back-End Disk Directors. Die Storage Arrays mit FC-Al Back-End-Konfiguration stellen stets eine gerade Anzahl von Array-Prozessoren zum Anschluss an externe Fibre Channel Devices (Switches oder Host-Bus-Adapter) zur Verfügung. Die Prozessoren greifen auf den Cache zu, der den Array-Prozessor übergreifend spiegelt. Je Array-Prozessor steht ein Loop Channel Director zur Verfügung, der die in einer FC-AL Loop angebrachten Magnetplatten verwaltet. Diese Magnetplatten sind Dual-Ported mit den Loops der jeweiligen Loop Channel Directors verbunden. Solche Arrays mit FC-AL Back-End-Konfiguration werden entweder mit zwei FC-AL Loops mit einer jeweiligen Bandbreite von 100 MB/Sek. oder mit vier FC-AL Loops angeboten.

173

4 SAN – Hardware-Komponenten Abbildung 4.18: FC-AL Back-EndKonfiguration

Fibre Channel N-Ports

Fibre Channel N-Ports

ArrayProzessor A

ArrayProzessor B

Cache

Cache

Loop A

Loop Channel Director A

Loop B

Loop Channel Director B

Storage Arrays mit FC-SW-interner Architektur sollen später nach der Erläuterung der Hochverfügbarkeits-Aspekte der Storage Arrays dargestellt werden, da sie die Architektur-Alternative zu den im Folgenden noch zu beschreibenden Komponenten darstellen und daher zuvor die KomplettArchitektur der Storage Arrays mit SCSI-Back-End vorgestellt werden soll.

4.2.1.3

Bus- und-Cache-Konfiguration und Operationen

Klassische hochverfügbare Highend-Storage Arrays werden in zwei Architekturen angeboten: Die Dual-Bus-Architektur, bei der das globale Shared Memory das Bindeglied zwischen den Channel Directors des Storage Array Front-Ends und den Disk Directors des Storage Arrays Back-Ends darstellt. Die Disk Directors und Channel Directors werden jeweils mit beiden internen Systembussen verbunden. Sämtliche Operationen zwischen Channel Directors und Disk Directors laufen über den Cache. Der Cache ist untergliedert in die Cache-Slots, über die sämtliche I/O-Operationen laufen. Je nach Größe des Storage Arrays sind Cache-Konfigurationen von bis zu 32 GB möglich. Weiter befinden sich im Cache die Track Tables. Die Track Tables enthalten je (physikalischer) Platte die Spuren, die sich aktuell im Cache befinden. Die Cache-Slots werden je nach tatsächlicher Auslastung den einzelnen (physikalischen) Platten zugewiesen. Der Allokationsalgorithmus ist so gestaltet, dass jede (physikalische) Platte eine Min174


destanzahl von Slots im Cache reserviert hat. Je nach Auslastung der Platte und des Caches werden einer (physikalischen) Platte weitere Slots zugeteilt. Die Cache-Zuordnung für die (physikalischen) Platten soll später in diesem Kapitel ausführlich erläutert werden. Die Status- und KommunikationsMailboxen werden für die Kommunikation zwischen Disk Director und Channel Director verwendet. Front-End

Globa l S ha re d Me mory Y-Bu s

Ho s t A

Ba ck-End

Ca c h e S lo ts Dis k Dire c to r


P ort A

Abbildung 4.19: Dual Bus Storage Array-Konfiguration

P ort B

P roze s s or B 68060-75MHz

P roze s s or B 68060-75MHz

P ort C P ort D

P ort A P ort B Tra c k Ta b le P roze s s or A 68060-75MHz

S ta tu s und Ko m m u n ika tio n s- Ma ilb o xe s

P roze s s or A 68060-75MHz


P ort C P ort D

Ho s t B

DA (Disk-Adapter) X-Bu s

Exkurs: Bei der Bezeichnung der Platten wurde das »physikalisch« beständig in Klammern gesetzt. Dies geschieht deshalb, weil die Zuordnung tatsächlich über »Devices« erfolgt. Diese Devices sind gleich große Teile oder Splits einer physikalischen Platte. Das Splitting physikalischer Platten in Devices wird im Folgenden noch näher erläutert. Im weiteren Verlauf des Buches wird jedoch stets von Devices gesprochen. Werden tatsächlich physikalische Platten referenziert, so wird darauf explizit hingewiesen. Die Quad Bus Storage Array-Architektur unterscheidet sich von der Dual Bus-Architektur im Wesentlichen durch die Aufsplittung des Cache in zwei Memory-Bereiche – Low Memory und High Memory. High Memory wird adressiert durch die beiden Busse Bottom-High und Top-High, LowMemory wird über die beiden Busse Bottom-Low und Top-Low erreicht. Die Disk Directors und Channel Directors werden somit stets an zwei der vier Busse angeschlossen – entweder an Top-High/Bottom-Low oder an BottomHigh/Top-Low. Dadurch ist gewährleistet, dass jeder Disk Director und jeder Channel Director den kompletten Cache adressieren kann. Funktional entspricht der Aufbau des Cache dem in der Dual Bus-Konfiguration. 175

4 SAN – Hardware-Komponenten Abbildung 4.20: Quad Bus Storage Array-Konfiguration

Front-End


Ba ck-End To p-Low


Dis k Dire c to r


P ort A P ort B



P ort C P ort D

P ort A P ort B Tra c k Ta b le



S ta tu s u n d Ko m m u n ika Tra c k Ta b le tio n s - Ma ilb o xe s


P ort C P ort D

High Me mory

Ho s t B

DA (Disk-Adapter) Low Me mory Bo tto m-Low

Abbildung 4.21: Read Operation Cache Hit

Front-End

Bo tto m-High


Ba ck-End To p-Low


Dis k Dire c to r


P ort A P ort B

4 1



2

P ort C P ort D

3 P ort A P ort B Tra c k Ta b le P roze s s or A P owe rP C750 266 MHz




P ort C P ort D

High Me mory

Ho s t B


176

Bo tto m-High


Im Folgenden soll die zentrale Funktion des Global Shared Memory anhand der klassischen I/O-Operationen erläutert werden. Als erste Operation soll ein Read-I/O-Request aus dem Cache des Storage Arrays dargestellt werden. 왘 Host A schickt über seinen Host-Kanal an den Channel Director (System-

adapter-Prozessor B) einen Read-I/O-Request (1). 왘 Prozessor A des Channel Directors sieht über den Top-High-Systembus

in den Track Tables des High Memory nach, ob die Spur für den I/ORequest bereits im Cache ist (2). 왘 Im Falle der Cache Hit Read-Operation wird die Cache-Slot-Adresse die-

ser Spur an den Channel Director übergeben (3). 왘 Der Channel Director befriedigt den I/O-Request direkt aus dem Cache (4).

Bei einem Read-I/O-Request, bei dem sich die angeforderten Tracks nicht im Cache befinden, ist das Vorgehen wie folgt: 왘 Host A schickt über seinen Host-Kanal an den Channel Director (System-

adapter-Prozessor B) einen Read-I/O-Request (1). 왘 Der Prozessor A des Channel Directors sieht über den Top-High System-

bus in den Track Tables des High Memory nach, ob die Spur, die der I/ORequest benötigt, bereits im Cache ist (2). Front-End


Abbildung 4.22: Read Operation Cache Miss

Back-End To p-Low


Dis k Dire c to r


P ort A P ort B

6 1



2

P ort C P ort D

4

P ort A P ort B


3

Tra c k Ta b le




P ort C

5

P ort D

High Me mory

Ho s t B


Bo tto m-High

177

4 SAN – Hardware-Komponenten 왘 Die Spuren, die der Read-I/O-Request benötigt, befinden sich nicht im

Cache. Der Channel Director stellt in die Status- und KommunikationsMailbox des Disk Directors, der das für den I/O-Request relevante Device administriert, im High Memory einen I/O-Request (3) (hier Prozessor A des Disk Directors, das relevante Device ist das erste Device an Port A des Prozessors A). 왘 Über den Bottom-High-Systembus pollt der Disk-Adapter (Prozessor A)

beständig seine Status- und Kommunikations-Mailbox. Dabei findet er den I/O-Request des Channel Directors und stellt die angeforderten Spuren in den Cache (4). 왘 Nun schreibt er über den Bottom-High-Systembus in die Status- und

Kommunikations-Mailbox des Channel Directors die Slot-Adresse und die I/O-ID, die der Read-I/O Request (5) benötigt. 왘 Der Channel Director pollt seine Status- und Kommunikations-Mailbox

beständig, findet die Slot-Adresse für seinen I/O-Request und gibt dem Request von dieser Adresse (6) aus, was er braucht. Die nächste Operation soll eine Write-Operation mit einem Cache-Hit sein. Hierbei handelt es sich um eine Operation, die nur von hochverfügbaren Storage Arrays unterstützt werden kann. Ein Write-I/O-Request wird beim initiierenden Host bereits als completed gemeldet, wenn er in einem CacheSlot platziert wurde, nicht erst dann, wenn die geschriebenen Daten auf das Device geschrieben wurden. Abbildung 4.23: Write Operation Cache Hit

Front-End


Ba ck-End To p-Low


Dis k Dire c to r


P ort A P ort B

3 1



4

2

P ort C P ort D


Tra c k Ta b le




P ort C P ort D

Ho s t B

High Me mory

DA (Disk-Adapter)


178

Bo tto m-High

Hochverfügbare Speichersysteme 왘 Host A schickt einen Write-I/O-Request über seinen Host-Channel an

seinen Channel Director am Storage Array (1). 왘 Der Channel Director überprüft, ob ein Cache-Slot für das Device frei ist,

für das der Write-I/O-Request bestimmt ist. Dies ist der Fall – der Write wird im Cache-Slot platziert (2). 왘 Der Channel Director meldet über den Host-Kanal an Host A, dass sein

Write Request befriedigt wurde (I/O complete) (3). Diese I/O completeMeldung erfolgt, obwohl die geschriebenen Daten erst im Cache platziert und noch nicht auf Disk geschrieben wurden. 왘 Der Disk Director schreibt sämtliche Cache-Slots, die I/Os seiner Devices

enthalten, bei einem zyklischen Schreibvorgang oder einem erzwungenen Schreibvorgang (Forced Destage) auf die Devices (4). Dieses Rückschreiben des Caches kann nach einem signifikanten Zeitraum auf die I/Ocomplete-Meldung an den initiierenden Host erfolgen (4). Wie bereits oben erwähnt, kann eine solche Fast Write-Funktionalität, die die Performance schreibender Plattenzugriffe signifikant verbessert und den einzelnen Disk Director als Performance-Flaschenhals eliminiert, nur von hochverfügbaren Storage Arrays geleistet werden. Das Storage Array muss sicherstellen, dass kein I/O verloren geht, der im Cache platziert wurde, als completed an die Hostapplikation gemeldet wurde, aber tatsächlich noch nicht auf dem physikalischen Speichermedium steht. Dies ist nur dadurch zu erreichen, dass der komplette Cache im Falle eines Stromausfalls oder eines Defekts des Storage Arrays auf die physikalischen Platten garantiert zurückgeschrieben wird. Dies wird dadurch erreicht, dass neben den bekannten Redundanzen ein ausreichend dimensionierter Batteriepuffer innerhalb des Storage Arrays vorgehalten wird, der ein sauberes Herunterfahren des kompletten Arrays im Fehlerfall garantiert. Bei Totalausfall des kompletten Arrays muss in wirklich hochverfügbaren SAN-Umgebungen sichergestellt sein, dass diese Daten auf einem Remote Storage Array verfügbar sind, auf welches im Fall des Ausfalls des primären Systems geschwenkt wird. Für das Fast Write existieren folgende Einschränkungen: 왘 Die Cache-Ressourcen sind begrenzt. Selbst bei einer Ausstattung des Sto-

rage Arrays mit 32 GB Cache können nicht sämtliche schreibenden I/Os im Cache gehalten werden. Ein Algorithmus zum Rückschreiben des Caches auf Magnetplatte muss implementiert sein. 왘 Diese Cache-Algorithmen optimieren die Cache-Ausnutzung »fair« für

sämtliche Volumes (Devices) aller Disk Directors. 왘 »Fair« bedeutet dabei, dass die Cache-Verteilung basierend auf der

aktuellen Auslastung angepasst werden muss. 왘 Je nach Konfiguration des Storage Arrays hat jedes Device eine minimale

und eine maximale Anzahl von Cache-Slots für Writes zur Verfügung. Eine

179

4 SAN – Hardware-Komponenten Abbildung 4.24: Write Operation Delayed Write

Front-End


Ba ck-End To p-Low


Dis k Dire c to r


6 1


P ort A P ort B

5


3

2

P ort C P ort D


Tra c k Ta b le



P ort D

4 Ho s t B


P ort C

High Me mory

DA (Disk-Adapter)


Bo tto m-High

Write Pending-Grenze stellt die maximale Anzahl von gefüllten CacheSlots eines Devices dar. Wird die Grenze von Write Pending erreicht, kommt es zu einem »Delayed Write«. 왘 Der Delayed Write stellt dem entsprechenden Disk Director einen Re-

quest in seine Status- und Kommunikations-Mailbox ein, der ihn zwingt, die Cache-Slots auf »seine« Devices zurückzuschreiben. 왘 Ein Delayed Write erfolgt auf Device Ebene (wird vom Storage Array in

aller Regel dynamisch ermittelt) oder auf Storage Array-System-Ebene (sobald ein bestimmter Prozentsatz sämtlicher Cache-Slots Write Pendings enthält). 왘 Der Disk Director beginnt dann mit einem Forced Destage, um den Über-

lauf des Caches zu verhindern. In Abbildung 4.24 wird ein Delayed Write für die Situation dargestellt, dass kein freier Cache-Slot für den Write-I/O-Request des Hosts mehr verfügbar ist. 왘 Host A schickt einenWrite-I/O-Request über seinen Host-Channel an sei-

nen Channel Director am Storage Array (1). 왘 Der Channel Director überprüft, ob ein Cache-Slot für das Device frei ist,

für das der Write-I/O-Request bestimmt ist (2).

180

Hochverfügbare Speichersysteme 왘 Dies ist nicht der Fall, daher wird dem entsprechenden Disk Director ein

Request in seine Status- und Kommunikations-Mailbox eingestellt, der ihn zwingt, die Cache-Slots auf »seine« Devices zurückzuschreiben. Der Disk Director führt einen Forced Destage durch (3). 왘 Der Disk Director stellt dem Channel Director eine Destage-Notification

in dessen Status- und Kommunikations-Mailbox, in der die Slots bezeichnet werden, die beim Forced Destage zurück auf Platte geschrieben wurden (4). 왘 Der Channel Director stellt den Write-I/O in einen der nun freien Slots (5)

und sendet dem Host sein I/O complete (6). Die Beschreibung der I/O-Operationen sollte die zentrale Bedeutung des Caches verdeutlicht haben. 왘 Sämtliche Read/Write-Operationen werden gecached. 왘 Das Global Shared Memory ist für alle Directors verfügbar. 왘 Der Cache wird in Track-»Slots« allokiert. Diese Track-Slots sind so di-

mensioniert, dass sie eine Spur sämtlicher gängiger SCSI-Magnetplatten aufnehmen können (in der Regel 32 Kbytes). 왘 Die Track Tables benötigen ebenfalls globales Shared Memory. Je nach

Größe der Magnetplatten und Anzahl der Devices im Storage Array sind die Cache-Anforderungen für Track Tables ca.: 18GB HDA – 10-16 MB 36GB HDA – 18-28 MB 50GB HDA – 28-38 MB 왘 Die Hauptspeicheranforderungen für Kommunikations- und Status-

Mailboxes betragen ca. 64-128 MB. 왘 Die Cache-Algorithmen sind adaptiv je Device. In aller Regel hält ein LRU-

Algorithmus (least recently used) häufig referenzierte Daten im Cache. 왘 Sequentielle Reads können automatisch erkannt und in ein Prefetch Win-

dow eingelesen werden. Dieses Prefetch Window liest dann je I/O-Request nicht mehr nur eine Spur, sondern mehrere Spuren hintereinander.

4.2.1.4

Konfiguration für Distanz-Topologien

Als zu implementierendes Beispiel einer hochverfügbaren Distanz-Topologie soll auf die hochverfügbare SAN-Topologie vom Ende des Kapitels 3 zurückgegriffen werden. In dieser SAN-Topologie werden (sämtliche) Devices des lokalen Storage Arrays zur Absicherung von Ausfällen – die beide Server, den lokalen Switch, beide Fibre Channel Directors, sämtliche Devices oder gar das komplette lokale Rechenzentrum betreffen können – auf entsprechende SpiegelDevices des Remote Storage Arrays gespiegelt. Diese Spiegelung wird klassisch vom Front-End und vom Cache der beteiligten Storage Arrays gesteuert. Dabei können auf der Front-End-Seite zwei Arten von Remote Link Directors eingesetzt werden:

181

4 SAN – Hardware-Komponenten 왘 ESCON RLDs (Remote Link Director), die das ESCON-Protokoll ver-

wenden 왘 Fibre Channel RLDs, die bidirektionales Fibre Channel verwenden.

Abbildung 4.25: Hochverfügbare SAN-Topologie

F C H B A


F C H B A

AIX-Server

F C H B A

F A

F A

Local

Remote

Storage

Storage

Array

Array

F A

F A

F C H B A


F C H B A


Die Funktionalität der Remote Link Directors und das Cache-to-Cache Mirroring in der Distanz-Topologie soll zunächst anhand der ESCON RLDs erläutert werden. Danach sollen die wesentlichen Unterschiede von Fibre Channel RLDs aufgezeigt werden. 왘 Die RLDs arbeiten nach dem ESCON-Protokoll und führen den Daten-

transfer vom lokalen zum entfernten Storage Array durch. 왘 Jeder RLD besitzt zwei Prozessoren, die Remote Link-Adapter. Jeder der

beiden Adapter besitzt zwei ESCON-Ports zum Anschluss an einen Remote Link Adapter über Glasfaserkabel oder T1/T3-Telefon-Protokoll (je nach Entfernung). 왘 Die Remote Link-Adapter (RLA) sind entweder als »RA1« oder »RA2«

konfiguriert. Dabei emulieren RLAs der Konfiguration RA1 einen ESCON-Host, als RA2 konfigurierte RLAs emulieren eine ESCON-Peripherie. 왘 In hochverfügbaren Storage Arrays werden die RLDs zur Gewährleis-

tung von Redundanz paarweise konfiguriert. 왘 Die RLAs können zu einer RA-Gruppe zusammengefasst sein.

182

Hochverfügbare Speichersysteme Abbildung 4.26: ESCON RLDKonfiguration (1)

Uni-Directional DA 1 S1 Dev DA 1

C A C H E

DD

2

RA

RA 1

2

RLD

C A C H E

RLD

DA 1 S2 Dev DA 1

DD

Bi-Directional

S2 Dev

DA 1

S1

DA

Dev

RA

RA 1

1

DD

C A C H E

RA 1

RA 1

RLD

S1

RA 2

RA 2

RLD

C A C H E

DA 1

Dev

DA

S2

1

Dev

DD

Aus diesen Eigenschaften der Remote Link Directors folgen die vier Konfigurationen für Distanz-Topologien: 왘 Die unidirektionale Konfiguration besteht aus reinen RA-Gruppen, bei

denen auf dem Storage Array, das die Original-Platten (S1) enthält, sämtliche RLDs als RA1-Devices konfiguriert sind. Auf dem Ziel-Storage Array, das die gespiegelten Platten enthält (S2), sind die RLDs als RA2Devices konfiguriert. 왘 Die bidirektionale Konfiguration ist seitens der ESCON-Konfiguration

identisch mit der unidirektionalen. Es werden jedoch auf beiden Storage Arrays die Platten des jeweils anderen gespiegelt. Dadurch wird der Remote Link in beide Richtungen genutzt. 왘 In der dualen Konfiguration werden gemischte RA-Gruppen über

mehrere RLDs gebildet, sodass zwischen den beiden Storage Arrays unidirektionale Verbindungen in beide Richtungen implementiert werden. 왘 Die Multiple-Source-to-Single-Target-Konfiguration stellt quasi eine Sto-

rage-Konsolidierung auf der Remote-Seite dar. Von mehreren RA1-Links auf unterschiedlichen Quell-Storage Arrays wird auf mehrere RA2-RLDs auf einem Remote-Storage Array gespiegelt. Ein klassisches Einsatzszenario für eine solche Konfiguration stellt ein Disaster-Recovery-Rechenzentrum dar, in dem sämtliche Informationen verteilter Rechenzentren vorgehalten werden, um im Falle einer Katastrophe von hier aus die Produktion des Unternehmens weiterlaufen zu lassen.

183

4 SAN – Hardware-Komponenten Abbildung 4.27: ESCON RLDKonfiguration (2)

S1 Dev

DA 1

DA S2 Dev

1

DA 1

DD DA 1 S1 Dev

C A C H E

DD

DA 1 S1 Dev

RA 1

DA 1

DD

RA 1

RLD

C A C H E

RA 2 RA 2

RLD

RA 2

RA 1

RA 2

RA 1

RLD C A C H E

Dual Configuration

RA 1 RA 1

RLD

RA 1

RLD

Dev

S1 Dev

RLD Multiple-Source-to-Single-Target

RA 2 RA 2

RLD RA 1

S2

C A C H E

RA 2 RA 2

RLD

C A C H E

DA DA 1 1

S1

DA DA 1 1

Dev

S2

DD DD

Wie erfolgt die Spiegelung der Devices in der ESCON-Konfiguration? Dazu soll nochmals ein Blick auf die Front-End- und die Back-End-Konfigurationen der beiden beteiligten Storage Arrays geworfen werden: Beide Storage Arrays werden identisch aufgebaut. Jedes Array besitzt zwei SCSI-Channel Directors, an die die Hosts angeschlossen sind. Weiter besitzt jedes Array zwei ESCON-Remote Link Directors mit jeweils vier Ports. In einer praktischen Gruppierung würden die vier ESCON-Links der beiden Directors zu je einer Gruppe zusammengefügt. Aus Vereinfachungsgründen denken wir uns eine unidirektionale Konfiguration (Pfeil). Dadurch wären sämtliche Devices des lokalen Storage Arrays S1-Devices, also Originale, sämtliche Devices des Remote Storage Arrays wären S2-Devices, also remote Spiegel der S1-Devices des lokalen Storage Arrays. Die Devices beider Storage Arrays werden über jeweils vier SCSI-Disk Directors an die internen Systembusse der Storage Arrays angeschlossen. Es fällt auf, dass die beiden ESCON RLDs ebenfalls, wie auch die Channel Directors und Disk Directors, an sämtliche Systembusse angeschlossen werden und daher ebenfalls den kompletten Cache des jeweiligen Storage Arrays sehen. Wie bereits oben erwähnt, ist der Cache in Slot-Sets für die einzelnen Devices des Back-Ends aufgeteilt. Platziert nun ein Host über einen der Channel Directors einen Write I/O in einem Cache-Slot des lokalen Storage Arrays, so wird über den Delayed Write von dem entsprechenden Disk Director dieser Slot auf das Ziel-S1-Device geschrieben. Der ESCON RLD

184


hat jedoch Zugriff auf denselben Cache und dieselben Cache-Slots. Mit jedem neuen I/O in einem Cache-Slot überträgt der ESCON RLD über einen seiner RA-Ports diesen I/O auf sein Pendant auf dem Remote Storage Array. Lokales Storage Array

SCSI


ESCON RLD

SCSI

ESCON RLD

ESCON RLD

ESCON RLD

SCSI

Abbildung 4.28: ESCON Cachebasierte Remote Spiegelung

SCSI


Cache

Cache

Bottom-Low

DD

DD

DD

DD

DD

DD

DD

DD

Was bedeutet hier »sein Pendant«? In einer hochverfügbaren SAN-Umgebung – wie in Abbildung 4.28 konfiguriert – sind die jeweiligen Front-End und Back-End Directors des Remote Storage Arrays auf die gleichen internen Busse gesteckt wie im lokalen Speichersystem. Dies bedeutet, dass in Abbildung 4.28 der erste Disk Director von links auf dem remote Speichersystem die S2-Spiegel der S1-Originale des ersten Disk Directors auf dem lokalen Speichersystem verwaltet, der zweite remote Disk Director die S2Spiegel der S1-Originale des zweiten lokalen Disk Directors usw. Dies bedeutet auch, dass der erste ESCON RLD von links auf dem lokalen Storage Array auf denselben internen Bussen sitzt wie der erste ESCON RLD von links auf dem Remote Storage Array usw., er ist also dessen »Pendant«. Diese Konfiguration ist jedoch nahezu beliebig zu tauschen. Wichtig ist, dass stets sämtliche Devices, die remote gespiegelt werden sollen, auch von dem lokalen ESCON RLD gesehen werden müssen. Zurück zum Spiegeln der Devices: Jeder I/O auf das Original-S1 Device – bezeichnen wir es als Standard-Device – wird über einen ESCON RLD in den Cache des Remote Storage Arrays übertragen und zwar in einen Slot des Spiegel-S2-Devices – bezeichnen wir es als Remote Mirror Device. Diese Übertragung erfolgt, sobald der ursprüngliche I/O-Request des Hosts auf der S1-Seite im Cache des Speichersystems der S1-Seite angekommen ist. Ein

185


Write-I/O-Request wird je nach Betriebsart der ESCON RLD-Spiegelung zu unterschiedlichen Zeitpunkten als »I/O complete« an den Host gemeldet. 왘 Primäre Betriebsarten

Synchronous oder synchrones Schreiben wartet bei jedem Write-I/O-Request des Hosts auf der lokalen Seite auf die Bestätigung des I/O complete auf dem Remote Storage Array. Erst wenn der auslösende I/O auch über einen RLD-Port des Remote Storage Arrays in dessen Cache platziert wurde, wird der I/O als abgeschlossen gemeldet und der lokale Host kann mit seinen Funktionen fortfahren. »Semi-synchronous« oder halbsynchrones Schreiben erlaubt einen I/O pro Device auf der S2-Seite, also auf dem Remote Storage Array. 왘 Sekundäre Betriebsarten

»Adaptive Copy« wartet nicht auf eine Bestätigung (I/O complete) der S2-Seite, sondern vertraut auf einen sicheren ESCON-Link, über den auch ausstehende Disk- I/Os zu einem späteren Zeitpunkt nachgezogen werden. Adaptive Copy lässt sich in den beiden Modi Disk Mode und Write Pending Mode betreiben. »Domino« stoppt jegliche Aktion auf der S1-Seite, sobald eine Spiegelung nicht möglich ist, also wenn ein I/O nicht im Cache des Remote Systems platziert werden kann. Die Betriebsarten sind für jedes Device einstellbar. Primäre Betriebsarten können mit sekundären Betriebsarten gemischt werden. Synchronous/Domino ist die sicherste Betriebsart. Hochverfügbare SANs operieren im Betrieb grundsätzlich nach diesem Modus. Kommt es zu einem Fehler, muss der lokale Host zur Fortführung seiner Produktion auf das Remote Storage Array umschalten, bis ein Fehler des Links, der die Spiegelung verhindert hat, beseitigt ist und wieder zurückgeschwenkt werden kann. Leider unterstützen die meisten Cluster-Systeme weder hardwarenoch softwareseitig diese Betriebsart. Hier ist nur eine Kombination der primären Betriebsarten mit der sekundären Betriebsart Adpative Copy möglich. Der Disk Mode des Adaptive Copy wird gerne zur Erstsynchronisation der S2-Devices von ihren S1-Devices verwendet. Hier wird während des laufenden Betriebes auf der S1-Seite die S2-Seite über die ESCON RLDs synchronisiert. Dabei wird nur synchronisiert, wenn der Produktionsbetrieb die Kanalbandbreiten des lokalen Storage Arrays nicht komplett benötigt, die Synchronisation läuft also verzögert und der Produktion nachgeordnet. Schlägt bei der Synchronisation irgendetwas fehl, so wird die Synchronisation nochmals gestartet. Der Zustand des Gesamtsystems ist hier kein anderer, als vor dem Start des Erstsynchronisationsversuchs.

186


Write Pending ist der Modus der sekundären Betriebsart Adaptive Copy, der nach erfolgter Synchronisation der S2-Seite für den beständigen Betrieb der Remote-Absicherung der lokalen Devices verwendet wird. Dieser ist für den Zweck der Hochverfügbarkeit nicht unbedingt sicher. Hier müssen in Cluster-Umgebungen aufwändige Cluster-Software-Services verwendet werden, um sicherzustellen, dass bei einem Schwenk des Clusters auf die S2-Seite nicht mit inkonsistenten Datenbeständen gearbeitet wird. Allgemein ist bzgl. der Realisierung einer hochverfügbaren Distanz-Topologie mithilfe des ESCON-Protokolls zu bemerken, dass lediglich die schreibenden oder verändernden I/Os über die ESCON-Links auf das Remote Storage Array transferiert werden. Je nach Implementierung kann der ESCONLink auch dafür verwendet werden, die lesenden I/Os parallel von der lokalen und der remote Umgebung zu befriedigen. Dazu müssen für den lesenden Host die Devices auf dem Remote Storage Array zumindest den Zustand Write Disabled oder Read Enabled besitzen. Dies ist für Hostsysteme in Client-Server-Systemumgebungen stets der Fall – in MainframeUmgebungen ist für Hosts der S1-Seite die S2-Seite jedoch nicht verfügbar, d.h. der Status der S2-Devices des Remote Storage Arrays ist Not Ready To Host. In einer klassischen Mainframe-Umgebung kann damit das parallele Lesen von S1-Storage Arrays und S2-Storage Arrays nicht genutzt werden. Bei der Betrachtung von Abbildung 4.28 wird schnell deutlich, wo in einer solchen Distanz-Topologie bei Verwendung des ESCON-Protokollsets Engpässe und Flaschenhälse auftreten können. Lokales Storage Array

Remote Storage Array Switch

SCSI

FCRLD

SCSI

FCRLD

FCRLD

FCRLD

SCSI

Abbildung 4.29: Auf FC-SW-Cache basierte remote Spiegelung

SCSI


Cache

Cache

Bottom-Low

DD

DD

DD

DD

DD

DD

DD

DD

187


Allein bei einer Front-End-Konfiguration wie im ESCON-Beispiel (vgl. Abb. 4.28) können die zwei SCSI-Channel Directors eine I/O-Bandbreite von jeweils insgesamt 320 MB/Sek. liefern (2 x 4 Ports x 40 MB/Sek.). Diese Bandbreite kann von den jeweils vier Disk Directors problemlos erbracht werden. Die je zwei ESCON Remote Link Directors besitzen jedoch eine maximale Kapazität von 136 MB/Sek. (2 x 4 Ports x 17 MB/Sek.). Hier gilt es, genau zu ermitteln, welcher I/O-Anteil schreibender und damit über die RLDs zu replizierender I/O ist um die benötigte Anzahl von ESCON RLDs in die Arrays hineinzukonfigurieren, damit z.B. bei einer Synchronous/Domino-Betriebsart nicht die RLD-Bandbreite die limitierende Größe des Gesamtsystems darstellt. Dieser Aspekt wird umso bedeutender, wenn man bedenkt, dass selbst die größten derzeit verfügbaren Storage Arrays maximal 16 Slots (Steckplätze) für Directors zur Verfügung haben. Hier ist die ideale Balance zwischen Channel Directors, Disk Directors und Remote Link Directors zu finden – kein triviales Problem. Würden statt der ESCON RLDs Fibre Channel Directors verwendet, so stünde bei einer ansonsten gleichen Konfiguration eine Bandbreite von bidirektional 400 MB/Sek. zur Verfügung (2 FC-RLDs x 2 Ports x 100 MB/Sek.). Die obige Konfiguration mit den SCSI-Channel Directors könnte – selbst bei reinen Write-I/O-Situationen – den remote Link nicht zum Engpassfaktor werden lassen. Selbst in einer reinen Fibre Channel-Umgebung mit ebenfalls Fibre Channel Directors wäre das Bandbreitenverhältnis von Host-I/O zu Cache-to-Cache Remote Link I/O stets 1:1, es sei denn, man würde die Storage Arrays so auskonfigurieren, dass eine ausreichende Anzahl von FCRLDs nicht vorhanden wäre.

4.2.2

Eigenschaften und Komponenten hochverfügbarer Speichersysteme

Wesentliches Merkmal der hochverfügbaren Speichersysteme ist die Redundanz der wesentlichen Architekturkomponenten. Welche Architekturkomponenten wie redundant gehalten werden und welche weiter reichenden Ausfall-Schutz-Mechanismen in Storage Arrays implementiert werden, ist Inhalt dieses Abschnittes.

4.2.2.1

Redundanz von Architekturkomponenten

Die Redundanz aller Hauptkomponenten eines Storage Arrays gewährleistet die Aufrechterhaltung der kompletten Produktion bei Ausfall nur einer Komponente. Die Hauptkomponenten eines solchen Speichersystems sind: Channel Directors: Jeder Channel Director besteht aus zwei Channel-Adaptern (Systemadapter des Storage Arrays zum Host-Bus-Adapter). Diese On-Board-Redundanz bietet jedoch in der Regel keinen gesteigerten Ausfallschutz, es sei denn, über Dynamic Multipathing-Mechanismen werden nicht alle Ports zum

188


Anschluss eines Hosts verwendet. In einer solchen-Umgebung werden sowohl auf HBA-Seite als auch auf der Seite des Channel Directors zwei Ports für die beiden unterschiedlichen Zugriffspfade verwendet. Zusätzlich zu dieser On-Board-Redundanz können jedoch bei Herstellern hochverfügbarer Storage Arrays die entsprechenden Channel Directors nur als Paare erworben werden, sodass zumindest eine komplette Redundanz mit einem Channel Director für die primären Zugriffspfade, mit einem zweiten für die sekundären Zugriffspfade, realisiert werden kann. Disk Director: Jeder Disk Director besteht ebenfalls aus zwei Disk-Adaptern. In der SCSIBack-End-Konfiguration besitzt jeder Disk-Adapter vier Ports zum Anschluss von je maximal acht physikalischen Magnetplatten. Redundanz zum Schutz vor dem Komplettverlust des Disk Directors wird hier ebenfalls durch den »Zwang zur Pärchenbildung« gewährleistet. Zusätzlich können weitere Ausfallschutzmechanismen implementiert werden, wie z.B. ein Dual-Initiated Disk-Adapter, wie er gleich näher erläutert wird. Cache Memory Boards: Cache Memory Boards gibt esebenfalls nur als Paare. Jedes dieser Boards sollte aus zwei oder vier Regionen bestehen, einer High-Memory-Region und einer Low-Memory-Region oder einer Top-High-, Bottom-High-/TopLow-, Bottom-Low-Memory-Region, abhängig davon, ob das Storage Array eine Dual-Bus- oder eine Quad-Bus-Architektur besitzt. Fällt ein komplettes Memory Board aus, so ist für sämtliche interne Kanäle (Systembusse) noch das zweite Memory Board verfügbar. Plattenlaufwerke: Plattenlaufwerke können auf vielfache Weise abgesichert werden (vgl. unten Disk Protection). Als einfachste Form der Absicherung kann ein lokales Spiegellaufwerk angesehen werden, das im eigenen Storage Array einen 1:1Spiegel eines Original-Plattenlaufwerkes implementiert. Power Module: Bei der Redundanz der Systemkomponenten kann auf eine doppelt vorhandene Stromversorgung nicht verzichtet werden. Kein hochverfügbares Storage Array existiert ohne redundante Power-Supplies. Batterien: Die Bedeutung der Batterien für die Verfügbarkeit des Systems tritt deutlich zu Tage, wenn man sich an die Funktionalität des Fast Write erinnert. Dieses meldet das I/O complete für einen Write-I/O bereits an den initiierenden Host, sobald der I/O in einem Cache-Slot platziert wurde. Das BatterieBackup muss also so konfiguriert sein, dass es das ordentliche Herausschreiben des kompletten Caches des Storage Arrays (bis zu 32 GB) auf eine Magnetplatte gewährleistet. So verwundert es nicht, dass auch das Battery-Pack eines Storage Arrays redundant vorhanden ist.

189


System Bus: Aus Redundanz-Gründen existieren Dual-Bus und Quad-Bus Storage ArrayArchitekturen. Storage Arrays mit nur einem internen Systembus können nicht hochverfügbar sein. In der Dual-Bus-Architektur sieht jeder Bus beide Cache Memory-Regionen. Jeder Director ist an beide Systembusse angeschlossen, sodass bei Ausfall eines Busses über den zweiten noch immer das komplette Memory sichtbar und jedes Device und jeder Host-Kanal adressiert werden kann. In der Quad-Bus-Architektur ist jeder Director so mit den Bussen verbunden, dass er High-Memory und Low-Memory sehen kann. Fällt einer der Busse aus, so wird durch Dual-Pathing und Dual-Initiated Disk-Adapter der Zugriff auf sämtliche Devices und das komplette Memory gewährleistet.

4.2.2.2

Hochverfügbare Cache-Konfiguration

Zum Zeitpunkt des Erscheinens dieses Buches ist der Cache hochverfügbarer Storage Arrays auf maximal 32 GB beschränkt. Diese sind lediglich für Quad-Bus-Architekturen verfügbar. Cache Boards gibt es nur paarweise. Dabei gelten folgende Konfigurations-Möglichkeiten: 왘 Maximal vier Memory Boards (minimal zwei) 왘 Jedes Board ist mit zwei Systembussen verbunden: Top-High/Bottom-

High oder Top-Low/Bottom-Low in der Quad-Bus-Architektur, oder Xund Y-Bus in Systemen mit Dual-Bus-Architektur. 왘 Memory Boards werden in folgender Paar-Stückelung installiert:

2 Boards à 512 MB (nur Dual-Bus-Architektur) 2 Boards à 1.024 MB 2 Boards à 2.048 MB 2 Boards à 4.096 MB 2 Boards à 8.192 MB (nur Quad-Bus-Architektur) 왘 Jedes Memory-Board hat zwei/vier Regionen, die über die Busse erreich-

bar sind. Je nach Hersteller wird der Cache systemintern gespiegelt, sodass bei Ausfall eines Memory Boards – wie bei gespiegelten Magnetplatten – sein Spiegel-Board den Inhalt des Original-Boards besitzt und die Produktion nahezu unterbrechungsfrei weiterläuft. Oder es wird mit folgenden Mechanismen eine auch nahezu unterbrechungsfreie Verfügbarkeit des Komplettsystems gewährleistet: 왘 High Density FRUs (Fencing Logic Redundant Units) mit gesteigerter

Zuverlässigkeit, geringerer Servicenotwendigkeit und Reduktion von Interconnections zwischen Memory-Regionen 왘 Distributed Design – Sämtliche Directors teilen sich die Cacheverwal-

tung 왘 Dual Memory Bus Design

190

Hochverfügbare Speichersysteme 왘 Daten, die in den Cache geschrieben werden, werden rescanned, um ihre

Korrektheit zu verifizieren, bevor der I/O complete an den initiierenden Host gesendet wird. 왘 Error Detection- und Correction-Mechanismen ermöglichen Single Error

Correction und Double Error Detection 왘 Aktive Selbstdiagnose-Algorithmen bieten eine Früherkennung poten-

tiell ausfallender Module. Über eine Fencing-Logik werden fehlerhafte Komponenten identifiziert und das komplette Board für die folgenden I/Os ausgeschaltet, sodass eine scheduled (geplante) unterbrechungsfreie Reparatur durch Austausch des defekten Boards vorgenommen werden kann. 왘 Integriertes redundantes Batteriesystem, das ein komplettes Rückschrei-

ben des Caches bei Power-Fehlern garantiert.

4.2.2.3

Hochverfügbare Dual-Initiated Disk Directors

In Storage Arrays mit SCSI-Back-End besitzt jeder Disk Director zwei unabhängige Disk-Adapter mit jeweils vier SCSI (UWD)-Ports. Ba ck Ada pte rKa rte P ort A

Midpla ne

DA 1

Dis k Dire c to r P roze s s or B P owe rP C750 266 MHz

P ort B

P ort A

Abbildung 4.30: Dual-Initiator Disk Directors

P ort B P ort C P ort D


P ort C

P ort A P ort B


P ort D

P ort C P ort D

DA 2

P ort A

Dis k Dire c to r P roze s s or B P owe rP C750 266 MHz

P ort B

P ort A P ort B P ort C P ort D


P ort C

P ort A P ort B


P ort C

P ort D

Midpla ne

P ort D

Statt nun sämtliche verfügbaren Ports zur Bestückung mit SCSI-Magnetplatten zu verwenden, werden aus Hochverfügbarkeitsgründen lediglich die Ports C und D mit bis zu acht Magnetplatten konfiguriert. Port A und B werden nicht genutzt, sondern elektrisch auf die Ports A und B eines DiskAdapters auf einem anderen Disk Director geschleift, der auf denselben Sys-

191


tembussen liegt. Dadurch werden bei einem Ausfall des Disk-Adapters seine Magnetplatten über die Ports A und B des anderen Disk-Adapters sichtbar und umgekehrt. Dieser Mechanismus steigert die Leistungsfähigkeit des kompletten Back-Ends, da bei Ausfall eines Ports nicht der komplette Disk Director durch seinen redundanten Partner ersetzt werden muss, sondern lediglich einer von zwei Disk-Adaptern ausfällt und durch seinen Dual Initiator Disk-Adapter ersetzt wird.

4.2.2.4

Devices und Disk Protection-Mechanismen

Nachdem nun sämtliche Front-End- und Back-End-Komponenten und der Cache des Storage Arrays erläutert wurden, soll das letzte Augenmerk auf die Magnetplatten, die Speicher Devices und deren Absicherung für Hochverfügbarkeit gelegt werden. Dabei wird zunächst darauf eingegangen, was unter »Device« verstanden werden soll.

Logical Devices versus Physical Disks Bisher wurde stets von (physikalischen) Magnetplatten mit dem »physikalisch« in Paranthese gesprochen. Tatsächlich ist es nicht die physikalische Magnetplatte, auf die sich sämtliche Operationen des Disk-I/Os auf HostSeite und im Cache des Storage Arrays beziehen. Abbildung 4.31: Logische versus physikalische Devices

HBA A

HBA B

Physical Devices System Adapter/Channel Director Cache

10 5A

20 5B

21 60

31 5C

22 5D

32 61

Logical Volumes

Disk Director/Disk-Adapter

Physical Disk

Physical Disk

Der Host erkennt über die Host-Bus-Adapter seine physikalischen Devices – bei SCSI-Konfigurationen in der Controller-Target-Disk-Slice-Mimik. Diese Physical Devices entsprechen jedoch mitnichten Physical Disks, also physi-

192


kalischen Magnetplatten, im Storage Array. Das ist deshalb so, weil die Größe physikalischer Devices des Hosts sehr stark applikationsabhängig ist und die meisten Applikationen keine Magnetplatten der Größe unterstützen, wie sie in heutigen Storage Arrays ausgeliefert werden. Daher werden – in aller Regel Microcode-gesteuert – die physikalischen Platten des Storage Arrays in Slices oder Logical Volumes gesplittet. Ein solches Logical Volume oder ein solcher Split wird vom Host über seinen Host-Bus-Adapter als Physical Device gesehen. Die physikalische Magnetplatte des Storage Arrays wird stets in n Splits unterteilt, wobei n eine Zweierpotenz darstellt. Ist ein Storage Array mit 256 physikalischen Magnetplatten in einem vierer Split bestückt, so sieht der Host 1.024 Physical Disks. Innerhalb des Storage Arrays werden die Logical Volumes in der Regel über einen HexadezimalIndex eindeutig identifiziert. Wie es applikationsseitig notwendig sein kann, die maximale Größe einer »physikalischen« Platte (innerhalb des Storage Arrays eines Logical Volumes) auf eine Größe kleiner als die tatsächliche physikalische Platte zu beschränken, kann es seitens der Applikation oder des Betriebssystems notwendig sein, mehrere physikalische Platten zu einer größeren Einheit zusammenzufassen. Dies kann auf das Betriebssystem bezogen z.B. stets dann erforderlich sein, wenn sämtliche Devices eines Storage Arrays Direct attached an einen einzigen Server angeschlossen werden, dessen Betriebssystem jedoch nur eine maximale Anzahl von n Target/LUNs unterstützt. In einer solchen Umgebung werden mehrere der oben erstellten Logical Volumes wieder zu einem größeren Device – nennen wir es ein Meta Device – zusammengefügt. In solchen Meta Devices benötigt lediglich das erste Logical Volume – der Meta Head – eine eigenständige Target/LUN. Auf sämtliche anderen Logical Volumes – die Meta Members – wird über den Meta Head zugegriffen. Nomenklatur-Vereinbarung: Für den Rest des Buches werden Logical Volumes als Devices, Meta Devices als Meta Devices und physikalische Platten als Physical Devices bezeichnet.

RAID-Level-Absicherung Die RAID-Level-Absicherung stellt eine Absicherung auf Device-Ebene dar, die – je nach Level – unterschiedliche Mechanismen zum Schutz vor Komplettverlust der Daten implementiert. Die bekanntesten RAID (Redundant Array of Inexpensive Disks)-Ebenen sind: 왘 RAID 1

lokale Spiegelung eines Devices

왘 RAID 5

Disk Striping (3) mit Parity

왘 RAID S

Disk Striping mit verteilter Parity

왘 RAID 7

Disk Striping (5) mit Parity

193

4 SAN – Hardware-Komponenten Abbildung 4.32: RAID-1-Absicherung durch lokale Spiegel

P ort C

Dis kAd a p te r


000

001

002

003

004

005

006

007

009

00A

00B

00C

00D

00E

00F

001

002

003

004

005

006

007

009

00A

00B

00C

00D

00E

P ort D

008

P ort C Dis kAd a p te r


000

P ort D

008

00F

Dabei lässt sich RAID 1 sehr einfach darstellen. Ein Device wird auf einem identischen Device innerhalb des Storage Arrays gespiegelt. Dieses SpiegelDevice (in Abbildung 4.32 dunkel) erhält die identischen Eigenschaften seines Originals, darunter auch die Adresse (dreistellige Hexadezimalzahl). Kein Server kann das Original eines Devices von seinem lokalen Spiegel unterscheiden, die Spiegel sind als solche nicht sichtbar für den Host. Kommt es jedoch zu einem Plattenfehler des Original-Devices, so wird seitens des Storage Arrays automatisch auf das Spiegel-Device umgeschaltet. Dieses wird nun allein – und daher auch ungeschützt – für die Produktion verwendet. Einen zweiten Plattenfehler auf dem Spiegel-Device kann das Storage Array mit einer reinen RAID 1-Absicherung nicht mehr ausgleichen. Daher sollte ein ausgefallenes Device unverzüglich getauscht werden. Die Spiegelung wird, sobald das getauschte Device wieder verfügbar ist, vom Storage Array automatisch synchronisiert. Spiegel-Devices können auch für Performancesteigerungen seitens der Storage Arrays genutzt werden. So werden z.B. schreibende I/Os allein auf dem Original-Device platziert und dann über Disk-Adapter und Cache auf das Spiegel-Device kopiert. Der I/O wird erst dann als »complete« an den Server gemeldet, wenn sowohl das Original-, als auch das Spiegel-Device geschrieben sind. Lesende I/Os können dagegen sowohl vom Original- als auch vom Spiegel-Device erfolgen. Dies kann zu hohen Performancegewinnen führen, wenn der Server in der Lage ist, von mehreren Devices parallel zu lesen.

194

Hochverfügbare Speichersysteme Abbildung 4.33: RAID 5-Absicherung mit Parity

P ort C

Dis kAd a p te r


000

001

002

003

004

005

006

007

009

00A

00B

00C

00D

00E

00F

011

012

013

014

015

016

017

019

01A

01B

01C

01D

01E

P ort D

008

P ort C Dis kAd a p te r P roze s s or B P owe rP C750 266 MHz

010

P ort D

018

01F

Hier wird jedoch auch schnell deutlich, wie wichtig eine durchdachte Konfiguration des Storage Arrays ist. Das Spiegel-Device sollte aus Gründen der Absicherung niemals auf der gleichen physikalischen Platte liegen wie sein Original-Device. Mit Verlust des Original-Devices ginge auch dessen Absicherung verloren. Weiter sollte jedoch der Spiegel nicht vom gleichen DiskAdapter gesteuert werden wie sein Original. Dadurch kann für das parallele Lesen die I/O-Last auch von zwei unterschiedlichen Disk-Adaptern geteilt werden, was die Parallelität des lesenden Zugriffs weiter beschleunigt. Während eine RAID 1-Absicherung stets die doppelte Anzahl von Magnetplatten erfordert, die für einen ungeschützten Betrieb notwendig wären, reduzieren RAID 5 und RAID S den Mehrbedarf auf ein Drittel des Produktionsbestandes. Bei RAID 5 werden die physikalischen Magnetplatten (graue Umrandung um Devices) »rein« gehalten. Das heißt, drei physikalische Magnetplatten enthalten die reinen Produktionsdaten. Eine vierte physikalische Magnetplatte enthält lediglich die Parity-Informationen zu den drei ProduktionsMagnetplatten. Mithilfe dieser Parity-Informationen können die Daten einer der drei Produktionsplatten bei Verlust wiederhergestellt werden. Diese Wiederherstellung ist jedoch eine Disk-Adapter-basierte Berechnung der Inhalte der verlorenen Platte aus der Parity-Platte. Das reduziert die Performanceleistung des Disk-Adapters für sämtliche Devices, die von ihm gesteuert werden. Die RAID 5-Plattenersparnis gegenüber RAID 1 wird also mit Leistungsverlusten beim Disk-Adapter erkauft.

195

4 SAN – Hardware-Komponenten Abbildung 4.34: RAID S-Absicherung mit verteilter Parity

P ort C

Dis kAd a p te r


000

001

002

003

004

005

006

007

009

00A

00B

00C

00D

00E

00F

011

012

013

014

015

016

017

019

01A

01B

01C

01D

01E

P ort D

008

P ort C Dis kAd a p te r P roze s s or B P owe rP C750 266 MHz

010

P ort D

018

01F

RAID S unterscheidet sich von RAID 5 lediglich dadurch, dass die Parity Devices über die physikalischen Platten verteilt werden. Dies führt sowohl im Normalbetrieb als auch im Falle des Verlustes einer Platte dazu, dass die I/O-Auslastung für die Disk-Adapter gleichmäßiger über die beteiligten RAID Devices verteilt wird. Für eine RAID 7-Absicherung werden fünf Produktiv-Devices mit einem Parity Device kombiniert, aus dem bei Verlust einer physikalischen Magnetplatte der Inhalt dieser Platte zur Laufzeit errechnet wird. Bei RAID 7 muss lediglich jede fünfte Magnetplatte für die Parity-Informationen doppelt installiert und konfiguriert werden. Die Anzahl benötigter zusätzlicher Devices ist nochmals geringer als bei RAID 5/S. Damit ist die Absicherung durch RAID 7 das kostengünstigste RAID-Level, was jedoch mit einem nochmals erhöhten Performanceverlust beim Defekt einer Magnetplatte erkauft werden muss. In hochverfügbaren Systemumgebungen wird heute im Wesentlichen auf eine Absicherung mit RAID 1, also der Verfügbarmachung eines 1:1-SpiegelDevices zurückgegriffen. Diese Absicherung wird in der Regel kombiniert mit Hot Spare-Magnetplatten, die bei Ausfall einer physikalischen Platte an deren Stelle tritt. In der Regel werden je Storage Array zwei Hot Spare-Magnetplatten eingebaut. Diese sind in einem identischen Split untergliedert in Logical Devices

196

Hochverfügbare Speichersysteme Abbildung 4.35: RAID 7-Absicherung mit Parity

P ort C

Dis kAd a p te r


000 001 002 003 004 005

006 007 008 009 00A 00B

P ort D

00C 00D 00E 00F 010 011

012 013 014 015 016 017

P ort C

Dis kAd a p te r P roze s s or B P owe rP C750 266 MHz

018 019 01A 01B 01C 01D

01E 01F 020 021 022 023

P ort D

024 025 026 027 028 029

02A 02B 02C 02D 02E 02F

wie die Produktivplatten des Arrays. Fällt nun eine der Produktivplatten aus, so wird die Hot Spare-Platte an deren Stelle eingesetzt. Die Logical Devices der ausgefallenen Produktivplatte werden – so dies möglich ist – auf den Logical Devices der bisherigen Hot Spare-Platte wiederhergestellt. Die ausgefallene Produktivplatte wird bei nächster Gelegenheit ausgetauscht und übernimmt die Funktion der Hot Spare-Platte. Fällt in Abbildung 4.36 die Physical Disk mit den Devices 012 bis 017 aus, so wird an deren Stelle automatisch die Hot Spare-Platte eingehängt. Aus den verbliebenen Produktions- und Parity-Devices 000, 007, 00E und 01C wird der Inhalt sämtlicher Devices (012 bis 017) ermittelt und auf die Hot SparePlatte geschrieben. Diese hält nun die Devices 012 bis 017. Wird die defekte Platte getauscht, so wird sie zur neuen Hot Spare. Hot Spares werden zusätzlich zu jeglicher RAID-Absicherung verwendet. Fällt eine Physical Disk in einer RAID 1-Umgebung aus, die Spiegel-Devices enthält, so werden die Logical Volumes der Hot Spare-Platte von den jeweiligen Original-Devices synchronisiert und stellen ab Erreichung des Synchronisationszustandes die Spiegel-Devices dar. Fällt in einer RAID 1-Umgebung eine Physical Disk mit Original-Devices aus, so werden die Logical Volumes der Hot Spare-Platte von den jeweiligen Spiegel-Devices synchronisiert. Während der Synchronisation läuft die Produktion auf den SpiegelDevices. Nach Erreichen des Synchronisationszustandes schwenkt die Produktion auf die bisherige Hot Spare-Platte, die Spiegel-Devices werden wieder als Spiegel-Devices verwendet.

197

4 SAN – Hardware-Komponenten Abbildung 4.36: Hot Spare-Disks

P ort C

Dis kAd a p te r


000 001 002 003 004 005

006 007 008 009 00A 00B

P ort D

00C 00D 00E 00F 010 011

012 013 014 015 016 017

P ort C

Dis kAd a p te r P roze s s or B P owe rP C750 266 MHz

018 019 01A 01B 01C 01D

01E 01F 020 021 022 023

P ort D

024 025 026 027 028 029

HotHot Spare Spare

Fällt eine Physical Disk mit Devices von RAID 5, RAID S oder RAID 7 aus, so wird die Hot Spare-Platte aus den verbliebenen Daten- und Parity-Devices der RAID-Gruppe synchronisiert und ersetzt die ausgefallene Platte vollständig.

Remote Mirror-Absicherung Die Remote Mirror-Absicherung verwendet die oben dargestellte Konfiguration für Distanz-Topologien. Sie entspricht logisch dem Verfahren RAID 1 zur Absicherung von Devices – lediglich werden bei der Remote Mirror-Absicherung die Spiegel-Devices nicht auf dem lokalen Storage Array gehalten, sondern auf dem Remote Storage Array. Erinnern wir uns an die Erläuterungen zur Distanz-Topologie. Die OriginalDevices (S1) befinden sich alle auf dem lokalen Storage Array. Diese Original-Devices werden über Cache und Remote Link Directors auf ihre remote Spiegel-Devices (S2) auf dem Remote Storage Array gespiegelt. Geht in dieser-Umgebung eine lokale physikalische Platte mit S1-Devices verloren, so ist nicht einfach eine unterbrechungsfreie Fortsetzung der Produktion über die remote Spiegel-Devices möglich. Diese können nicht – im Gegensatz zu den lokalen RAID 1-Spiegeln – dieselben Eigenschaften besitzen wie ihr Original-Device. Der Server muss über einen eigenen Kanal an das Remote Storage Array angeschlossen sein. Dies bedeutet, dass er über einen anderen Port desselben oder eines anderen Host-Bus-Adapters das Remote Storage Array sieht. Damit haben die remote Devices definitiv eine andere Controller-Target-LUN-Adresse als die lokalen Original-Devices. 198




Switch S CS I

FCRLD

S CS I

FCRLD

FCRLD

FCRLD

S CS I

Abbildung 4.37: Remote Mirror Device-Absicherung

S CS I

Top-High Top-Low Bottom-High Ca c h e

Ca c h e

Bottom-Low

DD

DD

DD

DD

DD

DD

DD

DD

Um die Produktion auf den remote Spiegeln weiter betreiben zu können, muss seitens des Hosts der Schwenk auf das Remote Storage Array erfolgen, das heißt, er muss die Filesysteme der remote Disks mounten, muss die Devices des lokalen Storage Arrays disablen, die Devices des Remote Storage Arrays enablen und die Produktions-Applikation auf den nun aktiven remote Disks starten. Eine Absicherung mit Remote Mirror allein führt bei einem Plattenfehler also grundsätzlich zu ungeplanten Ausfallzeiten, obwohl die Daten der ausgefallenen Platte zu 100 Prozent remote verfügbar sind. In tatsächlich hochverfügbaren-Umgebungen dient die Remote Mirror-Absicherung daher nur als zusätzliche Absicherung für den Fall des Totalverlustes des lokalen Storage Arrays. Die Devices zumindest des lokalen Storage Arrays sind in einer solchen-Umgebung zusätzlich lokal mit RAID 1 gespiegelt und über ein Hot Spare Device abgesichert. Höchstverfügbare-Umgebungen halten auf beiden Storage Arrays sämtliche Devices nochmals lokal gespiegelt, sodass für diese Form der Absicherung das Vierfache an Magnetplatten benötigt wird als in einer ungeschützten Produktivumgebung.

Flexible Mirror-Absicherung Sämtliche bisher dargestellten Absicherungen von Magnetplatten vor Datenverlust sind statische Absicherungen, d.h. sie werden einmal erstellt, in der Regel im Microcode oder durch Binärfiles des Storage Arrays eingestellt und

199


sind danach nicht mehr ohne neuerliche Binärfile-Änderung machbar. Ein Spiegel-Device ist immer fest mit seinem Original-Device verdrahtet – der Spiegel lässt sich nicht aufbrechen. Abbildung 4.38: Flexible MirrorAbsicherung

Server 1 Daten

Daten

Daten

Original-Devices

Daten

Daten

Daten

Flexible Mirror Devices

Storage Array

Server 2

Flexible Mirrors dagegen sind Devices, die an Original-Devices gebunden und synchronisiert werden können, nach der Synchronisation jedoch von ihren Original-Devices wieder gelöst und einem anderen Server oder einer anderen Applikation zur Verfügung gestellt werden können. Anwendungsbeispiele für flexible Spiegel-Devices lesen sich wie das »Who is Who« aktueller IT-Anwendungen: 왘 Versorgung von Read-Only Data Warehouses mit stets aktuellen

Informationen aus den Produktionsdatenbeständen 왘 Beschaffung realistischer Testdatenbestände zur Durchführung von Tests

für zum Beispiel die Einführung des Euro 왘 »Point in Time«-Datensicherung und schnelles Recovery großer Daten-

banken 왘 Beschaffung realistischer Testdatenbestände für Funktions- und Integra-

tionstests neuer Programme für die Produktionsumgebung Bei all diesen Anwendungen wird der Flexible Mirror nicht zur Absicherung eines Original-Devices vor Verlust verwendet, sondern zur Erzeugung von Kopien der realen Produktionsdaten, die dann zur Zeit der Optimierung

200


anderen Anwendungen zur Verfügung gestellt werden. Die Vorteile der Flexible Mirrors liegen hier im Wesentlichen in folgenden Eigenschaften begründet: 왘 Von jedem aktiven Anwendungs-Datenträger kann eine Kopie erzeugt

werden. Die Betonung liegt hier auf dem aktiven Datenträger. Mit Flexible Mirrors können sogar geöffnete Filesystems oder Online-Datenbanken ohne Produktionsunterbrechung konsistent gesichert/kopiert werden. 왘 Die erzeugte Kopie kann von einer beliebigen anderen Anwendung bzw.

einem anderen System genutzt werden. So könnte z.B. der Server 2 in Abbildung 4.38 nach Synchronisation des Flexible Mirrors und dessen Trennung vom Original- oder Standard-Device als Backup-Server die Flexible Mirror Devices Direct Attached oder via SAN verfügbar machen, um eine Datensicherung ohne Belastung eines LANs durchführen zu können. 왘 Von einem einzelnen Standard-Device lassen sich mehrere Kopien erzeu-

gen. Über multiple Flexible Mirrors können mehrere Anwendungen, z.B. Data Warehouse, Schatten-Datenbank, Entwicklungsabteilung und Backup Server-Kopien eines Original-Devices erhalten. 왘 Nach Abschluss der Nutzung des Flexible Mirrors durch die alternativen

Anwendungen können diese unterbrechungsfrei vom Standard-Device resynchronisiert werden. Abbildung 4.39: Flexible MirrorAnwendungsschritte

S1

M2

F1

201


Ein Flexible Mirror Device wird dabei in folgenden Schritten genutzt: (1) Einrichten des Flexible Mirror Devices Je nach Hersteller des Storage Arrays respektive der unterstützenden Software müssen die Flexible Mirror Devices ihren Original-Devices auf unterschiedliche Weisen zugeordnet werden. Allen Herstellern gemein ist, dass ein Flexible Mirror Device einem Standard-Device zugeordnet wird (assoziieren des Flexible Mirrors) und die darauf folgende Synchronisation des Flexible Mirrors von »seinem« Standard-Device (etablieren des Spiegels). Im synchronen Zustand stellt der Flexible Mirror einen weiteren Spiegel des Standard-Devices dar. (2) Garantie der Konsistenz der Daten des Flexible Mirrors Flexible Mirrors dienen dazu, nach ihrer Synchronisation von ihrem Standard-Device getrennt und einer anderen Applikation oder einem anderen Server zur Verfügung gestellt zu werden. Dazu müssen die Daten des Flexible Mirrors zum Zeitpunkt des Auftrennens des Spiegels konsistent sein. Konsistenz bedeutet hierbei, dass – für den Fall, dass das Standard-Device ein Filesystem beherbergt – zum Zeitpunkt der Trennung keine Datei geöffnet ist und damit sichergestellt ist, dass sämtliche Dateien ohne noch ungesicherte Änderungen auf dem Standard-Device und dem Flexible Mirror vorliegen. Ist das Standard-Device ein Datenbank-Device, so muss sichergestellt werden, dass sämtliche Transaktionen, die zum Zeitpunkt der Trennung bereits abgeschlossen sind, auch auf das Mirror Device geschrieben wurden. Weiter muss sichergestellt sein, dass das aktuelle Transaktions-Protokoll, das die zum Zeitpunkt des Trennens noch nicht abgeschlossenen Transaktionen enthält, ebenfalls übertragen wird, oder zumindest sichergestellt wird, dass ein Recovery von diesem Transaktions-Protokoll möglich ist. Für die Gewährleistung der Konsistenz der Daten des DatenbankDevices bieten sich – je nach Datenbank-Management-System (DBMS) – zwei Ansätze zur Realisierung an. Der erste Ansatz ist ein Offline-Ansatz, das heißt, sämtliche Transaktionen werden vor der Auftrennung des Spiegels zwischen Standard-Device und Flexible Mirror gestoppt. Dies geschieht in der Praxis durch Stoppen der DBMS-Services, indem das DBMS heruntergefahren wird. Nachteil des Offline-Ansatzes ist, dass hier das Trennen des Flexible Mirrors grundsätzlich eine geplante Ausfallzeit der Produktion erfordert. Um das zu verhindern, haben einige DBMS – insbesondere Oracle – einen so genannten Hot Backup-modus implementiert, der einen OnlineAnsatz zur Gewährleistung der Konsistenz ermöglicht. Dabei wird für jeden Tablespace, also für sämtliche Datenbank-Devices, ein Marker gesetzt, zu welchem Zeitpunkt dieser Hot Backup angestoßen wurde. Das aktuelle Transaktions-Protokoll wird geschlossen und ein neues erstellt, in das sämtliche Änderungen durch Transaktionen kopiert werden, die zum Zeitpunkt des Hot Backup noch nicht abgeschlossen waren, und das die Änderungen sämtlicher Transaktionen enthält, die nach Start des Hot Backup beginnen. Dieses Transaktions-Protokoll wird für das Recovery im Fall eines Daten-

202


bankfehlers benötigt Sämtliche Änderungen der zum Zeitpunkt des Hot Backups bereits abgeschlossenen Transaktionen befinden sich auf dem Standard-Device und damit auch auf dem Flexible Mirror. Doch befinden sich die Änderungen wirklich auf dem Standard-Device und Flexible Mirror? Erinnert man sich an das Handling von Write I/Os in den dargestellten Storage Arrays, so weiß man, dass diese eine Write I/O als complete an den Server melden, sobald er in einem freien Cache-Slot platziert wurde. Erst nach einem Forced Destage oder einem Delayed Destage durch einen Disk Director befinden sich die Daten tatsächlich auf dem Standard-Device und dem Flexible Mirror. Die Konsistenz der Daten auf dem Flexible Mirror wird nur dadurch garantiert, dass neben sämtlichen Aktionen auf der Filesystemund der DBMS-Ebene auch ein Forced Destage durchgeführt wird, der eben den Cache der betroffenen Datenbank-Devices leer räumt. (3) Trennung des Flexible Mirrors Ist die Konsistenz der Daten auf dem Flexible Mirror gewährleistet, so wird dieser von seinem Standard-Device getrennt. Dabei verliert er nicht die Bindung an sein Standard-Device. Erinnern wir uns an die Cache-Struktur der Storage Arrays, so waren im Cache die Slots für Track Tables enthalten. Bei Verwendung von Flexible Mirrors werden ab dem Zeitpunkt der Trennung des Flexible Mirrors von seinem Standard-Device in jeder Device Track Table die Spuren auf dem Standard-Device festgehalten, die sich seit der Trennung geändert haben. Soll der Flexible Mirror später wieder von seinem StandardDevice synchronisiert werden, so kann diese Synchronisation inkrementell erfolgen, d.h. es müssen nur die Spuren resynchronisiert werden, die sich seit der letzten Trennung geändert haben. Dies gilt jedoch nur, wenn der Flexible Mirror nach der Trennung von seinem Standard-Device lediglich lesend von einer anderen Applikation, also z.B. von einer Data Warehouse-, Reporting- oder Backup-Applikation genutzt wurde. Wurde er jedoch nach der Trennung für schreibende Aktionen genutzt, muss die Resynchronisation des Flexible Mirror wieder sämtliche Spuren des Standard-Devices auf den Flexible Mirror übertragen. (4) Re-Start der Transaktionen Nachdem die Trennung des Flexible Mirrors von seinem Standard-Device stattgefunden hat, können die Transaktionen auf dem Standard-Device wieder gestartet werden. Sämtliche nun stattfindende Änderungen werden in den Transaktions-Protokollen der Datenbanken und in den Track Tables im Cache des Storage Arrays protokolliert. (5) Verwendung des Flexible Mirrors für Backups, Tests etc. Nach Trennung des Flexible Mirrors von seinem Standard-Device ist er für den Server, der das Standard-Device hosted not ready – er kann den Flexible Mirror nicht sehen und nicht manipulieren. Der Server, der den Flexible Mirror nach der Trennung erhält, muss ihn je nach Applikation, die ihn verwen-

203


den soll, write disabled oder read/write enabled sichtbar machen. Bis der Flexible Mirror wieder resynchronisiert werden soll, kann er nun von diesem Server aus wie jede andere »normale« Magnetplatte genutzt werden. (6) Resynchronisation des flexible Mirrors Bei der Resynchronisation des Flexible Mirrors werden entweder nur die seit der Trennung geänderten Spuren gemäß des Device Track Tables im Cache des Storage Arrays auf den Flexible Mirror übertragen (Flexible Mirror wurde nur zum Lesen genutzt) oder sämtliche Spuren des Standard-Devices auf den Flexible Mirror kopiert (Flexible Mirror wurde auch zum Schreiben verwendet). Danach kann der Verwendungszyklus erneut durchlaufen werden. Bei dem oben dargestellten Verwendungszyklus wurde davon ausgegangen, dass idealerweise je Standard-Device ein Flexible Mirror Device verfügbar ist. Aus Gründen der Kostenersparnis kann jedoch ein Flexible Mirror auch für mehrere Standard-Devices genutzt werden, je nach der zweiten Applikation, die dieses Device verwenden soll. Dabei bleibt es bei den Schritten des Einrichtens des Flexible Mirror Device (1), der Garantie der Konsistenz der Daten des Flexible Mirror (2), der Trennung des Flexible Mirror (3), des Re-Startes der Transaktionen (4) und der Verwendung des Flexible Mirror für Backups, Tests etc. (5). Nun soll jedoch der Flexible Mirror für ein weiteres, anderes Standard-Device verwendet werden. Dadurch folgen jetzt zwei neue Verwendungsschritte: (6) Einrichten des Flexible Mirror Device für ein anderes Standard-Device Wie oben erwähnt wird ein Flexible Mirror einem Standard-Device assoziiert. Daher muss bei Wiederverwendung eines Flexible Mirrors für ein anderes Standard-Device zunächst die Assoziierung des ersten Standard-Devices aufgehoben werden. Dadurch wird die Track Table für das Flexible Mirror Device im Cache des Storage Arrays obsolet. Der Flexible Mirror wird dem zweiten Standard-Device assoziiert und voll synchronisiert, d.h. sämtliche Spuren des zweiten Standard-Devices werden nun auf den Flexible Mirror kopiert. (7) Wiederholung der Schritte (1)-(3) Für jedes weitere Standard-Device, für das dieser Flexible Mirror verwendet werden soll, müssen nun die Schritte (1)-(3) wiederholt werden. Die Verwendung eines Flexible Mirrors für mehrere Devices erfordert ein Mehrfaches an Administrationsaufwand gegenüber der Idealsituation, dass jedes StandardDevice einen eigenen Flexible Mirror besitzt. Dennoch kann mithilfe der entsprechenden Storage Array-Administrations-Software der komplette Verwendungszyklus der Flexible Mirrors automatisiert werden, sodass der Aufwand lediglich in der Design- und Testphase der Implementierung auftritt.

204


S1

S1

(1)-(5)

Abbildung 4.40: Verwendung eines Flexible Mirror Device für mehrere Standard-Devices

(6)

F1

Auch in Umgebungen, die ihre Standard-Devices mit Gruppen von RAID 5/S absichern, können Flexible Mirrors eingesetzt werden. Dabei wird einem Device aus der RAID-Gruppe (jeweils) ein Flexible Mirror zugewiesen. Wichtig ist dabei, dass nur Daten-Devices mit einem Flexible Mirror assoziiert werden – das Parity Device muss nicht mit einem Flexible Mirror abgesichert werden. Eine weitere Anwendung von Flexible Mirrors basiert auf mehreren Generationen von Flexible Mirrors für ein einziges Standard-Device. Ein solches Szenario ist entweder dort notwendig, wo über mehrere Flexible Mirrors eines Standard-Devices mehrere Applikationen mit den Produktionsdaten desselben versorgt werden sollen, also z.B. Backup, Schattendatenbank und Data Warehouse. Ein weiteres klassisches Szenario für multiple Flexible Mirrors sind Umgebungen, die eine Maximal-Recovery-Zeit von wenigen Minuten definieren. So fordert z.B. die MaH-Mindestanforderung an Handelssysteme für Banken eine maximale Downtime eines Handelssystems von zwölf Minuten pro Monat und 90 Minuten pro Jahr. Diese Maximalforderungen sind mit Tapebasierten Datensicherungen überhaupt nicht zu realisieren. Hier ist es also erforderlich, mehrmals pro Tag ein Abbild der Produktionsdaten auf Flexible Mirrors zu ziehen, von dem ein schnelles Recovery möglich ist. Dabei sollte es sich auch tatsächlich um mehrere Generationen von Flexible Mirrors handeln. Je nach Art des die Downtime bewirkenden Fehlers (Hardware- oder Benutzerfehler) ist es möglich, dass dieser Fehler, bevor er bemerkt wurde, bereits auf einem Backup Flexible Mirror gespeichert ist.

205

4 SAN – Hardware-Komponenten Abbildung 4.41: RAID 5/S DeviceGruppen mit Flexible Mirrors

S1

S1

S1

F1

F1

F1

Parity

Dann ist es notwendig, auf ein Flexible Mirror einer früheren Generation zurückzugreifen, um sämtliche Transaktionen bis kurz vor dem Fehler wiederherstellen zu können. Die Verwendungsschritte der multiplen Flexible Mirrors sind dann wie folgt: 왘 Einrichtung der Flexible Mirrors der ersten Generation (F1) 왘 Trennen der Flexible Mirrors der ersten Generation (F1) 왘 Einrichten der Flexible Mirrors der zweiten Generation (F2) 왘 Trennen der Flexible Mirrors der zweiten Generation (F2) 왘 Einrichten der Flexible Mirrors der n-ten Generation (Fn) 왘 Trennen der Flexible Mirrors der n-ten Generation (Fn) 왘 Einrichten der Flexible Mirrors der ersten Generation (F1) usw.

Interessant ist bei multiplen Flexible Mirrors das Handling der Track Tables der Devices im Cache des Storage Arrays. Idealerweise werden hier im Cache die Track Tables je Generation gehalten. Dies führt dazu, dass bei der Einrichtung einer jeden Generation von Flexible Mirrors lediglich die Spuren resynchronisiert werden müssen, die sich auf dem Standard-Device geändert haben, seit diese Generation der Flexible Mirrors zum letzten Mal voll synchronisiert war. Dadurch verringern sich die Synchronisationszeiten immens, was insbesondere in den Szenarien von großer Bedeutung ist, die

206


mithilfe der Flexible Mirrors maximale Downtimes realisieren. Das ist besonders aus dem Grund von immenser Bedeutung, weil die Synchronisation des Flexible Mirrors nicht unterbrochen werden kann, um von einer anderen Generation Flexible Mirrors ein schnelles Recovery zu starten, da sonst die Folge der Track Tables im Cache korrumpiert würde. Storage Arrays, die die Operation mehrerer Flexible Mirror-Generationen erlauben, unterbinden ein Unterbrechen der Synchronisation einer Generation. Daher ist es extrem wichtig, dass es über multiple Track Tables eines Standard-Devices im Cache möglich wird, die Resynchronisation der Flexible Mirrors inkrementell durchzuführen. Ein Kopieren sämtlicher Spuren eines Standard-Devices zur Resynchronisation des Flexible Mirrors ist nicht notwendig. Abbildung 4.42: Multiple Flexible Mirrors

S1

F1

F2

M2

Fn

Flexible Mirrors sind nicht nur auf ein lokales Storage Array einzusetzen. So können auch in Distanz-Topologien Flexible Mirrors auf dem lokalen und dem Remote Storage Array für die genannten Zwecke verwendet werden. So stellen Remote Flexible Mirrors (RR1) die Möglichkeit dar, Backups und Entscheidungsunterstützung an mehreren Standorten bei vollem Schutz der Magnetplatten und der Standort-Rechenzentren zu gewährleisten. In Abbildung 4.43 stellt S2 den remote Spiegel des Standard-Devices S1 dar. Sowohl für S1 als auch für S2 existieren mit M3 und M4 lokale Spiegel zur Absicherung vor Magnetplattenfehlern. R1 ist ein Flexible Mirror des S1Devices auf dem lokalen Storage Array. RR1 ist ein Flexible Mirror des S2-Devices auf dem Remote Storage Array. Da jedoch das S2-Device der remote Spiegel des S1 Devices auf dem lokalen Storage Array ist, ist RR1 also auch ein weiterer Flexible Mirror des S1-Devices.

207

4 SAN – Hardware-Komponenten Abbildung 4.43: Remote Flexible Mirrors

Lo ka le s S to ra g e Arra y

PProduktion roduktion

S1

Re m o te S to ra g e Arra y

M3

La Lade denn eeine iness Da Data ta-Wa Ware rehous house, e, Ents Entsche cheidungsidungsunte unters rstützung tützung

„Re „Recove covery“ ry“na nach ch Tota Totala laus usfä fälle llenn

S2

M4

Da Date tens nsiche icherunge rungen, n, Te Tessts ts von von PProgra rogramme mmenn R1

RR1

Im Folgenden sollen noch einmal die wesentlichen Eigenschaften der Flexible Mirrors dargestellt werden. 왘 Flexible Mirrors werden auf der logischen Ebene eingerichtet, also basie-

rend auf Logical Volumes und nicht auf physikalischen Platten. 왘 Die Spur- und Zylindergröße der Flexible Mirrors ist stets gleich. So be-

steht eine Spur z.B. aus 64 Blöcken à 512 Bytes (32 KB) und ein Zylinder aus 15 Spuren. 왘 Die physikalischen Laufwerke zwischen Standard-Device und Flexible

Mirror können unterschiedlich groß sein, wichtig ist die logische Größe, die sich aus oben angegebenen Spur- und Zylinderwerten ergibt. 왘 Im synchronisierten Zustand funktioniert ein Flexible Mirror wie ein

weiterer Spiegel eines Standard-Device. 왘 Zum Kopieren von Meta Volumes (siehe oben) müssen auch Meta Fle-

xible Mirrors verwendet werden.

4.2.3

Highend Fibre Channel Storage Arrays

Der Abschnitt über hochverfügbare Storage Arrays soll abgeschlossen werden mit der Architektur der Highend All-Fibre Channel-Storage Arrays. Diese bieten sämtliche zuvor beschriebenen Funktionalitäten lediglich mit dem architektonischen Unterschied, dass auch das Storage Array Back-End in Fibre Channel-Technologie, in der Regel über Arbitrated Loop verknüpfte Magnetplatten, realisiert ist.

208


Fibre Channel FC-HCP

Cross Bar

FC-HCP

.

FC-HCP

Bis zu 32 physikalische Platten je FC-AL-Paar

32 Fibre Channel Arbitrated Loops im Backend (512 Physical Disks)

. .

.. .

DAP

FC-HCP

Bis zu 32 Fibre Channel-Ports

DAP

Abbildung 4.44: Highend All-Fibre Channel-Storage Array-Architektur

6,4 GB/ Sek Switch

Fibre Channel DAP

.. .

Bis zu 32 physikalische Platten je FC-AL-Paar

DAP

Cache und Shared Memory Highend All-Fibre Channel-Storage Arrays werden derzeit von zwei Herstellern (Hitachi Data Systems – HDS und Hewlett-Packard – HP) angeboten, wobei es sich jedoch um die gleichen Systeme handelt. Hewlett-Packard vertreibt dabei in einer engen Partnerschaft die Systeme von HDS. Bezüglich der Host Connectivity bieten die Systeme bis zu 32 Fibre Channels oder ESCON-Ports auf Channel Director-Boards (Client-Host Interface-Prozessoren, CHIP) mit vier Host Connection-Prozessoren (HCP). Seitens HDS ist das Angebot ausschließlich auf Glasfaser-Connectivity, also ESCON und Fibre Channel, beschränkt, während HP auch noch SCSI HCPs anbietet, die einen Direct Attach von SCSI-Host-Bus-Adaptern unterstützen. Das Fibre Channel Back-End besteht aus bis zu 32 Fibre Channel Disk Access-Prozessoren (DAP), die ebenfalls auf Boards zu je vier DAPs (Array Control Prozessoren ACP) verfügbar sind. Jeder DAP steuert eine FC-AL Loop mit bis zu 32 Fibre Channel-Magnetplatten. Je zwei DAP FC-AL Loops unterschiedlicher ACPs sind zu Hochverfügbarkeitszwecken zusammengefasst. Fällt also ein DAP aus, so werden seine Disks über die Loop des zweiten DAP erreicht, fällt ein ACP aus, so sind sämtliche Disks der DAPs dieses ACP über einen zweiten erreichbar. Auch die All-Fibre Channel Storage Arrays verarbeiten die I/O-Requests Cache-basiert. Der Cache kann bis zu 32 GB groß sein, von denen 1,5 GB als so genanntes Shared Memory für interne Instruktionen verwendet werden. Dieses Shared Memory entspricht dem für die SCSI-Back-End-Systeme dargestellten Memory-Bedarf für Track Tables und Kommunikations-Mailboxes. Der Rest des Caches ist segmentiert für Read-I/Os und Write-I/Os. Der Cache

209


für Write-I/Os ist gespiegelt, sodass hier auch Cache-Segmente verloren gehen können, ohne dass der Produktionsbetrieb stoppt. Dies entspricht den Möglichkeiten der Fencing Logic des Caches der SCSI-Back-End-Storage Arrays. Front-End und Back-End des All-Fibre Channel Storage Arrays werden durch einen so genannten Hi-Star-Crossbar Fibre Channel-Switch über den Cache miteinander verbunden. Hier werden N-Ports der CHIP (Client-Host Interface Prozessor) HCP-Prozessoren (1 Port je Prozessor) auf NL-Ports der ACP (Array Control Prozessor) DAP-Prozessoren (1 Port je Prozessor) und damit einer FC-AL Disk Loop geswitched. Dies verleitet zu der Aussage, die Systeme unterstützten eine interne Bandbreite von 6,4 GB/Sek. Diese Aussage ergibt sich rechnerisch aus bis zu 32 Fibre Channel-Ports auf der FrontEnd-Seite plus bis zu 32 Fibre Channel-Ports auf der Back-End-Seite multipliziert mit der Fibre Channel-Bandbreite von 100 MB/Sek. je Port (64 Ports x 100 MB/Sek. = 6,4 GB/Sek.). Abbildung 4.45: All-Fibre ChannelArchitektur

CHIP

32 Ports

32 Ports

Control Memory

Cache

Control Memory

Cache

Cache

Cache/Data Side

Cache/Data Side

Cache/Data Side

Cache-Switch

Cache-Switch

Cache-Switch

Processor Side

Processor Side

8 Ports

CHIP = Client-Host Interface Processor

CHIP

8 Ports

ACP

Processor Side

8 Ports

ACP

Cache

Cache/Data Side

Cache-Switch Processor Side

8 Ports

ACP = Array Control Processor

Unabhängig davon, dass aus Anwendungssicht bei optimaler Lastverteilung auf 32 CHIP-Ports maximal eine Gesamtbandbreite von 3,2 GB/Sek. gemessen werden kann (die Back-End-Bandbreite interessiert die FrontEnd-Performance leidlich wenig), werden diese 6,4 GB/Sek. aus anderen Gründen utopisch bleiben. Diese Gründe sind:

210

Connectivity-Hardware 왘 Die Cache-Basis der I/Os. Es kann maximal die Bandbreite erreicht wer-

den, die der Cache bietet. Bei Cache Board-Geschwindigkeiten von 500 MB/Sek. und maximal vier Cache Boards sind also Maximalbandbreiten von zwei GB/Sek. erreichbar. 왘 Bandbreitenverluste durch Cache-Mirroring. Wenn der Cache für schrei-

benden I/O gespiegelt wird, geht zumindest von der maximalen Bandbreite noch der Bestandteil verloren, der für die Spiegelung der Write I/Os zusätzlich benötigt wird. Der wesentliche Faktor, der die Bandbreite beschränkt, dürfte jedoch die optimale Verteilung der Back-End-Devices auf die Front-End-Ports darstellen, eine Problematik, die im folgenden Abschnitt der Connectivity-Hardware beschrieben wird.

4.3

Connectivity-Hardware

4.3.1

Fibre Channel-Hubs und Multiplexer

Fibre Channel-Hubs dienen in einer FC-AL-Topologie zur Verbindung mehrerer Loops und zur Implementierung einer Stern-Topologie im Gegensatz zur Daisy-Chain Arbitrated Loop von bis zu 128 Devices.

Client-Host InterfaceProzessor 4 Port

Client-Host InterfaceProzessor 2 Port

Array ControlProzessor 4 Port

Tachyon

FOP

i960

i960

Tachyon

Tachyon

i960

FOP

i960

Tachyon

i960

Tachyon

Tachyon

i960

DRR

FOP

Tachyon

DRR

i960

Tachyon

Tachyon

i960

FOP

i960

i960

Abbildung 4.46: All-Fibre FrontEnd- und Back-EndLayout

i960

DRR

i960

DRR

Tachyon

FC-AL Disk Loops

211

4 SAN – Hardware-Komponenten Abbildung 4.47: Fibre Channel-Hubs

NT-Server

IBM-Server

Sun-Server

HP-Server

F C HB A

F C HB A

F C HB A

F C HB A

Port A

Port B

Port A

Port B

Port A

Storage F A

Array 1

Port B

Port A

Port B

Die klassische Konfiguration von Fibre Channel-Hubs sieht Hubs mit zehn Shortwave Fibre Ports zum Anschluss von maximal zehn Endgeräten oder Hubs mit neun Shortwave Fibre-Ports und einem Longwave Fibre-Port zur Implementierung von Hub-Cascadierung (vgl. Abbildung 4.46) oder zum Anschluss an einen Switch vor. Ist der Hub in kompletter Glasfaser-Technologie aufgebaut, so benötigt er keinen Gigabit Interface Converter (GBIC, vgl. Kapitel 2). Aus Gründen der Kapazität und der Bandbreite empfiehlt sich im Einsatz von Hubs in einer Fibre Channel SAN-Umgebung folgende Konfiguration: 왘 vier Host Connections (Verbindungen zu Host-Bus-Adapter Ports) pro

Fibre Channel Loop 왘 acht Storage Array Connections (Verbindungen zu Fibre Channel Chan-

nel Director-Ports) pro Fibre Channel Loop Ein großer Vorteil der Hub-Konfiguration gegenüber der klassischen DaisyChained Arbitrated Loop besteht darin, dass sowohl die Host- als auch die Storage Array-Verbindungen an den Hub online angesteckt oder entfernt werden können. Diese Hot Plugging/Hot Unplugging-Funktionalität macht es möglich, für Hub-Topologien hochverfügbare Lösungen zu entwickeln, die darauf basieren, dass über zwei Host-Kanäle (Host Port/Hub Port) auf unterschiedlichen Hubs sichergestellt wird, dass die Devices des Storage Arrays über den zweiten verfügbar sind, wenn einer der beiden Hubs ausfällt. Der defekte Hub kann ausgetauscht werden, seine Verbindungen können dann hot neu gesteckt werden und die Devices des Storage Arrays sind wieder über beide Host-Kanäle sichtbar.

212


NT-Server

F C HB A

IBM-Server

F C HB A

Sun-Server

F C HB A

HP-Server

F C HB A

Abbildung 4.48: Hochverfügbare Fibre Channel-Hubs

Storage F A

Array 1

Cascadierte Hubs werden für Hub-zu-Hub oder für Site-zu-Site Verbindungen in Distanz-Topologien benötigt. In der Regel werden mehr als zwei Hubs in einer kaskadierten Loop nicht unterstützt. Sämtliche Longwave-Distanz-Verbindungen müssen Hub-zu-Hub-Verbindungen sein. Die maximale Entfernung zwischen den beiden Hubs ist in aller Regel auf zehn Kilometer beschränkt. Longwave-Verbindungen zwischen Host und Hub oder Hub und Storage Array werden allgemein nicht unterstützt. Die physikalischen Verbindungen zum Hub sollten auf aufeinander folgende Port-Anschlüsse des Hubs gesteckt werden. Zwischen den Kabelverbindungen sollten keine ungenutzten Hub Connectors liegen (es könnte zu einem Antenneneffekt auf dem offenen Connector und zum Verlust eines Arbitration Cycles kommen. Daraus folgt eine verringerte Gesamtbandbreite und ein signifikanter Performanceverlust für die gesamte Arbitrated Loop). Eine weitere physikalische Einschränkung betrifft die Gesamtkabellänge der an den Fibre Channel-Hub verbundenen Kabel. Diese darf 13 Kilometer nicht übersteigen. Es gibt keine Restriktionen bezüglich der Mixtur der Fibre Channel-Kabel, die an einen Hub angesteckt werden, solange die Gesamtlänge der Kabel 13 Kilometer nicht übersteigt. Sämtliche Administrations- und Anwendungs-Software, die in Fibre Channel-Umgebungen unterstützt wird, wird in aller Regel sowohl in FC-SW- als auch in FC-AL-Hub-Konfigurationen unterstützt.

213


Ein Fibre Channel Multiplexer wird auch häufig als Fibre Channel-to-SCSI-Router oder Fibre Channel-to-SCSI-Bridge bezeichnet. Er verbindet einen Port eines Fibre Channel-Host-Bus-Adapters mit vier SCSI-Ports eines Storage Array SCSI-Channel Directors. Abbildung 4.49: Fibre Channel Multiplexer

F i b r e

NT-Server

F C H B A

C h a n n e l M u l t i p l e x e r

S A

Storage Array 1

Die physikalische Verkabelung vom Host-Bus-Adapter zum Fibre Channel Multiplexer erfolgt über Shortwave-Glasfaserkabel (fünf Meter bis 500 Meter), die Verkabelung zwischen Multiplexer und SCSI Channel Director des Storage Arrays erfolgt über Standard-SCSI-Kabel. Je nach Hersteller von Host-Bus-Adapter, Fibre Channel Multiplexer und Storage Array können mehr oder weniger Einschränkungen für den Einsatz des Multiplexers zum Tragen kommen. Übliche Einschränkungen für den FC-Mux-Einsatz sind: 왘 Je Multiplexer darf nur ein einziger Fibre Channel-Host-Bus-Adapter-

Port angeschlossen werden. 왘 Der Host muss direkt über den Multiplexer an das Storage Array ange-

schlossen werden. Eine Multiplexer-Verbindung über FC-AL-Hubs wird nicht unterstützt. 왘 Dynamic Multipathing ist nur über den Einsatz eines zweiten Multi-

plexers möglich.

214

Connectivity-Hardware 왘 Es wird lediglich der FC-AL-Protokoll-Stack unterstützt. Dies ist beim

Multiplexen eines Fibre Channel-Ports mit 100 MB/Sek. auf vier FWDSCSI-Ports (je 20 MB/Sek.) vollkommen ausreichend. Wird jedoch UWDSCSI (je 40 MB/Sek.) verwendet, so wird beim Einsatz des Multiplexers einiges an Bandbreite verschenkt. 왘 Die Distanz zwischen Host-Bus-Adapter und Fibre Channel Multiplexer

und damit zwischen Server und Storage Array ist auf maximal 500 Meter beschränkt.

F C H B A

Abbildung 4.50: Konfiguration eines hochverfügbaren Fibre Channel Multiplexer

S A Fibre Channel Multiplexer

Storage

NT-Server

Array 1 F C H B A

S A Fibre Channel Multiplexer

4.3.2 4.3.2.1

Hochverfügbare Fibre Channel-Switches Hochverfügbare Switch Komponenten

Fibre Channel-Switches sind die Komponenten eines Storage Area Networks, die dieses eigentlich erst definieren und begründen. Ein Switch ist in einer FC-SW-Umgebung der Teil, der die Verbindung zwischen den Storage Devices und den Servern des SAN herstellt und die einfache Verwaltung des kompletten SANs sicherstellt. Beim Switch wird definiert, welcher Server welche Magnetplatten von welchem Storage Array sieht und mit ihnen operiert. Über die Switched Connectivity wird es leicht möglich, neue Fibre Channel-Geräte in den SAN zu integrieren und ohne großen Verwaltungsaufwand in Betrieb zu nehmen. Switches bieten hardwareseitig eine bestimmte Anzahl von Ports zum physikalischen Anschluss von Fibre Channel Devices. Klassische Switch-Konfigurationsgrößen betragen vier

215


Ports, acht Ports, 16 Ports, 32 Ports und inzwischen auch 64 Ports, über die Hosts und Storage Arrays oder auch Magnetbandarchive für Fibre Channelbasierte Backup-Lösungen angeschlossen werden. Über spezielle Ports eines Switches (E-Ports oder Expansion-Ports) werden mehrere Switches zu einer administrativen Einheit, ihre Fibre Channel-Endgeräte zu einem SAN zusammengeschlossen. Mehrere über E-Ports zusammengeschlossene Switches bilden eine Fabric. Abbildung 4.51: SAN-FC-SWUmgebung

Switch Management Workstations

Switch

Switch

Switch

Switch

Ethernet

Switch

Switch

SNMP Management Station

Switch

Switch

Switch Service Processor

Switched Fabric In diesem Abschnitt soll zunächst die Fibre Channel-Switching-Hardware dargestellt werden, bevor im folgenden Abschnitt die softwareseitige Administration von Switches und Fabrics dargestellt werden soll. In diesem Abschnitt über Hardware soll wiederum der Schwerpunkt auf die Hochverfügbarkeit der Switching Devices gelegt werden. Switches werden heute im Wesentlichen von drei Herstellern geliefert, deren Produkte in die Fibre Channel-Geräte sämtlicher Storage Array-, BackupTape-Libraries- und Server-Hersteller integriert und von diesen – auch unter eigenem Namen – vertrieben werden. Hochverfügbare Switch-Komponenten sollen im Folgenden am Beispiel eines 32-Port-Switches erläutert werden. Dabei bietet ein solcher Switch allgemeine Eigenschaften wie:

216

Connectivity-Hardware 왘 bis zu 32 Fibre Channel-Verbindungen über bis zu 32 Fibre Channel

G-Ports. Bei Anschluss an ein FC-Endgerät wird ein G-Port zum F-Port, beim Anschluss eines weiteren Switches zu einer Fabric werden die beiden verwendeten G-Ports der Switches zu E-Ports. 왘 Hochverfügbarkeit wird – wie gewohnt – durch redundante Auslegung

der kritischen Hardware-Komponenten erreicht. Sämtliche HardwareKomponenten bieten eine automatische Fehlererkennung und automatische Failover-Mechanismen bei einem Komponentenverlust. 왘 Das Zoning ermöglicht die genaue Zuordnung von Speicherendgeräten

zu Host- oder Serverendgeräten und damit die Zuordnung von Magnetplatten zu ihren Servern. 왘 Multiswitch Fabric-Unterstützung ist unbedingt notwendig, um größere

SANs und Distanz-Topologien von Storage Area Networks aufzubauen. Abbildung 4.52: Aufbau eines hochverfügbaren 32 Port Switches

Slot 7

Port 31 Power-Schalter Bedienungsfeld

Port-Karten

CTP-Karten

Central Memory Module

Control Processor

MPC-Karten CMM-Karten Message Path Controller Port 0 Port 12

Slot 0 Port 4

왘 Full-Duplex-Datentransfer mit einer Übertragungsbandbreite von 1,0625

Gigabit/Sek. auf jedem Port. Auf jedem Port wird die komplette Fibre Channel-Bandbreite von 100 MB/Sek. für das SAN garantiert. 왘 Extended Distance Port-Optionen, die die Kopplung von Switches über

E-Ports oder den Anschluss von Endgeräten über F-Port/N-Port oder FPort/NL-Port bei Distanzen von bis zu 20 Kilometern ermöglichen. Diese Optionen sind notwendig für den Aufbau von SAN-Distanz-Topologien.

217

4 SAN – Hardware-Komponenten 왘 Maximale Latenzzeit einer Frameübertragung vom Sender-Port bis zum

Empfang auf dem Empfänger-Port von vier Mikrosekunden. Gewährleistung, dass es zu keiner Port-Contention kommen kann. 왘 Eine Bitfehlerrate von maximal einem Bit pro Trillion (1012 ) übertragener

Bits. 왘 Automatische Pfadauswahl in einer Switched Fabric. Intelligente Swit-

ches erkennen automatisch die Fabric-Topologie und wählen stets die Datentransfer-Pfade durch die Fabric, die mit der geringsten Anzahl von Switch-Hops zu erreichen sind. Bei Änderung der Fabric-Topologie, z.B. indem zusätzliche Switches oder Inter-Switch-Links (über E-Ports) hinzugefügt werden oder Hardware aus der Fabric entfernt wird, registrieren die Switches automatisch die Veränderung und definieren intern die neuen Datentransfer-Pfade durch die Fabric. 왘 Konfiguration der Port-Karten mit zwei Ports je Karte. 왘 Unterstützung von drei Fibre Channel-Serviceklassen. Fibre Channel

Class2 Service unterstützt optimal die klassischen kaufmännisch orientierten Anwendungen. Fibre Channel Class3 Service unterstützt optimal Massenspeicher und Video-basierte Anwendungen. Fibre Channel ClassF Service kontrolliert und koordiniert das Verhalten einer Fibre Channel Fabric. Abbildung 4.53: Zentrale Komponenten eines Fibre Channel-Switches

CTP - Control Prozessor-Karte

MPC Message Path Controller-Karte, kommuniziert mit den Ports

System Clock

Port ModuleKarte

Port ModuleKarte

CMM- Central Memory Module-Karte

218

FC-Frame


Fibre Channel-Switches werden um folgende zentrale Komponenten aufgebaut: 왘 Bedienungsfeld 왘 Abgesicherter On/Off-Schalter 왘 Port-Karten 왘 Message Path Controller-Karte 왘 Central Memory Module-Karte 왘 Kontrollprozessor-Karte 왘 Lüfter (Fan) Modul 왘 Power Supplies

Das Bedienungsfeld besteht aus mehreren Funktionsbausteinen. Ein in aller Regel alphanummerischer Bildschirm wird für die Präsentation von Statusund Ereignis-Mitteilungen verwendet. Ein Funktions-Button für den Initial Machine Load (IML) sorgt –wenn er länger als drei Sekunden gedrückt wird – für ein Neuinitialisieren der Switch-Firmware und für ein Reset sämtlicher Kontrollprozessoren des Switches, ohne dass dieser ausgeschaltet werden muss oder existierende Links unterbrochen werden. Weiter wird ein Maintenance Port für den Anschluss eines lokalen Wartungs-Terminals oder für einen Dial-In-Anschluss eines Remote Wartungs-Terminals im Bedienungsfeld angeboten. Der abgesicherte On/Off-Schalter ist – im Falle eines hochverfügbaren Switches – verbunden mit beiden Power-Supplies. Die On/Off-Schalter bei Switches sind vor versehentlichem Ausschalten dadurch geschützt, dass ein laufender Switch nur durch das Beiseiteschieben einer »Schutzplatte« ausgeschaltet werden kann, die sich beim Einschalten des Switches über den On/Off Power-Schalter schiebt. Die Port-Karten größerer Switches (32-Ports und größer) enthalten jeweils vier Full Duplex G-Ports mit 1,0625 Gigabit/Sek. (Generic Ports). Diese Ports operieren als F-Ports (Fabric-Ports) zum Anschluss an N-Ports (Node-Ports) von Fibre Channel-Endgeräten. Sie können jedoch auch als E-Ports (Expansion-Ports) zum Anschluss eines E-Ports eines anderen Switches verwendet werden, was zu einer Multiswitch Fabric führt. Die Ports unterstützen die Fibre Channel-Services Class 2, Class 3 und Class F. Weiter enthält jede PortKarte vier Standard Duplex Subscriber-Konnektoren (SC) zum Anschluss von Glasfaserkabel bei Endgeräten. In der Regel gibt es zwei unterschiedliche Typen von Port-Karten: 왘 GSM Port-Karten

G-Port Shortwave Laser mit Multi-Mode Fibre Channel-Verbindungen und

왘 GXX Port-Karten

G-Port MiXed Laser mit MiXed-Mode Fibre Channel-Verbindungen.

219

4 SAN – Hardware-Komponenten Abbildung 4.54: GSM- und GXXPort-Karten

GSM-Karte

Karten-Status-LED

GXX-Karte

Shortwave Ports Shortwave Ports Port-Status-LED

Longwave Port

Bis zu acht Port-Karten können in einen 32-Port-Switch eingebaut werden. Wird der Switch rein mit GSM-Karten bestückt, so sind 32 Verbindungen mit Kurzwellen-Multi-Mode-Laser Transmission möglich. Bei der Bestückung mit GXX-Karten existieren 24 Kurzwellen-Multi-Mode-Laser-Verbindungen sowie acht Langwellen-Single Mode-Laser-Verbindungen zum Aufbau einer Distanz-Topologie. Die größte Verfügbarkeit einer auf GXX-Karten basierenden Distanz-Topologie zwischen zwei Rechenzentren besteht in der Konfiguration zweier Switches in jedem Rechenzentrum. Jeder dieser Switches besitzt zwei GXX-Port-Karten. So können im laufenden Betrieb Ports hinzugefügt und entfernt werden oder einer der beiden Switches einer Lokation ausfallen, ohne dass der Betrieb unterbrochen wird. Die folgende Tabelle stellt die Spezifikationen und die unterstützten Übertragungsdistanzen von Laser-Ports und die Glasfasermedien dar, mit denen diese verbunden werden können. Jeder nicht für eine Port-Verbindung genutzte Port oder jede ungenutzte Port-Karte kann dafür verwendet werden, bei Ausfall eines genutzten Ports dessen Funktionen zu übernehmen. Dazu müssen lediglich die Glasfaserkabel vom ausgefallenen Port auf den bisher ungenutzten umgesteckt werden.

220


Kartentyp

Ports Transceiver

GSM

4

GXX

3

1

Unterstützte GlasfaserMedien

Distanz Connector

2–500 Kurzwellenlaser, 50/125-Micron Multi Mode Glas- Meter Non-OFC, 850 Nanometer (nm) faser

Standard SC Duplex

62,5/125-Micron 2–300 Multi Mode Glas- Meter faser

Standard SC Duplex

Kurzwellenlaser, 50/125-Micron 2–500 Non-OFC, 850 Multi Mode Glas- Meter Nanometer (nm) faser

Standard SC Duplex

62,5/125-Micron 2–300 Multi Mode Glas- Meter faser

Standard SC Duplex

Single Mode Glasfaser

Standard SC Duplex

Langwellenlaser, Non-OFC, 1310 nm

2 Meter bis 20 Kilometer

Tab. 4.1: Glasfaser/Port-Konfigurationen

Die Message Path Controller-Karte (MPC) bietet folgende Funktionalitäten: 왘 Eingebauter Fibre Channel-Port 왘 Kontrolle und Aufrechterhaltung der Kommunikation zwischen den

Ports 왘 System Clock 왘 Zentrale Kontrolle und Verteilung der Taktraten für die MPC selbst, die

Port- und die CMM-Karten Wird ein Verbindungs-Request an den Switch gerichtet, so schickt die MPC eine Message (Nachricht, Acknowledgement) mit der zentralen CMMAdresse der Frame-Daten vom empfangenden Port zu dem übertragenden Port. Weiter informiert die MPC den empfangenden Port, dass diese Message beim sendenden/übertragenden Port auch angekommen ist. Eine Standby MPC-Karte könnte im Falle eines Ausfalls der aktiven MPCKarte den Message Flow aufrechterhalten und eine konsistente System Clock darstellen, wodurch die ausgefallene MPC-Karte im laufenden Betrieb des Switches ausgetauscht werden könnte.

221


Eine der beiden MPC-Karten wird zum Zeitpunkt des Starts des Switches als aktive Karte ausgewählt, die andere wird Standby oder Backup-MPC. Wird ein Ausfall der aktiven MPC-Karte entdeckt, so wird die Kontrolle an die Backup-Karte weitergereicht. Da die MPC die Master-System-Clock-Signale für sämtliche Komponenten des Switches generiert, muss beim Failover auf die Backup-MTC sämtliche Hardware des Switches reinitialisiert werden, was einen kurzzeitigen Ausfall darstellt. Dieser kurzzeitige Ausfall bleibt jedoch für die höheren Fibre Channel-Ebenen transparent, d.h. die Anwendungen werden diesen Ausfall nicht registrieren. Die Reinitialisierung bewirkt einen Reset und Neuaufbau des Links zu jedem angeschlossenen N-Port. Dieser Failover resultiert in einen Fabric Logout/Login, der zwar für die Upper-Level Fibre Channel-Protokolle folgenlos und unterbrechungsfrei abläuft, aber zu einem Verlust sämtlicher Frames führt, die zum Zeitpunkt des Failovers in der CMM-Karte gepuffert waren. Diese müssen von den angeschlossenen N-Ports erneut übertragen werden, was jedoch automatisch erfolgt. Die Central Memory Module-Karte (CMM) stellt den Speicher des Switches dar, der von den Ports für die Speicherung und den Empfang von Frames benötigt wird. Jedem Port wird ein bestimmter Anteil dieses Hauptspeichers zugeordnet. Dieser dem Port gehörende Memory-Anteil ist in eine feste Anzahl von Frame-Buffern aufgeteilt, die für das Speichern und Abfragen von Frames verwendet werden. Ein Frame, der zu einem Port übertragen werden soll, wird von dem sendenden/übertragenden Port in einen FrameBuffer der Memories des empfangenden Ports gespeichert. Dieser fragt periodisch seinen Hauptspeicher nach empfangenen Frames ab. Das Buffer/ Hauptspeicher-Management obliegt dabei den Ports. Auch die CMM-Karten können redundant vorgehalten werden. Eine der beiden CMM-Karten wird dann zum Zeitpunkt des Starts des Switches als aktive, die andere als Backup CMM-Karte ausgewählt. Die Frames werden simultan zu beiden CMM-Karten gesendet und in den Frame-Buffern der Ports abgestellt. Zu einem gegebenen Zeitpunkt kann jedoch allein die aktive CMM-Karte die Frames an die Ziel-Ports weiterleiten. Die Backup CMM-Karte kann jedoch bei Ausfall der aktiven CMM-Karte ohne Unterbrechung die Frame-Übertragung fortsetzen, da sie die Frames simultan erhalten hat. Die einzige Auswirkung, die ein Fehler einer aktiven CMM-Karte dann hat, ist, dass die Frames, die sich zum Zeitpunkt des Failovers der CMM-Karte auf die Backup CMM-Karte noch »auf der Reise« zur CMMKarte befunden haben, vom sendenden N-Port wiederholt werden müssen. Diese Retransmission erfolgt jedoch ebenfalls automatisch. Die ausgefallene CMM-Karte kann online ausgetauscht werden und als neue Backup CMMKarte reinitialisiert werden. Die Control Processor Card (CTP) enthält den Mikroprozessor und die diesem zugeordnete Logik zur Steuerung und Kontrolle des gesamten Switches. Weiter werden zum Zeitpunkt des Startes des Switches (Power On) seitens der CTP-Karte sämtliche Hardware-Komponenten des Switches (re-)initialisiert.

222


Auf jeder CTP-Karte befindet sich ein RJ45-Twisted Pair-Anschluss mit 10/100 Mb/Sek., um diese an ein Ethernet Local Area Network (LAN) anzuschließen und mit einem Service-Prozessor oder einer Remote Simple Network Management Protocol (SNMP) Management Workstation zu kommunizieren. Dabei besitzt – aus Gründen der Hochverfügbarkeit – jede CTPKarte ihren eigenen Ethernet-Anschluss. Eine CTP-Karte besteht aus folgenden beiden Subsystemen: 왘 Der System Service Prozessor (SSP) kontrolliert den Maintenance Port, den

10/100 Mb/Sek. Ethernet Port und das Bedienerfeld des Switches. 왘 Der Fibre Channel Channel-I/O Controller (FCC-IOC) kontrolliert den ein-

gebauten Fibre Channel-Port der MPC-Karte und konfiguriert die applikationsspezifischen integrierten Schaltkreise (ASICs) des Ports. Ein unterbrechungsfreier Upgrade der Firmware oder der Tausch einer CTPKarte wird wiederum durch Einbau einer Backup CTP-Karte erreicht. Der Failover von der fehlerhaften aktiven CTP-Karte zur Backup CTP-Karte erfolgt für die angeschlossenen Node-Ports (N-Ports) absolut transparent. Die aktive CTP-Karte unterzieht sich permanent einer Selbstdiagnose. Stellt diese einen Fehler fest oder kommt es zu einem »überraschenden« Ausfall der CTP-Karte, werden die aktiven Funktionen automatisch von der Backup CTP-Karte übernommen. Die bisherige Backup CTP-Karte wird sofort der neue Master und führt einen IPL durch, jedoch ohne die Power On-Diagnosen zu durchlaufen. Der IPL selbst reinitialisiert die Hardware- und Firmware-Datenbanken nicht und führt die Operationen nach erfolgtem Failover automatisch weiter. Der Port-zu-Port Frame-Fluss wird von dem Failover nicht berührt. Ein Fan Module mit zwei Lüftern dient der Kühlung sämtlicher interner Hardware-Komponenten und bietet auch ausreichend Kühlung, falls einer der beiden Lüfter ausfällt. Ein Fan Module mit einem ausgefallenen Lüfter oder Lüftern mit eingeschränkter Leistung kann online ausgetauscht werden. Der Austausch oder der Ersatz eines komplett ausgefallenen Fan Modules muss binnen kurzer Frist, in der Regel ca. 30 Minuten, erfolgen. Ansonsten wird der Switch kontrolliert heruntergefahren, sodass keine inkonsistenten Zustände des SANs auftreten können. Power Supplies eines Switches werden ebenfalls redundant gehalten, sodass ein Power Supply ohne negative Auswirkungen ausfallen und ausgetauscht werden kann. Dabei sollten beide Power Supplies von unterschiedlichen Stromkreisen unterhalten werden. Jedes Power Supply untersucht die Stromzufuhr nach Stromschwankungen. Schwankt die Stromzufuhr außerhalb eng gesteckter Eckwerte, werden Fehlermeldungen an das Display des Bedienerfelds, ein switchinternes Ereignis-Protokoll und jede externe Control/Reporting-Station geschickt. Beide Power Supplies balancieren untereinander ihre Auslastung bei der Stromzufuhr für den Switch. Fällt eines der beiden Power Supplies aus, wird die volle Last der Stromversorgung von dem verbleibenden übernommen. Sind die Power-Fehler ernsthaft und

223


kann eine unterbrechungsfreie Stromversorgung nicht gewährleistet werden, so wird auch hier seitens des CTP und der Switch-Firmware der Switch kontrolliert heruntergefahren. Abschließend soll der Hochverfügbarkeitsaspekt bei den Switches nochmals zusammengefasst werden. Hochverfügbare Switches zeichnen sich durch die durchgängige Verwendung redundanter und dadurch während des Betriebes austauschbarer Komponenten (Field Replaceable Units FRU) aus. FRU bedeutet dabei, das der Switch während des Austausches sowohl elektrisch als auch funktional weiter betrieben wird, sämtliche Verbindungen bleiben erhalten. In einem hochverfügbaren Switch werden FRU-Paare zur Gewährleistung eines automatischen Failovers installiert, sobald ein Teil des Paares ausfällt. Dabei bleiben sämtliche zum Zeitpunkt des Ausfalls existierende Fabric Logins und die Name-Server-Registrierung intakt. Werden zusätzlich so genannte Spare-Port Cards, also quasi Cold Standby PortKarten vorgehalten, so können diese die Link-Funktionalitäten einer ausgefallenen Port-Karte nicht automatisch übernehmen. Die Glasfaserkabel der ausgefallenen Port-Karte müssen zuvor physikalisch auf die Ports der Spare-Port Card gesteckt werden, bevor diese die Link-Operation der ausgefallenen Karte fortführen kann. Folgende FRUs sind Bestandteil eines hochverfügbaren Fibre Channel-Switches: 왘 zwei parallel aktive Lüfter (Fan Module), von denen lediglich einer zur

notwendigen Kühlung des Switches benötigt wird, 왘 zwei parallel aktive Stromversorgungen (Power Module), von denen ledig-

lich eine zur Versorgung des Switches benötigt wird, 왘 eine aktive und eine passive Control Prozessor-Karte. Bei Ausfall des akti-

ven Prozessors kann der passive ohne Behinderung des Datenverkehrs die Arbeit aufnehmen. Die passive/aktive Redundanz wird auch für Online Firmware Updates verwendet; 왘 eine aktive und eine passive Message Path Controller-Karte. Das Failover

auf den passiven MPC bei Ausfall des aktiven Message Path Controllers erfolgt automatisch. Um jedoch einen einheitlichen Systemtakt für sämtliche Switchkomponenten gewährleisten zu können, der von dem jeweils aktiven MPC erzeugt wird, muss die Hardware reinitialisiert werden; 왘 ein aktives und ein passives Central Memory Module. Die Daten werden in

beide Speicher geschrieben, aber nur vom aktiven weitertransportiert. Da das passive CMM jedoch der Spiegel des aktiven CMM ist, erfolgt auch hier der Failover wieder ohne Betriebsunterbrechung.

4.3.2.2

Multi-Switch Fabrics

In diesem Abschnitt sollen die Konzepte von Fibre Channel-Switched Fabrics, bestehend aus mehreren Switches, deren Vorteile und Konfigurationsoptionen dargestellt werden. Dabei werden folgende Themen bezüglich Multi-Switch Fabrics erörtert:

224

Connectivity-Hardware 왘 Grenzen einer Fabric-Topologie 왘 Überlegungen zum Einsatz von Multi-Switch Fabrics 왘 Auswahl des Principal Switches in einer Multi-Switch Fabric. Dabei müs-

sen folgende Entscheidungen getroffen werden: 왘 Zuweisung des Fabric World-Wide-Namens (WWN) 왘 Zuweisung der Domain ID 왘 Pfad-Selektion 왘 Reihenfolge der Auslieferung von Frames (Frame Delivery Order) 왘 E-Port-Segmentierung 왘 Domain Name Service (DNS) für eine Fabric 왘 Benachrichtigung bei Änderung registrierter Status (RSCN) 왘 Zoning-Konfigurationen für verknüpfte Fabrics 왘 Zusätzliche Konzepte 왘 Port-Nummerierung 왘 Knoten 왘 Knoten und Switch-WWNs.

Eine Fibre Channel-Topologie, die aus einem oder mehreren miteinander verbundenen Switches besteht, wird als Fabric bezeichnet. Eine Multi-Switch Fabric verknüpft mehrere Switches über E-Ports zu einer (administrativen) Einheit. Dabei müssen die Fabric-Bestandteile dahingehend kooperieren, dass sie die Daten eines angeschlossenen sendenden N-Ports eines Fibre Channel-Endgeräts erhalten, diese innerhalb der Fabric über die geeigneten Switch-Ports (F-Ports und E-Ports) weiterleiten (Routing) und am korrekten N-Port eines Ziel-Endgeräts abliefern. Der Pfad der Datenübertragung durch die Fabric wird typischerweise durch die Elemente der Fabric determiniert. Der Routing-Prozess ist daher für die Benutzer transparent. Endgeräte, die mit einem der untereinander verbundenen Switches verbunden sind, können nach Fibre Channel-Definition mit jedem anderen Endgerät kommunizieren, das an den gleichen oder einen anderen der zur Multi-Switch Fabric verbundenen Switches angeschlossen ist. Das Konzept des Zonings schränkt diese universelle Sichtbarkeit sämtlicher Endgeräte füreinander ein. Eine Multi-Switch Fabric ist daher typischerweise komplex. Sie bietet die Möglichkeit, das Routing zu sämtlichen N-Ports von Endgeräten zu betreiben, die an die Fabric angeschlossen sind. Weiterhin kann mit ihr die Flow Control der Frames betätigt werden und die Anforderungen sämtlicher unterstützten Fibre Channel Services Classes kann sie auch erfüllen.

225

4 SAN – Hardware-Komponenten Abbildung 4.55: Multi-Switch Fabric mit vier 32-PortSwitches

Server

F C HB A

N

Server

F

Server

F C HB A

F E

N

E

N

Storage F A

Array

E E F F

F C HB A

N

N E E

E E

F

E E

E E

E E

E E

E E

E E

E E

E E F F

F

F C HB A

N

Linien zwischen zwei E-Ports = ISL (Inter Switch Link)

Server

F C HB A

Array

Storage F A

N

Server

Storage F A

Array

N

Die Komplexität der Multi-Switch Fabric steckt daher auch die Grenzen einer Fabric-Topologie ab. Je nach Hersteller der Switch- und Endgeräte-Komponenten existieren gängige Einschränkungen wie: 왘 Bis maximal 16 einzelne Switches werden in einer einzigen Fabric unter-

stützt. Jeder Switch in der Fabric wird durch eine eindeutige Domain ID aus dem Wertebereich 1 bis 32 identifiziert. 왘 Die Fabric muss homogen sein. Die Fabric-Elemente müssen auch homo-

gen sein. Hier werden sehr häufig herstellerbezogene Einschränkungen gemacht, z.B. können innerhalb einer Fabric nur Switches eines Herstellers und dann – noch restriktiver – lediglich 8-Port-Switches, 16-PortSwitches oder nur 32-Port-Switches eingesetzt werden. Dabei entdeckt die proprietäre Firmware der Switches, ob ein inkompatibles Element in die Fabric eingebunden werden soll. Dieses wird durch eine Segmentierung der E-Ports verhindert, die den Inter Switch Link (ISL) aufbauen. Diese Homogenitätsforderung wird (glücklicherweise) seitens der Hersteller auf Anwenderdruck Stück für Stück aufgeweicht. So berichtet die Computerwoche vom 15. 06. 2001: »Speicherhersteller EMC hat jetzt ein Programm zur Interoperabilität von Fibre Channel-Switches aufgelegt. Im Rahmen des Konzepts ‚E-Port’ wurden FC-Produkte inklusive der zugehörigen Software von Brocade (Switchhersteller, der Autor), McData (Switchhersteller, der Autor) und der hauseigenen ‚Connectrix’Switches auf ihre Interoperabilität getestet. Im Einzelnen erhielten Brocades 8- und 16-Port-Switches ‚Silkworm’, McDatas ‚ED-5000 Enterprise

226


Director’ sowie die Connectrix-Modelle ‚ED-1032’, ‚DS-16B’ und ‚DS-8B’ die Zertifizierung für den Einsatz in ein Enterprise Storage Network.«2 Switch C

Switch A F

E

F

E

E

F

E

E

E

E

E

E

E F E E

Switch B

Abbildung 4.56: ISLs und Hops in einer Multi-Switch Fabric

Switch D

E E

E

E

E

E

E

F

E

F

E E F E F

E

왘 Die Anzahl der Inter Switch Links wird begrenzt. So sind sechs ISLs je 32-

Port-Switch sowie vier ISLs zwischen einzelnen Domänen gängige Einschränkungen der Anzahl von ISLs. 왘 Der Hop Count wird gerne auf ein Maximum von einem Hop reduziert. Ein

Hop ist dabei die Anzahl von ISLs innerhalb eines Pfades durch die Fabric. Mit dieser Einschränkung folgt die Connection einer jeden Domain mit jeder anderen Domain. Der Hop Count entspricht der Anzahl der ISL-Verbindungen, die in einem einzigen Pfad durch den Switch verwendet werden, nicht der Anzahl der ISL-Verbindungen zwischen den einzelnen Fabric-Elementen. So existieren in obigem Beispiel zwei ISLs zwischen jedem Switch-Paar der Fabric, es gibt aber jeweils maximal einen Hop. Überlegungen zum Einsatz von Multi-Switch Fabrics werden zu Fragen der Implementierung und deren Reihenfolge angestellt und zwar sowohl software- als auch hardwareseitig. So müssen sämtliche Switches der Fabric in einer Fabric-Management-Software der Fabric bekannt gemacht werden. Die Switches müssen über dedizierte E-Ports durch Glasfaserkabel miteinander verbunden werden, um die ISL-Verbindungen zu ermöglichen. Bei dieser Verkabelung gilt es, 2.

»Das E-Port-Konzept – EMC zertifiziert«, in Computerwoche 24/2001 vom 15. 06. 2001, S. 35.

227

4 SAN – Hardware-Komponenten 왘 die physikalischen Charakteristika (Distanz, Transceiver etc.) und die

Performance-Anforderungen des Unternehmens/unternehmensweiten Speichernetzes, 왘 die Distanz zwischen den einzelnen Fabric-Elementen, 왘 die durch die ISLs verfügbare Bandbreite, 왘 das Load Balancing von Endgeräte-Ports an Switch F-Ports und 왘 die Einschränkung der globalen Sichtbarkeit der Endgeräte durch das

Zoning zu bedenken. Nach der Definition der Multi-Switch Fabric in der FabricManagement-Software und der physikalischen Verkabelung durch ISLs wird die Fabric durch absolut benutzertransparente Prozesse erstellt. Dabei sollten dem Designer einer solchen Fabric jedoch die generellen Prozesse bewusst sein. Die Auswahl des Principal Switches als des Primus inter Pares innerhalb der Multi-Switch Fabric. Dieser wird gewählt, wenn Switches zu einer Fabric zusammengefasst werden, wenn ein Switch in eine Multi-Switch Fabric eingebunden oder aus ihr entfernt wird oder wenn ein Principal ISL entfernt wird, indem die Steckverbindung zwischen zwei Switches abgezogen wird. Die Switches in der Multi-Switch Fabric kommunizieren über so genannte Exchange Fabric Parameter (EFP)-Frames, um den Principal Switch zu ermitteln. Dieser wird durch die Switch-Priorität – einen Konfigurationsparameter innerhalb der Fabric-Konfigurations-Dialoge der Fabric-Management-Software – vorgegeben. Der Switch mit der höchsten Priorität wird der Principal Switch. Zuweisung des Fabric World-Wide-Namens. Die Fabric-Management-Software identifiziert eine Fabric über eine Fabric-WWN (zu einer Erläuterung des WWN-Konzeptes s. unten). Die WWN der Fabric entspricht der WWN ihres Principal Switches. Wird aufgrund einer Topologieänderung der Fabric ein neuer Switch als Principal Switch ausgewählt, so wird dessen WWN automatisch die Fabric-WWN der Multi-Switch Fabric. Zuweisung der Domain-ID. Jeder Switch einer Multi-Switch Fabric wird durch eine eindeutige Domain-ID identifiziert. Die Domain-IDs werden in 24-Bit Fibre Channel-Adressen verwendet, die eindeutig Quell- und ZielPort in einer Fabric definiert. Bootet ein Switch in einer Multi-Switch Fabric, so fordert er von dessen Principal Switch eine Domain-ID an. Dabei wird als Bestandteil dieser Anforderung eine »Wunsch-Domain-ID« mitgeliefert. Ist diese Domain-ID noch nicht von einem anderen Fabric-Element belegt, so wird diese Wunsch-ID dem anfordernden Switch als Domain-ID zugewiesen. Ist die gewünschte Domain-ID jedoch bereits einem anderen Switch zugeteilt worden, so wird dem anfordernden Switch ein andere freie Domain-ID zugewiesen. Die Wunsch-Domain-ID ist ebenfalls ein Konfigurationsparameter für das Setup der Multi-Switch Fabric in der FabricManagement-Software.

228


Pfad-Selektion. Switches, die zu einer Fabric zusammengeschlossen werden, tauschen firmware-basiert automatisch Informationen aus, um die Topologie der Fabric zu ermitteln. Mit diesen Informationen werden die Übertragungspfade durch die Fabric ermittelt, die mit einem Minimum an Hops zu erreichen sind. Diese Informationen sind ebenfalls für die Fabric Services der Switches unerlässlich. Eine Endgeräteport-zu-ISL-Zuweisung erfolgt, sobald sich ein N-Port in die Fabric einwählt. Daher werden die Pfade durch die Fabric festgelegt, sobald die Topologie der Fabric definiert wird. Sie bleiben solange unverändert, wie auch die Fabric-Topologie statisch bleibt. Ändert sich jedoch diese durch Hinzufügen oder Entfernen eines Switches oder von ISLs, so bemerken die Switches der Fabric diese Topologieänderung automatisch und ermitteln – je nach Bedarf – die neuen Pfade durch die Fabric. Der Algorithmus zur Determinierung der Übertragungspfade durch die Fabric ist dabei auf sämtliche Switches der Fabric verteilt. Es bedarf daher nicht der Aktion des Principal Switches, um die Pfade durch die Fabric festzulegen, jeder Switch ermittelt seine optimalen Pfade bezüglich der anderen Fabric Switches eigenständig. Standardmäßig werden die Daten-Frames nur auf der Route durch die Fabric übertragen, die die minimale Anzahl von Hops erfordert. Fällt der ISL dieses Minimum-Hop-Pfades aus, so wird von den Switches der Fabric ein neuer Pfad errechnet. Dieser kann durchaus mehr Hops erfordern als der ausgefallene Pfad. Über diesen neuen Minimum-Hop-Pfad werden nun sämtliche Daten-Frames geroutet. Wird der ausgefallene ISL wiederhergestellt, so wird der Vorgang umgekehrt ausgeführt. Das Hinzufügen dieses neuen ISL führt zur automatischen Rekalkulation des Pfades. Der hinzugefügte ISL wird als neuer Minimum-Hop-Pfad identifiziert und zum DatenFrame Routing unverzüglich verwendet. Gibt es mehrere Pfade innerhalb der Fabric, die die gleiche Anzahl von minimalen Hops darstellen, so wird die Routing-Last durch die Firmware der Switches über diese verfügbaren ISLs wie folgt balanciert: 왘 Der Switch weist jedem E-Port, der an einen ISL angeschlossen ist, die

gleiche Anzahl von Entry-Ports (das sind entweder F-Ports oder E-Ports) zu. Hat beispielsweise ein Switch sechs ISLs und sechs angeschlossene Fibre Channel-Endgeräte, so werden über jedes die Domains verbindende ISL-Paar vier ISL- und sechs Device-Verbindungen zugeordnet. 왘 Ist der Gerätetreiber des Fibre Channel-Host-Bus-Adapters eines Servers

in der Lage, sämtlichen Host-Bus-Adaptern dieses Servers eine gemeinsame WWN zuzuweisen und wird dieses durch das Server-Betriebssystem unterstützt, so verteilt der Switch die Transferlast von Daten-Frames über mehrere ISLs, wenn der Server mehrere F-Port-Verbindungen zu einem Switch der Fabric besitzt. Dadurch wird die Verfügbarkeit des Endgeräts (hier des Servers) maximiert.

229


Reihenfolge der Auslieferung von Frames (Frame Delivery Order) Sobald ein Switch einen neuen Minimum-Hop-Pfad durch die Fabric kalkuliert, implementieren die Routing-Tabellen des Switches diesen Pfad unverzüglich. Das erfolgt automatisch auch bei bereits laufenden Übertragungen von Frames, was bedeutet, dass ein Frame einer Übertragung, der noch über den bisher kostengünstigsten Pfad übertragen wurde, zeitlich verzögert zu einem Frame am Ziel-Port ankommt, der bereits über den neuen kostengünstigsten Pfad geroutet wurde. Eine solche inkorrekte Reihenfolge der Frames beim Ziel-Port kann zu Problemen führen, da eine Vielzahl von Fibre Channel-Endgeräten Frames in falscher Reihenfolge nicht verarbeiten kann. Die Lösung für derartige Probleme bietet das Rerouting Delay, das bei der Fabric-Konfiguration in der Fabric-Management-Software aktiviert werden kann. Dieses garantiert auch für den Fall der dynamischen Rekalkulation der kostengünstigsten Pfade die Auslieferung der Datenframes in der korrekten Reihenfolge. Class 2-Frames, die während dieser Delay (Verzögerung)-Periode in die Fabric übertragen werden, werden von der Fabric zurückgewiesen, Class 3-Frames werden ohne Benachrichtigung beendet. E-Port Segmentierung E-Port-Segmentierung ist das Verfahren, das verhindert, dass Firmwareinkompatible Switches zu einer Fabric zusammengeschlossen werden können. So tauschen die Switches einer Fabric Betriebsparameter aus, um ihre Kompatibilität zu prüfen. Es kommt zu einer Segmentierung des E-Ports eines Switches, über den ein inkompatibler Switch versucht, in die Fabric »aufgenommen« zu werden. Ein segmentierter Link überträgt lediglich Class F-Verkehr, Class 2- und Class 3-Frames werden nicht übertragen. Folgende Zustände führen in aller Regel zu einer Segmentierung des E-Ports, über den ein neuer ISL aktiviert werden soll: 왘 Inkompatible oder inkonsistente Betriebsparameter zwischen den bei-

den Switches. Das sind entweder der R-A-TOV (Resource Allocation Time Out Value, gängiger Wert zehn Sekunden) oder der E-D-TOV (Error Detect Time Out Value, gängiger Wert zwei Sekunden). 왘 Duplikate der Domain-ID, d.h. ein oder mehrere Domain-IDs sind mehr-

fach vergeben. 왘 Inkompatible Zoning-Konfigurationen (vgl. unten). 왘 Auftreten eines Fabric Build-Protokollfehlers. Im normalen Betrieb kann

es nicht zu einem solchen Fehler kommen. Er wird während des automatischen Aufbauprozesses der Fabric erkannt, sobald eine unerwartete oder unbekannte Antwort eines Switches auf einen Request an den Principal Switch zurückgeliefert wird. 왘 Es existiert kein Principal Switch.

230

Connectivity-Hardware 왘 Ein Switch antwortet nicht auf einen Verifikations-Request. Jeder Switch

in einer Fabric verifiziert durch einen solchen Verifikations-Request periodisch die Betriebsbereitschaft sämtlicher Switches der Fabric. Der EPort eines ISLs zu einem Switch wird segmentiert, sobald dieser Switch nicht auf einen gesendeten Verifikations-Request reagiert. Domain Name Service (DNS) für eine Fabric In einer Multi-Switch Fabric werden Dienste, die eigentlich Switch-basiert sind, wie z.B. Name Service, Registered State Change Notifications (RSCN – Benachrichtigung bei Änderung eines registrierten Status) und Zoning, Fabric-weit genutzt. Fragt beispielsweise ein Endgerät, das an der Fabric angeschlossen ist, beim Name-Server sämtliche Devices an, die ein bestimmtes Protokoll (z.B. HiPPI) unterstützen, so bekommt der anfragende Port nicht nur sämtliche Devices des Switches angezeigt, über den er den Request an den Name-Server gestellt hat, und die das Protokoll unterstützen, sondern sämtliche Devices, die über sämtliche Switches der Fabric, die sich in der gleichen Zone wie der anfragende Port befinden und das angefragte Protokoll unterstützen. Benachrichtigung bei Änderung eines registrierten Status (Registered State Change Notification RSCN) RSCNs werden an sämtliche registrierte Endgeräte-N-Ports gesendet, die an die Fabric angeschlossen sind, sobald eines der beiden folgenden Ereignisse innerhalb der Fabric eintritt: 왘 Ein Fabric-weites Ereignis wie z.B. ein Login eines neuen Switches in die

Fabric, ein Switch Logout aus der Fabric oder eine Rekonfiguration der Fabric aufgrund eines ISL-Fehlers tritt ein. 왘 Die Zoning-Konfiguration wird geändert.

Zoning-Konfigurationen für verknüpfte Fabrics Über die Fabric-Management-Software wird Zoning Fabric-weit konfiguriert. Jede Änderung der Zoning-Konfiguration wird an sämtliche Switches der Fabric weitergereicht. Um ein Fabric-weites konsistentes Zoning zu gewährleisten, werden Regeln (vergleichbar zu Datenbanktriggern) ausgelöst, sobald ein Switch mit einem anderen Switch (zoned oder unzoned) über einen ISL verknüpft wird. Diese Regeln überprüfen die Kompatibilität der Zoning-Konfiguration der beteiligten Switches und gewährleisten somit ein konsistentes Zoning für die gesamte Fabric. Zusätzliche Konzepte, die bei der Konfiguration der Betriebsparameter in der Fabric-Management-Software berücksichtigt werden müssen, sind: 왘 Die Port-Nummerierung. Bei einem 32-Port Switch werden die Ports nor-

malerweise von 0 bis 31 durchnummeriert. Je nach Fabric-ManagementSoftware werden lediglich diese Port-Nummern angezeigt oder aber der Port-Nummer die Domain-ID vorangestellt, an der dieser Port existiert.

231

4 SAN – Hardware-Komponenten 왘 Die Nodes (Knoten). Ein Knoten ist ein an einen Switch angeschlossenes

Fibre Channel-Endgerät, z.B. ein Server oder ein Storage Array. Diese Endgeräte werden in aller Regel nicht von der Fabric-Management-Software administriert. Dabei muss jedoch berücksichtigt werden, dass die Verbindung des Switches zu diesem Endgerät sehr wohl von der FabricManagement-Software administriert wird. 왘 Die Knoten- und Switch-WWNs. Eine WWN ist eine acht Byte (16 Zahlen)

große Nummer, die einem Fibre Channel Director oder einem Host-BusAdapter oder einem Fibre Channel Interface in einem Storage Array, Server oder Switch eindeutig zugeordnet ist. Sie entspricht somit z.B. in Zuordnung und Funktion einer IP-Adresse unter Unix. Diese WWN (z.B. 10:00:01:55:43:C1:D2) wird für eine Vielzahl administrativer Funktionen in der Fabric-Management-Software benötigt (vgl. unten), ist jedoch sehr unhandlich. Daher kann für die WWN ein Alias vergeben werden, über den dann der/das Fibre Channel Director/Host-Bus-Adapter/Fibre Channel Interface erreicht werden kann.

4.3.2.3

Design von Switches und Fabrics für SANs

Topologie-Design Fibre Channel-Switches und Switched Fabrics dienen der Implementierung der in Kapitel 3 vorgestellten SAN-Topologien. 왘 Kapazitätserweiterungs-Topologie 왘 Speicherkonsolidierungs-Topologie 왘 Distanz-Topologie

in jeweils reiner oder hochverfügbarer Form. Doch wie kommt man zu welcher Topologie unter Einsatz welcher Switches/Fabrics und wie gewährleistet man, dass jedes Fibre Channel-Endgerät nur die für es selbst gedachten Endgeräte innerhalb der Fabric sieht und nicht alle an die Fabric angeschlossenen Endgeräte? Diese Fragen können nur durch intensive Planung der SAN Switch- und Switched Fabric-Topologie und des Zonings beantwortet werden.3 Diese Planung erfordert eine Analyse der jeweiligen Anwendungsumgebung auf Lösungsebene. Die wesentlichen Determinanten einer korrekten Topologieplanung sind dabei:

3.

232

In diesem Buch wird für die Planung der Topologien von einem Single-HBA-Zoning ausgegangen, einer Praxis, die jedem Host-Bus-Adapter eines Servers in Verbindung mit den Fibre Channel Director-Ports der Storage Arrays, deren Devices der HBA sehen soll, eine eigene Zone zuweist, nicht jedem Port eine FC-HBA. Single-HBA-Zoning sowie Zoning-Konzepte allgemein werden weiter unten detailliert erläutert. Für die Planung der Topologie soll diese Annahme jedoch bereits hier erwähnt werden.

Connectivity-Hardware 왘 Anzahl der Ports innerhalb der Anwendungsumgebung 왘 Gewünschter Grad der Verfügbarkeit 왘 Gewünschter Grad der Performance 왘 Administrative und applikationsspezifische Anforderungen

Der Prozess des Topologiedesigns ist iterativ. Die Erörterung jeder Determinante führt zu einem Topologieansatz, der durch die Einbeziehung der folgenden Determinante wieder in Frage gestellt wird. Die Topologie, die nach Betrachtung sämtlicher Determinanten als realisierbar erscheint, wird dann implementiert. Die Ermittlung der optimalen Anzahl von Switches für die SAN-Topologie anhand der Anzahl der Ports innerhalb der Anwendungsumgebung geschieht in folgenden vier Schritten: 1. Ermitteln der Anzahl der Fibre Channel-Host-Bus-Adapter jedes Servers, der in das zu planende SAN integriert wird (∑HBA) 2. Ermitteln der Anzahl der Fibre Channel Director-Ports sämtlicher Storage Arrays, die in das zu planende SAN integriert werden (∑FA ) 3. Ermitteln der Summe der N-Ports des SANs als Summe der Host-BusAdapter und der FC-Channel Director-Ports (∑HBA + ∑FAP = ∑N-Port) 4. Abhängig von der Wahl der Switchgröße (8 Port, 16 Port, 32 Port etc.) kann nun die benötigte Anzahl der Switches innerhalb der Fabric ermittelt werden, die benötigt wird, um diese N-Ports zu bedienen. Dabei muss beachtet werden, dass genügend Ports der verwendeten Switches für die benötigten E-Ports zum Aufbau der ISLs einer Multi-Switch Fabric berücksichtigt werden. Weiter sollten in Switches mit multiplen Port-Karten die Ports jeweils einer Karte nicht belegt und als Spare-Ports verwendet werden, um für den Fall des Ausfalls eines Ports oder einer kompletten Port-Karte dessen/deren Funktion übernehmen zu können. In dem bisher angenommenen 32-Port-Switch würden also vier Ports als Spare-Ports nicht verwendet werden, es stünden 28 Ports für den Anschluss von Endgeräten oder von anderen Switches zur Verfügung. Die Anzahl der benötigten Switches beträgt nun (∑N-Port : 28 = ∑32-Port Switches). Diese Formel gilt jedoch allein für ein SAN, das nur einen einzigen Switch benötigt, da maximal 28 N-Ports angeschlossen werden dürfen. Sobald jedoch mehr als 28 N-Ports angeschlossen werden sollen, reduziert sich die Anzahl verfügbarer F-Ports auf 26 (bei zwei Switches), 24 (bei drei Switches) und 22 (bei vier Switches), da für die ISL-Verbindung mit jedem anderen Switch in der Fabric jeweils zwei E-Ports benötigt werden. Die Überlegungen bezüglich der Verfügbarkeitsanforderungen und/oder der Performance können eine Anpassung der so gefundenen Topologie basierend auf der Anzahl der Ports erforderlich machen.

233


Die Auswahl der SAN-Topologie aufgrund des gewünschten Grades der Verfügbarkeit baut auf der Forderung auf, dass ein gutes Topologie-Design die Ausfallzeiten aufgrund einer ausgefallenen Komponente minimiert. Um dieses zu erreichen, muss das Design die Ende-zu-Ende-Kanäle berücksichtigen. Eine Analyse der Ende-zu-Ende-Verbindungen betrachtet den HBA, einen Link zu einer Switch-Komponente (Port-Karte), evtl. einen Inter Switch Link (ISL) in einer Multi-Switch Fabric, den Link (Port-Karte) zum Storage Array und den Fibre Channel Director-Port des Storage Arrays. Design-Optionen sind 왘 maximale Verfügbarkeit (gewünschte Strategie) und 왘 hohe Verfügbarkeit.

Eine maximale Verfügbarkeit wird durch die Verwendung einer Dynamic Multipathing-Strategie beim Server, zweier Switches und doppelter Fibre Channel Directors beim Storage Array erreicht. Abbildung 4.57 zeigt die Strategie der maximalen Verfügbarkeit bei der Auswahl der Topologie. Abbildung 4.57: Topologie der maximalen Verfügbarkeit

A A

F C H B A

F F E E

F A 1

F F E

B E

Storage Server

Array A

B F C H B A

E

E

E

E

F

F

FF

F

F A 2 B

Die beiden Host-Bus-Adapter seien als HBAA und HBAB bezeichnet, die beiden Switches als FCSW1 (oben) und FCSW2 (unten) sowie die beiden Fibre Channel Director-Ports als FA1A und FA2A. Daraus folgt: 왘 Auf der Server-Seite besitzt jeder Server zwei Host-Bus-Adapter und ver-

wendet eine Software, die ihm ein dynamisches Multipathing zwischen diesen beiden HBAs ermöglicht. Die physikalische Topologie ist so ausgelegt, dass HBAA mit FC-SW1 und HBAB mit FC-SW2 verbunden ist.

234

Connectivity-Hardware 왘 Auf der Seite des Storage Arrays werden die A- und B-Ports der Fibre

Channel Directors mit entsprechenden Switch-Ports (F-Ports) verknüpft, also FA-1A und FA-1B mit FC-SW1 sowie FA-2A und FA-2B mit FC-SW2. Die Topologie hoher Verfügbarkeit wird mit einem einzigen Switch erreicht, wenn die HBAA/FA1- und HBAB/FA2-Bestandteile über Port-Karten voneinander getrennt werden. Abbildung 4.58: Topologie der hohen Verfügbarkeit

A A

F C H B A

F A 1 B Storage

Server

Array A

B F C H B A

F A 2 F

B

Auf der Server-Seite besitzt jeder Server zwei Host-Bus-Adapter und verwendet eine Software, die ihm ein dynamisches Multipathing zwischen diesen beiden HBAs ermöglicht. Die physikalische Topologie ist so ausgelegt, dass HBAA und HBAB mit unterschiedlichen Port-Karten des Switches verbunden sind. 왘 Auf der Storage Array Seite werden die A- und B-Ports der Fibre Chan-

nel Directors mit entsprechenden Switch-Ports (F-Ports) auf unterschiedlichen Port-Karten verknüpft. In einer Konsolidierungs-Topologie werden die Links vom Switch zum Storage Array gleichmäßig über mehrere Port-Karten verteilt. Dadurch wird eine minimale Anfälligkeit gegenüber Komponentenausfall implementiert. Würden beispielsweise in einer SAN-Umgebung mit 16 Servern und vier Storage Array Fibre Channel Director Links die vier Storage Array Links auf eine Port-Karte gelegt, so wäre bei Verlust dieser Port-Karte in einer-Umgebung, die kein Dynamic Multipathing unterstützt und implementiert hat,

235


kein I/O zu diesem Storage Array mehr möglich, bis diese Port-Karte ausgetauscht oder die physikalische Verkabelung auf Spare-Ports umgesteckt wäre. Der gewünschte Grad der Performance ist für die Auswahl der korrekten SANTopologie keine Determinante der Switch-Seite, sondern lediglich auf der Storage Seite zu beachten. Die Zuweisung von Switch-Ports hat daher keinen Einfluss auf die Performance, da es innerhalb eines Switches keine Ressourcen gibt, die Port-zu-Port-Performance-Interaktionen erzeugen. Resultierend daraus ist die gemeinsame Benutzung von Fibre Channel-Ports auf derselben Port-Karte oder zwischen unterschiedlichen Port-Karten keine Performance-Überlegung, sehr wohl jedoch – wie bereits erwähnt – eine Verfügbarkeits-Determinante. Die Port-Zuweisung auf der Seite der Storage Arrays ist jedoch für die Performance relevant. Bei der Konsolidierungs-Topologie wird beispielsweise die I/O-Last mehrerer Host-Bus-Adapter von unterschiedlichen Servern auf einen Fibre Channel-Port eines Fibre Channel Directors gebündelt. Daher ist die Summe der Server I/O-Lasten sehr wohl eine bedeutende Determinante für die Zuweisung an geteilte Ports und die Auswahl der Fan-Out-Rate (vgl. Kapitel 3, Konsolidierungs-Topologie). Für die korrekte Planung, welche Server-HBAs, auf welche Ports eines Storage Arrays konsolidiert werden, müssen neben der Normal-I/O-Last auch Auslastungsspitzen wie z.B. Batch-Läufe und Backups in Betracht gezogen werden. Die Fan-Out-Rate für die Konsolidierungs-Topologie ermittelt sich aus der Summe der I/Os pro Sek. ( ∑IOPS ) sämtlicher Server, die an ein Storage Array angeschlossen werden sollen, in Relation zu den I/O-Durchsatzraten eines Fibre Channel Director-Ports und den durchschnittlichen Antwortzeiten solchen Ports gemäß seiner prozentualen Auslastung. Diese Werte müssen von den Herstellern des Storage Arrays beschafft werden. Aus diesen Werten lässt sich die entsprechende Fan-Out-Rate ermitteln. Dabei bedeutet eine Fan-Out-Rate von 4:1, dass vier HBAs sich einen Channel Director-Port teilen. Diese Fan-Out-Rate ist eine von vielen Herstellern von Storage Arrays empfohlene Rate, wenn genaue Werte der I/O-Last der Server nicht bekannt sind oder nur schwer abzuschätzen sind. Administrative und applikationsspezifische Anforderungen, die das Design der physikalischen und logischen Topologie des SANs beeinflussen, resultieren aus einer Administrationsstrategie oder einer Administrationsorganisation des Unternehmens, für welches das SAN entwickelt werden soll. So kann die IT-Administration eines Unternehmens nach Applikationen (Finanzbuchhaltung, Produktionsplanung und -Steuerung, CRM, Anlagenbuchhaltung), Applikationsklassen (Datenbankapplikationen, Filesystem-basierte Applikationen, File- und Print-Services, Exchange-Applikationen) oder nach Abteilungen/Arbeitsgruppen (Marketing-, Produktions-, Vertriebsoder Administrations-Applikationen) organisiert sein.

236


So sollen beispielsweise innerhalb des Unternehmens die vier Abteilungen Marketing, Produktion, Vertrieb und Administration existieren. Jede dieser Abteilungen betreibt vier Server für File-, Print-, Exchange- und DatenbankService. Bei einer Fan-Out-Rate von 4:1 (Ergebnis der Performance-Überlegungen) bedeutet dies, dass die I/O-Last von vier Servern auf vier Fibre Channel Director-Ports eines Storage Arrays konsolidiert werden muss. Eine Lösung dieser Konsolidierungs-Topologie könnte sein, sämtliche Server einer Abteilung auf einen Channel Director-Port des Storage Arrays zu konsolidieren.

Admin Exchange Server

Admin File Server

Admin Print Server

Admin DB Server

F C HB A

F C HB A

F C HB A

F C HB A

Abbildung 4.59: Abteilungsorientierte Konsolidierungs-Topologie

Port A

Port B

FC Switch

Port A

Port B

Port A

Storage F A

Array 1

Port B

Port A

Port B

Als Alternative könnten die identischen Services sämtlicher Abteilungen jeweils auf einen Storage Array-Port konsolidiert werden. Dabei wird das Topologie-Design beeinflusst von: 왘 der Administration der Speicherressourcen hinsichtlich Kapazität, Per-

formance und Connectivity, 왘 Anforderungen an die Verfügbarkeit der Services, die von den Abteilun-

gen genutzt werden, 왘 interne Organisationsstrukturen der Administration in den Rechenzent-

ren (z.B. Administrationsteams sind den Abteilungen zugeordnet oder Administrationsteams sind nach Services organisiert).

237

4 SAN – Hardware-Komponenten Abbildung 4.60: Serviceorientierte KonsolidierungsTopologie

Admin Exchange Server

Marketing Exchange Server

Prod Exchange Server

Vertrieb Exchange Server

F C HB A

F C HB A

F C HB A

F C HB A

Port A

Port B

FC Switch

Port A

Port B

Port A

Storage F A

Array 1

Port B

Port A

Port B

Sämtliche bisherigen Überlegungen zur Switch- und Fabric-Topologie des SANs waren unabhängig davon, ob die Topologie mit einem Switch oder nur mit einer Multi-Switch Fabric zu realisieren war. Folgende Überlegungen müssen zusätzlich einbezogen werden, wenn eine SAN-Lösung lediglich über eine Multi-Switch Fabric realisiert werden kann: Die Connectivity stellt die Determinante der Anschließbarkeit von Endgeräte-Ports an die Fabric dar. Wie bereits oben erwähnt, gibt es hier eine Vielzahl von Einschränkungen, die berücksichtigt werden müssen: 왘 Die Anzahl der Switches in einer Multi-Switch Fabric ist auf vier be-

schränkt. 왘 Unter normalen Produktionsbedingungen (nicht im Betrieb nach einem

Failover) ist die Anzahl gestatteter Hops auf einen beschränkt. 왘 Zwischen den Domains der Fabric sind zwei oder vier Inter Switch Links

(ISLs) erlaubt. Die durchgezogenen Linien zwischen den einzelnen Switches repräsentieren die kleinste Anzahl von ISLs zwischen den Domains (DID = DomainID), jeder Switch stellt eine eigene Domain dar (vgl. Abb. 4.61 und 4.62). Die gepunkteten Linien stellen zusätzliche ISLs dar, die die Maximalkonfiguration an Inter Switch Links von vier ISL repräsentieren. Die ISL bieten sowohl für die an die Fabric angeschlossenen Server und die angeschlossenen Speicher-Endgeräte vollständige Heterogenität. Jeder ISL kann entweder eine Kurzwellen-Laser- oder eine Langwellen-Laser-Verbindung ohne jede weitere Restriktion nutzen.

238


96-Port Fabric

64-Port Fabric FF E F E E E E

D I D

D I D

1

D I D

E E F E F E

1

E E E E

E E E E

D I D 2

E E E E

D I D

E E E E

2

3

FF E F E E E E

D I D 1

E E F E F E

D I D 3

E E E E

E E E E

E E E E

E E E E

E E E E

E E E E

E E E E

E E E E

F E F E E E

Abbildung 4.61: 64/96/128-Port Multi-Switch Fabrics

D I D

E E F E F E

F E F E E E

2 128-Port Fabric

D I D 4

E E F E F E

Balancierte Fabric-Umgebungen können aus mehreren dieser Fabric-Typen zusammengesetzt werden. Dazu sind jedoch sowohl auf Server- als auch auf Storage-Seite doppelte HBAs und Fibre Channel Directors sowie Dynamic Multipathing-Software notwendig. Die in Abbildung 4.62 dargestellte balancierte Many-to-Many Multi-Switch Fabric besteht aus zwei Fabrics maximaler Größe (128 Ports). Über Dynamic Multipathing wird das Fabric-Paar über multiple Host-Bus-Adapter und multiple Fibre Channel Directors erreicht. Load Balancing über die ISLs wird mithilfe dreier Routing-Algorithmen gewährleistet: 왘 Der kürzeste Pfad wird als erster bedient (Shortest-Path-First Algorith-

mus). 왘 Verwendung multipler, gleich langer Routing Pfade (Multiple-Equal-

Cost-Paths Algorithmus) 왘 Load Balancing über den WWNN (WWNN-Based-Balanced-Loads Al-

gorithmus)

239

4 SAN – Hardware-Komponenten Abbildung 4.62: Balancierte Manyto-Many MultiSwitch Fabrics

Server HBA

HBA

Server HBA

FF E F E E E E

E E F E F E

E E D E I E

E E E E

D E E 1 E E

E E E E

E E D E I E

E E E E

D 3

E E E E

E E E E

HBA E E D E I E

E E E E

D E

2

E 5 E E

E E E E

D I D

E E D E I E

E E E E

E E E E

E E E E

FF E F E E E E

E F E F E E

D I D

E E E F E F

4

E E F E F E

D 7

FA

D I D

E F E F E E

6 D I D 8

E E E F E F

FA Storage

FA

FA Storage

Für jeden N-Port kalkuliert jeder Switch der Fabric den kürzesten Pfad (minimale Anzahl von Hops) durch die Fabric zu jedem Ziel-N-Port. Als Hop wird jede Route durch einen ISL bezeichnet, die ein Frame innerhalb des Switches durchlaufen muss. In der Kalkulation des kürzesten Weges ist dabei die tatsächliche Distanz, die der ISL überbrückt, vollkommen unerheblich. In Abbildung 4.63 ist jeder Quell-HBA maximal einen Hop von jedem beliebigen Ziel-FA entfernt. Werden Frames eines N-Ports von Domain 1 (DID1) auf einen N-Port auf Domain vier (DID4) transportiert, so wird beim Shortest-Path-First Algorithmus einer der vier diagonalen ISLs zwischen Domain 1 und Domain 4 verwendet. Sämtliche Frames, die von diesem N-Port in die Fabric mit diesem Ziel-N-Port eintreten, werden von der Fabric über diesen ISL geroutet.4 Existieren mehrere gleich lange Pfade durch die Fabric, so verwendet ein Switch für das Load Balancing den Multiple-Equal-Cost-Paths Algorithmus und verteilt die Quell-N-Ports über die verfügbaren ISLs zum Ziel in einem Round-Robin-Verfahren gleichmäßig. Würden in obiger Abbildung vier N-Ports von Domain 1 eine Übertragung zu einem N-Port von Domain 4 initiieren, so würde jeder der vier N-Ports dediziert über einen der vier diago4.

240

Ein N-Port initiiert eine Frame-Übertragung an einen anderen N-Port. In jedem FrameHeader befindet sich die Destination ID (ZID) für das Ziel des Frames. Diese ZID ist ein Wert von 24 Bit. Die oberen acht Bit stellen die Destination Domain dar, die unteren acht Bit bezeichnen den Destination N-Port. Die Fabric verwendet diese ZID für das Routing des Frames zwischen den Domains bis hin zum Ziel-N-Port.


nalen ISLs geroutet. Die Round-Robin-Zuweisung von ISLs an die N-Ports erfolgt beim Fabric Login des N-Ports. Nicht verbundene, inaktive N-Ports besitzen keine ISL-Zuordnung. Um die Auslieferung der Frames in der richtigen (konsistenten) Reihenfolge sicherzustellen, wird für jedes QuellDomain/Ziel-Domain-Paar nur ein N-Port zeitgleich einem ISL zugewiesen.

E

E

E

E

E

E E

D I E D

E

E

E

E

1

EF F E F

F C H B A

Server

E E

F C H B A

E F E F

E

E

E

E

E

E

E

E

E

E

E

D I E D E

E

3

FA 1 F E

D I D

E

E E

E

E

E

E

Array

E E

D I D

E E

E

Storage

F E

2

4 E

Abbildung 4.63: One Hop Shortest-Path-FirstAlgorithmus

FA 2

FA 1

Storage

F E F E

Array FA 2

Der WWNN-Based-Balanced-Loads Algorithmus ist insbesondere für Fabrics geeignet, deren Server Dynamic Multipathing implementiert haben. Hierbei werden die Links des Servers dynamisch auf unterschiedliche ISLs in der Fabric geroutet, unabhängig davon, ob die Quell-N-Ports an der gleichen Domain angeschlossen sind (schlechtere Lösung) oder an unterschiedlichen Domains angeordnet sind (bessere Variante). Voraussetzung hierfür ist, dass die HBAs des Servers einen gemeinsamen World Wide Node Name (WWNN) unterstützen und dass es mehrere gleich lange ISLs durch die Fabric zu dem Ziel-N-Port gibt. Ist dies der Fall, werden die N-Ports beim Fabric Login wie beim Multiple-Equal-Cost-Paths Algorithmus über die ISLs verteilt. Das Load Balancing auf dieser Ebene wird unterstützt durch Dynamic Multipathing-Funktionalitäten der entsprechenden Server-Software. So gibt es Dynamic Multipathing-Software, die erkennt, dass die Warteschlange für I/Os auf einem HBA immer größer wird, und dann die I/Os für diesen HBA auf den HBA umleitet, dessen Warteschlange die kleinste ist. Dieser Mechanismus kombiniert mit dem WWNN Routing Algorithmus bietet automatische Load Balancing-Services gegen kurzzeitige Überlastungen der Inter Switch Links der Fabric an.

241

4 SAN – Hardware-Komponenten Abbildung 4.64: WWNN-basiertes Load Balancing

F F E F E E E F C H B A

E

D I D

FA 1 Storage

1

Array FA 2

Server

F C H B A

E

D I D

E

2

FA 1 Storage Array

F E F E

FA 2

In das Design der Topologie eines Multi-Switch Fabric SANs sollten noch folgende Überlegungen einfließen: 왘 Über die Fabric-Management-Software kann die Auslastung der ISLs in

einer Fabric basierend auf den Bandbreitenauslastungen der einzelnen E-Ports überwacht werden. Wird festgestellt, dass ein ISL beständig hoch ausgelastet ist (Auslastung über 50%), sollte das Hinzufügen weiterer ISLs zwischen beiden Domains bis zum Maximum von vier ISLs geplant werden. Da beim Hinzufügen eines ISLs die Switches automatisch die kürzesten Pfade neu ermitteln und auch die N-Ports den ISLs neu zuordnen, wird der neue ISL ohne Unterbrechung zusätzlich Bandbreite zwischen den Domains verfügbar machen. 왘 Die Strategie von maximal einem Hop beim Routing durch die Fabric

sollte – wenn möglich – stets eingehalten werden. Werden z.B. stattdessen zwei Hops für die Frameübertragung benötigt, reduziert sich die ISL-Bandbreite dadurch schon auf nur noch 50% der One-Hop-Strategie. Frame Latency und Verfügbarkeit profitieren beide von der Implementierung einer One-Hop-Strategie. 왘 Eine unterbrechungsfreie Domain Relocation kann – falls von der Fabric-

Management-Software unterstützt – dazu verwendet werden, N-Ports je nach Auslastung der Domain-ISLs auf eine andere Domain zu verschieben. Voraussetzung ist hierfür ein Zoning über die WWN, das im folgenden Abschnitt über das Zoning beschrieben wird.

242


Zoning von Switches und Fabrics Ein Aspekt, der eine Multi-Switch Switched Fabric als so mächtiges Werkzeug erscheinen lässt, ist die Tatsache, dass sämtliche Fibre Channel-Endgeräte, die an einen beliebigen Port eines Switches der Fabric angeschlossen sind, miteinander kommunizieren können. In einem Storage Area Network kann dieses jedoch zu einigen administrativen Problemen führen. Diese können z.B. normale Interoperabilitätsprobleme zwischen den Servern des SANs sein, je nach deren Typ (PC-Server vs. Mainframes). Weiter kann es notwendig sein, die Kommunikation auf dem SAN zu segmentieren, um zusätzliche Sicherheitsebenen zwischen funktionalen Gruppen von Anwendern/Anwendungen zu schaffen oder z.B. Test- von Produktionsumgebungen zu trennen.5 Das Konzept des Zonings bietet die Möglichkeit, eine Fabric in mehrere, vollständig selbstständige Entitäten – Zones genannt – zu untergliedern. Eine Zone enthält eine Menge von Fibre Channel-Endgeräten, die auf einander zugreifen können. Ein Fibre Channel-Endgerät kann dabei ein Port eines Switches sein oder der WWN (World Wide Name) eines Fibre Channel Devices, das an einem Switch-Port angeschlossen ist. Ports und Endgeräte, die innerhalb einer Multi-Switch Fabric über mehrere Switches verteilt sind, können zu einer Zone zusammengefasst werden. Die Mitglieder einer Zone können einander sehen, die Mitglieder unterschiedlicher Zonen dagegen nicht. Die Anzahl der Mitglieder einer Zone ist abhängig von der Anzahl der Zonen insgesamt, der Länge der Zone-Namen und vielen weiteren Faktoren. Durch das Zoning wird das Device Discovery eines Servers vereinfacht. Ein Switch kann sämtliche Device-Adressen sämtlicher Fibre Channel-Endgeräte entdecken, die an die Fabric angeschlossen sind. Die Zoning-Konfigurations-Informationen, die diese generelle Sichtbarkeit einschließen, werden im Name Service des Switches gespeichert. Ein Server sieht (entdeckt) dank Zoning dann nicht mehr sämtliche Fibre Channel Storage Devices, die an der Fabric angeschlossen sind als »seine« Speicher-Endgeräte, sondern »nur noch« die Storage Devices, die zur gleichen Zone gehören wie er. Dadurch soll auch die persistente »Bindung« der CTL-Devices6 über die WWNs unterstützt werden. Dieses stellt sicher, dass Hardwarefehler beim Booten eines Servers nicht dazu führen, dass die Zuordnung der Magnetplatten an »ihre« Server in einer inkonsistenten Reihenfolge erfolgt.

5.

6.

Eine der wesentlichen Mindestanforderungen an Handelssysteme für Finanzinstitute ist eben die strikte Trennung von Test- und Produktionsnetzen und Test- und Produktionssystemen. CTL = Controller-Target-LUN, bezeichnet die Mimik der Device-Bezeichnung in UnixBetriebssystemumgebungen, vgl. Kapitel 2.

243

4 SAN – Hardware-Komponenten Abbildung 4.65: Persistentes Binding der Fibre Channel Devices über WWN

c0t0d(0-15) FA WWN A Dev 0-15

SERVER Switch Fabric

c0t1d(0-15)

c0

FA WWN A Dev 0-15 c0t2d(0-15)

FA WWN A Dev 0-15 c0t3d(0-15)

FA WWN A Dev 0-15

Zoning wird in den Switches häufig basierend auf dem ANSI-Standard für Simple Name-Servers implementiert. Das führt dazu, dass die Zugriffskontrolle auf die N-Ports ebenfalls über Name-Server-Vereinbarungen gesteuert wird. Dies bedeutet, dass ein Host-Bus-Adapter niemals über einen Hardwarecheck versuchen darf, seine Speicher-Devices zu finden, sondern das Device Discovery allein über die Dienste des Name-Servers betreiben darf. Das Zoning innerhalb einer Fabric erfolgt Fabric-weit, also Switch übergreifend. Ein definiertes Zone Set ist für die komplette Fabric gültig. Wird beispielsweise in einer Distanz-Topologie ein Host-Bus-Adapter an einen Switch der Fabric im Hauptrechenzentrum angeschlossen und mit einigen Ports eines remote Switches der Fabric im Notfallrechenzentrum zu einer Zone zusammengeschlossen, so können sich auf den Switches der Fabric im Hauptrechenzentrum noch so viele Devices tummeln, erkannt werden lediglich die Devices der Zone im Notfallrechenzentrum. Das Login über den Name Service erfolgt lediglich in die Ports, die zur gleichen Zone wie der Host-Bus-Adapter gehören. Zur administrativen Vereinfachung empfiehlt sich die Praktik des Single HBA-Zonings für einen Switch, d.h. jeder Host-Bus-Adapter erhält seine eigene Zone; zu einer Zone können keine zwei Host-Bus-Adapter gehören. Bei dieser Praxis besteht eine jede Zone aus einem HBA und den Storage Array-Ports, über die die Devices des Hosts sichtbar sind.

244

Connectivity-Hardware Abbildung 4.66: Single HBA-Zoning

1 Z1=1,5

Host1

5 FA 1

2

Storage

Z2=2,5,6

Host2

6 FA 2

Z3=3,6 3

Array 7

Host3

FA 3

4 Host4

Z4=4,6,7 Switch Fabric

In Abbildung 4.66 werden vier Zonen gebildet – für jeden Host-Bus-Adapter eine. Die Zonen Z1 (Port 1 und Port 5) und Z3 (Port 3 und Port 6) stellen quasi ein Fibre Channel Direct Attachment der Devices von FA 1 respektive FA 2 des Storage Arrays an die Hosts 1 und 3 dar. Die Zonen Z2 (Port 2, Port 5 und Port 6) und Z4 (Port 4, Port 6 und Port 7) stellen jeweils einen Fan-In von 2:1 des Storage Arrays dar. Allein in Abbildung 4.66 wird jedoch schon deutlich, dass das Zoning zur Einschränkung der Device-Sichtbarkeit, zur Eindeutigkeit des Device Discovery und zur Gewährleistung der Persistenz des Bindings allein nicht ausreicht. So können sowohl Host 2 als auch die Hosts 3 und 4 über Port 6, der in sämtlichen Zonen Z2, Z3 und Z4 enthalten ist, sämtliche Devices sehen, die über den Fibre Channel Director FA 2 des Storage Arrays sichtbar sind. Um dieses zu verhindern und den Zugriff weiter einzuschränken, ist eine Server-basierte, jedoch von Name Service und Login abhängige Software ( im Folgenden DCS – Device Control Software – genannt ) vonnöten, die in Kapitel 6 dargestellt wird. Das Zoning nach der Single-HBA-Methode garantiert Performance, Effizienz und Zuverlässigkeit des Device Discovery-Prozesses. Jeder HBA kann sich nur in die Ports eines Storage Arrays einloggen, die er verwenden soll. Ist die auto mapping-Funktionalität des Device-Treibers auf BetriebssystemSeite aktiviert, werden im Filesystem des Servers auch nur CTL-Objekte für die Devices erstellt, die über diese Ports erreichbar und über die DCS für den Host-Bus-Adapter freigegeben sind. Single HBA-Zoning simuliert am ehesten eine Standard (Direct Attached) Single-Initiator SCSI-Umgebung, in der Host-Bus-Adapter sich nicht in andere Host-Bus-Adapter einwählen und keine Dienste auf Verbindungs-

245


ebene zwischen zwei Host-Bus-Adaptern existieren. Dies sorgt für eine erhebliche Reduktion von Beeinträchtigungen der SAN-Zuverlässigkeit , die bei unterschiedlichen Treiber-Revision-Levels, HBA-Typen und -Herstellern und heterogenen Servern in derselben Fabric auftreten können. Ein Host-Bus-Adapter in einer Single-HBA-Zone sieht auf dem Switch, an den er angeschlossen ist, lediglich die Nachrichten über Statusänderungen (SCN – State Change Notifications) der für ihn konfigurierten Storage Array FA-Ports. Dadurch ist auch bei einer dynamischen Fabric, bei der Switches und ISLs hinzugefügt und entfernt werden, die Device Detection und die Reaktion auf SCNs für den HBA von den Änderungen der Fabric unabhängig. Die DCS arbeitet mit dem Single HBA-Zoning Hand in Hand. Die DCS arbeitet auf der Ebene logischer Volumes (also Devices, nicht physikalischer Platten) und vergibt die Zugriffe auf die Volumes nur an die HBAs, die dafür die Berechtigung besitzen. Die DCS arbeitet nicht Switch-Port-basiert und kontrolliert damit auch nicht direkt den Discovery-Prozess für die Storage-Port-Detection. Ist in einer DCS-Umgebung das Zoning nicht nach einer Single-HBA Methode aufgesetzt, so versuchen sämtliche HBAs während des Discovery-Prozesses und zur Antwort auf SCNs sich in alle Ports der Fabric einzuwählen (Login). Dagegen wird beim Single HBA-Zoning der zeitliche Aufwand und der Fibre Channel-Protokoll-Traffic für den Discovery-Prozess und für das SCNHandling auf ein Minimum beschränkt. Dies steigert die Geschwindigkeit, die Effizienz und die Zuverlässigkeit der Fabric. Abbildung 4.67: Zoning über PortNummern oder WWN

WWNx

246

0

8

1

9

2

10

3

11

4

12

5

13

6

14

7

15

1. Zoning über Portnummern z.B. 7,8,15 Für diese Zone können nur diese Ports verwendet werden. Es können beliebige WWNs gesteckt (physikalisch verkabelt) werden. Geringe Sicherheit.

WWNy

WWNz

2. Zoning über WWNs z.B. WWNa, WWNb, WWNc Für diese Zone können beliebige Ports verwendet werden (0,1,2,4,5,6,7,8,9, 11,13,14,15). Es können keine anderen WWNs gesteckt (physikalisch verkabelt) werden. Größere Sicherheit.


Single HBA-Zoning lässt sich einfach von einer Ein-Switch- in eine MultiSwitch-Umgebung migrieren. Durch Zoning unter Verwendung der World Wide Names ist es völlig unerheblich, an welchen F-Port einer Fabric ein N-Port angeschlossen wird. Der verteilte Name-Server der Fabric entdeckt jede Veränderung sofort und macht die physikalischen Topologie-Veränderungen für die Konfigurationsvariable der Device-Treiber vollständig transparent. Zoning kann entweder 왘 über WWNs (World Wide Names) oder 왘 über Port-Nummern

erfolgen. Um ein Zone-Mitglied anhand seines World Wide Names (WWN) zu identifizieren, muss der WWN des Devices, das an den Channel Director-Port angeschlossen ist, angegeben werden. Ein WWN besteht aus 16 Zeichen und sieht beispielsweise wie folgt aus: 10:00:06:02:66:40:C0:D4

Der WWN wird einem Host-Bus-Adapter oder einem Fibre Channel Director eines Server- oder Storage-Fibre-Channel-Endgeräts zugewiesen. Obwohl der Server oder das Storage Array selbst einen eigenen Knoten-WWN besitzt, wird dieser nicht für das Zoning verwendet, sondern der WWN des HBAs oder des Channel Directors. WWNs von HBA und Channel Directors können auch Aliase zugewiesen werden und das Zoning kann dann über diese Aliase erfolgen. Dies hat den Vorteil, dass bei Wechsel eines defekten HBAs nicht die komplette ZoningDatenbank für den Tausch der WWNs von defektem HBA auf neuen HBA geändert, sondern lediglich an einer Stelle in der Fabric-Management-Software die Definition des Alias an den neuen WWN angepasst werden muss. Für die Identifikation eines Zone-Mitglieds anhand des WWNs des angeschlossenen Endgeräts gibt es zwei wesentliche Argumente: 왘 Die Identifikation der Mitglieder der Zone ändert sich nicht, wenn die

WWNs der Mitglieder physikalisch auf andere Ports gesteckt werden müssen, da z.B. eine Port-Karte einen Defekt hat. 왘 Wie bereits oben erwähnt, existiert eine Strategie, eine ISL-Überlastung

in einer Multi-Switch Fabric dadurch zu verhindern, dass Port-Paare mit einer hohen Auslastung auf eine gemeinsame Domain (auf denselben Switch) verschoben werden. Dieses Verschieben ist bei WWN-basiertem Zoning ohne Änderung von Device-Treiber-Konfigurationen möglich.

247


Port-basiertes Zoning sollte, wenn möglich, daher aus folgenden Gründen vermieden werden: 왘 Die Reparatur einer Port-Karte bei Verwendung von Spare-Ports (ma-

chen das Umstecken des physikalischen Kabels notwendig) erfordert bei Port-basiertem Zoning eine Änderung des Zone-Sets. 왘 Verändert sich die Domain-ID eines Switches, wenn z.B. bisher allein ste-

hende Switches (alle Domain-ID 1) zu einer Multi-Switch Fabric rekonfiguriert werden, so sind die Zoning-Informationen ungültig. Dies kann zur Datenkorruption von Frames existierender Links führen. 왘 Die Beseitigung der ISL-Überlastung durch das Verschieben von hoch

ausgelasteten Port-Paaren auf eine gemeinsame Domain kann nicht automatisch erfolgen. Das Verschieben dieser Links ohne Anpassung der Port-Zoning-Informationen kann zu Datenkorruptionen bei Frames aktiver Übertragungen führen. Port-basiertes Zoning wird manchmal als Lösung dafür angesehen, den Austausch von HBAs ohne Änderungsnotwendigkeit für die Zoning-Informationen durchführen zu können. Dieses Argument ist jedoch nicht vollständig durchdacht. Der Austausch eines HBAs erfordert eine Änderung der DCSDatenbank. Mit dem Port-basierten Zoning ist somit der Swap eines HBAs ohne Anpassungen nicht möglich. Da empfiehlt es sich doch eher, das WWN-basierte Zoning mit WWN-Aliasen zu verwenden. Dies lässt beim HBA-Tausch die DCS-Datenbank und die Zoning Informationen unverändert und erfordert lediglich die Anpassung des Alias an den neuen WWN. Werden Fabrics durch ISLs zu einer Multi-Switch Fabric zusammengefasst, so gilt die aktive Zoning-Konfiguration für die komplette Fabric. Jede Änderung der Zoning-Konfiguration ist für sämtliche an die Fabric angeschlossene Endgeräte wirksam. Wenn zwei Fabrics über einen ISL miteinander verbunden werden, tauschen die Switches der Fabric ihre Zoning-Konfigurationen aus, um zu entscheiden, ob diese kompatibel sind und miteinander verschmolzen werden können. Ist die Zoning-Konfiguration beider Fabrics kompatibel, so werden diese über ISL verknüpft. Die aus der Verknüpfung resultierende Konfiguration ist ein einziges Zone-Set mit Zoning-Konfigurationen aus beiden ehemals allein stehenden Fabrics. Können die beiden Fabrics aus Inkompatibilitätsgründen nicht miteinander verknüpft werden, so werden die beiden beteiligten E-Ports segmentiert. Das bedeutet, dass diese keinen Transfer für an die Fabric angeschlossene Endgeräte transportieren können (Class 2 oder Class 3 Service), jedoch Management und Kontroll-FC-Traffic sehr wohl übernehmen können (Class F Service). Die Zoning-Konfigurationen zweier Fabrics sind stets kompatibel, wenn Zonen gleichen Namens in beiden ursprünglichen Fabrics die gleichen Mitglieder besitzen.

248


Fabric A

Fabric B

Ergebnis

UnZoned

UnZoned

Die Fabrics werden erfolgreich miteinander verknüpft. Das Zoning in der resultierenden Multiswitch Fabric bleibt UnZoned.

UnZoned

Zoned

Die Fabrics werden erfolgreich miteinander verknüpft. Fabric A »erbt« das Zoning der Fabric B.

Zoned

UnZoned

Die Fabrics werden erfolgreich miteinander verknüpft. Fabric B »erbt« das Zoning der Fabric A.

Zoned

Zoned

Die Fabrics werden nur miteinander verknüpft, wenn das Zoning der beiden Fabrics kompatibel ist. Andererseits wird auf jedem Switch der E-Port segmentiert – die Fabrics bleiben separat. Die Fabrics werden stets miteinander verknüpft, wenn die Zonen beider Fabrics dieselbe Bezeichnung und dieselben Mitglieder haben.

Tab. 4.2: Verknüpfung von Fabrics – Folgen für das Zoning

Tabelle 4.2 fasst die Regeln zur Verknüpfung von Zoned Fabrics zusammen. Dabei bedeuten die Begriffe Zoned

UnZoned

Zoning

Ein Zone-Set ist in der Fabric aktiv. In diesem Zustand können Fibre Channel Devices andere Devices erkennen, die in der gleichen Zone enthalten sind. Es gibt in der Fabric kein aktiviertes Zone-Set. Dies bedeutet, sämtliche Fibre Channel-Endgeräte können sämtliche anderen Endgeräte an der Fabric erkennen. Kombination aus einem aktiven Zone-Set und dessen Aktivierungszustand (freigeschaltet oder abgeschaltet, enabled oder disabled)

Führt der Versuch, zwei Fabrics miteinander zu verknüpfen, zu einer E-PortSegmentierung und können die Fabrics daher aufgrund ihrer ZoningInkompatibilitäten nicht via ISL zu einer Multi-Switch Fabric verbunden werden, kann die Verknüpfung der beiden Fabrics dadurch erzwungen werden, dass das Zone-Set einer der beiden Fabrics zuvor disabled wird. Dies beseitigt sämtliche potentielle Verknüpfungs-Konflikte, da die resultierende Fabric dann lediglich das Zoning der enabled verbliebenen Fabric erhält. Nach dem Join der Fabrics können dann über die Fabric-Management-Software Anpassungen on Demand an dem Zoning der Multi-Switch Fabric vorgenommen werden.

249

5

Hochverfügbare NASHardware-Komponenten

Network Attached Storage (NAS) verwendet die Speicherkapazitäten der SANUmgebungen, 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 dem möglichst schnellen Zugriff auf die gespeicherten Daten oder die Gewährleistung deren Verfügbarkeit gelten, sondern es wird 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 ihren Vertretern und auch den Maklern und potentiellen Kunden eine Internet-gestützte Auswahl von Verträgen bieten. Weitere Beispiele können 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 SANUmgebungen und nutzen daher auch deren Hochverfügbarkeitspotential. Für sämtliche-Umgebungen ist jedoch eines gemein: Der Druck zur Vereinfachung der System-Komplexität, zur Standardisierung und Reduktion der IT-Kosten führt dazu, dass Unternehmen durchgängige, konsistente Informationsstrukturen aufbauen. Anstatt also File-Servern die Direct Attached Storage Arrays zuzuordnen und deren Filesysteme über das Netzwerk an Clients freizugeben, werden in modernen unternehmensweiten Informationsstrukturen natürlich die Vorzüge existierender Investionen in SAN Storage- und Switching-Hard- und Software genutzt und dahingehend ausgebaut, dass sie sämtlichen Clients innerhalb des Unternehmens verfügbar gemacht werden. Weiter muss eine konsistente durchgängige Informationsstruktur gewährleisten, dass unabhängig von zu Grunde liegenden Betriebs- und Dateisystemen eine uniforme Administration der Informationen, seien es nun auf MVS, Unix oder Windows NT/Windows 2000 basierende Informationen, zu gewährleisten. Ziel ist es, sämtliche Speicherkapazitäten des Unternehmens als einzelne, von allen Unternehmens-Clients geteilte, Ressourcen zu allokieren und zu administrieren.

251

5 Hochverfügbare NAS-Hardware-Komponenten Abbildung 5.1: Konsistente unternehmensweite Informationsstruktur

Un te rn e h m e n s we ite s S p e ic h e rn e tzwe rk (ES N)

F A

Storage Array

U S N

NAS -S e rve r

FC-S witc h

Un te rn e h m e n s we ite r S to ra g e p o o l

Un te rn e h m e n s we ite Co n n e c tivity - Ha rd wa re

Un te rn e h m e n s we ite Clie n ts

Um dies zu erreichen, müssen über alle Systeme und Plattformen hinweg folgende gemeinsame Prozeduren verwendet werden: 왘 Gemeinsame Prozeduren zum Sharing der Daten 왘 Gemeinsame Prozeduren zum Schutz der Daten vor unberechtigtem Zu-

griff und Verlust 왘 Übergreifende Prozesse für die Gewährleistung der Datenverwaltung

und der Systemadministration Diese gemeinsamen Prozeduren werden für unterschiedlichste Anwendungssystem-Umgebungen verwendet: Klassische Industrieanwendungen 왘 Unterstützungen von CAD/CAM-, CAE-, ECAD-Werkzeugen und

Werkzeugen zur Softwareentwicklung 왘 Produktionsplanungs- und Steuerungssysteme 왘 Datenbank-basierte CRM- und ERP-Systeme

Klassische Finanz- und Bank-Dienstleistungen 왘 Systeme zur Entscheidungsunterstützung 왘 Computergestützte Handelssysteme 왘 Softwareentwicklung 왘 Forecasting, Simulationen und Modellierungen 왘 Bild- und Dokumentenverarbeitung

252

Klassische Softwareentwicklung 왘 Source-Code und Library-Verwaltung 왘 Change Management-Anwendungen 왘 Modellierung und Simulation von Forschungs- und Entwicklungspro-

zessen 왘 CASE

Telekommunikationsanwendungen 왘 Softwareentwicklung und -Test 왘 CRM- und Billing-Systeme 왘 Angebot von Internet-Dienstleistungen 왘 CASE

Windows NT und PC-Konsolidierung 왘 Automatisierung von Bürokommunikations-Systemen 왘 CRM-Systeme 왘 Entscheidungsunterstützungs-Systeme

Internet- und Web-Dienstleistungen 왘 Internet Service Providers 왘 Internet Content Providers 왘 Softwareentwicklung, -Modellierung und -test

Nahezu jedes maßgebliche Unternehmen in einem der oben dargestellten Märkte setzt große File-Server-Systeme ein. Dabei fällt auf, dass die am stärksten wachsenden Anwendungen dieser Unternehmungen Network Storage Applications darstellen. Die zum Zeitpunkt der Drucklegung des Buches am stärksten wachsenden Anwendungen waren: 왘 Bildverarbeitungs-Applikationen (klassische Videoanwendungen) 왘 Data Warehousing 왘 Network File-Services 왘 E-Mail Services 왘 Data Mining 왘 E-Commerce 왘 Enterprise-Portale

253

5 Hochverfügbare NAS-Hardware-Komponenten 왘 Multimedia-Anwendungen 왘 NT- und Linux-Speicher-Konsolidierung

Network Attached Storage (NAS) unterstützt diese Anwendungen durch die Adressierung der Hauptanforderungen, die all diesen Anwendungen gemein sind: 왘 Vereinfachter Zugriff auf die Informationen 왘 Gesteigerte Verfügbarkeit der Informationen 왘 Optimierung der Ausnutzung der Speicher-Investionen 왘 Konsistente Datenhaltung

Dabei wurzeln diese Hauptanforderungen in den Problemkreisen, die ebenfalls allen oben genannten Applikationsumgebungen gemein sind: 왘 Gemeinsames File Sharing von Unix- und NT-Dateisystemen ist in der

Zwischenzeit unabdingbar. Es gibt keine homogenen Systemumgebungen mehr. Dateien der gängigen Betriebssystem-Dateisysteme müssen interoperabel sein. 왘 Ausfälle von File-Servern gefährden den Unternehmenserfolg. 왘 Das Wachstum der gemeinsam zu verarbeitenden Informationen über-

steigt die Kapazität eines einzigen File-Servers um ein Vielfaches. 왘 Werden parallel mehrere File-Server eingesetzt, führt dies zu Problemen

hinsichtlich der Gewährleistung dauernder Verfügbarkeit, zu einem Anstieg der Komplexität der Verwaltung der File-Server und zu einem skalierten Anstieg der Kosten für die Hardware und die multiple Lizenzierung der eingesetzten Software. Nutzen Unternehmen also die Vorzüge des Network Attached Storage, so finden sie sich recht bald auf einem so genannten mission critical-Level des eingesetzten Storages, der von den eingesetzten NAS-Produkten entsprechend berücksichtigt werden muss. Sämtliche Hochverfügbarkeitsaspekte, die wir im Rahmen der Server, Storage Arrays und Fibre Channel-Switches betrachtet haben, müssen ebenfalls für die File-Server des NAS gelten. Redundante Hardware in Kombination mit automatisierbarer Software müssen automatische Failover-Szenarien im Katastrophenfall unterstützen. Mit wachsenden Anforderungen an den Network Attached Storage eines Unternehmens wird es immer weniger damit getan sein, die Speicheranforderungen durch beständiges Hinzukaufen von File-Servern zu befriedigen. Hier werden die Funktionalitäten erforderlich, die – wie im Teil über Storage Array des Kapitels vier dieses Buches beschrieben – Remote Mirroring und Flexible Mirrors für Disaster-Recovery und Business Continuity-Szenarien bieten; hier werden hochverfügbare File-Server benötigt, die mit ebenso

254

hochverfügbaren Storage Arrays verbunden sind, auf deren Devices die von den File-Servern verwalteten und verfügbar gemachten Dateien gespeichert werden. Solche hochverfügbaren NAS-Server-Systeme bieten daher folgende Eigenschaften und Merkmale, die sie von herkömmlichen File-Servern unterscheiden. 왘 Hohe Verfügbarkeit des File-Servers und des an diesen (über Fibre Chan-

nel) angeschlossenen Storage Arrays. Diese wird durch die redundante Architektur beider NAS-Storage-Komponenten sichergestellt. 왘 Hohe Performance (Datendurchsatz) durch ein I/O-optimiertes File-Server-

Betriebssystem, mehrpfadigen Datentransfer vom Storage Array zum File-Server und vom File-Server zum Client und leistungsfähige CacheSysteme auf Storage Array und File-Servern. 왘 Schneller Restart im Falle eines Ausfalles des File-Servers oder des Storage

Arrays. Diese Fast Restart-Funktion wird durch Protokollierung von Metadaten je Dateisystem realisiert. Diese Metadaten enthalten auf Dateisystemebene Informationen, welche Datenblöcke wie verändert wurden. Aus dem Protokoll der Metadaten können bei Restart geänderte Dateisysteme wiederhergestellt und lang laufende File-System-Checks vermieden werden. Die Protokollierung der Dateisysteme entspricht der Funktionalität eines Unix journaled file systems. 왘 Datensicherheit durch batteriegepufferte File-Server und Storage Array-

Hardware. Die Batterien der Hardware-Komponenten sind so ausgelegt, dass sie bei Stromausfall ein kontrolliertes Shutdown der Komponenten ermöglichen. 왘 Sicherung der Investitionen durch Systemskalierbarkeit. NAS-Server be-

stehen aus standardisierten Hardware-Komponenten, die so ausgelegt sind, dass sie auch evolutionäre Übergänge auf neue Technologien ermöglichen. Dabei stellen diese NAS-Server-Systeme 왘 Front-End-Prozessoren für Storage-Systeme der gängigen Hersteller dar,

die 왘 zumindest das Industriestandard Network File System (NFS) von Sun

(gängigstes File Sharing-System im Unix-Umfeld) und das Industriestandard Common Internet File System (CIFS) von Microsoft (gängigstes File Sharing-System im Umfeld von Microsoft Windows NT) unterstützen; 왘 eine Speicherlösung dar, die den direkten Zugang zu den Dateien und

deren Übertragung über das Netzwerk ermöglicht, 왘 dedizierte extrem leistungsfähige File-Server dar.

255

5 Hochverfügbare NAS-Hardware-Komponenten

5.1

Architektur hochverfügbaren NAS

Hochverfügbarer Network Attached Storage ist durch die Verwendung skalierbarer und modularer Standard-Hardware-Komponenten gekennzeichnet. So werden folgende Konfigurationen für die File-Server verwendet: 왘 Motherboards mit (in der Regel) Intel Pentium III- oder Pentium-4-Pro-

zessoren mit bis zu 1 GHz Taktrate und bis zu mehreren GB RAM 왘 Interne PCI oder ISA-Busse 왘 UWD SCSI oder FC-SW für die Kommunikation mit dem Storage Array 왘 Standard NICs (Network Interface Cards) für Ethernet, FDDI, ATM (OC-

3 mit 155 MB/Sek. Bandbreite) 왘 In der Regel Spezialbetriebssysteme wie z.B. DART (Data Access in Real

Time), die Standard-Betriebssysteme wie Windows NT oder Linux für (Fibre Channel) I/O optimieren Als Control Stations werden ebenfalls Industriestandard-PCs eingesetzt. Sie dienen dem Systemmanagement und der Systemkonfiguration über Administrations-Software, die auf Linux- oder Windows NT/Windows 2000 basiert. Hochverfügbare NAS-Server enthalten meist als Komponenten: 왘 Redundante Stromversorgung (Power Supplies und Stromkabel an zwei

getrennten Stromkreisen) und Kühlung 왘 Redundantes Battery Backup 왘 Redundante interne Kommunikation zwischen den Kontroll-Stationen

und den File-Servern und zwischen den File-Servern untereinander 왘 Industriestandard-Motherboards der File-Server und Control-Stations 왘 Industriestandard-PCI-Bus oder ISA-Bus 왘 Industriestandard-Netzwerkkarten zum Anschluss externer Mainte-

nance 왘 UWD SCSI-Adapter-Karten oder Fibre Channel-Karten zum Anschluss

an die SCSI- oder Fibre Channel Directors der Storage Arrays 왘 Mehrere autonome »hot changeable« File-Server 왘 Automatisches Failover auf Hot Spare (Standby-) File-Server 왘 Gigabit Ethernet, Ethernet, FDDI, ATM Anschluss der Netzwerk-Clients 왘 Automatisches Multipath Load-Balancing 왘 Automatischer Multipath Failover 왘 Redundante Control Station (eine aktive, eine hot standby) mit automati-

schem Failover

256

Architektur hochverfügbaren NAS Abbildung 5.2: Grundaufbau eines NAS-Servers

Cooling Fileserver

Fileserver

Fileserver

Fileserver

Fileserver

Fileserver

Fileserver

Fileserver

Fileserver

Fileserver

Fileserver

Fileserver

Fileserver

Fileserver

Control Station

Control Station

Battery Backup Power Supply

Die Verwendung von Industriestandard-Komponenten wird dadurch dokumentiert, dass sowohl File-Server wie auch Control Stations nahezu identisch aufgebaut sind. Die Prozessoren sind Standard-Intel-Prozessoren. Redundante Netzwerkkarten zu den Kundennetzwerken, die ATM, Ethernet, Gigabit Ethernet oder FDDI-Kommunikation ermöglichen, sind sowohl in den File-Servern als auch in den Control Stations vorhanden. In den FileServern werden diese zur Verbindung mit den Clients der File-Services verwendet, in den Control Stations zum Anschluss der Control Station an ein Kunden-Administrationsnetzwerk. Redundante Fast-Wide-DifferentialSCSI- oder Fibre Channel-Host-Bus-Adapter-Karten dienen dem Anschluss der File-Server an das Storage Array des NAS-Systems. Eine in der Regel nicht redundant ausgelegte Fast-Wide-Differential-SCSI- oder Fibre Channel-Host-Bus-Adapter-Karte dient dem Anschluss der Control Station an das Storage Array. Auf dem Storage Array lagern die Boot-Platte der Control Station und die Boot Devices der von der Control Station administrierten FileServer.

257

5 Hochverfügbare NAS-Hardware-Komponenten Abbildung 5.3: Komponenten eines NAS-Servers

ATM, Ethernet, FDDI

ATM, Ethernet, FDDI

oder FC

Fileserver

Fileserver

Fileserver

Fileserver

Fileserver

oder FC

Fileserver

Fileserver

Fileserver

Fileserver

Fileserver

Fileserver

Fileserver

Fileserver

ATM, Ethernet, FDDI

F R E I

Control Station PCI Slots

Battery Backup Power Supply

FWDSCSI oder FC

Primäre Control Station ATM, F Ether- R net, E FDDI

I

I

PCI Slots

F R E I

P A R A L L E L

Intel D Pentium III E oder 4 mit bis zu Inte1 GHz grierte Taktrate I/O und bis zu Key1 GB C bd. RAM O Maus M 1+2

Internes Ethernet

ATM, F Ether- R net, E FDDI

I

PCI Slots

258

F R E I

I Intel D Pentium III E

P A R A L L E L

oder 4 mit bis zu Inte1 GHz grierte Taktrate I/O und bis zu Key1 GB C bd. RAM O Maus

ISA Slots

V G A

M 1+2

Internes Ethernet

F R E I

Internes Ethernet

ISA Slots

V G A

F R E I

EEther- thernet net

P A R A L L E L

I D E

Intel Pentium III oder 4 mit bis zu 1 GHz Integrierte Taktrate I/O und bis zu Key1 GB COM bd. 1+2 Maus RAM

Internes Ethernet

Internes Ethernet

ISA Slots

V G A

F R E I

P

Internes Ethernet

P O W E R C O N V E R T E R

Sekundäre Control Station (Optional)

FWDSCSI oder FC

S P A R E

Fileserver

Control Station

FWDSCSI oder FC

S P A R E

Intel Pentium III oder 4 mit bis zu 1 GHz Integrierte ISA PCI Slots Taktrate I/O Slots und bis zu Key- InIn1 GB COM bd. ter- terFWDFWD1+2 Maus nes nes RAM SCSI SCSI

Cooling

Abbildung 5.4: Anbindung der NAS-ServerKomponenten an das Storage Array

P A R A L L E L

I D E

F R E I


AP S S P ATM, ATM, AP S S P ATM, ATM, I I RA R A PA P PPSSPPSSOOPP ATM,EtherEtherATM, EtherATM,EtherATM, S P W S O P I I LL AL RA R AAPPAAPPA EtherATM, net, D EtherATM, net, Intel S S O P A P W ATM, net, EtherD L L A R AR P A R ATM,Intel net, EtherPSA E PSW OP ATM, net, EtherFDDI ATM, net, EtherFDDI Intel Pentium III E DDIEL IE L L AR A A R PSA E PSW OP R ATM, EtherFDDI net, AR ATM, EtherFDDI net, Pentium III E DIL E L L E Intel APR R APE WO RR E EtherFDDI net, A EtherFDDI net, L Pentium III Intel oder 4 L E APR R APE WO IL E EA R E Ether-net, net, FDDI Etheroder 4Intel Pentium III E D RAR EW E C net, FDDI FDDI D L EL LLLE L EERA net, Intel oder 4 Pentium III mit bis zu E A R RAR EW E C net, FDDI FDDI D net, FDDI Pentium III E mit bis zuIntel oder 4 L ER O ERC RE E L ISA FDDI FDDI Integrierte III E mit Pentium bis zu oder 4 1GHz ER O ERC RE L E ISA FDDI FDDI Integrierte III oder 4 1GHz mit Pentium bis zu E E EO CR N L ISA Integrierte PCI Slots 4 1GHz mitoder bis zu Taktrate I/O E EO CR N Slots Integrierte PCI Slots ISA 4 mitoder bis zu Taktrate 1GHz I/O V N OC Slots PCI Slots ISA mit bis zuIntegrierte Taktrate 1GHz und I/O V N OC Slots PCI Slots ISA mit bis zuIntegrierte 1GHz und Taktrate I/O E V NO Slots Integrierte PCI Slots bis und ISA 1GHz Taktrate zu I/O V NO E Slots Integrierte PCI Slots bis und ISA In- In-Slots 1 GHz KeyTaktrate zu I/O R E VN PCI Slots1 GB In- InKeybisTaktrate zu C und I/OterVN PCI Slots1 GB In- TRREEV In- ter-Slots und bisTaktrate zu C bd.KeyI/OterFWD- FWDter-Slots In- T R EV In1 GB bisund zuO C bd.Keynes nes FWD- FWD- RAM ter-In- ter-Inbd.Keybisund zuO CMaus 1 GB T RE nes nesterFWD-SCSI FWD- RAM SCSI ter-E InInbd.EKey1bis GBzu E T RE nesternesESCSI FWD-SCSI FWD- RAM MzuO CMaus terInInbd. KeyMaus bis 1 GB RAM R E TR E- nesEnes SCSI SCSI FWDFWD- RAM oder oder M O C therterterInInKeybd. E TR R EE- thernes nes FWDFWD- 1 1GB oder oder SCSI SCSI 1+2M OC Maus terbd. GB thertherR ET E- terE-net nes nes FWDFWD- RAM SCSI SCSI FCoder FCoder 1+2M OC Maus terterbd. Maus thertherR ET E-nes E-net nes FWDFWD- RAM SCSI SCSI FCoder FCoder MO net nettherRAM1+2 therE-nes RE E-net nes SCSIFCoder SCSI FCoder 1+2MO Maus net Maus thertherRE EESCSIFCoder SCSI FCoder 1+2 M nettherE- R E-nettheroder FC oder FC M 1+2 net therther-net R oder FC oder FC 1+2 net net ther- therFC FC 1+2 net net FC FC net net

Fileserver P O W E R C O N V E R T E R


Storage Array

Architektur hochverfügbaren NAS

Die Tastatur- und Maus-Ports und die VGA-Grafikkarte werden für die FileServer in aller Regel nicht verwendet. Bei Control Stations werden die Tastatur- und Maus-Ports sowie die Ausgänge der Grafikkarten über einen Multiplexer an einen im Schrank befindlichen Laptop oder eine externe Administrations-Workstation verbunden, über den/die die Administration von Control Station und File-Servern auch ohne Einbindung in ein KundenAdministrationsnetzwerk durchgeführt werden kann. Primäre Control Station ATM, F Ether- R net, E FDDI

I

I

PCI Slots

FWDSCSI oder FC

F R E I

P A R A L L E L

Intel D Pentium III E oder 4 mit bis zu Inte1 GHz grierte Taktrate I/O und bis zu Key1 GB C bd. RAM O Maus M 1+2

Internes Ethernet

P

Internes Ethernet

ISA Slots

V G A

F R E I


AP S S P ATM, ATM, AP S S P ATM, ATM, I I RA R A PA P PPSSPPSSOOPP ATM,EtherEtherATM, ATM,EtherEtherATM, S P W S O P I I LL AL RA R AAPPAAPPA ATM, Ethernet, D ATM, Ethernet, Intel S P W S O P A ATM, Ethernet, D ATM, Ethernet, L A RR Intel P L A P P S SW OP A A R E E EtherATM, net, FDDI EtherATM, net, FDDI Intel Pentium III E DDIL IE L L A RRAR A A R PSA E PSW OP EtherATM, net, FDDI EtherATM, net, FDDI Intel Pentium III E DIL E L L E APR R APE WO RR E net, EtherFDDI net, EtherFDDI Pentium III E DIL E L AL E oder 4Intel APR R APE WO net, EtherFDDI A R E net, EtherFDDI L Intel Pentium III oder 4 L E R R A E E CAR EW LE L FDDI net, FDDI D net, Pentium III Intel oder 4 mit bis zu L E R RAR EW A E E E C L FDDI net, FDDI net, Pentium III ED EL L ER O oder 4 mit bis zuIntel RC RE FDDI FDDI Integrierte ISA ER EO oder 4 III E mit Pentium bis zu 1GHz ERC RE L E ISA FDDI FDDI Integrierte oder 4 III mit Pentium bis zu 1GHz E E NEO CR L ISA Integrierte PCI Slots mitoder bis zu 4 1GHz Taktrate I/O E EO CR N Slots Integrierte PCI Slots ISA mitoder bis zu 4 1GHz Taktrate I/O N OC V Slots PCI Slots ISA 1GHz mit bis zuIntegrierte Taktrate und I/O V N OC Slots PCI Slots ISA 1GHz mit bis zuIntegrierte Taktrate und I/O E V NO Slots Integrierte PCI Slots bis und ISA Taktrate 1GHz zu I/O E Slots Integrierte PCI Slots bis und ISA V NO In- In-Slots Taktrate 1 GHz Keyzu I/O PCI Slots1 GB In- In- RREEVN Keyund bisTaktrate zu C I/O N ter-In- ter-Slots PCI Slots1 GB In- T R EV und bisTaktrate zu C bd.KeyI/O V FWD- FWDter-In- ter-Slots InKeybd. bis zu und 1 GB RAM T R EV nester-nes FWD- FWD- RAM O C Maus ter-InInbd.Keybisund zu 1 GB T RE nes nesterFWD-SCSI FWD- RAM SCSI O C Maus ter-E InInKeybd.E1bis GBzu E T R E Enes nes FWD-SCSI FWD- RAM SCSI C M O terterInInKeybd. Maus 1bis GBzu E TR R E- nesEnes FWDFWD- RAM SCSI SCSI oder oder M O C therterterInInKeybd. E TR R E- therEnes nes FWDFWD- 1 1GB SCSI SCSI oder oder 1+2M OC Maus terbd. GB thertherR ET E-net E- ternes nes SCSI SCSI FWDFWD- RAM FCoder FCoder 1+2M OC Maus terternet bd. Maus thertherT R E EEnes nes SCSI SCSI FWDFWD- RAM FCoder FCoder O M 1+2 net net RAM 1+2MO Maus thertherE-nes RE E-net nes SCSIFCoder SCSI FCoder nettherMaus therRE ESCSIFCoder SCSI FCoder M 1+2 netEtherE- R E-nettherFC oder FC oder M 1+2 net therther-net R FC oder FC oder 1+2 net therther-net FC FC 1+2 net net FC FC net net



I

PCI Slots

FWDSCSI oder FC

F R E I


P A R A L L E L

oder 4 mit bis zu Inte1 GHz grierte Taktrate I/O und bis zu Key1 GB C bd. RAM O Maus M 1+2

Internes Ethernet

Internes Ethernet

ISA Slots

V G A

F R E I

Abbildung 5.5: NAS-Server: interne Administration


M U L T I P L E X E R

CD-ROM

CD-ROM

Das NAS-Server-interne Ethernet ist redundant aufgebaut. Es existieren zwei interne Netzwerke. Jeder File-Server ist mit je einer Ethernet-Karte an jedes der beiden internen Ethernets angebunden, ebenfalls jede Control Station. Über das interne Ethernet werden die File-Server von der aktiven Control Station gebootet und die NAS-Server-interne Clock vereinheitlicht. Weiter dient das interne Ethernet der beständigen Zustandskontrolle der File-Server durch die Control Station. Eine der beiden Control Stations ist die aktive. Solange sie fehlerfrei funktioniert, ist die zweite lediglich ein HotStandby-System. Sämtlicher interner Netz-Traffic erfolgt über die aktive Control Station. Fällt diese jedoch aus, so wird die bisher sekundäre Control Station ohne Ausfall aktiv. Die gesamte interne Kommunikation wird nun über diese Control Station betrieben.

259


An den IDE-Karten der Control Stations werden Diskettenlaufwerke angeschlossen, über die Treiberänderungen geladen und die Konfigurationsdaten des NAS-Servers extrahiert werden können. Die Basisinstallation der Software und umfangreichere Softwareupgrades werden in der Regel über die CD-ROM eines internen Administrations-Laptops oder einer externen Workstation durchgeführt. Weiter muss die redundante Stromversorgung der NAS-Server erklärt werden. Über die Parallel-Schnittstellen-Karten der Control Station(s) werden Kommunikations-Karten angeschlossen, die beständig Status-Informationen von den aktiven Komponenten der Stromversorgung: 왘 Externe Stromversorgung (Stromnetz und Notstromversorgung) 왘 Powerkonverter des Schrankes 왘 Battery Backup und 왘 Powerkonverter der File-Server und Control Stations

abfragen. Abbildung 5.6: NAS-Server – Internes Ethernet und Stromversorgung

Primäre Control Station P


I

I

PCI Slots

F R E I

FWDSCSI oder FC

P A R A L L E L

Intel D Pentium III E oder 4 mit bis zu 1 GHz Integrierte Taktrate I/O und bis zu Key1 GB C bd. RAM O Maus M 1+2

Internes Ethernet

Internes Ethernet

ISA Slots

V G A

F R E I


Diskettenlaufwerk

net

Sekundäre Control Station (Optional) Diskettenlaufwerk


I

PCI Slots

FWDSCSI oder FC

F R E I

AP S S P ATM, ATM, S S P RAP ATM, ATM, AP P S P S O P I EtherATM,EtherATM, P S O P I I AL RA R A PAAP PPSA EtherATM,EtherATM, P S S O P W R net, EtherATM, A D net, EtherATM, L Intel A S P W S O P I LE L L A RRPAAAP APR net, EtherATM, D net, EtherATM, Intel A P P S SW OP E I FDDI net, EtherATM, FDDI net, EtherATM, Pentium III E DDL IE L L A RRAR Intel A A R PSA E PSW OP FDDI net, EtherATM, FDDI net, EtherATM, Pentium III E DIL E L L E Intel APR R APE WO RR E FDDI net, EtherFDDI net, Etheroder 4Intel Pentium III E DIL E L AL E APR R APE WO FDDI net, Ethernet, Etheroder 4Intel Pentium III E D L E LL AERRE E R A AR EW C FDDI net, FDDI FDDI net, mit bis zuIntel Pentium oder 4 III E D L LE L E RAE C RAR EW FDDI net, FDDI net, mit bis zu oder 4 Pentium III Intel L E E E R RC RE E O L ISA FDDI FDDI Integrierte 1GHz oder 4 III E mit Pentium bis zu E ERC RE R O L E ISA FDDI FDDI Integrierte 1GHz mit Pentium bis zu4 oder III E E NEO CR L ISA Integrierte PCI Slots Taktrate mitoder bis zu 4 1GHz I/O E EO CR N SlotsISA V N Integrierte PCI Slots Taktrate 1GHz mitoder bis zu 4 I/O OC Slots PCI Slots ISA und 1GHz mit bis zuIntegrierte Taktrate I/O V N OC Slots PCI Slots ISA und Taktrate 1GHz mit bis zuIntegrierte I/O E V NO Slots Integrierte PCI Slots bis und ISA zu Taktrate 1GHz I/O E V NO Slots Integrierte PCI Slots bis und ISA zu Taktrate 1 GHz KeyI/OIn-In- In-InR E VN Slots PCI Slots1 GB Keyund bisTaktrate zu C I/O VN ter-In- ter-Slots PCI Slots1 GB In- TRREEV bisTaktrate zu C bd.Keyund I/O FWD- FWDter-In- ter-Slots In- T R EV bisund zuO C bd.Key1 GB nesternes FWD- FWD- RAM ter-InInbd.Key1 GB bisund zuO CMaus T RE nes nesterSCSI FWD-SCSI FWD- RAM ter-E InInKeybd.E1bis GBzu E T RE nesEnesterSCSI FWD-SCSI FWD- RAM MzuO CMaus terInInMaus bd. Key1bis GB R E TR EE- nes nes oder oder SCSI SCSI FWDFWD- RAM C M O terterInInbd. KeyMaus RAM 1 GB thertherR E TR E- nes E- nes oder oder SCSI SCSI FWDFWD1+2M OC Maus terterbd. 1 GB thertherR ET E-net E- nes nes FCoder FCoder SCSI SCSI FWDFWD- RAM 1+2M OC net terterMaus bd. thertherR ET E-nes E-net nes FCoder FCoder SCSI SCSI FWDFWD- RAM MO nettherRAM1+2 therE-nes RE E-net nes FCoder SCSIFCoder SCSI 1+2MO Maus nettherMaus therRE EFCoder SCSIFCoder SCSI 1+2 M netEthertherE-net E- R FC oder FC oder 1+2 M net net thertherR FC oder FC oder 1+2 net net thertherFC FC 1+2 net net FC FC

I

P A R A

Intel D LL E Pentium III E L oder 4 mit bis zu 1 GHz Integrierte Taktrate I/O und bis zu Key1 GB C bd. RAM O Maus M 1+2

Internes Ethernet

Internes Ethernet

ISA Slots

V G A

F R E I

net


Kommunikations-Karte

Powerkonverter des Schrankes

Kommunikations-Karte

Battery Backup

Externe Stromversorgung

Die Ports COM1 und COM2 werden wie die Tastatur- und Maus-Ports und die VGA-Grafikkarte für die File-Server in aller Regel nicht verwendet. In der Control Station werden COM1 und COM2 für Incoming- und OutgoingModem-Verkehr genutzt. Outgoing Modem-Verkehr entsteht, wenn sich der NAS-Server via Modem »nach Hause« auswählt. Dabei stellt das »zu Hause« einen zentralen Supportpunkt des NAS-Herstellers dar. Zu einem Ruf nach extern kommt es stets dann, wenn irgendeine Komponente des

260

Aufbau und Funktion der Control Station

NAS-Systems einen Hardwarefehler aufweist. Vom zentralen Supportpunkt aus werden dann seitens der NAS-Hersteller sämtliche Aktionen des Kundendienstes gestartet und koordiniert, sodass viele Anwender von ihrem Problem noch gar nichts bemerkt haben, wenn bereits der Techniker des Herstellers zur Behebung des Fehlers angekommen ist. Die redundanten ATM-, Ethernet-, Gigabit-Ethernet- oder FDDI-Karten werden dazu verwendet, die File-Server an das Anwendernetzwerk anzuschließen. Jeder File-Service Client kann über diese Schnittstelle dann die für ihn freigegebenen Filesysteme des File-Servers »mounten« und bearbeiten. Primäre Control Station P



I

PCI Slots

FWDSCSI oder FC

F R E I

P A R A L L E L

oder 4 mit bis zu 1 GHz Integrierte I/O Taktrate und bis zu Key1 GB C bd. RAM O Maus M 1+2

Internes Ethernet

Internes Ethernet

ISA Slots

V G A

F R E I



MODEM


I

PCI Slots

FWDSCSI oder FC

F R E I

I

P A R A L L E L

Intel D Pentium III E oder 4 mit bis zu 1 GHz Integrierte Taktrate I/O und bis zu Key1 GB C bd. RAM O Maus M 1+2

Internes Ethernet

Internes Ethernet

ISA Slots

V G A

F R E I

AP S S P ATM, ATM, S S P RAP ATM, ATM, AP P S P S O P I EtherATM,EtherATM, O P I A RA R A P P SSPPSW EtherATM,EtherATM, S O P net, EtherATM, D I I LL L A RA ARAPPAAPPA net, EtherATM,Intel A P S S O P W net, EtherATM, DD IE L L ARAR P A R net, EtherATM,Intel PSA E PSW OP FDDI net, EtherATM, FDDI net, EtherATM, L Pentium III Intel L E DL IE L L RARA A R PSA E PSW OP FDDI ATM, net, EtherFDDI ATM, net, EtherIntel Pentium III E E E R R A A P PE WO E R I R L FDDI net, EtherFDDI net, Etheroder 4Intel Pentium III E DDIL E L AL E APR R APE WO EtherFDDI net, A R E EtherFDDI net, L Pentium III oder 4 Intel L E E C RAR EW FDDI net, FDDI mit bis zuIntel oder 4 III EDDL EL LE L EERA Pentium RAE C RAR EW net, net, FDDI net, FDDI oder 4 mit bis zuIntel Pentium III E L ER O ERC RE E L ISA FDDI FDDI Integrierte 1GHz mit bis zu oder 4 Pentium III E L E ISAER O ERC RE FDDI FDDI Integrierte mit Pentium bis zu 1GHz oder 4 III E E EO CR N L Integrierte PCI Slots ISA Taktrate 1GHz mitoder bis zu 4 I/O E NEO CR Slots Integrierte PCI Slots ISA 1GHz Taktrate mitoder bis zu 4 I/O SlotsISAVVNNOC PCI Slots und Taktrate 1GHz mit bis zuIntegrierte I/O OC Slots Integrierte PCI Slots ISA Taktrate und 1GHz mit bis zuIntegrierte I/O E V NO Slots PCI Slots bis und ISA zu Taktrate 1GHz I/O E V NO Slots Integrierte PCI Slots bis und ISA zu Taktrate 1 GHz KeyI/OIn-In- InR E VN Slots PCI Slots1 GB InKeybisTaktrate zu C und I/O R E VN Slots terterPCI Slots InInbd. KeybisTaktrate zu C 1 GB und I/Oter-In- ter-Slots FWD- FWD- RAM In-TTRREV 1 GB bisund zuO C bd.KeyEV nester-nes FWD- FWD- RAM ter-InInbd.Key1 GB bisund zuO CMaus T RE nesternes SCSI FWD-SCSI FWD- RAM ter-E InInMaus bd.EKey1bis GBzu E T RE nesternesESCSI FWD-SCSI FWD- RAM M O C terInInMaus bd. Key1 GB bis zu E T R EEnesternes oder oder SCSI SCSI FWDFWD- RAM M O C Maus terIn-E R Inbd. KeyGB thertherR TR EEnes nes oder oder SCSI SCSI FWDFWD- 1 1+2 M O C terterbd. RAM 1 GB thertherR ET E- nes E-net nes FCoder FCoder SCSI SCSI FWDFWD- RAM 1+2M OC Maus terterMaus bd. thertherR ET E-nes E-net nes FCoder FCoder FWDFWD- RAM SCSI SCSI 1+2MO net netthertherE-nes RE E-net nes FCoder SCSIFCoder SCSI 1+2MO Maus nettherMaus therRE E- net ESCSIFCoder SCSI FCoder 1+2 M net thertherR EEFC oder FC oder 1+2 M net ther-net therR oder FC oder FC 1+2 net therther-net FC FC 1+2 net net FC FC net net

Abbildung 5.7: NAS-Server – Einbindung in das Anwendernetzwerk


MODEM

5.2

Aufbau und Funktion der Control Station

Hochverfügbare Control Stations bestehen aus folgenden Hardware-Komponenten: 왘 Motherboard, in der Regel Intel Pentium-III oder Intel Pentium 4 mit bis

zu 1 GHz Taktrate und bis zu 1 GB internem Hauptspeicher 왘 Ein oder (idealerweise) zwei Ultra Wide Differential (UWD) oder Fast

Wide Differential (FWD) SCSI Host-Bus-Adapter-Karten oder zwei Fibre Channel-Switched Fabric (FC-SW) Host-Bus-Adapter-Karten für den Anschluss der Control Station an das Storage Array des NAS-Systems.

261

5 Hochverfügbare NAS-Hardware-Komponenten 왘 Zwei Ethernet LAN-Karten für das redundante interne Ethernet-Netz-

werk zur Kommunikation mit den File-Servern. 왘 Eine Netzwerk Interface Card (NIC) zum Anschluss an das externe An-

wendernetzwerk (ATM, Gigabit Ethernet, Ethernet oder FDDI). Diese Komponente ist bei Control Stations oft nicht redundant vorhanden, da davon ausgegangen wird, dass die Control Station über das Anwendernetzwerk höchstens zentral verwaltet wird und daher ihre Funktion nicht verlorengeht, wenn die NIC ausfällt. Die Administration der Control Station und des NAS-Servers ist durch den internen Laptop oder die über das Console Multiplexer Board angeschlossene externe Administrations-Workstation weiterhin gegeben. Dennoch kann auch ein kompletter Schwenk auf eine Failover Control Station stattfinden, wenn der Zugriff auf das Anwendernetzwerk verloren geht und eine Hot-Standby Control Station vorhanden ist. 왘 Ein Server Interconnect Board (SIB) als interne Brücke zum restlichen

NAS-Server-System 왘 Ein Diskettenlaufwerk für die Softwareinstallation und als Medium zur

Kopie der Konfiguration 왘 Ein Anschluss eines CD-Laufwerks und einer externen Administrations-

Workstation über das Console Multiplexer Board Der Zugang zur Control Station wird ermöglicht durch einen 왘 Local Access über ein Command Line Interface (CLI) von der System-

konsole des internen Laptops oder der externen Administrations-Workstation, 왘 Local Access durch System-Start und System-Shutdown, 왘 Local Access durch eine grafische Benutzerschnittstelle (GUI) von der

Systemkonsole des internen Laptops oder der externen AdministrationsWorkstation, 왘 Remote Access über Telnet oder Rlogin von jeder Workstation innerhalb

des Anwendernetzwerkes, 왘 Remote Access über ein Java-basiertes Browser-GUI (vgl. dazu Kapitel

acht dieses Buches). Die allgemeinen Aufgaben der NAS-Control Station(s) lassen sich wie folgt beschreiben: 왘 Software-Installation, Konfiguration und Verwaltung des kompletten

NAS-Servers, d.h. der Control Station(s) und der File-Server. 왘 Ermittlung und Darstellung der Auslastung und Performance der File-

Server. Dies erfolgt je nach zu Grunde liegendem Betriebssystem der File-Server und Control Station(s) mithilfe vergleichbarer, in aller Regel Unix-basierter Befehle, weil beliebte Betriebssysteme für den Einsatz in File-Servern neben Windows NT eben die Unix-Derivate SCO UnixWare, Red Hat Linux und S.U.S.E. Linux sind.

262

Aufbau und Funktion der Control Station 왘 »Phone Home«-Funktionalität des »nach Hause« Auswählens über Mo-

dem bei fehlerhaften Hardware-Komponenten oder Software-Fehlern, die zu Fehlfunktionen des/der File-Server führen. 왘 »Dial In«-Funktionalität, die es ermöglicht, von Remote über Modem

Wartungsleistungen nach einem »Phone Home« des NAS-Servers durchzuführen. Control Stations sind »Hot Plug«-fähig, das heißt, sie können ohne Einfluss auf die Funktion der File-Server im laufenden Betrieb ausgetauscht werden. 왘 Die Kommunikation zu den File-Servern erfolgt über die internen Ether-

net-Netzwerke in aller Regel über rpc (Remote Procedure Call). Jede Control Station hat Zugriff auf ihre Boot-Platte auf dem Storage Array. Diese Boot Platte sei als Control Disk bezeichnet. Layout und Bezeichnung der Control Disk sind stark herstellerabhängig. Im Folgenden wird auf Layout und Bezeichnung von EMC2 Celerra File-Servern zurückgegriffen. Dies erfolgt nicht, um die Produkte des EMC2-Mitbewerbers wie z.B. die NetApp 760-Produktfamilie, die IBM Shark-Familie oder auch die EMC2-interne Konkurrenz der CLARiiON-Produktfamilie zurückzusetzen. Die Control Disk ist eine physikalische Platte auf dem Storage Array und in folgende sechs Volumes aufgeteilt, die durch einen physikalischen Spiegel auf dem Storage Array (RAID 1) oder durch RAID S abgesichert sein können: Vol. 00

Betriebssystem-Volume für Control Station 0 (aktive Control Station). Dieses Betriebssystem kann entweder SCO Unix oder Red Hat Linux sein.

Vol. 01

Betriebssystem-Volume für Control Station 1 (für die optionale, passive Control Station). Dieses Betriebssystem kann entweder SCO Unix oder Red Hat Linux sein.

Vol. 02

Das NAS-Volume enthält die Boot-Platte für sämtliche File-Server und die Control Station sowie für jeden File-Server und jede Control Station des NAS-Servers das Root-Filesystem.

Vol. 03

Die Systemdatenbank des NAS-Systems. Diese enthält die komplette Konfiguration des NAS-Systems, wie z.B. welcher File-Server ist über welche Switch-Ports an welche Fibre Channel Director-Ports des Storage Arrays angeschlossen und kann welche Devices sehen. Weiter sind Informationen darüber enthalten, welche Dateisysteme auf den Devices liegen, ob Hot-Standby File-Server konfiguriert sind, die im Falle eines File-Server-Fehlers den Betrieb übernehmen usw. Abschließend ist auf Vol. 03 der Swap Space sämtlicher File-Server lokalisiert.

Vol. 04

Journal der Filesystem-Transaktionen. Dieses Volume dient dem schnellen Recovery bei Filesystemfehlern. Sämtliche Operationen mit dem Filesystem, durch die Blocks des Dateisystems verändert werden, werden hier protokolliert. Dieses Journaling der Filesystem-Aktivitäten ist insbesondere von großem Vorteil, wenn via Flexible Mirrors eines Storage Arrays des NAS-Systems

263


Backup-Lösungen angewandt werden, die wir im Rahmen der Beschreibung des Storage Arrays bereits dargestellt haben (siehe Kapitel 4 dieses Buches, vgl. aber auch unten). Vol. 05

Abbildung 5.8: NAS-Server Control Disk

Enthält sämtliche Protokolldateien und Ereignis-Protokolldateien des NAS-Servers Control Station 1 optional

Control Station 0

Fileserver 1 Fileserver 2

Volume 00


Volume 01


Volume 02


Volume 03

Fileserver 9 Volume 04 Fileserver 10 Fileserver 11

Volume 05


Volume 06

Fileserver 14

Auf Volume 00 greift lediglich die primäre aktive Control Station (Control Station 0) zu. Auf Volume 01 greift nur – falls vorhanden – die passive Control Station 1 zu. Die Boot-Sektion des Volume 02, sowie die Systemdatenbank des Volume 03 und die Protokolldateien der Volume 05 enthalten ausschließlich Steuerungs- und Management-Informationen und werden daher nur von der aktiven oder der passiven Control Station bearbeitet. Die Root-Filesysteme der NAS-Partition des Volume 02 sowie die Transaktionsjournale der Veränderungen der Filesysteme auf Volume 04 werden dagegen von dem jeweiligen File-Server gelesen und aktualisiert. Bei der Konfiguration der Control Disk Volumes und der Volumes auf dem Storage Array für die einzelnen File-Server gilt es, folgende Überlegungen anzustellen und zu berücksichtigen. 왘 Die Split-Größe und damit die Volume Größe der sechs Volumes für die

Control Disk der Control Station(s) müssen gleich groß sein. 왘 Die Volumes (Devices) der Control Disk sollten zumindest mit einem lo-

kalen Spiegel (RAID 1) abgesichert sein.

264

Aufbau und Funktion eines File-Servers 왘 Für die File-Server wird empfohlen, die Devices auf dem Storage Array,

die von ihnen bearbeitet werden, ebenfalls optimal abgesichert zu halten (RAID S, lokaler Spiegel oder remote Spiegel). 왘 Sämtliche Devices (Volumes) sollten via FC-SW sämtlichen File-Servern

sichtbar gemacht werden. Dies ermöglicht ein Übernehmen der Funktionalitäten eines ausgefallenen File-Servers durch einen anderen, noch aktiven. Abbildung 5.9 zeigt die wesentlichen Verzeichnisse in der Verzeichnisstruktur einer Control Station mit einem Unix-Derivat als Betriebssystem (Volume 02 der Control Disk). /nas

bin

dos

sbin - PlattformKommandos - FileserverKommandos - NetzwerkKommandos

lock

server

http

- Install oder - Upgrade - Setup-Slot

bin

Abbildung 5.9: NAS-Server – Unix-Verzeichnisbaum des Volume 02 der Control Disk

Bspw. /var/adm/log/osmlog -> Bootmeldungen

- Slot 1 - Slot 2 - Slot 3 - ... - Slot n

conf

log

sys

volume

man

INSTALL.LOG

bin

docs

log

disks

slices

volumes

filesystems boot.cfg

Serverdateien

Server-1

Server-2

Server-n

Slot-2

Slot-3

Server-1 enthält: - Dateien für Server-2 - Ifconfig-Kommandos - Diese werden von den Fileservern beim Bootvorgang gelesen!

5.3

Aufbau und Funktion eines File-Servers

Folgende Hardware-Komponenten sind Bestandteil eines File-Servers und werden durch Redundanz für Hochverfügbarkeits-Fileservices verwendet. 왘 Die File-Server als Ganzes sind in aller Regel unterbrechungsfrei im lau-

fenden Betrieb austauschbare (hot Swappable) FRUs (Field Replaceable Units). 왘 Motherboard, in der Regel ein Intel Pentium-III oder Intel Pentium 4 mit

bis zu 1 GHz Taktrate und bis zu 1 GB internem Hauptspeicher

265

5 Hochverfügbare NAS-Hardware-Komponenten 왘 Zwei Ultra Wide Differential (UWD) oder Fast Wide Differential (FWD)

SCSI Host-Bus-Adapter-Karten oder zwei Fibre Channel-Switched Fabric (FC-SW) Host-Bus-Adapter-Karten für den Anschluss des File-Servers an das Storage Array des NAS-Systems 왘 Zwei Ethernet LAN-Karten für das redundante interne Ethernet-Netz-

werk zur Kommunikation mit der aktiven Control Station. 왘 Eine Netzwerk Interface Card (NIC) zum Anschluss an das externe An-

wendernetzwerk (ATM, Gigabit Ethernet, Ethernet oder FDDI). Diese Komponente ist bei Control Stations oft nicht redundant vorhanden, da davon ausgegangen wird, dass die Control Station über das Anwendernetzwerk höchstens zentral verwaltet wird und daher die Funktion der Control Station nicht verloren geht, wenn die NIC ausfällt. Die Administration der Control Station und des NAS-Servers ist durch den internen Laptop oder die über das Console Multiplexer Board angeschlossene externe Administrations-Workstation weiterhin gegeben. Dennoch kann auch ein kompletter Schwenk auf eine Failover Control Station stattfindet, wenn der Zugriff auf das Anwendernetzwerk verloren geht und eine Hot-Standby Control Station vorhanden ist. Für File-Server ist die NICKarte jedoch redundant vorhanden, da über diese eben im Gegensatz zu den Control Stations keine Administration des File-Servers stattfindet, sondern die File-Services an die angeschlossenen Netzwerk-Clients dargeboten werden. Hier ist die Redundanz der Funktionskomponente NIC-Karte unerlässlich. 왘 Ein Server Interconnect Board (SIB) als interne Brücke zum restlichen

NAS-Server-System Gängige Konfigurationen der File-Server gestatten den Einsatz unterschiedlicher Mixturen aus NIC-Karten, um unterschiedliche Netzwerk-Clients bedienen zu können. So können, wie oben erwähnt, je File-Server zwei NICKarten konfiguriert werden. Diese können sein: 왘 2 Quad-Ethernet 10/100 Base T Ethernet-Karten. Wird ein NAS-Server mit

z.B. maximal 14 integrierten File-Servern voll mit Quad-Ethernet NICs bestückt, so werden von diesem 112 Ethernet-Ports zum Anschluss an ein oder mehrere Netzwerke zur Verfügung gestellt. 왘 2 FDDI NICs 왘 1 ATM NIC und 1 Quad-Ethernet NIC 왘 1 Gigabit-Ethernet NIC und 1 Quad-Ethernet NIC

Weitere Merkmale der File-Server lassen sich wie folgt zusammenfassen: 왘 Die File-Server des NAS-Servers übernehmen den Datentransfer zwi-

schen dem Anwendernetzwerk und dem Storage Array des NAS-Servers. 왘 Sie besitzen ein eigenes multi-threaded Betriebssystem, das für schnellen

Datentransfer optimiert wurde.

266

Aufbau und Funktion eines File-Servers 왘 Die Software wird beim Booten der File-Server von der Control Station

gedownloaded. Dabei funktioniert die Control Station quasi als Anwendungs-Server, da sowohl die Control Station als auch die File-Server Diskless Workstations darstellen. Die Daten werden de facto von Volume 02 der Control Disk auf dem Storage Array des NAS-Servers beim Bootvorgang geladen. 왘 Die Konfiguration der File-Server erfolgt mithilfe der Management-Soft-

ware der Control Station. 왘 Die Kommunikation zwischen File-Server und Control Station erfolgt

über die internen Ethernet Netzwerke via Remote Procedure Call (rpc). 왘 Der File-Server re-bootet sich selbst, wenn Softwarefehler erkannt werden

(Bootzeit weniger als 100 Sek.). Diese kurze Reboot-Zeit erklärt sich aufgrund der Protokollierung der Filesystem-Transaktionen in Volume 04 der Control Disk. Durch dieses als Metadata Logging bezeichnete Journaling der Filesystemaktivitäten kann auf die Standard-fsck-Routine des UnixDateisystems bei großen Dateisystemen verzichtet werden. Da die Veränderungen des Dateisystems im Volume 04 protokolliert werden, müssen beim Reboot lediglich diese Veränderungen geprüft werden – der fsck muss nicht über das komplette (evtl. sehr große) Filesystem laufen. Dadurch reduzieren sich die Reboots auf durchschnittlich weniger als 100 Sek. Dauer. 왘 Filesysteme können bei NAS-File-Servern in der Regel dynamisch online

vergrößert werden, ohne dass eine Sicherung mit darauf folgendem Unmount, Vergrößern und Remount des Filesystems mit nachfolgendem Rückladen der Sicherung erforderlich ist. 왘 Die SCSI- und/oder Fibre Channel-Verbindungen zwischen File-Server

und Storage Array können mit Dynamic Multipathing ausgelegt werden, sodass ein dynamisches Load Balancing zwischen den verfügbaren Kanälen stattfinden kann. Weiter können die redundanten Kanäle auch bei Ausfall eines Kanals als Backup-Kanal die Funktion des ausgefallenen unverzüglich, d.h. benutzertransparent, übernehmen. 왘 Für den Fall, dass ein File-Server komplett ausfällt (z.B. bei Bruch des

Motherboards etc.), kann der NAS-Server so konfiguriert werden, dass ein automatisches Failover auf einen Hot Spare File-Server stattfindet. Dieser Hot Spare File-Server übernimmt nun die Netzwerkadressen des ausgefallenen File-Servers, sodass die Datendienste der Clients von dem Ausfall nicht betroffen werden. Die Clients können weiter betrieben werden, ein Reboot ist nicht erforderlich. Der Wechsel des aktiven auf den Hot Spare File-Server bleibt für den Anwender transparent. Die Softwareaspekte zur Administration der Control Stations und der FileServer, das Volume-Management auf dem NAS-Storage Array, die unterstützten Dateisysteme, die Administration des Control Station und FileServer Failover sowie die Unterstützung von Flexible Mirrors und Remote Mirroring und damit die Einbindung von NAS und SAN in ein unter-

267


nehmensweites Speichernetzwerk sollen im Kapitel 8 dieses Buches tiefer gehend beleuchtet werden. Abschließend wird in diesem Kapitel noch auf klassische NAS-Applikationen eingegangen. Abbildung 5.10: NAS-Server: FileServer Dynamic Multipathing

CL1

Fileserver 1 (P1, S2)

fs1

fs1 fs1

fs2

fs1

fs2

fs2

fs2

fs1

fs2

Fileserver 2 (S1, P2) CL2

5.4

NAS-Applikationen

5.4.1

Windows NT oder Windows 2000Serverkonsolidierung

Klassische Windows NT- oder Windows 2000-Umgebungen werden von ihren Anwendern häufig dahingehend beschrieben, dass in der Beschaffung und im Wachstum ihre Serversysteme günstig und skalierbar seien, dagegen in den Total Cost of Ownership, die auch die Kosten des Betriebs (Lizenzgebühren, Aufspielen neuer Softwarereleases, Soft- und Hardware-Wartung, Administrationskomplexität und -Aufwand) beinhalten, sehr schnell als ausgesprochen teuer erscheinen. Weiter stellt die Datenkonsistenz und das File Sharing über Windows NT und Windows 2000 eine immer wieder interessante Herausforderung dar. Eine Lösung des Problems scheint da die Serverkonsolidierung von NT-Servern zu sein.

268

NAS-Applikationen

NT-Server

NT-Server

NT-Server

NT-Server

F C HB A

F C HB A

F C HB A

F C HB A

Abbildung 5.11: NT-ServerKonsolidierung in einem FC-SW SAN

Port A

Port B

FCSwitch

Port A

Port B

Port A

Storage F A

Array 1

Port B

Port A

Port B

Die Server-Konsolidierung könnte, wie schon in Kapitel 3 dieses Buches beschrieben, über Shared Channels mithilfe eines Switches geschehen. Dies würde zwar den Magnetplattenspeicher der NT-Server und -Clients konsolidieren, dabei würde jedoch jeder NT- oder Windows 2000-Server seine Daten auf seinen Devices des Storage Arrays abspeichern und zugreifen, wie sie ihm von der Zugriffs-Software freigeschaltet worden ist. Sharing der Daten ist über diese Variante nicht zu erreichen. Wesentliche Ziele einer wahrhaftigen Windows NT- oder Windows 2000-Server-Konsolidierung sind jedoch: 왘 Transparentes Sharing der Daten und Dateien sowohl durch Windows

NT, Windows 2000 als auch Unix-Clients 왘 Weiterverwendung der bisherigen Windows NT oder Windows 2000

File-Server als Applikations-Server 왘 Entlastung der Systemadministratoren

Diese Ziele werden durch die Server-Konsolidierung auf einen NAS-Server erreicht. Durch die Konsolidierung auf den NAS-Server haben sämtliche NT-Server des Anwendernetzwerks über die File-Server des NAS-Servers Zugriff auf die gleichen Daten auf dem Storage Array. Ein weiterer Vorteil des Einsatzes des NAS-Servers ist die vereinfachte Migration von und zu Windows NT, da sowohl Unix als auch NT-Clients auf die gleichen Dateien zugreifen können. Die Dateiverwaltungsmechanismen, Zugriffs- und Sperrmechanismen sind vollkommen transparent für das Client-Betriebssystem.

269

5 Hochverfügbare NAS-Hardware-Komponenten Abbildung 5.12: Windows NT ServerKonsolidierung via NAS-Server

F F F F F F F F F F F F F F F F

E E E E

E E F F

NT-Speicherkonsolidierung via SAN-Lösung bearbeitet lediglich die Speicherkapazitäten der NT-Server, die File-Services müssen von den NT-Servern weiter übernommen werden. NT-Serverkonsolidierung über NAS-Server dient dagegen sowohl der Speicherkonsolidierung als auch der Konsolidierung der File-Services. Dies erlaubt den Anwendern, die existierenden NTServer nicht mehr als File-Server einzusetzen, sondern mit neuen Aufgaben weiterzuverwenden.

5.4.2

Internet als NAS-Applikation

Die IT-Landschaft von Internet Service Providern ist heute durch folgende Anforderungen an die eingesetzte Hardware, insbesondere auch Speicherhardware, charakterisiert: 왘 Die Hardware muss ein Höchstmaß an Verfügbarkeit bieten. Kein Inter-

netprovider – auch und vielleicht sogar gerade nicht die Low-Cost Massen-Provider – kann sich erlauben, seinen Kunden durch Unzulänglichkeiten der Hardwareausstattung für einen längeren Zeitraum (wobei längerer Zeitraum sich in Stunden misst) den Zugriff auf das Internet nicht zu ermöglichen.1 Das öffentliche Interesse, das gerade Internetan1.

270

So führte die Nachricht, ein defekter EMC-Speicher habe Strato lahmgelegt, sowohl für Strato als auch für EMC zu einer ausgesprochen negativen Presse und schädlicher Publizität. Vgl. dazu: »Defekter EMC-Speicher legt Strato lahm«, Computerwoche 14/ 2001, vom 06.04.2001, S. 10. Vgl. auch: »EMC verliert den Glanz früherer Tage«, Computerwoche 22/2001, vom 01.06.2001, S1 und S. 16.

NAS-Applikationen

bieter wie Strato, Lycos oder PureTec genießen, sorgt bei Hardwareausfall für sofortige ökonomische Auswirkungen für den Internetprovider. 왘 Sie muss skalierbar für jede Form des Wachstums sein. 왘 Sie muss sicherstellen, dass trotz des Einsatzes multipler Web-Server die

Daten nicht repliziert werden müssen. Firewall

Abbildung 5.13: NAS-IT-Umgebung für Internet Services

Internes Netzwerk

SCSI/FC

S1

S2 .. ..

NAS-Server und Storage Array

ESCON, Parallel oder Fibre Channel

Sn

Web-Server

Rechenzentrum

왘 Sie muss die Flexibilität des gesamten internen Netzes erhöhen und da-

bei die Komplexität des Systems ideal verringern. 왘 Letztlich muss die Sicherheit gesteigert werden und zwar sowohl hin-

sichtlich des Schutzes vor unberechtigtem Zugriff auf die Daten (Datenschutz) als auch des Schutzes vor Verlust der Daten (Datensicherheit). 왘 Internetprovider verwenden in der Regel Network Attached Storage an-

stelle eines Direct Attached oder SAN-Storage, da sie multiple Web Server einsetzen, die den Zugriff auf die gleichen Daten ermöglichen sollen. Der Network Attached Storage muss jedoch hochverfügbar sein, um die oben dargestellte Verfügbarkeitsanforderung zu erfüllen. Daher werden hochredundante NAS-Server mit automatischem File-Server Failover, Battery Backup, Call Home, Remote Service und allen oben dargestellten Features mit hochverfügbaren Storage Arrays kombiniert, verwendet. Die Skalierbarkeitsanforderungen werden durch NAS-Server und Storage Arrays ebenfalls erfüllt, da File-Server und Devices sowohl hot Swappable sind als auch während des Betriebes hinzugefügt und auch die Filesysteme online erweitert werden können, ohne dass das Gesamtsystem vom Netz genommen werden muss.

271


Datenredundanz und damit Datenreplikation ist nicht notwendig. Über die Anbindung der File-Server an das Netz und die Sichtbarmachung sämtlicher Dateisysteme für alle File-Server kann jeder Client die gleichen Files sehen und nutzen. Dies reduziert die bereitzustellende Datenmenge und gleichzeitig auch den Administrationsaufwand, da die Replikation nicht verwaltet werden muss. Abbildung 5.14: NAS-Absicherung durch Remote Mirrors

NASS e rve r 1

S tora ge Arra y 1

S tora ge Arra y 2

NASS e rve r 2

Die Hochverfügbarkeits- und Skalierbarkeitsanforderung an die ISP-ITTechnologie wird ebenfalls durch die Unterstützung einer Vielzahl von Netzwerken wie Ethernet, Gigabit Ethernet, ATM und FDDI erfüllt. Die Verbindungen zum NAS-Server und damit zum Speicher können im Bedarfsfall dynamisch rekonfiguriert werden, ohne dass die Anwendungen vom Netz genommen werden müssen. Die Zentralisierung der Speicherkapazitäten reduziert die Systemkomplexität und vereinfacht die Systemadministration, was auch zu einer erheblichen Senkung der Administrationskosten führt. Die Verbesserung der Sicherheit wird dadurch erreicht, dass sämtliche Features bzgl. Ausfallsicherheit, die die Storage Arrays bieten, natürlich auch vom Network Attached Storage geboten werden. So kann eine DistanzTopologie mit Switched Fabrics erstellt werden, durch welche die Remote Mirrors der Devices des NAS-Storage Arrays vor einem Totalverlust einer Speicherlokation schützen.

272

NAS-Applikationen

Clients

FS2 Kopie

Client-Zugriff auf flexible Mirrors

FS3 Kopie

Abbildung 5.15: NAS-Absicherung durch Flexible Mirrors

Flexible Mirrors FS1 Kopie

FS2

FS3

Client-Zugriff auf Quelldaten (Standard Devices)

FS1

Fileserver

Storage Array

Diese Möglichkeiten zum Disaster Recovery können noch um die Datensicherungs- und -Wiederherstellungsvorteile von Flexible Mirrors erweitert werden, sodass die Dienste der Internet Service Provider mit sämtlichen charakteristischen Anforderungen ideal durch NAS-Implementierungen gewährleistet werden können.

5.4.3

NAS-Backup-Applikation

Die Eignung von NAS als unternehmensweite Backup-Architektur soll im abschließenden Kapitel dieses Buches, das einen Ausblick auf die Weiterentwicklung und die Nebenbereiche von SAN und NAS geben wird, tiefer erläutert werden. Dennoch soll auch hier schon kurz darauf hingewiesen werden, dass ein großes Argument für die Einführung des Network Attached Storage in Unternehmen eben in der Unterstützung einer unternehmensweiten Backup- und Restore-Strategie liegt. Dabei stellt NAS zurzeit drei wesentliche Backup-Lösungen unternehmensweit zur Verfügung: 왘 Netzwerk-basierte Datensicherung via NFS-Mount der Filesysteme. Die

Datensicherung erfolgt auf Bandbibliotheken wie z.B. den EDM (EMC Data Manager) von EMC2 oder den Powderhorn von StorageTek. Als Backup-Software werden Produkte wie Veritas NetBackup, Legato Networker, HP Omniback oder ADSM verwendet. 왘 Lokale Datensicherung mit zentraler Datenverwaltung über NDMP

(Networked Data Management Protocol) 왘 Disaster Recovery Lösungen über Flexible Mirrors oder Remote Mirrors

273


Diese drei Lösungen werden – wie erwähnt – später noch näher beleuchtet. Abbildung 5.16: NAS im SAN – Unternehmensweite Speichernetzwerke

Verbindung von SAN und NAS Heterogene Clients

Netzwerk

5.4.4

Networked Storage als NAS-Applikation

Unter dem Stichwort des Networked Storage soll all das zusammengefasst werden, was einen NAS-Server an eine oder mehrere Storage Arrays eines bereits existierenden SAN anschließt. Hier werden die Flexibilität in Data Sharing und der Zugriff auf Informationen des NAS-Servers gepaart mit der Möglichkeit der Speichernetzwerk- und Datenbankzugriffs-Fähigkeit des SAN. Dabei sind folgende Einschränkungen zu beachten: 왘 Auf dem Storage Array des SAN, an das ein NAS-Server angeschlossen

werden soll, muss ausreichend Plattenplatz verfügbar sein. 왘 Das Storage Array sollte mit ausreichendem Cache versorgt sein. 왘 Es müssen ausreichend freie SCSI- oder Fibre Channel-Ports auf Channel

Directors des Storage Arrays frei sein, um die File-Server und Control Station(s) des NAS-Servers anzuschließen. 왘 Ein Post-Installation-Tuning sollte stattfinden, um die gewünschte SAN-

Performance zu überprüfen. Diese Einschränkungen sind jedoch keine besonderen, die lediglich beim Hinzufügen eines NAS-Servers in das SAN zu beachten sind. Sie gelten vielmehr für das Hinzufügen eines jeden Servers in den SAN.

274

6

Hochverfügbare SAN – Software-Komponenten

6.1

Hochverfügbare ClusterSoftware

In Kapitel 4 dieses Buches wurden die Hardware-Komponenten hochverfügbarer Cluster-Systeme dargestellt. Im ersten Abschnitt dieses Kapitels soll der Blick nun auf die Software-Komponenten einer solchen ClusterUmgebung gelenkt werden.

6.1.1

Was ist ein Cluster?

Ein Cluster besteht aus zwei oder mehreren über ein privates Netzwerk vernetzten Computersystemen, die auf unterschiedliche Weise an einen gemeinsam genutzten Speicher angeschlossen sind. Dieser gemeinsam genutzte Speicher hält die Applikationen oder Dienste sowie die Daten, auf die diese Applikationen und Dienste zugreifen. Jedes Computersystem im Cluster ist in der Lage, sämtliche Applikationen und Dienste oder zumindest ein Subset aus diesen zu betreiben. Im Normalbetrieb sind die Applikationen und Services über sämtliche Cluster-Hosts verteilt. Alle ClusterKnoten sind jedoch so konfiguriert, dass bei einem Hardware- oder Software-Fehler die Kontrolle der Applikationen, die von der ausgefallenen Komponente betrieben wurden, von einem Failover-Knoten automatisch übernommen werden kann. Abbildung 6.1 skizziert eine Cluster-Konfiguration, in der auf lokaler Seite (Cluster A) zwei Cluster-Knoten über ein privates LAN miteinander verbunden und über dynamisches Multipathing und via Fibre Channel-SwitchPorts an das lokale Storage Array angeschlossen sind. Die Konfiguration der linken Seite soll einen lokalen Cluster implementieren, durch den bei Ausfall einer Hardwarekomponente die redundante Hardware einen Failover verhindern soll. Kommt es jedoch zu einem Software- oder Netzwerk-Fehler für die auf einen der beiden Knoten laufenden Applikationen oder Services, so findet ein Failover auf den zweiten lokalen Cluster-Knoten statt. Die rechte Seite der Abbildung bildet in einer entfernten Lokation die gleiche Konfiguration ab wie die linke. Der Cluster B mit seinen beiden Knoten und dem FCSW-Anschluss an das Remote Storage Array dient lediglich als Absicherung für den Totalausfall der lokalen-Umgebung auf der linken Seite. Hier wird also ein Failover auf den Cluster B ermöglicht, falls das lokale Storage Array oder der lokale Switch oder beide Cluster-Knoten des Clusters A ausfallen.

275

6 Hochverfügbare SAN – Software-Komponenten Abbildung 6.1: Hochverfügbare ClusterKonfiguration

F C H B A

Cluster-A Knoten 1 F C H B A

F C H B A

Cluster-A Knoten2 F C H B A

F C H B A

F A

F A

F A

Local

Remote

Storage

Storage

Array

Array

F A

Cluster-B Knoten 1 F C H B A

F C H B A

Cluster-B Knoten 2 F C H B A

Nach Beseitigung des Fehlers, der den Failover einer Cluster-Komponente auf einen anderen Knoten bewirkt hat, kann der Failback auf die ursprüngliche Komponente durchgeführt werden. Ein Fehler kann das Failover entweder des gesamten Cluster-Knotens und sämtlicher Applikationen und Services des Knotens auf den Failover-Knoten erzwingen oder nur den Failover des Services oder der Applikation auf den Failover-Knoten durchführen, die von dem Fehler betroffen war. So kann beispielsweise bei Ausfall eines Datenbank-Services auf einem ClusterKnoten dieser Service vom Failover-Knoten angeboten werden. Die Datenbank-Client-Anwendungen und -Anwender werden dann nahezu benutzertransparent auf den Failover-Knoten umgeleitet. Folgende Abschnitte stellen mit Hewlett-Packards MetroCluster/Serviceguard (MC/Serviceguard) eine Cluster-Software-Implementierung vor, die lediglich von Fehlern betroffene Applikationen und Services auf einen Failover-Knoten umleitet, und mit dem Veritas Cluster-Server (VCS) eine Cluster-Software-Implementierung, die bei einem Fehler den Schwenk des kompletten Cluster-Knotens auf einen Failover-Knoten erzwingt.

6.1.2

Cluster-Software-Implementierung unter HP-MC/ServiceGuard

In Kapitel 4 wurde bereits die Hardware-Konfiguration und die Implementierung von MC/ServiceGuard vorgestellt. Hier sollen nun seitens der Cluster-Software folgende Aspekte aufgezeigt werden:

276

Hochverfügbare Cluster-Software 왘 Software-Architektur von MetroCluster ServiceGuard 왘 Funktionsweise des Cluster-Managers unter MC/ServiceGuard, der den

Cluster initialisiert und die Funktion des Clusters überwacht 왘 Funktionsweise des Package-Managers unter MC/Serviceguards, der

darüber entscheidet, wann auf welchem Cluster-Knoten ein Applikations-/Service-Package läuft, angehalten wird oder geschwenkt werden muss 왘 Funktionsweise des Netzwerk-Managers, der die Netzwerk-Controller-

Karten und -Verbindungen initialisiert und überwacht und darüber entscheidet, wann ein Netzwerkfehler vorliegt, der einen Failover notwendig macht 왘 Reaktionen des MetroClusters auf Fehlersituationen

6.1.2.1

MC/ServiceGuard-Architektur

Abbildung 6.2 zeigt die wesentlichen Software-Komponenten der MetroCluster ServiceGuard-Konfiguration, die im Rest dieses Abschnittes detailliert gezeigt wird.

Packages

Applikationen, Services, Ressourcen

Abbildung 6.2: MetroCluster/ ServiceGuard-Software-Komponenten

Cluster-Manager MC/ ServiceGuardKomponenten

Package-Manager

Netzwerk-Manager

Betriebssystem

HP-UX Kernel mit LVM

277

6 Hochverfügbare SAN – Software-Komponenten

MC/ServiceGuard verwendet einen »Cluster-Manager Daemon« (cmcld), der ein »Heart Beat«-Protokoll benutzt, um den Zustand des Clusters abzufragen. Die drei zentralen Komponenten Cluster-Manager, PackageManager und Netzwerk-Manager laufen als Teil dieses Daemons. Der cmcld-Daemon läuft auf jedem Cluster-Knoten mit der Prozesspriorität 20. Es ist absolut erforderlich, dass keine Benutzerprozesse eine niedrigere, d.h. bessere, Priorität als diese 20 besitzen, wodurch verhindert werden könnte, dass MC/ServiceGuard seinen Safety Timer aktualisieren kann, da ein Benutzerprozess mit höherer Priorität den Safety Timer Task behindert. Dies würde den kompletten Cluster-Knoten zu einem TOC (Transfer of Control), also einem Knoten-Failover zwingen.

6.1.2.2

Cluster-Manager – Arbeitsweise

Der Cluster-Manager erfüllt innerhalb von MC/ServiceGuard im Wesentlichen die folgenden Aufgaben: 왘 Initialisierung des kompletten Clusters 왘 Monitoring der Funktionsfähigkeit sämtlicher Clusterkomponenten 왘 Erkennung von Knoten-Fehlern 왘 Regulierung der Re-Formierung des Clusters, wenn ein Knoten den

Cluster aufgrund eines Fehlers verlässt oder nach Behebung eines Fehlers wieder in den Cluster zurückkehrt. Der Cluster-Manager läuft als Daemon-Prozess auf jedem Cluster-Knoten. Während der Cluster-Initialisierung und während einer Cluster-Re-Formierung wird ein Knoten des Clusters als so genannter Cluster Coordinator ausgewählt. Dieser stellt die zentrale Schaltzentrale des Clusters für die Kommunikation zwischen den Cluster-Knoten dar. Die knotenbezogenen Aktivitäten bei Initialisierung und Re-Formierung werden jedoch von dem jeweils Knoten-lokalen Cluster-Manager ausgeführt.

Cluster-Konfiguration Die Konfiguration eines Clusters ist eine Aufgabe eines HP-UX-Systemadministrators. Die Cluster-Konfigurationsparameter werden in einem Konfigurationsfile gesetzt und mit diesem dann ein initiierendes Cluster-Startup gefahren. Die Konfigurationsparameter für den Cluster umfassen die Wahl des Cluster-Namens, die Identifikation sämtlicher Cluster-Knoten, die NetzwerkKonfigurationsparameter für das Cluster Heartbeat-Netzwerk, Informationen über die Cluster Lock Disk sowie sämtliche Cluster Timing Parameter. Diese Parameter werden entweder über das Administrationstool SAM oder durch Editieren des ASCII Cluster Configuration Templates gesetzt. Mithilfe der via SAM oder Cluster Configuration Template definierten Parameter wird

278

Hochverfügbare Cluster-Software

ein binäres Konfigurationsfile erzeugt, das dann an sämtliche Knoten des Clusters propagiert wird. Dieses binäre Cluster-Konfigurationsfile muss auf sämtlichen Knoten des Clusters identisch sein. Nach dem initiierenden Startup des Clusters durch den Systemadministrator reguliert sich dieser im Regelbetrieb selbst ohne die Notwendigkeit einer manuellen Intervention. Folgende Schritte müssen zur Konfiguration eines MC/ServiceGuard-Clusters durchgeführt werden: 왘 cmquery

[-v] –n node1 –n node zwei [-n node n]

-v

(Verbose) Diese Option gibt detaillierte Informationen über den Cluster. –n node Beschränkt die angezeigten Informationen auf den mit node benannten Cluster-Knoten. Um Informationen über sämtliche Knoten des Clusters zu erhalten, müssen diese alle mit der n-Option angegeben werden. Mithilfe des Kommandos cmquery werden zunächst die vorhandenen Informationen über den Cluster abgefragt und verifiziert. Dabei zeigt cmquery sämtliche konfigurierte Subnetwerke, die IP-Adressen der Heartbeats sowie die Volume-Gruppen des Logical Volume-Managers (LVM).1 왘 cmquerycl

[-v] –C /etc/cmcluster.cmclconf.ascii –n node1 –n node2 [-n node n]

-v

(Verbose) Diese Option gibt detaillierte Informationen über den Cluster. -C /etc/cmcluster.cmclconf.ascii Cluster-Konfigurationsfile –n node Beschränkt die angezeigten Informationen auf den mit node benannten Cluster-Knoten. Um Informationen über sämtliche Knoten des Clusters zu erhalten, müssen diese alle mit der n-Option angegeben werden. Mithilfe des Kommandos cmquerycl wird der Cluster-Konfigurationsfile erzeugt. Dieser Konfigurationsfile enthält die Parameter, die zum Setup des Clusters editiert werden müssen. Im Template sind die Parameter auf Default-Werte gesetzt. 왘 cmcheckconf [-v] –C /etc/cmcluster.cmclconf.ascii

-v

(Verbose) Diese Option gibt detaillierte Informationen über den Cluster-Konfigurationsfile. -C /etc/cmcluster.cmclconf.ascii Cluster-Konfigurationsfile Mithilfe des Kommandos cmcheckconf wird der Cluster-Konfigurationsfile auf Syntax- und häufige Anwenderfehler überprüft.

1.

Vgl. unten, Abschnitt »SAN – Unterstützte File-Systeme«.

279

6 Hochverfügbare SAN – Software-Komponenten 왘 cmapplyconf [-v] –C /etc/cmcluster.cmclconf.ascii –n node1 –n node2

[-n node n]

-v

(Verbose) Diese Option gibt detaillierte Informationen über den Cluster-Konfigurationsfile. -C /etc/cmcluster.cmclconf.ascii Cluster-Konfigurationsfile Mithilfe des Kommandos cmapplyconf wird der binäre Cluster-Konfigurationsfile /etc/cmcluster/cmclconfig erzeugt und an sämtliche Cluster-Knoten propagiert. Dieser Konfigurationsfile enthält die Cluster-Konfiguration, die die ServiceGuard Daemons bei jedem Cluster-Start und jeder Cluster-ReFormierung lesen. 왘 cmruncl

Mithilfe des Kommandos cmruncl wird der Cluster gestartet. 왘 cmviewcl

Mithilfe des Kommandos cmviewcl wird der Clusterstatus abgefragt. 왘 cmhaltcl

Mithilfe des Kommandos cmhaltcl wird der Cluster gestoppt. Diese Prozedur in genau der dargestellten Reihenfolge muss jedesmal dann wiederholt werden, wenn ein Hardwarefehler eine Änderung der Konfiguration erforderlich macht, z.B. durch einen Kabeldefekt oder eine defekte LAN-Karte. Weiter muss sichergestellt werden, dass die mit cmruncl gestartete Konfiguration die einzige Konfiguration ist, die an die beteiligten Cluster-Knoten propagiert wurde. Die wesentliche Konfigurationsparameter des Konfigurationsfiles sind: 왘 CLUSTER-NAME

Der Cluster-Name muss eindeutig sein, falls mehrere Cluster im Netz verfügbar sind. 왘 HEARTBEAT-IP

Die Heartbeat Messages werden über TCP/IP kommuniziert. Zumindest eines der in /etc/rc.config.d/netconf konfigurierten Subnets muss für die Übertragung der Heartbeat-Signale ausgewählt werden. Im ClusterKonfigurationsfile muss die IP-Adresse eines jeden Knoten für das für den Heartbeat ausgewählte Subnet als HEARTBEAT-IP deklariert werden. Die Verwendung mehrerer (redundanter) LANs zum Transport der Heartbeat-Informationen muss befürwortet werden, um eine reibungslose Übertragung derselben zu gewährleisten, auch wenn einer der Heartbeat-LANs ausfällt. 왘 STATIONARY-IP

Stationäre IPs können optional für Sub-Netzwerke werwendet werden, die durch MC/ServiceGuard überwacht werden sollen.

280

Hochverfügbare Cluster-Software 왘 FIRST-CLUSTER-LOCK-VG

Hier muss die Volume-Gruppe und die Platte für die Cluster Locks definiert werden. 왘 HEARTBEAT-INTERVAL

Polling Intervall, in dem Heartbeat-Informationen abgefragt werden. Die Standardeinstellung beträgt 1 Sek. 왘 NODE-TIMEOUT

Zeitraum, für den ein Cluster-Knoten maximal nicht auf Heartbeat Messages reagieren darf. Wird der Timeout übertroffen, erfolgt ein KnotenFailover auf einen anderen Cluster-Knoten. Die Standardeinstellung für den Node-Timeout beträgt zwei Sek. 왘 NETWORK-POLLING-INTERVAL

Polling-Intervall, in dem das Netzwerk auf Funktionsfähigkeit getestet wird. Standardwert ist hier bei zwei Sek. 왘 AUTO-START-TIMEOUT

Die Standardeinstellung beträgt zehn Minuten. Dieser Zeitraum wird bei einem Autostart der Cluster-Knoten nach Aufruf des cmruncl gewartet, bevor der Autostart-Benutzer auf den Knoten enabled. In dieser Zeit muss das System den Boot-Prozess beendet haben.

Manueller Cluster-Startup Ein manueller Startup bildet den Cluster aus sämtlichen Knoten, die im Konfigurationsfile definiert wurden. Ein manueller Startup wird in aller Regel lediglich beim initiierenden Start des Clusters, nach Cluster übergreifenden Wartungsarbeiten und Upgrades oder nach einer Rekonfiguration notwendig. Bevor der Startup manuell angestoßen wird, muss sichergestellt sein, dass auf sämtlichen Cluster-Knoten derselbe binäre Cluster-Konfigurationsfile vorliegt. Der Systemadministrator startet den Cluster aus dem SAM oder mit dem Kommando cmruncl auf einem der Cluster-Knoten. Das Kommando kann nur verwendet werden, wenn der Cluster nicht läuft, das heißt, wenn auf keinem der Cluster-Knoten der Daemon cmcld läuft. Während des Startups prüft die Cluster-Manager Software, ob sämtliche Cluster-Knoten, die im Startup-Kommando spezifiziert wurden, gültige Mitglieder des Clusters sind, ob sie aktiv sind (»laufen«), untereinander kommunizieren und ob sie versuchen, sich zu einem Cluster zu gruppieren. Sind diese Bedingungen erfüllt, bildet der Cluster-Manager den Cluster.

Cluster Heartbeat Messages Von zentraler Bedeutung für den Betrieb des Cluster-Managers ist das Senden und Empfangen von Heartbeat Messages zwischen den Knoten des Clusters. Jeder Knoten des Clusters schickt eine Hearbeat Message über die stationäre

281


IP-Adresse eines vom Cluster-Koordinator überwachten LANs oder einer seriellen Leitung (RS232) zum Koordinator. Das Monitoring des LANs wird später in diesem Abschnitt näher erläutert. Der Cluster-Koordinator prüft, ob die Heartbeat Messages von sämtlichen Cluster-Knoten im ausgewählten Zeitrahmen (HEARTBEAT-INTERVAL) empfangen werden können. Kommen die Heartbeat Messages eines Knoten nicht an, so re-formiert der Cluster-Koordinator den gesamten Cluster. Wenn nach Abschluss der Re-Formierung wieder ein neues Set von Knoten – nun ohne den, dessen Heartbeat Messages nicht empfangen werden konnten – den Cluster bilden, wird diese Information an den Package-Koordinator (vgl. Abschnitt »Package-Manager – Arbeitsweise«) weitergereicht. Packages, die auf den nun sich nicht mehr im Cluster befindlichen Knoten liefen, werden in der neuen Konfiguration auf ihren Adoptive Node transferiert. War der Verlust der Heartbeat-Informationen lediglich vorübergehend, so kann der Cluster nach der Re-Formierung auch wieder mit den Knoten gebildet worden sein, deren Heartbeat Messages nur kurzfristig verloren waren. In einem solchen Fall werden die Packages nicht auf die Adoptiven Knoten transferiert – die Anwender der Packages können lediglich einen leichten Performancerückgang für die Dauer der Cluster-Re-Formierung bemerken. Werden Heartbeat Messages und Anwendungsdaten über das gleiche Subnet LAN versandt, kann Data Congestion auf dem LAN dazu führen, dass MC/ServiceGuard Heartbeat Messages eines Cluster-Knotens innerhalb einer Heartbeat Timeout-Periode nicht ausgeliefert werden, sodass der Cluster-Koordinator eine Cluster-Re-Formierung initiiert, obwohl diese nicht nötig gewesen wäre, falls dieser Congestion Error nicht aufgetreten wäre. Daher ist es empfehlenswert, um eine solche unnötige Cluster-Re-Formierung zu verhindern, einen dedizierten Heartbeat-LAN und/oder eine serielle Heartbeat-Leitung neben einem Daten/Heartbeat-Misch-LAN zu konfigurieren. Der dedizierte LAN ist nicht zwingend erforderlich, wenn Netzwerk-Monitoring ergibt, dass der Verlust der Heartbeat Messages aufgrund von Congestion Errors auszuschließen ist. Dennoch ist eine solche Einschätzung stets vorsichtig zu genießen, da zukünftiges Wachstum auch den Verkehr auf dem Netzwerk erhöhen kann, was das Ergebnis des Netzwerk-Monitorings konterkarieren könnte. Von jedem Cluster-Knoten werden mehrere Heartbeats parallel versendet. Wenn sämtliche verfügbare Subnets zwischen den Cluster-Knoten auch für den Transfer von Heartbeat Messages konfiguriert werden, kann somit der Schutz vor Heartbeat-Verlust ohne zusätzliche Kosten gesteigert werden. Jeder Knoten sendet seine Heartbeat Messages in Intervallen, die durch das Cluster Heartbeat Interval im Cluster-Konfigurationsfile definiert werden.

282


Automatischer Cluster-Restart Ein automatischer Cluster-Neustart erfolgt stets dann, wenn zeitgleich bei sämtlichen Knoten eines Clusters ein Fehler auftritt. Dies ist in aller Regel bei einem lokalen Stromausfall der Fall, wenn sämtliche SPUs stoppen. Um einen automatischen Restart des Clusters zu ermöglichen, müssen zunächst sämtliche Knoten des Clusters, die im Cluster-Konfigurationsfile eingetragen sind, wieder gestartet worden sein, untereinander kommunizieren können und versuchen, einen Cluster zu bilden. Damit ein automatischer Restart des Clusters versucht wird, muss das AUTOSTART-CMCLD Flag im Cluster-Konfigurationsfile /etc/rc.config.d/cmcluster auf 1 gesetzt sein.

Dynamische Cluster-Re-Formierung Eine dynamische Cluster-Re-Formierung ist eine temporäre Änderung der Anzahl der Knoten, die zu einem Cluster gehören. Eine dynamische Re-Formierung findet stets statt, wenn ein Knoten den Cluster verlässt oder wieder zum Cluster hinzustößt. Dabei unterscheidet sich die Re-Formierung stark von der Rekonfiguration des Clusters. Während die Re-Formation vorübergehend ist, handelt es sich bei der Rekonfiguration um eine permanente Veränderung des Konfigurationsfiles. Eine Cluster-Re-Formierung tritt unter folgenden klar umrissenen Umständen auf: 왘 Bei einem aktiven Cluster-Knoten wird ein SPU (System Processing Unit)

oder Netzwerk-Fehler festgestellt. 왘 Ein inaktiver Knoten will in den Cluster zurückkehren. Dies bedeutet,

dass auf dem bisher inaktiven Knoten der Cluster-Manager Daemon (cmcld) gestartet wird und Heartbeat Messages gesendet werden. 왘 Ein Knoten wird von einem Systemadministrator gestoppt (cmhaltcl). 왘 Ein Knoten wurde dem (binären) Cluster-Konfigurationsfile hinzugefügt

oder gelöscht. 왘 Ein Knoten stoppt aufgrund eines Package-Fehlers. 왘 Ein Knoten stoppt aufgrund eines Service-Fehlers. 왘 Eine starke Netzwerk-Contention verhindert den Empfang des Heart-

beat-Signals eines Knoten durch den Cluster. 왘 Das Heartbeat-Netzwerk fällt aus und kein weiteres Subnet ist konfigu-

riert, die Heartbeat-Signale zu transportieren. Typischerweise resultiert die Cluster-Re-Formierung in einer neuen Zusammensetzung des Clusters mit mehr oder weniger Cluster-Knoten als in der Vorgänger-Zusammensetzung.

283


Cluster-Quorum für Re-Formierung Für die dynamische Re-Formierung des Clusters wird ein mehrheitliches Cluster-Quorum benötigt, d.h. mehr als 50% der zuvor laufenden Knoten müssen die Re-Formierung befürworten, müssen also die fehlenden Heartbeat-Signale eines ausgefallenen respektive die zusätzlichen Heartbeat-Signale eines neuen Cluster-Knotens registriert haben. Dennoch können auch exakt 50% der zuvor laufenden Cluster-Knoten zu dem neuen Cluster re-formiert werden, wobei sichergestellt werden muss, dass nicht die anderen 50% der Cluster-Knoten ebenfalls versuchen, sich zum Cluster zu re-formieren. In diesen Fällen wird in Analogie zum Tennisspiel ein Tiebreaker benötigt, der sicherstellt, dass nur ein Cluster re-formiert wird. Als Beispiel mag ein Cluster aus zwei Knoten dienen. Kommt es zu einem Kommunikations-Fehler zwischen den beiden Knoten, so versucht jeder der beiden, den Cluster zu re-formieren. Hier gewährleistet der TiebreakingMechanismus von MC/ServiceGuard, dass nur einer der beiden Knoten den neuen Cluster bilden darf. Dieser Mechanismus basiert auf der Verwendung einer Sperre, dem so genannten Cluster Locks.

Cluster Locking-Mechanismen Beim Cluster Lock handelt es sich um einen Bereich auf einem Storage Device, das zu einer Volume-Gruppe gehört, die von sämtlichen Knoten des Clusters geShared wird. Dabei wird die Cluster Lock Volume-Gruppe und der Name des physikalischen Volumes über den Cluster-Konfigurationsfile (Parameter FIRST-CLUSTER-LOCK-VG) identifiziert. Der Cluster Lock wird nur in den Fällen als Tiebreaker verwendet, in denen ein laufender Cluster durch einen Fehler auseinanderbricht und MC/ServiceGuard während der Re-Formierung des Clusters feststellt, dass der ursprüngliche Cluster in zwei Sub-Cluster von genau gleicher Größe gesplittet wurde, die beide den Versuch unternehmen, als Cluster zu re-formieren. Bei diesem Re-Formierungsversuch ist jeder der beiden Sub-Cluster bemüht, den Cluster Lock einzubinden. Der Sub-Cluster, der als erster den Cluster Lock einzubinden sucht, erhält ihn und bildet den neuen Cluster. Der andere Sub-Cluster scheitert beim Einbinden des Cluster Lock und kann daher nicht als Cluster re-formieren. Dadurch wird verhindert, dass zwei Sub-Cluster gleichzeitig als Cluster laufen. Bricht der ursprüngliche Cluster dagegen in zwei Sub-Cluster unterschiedlicher Größe auseinander, so re-formiert sich der Sub-Cluster mit mehr als 50% der Knoten des ursprünglichen Clusters zum neuen Cluster – der Cluster Lock wird als Tiebreaker nicht benötigt. Werden zwei Hosts zu einem Two-Node-Cluster unter MC/ServiceGuard zusammengebunden, so muss der Cluster Lock zwingend konfiguriert werden. Geht die (Heartbeat)-Kommunikation zwischen den beiden ClusterKnoten verloren, so übernimmt der Knoten, der den Cluster Lock erhält, den Cluster, der andere fährt herunter. Ohne den Cluster Lock würde im Falle

284


eines Fehlers eines der beiden Knoten im Cluster der andere Knoten und damit der komplette Cluster zum Herunterfahren gezwungen. Auch wenn keiner der beiden Cluster-Knoten den Cluster Lock einbinden kann (z.B. durch einen Fehler der Volume-Gruppe) stoppt der Cluster. Bei der Konfiguration des Cluster Lock kann aus zwei Cluster Lock-Optionen gewählt werden. Je nach (Hoch)-Verfügbarkeit der Cluster-Lösung kann ein Single Cluster Lock oder ein Dual Cluster Lock konfiguriert werden. Dabei empfiehlt Hewlett-Packard, wo immer möglich Single Cluster Locks zu implementieren. Unabhängig von der gewählten Cluster Lock-Strategie muss sichergestellt werden, dass die Cluster Lock Disk stets verfügbar ist, auch wenn die Stromversorgung eine des Cluster-Knoten unterbrochen ist. Daher hängt die Wahl der Strategie zum Teil auch davon ab, wie viele voneinander unabhängige Stromkreise bei der Formierung des Clusters verfügbar sind. Für Hochverfügbarkeit muss auf jeden Fall sichergestellt sein, dass sämtliche Knoten innerhalb des Clusters auf den Cluster Lock zugreifen können. Bei einem Cluster mit mehr als vier Knoten ist die Konfiguration eines Cluster Lock nicht erlaubt. Wächst die Anzahl der Knoten im Cluster auf mehr als vier, so sollte der Cluster gestoppt werden, bevor der fünfte Knoten zum Cluster hinzugefügt wird, und der Cluster Lock sollte entfernt werden.

Single Cluster Lock Hewlett-Packard empfiehlt die Verwendung eines Single Cluster Locks. Dieser Cluster Lock soll auf einem unabhängigen Stromkreis konfiguriert sein, getrennt von jedem Knoten des Clusters. In einem Cluster aus zwei Knoten empfiehlt Hewlett-Packard die Verwendung von drei Stromkreisen, einen für den Cluster Lock, je einen für die beiden Cluster-Knoten. Der Cluster Lock respektive die Cluster Lock Disk sollte stets eine externe Platte sein, also idealerweise auf einem HA-Storage Array liegen. Für Cluster mit mehr als zwei Knoten sollte der Cluster Lock an einem Stromkreis angeschlossen sein, der nicht mit der Mehrzahl der Cluster-Knoten geteilt wird.

Dual Cluster Lock Ein Dual Cluster Lock wird lediglich bei Verwendung interner Platten anstelle eines externen Storage Arrays notwendig. In einem solchen Falle, in dem die Cluster Lock Disk im gleichen Schrank wie einer der Knoten eingebaut ist, würde der Ausfall dieses Node-Cabinets den Ausfall des kompletten Clusters bedeuten. Bei der Verwendung interner Platten ist es also nötig, auf zwei an unterschiedlichen Stromkreisen hängenden Knoten jeweils eine Cluster Lock Disk zu konfigurieren. Dadurch würde der Cluster Lock als Single Point of Failure eliminiert. Dabei ist darauf zu achten, dass die beiden Cluster Lock Disks weder im gleichen Chassis montiert sind noch am gleichen Stromkreis angeschlossen sind. Sind die Dual Cluster Locks so konfiguriert, ist sicherge-

285


stellt, dass beim Ausfall einer der beteiligten Komponenten – Cluster-Knoten, Chassis, Stromkreis – der zweite verbleibende Knoten mit seiner internen Cluster Lock Disk den Cluster re-formieren kann.

Kein Cluster Lock In einem Cluster mit drei oder weniger Knoten sollte stets ein Cluster Lock konfiguriert werden; Cluster mit lediglich zwei Knoten bedürfen unbedingt eines Cluster Locks. Jedoch auch Cluster mit drei oder vier Knoten können in Situationen kommen, in denen der Cluster Lock als Tiebreaker benötigt wird. So könnte z.B. in einem Drei-Knoten-Cluster einer der Knoten für Wartungsarbeiten aus dem Cluster genommen worden sein. Die beiden verbleibenden Knoten wären dann zum Cluster re-formiert worden. Kommt es nun zu einer Fehlersituation mit darauf folgender Re-Formierungsnotwendigkeit, wäre wiederum eine Situation vorhanden, die ohne Tiebreaker den kompletten Cluster lahm legt. Bei Clustern mit mehr als vier Knoten ist die Konfiguration eines Cluster Locks nicht gestattet, da hier – bei korrekter Konfiguration des Clusters – eine Tiebreaker-Situation nicht auftreten kann. Dennoch muss sichergestellt werden, dass dieser Cluster hochverfügbar konfiguriert wird, also keinen Single Point of Failure enthält, wie z.B. einen einzigen LAN zwischen einer geraden Anzahl von Cluster-Knoten oder einen Anschluss von exakt der Hälfte aller Knoten an einen einzigen Stromkreis. Abbildung 6.3: MC/ServiceGuard – Hochverfügbare Single Cluster LockKonfiguration

F C H

FC-Switch Single Cluster Lock

B

HP-Server

A

Cluster-

F

Knoten A F

Cluster Lock Disk

A

C H B

Local

A

Storage Single Cluster Lock

F

Array

C

Local Mirror

H B

HP-Server

A

Knoten B F C H B A

286

F A

Cluster-

Cluster Lock Disk Mirror


Backup der Cluster Lock-Information Sämtliche oben dargestellten Probleme mit Dual und Single Cluster Locks lassen sich durch eine hochverfügbare Cluster-Konfiguration wie in Abbildung 6.3 dargestellt vermeiden. Es wird lediglich ein Cluster in einer lokalen-Umgebung dargestellt. Die Verfügbarkeit kann auch noch mit einem Remote Szenario wie einleitend zu diesem Kapitel dargestellt vor Disastern, sprich Totalverlust des Rechenzentrums, mit der Einführung des Remote Mirrors für die Cluster Lock Disk optimiert werden. Dennoch sollte nach der Konfiguration des Clusters und der Erzeugung der Cluster Lock Volume-Gruppe und dem Cluster Lock Physical Volume ein Backup der Konfigurationsdaten jeder Lock Volume-Gruppe erzeugt werden, um von diesem Backup die Informationen wiederherstellen zu können. vgcfgbackup

HP-LVM-Kommando zur Sicherung der Konfigurationsdaten der Lock Volume-Gruppe

vgcfgrestore

HP-LVM-Kommando zur Wiederherstellung der Konfigurationsdaten der Lock Volume-Gruppe aus einem vgcfgbackup-File nach einem Plattenfehler der Cluster Lock Disk

Dabei ist darauf zu achten, dass nur Backup-Dateien, die mit dem vgcfgbackup erzeugt wurden, zur Wiederherstellung der Konfigurationsdaten der Cluster Lock Volume-Gruppe mit dem Kommando vgcfgrestore verwendet werden können. Dies ist vollkommen unabhängig davon, ob die Lock Volume-Gruppe mit SAM oder mit HP-UX erzeugt wurde. Abschließend sollen im Abschnitt des Cluster-Managers nochmals die Cluster-Konzepte von MC/Serviceguard zusammengefasst werden. 왘 Beim Start von MC/ServiceGuard wird auf jedem der Cluster-Knoten der

Cluster Daemon gestartet. Die Cluster Daemons tauschen untereinander die Status-Informationen ihrer Knoten aus. Typische Status-Informationen sind dabei die aktuell auf dem Knoten laufenden Packages und die auf dem Knoten aktivierten Volume-Gruppen. Weiter werden natürlich die Heartbeat-Signale übertragen, um den Knoten des Clusters die Betriebsbereitschaft des sendenden Knoten anzuzeigen. 왘 Heartbeat-Signale werden nicht unidirektional in eine Richtung übertra-

gen. Es handelt sich hierbei vielmehr um Tokens, die zwischen den Cluster-Knoten weitergereicht werden. Die schnellste Heartbeat-Frequenz, die auch als Standardeinstellung im Konfigurationsfile-Template verwendet wird, beträgt ein Heartbeat-Signal pro Sek. 왘 Der Standard-Timeout eines Knotens, bevor ein Fehler vermutet wird,

beträgt zwei Sek. Kommt es zu einem Fehler auf einem Knoten, so wird von diesem kein Heartbeat-Signal mehr gesendet. Sämtliche auf diesem Knoten laufenden Applikationen schwenken dann auf den Adoptive Knoten.

287

6 Hochverfügbare SAN – Software-Komponenten 왘 Da für den Schwenk kein Reboot des Adoptive Knotens notwendig ist, ist

das Failover der Applikationen ausgesprochen schnell. Dennoch ist das Failover nicht unbedingt für den Benutzer transparent, es muss vielmehr zusätzlich zu der Zeit, die für das Failover benötigt wird, noch Zeit für das Recovery der Applikation (Datenbank Recovery für Datenbank-basierte Applikationen, evtl. fsck für Filesystem-basierte Applikationen) eingeplant werden, bevor eine Applikation wieder komplett verfügbar ist. Ein Fehler, der Cluster-Knoten-Schwenks und Applikations-Failover auslöst, muss nicht stets ein Fehler eines kompletten Knoten sein. Schwenks werden auch hervorgerufen durch defekte LAN-Karten, gebrochene LAN-Kabel, Timeouts aufgrund Contention im LAN usw. Dies wird in hochverfügbaren Clustern durch die Konfiguration eines zweiten Anwendungs-LANs und eines zweiten Heartbeat-LANs verhindert.

6.1.2.3

Package-Manager – Arbeitsweise

Package Grundlagen MC/ServiceGuard bündelt Applikationen, Dienste und die von diesen verwendeten Daten zu logisch atomaren Entitäten, so genannten Packages. Das MC/ServiceGuard Package-Konzept lässt sich durch folgende Charakteristika beschreiben: 왘 Applikationen werden zu Packages zusammengebunden. Ein Package

enthält sämtliche Ressourcen, die zum Betrieb der Applikation erforderlich sind. Typische Ressourcen sind dabei Volume-Gruppen, logische Volumes und Filesysteme. 왘 Als Entscheidungshilfe zur Auswahl der Ressourcen für das Schnüren ei-

nes Packages mag gelten, dass Ressourcen, die für ein Package definiert werden, keinem anderen Package mehr zugewiesen werden können, d.h. ein Package sollte sämtliche Applikationen enthalten, die auf dieselben Ressourcen zugreifen. 왘 Ein Package enthält nicht nur Ressourcen, sondern auch Shell-Scripts

und Funktionen (Shell-Script-Bibliotheken), die zum Start und Stopp der Applikationen benötigt werden. 왘 Aus obigen drei Charakteristika ergibt sich die Grundidee eines Pa-

ckages. Das Package soll die Ressourcen einer Applikation administrieren können, nicht – wie in einer Non-Cluster-Umgebung – das System. Im Fall der Steuerung durch das System aktiviert das Betriebssystem die Volume-Gruppe und mounted die Filesysteme der Applikation beim Startup des Servers. Volume-Gruppen-Aktivierung und Mount der Filesysteme erfolgt im Package-Konzept durch das Package selbst. Dies hat den Vorteil, dass die Tasks, die für den Betrieb der Applikation benötigt

288


werden, unabhängig vom Status des Serversystems ausgeführt werden können und zwar stets dann, wenn das Package gestartet wird und unabhängig vom Server, auf dem es gestartet wird. 왘 Dadurch wird eine zusätzliche administrative Ebene eingeführt, die

komplexe Funktionalitäten, wie z.B. ein Failover oder Failback, serverunabhängig automatisieren lässt.

Shared Volume Groups Voraussetzung für die Bildung von Packages und die Nutzung der zusätzlichen administrativen Ebene innerhalb von MC/ServiceGuard ist, dass die Ressourcen der Applikationen, die in das Package eingebunden sind, auch von mehreren Server-Rechnern innerhalb eines Clusters geshared werden können, also für mehrere Cluster-Knoten verfügbar sind. Dies wird durch das Konzept der Shared Volume Groups erreicht, das wie folgt beschrieben werden kann: 왘 Damit mehrere Cluster-Knoten als Server für eine Applikation arbeiten

können, müssen sie auf die Speichermedien zugreifen können, auf denen die Applikation und ihre Daten residieren. 왘 Dies wird durch die HP/UX-Funktionalität (ab Release 10.x) der Shared

Volume Group realisiert. Shared Volume Groups werden auf einem Cluster-Knoten angelegt und von (sämtlichen) anderen Cluster-Knoten geteilt, die sich den gleichen I/O-Kanal teilen. Bei der Verwendung hochverfügbarer Storage Arrays im SAN handelt es sich dabei um die Knoten, die via Switch-Zoning auf Ports von Fibre Channel Directors des Storage Arrays verbunden sind, die auf demselben Storage Array-internen Systembus angeschlossen sind. Mit einem Locking-Mechanismus (siehe unten) wird seitens der LVM-Erweiterungen für MC/ServiceGuard sichergestellt, dass eine solche Shared Volume Group zu einem gegebenen Zeitpunkt nur von einem Cluster-Knoten aktiviert werden kann. Dieser Locking-Mechanismus ist zur Gewährleistung der Integrität der Devices der Shared Volume Group unerlässlich. 왘 Sämtliche Volume-Gruppen, die über den Package-Manager zwischen

den Cluster-Knoten geswitched werden können, müssen dieselben (konsistente) Device-Filenamen verwenden. Dies bedeutet, dass die Namen der Logical Volumes und der Logical Volume-Gruppen gleich und die Minor Device Numbers der Logical Volumes und Volume Group Device Files auf den Cluster-Knoten identisch sein müssen. Die Device Files der Physical Volumes (basierend auf einer Controller-Target-LUN-Mimik) können dagegen auf den Cluster-Knoten unterschiedlich sein. 왘 Nur Daten-Platten kritischer Applikationen sollten zwischen Cluster-

Knoten geshared werden, also zu Shared Volume Groups zusammengefasst werden. Lediglich auf einem Cluster-Knoten lokal verwendete

289


Applikationen, wie auch die Betriebssystem-Platte(n) eines jeden Cluster-Knoten (root Disk) werden nicht geshared und stellen definitiv keine High Availability-Applikationen dar.

LVM Disks für einen MC/ServiceGuard Cluster Folgende Schritte sind für die Auswahl und Erstellung von Platten für einen MC/ServiceGuard Cluster einzuhalten: 왘 Planen des Layouts der Volume-Gruppen für den Cluster. Dieser initiale

Schritt erfordert den höchsten (Design)-Aufwand. Hier müssen die HAApplikationen identifiziert werden und die Cluster-Knoten definiert werden, auf denen diese Applikationen laufen sollen und das Switch Zoning muss so geplant werden, dass die HBAs der benötigten ClusterKnoten auch alle die Devices der Applikation auf dem Storage Array sehen können. 왘 Erstellen eines Mirrors der Boot Disk auf jedem Knoten 왘 Definition der Shared Volume-Gruppen gemäß der Planung des ersten

Schrittes, die von den Cluster-Knoten geteilt werden sollen 왘 Erzeugen der Logical Data Volumes für die HA-Applikationen 왘 Erzeugen der Filesysteme auf den Logical Data Volumes und initiales

Mount dieser Filesysteme 왘 Test der Konfiguration. Überprüfung der Adressen sämtlicher Cluster-

Knoten, die das Package hosten sollen, via Mapfiles 왘 Mithilfe des Mapfiles muss letztendlich die Volume-Gruppe auf sämtli-

chen für dieses Package geplanten (Primary und Adoptive) Knoten des Clusters importiert werden (Kommando vgimport). Auf sämtlichen Knoten des Clusters müssen die Minor Number der Volume Group und der Volume Group Name übereinstimmen. Der letzte Schritt sollte auf einer weiteren Ebene fortgesetzt werden – bei der Definition der Device-Gruppen auf dem Storage Array (vgl. unten) zur Gruppierung der Logical Devices auf dem Storage Array sollte die DeviceGruppe, die die Platten einer Volume Group enthält, den gleichen Namen besitzen wie diese Volume Group, um auch hier ein einfaches Mapping sicherzustellen.

Volume Group Locking Zur Gewährleistung der Integrität der Volumes einer Shared Volume Group muss sichergestellt sein, dass die Shared Volume Group zu jedem gegebenen Zeitpunkt lediglich auf einem Knoten des Clusters aktiviert ist und nicht von sämtlichen Knoten des Clusters gleichzeitig auf die Volumes zugegriffen werden kann. Dies wird durch den Lock-Mechanismus der MC/Service-

290


Guard-Version des Logical Volume-Managers LVM gewährleistet. Der LockMechanismus wird durch zwei zusätzliche Optionen für das Kommando vgchange implementiert. 왘 Mit dem Kommando

vgchange –c [y/n] /dev/vg

wird angezeigt, ob die Volume-Gruppe dem Cluster »gehört« oder nicht (und damit eine lokale Volume-Gruppe des Knotens darstellt). Wird für die c-Option »y« ausgewählt, so ist die Volume-Gruppe eine ClusterGruppe, bei »n« ist sie eine lokale Gruppe. 왘 Mit dem Kommando

vgchange –a e/y /dev/vg

wird die Volume-Gruppe exklusiv auf einem Knoten aktiviert. Lässt man das Attribut e/y weg, so wird sie normal aktiviert, es kann die VolumeGruppe von anderen Knoten des Clusters read/only aktiviert werden. Bei exklusiver Aktivierung ist die Gruppe absolut gesperrt, das heißt, sie kann von anderen Knoten des Clusters nicht einmal read/only aktiviert werden.

Package-Management Auf jedem aktiven Knoten eines Clusters läuft eine Instanz des PackageManagers. Der Package-Manager, der auf dem Cluster-Koordinator läuft, wird als Package-Koordinator bezeichnet.

Package 1 HP- Server ClusterKnoten A

F C H B A

Package 2 HP- Server ClusterKnoten B

F C H B A

F C H B A

Abbildung 6.4: MC/ServiceGuard – Package Failover

F C H B A

Package 2 HP- Server ClusterKnoten C

F C H B A

F C H B A

291


Aufgabe des Package-Koordinators ist zu entscheiden, wann und wo die Ausführung eines Packages gestartet wird, gestoppt wird oder ein Package auf einen anderen Knoten geswitched wird. Die Aufgabe des Package-Managers auf jedem Cluster-Knoten ist 왘 die Ausführung des benutzerdefinierten Control Scripts zum Start und

Stopp von Packages und Package Services, 왘 die Reaktion auf Statusänderungen der von ihm überwachten Ressourcen.

Ein Package startet mit dem Start des Clusters auf dem ihm zugewiesenen Cluster-Knoten. Ein Failover des Packages findet dann statt, wenn der Package-Koordinator den Start des Packages auf einem anderen Knoten initiiert.

Running und Halting von Packages – Wo und Wann? Jedes Package wird mit einem Package-Konfigurationsfile eigenständig konfiguriert. Dieser Konfigurationsfile kann entweder via Texteditor oder SAM an die Package-Umgebung angepasst werden. Im Konfigurationsfile wird der Name des Packages definiert und die Reihenfolge der Cluster-Knoten festgelegt, auf denen das Package laufen kann. Dabei ist die Priorität durch die Reihenfolge der Cluster-Knoten-Einträge im Konfigurationsfile gesetzt. Der erste Knoten im sequentiell abgearbeiteten Konfigurationsfile ist der Knoten mit der höchsten Priorität für dieses Package. Das Verhalten des Packages beim Package Switching, also beim Failover auf einen zweiten Cluster-Knoten im Fehlerfall und beim Failback nach Behebung dieses initialen Fehlers, wird durch die Parameter 왘 PACKAGE-SWITCHING-ENABLED 왘 FAILOVER-POLICY 왘 FAILBACK-POLICY

festgelegt.

Package Switching Der Parameter PACKAGE-SWITCHING-ENABLED definiert zum Startzeitpunkt des Clusters das allgemeingültige Switching-Attribut für das Package. Das heißt, über diesen Parameter wird gesteuert, ob das Package im Fehlerfall auf einem zweiten Cluster-Knoten automatisch gestartet wird und ob es im Autostart mit dem Anlauf des Clusters startet. Dieser Parameter kann im Konfigurationsfile auf YES/NO gesetzt werden:

292


# The default for PKG-SWITCHING-ENABLED is YES. In the event # of a failure, this permits the cluster -Software to transfer # the package to an Adoptive Node. Adjust as necessary. PKG-SWITCHING-ENABLED

YES

Bei laufendem Cluster kann das Packet Switching-Attribut eines jeden Packages mit dem Kommando cmmodpkg

geändert werden.

Failover-Politik Die Prioritätsliste der Cluster-Knoten im Package-Konfigurationsfile determiniert die Auswahl des bevorzugten Knoten durch den Package-Manager. Zusätzlich zur Prioritätsliste muss – ebenfalls im Package-Konfigurationsfile – der Parameter FAILOVER-POLICY mit einer zu wählenden Politik im Falle eines Fehlers belegt sein. Die Definition der Failover Policy erfolgt wieder via Editor im ASCII-Package-Konfigurationsfile oder via SAM. Der Parameter FAILOVER-POLICY definiert nun, auf welchem Cluster-Knoten ein Package laufen soll, falls ein bestimmter Knoten, der als Primary-Knoten für das Package definiert ist oder ein Adoptiver Knoten mit hoher Priorität ist, nicht verfügbar ist. Dieses Vorgehen – Überprüfung der Prioritätsliste und Abgleich mit der Failover Policy – erfolgt nicht nur im Failover-Fall, sondern auch beim ganz normalen Start des Clusters oder des Packages. Die beiden für die Auswahl der Failover Policy verfügbaren Alternativen sind 왘 CONFIGURED-NODE und 왘 MIN-PACKAGE-NODE

Wird als Failover Policy die Politik des CONFIGURED-NODE verwendet, so startet der Package-Manager das Package auf dem verfügbaren Knoten mit der höchsten Priorität gemäß der Knoten-Liste im Package-Konfigurationsfile. Kommt es im Fehlerfall zu einem Failover, wird das Package auf den verfügbaren Knoten mit der (nächst) höheren Priorität geschwenkt. Wird als Failover Policy die Politik des MIN-PACKAGE-NODE gewählt, so wird das Package auf dem Knoten gestartet, auf dem zum Zeitpunkt des Starts die wenigsten sonstigen Packages laufen. Hierbei ist zu beachten, dass dies nicht gleichbedeutend damit ist, dass dieser Knoten auch die niedrigste Load-Last besitzt. Das einzige, was tatsächlich überprüft wird, ist die Anzahl der auf den Knoten des Clusters laufenden Packages, nicht die Auslastung der Knoten.

293


Der Part der Auswahl der Failover Policy im Package-Konfigurationsfile stellt sich wie folgt dar: # # # # # #

Enter the failover policy for this package. This policy will be used to select an Adoptive Node whenever the package needs to be started. The default policy unless otherwise specified is CONFIGUREDNODE. This policy will select nodes in priority order from the list of NODE-NAME entries specified below.

# # # #

The alternative policy is MIN-PACKAGE-NODE. This policy will select the node, from the list of NODE-NAME entries below, which is running the least number of packages at the time of failover.

FAILOVER-POLICY

CONFIGURED-NODE

Automatisches rotierendes Standby Wird als Failover Policy die Politik des MIN-PACKAGE-NODE verwendet, so kann ein Cluster so konfiguriert werden, dass einer der Cluster-Knoten als automatisch rotierender Standby-Knoten definiert wird. Abbildung 6.5: MC/ServiceGuard – Rotierendes Standby


F C H B A


F C H B A


F C H B A

F C H B A

F C H B A


F C H B A


F C H B A

F C H B A

F C H B A

Lokale Packages HP- Server ClusterKnoten D

F C H B A


F C H B A

F C H B A

F C H B A

F C H B A

Lokale Packages Package 2 HP- Server ClusterKnoten D

F C H B A

F C H B A

In Abbildung 6.5 sei der Knoten D des Vier-Knoten-Clusters das rotierende Standby. Voraussetzung für ein rotierendes Standby ist, dass sämtliche Packages auf sämtlichen Knoten des Clusters laufen können, also die NODE-

294


NAME-Liste in den Package-Konfigurationsfiles auf den Cluster-Knoten dieselben Knoten enthält. Diese können jedoch in ihrer Reihenfolge (Priorität) unterschiedlich in den Konfigurationsfiles gelistet sein. Tabelle 6.2 stellt beispielhaft die konkreten Einträge der Package-Parameter in den Konfigurationsfiles auf den einzelnen Knoten dar. PACKAGENAME

NODE-NAME Liste

FAILOVER-POLICY

Package 1

Knoten A, Knoten B, Knoten C, Knoten D

MIN-PACKAGENODE

Package 2

Knoten B, Knoten C, Knoten D, Knoten A

MIN-PACKAGENODE

Package 3

Knoten C, Knoten D, Knoten A, Knoten B

MIN-PACKAGENODE

Tab. 6.1: Package Parameter Setting für rotierendes Standby in einem 4-Knoten-Cluster


F C H B A


F C H B A


F C H B A

F C H B A

F C H B A


F C H B A


F C H B A

F C H B A

F C H B A


F C H B A

Package 3 Package 2 HP- Server ClusterKnoten C

F C H B A

F C H B A

F C H B A

Abbildung 6.6: MC/ServiceGuard – CONFIGUREDNODE Failover Policy

F C H B A


F C H B A

F C H B A

Beim Start des Clusters starten sämtliche Packages gemäß ihrer Priorisierung, Package 1 auf Knoten A, Package 2 auf Knoten B und Package 3 auf Knoten C. Fällt bei der Rotating Standby-Konfiguration einer der Knoten aus, so wechselt das Package gemäß der Failover Policy MIN-PACKAGE-NODE auf den Knoten, auf dem die wenigsten Cluster-(HA-) Packages laufen – in unserem Beispiel stets der Knoten D, unabhängig von einer vorgegebenen Priorität. Interessant wird das Verhalten des Clusters bei einer MIN-PACKAGENODE-Konfiguration, wenn der in unserem Beispiel ausgefallene Knoten B

295


nach Beseitigung des Fehlers wieder gestartet wird und dem Cluster hinzugefügt wird. Dann ist er der Knoten mit den wenigsten aktiven ClusterPackages. Kommt es dann wieder zu einem Package-Fehler, so schwenkt das betroffene Package auf den Knoten B. Im Gegensatz zur Politik des MIN-PACKAGE NODE ist bei Konfiguration der Failover Policy CONFIGURED-NODE das Verhalten so, wie in der Abbildung 6.6, »MC/ServiceGuard – CONFIGURED-NODE Failover Policy« dargestellt. Hier würden die Packages beim Cluster-Start ebenfalls auf den Knoten A, B und C starten. Beim notwendigen Failover würde der Schwenk dann aber gemäß der Prioritäts-Reihenfolge im Konfigurationsfile erfolgen, das Package 2 würde also zusätzlich zum Package 3 auf dem Cluster-Knoten C gestartet.

Failback-Politik Der Parameter FAILBACK-POLICY im Package-Konfigurationsfile beeinflusst, ob nach einem erfolgten Package Failover aufgrund eines Fehlers das Package nach Behebung des Fehlers wieder auf den gestarteten Primary-Knoten für das Package zurückschwenkt oder nicht. Abbildung 6.7: MC/ServiceGuard – Automatisches Failback nach erfolgtem Failover


F C H B A


F C H B A


F C H B A

F C H B A

F C H B A


F C H B A


F C H B A

F C H B A

F C H B A


F C H B A


F C H B A

F C H B A

F C H B A

F C H B A


F C H B A

F C H B A

Der konfigurierte Primary Node eines Packages ist der erste Knoten in der Node List des Packages im Package-Konfigurationsfile. Der Parameter FAILBACK-POLICY kann auf die beiden Werte

296

Hochverfügbare Cluster-Software 왘 AUTOMATIC und 왘 MANUAL

gesetzt werden. Dabei bedeutet AUTOMATIC, dass bei Restart des eigentlichen Primary Node des Packages, nachdem dieses im Rahmen eines Failover auf einen Adoptiven Knoten geschwenkt war, das Package automatisch auf dem Adoptiven Knoten gestoppt und auf dem Primären Knoten neu gestartet wird. Der entsprechende Part im ASCII-Package-Konfigurationsfile lautet: # # # # # # # # #

Enter the failback policy for this package. This policy will be used to determine what action to take during failover when a package is not running on its Primary Node and its Primary Node is capable of running the package. Default is MANUAL which means no attempt will be made to move the package back to ist Primary Node when it is running on an alternate node. The alternate policy is AUTOMATIC which means the package will be moved back to its Primary Node whenever the Primary Node is capable of running the package.

FAILBACK-POLICY

AUTOMATIC

Abbildung 6.7 zeigt einen 4-Knoten-Cluster, dessen FAILOVER-POLICY auf CONFIGURED-NODE und dessen FAILBACK-POLICY auf AUTOMATIC gesetzt ist. Dabei sind im jeweiligen Package-Konfigurationsfile auf den beteiligten Knoten die Parameter wie folgt gesetzt: PACKAGENAME

NODE-NAME Liste

FAILOVERPOLICY

Package 1

Knoten A, Knoten D

CONFIGUREDNODE

AUTOMATIC

Package 2

Knoten B, Knoten D

CONFIGUREDNODE

AUTOMATIC

Package 3

Knoten C, Knoten D

CONFIGUREDNODE

AUTOMATIC

FAILBACK-POLICY

Tab. 6.2: MC/Serviceguard – Parameter Settings für Failback Policy AUTOMATIC im 4-Knoten-Cluster

Nach dem Fehler des Knotens B re-formiert sich der Cluster neu mit den verbleibenden Knoten A, C und D. Gemäß der Priorität in der NODE-NAME-Liste im Konfigurationsfile für Package 2 wird dieses auf den Knoten D geschwenkt und dort neu gestartet. Nach der Re-Formierung des Clusters läuft Package 2 also auf dem Knoten D. Abbildung 6.8 zeigt das Verhalten des Packages, nachdem der Fehler des Knotens B behoben wurde und eine Cluster-Re-Formierung automatisch stattgefunden hat, um Knoten B wieder in den Cluster zu integrieren.

297

6 Hochverfügbare SAN – Software-Komponenten Abbildung 6.8: MC/ServiceGuard – Automatisches Failback nach erfolgtem Failback


F C H B A


F C H B A


F C H B A

F C H B A

F C H B A


F C H B A


F C H B A

F C H B A

F C H B A


F C H B A


F C H B A

F C H B A

F C H B A


F C H B A

F C H B A

F C H B A

Die Ausgangslage ist hier der erfolgte Failover – Package 2 läuft auf Knoten D. Der Cluster re-formiert sich, Knoten B ist wieder verfügbar. Package zwei wird automatisch anschließend an die Re-Formierung auf dem Knoten D gestoppt und auf dem Knoten B neu gestartet. Das Setzen der FAILBACK-POLICY auf AUTOMATIC ist mit ausgesprochener Vorsicht zu genießen. Das automatische Failback führt stets dazu, dass das Package automatisch auf dem Adoptive Node gestoppt wird und auf dem Primary Node gestartet wird, sobald dieser nach Re-Formierung des Clusters wieder verfügbar ist. Dies führt stets zu einer mehr oder weniger kurzen Ausfallzeit für die Applikation. Soll bei einer Konfiguration mit AUTOMATIC FAILBACK POLICY verhindert werden, dass dieser Applikations-Timeout zu einem kritischen Produktionszeitpunkt der Applikation stattfindet, muss explizit darauf geachtet werden, dass der wiederhergestellte Primäre Knoten nicht neu gestartet wird und die Re-Formierung des Clusters und damit den Package Failback erzwingt.

Bemerkungen zur Kombination von Package Failover und Failback Die Package-Konfiguration im obigen Beispiel mit der FAILOVER-POLICY des CONFIGURED-NODE und der FAILBACK-POLICY des AUTOMATIC Failback macht den Zustand des Clusters zu jedem Zeitpunkt vorhersehbar. Nach einem Failover läuft das Package auf seinem Adoptiven Knoten, nach dem Failback wieder auf seinem Primären Knoten.

298


Anders stellt sich die Situation dar, wenn für die Package-Konfiguration als FAILOVER-POLICY die Strategie MIN-PACKAGE-NODE zusammen mit der AUTOMATIC Failback Policy gewählt wurde. Hier ist der Zustand des Clusters zu einem gegebenen Zeitpunkt nicht mehr vorhersehbar. Dies geschieht deshalb, weil der Knoten, der die minimale Anzahl von Packages hosted, nicht zu jedem Zeitpunkt der gleiche sein muss. So kann auch nach Cluster-Re-Formierung durch Wiedereingliederung des ursprünglichen Primären Knotens der Failback nicht stattfinden, da der ursprüngliche Primäre Knoten evtl. nicht der Knoten ist, der die wenigsten Cluster-Packages bedient.

Package-Konfigurationsdateien Mit dem Kommando cmmakepkg wird ein Package-Konfigurationsfile angelegt. Mit jeder neuen Release von MC/ServiceGuard kann es notwendig sein, ein neues Package-Konfigurationsfile anzulegen. »Alte« Packages können jedoch auch stets mit den »alten« Konfigurationsfiles betrieben werden. Dabei ist jedoch zu beachten, dass bei einem Releasewechsel dann vom Package-Manager – unabhängig von den Einstellungen im »alten« Konfigurationsfile – die Standard FAILOVER-POLICY (CONFIGURED-NODE) und FAILBACKPOLICY (MANUAL) betrieben werden. Um diese zu ändern, sollte mit cmmakepkg ein neues Konfigurationsfile angelegt und editiert werden.

Applikations-Recovery – Zusammenfassung der Vorgehensweise des Package-Managers Folgende Schritte werden beim Recovery einer Applikation gegangen, um diese mit der geringsten Ausfallzeit wiederherzustellen: 왘 Der Cluster-Knoten, der das Applikations-Package bedient, hat einen

Fehler. 왘 Der Cluster re-formiert sich ohne den fehlerhaften Cluster-Knoten. 왘 Der Adoptive Node übernimmt das Package. 왘 Ein fsck beseitigt Filesystem-Inkonsistenzen, die durch den Fehler im

Cluster-Knoten aufgetreten sind. 왘 Die Applikation startet auf dem Adoptiven Knoten. Ein automatisches Re-

covery findet statt, falls die Applikation eine Datenbank-Applikation ist. 왘 Die Benutzung der Applikation wird auf dem Adoptiven Knoten freige-

geben.

299


6.1.2.4

Network-Manager – Arbeitsweise

Der Network-Manager von MC/ServiceGuard soll Netzwerk- und Kabelfehler entdecken und diese insofern umgehen, dass die Netzwerk-Services für die Netzwerk-Clients weitestgehend verfügbar bleiben. Dies bedeutet für die praktische Arbeitsweise, dass jedes Package eines Knoten die IP-Adresse der ersten LAN-Schnittstellenkarte des Knotens zugewiesen bekommt und die Funktionsfähigkeit dieser Karte sowie sämtlicher sekundären Schnittstellen(karten) überwacht wird und im Falle eines Fehlers auf der ersten LAN-Schnittstellenkarte auf eine sekundäre Schnittstelle umgeschaltet wird.

Stationäre und Relocatable IP-Addressen Relocatable IP-Adressen sind ein zentrales Funktionselement in einer MC/ServiceGuard-Konfiguration. Sie tragen erheblich zur Verfügbarkeit einer Applikation bei. Bei den IP-Adressen unterscheidet man zwischen 왘 stationären IP-Adressen, die als »normale« IP-Adressen einer Netzwerk-

Karte sich niemals ändern und daher auch »normal« behandelt werden und 왘 relocatable IP-Adressen die auf der Basis der Kritizität einer Anwendung

vergeben werden. Wird ein Applikations-Client an die Anwendung gebunden, so geschieht dies über die relocatable IP-Adresse. Dadurch wird er stets mit der Anwendung verbunden, gleichgültig auf welchem Cluster-Knoten diese gerade läuft. Jeder Cluster-Knoten besitzt für jedes aktive Netzwerk-Interface (LANKarte) eine IP-Adresse. Diese Adresse wird als die stationäre IP-Adresse bezeichnet und in der Datei /etc/rc.config.d/netconf konfiguriert. Eine solche stationäre IP-Adresse kann nicht auf einen anderen (Adoptiven) Knoten des Clusters übertragen werden, jedoch sehr wohl auf eine Standby NetzwerkKarte desselben Cluster-Knotens. Die stationäre IP-Adresse wird nicht mit Packages assoziiert, sondern lediglich zur Übertragung von HeartbeatInformationen und anderen – nicht auf Package bezogenen Daten – genutzt. Jedem Package werden zusätzlich zu dieser stationären IP-Adresse des Cluster-Knotens eine oder mehrere eindeutige IP-Adressen assoziiert. Mithilfe des Kommandos cmmodnet innerhalb des Package Kontrollscripts wird beim Startup des Packages diese IP-Adresse des Packages dem primären LAN-Interface zugewiesen. Diese mit dem Package verknüpften IP-Adressen bezeichnet man als relocatable IP-Adressen oder Package IP-Adressen oder auch floating IP-Adressen, da diese Adressen mit dem Package auf einen weiteren Knoten des Clusters switchen können, wenn ein Package Failover stattfindet. MC/ServiceGuard beschränkt die Anzahl der relocatable IP-Adressen eines Clusters auf 200 in maximal 30 Packages.

300


Die relocatable IP-Adresse funktioniert quasi als virtuelle Host-IP-Adresse, die dem Package zugeordnet wird. Wenn via DNS (Domain Name System) jedem Package ein eindeutiger Name vergeben wird, kann ein jedes Programm den Package-Namen als Eingabe für die Funktion gethostbyname() verwenden. Diese Funktion liefert als Ausgabe die relocatable IP-Adresse des Packages. Kommt es zu einem Fehler der Netzwerk-Schnittstellenkarte, werden sowohl die stationäre IP-Adresse der Karte als auch sämtliche relocatable IPAdressen der Packages, die dieser Schnittstellenkarte via cmmodnet assoziiert wurden, auf eine Standby-LAN-Schnittstelle übertragen. Existiert im Knoten, der das Package betreibt, keine Standby NetzwerkSchnittstellenkarte oder ist auch diese defekt, so kommt es zu einem Package Failover auf den nächsten verfügbaren Adoptiven Knoten. Beim Transfer des Packages wird auch jede relocatable IP-Adresse des Packages auf diesen Adoptiven Knoten übertragen. Der Vorteil der relocatable IP-Adressen liegt darin, dass jede Applikation das Package über diese adressieren kann, ohne die stationäre IP-Adresse des Hosts kennen zu müssen, der das Package gerade bedient. Nur so kann ein Package Failover auf einen anderen Cluster-Knoten geschehen, ohne dass sämtliche Clients der Applikation(en) des Packages langwierige und administrationsaufwändige Rekonfigurationen erfahren müssen.

Hinzufügen und Löschen der Relocatable IP-Addressen Das Hinzufügen und Löschen der relocatable IP-Adressen des Packages zu/ von dem beim Package-Start verwendete IP-Subnet erfolgt durch die Zuweisungen mit dem Kommando cmmodnet im Package-Kontrollscript. Beim Start des Packages wird seine relocatable IP-Adresse dem verwendeten IP-Subnet hinzugefügt, beim Stoppen des Packages wird sie aus dem verwendeten IPSubnet wieder entfernt. Sämtliche IP-Adressen – stationäre wie relocatable – werden lediglich auf der primären Netzwerk-Schnittstellenkarte konfiguriert, Standby-Karten erhalten keine IP-Adresskonfiguration. Multiple IP-Adressen auf einer Netzwerk-Schnittstellenkarte müssen zum gleichen IP-Subnet gehören.

Load Sharing Unter MC/ServiceGuard ist es möglich, mehrere Services auf einem ClusterKnoten mit derselben IP-Adresse zu verknüpfen. Dies hat zur Folge, dass beim Switch eines dieser Services auf einen anderen Cluster-Knoten die anderen Services, die dieselbe IP-Adresse teilen, ebenfalls auf den anderen Cluster-Knoten wechseln. Dies geschieht natürlich auch mit allen damit verbundenen Folgen, wie z.B.

301

6 Hochverfügbare SAN – Software-Komponenten 왘 Ausfall des Services für die Service-Clients während des Schwenks 왘 Startup-Zeit des Services auf dem neuen Knoten etc.

Ein Load Sharing ohne diese unangenehmen Nebenwirkungen kann dadurch erreicht werden, dass jeder Service zu einem eigenen Package geschnürt wird und eine eigenständige eindeutige IP-Adresse erhält. Dadurch wird verhindert, dass beim Switch eines Services alle anderen Services ebenfalls den Cluster-Knoten wechseln – ein Administrator kann jedoch auch manuell einen oder mehrere Services bei Bedarf einem Cluster-Knoten zuweisen, der zum betrachteten Zeitpunkt eine niedrigere Auslastung aufweist.

Monitoring der LAN-Interfaces MC/ServiceGuard pollt in diskreten Zeitabständen sämtliche NetzwerkSchnittstellenkarten, die im Konfigurationsfile des Clusters konfiguriert wurden. Dabei werden Netzwerkfehler wie folgt entdeckt: 왘 Eine Schnittstellenkarte in einem bridged Netzwerk wird als die Poller-

Schnittstelle definiert. 왘 Der Poller pollt sämtliche anderen primären und sekundären Schnittstel-

len des bridged Netzwerks, um deren Funktionsfähigkeit zu überprüfen. 왘 Normalerweise wird als Poller eine Standby-Schnittstelle ausgewählt.

Nur wenn kein Standby verfügbar ist, wird als Poller eine primäre Schnittstellenkarte verwendet. 왘 Die Poller-Schnittstelle schickt Acknowledgement LAN Packets an sämt-

liche konfigurierten Schnittstellenkarten, die diese als Acknowledgement zurücksenden. 왘 Kann eine der angewählten Schnittstellen nicht antworten oder stimmt

die Anzahl der an eine Schnittstelle gesendeten und von dieser zurückgeschickten Pakete über einen definierten Zeitraum nicht überein, so wird diese Schnittstelle als DOWN, d.h. nicht betriebsbereit, definiert. Ist eine Schnittstellenkarte nicht betriebsbereit, so werden die von dieser Schnittstelle bedienten Services auf die lokale Standby-Schnittstelle verschoben. Ist auch diese nicht verfügbar, so kommt es zu einem Failover auf einen anderen Cluster-Knoten.

Local Switching Ein lokaler Netzwerk Interface Switch findet dann statt, wenn beim Monitoring der LAN-Interfaces der Ausfall einer LAN-Schnittstelle festgestellt wird. Dann wird – wie bereits oben erläutert – zunächst versucht, die betroffenen Services auf eine lokale Backup-LAN-Schnittstellenkarte zu übertragen. Dabei darf die Standby-LAN-Schnittstellenkarte keinerlei IP-Adresse konfiguriert haben, da ihr die IP-Adresse der fehlgeschlagenen primären Schnittstellenkarte zugewiesen wird.

302


Segment B

Segment A S t a n d b y

P r I m a r y

L A N


H e a r t b e a t

H e a r t b e a t

H e a r t b e a t

L A N

u n d

u n d D a t e n

H U B

L A N

D a t e n


F C H B A

F C H B A


Abbildung 6.9: MC/ServiceGuard – Ausgangszustand des Local Network Switchings

F A

Local Storage


F C H B A


F A

F C H B A

Im Falle eines lokalen Switches gehen die TCP/IP-Verbindungen des Ethernet nicht verloren, jedoch die Verbindungen IEEE 802.3. Da Ethernet, Token Ring und FDDI das ARP-Protokoll verwenden und HP/UX beim lokalen Switch eine »unsolicited« ARP Message an sämtliche Remote Systeme versendet, um das Address Mapping zwischen den MACAdressen (Adressen der Verbindungsebene im ISO/OSI-Schichten-Modell, vgl. Kapitel 2) und den Adressen der IP-Ebene zu korrigieren, bleibt der Switch für Ethernet-Clients unbemerkt. IEEE 802.3 kennt jedoch eine solche rearp-Funktion nicht. Während des Transfers gehen nun zuwar IP-Pakete verloren, dies wird jedoch vom TCP (Transmission Control Protocol) bemerkt und die verloren gegangenen Pakete werden an die neue Schnittstelle zurückübertragen. Wird hingegen das UDP (User Datagram Protocol) verwendet, so werden verloren gegangene Pakete nicht erneut übertragen. Da jedoch UDP als unzuverlässiges Protokoll eingestuft ist, müssen UDP-Client-Applikationen ihrerseits sowieso verlorene Netzwerk-Pakete und das Recovery dieser Situation handhaben. Beim lokalen Netzwerk-Switch ist lediglich zu beachten, dass dieser nur zwischen zwei LANs des gleichen Typs funktioniert. Ein lokaler Switch von Ethernet auf FDDI oder umgekehrt ist nicht möglich. Abbildung 6.9 zeigt die Ausgangssituation vor einem lokalen Switch. Die beiden Segmente des bridged Network werden durch einen Hub verbunden. Die primäre Verbindung erfolgt über die dick markierte Verbindung des Segments B. Das Segment B fungiert als Standby-Segment.

303

6 Hochverfügbare SAN – Software-Komponenten Abbildung 6.10: MC/ServiceGuard – Netzwerk nach Local Switching

Segment B


P r I m a r y

L A N


H e a r t b e a t

H e a r t b e a t

H e a r t b e a t

L A N

u n d

u n d D a t e n

H U B

L A N

D a t e n


F C H B A

F C H B A


Local Storage


F C H B A


F A

F C H B A

Kommt es aufgrund eines Fehlers der primären LAN-Schnittstellenkarte des Cluster-Knotens A zu einem lokalen Switching, so übernimmt die StandbySchnittstellenkarte. Die IP-Adressen werden auf den Hardware-Pfad der Standby-Schnittstellenkarte umgeschaltet (ebenfalls dick markiert). Der Wechsel der Schnittstellenkarte und des Übertragungspfades ist für TCP/IP transparent. Sämtliche Applikationen laufen wie bisher auf ihren primären Cluster-Knoten. Auf dem Cluster-Knoten B erscheint aufgrund des Switches lediglich die Auslieferung der Packages etwas verspätet, da evtl. falsch transferierte Netzwerk-Packages via TCP neu übertragen werden müssen. MC/ServiceGuard unterstützt einen solchen lokalen Failover auf EthenetNetzwerken, deren Netzwerk-Schnittstellenkarten mit dem »Ethernet protocol« konfiguriert wurden oder bei denen zwischen den Interfaces »SNAP encapsulation within IEEE 802.3 protocol« konfiguriert wurde. Beide Protokolle können nicht parallel auf demselben Interface gefahren werden. Weiter kann – wie schon oben erwähnt – ein lokaler Failover nicht zwischen Interfaces stattfinden, die unterschiedliche Protokolle (Ethernet oder FDDI) betreiben. Abbildung 6.11 soll das letzte Beispiel für das Auftreten lokaler Switches darstellen. Hier wird der Fall beschrieben, dass auf das Backup LAN-Segment (Segment A) zurückgegriffen werden muss, wenn aufgrund eines Kabelfehlers das komplette primäre LAN-Segment (Segment B) verloren geht.

304


Segment B


P r I m a r y

L A N


H e a r t b e a t

H e a r t b e a t

H e a r t b e a t

L A N

u n d

u n d D a t e n

H U B

L A N

D a t e n


F C H B A

F C H B A


Abbildung 6.11: MC/ServiceGuard – Lokaler Switch nach Kabelfehler

F A

Local Storage


F C H B A


F A

F C H B A

Das lokale Switching des Netzwerks auf Standby-Netzwerkkomponenten ist für Cluster mit zwei oder mehr Cluster-Knoten entwickelt worden. Dennoch funktioniert es auch für einen Cluster, der lediglich aus einem Knoten besteht. Ein solcher kann dann konfiguriert werden, wenn lediglich die Vorteile des lokalen Switching gewünscht werden, jedoch keine weitere Verfügbarkeitsanforderung einen weiteren Cluster-Knoten legitimiert.

Remote Switching Ein Remote Switching bedingt den Failover eines oder mehrerer Packages mit den diesem/diesen assoziierten IP-Adressen auf einen Adoptiven ClusterKnoten. Auf dem Adoptiven Cluster-Knoten muss ein Subnet des gleichen Typs konfiguriert sein und betriebsbereit sein, damit der remote Switch auf den Cluster-Knoten funktioniert und die Packages auf diesem gestartet werden können. Dabei ist zu beachten, dass für Packages, die für multiple Subnets konfiguriert wurden, sämtliche benötigten Subnets auf dem Adoptiven Cluster lauffähig sein müssen, bevor nach dem Schwenk des Packages dieses wieder gestartet werden kann. Im Gegensatz zum lokalen Switching gehen beim remote Switching die TCP/IP Verbindungen verloren. Um wieder die Connectivity zu erlangen müssen sich sämtliche TCP-Applikationen neu einwählen, was nicht automatisch von MC/ServiceGuard betrieben werden kann.

305

6 Hochverfügbare SAN – Software-Komponenten Abbildung 6.12: MC/ServiceGuard – Remote SwitchingAusgangssituation

Segment A

Client 1

P r i m a r y L A N H e a r t b e a t u n d

Client 2

D a t e n

Segment B S e c o n d a r y

Package1 IP131.14.10.2

HP-Server ClusterKnoten A

F C H B A

L A N H e a r t b e a t u n d D a t e n

F C H B A


Local Storage

Package2 IP131.14.10.8-

HP-Server ClusterKnoten B

F C H B A


F A

F C H B A

In der Ausgangssituation für das Remote Switching sei ein 2-Knoten-Cluster in normaler Funktionsbereitschaft dargestellt. Das Package 1 läuft auf dem Cluster-Knoten A, Package 2 läuft auf dem Cluster-Knoten B. Zwei Clients verbinden sich mit dem entsprechenden Knoten über die relocatable IPAdresse des Packages, das sie nutzen wollen. Jeder der beiden Cluster-Knoten besitzt eine stationäre IP-Adresse, jedes Package eine relocatable IPAdresse, über die Clients sich mit dem Server verbinden. Nun kommt es zu einem Fehler des Knotens A, durch den ein lokales Switching verhindert wird. Package 1 wird auf den Cluster-Knoten B transferiert. Die relocatable IP-Adresse des Packages 1 (131.14.10.2 in unserem Beispiel) wandert mit dem Package auf den Cluster-Knoten B. Das Package 1 wird nun über den Cluster-Knoten B verfügbar. Die Clients verbinden sich wie gehabt über die relocatable Package-IP-Adresse mit ihrem Server, dieser wird jedoch nun von Cluster-Knoten B betrieben.

Switching und ARP-Messages Wird eine relocatable IP-Adresse auf ein neues Interface, sei es ein lokales (zweite Netzwerkkarte, die nicht als Standby-Karte betrieben wird) oder ein remote Interface gelegt, so wird eine ARP-Message an alle Knoten des Netzes verschickt, die diese Veränderung des Mappings zwischen den IP-Adressen und den MAC-Adressen der Verbindungsebene anzeigt. Je verschobene IPAdresse wird eine solche ARP-Message verschickt – die Empfängerknoten müssen darauf den Cache-Eintrag des ARP ändern, um die so erfolgte Änderung »permanent« zu speichern.

306


Segment A

Client 1

P r i m a r y L A N H e a r t b e a t u n d

Client 2

D a t e n

Abbildung 6.13: MC/ServiceGuard nach Remote Switch

Segment B S e c o n d a r y

HP-Server ClusterKnoten A

F C H B A

F C H B A

L A N H e a r t b e a t

F C 131.14.10.8- H Package1 B IPA

u n d

HP-Server Cluster- F Knoten B C

D a t e n


Local Storage Disk Group Package 2

Package2 IP-

131.14.10.2

Array

F A

H B A

Aktuell wird die ARP-Message dann versendet, wenn die relocatable IPAdresse des auf den Adoptiven Cluster-Knoten geschwenkten Packages dessen Netzwerkkonfiguration hinzugefügt wird. Eine ARP-Message wird in der Form einer ARP-Anforderung geschickt. Dabei werden die Adressfelder sowohl des Sender- als auch des Empfänger-Protokolls auf die gleiche relocatable IP-Adresse gesetzt. Dadurch wird erreicht, dass die Empfänger-Knoten nicht mit einem Acknowledgement auf diesen ARP-Request reagieren.

6.1.2.5

Reaktion auf Cluster Failures

Die Reaktion auf Cluster-Fehler ist bei MC/ServiceGuard bedingt konfigurierbar. Die meisten Reaktionen auf Hardwarefehler sind softwareseitig fest eingebrannt. Fehler eines Packages oder eines Services sind jedoch sehr wohl durch das Systemmanagement konfigurierbar.

Node Failure mit Transfer of Control Die wohl deutlichste Reaktion auf einen Fehler innerhalb eines MC/ServiceGuard Clusters ist ein seitens HP-UX erzwungener TOC (Transfer of Control). Dabei handelt es sich um ein unverzügliches Shutdown der System Processing Unit (SPU), ohne eine graceperiod zu gewähren, also ohne den Applikationen und Services die Möglichkeit zu bieten, ordnungsgemäß herunterzufahren. Ein solcher TOC erfolgt stets bei massiven Fehlern, um einen Verlust der Datenintegrität durch Hardwarefehler auszuschließen. Fehler, die einen TOC erzwingen, sind:

307

6 Hochverfügbare SAN – Software-Komponenten 왘 ein kernel hang von HP-UX (Betriebssystem-Selbstblockade), 왘 ein kernel spin von HP-UX (Betriebssystem befindet sich in einer Endlos-

schleife), 왘 ein Runaway Realtime Process (Echtzeitprozess mit hoher Priorität blo-

ckiert das Betriebssystem), 왘 der MC/ServiceGuard Daemon cmcld schlägt selbst fehl.

Beim TOC wird ein Systemdump erzeugt und folgende Meldung auf die Administrationskonsole geschrieben: MC/ServiceGuard: Unable to maintain contact with cmcld daemon. Performing TOC to ensure data integrity.

MC/Serviceguard erzeugt selbst unter bestimmten Umständen ebenfalls einen TOC. Ist für einen bestimmten Dienst der Service Failfast-Parameter im Package-Konfigurationsfile aktiviert, so reagiert der komplette ClusterKnoten mit einem TOC, sobald dieser Service einen Fehler hat. Ist der Package Failfast-Parameter NODE-FAIL-FAST-ENABLED im Package-Konfigurationsfile aktiviert, so kommt es zu einem TOC des gesamten ClusterKnotens, sobald ein Fehler das Package Kontrollscript beendet. Weitere Fehler, die einen TOC erzwingen, obwohl die Services funktionsfähig sind und die Packages laufen, sind: 왘 Verlust des Heartbeat-Signals 왘 Verlust weiterer kritischer Daemons neben dem Daemon cmcld

In einigen Fehlerfällen wird vor dem TOC ein Reboot des Systems versucht. Schlägt dieser Versuch jedoch fehl, d.h. dauert er länger als der Safety Timer vorsieht, so erfolgt der TOC. Kommt es jedoch zu einem TOC, erfolgt automatisch auch der Remote Switch.

Reaktion auf Hardware Failures Kommt es zu einem ernsthaften Hardwarefehler (nahezu jeder physikalische Schaltkreisfehler der SPU), so erkennt MC/ServiceGuard diesen sofort als Fehler des betroffenen Cluster-Knotens und transferiert die Packages dieses Knoten auf einen verfügbaren Adoptiven Knoten im Cluster. Wohin die Packages transferiert werden, ist abhängig von den Einträgen für den Primary Node und die Reihenfolge der Alternate Nodes dieses Packages im Package-Konfigurationsfile. Der Transfer des Packages auf einen Adoptiven Knoten bedeutet jedoch nicht den gleichzeitigen Transfer des Program Counters für dieses Package. Dies bedeutet, dass sämtliche Prozesse innerhalb des transferierten Packages erneut (automatisch) gestartet werden müssen. Für einen automatischen Restart einer Applikation nach einem Remote Switch muss diese crashtole-

308


rant geschrieben sein, d.h. sämtliche Prozesse einer solchen Applikation müssen solche Restart-Situationen erkennen und automatisch darauf reagieren können. Folgende Reaktionen erfolgen bei dedizierten Hardware-Fehlern: 왘 Ein Fehler einer LAN-Schnittstellenkarte bewirkt einen lokalen Switch

auf eine Standby LAN-Schnittstellenkarten, falls eine existiert. 왘 Schlägt der Heartbeat-LAN fehl und existiert kein Standby Heartbeat-

LAN, so kommt es für den betroffenen Cluster-Knoten zu einem TOC. 왘 Kommt es zu einem Fehler auf einer Daten-LAN-Schnittstelle, so gibt es

nur dann einen TOC, wenn der Package Failfast-Parameter des Packages aktiviert ist. 왘 Plattenfehler werden durch Einsatz von RAID-1, Remote Mirrors und

anderer Plattenschutzverfahren vermieden. Sie erzeugen in der Regel keinen TOC, müssen jedoch überwacht werden. Dies geschieht meist über Administrations-Software, die seitens der Hersteller der Storage Arrays geliefert wird. 왘 Der Schutz vor Spannungsfehlern ist lediglich durch UPS-Absicherung

(Uninterruptable Power Supply) möglich. Der Verlust eines Power Supply selbst wird seitens MC/ServiceGuard nicht erkannt. Kommt es jedoch zu einem Panic eines Cluster-Knotens, weil dessen Power Supply(ies) ausfällt, so wird der Panic als solcher erkannt und das remote Switching der Packages des Knotens initiiert.

Reaktion auf Package und Service Failures Im Regelfall führt der Fehler eines Packages oder eines Dienstes innerhalb des Packages dazu, dass das Package regulär heruntergefahren wird (das Package Kontrollscript läuft mit dem Parameter »STOP«) und auf einem Adoptiven Knoten neu gestartet wird. Ist der Zugriff auf eine Ressource (Volume) nicht mehr möglich, so vollzieht der Package-Manager einen Package Failover auf einen anderen ClusterKnoten. Dieses Standardverhalten bei Package-Fehlern kann benutzerdefiniert geändert werden, indem anstelle des Package Transfers ein TOC erzeugt wird, der den kompletten Cluster-Knoten crashed. Hier versucht MC/ServiceGuard vor dem TOC einen Reboot des Systems, der – falls die Caches rechtzeitig zurück auf Platte geschrieben werden können – den TOC verhindert. Es ist jedoch stets sichergestellt, dass der Cluster-Knoten binnen Sekunden herunterfährt. Ist ein Package crashtolerant, ein reguläres STOP des Packages jedoch zeitaufwändig, kann diese Methode das Package auf einem anderen Knoten schneller wieder verfügbar machen, als die Standard-Methode. Dabei ist jedoch daran zu erinnern, dass ein TOC den Transfer sämtlicher Packages des Knoten erzwingt, während ein regulärer STOP dediziert nur das fehlerhafte Package schwenken lässt.

309


Welches der beiden Verhalten realisiert wird, wird mithilfe der Package- und Service Failfast-Parameter gesteuert, die oben bereits beschrieben wurden.

Automatischer Restart von Services Nach einem Servicefehler kann mithilfe eines Restart-Parameters (definiert die Anzahl von Restart-Versuchen vor Package Failover) in der Beschreibung des Services im Package-Kontrollfile konfiguriert werden, dass dieser Service zunächst lokal erneut gestartet werden soll. Bei jedem regulären Start des Services wird in seiner Umgebung die Umgebungsvariable RESTART-COUNT gesetzt. Während der Laufzeit des Services kann dieser die Umgebungsvariable auslesen, um festzustellen, ob sich der Inhalt geändert hat, also ob ein Restart stattgefunden hat. Ist es zu einem Restart gekommen, so können von diesem Service die notwendigen Aktionen wie z.B. Cleanups unternommen werden.

Network Communication Failures Ein bedeutendes Element im Cluster ist die Funktionsbereitschaft des internen (Heartbeat) Netzwerks. Dieses überwacht den Cluster, jeder Knoten prüft die Heartbeat Messages der anderen im Cluster beteiligten Knoten, um zu jedem Zeitpunkt sicherzustellen, dass sämtliche Cluster-Knoten untereinander kommunizieren können. Empfängt ein Knoten für eine konfigurierbare Zeitdauer keine Heartbeat Messages oder sendet er keine, so erfolgt ein TOC dieses Cluster-Knotens. In einem 2-Knoten-Cluster wird für die Heartbeat-Informationen eine zusätzliche RS-232-Leitung empfohlen, die den TOC vor dem momentanen Verlust der Heartbeat-Informationen bei Überlastung der Netzkapazität schützen soll. Diese Leitung ist auch für die Entdeckung von Netzwerkfehlern und deren Weitermeldung von immenser Bedeutung.

6.1.2.6

MC/ServiceGuard Cluster-Management

Abschließend sollen nochmals zusammenfassend die wichtigsten Management-Informationen für MC/ServiceGuard dargestellt werden. 왘 MC/ServiceGuard residiert in /usr/bin.

Die Kommandos für MC/ServiceGuard können unterteilt werden in: 왘 die Konfigurationskommandos cmquerycl, cmcheckconf, cmapplyconf,

cmmakepkg, 왘 die Cluster-Operationskommandos cmruncl,

cmhaltcl,

cmrunmode,

cmhaltmode, 왘 die Package Operationskommandos cmrunpkg, cmhaltpkg, cmmodpkg.

310


Als MC/ServiceGuard Daemons müssen laufen: 왘 cmcld und 왘 cmlvmd.

Diese Daemons dürfen nicht via kill-9 gestoppt werden, da dies entweder zu einem Hang von MC/ServiceGuard, des kompletten Clusters oder zu einem PANIC führen kann. 왘 Das Standardverzeichnis für die Cluster- und Package-Konfigurationsfi-

les von MC/ServiceGuard ist üblicherweise /etc/cmcluster.

6.1.3

6.1.3.1

Cluster-Software-Implementierung für Sun mit Veritas Cluster Server (VCS) VCS-Architektur Abbildung 6.14: VCS – Basiskonfiguration VCS - Shared Storage

VCS Cluster System A

VCS Cluster System B

VCS Cluster System D

VCS Cluster System C

VCS - Privates Netzwerk VCS - Public Netzwerk

Client

Client

Client

Ein Veritas Cluster-Server (VCS) Cluster besteht aus mehreren Rechnersystemen, die in unterschiedlichen Kombinationen an gemeinsam genutzten Massenspeichern angeschlossen sind. VCS überwacht und steuert die Applikationen, die auf den Cluster-Members laufen und startet diese Applikationen neu, abhängig davon, ob ein Fehler aus einer Vielzahl von durch

311


VCS überwachten Hardware- oder Software-Fehlerereignissen aufgetreten ist. Ziel ist es auch hier, den Betrieb der Client-Anwendungen mit so wenig Ausfallzeit wie möglich zu realisieren. So wenig Ausfallzeit wie möglich bedeutet bei einigen Applikationen wie z.B. NFS (Network File System), dass ein Ausfall und ein damit von VCS initiierter Schwenk auf einen anderen Cluster-Member, für die Benutzeranwendungen transparent bleibt. Andere Applikationen, wie z.B. Downloads aus dem Internet, müssen im Fehlerfall reinitiiert werden. Ein VCS-Cluster besteht aus mehreren Systemen, die an gemeinsam genutzte Massenspeicher angeschlossen sind. Die Client-Workstations greifen auf die Services der VCS-Cluster-Systeme über ein öffentliches Netzwerk zu. Die Überwachung der Cluster-Systeme durch VCS und die interne Kommunikation der Systeme untereinander erfolgt über das private VCS Netzwerk. Abbildung 6.15: VCS – Shared Storage VCS - Shared Storage





Auf jedem Cluster-System läuft eine VCS Engine. Jedes Cluster-System ist eine so genannte replicated state machine, eine Maschine, deren Status repliziert wird, d.h. eine Maschine, die durch eine andere ersetzt werden kann, die mit den identischen Konfigurationsdaten der ersten (Replikat) deren Applikationen bedient. Die Status-Informationen werden über das private Netzwerk zwischen den Cluster-Systemen ausgetauscht. Durch den Austausch der Status-Informationen teilen sich sämtliche Cluster-Members die Informationen über die Verfügbarkeit der gemeinsam genutzten Ressour-

312


cen. Weiter ist es dadurch möglich zu entscheiden, ob ein Cluster-System aktiv ist, nicht betriebsbereit ist und den Cluster verlässt oder in ihn zurückkehrt. Um den Austausch der Status-Informationen der Cluster-Systeme zu gewährleisten, ist neben dem privaten Netzwerk der VCS-Systeme ein weiterer Kommunikationskanal notwendig, der den VCS-Cluster mit der geeigneten Redundanz vor Netzwerkfehlern schützt (vgl. Abb. 6.15). Eine VCS Hardware-Konfiguration besteht stets aus mehreren Cluster-Systemen, die über I/O-Kanäle an Shared Storage angeschlossen sind. Durch die Implementierung von Shared Storage haben mehrere Cluster-Systeme (gleichzeitigen) Zugriff auf dieselben Daten. Dies ist die Voraussetzung dafür, dass VCS eine Applikation auf einem anderen Cluster-Server starten kann, als demjenigen, auf dem sie bis zum Eintritt eines Fehlerfalles lief. Dabei kann VCS jeden denkbaren Freiheitsgrad bzgl. physically attached shared storage realisieren, indem die beiden Varianten des Shared Storage 왘 Shared Storage und 왘 Verteilter (Distributed) Shared Storage

unterstützt werden. Abbildung 6.16: VCS – Verteilter Shared Storage





In der Variante Shared Storage wird der Massenspeicher quasi wie in den im Kapitel 4 beschriebenen Storage-Konsolidierungsvarianten gemeinsam von den Cluster-Systemen genutzt.

313


Die Variante des verteilten Shared Storage würde bewirken, dass nicht sämtliche Systeme des Clusters den kompletten Storage sehen könnten, sondern lediglich zwei Cluster-Systeme. Diese würden dann jeweils füreinander das Failover-Cluster-Member darstellen. Letztendlich soll in Abbildung 6.17 eine realistische Storage-Konfiguration eines Clusters unter Einbeziehung der Technologien der hochverfügbaren Storage Arrays und der hochverfügbaren Fibre Channel-Switches dargestellt werden. Diese Konfiguration stellt in SAN-Umgebungen die wohl realistischste VCS-Konstellation dar. Abbildung 6.17: VCS-SAN Shared Storage

Storage Array FA

FCSwitch


F C H B A

F C H B A


Client

F C H B A

F C H B A

Client


F C H B A


F C H B A

F C H B A

F C H B A

Client

Oben wurde bereits erwähnt, dass für VCS neben dem VCS-privaten LAN ein weiterer Kommunikationskanal notwendig ist, um die Redundanz der Übertragungsmedien für die Status-Informationen der Cluster-Systeme und die Monitoring-Funktionen von VCS zu bieten. VCS verwendet für die Redundanz der Übertragungsmedien zwei unterschiedliche Typen von Kommunikationskanälen. 왘 Kommunikation über ein privates Netzwerk der VCS-Cluster-Systeme 왘 Kommunikations-Platten (Heartbeat Disks), die (auf einem Storage Ar-

ray) geshared werden Dabei ist seitens VCS zumindest ein Netzwerk-Kommunikationskanal erforderlich. Weitere Kommunikationskanäle können zwischen Netzwerk-Kanälen und Heartbeat Disks frei kombiniert werden. Durch diese Konfiguration

314


wird der Cluster sowohl vor dem Ausfall eines einzelnen Kanals geschützt, als auch sichergestellt, dass die Auslieferung der Status- und KontrollInformationen nicht durch Netzwerküberlastung verzögert wird. VCS unterstützt derzeit maximal acht unterschiedliche Netzwerk-Kanäle und vier Heartbeat Disks. Die Heartbeat-Platten müssen für jedes ClusterSystem des VCS-Cluster erreichbar sein. Dabei wird seitens Veritas empfohlen, für jede I/O-Kette zwischen den Systemen mindestens eine Heartbeat Disk zu verwenden. Derzeit besteht noch eine Begrenzung auf Cluster mit maximal acht ClusterSystemen, so diese über einen Heartbeat Disk-Kommunikationskanal verfügen sollen. Im obigen Beispiel des VCS-SAN Shared Storage würde eine Heartbeat Disk auf dem Storage Array genügen. Über die zwei verfügbaren Kanäle eines jeden Cluster-Systems wären dann zwei Heartbeat Disk-Kanäle für den Cluster konfiguriert und nutzbar. Das obige Beispiel des verteilten Shared Storage würde für jedes dargestellte Shared Storage Storage Array eine Heartbeat Disk erfordern. Wäre in dieser Konfiguration ebenfalls ein Multipathing mit Path-Failover konfiguriert, existierten in diesem Beispiel sechs Heartbeat Disk-Kommunikationskanäle. Abbildung 6.18: VCS-SAN Shared Storage mit Heartbeat Disk

Storage Array FA

FCSwitch


Client

F C H B A

F C H B A


F C H B A

F C H B A

Client


F C H B A


F C H B A

F C H B A

F C H B A

Client

Seien in Abbildung 6.18 die dargestellten Magnetplatten der Shared Storage des Clusters, so stellt die auf der ersten Platte dargestellte helle Partition die Heartbeat Disk des Clusters dar.

315


In der bisher erläuterten Konfiguration der Heartbeat Disk-Kommunikation ist die Heartbeat Disk als Kommunikationskanal einem Veritas Cluster-System zugeteilt. Für eine Nicht-SAN und Nicht-Path-Failover-Umgebung könnte dies bedeuten, dass ein Stromausfall beide konfigurierten Kommunikationskanäle – Netzwerk und Heartbeat Disk – gleichzeitig nicht verfügbar machen würde. Für diese Zwecke ermöglicht VCS, jeder Service-Gruppe – vergleichbar mit den Packages von MC/ServiceGuard – eine eigene Heartbeat Disk zuzuweisen. Dadurch könnte zumindest in einer verteilten Shared Storage-Konfiguration ein Totalverlust der Kommunikationskanäle verhindert werden, da die Heartbeat Disk der Service-Gruppe für jedes ClusterSystem verfügbar sein muss, dass die Applikationen dieser Service-Gruppe bedienen kann. Die Anzahl konfigurierbarer Service Group Heartbeat Disks ist unbegrenzt. In hochverfügbaren SAN-Umgebungen werden daher die SAN-Komponenten mit Heartbeat Disks für Service-Gruppen kombiniert. Während der Installation von VCS wird der für Heartbeat Disks und Service Group Heartbeat Disks benötigte Plattenplatz konfiguriert und zugewiesen. Vor dem Start von VCS und damit vor der Initiierung des Clusters kann es zu so genannten Preexisting Network Partitions kommen. Dabei handelt es sich um teilweise nicht funktionierende Netzwerk-Kommunikationskanäle, bei denen es zu einem Fehler gekommen ist, während die Cluster-Systeme DOWN waren. Dabei ist es gleichgültig, ob ein solcher Fehler geplant – z.B. bei einer geplanten Wartung des Netzwerks – oder ungeplant durch einen Hardware- oder Softwarefehler aufgetreten ist. VCS kann auf diese Fehler nicht reagieren, da ja die Cluster-Systeme DOWN sind. Dies kann VCS beim Neuboot der Cluster-Systeme verwundbar machen, da teilweise die Netzwerk-Kommunikationskanäle des Clusters nicht zur Verfügung stehen. Um VCS vor solchen Preexisting Network Partitions zu schützen, gibt es das Konzept des Seeding. Startet ein Cluster-System, ist es zunächst nicht seeded. Die Systeme des Clusters können manuell oder automatisch geseedet werden, wichtig ist lediglich, dass VCS nur auf geseedeten Cluster-Systemen gestartet werden kann. Das Seeding erfolgt automatisch, wenn 왘 ein nicht geseedetes System mit einem geseedeten Cluster-System kom-

muniziert. Dies geschieht immer dann, wenn ein Cluster-System aufgrund eines Fehlers aus dem Cluster herausgefallen ist und – nach Behebung des Fehlers – in den Cluster zurückkehrt; 왘 alle Systeme des Clusters nicht geseedet sind, jedoch untereinander über

das private Netzwerk oder die Heartbeat Disks miteinander kommunizieren können, also in aller Regel nach dem Start sämtlicher Cluster-Systeme des Clusters. Letzteres erfolgt automatisch, da in der Cluster-Konfiguration für VCS definiert wird, welche und wie viele Cluster-Systeme den Cluster bilden. Wird das letzte dieser Systeme gebootet, findet das Seeding des kompletten Clusters statt. Danach startet VCS. Nach Start von VCS können die Cluster-Mem-

316


bers nach Belieben gestartet und gestoppt werden. Kehrt ein gestopptes Cluster-Member wieder in den Cluster zurück, sendet es seine Status-Informationen über die Kommunikationskanäle, kommuniziert also mit den übrigen geseedeten Cluster-Systemen und wird dadurch automatisch geseedet. Das Seeding erfolgt also automatisch, solange nach dem initialen Start des Clusters mindestens noch ein Cluster-System im Cluster intakt bleibt. Manuelles Seeding ist daher nur im Falle des Cold Start des Clusters erforderlich, bei dem kein einziges Cluster-Member verfügbar ist.

6.1.3.2

VCS-Installation

Die Installation von Veritas Cluster-Server folgt einer präzise einzuhaltenden Reihenfolge. 왘 Aufbau und Setup der Hardware 왘 Installation von VCS 왘 Konfiguration der Kommunikationsdienste von VCS 왘 Allokation von Magnetplattenkapazität für die Kommunikations-Disks

(Heartbeat Disks) und die Service Group Heartbeat Disks 왘 Start von VCS 왘 Verifikation von LLT (Low Latency Transport), GAB (Group Member-

ship and Atomic Broadcast, Dienstprogramme, die die Berechtigung eines Systems als Cluster-Member prüfen und gewährleisten) und Test der Funktionsfähigkeit des Clusters 왘 Initialisierung der Filesysteme und Disk Groups im Shared Storage 왘 Vorbereitung des NFS-Starts

Hardware-Setup Tabelle 6.3 definiert die Hardwarevoraussetzungen für einen VCS-Cluster. Als Beispiel ist hier ein VCS-Cluster für Sun Solaris dargestellt. HardwareBestandteil

Beschreibung

VCS-ClusterSystem

Sun-Server mit SPARC-Architektur, Solaris 2.5.1 oder höher

CD-ROMLaufwerk

Je Cluster-System ein lokal angeschlossenes CD-ROM-Laufwerk oder ein für alle Systeme erreichbares Netz-CD-ROMLaufwerk

Magnetplatten

Je nach Anwendung, für die ein Failover zwischen den Systemen des Clusters konfiguriert werden soll, muss die entsprechende Anzahl von Shared Disk Devices verfügbar sein.

Tab. 6.3: VCS – Hardware-Setup

317


HardwareBestandteil

Beschreibung

Ethernet LAN-Schnittstellenkarten

Für das Private Network von VCS wird mindestens ein Ethernet-Controller zusätzlich zum Ethernet-Controller für das Public Network je System benötigt.

SCSI und/ oder Fibre Channel Adapter

VCS-Software muss auf einer internen Platte eines jeden Cluster-Systems installiert werden. Daher werden mindestens ein SCSI-Adapter für die interne Platte und zusätzlich mindestens ein SCSI- oder FC-Adapter für den Shared Storage benötigt.

Plattenplatz für VCSSoftware

Zur Installation der VCS-Software werden mindestens 35 Megabytes freier Plattenplatz im /opt-Filesystem eines jeden Cluster-Systems benötigt.

Hauptspeicher

Minimum von 128 MB RAM je Cluster-System

IP-Adressen

Jede Service-Gruppe des Clusters benötigt eine eigene eindeutige IP-Adresse zusätzlich zur IP-Adresse des Cluster-Systems (vgl. Relocatable IP-Adressen bei MC/ServiceGuard).

Tab. 6.3: VCS – Hardware-Setup (Forts.)

Abbildung 6.19 stellt eine typische VCS-Konfiguration mit zwei Cluster-Systemen in einem Cluster dar. Abbildung 6.19: VCS – Dual System-ClusterKonfiguration

Storage Array FA System A c1t0d0 c2t0d0 System B c1t1d0 c2t1d0

c1t0d1 c2t0d1

c1t0d2 c2t0d2

c1t0d3 c2t0d3

c1t1d1 c2t1d1

c1t1d2 c2t1d2

c1t1d3 c2t1d3

Root Disk

c0t0d0


FCSwitch

F C H B A

Root Disk

F C H B A


F C H B A

c0t0d0

hme:0 qfe:0

Client

318

Client

F C H B A

Client


Dabei erfordert VCS klar definierte Verbindungen zwischen sämtlichen Komponenten des Clusters, also: 왘 Verbindungen von jedem Cluster-System zu dem Shared Storage und

zur Kommunikations-Heartbeat Disk. Im Beispiel der Abbildung 6.19 existieren je Cluster-System zwei Pfade zum Storage Array, das die Shared Devices beherbergt. Dies bedeutet, dass ein Storage Device von jedem System über zwei CTLs gesehen wird (siehe Device-Beschriftung oben), dabei sei der obere der FC-HBAs eines jeden Cluster-Systems der zweite I/O-Controller (c1), der untere der FC-HBAs der dritte I/O-Controller (c2). Der erste I/O-Controller (c0) eines jeden Cluster-Systems ist der interne SCSI-Bus. An diesen ist die interne Root Disk angeschlossen. 왘 Verbindungen von jedem Cluster-System zum Public Network (qfe:0)

und zum privaten Netzwerk für die Statuskommunikation und die Überwachung des Clusters (hme:0). Daher ist beim Hardware-Setup in folgender Reihenfolge vorzugehen: 왘 Installation der erforderlichen Ethernet-Schnittstellenkarten, SCSI-Host-

Bus-Adapter und/oder Fibre Channel-Host-Bus-Adapter. 왘 Anschluss der privaten Ethernet-Schnittstellenkarten zwischen den

Cluster-Systemen über Kreuzverkabelung oder über Hub. Dabei ist jedoch sicherzustellen, dass das private Netzwerk des Clusters physikalisch vom öffentlichen Netzwerk zu den Clients getrennt bleibt. Bei der Verkabelung über Hub sind also sowohl für das private Netz als auch für das öffentliche Netz eigene Hubs zu verwenden. Der folgende Schritt muss in zwei Fälle unterschieden werden, je nachdem ob die Shared Disks des Storage Arrays Direct Attached über SCSI angeschlossen werden, oder über FC-SW Switched Fabric Fibre Channel-Ports. 왘 Bei Direct Attached SCSI-Anschluss muss ein Port eines jeden der beiden

SCSI-HBAs (in Abbildung 6.19 wären diese alternativ zu den FC-HBAs eingebaut) des Systems A an einen SCSI Channel Director-Port des Storage Arrays angeschlossen sein (hier müssten anstelle des einen Fibre Channel-Adapters FA des Storage Arrays zwei SCSI-Channel Directors SA eingebaut sein, über die die beiden alternativen Pfade verkabelt würden. Diese beiden SAs müssten auf denselben internen Systembussen des Storage Arrays liegen, damit die Shared Devices über beide Pfade gesehen werden können.)2 Die Verkabelung über Fibre Channel erfolgt durch Anschluss eines Ports eines jeden Host-Bus-Adapters an einen Port des Fibre Channel-Switches und durch Anschluss der beiden Ports eines Fibre Channel Directors des Storage Arrays an zwei Ports des Fibre Channel-Switches.

2.

Zur Verkabelung von Dual-Ported Devices über SCSI- oder Fibre Channel-Technologie vgl. Kapitel 3 dieses Buches.

319


Die folgenden drei Schritte sind in ihrer Reihenfolge nur für Direct Attached SCSI-Verbindungen des Shared Storage einzuhalten: 왘 Überprüfung der korrekten Installation und des funktionsfähigen An-

schlusses der Shared Disks mithilfe folgender Kommandos (auf EEPROM-Ebene vor System-Boot): ok ok

show-devs probe-scsi-all

Hier sollte schon darauf geachtet werden, dass die Devices auf einem Shared SCSI-Bus nicht mit entsprechenden Target-Adressen sämtlicher SCSI-HBAs der am Cluster beteiligten HBAs in Konflikt geraten können (wird durch den übernächsten Schritt sichergestellt). Dies stellt jedoch lediglich ein Problem in-Umgebungen dar, in denen keine hochverfügbare Storage Arrays eingesetzt werden. Deren innere Architektur verhindert solche Konfliktsituationen. 왘 Verkabelung des Shared Storage vom System B aus, indem wieder ein

Port eines jeden der beiden SCSI-HBAs des Systems B an einen SCSI Channel Director-Port des Storage Arrays angeschlossen wird. 왘 Es muss sichergestellt sein, das die SCSI-IDs der Host-Bus-Adapter der

am Cluster beteiligten Systeme unterschiedlich sind. Daher sollte am System B sichergestellt sein, dass dessen SCSI-ID sich von der des Systems A unterscheidet. Die SCSI-ID eines HBAs kann ebenfalls vom EEPROM aus mit folgendem Kommando verändert werden: ok

setenv scsi-initiator-id 5

wobei die SCSI-ID nun beispielhaft auf 5 geändert wurde. Bei Verwendung hochverfügbarer Storage Arrays erfolgt der I/O auf/von Platte – unabhängig von der verwendeten Connectivity-Technologie – über SCSI-Kommandos. Daher kann auch für die über FA-Ports angeschlossenen Shared Devices nach Verkabelung sämtlicher Cluster-Systeme deren Korrektheit mit den Kommandos ok ok

show-devs probe-scsi-all

auf der EEPROM-Ebene jedes Cluster-Systems überprüft werden. Als letzter Schritt des Hardware Setups erfolgt in beiden Konfigurationsvarianten 왘 Das Booten der Cluster-Systeme, jeweils vom EEPROM-Level mit dem

Kommando ok boot –r

Die r-Option (Reconfigure) erkennt sämtliche neu hinzugefügten Devices und trägt sie in die Filesystemhierarchie des Cluster-Systems ein.

320


Konfiguration der Maintenance IP-Addresse Die Maintenance IP Adresse eines Cluster-Systems stellt die stationäre IP-Adresse dar, die dem Cluster-System während der Installation des Betriebssystems Solaris zugewiesen wurde. Dabei handelt es sich um die IPAdresse der Ethernet-Schnittstellenkarte des Public Networks des ClusterSystems. Als IP-Adresse des Public Networks unterliegt die Maintenance IPAdresse nicht der Kontrolle von VCS. Abbildung 6.20: VCS – Dual System-Cluster – Maintenance IPAdresse

Storage Array FA System A c1t0d0 c2t0d0 System B c1t1d0 c2t1d0

c1t0d1 c2t0d1

c1t0d2 c2t0d2

c1t0d3 c2t0d3

c1t1d1 c2t1d1

c1t1d2 c2t1d2

c1t1d3 c2t1d3

Root Disk

c0t0d0

Maintenance IP qfe:0


FCSwitch

F C H B A

F C H B A

Onboard le0


Root Disk

F C H B A

c0t0d0

hme:0

F C H B A

Onboard le0 Maintenance IP qfe:0

Privates Netzwerk Öffentliches Netzwerk

Client

Client

Client

Veritas erwartet für VCS eine strikte Trennung des privaten Netzwerks für die Heartbeat-Informationen vom öffentlichen Netzwerk für den Anschluss der Clients. Dies kann dazu führen, dass die Maintenance IP-Adresse auf einen anderen als den Standard-Netzwerk-Controller versetzt werden muss. Sun liefert eine Netzwerk-Interface-Karte quasi als Built-In auf dem Motherboard aus. Diese ist die Onboard le0. Auf einer zusätzlichen Quad-FastEthernet Ethernet-Schnittstellenkarte sind weitere vier Interfaces vorhanden (qfe:0, qfe:1, qfe:2, qfe:3). Hier ist es seitens VCS notwendig, die Maintenance IP-Adresse von dem le0-Interface auf ein qfe-Interface zu versetzen, da das le0-Interface allein für das private Heartbeat-Netzwerk verwendet werden muss. Folgende Schritte müssen durchgeführt werden, um die Maintenance IPAdresse auf eine weitere Netzwerk-Schnittstelle zu verschieben:

321

6 Hochverfügbare SAN – Software-Komponenten 왘 Sicherstellung, dass das öffentliche Netzwerk korrekt angeschlossen und

funktionsfähig ist. Dies wird durch Anwählen eines Hosts außerhalb des Clusters erreicht, der über das öffentliche Netzwerk erreichbar ist. $ ping lucifer

Ist der Ping erfolgreich, so ist das öffentliche Netzwerk funktionsfähig und erreichbar. 왘 Überprüfen, ob die Maintenance IP-Adresse auf Schnittstelle le0 liegt:

$ cat /etc/Cluster-System-B.le0

Als Ausgabe für dieses cat-Kommando wird der Systemname erwartet, in diesem Beispiel wäre dies Cluster-System-B. 왘 Umbenennen dieser Datei, um die Maintenance IP-Adresse softwaresei-

tig zu verschieben: $ mv /etc/Cluster-System-B.le0 etc/Cluster-System-B.qfe0 왘 Umstecken des Netzwerk-Drop-Kabels von le0 auf den äußersten linken

Port (Port 0) der Quad-Fast-Ethernet-Schnittstellenkarte. 왘 Reboot des Systems mit

$ boot –r 왘 Sicherstellung, dass das Public-Netzwerk korrekt angeschlossen ist und

funktionsfähig ist. Dies wird durch Anwählen eines Hosts außerhalb des Clusters erreicht, der über das Public-Netzwerk erreichbar ist. $ ping lucifer

Ist der Ping erfolgreich, so ist das Public-Netzwerk funktionsfähig und erreichbar. Die Netzwerk-Schnittstellenkarte, auf die die Maintenance IP-Adresse gelegt wird, darf nicht zum Kommunikations-Netzwerk gehören. Sie kann sehr wohl jedoch mit Netzwerk Services von Service-Gruppen des Clusters geteilt werden.

Netzwerk Partitions und Sun Boot Monitor Ein Sun-Feature bei SPARC-Prozessoren ist, mit einer CONSOLE-ABORT Sequenz den Prozessor von der Konsole des SCP (System Control Prozessor) aus anhalten und erneut starten zu können. Diese Sequenz ist L1-A oder STOP-A oder auch BREAK auf der Systemkonsole. Nach Anhalten des Prozessors können Kommandos eingegeben werden, die auf dem EEPROMPrompt mit GO gestartet werden können. Diese Möglichkeit, auch nach dem Anhalten des Prozessors eines ClusterSystems mit Aktionen auf diesem System fortsetzen zu können, kann und darf aus Gründen der Daten-Konsistenz von VCS nicht unterstützt werden.

322


Dies kommt daher, dass sobald der Prozessor auf einem Cluster-System angehalten wird, dieses Cluster-System keine Heartbeat-Informationen mehr über das private Netz oder die Heartbeat-Platten liefern kann. Dies wird von VCS erkannt, er produziert einen Failover, wodurch ein anderes Cluster-System sämtliche Service-Gruppen dieses Cluster-Systems übernimmt. Wird nun das angehaltene System mit GO wieder aktiviert, schreibt es weiter auf die Shared Storage Devices, obwohl seine Applikationen mit ihren Service-Gruppen auf ein Failover-System geschwenkt worden sind. Durch das Seeding-Konzept (vgl. oben), wird dies zwar seitens VCS automatisch verhindert, dennoch gibt es die Möglichkeit, durch administrative Maßnahmen solche Daten-Inkonsistenzen zu verhindern. Unter Solaris 2.6 und höher gibt es die Möglichkeit, die CONSOLE-ABORTSequenz für Clusterumgebungen zu sperren. Dazu wird in der Datei /etc/ default/kbd die Zeile $ KEYBOARD-ABORT=disable

eingefügt. Existiert die Datei /etc/default/kbd nicht, so sollte sie angelegt werden. Nach Änderung der Keyboard-Parameter-Datei muss das Cluster-System neu gebootet werden. Unter Solaris 2.5.1 existiert die Möglichkeit, das Console Abort auszuschalten, noch nicht. Hier kann nur organisatorisch verhindert werden, dass nach Verwendung der Abort-Sequenz das GO untersagt wird. Zum Restart des Systems muss auf EEPROM-Ebene mit boot das System wieder angefahren werden.

Block Devices für den NFS-Service Bestandteil des Shared Storage sind Devices, die über NFS-Mount den Clients zur Verfügung gestellt werden. Damit auch für diese Devices symmetrische Konfigurationen für das Failover des NFS-Services ermöglicht werden, werden diese Devices bei einem Zwei-System-Cluster in zwei Disk Groups organisiert oder in eine entsprechende Anzahl von Disk Groups, die eine Disk Group pro Cluster-System ermöglichen, auf die die NFS-Filesysteme im Normalbetrieb deportiert werden. Jede Disk Group unterstützt mehrere Filesysteme. Jedes Filesystem kann entweder auf einer Partition einer Platte (z.B. c0t1d0s3) oder einem Volume (z.B. /dev/vx/dsk/nfsdg/vol1) unter Veritas Volume-Manager (VxVM) angelegt werden.3 Der Partition- oder der Volume-Name repräsentieren dabei ein Block Device für NFS, auf das das Filesystem gemounted wird. Werden VxVM Volumes vewendet, so darf kein Device des Shared Storage in der rootdg Disk Group liegen. Diese ist dem Betriebssystem vorbehalten und sollte auf einer lokalen Platte des Cluster-Systems liegen. Mit VxVM

3.

Zu VxVM vgl. Abschnitt »Veritas Volume-Manager: Übersicht« weiter unten.

323


sollten Disk Groups für NFS nur auf einem Cluster-System erzeugt werden. Diese Disk Groups werden seitens VCS exportiert und bei den übrigen Cluster-Systemen importiert. Die NFS Block Devices müssen auf jedem beteiligten Cluster-System identische Major und Minor Numbers besitzen. Diese identifizieren unter Solaris die Partitions oder Slices eines Volumes. Unter NFS werden die Major und Minor Numbers weiter für die Identifikation der exportierten Dateisysteme verwendet, sie müssen ebenfalls für jedes exportierte Filesystem identisch sein. Dies kann mit folgenden Schritten überprüft werden: 왘 Anzeige der Major und Minor Numbers jedes Block Devices auf jedem

beteiligten Cluster-System. Sollen diese für VxVM Volumes angezeigt werden, so müssen zunächst sämtliche den Volumes assoziierte Shared Disk Groups auf jedem beteiligten System importiert worden sein. # ls –lL

Dabei enthält die Variable die Bezeichnung der Partition, auf die das Filesystem zum Export durch NFS gemountet wird. Als Beispiel also: # ls –lL /dev/dsk/c2t1d0s4

Die Ausgabe auf das Kommando kann auf den beteiligten Cluster-Systemen differieren, z.B.: Cluster-System-A crw--r---- 1 root sys 28,130 Aug zwölf 06:32 /dev/dsk/c2t1d0s4 Cluster-System-B crw--r---- 1 root sys 28,130 Aug 14 19:48 /dev/dsk/c2t1d0s4 Die Major Number 28 und die Minor Number 130 sind jedoch auf beiden Cluster-Systemen identisch. 왘 Differieren Major und Minor Numbers auf den Cluster-Systemen von-

einander, so können sie mithilfe des VCS-Kommandos haremajor angeglichen werden. 왘 Beide vorhergehenden Schritte müssen für jedes NFS-Block Device wie-

derholt werden. Bevor die VCS-Software installiert und konfiguriert werden kann, müssen die für NFS benötigten Platten, Filesysteme und Mount Points initialisiert und erstellt werden. Dazu müssen für jedes NFS-Filesystem folgende Schritte durchlaufen werden: 왘 Erstellen des Filesystems auf lediglich einem der Cluster-Systeme mit-

hilfe des Kommandos mkfs.

324

Hochverfügbare Cluster-Software 왘 Erstellen des Mount Points, zu dem das Filesystem via NFS exportiert/

importiert wird, auf sämtlichen im Cluster beteiligten Cluster-Systemen mithilfe des Kommandos mkdir. Die via NFS exportierten Filesysteme dürfen jedoch nicht in /etc/vfstab oder /etc/dfs/dfstab eingetragen werden, da VCS diese Filesysteme automatisch exportieren und mounten muss.

Softwareinstallation von VCS Nach Abschluss der Vorbereitungen für NFS kann die Veritas Cluster-ServerSystem-Software installiert werden. Dazu muss die Installations-CD auf einem CD-ROM-Laufwerk lokal oder via Netz auf jedem der beteiligten Cluster-Server gemountet werden. Unter Solaris wird bei aktiviertem VolumeManagement die CD-ROM automatisch unter /cdrom/cdrom0 gemounted. Ist Volume-Management nicht aktiv, muss die CD-ROM manuell via # mount –F hsfs –o –ro /dev/dsk/c0t6d0s2 /cdrom/cdrom0

gemountet werden, wobei /dev/dsk/c0t6d0s2 das Standard Block Device für das CD-ROM-Laufwerk darstellt. Auf der Installations-CD befinden sich die VCS-Installationspackages, die auf sämtlichen Cluster-Systemen via # pkgadd –d /cdrom/cdrom0

installiert werden müssen. Dabei wird zunächst eine Liste der auf der CD befindlichen Packages angezeigt und dann nach dem Package gefragt, das installiert werden soll. Auf diese Frage ist als Aktion die Auswahl-Möglichkeit all zu wählen. Während der Installation der Packages wird vor jedem Package erneut abgefragt, ob denn wohl auch dieses Package zu installieren sei. Darauf ist stets mit Yes zu antworten. Nach Installation aller Packages wird mit q der Installationsprozess verlassen. Darauf wird folgende Message auf die Konsole geschrieben: *** IMPORTANT NOTICE *** This machine must now be rebooted in order to ensure sane operation. Execute shutdown –y –i6 –g0 and wait for the “Console Login:“ prompt.

Dieser Anweisung ist bei Erstinstallation der VCS-Software nicht Folge zu leisten, sondern zunächst der komplette Cluster zu etablieren.

325


Etablieren des Clusters Mithilfe des Quick-Start Wizards können VCS-Cluster benutzerfreundlich geführt aufgesetzt werden. Dabei wird der Quick-Start Wizard lediglich für 2-Host-Cluster mit zwei privaten Ethernet Heartbeat LANs als Kommunikationskanäle verwendet. Er wird auf einem der beiden Cluster-Systeme, dem lokalen System, ausgeführt und hilft sowohl das lokale als auch das remote System aufzusetzen. Die Reihenfolge, in der beim Aufsetzen des Clusters vorzugehen ist, lautet: 왘 Planung der Etablierung des Clusters 왘 Ausführen des VCS Quick-Start Wizard 왘 Überprüfen der LLT, GAB und der Funktionsfähigkeit des Clusters

Die Planung des Clusters umfasst sämtliche vorbereitende Tätigkeiten, bevor mit dem VCS Quick-Start Wizard der Cluster tatsächlich aufgesetzt wird. Veritas empfiehlt, ein Worksheet mit seinen Inhalten (in Abbildung 6.21 gezeigt) vor dem Start des Quick-Start Wizards auszufüllen, um dann während des Quick-Starts die notwendigen Informationen zur Hand zu haben. Dabei soll im Feld »Name des Remote Systems« ein IP-Name des Remote VCSCluster-Systems oder eine IP-Adresse dieses Systems eingegeben werden. Dieser Name sollte feststehen und das Netz auch bereits konfiguriert und lauffähig sein, da das lokale VCS-Cluster-System via rsh zur Laufzeit des Quick-Starts auf das remote VCS-Cluster-System zugreifen muss. In unserem Beispiel müsste hier als Name Cluster-System-B eingetragen werden. Als Name des Clusters sollte der Cluster-Name eingetragen werden, über den VCS den kompletten Cluster steuert. Wird kein Name für den Cluster vergeben, so wird dieser standardmäßig als vcs benannt. Die Liste der Cluster-Systeme enthält eine Liste sämtlicher Systeme, die Mitglied des Clusters werden sollen. Für die Verwendung des Quick-Start Wizards kann es sich nur um das lokale System und das remote System handeln. Die hier eingetragenen Namen müssen die sein, die über den uname() System Call vom Kernel von Solaris zurückgeliefert werden. Kommt der Quick-Start Wizard an den Punkt, an dem die Systemnamen eingegeben werden müssen, bietet der Quick-Start Wizard Standard-Vorschläge auf Basis der uname()-Ausgaben an. VCS erfordert zwei oder mehr Kommunikationskanäle zwischen den ClusterSystemen. Beim Quick-Start Wizard wird davon ausgegangen, dass es sich dabei um private LANs handelt, nicht um Heartbeat Disks. Diese privaten Netzwerke sind getrennt von dem public Netzwerk, das für die NFS-Dienste für die Clients genutzt wird. VCS verwendet auf seinen privaten Netzwerken ein eigenes Protokoll, daher sollte auf den hier konfigurierten Kommunikations-Kanälen kein IP installiert und konfiguriert werden. Vor allem darf für die hier eingetragenen Devices kein /etc/hostname.<device> File erzeugt werden.

326

Hochverfügbare Cluster-Software Abbildung 6.21: VCS – Quick-StartVorbereitung

Name des Remote Systems Name des Clusters Liste der Cluster-Systeme Lokales System Remote System Kommunikationskanal 1 Lokales System Device

Remote System Device

Kommunikationskanal 2 Lokales System Device


Abbildung 6.22 zeigt ein ausgefülltes Quick-Start Worksheet, angepasst an unsere bisherigen Beispiele.

Name des Remote Systems

Cluster-System-B

Name des Clusters

VCS-MAH

Abbildung 6.22: VCS – Quick-Start Worksheet für Beispielkonfiguration

Liste der Cluster Systeme Lokales System

Cluster-System-A

Remote System

Cluster-System-B Kommunikationskanal 1

Lokales System Device

le:0


le:0

Kommunikationskanal 2 Lokales System Device

qef:3


qef:3

327


Nach Start des Quick-Start Wizards auf dem lokalen Cluster-System werden die im Worksheet eingetragenen Daten abgefragt. Danach werden vom Wizard die folgenden Konfigurationsfiles auf dem lokalen und dem remote Cluster-System erzeugt: 1. /etc/llthosts 2. /etc/llttab 3. /etc/gabtab 4. /etc/VRTSvcs/conf/config/main.cf 5. /etc/VRTSvcs/conf/config/sysname

Um den Quick-Start Wizard laufen lassen zu können, müssen folgende Bedingungen erfüllt sein: 왘 Der VCS Quick-Start Wizard kann nur vom Benutzer root ausgeführt

werden. 왘 Das lokale System hat via rsh root Berechtigungen auf dem remote System. 왘 Das Hardware-Setup ist erfolgreich durchgeführt worden. 왘 Die VCS-Software ist vollständig und korrekt installiert worden.

Mit der Kommandozeile # $VCS-HOME/wizards/config/quick-start

wird der Quick-Start Wizard gestartet. Auf den folgenden Screens werden die Konfigurationsparameter abgefragt, die im Worksheet vorbereitet wurden. Nach erfolgtem Quick-Start gibt der Wizard folgende Confirmation Message aus: Congratulations! You have completed the initial Veritas Cluster-Server installation and configuration.

Verifikation von LLT, GAB und Cluster-Funktionen Nach Beenden des Quick-Starts muss sichergestellt werden, dass LLT, GAB und der Cluster selbst laufen und funktionsfähig sind. LLT und GAB werden als Benutzer root auf jedem der beiden Cluster-Systeme überprüft: # /sbin/gabconfig –a

Sind GAB und LLT funktionsfähig, werden die Informationen von GAB Port-Membership angezeigt: GAB Port Membership ============================================== Port a gen bf3a1008 membership 01 Port h gen af760032 membership 01

328


Port a zeigt an, dass LLT und GAB kommunizieren, gen bf3a1008 stellt eine generierte hexadezimale Zufallszahl dar, die membership 01 zeigt an, dass die Cluster-Systeme 0 und 1 verbunden sind. Port h zeigt an, dass VCS gestartet ist, gen af760032 stellt eine generierte hexadezimale Zufallszahl dar, die membership 01 zeigt an, dass die ClusterSysteme 0 und 1 VCS gestartet haben.

Sind GAB und LLT nicht funktionsfähig, werden die Informationen von GAB Port-Membership nicht angezeigt: GAB Port Membership ==============================================

Die Funktionsfähigkeit des kompletten Clusters wird als Benutzer root mit folgendem Kommando überprüft: # /opt/VRTSvcs/bin/hasys –display

Läuft der Cluster fehlerfrei, so werden die Attribute des aktiven Clusters angezeigt. # $VCS-HOME/bin/hasys –display #System Attribute Cluster-System-A AgentsStopped Cluster-System-A ConfigBlockCount Cluster-System-A ConfigCheckSum ...

Value 0 0 0

Läuft der Cluster nicht fehlerfrei, so wird folgende Meldung angezeigt. Unsuccessful open of service

Konfiguration der Heartbeat Kommunikations-Disks und Service-Gruppen Heartbeat Disks Jede Heartbeat Disk oder Service-Gruppen Heartbeat Disk liegt auf einer Region (128 Blöcke und damit 64 Kbytes) einer Partition einer physikalischen Platte. Die Regionen der Heartbeat Disk werden über einen Block Device-Namen und einen Block Offset adressiert. Auf anderen Partitionen der gleichen Platte oder auch auf einem nicht überlappenden Block Offset derselben Partition können weitere Heartbeat Disks oder Service-Gruppen Heartbeat Disks angelegt werden. Eine Kommunikations-Disk benötigt zwei Regionen auf einer physikalischen Platte, eine Region für die Durchführung des Seedings, die andere für den Betrieb von VCS. Existieren mehrere I/O-Kanäle je beteiligtem ClusterSystem, wird seitens Veritas je I/O-Kanal die Konfiguration einer Kommunikations-Disk empfohlen. Jede Disk benötigt zwei 128 Blöcke große Regionen, die, falls die Partition, auf der die Regionen residieren, auf dem ersten Zylinder der physikalischen Platte beginnt, die Blöcke 0-15 vermeiden sollten, da dort in der Regel die Partition Table abgelegt wird.

329


Heartbeat Kommunikations-Disks werden mit identischen gabdisk-Kommandos in der /etc/gabtab jedes beteiligten Cluster-Systems eingetragen. Service-Gruppen Heartbeat Disks werden als VCS-Ressource im ServiceGroupHB Agent konfiguriert. Werden Kommunikations-Disk-Regionen und Service Group Heartbeat Disk-Regionen auf Partitionen physikalischer Platten, die VxVM Disks enthalten, angelegt, so können sie mit diesen VxVM-Disks koexistieren, können jedoch nicht auf VxVM-Volumes konfiguriert werden und müssen mit Block Offsets der unter den VxVM liegenden physikalischen Disks angelegt werden. Der für die Heartbeat-Regionen benötigte Platz auf den Partitions muss reserviert sein, bevor eine Platte durch den Veritas Volume-Manager initialisiert wird. Folgende Schritte lassen eine Platte sowohl als Heartbeat-KommunikationsPlatte als auch für VxVM Volumes nutzen: 왘 Korrekte Installation von Veritas Volume-Manager VxVM.4 왘 Identifikation der Platte anhand des VxVM Tag-Namens (entspricht ei-

ner CTL, also z.B. c0t1d3). 왘 Enthält die Platte Daten, sollten die Daten auf ein anderes oder andere

Device(s) migriert werden. Dafür müssen sämtliche Filesysteme auf der Disk mit umount abgehängt werden, sämtliche Volumes, Plexes oder Subdisks von der Platte entfernt werden und die Disk selbst aus jeder aktiven Disk Group entfernt werden oder die komplette Disk Group deportiert werden, in der sich diese Platte befindet.5 왘 Die PATH-Variable sollte um das Verzeichnis erweitert werden, in dem

sich die VCS-Kommandos befinden, also # export PATH=$PATH:/opt/VRTSvcs/bin 왘 Reservieren einer VCS-Partition auf der Platte mit dem als Benutzer root

abgesetzten Kommando: # hahbsetup

Die Variable ist der Name, der im zweiten Schritt identifiziert wurde, für unser Beispiel also # hahbsetup c0t1d3

4.

5.

330

VxVM Veritas Volume-Manager soll in diesem Buch nicht en detail dargestellt werden. Daher sei für die Installation auf das entsprechende Veritas Manual Veritas VolumeManage Installation and Configuration Guide hingewiesen. Vgl. hierzu auch die Literaturliste am Ende des Buches. Zur Definition der Begriffe Disk, Subdisk, Volume und Plex vgl. Abschnitt »Veritas Volume-Manager: Übersicht« später in diesem Kapitel.


Auf jede nun seitens VCS gestellte Frage ist mit »Y« zu antworten. Das Kommando steht für »High Availability HeartBeat Setup« und konfiguriert somit die Kommunikation über Heartbeat Disk für VxVM und VCS. Als Output erzeugt das Kommando hahbsetup: The hadiskhb command is used to set up a disk for combined use by Veritas Volume-Manager and Veritas Cluster-Server for disk communication. WARNING: This utility will destroy all data on c0t1d3 Have all disk groups and file systems on disk c0t1d3 been either unmounted or deported? Y There are currently slices in use on disk /dev/dsk/c0t1d3s4 /dev/dsk/c0t1d3s5 Destroy existing data and reinitialize disk? Y 1520 blocks are available for VxCS disk communication and service group heartbeat regions on device /dev/dsk/c0t1d3s7 This disk can now be configured into a Volume-Manager disk group. Using vxdiskadm, allow it to be configured into the disk group as a replacement disk. Do not select reinitialization of the disk. After running vxdiskadm, consult the output of prtvtoc to confirm the existence of slice 7. Reinitializing the disk under VxVM will delete slice 7. If this happens, deport the disk group and rerun hahbsetup. 왘 Die Platte sollte nun initialisiert werden, obwohl sie noch nicht einer

Disk Group zugeordnet wurde. Um die Platte danach einer Disk Group hinzuzufügen, sollte das VxVM-Kommando vxdg adddisk verwendet werden. Das Kommando # vxdg –g mahdg adddisk disk11=c0t1d3

fügt die Platte c0t1d3 als disk11 in die Disk Group mahdg ein. 왘 Anzeigen der Partition Table mit

# prtvtoc /dev/dsk/s0 also beispielsweise # prtvtoc /dev/dsk/c0t1d3s0

Die angezeigte Partition Table sieht ungefähr wie folgt aus: Partition 2 3 4 7

Tag

Flags

5 15 14 13

01 01 01 01

First Sector 0 0 3040 1520

Sector Count 8887440 1520 8884400 1520

Last Mount Directory Sector 8887439 1519 8887439 3039

왘 Überprüfen, dass Slice 7 existiert und ihr Tag 13 ist 왘 VCS-Konfiguration der Partition /dev/dsk/c9t1d3s7

Hiermit ist die Konfiguration der Heartbeat-Platten abgeschlossen. Diese Konfiguration ist nur für Cluster notwendig, die mit KommunikationsDisks als zweitem Kommunikations-Heartbeat-Kanal arbeiten. Diese können mit dem Quick-Start Wizard nicht angelegt werden.

331


6.1.3.3

VCS-Konfiguration

Veritas Cluster-Server bietet mit Quick-NFS einen weiteren Wizard, um die Konfiguration des 2-Host-Clusters zu vervollständigen, nachdem dieser mit dem Quick-Start Wizard etabliert wurde. Die Konfigurationsprozedur besteht aus der 왘 Definition von VCS Service-Gruppen und Ressourcen sowie der 왘 Zuweisung von File-Systemen für jede Service-Gruppe.

Abbildung 6.23 stellt wiederum ein Worksheet zur Verfügung, das vor der Ausführung des Quick-NFS Wizards bedacht und ausgefüllt werden sollte.

Service-Gruppen-Definition Jede Information bezüglich der Definition der Service-Gruppen eines VCSClusters wird vom Quick-NFS Wizard abgefragt. Im Gegensatz zu MC/ServiceGuard muss unter VCS jeder Dienst zu einer eigenen Service-Gruppe gefasst werden. Hingegen ist vergleichbar mit MC/ServiceGuard jedem Dienst ein Ressourcen-Set zugeordnet, das gestartet werden muss, um die Service-Gruppe für die Client-Anwendungen verfügbar zu machen. Jede Ressource kann lediglich zu einer Service-Gruppe gehören. Typische Ressourcen sind: 왘 Hardware Ressourcen wie Magnetplatten und Netzwerk-Schnittstellen-

karten 왘 Betriebssystem und systemnahe Ressourcen wie Disk Groups, Volumes,

Filesysteme und IP-Adressen 왘 Anwendungsprogramme und Datenbank-Management-Systeme, die

NFS-Filesysteme exportieren Im folgenden Beispiel werden zwei Service-Gruppen MAHGroup und SAPGroup definiert. Das lokale System – also das Cluster-System, auf dem der Quick-NFS Wizard gestartet wird – ist das primäre Cluster-System für die MAHGroup, das remote System ist das primäre Cluster-System für die SAPGroup. Das primäre Cluster-System unter VCS entspricht dem Primary Node unter MC/ServiceGuard, ist also das System, auf dem die Service-Gruppe beim Clusterstart gestartet wird. Die Beispiele für diese Quick-NFS-Konfiguration basieren ebenfalls noch auf der Annahme der Symmetrie innerhalb des 2-System-Clusters. Daher werden auch zwei Service-Gruppen erzeugt, die als primary System jeweils das secondary System – das einem Adoptiven Knoten unter MC/ServiceGuard X entspricht – besitzen.

332

Hochverfügbare Cluster-Software Abbildung 6.23: VCS – 2-SystemCluster QuickNFS Worksheet

Service Group _________________ Device-Name Public Netzwerk Name der Service Group IP-Adresse der Service Group Disk Group (optional) Disk Partition/Volume

Mount Point

Mount-Optionen

Typ

Service Group _________________ Device-Name Public Netzwerk Name der Service Group IP-Adresse der Service Group Disk Group (optional) Disk Partition/Volume

Mount Point

Mount-Optionen

Typ

Der Name der Service-Gruppe dient dazu, die Service-Gruppe als atomare Einheit administrieren zu können. VCS benötigt hier eine Entitätsbezeichnung, da die Service-Gruppe einen Container miteinander verknüpfter Ressourcen darstellt, die über den Namen als Einheit angesprochen werden können. Der Name der Service-Gruppe wird dazu verwendet, diese zu starten (online), zu stoppen (offline) oder einen Failover durchzuführen, also die Service-Gruppe von einem Cluster-System auf ein anderes Cluster-System zu migrieren. Der Device-Name des Public-Netzwerks referenziert auf die NetzwerkSchnittstellenkarte respektive auf den Port der Netzwerk-Schnittstellenkarte, auf die die Services der Applikation konfiguriert sind. Die IP-Adresse der Service-Gruppe entspricht unter MC/ServiceGuard der relocatable IP-Adresse eines Packages. Für diese Adresse darf keine Datei /etc/hostname. 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.

333

6 Hochverfügbare SAN – Software-Komponenten Abbildung 6.24: VCS – 2-System QuickNFS ServiceGruppenkonfiguration

Service Group MAH Group Device-Name Public Netzwerk

qfe:0

Name der Service Group

MAH Group

IP-Adresse der Service Group

191.81.142.3

Disk Group (optional)

mahdg

Disk Partition/Volume

Mount Point

Mount-Optionen

Typ

Service Group SAP Group Device-Name Public Netzwerk

qfe:0


SAP Group


191.81.142.12


sapdg


Mount Point

Mount-Optionen

Typ

Auswahl und Zuweisung von File-Systemen Nach Eintrag der Konfigurationswerte für die Service-Gruppen müssen ihre Filesysteme konfiguriert werden. Nach den Werten für die Filesysteme wird ebenfalls vom Quick-NFS Wizard geprompted. Die Informationen müssen für jedes Filesystem zusammengetragen werden, das mit NFS exportiert wird. Wird bei der Auswahl und Zuweisung von Filesystemen nicht mit Disk Partitions, sondern mit Volumes gearbeitet, so muss bei der Definition der Parameter der Service-Gruppen (vgl. oben) eine Disk Group angegeben sein. Diese Angabe ist dann nicht mehr optional. Im Quick-NFS Wizard muss mann sich zunächst entscheiden, ob man für das Filesystem eine Partition oder ein Veritas Volume-Manager Volume verwenden will. Quick-NFS Wizard prompted, ob das Filesystem auf einem VxVM-Volume angelegt werden soll. Soll es auf eine Partition gelegt werden, so ist diese Frage mit no zu beantworten, falls es auf ein VxVM-Volume soll, so ist die Frage mit yes zu beantworten. Die Einträge Disk Partition/Volume Name im Worksheet sind abhängig davon, ob die Filesysteme auf Disk Partitions oder VxVM-Volumes gelegt werden. 왘 Soll das Filesystem auf eine Disk Partition gelegt werden, so ist hier die

Disk Partition (Slice) anzugeben, auf der das Filesystem gemounted werden soll.

334

Hochverfügbare Cluster-Software 왘 Soll das Filesystem auf einem Veritas Volume-Manager Volume angelegt

werden, so ist hier das Veritas-Volume einzutragen, auf dem das Filesystem gemounted werden soll. Abbildung 6.25: VCS – 2-KnotenQuick-NFSGesamtkonfiguration

Service Group MAH Group Device-Name Public Netzwerk

qfe:0


MAH Group


191.81.142.3

Disk Group (optional) Disk Partition/Volume

Mount Point

Mount-Optionen

Typ

c0t1d3s3

/opt/mah

rw

ufs

c0t1d8s3

/mahdata

rw

ufs

Service Group SAP Group Device-Name Public Netzwerk

qfe:0


SAP Group


191.81.142.12


sapdg


Mount Point

Mount-Optionen

Typ

vol1

/opt/SAP

rw

vxfs

vol2

/sapdata

rw

vxfs

Der Mount Point stellt das Verzeichnis dar, unter dem das Filesystem gemounted werden soll, die Mount Optionen sind die Optionen, die man dem Kommando mount mitgeben kann, wie: 왘 ro

Read-Only-Filesystem

왘 Rw

Read-Write-Filesystem

Der File System Typ ist der Typ des Filesystems, das mit obigen Optionen auf diesem Mount Point eingehängt werden soll. Klassische Filesystemtypen unter Solaris in Verbindung mit VxVM sind: 왘 ufs

Unix Filesystem

왘 vxfs

Veritas Filesystem.

Soll das Filesystem auf ein Veritas-Volume gemounted werden, so ist als weitere Information die Disk Group nötig, in der sich dieses Volume befindet. Obige Abbildung zeigt das komplett ausgefüllt Quick-NFS Worksheet für unser Beispiel. Im Folgenden soll ein kompletter Quick-NFS-Dialog aufgezeigt werden. Nach Bestätigung sämtlicher Prompts erfüllt der Quick-NFS Wizard folgende Script-Schritte:

335

6 Hochverfügbare SAN – Software-Komponenten 왘 Verifikation des kompletten Clusters 왘 Erstellen eines Konfigurationsfiles auf dem lokalen Cluster-System 왘 Kopieren des Konfigurationsfiles auf das remote Cluster-System

Die Konfigurationsverzeichnisse liegen auf beiden Systemen unter dem Pfad /etc/VRTSvcs/conf. Vor dem Start des Quick-NFS Wizards sollte eine Sicherungskopie der Datei /etc/VRTSvcs/conf/main.cf erzeugt werden. Dabei handelt es sich um die Cluster-Konfigurationsdatei, die durch den Quick-Start Wizard erzeugt wurde. Der Quick-NFS Wizard hängt zusätzliche Konfigurationsdefinitionen an diese Datei an. Werden beim Quick-NFS Wizard falsche Antworten auf die Prompts eingegeben, so kann man zumindest auf die Quick-Start-Konfiguration zurückgreifen. Wurde kein Backup erzeugt, muss man den kompletten Prozess erneut mit dem Quick-Start beginnen. Der Quick-NFS Wizard wird als Benutzer root mit dem Kommando # $VCS-HOME/wizards/services/quick-nfs

gestartet. Quick-NFS durchläuft zehn Screens, die im Folgenden dargestellt und die entsprechenden Prompts mit unseren Beispielwerten gefüllt werden. Quick-NFS Install Wizard SCREEN # 1 WELCOME TO THE QUICK-NFS WIZARD! This wizard will help you to set up an NFS service on the two-system VCS cluster that you have already configured by using the Quick-Start wizard. You will be asked a series of questions that will be used in configuring the NFS service. ^F=Forward screen ^C=Exit

Quick-NFS Install Wizard SCREEN # 2 SERVICE GROUP INFORMATION FOR GROUPX The primary system for this service group is Cluster-System-A. Select a network device from the list shown below. Your selection will be the default network device. To enter any other option, type the new name. [j=down/k=up] le0 qfe0 qfe1 qfe2 qfe3 Public Network Device-Name: qfe0 Service Group Name: MAHGroup Service Group IP Address: 191.81.142.3 ^B=Back screen ^C=Exit

336


Quick-NFS Install Wizard SCREEN # 3 You can configure a service group with disks or -Volumes. If you have installed the Veritas Volume-Manager and want to configure -Volumes in your service group, answer yes to the following question. Do you want to use the Veritas Volume-Manager?: n

Quick-NFS Install Wizard SCREEN # 4 Select a disk partition from the list shown below. Your selection will be the default partition. To enter any other option, type in the new name. [j=down/k=up] /dev/rdsk/c0t0d0s0 ... /dev/rdsk/c0t1d3s0 /dev/rdsk/c0t1d3s3 ... /dev/rdsk/c0t1d8s0 /dev/rdsk/c0t1d8s3 Disk Partition: /dev/rdsk/c0t1d3s3 Mount Point: /opt/mah Mount Options: rw File System Type: ufs Additional File system for this group? Y ^B=Back screen ^C=Exit

Quick-NFS Install Wizard SCREEN # 5 Select a disk partition from the list shown below. Your selection will be the default partition. To enter any other option, type in the new name. [j=down/k=up] /dev/rdsk/c0t0d0s0 ... /dev/rdsk/c0t1d3s0 ... /dev/rdsk/c0t1d8s0 /dev/rdsk/c0t1d8s3 Disk Partition: /dev/rdsk/c0t1d8s3 Mount Point: /mahdata Mount Options: rw File System Type: ufs Additional File system for this group? N ^B=Back screen ^C=Exit

337


Quick-NFS Install Wizard SCREEN # 6 SERVICE GROUP INFORMATION FOR GROUPY The primary system for this service group is Cluster-System-B. Select a network device from the list shown below. Your selection will be the default network device. To enter any other option, type the new name. [j=down/k=up] le0 qfe0 qfe1 qfe2 qfe3 Public Network Device-Name: qfe0 Service Group Name: SAPGroup Service Group IP Address: 191.81.142.12 ^B=Back screen ^C=Exit

Quick-NFS Install Wizard SCREEN # 7 You can configure a service group with disks or -Volumes. If you have installed the Veritas Volume-Manager and want to configure -Volumes in your service group, answer yes to the following question. Do you want to use the Veritas Volume-Manager?: y

Quick-NFS Install Wizard SCREEN # 8 CONFIGURE FILE SYSTEM WITH VOLUMES FOR SERVICE GROUPY Select a -Volume from the list shown below. To enter any other option, type in the new name. [j=down/k=up] rootdisk3vol rootdisk4vol rootvol Swapvol Volume Name: vol1 Mount Point: /opt/SAP Mount Options: rw File System Type: vxfs Disk Group: sapdg Additional File system for this group? Y Note: The same disk group will be used if you configure additional file systems. ^B=Back screen ^C=Exit

338


Quick-NFS Install Wizard SCREEN # 9 CONFIGURE FILE SYSTEM WITH VOLUMES FOR SERVICE GROUPY Select a -Volume from the list shown below. To enter any other option, type in the new name. [j=down/k=up] rootdisk3vol rootdisk4vol rootvol Swapvol Volume Name: vol2 Mount Point: /opt/sapdata Mount Options: rw File System Type: vxfs Disk Group: sapdg Additional File system for this group? n Note: The same disk group will be used uf you configure additional file systems. ^B=Back screen ^C=Exit

Quick-NFS Install Wizard SCREEN # 10 EXIT THE QUICK-NFS WIZARD Congratulations! You have successfully created a valid NFS configuration file. The configuration file has been copied to /etc/VRTSvcs/conf/config/main.cf. Important: To run VCS you must reboot both systems. ^B=Back screen ^C=Exit

6.1.3.4

VCS-Basis-Operationen

Die Basis-Operationen für VCS sind: 왘 Start des Veritas Cluster-Servers 왘 Verifikation des Status der Service-Gruppen und Ressourcen 왘 Start und Stopp einer Service-Gruppe 왘 Migration (Failover) einer Service-Gruppe 왘 Test des Failovers 왘 Verwendung des VCS-GUI zur Überwachung des Clusters

Start des Veritas Cluster-Servers Zum manuellen Start von VCS muss das Verzeichnis, das die VCS-Kommandos enthält, in die PATH-Variable aufgenommen werden. # export PATH=$PATH:/opt/VRTSvcs/bin

339


Um die MAHGroup auf Cluster-System-A und die SAPGroup auf ClusterSystem-B zu starten, muss auf beiden Cluster-Systemen als Benutzer root folgendes Kommando eingegeben werden: # hastart

Die mit dem Quick-Start Wizard und dem Quick-NFS Wizard erstellte Konfiguration besteht aus Konfigurationsdaten für Cluster-System-A und Cluster-System-B sowie für die Service-Gruppen MAHGroup und SAPGroup. Die Konfigurationsdatei steht auf beiden Cluster-Systemen im Verzeichnis /etc/VRTSvcs/conf/config. Das Kommando hastart führt dieses Konfigurationsfile aus. Nach Start von VCS müssen sämtliche VCS-Kommandos auf beiden Cluster-Systemen eingegeben werden.

Status-Verifikation von Systemen, Service-Gruppen und Ressourcen Das ebenfalls wieder als Benutzer root eingegebene Kommando zum Überprüfen, ob beide Cluster-Systeme verfügbar sind und die Service-Gruppen mit ihren Ressourcen online sind, lautet: # hastatus –summary

Folgende Zeilen geben eine Beispiel-Status-Anzeige wieder. Dabei zeigen die System Status RUNNING und Group Status ONLINE den Zustand wieder, in dem der komplette Cluster verfügbar ist. --A A

SYSTEM STATE System Cluster-System-A Cluster-System-B

--B B

GROUP STATE Group MAHGroup SAPGroup

State RUNNING RUNNING

System Cluster-System-A Cluster-System-B

Frozen 0 0

Probed Y Y

AutoDisabled N N

State ONLINE ONLINE

Kontinuierliche Status-Informationen können auf der Konsole dadurch angezeigt werden, dass das Kommando hastatus ohne Option und Argument auf sämtlichen Cluster-Systemen eingegeben wird. Der Status der Ressourcen (hier als Beispiel die Ressource nfs-export1) wird als Benutzer root auf beiden Cluster-Systemen wie folgt abgefragt und angezeigt: # hares –display nfs-export1 #Resource nfs-export1 nfs-export1 nfs-export1 nfs-export1 nfs-export1

340

Attribute ConfidenceLevel ConfidenceLevel Probed Probed State

System Cluster-System-A Cluster-System-B Cluster-System-A Cluster-System-B Cluster-System-A

Value 0 0 1 1 ONLINE


nfs-export1 nfs-export1 nfs-export1 nfs-export1 nfs-export1 nfs-export1 nfs-export1 nfs-export1 nfs-export1 nfs-export1 nfs-export1 nfs-export1 nfs-export1 nfs-export1 nfs-export1 nfs-export1 nfs-export1

State ArgListValues ArgListValues Istate Istate MonitorOnly LastOnline Enabled AutoStart Critical TriggerEvent PathName Options OnlineNFSRestart OfflineNFSRestart Type Group

Cluster-System-B Cluster-System-A Cluster-System-B Cluster-System-A Cluster-System-B global global global global global global global global global global global global

OFFLINE /export1/... /export1/... not waiting not waiting NO YES YES YES NO /export1 0 1 Share MAHGroup

Service-Gruppen-Management – Starten, Stoppen und Migration von Service-Gruppen Zum Stoppen einer Service-Gruppe unter gleichzeitigem Offline-Setzen ihrer Ressourcen müssen folgende Kommandos als Benutzer root auf den Cluster-Systemen eingegeben werden: Auf Cluster-System-A: # hagrp –offline MAHGroup –sys Cluster-System-A

Auf Cluster-System-B: # hagrp –offline SAPGroup –sys Cluster-System-B

Mit folgenden Kommandos kann überprüft werden, ob beide Gruppen offline sind: # hagrp –display MAHGroup # hagrp –display SAPGroup

Zum Starten einer Service-Gruppe unter gleichzeitigem Online-Setzen ihrer Ressourcen müssen folgende Kommandos als Benutzer root auf den ClusterSystemen eingegeben werden: Auf Cluster-System-A: # hagrp –online MAHGroup –sys Cluster-System-A

Auf Cluster-System-B: # hagrp –online SAPGroup –sys Cluster-System-B

341


Zum Migrieren einer Service-Gruppe unter gleichzeitigem Online-Setzen ihrer Ressourcen müssen folgende Kommandos als Benutzer root auf den Cluster-Systemen eingegeben werden: Auf Cluster-System-A: # hagrp –switch MAHGroup –to Cluster-System-B

Auf Cluster-System-B: # hagrp –switch SAPGroup –to Cluster-System-A

Mit folgenden Kommandos kann überprüft werden, ob die Migration erfolgreich war: Auf Cluster-System-A: # hagrp –display SAPGroup

Auf Cluster-System-B: # hagrp –display MAHGroup

Failover Ein Failover kann dadurch getestet werden, dass eines der Cluster-Systeme heruntergefahren wird. Danach müsste der Failover automatisch erfolgen. Wurde das Cluster-System A heruntergefahren, so sollte auf Cluster-SystemB der erfolgte Failover wie folgt geprüft werden: # hagrp –display MAHGroup # hagrp –display SAPGroup

Nach Neustart des Cluster-System-B via # hastart

kann die Gruppe MAHGroup zurückmigriert werden: # hagrp –switch MAHGroup –to Cluster-System-A

Verwendung des VCS-GUI zur Überwachung des Clusters Veritas stellt mit dem Cluster-Manager eine grafische Benutzerschnittstelle (GUI) zur Überwachung und Administration eines VCS-Clusters zur Verfügung. Vor Benutzung des GUI muss 왘 ein Benutzeraccount der Cluster-Konfiguration zugewiesen werden 왘 das GUI-Display eingerichtet werden.

Der Benutzeraccount für das GUI wird als Benutzer root eingerichtet. Je nachdem, ob der Benutzer Administrationsrechte haben soll oder lediglich Monitoring betreiben soll, sind die zur Einrichtung benötigten Schritte unterschiedlich. Für die Einrichtung eines Benutzers mit administrativen Rechten müssen folgende Kommandos auf sämtlichen Rechnern des Clusters ausgeführt werden:

342

Hochverfügbare Cluster-Software 왘 Der VCS-Konfigurationsfile muss auf die read/write-Berechtigung ge-

setzt werden: # haconf –makerw 왘 Der Benutzer wird hinzugefügt. Nach Eingabe des folgenden Komman-

dos wird nach dem Passwort geprompted, das eingegeben werden muss. # hauser –add 왘 Der VCS-Konfigurationsfile wird wieder auf die read only-Berechtigung

zurückgesetzt: # haconf –dump –makero

Für die Einrichtung eines Benutzers mit lediglich überwachenden Rechten sieht die Kommandofolge auf sämtlichen Rechnern des Clusters ein wenig anders aus: 왘 Der VCS-Konfigurationsfile muss wieder auf die read/write-Berechti-

gung gesetzt werden: # haconf –makerw 왘 Der Benutzer wird hinzugefügt. Nach Eingabe des folgenden Komman-

dos wird nach dem Passwort geprompted, das jedoch nicht eingegeben werden muss. # hauser –add VCSGuest 왘 Der VCS-Konfigurationsfile wird wieder auf die read only-Berechtigung

zurückgesetzt: # haconf –dump –makero

Die Solaris (Unix)-Variante des Cluster-Managers (existiert auch als MS Windows NT oder Java-GUI) benötigt ein X-Windows-Fenster. Dazu muss jedem Cluster-System via # xhost +

die Berechtigung erteilt werden, ein X-Windows-Fenster eines auf einem anderen Host laufenden Prozesses loakal zu öffnen und anzeigen zu lassen. Darauf muss auf dem System, auf dessen Konsole ein X-Windows-Fenster des Cluster-Managers gezeigt werden soll, die DISPLAY-Umgebungsvariable gesetzt werden, für Cluster-System-B z.B. über: # export DISPLAY=Cluster-System-B:0

Nach Einrichtung des Displays kann der Cluster-Manager mit # hagui

gestartet werden. Die vier unterschiedlichen Fenster des Cluster-Manager erfüllen dabei folgende Funktionen:

343

6 Hochverfügbare SAN – Software-Komponenten 왘 Der Cluster Monitor ist das Fenster, in dem man sich in den Cluster-Mana-

ger einwählt. Hier können Cluster zur Administration durch das GUI hinzugefügt werden und Monitoring-Parameter geändert werden. Weiter werden hier zusammenfassende Informationen über jeden überwachten Cluster angezeigt. 왘 Der Cluster Explorer ermöglicht das Überwachen einzelner Systeme eines

Clusters und der diesem System zugeordneten Service-Gruppen, Ressourcen, Attribute und Abhängigkeiten. 왘 Das Log Desk von dem aus (Fehler-) Log Einträge der Cluster Engines

überwacht werden und die Ausführung von GUI-Kommandos kontrolliert werden können. 왘 Das Command Center, aus dem VCS-Kommandos aufgebaut und an die

Engine geschickt werden können.

6.1.4

Bemerkungen zu HP MetroCluster/ ServiceGuard und Veritas Cluster Server

In den bisherigen Abschnitten dieses Kapitels wurden mit MC/ServiceGuard und VCS zwei Cluster-Software-Architekturen vorgestellt, die auf der Host-Seite hochverfügbarer SAN-Umgebungen für eine möglichst hohe Verfügbarkeit der Applikationen stehen. Beide Konzepte gehen von einer Redundanz der Serverleistungen mit Path Failover-Möglichkeiten auf HBA-Ebene aus. In der Implementierung unterscheiden sich beide Architekturen leicht voneinander. Durch das Bündeln von Services, Anwendungen und Ressourcen in Packages und Versehen dieses Packages mit einer relocatable IP-Adresse ist MC/ServiceGuard in der Lage, gezielt auf Package-Fehler zu reagieren und lediglich fehlgeschlagene Packages auf einen Failover-Server zu verlagern. VCS kennt zwar ebenfalls eine Bündelung in Service-Gruppen und das Konzept der relocatable IP-Adressen, dennoch ist hier das Failover sämtlicher Service-Gruppen eines Hosts auf ein anderes Cluster-System die Folge eines Fehlers nur einer Service-Gruppe. Trotz dieses Unterschiedes ist die Funktionsweise beider Architekturen doch so ähnlich, dass der Autor im Abschnitt über MC/ServiceGuard die Funktionsweise eines solchen Host-Clusters zu beschreiben versucht hat und dann bei der Beschreibung von VCS eher einen Schwerpunkt auf die beispielhafte kommandogestützte Konfiguration eines solchen Clusters gelegt hat. In den folgenden Abschnitten soll die Software-Ausstattung der Storage Arrays des SAN erläutert werden.

344

Hochverfügbare Software für SAN Storage Arrays

6.2


Storage-Software macht schon heute für die Hersteller hochverfügbarer Storage Arrays einen Großteil ihrer Speicherumsätze aus. In Zeiten ständig sinkender Kosten pro Megabyte Plattenkapazität sind als Haupt-Differentiatoren und auch als Hauptumsatzträger zwar noch immer die SAN-Hardware bestehend aus Storage Arrays und Switches zu nennen, dennoch verlagert sich das Gewicht immer mehr auf die diesen zu Grunde liegende SpeicherSoftware und den mit dieser verbundenen Dienstleistungsanteil für Installation und Konfiguration sowie Automatisierung der SAN-Umgebung. Den Löwenanteil des Marktes für hochverfügbare Storage Arrays machen zurzeit der Marktführer EMC2 sowie Hewlett-Packard (HP) und Hitachi Data System (HDS) unter sich aus. Dabei tritt HP als Wiederverkäufer von HDS-Hardwareprodukten auf. Im Low-Price Umfeld – das in hochverfügbaren-Umgebungen relativ gering vertreten ist – treten als SAN-Anbieter noch Compaq, Sun und IBM mit der »Shark« Storage Array-Familie auf. Diese seien erwähnt, jedoch nicht näher beleuchtet. Was die Softwareunterstützung ihrer Hardware anbelangt, so liefern sie keine wesentlich anderen oder neuen Ansätze zur Einrichtung und Administration ihrer Umgebung als die »großen Drei«, fallen jedoch auch nicht hinter diesen zurück. Abbildung 6.26 zeigt die wesentlichen Softwarekomponenten für Konfiguration und Administration der Storage Arrays für HDS, HP und EMC2. EMC SRDF

HP Continuous Access

HDS HSRC

Abbildung 6.26: Storage-Software

HORC HARC(XRC) HAARC(Nanocopy) Timefinder

Business Copy XP

ShadowImage

Powerpath

Auto Path

Path manager

Infomover

Data Exchange

HMDE

Volume Logix

Secure Manager

Zone Allocation Manager

Control Center

Remote Control

Resource Manager

ECC Symm Optimizer

AutoLUN XP

Dynamic Optimizer

ECC Workload Analyser

Performance Manager XP

Graph-Track

ECC SDR

LUN Configuration Manager

LUN Manager

ECC Solutions Enabler

RAID Manager XP

Command Control

Cache LUN XP

Flashaccess

DMS Permacache Remote Support

HODM CVS

Log. Vol. Image mgr

Hi-Track

Hi-Track

345


Die Storage-Softwareprodukte sollen in folgende Kategorien unterteilt werden: Basiskomponenten zum Einrichten des Layouts der Storage Arrays Unter diese Kategorie fallen die Produkte 왘 ECC SolutionsEnabler (EMC2) 왘 RAID Manager XP (HP) 왘 Command Control (HDS).

Einrichtung von Disaster Recovery Szenarien – Remote Mirrors Unter diese Kategorie fallen die Produkte 왘 SRDF (EMC2) 왘 Continuous Access (HP) 왘 HSRC, HCRC, HARC (XRC) sowie HAARQ (Nanocopy) (HDS).

Business Continuity-Produkte – flexible Mirrors Unter diese Kategorie fallen die Produkte 왘 TimeFinder (EMC2) 왘 Business Copy XP (HP) 왘 Shadowimage (HDS).

Path Failover und dynamisches Multipathing Unter diese Kategorie fallen die Produkte 왘 PowerPath (EMC2) 왘 AutoPath (HP) 왘 Path Manager (HDS).

Datenaustausch zwischen Mainframe und OpenSystems-Umgebungen Unter diese Kategorie fallen die Produkte 왘 InfoMover (EMC2) 왘 DataExchange (HP) 왘 HMDE (HDS).

Steuerung von Volume-Access in FC-SW-Umgebungen Unter diese Kategorie fallen die Produkte 왘 VolumeLogix (EMC2) 왘 Secure Manager (HP) 왘 Zone Allocation Manager ( HDS).

346


SAN- und Speichernetzwerk-Management Unter diese Kategorie fallen die Produkte 왘 EMC Control Center ECC und ESN Manager (Enterprise Storage Net-

work Manager) von EMC2 왘 Remote Control (HP) 왘 Resource Manager (HDS).

Lastanalyse und Optimierung der Storage Arrays Unter diese Kategorie fallen die Produkte 왘 ECC Workload Analyzer und ECC Symmetrix Optimizer (EMC2) 왘 AutoLUN XP und Performance Manager XP (HP) 왘 Graph Track und Dynamic Optimizer (HDS).

Lastanalyse und Optimierung der Storage Arrays Unter diese Kategorie fallen die Produkte 왘 ECC Workload Analyzer und ECC Symmetrix Optimizer (EMC2) 왘 AutoLUN XP und Performance Manager XP (HP) 왘 Graph Track und Dynamic Optimizer (HDS).

Benutzergesteuerte LUN-Kontrolle Unter diese Kategorie fallen die Produkte 왘 ECC SDR (EMC2) 왘 LUN Configuration Manager (HP) 왘 LUN Manager (HDS).

Jedes der beteiligten Unternehmen wird begründen können, warum seine jeweilige Softwareunterstützung seiner Hardware um vieles ausgereifter und leistungsfähiger ist als die der Konkurrenz. Hier möchte ich auf die jeweiligen Marketing- und Produkt-Webseiten der einzelnen Anbieter, seien es nun HP, HDS, EMC2 oder auch Compaq, Sun und IBM, verweisen. Ein detaillierter Vergleich der einzelnen Softwareprodukte würde klar den Rahmen dieses Buches sprengen. Dennoch sei darauf verwiesen, dass aus Abbildung 6.26 und der daraus folgenden Kategorisierung der Softwareprodukte ein synchroner Gleichklang der Softwareunterstützung durch sämtliche Hersteller abgelesen werden kann. Die hier dargestellten Kategorien sind die, die der Softwareunterstützung bedürfen, und kein Hersteller eines SAN-Produktes entzieht sich dieser Möglichkeiten.

347


Wie soll nun bei der Darstellung von SAN-Software-Produkten vorgegangen werden? Eine detaillierte Darstellung sämtlicher Produkte würde, wie bereits erwähnt, weit über das hinausgehen, was der Autor im Rahmen dieses Buches leisten kann. Daher habe ich mich dazu entschlossen, sämtliche Kategorien durchgängig anhand der Softwareprodukte eines Herstellers darzustellen und mich für die Produkte des Marktführers6 auch bei den Softwareprodukten EMC2 entschieden. Wie aus den obigen Bemerkungen ersichtlich sein sollte, ist dies mit keiner Wertung verbunden. Die ausgezeichnete Funktion der Produkte der übrigen Hersteller Sun, HDS, HP, Compaq, IBM u.v.m. steht außer Frage ebenso wie ihre auf die Produkte des jeweiligen Herstellers zugeschnittene Exzellenz. Einer musste es sein – EMC2 ist es geworden.

6.2.1

Konfiguration der Storage Devices

EMC2 stellt mit dem ECC Solution Enabler ein Set von Kommandos zur Verfügung, mit dem die Konfiguration eines Storage Arrays beschrieben und auf einer host-basierten Datenbank gespeichert werden kann. Die Storage Arrays von EMC2 gehören zur Symmetrix-Produktfamilie, daher wird im weiteren auch nicht mehr allgemein vom Storage Array, sondern – da EMC2Beispiele gewählt werden – auch von den Symmetrix-Systemen gesprochen. Abbildung 6.27 zeigt die Abhängigkeiten des ECC-Solution-Enablers von der zu Grunde liegenden Hardware. Der ECC-Solution Enabler wird auf einem Serversystem installiert. Er enthält einen Satz von Command Line Interpreter Kommandos (SymCLI), mithilfe derer die Konfiguration eines an den Server via SCSI-, ESCON, Paralleloder Fibre Channel angeschlossenen Symmetrix Storage Arrays abgefragt und geändert werden kann. Die Konfiguration wird in einer Datenbank, der symapi.db auf dem Serversystem hinterlegt. Diese Datenbank liegt auf Unix-Serversystemen unter dem Pfad /var/symapi/db/symapi-db.bin, unter Windows NT unter C:\Program-Files\EMC\Symapi\db\symapi-db.bin. Der SymCLI greift bei jeder Konfigurationsabfrage oder –änderung auf die symapi.db zu. Eine Vielzahl von EMC2 –eigenen, jedoch auch von Fremd-Softwareprodukten wie z.B. Veritas Dynamic Multipathing oder Legato Networker Backup-Software nutzen ebenfalls die SymCLI-Schnittstelle als API (Application Programming Interface) zur Kommunikation mit den Symmetrix Storage Arrays. Da das Symmetrix Storage Array lediglich via SCSI-Kommandos angesprochen werden kann, diese jedoch als normaler I/O von der Symmetrix erkannt werden, existieren innerhalb der Symmetrix so genannte, lediglich 2,8 Mbytes große Gatekeeper Devices, über die die in SCSI-Kommandos interpretierten SymCLI-Kommandos an die Symmetrix weitergegeben werden.

6.

348

Gartner/IDC-Analyse


Serversystem

Gatekeeper

Abbildung 6.27: ECC-Solution Enabler Basiskomponente

Applikationen wie ECC oder ESN

Device-Gruppen

Datenbasis der SymmetrixKonfiguration symapi.db

SymCli - Symmetrix Command Line Interpreter

Gatekeeper Devices

Symmetrix Storage Array

Diese Gatekeeper werden von den Channel Directors der Symmetrix beständig gepollt, deren I/Os werden als Kommandos erkannt und unverzüglich ausgeführt. Die Trennung von Gatekeepern und »normalen« Daten Devices erfolgt vor allem, um eine unverzügliche Ausführung der Kommandos zu gewährleisten und diese nicht durch massive I/Os auf einem gemeinsam mit Daten genutzten Device zu verzögern. Sind auch auf dem Serversystem diese Gatekeeper definiert, so können Devicegruppen definiert, Devices in die Devicegruppen integriert und diese neue Konfiguration der Symmetrix in die symapi Datenbank eingetragen werden. Abbildung 6.28 zeigt die wesentlichen Kommandos des SymCLI. Sämtliche SymCLI-Kommandos müssen von dem Benutzer root oder einem Benutzer mit Root-Berechtigungen ausgeführt werden.

Operationen auf der Konfigurationsdatenbank Das einfachste Kommando ist das Kommando zur Anzeige der SymCLIUmgebung. # symcli [-env][-def][-h][-v]

349

6 Hochverfügbare SAN – Software-Komponenten Abbildung 6.28: SymCLI Basiskommandos

symapi-Operationen

symcli

syminq

symcfg

Operationen mit einzelnen »Devices« und DeviceGruppen

symdg symld Operationen mit »Gatekeeper Devices«

sympd symdev

symgate

Anzeige von StatistikInformationen

symstat

Dabei bedeuten die Optionen:

350

-env

Anzeige sämtlicher verfügbarer-Umgebungsvariable für SymCLI.-Umgebungsvariable. Es sind Folgende: SYMCLI-SID Eindeutige Symmetrix Identifikationsnummer, Seriennummer, die das Storage Array identifiziert SYMCLI-DG Name der Device-Gruppe SYMCLI-VG Name der logischen Volume-Gruppe SYMCLI-NOLOGGING Ausschalten des Logging SYMCLI-OFFLINE Offline Zugang möglich SYMCLI-NOPROMPT Keine Bestätigung vom Benutzer erforderlich SYMCLI-VERBOSE Detaillierte Ausgabe bei SRDF(Remote Mirror) und BCV- (flexible Mirror) Kontrolloperationen SYMCLI-DB-FILE Name einer symapi-Datenbank

-def

Anzeige nur der verwendeten-Umgebungsvariable

-h

Hilfe, zeigt lediglich das Kommando mit seinen Optionen an.

-v

Verbose, zeigt die Langform der Informationen des Kommandos an.


Das Kommando # syminq

[-h][-v][-copa][-la][-sym][-bcv][-nocapacity][-powerpath] []

erzeugt einen SCSI-Scan auf sämtlichen I/O-Kanälen des Servers, von dem das Kommando aus gestartet wird. Dabei bedeuten die Optionen: -bcv

Es werden nur BCV Devices (Flexible Mirrors) angezeigt.

-copa

Die Ausgabe erfolgt in einem Format für EMC2s COPA Werkzeug.

-h


-la

Ausrichtung der Ausgabe an den linken Rand.

-nocapacity

Es wird keine Speicherkapazität des Devices angegeben.

-powerpath

Zeigt lediglich sämtliche »PowerPath Devices« des Servers und ihre alternativen Pfade an.

Zeigt den Namen des Devices an, wie er im Devices-Verzeichnis des Servers eingetragen ist (CTL-Mimik).

Als Ergebnis sind nicht nur die Devices zu sehen, die der Server über seine I/O-Kanäle zum Symmetrix Storage Array sieht, sondern auch sämtliche interne Platten des Serversystems, von dem aus das syminq Kommando aufgerufen wurde. Eine Beispielausgabe des Kommandos sieht wie folgt aus: Device Product Device --------------------- --------- --------------------- ----------------Name Type Vendor ID Rev Ser Num Cap (KB) --------------------- --------- --------------------- ----------------/dev/rdsk/c0t0d0s2 SEAGATE ST318203LSun18G 034A 0013E672 17689266 /dev/rdsk/c0t1d0s2 SEAGATE ST318203LSun18G 034A 0013E610 17689266 /dev/rdsk/c0t2d0s2 FUJITSU MAG3182L Sun18G 1111 00135481 17689266 /dev/rdsk/c1t0d0s2 FUJITSU MAG3182L Sun18G 1111 00135488 17689266 /dev/rdsk/c1t1d0s2 FUJITSU MAG3182L Sun18G 1111 00135488 17689266 /dev/rdsk/c1t2d0s2 SEAGATE ST318203LSun18G 034A 0013E718 17689266 /dev/rdsk/c2t17d0s2 R1 EMC SYMMETRIX 5265 62009000 8838720 /dev/rdsk/c2t17d1s2 R1 EMC SYMMETRIX 5265 6200A000 8838720 /dev/rdsk/c2t17d2s2 R1 EMC SYMMETRIX 5265 6200B000 8838720 /dev/rdsk/c2t17d3s2 R1 EMC SYMMETRIX 5265 6200C000 8838720 /dev/rdsk/c2t17d4s2 R1 EMC SYMMETRIX 5265 6200D000 8838720 /dev/rdsk/c2t17d5s2 R1 EMC SYMMETRIX 5265 6200E000 8838720 /dev/rdsk/c2t17d6s2 R1 EMC SYMMETRIX 5265 62016000 8838720 /dev/rdsk/c2t17d7s2 R1 EMC SYMMETRIX 5265 62017000 8838720 /dev/rdsk/c2t17d8s2 R1 EMC SYMMETRIX 5265 62018000 8838720 /dev/rdsk/c2t17d9s2 R1 EMC SYMMETRIX 5265 62019000 8838720 /dev/rdsk/c2t17d10s2 R1 EMC SYMMETRIX 5265 6201A000 8838720 /dev/rdsk/c2t17d11s2 R1 EMC SYMMETRIX 5265 6201B000 8838720 /dev/rdsk/c2t17d12s2 R1 EMC SYMMETRIX 5265 6201C000 8838720 /dev/rdsk/c2t17d13s2 R1 EMC SYMMETRIX 5265 6201D000 8838720 /dev/rdsk/c2t17d14s2 R1 EMC SYMMETRIX 5265 6201E000 8838720

Abbildung 6.29: syminqBeispielausgabe

351


/dev/rdsk/c2t17d15s2 R1 EMC /dev/rdsk/c2t17d16s2 R1 EMC /dev/rdsk/c2t17d17s2 R1 EMC /dev/rdsk/c2t17d18s2 R1 EMC /dev/rdsk/c2t17d19s2 R1 EMC /dev/rdsk/c2t17d240s2 GK EMC /dev/rdsk/c2t17d241s2 GK EMC /dev/rdsk/c3t18d0s2 R1 EMC /dev/rdsk/c3t18d1s2 R1 EMC /dev/rdsk/c3t18d2s2 R1 EMC /dev/rdsk/c3t18d3s2 R1 EMC /dev/rdsk/c3t18d4s2 R1 EMC /dev/rdsk/c3t18d5s2 R1 EMC /dev/rdsk/c3t18d6s2 R1 EMC /dev/rdsk/c3t18d7s2 R1 EMC /dev/rdsk/c3t18d8s2 R1 EMC /dev/rdsk/c3t18d9s2 R1 EMC /dev/rdsk/c3t18d10s2 R1 EMC /dev/rdsk/c3t18d11s2 R1 EMC /dev/rdsk/c3t18d12s2 R1 EMC /dev/rdsk/c3t18d13s2 R1 EMC /dev/rdsk/c3t18d14s2 R1 EMC /dev/rdsk/c3t18d15s2 R1 EMC /dev/rdsk/c3t18d16s2 R1 EMC /dev/rdsk/c3t18d17s2 R1 EMC /dev/rdsk/c3t18d18s2 R1 EMC /dev/rdsk/c3t18d19s2 R1 EMC /dev/rdsk/c3t18d240s2GK EMC /dev/rdsk/c3t18d241s2 GK EMC /dev/rdsk/c4t33d0s2 R2 EMC /dev/rdsk/c4t33d1s2 R2 EMC /dev/rdsk/c4t33d2s2 R2 EMC

SYMMETRIX SYMMETRIX SYMMETRIX SYMMETRIX SYMMETRIX SYMMETRIX SYMMETRIX SYMMETRIX SYMMETRIX SYMMETRIX SYMMETRIX SYMMETRIX SYMMETRIX SYMMETRIX SYMMETRIX SYMMETRIX SYMMETRIX SYMMETRIX SYMMETRIX SYMMETRIX SYMMETRIX SYMMETRIX SYMMETRIX SYMMETRIX SYMMETRIX SYMMETRIX SYMMETRIX SYMMETRIX SYMMETRIX SYMMETRIX SYMMETRIX SYMMETRIX

5265 5265 5265 5265 5265 5265 5265 5265 5265 5265 5265 5265 5265 5265 5265 5265 5265 5265 5265 5265 5265 5265 5265 5265 5265 5265 5265 5265 5265 5265 5265 5265

6201F000 62020000 62021000 62022000 62023000 62014000 62015000 62009000 6200A000 6200B000 6200C000 6200D000 6200E000 62016000 62017000 62018000 62019000 6201A000 6201B000 6201C000 6201D000 6201E000 6201F000 62020000 62021000 62022000 62023000 62014000 62015000 99009000 9900A000 9900B000

8838720 8838720 8838720 8838720 8838720 2880 2880 8838720 8838720 8838720 8838720 8838720 8838720 8838720 8838720 8838720 8838720 8838720 8838720 8838720 8838720 8838720 8838720 8838720 8838720 8838720 8838720 2880 2880 8838720 8838720 8838720

Dabei stellen die ersten sechs Devices die internen Platten des Servers dar (leicht erkennbar an den Nicht-EMC Hersteller- und Produktangaben). R1 Devices sind lokale Devices, R2 Devices sind Remote-Mirror Devices für lokale Devices eines remote Symmetrix Storage Arrays (Disaster Recovery) und GK Devices sind Gatekeeper zur Kommunikation zwischen Server und Symmetrix.

Das Kommando

352


# symcfg

[-h] discover list [-sid <SymmID>][-v][-CA ][-noprompt][-v] offline –RA [-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]

ist das Hauptkommando zum Aufbau und zur Abfrage der symapi-Datenbank des Servers. symcfg bietet folgende Aktionen mit dem entsprechenden Ergebnis: discover

Das symcfg discover setzt einen kompletten Scan auf das Storage Array ab und baut die symapi-Datenbank mit den Ergebnissen des Scans voll auf. Dabei werden sämtliche Devices des Storage Arrays, sämtliche Device-Gruppen und sämtliche Front-End Channel Directors sowie BackEnd Disk Directors durchlaufen und in die symapi-Datenbank eingetragen, unabhängig davon, ob die Directors und die Devices über die I/O-Kanäle des Servers gesehen werden können oder nicht. Die so erzeugte symapi-db stellt also das Inventar der Symmetrix dar, nicht nur den Inhalt des Storage Arrays, den dieser Server erreichen kann.

list

Anzeige der Symmetrix-Konfiguration. Hierbei wird die symapi-Datenbank komplett angezeigt, je nachdem welche einschränkenden Optionen für das Kommando gesetzt sind.

online

Setzt die Remote Adapter der Remote Link Directors zu einer Remote Symmetrix in einer Disaster Recovery-Umgebung online. Die remote Spiegelung wird damit ermöglicht

offline

Setzt die Remote Adapter der Remote Link Directors zu einer Remote Symmetrix in einer Disaster Recovery-Umgebung offline. Eine remote Spiegelung ist nicht mehr möglich

release

Werden mit SymCLI-Kommandos an der Konfiguration eines Storage Arrays Änderungen vorgenommen, so wird die symapi-Datenbank für die Dauer dieser Operationen gesperrt. Mit der remove Aktion kann eine Sperre gezielt aus einer Sperrliste entfernt und damit die symapi-Datenbank wieder freigegeben werden. Diese Operation ist mit

353


großer Vorsicht zu genießen, da durch Aufhebung einer Sperre die Konsistenz der Datenbank gefährdet werden kann und erst durch ein erneutes discover wiederhergestellt werden kann. remove

Entfernung der symapi-Datenbank

show

Applikationen wie ECC oder ESN oder Veritas Dynamic Multipathing registrieren sich während ihrer Laufzeit an der symapi-Datenbank. Die Registrierungsdaten der Applikationen können mit show angezeigt werden.

sync

Konsistenzüberprüfung der symapi-Datenbank

verify

Überprüfung, ob die Symmetrix-Konfiguration und die Einträge in der symapi-Datenbank übereinstimmen.

Das Kommando symcfg verwendet folgende Optionen:

354

-applications

Ausgabe der Anwendungsregistrierungen, sortiert nach der Symmetrix-ID. Ist der Server über seine HBA-Ports an mehrere Symmetrix Storage Arrays angeschlossen, so wird seine symapi-DB die Konfigurationsdaten sämtlicher ihm bekannten Arrays erhalten. Daher werden diese nach Symmetrix-ID angezeigt und sortiert.

-bcv

Die Einträge über die flexible Mirrors (BCV = Business Continuance Volume) werden in der symapi-Datenbank aktualisiert.

-CA

Beschränkt die ausgewählte Aktion lediglich auf die Parallel-Adapter.

-connections

Ausgabe von aktuellen Verbindungen zwischen einem Host und einem in der symapi enthaltenen Symmetrix Storage Array. Es werden nur solche Hosts angezeigt, von denen mindestens eine Applikation an der symapi registriert ist.

-DA

Beschränkt die ausgewählte Aktion lediglich auf die DiskAdapter.

-def

Zeigt die eingestellten Werte der derzeit aktiven Umgebungsvariable an.

-DIR

Beschränkt die ausgewählte Aktion lediglich auf Channel Directors. Hiermit wird die Aktion lediglich auf das FrontEnd des Storage Arrays beschränkt.

-dirsts

Einschränkung auf einen dedizierten Channel Director.

-EA

Beschränkt die ausgewählte Aktion lediglich auf die ESCON-Adapter des Storage Arrays.

-env

Anzeige sämtlicher verfügbarer-Umgebungsvariable für SymCLI.

-force

Erzwingt die Freigabe einer externen Sperre der symapiDatenbank. Diese Option darf nur von geschultem Perso-


-h -local

-lock -lockn -noprompt -RA -rdf

-SA -semaphore -services -sid -sorthost -v

nal, also in der Regel vom Support des Herstellers genutzt werden. Hilfe, zeigt lediglich das Kommando mit seinen Optionen an. Die symapi-Datenbank wird lediglich mit lokalen Informationen aufgefrischt, ohne auf dem Remote Storage Array ebenfalls einen Scan zu durchlaufen. Zeigt an, ob eine Sperre auf der symapi-Datenbank des Servers liegt. Zeigt eine dedizierte Lock-Nummer an. Für die Aktion erfolgt keine Bestätigungsabfrage. Beschränkt die ausgewählte Aktion lediglich auf die Remote-Adapter der RLDn. Die symapi-Datenbank wird mit Informationen des remote Symmetrix Storage Arrays aufgefrischt. Hier erfolgt der Scan lediglich über das/die Remote Storage Array/s. Beschränkt die ausgewählte Aktion lediglich auf die SCSIAdapter. Zeigt benutzte Gatekeeper-, Datenbank- und Lock-DateiSemaphoren an. Zeigt die konfigurierten Netzwerkdienste an. Eindeutige Symmetrix-Identifikationsnummer, Seriennummer, die das Storage Array identifiziert. Die Liste wird nicht nach Symmetrix-ID sondern nach Servern sortiert, die an die Symmetrix/en angeschlossen sind. Detaillierte Ausgabe der Ergebnisse auf die Aktionen.

Operationen mit Gatekeeper Devices Die Operationen mit den Gatekeeper Devices werden mit dem symgate Kommando ausgeführt. # symgate associate associate <SymDevName> define define disassociate disassociate <SymDevName> list undefine undefine

[-h][-offline] -g 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>

symgate bietet folgende Aktionen mit dem entsprechenden Ergebnis:

355


associate

Das symgate associate assoziiert die Gatekeeper Devices in einer Liste von 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.

define

Trägt ein Gatekeeper Device als solches in die symapiDatenbank ein und macht es für SymCLI-Operationen verfügbar.

disassociate

Macht die Zuweisung des Gatekeeper Devices an eine Devicegruppe rückgängig.

list

Anzeige aller Gatekeeper Devices, die in der symapiDatenbank eingetragen und damit für SymCLI-Kommandos verfügbar sind.

undefine

Entfernt ein Gatekeeper Device als solches aus der symapiDatenbank und macht es für SymCLI-Operationen nicht mehr verfügbar.

Das Kommando symgate verwendet folgende Optionen:

356

-g

Angabe der Devicegruppe, für die das Kommando mit seiner gewählten Aktion gelten soll.

-h


-offline

Der Befehl wird »offline« durchgeführt, d.h., der I/O-Kanal zwischen Server und Storage Array ist nicht verfügbar, dennoch wird das Gatekeeper Device in die symapi-Datenbank eingetragen.

-sid

Eindeutige Symmetrix-Identifikationsnummer, nummer, die das Storage Array identifiziert.

Serien-


-v

Detaillierte Ausgabe der Ergebnisse der Aktionen.

Ausgabe von Storage Array-Statistiken Neben dem im Abschnitt der administrativen Software für SAN und NAS dargestellten Workload Analyzer werden durch das SymCLI symstat Auslastungsstatistiken für die an den Server angeschlossenen Storage Arrays geliefert. Die allgemeine Syntax des symstat Kommandos lautet: # symstat [-type REQUESTS [-g DgName]] [-i ][-c ][-h] -type PREFETCH [-i ][-c ][-sid <SymmID>] [-DA ][-CA ] [-DIR ] -type CACHE [-i ][-c ][-sid <SymmID>] [-EA ][-RA ][-SA ] -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>

Dabei haben die Optionen und Argumente des Kommandos folgende Bedeutung: -type

Typ der Storage Array Ressource, für die PerformanceWerte gesammelt und angezeigt werden sollen, Voreingestellt ist dabei der Typ REQUEST, der die Summe aller Zugriffe auf die Ressource (Lese- und Schreib-I/Os) misst.

-type BACKEND

Misst und zeigt die Anzahl der I/Os und den Durchsatz im Back-End (Disk-Adapter/Platte) der Symmetrix-bezogenen logischen Volumes (Devices)

-type CACHE

Gibt die während des Messintervalls gemessene durchschnittliche Cache read miss rate (I/O bedurfte eines physikalischen I/Os über einen Disk-Adapter), System disconnect rate (Disk-Adapter musste destagen), Device disconnect rate (Device I/O musste von Disk-Adapter destaged werden) wieder.

357


-type DISK.

Gibt die während des Messintervalls gemessene Anzahl der I/Os und den Durchsatz der physikalischen Laufwerke (mehrere Devices je physikalischem Laufwerk) in der Symmetrix wieder. Dabei kann der DA »Disk Director«-Einbauplatz (z.B 2A) angegeben werden. Hierbei handelt es sich um den Slot (Steckplatz) am Backpanel des Storage Arrays. Director A ist auf der Oberseite der Einsteckkarte angebracht, Director B auf der Unterseite. Der DA 2A wäre also der Disk Director auf der Oberseite des Boards, das in Slot zwei des Storage Arrays eingebaut ist. Int gibt den »Disk Director-Port« an, an dem die Platte via FWD-SCSI angeschlossen ist. Dieser kann entweder C oder D sein, da bei den Symmetrixen Dual-Initiator Disk Directors verbaut sind (vgl. Kapitel 3 dieses Buches). id stellt die SCSIAdresse des physikalischen Laufwerks (z.B. 0) dar, die das Laufwerk an diesem Disk Director-Port besitzt. id 0 wäre somit die erste Platte an diesem Disk Director-Port.

-type MEMIO

Gibt als Werte den Write pending track count (Anzahl von Spuren, die von dem Disk Director auf Platte destaged werden müssen), die Track prefetch rate (prozentualer Anteil, zu dem der Prefetch einer Spur auch für einen I/O benötigt wurde), die Track destage rate (Geschwindigkeit des Rückschreibens von Cache auf Platte) sowie das Write pending device limit percentage (zu wie viel Prozent ist der CacheBereich des einzelnen Devices gefüllt, wenn er vom Disk Director auf Platte zurückgeschrieben wird) wieder.

-type PREFETCH Gibt die Track prefetch rate (Anzahl von Spuren, die vor-

ausgelesen wurden zu Anzahl der gesamten I/Os), die Used prefetched track rate (prozentualer Anteil erfolgreicher Prefetches) und die Unused prefetched track rate (prozentualer Anteil nicht erfolgreicher Prefetches) wieder. -type DMSP

358

Die Dynamic mirroring service policy bedeutet für sämtliche Directors (DIR) die Anzeige der I/Os (Front-End, BackEnd, Remote), die Read cache request rate (prozentualer Anteil an Read-Operationen), die Write cache request rate (prozentualer Anteil der Schreibe-Operationen) sowie die Total cache request rate (Anzahl der Cache Requests) und zuletzt die Cache hit ratio, das ist der prozentuale Anteil der aus dem Cache ohne physikalischem I/O befriedigten Schreib-/Leseoperationen. Für die einzelnen Devices wird bie DMSP der Write pending track count (Spuren je Device, die aus dem Cache auf Platte geschrieben werden müssen), die Track prefetch rate (Ausnutzung des PREFETCH-Mechanismus), die Track destage rate (prozentualer Anteil der aus dem Cache auf Platte zurückgeschriebenen Spuren) sowie das Write pending device limit percentage (zu wie


viel Prozent ist der Cache-Bereich des einzelnen Devices gefüllt, wenn er vom Disk Director auf Platte zurückgeschrieben wird) angezeigt. Die Optionen des symstat-Kommandos bedeuten: -c

Count, das ist die Anzahl der Sammelaktionen und damit auch die Anzahl, wie oft eine Ausgabe erstellt wird.

-CA

Die angeforderte Aktion wird auf einen Channel Director beschränkt.

-DA

Die angeforderte Aktion wird auf einen Disk Director beschränkt.

-dev

Es werden die hexadezimalen Symmetrix Device-Namen verwendet.

-DIR

Die angeforderte beschränkt.

-disk

Die angeforderte Aktion wird auf ein physikalisches Laufwerk beschränkt.

-EA

Die angeforderte Aktion wird auf einen ESCON Adapter beschränkt.

-g

Angabe einer Devicegruppe.

-i

Zeitliches Intervall für die Sammlung und Ausgabe.

-ld

Angabe eines logischen Device-Namens. Ein Device in einem Symmetrix Storage Array kann über seinen physikalischen Namen beim Server (CTL), seinen hexadezimalen Symmetrix-Devicenamen sowie einen logischen Namen bezeichnet werden, der ihm beim Hinzufügen in eine Devicegruppe vergeben werden kann (siehe unten).

-pd

Die angeforderte Aktion wird mit dem physikalischen Device-Namen des Devices ausgeführt.

-RA

Die angeforderte Aktion wird auf einen RDF Director beschränkt.

-sid

Eindeutige Symmetrix-Identifikationsnummer, Seriennummer, die das Storage Array identifiziert.

Aktion

wird

auf

einen

Director

Mit dem symstat Kommando sind die wesentlichen Basiskommandos dargestellt, die nicht mit der Erstellung und Manipulation der Devicegruppen zusammenhängen. Diese Operationen sollen im folgenden Abschnitt dargestellt werden.

359


Matching von Cluster Packages und Disk Groups und Konfigurationen für Disaster Recovery – Lokale und Remote Device-Gruppen Wie im Abschnitt über die Cluster-Software erwähnt, sollten die Disk Groups und Package Ressourcen auf den Cluster Hosts sowohl in Größe, Anzahl der Volumes, als auch idealerweise im Namen mit einer entsprechenden Gruppierung der Shared Devices auf dem Storage Array übereinstimmen. Um ein Pendant zu Cluster Disk Groups oder Package-Ressourcen auf einer Symmetrix erstellen zu können gibt es das Konzept der Device-Gruppen auf dem Storage Array. Dabei stellt eine Device-Gruppe eine logisch zusammengehörigen Entität eines oder mehrerer Symmetrix Devices dar, die als ganze adressiert und administriert werden können. Das Kommando zum Erstellen, Manipulieren und Anzeigen einer Devicegruppe lautet symdg. # symdg

create delete dg2cg dg2file export file2dg import list rename show

[-h][-type REGULAR | RDF1 | RDF2] [-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]

Dabei bewirken die angegebenen Aktionen folgende Ergebnisse:

360

create

Erzeugt eine leere Device-Gruppe des mit der -type Option angegebenen Device-Gruppen Typs (vgl. Optionen).

delete

Löscht eine vorhandene Device-Gruppe. Sind in der DeviceGruppe noch Devices enthalten, so müssen zunächst diese entfernt werden (vgl. unten die Kommandos symld oder sympd) oder mit der -force Option das Löschen erzwungen werden. Auch hier ist die Anwendung der -force Option auf geschultes Personal zu beschränken.

dg2cg

Addiert die Device-Gruppe zu einer »Consistency«Gruppe, deren Konsistenz automatisch seitens der Storage Array Firmware überwacht wird.


dg2file

Erzeugt eine Datei in dem Format, das der ECC Open Symmetrix Manager (OSM) verwendet. Dabei handelt es sich um ein grafisches Administrationstool, mit dem eine Vielzahl von administrativen Tätigkeiten bzgl. der Symmetrix Storage Arrays ausgeführt werden kann, unter Anderem sämtliche Operationen, die mit den SymCLI-Kommandos kommandoorientiert ausgeführt werden können. Zum Open Symmetrix Manager vgl. den Abschnitt über administrative Software in diesem Buch.

export

Erzeugt eine Textdatei, die sämtliche Devices der spezifizierten Device-Gruppe enthält.

file2dg

Erzeugt eine Device-Gruppe aus einer Datei im Format des ECC Open Symmetrix Managers.

import

Importiert die Devices einer Devicegruppe aus einer Textdatei, die durch »export« erzeugt wurde.

list

Zeigt alle Device-Gruppen an, die in der symapi-Datenbank des Servers gefunden werden.

rename

Benennt eine Device-Gruppe um.

show

Zeigt Informationen über eine Device-Gruppe an.

Die Optionen des symdg Kommandos bedeuten: -bcv

Die Aktion wird auf spezifizierte BCV Devices angewendet, die mit der Devicegruppe verbunden (assoziiert) sind. BCV stellen als Business Continuance Volumes die Implementierung von flexible Mirror Devices auf Symmetrix Storage Arrays dar.

-CAP

Festschreiben einer minimalen Kapazität.

-delete

Nach dem Export in eine Formatdatei wird die Devicegruppe gelöscht.

-f

Angabe des Dateinamens einer Formatdatei.

-force

Erzwingt das Löschen einer Devicegruppe, auch wenn noch Devices in der Devicegruppe vorhanden sind und diese somit nicht leer ist.

-ftype

Angabe des Typs bei der Umwandlung einer OSM Devicegruppe (STD|R1BCV|STD-BCV|STD-R1BCV).

–g


-h


-N

Festschreiben einer maximalen Anzahl von Devices für diese Device-Gruppe.

-nobcv

Es werden nur Standard und SRDF Devices zur »Consistency«-Gruppe hinzugefügt. BCVs werden nicht zugelassen.

361


-noprompt

Eine Abfrage zur Eingabebestätigung erfolgt nicht.

-offline

Das Kommando wird ohne Zugriff auf das Storage Array aufgrund eines nicht verfügbaren Kanals »offline« ausgeführt. Das Ergebnis des Kommandos wird in die symapiDatenbank eingetragen.

-P

Angabe eines Channel Director-Ports.

-RANGE

Setzen eines Bereichs (nach hexadezimalen SymmetrixNamen) für Symmetrix Devices.

-rdf

Es wird eine Datei für die RDF Devices auf einer entfernten Symmetrix erzeugt. Dabei steht RDF für Remote Data Facility, die seitens EMC2 die Implementierung von remote Mirrors ermöglicht.

-sid

Eindeutige Symmetrix-Identifikationsnummer, Seriennummer, die das Storage Array identifiziert

-type

Typ der Gruppe bei symdg create (REGULAR|RDF1| RDF2). Dabei stellt REGULAR eine Device-Gruppe dar, die keinen remote Mirror besitzt, RDF1 die Device-Gruppe auf einer lokalen Symmetrix, die ein remote Mirror Pendant besitzt und RDF2 eine remote Device-Gruppe, die auf der lokalen Symmetrix ihre Standard-Produktions-DeviceGruppe besitzt. Eine weitere Bedeutung hat die -type Option zur Spezifikation des Betriebssystems (ACOS oder WNT) bei symlabel, dem Kommando, mit dem auf ein Symmetrix Device ein Label geschrieben wird.

-v


Nachdem mit symdg eine Device-Gruppe erzeugt wurde, können mit dem Kommando symld einzelne Devices in diese Devicegruppe hineingenommen werden. symld add add addall

break list move moveall

not-ready

362

–g [-h][-offline] pd [] –g [-h][-offline][-sid <SymmID>] dev <SymDevName> [] –g [-h][-offline][-sid <SymmID>] [-SA ][-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 ][-P #][-RDFG #][-CAP #] [-N #][-RANGE <SymDevStart>:<SymDevEnd>] –g [-noprompt][-bcv] [ […]]


ready

–g [-noprompt][-bcv] [ […]] relabel –g [-noprompt][-bcv] [ […]] remove –g [-h][-offline][-force] rename –g [-h][-offline] rmall –g [-h][-offset][-force][-SA] [-P #][-CAP #][-N #] [-RANGE <SymDevStart>: <SymDevEnd>] rw-enable –g [-h][-offline][-noprompt][-SA ] [-P #][-bcv][ [ [] [-h][-offline][-sid <SymmID>] pd –g [-SA ][-P #][-CAP #][-N #][-R1|-NOR1] [-RANGE <SymDevStart>:<SymdevEnd>] [-h][-offline][-sid <SymmID>] dev –g [-rdf][-RDFG ][-bcv][-SA ] [-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]


moveall

rmall

[-h][-offline] -g [-force][-rdf][-bcv][-rename][-SA ] [-P #][-CAP #][-N #][-R1|-NOR1] [-RANGE <SyDevStart>:<SydevEnd>] [-h][-offline] -g [-force][-rdf][-bcv] [-SA ][-P #][-CAP #] [-N #][-R1|-NOR1] [-RANGE <SymDevStart>:<SymdevEnd>]

Dabei bewirken die angegebenen Aktionen folgende Ergebnisse: associate

Weist ein BCV Device entweder mit seinem physikalischen Device-Namen 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.

associateall

Weist der angegebenen Devicegruppe alle für den Server sichtbaren BCV Devices zu. Die Zuweisung kann wiederum via physkalischem Devicename oder Symmetrix Device-Namen erfolgen.

disassociate

Entfernt ein BCV Device aus einer Device-Gruppe. Das Device kann mit physikalischem Devicenamen oder mit Symmetrix Device-Namen spezifiziert werden. Beim Assoziieren eines BCVs an eine Device-Gruppe kann dem BCV ein logischer Name vergeben werden . 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.

list

Zeigt alle BCV Devices an, die von diesem Server aus sichtbar sind oder alle BCV Devices des mit der SID identifizierten Storage Arrays, ob sie von dem Server, von dem aus das symbcv-Kommando gestartet wurde, sichtbar sind oder nicht.

367


move

Verschiebt ein über logischen Device-Namen, physikalischen Device-Namen oder Symmetrix Device-Namen identifiziertes BCV von einer Device-Gruppe in eine andere .

moveall

Verschiebt sämtliche BCVs von einer in eine andere .

rmall

Entfernt alle flexible Mirrors aus einer Device-Gruppe.

Device-Gruppe

Die Optionen des symbcv-Kommandos bedeuten:

368

-bcv

Die Aktion betrifft ein spezifiziertes BCV Device auf der S2Seite eines Disaster Recovery-Szenarios, dessen »Produktionsdevice« ebenfalls ein BCV auf der lokalen S1-Seite der Disaster Recovery-Konfiguration ist. Die Operation mit einem solchen doppelten flexible Mirror wird mit der Option -rdf verknüpft.

-CAP

Festschreiben einer minimalen Kapazität.

-force

Erzwingt das Entfernen eines BCVs aus einer Device-Gruppe, auch wenn das BCV Device noch in Gebrauch ist oder sich in einer nicht zu unterbrechenden Operation wie z.B. Synchronisation des Spiegels, Rückladen des flexible Mirror befindet. Diese Option bedarf genauester Überlegung, in welchem Zustand die Devicegruppe durch das entfernen des BCVs hinterlassen wird. Daher sollte diese Option nur von geschultem Personal durchgeführt werden.

-g


-h


-N

Festschreiben einer maximalen Anzahl von BCVs Devices für das assoziieren, entfernen oder verschieben zu/in/aus diese/r Device-Gruppe.

-offline

Das Kommando wird ohne Zugriff auf das Storage Array aufgrund eines nicht verfügbaren Kanals »offline« ausgeführt. Das Ergebnis des Kommandos wird in die symapi-Datenbank eingetragen.

-P

Angabe eines Channel Director-Ports. Lediglich die flexible Mirror Devices, die über diesen Port sichtbar sind, werden von dem symbcv-Kommando manipuliert.

-RANGE

Setzen eines Bereichs (nach hexadezimalen SymmetrixNamen). Nur BCVs aus diesem Bereich sind von dem symbcvKommando betroffen.

-rdf

Das symbcv-Kommando bezieht sich auf BCVs auf einer entfernten Symmetrix. Dabei steht RDF für Remote Data Facility, die seitens EMC2 die Implementierung von remote Mirrors ermöglicht.


-sid


-v


-c

Wiederholte Ausführung der Aktion (Count). Wird die Option -i (Intervall) ohne Angabe der Häufigkeit durch -c ausgewählt, so bedeutet dies die »unendliche« Ausführung der Aktion.

-i

Ausführungsintervall in Sek. Alle i-Sek. wird die spezifizierte Aktion ausgeführt.

-NOR1

Das spezifizierte BCV Device darf kein R1-BCV Device sein. Ein R1 Device bedeutet bei EMC2, dass das Device sich in der lokalen Symmetrix eines Disaster Recovery-Szenarios befindet. R1 Devices entsprechen den S1 Devices der Nomenklatur dieses Buches (vgl. Kapitel 3).

-R1

Für die Operation sollen nur flexible Mirrors der lokalen Symmetrix (R1-Seite) verwendet werden.

-RDFG

Spezifikation der RDF-Gruppennummer (Nummer der Device-Gruppe auf der R2-Seite, also der remote Symmetrix im Disaster Recovery-Szenario). Die RDF-Gruppennummer kann als Alternative zum eindeutigen Device-Gruppennamen verstanden werden und wird zusammen mit der -rdf-Option verwendet.

-rename

Die von einem Verschieben in eine andere Device-Gruppe betroffenen BCV Devices werden auf die voreingestellten Namen umbenannt (BCV001 für das erste BCV usw.). Bei dem voreingestellten Namen handelt es sich um den logischen Devicenamen 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.

-resv

SCSI-Devicereservierung, vgl. oben.

-SA

Bezeichnung des Channel Directors. Nur BCV Devices, die über diesen Channel Director sichtbar sind, werden von der Operation betroffen.

Mit der Zuweisung von BCV flexible Mirrors zu »ihren« Device-Gruppen, die die produktiven Standard-Devices enthalten, ist die Konfiguration des Device-Layouts des Storage Arrays abgeschlossen. In den Abschnitten Software Business Continuity Komponenten und Software Disaster Recovery Komponenten wird mit den konfigurierten flexible und remote Mirror Devices in ihren Device-Gruppen operiert.

369


Die Basiskomponente der Storage Array Software enthält nun lediglich noch Kommandos zur Anzeige der Konfiguration der Storage Devices, die im nächsten Abschnitt dargestellt werden sollen.

6.2.1.1

Anzeige der Konfiguration der Storage Devices

Mit den Kommandos sympd und symdev kann die Konfiguration der Storage Devices angezeigt werden. Das sympd operiert dabei mit den physikalischen Devicenamen der Devices in den Device-Gruppen. sympd list [-h][-offline][-sid <SymmID>][-v][-resv][-powerpath] [-SA ][-P #][-scsi][-fibre][-vcm] show

Dabei bewirken die angegebenen Aktionen folgende Ergebnisse: list

Zeigt sämtliche Devices an, die für den Server aus sichtbar sind, von dem aus das sympd-Kommando gestartet wird.

show

Gibt für das mit spezifizierte Device StatusInformationen aus.

Die Optionen des sympd-Kommandos bedeuten:

370

-bcv

sympd zeigt nur BCV Devices an.

-CAP

Festschreiben einer minimalen Kapazität der Devices, die angezeigt werden sollen.

-h


-offline

Das Kommando wird ohne Zugriff auf das Storage Array aufgrund eines nicht verfügbaren Kanals »offline« ausgeführt. Das Ergebnis des Kommandos wird in die symapi-Datenbank eingetragen.

-P

Angabe eines Channel Director-Ports. Lediglich die Devices, die über diesen Port sichtbar sind, werden von dem sympdKommando angezeigt.

-sid


-v


-resv


-SA

Bezeichnung des Channel Directors. Nur Devices, die über diesen Channel Director sichtbar sind, werden von der Operation betroffen.

-fibre

Zeigt lediglich Devices an, die über einen Fibre Channel Director des Servers sichtbar sind.


-powerpath


-scsi

Zeigt lediglich Devices an, die über einen SCSI Channel Director des Servers sichtbar sind.

-vcm

Es werden nur Volume Logix VCM Devices ausgegeben (16 Cyl., acht MB). Volume Logix Devices enthalten die Volume Logix-Konfiguration einer FCSW-Umgebung, d.h. die Konfigurationsdatenbank, welche Devices über welchen Port eines Fibre Channel Directors für welche Zone sichtbar gemacht werden (vgl. dazu unten).

Das symdev zeigt sämtliche Devices der angeschlossenen Storage Arrays an, unabhängig davon, ob sie von einem Host-Kanal gesehen werden können oder nicht. # symdev list

show

[-sid <SymmID>][-h][-offline][-v] [-scsi] [-fibre][-noport | -multiport][-vcm][-drv] [-R1][-R2][-bcv | -nobcv][-SA ] [-P #][-CAP #][-resv] [-RANGE <symdevstart:symdevend>][-N #] [-sid <SymmID>][-h][-offline] <SymDevName>

Dabei bewirken die angegebenen Aktionen folgende Ergebnisse: list

Zeigt sämtliche Devices sämtlicher für den Server, von dem aus das symdev-Kommando gestartet wird, sichtbarer Symmetrix Storage Arrays an. Dabei werden auch die Devices in den Storage Arrays angezeigt, die der Server über seine Host-Kanäle nicht sehen kann.

show

Gibt für das mit <SymdevName> spezifizierte Device detaillierte Status-Informationen aus.

Die Optionen des symdev-Kommandos bedeuten: -bcv

sympd zeigt nur BCV Devices an.

-CAP

Festschreiben einer minimalen Kapazität der Devices, die angezeigt werden sollen.

-h


-offline

Das Kommando wird ohne Zugriff auf das Storage Array aufgrund eines nicht verfügbaren Kanals »offline« ausgeführt. Das Ergebnis des Kommandos wird in die symapiDatenbank eingetragen.

-P

Angabe eines Channel Director-Ports. Lediglich die Devices, die über diesen Port sichtbar sind, werden von dem sympdKommando angezeigt.

-sid

Eindeutige Symmetrix-Identifikationsnummer, Seriennummer, die das Storage Array identifiziert.

371


372

-v


-resv


-SA

Bezeichnung des Channel Directors. Nur Devices, die über diesen Channel Director sichtbar sind, werden von der Operation betroffen.

-fibre

Zeigt lediglich Devices an, die über einen Fibre Channel Director des Servers sichtbar sind.

-powerpath


-scsi

Zeigt lediglich Devices an, die über einen SCSI Channel Director des Servers sichtbar sind.

-vcm

Es werden nur Volume Logix VCM Devices ausgegeben (16 Cyl., acht MB). Volume Logix Devices enthalten die Volume Logix-Konfiguration einer FCSW-Umgebung, d.h. die Konfigurationsdatenbank, welche Devices über welchen Port eines Fibre Channel Directors für welche Zone sichtbar gemacht werden (vgl. dazu unten).

-copa

Die Ausgabe erfolgt in einem Format für EMC2s COPAWerkzeug.

-drv

Es werden nur DRV Devices angezeigt. DRV Devices sind Dynamic Relocatable Volumes, die seitens des Symmetrix Optimizers (vgl. unten) dazu verwendet werden, eine optimale Lastverteilung auf dem Storage Array zu erreichen.

-la

Die Ausgabe erfolgt an den linken Rand ausgerichtet.

-multiport

Ausgabe von Geräten, die über mehrere Adapter angeschlossen sind.

-nobcv

Es werden alle Devices außer BCV Devices ausgegeben.

-nocapacity

Für die Devices gibt es keine Kapazitätsabfrage und -anzeige.

-noport

Ausgabe sämtlicher Geräte, die an keinem Channel Director angeschlossen sind. Dabei handelt es sich um Devices, die bereits vorinstalliert im Storage Array vorhanden sind, jedoch noch nicht genutzt werden können.

-R1

Es werden nur R1 Devices (S1 Devices nach Nomenklatur dieses Buches) ausgegeben.

-R2

Es werden nur R2 Devices (S2 Devices nach Nomenklatur dieses Buches) ausgegeben

-RANGE

Es werden nur Geräte innerhalb eines bestimmten Bereiches hexadezimaler Symmetrix Device-Namen ausgegeben.

-sym

Es werden nur Symmetrix Devices gezeigt, keine internen Platten des Servers.


Eine Beispielausgabe des symdev-Kommandos sieht wie folgt aus: Symmetrix ID: 000283701562 Device-Name Directors Device --------------------------- ------------ -----------------------------Cap Sym Physical SA :P DA :IT Config Attribute Sts (MB) --------------------------- ------------ -----------------------------000 Not Visible ???:? 01A:C0 RDF1+Mir N/Grp'd RW 8632 001 Not Visible ???:? 02A:C0 RDF1+Mir N/Grp'd RW 8632 002 Not Visible ???:? 07A:C0 RDF1+Mir N/Grp'd RW 8632 003 Not Visible ???:? 08A:C0 RDF1+Mir N/Grp'd RW 8632 004 Not Visible ???:? 09A:C0 RDF1+Mir N/Grp'd RW 8632 005 Not Visible ???:? 10A:C0 RDF1+Mir N/Grp'd RW 8632 006 Not Visible ???:? 15A:C0 RDF1+Mir N/Grp'd RW 8632 007 Not Visible ???:? 16A:C0 RDF1+Mir N/Grp'd RW 8632 008 Not Visible ???:? 01B:C0 RDF1+Mir N/Grp'd RW 8632 009 /dev/rdsk/c2t17d0s2 03B:0 02B:C0 RDF1+Mir Grp'd RW 8632 00A /dev/rdsk/c2t17d1s2 03B:0 07B:C0 RDF1+Mir Grp'd RW 8632 00B /dev/rdsk/c2t17d2s2 03B:0 08B:C0 RDF1+Mir Grp'd RW 8632 00C /dev/rdsk/c2t17d3s2 03B:0 09B:C0 RDF1+Mir Grp'd RW 8632 00D /dev/rdsk/c2t17d4s2 03B:0 10B:C0 RDF1+Mir Grp'd RW 8632 00E /dev/rdsk/c2t17d5s2 03B:0 15B:C0 RDF1+Mir Grp'd RW 8632 00F Not Visible ???:? 16B:C0 RDF1+Mir N/Grp'd RW 8632 010 Not Visible ???:? 01A:C0 2-Way Mir N/Grp'd RW 3 011 Not Visible ???:? 02A:C0 2-Way Mir N/Grp'd RW 3 012 Not Visible ???:? 07A:C0 2-Way Mir N/Grp'd RW 3 013 Not Visible ???:? 08A:C0 2-Way Mir N/Grp'd RW 3 014 /dev/vx/rdmp/c2t17d240s2 04B:0 09A:C0 2-Way Mir N/Grp'd RW 3 015 /dev/vx/rdmp/c2t17d241s2 04B:0 10A:C0 2-Way Mir N/Asst'd GK RW 3 016 /dev/rdsk/c2t17d6s2 03B:0 01A:D0 RDF1+Mir Grp'd RW 8632 017 /dev/rdsk/c2t17d7s2 03B:0 02A:D0 RDF1+Mir Grp'd RW 8632 018 /dev/vx/rdmp/c2t17d8s2 04B:0 16B:D0 RDF1+Mir N/Grp'd RW 8632 019 /dev/vx/rdmp/c2t17d9s2 04B:0 15B:D0 RDF1+Mir N/Grp'd RW 8632 01A /dev/vx/rdmp/c2t17d10s2 04B:0 07A:D0 RDF1+Mir N/Grp'd RW 8632 01B /dev/vx/rdmp/c2t17d11s2 04B:0 08A:D0 RDF1+Mir N/Grp'd RW 8632 01C /dev/vx/rdmp/c2t17d12s2 04B:0 09A:D0 RDF1+Mir N/Grp'd RW 8632 01D /dev/vx/rdmp/c2t17d13s2 04B:0 10A:D0 RDF1+Mir N/Grp'd RW 8632 01E /dev/vx/rdmp/c2t17d14s2 04B:0 15A:D0 RDF1+Mir N/Grp'd RW 8632 01F /dev/vx/rdmp/c2t17d15s2 04B:0 16A:D0 RDF1+Mir N/Grp'd RW 8632 020 /dev/vx/rdmp/c2t17d16s2 04B:0 01A:C1 RDF1+Mir N/Grp'd RW 8632 021 /dev/vx/rdmp/c2t17d17s2 04B:0 02A:C1 RDF1+Mir N/Grp'd RW 8632 022 /dev/vx/rdmp/c2t17d18s2 04B:0 10B:D0 RDF1+Mir N/Grp'd RW 8632 023 /dev/vx/rdmp/c2t17d19s2 04B:0 09B:D0 RDF1+Mir N/Grp'd RW 8632 024 Not Visible ???:? 08B:D0 RDF1+Mir N/Grp'd RW 8632 025 Not Visible ???:? 07B:D0 RDF1+Mir N/Grp'd RW 8632 026 Not Visible ???:? 02B:D0 RDF1+Mir N/Grp'd RW 8632 027 Not Visible ???:? 01B:D0 RDF1+Mir N/Grp'd RW 8632 028 Not Visible ???:? 16B:D1 RDF1+Mir N/Grp'd RW 8632 029 Not Visible ???:? 15B:D1 RDF1+Mir N/Grp'd RW 8632

Abbildung 6.30: Beispielausgabe auf das symdevKommando

373


02A 02B 02C 02D 02E 02F 030 031 032 033 034 035 036 037 038 039 03A 03B 03C 03D 03E 03F 040 041 042 043 044 045 046 047 048 049 04A 04B 04C 04D 04E 04F 050 051 052 053 054 055 056 057 058 059 05A

374

Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not

Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible 05A:0 Visible 05A:0 Visible 12A:0 Visible 12A:0 Visible ???:?

07A:C1 10B:D1 08A:C1 09B:D1 09A:C1 08B:D1 10A:C1 09A:D1 15A:C1 08A:D1 16A:C1 07A:D1 01B:C1 02A:D1 02B:C1 01A:D1 07B:C1 16B:C1 08B:C1 15B:C1 09B:C1 10B:C1 10B:D1 09B:D1 08B:D1 09A:D1 08A:D1 07A:D1 02A:D1 01A:D1 16B:C1 15B:C1 10B:C1 09B:C1 08B:C1 07B:C1 02B:C1 01B:C1 16A:C1 15A:C1 10A:C1 09A:C1 08A:C1 07A:C1 07A:D0 08A:D0 09A:D0 10A:D0 15A:D0

RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 RDF2 2-Way 2-Way 2-Way 2-Way 2-Way

N/Grp'd WD N/Grp'd WD N/Grp'd WD N/Grp'd WD N/Grp'd WD N/Grp'd WD N/Grp'd WD N/Grp'd WD N/Grp'd (M) N/Grp'd (m) N/Grp'd (M) N/Grp'd (m) N/Grp'd (M) N/Grp'd (m) N/Grp'd (M) N/Grp'd (m) N/Grp'd (M) N/Grp'd (m) N/Grp'd (M) N/Grp'd (m) N/Grp'd (M) N/Grp'd (m) N/Grp'd (M) N/Grp'd (m) N/Grp'd (M) N/Grp'd (m) N/Grp'd (M) N/Grp'd (m) N/Grp'd (M) N/Grp'd (m) N/Grp'd (M) N/Grp'd (m) N/Grp'd (M) N/Grp'd (m) N/Grp'd (M) N/Grp'd (m) N/Grp'd (m) N/Grp'd (m) N/Grp'd (M) N/Grp'd (m) N/Grp'd (m) N/Grp'd (m) N/Grp'd (m) N/Grp'd (m) Mir N/Grp'd Mir N/Grp'd Mir N/Grp'd Mir N/Grp'd Mir N/Grp'd

8632 8632 8632 8632 8632 8632 8632 8632 WD 17263 WD WD 17263 WD WD 17263 WD WD 17263 WD WD 17263 WD WD 17263 WD WD 17263 WD WD 17263 WD WD 17263 WD WD 17263 WD WD 17263 WD WD 17263 WD WD 17263 WD WD 34526 WD WD WD WD 51789 WD WD WD WD WD RW 3 RW 3 RW 3 RW 3 RW 3


05B 05C 05D 05E 05F 060 061 062 063 064 065 066 067 068 069 06A 06B 06C 06D 06E 06F 070 071 072 073 074 075 076 077 078 079 07A 07B 07C 07D 07E 07F 080 081 082 083 084 085 086 087 088 089 08A 08B

Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not Not

Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:? Visible ???:?

16A:D0 10A:D1 15A:D1 16A:D1 01A:C2 02A:C2 07A:C2 08A:C2 09A:C2 10A:C2 15A:C2 16A:C2 01B:C2 02B:C2 07B:C2 08B:C2 09B:C2 10B:C2 15B:C2 16B:C2 01A:C3 02A:C3 07A:C3 07B:D1 02B:D1 01B:D1 16B:D2 15B:D2 10B:D2 09B:D2 08B:D2 07B:D2 02B:D2 01B:D2 16A:D2 15A:D2 10A:D2 09A:D2 08A:D2 07A:D2 02A:D2 01A:D2 16B:D3 15B:D3 10B:D3 08A:C3 09B:D3 09A:C3 08B:D3

2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW 2-Way Mir N/Grp'd RW BCV N/Asst'd RW 8632 BCV N/Asst'd RW 8632 BCV N/Asst'd RW 8632 BCV N/Asst'd RW 8632

3 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632

375


08C 08D 08E 08F 090 091 092 093 094 095 096 097 098 099 09A 09B 09C 09D 09E 09F 0A0 0A1 0A2 0A3 0A4 0A5 0A6 0A7 0A8 0A9 0AA 0AB 0AC 0AD 0AE 0AF 0B0 0B1 0B2 0B3 0B4 0B5 0B6 0B7

Not Visible ???:? 10A:C3 BCV N/Asst'd Not Visible ???:? 07B:D3 BCV N/Asst'd Not Visible ???:? 15A:C3 BCV N/Asst'd Not Visible ???:? 02B:D3 BCV N/Asst'd Not Visible ???:? 16A:C3 BCV N/Asst'd Not Visible ???:? 01B:D3 BCV N/Asst'd Not Visible ???:? 02B:C3 BCV N/Asst'd Not Visible ???:? 15A:D3 BCV N/Asst'd Not Visible ???:? 07B:C3 BCV N/Asst'd Not Visible ???:? 10A:D3 BCV N/Asst'd Not Visible ???:? 08B:C3 BCV N/Asst'd Not Visible ???:? 09A:D3 BCV N/Asst'd Not Visible ???:? 09B:C3 BCV N/Asst'd Not Visible ???:? 08A:D3 BCV N/Asst'd Not Visible ???:? 10B:C3 BCV N/Asst'd Not Visible ???:? 07A:D3 BCV N/Asst'd Not Visible ???:? 15B:C3 BCV N/Asst'd Not Visible ???:? 02A:D3 BCV N/Asst'd Not Visible ???:? 16B:C3 BCV N/Asst'd Not Visible ???:? 01A:D3 BCV N/Asst'd /dev/vx/rdmp/c2t17d128s2 04B:0 01A:D3 /dev/vx/rdmp/c2t17d129s2 04B:0 16B:C3 /dev/vx/rdmp/c2t17d130s2 04B:0 02A:D3 /dev/vx/rdmp/c2t17d131s2 04B:0 15B:C3 /dev/vx/rdmp/c2t17d132s2 04B:0 07A:D3 /dev/vx/rdmp/c2t17d133s2 04B:0 10B:C3 /dev/vx/rdmp/c2t17d134s2 04B:0 08A:D3 /dev/vx/rdmp/c2t17d135s2 04B:0 09B:C3 /dev/vx/rdmp/c2t17d288s2 04B:0 09A:D3 /dev/vx/rdmp/c2t17d289s2 04B:0 08B:C3 /dev/vx/rdmp/c2t17d290s2 04B:0 10A:D3 /dev/vx/rdmp/c2t17d291s2 04B:0 07B:C3 /dev/vx/rdmp/c2t17d292s2 04B:0 15A:D3 /dev/vx/rdmp/c2t17d293s2 04B:0 02B:C3 /dev/vx/rdmp/c2t17d294s2 04B:0 01B:D3 /dev/vx/rdmp/c2t17d295s2 04B:0 16A:C3 /dev/vx/rdmp/c2t17d352s2 04B:0 02B:D3 /dev/vx/rdmp/c2t17d353s2 04B:0 15A:C3 /dev/vx/rdmp/c2t17d354s2 04B:0 07B:D3 /dev/vx/rdmp/c2t17d355s2 04B:0 10A:C3 /dev/vx/rdmp/c2t17d356s2 04B:0 08B:D3 /dev/vx/rdmp/c2t17d357s2 04B:0 09A:C3 /dev/vx/rdmp/c2t17d358s2 04B:0 09B:D3 /dev/vx/rdmp/c2t17d359s2 04B:0 08A:C3

RW 8632 RW 8632 RW 8632 RW 8632 RW 8632 RW 8632 RW 8632 RW 8632 RW 8632 RW 8632 RW 8632 RW 8632 RW 8632 RW 8632 RW 8632 RW 8632 RW 8632 RW 8632 RW 8632 RW 8632 BCV N/Asst'd BCV N/Asst'd BCV N/Asst'd BCV N/Asst'd BCV N/Asst'd BCV N/Asst'd BCV N/Asst'd BCV N/Asst'd BCV N/Asst'd BCV N/Asst'd BCV N/Asst'd BCV N/Asst'd BCV N/Asst'd BCV N/Asst'd BCV N/Asst'd BCV N/Asst'd BCV N/Asst'd BCV N/Asst'd BCV N/Asst'd BCV N/Asst'd BCV N/Asst'd BCV N/Asst'd BCV N/Asst'd BCV N/Asst'd

RW RW RW RW RW RW RW RW RW RW RW RW RW RW RW RW RW RW RW RW RW RW RW RW

8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632 8632

Obiges Beispiel ist bewusst nicht gekürzt worden, um ein Gefühl für die Anzahl adressierbarer Devices in einem Storage Array zu vermitteln.

376


Device-Name Directors --------------------------- -----------Cap Sym Physical SA :P DA :IT Config --------------------------- ------------

Device -----------------------------Attribute Sts (MB) ------------------------------

Abbildung 6.31: Listenkopf symdevErgebnisliste

Der Listenkopf der symdev-Ergebnisliste soll hier erläutert werden, um eine genaue Zuordnung und ein Verständnis der Device-Informationen zu gewährleisten. Die angezeigten Werte sollen anhand der letzten Zeile des obigen Ergebnisses erläutert werden: 왘 Die Haupt-Spalte Device-Name ist untergliedert in Sym (hexadezimaler

Symmetrix Devicename 0B7) und Physical (physikalischer Devicename beim Server). So sagt der physikalische Devicename /dev/vx/rdmp /c2t17d359s2), dass es sich um ein Device unter Veritas Volume-Manager VxVM handelt (/dev/vx) und als Raw Device (rdmp) auf Controller 2, Target 17, Disk 359 und Slice zwei seitens des Servers gesehen wird. 왘 Die Spalte der Directors unterteilt sich in SA:P (Channel Director oder

System Adapter und Port auf dem Channel Director) und DA:IT (DiskAdapter:Interner Port/Target, entspricht dem n-ten Device auf dem Port). Für unser Beispiel des Device 0B7 bedeutet dies, dass es über den Port 0 des Channel Directors 04B (Einschubplatz 04, oberes Prozessorboard) sichtbar ist und das 4. Device (Nummerierung beginnt mit 0, daher entpricht 3 dem 4. Device) auf Port C des Disk-Adapters 08A (Einschubplatz 08, oberes Prozessorboard) darstellt. 왘 Die Device-Informationen untergliedern sich in Informationen, als was

dieses Device konfiguriert ist (Config), das Attribute gibt GruppenInformationen wieder, Sts gibt an, wie das Device zu verwenden ist und CAP (MB) gibt die Devicekapazität in MB wieder. Die Config-Spalte kann folgende Werte annehmen: 왘 2-Way Mir stellt ein Standard-Device mit lokalem Spiegel-Device dar. 왘 RDF1+ Mir stellt ein lokales Produktionsdevice eines Disaster Recovery-

Szenarios (R1 Device) mit zusätzlichem lokalen Spiegel dar. 왘 RDF2+ Mir stellt einen remote Mirror eines Disaster Recovery-Szenarios

(R2 Device) mit zusätzlichem lokalen Spiegel dar. 왘 RDF2 stellt einen remote Mirror eines Disaster Recovery-Szenarios (R1

Device) mit zusätzlichem lokalen Spiegel dar. 왘 RS stellt ein lokales Standarddevice mit Raid-S Absicherung dar. 왘 UP stellt ein lokales Standarddevice ohne jegliche Absicherung dar. 왘 BCV stellt einen flexible Mirror dar.

377


Die Config-Spalte kann folgende Werte annehmen: 왘 N/Grpd – das Device gehört keiner Device-Gruppe an. 왘 N/Asst'd – das BCV wurde niemals einer Device-Gruppe zugeordnet 왘 Grpd – das Device gehört zu einer Device-Gruppe. 왘 Diverses – diverse Zustände des flexible Mirror. Diese werden später nä-

her erläutert ( vgl. Abschnitt Software Business Continuity-komponenten). Abbildung 6.32: HardwareKonfiguration für Dynamic Multipathing

Front-End



Ba ck-End To p-Low

Ca c h e S lo ts

Dis k Dire c to r

P ort A P ort B



Ho s t

P ort C P ort D


P ort A P ort B Tra c k Ta b le Ch a n n e l Dire c to r




P ort C


P ort D

High Me mory DA (Dis kAd a p te r)

Low Me mory


Bo tto m-High Bo tto m-Low

Die Sts (Statuses) Spalte kann folgende Werte annehmen: 왘 WD – das Device ist ein Read-Only Device. 왘 RW – das Device ist Read/Write Enabled. 왘 NR – das Device ist Not Ready To Host.

6.2.1.2

Konfiguration für Dynamic Multipathing

Zur Erläuterung des dynamischen Multipathing sei nochmals auf eine frühere Abbildung zurückgegriffen (vgl. Abbildung 6.32). Um ein dynamisches Path-Failover durchführen zu können und so vor Verlust der Devices bei Ausfall eines Host-Kanals geschützt zu sein, waren serverseitig zwei Host-Bus-Adapter notwendig, die auf Ports zweier unterschiedlicher Channel Directors des Storage Arrays verbunden sind. Diese

378


Channel Directors müssen vom gleichen Typ sein und auf denselben internen Bussen des Storage Arrays sitzen, um die gleichen Devices im Back-End des Storage Arrays sehen zu können. Softwareseitig wird diese Konfiguration bei EMC2 durch das Produkt Powerpath unterstützt, der vom grafischen Administrations-GUI (vgl. Management Software unten) oder über den Powerpath CLI gesteuert wird. watch dev

Ausgabe des Device-Status

set mode

Pfad wird auf aktiv oder standby gesetzt

display dev set policy watch

Ausgabe des Adapterdisplay Status

powermt

Abbildung 6.33: Dynamic Multipathing – der Powerpath CLI

Einstellung der Lastverteilung

set priority

check-registration save

restore

Pfad wird getestet. Er wird wieder benutzt, wenn er in Ordnung ist.

# powermt

load

Konfiguration sichern und laden

check [dev=device|all] [adapter=adapter#|all] check-registration config display display dev=power#|all restore save set adapter-switch=disabled|enabled adapter=adapter# set mode=active|standby adapter=adapter# [dev=power#|all] set policy=rr|io|lb|so [dev=power#|all] set priority= [dev=power#|all] validate watch every=#seconds watch dev=power#|all every=#seconds

379


check

Überprüft, ob alle Pfade mit den richtigen Symmetrix Volumes verbunden sind. Dabei muss einer der beiden Parameter [dev=device|all] [adapter=adapter#|all] angegeben sein. Bei der Überprüfung wird je nach Parameterwahl ausgehend von den Devices des Storage Arrays oder von den Host-Bus-Adaptern geprüft, ob sämtliche Devices über sämtliche Channel Directors und Host-Bus-Adapter der alternativen Pfade sichtbar und im gleichen Modus nutzbar sind (rw-enabled oder write-disabled).

check-registration Überprüft die Lizensierung und liefert Information

über die konfigurierte Powerpath-Lizenz.

380

config

Konfiguriert die alternativen Pfade zu allen bekannten Symmetrix Devices für maximale Verfügbarkeit und Durchsatz.

display

Überprüft sämtliche Host-Bus-Adapter und zeigt die Status-Informationen aller gefundenen Hostadapter an.

display dev

Zeigt den Status eines mit power# spezifizierten oder aller über Powerpath erreichbaren Devices an.

restore

Versucht alle Device-Pfade, die als geschlossen markiert sind, wieder zu aktivieren. Ein Device-Pfad oder Kanal wird als geschlossen markiert, sobald er aufgrund eines Port-Fehlers am Host-Bus-Adapter oder am Channel Director nicht mehr verfügbar ist. Nach Behebung des Fehlers wird mit dem restore der Kanal wieder verfügbar gemacht.

save

Sichert die momentane Powerpath-Konfiguration.

set adapter-switch

Schaltet den angegebenen Channel Director ein oder aus.

set mode

Setzt den Device-Pfad auf aktiv oder »standby«. Einer der alternativen Kanäle muss stets aktiv sein, einer muss stets als standby definiert sein. Dabei bedeutet das standby nicht, dass dieser Kanal inaktiv ist. Über ihn wird gemäß der Lastverteilungspolitik ebenfalls auf die Devices geschrieben und gelesen. Er wird nur klar als Pfad definiert, auf den ein Pfad-Failover stattfindet, sobald ein aktiver Pfad aufgrund eines Fehlers ausfällt.

set policy

Einstellung des gewünschten Lastverteilungs-Algorithmus. Dabei kann aus drei Lastverteilungsverfahren gewählt werden. In einem Round-Robin-Verfahren werden die einkommenden I/O-Requests auf die definierten Powerpath-Kanäle der Reihe nach verteilt. Ein I/OCount-Verfahren teilt einen neuen I/O-Request dem Kanal zu, in dessen I/O-Queue die geringste Anzahl an


I/O-Requests steht. Beide Verfahren garantieren jedoch keine optimierte oder gleiche Lastverteilung. Beim Round-Robin-Verfahren werden genau wie beim reinen I/O-Count-Verfahren die I/O-Requests als solche verteilt. Dies bedeutet, ein Kanal erhält einen I/ORequest, der lediglich eine geringe Anzahl von Device Tracks (beispielsweise Änderung eines Kapitels in einer Textdatei) betrifft, ein anderer Kanal erhält einen I/O-Request, der die Änderung einer Vielzahl von Tracks enthält (z.B. Datenbank-Update zur prozentualen Erhöhung/Senkung der Preise sämtlicher Produkte eines Versandhauses). Beide Kanäle sind mit einer tatsächlich massiv differierenden Last ausgestattet worden. Im dritten Verfahren, der Lastgleichverteilung, wird die tatsächliche Auslastung der Kanäle bei der Zuteilung eines I/O-Requests beachtet. Den neuen I/ORequest bekommt der Kanal zugeteilt, der tatsächlich die geringste Auslastung hat. set priority

Zusätzlich zur Lastverteilungs-Politik kann über die Vergabe einer Priorität für die angegebenen Devices eine »Vorzugsbehandlung« für I/Os einzelner Devices erzielt werden. Es können die Prioritäten 0 – 10 vergeben werden, wobei 10 den I/O mit der höchsten Priorität darstellt. Bei der Lastverteilung werden Hochprioritäts-I/Os gegenüber I/Os niedriger Priorität bevorzugt.

validate

Überprüft, ob der primäre (der aktive) Pfad für jedes Powerpath Device mit dem richtigen Symmetrix Volume verbunden ist.

watch every

Zeigt periodisch im Abstand der angegebenen Zeit in Sek. den Status der Channel Directors.

watch dev

Zeigt periodisch im Abstand der angegebenen Zeit in Sek. den Status der angegebenen Devices.

6.2.2

Software Business ContinuityKomponenten

In diesem Abschnitt soll der Umgang mit flexible Mirrors, in EMC2-Terminologie BCVs (Business Continuance Volumes) dargestellt werden. BCVs wurden mit dem oben dargestallten SymCLI Basiskommando symbcv einer bestehenden Devicegruppe zugeordnet. Die Manipulation des BCVs bedarf einer Solution Enabler-Zusatzkomponente, der TimeFinder-Komponente des SymCLI.

381


6.2.2.1

Business Continuity-Konzepte

Zielsetzung der Business Continuity-Konzepte ist es sogeannte geplante Ausfallzeiten von Anwendungen so gering als möglich zu halten. Dabei geht es darum, konsistente Replikate von Daten mehreren konkurrierenden Prozessen zur Verfügung zu stellen. Abbildung 6.34: Anwendung von flexible Mirrors für Business Continuity

F C H B A

Daten

Daten

Daten

F A

Original Devices

Daten

Daten

Flexible Mirror Devices

Daten

F A

Host A Produktion F C H B A

F C H B A

Host B Backup

Storage Array F C H B A

Abbildung 6.34 soll den Sachverhalt beschreiben. Es exisitieren zwei konkurrierende Prozesse – Backup und Produktion. Beide benötigen die Original-Devices – Backup zur Sicherung der Daten, Produktion zur Aufrechterhaltung der Produktion. Klassische Backup-Verfahren würden für die konsistente Sicherung der Daten die Applikation stoppen, die Datensicherung von den Original-Devices fahren und danach die Applikation wieder starten. Eine solche Prozedur würde voraussichtlich nicht über eine SANLösung, sondern eher über ein eigenständiges Backup-Netzwerk realisiert, wofür ein LAN-Controller sowohl beim Backup-Host, als auch beim Produktions Host – über den das Backup »seiner« Devices laufen müsste – involviert werden müsste. Unabhängig davon, über welchen physikalischen Pfad die Datensicherung erfolgt, ist für die klassischen Backup-Verfahren kennzeichnend, dass für die Datensicherung die Applikation gestoppt werden muss und es zu einer geplanten Unterbrechung des Produktionsbetriebes kommt. Die Dauer der

382


Unterbrechung ist abhängig von der Menge der Daten und der Geschwindigkeit der Backup-Pfade. Abbildung 6.35 zeigt das Problem der konkurrierenden Prozesse. Geplante Ausfallzeiten System ist verfügbar

00:00 Uh r

Anwendung wird gestoppt, Konkurrierender Prozess wird gestartet

Abbildung 6.35: Das Problem konkurrierender Prozesse

Ba Backups ckups

Aktua Aktualis lisie iere renn von von Da Data ta Wa Ware rehous houseess Prozess wird beendet, Neustart der Anwendung

Komple Komplexe xe Re Reports ports und und Que Querie riess Ba Batchve tchvera rarbe rbeitung itung

03:00 Uh r

System ist wieder verfügbar

Zielsetzung: kleiner werdende Zeitfenster für geplante Ausfallzeiten bei gleichzeitig wachsenden Informationsbeständen

Um eine Reduktion der geplanten Ausfallzeiten zu erreichen, können in SAN-Umgebungen mit leistungsfähigen Storage Arrays flexible Mirrors eingesetzt werden. Die flexible Mirror Devices stellen Spiegel-Devices ihrer Standard-Devices dar, die jedoch im Gegensatz zu klassischen Mirrors aufgebrochen werden können. Dank der Möglichkeit des Splits des Mirrors, kann das flexible Mirror Device unseres obigen Beispiels vom Standard-Device synchronisiert werden und damit quasi über den Produktions-Host gesehen und manipuliert werden. Während der Synchronisationsphase respektive solange das flexible Mirror Device nicht von seinem Standard-Device getrennt wird, ist es für den Backup-Host nicht sichtbar. Nach erfolgter Synchronisation wird es von seinem Standard-Device getrennt, der Produktions-Host sieht das Device nicht mehr. Es wird nun einem konkurrierenden Prozess, dem Backup respektive dem Backup-Host zugeordnet. Dieser sieht die flexible Mirrors nun und führt seine Operationen aus, während die Produktion auf den Standard-Devices über den Produktions-Host unbehindert weiterläuft. Die Ausfallzeit reduziert sich auf die Zeitdauer der konsistenten Trennung des flexible Mirrors von seinem Standard-Device, von bis zu mehreren Stunden auf wenige Sek. bis Minuten.

383


Nach erfolgtem Backup wird das flexible Mirror Device dem Backup Host entzogen, wieder seinem Standard-Device zugeordnet und von diesem resynchronisiert. Diese Aktion erfolgt cachebasiert im Storage Array, ohne Involvierung des Produktions-Hosts und ohne Beeinträchtigung des Laufzeitverhaltens der Anwendung, da Produktions-I/O vor dem Resynchronisierungs-I/O bevorzugt wird.

6.2.2.2

Implementierung von Business Continuity

Die Anwendungsschritte zur Implementierung der Business Continuity mithilfe von flexible Mirrors wurde bereits in Kapitel vier dieses Buches dargestellt. Es sei hier daher nur nochmals die Reihenfolge der Schritte in Erinnerung gerufen. Dabei soll – da auch hier auf die Implementierung der flexible Mirrors von EMC2 zurückgegriffen werden soll – direkt auch die Nomenklatur von EMC2 verwendet werden. 왘 Einrichtung eines BCV

Dieser Schritt wird von dem SymCLI Basiskommando symbcv abgedeckt. Mit dem Assoziieren eines BCVs an eine Device-Gruppe ist das BCV als flexible Mirror eingerichtet. 왘 Synchronisieren eines BCV

Dieser Schritt wird von dem SymCLI TimeFinder Kommando symmir abgedeckt. Mit dem Establish eines BCVs von einem Standard-Device wird das BCV als flexible Mirror von seinem Standard-Device synchronisiert. Dabei werden beim ersten Establish sämtliche Tracks des Standard-Devices auf das BCV übertragen. Jedes weitere Establish nach der ersten Trennung des BCVs von seinem Standard-Device kann inkrementell erfolgen. Hierbei werden nur noch die invalid Tracks, das sind die Spuren, die sich auf dem Standard-Device seit der Trennung verändert haben, auf das BCV kopiert. Invalid Tracks werden in einer Track Table im Cache des Symmetrix Storage Arrays gehalten, sodass auf sie sofort zugegriffen werden kann. 왘 Gewährleistung einer konsistenten Trennung des BCV

Dieser Schritt wird von den SymCLI TimeFinder Kommandos symmir und symioctl abgedeckt. Bei Anwendungen auf Basis von Datenbank Managementsystemen (DBMS) ohne Hot Backup Funktionalität (z.B. CAIngres oder Sybase ASE bis Release 11.5 einschließlich) oder auf Basis von Filesystemen müssen die Transaktionen kurzfristig gestoppt werden, um die Hauptspeicher-Puffer des Produktions-Host auf das Storage Array zu schreiben und den Cache des Storage Arrays zurück auf Platte zu schreiben. In einer solchen Umgebung kommt es zu einer – allerdings im Vergleich zum traditionellen Backup – sehr kurzen geplanten Ausfallzeit der Anwendung. Besitzt ein DBMS jedoch die Hot Backup Funktionalität (Oracle ab Release 8, Sybase ASE ab Release 12), muss das DBMS und damit die Anwendung nicht gestoppt werden. Die Tablespaces oder Daten-

384


banken werden lediglich in den Hot-Backup-Modus versetzt. Dies versieht die Originaldaten des Standard-Devices mit einem Zeitstempel, wann das BCV von dem Original-Device getrennt wurde und vermerkt diesen Zeitstempel auch in den Redo-Logfiles oder Transaktions-Protokollen der betroffenen Datenbanken. Dadurch wird sichergestellt, dass sich sämtliche zum Zeitpunkt des Trennens abgeschlossenen Transaktionen auf dem BCV befinden und sämtliche zum Zeitpunkt des Trennens noch nicht abgeschlossenen und sämtliche danach gestartete Transaktionen aus den Redo Logfiles oder Transaktions-Protokollen wiederhergestellt werden können. 왘 Trennung eines BCVs von seinem Standard-Device

Dieser Schritt wird von dem SymCLI TimeFinder Kommando symmir abgedeckt. Mit dem Split eines BCVs von seinem Standard-Device wird sichergestellt, dass sämtliche I/Os für das Standard-Device, die bis zum Zeitpunkt des Split als komplett an den Produktions-Host gemeldet wurden, vom Cache des Storage Arrays auf das Standard-Device destaged und damit auch auf das BCV geschrieben werden, bevor die tatsächliche physikalische Trennung stattfindet. 왘 Neustart der Transaktionen

In diesem Schritt werden evtl. gestoppte Anwendungen wieder gestartet oder – bei Hot Backup Datenbanken – der Backup Modus über das TimeFinder Kommando symioctl wieder beendet. 왘 Verwendung des BCVs für einen konkurrierenden Prozess

Das BCV wird vom Host des konkurrierenden Prozesses in dessen Filesystem-Hierarchie integriert, als write disabled oder read/write enabled aktiviert und dem konkurrierenden Prozess zur Verfügung gestellt. Nach Beendigung der Aktivität des konkurrierenden Prozesses wird das BCV vom Host des konkurrierenden Prozesses wieder freigegeben und beginnt diesen Prozess wieder mit dem Synchronisieren eines BCV. Die beteiligten TimeFinder-Kommandos innerhalb dieses Prozesses werden im Folgenden dargestellt. Das symmir-Kommando steuert sämtliche Operationen, die das BCV betreffen und nichts mit der Konsistenz der Anwendungsdaten zu tun haben.

385


# symmir –g 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 ] ..) –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 ]]..)

386


restore

#

#

#

#

[-h][-v][-noprompt][-rdf][-i ][-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] ([ [-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]] [ [ ..]] –f query -sid <SymmID> [-v][-i ][-c ] [-force][-symforce][-attach][-multi [-bg]] symmir –g verify [-h][-v][-rdf][-bcv][-i ][-c ] [-offline][-synched|-restored|-split [-bg]| -syncinprog|-restinprog][-bcv-mirrors][-force] [ [ ..]] –f verify -sid <SymmID> [-v][-i ][-c ] [-force][-symforce][-synched|-restored|-split [-bg]| -syncinprog|-restinprog][-bcv-mirrors]

Dabei bewirken die angegebenen Aktionen folgende Ergebnisse: attach

Verknüpft die Standard-Devices mit ihren BCVs. Dabei können drei Kombinationen der Zuweisung der BCVs zu ihren Standard-Devices gewählt werden: 왘 Das Standard-Device wird mit seinem logischen De-

vice-Namen angegeben (DEV001), das BCV wird mit seinem physikalischen Namen angegeben.

387

6 Hochverfügbare SAN – Software-Komponenten 왘 Das Standard-Device wird mit seinem logischen De-

vice-Namen angegeben (DEV001), das BCV wird mit seinem Symmetrix Device-Namen angegeben (0A0). 왘 Sowohl Standard-Device (DEV001), als auch BCV

(BCV001) werden mit ihrem logischen Namen angegeben. Beim Attachen der Devices wird mit der -g die Device-Gruppe mitgegeben, in der sowohl die BCV Devices, als auch ihre Standard-Devices enthalten sein müssen. Mit der -f Option kann sowohl die Device-Gruppe, als auch die Liste der in dieser DeviceGruppe enthaltenen Standard- und BCV Devices aus einer Konfigurationsdatei ausgelesen werden. Diese Option wird genutzt, wenn die Attach-Operation häufiger automatisiert angewendet wird. Hier müssen lediglich die Device-namen in der Konfigurationsdatei geändert/erweitert werden, wenn sich an dem Attachment etwas ändern soll. detach

Hebt die Verknüpfung der Standard-Devices mit ihren BCVs wieder auf. Dabei können drei Kombinationen der Bezeichnung der BCVs und ihrer Standard-Devices gewählt werden: 왘 Das Standard-Device wird mit seinem logischen De-

vice-Namen angegeben (DEV001), das BCV wird mit seinem physikalischen Namen angegeben. 왘 Das Standard-Device wird mit seinem logischen De-


(BCV001) werden mit ihrem logischen Namen angegeben. Beim Detachen der Devices wird mit der -g die Device-Gruppe mitgegeben, in der sowohl die BCV Devices, als auch ihre Standard-Devices enthalten sein müssen. Mit der -f Option kann sowohl die Device-Gruppe, als auch die Liste der in dieser DeviceGruppe enthaltenen Standard- und BCV Devices aus einer Konfigurationsdatei ausgelesen werden. Diese Option wird genutzt, wenn die Detach-Operation häufiger automatisiert angewendet wird. Hier müssen lediglich die Device-namen in der Konfigurationsdatei geändert/erweitert werden, wenn sich an dem Detachment etwas ändern soll. cancel

388

Hebt eine Delta Mark Session der Standard-Devices mit ihren BCVs wieder auf. Delta Mark stellt die eigenständig


zu lizenzierende Symmetrix Differential Data Facility (SDDF) dar, auf die hier nicht eingegangen werden soll. Die CancelOption wird daher nur der Vollständigkeit halber erwähnt. Dabei können drei Kombinationen der Bezeichnung der BCVs und ihrer Standard-Devices gewählt werden: 왘 Das Standard-Device wird mit seinem logischen De-


vice-Namen asngegeben (DEV001), das BCV wird mit seinem Symmetrix Device-Namen angegeben (0A0). 왘 Sowohl Standard-Device (DEV001), als auch BCV

(BCV001) werden mit ihrem logischen Namen angegeben. Beim Cancel der Session wird mit der -g die Device-Gruppe mitgegeben, in der sowohl die BCV Devices, als auch ihre Standard-Devices enthalten sein müssen. Mit der -f Option kann sowohl die Device-Gruppe, als auch die Liste der in dieser DeviceGruppe enthaltenen Standard- und BCV Devices aus einer Konfigurationsdatei ausgelesen werden. Diese Option wird genutzt, wenn die Cancel-Operation häufiger automatisiert angewendet wird. Hier müssen lediglich die Device-namen in der Konfigurationsdatei geändert/erweitert werden, wenn sich an den Session-Cancels etwas ändern soll. establish

Started die Synchronisation der BCVs einer Device-Gruppe von ihren Standard-Devices. Dabei können drei Kombinationen der Bezeichnung der BCVs und ihrer StandardDevices gewählt werden: 왘 Das Standard-Device wird mit seinem logischen De-



(BCV001) werden mit ihrem logischen Namen angegeben. Beim Establishen der Devices wird mit der -g die Device-Gruppe mitgegeben, in der sowohl die BCV Devices, als auch ihre Standard-Devices enthalten sein müssen. Mit der -f Option kann sowohl die Device-Gruppe, als auch die Liste der in dieser DeviceGruppe enthaltenen Standard- und BCV Devices aus einer

389


Konfigurationsdatei ausgelesen werden. Diese Option wird genutzt, wenn die Establish-Operation häufiger automatisiert angewendet wird. Hier müssen lediglich die Device-Namen in der Konfigurationsdatei geändert/erweitert werden, wenn sich an dem Synchronisieren etwas ändern soll. restore

Startet die Wiederherstellung der Standard-Devices von ihren BCVs. Dabei können drei Kombinationen der Bezeichnung der BCVs und ihrer Standard-Devices gewählt werden: 왘 Das Standard-Device wird mit seinem logischen De-



(BCV001) werden mit ihrem logischen Namen angegeben. Beim Restore der Standard-Devices wird mit der -g die Device-Gruppe mitgegeben, in der sowohl die BCV Devices, als auch ihre Standard-Devices enthalten sein müssen. Mit der -f Option kann sowohl die Device-Gruppe, als auch die Liste der in dieser DeviceGruppe enthaltenen Standard- und BCV Devices aus einer Konfigurationsdatei ausgelesen werden. Diese Option wird genutzt, wenn die Restore-Operation häufiger automatisiert angewendet wird. Hier müssen lediglich die Devicenamen in der Konfigurationsdatei geändert/erweitert werden, wenn sich an den Wiederherstellungsparametern etwas ändern soll. Exkurs: Als Argument für die Verwendung von flexible Mirrors für konkurrierende Prozesse wurde im Wesentlichen auf die zeitliche Reduktion geplanter Ausfallzeiten verwiesen. Die Restore-Funktionalität der BCVs führt jedoch zu einer durchaus als noch wesentlich angenehmer empfundenen Senkung ungeplanter Ausfallzeiten – nämlich der ungeplanten Ausfallzeiten aufgrund logischer Daten(bank)fehler, die aufgrund fehlerhafter Bedienung der Anwendungs-Software zustandekommen. Wird beispielsweise in einer Datenbankanwendung fälschlicherweise in einer Transaktion ein Datensatz gelöscht, der nicht gelöscht werden durfte, so muss über den RecoveryMechanismus des DBMS der konsistente Zustand der Datenbank wiederhergestellt werden, der zuletzt vor dieser fehlerhaften Transaktion bestanden hat. Der Recovery-Mechanismus erfordert ein Zurückladen einer gültigen Datensicherung und einem Rollforward sämtlicher korrekter Trans-

390


aktionen die vor Start der fehlerhaften Transaktion erfolgreich abgeschlossen waren. Man stelle sich die Dauer des Rückladens einer mit 100 Gbytes Größe mittelgroßen Datenbank von Sicherungsmagnetband vor, während dessen die Applikation nicht verfügbar ist. Diese ungeplante Ausfallzeit kann durch BCVs (flexible Mirrors) immens verkürzt werden, wenn diese zum Zeitpunkt des logischen Datenbankfehlers nicht mit ihrem StandardDevice verknüpft waren (und daher den logischen Fehler nicht auch enthalten).7 Mit dem Start des Restore kann schon das Rollforward des DatenbankManagement-Systems gestartet werden, obwohl das Standard-Device noch nicht komplett von seinem BCV wiederhergestellt wurde. Dies wird dadurch erzielt, dass ab dem Start des Restore sämtliche Write I/Os lediglich auf das wiederherzustellende Standard-Device gerichtet werden, während lesende Zugriffe auf das BCV oder das Standard-Device erfolgen, je nachdem, welches der beiden Devices aktuellere Daten enthält. split

Trennt das BCV von seinem Standard-Device. Vor dem Split muss mit dem unten erläuterten Kommando symioctl die Konsistenz der Daten auf dem BCV sichergestellt werden. Beim Trennen der Devices wird mit der -g die Device-Gruppe mitgegeben, in der sowohl die BCV Devices, als auch ihre Standard-Devices enthalten sein müssen. Mit der -f Option kann sowohl die Device-Gruppe, als auch die Liste der in dieser DeviceGruppe enthaltenen Standard- und BCV Devices aus einer Konfigurationsdatei ausgelesen werden. Diese Option wird genutzt, wenn die Split-Operation häufiger automatisiert angewendet wird. Hier müssen lediglich die Device-namen in der Konfigurationsdatei geändert/erweitert werden, wenn sich an dem Split etwas ändern soll.

query

Überprüft den Fortschritt der zuvor angestoßenen Establish-, Split- oder Restore-Operation. Bei der Überprüfung des Fortschritts der jeweiligen Operation wird mit der -g die Device-Gruppe mitgegeben, in der sowohl die BCV Devices, als auch ihre Standard-Devices enthalten sein müssen. Mit der -f Option kann sowohl die Device-Gruppe, als auch die Liste der in dieser Device-Gruppe enthaltenen Standard- und BCV Devices aus einer Konfigurationsdatei ausgelesen werden. Diese Option wird genutzt, wenn die Query-Operation häufiger automatisiert

7.

Allein schon aus diesem Grunde empfiehlt sich der Einsatz mehrerer Generationen von flexible Mirrors (BCVs). Da zu einem gegebenen Zeitpunkt nur eine Generation mit ihrem Standard-Device verknüpft sein kann, stehen die übrigen Generationen für ein Restore zur Verfügung, da auf ihnen der stattgefundene logische Datenbankfehler nicht enthalten sein kann.

391


angewendet wird. Hier müssen lediglich die Devicenamen in der Konfigurationsdatei geändert/erweitert werden, wenn sich an dem Query etwas ändern soll. verify

Überprüft den Status der Device-Gruppen und einzelner Devices nach einer zuvor angestoßenen Establish-, Splitoder Restore-Operation. Bei der Überprüfung des Status der Devices wird mit der -g die Device-Gruppe mitgegeben, in der sowohl die BCV Devices, als auch ihre Standard-Devices enthalten sein müssen. Mit der -f Option kann sowohl die Device-Gruppe, als auch die Liste der in dieser DeviceGruppe enthaltenen Standard- und BCV Devices aus einer Konfigurationsdatei ausgelesen werden. Diese Option wird genutzt, wenn die Verify-Operation häufiger automatisiert angewendet wird. Hier müssen lediglich die Devicenamen in der Konfigurationsdatei geändert/erweitert werden, wenn sich an dem Verify etwas ändern soll.

Die Optionen des symmir-Kommandos bedeuten:

392

-attach

Mit dieser Option zeigt die Query-Operation auch die Informationen über die Zuordnung von Standard-Devices und BCVs an.

-bcv

Die angegebene Operation wird mit den BCVs auf der remote Seite eines Disaster Recovery-Szenarios durchgeführt. Bedingung für die Verwendung dieser Option ist jedoch, dass zusätzlich zu den BCVs auf der R2-Seite (Remote Storage Array) auch auf der R1-Seite (lokal) den Standard-Devices BCVs zugeordnet sind und als weitere Option -rdf verwendet wird.

-bcv-mirrors

Die ausgewählte Operation wird auf die Spiegel der BCV Devices angewendet. Diese Option macht nur dann Sinn, wenn die BCV Devices zusätzlich durch einen eigenen lokalen Spiegel abgesichert sind. Eine solche zusätzliche Absicherung ist stets dann angebracht, wenn die flexible Mirrors nach dem Split von ihren Standard-Devices einem konkurrierenden Prozess zugeordnet werden sollen, der die auf den BCVs befindlichen Daten auch verändern können soll.

-bg

Bei einer Query-Operation wird angezeigt, ob sich die BCV Devices gegenüber ihren Standard-Devices im Status background split befinden. Bei der Verify-Operation in Verbindung mit der -split Option wird überprüft, ob sich die BCVs nach einem Background Split im Status Split befinden. Ein Background Split erlaubt die Durchführung der Split-


Operation im Hintergrund. Der Vordergrundprozess kann mit weiteren Aktionen beginnen, während der Split als Hintergrundprozess noch läuft. -bypass

SCSI Device-Reservierungen durch andere Server werden umgangen.

-c

Anzahl (count), wie häufig die Ausführung des Kommandos versucht werden soll oder wie häufig das Kommando tatsächlich ausgeführt werden soll. Der Halbsatz bzgl. eines Versuchs der Ausführung des Kommandos bezieht sich dabei auf die Situation, dass die symapi-Datenbank gesperrt ist und das Kommando daher nicht ausgeführt werden kann. Ohne einen solchen Count würde das Kommando mit einer Fehlermeldung abbrechen (vgl. unten Statuscodes für die SymCLI-Operationen).

-diff

Nach dem Split soll der Inhalt des BCVs auf einen Spiegel des BCVs differentiell kopiert werden. Dabei wird zunächst das BCV von seinem Standard-Device synchronisiert. Mit erfolgtem Split wird das BCV dann auf sein Spiegel-Device kopiert. Würde die -diff-Option nicht verwendet, so würde das Spiegel-Device des BCVs während des laufenden Establish ebenfalls aktualisiert. Diese Vorgehensweise könnte – in einer Umgebung mit multiplen Spiegeln – jedoch dazu führen, dass die Vielzahl der Spiegel zu einem Cache-Engpass führen könnten, der den laufenden Produktionsbetrieb im Laufzeitverhalten behindern könnte. Dies wird dadurch ausgeschlossen, dass die Synchronisation des BCVs stets der Produktions-Aktivität nachgeordnet ist. Das wiederum kann bedeuten, dass die Synchronisation der BCVs nicht in einem vorgesehenen Zeitfenster abgeschlossen werden kann. Daher kann mit dieser Option das Aktualisieren des Spiegels des BCVs zeitversetzt zum Aktualisieren des BCVs und ohne Behinderung des Laufzeit-verhaltens für die Produktion stattfinden.

-exact

Die Zuordnung der BCVs zu ihren Standard-Devices und die Reihenfolge der Devices beim Start eines vollen Establish oder vollen Restore (sämtliche Device Tracks werden auf das / von dem BCV geschrieben) wird genau nach der Reihenfolgeder Devices in der Device-Gruppe durchgeführt.

-force

Erzwingt die Ausführung eines Kommandos, auch wenn sich die von dem Kommando betroffenen Devices nicht in dem benötigten Status befinden oder die Ausführung aus anderen Gründen blockiert wird.

-full

Sämtliche Tracks werden für die Ausführung der Operation kopiert.

393


-g

Angabe einer Device-Gruppe, für die die ausgewählte Operation ausgeführt werden soll.

-h


-i

Zeitintervall, das in Verbindung mit der Option -c angibt, wie häufig und in welchen Zeitabständen die Ausführung des Kommandos gestartet wird. Dabei sind 10 Sek. für das Zeitintervall voreingestellt.

-instant

Beschleunigt die Ausführung der Split-Operation.

-multi

Bei Ausführung einer Query-Operation im Rahmen einer SDDF-Session werden alle BCVs angezeigt, mit denen eine inkrementelle Operation (Kopie lediglich der seit dem letzten Split veränderten Tracks) durchgeführt werden kann.

-noprompt


-not-ready

Nach Ausführung einer Split-Operation werden die BCVs der Device-Gruppe auf den Zustand NR geschaltet, nach einem Restore werden die Standard-Devices auf den Zustand NR geschaltet. Der Zustand NR (Not Ready To Host) erlaubt die Zuordnung der BCVs zu einem konkurrierenden Prozess und die Überprüfung der StandardDevices vor dem Neustart der Anwendung.

-offline

Das Kommando wird ohne Zugriff auf das Storage Array »offline« ausgeführt. Das Ergebnis des Kommandos wird in die symapi-Datenbank eingetragen.

-opt

Die Zuordnung der BCVs einer Device-Gruppe zu den Standard-Devices der Device-Gruppe wird optimiert. Dabei wird nach folgender Reihenfolge der Optimierung vorgegangen: 왘 Das BCV ist über einen anderen Channel Director zu er-

reichen als sein Standard-Device (dadurch Verwendung eines anderen internen Kanals des Storage Arrays). Ist dies nicht möglich wird als nächste Iterationsstufe versucht: 왘 Das BCV ist über einen anderen Disk-Adapter zu errei-

chen als sein Standard-Device (dadurch eine Verteilung der I/O-Last auf zwei Controller). Wenn auch das nicht sicherzustellen ist, so muss als letztes sichergestellt sein: 왘 Das BCV liegt auf einem anderen physikalischen Lauf-

werk als sein Standard-Device. -rdf

394

Das Kommando bezieht sich auf BCVs auf einer entfernten Symmetrix. Dabei steht RDF für Remote Data Facility, die seitens EMC2 die Implementierung von remote Mirrors ermöglicht.


-remote

Die Operation wird lokal auf der remote Symmetrix eines Disaster Recovery-Szenarios durchgeführt, jedoch parallel dazu über den SRDF-Link der Remote Link Directors gleichzeitig auch auf der lokalen Symmetrix.

-restored

Es wird überprüft, ob sich alle Standard-Device/BCV Device-Paare im Zustand Restored befinden. Dieser Zustand zeigt an, dass die Wiederherstellung eines Standard-Devices von seinem BCV erfolgreich abgeschlossen wurde.

-restinprog

Es wird überprüft, ob sich alle Standard-Device/BCV Device-Paare im Zustand Restore-In-Progress befinden. Dieser Zustand zeigt an, dass der Restore zwar gestartet wurde, jedoch noch nicht beendet ist.

-reverse

Nach einer Split Operation wird eine Kopie der SpiegelDevices der BCV Devices auf die Devices einer ersten BCVGeneration durchgeführt. Eine solche Operation ist dann sinnvoll, wenn über zwei BCV-Generationen ein schnelles Restore gewährleistet werden soll. Hierdurch wird sichergestellt, dass beide BCV-Generationen stets den jüngsten synchronen Zustand besitzen.

-split

Es wird überprüft, ob sich alle Standard-Device/BCV Device-Paare im Zustand Split befinden. Dieser Zustand zeigt an, dass die Trennung eines BCVs von seinem Standard-Device erfolgreich abgeschlossen wurde.

-symforce

Erzwingt die Durchführung einer Operation auf dem Symmetrix Storage Array, auch wenn ein Zustand der Devices, der Device-Gruppe oder des Storage Arrays die Durchführung der Operation unter normalen Umständen verhindert. Diese Option sollte lediglich durch EMC2-Mitarbeiter durchgeführt werden, da durch sie ein inkonsistenter Status der Devices erzeugt werden kann.

-synched

Es wird überprüft, ob sich alle Standard-Device/BCV Device-Paare im Zustand Synchronized befinden. Dieser Zustand zeigt an, dass das Establish eines BCV-Devices von seinem Standard-Device erfolgreich abgeschlossen wurde.

-syncinprog

Es wird überprüft, ob sich alle Standard-Device/BCV Device-Paare im Zustand Synchronization-In-Progress befinden. Dieser Zustand zeigt an, dass der Establish zwar gestartet wurde, jedoch noch nicht beendet ist.

-v


Die Operationen können lediglich mit den angegebenen Optionen kombiniert aufgerufen werden. Abbildung 6.36 stellt nochmals die TimeFinderOperationen den Optionen gegenüber, mit denen sie kombiniert werden können.

395


Das symioctl-Kommando gewährleistet beim Split eines BCVs die Konsistenz von Datenbank-Daten auf den BCV Devices. # symioctl [-h] –type begin backup .. [-noprompt] end backup .. [-noprompt] freeze .. [-noprompt] thaw .. [-noprompt] Abbildung 6.36: TimeFinder BCVOperationen und Optionen

Option -bypass -c -i

-force -opt -remote -rdf

-diff

-v

Operation establish establish -full split restore -full

√ √

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

√

query

√

√

√

√

√ √

√ √

verify


396

begin backup

Die spezifizierten Tablespace-Objekte oder DatenbankObjekte werden in den Hot-Backup-Modus gesetzt (nur Oracle und Sybase ASE ab Release 12). Dabei wird in den Redo-Logs (Oracle) und im Transaktions-Protokoll (Sybase) der Timestamp des Backups gesetzt. Sämtliche zu diesem Zeitpunkt abgeschlossenen Transaktionen befinden sich auf den BCVs, sämtliche nicht abgeschlossenen oder neuen Transaktionen müssen über Redo-Log und Transaktions-Protokoll wiederhergestellt werden.

end backup

Beendet einen mit begin backup initiierten Hot-BackupModus.

freeze

Friert kurzfristig während des Splits der BCVs von ihren Standard-Devices alle I/O-Operationen zu einer spezifizierten Datenbank-Anwendung ein, wobei der Cache des Storage Arrays auf Produktions- und BCV Devices geschrieben


wird und diese damit den konsistenten Zustand der Datenbank zum Zeitpunkt des Split enthalten. thaw

Der durch einen freeze eingefrorene I/O-Betrieb wird wieder aktiviert.

Die Optionen des ioctl-Kommandos bedeuten: -type

6.2.3

Typ der unterstützten Datenbank. Mögliche Werte sind dabei Oracle, Informix oder MS-SQLServer.

Software Disaster RecoveryKomponenten

Die hardwareseitige Implementierung eines Disaster Recovery-Szenarios besteht, wie in Kapitel vier dargestellt, aus folgenden Komponenten. 왘 Mindestens zwei Serversysteme in unterschiedlichen Lokationen, die

von unterschiedlichen Stromkreisen versorgt werden, zumindest mit einem Brandschutz voneinander getrennt sind, sich idealerweise jedoch bei Verwendung von Fibre Channel, bis zu 60 Kilometer voneinander entfernt befinden. Die Serversysteme sind idealerweise zu einem Cluster zusammengefasst, der bidirektional Failoverfunktionalitäten übernimmt. 왘 Die Serversysteme sind mit mindestens zwei Host-Bus-Adaptern ausge-

stattet, über die ein dynamisches Multipathing mit Path-Failover realisiert ist. 왘 Mindestens zwei Fibre Channel-Switches – an jeder der beiden Lokatio-

nen einer – über die der Ausfall eines der beiden Switches abgefangen werden kann. Beide Serversysteme sind mit ihren Host-Bus-Adaptern an beide Switches angeschlossen, sodass auch hier ein Path Failover unterstützt werden kann. 왘 Zwei hochverfügbare Storage Arrays – je eines an jeder der beiden Loka-

tionen – die jeweils mit mindestens zwei Fibre Channel Directors ausgestattet sind, über die das dynamische Multipathing auf Speicher-Seite implementiert wird. 왘 Je Storage Array mindestens zwei ESCON oder – idealerweise – Fibre

Channel Remote Link Direktoren, über die ein bidirektionales remote Mirroring der Devices stattfindet. Abbildung 6.37 visualisiert nochmals die Hardwarekonfiguration eines Disaster Recovery-Szenarios.

397

6 Hochverfügbare SAN – Software-Komponenten Abbildung 6.37: Hardware Disaster Recovery-Konfiguration

F C H B A


F C H B A

AIX-Server

F C H B A

F A

F A

Local

Remote

Storage

Storage

Array

Array

F A

F A

F C H B A


F C H B A


In obigem Szenario würde bei Wegbrechen des lokalen Switches ein Failover auf die Remote-Seite stattfinden. Würden die freien Ports auf den Host-BusAdaptern dazu genutzt, einen Failover-Pfad auf den jeweiligen Remote Switch zu implementieren, könnte im Disaster-Fall ein Failover lediglich auf der Storage-Seite durchgeführt werden, da das lokale Storage Array über den lokalen Switch nicht mehr verfügbar ist. Zur Softwareseitigen Implementierung eines solchen Szenarios ist serverseitig die entsprechende Cluster Software notwendig. Auf Storage-Seite sind folgende Schritte auszuführen. 왘 Einrichtung lokaler Device-Gruppen auf dem lokalen Storage Array

(symdg create –type RDF1 ). 왘 Hinzufügen sämtlicher Applikations-Devices zu diesen Device-Gruppen

(symld add, vgl. vorne). 왘 Einrichtung von remote Device-Gruppen auf dem Remote Storage Array

(symdg create –type RDF2 ). 왘 Hinzufügen sämtlicher Remote Mirror Devices zu diesen Device-Grup-

pen (symld add, vgl. oben). 왘 Synchronisierung der remote Mirrors von den lokalen Produktions-De-

vices.

398

Hochverfügbare Software für SAN Storage Arrays 왘 Operationen mit den remote Mirror Devices wie Auftrennen der Syn-

chronisation (split) oder Wiederherstellung eines lokalen ProduktionsDevices von seinem remote Mirror Device (restore). Folgende Schritte wären in einem Disaster-Fall seitens einer EMC2 SymCLISteuerung zu implementieren: 왘 Aufbrechen des Remote Link zwischen den beiden Storage Arrays. 왘 Die bisherigen Produktionsdevices auf dem lokalen Storage Array müss-

ten auf Write-Disabled und Not-Ready-To-Host gesetzt werden. 왘 Die bisherigen remote Mirror Devices auf dem Remote Storage Arrays

müssten auf Read-Write-Enabled und Ready-To-Host gesetzt werden. Mit diesen Schritten ist ein Failover vom lokalen Storage Array auf das Remote Storage Array abgeschlossen. Sobald der Fehler auf der lokalen Seite behoben ist, durch den das Failover erzwungen wurde, kann ein Failback vom Remote Storage Array auf das lokale Storage Array vorbereitet und durchgeführt werden. Die Schritte für das Failback sind: 왘 Aktualisieren der lokalen Devices vom remote Mirror. 왘 Abgleich der Track Tables des lokalen und Remote Storage Arrays. 왘 Die Failover Devices des Remote Storage Arrays müssen wieder auf

Write-Disabled und Not-Ready-To-Host gesetzt werden. 왘 Die Produktions-Devices des lokalen Storage Array müssen wieder auf

Read-Write-Enabled und Ready-To-Host gesetzt werwden. 왘 Aktivieren des Remote Link zwischen den beiden Storage Arrays.

Nach diesen Einzelschritten ist der Failback auf das lokale Storage Array erfolgt. Sämtliche hier skizzierten Aktionen sind Operationen des symrdfKommandos, das im Folgenden dargestellt werden soll. Dabei sollen die Operationen nach Funktionen gruppiert werden, um die Übersichtlichkeit des Kommandos zu gewährleisten. Die Optionen des Kommandos werden nach der Darstellung sämtlicher Operationen in einem eigenständigen Abschnitt erläutert, um unnötige Wiederholungen zu vermeiden.

6.2.3.1

Einstellung der Arbeitsweise des remote Mirroring

Die Arbeitsweise des remote Mirroring definiert die garantierte Synchronizität zwischen den Devices der R1- und der R2-Seite. # symrdf -g set mode sync|semi|acp-disk|acp-wp|acp-off [-v][-bcv|-rbcv|-brbcv|-all][-bypass] [-noprompt][-i ][-c ] [skew ] [ [ ..]]

399


set domino

on | off [-v] [-bcv|-rbcv|-brbcv|-all][-bypass][-noprompt] [-i ][-c ] [ [ ..]] set acp-skew [-v] [-bcv|-rbcv|-brbcv|-all][-bypass] [-noprompt] [-i ] [-c ] [ [ ..]]

Dabei bewirken die angegebenen Aktionen folgende Ergebnisse: set mode

Setzt den Betriebs-Modus für den SRDF-Betrieb. Zu den Betriebs-Modi vgl. Abschnitt Konfiguration für Distanz-Topologien in Kapitel vier dieses Buches.

set domino

Schaltet den Domino Betriebs-Modus ein oder aus. Zu den Betriebs-Modi vgl. Abschnitt Konfiguration für Distanz-Topologien in Kapitel vier dieses Buches.

set acp-skew

Setzt den Skew-Wert für die Adaptive Copy-Betriebsart. Zu den Betriebs-Modi vgl. Abschnitt Konfiguration für DistanzTopologien in Kapitel vier dieses Buches.

6.2.3.2

Einzelkommandos zur Steuerung der Disaster Recovery-Konfiguration

# symrdf -g suspend [-v|-noecho][-force][-bcv|-rbcv|-brbcv|-all] [-bypass][-noprompt][-i ] [-c ][ [ ..]] resume [-v|-noecho][-force][-bcv|-rbcv|-brbcv|-all] [-bypass][-noprompt][-i ] [-c ][ [ ..]] merge [-v|-noecho][-force][-bcv|-rbcv|-brbcv|-all] [-bypass][-noprompt] [-i ] [-c ][ [ ..]] update [-v|-noecho][-force][-bcv|-rbcv|-brbcv|-all] [-bypass][-noprompt][-i ][-c ] [-until ] [ [ ..]] ready [-v|-noecho][-force][-bcv|-rbcv|-brbcv|-all] [-bypass][-noprompt] [-i ][-c Count] [LdevName [LdevName ..]] not ready r1 | r2 [-v|-noecho][-force][-bcv|-rbcv|-brbcv| -all][-bypass][-noprompt][-i ] [-c ][ [ ..]] rw-enable r1 | r2 [-v|-noecho][-force][-bcv|-rbcv|-brbcv| -all][-bypass][-noprompt][-i ] [-c ][ [ ..]]

400


write-disable

refresh

invalidate

r1 | r2 [-v|-noecho][-force][-bcv|-rbcv|-brbcv| -all][-bypass][-noprompt][-i Interval] [-c Count][LdevName [LdevName ..]] r1 | r2 [-v|-noecho][-force][-bcv|-rbcv|-brbcv| -all][-bypass][-noprompt][-i ] [-c ][ [ ..]] r1 | r2 [-v|-noecho][-force][-bcv|-rbcv|-brbcv| -all][-bypass][-noprompt][-i ] [-c ][ [ ..]]

Dabei bewirken die angegebenen Aktionen folgende Ergebnisse: suspend

Trennt die SRDF-Verbindung der beiden Symmetrix Storage Arrays über die Remote Link Directors.

resume

Aktiviert die SRDF-Verbindung der beiden Symmetrix Storage Arrays über die Remote Link Directors.

merge

Mischt die Track Tables der beiden Storage Arrays. Mit diesem Schritt wird sichergestellt, dass die wiederhergestellte R1-Seite beim Failback sämtliche auf der R2-Seite geänderten Tracks auf den Produktionsdevices enthält.

update

Beginnt mit der Re-Synchronisation der R1 Devices von ihren aktiven R2 Remote Mirror Devices, während auf diesen nach erfolgtem Failover noch die Produktion läuft.

ready

Setzt die angegebenen Devices auf Ready-To-Host.

not ready

Setzt die angegebenen Devices auf Not-Ready-To-Host.

rw-enable

Setzt die angegebenen Devices auf Read-Write-Enabled.

write-disable

Setzt die angegebenen Devices auf Write-Disabled.

refresh

Markiert auf den wiederhergestellten lokalen Devices nach Vergleich mit der remote Track Table alle geänderten Spuren, damit sie mit den Daten der remote Mirrors überschrieben werden können.

invalidate

Vorbereitung für eine komplette Synchronisation der Devices entweder durch ein Establish oder ein Restore.

6.2.3.3

Container-Kommandos zur Steuerung des Remote Mirroring und Disaster Recovery

# symrdf -g establish [-v|-noecho][-force][-bcv|-rbcv|-brbcv|-all] [-bypass][-noprompt] [-i ][-c ] [-full][ [..]] restore [-v|-noecho][-force][-bcv|-rbcv|-brbcv|-rbcv| -brbcv|-all][-bypass] [-noprompt][-i ] [-c ][-full][ [ ..]]

401


split

failover

failback

[-v|-noecho][-force][-bcv|-rbcv|-brbcv|-all] [-bypass][-noprompt] [-i ] [-c ][ []] [-v|-noecho][-force][-bcv|-rbcv|-brbcv|-all] [-bypass][-noprompt] [-i ] [-c ][ [ ..]] [-v|-noecho][-force][-bcv|-rbcv|-brbcv|-all] [-bypass][-noprompt] [-i ] [-c ][ [ ..]]


402

establish

Aufbau der RDF-Verbindung zwischen den Storage Arrays über die Remote Link Directors und Synchronisation der remote Mirror Devices (R2 Devices) von ihren lokalen Produktions-Devices (R1 Devices).

restore

Aufbau der RDF-Verbindung zwischen den Storage Arrays über die Remote Link Directors und Re-Synchronisation der lokalen Produktions-Devices (R1 Devices) von ihren remote Mirror Devices (R2 Devices). Dieses Restore erfolgt, nachdem ein Failover stattgefunden hat und die Produktion über eine diskrete Zeitdauer auf den Devices der R2Seite stattgefunden hat.

split

Trennen der RDF-Verbindung zwischen den Storage Arrays über die Remote Link Directors. Weiter werden remote Mirror Devices (R2 Devices) auf Read-Write-Enabled gesetzt. Dieser Split erfolgt, um gezielte geplante Wartungsarbeiten an der Disaster Recovery-Konfiguration vorzunehmen. Dafür wird die Produktion für die Zeitdauer der Wartungsarbeiten auf den Devices der R2-Seite gefahren, bevor ein Failback stattfindet und danach die Wartung ebenfalls im Split-Zustand auf der R2-Seite durchgeführt wird.

failover

Aufbrechen des Remote Link zwischen den beiden Storage Arrays. Die bisherigen Produktionsdevices auf dem lokalen Storage Array werden auf Write-Disabled und NotReady-To-Host gesetzt. Die bisherigen remote Mirror Devices auf dem Remote Storage Arrays werden auf ReadWrite-Enabled und Ready-To-Host gesetzt. Die Applikationen können nach erfolgtem Failover auf dem Remote Server gestartet werden.

failback

Aktualisieren der lokalen Devices vom remote Mirror. Abgleich der Track Tables des lokalen und Remote Storage Arrays. Die Failover Devices des Remote Storage Arrays werden wieder auf Write-Disabled und Not-Ready-To-Host gesetzt. Die Produktions-Devices des lokalen Storage Array werden wieder auf Read-Write-Enabled und Ready-


To-Host gesetzt. Der Remote Link zwischen den beiden

Storage Arrays wird wieder aktiviert. Danach können die Applikationen auf dem lokalen Server neu gestartet werden.

6.2.3.4 # symrdf # symrdf # symrdf

# symrdf

Abfrage der Funktionsfähigkeit und StatusInformationen zum remote Mirroring [-h] ping list

[-sid <SymmID>][-i ][-c ][-rdf] [-sid <SymmID>][-i ][-c ] [-offline][-v][-R1|-R2][-RDFG ] [-bcv|-nobcv][-resv][dev|pd][-consistency] -g query [-bcv|-rbcv|-brbcv|-all][-offline] [-i ][-c ] [ [..]] verify [-bcv|-rbcv|-brbcv|-all][-offline] [-i ][-c ] [[-synched|-suspended|[-enabled]] | -susp-offline|-split|-failedover|-updated| -syncinprog|-updateinprog|-partitioned| -valid][ [..]]

Dabei bewirken die angegebenen Aktionen folgende Ergebnisse: ping

Überprüfung der SRDF-Verbindung durch Abschicken einer Acknowledge-Anforderung an sämtliche beteiligten Storage Arrays. Ist die SRDF-Verbindung zwischen den Storage Arrays aktiv, so wird ein Acknowledge zurückgeschickt.

list

Ausgabe der für das Disaster-Szenario angelegten Devices.

query

Abfrage des Status der Synchronizität zwischen den lokalen Produktions- (R1 Devices) und remote Mirror Devices (R2 Devices). Mit dieser Operation kann angezeigt werden, welches Device der RDF1 Device-Gruppe mit welchem Device der RDF2 Device-Gruppe verknüpft ist, also welches Device auf dem Remote Storage Array der remote Mirror eines lokalen Produktions-Devices ist.

verify

Verifikation des Zustandes der R1/R2-Synchronizität der Devices einer Device-Gruppe.

403


6.2.3.5

404

Optionen der Operationen zum remote Mirroring

-all

Die angegebene Operation wird mit sämtlichen Devices der Device-Gruppe ausgeführt.

-bcv

Die Operation wird lediglich mit lokalen BCV Devices durchgeführt.

-brbcv

Die Operation wird mit einem remote BCV durchgeführt, wobei das lokale Standard-Device des BCV ebenfalls ein BCV ist.

-bypass

Vorhandene Sperren in der symapi-Datenbank werden umgangen. Die Option darf nur dann angewendet werden, wenn sichergestellt ist, dass keine anderen SRDF-Operationen lokal oder remote aktiv sind und diese Sperre gesetzt haben.

-c

Definition der Wiederholungsrate des Kommandos mithilfe eines Zählerwerts (Count).

-cg

Die Operation wird auf Devices einer consistency group angewendet. Operationen auf Konsistenzgruppen werden hier nicht dargestellt, da diese lediglich eine zusätzliche Ebene der Gewährleistung der Konsistenz der R1/R2Daten darstellen, die in unseren Diskussionen durch die Wahl der geeigneten Betriebsart sichergestellt wird.

-consistency

Anzeige des Status der Konsistenz der Devices.

-enabled

Überprüfung, ob sich die R1/R2-Devicepaare im Zustand consistency-state-enabled befinden.

-f

Mit der -f Option kann sowohl die DeviceGruppe, als auch die Liste der in dieser Device-Gruppe enthaltenen Standard- und BCV Devices aus einer Konfigurationsdatei ausgelesen werden.

-force

Die Aktion wird erzwungen.

-full

Bei einer establish oder restore-Operation werden sämtliche Spuren des Quell-Devices auf das Ziel-Device synchronisiert.

-g

Angabe einer Device-Gruppe.

-h


-i

Zeitintervall, das in Verbindung mit der Option -c angibt, wie häufig und in welchen Zeitabständen die Ausführung des Kommandos gestartet wird. Dabei sind 5 Sek. als Minimum für das Zeitintervall vorzusehen.

-nobcv

Die Operation wird nur mit Standard RDF Devices, nicht mit BCV Devices, durchgeführt


-noecho

Fortschrittsanzeigen der Operation werden nicht an das Display gesendet.

-noprompt


-offline

Das Kommando wird ohne Zugriff auf das Storage Array »offline« ausgeführt. Das Ergebnis des Kommandos wird in die symapi-Datenbank eingetragen.

-partitioned

Überprüft, ob sich die R1/R2-Devicepaare im Zustand partitioned befinden.

-rbcv

Die Operation wird lediglich mit einem remote BCV durchgeführt.

-R1

Die Operation wird lediglich mit einem R1 Device durchgeführt.

-R2

Die Operation wird lediglich mit einem R2 Device durchgeführt.

-RDFG

Begrenzt die Anwendung der Operation auf Devices der spezifizierten RDF Remote Adapter-Gruppe.

-resv

Es werden alle Devices des Storage Arrays ausgegeben, die auf dem Server, der die Operation startet, sichtbar sind und eine SCSI-Reservierung besitzen.

-sid

Eindeutige Symmetrix-Identifikationsnummer, nummer, die das Storage Array identifiziert.

-split

Überprüft, ob sich die R1/R2-Devicepaare im Zustand split befinden.

-suspended

Überprüft, ob sich die R1/R2-Devicepaare im Zustand suspended befinden.

-susp-offline

Überprüft, ob sich die R1/R2-Devicepaare im Zustand suspended befinden und die Links über die Remote Link Directors im Zustand offline sind.

-synchronized

Überprüft, ob sich die R1/R2-Devicepaare im Zustand synchronized befinden.

-syncinprog

Überprüft, ob sich die R1/R2-Devicepaare im Zustand synch-in-prog befinden.

-until

Die Update-Operation als Vorbereitung des Failback wird abgebrochen, sobald die Anzahl der Invalid Tracks dem angegebenen Wert entsprechen.

-updated

Überprüft, ob sich die R1/R2-Devicepaare im Zustand updated befinden.

-updateinprog

Überprüft, ob sich die R1/R2-Devicepaare im Zustand upd-in-prog befinden.

-valid

Überprüft, ob sich die R1/R2-Devicepaare im Zustand synchronized befinden.

-v


Serien-

405


6.2.4

Status-Meldungen von SymCLIKommandos

Nach Ausführung eines jeglichen SymCLI-Kommandos liefert die Software einen Statuscode an das ausrufende Programm zurück. Diese Statusmeldungen sollten zur Steuerung automatisierter SymCLI-Operationen jeweils abgefragt und mit einer entsprechenden Reaktion versehen werden. Return Meldungen und Bedeutung Codes 0

SUCCESSFUL Termination Operation wurde erfolgreich ausgeführt.

1

CLI-C-FAIL Das Kommando konnte nicht abgesetzt werden, das Kommando bzw. die Umgebung muss überprüft werden. Die Ausführung des Kommandos wird abgebrochen.

2

CLI-DB-FILE-IS-LOCKED Die Datenbankdatei ( /var/symapi/db/symapi-db.bin ) ist von einem anderen Benutzer gesperrt. Die Sperre kann mit dem Kommando: symcfg -lock list überprüft werden.

3

CLI-DB-IS-LOCKED Das Kommando konnte nicht ausgeführt werden, da das gesamte Storage Array gelockt ist. Um weitere SymCLI-Kommandos auf das System absetzen zu können, muss zuerst diese Sperre gelöst werden.

4

CLI-C-NOT-ALL-SYNCHRONIZED Es sind noch nicht alle (Standard/BCV/R2) Devices synchronisiert.

5

CLI-C-NONE-SYNCHRONIZED Es ist noch kein Device synchronisiert!

6

CLI-C-NOT-ALL-UPDATED Der Update ist noch nicht für alle Devices komplett erfolgt.

7

CLI-C-NONE-UPDATED Der Update ist noch nicht für alle Devices komplett erfolgt.

8

CLI-C-NOT-ALL-PINGED Es konnten nicht alle angeschlossenen Storage Arrays erreicht werden.

9

CLI-C-NONE-PINGED Es konnten keines der angeschlossenen Storage Arrays erreicht werden.

10

CLI-C-NOT-ALL-SYNCHED Es befinden sich noch nicht alle Devices im »Synchronized«-Status.

Tab. 6.4: SymCLI – Returncodes und Bedeutung

406


Return Meldungen und Bedeutung Codes 11

CLI-C-NONE-SYNCHED Es befindet sich noch kein Device im »Synchronized«-Status!

12

CLI-C-NOT-ALL-RESTORED Es sind noch nicht alle Devices von BCV oder R2 Device wiederhergestellt.

13

CLI-C-NONE-RESTORED Es ist noch kein Device von BCV oder R2 Device wiederhergestellt.

14

CLI-C-NOT-ALL-VALID Es sind nicht alle Devices im erforderlichen R1/R2-Status. Mit dem Kommando symrdf -g DgName query kann der Devicestatus überprüft werden.

15

CLI-C-NONE-VALID Kein Device ist im erforderlichen R1/R2-Status. Mit dem Kommando symrdf -g DgName query kann der Devicestatus überprüft werden.

16

CLI-C-SYM-NOT-ALL-LOCKED Es haben noch nicht alle Symmetrix-Storage Arrays eine exklusive Symmetrix-Sperre. Mit dem Kommando: symcfg -lock list kann der Zustand der Sperren der beteiligten Storage Arrays überprüft werden.

17

CLI-C-SYM-NONE-LOCKED Es ist kein Symmetrix-Storage Array mit einer exklusiven SymmetrixSperre versehen. Mit dem Kommando: symcfg -lock list kann der Zustand der Sperren der beteiligten Storage Arrays überprüft werden.

18

CLI-C-ALREADY-IN-STATE Die Devices oder Device-Gruppen befinden sich bereits im gewünschten R1/R2-Status.

19

CLI-C-GK-IS-LOCKED Alle Gatekeeper Devices zur Kommunikation mit den Storage Arrays werden gerade von einem anderen Benutzer verwendet.

20

CLI-C-WP-TRACKS-IN-CACHE Es gibt Write-Pending I/O für remote Mirror Devices im Cache. Dies bedeutet, dass die Remote Link Director-Verbindungen nicht eine ausreichende Bandbreite zur Verfügung stellen können, um die remote Mirror Devices in dem gewählten Betriebsmodus synchron zu halten.

21

CLI-C-NEED-MERGE-TO-RESUME Vor einem Aktivieren der Links über die Remote Link Directors müssen die Track Tables der Storage Arrays erst synchronisiert werden.

Tab. 6.4: SymCLI – Returncodes und Bedeutung (Forts.)

407



CLI-C-NEED-FORCE-TO-PROCEED Die -force-Option ist erforderlich um die gewünschte Operation auszuführen.

23

CLI-C-NEED-SYMFORCE-TO-PROCEED Die -symforce-Option ist erforderlich um die gewünschte Operation auszuführen.

24

CLI-C-NOT-IN-SYNC Die Konfiguration im Symmetrix Storage Array stimmt nicht mit der symapi-Datenbank überein. Mit symcfg discover kann die Übereinstimmung wiederhergestellt werden.

25

CLI-C-NOT-ALL-SPLIT Es sind nicht alle Devices im Split BCV-Status. Mit symmir -g DgName query kann der Status überprüft werden.

26

CLI-C-NONE-SPLIT Es ist kein Device im Split BCV-Status. Mit symmir -g DgName query kann der Status überprüft werden.

27

CLI-C-NOT-ALL-SYNCINPROG Es sind nicht alle Devices im SYNCINPROG BCV-Status. Mit symmir -g DgName query kann der Status überprüft werden.

28

CLI-C-NONE-SYNCINPROG Kein Device ist im SYNCINPROG BCV-Status. Mit symmir -g DgName query kann der Status überprüft werden.

29

CLI-C-NOT-ALL-RESTINPROG Es sind nicht alle Devices im RESTINPROG BCV-Status. Mit symmir -g DgName query kann der Status überprüft werden.

30

CLI-C-NONE-RESTINPROG Kein Device ist im RESTINPROG BCV-Status. Mit symmir -g DgName query kann der Status überprüft werden.

31

CLI-C-NOT-ALL-SUSPENDED Es sind nicht alle Devices im SUSPENDED R1/R2-Status. Mit symrdf -g DgName query kann der Status überprüft werden.

32

CLI-C-NONE-SUSPENDED Kein Device ist im SUSPENDED R1/R2-Status. Mit symrdf -g DgName query kann der Status überprüft werden.

33

CLI-C-NOT-ALL-FAILED-OVER Es sind nicht alle Devices im FAILED-OVER R1/R2-Status. Mit symrdf -g DgName query kann der Status überprüft werden.

34

CLI-C-NONE-FAILED-OVER Kein Device ist im FAILED-OVER R1/R2-Status. Mit symrdf -g DgName query kann der Status überprüft werden.

Tab. 6.4: SymCLI – Returncodes und Bedeutung (Forts.)

408



CLI-C-NOT-ALL-UPDATEINPROG Es sind nicht alle Devices im UPDATEINPROG R1/R2-Status. Mit symrdf -g DgName query kann der Status überprüft werden.

36

CLI-C-NONE-UPDATEINPROG Kein Device ist im UPDATEINPROG R1/R2-Status. Mit symrdf -g DgName query kann der Status überprüft werden.

37

CLI-C-NOT-ALL-PARTITIONED Es sind nicht alle Devices im PARTITIONED R1/R2-Status. Mit symrdf -g DgName query kann der Status überprüft werden.

38

CLI-C-NONE-PARTITIONED Kein Device ist im PARTITIONED R1/R2-Status. Mit symrdf -g DgName query kann der Status überprüft werden.

39

CLI-C-NOT-ALL-ENABLED Es sind nicht alle Devices im ENABLED R1/R2-Status. Mit symrdf -g DgName query kann der Status überprüft werden.

40

CLI-C-NONE-ENABLED Kein Device ist im ENABLED R1/R2-Status. Mit symrdf -g DgName query kann der Status überprüft werden.

41

CLI-C-NOT-ALL-SYNCHRONIZED-AND-ENABLED Es sind nicht alle Devices im SYNCHRONIZED-AND-ENABLED R1/R2Status. Mit symrdf -g DgName query kann der Status überprüft werden.

42

CLI-C-NONE-SYNCHRONIZED-AND-ENABLED Kein Device ist im SYNCHRONIZED-AND-ENABLED R1/R2-Status. Mit symrdf -g DgName query kann der Status überprüft werden.

43

CLI-C-NOT-ALL-SUSP-AND-ENABLED Es sind nicht alle Devices im SUSP-AND-ENABLED R1/R2-Status. Mit symrdf -g DgName query kann der Status überprüft werden.

44

CLI-C-NONE-SUSP-AND-ENABLED Kein Device ist im SUSP-AND-ENABLED R1/R2-Status. Mit symrdf -g DgName query kann der Status überprüft werden.

45

CLI-C-NOT-ALL-SUSP-AND-OFFLINE Es sind nicht alle Devices im SUSP-AND-OFFLINE R1/R2-Status. Mit symrdf -g DgName query kann der Status überprüft werden.

46

CLI-C-NONE-SUSP-AND-OFFLINE Kein Device ist im SUSP-AND-OFFLINE R1/R2-Status. Mit symrdf -g DgName query kann der Status überprüft werden.

Sonsti- Neuer oder unbekannter Fehler ger Tab. 6.4: SymCLI – Returncodes und Bedeutung (Forts.)

409

7

SAN und NAS – Unterstützte File-Systeme

Nachdem mit den Softwarekomponenten die Devices der Storage Arrays in Device-Gruppen zusammengefasst sowie Business Continuity und Disaster Recovery eingerichtet wurden, können die Devices nun für die Produktion verwendet werden. In heutigen SAN- und NAS-Umgebungen können dabei innerhalb des SAN auf jedem der eingebundenen Storage Arrays heterogene Dateisystem-Umgebungen verwendet und unterstützt werden. Die am häufigsten eingesetzten Filesysteme sowie deren Administration sollen in diesem Kapitel skizziert werden.

7.1

Disk/Device-Verwaltung unter MS Windows NT

7.1.1

Grundbegriffe für die DiskAdministration – Partitions

Die physikalischen Platten in einem Storage Array werden in Splits logischer Volumes untergliedert. Ein solcher Split einer physikalischen Platte kann unter Windows NT in eine oder mehrere Partitions aufgegliedert werden. Das Symmetrix Device des EMC2 Storage Arrays präsentiert sich unter Windows NT also als physikalische Platte, die partitioniert werden kann. Eine Partition kann nun ein Teil des Devices oder das komplette Device sein. Unter Windows NT können maximal vier bootfähige Primary Partitions und eine Extended Partition existieren. Ein Windows NT Laufwerk wird wie folgt eingerichtet: 왘 Beim Booten von Windows NT wird ein Hardware-Scan über alle SCSI-

Laufwerke durchgeführt. Dieser entdeckt sämtliche Devices des Storage Arrays, die über Host-Bus-Adapter des NT-Systems sichtbar sind. 왘 Aufruf des Disk Administrator. Dabei wird bei allen Laufwerken versucht,

die Signatur (Label des Laufwerks) zu lesen. Falls keine Signatur vorhanden ist erfolgt eine Bestätigungsabfrage, ob eine Signatur geschrieben werden soll. Wird eine Signatur geschrieben, so erfolgt ein Eintrag in die Registry. Ohne Signatur wird das Laufwerk nicht in die Registry eingetragen.

411

7 SAN und NAS – Unterstützte File-Systeme Abbildung 7.1: Partition und Split Mapping Symmetrix Device

Symmetrix Device

Physikalische Platte wird aufgeteilt in

Symmetrix Device

Symmetrix Device

Partitions

Teile einer Platte, die als Einheit adressierbar sind

Primary Partition

Extended Partition

Unter NT maximal 4 bootfähige Primary Partitions

Unter NT maximal eine nicht bootfähige Extended Partition, die in logische Laufwerke aufgeteilt werden kann

왘 Einrichten einer Partition. Dabei kann ein Laufwerksbuchstabe zugeord-

net werden. Wird der Partition ein Laufwerksbuchstabe zugeordnet, so wird dieser ebenfalls in die Registry eingetragen. 왘 Formatieren der Partition mit FAT oder NTFS Filesystem. Danach ist das

Laufwerk unter Windows NT verwendbar.

7.1.2

Grundbegriffe für die DiskAdministration: Volume Set und Stripe Set

Da unter Windows NT nur eine begrenzte Anzahl von Laufwerksbuchstaben verwendbar ist können mehrere Partitions zu einem Volume Set zusammengefasst werden, das dann über einen Laufwerknamen angesprochen werden kann. Dieses Volume Set implementiert das Konzept der Meta Devices des Storage Arrays unter Windows NT. Während das Volume Set lediglich die Erweiterung eines Filesystems über die Grenze einer physikalischen Platte hinaus beabsichtigt ist ein Stripe Set ein Konstrukt zur Optimierung der I/O-Last, indem bewusst Partitions unterschiedlicher physikalischer Devices gruppiert werden, um eine Verteilung des I/Os auf mehrere Schreib-/Leseköpfe zu realisieren.

412

Dateisysteme unter WIN NT

F: Partition A1

Partition B1

Partition C1

Partition D1

Partition A1

Partition A2

Partition B2

Partition C2

Partition D2

Partition B2

Partition A3

Partition B3

Partition C3

Partition D3

Partition C3

Partition A4

Partition B4

Partition C4

Partition D4

Partition D4

Partition A1

Partition B1

Partition C1

Partition D1

Partition A2

Partition B2

Partition C2

Partition D2

Partition A3

Partition B3

Partition C3

Partition D3

Partition A4

Partition B4

Partition C4

Partition D4

Partition A1

Partition B1

Partition C3

Partition D4

F:

Das Volume Set besteht aus A1, B2, C3 und D4. Eine Partition könnte eine komplette Platte sein.

Abbildung 7.2: Volume Set und Stripe Set

Das Stripe Set besteht aus A1, B2, C3 und D4.

Eine Volume Set wird wie folgt angelegt: 왘 Aufruf des Disk Administrator zum Einrichten des Volume Sets. 왘 Auswahl der Aktion Einrichten eines Volume Sets, dabei Auswählen freier

Partitionen, die zum Volume Set zusammengefasst werden, Anwählen des Create Volume Set Buttons, danach Anwählen des Commit Button. Dadurch wird das Volume Set in die Registry eingetragen und wird nach einem Reboot des Systems verfügbar. 왘 Formatieren des Volume Sets mit FAT oder NTFS. 왘 Der Laufwerksbuchstabe und die Signaturen der einzelnen Devices des

Volume Sets stehen in der Registry.

7.2


7.2.1

Die Symmetrix Manager Control Utility

Unter Windows NT werden die Informationen über die Dateisysteme an zwei Stellen gehalten: 왘 In der Registry werden unter dem Laufwerksbuchstaben die Signatur,

das auf dem Laufwerk befindliche Dateisystem sowie die Mitglieder eines Volume- oder Stripe-Sets gehalten.

413

7 SAN und NAS – Unterstützte File-Systeme 왘 Auf dem Laufwerk werden nach einem erfolgten Reboot und nach dem

Formatieren des Laufwerks in der Signatur Informationen über die Partitions sowie die Dateisysteme gehalten. Windows NT bietet als Administrationstool zum Schreiben von Signaturen und zur Zuweisung und Wegnahme von Laufwerksbuchstaben lediglich den Disk-Administrator an. Der Disk-Administrator ist jedoch ein manuelles Tool und kann nicht in einem Script verwendet werden. Er ist lediglich eingeschränkt über NT-Tasks zur Automatisierung dieser Disk-Administrationstätigkeiten einzusetzen. Aus diesem Grunde bietet EMC2 das symntctlKommando an, mit dem Administrationstätigkeiten geskriptet und automatisiert werden können. symntctl delete delete export flush import list list list

–pd diskN [-noprompt][-force] –sig signature [-noprompt][-force] NT-drive-letter[:] –file filename NT-drive-letter[:] [NT-drive-letter[:]] –file filename [-force] [NT-drive-letter[:]][-brief] || [-physical] || [-registry] || [-full] [-pd diskN][-brief] || [physical] || [-registry] || [-full] [-sig signature][-brief] || [-physical] || [-registry] || [-full]

symntctl mount NT-drive-letter[:] –pd diskN [-p partitionN] mount NT-drive-letter[:] –sig signature [-p partitionN] partition –pd diskN [-size X] –type filesystemtype settimeout N signature –pd diskN –save signature –pd diskN -restore signature –pd diskN –sig signature [-noregupdate] signature –pd diskN –erase [-noregupdate] umount NT-drive-letter[:][-fs] verify

Dabei bewirken die Operationen des symntctl-Kommandos folgende Ergebnisse:

414

delete

Konsistentes Entfernen einer Disk-Information aus der Registry. Dabei kann die Platte über das Laufwerk oder die Signatur identifiziert werden.

export

Exportiert einen Registry-Eintrag eines Volume Sets aus der Registry in eine Datei, die zur Administration von Volume Sets auf anderen Servern und zur Dokumentation verwendet werden kann.

flush

Erzwingt das Rückschreiben sämtlicher I/Os für das bezeichnete Device aus dem Cache des NT-Servers auf


Platte. Dabei wird natürlich jeder der schreibenden I/Os als complete gemeldet, sobald er im Cache des Storage Arrays platziert wurde – die Daten befinden sich erst nach einem Destage des Storage Array Caches auf der physikalischen Platte im Storage Array. import

Importiert einen Registry-Eintrag eines Volume Sets aus einer Datei in die Registry. Volume-Set-Definitionen anderer NT-Server können so einfach repliziert werden.

list

Anzeige der physikalischen Konfiguration und der Registryeinträge für die mit Namen, Laufwerksbezeichnung oder Signatur bezeichneten Disks, Stripe Sets oder Volume Sets.

mount

Mount eines Netzwerk-Laufwerks. Beim Mount wird der Platte ein Laufwerkbuchstabe zugewiesen und es erfolgt ein Eintrag in die Registry.

partition

Erstellt eine Primary Partition und formatiert diese mit dem angegebenen Filesystemtyp.

settimeout

Angabe einer maximalen Dauer einer symntctl Session. Mit dieser Operation soll vermieden werden, dass eine fehlerhaft oder nicht beendete symntctl Session die Registry des NT-Servers blockiert.

signature -save

Sichern der bezeichneten Signatur.

signature -restore Wiederherstellen der bezeichneten Signatur. signature -sig

Schreiben der bezeichneten neuen Signatur auf eine Disk.

signature –erase

Löschen der bezeichneten Signatur.

umount

Abhängen eines Netzlaufwerks. Dabei wird der Laufwerksbuchstabe aus der Registry entfernt und zuvor sämtliche I/Os für dieses Laufwerk aus dem ServerCache auf das Storage Array zurückgeschrieben, sodass das Laufwerk in einem konistenten Zustand aus der Verzeichnisstruktur entfernt wird.

verify

Die physikalische Konfiguration der Disks, die über einen SCSI-Scan auf den Host-Bus-Adaptern gesehen werden, wird mit den Einträgen der Disks in der Registry verglichen.

Die Optionen des symntctl-Kommandos lauten: -brief

Kurzversion der Registrydaten und der physikalischen Konfiguration wird angezeigt.

-erase

Löschen einer Signatur.

-file

Name der Datei, in die exportiert oder aus der importiert werden soll.

415

7 SAN und NAS – Unterstützte File-Systeme

-force

Erzwingt das Importieren der Registry-Informationen auf dem NT-Server, von dem sie erzeugt wurden, auch wenn kleine Abweichungen der Konfiguration vorhanden sind.

-fs

Filesystem.

-full

Detaillierte Langversion der Registrydaten und der physikalischen Konfiguration wird angezeigt.

-p

Partition.

-pd

Bezeichnung des physikalischen Devices

-physical

Es werden keine Registry-Einträge sondern nur Informationen über die physikalische Konfiguration ausgegeben.

-registry

Es werden lediglich Registry-Einträge und keine Informationen über die physikalische Konfiguration ausgegeben.

-restore

Eine gesicherte Signatur wird wiederhergestellt.

-save

Sichern der angegebenen Signatur.

-sig

Signatur.

-size

Größe der angegebenen Partition in MB.

7.2.2

Dateisystemvorbereitungen in einer Cluster-Umgebung

Unter Windows NT können ebenfalls Zwei-Knoten-Cluster-Konfigurationen mit dynamischem Path Failover konfiguriert werden. Dabei sind vor einer bei Clustern üblichen Powerpath-Installation jedoch einige Vorbereitungen auf den beteiligten NT-Cluster-Systemen zu treffen. Folgende Überlegungen sind zu berücksichtigen: 왘 Das Kommando symntctl list liefert Informationen über Volume Sets,

Stripe Sets und einzelne Devices (mit deren Signaturen). 왘 Bei Verwendung der Solution Enabler Erweiterung TimeFinder (symmir-

Kommando, vgl. voriges Kapitel) werden die Devices physikalisch Track für Track von Standard- auf BCV Devices kopiert. Dies bedeutet, dass auch die Signaturen kopiert werden. Daher müssen auf Server2 die gleichen Signaturen der Devices wie auf Server1 verwendet werden. 왘 Die Signaturen der Devices für Server2 können problemlos durch ein es-

tablish der Devices des Servers2 mithilfe des symmir- (TimeFinder) oder des symrdf- (Disaster Recovery via SRDF) Kommandos von den mit den Signaturen versehenen Devices des Servers1 erzeugt werden.

416


Aufruf des Disk Administrators, um Partitions, Volume Sets und Stripe Sets einzurichten, zu formatieren und Laufwerksbuchstaben zuzuordnen. Danach REBOOT

Abbildung 7.3: Vorbereitung für den Einsatz von Storage Software unter Windows NT

Server1 Mit dem Werkzeug symntctl list Informationen über die Disk-Konfiguration von Server1 sammeln, bspw. Signaturen und Mitglieder der Volume- und Stripe Sets. Laufwerke mit TimeFinder oder SRDF synchronisieren, damit die Signaturen kopiert werden.

Server2

Alte Laufwerkseinträge aus der Registry löschen und REBOOT. Aufruf des Disk Administrators, um Partitions, Volume Sets und Stripe Sets einzurichten und Laufwerksbuchstaben zu zuweisen. Danach REBOOT

왘 Die FAT oder NTFS Filesystem Formate werden nur dann auf die Devices

geschrieben, wenn der Server nach dem symntctl oder Disk Administrator neu gebootet wird. 왘 Der ftdisk (fault-tolerant disk driver) muss aktiviert sein, damit mit Vo-

lume- und Stripe Sets gearbeitet werden kann. Dies kann im Geräteeintrag der Systemsteuerung und Windows NT überprüft werden. Bei der Überprüfung sollte beachtet werden, dass der Startparameter von ftdisk auf Boot stehen muss.

7.2.3

Dateisystemvorbereitung – Übertragung von Volume SetInformationen

Auch die Volume Set-Informationen in einer 2-Server Clusterumgebung können via TimeFinder übertragen werden. In der Registry sind Volume Set-Typ, Mitglieder-Laufwerke und deren Signatur sowie die Reihenfolge der Laufwerke im Volume Set gespeichert. Bei der Operation mit TimeFinder (symmir-Kommando) müssen die Volume Sets der Standard-Devices des Volume Sets und ihrer BCVs übereinstimmen. Die BCV-Laufwerke benötigen die selbe Signatur und die selbe Reihenfolge im Volume Set wie ihre Standard-Devices.

417

7 SAN und NAS – Unterstützte File-Systeme Abbildung 7.4: Varianten zur Übertragung von Volume Set-Informationen

S ta n d a rdLa u fwe rke S ig 1

S ig 2

S ig 3

S ig 4

BCVLa u fwe rke S ig 1

S ig 2

S ig 3

S ig 4

ftp regfile Server 2

Server 1

symntctl export n: -file regfile

symntctl import [n:] -file regfile

Mit dem symntctl export und import können die Volume Set-Beschreibungen aus der Registry des einen Servers auf den zweiten Server übertragen werden. Damit sind die Registry-Eintragungen auf beiden Servern gleich, es muss nur noch die tatsächliche Signatur auf die physikalischen Devices geschrieben werden. Die Signatur kann mit dem Kommando symntctl -signature -sig oder mit einem full establish der BCVs von ihren Standard-Devices durch TimeFinder auf die BCVs geschrieben werden. Existieren noch alte Einträge über die BCVs in der Registry, die von einer früheren Nutzung der BCVs an diesem Server herrühren, andere Signaturen enthalten, einem anderen Volume Set zugeordnet sind und/oder in diesem in einer anderen Reihenfolge genutzt wurden, dann müssen diese z.B. mit dem Kommando symntctl delete oder dem Disk Administrator gelöscht werden.

7.2.4

Dateisystemvorbereitungen bei einem Single Server

Die Dateisystemvorbereitungen auf einem Single Server für Volume- und Stripe Sets sind leicht unterschiedlich zu denen in einer Cluster-Umgebung. Zu beachten ist hierbei besonders, dass evtl. zu nutzende BCVs nicht formatiert werden dürfen. Auch die hier beschriebenen Vorbereitungen sind vor einer eventuellen Powerpath-Installation zu treffen.

418


Server 1

Aufruf des Disk Administrators, um Partitions, Volume Sets und Stripe Sets für StandardDevices und BCVs einzurichten, danach lediglich die Standard-Devices zu formatieren und ihnen Laufwerksbuchstaben zuzuordnen. Danach REBOOT

Abbildung 7.5: Dateisystemvorbereitungen für Single Host-Umgebungen

Sichern der Signaturen mit dem Werkzeug symntctl save

Sollen in der Single-Server-Umgebung mit TimeFinder Daten kopiert werden, so besitzen die BCVs zunächst keine Formatierung und keinen Laufwerksbuchstaben. Signatur und Laufwerksbuchstabenzuweisung müssen jedoch in die Registry eingetragen werden. Nach dem Kopieren der Daten vom Standard-Device befinder sich die Signatur auf dem Device. Diese muss dann vor der Zuweisung eines Laufwerksbuchstabens mit symntctl restore ins Registry übertragen werden, bevor mit dem Disk Administrator ein Laufwerksbuchstabe zugeordnet werden kann. Nach Zuordnung des Laufwerksbuchstabens kann nach einem Reboot das BCV wie sein Standard-Device verwendet werden.

7.2.5

Kopieren von Daten mit flexible Mirror oder remote Mirror im 2-Knoten-Cluster

Volume Sets oder Stripe Sets dürfen nicht mit dem Disk-Administrator restauriert werden, da sonst die Daten auf den Devices verloren gehen. Sollen nun BCVs zur Unterstützung konkurrierender Prozesse oder auch remote Mirrors zur Implementierung eines Disaster Recovery Clusters eingeführt werden, so ist auch im Katastrophenfall eine solche Restaurierung nicht notwendig, da sich die Daten inklusive der Volume Set- und Stripe SetInformationen auf dem flexible oder remote Mirror befinden. Abbildung 7.6 skizziert die Reihenfolge der Schritte, die zur Nutzung der flexible oder remote Mirrors zum Kopieren der Daten eingehalten werden muss.

419

7 SAN und NAS – Unterstützte File-Systeme Abbildung 7.6: Kopieren von Daten mithilfe von flexible oder remote Mirrors in einer DualServer-Umgebung

Server 1

Warten auf den Zustand „synchronized” Anwendungen stoppen Cache leeren Anwendungen starten

Server 2

Symmetrix Storage Array Establish starten 2

1

Anwendungen stoppen Laufwerksbuchstaben entfernen

3 Split durchführen 4

5

Laufwerksbuchstaben zuweisen, danach Anwendungen starten

Die Abbildung geht davon aus, dass die Daten bereits einmal von den Standard-Devices des Servers 1 auf flexible Mirror Devices (Server 1 und konkurrierender Prozess auf Server 2) oder remote Mirrors auf Server 2 synchronisiert wurden und dann von Server 1 getrennt wurden (vgl. Kapitel 6). Unabhängig davon, ob es sich um einen flexible oder remote Mirror handelt, laufen im Ausgangszustand die Anwendungen des Servers 2 auf den Mirror Devices, die sich aus Sicht des Servers 1 im Zustand split befinden. Für eine erneute Kopie der Daten des Servers 1 sind nun folgende Schritte einzuhalten. 1. Auf Server 2 müssen die Anwendungen gestoppt werden und der Laufwerksbuchstabe der Devices, Volume Sets oder Stripe Sets aus dem Registry entfernt werden. 2. Von Server 1 aus wird die Resynchronisation der Mirror Devices gestartet. Dieser establish erfolgt unabhängig davon, ob es sich um einen flexible Mirror (TimeFinder BCV mit dem Kommando symmir establish) oder um einen remote Mirror (SRDF R2 Device mit dem Kommando symrdf establish) handelt.1 3. Sobald der Device Status SYNCHRONIZED erreicht ist, müssen auf Server 1 die Anwendungen gestoppt werden und ein Buffer-Cache-Flush erfolgen. Der nachfolgende split der Mirror Devices (symmir split oder symrdf split) leert den Cache des Storage Arrays und gewährleistet den konsistenten Zustand der Daten auf den Mirror Devices.

1.

420

Zur Verwendung der TimeFinder- und SRDF-Kommandos vergleiche Kapitel sechs dieses Buches.


4. Die Anwendungen des Servers 1 können auf den Standard-Devices wieder gestartet werden. 5. Auf Server 2 werden den Devices mit symntctl restore wieder die Laufwerksbuchstaben zugewiesen. Danach können sie wieder zur Produktion des Servers 2 eingesetzt werden.

7.2.6

Restore von Daten mit flexible Mirror oder Disaster Recovery im 2-Knoten-Cluster

Standard-Devices, deren Daten mit flexible Mirrors oder remote Mirrors kopiert wurden, können von diesen Mirror Devices auch wiederhergestellt werden. Dazu sind folgende Schritte zu vollziehen. Abbildung 7.7: Wiederherstellung von Laufwerken im 2-Knoten-Cluster Server 1

Server 2


Anwendungen stoppen Laufwerksbuchstaben entfernen 2

1


Restore starten 3 Laufwerksbuchstaben zuweisen, danach Anwendungen starten

1. Seien die Standard-Devices auf Server 1 defekt und müssen von den getrennten flexible oder remote Mirrors, auf denen die Produktion des Servers 2 läuft, wiederhergestellt werden. Dazu müssen zunächst auf Server 2 die Anwendungen gestoppt und die Laufwerksbuchstaben der Devices, Volume Sets oder Stripe Sets aus dem Registry entfernt werden. Weiter müssen auch auf dem Server 1 – so das noch möglich ist – die Anwendungen gestoppt und die Laufwerksbuchstaben der Devices, Volume Sets oder Stripe Sets aus dem Registry entfernt werden. 2. Server 1 startet den Restore seiner Standard-Devices vom BCV flexible Mirror oder R2 remote Mirror (symmir restore oder symrdf restore).

421


3. Sobald der Restore der Standard-Devices angelaufen ist wird den Devices mit symntctl restore wieder der Laufwerksbuchstabe zugewiesen. Danach können sie wieder zur Produktion des Servers 1 eingesetzt werden. Soll der Zustand vor dem Restore wiederhergestellt werden, muss nun der Status RESTORED abgewartet werden und mit Punkt 3 des Abschnitts Kopieren von Daten mit flexible Mirror oder remote Mirror im 2-Knoten-Cluster fortgefahren werden. Dabei sei darauf hingewiesen, dass der Restore von remote oder flexible Mirror eine erhebliche Reduktion der ungeplanten Ausfallzeit im Vergleich zum Restore von Band-Datensicherungen bietet. Dies ist deshalb der Fall, da mit der Produktion auf Server 1 bereits direkt nach Anlaufen des Restore begonnen werden kann, also noch bevor alle Daten von den BCVs oder den R2 Devices auf die Standard-Devices rückkopiert wurden. Dabei ist darauf zu achten, dass – falls die BCVs oder die remote Mirrors nicht durch einen jeweiligen lokalen Mirror zusätzlich abgesichert sind – ein Verlust dieser Devices während der Restore-Operation nur durch eine vorhandene Bandsicherung behoben werden kann. Bei SRDF remote Mirrors muss zusätzlich beachtet werden, dass die Produktion mit einer reduzierten Bandbreite läuft, solange nicht alle Daten kopiert sind, also mit einem schlechteren Laufzeitverhalten zu rechnen ist.

7.2.7

Kopieren von Daten mit flexible Mirror oder remote Mirror bei einem Single Server

Abbildung 7.8 zeigt den Ablauf der Erzeugung von Datenkopien mithilfe von flexible Mirrors oder remote Mirrors im Single Server-Fall. Dabei lässt sich über den Sinn von remote Mirrors in einem Single Server-Fall trefflich streiten, dennoch bietet der remote Mirror auch hier eine weitere Ebene des Schutzes vor Verlust der Devices. Er sichert auch im Single Server-Umfeld vor dem Verlust des primären Storage Arrays. Bezüglich der Anwendungsschritte unterscheidet sich der Single Server-Fall jedoch kaum vom 2-Knoten Cluster. Die Abbildung geht davon aus, dass die Daten bereits einmal von den Standard-Devices des Servers 1 auf flexible Mirror Devices (ebenfalls Server 1, evtl. konkurrierender Prozess auf Server 1) oder remote Mirrors, die ebenfalls über Server 1 erreicht werden können, synchronisiert und dann von Server 1 getrennt wurden (vgl. Kapitel 6). Unabhängig davon, ob es sich um einen flexible oder remote Mirror handelt, laufen im Ausgangszustand konkurrierende Anwendungen des Servers 1 auf den Mirror Devices, die sich aus Sicht der Standard-Devices des Servers 1 im Zustand split befinden. Für eine erneute Kopie der Daten der Standard-Devices auf die flexible oder remote Mirrors sind nun folgende Schritte einzuhalten.

422


R2-Devices (flexible Mirrors) und evtl. BCVs

StandardDevices oder R1-Devices und BCVs

Server 1


Symmetrix Storage Array Warten auf den Zustand »synchronized« Anwendungen stoppen Cache leeren Anwendungen starten

Abbildung 7.8: Datenkopie mit flexible und remote Mirrors im Single Server-Umfeld

Establish starten 2

1



5

Re s to re d e r u rs p rü n g lic h e n S ig n a tu re n, Laufwerksbuchstaben zuweisen, danach Anwendungen starten

1. Auf Server 1 müssen die Anwendungen der konkurrierenden Prozesse gestoppt werden und der Laufwerksbuchstabe der Devices, Volume Sets oder Stripe Sets der Mirror Devices aus dem Registry entfernt werden. 2. Von Server 1 aus wird die Resynchronisation der Mirror Devices gestartet. Dieser establish erfolgt unabhängig davon, ob es sich um einen flexible Mirror (TimeFinder BCV mit dem Kommando symmir establish) oder um einen remote Mirror (SRDF R2 Device mit dem Kommando symrdf establish) handelt. 3. Sobald der Device Status SYNCHRONIZED erreicht ist, müssen auf Server 1 die Standard-Anwendungen auf den Standard-Devices gestoppt werden und ein Buffer-Cache-Flush erfolgen. Der nachfolgende split der Mirror Devices (symmir split oder symrdf split) leert den Cache des Storage Arrays und gewährleistet den konsistenten Zustand der Daten auf den Mirror Devices. 4. Die Standard-Anwendungen des Servers 1 können auf den StandardDevices wieder gestartet werden. 5. Auf Server 1 werden danach den Mirror Devices mit symntctl restore wieder die Laufwerksbuchstaben und die alte Signatur zugewiesen. Danach können sie wieder zur Produktion der konkurrierenden Prozesse des Servers 1 eingesetzt werden.

423


7.2.8

Restore von Daten von flexible Mirror oder remote Mirror bei einem Single Server

Auch im Single Server-Fall können Standard-Devices, deren Daten mit flexible Mirrors oder remote Mirrors kopiert wurden, von diesen Mirror Devices wiederhergestellt werden. Dazu sind folgende Schritte zu vollziehen. 1. Seien die Standard-Devices auf Server 1 defekt und müssen von den getrennten flexible oder remote Mirrors, auf denen die Produktion der konkurrienden Prozesse des Servers 1 läuft, wiederhergestellt werden. Dazu müssen zunächst auf Server 1 die Anwendungen der konkurrierenden Prozesse auf den Mirror Devices gestoppt und die Laufwerksbuchstaben der Mirror Devices, Volume Sets oder Stripe Sets aus dem Registry entfernt werden. Weiter müssen auf dem Server 1 – so das noch möglich ist – die primären Anwendungen gestoppt und die Laufwerksbuchstaben der Standard-Devices, Volume Sets oder Stripe Sets aus dem Registry entfernt werden. 2. Server 1 startet den Restore seiner Standard-Devices vom BCV flexible Mirror oder R2 remote Mirror (symmir restore oder symrdf restore). 3. Sobald der Restore der Standard-Devices angelaufen ist wird den Devices mit symntctl restore wieder der Laufwerksbuchstabe zugewiesen. Danach können sie wieder zur primären Produktion des Servers 1 eingesetzt werden. Soll der Zustand vor dem Restore wiederhergestellt werden, muss nun der Status RESTORED abgewartet werden und mit Punkt 3 des Abschnitts Kopieren von Daten mit flexible Mirror oder remote Mirror bei einem Single Server fortgefahren werden.

7.2.9

Probleme beim Softwareeinsatz im NT-Umfeld

Bei oben beschriebenen Vorbereitungen zum Einsatz von Softwareprodukten wie Powerpath, TimeFinder und SRDF im Windows NT-Umfeld unter FAT oder NTFS Filesystemen kommt es hin und wieder zu Problemen, deren Schwerpunkte wie folgt beschrieben werden können. Problembeschreibung: Größe und Geometrie einer Disk können bei zwei unterschiedlichen Serversystemen unterschiedlich sein, obwohl die unter den Disk Volumes liegenden Splitgrößen der Devices im Storage Array identisch sind.

424




Server 1

Abbildung 7.9: Wiederherstellung von Laufwerken im Single ServerUmfeld


Symmetrix Storage Array Anwendungen stoppen Laufwerksbuchstaben entfernen

1


2 Restore starten 3 La u fwe rks b u c h s ta b e n zu we is e n u n d Anwendungen starten

Ursache: 왘 Auf den Server-Systemen werden unterschiedliche NT-Versionen oder

Service Packs betrieben. 왘 In den Server-Systeme werden unterschiedliche Host-Bus-Adapter und/

oder Host-Bus-Adapter BIOS-Versionen oder Einstellungen verwendet. Problemlösung/Umgehung des Problems: 왘 Verwendung der gleichen Host-Bus-Adapter Modelle und BIOS-Ver-

sionen. 왘 Verwendung der gleichen Server Hardware mit gleichen BIOS-Ver-

sionen. 왘 Verwendung der gleichen NT-Versionen und Service Packs auf sämtli-

chen Systemen. 왘 Erstellung der Signaturen sämtlicher Laufwerke sämtlicher Server mit ei-

ner NT-Version.

425


7.3

Logical Volume-Manager HP-UX

7.3.1


Der Logical Volume-Manager (LVM) wurde unter HP-UX Release 9.0 auf den Serversystemen der HP 9000 und unter der Betriebssystemversion HP-UX 10.0 auf HP 9000 Workstations eingeführt. Der LVM kann für Filesysteme, Raw Data wie Datenbankfiles, Swap-Regionen oder Dump-Bereiche (Datensicherungsbereiche) eingesetzt werden. Diese Einsatzmöglichkeiten sind flexibler, als die in früheren Versionen von HP-UX verwendeten Partioning-Konzepte. Abbildung 7.10: HP-LVM – Physical Volumes, Logical Volumes und Volume Groups

pvcreate pv vgcreate, Symmetrix Device

PVRA

vgextend

Symmetrix Device

Physical Volume Symmetrix Device

dev/vg00

Symmetrix Device PVRA VGRA

PVRA VGRA

PVRA VGRA

Logical Volume Logical Extents

Physical

Extents

Im Folgenden werden grundlegende Begriffe des LVM und seiner Bestandteile erläutert. 왘 Physikalische Datenträger werden vom LVM zu so genannten Volume-

Gruppen zusammengefasst. Da als physikalische Datenträger unter HPUX wiederum die Devices – also Splits einer physikalischen Platte – eines Storage Arrays sichtbar sind, kann wiederum ein Matching der VolumeGruppen des LVM mit den Device-Gruppen des Storage Arrays empfohlen werden.

426

Logical Volume-Manager HP-UX 왘 Jede physikalische Platte, also jedes für den Server sichtbare Device, be-

sitzt eine eindeutige Identifikationsnummer (PVID). 왘 Jede physikalische Platte ist in physical partitions oder extends aufgeteilt,

die in der CTL-Mimik den Slices entsprechen. 왘 Logische Platten bestehen aus logical partitions, die den physischen

extends zugewiesen sind. 왘 Logische Platten werden für Filesysteme oder direkt für Anwendungen

in Packages verwendet. 왘 Auf jeder physikalischen Platte werden die Merkmale ihrer Volume-

Gruppe gesichert (VGDA), sodass die Zuordnung der Platte zu ihrer Volume-Gruppe stets gewährleistet ist. Für jede Volumegruppe muss in /dev ein Verzeichnis angelegt worden sein. Der Name kann beliebig sein, normalerweise wird jedoch vgnn verwendet. Mit dem Kommando pvcreate wird auf einer physikalischen Platte eine PVRA eingetragen. Diese enthält folgende Informationen: 왘 PV ID

Eindeutige Identifikationsnummer des physikalischen Volumes.

왘 VG ID

Eindeutige Identifikationsnummer der Volume-Gruppe, zu der das physikalische Volume gehört.

왘 PE Size

Größe des physikalischen extends.

왘 PV Size

Größe des physikalischen Volumes.

Mit den Kommandos vgcreate und vgextend wird auf jedem physikalischen Extend der Volume-Gruppe eine VGRA eingetragen. Diese enthält folgende Informationen: 왘 VG ID

Eindeutige Identifikationsnummer der Volume-Gruppe, zu der das physikalische Volume gehört.

왘 VG Size

Größe der Volume-Gruppe.

Unter etc/lvmtab werden Informationen über die Volume-Gruppen des Servers gehalten. Diese Datei kann nicht mit einem Editor gelesen und daher auch nicht geändert werden. Immer, wenn eine Volume-Gruppe geändert wird, wird auch der Inhalt von /etc/lvmtab auf den neuesten Stand gebracht. Falls diese Datei defekt ist, kann sie aus dem Inhalt der PVRAs und VGRAs auf den physikalischen Platten wiederhergestellt werden. Die Wiederherstellung wird mit dem Kommando vgscan angestoßen.

427


7.3.2

Anlegen einer Volume-Gruppe

Zum Anlegen einer Volume-Gruppe sind folgende Schritte erforderlich: 왘 Erstellen des Verzeichnisses /dev/vgnn für die Volumegruppe. Das Ver-

zeichnis wird mit dem normalen Unix-Kommando mkdir erzeugt. Das Verzeichnis kann auch einen anderen Namen als vgnn haben, es muss jedoch darauf geachtet werden, dass die Nummer der Volume-Gruppe nn eindeutig sein muss. 왘 Anlegen einer Datei mit dem Namen group im erstellten Verzeichnis /dev/

vgnn. Danach erfolgt eine direkte Zuweisung einer Filesystem Node-ID für die Volume-Gruppe mithilfe des Kommandos mknod group c 64 0xnn0000. Dabei stellt die 64 die Treibernummer für den Logical VolumeManager und nn die eindeutige Nummer der Volume-Gruppe dar. Die maximale Anzahl von Volume-Gruppen wird im Kernel-Konfigurationsparameter maxvgs festgelegt. Soll die Eindeutigkeit der Volume-Gruppen-Bezeichnung sichergestellt werden, so kann mit ls -l /dev/*/group nach bereits vorhandenen Volume-Gruppen gesucht werden. Abbildung 7.11: Verzeichnisstruktur für LVM VolumeGruppen

/

dev

vg00

0x000000

vg01

group Control File

0x000001

lvol1

0x000002

lvol2

Block Device Files

rlvol1

rlvol2

Character Device Files

0x010000

group

0x010001

lvol1

rlvol1

0x010002

lvol2

rlvol2

왘 Aufruf von vgcreate oder vgimport zur Neuerstellung oder zum Importie-

ren der Volume-Gruppe.

428


7.3.3

LVM-Volume-Gruppen Kommandos

Mit dem Kommando vgcreate werden LVM-Volume-Gruppen erzeugt. # vgcreate -s –e –p PE-Size VG PV [PV]

Dabei haben die Optionen und Argumente des Kommandos folgende Bedeutung: -s

Größe der Physical Extents. Die Größe der physical extents muss ein Vielfaches von zwei MB betragen und kann zwischen zwei und 256 MB liegen. Der voreingestellte Wert für die Größe eines physical extents liegt bei vier MB.

-e

Maximale Anzahl der Physical Extents. Werden bei der Erstellung einer Volume-Gruppe keine Angaben zu den maximalen Werten für die Anzahl der physical extents bei der Erstellung einer Volume-Gruppe gemacht, so werden die voreingestellten Werte verwendet. Es gibt danach keine Möglichkeit mehr, die Anzahl zu erhöhen. Der voreingestellte Wert für die maximale Anzahl der physical extents beträgt 1016.

-p

Maximale Anzahl der physical Volumes in der Gruppe. Werden bei der Erstellung einer Volume-Gruppe keine Angaben zu den maximalen Werten für die Anzahl der physical Volumes gemacht, so werden die voreingestellten Werte verwendet. Es gibt danach keine Möglichkeit mehr, die Anzahl zu erhöhen. Der voreingestellte Wert für die maximale Anzahl der physikalischen Laufwerke beträgt 16.

VG

Name der Volume-Gruppe.

PV

Bezeichnung des physikalischen Laufwerks.

-l

Maximale Anzahl der Logical Volumes, die auf physical extents der Volume-Gruppe gemapped werden dürfen.

Beispiel: # vgcreate /dev/vg10 /dev/dsk/c0t4d3

Der Erfolg des vgcreate kann mit den Kommandos # vgdisplay [-v] [VG] und # pvdisplay [-v] [PV]

erfolgen. Dabei bedeuten die verendeten Optionen und Argumente: -v

Anzeige ausführlicher Informationen über alle (ohne Argument) oder der spezifizierten Volume-Gruppe.

VG


Das Kommando pvdisplay kann erst dann verwendet werden, wenn die Platte einer Volume-Gruppe zugeordnet wurde.

429


Logical Volumes werden mit dem Kommando lvcreate wie folgt erzeugt: # lvcreate [-l extents|-L size][-n name][-p perm][-r y/n]-C [y/n] VG

Mit lvcreate werden die notwendigen device files erzeugt, also die Einträge im Devices-Verzeichnis wie beispielswiese /dev/vg10/lvol1 und /dev/vg10/ rlvol1 gemacht. Die Optionen und Argumente des lvcreate-Kommandos haben dabei folgende Bedeutung: -l extends

Maximale Anzahl der physical extends, auf die die logical extends der Volume-Gruppe gemapped werden dürfen.

-L size

Größe der Extends in MB.

-n name

Name des logical Volumes.

-p perm

Das Volume wird als permanentes erzeugt.

-r

Abfrage, ob es ein Read-Only Volume ist.

-C

Bestätigung für das Anlegen des Volumes wird verlangt.

VG


Mit folgender Vorgehensweise werden die logischen Datenträger bestimmten physikalischen Laufwerken zugewiesen. # lvcreate -l 0 vg01

Durch dieses Kommando wird die Verzeichnisstruktur /dev/vg01/lvol1 erzeugt. # lvextend -L 100 /dev/vg01/lvol1 /dev/dsk/c0t4d3

Durch dieses Kommando wird ein logical Volume in Größe von 100 MB erzeugt und als /dev/vg01/lvol1 auf das physikalische Device /dev/dsk/c0t4d3 gelegt. Überall dort, wo eine Platte verwendet werden kann, kann man auch Logical Volumes verwenden. Beispiele für die Anwendung logischer Volumes sind: 왘 Das Erzeugen eines Filesystems auf einem Logical Volume.

# newfs -F vxfs /dev/vg01/rlvol1 왘 Das Mounten eines Logical Volumes in eine Verzeichnisstruktur.

# mount -F /dev/vg01/lvol1 /database/sybase 왘 Das Verwenden eines Logical Volumes als Swap-Space.

# Swapon /dev/vg01/Swaplv

430


7.3.4


Folgende weiteren Befehle dienen der Erzeugung und Verwaltung von Volume-Gruppen und Volumes. Mit vgchange werden Änderungen an existierenden Volume-Gruppen vorgenommen. # vgchange -a y/n/r [-q y/n][-l][-p] VG

Dabei haben die Optionen und Argumente folgende Bedeutung: -a y

Aktivierung der Volume-Gruppe.

-a n

Deaktivierung der Volume-Gruppe.

-a r

Setzen der Volume-Gruppe auf read only.

-q

Verlassen von vgchange.

-l

Maximale Anzahl der Logical Volumes, die auf physical extends der Volume-Gruppe gemapped werden dürfen.

-p

Maximale Anzahl der physical Volumes in der Gruppe. Werden bei der Erstellung einer Volume-Gruppe keine Angaben zu den maximalen Werten für die Anzahl der physical Volumes gemacht, so werden die voreingestellten Werte verwendet. Es gibt danach keine Möglichkeit mehr, die Anzahl zu erhöhen. Der voreingestellte Wert für die maximale Anzahl der physikalischen Laufwerke beträgt 16.

VG


Das Kommando vgexport entfernt eine Volume-Gruppe aus der Verzeichnisstruktur des Servers. Um eine Volume-Gruppe exportieren zu können muss sie zuvor deaktiviert worden sein. # vgexport [-p][-v][-m file] VG

Dabei haben die Optionen und Argumente des Kommandos folgende Bedeutung: -p

Erlaubt das Spezifizieren von physikalischen Laufwerken, die exportiert werden sollen.

-v

Erlaubt das Spezifizieren von logischen Laufwerken, die exportiert werden sollen.

-m file

Angabe eines Mapfile, in den die Volume-Gruppen-Informationen für einen späteren Import der Volume-Gruppe eingetragen werden.

VG


Das Kommando vgimport erstellt eine Volume-Gruppe in derselben Weise wie vgcreate, d.h. auch hier müssen ein /dev/vgxx Verzeichnis und eine group-Datei bereits existieren. Der Name der Volume-Gruppe muss nicht der selbe sein wie der der Volume-Gruppe, die importiert wird. Wird eine Map-

431


datei (-m Option beim vgexport-Kommando) verwendet, so werden die Logical Volumes mit ihren im Mapfile enthaltenen Namen eingelesen, ansonsten werden vom System aufsteigende Nummern als Name vergeben (lvol0, lvol1...). Beim vgimport müssen alle physikalischen Platten angegeben werden, da es keinen dem vgextend vergleichbaren Befehl gibt. Wird eine physikalische Platte vergessen, so kann sie später nicht mehr in die Volume-Gruppe eingefügt werden. In diesem Falle müsste ein vgexport mit nachfolgendem vgimport erfolgen, bei dem die fehlende physikalische Platte explizit angegeben wird. # vgimport [-p][-v][-m file]

Dabei haben die Optionen und Argumente des Kommandos folgende Bedeutung: -p

Erlaubt das Spezifizieren von physikalischen Laufwerken, die exportiert werden sollen.

-v

Erlaubt das Spezifizieren von logischen Laufwerken, die exportiert werden sollen.

-m file

Angabe eines Mapfile, aus dem die Volume-Gruppen-Informationen für den Import der Volume-Gruppe ausgelesen werden.

VG


Das Kommando # vgchgid PV

ändert die Volume Group ID des angegebenen physical Volumes.

7.3.5

Backup von LVM-Datenträgern

Der Logical Volume-Manager bietet mit dem vgcfgbackup und vgcfgrestore zwei Tools an, mit denen Volume-Gruppen gesichert und wiederhergestellt werden können. Dabei ist zu berücksichtigen, dass ein normaler Backup meistens auf Dateiebene arbeitet und dabei die auf dem physikalischen Device eingetragenen PVRA und VGRA nicht mitsichert. # vgcfgbackup

[-u] [-f file] VG

sichert die LVM-Strukturen in /etc/lvmconf/vgnn.conf. # vgcfgrestore [-n VG | -f file] [-o PV] PV

schreibt die LVM-Strukturen wieder auf die Platte.

432


7.3.6

Multipathing unter LVM

Auch Multipathing, d.h. Adressierung ein und derselben Platte über zwei physikalische Adressen, wird vom LVM unterstützt. Mit dem Kommando pvcreate wird dabei lediglich der primäre Pfad zur Platte eingerichtet. Beim vgcreate für die Volume-Gruppe müssen dann beide Pfade angegeben werden. Der LVM erkennt dann, dass eine Platte über zwei Pfade angeschlossen ist. pvcreate pv

vgcreate

PVRA

PVRA

Abbildung 7.12: Multipathing beim LVM

F C H B A

HP-Server F C H B A

Secondary Link

Primary Link /dev/rdsk/c1t3d5

/dev/rdsk/c1t3d5

/dev/rdsk/c4t1d4

PVRA /dev/rdsk/c4t1d4

Im Ausdruck, der durch das Kommando vgdisplay erzeugt wird, sind die alternate links zur mit pvcreate angelegten Platte angezeigt.

7.3.7

Striping unter LVM

Unter Striping versteht man die Verteilung eines Logical Volumes über verschiedene physikalische Platten. Die Vorteile dieser Verteilung sind dabei: 왘 Der Datenzugriff ist auf mehrere Laufwerke verteilt. Dies führt dazu,

dass idealerweise eine bessere Auslastung der Disk Directors und des Caches erreicht wird, da die Anzahl der physikalischen I/Os evtl. über mehrere Disk Directors, definitiv jedoch über mehrere physikalische Laufwerke verteilt und somit die Positionierungsbewegungen der Schreib-/Leseköpfe distanzverringert und somit schneller durchgeführt werden können.

433

7 SAN und NAS – Unterstützte File-Systeme 왘 Die Verteilung der I/O-Last auf mehrere Channel Directors. Dieser Vor-

teil kommt zusätzlich zum zuvor genannten hinzu, wenn für das Striping die Pfade einer Multipathing-Konfiguration genutzt werden. Nachteile des Stripings sind eindeutig darin zu sehen, dass 왘 Ein Hardwarefehler auf einer physikalischen Platte dazu führen kann,

dass Daten unterschiedlicher Anwendungen von diesem Fehler betroffen sind. Alle Anwendungen, die auf einem von einem Fehler betroffenen physikalischen Laufwerk einen Stripe liegen haben, werden von den durch den Fehler erzeugten Auswirkungen betroffen. Bei einer anwendungsreinen Platte, auf der ohne Striping lediglich Daten dieser Applikation liegen, würde allein diese Applikation vom Fehler betroffen. 왘 Sämtliche Dateien, von denen ein auch nur geringer Teil auf einem Stripe

des betroffenen physikalischen Laufwerks gelegen haben, wiederhergestellt werden müssen. 왘 Eine zusätzliche Ebene architekturaler und administrativer Komplexität

eingeführt wird. 왘 Die Anzahl der physikalischen I/Os steigt. Jeder I/O-Request wird über

den Cache des Storage Arrays auf mehrere Devices verteilt, über die das Volume gestriped wurde. Sämtliche bisher betrachteten Destaging Operationen der Disk-Adapter werden je Device durrchgeführt, auf dem ein Stripe liegt. Striping wird unter LVM mit dem Kommando lvcreate eingerichtet. # lvcreate

-i stripes -I stripe-size [-l|L space][-n lv-name] VG

Dabei haben die Optionen und Argumente des Kommandos folgende Bedeutung: -i stripes

Anzahl der Laufwerke, über die gestriped werden soll.

-I stripe-size Größe des einzelnen Stripes in KB (erlaubte Werte betra-

gen: 4,8,16,32 oder 64 KB). -l space

Maximale Anzahl der physical extends, auf die die logical extends der Volume-Gruppe gemapped werden dürfen.

-L space

Größe der Extends in MB.

-n lv-name

Name des logical Volumes, über das gestriped werden soll.

VG


Beispiele für das lvcreate-Kommando sind: # lvcreate -i 3 -I 8 -L 32 -n lvstripe /dev/vg01

Erstellt auf dem logical Volume lvstripe für die Volume-Gruppe /dev/vg01 einen Stripe über drei Laufwerke mit einer Stripe-Größe von je acht KB. Das gesamte Extend ist 32 MB groß.

434


# lvcreate -i 2 -I 8 -n newstripe /dev/vg01

Erstellt auf dem logical Volume newstripe für die Volume-Gruppe /dev/vg01 einen Stripe über zwei Laufwerke mit einer Stripe-Größe von je acht KB. # lvextend -L 24 /dev/vg01/newstripe /dev/dsk/c0t3d0 /dev/dsk/c0t4d0

Auf die Laufwerke /dev/dsk/c0t3d0 und /dev/dsk/c0t4d0 werden die Stripes von newstripe mit einer Extend-Größe von je 24 MB abgelegt.

7.3.8

Dateisysteme und flexible/remote mirrors unter HP-UX

Unter HP-UX und dem Logical Volume-Manager kann das Konzept der flexible Mirrors wie beschrieben umgesetzt und realisiert werden. Auch hier können BCV Devices (EMC2) für konkurrierende Prozesse genutzt werden.

7.3.8.1

LVM und flexible Mirrors mit unterschiedlichen Hosts

Bei der Nutzung der flexible Mirrors für einen konkurrierenden Prozess auf einem anderem Host als dem, von dem die Standard-Devices verwendet werden, müssen keinerlei Besonderheiten beachtet werden.

HP-Server 1

F C H B A

F C H B A

HP-Server 2 RW-Enabled

Abbildung 7.13: HP-UX, LVM und flexible Mirrors in einer Multiple HostUmgebung

F C H B A

F C H B A

RW-Enabled

PVRA VGRA

PVRA VGRA

Standard-Device

Flexible Mirror Device

435

7 SAN und NAS – Unterstützte File-Systeme 왘 Werden Standard- und BCV-Datenträger mit symmir split voneinander

getrennt, so kann ein zweiter Server (HP Server 2) das BCV-Volume einfach durch Importieren der Daten verwenden. Beim Importieren einer Volume-Gruppe auf flexible Mirror durch den HP Server 2 kann dieser Volume-Gruppe der gleiche Name oder auch ein anderer Name zugewiesen werden, als ihn die Volume-Gruppe auf den Standard-Devices besitzt. Dennoch werden natürlich durch die Verwendung des TimeFinder symmir-Kommandos auch die PVRA und die VGRA der Laufwerke auf das BCV geschrieben. 왘 Wurde auf dem HP Server 1 eine Mapdatei erzeugt, so kann diese auf

dem HP Server 2 beim Importieren der Volume-Gruppe verwendet werden. Die logischen Volumes bekommen dann die gleichen Namen wie auf HP Server 1. Ohne Verwendung einer Mapdatei werden die logischen Volumes bei 0 beginnend aufsteigend nummeriert (lvol0, lvol1 usw.). 왘 Es gibt keinen Konflikt wegen der gleichen Inhalte in den reservierten

Bereichen. 왘 Der zweite Server kann das flexible Mirror Device (BCV) für sämtliche

Aktionen nutzen, die mit flexible Mirrors durchgeführt werden können. Abbildung 7.14: HP-UX, LVM und flexible Mirrors in einer Single HostUmgebung HP-Server 1

F C H B A

F C H B A

RW-Enabled

RW-Enabled

436

PVRA VGRA

PVRA VGRA

Standard-Device



7.3.8.2

LVM und Nutzung von flexible Mirrors bei nur einem Server

Ist nur ein Server vorhanden, über dessen Standard-Devices flexible Mirrors synchronisiert werden, getrennt werden, und dann durch Importieren der Volume-Gruppe auf dem selben Server einem konkurrierenden Prozess zur Verfügung gestellt werden, dann muss die Group ID der importierten Volume-Gruppe geändert werden. Ansonsten kann es zu schwerwiegenden Naming-Konflikten und zu Problemen bei der I/O-Platzierung kommen.

7.3.8.3

Kopieren von Daten mit flexible oder remote Mirror in einer Dual-Server-Umgebung

Volume-Gruppen oder Striping Informationen werden beim Kopieren auf flexible Mirror oder remote Mirror mit kopiert. Sollen nun BCVs zur Unterstützung konkurrierender Prozesse oder auch remote Mirrors zur Implementierung eines Disaster Recovery Clusters eingeführt werden, so ist auch im Katastrophenfall eine Restaurierung dieser Informationen nicht notwendig, da sich die Daten inklusive der Volume-Gruppen und Striping Informationen auf dem flexible oder remote Mirror befinden. Folgende Abbildung skizziert die Reihenfolge der Schritte, die zur Nutzung der flexible oder remote Mirrors zum Kopieren der Daten eingehalten werden muss.

HP-Server 1

FC H B A

HP-Server 2

FC H B A

FC H B A


Warten auf den Zustand »synchronized«

FC H B A

Establish starten 2

Abbildung 7.15: HP-UX LVM – Datenkopie mit flexible oder remote Mirror in einer Dual Server-Konfiguration

Anwendungen stoppen Dateisysteme umounten

1 Volume-Gruppen deaktivieren Volume-Gruppen exportieren

3 Anwendungen stoppen, Dateisysteme umounten, VolumeGruppen deaktivieren

Split durchführen 5 4

Volume-Gruppen aktivieren, Dateisysteme mounten, Anwendungen starten

Volume-Gruppen importieren Volume-Gruppen aktivieren Dateisysteme mounten Anwendungen starten

437


Abbildung 7.15 geht davon aus, dass die Daten bereits einmal von den Standard-Devices des HP Servers 1 auf flexible Mirror Devices (HP Server 1 und konkurrierender Prozess auf HP Server 2) oder remote Mirrors auf HP Server 2 synchronisiert wurden und dann von HP Server 1 getrennt wurden (vgl. Kapitel 6). Unabhängig davon, ob es sich um einen flexible oder remote Mirror handelt, laufen im Ausgangszustand die Anwendungen des HP Servers zwei auf den Mirror Devices, die sich aus Sicht des HP Servers 1 im Zustand split befinden. Für eine erneute Kopie der Daten des HP Servers 1 sind nun folgende Schritte einzuhalten. Abbildung 7.16: LVM-Wiederherstellung von flexible und remote Mirror in Dual-ServerKonfiguration

HP-Server 1

FC H B A

HP-Server 2

FC H B A

FC H B A


Anwendungen stoppen Dateisysteme unmounten Volume-Gruppen deaktivieren (Volume-Gruppen exportieren)

1

FC H B A

Anwendungen stoppen Dateisysteme unmounten Volume-Gruppen deaktivieren

2 Restore starten 3 (Volume-Gruppen importieren) Volume-Gruppen aktivieren Dateisysteme mounten Anwendungen starten

1. Auf HP Server 2 müssen die Anwendungen gestoppt, die Dateisysteme auf den Devices aus dem Filesystem mit umount entfernt sowie die betreffenden Volume-Gruppen deaktiviert und exportiert werden. 2. Von HP Server 1 aus wird die Resynchronisation der Mirror Devices gestartet. Dieser establish erfolgt unabhängig davon, ob es sich um einen flexible Mirror (TimeFinder BCV mit dem Kommando symmir establish) oder um einen remote Mirror (SRDF R2 Device mit dem Kommando symrdf establish) handelt.2 3. Sobald der Device Status SYNCHRONIZED erreicht ist, müssen auf HP Server 1 die Anwendungen gestoppt, die Dateisysteme auf den Devices aus dem Filesystem mit umount entfernt sowie die betreffenden VolumeGruppen deaktiviert werden. Der nachfolgende split der Mirror Devices 2.

438



(symmir split oder symrdf split) leert den Cache des Storage Arrays und gewährleistet den konsistenten Zustand der Daten auf den Mirror Devices. 4. Die Anwendungen des HP Servers 1 können auf den Standard-Devices wieder gestartet werden, nachdem die Volume-Gruppen wieder aktiviert und die Dateisysteme mit mount ins Filesystem eingehängt wurden. 5. Auf HP Server 2 werden die Volume-Gruppen importiert und aktiviert, die Dateisysteme mit mount ins Filesystem eingehängt und danach die Applikationen der konkurrierenden Prozesse wieder gestartet. Die Produktion des HP Server zwei ist damit wieder gestartet.

7.3.8.4

Restore von Daten mit flexible oder remote Mirror in einer Dual-Server-Umgebung

Standard-Devices, deren Daten mit flexible Mirrors oder remote Mirrors kopiert wurden, können von diesen Mirror Devices auch wiederhergestellt werden. Dazu sind folgende Schritte auszuführen. 1. Seien die Standard-Devices auf HP Server 1 defekt und müssen von den getrennten flexible oder remote Mirrors, auf denen die Produktion des HP Servers 2 läuft, wiederhergestellt werden. Dazu müssen zunächst auf HP Server 2 die Anwendungen gestoppt und die Dateisysteme auf den Devices aus dem Filesystem mit umount entfernt sowie die betreffenden Volume-Gruppen deaktiviert werden. 2. Auf HP Server 1 müssen ebenfalls die Anwendungen gestoppt und die Dateisysteme auf den Devices aus dem Filesystem mit umount entfernt sowie die betreffenden Volume-Gruppen deaktiviert, evtl. sogar exportiert werden. HP Server 1 startet danach den Restore seiner StandardDevices vom BCV flexible Mirror oder R2 remote Mirror (symmir restore oder symrdf restore). 3. Sobald der Restore der Standard-Devices angelaufen ist, wird eine evtl. exportierte Volume-Gruppe wieder importiert und aktiviert. Danach werden die Dateisysteme der Volume-Gruppe mit mount ins Filesystem von HP Server 1 eingehängt und die Anwendungen gestartet, sodass die Standard-Devices wieder zur Produktion des Servers 1 eingesetzt werden. Soll der Zustand vor dem Restore wiederhergestellt werden, muss nun der Status RESTORED abgewartet werden und mit Punkt 3 des Abschnitts Kopieren von Daten mit flexible oder remote Mirror in einer Dual-Server-Umgebung fortgefahren werden. Dabei sei darauf hingewiesen, dass der Restore von remote oder flexible Mirror eine erhebliche Reduktion der ungeplanten Ausfallzeit im Vergleich zum Restore von Band-Datensicherungen bietet. Dies ist deshalb der Fall, da mit der Produktion auf HP Server 1 bereits direkt nach Anlaufen des Restore begonnen werden kann, also noch bevor alle Daten von den BCVs oder den R2 Devices auf die Standard-Devices rückkopiert wurden. Dabei ist darauf

439


zu achten, dass – falls die BCVs oder die remote Mirrors nicht durch einen jeweiligen lokalen Mirror zusätzlich abgesichert sind – ein Verlust dieser Devices während der Restore Operation nur durch eine vorhandene Bandsicherung behoben werden kann. Bei SRDF remote Mirrors muss zusätzlich beachtet werden, dass die Produktion mit einer reduzierten Bandbreite läuft, solange nicht alle Daten kopiert sind, also mit einem schlechteren Laufzeitverhalten zu rechnen ist.

7.3.8.5

Kopieren von Daten mit flexible oder remote Mirror in einer Single-Server-Umgebung

Abbildung 7.17 zeigt den Ablauf der Erzeugung von Datenkopien mithilfe von flexible Mirrors oder remote Mirrors im Single Server-Fall. Dabei lässt sich über den Sinn von remote Mirrors in einem Single Server-Fall trefflich streiten, dennoch bietet der remote Mirror auch hier eine weitere Ebene des Schutzes vor Verlust der Devices. Er sichert auch im Single Server-Umfeld vor dem Verlust des primären Storage Arrays. Bezüglich der Anwendungsschritte unterscheidet sich der Single Server-Fall jedoch kaum von einer Dual-Server Konfiguration. Die Abbildung geht davon aus, dass die Daten bereits einmal von den Standard-Devices des HP Servers 1 auf flexible Mirror Devices (ebenfalls HP Server 1, evtl. konkurrierender Prozess auf HP Server 1) oder remote Mirrors, die ebenfalls über HP Server 1 erreicht werden können, synchronisiert wurden und dann von HP Server 1 getrennt wurden (vgl. Kapitel 6). Unabhängig davon, ob es sich um einen flexible oder remote Mirror handelt, laufen im Ausgangszustand konkurrierende Anwendungen des HP Servers 1 auf den Mirror Devices, die sich aus Sicht der Standard-Devices des HP Servers 1 im Zustand split befinden. Für eine erneute Kopie der Daten der Standard-Devices auf die flexible oder remote Mirrors sind nun folgende Schritte einzuhalten. 1. Auf HP Server 1 müssen die Anwendungen der konkurrierenden Prozesse gestoppt, die Dateisysteme mit umount aus dem Filesystem des Servers entfernt sowie die Volume-Gruppen deaktiviert und exportiert werden. 2. Von HP Server 1 aus wird die Resynchronisation der Mirror Devices gestartet. Dieser establish erfolgt unabhängig davon, ob es sich um einen flexible Mirror (TimeFinder BCV mit dem Kommando symmir establish) oder um einen remote Mirror (SRDF R2 Device mit dem Kommando symrdf establish) handelt.

440



HP-Server 1

Symmetrix Storage Array Warten auf den Zustand »synchronized« Anwendungen stoppen, Dateisysteme unmounten, VolumeGruppen deaktivieren Volume-Gruppen aktivieren, Dateisysteme mounten, Anwendungen starten

FC H B A


FC H B A

Abbildung 7.17: LVM-Kopie von flexible und remote Mirror in SingleServer Konfiguration


Establish starten 2

Anwendungen stoppen Dateisysteme unmounten 1 Volume-Gruppen deaktivieren Volume-Gruppen exportieren


5

Ändern der Group-ID Volume-Gruppen importieren Volume-Gruppen aktivieren Dateisysteme mounten Anwendungen starten

3. Sobald der Device Status SYNCHRONIZED erreicht ist, müssen auf HP Server 1 die Standard-Anwendungen auf den Standard-Devices gestoppt, die Dateisysteme mit umount aus dem Filesystem des Servers entfernt sowie die Volume-Gruppen deaktiviert werden. 4. Die Standard-Anwendungen des HP Servers 1 können auf den StandardDevices wieder gestartet werden, nachdem die Volume-Gruppen wieder aktiviert und die Dateisysteme mit mount in das Filesystem des Servers eingehängt wurden. 5. Auf HP Server 1 wird danach auf den Mirror Devices die Group-ID der auf ihnen befindlichen Volume-Gruppen geändert, die Volume-Gruppen werden importiert und aktiviert. Die Dateisysteme der Volume-Gruppen werden mit mount in das Filesystem des Servers eingehängt. Danach können die Anwendungen der konkurrierenden Prozesse auf HP Server 1 gestartet und wieder zur Produktion eingesetzt werden.

7.3.8.6

Restore von Daten mit flexible oder remote Mirror in einer Single-Server-Umgebung

Auch im Single Server-Fall können Standard-Devices, deren Daten mit flexible Mirrors oder remote Mirrors kopiert wurden, von diesen Mirror Devices wiederhergestellt werden. Dazu sind folgende Schritte durchzuführen.

441

7 SAN und NAS – Unterstützte File-Systeme Abbildung 7.18: LVM-Wiederherstellung von flexible und remote Mirror in Single-Server Konfiguration


HP-Server 1

FC H B A

FC H B A



Symmetrix Storage Array Anwendungen stoppen Dateisysteme unmounten 1 Volume-Gruppen deaktivieren Volume-Gruppen exportieren

Anwendungen stoppen Dateisysteme unmounten Volume-Gruppen deaktivieren Volume-Gruppen exportieren

2 Restore starten 3 Volume-Gruppen importieren Volume-Gruppen aktivieren Dateisysteme mounten Anwendungen starten

1. Seien die Standard-Devices auf HP Server 1 defekt und müssen von den getrennten flexible oder remote Mirrors, auf denen die Produktion der konkurrienden Prozesse des HP Servers 1 läuft, wiederhergestellt werden. Dazu müssen zunächst auf HP Server 1 die Anwendungen der konkurrierenden Prozesse auf den Mirror Devices gestoppt, die Dateisysteme mit umount aus dem Filesystem des Servers entfernt sowie die VolumeGruppen deaktiviert werden. Weiter müssen die Anwendungen der Standard-Prozesse auf den Mirror Devices gestoppt, die Dateisysteme mit umount aus dem Filesystem des Servers entfernt sowie die Volume-Gruppen deaktiviert werden. 2. HP Server 1 startet dann den Restore seiner Standard-Devices vom BCV flexible Mirror oder R2 remote Mirror (symmir restore oder symrdf restore). 3. Sobald der Restore der Standard-Devices angelaufen ist werden die Volume-Gruppen wieder importiert und aktiviert und die Dateisysteme mit mount in das Filesystem des Servers wieder eingehängt. Danach können die Applikationen der Standard-Prozesse auf HP-Server 1 gestartet und wieder zur primären Produktion eingesetzt werden. Soll der Zustand vor dem Restore wiederhergestellt werden, muss nun der Status RESTORED abgewartet werden und mit Punkt 3 des Abschnitts Kopieren von Daten mit flexible oder remote Mirror in einer Single-Server-Umgebung fortgefahren werden.

442

Logical Volume-Manager IBM-AIX

7.4


7.4.1


Der Logical Volume-Manager (LVM) von IBM wird auf RS6000-Systemen unter dem Betriebssystem AIX eingesetzt. Der LVM kann für Filesysteme, Raw Data wie Datenbankfiles und SwapRegionen eingesetzt werden. Im Folgenden werden grundlegende Begriffe des LVM und seiner Bestandteile erläutert. 왘 Physikalische Datenträger werden auch vom IBM-LVM zu so genannten

Volume-Gruppen zusammengefasst. Da als physikalische Datenträger unter AIX wiederum die Devices – also Splits einer physikalischen Platte – eines Storage Arrays sichtbar sind, kann wiederum ein Matching der Volume-Gruppen des LVM mit den Device-Gruppen des Storage Arrays empfohlen werden. 왘 Jede physikalische Platte, also jedes für den Server sichtbare Device, be-

sitzt eine eindeutige Identifikationsnummer (PVID). 왘 Jede physikalische Platte ist in physical partitions aufgeteilt, die den Slices

des Storage Arrays entsprechen. 왘 Logische Platten bestehen aus logical partitions, die den physischen parti-

tions zugewiesen sind 왘 Logische Platten werden für Filesysteme oder direkt für Anwendungen

verwendet. 왘 Auf jeder physikalischen Platte werden die Merkmale ihrer Volume-

Gruppe gesichert (VGDA), sodass die Zuordnung der Platte zu ihrer Volume-Gruppe stets gewährleistet ist. Für jede Volumegruppe muss in /dev ein Verzeichnis angelegt worden sein. Der Name kann beliebig sein, normalerweise wird jedoch vgnn verwendet. Mit den Kommandos mkvg und extendvg wird eine Volume-Gruppe erzeugt. Die Vorgehensweise soll im folgenden Abschnitt dargestellt werden.

7.4.2

Erzeugung einer Volume-Gruppe

Bevor eine Volume-Gruppe erstellt werden kann muss auf die physikalischen Devices eine PVID geschrieben werden (diese Aktion muss nur einmal beim Anlegen der Volume-Gruppe ausgeführt werden, ansonsten kann sie immer wieder importiert werden).

443

7 SAN und NAS – Unterstützte File-Systeme Abbildung 7.19: Volumes und Partitions im IBM-LVM

chdev -l hdiskn -a pv=yes mkvg, Symmetrix Device

VGDA

extendvg

Symmetrix Device

Physical Volume Symmetrix Device

dev/vg00

Symmetrix Device

VGDA

VGDA

VGDA

Logical Volume Physical

Logical Partitions

Partitions

Das Schreiben der PVID erfolgt mit dem Kommando # chdev -l hdiskn -a pv=yes

Dabei haben die Optionen und Argumente des Kommandos folgende Bedeutung: -l

Link auf eine physikalische Platte. Unter AIX wird keine CTL-Mimik zur Bezeichnung der Platten verwendet, sondern Aliase, die die verfügbaren Platten in aller Regel einfach nur durchnummerieren, wobei mit der ersten Platte des ersten Targets des ersten Disk-Controllers begonnen und in aufsteigender Reihenfolge fortgeführt wird.

hdiskn

Alias-Name der Platte.

-a

Hinzufügen (Add) einer Option. Hier Erzeugen der PVID.

pv=yes

Hinzufügen der PVID. Eine einmal erzeugte PVID kann mit pv=no wieder entfernt werden.

Daraufhin erfolgt der Aufruf von mkvg oder importvg zur Erstellung oder zum Importieren einer Volume-Gruppe, die auf einem anderen Server oder zu einem anderen Zeitpunkt bereits erstellt wurde. # mkvg [-d nn] [-m maxpvsize] [-s PP] [-y VG] hdiskn [hdiskn] ...

444


Dabei haben die Optionen und Argumente des Kommandos folgende Bedeutung: -s -m -d

VG hdiskn

Größe der physical partitions. Maximale Größe des physikalischen Volumes, dabei wird die maximale Anzahl der physical partitions berechnet. Maximale Anzahl der physikalischen Laufwerke in einer Volume-Gruppe. Dabei sind 32 physikalische Laufwerke in einer Volume-Gruppe voreingestellt. Name der Volume-Gruppe. Alias-Name der Platte.

Beispiel: # mkvg -s 16 -y vg01 hdisk5

Diese Kommandozeile erstellt die Volume-Gruppe vg01 mit der Platte hdisk5. Diese ist 16 MB groß. Eine Volumegruppe wird entfernt, wenn das letzte Laufwerk durch reducevg entfernt wurde.

7.4.3

Erzeugung von Logical Volumes

Mit dem Kommando mklv wird ein logical Volume erzeugt, das Kommando rmlv dient dem Löschen logischer Volumes. # mklv [-y newlv] [-m mapfile] vg number [hdiskn]

Dabei haben die Optionen und Argumente des Kommandos folgende Bedeutung: -y newlv -m mapfile vg number hdiskn

Erzeugt ein neues logisches Volume. Erzeugt ein neues logisches Volume unter Verwendung eines Mapfiles. Volume-Gruppe, für die das logische Volume erzeugt wird. Anzahl der Partitions. Alias-Name der Platte.

Dabei sind folgende Anwendungen zu beachten: 왘 Ein logisches Volume kann als raw device z.B. für Daten unter Kontrolle

eines Datenbank Management Systems verwendet werden. 왘 Durch Angabe der Laufwerke kann eine bestimmte Verteilung der I/O-

Lasten auf unterschiedliche Disk Directors realisiert werden. 왘 Zum Erzeugen eines Dateisystems kann der Befehl crfs verwendet wer-

den, ohne dass zuvor ein logisches Volume erzeugt werden muss. 왘 Das Kommando rmlv löscht ein vorhandenes logisches Volume.

445


7.4.4


Das Kommando crfs legt ein Dateisystem auf einem bestehenden oder neuen logischen Volume an. Dabei wird das logische Volume durch crfs erzeugt, falls es noch nicht existiert. Folgende Funktionen werden ausgeführt: 왘 Ein logisches Volume wird erzeugt, falls es noch nicht vorhanden ist,

d.h., falls es noch nicht mit mklv erzeugt wurde. 왘 Ein Dateisystem wird mit dem impliziten Kommando mkfs angelegt. 왘 Diese Änderungen werden in der ODM (Object Data Manager) Datenbank

und in /etc/filesystems eingetragen. Optionen und Parameter des crfs-Kommandos sind: -g volgrp -a size = nn -d device -m mntpt -A yes|no

7.4.5

Name der Volume-Gruppe Größe des Dateisystems (in 512 Byte Blöcken). Gerätename eines bestehenden logischen Volumes. Mountpunkt, an dem das Dateisystem im Verzeichnissystem des Servers eingehängt wird. Der Automount Parameter erzeugt die Zeile mount=true in /etc/fstab und sorgt dafür, dass dieses Dateisystem beim Start von AIX automatisch in die Verzeichnisstruktur des Servers eingehängt wird.


Folgende weitere Befehle definieren zusätzliche Funktionen für den Logical Volume-Manager: # varyonvg vg

Dieses Kommando wird bei Ausführung von mkvg automatisch ausgeführt, muss jedoch auch für jede Änderung der Zusammensetzung einer VolumeGruppe durchgeführt werden. # varyoffvg vg

Dieses Kommando beendet die Änderung der Zusammensetzung der Device-Gruppe. # exportvg vg

Dieses Kommando entfernt die Volume-Gruppe aus dem System. Die Volume-Gruppe muss zuvor deaktiviert worden sein, damit exportvg ausgeführt wird. # importvg [-m file] vg

Importiert eine Volume-Gruppe aus einer mit –m spezifizierten Datei.

446


7.4.6

Striping im AIX-LVM

Unter Striping versteht man die Verteilung eines Logical Volumes über verschiedene physikalische Platten. Die Vorteile dieser Verteilung sind dabei: 왘 Der Datenzugriff ist auf mehrere Laufwerke verteilt. Dies führt dazu,

dass idealerweise eine bessere Auslastung der Disk Directors und des Caches erreicht wird, da die Anzahl der physikalischen I/Os evtl. über mehrere Disk Directors, definitiv jedoch über mehrere physikalische Laufwerke verteilt und somit die Positionierungsbewegungen der Schreib-/Leseköpfe distanzverringert und somit schneller durchgeführt werden können. 왘 Die Verteilung der I/O-Last auf mehrere Channel Directors. Dieser Vor-

teil kommt zusätzlich zum zuvor genannten hinzu, wenn für das Striping die Pfade einer Multipathing-Konfiguration genutzt werden. Nachteile des Stripings sind eindeutig darin zu sehen, dass 왘 Ein Hardwarefehler auf einer physikalischen Platte dazu führen kann,

dass Daten unterschiedlicher Anwendungen von diesem Fehler betroffen sind. Alle Anwendungen, die auf einem von einem Fehler betroffenen physikalischen Laufwerk einen Stripe liegen haben, werden von den durch den Fehler erzeugten Auswirkungen betroffen. Bei einer anwendungsreinen Platte, auf der ohne Striping lediglich Daten dieser Applikation liegen, würde allein diese Applikation vom Fehler betroffen. 왘 Sämtliche Dateien, von denen ein auch nur geringer Teil auf einem Stripe

des betroffenen physikalischen Laufwerks gelegen haben, wiederhergestellt werden müssen. 왘 Eine zusätzliche Ebene architekturaler und administrativer Komplexität

eingeführt wird. 왘 Die Anzahl der physikalischen I/Os steigt. Jeder I/O-Request wird über

den Cache des Storage Arrays auf mehrere Devices verteilt, über die das Volume gestriped wurde. Sämtliche bisher betrachteten Destaging Operationen der Disk-Adapter werden je Device durrchgeführt, auf dem ein Stripe liegt. Striping wird unter LVM mit dem Kommando mklv eingerichtet. # mklv -u phvol -S stripe-size vg

Dabei bedeuten die Optionen und Argumente des Kommandos Folgendes: -u

Anzahl der Laufwerke über die das Striping erfolgt.

-S

stripe size in Kb (4,8,16,32,64 oder 128). Hierdurch wird die Größe eines Blockes definiert, der auf eine physikalische Platte geschrieben wird, bevor der nächste Block dieser Größe auf die nächste Platte des Stripe-Sets geschrieben wird usw. in alternierender Folge.

447


7.4.7

Dateisysteme und flexible/remote mirrors unter AIX

Unter AIX und dem Logical Volume-Manager kann das Konzept der flexible Mirrors wie beschrieben umgesetzt und realisiert werden. Auch hier können BCV Devices (EMC2) für konkurrierende Prozesse genutzt werden.

7.4.8

LVM und flexible Mirrors in einer Dual-Server-Umgebung

Bei der Nutzung der flexible Mirrors für einen konkurrierenden Prozess auf einem anderem Host als dem, von dem die Standard-Devices verwendet werden, müssen keinerlei Besonderheiten beachtet werden. Abbildung 7.20: Flexible Mirrors unter AIX-LVM

AIX-Server 1

F C H B A

F C H B A

AIX-Server 2 RW-Enabled

F C H B A

F C H B A

RW-Enabled

VGDA

VGDA

Standard-Device


왘 Werden Standard- und BCV-Datenträger mit symmir split voneinander

getrennt, so kann ein zweiter Server (AIX Server 2) das BCV-Volume einfach durch Importieren der Daten verwenden. Beim Importieren einer Volume-Gruppe auf flexible Mirror durch den AIX Server 2 kann dieser Volume-Gruppe der gleiche Name oder auch ein anderer Name zugewiesen werden, als ihn die Volume-Gruppe auf den Standard-Devices besitzt. Dennoch werden natürlich durch die Verwendung des TimeFinder symmr-Kommandos auch die VGDAs der Laufwerke auf das BCV geschrieben.

448

Logical Volume-Manager IBM-AIX 왘 Wurde auf dem AIX Server 1 eine Mapdatei erzeugt, so kann diese auf

dem AIX Server 2 beim Importieren der Volume-Gruppe verwendet werden. Die logischen Volumes bekommen dann die gleichen Namen wie auf AIX Server 1. Ohne Verwendung einer Mapdatei werden die logischen Volumes bei 0 beginnend aufsteigend nummeriert (lvol0, lvol1 usw.). 왘 Es gibt keinen Konflikt wegen der gleichen Inhalte in den reservierten


Aktionen nutzen, die mit flexible Mirrors durchgeführt werden können.

7.4.9

AIX-LVM und Nutzung der flexible Mirrors bei nur einem Server

Ist nur ein Server vorhanden, über dessen Standard-Devices flexible Mirrors synchronisiert werden, getrennt werden, kann man diese nicht durch Importieren der Volume-Gruppe auf dem selben Server einem konkurrierenden Prozess zur Verfügung stellen. Hierfür müssen die IDs der physikalischen Platten (PVID) neu geschrieben und die Volume-Gruppen mit angepassten Mapfiles neu erstellt werden.

AIX-Server 1

Abbildung 7.21: AIX-LVM-Flexible Mirrors in einer Single-Host-Umgebung

F C H B A

F C H B A

RW-Enabled

RW-Enabled

PVID VGDA

PVID VGDA

Standard-Device


449


7.4.10 Kopieren von Daten mit flexible oder remote Mirror in einer Dual-ServerUmgebung Volume-Gruppen oder Striping Informationen werden beim Kopieren auf flexible Mirror oder remote Mirror mit kopiert. Sollen nun BCVs zur Unterstützung konkurrierender Prozesse oder auch remote Mirrors zur Implementierung eines Disaster Recovery Clusters eingeführt werden, so ist auch im Katastrophenfall eine Restaurierung dieser Informationen nicht notwendig, da sich die Daten inklusive der Volume-Gruppen und Striping-Informationen auf dem flexible oder remote Mirror befinden. Abbildung 7.22 skizziert die Reihenfolge der Schritte, die zur Nutzung der flexible oder remote Mirrors zum Kopieren der Daten eingehalten werden muss. Die Abbildung geht davon aus, dass die Daten bereits einmal von den Standard-Devices des AIX Servers 1 auf flexible Mirror Devices (AIX Server 1 und konkurrierender Prozess auf AIX Server 2) oder remote Mirrors auf AIX Server 2 synchronisiert wurden und dann von AIX Server 1 getrennt wurden (vgl. Kapitel 6). Unabhängig davon, ob es sich um einen flexible oder remote Mirror handelt, laufen im Ausgangszustand die Anwendungen des AIX Servers 2 auf den Mirror Devices, die sich aus Sicht des AIX Servers 1 im Zustand split befinden. Für eine erneute Kopie der Daten des AIX Servers 1 sind nun folgende Schritte einzuhalten. 1. Auf AIX Server 2 müssen die Anwendungen gestoppt, die Dateisysteme auf den Devices aus dem Filesystem mit umount entfernt sowie die betreffenden Volume-Gruppen deaktiviert und exportiert werden. 2. Von AIX Server 1 aus wird die Resynchronisation der Mirror Devices gestartet. Dieser establish erfolgt unabhängig davon, ob es sich um einen flexible Mirror (TimeFinder BCV mit dem Kommando symmir establish) oder um einen remote Mirror (SRDF R2 Device mit dem Kommando symrdf establish) handelt.3 3. Sobald der Device Status SYNCHRONIZED erreicht ist, müssen auf AIX Server 1 die Anwendungen gestoppt, die Dateisysteme auf den Devices aus dem Filesystem mit umount entfernt sowie die betreffenden VolumeGruppen deaktiviert. Der nachfolgende split der Mirror Devices (symmir split oder symrdf split) leert den Cache des Storage Arrays und gewährleistet den konsistenten Zustand der Daten auf den Mirror Devices. 4. Die Anwendungen des AIX Servers 1 können auf den Standard-Devices wieder gestartet werden, nachdem die Volume-Gruppen wieder aktiviert und die Dateisysteme mit mount ins Filesystem eingehängt wurden.

3.

450



AIX-Server 1

FC H B A

AIX-Server 2

FC H B A

FC H B A



FC H B A

Establish starten 2

Abbildung 7.22: AIX-LVM – Datenkopie mit flexible oder remote Mirror in einer Dual Server-Konfiguration


3 Anwendungen stoppen, Dateisysteme unmounten, VolumeGruppen deaktivieren


Volume-Gruppen aktivieren, Dateisysteme mounten, Anwendungen starten

Volume-Gruppen importieren Volume-Gruppen aktivieren Dateisysteme mounten Anwendungen starten

5. Auf AIX Server 2 werden die Volume-Gruppen importiert und aktiviert, die Dateisysteme mit mount ins Filesystem eingehängt und danach die Applikationen der konkurrierenden Prozesse wieder gestartet. Die Produktion des AIX Server 2 ist damit wieder gestartet.

7.4.11 Restore von Daten mit flexible oder remote Mirror in einer Dual-ServerUmgebung Standard-Devices, deren Daten mit flexible Mirrors oder remote Mirrors kopiert wurden, können von diesen Mirror Devices auch wiederhergestellt werden. Dazu sind folgende Schritte auszuführen. 1. Seien die Standard-Devices auf AIX Server 1 defekt und müssen von den getrennten flexible oder remote Mirrors, auf denen die Produktion des AIX Servers zwei läuft, wiederhergestellt werden. Dazu müssen zunächst auf AIX Server 2 die Anwendungen gestoppt und die Dateisysteme auf den Devices aus dem Filesystem mit umount entfernt sowie die betreffenden Volume-Gruppen deaktiviert werden. 2. Auf AIX Server 1 müssen ebenfalls die Anwendungen gestoppt und die Dateisysteme auf den Devices aus dem Filesystem mit umount entfernt sowie die betreffenden Volume-Gruppen deaktiviert, evtl. sogar exportiert werden. AIX Server 1 startet danach den Restore seiner Standard-

451


Devices vom BCV flexible Mirror oder R2 remote Mirror (symmir restore oder symrdf restore). 3. Sobald der Restore der Standard-Devices angelaufen ist, wird eine evtl. exportierte Volume-Gruppe wieder importiert und aktiviert. Danach werden die Dateisysteme der Volume-Gruppe mit mount ins Filesystem von AIX Server 1 eingehängt und die Anwendungen gestartet, sodass die Standard-Devices wieder zur Produktion des AIX Servers 1 eingesetzt werden. Abbildung 7.23: AIX-LVM – Datenwiederherstellung mit flexible oder remote Mirror in einer Dual ServerKonfiguration

AIX-Server 1

FC H B A

AIX-Server 2

FC H B A

FC H B A


Anwendungen stoppen Dateisysteme unmounten Volume-Gruppen deaktivieren (Volume-Gruppen exportieren)

1

FC H B A

Anwendungen stoppen Dateisysteme unmounten Volume-Gruppen deaktivieren

2 Restore starten 3 (Volume-Gruppen importieren) Volume-Gruppen aktivieren Dateisysteme mounten Anwendungen starten

Soll der Zustand vor dem Restore wiederhergestellt werden, muss nun der Status RESTORED abgewartet werden und mit Punkt 3 des Abschnitts Kopieren von Daten mit flexible oder remote Mirror in einer Dual-Server-Umgebung fortgefahren werden. Dabei sei darauf hingewiesen, dass der Restore von remote oder flexible Mirrors eine erhebliche Reduktion der ungeplanten Ausfallzeit im Vergleich zum Restore von Band-Datensicherungen bietet. Dies ist deshalb der Fall, da mit der Produktion auf AIX Server 1 bereits direkt nach Anlaufen des Restore begonnen werden kann, also noch bevor alle Daten von den BCVs oder den R2 Devices auf die Standard-Devices rückkopiert wurden. Dabei ist darauf zu achten, dass – falls die BCVs oder die remote Mirrors nicht durch einen jeweiligen lokalen Mirror zusätzlich abgesichert sind – ein Verlust dieser Devices während der Restore-Operation nur durch eine vorhandene Bandsicherung behoben werden kann. Bei SRDF remote Mirrors muss zusätzlich

452


beachtet werden, dass die Produktion mit einer reduzierten Bandbreite läuft, solange nicht alle Daten kopiert sind, also mit einem schlechteren Laufzeitverhalten zu rechnen ist.


AIX-Server 1

Symmetrix Storage Array Warten auf den Zustand »synchronized« Anwendungen stoppen, Dateisysteme unmounten, VolumeGruppen deaktivieren, Mapdatei für jedes logische Volume erzeugen Volume-Gruppen aktivieren, Dateisysteme mounten, Anwendungen starten

FC H B A


FC H B A


Establish starten 2

Abbildung 7.24: AIX-LVM – Datenkopie mit flexible oder remote Mirror in einer SingleServer-Konfiguration



5

Mapdateien editieren, IDs für die Laufwerke neu schreiben, Volume-Gruppen neu anlegen, Logische Volumes mithilfe der Mapdateien erzeugen, »jfslog«-Datei erzeugen, Eintragung in /etc/filesystems, Dateisysteme mounten, Anwendungen starten

7.4.12 Kopieren von Daten mit flexible/remote Mirror in einer Single-ServerKonfiguration Abbildung 7.24 zeigt den Ablauf der Erzeugung von Datenkopien mithilfe von flexible Mirrors oder remote Mirrors im Single Server-Fall. Dabei lässt sich über den Sinn von remote Mirrors in einem Single Server-Fall trefflich streiten, dennoch bietet der remote Mirror auch hier eine weitere Ebene des Schutzes vor Verlust der Devices. Er sichert auch im Single Server-Umfeld vor dem Verlust des primären Storage Arrays. Bezüglich der Anwendungsschritte unterscheidet sich der Single Server-Fall jedoch erheblich von einer Dual-Server Konfiguration, da hier die VolumeInformationen nicht übernommen werden können, da dies extreme Unregelmäßigkeiten beim Betrieb der Mirror Devices für konkurrierende Prozesse hervorrufen würde. Die Abbildung geht davon aus, dass die Daten bereits einmal von den Standard-Devices des AIX Servers 1 auf flexible Mirror Devices (ebenfalls AIX Server 1, evtl. konkurrierender Prozess auf AIX Server 1) oder remote Mirrors, die ebenfalls über AIX Server 1 erreicht werden können, synchronisiert

453


wurden und dann von AIX Server 1 getrennt wurden (vgl. Kapitel 6). Unabhängig davon, ob es sich um einen flexible oder remote Mirror handelt, laufen im Ausgangszustand konkurrierende Anwendungen des AIX Servers 1 auf den Mirror Devices, die sich aus Sicht der Standard-Devices des AIX Servers 1 im Zustand split befinden. Für eine erneute Kopie der Daten der Standard-Devices auf die flexible oder remote Mirrors sind nun folgende Schritte einzuhalten. 1. Auf AIX Server 1 müssen die Anwendungen der konkurrierenden Prozesse gestoppt, die Dateisysteme mit umount aus dem Filesystem des Servers entfernt sowie die Volume-Gruppen deaktiviert und exportiert werden. 2. Von AIX Server 1 aus wird die Resynchronisation der Mirror Devices gestartet. Dieser establish erfolgt unabhängig davon, ob es sich um einen flexible Mirror (TimeFinder BCV mit dem Kommando symmir establish) oder um einen remote Mirror (SRDF R2 Device mit dem Kommando symrdf establish) handelt. 3. Sobald der Device Status SYNCHRONIZED erreicht ist, müssen auf AIX Server 1 die Standard-Anwendungen auf den Standard-Devices gestoppt, die Dateisysteme mit umount aus dem Filesystem des Servers entfernt sowie die Volume-Gruppen deaktiviert und für jedes logische Volume eine Mapdatei erzeugt werden, die im Schritt 5 editiert werden muss. 4. Die Standard-Anwendungen des AIX Servers 1 können auf den Standard-Devices gestartet werden, nachdem die Volume-Gruppen wieder aktiviert und die Dateisysteme mit mount in das Filesystem des Servers eingehängt wurden. 5. Auf AIX Server 1 werden danach die Mapdateien der Volume-Gruppen eingehängt, die Volume-Gruppen werden importiert und aktiviert. Die Dateisysteme der logischen Volumes werden editiert und mit neuen IDs für die einzelnen physikalischen Volumes versehen. Die Volumegruppen müssen neu erzeugt und die Volumegruppen mithilfe der in Schritt 3 erzeugten Mapdateien neu angelegt werden. Bevor die Dateisysteme mit mount in das Filesystem des Servers eingehängt werden können, muss noch ein jfslog-Eintrag erzeugt werden und ein Eintrag in /etc/filesystems für das neue Dateisystem gemacht werden. Danach können die Anwendungen der konkurrierenden Prozesse auf AIX Server 1 gestartet und wieder zur Produktion eingesetzt werden.

454


7.4.13 Restore von Daten mit flexible/remote Mirror in einer Single-ServerKonfiguration Auch im Single Server-Fall können Standard-Devices, deren Daten mit flexible Mirrors oder remote Mirrors kopiert wurden, von diesen Mirror Devices wiederhergestellt werden. Dazu sind folgende Schritte durchzuführen.


AIX-Server 1

FC H B A

FC H B A




Abbildung 7.25: AIX-LVM – Datenwiederherstellung mit flexible oder remote Mirror in einer Single-ServerKonfiguration


Anwendungen stoppen Dateisysteme unmounten Volume-Gruppen deaktivieren Volume-Gruppen exportieren

2 Restore starten 3 Volume-Gruppen importieren Volume-Gruppen aktivieren Dateisysteme mounten Anwendungen starten

1. Seien die Standard-Devices auf AIX Server 1 defekt und müssen von den getrennten flexible oder remote Mirrors, auf denen die Produktion der konkurrienden Prozesse des AIX Servers 1 läuft, wiederhergestellt werden. Dazu müssen zunächst auf dem AIX Server 1 die Anwendungen der konkurrierenden Prozesse auf den Mirror Devices gestoppt, die Dateisysteme mit umount aus dem Filesystem des Servers entfernt sowie die Volume-Gruppen deaktiviert werden. Weiter müssen die Anwendungen der Standard-Prozesse auf den Mirror Devices gestoppt, die Dateisysteme mit umount aus dem Filesystem des Servers entfernt sowie die Volume-Gruppen deaktiviert werden. 2. AIX Server 1 startet dann den Restore seiner Standard-Devices vom BCV flexible Mirror oder R2 remote Mirror (symmir restore oder symrdf restore).

455


3. Sobald der Restore der Standard-Devices angelaufen ist werden die Volume-Gruppen wieder importiert und aktiviert und die Dateisysteme mit mount in das Filesystem des Servers wieder eingehängt. Danach können die Applikationen der Standard-Prozesse auf AIX Server 1 gestartet und wieder zur primären Produktion eingesetzt werden. Soll der Zustand vor dem Restore wiederhergestellt werden, muss nun der Status RESTORED abgewartet werden und mit Punkt 3 des Abschnitts Kopieren von Daten mit flexible/remote Mirror in einer Single-Server-Umgebung fortgefahren werden.

7.5

Volumes und Dateisysteme unter Sun Solaris

7.5.1

Solstice DiskSuite: Überblick

Die Solstice DiskSuite von Sun dient als ein Werkzeug zum Erstellen und Verwalten von Dateien. Sie unterstützt grose Dateisysteme, die über die physikalische Größe einer physikalischen Magnetplatte hinausgehen, die Erweiterung von Dateisystemen und eine spezielle Protokollierung auf VolumeManager Ebene, die als intent logging bezeichnet wird. Unter der Solstice Disk Suite können zusammenhängende, gestripte oder gespiegelte (mirrored) logische Volumes erzeugt werden. Diese können als raw device für Dateien unter Kontrolle eines Datenbank Management Systems oder anderen Services oder für Unix-Dateisysteme mit oder ohne logging verwendet werden. Zur Erzeugung eines Metadevices, das aus mehreren Volumes besteht, muss die Datei /etc/opt/SunWmd/md.tab editiert und anschließend das Metadevice mit dem Kommando metainit angelegt werden. Das erfolgreiche Anlegen eines Metadevices wird mit dem Kommando metastat überprüft.

7.5.2

Erzeugung eines Concatenated Volume

Ein Metadevice stellt ein Concatenated Volume dar, das aus mehreren Volumes zusammengesetzt ist. Zur Erstellung eines Metadevices, das sich aus mehreren Datenträgern zusammensetzt, muss für das Device ein Eintrag in der Datei /etc/opt/SunWmd/md.tab gemacht werden, z.B. also: /dev/md/dsk/d0 2 1 /dev/dsk/c1t0d0s0 1 /dev/dsk/c1t0d1s0

456


Dabei haben die eingegebenen Optionen und Argumente folgende Bedeutung: d0

Name des »Metadevice«

2

Anzahl der Laufwerk-Definitionsblöcke

1

Anzahl der Laufwerke in einem Definitionsblock

Anschließend folgt die Bezeichnung der Laufwerke des ersten LaufwerkDefinitionsblocks nach CTL-Mimik wiederum gefolgt von einer Anzahl der Laufwerke im nächsten Definitionsblock, an die sich wiederum die Bezeichnung der Laufwerke dieses Definitionsblocks in CTL-Mimik anschließt usw. Anschließend wird mit dem Kommando metainit d0 das Metadevice d0 angelegt.

7.5.3

Erzeugung eines Concatenated Volume mit UFS Logging

UFS-Logging implementiert das intent logging der Solstice DiskSuite. Hier werden die initialen Zustände der Filesystem-Blöcke gehalten – ähnlich eines Journaled Filesystems – deren Dateien zum gegenwärtigen Zeitpunkt geöffnet sind. Bei einem Systemabsturz oder sonstigen gravierenden Fehler muss der anschließende fsck nun nicht mehr das komplette Dateisystem durchlaufen, um die Konsistenz des Filesystems zu gewährleisten, sondern lediglich die Einträge im Logfile auf die Basisblöcke des Filesystems zurückkopieren, wodurch dieses sich wieder in dem Zustand befindet, in dem es vor den Änderungen der zum Zeitpunkt des Fehlers aktiven Anwendungen war. Für die Erzeugung eines Concatenated Volumes mit UFS Logging muss ein so genanntes Metatrans Device erzeugt werden. Dabei deutet der Begriff schon darauf hin, dass dieses Device einem transaktionsorientierten Logging der Dateisystemänderungen dienen soll, wie man es von Datenbank Managementsystemen her kennt. Dieses Metatrans Device setzt sich aus folgenden zwei Datenträgern zusammen: 왘 Das Master Metadevice beinhaltet die Daten respektive das Dateisystem,

das Protokolliert (geloggt) werden soll. 왘 Das Logging Metadevice .beinhaltet die Protokolldatei. Dabei muss der

logging file 10MB pro 1GB zu protokollierender Daten groß sein. Wie schon beim Anlegen des Concatenated Volumes ohne UFS-Logging müssen Einträge in die Datei /etc/opt/SunWmd/md.tab gemacht werden: /dev/md/dsk/d1 2 1 /dev/dsk/c1t2d2s0 1 /dev/dsk/c1t2d3s0 /dev/md/dsk/d2 2 1 /dev/dsk/c1t2d2s3 1 /dev/dsk/c1t2d3s3 /dev/md/dsk/d0 -t /dev/md/dsk/d1 /dev/md/dsk/d2

457


Dabei haben die Optionen und Argumente der Einträge folgende Bedeutung d0

Name des Metatrans Devices

d1

Name des Master Metadevices

d2

Name des Logging Metadevices

-t

Option zur Erstellung eines Metatrans Devices

2

Anzahl der Laufwerk-Definitionsblöcke

1

Anzahl der Laufwerke in einem Definitionsblock

Anschließend folgt die Bezeichnung der Laufwerke des ersten LaufwerkDefinitionsblocks nach CTL-Mimik wiederum gefolgt von einer Anzahl der Laufwerke im nächsten Definitionsblock, an die sich wiederum die Bezeichnung der Laufwerke dieses Definitionsblocks in CTL-Mimik anschließt usw. Letztendlich wird mit den Kommandos # metainit d2 # metainit d1 # metainit d0

das Logging Metadevice, das Master Metadevice und das Metatrans Device angelegt.

7.5.4

Erzeugung eines Striped Volume

Zur Erzeugung eines Striped Volume muss die Datei /etc/opt/SunWmd/md.tab wie folgt editiert werden: /dev/md/dsk/d0 1 4 /dev/dsk/c1t1d1s0 /dev/dsk/c2t1d1s0 \ /dev/dsk/c1t1d1s0 /dev/dsk/c2t1d1s0 -i 64k Dabei haben die Optionen und Argumente des Eintrages folgende Bedeutung: d0

Name des »Metadevice«

1

Anzahl der Stripe-Definitionsblöcke

4

Anzahl der Laufwerke in einem Stripe-Definitionsblock

- i 64k

Stripegröße (8 – 64k)

Anschließend folgt die Bezeichnung der Laufwerke des ersten Stripe-Definitionsblocks nach CTL-Mimik wiederum gefolgt von einer Anzahl der Laufwerke im nächsten Definitionsblock, an die sich wiederum die Bezeichnung der Laufwerke dieses Definitionsblocks in CTL-Mimik anschließt usw. Anschließend wird mit dem Kommando metainit d0 das Stripe-Volume d0 angelegt.

458


7.5.5

Erzeugung eines Striped Volume mit UFS Logging

Wie schon beim Anlegen des Striped Volumes ohne UFS-Logging müssen Einträge in die Datei /etc/opt/SunWmd/md.tab gemacht werden: /dev/md/dsk/d1 2 1 /dev/dsk/c1t2d2s0 1 /dev/dsk/c1t2d3s0 –i 64k /dev/md/dsk/d2 2 1 /dev/dsk/c1t2d2s3 1 /dev/dsk/c1t2d3s3 –i 64k /dev/md/dsk/d0 -t /dev/md/dsk/d1 /dev/md/dsk/d2

Dabei haben die Optionen und Argumente der Einträge folgende Bedeutung d0 d1 d2 -t 1 2 - i 64k

Name des Metatrans Devices Name des Master Metadevices Name des Logging Metadevices Option zur Erstellung eines Metatrans Devices Anzahl der Stripe-Definitionsblöcke Anzahl der Laufwerke in einem Stripe-Definitionsblock Stripegröße (8 – 64k)

Anschließend folgt die Bezeichnung der Laufwerke des ersten Stripe-Definitionsblocks nach CTL-Mimik wiederum gefolgt von einer Anzahl der Laufwerke im nächsten Definitionsblock, an die sich wiederum die Bezeichnung der Laufwerke dieses Definitionsblocks in CTL-Mimik anschließt usw. Letztendlich wird mit den Kommandos # metainit d2 # metainit d1 # metainit d0

das Logging Metadevice, das Master Metadevice und das Metatrans Device angelegt.

7.5.6


Nachdem ein Datenträger – auch hier stets ein Storage Array Split oder Device – formatiert, partitioniert und gekennzeichnet (Label) ist, kann ein Dateisystem auf dem Device erzeugt werden. Dies geschieht – wie schon im Kapitel zwei beschrieben, auf das hier verwiesen sei – mit den Kommandos: # newfs -v /dev/rdsk/c0t1d2s0 # mkdir /myfilesystem # mount /dev/dsk/c0t1d2s0 /myfilesystem

oder für SDS (Solstice DiskSuite) Devices mit den Kommandos: # newfs -v /dev/md/rdsk/d0 # mkdir /myfilesystem # mount /dev/md/dsk/d0/myfilesystem

459


7.6

EMC Foundation Suite von Veritas (FS)

Die EMC Foundation Suite von Veritas integriert die Funktionalität des Veritas Volume-Managers und des Veritas File Systems in die Betriebs- und Administrations-Storage-Software von EMC2. Die EMC Foundation Suite dient als Werkzeug zum Erstellen und Verwalten von Dateien und unterstützt dabei große Dateisysteme, die über die physikalische Grenze eines physikalischen Magnetplatten-Laufwerkes hinaus reichen können, die Erweiterung von Dateisystemen und eine Journalfunktion vergleichbar dem Logging der Solstice DiskSuite von Sun für das Filesystem. Unter der EMC Foundation Suite können zusammenhängende, gestripte oder gespiegelte (mirrored) logische Volumes erzeugt werden. Diese können als raw device für Dateien unter Kontrolle eines Datenbank Management Systems oder anderen Services oder für Unix-Dateisysteme – auch dem Veritas File System – mit oder ohne logging verwendet werden. Die EMC Foundation Suite ist durchaus tiefer in die Storage Software von EMC2 integriert als die Solstice DiskSuite. Diese unterstützt im Wesentlichen lediglich die Standard-Betriebs- und Administrations-Applikationen der Symmetrix-Speichersysteme. Die EMC Foundation Suite von Veritas unterstützt daneben zusätzlich die Analyse der Plattenauslastung im Symmetrix Storage Array, sämtliche RAID-Techniken und die dynamische Rekonfiguration der Devices des Storage Arrays im Online Betrieb. Dabei besteht die EMC Foundation Suite aus folgenden Bausteinen: 왘 Veritas Volume-Manager(VxVM) 왘 Veritas File System(VxFS) 왘 Veritas TimeFinder Toolkit(VRTSvxtf)

7.7

Veritas Volume-Manager: Übersicht

Der Veritas Volume-Manager (VxVM) entspricht seiner Funktionalität nach den LVMs unter HP-UX und AIX, wird jedoch von Veritas für eine Vielzahl von Betriebssystemen als übergreifendes Volume-Management System verfügbar gemacht.

460

Veritas Volume-Manager: Übersicht 왘 Durch VxVM werden physikalische Datenträger – Splits oder Devices

des Storage Arrays – zu Disk Groups zusammengefasst. Diese Disk Groups sollten idealerweise mit den Device-Gruppen des Storage Arrays für die Operation mit flexible und remote Mirrors übereinstimmen. 왘 Jede physikalische Platte erhält von VxVM eine eindeutige ID und einen

eigenen Namen zugewiesen. 왘 Teile der physikalischen Platten – als Subdisks bezeichnet – werden zu so

genannten Plexes zusammengefasst. Ein oder mehrere Plexes bilden unter VxVM wiederum ein Volume. 왘 Ein Volume ist unter VxVM eine virtuelle Platte, die für ein Dateisystem

oder ein raw Device unter Kontrolle eines Datenbank Management Systems oder eines anderen Services verwendet werden kann. Physical Volumes

Abbildung 7.26: VxVM – Volumes, Disks, Subdisks und Plexes

VM -Disks

vxdiskadd

Symmetrix Device Symmetrix Device Symmetrix Device Symmetrix Device

Label Private Region Public Region Label Private Region Public Region Label Private Region Public Region Label Private Region Public Region

Gro u p 1

Gro u p 2

Volume Plex

VM -Disks Plex

Subdisk Subdisk Subdisk

Subdisk

Subdisk

Subdisk

Subdisk

Subdisk

Subdisk

Subdisk

Subdisk

Plex

Subdisk

왘 Auf jeder Platte werden in einem privaten Bereich Daten über die Grup-

pen und Volumes abgespeichert, sodass aus jeder Disk innerhalb der Disk Group die komplette Disk Groups Information erhalten werden kann.

461


7.7.1

Erzeugung einer Disk Group

Der Veritas Volume-Manager unterstützt die als Standard Disk Group die Disk Group rootdg. Eine neue Disk Group (mynewdg) wird mit folgendem Kommando erzeugt: # vxdg init mynewdg c1t2d3

Dabei wird der Disk Group in CTL-Mimik ein physical Device zugewiesen. Eine zweite Möglichkeit der Erstellung einer Disk Group ergibt sich durch Aufruf des Kommandos vxdiskadd bei dem ein Name für eine neue Gruppe spezifiziert werden kann.

7.7.2

Import/Deport einer Disk Group

Das Konzept des Importierens und Deportierens einer Disk Group wird in Verbindung mit Veritas Cluster-Server relevant, der eine Clusterkonfiguration multipler Knoten unterstützt (vgl. Kapitel sechs dieses Buches). Für die Arbeit mit Gruppen im Cluster gilt dabei zu beachten: 왘 Eine Disk Group kann nur in einem Server importiert worden sein. Mit

dem Kommando # vxdg import mydiskgroup

wird die Disk Group in den Server importiert, von dem aus das Kommando eingegeben wird. 왘 Mit dem Kommando

# vxrecover –g mydiskgroup -sb

werden die Volumes der Disk Group auf dem Server gestartet, von dem aus das Kommando eingegeben wird. 왘 Mit dem Kommando

# vxdg deport mydiskgroup

wird die Disk Group aus dem Server deportiert, von dem aus das Kommando eingegeben wird.

7.7.3

Erzeugung einer Subdisk

Für die Erzeugung einer Subdisk bietet VxVM mehrere Möglichkeiten. 왘 VxVM und vxassist suchen automatisch einen passenden Bereich auf ei-

ner VxVM Disk und legen die Subdisk an. 왘 Mit den Kommandos vxmake oder vxsd legt der Administrator die genaue

Lage der Subdisk auf einer Disk fest.

462


Das vxmake-Kommando wird dazu wie folgt verwendet: # vxmake

-g mydiskgroup sd my-Volume 9-1 disk=mysubdisk 9-1-1 offset=0 len=1800m

Dabei haben die Optionen und Argumente des Kommandos folgende Bedeutung: -g mydiskgroup Name der Veritas Disk Group. sd

Es soll eine Subdisk angelegt werden.

my-Volume 9-01 Name des Volumes. disk=mysubdisk Genaue Bezeichnung der Disk innerhalb der Disk Group. offset=0

Der Offset gibt die Anzahl der Spuren vom logischen Beginn der Platte an, die übersprungen werden, bevor die Subdisk beginnt. Dies sind Disk-Bereiche, die in der Regel bereits durch andere Subdisks belegt sind. Ein Offset von 0 bedeutet, dass die Subdisk mit Spur 0 des physikalischen Devices beginnt, also wahrscheinlich die erste Subdisk auf der Disk ist.

len=1800m

Definiert die Größe der Subdisk in Megabytes.

7.7.4

Erzeugung eines Plexes

Ein leerer Plex wird unter VxVM mit den Kommandos # vxmake -g mynonstripeddg plex my-Volume 9-01 layout=nostripe # vxmake -g mystripeddg plex my-Volume 9-01 layout=stripe # vxmake -g mayraid5dg plex my-Volume 9-01 layout=raid5

erzeugt, je nachdem, ob der Plex nicht gestriped, gestriped oder als RAID5Plex angelegt werden soll. Die Optionen und Argumente des Kommandos bedeuten hier: -g diskgroupname Name der Veritas Disk Group. plex

Es soll ein Plex angelegt werden.

my-Volume 9-01 Name des Volumes. layout=layoutdef Definiert das Layout des Plexes. Ein Plex kann ein nostripe,

stripe oder raid5 Layout besitzen. Nach der Erstellung eines Plexes können diesem die zuvor erstellten Subdisks zugeordnet werden. Dies geschieht mit dem Kommando vxsd. # vxsd

-g mydg -U gen assoc my-Volume 9-01 mysubdisk 9-01-1 mysubdisk 9-01-2

463


Die Optionen und Argumente des Kommandos bedeuten hier: -g diskgroupname Name der Veritas Disk Group. -U gen

Usage des Plexes. Hier wird eingestellt, ob der Plex lesbar (read only) oder generell (gen) verwendet werden kann.

assoc

Assoziiert dem nachfolgenden Volume die danach aufgeführten Subdisks.

my-Volume 9-01 Name des Volumes. mysubdisk n-n-n Genaue Bezeichnung der Subdisk.

7.7.5

Erzeugung eines Volumes

Ein Volume wird wiederum mit dem Kommando vxmake aus einem Plex oder mehreren Plexes erzeugt. # vxmake

-g mydg -U gen vol my-Volume plex=my-Volume 9-01, my-Volume 9-02

Die Optionen und Argumente des Kommandos bedeuten hier: -g diskgroupname Name der Veritas Disk Group. -U gen

Usage des Volumes. Hier wird eingestellt, ob das Volume lesbar (read only) oder generell (gen) verwendet werden kann.

vol

Es soll ein Volume angelegt werden.

my-Volume

Name des Volumes.

my-Volume n-nn Name der Plexes, aus denen das Volume bestehen soll.

Nachdem es angelegt wurde wird das Volume mit dem Kommando vxvol gestartet und initialisiert. # vxvol -g mydg -U gen start my-Volume

Die Optionen und Argumente des Kommandos bedeuten hier: -g diskgroupname Name der Veritas Disk Group.

464

-U gen

Usage des Volumes. Hier wird eingestellt, ob das Volume lesbar (read only) oder generell (gen) verwendet werden kann.

start

Das Volume soll gestartet werden. Mit stop kann es gestoppt werden.

my-Volume

Name des Volumes.


7.7.6


Auch Veritas Filesysteme werden mit dem Standard-Unix-Kommando mkfs angelegt. # mkfs -F vxfs

legt ein Dateisystem auf einer raw partition an. Die Option -F vxfs legt ein Filesystem vom Typ des VxFS Veritas File System an. Die Partition, auf der das Filesystem angelegt wird, kann auch eine Nicht-VxVM-Partition sein. Die für Veritas Filesysteme relevanten Parameter des Kommandos mkfs sind: version =[2|3|4]

Veritas File System Version

inosize =[256|512]

Größe eines inode Bereiches für das Filesystem.

bsize = [1024|2048|4096|8192]

Blocksize des Filesystems.

Die Standardeinstellung für die Blockgrößen betragen: 1024

Für Filesysteme, deren Größe weniger als acht GB beträgt.

2048

Für Filesysteme, deren Größe weniger als 16 GB beträgt.

4096

Für Filesysteme, deren Größe weniger als 32 GB beträgt. Größe der Logging Area für das Journaling des Filesystems in Anzahl von Filesystem-Blöcken.

logsize = [32 – 16384]

Die Standardeinstellung für die Logging-Größen betragen: 512 Blöcke

Für Filesysteme, deren Größe weniger als 512 MB beträgt.

1024 Blöcke

Für Filesysteme, deren Größe mehr als 512 MB beträgt.

7.7.7

Veritas Volume-Manager: Übersicht der Kommandos

Folgende Abbildungen stellen eine Übersicht über die Kommandos des Veritas Volume-Manager (VxVM) dar. Diese sind gegliedert in: 왘 Kommandos für Disk Group-Operationen. 왘 Kommandos für Disk-Operationen. 왘 Kommandos für Subdisk-Operationen. 왘 Kommandos für Plex-Operationen. 왘 Kommandos für Volume-Operationen.

465


7.7.8

Kommandos für Disk Groups Operationen

Disk Groups Operationen manipulieren die Disk Groups unter VxVM. Sie entsprechen den Device-Gruppen-Operationen der Storage Array-BetriebsSoftware. Abbildung 7.27 fasst die Disk Groups-Operationen zusammen. Abbildung 7.27: VxVM Disk Groups Operationen

Op e ra tio n

• Erstellen einer Disk-Gruppe • Hinzufügen einer Disk zu einer existierenden Disk-Gruppe • Deportieren einer Disk-Gruppe • Umbenennen einer Disk-Gruppe

vxd g -Ko m m a n d o, Aktio n init adddisk deport deport gefolgt von import free

• Anzeige des freien Plattenplatzes einer Disk-Gruppe • Importieren einer Disk-Gruppe import • Anzeige der importierten Disk-Gruppen list • Ersetzen der Minor Numbers der reminor Disk-Gruppe • Ersetzen einer Platte aus der Disk-Gruppe repldisk • Entfernen einer Platte aus der Disk-Gruppe rmdisk • Anzeige von Platz auf Spare Devices spare

7.7.9

Kommandos für Disk Operationen

Disk Operationen manipulieren die einzelnen Disks in den Disk Groups. Die Disks entsprechen den Splits oder Devices des Storage Arrays, die den Device-Gruppen des Storage Arrays zugeordnet werden. Abbildung 7.28: VxVM Disk Operationen

Op e ra tio n

• Hinzufügen einer Platte

vxd is k -Ko m m a n d o, Aktio n, we ite re Ko m m a n d o s

vxdisk add ode r vxdisk init ode r vxdisk adm ode r vxdisk setup vxdg rmdisk

• Löschen einer Disk aus ihrer Disk-Gruppe • Entfernen der Platte aus der rm Kontrolle von VM • Einbinden existierender Daten define (type= • Anzeige der Platteninformationen list

466

nopriv )


7.7.10 Kommandos für Subdisk-Operationen Subdisk Operationen manipulieren die Subdisks einer VxVM Platte.

Op e ra tio n

• Auftrennen einer Subdisk in mehrere Subdisks • Zusammenführen mehrerer Subdisks zu einer Subdisk • Hinzufügen einer Subdisk zu einem Plex • Löschen einer Subdisk Platz wird als frei gekennzeichnet • Hinzufügen einer DRL-Subdisk zu einem Plex (Dynamic Relocatable Log) • Kopieren des Inhalts einer Subdisk auf eine andere

vxs d -Ko m m a n d o, Aktio n

Abbildung 7.29: VxVM SubdiskOperationen

split join assoc dis ASLOG mv

7.7.11 Kommandos für Plex-Operationen Op e ra tio n

• (Wieder-) Zuordnung eines Plexes zu einem Volume • Temporäres Entfernen eines Plexes aus einem Volume • Permanentes Entfernen eines Plexes aus einem Volume • Kopieren eines Plexes • Zuordnung eines Plexes zu einem Volume, um einen Snapshot zu erzeugen • Entfernen eines Snapshot-Plexes aus einem Volume • Kopieren eines Plexes mit nachfolgendem Austausch des Plexes durch ein anderes

vxp le x -Ko m m a n d o, Aktio n

Abbildung 7.30: VxVM PlexOperationen

att det dis cp snapstart snapshot mv

467


7.7.12 Volume-Operationen Abbildung 7.31: VxVM VolumeOperationen

Op e ra tio n

vxvo l -Ko m m a n d o, Aktio n

• Initialisierung eines Volumes • Start eines Volumes • Stopp eines Volumes • Start sämtlicher verfügbarer Volumes • Stopp sämtlicher aktiver Volumes • Wiederherstellung der Daten des Volumes • Resynchronisierung der Plexes • Entfernen eines Volumes zur Minimierung der User • Ändern des Leseverhaltens des Volumes • Ändern der Volume-Charakteristika

init start stop startall stopall recover resync maint rdpol set

7.7.13 Dateisysteme und flexible/remote mirrors unter Veritas Unter Veritas Volume-Manager kann das Konzept der flexible Mirrors wie beschrieben umgesetzt und realisiert werden. Auch hier können BCV Devices (EMC2) für konkurrierende Prozesse genutzt werden.

7.7.14 VxVM und flexible Mirrors in einer DualServer-Umgebung Bei der Nutzung der flexible Mirrors für einen konkurrierenden Prozess auf einem anderem Host als dem, von dem die Standard-Devices verwendet werden, müssen keinerlei Besonderheiten beachtet werden. 왘 Werden Standard- und BCV-Datenträger mit symmir split voneinander

getrennt, so kann ein zweiter Server (VxVM Server 2) das BCV-Volume einfach durch Importieren der Daten verwenden. Beim Importieren einer Volume-Gruppe auf flexible Mirrors durch den VxVM Server 2 kann dieser Volume-Gruppe der gleiche Name oder auch ein anderer Name zugewiesen werden, als ihn die Volume-Gruppe auf den Standard-Devices besitzt. Dennoch werden natürlich durch die Verwendung des TimeFinder symmir-Kommandos auch die VGRAs der Laufwerke auf das BCV geschrieben.

468


VxVM-Server 1

F C H B A

F C H B A

VxVM-Server 2 RW-Enabled

Abbildung 7.32: VxVM flexible Mirrors in einer Dual-ServerUmgebung

F C H B A

F C H B A

RW-Enabled

PVRA VGRA

PVRA VGRA

Standard-Device


왘 Wurde auf dem VxVM Server 1 eine Mapdatei erzeugt, so kann diese auf

dem VxVM Server 2 beim Importieren der Volume-Gruppe verwendet werden. Die logischen Volumes bekommen dann die gleichen Namen wie auf VxVM Server 1. Ohne Verwendung einer Mapdatei werden die logischen Volumes bei 0 beginnend aufsteigend nummeriert (vol0, vol1 usw.). 왘 Es gibt keinen Konflikt wegen der gleichen Inhalte in den reservierten


Aktionen nutzen, die mit flexible Mirrors durchgeführt werden können. Das Vorgehen bei der Operation auf zwei Servern ist wie folgt: Volume-Gruppen oder Striping Informationen werden beim Kopieren auf flexible Mirror oder remote Mirror mit kopiert. Sollen nun BCVs zur Unterstützung konkurrierender Prozesse oder auch remote Mirrors zur Implementierung eines Disaster Recovery Clusters eingeführt werden, so ist auch im Katastrophenfall eine Restaurierung dieser Informationen nicht notwendig, da sich die Daten inklusive der Volume-Gruppen und Striping Informationen auf dem flexible oder remote Mirror befinden. Abbildung 7.33 skizziert die Reihenfolge der Schritte, die zur Nutzung der flexible oder remote Mirrors zum Kopieren der Daten eingehalten werden muss.

469

7 SAN und NAS – Unterstützte File-Systeme Abbildung 7.33: VxVM Datenkopie mit flexible Mirror in einer DualServer-Umgebung

VxVM-Server 1

FC H B A

VxVM-Server 2

FC H B A

FC H B A



FC H B A

Establish starten 2

Anwendungen stoppen

1 Dateisysteme unmounten Volume-Gruppen deportieren

3 Anwendungen stoppen, Dateisysteme unmounten, VolumeGruppen deportieren


Volume-Gruppen importieren Dateisysteme mounten Anwendungen starten

Volume-Gruppen importieren, Dateisysteme mounten, Anwendungen starten

Die Abbildung geht davon aus, dass die Daten bereits einmal von den Standard-Devices des VxVM Servers 1 auf flexible Mirror Devices (VxVM Server 1 und konkurrierender Prozess auf VxVM Server 2) oder remote Mirrors auf VxVM Server 2 synchronisiert wurden und dann von VxVM Server 1 getrennt wurden (vgl. Kapitel 6). Unabhängig davon, ob es sich um einen flexible oder remote Mirror handelt, laufen im Ausgangszustand die Anwendungen des VxVM Servers 2 auf den Mirror Devices, die sich aus Sicht des VxVM Servers 1 im Zustand split befinden. Für eine erneute Kopie der Daten des VxVM Servers 1 sind nun folgende Schritte einzuhalten. 1. Auf VxVM Server 2 müssen die Anwendungen gestoppt, die Dateisysteme auf den Devices aus dem Filesystem mit umount entfernt sowie die betreffenden Volume-Gruppen exportiert werden. 2. Von VxVM Server 1 aus wird die Resynchronisation der Mirror Devices gestartet. Dieser establish erfolgt unabhängig davon, ob es sich um einen flexible Mirror (TimeFinder BCV mit dem Kommando symmir establish) oder um einen remote Mirror (SRDF R2 Device mit dem Kommando symrdf establish) handelt.4 3. Sobald der Device Status SYNCHRONIZED erreicht ist, müssen auf VxVM Server 1 die Anwendungen gestoppt, die Dateisysteme auf den Devices aus dem Filesystem mit umount entfernt sowie die betreffenden Volume-

4.

470



Gruppen exportiert werden. Der nachfolgende split der Mirror Devices (symmir split oder symrdf split) leert den Cache des Storage Arrays und gewährleistet den konsistenten Zustand der Daten auf den Mirror Devices. 4. Die Anwendungen des VxVM Servers 1 können auf den StandardDevices gestartet werden, nachdem die Volume-Gruppen wieder importiert und die Dateisysteme mit mount ins Filesystem eingehängt wurden. 5. Auf VxVM Server 2 werden die Volume-Gruppen importiert und aktiviert, die Dateisysteme mit mount ins Filesystem eingehängt und danach die Applikationen der konkurrierenden Prozesse wieder gestartet. Die Produktion des VxVM Servers 2 ist damit wieder gestartet. Standard-Devices, deren Daten mit flexible Mirrors oder remote Mirrors kopiert wurden, können von diesen Mirror Devices auch wiederhergestellt werden. Dazu sind folgende Schritte auszuführen. 1. Seien die Standard-Devices auf VxVM Server 1 defekt und müssen von den getrennten flexible oder remote Mirrors, auf denen die Produktion des VxVM Servers zwei läuft, wiederhergestellt werden. Dazu müssen zunächst auf Vx Server 2 die Anwendungen gestoppt und die Dateisysteme auf den Devices aus dem Filesystem mit umount entfernt sowie die betreffenden Volume-Gruppen deportiert werden. 2. Auf VxVM Server 1 müssen ebenfalls die Anwendungen gestoppt und die Dateisysteme auf den Devices aus dem Filesystem mit umount entfernt sowie die betreffenden Volume-Gruppen deportiert werden. VxVM Server 1 startet danach den Restore seiner Standard-Devices vom BCV flexible Mirror oder R2 remote Mirror (symmir restore oder symrdf restore). 3. Sobald der Restore der Standard-Devices angelaufen ist, wird eine deportierte Volume-Gruppe wieder importiert. Danach werden die Dateisysteme der Volume-Gruppe mit mount ins Filesystem von VxVM Server 1 eingehängt und die Anwendungen gestartet, sodass die Standard-Devices wieder zur Produktion des VxVM Servers 1 eingesetzt werden. Soll der Zustand vor dem Restore wiederhergestellt werden, muss nun der Status RESTORED abgewartet werden und mit Punkt 3 des des oben beschriebenen Kopieren von Daten mit flexible/remote Mirror in einer Dual-Server-Umgebung fortgefahren werden. Dabei sei darauf hingewiesen, dass der Restore von remote oder flexible Mirror eine erhebliche Reduktion der ungeplanten Ausfallzeit im Vergleich zum Restore von Band-Datensicherungen bietet. Dies ist deshalb der Fall, da mit der Produktion auf VxVM Server 1 bereits direkt nach Anlaufen des Restore begonnen werden kann, also noch bevor alle Daten von den BCVs oder den R2 Devices auf die Standard-Devices rückkopiert wurden. Dabei ist darauf zu achten, dass – falls die BCVs oder die remote Mirrors nicht durch ei-

471


nen jeweiligen lokalen Mirror zusätzlich abgesichert sind – ein Verlust dieser Devices während der Restore Operation nur durch eine vorhandene Bandsicherung behoben werden kann. Bei SRDF remote Mirrors muss zusätzlich beachtet werden, dass die Produktion mit einer reduzierten Bandbreite läuft, solange nicht alle Daten kopiert sind, also mit einem schlechteren Laufzeitverhalten zu rechnen ist. Abbildung 7.34: VxVM Datenwiederherstellung mit flexible Mirrors in einer Dual-ServerUmgebung

VxVM-Server 1

FC H B A

VxVM-Server 2

FC H B A


Anwendungen stoppen Dateisysteme unmounten Volume-Gruppen deportieren

1

FC H B A

FC H B A


2 Restore starten 3 Volume-Gruppen importieren Dateisysteme mounten Anwendungen starten

7.7.15 VxVM-Dateisysteme und flexible Mirrors in einer Single-Server-Umgebung Ist nur ein Server vorhanden, über dessen Standard-Devices flexible Mirrors synchronisiert werden, getrennt werden, und dann durch Importieren der Volume-Gruppe auf dem selben Server einem konkurrierenden Prozess zur Verfügung gestellt werden, dann muss die Group ID der importierten Volume-Gruppe geändert werden. Ansonsten kann es zu schwerwiegenden Naming-Konflikten und zu Problemen bei der I/O-Platzierung kommen. Abbildung 7.36 zeigt den Ablauf der Erzeugung von Datenkopien mithilfe von flexible Mirrors oder remote Mirrors im Single Server-Fall. Dabei lässt sich über den Sinn von remote Mirrors in einem Single Server-Fall trefflich streiten, dennoch bietet der remote Mirror auch hier eine weitere Ebene des Schutzes vor Verlust der Devices. Er sichert auch im Single-Server-Umfeld vor dem Verlust des primären Storage Arrays. Bezüglich der Anwendungsschritte unterscheidet sich der Single-Server-Fall jedoch schon von einer Dual-Server-Konfiguration.

472


VxVM-Server 1

Abbildung 7.35: VxVM und flexible Mirrors in einer Single-ServerUmgebung

F C H B A

F C H B A

RW-Enabled

RW-Enabled

PVRA VGRA

PVRA VGRA

Standard-Device


Die Abbildung geht davon aus, dass die Daten bereits einmal von den Standard-Devices des VxVM Servers 1 auf flexible Mirror Devices (ebenfalls VxVM Server 1, evtl. konkurrierender Prozess auf VxVM Server 1) oder remote Mirrors, die ebenfalls über VxVM Server 1 erreicht werden können, synchronisiert wurden und dann von VxVM Server 1 getrennt wurden (vgl. Kapitel 6). Unabhängig davon, ob es sich um einen flexible oder remote Mirror handelt, laufen im Ausgangszustand konkurrierende Anwendungen des VxVM Servers 1 auf den Mirror Devices, die sich aus Sicht der StandardDevices des VxVM Servers 1 im Zustand split befinden. Für eine erneute Kopie der Daten der Standard-Devices auf die flexible oder remote Mirrors sind nun folgende Schritte einzuhalten. 1. Auf VxVM Server 1 müssen die Anwendungen der konkurrierenden Prozesse gestoppt, die Dateisysteme mit umount aus dem Filesystem des Servers entfernt sowie die Volume-Gruppen deportiert werden. 2. Von VxVM Server 1 aus wird die Resynchronisation der Mirror Devices gestartet. Dieser establish erfolgt unabhängig davon, ob es sich um einen flexible Mirror (TimeFinder BCV mit dem Kommando symmir establish) oder um einen remote Mirror (SRDF R2 Device mit dem Kommando symrdf establish) handelt.

473

7 SAN und NAS – Unterstützte File-Systeme Abbildung 7.36: VxVM Datenkopie auf flexible Mirror in einer SingleServer-Umgebung


VxVM-Server 1

Symmetrix Storage Array Warten auf den Zustand »synchronized«

FC H B A


FC H B A


Establish starten 2

1


3 Anwendungen stoppen, Dateisysteme unmounten, VolumeGruppen deportieren

Split durchführen 4

Volume-Gruppen importieren, Dateisysteme mounten, Anwendungen starten

5

Ändern der Group-ID Volume-Gruppen importieren Dateisysteme mounten Anwendungen starten

3. Sobald der Device Status SYNCHRONIZED erreicht ist, müssen auf VxVM Server 1 die Standard-Anwendungen auf den Standard-Devices gestoppt, die Dateisysteme mit umount aus dem Filesystem des Servers entfernt sowie die Volume-Gruppen deportiert werden. 4. Die Standard-Anwendungen des VxVM Servers 1 können auf den Standard-Devices wieder gestartet werden, nachdem die Volume-Gruppen wieder importiert und die Dateisysteme mit mount in das Filesystem des Servers eingehängt wurden. 5. Auf VxVM Server 1 wird danach auf den Mirror Devices die Group-ID der auf ihnen befindlichen Volume-Gruppen geändert, die VolumeGruppen werden importiert. Die Dateisysteme der Volume-Gruppen werden mit mount in das Filesystem des Servers eingehängt. Danach können die Anwendungen der konkurrierenden Prozesse auf VxVM Server 1 gestartet und wieder zur Produktion eingesetzt werden. Auch im Single Server-Fall können Standard-Devices, deren Daten mit flexible Mirrors oder remote Mirrors kopiert wurden, von diesen Mirror Devices wiederhergestellt werden. Dazu sind folgende Schritte durchzuführen. 1. Seien die Standard-Devices auf VxVM Server 1 defekt und müssen von den getrennten flexible oder remote Mirrors, auf denen die Produktion der konkurrienden Prozesse des VxVM Servers 1 läuft, wiederhergestellt werden. Dazu müssen zunächst auf VxVM Server 1 die Anwendungen der konkurrierenden Prozesse auf den Mirror Devices gestoppt, die Dateisysteme mit umount aus dem Filesystem des Servers entfernt sowie

474


die Volume-Gruppen deportiert werden. Weiter müssen die Anwendungen der Standard Prozesse auf den Mirror Devices gestoppt, die Dateisysteme mit umount aus dem Filesystem des Servers entfernt sowie die Volume-Gruppen deportiert werden. 2. VxVM Server 1 startet dann den Restore seiner Standard-Devices vom BCV flexible Mirror oder R2 remote Mirror (symmir restore oder symrdf restore). 3. Sobald der Restore der Standard-Devices angelaufen ist werden die Volume-Gruppen wieder importiert und die Dateisysteme mit mount in das Filesystem des Servers wieder eingehängt. Danach können die Applikationen der Standard-Prozesse auf VxVM Server 1 gestartet und wieder zur primären Produktion eingesetzt werden. Soll der Zustand vor dem Restore wiederhergestellt werden, muss nun der Status RESTORED abgewartet werden und mit Punkt 3 des Kopieren von Daten mit flexible/remote Mirror in einer Single-Server-Umgebung fortgefahren werden.


VxVM-Server 1

FC H B A

FC H B A

Symmetrix Storage Array Anwendungen stoppen Dateisysteme unmounten Volume-Gruppen deportieren


Abbildung 7.37: VxVM Datenwiederherstellung von flexible Mirror in einer Single-ServerUmgebung


1


2 Restore starten 3 Volume-Gruppen importieren Dateisysteme mounten Anwendungen starten

475


7.8

EMC2s TimeFinder Toolkit (VRTSvxtf) – TimeFinderIntegration in Veritas VolumeManager

Mit dem EMC2s TimeFinder Toolkit (VRTSvxtf) wird die Integration der flexible Mirror Softwarelösung von EMC2 in VxVM betrieben. Dies hat im Wesentlichen folgende Auswirkungen: 왘 Das Management der flexible Mirror BCV Devices durch das CLI des

VxVM Volume-Managers wird stark erleichtert. 왘 Das Mapping zwischen den Device-Gruppen des Storage Arrays und

den Disk Groups wird erleichtert, da VRTSvxtf mit den Disk Groups als einer administrierbaren Einheit arbeitet. 왘 Verringert das Risiko, beim Split der Device-Gruppe nur eine Teilmenge

einer Disk Group zu splitten. 왘 Das VxFS Filesystem sowie jedes andere Filesystem auf den Disk Groups

wird während der Verarbeitung eingefroren und nach dem Split der BCVs wieder aktiviert. 왘 Vereinfacht die gleichzeitige Verwendung von Standard- und BCV De-

vices am selben Host in einer Single-Server-Umgebung. Ohne Einsatz des TimeFinder Toolkits kommt es bei der Verwendung der flexible Mirror BCVs zu den bereits oben im Abschnitt VxVM-Dateisysteme und flexible Mirrors in einer Single-Server-Umgebung dargestellten Verhaltensweisen der BCVs: 왘 Nach dem Split enthält das BCV eine Kopie auch der Private Area, mit

identischer Disk-ID und identischem Disk Groups-Namen wie sein Standard-Device. 왘 Der Versuch dieses flexible Mirror BCV am gleichen Server unter VxVM

Volume-Manager Kontrolle zu bringen, führt zu einem Konflikt. Mit Einsatz des TimeFinder Toolkits sieht das Verfahren wie folgt aus: 왘 Während das BCV Device beim Split von seinem Standard-Device ge-

trennt wird, ändert das TimeFinder Toolkit die Private Area des BCV Devices. 왘 Zusätzlich wird eine neue Disk Group mit dem Präfix bcv generiert, die

am gleichen Host mit dem mount Befehl in das Filesystem des Servers eingehängt und genutzt werden kann.

476

EMC2s TimeFinder Toolkit (VRTSvxtf) – TimeFinder-Integration in Veritas Volume-Manager

Lautet der Disk Groups-Name der Disk Group für die Standard-Devices beispielsweise myoracledatadg und sind zu der entsprechenden DeviceGruppe des Storage Arrays flexible Mirror BCVs z.B. für die konsistente Datensicherung assoziiert, so lautet bei Benutzung des TimeFinder Toolkits der Name der BCV Disk Group bcvmyoracledatadg. Das Verhalten der BCVs wird durch das TimeFinder Toolkit Kommando vxsymsplit determiniert. # vxsymsplit -F vxfs -g vxvm-dg-name

Dabei haben die Optionen und Argumente des Kommandos folgende Bedeutung: -F vxfs

Friert das eingegebene Filesystem vor der TimeFinder Split-Operation ein.

-g Disk Groups Name

Name der Disk Group, deren BCVs der StandardDevice-Gruppe von ihren Standard-Devices getrennt werden sollen.

Während das BCV Device beim Split von seinem Standard-Device getrennt wird, ändert das TimeFinder Toolkit die Private Area des BCV Devices. Zusätzlich wird eine neue Disk Group mit dem Präfix bcv generiert, die am gleichen Host mit dem mount Befehl in das Filesystem des Servers eingehängt und genutzt wird. Abbildung 7.38 zeigt die wesentlichen Kommandos der TimeFinder Toolkit Erweiterung für VxVM.

EMC2 BCV bcv setup bcv establish bcv query bcv split bcv establish bcv restore

EMC2 SymCli

VERITAS TFToolkit

symld/symdg/symbcv symmir -full establish symmir query symmir split symmir establish symmir restore symld/symdg/symbcv

vxsymsetup attach vxsymmir vxsymquery vxsymsplit vxsymremir vxsymrestore vxmsymsetup detach

Abbildung 7.38: VxVM TimeFinder Toolkit-Kommandos

477

8

Administration unternehmensweiter Speichernetzwerke

Nachdem in den vorigen Kapiteln dargestellt wurde, wie Server für hochverfügbare-Umgebungen mithilfe von Cluster-Software und Storage Arrays mithilfe von Speicher-Software implementiert werden soll letztendlich das Augenmerk auf die Administration der Speicher-Landschaft gerichtet werden. Auch hier wird die einzusetzende Software aus den in Kapitel sechs bereits genannten Gründen auf die Produktfamilie aMulti-Switchus dem Hause EMC2 beschränkt, anhand derer jedoch die Administration der Komponenten des Speichernetzwerks abgearbeitet werden soll. Betrachten wir nochmals ein Speichernetzwerk, so besteht dieses aus den zu administrierenden Komponenten 왘 Server, Cluster, Mainframes etc. 왘 Kommunikationsnetzwerke 왘 Storage Arrays 왘 Switches 왘 NAS-Server.

Abbildung 8.1: Unternehmensweites Speichernetzwerk

Unternehmen KommunikationsNetzwerke

Datenbank- und Applikationsserver, Mainframes

Fileserver

NAS-Server

Switch

Unternehmensweites SpeicherNetzwerk

Storage Array

479

8 Administration unternehmensweiter Speichernetzwerke

Während die ersten beiden Komponenten èn detail in diversen Publikationen bereits diskutiert wurden – aus diesem Grunde sei auch auf die entsprechende Literatur verwiesen – soll die Administration der letzten drei Komponenten in diesem Abschnitt dargestellt werden.

8.1

Die Administration von Storage Arrays

Die Administration der Storage Arrays beinhaltet ihre Einrichtung, die in Grundzügen bereits in Kapitel sechs dieses Buches dargestellt wurde, sowie die Automatisierung und Überwachung des laufenden Betriebes. Dabei ist es vollkommen unerheblich, ob von einem Administrationsarbeitsplatz ein Storage Array oder mehrere 100 innerhalb des SANs eines Unternehmens administriert werden müssen. Die Aktionen und die verfügbare Administrations-Software sind für beide Fälle identisch. Je nach Installationsverfahren kann mit der Administrations-Software ein Storage Array, das komplette SAN innerhalb eines privaten Netzwerkes oder das komplette SAN über eine Web-Schnittstelle administriert werden. Mit einer Three-Tier-Installation ist letztere Form der Administration erreichbar. Diese stellt das Maximum derzeitig denkbaren Administrationskomforts dar. Abbildung 8.2: Three-TierAdministrationsarchitektur

Storage Array

Installiert:

Agent

Admin-Agent

Direct Attachement Unix oder WIN NT

Netzwerk

Host 1

Clients WINNT

Intranet

Server

Host 2 Installiert: Webserver-Komponenten

WIN NT Windows 95/98 Windows 2000

480

Administrator, Console wird über Webbrowser geladen


Eine solche dreistufige Installation arbeitet in der Regel mit einem Java-basierenden Client und einem RPC Protokoll (Remote Procedure Call). Die Clients rufen einen Browser auf und stellen die Verbindung zum AdministrationsServer her. Die benötigte Software wird dann von dort heruntergeladen. Auf den Clients kann die gesamte Struktur des SAN gesehen und administriert werden, angefangen von den Storage Arrays über Fibre Channel-Hubs und Switches bis zu den Servern, die über FC-AL oder FC-SW an die Storage Arrays angeschlossen sind. Seitens EMC2 stellt das EMC ControlCenter (ECC) eine solche Storage Array Administrations-Suite dar.

8.1.1

Einführung in das ECC

Das EMC ControlCenter (ECC) stellt eine modulare Anwendungs-Software für ein unternehmensweites Speichernetzwerk dar, mithilfe derer sämtliche Komponenten des Speichernetzwerkes administriert werden können. In einer Three-Tier-Architektur installiert, bietet es die Administration des kompletten Speichernetzwerkes von einem Arbeitsplatz. Abbildung 8.3: Administration eines Speichernetzwerkes – Das EMC ControlCenter

.

EMC ControlCenter

Symmetrix

ISV

Bspw. Patrol

ESN

Volume Logix

PowerPath

EFC-Manager

SymCLI

Resource Availability

Resource View

Optimizer

Analyzer

Data Base Tuner

Disk Reallocation

SRDF/TF-Manager

ISV

Bspw. TIVOLI

ESN-Manager

Manager

Dabei bietet das ECC folgende Hauptmodule: 왘 Der (Open) Symmetrix Manager dient der Konfiguration und Administra-

tion der Symmetrix Storage Arrays innerhalb des SAN. Hierbei kann die Steuerung der Operationen mit remote Mirrors im Disaster Recovery-

481


Szenario und der BCV Business Continuance Volumes flexible Mirrors mit dem SRDF/TimeFinder Manager erfolgen. Weiter können benutzergesteuert unabhängig von der Firmware und den binären Konfigurationsdaten des Storage Arrays mit der Disk Reallocation (SDDR) Devices im Back-End des Storage Arrays auf andere Disk-Adapter verschoben werden, um so benutzergesteuert die kapazitative Auslastung der DiskAdapter zu steuern. Der Data Base Tuner des Symmetrix Managers erlaubt das Performance Monitoring und Tuning von Oracle Datenbanken bis auf die Ebene der physikalischen Devices, der Analyzer analysiert die Auslastung des Storage Arrays und der Optimizer optimiert die Deviceauslastung nach vorheriger Analyse über einen längeren Zeitraum. 왘 Resource View stellt den kompletten Pfad der Daten dar – vom Host-File-

system bis hin zu den Devices in der Symmetrix, auf denen diese Filesysteme physikalisch liegen. 왘 Resource Availability erlaubt die Administration der Resourcen aus dem

ECC heraus, entweder aus Filesystem/Server-bezogener Sicht, oder aus Sicht der Deviceallokation im Symmetrix Storage Array. Abbildung 8.4: EMC ControlCenter Module*

Überwachen

• EMC ControlCenter – Überwachung von Symmetrix, Hubs/Switches

• Resource View – Abbildung Host-Daten Speicher

• Resource Availability Konfigu rieren

– Management von SpeicherRessourcen

• SRDF/TimeFinder-Manager – Steuerung von SRDF/TimeFinder

• Symmetrix Disk Reallocation – Speicherkonfiguration

• Volume Logix – Zugangskontrolle zu logischen Datenträgern

Optimieren

• Symmetrix Optimizer – Automatische Leistungsoptimierung

• EMC PowerPath – Management von I/O-Pfaden

• Symmetrix Database Tuner – Optimierung von OracleDatenbanken

• Workload Analyzer Planen

– Leistungsmessung und

Analyse

* Nach EMC-Schulungsunterlage SymCLI Basics, München 1999, 2000. 왘 Der SymCLI ist das Command Line Interface zu den oben beschriebenen

Funktionen des Symmetrix Managers. 왘 Der ESN-Manager erlaubt die Überwachung, Konfiguration und Admi-

nistration der Verbindungskomponenten des SAN.

482

Die Administration von Storage Arrays 왘 Die für Independent Software Vendors (ISV) freigegebene API-Schnittstelle

zum ECC erlaubt die Integration des EMC ControlCenters in Administrations-Suiten wie Tivoli von IBM, Patrol von BMC oder OpenView von Hewlett-Packard etc. Die Module des ECC lassen sich nach ihrer Funktion in folgende Gruppierungen gliedern: 왘 Werkzeuge zur Überwachung des SAN 왘 Werkzeuge zur SAN-Konfiguration 왘 Werkzeuge zur SAN-Leistungsoptimierung 왘 Werkzeuge zur Planung der SAN-Entwicklung

• Erfüllung von Anforderungen bezüglich • Verfügbarkeit • Leistung

• Anzeige der Konfiguration • Topologie »Welcher Server ist über welchen Switch mit welchem Storage Array verbunden?« • Abbildung von Komponenten (Switch, Storage Array)

EMC ControlCenter Monitor Symmetrix, Hubs/Switches Resource View Map Host Data to Storage Resource Availability Host Logical Storage Management

Abbildung 8.5: ECC Monitoring Tools*

• Erzeugen von Event/Alarm Notifications bezüglich • Komponenten-Status • Leistung der Komponenten • Weiterleitung zu Management-Software * Nach EMC-Schulungsunterlage SymCLI Basics, München 1999, 2000.

8.1.1.1

Werkzeuge zur Überwachung des SANs

Folgende Komponenten des ECC dienen der Überwachung des unternehmensweiten Speichernetzwerkes: 왘 Das EMC ControlCenter ist die Grundlage für ein zentrales Management

sämtlicher Komponenten eines EMC2-SANs. Es bietet die Möglichkeit, die Struktur des unternehmensweiten Speichernetzwerkes zu überblicken und liefert die Zustands-Informationen der einzelnen Komponenten, also der Storage Arrays, Server und Switches. Bestandteil des ECC

483


ist auch der (Open) Symmetrix Manager, der Informationen über die Konfiguration und Leistung der hochverfügbaren Symmetrix Storage Arrays liefert. 왘 Das Modul Resource View liefert die Abbildung und das Matching der

Host-Datenstrukturen (Datenbanken, Dateisysteme, Volume-Gruppen respektive Disk Groups) auf die logischen und physikalischen Datenträger in dem Symmetrix Storage Array. Resource View liefert damit einen Überblick über die Benutzung aller Speicher-Ressourcen innerhalb des SAN. Abbildung 8.6: ECC Konfigurations- und SteuerungsModule*

• Unterhaltung einer flexiblen SpeicherInfrastruktur • Zuteilung von Ressourcen an Server und Directors • Zugangssteuerung für Server-Konsolidierungen • Steuerung von Flexible und Remote Mirror Devices

SRDF/TimeFinder-Manager Control SRDF/TimeFinder Symmetrix Disk Reallocation Configure „just-in-time” Storage Volume Logix Control Logical-Volume Access

* Nach EMC-Schulungsunterlage SymCLI Basics, München 1999, 2000. 왘 Das Modul Resource Availability bietet die Möglichkeit des Manage-

ments der Speicher-Ressourcen innerhalb des SANs. Ereignisse werden gemeldet (Event Alerts), bevor sie zu Problemen werden. So können z.B. Thresholds für ein Dateisystem eingerichtet werden, die melden, wenn der freie Speicher zu knapp wird. Es gibt auch die Möglichkeit der automatischen Korrektur, d.h. für das vorige Beispiel, dass die ThresholdÜberschreitung nicht allein zu einer Fehlermeldung führt, sondern auch automatisch der Speicher für das Dateisystem erweitert und das Filesystem auf den neuen Speicher erweitert werden kann.

484


8.1.1.2

Werkzeuge zur Konfiguration und Steuerung des SANs

Die Werkzeuge zur Konfiguration und Steuerung des SANs dienen den gleichen Funktionen, wie die bereits im Kapitel sechs dargestellten SymCLIKommandos. Hier werden diese nur durch ein benutzerfreundliches GUI unterstützt, das die Aufgaben auch für mehrere Storage Arrays und Switches durchführbar macht. 왘 Der SRDF/TimeFinder Manager beziehungsweise der EMC Solution Enab-

ler SymCLI mit der Base Component, der TimeFinder Component und der SRDF Component ermöglichen die Konfiguration und administrative Steuerung der TimeFinder BCV flexible Mirrors und der SRDF remote Mirror Devices. 왘 Die Symmetrix (Dynamic) Disk Reallocation (SDDR) unterstützt die Zutei-

lung von Device-Ressourcen zu Anwendungen dann, wenn diese benötigt werden. SDDR bietet dem Benutzer die Möglichkeit, bis zu 32 Symmetrix Storage Array Devices frei an frei wählbare Disk Directors des Back-Ends der Symmetrix zu verschieben, ohne eine Änderung der binären Konfigurationsdatei durch EMC2 zu bedürfen. 왘 Das Volume Logix-Modul ermöglicht den Schutz der Daten, die auf vielen

verschiedenen Datenträgern in der Symmetrix liegen. Nur diejenigen Hosts können auf die Daten zugreifen, denen die Erlaubnis dazu erteilt wurde. Mit Volume Logix wird das Werkzeug beschrieben, mithilfe dessen sichergestellt werden kann, dass in Serverkonsolidierungs-Topologien nicht jeder Server sämtliche Devices im Symmetrix Storage Array sehen kann, die auf den internen Bussen des Storage Arrays sichtbar sind, an die der Channel Director verbunden ist, über den den Server auf das Storage Array zugreifen.

8.1.1.3

Werkzeuge zur Optimierung des SANs

Unter den Werkzeuge zur Optimierung des SANs werden sämtliche Werkzeuge zusammengefasst, die den Zugriff auf die Daten im Storage Array optimieren helfen. 왘 Der Symmetrix Optimizer automatisiert das Symmetrix-interne Tuning

der Datenträger. Der Symmetrix Optimizer sammelt über einen konfigurierbaren Zeitraum die Auslastungsdaten der logischen Datenträger (Devices) im Symmetrix Storage Array. Ausgehend von diesen Auslastungsdaten werden Devices zwischen den physikalischen Laufwerken verschoben, um die generelle Auslastung des Storage Arrays zu balancieren und zu verbessern. 왘 Das EMC PowerPath-Modul verbessert dadurch die Möglichkeit, auf Da-

ten in der Symmetrix zuzugreifen, dass mit PowerPath dynamisches Multipathing konfiguriert und administriert werden kann. Leistung und Verfügbarkeit der I/Os werden für die Serverapplikationen dadurch ge-

485


steigert, dass mehrere Host-Kanäle zum Storage Array für die I/Os verfügbar gemacht werden, die im Standardbetrieb über einen Algorithmus möglichst gleichmäßig genutzt werden und im Falle des Ausfalls einer der Kanäle die Devices auf dem Storage Array dennoch über die anderen konfigurierten Kanäle für I/Os verfügbar halten. Abbildung 8.7: ECC TuningModule*

•

Höchste Leistung bei gegebenem Aufwand

•

Wachsender Datenbestand

•

Werkzeuge zur Messung der Leistung

•

Werkzeuge zur Gewährleistung eines optimalen Zugangs zu den Daten

Symmetrix Optimizer Optimize Logical/Physical Disk Loading EMC PowerPath Enable I/O Path Management Symmetrix Database Tuner Optimize Oracle Database

* Nach EMC-Schulungsunterlage SymCLI Basics, München 1999, 2000. 왘 Der Symmetrix Database Tuner stellt ein Werkzeug zur Leistungsüberwa-

chung und zum Tuning von Oracle-Datenbanken dar. Hier wird ermöglicht, die Performance einer Oracle-Anwendung I/O-basiert bis auf die physikalische Speicherung auf einem Device des Storage Arrays zu monitoren. Gleichzeitig kann die Oracle Anwendung – in Kombination mit den übrigen Tools des ECC – über die reinen Oracle-Spezifika (init.ora Parameter etc.) hinaus, auch auf physikalischer Deviceebene durch z.B. Verlagerung eines Devices auf einen anderen Adapter (SDDR) getuned werden.

8.1.1.4

Werkzeuge zur Unterstützung der Planung des SANs

Eine der großen Herausforderungen eines SAN-Betriebes ist die antizipative Planung der zukünftigen Entwicklung des SAN. Wie wird sich der Deviceund Kanalbedarf der Server respektive ihrer Anwendungen in Zukunft entwickeln? Zur Beantwortung einer solchen Frage ist in komplexen Umgebun-

486

SAN-Monitoring mithilfe des ECC, Resource View und Resource Availability

gen, wie sie ein SAN zweifelsohne darstellt, ein Werkzeug notwendig, das zuverlässige Auslastungs- und Entwicklungsdaten über konfigurierbare Zeiträume zur Planungsunterstützung liefert.

•

KapazitätsAbschätzungen für die Zukunft

•

Trends erkennen, bevor Probleme auftauchen

• • • •

Probleme isolieren

•

Eingrenzung von Leistungsproblemen

Workload Analyzer Analyze Symmetrix Performance

Abbildung 8.8: ECC Planungsmodule*

Trend-Analyse Lastausgleich Kapazitäts-Analyse und -Planung

* Nach EMC-Schulungsunterlage SymCLI Basics, München 1999, 2000.

Der Workload Analyzer/Archiver (WLA) des ECC sammelt konfigurierbar die Leistungsdaten der Symmetrix Storage Arrays im SAN und stellt sie grafisch dar. Er kann für Trend-Analysen zur Planung der SAN-Entwicklung, aber auch zur Untersuchung aktueller Laufzeit-Probleme und deren Behebung verwendet werden.

8.2


8.2.1

ECC Monitoring Tools

Das EMC ControlCenter stellt für EMC2 das Herz der SAN-Administration dar. Diese wird bei EMC2 gerne als Informations-Management bezeichnet. Das ECC ermöglicht einen Überblick über sämtliche Komponenten des unter-

487


nehmensweiten Speichernetzwerks, aber auch einen tiefgreifenden Einblick in eine Komponente, falls dieser z.B. aufgrund eines aktuell fehlerhaften Verhaltens oder aufgrund einer Planungstätigkeit nötig ist. Wird ein Enterprise Management Framework wie z.B. Tivoli von IBM, CA Unicenter von Computer Associates, HP Open View von Hewlett-Packard oder irgendein SNMPProtokoll-Schnittstellen-Produkt verwendet, dann kann das EMC ControlCenter Status-Informationen zum SAN an diese Anwendungen weiterleiten. Das Basiswerkzeug zur Überwachung des SAN stellt bei EMC2 der (Open) Symmetrix Manager (OSM) dar. Dieser dient im Wesentlichen – bezogen auf seine Monitoring-Aufgaben – der Darstellung eines Symmetrix Storage Arrays im SAN und seiner Topologie-Verknüpfung. Über das ECC ist der OSM natürlich in der Lage, diese Informationen für jedes Symmetrix Storage Array im SAN zu liefern. Abbildung 8.9: Die Menüflächen des Open Symmetrix Managers

Markierte Menüflächen für: Director Layout (Director-Kartenposition im Storage Array) Front-End Layout (Host-Topologie des Storage Arrays) Back-End Layout (Device -Verteilung auf Disk Directors)

In der Titelzeile des Menüs für den EMC ControlCenter wird links die eindeutige Seriennummer des Symmetrix Storage Arrays angezeigt, das zum Monitoring ausgewählt wurde. Über das ECC-OSM-Menü können nahezu sämtliche unter dem vorigen Abschnitt angeschnittenen AdministrationsSoftwareprodukte angewählt werden. Für das Monitoring eines Storage Arrays sind jedoch die drei markierten Menüflächen besonders interessant. Diese dienen der Auswahl der Funktionsfenster: 왘 Director Layout, das einen Blick in das Symmetrix Storage Array erlaubt

und darstellt, in welchem Slot des Storage Arrays welcher Director-Typ steckt.

488

SAN-Monitoring mithilfe des ECC, Resource View und Resource Availability 왘 Front-End Layout, das darstellt, welcher Server über welchen Front-End,

also über welchen Channel Director, mit dem Storage Array verbunden ist. 왘 Back-End Layout, das anzeigt, welche Symmetrix Devices (also logical

Volumes, Splits oder Devices) über welchen Disk Director erreichbar sind. Diese drei Layouts sollen im Folgenden auch zur optischen Darstellung des in Kapitel 3 skizzierten Aufbaus eines hochverfügbaren Storage Arrays, dargestellt werden.

8.2.1.1

Das Director-Layout des OSM

Folgende Abbildung zeigt exemplarisch das Director Layout eines Symmetrix Storage Arrays. Abbildung 8.10: ECC-OSM Director-Layout

In aller Regel ist ein Symmetrix Storage Array so aufgebaut, dass in den Slots 6, 7, 8 und 9 am Backpanel die Cache-Karten des Storage Arrays eingesteckt sind. Sämtliche andere Slots (12 freie Slots) können für Channel Directors (Front-End-Adapter) und Disk Directors (Back-End-Adapter) verwendet werden. Das Slot-Assignment des Beispiel-Arrays der obigen Abbildung sieht wie folgt aus:

489


Abbildung 8.11: ECC-OSM FrontEnd-Layout

490

Slot1

Ein ESCON-Channel Director-Board oder Remote Link DirectorBoard. Der Prozessor auf der Oberseite des Boards wird über EA01a, der auf der Unterseite als EA01b adressiert.

Slot2

Ein Disk Director-Board. Der Disk-Adapter-Prozessor auf der Oberseite des Boards wird über DA02a, der auf der Unterseite als DA02b adressiert.

Slot3

Ein Disk Director-Board. Der Prozessor auf der Oberseite des Boards wird über DA03a, der auf der Unterseite als DA03b adressiert.

Slot4

Ein SCSI-Channel Director-Board. Der Prozessor auf der Oberseite des Boards wird über SA04a, der auf der Unterseite als SA04b adressiert.

Slot5

Ein ESCON-Channel Director-Board oder Remote Link DirectorBoard. Der Prozessor auf der Oberseite des Boards wird über EA05a, der auf der Unterseite als EA05b adressiert.

Slot12

Ein Fibre Channel Remote Link – Director-Board. Der Prozessor auf der Oberseite des Boards wird über R112a, der auf der Unterseite als R112b adressiert.

Slot13

Ein SCSI-Channel Director-Board. Der Prozessor auf der Oberseite des Boards wird über SA13a, der auf der Unterseite als SA13b adressiert.


Slot14


Slot15


Slot16

Ein Fibre Channel Remote Link – Director-Board. Der Prozessor auf der Oberseite des Boards wird über R116a, der auf der Unterseite als R116b adressiert.

Die Anzeige der Aktivitäten auf den Channel Director-Boards erfolgt über symbolisierte Lampen in Ampelfarben. So sind bei den beiden ESCON Adaptern EA01b und EA05b mit gelb markierte Lampen angezeigt, die symbolisieren sollen, dass die Anzahl der I/Os pro Sek. für diese beiden Adapter bereits einen Warnschwellwert überschritten haben. Für sämtliche übrigen Adapter sind die Betriebswerte im vorgesehenen Normalbereich.

8.2.1.2

Das Front-End-Layout des OSM

Das Front-End-Layout des OSM zeigt ausgehend von einem Host, welches/ welche Symmetrix Storage Array/s über welche Channel Directors sichtbar sind. Ausgehend von der Symmetrix wird angezeigt, welche Hosts über welche Channel Directors an das Storage Array angeschlossen sind. Weiter wird heruntergebrochen, welche Devices des Storage Arrays über welche Disk Directors für die einzelnen Hosts sichtbar sind. Durch Anklicken eines Devices wird die Absicherung des Devices durch einen lokalen Spiegel – so vorhanden – dargestellt sowie die, aus Platzgründen nur zweistellig dargestellten eindeutigen logischen Device-Namen (Hexadezimalzahl) der Devices im Storage Array sowie – falls vorhanden – ihre komplette TargetLUN dargestellt. Im Beispiel der obigen Abbildung ist folgende Topologie dargestellt: Host Milford

Angeschlossen über ESCON Director EA01b sieht dieser Host die Devices 00-04 sowie die Devices 05-10, zu denen jeweils ein lokales flexible Mirror BCV Device assoziiert ist. Da Host Milford über ESCON Direct Attached an das Storage Array angeschlossen ist, kann daraus geschlossen werden, dass es sich hierbei um ein S/390 Mainframe-System handelt.

Host Hopkinton Angeschlossen über ESCON Director EA01a sieht dieser Host die Devices 00-04 sowie die Devices 05-10, zu denen jeweils ein lokales flexible Mirror BCV Device assoziiert ist. Da Host Milford über ESCON Direct Attached an das Storage Array angeschlossen ist, kann daraus geschlossen werden, dass es sich hierbei um ein S/390 Mainframe-System handelt. Handelt es sich bei den Devices tatsächlich um dieselben Devices, die auch Host Milford sieht, kann davon

491


ausgegangen werden, dass Host Hopkinton und Host Milford ein Produktiv-Failover-Szenario repräsentieren. Host Natick

Angeschlossen über SCSI Director SA04b sieht dieser Host über Port C dieses SCSI-Adapters die Devices 6a-6d sowie die Devices 60-62 über Port D dieses SCSI-Adapters sieht er die Devices 5d, 4b, 52, 60-62. Da Host Natick über SCSI Direct Attached an das Storage Array angeschlossen ist, werden hier auch die Target-LUNs der Devices angezeigt. Diese werden bei Anklicken eines Devices komplett dargestellt, in der Übersichtsdarstellung jedoch – ebenfalls wie der Devicename der einzelnen Devices – nur als zweistelliger Wert.

Host Franklin

Angeschlossen über SCSI Director SA04b sieht dieser Host über Port C dieses SCSI-Adapters die Devices 5a-5c, 23-27, 66, 17-19 und 28-2b. Über Port D dieses SCSI Adapters sieht er keine Devices. Da Host Franklin über SCSI Direct Attached an das Storage Array angeschlossen ist, werden auch hier die Target-LUNs der Devices angezeigt.

Host Newton

Angeschlossen über ESCON Director EA05b sieht dieser Host die Devices 00-10. Da Host Newton über ESCON Direct Attached an das Storage Array angeschlossen ist, kann daraus geschlossen werden, dass es sich hierbei um ein S/390 Mainframe-System handelt.

Host Boston

Angeschlossen über ESCON Director EA05a sieht dieser Host dieselben Devices wie Host Newton. Auch hier kann davon ausgegangen werden, dass Host Newton und Host Boston ein Produktiv-Failover-Szenario repräsentieren.

An SCSI-Channel Director SA13b werden an Port D die Devices 6a-6d angezeigt, jedoch kein Host, der diese Devices sieht. Da jedoch Target-LUNs vorhanden sind, kann es sich nur um Devices eines Open Systems Hosts handeln, der momentan nicht verfügbar ist, dessen Device-Allokation jedoch noch im Cache des Storage Arrays für den nächsten Boot gehalten wird.

8.2.1.3

Das Back-End-Layout des OSM

Das Back-End-Layout stellt im OSM dar, welche Devices über welchen Disk Director angeschlossen sind und auf welcher physikalischen Platte sie mit welchen anderen Splits im Storage Array liegen. In dieser Darstellung werden die physikalischen Platten als Rechtecke dargestellt, in denen die Devices des Storage Arrays als Magnetplatten mit ihrem Device-Namen (dunkel unterlegt) dargestellt werden. Unter dem Devicenamen steht der Devicetyp des jeweiligen Device.

492

SAN-Monitoring mithilfe des ECC, Resource View und Resource Availability Abbildung 8.12: ECC-OSM BackEnd-Layout

Dabei sind folgende Devicetypen möglich: UP

Ein unprotected Device ist ein Standard-Produktionsdevice, das weder durch RAID-Verfahren, noch durch lokale, flexible oder remote Mirror Devices vor Verlust abgesichert ist.

Rp

Ein Device mit RAID protection ist ein Device, das durch ein RAID 7 oder höheres Verfahren abgesichert ist.

Rd

Ein Device mit RAID with parity distribution Device ist ein Device, das mit dem RAID S-Verfahren abgesichert ist.

M1

Ein mirrored Device ist ein Standard-Device, das mit einem lokalen Spiegel-Device abgesichert ist.

M2

Ein Mirror Device stellt den lokalen Spiegel eines lokalen M1-Produktionsdevices dar.

M3

Ebenfalls ein Mirror Device. Jeder weitere lokale Spiegel eines Produktionsdevices wird als M3 Device gekennzeichnet.

R1

Ein remotely mirrored Device ist ein lokales Standard-Produktionsdevice, das durch einen remote Mirror eines Disaster RecoverySzenarios abgesichert ist.

R2

Der remote Mirror stellt den remote Mirror eines produktiven Standard R1 Devices auf einem zweiten Storage Array in einem Disaster Recovery-Szenario dar.

Über das (Open) Symmetrix Manager Menü können auch die aktuellen Leistungsdaten des Storage Arrays abgefragt werden.

493

8 Administration unternehmensweiter Speichernetzwerke Abbildung 8.13: ECC-OSM Abfrage von Leistungsdaten des Storage Arrays

Markierte Menüflächen für: System-Performance (Laufzeitverhalten des Storage Arrays) Director-Performance (Performance der Directors) Volume-Performance (Leistungsdaten der Devices )

8.2.1.4

Abfrage der Syste- Performance im OSM

Die System-Performance kann im OSM als Kurvendiagramm über eine Anzahl genereller Leistungsdaten über den Verlauf eines konfigurierbaren Zeitraums angezeigt werden. Abbildung 8.14: ECC-OSM Anzeige der SystemPerformance

494


Performance-Parameter können in ihrem Verlauf über einen Tag, eine Woche, einen Monat oder über einen frei konfigurierbaren Zeitraum als Kurve dargestellt werden: 왘 Short-term IO/sec

Snapshot über das I/O-Verhalten eines kurzen Zeitraums. Es wird die Anzahl lesender und schreibender Zugriffe je Sek. auf das Storage Array zum Zeitpunkt des Snapshots gemessen und über den Zeitraum extrapoliert.

왘 Short-term Hit Ratio

Snapshot über das I/O-Verhalten eines kurzen Zeitraums. Es wird der prozentuale Anteil lesender und schreibender Zugriffe auf das Storage Array zum Zeitpunkt des Snapshots angezeigt, die über den Cache des Storage Arrays direkt befriedigt werden konnten, ohne dass ein Disk Director einen physikalischen I/O tätigen musste. Diese Werte werden ebenfalls über den Zeitraum extrapoliert.

왘 Short-term Write Ratio

Snapshot über das I/O-Verhalten eines kurzen Zeitraums. Es wird der prozentuale Anteil schreibender Zugriffe auf das Storage Array zum Zeitpunkt des Snapshots angezeigt, die direkt im Cache des Storage Arrays platziert werden konnten, ohne dass ein Disk Director einen Destage auf die Devices tätigen musste. Diese Werte werden ebenfalls über den Zeitraum extrapoliert. Abbildung 8.15: ECC-OSM Abbildung der Director-Performance

495

8 Administration unternehmensweiter Speichernetzwerke 왘 Long-term IO/sec

Konfigurierbare Anzahl von Snapshots über das I/OVerhalten eines kurzen Zeitraums, die zu einem Long-term-Verhalten hochgerechnet werden. Es wird die Anzahl lesender und schreibender Zugriffe je Sek. auf das Storage Array zum Zeitpunkt des Snapshots gemessen und über den Zeitraum extrapoliert.

왘 Long-term Hit Ratio

Konfigurierbare Anzahl von Snapshots über das I/O-Verhalten eines kurzen Zeitraums, die zu einem Long-term-Verhalten hochgerechnet werden. Es wird der prozentuale Anteil lesender und schreibender Zugriffe auf das Storage Array zum Zeitpunkt des Snapshots angezeigt, die über den Cache des Storage Arrays direkt befriedigt werden konnten, ohne dass ein Disk Director einen physikalischen I/O tätigen musste. Diese Werte werden ebenfalls über den Zeitraum extrapoliert.

왘 Long-term Write Ratio

Konfigurierbare Anzahl von Snapshots über das I/O-Verhalten eines kurzen Zeitraums, die zu einem Long-term-Verhalten hochgerechnet werden. Es wird der prozentuale Anteil schreibender Zugriffe auf das Storage Array zum Zeitpunkt des Snapshots angezeigt, die direkt im Cache des Storage Arrays platziert werden konnten, ohne dass ein Disk Director einen Destage auf die Devices tätigen musste. Diese Werte werden ebenfalls über den Zeitraum extrapoliert.

8.2.1.5

Abfrage der Disk und Channel DirectorPerformance im OSM

Alternativ kann die Performance der Disk Directors oder der ESCON, Fibre Channel, SCSI und Centronics Channel Directors abgefragt werden. Dabei werden über kurzfristige oder langfristige Snapshots die Laufzeitdaten sämtlicher Directors erfasst und wesentliche kumulative Kerndaten in Form von Balkendiagrammen dargestellt. Die dargestellten kumulativen Kerndaten sind: 왘 Write %

Die Write Percentage stellt den prozentualen Anteil der schreibenden Zugriffe an der Gesamtanzahl der Zugriffe über den Beobachtungszeitraum dar, die der betrachtete Director verarbeiten musste.

왘 Prefetch Util %

Die Prefetch Utilization Ratio Percentage gibt an, mit welchem Anteil an der Gesamtzahl der Prefetch I/Os des betrachteten Directors die erfolgreichen Prefetches gemessen wurden. Die Disk Directors des Symmetrix Storage Arrays betreiben Prefetching, sobald festgestellt wird, dass sequentielles Lesen auf der Hostseite stattfindet, also dass komplette Spuren auf den Devices nacheinander gelesen werden. Ein erfolgreicher Prefetch tritt dann auf, wenn eine Spur, die aufgrund des Prefetch Algorithmus vom Disk Director vorausschauend in den Cache des Storage Arrays eingelesen wurde, auch tatsächlich vom Host angefordert wird. Je höher also die Prefetch Utilization Rate gemessen wird, umso effektiver ist der Prefetch Algorithmus des Storage Arrays.

496

SAN-Monitoring mithilfe des ECC, Resource View und Resource Availability 왘 Prefetch Tasks %

Die Prefetch Tasks Percentage stellt den prozentualen Anteil der Prefetch Operationen an sämtlichen I/O-Operationen eines Directors dar. Anhand dieses Datums kann festgestellt werden, ob die Anwendungen, die über diesen Director auf die Daten zugreifen, eher sequentielle Datenverarbeitung betreiben oder eher eine Gleichverteilung zwischen sequentiellen und instanziellen Schreib-/Lese-Operationen besteht.

왘 IO/Sec

Durchschnittliche Anzahl an Schreib- und Leseoperationen, die dieser Director während des Messzeitraumes pro Sek. zu befriedigen hatte.

8.2.1.6

Abfrage der Device-Performance im OSM

Mit dem (Open) Symmetrix Manager kann auch das Laufzeitverhalten der einzelnen Devices im Storage Array untersucht werden. Abbildung 8.16: ECC-OSM Abbildung der Device-Performance

Die Device Statistics-Maske des OSM teilt sich in drei Teile. In der oberen Hälfte werden die Devices dargestellt. Hier kann man die Devices markieren, deren Performancedaten untersucht werden sollen. Weiter kann man hier einstellen, welche Performance relevanten Informationen gemessen werden sollen. Auswahlmöglichkeiten sind hier: 왘 IO per Sec

Durchschnittliche Anzahl der Schreib-/Lese-Zugriffe auf das betrachtete Device über den Beobachtungszeitraum.

497

8 Administration unternehmensweiter Speichernetzwerke 왘 Total Hit Ratio Prozentualer Anteil der Schreib-/Lese-Operationen auf

das betrachtete Device über den Beobachtungszeitraum, der direkt aus dem Cache des Storage Arrays befriedigt werden konnte und keinen physikalischen I/O von/auf dem/das Device erforderlich machte. 왘 Write Ratio

Prozentualer Anteil der Schreib-Operationen auf das betrachtete Device über den Beobachtungszeitraum, die direkt in dem Cache des Storage Arrays platziert werden konnten und keinen physikalischen I/O auf das Device erforderlich machten. Die Write Hit Ratio sollte möglichst hoch sein, was einer optimalen Cache Utilization entspricht.

왘 Read Hit Ratio

Prozentualer Anteil der Lese-Operationen auf das betrachtete Device über den Beobachtungszeitraum, der direkt aus dem Cache des Storage Arrays befriedigt werden konnte und keinen physikalischen I/O von dem Device erforderlich machte.

왘 Throughput

Gesamtdurchsatzmenge der I/Os auf das betrachtete Device über den Beobachtungszeitraum. Aus Throughput und IO per Sec kann die durchschnittliche Größe eines I/O-Requests ermittelt werden. Der Throughput Faktor kann als Grundlage für eine Entscheidung dienen, Devices mit SDDR auf einen anderen Disk Director zu verschieben, wenn der Disk Director, der das betrachtete Device kontrolliert, zu überlastet ist, um den benötigten Throughput sicherzustellen.

Weiter kann eingestellt werden, ob man auch die Labels der Volumes angezeigt bekommen möchte und ob man die Member Devices eines Meta Devices angezeigt haben will. Voreingestellt ist, das bei Metadevices lediglich der Meta-Head in der Device Liste oben rechts dargestellt wird. Der Meta-Head ist das erste Device innerhalb eines Meta Devices. Im unteren Teil der Device Statistics-Maske des OSM werden für jedes der ausgewählten Devices sämtliche Ausprägungen der ausgewählten Laufzeitparameter in absoluten Werten und farblich in Ampelfarben markiert dargestellt. Dabei stellt eine gelbe oder rote Farbe Devices dar, bei denen die Ausprägung eines Laufzeitparameters einen zuvor definierten Schwellwert für Warn- und kritische Grenzen überschritten hat. 왘 Weiter werden als generelle Laufzeit-Informationen für die Devices an-

gezeigt: 왘 Average IO Size

Die durchschnittliche Größe einer Schreib-/Leseanforderung auf sämtliche Devices in MB.

왘 Average Read Size

Die durchschnittliche Größe einer Leseanforderung auf sämtliche Devices in MB.

왘 Average Write Size

Die durchschnittliche Größe einer Schreibanforderung auf sämtliche Devices in MB.

498


8.2.1.7

Definition von Performance Thresholds im OSM

Aus der Device Statistics-Maske des OSM gelangt man über den LimitsSchalter auf eine Maske, in der die Schwellwerte für kritische Laufzeitparameter der Devices gesetzt werden können. Für die devicebezogenen Performance-Parameter 왘 IO per Sec

Durchschnittliche Anzahl der Schreib-/Lese-Zugriffe auf das betrachtete Device über den Beobachtungszeitraum.

왘 Total Hit Ratio

Prozentualer Anteil der Schreib-/Lese-Operationen auf das betrachtete Device über den Beobachtungszeitraum, der direkt aus dem Cache des Storage Arrays befriedigt werden konnte und keinen physikalischen I/O von/auf dem/das Device erforderlich machte.

왘 Write Ratio

Prozentualer Anteil der Schreib-Operationen auf das betrachtete Device über den Beobachtungszeitraum, die direkt in dem Cache des Storage Arrays platziert werden konnten und keinen physikalischen I/O auf das Device erforderlich machten.

왘 Read Hit Ratio

Prozentualer Anteil der Lese-Operationen auf das betrachtete Device über den Beobachtungszeitraum, der direkt aus dem Cache des Storage Arrays befriedigt werden konnte und keinen physikalischen I/O von dem Device erforderlich machte.

왘 Throughput

Gesamtdurchsatzmenge der I/Os auf das betrachtete Device können Schwellwerte (Thresholds) und erlaubte Abweichungen vom Schwellwert (Deviation) definiert werden. Abbildung 8.17: ECC-OSM Definition von Device PerformanceSchwellwerten

499


Als Voreinstellungen gelten für die Anzahl der I/Os pro Sek. 200 I/Os zum Erreichen der gelben Warnstufe und 500 I/Os für das Erreichen der roten kritischen Marke. Bei einem Throughput von 100 kBytes/Sek. wird die gelbe Warnstufe erreicht, bei 2.500 kBytes/Sek. ist die kritische Marke überschritten. Der niedrigere Schwellwert für die Total Hit Ratio liegt bei 70%. Hier ist die gelbe Warnstufe in der Standardeinstellung erreicht. Kritisch wird es, sobald der »rote« Threshold von 30% unterschritten wird. Die Write Ratio erreicht den »gelben« Threshold bei 30%, den kritischen roten bei 70%, die Defaulteinstellungen der Read Hit Ratio sind genau umgekehrt.

8.2.2

Monitoring mit der Resource View

Die Resource View bildet die Verwendung einzelner Speicher-Ressourcen ab – unabhängig von dem zu Grunde liegenden Dateisystem und dem verwendeten Betriebssystem und Volume-Management. Dabei werden von Resource View folgende Dateisysteme unterstützt: 왘 Compaq Tru64 UFS 왘 HP-UX HFS 왘 IBM AIX JFS 왘 Sun Solaris USF 왘 Windows NT FS

Abbildung 8.18: Schematische Darstellung der Resource ViewEbenen

Benutzerobjekte

Benutzer-Ressourcen

Applikationen

Datenbank

Server-Ressourcen Filesysteme

LVM

Raw Devices

Symmetrix Logical Volumes

Storage-Ressourcen Symmetrix Physikalische Platten

500


Die unterstützten Volume-Manager sind: 왘 Compaq LSM 왘 HP LVM 왘 IBM AIX LVM 왘 Solaris/Veritas VxVM 왘 Windows NT Disk Administrator

Die Ressourcenverwendung wird auch noch für Files des DatenbankManagement-Systems Oracle dargestellt. Abbildung 8.19: Resource View Details-Maske

Die Benutzerschnittstelle der Resource View kann wie ein Dateisystem-Explorer verwendet werden. Die Ebenen der Resource View können aufsteigend vom Storage Array über physikalische und logische Devices, Volume-Management-Systeme, Filesysteme, Datenbanken bis hin zu Benutzerobjekten oder startend vom Server bis hinunter zur Speicherung auf der physikalischen Platte im Storage Array dargestellt werden. Für einen ausgewählten Server können Devices, logische Volumes, Dateisysteme und Datenbanken angezeigt werden. Wird ein Dateisystem ausgewählt, so zeigt Resource View an, auf welchem Symmetrix Storage Array, welchen logical Volumes in diesem Storage Array dieses Dateisystem liegt und über welche physikalischen Laufwerke dieses Storage Array die Volumes des Dateisystem verteilt sind. Bei Auswahl eines physikalischen Laufwerks wird angezeigt, welche Server und Filesystem die logical Volumes auf diesem physikalischen Laufwerk verwenden.

501

8 Administration unternehmensweiter Speichernetzwerke Abbildung 8.20: Resource ViewDetailansicht einer physikalischen Platte

Die Anzeige der Ressourcenverwendung durch Resource View erlaubt es, die Speicher-Ressourcen eines Servers für seine Datenbanken, Applikationen und Filesysteme zu überwachen. In Abbildung 8.21 wird dargestellt, wie über Resource View der freie Speicherplatz angezeigt werden kann. Die Daten der Resource View können exportiert und mit entsprechenden Programmen weiterverarbeitet werden. So könnten beispielsweise über die ISV-Schnittstelle eines Open Management Framework wie BMC Patrol beim ECC periodisch Resource View-Auswertungen des freien Platzes in Filesystemen angestoßen, die Ergebnisse exportiert und seitens Patrol ausgewertet werden. Im Open Management Framework könnten Thresholds, als Schwellwerte, gesetzt werden, bei welchem Füllgrad des Filesystems dieses erweitert werden muss. Die Erweiterung auf ein weiteres logisches Volume kann ebenfalls dort angestoßen werden und mithilfe weiterer – noch darzustellender ECC-Tools – seitens des Open Management Frameworks ebenfalls automatisiert werden. Ergebnis einer solchen Automatisierung ist die Reduktion der administrativen Tätigkeiten auf ein Exception Handling. Administration wird hier zur Kontrollund Steuerungsinstanz und bleibt vom normalen stupiden Betrieb befreit.

502

SAN-Monitoring mithilfe des ECC, Resource View und Resource Availability Abbildung 8.21: Verwendung der Resource View zur Kapazitätsplanung 9250800

Zwei Zwei Schritte: Schritte: 1. 1. Auswahl Auswahl des des Filesystems Filesystems 2. 2. Sortieren Sortieren nach nach freiem freiem Speicherplatz Speicherplatz

8.2.3

Monitoring und Administration der Ressourcen-Verfügbarkeit – Resource Availability

Resource Availability bietet einem Administrator eine Schnittstelle, mit der er von einer zentralen Management Workstation aus sämtliche Speicherressourcen nicht nur anschauen, sondern auch verwalten kann. Intelligente Agenten für MVS, Unix und Windows, die auf den jeweiligen Serversystemen installiert werden, überwachen die Dateisystem-Strukturen des Servers nach den Kriterien, die von den Administratoren festgelegt werden und informieren sie über SNMP-Schnittstellen, falls eine Verletzung festgelegter Schwellwerte erreicht ist. In Datenbankumgebungen können volle Tablespaces oder Transaktions-Protokolle, die zu einem Anwendungsfehler führen, durch die Anwendung von Resource Availability verhindert werden. Resource Availability bietet zusätzlich die Möglichkeit, auftretende Ausnahmesituationen und Probleme mithilfe so genannter Autofixes automatisch zu lösen, Dateisysteme online zu erweitern und automatisch administrative Prozeduren zu starten.

503

8 Administration unternehmensweiter Speichernetzwerke Abbildung 8.22: Resource Availability – Funktionen und Schnittstellen*

* Aus EMC-Schulungsunterlage SymCLI Basics, München 1999, 2000.

Folgende Funktionen werden durch Resource Availability erfüllt: Verwaltungsfunktionen: Resource Availability verbessert die Verwaltungsmöglichkeiten von Speicher- und System-Administratoren dadurch, dass ein einziges Interface für sämtliche verfügbaren Speicherresourcen verwendet wird. Dies stellt eine wesentliche Vereinfachung der Administrationsabläufe dar. Auswahlfunktion: Auswahl der zu administrierenden Speicherressourcen ausgehend von einer applikationsnahen logischen Sicht oder Auswahl nach physikalischen Kriterien. Berichtsfunktion: Die Reporting-Funktion der Resource Availability liefert die für die Planung und Kommunikation zwischen den Abteilungen benötigten Speicherauslastungs-Informationen. Durch die einfache Benutzerschnittstelle wird die Erstellung von Berichten beschleunigt. Überwachungsfunktion: Die Überwachungsfunktion basiert auf von Resource Availability erzeugten Meldungen, die durch das Erreichen grundsätzlicher Schwellwerte oder

504


vorab definierter Ereignisse ausgelöst werden. Die im Leistungsumfang der Resource View enthaltenen vordefinierten Events decken vom Speicherüberlauf bis zu einer Fehlfunktion des Speichersystems sämtliche denkbaren Ausnahmesituationen ab, die einen Administrator zum Einschreiten zwingen können. Dennoch können selbstdefinierte Schwellwerte und Events zusätzlich zu den mitgelieferten definiert und verwendet werden. Abbildung 8.23: Resource Availability – Definition von Alerts für Autofixes

Die Überwachungsfunktion der Resource Availability bietet die Möglichkeit, so genannte Autofixes zur Korrektur voraussehbarer Fehler einzurichten. 왘 Autofix: Werden allgemeine und häufiger auftretende Fehler entdeckt

kann ein Autofix so aufgesetzt werden, dass es automatisch die Fehler erkennt und korrigiert 왘 Automatisierung: Mit Resource Availability können allgemeine Aufga-

ben wie z.B. die Erweiterung von Speicher-Pools und andere tägliche Administrationsaufgaben weitestgehend automatisiert werden. 왘 Benachrichtigung: Eine Benachrichtigung bei Überschreiten eines

Schwellwertes oder Eintreten eines Events wird über die ManagementKonsole oder durch vorhandene Management-Programme wie z.B. Tivoli definiert und versandt. Die in der Abbildung 8.24 mit Ausrufungszeichen dargestellten Ereignisse sind Eintragungen von Autofixes, die durch einen Event-Alert erzeugt wurden.

505

8 Administration unternehmensweiter Speichernetzwerke Abbildung 8.24: Resource Availability – Events für Autofixes

Die Abbildung 8.25 stellt die einzelnen Architektur-Komponenten der Resource Availability dar. Im Zentrum stehen die Speicheragenten, die als ein »Team« autonomer, wissensbasierter Agenten auf den Servern installiert werden und dafür verantwortlich sind, die Speicher-Ressourcen, auf die »ihr« Server Zugriff hat, zu finden, diese zu analysieren und darzustellen und an die zentrale Management-Konsole zu kommunizieren. Speicheragenten existieren MVS Mainframes, IBM AIX, HP-UX, Sun Solaris und Windows Server. Enterprise Agenten stellen die Verbindung zwischen den Speicher-Agenten und der Management-Konsole her. Über die Enterprise-Agenten werden die Notifikationen an die zuvor definierte Liste authorisierter Benutzer verschickt. Zur Gewährleistung der Zugriffs-Sicherheit und die Zugangskontrolle wird der Authentication Agent benötigt. Resource Availability wird auf der Management-Konsole ausgeführt. Es können beliebig viele Management-Konsolen installiert werden. Server, Speicher und Datenbanken können z.B. zu Gruppen zusammengefasst werden, die von einer Management-Konsole administriert werden. Für jede dieser Gruppen können wiederum mehrere Konsolen installiert sein. Die Architektur der Management-Konsolen ermöglicht die Abbildung jeglicher Administrationsorganisation. Erweiterte Agenten erweitern die Möglichkeiten von Resource Availability auf Datenbanken, Agenten für physikalischen Speicher (STK (StorageTek) Bänder, RVA, Symmetrix), Backup- und Restore-Agenten für MVS HSM, SMS und Tivoli Speicher-Manager.

506

SAN-Konfiguration und -Steuerung Abbildung 8.25: Architektur der Resource Availability

ManagementKonsolen

Open EnterpriseAgenten und Authentication Server

Management Frameworks Tivoli TME CA TNG HP OpenView

Speicheragenten

BMC Patrol

Erweiterte Agenten

Eine Integration der Resource Availability ist möglich in die Open Management Frameworks Tivoli TME (IBM) , CA TNG (Computer Associates), HP OpenView (Hewlett-Packard), und BMC Patrol (BMC).

8.3

SAN-Konfiguration und -Steuerung

8.3.1

Einschränkung zugreifbarer Devices – Volume Logix

Wie bereits in den Kapiteln 3 und 4 dargestellt, kann in der Grundeinstellung jeder Server sämtliche Devices in einem Storage Array sehen, die der Channel Director, über den der Host an das Storage Array angeschlossen ist, über die internen Busse des Storage Arrays sehen kann. Gerade in Serverkonsolidierungs-Umgebungen muss jedoch die Zugreifbarkeit der Server bis auf Device-Ebene hinunter eingeschränkt werden können. EMC2 stellt hierzu mit Volume Logix eine datenbank-basierte Anwendung zur Verfügung.

507

8 Administration unternehmensweiter Speichernetzwerke Abbildung 8.26: Typische Volume Logix-Umgebung*

...

Switch/Hub

Storage Array 1

Storage Array 2

* Nach EMC-Schulungsunterlage SymCLI Basics, München 1999, 2000.

Dabei sind folgende Konfigurationen denkbar und konfigurierbar: 왘 Jeder Server kann auf bestimmte Datenträger nur allein zugreifen, ob-

wohl das Device von mehreren Servern aufgrund seines Anschlusses gesehen werden könnte. 왘 Die Devices eines Servers können über mehrere Storage Arrays verteilt

sein. 왘 Dasselbe Device kann von mehreren Hosts gesehen werden. Diese Aus-

sage scheint ein Widerspruch zur ersten zu sein. Beachtet man dabei aber z.B. die Funktionalität von Flexible (BCVs) und Remote Mirror (SRDF Devices) Devices, so wird deutlich, dass für die Nutzung dieser Devices diese dritte Konfigurationsmöglichkeit erfüllt sein muss. Volume Logix stellt eine Software dar, die zum Schutz der Daten vorhanden ist, die sich auf verschiedenen logischen Datenträgern (Devices) in einem Symmetrix Storage Array befinden. Der Zugriff wird nur bestimmten Servern gestattet, die in der Volume Logix-Datenbank eingetragen sind. Volume Logix kann sowohl für Windows NT/2000, als auch für die gängigen UnixDerivate eingesetzt werden. Die Server können über einen Fibre Channel Arbitrated Loop Hub, über einen Switch oder über eine Switched Fabric an das Symmetrix Storage Array angeschlossen sein. Bei Serverkonsolidierungs-Topologien unter Windows NT/Windows 2000 ist Volume Logix unbedingt erforderlich. 508

SAN-Konfiguration und -Steuerung Abbildung 8.27: Der ECC SRDFManager

8.3.2

Steuerung und Konfiguration von Remote Mirrors – der SRDF-Manager

EMC2 bietet mit SRDF (Symmetrix Remote Data Facility) seine Implementierung von Remote Mirrors für Disaster Recovery-Szenarien an. SRDF kann mit dem SRDF Manager über die grafische Oberfläche des EMC ControlCenter (ECC) oder über ein Command Line Interface SymCLI (vgl. Kapitel 6) gesteuert werden. Die Daten werden von einem Symmetrix Storage Array auf ein anderes gespiegelt. Im Falle eines Ausfalls der ersten Symmetrix können die Daten auf der zweiten durch einen Befehl zugänglich gemacht werden. Die im SRDFManager verwendbaren Status- und Operations-Kommandos entsprechen den im Kapitel 6 bereits vorgestellten SymCLI-Befehlen und zwar der: 왘 Status-Abfrage der SRDF-Verbindung und SRDF-Operationen 왘 Steuerung der SRDF-Operationen 왘 Verbinden (establish) 왘 Trennen (split) 왘 Schwenken auf den Remote Mirror (failover) 왘 Rückschwenken auf das lokale Produktiv-Device (failback) 왘 Einrichtung von lokalen und Remote Device-Gruppen aus lokalen R1-

Standard-Produktiv-Devices und Remote Mirror R2 Devices.

509


8.3.3

Steuerung und Konfiguration von Flexible Mirrors – der TimeFinder Manager

EMC2 bietet mit TimeFinder BCVs (Business Continuance Volumes) seine Implementierung von Flexible Mirrors für konkurrierende Prozesse an. TimeFinder BCVs können mit dem TimeFinder Manager über die grafische Oberfläche des EMC ControlCenter (ECC) oder über ein Command Line Interface SymCLI (vgl. Kapitel 6) gesteuert werden. Die Daten werden von einem produktiven Symmetrix-Standarddevice auf ein Flexible Mirror BCV Device gespiegelt. Durch das Trennen des Flexible Mirror Devices von seinem Standard-Device können die Daten auf einem zweiten oder dem gleichen Server durch einen Befehl zugänglich gemacht werden. Die im TimeFinder-Manager verwendbaren Status- und Operations-Kommandos entsprechen den im Kapitel 6 bereits vorgestellten SymCLI-Befehlen und zwar der Statusabfrage und Steuerung der TimeFinderOperationen: 왘 Establish eines Business Continuance Volume (BCV) Flexible Mirrors. Der

Establish erfolgt durch Übertragung sämtlicher Spuren eines produktiven Standard-Devices auf das ihm assoziierte BCV. 왘 Trennung (Split) eines Standard – BCV- Device-Paares 왘 Inkrementelles Establish eines Business Continuance Volume (BCV) flex-

ible Mirrors. Der inkrementelle Establish erfolgt durch Übertragung sämtlicher seit dem letzten vollen Establish veränderten Spuren eines produktiven Standard-Devices auf das ihm assoziierte BCV. 왘 Restore eines Standard-Devices von einem BCV Device und dadurch Wie-

derherstellung eines konsistenten Zustandes des Standard-Devices 왘 Inkrementelles Restore von einem BCV Device und dadurch Wiederherstel-

lung eines konsistenten Zustandes des Standard-Devices 왘 Remote Steuerung der kompletten TimeFinder-Operationen. Dies bedeu-

tet, dass die BCV Flexible Mirrors nicht unbedingt lokal in dem Storage Array liegen müssen, in dem sich ihre Standard-Devices befinden. Sie können in einer SRDF-Disaster Recovery-Umgebung sehr wohl auch auf dem Remote R2-Storage Array eingebunden sein und werden dann von dem Remote Mirror established, gesplittet und restored. Diese Operationen können jedoch bei vorhandener Verbindung zwischen den beiden Storage Arrays auch von der R1-Seite aus initiiert werden.

510

SAN-Tuning Abbildung 8.28: Der ECC TimeFinderManager

322 322

8.4

SAN-Tuning

8.4.1

Dynamisches Pfad-Failover und Multipathing – PowerPath

PowerPath verbessert die Leistung eines Servers durch bessere Nutzung der I/O-Kanäle und sorgt über dynamisches Multipathing für eine größere Ausfallsicherheit des I/O-Systems. Dabei bietet PowerPath, wie bereits schon in Kapitel 6 dargestellt, folgende Funktionalitäten an: 왘 Konfiguration mehrerer physikalischer Wege (Host-Kanäle) zu den logi-

schen Datenträgern im Storage Array 왘 Dynamische Lastverteilung der I/Os über die verschiedenen Host-Ka-

näle 왘 Online-Konfiguration und Management 왘 Automatische Erkennung von ausgefallenen Pfaden 왘 Online-Wiederherstellung eines ausgefallenen Pfades

511

8 Administration unternehmensweiter Speichernetzwerke Abbildung 8.29: Dynamisches Multipathing mit PowerPath

Server HOST-Applikationen und Services

PowerPath PowerPath SCSI-Devicetreiber Host-Bus-Adapter

Channel -Directors Y-Bus

Cache Cache Cache Cache

X-Bus Disk -Directors

Storage Array

8.4.2

Oracle-Datenbank-Monitoring und Tuning – Der DB-Tuner

Der Symmetrix Database Tuner unterstützt den Administrator bei den Herausforderungen, die das Management von in einer Oracle-Datenbank gespeicherten Daten stellt. Besondere Herausforderungen bestehen oft darin, Performance-Engpässe und leistungshemmende Faktoren zu lokalisieren. Mögliche Ursachen von Performanceproblemen in Datenbank-Umgebungen sind: 왘 Das Daten- und Funktions-Modell bildet die produktive Realität der

Applikation nur schlecht ab. 왘 Der Anwendungscode verwendet keine für das jeweilige Datenbank-

Management-System optimierten Zugriffe wie z.B. Stored Procedures und Trigger. 왘 Betriebssystemseitige Umgebungsparameter sind nicht an das Daten-

bank-Management-system angepasst. 왘 I/O-Probleme, die von einer überlasteten Resource des Storage Arrays

herrühren, auf der die Daten der Datenbank residieren

512

SAN-Tuning

I/O-Probleme müssen jedoch nicht notwendigerweise auf eine überlastete Ressource eines angeschlossenen Storage Arrays hinweisen. So können auch Client-Netzwerkprobleme oder Bandbreitenprobleme eines HostBus-Adapters für eine unbefriedigende Datenbank-I/O-Performance verantwortlich sein. Der Database Tuner stellt sowohl für Storage-Administratoren, als auch für Datenbank-Administratoren ein wirkungsvolles Werkzeug zur Verfügung, diese Ursachen aufzufinden und die entdeckten Probleme zu beheben. Er misst die Leistung der Datenbankanwendung und bietet die Möglichkeit eines proaktiven Eingriffs, bevor tatsächlich Performanceprobleme auftreten. Abbildung 8.30: Der Symmetrix Database Tuner

Die Leistung der Datenbankumgebung wird durch die Überwachung der SGA (Shared Global Area) während der Produktion gemessen. Der erzeugte Overhead ist im Vergleich zu gängigen Monitoring-Applikationen eher niedrig. Die Hauptfunktionen des DB-Tuner lassen sich wie folgt zusammenfassen: 왘 Dynamische Messung der Leistung einer Oracle-Datenbank 왘 Überwachund der Oracle-Datenbank-Parameter 왘 Absetzen von Event-Meldungen 왘 Oracle SQL Monitoring, Analyse und Optimierung

513


Dabei ist der DBTuner 왘 in das EMC Control Center integriert, 왘 er identifiziert konfigurierbare Ereignisse für wichtige Datenbank-Para-

meter und 왘 liefert Warnungen, wenn Schwellwerte (Thresholds) überschritten werden.

Abbildung 8.31: Integration des DBTuners in das ECC

Werden Schwellwerte für die definierten Alerts überschritten, so werden diese Ereignisse über das SNMP-Protokoll direkt an das ECC weitergereicht. Mit der Resource Availability-Funktionalität des ECC können die Messages auch direkt an Open Management Frameworks durchgereicht und über diese automatisch auf die Schwellwertverletzung reagiert werden.

8.5

SAN-Planung

EMC2 bietet mit dem Workload Analyzer (WLA) ein Tool, mithilfe dessen sowohl die Auslastung des Storage Arrays über größere Zeiträume und über mehrere physikalische Ebenen des Storage Arrays untersucht und protokolliert werden kann, aber auch Auswertungen über die Entwicklung innerhalb des Beobachtungszeitraumes erzeugt werden können, die zur Planung der weiteren kapazitativen Entwicklung des SANs herangezogen werden können.

514

SAN-Planung

Der EMC ControlCenter Workload Analyzer liefert über Beobachtungszeiträume historische Trendanalysen. Performance-Daten des Symmetrix Storage Arrays werden gesammelt, archiviert und können in Auswertungen dargestellt werden. Abbildung 8.32: DBTuner – Definition von Datenbank-Alerts

Die Leistung der einzelnen Symmetrix-Komponenten können analysiert und die Korrelation verschiedener Variablen kann herausgefunden werden. Weiter können unterschiedliche Symmetrix Storage Array-Systeme miteinander verglichen werden. Die grafische Ausgabe des Workload Analyzers ermöglicht es dem Benutzer, Leistungstrends zu erkennen. Der Workload Analyzer besteht aus drei Komponenten: 왘 Der WLA-Archiver 왘 Das WLA-Archive 왘 Der WLA-Analyzer

Mit dem Archiver werden die Daten gesammelt und im WLA-Archive archiviert. Mit dem Analyzer können die Daten dann ausgewertet und präsentiert werden. Abschließend soll darauf hingewiesen werden, dass eine Vielzahl von Administrationstools dem Storage-Manager eines Unternehmens von dem jeweiligen Hersteller seiner Storage-Systeme angeboten werden. Die Integration der Tools in unternehmensweite Administrationsplattformen wie Tivoli oder OpenView wird ebenfalls vorangetrieben und angeboten.

515

8 Administration unternehmensweiter Speichernetzwerke Abbildung 8.33: Der Workload Analyzer WLA

Dennoch bleibt ein fader Beigeschmack bei der Vorstellung der heilen Welt der Storage-Administration. Sämtliche Administrations- und Konfigurationswerkzeuge sind heute noch proprietär. Das bedeutet, sie sind stark herstellerorientiert. Es ist zum gegenwärtigen Zeitpunkt noch nicht möglich, ein Storage Array von Hitachi Data Systems (HDS) mit dem ECC als Administrationstool seitens EMC2 zu administrieren und umgekehrt. Anwender heterogener Storage-Landschaften sind daher noch immer gezwungen, mehrere Administrationstools einzusetzen und die Administration ihrer Speichernetzwerke vielleicht sogar künstlich über die Open Management Frameworks zu vereinheitlichen. Dies ist eine der Herausforderungen an die Zukunft, die im Rahmen des nun abschließend folgenden Ausblickes kurz angerissen werden sollen.

516

9

Ausblick

Auf den vergangenen 500 Seiten wurde versucht, den technischen Background für das Phänomen der Storage Area Networks und des Network Attached Storage darzustellen. Doch wohin geht sowohl die technische Entwicklung als auch die Entwicklung des Einsatzes der Technologien? Roger Cox definiert als Ausblick auf die Entwicklung im Storage-Sektor folgende Aussagen: 왘 In der Infrastruktur für SAN-basierten externen Speichern bleibt der

Fibre Channel-Standard führend. 왘 iSCSI verhilft dem SAN-basierten Speicher zu weiterem Wachstum ge-

genüber jeglichem Direct Attached Storage. 왘 InfiniBand und GigaBit Ethernet eröffnen Möglichkeiten zur Interopera-

tion mit Fibre Channel SAN-Umgebungen. 왘 Zentrale Bedeutung wird die Speicher-Software besitzen. Die Implemen-

tierung einer API- und interoperablen Infrastruktur wird heterogene Speichernetzwerke ermöglichen. 1 Diese Prognosen sollen im Folgenden nochmals etwas genauer dargestellt werden. Gartner definiert als eines der wichtigsten Erkenntnisse des letzten Jahres die Bedeutung, die Software und Services im Umfeld von SAN und NAS gewonnen haben und bezeichnet die Storage-Software als den Key Differentiator zwischen den Storage-Herstellern. Dabei kann Software unter funktionalem und administrativemAspekt als Schlüsselfaktor betrachtet werden. Die Bedeutung der anwendungsnahen Speicher-Software wird in einer Vielzahl von Artikeln dargestellt. Ein Beispiel mag eine Meldung im Abschnitt Produkte & Technologien der Computerwoche 20/2001 vom 18.05.2001 sein, in dem die großen Vorteile der SAP R/3-Datensicherung mit Flexible Mirror Devices dargestellt werden. »Erst durch Spiegelplatten wird es möglich, den Backup Mode auf wenige Minuten zu reduzieren, da das Abkoppeln der Spiegelplatten wesentlich schneller geht als das Schreiben der Daten auf Band.«2

1. 2.

Aus: Cox, Roger, Storage: The New IT Gorilla, Gartner Dataquest Storage, General Session, STR17, 06/01, Stamford, 2001, S. 18. Gottwald, Holger, R/3-Datensicherung mit Spiegelplatten, Computerwoche 20/2001, vom 18.05.2001, S. 34 ff.

517

9 Ausblick

»Wesentlicher Bestandteil der Migration (von COBOL-basierten Daten auf eine Oracle-Datenbank, der Autor) ist auch der Umstieg vom Rechenzentrum im Keller des NFV (Niedersächsischer Fußball-Verband, der Autor) zu einer geografisch verteilten Systemumgebung. Sie besteht aus einem Mainframe-Unix-Cluster SR2000 mit getrennten Datenbank- und Applikationsservern in einem Rechenzentrum (RZ) der Firma Merkur. Ein EMC-Speichersystem sorgt hier für die zentrale Datensicherung.«3 »Auch wenn das Backup vom LAN auf Fibre Channel-Verbindungen übertragen wird, nimmt es sehr viel Zeit in Anspruch, wenn große Daten-Volumen im Spiel sind. Eine Möglichkeit, die erforderliche Zeit weiter zu reduzieren, besteht darin, Software wie ShadowImage von Hitachi Data Systems, FlashCopy von IBM und TimeFinder von EMC für die Replizierung des Platten-Subsystems einzusetzen.«4 Die Bedeutung der Speicher-Software drückt sich darin aus, dass Unternehmen, die sich mit Cluster- und Datensicherungs-Software schwerpunktmäßig beschäftigen, diesen Markt zunehmend für sich erkennen. »Diese Softwaredienstprogramme der Enterprise-Klasse ziehen die Aufmerksamkeit der Softwareunternehmen auf sich, weil sie aktuell auf Highend-Plattensystemen massiv zum Einsatz kommen. Microsoft erlaubt es Benutzern beispielsweise, sich mit den 200er Versionen von Windows, Exchange und SQL Server in diese Programme einzuklinken. Auch Veritas ermöglicht nunmehr serverloses Backup – mit ihrer neuen Vertex-Software und durch Nutzung geklonter Datentenkopien, die von diesen Replizierungsdienstprogrammen erstellt wurden.«5 Die durch Speicher-Software verbesserte Funktionalität des Betriebs von Speichernetzwerken ist den Anwendern bereits heute Geld wert. »Extra zur Kasse bitten die SSPs (Storage Service Provider, der Autor) auch, wenn regelmäßige Backups nachgefragt werden. Je häufiger Daten gesichert werden müssen, desto teurer wird der Dienst. In gesonderten Servicepaketen werden zudem Leistungen wie die Spiegelung von Daten verkauft.«6 Weiter wird hier auch auf die gestiegene Bedeutung der Dienstleistungen (Service-Consulting) hingewiesen. »Schließlich bieten einige SSPs auch noch Zusatzdienste wie Migrationsservices an, bei denen Daten auf neue Plattformen umgeschichtet werden. Weil sich sämtliche Dienste ähneln, gehen die ersten Anbieter bereits dazu über, auch Content-Management- und Knowledge-Management-Dienste anzubieten.«7 3.

4. 5. 6. 7.

518

Ripke, Joachim, Der deutsche Fußball geht ins Netz, aus: Computerwoche extra, Ausgabe Nr. 2, Wege zum E-Business, Von Anwendungsinseln zu innovativen Architekturen, 23. 03.2001. Enticknap, Nick, Ein verkanntes Problem tritt in den Vordergrund, in: Storage Aktuell, e-business Sonderausgabe, 2001, S. 14. Enticknap, Nick, a.a.O., S. 14. Speicher für 25.000 Dollar zu vermieten, aus: Computerwoche 16/2001 vom 20.04.2001, S. 64. Speicher für 25.000 Dollar zu vermieten a.a.O., S. 64.

Aus diesen Anmerkungen tritt deutlich hervor, dass die Vorzüge SANbasierter Lösungen besonders durch die angebotenen Softwarefunktionalitäten bereits heute ausgeschöpft werden. In Zukunft wird gerade für die Hersteller von Storage-Lösungen der Anteil der Software an den Gesamtumsätzen durchaus noch wachsen, insbesondere daher, weil gerade der Erfolg der Großen im Hardwareumfeld eine Vielzahl von Newcomer ins Feld ruft und der Wettbewerb im Hardware-Bereich im Wesentlichen über den Preis geführt wird.8 Eine interessante weitere Entwicklung im Softwareumfeld von SAN und NAS ist die Entwicklung und das Angebot von Administrations-Software, die den Betrieb auch heterogener unternehmensweiter Speichernetzwerke ermöglichen. Hier geht es im Wesentlichen um die Interoperabilität im Storage-Management, die auf zwei Wegen realisiert werden kann. 왘 Interoperabilität durch API-basierte Management-Systeme 왘 Interoperabilität durch Unternehmenskooperationen und Standardisie-

rung API-basierte Management-Systeme sind ein Schauplatz, auf dem sich sowohl etablierte Unternehmen wie auch hoffnungsvolle Newcomer tummeln. So kündigt das in Southborough, Massachusetts ansässige Unternehmen Sangate eine Hardware- und Softwarekombination an, die »bislang proprietäre Speicherfunktionen wie Fernspiegelung oder Datenmigration plattformübergreifend auf beliebigen Storage-Systemen nutzen lassen«9 kann. Hewlett-Packard startet in der Computerwoche vom 27.07.2001 eine mehrseitige Anzeigenkampagne für das HP Storage Area Management mit HP OpenView Storage Area Management, die massiv auf Open StorageManagement hinweist.10 Der zweite Weg, zur Interoperabilität über Unternehmenskooperationen und Standardisierungen zu gelangen, wird von einer Vielzahl von Unternehmen in immer schnelleren Schritten begangen. »In den Markt für hochverfügbare Speicherlösungen kommt Bewegung. Nachdem Softwarehersteller Veritas verschiedene Allianzen mit Hard- und Softwareherstellern geschlossen hat, ist Marktführer EMC mit einer neuen, offenen Management-Software (dem im letzten Abschnitt dargestellten ECC-ESN-Manager, Enterprise Storage Network Administrationstool, der Autor) an die Öffentlichkeit getreten.«11 8.

Vgl. Federated Storage Area Management, HP setzt auf dezentrale Systeme, in: Computerwoche 12/200, vom 23.03.2001, S. 48. Vgl. ebenfalls, Neue Server-Familie von Maxtor, NAS 4100 unterstützt Directories, in: Computerwoche 12/200, vom 23.03.2001. 9. Startup verspricht Interoperabilität im Storage-Management, Sangate sprengt Plattformgrenzen zwischen Speichern, in: Computerwoche 28/2001, vom 13.07.2001, S. 9. 10. Vgl. Computerwoche 30/2001, vom 27.07.2001, S. 7 f., S. 10.

519

9 Ausblick

Die im obigen Artikel zitierten Allianzen werden im Juni 2001 präzisiert. »Die Speicherhersteller IBM, EMC, Hitachi und Compaq haben zwei SANLösungen entwickelt, die Geräte aller Beteiligten zusammen in einem Speichernetz betreiben. Für die Verteilerstelle im Fibre Channel-Netz wurden vier ‚ED-5000 Directors‘ von MacData und 16 ‚Silkworm‘-Switches von Brocade ausgewählt. Anwender erhalten damit immerhin die Möglichkeit, Speicher von verschiedenen Herstellern in ein SAN einzubinden.«12 »Speicherhersteller EMC hat jetzt ein Programm zur Interoperabilität von Fibre Channel-Switches aufgelegt. Im Rahmen des Konzepts ‚E-Port‘ wurden FC-Produkte inklusive der zugehörigen Software von Brocade, McData und der hauseigenen ‚Connectrix‘-Switches auf ihre Interoperabilität getestet.«13 »Zumindest für die Kompatibilitätsprobleme zwischen den Hardwareherstellern zeichnete sich auf der Storage Networking World 2001 ein Silberstreif am Horizont ab. Dort beteiligten sich mehr als 50 Hersteller und Händler an einem ‚Interoperability Lab‘. Offensichtlich hat die Branche erkannt, dass standardisierte und zueinander kompatible Technologien unerlässlich sind, um die SANs am Markt durchzusetzen.«14 Was die Entwicklung der SAN und NAS-Infrastruktur anbelangt, so ist diese in zwei Pfade gesplittet. Der erste Pfad, der heute und auch in übersehbarer Zukunft die technologische Marktführerschaft besitzt, ist die Fortführung der Standardisierung des Fibre Channels als Infrastruktur-Medium für SAN- und NAS-Landschaften. Die Fibre Channel-Technologie hat jedoch den Nachteil, eine komplett neue Infrastruktur basierend auf der Glasfaserverkabelung zu benötigen, die durchaus kostspielig ist. Daher werden Entwicklungen, die vorhandene Technologien nutzen, zumindest den Markt für Storage Systeme auf Unternehmen ausweiten, denen eine Fibre Channel-Infrastruktur einfach zu teuer ist. »Der Fibre Channel hat sich trotz hoher Kosten bislang als die geeignetste Technik für Speichernetze erwiesen. Jetzt eröffnet sich durch die Koalition zwischen TCP/IP und Gigabit Ethernet eine kostengünstige Alternative.«15 »Während die meisten Anbieter von Highend-Speichersystemen auf die proprietäre Fiber Channel-Technik setzen, bringt IBM nun neue Produkte, 11. Hersteller setzen zunehmend auf offene Standards, Viele neue Allianzen auf dem Speichermarkt, in: Computerwoche 9/2001 vom 02.03.2001, S. 6. 12. IBM und Hitachi gehen einen Schritt weiter, Schulterschluss von sechs Speicherherstellern, in: Computerwoche 26/2001, vom 29.06.2001, S. 29. 13. Das E-Port-Konzept, EMC zertifiziert, in: Computerwoche 24/2001, vom 15.06.2001, S. 35. 14. Morgan Stanley vermisst Anwenderfreundlichkeit, SAN: Die große Herausforderung, in: Computerwoche 21/2001, vom 25.05.2001, S. 52. 15. Erste Produkte für IP-Speicher, SAN mit Gigabit Ethernet und IP, in: Computerwoche 13/2001, vom 30.03.2001, S. 42.

520

die auf dem offenen Internet-Protokoll TCP/IP basieren. Bisher hatte bereits Network Appliance TCP/IP verwendet, doch nach Ansicht einiger Experten können Produkte, die das Protokoll nutzen, derzeit in Sachen Geschwindigkeit noch nicht mit den Fiber Channel-Pendants mithalten.«16 »IBM ... wartet mit einer echten Neuerung auf. Der Hersteller führt errstmalig mit seinem ‚Total Storage IPStorage 200i‘ ein iSCSI-(Small-Computer-Systems-Interface) basierendes Speichersystem vor. Es verbindet Rechner mit Speicher-Pools in einem IP-Netzwerk. Neu ist außerdem der multi-protokollfähige Dateiserver ‚NAS 300G‘, der ein Netz auf IP-Basis mit einem SAN verbindet.«17 Eine weitere Entwicklung stellt FCIP (Fibre Channel over IP) dar, das FCDatenpakete in IP-Pakete assembliert, über große Distanzen via TCP/IP verschickt und auf einer Remote-Umgebung wieder in FC-Datenpakete disassembliert.18 Sämtliche Entwicklungen, sowohl auf Software-, als auch auf Infrastrukturseite verdienen die höchste Aufmerksamkeit, da sie die Festigung der Storage Area Networks und des Network Attached Storages als tatsächlicher »IT-Gorilla« nur noch vorantreiben können. Als bedeutsame Produkte können sie eigenständig Bücher füllen, daher seien sie hier lediglich erwähnt. Dennoch ist ihnen ein so großes Gewicht zuzuweisen, dass mit ihnen dieses Buch abgeschlossen werden soll.

16. IBM entscheidet sich für TCP/IP, in: Computerwoche 9/2001, vom 02.03.2001, S.6. 17. Rundgang Speichersysteme, SAN und NAS kommen sich näher, in: Computerwoche 11/2001, vom 16.03.2001, S. 52. 18. Vgl. Optische Storage-Netze, Speicherlösungen ohne Begrenzungen, in: Computerwoche 24/2001 vom 15.06.2001, S. 35.

521

Bibliographie

Ault, Michael R., Das Oracle 8-Handbuch, Bonn et. al., 1998. Ault, Michael, Oracle 8-Administration and Management, New York et. al., 1998. Benner, Alan F., FIBRE CHANNEL for SANs, New York et. al., 2001. Black, Uyless, ATM – Foundation for Broadband Networks, Prentice-Hall PTR, Englewood Cliffs, NJ, 1995. Clark, Tom, Designing Storage Area Networks, 3.Aufl., Massachusetts et. al., 2000. Comer, Douglas E., Internetworking with TCP/IP Vol. 1: Principles, Protocols, and Architecture, Prentice-Hall, Englewood Cliffs, NJ, 1995. Computerwoche 9/2001, vom 27.07.2001, S. 7f, S. 10. Cox, Roger, Storage:The New IT Gorilla, Gartner Dataquest Storage, General Session, STR 17, 06/01, Stammford, 2001, S. 18. Defekter EMC-Speicher legt Strato lahm, aus: Computerwoche 14/2001, vom 06.04.2001, S. 10. EMC Corporation (Hrsg.), Connectrix EC-1100 System, USER GUIDE, Hopkinton, 2000, P/N 300-600-001. EMC Corporation (Hrsg.), Connectrix EC-1100 System, PLANNING GUIDE, Hopkinton, 2000, P/N 300-600-002. EMC Corporation (Hrsg.), Connectrix ED-1032 Director, USER GUIDE, Hopkinton, 2000, P/N 300-600-004. EMC Corporation (Hrsg.), EMC Connectrix Enterprise Storage Network System, TOPOLOGY GUIDE, Hopkinton, 2000, P/N 300-600-008. EMC Corpoation (Hrsg.), Symmetrix Optimizer Control Interface, Version 4.0 for MVS, USER GUIDE, Hopkinton, 1999, P/N 300-999-035. EMC Corporation (Hrsg.), EMC Solutions Enabler SYMCLI Mapping Component, Version 4.1, PRODUCT GUIDE, Hopkinton, 2000, P/N 300-999-037-01. EMC Corporation (Hrsg.), EMC Solutions Enabler SYMCLI Control Component, Vesion 4.1, PRODUCT GUIDE, Hopkinton, 2000, P/N 300-999-142.

523

Bibliographie

EMC Corporation (Hrsg.), EMC ControlCenter Console with Resource View, Version 4.1 for Windows, PRODUCT GUIDE, Hopkinton, 2000, P/N 300-999229. EMC Corporatin (Hrsg.), EMC ControlCenter, Version 4.1, INSTALLATION GUIDE, Hopkinton, 2000, P/N 300-999-230. EMC Corporation (Hrsg.), EMC ControlCenter Web Edition, Version 4.1, PRODUCT GUIDE, Hopkinton, 2000, P/N 300-999-232. EMC Corporation (Hrsg.), EMC ControlCenter Symmetrix Manager for Windows, Verson 4.1, PRODUCT GUIDE, Hopkinton, 2000, P/N 300-999233. EMC Corporation (Hrsg.), EMC ControlCenter Symmetrix Manager, Version 4.1 for UNIX, PRODUCT GUIDE, Hopkinton, 1999,2000, P/N 300-999-234. EMC Corporation (Hrsg.), EMC ControlCenter Integration Packages, Version 4.1 for Windows and UNIX, PRODUCT GUIDE, Hopkinton, 2000, P/N 300-999-235. EMC Corporation (Hrsg.), EMC ControlCenter SRDF Manager, Version 4.1 for Windows, PRODUCT GUIDE, Hopkinton, 1999,2000, P/N 300-999-237. EMC Corporation (Hrsg.), EMC ControlCenter SRDF Manager, Version 4.1 for UNIX, PRODUCT GUIDE, Hopkinton, 1998,1999,2000, P/N 300-999,238. EMC Corporation (Hrsg.), EMC ControlCenter TimeFinder Manager, Version 4.1 for Windows, PRODUCT GUIDE, Hopkinton, 1999,2000, P/N 300999-239. EMC Corporation (Hrsg.) EMC ControlCenter TimeFinder Manager, Version 4.1 for UNIX, PRODUCT GUIDE, Hopkinton, 1998,1999,2000, P/N 300-999240. EMC Corporation (Hrsg.), EMC ControlCenter Symmetrix Disk Reallocation, Version 4.1 for Windows, PRODUCT GUIDE, Hopkinton, 2000, P/N 300-999-241. EMC Corporation (Hrsg.), EMC ControlCenter Symmertix Disk Reallocation, Version 4.1 for UNIX, PRODUCT GUIDE, Hopkinton, 2000, P/N 300999-242. EMC Corporation (Hrsg.), EMC ControlCenter Symmetrix Optimizer, Version 4.1 for Windows, PRODUCT GUIDE, Hopkinton, 1999,2000, P/N 300999-243. EMC Corporation (Hrsg.), EMC ControlCenter Symmetrix Optimizer, Version 4.1 for UNIX, PRODUCT GUIDE, Hopkinton, 1999,2000, P/N 300-999244. EMC Corporation (Hrsg.), EMC ControlCenter Workload Analyzer, Version 4.1, PRODUCT GUIDE, Hopkinton, 2000, P/N 300-999-246.

524

Bibliographie

EMC Corporation (Hrsg.), EMC Solutions Enabler SYMCLI Base Component, Version 4.2, PRODUCT GUIDE, Hopkinton, 2000, P/N 200-999-624-04. EMC Corporation (Hrsg.), EMC Solutions Enabler SYMCLI SRDF Component, Version 4.2, PRODUCT GUIDE, Hopkinton, 2000, P/N 200-999-625-04. EMC Corporation (Hrsg.), EMC Solutions Enabler SYMCLI, Version 4.1.2, Release Notes, Hopkinton, 2000, P/N 200-999-632-07. EMC Corporation (Hrsg.), EMC Solutions Enabler SYMCLI, Version 4.2, Release Notes, Hopkinton, 2000, P/N 200-999-632-08. EMC Corporation (Hrsg.), EMC Solutions Enabler SYMCLI TimeFinder Component, Version 4.2, PRODUCT GUIDE, Hopkinton, 2000, P/N 200-999634-04. EMC Corporation (Hrsg.), EMC Solutions Enabler, Version 4.2, INSTALLATIONS GUIDE, Hopkinton, 2000, P/N 200-999-635-05. EMC Corporation (Hrsg.), EMC Solutions Enabler SYMCLI Mapping Component, Version 4.2, PRODUCT GUIDE, Hopkinton, 2000, P/N 300-99-03702. EMC Corporation (Hrsg.), EMC Solutions Enabler SYMCLI Control Component, Version 4.2, PRODUCT GUIDE, Hopkinton, 2000, P/N 300-999-142-01. EMC Corporation (Hrsg.), EMC Solutions Enabler SYMCLI Configuration Component, Version 4.2, PRODUCT GUIDE, Hopkinton, 2000, P/N 300-999298. EMC Corporation (Hrsg.), EMC Solutions Enabler SYMCLI Base Component, Version 4.1, PRODUCT GUIDE, Hopkinton, 2000, P/N 200-999-624-03. EMC Corporation (Hrsg.), EMC Solutions Enabler SYMCLI SRDF Component, Version 4.1, PRODUCT GUIDE, Hopkinton, 2000, P/N 200-999-625-03. EMC Corporation (Hrsg.), EMC Solutions Enabler SYMCLI Time Finder Component, Version 4.1, PRODUCT GUIDE, Hopkinton, 2000, P/N 200-999634-03. EMC Corporation (Hrsg.), EMC Solutions Enabler, version 4.1, INSTALLATIONS GUIDE, Hopkinton, 2000, P/N 200-999-635-04. EMC Corporation (Hrsg.), Instant Restore of Oracle Databases: Leveraging TimeFinder Multi-BCV and Instant Split, Hopkinton, 1999,2000. EMC Corporation (Hrsg.), Symmetrix SRDF Host Component, Version 4.0, PRODUCT GUIDE, Hopkinton, 2000, P/N 200-999-561. EMC verliert den Glanz früherer Tage, aus: Computerwoche 22/2001, vom 01.06.2001, S. 1 und S. 16. EMC zertifiziert, aus: Computerwoche 24/2001, 28. Jahrgang, München, 2001.

525

Bibliographie

EMC zertifiziert, aus: Computerwoche 24/2001, vom 15.06.2001, S. 35. Enticknap, Nick, Ein verkanntes Problem tritt in den Vordergrund, STORAGE AKTUELL, e-business Sonderausgabe, 2001, S. 14. Erste Produkte für IP-Speicher, SAN mit Gigabit Ethernet und IP, aus: Computerwoche 13/2001, vom 30.03.2001, S. 42. Farley, Marc, Building Storage Networks, The McGraw-Hill Companies, 2000. FC-AL, Fibre Channel Arbitrated Loop, ANSI X3.272-1996. FC-AL-2, Fibre Channel Arbitrated Loop, ANSI X3.T11 Project 1133-D. FC-GS, Fibre Channel Generic Services, ANSI X3.288-1996. FC-GS-2, Fibre Channel Generic Services 2, ANSI X3.T11 Project 1134-D. FC-LE, Fibre Channel Link Encapsulation, ANSI X3.287-1996. FC-PH, Fibre Channel Physical and Signaling Interface, ANSI X3.230-1994. FC-PH Errata, Fibre Channel Physical and Signaling Interface Errata, ANSI X3.230:AM1-1996. FC-PH-2, Fibre Channel Physical and Signaling Interface-2, ANSI X3.2971997. FC-PH-3, Fibre Channel Physical and Signaling Interface-3, ANSI X3.T11 Project 1119-D. FC-SL, Fibre Channel Slotted Loop, ANSI X3.T11 Projekt 1232-D. FC-SW, Fibre Channel Switch Fabric, ANSI X3.T11 Project 959-D FCP, Fibre Channel Protocol for SCSI, ANSI X3.269-199x. Federated Storage Area Management, HP setzt auf dezentrale Systeme, aus: Computerwoche 12/2001, vom 23.03.2001, S. 48. Gottwald, Holger, R/3-Datensicherung mit Spiegelplatten, aus: Computerwoche 20/2001, vom 18.05.2001, S. 34ff. Gulbins, Jürgen, Obermayr, Karl, AIX UNIX System V.4, Berlin et. al., 1996. Handschuch, Thomas, SOLARIS zwei Systemadministration, Bonn et. al., 1996. Hesteller setzen zunehmend auf offene Standards, Viele neue Allianzen auf dem Speichermarkt, aus: Computerwoche 9/2001, vom 02.03.2001, S. 6. Hewlett Packard Company (Hrsg.), MC/Service Guard, User Guide, 1998. Hörner, Brigitte, DECnet- Das Netzwerk als System, 2. Aufl., Bonn et. al., 1992.

526

Bibliographie

IBM entscheidet sich für TCP/IP, aus: Computerwoche 9/2001, vom 02.03.2001, S. 6. IBM und Hitachi gehen einen Schritt weiter, Schulterschluss von sechs Speicherherstellern, aus: Computerwoche 26/2001, vom 29.06.2001, S. 29. Johnson, Robert H., MVS Concepts and Facilities, New York et.al., 1989. Kumar, Balaji, Broadband Communications: A Professional`s Guide to ATM, Frame Relay, SMDS, SONET, and BISDN, The McGraw-Hill Companies, New York, 1995 McData, Fibre Channel, Connection to the Future, 2.Aufl.,1998. McDysan, David E., and Spohn, Darren L., ATM: Theory and Application, The McGraw-Hill Companies, New York, 1995. Microsoft Press (Microsoft Corporation) (Hrsg.), Networking Essentials, Washington, 1996. Microsoft Press (Microsoft Corporation) (Hrsg.), Windows NT Workstation, Version 4, Unterschleißheim, 1996. Miller, Mark A., P.E. Internetworking: A Guide to Network Communications: LAN to LAN; LAN to WAN, M&T Books, New York, 1991. Morgan Stanley vermisst Anwenderfreundlichkeit, SAN: Die große Herausforderung, aus: Computerwoche 21/2001, vom 25.05.2001, S 52. Neue Server-Familie von Maxtor, NAS 4100 unterstützt Directories, aus: Computerwoche 12/2001, vom 23.03.2001. Optische Storage-Netze, Speicherlösungen ohne Begrenzungen, aus: Computerwoche 24/2001, vom 15.06.2001, S. 35. Page, William G. Jr., Special Edition Using Oracle 8/8i, Indianapolis, 1999 Partridge, Craig, Gigabit Networking, Addison-Wesley, Reading, MA, 1994. Petcoviæ Dušan, Sybase- und Microsoft-SQL Server, Bonn et.al., 1994. Ripke, Joachim, Der deutsche Fussball geht ins Netz, aus: Computerwoche extra, Ausgabe Nr. 2, Wege zum E-Business, Von Anwendungsinseln zu innovativen Architekturen, 23.03.2001. Rosen, Kenneth H., Rosinski, Richard R., Faber, James M., Unix System V Release 4: An Introduction, Berkeley, 1990. Rundgang Speichersysteme, SAN und NAS kommen sich näher, aus: Computerwoche 11/2001, vom 16.03.2001, S. 52. Schwartz, M., Computer-Communication Network Design and Analysis, Prentice-Hall, Inc., Englewood Cliffs, NJ, 1977. Smith III, Philip H., Goldberg, Gabriel, The VM/ESA User`s and Applications Handbook, New York et.al., 1994.

527

Bibliographie

Sollbach, Wolfgang , Bausteine für die Client/Server Technik, Landsberg, 1996. Speicher für 25000 Dollar zu vermieten, aus: Computerwoche 16/2001, vom 20.04.2001, S. 64. Startup verspricht Interoperabilität im Storage-Management, Sangate sprengt Plattformgrenzen zwischen Speichern, aus: Computerwoche 28/ 2001, vom 13.07.2001, S. 9. Stürner, Günther, Oracle sieben A User`s and Developer`s Guide, London et.al., 1995. SuSE GmbH (Hrsg.), SuSE Linux 6.0, 13. Aufl. Nürnberg, 1998. Tanenbaum, Andrew S., Computer-Netzwerke, 2. Aufl., Amsterdam, 1990. VERITAS Software Corporation (Hrsg.), VERITAS Cluster-Server SUN StorEdge A5000 Disk Array, Application Note, Version 1.0, 1999, P/N 100001171. VERITAS Software Corporation (Hrsg.), VERITAS Cluster-Server Agent Developer`s Guide, Version 1.2, 1999, P/N 100-001165. VERITAS Software Corporation (Hrsg.), VERITAS Cluster-Server Enterprise Agents Istallation and Configuration Guide, 1999, P/N 100-001181. VERITAS Software Corporation (Hrsg.), VERITAS Cluster-Server Enterprise Agents Release Notes, 1999, P/N 100-001182. VERITAS Software Corporation (Hrsg.), VERITAS Cluster-Server Enterprise Agents Release Notes, Version 1.1, 1999, P/N 100-001182. VERITAS Software Corporation (Hrsg.), VERITAS Cluster-Server Installation Guide, Version 1.1, 1999, P/N 100-001168. VERITAS Software Corporation (Hrsg.), VERITAS Cluster-Server Release Notes, Version 1.1, 1999, P/N 100-001170. VERITAS Software Corporation (Hrsg.), VERITAS Cluster-Server QuickStart Guide, An Examle with NFS, Version 1.1, 1999. P/N 100-001205. VERITAS Software Corporation (Hrsg.), VERITAS Cluster-Server User`s Guide, Version 1.1, 1999. P/N 100-001164. VERITAS Software Corporation (Hrsg.), VERITAS WHITE PAPER, Cluster-Server Enterprise Availability Management, 1998. VERITAS Software Corporation (Hrsg.), VERITAS Volume-Manager Storage Administrator, Administrator Guide, Release 3.0.1, 1999, P/N 100000954. Washburn, K., and Evans, J.T., TCP/IP-Running a Successful Network, Addison-Wesley Publishing Company, Wokingham, England, 1993.

528

Stichwortverzeichnis ! /dev/vgnn 428 « 131 24-Bit Fibre Channel-Adresse 228 2-Way Mir 377 4-Port SCSI Limit 158 A Adapter Board 167 Adaptive Copy 186 Administration 479 Administrations Suite 481 Administrationskomplexität 268 Administrationsnetzwerk 259 Adoptive Node 147, 282 Adressklassen 68 ADSL 56 ADSM 273 AIX 449 aktiver Knoten 147 Allokationsalgorithmus 174 Analyzer 482 ANSI 28, 52, 77, 79 ANSI-Standard 28 Anwendungs-Header 66 anwendungsreine Platte 434 Applikations-Prozess 54 Applikations-Recovery 299 Arbitrated Loop 170 Arbitrated Loop Hub 508 Arbitrated Loop-Topologie 168 Arbitration Cycle 213 ARP 67, 83, 303 Array-Prozessor 173 ASCII-Code 65 ATM 256 Authentication Agent 506 Auto configure 44 auto mapping 245 Autofix 503 AutoLUN XP 347 AUTOMATIC 297 automatisch rotierender Standby-Knoten 294

Automount 446 AutoPath 346 AUTOSTART-CMCLD 283 AUTO-START-TIMEOUT 281 Average IO Size 498 Average Read Size 498 Average Write Size 498 B Back-End 162 Back-End Layout 489 Back-End-System 162 Backpanel 30, 489 Backup Mode 517 Backup-Architektur 273 Backup-Kanal 267 Backup-Knoten 159 Backup-Tape-Library 216 Bad Block 48 Bad Network Connections 153 Bad-Block 37 Bandbibliothek 273 Base Component 485 Batterien 189 Batteriepuffer 179 Battery Backup 256 Battery-Pack 189 BCV 377, 381, 482, 485 bidirektionale Konfiguration 183 bidirektionales Fibre Channel 182 BIOS 425 Bitübertragungsschicht 55–57, 59, 67 Block-Device-Name 324 BMC 156 boot 320 Boot-Platte 20 Bottom-High 165 Bottom-Low 165 Bridged Net 149 Broadcasting 58, 61, 113 Brocade 226, 520 Browser 262 BSD 32–33

529


Buffer-Cache-Flush 420 Buffered Service 111 Business Continuity 254, 411 Business Copy XP 346 C CA Unicenter 488 Cache 162 Cache Memory Boards 189 Cache Utilization 498 Cache-Mirroring 211 Cache-Slot 174 Cache-to-Cache Remote Link 188 CAD/CAE-Netzwerk 82 CAD/CAM 252 CAE 252 Campus-Distanz-Topologie 144 Cascadierte Hubs 213 CCITT 52 Celerra 263 Central Memory Module 219 Central Memory Module-Karte 222 Centronix 165 Channel Director 162, 167 Character Device 39 chdev 444 CHIP 209 CIFS 255 CIFS(SMB)-Protokolle 25 Circuit Switch 106 Circuit Switching 91 CLARiiON 263 Cleanup 310 CLI 262 Client/Server 17 Client/Server-Speicherkonsolidierungen 131 Client-Dateien 76 Client-Host Interface-Prozessor 209 Client-Netzwerkprobleme 513 Clients Fileservice 26 CLNP 61 CLT-Mimik 30 Cluster 20, 22, 145, 479 Cluster Configuration Template 278 Cluster Coordinator 278 Cluster Explorer 344 Cluster Heartbeat-Netzwerk 278 Cluster Lock Disk 278 Cluster Locks 284 Cluster Monitor 344

530

Cluster Timing Parameter 278 Cluster-Knoten 275 Cluster-Manager 277 Cluster-Manager Daemon 278 Cluster-Member 312 CLUSTER-NAME 280 Cluster-Quorum 284 Cluster-Server 161 Cluster-Software 20, 479 ClusterView 156 cmapplyconf 280 cmcheckconf 279 cmcld 278 cmhaltcl 280 cmlvmd 311 cmmakepkg 299 CMM-Karte 221 cmmodnet 300 cmmodpkg 293 cmquery 279 cmquerycl 279 cmruncl 280 cmviewcl 280 COBOL 518 COM1 260 COM2 260 Command Center 344 Command Control 346 Command Line Interface 262 Commit 413 Compaq LSM 501 Compaq Tru64 UFS 500 Computer Associates 488 COMPUTERWOCHE 226, 517 Concatenated Volume 456 Concentrator 149, 151 CONFIGURED-NODE 293 Congestion Error 282 Connectivity 238 Connectivity-Hardware 211 Connectivity-Software 119 Connectrix 226 consistency group 404 Console Multiplexer Board 262 CONSOLE-ABORT 323 Content on Demand 18, 251 Content-Management 518 Continuous Access 346 Control Disk 263, 265 Control Station 256


Controller 29–30, 34, 37–39, 49, 56, 60, 70–72, 91, 96, 101

Controller-Target-Disk-Slice-Mimik 192 Controller-Target-LUN 121, 198 Cooked Files 29 crfs 446 CRM 236, 252 Crossbar 210 CSMA 56, 59–60 CTL-Mimik 29 CTP 222 D Daisy-Chain 170 DAP 209 DART 256 Data Base Tuner 482 Data Congestion 282 Data Frame 56, 58 Data Link Layer 56–57 Data Mining 253 Data Sharing 274 DataExchange 346 Dateisystem 251 Daten Service Modul 160 Datendurchsatz 255 Daten-Kommunikations-Protokolle 53 Datensicherheit 255, 271 DBMS 202 defect-Untermenü 48 Delayed Write 180 Density 34–36 Desaster- Recovery 183, 254, 411 Destage-Notification 181 Destaging 172 Operationen 434 Device 175 Device Control Software 245 Device Discovery 243 Device Name 333 Device Statistics 497 Device-Allokation 482 Device-Gruppen 426 Device-Performance 497 devices-Verzeichnis 30 Dial In 263 Direct Attached Storage 119 Direct Attachment 131 Director Layout 488 Director-Board 167–168 Disk Access-Prozessor 209

Disk Administrator 411 Disk Array 22 Disk Director 162 Disk Group 146, 157, 461 Disk Mirroring 20–21, 155 Disk Mode 186 Disk Reallocation 482 Disk Striping 155 Disk-Adapter 147, 162 Disk-Interface-Karte 154 Distanz-Topologie 119, 137, 181, 232 Distributed Shared Storage 313 DNS 225 Domain ID 225 Domain Relocation 242 Domino 186 DOS 36–37 Double Error Detection 191 DS-16B 227 DS-8B 227 DSA 364 Dual Cluster Lock 285 Dual Initiation 165 Dual Ported 147 Dual Porting 20–21 Dual-Bus-Architektur 174 Dual-Initiated 147 Dual-Initiated Disk-Adapter 172 Dual-Pathing 190 Duplex Subscriber-Konnektoren 219 Dynamic Multipathing 125, 214, 235, 267 Dynamic Optimizer 347 E EBCDIC-Code 65 ECAD 252 ECC 156, 481 ECC SDR 347 ECC Symmetrix Optimizer 347 ECC Workload Analyzer 347 ECC-Solution Enabler 346, 348 E-Commerce 253 ED-1032 227 ED-5000 Enterprise Director 227 EDM 273 E-D-TOV 230 EEPROM 320 EFP 228 EIA 52 Einrichtung eines BCV 384 EMC Control Center (ECC) 347, 481, 483 531


EMC Foundation Suite 460 EMC PowerPath 485 EMC Solution Enabler SymCLI 485 EMC2 156, 171, 263 EMC2‘s TimeFinder Toolkit 476 EMS HA-Monitor 156 Enterprise Agenten 506 Enterprise Management Framework 488 Enterprise Portal 251 Enterprise Storage Connectivity 120 Enterprise Storage Network 26, 227 Enterprise Systems Connection 165 Enterprise-Portal 18 E-Port 139, 216 E-Port-Segmentierung 230 ERP 252 Erweiterte Agenten 506 ESCON 120, 164–165 ESCON Channel Director 164 ESCON-Protokoll 28 ESCON-zu-ESCON 138 ESN Manager 347, 482 establish 420, 509 Ethernet 150, 256 Event Alert 484, 505 Exception Handling 502 Exchange 93–95, 518 exchange fabric parameter 228 Exportieren 75 exportvg 446 Extended Distance Port 217 Extended Partition 411 extends 427 extendvg 443 externe Ports 164 F FA 124–125 Fabric 216, 225 Fabric-Management-Software 232 Fabric-Topologie 218 Failback 147, 276, 399, 509 FAILBACK-POLICY 292, 296 Failover 23, 147, 276, 399, 509 Failover-Knoten 275 Failover-Mechanismen 217 FAILOVER-POLICY 292 Fan-In 245 Fan-Out-Rate 135, 236 Fast Wide Differential SCSI 28

532

Fast Write 179 Fast/Wide SCSI 149, 154 Fast/Wide SCSI-Bus 154 FAT 412 fault-tolerant disk driver 417 FC-AL 118 FC-AL Back-End 170 FC-AL Hub 125 FC-AL-Distanz-Topologie 138 FC-AL-Hub 134 FC-AL-Topologie 173 FCC-IOC 223 FC-HBA 125, 127 FCIP 521 FC-SW 127, 135, 256 FC-SW Back-End 170 FC-SW-Topologie 173 FDDI 56, 149, 151, 256 Fehlertoleranz 19, 21 Fencing Logic Redundant Unit 190 Fencing-Logik 191 Fibre Channel 23, 28, 77–95, 97–98, 100–115, 154 Fibre Channel Channel-I/O Controller 223 Fibre Channel Class2 Service 218 Fibre Channel Class3 Service 218 Fibre Channel ClassF Service 218 Fibre Channel Common Transport Protocol 95 Fibre Channel Direct Attachment 245 Fibre Channel Director 164 Fibre Channel Fabric Switch 145 Fibre Channel Multiplexer 214 Fibre Channel over IP 521 Fibre Channel Remote Link Director 167, 397 Fibre Channel-Adapter 23, 119 Fibre Channel-Architektur 173 Fibre Channel-Host-Bus-Adapter 133 Fibre Channel-Hub 145 Fibre Channel-Protokollstack 28 Fibre Channel-Standard-Implementierung 28 Fibre Channel-Switch 215 Fibre Channel-Switched Fabric-DistanzTopologie 139 Fibre Channel-Switched-Konfiguration 152 Fibre Channel-Switching-Hardware 216 Fibre Channel-Systemadapter 124 Fibre Channel-Technologie 118 Fibre Channel-Topologien 132 Fibre Channel-to-SCSI Bridge 145, 214 Fibre Channel-to-SCSI-Router 214


Field Replaceable Unit 224 File System Typ 335 File-Server 18, 24–25, 251, 264 File-Services 257 Filesystem 273 FIPS 52 Firmware 157 FIRST-CLUSTER-LOCK-VG 281, 284 FlashCopy 518 Flexible Mirror 199, 254, 273, 381, 419, 482 Floating IP-Adressen 300 Flow Control 225 Forced Destage 179 F-Port 135, 168, 217 Frame Delivery Order 225 Frame Pacing 114 Frame Switch 106 Frame-Header 240 Free Hog Partition 47 Front-End 162 Front-End Layout 489 FRU 190, 224, 265 fsck 267, 299 ftdisk 417 FTP 66 FTSC 52 FWD 28–29 G GAB 317 gabconfig 328 Gartner 517 Gatekeeper Device 348 GBIC 212 geplante Ausfallzeiten 382 gethostbyname() 301 Gewährleistung einer konsistenten Trennung des BCV 384 Gigabaud Link Module 89 Gigabit Ethernet 84–85, 256, 517, 520 Gigabit Interface Converter 212 Global Shared Memory 162 Globalisierung 17 G-Port 217 Graph Track 347 group 428 Group Membership and Atomic Broadcast 317 GSM-Karte 220 GUI 262 GXX-Port-Karte 220

H HA Cluster Foundation Package 160 HAARQ 346 haconf 343 hadiskhb 331 hagrp 341 hagui 343 hahbsetup 330 HA-NFS 160 HARC 346 Hardware-Scan 411 hares 340 hastart 340 hastatus 340 hasys 329 Hauptspeicher-Boards 19 hauser 343 HBA 28, 147 HCP 209 HCRC 346 HDS 209 Heartbeat 20, 147, 278 heartbeat messages 147 Heartbeat Timeout Periode 282 HEARTBEAT-INTERVAL 281–282 HEARTBEAT-IP 280 Heartbeat-LAN 151 Heartbeat-Platte 315 heterogene Dateisystem-Umgebungen 411 heterogene Storage-Landschaften 516 High Availability 18 High Memory 175 HiPPI 27, 78, 101, 103, 231 Hi-Star 210 Hitachi 171 Hitachi Data Systems 209 HMDE 346 Hochverfügbare Speichersysteme 161 Hochverfügbarkeit 145 Hochverfügbarkeitsansatz 130 Hochverfügbarkeitslösung 136 Hop Count 227 Host Connection-Prozessor 209 Host-Bus-Adapter 22–23, 28, 30, 147 Hostkomponenten 20 hostname 70–73 Host-Umfeld 17 Hot Backup 202 Hot Backup-Funktionalität 384 Hot Backup-Modus 202 Hot Plug 263 533


Hot Plugging/Hot Unplugging 212 Hot Spare 197 Hot Spare-File-Server 256, 267 Hot Spare-Magnetplatte 196 Hot Spare-Platte 197 hot SWAPpable 265 HP 156 HP LVM 501 HP Omniback 273 HP-UX HFS 500 HSRC 346 HSSDC-Connectoren 89 Hub Connector 213 Hub-Cascadierung 212 Hub-to-Hub 138 Hunt Groups 98 I I/O-complete 179 I/O-Prozessor 159 I/O-Subsystem 19, 23, 25 I/O-Subsystemkomponenten 22 IBM 156, 263 IBM AIX JFS 500 IBM AIX LVM 501 ICMP 67 IEEE 52–53, 56–58, 96–97, 101–102 if-Status 71 IML 219 importvg 446 Independent Software Vendors 483 inetd 73 InfiniBand 517 InfoMover 346 Informations-Management 487 Informix 160 init.ora 486 Initial Machine Load 219 Inkrementelles Establish 510 Inkrementelles Restore 510 Instruction Fault 19 Instruction Retry 18 Intel 256 intent logging 456 Inter Switch Link 226 Inter Working Units 106 Interface-Protokoll 29 Intermix-Modus 115 Internet 160 Internet Content Provider 253

534

Internet Service Provider 253 Internetprovider 18, 251, 270 Interoperability Lab 520 Interoperability Laboratory 81 Interoperation 517 Inter-Switch-Link 218 IO per Sec 497, 499 IO/Sec 497 IODC 157 IP 61–62, 67–73, 78, 82, 96–98, 101, 113 IP-Adresse 151 der Service-Gruppe 333 IP-Netzwerke 24 IPX 61 ISA 256 iSCSI 517 ISDN 56–57 ISL 226 ISO 52–55, 65–66 ISP-IT-Technologie 272 ISV 483 J JAVA 262 Java 481 JBOD-System 82 Journaled Filesystem 255, 457 K Kanal-Failover 135, 158 Kanal-Load-Balancing 135 Kanalprozessor 165 Kapazitätserweiterungs-Topologie 117, 232 kaskadierte Loop 213 kernel hang 308 kernel spin 308 KEYBOARD-ABORT 323 Knowledge-Management 518 Kommunikationskanäle 314, 326 Kommunikations-Mailbox 175, 178 Kommunikationsnetzwerk 479 Komponentenredundanz 121 Konfigurationsfile 279 Konsistenz 202 Konsolidierungs-Topologie 129 Kontrollprozessor 219 Kontrollscript 309 Kurzwellen-Laser 238 Kurzwellen-Multi Mode-Laser Transmission 220 kurzwellige Laser 138


L Langwellen-Laser 238 Langwellen-Single Mode-Laser-Verbindung 220 langwellige Glasfaserverbindungen 137 langwellige/Single Mode-Glasfaser 138 LAN-Schnittstellenkarte 150 Laptop 259 Latenzzeit 218 Legato Networker 273 Legato Networker Backup-Software 348 Linux 256 Liste der Cluster-Systeme 326 LLT 317 Load Sharing 301 Load-Balancing 131 Log Desk 344 Logging Metadevice 457 Logical Data Volumes 290 logical partitions 427, 443 Logical Volume 193 Logical Volume-Manager 154, 426 lokale Spiegel 207 lokaler Netzwerk Interface Switch 302 Long-term Hit Ratio 496 Long-term IO/sec 496 Long-term Write Ratio 496 Longwave Fibre-Port 212 Loop Channel Director 173 low cost-Komponenten 19 Low Latency Transport 317 Low Memory 175 Low-Cost Massen-Provider 270 LRU-Algorithmus 181 Lüfter (Fan) Modul 219 LUEGFIX 64 LUN 29 LUN Configuration Manager 347 LUN Manager 347 lvcreate 430, 434 lvextend 435 LVM 153, 279, 426 Lycos 271 M MAC 303 MacData 520 Maestro 156 Magnetbandarchive 216 Magnetplattencontroller 147 Magnetplatten-Subsystem 22

MaH 17 Mainframe 479 Mainframe-Umgebung 28 Maintenance IP-Adresse 322 Maintenance Port 219 MAN 56 Management Konsole 506 MANUAL 297 Mapdatei 432 Mapfile 290, 432 Master Metadevice 457 maxvgs 428 MC/Serviceguard 145, 276 McData 226 Media Interface Adapter 90 Member Devices 498 Message Path Controller 219 Meta Device 193, 412, 498 Meta Flexible Mirror 208 Meta Head 193 Meta Volumes 208 Metadata Logging 267 Metadevices 456 Meta-Head 498 metainit 457–458 metastat 456 Metatrans Device 457 MetroCluster ServiceGuard 145 Microcode 193 Microsoft 255 Midplane 169 Mindestanforderungen für Handelssysteme 17 MIN-PACKAGE-NODE 293 Mirror Device 493 MirrorDisk/UX 155 mirrored Device 493 mkdir 459 mkfs 465 mklv 445, 447 mknod 428 mkvg 443–444 Monitoring 156 Motherboard 256 mount 459 MS Windows NT 411 Multi Mode-Glasfaserkabel 138 Multi Switch Fabric 217, 224 Multicast Groups 98 Multicasting 58, 100, 113, 115

535


Multipath Failover 256 Multipath Load-Balancing 256 Multipathing 158 Multiple Flexible Mirrors 207 Multiple-Equal-Cost-Paths Algorithmus 239 Multiple-Source-to-Single-Target 183 Multiplexer 259 MVS 251 N Name Service 231, 243 Name, des Clusters 326 des Remote Systems 326 Name, Service-Gruppe 333 Namenskonvention 38 Nanocopy 346 NAS 17–18, 24–26, 251 NAS 300G 521 NAS-Server 479 NAS-Server-Systeme 255 NAS-Volume 263 NDMP 273 NetApp 760 263 Network Appliance 521 Network Attached Storage 18, 24–26, 73, 109, 251 Network Interface Card 256 Network Layer 60–61 Network Storage Applications 253 Networked Storage 274 Network-Filesystem 65 Network-Manager 300 NETWORK-POLLING-INTERVAL 281 Netzwerk als System 17 Netzwerk-Manager 277 Neustart der Transaktionen 385 newfs 459 NFS 25, 65–66, 73–76, 255, 312 NFS-Mount 273 NIC 256 NIS 66 NL-Port 124, 133, 217 NODE-FAIL-FAST-ENABLED 308 NODE-NAME 295 NODE-TIMEOUT 281 Not Ready To Host 146, 187, 378, 399 Not-Ready To-Host N-Port 133, 168 NTFS 412

536

O Object Data Manager 446 OC-3 256 ODM 446 offline 333 OLTP 364 On-Board-Redundanz 189 online 333 Online-Ansatz 202 Online-Datensicherung 155 Open Management Framework 502 Open Systems 17–18 OpenView 483 OpenView Storage Area-Management 519 Optimizer 482 Oracle 160, 486 oracleredo 364 OSI 53–55, 61–62, 65–66 OSM 488, 492 Outgoing Modem 260 P Package 146, 288 Package-IP-Adressen 300 Package-Koordinator 291 Package-Manager 277 Package-Switch 148 PACKAGE-SWITCHING-ENABLED 292 Parallel Channel Director 163 Parity 155 Parity Device 196, 205 Parity-Informationen 22 Partitioning 38–40, 47 Partitions 411 Partition-Tabelle 40–42, 47, 49 Path Manager 346 Patrol 156, 483 PCI 256 PE Size 427 Pentium 256 Performance 255 Performance Manager XP 347 Performance-Engpässe 512 Phone Home 263 Physical Device 193 physical partitions 427, 443 Piggy Back-Transfer 57 pkgadd 325 Planung der SAN-Entwicklung 483 Planung des Clusters 326


Plattenspiegelung 155 Plex 461 Point in Time-Datensicherung 200 Point-to-Point 62, 79, 102–104, 160 Poller-Schnittstelle 302 Port-Contention 218 Port-Karte 219 Portmapper 64 Port-Nummer 63, 68 Powderhorn 273 Power Module 189 Power PC 750 168 Power Supplies 19, 219 Powerkonverter 260 powermt 379 PowerPath 346, 379, 511 Preexisting Network Partitions 316 Prefetch Tasks % 497 Prefetch Tasks Percentage 497 Prefetch Util % 496 Prefetch Utilization Ratio Percentage 496 Prefetch Window 181 Presentation-Header 66 primäres Interface 150 Primary Node 147 Primary Partition 411 Principal Switches 225 privates Netzwerk 275 privates VCS-Netzwerk 312 probe-scsi-all 320 Produktiv-Failover-Szenario 492 Program Counter 308 prtvtoc 331 Public Loop 103, 108 PureTec 271 PV ID 427, 443 PV Size 427 PV-Link 155 PVRA 427 Q Quad Bus 175 Quad-Fast-Ethernet 321 Quick-NFS Wizard 332 Quick-Start Wizard 326 Quick-Start Worksheet 327 R RA-Gruppe 183 RAID 193

RAID 1 155 RAID 5 155, 195 RAID Manager XP 346 RAID protection 493 RAID S 195 RAID-Level 155 RAID-Standard 22 RARP 67, 83 R-A-TOV 230 Raw Files 29 RCP 65 rcpinfo 64 RDF1+ Mir 377 RDF2 377 RDF2+ Mir 377 Read Enabled 187 Read Hit Ratio 498–499 Read/Write Enabled 154, 378 Read-I/O-Request 177 Read-Only Data Warehouse 200 Read-Only Device 378 Read-Write-Enabled 399 rearp-Funktion 303 Reboot 267 Recovery 20–21, 200, 202 Red Hat Linux 263 Redo-Logfile 385 Redundant Array of Inexpensive Disk 193 Redundanz 19–20, 22, 145 Redundanzprüfung 59 Re-Formierung 278 Registered State Change Notification 231 Registry 411 Rekonfiguration 33 Relocatable IP-Adressen 300 Remote Control 347 Remote Flexible Mirrors 208 Remote Link 183 Remote Link Director 166, 181 Remote Mirror 198, 273, 419, 485, 493 Remote Mirroring 254, 399 remote Server-/Storage-Verbund 138 Remote Service 271 Remote Storage Array 144, 181 Remote Switching 305 remotely mirrored Device 493 Repeater 168 replicated state machine 312 Replikate 382

537


Replikation 272 Rerouting Delay 230 Resource Availability 482, 503 Resource Manager 347 Resource View 482, 500 Restart 255 RESTART-COUNT 310 Restore 421, 510 RESTORED 422 Restore-Funktionalität 390 Resynchronisation 204 Rezentralisierung 17 Rezentralisierungskonzepte 129 RJ45-Twisted Pair 223 RLD 166 Rlogin 262 ro 335 Rollforward 390 Root-Disk 155 Router 151 Routing 225 RPC 63–64, 66, 74, 481 rpc 263 RS 377 RS232 Heartbeat 152 RS6000 443 RSCN 225, 231 Runaway Realtime Process 308 Rw 335 S S/390 Mainframe 491 S/390-Systemarchitektur 27 S1 Device 185 S2 Device 185 Safety Timer 278 SAM 278 SAN 17–18, 20, 22–27, 32, 80–82, 90–91, 98, 103, 116, 251 SAN und NAS Infrastruktur 520 Sangate 519 SAN-Konfiguration 483 SAN-Leistungsoptimierung 483 SAN-Topologien 143 SAP R/3-Datensicherung 517 SBCCS 101 SC 219 Schwellwert 498 SCN 246 SCSI 27–30, 34, 37–38, 44, 49, 78–79, 82, 86, 101–103, 109

538

SCSI Channel Director 163 SCSI Device-Administration 28 SCSI Storage Device 28 SCSI-2-Festplatte 44 SCSI-Adresse 154 SCSI-Back-End 170 SCSI-Bus 157 SCSI-Controller 30, 157 SCSI-HBA 120 SCSI-Host-Bus-Adapter 30 scsi-initiator-id 320 SCSI-Interface 29 SCSI-Protokoll 27–28 SDDR 482 Secure Manager 346 Seeding 316 Segmentierung 225 Selbstdiagnose-Algorithmen 191 Semi-synchronous 186 Sequenz 94–95 Server Connections 137 Server Interconnect Board 266 Server-/Storage-Verbindungen 138 Server-/Storage-Verbund 138 Server-Konsolidierung 269 Serverkonsolidierungs-Topologie 485 Service Group Heartbeat Disks 316 Service Pack 425 Service-Gruppe 316 Serviceklassen 97, 102–103, 106, 109 Service-Server 96, 99 SGA 513 ShadowImage 346, 518 shareall 75 Shared Bus 158 Shared Global Area 513 Shared Storage 313 Shared Volume Groups 289 Shark 263, 345 Shortest-Path-First-Algorithmus 239 Short-term Hit Ratio 495 Short-term IO/sec 495 Short-term Write Ratio 495 Shortwave Fibre Port 212 show-devs 320 SIB 266 Signatur 416 Silkworm 226 Single Cluster Lock 285


Single Error Correction 191 Single HBA-Zoning 244 Single Point of Failure 146 Single-ended SCSI 154 Single-HBA-Zoning 232 Slice 193, 324 slice 44–45 Slot 30, 60 Slot-Set 184 SMTP 66 Snapshot 496 SNMP 66, 97, 223, 488 SOLARIS 28–30, 34, 38–40, 42, 44, 46, 49, 70 Solstice 160 Solstice DiskSuite 456 SPARC-Station 35 Spare Part 19 Spare-Port Card 224 Special File 29–30, 32–37, 39 Speicheragenten 506 Speicherkonsolidierungs-Topologie 232 Speicher-Landschaft 479 Speichermedien 17 Speichernetzwerk 479 Speicher-Pool 505 Speicher-Software 479, 517 Speichersysteme 17 Split 193, 423, 492, 509 Splitting 175 SPU 145 SPX 62 SQL Monitoring 513 SQL Server 518 SRDF 346, 422, 485, 509 SRDF Manager 509 SRDF/TimeFinder Manager 482 SSP 223, 518 Standard-Device 185 Standardisierung 519 Standard-Partition-Layout 40 Standby Interface 150 Standby-Cluster-Knoten 149 Standby-LAN 149 Stationäre IP-Adressen 300 STATIONARY-IP 280 Stern-Topologie 151 STK 506 Storage Area Networks 17, 22–23 Storage Array 18, 22–23, 30, 32, 79–80, 82, 91, 102, 108–109, 147, 216, 479

Storage Connectivity 138 Storage Device 24–27, 79, 98, 101, 131, 159 Storage Networking World 2001 520 Storage Service Provider 518 Storage-Administrator 513 Storage-Control 169 Storage-Konsolidierung 183 Storage-Konsolidierungs-Topologie 118, 132 Storage-System 27–28 StorageTek 273, 506 Stored Procedures 512 Strato 271 Stripe Set 412 Striped Volume 458 Striping 433, 447 Stromausfall 23 Stubs 63–64 Sub-Cluster 284 Subdisks 461 Subnet 149 Subnet-Maske 71 Subnetting 69 SUN 160, 255, 321, 456 SUN Enterprise Cluster-HA 160 SUN SOLARIS USF 500 SUNService HA Support-Paket 160 Switch 128, 479 Switched Connectivity 215 Switched Fabric 79–81, 91, 100–101, 104 Switch-Hop 218 Switching-Hub 145 Switch-Port 149 Switch-to-Switch 138 Sybase Adaptive Server Enterprise 160 symapi.db 348 symbcv 366, 381 symcfg 353 SymCLI 348, 482, 510 symcli 349 SYMCLI-DB-FILE 350 SYMCLI-DG 350 SYMCLI-NOLOGGING 350 SYMCLI-NOPROMPT 350 SYMCLI-OFFLINE 350 SYMCLI-SID 350 SYMCLI-VERBOSE 350 SYMCLI-VG 350 symdev 371 symdg 360 symgate 355

539


syminq 351 symioctl 391, 396 symld 362 Symmetrix 482 Symmetrix (Dynamic) Disk Reallocation 485 Symmetrix Database Tuner 486, 512 Symmetrix Manager 481 Symmetrix Manager Control Utility 413 Symmetrix Remote Data Facility 509 SYMMETRIX-System 32 symmir 386 symntctl 414 sympd 370 symrdf 399 symstat 357 Synchronisieren eines BCV 384 SYNCHRONIZED 420 Synchronous 186 System Bus 190 System Clock 221 System Service Prozessor 223 Systemadapter 147, 162 Systembus 171 System-Performance 494 Systemskalierbarkeit 255 System-V- Gewohnheit 32 T T1/T3-Telefon-Protokoll 182 Tablespace 503 TACHYON 168 TAG 330 Tape-Control-Kommando 35 Tape-Libraries 131 Tape-Roboter 131 Target 29–30, 34, 37–38, 49 Target-LUN 492 TCP 61–62, 67–68, 70, 72–74 TCP/IP 153, 520 TELNET 66 Telnet 262 Testdatenbestände 200 Three-Tier-Installation 480 Threshold 484, 499 Throughput 498–499 Tiebreaker 284 TimeFinder 346, 381, 417, 518 TimeFinder BCV 510 TimeFinder Component 485 TimeFinder Manager 510

540

Tivoli 156, 483 TME 507 TNG 507 TOC 278 Token Ring 150 Token-Management 63 Top-High 165 Top-Low 165 Topologieplanung 232 Total Cost of Ownership 268 Total Hit Ratio 498–499 Total Storage IPStorage 200i 521 TP 62, 88 Track Table 174 Transaktionsjournal 264 Transaktions-Protokoll 202 Transceiver 169 Transfer of Control 278 Transport-Header 62–63, 66 Trendanalyse 515 Trennung eines BCVs von seinem Standard-Device 385 Trigger 512 U UDP 62, 68, 74, 303 Überwachung des SAN 483 ufs 335 UFS-Logging 457 ULP 95, 101–102 Ultra Wide Differential 172 Ultra Wide Differential SCSI 28 Ultra-SCSI 172 uname() 326 unidirektionale Konfiguration 183 uninterruptable power supply 148 UNIX 251 UNIX-Derivate 29 unprotected 493 UnShared Channel 163 Unternehmenskooperationen 519 UP 377 UPS 148 UWD 28–29 UWD SCSI 256 UWD-SCSI 215 V varyoffvg 446 varyonvg 446


VCS 161, 276, 311 Verfügbarkeit 17–20, 26, 255 Verfügbarmachung großer Speicherkapazitäten 17 Verifikations-Request 231 VERITAS 161, 321, 460 Veritas 519 VERITAS Cluster-Server 161, 276, 311 Veritas DMP 123 VERITAS Dynamic Multipathing 348 VERITAS File System 460 VERITAS NetBackup 273 VERITAS Volume-Manager 161, 460 VERITAS VxVM 501 Vermittlungsschicht 55–56, 58, 60–61, 66 Vertex 518 Verwendung des BCVs 385 VG ID 427 VG Size 427 VGA 259 vgcfgbackup 287, 432 vgcfgrestore 287, 432 vgchange 291, 431 vgchgid 432 vgcreate 428 VGDA 427, 443 vgdisplay 429 vgexport 431 vgimport 290, 428, 432 vgscan 427 Video on Demand 18, 251 virtuelle Terminals 66 Volume 155, 461 Volume Logix 485, 507 Volume Set 412 Volume-Gruppe 288, 426, 443 VolumeLogix 346 Volume-Management 500 VRTSvxtf 460, 476 vxdg 331, 462 vxdg adddisk 331 vxdiskadd 462 VxFS 460 vxfs 335 vxmake 463

vxrecover 462 vxsd 463 vxsymsplit 477 VxVM 161, 323, 460 vxvol 464 W WAN 56 Web-Schnittstelle 480 Windows 2000 251 Windows NT 251, 256 Windows NT Disk Administrator 501 Windows NT FS 500 with parity distribution 493 WLA 487, 514 WLA Archiver 515 WLA-Analyzer 515 WLA-Archive 515 Workload Analyzer 514 Workload Analyzer/Archiver 487 World-Wide-Name 225 Write % 496 Write Disabled 187 Write Pending 180 Write Pending Mode 186 Write Percentage 496 Write Ratio 498–499 Write-Disabled 399 Write-I/O-Request 179 WWN 225 WWN-Alias 248 WWNN-Based-Balanced-Loads Algorithmus 239 X XDR 65 xhost 343 XRC 346 Z Zone 243 Zone Allocation Manager 346 Zoning 128, 217, 225 Zwilling 19

541

Storage Area Networks Network Attached Storage. Hohe Datenverfügbarkeit durch Speichernetzwerke

Storage Area Networks for Dummies

Storage networks

Storage Area Networks: Designing and Implementing a Mass Storage System

Storage Area Networks: Designing and Implementing a Mass Storage System

Special Edition Using Storage Area Networks

Storage Network Performance Analysis

Storage Networks: The Complete Reference

Building Storage Networks (Second Edition)

Building Storage Networks Second Edition

Storage Area Networks (SAN) in Germany: A Strategic Reference, 2006

Data Storage

Energy Storage

Storage Solutions

The Holy Grail of Network Storage Management

Distributed Storage Networks: Architecture, Protocols and Management

The business case for storage networks

Grain storage techniques

Storage Networking Protocol Fundamentals

Memory Mass Storage

Complete Home Storage

Oracle Automatic Storage Management

Optical Data Storage

Food Storage Stability

Aboveground Oil Storage Tanks

Food Storage Stability

Resilient Storage Networks : Designing Flexible Scalable Data Infrastructures (Digital Press Storage Technology (Paperback))

Food Storage Stability

Home Storage Solutions

Carbon capture and storage

Storage Area Networks Network Attached Storage. Hohe Datenverfügbarkeit durch Speichernetzwerke

Storage Area Networks for Dummies

Storage networks

Storage Area Networks: Designing and Implementing a Mass Storage System

Storage Area Networks: Designing and Implementing a Mass Storage System

Special Edition Using Storage Area Networks

Storage Network Performance Analysis

Storage Networks: The Complete Reference

Building Storage Networks (Second Edition)

Building Storage Networks Second Edition

Storage Area Networks (SAN) in Germany: A Strategic Reference, 2006

Data Storage

Energy Storage

Storage Solutions

The Holy Grail of Network Storage Management

Distributed Storage Networks: Architecture, Protocols and Management

The business case for storage networks

Grain storage techniques

Storage Networking Protocol Fundamentals

Memory Mass Storage

Complete Home Storage

Oracle Automatic Storage Management

Optical Data Storage

Food Storage Stability

Aboveground Oil Storage Tanks

Food Storage Stability

Resilient Storage Networks : Designing Flexible Scalable Data Infrastructures (Digital Press Storage Technology (Paperback))

Food Storage Stability

Home Storage Solutions

Carbon capture and storage

Recommend Documents