Unterschied Stripe Size (Raidcontroller) und Blockgröße (Festplatte)

Hallo Wuhjaa,

ich bin der Meinung dass es dort mehrere Ansätze gibt, den Du aber auch irgendwie allen nach gehen solltest.

Du entscheidest Dich für ein Raid Level in Punkto benötigter Geschwindigkeit, gewünschter Größe, Datenredundanz und Sicherheit.
D.h. für mich Du wählst einen Raid Level aus schließt die Festplatten am Raid Controller an und stellst dann am im Bios des Raid Controllers für das von Dir gewählte Stripping die optimal zum Raid Level passende Stripesize ein. Raid bezogen!

Dann setzt Du das von Dir gewählte Server OS auf und stellst für das Server OS die dafür optimale
Blockgröße ein. OS bezogen!

Hohe Datendichte da freut sich der Chef, aber die Benutzer meckern. = Mehr plattenplatz
Niedrige Datendichte da meckert der Chef und die Benutzer freuen sich. = Weniger Plattenplatz

Bleibt nur noch die Sache mit dem Backup, nicht das Du alles für jedermann (Chef & Benutzer)
gut gelöst hast, die Datendichte aber so groß geworden ist und jemand Nachts das Band für das Backup wechseln muss!!!!!!

Und mehr Performance kann man auch leicht für Geld haben ohne an den Festplatten und dem OS was ein zu stellen, einfach mehr RAM in die Kiste, kommt natürlich auf das Mainboard und das OS an, aber gibt dem ganzen einen ordentlichen Schub, es sei denn Du hast echte Performance Einbußen wenn Daten in die Datenbank
und auf die Festplatte geschrieben werden. Da hilft dann auch mehr RAM nicht.

Hallo,

also Du sprichst an sich von Dateisystem-Clustern, was einer Recherche nach "Blockgrößen" wohl im Wege steht. Die Blockgröße ist von der Festplatte vorgegeben und nur für den Raid-Controller relevant. Bei dem RAID-Verbund aus Sicht des OS handelt es sich ja um ein emuliertes Volume, welches dann mit einer bestimmten Cluster-Größe formatiert wird.
Die Stripe-Größe bestimmt nur die Aufteilung der Daten in der RAID0-Ebene.
Bei 4/64 hast Du im Ergebnis physisch 16 Cluster auf einem Stripe (ein "echter" RAID-Controller vorausgesetzt, der diesbezüglich das Alignment gewährleistet).

Über den Sinn verschiedener Konfigurationen lässt sich streiten. Ich sehe zwei Aspekte:
- Bzgl. der Cluster-Größe sind die Anforderungen der Anwendung für die Performance absolut maßgeblich. Ein Abweichen wegen der RAID-Stripe-Größe sollte gut begründet sein, oder außer Acht gelassen werden.
- Vom Standpunkt der Datenwiederherstellung würde ich auf 64k-Stripes maximal 32k, eher 16k Cluster formatieren und bei größeren Clustern auch die Stripe-Größe entsprechend erhöhen. Wenn gleichgroße oder größere Cluster verwendet werden, kann das die Datenrettung im Fall eines Misalignments i.V.m. mit einem Dateisystemfehler sehr erschweren, weil keine ganzen Cluster mehr auf dem Stripe vorhanden sind.

Mit besonderen Vorteilen von identischer Cluster-Größe habe ich mich insofern noch kaum beschäftigt. Vielleicht erläuterst Du deinen Gedankengang etwas. Natürlich kann der Stripe dann nicht mehr fragmentieren und es ergibt sich ein Alignment der Dateien, die kleiner als der Cluster/Stripe sind, auf dem RAID. Ich denke, das würde für diese Dateien die RAID-spezifischen Vorteile von der Leserate auf die Zugriffszeiten verlagern. Bei 32/64 könnte eine Datei größer 32k, kleiner 64k auf zwei halben Stripes verteilt liegen. D.h. RAID0 würde das Lesen beschleunigen. Bei 64/64 würde sie zwingend auf einem Cluster/Stripe liegen, d.h. RAID0 käme zum Tragen, wenn sie zusammen mit anderen Dateien sequenziell gelesen wird.

Grüße
Richard

Moint,

Du soltest einfach mal google oder eine andere Suchmaschine Deiner Wahl bemühen und Dich in die Grundlagen einlesen. Hie rnur ein Kurzüberblick.

• Daten werden physikalisch auf Festplatten in "Blöcken", den sogenanten Sektoren geschrieben. Dies können unterschiedlich sein, und waren bis vor kurzem 512 Byte groß. Die Festplattenhersteller sind in letzter Zeit dazu übergegangen, 4k-Sektoren zu verwenden, um den "verschnitt" zu optimieren.

• Betriebsysteme verwenden für Filesysteme auch Blöcke verschiedener Größe (z.B. Cluster genannt), die meist ein ganzhahliges vielfaches der Sektorgröße ist. Je größer die Cluster sijnd, desto weniger verwaltungsaufwand hat man, aber dafür auch um so mehr "verschnitt" bei kleinen Dateien.

• RAID-Systeme schreiben auch Daten auf die Festplatten in Blöcken. um die Verwaltung und Performance zu verbessern, fassen sie auch dazu die Sektoren zu größeren Blöcken zusammen, den sogenannten chunks. Die chunk oder Stripe size gibt an, wie große ein einzelner Block ist, bevor auf die nächste Platte geschrieben wird. Da landen bei RAID0 z.B. die ersten 64k auf der ersten Platte. die nächsten auf der 2. Platte, die 3. 64k auf der 3. falls vorhanden oder wieder auf der ersten, wenn man nur zwei Platten hat.

Prinzipiell kann man zwar die Größen für Sektoren, Cluster und chunks unabhängig voneinander wählen und es funktioniert trotzdem alles, aber eine ungeschickte Wahl kann die Performance stark beeinträchtigen.

Um, nun für Dein Problem eine Lösung zu finden, müßte man erst protokollieren, wie die datenzugriffe deines SQL-Servers aussehen, um dann die cluster oder stripe-size darauf zu optimieren.

Bei RAID10 und kleinen Datenbröckchen in SQL (Adressverwaltung, Warenwirtschaft & Co.), wo keine blobs drin sind, wäre eine stripe size von <= 16k nicht verkehrt.

das beste wäre aber, daß Du für Deine Anwendung einfach einen Benchmark machst, weil jede Anwendung sich anders verhält.


lks

PS: Für Multi-user-DB-Anwendungen sind SSDs mit vielen IOPS meist sehr gut geeignet, weil die mehr bringen als ein RAID0 mit vielen Platten. HDDs haben meist IOPS von einigen hundert bis wenigen tausend. Eine SSD bringt dann meist schon die 10-fache Leistung, im RAID sogar deutlich mehr.

PPS: Man sollte natürlich die eigenheiten von SSDs kennen und bein Backup- und/oder HA-Konzept berücksichtigen.

In Bezug auf die Festplatten. Ein RAID-Controller ist ein eigener Unsicherheitsfaktor. Es ist denkbar, dass bei einem Rebuild der Controller kein Alignment von Clustern und Stripes mehr hinbekommt und das Dateisystem beschädigt wird. Bei <1 ganzen Clustern pro Stripe wird eine Datenrettung abhängig von der Fragmentierung schwer zu automatisieren und damit mehrfach so teuer wie nötig.


Also den von LKS angesprochenen Management-Overhead würde ich vernachlässigen. Die Kapazitäten sind i.d.R. für aktuelle Systeme einfach nicht groß genug, um durch große Cluster eine geringe Cluster-Anzahl sinnvollerweise anstreben zu müssen.

Das obige Beispiel gilt für Schreibzugriffe analog. Bei einer Datengröße von 32-64k ist verteiltes physisches Schreiben/Lesen der Datei im RAID0 ja nur denkbar, wenn die Clustergröße 32k oder kleiner ist und die Datei zufällig auf zwei Stripes verteilt ist. Das ist eine statistische Größe, denn die Daten können genauso innerhalb des 64k-Stripes Platz finden. Um den Effekt zu erzwingen, müssten auch die Stripes kleiner sein. Umgekehrt bei 64/64 belegen sie immer einen Cluster = Stipe, und damit kann ihr _vereinzeltes_ Schreiben/Lesen nicht RAID-spezifisch beschleunigt werden.

Eine Beschleunigung wird sich damit erst bei der sequenziellen Anforderung einstellen, und gerade in Bezug auf die Zugriffszeiten nur dann, wenn die Daten aus Sicht der Anwendung fragmentiert sind, weil dann die jeweils nicht belastete RAID-Platte vorpositionert wird.
Grundsätzlich wird aber eine Anwendung immer versuchen, die Daten sequenziell zu schreiben, über Cluster und Stripes hinweg. Im Idealfall bleibt es immer ein Zugiff. Welche Cluster-Größe gegenüber der möglichen Blockade einer Sequenz durch Fragmentierung geboten ist, musst Du der Dokumentation des jeweiligen Servers entnehmen. MS SQL wird wohl auf NTFS bestmöglich arbeiten, aber wie es das macht, und welche ideale Cluster-Größe daraus resultiert, weiß nur der Hersteller. Cluster können ja dateisystemunabhängig vorbelegt werden, womit eine dies vorweg nehmende, überhöhte Cluster-Größe unnötig wäre. Unterm Strich wäre sie also hinsichtlich kleinerer Datenpakete, der reinen Transferraten und der Datenrettung nachteilig.