Um die in den vorigen Abschnitte besprochenen Probleme zu lösen, verwendet Vinum eine vierstufige Objekthierarchie:
Das auffälligste Objekt ist die virtuelle Platte, die Volume genannt wird. Volumes haben im Wesentlichen die gleichen Eigenschaften wie ein UNIX®-Laufwerk, obwohl es ein paar kleine Unterschiede gibt. So existieren für Volumes beispielsweise keine Größenbeschränkungen.
Volumes bestehen aus einem oder mehreren Plexus, von denen jeder den gesamten Adressraum eines Datenträgers repräsentiert. Diese Hierarchieebene ist für die benötigte Redundanz der Daten erforderlich. Stellen Sie sich die Plexus als eigenständige Platten in einem gespiegelten Array vor, von denen jede die gleichen Daten enthält.
Da Vinum im UNIX-Plattenspeicher-Framework arbeitet, wäre es möglich, als Grundbaustein für Multiplatten-Plexus UNIX-Partitionen zu verwenden. In der Praxis ist dieser Ansatz aber zu unflexibel, da UNIX-Platten nur eine begrenzte Anzahl von Partitionen haben können. Daher unterteilt Vinum stattdessen eine einzige UNIX-Partition (die Platte) in zusammenhängende Bereiche, die als Subdisks bezeichnet werden und als Grundbausteine für einen Plexus benutzt werden.
Subdisks befinden sich auf Vinum-Platten, eigentlich UNIX-Partitionen. Vinum-Platten können eine beliebige Anzahl von Subdisks haben und den gesamten Speicher der Platte mit Ausnahme eines kleinen Bereiches am Anfang der Platte (welcher zur Speicherung von Konfigurations- und Statusinformationen verwenden wird) verwenden.
Der folgende Abschnitt beschreibt, wie diese Objekte die von Vinum benötigten Funktionen zur Verfügung stellen.
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.
Vinum implementiert die Datenspiegelung, indem es ein Volume auf mehrere Plexus verteilt. Jeder Plexus ist dabei die Repräsentation der Daten eines Volumes. Ein Volume kann aus bis zu acht Plexus bestehen.
Obwohl ein Plexus die gesamten Daten eines Volumes repräsentiert, ist es möglich, dass Teile der Repräsentation physisch fehlen, entweder aufgrund des Designs (etwa durch nicht definierte Subdisks für Teile des Plexus) oder durch Zufall (als ein Ergebnis eines Plattenfehlers). Solange wenigstens ein Plexus die gesamten Daten für den kompletten Adressbereich des Volumes zur Verfügung stellen kann, ist das Volume voll funktionsfähig.
Sowohl Konkatenation als auch Striping werden von Vinum auf der Plexus-Ebene realisiert:
Ein konkatenierter Plexus benutzt abwechselnd den Adressraum jeder Subdisk.
Ein gestripter Plexus striped die Daten über jede Subdisk. Die Subdisks müssen alle die gleiche Größe haben, und es muss mindestens zwei Subdisks in Reihenfolge geben, um ihn von einem konkatenierten Plexus unterscheiden zu können.
Die Version von Vinum, welche von FreeBSD-9.1 bereitgestellt wird, implementiert zwei Arten von Plexus:
Konkatenierte Plexus sind die flexibelsten: Sie können aus einer beliebigen Anzahl von Subdisks unterschiedlicher Größe bestehen. Der Plexus kann erweitert werden, indem man zusätzliche Subdisks hinzufügt. Sie brauchen weniger CPU-Zeit als gestripte Plexus, obwohl der Unterschied des CPU-Overheads nicht messbar ist. Auf der anderen Seite sind sie aber sehr anfällig für das Entstehen von "hot spots", wobei eine Platte sehr aktiv ist, andere hingegen nahezu ungenutzt sind.
Der größte Vorteil eines gestripten Plexus (RAID-0) ist die Verringerung von "hot spots". Dies wird durch die Auswahl eines Stripes optimaler Größe (etwa 256 kB) erreicht, wodurch die Last gleichmäßig auf die Platten verteilt werden kann. Nachteile dieser Vorgehensweise sind ein (geringfügig) komplexerer Code sowie einige Restriktionen für die Subdisks: Diese müssen alle die gleiche Größe haben, und das Erweitern eines Plexus durch das Hinzufügen neuer Subdisks ist so kompliziert, dass es von Vinum derzeit nicht unterstützt wird. Vinum fordert noch eine weitere triviale Beschränkung: Ein gestripter Plexus muss aus mindestens zwei Subdisks bestehen, da er ansonsten nicht von einem konkatenierten Plexus unterscheidbar ist.
Tabelle 22-1 fasst die Vor- und Nachteile jedes Plexus-Aufbaus zusammen.
Tabelle 22-1. Vinum-Plexus - Aufbau
| Plexus-Typ | Minimum an Subdisks? | Kann Subdisks hinzufügen? | Müssen die gleiche Größe haben | Applikation |
|---|---|---|---|---|
| konkateniert | 1 | ja | nein | Großer Datenspeicher mit maximaler Platzierungsflexibilität und moderater Leistung |
| gestriped | 2 | nein | ja | Hohe Leistung in Kombination mit gleichzeitigem Zugriff |
| Zurück | Zum Anfang | Weiter |
| Datenintegrität | Nach oben | Einige Beispiele |
Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an
<de-bsd-questions@de.FreeBSD.org>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an <de-bsd-translators@de.FreeBSD.org>.