svn commit: r39415 - in projects/sgml2xml:
de_DE.ISO8859-1/books/handbook/vinum
en_US.ISO8859-1/htdocs/layout ja_JP.eucJP/htdocs/ports
Gabor Kovesdan
gabor at FreeBSD.org
Tue Aug 21 18:58:50 UTC 2012
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 at FreeBSD.org>
- and Tom Rhodes <trhodes at 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 at FreeBSD.org>
+ and Tom Rhodes <trhodes at 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 ***
More information about the svn-doc-projects
mailing list