diff options
Diffstat (limited to 'de_DE.ISO8859-1/books/handbook/vinum/chapter.xml')
| -rw-r--r-- | de_DE.ISO8859-1/books/handbook/vinum/chapter.xml | 1440 |
1 files changed, 1440 insertions, 0 deletions
diff --git a/de_DE.ISO8859-1/books/handbook/vinum/chapter.xml b/de_DE.ISO8859-1/books/handbook/vinum/chapter.xml new file mode 100644 index 0000000000..4784c0247d --- /dev/null +++ b/de_DE.ISO8859-1/books/handbook/vinum/chapter.xml @@ -0,0 +1,1440 @@ +<?xml version="1.0" encoding="iso-8859-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.xml,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> + + <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 + definieren, die Vinum schon bekannt sind. Nach dem Abarbeiten + dieser Definition sieht die Konfiguration wie folgt aus:</para> + + <programlisting width="92"> + Drives: 4 (4 configured) + Volumes: 3 (4 configured) + Plexes: 4 (8 configured) + Subdisks: 7 (16 configured) + + D a State: up Device /dev/da3h Avail: 1421/2573 MB (55%) + D b State: up Device /dev/da4h Avail: 1933/2573 MB (75%) + D c State: up Device /dev/da5h Avail: 2445/2573 MB (95%) + D d State: up Device /dev/da6h Avail: 2445/2573 MB (95%) + + V myvol State: up Plexes: 1 Size: 512 MB + V mirror State: up Plexes: 2 Size: 512 MB + V striped State: up Plexes: 1 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 + P striped.p1 State: up 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 + S striped.p0.s0 State: up PO: 0 B Size: 128 MB + S striped.p0.s1 State: up PO: 512 kB Size: 128 MB + S striped.p0.s2 State: up PO: 1024 kB Size: 128 MB + S striped.p0.s3 State: up PO: 1536 kB Size: 128 MB</programlisting> + + <para> + <figure id="vinum-striped-vol"> + <title>Ein Striped Vinum Volume</title> + <graphic fileref="vinum/vinum-striped-vol"/> + </figure> + </para> + + <para>Dieses Volume wird in <xref linkend="vinum-striped-vol"/> + dargestellt. Die Schattierung der Stripes zeigt die Position + innerhalb des Plexus-Adressraumes an. Die hellsten Stripes + kommen zuerst, die dunkelsten zuletzt.</para> + </sect2> + + <sect2> + <title>Ausfallsicherheit und Leistung</title> + + <para><anchor id="vinum-resilience"/>Mit entsprechender Hardware + ist es möglich, Volumes zu bauen, welche gegenüber + Standard-&unix;-Partitionen beides, nämlich erhöhte + Ausfallsicherheit und erhöhte Leistung, aufweisen + können. Eine typische Konfigurationsdatei könnte + etwa so aussehen:</para> + + <programlisting> + volume raid10 + plex org striped 512k + sd length 102480k drive a + sd length 102480k drive b + sd length 102480k drive c + sd length 102480k drive d + sd length 102480k drive e + plex org striped 512k + sd length 102480k drive c + sd length 102480k drive d + sd length 102480k drive e + sd length 102480k drive a + sd length 102480k drive b</programlisting> + + <para>Die Subdisks des zweiten Plexus sind gegenüber denen + des ersten Plexus um zwei Platten verschoben. Dadurch wird + sichergestellt, dass Schreibzugriffe nicht auf den gleichen + Subdisks auftreten, auch wenn eine Übertragung über + zwei Platten geht.</para> + + <para><xref linkend="vinum-raid10-vol"/> veranschaulicht die + Struktur dieses Volumes.</para> + + <para> + <figure id="vinum-raid10-vol"> + <title>Ein gespiegeltes, Striped Vinum Volume</title> + <graphic fileref="vinum/vinum-raid10-vol"/> + </figure> + </para> + </sect2> + </sect1> + + <sect1 id="vinum-object-naming"> + <title>Objektbenennung</title> + + <para>Wie oben beschrieben, weist Vinum den Plexus und + Subdisks Standardnamen zu, wenngleich diese überschrieben + werden können. Das Überschreiben dieser Standardnamen + wird allerdings nicht empfohlen. Erfahrungen mit dem VERITAS + Volume Manager (der eine willkürliche Benennung von + Objekten erlaubt) haben gezeigt, dass diese Flexibilität + keinen entscheidenden Vorteil bringt und zudem Verwirrung + stiften kann.</para> + + <para>Namen dürfen zwar alle nichtleeren Zeichen enthalten, + es ist aber sinnvoll, nur Buchstaben, Ziffern und den + Unterstrich zu verwenden. Die Namen von Volumes, Plexus und + Subdisks können bis zu 64 Zeichen lang sein, die Namen + von Platten dürfen hingegen nur bis zu 32 Zeichen lang + sein.</para> + + <para>Vinum-Objekten werden Gerätedateien in der <filename + class="directory">/dev/gvinum</filename>-Hierarchie zugewiesen. Die + weiter oben dargestellte Konfiguration würde Vinum dazu + veranlassen, die folgenden Gerätedateien zu erstellen:</para> + + <itemizedlist> + <listitem> + <para>Geräte-Einträge für jedes Volume. + Dieses sind die Hauptgeräte, die von Vinum benutzt + werden. Somit würde die Konfiguration von oben + folgende Geräte beinhalten: + <filename class="devicefile">/dev/gvinum/myvol</filename>, + <filename class="devicefile">/dev/gvinum/mirror</filename>, + <filename class="devicefile">/dev/gvinum/striped</filename>, + <filename class="devicefile">/dev/gvinum/raid5</filename> sowie + <filename class="devicefile">/dev/gvinum/raid10</filename>.</para> + </listitem> + + <listitem> + <para>Alle Volumes bekommen direkte Einträge unter <filename + class="directory">/dev/gvinum/</filename>.</para> + </listitem> + + <listitem> + <para>Die Verzeichnisse <filename + class="directory">/dev/gvinum/plex</filename> und <filename + class="directory">/dev/gvinum/sd</filename>, die Gerätedateien + für jeden Plexus sowie jede Subdisk enthalten.</para> + </listitem> + </itemizedlist> + + <para>Stellen Sie sich folgende Konfigurationsdatei vor:</para> + + <programlisting> + drive drive1 device /dev/sd1h + drive drive2 device /dev/sd2h + drive drive3 device /dev/sd3h + drive drive4 device /dev/sd4h + volume s64 setupstate + plex org striped 64k + sd length 100m drive drive1 + sd length 100m drive drive2 + sd length 100m drive drive3 + sd length 100m drive drive4</programlisting> + + <para>Nach Abarbeitung dieser Datei erstellt &man.gvinum.8; die + folgende Struktur unter <filename + class="directory">/dev/gvinum</filename>:</para> + + <programlisting> + drwxr-xr-x 2 root wheel 512 Apr 13 16:46 plex + crwxr-xr-- 1 root wheel 91, 2 Apr 13 16:46 s64 + drwxr-xr-x 2 root wheel 512 Apr 13 16:46 sd + + /dev/vinum/plex: + total 0 + crwxr-xr-- 1 root wheel 25, 0x10000002 Apr 13 16:46 s64.p0 + + /dev/vinum/sd: + total 0 + crwxr-xr-- 1 root wheel 91, 0x20000002 Apr 13 16:46 s64.p0.s0 + crwxr-xr-- 1 root wheel 91, 0x20100002 Apr 13 16:46 s64.p0.s1 + crwxr-xr-- 1 root wheel 91, 0x20200002 Apr 13 16:46 s64.p0.s2 + crwxr-xr-- 1 root wheel 91, 0x20300002 Apr 13 16:46 s64.p0.s3</programlisting> + + <para>Es wird empfohlen, für Plexus und Subdisks keine + eigenen Namen zu vergeben. Dies gilt aber nicht für + Vinum-Platten. Durch die Benennung von Vinum-Platten + wird es erst möglich, eine Platte an einen anderen Ort zu + verschieben und sie trotzdem noch automatisch erkennen zu lassen. + Plattennamen können bis zu 32 Zeichen lang sein.</para> + + <sect2> + <title>Dateisysteme erstellen</title> + + <para>Volumes erscheinen (mit einer Ausnahme) dem System nicht + anders als Platten. Anders als &unix;-Platten partitioniert + Vinum seine Volumes nicht, weshalb diese auch keine + Partitionstabellen haben. Dies wiederum hat Modifikationen an + einigen Platten-Tools, insbesondere &man.newfs.8;, nötig + gemacht, welche bis dahin den letzten Buchstaben eines + Vinum-Volume-Namen als Partitionsbezeichner identifiziert haben. + Zum Beispiel könnte eine Platte einen Namen wie + <filename class="devicefile">/dev/ad0a</filename> oder + <filename class="devicefile">/dev/da2h</filename> haben. Diese Namen + bedeuten, dass es sich um die erste Partition + (<devicename>a</devicename>) der ersten (0) IDE-Platte + (<devicename>ad</devicename>) und respektive die achte + Partition (<devicename>h</devicename>) der dritten (2) + SCSI-Platte (<devicename>da</devicename>) handelt. Im Vergleich + dazu könnte ein Vinum-Volume beispielsweise <filename + class="devicefile">/dev/gvinum/concat</filename> heißen, ein Name, + der in keiner Beziehung mit einem Partitionsnamen steht.</para> + + <para>Um nun ein Dateisystem auf diesem Volume anzulegen, benutzen + Sie &man.newfs.8;:</para> + + <screen>&prompt.root; <userinput>newfs /dev/gvinum/concat</userinput></screen> + </sect2> + </sect1> + + <sect1 id="vinum-config"> + <title>Vinum konfigurieren</title> + + <para>Der <filename>GENERIC</filename>-Kernel enthät kein + Vinum. Es ist zwar möglich, einen speziellen Kernel zu + bauen, der Vinum beinhaltet, empfohlen wird aber, Vinum als + ein Kernelmodul (über <acronym>kld</acronym>) zu laden. + Dazu müssen Sie nicht einmal &man.kldload.8; benutzen, + da beim Start von &man.gvinum.8; automatisch überprüft + wird, ob das Modul bereits geladen wurde. Falls das Modul noch + nicht geladen wurde, wird es daraufhin geladen.</para> + + <sect2> + <title>Inbetriebnahme</title> + + <para>Vinum speichert seine Konfigurationsinformationen auf den + Platten-Slices im Wesentlichen genauso ab wie in den + Konfigurationsdateien. Beim Lesen der Konfigurationsdatenbank + erkennt Vinum eine Anzahl von Schlüsselwörtern, die + in den Konfigurationsdateien nicht erlaubt sind. Zum Beispiel + könnte eine Platten-Konfiguration den folgenden Text + enthalten:</para> + + <programlisting width="119">volume myvol state up +volume bigraid state down +plex name myvol.p0 state up org concat vol myvol +plex name myvol.p1 state up org concat vol myvol +plex name myvol.p2 state init org striped 512b vol myvol +plex name bigraid.p0 state initializing org raid5 512b vol bigraid +sd name myvol.p0.s0 drive a plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 0b +sd name myvol.p0.s1 drive b plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 1048576b +sd name myvol.p1.s0 drive c plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 0b +sd name myvol.p1.s1 drive d plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 1048576b +sd name myvol.p2.s0 drive a plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 0b +sd name myvol.p2.s1 drive b plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 524288b +sd name myvol.p2.s2 drive c plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1048576b +sd name myvol.p2.s3 drive d plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1572864b +sd name bigraid.p0.s0 drive a plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 0b +sd name bigraid.p0.s1 drive b plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 4194304b +sd name bigraid.p0.s2 drive c plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 8388608b +sd name bigraid.p0.s3 drive d plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 12582912b +sd name bigraid.p0.s4 drive e plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 16777216b</programlisting> + + <para>Die offensichtlichen Unterschiede sind hier die Anwesenheit + von Informationen über explizite Speicherorte und + Benennungen (beides ist zwar erlaubt, aber es wird dem Benutzer + davon abgeraten, es zu benutzen) und Informationen über die + Zustände (welche für den Benutzer nicht zur + Verfügung stehen). Vinum speichert keine Informationen + über Platten in den Konfigurationsinformationen, es findet + die Platten durch Scannen nach Vinum-Markierungen auf den + eingerichteten Laufwerken. Dies ermöglicht es, + Vinum-Platten auch dann noch korrekt zu identifizieren, wenn + sie schon andere &unix;-Platten-IDs zugewiesen bekommen + haben.</para> + + <sect3 id="vinum-rc-startup"> + <title>Automatische Inbetriebnahme</title> + + <note> + <para><emphasis>Gvinum</emphasis> + unterstützt eine automatische Inbetriebnahme immer, + wenn das Kernelmodul über &man.loader.conf.5; geladen ist. + Um das <emphasis>Gvinum</emphasis> Modul beim Hochfahren des + Systems zu laden, fügen Sie die Zeile + <literal>geom_vinum_load="YES"</literal> in + <filename>/boot/loader.conf</filename> ein.</para> + </note> + + <para>Beim starten von Vinum durch den Befehl <command>vinum + start</command> liest Vinum die Konfigurationsdatenbank von + einer der Vinum-Platten. Unter normalen Umständen + enthält jede Platte eine identische Kopie der + Konfigurationsdatenbank, so dass es keine Rolle spielt, von + welcher der Platten diese eingelesen wird. Nach einem + Plattencrash muss Vinum allerdings zunächst feststellen, + welche der Platten zuletzt aktualisiert wurde und dann die + Konfiguration von dieser Platte lesen. Danach werden (falls + nötig) die Konfigurationen der "alten" Platten + aktualisiert.</para> + </sect3> + </sect2> + </sect1> +<!-- 2006-01-04__16:15 --> + <sect1 id="vinum-root"> + <title>Vinum für das Root-Dateisystem benutzen</title> + + <para>Auf einem System, das mit Hilfe von Vinum + vollgespiegelte Dateisysteme hat, ist es wünschenswert, auch + das Root-Dateisystem zu spiegeln. Solch eine Konfiguration ist + allerdings weniger trivial als das Spiegeln eines + gewöhnlichen Dateisystems, weil:</para> + + <itemizedlist> + <listitem> + <para>Das Root-Dateisystem in einer sehr frühen Phase + des Bootvorgangs verfügbar sein muss, und damit auch + die Vinum-Infrastruktur.</para> + </listitem> + + <listitem> + <para>Das Volume, welches das Root-Dateisystem enthält, + auch den Bootstrap und den Kernel enthält, die + wiederum nur mit den systemeigenen Tools (zum Beispiel + dem BIOS bei handelsüblichen PCs) gelesen werden + können und meist nicht dazu gebracht werden können, + Vinum zu verstehen.</para> + </listitem> + </itemizedlist> + + <para>Im folgenden Abschnitt wird der Begriff + <quote>Root-Volume</quote> benutzt, um das Vinum-Volume zu + beschreiben, welches das Root-Dateisystem enthält. Es ist + eine gute Idee, für dieses Volume den Namen + <literal>"root"</literal> zu benutzen, aber es ist in keiner + Weise technisch nötig (Das folgende Beispiel geht allerdings + davon aus, dass dies der Fall ist.).</para> + + <sect2> + <title>Vinum für das Root-Dateisystem rechtzeitig + starten</title> + + <para>Damit dies gelingt, müssen Sie folgende Aufgaben + erledigen:</para> + + <itemizedlist> + <listitem> + <para>Vinum muss zum Zeitpunkt des Bootvorganges im + Kernel zur Verfügung stehen. Deswegen ist die + Methode zum Start von Vinum, die in + <xref linkend="vinum-rc-startup"/> beschrieben wird, + für diese Aufgabe nicht geeignet. Also muss + auch der <literal>start_vinum</literal>-Parameter + eigentlich <emphasis>nicht</emphasis> gesetzt werden, + wenn man das folgende Setup einrichtet. Die erste + Möglichkeit wäre es, Vinum statisch in den + Kernel zu kompilieren, so dass es ständig + verfügbar ist, was aber in der Regel nicht + erwünscht ist. Ebenso gibt es die Möglichkeit + <filename>/boot/loader</filename> + (<xref linkend="boot-loader"/>) das Vinum-Kernelmodul + früh genug laden zu lassen (und zwar noch bevor + der Kernel gestartet wird). Dies kann bewerkstelligt + werden, indem die Zeile</para> + + <programlisting>geom_vinum_load="YES"</programlisting> + + <para>in die Datei <filename>/boot/loader.conf</filename> + eingetragen wird.</para> + </listitem> + + <listitem> + <para>Für <emphasis>Gvinum</emphasis> ist das oben + beschriebene Prozedere alles, was Sie tun müssen, + da der gesamte Startvorgang automatisch erledigt wird, + sobald das Kernelmodul geladen wurde.</para> + </listitem> + </itemizedlist> + </sect2> + + <sect2> + <title>Ein Vinum-basiertes Root-Volume dem Bootstrap + verfügbar machen</title> + + <para>Da der aktuelle &os;-Bootstrap nur 7,5 KB Code + enthält und schon ohne Vinum die Aufgabe hat, + bestimmte Dateien (wie <filename>/boot/loader</filename>) + von einem UFS-Dateisystem zu lesen, ist es schier + unmöglich, ihm auch noch die Interna von Vinum + beizubringen, damit er die Vinum-Konfigurationsdaten + auslesen und die Elemente eines Boot-Volumes selbst + herausfinden könnte. Daher sind ein paar Tricks + nötig, um dem Bootstrap-Code die Illusion + einer Standard-<literal>"a"</literal>-Partition mit + einem Root-Dateisystem vorzugaukeln.</para> + + <para>Damit dies überhaupt möglich wird, + müssen die folgenden Bedingungen für das + Root-Dateisystem erfüllt sein:</para> + + <itemizedlist> + <listitem> + <para>Das Root-Volume darf weder gestriped noch + RAID-5 sein.</para> + </listitem> + + <listitem> + <para>Das Root-Volume darf nicht mehr als eine konkatenierte + Subdisk pro Plexus enthalten.</para> + </listitem> + </itemizedlist> + + <para>Beachten Sie, dass es möglich und + wünschenswert ist, mehrere Plexus zu haben, von denen + jeder eine Kopie des Root-Dateisystems enthält. Der + Bootstrap-Prozess wird hingegen nur einen dieser Plexus + benutzen, um den Bootstrap und alle Dateien zu finden, bis der + Kernel letztendlich das Root-Dateisystem selbst laden wird. + Jede einzelne Subdisk innerhalb dieser Plexus wird dann ihre + eigene Illusion der Partition <literal>"a"</literal> brauchen, + damit das entsprechende Gerät bootbar wird. Es ist nicht + unbedingt notwendig, dass sich jede dieser gefälschten + <literal>"a"</literal>-Partitionen auf seinem Gerät an + einem Ort befindet, der um den selben Wert verschoben ist wie + auf den anderen Geräten, die Plexus des Root-Dateisystems + enthalten. Um Unklarheiten zu verhindern, ist es jedoch eine + gute Idee, die Vinum-Volumes so zu erstellen, dass die + gespiegelten Geräte symmetrisch sind.</para> + + <para>Damit diese <literal>"a"</literal>-Partitionen eingerichtet + werden können, muss für alle Geräte, die Teil des + Root-Dateisystems sind, folgendes getan werden:</para> + + <procedure> + <step> + <para>Der Ort (Verschiebung vom Beginn des Gerätes) und + die Größe der Subdisk, die Teil des Root-Volumes + ist, muss untersucht werden:</para> + + <screen>&prompt.root; <userinput>gvinum l -rv root</userinput></screen> + + <para>Beachten Sie, dass Vinum-Verschiebungen und + -Größen in Bytes gemessen werden. Sie müssen + deshalb durch 512 geteilt werden, um die Blockanzahl zu + erhalten, wie sie das <command>bsdlabel</command>-Kommando + verwendet.</para> + </step> + + <step> + <para>Führen Sie den Befehl</para> + + <screen>&prompt.root; <userinput>bsdlabel -e <replaceable>devname</replaceable></userinput></screen> + + <para>für jedes Gerät, dass am Root-Volume beteiligt + ist, aus. <replaceable>devname</replaceable> muss entweder + der Name der Platte (wie <devicename>da0</devicename>), im + Falle einer Platte ohne Slice-Tabelle oder der Name des + Slices (wie <devicename>ad0s1</devicename>) sein.</para> + + <para>Wenn es schon eine <literal>"a"</literal>-Partition auf + dem Gerät (in der Regel wahrscheinlich ein + Prä-Vinum-Root-Dateisystem) gibt, sollte diese + umbenannt werden, damit sie weiterhin verfügbar bleibt + (nur für den Fall). Sie wird aber nicht länger + benutzt, um das System zu starten. Beachten Sie aber, dass + aktive Partitionen (wie ein gemountetes Root-Dateisystem) + nicht umbenannt werden können, sodass Sie entweder von + einem <quote>Fixit</quote>-Medium booten müssen, oder + aber mittels eines zweistufigen Prozesses (sofern Sie in einer + gespiegelten Umgebung arbeiten) zuerst die Platte + ändern, von der gerade nicht gebootet wurde.</para> + + <para>Nun muss die Verschiebung der Vinum-Partition (sofern + vorhanden) auf diesem Gerät mit der Veschiebung der + entsprechenden Root-Volume-Subdisk addiert werden. Das + Resultat wird der <literal>"offset"</literal>-Wert für + die neue <literal>"a"</literal>-Partition. Der + <literal>"size"</literal>-Wert für diese Partition + kann entsprechend der Berechnung ermittelt werden. + <literal>"fstype"</literal> sollte <literal>4.2BSD</literal> + sein. Die <literal>"fsize"</literal>-, + <literal>"bsize"</literal>-, und + <literal>"cpg"</literal>- Werte sollten entsprechend dem + eigentlichen Dateisystem gewählt werden, obwohl sie in + diesem Kontext ziemlich unwichtig sind.</para> + + <para>Auf diese Art und Weise wird eine neue Partition + <literal>"a"</literal> etabliert, die die Vinum-Partition + auf diesem Gerät überschneidet. Beachte Sie, dass + das <command>bsdlabel</command>-Kommando diese + Überschneidung nur erlaubt, wenn die Partition richtig + mit dem <literal>"vinum"</literal>-fstype markiert ist.</para> + </step> + + <step> + <para>Das ist alles. Auf jedem Gerät befindet sich nun + eine gefälschte <literal>"a"</literal>-Partition, die + eine Kopie des Root-Volumes enthält. Es wird dringend + empfohlen, das Resultat dieser Konfiguration zu + überprüfen:</para> + + <screen>&prompt.root; <userinput>fsck -n /dev/<replaceable>devname</replaceable>a</userinput></screen> + </step> + </procedure> + + <para>Denken Sie stets daran, dass alle Dateien, die + Kontrollinformationen enthalten, nun relativ zum + Root-Dateisystem innerhalb des Vinum-Volumes sein müssen. + Denn ein neu eingerichtetes Vinum-Root-Dateisystem ist + möglicherweise inkompatibel zum gerade aktiven + Root-Dateisystem. Deshalb müssen insbesondere die + Dateien <filename>/etc/fstab</filename> und + <filename>/boot/loader.conf</filename> überprüft + werden.</para> + + <para>Beim nächsten Systemstart sollte der Bootstrap die + adäquaten Kontrollinformationen des neuen + Vinum-basierten Root-Dateisystems automatisch herausfinden und + entsprechend handeln. Am Ende des + Kernel-Initialisierungsprozesses (nachdem alle Geräte + angezeigt wurden) erhalten Sie bei einer erfolgreichen + Konfiguration eine Nachricht ähnlich der folgenden:</para> + + <screen>Mounting root from ufs:/dev/gvinum/root</screen> + </sect2> + + <sect2> + <title>Beispiel eines Vinum-basierten Root-Setups</title> + + <para>Nachdem das Vinum-Root-Volume eingerichtet wurde, + könnte die Ausgabe von <command>gvinum l -rv root</command> + bespielsweise so aussehen:</para> + + <screen> +... +Subdisk root.p0.s0: + Size: 125829120 bytes (120 MB) + State: up + Plex root.p0 at offset 0 (0 B) + Drive disk0 (/dev/da0h) at offset 135680 (132 kB) + +Subdisk root.p1.s0: + Size: 125829120 bytes (120 MB) + State: up + Plex root.p1 at offset 0 (0 B) + Drive disk1 (/dev/da1h) at offset 135680 (132 kB) + </screen> + + <para>Wichtig ist hier insbesondere ist der Wert + <literal>135680</literal> für die Verschiebung (relativ zur + Partition <filename + class="devicefile">/dev/da0h</filename>). Das entspricht + beim Einsatz von <command>bsdlabel</command> 265 + 512-Byte-Plattenblöcken. Dieses Root-Volume ist ebenso + 245760 512-Byte-Blöcke groß. + <filename class="devicefile">/dev/da1h</filename> enthält die + zweite Kopie dieses Root-Volumes und ist symmetrisch aufgebaut.</para> + + <para>Das Bsdlabel für diese Geräte könnte + so aussehen:</para> + + <screen> +... +8 partitions: +# size offset fstype [fsize bsize bps/cpg] + a: 245760 281 4.2BSD 2048 16384 0 # (Cyl. 0*- 15*) + c: 71771688 0 unused 0 0 # (Cyl. 0 - 4467*) + h: 71771672 16 vinum # (Cyl. 0*- 4467*) + </screen> + + <para>Wie man leicht feststellen kann, entspricht der Parameter + <literal>"size"</literal> der gefälschten + <literal>"a"</literal>-Partition dem ausgewiesenen Wert von + oben, während der Parameter + <literal>"offset"</literal> gleich der Summe der Verschiebung + innerhalb der Vinum-Partition <literal>"h"</literal> und der + Verschiebung innerhalb des Geräts (oder Slice) ist. Dies + ist ein typischer Aufbau, der nötig ist, um die in + <xref linkend="vinum-root-panic"/> beschriebenen Probleme zu + vermeiden. Die gesamte Partition <literal>"a"</literal> befindet + sich in <literal>"h"</literal>, die alle Vinum-Daten für + dieses Gerät enthält.</para> + + <para>Beachten Sie, dass in dem oben beschriebenen Beispiel das + gesamte Gerät Vinum gewidmet ist und keine + Prä-Vinum-Partition zurückgelassen wurde, da es sich + im Beispiel um eine neu eingerichtete Platte handelt, die nur + für die Vinum-Konfiguration bestimmt war.</para> + </sect2> + + <sect2> + <title>Fehlerbehebung</title> + + <para>Der folgende Abschnitt beschreibt einige bekannte + Probleme und Fallstricke bei der Vinum-Konfiguration sowie + deren Behebung.</para> + + <sect3> + <title>Der System-Bootstrap lädt zwar, das System startet + aber nicht.</title> + + <para>Wenn aus irgendeinem Grund das System nicht mit dem Booten + fortfährt, kann man den Bootstrap während der + 10-Sekunden-Warnung durch Drücken der + <keycap>Leertaste</keycap> unterbrechen. Die + <foreignphrase>loader</foreignphrase>-Variablen (wie + <literal>vinum.autostart</literal>) können mittels des + <command>show</command>-Kommandos untersucht, und mit + <command>set</command> oder <command>unset</command> + geändert werden.</para> + + <para>Wenn das einzige Problem das Fehlen des + Vinum-Kernelmoduls in der Liste der automatisch zu ladenden + Module ist, hilft ein einfaches + <command>load geom_vinum</command>.</para> + + <para>Danach können Sie den Bootvorgang mit + <command>boot -as</command> fortsetzen. Die Optionen + <option>-as</option> fordern den Kernel auf, nach dem zu + mountenden Root-Dateisystem zu fragen (<option>-a</option>), + und den Bootvorgang im Single-User-Modus + (<option>-s</option>) zu beenden, in dem das + Root-Dateisystem schon schreibgeschützt gemountet ist. + Auf diese Weise wird keine Dateninkonsistenz zwischen den + Plexus riskiert, auch wenn nur ein Plexus eines + Multi-Plexus-Volumes gemountet wurde.</para> + + <para>Beim Prompt, das nach einem Root-Dateisystem fragt, + kann jedes Gerät angegeben werden, dass ein + gültiges Root-Dateisystem hat. Wenn + <filename>/etc/fstab</filename> richtig konfiguriert + wurde, sollte die Vorgabe etwas wie + <literal>ufs:/dev/gvinum/root</literal> sein. Eine typische + Alternative würde etwas wie + <literal>ufs:da0d</literal> sein, welches eine + hypothetische Partition sein könnte, die ein + Pre-Vinum-Root-Dateisystem enthält. Vorsicht sollte + walten, wenn eine der <foreignphrase>alias</foreignphrase> + <literal>"a"</literal>-Partitionen hier eingegeben wird, die + eigentlich Referenzen auf die Subdisks des + Vinum-Root-Dateisystems sind, da so nur ein Stück eines + gespiegelten Root-Gerätes gemountet werden würde. + Wenn das Dateisystem später zum Lesen und Schreiben + gemountet werden soll, ist es nötig, die anderen Plexus + des Vinum-Root-Volumes zu entfernen, weil diese Plexus + andernfalls inkonsistente Daten enthalten würden.</para> + </sect3> + + <sect3> + <title>Nur der primäre Bootstrap lädt</title> + + <para>Wenn das Laden von <filename>/boot/loader</filename> + fehlschlägt, aber der primäre Bootstrap dennoch + lädt (sichtbar an dem einzelnen Strich in der linken + Spalte des Bildschirms gleich nachdem der Bootprozess + startet), kann man versuchen, den primären Bootstrap + an diesem Punkt durch Benutzen der + <keycap>Leertaste</keycap> zu unterbrechen. Dies wird + den Bootstrap in der zweiten Phase stoppen (siehe dazu auch + <xref linkend="boot-boot1"/>). Hier kann nun der Versuch + unternommen werden, von einer anderen Partition zu booten, + wie beispielsweise dem vorhergehenden Root-Dateisystem, + das von <literal>"a"</literal> verschoben wurde.</para> + </sect3> + + <sect3 id="vinum-root-panic"> + <title>Nichts bootet, der Bootstrap hängt sich auf</title> + + <para>Diese Situation wird vorkommen, wenn der Bootstrap durch + die Vinum-Installation zerstört worden ist. + Unglücklicherweise lässt Vinum am Anfang seiner + Partition nur 4 KB frei und schreibt dahinter seine + Kopfinformationen. Allerdings benötigen Stufe-Eins- + und -Zwei-Bootstraps plus dem dazwischen eingebetteten + <foreignphrase>bsdlabel</foreignphrase> momentan 8 KB. + Demzufolge wird die Vinum-Installation, wenn die + Vinum-Partition mit der Verschiebung 0 (innerhalb eines + Slice oder einer Platte, die zum Start bestimmt waren) + eingerichtet wurde, den Bootstrap zerstören.</para> + + <para>Analog wird eine anschließende + Reinstallation eines Bootstrap (zum Beispiel durch Booten + eines <quote>Fixit</quote>-Mediums) mit + <command>bsdlabel -B</command>, wie in + <xref linkend="boot-boot1"/> beschrieben, den Vinum-Kopf + zerstören und Vinum wird seine Platte(n) nicht mehr + finden können. Obwohl keine eigentlichen + Vinum-Konfigurationsdaten oder Daten in den Vinum-Volumes + zerstört werden und es möglich wäre, alle + Daten wiederherzustellen, indem die exakt gleichen + Vinum-Konfigurationsdaten noch einmal eingegeben werden, + bleibt die Situation schwer zu bereinigen, da es nötig + ist, die gesamte Vinum-Partition um mindestens + 4 KB nach hinten zu verschieben, damit Bootstrap + und Vinum-Kopf nicht mehr kollidieren.</para> + </sect3> + </sect2> + </sect1> +</chapter> |