Stripe mit RAID, LVM oder BTRFS?

[tecneeq]

Ich habe zwei Server. Die Dateisysteme werden via DRBD synchron gehalten. Also braucht es keinen Mirror auf den lokalen Platten der Server.

Trotzdem hat jeder Server zwei Platten. Da bietet sich ja Striping an für ein bissel mehr Speed. Die Frage ist nur:

- Stripe mit RAID, dann ext4 drauf

- Stripe mit LVM, dann ext4 drauf

- Stripe mit BTRFS

Für Stripe mit RAID spricht ja eigentlich recht wenig.

Welche Option würdet ihr wählen, und warum? Ich tendiere ja zu Stripe mit LVM, weil man da die Dateisysteme so schön einfach vergrössern, verkleinern und auf andere Platten verschieben kann. Die Snapshot-Funktion ist auch nützlich.

Mit BTRFS habe ich keine Erfahrung, aber soll ja auch möglich sein damit zu Stripen und Snapshots sollen auch möglich sein. Auch scheint BTRFS schon API-Stable zu sein (ist aber eh keine Mission-Critical Aufgabe).

[bigvic]

Auch mit deinem LVM machst du eine Art RAID 1 (oder Mirror je nachdem wie das dein LVM nennt).

Kannst ja mal ein Performancetest machen, ob dein (vermutlich onboard-?) raid controller oder der LVM besser performed.

Btrfs kenn ich nicht, aber zfs und das ist akzeptabel vom speed bzw. die Zeiten, dass z.B. Oracle abgeraten hat es zu nutzen sind vorbei

Edit: Sorry, ich hab gerade nochmal gelesen und erst jetzt gesehen, dass du ein RAID 0 machen willst - aber ändert an der Aussage letztlich nichts.

Bearbeitet 5. Mai 2011 von bigvic

[bigvic]

Hier noch ein Link mit der Diskussion:

RAID Verse LVM

Bearbeitet 5. Mai 2011 von bigvic

[tecneeq]

Erstmal danke für die Antwort.

Kannst ja mal ein Performancetest machen, ob dein (vermutlich onboard-?) raid controller oder der LVM besser performed.

Also wenn dann würde ich RAID Stripe Software machen. Wenn der Controller stirbt krieg ich eventuell keinen Ersatz. Aber Snapshotting will ich eh, also bietet sich Stripe mit LVM oder BTRFS auch an. Sozusagen ein Layer weniger auf der Hardware:

Platte => Stripe RAID => LVM => ext4 => Daten

Platte => Stripe LVM => ext4 => Daten

Platte => Stripe BTRFS => Daten

Ja, man müsste die Performance aller Lösungen vergleichen. Ich hatte den Thread in der Hoffnung gestartet das sich jemand meldet der das Problem schon hatte und eventuell sogar Messwerte oder konkrete Erfahrung hat.

Btrfs kenn ich nicht, aber zfs und das ist akzeptabel vom speed bzw. die Zeiten, dass z.B. Oracle abgeraten hat es zu nutzen sind vorbei

Was sind deine Messwerte zu ZFS? Was ist für dich akzeptabel? Was sind die Vorteile von ZFS, was die Nachteile? Wird ZFSs Lizenzierung sich mit Oracles Wünschen mal ändern?

Zumindest die Lizenz ist bei BTRFS/LVM/SoftRAID garantiert kein Problem.

[bigvic]

Ich hab keine konkreten Messwerte für zfs - wir hatten vor ca einem Jahr mal zfs vs. ufs/svm mit verschiedenen filesystem paramter/io size/io verhalten (random read/write ...)/ etc. mit Solaris geteset auf Durchsatz/IOPS/Antwortzeiten/... und Ergebnis war, dass zfs ca 5-10% "schneller" war und für der Speed für unser SAP eben akzeptabel war. Ich weiss, dass es sehr schwammig ist - aber mehr kann ich dir nicht sagen, da ich die Daten nicht (mehr) habe. Ausserdem bringt es dich ja auch nicht wirklich weiter für BTRFS. Und je spezieller es ist, desto mehr sollte man eh die Gesamtlösung testen.

Aber ehrlichgesagt glaube ich nicht, dass bei deinem Konstrukt mit DRBD die Wahl zwischen BTRFS oder LVM der Perfomance Bottleneck sein wird - wohl eher der network interconnect zwischen den DBs (zumindest, wenn das TCP/IP ist?!), oder nicht?

Edit: Wobei wenn nur 2 Platten hast und dein interconnect dediziert gigabit ist, dann könnten die platten evtl. noch der bottleneck sein...

Bearbeitet 5. Mai 2011 von bigvic

[tecneeq]

Beim Netzwerk bin ich da noch nicht so sicher. Wenn ich zwei Festplatten stripe sollte da schon deutlich über 100 MB/s herauskommen. Eventuell sogar über 200 MB/s. Da kann 1Gbit/s schon eng werden. Zumindest ist die Strecke dediziert. Eventuell sogar 2 Gbit NICs mit Link Aggregation. Kommt drauf an was 10 Gbit/s über Kupfer kostet und wie der Auftraggeber das sieht .

Ist eben alles noch in der Planung.