Raid mit mehr als 2 Terabyte

[marcdevil]

Mahlzeit,

ich plane eine Aufrüstung unseres Samba Fileservers.
Nun stoße ich bei meinen Recherchen auf die 2 Terabyte-Beschränkungen an diversen Stellen.
- Controller (nur neuere)
- Kernel (>2.6)
- Partitionstabelle
- grub (fällt bei mir flach, da System mit grub-mbr und /boot auf einem 18Gb Raid1 läuft)
- LVM
- Samba

Also ich habe hier einen alten Mylex eXtremeRAID 2000 SCSI Controller von 2001 und wollte noch einen neuen LSI Megaraid SCSI 320-2X holen, der kann 64bit LBA.
Am alten hängen 14 73Gb Platten und am neuen sollen nochmal 14 300Gb Platten ran (1 Fujitsu-Siemens Primepower, 2 Kabel, pro Kabel 7 Platten).
Den Kernel muss ich noch von 2.4.2? auf den aktuellsten 2.6er kompilieren, damit 64bit LBA unterstützt wird.
Wenn ich die >2TB Arrays partitionieren will muss ich GPT-Partitionen erzeugen, stimmt das?
Oder soll ich mehrere 2TB Arrays erzeugen und die dann mit LVM zusammenfassen?
Das LVM muss ich aber auch noch partitionieren, gell?
Bei Ext3 ist nach 8TB schluss, soll ich lieber auf XFS wechseln? Wir nutzen ACLs und Quota.
Haben Samba oder die WinXP-Clients ein Problem damit ein >2TB Share zu nutzen (z.B. bei der Kapaziätsanzeige)?

... Fragen über Fragen ;)

[marce]

Wenn ich die >2TB Arrays partitionieren will muss ich GPT-Partitionen erzeugen, stimmt das?
Unter Linux AFAIK ja.


Oder soll ich mehrere 2TB Arrays erzeugen und die dann mit LVM zusammenfassen?
Wenn das Deiner Anwendungsanforderung oder Philosophie entspricht - warum nicht?


Das LVM muss ich aber auch noch partitionieren, gell?
Ja.

Bei Ext3 ist nach 8TB schluss, soll ich lieber auf XFS wechseln? Wir nutzen ACLs und Quota.
Auch hier wieder eher eine Philosophie-Frage - man kann ja auch mehrere 8TB-Blöcke durch die Organisation entsprechend "zusammenfassen" - solnge kein Share bzw. Verzeichnis > 8TB sein muss ist man ja flexibel...


Haben Samba oder die WinXP-Clients ein Problem damit ein >2TB Share zu nutzen (z.B. bei der Kapaziätsanzeige)?
AFAIK ja.
edit: ... was die Kapazitätsanzeige angeht. Die Nutzung an sich ist problemlos, solange die Fehlerhafte Anzeige da nicht reinspielt (z.B Softwareinstallation auf das Share und der Installer meint, es wäre kein Speicher mehr frei)...


... Fragen über Fragen ;)
... und hoffentlich war das noch nicht zu früh am Morgen und ich habe keinen völligen Bockmist geschrieben :-)

[bla!zilla]

Wenn ich die >2TB Arrays partitionieren will muss ich GPT-Partitionen erzeugen, stimmt das?

Ja.



Oder soll ich mehrere 2TB Arrays erzeugen und die dann mit LVM zusammenfassen?

Würde ich nicht machen.



Das LVM muss ich aber auch noch partitionieren, gell?


Natürlich.



Bei Ext3 ist nach 8TB schluss, soll ich lieber auf XFS wechseln? Wir nutzen ACLs und Quota.

Ich würde mich eher Fragen: Brauche ich so große Volumes. Solche großen Volumes bringen immer die gleichen Probleme mit sich:

- Management
- Backup
- Dateisystemcheck im Fehlerfall

Ich würde viel eher kleinere Volumes bauen, und davon mehr.



Haben Samba oder die WinXP-Clients ein Problem damit ein >2TB Share zu nutzen (z.B. bei der Kapaziätsanzeige)?


Nicht das ich wüsste.

[marce]

Oder soll ich mehrere 2TB Arrays erzeugen und die dann mit LVM zusammenfassen?
Würde ich nicht machen.

... Brauche ich so große Volumes ... Ich würde viel eher kleinere Volumes bauen, und davon mehr.

Kurze Frage: widerspricht sich das nicht? Oder spielst Du im konkreten Fall auf den Vorschlag mit LVM an?

[bla!zilla]

Nein, tut es nicht. :) Ich will die vielen kleinen Volumes ja nicht zusammenfassen. Wenn ich z.B. für User- und Abteilungsdaten brauche, dann lege ich die nicht auf ein Volume, mit getrennten Verzeichnissen, sondern jeweils auf ein Volume.

[marce]

ok, alles klar... Dann habe ich richtig verstanden...

Ist ja auch sinnig, jedenfalls solange man kein Volume mit 8TB am Stück braucht - soll ja auch vorkommen :-)


edit: Zu dem Ja beim "Probleme beim Nutzen" von mir - das bezog sich nur auf die Anzeige des Verfügbaren Platzes und der Größenangabe - da bekommt man AFAIK falsche Werte zurück. Jedenfalls, als ich das letzte mal das Vergnügen im konkreten Fall hatte... Die Nutzung als Share ist völlig problemlos...

[bla!zilla]

