doc/de_DE.ISO8859-1/books/handbook/vinum/chapter.sgml
2012-09-14 17:47:48 +00:00

1440 lines
58 KiB
XML

<?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.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;&nbsp;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;&nbsp;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&nbsp;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&nbsp;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&nbsp;kB transferieren wollen. Aktuelle
hochperformante Platten können die Köpfe im Durchschnitt
in 3,5&nbsp;ms positionieren und drehen sich mit maximal
15.000&nbsp;U/min. Daher beträgt die durchschnittliche
Rotationslatenz (eine halbe Umdrehung) 2&nbsp;ms.
Bei einer Transferrate von 70&nbsp;MB/s dauert die eigentliche
Übertragung von 10&nbsp;kB etwa 150&nbsp;&mu;s, fast
nichts im Vergleich zur Positionierungszeit. In einem solchen
Fall beträgt die effektive Transferrate nur etwas mehr
als 1&nbsp;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&nbsp;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 -&gt; <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&nbsp;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&nbsp;KB frei und schreibt dahinter seine
Kopfinformationen. Allerdings benötigen Stufe-Eins-
und -Zwei-Bootstraps plus dem dazwischen eingebetteten
<foreignphrase>bsdlabel</foreignphrase> momentan 8&nbsp;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&nbsp;KB nach hinten zu verschieben, damit Bootstrap
und Vinum-Kopf nicht mehr kollidieren.</para>
</sect3>
</sect2>
</sect1>
</chapter>