Welcher Partitionstyp & Dateisystem für 2,25 TB RAID5 Array?

H_M_Murdock

Urgestein
Thread Starter
Mitglied seit
29.10.2007
Beiträge
8.696
Ort
München
Ich werd jetzt dann nach Weihnachten endlich mein Fileserver-Projekt fertig stellen, d.h. die Platten einbauen und alles fertig einrichten.

Ich hab dann 4x die WD 750 GB RE2 in nem RAID 5 (Netto 2,25 TB).
Das ganze läuft dann unter Windows Server 2003.

Jetzt stellen sich mir natürlich noch ein paar Fragen die ich vorher klären möchte, ich werd allerdings bevor das ganze produktiv in Betrieb genommen wird auch noch ein wenig benchen um möglichst das Optimum heraus zu holen, allerdings sind Benchmarks leider oft nicht so praxisnah wie man das gern hätte.

Die erste Frage ist die nach dem Partitionstyp.
GPT oder Dynamischer Datenträger? MBR kommt bei > 2TB natürlich nicht in Frage.

Die nächste Frage ist die nach der Clustergröße des Dateisystems.
Standardmässig bei NTFS soweit ich weiss 4 KiB, bitte berichtigt mich wenn ich falsch liege, machbar sind bis 64 KB, allerdings steht noch nicht zu 100% fest was an Daten drauf kommt.
In erster Linie wohl Files > 500 MB.
Ist es sinnvoll den Verwaltungsaufwand fürs Filesystem zu verringern indem man die Clustergröße auf wenigstens 8 KiB anhebt oder kann man mit den 4 KB leben und hat in der Praxis ohnehin keine großartigen negativen Nachteile?

Die Dritte Frage wäre die zur Stripesize, der 3Ware Controller lässt 8 KB, 32 KB und 64 KB zu.
Ich hab schon mit 4x 80GB Seagate HDDs gebencht (allerdings nur lesend) und dabei mit der Stripesize experimentiert.
Dabei habe ich festgestellt, dass die kleinste Stripesize die größte Geschwindigkeit brachte.
Beim Schreiben nehm ich an, dass es wohl eher langsamer wird weil die XOR Unit mehr zu tun hat oder lieg ich da falsch?
Hab dazu schon die unterschiedlichsten Empfehlungen gehört und alle waren völlig widersprüchlich.
Gerade dazu werd ich auf jeden Fall ein paar Benchmarks machen (Read & Write), wüsst aber trotzdem gern eure Erfahrungswerte dazu.

Lange Rede kurzer Sinn, ich will natürlich das Optimum aus der Kiste rauskitzeln, mit so großen Dateisystemen hatte ich bisher nichts zu tun da sich meine bisherigen RAID Erfahrungen alle auf wesentlich kleinere (Platzmässig) Arrays beschränken und meine größte Platte die ich derzeit verwende 250 GB hat.
Ich glaube keinesfalls dass NTFS "überfordert" ist o.ä., aber die Geschichte muss dann ein paar Jahre so gut wie möglich so laufen und ich kann dann nicht einfach mal eben alles auslagern und neu formatieren weil mir einfällt dass das was ich gemacht hab doch blöd ist.

Edit:
Das Betriebssystem kommt natürlich seperat auf eine 74er WD Raptor, also nicht mit aufs RAID 5.
Sollte ich noch zusätzlich (das ist dann aber von den Zugriffszahlen in sehr kleinem Stil, also eher als Testsystem zu sehen) meinen Webserver mit MySQL mit auf den Server packen werden das Webrootverzeichnis und die MySQL Datenbank auch mit auf der Raptor landen.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Was soll auf dem Fileserver denn alles laufen?
Wenn es wirklich nur darum geht Dateien im Netz bereitzustellen, dann würde ich eine Linux-Distribution nehmen und dann xfs als Dateisystem nutzen.
 
Beim Schreiben nehm ich an, dass es wohl eher langsamer wird weil die XOR Unit mehr zu tun hat oder lieg ich da falsch?

Da liegst du falsch, da jedes einzelne Bit "codiert" werden muss, sprich zu jeder 0, 0, 0 muss der Controller für die vierte Platte eine 1 berechnen, als Beispiel. Ob der nun 2x 32kb oder 1x 64kb "berechnet", ist egal.
 
Ich hatte vor kurzem eine ähnliche Fragestellung, als ich mein RAID5 array von 4x500 auf 5x500 erweitern wollte.

Als Partitionstyp würde ich GPT wählen - mei nSystem rann eigentlich sehr lange ultra-stabil und ich dachte mit einem externen Controller kann ich meinen Platzbedarf schön flexibel erweitern. Das Raid5 array ließ sich auch ohne weiteres erweitern, jedoch nicht die Partition :(

Daher mache dir lieber heute schon Gedanken, wie du verfahren willst falls dein array voll ist!

Option 1: alle Daten woanders hin speichern und array neu machen

Option 2: Controller mit min. 8 ports: falls mein array asu 5x500GB voll ist, werde ich mir 3x1TB Platten kaufen und an die verbleibenden Ports des Controllers hängen -> Daten kopieren -> und dann eine weitere 1TB Platte einbauen + gegebenenfalls eine weitere, bis ich wieder an dem Punkt mit 5 Platten angekommen bin und dann 2TB Platten benötige :fresse:

Option 3: Mainboard mit mehreren Slots für Controller, z.B. 2x PCIe + IGP/PCI Graka. Falls das Array voll ist: neuen Controller kaufen + neue Platten und Daten rüberziehen

Gruss
Alex
 
Yep, über den potentiellen Upgradepath sollte man sich vorher Gedanken machen...

Als Partitiontyp nimmst du EFI/GPT & das Dateisystem ist eh von Windows vorgegeben (NTFS) --> da gibts keine Alternative zu.
:)
 
