X.systems.press Veritas Storage Foundation High End-Computing für UNIX, Design und Implementation von Hochverfügbarkeitslösungen mit VxVM und VCS Bearbeitet von Volker Herminghaus, Albrecht Scriba 1. Auflage 2006. Buch. xviii, 279 S. Hardcover ISBN 978 3 540 34610 4 Format (B x L): 15,5 x 23,5 cm Weitere Fachgebiete > EDV, Informatik > EDV, Informatik: Allgemeines, Moderne Kommunikation > EDV & Informatik Allgemein Zu Inhaltsverzeichnis schnell und portofrei erhältlich bei Die Online-Fachbuchhandlung beck-shop.de ist spezialisiert auf Fachbücher, insbesondere Recht, Steuern und Wirtschaft. Im Sortiment finden Sie alle Medien (Bücher, Zeitschriften, CDs, ebooks, etc.) aller Verlage. Ergänzt wird das Programm durch Services wie Neuerscheinungsdienst oder Zusammenstellungen von Büchern zu Sonderpreisen. Der Shop führt mehr als 8 Millionen Produkte.
KAPITEL 1 EINFÜHRUNG
1 1.1 EINFÜHRUNG Ist-Zustand physische en von Disks 10 GB Datei 9 GB 9 GB 9 GB 180 GB 9 GB der Größe l Eine 10 GB Datei passt nicht auf eine 9 GB Disk auch nicht auf mehrere davon. der Performance l Eine Disk erreicht ca. 100-150 TX/s zu langsam für viele Anwendungen. der Sicherheit l Ausfall einer Disk bedeutet den Ausfall der darauf befindlichen Daten. 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 passt sich den sich wandelnden Anforderungen der EDV nicht an. Wie in der EDV üblich lassen sich diese physischen en 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 en mit geeigneten Mitteln umgeht. Umgesetzt auf Disks würden also virtuelle Disks geschaffen werden, die die en 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 EMC 2 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. 4
EINFÜHRUNG 1 Guaredisch Idealvorstellung 1.1 1.2 Idealzustand wäre: l Alle Disks als großer Pool. l 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. 1.2 Idealvorstellung 1.2.1 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 en gelindert oder gänzlich aufgehoben werden. Die ersten drei en 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 SAN- Zoning 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. Ë 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 Volume- Eigenschaften setzen und ändern. Ë VxVM basiert auf Dynamic Multipathing ( DMP) und benutzt alle vorhandenen Pfade. Ë Alle Aktionen sind bei VxVM online möglich. 1.3 1.3.1 Wie nahe kommt Veritas Volume Manager dem Idealbild? Theoretisch implementiert VxVM unsere Ide alvorstellung 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 verwalt barer 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 Solaris- Filesystem 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 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 Betriebs system 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 ( Dy namic Multipathing), der transparenten Disk- Zugriff ü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-Kon fi gurationen 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. 6
EINFÜHRUNG Alternativen Welche Alternativen gibt es zu VxVM? Die Alternativen sind im Allgemeinen be triebssystemspezifisch, 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 Neu entwicklung 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 vorallozierten 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 1.3.2 Historische Information Bereits vor zwanzig Jahren bot DEC ( Digital Equipment, später von Compaq, jetzt von HP gekauft) ein Disk-Sub sys tem mit ähnlichen Features wie VxVM heute. Alle Disks wurden in den Storage Pool getan, und aus diesem Pool wur de Platz alloziert, wenn dieser benötigt wurde. Es gab sogar eine im Hintergrund laufende Load-Balancing Funk tion, welche die Daten auf den Disks neu verteilte, wenn sich Bottle necks auf taten! Einige ehemalige DEC-Entwickler arbeiten heute bei Veri tas. Der Veritas Volume Manager wurde allerdings nicht von ehemaligen DEC- Ingenieuren 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. 1.3.3 7