Ich hätte weniger Sorgen wegen der Größenanzeigen, als vor einem Crash. Selbst mit Journaling-Dateisysteme kann das böse in die Hose gehen. So große Volumes sind mit den aktuellen Dateisystemen einfach nicht ordentlich handelbar. Evtl. ist ZFS da ein richtiger Ansatz, wobei ich da nicht weiß wie es sich bei solchen Volumegrößen verhält.

[marce]

Evtl. lohnt sich da dann auch, mal über verteilte Dateisystem nachzudenken? Die haben zwar für den Admin einen höheren Verwaltungsaufwand, bieten aber gegen solche Worst-Case-Szenarien manchmal eine bessere Absicherung...

Was anderes: schenkt es sich eigentlich was, ob ich ein fsck beim Booten über 8TB oder 4x2TB laufen lassen, was die Zeit angeht (wenn ich mal davon ausgehe, dass ich nicht gedreht habe, dass der Check nicht laufen soll und alle Shares gleich "alt" sind)?

[cane]

Bei solchen Datenmengen sollte man vielleicht alternativ darüber nachdenken die Storage in Form eines SAN, gerne per iSCSI angebunden, zu konsolidieren.

IMO interessante Hersteller sind neben den bekannten großen beispielsweise Lefthand oder Equalogic.

mfg
cane

[bla!zilla]

Alternativ auch DataCore mti SANmelody (*würg*), Windows Server 2003 Storage Server, Linux mit iSCSI Initiator oder ein beliebiges anderes Storagesystem, welches Speicher per iSCSI exportieren kann.

Fakt ist: Solche Speichermengen sind in einzelnen Servern keine Seltenheit mehr. Schaut euch mal den HP ProLiant DL320s an. Bis zu 10,5 TB mit SATA oder 4,2 TB mit SAS Platten. Oder die SUN X4500 (Thumper). Das Ding packt bis zu 48 SATA Platten.

Ich gehe stark davon aus, dass sich gerade im Entry-Level Bereich mehr und mehr hochkapazitive Server mit iSCSI durchsetzen werden. Im Midrange oder Highend ist das noch nix.

[marcdevil]

Danke für die Antworten.

Ich werde noch kein SAN einführen.
Erstmal wird die vorhandene Hardware ausgenutzt.
Der Controller ist übrigens ein Mylex eXtremeRAID 2000.
Wenn ich eh logische Laufwerke mit unter 2TB anlegen muss, dann kann ich auch bei dem Controller bleiben, obwohl seine Raid5 performance nicht gerade der Bringer ist, aber vielleicht ist der einfach nur falsch konfiguriert.

[echo]

Das LVM muss ich aber auch noch partitionieren, gell?


den vorrednern zu diesem punkt wiederspreche ich mal!

lvm benötigt keine partitionen, du kannst ein lvm auf zb /dev/sda (ohne partitionsnummer) anlegen.
obs sinnvoll ist ne andere sache...

hier haste also 4 möglichkeinten
- so genante superdisk ohne partitionen
- partitionstabellen
- LVM
- partitionstabellen in denen ein LVM steckt

[echo]

Ich hätte weniger Sorgen wegen der Größenanzeigen, als vor einem Crash. Selbst mit Journaling-Dateisysteme kann das böse in die Hose gehen. So große Volumes sind mit den aktuellen Dateisystemen einfach nicht ordentlich handelbar.


könntest du deine bedenken etwas ausführen? ein check mit jornal sollte hier doch auch nicht all zu lange dauern...
XFS zb ist doch extra für solche riesen-datensysteme gebaut, oder irre ich mich hier?

[marce]

lvm benötigt keine partitionen, du kannst ein lvm auf zb /dev/sda (ohne partitionsnummer) anlegen.
obs sinnvoll ist ne andere sache...
Meinst Du:

LVM anlegen, darin dann Parititionen oder meinst Du Paritionen anlegen und über die ein LVM machen?

[echo]

Meinst Du:

LVM anlegen, darin dann Parititionen oder meinst Du Paritionen anlegen und über die ein LVM machen?

soweit ich weiß, lässt sich innerhalb eines LV keine partition anlegen, da weigern sich die tools. mag sein, dass man das dann doch hinbekommt, aber ich hatte da kein glück. wäre auch nicht sinnvoll oder?

mein vorschlag du lägst mindestens eine partition an und legst dort die LVM an.
vielleicht wären aber in deinem umfeld mehrere partitionen sinnvoller, wird zb heufig von IBM empfohlen, auf deren schulungen.

LVM ohne partitionen bringen keinen vorteil und verwirren einige admins, so meine erfahrung.

[bla!zilla]

Das LV wird direkt mit einem Dateisystem versehen, korrekt. Das ist quasi die "Partition".

Erfahrungsgemäß funktioniert Journaling, trotzdem kann es bei großes Volumes immer noch zu aufwendigen Checks kommen. Ich habe da in der Vergangenheit ein paar Mal schlechte Erfahrungen gemacht, wo fsck nicht weiterkam.

[echo]

Erfahrungsgemäß funktioniert Journaling, trotzdem kann es bei großes Volumes immer noch zu aufwendigen Checks kommen. Ich habe da in der Vergangenheit ein paar Mal schlechte Erfahrungen gemacht, wo fsck nicht weiterkam.

welches dateisystem war das?

unter HP-UX haben wir da keine probleme, wobei das filesystem auch aus dem san bezogen wird...

[bla!zilla]

ext3 und ReiserFS. MIt VxFS oder XFS hatte ich die Probleme nicht.