From owner-svn-doc-projects@FreeBSD.ORG Tue Aug 21 18:58:50 2012 Return-Path: Delivered-To: svn-doc-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63B111065678; Tue, 21 Aug 2012 18:58:50 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c]) by mx1.freebsd.org (Postfix) with ESMTP id 4D0158FC1C; Tue, 21 Aug 2012 18:58:50 +0000 (UTC) Received: from svn.freebsd.org (localhost [127.0.0.1]) by svn.freebsd.org (8.14.4/8.14.4) with ESMTP id q7LIwoPc087396; Tue, 21 Aug 2012 18:58:50 GMT (envelope-from gabor@svn.freebsd.org) Received: (from gabor@localhost) by svn.freebsd.org (8.14.4/8.14.4/Submit) id q7LIwodv087392; Tue, 21 Aug 2012 18:58:50 GMT (envelope-from gabor@svn.freebsd.org) Message-Id: <201208211858.q7LIwodv087392@svn.freebsd.org> From: Gabor Kovesdan Date: Tue, 21 Aug 2012 18:58:50 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-projects@freebsd.org X-SVN-Group: doc-projects MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: svn commit: r39415 - in projects/sgml2xml: de_DE.ISO8859-1/books/handbook/vinum en_US.ISO8859-1/htdocs/layout ja_JP.eucJP/htdocs/ports X-BeenThere: svn-doc-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for doc projects trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 18:58:50 -0000 Author: gabor Date: Tue Aug 21 18:58:49 2012 New Revision: 39415 URL: http://svn.freebsd.org/changeset/doc/39415 Log: - Strip CR characters Approved by: doceng (implicit) Modified: projects/sgml2xml/de_DE.ISO8859-1/books/handbook/vinum/chapter.sgml projects/sgml2xml/en_US.ISO8859-1/htdocs/layout/Makefile projects/sgml2xml/ja_JP.eucJP/htdocs/ports/comments.ja Modified: projects/sgml2xml/de_DE.ISO8859-1/books/handbook/vinum/chapter.sgml ============================================================================== --- projects/sgml2xml/de_DE.ISO8859-1/books/handbook/vinum/chapter.sgml Tue Aug 21 18:53:10 2012 (r39414) +++ projects/sgml2xml/de_DE.ISO8859-1/books/handbook/vinum/chapter.sgml Tue Aug 21 18:58:49 2012 (r39415) @@ -1,1440 +1,1440 @@ - - - - - - - Greg - Lehey - Ursprünglich geschrieben von - - - - - Johann - Kois - Übersetzt von - - - Kay - Abendroth - - - - - Der Vinum Volume Manager - - - Übersicht - - - Egal, über welche und wieviele Festplatten Ihr System - auch verfügt, immer wieder werden Sie mit den folgenden - Problemen konfrontiert: - - - - Ihre Platten sind zu klein. - - - - Sie sind zu langsam. - - - - Ihre Platten sind unzuverlässig. - - - - Um derartige Probleme zu lösen, wurden verschiedene - Methoden entwickelt. Eine Möglichkeit bietet der - Einsatz von mehreren, manchmal auch redundant ausgelegten - Platten. Zusätzlich zur Unterstützung verschiedener - Erweiterungskarten und Controller für Hardware-RAID-Systeme - enthält das &os;-Basissystem auch den Vinum - Volume Manager, einen Blockgerätetreiber, der die - Einrichtung virtueller Platten unterstützt. Bei - Vinum handelt es sich um einen - sogenannten Volume Manager, einen - virtuellen Plattentreiber, der obige drei Probleme löst. - Vinum bietet Ihnen größere Flexibilität, - Leistung und Zuverlässigkeit als die klassische - Datenspeicherung auf einzelne Festplatten. Dazu unterstützt - Vinum RAID-0, RAID-1 und RAID-5 (sowohl einzeln als auch in - Kombination). - - Dieses Kapitel bietet Ihnen einen Überblick über - potentielle Probleme der klassischen Datenspeicherung auf - Festplatten sowie eine Einführung in den Vinum - Volume Manager. - - - Für &os; 5.X wurde Vinum überarbeitet und - an die GEOM-Architektur () angepasst, - wobei die ursprünglichen Ideeen und Begriffe sowie die - auf der Platte benötigten Metadaten beibehalten wurden. - Die überarbeitete Version wird als - gvinum (für - GEOM-Vinum) bezeichnet. Die folgenden - Ausführungen verwenden den Begriff - Vinum als abstrakten Namen, unabhängig - davon, welche Variante implementiert wurde. Sämtliche - Befehlsaufrufe erfolgen über gvinum, - welches nun das Kernelmodul geom_vinum.ko - (statt vinum.ko) benötigt. Analog - finden sich alle Gerätedateien nun unter /dev/gvinum statt unter /dev/vinum. Seit &os; 6.x ist die - alte Vinum-Implementierung nicht mehr im Basissystem enthalten. - - - - - Ihre Platten sind zu klein. - - Vinum - - RAID - Software - - - Festplatten werden zwar immer größer, parallel - dazu steigt aber auch die Größe der zu speichernden - Daten an. Es kann also nach wie vor vorkommen, dass Sie ein - Dateisystem benötigen, welches die Größe Ihrer - Platten übersteigt. Zwar ist dieses Problem nicht mehr - so akut wie noch vor einigen Jahren, aber es existiert nach - wie vor. Einige Systeme lösen dieses Problem durch die - Erzeugung eines abstrakten Gerätes, das seine Daten auf - mehreren Platten speichert. - - - - Mögliche Engpässe - - Moderne Systeme müssen häufig parallel auf - Daten zugreifen. Große FTP- und HTTP-Server - können beispielsweise Tausende von parallelen Sitzungen - verwalten und haben mehrere 100 MBit/s-Verbindungen - zur Außenwelt. Diese Bandbreite überschreitet - die durchschnittliche Transferrate der meisten Platten - bei weitem. - - Aktuelle Plattenlaufwerke können Daten mit bis zu - 70 MB/s sequentiell übertragen, wobei dieser Wert - in einer Umgebung, in der viele unabhängige Prozesse auf - eine gemeinsame Platte zugreifen, die jeweils nur einen - Bruchteil dieses Wertes erreichen, von geringer Aussagekraft - ist. In solchen Fällen ist es interessanter, das Problem - vom Blickwinkel des Platten-Subsystems aus zu betrachten. - Der wichtigste Parameter ist dabei die Last, die eine - Übertragung auf dem Subsystem verursacht. Unter Last - versteht man dabei die Zeit, in der die Platte mit der - Übertragung der Daten beschäftigt ist. - - Bei jedem Plattenzugriff muss das Laufwerk zuerst die - Köpfe positionieren und auf den ersten Sektor warten, bis - er den Lesekopf passiert. Dann wird die Übertragung - gestartet. Diese Aktionen können als atomar betrachtet - werden, da es keinen Sinn macht, diese zu unterbrechen. - - Nehmen wir beispielsweise an, - dass wir 10 kB transferieren wollen. Aktuelle - hochperformante Platten können die Köpfe im Durchschnitt - in 3,5 ms positionieren und drehen sich mit maximal - 15.000 U/min. Daher beträgt die durchschnittliche - Rotationslatenz (eine halbe Umdrehung) 2 ms. - Bei einer Transferrate von 70 MB/s dauert die eigentliche - Übertragung von 10 kB etwa 150 μs, fast - nichts im Vergleich zur Positionierungszeit. In einem solchen - Fall beträgt die effektive Transferrate nur etwas mehr - als 1 MB/s. Die Tranferrate ist also stark von der - Größe der zu tranferierenden Daten - abhängig. - - Die traditionelle und offensichtliche Lösung zur - Beseitigung dieses Flaschenhalses sind mehr - Spindeln. Statt einer einzigen großen Platte werden - mehrere kleinere Platten mit demselben Gesamtspeicherplatz - benutzt. Jede Platte ist in der Lage, unabhängig zu - positionieren und zu transferieren, weshalb der effektive - Durchsatz um einen Faktor nahe der Zahl der eingesetzten Platten - steigt. - - Obwohl die Platten Daten parallel transferieren können, - ist es nicht möglich, Anfragen gleichmäßig auf - die einzelnen Platten zu verteilen. Daher wird die Last auf - bestimmten Laufwerken immer höher sein als auf anderen - Laufwerken. Daraus ergibt sich auch, dass die exakte Verbesserung - des Datendurchsatzes immer kleiner ist als die Anzahl der - involvierten Platten. - - - Plattenkonkatenation - - - Vinum - Konkatenation - - - Die gleichmäßige Verteilung der Last auf die einzelnen - Platten ist stark abhängig von der Art, wie die Daten auf die - Laufwerke aufgeteilt werden. In den folgenden Ausführungen - wird eine Platte als eine große Anzahl von Datensektoren - dargestellt, die durch Zahlen adressierbar sind (ähnlich - den Seiten eines Buches). Die naheliegendste Methode ist es, - die virtuelle Platte (wieder analog den Seiten eines Buches) - in Gruppen aufeinanderfolgender Sektoren zu unterteilen, die - jeweils der Größe der einzelnen physischen Platten - entsprechen. Diese Vorgehensweise wird als - Konkatenation bezeichnet und hat den - Vorteil, dass die Platten keine spezielle - Größenbeziehung haben müssen. Sie funktioniert - gut, solange der Zugriff gleichmäßig auf den - Adressraum der virtuellen Platte verteilt wird. Wenn sich der - Zugriff allerdings auf einen kleinen Bereich konzentriert, ist die - Verbesserung vernachlässigbar klein. - verdeutlicht die Verteilung der - Speichereinheiten in einer konkatenierten Anordnung. - - -
- Konkatenierte Anordnung - -
- - - - Striping von Platten - - - Vinum - Striping - - - RAID - - - Ein alternatives Mapping unterteilt den Adressraum in - kleinere, gleich große Komponenten und speichert diese - sequentiell auf verschiedenen Geräten. Zum Beispiel werden - die ersten 256 Sektoren auf der ersten Platte, die nächsten - 256 Sektoren auf der zweiten Platte gespeichert und so - weiter. Nachdem die letzte Platte beschrieben wurde, wird dieser - Vorgang solange wiederholt, bis die Platten voll sind. Dieses - Mapping nennt man Striping oder + + + + + + + Greg + Lehey + Ursprünglich geschrieben von + + + + + Johann + Kois + Übersetzt von + + + Kay + Abendroth + + + + + Der Vinum Volume Manager + + + Übersicht + + + Egal, über welche und wieviele Festplatten Ihr System + auch verfügt, immer wieder werden Sie mit den folgenden + Problemen konfrontiert: + + + + Ihre Platten sind zu klein. + + + + Sie sind zu langsam. + + + + Ihre Platten sind unzuverlässig. + + + + Um derartige Probleme zu lösen, wurden verschiedene + Methoden entwickelt. Eine Möglichkeit bietet der + Einsatz von mehreren, manchmal auch redundant ausgelegten + Platten. Zusätzlich zur Unterstützung verschiedener + Erweiterungskarten und Controller für Hardware-RAID-Systeme + enthält das &os;-Basissystem auch den Vinum + Volume Manager, einen Blockgerätetreiber, der die + Einrichtung virtueller Platten unterstützt. Bei + Vinum handelt es sich um einen + sogenannten Volume Manager, einen + virtuellen Plattentreiber, der obige drei Probleme löst. + Vinum bietet Ihnen größere Flexibilität, + Leistung und Zuverlässigkeit als die klassische + Datenspeicherung auf einzelne Festplatten. Dazu unterstützt + Vinum RAID-0, RAID-1 und RAID-5 (sowohl einzeln als auch in + Kombination). + + Dieses Kapitel bietet Ihnen einen Überblick über + potentielle Probleme der klassischen Datenspeicherung auf + Festplatten sowie eine Einführung in den Vinum + Volume Manager. + + + Für &os; 5.X wurde Vinum überarbeitet und + an die GEOM-Architektur () angepasst, + wobei die ursprünglichen Ideeen und Begriffe sowie die + auf der Platte benötigten Metadaten beibehalten wurden. + Die überarbeitete Version wird als + gvinum (für + GEOM-Vinum) bezeichnet. Die folgenden + Ausführungen verwenden den Begriff + Vinum als abstrakten Namen, unabhängig + davon, welche Variante implementiert wurde. Sämtliche + Befehlsaufrufe erfolgen über gvinum, + welches nun das Kernelmodul geom_vinum.ko + (statt vinum.ko) benötigt. Analog + finden sich alle Gerätedateien nun unter /dev/gvinum statt unter /dev/vinum. Seit &os; 6.x ist die + alte Vinum-Implementierung nicht mehr im Basissystem enthalten. + + + + + Ihre Platten sind zu klein. + + Vinum + + RAID + Software + + + Festplatten werden zwar immer größer, parallel + dazu steigt aber auch die Größe der zu speichernden + Daten an. Es kann also nach wie vor vorkommen, dass Sie ein + Dateisystem benötigen, welches die Größe Ihrer + Platten übersteigt. Zwar ist dieses Problem nicht mehr + so akut wie noch vor einigen Jahren, aber es existiert nach + wie vor. Einige Systeme lösen dieses Problem durch die + Erzeugung eines abstrakten Gerätes, das seine Daten auf + mehreren Platten speichert. + + + + Mögliche Engpässe + + Moderne Systeme müssen häufig parallel auf + Daten zugreifen. Große FTP- und HTTP-Server + können beispielsweise Tausende von parallelen Sitzungen + verwalten und haben mehrere 100 MBit/s-Verbindungen + zur Außenwelt. Diese Bandbreite überschreitet + die durchschnittliche Transferrate der meisten Platten + bei weitem. + + Aktuelle Plattenlaufwerke können Daten mit bis zu + 70 MB/s sequentiell übertragen, wobei dieser Wert + in einer Umgebung, in der viele unabhängige Prozesse auf + eine gemeinsame Platte zugreifen, die jeweils nur einen + Bruchteil dieses Wertes erreichen, von geringer Aussagekraft + ist. In solchen Fällen ist es interessanter, das Problem + vom Blickwinkel des Platten-Subsystems aus zu betrachten. + Der wichtigste Parameter ist dabei die Last, die eine + Übertragung auf dem Subsystem verursacht. Unter Last + versteht man dabei die Zeit, in der die Platte mit der + Übertragung der Daten beschäftigt ist. + + Bei jedem Plattenzugriff muss das Laufwerk zuerst die + Köpfe positionieren und auf den ersten Sektor warten, bis + er den Lesekopf passiert. Dann wird die Übertragung + gestartet. Diese Aktionen können als atomar betrachtet + werden, da es keinen Sinn macht, diese zu unterbrechen. + + Nehmen wir beispielsweise an, + dass wir 10 kB transferieren wollen. Aktuelle + hochperformante Platten können die Köpfe im Durchschnitt + in 3,5 ms positionieren und drehen sich mit maximal + 15.000 U/min. Daher beträgt die durchschnittliche + Rotationslatenz (eine halbe Umdrehung) 2 ms. + Bei einer Transferrate von 70 MB/s dauert die eigentliche + Übertragung von 10 kB etwa 150 μs, fast + nichts im Vergleich zur Positionierungszeit. In einem solchen + Fall beträgt die effektive Transferrate nur etwas mehr + als 1 MB/s. Die Tranferrate ist also stark von der + Größe der zu tranferierenden Daten + abhängig. + + Die traditionelle und offensichtliche Lösung zur + Beseitigung dieses Flaschenhalses sind mehr + Spindeln. Statt einer einzigen großen Platte werden + mehrere kleinere Platten mit demselben Gesamtspeicherplatz + benutzt. Jede Platte ist in der Lage, unabhängig zu + positionieren und zu transferieren, weshalb der effektive + Durchsatz um einen Faktor nahe der Zahl der eingesetzten Platten + steigt. + + Obwohl die Platten Daten parallel transferieren können, + ist es nicht möglich, Anfragen gleichmäßig auf + die einzelnen Platten zu verteilen. Daher wird die Last auf + bestimmten Laufwerken immer höher sein als auf anderen + Laufwerken. Daraus ergibt sich auch, dass die exakte Verbesserung + des Datendurchsatzes immer kleiner ist als die Anzahl der + involvierten Platten. + + + Plattenkonkatenation + + + Vinum + Konkatenation + + + Die gleichmäßige Verteilung der Last auf die einzelnen + Platten ist stark abhängig von der Art, wie die Daten auf die + Laufwerke aufgeteilt werden. In den folgenden Ausführungen + wird eine Platte als eine große Anzahl von Datensektoren + dargestellt, die durch Zahlen adressierbar sind (ähnlich + den Seiten eines Buches). Die naheliegendste Methode ist es, + die virtuelle Platte (wieder analog den Seiten eines Buches) + in Gruppen aufeinanderfolgender Sektoren zu unterteilen, die + jeweils der Größe der einzelnen physischen Platten + entsprechen. Diese Vorgehensweise wird als + Konkatenation bezeichnet und hat den + Vorteil, dass die Platten keine spezielle + Größenbeziehung haben müssen. Sie funktioniert + gut, solange der Zugriff gleichmäßig auf den + Adressraum der virtuellen Platte verteilt wird. Wenn sich der + Zugriff allerdings auf einen kleinen Bereich konzentriert, ist die + Verbesserung vernachlässigbar klein. + verdeutlicht die Verteilung der + Speichereinheiten in einer konkatenierten Anordnung. + + +
+ Konkatenierte Anordnung + +
+ + + + Striping von Platten + + + Vinum + Striping + + + RAID + + + Ein alternatives Mapping unterteilt den Adressraum in + kleinere, gleich große Komponenten und speichert diese + sequentiell auf verschiedenen Geräten. Zum Beispiel werden + die ersten 256 Sektoren auf der ersten Platte, die nächsten + 256 Sektoren auf der zweiten Platte gespeichert und so + weiter. Nachdem die letzte Platte beschrieben wurde, wird dieser + Vorgang solange wiederholt, bis die Platten voll sind. Dieses + Mapping nennt man Striping oder RAID-0. - - RAID steht für Redundant - Array of Inexpensive Disks und bietet verschiedene - Formen der Fehlertorleranz, obwohl der letzte Begriff etwas - irreführend ist, da RAID keine Redundanz bietet. + + RAID steht für Redundant + Array of Inexpensive Disks und bietet verschiedene + Formen der Fehlertorleranz, obwohl der letzte Begriff etwas + irreführend ist, da RAID keine Redundanz bietet. - - Striping erfordert einen etwas größeren Aufwand, - um die Daten zu - lokalisieren, und kann zusätzliche E/A-Last verursachen, - wenn eine Übertragung über mehrere Platten verteilt - ist. Auf der anderen Seite erlaubt es aber eine - gleichmäßigere Verteilung der Last auf die einzelnen - Platten. veranschaulicht - die Abfolge, in der Speichereinheiten in einer striped-Anordnung - alloziert werden. - - -
- Striped-Anordnung - -
- - - - - Datenintegrität - - Das dritte Problem, welches aktuelle Platten haben, ist ihre - Unzuverlässigkeit. Obwohl sich die Zuverlässigkeit - von Festplatten in den letzten Jahren stark verbessert hat, - handelt es sich bei ihnen nach wie vor um die Komponente eines - Servers, die am ehesten ausfällt. Fällt eine - Festplatte aus, können die Folgen katastrophal sein: Es - kann Tage dauern, bis eine Platte ersetzt und alle Daten - wiederhergestellt sind. - - - disk mirroring - - - Vinum - Spiegelung - - - RAID-1 - - - Die traditionelle Art, dieses Problem anzugehen, war es, - Daten zu spiegeln, also zwei Kopien der - Daten auf getrennten Platten zu verwahren. Diese Technik wird - auch als RAID Level 1 oder - RAID-1 bezeichnet. Jeder Schreibzugriff - findet auf beiden Datenträgern statt. Ein Lesezugriff - kann daher von beiden Laufwerken erfolgen, sodass beim Ausfall - eines Laufwerks die Daten immer noch auf dem anderen - Laufwerk verfügbar sind. - - Spiegeln verursacht allerdings zwei Probleme: - - - - Es verursacht höhere Kosten, da doppelt so viel - Plattenspeicher wie bei einer nicht-redundanten - Lösung benötigt wird. - - - - Die Gesamtleistung des Systems sinkt, da - Schreibzugriffe auf beiden Laufwerken ausgeführt - werden müssen, daher wird im Vergleich zu einem - nicht gespiegelten Datenträger die doppelte - Bandbreite benötigt. Lesezugriffe hingegen sind - davon nicht betroffen, es sieht sogar so aus, als - würden diese schneller ausgeführt. - - - - RAID-5 - - Eine alternative Lösung ist - Parity, das in den - RAID-Leveln 2, 3, 4 und 5 - implementiert ist. Von diesen ist RAID-5 - der interessanteste. So wie in VINUM implementiert, ist es - eine Variante einer gestripten Anordung, welche einen Block - jedes Stripes als Paritätsblock für einen der anderen - Blöcke verwendet. Wie in RAID-5 - vorgeschrieben, ist die Position dieses Paritätsblockes - auf jedem Stripe unterschiedlich. Die Nummern in den - Datenblöcken geben die relativen Blocknummern an. - - -
- RAID-5 Aufbau - -
- - - Im Vergleich zur Spiegelung hat RAID-5 den Vorteil, dass - es signifikant weniger Speicherplatz benötigt. - Lesezugriffe sind vergleichbar schnell mit jenen bei einem - Striped-Aufbau, aber Schreibzugriffe sind deutlich langsamer - (etwa 25% der Lesegeschwindigkeit). Wenn eine Platte - ausfällt, kann das Array in einem "schwachen" Modus - weiterarbeiten: Ein Lesezugriff auf eine der übrigen - erreichbaren Platten wird normal ausgeführt, ein - Lesezugriff auf die ausgefallene Platte muss aber - zunächst mit dem zugehörigen Block aller - verbleibender Platten rückberechnet werden. - - - - Vinum-Objekte - Um die in den vorigen Abschnitte besprochenen Probleme zu - lösen, verwendet Vinum eine vierstufige - Objekthierarchie: - - - - Das auffälligste Objekt ist die virtuelle Platte, - die Volume genannt wird. Volumes - haben im Wesentlichen die gleichen Eigenschaften wie ein - &unix;-Laufwerk, obwohl es ein paar kleine Unterschiede - gibt. So existieren für Volumes beispielsweise keine - Größenbeschränkungen. - - - - Volumes bestehen aus einem oder mehreren - Plexus, - von denen jeder den gesamten Adressraum eines - Datenträgers repräsentiert. Diese Hierarchieebene - ist für die benötigte Redundanz der Daten - erforderlich. Stellen Sie sich die Plexus als - eigenständige Platten in einem gespiegelten - Array vor, von denen jede die gleichen Daten - enthält. - - - - Da Vinum im &unix;-Plattenspeicher-Framework arbeitet, - wäre es möglich, als Grundbaustein für - Multiplatten-Plexus &unix;-Partitionen zu verwenden. In - der Praxis ist dieser Ansatz aber zu unflexibel, da - &unix;-Platten nur eine begrenzte Anzahl von Partitionen - haben können. Daher unterteilt Vinum stattdessen - eine einzige &unix;-Partition (die - Platte) in zusammenhängende - Bereiche, die als Subdisks bezeichnet - werden und als Grundbausteine für einen Plexus - benutzt werden. - - - - Subdisks befinden sich auf - Vinum-Platten, eigentlich - &unix;-Partitionen. Vinum-Platten können eine - beliebige Anzahl von Subdisks haben und den gesamten - Speicher der Platte mit Ausnahme eines kleinen Bereiches - am Anfang der Platte (welcher zur Speicherung von - Konfigurations- und Statusinformationen verwenden wird) - verwenden. - - - - Der folgende Abschnitt beschreibt, wie diese Objekte - die von Vinum benötigten Funktionen zur - Verfügung stellen. - - - Überlegungungen zur Größe eines Volumes - - Plexus können mehrere Subdisks beinhalten, die - über alle Platten der Vinum-Konfiguration verteilt sind. - Daraus folgt, dass die Größe einer Platte nicht die - Größe eines Plexus (und damit eines Volumes) - limitiert. - - - - Redundante Datenspeicherung - - Vinum implementiert die Datenspiegelung, indem es ein - Volume auf mehrere Plexus verteilt. Jeder Plexus ist - dabei die Repräsentation der Daten eines Volumes. - Ein Volume kann aus bis zu acht Plexus bestehen. - - Obwohl ein Plexus die gesamten Daten eines Volumes - repräsentiert, ist es möglich, dass Teile der - Repräsentation physisch fehlen, entweder aufgrund des - Designs (etwa durch nicht definierte Subdisks für Teile - des Plexus) oder durch Zufall (als ein Ergebnis eines - Plattenfehlers). Solange wenigstens ein Plexus die gesamten - Daten für den kompletten Adressbereich des Volumes zur - Verfügung stellen kann, ist das Volume voll - funktionsfähig. - - - - Überlegungen zur Leistung - - Sowohl Konkatenation als auch Striping werden von Vinum - auf der Plexus-Ebene realisiert: - - - - Ein konkatenierter Plexus benutzt - abwechselnd den Adressraum jeder Subdisk. - - - - Ein gestripter Plexus striped die - Daten über jede Subdisk. Die Subdisks müssen alle - die gleiche Größe haben, und es muss mindestens - zwei Subdisks in Reihenfolge geben, um ihn von einem - konkatenierten Plexus unterscheiden zu können. - - - - - - Wie ist ein Plexus aufgebaut? - - Die Version von Vinum, welche von &os;-&rel.current; - bereitgestellt wird, implementiert zwei Arten von Plexus: - - - - Konkatenierte Plexus sind die flexibelsten: Sie - können aus einer beliebigen Anzahl von Subdisks - unterschiedlicher Größe bestehen. Der Plexus - kann erweitert werden, indem man zusätzliche Subdisks - hinzufügt. Sie brauchen weniger - CPU-Zeit als gestripte Plexus, obwohl - der Unterschied des CPU-Overheads nicht - messbar ist. Auf der anderen Seite sind sie aber sehr - anfällig für das Entstehen von "hot spots", wobei - eine Platte sehr aktiv ist, andere hingegen nahezu ungenutzt - sind. - - - - Der größte Vorteil eines gestripten - Plexus (RAID-0) ist die Verringerung von - "hot spots". Dies wird durch die Auswahl eines Stripes - optimaler Größe (etwa 256 kB) erreicht, - wodurch die Last gleichmäßig auf die Platten - verteilt werden kann. Nachteile dieser Vorgehensweise sind - ein (geringfügig) komplexerer Code sowie einige - Restriktionen für die Subdisks: Diese müssen alle - die gleiche Größe haben, und das Erweitern eines - Plexus durch das Hinzufügen neuer Subdisks ist so - kompliziert, dass es von Vinum derzeit nicht - unterstützt wird. Vinum fordert noch eine weitere - triviale Beschränkung: Ein gestripter Plexus muss - aus mindestens zwei Subdisks bestehen, da er ansonsten nicht - von einem konkatenierten Plexus unterscheidbar ist. - - - - fasst die Vor- und - Nachteile jedes Plexus-Aufbaus zusammen. - - - Vinum-Plexus - Aufbau - - - - - Plexus-Typ - Minimum an Subdisks? - Kann Subdisks hinzufügen? - Müssen die gleiche Größe - haben - Applikation - - - - - - konkateniert - 1 - ja - nein - Großer Datenspeicher mit maximaler - Platzierungsflexibilität und moderater - Leistung - - - - gestriped - 2 - nein - ja - Hohe Leistung in Kombination mit - gleichzeitigem Zugriff - - - -
- - - - - Einige Beispiele - - Vinum verwaltet eine - Konfigurationsdatenbank für alle - einem individuellen System bekannten Objekte. Zu Beginn - erzeugt ein Benutzer mit &man.gvinum.8; - eine Konfigurationsdatenbank aus einer oder mehreren - Konfigurationsdateien. Vinum speichert danach eine Kopie der - Konfigurationsdatenbank in jedem von ihm kontrollierten - Slice (von Vinum als Device - bezeichnet). Da die Datenbank bei jedem Statuswechsel - aktualisiert wird, kann nach einem Neustart der Status - jedes Vinum-Objekts exakt wiederhergestellt werden. - - - Die Konfigurationsdatei - - Die Konfigurationsdatei beschreibt individuelle - Vinum-Objekte. Die Beschreibung eines einfachen Volumes - könnte beispielsweise so aussehen: - - - drive a device /dev/da3h - volume myvol - plex org concat - sd length 512m drive a - - Diese Datei beschreibt vier Vinum-Objekte: - - - - Die drive-Zeile beschreibt eine - Plattenpartition (drive) sowie ihre - Position in Bezug auf die darunter liegende Hardware. - Die Partition hat dabei den symbolischen Namen - a. Diese Trennung von symbolischen - Namen und Gerätenamen erlaubt es, die Position von - Platten zu ändern, ohne dass es zu Problemen - kommt. - - - - Die volume-Zeile beschreibt ein - Volume. Dafür wird nur ein einziges Attribut, der - Name des Volumes, benötigt. In unserem Fall hat das - Volume den Namen myvol. - - - - Die plex-Zeile definiert einen - Plexus. Auch hier wird nur ein Parameter, und zwar die - Art des Aufbau, benötigt (in unserem Fall - concat). Es wird kein Name - benötigt, das System generiert automatisch einen - Namen aus dem Volume-Namen und dem Suffix - .px wobei - x die Nummer des Plexus innerhalb - des Volumes angibt. So wird dieser Plexus den Namen - myvol.p0 erhalten. - - - - Die sd-Zeile beschreibt eine - Subdisk. Um eine Subdisk einzurichten, müssen Sie - zumindest den Namen der Platte, auf der Sie die - Subdisk anlegen wollen, sowie die Größe der - Subdisk angeben. Analog zur Definition eines Plexus wird - auch hier kein Name benötigt: Das System weist - automatisch Namen zu, die aus dem Namen des Plexus und - dem Suffix .sx - gebildet werden, wobei x die Nummer - der Subdisk innerhalb des Plexus ist. Folglich gibt - Vinum dieser Subdisk den Namen - myvol.p0.s0. - - - - Nach dem Verarbeiten dieser Datei erzeugt &man.gvinum.8; - die folgende Ausgabe: - - - &prompt.root; gvinum -> create config1 - Configuration summary - Drives: 1 (4 configured) - Volumes: 1 (4 configured) - Plexes: 1 (8 configured) - Subdisks: 1 (16 configured) - - D a State: up Device /dev/da3h Avail: 2061/2573 MB (80%) - - V myvol State: up Plexes: 1 Size: 512 MB - - P myvol.p0 C State: up Subdisks: 1 Size: 512 MB - - S myvol.p0.s0 State: up PO: 0 B Size: 512 MB - - Diese Ausgabe entspricht dem verkürzten - Ausgabeformat von &man.gvinum.8; und wird in - grafisch dargestellt. - - -
- Ein einfaches Vinum-Volume - -
- - - Dieses und die folgenden Beispiele zeigen jeweils ein - Volume, welches die Plexus enthält, die wiederum die - Subdisk enthalten. In diesem trivialen Beispiel enthält - das Volume nur einen Plexus, der wiederum nur aus einer - Subdisk besteht. - - Eine solche Konfiguration hätte allerdings keinen - Vorteil gegenüber einer konventionellen Plattenpartion. - Das Volume enthält nur einen einzigen Plexus, daher - gibt es keine redundante Datenspeicherung. Da der Plexus - außerdem nur eine einzige Subdisk enthält, - unterscheidet sich auch die Speicherzuweisung nicht von der - einer konventionellen Plattenpartition. Die folgenden - Abschnitte beschreiben daher verschiedene interessantere - Konfigurationen. - - - - Verbesserte Ausfallsicherheit durch Spiegelung - - Die Ausfallsicherheit eines Volumes kann durch - Spiegelung der Daten erhöht werden. Beim Anlegen eines - gespiegelten Volumes ist es wichtig, die Subdisks jedes - Plexus auf verschiedene Platten zu verteilen, damit ein - Plattenausfall nicht beide Plexus unbrauchbar macht. Die - folgende Konfiguration spiegelt ein Volume: - - - drive b device /dev/da4h - volume mirror - plex org concat - sd length 512m drive a - plex org concat - sd length 512m drive b - - Bei diesem Beispiel war es nicht nötig, noch einmal - eine Platte a zu spezifizieren, da - Vinum die Übersicht über alle Objekte und seine - Konfigurationsdatenbank behält. Nach dem Abarbeiten - dieser Definition sieht die Konfiguration wie folgt aus: - - - Drives: 2 (4 configured) - Volumes: 2 (4 configured) - Plexes: 3 (8 configured) - Subdisks: 3 (16 configured) - - D a State: up Device /dev/da3h Avail: 1549/2573 MB (60%) - D b State: up Device /dev/da4h Avail: 2061/2573 MB (80%) - - V myvol State: up Plexes: 1 Size: 512 MB - V mirror State: up Plexes: 2 Size: 512 MB - - P myvol.p0 C State: up Subdisks: 1 Size: 512 MB - P mirror.p0 C State: up Subdisks: 1 Size: 512 MB - P mirror.p1 C State: initializing Subdisks: 1 Size: 512 MB - - S myvol.p0.s0 State: up PO: 0 B Size: 512 MB - S mirror.p0.s0 State: up PO: 0 B Size: 512 MB - S mirror.p1.s0 State: empty PO: 0 B Size: 512 MB - - stellt diese Struktur - grafisch dar. - - -
- Ein gespiegeltes Vinum Volume - -
- - - In diesem Beispiel enthält jeder Plexus die vollen - 512 MB des Adressraumes. Wie im vorangegangenen Beispiel - enthält jeder Plexus nur eine Subdisk. - - - - Die Leistung optimieren - - Das gespiegelte Volume des letzten Beispieles ist - resistenter gegenüber Fehlern als ein ungespiegeltes - Volume, seine Leistung ist hingegen schlechter, da jeder - Schreibzugriff auf das Volume einen Schreibzugriff auf beide - Platten erfordert und damit mehr der insgesamt verfügbaren - Datentransferrate benötigt. Steht also die optimale - Leistung im Vordergrund, muss anders vorgegangen werden: - Statt alle Daten zu spiegeln, werden die Daten über - so viele Platten wie möglich gestriped. Die folgende - Konfiguration zeigt ein Volume - mit einem über vier Platten hinwegreichenden Plexus: - - - drive c device /dev/da5h - drive d device /dev/da6h - volume stripe - plex org striped 512k - sd length 128m drive a - sd length 128m drive b - sd length 128m drive c - sd length 128m drive d - - Wie zuvor ist es nicht nötig, die Platten zu *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***