Veritas Storage Foundation: High End-Computing für UNIX, Design und Implementation von Hochverfügbarkeitslösungen mit VxVM und VCS

X. systems.press X.systems.press ist eine praxisorientierte Reihe zur Entwicklung und Administration von Betriebssystemen, Netzwerken und Datenbanken.

Volker Herminghaus · Albrecht Scriba

Veritas Storage Foundation® High End-Computing für UNIX Design und Implementation von Hochverfügbarkeitslösungen mit VxVM und VCS Mit 150 Abbildungen

123

Volker Herminghaus Bgm.-Jakob-Sieben-Str. 6 55268 Nieder-Olm [email protected]

Albrecht Scriba Friedrichsstr. 19 55124 Mainz [email protected]

Bibliografische Information der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.

ISSN 1611-8618 ISBN-10 3-540-34610-4 Springer Berlin Heidelberg New York ISBN-13 978-3-540-34610-4 Springer Berlin Heidelberg New York Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Springer ist ein Unternehmen von Springer Science+Business Media springer.de © Springer-Verlag Berlin Heidelberg 2006 Printed in Germany Veritas Storage Foundation ist ein eingetragenes Warenzeichen der Firma Symantec. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Text und Abbildungen wurden mit größter Sorgfalt erarbeitet. Verlag und Autor können jedoch für eventuell verbliebene fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Satz und Layout: Chris Fuhlrott, art-works, Mainz Herstellung: LE-TEX, Jelonek, Schmidt & Vöckler GbR, Leipzig Umschlaggestaltung: KünkelLopka Werbeagentur, Heidelberg Gedruckt auf säurefreiem Papier 33/3100 YL – 5 4 3 2 1 0

Für 将貴, 貴統 und 真理 V.H.

Für meine Familie A.S.

Für Max und Bettina C.F.

EDITORIAL

Hochverfügbarkeit ist in heutigen Rechenzentren längst zur unverzichtbaren Mindestanforderung geworden. Durch das Anbieten ständig erreichbarer Dienste über das Internet wird die Qualität der eigenen EDV den Kunden gegenüber exponiert. Jeder noch so kurzfristige Ausfall wird nach außen sichtbar und kann dem Vertrauen in den Anbieter schaden. Wie aber lassen sich EDV-Systeme hochverfügbar machen? Es gilt, bereits beim Aufbau und der Architektur einer Lösung zu beachten, dass alle Komponenten redundant (normalerweise gedoppelt) ausgelegt sind und kein Single Point Of Failure (SPOF) verbleibt. Das beginnt schon bei der Versorgung des Gebäudes mit Strom und Netzwerkfunktionalität. Seit den Anschlägen vom 9. September 2001 werden sogar vermehrt parallele Rechenzentren betrieben. Es setzt sich fort über die Verwendung verschiedener Brandabschnitte eines Gebäudes, gedoppelte IP- und SAN-Netzwerkswitches und -anschlüsse, redundante Netzteile, Disks und vieles andere mehr. Es endet derzeit beim parallelen Betrieb mehrerer Server, die – entweder gleichzeitig oder wechselseitig – an derselben Aufgabe arbeiten. Diesen Setup bezeichnet man als HA-Cluster (High-Availability-Cluster). Natürlich nützt es wenig, schlicht alle Komponenten zu verdoppeln; man braucht auch die dazugehörige Steuerungssoftware, die die vorhandene Redundanz entsprechend ausnutzt. Dazu gibt es auf dem Markt etliche Produkte der etablierten Hardwarehersteller. Sun spiegelt Platten mit der Solstice Disk Suite oder seit Solaris 10 mit ZFS und clustert mit SunCluster 3. IBM benutzt seit den Anfängen von AIX einen Logical Volume Manager für den Storage und HACMP als Clusterlösung. HP verwendet eine lizenzierte (alte) Version von Veritas Volume Manager und ServiceGuard als Cluster. Für Linux gibt es mehrere in Entstehung befindliche oder bereits fertiggestellte Produkte sowohl für logische Volumes als auch zum Clustering. Auch Fujitsu, Silicon Graphics und die anderen Hardwarehersteller haben natürlich entsprechende Lösungen im Programm. Allen gemein ist jedoch dasselbe Problem: Durch ihre Herstellerabhängigkeit können sie ihr zweifellos vorhandenes Potential nur in homogenen Umgebungen ausspielen. Und wo gibt es noch Rechenzentren mit rein homogenen Lösungen? Durch die Vielzahl hinzugekaufter Lösungen und Lösungsteile (man denke nur an Reuters-Terminals, SWIFT-Anbindungen und ähnliches) landet jeder Betreiber eines Rechenzentrums früher oder später bei einer heterogenen Landschaft. Diese hochverfügbar zu halten gelingt nur dann, wenn gerade bei einem Ausfall – die Zeit ist knapp, die Nerven gereizt – das Bedienungspersonal optimal auf die Software eingespielt ist. Muss man in einem solchen Fall acht verschiedene Softwareprodukte beherrschen – je vier für Plattenspiegelung und vier für Clustering - so werden schnell Fehler gemacht, die fatale Auswirkungen haben können. Unter anderem aus diesem Grund hat sich die Storage Foundation der auf Hochverfügbarkeitslösungen spezialisierten Firma Veritas am Markt weitgehend durchgesetzt. Seit Mai 2006 kann die Storage Foundation für kleinere Systeme sogar kostenlos von der Symantec-Website heruntergeladen und benutzt werden. Die URL lautet http://www.symantec.com/sfbasic. Die Verfügbarkeit entsprechender Skills am Markt (in Form geschulter Administratoren) und die Verbreitung des Produktes bedingen und begünstigen sich gegenseitig. Anders als in vielen vergleichbaren Fällen hat hier jedoch erfreulicherweise das technisch bessere Produkt das Rennen gemacht. Denn je mehr man über die teilweise extrem diffizilen Problematiken von HA und die

VII

EDITORIAL

entsprechenden Lösungsansätze weiß, desto mehr lernt man die Veritas Storage Foundation zu schätzen. Allerdings haben wir in den gut zehn Jahren, in denen wir in diesem Umfeld tätig sind, nur sehr wenige Administratoren kennengelernt, welche die HA-Software in dem Maße verstanden hatten, wie es für einen sicheren Betrieb eigentlich notwendig gewesen wäre. Allzu oft trifft man auch heute noch vermeintliche Spezialisten, die beispielsweise einen identischen Aufbau gespiegelter Bootplatten für zwingend erachten, den „Jeopardy“-Zustand eines VCS-Clusters für dramatisch halten oder Backups zurückspielen, weil das Volume Management alle Seiten eines Spiegels als ungültig markiert hat und sie nicht weiter wissen. Besonders für die erfahreneren Leute, aber auch für alle, die sich vielleicht in Zukunft mit der Veritas Storage Foundation auseinandersetzen werden, haben wir Kursunterlagen für den Veritas Volume Manager und den Veritas Cluster Server erarbeitet, die sowohl zur Präsentation als auch zum Selbststudium geeignet sind – geeignete Trainingshardware natürlich vorausgesetzt. Dabei werden die Erfahrenen allerdings mehr profitieren als die Unerfahrenen, denn eine komplette Wissensvermittlung für den Neuling benötigt die Interaktion mit einem menschlichen Trainer. Die beiden in diesem Buch abgedruckten Kurse sollen – neben dem selbstverständlichen Ziel der Produktbeherrschung – dem erfahrenen UNIX-Administrator möglichst vollständiges Verständnis für das Produkt übermitteln, so dass auch ungewöhnliche, neue Zustände schnell verstanden und sicher beherrscht werden. Darüberhinaus ermöglicht erst das volle Verständnis der Software eine optimale Nutzung beim Entwerfen neuer oder beim Überarbeiten bestehender Lösungen. Eine vollständige Aufzählung aller Features, aller Befehle und Optionen und sämtlicher möglichen sogenannten „Best Practices“ werden Sie hier nicht finden. Aber Sie werden nach Durcharbeiten der beiden Kurse in der Lage sein, sich ihre eigene „Best Practice“ für Ihre eigene Umgebung herzuleiten. Und Sie werden in der Lage sein, aus der vielen Spreu, die mit heutiger Software auch bei Veritas ausgeliefert wird, die wirklich nützlichen Weizenkörner herauszupicken und sinnvoll anzuwenden. Um den Umfang nicht zu sprengen, haben wir uns hier auf das Übermitteln der Konzepte sowie den Aufbau und den Betrieb von Lösungen auf Basis der Storage Foundation auf Solaris beschränkt. Damit erhalten Sie prinzipiell auch das nötige Werkzeug, um Fehlerzustände zu analysieren und zu beheben. Allerdings ist der Bereich Fault Analysis sehr umfangreich und braucht zu viel Erfahrung, als dass man ihn sich schon als relativer Neuling der Materie sinnvoll selbst erarbeiten könnte. Deshalb ist bereits ein weiteres Buch in Arbeit, das sich auf die Analyse und Reparatur defekter Cluster (auch das kommt vor!) und defekter logischer Volumes konzentriert. Als Administrator in einem Rechenzentrum, das Veritas Software einsetzt, sollten Sie dieses Buch nur dann nicht lesen, wenn Sie folgende Fragen zu Volume Manager und Cluster Server genau und sicher beantworten können: Was genau ist eine DiskGroup, was ein Plex, was ein Volume, was eine Subdisk, und welche Aufgaben haben diese? l Was sind die einzelnen Bestandteile eines Layered Volume und wozu dienen sie? l Was ist ein DCO-Log und wozu dient es? l

VIII

EDITORIAL

Was ist ein Dirty Region Log und wozu dient es? l Wie kann ich einen bootfähigen „kalten Spiegel“ für Wartungszwecke abtrennen (z.B. um das Root-Filesystem zu vergrößern)? l Wie kann es sein, dass ein gespiegeltes Volume, dessen Spiegelseiten nach einem Crash inkonsistent sein können, trotzdem sofort gelesen und beschrieben werden darf? l Was genau bedeutet es, wenn der Cluster sich in einer „Jeopardy“ befindet und welche Einschränkungen bringt es mit sich? l Was bedeutet und wie entsteht das AutoDisable im Cluster? l Welche Bedeutung haben die „Ports“ auf GAB? l Wie kann ich die Clustersoftware updaten, das Betriebssystem eines Servers patchen oder eine neue Version der Datenbank einspielen, ohne dass Dienste gestoppt werden müssen? l Wieso sind nicht nur die Konfigurationsfiles auf allen Clusterknoten identisch, sondern auch alle maßgeblichen Einträge in den Cluster-Logfiles aller Maschinen? l Wieso hat VCS im Gegensatz zu den anderen üblichen Cluster-Produkten keine Probleme beim Ausfall eines kompletten Rechenzentrums (bei Split-Data-Center-Setup)? l

IX

ÜBER DIE AUTOREN Volker Herminghaus studierte Maschinenbau und Informatik in Darmstadt und arbeitet

seit 1987 mit Unix-Systemen. Er ist seit 1990 selbstständiger Consultant und Trainer und kooperiert seit 1997 eng mit Veritas. Er hatte die Idee und war für die Erstellung des Gesamtwerks verantwortlich. Er nimmt unter [email protected] gern Kommentare zu diesem Buch entgegen und leitet dort auch Kontaktanfragen an die Koautoren weiter. Dr. habil. Albrecht Scriba studierte Mathematik und Theologie in Mainz und habilitierte

dort 1998. Er arbeitet seitdem als Consultant und Trainer und ist seit 2001 bei Veritas in Wiesbaden als Trainer angestellt. Er steuerte Schulungskonzepte, viele Details sowie fast alle Übungsbeispiele und Musterlösungen bei und hat den Gesamttext immer wieder probegelesen, korrigiert und konstruktiv kritisiert.

Chris Fuhlrott studierte Kommunikationsdesign in Wiesbaden und betreibt in Mainz sein

Grafik-Atelier Art-Works. Er zeichnet für das gestalterische Konzept, das Layout sowie alle Grafiken in Teil 1 und streckenweise in Teil 2 verantwortlich.

X

DANKSAGUNGEN Neben unseren Familien für ihre Geduld mit den stets überbeschäftigten Autoren gilt unser Dank der Firma SQL-AG, Schweiz, ohne die dieses Buch nicht entstanden wäre. Dank auch an Christian Rabanus für unerschöpfliche und fundierte Einsichten in Volume-Manager sowie an Markus Schwindenhammer und Thomas Barella für stetige Bereitschaft zur Diskussion und für mehr als zehn Jahre Freundschaft. Dank auch an Uwe Mälzer für die Initialzündung und alles, was folgte ...

XI

Inhaltsverzeichnis TEIL I · VxVM · VERITAS VOLUME MANAGER EINFÜHRUNG

3

Problemstellung: physische Beschränkungen von Disks .........................................................4 Idealvorstellung .........................................................................................................................5 Konkrete Fähigkeiten von VxVM .............................................................................................6

DISKMANAGEMENT UNTER SOLARIS/VXVM

9

Disk-Management unter Solaris ........................................................................................... 10 Disk-Management unter VxVM .............................................................................................11 Installation von VxVM ........................................................................................................... 13 Befehlssammlung Kapitel 2 ................................................................................................... 14 Übungen: Installation von VxVM .......................................................................................... 15 Musterlösung ......................................................................................................................... 16

DISKGROUPS

17

Zweck von DiskGroups ........................................................................................................... 18 Befehlssammlung Kapitel 3 – 1. Teil .................................................................................... 20 Befehlssammlung Kapitel 3 – 2. Teil .................................................................................... 20 Übungen: DiskGroups ............................................................................................................ 21

VOLUMES

25

Eigenschaften eines VxVM-Volumes .................................................................................... 26 RAID-Konzept ......................................................................................................................... 27 Übersicht RAID-Level............................................................................................................. 28 Parity-Berechnung mittels XOR bei RAID-4 und RAID-5 ................................................... 29 Eignungskriterien der RAID-Level ........................................................................................ 30 Implementation von RAID in VxVM ...................................................................................... 30 Befehlssammlung Kapitel 4 ................................................................................................... 31 Übungen: Volumes erstellen .................................................................................................. 32

VOLUMES VERSTEHEN

35

Aufbau eines Volumes ........................................................................................................... 36 Aufbau eines Plexes ............................................................................................................... 38 Aufbau einer Subdisk ............................................................................................................ 39 Mirroring durch Plexes .......................................................................................................... 40 Namenskonventionen ............................................................................................................ 42 Antworten zu Verständnisfragen .......................................................................................... 44

VOR- UND NACHTEILE DER RAID-LEVEL

45

Vergleich der RAID-Level ...................................................................................................... 46 Entwicklung der Hard-Disks 1986 - 2003............................................................................ 47 Zustand 1986 ......................................................................................................................... 48

XIII

Zustand 2006 ......................................................................................................................... 49 Einfluss der Stripe-Size ......................................................................................................... 50 RAID-01 vs RAID-10.............................................................................................................. 51 Antworten zu Verständnisfragen .......................................................................................... 53

LOGS

55

Problem der Resynchronisierung........................................................................................... 56 Inkonsistenter Spiegel – Lösung durch DRL ........................................................................ 59 Befehlssammlung Kapitel 7 ................................................................................................... 60 RAID-5 Logs ........................................................................................................................... 61 Übungen: Logs ........................................................................................................................ 64 Musterlösung ......................................................................................................................... 65 Antworten zu Verständnisfragen .......................................................................................... 66 Antworten zu Verständnisfragen (Fortsetzung) ................................................................. 67

VOLUMES VERÄNDERN

69

Problemstellung: Dynamische Anforderungen an Storage ................................................. 70 Lösung mit VxVM .................................................................................................................. 70 Storage-Attribute ...................................................................................................................71 Verändern der Grösse von Volumes ...................................................................................... 73 Übungen: Volumes verändern ............................................................................................... 75 Musterlösung ......................................................................................................................... 76 Antworten zu Verständnisfragen .......................................................................................... 77

LAYERED VOLUMES

79

Problemstellung ..................................................................................................................... 80 Lösung mit VxVM: Layered Volumes .................................................................................... 81 Layered Volumes in der Praxis .............................................................................................. 82 Lesen und Interpretieren von Layered Volumes ................................................................... 82 Übungen: Logs und Trigger-Points ....................................................................................... 84 Musterlösung und Antworten zu Verständnisfragen........................................................... 85 Musterlösung (Fortsetzung) .................................................................................................. 86

RELAYOUT

87

Problemstellung: Performance- und Größenoptimierungen ............................................... 88 Änderung des Volume- und des Plex-Layouts ..................................................................... 88 Relayout und Convert ............................................................................................................ 89 Relayout-Vorgang schematisch ............................................................................................ 90 Relayout Job-Management ................................................................................................... 90 Befehlssammlung Kapitel 9 bis 11 ....................................................................................... 91 Übungen: Schwierigkeiten beim Relayout ........................................................................... 92

SNAPSHOTS

95

Problemstellung: Inkonsistentes Backup-Image .................................................................. 96 Lösung durch Snapshots ........................................................................................................ 98

XIV

Benutzung von Snapshots lokal ............................................................................................ 98 Resynchronisieren von temporär abgetrenntem Spiegel .................................................... 99 Ablaufdiagramm Snapshot – Offline ................................................................................. 101 Offhost Processing ............................................................................................................... 102 Aufspalten von DiskGroups ................................................................................................. 103 Ablaufdiagramm Snapshot – Offhost ................................................................................ 104 Benutzung von Snapshots – Offhost .................................................................................. 105 Übungen: Snapshots mit und ohne FMR ............................................................................ 106 Musterlösung ....................................................................................................................... 107 Antworten zu Verständnisfragen ........................................................................................ 108

ROOT DISK SPIEGELUNG UND DER BOOT-PROZESS

109

Root-Disk unter Solaris ........................................................................................................110 Enkapsulierte Root-Disk .......................................................................................................110 Root-Disk Spiegelung .......................................................................................................... 112 Boot-Vorgang bei Solaris 9 ................................................................................................. 114 Bereitstellen eines Not-Spiegels......................................................................................... 116 Befehlssammlung Kapitel 12 .............................................................................................. 117 Antworten zu Verständnisfragen ........................................................................................ 118

VXVM-ARCHITEKTUR

119

Treiber- und Prozess-Struktur von VxVM.......................................................................... 120

KOMMANDO UND KONFIGURATIONS-ÜBERSICHT

125

Disks & Diskgroups .............................................................................................................. 126 Subdisks ................................................................................................................................ 127 Plexes .................................................................................................................................... 127 Volumes ................................................................................................................................ 127 VxVM-Tasks.......................................................................................................................... 128 Volume aufbauen Schritt für Schritt ................................................................................. 128 Volume abbauen Schritt für Schritt ................................................................................... 128 Layered Volume manuell erzeugen ..................................................................................... 128 Boot-Disk enkapsulieren ..................................................................................................... 129 Boot-Disk-Enkapsulierung aufheben ................................................................................. 129 Snapshot-Volume erzeugen ................................................................................................ 129 Konfiguration sichern und wiederherstellen ...................................................................... 129 Solaris VTOC Tags ................................................................................................................ 129

GUI

131

GUI-Übersicht ...................................................................................................................... 132 GUI-Menüstruktur ............................................................................................................... 133

XV

TEIL II · VCS · VERITAS CLUSTER SERVER EINFÜHRUNG

137

Manuelle Umschaltung – Schritt 1 ................................................................................... 141 Manuelle Umschaltung – Schritt 2 ................................................................................... 142 Manuelle Umschaltung – Schritt 3 ................................................................................... 143 Umleiten der Clients ............................................................................................................ 144 Automatische Umschaltung – Hot Spare ........................................................................... 146 Automatische Umschaltung – Symmetrischer Cluster ..................................................... 147 Automatische Umschaltung: N-to-M Cluster ................................................................... 148 Automatische Umschaltung: parallele Services ................................................................ 149

ÜBERBLICK ÜBER VCS

151

Komponenten des VCS-Clusters: Hardware ....................................................................... 152 Komponenten des VCS-Clusters: Software ........................................................................ 153 Komponenten des VCS-Clusters: Konfiguration ................................................................ 154

INSTALLATION UND KONFIGURATION

155

Konfiguration des Heartbeat-Netzes.................................................................................. 156 Konfiguration des VCS-Clusters ......................................................................................... 157 Starten, Stoppen und Überwachen von VCS...................................................................... 158

AUFBAU EINER EINFACHEN SERVICEGROUP

161

Einführung in das GUI ......................................................................................................... 162 Öffnen und Schliessen der Konfiguration .......................................................................... 163 Die hochverfügbare Xclock ................................................................................................. 164 Online, Offline, Switch, Failover ........................................................................................ 165 Clear ...................................................................................................................................... 166 Flush .................................................................................................................................... 167 Übung: Xclock-ServiceGroup .............................................................................................. 169 Musterlösung Xclock-ServiceGroup ................................................................................... 170

FUNKTIONSWEISE VON VERITAS CLUSTER SERVER

173

Architekturübersicht ........................................................................................................... 174 High-Speed Kommunikation via LLT .................................................................................. 175 TX-orientierte Nachrichtenübermittlung via GAB ............................................................ 176 Feststellung von Mitgliedschaften via GAB ....................................................................... 177 Aufgaben des HA-Daemons (had) ...................................................................................... 178 Kommunikationsprinzip des HA-Daemons ......................................................................... 179 Überwachung von Ressourcen durch Agents ..................................................................... 180 Bestandteile von Agents ...................................................................................................... 181 Zusammenspiel der Komponenten ...................................................................................... 182

AUFBAU VON SERVICE GROUPS

185

Definition von ServiceGroup ............................................................................................... 186

XVI

Dependencies ........................................................................................................................ 188 Beispiel einer ServiceGroup................................................................................................. 189 Beziehung zwischen Agent und Resource .......................................................................... 190

APACHE WEB SERVER TEIL 1 · NETZWERKRESOURCES

193

Vorstellung der Apache-ServiceGroup ............................................................................... 194 IP-Resource .......................................................................................................................... 195 NIC-Resource ....................................................................................................................... 197 ResourceType-Attribute ...................................................................................................... 199 Übersicht und Struktur der ha-Befehle ............................................................................. 201 Übung: ApacheSG und Netzwerk-Resources ..................................................................... 202 Kommandos für ServiceGroups und Resources .................................................................. 203 Musterlösung und Antworten zu Verständnisfragen......................................................... 205

APACHE WEB SERVER TEIL 2 · FILE- & PROZESSRESOURCES

207

Process-Resource ................................................................................................................. 208 Concurrency Violation ......................................................................................................... 209 FileNone-Resource ............................................................................................................... 210 Übung ....................................................................................................................................211 Musterlösung ....................................................................................................................... 212

APACHE WEB-SERVER TEIL 3 · APPLICATION, MOUNT, DISK

213

Application-Resource .......................................................................................................... 214 Mount-Resource .................................................................................................................. 215 Disk-Resource ...................................................................................................................... 216 Übung ................................................................................................................................... 217

APACHE WEB-SERVER TEIL 4 · VOLUME UND DISKGROUP

219

Volume-Resource ................................................................................................................. 220 DiskGroup-Resource ............................................................................................................ 221 Die fertige ServiceGroup ..................................................................................................... 222 Übung ................................................................................................................................... 223

HEARTBEAT IM DETAIL

225

Allgemeine Clusterproblematiken ....................................................................................... 226 Heartbeat über GAB-Disks .................................................................................................. 227 Heartbeat-Verhalten ........................................................................................................... 230 Rejoin .................................................................................................................................... 231 Übung: Übernahmetests und GAB-Disks ............................................................................ 232

CLUSTER MAINTENANCE

233

Wartung von Systemen ....................................................................................................... 234 Wartung von ServiceGroups ............................................................................................... 235 Stillegen von ServiceGroups auf Systemen ........................................................................ 236 Configuration Recovery und Replication ........................................................................... 237

XVII

Event Notification und Trigger ........................................................................................... 238 Übung: Maintenance, Configuration und Trigger ............................................................. 239

REDUNDANTE NETZWERKANBINDUNG

241

Bündeln von Netzwerkinterfaces ........................................................................................ 242 MultiNICA-Resource ............................................................................................................ 243 NetSG, Phantom- und Proxy-Resource .............................................................................. 244 ApplicationSG und IPMultiNIC-Resource ........................................................................... 245 IPMultiNIC-Resource ........................................................................................................... 246 IPMultiNICB-Resource ......................................................................................................... 248 MultiNICB-Resource ............................................................................................................ 249 Übung: Redundante Netzwerkanbindung ........................................................................... 251

I/O-FENCING

253

Problemstellung: Überlast und parallele Applikationen ................................................... 254 Vorteil von I/O-Fencing gegenüber Quorum-Device ......................................................... 255 Arbeitsweise von I/O-Fencing bei parallelen Clustern (RAC/CFS) ................................... 257 Konfiguration von I/O-Fencing ........................................................................................... 260 Wiederanlauf nach erfolgreichem I/O-Fencing ................................................................. 262 Problematische Setups bei I/O-Fencing ............................................................................. 263 Übung: Konfiguration und Test diverser Szenarien ........................................................... 267

XVIII

KAPITEL 1

EINFÜHRUNG

1 1.1

EINFÜHRUNG Ist-Zustand – physische Beschränkungen von Disks Beschränkung der Größe

10 GB Datei

9 GB

9 GB

l

9 GB

9 GB

Beschränkung der Performance l

180 GB

Eine 10 GB Datei passt nicht auf eine 9 GB Disk – auch nicht auf mehrere davon.

Eine Disk erreicht ca. 100150 TX/s – zu langsam für viele Anwendungen.

Beschränkung der Sicherheit l

Ausfall einer Disk bedeutet den Ausfall der darauf befindlichen Daten.

Beschränkung der Flexibilität l

Die Eigenschaften einer Disk sind nachträglich nicht änderbar. 1.1

1.1.1

Problematik: die Unzulänglichkeiten von Disks umgehen Prinzipiell sind Disks allein durch die Tatsache, dass es sich bei ihnen um physische Gegenstände handelt, eingeschränkt. Diese Einschränkungen betreffen die folgenden vier Bereiche: Größe: Eine Datei, die größer ist als die zugrundeliegenden Disks, kann ohne Volume Management selbst dann nicht abgespeichert werden, wenn man unendlich viele Disks zur Verfügung hat. Performance: Durch die Mechanik der Disks ist die Anzahl Zugriffe auf ca. 100 bis 150 pro Sekunde beschränkt. Je größer Disks werden die Kapazität verdoppelt sich etwa alle 15 bis 20 Monate - desto weniger TPS (Transaktionen Pro Sekunde) können auf jedem GB Diskspeicher ausgeführt werden. Sicherheit: Fällt eine Disk aus, sei es durch Stromausfall oder Defekt, so sind die darauf gespeicherten Daten entweder temporär oder persistent verloren. Flexibilität: Eine Disk behält ihre physischen Eigenschaften und kann sie nicht ändern. Sie

4

passt sich den sich wandelnden Anforderungen der EDV nicht an. Wie in der EDV üblich lassen sich diese physischen Beschränkungen durch Virtualisierung aufheben. Virtualisierung heißt, es wird eine Zwischenschicht implementiert, die ein logisches Äquivalent der physischen Objekte zur Verfügung stellt und dabei die genannten Beschränkungen mit geeigneten Mitteln umgeht. Umgesetzt auf Disks würden also virtuelle Disks geschaffen werden, die die Beschränkungen physischer Disks aufheben. Dies kann sowohl als reine Softwarelösung implementiert werden oder in Form einer dedizierten Hardware (RAID-Arrays bzw. SAN-Speichersysteme, z.B. IBM ESS, HDS 9x00 oder EMC2 Symmetrix). Die dedizierte Hardware kann jedoch aufgrund mangelnder Flexibilität bei der Administration in der Regel nicht alle Vorgaben erfüllen, weshalb bei Enterprise-Anwendungen meist zusätzlich eine Softwarelösung wie Veritas Volume Manager (VxVM) verwendet wird.

EINFÜHRUNG

1

Guaredisch Idealvorstellung

1.1 1.2 Idealzustand wäre: l

Alle Disks als großer Pool. Alle Server aller Architekturen greifen auf den Pool zu. l Storage on Demand. l Storage so sicher, so schnell und so groß wie gewünscht. l Zuverlässige Anbindung der Server an die Disks. l Online Management mit minimaler Downtime. l

1.2

1.2.1

Idealvorstellung Was ist das Ziel von Volume Management? Das primäre Ziel jedes Volume Management Produkts ist die Aufhebung der durch die Physik der Disks vorgegebenen Grenzen durch Verwendung virtueller Objekte, sogenannter Volumes. Diese verhalten sich den darüberliegenden Layern (Filesysteme, Datenbanken etc.) gegenüber exakt wie physische Disks. Durch ihre softwaremäßige Implementation können jedoch die genannten Beschränkungen gelindert oder gänzlich aufgehoben werden. Die ersten drei Beschränkungen – Größe, Performance und Sicherheit – können schon mit vergleichsweise simplen Hardware- oder Software-RAID-Systemen aufgelöst werden. Der Unterschied zu einem erwachsenen Volume Management Produkt ist jedoch noch gewaltig. Eine der vielen Einschränkungen einfacherer RAID-Systeme besteht zum Beispiel darin, dass deren kleinste Einheit die Disk ist. Es können also nur komplette Disks gespiegelt oder gestripet werden. VxVM arbeitet im Gegensatz dazu konsequent mit Extents, also Teilen von Disks, was erst die benötigte Flexibilität ermöglicht. Formulieren wir zunächst einmal unsere Idealvorstellung als Ziel:

1. Alle Server sollen auf alle Disks zugreifen könnten; jede Art von Abgrenzung wäre freiwillig zu konfigurieren (z.B. über SANZoning etc.) 2. Die logischen Datenspeicher sollten frei von einem Host zum anderen wandern können. Dies ermöglicht zum einen HA-Lösungen (High Availability) als auch Prozesskettenverarbeitungen, wo jeweils spezielle Server für bestimmte Aufgaben herangezogen werden können. Sie importieren die Daten, verarbeiten sie und exportieren sie an die nächste Stufe der Prozesskette. 3. Immer dann, wenn ein Server mehr (Disk-) Storage braucht, soll dieser zeitnah und ohne Downtime angebunden werden können. 4. Der Storage sollte in jeder Hinsicht frei dimensionierbar sein, also so sicher, so schnell und so groß wie er gerade benötigt wird. 5. Die Anbindung der Server an die Disks sollte redundant und transparent sein, zum Beispiel durch gleichzeitige Benutzung mehrerer Pfade zum Storage. 6. Keine Aktion des Volume Management sollte zu einer Downtime führen.

5

1 1.1 1.3

EINFÜHRUNG Konkrete Fähigkeiten von VxVM Wie wird dies erreicht? 1. Alle Disks als großer Pool. 2. Alle Server aller Architekturen greifen auf den Pool zu. 3. Storage on Demand. 4. Storage so sicher, so schnell und so groß wie gewünscht. 5. Zuverlässige Anbindung der Server an die Disks. 6. Online Management mit minimaler Downtime.

1.3.1

Ë VxVM kann beliebig viele Disks verwalten. Ë VxVM ist architekturunabhängig und clusterfähig. Ë VxVM kann sowohl Disks als auch Diskplatz dynamisch online verwalten. Ë VxVM kann alle relevanten VolumeEigenschaften setzen und ändern. Ë VxVM basiert auf Dynamic Multipathing (DMP) und benutzt alle vorhandenen Pfade. Ë Alle Aktionen sind bei VxVM online möglich.

Wie nahe kommt Veritas Volume Manager dem Idealbild? Theoretisch implementiert VxVM unsere Idealvorstellung vollständig. Dennoch gibt es natürlich Einschränkungen, die nicht unerwähnt bleiben dürfen. Gehen wir schrittweise vor: 1. Es gibt kein festes Limit in der Anzahl verwaltbarer Disks. Wohl aber gibt es Nachteile, wenn zu viele Disks an einem System sichtbar sind. So schadet es einerseits der Übersicht, zum anderen kann das Importieren von DiskGroups, also das Reservieren bestimmter Storage-Resources, unter Umständen recht lange dauern, wenn viele Disks beteiligt sind. 2. VxVM ist architekturunabhängig und clusterfähig. Um genau zu sein: DiskGroups mit ihren Volumes und Filesystemen können seit der Version VxVM 4.0 tatsächlich zwischen Hosts verschiedener Architekturen hin- und herwandern. Dies ist allerdings beschränkt auf die UNIX- und Linux-Versionen (also ohne Windows) und funktioniert nur mit über das SCSI-Protokoll angesprochenen Disks. Über das ATA-Protokoll adressierte IDE-Disks sind (aufgrund architekturabhängiger Umsetzung von LBA- auf CHS-Adressierung) nicht kompatibel mit dem neuen Layout. Außerdem kann eine HP-Maschine wenig mit einem SolarisFilesystem anfangen. Das Ganze funktioniert also nur, wenn man entweder auf Raw-Devices zugreift (Datenbanken) oder ein Cross-Platform-Filesystem wie VxFS (Veritas Filesystem) verwendet. Über ein cleveres Reservierungsverfahren wird dafür gesorgt, dass stets nur ein einziger Host zu

6

1.3

einer Zeit Zugriff auf eine DiskGroup hat, was Clusterkonfigurationen vereinfacht. 3. Ohne Einschränkungen können jederzeit zur Laufzeit neue Disks zu VxVM hinzugenommen werden, vorausgesetzt das Betriebssystem unterstützt dies. Für Solaris wäre die Befehlskette (ohne Parameter) etwa folgende: cfgadm (Controllerhardware aktivieren) devfsadm (neue Devices in Solaris einbinden) format/fmthard (Solaris-Label schreiben) vxdisk scandisks (VxVM informieren) 4. Selbstverständlich kann VxVM sämtliche bekannten (sinnvollen) RAID-Level abbilden. Es tut dies allerdings nicht durch Spiegelung, Striping oder Concatenation ganzer Disks, sondern durch entsprechende Kombination von frei allozierten Teilen von Disks, sogenannten Subdisks. Dadurch können mit VxVM Disks mit beliebigen Geometrien frei verwendet werden. 5. VxVM integriert den VxDMP-Treiber (Dynamic Multipathing), der transparenten DiskZugriff über mehrere Pfade bietet und dabei komplexe Optimierungen in Abhängigkeit von I/O-Anfrage und Disk-Typ durchführt. 6. VxVM ist in der Lage, die Volume-Konfigurationen beliebig zu ändern (z.B. Umstellung von Mirroring auf Stripe-Mirror oder auf RAID-5), während das Volume gemountet ist und I/O darauf stattfindet! Darin ist VxVM derzeit einmalig. Wir werden später darauf eingehen, wie dies möglich ist.

EINFÜHRUNG

1

Alternativen

1.3.2

Welche Alternativen gibt es zu VxVM? Die Alternativen sind im Allgemeinen betriebssystemspezifisch, so dass wir diese Frage für jede einzelne UNIX-Version beantworten müssten. Ich möchte mich hier jedoch beispielhaft auf Solaris beschränken; ähnliche Konzepte findet man in Linux und anderen Plattformen. Zu den bekanntesten Alternativen für Solaris gehören die Solstice Disk Suite, die von Sun mit Solaris gebündelt wird und häufig trotz vorhandener VxVM-Installation zum Spiegeln der Rootdisks verwendet wird. Eine Neuentwicklung stellt ZFS dar, das zur Zeit aber erst seine ersten Gehversuche unternimmt und über das noch nicht viel gesagt werden kann, außer dass es sich sehr grundsätzlich von allen anderen Volume Management Produkten unterscheidet, da es das Filesystem mit dem Volume Management integriert und völig neue Denkansätze benötigt. Solstice Disk Suite implementiert sogenannte MetaDevices, die aus der logischen Verknüpfung von durch den User vorallozier-

ten Partitionen hervorgehen. Damit ist bereits eine große Schwachstelle von SDS identifiziert, denn so kann das Volume Management Produkt nicht in die Allokation eingreifen, etwa um ein Volume zu vergrößern oder dessen Layout nachträglich zu verändern. Ein anderer Nachteil liegt darin, dass SDS nicht von den Controllerpfaden abstrahiert, d.h. eine Disk wird primär über ihren Zugriffspfad identifiziert. Fällt ein Controller aus und wird die Disk nun über einen anderen Controller angesprochen, so werden die Basis-Partitions nicht mehr gefunden, und das Volume kann nicht benutzt werden. HP lizenzierte eine recht frühe Version von VxVM (2.x) und VxFS und liefert diese seitdem mit HP/UX zusammen aus. Der Logical Volume Manager von AIX ist eine Eigenentwicklung von IBM und basiert noch auf Blockadressierung im Gegensatz zu VxVMs Extentadressierung. Insgesamt ist er zwar vergleichbar, wirkt aber im direkten Vergleich etwas krude und alt.

1.3.3

Historische Information Bereits vor zwanzig Jahren bot DEC (Digital Equipment, später von Compaq, jetzt von HP gekauft) ein Disk-Subsystem mit ähnlichen Features wie VxVM heute. Alle Disks wurden in den Storage Pool getan, und aus diesem Pool wurde Platz alloziert, wenn dieser benötigt wurde. Es gab sogar eine im Hintergrund laufende Load-Balancing Funktion, welche die Daten auf den Disks neu verteilte, wenn sich Bottlenecks auftaten!

Einige ehemalige DEC-Entwickler arbeiten heute bei Veritas. Der Veritas Volume Manager wurde allerdings nicht von ehemaligen DECIngenieuren entworfen, sondern von Leuten der Firma Tolerant Transaction Systems, einer auf ausfallsichere Systeme spezialisierten Firma, aus der Veritas hervorging. Die Truppe wurde später durch Entwickler von Amdahl verstärkt und brachte 1990 VxVM und 1991 VxFS auf den Markt. 1998 folgte VCS.

7

KAPITEL 2

DISK-MANAGEMENT UNTER SOLARIS/VXVM

2 2.1

DISK-MANAGEMENT UNTER SOLARIS/VXVM Disk-Management unter Solaris VTOC:

2.1

2.1.1

Aufbau und Zweck der Volume Table Of Contents oder Partition Table Die VTOC dient zunächst einmal dazu, einzelne lineare Bereiche einer Disk von anderen Bereichen abzutrennen. Auf diese Weise können innerhalb einer Disk mehrere getrennte Filesysteme angelegt werden. Das Überlaufen des einen Filesystems (z.B. /var, das u.U. schnell wachsende Logfiles enthält) beeinträchtigt nicht mehr den freien Platz der anderen Filesysteme. Die durch die VTOC definierten Bereiche nennt man normalerweise Partitionen oder englisch Partitions, bei Solaris auch Slices. Wir möchten an dieser Stelle jedoch gleich zu einem anderen Begriff übergehen. Denn um VxVM vollständig verstehen zu können, müssen wir bereits sehr früh abstrahieren und fangen am besten gleich an. Die einzelnen Teile, in die die Disk durch die VTOC aufgeteilt wird, bestehen aus einem Beginn und einer Länge. Diese beiden Werte bilden die Beschreibung der Partition, legen also fest, wo letzlich Daten physisch liegen werden. Allgemein gesprochen, also abstrahiert, nennen wir ein solches Konstrukt einen „Extent“. Der Begriff des Extents wird uns von nun an immer wieder begegnen; Extents sind sowohl im VxVM als auch im VxFS (Veritas Filesystem) die Basiseinheit zur Datenspeicherung, und das gedankliche Umschalten auf Extents kann daher gar nicht früh genug geschehen. Da Sun von Anfang an eine Partitionierung von Disks vorsah, kann bereits das Boot-PROM

10

Volume Table Of Contents l Enthält Informationen über belegte Bereiche der Disk (Partitionen/Slices). l Auswertung bereits beim Booten (im Boot–PROM). l Wird vom Betriebssystem voll unterstützt. l Ist auf 8 Bereiche begrenzt. l Ein Bereich (Slice 2) wird systemintern benötigt l Zu wenig Platz für MetaInformationen eines Volume Managements

eine VTOC lesen und auswerten. So wird zum Beispiel der Anfangsblock des Root-Filesystems der Bootdisk darüber identifiziert, dass das Boot-PROM die VTOC der Bootdisk liest, den Extent sucht, der das Tag für „boot“ bzw. „root“ trägt, und von dort den Bootvorgang einleitet (viel mehr dazu später). Die Definition der VTOC stammt leider aus Zeiten, in denen noch kaum jemand an logische Volumes dachte, zumindest nicht im UNIX-Bereich. Daher ist sie sehr klein (512 Bytes) und enthält über die (maximal acht) Extents hinaus nur rudimentäre Informationen, nämlich ein Tag, das den vorgesehenen Verwendungszweck eines Extents angibt (root, swap etc), sowie einige Flags, aus denen hervorgeht, ob es sich bei den im Extent liegenden Daten um ein mountbares Filesystem handelt und ob es beschrieben werden darf (bzw. sollte; die Flags sind rein informativer Natur). Für Aussagen wie „dieser Extent verbindet sich mit diesen fünf Extents von jener Disk gekoppelt mit weiteren zwei Extents einer dritten Disk zu einem logischen Volume mit Stripe-Layout“ ist schlicht kein Platz. Damit fällt der VTOC im Rahmen des Volume Management nur noch eine untergeordnete Rolle zu. Die Metadaten selbst müssen woanders Platz finden.

DISK-MANAGEMENT UNTER SOLARIS/VXVM

2

Disk-Management unter VxVM

2.2 Für ein dynamisches Volume Management wird eine eigene Verwaltungsinformation benötigt. VxVM teilt daher die Disk in zwei Bereiche: l Private Region – Verwaltungsdaten. l Public Region – Nutzdatenbereich. Diese beiden Bereiche werden in der VTOC eingetragen, damit das Betriebssystem diese als belegt erkennt und nicht anderweitig verwendet. 2.2

Speicherung der VxVM-Metadaten in der Private Region Soll eine Disk von VxVM verwaltet werden, so wird sie zunächst für VxVM initialisiert. Dies geschieht mit dem im Directory /usr/lib/ vxvm/bin liegenden Befehl vxdisksetup i . Dabei geschieht bei einer bisher unbenutzten Disk folgendes: Zunächst einmal entfernt das Kommando alle vorhandenen (Default-)Partitionen außer Slice 2, denn dieser Slice wird von Solaris für das Betriebssystem selbst benötigt. Anschließend trägt es folgende zwei Slices in die VTOC ein: l Einen kleinen Slice für die Metadaten. Dieser wird als Private Region bezeichnet und ist mindestens 1 MB groß, auf ganze Zylinder gerundet. Normalerweise müsste die Private Region daher genau ein Zylinder groß sein. Tatsächlich reserviert das Initialisierungsprogramm von VxVM jedoch einen weiteren Zylinder für interne Zwecke. l Einen weiteren Slice für den freien Platz, innerhalb dessen später die Extents für die Userdaten alloziert werden. Dieser Slice wird als Public Region bezeichnet. Eine Disk, die so initialisiert wurde, trägt in der Terminologie des VxVM das Format „sliced“. Die Private Region verwaltet viel mehr Extents (die Extents werden bei VxVM „Subdisks“

2.2.1

genannt; ihre Anzahl ist praktisch unbeschränkt) und zusätzlich noch andere Informationen: l Zugehörigkeit zu Servern, d.h. welcher Host hat diese DiskGroup momentan reserviert. l Weitere Disks, die logisch zu dieser Disk gehören (DiskGroup Membership). l Mapping von Extents (Subdisks) zu logischen Disks (Volumes). l Viele weitere, intern benutzte Informationen wie Zustandsflags, Volume-Größen etc. Mit dem Eintragen der Slices ist es aber nicht getan, damit ist nur Platz reserviert. Die Private Region muss noch initialisiert werden. Dies wird durch das oben angegebene Flag „-i“ erreicht. Ohne dieses Flag ist der Befehl nur in Ausnahmefällen sinnvoll (z.B. um eine versehentliche Neupartitionierung rückgängig zu machen). Selbstverständlich gibt es zahlreiche Optionen für vxdisksetup, um das Format und die Größe der Private Region festzulegen und vieles mehr. Wir möchten dazu aber auf die man-Pages verweisen, da eine Besprechung den Rahmen und Ihre Aufmerksamkeit überstrapazieren würde.

11

2

DISK-MANAGEMENT UNTER SOLARIS/VXVM Verständnisfrage 2.1 Warum lässt VxVM den Rest der Disk (außerhalb der Private Region) nicht einfach frei? Wirklich brauchen tut er doch nur die Metadaten, oder?

Verständnisfrage 2.2 Warum werden die Verwaltungsinformationen in eine Partition bzw., im Falle von CDSDisks, in einen festen Diskbereich, geschrieben und nicht in eine Datei?

Verständnisfrage 2.3 Muss sich ein logisches Volume dem Betriebssystem gegenüber genau so verhalten wie eine physische Disk oder wie etwas anderes? Warum?

Hinweis Die Private Region wird nicht vom Betriebssystem ausgewertet, sondern nur vom VxVM-Layer! Dem Betriebssystem erscheint sie im sliced Layout wie eine normale (kleine) Partition. Das stellt im Betrieb kein Problem dar, wohl aber beim Booten von VxVM-Disks, da zu diesem Zeitpunkt nur die Partition Table ausgewertet werden kann und nicht die Private Region. Daher wird die Bootdisk enkapsuliert! Darauf wird später näher eingegangen.

2.2.2

Ein Wort noch zu den Diskpfaden: Die allgemeine, im UNIX-Umfeld übliche Benennung von Disks nach ihrem Zugriffspfad, also Controllernummer, Targetnummer, Disknummer, ist bei Solaris um die Slicenummer ergänzt worden. So wird beispielsweise die LUN 3 von Target 5 auf Controller 1 folgendermaßen adressiert: c1t5d3s2. Bei Solaris steht Slice 2 ja bekanntlich für das gesamte Device. Diese Notation ist aber nicht architekturunabhängig. So kennt beispielsweise HP/UX keine Partitions, da hier wie bereits erwähnt eine frühe Version von VxVM bereits im Betriebssystem integriert ist und somit Partitions nie nötig waren. Um die Adressierung von Devices innerhalb von VxVM betriebssystemübergreifend zu vereinheitlichen, wird daher die Slice-Angabe weggelassen und die Disk nur über c1t5d3 adressiert. Die Angabe von c1t5d3s2, beispielsweise beim Befehl vxdisksetup, führt zu einem Syntaxfehler. In der Terminologie von VxVM heißen die Diskpfade „Accessname“. Bei SAN-Storage verwendet VxVM sogenannte Enclosure Based Names als Diskpfade. Diese ergeben sich aus dem Typ des Arrrays sowie der Position der Disk im Array. Die EBNs werden dynamisch erzeugt und unterscheiden

12

sich, ebenso wie die Controllerpfade, oft von Host zu Host. Mit diesem Hintergrundwissen können wir nun die Installation von VxVM in Angriff nehmen. Glücklicherweise hat Veritas wenige Wochen vor Erscheinen dieses Buches die Storage Foundation für sogenannte Edge & Infrastructure-Server kostenlos zum Download freigegeben. Sie finden sie unter der URL http://www.symantec.com/sfbasic. In dieser Version sind laut Symantec alle Optionen freigeschaltet. Die einzigen Einschränkungen bestehen in einer Limitierung auf zwei physische CPU-Sockel und vier User-Datenvolumes (zusätzlich zu den zum Booten benötigten Volumes). Sinnvollerweise sollten die Dateien /etc/ system und /etc/vfstab in ihrer unveränderten Form bereits vor dem Installieren der VxVM-Packages unter anderem Namen aufbewahrt werden, da diese durch die Installation verändert werden können. Auf der CD bzw. im Image befindet sich ein ASCII-basiertes Installationsmenu namens installer bzw. installsf. Dieses Skript führt die Installation der Packages und ggf. der VxVM-Patches aus und konfiguriert das Produkt.

DISK-MANAGEMENT UNTER SOLARIS/VXVM

2

Installation von VxVM

2.3

Zur VxVM-Distribution gehören u.a. folgende Packages: VRTSvlic VRTSvxvm VRTSvmman VRTSvmdoc VRTSob VRTSvmpro VRTSfspro VRTSobgui

· · · · · · · ·

VERITAS License Utilities. VERITAS Volume Manager, Binaries. VERITAS Volume Manager, Manual Pages. VERITAS Volume Manager, User Documentation. VERITAS Enterprise Administrator Service. VERITAS Volume Manager Management Services Provider. VERITAS File System Management Services Provider. VERITAS Enterprise Administrator.

2.3

Architekturübergreifender Storage durch CDS-Disklayout Die Version 4.0 von VxVM führte ein neues, architekturübergreifendes Disk-Format ein, von dem zu Beginn bereits die Rede war. Dieses Format heißt „cdsdisk“ (für CrossPlatform Data Sharing). Wird eine Disk mit vxdisksetup -i format=cdsdisk (Default bei VxVM 4.0) initialisiert, so kann sie anschließend auf Solaris/SPARC, Linux (mit Solaris-kompatiblen Labels), AIX und HP/ UX verwendet werden. Das Diskformat ist relativ komplex: Zunächst wird auf Sektor 0 ein sogenannter Platform Block geschrieben. Dieser ist kompatibel mit allen unterstützten Plattformen, enthält jedoch nur für das Solaris-Format die VTOC, da dort die VTOCLokation fest an dieser Adresse erwartet wird. Diese Solaris-VTOC markiert die Disk als komplett belegt durch eine einzige, grosse Private Region auf Slice 7. Linux kann diese VTOC ebenfalls verwerten. Für die anderen unterstützten Betriebssysteme - HP-UX und AIX - werden an anderen Stellen

2.3.1

systemspezifische sogenannte Coexistence Labels geschrieben (z.B. AIX in Sektor 7), in welchen ebenfalls die gesamte Disk als belegt markiert wird. Im Platform Block stehen Zeiger auf die Coexistence Labels und in jenen wiederum ein Zeiger auf eine weitere Datenstruktur, den VxVM ID Block (Sektor 16). Das HP/UX Coexistence Label hat denselben Inhalt wie der VxVM ID Block, liegt jedoch an anderer Stelle. Zu VxVM ab Version 4.0 gehört ein Programm namens vxcdsconvert, mit dem ganze DiskGroups vom alten sliced-Format in das neue cdsdisk-Format überführt werden können. Dies kann sogar komplett online geschehen, wobei allerdings etliche Einschränkungen zu berücksichtigen sind. So müssen sämtliche Volumes komplett intakt sein, die Disks müssen für die zusätzliche Information des cds-Formats noch etwas Platz frei haben und so weiter.

13

2 2.4

DISK-MANAGEMENT UNTER SOLARIS/VXVM Befehlssammlung Kapitel 2 Befehle zur Installation installer (installsf) ..... vxdisk list ................................ vxdisksetup -i Disk ........ vxdiskunsetup Disk ...........

2.4.1

Erlaubt die Installation der Pakete und Lizenzen. Zeigt Disk- und DiskGroup-Informationen an. Bereitet die Disk für Volume Manager vor. Bereitet die Disk wieder für Solaris vor (kein VxVM mehr).

Nicht vergessen: Die Befehle vxdisksetup und vxdiskunsetup sind mit Vorsicht zu bedienen, da sie die Partition Table (VTOC) der angegebenen Disk verändern und somit u.U. Daten nicht mehr zugreifbar sind. Das Kommando vxdisksetup löscht alle Einträge aus der VTOC mit Ausnahme von Slice 2 („backup“; die gesamte Disk). Anschliessend trägt es Partition-Informationen für die VxVMeigenen Metadaten ein. Dies geschah bis VxVM 3.5 durch separate Partition-Einträge für Slice 3 und 4, die „Private Region“ und die „Public Region“. Der Platz innerhalb der „Public Region“ wird für Userdaten benutzt; in der „Private Region“ liegen die VxVM-Metadaten. Seit Version 4 wird die gesamte Disk über Slice 7 als „Private Region“ belegt und damit für Betriebssystem und Applikationen als belegt markiert. Die „Public Region“ existiert immer noch, allerdings lediglich innerhalb der Private Region. Es gibt keine Partition mehr für die Public Region. Disks im neuen Defaultformat sind zwischen

2.4

allen UNIX-VxVM-Plattformen austauschbar. Das Format wird als cdsdisk bezeichet, was für Cross-Platform Data Sharing steht. Das alte Format heisst sliced, weil dort Private und Public Region in eigenen Slices liegen. Wird das Flag -i angegeben, so wird die Private Region ausserdem initialisiert. Die Disk ist dann für VxVM vorbereitet und kann einer Diskgroup zugeordnet werden. Das Kommando vxdiskunsetup entfernt die VTOC-Einträge für die Public und die Private Region, stellt aber die alte VTOC nicht wieder her. Die Disk kann jetzt nicht mehr von VxVM verwaltet werden, da die Lokation der Private Region nicht mehr ermittelt werden kann. Ein erneutes Aufrufen von vxdisksetup, allerdings ohne -i, würde die Disk wieder in einen für VxVM brauchbaren Zustand zurückbringen, da durch vxdiskunsetup keinerlei Daten geändert werden (weder in der Public noch in der Private Region), sondern lediglich die Zeiger auf diese Regions aus der VTOC gelöscht werden.

Hinweis Sie erhalten mehr Informationen über den Inhalt und Status der Private Region, wenn Sie das Kommando vxdisk list Disk eingeben.

14

DISK-MANAGEMENT UNTER SOLARIS/VXVM

2

Übungen: Installation von VxVM

Ü2

Installation von VxVM

Ü 2.1

Starten Sie das Programm installer vom Distributionsmedium als User root. Zuerst wird automatisch das notwendige LizenzPackage installiert. Der dann folgende Überblicksbildschirm zeigt die installierbare Software (Achtung: nicht alles auf der CD!) und ihren Installationsund Lizenz-Status an. Wählen Sie hier das Installations-Menu (Punkt 2; die Lizenz wird später eingespielt).

Starten Sie die Installation der Storage Foundation. Die Installationsroutine installiert auch Patches, wenn sie sich auf der CD befinden. Wenn das Einspielen der Patches es erfordert, rebooten Sie den Rechner. Das Protokoll der Installation finden Sie in drei Logfiles, deren Pfadnamen am Ende der Installation ausgegeben werden.

Ü 2.2

Verifizieren der Installation Kontrollieren Sie anschließend das Ergebnis. vxdisk list Alle Disks, die dem System bekannt sind, werden mit dem Controllerpfad oder, bei SANStorage, einem aus dem Disk-Array abgeleiteten sog. „Enclosure Based Name“, Typ auto und Zustand online angezeigt. Die Angabe online repräsentiert dabei den Zustand, den die Disk für das Betriebssystem hat, d.h. sie ist

für das Betriebssystem sichtbar und nicht fehlerhaft. Die Angabe neben online gibt den VxVM-seitigen Zustand wieder, etwa invalid, wenn sich noch keine gültige Private Region auf der Disk befindet, Neue Befehle: vxdisk list vxprint vxdisk list Disk

Environment-Variablen: Folgende Variablen sollten Sie in Ihrem Profile setzen: PATH-Variable: $PATH:/sbin:/usr/lib/vxvm/bin .................................................... MANPATH-Variable: $MANPATH:/opt/VRTS/man .........................................................................

Übernahme der Disks unter VxVM-Kontrolle Initialisieren Sie alle freien Disks für VxVM mit tup, vxdisk list und vxdisk list dem Befehl vxdisksetup -i c#t#d#. Bedenken Sie, dass dieser Befehl bestehende Partitionen überschreiben kann! Schauen Sie mit format und vxdisk list nach, welche Disks zur Verfügung stehen, und vergewissern Sie sich, welche Disks wirklich frei sind und keine Daten enthalten. Üben Sie die Befehle vxdisksetup, vxdiskunse-

Ü 2.3

, bis Sie sie flüssig beherrschen. Disks können mit dem Befehl vxdiskunsetup der VxVM-Kontrolle wieder entzogen werden. Neue Befehle: vxdisksetup -i vxdiskunsetup

Hinweis Sollten Sie die Befehle nicht finden, so stellen Sie sicher, dass die PATH-Variable die genannten Pfade enthält.

15

2

DISK-MANAGEMENT UNTER SOLARIS/VXVM Musterlösung Verständnisfrage 2.1 Warum lässt VxVM den Rest der Disk (außerhalb der Private Region) nicht einfach frei? Wirklich brauchen tut er doch nur die Metadaten, oder? Antwort: Mit Übergabe der Kontrolle über die Disk an VxVM ist die Disk nicht mehr frei für das Betriebssystem. Sie steht unter VxVM-Kontrolle. Diesen Zustand muß die VTOC auch widerspiegeln. Würde die Public Region nicht in der VTOC eingetragen, sähe die Disk bis auf die kleine Private Region leer aus, und ein Administrator könnte versucht sein, innerhalb des freien Bereichs Partitionen zu definieren und dort Daten hinzuschreiben. Diese würden sich dann völlig unkoordiniert mit Daten aus Volumes von VxVM vermischen, was zu allerlei wenig erheiternden Resultaten führen könnte.

Verständnisfrage 2.2 Warum werden die Verwaltungsinformationen in eine Partition bzw., im Falle von CDSDisks, in einen festen Diskbereich, geschrieben und nicht in eine Datei? Antwort Die Datei könnte auf jeden Fall nicht auf einem Volume innerhalb der DiskGroup liegen, denn um auf die Datei zuzugreifen, müssten zuerst die Beschreibung der DiskGroup und die VolumeLayouts bekannt sein. Diese Informationen stehen aber in der Datei, so dass ein Henne/Ei-Problem aufträte. Wird die Datei mit den Verwaltungsinformationen hingegen außerhalb der DiskGroup abgelegt, so würde die Information über die DiskGroup nicht mit derselben mit von Host zu Host wandern, was ebenfalls inakzeptabel ist. Es führt daher kein Weg daran vorbei, die Informationen außerhalb des Filesystems in einem festen Bereich zu speichern.

Verständnisfrage 2.3 Muss sich ein logisches Volume dem Betriebssystem gegenüber genau so verhalten wie eine physische Disk oder wie etwas anderes? Warum? Antwort Es muss sich so verhalten wie eine Partition. Würde es sich verhalten wie eine Disk, so wäre ein Volume wiederum formatierbar und hätte eine VTOC, ließe sich für VxVM sozusagen rekursiv verwenden (das geht auch, kommt aber viel später). Damit die Treiber des Filesystems, die RawDevice-Treiber einer Datenbank etc. nicht auf Volumes angepasst werden müssen, muss sich ein Volume sogar hundertprozentig genau so verhalten wie eine Partition, da es ansonsten schlicht zu unerwarteten Zuständen, mithin Fehlerzuständen, im Treiber kommt. Diese würden unausweichlich in einer Betriebssystem-Panic enden, was im HA-Bereich nur selten gewünscht ist. Das wichtigste Kriterium für die logische Kompatibilität mit Partitions ist, abgesehen vom blockweisen Lesen und Schreiben des Adressbereichs, die Konsistenz der Daten. Liest man von einer Partition mehrmals den gleichen Block herunter, ohne ihn zwischendurch zu schreiben, so werden garantiert immer dieselben Daten zurückgegeben. Dies ist bei einem logischen Volume, das ja mehrere Repräsentationen der Daten (Spiegelseiten) besitzen kann, nicht immer gegeben. Besonders nach einem Crash während des Schreibens muss mit unterschiedlichen Spiegelinhalten gerechnet werden. VxVM stellt mit Hilfe einer sehr cleveren und daher zunächst schwer zu verstehenden Methode sicher, dass die Konsistenz dennoch gewährleistet ist, und das ganz ohne Brute Force (Komplettsynchronisation vor Inbetriebnahme des Volumes o.ä.). Dazu später viel mehr …

16

KAPITEL 3

DISKGROUPS

3 3.1

DISKGROUPS Zweck von DiskGroups DiskGroups l

prod

test

devel

test devel devel

Einzelne Disks im RAIDUmfeld sinnlos. l Bündelung zur gemeinsamen Behandlung. l Zugriffssteuerung. l Verhinderungunkoordinierter gleichzeitiger Zugriffe. l Unterstützung von HA (High Availability, Hochverfügbarkeit).

devel devel test prod prod prod

test

prod prod prod 3.1

3.1.1

DiskGroups Da einzelne Disks im Umfeld von Volume Management sinnlos sind (es geht ja gerade um die Sprengung der physischen Grenzen einzelner Disks), ist die elementare Einheit, auf der VxVM arbeitet, eine Gruppe mehrerer Disks, die sogenannte DiskGroup. Das entspricht einer logischen Aufteilung oder Partitionierung des verfügbaren Speichers in separate Einheiten. Wir wissen aber von der Arbeit mit Filesystemen, dass Partitionierung immer Verschnitt mitbringt und eine vollständige Ausnutzung der vorhandenen Resourcen erschwert. Wird in einem Container (egal ob das nun eine DiskGroup oder ein Filesystem ist) Platz benötigt, während in einem anderen noch genügend frei ist, so hat man auf der einen Seite unnötige Enge, während auf der anderen Seite Platz verschwendet wurde. Warum also soll man den Speicher partitionieren? Der Grund liegt in der Unterstützung von HighAvailability: Eine DiskGroup wird als eine Einheit, sozusagen atomar, für einen Host reserviert (wie das genau geht, kommt später). Somit kann dann genau dieser Host auf die

18

darin enthaltenen Volumes zugreifen. Heutige Clustersoftware (hier greifen wir dem zweiten Teil des Buches voraus) wird üblicherweise in einer Active-Active-Konfiguration betrieben, d.h. mehrere Clusterknoten arbeiten gleichzeitig und stellen unterschiedliche Teil-Dienste einer Gesamtlösung zur Verfügung. Die einzelnen, über die Clusterknoten verteilten Dienste werden bei einem Ausfall durch die Clustersoftware kontrolliert auf einen anderen Knoten hinübergeschwenkt. Der Zusammenhang mit den DiskGroups ergibt sich dadurch, dass alle logischen Volumes, die für einen solchen schwenkbaren Dienst (man nennt diese Dienste ServiceGroups) benötigt werden, in einer einzigen DiskGroup zusammengefaßt werden. Auf diese Weise schwenkt zunächst der Storage (die DiskGroup mit den darin enthaltenen Volumes) zu einem anderen Server, anschließend kann dieser Server auf die darin gespeicherten Volumes (für Programm, Konfiguration und Benutzerdaten) zugreifen und so den Dienst starten.

DISKGROUPS

3

Implementation von DiskGroups

3.1.2

Disks werden einzeln oder gemeinsam in DiskGroups eingebracht. Dabei werden in der Private Region jeder beteiligten Disk der DGName sowie die DG-ID (interner Name) vermerkt. Nach dem Anlegen einer neuen DiskGroup ist diese auf dem agierenden Host „im-

portiert“, d.h. die DiskGroup mit allen darauf befindlichen Objekten ist nur für diesen Host zugreifbar. Ein Importversuch durch einen anderen Host wird vom dortigen VxVM abgelehnt.

Importieren und Deportieren von DiskGroups Soll der Zugriff auf eine DiskGroup einem anderen Host übertragen werden, so muss die DG zunächst deportiert und anschliessend vom neuen Host importiert werden. Beim Importieren wird der Name des Hosts auf jede Disk der DiskGroup in die Private Region geschrieben, beim Deportieren wird der Name wieder gelöscht. Befindet sich beim Importieren bereits ein fremder Namenseintrag auf den Disks, so schlägt der Import fehl. Nach dem Import einer DiskGroup kann auf die darin enthaltenen Volumes zugegriffen werden. Wo liegt der dazugehörige DeviceTreiber? In /dev gibt es ein Unterverzeichnis

3.1.3

vx (für Veritas), innerhalb dessen sich alle Veritas-bezogenen Treiber sammeln. Dort gibt es, analog zu /dev/dsk und /dev/rdsk, ebenfalls dsk und rdsk-Verzeichnisse. In diesen liegt für jede importierte DiskGroup ein eigenes Verzeichnis, das den Namen der DiskGroup trägt, und innerhalb dieses Verzeichnisses befindet sich je ein DeviceTreiber für jedes Volume der DiskGroup. Durch das Importieren einer DiskGroup wird das entsprechende Verzeichnis in /dev/ vx/dsk bzw /dev/vx/rdsk erzeugt und durch das Deportieren wieder gelöscht.

Daraus folgt: l l

Alle Objekte eines Volumes müssen sich innerhalb derselben DiskGroup befinden. Es sind keine DiskGroup-übergreifenden Aktionen auf Volumes möglich, kein Spiegeln, Erweitern etc.

Was passiert dabei noch? Beim Importieren stellt VxVM fest, welche Objekte sich auf der DG befinden, und baut die für den Zugriff nötigen Strukturen im Betriebssystem auf (I/O-Mapping, DeviceTreiber etc.). Für die Volumes befinden sich anschließend Einträge für die Device-Treiber in

/dev/vx/dsk/DG/VolName bzw. /dev/vx/rdsk/DG/VolName. Diese Volumes sind aber noch gestoppt und müssen vor dem Zugriff gestartet werden. Erst durch das Starten wird I/O auf das Volume ermöglicht.

Verständnisfrage 3.1 Alle Informationen über eine DiskGroup sind innerhalb der DiskGroup selbst gespeichert – warum? Was bedeutet dies für das Importieren von DiskGroups, wenn viele Disks vorhanden sind?

Verständnisfrage 3.2 Wenn die Zugriffssteuerung auf Goodwill beruht, ist sie dann ausreichend? Denken Sie auch an den HA-Aspekt (Cluster)! Wie werden unter Solaris sonst Diskzugriffe hostübergreifend geregelt?

19

3

DISKGROUPS Achtung Die Zugriffssteuerung mittels DiskGroups beruht auf einer VxVM-internen Vereinbarung. Es ist möglich, unter Umgehung von VxVM auf Disks zuzugreifen, auch wenn diese nicht auf dem Host importiert sind. Dabei können wichtige Informationen verlorengehen.

3.2

Befehlssammlung Kapitel 3 – 1. Teil Befehle für Disks und DiskGroups vxdg init DG [Disk=]AccessName .................... Erzeugt eine neue DiskGroup. vxdg deport DG .......................................................... Gibt die DiskGroup für andere Rechner frei. vxdg import DG .......................................................... Reserviert die DiskGroup. vxdg list ...................................................................... Zeigt alle importierten DiskGroups an. vxdg -g DG adddisk [Disk=]AccessName ...... Fügt Disks zu einer DiskGroup hinzu. vxdg -g DG rmdisk Disk|AccessName ............. Entnimmt Disks einer DiskGroup. vxdg list DG ............................................................... Zeigt nähere Informationen über die DG. vxdg destroy DG ........................................................ Zerstört eine DiskGroup. vxdisk -o alldgs list ......................................... Zeigt DG-Informationen auch von nicht importierten Disks. vxdctl defaultdg DG .............................................. Legt DiskGroup als Default fest (ab 4.0). vxdctl bootdg ......................................................... Legt DiskGroup als Boot-DG fest (ab 4.0). vxdg defaultdg ....................................................... Zeigt die Default-DiskGroup (ab 4.0). vxdg bootdg .............................................................. Zeigt die Boot-DG an (ab 4.0).

3.3

3.2

Befehlssammlung Kapitel 3 – 2. Teil Fortgeschrittene Befehle für DiskGroups Weitere Flags zum gezielten De- und Importieren: vxdg -t ............. Importiere temporär – kein automatisches Importieren beim Booten (z.B. nach Crash). vxdg -n ............. Importiere / deportiere unter Umbenennung der DiskGroup – das DiskGroupName-Feld wird überschrieben. vxdg -h ............. Deportiere gezielt an einen anderen Host – das HostID-Feld wird gesetzt und die DiskGroup deportiert. vxdg -f ............. Importiere forciert, d.h. auch wenn die DiskGroup unvollständig ist. vxdg -C ............. Importiere mit Clear HostID Feld.

3.3

Hinweise für große Umgebungen Normalerweise können aufgrund der Größe der Private Region circa 3000 Objekte pro DiskGroup verwaltet werden. Als Objekt zählen hierbei Volumes, Plexes, Subdisks, Logs etc. Diese Grenze kann durch eine größere Private Region erweitert werden. Dies ist jedoch nur möglich zum Zeitpunkt der Initialisierung der Disk. Dazu benutzt man die Option privlen: vxdisksetup -i c#t#d# privlen=XXXX Der Import von VxVM-Disks kann ca. 1 Sekunde pro Disk dauern. Bei z.B. 4000 Disks bzw. LUNs dauert der Import also über eine Stunde (Cluster-Switch, Boot etc.)! Wenn Sie viele Disks haben, sollten Sie vielleicht erwägen, schon im Disk-Array größere Einheiten zu bilden.

20

DISKGROUPS

3

Übungen: DiskGroups

Ü3

Anlegen, Deportieren, Importieren

Ü 3.1

Legen Sie auf einer freien VM-Disk eine DiskGroup an. Deportieren Sie sie und importieren Sie die DG wieder. Stellen Sie dabei mittels vxdisk list c#t#d# den Inhalt des HostID-Feldes fest. Finden Sie noch weitere Unterschiede?

Neue Befehle: vxdg init vxdg deport vxdg import vxdg list [DG ] vxdisk list [Disk]

Ü 3.2

Vergrößern, Verkleinern, Löschen Fügen Sie zu der DiskGroup weitere Disks hinzu. Wenn mehr als fünf Disks* in der DG sind: 1. Was fällt bei vxdg list DG auf? 2. Entfernen Sie eine der ersten fünf Disks aus der DG. Was fällt nun auf? 3. Löschen Sie die DG wieder und schauen Sie sich eine Disk mit vxdisk list c#t#d# an. Welches Feld hat sich noch geändert?

Neue Befehle: vxdg adddisk vxdg rmdisk vxdg destroy

* Sollten Sie nicht genügend Disks zur Verfügung haben, schlagen Sie in der Musterlösung nach.

Umbenennen, gezielter Deport, forcierter Import, unbedingter Import Legen Sie erneut eine DG an. Nennen Sie die DG beim Deportieren um und importieren Sie sie wieder. Nun deportieren Sie die DG zu einem fremden Host und versuchen Sie, sie wieder zu importieren. Versuchen Sie folgende Möglichkeiten, um die DG trotzdem zu importieren: 1. Das Umbenennen Ihres Hosts (mit uname -S) 2. einen forcierten Import (mit -f) 3. einen Clear-Import (mit -C)

Ü 3.3

Neue Befehle: vxdisk -o alldgs list Neue Flags: vxdg -n -h -f -C

Achtung Sie können mit der Option -C auch DiskGroups importieren, die auf einem anderen Host importiert und aktiv sind. Dann haben beide Hosts gegenseitig unkontrollierten Lese- und Schreibzugriff auf diese DiskGroups! Die Konsistenz ihres Datenbestandes ist dabei hochgradig gefährdet! Eine Lösung bietet z.B. die Verwendung von VERITAS Cluster Volume Manager und VERITAS Cluster File System.

Ü 3.4

Fortgeschrittene Übung (optional) Legen Sie erneut eine DG an. Nennen Sie die DG beim Deportieren um und erzeugen Sie eine zweite DG mit dem gleichen Namen, so dass es zwei DGs mit dem gleichen Namen gibt, eine importierte und eine deportierte.

Fragen: 1. Warum lässt VxVM dies zu? 2. Wie kann man die zweite DG importieren? 3. Wozu ist dieses Wissen nützlich?

21

3 Ü3

DISKGROUPS Musterlösung

Log Ü 3.1

vxdg init adg adg01=c1t2d0 vxdisk list c1t2d0 | tee before vxdg deport adg vxdisk list c1t2d0 | tee after diff before after Vorher: disk: name=adg01 ... flags: online ready private autoconfig autoimport imported Nachher: disk: name= ... flags: online ready private autoconfig

Log Ü 3.2

1. Eine der Disks erscheint nicht als Config-Disk. vxdg import adg vxdg -g adg adddisk adg02=c1t3d0 adg03=c1t4d0 … adg06=c1t9d0 vxdg list adg Group: adg … config disk c1t2d0s2 copy 1 len=2034 state=clean online … config disk c1t8d0s2 copy 1 len=2034 state=clean online config disk c1t9d0s2 copy 1 len=2034 disabled log disk c1t2d0s2 copy 1 len=308 … log disk c1t8d0s2 copy 1 len=308 log disk c1t9d0s2 copy 1 len=308 disabled 2. Nach Entnahme einer Config-Disk wird automatisch eine andere Disk zur Config-Disk. Die Konfigurations- und die Logdatenbank ist fünffach (default) vorhanden. Wird eine Disk entfernt, auf der Config und Log liegen, so wird seine Config- und Log-Eigenschaft an eine andere Disk übergeben. vxdg rmdisk adg01 vxdg list adg Group: adg … config disk c1t3d0s2 copy 1 len=2034 state=clean online … config disk c1t9d0s2 copy 1 len=2034 state=clean online log disk c1t3d0s2 copy 1 len=308 … log disk c1t9d0s2 copy 1 len=308 3. Nach Zerstörung der DiskGroup bleiben die meisten Informationen über die DiskGroup erhalten; nur DG- Name, hostid-Feld und einige Flags werden gelöscht. vxdisk list c1t2d0 | tee before vxdg destroy adg vxdisk list c1t2d0 | tee after diff before after

22

DISKGROUPS

3

Musterlösung (Fortsetzung)

Ü3

Vorher: hostid: disk: group: flags: update: Nachher: hostid: disk: group: flags: update:

e250 name=adg01 id=1063108317.1118.e250 name=adg id=1035629386.2115.e250 online ready private autoconfig autoimport imported time=1035629386 seqno=0.57

name= id=1063108317.1118.e250 name= id=1035629386.2115.e250 online ready private autoconfig time=1035629414 seqno=0.59

vxdg init adg adg01=c1t2d0 vxdg -n bdg deport adg vxdg -o alldgs list vxdg import bdg vxdg -h newhost deport bdg vxdg import bdg # Fehler, weil die DG nicht unserem Host gehört uname -S newhost # Versuch, durch Umbenennung des Hosts den Import zu erzwingen vxdg import bdg # Fehler, weil der aktuelle Hostname keine Rolle spielt (vxdctl list) vxdg -f import bdg # Fehler, weil das Problem nicht eine unvollständige DG ist vxdg -C import bdg # Import funktioniert, da das Hostid-Feld vor dem Import gelöscht wurde uname -S oldhost # Änderung des Hostnamens wieder rückgängig machen vxdg destroy bdg

Log Ü 3.3

1. VxVM weiss nach dem Deport nichts mehr über die DG, da alle Informationen über eine DG in dieser selbst gespeichert sind. Daher kann VxVM nicht verhindern, dass DG-Namen mehrfach benutzt werden. vxdg init adg adg01=c1t2d0 vxdg deport adg vxdg init adg adg02=c1t3d0

Log Ü 3.4

2. Durch Angabe der DG-ID anstelle des DG-Namens kann man zwei DiskGroups gleichen Namens importieren. Die DG-ID erhält man durch den Befehl vxdisk list c#t#d# auf eine Disk der zu importierenden DiskGroup. Zusätzlich muss die zweite DiskGroup beim Importieren umbenannt werden, um einen Namenskonflikt zu vermeiden. vxdg import adg # Fehler, da eine DiskGroup „adg“ bereits importiert ist vxdisk list c1t2d0 [...] hostid: disk: name= id=1063108317.1118.e250 group: name=adg id=1035629793.2121.e250 # DiskGroup-ID flags: online ready private autoconfig [...] vxdg import 1035629793.2121.e250

23

3 Ü3

DISKGROUPS Musterlösung (Fortsetzung) und Antworten zu Verständnisfragen # Schlägt noch fehl, weil gleicher DG-Name wie importierte DG vxdg -n bdg import 1035629793.2121.e250 # DG über ID importieren und gleichzeitig umbenennen 2. Diese Prozedur wird bis VxVM3.5 benutzt, um eine fremde rootdg zwecks Reparatur vorübergehend zu importieren (bis 3.5 war eine rootdg zwingend vorgeschrieben).

Verständnisfrage 3.1 Alle Informationen über eine DiskGroup sind innerhalb der DiskGroup selbst gespeichert – warum? Damit eine DiskGroup als abgeschlossenes, vollständiges Objekt von Host zu Host migrieren kann, ohne dass weitere Kommunikation zwischen den Hosts stattfinden muss (z.B. NetzwerkFiletransfer mit den Metadaten der DiskGroup). Was bedeutet dies für das Importieren von DiskGroups, wenn viele Disks vorhanden sind? Um die einer DiskGroup zugehörigen Disks zu finden, muss schlimmstenfalls physischer I/O auf allen Disks durchgeführt werden, die mit dem System verbunden sind. Das kann bei großen SAN-Umgebungen lange dauern. Aus diesem Grunde werden einige DiskGroup-Informationen in /var/vxvm/tempdb zwischengespeichert.

Verständnisfrage 3.2 Wenn die Zugriffssteuerung auf Goodwill beruht, ist sie dann ausreichend? Denken Sie auch an den HA-Aspekt (Cluster)! Sie ist nicht nur ausreichend, sie darf gar nicht strenger sein als Goodwill, da im HA-Umfeld die zwangsweise Übernahme von DiskGroups vorgesehen sein muss. Sonst könnte ein Cluster-Node niemals DiskGroups von einem ausgefallenen Node übernehmen, da man nicht erwarten kann, dass der ausfallende Node vor seinem Ausfall noch die DiskGroups freigibt. Wie werden unter Solaris sonst Diskzugriffe hostübergreifend geregelt? Sie werden unter Solaris normalerweise überhaupt nicht geregelt. Es gibt prinzipiell die Möglichkeit, mittels des Kommandos luxadm reserve SCSI-Targets zu reservieren, jedoch wird dies üblicherweise nicht verwendet.

24

KAPITEL 4 VOLUMES

4 4.1

VOLUMES Eigenschaften eines VxVM-Volumes Volume l

Stellt sich dem Betriebssystem wie eine DiskPartition dar. l Wird angesprochen über eine VX-Treiberdatei. l Besteht aus einem oder mehreren „Plexes“. l Plexes bestehen aus einer oder mehreren „Subdisks“. l Wird mit vxassist make angelegt. l Wird mit vxprint angezeigt.

4.1

4.1.1

Grundlagen von Volumes Wie eingangs erwähnt erzeugt Volume Management virtuelle Objekte, die auf die eine oder andere Weise mit Disk-Hardware kompatibel sind. SAN-Systeme (auch RAIDArrays genannt) stellen virtuelle Disks, sogenannte LUNs, im SAN zur Verfügung, die exakt kompatibel mit ganzen Disks sind, tragen also VTOC bzw. Partition-Table und können mehrere Partitions enthalten. Wir werden daher im Rahmen dieses Kurses normalerweise keine Unterscheidung zwischen LUNs (virtuellen Disks aus einem SAN-Storage) und Disks (physischen Spindeln) machen. Die virtuellen Objekte, die Volume Manager dem Betriebssystem bereitstellt, sind im Gegensatz zu LUNs kompatibel mit Partitions. VxVM-Volumes können also nicht weiter partitioniert werden und enthalten auch keine VTOC. Man kann auf sie nicht mit dem Programm format, fmthard oder prtvtoc zugreifen, und sie besitzen auch keine Treiber in /dev/dsk und /dev/rdsk. Anstelle dessen würde man ein Volume, aufgrund seiner Kompatibilität zur Partition, mittels mkfs bzw. newfs mit einem Filesystem initialisieren und mounten. Alternativ könnte man ein Volume auch als Raw-Device zur Speicherung von Table-Spaces einer Datenbank benutzen. Natürlich brauchen mkfs, mount und auch die Datenbank einen Gerätetreiber, um auf das Volume zuzugreifen. Dieser Gerätetreiber

26

findet sich in einem durch die Installation von VxVM angelegten Verzeichnis innerhalb der / dev-Hierarchie, nämlich /dev/vx/dsk bzw. /dev/vx/rdsk. Näheres zu den DeviceTreiber-Namen folgt im Verlauf des Kurses. Da für das Anlegen eines Volumes unter VxVM oft viele Objekte erzeugt und miteinander verknüpft werden müssen (Volume, Plexes, Subdisks in jedem Plex), wird die Erstellung und Verwaltung von Volumes einem Front-End überlassen. Dieses Front-End heisst vxassist und ist für uns die zentrale Schnittstelle zu VxVM. Das vxassist Kommando übernimmt die intelligente Allokation von Speicher und deren Verknüpfung zu Volumes. Man kann über sogenannte Storage-Attribute die Allokation innerhalb von vxassist auch gezielt steuern. Auf Storage Attribute wird später genauer eingegangen. Einmal angelegte Volumes kann man mit dem Befehl vxprint anschauen und ebenfalls mit vxassist oder mit dem Low-Level-Befehl vxedit wieder löschen. Anlegen: vxassist -g DG make testvol 100m Überprüfen: vxprint -g DG vxprint -g DG -tr Löschen: vxassist remove volume testvol vxedit -rf rm testvol

VOLUMES

4

RAID-Konzept

4.1

Das Kommando vxassist kennt viele Optionen zur Steuerung der Volume-Eigenschaften, um die Beschränkungen (Größe, Redundanz, Geschwindigkeit) zu umgehen. Diese orientieren sich an den sog. RAID-Leveln.

RAID Redundant Array of Inexpensive Disks l Entwickelt Ende der 80er Jahre an der University of California in Berkeley. l Ziel: Die teuren Disks aus Host-Architekturen durch billige Standard-Disks zu ersetzen. l Methode: Logische Verknüpfung mehrerer Disks auf unterschiedliche Weisen.

4.1.2

Entwicklung Ende der achtziger Jahre entstand in der University of California Berkeley (UCB) die Grundlage für die meisten heute verbreiteten Volume Management Produkte. Die Idee war, die relativ schnellen, relativ sicheren und relativ großen, aber sündhaft teuren High-EndPlatten der Hostsysteme schlicht durch eine große Menge an preisgünstigen Standardplatten zu ersetzen. (Damals fand sich in Berkeley an einer Tafel im 4. Stock des InformatikGebäudes folgende Überschrift: „RAID Redundant Array of Inexpensive Disks“. Erst Jahre später tauchte der Begriff RAID auch im deutschen Zeitschriftenwald auf, allerdings unter dem marketingtechnisch geprägten Begriff „Redundant Array of Independent Disks“. Dies rührt sicher daher, dass sich Disksysteme nicht teuer verkaufen lassen, wenn sie das Label „inexpensive“ im Namen tragen. Wer also Wert auf Korrektheit legt, vermeidet bei RAID den Begriff „independent“.) In mehreren Schüben entstanden Treiber, die zunächst die Größenbeschränkung aufhoben, dann die Performance und endlich auch die Sicherheit erhöhten und schließlich, in mehreren verzweifelten, aber hoffnungslosen Anläufen versuchten, alle drei Dinge auf einmal zu tun. Diese Entwicklung spiegelt sich in den RAID-Leveln 0c (Concat), 0s (Stripe), 1 (Mirror)

und 2,3,4,5 (Parity-Stripe) wieder. Aufgrund der hohen Kosten für Disks zur damaligen Zeit glaubte man, die Sicherheit durch eine Art Checksummenverfahren implementieren zu müssen, denn eine Doppelung der Disks war für die meisten Anwendungen schlicht zu teuer. Andererseits waren checksummengesicherte Stripes (RAID-2 bis RAID-5) aus verschiedenen Gründen immer nur schlechte Kompromisse. Erst seit Ende der neunziger Jahre benutzt man kombinierte RAID-Level; man verbindet Concatenation oder Striping mit Mirroring zu einem schnellen, großen und sicheren Volume mit aufgrund der gefallenen Preise noch akzeptablen Kosten. Achtung: Zu der Zeit, als RAID entwickelt wurde, waren die üblichen Disks ca. 20-40MB groß, übertrugen ca. 500KB bis 1MB pro Sekunde und rotierten mit 3600/min. Diese heute vollkommen antiquierten physischen Parameter definieren bis heute die Denkweise der meisten Leute, die RAID-Systeme konfigurieren. Wir werden später die heutige Situation darstellen und entsprechende Schlüsse daraus für die performante Konfiguration aktueller Disksysteme ziehen. Sie werden staunen, wie schlecht Stripes dabei abschneiden!

Hinweis Da seit VxVM 4.0 die rootdg optional ist kann die Ziel-DiskGroup nicht mehr ermittelt werden, wenn diese nicht angegeben wurde. Ist keine DefaultDG gesetzt, so müssen Sie daher stets die Option -g DG angeben, um festzulegen, auf welche DiskGroup sich ein Kommando bezieht. Sie können die DefaultDG entweder systemglobal setzen (mit dem Befehl vxdctl defaultdg DG, abfragen mit vxdg defaultdg) oder prozesslokal durch Setzen der Environment-Variable VXVM_DEFAULTDG. In den folgenden Kommandozeilen wird eine DefaultDG vorausgesetzt!

27

4 4.2

VOLUMES Übersicht RAID-Level RAID-0 · Concat

Disk

Disk

Disk

RAID-0 / Concat:

Disk

RAID-0 / Stripe:

RAID-0 · Stripe 0 4 8

1 5

2 6

3 7

Disk

Disk

Disk

Disk

RAID-1 · Mirror

Disk

Disk

Disk

Mehrere, auch unterschiedlich große Disks werden logisch hintereinander gehängt. Das resultierende Volume beginnt am Anfang der ersten Disk und endet am Ende der letzten. Erst bei Überschreiten der Kapazität der ersten Disk wird die zweite benutzt. Mehrere gleich große Disks werden logisch kammförmig ineinander geschoben. Das resultierende Volume beginnt parallel an den Anfängen aller Disks (Columns), jeweils verschoben um die Breite einer Stripe-Unit (Stripe Unit Width). Sequentielle Zugriffe werden auf mehrere Disks verteilt.

RAID-1 (Mirror):

Disk

Zwei oder mehr Disks werden aufeinander abgebildet (gespiegelt). Schreibzugriffe gehen auf alle Disks, Lesezugriffe werden algorithmisch verteilt (z.B. reihum oder per Zufall).

RAID-4 (Parity): RAID-4 · Parity 0 3 6

1 4

2 5

P(0...2) P(3...5)

Disk

Disk

Disk

Disk

RAID-5 · Distributed Parity

Auf Basis eines RAID-0/Stripe wird zu jedem vollen Stripe (Stripe Unit Width x Anzahl Columns) die Parity per XOR berechnet und auf einer weiteren Disk gespeichert. Durch die Parity-Information kann der Ausfall einer beliebigen Disk kompensiert werden. RAID-4 wird von VxVM nicht unterstützt; RAID-2 und RAID-3 haben nie kommerzielle Bedeutung erlangt.

RAID-5 (Distributed Parity):

0 3 6

1 4 P(6...8)

2 P(3...5)

P(0...2) 5

Disk

Disk

Disk

Disk

Prinzipiell identisch mit RAID-4, jedoch wird die Parity-Information gleichmäßig über alle Disks verteilt, um ein Bottleneck bei parallelen Schreibzugriffen vermeiden.

4.2

28

VOLUMES

4

Parity-Berechnung mittels XOR bei RAID-4 und RAID-5

4.3

AND 1 0 1 1

0 1 1 0

1 1 0 0

OR 0 0 1 0

1 0 1 1

0 1 1 0

Logische Operationen

1 1 0 0

0 0 1 0

0 0 0 0

1 1 1 1

XOR

XOR-Recovery

1 0 1 1

0 1 1 0

1 1 0 0

0 0 1 0

1 0 0 1

1 0 1 1

0 1 1 0

1 1 0 0

0 0 1 0

1 0 0 1 1 1 0 1

AND: Ergebnis NULL, wenn ein Eingabewert NULL OR: Ergebnis EINS, wenn ein Eingabewert EINS XOR: Ergebnis EINS bei ungerader Anzahl EINSen in der Eingabe. Bei XORVerknüpfung kann nach Ausfall einer Column (hier Zeile 3 rechts unten) durch erneute XOR-Berechnung aller verbliebenen Columns mit der Parity der ursprüngliche Wert zurückgerechnet werden. 4.3

4.3.1

Entwicklung Ursprünglich arbeitete RAID ausschließlich mit ganzen Disks. RAID-Level wurden während der Entwicklung einfach durchnummeriert. RAID-0: Concat – Mehrere Disks werden logisch hintereinander gehängt. Bereiche des Concat-Volumes jenseits der ersten Disk werden auf die folgenden Disks umgelenkt. RAID-0: Stripe – Mehrere Disks werden in sog. „Columns“ logisch ineinander verwoben. Jeweils x aufeinander folgende Sektoren eines Stripe-Volumes bilden eine sog. Stripe-Unit. Bei einem Stripe-Volume mit drei Columns gehört Stripe-Unit 0 zur ersten Disk, 1 zur zweiten, 2 zur dritten, 3 wieder zur ersten Disk usw. Ein großer sequentieller I/O auf einem Stripe-Volume führt zu mehreren kleinen, reihum ausgeführten physischen I/Os auf den Columns. Die Größe x wird als Stripe Unit Width oder Stripesize bezeichnet.

RAID-4: Stripe mit Parity auf dedizierter Disk - Zu allen Daten eines zugrundeliegenden Stripes wird stripeweise eine Parity berechnet und auf einer dedizierten Disk gespeichert. Da es sich hier nicht um einen ECC, sondern eine einfache Parity-Information handelt, kann RAID-4 nur noch den Ausfall einer einzigen Disk kompensieren. RAID-5: Stripe mit verteilter Parity - Wie RAID-4, jedoch wird die Parity-Information über die Stripe-Disks gleichmäßig verteilt (siehe Bild). Heutige RAID-Produkte arbeiten normalerweise mit Teilen von Disks, z.B. mit Partitions (SDS) oder mit Subdisks (VxVM). Außerdem gibt es Kombinationen von RAID-Leveln: RAID-01: Mirrored Stripe – Ein kompletter Stripe wird auf einen anderen Stripe gespiegelt.

RAID-1: Mirror – Mehrere Disks werden aufeinander gespiegelt, mit gleichen Daten an gleicher Stelle.

RAID-10: Striped Mirror – Mehrere individuelle Spiegel werden zusammen durch Striping verknüpft.

RAID-2/3: ECC over Words/Blocks - Error Correction Code wird mit den Daten gespeichert. Ohne kommerzielle Bedeutung.

Andere RAID-Level (RAID-S, RAID-6, RAID-7 etc.) sind nicht standardisiert und herstellerabhängig.

29

4 4.4

VOLUMES Eignungskriterien der RAID-Level RAID-Dreieck Die Kugeln geben die Eigenschaften an, nach denen optimiert werden soll, die Strecken liefern den geeigneten RAID-Level. Häufigste RAID-Level heute: RAID-10 in Software RAID-5 in Hardware

0 IDRA

RA ID5

Preis

Sicherheit

Durchsatz RAID-1 4.4

4.4.1

Finden des geeigneten RAID-Levels Das oben abgebildete sogenannte RAID-Dreieck stammt aus der Anfangszeit von RAID und gibt eine grobe Orientierung, welche RAID-Konfiguration sich für welches Problem eignet. An der Ecken des Dreiecks stehen die Kriterien, nach denen optimiert werden soll. Auf den Verbindungsstrecken findet sich der für je zwei der Kriterien passende RAID-Level. Es ist wohlgemerkt nicht möglich, nach allen drei Kriterien gleichzeitig zu optimieren. Mit RAID5 wurde dies versucht, der Versuch darf aber

4.5

aufgrund des geringen Durchsatzes bei kleinen Schreibvorgängen und des großen Performanceeinbruchs im Worst-Case (Diskausfall und besonders Recovery danach) als gescheitert betrachtet werden. Heute werden aufgrund gefallener Hardwarepreise meist kombinierte RAID-Level (Raid-01 bzw. RAID-10) eingesetzt. Bei diesen wird entweder ein RAID-0 (c/s) gespiegelt oder ein Concat bzw. Stripe aus unabhängigen gespiegelten Untereinheiten zusammengestellt.

Implementation von RAID in VxVM RAID-Konzept in VxVM: l

Benutzt Subdisks (Teile von Disks, Extents) statt ganzer Disks. Verwendet keine numerischen Level. l Statt dessen Parameter für layout-Schlüsselwort des vxassist-Kommandos. l Erlaubt Kombinationen von RAID-Leveln. l Erlaubt weitere Optionen, z.B. Logging. l Bietet umfangreiche Verwaltungsfunktionen und arbeitet vollständig dynamisch. l

4.5

Klassisches RAID und VxVM VxVM unterscheidet sich von den frühen oder heutigen einfachen RAID-Systemen durch etliche fortgeschrittene Features. Zu den wich-

30

tigsten gehört die selbständige Allokation des Diskspeichers nach Bedarf und mit bestimmten, adressierbaren Eigenschaften (gleicher

4

VOLUMES Controller, Mirroring über Enclosures hinweg, Angabe von Disks, Controllern, Trays etc.). Aufgrund der damit verbundenen Komplexität wird das Frontend-Kommando vxassist benutzt, um die meisten Volume-orientierten Aktionen auszuführen. Dieses Frontend versteht die RAID-Level im Klartext („mirror“,

„stripe“, „concat“, „raid5“), erlaubt die Kombination von RAID-Leveln sowie weitere Optionen wie Logging, Snapshots, Größenund sogar Layoutveränderungen von Volumes. Alle diese Aktionen können online durchgeführt werden. Das Volume kann also gemountet und die Applikation aktiv bleiben.

Befehlssammlung Kapitel 4

4.6

Beispiele l

vxassist make avol 100m layout=[concat|stripe|mirror| stripe-mirror|mirrorstripe|raid5] l vxassist make avol 100m layout=stripe-mirror,log nmirror=3 ncol=2 nlog=3 xdg03 xdg04 xdg05 xdg08 xdg09 xdg10 l vxassist make avol 100m; vxassist mirror avol xdg06 xdg07 l vxassist mirror avol layout=stripe ncol=4 stwidth=256 Die Objekte xdg## sind die Namen der hier verwendeten Disks der Default-DiskGroup.

Hinweis Die häufigste Fehlermeldung von vxassist lautet: „Cannot allocate space...“. Dies ist aber in den meisten Fällen keine Platzfrage, sondern eine Frage der freien Spindeln! Bedenken Sie, dass alle Stripe-Columns und alle Mirror-Seiten auf eigene Spindeln gehören!

Befehle für Volumes vxassist make VolName Size [Opts] .................. vxprint -tr .................................................................................... vxassist remove volume VolName ........................... vxedit -rf rm VolName ......................................................

Erzeugt ein neues Volume. Gibt die Volumekonfiguration aus. Löscht ein intaktes Volume. Löscht auch defekte Volumes. 4.6

Verständnisfrage 4.1 Warum gibt vxassist trotz ausreichendem freien Platz einen Fehler aus („Cannot allocate space ...“) und alloziert nicht einfach die gewünschte Menge Diskplatz von irgendwelchen freien Bereichen?

Verständnisfrage 4.2 Mit welchem Layout-Typ können Sie vorhandenen restlichen Platz optimal nutzen, allerdings auf Kosten von Performance und Sicherheit?

31

4

VOLUMES

Ü 4

Übungen: Volumes erstellen

Ü 4.1

Volumes erstellen Erstellen Sie eine DG aus möglichst vielen (bis zu 12) freien Disks (außer den Disks in der rootdg). Legen Sie in dieser DG Volumes mit den unten aufgeführten Eigenschaften an. Messen Sie dabei mit dem time oder timex-Kommando jeweils die Zeit, die das vxassist-Kommando braucht. Schauen Sie sich auch immer wieder die Volumes mit dem vxprint-Befehl an (am besten vxprint -rt) und versuchen Sie, den Output zu verstehen. 100 MB Concat 100 MB Stripe mit 2 Columns l 100 MB Mirror-Stripe l 100 MB RAID-5

500 MB Mirror 500 MB RAID-5 l 4 GB Stripe l 4 GB Mirror

l

l

l

l

Hinweis Sie können beim Anlegen eines redundanten Volumes durch Setzen eines geeigneten Initialzustandes (init=...) ein zeitraubendes Synchronisieren vermeiden, wenn sichergestellt ist, dass das Volume anschliessend sowieso auf einer höheren Ebene initialisiert wird (z.B. durch Anlegen eines Filesystems oder Tablespaces). Geeignete Zustände sind active (überspringt die Synchronisation) und zero (für RAID-5, füllt das Volume mit Null-Daten und erspart so die Parity-Berechnung). Beispiele: vxassist make testvol 2g layout=mirror init=active vxassist make testvol 2g layout=raid5 init=zero Die Benutzung des Flags init=active ist erst seit kurzem von Veritas supportet, obwohl es schon lange existiert.

32

VOLUMES

4

Musterlösung und Antworten zu Verständnisfragen

4.1

100 MB Concat: ....................vxassist 100 MB Stripe, 2 Columns: .vxassist l 100 MB Mirror-Stripe: ........vxassist l 100 MB RAID-5: ....................vxassist l 500 MB Mirror: .....................vxassist l 500 MB RAID-5: ....................vxassist l 4 GB Stripe .............................vxassist l 4 GB Mirror: ...........................vxassist

Log Ü 4.1

l l

make make make make make make make make

avol avol avol avol avol avol avol avol

100m 100m layout=stripe ncol=2 100m layout=mirror-stripe 100m layout=raid5 500m layout=mirror 500m layout=raid5 4g layout=stripe 4g layout=mirror

Verständnisfrage 4.1 Warum gibt vxassist trotz ausreichendem freien Platz einen Fehler aus („Cannot allocate space ...“) und alloziert nicht einfach die gewünschte Menge Diskplatz von irgendwelchen freien Bereichen? Weil es keinen Sinn ergibt, auf der physischen Ebene die durch das Volume-Layout vorgegebenen Features wieder aufzuheben. Ein mirror-Volume, von dem mehrere Seiten auf der gleichen physischen Spindel liegen, bringt keine erhöhte Sicherheit. Ein Stripe, von dem mehrere Columns auf der gleichen Spindel liegen, erhöht nicht die Performance, sondern verringert sie! Das vxassistKommando erkennt solche Konflikte und vermeidet sie nicht nur, sondern verbietet sogar mutwillige Fehlallokationen durch Userangaben, sofern diese zu einer Gefährdung der angegebenen Volume-Eigenschaften führen würden.

Verständnisfrage 4.2 Mit welchem Layout-Typ können Sie vorhandenen restlichen Platz optimal nutzen, allerdings auf Kosten von Performance und Sicherheit? Mit einem concat-Volume, da bei diesem Layout die einzelnen Subdisks von unterschiedlicher Größe sein können, was bei Stripe und RAID-5 nicht der Fall ist.

33

KAPITEL 5

VOLUMES VERSTEHEN

5

VOLUMES VERSTEHEN Viele Fragen und ein paar klärende Worte … Warum liegt in jedem noch so simplen Volume immer auch ein Plex und nicht nur eine Subdisk? Gibt es auch Subdisks außerhalb von Plexes? Kann man in Plexes spiegeln? Wie stripet man über Plexes hinweg? Was sind diese Plexes überhaupt? Und warum kann ich nicht einfach auf das Volume verzichten und einen Plex mounten?

5.1

All diese Fragen lassen sich sehr kompakt beantworten. Man muss nur einmal verstanden haben, was die drei elementaren Datentypen – Subdisk, Plex und Volume – sind und welche Aufgabe sie haben. Dann ergibt sich der Rest von selbst. Beginnen wir mit dem Volume:

Aufbau eines Volumes Was ist ein VxVM–Volume?

Ein Volume besteht aus: l

Einer Schnittstelle nach „oben“ zu Filesystem/Applikation, mit Größe und Namen etc. l Einer Schnittstelle nach „unten“ mit Adressbereich, Plexes, UsageType, Zustand etc. l Ein Volume ist nur eine Datenstruktur, die Größe, assoziierte Plexes, Zustand und einige weitere Informationen (für VxVM intern) enthält! 5.1

Hinweis Die folgenden Kommando-Beispiele sind nicht im geringsten praxisrelevant. Sie dienen lediglich der Illustration dessen, was die einzelnen virtuellen Objekte darstellen. Selbst die größten Gurus benutzen zum Anlegen von Volumes den Befehl vxassist und nicht vxmake!

5.1.1

Volume folgenden Kommando-Beispiele sind nicht im geringsten praxisrelevant. Sie dienen lediglich der Ein Die Volume ist eine Datenstruktur, die zum trägt und das beim Importieren der DiskGroup Illustration dessen, was die einzelnen virtuellen Objekte darstellen. Selbst die größten Gurus benutzen Betriebssystem hin einen Device-Treiber bereit- angelegt wird. Innerhalb dieses Verzeichnisses zum Anlegen von Volumes den Befehl vxassist und nicht vxmake! stellt, durch welchen die Applikation (File- werden beim Importieren die Device-Treiber system oder Raw-Device-Zugriff) auf den für den Volume-Zugriff angelegt. logischen Adressraum des Volumes zugreifen Das Volume stellt also schlicht eine Partitionkann. Das Volume stellt also im wesentlichen kompatible Schnittstelle zum Betriebssystem den Device-Treiber bereit. Wo liegt dieser dar, d.h. wir können mit einem Volume genau Device-Treiber? Wie schon zuvor besprochen das gleiche tun wie mit einer Partition: ein gibt es in /dev ein Unterverzeichnis vx (für Filesystem darauf anlegen und dieses mounVeritas), innerhalb dessen sich alle Veritas- ten oder per Raw-Device, etwa aus einer bezogenen Treiber sammeln. Dort liegen, ana- Datenbank heraus, darauf zugreifen. log zu /dev/dsk und /dev/rdsk, ebenfalls Volumes erscheinen als „v“-Objekt (erste Spalte) dsk und rdsk Verzeichnisse. In diesen liegt im Output von vxprint. für jede importierte DiskGroup ein eigenes Beispiel: Manuelles Anlegen eines 10 Terabyte Verzeichnis, das den Namen der DiskGroup großen Volumes zur Benutzung als Filesystem

36

5

VOLUMES VERSTEHEN (usetype=fsgen; die Angabe eines UsageTypes ist hier zwar irrelevant, aber für das vxmake-Kommando syntaktisch Pflicht). vxmake vol Teravol len=10240g usetype=fsgen Das Volume hat noch keine Plexes und kann daher auch noch keine Daten speichern, die Schnittstelle nach „oben“ ist jedoch intakt. Sie können dies verifizieren, indem Sie nach dem Device-Treiber schauen, der sich jetzt in /dev/vx/dsk/xdg/Teravol befindet. Zugriff auf diesen ist jedoch leider nicht möglich, da man in diese leere Hülle nichts hineinschreiben oder aus ihr herauslesen kann. Die Fehlermeldung, wenn wir zum Beispiel versuchen, auf dem Volume ein Filesystem anzulegen (newfs /dev/vx/rdsk/xdg/ Teravol), lautet: „no such device or address“. Das bedeutet, der Device-Treiber ist zwar

vorhanden und wurde angesprochen, er kann aber sein (virtuelles) Gerät nicht finden. Bevor auf ein Volume zugegriffen werden kann, muss es zunächst gestartet werden (vxvol start Teravol). Beim Starten stellt VxVM fest, ob das Volume in Ordnung ist oder etwa unsauber heruntergefahren wurde, und nimmt ggf. entsprechende Aktionen vor (Fehlermeldung und Abbruch, Resynchronisierung o.ä.). Versuchen wir nun, unser leeres Volume zu starten, erhalten wir die Fehlermeldung „Volume Teravol has no associated data plexes“. Das Volume speichert seine Daten in „Plexes“ und benötigt mindestens einen Plex, der die gesamte Größe des Volumes ausfüllt (was bei 10 TB natürlich etwas schwierig werden könnte). Die Plexes sind die Container, welche die Volume-Daten enthalten.

37

5 5.2

VOLUMES VERSTEHEN Aufbau eines Plexes Was ist ein VxVM–Plex?

Ein Plex besteht aus: l

Einer Schnittstelle nach „oben“ zum Volume, mit Größe, Namen, Adressbereich, Zustand etc. l Einer Mapping-Table, die den einen Extent des Volumes umsetzt auf beliebig viele Extents der physischen Disks. l Ein Plex ist nur eine Datenstruktur, die Größe, assoziierte Subdisks, Layout, Zustand und einige weitere, VxVM-interne Informationen enthält. 5.2

5.2.1

Plex Ein Plex ist ein Datencontainer, der den gesamten Adressbereich des Volumes abbildet bzw. enthält. Das erste MB des Volumes findet sich also im ersten MB jedes im Volume enthaltenen Plexes wieder, und das letzte MB des Volumes im letzten MB jedes Plexes usw. Jeder Plex ist aber mit einer Mapping-Funktion versehen. Über diese Mapping-Funktion findet eine Umsetzung statt von seinen logischen Adressen bzw. Extents (Extents sind nichts weiter als ein Offset und eine Längenangabe) auf die physischen Extents der zugrundeliegenden Subdisks. Die logischen Adressen des Volumes sind mit denen des Plexes identisch (s.o.), werden im Plex jedoch durch eine Mapping-Funktion umgesetzt auf die entsprechenden physischen Diskblöcke. Die Art des Mapping bestimmt das sogenannte Layout des Plexes. Mögliche Layouts sind: l Concat l Stripe l RAID-5 (Stripe mit Parity) Alle fortgeschritteneren Layouts, wie Mirror und Stripe-Mirror, werden durch geeignete Kombinationen von Plexes hergestellt. Ein MirrorLayout im Plex gibt es nicht. Plexes werden von vxprint als „pl“-Objekt ausgegeben. Ähnlich wie ein Volume eine Zugriffsschnittstelle für das Filesystem darstellt, stellt ein Plex also eine interne Zugriffsschnittstelle für den

38

Volume Manager selbst dar. Ein Plex blendet aber kein Device-File in /dev/vx ein, sondern er reiht sich innerhalb des Volumes in eine Liste von Objekten ein. Diese Objekte werden bei Schreibzugriffen alle beschrieben, bei Lesezugriffen wird jedoch reihum aus ihnen herausgelesen (defaultmäßig, es lässt sich einstellen). Jeder Plex repräsentiert ja dieselben Adressbereiche und hat daher auch identischen Inhalt. Es ist also egal, von welchem Plex wir lesen; wir bekommen für dieselben logischen Extents stets dieselben Daten zurück. Analog zu dem leeren Volume aus dem ersten Beispiel kann man auch leere Plexes, quasi Hüllen, erzeugen. Die Länge eines Plexes ergibt sich stets aus der Summe der Größen der in ihm enthaltenen Subdisks. Mindestens ein Plex in einem Volume muss die volle Größe des Volumes erreichen, damit das Volume gestartet werden kann. Ansonsten hätte das Volume „Löcher“, für die es in der Welt der Partitionen kein Gegenstück gibt und die daher die Kompatibilität mit dem Filesystemtreiber brechen würden. Dies würde, wie bereits erwähnt, zu undefinierten Zuständen beim Zugriff und somit zur Betriebssystem-Panic führen. Anlegen eines Plexes für obiges Volume vxmake plex Teravol-01

5

VOLUMES VERSTEHEN Verständnisfrage 5.1 Andere Software-RAID-Produkte benutzen oft bestehende Allokationseinheiten, z.B. Partitionen oder Disks, als Basiseinheit. Diese werden „Bottom-Up“ zu Volumes zusammengebaut. Welche Beschränkungen bringt dieser Ansatz im Vergleich zu dem von VxVM?

5.3

Aufbau einer Subdisk Was ist eine VxVM–Subdisk?

Eine Subdisk besteht aus: l

Einer Schnittstelle nach „oben“ zum Plex, mit Größe, Namen, Zustand etc. l Einem Extent auf einer Disk, üblicherweise beginnend auf einer Zylindergrenze. Ein Extent besteht aus Beginn und Länge. l Eine Subdisk stellt den Speicherplatz zur Verfügung, auf den der Plex seine Lese- und Schreibrequests abbildet.

5 .3

5. 3.1

Subdisk Eine Subdisk ist das trivialste Objekt im Volume Manager: Es handelt sich schlicht um einen reservierten Extent (Beginn und Länge) auf einer Disk. Dieser wird natürlich nicht in der Partition Table (VTOC) eingetragen, sondern ausschließlich in der Private Region vermerkt. Er taucht als „sd“ Objekt im Output von vxprint auf. Volume Manager kann, falls nötig, auf jeder physischen Disk tausende von Subdisks allozieren. Subdisks dürfen Diskgrenzen nicht überschreiten. Das ist auch nicht nötig, denn die Mapping-Funktion des Plexes kettet sie nötigenfalls auf geeignete Weise logisch zusammen. Normalerweise werden Subdisks so alloziert, dass sie auf Zylindergrenzen beginnen. Dies lässt sich allerdings auch abschalten (in vxassist mit der Option nodiskalign). Das Anlegen einer 10 Terabyte großen Subdisk für obigen Plex ist jetzt natürlich unmöglich, denn dazu fehlen uns noch die gigantischen

physischen Disks. Oder haben Sie irgendwo 10 TB herumliegen? Im Jahre 2014 ist das voraussichtlich kein Thema mehr, aber mit dem heutigen Stand der Technik müsste gestückelt werden, bis der gesamte Plex gefüllt ist. vxmake sd xdg01-01 disk=xdg01 len=100m offset=0 vxmake sd xdg02-01 … Vielleicht hätten wir das Volume doch etwas kleiner anlegen sollen ... ? Also löschen wir jetzt die ganzen Objekte wieder. Dafür gibt es das Allround-Kommando vxedit mit dem Keyword rm: vxedit rm Teravol Teravol-01 xdg01-01 xdg01-02 Was uns beim Output von vxprint wahrscheinlich auffiel, war, dass die Objekte einzeln herumlagen und nicht zu einem Volume verknüpft waren. Aus didaktischen Gründen hatten wir beim Volume angefangen und

39

5

VOLUMES VERSTEHEN nicht, wie es technisch geschickter gewesen wäre, bei der Subdisk. Machen wir es nun andersherum, und gleich mit einer realistischeren Größe (100 MB): 1. Subdisk anlegen. Sie können vorher mit vxdg free eine Liste freier Extents erhalten: vxmake sd xdg01-01 disk=xdg01 len=100m offset=0 2. Plex anlegen und mit Subdisk assoziieren: vxmake plex myvol-01 sd=xdg01-01 3. Volume anlegen und mit Plex assoziieren. Der Usage-Type ist wieder syntaktisch Pflicht: vxmake vol myvol plex=myvol-01 usetype=fsgen 4. Volume starten: vxvol start myvol 5. Filesystem anlegen und mounten: newfs /dev/vx/rdsk/xdg/myvol mount /dev/vx/dsk/xdg/myvol /mnt Die Punkte 1. bis 4. übernimmt natürlich normalerweise das Kommando vxassist für uns. Setzen Sie spätestens jetzt eine Default-DiskGroup. Dies können Sie entweder prozesslokal durch Setzen der Environment-Variablen VXVM_DEFAULTDG tun oder systemglobal mithilfe des Kommandos vxdctl (für Vx Daemon Control): vxdctl defaultdg DG Überprüft wird der aktuelle Wert für die Default-DiskGroup hingegen mit dem vxdgKommando: vxdg defaultdg

5.4

Mirroring durch Plexes Was ist ein VxVM-Mirror?

Volume Plex Subdisk

Schreibzugriff

concat stripe concat

l

Ein Standard-Plex bildet grundsätzlich immer den gesamten Adressbereich des Volumes ab. l Mindestens ein Plex füllt das Volume vollständig aus. Sind mehrere Plexes in einem Volume vorhanden, so wird der Adressbereich mehrfach abgebildet. Dadurch ergibt sich eine Spiegelung als Resultat mehrerer Datenplexe. l Das Layout der Plexes darf unterschiedlich sein! l Einige Funktionen stehen nur bei identischem Layout aller Plexes zur Verfügung.

5.4

40

VOLUMES VERSTEHEN

5

Mirroring

5.4.1

Alle fortgeschritteneren Layouts, wie Mirror und Stripe-Mirror, werden durch geeignete Kombinationen von einfachen Plexes hergestellt. Ein Mirror-Layout im Plex gibt es nicht, wie wir oben gesehen haben. Für jeden Extent (oder Block oder Adressbereich oder wie Sie es nennen wollen) gibt es in einem Plex nur ein Gegenstück auf den physischen Disks. Für Mirroring bräuchte man mehrere Gegenstücke, was innerhalb eines Plexes aber nicht möglich ist. Die Lösung liegt natürlich auf der Hand: Um ein Volume zu spiegeln werden mehrere Plexes innerhalb des Volumes angelegt. Jeder dieser Plexes bildet den gesamten Adressbereich des Volumes ab (spiegelt ihn wieder). Noch einmal zur Wiederholung: Jeder Plex reiht sich innerhalb des Volumes in eine Liste von Objekten ein. Diese Objekte werden bei Schreibzugriffen alle beschrieben, bei Lesezugriffen wird defaultmäßig reihum aus ihnen herausgelesen. Jeder Plex repräsentiert ja dieselben Adressbereiche (nämlich den des Volumes, 1-

zu-1) und hat daher auch identischen Inhalt. Es ist also egal, von welchem Plex wir lesen; wir bekommen für dieselben Extents stets dieselben Daten zurück. Beim Schreiben werden alle Plexes beschrieben, also enthalten alle Mirrorseiten (Plexes) dieselben Daten. Ein Volume kann bis zu 32 Plexes enthalten; alle Plexes sind völlig gleichberechtigt. Es gibt keinen „Master-Plex“, der zuerst beschrieben wird, oder etwas ähnliches. Alle Plexes eines Volumes werden im Normalfall reihum gelesen. (Natürlich lässt sich auch dies wieder ändern. Siehe dazu die Hinweistafel.) Das Interessanteste ist natürlich, dass jeder einzelne Plex ein eigenes Layout haben kann und dass sich Plexes sehr leicht aus einem Volume entnehmen lassen, um so eine Zwischenkopie zu sichern, etwa für ein konsistentes Backup. Sie sehen also, es lohnt sich, die Datentypen von VxVM gut zu kennen, denn dann kann man mit dem Produkt anfangen zu „zaubern“.

Hinweis Man kann einen Plex auch so einrichten, dass er nicht vollständig mit Subdisks gefüllt ist. Einen solchen Plex nennt man „Sparse Plex“. Er kann z.B. zur Beschleunigung von sogenannten Hot Spots benutzt werden.

Verständnisfrage 5.2 Auf welche Weise könnte ein Sparse Plex einen Hot Spot beschleunigen?

41

5 5.5

VOLUMES VERSTEHEN Namenskonventionen DiskGroup

Namenskonvention l

Volume

oradg

…

datavol oradg04

Subdisk oradg05-02

oradg05 oradg05-02

oradg06

…

Disks

Plex datavol-01

Volume-Namen enden auf „vol“. l Plexes tragen den Namen des Volumes, gefolgt von einem zweistelligen Zähler. l DiskGroup-Namen enden auf „dg“. l Disks tragen den Namen ihrer DiskGroup, gefolgt von einem zweistelligen Zähler. l Subdisks tragen den Namen der zugehörigen Disk, gefolgt von einem zweistelligen Zähler. l vxassist verwendet bei den internen Objekten (Plexes, Subdisks) diese Namenskonvention.

5.5

Hinweis Jedes Volume trägt eine „Read-Policy“, die einen von drei Werten annehmen kann: round, prefer und select. Diese Policies bedeuten folgendes: round: Alle Plexes werden streng Round-Robin (reihum) gelesen. prefer: Lesezugriffe werden, wenn möglich, immer aus einem bestimmten (angegebenen) Plex getätigt. select (default): VxVM wählt selbst die Read-Policy zwischen round und prefer aus. Haben alle Plexes das Layout concat, oder sind mehrere stripe-Plexes vorhanden, so liest VxVM gemäß round-Policy. Ist jedoch genau ein Plex mit Stripe-Layout vorhanden, dann wird dieser Plex automatisch bevorzugt gelesen (prefer).

5.5.1

Namenskonventionen Bitte berücksichtigen Sie beim Anlegen von VxVM-Objekten folgende Namenskonventionen (Plexes und Subdisks werden von vxassist automatisch richtig benannt, die Namenskonvention ist aber dennoch wichtig zu kennen, damit man den Output von vxprint richtig interpretieren kann):

einem zweistelligen Zähler, z.B. datavol-01, backupvol-03 etc.

Volumes tragen einen frei gewählten Namen, der sich an der Aufgabe des Volumes orientiert, mit der Nachsilbe „vol“, z.B. appvol, datavol, backupvol etc.

Disks hängen an den Namen ihrer Diskgroup einen zweistelligen Zähler, z.B. oradg01, oradg02 etc.

Plexes gehören logisch gesehen zum abstrakten Layer des Volumes. Sie tragen daher den Namen des Volumes, gefolgt von „-“ und

42

DiskGroups tragen einen Namen, der sich an der Aufgabe aller Volumes der Diskgroup orientiert, gefolgt vom Appendix „dg“, z.B. oradg.

Subdisks tragen den Namen der zugehörigen Disk, gefolgt von „-“ und einem zweistelligen Zähler, z.B. oradg05-02, oradg14-56.

VOLUMES VERSTEHEN

5

43

5

VOLUMES VERSTEHEN Antworten zu Verständnisfragen Verständnisfrage 5.1 Andere Software-RAID-Produkte benutzen oft bestehende Allokationseinheiten, z.B. Partitionen oder Disks, als Basiseinheit. Diese werden „Bottom-Up“ zu Volumes zusammengebaut. Welche Beschränkungen bringt dieser Ansatz im Vergleich zu dem von VxVM? Die RAID-Software kann den Administrator beim dynamischen Verändern von Volumes nicht unterstützen. Der Administrator muss das Volume auflösen, die Allokationseinheiten (Partitions) manuell verändern und sie erneut zu einem Volume zusammenfügen. Es ist in der Regel nicht möglich, dass die Daten dabei erhalten bleiben (und schon gar nicht online weiter verfügbar)!

Verständnisfrage 5.2 Auf welche Weise könnte ein Sparse Plex einen Hot Spot beschleunigen? Indem eine besonders schnelle Subdisk (z.B. RAM-basiert) genau am Ort des Hot-Spots in einen ansonsten leeren Plex manuell mithilfe von Low-Level-Befehlen eingeblendet und dieser Plex als „preferred Plex“ gesetzt wird. Bei Lesezugriffen auf den Hot Spot wird dann nur der Sparse Plex mit der schnellen Disk gelesen. Schreibzugriffe gehen selbstverständlich auf alle Plexes. Schreibzugriffe auf den leeren Bereich des Sparse Plexes finden nicht statt. Diese Technik ist nur bei physischen Disks sinnvoll, bei SAN-basierten LUNs bringt sie in der Regel keinen Vorteil mehr.

44

KAPITEL 6

VOR- UND NACHTEILE DER RAID-LEVEL

6 6.1

VOR- UND NACHTEILE DER RAID-LEVEL Vergleich der RAID-Level RAIDLevel

Performance

1

5

0

0

––

–

0

0

++

multi-threaded random

0

0

6.1.1

46

++/– – Read/Write

++

+

0 SD 1

SD 2 2 GB

+/– Read/Write

––

SD 1

Darstellung

–/– – Read/Write

++

–

Sicherheit

0/– Read/Write

2 GB

Vergleicht man die einzelnen RAID-Level, die VxVM implementiert, also 0 (concat), 0 (stripe), 1 (mirror) und 5 (parity-stripe), in bezug auf ihre Kosten pro GB, Sicherheit und Performance mit einer physischen Disk, so fallen einige Punkte auf, die man nicht direkt erwartet hätte. Daher lohnt sich eine nähere Betrachtung: Preis pro GB: Dies ist trivial, es leitet sich einfach aus dem Verhältnis Nettokapazität zu Bruttokapazität her. Mirroring ist natürlich ungünstiger als RAID-5, da RAID-5 für einen ganzen Stripe nur eine einzige weitere Column benötigt, während Mirroring die doppelte Kapazität verlangt. Sicherheit: Auch dies ist einfach, da RAID-5 den Ausfall genau einer Column kompensieren kann, (einfaches) Mirroring hingegen maximal einen Ausfall pro Column. Concat und Stripe bieten nicht nur keinerlei Sicherheit, sondern die Ausfallwahrscheinlichkeit erhöht sich

0

1 GB

SD 2

Performance single-threaded sequentiell

0s

SD 1

Preis/GB

0c

SD 2

Eigenschaft

2 GB

6.1

sogar mit der Anzahl verwendeter Disks. Da bei einem Stripe alle Columns auf unterschiedlichen Disks liegen müssen, hat ein 10-Column Stripe also eine zehnmal so große Ausfallwahrscheinlichkeit. Der Unterschied zwischen Concat (-) und Stripe (--) liegt darin, dass bei Ausfall einer Disk eines Concat-Volumes unter Umständen noch Daten vom Beginn des Filesystems gerettet werden können, während dies bei einem Stripe praktisch immer ausgeschlossen ist. Das eigentlich Interessante ist die Betrachtung der Performance. Hier unterscheiden wir zwischen der Performance bei einzelnen großen sequentiellen I/Os (typisch für Filesystem-I/O) und der beim Random-Zugriff auf kleine Blocks (typische Datenbank-Last). Es fällt auf, dass im Gegensatz zur herkömmlichen Meinung die sequentielle Performance eines Stripe nicht deutlich besser ist als die

6

VOR- UND NACHTEILE DER RAID-LEVEL eines Concat. Den Grund dafür erfahren wir gleich. Dass die Schreibperformance eines Mirrors schlechter ist als die eines Concat leuchtet ein, da mehr I/O durchgeführt werden muss. Der Verlust ist jedoch relativ klein; er liegt bei Verwendung getrennter Controllerpfade bei ca. 5% pro zusätzlichem Plex (Mirror). Da ein RAID-5 Volume zunächst einmal ein Stripe ist, ist die Leseperformance dort auch nicht besser als bei einem nicht durch Parity abgesicherten Stripe (RAID-0s). Die Schreibperformance fällt hingegen stark ab, besonders bei kleinen I/Os. Den Grund dafür werden wird ebenfalls noch besprechen. Sie können sich schon jetzt merken, dass RAID-5 in Software normalerweise nicht das erfüllt, was

man sich davon verspricht. Kommen wir jetzt zum multi-threaded Write, der interessantesten Größe, denn normalerweise greift ein Server in einem Rechenzentrum letzlich immer auf eine Datenbank zu, und die erzeugt nun einmal diese Art von Last. Wir sehen hier, dass ein gespiegeltes Volume eine höhere Performance erreicht als eine physische Disk. Dies liegt daran, dass die einzelnen Plexes reihum gelesen werden und sich somit die Anzahl Requests pro Disk reduziert. Dasselbe gilt für Stripe- und Concat-Volumes und am meisten natürlich für eine Kombination aus Stripe oder Concat mit Mirroring, da dort schlicht am meisten Spindeln zum Lesen zur Verfügung stehen.

Entwicklung der Hard-Disks 1986-2003

6.2

Jahr

Kapazität

Datendurchsatz

Transaktionen/s

1986

20 MB

0,5 MB/s

15

1991

1.000 MB

2 MB/s

50

2006

200.000 MB

50 MB/s

150

Faktor

x 10.000

x 100

x 10

An der obigen Tabelle kann man sehen, wie stark sich die Größenordnungen seit Erfindung des RAID-Konzepts verschoben haben. Die Anzahl Transaktionen pro Sekunde hat sich um den Faktor 10 verbessert, der Datendurchsatz sogar um den Faktor 100. Im gleichen Zeitraum ist aber die Größe der Disks um das 10.000-fache angewachsen! Eine Datenbank von 200 Gigabyte Größe hätte im Jahre 1986 über 10.000 Disks benötigt, damit also rund 150.000 Anfragen pro Sekunde abarbeiten

6.2.1

6.2

können. Mit heutiger Hardware bekommen wir die ganze Datenbank zwar auf einer einzigen Disk unter, schaffen aber nicht einmal ein Tausendstel der Last, nämlich nur ca. 150 Operationen pro Sekunde. Diese schleichende Verschiebung der Größenordnungen ist ein Grund dafür, dass auch heute noch Striping als Allheilmittel gilt, wenn es um Disk-Performance geht, obwohl vielfach ein Concat aus mehreren Disks die bessere Wahl ist.

47

6

VOR- UND NACHTEILE DER RAID-LEVEL Verständnisfrage 6.1 Warum ist die Performance beim single-threaded sequentiellen Lesen von einem Stripe oft geringer als von einer einfachen Disk?

Verständnisfrage 6.2 Weshalb gilt trotzdem die Daumenregel, nach der Stripes zur Performancesteigerung führen?

Verständnisfrage 6.3 Warum ist die Performance beim Lesen von einem Mirror höher als von einer einfachen Disk?

Verständnisfrage 6.4 Weshalb eignen sich Software-RAID-5 Volumes im allgemeinen nicht für typische Rechenzentrums-Anwendungen?

Verständnisfrage 6.5 Welche Auswirkungen hat die (immer noch fortschreitende) Verschiebung von Kapazität, Geschwindigkeit und Latenz?

6.3

Zustand 1986 Ohne Striping

Mit Striping

Striping damals Früher war Striping auch vorteilhaft bei sequentiellem Zugriff. Beispiel: Lesen von 1MB von einzelner Disk benötigt durchschnittlich 0.5 Rotationen (rot) Latenz plus 3rot Datentransfer. Summe 3.5rot Lesen vom 6-fach Stripe benötigt max. 1rot Latenz plus 0.5rot Datentransfer. Summe 1.5rot

6.3

Betrachten wir einen großen sequentiellen I/O mit Disks aus der Zeit, in der RAID entwickelt wurde. Der I/O benötigt drei volle Umdrehungen der Platte, um die Daten zu transferieren. Zuvor muss noch durchschnittlich eine halbe

48

Rotation gewartet werden, bevor der erste Sektor gelesen werden kann. Das macht zusammen 3,5 Rotationen. Dazu kam damals noch häufig ein „Disk Interleaving Factor“, durch den logisch aufeinanderfolgende Sekto-

6

VOR- UND NACHTEILE DER RAID-LEVEL ren nicht physisch hintereinander lagen, um den I/O-Kanal nicht zu überlasten. Es konnten so schnell aus 3,5 Rotationen auch zehn oder mehr werden. Durch Striping über sechs Disks erhöht sich jetzt zunächst die Wartezeit auf den ersten Sektor. Da jede der Platten den ersten Sektor ihres Lesebereichs abwarten muss, erhöht sich die Initial-Latenz auf rund eine volle Ro-

tation. Dafür können jetzt die Daten in nur noch einer halben Rotation übertragen werden (Interleaving lassen wir jetzt außen vor). Somit hat sich die Gesamtzeit von 3,5 Rotationen reduziert auf 1,5 Rotationen, ein erheblicher Geschwindigkeitsvorteil. Aber dies gilt nur für die alten Disks, die pro Zylinder wenige Daten speicherten. Schauen wir uns die heutige Situation im nächsten Bild an.

Zustand 2006

6.4 Ohne Striping

Mit Striping

Striping heute Heute ist Striping bei sequentiellem Zugriff meist deutlich langsamer. Lesen von 1MB von einzelner Disk braucht 0.5rot Latenz plus 0.25rot Transfer. Summe 0.75rot. Lesen vom 6-fach Stripe benötigt 1rot Latenz plus 1rot

6.4

Selbst ein großer I/O liest heute normalerweise nicht mehr als einen Bruchteil eines Tracks der Disk. Die Latenz setzt sich jetzt zusammen aus der bekannten halben Rotation Wartezeit auf den ersten Sektor plus vielleicht einer viertel Umdrehung für die Daten. Die Umstellung auf Striping bringt hier zunächst eine Erhöhung der Initial-Latenz, denn wir warten auf den ersten Sektor der ungünstigsten Disk; die Übertragungszeit fällt natürlich kleiner aus. Dennoch hat sich die Gesamtlatenz in vielen Fällen verschlechtert! Darüber hinaus hatten wir wesentlich mehr

I/O-Setups zu behandeln, Interrupts zu bedienen etc. Insgesamt lohnt sich Striping heutzutage also nicht mehr unbedingt. Es hängt immer von den konkreten Gegebenheiten wie Disk-Parameter, Stripesize, Anzahl Columns und I/O-Verhalten ab. Das große Argument der Verteidiger von Striping lautet, durch Striping würde bei RandomZugriffen die Last auf die Disks gleichmäßiger verteilt und so die Gesamtperformance optimiert. Wir widersprechen diesen Leuten nicht, möchten ihnen aber gleichzeitig anbieten, ihren Horizont in Bezug auf Concat erneut zu

49

6

VOR- UND NACHTEILE DER RAID-LEVEL erweitern. Sie werden überrascht sein … Wir haben gerade nachgewiesen, dass Concat bei sequentiellen I/Os oft günstiger ist als Stripe. Als nächstes werden wir nachweisen,

6.5

dass Concat bei Random-I/Os nicht schlechter ist als Stripe (in vielen Fällen besser!) und dass große Stripe-Sizes fast immer besser sind als kleine.

Einfluss der Stripe-Size Zugriff

Kleine Stripe-Size

Random

l

sequentiell

0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 kleine Stripe-Size 8 KB

Random: gute Lastverteilung l Sequentiell: viele kleine I/Os l Misaligned: zwei I/Os statt einem

Große Stripe-Size l

Zugriff

Random: gute Lastverteilung l Sequentiell: effiziente große I/Os l Misaligned: keine zwei I/Os nötig

Random

sequentiell

2

3

0

1

2

3

große Stripe-Size 1024 KB 6.5

6.5.1

50

Bei der traditionellen Vorgehensweise wird die Stripesize an die I/O-Größe angepasst. Häufig werden Volumes für Datenbanken mit 8KB Stripesize angelegt, wenn diese ihre Daten in 8KB großen Blöcken abspeichern. Diese Vorgehensweise ist wegen der oben abgehandelten Veränderung der Diskgeometrie heute nicht mehr sinnvoll, sondern ausgesprochen ungünstig. Vergleicht man systematisch die Unterschiede zwischen kleinen und großen Stripesizes, so stellt man fest, dass die Lastverteilung bei Random-Zugriffen auf ein Volume unabhängig von der Stripesize ist. Volumes mit großer und kleiner Stripesize erhalten für jede Disk etwa gleich viele I/O-Anforderungen (siehe Abbildung oben). Im Fall des sequentiellen Zugriffs jedoch wird bei kleinen Stripesizes die Last zwar verteilt,

aufgrund der hohen Latenzen beim Zugriff und des hohen CPU-Aufwandes für einen I/OVorgang können aber sowohl Gesamtdauer als auch CPU-Belastung gegenüber einem einzelnen großen I/O deutlich ansteigen. Ein besonderer Nachteil besteht darin, dass man nicht sicher sagen kann, ob die I/OZugriffe der Anwendung genau auf ColumnGrenzen beginnen (aligned) oder mit einem Offset (misaligned). Schreibt die Anwendung ihre 8 KB großen Blocks mit einem Offset von beispielsweise 2KB, dann wird bei jedem I/O auf zwei Disks zugegriffen statt nur auf eine (6KB von der ersten Column und 2 KB von der nächsten), und die Zugriffszeit verschlechtert sich auch für Random-Zugriffe. Bei einer großen Stripesize macht dies nur in Ausnahmefällen einen Unterschied, nämlich wenn gerade auf den letzten Datenblock in der

6

VOR- UND NACHTEILE DER RAID-LEVEL Column zugegriffen wird. Ansonsten bleibt die große Stripesize gegenüber misalignedZugriffen immun. Nun folgt ein großer Gedankensprung: Haben wir ein Volume von 100MB Größe als Concat aus vier gleich großen Subdisks auf unterschiedlichen physischen Disks aufgebaut, so ist das I/O-Verhalten auf dieses Volume identisch mit dem auf ein Stripe-Volume mit einer Stripesize von 25MB. Ein Concat-Volume ist praktisch das gleiche wie ein Stripe-Volume mit extrem großer Stripe-Size! So teilt das Concat-Volume bei Random-I/O die oben beschriebenen Vorteile eines Stripes mit großer Stripesize, vermeidet aber gleichzeitig die Nachteile eines Stripe-Volumes bei sequentiellen I/O. Nicht einmal der Füllungsgrad des Volumes hat irgendwelche Auswirkungen, jedenfalls wenn es mit einem ufs- oder vxfsFilesystem initialisiert wurde, denn diese Filesysteme verteilen selbsttätig die Daten relativ gleichmässig über die Disk. Lediglich

bei Datenbank-Raw-Devices könnte ein Stripe günstiger sein, aber selbst dann nur, wenn die Tablespaces das Volume nicht ausfüllen. Zusammenfassend kann man sagen, dass das Concat-Layout derzeit die sequentielle Performance gegenüber einem Stripe häufig erhöht, ohne die Random-Performance zu verschlechtern. Da es darüberhinaus sehr viel einfacher ist, ein Concat-Volume zu vergrößern als einen Stripe, ist Concat zur Zeit in vielen Fällen das Layout der Wahl. Striping kann allerdings dann noch große Vorteile haben, wenn das Volume auf einem Disk-Array liegt, dessen einzelne Trays von unterschiedlichen Controllern angesprochen werden, oder gar über mehrere Arrays verteilt ist. Wird der Stripe über die Controller bzw. RAID-Arrays gleichmäßig verteilt, so kann auch die sequentielle Performance steigen, wenn ansonsten die Controller das Bottleneck darstellen.

6.6

RAID-01 vs RAID-10 RAID-01

RAID-01 l

Mirror

l

Disk

Disk

Stripe

Disk

Disk

Disk

Disk

Stripe

Disk

Disk

RAID-10

Mirror von Stripes. layout=mirrorstripe

RAID-10 l

Stripe

l

Disk

Disk

Disk

Disk

Mirror

Mirror

Mirror

Mirror

Disk

Disk

Disk

Disk

Stripe von Mirrors. layout=stripemirror

6.6

51

6 6.6.1

VOR- UND NACHTEILE DER RAID-LEVEL Kombination von RAID-Leveln: RAID-01 und RAID-10 Um auch bei gespiegelten Volumes die Größenbeschränkung aufheben zu können, wurden in späteren Implementationen von RAID-Systemen die Level 0 (stripe und concat) und 1 (mirror) kombiniert zu RAID-01 bzw. RAID-10. Dabei bezeichnet RAID-01 einen sogenannten mirror-stripe (bzw. analog einen mirror-concat), also ein RAID-0 Objekt, das durch ein weiteres RAID-0 Objekt gespiegelt wird. Der kombinierte Level RAID-10 hingegen bezeichnet einen stripe-mirror (bzw concat-mirror), bei dem einzelne RAID-1 Objekte (also voneinander unabhängige gespiegelte Einheiten) mit den RAID-0 Methoden Concatenation bzw. Striping vergrößert werden. Die Eigenschaften dieser beiden RAID-Level unterscheiden sich in verschiedenen Aspekten. Beispiel anhand eines Volumes mit zwei Mirror-Seiten. 1. Beim Ausfall von Disks: 1.1. RAID-01 Hier führt der Ausfall einer Disk zur Deaktivierung des gesamten betroffenen Stripes und somit zur kompletten Deaktivierung einer Mirror-Seite des Volumes. Der Ausfall einer weiteren Disk auf der anderen Mirror-Seite würde zum Ausfall des gesamten Volumes führen. 1.2. RAID-10 Hier führt der Ausfall einer Disk nur zum Ausfall einer Mirror-Seite der betroffenen StripeColumn bzw. eines Extents des Concat-MirrorVolumes. Weitere Disks können ausfallen, solange sie sich in anderen Stripe-Columns befinden bzw. andere Extents des Volumes betreffen.

2. Beim Betrieb im degradierten Zustand: 2.1 RAID-01 Es ist durch den vorangegangenen DiskAusfall eine Mirror-Seite des kompletten Volumes inaktiv. Folglich wird auch nicht mehr abwechselnd von den beiden Mirror-Seiten gelesen. Die Performance verringert sich durch die nicht mehr vorhandene Lastverteilung. 2.2 RAID-10 Hier sind für die anderen Stripe-Columns/ Extents noch beide Mirror-Seiten aktiv. Folglich werden die intakten Bereiche des Volumes weiterhin mit durch Load Balancing erhöhter Performance gelesen. 3. Nach Ersatz der ausgefallenen Disk 3.1. RAID-01 Es wird die ausgefallene Mirror-Seite des gesamten Volumes resynchronisiert, da seit dem Ausfall keine Schreibzugriffe mehr auf diese Seite gemacht wurden. 3.2. RAID-10 Es muss nur die Stripe-Column bzw. der Extent resynchronisiert werden, deren Mirror-Seite ausgefallen war. l

Nachteil von RAID-10: Die Konfiguration sieht im vxprint-Output unübersichtlicher aus und benötigt mehr VxVM-Objekte (Zur Erinnerung: Bei Standardgröße der Private Region sind maximal ca. 3000 Objekte pro DiskGroup möglich).

Verständnisfrage 6.6 VxVM kann nur auf Volume-Ebene (durch Einbringen mehrerer Plexes) spiegeln und nur auf Plex-Ebene (durch Mappen von Subdisks) stripen. Wie kann VxVM RAID-10 implementieren? Hier handelt es sich ja um ein Stripen über bereits gespiegelte Einheiten!

52

VOR- UND NACHTEILE DER RAID-LEVEL

6

Antworten zu Verständnisfragen Verständnisfrage 6.1 Warum ist die Performance beim single-threaded sequentiellen Lesen von einem Stripe oft geringer als von einer einfachen Disk? Man erleidet den Nachteil der erhöhten Rotationslatenz, denn es muss auf die langsamste Disk gewartet werden. Der Vorteil des parallelen Datentransfers ist aufgrund der Kürze dieses Transfers minimal. Nähert man die Stripe Unit Size einer Zylindergröße an, so kann dies zu Verbesserungen beim sequentiellen Zugriff führen, ohne Random-Zugriff zu benachteiligen. Dafür sind aber noch weitere Parameter entscheidend (Disk-Cachegröße, SCSI-Queue-Länge von Disk und Betriebssystem etc.), die aufeinander abgestimmt werden müssen.

Verständnisfrage 6.2 Weshalb gilt trotzdem die Daumenregel, nach der Stripes zur Performancesteigerung führen? Weil man selten single-threaded sequentiellen I/O hat, sondern meistens multiuser sequentiell oder multiuser random. Durch die Verteilung der Last auf mehrere Aktuatoren („Disk-Arme“) werden so mehr Transaktionen pro Sekunde durchgeführt.

Verständnisfrage 6.3 Warum ist die Performance beim Lesen von einem Mirror höher als von einer einfachen Disk? Weil die Plexes reihum gelesen werden und damit die einzelnen Disks entlastet werden.

Verständnisfrage 6.4 Weshalb eignen sich Software-RAID-5 Volumes im allgemeinen nicht für typische Rechenzentrums-Anwendungen? Dies hat mehrere Gründe. Zum einen sind (insbesondere kleine) Schreibzugriffe langsam, denn 1. Schreibzugriffe werden durch ein Transaktionslog abgesichert (siehe Kapitel 7: Logs). 2. Bei jedem Schreibzugriff, der weniger als einen ganzen Stripe beschreibt, müssen zunächst alte Daten gelesen und mit den zu schreibenden Daten per XOR verknüpft werden. Bei Ausfall einer Disk treten folgende Probleme auf (das Volume ist nicht mehr abgesichert!): 1. Lesezugriffe werden durch das jetzt nötige reconstruct-read ausgesprochen langsam. 2. Da Diskausfälle oft aufgrund von Überhitzungen geschehen und der reconstruct-read die Disks zusätzlich belastet, ist der Ausfall einer zweiten Disk nun besonders wahrscheinlich! 3. Die Wiederherstellung des Volumes nach Ersetzen der Disk belastet das Volume stark, macht die Applikation zusätzlich langsamer und erhöht nochmals die Belastung der Disks.

Verständnisfrage 6.5 Welche Auswirkungen hat die (immer noch fortschreitende) Verschiebung von Kapazität, Geschwindigkeit und Latenz? Bisherige Erfahrungen und „Daumenwerte“ veralten sehr schnell und sehr gründlich. Man sollte mit den Werten der tatsächlich benutzten Disks ermitteln, welche Volume-Layouts sich für ein Problem eignen.

Verständnisfrage 6.6 VxVM kann nur auf Volume-Ebene (durch Einbringen mehrerer Plexes) spiegeln und nur auf Plex-Ebene (durch Mappen von Subdisks) stripen. Wie kann VxVM RAID-10 implementieren? Hier handelt es sich ja um ein Striping über bereits gespiegelte Einheiten! Es müsste dazu möglich sein, anstelle von physischen Disks auf Volumes als Basis-Speicher der Subdisks zurückzugreifen. Die Volumes könnten dann als gespiegelte Volumes den unteren Layer eines RAID-10 bilden, das Striping geschähe darüber in einem normalen Striped-Plex. Mehr dazu in Kapitel 9.

53

KAPITEL 7 LOGS

7 7.1

LOGS Problem der Resynchronisierung Schreibvorgang

Problem: l

Daten

Schreibvorgang komplett

Plex 1

Schreibvorgang durch Crash etc. unterbrochen

Plex 2

Beim Crash während des Schreibens sind die MirrorSeiten nicht mehr überall identisch. l Ohne Reparatur würden nachfolgende Lesezugriffe auf die gleiche Stelle unterschiedliche Resultate liefern. Das kann zum Crash (Panic) führen. l Daher müssten alle MirrorSeiten komplett synchronisiert werden. 7.1

7.1.1

Wahrung der Datenkonsistenz bei redundanten Volumes Erinnern wir uns an die Grundlagen von Volumes: Damit nicht die darüberliegende Schicht, insbesondere das Filesystem, in undefinierte Zustände gerät und eine Panic auslöst, muss sich ein Volume nach oben hin genau so verhalten wie eine physische Partition. Das wichtigste Kriterium für diese Kompatibilität stellt die Datenkonsistenz dar. Das bedeutet, dass wiederholtes Lesen eines bestimmten Extents (oder Bereiches) eines Volumes immer identische Daten liefert, solange keine Schreibzugriffe auf diesen Extent geschehen. Diese Konsistenz kann nicht ohne weiteres garantiert werden, wenn ein Volume gespiegelt ist, also mehrere Instanzen der Daten in einem Volume liegen. Unter gewissen Umständen, besonders natürlich nach einem Crash, aber auch nach temporärem Ausfall eines der Plexes, können die Plexes unterschiedliche Daten enthalten. Konzentrieren wir uns zunächst auf den Crashfall: Die auf das Volume zugreifende „Applikation“, d.h. normalerweise Raw-Device-Datenbank oder Filesystem, schickt einen Schreibrequest für einen bestimmten Extent an das Volume. Dieser wird durch die beiden Plexes des gespiegelten Volumes auf zwei physische Extents auf unterschiedlichen Disks umgemappt. Dies ergibt zwei unabhängige I/Os, die nun mehr oder weniger unkoordiniert vom Betriebssystem (SCSI-Treiber) an die Disks geschickt werden. Um das ganze etwas dramatischer zu machen,

56

nehmen wir an, bei dem fraglichen Extent handele es sich um einen Teil der Inode-Tabelle des Root-Filesystems, also um recht kritische Daten. Irgendwann zwischen dem Abschicken des Requests an das Volume und der Rückkehr des Aufrufs fällt der Strom und damit auch das System aus. Wir wissen nun, dass nach dem Restart der beschriebene Bereich einen von drei Zuständen hat: l beide Seiten synchron mit neuem Inhalt l beide Seiten synchron mit altem Inhalt l beide Seiten nicht synchron Das ganze wird spätestens bei fünf Spiegeln sehr interessant; VxVM kann bis zu 32-fach spiegeln. Auf die Frage, wie ein Volume Management nun reagieren sollte, gibt es die unterschiedlichsten Antworten. Fast alle davon sind falsch, unvollständig oder gar gefährlich. Die meisten sind schlicht nicht zu Ende gedacht. Hier sind ein paar Beispiele: 1. Die Konsistenz ist nicht gewährleistet, also müssen alle Spiegel bis auf den „neuesten“ abgehängt werden. Dies ist zwar eine interessante Idee, nur woher sollen wir wissen, welche Seite „neue“ Daten enthält und welche alte? Glauben Sie es uns, es gibt nirgendwo so etwas wie einen Timestamp auf Disk-Blocks! Außerdem wäre das Volume dann nicht mehr gespiegelt. Ein weiterer Ausfall hätte fatale Folgen. 2. Das Volume Management soll erst die

7

LOGS Spiegelseiten komplett so synchronisieren, dass die neuesten Daten die alten überschreiben. Erst danach darf auf das Volume zugegriffen werden. Auch gut, nur wissen wir auch hier nicht, wo die „neuen“ Daten sind. 3. Das Volume Management soll sich vorher merken, wenn es einen Plex beschreibt, sodass es die neuen Daten findet. Dann kann eine der vorherigen Methoden benutzt werden. Das wäre eine gute Idee, aber was bedeutet das tatsächlich? Wir müssten vor jedem Plex-I/O einen synchronen I/O in ein Transaktionslog machen, denn wir müssen den Zustand crashfest, also persistent und mithin auf Disk, festhalten. Nach Ende des I/Os müssten wir den Log-Eintrag wieder löschen. Die sich daraus ergebende Performance wäre ausgesprochen schlecht! 4. Das Volume Management soll immer denselben Plex zuerst beschreiben und erst nach Ende des I/Os auf diesen Plex die weiteren I/Os beginnen. Dann kann beim Recovery von diesem „Master“-Plex auf die „Slave“-Plexes synchronisiert werden. Denkbar, aber erstens langsam und zweitens unvollständig: Was passiert, wenn aufgrund eines Fehlers auf dem Master-Plex eine Maschine eine Panic auslöst? Beim Wiederanlauf gibt es keinen Masterplex mehr, und wir haben dasselbe Problem wie vorher, nur stehen wir dann ohne Lösung da. Wenn man die Aufgabenstellung wirklich verstanden hat, kommt man auf eine ganz andere, viel einfachere Lösung: Es ist gar nicht die Aufgabe des Volume Managements, die neuesten Daten zu schützen! Eine Partition tut dies ja auch nicht, und das Volume muss sich dem Filesystem gegenüber wie eine Partition verhalten. Volume Management muss, genau wie eine Partition, nur die Konsistenz der Daten sicherstellen, nicht deren Aktualität! Es reicht daher völlig, irgendeine Instanz der Daten, ohne Rücksicht auf deren Aktualität, zum Überschreiben aller anderen Instanzen zu verwenden! Um dies zu verstehen, vergleichen wir, wie derselbe Ausfall bei einer Disk aussähe:

Wir schreiben also gerade die Inode-Table des Root-Filesystems auf einer physischen Disk, als plötzlich der Strom ausfällt. Fällt er aus, nachdem wir die Inode-Table geschrieben haben, so finden wir nach dem Reboot bereits die neuen Daten: Glück gehabt. Fällt er hingegen davor aus, so finden wir die alten Daten vor: Pech gehabt. Die Frage, ob wir nach dem Ausfall alte oder neue Daten bekommen, entscheidet sich bei einer physischen Partition also anhand eines Zeitunterschieds beim Stromausfall von vielleicht einer Hundertstelsekunde. Jeder Mechanismus zur Rettung der „neuesten“ Daten in einem redundanten Volume schafft also nicht mehr, als eine Partition eine Hundertstelsekunde länger online zu lassen. Ist dies sinnvoll? Natürlich nicht! Wir kümmern uns im Volume Management grundsätzlich nicht um User-Dateninhalte, sondern ausschließlich um deren Konsistenz. Denn das genannte Problem existiert ja schon so lange, wie es Disks gibt, und deshalb sind längst Mechanismen etabliert, die die Folgen eines Ausfalls abfangen: Transaktionslogs im Filesystem bzw. der Datenbank, die selbstverständlich synchron geschrieben werden. Wenn der User (besser gesagt die Applikation) Daten in ein Volume schreibt, für die gewährleistet sein muss, dass sie nicht durch einen Ausfall auf einen alten Stand zurückfallen können, so schreibt sie diese Daten synchron. Typischerweise gilt dies für Datenbankzugriffe, aber auch für Filesystem-Transaktionslogs. Solche synchronen Schreiboperationen gelten erst dann als endgültig, wenn der Systemaufruf zurückgekehrt ist. Erst danach kann sich die Applikation darauf verlassen, dass die Daten geschrieben wurden. Natürlich ist VxVM auch hier kompatibel mit dem Partitionsverhalten und kehrt bei synchronen Schreibvorgängen erst dann zurück, wenn alle Plexes endgültig beschrieben wurden. Damit ist ein Zurückfallen auf einen alten Datenbestand durch die Resynchronisierung ausgeschlossen und wir können völlig beliebig zwischen Spiegelseiten hin- und hersynchronisieren. Wichtig ist ausschließlich, dass hinterher alle Seiten identischen Inhalt haben.

57

7 7.1.2

LOGS Erkennung nichtsynchroner Inhalte und Resynchronisierungsvorgang Wie merkt VxVM überhaupt, ob ein Volume aktiv war und einen Crash mitgemacht hat, oder ob es sauber geschlossen wurde? Dafür ist ein Flag im Volume zuständig, das OpenFlag. Dieses wird beim ersten Öffnen des Volumes zum Schreiben gesetzt und beim letzten Schliessen des Volumes wieder genullt. Wenn dieses Flag ungleich Null ist, kann also eine Schreiboperation aktiv sein und damit ist der Inhalt der Plexes eines redundanten Volumes nicht mehr garantiert identisch. Als Beispiel für das Verhalten des OpenFlag könnte man den mount-Befehl und (stellvertretend für Datenbank-Raw-I/O) das Programm dd nennen. Beim Mounten wird das Volume geöffnet und somit der OpenFlag gesetzt, beim Unmounten wird das Volume wieder geschlossen und, wenn das Volume nicht noch anderweitig geöffnet war, das OpenFlag wieder genullt. Schreibt man, statt es zu mounten, mit dd im Raw-Modus auf ein Volume, so wird das OpenFlag beim Starten des Schreibvorgangs (wenn das Kommando dd den open()-Systemcall aufruft) gesetzt und nach Ende des I/Os (wenn dd den close()Systemcall tätigt) genullt. Da das Flag erst beim letzten close()-Aufruf genullt wird, ist gewährleistet, dass auch bei mehreren konkurrierenden Zugriffen stets klar ist, ob das Volume als ganzes garantiert synchron ist oder die Plexes unter Umständen verschiedene Inhalte haben könnten. Das OpenFlag muss natürlich bei jeder Änderung seines Zustandes in der Private Region persistent gespeichert werden. Wird ein Volume gestartet, so überprüft VxVM den Zustand dieses Flags. Findet es das OpenFlag gesetzt vor, so geht VxVM von einem Post-Crash-Szenario aus, andernfalls ist eindeutig klar, dass das Volume keine Resynchronisierung benötigt, da offensichtlich zum Crashzeitpunkt kein I/O aktiv war und mithin alle Plexes den gleichen Inhalt haben müssen. Viele meinen, VxVM müsse nach einem Crash zunächst die Volumes komplett resynchronisieren, bevor man sie wieder benutzen kann. Dies ist jedoch ein Irrtum. Die Volumes können vielmehr sofort benutzt werden. Sie bekommen lediglich ein Flag gesetzt, welches angibt, dass sie sich im Zustand „SYNC“ befinden. Dieses Flag verändert die Zugriffsmethode für

58

Lesen vom Volume wie folgt: Zu Beginn (beim Start des Volumes) wird im Speicher eine sogenannte Dirty-Region-Bitmap erzeugt, welche die Extents des Volumes in geeigneter Granularität enthält (ca. 512KB/Bit). Diese Bitmap wird komplett mit Einsen initialisiert, da VxVM annehmen muss, dass jeder Extent (jede Region) inkonsistent (also dirty) ist. Fällt nun eine Leseoperation an, so überprüft VxVM zunächst den Zustand der Bits in der Dirty-Region-Bitmap, die den zu lesenden Extent repräsentieren. Enthält die Bitmap dort bereits Nullen, so wird völlig normal vorgegangen: VxVM liest von dem Plex, der als nächstes an der Reihe ist (wir erinnern uns: die Plexes werden normalerweise reihum gelesen), und liefert die Daten nach „oben“, also normalerweise an das Filesystem oder an fsck, weiter. Enthält die Bitmap für den zu lesenden Bereich hingegen noch Einsen, so liest auch in diesem Fall VxVM zunächst über seine normale ReadPolicy (also reihum) die Daten aus dem nächsten Plex. Damit die Konsistenz nach oben gewahrt bleibt, muss VxVM jetzt dafür sorgen, dass die Applikation (Filesystem, fsck) bei weiteren Zugriffen auf den gleichen Extent exakt dieselben Daten bekommt. Er tut dies, indem er die gerade gelesenen Daten zunächst auf alle anderen Plexes kopiert und sie erst nach Abschluss dieses Kopiervorgangs nach oben weitergibt. Anschließend nullt er die korrespondierenden Bits in der Bitmap. Dieses Leseverhalten nennt man in der Volume Manager Terminologie Read-Writeback (oder kurz RDWRBACK), da gelesen und sofort auf alle anderen Plexes zurückgeschrieben wird, bevor die Applikation die Daten zu Gesicht bekommt. Während des RDWRBACK werden die Inhalte der Plexes aufgrund des RoundRobin-Leseverfahrens gewissermaßen kammförmig ineinandersynchronisiert. Es leuchtet ein, dass durch das RDWRBACKVerfahren ein Volume nunmehr auch nach einem Crash sofort starten darf. Die Konsistenz innerhalb des Volumes mag gestört sein, die Konsistenz nach außen ist jedoch intakt, und das ist alles, was das Volume Management leisten muss.

7

LOGS Nun fehlt nur noch eine Kleinigkeit: Wir würden gern irgendwann diesen Read-WritebackZustand wieder loswerden, denn er bedeutet zusätzliche Prüfungen auf Bitmap-Zustände, die man weglassen könnte, wenn einmal alles snychron wäre. Deshalb spaltet VxVM beim Starten eines solchen Volumes einen Thread ab, dessen einzige Aufgabe es ist, vom gesamten Volume einmal all jene Stellen zu lesen, deren korrespondierendes Bit in der DirtyRegion-Bitmap noch gesetzt ist, und das Ergebnis zu verwerfen. Der durch dieses Lesen hervorgerufene Seiteneffekt ist, dass die

Plexes nach Abschluss dieses Threads synchron sind und die Bitmap von diesem Zeitpunkt an ignoriert werden kann. Daher wird die Zugriffsmethode anschließend auf das alte, unbedingte Lesen ohne Check der DirtyRegion-Bitmap umgestellt und das SYNCFlag des Volumes wieder gelöscht. Die VxVM-internen Tasks können Sie sich übrigens mit dem Kommando vxtask list anzeigen lassen. Sie finden dort beim Resynchronisieren im Output auch das Schlüsselwort RDWRBACK wieder.

7.2

Inkonsistenter Spiegel – Lösung durch DRL DRL

Schreibvorgang

l

Daten

Schreibvorgang durch Crash etc. unterbrochen

Schreibvorgang komplett

Disk

Plex 1

2 Bitmaps mit je 1 Bit pro 512 KB Adressbereich des Volumes. l Wird vor dem Schreibvorgang synchron aktualisiert. l Hält nur die Orte fest, an denen momentan geschrieben wird. l Ältere Änderungen werden aus dem Log asynchron wieder entfernt.

Plex 2 DRL 7.2

7.2.1

Dirty Region Logging Stellt man bei gespiegelten Volumes VxVM ein wenig persistenten Speicher im Volume bereit, so schreibt er dort eine „Dirty-Region-Bitmap“ aus lauter Nullen hinein und ändert sie vor einem Schreib-I/O so ab, dass für jeden Extent, für den gerade I/O aktiv ist, das korrespondierende Bit gesetzt wird. Ist der Schreibvorgang beendet, kann (beim nächsten sowieso fälligen Schreiben des Logs) das Bit quasi nebenbei wieder zurückgesetzt werden. Das sogenannte Dirty-Region-Log (DRL) enthält also genau dort Einsen, wo gerade aktuell Schreiboperationen ablaufen. Beim Wiederanlauf eines DRL-bestückten Volumes nach einem Crash geschieht genau

das gleiche wie ohne DRL: Das Volume wird im RDWRBACK-Modus gelesen und ein Lesethread abgespalten, der das gesamte Volume dort liest, wo die Dirty-Region-Bitmap Einsen enthält. Der Unterschied liegt darin, dass die Bitmap nun aus dem Dirty-Region-Log heraus initialisiert wird, das normalerweise nur sehr wenige Einsen enthält (es wird bei ca. 200 Einsen gedrosselt). Damit ist der Wiederanlauf in sehr kurzer Zeit erledigt; allerdings dauert ein regulärer Schreib-I/O auf ein solches Volume natürlich etwas länger, da das DRL synchron beschrieben werden muss, bevor ein I/O in den Datenbereich gehen kann.

59

7

LOGS Bereitgestellt wird ein DRL am einfachsten mit dem Zusatz „,log“ zum Schlüsselwort „layout=LayoutType“ beim Anlegen eines gespiegelten Volumes. Beispiel: vxassist make testvol 100m layout=mirror,log Oder nachträglich mit vxassist addlog auf ein bestehendes Mirror-Volume: Beispiel: vxassist addlog testvol nlog=3 Durch das Anlegen eines DRLs wird eine Subdisk alloziert (irgendwohin muss VxVM die Bits schließlich schreiben), ein Plex vom Typ LOG erzeugt und um die Subdisk herum gelegt (VxVM kann, obwohl es Ausnahmen gibt, normalerweise nur über die Plex-Schnittstelle

7.3

auf Daten in der Public Region zugreifen). Der Plex schließlich wird in das Volume gelegt , erscheint im Output von vxprint aber nicht als ACTIVE-Plex, sondern als LOGONLY-Plex. Die Subdisk ist, da sie lediglich eine Bitmap enthält, nur wenige Blocks groß. Soll das DRL ebenfalls gespiegelt sein? Eine kurze Überlegung führt zu dem Ergebnis, dass ein DRL für ein Volume, von dem ein Plex und damit eine Spiegelseite ausgefallen ist, keinen Vorteil bringt, denn es ist in diesem Fall nichts zu synchronisieren. Daraus folgt, dass die Anzahl DRLs in einem gespiegelten Volume die Anzahl „Spiegel minus eins“ nicht zu überschreiten braucht. Bei einem normalen Volume mit zwei Plexes genügt also ein einziges DRL, ein 4-Wege-Mirror bräuchte 3.

Befehlssammlung Kapitel 7 Befehle für Logs vxassist addlog VolName ........................................... Fügt dem Volume ein Log hinzu. vxassist remove log VolName ............................... Löscht ein Log aus dem Volume. vxassist -g DG make … layout=mirror,log ....... Erzeugt ein Mirror-Volume mit Log.

Hinweis Das DRL ist doppelt ausgelegt. Es besteht aus zwei Bitmaps: einer Active Map und einer Repair Map. Im Reparaturfall wird die Active Map durch logisches OR in die Repair Map eingebracht und anschließend genullt. Anhand der Repair Map wird resynchronisiert, während die Active Map wieder aktiv wird. Dies fängt auch den Fall „Crash beim Schreiben während Reparatur“ ab.

Verständnisfrage 7.1 Wie und wann werden Logs beschrieben?

Verständnisfrage 7.2 Wo sollten Logs demnach vorzugsweise liegen?

Verständnisfrage 7.3 Welche Eigenschaften sollte eine für Logs vorgesehene Disk besitzen? Was wäre also die ideale Hardware für Logs?

Verständnisfrage 7.4 Welchen Nachteil hat dedizierte Hardware für Logs? Denken Sie an die Diskgroups!

60

LOGS

7

RAID-5 Logs

7.4 Problem

Intaktes RAID-4 oder RAID-5 A

B

C

D

E

l

XOR von A-E

Nach Crash beim Schreiben F

G

H

D

E

XOR von A-E

Neuberechnung sämtlicher Parity-Information beim Volume-Start F

G

H

D

E

XOR von F-H, D, E

Nach einem Crash stimmen Daten und Parity nicht unbedingt überein. Daher müssen vor Inbetriebnahme das gesamte Volume gelesen und sämtliche ParityBlocks neu berechnet und geschrieben werden. Das dauert sehr lange. l DRL reicht hier nicht, da es keine zweite Instanz der Daten gibt, von der aus kopiert werden könnte. Die Daten sind in sich inkonsistent. 7.4

RAID-4/5 Logging Bei RAID-4 bzw. der optimierten Variante RAID-5 stellt sich ein ähnlich komplexes, jedoch subtileres Problem: Hier gibt es nur eine Instanz der Daten, nicht mehrere. Die (virtuelle) andere Instanz wird bei Bedarf aus den verbliebenen Fragmenten plus der ParityInformation zurückgerechnet. Genau in diesem Zurückrechnen liegt der Haken. Geraten Daten-Columns und Parity-Column durch einen Crash oder Stromausfall „out of Sync“ (mittlere Darstellung im Bild oben), so könnten durch das Zurückrechnen im Volume Management tatsächlich falsche Daten erzeugt werden. Wir würden Daten erhalten, die weder den Ausgangszustand noch den Endzustand widerspiegeln, sondern etwas völlig neues, das durch die XOR-Verknüpfung von gemischten alten und neuen Daten entstanden ist! Passiert so etwas ausgerechnet im Superblock, der Inode-Table oder einem Transaktionslog, so können die Folgen verheerend sein. Betrachten wir die mittlere Darstellung der obigen Abbildung. Fiele in diesem Zustand die mit „H“ gekennzeichnete Datencolumn aus und führte dies überdies zu einer Panic, so müssten nach Reboot und Volume-Start die Daten der Column H durch XOR-Kombination der Columns F, G, D und E sowie der ParityColumn zurückgerechnet werden. Erhalten

würden wir für die Column H allerdings einen völlig sinnlosen Mischmasch von Bits, die weder mit dem vorherigen, noch mit dem späteren Zustand des Stripes irgendeine Ähnlichkeit aufweisen würden. Denn die logische XOROperation fände mit gemischt alten und neuen Ausgangswerten statt, die in der ParityColumn abgespeicherte Information basiert jedoch auf den alten Daten (mit den neuen wäre es allerdings auch kein bisschen besser). Daher muss zunächst beim Volume-Start die komplette Parity-Column neu berechnet werden. Um den Vorgang zu optimieren, wird tatsächlich - Sie haben es vielleicht erraten analog zum RDWRBACK während des Lesens die Parity neu berechnet, zurückgeschrieben und erst dann die Daten an das Filesystem geliefert. Ist dies geschehen und fällt nun eine Datencolumn aus, so werden zumindest die korrekten Daten der defekten Column erzeugt. Damit ist das Volume wieder in einem konsistenten Zustand, das darin enthaltene Filesystem allerdings in der Regel nicht. Letzteres kann durch Benutzung eines Logging-Filesystems wie ufs mit logging-Option beim Mounten oder vxfs (dort ist Logging default) verhindert werden. Um die nach einem Crash sonst unvermeidliche und sehr langwierige Rekonstruktion

61

7

LOGS sämtlicher Parity-Daten zu vermeiden, wird bei VxVM Volumes vom Typ RAID-5 defaultmäßig ein Transaktionslog mit angelegt. Dieses muss auf einer vom Volume unabhängigen Disk residieren (vxassist legt es automatisch entsprechend an) und enthält genug Platz für sechs Full-Stripe-Writes, also sechsmal die gesamte Stripesize einschließlich Parity, zuzüglich weiterem Platz für Metainformation. Es erscheint als separater, kleiner LOG-Plex mit eigenen Subdisks. Das RAID5-Log ist als Ringpuffer ausgelegt, so dass die siebte Schreibtransaktion die erste überschreibt, die achte Transaktion die zweite usw. Beim Schreiben in ein RAID-5 Volume

7.5

mit Log wird zunächst der gesamte Stripeinhalt ermittelt (evtl. Lesen alter Blocks, Berechnen der Parity), an der aktuellen RingpufferPosition in das RAID-5 Log geschrieben und der Ringpufferzeiger erhöht. Anschließend wird asynchron (denn die Daten sind nun sicher) auf die eigentlichen Columns geschrieben. Fällt bei einem durch RAID-5 Log geschützten Volume während des Schreibens die Maschine aus und kommt wieder hoch, so braucht beim Volume-Start nichts weiter getan zu werden als alle im Log gespeicherten Schreibvorgänge erneut auszuführen. Das Volume ist dann ohne Neuberechnung der Parity garantiert intakt.

Lösung durch RAID-5 Log Schreiben auf RAID-5 Log vor Schreiben auf Datendisks F,G,H,I,J XOR von F-J

A

B

C

D

XOR von A-E

E

Nach Crash beim Schreiben F,G,H,I,J XOR von F-J

F

G

H

D

RAID-5 Log l

Speichert ganze SchreibTransaktionen zwischen, um sie nach einem Crash wiederholen zu können. l Ringpuffer mit Platz für sechs Full Stripe Writes. l Größe hängt von Full Stripe Size ab.

XOR von A-E

E

Log Replay beim Volume Start F,G,H,I,J XOR von F-J

F

G

H

I

J

XOR von F-J

7.5

Management von RAID-5 Logs Anlegen bzw. Anlage verhindern: Angelegt wird das Radi-5 Log das DRL mit vxassist addlog. Logging ist bei RAID5 Volumes allerdings per Default bereits eingeschaltet. Sie können das Anlegen eines RAID-5 Logs verhindern, indem Sie statt layout=raid5 bei vxassist den Parameter layout=raid5,nolog übergeben.

62

Hinzufügen und Entfernen: vxassist addlog xvol fügt ein Log hinzu. vxassist addlog xvol nlog=4 fügt vier Logs hinzu. vxassist remove log xvol entfernt ein Log. vxassist remove log xvol nlog=4 lässt vier Logs übrig!

LOGS

7

Verständnisfrage 7.5 Warum spielt es für VxVM keine Rolle, in welcher Richtung die Mirror-Seiten synchronisiert werden? Was wäre der Vorteil, wenn VxVM sich merken würde, welche Mirror-Seite aktuell ist und welche nicht? Was wäre dazu nötig? Meinen Sie, dass sich der Aufwand lohnen würde?

Verständnisfrage 7.6 Wie groß muss ein RAID-5 Log mindestens sein? Wie läuft ein Schreibvorgang bei RAID-5 in Software ab? Es gibt drei verschiedene Fälle! 1. Full Stripe Write 2. Schreiben auf weniger als die Hälfte der Columns 3. Schreiben auf die Hälfte der Columns oder mehr

63

7 Ü7 Ü 7.1

LOGS Übungen: Logs DRL - Dirty Region Log Legen Sie ein Mirror-Volume mit DRL-Log an und fügen Sie drei weitere DRL-Logs hinzu. Löschen Sie zwei DRL-Logs, dann ein weiteres, dann das letzte. Auf welchen Disks liegen die Log-Plexes? Wie groß sind sie? Wie verhält sich VxVM beim Löschen des letzten Logs?

Ü 7.2

RAID-5 Log Legen Sie ein RAID-5 Volume ohne Log an. Fügen Sie ein RAID-5 Log hinzu. Versuchen Sie, ein weiteres Log hinzuzufügen. Löschen Sie anschließend alle RAID-5 Logs wieder. Auf welcher Disk liegt das RAID-5 Log? Lässt sich ein zweites RAID-5 Log einrichten und wenn ja, wo liegt es?

Ü 7.3

Logs verwalten (optional) Legen Sie ein Mirror-Volume an. Legen Sie gezielt ein Log auf einer bestimmten Disk an. Legen Sie weitere Logs an. Versuchen Sie, mit vxassist remove log gezielt ein Log von einer bestimmten Disk zu löschen. Was fällt auf?

Hinweis Beim Anlegen von Mirror- bzw. RAID-5-Volumes den Zusatz init=active hier nicht vergessen!

64

LOGS

7

Musterlösung

Ü7

DRL – Dirty Region Log

Log Ü 7.1

vxassist vxassist vxassist vxassist vxassist

make avol 100m layout=mirror,log addlog avol nlog=3 remove log avol nlog=2 remove log avol remove log avol

Auf welchen Disks liegen die Log-Plexes? Wie groß sind sie? Jeweils auf einer der Mirror-Seiten! Sie sind sehr klein. Wie verhält sich VxVM beim Löschen des letzten Logs? Ganz normal, kein Unterschied feststellbar. Insbesondere keine Warnung!

RAID-5 Log vxassist vxassist vxassist vxassist

make avol 100m layout=raid5,nolog addlog avol addlog avol remove log avol nlog=0

Log Ü 7.2

Auf welcher Disk liegt das RAID-5 Log? Auf einer anderen Disk als die Datendisks des RAID-5 Volumes. Lässt sich ein zweites RAID-5 Log einrichten und wenn ja, wo liegt es? Ja, wenn eine freie Disk vorhanden ist. Es liegt auf einer weiteren Disk, die nicht von Daten des RAID-5 Volumes belegt wird.

Logs verwalten (optional) vxassist vxassist vxassist vxassist

make avol 100m layout=mirror addlog avol adg04 addlog avol nlog=2 remove log avol !adg04

Log Ü 7.3

Was fällt auf? Die Disk-Allokation, die auf der Kommandozeile spezifiziert wird, ist nach Abschluss des Kommandos Bestandteil des Volumes. Soll sie entfernt werden, muss ihre Existenz im Volume mit dem !-Operator verneint werden. Bedenken Sie dabei die Sonderbedeutung von „!“ in vielen Shells (csh, tcsh, bash, zsh).

65

7 1.1

LOGS Antworten zu Verständnisfragen Verständnisfrage 7.1 Wie und wann werden Logs beschrieben? Sie werden synchron vor dem eigentlichen Datenzugriff beschrieben.

Verständnisfrage 7.2 Wo sollten Logs demnach vorzugsweise liegen? Alle Logs einer DiskGroup sollten zusammen auf einer oder wenigen Disks liegen. So bleibt der Aktuator der Datendisks ruhig.

Verständnisfrage 7.3 Welche Eigenschaften sollte eine für Logs vorgesehene Disk besitzen? Was wäre also die ideale Hardware für Logs? Sie sollte eine möglichst geringe Latenz haben. Da die Logs sehr klein sind, bieten sich für LogDisks sogenannte Solid-State-Disks an.

Verständnisfrage 7.4 Welchen Nachteil hat dedizierte Hardware für Logs? Denken Sie an die DiskGroups! Es wird pro DiskGroup eine Log-Disk (oder zwei, wenn die Logs gespiegelt werden sollen) benötigt. Manche Solid-State-Disks bieten Multi-LUN-Fähigkeit, so dass pro DiskGroup eine LUN benutzt werden kann.

Verständnisfrage 7.5 Warum spielt es für VxVM keine Rolle, in welcher Richtung die Mirror-Seiten synchronisiert werden? Gesichert wird durch das Log nur die Identität aller Spiegelplexes, nicht die Aktualität. Die Aktualität von Daten kann auf einer höheren Ebene durch Filesystem-Logs oder DatenbankTransaktionslogs gesichert werden. Was wäre der Vorteil, wenn VxVM sich merken würde, welche Mirror-Seite aktuell ist und welche nicht? Der Vorteil wäre minimal. Betrachten wir zum Vergleich eine einzelne Disk statt eines MirrorVolumes, so entspräche das einem Ausfall, der wenige Millisekunden früher oder später auftritt, je nachdem, welche Mirror-Seite beim Wiederstarten des Volumes aktiv wird. Was wäre dazu nötig? Dazu müsste vor und nach jedem Schreibzugriff auf jeden Plex synchron ein Log beschrieben werden. Meinen Sie, dass sich der Aufwand lohnen würde? Sicher nicht, denn der Zugewinn an Sicherheit ist minimal und der Performance-Verlust erheblich.

66

LOGS

7

Antworten zu Verständnisfragen (Fortsetzung) Verständnisfrage 7.6 Wie groß muss ein RAID-5 Log mindestens sein? Mindestens so groß wie ein voller Stripe. Bei VxVM enthält er sechs volle Stripes (default) für sechs parallele I/Os. Wie läuft ein Schreibvorgang bei RAID-5 in Software ab? Es gibt drei verschiedene Fälle! 1. Full Stripe Write Im Speicher wird die Parity gebildet und mit den Daten zusammen in das RAID-5 Log geschrieben. Anschließend werden die Daten in den Stripe geschrieben, also „persistiert“. 2. Schreiben auf weniger als die Hälfte der Columns Da bei Änderung nur einiger Disks die Parity-Information nicht mehr stimmt, muss diese aktualisiert werden. Es werden also erst die zu überschreibenden Daten plus die Parity gelesen. Diese Daten werden mit XOR aus der Parity heraus- und die neuen Daten in die Parity hineingerechnet. Anschließend weiter wie bei 1. 3. Schreiben auf die Hälfte der Columns oder mehr Auch hier muss die Parity angepasst werden. Hierzu werden erst die Columns gelesen, die sich nicht ändern (auf diese Weise müssen weniger Disks gelesen werden) und mit den Daten im Speicher mittels XOR verknüpft, wodurch der Parity-Block neu entsteht. Anschließend weiter wie bei 1.

67

KAPITEL 8

VOLUMES VERÄNDERN

8 8.1

VOLUMES VERÄNDERN Problemstellung: Dynamische Anforderungen an Storage Die Anforderungen an die Hochverfügbarkeit der Daten ändern sich l

Mirror statt RAID-5. 3 Mirror-Seiten statt 2. l RAID-10 statt RAID-01. l

Die Menge der Daten nimmt zu l l

Vergrößern von Volumes für Tablespaces und Filesysteme. Verkleinern von Filesystemen und Volumes zwecks Platzgewinn.

Die Anforderungen an die Performance steigen l l

Erhöhen der Anzahl Columns im Stripe. Erhöhen der Anzahl der Datenpfade.

Alle Änderungen sollen im laufenden Betrieb und möglichst ohne Performance-Einbuße möglich sein. 8.1

8.2

Lösung mit VxVM VxVM erlaubt Volume-Operationen online spiegeln entspiegeln l vergrößern l verkleinern l aufspalten l im Layout ändern Kommando dafür ist jeweils vxassist mit entsprechenden Schlüsselwörtern: mirror remove mirror growto / growby shrinkto / shrinkby snapstart / snapshot / snapback (wird später besprochen) relayout / convert (wird später besprochen) l l

8.2.1

8.2

Hinzufügen und Entfernen von Spiegelseiten (Plexes) Einem Volume können jederzeit weitere Plexes hinzugefügt bzw. bestehende entfernt werden. Das entsprechende Kommandowort von vxassist lautet mirror bzw. remove mirror. Beispiele: vxassist mirror VolName [layout=…] [StorageAttribute] vxassist remove mirror VolName [StorageAttribute] Ohne Layout-Spezifizierung erhält der Spiegel-Plex das gleiche Layout wie die bisherigen. Ist dies nicht möglich, z.B. mangels geeigneter Disks in der DiskGroup, so bricht die Operation ab. Ein abweichendes Plex-Layout kann mit Parametern wie layout, stripeunit, ncol, usw. wie üblich spezifiziert werden. Die Anzahl der neu hinzukommenden Spiegel–Plexes kann mit nmirror=… festgelegt werden.

70

VOLUMES VERÄNDERN

8

Storage-Attribute

8.3

Mehr Kontrolle über den Volume Manager Mit sogenannten Storage-Attributen können Sie die Auswahl der Storage–Elemente für jede vxassist-Aktion bestimmen. Unterstützt werden unter anderem: l Disks vxassist make avol layout=stripe adg07 adg08 adg09 l Controller vxassist make avol layout=stripe ctlr:c3 l Enclosures vxassist make avol layout=stripe enclr:emc0 l Trays vxassist make avol layout=stripe tray:t3,t2 l Verhaltensweisen vxassist make avol layout=mirror \ mirror=ctlr|enclr|target|tray

8.3.1

Noch mehr Kontrolle über den Volume Manager l

Storage Attribute lassen sich mittels „!“ auch negieren Storage Attribute lassen sich beliebig kaskadieren Beispiele: l Negation vxassist make avol layout=stripe !adg03 !adg02 l Kaskadierung vxassist make avol layout=mirror ctlr:c1,c3 mirror=ctlr l Beides kombiniert vxassist make avol layout=stripe-mirror mirror=ctlr \ ctlr:c1,c3 !c1t3d0 !c1t4d0 enclr:IBM_SHARK0 l

8.3.2

Geheimnisse des vxassist-Kommandos Schaut man sich eine komplexe vxassistKommandozeile an, so kann einem gestandenen Systemadministrator schon einmal der Schweiß ausbrechen: so viele Variablen, und alle scheinen irgendetwas zu machen, bloß was? Dabei ist es eigentlich nicht schwer; man muss sich nur die Funktion von vxassist klarmachen (Front-End für komplexe Allokationsvorgänge) und ein bisschen experimentieren, dann wird alles schnell klarer: Zunächst einmal: Die von vxassist angelegten Datentypen teilen sich auf in Volume, Plex und Subdisk. Zugegeben, es gibt noch ein paar weitere, eher exotische Kandidaten, aber diese drei sollten erst einmal reichen. Die Parameter, die wir vxassist auf der Kommandozeile mitge-

8.3.1

ben, müssen den richtigen Objekttypen zugeordnet und an diese weitergeleitet werden. Ein Beispiel: vxassist make avol 1g \ layout=stripe ncol=5 Sowohl die Layout-Angabe als auch die Number of Columns (ncol) adressieren das Plex-Objekt, das vxassist „nebenbei“ beim Volume-Erzeugen erstellt. Wohingegen das folgende Kommando: vxassist make bvol 1g layout=mirror den Plexes nicht zu sagen hat, sie arbeiten mit den Defaultwerten. Aber das Volume bekommt mitgeteilt, dass es nicht nur einen, sondern zwei Container (Plexes) anlegen muss. Die Angabe des „Layout“ ist also kontextabhängig

71

8

VOLUMES VERÄNDERN mal für den Plex, mal für das Volume interessant. Etwas komplexer: vxassist make cvol 1g \ ncol=3 nmirror=2 stwid=192 Dies reicht die Variablen ncol und stwid (die kürzeste Form von stripewidth) an alle Plexes weiter, nmirror hingegen an das Volume (damit es zwei Plexes generiert, alle mit den angegebenen Plex-Werten). Wir müssen nicht zwingend ein Layout angeben! Die LayoutAngabe wird ohnehin intern in einen geeigneten Variablensatz für Volume und Plexes umgerechnet und entsprechend an diese Objekte weitergeleitet. Wir können, wie gezeigt, die Zielvariablen auch direkt adressieren. Nächstes Beispiel: vxassist make dvol 1g adg01 adg02 Dies instruiert vxassist, nur die zwei angegebenen Disks zur Allokation zu verwenden. Eigentlich ist das eine Kurzform des folgenden Kommandos: vxassist make dvol 1g \ alloc=adg01,adg02 Die Variable alloc enthält die Liste möglicher Disks, auf denen das Volume liegen darf. Sie wird bei der Allokation der Subdisks berücksichtigt. Darüberhinaus gibt es zahlreiche andere, teilweise undokumentierte, Variablen, die man nutzen kann. Schauen wir uns an, was der Befehl „vxassist help space“ bzw. „vxassist help alloc“ ausgibt, so finden wir Dinge wie ctype (Controller type, z.B. photon für FibreChannel), driver (sd), dirkrpm (U mdrehungsgeschwindigkeit der Disks), diskgeom (Geometrie der Disks), protection, enclosure, vendor und viele andere mehr. Die meisten dieser Attribute lassen sich bei vxassist adressieren, und zwar sowohl positiv als auch (mit vorangestelltem Ausrufungszeichen „!“) negativ. Benutzer von csh, tcsh, zsh und bash dürfen allerdings nicht vergessen, das Ausrufungszeichen jeweils zu quoten (“!“) bzw. zu escapen (\!), da diese Shells sonst versuchen, eine Command-Line-Substitution durchzuführen.

Aber nicht nur die Hardwareparameter setzt vxassist, sondern auch rein VxVM-interne Dinge. Zum Beispiel erzeugt das Kommando: vxassist make evol 1g \ layout=mirror logtype=dco \ nlog=2 fmr=on init=active ein Volume mit zwei Plexes (Layout=mirror), zwei Logs (nlog=2) vom (nicht-Default) Typ DCO, setzt das FastMirrorResync-Flag (wird später besprochen) und definiert den Initialzustand (init) als active, das heisst, es findet keine Synchronisation der anfangs völlig unterschiedlichen Plexes miteinander statt (dies ist immer dann sinnvoll, wenn das Volume anschließend ohnehin durch mkfs initialisiert wird). Sie sehen, die Kommandozeile von vxassist ist so unerschöpflich wie unerklärbar. Schauen wir uns also einmal an, was vxassist so alles kennt. Wo liegt das Executable? whence vxassist -> /usr/sbin/vxassist (whence ist ein ksh-builtin, das besser funktioniert als „which“. User von bash mögen stattdessen type -p benutzen). Jetzt schauen wir in das Executable hinein und suchen beispielsweise alles heraus, was nach striping aussieht: strings -a /usr/sbin/vxassist | egrep “stripe|stwid“ Wir finden (bei SF4.1) nicht weniger als 140 Einträge, die meisten davon sind gültige Kommandozeilenparameter, um die Stripewidth zu setzen. Vergeben Sie uns, wenn wir darauf verzichten, diese einzeln zu besprechen; wahrscheinlich kennen die Entwickler sie selbst nicht mehr alle. Suchen Sie sich einfach die Strings heraus, die Ihnen am meisten liegen, und benutzen Sie sie. Wir schlagen stwid vor, das ist kürzer als stripe_stripeunitwidth und erledigt dasselbe. Analog zur Stripesize können Sie mit der beschriebenen Vorgehensweise noch alle möglichen anderen, teilweise undokumentierten, Features von vxassist herausfinden. Wir hatten dabei viel Spass und wünschen Ihnen dasselbe!

Hinweis zur Negation Beim Entfernen von Spiegeln (wie schon bei den Logs) geben die Storage-Attribute an, was nach der Operation vom Volume verwendet werden wird! Nur durch Negation mit '!' kann man also spezifizieren, was aus dem Volume entfernt werden soll. Das Kommando vxassist remove mirror mirrvol adg04 entfernt eine Mirror-Seite

72

VOLUMES VERÄNDERN

8

aus dem Volume mirrvol, allerdings so, dass die Disk adg04 hinterher vom Volume noch verwendet wird! Der Plex, der adg04 enthält, wird also vor dem Löschen geschützt! Wenn Sie dies umständlich finden, können Sie statt dessen auch einen bestimmten Plex dem Volume entnehmen und gleichzeitig löschen mit vxplex -o rm dis Plex. Man kann die Logik hinter der Negation besser verstehen, wenn man die ursprüngliche Version der Allokationsangabe verwendet: eigentlich ist die Angabe vxassist … ad087 adg08 lediglich eine Kurzform für vxassist … alloc=adg07,adg08. Auf den angegebenen Disks wird also Platz alloziert! Dreht man dies zum Entfernen um, lautet der Befehl etwa: vxassist remove mirror … alloc=adg08. Damit ist klarer, was gemeint ist. Auf adg08 soll nach Ende des Befehl immer noch Platz des Volumes alloziert werden. Auf diese Weise wird das Verhalten wenigstens, wenn auch auf eine etwas merkwürdige Weise, systematisch.

Hinweis zur Allokation Die Angabe von Disks als Storage Attribute führt nicht dazu, dass alle angegebenen Disks auch tatsächlich benutzt werden. Diese stellen lediglich die Obermenge dar, aus denen sich das vxassist–Kommando selbstständig eine geeignete Untermenge heraussucht. Insbesondere ist es nicht möglich, durch Angabe mehrerer Disks zu erzwingen, dass ein kleines concatVolume über mehrere Disks verteilt wird. vxassist würde einfach von der Gesamtmenge des auf den angegebenen Disks verfügbaren Platzes so viel allozieren (vorzugsweise an einem Stück), dass es für das Volume reicht, selbst wenn dazu nur eine einzige Disk benötigt wird.

Verständnisfrage 8.1 Ihr 8fach Stripe-Volume läuft voll. Sie möchten es um 20% erweitern. Wie gehen Sie vor? Wie viele zusätzliche Disks benötigen Sie?

Verständnisfrage 8.2 Wie kann man VxVM dazu zwingen, für ein Concat-Volume mehrere Disks zu nehmen, auch dann, wenn jede in Frage kommende Disk allein schon genügend Platz für das Volume frei hat?

Verändern der Grösse von Volumes

8.4

l

Volumes können mit vxassist auch in der Größe verändert werden. Schlüsselwörter growto / growby und shrinkto / shrinkby l Vergrößern des Volumes hat keinen Einfluss auf darauf liegende Datenstrukturen (Filesystem, Datenbank–Tablespace) l Filesysteme auf übergroßen Volumes oder Partitionen können durch growfs bzw. fsadm vergrößert werden. ufs: growfs (nur Vergrößerungen) vxfs: fsadm -b (Vergrößerungen und Verkleinerungen) l Um Volume und Filesystem gleichzeitig und sicher zu vergrößern/verkleinern, wird vxresize benutzt. Beispiel: vxresize -F vxfs smallvol +10g 8.4 l

73

8 8.4.1

VOLUMES VERÄNDERN Das Kommando vxassist erlaubt auch die Veränderung der Größe von Volumes. Mit den Kommandowörtern growto und shrinkto wird die Größe des Volumes auf den angegebenen Wert (absolut), mit growby und shrinkby um den angegebenen Wert geändert (relativ). Die Größe eines evtl. darauf befindlichen Filesystems ändert sich jedoch durch vxassist nicht. Die Kommandos growfs (ufs) und fsadm -F vxfs -b (vxfs) dienen dazu, nur die Größe des Filesystems zu ändern. Zum zuverlässigen gleichzeitigen Ändern von Volume- und Filesystem-Größe verwenden Sie am besten das Kommando vxresize. Ein ufs lässt nur das Vergrössern, ein vxfs auch das Verkleinern zu. Beispiel: vxresize -F fstype [-x|-s] \ [-b] VolName [+|-]Size Die Optionen -x (expand) und -s (shrink) helfen gegen versehentliches Verkleinern oder Vergrößern aufgrund von Tipp- oder Berechnungsfehlern. Die Option -b führt wie üblich die Aktion im Hintergrund aus, + oder - erlaubt eine relative Größenangabe. Das Kommando vxresize lässt es nicht zu, ein Filesystem kleiner als die belegten Daten zu machen. Ist das Filesystem zu 100% voll, ist auch ein starkes Vergrößern nicht mehr möglich, da hierzu ein wenig temporärer Platz benötigt wird. Zur Abhilfe können Dateien gelöscht oder zunächst eine sehr geringe Vergrößerung versucht werden, um so Platz für den nächsten Vergrößerungsschritt zu schaffen. Beim Hinzufügen und beim Wegnehmen von Mirrors (wie auch von Logs) kann man die

Anzahl Objekte direkt auf der Kommandozeile angeben, zum Beispiel so: vxassist mirror avol nmirror=4 Dieses Kommando fügt dem Volume avol vier weitere Spiegel hinzu. Beim Entfernen ist die Logik hingegen, wie wir schon bei den Logs gesehen haben, etwas eigenartig. Das Kommando: vxassist remove mirror avol nmirror=3 entfernt nicht etwa drei Plexes, sondern es lässt drei übrig. Dies kann man nur nachvollziehen, indem man sich ins Gedächtnis ruft, dass die vxassist übergebenen Parameter stets für die Allokation stehen, nicht für eine allgemeine Adressierung. nmirror=3 bedeutet unter diesem Blickwinkel, dass beim Hinzufügen von Spiegeln 3 Plexes alloziert werden sollen, während beim Entfernen von Spiegeln bedeutet, dass 3 Plexes alloziert bleiben sollen. Mit der gleichen Logik leuchtet auch ein, dass der Befehl vxassist remove mirror avol mydg03 eben nicht jenen Plex entfernt, von dem eine Subdisk auf mydg03 liegt, sondern irgendeinen ausser jenen. Die Disk mydg03 soll alloziert bleiben. Um den Plex mit mydg03 tatsächlich zu entfernen, muss man also die Logik mit Hilfe des „!“-Operators umkehren: vxassist remove mirror avol !mydg03 Oder man benutzt das Low-Level-Kommando vxedit und adressiert den gewünschten Plex direkt: vxedit -rf rm myvol-04 Dadurch wird der Plex myvol-04 gelöscht (Keyword rm) und zwar durch -r rekursiv (denn er enthält noch Subdisks) und durch -f forciert (denn er ist noch Bestandteil des Volumes).

Achtung Das Verkleinern eines Volumes könnte ein dort befindliches Filesystem zerstören. Das Kommando vxassist gibt daher beim Verkleinern eines Volumes vom Usetype fsgen (File System Generic) eine Warnmeldung aus und fordert zum Ausführen die Eingabe der Option -f.

Verständnisfrage 8.3 Wenn ein Volume mit den angegebenen vxresize- oder fsadm-Befehlen in der Grösse verändert werden soll, so funktioniert dies nur, wenn das Filesystem bereits gemountet ist. Warum ist dies der Fall?

74

VOLUMES VERÄNDERN

8

Übungen: Volumes verändern

Ü8

Vorbereitung

Ü 8.1

Erzeugen Sie in einer Diskgroup bestehend aus 6 Disks zwei Volumes von 256 MB Größe. Das eine (avol) soll nur eine Subdisk enthalten, das andere (bvol) soll aus einem Stripe-Plex mit zwei Columns bestehen.

Hinweis Fragen Sie VxVM-Tasks für die folgenden Übungen in einer Schleife auf einem Terminal ab: while :; do vxtask list | tail +2; sleep 1; done

Ändern der Spiegel-Anzahl

Ü 8.2

1. Fügen Sie den beiden Volumes mit vxassist mirror ohne weitere Spezifikationen einen Spiegel hinzu. Was zeigt die vxtask-Schleife an? Welches Layout haben die neuen Plexes? 2. Wie erzwingen Sie, dass vxassist mirror einen Spiegel-Plex in einem von Ihnen gewünschten Layout erzeugt? Testen Sie, indem Sie dem Volume bvol einen dritten Spiegel, bestehend aus nur einer Subdisk, hinzufügen. Wann ist ein unterschiedliches Layout der Spiegel-Plexes sinnvoll? 3. Entfernen Sie mit vxassist remove mirror aus avol ohne weitere Spezifikationen einen Spiegel-Plex. Welcher Plex wird entfernt? 4. Entfernen Sie aus bvol den concatenated Plex. Wie stellen Sie sicher, dass genau dieser Plex entfernt wird?

Ändern der Volume-Größe

Ü 8.3

Das Volume avol ist wieder ungespiegelt und concatenated, bvol ein mirror-stripe Volume mit zwei Columns und zwei Plexes, beide 256 MB groß. 1. Legen Sie auf avol ein Unix- und auf bvol ein Veritas-Filesystem an: newfs /dev/vx/rdsk/DG/avol mkfs -F vxfs /dev/vx/rdsk/DG/bvol Mounten Sie die Volumes an /avol und /bvol. mount -F ufs /dev/vx/dsk/DG/avol /avol mount -F vxfs /dev/vx/dsk/DG/bvol /bvol 2. Vergrößern Sie avol mit vxassist growby um 256 MB. Zeigt der vxtask-Output etwas an? Wie groß ist laut df -k jetzt das Filesystem? Wie könnten Sie (bitte nicht ausführen) die Größe des ufs nachträglich anpassen? 3. Versuchen Sie, mit vxassist shrinkby bvol auf 192 MB zu verkleinern. Warum scheitert das Kommando mit den Standard-Parametern (Fehlermeldung beachten)? Wie könnte es zwangsweise durchgeführt werden? Belassen Sie jedoch bvol in seiner Originalgröße! 4. Verkleinern Sie avol zunächst wieder auf 256 MB mittels vxassist shrinkto. Vergrößern Sie jetzt avol mit dem Filesystem auf 512 MB unter Verwendung von vxresize [-x]. Warum würde ein erneutes Verkleinern von Volume und Filesystem auf jeden Fall scheitern? 5. Verkleinern Sie Volume bvol und sein Filesystem mit vxresize zunächst auf 192 MB und vergrößern Sie beides anschließend auf 512 MB. Wann und warum zeigt der vxtask-Output eine Aktion an? 6. Legen Sie unter /bvol eine Datei von 256 MB Größe an: mkfile 256m /bvol/file Versuchen Sie anschließend, bvol und sein Filesystem auf 192 MB zu verkleinern. Was passiert? 7. Löschen Sie /bvol/file und verkleinern Sie jetzt bvol und sein Filesystem auf 192 MB.

75

8 Ü8

VOLUMES VERÄNDERN Musterlösung

Log Ü 8.1

1. vxassist make avol 256m 2. vxassist make bvol 256m layout=stripe ncol=2

Log Ü 8.2

1. vxtask list zeigt ATCOPY (Atomic Copy), z.B.: 325 ATCOPY/R 08.66% 0/524288/45384 PLXATT bvol bvol-02 Die Plexes haben das gleiche Layout wie der Original-Plex. 2. vxassist mirror bvol layout=concat Unterschiedliches Layout ist sinnvoll, wenn z.B. zu wenige Disks vorhanden sind, wenn die Disks unterschiedlich schnell sind, so dass man einen Plex stärker stripen muss als einen anderen oder wenn man einen billigen dritten Spiegel zum Abtrennen (Snapshot) braucht. 3. vxassist remove mirror avol Der zweite Plex wird entfernt. 4. vxprint bvol Disk group: adg TY NAME ASSOC KSTATE LENGTH PLOFFS STATE TUTIL0 PUTIL0 v bvol fsgen ENABLED 524288 ACTIVE pl bvol-01 bvol ENABLED 526000 ACTIVE sd adg01-01 bvol-01 ENABLED 262960 0 sd adg03-01 bvol-01 ENABLED 262960 0 pl bvol-02 bvol ENABLED 526000 ACTIVE sd adg05-01 bvol-02 ENABLED 262960 0 sd adg06-01 bvol-02 ENABLED 262960 0 ENABLED 524400 ACTIVE pl bvol-03 bvol sd adg07-01 bvol-03 ENABLED 524400 0 vxassist remove mirror bvol !adg07 oder vxedit -o rm dis bvol-03

Log Ü 8.3

1. Siehe Aufgabe. 2. vxassist growby avol 256m df -k /avol Filesystem kbytes used avail capacity Mounted on /dev/vx/dsk/adg/avol 246511 9 221851 1% /avol Das Filesystem könnte vergrößert werden mit: growfs /dev/vx/rdsk/adg/avol 3. vxassist shrinkby bvol 64m vxvm:vxassist: ERROR: Shrinking a FSGEN usage type volume can result in loss of data. It is recommended to use the "vxresize" command or specify "-f" option to force the operation. 4. vxassist -f shrinkto avol 256m vxresize -x avol 512m Verkleinern würde scheitern, da UFS Filesysteme nicht verkleinert werden können. 5. vxresize -s bvol 192m vxresize -x bvol 512m Beim Vergrössern zeigt vxtask list etwa folgendes an: 1228 RDWRBACK/R 15.52% 393216/1048576/494896 RESYNC bvol da die hinzugekommenen Teile des Volumes zunächst miteinander synchronisiert werden. 6. mkfile 256m /bvol/file vxresize -s bvol 192m UX:vxfs fsadm: ERROR: sectors must be >= 526792 as they are currently in use.

76

VOLUMES VERÄNDERN

8

Antworten zu Verständnisfragen

Ü9

vxvm:vxresize: ERROR: Problem […] in diskgroup adg 7. rm /bvol/file; vxresize -s bvol 192m

Verständnisfrage 8.1 Ihr 8fach Stripe-Volume läuft voll. Sie möchten es um 20% erweitern. Wie gehen Sie vor? Wie viele zusätzliche Disks benötigen Sie? Mit dem bisher Gelernten geht dies nur durch Hinzufügen von acht weiteren Disks, da niemals verschiedene Stripe-Columns auf der selben Disk liegen dürfen.

Verständnisfrage 8.2 Wie kann man VxVM dazu zwingen, für ein Concat-Volume mehrere Disks zu nehmen, auch dann, wenn jede in Frage kommende Disk allein schon genügend Platz für das Volume frei hat? In mehreren Schritten durch sukzessives Vergrößern eines zunächst kleinen Volumes, zum Beispiel wie folgt: vxassist make avol 100m adg01 vxassist growby avol 100m adg02 vxassist growby avol 100m adg03 In einem Schritt geht es mit den bisher gelernten Allokationsbefehlen überhaupt nicht. Es gibt allerdings für vxassist das Flag -o ordered, das zusammen mit dem Schlüsselwort col_ switch zu diesem Zweck verwendet werden kann, jedoch ist der Aufwand im Verhältnis zum Ergebnis meist zu groß. Bei Interesse lesen Sie bitte die vxassist-Manpage.

Verständnisfrage 8.3 Wenn ein Volume mit den angegebenen vxresize- oder fsadm-Befehlen in der Größe verändert werden soll, so funktioniert dies nur, wenn das Filesystem bereits gemountet ist. Warum ist dies der Fall? Weil zum Vergrössern eines vxfs Datenstrukturen wie Allocation-Tables, Inode-Files etc. angelegt werden müssen und weil zum Verkleinern unter Umständen Daten von hinteren Teilen des Volumes nach vorne kopiert werden müssen. Dabei werden Dateizugriffe nötig, für die der Filesystem-Treiber benötigt wird. Ist das Volume gemountet, so können durch den vxfs-Treiber die notwendigen Aktionen initiiert werden. Bei ufs-Filesystemen ist ein vorheriges Mounten deswegen nicht nötig, da die zum Vergrößern notwendigen Änderungen (Cylinder Groups anlegen) durch relativ einfache Operationen auf dem Raw-Device möglich sind. Ein Verkleinern von ufs-Filesystemen ist hingegen generell nicht möglich.

77

KAPITEL 9

LAYERED VOLUMES

9 9.1

LAYERED VOLUMES Problemstellung Problem l

RAID-10 verlangt Striping über gespiegelte Einheiten. VxVM implementiert Striping auf Plex–Ebene, Spiegelung auf Volume-Ebene. l Striping müsste also oberhalb der Volume-Ebene implementiert werden. l

9.1.1

Hintergrund Als die Idee aufkam, RAID-01, als gespiegelte Stripes oder Concats, anders zu arrangieren und als RAID-10 zu betreiben (separat gespiegelte Einheiten, die anschließend zu einem Concat oder Stripe verbunden werden), sah sich Veritas zunächst mit einem Problem konfrontiert. Wir erinnern uns: Mirroring geschieht durch Einbringen mehrer Plexes, also Datenbehälter, in ein Volume. Striping oder Concatenation geschieht in Form des Layout innerhalb des Plexes, also logisch darunter. Mit diesem Konzept war RAID-10 zunächst prinzipiell unmöglich. Man hätte gespiegelte Volumes zusammenstripen müssen, um wieder ein (Hyper-)Volume zu erhalten, das dann mit eigenen Zugriffsmethoden auf die enthaltenen Volumes zugreift. Da hätte aber eine Verdopplung des Codes für Striping bedeutet: einmal der klassische Code für Striping innerhalb eines Plexes, einmal für Striping über Volumes. Dasselbe für Concat-Mirrors etc. Wieder hilft es, das Problem komplett, gewissermaßen von „ganz oben“ zu betrachten. Das Prinzip lautet: Wenn die kleinste Allokationseinheit (Subdisk) nicht mehr auf physischen Disks, sondern auf logischen Volumes beruhen würde, wäre praktisch jede denkbare Komplexitätsstufe machbar. Erinnern wir uns: Das manuelle Anlegen einer Subdisk geschieht, siehe Kapitel 5, etwa so: vxmake sd adg04-01 len=x disk=adg04 Als Disk mussten wir ein physisches Target angeben. Der Volume Manager benutzt von diesem Target die Public Region, also letztlich eine Partition bzw. einen reservierten Bereich, um daraus den Platz zu allozieren. Am Ende des Zusammenbaus des Volumes erhalten wir aber ein Objekt, das sich wiederum exakt wie eine Partition verhält. Warum sollen wir also nicht eine Subdisk auf einem Volume anlegen können? Dann könnten wir einzelne gespiegelte Volumes als Basis für Subdisks nehmen,

80

9.1

diese Subdisks wie bisher mit einem geeigneten Layout in Plexes einbringen und um den Plex wiederum ein Volume hüllen. Das Ergebnis wäre ein Stripe- oder Concat-Volume, das auf gespiegelten Einheiten basiert und somit vom Typ RAID-10 ist, mit allen Vorteilen, die dieses Konzept bietet. Tatsächlich ist das Anlegen eines RAID-10 Volumes mit vxassist heute nicht schwerer als irgendein anderes Layout zu erzeugen. Man übergibt einfach den geeigneten LayoutParameter (stripe-mirror bzw. concatmirror) und vxassist erledigt die ganze Arbeit. Um aber zu verstehen, was dabei passiert, gehen wir den Aufbau eines solchen Volumes von Hand durch. Versuchen wir es also; legen wir zunächst zwei gespiegelte Volumes an: vxassist make c1vol 1g layout=mirror vxassist make c2vol 1g layout=mirror Nun versuchen wir, auf einem Volume eine Subdisk zu erzeugen: vxmake sd c1-sd len=1g disk=c1vol Dies erzeugt leider nur eine Fehlermeldung: Volume does not have the storage attribute. Nun kommt ein Trick: Wir setzen ein Flag, das VxVM sagt, es handele sich bei dem Volume um Storage, also um so etwas wie eine physische Disk. Dieses Flag heißt layered: vxedit set layered=on c1vol c2vol Jetzt funktioniert das Erzeugen der Subdisks: vxmake sd c1-sd len=1g disk=c1vol vxmake sd c2-sd len=1g disk=c2vol erzeugt keinen Fehler mehr; die Subdisks für Columns 1 und 2 sind angelegt. Jetzt geht es normal weiter: vxmake plex r10plex sd=c1-sd,c2-sd \ layout=stripe stripesize=2048 vxmake vol r10vol plex=r10plex \ usetype=fsgen vxvol start r10vol

9

LAYERED VOLUMES Was ist durch das Setzen des Flags geschehen? Im wesentlichen wird dadurch der DeviceTreiber in /dev/vx/[r]dsk/DG/c#vol ausgeblendet. Ansonsten wäre ein konkurrierender Zugriff auf die zugrundeliegenden Volumes nicht auszuschließen gewesen, was wenig erquickliche Resultate gehabt hätte. Durch das Setzen des layered-Flags wird der Device-Treiber gelöscht, das Volume kann nur noch intern benutzt werden und ist daher frei, um als Basiselement für Volumes verwendet zu werden.

Durch das Konzept des Layering taten sich außerdem zusätzliche, bisher ungeahnte Lösungsmöglichkeiten auf, z.B. Online Relayout! Denn durch das Layering von Volumes ist es möglich, beliebige Teile eines Volumes temporär zu kapseln und seine Innereien in einem untergeordneten Layer zu verstecken, während man an ihnen beliebige Änderungen - nach oben hin transparent vornimmt. Wir werden dies in einem späteren Kapitel besprechen.

Verständnisfrage 9.1 Warum hatte zum Beispiel Solstice Disk Suite dieses Problem nicht? Welches Problem hat SDS stattdessen?

9.2

Lösung mit VxVM: Layered Volumes Lösung: Layered Volume Plex SV SV SV V2 P2 P2 S2 S2

V2

l Subdisks, die untersten

Einheiten eines Volumes, basieren auf RAID-Volumes statt Disks. l Praktisch jedes beliebige Volumeformat kann jetzt leicht abgebildet werden. l Kein Bruch des bewährten VxVM–Konzepts. l Andere Features (insbesondere Relayout) werden möglich. l Theoretisch beliebige Verschachtelungstiefe möglich (z.Zt. auf 5 beschränkt). 9.2

81

9 9.3

LAYERED VOLUMES Layered Volumes in der Praxis Benutzung von Layered Volumes l

Benutzertransparent bei Verwendung von z.B. stripe-mirror statt mirror-stripe bzw. concat-mirror statt mirror-concat. l Ab „Trigger-Point“ automatische Umschaltung auf layered bei stripe,mirror. l „Bindestrich“–Varianten den „Komma“–Varianten vorziehen.

9.3.1

mirror-stripe und mirror,stripe im Vergleich Bereits vor Einführung von Layered-Volumes erlaubte die Syntax von vxassist die Kombination von RAID-Leveln und anderen Features. Dies geschah einfach durch Angeben einer komma-separierten Liste beim LayoutParameter, etwa so: vxassist make newvol 1g \ layout=mirror,stripe,log oder so: vxassist make newvol 1g \ layout=stripe,log,mirror Diese Befehl haben das gleiche Ergebnis: Sie instruieren vxassist, das Zielvolume jeweils so anzulegen, dass es sowohl gespiegelt, als auch gestriped, als auch geloggt ist. Die genaue Art und Weise, wie dies zu erreichen ist, bleibt vxassist überlassen. Mit Einführung der Layered Volumes stellte sich das Problem, wie man den User an das neue Layout heranführen könnte. Dafür wurden zunächst einmal vier neue LayoutVarianten ersonnen: mirror-concat und mirror-stripe für RAID-01 (herkömmliche Volumes). concat-mirror und stripe-mirror für RAID-10 (layered, die neuartigen Volumes). Würde man mirror,stripe aber verbieten, wäre man nicht mehr abwärtskompatibel und würde Scripts und andere Prozeduren ungültig machen. Würde man mirror,stripe so wie mirror-stripe und stripe,mirror so

9.4

9.3

wie stripe-mirror behandeln, wäre ebenfalls die Kompatibilität zumindest fragwürdig, denn zuvor lieferten beide Kommandos dasselbe Ergebnis, danach jedoch nicht mehr. Als Lösung ersann man einen (konfigurierbaren) sogenannten „Trigger-Point“ (Default: 1GB). Bis zu dieser Größe wird bei der konventionellen Angabe ein non-layered Volume erzeugt, ab der Größe jedoch ein layered Volume. Folgendes ergibt also ein non-layered Volume: vxassist make testvol1 1023m \ layout=mirror,stripe Und nur 1 MB mehr führt durch Überschreiten des Trigger-Points zu einem layered Volume: vxassist make testvol2 1024m \ layout=mirror,stripe Die Qualität dieser Entscheidung mag jeder selbst bewerten, möglicherweise war sie das Resultat eines Komittees. Es ist wahrscheinlich günstiger, das Layout selbst zu definieren und daher ausschließlich die Schlüsselwörter zu verwenden, bei denen die Wortteile durch Bindestrich zusammengefügt sind: vxassist make testvol3 10m \ layout=stripe-mirror liefert ein 10MB kleines layered Volume, und vxassist make testvol4 100g \ layout=mirror-stripe ein 100GB großes non-layered Volume.

Lesen und Interpretieren von Layered Volumes l

Normal sind die Elemente v, pl und sd für Volume, Plex und Subdisk. Bei Layered Volumes gibt es zusätzlich v2, p2 und s2 für Elemente auf Layer 2. l Bei komlizierteren Layered Volumes kommen sogar v4, p4 und s4 vor. l

82

9.4

LAYERED VOLUMES

9

Beispiel: Output von vxprint -rtL auf ein layered Volume

9.4.1

l

Vom obersten Layer ausgehend sehen wir ein Volume (v) namens layvol, das nur einen einzigen Plex (pl) namens layvol03 enthält. l Dieser Plex wiederum enthält nun aber nicht, wie gewohnt, Subdisks, sondern statt dessen fünf Subvolumes (sv) namens layvol-S01 bis layvol-S05. l Die Anzahl von fünf Subvolumes korrespondiert mit der Anzahl der Stripe-Columns von layvol-03; layvol-03 ist ein 5-fach Stripe-Mirror-Plex (siehe 2. Zeile rechts). l Ein Subvolume entspricht einer Subdisk eines nonlayered Volumes.

l

Innerhalb jedes Subvolumes findet man nun ein Volume auf Layer 2 (v2) mit einem bestimmten Layout. Sozusagen hat also die Subdisk (Subvolume) des oberen Volumes bereits ein RAID-Layout. l In dem hier gezeigten Fall hat jedes Volume auf Layer 2 jeweils zwei Plexes auf Layer 2 (p2), ist also gespiegelt. l Jeder Plex auf Layer 2 besitzt hier eine Subdisk auf Layer 2 (s2), ist also ein concat Plex. l Komliziertere Layouts wären ebenfalls möglich, etwa striped oder RAID-5-basierte p2Plexes. Allerdings lassen sich solche Volumes nicht über vxassist anlegen, sondern nur manuell.

v layvol pl layvol-03

layvol

ENABLED ENABLED

ACTIVE ACTIVE

20971520 SELECT 20971520 STRIPE

layvol-03 fsgen 5/128 RW

sv v2 p2 s2 p2 s2

layvol-S01 layvol-L01 layvol-P01 big05-03 layvol-P02 big00-03

layvol-03 layvol-L01 layvol-P01 layvol-L01 layvol-P02

layvol-L01 ENABLED ENABLED big05 ENABLED big00

1 ACTIVE ACTIVE 24119840 ACTIVE 24119840

4194304 4194304 4194304 4194304 4194304 4194304

0/0 SELECT CONCAT 0 CONCAT 0

2/2 c2t1d0 c3t1d0

ENA fsgen RW ENA RW ENA

sv v2 p2 s2 p2 s2

layvol-S02 layvol-L02 layvol-P03 big06-03 layvol-P04 big01-03

layvol-03 layvol-L02 layvol-P03 layvol-L02 layvol-P04

layvol-L02 ENABLED ENABLED big06 ENABLED big01

1 ACTIVE ACTIVE 24119840 ACTIVE 24119840

4194304 4194304 4194304 4194304 4194304 4194304

1/0 SELECT CONCAT 0 CONCAT 0

2/2 c2t2d0 c3t2d0

ENA fsgen RW ENA RW ENA

sv v2 p2 s2 p2 s2

layvol-S03 layvol-L03 layvol-P05 big07-03 layvol-P06 big02-03

layvol-03 layvol-L03 layvol-P05 layvol-L03 layvol-P06

layvol-L03 ENABLED ENABLED big07 ENABLED big02

1 ACTIVE ACTIVE 24119840 ACTIVE 24119840

4194304 4194304 4194304 4194304 4194304 4194304

2/0 SELECT CONCAT 0 CONCAT 0

2/2 c2t3d0 c3t3d0

ENA fsgen RW ENA RW ENA

sv v2 p2 s2 p2 s2

layvol-S04 layvol-L04 layvol-P07 big08-03 layvol-P08 big03-03

layvol-03 layvol-L04 layvol-P07 layvol-L04 layvol-P08

layvol-L04 ENABLED ENABLED big08 ENABLED big03

1 ACTIVE ACTIVE 24119840 ACTIVE 24119840

4194304 4194304 4194304 4194304 4194304 4194304

3/0 SELECT CONCAT 0 CONCAT 0

2/2 c2t4d0 c3t4d0

ENA fsgen RW ENA RW ENA

sv v2 p2 s2 p2 s2

layvol-S05 layvol-L05 layvol-P09 big09-03 layvol-P10 big04-03

layvol-03 layvol-L05 layvol-P09 layvol-L05 layvol-P10

layvol-L05 ENABLED ENABLED big09 ENABLED big04

1 ACTIVE ACTIVE 24119840 ACTIVE 24119840

4194304 4194304 4194304 4194304 4194304 4194304

4/0 SELECT CONCAT 0 CONCAT 0

2/2 c2t5d0 c3t5d0

ENA fsgen RW ENA RW ENA

83

9

LAYERED VOLUMES Verständnisfrage 9.2 Wenn ein DRL auf einem Layered Volume angelegt wird (stripe-mirror), wo genau liegt die Subdisk/liegen die Subdisks für dieses Log? Gibt es ein großes DRL für das ganze Volume oder mehrere kleine DRLs; je eines für jede Stripe-Column, die ja jeweils ein einzelner Mirror ist?

Ü9 Ü 9.1

Übungen: Logs und Trigger-Points Trigger–Points und Layout–Versionen Legen Sie ein Volume namens cvol mit 10 MB Größe an mit layout=stripe,mirror. Prüfen Sie anhand von vxprint -trL das Layout des neuen Volumes. Löschen Sie das Volume wieder und legen Sie es mit 100 MB neu an. Prüfen Sie erneut das Layout. Tun Sie das gleiche mit 1000 MB und mit 1 GB. Legen Sie nun das Volume mit layout=stripe-mirror an. Variieren Sie auch hier die Größe und prüfen Sie das Layout mit vxprint -trL. Optional können Sie das gleiche mit layout=mirror,stripe und layout=mirrorstripe sowie mit den concat-Versionen (concat,mirror, concat-mirror etc.) tun.

Ü 9.2

Logs in Layered Volumes Fügen Sie je einem Non-Layered und einem Layered Volume ein Dirty Region Log hinzu. Suchen Sie das DRL mit vxprint -trL und analysieren Sie, warum es gerade dort im Layout angelegt wird. Fügen Sie jedem Volume ein weiteres Log hinzu. Können Sie die Übersicht bewahren? Versuchen Sie, das Layout trotzdem zu verstehen; es ist wichtig.

Hinweis Sie können alle Default-Werte von vxassist mit einem einfachen Kommando abfragen: vxassist help showattrs Dabei werden die von Ihnen in der Datei /etc/default/vxassist eventuell umgestellten Defaults ebenfalls berücksichtigt.

Verständnisfrage 9.3 Wie entwickelt sich das Layout des Volumes mit zunehmender Größe? Finden Sie dieses Verhalten eher hilfreich oder eher störend? Welche Schlüsse ziehen Sie daraus für Ihre tägliche Arbeit?

84

LAYERED VOLUMES

9

Musterlösung und Antworten zu Verständnisfragen

Ü9

vxassist make cvol 10m layout=stripe,mirror vxprint -trL cvol; vxedit -rf rm cvol RAID-01 (non-layered) vxassist make cvol 100m layout=stripe,mirror vxprint -trL cvol; vxedit -rf rm cvol RAID-01 (non-layered) vxassist make cvol 1000m layout=stripe,mirror vxprint -trL cvol; vxedit -rf rm cvol RAID-01 (non-layered) vxassist make cvol 1024m layout=stripe,mirror vxprint -trL cvol; vxedit -rf rm cvol RAID-10 (layered) vxprint make cvol 10m layout=stripe-mirror vxprint -trL cvol; vxedit -rf rm cvol RAID-10 (layered) vxprint make cvol 1200m layout=mirror-stripe vxprint -trL cvol; vxedit -rf rm cvol RAID-01 (non-layered)

Log Ü 9.1

vxassist make nvol 10m layout=stripe,mirror,log; vxprint -trL nvol vxassist addlog nvol [logtype=drl]; vxprint -trL nvol vxedit -rf rm nvol RAID-01, es existiert ein DRL insgesamt

Log Ü 9.2

vxassist make lvol 10m layout=stripe,mirror,log; vxprint -trL lvol vxassist addlog lvol [logtype=drl]; vxprint -trL lvol vxedit -rf rm lvol RAID-10, es existiert ein DRL pro Column

Verständnisfrage 9.1 Warum hatte zum Beispiel Solstice Disk Suite dieses Problem nicht? SDS benutzt als Basis eines Meta-Device entweder ein einfaches Device (Disk-Partition) oder ein Metadevice, unterstützt also gewissermassen von Haus aus Layered Volumes. Welches Problem hat SDS stattdessen? SDS basierte bis vor kurzem auf unterster Ebene auf Disk Partitions. Da diese vom Benutzer eingerichtet werden müssen, sind automatische Allokationen, Vergrösserungen oder Layoutveränderungen wie bei VxVM unmöglich.

Verständnisfrage 9.2 Wenn ein DRL auf einem Layered Volume angelegt wird (stripe-mirror), wo genau liegt die Subdisk/liegen die Subdisks für dieses Log? Gibt es ein großes DRL für das ganze Volume oder mehrere kleine DRLs; je eines für jede Stripe-Column, die ja jeweils ein einzelner Mirror ist? Ein DRL wird auf der Ebene der Spiegelung verwaltet. Beim stripe-mirror ist jede Column ein eigener, unabhängiger Spiegel, also wird pro Stripe Column jeweils ein DRL mit Plex und Subdisk angelegt. Die Subdisks liegen standardmäßig jeweils auf einer der Mirror-Seiten.

85

9

LAYERED VOLUMES Musterlösung (Fortsetzung) Verständnisfrage 9.3 Wie entwickelt sich das Layout des Volumes mit zunehmender Größe? Ab einer Größe von 1 GB wird automatisch auf ein Layered Layout umgeschaltet. Finden Sie dieses Verhalten eher hilfreich oder eher störend? Eher störend, denn es verhält sich in Abhängigkeit der Randbedingungen jeweils unterschiedlich. Welche Schlüsse ziehen Sie daraus für Ihre tägliche Arbeit? Die Ergebnisse der Varianten, bei denen RAID-Level durch Komma getrennt hintereinander gefügt werden, hängen vom Trigger-Point und der Volume-Größe ab. Die genau definierten Varianten, bei denen die RAID-Bestandteile durch Bindestriche getrennt werden, erscheinen zuverlässiger.

86

KAPITEL 10 RELAYOUT

10 10.1

RELAYOUT Problemstellung: Performance- und Größenoptimierungen l l

10.2

Bestehende Volumes sollen in effizientere Layouts überführt werden. Striped Volumes sollen vergrößert werden ohne Verdoppelung der Anzahl Disks.

10.1

Änderung des Volume- und des Plex-Layouts Gliedert sich in zwei Arten: relayout und convert l convert schaltet zwischen Layered und Non-Layered hin und her; wechselt Layout auf Volume-Ebene zwischen RAID-01 und RAID-10 l relayout ändert das Layout innerhalb der Plexes Wird über vxassist gestartet: vxassist relayout avol layout=stripe-mirror ncol=3 Einige sonst optionale Parameter sind jetzt erforderlich: layout=LayoutType l ncol=AnzahlColumns (nur bei Stripe–Typen und RAID-5) l

10.2.1

Änderungen des Volume-Layouts Veritas Volume Manager erlaubt es, bei aktivem Volume (das Filesystem ist gemountet und wird gelesen und beschrieben) das Layout des Volumes beliebig umzustellen. Um die dazu nötigen Kommandos zu verstehen, müssen wir allerdings zwei Arten von Layout unterscheiden: Volume-Layout und Plex-Layout. Volume-Layout Ein klassisches VxVM-Volume besitzt kein Layout im eigentlichen Sinne, auch wenn vxassist dies mit seiner layout=…-Angabe suggeriert. Vielmehr ist das Layout eine Eigenschaft jedes einzelnen Plexes, denn hier findet die Übersetzung von logischen in physische Extents statt. Ein Plex kann ein Layout vom Typ Concat, Stripe oder RAID-5 besitzen, die letzteren beiden mit zusätzlichen Parametern wie stripesize und Anzahl Columns. Ein VxVM-Volume hingegen kann lediglich einen oder mehrere Plexes besitzen. Das rechtfertigt eigentlich nicht den Begriff „Layout“. Was also ist das „Volume-Layout?“ Mit der Einführung von Layered Volumes kam etwas mehr Komplexität in den Aufbau eines Volumes hinein. Zwar enthält ein normales Layered Volume immer noch nur einen einzelnen Plex, aber obwohl das Mapping der logischen auf die physischen Extents bei der layered und der non-layered Version eines Volumes

88

10.2

völlig identisch ist, stellt sich das Volume selbst unterschiedlich dar und hat auch andere Funktionalitäten (insbesondere die höhere Ausfallsicherheit gegenüber den non-layered Versionen). Somit ist es wohl gerechtfertigt, von einem Volume-Layout zu sprechen. Um dieses Volume-Layout zu ändern, sprich: zwischen der layered und der non-layered Version desselben Volumes hin- und herzuschalten, benutzen wir vxassist mit dem Keyword convert. Dieser Befehl benötigt unabhängig von der Größe des Volumes sehr wenig Zeit (ca. 1 Sekunde), da das Mapping von logischen auf physische Extents unverändert bleibt und somit keine Daten kopiert oder bewegt werden müssen. Ein Beispiel, ausgehend von einem stripe-mirror: vxassist convert myvol \ layout=mirror-stripe und wieder zurück vxassist convert myvol \ layout=stripe-mirror Versuchen wir mit convert allerdings, auch das Plex-Layout zu ändern, so schlägt es fehl: vxassist convert myvol \ layout=raid5 liefert die Fehlermeldung: Cannot convert from stripe-mirror to raid5 Auch das Umwandeln eines concat-Volumes

10

RELAYOUT in einen mirror und umgekehrt schlägt fehl. Denn hierbei handelt es sich nicht um eine Konvertierung (zwischen layered und non-layered), sondern um das Hinzufügen bzw. Wegnehmen eines Spiegels. Dafür wird stattdessen vxassist mirror bzw vxassist remove mirror verwendet. Plex-Layout Ändern wir das Plex-Layout, also das Mapping zwischen logischen und physischen Extents, so verwenden wir das Keyword „relayout“ anstelle von „convert“. Nun beginnt eine äußerst kompliziert aussehende, für den User aber fast völlig transparente Metamorphose. Der Volume Manager überführt stückweise das Volume in das neue Layout. Dazu kopiert er die Daten eines Extents einer gewissen Größe (50MB oder 1GB, je nach Volume-Größe) zunächst in einen temporären Puffer und ändert das PlexMapping für diesen Bereich des Volumes so um, dass es auf diesen Puffer zeigt. Anschließend baut er den kopierten Extent des Volumes aus dem alten Layout ab, gibt die nicht mehr benutzten Bereiche frei und alloziert Subdisks für das neue Layout. Dorthin kopiert er nun die Daten aus dem Puffer und ändert das PlexMapping wiederum so ab, dass der betroffene Extent des Volumes bereits auf das neue Layout zeigt. Damit all dies ohne Unterbrechung vonstatten gehen und der I/O transparent weitergehen kann, müssen sich alle Teile – altes Layout, neues Layout und Scratchpad – innerhalb des selben Volumes befinden. Dies ist auch der Fall; alle bisherigen Bestandteile des Volumes werden während des Relayouts bis zum vierten Level nach unten geschoben, also mehrfach layered. Nach Abschluß des Relayouts trägt das Volume

komplett das neue Layout, die temporären Volumes (Scratchpad etc.) in den Zwischenlayern werden wieder aufgelöst und freigegeben. Das Relayout hat einige Besonderheiten: l Enthält das Ziellayout mehr als einen Plex, so entsteht immer ein layered Volume (auch wenn man ausdrücklich z.B. mirror-stripe, also non-layered, verlangt hat). l Vergisst man die Angabe ncol=xxx bei einem Stripe-Layout, so wählt VxVM selbst eine Anzahl Columns. Diese ist aber normalerweise so hoch (z.B. 12), dass dafür nicht genügend Disks zur Verfügung stehen und das Kommando mit einer Fehlermeldung abbricht. l Schlägt ein Relayout-Kommando bei der Vorprüfung fehl, so versucht vxassist automatisch, dasselbe Kommando mit dem Keyword „convert“ noch einmal zu starten. Man erhält die Fehlermeldung: „This operation is not a relayout -- trying convert“. Ist auch convert nicht in der Lage, die gewünschte Konversion vorzunehmen, so erhalten wir eine weitere Fehlermeldung vom „convert“-Versuch. Dies ist zum Beispiel der Fall, wenn wir versuchen, ein concatVolume mittels vxassist relayout in ein mirror-Volume zu verwandeln. l Erzwingt man „unter anderem“ ein PlexLayout, so nimmt vxassist relayout auch das Hinzunehmen oder Abtrennen von Plexes vor. Beispiel eines Stripes mit ncol=3: vxassist relayout myvol \ layout=stripe-mirror ncol=3 liefert die Fehlermeldung „This operation is not a relayout -- trying convert“, aber vxassist relayout myvol \ layout=stripe-mirror ncol=4 Relayoutet das Volume zu einem gespiegelten 4-Column Stripe-Mirror.

Relayout und Convert

10.3

Relayout von Volumes und Plexes: l Jederzeit möglich. l Wird online durchgeführt. l Darf durch Crash, Panic, Stromausfall etc. unterbrochen werden. l Wird nach Unterbrechung durch Volume-Start automatisch wieder aufgenommen. l Kann auch manuell abgebrochen, wiederaufgenommen oder umgedreht werden. l Wird durchgeführt durch vxassist relayout bzw. vxassist convert. l Wird überwacht durch vxrelayout status. Die durch Relayout eingeleiteten Tasks werden wie andere VxVM-Tasks durch vxtask list / monitor / pause / abort überwacht bzw. gesteuert. 10.3

89

10 10.3.1

RELAYOUT Relayout und Convert im Detail Convert auf Volume–Ebene vxassist convert schaltet zwischen einem layered und einem non-layered VolumeLayout ohne weitere Layout-Änderungen um: l mirror-concat Û concat-mirror l mirror-stripe Û stripe-mirror Da hierzu nur Änderungen in der Private Region nötig sind, ist die Laufzeit dieses Befehls sehr kurz. Relayout auf Plex–Ebene Jedes Layout, das vxassist make erzeugen kann, kann auch nachträglich mit vxassist relayout erreicht werden, wenn auch nicht unbedingt in einem einzigen Kommando. Das Ziel-Layout wird wie üblich mit layout=…

10.4

spezifiziert. Einige Beispiele: l concat Û stripe l stripe Û raid5 l Ändern der Anzahl der Columns l Ändern der Größe der Stripeunits Das Volume-Layout ist während des Konvertierens zu jedem Zeitpunkt regulär und damit crashfest. Das alte Layout wird Stück für Stück ab-, das neue ebenso aufgebaut, als Zwischenspeicher dient ein temporäres Subvolume. Möglich ist dies durch den Einsatz eines temporären layered Volume-Layouts mit bis zu 4 Ebenen.

Relayout-Vorgang schematisch Relayout l

Altes Layout

Neues Layout

0..49 MB 50..99 MB

Puffer 50MB

100..149 MB 150..199 MB RAID-5

RAID-10

Kapselung des Volumes durch ein Layered Layout. l Sukzessives Abbauen des Originals über einen Puffer ins neue Layout. l Auflösen des Layered Volumes. l Tatsächlich werden nicht drei, sondern bis zu sieben Objekte verknüpft. Ein Volume ist währenddessen schwer mit vxprint zu durchschauen. 10.4

10.5

Relayout Job-Management Verwaltung von Relayout–Jobs l

Relayout kann relativ lange dauern. Das Relayout kann nach dem Starten verwaltet werden. l vxrelayout und vxtask-Befehle werden gemischt verwendet. Statusabfrage: vxrelayout status VolName oder vxtask list Pausieren: vxtask pause Weiterlaufen: vxtask resume Stoppen: vxtask abort Nach Stoppen (insbesondere auch nach Crash etc.): Fortsetzen: vxrelayout start Undo-Funktion: vxrelayout reverse l

90

10.5

10

RELAYOUT Verständnisfrage 10.1 Weshalb können Sie mit vxassist relayout nicht ein Concat Volume in ein MirrorConcat Volume umwandeln?

10.5.1

Zusätzliche Informationen zum Relayout Die Geschwindigkeit des Relayouts hängt auch von der Größe des als Scratchpad benutzten temporären Subvolumes ab (Übrigens: dieses Subvolume ist stets gespiegelt). Die Größe lässt sich beim Kommando vxassist relayout bestimmen mit dem Parameter tmpsize=Size[kmgt]. Die Default-Größen orientieren sich an der Größe des Volumes: l Volume < 50 MB: Volume-Größe l Volume < 1 GB: 50 MB l Volume ≥ 1 GB: 1 GB In VxVM 3.5 vor MP2 bestimmt die Größe des temporären Subvolumes zugleich die Größe der Subdisks des Ziel-Layouts. Bei relativ kleinem temporären Subvolume entstehen auf diese Weise sehr viele Subdisks, die logisch und physisch concatenated sind. Regulär lassen sich diese Subdisks über vxsd join wieder verbinden. Einfacher, wenn auch undokumentiert, ist ein vxassist convert, zweimal hintereinander durchgeführt (hin und zurück). Dabei fasst VxVM so viele Subdisks wie möglich zusammen.

Hinweis Enthält das Original-Layout mehr als einen Daten-Plex, dann wird das Ziel-Layout immer ein layered Volume sein. Gegebenenfalls müssen Sie also noch anschliessend das Zielvolume zu RAID-01 konvertieren

Befehlssammlung Kapitel 9 bis 11

10.6

Befehle für Disks und Diskgroups vxassist mirror Volume ............................. Fügt dem Volume einen Datenplex hinzu. vxassist remove mirror Volume ........ Entfernt einen Datenplex aus dem Volume. vxassist growto|growby Volume Size Vergrößert das Volume. vxassist shrinkto|shrinkby Volume Size Verkleinert das Volume. vxassist convert Volume layout=… . Schaltet um zwischen Layered/Nonlayered. vxassist relayout Volume layout=… Ändert das Layout der Volume-Plexes. vxresize Volume Size ................................... Ändert die Größe von Volume und Filesystem. vxrelayout status Volume ....................... Zeigt den Fortschritt einer Relayout-Operation. vxrelayout start Volume .......................... Nimmt unterbrochenes Relayout wieder auf. vxrelayout reverse Volume .................... Kehrt unterbrochenes Relayout um. vxtask list .............................................................. Zeigt aktuelle VxVM-Tasks an. vxtask pause Task-ID ................................... Hält angegebenen Task an. vxtask resume Task-ID ................................ Lässt angehaltenen Task weiterlaufen. vxtask abort Task-ID ................................... Bricht angegebenen Task ab.

10.6

91

10

RELAYOUT

Ü 10

Übungen: Schwierigkeiten beim Relayout

Ü10.1

Relayout Beginnen Sie diese Übung mit einem concat Volume von 50 MB. Wandeln Sie dieses Volume nacheinander in die unten stehenden Layouts um. Einige Konvertierungen sind nicht möglich und führen zu Fehlermeldungen. Notieren Sie sich diese Fälle und suchen Sie zum Abschluss der Übung eine Erklärung dafür. Machen Sie bei Fehlern mit dem nächsten Ziellayout weiter oder versuchen Sie, das gewünschte Layout auf andere Weise zu erreichen: l mirror l stripe (ncol=3, stwidth=32) l mirror l concat l stripe-mirror l stripe l Raid5 (ncol=3, stwidth=64, nolog) l concat

Ü10.2

Convert Beginnen Sie diese Übung wieder mit einem concat Volume von 50 MB. Verwandeln Sie dieses Volume nacheinander in folgende Layouts. Einige dieser Konvertierungen führen zu einer Warnmeldung. Lesen Sie diese sorgfältig und schauen Sie sich das Layout nach dem Konvertieren an. Hat die Konvertierung stattgefunden oder nicht? l concat-mirror l mirror l stripe-mirror l mirror-stripe

Hinweis Denken Sie daran, dass bei vxassist relayout sowie vxassist convert bei einem Ziellayout vom Typ Stripe oder RAID-5 die Angabe ncol=# zwingend notwendig ist.

92

RELAYOUT

10

Musterlösung

Ü 10

l

mirror stripe

vxassist relayout vxassist relayout stwidth=32 l mirror vxassist relayout l concat vxassist relayout l stripe-mirror vxassist relayout l stripe vxassist relayout l RAID-5 vxassist relayout stwidth=64 l concat vxassist relayout l

avol layout=mirror (schlägt fehl) avol layout=stripe ncol=3 \

Log Ü10.1

avol layout=mirror avol layout=concat (schlägt fehl) avol layout=stripe-mirror (schlägt fehl) avol layout=stripe (schlägt fehl) avol layout=raid5,nolog ncol=3 \ avol layout=concat

concat-mirror vxassist relayout avol layout=concat-mirror mirror vxassist relayout avol layout=mirror l stripe-mirror vxassist relayout avol layout=stripe-mirror l mirror-stripe vxassist relayout avol layout=mirror-stripe Wie können Sie die Warnmeldung vermeiden? vxassist convert statt vxassist relayout benutzen.

Log Ü10.2

stripe-mirror vxassist relayout avol layout=stripe-mirror mirror-stripe vxassist relayout avol layout=mirror-stripe l stripe-mirror vxassist relayout avol layout=stripe-mirror Was fällt gegenüber der Übung 10.2 auf? Es gibt nicht mehr viele kleine Subdisks, sondern eine große. Dieses Verhalten ist allerdings von der verwendeten Version von VxVM abhängig. Neuere Versionen erzeugen normalerweise keine stark zersplitterten Subdisk-Allokationen mehr.

Log Ü10.3

l l

l l

Verständnisfrage 10.1 Weshalb können Sie mit vxassist relayout nicht ein Concat Volume in ein Mirror-Concat Volume umwandeln? Weil die Konvertierung von einem Concat in ein Mirror keine Änderung des Plex-Layouts ist. Diese Änderung sollte statt dessen mit vxassist mirror durchgeführt werden. Beide Plexes haben danach ein „concat“-Layout. Somit ist keine Änderung am Plex-Layout erfolgt.

93

KAPITEL 11 SNAPSHOTS

11 11.1

SNAPSHOTS Problemstellung: Inkonsistentes Backup-Image Backup bei aktiver Applikation

BackupImage aktueller Sicherungspunkt

Backup-Vorgang

l Während des Backups

Schreibvorgang der Applikation

ändern sich die Daten auf dem Filesystem. l Einige Änderungen beziehen sich auf bereits gesicherte Bereiche, andere auf noch nicht gesicherte. l Resultat: Das Backup spiegelt ein Filesystem wieder, das so nie existiert hat. Es ist inkonsistent.

11.1

11.1.1

Point-In-Time Copies, Snapshots Für viele Zwecke, am häufigsten zum Erstellen konsistenter Backups, möchte man einen Spiegel eines Volumes abtrennen und mit dieser Offline-Kopie, getrennt vom aktiven Original, weiterarbeiten. Würde man beispielsweise ein Backup von einem aktiven Filesystem ziehen, so würde das gesicherte Filesystem keinen konsistenten Zustand des Originals wiederspiegeln, sondern wäre im allgemeinen ein PhantomFilesystem, welches es in dieser Form im Original nie gegeben hat. Das kommt daher, dass das Backup selbst eine endliche Zeit braucht, und während dieser Zeit Änderungen im Filesystem, sowohl an bereits gesicherten, als auch an noch zu sichernden Dateien vorgenommen werden können. Dies führt zu logischen Inkonsistenzen, die bei normalen Filesystemen zwar üblicherweise keine kritischen Auswirkungen haben, beim Sichern aktiver Datenbank-Tablespaces jedoch zu korrupten Datenbanken führen. Auch andere Operationen können von einer kalten Kopie, einer sogenannten Point-InTime-Copy (PITC) eines Volumes profitieren, wir werden uns aber hier auf die BackupThematik beschränken. Die Prozedur des sogenannten Snapshottings beruht darauf, dass man das Volume um einen Spiegel reicher anlegt als für den Produktionsbetrieb nötig. Vor Beginn des Backups trennt man diesen „dritten Spiegel“ in einer (sehr kurzen) Operation von dem Originalvolume ab.

96

Durch die Kürze des Abtrennvorgangs – meist Bruchteile von Sekunden – verringert sich die Wahrscheinlichkeit logischer Inkonsequenzen gegenüber einem herkömmlichen Backup stark. Idealerweise sollte natürlich auch bei Verwendung von Snapshots das Filesystem unmounted sein, während man die Kopie zieht (den Spiegel abhängt), doch ist dies nicht mmer praktikabel. Bei Datenbanken, die Online-Backups erlauben, z.B. Oracle, wird stattdessen die Datenbank in einen speziellen Backup-Modus versetzt (nur für die Sekunde des Snapshottings) und dieser Modus anschließend wieder ausgeschaltet. Ohne Snapshotting müsste der Backup-Modus während des gesamten Backupvorgangs, oft für Stunden, beibehalten werden. Der Vollständigkeit halber sei erwähnt, dass es zahlreiche Methoden gibt, PITCs eines Filesystems zu ziehen, und jede hat Vor- und Nachteile: 1. Snapshot-Filesysteme: Hier wird über eine spezielle Mount-Option ein im Vergleich zum Originalfilesystem relativ kleiner Container (Volume, Partition) als „Snapshot von Filesystem xxx“ gemountet. Bei der ersten Änderung eines Extents im Original werden dessen Originaldaten zunächst in das Snapshot-Filesystem hineinkopiert und erst dann der eigentliche Schreibvorgang auf dem Original durchgeführt. Weitere Änderungen des gleichen Extents werden normal

11

SNAPSHOTS durchgeführt. Auf diese Weise enthält der Filesystem-Snapshot jeweils die Originaldaten jedes seit dem Zeitpunkt des Snapshots geänderten Extents. Dieses Prinzip bezeichnet man als „Copy On First Write“. Für Zugriffe auf das Snapshot-Filesystem werden für die im Original unveränderten Bereiche die Daten aus dem OriginalFilesystem gelesen, für geänderte Bereiche jedoch jene Daten, die vor Überschreiben des Originals in das Snapshot-Filesystem hineinkopiert wurden. Der Vorteil dieses Ansatzes liegt im geringen Platzverbrauch (ca 10% der Original-Filesystemgröße pro Tag). Ein entscheidender Nachteil ist jedoch, dass das Snapshot-Filesystem beim Mounten initialisiert wird (der Mount-Zeitpunkt ist der Zeitpunkt des logischen Snapshots). Das bedeutet, dass dieser Ansatz nicht crashfest ist, da nach einem Reboot der Snapshot neu gemountet und damit neu initialisiert würde. Damit fällt dieser Ansatz für Enterprise-Anwendungen normalerweise aus. 2. Snapshot-Volumes (unser Thema in diesem Kapitel): Hier wird, wie erwähnt, das Volume um einen zusätzlichen Spiegel erweitert. Der Nachteil ist evident: Es wird genausoviel Platz verbraucht, wie der Größe des Volumes entspricht. Dafür ist dieses Verfahren nicht nur crashfest. Man kann sogar

das Snapshot-Volume zum Sichern an einen anderen Host deportieren und so die Arbeit der Erstellung des Backup-Images delegieren. 3. Space Optimized Snapshot Volumes: Dies ist eine Kombination von 1) und 2), die nur wenig Platz verbraucht und dennoch crashfest ist. Allerdings kannn ein solcher Snapshot nicht deportiert werden. Diese Variante wurde mit der Storage Foundation 4.0 eingeführt und benötigt die Enterprise-Lizenz. Sie wird hier nicht besprochen. 4. Storage Checkpoints: Dies ist nur innerhalb eines Veritas Filesystems (vxfs) möglich und stellt dort für jeden festgehaltenen Snapshot quasi eine eigene Filesystem-Version bereit. Storage Checkpoints sind platzsparend, schnell und crashfest, aber ebenfalls nicht deportierbar. Dafür können mehrere dieser Storage Checkpoints gleichzeitig read-write gemountet sein und es können sogar weitere, hierarchische Checkpoints von ihnen angefertigt werden! Das Thema ist allerdings zu komplex, um es hier auszuführen; es kann nur im Rahmen einer Schulung sinnvoll übermittelt werden. Die Behandlung von Storage Checkpoints und Space Optimized Snapshot Volumes sind für eine spätere Ausgabe dieses Buches geplant.

97

11 11.2

SNAPSHOTS Lösung durch Snapshots Vorbereitung: Erstellen eines Snapshot-Plexes l Logisch gesehen Mirror-

SnapshotPlex

Seite, die nach Abtrennung zum eigenständigen Spiegelvolume wird. l Physisch gesehen spezieller Zusatz-Plex, der nach Abtrennung seine Herkunft weiterhin kennt. l Bietet keine vollständige Mirror-Funktionalität (WO).

Plex

11.2.1

SnapshotVolume

BackupImage

OriginalVolume

Abtrennung des Snapshot-Plexes l Erzeugt ein mit dem

Plex

Schreibvorgang der Applikation

Original inhaltlich identisches, aber unabhängiges Snapshot-Volume. l Nur in dem kurzen Moment des Abtrennens darf die Applikation nicht aktiv sein. l Snapshot-Volume kann auf dem gleichen Host bleiben oder an einen anderen Host exportiert werden. l Snapshot-Volume kann mit einem Befehl wieder in das Original-Volume zurückgebracht und resynchronisiert werden.

11.2.2

11.3

Benutzung von Snapshots lokal Snapshots bleiben lokal: 1a. 1b. 2a. 2b. 2c. 3. 4.

98

vxassist snapstart ....... Plex und Subdisks für Snapshot allozieren, synchronisieren. (vxassist snapwait ......... Für Scripts: Warten bis Snapshot fertig vorbereitet ist.) Applikation stillegen, also FS umount oder DB in Backup-Mode schalten. vxassist snapshot .......... Snapshot abtrennen und eigenes Volume daraus bilden. Applikation wieder starten, FS mount oder DB in Online Mode zurückschalten. Snapshot-Volume verwenden, z.B. Backup erstellen. vxassist snapback ......... Snapshot nach getaner Arbeit wieder resynchronisieren.

11.3

SNAPSHOTS

11

Resynchronisieren von temporär abgetrenntem Spiegel

11.4

Wollen wir per Snapshot sichern, so müssen wir zunächst, am besten gleich zu Anfang nach dem Einrichten des Volumes, den „dritten“ Spiegel anlegen (natürlich könnte es auch ein vierter, fünfter usw. sein). Da es sich hier um einen besonderen „Snapshot-Plex“ handeln wird, verwenden wir dazu nicht das Kommando vxassist mirror VolName, sondern vxassist snapstart VolName. Dadurch wird Platz alloziert, der Plex in das Volume eingebracht und mit den Daten des Volumes gefüllt. Während dieser Zeit befindet er sich im Zustand SNAPATT (Snap-Attach) und hat den Zustand WO (Write-Only; er kann nicht gelesen werden, da er noch keine sinnvollen Daten enthält). Nach Abschluß der Synchronisation bekommt der Plex den neuen Zustand SNAPDONE, bleibt aber WO, da dies VxVM einige Optimierungen erlaubt. Ist die Zeit für das Backup gekommen, legen wir die Applikation kurz still (Unmounten des Filesystems bzw. Umschalten der Datenbank in den Backup-Mode) und trennen den Spiegel ab. Dazu verwenden wir das Kommando vxassist snapshot VolName. Durch dieses Kommando wird irgendein Plex des Volumes, der den Zustand SNAPDONE hat, abgetrennt und ein eigenes Volume mit dem Namen SNAP-VolName daraus erzeugt. Dieses Volume können wir nun irgendwohin mounten (gern auch read-only) und in aller Ruhe eine Datensicherung davon ziehen. Ist diese beendet, wird das Volume wieder unmounted und anschließend mit vxassist snapback SNAP-VolName wieder mit dem Original synchronisiert (nicht vxassist

snapback VolName, denn von VolName könnten beliebig viele Snapshot existieren. Wir müssen daher angeben, welchen wir zurückholen wollen). Auch der umgekehrte Weg ist übrigens möglich: Sollte in der Zwischenzeit das Original fehlerhaft geworden sein, etwa durch einen unvorsichtigen Löschbefehl etc., so können wir – nach unmounten von Original und Snapshot – den Inhalt des Snapshot-Volumes wieder in das Original hineinschreiben. Das geht mit vxassist -o resyncfromreplica \ snapback SNAP-VolName Bis hierhin lässt sich die Funktionalität auch mit vxplex und vxmake-Befehlen nachbauen. Allerdings würde dies stets zu einer kompletten Resynchronisation führen. Die SnapshotSchnittstelle bietet hingegen die Möglichkeit, die Resynchronisation auf die geänderten Bereiche einzuschränken. Da hierfür separate Lizenzen erforderlich sind, werden die nötigen Datenstrukturen jedoch nicht per Default eingerichtet, sondern müssen manuell angelegt werden. Wieder gehen wir zunächst sukzessive durch alle Objekte und Verästelungen, um das Prinzip zu verstehen, und lernen dann abschließend zwei einfache Kommandos, um es auch benutzen zu können. Einfache Kommandos für komplizierte Sachverhalte sind ja nur dann von Vorteil, wenn man zuvor im Detail verstanden hat, was geschieht. Ansonsten sind sie eher gefährlich als nützlich.

Problemstellung l

Änderungen am abgespaltenen Snapshot bzw. am Originalspiegel müssen beim Wiederverbinden des Snapshots überschrieben werden. l Ohne Information über die geänderten Bereiche muss alles resynchronisiert werden.

11.4

11.4.1

Fast Mirror Resynchronisation Um nur die geänderten Bereiche eines abgetrennten Snapshots zu resynchronisieren, muss VxVM sich merken, welche Bereiche beschrieben wurden. Dafür haben wir im Kapitel über Logs bereits eine grundsätzlich geeignete

Datenstruktur kennengelernt: die DirtyRegion-Bitmap. In dieser repräsentiert ein einzelnes Bit einen relativ grossen Extent des Volumes. Wird das Volume dort beschrieben, so wird das Bit in der Bitmap gesetzt. Prinzipiell

99

11

SNAPSHOTS ist so etwas zur Optimierung der Resynchronisation auch nutzbar. Allerdings erst nach ein paar Änderungen. Erstens braucht die Bitmap einen neuen Namen. Es sind ja keine Dirty Regions mehr, sondern vielmehr Änderungen am Volume, also auf englisch Data Changes. Daher nennen wir diese Bitmap nicht Dirty Region Log, sondern Data Change Log. Zweitens dürfen die Bits in diesem Log nicht mehr nach erfolgreichem Abschluss des Schreibvorgangs auf Null zurückgesetzt werden, sondern sie müssen alle Schreibvorgänge akkumulieren. Während das Dirty Region Log nur für sogenannte In-Flight-Transactions eine Eins in der Bitmap stehen hat, muss in unserem Data Change Log eine Eins stehen für jeden Extent, in dem sich seit Abtrennen vom Original etwas geändert hat. Drittens brauchen wir, damit ein Snapshot auch read-write gemountet werden kann, auch auf dem Snapshot-Volume selbst eine solche Bitmap. Beim Resynchronisieren werden dann die beiden Bitmaps mit OR verknüpft und jene Extents, die mit den resultierenden 1-Bits korrespondieren, in der angegebenen Richtung überschrieben. Viertens, aber das ist hier nebensächlich und wird erst ausserhalb dieses Kurses wichtig, sollte die Granularität etwas feiner sein, damit nicht aufgrund relativ weniger Änderungen doch fast das gesamte Volume resynchronisiert werden muss. Aufgrund der Lizenzpolitik des Herstellers (es handelt sich um ein ehemals kostenpflichtiges Extra) müssen wir vor Abtrennen des Snapshots das Fast-Resync manuell einschalten: vxvol set fmr=on (oder fastresync=on) Beim Setzen dieses Flags prüft VxVM, ob sich im Volume ein persistentes Data Change Log befindet (dessen Erstellung wird unten besprochen). Ist dies nicht der Fall, so legt er in Memory ein Data Change Log an und benutzt dieses, und zwar so lange, bis wir fmr (fast mirror resync) wieder ausschalten. Natürlich ist diese Variante nicht dazu geeignet, Volumes an einen Backup-Host zu deportieren, denn das Data Change Log im Speicher kann nicht mit dem Volume mitwandern. Wollen wir eine persistente Bitmap auf Disk

100

anlegen, so müssen wir dies vor Anlegen des Snapshots tun, da die Anzahl Plexes für die Bitmap mit der Anzahl Snapshot-Plexes und Data-Plexes korreliert. Das Anlegen dieses Logs geschieht durch einen einfachen Befehl: vxassist addlog myvol logtype=dco Der Name DCO steht für Data Change Object, das ist ein kleines Volume, welches mit Original bzw. Snapshot verpointert ist und das Data Change Log enthält. Das Anlegen des DCO allein reicht aber noch nicht. Auch hier müssen wir das fmr-Flag explizit setzen: vxvol set fmr=on VolName Beim Setzen dieses Flags prüft VxVM wieder, ob sich im Volume ein persistentes Data Change Log befindet. Da dies nun der Fall ist, schaltet VxVM auf persistente Speicherung des Data Change Logs um. Ein so vorbereitetes Volume kann man nach dem Absnappen tatsächlich deportieren und anderswo bearbeiten. Nach dem Zurückimportieren müssen nur die Änderungen resynchronisiert werden. Natürlich geht das Ganze auch viel einfacher. Man erledigt bereits beim Anlegen des Volumes alle Vorbereitungen. Transient geht das so: vxassist make avol 1g \ layout=mirror fmr=on und persistent nur wenig aufwendiger: vxassist make avol 1g \ layout=mirror,log \ logtype=dco fmr=on Dann kann man sofort mit snapstart beginnen und wird mit kurzen Resynchronisierungszeite n belohnt. Übrigens ist ein DCO-Log nicht nur für Snapshots nützlich. Ein DCO ist ganz allgemein eine Bitmap, die Veränderungen an Plexes seit dem Disablen eines Plexes aus dem DCO-tragenden Volume festhält. Ob der Plex dem Volume entnommen und als Snapshot verwendet wurde, spielt keine Rolle. Wird ein Plex deswegen disabled, weil eine seiner Subdisks nicht mehr erreicht werden kann, so tritt das DCO-Logging ebenfalls in Kraft. Nach Reparatur des Fehlerzustandes auf dem Plex (Reaktivieren der Disk) werden anhand des DCO-Logs die seit dem Disablen geänderten

11

SNAPSHOTS Extents identifiziert und nur diese synchronisiert. Wird eine Disk durch eine neue ersetzt, wird natürlich der gesamte entsprechende Volume-Bereich DIRTY markiert. Ab Version 4.0 unterstützt VxVM DCO-Logs mit integriertem DRL, sodass nur noch ein Log für alle

Arten von schneller Resynchronisation notwendig ist. Die Erstellung solcher Logs fällt aber in denselben Themenkomplex wie Space Optimized Snapshot Volumes und wird daher hier nicht behandelt.

Verständnisfrage 11.1 Worin unterscheiden sich FMR und DRL?

11.5

Ablaufdiagramm Snapshot – Offline Original-Volume

Vorbereitung vxassist snapstart vxvol set fmr=on

vxassist snapwait

vxassist snapabort

Nein

Snapshot erwünscht?

Ja Snapshot Plex aufgelöst

DB in Backup Mode

Offline Processing vxassist snapshot

mount SNAP-VolName

DB in Online Mode

Daten, sichern, analysieren etc.

Weitere Snapshots?

umount SNAP-VolName

vxassist snapclear

Nein

Ja Snapshot Verbindung gekappt

vxassist snapback

11.5

101

11 11.6

SNAPSHOTS Offhost Processing l

Nach Abspalten des Snapshots wird der Snapshot deportiert und remote verwendet. Vorteil: aktiver Host wird entlastet, ein anderer Host macht die Arbeit (Backup etc.). l Aber: nicht Volumes können deportiert werden, sondern nur DiskGroups. l Problem: Snapshot ist in der gleichen DiskGroup wie Originalvolume. l Lösung: DiskGroup wird aufgespalten und später wieder mit Original–DG verschmolzen. l

11.6.1

Deportieren von Snapshots; Split und Join von DiskGroups Ein Snapshot-Volume an einen anderen Host zu deportieren ist leichter gesagt als getan. Schließlich ist das Volume Bestandteil derselben DiskGroup wie das Originalvolume, und dieses soll weiter online bleiben. Wir können daher nicht die DiskGroup, welche das Snapshot-Volume enthält, deportieren. Theoretisch ist es natürlich schon möglich, Disks zwischen DiskGroups hin und her zu schieben. Um die Daten nicht zu verlieren müsste sich dazu allerdings die Subdisks der fraglichen Disk und alle darauf aufbauenden Objekte (Plexes, Volumes, DRLs etc.) merken und anschließend löschen, damit die Disk aus der DiskGroup entfernt werden kann. Anschließend könnte man aus der Disk eine neue DiskGroup erstellen und die Volumes rekonstruieren (mit den Subdisks an denselben Stellen). Dadurch erhielte man eine neue DiskGroup mit denselben Volumes, die vorher auf der Disk lagen. Dieser Vorgang ist natürlich sehr komplex und fehlerträchtig und daher nicht zu empfehlen! Veritas bietet die Möglichkeit des VolumeExports in der separaten DGSJ-Lizenz an (Disk Group Split & Join). Damit erhält man einige neue Keywords für vxdg: split, join, move und listmove. Mit split kann eine DiskGroup aufgespalten werden. Dazu gibt man Quell-DG, die neue Ziel-DG und das Objekt an, welches bewegt werden soll: vxdg split FROMdg NEWdg SNAPVolName Dieser Befehl trennt das Volume aus der DiskGroup FROMdg in eine separate, neue DiskGroup TOdg ab. Diese können wir anschliessend deportieren und anderswo importieren, bearbeiten (Backup vom Volume ziehen). Nach Abschluss der Remote-Bearbeitung können wir sie dort wieder deportieren, auf dem Original-Host importieren und mit der original-DiskGroup verschmelzen:

102

11.6

vxdg join NEWdg FROMdg Vor dem Resynchronisieren müssen allerdings die Volumes der ehemaligen TOdg (diese DiskGroup existiert jetzt nicht mehr, sie ist in FROMdg aufgegangen) gestartet werden: vxvol -g FROMdg startall Nun wird der Snapshot wieder zeitsparend auf den Stand des Originals gebracht: vxassist snapback SNAP-VolName Es verbleibt eine mögliche Komplikation: Was, wenn auf den Disks, die das Snapshot-Volume belegt, noch Teile weiterer Volumes liegen? Dann kann die Disk nicht ohne weiteres in eine andere DiskGroup überführt werden, da sonst Volumes zerrissen würden. In diesem Fall kann man den DG-Split-Befehl instruieren, alles, was auf den zu trennenden Disks liegt, rekursiv mit abzutrennen. Es wandert dann nicht nur das Snapshot-Volume hinüber, sondern u.U. noch andere, unbeteiligte Volumes. Das will natürlich genau überlegt sein. Der Befehl lautet: vxdg -o expand split \ FROMdg NEWdg SNAP-VolName Um zu schauen, welche Objekte von der Aktion betroffen wären, kann man sich diese mit dem Keyword listmove zuvor ausgeben lassen: vxdg -o expand listmove \ FROMdg NEWdg SNAP-VolName Sind unerwünschte Volumes dabei, so kann man diese zunächst von den Disks des Snapshot-Volumes herunterbewegen: vxassist move volname \ !FROMdisk(s) TOdisk(s) Wie Sie sehen ist so ziemlich alles möglich. Für tiefere Informationen müssen wir Sie dennoch an die man-Pages verweisen; hier geht es nur um die Konzepte, nicht um die Details.

SNAPSHOTS

11

Aufspalten von DiskGroups

11.7

DiskGroup Split and Join l

Benötigt wird die Lizenz DGSJ (DiskGroup Split & Join) oder die Enterprise-Lizenz. vxdg split FROMdg NEWdg Objekt erzeugt aus den Disks, die zu dem angegebenen Objekt gehören, eine neue, importierte DiskGroup. l Anschliessend kann diese neue DiskGroup normal deportiert werden. l Subdisks weiterer, fremder Volumes auf einer split-Disk würden deren Volumes zerreissen lassen. In diesem Falle bricht das Kommando mit einer Fehlermeldung ab. l Die Option -o expand erlaubt rekursives Erweitern der split-Disks um diese Disks. l Vorher mit vxdg -o expand listmove prüfen, welche Objekte in die neue DiskGroup wandern würden. l Manchmal ist kein sinnvolles vxdg split möglich. Hier helfen die Kommandos vxevac und vxassist move weiter. l Bewegen zwischen bestehenden DiskGroups mit: vxdg move. l Verschmelzen von DiskGroups mit: vxdg join. l Nach vxdg join|move|split sind die Volumes, die bewegt wurden, gestoppt. l Starten dieser Volumes mit vxrecover -s oder vxvol startall. 11.7 l

Verständnisfrage 11.2 Wie könnte man eine Disk, auf der sich Volumes befinden, ohne Verlust der Daten in eine andere DiskGroup überführen, wenn man die DGSJ–Lizenz nicht besitzt?

103

11 11.8

SNAPSHOTS Ablaufdiagramm Snapshot – Offhost Vorbereitung vxassist snapstart

vxvol set fmr=off vxassist addlog volname \ logtype=dco vxvol set fmr=on

vxassist snapwait

vxassist snapabort

Nein

Snapshot erwünscht?

Ja DB in Backup Mode

Snapshot Plex aufgelöst

vxassist snapshot

DB in Online Mode

vxdg split

vxdg deport

Offhost Processing vxassist snapclear

Nein

Weitere Snapshots?

Ja Snapshot Verbindung gekappt

vxdg import

vxdg join

vxvol startall

vxassist snapback

11.8

104

SNAPSHOTS

11

Benutzung von Snapshots – Offhost

11.9

Offhost Processing (OHP) 1. vxvol set fmr=off ...........Sicherstellen, dass transientes FMR aus ist. 2. vxassist addlog logtype=dco ........... Datenstruktur für Änderungsbitmap (DCO) anlegen. 3. vxvol set fmr=on .............. FMR einschalten. Wegen DCO ist FMR jetzt persistent. 4. vxassist snapstart ......... Plex und DCO für Snapshot allozieren, synchronisieren. 5a. Applikation stillegen, also FS umount oder DB in Backup-Mode schalten. 5b. vxassist snapshot ........... Snapshot abtrennen und eigenes Volume daraus bilden. 5c. Applikation wieder starten, FS mount oder DB in Online Mode zurückschalten. 6. vxdg split............................... Snapshot Volume aus der DiskGroup in eine Export DiskGroup migrieren. 7. vxdg deport ............................Export DiskGroup deportieren. 8. DiskGroup auf anderem Host importieren, benutzen und wieder deportieren. 9. vxdg import ............................ Export DiskGroup nach OHP wieder importieren. 10. vxdg join .................................Export DiskGroup wieder mit alter verschmelzen. 11. vxvol startall....................Volumes aus Export DiskGroup starten. 12. vxassist snapback ...........Snapshot resynchronisieren. 11.9

105

11

SNAPSHOTS

Ü 11

Übungen: Snapshots mit und ohne FMR

Ü11.1

Snapshot allgemein 1. Legen Sie ein concat Volume mit zwei Plexes an, Grösse 512 MB. Messen Sie die Dauer. Anschliessend versehen Sie das Volume mit einem Filesystem und mounten es unter /mnt. 2. Synchronisieren Sie (mit Zeitmessung) einen Snapshot-Plex an dieses Volume. Halten Sie die „Applikation“ an (umount), erzeugen Sie das Snapshot-Volume und starten Sie wieder die „Applikation“ (mount). 3. Erzeugen Sie jetzt auf Ihrem Original-Volume mit mkfile eine Datei von 256 MB Grösse. Führen Sie jetzt den Snapback aus. Was ersehen Sie aus der Zeitangabe?

Ü11.2

Snapshot mit temporärem FMR 1. Löschen Sie die Datei wieder und schalten Sie temporäres FMR an. 2. Unmounten Sie das Filesystem, erzeugen Sie das Snapshot-Volume und mounten Sie das FS wieder. 3. Wiederholen Sie jetzt Schritt 3 aus der vorigen Übung und vergleichen Sie die Ergebnisse.

Ü11.3

Snapshot mit persistentem FMR (DCO-Log) 1. Die gleiche Prozedur soll jetzt für persistentes FMR mit einem DCO-Log-Volume durchgeführt werden. Orientieren Sie sich für das Anlegen des DCOs und Einschalten von FMR an dem Ablaufplan für „Offhost Processing“ 2 . Wiederholen Sie Schritt 2 der 2. Übung. 3. Um Offhost-Processing im 3. Schritt zu simulieren, splitten Sie das Snapshot-Volume in eine eigene DiskGroup, deportieren und re-importieren Sie diese und vereinigen Sie wieder beide DiskGroups.

Hinweis Sie können den FMR-Zustand der Volumes wie folgt abfragen: vxprint -v -F%name,%fastresync # -F = Fieldnames Diese und weitere Informationen erhalten Sie ausserdem mit dem Befehl: vxprint -l # -l = long Alle Informationen aus der Private Region liefert der Befehl: vxprint -rvm # -m = Makefile format Übrigens sind die meisten Feldnamen, die bei Ausgabe im Makefile-Format angezeigt werden, mit dem %-Operator für das Flag -F benutzbar. Probieren Sie es einfach einmal aus, es ist zur Script-Programmierung sehr nützlich.

106

SNAPSHOTS

11

Musterlösung

Ü 11

Snapshot allgemein

Log Ü11.1

1. time vxassist -g adg make avol 512m nmirror=2 [1m31.39s] mkfs -F vxfs /dev/vx/rdsk/adg/avol mount -F vxfs /dev/vx/dsk/adg/avol /mnt 2. time vxassist -g adg snapstart avol [0m56.11s] umount /mnt vxassist -g adg snapshot avol mount -F vxfs /dev/vx/dsk/adg/avol /mnt 3. mkfile 50m /mnt/file mount -F vxfs -o remount /dev/vx/dsk/adg/avol /mnt time vxassist -g adg snapback SNAP-avol [0m55.51s]

Snapshot mit temporärem FMR 1. rm /mnt/file vxvol -g adg set fmr=on avol 2. umount /mnt vxassist -g adg snapshot avol mount -F vxfs /dev/vx/dsk/adg/avol /mnt 3. mkfile 50m /mnt/file mount -F vxfs -o remount /dev/vx/dsk/adg/avol /mnt time vxassist -g adg snapback SNAP-avol [0m5.95s]

Snapshot mit persistentem FMR (DCO-Log) 1. rm /mnt/file vxvol -g adg set fmr=off avol vxplex –g adg convert state=ACTIVE snap-plex vxassist –g adg addlog avol logtype=dco vxvol -g adg set fmr=on avol vxplex –g adg convert state=SNAPDONE snap-plex 2. umount /mnt vxassist -g adg snapshot avol mount -F vxfs /dev/vx/dsk/adg/avol /mnt 3. mkfile 50m /mnt/file mount -F vxfs -o remount /dev/vx/dsk/adg/avol /mnt vxdg split adg offdg SNAP-avol vxdg deport offdg vxdg import offdg vxdg join offdg adg vxvol -g adg start SNAP-avol time vxassist -g adg snapback SNAP-avol [0m6.34s]

Log Ü11.2

Log Ü11.3

107

11 Ü 11

SNAPSHOTS Antworten zu Verständnisfragen Verständnisfrage 11.1 Worin unterscheiden sich DCO und DRL? In der DRL-Bitmap steht, in welchen Bereichen momentan Schreib-I/O stattfindet. In der DCO-Bitmap steht, in welchen Bereichen seit Abtrennen des Plexes Schreib-I/Os stattgefunden haben.

Verständnisfrage 11.2 Wie könnte man eine Disk, auf der sich Volumes befinden, ohne Verlust der Daten in eine andere DiskGroup überführen, wenn man die DGSJ–Lizenz nicht besitzt? Es ist jedenfalls nicht einfach und nur machbar, wenn auf der Disk möglichst nur ein Volume liegt und dies auch nur diese eine Disk belegt. Mit vxprint -rvm -g G VolumeName >descFile kann man zunächst die Konfiguration des Volumes abspeichern, dann das Volume löschen, die Disk mittels vxdg rmdisk aus der DiskGroup entnehmen und mit vxdg -g DG adddisk in die andere DiskGroup überführen. Dort kann man mit vxmake -d descFile die Volume-Information der Disk wieder auffrischen. vxassist -g adg make testvol 100m adg12 vxprint -rvm -g adg testvol >/tmp/desc vxedit -rf rm testvol vxdg rmdisk adg12 vxdg -g newdg adddisk adg12=c1t15d0 vxmake -g newdg -d /tmp/desc

108

KAPITEL 12

ROOT DISK SPIEGELUNG UND DER BOOT-PROZESS

12 12.1

ROOT DISK SPIEGELUNG UND BOOT–PROZESS Root-Disk unter Solaris Boot-Informationen l Eintrag 0 der VTOC zeigt auf

die /-Partition. l Am Beginn von Partition 0

(Sektoren 1-15) liegt der Boot-Code. l Weitere Einträge zeigen auf weitere Partitionen. l EEPROM findet über VTOC die /-Partition und darüber den Boot-Code. 12.1

12.2

Enkapsulierte Root-Disk Boot-Informationen l Zum Booten nötige Partitio-

nen bleiben erhalten. l Andere Partitionen (hier: /

home) werden aus der VTOC gelöscht. l VTOC wird um VxVM-eigene Partitionen erweitert (Public & Private Region). l In der Private Region werden die Boot-Partitionen zusätzlich als Volumes abgebildet. l Bei voller Disk wird die Private Region vom Ende der swap-Partition alloziert. 12.2

12.2.1

Encapsulation der Root-Disk Da mit VxVM keine Partitions, sondern nur Volumes gespiegelt werden können, muss zunächst die Root-Disk unter VxVM-Kontrolle gebracht werden. Würden wir dafür allerdings vxdisksetup verwenden, so würden unserere Partitionen durch diesen Vorgang gelöscht. Darüberhinaus würden durch die neu angelegte Private Region auch die Daten am Anfang der Disk überschrieben werden (die Private Region belegt normalerweise die ersten Zylinder der Disk). Die Disk würde also unbrauchbar

110

gemacht. Um dies zu vermeiden, muss die Disk stattdessen so in VxVM integriert werden, dass die Private Region keine belegten Bereiche überschreibt. Sie muss irgendwo auf der Disk in einen noch unbenutzten Bereich gelegt werden. Dafür – also für das Übernehmen bestehender Daten in VxVM – gibt es das Programm vxencap. Es dient zur sogenannten Enkapsulierung einer Disk. Das Kommando liest aus der VTOC alle Extents und sucht einen freien Bereich, der groß genug für die Private Region

ROOT DISK SPIEGELUNG UND BOOT–PROZESS ist. Hat vxencap diesen gefunden, so legt es die Private Region dort an und initialisiert sie. Anschließend erzeugt vxencap für jede gefundene Partition eine Subdisk. Beide Objekte – sowohl Partition als auch Subdisk - bilden denselben physischen Extent auf der Disk ab. Die Lokation des Extents und die darin befindlichen Daten selbst bleiben unverändert. Für jede Subdisk werden anschließend ein concat-Plex sowie ein Volume generiert und diese Objekte miteinander verbunden. Auch eventuell vorhandene Einträge in /etc/vfstab werden durch vxencap so umgestellt, dass sie auf Volumes statt auf Partitions zugreifen. Reine Datenpartitions werden anschließend aus der VTOC gelöscht, lediglich die zum Booten notwendigen Partition-Einträge bleiben erhalten. Da die Partitionen zum Zeitpunkt des vxencap gemountet sein könnten, bereitet der Befehl die oben erläuterten Aktionen jedoch lediglich vor. Beim nächsten Reboot werden sie dann durch die VxVM-Bootscripts zu einem Zeitpunkt durchgeführt, zu dem die Partitionen garantiert nicht gemountet sind. Für die RootDisk ist dieser Reboot unumgänglich, andere enkasulierte Disks mit User-Partitionen kann man natürlich auch einfach unmounten und die Reconfig-Scripts von VxVM manuell aufrufen. Der folgende Befehl die Disk c4t9d0 zur Enkapsuliereung als cdsdisk (cdsdisk ist Default) vor und fügt sie der DiskGroup adg unter dem Namen adg01 hinzu. Die DiskGroup adg muss dazu bereits existieren. Erst beim nächsten Aufruf des VxVM-rc-Scripts (manuell oder beim Booten) wird die VTOC tatsächlich aktualisiert. vxencap -g adg adg01=c4t9d0 Für die Root-Disk muss etwas anders vorgegangen werden, denn sie muss erstens das Format sliced haben, damit auch die BootPartitions in der VTOC stehen dürfen und nicht nur eine große Private Region. Dies erzwingen wir mit der Angabe „-f sliced“. Zweitens müssen wir beim Enkapsulieren gleichzeitig die Boot-Diskgroup erzeugen, da sie zu diesem Zeitpunkt normalerweise noch existiert. Dazu dient das Flag „-c“ (create). Der Befehl lautet also: vxencap -c -g osdg -f sliced \ bootdisk=c#t#d# Dieser Befehl bereitet die Root-Disk zum Enkapsulieren vor. Da dies die VTOC der Root-

12

Disk ändert und deren Partitions gemountet sind, kann die Änderung erst nach einem Reboot wirksam werden (s.o.). Manuelles Aufrufen des rc-Scripts funktioniert nicht, da man die root-Partitions nicht unmounten kann. Zusätzlich zu den Volumekonfigurationen nimmt das Enkapsulieren der Root-Disk noch Änderungen in /etc/vfstab und /etc/ system vor. In /etc/vfstab werden die PartitionMounts durch Volume-Mounts ersetzt (wie auch beim Enkapsulieren jeder anderen Disk). In /etc/system werden gegen Ende folgende zwei Zeilen eingetragen: rootdev:/pseudo/vxio@0:0 set vxio:vol_rootdev_is_volume=1 Die erste Zeile informiert den Solaris-Kernel darüber, dass auf das Root-Device nicht mehr über den Hardware-Pfad (pci@1f,800…/…) zuzugreifen ist, sondern über den vxio-Treiber. Die zweite Zeile sorgt dafür, dass der vxioTreiber im Speicher ein Pseudo-Volume für die Root-Partition erzeugt, damit der VolumeZugriff über den vxio-Treiber gelingt. Nach dem Reboot kann man weitere Targets zur neu erzeugten DiskGroup osdg hinzunehmen. Da eine bootbare Disk sliced formatiert sein muss (sie braucht die Partition Table für den Bootvorgang) initialisieren wir die RootMirrordisk in diesem Format. vxdisksetup -i c#t#d# \ format=sliced Anschliessend wird sie der osdg hinzugefügt: vxdg -g osdg adddisk \ bootmirr=c#t#d# Und schliesslich mit einem einzigen Kommando gespiegelt: vxmirror -g osdg bootdisk bootmirr Das Programm vxmirror ist ein von Veritas geliefertes Shell-Script, das alle für die RootSpiegelung nötigen Prozeduren beherrscht und die internen Befehle, die es dazu ausführt, auf das Terminal ausgibt. Nach Abschluss des Kommandos ist die RootDisk gespiegelt und bootbar. Sie kann ab sofort als Boot-Disk benutzt werden. Es spricht nichts dagegen, mit den von vxmirror als Kommentar ausgegebenen Befehlen zusätzliche Spiegel auf weiteren Disks anzulegen. Der Befehl vxmirror selbst erzeugt jedoch immer nur den ersten Bootspiegel.

111

12

ROOT DISK SPIEGELUNG UND BOOT–PROZESS Übrigens: Sie können – genügend Disks in der osdg vorausgesetzt – auch zu Root- oder Swapvolume einen Plex mit Stripe-Layout hinzufügen. Das geht ganz konventionell mit: vxassist -g osdg mirror rootvol \ layout=stripe Durch die default Read-Policy (select) wird

12.3

VxVM im Betrieb dann nur von diesem Plex lesen, da er über den höheren Stripefaktor verfügt. Natürlich benötigt man zum Booten immer noch mindestens eine Disk, auf der alle Bootvolumes im einfachen Layout vorliegen. Schliesslich kann das Boot-PROM noch keine Stripes verwenden.

Root-Disk Spiegelung l

Zunächst muss die Root Disk unter VxVM-Kontrolle gebracht werden. Dies geschieht durch Enkapsulieren mit dem Befehl vxencap mit anschließendem Reboot.

l

Enkapsulieren erzeugt Volumes aus Partitionen und löscht alle Partitionen, die nicht während des Bootvorgangs benötigt werden. /etc/vfstab und /etc/system werden angepasst.

l

Root-Disk Spiegelung ist danach durch den Befehl vxmirror sehr einfach.

l

vxmirror basiert auf normalen vxassist–Kommandos (Shell–Script).

l

Am Ende ruft vxmirror den Befehl vxbootsetup auf.

l

vxbootsetup erzeugt aus den Volumes, die zum Booten benötigt werden, Partitionen auf der Zieldisk und fügt devalias Komandos für die Spiegel in die EEPROM-Konfiguration ein. 12.3

Root-Disk Spiegelung im Detail Die Spiegelung einer Root–Disk muss hier einmal entzaubert werden. Häufig herrscht die falsche Vorstellung, Rootspiegel müssten Zylinder für Zylinder identisch mit der Originaldisk sein, weil sonst nicht von ihnen gebootet werden könnte. Andere meinen, die Root-Mirrordisk müsse eine enkapsulierte Disk sein. Beides ist definitiv nicht der Fall. Rootspiegel können sich völlig von ihrem Original unterscheiden, ohne dass dies zu irgendwelchen Problemen führen müsste. Bei allen Boot-Disks, egal ob „Original“ oder „Spiegel“ ist es lediglich wichtig, dass die Maschine zur richtigen Zeit an die richtigen Informationen gelangt, unabhängig davon, wo diese Informationen genau liegen. Diese fraglichen Informationen sind: Beginn und Größen des File Systems für /, /var, / usr und der Beginn des swap–Bereichs, also die Information über die Extents für die zum Booten wichtigen Partitions. Voraussetzung für einen erfolgreichen Bootvorgang ist, dass die Maschine zu jedem Zeitpunkt die adäquaten Datenstrukturen findet, die ihr den Weg zu den Filesystemen weisen. Für den frühen Bootvorgang sind dies die Partitionen, die in der VTOC eingetragen sind. Später, wenn die

112

Filesysteme endgültig gemountet werden, sind es die Volumes mit ihren Definitionen in der Private Region. Rootspiegelung durch das Kommando vxmirror unterscheidet sich von normaler Spiegelung durch vxassist mirror Befehle in folgender Hinsicht: a. Alle bootkritischen Volumes der zu spiegelnden Bootdisk werden auf die gleiche Ziel-Disk (den Root–Mirror) gespiegelt, und zwar zwingend als jeweils als ein einziger, zusammenhängende Extent. Eine Stückelung mehrer Subdisks ist hier nicht erlaubt, da dieselben Extents auch beim Bootvorgang (dann als Partitions aus der VTOC) verwendet werden, und dieser kann kein Mapping durchführen wie ein Plex dies tut. Das einzige „Mapping“, das im frühen Stadium des Bootens funktioniert, ist die lineare 1-zu-1 Abbildung. b. Im Anschluss an die Spiegelung werden die zum Booten notwendigen Extents (die Subdisks der Volumes für /, /var, /usr, swap) zusätzlich als Partitionen in der VTOC der Rootmirror–Disk verankert, und zwar mit ihren dort aktuellen Positionen. Diese

ROOT DISK SPIEGELUNG UND BOOT–PROZESS haben nichts mit den Positionen der Filesysteme auf dem Original zu tun! Wird vom Original gebootet, liest das Betriebssystem die Partition–Informationen von der VTOC der Originaldisk. Wird vom Spiegel gebootet, liest das Betriebssystem die Informationen von der VTOC des Rootmirrors, die selbstverständlich auch zum Layout der Rootmirror-Disk passen müssen. Letztlich ist vxmirror nur ein Shell-Script, das nach Prüfung der Vorbedingungen schlicht vxassist mirror für jedes Volume der Rootdisk aufruft und den Vorgang mit einem speziellen Kommando abschliesst: vxbootsetup. Dieses Kommando (erneut ein ShellScript) sorgt dafür, dass alle Root-Spiegel auch bootbar werden. Dazu ermittelt es für alle Bootvolumes (/, /var, /usr und swap) die Lokation der Subdisk, also des Extents, der die Daten enthält. Diese Extents, die selbstverständlich bei jedem Root-Spiegel woanders liegen können – trägt vxbootsetup in die VTOC der jeweiligen Disk als Partitions ein. Somit zeigen jetzt VTOC- und Volume-Strukturen auf identische Extents der jeweiligen Disk.

12

Das Kommando vxbootsetup hat gewissermassen das gleiche Ergebnis wie das Enkapsulieren der Root-Disk. Nach beiden Vorgängen zeigen sowohl Private Region als auch VTOC auf identische Extents dedr BootVolumes. Nur die Richtung der Synchronisation ist unterschiedlich: vxencap liest die VTOC und generiert Subdisks, vxbootsetup geht von den Subdisks aus und trägt in der VTOC entsprechende Partitionen ein. Zusätzlich zur reinen Anpassung der PartitionTable trägt vxbootsetup noch Aliases im Boot-PROM ein, damit die einzelnen BootSpiegel bequem adressiert werden können. Diese Aliases lauten wie die Disk-Mediennamen in VxVM, bekommen jedoch das Kürzel „vx-“ vorangestellt, um Konflikte mit eventuell bereits bestehenden Aliases zu vermeiden. Tragen beispielsweise Bootdisk und Bootmirror in VxVM die Namen bootdisk und osdg02, so werden die Aliases vx-bootdisk und vxosdg02 eingetragen. Man kann dann im BootPROM (am OK-Prompt) mit folgendem Befehl vom Mirror booten: OK> boot vx-osdg02

Verständnisfrage 12.1 Warum gibt es keine Probleme, wenn mal vom Original, mal vom Rootmirror gebootet wird? Warum laufen die beiden Mirror-Seiten dann nicht auseinander?

Hinweis Die hier beschriebenen Vorgänge und Prozeduren sind stark betriebssystemabhängig. Wir haben uns hier am verbreiteten Solaris 9 orientiert. Für andere Betriebssysteme gelten zwar die selben Prinzipien, aber unter Umständen andere Prozeduren.

Hinweis Beobachten Sie die Console-Meldungen während des Reboots nach einer Encapsulation der Root-Disk. Beim Starten werden zunächst die entsprechenden VxVM-Objekte über den Partitionen erzeugt, die Dateien /etc/system und /etc/vfstab und die VxVM-interne Statusinformation aktualisiert. Anschließend rebootet VxVM die Maschine erneut. Bei diesem zweiten Reboot werden nach der ersten Bootphase über die /-Partition die Mounts bereits als Volume-Mounts ausgeführt.

113

12 12.4

ROOT DISK SPIEGELUNG UND BOOT–PROZESS Boot-Vorgang bei Solaris 9 0. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.

12.4.1

Boot–Kommando erfolgt (automatisch/manuell). EEPROM ermittelt HW–Pfad (boot–device, devalias). EEPROM liest VTOC des Boot–Device, identifiziert Beginn der root-Partition. EEPROM liest den Boot-Code von Blocks 1-15 der root-Partition und führt ihn aus. Boot–Code liest File /platform/$(uname –m)/ufsboot und führt es aus. ufsboot liest boot.conf und startet /platform/$(uname –m)/ kernel/unix (hardwareabhängig) danach …/kernel/genunix (generisch). genunix mountet / (r/o), liest /etc/system & Kernel Treiber, initialisiert Treiber. genunix baut Pseudo–Context für ersten Prozess, lädt /sbin/init & Context Switch. /sbin/init liest /etc/inittab, startet alles bis default–Runlevel (3). /etc/rcS.d/S25vxvm–sysboot startet vxconfigd im boot–mode, holt bootdg. /etc/rcS.d/S35vxvm–startup1 startet alle bootdg–Volumes. /etc/rcS.d/S40standardmounts.sh re–mountet / read–write anhand der Information in /etc/vfstab. /etc/rcS.d/S85vxvm–startup2 setzt vxdctl enable, startet VxVM also vollständig.

Wie bootet Solaris von einem gespiegelten Volume? Wir müssen der Bootvorgang sukzessive durchgehen, um zu verstehen, an welchem Punkt das Betriebssystem welche Daten benötigt (VTOC bzw. VxVM). Die Erklärung enthält auch Teile, die für VxVM nicht relevant sind. Ein gutes Verständnis dessen, was beim Booten genau geschieht, ist jedoch so wichtig, dass hier die Gelegenheit ergriffen wird, dieses Wissen gleich mit zu übermitteln. 0. Zunächst erfolgt – wodurch auch immer – das Boot-Kommmando. Das kann entweder durch den User interaktiv geschehen oder dadurch, dass die Variable „autoboot?“ den Wert true hat. Das Boot-PROM ermittelt nun aus der Variablen bootdevice die Reihenfolge der Gerätenamen, von denen ein Bootversuch gestartet werden soll. Beschränken wir uns der Einfachheit halber auf nur ein Gerät. 1. Das Boot-PROM ermittelt für den in der Variablen hinterlegten Gerätenamen, ob es sich bei ihm um einen Hardwarepfad (beginnt mit /) oder um einen Device-Alias handelt. Ist es ein Device-Alias, so wird dieser durch Lookup in der Liste der DeviceAliases (Boot-PROM-Kommando devalias) aufgelöst. 2. Das Boot-PROM, spricht über den Hardwarepfad den in FCODE auf jedem Sun-kompatiblen Controller hinterlegten Mini-Device-

114

3.

4.

5.

6.

Treiber an und lässt ihn (bei Disks) den ersten Block des Geräts, also die VTOC, lesen. Aus dem gelesenen Block ermittelt es anhand der Tags (siehe Anhang) sowie der ExtentDaten in der Partition Table den Beginn der root-Partition (Diese trägt das Tag 2). Das Boot-PROM liest Block 1 bis 15 der root-Partition. Dort liegt der Boot-Code, der bereits UFS-Filesysteme lesen kann. Dieser Code wird anschliessend durch das Boot-PROM gestartet. Der Boot-Code liest wiederum den UFSBootloader, der in dem (fest eingetragenen) Pfad /platform/$(uname -m)/ufsboot liegt und startet ihn. Der Wert von uname -m ist maschinenabhängig. der UFS-Bootloader liest aus demselben Verzeichnis die Boot-Konfigurationsdatei boot.conf und startet den hardwareabhängigen Teil …/kernel/unix sowie den allgemeinen Teil des Solaris-Kernels, …/ kernel/genunix. Der nunmehr laufende Kernel gibt eine Versionsmeldung aus und mountet das Root-Filesystem. Auch dies geschieht noch über den vom Boot-PROM-Environment übergebenen Hardwarepfad. Er liest die Datei /etc/system und initialisiert seine Datenstrukturen entsprechend. Danach liest er die Default-Treiber sowie die mit

ROOT DISK SPIEGELUNG UND BOOT–PROZESS forceload in /etc/system angegebenen Treiber ein und ruft deren Initialisierungsfunktion auf (Zu diesem Zeitpunkt bleibt die „Dial“, der sich drehende ASCII-Cursor, meist für geraume Zeit stehen). 7. Der Kernel startet den einzigen Prozess, den er je starten wird, nämlich /sbin/init. Da es keine reguläre Möglichkeit zum Start eines Prozesses aus dem Kernel heraus gibt, muss er an dieser Stelle tricksen: er erstellt einen Stack-Frame, der aussieht wie ein normaler Prozesskontext, initialisiert diesen Kontext mit dem Binary von /sbin/init und passenden Werten für Programmzähler, Stackpointer etc., und führt einen Context-Switch in diesen Stack-Frame durch. Ab jetzt ist der Kernel nur noch passiver „Dienstleister“; init hat ab jetzt die Kontrolle über den weiteren Bootvorgang. 8. Das Programm init liest seine Konfigurationsdatei /etc/inittab, ermittelt daraus den Ziel-Runlevel und arbeitet mit Hilfe seiner eingebauten Logik die niederen Runlevel der Reihenfolge nach bis zum Ziel-Runlevel ab. Normalerweise sind dies die Runlevel S, dann 2 und schliesslich 3. Bereits in Runlevel S (Single-User) werden alle für VxVM wichtigen Start-Scripts ausgeführt. Dazu gehören folgende: 9. In /etc/rcS.d/S25VxVM-sysboot wird der Configuration Daemon (vxconfigd) im boot-mode gestartet und importiert die bootdg.

12

10. In /etc/rcS.d/S35VxVM-startup1 werden die Volumes der bootdg gestartet. 11. In /etc/rcS.d/S40standardmounts.sh wird das root-Filesystem anhand des Eintrags in /etc/vfstab vollständig (also readwrite) gemountet. Bis Punkt 10 einschliesslich waren nur die Partition-Einträge in der VTOC relevant, ab Punkt 11 nur die VxVMKonfiguration. Bis Punkt 10) wurde das Root-Filesystem über den Hardwarepfad angesprochen, ab Punkt 11) über den in / etc/vfstab hinterlegten Device-Treiber. Eine Disk muss also für alle Partitions, die bis Punkt 10 benutzt werden ( /, /usr, / var und swap), VTOC–Einträge haben, und für alle weiteren Filesysteme, die ab Punkt 11 gebraucht werden (die in / etc/vfstab eingetragen sind), die entsprechend geeigneten Strukturen. Sind in /etc/vfstab also Partitions eingetragen (/dev/dsk/…), dann müssen die Filesysteme auch als Partitions in der VTOC vorhanden sein. Sind in /etc/ vfstab hingegen Volumes eingetragen (/dev/vx/dsk/…), dann müssen die VxVM-Strukturen (Subdisk-Einträge und Plex-Mappings) in der Private Region vorhanden sein. 12.Im späteren Verlauf des Bootvorgangs wird der vxconfigd enabled, was ihm den vollständigen Funktionsumfang freischaltet, sodass auch die anderen DiskGroups importiert und deren Volumes gestartet und gemountet werden können.

Verständnisfrage 12.2 Wozu gibt es einen „boot-mode“ und weshalb wird der vxconfigd später separat „enabled“? Woher weiss der vxconfigd, welche der vielleicht zahlreichen „bootdg“-Disks im SAN für ihn bestimmt ist? Woher weiss der vxconfigd überhaupt, wie seine boot-DiskGroup heisst, sodass er sie beim Booten importieren kann?

115

12 12.5

ROOT DISK SPIEGELUNG UND BOOT–PROZESS Bereitstellen eines Not-Spiegels 1. Rootdisk spiegeln: vxmirror rootdisk rootmirr. Dabei wird durch das Kommando vxbootsetup die VTOC auf rootmirr automatisch an die Volumes angepasst. 2. Spiegel in VxVM verwerfen: vxassist remove mirror rootvol !rootmirr (und swapvol, opt, var, usr). 3. vxdg rmdisk des rootmirr durchführen, damit die Disk aus der Diskgroup entfernt wird. Anschliessend mit vxdiskunsetup die Private und Public Region aus der VTOC dieser Disk entfernen. 4. Root–Filesystem des Not-Spiegels mit fsck überprüfen und mounten, dort /etc/system und /etc/vfstab anpassen. Die anderen Filesysteme ebenfalls checken. 5. Not-Spiegel enthält jetzt bootbares System mit VxVM–Funktionalität.

12.5

Offline Spiegel zur Wartung Hat man den Bootvorgang mit VxVM und das Verfahren des Root-Disk-Spiegelung vollständig verstanden, so ergibt sich daraus eine Möglichkeit zur Bereitstellung eines „kalten“ Not–Spiegels, der für Wartungszwecke verwendet werden kann, etwa zum Vergrößern des Root-Filesystems (was online nicht möglich ist) oder für den Fall einer defekten VxVMInstallation (abgelaufene Lizenz, gelöschter Treiber, schlechter Patch etc.). Dazu wird zunächst einmal die Root-Disk auf eine ansonsten leere, mit dem Format sliced initialisierte Disk gespiegelt. Dies kannn entweder durch vxmirror oder durch äquivalente vxassist-Kommandos geschehen. In letzterem Fall dürfen wir nicht vergessen, abschließend vxbootsetup aufzurufen, um den neuen Spiegel durch Eintragen der Subdisks als Partitionen in die VTOC bootbar zu machen. Das vxmirror-Kommando tut dies natürlich bereits intern. Da wir diese Disk als Notspiegel auf PartitionBasis bereitstellen wollen, muss die Disk nun, da sie bootbar ist, wieder komplett aus VxVM herauskonfiguriert werden. Um die Disk aus der DiskGroup entnehmen zu können, müssen wir zunächst alle VxVM-Objekte von ihr entfernen. Daher löschen wir alle Plexes von der zusätzlichen Disk, und zwar entweder mit vxassist remove mirror !coldmirror oder mit vxplex -o rm dis plexname

116

Wir brauchen uns dabei keine Sorgen über die Daten auf diese Disk zu machen; das Löschen von Plex-Strukturen in der Volume-ManagerKonfiguration ändert selbstverständlich nichts an den Inhalten der Extents auf der Disk. Das Filesystem liegt nach wie vor auf denselben Disk-Blocks, und die Partitions zeigen nach wie vor auf diese Bereiche. Mehr braucht Solaris nicht während des frühen Bootvorgangs. Als nächstes entnehmen wir die Disk der DiskGroup: vxdg rmdisk coldmirror Anschliessend deinitialisieren wir die Disk für Volume Manager, indem wir das Gegenteil von vxdisksetup aufrufen, nämlich vxdiskunsetup c#t#d# Dieses Kommando entfernt die PartitionEinträge für Public und Private Region aus der VTOC, lässt aber alle anderen Einträge unverändert, insbesondere die zum Booten notwendigen Partitions für /, /var, /usr und swap. Wir besitzen nun eine Disk mit folgenden Eigenschaften: · Sie enthält alle zum Booten nötigen Filesysteme als Partitionen. · Diese Filesysteme sind, da sie „live“ abgetrennt wurden, als „dirty“ markiert und müssen vor dem ersten Mounten mit fsck überprüft werden. · Sie ist keine VxVM-Disk mehr. · Sie enthält eine komplett lauffähige VxVMKonfiguration. · In ihrem Root-Filesystem basieren die Einträge für die Mount-Points in etc/vfstab noch auf Volumes.

12

ROOT DISK SPIEGELUNG UND BOOT–PROZESS · In ihrem Root-Filesystem enthält etc/system noch die zwei Zeilen, die den Zugriff auf das Root-Device auf das Pseudo-Devce vxio umlenken. Um die Filesysteme mountbar zu machen, werden sie zunächst der Reihe nach mit fsck überprüft. Dieser Befehl gibt uns praktischerweise aus, an welches Directory die überprüfte Partition zuletzt gemountet war. Entsprechend müssen wir später die etc/vfstab im RootFilesystem des abgetrennten Spiegels ändern. Nach Abschluss der fsck-Läufe mounten wir das Root-Filesystem der behandelten Disk nach /mnt. Dort editieren wir etc/vfstab, indem wir die Device-Pfade von Volumes auf die für diese Disk gültigen Partitions umstellen. Wir verwenden dafür die Info, die uns

fsck zuvor ausgegeben hat. In /mnt/etc/system kommentieren wir mit einem Asterisk („*“) die beiden Zeilen aus, die das Root-Device als Volume definieren (s.o.): * rootdev:/pseudo/vxio@0:0 * set vxio:vol_rootdev_is_ volume=1 Nach dem Zurückschreiben der korrigierten Files und Unmounten von /mnt können wir von dieser Disk booten. Wir haben ein vollständiges Betriebssystem einschließlich Volume Manager und können nun Volume Manager dazu verwenden, die Filesysteme /, /var und /usr sowie das swapvol zu verändern (vergrößern, verschieben, den Inhalt reparieren etc.). Dies ist sonst aufgrund der Tatsache, dass diese Filesysteme nicht unmounted werden können, nicht möglich.

Wichtig! Alle Änderungen an Größe und Lokation der Boot-Volumes müssen so durchgeführt werden, dass nach Abschluss der Arbeiten die resultierenden Volumes folgende zum Booten notwendigen Eigenschaften behalten: · Sie liegen alle auf derselben Disk · Sie bestehen aus einer einzigen Subdisk Haben sich Größe und/oder Lokation der Boot-Volumes geändert, so muss ausserdem zwingend das Kommando vxbootsetup aufgerufen werden, um die VTOC mit den neuen Extents zu aktualisieren. Ansonsten kann von diesen Disks nicht gebootet werden!

Hinweis Die VTOC eines solchen Not-Spiegels enthält nur Einträge für /, swap, /var, /usr und /opt. Einträge für /home, /export usw. fehlen!

Befehlssammlung Kapitel 12

12.6

Befehle für Rootspiegelung vxencap DiskName ...................................... Bereitet Disk zum Enkapsulieren vor (bei Reboot). vxmirror rootdisk rootmirror... Erzeugt bootbaren Spiegel auf rootmirror. vxbootsetup ..................................................... .Schreibt Bootinformationen auf alle Rootspiegel. vxdiskunsetup DiskName .................... Löscht VTOC-Einträge für Private und Public Region. vxevac Source [Destination] ..... Bewegt alle Subdisks von Source weg [auf Destination]. vxassist move Volume !D1 D2 ........ Bewegt angegebenes Volume von D1 nach D2. 12.6

117

12

ROOT DISK SPIEGELUNG UND BOOT–PROZESS Antworten zu Verständnisfragen Verständnisfrage 12.1 Warum gibt es keine Probleme, wenn mal vom Original, mal vom Rootmirror gebootet wird? Warum laufen die beiden Mirror-Seiten dann nicht auseinander? Weil solange, wie auf die Partition zugegriffen wird und nicht auf das Volume, kein Schreibzugriff erfolgen kann (die Partition ist readonly gemountet) und somit die Mirror-Seiten nicht auseinander laufen können. Das Umschalten auf read-write (via /etc/vfstab-Eintrag) geschieht gemeinsam mit dem Umschalten auf Volume-Zugriff. Somit ist garantiert, dass alle Schreibzugriffe stets auf alle Plexes geleitet werden.

Verständnisfrage 12.2 Wozu gibt es einen „boot-mode“ und weshalb wird der vxconfigd später separat „enabled“? Für seine volle Funktionalität benötigt vxconfigd Schreibzugriff auf das /var-Filesystem, da er für jede importierte DiskGroup einen Eintrag in /var/vxvm/tempdb vornimmt. Bevor dieser Schreibzugriff jedoch erreicht werden kann, muss die bootdg importiert werden, damit das entsprechende Volume zur Verfügung steht. Wer aber importiert die bootdg? vxconfigd! Wir stehen also vor einem Henne-und-Ei Problem. Dieses Problem wird dadurch gelöst, dass die zum Importieren der bootdg nötige Funktionalität ohne Schreibzugriff auf das root-Filesystem auskommt und beim Booten zunächst dieser Modus gewählt wird. Nach dem Import der bootdg, Starten der Volumes und read-write Remount der Boot-Volumes wird der Modus umgeschaltet auf die volle Funktionalität, den sogenannten „Enable-Mode“. Dadurch werden unter anderem die Device-Bäume unter /dev/vx/dsk und /dev/vx/rdsk neu aufgebaut. Woher weiss der vxconfigd, welche der vielleicht zahlreichen „bootdg“-Disks im SAN für ihn bestimmt ist? Woher weiss der vxconfigd überhaupt, wie seine boot-DiskGroup heisst, sodass er sie beim Booten importieren kann? Die Datei /etc/vx/volboot enthält einige wichtige Einträge zum korrekten Start von VxVM. Unter anderem sind dies der Hostname (der beim Import in die Private Region der Disks geschrieben wird), der Name der bootdg und der Name der defaultdg. Anhand des dort gefundenen eigenen Namens sowie des Namens der bootdg kann er nun aus den angeschlossenen Disks die richtigen selektieren. Die Datei /etc/vx/volboot wird beim Installieren von VxVM angelegt und kann später durch vxdctl-Befehle verändert und ausgelesen werden.

Hinweis Ändern Sie niemals die Datei /etc/vx/volboot von Hand! Wenn man diese Datei genau anschaut fällt auf, dass sie exakt 512 Bytes lang ist. Sie wird aus historischen Gründen mit „#“-Zeichen auf einen vollen Diskblock aufgefüllt. Ist die Datei nicht völlig korrekt in Bezug auf Inhalt und Länge, so kann VxVM beim nächsten Booten nicht mehr starten, da es die bootdg nicht mehr identifizieren kann. Das bedeutet auch, dass Sie das /etc/vx/volboot-File nicht mehr korrigieren können (ausser Sie haben wie in diesem Kapitel beschrieben einen „kalten“ Spiegel abgetrennt)! Die richtige Methode, um /etc/vx/volboot auszulesen, lautet vxdctl list. Die korrekte Methode zum Rekonstruieren von /etc/vx/volboot stellt der Befehl vxdctl init dar.

118

KAPITEL 13

VXVM-ARCHITEKTUR

13 13.1

VXVM-ARCHITEKTUR Treiber- und Prozess-Struktur von VxVM

User Space

vxassist etc.

vxconfigd

vxrelocd vxrelocd

Applikation

Daten

vxnotify

konfiguriert

vxspec

Kernel Space

schreibt

vxio

liest Volume Mapping logische zu physische Adressbereiche etc.

Filesystem

liest

vxdmp

sd

sd

sd

fc

fc

fc

Disk 13.1

120

VXVM-ARCHITEKTUR

13

Kernel-Architektur von VxVM

13.1.1

VxVM benutzt 3 Kernel-Module: vxio für das Mapping zwischen virtuellem und physischem I/O, vxdmp für Dynamic Multipathing und vxspec zum Auslesen und Ändern der VxVMKonfigurationsdatenbank im Kernel. Die Treiber vxio und vxdmp kennen etliche konfigurierbare Kernel-Parameter über Einträge in vxio. conf und vxdmp.conf in /kernel/drv. Eine Liste verfügbarer Parameter zeigen die Man-Pages zu vxio und vxdmp. Der vxio-Treiber greift auf die MappingTabelle in der Konfigurationsdatenbank zurück, wenn er auf ein Volume zugreift, um für einen logischen I/O die entsprechenden physischen I/Os auf die richtigen Subdisks durchzuführen. Da UNIX auf dieser Ebene keine LockingMechanismen bereitstellt ist es für Applikationen nach wie vor möglich, auf die von VxVM benutzten Disks unter Umgehung von VxVM zuzugreifen (Blitz-Symbol). Dies ist aber normalerweise nicht zielführend und sollte unterbleiben. Ist dennoch einmal eine Disk an VxVM vorbei geändert worden (z.B. Partition Table geändert), oder haben sich Eigenschaften von Disks innerhalb des Betriebssystems geändert (z.B. Hinzufügen oder Wegnehmen von Pfaden oder Disks), so muss VxVM dies signalisiert werden. Dazu gibt es recht feinkörnig definierte Kommandos, um möglichst nur das allernötigste neu einzulesen. Diese Kommandos sind in den manPages von vxdisk und vxdctl nachzulesen. Im Allgemeinen reichen folgende drei Level aus: 1. vxdctl enable Der Name vxdctl steht für VxVM daemon control, enable ist der Modus, in den der vxconfigd gehen soll. Beim Booten startet vxconfigd im Boot-Mode und wird später während des Bootvorgangs auf enable gesetzt. Dies geschieht durch dasselbe Kommando. Das Enablen signalisiert dem vxconfigd (siehe Grafik), dass er über jeden vorhandenen DiskDeviceknoten versuchen soll das dazugehörige Device zu finden und in den DMP-Baum (s.u.) einzufügen. Dadurch werden z.B. neu hinzugekommene Disks gefunden, abgeschaltete Disks als verloren erkannnt und modifizierte VTOCs neu gelesen und interpretiert. Allerdings sind die Ergebnisse dieses Kommandos in gewissem Umfang versionsabhängig und variieren auch leicht mit der verwendeten Disk-Hardware.

2. vxconfigd -k (-k für kill) Dies killt und restartet den vxconfigd, was ihn dazu zwingt, ebenfalls die Disk-Deviceknoten neu zu scannen. Sollte das Enablen nicht den gewünschten Effekt haben, z.B. weil der vxconfigd hängt, sollte man dieses Kommando versuchen. 3. vxconfigd -k -r reset Dies ist ein relativ brutales Kommando, denn es deportiert und re-importiert alle DiskGroups. Dazwischen nullt es die Information, die vxspec im Kernel angelegt und für vxio und vxdmp zwischengespeichert hat. Dieses Kommando ist nur in Extremfällen nötig, z.B. wenn sich aufgrund eines Bugs DiskGroups nicht mehr deportieren lassen. Dynamic Multi Pathing (DMP) Die Grafik zeigt drei gleichberechtigte Wege zur selben, über SAN angeschlossenen Disk. Da die Disk über drei Fibre-Channel Controller erreicht werden kann existieren drei SCSI-Disk Devicefiles. Diese Devicepfade werden von DMP beim Zugriff reihum verwendet, wenn auf die Disk geschrieben oder von ihr gelesen werden soll. Wie wird dies erreicht? Das Verfahren ist erstaunlich einfach: Beim Enablen des vxconfigd liest dieser über jeden in /dev/dsk verfügbaren Diskpfad („Access Path“) die weltweit eindeutige SCSI-Kennung (WWID für World-Wide ID) der darüber erreichbaren Disk und merkt sich in einer Datenstruktur alle erreichbaren SCSI-WWIDs mit jeweils allen gefundenen SCSI-Pfaden. Alle Pfade, die zur selben WWID führen, werden zusammengefasst zu einem redundanten Zugriffsweg zu dieser WWID. Zugriffe von VxVM geschehen grundsätzlich über diesen redundanten Weg, d.h. reihum über alle Pfade, die diesem Weg angehören. Das Protokoll DMP liegt also oberhalb des SCSI-Treibers, im Gegensatz zu Solaris MPXIO, das unterhalb der SCSI-Treiberschicht liegt. Fällt einer der Pfade aus, was für DMP daran erkennbar ist, dass es vom darunterliegenden SCSI-Treiber einen „unrecoverable SCSI-error“ beim Zugriff über diesen Pfad zurückbekommt, so wird zunächst dieser Pfad temporär disabled. Es erscheint eine disebezügliche Fehlermeldung auf der Console (DMP disabled path xxx to dmpno-

121

13

VXVM-ARCHITEKTUR de yyy). Darüberhinaus wird er in eine Liste defekter Pfade einsortiert, deren Fehlerzustand regelmäßig (default: alle 5 Minuten) abgefragt wird. Findet DMP bei einer solchen Abfrage heraus, dass ein zuvor defekter Pfad wieder

13.2 13.2.1

aktiv wurde, wird dieser sofort reaktiviert. Zur Administration von DMP steht hauptsächlich das Kommando vxdmpadm zur Verfügung.

Notizen User-Architektur von VxVM Ausserhalb des Kernels benötigt VxVM im laufenden Betrieb zwingend keinen Prozess. Dennoch laufen standardmässig folgende Prozesse: l vxconfigd: die Schnittstelle für alle durch den User initiierten KonfigurationsÄnderungen, sei es durch GUI, CLI oder automatisch durch den Relocation-Daemon vxrelocd. l vxrelocd: sucht automatisch Ersatz für ausgefallene Subdisks und versendet bei Fehlern Mails (Mail-Empfänger als Parameter, konfiguriert in /etc/rc2.d/

S95vxvm-recover) vxnotify: konfigurierbare EventBenachrichtigung. Wird von vxrelocd benutzt, um ausgefallene Plexes sofort zu relozieren. Auch bei nicht laufendem vxconfigd können noch gewisse Konfigurationsänderungen stattfinden: Ausfälle jedweder Art werden automatisch durch die Kernel-Treiber persistent in den Private-Regions vermerkt und ändern den Health-Zustand von Subdisks, Plexes und Volumes.

l

SAN-Probleme und DMP Eines der Probleme mit SANs liegt in der Definition der UNIX-Treibertypen. Allgemein gesprochen unterscheidet der UNIX-Kernel zwischen „schnellen“ und „langsamen“ Devices. Die Device-Treiber sind entsprechend programmiert. Zu den „schnellen“ Devices gehören alle Geräte, von denen eine Antwort in sehr kurzer Zeit erwartet werden kann. Die Device-Treiber für diese Geräte erhalten einen niedrigen Interrupt-Level, können viele Kernel-Locks und sonstige Resourcen belegen und sind nicht unterbrechbar, während sie auf I/O warten. Zu den schnellen Devices gehören /dev/kmen, /dev/null und alle SCSI-Geräte, denn grundsätzlich sind SCSI-Geräte per Kabel direkt mit dem Host verbunden und antworten sofort. Zu den „langsamen“ Geräten gehören all jene, von denen die Antwortzeit nicht vorhergesagt werden kann. Zum Beispiel serielle Terminals, die per RS-232 angeschlossen sind, denn der UNIX-Kernel muss im Extremfall warten, bis der User seine Mittagspause beendet hat, bevor der Device-Treiber endlich seine Daten bekommt. Ein anderes Beispiel sind alle Arten

122

von Netzwerk, da hier die Antwortzeit durch Routenfindung, rebootende Komponenten und sonstige Komplikationen schwer berechenbar wird. Im Netzwerkbereich haben sich daher Timeouts in der Größenordnung einer Minute etabliert. Langsame Geräte erhalten einen hohen Interrupt-Level (wenn die Daten endlich da sind, sollen sie wenigstens auch gleich bearbeitet werden), belegen typischerweise wenige Kernel-Resourcen und sind, während sie auf I/O warten, unterbrechbar. Den Effekt, den es hat, wenn ein effektiv langsames Gerät über einen „schnellen“ DeviceTreiber angesprochen wird, hat jeder erlebt, der schon einmal versucht hat, einen RewindBefehl auf ein SCSI-Tapedrive abzubrechen. Der Device-Treiber ist nicht unterbrechbar (SCSI-Geräte sind „schnell“), aber durch die langsame Mechanik des Tape-Drives kann es Minuten dauern, bis das Band zurückgespult ist. In der Zwischenzeit schläft der Prozess, der das Tape angesprochen hat, nicht unterbrechbar im Kernel-Mode und belegt dort wertvolle Kernel-Resourcen (die man allerdings nicht

13

VXVM-ARCHITEKTUR leicht direkt beobachten kann - dafür fehlen uns die Diagnose-Tools). Wenn wir uns nun die Hierarchie der DeviceTreiber in der Grafik anschauen, stellen wir fest, dass sich mit der Einführung von SANs ein fataler Zustand etabliert hat: Geräte werden nach „oben“ hin als „schnelle“ SCSIDevices angeboten, sind tatsächlich jedoch als „langsame“ Netzwerk-Devices, nämlich über das Storage Area Network, erreichbar. Finden viele I/Os parallel auf diesen Geräten statt, und tauchen auch nur kleine Probleme im SAN auf, so kann sich wegen der dauerhaften Belegung der Kernel-Resourcen durch die SCSI-Treiber ein System nachhaltig verklemmen und somit minutenlang praktisch stehenbleiben.

In Cluster-Umgebungen gehört dies mit zum Schlimmsten, was passieren kann, da nach wenigen Sekunden das betroffene System für tot erklärt und übernommen wird. Taucht es dann nach ein, zwei Minuten doch wieder auf, ist höhere Clustertheorie nötig, um die Situation wieder unter Kontrolle zu bringen. Innerhalb von VxVM und UNIX beschränkt sich das Problem noch darauf (siehe Grafik), dass bei einer angenommenen Nicht-Erreichbarkeit der Disk (Grafik) die Kombination von (defaultmässig fünf) SCSI-Retries, dem einminütigen Timeout der FC-Verbindung und den drei vorhandenen Verbindungen zur Disk insgesamt fünfzehn Minuten verstreichen, bevor VxVM durch VxDMP benachrichtigt wird, dass eine Disk tatsächlich ausgefallen ist.

123

KAPITEL 14

KOMMANDO UND KONFIGURATIONSÜBERSICHT

14

KOMMANDO- UND KONFIGURATIONSÜBERSICHT Haftungsbeschränkung Die hier dargebotenen Informationen wurden mit der grössten Sorgfalt zusammengestellt. Natürlich kann trotzdem nicht ausgeschlossen werden, dass sich Fehler eingeschlichen haben. Eine Garantie auf Fehlerfreiheit kann nicht übernommen werden.

Interpretationshinweis Kursiv gesetzte Wörter müssen durch die der jeweiligen Konfiguration entsprechenden Werte ersetzt werden. Angaben in eckigen Klammern sind optional. Angaben in runden Klammern stellen Kommentare/Erklärungen dar.

14.1

Disks & Diskgroups AKTION

KOMMANDO

Diskgroup anlegen Diskgroups löschen Diskgroups importieren

vxdg init DG diskname=c#t#d# [diskname=c#t#d# ...] [cds=off] vxdg destroy DG [DG ...] vxdg import DG [DG ...] vxdiskadm Menüpunkt 8 Diskgroups deportieren vxdg deport DG [DG ...] vxdiskadm Menüpunkt 9 Diskgroups anzeigen vxprint [-qQ][a|l][g] DG [DG ...] Disks einer Diskgroup hinzufügen vxdg -g DG adddisk diskname=c#t#d# [diskname=c#t#d# ...] vxdiskadm Menüpunkt 1 Disks aus einer Diskgroup entfernen vxdg rmdisk diskname [diskname ...] Disks enkapsulieren vxencap options & arguments (Shell-Script) vxdiskadm Menüpunkt 2 Spare-Flag einer Disk togglen vxedit -g DG set spare={on|off} diskname [diskname ...] vxdiskadm Menüpunkt 12/13 Hot-Relocation auf Disks togglen vxedit -g DG set nohotuse={on|off} diskname [diskname ...] vxdiskadm Menüpunkt 15/16 Disks initialisieren vxdisksetup [-i] c#t#d# [privlen=ns] (bei mehr als ca. 3.000 VM-Objekten pro Diskgroup) Disks zum Ersetzen entfernen vxdg -g DG -k rmdisk diskname vxdiskadm Menüpunkt 4 Disks zum Ersetzen einfügen vxdg -g DG -k adddisk diskname=c#t#d# vxdiskadm Menüpunkt 5 Disk nach Reparatur einbinden vxreattach [-r] [c#t#d#] Relocatete Subdisks zurückbringen vxunreloc [diskname] vxdiskadm Menüpunkt 14 Disks umbenennen vxedit rename oldname newname Disks disablen (offline) vxdisk offline c#t#d# vxdiskadm Menüpunkt 11 Disks enablen (online) vxdisk online c#t#d# vxdiskadm Menüpunkt 10 Disks deinitialisieren vxdiskunsetup [-C] c#t#d# [c#t#d# ...] vxdiskadm Menüpunkt 3 Disks & Diskgroups anzeigen vxdisk [-g DG] [-s] [-o alldgs] list [diskname] Disks anzeigen vxprint [-qQ][a|l] diskname [diskname ...] freien Platz anzeigen vxdg [-g DG] free [diskname] Test für Diskgroup-Split/Move Diskgroup-Move Diskgroup-Split Diskgroup-Join Diskgroup Parameter ändern

vxdg vxdg vxdg vxdg

[-o expand] [-o expand] [-o expand] join src-dg

listmove src-dg dst-dg vol/disk-objects move src-dg dst-dg vol/disk-objects split src-dg dst-dg vol/disk-objects dst-dg

vxedit -g DG set {nlog|nconfig}={0-9|all|default} DG (nconfig/nlog: Anzahl der config/log-Datenbanken pro DiskGroup) Default-Diskgroup festlegen/löschen vxdctl defaultdg {DG|nodg} Boot-Diskgroup festlegen/löschen vxdctl bootdg {DG|nodg} Default-Diskgroup anzeigen vxdg defaultdg Boot-Diskgroup anzeigen vxdg bootdg

126

KOMMANDO- UND KONFIGURATIONSÜBERSICHT

14

Subdisks

14.2

AKTION

KOMMANDO

Subdisk anlegen

vxmake -g DG sd sd-name disk=diskname offset=offset[-kmg] len=length[-kmg] vxedit rename oldname newname vxsd [-o rm] mv oldname newname vxsd [-o rm] dis sd-name [sd-name ...] vxsd assoc plexname sd-name [sd-name ...] vxsd aslog plexname sd-name

Subdisk umbenennen Subdisk verschieben Subdisks aus Plex ausgliedern (dissociate) Subdisks einem Plex assoziieren Subdisk als Log-SD einem Plex assoziieren (nur für DRL) Subdisks löschen Subdisks anzeigen

vxedit rm sd-name [sd-name ...] vxprint -s[qQ][a|l] sd-name [sd-name ...]

14.3

Plexes AKTION

KOMMANDO

Plex concatenated anlegen Plex striped anlegen

vxmake -g DG plex plexname sd=sd-list vxmake -g DG plex plexname layout=stripe stwidth=stripeunit-width ncolumn=column-number sd=sd-list vxmake -g DG plex plexname layout=stripe stwidth=stripeunit-width ncolumn=column-number sd=sd-name:column/offset,... vxmake -g DG plex plexname layout=raid5 stwidth=stripeunit-width ncolumn=column-number sd=sd-list vxplex det plexname [plexname ...] vxplex att volname plexname [plexname ...]

Plex concatenated/striped anlegen Plex RAID5 anlegen Plexes im Volume abhängen (detach) Plexes im Volume einhängen (attach) (bewirkt Spiegelung) RADI 5 Log-Plex einhängen (Plex darf kein Log-only-Plex sein) Plexes aus Volume ausgliedern (dissociate) Plexes löschen [rekursiv, forced] Plexes anzeigen Datenplex zu Snapshot-Plex konvertieren Snapshot-Plex zu Datenplex konvertieren

vxplex att raid5volname logplexname vxplex dis plexname [plexname ...] vxedit [-rf] rm plexname [plexname ...] vxprint [-pqQ][a|l] plexname [plexname ...] vxplex –g dg convert state=ACTIVE plex vxplex –g dg convert state=SNAPDONE plex

14.4

Volumes AKTION

KOMMANDO

Volume simple anlegen Volume mirrored anlegen Volume RAID5 anlegen

vxmake -g DG -U [fs]gen vol vol-name plex=plexname vxmake -g DG -U [fs]gen vol vol-name plex=plexlist [fmr=on] vxmake -g DG -U raid5 vol vol-name plex=plexname[,logplexna me1,logplexname2] Volume erzeugen vxassist [-g DG] make vol-name length layout=layoutlist maximale Volume-Grösse errechnen vxassist [-g DG] maxsize layout=layoutlist [diskname ...] Volume-Eigentümer ändern vxedit -g DG set user=username group=groupname mode=octal vol-name [vol-name ...] Volumes starten vxvol start vol-name [vol-name ...] vxrecover –sE [vol-name ...] (ohne Argumente: alle enablen) vxvol init active vol-name Volumes stoppen vxvol stop vol-name [vol-name …] Volume mit Filesystem (hier ufs) versehen newfs /dev/vx/rdsk/DG/vol-name Volume mounten mount –F fstype /dev/vx/dsk/DG/vol-name mountpoint Mirror hinzufügen vxmake –g DG plex plexname sd=sd-list vxplex att vol-name plexname vxassist mirror vol-name Log-Plex hinzufügen vxassist -g DG addlog vol-name Volume- und FS-Grösse verändern vxresize –F fstype –g DG vol-name [+|-]size [diskname[,offset]] (ufs, vxfs; Verkleinern nur mit vxfs) Volume-Grösse verändern vxassist -g DG growto vol-name size

127

14

KOMMANDO- UND KONFIGURATIONSÜBERSICHT AKTION

KOMMANDO

(FS-Grösse wird nicht geändert)

vxassist -g DG growby vol-name diff vxassist -g DG shrinkto vol-name size vxassist -g DG shrinkby vol-name diffVolume konvertieren vxassist –g dgname convert vol-name layout=new-layout vxassist –g dgname relayout vol-name new-layout (evtl. Mirror-Plexes zuvor dissoziieren) vxedit [-rf] rm vol-name [vol-name …] vxprint [-vrqQ][a|l] volname [volname …] ls –ld /dev/vx/rdsk/DG/vol-name

(layered simple) Volume relayouten Volumes löschen [rekursiv, forced] Volumes anzeigen Volume-Eigentümer anzeigen

14.5

14.6

VxVM-Tasks AKTION

KOMMANDO

VxVM-Tasks anzeigen VxVM-Task abbrechen VxVM-Task anhalten VxVM-Task fortführen

vxtask vxtask vxtask vxtask

[-n] list abort task-id pause task-id resume task-id

Volume aufbauen Schritt für Schritt AKTION

KOMMANDO

Diskgroup anlegen Subdisk anlegen

vxdg init DG diskname=c#t#d#s2 vxmake –g DG sd sd-name disk=diskname offset=offset[-kmg] len=length[-kmg] Plex concatenated anlagen vxmake –g DG plex plexname sd=sd-list Volume simple anlagen vxmake –g DG –U [fs]gen vol vol-name plex=plexname Volume starten vxvol start vol-name Volume mit Filesystem (hier ufs) versehen newfs /dev/vx/rdsk/DG/vol-name Volume mounten mount –F fstype /dev/vx/dsk/DG/vol-name mountpoint

14.7

14.8

Volume abbauen Schritt für Schritt AKTION

KOMMANDO

Volume unmounten Volume stoppen Plex aus Volume ausgliedern (dissociate) Volume löschen Subdisk aus Plex ausgliedern (dissociate) Plex löschen Subdisk löschen Diskgroup löschen Schnellverfahren

umount mountpoint vxvol stop vol-name vxplex dis plexname vxedit rm vol-name vxsd dis sd-name vxedit rm plexname vxedit rm sd-list vxdg destroy DG vxedit –rf rm vol-name

Layered Volume manuell erzeugen AKTION

KOMMANDO

Subvolumes anlegen

vxassist –g DG make subvol-name size layout=mirror,log nmirror=m alloc=disklist vxedit –g DG set layered=on subvol-name [subvol-name …] vxmake –g DG sd sd-name disk=subvol-name offset=0 len=subvol-length vxmake -g DG plex plexname layout=stripe stwidth=stripeunit-width ncolumn=n sd=sd-list vxmake -g DG –U [fs]gen vol volname plex=plexname vxvol –g DG start vol-name vxassist –g DG make vol-name size layout=stripe-mirror,log nmirror=m ncolumn=n stripeunit=stripeunit-width alloc=disklist

Als Subvolumes markieren Als Subdisks übernehmen Plex aufbauen Volume aufbauen Volume starten Kurzfassung

128

KOMMANDO- UND KONFIGURATIONSÜBERSICHT

14

Boot-Disk enkapsulieren

14.9

AKTION

KOMMANDO

Boot-Disk enkapsulieren Rebooten (intern doppelter Reboot) Mirror-Disk anlegen Boot-Disk spiegeln

vxencap -c -g DG -f sliced rootdiskname=c#t#d# init 6 (o.ä.) vxdg –g DG adddisk rootmirrorname=c#t#d# vxmirror DG rootmirrorname

Boot-Disk-Enkapsulierung aufheben AKTION

KOMMANDO

Mirror-Plexes ausgliedern (dissociate) Mirror-Plexes und –Subdisks löschen Zusätzliche Disk in rootdg einfügen Enkapsulierung aufheben Rebooten

vxplex dis plexname [plexname …] vxedit –r rm plexname [plexname …] vxdg adddisk diskname=c#t#d# /etc/vx/bin/vxunroot init 6 (o.ä.)

14.11

Snapshot-Volume erzeugen AKTION

14.10

KOMMANDO

vxassist snapstart orig-volname Snapshot-Spiegel anlegen Snapshot erzeugen vxassist snapshot orig-volname snap-volname Backup-Volume mounten mount –F fstype –o ro /dev/vx/dsk/DG/snap-volname mountpoint Backup-Prozedur tar, ufsdump (o.ä.) umount mountpoint Backup-Volume unmounten Snapshot-Spiegel wieder in Volume einbinden vxassist snapback snap-volname Snapshot-Volume löschen vxedit -rf rm snap-volname

Konfiguration sichern und wiederherstellen AKTION

KOMMANDO

Gesamte Konfiguration sichern (inklusive Infos über Diskmedia und Diskgroup) Volume-Konfiguration einer Diskgroup sichern Konfiguration aus einer Konfigurationsdatei erzeugen Volumes starten

vxprint -mrA > config-file vxprint -mrvpsg DG > config-file vxmake -g DG -d config-file vxrecover -sE

14.13

Solaris VTOC Tags 0 1 2 3 4 5

........... ........... ........... ........... ........... ...........

unassigned boot root swap usr backup

14.12

6 ........... 7 ........... 8 ........... 9 ........... 14 ........ 15 ........

stand var home alternates [VxVM only] public region [VxVM only] private region

129

KAPITEL 15

GUI GRAPHICAL USER INTERFACE

15

GUI · GRAPHICAL USER INTERFACE

15.1

GUI-Übersicht

15.1.1

Prozess-Struktur Das Graphical User Interface besteht aus zwei Teilen: einem Frontend zur Darstellung und einem Serverprozess als Backend. Der Serverprozess heisst vxsvc und wird beim Booten durch das Run-Level-Script /etc/rc2.d/S50isisd gestartet. Das Frontend heisst vea (Veritas Enterprise Administrator) und kann auf einer beliebigen Maschine im Netzwerk gestartet werden. Es greift über einen Socket auf Port

Zentrales, dynamisches Aktionsmenü

Explorer-Leiste

2148 bzw. über das Socket-File /tmp/portal auf das Backend zu und kann alle über Sockets erreichbaren Backends verwalten. Das GUI wird als Package VRTSvea installiert. Es stellt auf der linken Seite in einer Explorerleiste die verwalteten Datentypen (Disks, Controller, Volumes, Systeme) und auf der rechten Seite die vorhandenen Objekte des links angewählten Datentyps dar.

Shortcuts

Informationen über die in der Explorer-Leiste selektierten Objekte

Warn- und Fehlermeldungen 15.1

132

GUI · GRAPHICAL USER INTERFACE

15

GUI-Menüstruktur

15.2

Ein rechter Mausklick auf einen Datentyp oder die Auswahl des „Action“-Menüs führt zu einem kontextsensitiven Menü, das die Aktionsmöglichkeiten für den entsprechenden

Datentyp anbietet. Der Übersicht halber sind die verschiedenen Versionen des Menüs für die wichtigsten Datentypen unten aufgeklappt dargestellt.

15.2.1

15.2

133

Die tolldreisten Abenteuer von

Folge 1

Raid Level 0 Concat

Raid Level 0 Stripe

134

KAPITEL 16

EINFÜHRUNG

16

EINFÜHRUNG Kursinhalt Stoff des Kurses l

Production Network

Apache

Server 1

SAN/SCSI

Apache

138

Server 2

Überblick über Clustering im Allgemeinen und VCS im Besonderen l Installation und Konfiguration von VCS l Starten und Stoppen des Clusters und Aufbau einer ersten ServiceGroup l Überblick über Architektur und Interna von VCS l Aufbau eines hochverfügbaren Apache-Servers l Vorstellung der gängigen ResourceTypes l Heartbeat im Detail l Cluster Maintenance l Fortgeschrittene ResourceTypes l I/O-Fencing

EINFÜHRUNG

16

Umfeld

16.1

Hochverfügbarkeit in Rechenzentren

Rechenzentrum (RZ)

Admin Server

Server 1

Client-Server l Zugriff über IP-Adresse der Maschine und Portnummer des Dienstes Remote Administration l Kein physischer Kontakt mit den Maschinen l Ausfälle nicht eindeutig feststellbar l Kommunikationskanäle: – Ethernet – Serielle Konsole (RS232) – Telefon (Clients)

Server 2 16.1

In Rechenzentrumsumgebungen wird meist auf andere Dinge Wert gelegt als in Büroumgebungen. Zuverlässigkeit geht vor Schnelligkeit, Wartbarkeit vor Kosten. Praktisch alle Zugriffe auf die Maschinen erfolgen remote, also über Netzwerke. Damit sind die Administratoren nicht bei den Maschinen vor Ort und müssen sich auf die Informationen verlassen, die über das Netzwerk geschickt werden.

Kann man bei einem Bürocomputer noch hören, wenn sich eine Disk dem Ausfall nähert, riechen, wenn ein Kabel qualmt oder sehen, wenn die LEDs ausgehen, so ist dies in Rechenzentrumsumgebungen nicht möglich. Ausfälle sind also prinzipiell nicht zuverlässig feststellbar, sondern es muss immer damit gerechnet werden, dass andere Gründe dafür verantwortlich sind, wenn ein Server nicht antwortet.

139

16 16.2

EINFÜHRUNG Problematik Problem:

Production Network NFS Apache

Oracle

Server 1

Server 2

SAN

Apache

NFS

l Ausfall eines Servers führt zu Ausfall aller dort befindlichen Dienste. l Verifikation des Ausfalls unzuverlässig oder langsam. l Alles was eine Maschine „sieht“ ist, ob Netzwerkpakete kommen oder nicht. l Umschalten benötigt qualifiziertes Personal. l Evtl. Neuverkabelung notwendig - mehrere Abteilungen involviert.

Oracle 16.2

16.2.1

140

Fällt ein Server aus, so sind die Dienste, die dieser Server anbietet, nicht mehr nutzbar. Versucht man die Verfügbarkeit der Dienste zu erhöhen, so trifft man auf zunehmend mehr Schwierigkeiten, je tiefer man in die Problematik eintaucht. Lassen Sie es uns gemeinsam versuchen: Die Daten und Programme könnten zwar zum Zwecke des Umschaltens über SAN mit einen anderem Server verbunden werden, aber die Konfiguration (IP-Adresse, Steuerdateien, Startup-Scripts, Verwaltung etc.) existiert normalerweise nur auf dem jetzt ausgefallenen Server und muß auf dem Ersatzgerät neu erstellt werden. Deshalb muß die gesamte Konfigurations-Historie einer Applikation dokumentiert oder automatisiert sein, sonst entspricht die Neuinstallation nicht mehr der ausgefallenen. Zum Umkonfigurieren muß während der gesamten Produktionszeit (meist

24/7) spezialisiertes Personal vorgehalten werden. Man kann die Umschaltung zwar durch paralleles Mitführen von Schattenservern (identisch konfiguriert und verkabelt, aber inaktiv) beschleunigen, jedoch muss jede Konfigurations-Änderung auf dem Schattenserver nachgezogen und getestet werden. Ausserdem muss zuverlässig verhindert werden, das beide Server gleichzeitig aktiv werden, weil irrtümlich ein vermeintlicher Ausfall festgestellt und auf den Schattenserver umgeschaltet wurde. Dieser Zustand wird als „SplitBrain“ bezeichnet und stellt den schlimmstmöglichen Fall dar, der im HA-Umfeld passieren kann. Denn dadurch würden die Filesysteme oder Tablespaces, die zu dem Dienst gehören, von beiden Servern gleichzeitig unkoordiniert beschrieben und dadurch korrumpiert. Das macht umfangreiche Nacharbeiten nötig, wie

16

EINFÜHRUNG Neuerzeugung der Filesysteme oder Tablespaces, Einspielen der letzten Datensicherung und Replay der Redo-Log-Dateien der Datenbank. Daher ist Split-Brain allgemein weit schlimmer als ein schlichter Ausfall eines Dienstes. Wenn schon menschliche Administratoren oft Schwierigkeiten bei der eindeutigen Feststellung eines Ausfalls haben, so ist dies natürlich für automatische Überwachungssoftware extrem schwer zu lösen. Ein Diensteausfall ist zwar schlimm; noch schlimmer ist jedoch die Korruption von Benutzerdaten durch gleichzeitige, unkoordinierte Zugriffe von mehreren Servern. Deshalb muss die Cluster-Software in Fehlersituationen besonders sicher und zuver-

lässig reagieren. Die Qualität dieser Überwachungs- und Entscheidungsfunktion ist ein sehr wichtiges Kriterium bei der Auswahl einer Clustertechnologie. Im allgemeinen gilt im HA-Umfeld die Devise: „Death before Corruption“. Dies bedeutet, dass sich im Zweifelsfall eine Maschine selbst abschaltet, wenn sie einen Split-Brain-Zustand nicht mit vollständiger Sicherheit ausschließen kann. Der Veritas Cluster Server bietet einige eindrucksvolle Möglichkeiten, den Dienst auch in Zweifelsfällen weiter online zu halten ohne die Datenkonsistenz zu gefährden. Wir werden bei der Besprechung des VCS-Heartbeats näher darauf eingehen.

Manuelle Umschaltung – Schritt 1

16.3 Manuelle Behandlung von Ausfällen l

Schaffung der Systemvoraussetzungen l Anbindung des Storage l Installation und Konfiguration der Software l Start der Software l Umleiten der Clients auf den neuen Server

Production Network NFS Apache Oracle

Server 1

SAN

Apache

NFS

Server 2

Oracle 16.3

141

16

EINFÜHRUNG

16.3.1

Der Versuch, Dienste eines Servers nach dessen Ausfall manuell umzuschalten, bringt einige Schwierigkeiten mit sich. Ein gutes Konfigurations-Management sowie fähige Administratoren vorausgesetzt, läßt sich zwar relativ schnell eine Software auf einem neuen Server installieren, konfigurieren und starten. Auch der verwendete Storage (persistenter Speicher im SAN) kann in modernen Umgebungen mit

16.4

Manuelle Umschaltung – Schritt 2 Bestandteile eines Service

überschaubarem Aufwand dem Ersatzserver zur Verfügung gestellt werden. Trotzdem bleiben erhebliche Probleme bestehen: l Identifikation der benötigten Ressourcen l Schaffung der systemseitigen Voraussetzungen l Umleiten der Zugriffe der Clients auf den neuen Server

Identifikation der Ressourcen l

Hardware Software Konfiguration Abhängigkeiten

Hardware – Disks – DiskGroups – Netzwerkschnittstellen l Software – Prozesse – Dateien l Konfiguration – IP-Adressen – Volumes – Mounts l Abhängigkeiten – Volumes von DiskGroups – Mounts von Volumes – Prozessstart von Mounts 16.4

16.4.1

142

Selbst bei einfach aufgebauten Diensten wird oft erst beim Wiederaufbau eines ausgefallenen Servers festgestellt, welche Ressourcen oder Systemvoraussetzungen nötig waren, um die auf dem Server befindlichen Dienste zur Verfügung zu stellen. Fallen Hardwareressourcen meist noch unmittelbar ins Auge, werden andere Voraussetzungen wie eine bestimmte Route auf einer IP-Adresse oder auch gemountete Filesysteme häufig vergessen. Auch die Abhängigkeiten der Ressourcen untereinander sind nicht immer unmittelbar klar. Durch die Komplexität ganzer Applikationshierarchien in vielen aktuellen Rechenzentrumsanwendungen ist jede Form von

manueller Rekonfiguration von vornherein zum Scheitern verdammt. Dort sind parallele Datenbanken mit hunderten von Volumes im Einsatz, die durch eine ganze Schicht von Middlewareprozessen die Daten an mehrere Applikationen liefern, welche ihre Ergebnisse wiederum über Java-Application-Server, WebServer und Load-Balancer dem Endbenutzer zur Verfügung stellen. Ein solches komplexes Netz von Ressourcen, Prozessen und Abhängigkeiten benötigt Wochen der Analyse, bevor es in einen Cluster integriert werden kann und die umfangreichen Funktions- und Failovertests vor der Inbetriebnahme besteht.

EINFÜHRUNG

16

Manuelle Umschaltung – Schritt 3

16.5 Systemseitige Voraussetzungen

Production Network

l

NFS

Apache

Oracle Server 1

SAN

Kompatibilität (CPU, OS) Dimensionierung (CPU, Memory) l Netzwerk (Routing) l Kernel (/etc/system) l Treiber (/kernel/drv/*.conf) l User (/etc/passwd, /etc/ group etc.) l Middleware (VxVM etc.) l Infrastruktur l

Server 2

16.5

Die systemseitigen Voraussetzungen sind vielfältiger Natur. Zunächst einmal muss die Ersatzmaschine binärkompatibel zur ausgefallenen Maschine sein (diese Einschränkung wird für das Nachfolgeprodukt von VCS, den Application Director, nicht mehr gelten!). Sie sollte außerdem über vergleichbare Leistung in Bezug auf CPU, Speicher und I/O verfügen und netzwerkseitig (sowohl in Bezug auf IP als auch in Bezug auf SAN) korrekt eingebunden sein. Die Kernelvariablen (z.B. shared Memory für Datenbanken) sowie die Parameter für Treiber (z.B. static LUN binding für SAN-Devices) müssen kompatibel sein. Eventuell von der Applikation benötigte User und Gruppen müssen eingetragen werden und die StorageVirtualisierung (Volume Manager, SDS etc.) muss kompatibel zu der des ausgefallenen Systems sein. Darüberhinaus muss die Infrastruktur des Rechenzentrums die beiden Maschinen

gleichwertig bedienen können. Dies gilt insbesondere für Dinge wie Load-Balancer, Firewalls, Queuemanager, Datensicherungssoftware und dergleichen.

16.5.1

Es können zahlreiche weitere Abhängigkeiten bestehen, die vom konkreten Fall abhängen. Hier ist das Know-How des Betreibers des Rechenzentrums bzw. der Applikation gefragt. Sucht man erst bei einem Ausfall nach den systemseitigen Voraussetzungen, ist es in praktisch alle nicht-trivialen Fällen zu spät. Denn einer defekten Maschine kann man nur noch wenig Information entlocken, und wenn Sie sich das komplexe Geflecht von Abhängigkeiten vor Augen führen, das heutige Applikationen mit sich bringen, wird die Ausweglosigkeit jedweder nachträglichen Rettungsversuche offensichtlich.

143

16 16.6

EINFÜHRUNG Umleiten der Clients Umleiten der Clients l

IP

17

.91

.3.

21

NFS Apache Oracle

Feste Zuordnung von Dienst zu Hostname bzw. IP-Adresse des Servers bindet Dienste an Server fest. l Bewegen eines Dienstes ohne Mitführen der IP-Adresse bedeutet Anpassung der Clients . l Virtuelle Interfaces ermöglichen Definition dienstespezifischer IP-Adressen.

16.6

16.6.1

144

Clients greifen im Client-Server-Computing über Netzwerke auf Dienste zu. Die Dienste sind auf bestimmten Servern installiert und in der Regel auch nur auf diesen lauffähig. Die Kommunikationsschnittstelle besteht aus der IP-Adresse des Servers und der Portnummer des Dienstes. Normalerweise läuft mehr als ein Dienst auf einem Server, sodass alle diese Dienste über die gleiche IP-Adresse erreicht werden. Fällt dieser Server aus und wird ein Ersatz in Betrieb genommen, so muss, zusätzlich zum Start der Dienste, die IP-Adresse auf den Ersatzrechner geschwenkt werden. Problematisch wird es aber in zwei Fällen: Zum einen der durch Ausfall oder Überlastung bedingte Umzug eines einzelnen Dienstes auf einen anderen Server, zum anderen der Umzug von Diensten auf einen bereits aktiven Server, dessen IP-Adresse also nicht einfach geändert werden kann. In diesen Fällen müssten alle

Clients umkonfiguriert werden, sodass sie den Dienst auf dem neuen Server finden. Ein eleganter Weg aus diesem Dilemma wird durch die Verwendung virtueller Interfaces und darauf basierender, diensteabhängiger IP-Adressen geebnet. Auf ein physisches Interface werden mehrere virtuelle Interfaces gelegt (z.B. mit ifconfig ce0 addif oder ifconfig ce0:1 plumb). Dies ermöglicht es, für jeden Dienst eine eigene IP-Adresse zu definieren. Natürlich muss diese wie bisher die Server-IP-Adressen auch im Name Service hinterlegt sein. Dann kann der Dienst für den Client transparent von einem Server auf einen anderen umziehen, denn die für das Routing entscheidende Information, die IP-Adresse, zieht mit um. Der Nachteil dieses Verfahrens, der Verbrauch zahlreicher IP-Adressen, wird in der Regel durch die Vorteile überkompensiert.

EINFÜHRUNG

16

Hinweise zur Terminologie Um Missverständnisse auszuschließen wollen wir hier ein wenig in die Terminologie von Veritas Cluster Server einführen. Cluster > Ein Zusammenschluss von mehreren Computern zu einem Hochverfügbarkeitsverbund Ressource > (deutsch) Ein allgemeines Element eines Computersystems oder seiner Infrastruktur. Beispiel: CPU, Memory, Swap Space, Netzwerkinterfaces, Disklaufwerke. Resource > (englisch) Eine Instanz eines definierten Typs, für den die Clustersoftware einen Steuerungs- und Überwachungsagenten besitzt. ResourceType > (englisch) Einer der oben genannten, vordefinierten Typen. Beispiele sind DiskGroup, Volume, Application, IP etc. Eine Analogie aus der objektorientierten Programmierung: „ResourceType verhält sich zu Resource wie Klasse zu Objekt.“ Agent > (englisch) Eine Sammlung von Programmen zur Steuerung und Überwachung von Resources eines bestimmten Typs, sowie die dazugehörige Interface-Definition, damit VCS den Agent ansprechen kann. Es gibt für jeden Resource Type einen Agent. Beispiele: DiskGroupAgent, VolumeAgent, Application Agent, IPAgent etc. Node > (englisch) Ein einzelnes Computersystem im Cluster. Dasselbe wie ein Server, Rechner, Computer etc., aber eben in Cluster-Terminologie. Client > (englisch) Ein Computer, der hochverfügbare Dienste in Anspruch nimmt. Onlining/Offlining Hochfahren bzw. Herunterfahren einer Resource, einer ServiceGroup oder eines Nodes. Dependency > (englisch) Eine Abhängigkeit zwischen zwei Resources, durch welche die Kausalität bei Failover-Situationen und die Reihenfolge des Offlining und Onlining definiert werden. ServiceGroup > (englisch) Eine Sammlung von Resources und Dependencies, die gemeinsam einen Dienst (Service) abbilden. Meist enthält eine ServiceGroup eine Resource vom Resource Type IP, über welche die Clients auf den Dienst zugreifen können. In anderen Clustern wird ein solches Konstrukt auch als „Logical Host“ bezeichnet. (private) Link > (englisch) Eine dedizierte Ethernet-Verbindung zwischen den Nodes, die (normalerweise ausschließlich) zur Kommunikation der Nodes untereinander dient und (normalerweise) nur von der HA-Software verwendet wird. Public Link (englisch) oder Link-lowpri > Eine zusätzliche Ethernet-Verbindung zwischen den Nodes, die an das Client-Netzwerk angeschlossen ist und nur bei Ausfall aller private Links zur Kommunikation der Nodes untereinander dient.

145

16 16.7

EINFÜHRUNG Automatische Umschaltung – Hot Spare Hot Spare (oder Active/Passive, Master/Slave) l

Production Network NFS Apache

Heartbeat

Oracle Server 1

Server 2

SAN

Apache

NFS

Überwachung des aktiven Servers (Master) durch einen Standby-Server (Slave) mittels Heartbeat l Bei Ausfall Übernahme des Masters und dessen IP durch den Slave Vorteile: l Kein 24/7 Personal nötig l Ressourcen vorab identifiziert; systemseitige Voraussetzungen vorab geschaffen Nachteile: l Automatische Ausfallerkennung sehr fehlerträchtig l Mechanismus zur Synchronisation der Konfiguration erforderlich

Oracle 16.7

16.7.1

146

Ein Hot Spare Setup, auch Master/Slave bzw. Active/Passive Cluster genannt, verhält sich im Allgemeinen wie folgt: Der Slave überwacht den Master mit Hilfe eines dedizierten Netzwerkinterfaces, des sogenannten Heartbeats, indem er regelmäßig kurze Pakete sendet, die der Master innerhalb einer bestimmten Zeit beantworten muß. Antwortet der Master nicht rechtzeitig, so deklariert der Slave ihn als ausgefallen und übernimmt die Dienste und die IP-Adresse des Masters. Zu den Diensten gehören in der Regel auch die Filesysteme, auf denen die zu den Diensten gehörenden Daten und Programme gespeichert sind. Problematisch ist hier, wie bei allen Clustertechnologien, daß der Ausfall des HeartbeatNetzwerks zu einer irrtümlichen Übernahme des Master führt. Dies endet damit, daß sowohl Master als auch Slave gleichzeitig aktiv sind. Dieser Zustand heißt „Split Brain“ und sein Auftreten stellt ein sehr großes Problem dar.

Denn das gleichzeitige Benutzen von Filesystemen durch mehrere Server endet in aller Regel mit irreparablen Schäden am Datenbestand. Dies wiederum bedeutet: Neuanlegen des Filesystems, Einspielen des Backups, Replay der Redo-Logs etc. Also großer Zeitverlust und evtl. auch permanenter Datenverlust. Ein weiteres interessantes Verhalten stellt bei Clustern der sogenannte „Dead-Man Switch“ dar. Darunter versteht man folgendes: Ist der Master so überlastet, dass er lange Zeit nicht mehr auf Heartbeat-Pakete antworten kann, so stellt er dies erst nach dem Ende der Überlastsituation fest. Er muss nun davon ausgehen, dass der Slave ihn selbst (den Master) für ausgefallen hält und übernommen hat. Damit befindet sich der Cluster in einem Split-Brain Zustand. Nun hat der Master keine andere Wahl, als sofort eine BetriebssystemPanic auszulösen, um diesen schnellstmöglich zu beenden.

EINFÜHRUNG

16

Automatische Umschaltung – Symmetrischer Cluster

16.8

Symmetrischer Cluster l

Production Network NFS Oracle

Server 1

Apache

Apache

Heartbeat

Server 2

SAN

NFS

Master und Slave teilen die Arbeit untereinander auf. l Notwendig: Überwachung einzelner Ressourcen statt ganzer Server l Ausfall einzelner Dienste kann durch Schwenk des Dienstes auf den anderen Server repariert werden l Einzelne Dienste müssen eigene IP-Adressen zugewiesen bekommen. Nachteile: l Immer noch 50% der Ressourcen ungenutzt, da Dimensionierung der Server auf den Ausfall ausgelegt sein muß

Oracle 16.8

Um die Nachteile eines Master/Slave-Systems zu umgehen, wurden symmetrische (Active/ Active) Cluster entwickelt. Die Dienste werden hier von den Servern abstrahiert. Beide Server sind aktiv, wobei ein Dienst jedoch nur auf einem Knoten zu einer Zeit aktiv ist. Dies wird durch einen Prozeß überwacht, der auf jedem Server permanent läuft und oft als HADaemon (had) bezeichnet wird. Beim Ausfall einer Resource (z.B. Prozeß, IPAdresse) teilt der HA-Daemon des betroffenen Servers dem HA-Daemon des anderen Servers diesen Umstand über den Heartbeat mit. In „Absprache“ der beiden HA-Daemons wird dann der zu der ausgefallenen Resource gehörige Dienst auf dem betroffenen Server kontrolliert heruntergefahren und auf dem anderen gestartet. Die ausgefallene Resource bleibt aber als defekt („Faulted“) markiert, bis sie von einem Administrator wieder als repariert markiert („Cleared“) wird. Die Summe aller

Resources, die zu einem Dienst gehören und die vom Cluster kontrolliert werden, heisst „ServiceGroup“ oder „Logical Host“. Für symmetrische Cluster werden neue Voraussetzungen nötig: 1. Aufteilung in Einzeldienste (ServiceGroups). Die Zusammengehörigkeit von Resources zu Diensten muß dem HA-Daemon bekannt sein, damit er gezielt genau all das, was einen Dienst ausmacht, schwenken kann. 2. Es muß für jede Resource Start- Stop- und Monitorfunktionen geben, die jeweils möglichst unter allen Umständen funktionieren (also einschließlich Wiederanlaufen einer Datenbank etc.) 3. Die einzelnen Dienste müssen eigene IPAdressen zugewiesen bekommen, da nur dann der Umzug eines Dienstes von einem Server auf einen anderen für die Clients transparent erfolgt.

16.8.1

147

16

EINFÜHRUNG Split-Brain: Kommen gar keine Heartbeat-Pakete mehr von der Gegenseite an, so übernimmt der dies feststellende Server sämtliche Dienste des anderen. Bei Ausfall des Heartbeat-Netzes gerät also auch ein symmetrischer Cluster in den Split-Brain-Zustand. Dies kann durch verschiedene, herstellerabhängige Methoden zu verhindern versucht werden, z.B. sogenannte Quorum-Devices oder redundante Heartbeat-Netze. In der Qualität der Split-Brain-Vermeidungsstrategien unterscheiden sich die marktüblichen Cluster teilweise erheblich. VCS ist hier technologisch führend.

16.9

Automatische Umschaltung: N-to-M Cluster N-to-M Cluster l

Viele Server, viele Dienste Ein einziger zusätzlicher Server sichert sämtliche anderen Server ab (vgl. RAID-5) l Lastverteilungsverfahren möglich l

Production Network

NFS Apache

Heartbeat

Oracle

Server 1

Server 2

Server 3

SAN

Apache

NFS

Oracle 16.9

16.9.1

148

Hier handelt es sich um eine Erweiterung der symmetrischen Cluster um die Möglichkeit, zusätzliche Server hinzuzunehmen und dadurch eine echte Kostenersparnis zu erreichen. Analog zu einem Volume mit RAID-5 Layout,

bei dem eine einzige zusätzliche Disk einen gesamten Stripe absichert, kann bei einem Nto-M Cluster eine grosse Menge Server mittels eines einzelnen zusätzlichen Servers abgesichert werden.

EINFÜHRUNG

16

Automatische Umschaltung: parallele Services

16.10

Oracle RAC l

Parallele Applikation Benutzt shared DiskGroups l Lock-Management durch Applikation l I/O-Fencing l

Production Network

Heartbeat

Oracle

Oracle

Serva

Server 2

Oracle

Server 3

SAN

Oracle 16.10

Der jüngste Fortschritt der Clustertechnologie besteht in der Verteilung desselben Dienstes auf mehrere Server. Der Dienst läuft also gleichzeitig auf mehreren Knoten. Der Fachbegriff dafür lautet „Parallele ServiceGroup“ im Gegensatz zu den sonst üblichen sogenannten „Failover ServiceGroups“. Ein typisches Beispiel ist ein Oracle RAC (Real Application Cluster). Weil es problematisch ist, wenn gemeinsam genutzte Ressourcen verwendet werden (insbesondere Disk-Ressourcen, also Filesysteme oder Raw-Devices), muß ein geeignetes LockManagement auf Applikationsebene vorhanden sein, um die gleichzeitigen Zugriffe zu koordinieren.

Clusterseitig muss bei Ausfall der Applikation auf einem Knoten durch hardwaremäßigen Eingriff verhindert werden, daß unkoordinierte Zugriffe auf die gemeinsamen Disks erfolgen. Dies geschieht bei VCS ab Version 4.0 durch sogenanntes I/O-Fencing, welches durch den Treiber vxfen implementiert wird. I/O-Fencing benutzt SCSI-3 PGR (Persistent Group Reservation), um auf Disk-Ebene Zugriffsrechte für einzelne Server zu vergeben und zu verwalten. Verlässt ein Server den Cluster (freiwillig oder durch einen Crash), so werden dessen Zugriffsrechte auf die Datendisk durch die verbleibenden Server gelöscht. Dadurch werden alle unkoordinierten Zugriffe physisch ausgeschlossen und so die Integrität der Daten garantiert.

16. 10.1

149

KAPITEL 17

ÜBERBLICK ÜBER VCS

17 17.1

ÜBERBLICK ÜBER VCS Komponenten des VCS-Clusters: Hardware Cluster-Hardware: Production Network

Server 1

SAN

l

Nodes (Server, Systeme). Heartbeat-Leitungen: – interne (link) – externe (link-lowpri) – Disk-basierte (gabdiskhb) l Shared Storage. l

Server 2

Storage 17.1

17.1.1

Hardwareseitig wird vom VCS-Cluster folgendes vorausgesetzt: l

Einer oder mehrere Nodes (Rechner) der gleichen Prozessorarchitektur (binärkompatibel). l Zwei dedizierte Verbindungen zwischen allen Nodes über eigene Ethernet-BroadcastDomains für das interne Heartbeating (HBNetz). Diese Domains werden im einfachsten Fall aus gekreuzten TP-Kabeln aufgebaut. Dies ist die bevorzugte Konstellation bei zwei Nodes, da einfache Kabel am wenigsten fehleranfällig sind. Werden mehr Nodes benötigt, so sollte jeweils ein Switch pro

152

HB-Link verwendet werden. Wie bei allen redundanten Komponenten muß auch beim Anschluss der Switches darauf geachtet werden, dass sie nicht an anderer Stelle von einem Single-Point-Of-Failure abhängig sind (z.B. gemeinsamer Stromkreis). l Gemeinsam nutzbare Massenspeicher (Shared Storage), möglichst mit redundanter Anbindung an die Nodes und idealerweise verwaltet über ein softwaremäßiges VolumeManagement (VxVM).

ÜBERBLICK ÜBER VCS

17

Komponenten des VCS-Clusters: Software

17.2 Cluster-Software: l

Heartbeat-Treiber HA-Daemon und hashadow l Agenten l HA-Befehle – Konfigurationsbefehle – HA-GUI – Statusmonitor l

17.2

Softwareseitig enthält der VCS Cluster folgende Komponenten: l

Kernel-Treiber für die Heartbeat-Kommunikation: LLT (Low Latency Transport) und GAB (Group Membership and Atomic Broadcast). Die durch den Heartbeat dargestellte Funktionalität nennt man auch Cluster-Monitor. l Die zentrale Steuerungssoftware, die Service Groups als Ganzes startet, stoppt und Failovers einleitet. Diese Software heißt HighAvailability-Daemon oder HA-Daemon und trägt in der Prozessliste den Namen had. l Den hashadow-Prozess. Dieser überwacht den HA-Daemon und startet ihn sofort neu, wenn dieser Prozess einmal terminieren sollte. l Mit dem HA-Daemon kommunizierende Agenten, die jeweils für einen bestimmten Typ von Resource zuständig sind und auf jedem Node alle für den Cluster konfigurierten Resourcen dieses Typs (z.B. Prozesse, Volumes, IP-Adressen etc.) starten, stoppen und überwachen. l HA-spezifische Befehle zur Konfiguration, Steuerung und Überwachung des Clusters l Eine grafische Benutzerschnittstelle zum

17.2.1

interaktiven Konfigurieren, Betreiben und Überwachen. l HA-spezifische Befehle zur Konfiguration, Steuerung und Überwachung des Clusters l HA-spezifische Befehle zur Konfiguration, Steuerung und Überwachung des Clusters Directories und Pfade: Zum Arbeiten mit dem VCS-Cluster sollte man sich folgende Directories merken (in Klammern stehen vorgeschlagene Namen für entsprechende Umgebungsvariablen): l /opt/VRTSvcs/bin ($VCSBIN) - Die Befehle und Agenten. Dieses Directory sollte dem $PATH hinzugefügt werden, ebenso wie /sbin, wo die Befehle für die HeartbeatKonfiguration liegen. l /etc/VRTSvcs/conf/config ($VCSCONF) Die Konfiguration des HA-Daemons, ResourceTypes und ServiceGroups l /var/VRTSvcs/log ($VCSLOG) - Die Logfiles, insbesondere das zentrale, replizierte Logfile engine_A.log.

153

17 17.3

ÜBERBLICK ÜBER VCS Komponenten des VCS-Clusters: Konfiguration Cluster-Konfiguration: l

LLT – schnelles Basisprotokoll – kompatible Konfiguration – /etc/llttab – /etc/llthosts – $VCSCONF/sysname l GAB – Maschinenüberwachung – Nachrichtenübermittlung – /etc/gabtab l HA-Daemon – Resources – Service Groups – Dependencies – etc … – $VCSCONF/main.cf

17.3

17.3.1

154

Der VCS-Cluster kann nur dann regulär arbeiten, wenn die Systeme über Ethernet-Leitungen miteinander kommunizieren können. Daher wird als Kommunikationsbasis für den Cluster zunächst das Heartbeat-Netzwerk aufgebaut. Durch das besondere Design des VCS-Heartbeats können darauf basierende Applikationen sozusagen global als verteilte Applikationen arbeiten (sie verteilen Variablenwerte über das HB-Netz auf alle Nodes). Der HA-Daemon ist nur eine von vielen möglichen Applikationen, die den Heartbeat nutzen können. Für den VCS-Heartbeat werden zwei Pakete installiert, VRTSllt (LLT-Treiber) als schnelles Transportprotokoll und VRTSgab (GAB-Treiber) für die transaktionsorientierte Nachrichtenübermittlung. Konfiguration von LLT: l Die Dateien /etc/llttab, /etc/llthosts und evtl. /etc/VRTSvcs/conf/sysname konfigurieren den LLT-Treiber. In der /etc/ llttab werden die für den Heartbeat benutzten Ethernet-Devices sowie die eigene Cluster- und Node-ID definiert. Gestartet wird das LLT-Protokoll beim Booten mit dem Befehl /sbin/lltconfig -c.

Konfiguration von GAB: In der Datei /etc/gabtab stehen Konfigurationsbefehle für den GAB-Treiber. Daher wird diese Datei nicht vom GAB-Treiber eingelesen, sondern beim Bootvorgang einfach ausgeführt (sh /etc/gabtab). l Der HA-Daemon erhält Informationen darüber, welche Systeme, Service Groups und Resourcen zu überwachen sind, über das HB-Netz. Initialisiert („seeded“) wird diese Information aus /etc/VRTSvcs/conf/config/main.cf des ersten Cluster-Systems, das startet. Von diesem aus verteilt es sich beim JOIN weiterer Systeme auf diese, sodass die Konfiguration stets auf allen Servern identisch ist. Abweichende main.cf Dateien werden beim Start des Systems sofort aktualisiert. Die Installationsprozedur von VCS nimmt bereits Standard-Einträge für alle Konfigurationen vor, sodass der Cluster nach Installation automatisch läuft. Er überwacht allerdings noch keine Resourcen, sondern stellt zunächst nur den Zustand der anderen Systeme fest. Konkrete zu überwachende Resources muss man dem Cluster erst definieren, bevor er sie überwacht. Darauf wird im weiteren Verlauf des Kurses näher eingegangen. l

KAPITEL 18

INSTALLATION UND KONFIGURATION

18 18.1

INSTALLATION UND KONFIGURATION Konfiguration des Heartbeat-Netzes LLT und GAB l

Maschinennamen Cluster-Name – beliebig, alphanumerisch – keine Leerzeichen l Cluster-ID – Integer von 0 … 255 – Im Netzwerk eindeutig l Node-IDs – Integer von 0 … 31 – automatisch erzeugt – beginnt bei 0 – niedrigste ID hat höchste Priorität l Links – interne (link) – externe (link-lowpri) l

18.1

18.1.1

156

Die Installations beginnt durch Aufruf eines Scripts, das auf dem Distributionsmedium liegt. Je nach Paketierung heisst es installvcs, installer oder ähnlich. Während der Installation müssen einige Fragen beantwortet werden. Hier ein kurzer Überblick über die abgefragten Daten: l Systemnamen: Die Namen der Maschinen, auf die die Software installiert werden soll. Voraussetzung zur automatischen Installation ist eine Umgebung, in der ohne Passworteingabe mittels rsh oder ssh auf jeden Host gewechselt werden kann. In einer Umgebung, in der auf die Passworteingabe nicht verzichtet werden kann, funktioniert die Installation nur sehr mühsam, weil das Passwort ständig wieder eingegeben werden muss. l Cluster-Name: Der logische Name, den dieser Cluster tragen soll. Er hat keine Bedeutung für die Software und dient nur dem Überblick für den Administrator. Die Software orientiert sich ausschliesslich an der Cluster-ID. l Cluster-ID: Eine Zahl zwischen 0 und 255 (Default 0). Diese ID ist in jedem LLT-Paket enthalten und trennt so mehrere Cluster, die identische Netzwerkhardware verwenden. Wählen Sie auf jeden Fall eine eindeutige

ID. Am besten ist es, wenn die Cluster-IDs ebenso unternehmensweit eindeutig vergeben werden wie IP-Adressen. Wenn mehrere Cluster Pakete mit identischen Cluster- und Node-IDs voneinander empfangen, so rufen diese Maschinen panic() auf. Die Definition der Cluster-ID wird durch das Installationsprogramm in die Datei /etc/llttab eingetragen mit der Direktive: set-cluster Cluster-ID. l Node-ID: Jeder Node erhält eine eindeutige ID zwischen 0 und 31, die ihn auf dem Cluster repräsentiert. Die IDs werden durch die Installation automatisch, beginnend bei 0, erzeugt und brauchen nicht geändert zu werden. Zum Debugging ist es hilfreich zu wissen, dass die jeweils niedrigste Node-ID die höchste Priorität besitzt. Die Definition der Node-ID wird durch das Installationsprogramm in die Datei /etc/llttab eingetragen mit der Direktive: setnode Systemname. In der Datei /etc/ llthosts befindet sich die Zuordnung zwischen Node-IDs und Maschinennamen, sodass die Maschinen per Namen angesprochen werden können. Diese Datei ist auf allen Maschinen gleich.

18

INSTALLATION UND KONFIGURATION l

Links: Die Interfaces für das Heartbeat-Netz. Es werden zwei link-Interfaces abgefragt, danach ein link-lowpri. Dieser läuft mit der halben Frequenz (1 Paket pro Sekunde statt 2) und überträgt keine Konfiguration. Er ist für für eine Anbindung über das Public-Netz gedacht. Fallen alle norma-

len Links aus, so wird der link-lowpri zum vollen Link befördert. Es können für jede Maschine unterschiedliche Interfaces angegeben werden. Die Links müssen sich alle in getrennten Broadcast-Domains befinden, da es sonst durch doppelten Paketempfang zu LLT-Fehlern kommt.

18.2

Konfiguration des VCS-Clusters VCS l

Parameter für ClusterService-SG l Parameter für Notifier l Parameter für Benutzerverwaltung l Pfade – /opt/VRTSvcs/bin – /etc/VRTSvcs/conf/ config – /var/VRTSvcs/log 18.2

Im weiteren Verlauf der Installation werden noch Parameter für die ServiceGroup ClusterService, die Notifier-Resource und die Benutzerverwaltung abgefragt. Dazu einige Erläuterungen: l ClusterService: Eine ServiceGroup, die VCS zwingend voraussetzt, wenn er als Global Cluster eingerichtet ist. In diesem Fall enthält die Gruppe zusätzliche Resources, die Daten aller lokalen Cluster sammeln und mit der Remote-Seite austauschen. Aus diesem Grund ist die ServiceGroup so eingerichtet, dass sie sich nur schwer stoppen oder faulten lässt. Für den Normalbetrieb stellt die ClusterService-Group einen kleinen TomcatWebserver bereit, über den der Clusterzustand per http abgerufen werden kann. Für den Kurs ist der ClusterService wegen seiner vielen Besonderheiten eher störend und sollte nicht installiert werden. l Notifier: Eine Resource, die zum Senden von eMail bzw. SNMP-Traps bei bestimmten Ereignissen konfiguriert werden kann. Auch diese Resource sollte im Kurs nicht benutzt werden. Ihre Funktionalität lässt sich durch den hatrigger-Mechanismus viel universeller darstellen. Beantworten Sie daher

die Fragen nach Konfiguration von SMTP und SNMP negativ. l Benutzerverwaltung: Per Default legt das Installationsprogramm einen Benutzer namens admin mit dem Passwort password an. Weitere Benutzer können während der Installation oder jederzeit später per Kommando angelegt werden. Nach Eingabe aller Parameter beginnt die Installation, wahlweise parallel oder sequentiell auf allen Servern. Dabei werden auch Patchstände sowie zuvor installierte Pakete berücksichtigt, sodass mit dem Installationsprogramm auch Updates und Upgrades ausgeführt werden können. Am Ende der Installation kann man wählen, die Clustersoftware direkt zu starten. Die notwendigen Dateien /etc/llttab, /etc/ llthosts, /etc/gabtab und /etc/ VRTSvcs/conf/config/main.cf liegen durch die Installation bereits vor; das Heartbeating ist bereits durch die Kommandos lltconfig -c (LLT) bzw. gabconfig -c -n2 (GAB) aktiviert worden. Wählt man den Start, so wird auf jedem Knoten der HADaemon mit hastart gestartet.

18.2.1

157

18 18.3

INSTALLATION UND KONFIGURATION Starten, Stoppen und Überwachen von VCS Clusterbefehle l

Starten – hastart l Stoppen – hastop -local – hastop -all – hastop -sys system – hastop -force – hastop -evacuate l Überwachen – hastatus [-sum]

18.3

18.3.1

158

Die Befehle zum Prüfen von HeartbeatConnectivity und Clusterzugehörigkeit sind: l lltstat -vvn liefert den Status der hardwaremässigen Verbindung der Systeme. Es gibt zahlreiche weitere Parameter, die aber normalerweise nicht von Interesse sind. l gabconfig -a liefert den Status der Clusterzugehörigkeit der Systeme, d.h. ob sich die Systeme auf GAB sehen oder nicht und wenn ja, auf welchen Ports. Der „Running State“ von VCS wird mit den Befehlen hastart, hastop und hastatus kontrolliert. Eine Übersicht über die möglichen Varianten finden Sie im Bild oben. Normalerweise sind alle ha-Befehle clusterweit verwendbar. Die eine Gruppe von Befehlen bezieht sich auf Resources, ServiceGroups etc., also Konfiguration, die ohnehin auf allen Rechnern verteilt vorliegt. Die andere Gruppe akzeptiert den Parameter -sys, dem ein Systemname folgt. Dadurch wird das Kommando auf dem angegebenen Server ausgeführt. Beispiel dafür ist das Kommando hastop, mit dem die Clustersoftware auf dem genannten Server, dem eigenen Server (-local) oder allen zugleich (-all) heruntergefahren werden kann. Die Optionen zu hastop teilen sich in zwei Gruppen. Die erste Gruppe adressiert den oder die betroffenen Server und ist nicht optional, d.h. einer der Parameter muss angegeben

werden: -local — Fährt VCS auf dem System herunter, auf dem das Kommando abgesetzt wurde. l -sys system — Fährt VCS auf dem angegebenen System herunter. l -all — Fährt VCS auf allen Servern herunter. Die zweite Gruppe von Parametern kontrolliert die Art des Herunterfahrens und ist optional: l -evacuate — Nimmt alle ServiceGroups auf dem angegebenen System OFFLINE und woanders ONLINE. Beim Herunterfahren des Systems wird im installierten init-Script VCS durch hastop -local -evacuate gestoppt. l -force — Stoppt, ohne ServiceGroups zuvor herunterzufahren, lässt also die Dienste weiterlaufen, wenngleich ohne Clusterkontrolle. VCS ist so programmiert, dass es alle Dienste beim Starten auch im laufenden Betrieb wieder übernimmt. Wird keine Option aus dieser Gruppe angegeben, so werden standardmäßig alle Dienste auf dem angegebenen System OFFLINE genommen und bleiben OFFLINE. l

Das Kommando hastart kann nur lokal ausgeführt werden. da vor Ausführung von hastart auf einer möglichen Empfängerseite

INSTALLATION UND KONFIGURATION noch kein ha-Prozess läuft, der den Befehl entgegennehmen könnte. Der Befehl hastatus liefert einen permanent mitlaufenden Überblick über den aktuel-

18

len Clusterstatus. Das Kommando terminiert nicht von selbst. Eine Kurzübersicht, die von selbst terminiert, kann man mit hastatus -sum erreichen.

159

KAPITEL 19

AUFBAU EINER EINFACHEN SERVICEGROUP

19 19.1

AUFBAU EINER EINFACHEN SERVICEGROUP Einführung in das GUI GUI l

$VCS_HOME/bin/ hagui l JAVA-basiert l Verbindung zu had l Zentrales GUI für alle über IP erreichbaren Cluster l Möglichst nicht auf Server installieren

Aufteilung l

Menüzeile Toolbar l Explorer-Leiste mit Tabs – ServiceGroups – Systems – ResourceTypes l Detail-Window mit Tabs – „Resources“ am besten – … diverse andere … l

19.1

19.1.1

162

Das Frontend-Programm hagui kann mehrere Cluster gleichzeitig verwalten. Wegen immer noch vorhandener Mängel des Java Runtime Environment unter Solaris (MemoryLeak) sollte es nicht auf produktiven Servern eingesetzt werden. Besser ist die lokale Installation auf einer Monitoring-Workstation oder einem sonstigen System, das nicht durch kritische Wartungsfenster eingeschränkt ist. Im hagui muss zunächst ein neuer Cluster eingerichtet werden (File->New Cluster). Hierdurch wird ein bestehender Cluster dem GUI bekannt gemacht. Man trägt Namen und IP-Adresse in den Dialog ein und bekommt ein Login-Fenster, in dem man sich mit dem durch die Installation per default angelegten User (Login: admin | Password: password) dem Cluster gegenüber authentifiziert. Dadurch öffnet sich zunächst ein kleines Fenster, in dem man den Datentransport vom Cluster zum hagui beobachten kann. Nach Übertragung aller Daten wird der Cluster in einem eigenen, grossen Fenster dargestellt (siehe oben). Das Fenster besteht aus mehreren Haupt-Elementen: l Menüzeile: Die Menüzeile bietet globale Aktionen ebenso an wie kontextabhängige.

Meist wird man jedoch stattdessen das Kontext-Menü mit der rechten Maustaste wählen, da dann genau die für das selektierte Objekt möglichen Aktionen angeboten werden. l Toolbar: Die Toolbar enthält einige Symbole für schnellen Zugriff auf häufig benutzte Funktionen, z.B. Speichern und Schliessen der Konfiguration, Öffnen des ClusterLogs oder Anlegen von Resources und ServiceGroups. l Explorer-Leiste: Die Explorerleiste ganz links bietet drei Tabs (Reiter) an: ServiceGroups, Systeme und ResourceTypes. Üblicherweise hat man den ServiceGroupsTab selektiert, da man dort sowohl Resourceals auch ResourceType- als auch ServiceGroup-spezifische Aktionen durchführen kann. Wenn Sie den Reiter „ResourceTypes“ (ganz rechts) selektiert haben, sollten Sie zunächst nichts ändern, da sonst schnell die Clusterdefinitionen korrumpiert werden könnten! l Detail-Window: Dieses Sub-Window besitzt eine variable Anzahl Tabs. Ist in der ExplorerLeiste der Systems-Tabs selektiert, so kann man hier z.B. den Heartbeat-Status ansehen.

19

AUFBAU EINER EINFACHEN SERVICEGROUP Steht der Explorer-Tab auf ServiceGroups, so bietet sich der „Resources“-Tab für den besten Überblick und Zugriff an. Auf tiefgehende Erklärungen zum GUI möchten wir an dieser Stelle verzichten. Man sollte davon ausgehen können, dass ein Administrator hochverfügbarer Systeme ein GUI nicht erklärt zu bekommen braucht. Aber ein Hinweis noch:

Wenn Sie im GUI ein neues Objekt anlegen, können Sie in dem sich öffnenden Dialog durch Anklicken der Checkbox „Show Commands“ die Ausgabe der Kommandozeilen erhalten, durch die das Objekt im CLI erzeugt werden kann. Außerdem ist das GUI ein gutes Tool zur Gewinnung einer Übersicht über die komplexen Resource-Abhängigkeiten.

19.2

Öffnen und Schliessen der Konfiguration Konfiguration öffnen und schliessen l

Cluster schützt Konfiguration Zustand immer global l Vor Änderungen öffnen haconf -makerw (toucht $VRTSCONF/.stale) l zwischendurch dumpen haconf -dump l Am Ende schliessen haconf -dump -makero l Wenn .stale, dann keine automatische Initialisierung l Initialisierung erzwingen hasys -force sysname l Nötig nach Cluster-Restart mit hastop -all -force l

19.2

Konfigurationsänderungen Der VCS-Cluster schützt seine Konfiguration (normalerweise die Dateien main.cf und types.cf im Verzeichnis /etc/ VRTSvcs/conf/config) vor versehentlichen Änderungen und bietet elementare Undo-Möglichkeiten für Konfigurationsänderungen. Dies ist wie folgt implementiert: Bevor die Konfiguration geändert werden kann, muss sie zunächst geöffnet werden. Dies geschieht mit dem Befehl haconf -makerw (make Read-Write). Erst danach können Objekte wie ServiceGroups oder Resources angelegt, geändert oder gelöscht werden. Soll ein Zwischenstand in das Filesystem geschrieben werden, so geschieht die mit dem Befehl haconf -dump. Diese Konfiguration kann fortan wie ein Checkpoint benutzt

werden, denn alle jemals geschriebenen Konfigurationen werden von VCS versioniert und aufgehoben. Jede Konfiguration trägt als Extension den Zeitstempel des Moments, zu dem der Dump-Befehl abgesetzt wurde. Die aktuelle Konfiguration ist zusätzlich unter der Extension .cf, die Vorgängerversion unter der Extension .previous erreichbar (Hardlinks). Um die Konfiguration zu schliessen wird der Befehl haconf -dump -makero benutzt (make Read-Only). Implementation Wie findet der Cluster beim Starten heraus, ob die Konfiguration geöffnet war oder sauber geschlossen wurde? Das Öffnen der Konfiguration wird auf jedem Cluster-System nicht nur in Memory vermerkt, sondern es wird auch die leere Datei $VRTSCONF/.

19.2.1

163

19

AUFBAU EINER EINFACHEN SERVICEGROUP stale (/etc/VRTSvcs/conf/config/.stale) auf jedem Knoten angelegt. Das Vorhandensein dieser Datei bedeutet, dass die Konfiguration geöffnet ist. Beim Schliessen der Konfiguraton wird die Datei auf allen

19.3

Cluster-Systemen wieder entfernt. Auf diese Weise wird auch über die Laufzeit des Clusters hinaus festgehalten, ob die Konfiguration geschlossen wurde oder zuletzt noch geöffnet war.

Die hochverfügbare Xclock Mini-ServiceGroup l

Einzelne Resource ResourceType Process l PathName /usr/openwin/bin/xclock l Arguments -display unix:0 l X-Server freischalten (xhost +) l Zum Aktivieren muss die Resource Enabled werden l Ab dann zyklisches Monitoring (Probing) der Resource im Online- und Offlinezustand! l Ändern von ResourceType Attributen ändert Verhalten (MonitorInterval, 19.3 RestartLimit) l

19.3.1

164

Um einen einfachen Dienst unter Clusterkontrolle zu nehmen, bedienen wir uns des vorinstallierten und äusserst einfachen Programms xclock. Mit diesem Beispieldienst lassen sich sehr einfach die grundlegenden Eigenschaften einer ServiceGroup demonstrieren, z.B. Failover, Switch, Resource Fault, Resource Clear, Restart etc. In dem Kasten auf der rechten Seite finden sich die Befehle und Erläuterungen zu dieser einfachen ServiceGroup sowie Hinweise, wie sie im GUI angelegt werden kann. Der Trainer führt Ihnen dies vor. Nachdem die ServiceGroup mit der XclockResource erstellt wurde, wird die ServiceGroup versuchsweise auf beiden Systemen nacheinander ONLINE genommen. Um ResourceFaults zu erzeugen und das Verhalten des Clusters und die Darstellung der Zustände im GUI zu beobachten wird die Resource gestoppt (durch pkill xclock oder durch Schliessen des Fensters). Zunächst muss ein Container geschaffen wer-

den, in dem eine geeignete Resource für die xclock angelegt werden kann. Dieser Container ist die ServiceGroup. Sie wird entweder im GUI durch „New Service Group“ erzeugt oder auf der Kommandozeile mit dem Befehl hagrp -add XclockSG. Im GUI lässt sich jetzt sehr einfach die Liste der Systeme festlegen, auf denen diese ServiceGroup lauffähig ist und ebenso einfach die Systeme, auf denen diese ServiceGroup automatisch starten können darf. Auf der Kommandozeile werden diese Attribute der ServiceGroup mit jeweils einem Befehl gesetzt. Die Befehle lauten: hagrp -modify XclockSG \ SystemList sys1 0 sys2 1 und hagrp -modify AutoStartList \ sys0 sys1 Das Attribut SystemList enthält eine Liste von Key-Value-Paaren, welche sowohl die Systeme als auch deren Priorisierung festlegt (niedrigere Zahl gleich höhere Priorität.

AUFBAU EINER EINFACHEN SERVICEGROUP Das Attribut AutoStartList enthält eine Liste von Systemen, die in /etc/llthosts eingetragen sind, also zum Cluster gehören. Diese werden nicht priorisiert. Als nächster Schritt muss eine Resource, zur Kontrolle des Xclock-Prozesses in diese ServiceGroup hineinkonfiguriert werden. Aus der Liste der möglichen ResourceTypes kann man schnell ermitteln, dass es eine geeig-

19

nete ResourceType gibt, nämlich Process. Im GUI wählt man also „Add Resource“ und sucht im folgenden Dialog die ResourceType Process aus, gibt einen Namen ein und füllt die Parameter aus. Hier kann man mit einem Haken auf „Enabled“ auch gleich die Resource einschalten. Die Kommandozeile wird im Übungsteil ausführlicher besprochen.

19.4

Online, Offline, Switch, Failover Aktionen auf der SG l Online: Alle Resources der SG werden in der Reihenfolge ihrer Anhängigkeit onlined · hagrp -online XclockSG -sys sys0 l Offline: Alle Resources der SG werden in der Reihenfolge ihrer Anhängigkeit offlined · hagrp -offline XclockSG -sys sys0 l Switch: Die SG wird auf dem aktiven System offlined und auf dem neuen System onlined · hagrp -switch XclockSG -to sys1 l Fault: Alle von der defekten Resource abhängigen Resources werden offlined. Ist eine der betroffenen Resources CRITICAL, dann wird die SG woanders onlined (wenn möglich). · pkill xclock 19.4 Um ein Gefühl für Verhalten einer ServiceGroup zu bekommen, nehmen wir sie kontrolliert auf bestimmten Systemen online bzw. offline. Dies geschieht mit den Befehlen hagrp -online bzw. hagrp -offline. Beide Befehle bekommen noch den Service Group-Namen sowie das Zielsystem als Parameter von -sys übergeben. Beim Switch, also dem manuell initiierten Übernehmen eines Dienstes durch einen anderen Host, heisst das Kommande hagrp -switch und das Zielsystem wird statt mit -sys mit -to angegeben. Erzeugt man einen ResourceFault, also einen unerwarteten OFFLINE-Zustand einer Resource, so nimmt had die von der defekten Resource abhängigen Resourcen von oben beginnend OFFLINE. Ist bei einer der durch den Fault OFFLINE gekommenen Resourcen

das Attribut Critical gesetzt (Critical 1), so wird nun die gesamte SG OFFLINE genommen und, wenn möglich, auf einem anderen System ONLINE genommen. Das genaue Verhalten lässt sich in weiten Bereichen steuern und ist Gegenstand späterer Betrachtungen. Interessant ist, dass die Resource nicht in dem Mo- ment des Ausfalls als FAULTED erkannt wird, sondern erst geraume Zeit später. Das liegt daran, dass der zuständige Agent aus Performancegründen nicht ständig überwacht, sondern per Default nur alle 60 Sekunden. Dieser Wert — die dazugehörige Variable heisst MonitorInterval — lässt sich ebenso wie viele weitere relevante Variablen leicht auf eigene Bedürfnisse anpassen, sodass die Steuerung des Clusterverhaltens einfach anzupassen ist.

19.4.1

165

19

AUFBAU EINER EINFACHEN SERVICEGROUP

19.4.2

Bei einigen ResourceTypes ist es durchaus sinnvoll, im Fehlerfall statt eines Failovers der gesamten ServiceGroup einen lokalen Restart der Resource zu versuchen (z.B. Process). Das dafür zuständige ResourceType-Attribut heißt RestartLimit und hat normalerweise den Wert 0. RestartLimit spezifiziert, wie oft ein Restart vor einem Failover versucht werden darf. Ist allerdings die Resource einmal länger als 10 min. fehlerfrei online (konfiguriert im ResourceType-Attribut ConfInterval, Default 600 Sekunden), dann wird der interne Restart-Counter wieder auf 0 gesetzt.

19.5

Clear

ConfInterval wird auch als Zeitrahmen für das ResourceType-Attribut ToleranceLimit (Default 0) ausgewertet, wie oft innerhalb von ConfInterval monitor offline melden darf, ohne dass es als Fehler interpretiert wird. Diese Attribute gehören zum ResourceType und werden bei Bedarf dort geändert. Sie sind daher global für alle Resources eines Types gültig. Wie man sie für einzelne Resources ändern kann, wird später besprochen.

CLEAR - manuelles Freigegeben von Faulted Resources l Clear FAULTED SG: Löscht den FAULTED-Zustand aller defekten Resources der SG (auf dem angegebenen System) · hagrp -clear XclockSG [-sys sys0] l Clear FAULTED Resource: Löscht den FAULTED-Zustand der defekten Resource (auf dem angegebenen System) · hares -clear XclockSGProcess [-sys sys0] 19.5 19.5.1

166

Fehlerbereinigung Wenn VCS einen Fehler feststellt, markiert er die betroffene Resource für diesen Node als FAULTED, bringt die ServiceGroup auf diesem Node offline und, wenn möglich bzw. konfiguriert (ServiceGroup-Attribut AutoFailover), auf einem anderen Node online. Die ausgefallene Resource bleibt so lange faulted, bis der VCS-Administrator den ResourceZustand FAULTED bereinigt und damit dem Cluster mitteilt, dass die Fehlerursache behoben wurde und der Node wieder als System für die ServiceGroup zur Verfügung steht oder bis der Cluster durch sein Monitoring feststellt, dass die Resource wieder online ist. Dies kann z.B. manuell geschehen sein oder eine Hardware-Resource kann repariert worden sein (Kabel wieder eingesteckt bzw. Strom wieder eingeschaltet). Soll der FAULTED-Zustand manuell bereinigt werden, so erfolgt dies mit dem Befehl hares -clear RES [-sys Node] Ohne System-Spezifizierung wird die Resource auf allen Nodes bereinigt, wo sie faulted ist.

hagrp -clear SG [-sys Node] bereinigt alle FAULTED Resources in der ServiceGroup; es lässt sich durch den Parameter -sys Node auf einem Node einschränken. Enablen von Resources Eine per CLI angelegte Resource hat das Enabled-Attribut zunächst auf 0 (off) gesetzt. Das bedeutet, dass VCS kein Monitoring (in anderer Terminologie: Probing) dieser Resource ausführt, dadurch den physischen Zustand der Resource auf allen Nodes nicht kennt und deswegen keinerlei Aktion wie z.B. Onlining ausführt. Wenn die Resource enabled wird, führt VCS auf allen Nodes als erstes ein Monitoring durch, um den physischen Zustand der Resource festzustellen, bis er deren Zustand auf allen Nodes kennt. Wird der Enabled-Attributwert wieder gelöscht, stellt VCS das Monitoring dieser Resource sofort ein. Eine Resource, die nicht sauber OFFLINE im gesamten Cluster ist, lässt sich allerdings nicht disablen, sie muss zuvor heruntergefahren werden.

19

AUFBAU EINER EINFACHEN SERVICEGROUP Ändern von Attribut-Werten Wenn Sie die Attribut-Werte einer Resource, die online ist, ändern, wird Monitoring ab jetzt nach der neuen Resource-Definition suchen und für diese Resource wahrscheinlich „unexpected offline“ melden, was zum Failover führt. Einzige Ausnahme: Der Process-Agent schaut nach der PID statt nach der

Prozesstabelle, die sich natürlich nicht geändert hat. Hier wird erst ein Offline-Versuch scheitern. Daher müssen Resourcen, deren Attribut-Werte geändert werden sollen, sinnvollerweise zuerst offline genommen, idealerweise sogar disabled werden (es findet ja auch ein Offline-Monitoring statt, das dann u.U. auf sinnlosen Werten arbeiten würde).

19.6

Flush Flush l

Unterbricht das Onlining und Offlining einer ServiceGroup l Bricht online- und offlineThreads der Agents ab l Löscht die Übergangszustände WAITING FOR ONLINE und WAITING FOR OFFLINE l Vorher sind weitere onlineoder offline-Versuche sinnlos l Im Onlining problemlos l Im Offlining Resource erst manuell offline nehmen

hagrp -flush XclockSG -sys sys0 Abbruch von Online- und Offline-Vorgängen Tritt beim Onlining ein Fehler auf so kann unter Umständen die Resource im OnliningZustand verbleiben. Sie erscheint als „Waiting for ONLINE“ im hastatus. In diesem Zustand sind weitere Versuche, die Resource zu onlinen, etwa nach Korrektur falscher Attributwerte, wirkungslos, da sich die Resource nicht in einem sauberen OFFLINEZustand befindet. Nur aus diesem Zustand heraus kann ein online-Versuch gestartet werden. Um die Resource in diesen Zustand zu bringen, muss der online-Thread des Agents abgebrochen und die Zustandsvariable wieder zurückgesetzt werden. Dazu dient die Aktion flush, die immer auf die ServiceGroup auf einem System abgesetzt wird. Die Syntax lässt es nicht zu, ServiceGroup auf allen Systemem zu flushen oder einzelne Resources zu flushen. Wird der Befehl ausgeführt, so geschieht für jede im Übergangszustand befindliche Resource folgendes: Die entsprechenden Agenten stoppen die online- oder offline-Threads, rufen den clean-

19.6

EntryPoint auf, der die Resource in einen sauberen OFFLINE-Zustand bringen soll, und führen zur Erfolgskontrolle einen Monitorzyklus auf die Resource aus. Liefert dieses Probing OFFLINE, so wird der Zustand der Resource entsprechend gesetzt und das Flushing war erfolgreich. Dies ist in der Regel der Fall, wenn ein Online-Versuch unterbrochen wird. Liefert er jedoch ONLINE, so bleibt der FlushVersuch wirkungslos; der Agent konnte den Fehlerzustand nicht bereinigen und die Resource verbleibt im Zustand „Waiting for OFFLINE“. Dies ist immer dann der Fall, wenn die Resource im OFFLINE-Versuch scheitert, zum Beispiel aufgrund einer Fehlkonfiguration. Wenn der Agent die Resource mit dem offline-EntryPoint nicht offlinen kann, kann er dies normalerweise auch mit dem clean-EntryPoint nicht. Daher muss in solchen Fällen die Resource zunächst manuell bereinigt und anschliessend erneut geflusht werden, sodass der abschliessende Monitorzyklus OFFLINE liefert.

19.6.1

167

19 19.6.2

AUFBAU EINER EINFACHEN SERVICEGROUP Environment des Agents und der EntryPoint-Skripte HA-Daemon durch Bootvorgang gestartet: init rc3 S99vcs start hastart HA-Daemon manuell gestartet: init dtlogin dtlogin Xsession sdt_shell -ksh dtsession dtterm ksh hastart Ob die Xclock-Resource problemlos gestartet werden kann hängt vom Environment des online-EntryPoints ab, das seinerseits auf dem Process-Agent und den VCS-Daemon had basiert. Das Environment des had hängt wiederum davon ab, wo hastart

168

ausgeführt wird: im RC-Skript /etc/rc3. d/S99vcs und damit noch ohne Login und X-Server oder auf einem Terminal nach Login mit X-Server. Im ersten Fall enthält z.B. die PATH-Variable nur /usr/bin und /usr/ sbin (von had um /opt/VRTSvcs/bin ergänzt; daher PathName auf /usr/ openwin/bin/xclock), und X-Requests aus diesem Environment sind für den XServer nicht identifizierbar (daher Arguments mit –display unix:0; und auf einem Terminal muss der Befehl xhost + ausgeführt werden, um solchen X-Clients Zugriff zum X-Server zu erlauben).

AUFBAU EINER EINFACHEN SERVICEGROUP

19

Übung: Xclock-ServiceGroup

Ü 19

Übung l

XclockSG anlegen · Attribute definieren l XclockSGProcess anlegen · Attribute definieren l Enablen nicht vergessen! l MonitorInterval, MonitorTimeout und RestartLimit umsetzen l ServiceGroup testen. Wenn Fehler auftreten, diese mit clear bzw. flush bereinigen · hagrp -online xclockSG -sys … · hagrp -offline xclockSG -sys … · hagrp -switch xclockSG -to … · pkill … · hagrp -clear xclockSG [-sys …] · hares -clear xclockSG [-sys …] · hagrp -flush xclockSG -sys … Während aller Übungen sollte auf mindestens einem System ständig ein Fenster mit laufendem hastatus geöffnet sein. Beachten Sie, dass jeder Zustandsübergang sofort im hastatus angezeigt wird. Legen Sie eine ServiceGroup an, wahlweise im GUI (/opt/VRTSvcs/bin/hagui) oder auf der Kommandozeile. Füllen Sie die Attribute PathName und Arguments aus, schalten Sie den X-Server mit xhost + frei und enablen Sie die Resource. Nehmen Sie die Resource oder die ServiceGroup nacheinander auf beiden Systemen online. Wenn dabei Fehler auftreten, versuchen Sie, diese Zustände zu bereinigen (clear für FAULTED Resources, flush für steckengebliebene). Versuchen Sie auch, die ServiceGroup auf beiden Systemen gleichzeitig online zu nehmen und schauen Sie sich die Fehlermeldung an. Ändern Sie die ResourceType-Attribute, die das Verhalten des Agenten bzgl. Monitoring und Restarting steuern. Erzeugen Sie Fehler durch Schliessen des xclock-Fensters und beobachten Sie den hastatus-Output bzw. das GUI.

Ü 19 1.1

Hinweis Zwei gleichzeitig laufende Monitorthreads auf dieselbe Resource können einen Agent irritieren und zu Fehlverhalten des Clusters führen. Daher muss das Attribut MonitorTimeout stets kleiner oder gleich sein wie das Attribut MonitorInterval. Dann unterbricht der Agent zuverlässig den laufenden Monitorzyklus, bevor er einen neuen startet.

169

19 Ü 19

AUFBAU EINER EINFACHEN SERVICEGROUP Musterlösung Xclock-ServiceGroup haconf -makerw # Konfiguration öffnen hagrp –add xclockSG hagrp –modify xclockSG SystemList sys0 0 sys1 1 hagrp –modify xclockSG AutoStart 0 Da AutoStartList leer ist, kann das Kommando zur Änderung von AutoStart auch übersprungen werden. hares –add xclock_process Process xclockSG hares –modify xclock_process PathName /usr/openwin/bin/xclock hares –modify xclock_process Arguments %ʻ–display unix:0 –bg red –update 1ʻ Die Erklärung des Prozentzeichens und des notwendigen Quotings findet sich in der Box auf der rechten Seite. hares –modify xclock_process Enabled 1 Ändern des Resource Types, um Prozesse enger zu überwachen und sie nach Ausfall restarten zu lassen. hatype -modify Process MonitorInterval 10 hatype -modify Process MonitorTimeout 10 hatype -modify Process RestartLimit 3 haconf -dump -makero hagrp hagrp hagrp hagrp hagrp

170

# Konfiguration schreiben und schliessen

-online xclockSG -sys sys0 -offline xclockSG -sys sys0 -online xclockSG -sys sys1 -switch xclockSG -to sys0 -flush xclockSG -sys sys0

AUFBAU EINER EINFACHEN SERVICEGROUP

19

Attribut-Typ und –Dimension: Eine Analyse des Process-Attributs Arguments zeigt, dass es sich um eine Zeichenketten-Variable (string) mit nur einem Element handelt (scalar, wird später noch detaillierter besprochen): haattr –display Process | awk ʻ$1==”Arguments”ʼ Arguments [string/scalar] = Daraus folgt, dass alle Optionen, die unter dem Attribut Arguments eingetragen werden sollen, mit single oder double Quotes als ein Shell-Wort markiert werden müssen, da es sich sonst um einen Vektor aus mehreren Werten handeln würde. Probieren wir dies: hares –modify xclock_process Arguments ʻ–display unix:0 –bg red –update 1ʼ Allerdings teilt uns die Fehlermeldung von hares mit, dass jetzt die Option ‘–display unix:0 –bg red –update 1’ unbekannt ist. Optionsverarbeitung unter VCS Das hares-Kommando kann nicht erkennen, dass die von uns als Attribut-Wert für Arguments gedachten Optionen nicht für das hares-Kommando selbst bestimmt sind, sondern einen Attributwert für die Resource darstellen. Der String beginnt mit einem Bindestrich, also wird er natürlich in die Optionsverarbeitung einbezogen, wo er zu einem Fehler führt. Jegliches Quoting, egal ob durch Backslash, Single- oder Double-Quotes, wird durch die interpretierende Shell verarbeitet. Daher macht es für die Interpretation des Bindestrichs keinen Unterschied, ob man quotet oder nicht. Aber es gibt einen Weg, um dem ausführenden Kommando mitzuteilen, dass jetzt keine hares-Option mehr folgt. Dazu dient in VCS das Zeichen % (ähnlich wie in der getopts-Library von UNIX System V die Escape-Sequenz „--“). hares –modify xclock_process Arguments %ʼ–display unix:0 –bg red –update 1ʼ

171

KAPITEL 20

FUNKTIONSWEISE VON VERITAS CLUSTER SERVER

20 20.1

FUNKTIONSWEISE VON VERITAS CLUSTER SERVER Architekturübersicht Architektur l

Heartbeat als Basis für clusterglobale Variablen l Parallele Applikationen darüber l had ist eine parallele Applikation

20.1

20.1.1

174

Konzeptionell ist ein Veritas Cluster nichts anderes als eine parallele Applikation, die zur Überwachung von einzelnen Komponenten der Maschine (sogenannten Resources) sowie zum kontrollierten Starten und Stoppen von Diensten (sogenannten ServiceGroups) dient. Um diese Aufgabe zu erfüllen, benötigt der Veritas Cluster eine sehr leistungsfähige Kommunikationsinfrastruktur: einen Heartbeat, bestehend aus physischen Netzwerkverbindungen und darauf agierenden speziellen Gerätetreibern. Der Heartbeat, auch Interconnect genannt, ermöglicht es, Variablen global im Cluster zu halten, indem sie auf jede Maschine repliziert werden. Oracle benutzt diese Funktionalität bei RAC (Real Application Clusters) zum Abgleich von SGA-Daten zwischen den einzelnen Nodes. Es handelt sich

hier also keineswegs um ein einfaches „ping", wie bei vielen anderen Clusterprodukten. Die parallele Applikation had verteilt die Konfiguration als clusterglobale Variablen auf alle Maschinen und führt auf Anfrage des Users oder automatisch Start- Stop- und Überwachungsaktionen aus. Im Gegensatz zu vielen anderen Clusterprodukten kapselt VCS die Resources nicht vom User ab. Dies würde dazu führen, dass Resources nur noch durch den Cluster zugreifbar sind. Fällt die Clustersoftware selbst aus oder muss sie zu Wartungszwecken gestoppt werden, so laufen bei VCS alle Resources unbeirrt weiter, während sie bei anderen Clustern in der Regel gestoppt werden müssen. VCS nimmt beim (Re)start auch bereits laufende Applikationen wieder unter Kontrolle.

FUNKTIONSWEISE VON VERITAS CLUSTER SERVER

20

High-Speed Kommunikation via LLT

20.2 LLT l

Low Latency Transport Basisprotokoll für Heartbeat l Lightweight l MAC-Adressierung l Kernel-Mode l höchste Priorität l Standardkonform (DLPI) l Multiplexing l

20.2

Als Basis-Transportprotokoll für VCS wird LLT benutzt. Die Abkürzung steht für Low Latency Transport. Es ist ein extrem schnelles Protokoll mit sehr geringem Overhead. Es basiert auf MAC-Adressierung und multiplext über alle verfügbaren Interfaces. Die erzeugten Pakete sind wegen der MAC-Adressierung nicht routbar. Da sie auf DLPI-Frames (DLPI=Data Link

Provider Interface) aufbauen, sind sie mit allen normalen Ethernet-Komponenten kompatibel. LLT-Pakete werden im Kernel mit höchster Priorität abgearbeitet; es kann nicht vorkommen, daß ein LLT-Paket ankommt, aber nicht verarbeitet wird, da die Verarbeitung direkt im Kernel-Treiber geschieht.

20.2.1

175

20 20.3

FUNKTIONSWEISE VON VERITAS CLUSTER SERVER TX-orientierte Nachrichtenübermittlung via GAB GAB l

Group membership services and Atomic Broadcast l Cluster-Monitor l Transportiert Nachrichten transaktionsfest l Nachrichten sind durch Broadcast serialisiert l Große Funktionalität von GAB ermöglicht komplexe Cluster wie VCS oder RAC

20.3

20.3.1

176

Oberhalb von LLT befindet sich ein weiterer Kernel-Treiber, GAB. Die Abkürzung steht für Group Membership Services and Atomic Broadcast. Daraus wird schon ersichtlich, dass GAB zwei (völlig unabhängige) Funktionen hat. Zunächst zum Atomic Broadcast: GAB sendet Nachrichten prinzipiell an alle Teilnehmer des Heartbeat-Netzes, da es (via LLT) nur Broadcasts sendet. Das Spezielle an GAB ist, dass es nicht nur explizite Nachrichten sendet, sondern auch implizite Nachrichten erzeugt. Denn dadurch, daß stets alle Maschinen adressiert werden, wird auch das Ausbleiben einer Nachricht zur Information. Bemerkt beispielsweise eine Maschine das Ausbleiben der Empfangsbestätigung für eine Nachricht, so kannn sie davon ausgehen, dass auch alle anderen Maschinen diese Empfangsbestätigung nicht erhalten haben. Die Aktion, die durch die Nachricht ausgeführt werden sollte, wird dann

nicht ausgeführt. Da alle Maschinen aufgrund des zugrundeliegenden Broadcast-Mechanismus stets zur selben Zeit die selben Datenpakete erhalten (oder eben vermissen), muss ein Rollback nicht ausdrücklich vereinbart werden, sondern er ergibt sich durch den Mechanismus selbst. Durch diesen Trick wird eine sehr zuverlässige Kommunikation mit sehr wenig Aufwand zur Laufzeit erreicht; das Problem, dass die Information auf den einzelnen Knoten des Clusters durch Kommunikationsprobleme oder RaceConditions auseinanderläuft und so zu Fehlverhalten führt, wurde in der Entwurfsphase von GAB gelöst und nicht in der Implementation. Hinzu kommt, dass der GAB-Layer die gesamte Komplexität von Transmit, Acknowledge, Commit bzw. Rollback vollständig von der darüberliegenden Applikation abkapselt und diese somit stark vereinfacht.

FUNKTIONSWEISE VON VERITAS CLUSTER SERVER

20

Feststellung von Mitgliedschaften via GAB

20.4 GAB l

Verwaltet Memberships Verwaltet Ports l Erzeugt Reconfiguration Events l Zentraler Teil von VCS, RAC etc. l

20.4

GAB enthält darüberhinaus Funktionen zum eindeutigen Feststellen der Mitgliedschaften in einem Clusterverbund. Dazu werden, ähnlich wie bei IP, Ports benutzt, deren ID bei GAB aus einem ASCII-Zeichen besteht. Für sich selbst verwendet GAB den Port „a“. Über diesen Port kann der GAB-Layer auf der einen Maschine den GAB-Layer auf jeder anderen Maschine abfragen. Wenn sich eine ausreichende Anzahl Maschinen gegenseitig auf Port a finden, so bildet GAB (auf allen Maschinen gleichzeitig) eine „Membership“ auf Port a. Die dazugehörigen Maschinen sind dann Mitglieder eines Clusters. Ist eine Maschine Teilnehmer einer solchen Membership, so können auf dieser Maschine weitere Ports auf GAB geöffnet werden. Dies geschieht durch speziell für GAB geschriebene Programme, z.B. durch ein paralleles Filesystem, den Oracle Disk Manager, oder auch den HA-Daemon (had) von VCS. VCS-had öffnet Port „h“. Im Falle des VCS-had wird damit unter anderem erreicht, daß nur eine Maschine die Konfiguration des Clusters aus dem Filesystem liest (main.cf). Jede weitere Maschine wird, durch die strenge Serialisierung aller Kommu-

nikation via GAB, an einer gleichzeitigen Initialisierung des Clusters gehindert und lädt stattdessen mit einem VCS-internen „BootRequest“ die Konfiguration von einem bereits laufenden Knoten (einem Mitglied der Membership auf Port h) herunter. Bevor eine Membership auf Port a besteht, wird das Öffnen anderer Ports durch GAB blockiert. So wird ein unkontrollierter Start von HA-Applikationen verhindert, wenn der Cluster nicht durch GAB abgesichert ist. Kurz gesagt wird durch GAB also geregelt, unter welchen Umständen auf welchen Maschinen parallele Applikationen gestartet werden können. Der had von VCS ist selbst nicht weiter als eine parallele Applikation, die ihre Daten per GAB-Broadcast über alle Knoten verteilt. Schließt eine Maschine einen bestimmten Port, so wird auf allen anderen „Members“ zeitgleich ein „Reconfiguration Event“ erzeugt, der für die nötigen Aufräumarbeiten (Übernahme von Diensten, Aufräumen von Locks etc.) sorgt. Der Absturz einer Maschine führt zu einem Schließen von Port a mit entsprechenden Reconfiguration Event auf allen Ports, da alle Applikations-Ports von Port a abhängen.

20.4.1

177

20 20.5

FUNKTIONSWEISE VON VERITAS CLUSTER SERVER Aufgaben des HA-Daemons (had) HA-Daemon (had) l

Schickt Anforderungen an seine Agents l Sammelt Informationen von den Agents l Reagiert auf Ausfallmeldungen von Agents(Failover) l Übermittelt Informationen via GAB an „den Cluster“ l Nimmt Befehle vom User entgegen und leitet sie via GAB an „den Cluster“ l Führt Befehle aus, die von GAB kommen l Verwaltet die Konfiguration des Clusters mit Ressourcen, ServiceGroups, Abhängigkeiten etc. l Steuert das gezielte Onlining und Offlining ganzer ServiceGroups 20.5

20.5.1

178

Zwischen GAB einerseits und den Agents andererseits befindet sich der HA-Daemon (in Zukunft had genannt). Diesem ist die Konfiguration des Clusters mit allen ServiceGroups, Ressourcen und deren Abhängigkeiten etc. bekannt. Er kann daher eine ServiceGroup, also eine Menge voneinander abhängiger Resources, die gemeinsam einen Dienst darstellen, geordnet starten und stoppen. Der had entscheidet auch, ob der Ausfall einer Ressource zu einem Failover der ServiceGroup führen muss oder nicht. Er tut dies anhand von durch den Administrator gesetzten Attributen und Abhängigkeiten. Ausserdem nimmt der had auch die Reconfiguration Events von GAB entgegen. Dadurch bekommt had den Ausfall bzw. den ClusterJoin/Cluster-Exit einer Maschine mitgeteilt und reagiert entsprechend, z.B. durch Über-

nahme der auf der ausgefallenen Maschine zuletzt oline gewesenen Service Groups. Ausserdem kommuniziert der had auf jeder Maschine seine gesamte Statusinformation zu allen anderen Mitgliedern des Clusters, sodass jede Maschine gewissermassen dasselbe „weiss“, zumindest bezüglich des Clusters. Auf diese Weise wird ein Cluster-Layer implementiert, der es unwichtig macht, auf welcher Maschine man eine Konfigurationsänderung macht (alle Konfigurationsänderungen werden durch Befehle durchgeführt), einen Online-Befehl für eine Ressource absetzt oder ähnliches. Stets ist der Empfänger eines Befehls „der Cluster“ als ganzes. Der einzige Befehl, der auf jedem Knoten einzeln ausgeführt werden muss ist der Befehl zum Starten des Clusters (hastart). Denn vorher ist die Funktionalität, die den ClusterLayer bildet, noch nicht vorhanden.

FUNKTIONSWEISE VON VERITAS CLUSTER SERVER

20

Kommunikationsprinzip des HA-Daemons

20.6 Atomic Broadcast l

Sendet Info per Broadcast wartet auf ACK von allen (auch von sich selbst) per Broadcast l Wenn alle ACKs vorliegen, ist Information gültig l Wenn ein ACK ausbleibt, gilt dies wegen Broadcast für jede Maschine l Alle Maschinen verwerfen dann die Information l

20.6

Der HA-Daemon benutzt einen interessanten Ansatz, um die Konsistenz aller Information auf allen Nodes sicherzustellen: Die Zustandsmeldungen von den Agents (Resource OK/nicht OK) werden nicht lokal verarbeitet sondern, ebenso wie auch alle ha-Befehle, nur entgegengenommen und über GAB und LLT transaktionsorientiert an alle Nodes übertragen. Bei Ausbleiben der Bestätigung eines aktiven Nodes wird der gesamte Vorgang zurückgerollt und neu versucht. Da auch der sendende Node seine eigenen Broadcasts empfängt, bekommt er auf die Mikrosekunde genau gleichzeitig mit allen anderen Nodes die exakt gleiche Information. Dadurch, dass auf allen Nodes der gleiche HA-Daemon und damit der gleiche Algorithmus läuft, sind identische

Ergebnisse bei allen Entscheidungen gewährleistet. Durch diesen Ansatz ergibt sich eine völlige Transparenz bezüglich des Ortes einer Aktion, d.h. es ist vollkommen egal, von welcher Maschine eine Information oder ein Befehl stammt; das Resultat ist stets genau das gleiche. Ausserdem weiss jede Maschine über sich selbst zu jedem Zeitpunkt genau das gleiche wie alle anderen Maschinen, da sie Informationen über sich selbst erst dann verwendet, wenn sie global verfügbar sind. Dieses Verfahren schliesst bereits durch das Design der Software jegliches Auseinanderlaufen der Konfiguration oder Zustandsinformation von vornherein aus.

20.6.1

179

20 20.7

FUNKTIONSWEISE VON VERITAS CLUSTER SERVER Überwachung von Ressourcen durch Agents VCS-Agents l

Spezielle Programme zur Überwachung bestimmter Funktionalitäten (Ressourcen) l Überwachen periodisch alle definierten Ressourcen l Kommunizieren mit had l Ein Agent pro RessourceType l Leicht selber zu entwickeln l Flexibles Konzept

20.7

20.7.1

180

Am nächsten an der zu überwachenden Applikation sind die sogenannten „Agents“ angesiedelt. Es handelt sich hierbei um ausführbare Programme, die mit VCS geliefert werden oder als eigene Entwicklung hinzukommen. Ein Agent enthält Programmcode, der zum Starten, Stoppen, Überwachen oder Aufräumen von Ressourcen eines bestimmten Typs dient. Natürlich kann der Mount-Agent, der den Code für das Mounten, Unmounten und Überwachen von Filesystemen enthält, nicht auch Netzwerkschnittstellen überwachen, da hierfür völlig anderer Programmcode verwendet wird. Für die Netzwerkschnittstellen ist daher ist ein anderer Agent zuständig, der seinerseits auch nur Netzwerkschnittstellen überwachen kann, und so weiter. Ein einziger Agent pro Maschine überwacht alle definierten und aktivierten Ressourcen seines Typs. Aktiviert wird eine Ressource,

indem ihr Attribut „Enabled“ auf den Wert 1 gesetzt wird. Dabei findet sofort eine Zustandsüberprüfung (Probing bzw. Monitoring) statt und darüberhinaus wird das periodische Monitoring eingeschaltet. Dieses findet defaultmässig alle 60 Sekunden statt, wenn die Resource ONLINE ist bzw. alle 300 Sekunden, wenn die Resource OFFLINE ist. Der Grund für die Überwachung auch der OFFLINE Resources ist, dass der had ein unerwartetes ONLINEgehen der Resourcen erkennen und unterbinden muss. Jeder Agent tauscht regelmässig Informationen bezüglich des Zustandes seiner Ressourcen mit dem had auf seiner Maschine aus. Der had leitet diese Information via GAB an alle anderen Mitglieder des Cluster-Verbundes weiter, sodass jederzeit auf allen Maschinen der Zustand aller „Enabled“ Resources bekannt ist.

FUNKTIONSWEISE VON VERITAS CLUSTER SERVER

20

Bestandteile von Agents

20.8 Bestandteile von Agents l

Agent-Binary – Kommunikation mit had – Heartbeating zum had – Aufruf von Entry Points l Entry-Points – häufig Perl-Scripts – sonst im Agent-Binary – Aktionen der Resources · online · offline · monitor · clean ·… l Überprüfung jeder Aktion durch anschliessenden monitor-Aufruf (Probing)

20.8

Ein VCS-Agent hat im wesentlichen zwei Funktionalitäten: Erstens kommuniziert er mit dem had, um Statusinformationen auszutauschen, über ProzessHeartbeating seine Existenz zu melden und um Online- bzw. Offline-Anforderungen vom had entgegenzunehmen. Zweitens steuert und kontrolliert er die Resources. Das heisst, er sorgt für das gezielte Starten und Stoppen von Resources, wenn ihm dies vom had befohlen wird. Dazu ruft der Agent sogenannte Entry-Points auf. Dies sind resourcebezogene Funktionen wie Onlining, Offlining oder Monitoring (Probing). Implementiert sind diese Funktionen meist in Form von

perl-Scripts. Sie sind dann die beste Referenz in all den Fällen, wo über das genaue Verhalten von bestimmten Resources Unklarheit herrscht. Gelegentlich sind auch einzelne Entry-Points direkt in das Agent-Binary hineinkompiliert; dies meist aus Performancegründen. Agenten liegen in einem Verzeichnis, dessen Name der Name des ResourceTypes ist, innerhalb von $VCSHOME/bin. Das Agent-Binary trägt den Namen des ResourceType, gefolgt von Agent, während die Entry-Point-Scripts einfach online, offline, monitor etc. heissen. Zum Beispiel hat das Agent-Binary der Mount-Resource den Pfad /opt/ VRTSvcs/bin/Mount/MountAgent.

20.8.1

181

20 20.9

FUNKTIONSWEISE VON VERITAS CLUSTER SERVER Zusammenspiel der Komponenten HA-Aktionsablauf 1: Online- oder Offline-Befehl ergeht an had 2: Broadcast über GAB 3: Empfang auf jedem Knoten 4: Ignorieren bzw. Ermitteln des richtigen Agents 5: Weiterleiten an Agent 6: Agent holt ArgListValues 7: Agent ruft Entry-Point mit diesen Parametern auf und wartet vor Monitoring 8: Agent ruft Monitor-EntryPoint auf und wertet ExitCode aus 9: Weiterleiten an had und Broadcast über GAB 10: Zustand clusterweit bekannt 20.9

20.9.1

182

Wie kommt eine Resource ONLINE? - Der User gibt den Online-Befehl für die Resource MyIP: hares -online MyIP -sys mysys - Der Befehl wird durch den had auf das HBNetz verteilt und dort von allen Maschinen empfangen. Alle Maschinen ausser mysys ignorieren den Befehl; nur auf mysys läuft folgendes ab: - Der had ermittelt anhand der im Speicher befindlichen Clusterkonfiguration den Resource Type der Resource MyIP. Er erhält den Resource Type IP. Sie können dies mit folgendem Befehl nachvollziehen: hares -value MyIP Type. - Der had leitet die Anforderung, die Resource online zu nehmen, an den IP-Agent weiter. - Der Agent ermittelt die zu der Resource MyIP gehörenden Werte der ArgumentenListe (Interface qfe3, Address 194.76.15.233, Netmask 255.255.255.0). Diese Parameter sind auf allen Maschinen des Clusters in der Konfiguration im Speicher für alle Agents abrufbereit (über GAB verteilte globale Variablen). Sie können dies mit folgendem Befehl nachvollziehen: hares -value MyIP ArgListValues. - Der Agent ruft seinen online-EntryPoint

auf. Im Falle der IP-Resource handelt es sich dabei um ein Perl-Script im AgentDirectory: ./online MyIP qfe3 \ 194.76.15.233 255.255.255.0 - Das online-Perl-Script des Agents übernimmt die Kommandozeilenparameter und benutzt sie, um die geforderte Aktion (Konfigurieren der angegebenen IP-Adresse auf dem richtigen Interface mit der richtigen Netmask etc.) auszuführen und liefert einen erfolgsunabhängigen Exit-Code zurück. Der Exit-Code teilt dem Agent mit, wie lange er warten soll, bevor die Resource überprüft wird. - Der Agent wartet die Anzahl Sekunden, die dem Exit-Code des online-Scripts entspricht und gibt damit der Resource Zeit, stabil online zu sein. Um festzustellen, ob das Onlining erfolgreich war, ruft er anschließend auf: ./monitor MyIP \ qfe3 194.76.15.233 \ 255.255.255.0 - Der monitor-Entry-Point des Agents — auch hierbei handelt es sich um ein PerlScript — übernimmt die Kommandozeilenparameter und benutzt sie, um die geforderte Aktion (Überprüfen, ob die angegebe-

FUNKTIONSWEISE VON VERITAS CLUSTER SERVER ne IP-Adresse auf dem richtigen Interface mit der richtigen Netmask etc. online ist) auszuführen und liefert als Exit-Code 100 zurück, wenn die Resource OFFLINE ist und 110, wenn die Resource ONLINE ist. Die Werte dazwischen sind vordefiniert für „varying degrees on ONLINE-ness“, werden jedoch in der Version 4.x von VCS noch nicht ausgewertet.

20

- Der Agent meldet den Erfolgsstatus des monitor-Entry-Points an den had zurück, der diesen Status über GAB clusterweit verteilt. - Die had-Prozesse auf allen Maschinen kennen jetzt den neuen Zustand der Resource MyIP.

183

KAPITEL 21

AUFBAU VON SERVICE GROUPS

21 21.1

AUFBAU VON SERVICE GROUPS Definition von ServiceGroup ServiceGroups: l

Dienste unter ClusterKontrolle. l Bestehen aus einer oder mehreren Resources. l Diese Resources dürfen nicht mehr vom Betriebssystem verwaltet werden. l Werden durch HA-Daemon gestartet, gestoppt und umgeschaltet. l Sind normalerweise auf allen Nodes lauffähig. l Sind normalerweise nur auf einem Node zu einer Zeit online. l Spezielle „parallele“ Service Groups können auf mehreren Nodes gleichzeitig online sein. 21.1

21.1.1

Der Übergang in den Clusterbetrieb Werden alle für einen bestimmten Dienst benötigten Resources (Disks, IP-Adressen, Filesystem-Mounts, Prozesse etc.) auf allen Nodes der Kontrolle durch das Betriebssystem entzogen und als VCS-Resources in eine Service Group übernommen, so kann dieser Dienst fortan durch VCS kontrolliert gestartet, gestoppt und überwacht werden. VCS sorgt dann dafür, dass bei Ausfall von Resources diese entweder nachgestartet wer-

186

den oder dass die gesamte ServiceGroup lokal offline und auf einem anderen Node online geht. „Der Kontrolle durch das Betriebssystem entziehen“ bedeutet z.B. Entnahme eines MountPoints aus der /etc/vfstab, Entnahme einer IP-Adresse aus einer /etc/hostname.* Datei, Umnennen der Startup- und Kill-Scripts in / etc/rc*.d etc. Die Übernahme als ClusterResources wird im folgenden dargestellt.

AUFBAU VON SERVICE GROUPS

21

Konfiguration

21.2 Resources: l

Teile einer Service Group. Tragen definierende Attribute. l Tragen einen clusterweit eindeutigen Namen. l Werden durch geeignete Agents überwacht. l Verschiedene vorgefertigte ResourceTypes vorhanden. l Weitere ResourceTypes verfügbar. l

21.2

Resources sind einzelne Objekte im Rechner, die zu einem Dienst gehören. Es gibt die unterschiedlichsten Möglichkeiten für ResourceTypes: z.B. gibt es einen ResourceType „NIC“, der Netzwerkcontroller (Hardware) steuert, aber auch einen Typ „Oracle“, der eine OracleDatenbank (Prozess) steuert und einen Typ „IP“, der IP-Adressen steuert (Konfiguration). „Steuern“ bedeutet in diesem Zusammenhang das Starten („Onlining“), Stoppen („Offlining“) und Überwachen („Monitoring“). Normalerweise besitzt jede Resource eine oder mehrere Variablen („Attribute“), die angeben, was gesteuert werden soll. Z.B. würde man einer Resource von Typ „Mount“ die Variable BlockDevice und die Variable MountPoint mit dem Diskpfad bzw. dem Zieldirectory der Mount-Aktion füllen. Erst dann kann eine sinnvolle Steuerung der Resource stattfinden.

Für jeden ResourceType und damit für alle Resources dieses Types ist jeweils ein Agent zuständig, der die entsprechenden Funktionen implementiert. Am Beispiel des MountResourceTypes kann man das Onlining, Offlining und Monitoring gut verdeutlichen: Online bedeutet, das angegebene $Block Device an den angegebenen $MountPoint zu mounten, Offline bedeutet ein umount desselben, und Monitor bedeutet eine Überwachung, ob das $BlockDevice and den $Mount Point gemountet ist. Diese Aktionen (mount, umount, df -k $MountPoint) sind natürlich für jeden ResourceType spezifisch. Daher braucht jeder ResourceType seinen eigenen Agents mit dem entsprechenden Programmcode für die von ihm gesteuerten Teile (Resources) des Clustersystems.

21.2.1

187

21 21.3

AUFBAU VON SERVICE GROUPS Dependencies Abhängigkeiten (Dependencies): l Bilden die logischen Abhängigkeiten ab. l Sorgen für korrekte Reihenfolge bei Start und Stop. l Bilden Kausalkette für Failover. l Parent-Child-Beziehung. l Parent hängt ab von Child! l Multi-Parent, Multi-Child möglich. l Nur der HA-Daemon kennt die Dependencies, die Resources kennen diese nicht.

21.3

21.3.1

188

Erst durch Abhängigkeiten werden die Resources in einen sinnvollen Zusammenhang gebracht. Es hat beispielsweise wenig Sinn, erst ein Directory zu exportieren und danach das Filesystem hinein zu mounten, denn dann ist das darunterliegende (leere) Directory exportiert. Durch geeignete Abhängigkeiten wird eine korrekte Reihenfolge der Abarbeitung von On- und Offlining aller Resources erreicht. Onlining beginnt gleichzeitig an allen Blättern und pflanzt sich nach oben fort, sobald alle Abhängigkeiten der darüberliegenden Resources erfüllt sind (alle Children sind online), Offlining beginnt bei allen Wurzelknoten einer ServiceGroup gleichzeitig und pflanzt sich von dort jeweils nach unten fort. Dieser Prozess heißt in der VCS-Terminologie OFFLINE PROPAGATE. Beim Ausfall einer Resource („Resource Fault“)

wird der von dieser Resource abhängige Teilbaum offline genommen und anschließend die Entscheidung getroffen, ob ein Failover auf einen anderen Node durchgeführt werden soll oder nicht. Ist eine der aufgrund des Resource Faults OFFLINE gegangenen Resources als „Critical“ definiert (Critical hat den DefaultWert 1, für TRUE), so wird anschliessend die gesamte ServiceGroup offline genommen. Ob die ServiceGroup danach auf einer anderen Maschine online genommen wird, hängt noch von verschiedenen Parametern ab (SystemList, HandleFaults etc.) Ist keine der Resources, die aufgrund des Faults OFFLINE gegangen sind, als „Critical“ definiert, so bleibt die ServiceGroup in dem jetzt erreichten Zustand. Dieser heißt PARTIAL (partiell online).

AUFBAU VON SERVICE GROUPS

21

Beispiel einer ServiceGroup

21.4 Konkrete ServiceGroup l

Resource Dependencies finden sich oft als logische Abhängigkeiten in Attributen wieder. l Online-Kette von unten nach oben. l Offline- und Fault-Ketten von oben nach unten.

21.4

Im Beispiel ist die vorherige ServiceGroup, bestehend aus fünf Resources mit fünf verschiedenen ResourceTypes, im ausgefüllten Zustand zu sehen. Eine Disk-Resource steuert die Partition „c1t12d0s3“, eine Mount-Resource steuert das Mounten von „/dev/dsk/c1t12d0s3“ nach „/export/apache“, die darüberliegende Process-Resource steuert einen ApacheServer mit dem Parameter „/export/apache“, der hier das Root-Directory für die Web-Daten angibt. Sind all diese Resources online und ist auch der Netzwerkcontroller qfe0 (gesteuert durch die NIC-Re- source) intakt, so kann die zuoberst liegende IP-Resource die Adresse „12.18.10.41“ auf qfe0 online nehmen. Fällt irgendeine der Resources aus, so werden alle darüberliegenden Resources, beginnend bei der IP-Resource, offline genommen. Anschliessend kann ein Failover eingeleitet werden. Beim Betrachten der Attributwerte fällt auf, dass sich die Parent-Child-Dependencies häufig in Form von gleichen Attributwerten in abhängigen Resources wiederfinden, z.B. qfe0 in der NIC- und der IP-Resource und die Kette

von c1t12d0s3->/export/apache->“-d /export/ apache“. Weder had noch die Agents haben Kenntnise über die Natur der Resources. Lediglich die Entry-Points der Agents verfügen über direkte, Resource-spezifische Methoden. Aus diesem Grund erfolgt bei der Definition der Resource-Dependencies keine automatische Konsistenzprüfung auf die ResourceParameter. Es ist z.B. möglich, eine IP-Resource so zu definieren, dass sie eine Adresse auf dem Interface „ce2“ kontrolliert, aber von einer NIC-Resource abhängt, die qfe0 überwacht. Dies führt nicht zu einer Fehlermeldung im VCS-Cluster. Im Betrieb wird die ServiceGroup aber nicht korrekt funktionieren, denn sie schwenkt, wenn qfe0 ausfällt und schwenkt nicht, wenn ce2 ausfällt. Bei der Einrichtung der ServiceGroups muß daher darauf geachtet werden, dass die logischen Abhängigkeiten der Resources sowohl durch Definition geeigneter Dependencies als auch durch Wahl der richtigen Attributwerte der Resources abgebildet werden.

21.4.1

189

21 21.5

AUFBAU VON SERVICE GROUPS Beziehung zwischen Agent und Resource Agent und Resource l

Kompiliertes Programm, das mit had kommuniziert l Funktionen in sog. EntryPoints (oft Perl-Scripts) l Implementiert einen ResourceType l 1-zu-1 Beziehung Agent zu ResourceType l Attribute des ResourceTypes gelten global für alle Resources dieses Typs l Ausnahmen möglich durch hares -override

21.5

21.5.1

190

Das obige Diagramm zeigt, dass auch bei Verwendung mehrerer Resources gleichen Typs nur ein Agent für alle Resources dieses Typs läuft. Daher wirken sich Änderungen an Agents oder ResourceTypes auf alle Resources dieses Typs aus. Die Agents zu jedem ResourceType finden sich jeweils in Directories mit den Namen $VCSHOME/bin/ResourceTypeName. In diesem Directory liegt ein Executable mit dem Namen ResourceTypeNameAgent und meist mehrere Perl-Scripts, die einige der Entry-Points implementieren (andere EntryPoints sind entweder in das Executable einkompiliert oder sie sind nicht implementiert). Anhand des Perl-Codes kann man die Arbeitsweise des jeweiligen Agents im Zweifelsfall gut nachvollziehen. Die Auswahl, welche Resource durch den Agent konkret angesprochen wird, geschieht ausschliesslich über die anhand des ResourceNamens aus der Konfiguration ermittelten Werte der Argumentliste (ArgListValues). Die Argumentliste (ArgList) ist ein Attribut des ResourceTypes und enthält die Namen jener Variablen, die den EntryPoints auf der Kommandozeile übergeben werden. Die ArgList eines ResourceTypes stellt also das Interface zwischen Benutzer und Resource

dar; die Liste der Variablen, die der Benutzer ausfüllen muss, um eine Resource auszufüllen. Das Attribut ArgListValues gehört zu jeder konkreten Resource und enthält die Werte der in ArgList definierten Variablen, mithin die konkreten Werte, die der Agent seinen Entry-Points übergibt, um eine bestimmte Resource zu steuern. Die ArgListValues sind daher das Interface zwischen dem HA-Daemon und dem Agents sowie zwischen dem Agents und seinen EntryPoints. Sie können es wahrscheinlich leichter begreifen, wenn Sie ein konkretes Beispiel durchführen. Etwa so: RESOURCE=MyProcRes hares -value $RESOURCE Type Process # der ResourceType hatype -value Process ArgList PathName Arguments # die Variablen hares -value $RESOURCE ArgListValues # die Variablenwerte “/usr/openwin/bin/xcalc“ \ “-display unix:0 -bg red“

AUFBAU VON SERVICE GROUPS Das Attribut ArgList ist im ResourceType die Liste der Namen von Variablen, die man für jede Resource, also für jede Instanz des ResourceTypes, ausfüllt.

21

Das Attribut ArgListValues ist für jede einzelne Resource unterschiedlich und enthält die Liste der Werte jener Variablen für die fragliche Resource.

191

KAPITEL 22

APACHE WEB SERVER TEIL 1 NETZWERKRESOURCES

22 22.1

APACHE WEB SERVER TEIL 1 Vorstellung der Apache-ServiceGroup Apache-Resources l

Client-Connect via IP IP benötigt NIC l Apache-Serverprozess l Serverprozess hängt von Existenz des Binary ab l Binary liegt im Shared Storage (Mount) l Shared Storage wird durch Volumes angeboten. Mount hängt von Volume ab. l Mount benötigt auch existierendes Zieldirectory. l Volumes liegen in einer gemeinsamen DiskGroup, hängen von dieser ab. l DiskGroup kann vor Import auf SCSI-Ebene 22.1 reserviert werden. l

22.1.1

194

Im Rest des Kurses wird schrittweise ein Apache Web-Server hochverfügbar gemacht. Dabei werden die dazu nötigen ResourceTypes besprochen sowie deren Handhabung und eventuelle mit ihnen auftretende Besonderheiten. Am Ende sollte ein gutes Verständnis sowohl für die architekturelle Vorgehensweise bei der Erstellung einer ServiceGroup als auch für die Details erarbeitet worden sein. Für Fortgeschrittene kann noch eine spezielle eigene Resource angefertigt werden, wenn die Zeitplanung und die Vorkenntnisse dies zulassen. In den folgenden Modulen wird vor dem Anlegen von VCS-Resources zunächst zusammengestellt, wie man per CLI den Zustand dieser Resource unabhängig von VCS feststellen und sie online bzw. (zwangsweise) offline bringen könnte. Dabei steht als Beispiel immer der zu clusternde Web-Server im Hintergrund. Der Vergleich mit dem Vorgehen des ResourceTypeAgents wird in den meisten Fällen klare Parallelen aufweisen. Das heißt: Die Agents führen im wesentlichen genau diejenigen Kommandos aus, die man auch per CLI eingeben würde. Da die Entry-Points der Agents überwiegend Perl-Skripte sind, die Beispiele jedoch in Shell vorliegen, gibt es natürlich Unterschiede im Detail.

Als Voraussetzung für alle VCS-Resources muss aber zunächst eine ServiceGroup definiert werden. Diese stellt den Behälter dar, in den die Resources eingefügt werden, und bündelt die Resources zwecks gemeinsamer Behandlung (Online, Offline etc.). Die Eigenschaften der ServiceGroup werden von uns so definiert, dass sie unser gewünschtes Verhalten möglichst genau abbildet. Dazu legen wir dieses Verhalten zu Beginn fest: l Die ServiceGroup soll einen sprechenden Namen haben, gleichzeitig aber als Object ServiceGroup eindeutig identifizierbar sein. Wir geben ihr daher den Namen apacheSG. l Die Applikation soll auf allen Nodes, nicht nur auf einer Teilmenge, lauffähig sein. l Der Web-Server ist eine Failover-ServiceGroup, d.h. die Applikation soll nicht auf mehr als einem Node gleichzeitig online sein. l VCS soll beim Starten die ServiceGroup automatisch online bringen. l Wir definieren die Priorität der Nodes, wenn VCS beim Starten die ServiceGroup online bringen will, und legen zugleich fest, dass VCS dafür alle Nodes benutzen darf. Daraus ergeben sich die notwendigen Attribute, die durch die auf der Übungsseite erläuterten Befehle gesetzt werden.

APACHE WEB SERVER TEIL 1

22

hagrp –add apacheSG Die ServiceGroup wird mit Default-Werten für ihre Attribute angelegt.

22.1.2

hagrp –modify apacheSG SystemList nodeA 0 nodeB 1 Die ServiceGroup ist auf nodeA und nodeB prinzipiell lauffähig (Attribut SystemList). Zugleich bekommt nodeA eine höhere Priorität (0) als nodeB (1). hagrp –modify apacheSG Parallel 0 Die ServiceGroup wird als Failover-ServiceGroup eingerichtet (Attribut Parallel ist 0). Dieses Kommando kann auch entfallen, da eine Failover-ServiceGroup der Default ist. hagrp –modify apacheSG AutoStart 1 Das AutoStart-Flag der ServiceGroup zum automatischen Start durch VCS wird gesetzt. Auch dieses Kommando kann entfallen, da AutoStart per Default auf 1 steht. hagrp –modify apacheSG AutoStartList nodeA nodeB Das Attribut AutoStart ist nur wirksam, wenn AutoStartList definiert, welche Nodes für einen automatischen Start in Betracht kommen. hagrp –display apacheSG Kontrolle der ServiceGroup

22.2

IP-Resource IP-Resource l

Basisdevice IP-Adresse l Netzmaske l Optionale Parameter l Nähere Info im Bundles Agents Reference Guide l

22.2

Für die Schnittstelle zum Client wird, wie in den vorangehenden Kapiteln angesprochen, eine IP-Adresse auf einem virtuellen Interface eingerichtet. Für das Einrichten des virtuellen Interfaces und das Konfigurieren der gewünschten IP-Adresse auf dieses sind VCS-Resources vom Typ IP zuständig. Die notwendigen Befehle und Erläuterungen finden Sie in dem Kasten auf der rechten Seite. Wichtige Informationen zu IP-Resources l Als Device (Attributname Device) ist das Basisdevice anzugeben, nicht ein virtuelles Interface. Das virtuelle Interface wird durch die Online-Funktion der Resource dyna-

misch erzeugt. Die IP-Adresse (Attribut Address) wird immer numerisch angegeben, niemals als Hostname. Die Benutzung von Hostnamen könnte aufgrund der notwendigen Namensauflösung (DNS, LDAP etc.) zu Timeouts führen und damit die Funktionalität des Monitoring stören. l Die Netmask (Attribut NetMask) ist optional, ihre Verwendung ist aber sehr empfohlen, da sich die Netzmaske sonst aus dem Inhalt der Datei /etc/netmasks herleitet und sich diese von Node zu Node unterscheiden kann. Damit würde sich nach einer

22.2.1

l

195

22

APACHE WEB SERVER TEIL 1 Übernahme ein anderes Verhalten auf IPEbene ergeben als davor. Da solche Fehler sehr schwer zu finden sind, sollte im Zwei-

22.2.2

felsfall alles, was sich in die Clusterkonfiguration integrieren lässt, auch integriert werden.

Erzeugung und Konfiguration einer IP-Resource Wir erzeugen eine IP-Resource und setzen die notwendigen Parameter der Resource: Device, IPAdresse und Netmask. Am Schluss wird die Resource aktiviert, indem das Attribut Enabled auf 1 gesetzt wird. hares –add apache_ip IP apacheSG Die IP-Resource bekommt den Namen apache_ip, gehört zum ResourceType IP und wird der ServiceGroup apacheSG hinzugefügt. (!) Es ist nicht möglich, Resources ohne diese drei Informationen zu erzeugen, d.h. es gibt keine unbenannten Resources ohne ResourceType-Deklaration und außerhalb von ServiceGroups. hares –modify apache_ip Address A.B.C.D hares –modify apache_ip NetMask 255.255.255.0 IP-Adresse (Attribut Address) und Netzmaske (NetMask) werden spezifiziert. Die Angabe des Attributs NetMask ist zwar optional, im obigen Beispiel aber wegen des KlasseC-Subnets nötig. hares –modify apache_ip Device DeviceName VCS soll die IP-Adresse der ServiceGroup auf dem Interface (Device) qfe0 konfigurieren. hares –display apache_ip Kontrolle hares –modify apache_ip Enabled 1 Erst mit dem Enablen (Attribut Enabled) einer Resource fängt VCS mit dem Monitoring an. Vorher war der Zustand der Resource daher für VCS unbekannt. Folglich hätte VCS bisher keine onlineoder offline-Aktionen auf diese Resource zugelassen. Ist die erste Resource erfolgreich definiert und enabled, so kann man nicht nur die Resource, sondern auch die ServiceGroup online und offline nehmen und überwachen.

196

APACHE WEB SERVER TEIL 1

22

NIC-Resource

22.3 NIC-Resource l

Basis für IP-Resource NIC kontrolliert die Hardware, IP nur die Adresse selbst l Benötigt einkommende IPPakete für Tests l Benötigt daher Basisadresse im selben Subnetz wie Service-IPs Resource ist PERSISTENT l

22.3

Beim Konfigurieren der Resource für die IPAdresse der ServiceGroup wird, wie im vorigen Modul gezeigt, nur an einer Stelle ein Test auf das Netzwerk ausgeführt: Beim Onlining stellt der Agent fest, ob die IP-Adresse der Resource bereits im Netzwerk vorhanden ist, und beendet gegebenenfalls den Online-Versuch. Ist die IP-Adresse dagegen noch nicht vorhanden, so wird sie durch den Agent nun konfiguriert. Ob die Netzwerk-Verbindung überhaupt funktioniert (defektes Kabel, ausgefallener Switch o.ä.), spielt dabei keine Rolle. Die IP-Resource allein würde also nichts nützen; sie dient nur der Herstellung und Überwachung der richtigen Konfiguration, nicht jedoch der Überwachung der Netzwerk-Funktionalität. Für diese Überwachung stellt VCS die ResourceType NIC bereit. Um permanent, am besten unabhängig vom Zustand der ServiceGroups, die Netzwerk-Anbindung testen zu können, ist eine Test-IP-Adresse nötig, über die physischer Netzwerk-Verkehr erzeugt werden kann. Da für die ServiceGroups virtuelle Interfaces erzeugt werden, die eine ständig vorhandene Basis-IP-Adresse des physischen Interfaces voraussetzen, liegt es nahe, diese Basis-IP-Adresse, die bereits beim Booten über /etc/hostname.Inter face angelegt wird, zugleich als Test-IPAdresse zu verwenden. Damit sind Onlining und Offlining dieser Resource unnötig. Startet der Cluster und nimmt seine Resources online, so darf deren Startreihenfolge nicht

dem Zufall überlassen bleiben. Sonst würden kuriose Szenarien entstehen, in denen beispielsweise zunächst leere Directories exportiert (shared) werden, in die anschliessend versucht wird ein Volume zu mounten, das aber in einer noch nicht importierten DiskGroup liegt etc. Nichts davon würde funktionieren. Um eine Startreihenfolge vorzugeben, gäbe es prinzipiell den Weg, ein Script zu schreiben um alle Resources online zu nehmen. Dies wird auch von vielen Clustern so implementiert. Allerdings werden diese Scripts schnell unhandlich gross und enthalten oft Fehler. Besonders wenn während des online- oder offline gehens Fehler auftreten, ist ein sauberes Stoppen oft nicht mehr korrekt implementiert. Der VCS-Cluster geht daher einen anderen Weg: Die logischen Abhängigkeiten der Resources voneinander werden dem Cluster bekanntgegeben, und die Start- und Stopreihenfolge wird vom had zur Laufzeit ermittelt. Die Abhängigkeiten werden als Dependencies zwischen Parent- und Child-Resource mit dem Kommando hares -link Parent Child definiert, mit hares -unlink Parent Child wieder aufgehoben und mit hares dep ResName angezeigt. Dabei hängt die Parent-Resource von der Child-Resource ab. IP-Resourcen benötigen ein funktionierendes Interface, deshalb wird die IP-Resource als Parent einer NIC-Resource definiert; beide enthalten ein Attribut namens Device, der die Hardware identifiziert, etwa ce2.

22.3.1

197

22 22.3.2

APACHE WEB SERVER TEIL 1 Aufbau der NIC-Resource: l Welches Interface soll als Zugang zum gewünschten Netzwerk ausgewählt werden? l Kontrolle: Existiert für das Interface die Konfigurationsdatei /etc/hostname.Interface? hares –add apache_nic NIC apacheSG hares –modify apache_nic Device qfe0 hares –display apache_nic (?) Welchen Resource- und ServiceGroup-Zustand zeigen hastatus und die GUI jetzt an, wenn die IP-Resource ONLINE bzw. OFFLINE ist? VCS-Aktionen: hares –modify apache_nic Enabled 1 hastatus –group apacheSG hagrp –state apacheSG hares –state apache_nic Die ServiceGroup hat jetzt auf beiden Nodes den Zustand, den die Resource apache_ip jeweils hat.

22.3.3

198

Operations-Attribut: NIC setzt die Existenz der Basis-IP-Adresse eines Interfaces voraus und konfiguriert sie nicht selbst. Daher stellt der NIC-Agent lediglich fest, ob das Interface Netzwerk-Kommunikation zulässt oder nicht. Der Agent führt nur den monitor-EntryPoint aus; online, offline und clean fehlen. Ein solcher ResourceType hat das Attribut Operations auf None gesetzt und heißt persistent im Unterschied beispielsweise zu IP (OnOff, non-persistent). Selten ist noch ein dritter Typ realisiert: VCS darf eine Resource online, aber nicht offline bringen (OnOnly, ebenfalls persistent). Dies ist immer dann der Fall, wenn es sich um systemglobale Resourcen handelt, z.B. den NFS-Daemon. Diese könnten in mehreren ServiceGroups benötigt werden. Das Stoppen einer ServiceGroup mit einer solchen Resource darf nicht zum Stoppen der systemglobalen Resource führen, da diese dann in den anderen ServiceGroups als FAULTED gemeldet würde. Eine Instanz persistenter ResourceTypes darf (und soll) prinzipiell auf mehreren Nodes im Cluster online sein.

(!) Da bei persistenten ResourceTypes VCS Offlining nicht möglich ist, dürfen solche Resources nicht von anderen abhängig sein. Sie sind stets online, also definitiv unabhängig von anderen. (!) Persistente ResourceTypes vom OperationsTyp None beziehen sich sinnvollerweise unmittelbar auf Hardware-Bestandteile. Da der Agent den Zustand OFFLINE nicht kennt, meldet VCS-Monitoring nach einer Reparatur der defekten Hardware sofort die betroffene Resource als ONLINE und macht damit ein Clear der FAULTED Resource unmöglich. Ist das ServiceGroup-Attribut AutoRestart gesetzt (so der Default), wird, wenn möglich, auch die entsprechende ServiceGroup wieder online gebracht. Wenn man nicht auf den nächsten zyklischen Monitor warten will, kann man ihn außerplanmäßig starten mit hares –probe Resource –sys Node

APACHE WEB SERVER TEIL 1

22

ResourceType-Attribute

22.4 ResourceType Attribute l

Steuern das Verhalten aller Resources des Types l Ein Standardsatz von Attributen l Geeignete Werte modellieren nahezu jedes mögliche Verhalten l Attribute können pro Resource überschrieben werden und sind dann nicht mehr global

22.4

VCS führt über die Agents nicht nur initiierendes, sondern auch zyklisches Monitoring der Resources aus, um auftretende Fehler zu registrieren. Aus dem vorigen Abschnitt (AutoClear von persistenten Resources vom Typ None) war ersichtlich, dass auch Resources im OFFLINE-Zustand beobachtet werden. Das Interval des zyklischen Monitorings kann über zwei Agent-Attribute für jeden ResourceType bestimmt und modifiziert werden: MonitorInterval (wenn die Resource als ONLINE gilt; Default 60 sek.), OfflineMonitorInterval (OFFLINE; Default 300 sek.). hatype –value ResourceType MonitorInterval 60 hatype –value ResourceType OfflineMonitorInterval 300 hatype –modify ResourceType MonitorInterval 20 hatype –modify ResourceType OfflineMonitorInterval 60

22.4.1

Viele Agents liefern sinnlose Ergebnisse, wenn während eines hängenden Monitor-Prozesses (z.B. NIC in einem überlasteten Netz) bereits das nächste Monitoring auf die gleiche Resource startet. Daher muss der hängende Monitor-Prozess zwangsweise zuvor vom Agent beendet werden. MonitorTimeout (Default: 60 sek.) sollte also gleich oder kürzer als das Minimum von MonitorInterval und OfflineMonitorInterval sein. hatype –value ResourceType MonitorTimeout 60 hatype –modify ResourceType MonitorTimeout 20 Das Beenden eines Monitor-Prozesses per MonitorTimeout wird vom Agent nicht sofort als Fehler interpretiert, sondern erst nach 4 aufeinanderfolgenden Timeouts. Auch dieser Wert (Attribut FaultOnMonitorTimeouts; Default 4) kann konfiguriert werden. hatype –value ResourceType FaultOnMonitorTimeouts hatype –modify ResourceType FaultOnMonitorTimeouts 2 Änderungen an den ResourceTypes wirken sich stets auf alle Resources dieses Types aus. Verlangt die Anwendung unterschiedliche Attributwerte für einzelne Instanzen eines ResourceTypes, so kann man Type-spezifische Attribute für einzelne Resources überschreiben. Der Befehl dafür lautet hares -override ResName AttributName. Anschliessend kann man den Attributwert mit hares -modify ResName setzen. Beispiel: hares -override MyNIC MonitorInterval; hares -modify MyNIC MonitorInterval 10

199

22

APACHE WEB SERVER TEIL 1 Das Ganze lässt sich mit hares -undo_override ResName AttributeName wieder rückgängig machen. Beispiel: hares -undo_override MyNIC MonitorInterval

22.4.2

Auf diese Weise lassen sich also ResourceTypespezifische Attribute sowohl global für den ResourceType als auch wahlweise lokal für einzelne Resources ändern und so gemäß dem aktuellen Bedarf gestalten. Was aber sind die wichtigsten ResourceType-spezifischen Attribute? Wir haben hier die wichtigsten zusammengestellt, mit den üblichen Default-Werten in Klammern. Einige ResourceTypes können andere Default-Werte haben. Sollten Sie sich für weitere Attribute interessieren, so wäre dies ein weiteres Anwendungsgebiet für das hagui. Dort bekommen Sie nach Doppelklick auf eine Resource oder ResourceType zunächst die Standard-Attribute, können dann aber durch Abhaken der „Show all properties“ Checkbox sämtliche Attribute anschauen. Wenn Sie in diesem Dialog auf einen Attributnamen klicken, bekommen Sie im oberen Bereich des Fensters eine Erläuterung des Attributs eingeblendet. MonitorInterval (60) > Anzahl Sekunden zwischen zwei aufeinanderfolgenden MonitorZyklen für eine Resource, die zuletzt im Zustand ONLINE war. OfflineMonitorInterval (300) > Anzahl Sekunden zwischen zwei aufeinanderfolgenden Monitor-Zyklen für eine Resource, die zuletzt im Zustand OFFLINE war. NumThreads (10) > Maximale Anzahl gleichzeitig laufender Threads des selben Entry-Point des Agents. Default ist 10 für alle ResourceTypes. Dies kann bei Benutzung mehrerer schwergewichtiger Applikationen Probleme verursachen. So würde zum Beispiel bei der (kostenpflichtigen) Oracle-ResourceType ein unveränderter Wert von NumThreads dazu führen, dass bis zu zehn Instanzen von Oracle gleichzeitig gestartet werden können, was spätestens bei einem Post-Crash-Szenario durch das parallele Recovery von zehn Datenbanken die Maschine überlasten dürfte. MonitorTimeout (60) > Anzahl Sekunden

200

nach Start eines Monitor-Zyklus, bevor der zu diesem Zyklus gehörende Thread abgebrochen wird. Dieser Abbruch erhöht einen internen Zähler, der so lange hochzählt bis der Wert von FaultOnMonitorTimeouts erreicht ist. FaultOnMonitorTimeouts (4) > Anzahl aufeinanderfolgender Monitor-Zyklen, die durch Timeout abgebrochen werden, bevor der Agent die betreffende Resource als UNEXPECTED OFFLINE deklariert und das normale FaultHandling einleitet (Clean aufrufen, evtl. Restart oder Failover einleiten etc.) ToleranceLimit (0) > Anzahl aufeinanderfolgender Monitor-Zyklen, die unerwartet OFFLINE liefern dürfen, bevor der Agent die Resource als UNEXPECTED OFFLINE deklariert und das normale Fault-Handling einleitet. RestartLimit (0) > Anzahl von Versuchen, die der Agent unternimmt, um eine als UNEXPECTED OFFLINE erkannnte Resource durch einen Neustart wiederzubeleben. Ist beispielsweise das RestartLimit auf zwei gesetzt und geht eine Resource auf UNEXPECTED OFFLINE, so startet der Agent sie zwei Male neu, bevor er „aufgibt“ und die Resource endgültig als FAULTED deklariert. ConfInterval (600) > Das Zeitintervall, das eine Resource nach irgendeinem Restartversuch ONLINE bleiben muss, um den internen Zähler für das RestartLimit wieder auf Null zurückzusetzen. Der Default-Wert entspricht zehn Minuten. OnlineRetryLimit (0) > Die Anzahl Versuche, die der Agent unternimmt, um beim Onlining eine Resource zu starten. Im Grunde ist dieses Attribut ähnlich wie das RestartLimit, aber das OnlineRetryLimit git nur während des Onlinings (wird alos ab dem ersten ONLINE vom Monitor-Zyklus nicht mehr berücksichtigt, während RestartLimit auch dann gilt, wenn die Resource bereits seit geraumer Zeit läuft).

APACHE WEB SERVER TEIL 1

22

Übersicht und Struktur der ha-Befehle

22.5

ha

grp res sys type user clus attr

-add -delete -modify -list -display -value

grp res sys

-online -offline -switch -clear -freeze [-persistent] -unfreeze [-persistent]

ResourceType Befehlsstruktur VCS l Alle VCS-Befehle beginnen Attribute

22.5.1

mit dem Kürzel ha Steuern das Als nächstes kommt der Verhalten aller res, grp, type… Datentyp: Resources des l Standardsatz von Types Switches Kommandos von l für Einviele Standardsatz l Auch seltenere Switches Attributen sind standardisiert l Geeignetevon Werte l Ausnahmen der Befehlsstruktur: LLT- und modellieren naheGAB-Befehle zu jedes mögliche l hastop -all -force kann gefährlich sein 7·4 l Vor Änderung der Konfiguration muss diese geöffnet und anschliessend wieder geschlossen werden l l

start [-stale] stop -[local|all|sys] [-force|evacuate] status [-sum] conf -[makerw|dump -makero] cf -[verify|cmdtocf] Die VCS Kommandostruktur ist so systematisch aufgebaut, dass sie sehr leicht zu erlernen ist. Am Anfang steht immer das Kürzel ha für High Availability. Dem folgt ein Identifier für den Datentyp bzw. die Aktion, z.B. res für Resource, grp für ServiceGroup oder start/stop/ status für den Start, Stop oder die Überwachung von VCS. Die Switches -add, delete, -modify, -list, -display, -value dienen der Konfiguration bzw. Abfrage der Objekte, während die Switches -online, -offline, switch, -clear, -freeze und unfreeze das Online-Offline-Verhalten beeinflussen. Die Letzteren sind daher nicht bei allen Datentypen möglich, sondern nur bei Resources, ServiceGroups und zum Teil noch Systems. Es gibt noch weitere, allerdings seltener benutzte Befehle in $VCSBIN.

22.5

hastop und Die Befehle hastart, hastatus sind selbsterklärend, während zu haconf und hacf eine kurze Erläuterung nötig ist: Der Befehl haconf ändert den Zustand der Configuration; er dient zum Öffnen und Schließen derselben. Der Befehl hacf hingegen arbeitet auf den Configuration File (main.cf). Dies ist ein ganz spezieller Befehl insofern, als er als einziger Befehl ausser hastart keinen laufenden had voraussetzt. Er bearbeitet nicht die in Memory befindliche Kopie der Konfiguration, sondern direkt das File main.cf. Er wird vor allem für zwei Dinge benutzt: erstens zum Checken der Syntax einer manuell geänderten Datei main.cf. Zweitens um aus der main.cf-Syntax Clusterbefehle zu generieren, die ein gewünschtes Objekt aufbauen. Beispiele sind der Aufbau eines neuen ResourceTypes oder einer ServiceGroup aus einer anderen main.cf-Datei.

201

22 Ü 22

202

APACHE WEB SERVER TEIL 1 Übung: ApacheSG und Netzwerk-Resources Übung l ApacheSG anlegen · Attribute definieren l ApacheSGIP anlegen · Attribute definieren l ApacheSGNIC anlegen · Attribute definieren l Abhängigkeiten definieren l Enablen nicht vergessen

l ServiceGroup testen

Erzeugung und Konfiguration einer IPResource Bauen Sie per CLI die ServiceGroup apacheSG und ihre Resource apache_ip wie oben dargestellt bis zum Enablen der Resource einschließlich auf. Lassen Sie sich vom Trainer Interface, IP-Adresse und Netzmaske nennen. Kontrollieren Sie hier und im folgenden per GUI das Ergebnis der Kommandos. Lassen Sie außerdem in einem eigenen Terminal hastatus laufen. Ab wann zeigt der hastatus-Output die Existenz und den Zustand von ServiceGroup und Resource an? Warum ist das so? Spielen Sie mit den Kommandos hagrp – online | -offline | -switch und hares –online | -offline. Beachten Sie insbesondere die Fehlermeldung, wenn Sie per VCS die ServiceGroup auf nodeA online bringen und dann auf nodeB einen weiteren Online-Versuch starten. Starten Sie jetzt einen Browser mit Zugang zum Trainingsnetz (z.B. auf einem Node mit / usr/dt/bin/netscape) und geben Sie als URL die (virtuelle) Adresse der ServiceGroup

ein. Der Apache-Webserver-Prozess läuft bereits aufgrund einer Standard-Konfigurationsdatei /etc/apache/httpd.conf und des RC-Skriptes /etc/rc3.d/S50apache. Auf dieser Seite sehen Sie einen Link, über den Sie sich die aktuelle Uhrzeit anzeigen lassen können (html- bzw. Perl-Skripte /var/apache/htdocs/index.html und /var/ apache/cgi-bin/showtime.pl). Stellen Sie mit hagrp –state apacheSG und ifconfig IF fest, auf welchem Node und auf welchem virtuellen Interface die IP-Adresse online ist. Entfernen Sie mit ifconfig VirtIF unplumb diese IP-Adresse. Wenn Sie jetzt einen BrowserRefresh starten, kommt nach einiger Zeit entweder eine Fehlermeldung, oder VCS hat bereits den Failover durchgeführt (nach spätestens 60 sek.). Welche Fehlermeldung erscheint, wenn Sie die ServiceGroup durch VCS-Befehle wieder auf den ersten Node zurückswitchen wollen? Beseitigen Sie die Ursache der Fehlermeldung und führen Sie dann den Switch aus.

· hagrp -online … · hagrp -offline … · hagrp -switch … · pkill … l Überwachen · hagrp -state … · hastatus … · hagui

APACHE WEB SERVER TEIL 1

22

Steuerung und Überwachung der ServiceGroup hastatus –group apacheSG hagrp –state apacheSG hares –state apache_ip Die ServiceGroup ist auf beiden Nodes im Zustand OFFLINE, ebenso die Resource apache_ip. hagrp –online apacheSG –sys nodeA Auf dem System nodeA wird die ServiceGroup insgesamt online gebracht. hagrp –switch apacheSG –to nodeB Die ServiceGroup wird auf nodeA heruntergefahren und anschließend auf nodeB online gebracht. hagrp –offline apacheSG –sys nodeB Die ServiceGroup wird komplett auf nodeB heruntergefahren. hares –online apache_ip –sys nodeA Die Resource apache_ip wird auf nodeA online gebracht. Die ServiceGroup gilt als ONLINE. hares –offline apache_ip –sys nodeA Die Resource wird wieder offline gesetzt. Auch die ServiceGroup ist jetzt offline.

22.6

Kommandos für ServiceGroups und Resources Instanzen erzeugen: hagrp –add ServiceGroup hares –add Resource ResourceType ServiceGroup Attribut-Werte ändern: hagrp –modify ServiceGroup Attribut Wert hares –modify Resource Attribut Wert Attribut-Werte anzeigen: hagrp –display [ServiceGroup] hagrp –value ServiceGroup Attribut hares –display [Resource] hares –value Resource Attribut Instanzen löschen: hagrp –delete ServiceGroup (nur bei leeren ServiceGroups) hares –delete Resource Instanzen online / offline bringen: hagrp –online ServiceGroup –sys Node hagrp –offline ServiceGroup –sys Node hagrp –switch ServiceGroup –to Node hares –online Resource –sys Node hares –offline Resource –sys Node Instanzen bereinigen nach einem Fehler: hares –clear Resource [-sys Node] hagrp –clear ServiceGroup [-sys Node]

22.6

203

22

APACHE WEB SERVER TEIL 1 Verständnisfrage 22.1 Können Sie mit Ihrem aktuellen Wissensstand einen Unterschied ermitteln, ob die ServiceGroup mit dem Kommando hagrp –online ... oder mit hares –online ... hochgefahren wurde (entsprechend auch beim Herunterfahren)?

Verständnisfrage 22.2 Warum wird das ausdrückliche Setzen der Netmask in der IP-Resource stark empfohlen? Das Betriebssystem kann doch eindeutig die richtige Netmask zu einer gegebenen IPAdresse ermitteln.

204

APACHE WEB SERVER TEIL 1

22

Musterlösung und Antworten zu Verständnisfragen

Ü 22

hagrp –add apacheSG hagrp –modify apacheSG SystemList nodeA 0 nodeB 1 hagrp –modify apacheSG AutoStartList nodeA nodeB hares –add apache_ip IP apacheSG hares –modify apache_ip Address 192.168.1.100 hares –modify apache_ip NetMask 255.255.255.0 hares –modify apache_ip Device qfe0 hares –modify apache_ip Enabled 1 hares –add apache_nic NIC apacheSG; hares -link apache_ip apache_nic hares –modify apache_nic Device qfe0 hares –modify apache_nic Enabled 1 Die ServiceGroup gilt mit ihrem Anlegen als OFFLINE, weil in ihr keine Resource existiert, die für VCS ONLINE sein könnte. Erst mit dem Enablen der Resource kann der Agent Monitoring ausführen und VCS den Zustand der Resource melden und mit hastatus anzeigen: Sie ist noch OFFLINE. hagrp –state #Group apacheSG apacheSG

apacheSG Attribute State State

System nodeA nodeB

Value |ONLINE| |OFFLINE|

ifconfig qfe0 [...] qfe0:1: flags=1000843 mtu 1500 index 2 inet 192.168.1.100 netmask ffffff00 broadcast 192.168.1.255 ifconfig qfe0:1 unplumb Fehlererkennung und Failover durch VCS abwarten. hagrp –switch apacheSG –to nodeA -> ##Fehlermeldung## hares –clear apache_ip –sys nodeA hagrp –switch apacheSG –to nodeA

Verständnisfrage 22.1 Können Sie mit Ihrem aktuellen Wissensstand einen Unterschied ermitteln, ob die ServiceGroup mit dem Kommando hagrp –online ... oder mit hares –online ... hochgefahren wurde (entsprechend auch beim Herunterfahren)? Derzeit ist kein Unterschied erkennbar: Der Ergebniszustand der ServiceGroup ist in beiden Fällen ONLINE (OFFLINE). Erst später bei den Event-Triggers wird sich eine Abweichung ergeben.

Verständnisfrage 22.2 Warum wird das ausdrückliche Setzen der Netmask in der IP-Resource stark empfohlen? Das Betriebssystem kann doch eindeutig die richtige Netmask zu einer gegebenen IP-Adresse ermitteln. Die Netmask soll in der IP-Resource explizit gesetzt werden, weil sie sonst aus der Datei /etc/netmasks ermittelt werden würde. Diese Datei kann aber bei den einzelnen Knoten des Clusters unterschiedlich sein und damit zu ortsabhängigem Verhalten der Resource führen. Generell ist is immer besser, dem Betriebssystem so wenig Einfluss wie möglich auf die im Cluster definierten Resoucen zu gestatten, um Überschneidungen und alternative Konfigurationen wie bei Netmasks auszuschliessen. Dies gilt zum Beispiel auch für vom Cluster verwaltete DiskGroups, Volumes und Mountpoints.

205

KAPITEL 23

APACHE WEB SERVER TEIL 2 FILE- & PROZESSRESOURCES

23 23.1

APACHE WEB SERVER TEIL 2 Process-Resource Process-Resource l

Startet einen Prozess Überwacht den Zustand des gestarteten Prozesses l Apache sorgt selbst für das Nachstarten beendeter Kindprozesse l Prozess muss aus BootScripts (/etc/rc*.d) entfernt werden! l

23.1

23.1.1

Problem: Bisher hatte VCS noch keine Information darüber, dass es auch den Apache-Serverprozess /usr/apache/bin/httpd kontrollieren soll. Stürzt dieser Prozess ab, haben die Browser-Clients keinen Zugriff auf den Server mehr, trotz bestehender IP-Adresse. Vorüberlegungen: Der Apache-Serverprozess kann nur sinnvoll gestartet werden, wenn seine Konfigurationsdatei /etc/apache/httpd.conf existiert. Wir werden zunächst eine einfache Standard-Konfiguration wählen und dieser Datei später mehr Aufmerksamkeit widmen. Der Hauptprozess /usr/apache/bin/ httpd startet einige httpd-Childprozesse und

23.1.2

Monitoring einer Process-Resource: Laut Veritas-Dokumentation führt der ProcessAgent Monitoring durch eine Suche nach Pfadnamen und Argumenten des Prozesses in der Prozesstabelle durch. Das ist jedoch nicht ganz richtig. Lediglich das erste Monitoring, das die Resource als ONLINE meldet, geht so vor und merkt sich dabei zugleich die PID (protokolliert im lokalen Agent-Log /var/ VRTSvcs/log/Process_A.log: Setting cookie to ...). Ab jetzt wird performanter nur noch nach der Existenz eines Prozesses mit dieser PID gesucht. Dieses Verhalten setzt Rahmenbedingungen für den Einsatz von Process-Resources. Man sollte sich zuvor folgende Fragen stellen: Welche Konsequenzen ergeben sich aus diesem Verfahren, wenn wie beim Apache-

208

kann diese nötigenfalls auch nachstarten. Wir werden daher nur den Hauptprozess - erkennbar an der User-ID 0 (root) und an init (PID 1) als seinem Parentprozess – unter VCS-Kontrolle bringen. Das Einrichten einer Process-Resource ist schon vom einführenden Teil her bekannt. Neu ist hier, dass es sich um einen Prozess handelt, der normalerweise bereits vom Betriebssystem gestartet wird und nun unter Clusterkontrolle kommen soll. Denn durch das Betriebssystem läuft der Prozess bereits auf allen Knoten, clusterseitig soll er aber nur auf einem einzelnen Knoten laufen, da er sich in einer FailoverServiceGroup befindet (Parallel=0).

Webserver der Hauptprozess mehrere im Blick auf Pfadnamen und Argumente identische Child-Prozesse nachstartet? Wie sicher ist dieses Monitor-Verfahren generell? Wie wird wohl VCS reagieren, wenn man zwischen zwei Monitor-Zyklen den Prozess beendet und mit gleichen Parametern manuell startet? Ist dies bei der verwendeten Applikation ein Problem oder nicht? Wie eindeutig ist die Identifizierung eines Prozesses allein über seinen Pfadnamen und seine Optionen, Argumente und Parameter, und zwar mithilfe des Kommandos /usr/ bin/ps? Beachten Sie dabei die Grenzen dieses ps-Kommandos und den Kontext eines Prozesses.

APACHE WEB SERVER TEIL 2

23

Alle Attribute von Process auf einen Blick:

23.1.3

Attribut

Typ

muss?

Beschreibung

Beispiel

PathName Arguments

str/scalar

ja

Pfadname des Executables

str/scalar

nein

Optionen, Argumente, Parameter

/usr/sbin/inetd -s

Default

23.2

Concurrency Violation Concurrency Violation l

OnOff-Resources einer Failover-Gruppe dürfen höchstens auf einem System online sein l Sonst muss VCS mit Datenkorruption rechnen l Erkennt VCS eine C.V., so wird der Zustand bereinigt und der violation-Trigger gestartet

23.2

23.2.1

Concurrency Violation: In einer Failover-ServiceGroup darf eine Resource vom Operations-Typ OnOff maximal auf einem Node zur gleichen Zeit ONLINE sein. Im obigen Beispiel traf das für httpd nicht zu, da dieser Prozess außerhalb der VCSKontrolle gestartet wurde. Für einen Cluster ist diese „Concurrency Violation“ genannte Situation der schlimmstmögliche Fehlerfall, weil z.B. die Konsistenz von Applikationsdaten auf Disk hochgradig gefährdet ist. Immerhin kann VCS hier wegen funktionierender Heartbeat-Kommunikation den Konflikt erkennen und sofort bereinigen: Alle betroffenen ServiceGroups werden außer auf einem Node sofort offline gebracht. Dafür ist das EventTrigger-Skript /opt/VRTSvcs/bin/ triggers/violation zuständig (zu EventTriggers später mehr). Da der Cluster nicht wissen kann, ob ein gleichzeitiger Betrieb einer Resource auf mehreren Knoten gefährlich sein könnte, verhindert er diesen Fall generell. Die Integration des httpd warf das Problem auf, dass jeder Node beim Booten durch ein

RC-Skript bereits eine Resource physisch gestartet hatte, die eigentlich VCS nur auf einem Node hätte online bringen sollen. Generell gilt aber, dass alles, was VCS kontrolliert, auch nur durch VCS gestartet werden soll. Das trifft nicht nur für RC-Skripte wie /etc/ rc3.d/S50apache zu, sondern auch für einige weitere Konfigurationsdateien: /etc/vfstab zum Mounten, /etc/dfs/dfstab für NFS-Shares (auch nicht, um die NFS-Serverprozesse zu starten, dafür ist eine NFS-Resource zuständig), /etc/hostname.virtIF für die ApplikationsIP-Adresse, usw. Auch das autoimport-Flag einer VxVM-DiskGroup sollte nicht gesetzt sein (siehe später). Solche Dateien können nicht nur Concurrency Violation erzeugen, sondern auch das automatische Onlining durch VCS verhindern: Der Boot-Prozess hat über /etc/vfstab ein Filesystem auf Node B gemountet, VCS muss aber wegen AutoStartList und der Priorität in der SystemList die entsprechende ServiceGroup auf Node A online bringen, was scheitert.

209

23 23.3

APACHE WEB SERVER TEIL 2 FileNone-Resource FileNone-Resource l

Prüft Existenz eines Files Operations-Type NONE l Löst keine Concurrency Violation aus, da nicht OperationsTyp OnOff l Nur ein Attribut: PathName l Weitere, ähnliche Typen: – ElifNone – FileOnOff – FileOnOnly l

23.1

23.3.1

Problem: Es ist nicht sinnvoll, httpd zu starten, wenn die Konfigurationsdatei /etc/apache/httpd. conf fehlt. Wir wollen daher in diesem Modul das Starten des httpd-Prozesses davon abhängig machen, ob seine Konfigurationsdatei existiert oder nicht. Vorüberlegungen: VCS soll nur testen, ob die Datei /etc/apache/httpd.conf existiert oder nicht. Daraus

23.3.2

Verwendung von File-Resources: Die File-ResourcesType gibt es in vier Ausprägungen: FileOnOff, FileOnOnly, FileNone und ElifNone. Die Anhängsel hinter „File“ entsprechen dem Operations-Typ, von dem die entsprechendie File-Resource ist. Somit ist FileOnOff eine non-persistent Resource vom Operations-Typ OnOff, FileNone jedoch eine persistent Resource vom Operations-Typ None. Der Online-EntryPoint von FileOnOff führt touch auf das File mit dem in PathName hinterlegten Pfadnamen aus, der MonitorEntryPoint überwacht die Existenz des Files. Der Monitor-EntryPoint liefert ONLINE, wenn die Datei existiert, und OFFLINE, wenn sie fehlt. Das kann zu einem Resource-Fault und ServiceGroup-Failover führen (abhängig von anderen Attributen wie Critical, RestartLimit etc.). Der Offline-EntryPoint von FileOnOff löscht die Datei, was in unserem Beispiel

210

geht hervor, dass es sich um einen ResourceType mit dem Operations-Attribut None handeln muss. Zweitens wollen wir die Kontrolle über den korrekten Inhalt der Konfigurationsdatei der Apache-Applikation überlassen. Da keine weitergehende Funktionalität nötig ist, können wir also die Standard-Resource FileNone benutzen.

sicher nicht gewünscht ist, da damit unsere Apache-Konfigurationsdatei (httpd.conf) gelöscht würde. Wir verwenden stattdessen FileNone. Dieser ResourceType überwacht lediglich die Existenz des Datei, würde also einen Start von Apache ohne Konfigurationsdatei verhindern. Der ResourceType ElifNone (Elif=File rückwärts) prüft auf das Fehlen der Datei, benutzt also die umgekehrte Logik. FileOnOnly legt beim Onlining die Datei an und überwacht sie, löscht sie aber beim Offlining nicht. Da für jeden Operations-Typ ein passender FileResourceType zur Verfügung steht, lassen sich File-Resources gut als Platzhalter für komplexere Resources einsetzen, um Testfälle durchzuspielen oder Dinge wie RestartLimit etc. auszuprobieren.

APACHE WEB SERVER TEIL 2

23

Alle Attribute der File-ResourceTypes auf einen Blick:

23.3.3

Attribut

Typ

muss?

Beschreibung

Beispiel

PathName

str/scalar

ja

Pfadname des Files

/var/run/$ResName

Default

Ü 23

Übung Übung

l

l

l

ApacheSGProcess anlegen · Attribute definieren l ApacheSGFileOnOnly anlegen · Attribute definieren l Abhängigkeiten definieren

Enablen nicht vergessen! ServiceGroup testen · hagrp -online … · hagrp -offline … · hagrp -switch … · pkill …

Fügen Sie der apacheSG eine Process-Resource hinzu, die den httpd-Daemon kontrollieren soll: PathName /usr/apache/bin/httpd, keine Arguments. Die IP-Resource soll auch von der Process-Resource abhängig sein. Wenn Sie jetzt die Process-Resource enablen, beobachten Sie genau den Output von hastatus –group apacheSG . Beschreiben Sie, was passiert. Wissen Sie eine Erklärung dafür? Bringen Sie ggf. die ServiceGroup auf einem Node online. Welchen httpd-Prozess beobachtet der Process-Agent jetzt über dessen PID (aus /var/VRTSvcs/log/Process_A.log)? Wenn es nicht der Hauptprozess ist: Beenden Sie ihn mit kill PID und beobachten Sie über den hastatus-Output und den Agent-Log das Verhalten von VCS. Fügen Sie der apacheSG eine FileNone-Resource hinzu, um die httpd-Konfigurationsdatei / etc/apache/httpd.conf zu kontrollieren. Konfigurieren Sie diese Resource als Child-Resource zur Process-Resource und enablen Sie sie.

211

23 Ü 23

APACHE WEB SERVER TEIL 2 Musterlösung hares hares hares hares

–add apache_process Process apacheSG –modify apache_process PathName /usr/apache/bin/httpd –link apache_ip apache_process –modify apache_process Enabled 1

Die neue Resource wird kurzzeitig auf beiden Nodes als ONLINE angezeigt. Sofort danach bringt der EventTrigger violation die ServiceGroup auf einem Node offline. hagrp –online apacheSG –sys nodeA (warten) kill PID Der Hauptprozess restartet sofort einen httpd-Childprozess. Der Agent-Log zeigt, dass monitor sich einfach durch Analyse der Prozesstabelle die PID eines neuen httpd-Prozesses merkt. Der Zustand der Resource bleibt ONLINE, da alles innerhalb des monitor-EntryPoints geregelt wird. hares hares hares hares

212

–add apache_filenone FileNone apacheSG –modify apache_filenone PathName /etc/apache/httpd.conf –link apache_process apache_filenone –modify apache_filenone Enabled 1

KAPITEL 24

APACHE WEB-SERVER TEIL 3 APPLICATION, MOUNT, DISK

24 24.1

APACHE WEB-SERVER TEIL 3 Application-Resource Application-Resource l

Kontrolliert Prozesse Wesentlich flexibler als Process l Verschiedene MonitoringVarianten möglich l Kann Boot-Scripts (/etc/ rc*.d) für Start und Stopp verwenden l Dadurch Applikationslogik komplett verfügbar l

24.1

24.1.1

Problem Bisher wurde der Test auf Existenz des ConfigFiles von einer FileNone-Resource erledigt und der Start des Daemons durch eine ProcessResource. Das Start-Script des Apache-Servers prüft allerdings ebenfalls die Existenz der

Konfiguration, tut aber noch einiges mehr als das. Warum soll VCS also nicht einfach das Start-Script des Apache-Servers für das Onlining verwenden?

Lösung Für komplexere Anwendungen stellt VCS den ResourceType Application bereit. Dieser erlaubt nicht nur, individuelle Start- und Stopscripte mit ihren jeweiligen Kommandozeilenparametern zu definieren, sondern auch, die Prozesse unter einer bestimmten User-ID auszuführen. Ausserdem werden drei verschiedene Arten von Monitoring unterstützt: das Attribut MonitorProcesses enthält eine Liste von Strings, nach denen in der Prozessliste gesucht wird und PidFiles eine Liste von Dateien, die abgelegte Prozess-IDs enthalten. Beide Attribute ergänzen sich, sind also in Kombination möglich. Alternativ kann auch das Attribut MonitorProgram mit dem Pfad zu einem eigenständigen Überwachungsprogramm gefüllt werden. Dieses Programm sorgt dann allein für die Überwachung. Die Attribute PidFiles und MonitorProcesses werden bei gesetztem

214

MonitorProgram nicht mehr verwendet. Da das existierende Startscript zwar durch VCS verwendet, andererseits aber nicht beim Booten gestartet werden soll, muss der symbolische Link in /etc/rc3.d gelöscht werden. In die VCS-Konfiguration wird dann der Pfadname des eigentlichen Scripts in /etc/ init.d als StartProgram bzw. StopProgram und CleanProgram eingetragen (jeweils mit dem richtigen Kommandozeilen-Parameter, um die entsprechende Funktion auszuwählen). Um die Funktionalität des Apache-Servers zu überprüfen (Monitoring), tragen wir entweder den Pfadnamen der Prozesse in das Attribut MonitorProcesses ein, oder wir füllen das Attribut PidFiles mit dem Pfad /var/run/ httpd.pid.

APACHE WEB-SERVER TEIL 3

24

Alle Attribute der Application-ResourceType auf einen Blick:

24.1.2

Attribut

Typ

muss?

Beschreibung

Beispiel

User StartProgram StopProgram CleanProgram MonitorProgram PidFiles MonitorProcesses ContainerName

str/scalar

nein

User-ID, unter der gestartet wird

str/scalar

ja

Kommandozeile zum Starten

str/scalar

ja

Kommandozeile zum Stoppen

str/scalar

nein

Kommandozeile zum Aufräumen

root abahachi /etc/init.d/httpd start /etc/init.d/httpd stop /etc/init.d/httpd stop

Default

str/scalar

nein

Kommandozeile zum Überwachen

str/array

nein

Pfadname des Executables

str/scalar

nein

Optionen, Argumente, Parameter

str/scalar

nein

Solaris-Zone

/var/run/httpd.pid /usr/apache/bin/httpd zone1

24.2

Mount-Resource Mount-Resource l

Mountet Dateisysteme Funktioniert seit 4.0 auch mit NFS-Mounts! l Zieldirectory muss existieren l Kann Partitionen, Volumes und Metadevices mounten l Kann ufs, vxfs und nfs mounten l

24.2

24.2.1

Problem Die normalerweise auf shared Storage befindlichen Programme, Konfigurationen und Daten müssen in die ServiceGroup eingebracht wer-

den, damit sie gemeinsam mit den Prozessen auf einen anderen Host migrieren können.

Lösung Der VCS Cluster stellt einige Resource-Typen bereit, die für shared Storage geeignet sind. In der Resources-Hierarchie einer Service-Group abwärts gehend sind dies: l Share – Exportieren des Inhalts eines Directories über NFS l Mount – Mounten eines Filesystem in ein bestehendes Verzeichnis l Disk – Überprüfen des Zugriffs auf eine Partition l Volume – Inbetriebnahme eines VxVMVolumes

l

DiskGroup – Importieren einer VxVMDiskGroup l DiskReservation – Reservierung von DiskTargets per SCSI-Kommando Die Disk-Resource wird bei Benutzung von VxVM für den shared Storage durch eine Kombination aus DiskGroup- und VolumeResource ersetzt. Bei einer Umstellung von einfachen Partitions zu VxVM-Volumes darf nicht vergessen werden, in den MountResources den Gerätetreiber anzupassen. Dort muss /dev/vx/dsk/dg/volume statt / dev/dsk/cXtXdXsX eingetragen werden.

215

24 24.2.2

24.3

APACHE WEB-SERVER TEIL 3 Alle Attribute der Mount-ResourceType auf einen Blick: Attribut

Typ

muss?

Beschreibung

MountPoint BlockDevice FSType MountOpt FsckOpt SnapUmount CkptUmount SecondLevelMonitor SecondLevelTimeout

str/scalar

ja

Zielverzeichnis

str/scalar

ja

str/scalar

ja

str/scalar

nein

str/scalar

ja

int/scalar

nein

int/scalar

nein

bool/scalar

nein

int/scalar

nein

Beispiel

/export/home/HAusers Treiberdatei des Block-Devices /dev/dsk/c2t11d0s2 Filesystem-Typ vxfs Mount-Optionen ro (read-only) Option für automatisches fsck -y (hares -modify … %-y) Automatischer Snapshot-umount 0 oder 1 Automatischer Checkpoint-Umount 0 oder 1 Detail-Monitoring für NFS-Mounts 0 oder 1 Timeout für SecondLevelMonitor 60

Default

0 1 0 30

Disk-Resource Disk-Resource l

Prüft Lesbarkeit einer Partition l Operations-Type NONE l Löst keine ConcurrencyViolation aus, da nicht OperationsTyp OnOff l Nur ein Attribut: Partition 24.3

24.3.1

Problem Die Mount-Resource überwacht nur, ob ein Filesystem unmountet wurde. Sie stellt nicht

sicher, dass das Filesystem zugreifbar ist.

Lösung Die Disk-Resource überprüft regelmässig durch Lesen eines einzigen Bytes, ob die Partition lesbar ist. Sie ist wie die NIC-Resource persistent (ihr Operations-Typ ist NONE), da sie als reine Hardware-Resource nicht softwäremässig online bzw. offline genommen werden kann. Wie alle persistenten Resources darf auch Disk nur als Blatt des Resource-Baumes vorkommen. Eine persistente Resource kann nicht von anderen Resources abhängig sein. Resources vom Operations-Typ NONE kennen übrigens keinen OFFLINE-Zustand, sondern sind entweder ONLINE oder FAULTED.

216

APACHE WEB-SERVER TEIL 3

24

Hinweis Es gab bisher keine VCS-Resource, die den Füllungsgrad eines Filesystems überprüft und bei vollgelaufenem Filesystem einen Fault auslöst. Dies ist auch nicht eigentlich Aufgabe des Clusters, denn ein Failover zu einem anderen System würde nichts an dem vollgelaufenen Filesystem ändern, da auf allen Systemen derselbe Storage benutzt wird und er damit nach Übernahme genauso voll sein würde wir zuvor. Diese Art von Überwachung gehört vielmehr in den Bereich des Enterprise Monitoring (Patrol, Tivoli etc…).. Tatsächlich wird aber derzeit VCS in diese Richtung weiterentwickelt. Es gibt bei manchen Resources (z.B. bei der Mount-Resource) bereits den „info“-Entry-Point, über den man näheres über den Zustand der Resources erfahren kann. Setzt man für die Resource das Attribut InfoInterval auf einen Wert größer Null, so führt er periodisch den info-Entry-Point aus und speichert dessen Ergebnisse (den Füllungsgrad des Filesystems) in dem Resource-Attribut ResourceInfo. Man kann es dann mit hares -value MyResource ResourceInfo abfragen. Stand: VCS 4.1 Solaris.

24.3.2

Alle Attribute der Disk-ResourceType auf einen Blick: Attribut

Typ

muss?

Beschreibung

Beispiel

Partition

str/scalar

ja

File- oder Pfadname der Partition

c2t11d0s2

Default

Übung

Ü 24

Übung l

ApacheSGApplication anlegen · Attribute definieren l Die Verzeichnisse /etc/apache, /usr/apache und /var/apache auf shared Storage auslagern und die lokalen Directories auf beiden Systemen leeren. l ApacheSGMountEtc, ApacheMountUsr und ApacheMountVar anlegen · Attribute definieren l ApacheSGDiskEtc, ApacheSGDiskUsr und ApacheSGDiskVar anlegen · Attribute definieren l Abhängigkeiten definieren l Enablen nicht vergessen! l ServiceGroup testen · hagrp -online … · hagrp -offline … · hagrp -switch … Um nicht httpd.conf anpassen zu müssen, lagern wir die benutzten Verzeichnisse /etc/apache, /usr/apache und /var/apache mit ihrem Inhalt auf shared Storage aus. Dazu legen wir auf einer beliebigen Disk drei Partitions an (format), erzeugen dort Filesysteme (mkfs -Fvxfs … oder newfs …), mounten sie temporär und kopieren dorthin die Inhalte der Verzeichnisse (cp -rp / etc/apache /mnt/. oder cd /etc/apache; tar xf - . | (cd /mnt; tar xf -)). Das Unmounten danach nicht vergessen, sonst sind die Filesysteme später doppelt gemountet! Befinden sich die Filesysteme auf derselben Disk, so genügt eine einzige Disk-Resource zur Überwachung. Liegen sie auf mehreren Targets, muss für jedes Target mindestens eine Disk-Resource definiert und in Abhängigkeit gebracht werden.

217

KAPITEL 25

APACHE WEB-SERVER TEIL 4 VOLUME UND DISKGROUP

25 25.1

APACHE WEB-SERVER TEIL 4 Volume-Resource Volume-Resource l

Kontrolliert VxVM-Volumes Erkennt Volume-Stop durch VxVM oder Administrator l Bei Datenbanken auch für Raw-Devices sinnvoll l

25.1

25.1.1

Problem Wird eine DiskGroup importiert, so sind die darin befindlichen Volumes aus Sicherheitsgründen zunächst nicht gestoppt. Zugriff auf ein gestopp-

tes Volume liefert einen Fehler der Form „No such device or address“.

Lösung Zum Starten und vor allem auch zum Überwachen der Volumes liefert VCS einen passenden ResourceType gleichen Namens mit. Die beiden Parameter – Volume und DiskGroup –

25.1.2

220

sind selbsterklärend. Erwähnenswert ist lediglich, dass das Attribut Volume nur den Namen, nicht etwa den Device-Pfad des Volumes enthalten soll.

Alle Attribute der Volume-ResourceType auf einen Blick: Attribut

Typ

muss?

Beschreibung

Volume DiskGroup

str/scalar

ja

Name des VxVM-Volumes

str/scalar

ja

Beispiel

datavol Name der DiskGroup des Volumes datadg

Default

APACHE WEB-SERVER TEIL 4

25

DiskGroup-Resource

25.2 DiskGroup-Resource l

Kontrolliert VxVM DiskGroups Importiert DiskGroups temporär l Startet alle Volumes l Unterstützt SCSI-3 PGR und I/O-Fencing l

25.2

25.2.1

Problem Logische Volumes sollen zuverlässig und sicher von einem zum anderen System wandern.

Lösung Der Veritas Volume Manager (VxVM) wurde von Anfang an mit dem Ziel der Hochverfügbarkeit geplant. Aus diesem Grunde befinden sich sämtlicheVxVM-Objekte in portablen Datencontainern, sogenannten DiskGroups. DiskGroups können nur als Ganzes einem System, bei Storage Foundation Cluster File System auch einem ganzen Cluster, zugeordnet und von diesem benutzt werden. Die passende VCS-Resource greift diese Funktionalität auf und importiert bzw. deportiert die DiskGroup. Beim Importieren werden normalerweise gleich die Volumes gestartet und vor dem Deportieren gestoppt. Als zusätzliche Sicherung gegen Split-Brain kann die DiskGroup-Resource beim Importieren SCSI-3 PGR aktivieren (Persistent Group Reservation), was zum Komplex I/O-Fencing gehört. Diese Reservierung kann die Resource zusätzlich überwachen (MonitorReservation).

Der Import einer DiskGroup durch VCS unterscheidet sich leicht vom normalen Import durch einen Administrator: vxdg import datadg importiert permanent; das Flag autoimport ist gesetzt. Stürzt das System ab und kommt wieder hoch, so wird beim Enablen des VxVM-Config-Daemons diese DiskGroup automatisch wieder importiert. Dieses ist in Clusterumgebungen ausdrücklich unerwünscht; die Entscheidung, ob eine DiskGroup importiert wird oder nicht, soll die Clustersoftware treffen. Aus diesem Grund importiert die DiskGroupResource von VCS ihre DiskGroup temporär; das noautoimport-Flag ist gesetzt. Der Befehl zum temporären Importieren einer DiskGrop auf der Kommandozeile lautet: vxdg -t import datadg.

Hinweis Bei Versionen von StorageFoundation vor 4.0 MP1 war das Monitorprogramm so implementiert, dass bei einer nicht temporär importierten DiskGroup die dazugehörige ServiceGroup komplett heruntergefahren wurde, um die DiskGroup temporär reimportieren zu können. Da beim Enablen einer Resource ein Monitorzyklus geschieht, war es unmöglich, eine VxVM-basierte Applikation im laufenden Betrieb unter Clusterkontrolle zu nehmen, wenn die DiskGroup nicht temporär, also mit vxdg -t import DGName importiert war. Das temporäre Importieren ist allerdings für den Normalbetrieb nicht sinnvoll, wohingegen es für den Clusterbetrieb zwingend ist. SF4.0 MP1 führte daher die Möglichkeit ein, das autoimport-Flag einer DiskGroup im importierten Zustand umzusetzen, sodass eine DiskGroup gewissermaßen nachträglich auf „temporär importiert“ abgeändert werden konnte, und der DiskGroup Agent wurde entsprechend angepasst.

221

25 25.2.2

25.3

APACHE WEB-SERVER TEIL 4 Alle Attribute der DiskGroup-ResourceType auf einen Blick: Attribut

Typ

muss?

Beschreibung

Beispiel

DiskGroup StartVolumes StopVolumes MonitorReservation tempUseFence

str/scalar

ja

Zielverzeichnis

str/scalar

ja

Treiberdatei des Block-Devices

str/scalar

ja

Filesystem-Typ

bool/scalar

ja

Option für automatisches fsck

datadg 0 oder 1 0 oder 1 0 oder 1

str/scalar

nein

Wird nur vom Agent intern benutzt

Default

1 1 0 INVALID

Die fertige ServiceGroup Fertige ServiceGroup l

Implementation eines hochverfügbaren Web-Servers l Erweiterungsmöglichkeiten · IP-MultiPathing (IPMP) – Apache-Agent – evtl. Oracle mit Agent

25.3

25.3.1

222

Die ServiceGroup ist jetzt komplett und kann so als Beispiel für eigene ServiceGroups dienen. Optionale Erweiterungen wären die Benutzung von redundanten Netzwerkinterfaces mittels IPMP (IP Multipathing). Dazu müssten die NIC- und IP-Resource umgestellt werden auf MultiNICB bzw. IPMultiNICB-Resourcen. Ausserdem bietet Veritas einen sogenannten Enterprise-Agent für den Apache-Server an, der auf einige spezielle Eigenschaften von Apache abgestimmt ist.

Natürlich könnte diese ServiceGroup auch noch um eine Datenbank für das Content Management des Web-Servers erweitert werden. Diese kann dann z.B. durch einen Oracle-Agenten kontrolliert werden, der Listener über einen NetLsnr-Agenten. Insgesamt sind tausende von ResourceTypes für VCS entwickelt worden, allerdings befinden sich nur wenige davon auch auf der Veritas-Preisliste.

APACHE WEB-SERVER TEIL 4

25

Übung

25.1

Übung l

ApacheSGVolumeEtc, ApacheSGVolumeUsr und ApacheSGVolumeVar anlegen · Attribute definieren l Abhängigkeiten definieren l Enablen nicht vergessen! l ServiceGroup testen · hagrp -online … · hagrp -offline … · hagrp -switch …

8·2

Stellen Sie die ServiceGroup fertig und testen Sie die Funktionalität mit Hilfe eines Browsers.

223

KAPITEL 26

HEARTBEAT IM DETAIL

26 26.1

HEARTBEAT IM DETAIL Allgemeine Clusterproblematiken Cluster-Problematiken l

Wann ist ein System ausgefallen? – Timeout (Missing Soldier) – Selbstausfall (Dead-Man Switch) – HB-Ausfall (Split Brain) l Was tun, wenn System lebt, Clustersoftware jedoch nicht?

26.1

26.1.1

Problem Die Clustersoftware muss genau dann übernehmen, wenn ein System ausgefallen ist. Wie und wann wird der Ausfall eines Systems zuverlässig festgestellt? Missing Soldier Da ein ausgefallenes System keine entsprechende Nachricht mehr generieren kann, kann nur anhand des Ausbleibens von Nachrichten auf den Ausfall geschlossen werden. Hier stellt sich sofort die Frage, nach welcher Zeit ein System als ausgefallen gelten soll. Für Soldatengattinnen, deren Ehemänner an der Front vermisst werden, gilt ein Zeitraum von sieben Jahren nach der letzten Nachricht. Während dieser Zeit dürfen und müssen sie mit einer Rückkehr des Vermissten rechnen. Danach gilt der Partner als verstorben. Dies ist eine Abwägung zwischen Rücksicht auf den möglicherweise noch lebenden Partner und der Tatsache, dass das Leben weitergehen muss. In Analogie nennt man diese Problematik beim Cluster „Missing Soldier“-Problem. Der LinkTimeout ist bei jedem Cluster eine Abwägung zwischen Zuverlässigkeit und Spontaneität der Reaktion. Wie bei den Soldatengattinnen gibt es auch hier prinzipiell keine richtige Zeit. Es handelt sich immer um einen Kom-

226

promiss. Der Default-Wert bei VCS beträgt 16 Sekunden und ist in /etc/llttab mit set-timer peerinact einstellbar. Dieser und weitere Parameter können in /opt/VRTSllt/ sample-llttab nachgelesen werden. Dead Man Switch Ist ein System so überlastet, dass es längere Zeit keine Heartbeat-Pakete mehr senden kann, so stellt es nach Ende dieser Situation im Heartbeat-Code eine Art „Zeitsprung“ fest. Übersteigt der Zeitsprung den Link-Timeout, so ist klar, dass das andere System bereits übernommen haben muss. Nun muss das System, das den Zeitsprung erlitten hat, eineBetriebssystemPanic auslösen, um Split-Brain zu vermeiden. Split Brain Fällt ein System aus, so muss übernommen werden. Fällt aber nicht ein System aus, sondern lediglich die Heartbeat-Verbindung dazwischen (sog. Network Partition), so darf nicht übernommen werden. Ansonsten tritt eine SplitBrain-Situation mit potentiell fatalen Folgen ein. Existiert nur eine einzige Verbindung zwischen den Systemen, so kann prinzipiell nicht zwischen Ausfall der Verbindung oder Ausfall des Systems unterschieden werden. Eine zweite Verbindung eröffnet diese Möglichkeit. Nur

26

HEARTBEAT IM DETAIL wenn auf allen Leitungen gleichzeitig die HBPakete ausbleiben, gilt das System als ausgefallen. Um die Gleichzeitigkeit eines Ausfalls aller Leitungen feststellen zu können, müssen alle

Leitungen im Regelfall gleichzeitig benutzt werden. Dies ist bei LLT der Fall, und GAB erfährt, wenn sich die Verbindung auf einen einzigen Heartbeat-Link reduziert hat, damit es entsprechend reagieren kann (siehe unten).

26.2

Heartbeat über GAB-Disks GAB-Disks l

Zusatzmechanismus für mehr Redundanz l Empfehlenswert, wenn kein I/O-Fencing benutzt wird l Schreibt Alive-Signale auf Disk-Partitionen, liest Signale aller anderen Nodes l Für Port a und h verwendbar l Benutzt andere Kabel, Treiber, Kommandos, daher hoch ausfallsicher

26.2

Problem Normalerweise besteht der Heartbeat eines Clusters nur aus Ethernet-Verbindungen. Ein Ausfall der gesamten Heartbeat-Funktionalität ist damit weniger gut abgefangen, als eigentlich gewünscht. Mögliche Ausfallgründe aus der Praxis sind nicht erkannte SPOF (Single Points Of Failure) in der Netzwerkhardware, defekte Gerätetreiber, uninformierte Netzwerktechniker, die beim Umpatchen alle HB-Kabel gleichzeitig ziehen und einiges mehr. Dies alles sind reale Praxisbeispiele aus den letzten Jahren! Vorüberlegungen Würde ein weiterer, völlig unabhängiger Pfad genutzt, mit anderen Kabeltypen, Gerätetreibern und Kommandos, so wäre der gesamte Heartbeat deutlich resistenter auch gegen Ausfallszenarios. Lösungsmöglichkeiten bei VCS GAB unterstützt Disk-Heartbeats, sogenannte GAB-Disks. Dazu wird eine Partition auf einer oder mehreren shared-Disks angelegt und der Gerätetreiber dieser Disks in GAB-Kommandos in /etc/gabtab hinterlegt. Wird anschliessend GAB gestartet (durch sh /etc/gabtab), so

schreibt das System in einen definierten Bereich (2KB ab Node-ID x 2KB) Alive-Signale hinein — eine hochzählende Sequenznummer — und liest anschliessend den gesamten Bereich (64KB). Dadurch kann GAB auch nach Ausfall aller HB-Links noch zuverlässig feststellen, welche Systeme noch laufen. Da dieser Mechanismus pro Port aktiviert werden kann, also z.B. Port a und Port h, ist hiermit sogar feststellbar, wenn der had gestoppt oder gestartet wurde. Konfigurationsänderungen oder Resourcen-Status sind über GAB-Disks jedoch nicht übermittelbar; der beschränkte Platz auf den Diskbereichen ist hierfür nicht geeignet. Konfiguration Zunächst wird auf einer von allen Systemen zugreifbaren Disk eine leere Partition eingerichtet. Diese kann sehr klein sein; ein einziges MegaByte ist bereits mehr als genug. Nun wird das Disk-Heartbeating eingeschaltet: gabdiskhb -a /dev/dsk/c3t0d0s7 \ -s 16 -p a gabdiskhb -a /dev/dsk/c3t0d0s7 \ -s 144 -p h

26.2.1

227

26

26.2.2

228

HEARTBEAT IM DETAIL Dabei stehen: -a für add -s für den ersten Sektor des GAB-Bereichs für diesen Port. Dieser sollte mindestens 16 betragen, da sonst u.U. die VTOC oder der Bootcode der Disk überschrieben werden könnte. -p für den Port Diese Befehle werden in /etc/gabtab eingetragen, damit die GAB-Disks bei Booten automatisch mit aktiviert werden. Es sind mehrere GAB-Disks möglich. Zur Feststellung des Systemzustandes reicht es, wenn eine einzige GAB-Disk Alive-Signale schreibt. Es ist auch möglich, zur erhöhten Sicherheit die GAB-Disk mit einer Signatur zu versehen (man gabdiskconf); nötig ist dies jedoch nicht. Zukunft von GAB-Disk GAB-Disk behandelt Heartbeat- und Systemausfälle zwar ausgesprochen elegant, bricht allerdings das Prinzip „Death before Corruption“. Es ist daher nicht empfohlen, GAB-Disks

in Clustern einzusetzen, die in Überlastsituationen kommen können. Es wird deshalb auch leider nicht weiterentwickelt und wohl auch irgendwann nicht mehr supportet. Glücklicherweise jedoch gibt es einen nicht minder eleganten Ausweg, sofern Ihr SAN dies zulässt: Wir können denselben Kanal, den wir zuvor für die GAB-Disk verwendet haben, also die Glasfaser-Pfade zur Disk, mit ifconfig plumb für IP einsatzbereit machen und dann über diese Leitungen LLT über UDP-Pakete tunneln. Somit hätten wir einen weiteren vollen Heartbeat (mit Informationsübermittlung statt nur Alive-Signalen) zur Verfügung, der mithin mindestens so gut wie die GAB-Disk funktionieren müsste. Für die genaue Konfiguration von IP auf Ihrem FibreChannel-Controller konsultieren Sie bitte die Treiber-Konfigurationsdatei im Verzeichnis / kernel/drv. Für die noch recht exotische Konfiguration von LLT über UDP möchten wir Sie an die sample-llttab verweisen.

Lösungsansätze anderer Clusterprodukte Rekapitulieren wir noch einmal die Problemstellung. Es muss zwischen folgenden drei Fällen unterschieden werden: 1. Das betroffene System ist ausgefallen 2. Die Heartbeat-Leitungen sind unterbrochen 3. Das betroffene System ist überlastet und kann keine Pakete mehr schicken Je nach Fall muss unterschiedlich gehandelt werden: Fall 1. verlangt nach Übernahme des ausgefallenen Systems. Fall 2. verbietet eine Übernahme jedoch, ansonsten wäre der Cluster in einer Split-Brain Situation. Fall 3. schliesslich würde idealerweise durch Abwarten abgefangen. Da allerdings nicht bekannt ist, wie lange die Situation andauern wird, die Software irgendeine Entscheidung treffen muss und darüberhinaus die Fälle 1. und 3. sowieso nicht softwaremässig unterscheidbar sind, wird auch in Fall 3. übernommen. Hier ist dann das Verhalten des Cluster beim Weiterlaufen des anderen Systems nach Ende der Überlastung kritisch. Wie wird der Fall 2., in dem nicht übernommen werden darf, identifiziert? Viele Clusterprodukte verwenden ein Abstimmungs- oder Quorum-Verfahren, um Split-BrainZustände auszuschliessen. Allgemein gesagt besteht ein Cluster nicht aus zwei Systemen,

sondern aus „mehr als einem“. In der Clustertheorie kann ein Cluster durch Ausfall immer nur in zwei Hälften zerfallen, von denen nur eine weiterlaufen darf. Die eine Hälfte ist die, mit welcher der Node noch kommunizieren kann, die andere Hälfte jene, zu deren Nodes keine Verbindung mehr besteht. Ob die für einen Node nicht mehr erreichbaren Nodes noch untereinander kommunizieren können, kann der einzelne Node nicht entscheiden, daher darf dies keine Rolle spielen. Um nun festzustellen, welcher Teil der für das Weiterlaufen geeignetere ist, wird angenommen, dass jedes Einzelsystem für das Überleben jener Clusterhälfte stimmt, der es selbst angehört. Zerfällt ein Cluster bestehend aus fünf Knoten in zwei Subcluster zu zwei und drei Knoten, so erhält der 3-er Cluster 3 Stimmen (Votes), der 2-er Cluster jedoch nur 2. Da die Gesamtzahl der Systeme vor dem Ausfall der Kommunikation beiden Subclustern bekannt war, kennen die Systeme jedes Subclusters auch die Anzahl Votes des anderen Subclusters und können somit entscheiden, ob sie weiterlaufen sollen (im grösseren Subcluster) oder eine Betriebssystem-Panic auslösen (im kleineren Subcluster). Dieser Ansatz ist jedoch aus verschiedenen Gründen unpraktikabel: 1. Jeder Cluster müsste aus einer ungeraden

26

HEARTBEAT IM DETAIL Anzahl Nodes bestehen, 2-Node Cluster wären nicht machbar. 2. Ein Multi-Node-Cluster zerfällt nur genau dann in zwei Teile, wenn ein System ausfällt. Es gibt dann eine überlebende Seite mit mehreren Nodes und eine nicht überlebende mit dem defekten Node. Fällt jedoch die HB-Infrastruktur aus (ein Core-Switch zum Beispiel), so zerfällt der Multi-NodeCluster in so viele Teile wie er Nodes hat, und das Voting-Verfahren erzeugt auf keinem System eine Mehrheit. Somit lösen alle Subcluster eine Betriebssystem-Panic aus und der Dienst fällt aus. Um diese beiden Probleme gleichzeitig anzugehen, wird ein dediziertes Gerät benutzt, welches ausschliesslich zum Voting dient. Bei Ausbleiben von HB-Paketen wird die andere Clusterhälfte nicht direkt als ausgefallen angenommen, sondern es wird zunächst versucht, sich das Gerät zu reservieren, um mit Hilfe von dessen „Vote“ als der grössere Subcluster zu erscheinen. Die Reservierung des Geräts kann z.B. durch eine SCSI-Reservierung auf eine Disk geschehen (Quorum-Disk) oder durch Reservieren eines definierten Ports auf einem Terminal-Server. Misslingt die Reservierung, so befindet sich das System im kleineren Subcluster und löst eine System-Panic auf. Es ist jedoch sehr schwierig, einen MultiNode-Cluster mit Quorum-Disks aufzusetzen, da für jede mögliche Kombination von

Systemen je eine Quorum-Disk definiert werden muss und somit die Anzahl Quorum-Disks schnell die Anzahl Systeme übersteigt. Oft sind daher Multi-Node-Cluster bei QuorumDisk basierten Clustern nicht erlaubt. Eine andere Methode zur Vermeidung von Split Brain heisst STONITH (Shoot The Other Node In The Head). Hier wird bei Ausbleiben von Heartbeat-Signalen mittels z.B. serieller Leitung die CPU des anderen Systems angehalten bzw. dessen Strom abgeschaltet. Dieses Verfahren unterstützt jedoch nur 2-NodeCluster. Beide Verfahren sind sehr problematisch, wenn sich die beiden Clusterhälften, wie heutzutage häufig, in unterschiedlichen Rechenzentren befinden. Für STONITH per serieller Leitung ist die Entfernung zu groß; STONITH über Ethernet hat das Problem, dass der Kabeltyp und damit die Infrastruktur dieselbe ist wie der Heartbeat und bei dessen Ausfall nicht mehr funktionieren kann. Quorum-Verfahren haben bei diesem Setup den Nachteil, dass ein Site-Ausfall mit 50%iger Wahrscheinlichkeit auf jener Seite auftritt, in der sich das Quorum-Device befindet. Somit kann das überlebende System die Quorum-Vote nicht erlangen und löst eine System-Panic aus. Auch hier ist wieder Dienstausfall die Folge. Und Achtung: Site-Ausfälle sind wesentlich häufiger, als Sie denken! WIr besprechen dies im I/O-Fencing Kapitel.

229

26 26.3

HEARTBEAT IM DETAIL Heartbeat-Verhalten Heartbeat-Verhalten Kommunikation zwischen Maschinen l Sendet Alive und Info – Alive via Ethernet und Disk – Info nur via Ethernet l Im Normalbetrieb redundant l Ausfall eines redundanten Heartbeat führt zur Übernahme l Bei Ausfall eines nicht redundanten Heartbeat werden keine automatischen Aktionen mehr durchgeführt 26.3 l

26.3.1

230

Vorüberlegungen Da die Clustersoftware die Zuverlässigkeit erhöhen soll, darf sie sich selbst nur auf zuverlässige Informationen verlassen und nur dann Resourcen starten und stoppen, wenn sie über deren Zustand auf jedem System zuverlässig informiert ist. AutoDisable Kann VCS den Zustand einer Resource auf irgendeinem Mitglied des Clusters nicht feststellen, so wird auf der dazugehörigen ServiceGroup keine automatische Aktion mehr zugelassen. Die ServiceGroup wird AutoDisabled. Einige mögliche Gründe dafür, dass VCS einen Resourcenzustand nicht feststellen kann, sind: l Das Probing schlägt fehl, weil die Resource falsch definiert ist, was z.B. zu einem Syntaxfehler beim Monitoring geführt hat. l Der HA-Daemon auf dem System läuft nicht, deswegen wird nicht über Port h kommuniziert (worüber normalerweise die Resourcezustände übermittelt werden) l Der HA-Daemon läuft und hat Port h geöffnet, jedoch besteht keine Ethernet-Verbindung zum Rest des Clusters. Über Disk werden nur die Alive-Signale von Port a und Port h übermittelt. Jeopardy Bei VCS wird die komplette Verwaltung der Cluster-Mitgliedschaften von GAB übernommen. Der Group Membership Services Teil von GAB stellt eindeutig fest, welche Systeme zur Zeit Mitglied im Cluster sind, welche den Cluster verlassen und welche hinzukommen. Er tut dies implementationsbedingt auf allen Systemen gleichzeitig auf identische Weise.

Über LLT werden die Heartbeat-Pakete reihum über bis zu acht Ethernet-Interfaces verteilt. Damit kann ein einzelner Leitungsausfall sofort festgestellt werden. Werden die Default-Werte benutzt, so markiert LLT nach 16 Sekunden Inaktivität auf einem Link diesen als ausgefallen. Sendet der Link wieder, so wird er sofort wieder als aktiv markiert. GAB bekommt von LLT mitgeteilt, wenn die Verbindung nicht mehr redundant, also nur noch ein einziges Ethernet-Interface aktiv ist. Es wird dann abgewartet, bis dieser Zustand garantiert auf alle Systeme propagiert ist (GAB-StableTimeout, Default 5 Sekunden). Anschliessend gilt der Cluster als „gefährdet“, weil bei in diesem Zustand nicht mehr zwischen Linkausfall und Systemausfall unterschieden werden kann. Das englische Wort für Gefährdung heisst „Jeopardy“. GAB merkt sich den Gefährdungszustand in Form einer zusätzlichen „Jeopardy“Membership auf den betroffenen Ports. Diese Membership kann man im Output von gabconfig -a sehen. Wird VCS von GAB mitgeteilt, dass ein System den Cluster verlassen hat (d.h. es sendet keine Pakete mehr auf Port a, dem GAB-eigenen Port), so wird im Normalfall das System übernommen. Befand sich das System jedoch ausserdem in einer Jeopardy-Membership, so wird stattdessen AutoDisabled, das heisst es wird nichts unternommen; alles läuft weiter wie bisher. Ein VCS-Cluster mit GAB-Disk ist sicherer als ein Cluster mit Quorum-Disk (Split Data Center) und hält die Services so lange wie irgend möglich verfügbar.

HEARTBEAT IM DETAIL

26

Rejoin

26.4 Rejoin l

System meldet sich nach Überlast wieder l Innerhalb des Timeouts kein Problem l Nach Timeout stoppt GAB auf Subcluster mit niedrigerer Priorität den had. l Gestoppter had wird von hashadow nachgestartet l Remote Build; Applikationen werden wieder übernommen l Anzahl Nodes bzw. Node-ID bestimmt die Priorität 26.4

Problem Kommen von einem System (streng genommen: Subcluster) nach Ablauf des Timeouts (peerinact) wieder Heartbeat-Pakete, so kann nicht entschieden werden, ob dieses System lediglich temporär nicht erreichbar war, ob seine CPU angehalten war oder ob es aufgrund von Überlast nicht kommuniziert hat. Prinzipiell wird daher der schlimmste Fall angenommen, nämlich dass beide Systeme in einer Network Partition Situation (getrennte Heartbeats) parallel weiterliefen. Damit sind zwei Dinge verbunden: 1. Beide Teile des Clusters haben die ServiceGroups des jeweils anderen Teil übernommen. Es liegt also ein Split-BrainZustand vor. 2. Auf beiden Teilen könnte eine gültige Umkonfiguration stattgefunden haben. Die Konfigurationsänderungen beider Subcluster könnten sich widersprechen. Lösung bei VCS Um die Situation eindeutig zu entscheiden, verwirft der „kleinere“ Subcluster seine Konfiguration. Der „Grössere“ ist bei gleicher Knotenanzahl der Subcluster derjenige Subcluster, der die niedrigste Node-ID enthält. Bei normalen 2-Node-Clustern ist dies die Node-ID 0. Auf

jedem System des „kleineren“ Subclusters wird der had-Prozess durch GAB gekillt und durch hashadow sofort erneut gestartet. Dadurch wird auf diesem System der Port h neu geöffnet, er joint dem Cluster und muss dafür einen Snapshot der Konfiguration von den anderen Nodes des Clusters laden (REMOTE BUILD). Das Herunterladen der Konfiguration besteht aus dem Ausführen aller Kommandos, die zusammen die Clusterkonfiguration erzeugen. Dazu gehört auch das Enablen aller Resources. Bei diesem Enablen findet ein Probing auf die Resource statt. Das Resultat wird mit dem Soll-Zustand verglichen, der ebenfalls Teil des soeben geladenen Snapshots ist. Hier erst kann VCS eine eventuelle Concurrency Violation feststellen und bereinigen. Da dies unter Umständen zu lange dauert und dadurch Datenkorruption auftreten kann, gibt es die Möglichkeit, bei GAB die Option „Halt on Rejoin“ einzustellen (man gabconfig). In diesem Fall stoppt GAB nicht den hadProzess, sondern löst eine BetriebssystemPanic aus. Bis dies passiert, werden aber unter Umständen auch Daten auf Disks geschrieben, die unter Kontrolle des anderen Subclusters sind.

26.4.1

231

26

HEARTBEAT IM DETAIL Hinweis Es ist wichtig, sich darüber klar zu werden, dass auch Quorum-basierte Lösungen nicht besser reagieren als GAB mit „Halt on Rejoin“. Denn die Abfrage des Quorum-Devices verbraucht ebenfalls eine endliche Zeit, während der Daten durch die anderen CPUs korrumpiert werden können. Eine wirklich sichere Lösung bringt erst I/O-Fencing

Ü 26

Übung: Übernahmetests und GAB-Disks Übungsvorschläge zum Aussuchen l

GAB-Disk(s) aussuchen Connectivity auf allen Systemen sicherstellen l GAB-Partitions anlegen l GAB-Disk Heartbeat starten auf beiden Systemen und mit gabdiskhb -l beobachten l GAB-Disk Heartbeats nacheinander stoppen (gabdiskhb -d … statt -a) und wieder überprüfen l GAB-Heartbeats wieder in Betrieb nehmen und in /etc/gabtab verankern 8·2 l Ein System Rebooten und auf dem anderen System die GAB-Meldungen auf der Console beobachten l Nach Belieben Systeme mit STOP-A anhalten und nach kurze oder längerer Zeit (am besten unter 16 oder über 21 Sekunden, um ein eindeutiges Verhalten zu erzielen) mit go bzw. boot weiterlaufen lassen bzw. booten . l Wahlweise mit aktivem oder nicht aktivem Disk-Heartbeat eines oder alle Ethernet-Kabel des Heartbeats ziehen und auf der Console jedes Systems die Rekonfiguration beobachten. Dabei sollte ein hastatus auf jedem System mitlaufen. Auch dessen Meldungen beobachten und interpretieren. Achtung! Werden ohne GAB-Disk alle Ethernet-Heartbeats binnen fünf Sekunden gezogen, so resultiert dies im schädlichen Split-Brain-Szenario! l

Suchen Sie sich aus den Übungsvorschlägen diejenigen heraus, die Sie interessieren, und führen Sie sie durch. Eine Musterlösung gibt es hierfür nicht.

232

KAPITEL 27

CLUSTER MAINTENANCE

27 27.1

CLUSTER MAINTENANCE Wartung von Systemen Systemwartung l

Patch des Betriebssystems Installation systemnaher Produkte (VxVM) l Patch oder Upgrade der Cluster-Software l

hasys -freeze [-persistent] sys0 27.1.1

Problem Es sollen systemnahe Wartungsarbeiten auf einem oder mehreren Node des Clusters durchgeführt werden. Wenn alles gutgeht, können die Services weiterlaufen. Im Notfall sollen die Dienste des gewarteten Systems aber übernommen werden. Keinesfalls sollen ServiceGroups anderer Clustersysteme auf dem in Wartung befindlichen System online gehen. Lösung in VCS Das System wird durch einen Befehl eingefroren: hasys -freeze sys0. Dadurch werden Onlining-Vorgänge auf diesem System unterbunden. Offlining-Vorgänge sind nach wie vor möglich. So kann ein Failover von dem in Wartung befindlichen System hinweg noch stattfinden, ein Failover zu dem System hin

234

27.1

jedoch nicht. Der eingefrorene Zustand kann mit dem zusätzlichen Flag -persistent bootfest gemacht werden. Dazu muss nach dem Einfrieren auch die Cluster-Konfiguration mit haconf -dump in das Filesystem geschrieben werden. Der eingefrorene Zustand wird im GUI als rotes Vorhängeschloss auf dem System dargestellt, auf der Kommandozeile kann er angezeigt werden mit den Befehlen: hasys -display bzw. hasys value sys Frozen (persistently frozen) hasys -display bzw. hasys value sys TFrozen (temporarily frozen). Aufgetaut wird das System mit dem Befehl: hasys -unfreeze \ [-persistent] sys.

CLUSTER MAINTENANCE

27

Wartung von ServiceGroups

27.2 Applikations-Wartung l

OracleSG

OracleSG

hagrp -freeze OracleSG [-persistent] Problem Es sollen Wartungsarbeiten an einer Applikation durchgeführt werden, die unter Clusterkontrolle ist. Die Applikation soll weiter überwacht werden, die Clustersoftware soll aber nicht während der Wartung störend eingreifen. Aus diesem Grund darf Monitoring zwar stattfinden, aber weder Offlining noch Onlining sind erlaubt. Lösung in VCS Die ServiceGroup wird durch einen Befehl eingefroren: hagrp -freeze group. Dadurch werden online- und offline-Vorgänge für diese ServiceGroup auf allen Systemen unterbunden. Monitor-Vorgänge sind nach wie vor möglich. So kann der Applikationsbetreuer oder das Supportpersonal auf die gewohnte Weise mit der Applikation arbeiten, ohne durch Eingriffe der Clustersoftware irritiert zu werden.

Patchen oder Umkonfigurieren der Applikation l Upgrade auf neue Release l Wartungsarbeiten durch Dritte (Supportpersonal) l Umstellungen innerhalb der ServiceGroup – IP auf IPMultiNICB – Application auf Oracle

27.2

Der eingefrorene Zustand kann auch hier mit dem zusätzlichen Flag -persistent bootfest gemacht werden, das in diesem Fall allerdings erst hinter dem Objekt-Namen steht, nicht wie beim Einfrieren eines Systems davor. Der eingefrorene Zustand wird im GUI als rotes Vorhängeschloss auf der ServiceGroup dargestellt, auf der Kommandozeile kann er angezeigt werden mit den Befehlen: hagrp -display bzw. hagrp value group Frozen (persistently frozen) hagrp -display bzw. hagrp value group TFrozen (temporarily frozen). Aufgetaut wird die ServiceGroup mit dem Befehl: hasys -unfreeze group [persistent].

27.2.1

235

27 27.3

CLUSTER MAINTENANCE Stillegen von ServiceGroups auf Systemen Applikationswartung auf einem System l

Kombination aus System freeze und ServiceGroup freeze l Onlining der ServiceGroup wird auf dem System nicht mehr zugelassen l Failover der ServiceGroup vom System weg möglich l Failover der ServiceGroup zum System hin gesperrt

hagrp -disable OracleSG -sys sys0 27.3.1

236

Vorüberlegungen Sind die Vorbedingungen für den Betrieb einer ServiceGroup auf einem der Systeme nicht mehr zuverlässig erfüllt, soll die ServiceGroup temporär auf diesem System gesperrt werden. Lösung in VCS Im VCS-Cluster kann jede ServiceGroup systembezogen disabled werden. Dies entspricht in den Auswirkungen dem Freezing des Systems, hat aber nur Gültigkeit für die angegebene ServiceGroup. Das heisst, die ServiceGroup kann zunächst weiterlaufen, wird auch von VCS überwacht und vom System heruntergenommen, wenn ein ResourceFault auf-

27.3

tritt. Sie kann jedoch nicht unbeabsichtigt zu dem System hin failovern, etwa weil auf einem anderen System ein Fault aufgetreten ist. Für alle anderen ServiceGroups verhält sich das System normal. Auch die ServiceGroup verhält sich auf allen anderen Systemen normal. Im Grunde könnte man auch das System aus der SystemList der ServiceGroup entfernen, allerdings ist dies nicht möglich, wenn die ServiceGroup gerade auf diesem System ONLINE ist. Ausserdem müsste man dann evtl. noch andere Attribute umsetzen, etwa die AutoStartList, SystemZones etc.

CLUSTER MAINTENANCE

27

Configuration Recovery und Replication

27.4 Configuration Recovery und Replication l

Aufbau mehrere ähnlicher ServiceGroups l Replikation eines ClusterSetups auf anderen Clustern l Restoration einer alten Konfiguration online l Erzeugen eines neuen Resource-Types per CLI

27.4

Problem Alle Änderungen der Konfiguration von VCS geschehen wie besprochen über das Command Line Interface (CLI). Nur die Ausgangskonfiguration wird aus der Datei $VCSCONF/ main.cf gelesen. Wie kann man die main. cf-Syntax in Kommandosequenzen umsetzen, um Änderungen in den Cluster einbringen zu können, deren Syntax für main.cf bekannt ist, als Kommandos aber unbekannt oder kompliziert, z.B. ResourceType-Definitionen? Lösung bei VCS Es gibt ein Utility hacf, welches genau diese Umseetzung vornimmt. Es dient zunächst einmal zum Überprüfen eines manuell editierten main.cf-Files (Syntax-Check). Dazu wird es aufgerufen mit dem Parameter -verify. und dem Directory, in dem sich eine Datei namens main.cf befinden muss: hacf verify $VCSCONF [-display]

Das Utility liest die main.cf-Datei und sämtliche davon abhängigen Dateien (types.cf etc.), erzeugt daraus zeilenweise die Befehle, die zur Erzeugung der entsprechenden Konfiguration nötig wären, und schreibt das Resultat in die Datei main.cmd. Mit dem Parameter display wird der Output zusätzlich nach stdout geschrieben. Hat man sich eine geeignete Namenskonvention für die Resources zu eigen gemacht, so kann man aus diesem Output leicht die gewünschten Objekte (ServiceGroups) mittels grep herausfilten, weiterbearbeiten und über eine /bin/sh pipen. Dadurch gelangt die Konfiguration live in den laufenden Cluster hinein. Eine eventuelle Rückkonversion geschieht mit: hacf -cmdtocf $VCSCONF

27.4.1

237

27

CLUSTER MAINTENANCE

27.5

Event Notification und Trigger Event Notification l

Definierte Events in $VCSBIN/hatrigger l Für jeden Event wird von had der hatrigger aufgerufen l hatrigger ruft Usergeschriebenes Script zur Eventverarbeitung auf (in $VCSBIN/triggers) l Vorhandensein des Scripts enabled Eventbearbeitung

27.5

27.5.1

238

Problem Gewisse Fehlersituationen verlangen ein anderes Verhalten als das vom Cluster vorgegebene. Lösung bei VCS Für eine grosse Menge Events ruft der had das Programm /opt/VRTSvcs/bin/ hatrigger auf. Dieses Perl-Script wechselt

in das Directory /opt/VRTSvcs/bin/ triggers und prüft dort auf die Existenz einer Datei, die den Namen des Events trägt. Die vollständige Liste der Eventnamen, die auch gleichzeitig die Dateinamen sind, findet sich am Beginn des hatrigger-Scripts, hier folgt nur ein Auszug der Wichtigsten:

preonline

ServiceGroup soll online gehen, Trigger checkt Vorbedingungen

postonline

ServiceGroup ist vollständig online

postoffline

ServiceGroup ist vollständig offline

sysoffline

Ein System ist faulted, Trigger wird auf jenem verbleibendem System mit der niedrigsten ID ausgeführt

resfault

Resource faulted

violation

Resource einer Failover-SG ist auf mehr als einem System online

injeopardy

Der Cluster befindet sich in Jeopardy

resnotoff

Eine Resource kann nicht offline kommen

nofailover

Es gibt kein mögliches Zielsystem mehr für einen Failover

resstatechange

Eine Resource hat ihren Zustand geändert

loadwarning

Das System ist überlastet

unable_to_restart_had

Der had kann nicht durch hashadow neu gestartet werden

resadminwait

Eine Resource benötigt Administrator-Eingriff

CLUSTER MAINTENANCE

27

Hinweis Für zwei Events genügt als Voraussetzung nicht die Existenz des entsprechenden Scripts im triggers-Verzeichnis. Für diese muss zusätzlich ein Attribut auf der ServiceGroup gesetzt werden. Es sind dies die Events PreOnline (Attribut PreOnline) und ResStateChange (Attribut TriggerResStateChange).

Übung: Maintenance, Configuration und Trigger

Ü 27

Übungsvorschläge zum Aussuchen l

Systeme einfrieren, Switch- oder Failover-Tests durchführen ServiceGroups einfrieren, Switch- oder Failover-Tests durchführen l ServiceGroup aus einem System disablen, Switch- oder Failover-Tests durchführen l Configuration schreiben (haconf -dump), ServiceGroup löschen und aus main.cf wieder aufbauen l Einen resfault-Trigger schreiben und testen. Beachten, dass dieser im Daemon-Environment läuft und entsprechend nur minimale Pfade gesetzt sind. l

Suchen Sie sich aus den Übungsvorschlägen diejenigen heraus, die Sie interessieren, und führen Sie sie durch. Eine Musterlösung gibt es hierfür nicht.

239

KAPITEL 28

REDUNDANTE NETZWERKANBINDUNG

28 28.1

REDUNDANTE NETZWERKANBINDUNG Bündeln von Netzwerkinterfaces Bündeln von Interfaces l

Verhindert Failover bei Netzwerkstörungen l Führt stattdessen NICSwitch durch l Reine VCS-Lösung – MultiNICA & IPMultiNIC l Hybridlösung OS und VCS – MultiNICB & IPMultiNICB

28.1

28.1.1

Problem Gelegentliche Störungen im Netzwerk oder der Ausfall eines Interfaces, Kabels oder Switch–Ports sollen nicht zum Failover einer ServiceGroup führen. Denn mit jedem Failover ist stets auch eine Downtime verbunden, er ist oft nicht transparent für die User, führt zu suboptimaler Lastverteilung etc.. Lösung in VCS VCS bietet als systemunabhängige Lösung eine ResourceType MultiNICA an. Diese Abkürzung steht für MultiNIC-Array, also eine Reihe von Network Interface Controllern. Benutzt man diese Resource, so überwacht ihr Agent zunächst nur ein einziges, das aktive, Interface. Er tut dies ähnlich wie der NICAgent durch Zählen einkommender Pakete. Alle anderen in der MultiNICA-Resource definierten Interfaces haben zunächst keine IPAdressen. Bemerkt der Agent einen Ausfall des aktive Interfaces, so wechselt er zum nächsten definierten Interface, aktiviert dort die in der Resource definierte IP-Adresse und prüft die Funktion. Beides, sowohl das Feststellen eines Ausfalls als auch die Funktionsprüfung nach einem Micro-Failover, kann jedoch recht lange dauern - typischerweise bis zu 90 Sekunden. In dieser Zeit sind häufig bereits die Client-Sessions mit einem TCP-Timeout beendet worden.

242

Vorteile von MultiNICA Trotz ihrer langsamen Umschaltung besitzt die MultiNICA-Resource auch einige gute Eigenschaften, die sie auch heute noch für etliche Anwendungen attraktiv macht: l Adressenbedarf – Da zu jeder Zeit nur ein einziges Interface aktiv ist, wird nur eine einzige Basis-IP-Adresse benötigt, um die Funktion des Interfaces zu prüfen. Bei einfachen Setups kann man als Basis-IP die normale IP-Adresse der Maschine (oft auch als Admin-IP bezeichnet) benutzen, sodass keine weiteren IP-Adressen benötigt werden. l Kompatibilität – Die MultiNICA-ResourceType ist auf jeder Plattform identisch. Die Betriebssystemspezifischen Varianten heißen MultiNICB und benötigen je nach System unterschiedliche Voraussetzungen. Nachteile von MultiNICA Hauptnachteil ist sicher die ausgesprochen langsame Umschaltung sowie die Tatsache, dass die Reserve-Interfaces weder benutzt noch überprüft werden. Aus diesem Grund wird stattdessen häufig eine MultiNICBResource verwendet.

REDUNDANTE NETZWERKANBINDUNG

28

MultiNICA-Resource

28.2 MultiNICA-Resource l

Device jetzt Key-Value Liste Test-IP ist normalerweise Maschinen-IP – maschinenspezifisch – Attribute lokalisieren l Resource bestimmt aktives Interface l Resource übernimmt gegebenen Zustand beim Enablen l Braucht neue ResourceType für Service-IP-Adressen – IPMultiNIC l Sollte in separate ServiceGroup ausgelagert werden l

28.2

28.2.1

Konfiguration von MultiNICA Das Attribut Device (Array von Key-Value Paaren) wird mit einer Liste der Interfaces und der korrespondierenden Basis-IP-Adressen gefüllt. Die Basis-IP ist normalerweise innerhalb eines Servers für alle Devices gleich und es ist oft sinnvoll, die Maschinen-IP im entsprechenden Netz (z.B. Admin-IP) zu verwenden. Als Nebeneffekt wird dadurch die Admin-IP hochverfügbar. Übrigens: Wenn die MultiNICA-Resource enabled wird prüft sie, auf welchem Interface die Basis-IP aktiv ist, und übernimmt dieses Interface im laufenden Betrieb. Da die Basis-IP-Adresse bei jedem System unterschiedlich sein muß, um Konflikte auf IP-Ebene zu vermeiden, und da außerdem eventuell auch auf verschiedenen Systemen unterschiedliche Netzwerkcontroller benutzt werden, muss innerhalb der Resource eine Unterscheidung zwischen den Maschinen stattfinden. So müsste beispielsweise auf einem System die Adresse 194.76.15.23 auf ce1 und ce3 konfiguriert werden, auf dem anderen System aber die Adresse 194.76.15.24 auf ge0 und ge2. Dies wird erreicht durch das Lokalisieren von Attributen: hares -local NetSGMultiNICA Device macht aus dem bisher globalen Attribut Device ein lokales Attribut, welches in Folge systemspezifisch

gesetzt werden kann: hares -modify NetSGMultiNICA Device … -sys node0. Ein Interface, das in einer MultiNICA-Resource definiert ist, darf nicht gleichzeitig durch irgendeine andere Resource kontrolliert werden. Insbesondere darf es nicht in einer anderen MultiNICA-Resource eingetragen sein. Zum einen würde das einen erhöhten Monitoring-Aufwand bedeuten, zum anderen wäre nicht garantiert, dass bei einem Micro-Failover jede Resource das gleiche Zielinterface auswählt. Dann würden sich mehrere MultiNICA-Resources widersprechen und das Resultat wäre nicht definiert. Ohne Benutzung von MultiNICs hat jede ServiceGroup eine Paarung aus IP- und NIC-Resource, um die Service-IP zu kontrollieren und die Hardware zu überwachen. Dies ist bei MultiNICs aus dem obengenannten Grund nicht eins-zueins umsetzbar, da ein Netzwerkinterface nicht durch mehrere MultiNICA-Resources kontrolliert werden darf. Übrigens ist auch die Überwachung einzelner NICs durch mehrere Resources nicht optimal. Deshalb sollte das im folgenden beschriebene Verfahren zur Auslagerung von Netzwerkresources generell angewendet werden.

243

28 28.2.2

28.3

REDUNDANTE NETZWERKANBINDUNG Alle Attribute von MultiNICA auf einen Blick: Attribut

Typ

muss?

Beschreibung

Device

str/assoc

ja

Paarung Interface-Name und IP

Beispiel

ce0 x.x.x.x ge2 x.x.x.x Verzögerung des gratuitous RARP 5 Interner Schleifenzähler beim 30

Default

int/scalar ArpDelay HandShakeIn- int/scalar terval IfconfigTwice int/scalar

nein

nein

Wenn TRUE (1), dann werden zwei gratuitous RARP gesendet

1

NetMask

str/scalar

nein

Netzmaske der IP-Adresse. Sollte gesetzt werden

255.255.255.0

NetworkHosts

str/vector

nein

Liste von IP-Adressen, die zum Testen des NICs angepingt werden. Wenn Liste leer, Broadcast-ping.

194.76.15.254 194.76.15.240

Options PingOptimize RouteOptions

str/scalar

nein

Optionen für ifconfig

int/scalar

nein

Spart Ping-Pakete beim Monitor

str/scalar

nein

Optionen für die Route auf dem aktiven Interface. Nur sinnvoll, wenn der Host sein eigener Default-Router ist.

notrailers 1 0 „default 194.76.15.17 0“

nein

1 20

Micro-Failover

NetSG, Phantom- und Proxy-Resource NetzwerkServiceGroup l

Ausschliesslich NetzwerkHardwareüberwachung l Besonderheiten – Phantom-Resource – Parallel l Indirekte Abhängigkeiten über Proxy-Resources

28.3

244

REDUNDANTE NETZWERKANBINDUNG

28

Auslagern der Netzwerkfunktionalität

28.3.1

Die Resource, welche die Netzwerkhardware überwacht (NIC bzw. MultiNIC[AB]) wird in eine eigene ServiceGroup ausgelagert, die ausschliesslich die Netzwerkfunktionalität birgt und typischerweise NetSG heißt. Somit wird die Überwachung der Netzwerkhardware an einem zentralen Punkt vorgenommen. Allerdings ergeben sich jetzt aus den Randbedingungen von VCS mehrere kleinere Unannehmlichkeiten, die überwunden werden müssen: 1. Solange die NetSG ausschliesslich persistente Resources enthält, kann ihr Zustand (online/offline) nicht festgestellt werden, denn dieser wird aus der Summe aller Zustände aller nicht-persistenten Resources ermittelt. Der undefinierte Online-Zustand kann beim Monitoring jedoch zu Irritationen führen. Dies umgeht man, indem man eine nicht-persistente Dummy-Resource zu der NetSG hinzufügt. Genau zu diesem Zweck steht der ResourceType Phantom bereit. Diese Resource wird ohne Attribute ver-

wendet; ihre reine Existenz in einer SG genügt, um künftig den Zustand der SG (online/offline) ermitteln zu können. 2. Auf verschiedenen Servern könnten ServiceGroups online sein, also sollte auch die NetSG auf allen Servern bereitstehen und damit online sein. Dies ist aber nur für besondere ServiceGroups erlaubt, nämlich für solche, die als Parallel definiert wurden. Das Parallel-Attribut muss gesetzt werden, bevor Resourcen in die ServiceGroup gelegt werden, also direkt nach Erzeugen der ServiceGroup. 3. Abhängigkeiten von Resources sind direkt nur innerhalb einer ServiceGroup möglich. Die NetzwerkResource befindet sich jedoch in einer ausgelagerten ServiceGroup (NetSG). Damit würden bei Ausfall der Netzwerkfunktionalität die anderen ServiceGroups unbeirrt weiterlaufen und nicht auf einen anderen Knoten wandern.

28.4

ApplicationSG und IPMultiNIC-Resource IPMultiNIC-Resource l

Kontrolle einer IP-Adresse auf einem in MultiNICA definierten Device l Analog zu IP für NIC IPMultiNICB / MultiNICB l Direkt abhängig von Proxy zu MultiNICA l Über MultiNICResName indirekt abhängig von MultiNICA

28.4

245

28 28.4.1

REDUNDANTE NETZWERKANBINDUNG Konfiguration von IPMultiNIC Da wir durch Benutzung von MultiNICA einem Clusteragenten die Entscheidung überlassen, welches Interface aktiv sein wird, können wir die IP-Adressen nicht mehr mit der herkömmlichen IP-Resource verwalten. Denn diese benötigt Address, NetMask und vor allem Device. Das Device wird nun aber dynamisch durch MultiNICA gesetzt. Man benutzt also eine neue ResourceType, IPMultiNIC, die anstelle des Attributs

28.5

„Device“ das Attribut MultiNICRes Name kennt. Über dieses Attribut greift der Agent auf die aktuelle Deviceauswahl der zugrunde liegenden MultiNICA-Resource zu und kontrolliert die IP-Adresse dort. Damit ist gewährleistet, dass auch nach einem MultiNICA Micro-Failover die IPMulti NIC-Resources die IP-Adressen stets korrekt kontrollieren.

IPMultiNIC-Resource IPMultiNICKonfiguration l

Attribute analog zu IP MultiNICResName ersetzt Device l Agent bezieht aktuelles Device aus Zielresource l

28.5

28.5.1

Konfiguration der IPMultiNIC-Resource Die IPMultiNIC-Resource verfügt IP-seitig über die gleichen Attribute wie die gewöhnliche IP-Resource. Der Unterschied liegt auf der Hardwareseite. Es wird nicht direkt das Device angegeben, sondern vielmehr die Quelle, aus der die Information über das aktuelle Device zu beziehen ist. Diese Quelle ist jene

28.5.2

Alle Attribute von IPMultiNIC auf einen Blick: Attribut

Typ

muss?

Beschreibung

Beispiel

MultiNICResName Address NetMask

str/scalar

ja

Name der MultiNICA-Resource, welche die Hardware überwacht

NetSGMultiNICA

str/scalar

ja

IP-Adresse

str/scalar

nein

Netzmaske der IP-Adresse. Sollte gesetzt werden

194.76.15.44 255.255.255.0

IfconfigTwice int/scalar

nein

Wenn TRUE (1), dann werden zwei gratuitous RARP gesendet

1

str/scalar

nein

Optionen für ifconfig

notrailers

Options

246

Resource, die die Hardware kontrolliert und somit entscheidet, welcher NIC gerade benutzt wird, sle die zugrundeliegende MultiNICAResource. Das entsprechende Attribut heisst MultiNICResName und enthält bei korrekter Konfiguration den Resourcenamen des MultiNICA-Resource.

Default

REDUNDANTE NETZWERKANBINDUNG

28

Beispiel:

28.5.3

Um die im Text genannten Parameter zu verwenden, würde man z.B. wie folgt vorgehen. ApplicationSG anlegen und konfigurieren: hagrp -add NetSG hagrp -modify NetSG SystemList node0 0 node1 1 hagrp -modify NetSG Parallel 1 # Parallel setzen bevor Resourcen eingebracht werden hagrp -modify NetSG AutoStartList node0 node1 Phantom-Resource für NetSG hares -add NetSGPhantom Phantom NetSG # keinerlei Konfiguration nötig hares -modify NetSGPhantom Enabled 1 MultiNICA-Resource für NetSG hares -add NetSGMultiNICA MultiNICA NetSG hares -local NetSGMultiNICA Device hares -modify NetSGMultiNICA Device ce1 194.76.15.23 ce3 194.76.15.23 -sys node0 hares -modify NetSGMultiNICA Device ge0 194.76.15.24 ge2 194.76.15.24 -sys node1 hares -modify NetSGMultiNICA NetMask 255.255.255.0 hares -modify NetSGMultiNICA Enabled 1 ApplicationSG anlegen und konfigurieren hagrp -add ApplicationSG hagrp -modify ApplicationSG SystemList node0 0 node1 1 hagrp -modify ApplicationSG AutoStartList node0 node1 Proxy-Resource für ApplicationSG hares -add ApplicationSGProxy Proxy ApplicationSG hares -modify ApplicationSGProxy TargetResName NetSGMultiNICA hares -modify ApplicationSGProxy Enabled 1 Wenn die Proxy-Resource State=UNKNOWN zeigt, ist meist der TargetResName falsch geschrieben oder die Target-Resource ist noch nicht Enabled. IPMultiNIC-Resource für ApplicationSG hares -add ApplicationSGIPMultiNIC IPMultiNIC ApplicationSG hares -modify ApplicationSGIPMultiNIC Address 194.76.15.230 # ServiceIP der ApplicationSG hares -modify ApplicationSGIPMultiNIC MultiNICResName NetSGMultiNICA hares -modify ApplicationSGIPMultiNIC NetMask 255.255.255.0 hares -modify ApplicationSGIPMultiNIC Enabled 1 Auch hier bei State=UNKNOWN zunächst den MultiNICResName auf korrekte Schreibweise überprüfen und sichergehen, dass die Zielresource Enabled ist. Resources voneinander abhängig machen hares -link ApplicationSGIPMultiNIC ApplicationSGProxy

247

28 28.6

REDUNDANTE NETZWERKANBINDUNG IPMultiNICB-Resource IPMultiNICB-Resource l

IP-Resource für MultiNICB-Hardware l BaseResName statt MultiNICResName l DeviceChoice für bevorzugtes Interface ist Offset für DeviceArray der MultiNICBResource 13·5 28.6

28.6.1

IPMultiNICB-Konfiguration Die IPMultiNICB-Resource wird benutzt, wenn die Netzwerkhardware mittels einer Resource vom Typ MultiNICB kontrolliert wird. Ähnlich wie bei der IPMultiNIC-Resource wird hier zusätzlich zu Adress und (empfohlen) NetMask der Resource-Name der Hardware-kontrollierenden Resource eingetragen. Allerdings heißt das entsprechende Attribut hier nicht MultiNICResName, sondern BaseResName. Im optionalen Attribut DeviceChoice kann der Index des bevor-

28.6.2

zugten Interfaces angegeben werden. Das Interface selbst wird nicht genannt, da sonst Änderungen an der Interfacekonfiguration an zwei Stellen durchgeführt werden müssten und das Attribut ausserdem bei unterschiedlicher Hardware lokalisiert werden müsste. Durch Benutzung des Index wird der konkrete Devicename abstrahiert und somit variabel gehalten. Näheres dazu in der Beschreibung von MultiNICB.

Alle Attribute von IPMultiNICB auf einen Blick: Attribut

Typ

muss?

Beschreibung

Beispiel

BaseResName

str/scalar

ja

Name der MultiNICB-Resource, welche die Hardware überwacht

NetSGMultiNICB

Address NetMask

str/scalar

ja

IP-Adresse

str/scalar

nein

Netzmaske der IP-Adresse. Sollte gesetzt werden

194.76.15.44 255.255.255.0

DeviceChoice

int/scalar

nein

Index des bevorzugten Interfacces der Basis-Resource

1

Default

0

Hinweis Die MultiNICB-ResourceType erlaubt es, einen NIC-Wechsel kommandogesteuert durchzuführen. Dazu gibt es das Kommando haipswitch. Es wird zwar selten benutzt, ist aber gegebenenfalls unentbehrlich. haipswitch -s MultiNICB # check status haipswitch MultiNICB IPMultiNICB Address NetMask from_IF to_IF Beispiel: haipswitch NetSGMultiNICB ApplSGIPMultiNICB 194.76.15.230 255.255.255.0 ge0 ce1

248

REDUNDANTE NETZWERKANBINDUNG

28

MultiNICB-Resource

28.7 MultiNICB-Resource l

Alternative zu MultiNICA Device ist Array von Interfaces und Index (für DeviceChoice, s.o.) l Zwei Modi (UseMpathd) – Base Mode – Multipathing Mode l Base Mode selten sinnvoll l Multipathing Mode braucht umfangreiche Basiskonfiguration l Defaultwert für MpathdCommand ist falsch! l Eine Testadresse pro Interface nötig l

28.7

28.7.1

MultiNICB Die MultiNICB-Resource kennt zwei Modi: den Base Mode und den Multipathing-Mode. Im Base-Mode verhält sie sich ähnlich wie eine MultiNICA-Resource mit zusätzlichem automatischem Failback, allerdings fragt sie bei nicht gesetztem Attribut IgnoreLink Status zusätzlich den Device-Treiber ab. Besonders interessant ist der MultipathingMode, der durch Setzen des Attributs Use Mpathd aktiviert wird. In dieser Betriebsart wird das Monitoring der Netzwerkinterfaces einschliesslich Interface-Failover und InterfaceFailback vom Multipathing-Daemon (in. mpathd) des Betriebssystems übernommen. Die Resource selbst überwacht nur noch das FAILED-Flag der Interfaces sowie den Prozess in.mpathd und startet in.mpathd gegebenenfalls neu. Über das vereinfachte Monitoring hinaus bietet der Multipathing-Mode den Vorteil, dass alle Interfaces gleichzeitig aktiv sind, damit auch überwacht werden und gleichzeitig eine Lastverteilung für ausgehenden Traffic erreicht wird. Dieser Modus ist für den laufenden Betrieb der einfachste und zuverlässigste, zumal sich die Umschaltung transparent und sekundenschnell vollzieht. Allerdings braucht die Einrichtung der betriebssystemseitigen Funktionalität einiges

KnowHow, und die Defaultwerte der Resource selbst müssen teilweise angepasst werden. Basiskonfiguration für Multipathing Mode Die in einer MultiNICB-Resource verwendeten Devices müssen bereits vorkonfigurierte Testadressen besitzen (sie können nicht durch Resource-Attribute konfiguriert werden). Dies geschieht bootfest durch Eintragen entprechendet Zeilen in die Dateien /etc/hostname.if. Dort werden zunächst die Testadressen eingetragen und als deprecated und -failover sowie als derselben Gruppe zugehörig (group name) markiert. Soll das Interface nicht für Load-Balancing benutzt werden, so muss es zusätzlich als standby markiert werden. Das Interface, welches die Admin-IP beherbergen soll, bekommt mit einer weiteren Zeile über ein addif-Statement ein virtuelles Interface mit der Admin-IP zugewiesen. Alle Adressen müssen sich im selben Subnetz befinden, und alle Adressen in diesem Subnetz müssen sich in der gleichen MultipathingGroup befinden. Der Gruppenname in den Dateien /etc/ hostname.if spielt übrigens keine Rolle. Er wird beim Enablen der MultiNICB-Resource durch deren Resourcenamen ersetzt.

249

28 28.7.2

28.7.3

REDUNDANTE NETZWERKANBINDUNG Alle Attribute von MultiNICB auf einen Blick: Attribut

Typ

muss?

Beschreibung

Beispiel

Device

str/assoc

ja

Paarung von Device und Index aller Interfaces der gleichen IPMP-Gruppe

ce3 0 ge2 1

Default

MpathdCommand str/scalar

nein

Kommandozeile zum Starten von in.mpathd

/sbin/ in.mpathd

UseMpathd

int/scalar

nein

Modus-Umschaltung: IPMP oder VCS-eigene Umschaltung

/usr/lib/inet/ in.mpathd -a 1

ConfigCheck

int/scalar

nein

Überprüfung der Konfiguration im Mpathd-Modus

0

1

MpathdRestart int/scalar

nein

in.mpathd nach Absturz neu starten oder nicht?

0

1

Beispiel für IP-Multipathing über ce1 und ge0. Die Adressen testip_von_ce1, testip_von_ce2 und adminip_des_servers müssen in /etc/hosts o.ä. eingetragen sein. Die Admin-IP (194.76.15.23 bzw. 194.76.15.24) soll beim Booten auf dem virtuellen Interface ge0:1 online gehen. Die Interfaces auf Betriebssystemebene multipathingfähig konfigurieren und die Admin-IP auf ein virtuelles Interface legen. Hier am Beispiel für node0: cat /etc/hostname.ce1 testip_von_ce1 netmask + broadcast + deprecated -failover [standby] group bootgroup up cat /etc/hostname.ge0 testip_von_ge0 netmask + broadcast + deprecated -failover [standby] group bootgroup up \ addif 194.76.15.23 netmask + broadcast + failover up ifconfig ce1 unplumb; ifconfig ce1 plumb $(cat /etc/hostname.ce1) ifconfig ge0 unplumb; ifconfig ge0 plumb $(cat /etc/hostname.ge0) MultiNICB-Resource konfigurieren: hares -add NetSGMultiNICB MultiNICB NetSG # ce1 hares -modify NetSGMultiNICB Device ce1 0 ge0 1 bekommt Index 0, ge0 Index 1 hares -modify NetSGMultiNICB UseMpathd 1 hares -modify NetSGMultiNICB MpathdCommand ʻ/usr/lib/inet/in.mpathd -aʻ hares -modify NetSGMultiNICB Enabled 1 IPMultiNICB-Resource konfigurieren: hares -add ApplSGIPMultiNICB IPMultiNICB ApplSG hares -local ApplSGIPMultiNICB Address # Attribut nodespezifisch lokalisieren hares -modify ApplSGIPMultiNICB Address 194.76.15.23 -sys node0 # und die entsprechenden hares -modify ApplSGIPMultiNICB Address 194.76.15.24 -sys node1 # IP-Adressen setzen hares -modify ApplSGIPMultiNICB NetMask 255.255.255.0 hares -modify ApplSGIPMultiNICB BaseResName NetSGMultiNICB # Deviceinfo von dieser Rescoure hares -modify ApplSGIPMultiNICB DeviceChoice 1 # Bevorzugt ge0 (Index 1, s.o.) benutzen hares -modify ApplSGIPMultiNICB Enabled 1

250

REDUNDANTE NETZWERKANBINDUNG

28

Irreführende Console-Meldungen bei Benutzung von MultiNICB-Resources

28.7.4

Im ungepatchten Solaris wird bei Vorhandensein von Interface-Gruppen der in.mpathd wie folgt gestartet: /sbin/in.mpathd Daher steht dies so als Defaultwert in der MultiNICB-Resource. Im gepatchten Solaris wird der in.mpathd aber gestartet durch: /usr/lib/inet/in.mpathd -a Der alte Pfad ist in diesem Fall ein symbolischer Link auf den neuen. Konfiguriert man ein Interface mit einem group-Attribut, so wird durch den ifconfig-Befehl der in.mpathd gestartet, allerdings auf eine dritte Weise, nämlich mit: /usr/lib/inet/in.mpathd (also ohne das Flag -a) Der MultiNICB findet den in.mpathd dann nicht, wenn die Definition in der Resource und der tatsächliche Eintrag in der Prozessliste nicht übereinstimmen. Aus diesem Grund versucht er ihn dann nachzustarten, und zwar mit jener

Kommandozeile, die in der Resource steht (Default /sbin/in.mpathd). Dies schlägt jedoch fehl, da der laufende in.mpathd ein Lockfile anlegt, damit er nicht zweimal gestartet wird. Der Agent versucht jetzt, den in.mpathd zu killen, findet ihn aber nicht in der Prozessliste (da er ja nach dem falschen Pfad sucht) und gibt dann eine Fehlermeldung aus, die alle paar Sekunden in /var/adm/messages und auf der Console erscheint.. Funktionieren tut Multipathing allerdings dennoch; der Daemon läuft ja. Die Lösung besteht darin, das Attribut MpathdCommand auf jene Kommandozeile zu setzen, durch die beim Booten mit bestehenden Interface-Groups der in.mpathd aktiviert wird. Dies ist bei normalerweise der Pfad /usr/lib/inet/in.mpathd -a. Anschließend sollte man den in.mpathd einmal killen, damit er durch den MultiNICB-Agent mit der korrekten Kommandozeile neu gestartet wird.

Übung: Redundante Netzwerkanbindung

Ü 28

Übungen zur redundanten Netzwerkanbindung l

NetSG erzeugen und ApacheSG auf redundante Netzwerkresources umstellen Wahlweise MultiNICA/IPMultiNIC oder MultiNICB/IPMultiNICB oder beide nacheinander verwenden l Bei MultiNICB betriebssystemseitige Konfiguration sorgfältig durchführen und ConsoleMessages eliminieren l Bei MultiNICA Zeit für Micro-Failover und komplettes Failover messen l

Stellen Sie Ihre ApacheSG auf eines der beiden MultiNIC-ResourceTypes um. Erzeugen Sie dazu zunächst eine parallele ServiceGroup NetSG. Benutzen Sie Phantom- und Proxy-Resources, um die NetSG zu komplettieren bzw um die Resources geeignet zu verknüpfen. Die Musterlösung befindet sich aus Platzgründen auf den rechten Seiten der Passagen, in denen die jeweiligen ResourceTypes besprochen wurden. Für eine MultiNICB-Konfiguration müssen Sie auch die Musterlösung von MultiNICA zu Rate ziehen, da dort der Aufbau der parallelen NetSG gezeigt wird.

251

KAPITEL 29

I/O-FENCING

29 29.1

I/O-FENCING Problemstellung: Überlast und parallele Applikationen Problemstellungen l

GAB ist bei extremen Überlastsituationen, in denen ein Node lange Zeit keine HBPakete schickt, nicht besser als herkömmliche QuorumVerfahren. l Parallele Diskzugriffe müssen durch einen clusterweiten Lock-Manager koordiniert werden. AutoDisable ist in diesen Fällen nutzlos l Das Prinzip „Death before Corruption“ wird streng ausgelegt 29.1

29.1.1

Problemstellung Zwar enthält GAB einen extrem leistungsfähigen und zuverlässigen Heartbeat-Mechanismus, jedoch gibt es Fälle, in denen die durch GAB (sogar trotz zusätzlicher Verwendung von GAB-Disks) erreichte Absicherung gegen SplitBrain-Situationen nicht ausreicht. Diese teilen sich in zwei völlig unterschiedliche Bereiche auf, die dennoch letztlich durch denselben neuen Split-Brain-Vermeidungsmechanismus abgehandelt werden. Wir möchten jedoch vorausschicken, dass dieser neue Mechanismus auch seine Tücken hat und nicht kritiklos als „das neue, also bessere“ Verfahren hingenommen werden sollte. Es gibt zahlreiche Cluster, in denen die klassische Variante mit GAB und evtl. GAB-Disks der Lösung mit I/O-Fencing in jeder Hinsicht überlegen ist, wenn gewisse Randbedingungen eingehalten werden. Was also sind die Fälle, in denen GAB nicht ausreicht und zusätzlich I/O-Fencing konfiguriert werden muss? l Überlastete Nodes – Ein Node gerät dermaßen unter Überlast, dass er zum Senden von Heartbeat-Paketen nicht mehr in der Lage ist. Das Resultat ist eine irrtümliche Übernahme durch eine andere Maschine, die den überlasteten Node (mit einigem Recht, wenn man es sich genau überlegt) für ausgefallen hält. Kehrt die Originalmaschine aus der

254

Überlastsituation zurück, so gibt es eine RaceCondition zwischen dem Kernel-Thread, der feststellt, was passiert ist, und entscheidet, dass der Dead-Man Switch durchgeführt werden und die Maschine Panic auslösen muss, und den zahllosen I/Os, die noch auf das Schreiben auf die Disks warten. Daher ist hierbei stets von einer Datenkorruption auszugehen. Im Grunde genommen ist die ganze Problematik allerdings kein Laufzeitproblem, sondern eigentlich ein Sizing- bzw. Designproblem. Denn eine Hardware, die sich durch interne Mittel (sprich: durch eine auf dieser Hardware laufenden Software) überwacht, muss unter allen Umständen auch über ausreichende Ressourcen für diese Überwachung verfügen, ansonsten kann unmöglich ein korrektes Verhalten erwartet werden. Natürlich kann man dieses Problems auch durch verünftige Auslegung der Nodes Herr werden. Da der Trend in der Groß-EDV zur Zeit jedoch wieder in Richtung maximale Auslastung der Maschinen tendiert, sind hier künftig vermehrt Probleme zu erwarten. l Paralleler Datenzugriff – Greifen mehrere Nodes gleichzeitig auf Daten im Storage zu, so muss für jeden der parallel benutzten Layer (DiskGroups, Volumes, Filesysteme, Datenbanken etc.) ein Lock-Management aktiv sein, um die Zugriffe zu regeln. Im Falle von Cluster File System oder Oracle

29

I/O-FENCING RAC auf Basis von VCS sind diese Kommunikationskanäle einfach weitere Ports auf GAB, neben den bekannten Ports a für GAB und h für den had. Dies bedingt zwangsläufig eine funktionierende GAB-Kommunikation zwischen den Nodes. Ohne Kommunikation könnten keine neuen Locks erzeugt werden (diese Locks sind clusterweit gültig und

müssen daher verteilt werden können, was ohne Kommunikation natürlich nicht möglich ist). Damit ist die ansonsten ausgesprochen elegante Lösung des AutoDisable bei sukzessivem Verlust aller Heartbeat-Links nicht mehr nutzbar, denn das Resultat wäre eine Applikation, die zwar liefe, mangels Locks jedoch nicht das geringste tun kann.

29.2

Vorteil von I/O-Fencing gegenüber Quorum-Device Vergleich QuorumDevice und I/O-Fencing l

Beide Ansätze reservieren ein externes Gerät exklusiv l Wenn Gerät nicht reserviert werden kann, wird bei beiden System-Panic aufgerufen l Quorum-Device kann Korruption nach Überlast nicht verhindern l I/O-Fencing verhindert Korruption durch Schreibrechte auf Storage

29.2

29.2.1

Der schnelle Weg zu I/O-Fencing Vorab ein Hinweis für Eilige: Wenn Sie nicht an einem Verständnis der Interna von I/O-Fencing interessiert sind, sondern nur einen Cluster aufbauen müssen, der I/O-Fencing benutzt, so können Sie die folgenden Seiten überspringen und direkt zum Abschnitt „Konfiguration von I/O-Fencing“ springen. Wir müssen allerdings darauf hinweisen, dass jeder, der einen Cluster mit I/O-Fencing betreibt, diesen Mechanismus gründlich verstanden haben sollte, da es ansonsten früher oder später zu Problemen kommen dürfte, sei es beim Wiederanlauf oder bei plötzlichen Betriebssystem-Panics, deren Gründe Sie nicht vorhersagen können, ohne I/O-Fencing verstanden zu haben. Kommen Sie also bitte auf jeden Fall irgendwann wieder auf die folgenden Seiten zurück, vozugsweise bevor Sie den Abschnitt über den Wiederanlauf nach Fencing lesen.

Was ist und wie arbeitet I/O-Fencing? Die Arbeitsweise von I/O-Fencing ähnelt der von Quorum-Devices, wie sie von anderen Clustern bekannt sein mögen. Das Prinzip besteht darin, bei Verlust der Heartbeat-Kommunikation ein externes Gerät zu reservieren, das nur von einer Maschine zu einer Zeit reserviert sein kann. Bei konventionellen Clustern handelt es sich dabei normalerweise um eine Disk, die „Quorum-Disk“. Es findet also gewissermaßen in jedem Fall, bei dem sich ein Node geraume Zeit nicht meldet, ein Rennen um das externe Gerät statt, das nur einer gewinnen kann. Der oder die Verlierer werden von dem reservierten Gerät zurückgewiesen und erkennen daran, dass ein anderes Gerät die Reservierung durchgeführt hat, also noch funktionieren muss. So kann unterschieden werden, ob es sich um den Ausfall des

255

29

I/O-FENCING Heartbeat-Netzes oder einen Ausfall der Maschine handelt. Die Verlierer des Rennens dürfen nicht weiterlaufen, sondern lösen eine Betriebssystem-Panic aus, um eine SplitBrain-Situation zu vermeiden. Problem bei Quorum-Device-Clustern Das Problem mit Quorum-Device-basierten Entscheidungen ist, dass diese von der Maschine selbst aktiv interpretiert werden müssen. Dies funktioniert in manchen Situationen nicht, beispielsweise in dem selbst bei Verwendung von GAB-Disks problematischen Fall der Rückkehr einer Maschine aus einer Überlastung, nachdem ihre ServiceGroups bereits durch einen anderen Node übernommen wurden. Kehrt die Maschine aus der Überlastsituation zurück (nehmen wir an, es handelt sich um eine große Enterprise-Maschine mit 64 CPUs und einer Datenbankapplikation), so fangen 63 der 64 CPUs an, ausstehende I/Os abzuschicken, während CPU 64 irgendwann wieder in den Heartbeat-Treiber geht und dort feststellt, dass sie selbst bereits seit Minuten keine Heartbeats mehr geschickt und erhalten hat. Je nach Implementation löst sie entweder sofort eine Betriebssystem-Panic aus oder versucht erst noch, das Quorum-Device zu reservieren (Dead-Man Switch). In jedem Fall ist es zu spät, da in der Zwischenzeit die anderen 63 CPUs bereits megabyteweise alte Daten in die Datenbank geschrieben haben und diese in sich inkonsistent geworden ist.

256

Lösung durch I/O-Fencing Um diesen großen Nachteil auszuschließen, wurde von Veritas das I/O-Fencing ersonnen. Dieses basiert prinzipiell ebenfalls auf einem externen Quorum-Device, hat aber zwei wesentliche Vorteile gegenüber einer einfachen Quorum-Disk 1. Das Quorum-Device ist eine DiskGroup mit einer ungeraden Anzahl Disks. Somit kann auch bei Ausfall einer Disk das Quorum-Device noch korrekt arbeiten, denn zur Reservierung muss lediglich die Mehrzahl der konfigurierten Disks der DiskGroup reserviert werden, nicht alle Disks. Daher sind mindestens drei Disks vorgeschrieben, bei sehr anfälligen Disks können es auch fünf oder sieben sein, sodass auch mehrere ausfallen können, ohne die Funktion zu beeinträchtigen. 2. Der entscheidende Vorteil ist jedoch der, dass beim I/O-Fencing die Datendisks selbst gewissermaßen eine Zugriffsrechteverwaltung bekommen. Dazu werden Keys jeder gültigen Maschine auf den Disks hinterlegt, damit diese schreiben kann. Führt nun ein Ausbleiben der Heartbeat-Pakete zu einer Quorum-Entscheidung, so wird nicht nur das Quorum-Device reserviert, sondern es werden auch die Schreibrechte des Nodes gelöscht, der sich nicht mehr meldet. War das Ausbleiben der Heartbeat-Pakete auf eine Überlast zurückzuführen, so findet die wiederkehrende Maschine nach ihrer Überlast Disks vor, auf die sie nicht mehr schreiben kann und kann daher keinerlei Schaden mehr anrichten.

I/O-FENCING

29

Arbeitsweise von I/O-Fencing bei parallelen Clustern (RAC/CFS)

29.3

Arbeitsweise von I/O-Fencing l

Registrieren aller Nodes auf einerm Quorum-Device (Coordinator-DiskGroup) beim Starten des FencingTreibers (zur Boot-Zeit) l Registrieren aller Nodes auf den Datendisks durch VCS-Agent beim Import der DiskGroup und Reservieren (Umschalten der Datendisks auf „geschlossene Gesellschaft“) durch den VCS-Agent l Mitführen der Registrierung als Schlüssel bei jedem Schreibvorgang 29.3

Interna zur Arbeitsweise von I/O-Fencing mit VCS Um I/O-Fencing richtig zu verstehen, betrachten wir zunächst einmal den Begriff selbst. Das Wort „fencing“ kommt aus dem Englischen und hat eine Doppelbedeutung. Zum einen bedeutet es „Fechten“, also den Zweikampf mit Schwert, Degen, Florett oder ähnlichem, oder auch „einen Streit ausfechten“. Es ist sicherlich naheliegend, an diese Bedeutung zu denken, wenn man von dem Streit zweier Clusterhälften spricht, die sich darüber einigen müssen, wer nach Ausbleiben der Heartbeat-Signale überleben darf und wer in Form einer Betriebssystem-Panic sozusagen Selbstmord begehen muss. Eine andere Bedeutung des Wortes „Fencing“ entpuppt sich jedoch als nicht minder passend: „eine Umzäunung“. Denn genau diese etabliert I/O-Fencing, zumindest in der von Veritas implementierten Version. Die Umzäunung, die hier gezogen wird, besteht aus einer klar definierten Reihenfolge der Aktionen bei Verlust des Heartbeats, die so gestaltet ist, dass in keinem theoretischen oder praktischen Fall eine Korruption auf den Datendisks durch ein unkoordiniertes Schreiben durch z.B. plötzlich wiedererwachende Nodes denkbar ist. Es wird gewissermassen ein Zaun um die

29.3.1

zu schützenden Daten gezogen, der nur auf dem „richtigen“ Weg durchschritten werden kann; alle anderen Wege sind blockiert. Wie funktioniert dieser Mechanismus? Grundlage der Arbeitsweise von I/O-Fencing ist die Fähigkeit moderner Disk-Hardware, sich gegen Schreibzugriffe durch unqualifizierte Maschinen zu schützen, diese also selbständig abzuwehren. Bei diesem Verfahren müssen alle Maschinen einmalig bei den Disks, auf die sie schreiben wollen, angemeldet werden. Sinnvollerweise geschieht dies einfach beim Importieren einer sogenannten Shared DiskGroup, also einer DiskGroup für parallelen Einsatz auf mehreren Nodes, wie sie z.B. für das Veritas Cluster File System und Oracle RAC benutzt werden. Sind die Maschinen angemeldet, so werden die Disks in einen Modus umgeschaltet, der es nur noch den angemeldeten Maschinen erlaubt, sie zu beschreiben. Die Anmeldungen geschehen in Form sogenannter Registrierungen, genauer gesagt durch Hinterlegung von Node-spezifischen Registration-Keys auf den Disks. Die Modus-Umschaltung wird als Reservierung (SCSI-3 Persistent

257

29

I/O-FENCING Group Reservation, PGR) bezeichnet. Auch sie wird von einem Key begleitet, der allerdings weniger wichtig ist. Um beim Zerfall eines solchen Clusters (Verlust des Heartbeats durch defekte Links oder tatsächlichen Node-Ausfall) einer Datenkorruption vorzubeugen, fechten (fencing) alle Subcluster einen Kampf aus, an dessen Ende nur noch die Registrierungen einer Seite des zerfallenen Clusters, also eines Subclusters, auf den Datendisks verbleiben. Alle Nodes, deren Keys von den Disks entfernt wurden, begehen Selbstmord durch Auslösen von Betriebssystem-Panic. Ein Node, der sich beispielsweise aufgrund von Überlastung länger als die erlaubte Zeit (settimer peerinact=1600 in /etc/llttab, default 16 Sekunden) nicht meldet, bekommt also von den anderen Nodes seine Keys auf den Datendisks gelöscht, sodass er nicht mehr auf diese zugreifen kann, selbst wenn er sich von der Überlastung erholt hat. Damit das Löschen der Registration-Keys als atomare Operation abläuft, also nicht ein Subcluster die Keys des jeweils anderen Subclusters von nur der Hälfte der Datendisks löscht und damit ein völlig unbrauchbarer Zustand entsteht, wird zunächst um das Recht gekämpft, die Keys entfernen zu dürfen. Das Recht erhält immer nur ein Node, und dieser löscht anschließend die Keys der fehlenden Nodes von allen Datendisks. Dafür muss eine spezielle DiskGroup ohne Daten eingerichtet werden, die als Coordinator-DiskGroup bezeichnet wird. Zu dieser DiskGroup unten mehr. Schauen wir uns zunächst die Registrierungen und Reservierungen näher an: Registrierungen (Registration-Keys) Beim Importieren einer DiskGroup in einem Fencing-Umfeld wird für jeden Node der aktuellen Cluster-Membership ein Schlüssel (der „Registration-Key“) auf den Disks hinterlegt, der allen Mitgliedern der „Group“ bekannt ist, da er über GAB verteilt wird, wenn sich der VCS-Cluster im entsprechenden Modus befindet (haclus -value UseFence ist „SCSI3“). Die „Group“ ist identisch mit der aktuellen Cluster Membership, enthält also alle Nodes, die miteinander kommunizieren können. Die Hinterlegung des Keys nimmt der DiskGroup-Agent des VCS-Clusters beim Importieren durch den vxdg-Befehl durch

258

Übergeben eines zusätzlichen Flags mit den Registrierungs-Keys als Parameter vor. Die von VCS verwendeten Keys bestehen bei parallelen Applikationen aus einem achtstelligen String, der aus der Node-ID, einem festen String und einem Zähler (bei 0 beginnend) erzeugt wird. Die Node-ID wird zu dem ASCIICharacter ‚A‘ addiert, sodass z.B. die Registrierungskeys auf der als achte importierten DiskGroup eines Zwei-Node-Clusters so aussehen: APGR0007 BPGR0007 A und B stehen für die Node-IDs 0 und 1, „PGR“ für „Persistent Group Reservation“, und die nächsten vier Stellen geben die Nummer der DiskGroup in der Importreihenfolge an. Reservierungen (Reservation-Keys) Sind die Schlüssel hinterlegt, so wird, ebenfalls durch den DiskGroup-Agent, auf den Disks die Reservierung durchgeführt. Diese heißt kryptisch: SCSI3_RESV_WRITEEXCLUSIV EREGISTRANTSONLY (SCSI 3 Reservierung: „exklusiver Schreibzugriff“ nur für registrierte Nodes). Damit werden die Disks so umgeschaltet, dass sie ab sofort alle Schreibversuche von jenen Maschinen ablehnen, die nicht auf der Disk registriert sind und im SCSI-Befehlsblock den passenden Schlüssel, nämlich ihre Registrierung, mitliefern. Die Reservierung erhält ebenfalls einen Schlüssel, nämlich jenen, mit dem die reservierende Maschine selbst bei der DIsk registriert ist. Hätte im obigen Beispiel Node 1 reserviert, so würde der Reservierungs-Key daher wie die Registrierung von Node 1 lauten, nämlich BPGR0007. Das bedeutet jedoch nicht, dass nur Node 1 fortan schreiben darf, sondern lediglich, dass Node 1 die Reservierung als letzter getätigt hat. Alle registrierten Nodes dürfen schreiben, und das sind Node 0 und Node 1. Da Volume-Manager selbstverständlich auch dafür sorgt, dass das Mitliefern des Schlüssels für die Applikation transparent geschieht, ist für diese zunächst kein Unterschied zu einem normalen Betrieb feststellbar, solange sie auf einem Node läuft, der auf den Disks registriert ist. Der Unterschied wird erst bei Verlust des Heartbeats deutlich. Denn in diesem Fall wird die eine Hälfte des Clusters die Registrierungs-

29

I/O-FENCING Keys der anderen Hälfte von allen importierten Shared DiskGroups atomar löschen, womit fortan den Mitgliedern jener Hälfte der Zugriff auf Hardwarebene verwehrt wird. Diese Nodes können nun unmöglich Schaden auf den Datendisks anrichten, da der Key, den sie mitliefern, auf den Disks gelöscht wurde und sie somit nicht mehr schreiben können. So wird im Gegensatz zu anderen Clustern, die lediglich auf einem freiwilligen „Selbstmord“ durch Auslösen von Panic basieren, jede Möglichkeit zur Datenkorruption durch Überlast oder Heartbeat-Verlust vollständig und zuverlässig verhindert. Reservierungen und Registrierungen können Sie z.B. mit folgenden Befehlen anschauen: Registrierungen: vxfenadm -g /dev/rdsk/c#t#d#s2 Reservierung: vxfenadm -r /dev/rdsk/c#t#d#s2 Coordinator-Disks Das Löschen der Registrierungen auf den Datendisks muss atomar ablaufen, also als Allesoder-nichts Operation. Ansonsten würden bei einem Heartbeat-Ausfall alle Nodes irgendwelche Registrierungen von irgendwelchen Disks löschen, was ein großes Chaos zur Folge hätte. Daher muss bei Ausbleiben des Heartbeats zunächst um das „Recht zu Löschen“ gefochten werden. Dies geschieht im Prinzip genau wie bei den Datendisks durch Löschen von Registration-Keys der „verlorengegangenen“ Nodes von ganz bestimmten, allen Nodes zugreifbaren Disks. Diese befinden sich in einer eigenen DiskGroup und werden ihrer Funktion entsprechend als Coordinator-Disks bezeichnet. Im Anschluss an den Löschversuch überprüft der löschende Node den Erfolg desselben. War der Node mit dem Löschen erfolgreich, so sind die „gegnerischen“ Keys von der Mehrheit der Coordinator-DiskGroup gelöscht. Auf diesem Node geht anschließend der Fencing Device-Driver dazu über, die Keys von allen importierten Shared DiskGroups zu löschen und danach eventuell ServiceGroups der nun fehlenden Nodes zu übernehmen. Auf einem Node, dessen Fencing-Versuch nicht erfolgreich war (er hat die „gegnerischen“ Keys nicht von der Mehrheit der Disks in der Coordinator-DiskGroup entfernt) löst der Fencing-Treiber eine System-Panic aus, bevor

had von GAB überhaupt über den fehlenden Node informiert wird und ServiceGroups übernehmen oder AutoDisablen könnte. Das Problem des konkurrierenden Löschens muss bei der Coordinator-DiskGroup natürlich ebenfalls abgefangen werden. Wie geschieht dies? Zunächst einmal sprechen wir hier von einer bestimmten, ausschließlich für die Mehrheitsentscheidung vorgesehenen DiskGroup, die selbst keine Daten enthält, sondern lediglich einige (sehr kleine) Disks oder LUNs. Damit erledigt sich jedes Problem der Dateninkonsistenz von selbst, da es keine Daten gibt. Die Coordinator-DiskGroup besteht aus einer ungeraden Anzahl Disks größer oder gleich drei, also 3, 5, 7 etc. Üblich sind tatsächlich drei. Alle diese Disks müssen von allen Nodes aus zugreifbar sein. Sie können über DMP mehrpfadig angeschlossen werden. Warum enthält die Coordinator-DiskGroup gerade drei Disks, warum nicht 1, 2 oder 100? Die Antwort ist dreiteilig: 1. Sie muss mehr als eine Disk enthalten, um bei Ausfall einer Disk noch funktionieren zu können. 2. Sie muss eine ungerade Anzahl Disks enthalten, um eine eindeutige Entscheidung zu ermöglichen. Bei einer geraden Anzahl könnte es geschehen, dass jeder Node die gleiche Anzahl Disks bekommt und so beide Subcluster eine Panic auslösen. 3. Sie sollte nicht sehr groß sein, denn erstens verursachen auch kleine LUNs Kosten, und zweitens sind zu viele LUNs in der Coordinator-DG unnötig. Sie bringen keinen Vorteil mehr. Wir kommen später noch auf das optimale Setup für die Coordinator-DiskGroup für verschiedene Szenarien zu sprechen. Registrierungen auf den Coordinator-Disks Die Coordinator-Disks werden nicht beschrieben, sondern es wird lediglich beim HeartbeatAusfall um sie gefochten. Deshalb brauchen sie nicht reserviert zu sein, denn die Reservierung führt lediglich zu einem Abweisen von Schreibzugriffen, wenn nicht der richtige Key mitgeliefert wird. Da die Coordinator-Disks nicht beschrieben werden, wäre eine Reservierung also überflüssig. Andererseits müssen aber alle Nodes des

259

29

I/O-FENCING Clusters an der Mehrheitsentscheidung mitwirken („mitfechten“) können, daher ist jeder Node registriert. Mithilfe dieser Registrierung ist jeder Node dazu in der Lage, die Registrierungen beliebiger anderer Maschinen zu löschen (Eject Key). Mehr zu Registrierungen und zum Löschen von Keys Was vielleicht nicht unmittelbar einleuchtet, ist, dass ein Node prinzipiell immer dazu imstande ist, sich selbst auf einer Disk zu registrieren unabhängig davon, ob die Disk von anderen Nodes reserviert wurde oder nicht. Denn auch Persistent Group Reservation (PGR) ist eine reine Goodwill-Reservierung, deren Konsistenz lediglich durch geeignete Program-

29.4

Konfiguration von I/O-Fencing

29.4.1

Am einfachsten funktioniert die Konfiguration von I/O-Fencing durch das Installationsskript (installer bzw. installvcs, installorarac, installcfs etc.). Installiert man das Cluster File System oder einen Oracle-RAC, so wird normalerweise stets Fencing konfiguriert, bei Installation eines einfachen Failover-Clusters kann dieser Schritt nachträglich rückgängig gemacht werden (siehe Hinweisbox). Hat man bereits einen laufenden, älteren VCS-Cluster ohne I/O-Fencing installiert und scheut daher eine Neuinstallation, so kann man dennoch den Installer zur Konfiguration der für das I/OFencing notwendigen Parameter verwenden, was die Vorteile hat, dass es erstens erheblich einfacher ist als das manuelle Neukonfigurieren und sich zweitens dieses Verfahren von Version zu Version nicht erheblich ändert. Dazu muss man den entsprechenden installer erneut aufrufen, wobei man ihm die Option -configure mitgibt, um so alle Konfigurationsabfragen erneut gestellt zu bekommen. So lässt sich Fencing auch nachträglich noch relativ einfach konfigurieren. Die wesentlichsten Parameter zur Konfiguration von I/O-Fencing sind die Frage, ob man es verwenden will oder nicht, sowie, im Falle der Verwendung, der Name der Fencing-DiskGroup. Auch ist es nützlich, wenn die FencingDIskGroup bereits angelegt ist, bevor man das Installationprogramm (erneut) aufruft.

260

mierung der beteiligten Softwarekomponenten gewährleistet ist. Ein böswillig programmiertes Shell-Script könnte durchaus auch durch PGR reservierte Disks überschreiben! Im Volume Manager-Teil haben wir bereits dargelegt, warum dies so ist; dass alles andere als eine Goodwill-Reservierung unsinnig wäre, weil sonst bei Ausfall eines Nodes die durch diesen reservierten Geräte – in VxVM waren es die DiskGroups – nicht mehr freigegeben werden könnten und für immer blockiert blieben. Hier sind es die PGR-reservierten DiskGroups, deren Reservation- und RegistrationKeys beim Wiederanlauf eines Clusters nach einem Node-Crash unter Umständen erst manuell von den Disks aller DiskGroups gelöscht werden müssen, weil sie sonst nicht importiert werden könnten.

Da bei Verwendung von I/O-Fencing die Frage nach der Redundanz der Heartbeat-Infrastruktur keine Rolle spielt, genügt theoretisch eine einzige Heartbeat-Leitung. VCS macht, wenn I/O-Fencing konfiguriert ist, keinen Unterschied zwischen einem redundanten und einem nicht redundanten Heartbeat, denn GAB löst bei Ausbleiben von Heartbeats als erstes den FencingMechanismus aus, der für die Arbitrierung der Datendisks sorgt. Erst wenn diese Arbitrierung abgeschlossen ist, wird VCS informiert. AutoDisabling ist also bei I/O-Fencing-Lösungen nicht vorgesehen, da es erst dann stattfinden würde, wenn der Fencing-Mechanismus bereits seine Arbeit getan hat und dann das AutoDisabling völlig sinnlos und höchstens kontraproduktiv wäre. Jeopardy spielt also keine Rolle mehr. Wie gesagt genügt also theoretisch eine einzige Heartbeat-Leitung, wenn I/O-Fencing konfiguriert ist. Allerdings würde dies bedeuten, dass der Ausfall einer einzigen Komponente (ein kurzes Kabelziehen des Heartbeats würde genügen) bereits zum Fencing mit allen Konsequenzen (Betriebssystem-Panic auf einem Node, u.U. komplizierter Wiederanlauf, evtl. Service-Downtime) führen würde. Um dies zu verhindern, und um möglichen Performanceproblemen zuvorzukommen, sollte mindestens ein weiterer Heartbeat-Link, also minimal zwei insgesamt, definiert werden.

29

I/O-FENCING VCS verlangt allerdings, dass die Disk-Hardware tatsächlich SCSI-3 PGR-konform ist, sie also PGRs tatsächlich versteht und korrekt implementiert. Um dies zu testen, wird ein Programm (ein Script, in das hineinzuschauen sich lohnt, wenn man mehr über I/O-Fencing lernen will!) mitgeliefert. Dieses Programm liegt in dem Pfad /opt/VRTSvcs/vxfen/ bin/vxfentsthdw. Es ist ein je nach Option interaktives Programm, mit dem Sie eigentlich jedes einzelne DiskDevice, das Sie im für I/O-Fencing konfigurierten Cluster benutzen wollen, testen sollten. Dies hat jedoch den großen Nachteil, dass das Programm versucht, Daten auf den getesteten Disks zu überschreiben, weil es testen muss, ob der Schutz gegen das Überschreiben funktioniert. Das ist natürlich ungünstig, wenn man nicht bei Null anfängt, sondern eine laufende Applikation mit ihren Daten integrieren muss. Für die Coordinator-Disks ist dies kein Problem, da diese ohnehin keine Daten enthalten dürfen. Für die anderen Disks, also den echten Storage, kann entweder ein Testmodus gewählt werden, der das Überschreiben vermeidet, dabei jedoch natürlich nicht gründlich testen kann (da er den Überschreib-Versuch auslassen muss), oder man testet bei Verwendung von gleichartigem Storage (LUNs im selben Array oder Disks der gleichen Serie) anhand einer leeren Disk oder LUN, ob die verwendete Version des Storage (Firmware plus Einstellungen) I/OFencing korrekt unterstützt. Ist dies gegeben, verlässt man sich darauf, dass die anderen Disks bzw. LUNs identisch sein werden. Beide Ansätze sind natürlich ein bisschen „mutig“. Ist die Disk-Hardware aber tatsächlich vom gleichen Firmwarestand und mit den gleichen Einstellungen versehen, so sollte es normalerweise funktionieren. Haben Sie den Cluster mit dem Installationsprogramm für I/O-Fencing konfiguriert, so werden Sie folgende Abweichungen von der vorherigen VCS-Konfiguration finden:

1. Die VCS-Clustervariable VCSMode ist auf den Wert VCS_RAC oder VCS_CFS gesetzt, je nachdem, ob Sie einen Oracle-RAC oder eine Cluster File System Variante installiert haben. Diese Variable informiert VCS über die Lizenz-Gegebenheiten. 2. Die Variable UseFence ist auf den Wert SCSI3 (statt NONE) gesetzt. Dies instruiert VCS darüber, welcher Mechanismus intern ablaufen muss, wenn er durch GAB über die Änderung einer Cluster-Membership informiert wird. Momentan ist SCSI3-PGR derzeit der einzige unterstützte Mechanismus, aber tatsächlich gibt es bereits in Version 5.0 der Storage Foundation einen völlig anderen I/O-Fencing-Mechanismus, der über IP funktioniert und bei dem die Registration-Keys durch einen externen Cluster verteilt werden. Dafür wird diese Variable benötigt, die das verwendete I/OFencing-Verfahren definiert. 3. Es gibt eine neue Datei /etc/vxfendg, in welcher der Name der CoordinatorDiskGroup vermerkt ist. Aus diesem Eintrag wird beim Starten des Fencing-DeviceDrivers in /etc/init.d/vxfen eine weitere neue Datei erzeugt, nämlich die Datei /etc/vxfentab. In dieser sind alle Pfade zu allen Coordinator-Disks hinterlegt, damit der Fencing-Driver direkt auf diesen Pfaden arbeiten kann, falls es einmal zur Arbitrierung mittels I/O-Fencing kommt. Allerdings werden die Pfade nicht durch Import der Coordinator-DiskGroup und Auslesen der Konfiguration erzeugt, sondern mit Hilfe eines sehr kruden Verfahrens, nämlich in Version SF4.1 mit vxdisk -o alldgs list | grep $DG. Es ist wichtig, sich über diese Tatsache klar zu sein, da die normalen Mechanismen zur sicheren und zuverlässigen DiskGroupPopulation bei der Coordinator-DiskGroup nicht die erhoffte Wirkung haben müssen. Diese Einschränkung ist insbesondere bei Umkonfigurationen dieser DiskGroup nach Ausfall eines Rechenzentrums bzw. Brandabschnitts kritisch!

Hinweis I/O-Fencing wird auskonfiguriert durch Entfernen von „UseFence = SCSI3“ aus der main.cf und echo `vxfen_mode=disabled` >/etc/vxfenmode auf allen Nodes und Reboot.

261

29 29.5

I/O-FENCING Wiederanlauf nach erfolgreichem I/O-Fencing Wiederanlauf nach I/O-Fencing l

Node 0 wurde gestoppt, sein Key dabei durch Node 1 von den Coordinator-Disks gelöscht. l Node 1 fällt danach aus, sein Key verbleibt auf den Coordinator-Disks. l Node 0 kann anicht wieder hochgefahren werden,13·5 da aufgrund der Keys auf den Coordinator-Disks NetworkPartition vermutet wird. l Kein Problem, wenn Node 1 der Membership beitritt. l Sonst vxfenclearpre aufrufen, um Keys manuell zu löschen. 29.5

29.5.1

Wiederanlauf nach I/O-Fencing Der Wiederanlauf nach einem erfolgten I/OFencing gestaltet sich im Normalfall problemlos. Startet die ausgefallene oder durch I/O-Fencing zur System-Panic gezwungene Maschine wieder, so werden als unterstes Element des Heartbeat-Stacks zunächst LLT und dann GAB gestartet. Ist die Heartbeat-Infrastruktur in Ordnung, so tritt die Maschine nun dem Cluster bei („Cluster-Join“), worüber jeder Node des Clusters im selben Moment informiert wird. Sie registriert sich auf den Coordinator-Disks, öffnet dadurch ihren Port b (den I/O-FencingPort), wird durch den VxVM Master-Node auf den Datendisks registriert (in der Version 4.x ist der parallele Volume Manager noch ein Master/Slave-Konzept, in 5.0 wird die MasterFunktionalität verteilt sein) und kann anschließend ihre Arbeit im Cluster aufnehmen. Anders sieht es jedoch in besonderen Situationen aus. Diese können zu erheblicher Verwirrung und Verunsicherung führen, deshalb ist es gut, wenn man Mechanismen von I/O-Fencing wenigstens im Grundsatz gut verstanden hat. Grundsätzlich dürfen sich nur Nodes auf den Disks (egal ob Daten- oder Coordinator-Disks) registrieren, die sich in einer gültigen ClusterMembership befinden, und auch nur wenn sich keine Registrierungen von Nodes außer-

262

halb der Membership auf den Disks befinden. Da durch das Seeding auf Port a von GAB zuverlässig verhindert wird, dass sich unabhängig voneinander mehrere gültige ClusterMemberships bilden, ist dieses Kriterium normalerweise ausreichend für die Entscheidung, ob eine Registrierung vorgenommen werden darf oder nicht. Im Umkehrschluss bedeutet dies jedoch auch, dass unter gewissen Umständen keine Registrierung erfolgen kann und der bootende Node schlicht stehenbleibt und auf die Entscheidung eines Administrators wartet. Die geschieht zum Beispiel in folgendem Szenario: Node 0 eines laufenden 2-Node Clusters wird für Wartungsarbeiten normal heruntergefahren (init 5), wodurch die Registration-Keys dieses Nodes von den Daten- und CoordinatorDisks gelöscht werden. Fällt nun Node 1 aus, so fährt der Administrator natürlich umgehend Node 0 wieder hoch, um den Dienst wiederherzustellen. Allerdings findet der startende Node 0 seine Keys nicht auf den Disks vor, denn die wurden beim Herunterfahren gelöscht, und er kann nicht der ClusterMembership beitreten, da dazu einmalig alle Nodes des Clusters benötigt werden.

29

I/O-FENCING Zwar kann man die Bildung einer Membership forcierten, indem man manuell das Kommando / s b i n / g a b c o n f i g - c x absetzt, wodurch alle momentan auf dem HeartbeatNetz sichtbaren Maschinen augenblicklich eine Membership bilden. Jedoch reicht dies im Falle von I/O-Fencing nicht aus. Denn der Node findet nun Keys eines Nodes auf den Coordinator-Disks vor, der nicht Teil seiner Cluster-Membership ist und vermutet daher eine „pre-existing network partition“, also eine Separation der Nodes auf dem Heartbeat-Netz beim Start des Clusters. Der vxfen-Treiber erkennt diese Situation und gibt aus, dass er eine „pre-existing network partition“ vermutet und deshalb nicht automatisch starten wird. Er schlägt vor, falls man sicher ist, dass die andere Maschine tatsäch-

lich heruntergefahren ist, mit dem Programm /opt/VRTS vcs /vxfen / bin/vxfenclearpre alle Keys der fremden Nodes von den Disks zu löschen. Ist man sich dieses Zustandes sicher, so stellt dies tatsächlich einen sicheren und schnellen Wiederanlaufmechanismus dar. Das Programm registriert dazu einen temporären Key (-m -k ) auf den Disks und benutzt diesen, um die Keys der anderen Maschinen (Victim-Keys, -v) von den Disks zu entfernen und de-registriert sich anschließend selbst (-x -k ) . Man kann dies grob durch folgende Befehlssequenz nachbilden: vxfenadm -mk -f /etc/vxfentab vxfenadm -pk -f /etc/vxfentab -v A------vxfenadm -xk .

29.6

Problematische Setups bei I/O-Fencing Problematische Setups bei I/O-Fencing l

Split-DataCenter Setup riskant bei DataCenter-Ausfall l Wiederanlauf nach Fencing kann kompliziert sein l Im jedem Zweifelsfall Auslösen einer System-Panic., daher 13·5 besonders zuverlässige Netzwerkinfrastruktur nötig

29.6

Problematische Setups und Situationen für I/O-Fencing Leider eignet sich I/O-Fencing nicht unbedingt für alle Anwendungsfälle. Die Tatsache, dass bei Ausbleiben von Heartbeat-Links unter allen Umständen ein Fencing-Versuch stattfindet und dass dieses Fencing auf einer QuorumEntscheidung (Mehrheit der Stimmen) basiert, kann bei gewissen Setups zu Ergebnissen führen, die nicht den Erwartungen entsprechen.

29.6.1

Im folgenden stellen wir einige Szenarios vor, die aus dem Leben gegriffen sind (es handelt sich um tatsächliche Vorkommnisse). 1. Site-Ausfall bei Split-Data-CenterCluster (Campus-Cluster) Bei diesem heute sehr verbreiteten Ansatz werden in der Regel Zwei-Node-Cluster mit ge-

263

29

I/O-FENCING spiegeltem Storage aufgebaut, deren eine Hardwareseite sich in einem anderen Rechenzentrum befindet als die andere Seite. Sprich: Node 0 sowie ein Plex jedes Volumes befindet sich an Site A, Node 1 und der andere Plex an Site B. (Die Distanz zwischen den Sites darf aufgrund der mit zunehmender Entfernung wachsenden Latenzen 30 Kilometer nicht überschreiten, ohne dass zuvor genauere Überprüfungen angestellt werden.) Bei Diskausfall tritt die Redundanz im VolumeManager ein und hält die Volumes online. Bei Nodeausfall übernimmt wie üblich der andere Node, um den Service oben zu halten. Allerdings muss hier darauf geachtet werden, dass auch die gesamte Infrastruktur auf der anderen Seite zur Verfügung steht bzw. angepasst ist. Dazu gehört zum Beispiel das Routing der IP-Adressen, Anschlussports für externeQueueManager oder Scheduler und so weiter. Außerdem muss sichergestellt sein, dass die Leitungsführung der redundanten Heartbeats über die gesamte Strecke physisch redundant ist, also nicht etwa zwei logische Kanäle auf derselben physischen Glasfaserstrecke geführt werden, was leider nicht selten ist. Split-Data-Center Cluster sind oft komplexer, als man auf den ersten Blick denken würde. Gelegentlich fällt auch einmal ein Rechenzentrum komplett aus. Das ist häufiger, als Sie vielleicht denken. Damit Sie sich des Problems bewusst werden, hier zunächst einige tatsächliche (aus rechtlichen Gründen leicht abgewandelte) Ausfall-Beispiele aus der Praxis der letzten Jahre: A. Es genügt schon, die Verpackung einer neuen Maschine an die Wand zu lehnen, an der sich der Not-Aus Knopf befindet. B. Es schlägt ein Rauchmelder an, weil ein ungelernter Servicetechniker mit Zigarette ins Rechenzentrum geht. Das löst die Sprinkler-Anlage aus (nicht überall wird mit Halon oder CO2 gelöscht), und die Maschinen werden erst nass und dann verschrottet. Besonders hart ist es, wenn die Sprinkleranlage den Stromversorgungskomplex löscht. C. Ihr Wartungsdienst hat die ErdungsSicherung nach einer vorgeschriebenen Frist durch eine neue ersetzt, die zwar die gleiche Leistung hat, aber nicht vom trägen, sondern vom flinken Typ ist. Diese

264

schlägt beim nächsten Generatortest durch, sobald die Lastspitze vom Generatoreinsatz kommt. D. (Ein Beispiel aus Texas) Jeden Freitag abend grillen die Administratoren Steaks vor der offenen Außentür des Rechenzentrums, weil es dort „so schön kühl“ ist. Abgesehen von dem Rauch und Fett in den Filtern der Netzteile belastet dies natürlich die Klimaversorgung des Rechenzentrums aufs äußerste. Da sie an denselben Stromkreisen hängt wie die Server, reißt ihre durchschlagende Sicherung alles mit herunter. E. Beim Ersetzen der sehr alten Hauptstromleitungen werden die alten Leitungen auf recht unelegante Weise aus ihren Befestigungen gelockert (Brecheisen). Dadurch wird die Isolierung beschädigt und die Hauptsicherung schlägt durch. F. Es wird übersehen, den Gesamt-Stromverbrauch zu überwachen. Bei Inbetriebnahme eines neuen (kleineren) Servers wird einer der Stromkreise überlastet und die Sicherung der ersten Phase schlägt durch. Daraufhin übernehmen die Maschinen eines anderen Stromkreises die Arbeit, was prompt zur Überlastung der nächsten Phase führt und so fort. Kommen wir zu den unschönen Folgen eines solchen Ausfalls: Jeder Cluster, der sich auf irgendeine Art von Quorum-Entscheidung zur Split-Brain-Vermeidung verlässt, erleidet mit 50%iger Wahrscheinlichkeit einen vollständigen Dienstausfall, da die überlebende Seite das Quorum nicht reservieren kann und Panic auslöst. Denn mit einer 50%-igen Wahrscheinlichkeit befindet sich das Quorum (bei I/O-Fencing mit VCS ist dies die Mehrheit der Coordinator-Disks) im ausgefallenen Rechenzentrum, was eine Akquisition des Quorums unmöglich macht. Als ob dies nicht schlimm genug wäre, kommt dann eine erheblich kompliziertere Wiederanlaufphase hinzu. Denn solange das Rechenzentrum ausgefallen bleibt, kann der Cluster nach seiner Betriebssystem-Panic nicht wieder starten, da er auch dazu die Mehrheit der Coordinator-Disks benötigt, die aber nicht zugreifbar sind. Um bei Verwendung von I/O-Fencing gegen den Ausfall eines Rechenzentrums gewappnet zu

29

I/O-FENCING sein, gibt es zur Zeit nur eine einzige Lösung: Die Bereitstellung einer dritten Lokation, in der sich entweder alle oder zumindest eine Coordinator-Disk jedes Clusters befindet. Verzichtet man auf I/O-Fencing und verwendet stattdessen GAB-Disks (mindestens eine pro Lokation), so kann GAB anhand der Information auf den Disks noch herleiten, ob der andere Node tatsächlich ausgefallen ist oder noch Heartbeats schickt. Denn GAB benötigt keine Mehrheit, sondern es genügt lediglich irgendeine GAB-Disk, die noch Heartbeat-Signale liefert, um eindeutig feststellen zu können, dass ein System noch arbeitet (das ist logisch, denn wo sollten die Heartbeat-Signale auf dieser Disk sonst herkommen, wenn nicht von dem noch lebenden Node?). Bei Verwendung mehrerer GAB-Disks empfehlen wir allerdings vorherige Tests mit der verwendeten Softwareversion, da dieses Verhalten unter Umständen nicht durch alle Versionen beibehalten wird. Übrigens kann man ein Rechenzentrum natürlich nicht einfach „neu starten“. Es beherbergt oft hunderte oder tausende von Maschinen, jede mit eigenen Restartprozeduren, von denen nicht alle automatisch ablaufen, und mit unglaublich komplexen gegenseitigen Anhängigkeiten. Switch-Infrastrukturen müssen ihre SpanningTrees wiederaufbauen, Storage-Arrays ihre internen Volumes resynchronisieren, Cluster müssen ihre Memberships neu aufbauen und so weiter. Ungünstigerweise können viele dieser Aktionen nicht unabhängig voneinander ablaufen, und vieles braucht manuelle Eingriffe durch wirklich gut ausgebildete Spezialisten, die natürlich rar sind und nicht überall zugleich sein können. Cluster-Nodes brauchen eine funktionierende Netzwerk-Infrastruktur, da sie sonst ihne Heartbeat-Leitungen nicht verwenden können. Damit die Cluster-Nodes ihren Storage ansprechen können, muss die Fibre-Channel-Infrastruktur funktionieren. Dies dauert aber ebenfalls eine geraume Zeit, bis die Switches gebootet und initialisiert sind und dann hoffentlich auch korrekt funktionieren. Bis dahin könnten in den startenden Nodes bereits alle Timeouts für den Storage abgelaufen sein und die Maschinen geben quasi auf und müssen erneut durchgestartet werden. Besonders interessant ist dies mit den Maschinen, die für die Wartung des Storage selbst vorgesehen sind, da sich hier u.U. die Schlange in

den Schwanz beißt. Der Wiederanlauf eines Rechenzentrums ist insgesamt eine Sache, die nicht Minuten, sondern Stunden und manchmal Tage dauert. Er ist ausgesprochen heikel und anstrengend, mit hohem Stressfaktor. Was machen wir also mit unseren VCS-Clustern, die wegen I/O-Fencing Selbstmord begangen haben? Eine schnelle Wiederanlaufprozedur für einen mit I/O-Fencing konfigurierten VCS-Cluster nach Ausfall einer Site setzt voraus, dass auf beiden Seiten jeweils drei Fencing-Disks (bzw. LUNs) bereitstehen. Insgesamt sind jedoch nur drei in die I/O-Fencing-DiskGroup (gleichbedeutend mit Coordinator-Disks) zu konfigurieren. Die anderen drei kann man zum Beispiel zu einer „Spare-Fencing-DG“ zusammenfassen. Diese Disks verteilt man jeweils im Verhältnis 2:1 bzw. 1:2 oder auch 3:0 bzw. 0:3 auf die Sites. Beim Wiederanlauf eines Nodes, der Panic auslöste, weil die Mehrheit der Coordinator-Disks auf der ausgefallenen Seite lag, muss für diesen Node zunächst eine neue Coordinator-DiskGroup bereitgestellt werden. Dazu wird aus insgesamt drei zugreifbaren Disks der Spare-Fencing-DG und der OriginalFencing-DG eine neue Fencing-DiskGroup gebildet. Anschließend muss im Zweifelsfall mit vxfenclearpre ein evtl. noch vorhandener Key der anderen Maschine von diesen Disks entfernt werden. Danach kann der Node komplett gestartet werden, wobei wir allerdings die Bildung einer Cluster-Membership mit gabconfig -cx erzwingen müssen, da die andere Maschine noch nicht auf dem GAB-Port a antwortet. Wegen der zumindest bis zur Version SF4.1 sehr ungünstigen Implementation der Konvertierung von DiskGroup- zu DevicepfadInformation muss beim Wiederanlauf des Nodes auf der ausgefallenen Seite unbedingt zuerst die alte Fencing-DiskGroup zerstört werden. Sonst könnte sich tatsächlich eine Split-Brain-Situation einstellen. Die alte Fencing-DiskGroup wird also zerstört und die neue muss zugreifbar sein. Erst dann kann (durch das rc-Script mit vxdisk -o alldgs list | grep $DG , s.o.) die /etc/vxfentab korrekt initialisiert und kann ihre Aufgabe erfüllen.

265

29

I/O-FENCING In der Zukunft wird Fencing auch über TCP/IP möglich sein, indem ein separat (an einer dritten Lokation!) aufgestellter VCS-Cluster mit der Verteilung von Keys beauftragt wird. Zwar wird auch hier eine dritte Lokation benötigt, jedoch muss diese nicht über Fibre bzw. SCSI erreichbar sein, sondern lediglich über IP, kann sich also im Grunde irgendwo auf der Welt befinden. Dies ist natürlich eine erhebliche Erleichterung gegenüber der direkten Anbindung über Fibre-Channel. 2. Anfällige Netzwerkhardware Ein zweiter Fall, in dem man mit GAB-Disks hervorragend bedient wäre, ist bei einer unzuverlässigen Netzwerkinfrastruktur gegeben. Fallen häufiger Switches oder Ports des Netzwerks aus, so sind die Chancen nicht schlecht, dass irgendwann alle Heartbeat-Links eines oder mehrerer Cluster gleichzeitig betroffen sind. Während eine GAB-Disk diese Situation elegant lösen würde (kein Diensteausfall, sondern AutoDisable, bis eine Heartbeat-Leitung wieder aktiv wird), würde eine I/O-FencingLösung sofort zu einer System-Panic auf einem der Nodes führen und der Service würde beim 2-Node-Cluster mit 50%-iger Wahrscheinlichkeit schwenken und recovern müssen. 3. Zu wenige verfügbare Heartbeat-Leitungen Es gibt zwei Wege, einen VCS-Cluster mit nur einer Ethernet Heartbeat-Leitung so zu konfigurieren, dass er seine volle Funktionalität erreicht: Entweder man benutzt I/O-Fencing zur Absicherung gegen Ausfall der Netzwerkhardware, oder die GAB-Disk-Funktionalität. Verwendet man GAB-Disk, so wird bei Verlust des Ethernet-Links lediglich ein AutoDisable durchgeführt. Alle Services bleiben in ihrem bisherigen Zustand. Konfiguriert man I/O-Fencing, so führt das Ziehen eines Kabels zur System-Panic auf einem Node und Übernahme der ServiceGroups auf dem anderen. Zusammenfassen kann man sagen, dass I/OFencing die vollständig sichere, allerdings vergleichsweise brutale Methode der Split-BrainVermeidung darstellt. Sie kann bei Split-DataCenter Clustern extrem problematisch sein. GAB-Disk-basierte Lösungen sind stets eleganter und tendieren dazu, im Zweifelsfall die

266

ServiceGroups weiterlaufen zu lassen, können dafür aber den Rejoin nach Überlastung oder temporärem Anhalten der CPU sowie den gleichzeitigen Ausfall aller Ethernet-Heartbeats und aller GAB-Disks nicht verkraften (letzteres ist allerdings auch nicht gefordert, da grundsätzlich keine Doppelfehler abgefangen werden müssen - der dafür nötige Aufwand wäre unkalkulierbar). Welchen Weg soll man also gehen, wenn man eine Hochverfügbarkeitslösung über zwei Rechenzentren spannen will? Da sind zwei Ansätze denkbar: Kann man mit Sicherheit extreme Überlastsituationen ausschließen, so wäre die naheliegende Variante die Verwendung von GAB-Disks oder eines weiteren (dritten) LLT-Links via UDP auf FibreChannel. Kann man die Überlastung nicht ausschließen, so bliebe außer der nachgewiesen problematischen Lösung mit I/O-Fencing nur noch der Weg über einen Replikationscluster (mittels der VCS Global Cluster Option). In dieser Variante wird auf jeder Site ein eigener Cluster aufgesetzt und die Daten mittels einer Replikationslösung (Veritas Volume Replicator, EMC SRDF, HDS HORC o.Ä.) auf den Remote Cluster übertragen. Bei Ausfall eines Nodes wird lokal übernmmen, bei Ausfall der Site wird über geeignetes Messaging eine manuelle(!) Übernahme der Services auf der RemoteSite eingeleitet, indem die Replikationsrichtung umgedreht wird und so die bisher passive Seite des Storage nun aktiv wird, sodass anschließend die Volumes gemountet und die Dienste gestartet werden können. Diese Lösung kann allerdings sehr teuer werden, da eigentlich sowohl der Storage als auch die Nodes lokal und remote doppelt vorhanden sein müssten, was bedeutet, dass man anstatt einer einzelnen Maschine insgesamt drei oder vier Maschinen (und Storage) aufstellen muss. Diese Lösung ist in diesem Buch nicht berücksichtigt worden, da sie aufgrund ihrer Komplexität den Rahmen sprengen würde und ohnehin nur mit fähigen Consultants implementiert werden sollte. Letzendlich muss man selber entscheiden, welcher Weg sich für das gegebene Problem am besten eignet. Die Basis für die Entscheidung hoffen wir mit diesem Buch gegeben zu haben.

I/O-FENCING

29

Übung: Konfiguration und Test diverser Szenarien

Ü 29

Übungen zu I/O-Fencing l

Fencing-DiskGroup aus drei kleinen, datenlosen Disks bzw. LUNs erzeugen. Cluster (z.B. durch Re-Installation bzw. Upgrade auf Cluster File System) mit zwei HeartbeatLeitungen für I/O-Fencing konfigurieren. l Mit vxfentsthdw die SCSI-3-Konformität der Disks überprüfen. l Ausfallszenarien durchspielen: - Ausfall eines Nodes, danach Wiederanlauf - Ausfall eines Links - Ausfall des zweiten Links, nachdem der erste bereits ausgefallen war, danach Wiederanlauf - Ausfall beider Links binnen vier Sekunden, danach Wiederanlauf - Herunterfahren Node 0, Ausfall Node 1, Starten Node 0 (siehe unter „Problematische Setups…“) - Ausfall eines Nodes und der Mehrheit der Coordinator-Disks binnen vier Sekunden (simulierter Site-Ausfall), danach Wiederanlauf l

Konfigurieren Sie Ihren Cluster mit Hilfe des Installers neu für I/O-Fencing bzw. upgraden Sie ihn zu einem Cluster File System (dort ist I/O-Fencing Pflicht). Richten Sie dazu eine CoordinatorDiskGroup aus drei oder fünf kleinen Disks ein, die keine Daten enthalten. Konfigurieren Sie zwei oder mehr Heartbeats für den Cluster, um die Unterschiede zum Ausfall von Heartbeat-Links beim normalen Cluster nachvollziehen zu können.. Überprüfen Sie die SCSI-3-PGR-Fähigkeiten der Disks mit Hilfe des Programms vxfentsthdw (Achtung: die Daten auf diesen Disks können dabei zerstört werden!). Öffnen Sie auf jedem System vor jedem Test ein Console-Fenster, sodass Sie die Meldungen der LLT- GAB- und vxfen-Device-Treiber beobachten können. Spielen Sie die obigen Testszenarien durch und stellen Sie fest, welche Prozeduren Probleme bereiten und wie diese zu lösen sind.

267

INDEX Symbole $VCS_HOME/bin/hagui ...................................... 162 $VCSCONF/main.cf .....................................154, 237 $VCSCONF/sysname ............................................ 154 $VRTSCONF/.stale ................................................ 163 .stale ........................................................................ 163 / .......................................................112, 113, 115, 117 /dev/dsk.............................................. 19, 26, 36, 115 /dev/rdsk ..................................................... 19, 26, 36 /dev/vx/dsk ...............................19, 26, 37, 115, 215 /dev/vx/rdsk ...................................................... 19, 26 /etc/apache ............................................................ 217 /etc/apache/httpd.conf ....................................... 202 /etc/gabtab ............................... 154, 157, 228, 232 /etc/group............................................................... 143 /etc/hostname.* .................................186, 197, 249 /etc/init.d/vxfen .................................................... 261 /etc/inittab ..............................................................115 /etc/llthosts.........................................154, 157, 165 /etc/llttab ............................................154, 157, 258 /etc/netmasks ...............................................195, 205 /etc/passwd............................................................ 143 /etc/system ..12, 111, 113, 114, 115, 116, 117, 143 /etc/vfstab ................... 12, 111, 113, 115, 116, 186 /etc/VRTSvcs/conf/config ................153, 157, 163 /etc/VRTSvcs/conf/config/.stale ....................... 164 /etc/VRTSvcs/conf/config/main.cf ..........154, 157 /etc/vx/volboot.......................................................118 /etc/vxfendg .......................................................... 261 /etc/vxfentab ......................................................... 261 /kernel/drv .....................................................121, 143 /opt/VRTSllt/sample-llttab................................. 226 /opt/VRTSvcs/bin .........................................153, 157 /opt/VRTSvcs/bin/hagui ...................................... 169 /opt/VRTSvcs/bin/hatrigger ............................... 238 /opt/VRTSvcs/bin/Mount/MountAgent .......... 181 /opt/VRTSvcs/bin/triggers .................................. 238 /opt/VRTSvcs/bin/triggers/violation ................ 209 /opt/VRTSvcs/vxfen/bin/vxfenclearpre ........... 263 /sbin/gabconfig -cx ............................................. 263 /sbin/in.mpathd .................................................... 251 /sbin/init ..................................................................115 /usr .................................................112, 113, 115, 117 /usr/apache ............................................................ 217 /usr/apache/bin/httpd ..........................................211 /usr/lib/inet/in.mpathd ....................................... 251 /usr/openwin/bin/xclock .................................... 164 /var ..........................................10, 112, 113, 115, 117 /var/apache ............................................................ 217 /var/VRTSvcs/log ..........................................153, 157 /var/vxvm/tempdb ..........................................24, 118

A Abbruch von Online- und Offline-Vorgängen .. 167 Abhängigkeiten..................................................... 142 Abhängigkeiten (Dependencies) ...................... 188 Accessname ..............................................................12 ACK........................................................................... 179 Acknowledge ......................................................... 176 ACTIVE ........................................................................60 Active-Active.................................................. 18, 147 Active-Passive ....................................................... 146 Address.................................................195, 246, 248 Admin-IP .............................................242, 243, 250 Adressbereich ............................................ 36, 38, 41 Adressraum ...............................................................36 Agent ....................................................145, 187, 190 Agent-Binary ......................................................... 181 Agents ..................................................................... 180 AIX ..........................................................................7, 13 Aktuator .....................................................................53 aligned .......................................................................50 Alive-Signale und Info ........................................ 230 Allokation ...............................................7, 30, 72, 74 Allokationseinheit ...................................................44 Allokation von Speicher ........................................26 Amdahl ......................................................................... 7 Analyse .................................................................... 142 AND .............................................................................29 Änderung des Volume-Layouts ...........................88 Anlegen einer Subdisk ...........................................39 Anlegen eines Plexes ..............................................38 Anlegen eines Volumes..........................................36 Application-Resource ......................................... 214 Application-Server ............................................... 142 Application Director ............................................ 143 Applikation....................................................143, 258 Arbitrierung der Datendisks .............................. 260 Architektur von VCS ...................................138, 174 ArgList ..................................................................... 190 ArgListValues ................................................182, 190 Arguments.............................................................. 164 ArpDelay ................................................................. 244 ATA ................................................................................ 6 atomar ..................................................................... 259 Atomic Broadcast........................................176, 179 Attribute ................................................................. 194 Ausbleiben des Heartbeat...............256, 257, 259 Ausfall .............28, 46, 52, 53, 139, 141, 144, 147, 227, 256, 264 Ausfall (Rechenzentrum) ................................... 264 auto-boot? ..............................................................114 AutoClear ............................................................... 199 AutoDisable ................V, 230, 254, 255, 260, 266 AutoFailover .......................................................... 166 autoimport-Flag ................................................... 221 AutoRestart............................................................ 198 AutoStart ................................................................ 170 AutoStartList ...................................... 165, 170, 236

269

B Backup........................................................................99 Backup-Modus (Datenbank) ................................96 BaseResName ........................................................ 248 Basis-IP ................................................197, 242, 243 Berkeley .....................................................................27 Best Practice..............................................................IV Betriebssystem .........................................................10 Betriebssystem-Panic........16, 38, 146, 226, 228, 229, 231, 255, 256, 257, 258, 260, 264 BlockDevice............................................................ 216 boot ...........................................................................113 Boot-Code ......................................................110, 114 boot-device.............................................................114 Boot-Disk.................................................................110 Boot-Informationen .............................................110 Boot-Konfigurationsdatei ...................................114 boot-mode ..............................................................115 Boot-Partition ........................................................110 Boot-PROM.............................................10, 112, 114 Boot-Request ........................................................ 177 boot.conf .................................................................114 bootbare Disk ......................................................... 111 bootdg ..................................................... 20, 115, 118 Bootdisk .....................................................................10 bootkritische Volumes .........................................112 Bootvorgang ....................................................10, 112 Bottleneck ..........................................................28, 51 Bottom-Up ................................................................44 Broadcast ............................................................... 176 Broadcast-Domain ......................................152, 157

C Campus-Cluster .................................................... 263 CDS............................................................... 12, 13, 16 cdsdisk ........................................................13, 14, 111 cfgadm ......................................................................... 6 Checksummenverfahren........................................27 CHS ............................................................................... 6 CkptUmount .......................................................... 216 clean-EntryPoint .................................................. 167 CleanProgram...............................................214, 215 Clear......................................................................... 166 CLI....................................................................194, 237 Client-Server ................................................139, 144 Cluster .............. 19, 123, 138, 142, 145, 221, 259 Cluster-Exit ............................................................ 178 Cluster-Hardware ................................................ 152 Cluster-ID ......................................................154, 156 Cluster-Join ..................................................178, 262 Cluster-Konfiguration ......................................... 154 Cluster-Layer ......................................................... 178 Cluster-Membership ........................................... 262 Cluster-Monitor...........................................153, 176 Cluster-Name ........................................................ 156 Cluster-Problematiken........................................ 226

270

Clusterbetrieb........................................................ 186 clusterglobale Variablen .................................... 174 Clusterknoten ...........................................................18 ClusterService ....................................................... 157 Clustersoftware ............................................. 18, 153 Clusterverhalten ................................................... 165 Cluster File System ........................... 221, 254, 257 Cluster Maintenance ........................................... 138 Coexistence Label ...................................................13 Column .........................................................49, 51, 61 Commit ................................................................... 176 Compaq ........................................................................ 7 Concat ..... 28, 29, 38, 40, 46, 47, 50, 51, 80, 88, 90, 134 concat-mirror ................................................... 80, 90 Concatenation .........................................................27 Concurrency Violation ..................... 209, 210, 231 ConfigCheck........................................................... 250 ConfInterval ..................................................166, 200 Container ...................................................................37 ContainerName..................................................... 215 Content Management ........................................ 222 Controller .................................................................... 7 Controllerpfad ............................................................ 7 Coordinator-DiskGroup ...................258, 259, 267 Coordinator-Disks .............................259, 262, 264 Copy On First Write ................................................97 CPU-Belastung.........................................................50 Crash während des Schreibens ...........................56 Critical .................................................. 165, 188, 210 Cross-Platform Data Sharing....................... 13, 14

D Data Change Log .................................................. 100 Data Change Object ............................................ 100 Dateien .................................................................... 142 Datenbank .........16, 36, 47, 51, 56, 96, 141, 142, 220, 222, 256 Datendisk.......................................................258, 259 Datendurchsatz .......................................................47 Datenkonsistenz bei redundanten Volumes ....56 Datenkorruption ..........................................231, 254 Datensicherung..................................................... 141 Datensicherungssoftware .................................. 143 Datenstruktur ...........................................................38 DCO .................................................................100, 108 DCO-Bitmap .......................................................... 108 DCO-Logs mit integriertem DRL .......................101 Dead-Man Switch ................... 146, 226, 254, 256 Death before Corruption ...........................141, 254 Debugging .............................................................. 156 DEC ................................................................................ 7 dedizierte Verbindung ......................................... 152 defaultdg ..........................................................20, 118 degradierter Zustand (RAID-5)............................52 Dependencies ..................145, 154, 188, 189, 197 Deport......................................................19, 102, 221

Deportieren von Snapshots ............................... 102 Detail-Window ..................................................... 162 devalias ...........................................................112, 114 devfsadm ..................................................................... 6 Device ................................195, 244, 246, 249, 250 Device-Pfad ........................................................... 220 Device-Treiber ..................................19, 36, 37, 123 DeviceChoice ................................................248, 249 Dienst .........................................................................18 Dienstausfall.......................................................... 264 Digital Equipment ..................................................... 7 Dimensionierung .........................................143, 147 DIRTY ........................................................................101 Disk................................................... 42, 47, 142, 215 Disk-Heartbeat ..................................................... 227 Disk-Resource ..............................................216, 217 Diskausfall ....................................................... 30, 264 Diskformat.................................................................13 Diskgeometrie ..........................................................50 DiskGroup ..... 6, 11, 18, 19, 42, 102, 142, 215, 220, 256, 257, 260 DiskGroup-Agent.................................................. 258 DiskGroup-Resource ............................................ 221 DiskGroup Split & Join .............................. 102, 103 DiskReservation .................................................... 215 Disk Interleaving Factor ........................................48 Distributed Parity ....................................................28 DLPI (Data Link Provider Interface) ................. 175 DMP ................................................. 6, 121, 122, 259 DNS .......................................................................... 195 Doppelfehler .......................................................... 266 Downtime .......................................................... 5, 242 DRL (Dirty Region Log) ...........59, 65, 84, 85, 108 DRL Bitmap ............................................................ 108 Dummy-Resource................................................. 245 Dynamic Multi Pathing (DMP) .....................6, 121

E EBN (Enclosure Based Names) ............................12 ECC (Error Correction Code).................................29 Edge & Infrastructure-Server ..............................12 EEPROM ...................................................................110 ElifNone-Resource ................................................210 EMC2 Symmetrix ...................................................... 4 EMC SRDF .............................................................. 266 Enabled .............................164, 166, 180, 196, 231 engine_A.log.......................................................... 153 Enkapsulieren einer Disk .....................................110 Enkapsulierte Boot-Disk ......................................110 Enterprise-Agent .................................................. 222 Enterprise-Anwendung .........................................97 Entfernen von Spiegeln ..................................70, 74 Entry-Point.......................................... 181, 182, 194 Entwicklung der Hard-Disks ................................47 Environment der EntryPoint-Skripte .............. 168 Environment des Agents .................................... 168 Environment des had .......................................... 168

Erkennung nichtsynchroner Inhalte ..................58 Escape-Sequenz ....................................................171 Ethernet-Device.................................................... 154 Ethernet-Komponenten...................................... 175 Ethernet-Link ........................................................ 266 Exit-Code.......................................................182, 183 explizite Nachrichten .......................................... 176 Explorer-Leiste ...................................................... 162 Extent ................ 5, 10, 30, 38, 39, 41, 56, 88, 112 Extentadressierung ................................................... 7

F Failover.................... 153, 164, 166, 188, 210, 242 Failover-ServiceGroup ...............................149, 208 Failovertest ............................................................ 142 fastresync (siehe auch FMR) ............................. 100 FAULTED ............................165, 166, 169, 198, 200 FaultOnMonitorTimeouts ..........................199, 200 fc ............................................................................... 120 FCODE .......................................................................114 Fehlerbereinigung ................................................ 166 Fehlverhalten......................................................... 176 Fehlverhalten des Clusters ................................ 169 Fibre-Channel ....................................................... 228 FileNone ......................................................... 210, 214 FileOnOff .................................................................210 FileOnOnly ...............................................................210 Filesystem......................... 10, 18, 51, 56, 140, 141 Filesystem-Snapshot ..............................................97 Firewall ................................................................... 143 Flag....................................................................... 10, 11 Flexibilität ................................................................... 4 FMR (Fast Mirror Resynchronisation) ..... 99, 100 fmthard .................................................................6, 26 format .....................................................6, 13, 15, 26 Frozen ...................................................................... 234 fsadm ..........................................................................73 fsck ...................................................................116, 117 FsckOpt ................................................................... 216 FSType ..................................................................... 216 Full Stripe Write ......................................................67

G GAB ...........V, 153, 154, 156, 176, 177, 227, 230, 254, 255, 260, 262, 267 GAB-Broadcast ..................................................... 177 GAB-Disk ..........................227, 228, 256, 265, 266 GAB-Stable-Timeout ........................................... 230 GAB-Treiber ........................................................... 154 gabconfig.......................................................157, 158 gabconfig -a .......................................................... 230 gabdiskconf............................................................ 228 gabdiskhb -a.......................................................... 232 gabdiskhb -d.......................................................... 232 gabdiskhb -l ........................................................... 232 Gesamtperformance ...............................................49

271

Geschwindigkeit ......................................................53 getopts-Library ......................................................171 Glasfaser ................................................................. 264 Global Cluster Option ......................................... 266 Goodwill-Reservierung ....................................... 260 grafische Benutzerschnittstelle ....................... 153 grillen (von Steaks im Rechenzentrum ;-) .... 264 Größe ................................................................ 4, 5, 27 Group Membership and Atomic Broadcast .. 153 Group Membership Services ............................. 230 Group Membership Services and Atomic Broadcast........................................................................... 176 growfs ........................................................................73 GUI ........................................................133, 162, 164

H HA ..................................................... 18, 19, 140, 141 HA-Daemon (had) ...147, 153, 154, 178, 179, 230 haattr....................................................................... 201 haattr -display .......................................................171 hacf .......................................................................... 201 hacf -cmdtocf ....................................................... 237 haclus ...................................................................... 201 haclus -value ......................................................... 258 HACMP ........................................................................III haconf ..................................................................... 201 haconf -dump ....................................................... 163 haconf -dump -makero ...................................... 163 haconf -makerw ................................................... 163 had . 147, 153, 162, 168, 174, 189, 201, 231, 238 hagrp ....................................................................... 201 hagrp -add ....................................................164, 203 hagrp -clear ........................................166, 169, 203 hagrp -delete ........................................................ 203 hagrp -disable ....................................................... 236 hagrp -display ....................................................... 203 hagrp -flush ..................................................167, 169 hagrp -freeze......................................................... 235 hagrp -modify ..............................................164, 203 hagrp -offline .....................................165, 169, 203 hagrp -online .....................................165, 169, 203 hagrp -state........................................................... 203 hagrp -switch.....................................165, 169, 203 hagrp -value .......................................................... 203 hagui ........................................................................ 162 haipswitch.............................................................. 248 Halt on Rejoin ..............................................231, 232 HandleFaults.......................................................... 188 HandShakeInterval .............................................. 244 Hardware ................................................................ 142 Hardwarebene ....................................................... 259 Hardwarepfad ............................................... 111, 115 hares ........................................................................ 201 hares -add .............................................................. 203 hares -clear.........................................166, 169, 203 hares -delete ......................................................... 203 hares -dep .............................................................. 197

272

hares -display........................................................ 203 hares -link .....................................................197, 212 hares -modify ...............................................171, 203 hares -offline......................................................... 203 hares -online ......................................................... 203 hares -override ..................................................... 199 hares -probe .......................................................... 198 hares -undo_override ......................................... 200 hares -unlink ......................................................... 197 hares -value ........................................................... 203 hashadow ......................................................153, 231 hastart .................................................. 157, 158, 201 hastatus ............................................... 158, 169, 201 hastatus -group .................................................... 203 hastop.............................................................158, 201 hastop -all -force ................................................. 163 hasys ........................................................................ 163 hasys -display ....................................................... 234 hasys -force ........................................................... 163 hasys -freeze ......................................................... 234 hasys -unfreeze .................................................... 234 hasys -value........................................................... 234 hatrigger ........................................................157, 238 hatype ..................................................................... 201 hatype -modify ..................................................... 199 hatype -value ........................................................ 199 hauser ...................................................................... 201 HDS 9x00 .................................................................... 4 HDS HORC .............................................................. 266 Heartbeat 146, 153, 154, 174, 175, 209, 226 ,227, 230, 256, 257, 259, 262, 263, 264, 265, 266 Heartbeat-Infrastruktur ..................................... 260 Heartbeat-Netz .................................................... 176 Heartbeat-Pakete ........................................226, 230 Heartbeat-Stack ................................................... 262 Heartbeat-Status ................................................. 162 Heartbeating zum had ........................................ 181 Herunterfahren ..................................................... 262 High-Availability .....................................................18 Hochverfügbarkeit ..................III, 18, 70, 221, 266 HORC ....................................................................... 266 Hot Spare ............................................................... 146 Hot Spot .............................................................41, 44 HP/UX .............................................................7, 12, 13

I I/O ..........................................46, 47, 49, 50, 51, 143 I/O-Fencing ........... 138, 149, 221, 227, 232, 255, 257, 260, 261, 264, 266 I/O-Fencing-Port .................................................. 262 I/O-Fencing über IP ....................................261, 266 I/O-Mapping .............................................................19 I/O-Verhalten............................................................49 IBM................................................................................ 7 IBM ESS ....................................................................... 4 IDE ................................................................................. 6 ID Block ......................................................................13

ifconfig .................................................................... 144 IfconfigTwice ................................................244, 246 IgnoreLinkStatus .................................................. 249 Implementation von DiskGroups ........................19 implizite Nachrichten ......................................... 176 Import.............................................................221, 258 import ............................................................... 19, 102 Importieren ................................................................. 6 Importieren und Deportieren von DiskGroups 19 in.mpathd ............................................................... 249 Infrastruktur .......................................................... 143 init=active .................................................................32 Initialisierung des Clusters ................................ 177 init 5 ........................................................................ 262 injeopardy (hatrigger-Event) ............................ 238 Inkonsistentes Backup ...........................................96 Installation .............................................15, 138, 141 installcfs ................................................................. 260 installer .................................... 12, 14, 15, 156, 260 installer -configure .............................................. 260 installorarac........................................................... 260 installsf ......................................................................12 installvcs ........................................................156, 260 Integrität der Daten ............................................ 149 Interconnect .......................................................... 174 Interleaving...............................................................48 Interrupt-Level ...................................................... 122 IP ............................................................194, 228, 243 IP-Adresse ... 140, 142, 144, 147, 162, 195, 208, 242, 264 IP-Multipathing .................................................... 250 IP-Resource.........................................195, 197, 222 IPMP (IP Multipathing)....................................... 222 IPMultiNIC-Resource .......................245, 246, 247 IPMultiNICB-Resource.....................222, 248, 250

J Java-Application-Server .................................... 142 Java Runtime Environment ............................... 162 Jeopardy............................................................ IV, 230

K Kapazität ........................................................... 47, 53 Kernel ........................111, 114, 121, 143, 175, 254 Kernel-Resourcen ................................................. 122 Kernel-Treiber............16, 27, 120, 143, 153, 176, 256, 263, 267 Key ...................................................................256, 258 Key Ejection ........................................................... 260 Kombination von Plexes ........................................38 Kombination von RAID-Leveln .................... 27, 52 Kommandozeile .................................................... 163 Kompatibilität ....................................................... 143 Komplexität ..................................................142, 176 Konfiguration ..................................... 140, 141, 142 Konfigurations-Management ........................... 142

Konfigurationsänderungen ................................ 178 Konfiguration des Clusters ................................ 177 Konfiguration öffnen und schliessen.............. 163 Konfiguration von GAB....................................... 154 Konfiguration von LLT ......................................... 154 Konsistenz .................................................................16 korrupte Datenbank ...............................................96

L Lastverteilung ....................................................... 242 Latenz .................................................48, 49, 53, 264 layered Volume ....................80, 81, 82, 85, 88, 90 Layout.............................................................7, 38, 41 Layout ändern ..........................................................70 LBA ................................................................................ 6 LDAP......................................................................... 195 Leitungsausfall...................................................... 230 Leitungsführung ................................................... 264 Leseperformance .....................................................47 Lesezugriffe ...................................................... 38, 44 Link ........................................................................... 156 Link-Lowpri ...................................................145, 157 Link-Timeout ......................................................... 226 Link (private/public) ............................................ 145 Linux ...........................................................................13 LLT..........153, 154, 156, 175, 227, 230, 262, 267 LLT-Protokoll.......................................................... 154 LLT-Treiber .............................................................. 154 lltconfig................................................................... 157 lltstat ....................................................................... 158 LLT auf FibreChannel ........................................... 266 LLT über UDP ................................................228, 266 Load-Balancer ..............................................142, 143 Load-Balancing................................................ 7, 249 loadwarning (hatrigger-Event)......................... 238 Load Balancing ........................................................52 Löcher (in Volumes) ................................................38 Lock-Management......................................149, 254 LOG-Plex ....................................................................62 Logfile ............................................................... 10, 153 Logging ......................................................................61 logische Inkonsistenz .............................................96 LOGONLY ...................................................................60 Lokalisieren von Attributen ............................... 243 Löschen der Registrierung ........................259, 260 Low-Level-Befehle ..................................................44 Low Latency Transport........................................ 175 LUN .....................................................12, 26, 44, 259 luxadm reserve.........................................................24

M MAC-Adressierung............................................... 175 main.cf ................................................. 163, 201, 237 manuelle Übernahme .......................................... 266 Mapping-Funktion .......................................... 38, 39 Mapping-Table ............................................... 38, 121

273

Master-Plex ..............................................................41 Master/Slave.......................................................... 146 Mechanismen von I/O-Fencing ........................ 262 Membership ........................................177, 230, 263 Meta-Information ...................................................10 Metadaten................................................... 10, 11, 14 MetaDevices ............................................................... 7 Micro-Failover .............................................242, 243 Middleware ...................................................142, 143 Mirror .................. 6, 28, 29, 38, 41, 47, 56, 70, 98 mirror..........................................................................46 mirror,stripe ..............................................................82 mirror-concat ...........................................................90 mirror-stripe .............................................. 51, 82, 90 Mirrored Stripe ........................................................29 Mirroring ...................................................................27 misaligned .................................................................50 Missing Soldier ..................................................... 226 mkfile ..........................................................................76 mkfs .................................................................. 26, 217 Monitor ................................................................... 245 Monitorfunktion ................................................... 147 Monitoring ............. 180, 181, 195, 196, 208, 230 Monitoring-Workstation .................................... 162 Monitoring (zyklisches und initiierendes) ..... 199 MonitorInterval .................................165, 199, 200 MonitorProcesses ........................................214, 215 MonitorProgram ..........................................214, 215 MonitorReservation ............................................. 221 MonitorTimeout...........................................199, 200 Monitorzyklus ....................................................... 167 mount ...............................................26, 40, 101, 105 Mount-Option ..........................................................96 Mount-Resource .........................................142, 215 MountOpt ............................................................... 216 MountPoint ............................................................ 216 MpathdCommand .......................................249, 250 MpathdRestart ...................................................... 250 MPXIO ..................................................................... 121 Multi-Child ............................................................ 188 Multi-Parent .......................................................... 188 MultiNICA-Resource .....242, 243, 245, 246, 247 MultiNICB-Resource ........................242, 245, 249 MultiNICResName ............................................... 246 Multipathing Mode ............................................. 249

N N-to-M Cluster ..................................................... 148 Namenskonvention .................................................42 Name Service ........................................................ 144 ncol .............................................................................72 NetMask .................................... 195, 244, 246, 248 Netmask .................................................................. 205 NetSG ...................................................................... 245 NetworkHosts........................................................ 244 Network Partition .......................................226, 231 Netzwerk ................................................................ 143

274

Netzwerkinfrastruktur ........................................ 266 Netzwerkschnittstelle ......................................... 142 newfs ........................................................... 26, 37, 40 nfs............................................................................. 215 NFS-Daemon ......................................................... 198 NIC .....................................194, 197, 243, 245, 246 NIC-Resource ...............................................197, 222 nicht-redundanter Heartbeat ........................... 230 nmirror .......................................................................72 noautoimport-Flag .............................................. 221 Node ..................................145, 174, 194, 258, 259 Node-ID ...............................................154, 156, 258 Nodeausfall ............................................................ 264 nofailover (hatrigger-Event) ............................. 238 non-layered ..............................................................88 non-persistent Resource ...........................198, 210 None (Operations-Typ) ...........198, 199, 210, 216 Not-Aus Knopf ...................................................... 264 Notifier .................................................................... 157 NumThreads........................................................... 200

O Offhost Processing ...................................... 102, 104 OFFLINE ... 165, 167, 180, 183, 198, 199, 200, 210 offline-EntryPoint ................................................ 167 Offline-Kopie ............................................................96 OfflineMonitorInterval ....................................... 200 OFFLINE PROPAGATE ........................................... 188 Offlining ......................................145, 181, 234, 235 OK-Prompt ..............................................................113 ONLINE .... 165, 167, 180, 183, 198, 199, 200, 210 OnlineRetryLimit .................................................. 200 Onlining ............................145, 181, 197, 234, 235 OnOff (Operations-Typ) ..........198, 209, 210, 216 OnOnly (Operations-Typ) ................................... 198 OpenFlag....................................................................58 Operations .....................................................209, 210 Operations (OnOff, OnOnly, None) .................. 198 Options ...........................................................244, 246 OR ........................................................................ 29, 60 Oracle ............................................................... 96, 174 Oracle Disk Manager ........................................... 177 Oracle RAC ............................................................. 149 Overhead ................................................................ 175

P Parallel-Attribut ................................................... 245 parallele Applikation .............. 149, 174, 177, 255 parallele Schreibzugriffe .......................................28 Parallele ServiceGroup ...............................149, 245 Parent-Child-Beziehung .................................... 188 Parent- und Child-Resource ............................. 197 Parity.............................................. 28, 29, 61, 62, 67 Parity-Stripe ..................................................... 27, 46 PARTIAL ................................................................... 188 Partition ......7, 10, 12, 14, 16, 26, 36, 56, 57, 80, 110, 114, 215, 217, 227

Partitionierung .........................................................18 Partition Table ................................ 10, 39, 114, 121 PathName ................................... 164, 168, 210, 211 peerinact........................................................226, 231 Performance ................4, 5, 27, 46, 47, 52, 53, 70 Performancesteigerung .........................................53 Performance multi-threaded random ...............46 Performanc esingle-threaded sequentiell ........46 persistent................................... 197, 198, 234, 235 persistent Resource ..............................................210 Phantom ................................................................. 245 Phantom-Filesystem ..............................................96 Phantom-Resource .............................................. 247 physisches Interface ............................................ 144 physische Disk ........38, 39, 41, 44, 46, 47, 57, 80 physische Grenzen ..................................................18 physische Partition .................................................56 physische Spindel ....................................................26 PidFiles ...........................................................214, 215 PingOptimize ......................................................... 244 PITC (Point-In-Time-Copy) ...................................96 pkill .......................................................................... 164 Platform Block .........................................................13 Plex........ 26, 36, 37, 38, 40, 41, 42, 47, 56, 74, 88, 102, 264 Pool .......................................................................... 5, 6 Portnummer ..................................................139, 144 Ports ......................................................................... 177 Port a (GAB) ........................................................... 177 postoffline (hatrigger-Event) ............................ 238 postonline (hatrigger-Event) ............................ 238 pre-existing network partition......................... 263 preferred Plex ...........................................................44 Preis/GB .....................................................................46 PreOnline ................................................................ 239 preonline (hatrigger-Event) .............................. 238 Priorität .............................156, 164, 175, 194, 231 Private Link ............................................................ 145 Private Region ...... 11, 13, 14, 16, 19, 39, 58, 110 privlen ........................................................................20 Probing .............................. 166, 180, 181, 230, 231 Process .................................................................... 165 Process-Resource ................................................. 208 Proxy ........................................................................ 244 Proxy-Resource ..................................................... 247 Prozentzeichen (Escape-Character für hares) .. 170 Prozess .................................................................... 142 Prozess-ID .............................................................. 214 Prozess-Struktur von VxVM .............................. 120 prtvtoc ........................................................................26 Public-Netz ............................................................ 157 Public Link .............................................................. 145 Public Region ....................................11, 14, 16, 110

Q Queuemanager ............................................143, 264 Quorum ................................................................... 264

Quorum-Device ....................... 148, 232, 255, 256 Quorum-Device und I/O-Fencing (Vergleich)255 Quorum-Disk ......................................................... 255 Quorum-Verfahren .....................................228, 254 Quoting ................................................................... 170

R RAC ............................................. 174, 176, 177, 255 Race-Condition............................................176, 254 RAID .................................................................... 18, 27 RAID-0........................................................................29 RAID-0/Concat.........................................................28 RAID-0/Stripe ...........................................................28 RAID-01 ...................................................... 29, 52, 70 RAID-1........................................................................28 RAID-10 .................................29, 30, 52, 53, 70, 80 RAID-2........................................................................28 RAID-3........................................................................28 RAID-4................................................................ 28, 29 RAID-5...... 27, 28, 29, 30, 33, 38, 46, 47, 53, 62, 67, 88, 92 RAID-5 Log................................... 61, 63, 64, 65, 67 RAID-6........................................................................29 RAID-7........................................................................29 RAID-Array .........................................................26, 51 RAID-Dreieck ............................................................30 RAID-Level .............................................6, 30, 46, 52 RAID-S........................................................................29 RAID-Systeme ..........................................................52 raid5............................................................................90 Random-I/O ............................................... 49, 50, 51 Rauchmelder ......................................................... 264 Raw-Device................................16, 36, 51, 56, 220 RDWRBACK ................................................ 58, 59, 61 Read-Policy .............................................. 42, 58, 112 Read-Policy prefer ..................................................42 Read-Policy round ..................................................42 Read-Policy select...................................................42 read-write .............................................................. 100 Real Application Clusters (Oracle) .........149, 174 Reboot ........................................................ 57, 61, 111 Rechenzentrum..................................139, 143, 264 Rechenzentrums-Anwendung .............................53 Rechenzentrumsausfälle .................................... 264 Reconfig-Scripts .................................................... 111 Reconfiguration Event ...............................177, 178 Recovery ............................................................ 30, 57 Redo-Log .......................................................141, 146 redundanter Heartbeat ....................................... 230 redundante Komponente ................................... 152 Redundant Array of Inexpensive Disks .............27 Redundanz ....................................................227, 260 Registration ........................................................... 260 Registration-Keys ..............................257, 258, 262 Registrierungen ....................... 257, 258, 259, 260 Relayout...................................................... 88, 90, 91 Remote Cluster ..................................................... 266

275

Replikationscluster .............................................. 266 Replikationslösung .............................................. 266 resadminwait (hatrigger-Event) ...................... 238 Reservierung .......................................257, 259, 260 Reservierung (SCSI-3 Persistent Group Reservation, PGR) ............................................................... 257 resfault (hatrigger-Event) .................................. 238 resnotoff (hatrigger-Event) ............................... 238 Resource .................................... 145, 147, 154, 187 ResourceFault........................................................ 165 ResourceInfo.......................................................... 217 ResourceType..........138, 145, 162, 166, 181, 187, 190, 194, 199, 222 ResourceType Attribute ...................................... 199 Resource Clear ...................................................... 164 Resource Fault ...................................................... 164 Ressource ............................................................... 145 ResStateChange ................................................... 239 resstatechange (hatrigger-Event) ................... 238 Restart ............................................................164, 166 RestartLimit ........................................ 166, 200, 210 Resynchronisierung ...................37, 52, 56, 58, 98 Ringpuffer .................................................................62 Rollback .................................................................. 176 Root-Device ............................................................ 111 Root-Disk.................................................................110 Root-Disk Spiegelung ..........................................112 Root-Filesystem .......................................................10 Root-Mirror ................................................... 111, 112 rootdg ................................................................. 24, 27 Rotationslatenz .......................................................53 Round-Robin ............................................................42 RouteOptions ........................................................ 244 Routing ..........................................................143, 144 RS232 ...................................................................... 139 rsh............................................................................. 156

S SAN ...................44, 122, 123, 140, 142, 143, 228 SAN-Storage..................................................... 12, 26 Schattenserver ...................................................... 140 Scheduler................................................................ 264 Schreibperformance ...............................................47 Schreibrechte ........................................................ 256 Schreibzugriffe ................................................ 38, 44 SCSI ............................................................................... 6 SCSI-3-PGR ........................................................... 267 SCSI-3 PGR (Persistent Group Reservation) ......... 149, 221 SCSI-Treiber ........................................................... 121 SCSI-WWID............................................................ 121 SCSI3_RESV_WRITEEXCLUSIVEREGISTRANTSONLY 258 sd .............................................................................. 120 SDS ........................................................ 7, 81, 85, 143 SecondLevelMonitor............................................ 216 SecondLevelTimeout............................................ 216

276

Seeding ................................................................... 262 Selbstmord ............................................................. 259 select ..........................................................................42 Sequentiell ................................................................50 sequentielle Performance .....................................51 Serialisierung aller Kommunikation................ 177 Service-IP ............................................................... 243 ServiceGroup ...........18, 145, 147, 162, 164, 166, 186, 194, 231, 236, 242, 243, 245, 259, 266 ServiceGroup automatisch online bringen ... 194 ServiceGuard .............................................................III Service Group ...............................................153, 154 set-cluster .............................................................. 156 set-node ................................................................. 156 set-timer................................................................. 226 set-timer peerinact ............................................ 258 SGA-Daten ............................................................. 174 Share........................................................................ 215 Shared DiskGroup ................................................ 259 shared DiskGroup ................................................. 149 Shared Storage ..................................................... 152 Sicherheit ................................................. 4, 5, 27, 46 Single-Point-Of-Failure (SPOF) ...............152, 227 Single Point Of Failure ............................................III Slice .......................................................10, 11, 12, 14 sliced........................................... 11, 13, 14, 111, 116 SNAPATT ....................................................................99 SNAPDONE ................................................................99 Snapshot ............................................................ 96, 98 Snapshot-Filesystem ..............................................96 Snapshot-Plex ..........................................................98 Snapshot-Volume............................................ 97, 98 SnapUmount.......................................................... 216 Software ................................................................. 142 Solaris .........III, 10, 12, 13, 19, 111, 114, 121, 162 Soll-Zustand .......................................................... 231 Solstice Disk Suite ......................................7, 81, 85 Space Optimized Snapshot Volume ......... 97, 101 SPARC .........................................................................13 Sparse Plex .........................................................41, 44 Spiegel........................................................................19 spiegeln ......................................................................70 Spindel .......................................................................47 Split-Brain....140, 141, 148, 228, 231, 232, 256, 264 Split-Data-Center ..................................V, 263, 264 Split Brain .....................................................146, 226 SRDF......................................................................... 266 ssh ............................................................................ 156 StartProgram ................................................214, 215 Startreihenfolge ................................................... 197 Statusinformation ................................................ 178 stdout ...................................................................... 237 STONITH (Shoot The Other Node In The Head) .... 229 STOP-A .................................................................... 232 StopProgram.................................................214, 215

Storage ................................................. 141, 142, 266 Storage-Attribute ...................................................26 Storage-Virtualisierung ...................................... 143 Storage Area Network ........................................ 123 Storage Checkpoint ................................................97 Storage Foundation ............................................. 261 Storage on Demand .................................................. 5 Stripe ........ 10, 27, 28, 29, 38, 40, 46, 47, 70, 80, 88, 92, 134 stripe ...........................................................................90 Stripe-Mirror ................................................6, 38, 41 stripe-mirror ....................................... 51, 80, 84, 90 Striped Mirror ..........................................................29 Stripesize .................................................... 49, 50, 51 stripewidth ................................................................72 Stripe Unit Width ....................................................28 Striping .................................................................6, 27 Striping über Volumes ...........................................80 Stromausfall .............................................................57 stwid ...........................................................................72 Subcluster .............................................................. 258 Subdisk .......................... 30, 38, 39, 40, 42, 51, 111 Subdisks ..................................................................... 11 Subnetz ................................................................... 197 Sun ..............................................................................10 SunCluster ..................................................................III swap...............................................112, 113, 115, 117 swap-Partition .......................................................110 Switch ............................................................152, 164 Switches ................................................................. 266 Symmetrischer Cluster ..............................147, 148 SYNC ...........................................................................58 Synchronisation der Konfiguration ................. 146 sysoffline (hatrigger-Event) .............................. 238 SystemList .....................................................164, 188 Systemnamen ........................................................ 156 Systemseitige Voraussetzungen....................... 143 Systemvoraussetzungen ..................................... 141 SystemZones.......................................................... 236

T Tablespace .....................................................140, 141 Tag ......................................................................10, 114 temporäres Subvolume..........................................91 Terabyte ............................................................. 36, 39 Test-IP ..................................................................... 197 TFrozen .................................................................... 234 Timeout ...................................... 122, 195, 199, 226 ToleranceLimit..............................................166, 200 Tolerant Transaction Systems ................................ 7 Toolbar .................................................................... 162 touch ........................................................................210 Transaktionen/s............................................4, 47, 53 transaktionsfest .................................................... 176 Transaktionslog ................................................ 53, 62 Transmit .................................................................. 176 Trigger-Point..................................................... 84, 86

TriggerResStateChange ...................................... 239 triggers .................................................................... 239 types.cf ...........................................................163, 237

U Übergangszustände ............................................. 167 Überhitzung ..............................................................53 Überlast......... 144, 146, 228, 254, 256, 259, 266 UCB .............................................................................27 ufs........................................................ 51, 61, 73, 215 UFS-Bootloader .....................................................114 umount .......................................................... 101, 105 Umschaltung (MultiNICB) ................................. 249 unable_to_restart_had (hatrigger-Event) .... 238 uname ......................................................................114 Undo-Funktion.........................................................90 Undo-Möglichkeit für Konfigurationsänderungen 163 UNEXPECTED OFFLINE ........................................ 200 University of California Berkeley (UCB) ............27 UNIX.................................................................. 10, 122 Unzulänglichkeiten von Disks................................ 4 UsageType ......................................................... 36, 37 UseFence................................................................. 258 UseMpathd....................................................249, 250 User .................................................................143, 215 User-ID .................................................................... 214 User-Partitionen .................................................... 111

V VCS ................................................................................ 7 Verfügbarkeit ......................................................... 140 vergrößern.................................................................70 Veritas Filesystem ...................................................10 Veritas Volume Replicator ................................. 266 verkleinern ................................................................70 Verschiebung der Größenordnungen .................47 Verschnitt ..................................................................18 Version 5.0 ............................................................. 261 violation-Trigger ................................................... 209 violation (hatrigger-Event)................................ 238 Virtualisierung ........................................................... 4 virtuelles Interface............................144, 195, 197 virtuelle Disk.............................................................26 Volume .........11, 26, 27, 36, 37, 40, 42, 102, 110, 142, 215, 220, 264 Volume-Layout ........................................................88 Volume-Operationen ..............................................70 Volume-Resource ................................................. 220 Volumes als Basis für Subdisks ...........................80 Volume Management ........................................ 4, 10 Volume Manager ......................4, 38, 39, 143, 221 Volume Manager (parallel) ................................ 262 Volume Mapping .................................................. 120 Volume Table Of Contents (VTOC) ......................10 Votes ........................................................................ 228

277

Voting-Verfahren.................................................. 229 VRTSfspro ..................................................................13 VRTSob .......................................................................13 VRTSobgui .................................................................13 VRTSvlic .....................................................................13 VRTSvmdoc ...............................................................13 VRTSvmman ..............................................................13 VRTSvmpro ................................................................13 VRTSvxvm ..................................................................13 VTOC .......... 10, 11, 13, 14, 39, 110, 111, 112, 113, 117, 121 vx-bootdisk .............................................................113 VX-Treiberdatei ........................................................26 vxassist -o resyncfromreplica snapback ...........99 vxassist addlog .................... 60, 65, 100, 104, 105 vxassist convert .......................... 70, 88, 90, 91, 92 vxassist growby .......................... 70, 73, 76, 77, 91 vxassist growto ..........................................70, 73, 91 vxassist help alloc ...................................................72 vxassist help space .................................................72 vxassist make ........26, 31, 32, 33, 60, 65, 76, 77, 80, 82, 100 vxassist mirror........... 31, 89, 91, 93, 99, 112, 113 vxassist move ............................................... 102, 117 vxassist relayout .................. 70, 88, 89, 91, 92, 93 vxassist remove log ........................................ 60, 65 vxassist remove mirror .... 72, 73, 76, 89, 91, 116 vxassist remove volume .................................26, 31 vxassist shrinkby ............................... 70, 73, 76, 91 vxassist shrinkto ........................................70, 73, 91 vxassist snapabort ...................................... 101, 104 vxassist snapback ....... 70, 98, 101, 102, 104, 105 vxassist snapclear ....................................... 101, 104 vxassist snapshot ......... 70, 98, 99, 101, 104, 105 vxassist snapstart......... 70, 98, 99, 101, 104, 105 vxassist snapwait .................................98, 101, 104 vxbootsetup ..........................................113, 116, 117 vxcdsconvert.............................................................13 vxconfigd .................................... 115, 118, 120, 122 vxdctl ..........................................................................20 vxdctl bootdg ...........................................................20 vxdctl defaultdg ....................................... 20, 27, 40 vxdctl enable ......................................................... 121 vxdg ............................................................................20 vxdg -t import....................................................... 221 vxdg adddisk .................................................... 20, 111 vxdg bootdg ..............................................................20 vxdg defaultdg .......................................... 20, 27, 40 vxdg deport ............................................ 20, 105, 107 vxdg destroy .............................................................20 vxdg import ........................ 20, 104, 105, 107, 221 vxdg init .....................................................................20 vxdg join ..................................... 102, 104, 105, 107 vxdg list .....................................................................20 vxdg listmove ........................................................ 102 vxdg move .............................................................. 102 vxdg rmdisk......................................................20, 116

278

vxdg split .................................... 102, 104, 105, 107 vxdisk .................................................................. 14, 15 vxdisksetup ......... 11, 12, 13, 14, 15, 20, 110, 116 vxdiskunsetup ................................ 14, 15, 116, 117 vxdisk list........................................................... 14, 15 VxDMP.......................................................................... 6 vxdmp .............................................................120, 121 vxdmp.conf ............................................................ 121 vxdmpadm.............................................................. 122 vxedit -rf rm ..................................................... 26, 74 vxedit rm ...................................................................39 vxedit set ...................................................................80 vxencap ......................................... 110, 111, 113, 117 vxevac.......................................................................117 vxfen ...............................................................149, 267 vxfenadm ................................................................ 259 vxfentsthdw ........................................................... 267 VxFS .................................................................. 6, 7, 10 vxfs ...................................................... 51, 61, 73, 215 vxio......................................................... 111, 120, 121 vxio.conf ................................................................. 121 vxmake ............................................................. 36, 108 vxmake plex ............................................... 38, 40, 80 vxmake sd................................................... 39, 40, 80 vxmake vol ........................................................ 37, 40 vxmirror ........................................ 111, 113, 116, 117 vxnotify ..........................................................120, 122 vxplex -o rm dis..............................................73, 116 vxprint ................................................15, 26, 83, 106 vxrecover ................................................................ 103 vxrelayout .................................................................90 vxrelayout reverse ............................................90, 91 vxrelayout start ................................................90, 91 vxrelayout status...................................... 89, 90, 91 vxrelocd .................................................................. 122 vxresize ................................................ 73, 76, 77, 91 vxsd join.....................................................................91 vxspec .............................................................120, 121 vxtask .........................................................................76 vxtask abort ............................................... 89, 90, 91 vxtask list ................................................... 76, 89, 91 vxtask monitor .........................................................89 vxtask pause .............................................. 89, 90, 91 vxtask resume ...................................................90, 91 VxVM ............4, 5, 6, 12, 58, 81, 85, 99, 100, 110, 114, 115, 118, 121, 152, 220, 234, 260 VxVM-Metadaten ...................................................14 VXVM_DEFAULTDG ......................................... 27, 40 VxVM ID Block .........................................................13 vxvol set...................................... 100, 101, 104, 105 vxvol start .................................................. 37, 40, 80 vxvol startall .............................. 102, 103, 104, 105

W WAITING FOR OFFLINE ....................................... 167 WAITING FOR ONLINE ........................................ 167 Wartbarkeit ............................................................ 139

Wartungsarbeiten ................................................ 262 Wartungsarbeiten an einem Node .................. 234 Wartungsarbeiten an einer Applikation ........ 235 Web-Server ...................................................142, 222 Wiederanlauf ......................................260, 262, 263 World-Wide ID ...................................................... 121 Worst-Case ...............................................................30 WO (Write-Only) ............................................. 98, 99 WWID ...................................................................... 121

Z Zeitsprung .............................................................. 226 ZFS........................................................................... III, 7 Zugriffspfad ..............................................................12 Zugriffssteuerung..................................... 18, 20, 24 Zustandsflag ............................................................. 11 Zuverlässigkeit ...................................................... 139 Zylindergrenze .........................................................39

X Xclock .............................................................164, 165 xhost + ...........................................................164, 168 XOR ................................................ 28, 29, 53, 61, 67

279