Re: Software Raid mit SCSI u160 unter FreeBSD?

On 07/21/04 17:35:59 +0200 Tobias Kilb wrote:
>> vinum oder ccd arbeiten innerhalb von Partitionen und somit
>> nicht zwangslaeufig auf den kompletten Platten. Du kannst
>> also problemlos eine regulaere "/"- und Swap-Partitionen
>> haben und den Rest per ccd oder vinum verwalten.
>
> Das interpretiere ich jetzt mal so, dass ich also erstmal ein Frisches
> BSD auf einer Platte (die erste) installiere, und danach mit Vinum meine
> /usr über beide Platten strecke.

zum Beispiel, ja.
Im Falle von vinum kennzeichnet man auf allen Platten
bzw. Slices (auf denen vinum Speicherplatz verwalten soll)
mindestens eine Partition im Disklabel als "vinum".

> Wohlgemerkt ich hab mich jetzt für Striping entschieden.

Warum? Hast Du besonders hohe Anforderungen an die Schreib-
performance? Mir persoenlich sind pure Stripes einfach zu
gefaehrlich. (Faellt eine Platte aus, sind die Daten saemt-
lich verloren.)

> Ist es dann auch möglich, nachträglich noch eine Platte
> ins Raid aufzunehmen?

Vinum (wenn man bei der Ersteinrichtung beachtet, was man
zukuenftig noch aendern moechte) ist recht flexibel.
Wichtig beim Erstkontakt mit vinum ist es, die relevanten
Informationen zu verstehen, bevor man wichtige Daten auf
die Volumes wirft.

Ich bin mir gerade allerdings selbst nicht sicher, ob man
ein Stripe-Set nachtraeglich vergroessern kann. Ich meine
aber nein, und zwar auf Basis folgender Argumentation:

Ausgangslage:

Ein "volume" ist das Objekt, auf dem schliesslich das Datei-
system erzeugt wird. Ein volume kann ein oder mehrere plexes
enthalten. *Jedes* plex repraesentiert den vollstaendigen
Inhalt bzw. Adressraum eines volumes. Die plexes selbst be-
stimmen die Art und Weise der Datenorganisation (concat,
stripe, raid5); also nach welchen Verfahren die Daten auf
die subdisks des jeweiligen plexes verteilt werden.
Ueber die subdisks wird schlussendlich die Allozierung der
Plattenbloecke vorgenommen.

Ein einfaches striped volume sieht unter vinum so aus:

    volume
      |
      +-----> plex (organization stripe)
                |
                +---> subdisk
                | +-----> Blockbereich auf einem drive
                +---> subdisk
                          +-----> Blockbereich auf einem drive

Ein einfaches mirrored voluem sieht so aus:

    volume
      |
      +-----> plex (organization concat)
      | |
      | +----> subdisk
      | +------> Blockbereich auf einem drive
      +-----> plex (organization concat)
                |
                +-----> subdisk
                           +------> Blockbereich auf einem drive

Zur Zeit (ich habs dann doch noch im Handbuch nachgelesen ;-))
kann man nur concat plexes nachtraeglich um neue subdisks erwei-
tern. Und genau das muss man tun, um ein Volume zu vergroessern.
Bei einem mirrored volume kann man jedes der plexes ueber zu-
saetzliche subdisks dieselbe Menge zusaetzlichen Platzes hinzu-
fuegen. Anschliessend kann man mit growfs das Filesystem des
Volumes erweitern. (Das hab ich auch schon einige Mal erfolg-
reich getan; Volume/Speicher-Management ist *mein* Hauptanwen-
dungsgebiet fuer vinum.)

Theoretisch muesste man stripes erweitern koennen; aber um das
"managebar" zu halten, braeuchte man (meiner unmassgeblichen
Einschaetzung nach) wohl eine weitere Indirektionsebene; damit
"plexes" nicht nur direkte Block-Allokationen (also subdisks),
sondern auch Block-Organisatoren (also "[sub-]plexes") enthalten
koennen.
Etwa in der Art:

    volume
      |
      +-----> plex (organization stripe)
                |
                +---> (sub-)plex (organization concat)
                | +---> subdisk
                | +--> Blockbereich auf einem drive
                | +---> subdisk
                | +--> Blockbereich auf einem drive
                |
                +---> (sub-)plex (organization concat)
                        +---> subdisk
                                +--> Blockbereich auf einem drive
                        +---> subdisk
                                +--> Blockbereich auf einem drive

>> > 3 SCSI u160 Platten gehen schon ganz schön ins Geld :-!
>>
>> Nicht notwendig.
>>
>> 36 GB/10kUPM sind bei ca 100,- EUR angekommen, wenn ich mich
>> recht an meine letzte Preisliste erinnere.
>
> Etwas mehr sind es noch,

Sorry, ... ich zitierte Netto-Einkaufspreise fuer kleine Haendler.
Fuer Endverbraucher landet man bei Brutto-Preisen von um die 150,-
Euro.

> aber ich hab hier jetzt 2x18GB u160 10k! Die
> müssen erstmal langen.

Die haben bei mir im Arbeitsplatz (allerdings nur 7200 UPM) jahre-
lang gereicht.

-Andreas

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Wed 21 Jul 2004 - 20:52:02 CEST