Aehm warum der Stress mit Neuerstellung des Arrays bei hinzufuegen einer Platte?

Es ist richtig, dass sich die Partition nicht mit Bordmitteln erweitern laesst, jedoch kommt mir folgendes in den Sinn:

Habt ihr etwa eure Arrays als eine einzelne Partition definiert? Ich finde sowas sehr ineffektiv...

Unter dieser praemisse kann man naemlich den hinzugekommenen Platz der hinzugefuegten Platte einfach als neue Partition definieren und fertig.

Alternativ waere evtl. eine erweiterung der Partition mit Partition Magic o.ae. moeglich. Dafuer moechte ich jedoch nicht meine Hand ins Feuer legen.



greetz
 
Habt ihr etwa eure Arrays als eine einzelne Partition definiert? Ich finde sowas sehr ineffektiv...

Bin ich komplett konträrer Meinung, sobald ich anfange ein großes Array mittels mehrer Partitionen zu zerstückeln, muß ich mir auch überlegen was ich wohin pack und, wie groß ich die einzelnen Partitione gestalte (in Abhängigkeit vom potentiellen Wachstum des Inhalts über Zeitraum xy) --> wesentlich mehr Aufwand/Arbeit für imho nichts...
(letztendlich zerstückel ich damit nur meinen freien Platz)

Bei einem großen Array hab ich den kompletten Platzt am Stück verfügbar und kann diesen fexibel nach Bedarf nutzen...

Und wieso soll man Partitionen nicht mit "Boardmitteln" erweitern können?
Jedes anständige OS/Filesystem beherscht das (außer Windows)
scnr!
;)
 
Zuletzt bearbeitet:
Richtig, ich will mein Array auch am Stück nutzen.
Auf das Thema mit der Arrayerweiterung wo die Partition ihre Größe behalten hat beim Promise Controller bin ich auch schon gestoßen.
Werd das mal testen indem ich bevor das ganze in Produktivbetrieb geht ein Array mit nur 3 Platten bau und das dann probehalber auf 4 erweiter dann seh ich ja was raus kommt.

Betriebssystemwahl ist getroffen da geht nichts mehr zu rütteln, und nein das System soll nicht als reiner Datenserver dienen.

Die Frage ist halt welche Blockgröße fürs RAID und welche Clustergröße fürs Filesystem sinnvoll sind.
Und hab ich nen Vorteil davon das ganze als dynamischen Datenträger zu erstellen oder "langt" ne normale GPT Partition.
 
OK daraus ist für mich kein wirklicher Vorteil ersichtlich, aber auch kein Nachteil.
Werd ich wohl einfach nen simplen GPT Datenträger machen.

Edit:
Hab grad bei Technet in nem älteren Artikel zu NTFS nen Tip gefunden wie man die Performance von NTFS erhöhen kann:
Another method to enhance NTFS performance is to disable unnecessary default NTFS behaviors. By modifying the Registry, you can stop NTFS from automatically updating the last access time and date stamp on directories as NTFS traverses its B-tree directory structure. When you disable this behavior, you can reduce NTFS's operational overhead without significantly impairing functionality. In the HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Control \FileSystem Registry key, change the NtfsDisableLastAccessUpdate value of type REG_DWORD from the default value 0 (enabled) to 1 (disabled). This Registry value doesn't exist by default, so you need to enter it manually.
Quelle: http://www.microsoft.com/technet/archive/winntas/tips/winntmag/optntfs.mspx?mfr=true

Jetzt stellt sich mir eigentlich nur noch die Frage der idealen Stripe Size, aber die ist angeblich mit synthetischen Benchmarks nicht wirklich mit einem vernünftigen Bezug auf die Real-Life Performance festzustellen.

Grad noch gefunden, die Aussage von 3Ware zur StripeSize:
http://www.3ware.com/KB/article.aspx?id=11133

EDIT:
So ich hab jetzt gar nicht mehr allzu groß rum gespielt damit.
Hab jetzt das komplette RAID zu nem GPT Datenträger gemacht und eine einzige Partition drauf gelegt mit der Standard NTFS Clustergröße.
Die Stripe Size beträgt 64 KB (also die Standardgröße).

Es war relativ schwer einen Benchmark zu finden der vernünftige Ergebnisse liefert, HD Tach kann man hier absolut vergessen und h2benchw hat mir zu lang gedauert, bin dann auf den ATTO Disk Benchmark gestoßen, der bencht aufm Dateisystem sowohl lesend als auch schreibend und kann auch Software-RAIDs benchen.
Ich komm mit meinen 4x 750er RE2 im RAID5 bei 64 KB Stripe Size auf ca. 350 bis über 390 MB/s beim lesen, zum schreiben kann ich noch nichts sagen weil das RAID zu der Zeit nicht initialisiert war, das wird heut Abend dann nochmal gebencht.
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh