Date: Tue, 21 Aug 2012 18:58:50 +0000 (UTC) From: Gabor Kovesdan <gabor@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-projects@freebsd.org 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 Message-ID: <201208211858.q7LIwodv087392@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
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 @@ <?xml version="1.0" encoding="ISO8859-1" standalone="no"?> -<!-- - The Vinum Volume Manager - By Greg Lehey (grog at lemis dot com) - - Added to the Handbook by Hiten Pandya <hmp@FreeBSD.org> - and Tom Rhodes <trhodes@FreeBSD.org> - - The FreeBSD Documentation Project - The FreeBSD German Documentation Project - - $FreeBSD$ - $FreeBSDde: de-docproj/books/handbook/vinum/chapter.sgml,v 1.19 2011/01/30 13:27:20 bcr Exp $ - basiert auf: 1.49 ---> - -<chapter id="vinum-vinum"> - <chapterinfo> - <authorgroup> - <author> - <firstname>Greg</firstname> - <surname>Lehey</surname> - <contrib>Ursprünglich geschrieben von </contrib> - </author> - </authorgroup> - <authorgroup> - <author> - <firstname>Johann</firstname> - <surname>Kois</surname> - <contrib>Übersetzt von </contrib> - </author> - <author> - <firstname>Kay</firstname> - <surname>Abendroth</surname> - </author> - </authorgroup> - </chapterinfo> - - <title>Der Vinum Volume Manager</title> - - <sect1 id="vinum-synopsis"> - <title>Übersicht</title> - - - <para>Egal, über welche und wieviele Festplatten Ihr System - auch verfügt, immer wieder werden Sie mit den folgenden - Problemen konfrontiert:</para> - - <itemizedlist> - <listitem> - <para>Ihre Platten sind zu klein.</para> - </listitem> - - <listitem> - <para>Sie sind zu langsam.</para> - </listitem> - - <listitem> - <para>Ihre Platten sind unzuverlässig.</para> - </listitem> - </itemizedlist> - - <para>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 - <emphasis>Vinum</emphasis> handelt es sich um einen - sogenannten <emphasis>Volume Manager</emphasis>, 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).</para> - - <para>Dieses Kapitel bietet Ihnen einen Überblick über - potentielle Probleme der klassischen Datenspeicherung auf - Festplatten sowie eine Einführung in den Vinum - Volume Manager.</para> - - <note> - <para>Für &os; 5.X wurde Vinum überarbeitet und - an die GEOM-Architektur (<xref linkend="GEOM"/>) angepasst, - wobei die ursprünglichen Ideeen und Begriffe sowie die - auf der Platte benötigten Metadaten beibehalten wurden. - Die überarbeitete Version wird als - <emphasis>gvinum</emphasis> (für - <emphasis>GEOM-Vinum</emphasis>) bezeichnet. Die folgenden - Ausführungen verwenden den Begriff - <emphasis>Vinum</emphasis> als abstrakten Namen, unabhängig - davon, welche Variante implementiert wurde. Sämtliche - Befehlsaufrufe erfolgen über <command>gvinum</command>, - welches nun das Kernelmodul <filename>geom_vinum.ko</filename> - (statt <filename>vinum.ko</filename>) benötigt. Analog - finden sich alle Gerätedateien nun unter <filename - class="directory">/dev/gvinum</filename> statt unter <filename - class="directory">/dev/vinum</filename>. Seit &os; 6.x ist die - alte Vinum-Implementierung nicht mehr im Basissystem enthalten.</para> - </note> - </sect1> - - <sect1 id="vinum-intro"> - <title>Ihre Platten sind zu klein.</title> - - <indexterm><primary>Vinum</primary></indexterm> - <indexterm> - <primary>RAID</primary> - <secondary>Software</secondary> - </indexterm> - - <para>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.</para> - </sect1> - - <sect1 id="vinum-access-bottlenecks"> - <title>Mögliche Engpässe</title> - - <para>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.</para> - - <para>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.</para> - - <para>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.</para> - - <para><anchor id="vinum-latency"/>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.</para> - - <para>Die traditionelle und offensichtliche Lösung zur - Beseitigung dieses Flaschenhalses sind <quote>mehr - Spindeln</quote>. 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.</para> - - <para>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.</para> - - <indexterm> - <primary>Plattenkonkatenation</primary> - </indexterm> - <indexterm> - <primary>Vinum</primary> - <secondary>Konkatenation</secondary> - </indexterm> - - <para>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 - <emphasis>Konkatenation</emphasis> 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. - <xref linkend="vinum-concat"/> verdeutlicht die Verteilung der - Speichereinheiten in einer konkatenierten Anordnung.</para> - - <para> - <figure id="vinum-concat"> - <title>Konkatenierte Anordnung</title> - <graphic fileref="vinum/vinum-concat"/> - </figure> - </para> - - <indexterm> - <primary>Striping von Platten</primary> - </indexterm> - <indexterm> - <primary>Vinum</primary> - <secondary>Striping</secondary> - </indexterm> - <indexterm> - <primary>RAID</primary> - </indexterm> - - <para>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 <emphasis>Striping</emphasis> oder +<!-- + The Vinum Volume Manager + By Greg Lehey (grog at lemis dot com) + + Added to the Handbook by Hiten Pandya <hmp@FreeBSD.org> + and Tom Rhodes <trhodes@FreeBSD.org> + + The FreeBSD Documentation Project + The FreeBSD German Documentation Project + + $FreeBSD$ + $FreeBSDde: de-docproj/books/handbook/vinum/chapter.sgml,v 1.19 2011/01/30 13:27:20 bcr Exp $ + basiert auf: 1.49 +--> + +<chapter id="vinum-vinum"> + <chapterinfo> + <authorgroup> + <author> + <firstname>Greg</firstname> + <surname>Lehey</surname> + <contrib>Ursprünglich geschrieben von </contrib> + </author> + </authorgroup> + <authorgroup> + <author> + <firstname>Johann</firstname> + <surname>Kois</surname> + <contrib>Übersetzt von </contrib> + </author> + <author> + <firstname>Kay</firstname> + <surname>Abendroth</surname> + </author> + </authorgroup> + </chapterinfo> + + <title>Der Vinum Volume Manager</title> + + <sect1 id="vinum-synopsis"> + <title>Übersicht</title> + + + <para>Egal, über welche und wieviele Festplatten Ihr System + auch verfügt, immer wieder werden Sie mit den folgenden + Problemen konfrontiert:</para> + + <itemizedlist> + <listitem> + <para>Ihre Platten sind zu klein.</para> + </listitem> + + <listitem> + <para>Sie sind zu langsam.</para> + </listitem> + + <listitem> + <para>Ihre Platten sind unzuverlässig.</para> + </listitem> + </itemizedlist> + + <para>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 + <emphasis>Vinum</emphasis> handelt es sich um einen + sogenannten <emphasis>Volume Manager</emphasis>, 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).</para> + + <para>Dieses Kapitel bietet Ihnen einen Überblick über + potentielle Probleme der klassischen Datenspeicherung auf + Festplatten sowie eine Einführung in den Vinum + Volume Manager.</para> + + <note> + <para>Für &os; 5.X wurde Vinum überarbeitet und + an die GEOM-Architektur (<xref linkend="GEOM"/>) angepasst, + wobei die ursprünglichen Ideeen und Begriffe sowie die + auf der Platte benötigten Metadaten beibehalten wurden. + Die überarbeitete Version wird als + <emphasis>gvinum</emphasis> (für + <emphasis>GEOM-Vinum</emphasis>) bezeichnet. Die folgenden + Ausführungen verwenden den Begriff + <emphasis>Vinum</emphasis> als abstrakten Namen, unabhängig + davon, welche Variante implementiert wurde. Sämtliche + Befehlsaufrufe erfolgen über <command>gvinum</command>, + welches nun das Kernelmodul <filename>geom_vinum.ko</filename> + (statt <filename>vinum.ko</filename>) benötigt. Analog + finden sich alle Gerätedateien nun unter <filename + class="directory">/dev/gvinum</filename> statt unter <filename + class="directory">/dev/vinum</filename>. Seit &os; 6.x ist die + alte Vinum-Implementierung nicht mehr im Basissystem enthalten.</para> + </note> + </sect1> + + <sect1 id="vinum-intro"> + <title>Ihre Platten sind zu klein.</title> + + <indexterm><primary>Vinum</primary></indexterm> + <indexterm> + <primary>RAID</primary> + <secondary>Software</secondary> + </indexterm> + + <para>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.</para> + </sect1> + + <sect1 id="vinum-access-bottlenecks"> + <title>Mögliche Engpässe</title> + + <para>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.</para> + + <para>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.</para> + + <para>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.</para> + + <para><anchor id="vinum-latency"/>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.</para> + + <para>Die traditionelle und offensichtliche Lösung zur + Beseitigung dieses Flaschenhalses sind <quote>mehr + Spindeln</quote>. 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.</para> + + <para>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.</para> + + <indexterm> + <primary>Plattenkonkatenation</primary> + </indexterm> + <indexterm> + <primary>Vinum</primary> + <secondary>Konkatenation</secondary> + </indexterm> + + <para>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 + <emphasis>Konkatenation</emphasis> 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. + <xref linkend="vinum-concat"/> verdeutlicht die Verteilung der + Speichereinheiten in einer konkatenierten Anordnung.</para> + + <para> + <figure id="vinum-concat"> + <title>Konkatenierte Anordnung</title> + <graphic fileref="vinum/vinum-concat"/> + </figure> + </para> + + <indexterm> + <primary>Striping von Platten</primary> + </indexterm> + <indexterm> + <primary>Vinum</primary> + <secondary>Striping</secondary> + </indexterm> + <indexterm> + <primary>RAID</primary> + </indexterm> + + <para>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 <emphasis>Striping</emphasis> oder <acronym>RAID-0</acronym>. - <footnote> - <para><acronym>RAID</acronym> steht für <emphasis>Redundant - Array of Inexpensive Disks</emphasis> und bietet verschiedene - Formen der Fehlertorleranz, obwohl der letzte Begriff etwas - irreführend ist, da RAID keine Redundanz bietet.</para> + <footnote> + <para><acronym>RAID</acronym> steht für <emphasis>Redundant + Array of Inexpensive Disks</emphasis> und bietet verschiedene + Formen der Fehlertorleranz, obwohl der letzte Begriff etwas + irreführend ist, da RAID keine Redundanz bietet.</para> </footnote></para> - - <para>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. <xref linkend="vinum-striped"/> veranschaulicht - die Abfolge, in der Speichereinheiten in einer striped-Anordnung - alloziert werden.</para> - - <para> - <figure id="vinum-striped"> - <title>Striped-Anordnung</title> - <graphic fileref="vinum/vinum-striped"/> - </figure> - </para> - </sect1> - - <sect1 id="vinum-data-integrity"> - <title>Datenintegrität</title> - - <para>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.</para> - - <indexterm> - <primary>disk mirroring</primary> - </indexterm> - <indexterm> - <primary>Vinum</primary> - <secondary>Spiegelung</secondary> - </indexterm> - <indexterm> - <primary>RAID-1</primary> - </indexterm> - - <para>Die traditionelle Art, dieses Problem anzugehen, war es, - Daten zu <emphasis>spiegeln</emphasis>, also zwei Kopien der - Daten auf getrennten Platten zu verwahren. Diese Technik wird - auch als <acronym>RAID Level 1</acronym> oder - <acronym>RAID-1</acronym> 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.</para> - - <para>Spiegeln verursacht allerdings zwei Probleme:</para> - - <itemizedlist> - <listitem> - <para>Es verursacht höhere Kosten, da doppelt so viel - Plattenspeicher wie bei einer nicht-redundanten - Lösung benötigt wird.</para> - </listitem> - - <listitem> - <para>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.</para> - </listitem> - </itemizedlist> - - <indexterm><primary>RAID-5</primary></indexterm> - - <para>Eine alternative Lösung ist - <emphasis>Parity</emphasis>, das in den - <acronym>RAID</acronym>-Leveln 2, 3, 4 und 5 - implementiert ist. Von diesen ist <acronym>RAID-5</acronym> - 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 <acronym>RAID-5</acronym> - vorgeschrieben, ist die Position dieses Paritätsblockes - auf jedem Stripe unterschiedlich. Die Nummern in den - Datenblöcken geben die relativen Blocknummern an.</para> - - <para> - <figure id="vinum-raid5-org"> - <title>RAID-5 Aufbau</title> - <graphic fileref="vinum/vinum-raid5-org"/> - </figure> - </para> - - <para>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.</para> - </sect1> - - <sect1 id="vinum-objects"> - <title>Vinum-Objekte</title> - <para>Um die in den vorigen Abschnitte besprochenen Probleme zu - lösen, verwendet Vinum eine vierstufige - Objekthierarchie:</para> - - <itemizedlist> - <listitem> - <para>Das auffälligste Objekt ist die virtuelle Platte, - die <emphasis>Volume</emphasis> 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.</para> - </listitem> - - <listitem> - <para>Volumes bestehen aus einem oder mehreren - <emphasis>Plexus</emphasis>, - 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.</para> - </listitem> - - <listitem> - <para>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 - <emphasis>Platte</emphasis>) in zusammenhängende - Bereiche, die als <emphasis>Subdisks</emphasis> bezeichnet - werden und als Grundbausteine für einen Plexus - benutzt werden.</para> - </listitem> - - <listitem> - <para>Subdisks befinden sich auf - Vinum-<emphasis>Platten</emphasis>, 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.</para> - </listitem> - </itemizedlist> - - <para>Der folgende Abschnitt beschreibt, wie diese Objekte - die von Vinum benötigten Funktionen zur - Verfügung stellen.</para> - - <sect2> - <title>Überlegungungen zur Größe eines Volumes</title> - - <para>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.</para> - </sect2> - - <sect2> - <title>Redundante Datenspeicherung</title> - - <para>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.</para> - - <para>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.</para> - </sect2> - - <sect2> - <title>Überlegungen zur Leistung</title> - - <para>Sowohl Konkatenation als auch Striping werden von Vinum - auf der Plexus-Ebene realisiert:</para> - - <itemizedlist> - <listitem> - <para>Ein <emphasis>konkatenierter Plexus</emphasis> benutzt - abwechselnd den Adressraum jeder Subdisk.</para> - </listitem> - - <listitem> - <para>Ein <emphasis>gestripter Plexus</emphasis> 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.</para> - </listitem> - </itemizedlist> - </sect2> - - <sect2> - <title>Wie ist ein Plexus aufgebaut?</title> - - <para>Die Version von Vinum, welche von &os;-&rel.current; - bereitgestellt wird, implementiert zwei Arten von Plexus:</para> - - <itemizedlist> - <listitem> - <para>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 - <acronym>CPU</acronym>-Zeit als gestripte Plexus, obwohl - der Unterschied des <acronym>CPU</acronym>-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.</para> - </listitem> - - <listitem> - <para>Der größte Vorteil eines gestripten - Plexus (<acronym>RAID-0</acronym>) 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.</para> - </listitem> - </itemizedlist> - - <para><xref linkend="vinum-comparison"/> fasst die Vor- und - Nachteile jedes Plexus-Aufbaus zusammen.</para> - - <table id="vinum-comparison" frame="none"> - <title>Vinum-Plexus - Aufbau</title> - - <tgroup cols="5"> - <thead> - <row> - <entry>Plexus-Typ</entry> - <entry>Minimum an Subdisks?</entry> - <entry>Kann Subdisks hinzufügen?</entry> - <entry>Müssen die gleiche Größe - haben</entry> - <entry>Applikation</entry> - </row> - </thead> - - <tbody> - <row> - <entry>konkateniert</entry> - <entry>1</entry> - <entry>ja</entry> - <entry>nein</entry> - <entry>Großer Datenspeicher mit maximaler - Platzierungsflexibilität und moderater - Leistung</entry> - </row> - - <row> - <entry>gestriped</entry> - <entry>2</entry> - <entry>nein</entry> - <entry>ja</entry> - <entry>Hohe Leistung in Kombination mit - gleichzeitigem Zugriff</entry> - </row> - </tbody> - </tgroup> - </table> - </sect2> - </sect1> - - <sect1 id="vinum-examples"> - <title>Einige Beispiele</title> - - <para>Vinum verwaltet eine - <emphasis>Konfigurationsdatenbank</emphasis> 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 <emphasis>Device</emphasis> - bezeichnet). Da die Datenbank bei jedem Statuswechsel - aktualisiert wird, kann nach einem Neustart der Status - jedes Vinum-Objekts exakt wiederhergestellt werden.</para> - - <sect2> - <title>Die Konfigurationsdatei</title> - - <para>Die Konfigurationsdatei beschreibt individuelle - Vinum-Objekte. Die Beschreibung eines einfachen Volumes - könnte beispielsweise so aussehen:</para> - - <programlisting> - drive a device /dev/da3h - volume myvol - plex org concat - sd length 512m drive a</programlisting> - - <para>Diese Datei beschreibt vier Vinum-Objekte:</para> - - <itemizedlist> - <listitem> - <para>Die <emphasis>drive</emphasis>-Zeile beschreibt eine - Plattenpartition (<emphasis>drive</emphasis>) sowie ihre - Position in Bezug auf die darunter liegende Hardware. - Die Partition hat dabei den symbolischen Namen - <emphasis>a</emphasis>. Diese Trennung von symbolischen - Namen und Gerätenamen erlaubt es, die Position von - Platten zu ändern, ohne dass es zu Problemen - kommt.</para> - </listitem> - - <listitem> - <para>Die <emphasis>volume</emphasis>-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 <emphasis>myvol</emphasis>.</para> - </listitem> - - <listitem> - <para>Die <emphasis>plex</emphasis>-Zeile definiert einen - Plexus. Auch hier wird nur ein Parameter, und zwar die - Art des Aufbau, benötigt (in unserem Fall - <emphasis>concat</emphasis>). Es wird kein Name - benötigt, das System generiert automatisch einen - Namen aus dem Volume-Namen und dem Suffix - <emphasis>.p</emphasis><emphasis>x</emphasis> wobei - <emphasis>x</emphasis> die Nummer des Plexus innerhalb - des Volumes angibt. So wird dieser Plexus den Namen - <emphasis>myvol.p0</emphasis> erhalten.</para> - </listitem> - - <listitem> - <para>Die <emphasis>sd</emphasis>-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 <emphasis>.s</emphasis><emphasis>x</emphasis> - gebildet werden, wobei <emphasis>x</emphasis> die Nummer - der Subdisk innerhalb des Plexus ist. Folglich gibt - Vinum dieser Subdisk den Namen - <emphasis>myvol.p0.s0</emphasis>.</para> - </listitem> - </itemizedlist> - - <para>Nach dem Verarbeiten dieser Datei erzeugt &man.gvinum.8; - die folgende Ausgabe:</para> - - <programlisting width="97"> - &prompt.root; gvinum -> <userinput>create config1</userinput> - 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</programlisting> - - <para>Diese Ausgabe entspricht dem verkürzten - Ausgabeformat von &man.gvinum.8; und wird in - <xref linkend="vinum-simple-vol"/> grafisch dargestellt.</para> - - <para> - <figure id="vinum-simple-vol"> - <title>Ein einfaches Vinum-Volume</title> - <graphic fileref="vinum/vinum-simple-vol"/> - </figure> - </para> - - <para>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.</para> - - <para>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.</para> - </sect2> - - <sect2> - <title>Verbesserte Ausfallsicherheit durch Spiegelung</title> - - <para>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:</para> - - <programlisting> - drive b device /dev/da4h - volume mirror - plex org concat - sd length 512m drive a - plex org concat - sd length 512m drive b</programlisting> - - <para>Bei diesem Beispiel war es nicht nötig, noch einmal - eine Platte <emphasis>a</emphasis> 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:</para> - - <programlisting width="97"> - 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</programlisting> - - <para><xref linkend="vinum-mirrored-vol"/> stellt diese Struktur - grafisch dar.</para> - - <para> - <figure id="vinum-mirrored-vol"> - <title>Ein gespiegeltes Vinum Volume</title> - <graphic fileref="vinum/vinum-mirrored-vol"/> - </figure> - </para> - - <para>In diesem Beispiel enthält jeder Plexus die vollen - 512 MB des Adressraumes. Wie im vorangegangenen Beispiel - enthält jeder Plexus nur eine Subdisk.</para> - </sect2> - - <sect2> - <title>Die Leistung optimieren</title> - - <para>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:</para> - - <programlisting> - 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</programlisting> - - <para>Wie zuvor ist es nicht nötig, die Platten zu *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201208211858.q7LIwodv087392>