RAID Guide

Status
Für weitere Antworten geschlossen.
Fileserver, das ist das Stichwort für Raid1, Raid5 oder Kombinationen mit 0 (10, 01, 50). Jetzt kommt es darauf an, wie wichtig dir noch ein Stückchen Restperformance, sowie die Kapazitätseffizienz ist. Hängt natürlich alles auch ab vom geplanten Controller (onboard: Raid5 lahm).

dann werde ich wirklich noch mit dem einsatz von raid warten, bis ich mir einen controller zulege
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hallo Leute,

ich plane gerade meinen Fileserver aufzurüsten.
Momentan sind drin:
1x 3Ware 9650SE-8LPML
2x Seagate ST380815AS RAID (Betriebssystem, openSUSE 11.1 x64)
3x Western Digital WD1000FYPS-01ZKB0 (1TB) RAID5 (Daten)

neu hinzukommen:
3x Western Digital WD1002FBYS (1TB)

Zum einen geht mir der Speicherplatz aus, zum anderen ist die Performance mies. Auf dem RAID5 liegen noch VMs (VMware Server 2.x) und die sind echt lahm.
Auf jeden Fall sollen die Platten in ein großes Array (Mix von Platten ist zwar nicht zu empfehlen, sollte aber gehen).
Nun stellt sich die Frage nach dem Raid Level... RAID5 ist bei der Anzahl von Platten nicht mehr zu empfehlen... RAID6 ? Jo ginge, aber Performance ist da auch nicht so toll.
RAID10? Wäre denke ich mal richtig schnell. Ich hätte da dann 3TB Nutzkapazität. Ziemlich großer Verschnitt...
Da fällt mir jetzt noch RAID50 ein. Zwar habe ich das bisher nie verwendet, aber es klingt ja recht gut. Die Schreibperformance sollte auf jeden Fall höher als bei RAID5 oder RAID6 liegen.2x RAID5 striped... sprich (3x1TB -1) + (3x1TB -1)... Nutzkapazität sollte ja dann 4TB sein oder?
Ich weiß gerade nicht wie ich mich entscheiden soll ;)
 
Zuletzt bearbeitet:
Da du schon einen gescheiten RAID Controller hast, setz alle Platten in eine RAID5.

Wieviel RAM steckt in der Kiste?
Bei VM sollte man mehr als genug haben ;)
 
Das Problem ist, dass VMs multiple Zugriffe auf das Array haben und das nicht zu knapp.
Einzige ausweg ist hier mehrere kleine Platten, 15k Platten, SSDs oder Ramdisk (welcher Art auch immer). Damit sollte dass dann besser gehen.
Natürlich brauchen die VMs auch etwas (mehr) RAM zum Arbeiten.
 
Da du schon einen gescheiten RAID Controller hast, setz alle Platten in eine RAID5.

Wieviel RAM steckt in der Kiste?
Bei VM sollte man mehr als genug haben ;)

Wie gesagt, bei RAID5 ist die Schreibperformance immer schlecht... und 6 Platten für ein RAID5 sind in Sachen Datenkorruption doch recht viel... da schlafe ich nicht gut (Backup von den Daten habe ich natürlich).

In der Kiste stecken 16GB RAM und nen Q9550. CPU- und RAM-Auslastung sind auch gering... ich merke deutlich, dass es an der Disk-Performance hapert.

edit: @underclocker2k4 durch die erhöhte Anzahl von Platten erhöhen sich dann natürlich auch die IOPS. Es sollte allein dadurch schon besser werden...

Die Frage ist nur, RAID10? RAID50? oder eher das RAID5/6... die Kapazität erhöht sich ja bei allen Varianten. Wenn es wieder knapp wird, dann kann ich meist das RAID-Level ja konvertieren.
 
Zuletzt bearbeitet:
Wie underclocker2k4 dann schon erwähnte wäre der nächste Schritt dann schon Richtung 15k SAS HDDs oder 2-4 SSDs.
Der Rest der Hardware scheint ja nicht zu limitieren, also musst du hier ansetzen ;)
 
Wie underclocker2k4 dann schon erwähnte wäre der nächste Schritt dann schon Richtung 15k SAS HDDs oder 2-4 SSDs.
Der Rest der Hardware scheint ja nicht zu limitieren, also musst du hier ansetzen ;)

damit erreiche ich aber nicht so hohe Kapazitäten ;) (zumindest nicht zu den Preisen).
Ich versuche das Maximale aus dieser Konstellation rauszuholen. Aber welches RAID-Level...
 
Das kann ich bestätigen. Raid5 ist einfach nicht gut für den VMware-Betrieb. Wir haben den 9650-4Port, aber nur ein Raid5 mit 3 Festplatten. Je nach Anforderung kann das 3-6 VMs betreiben, aber dann wirds schwierig. Bei 8 VMs parallel hatten wir üble IO-Waits und damit Freezes in den Gastsystemen.
Daher lassen wir die VMs jetzt auf Single-Platten laufen und das geht echt gut. So ne Hitachi 7K1000.B schluckt im Single-Betrieb locker 4 Maschinen, in Einzelfällen haben wir sogar 5, bis zu 6 VMs auf einer Platte laufen. Aber da muss ich fairerweise dazu sagen, dass einige VMs bei uns keine große Last verursachen (Enterprise PBXen).

Zurück zu deinem Fall: Warum alles in ein großes Array?? Ich würde eins für Daten machen und das dann je nach Größe als Raid5 oder 6.
Für die VMs entweder Single-Platten (wenn dort keine produktiven Daten behandelt werden oder Entwicklungsarbeit reingesteckt wird - oder aber nächtlich automatisiert wegsichern lassen), oder nen Raid 10/01.

Klar würde ein Raid 50 oder 60 auch gehen, jedoch stellt sich die Frage ob die Daten so schnell angebunden sein müssen?
 
@7even
Naja mir schwebt im Kopf: Je mehr Platten, desto höher die IOPS und die sequentiellen Transferraten.
Wenn ich das jetzt in Daten und VMs aufteile, dann ist es so langsam wie vorher ;)
Single-Platte ist keine Option.

Klar würde ein Raid 50 oder 60 auch gehen, jedoch stellt sich die Frage ob die Daten so schnell angebunden sein müssen?

Warum nicht? Ist nur die Frage ob sich irgendwelche Nachteile ergeben (mir fallen keine ein)
Bei RAID10 ist der Verschnitt zu hoch... bei RAID50 ist es besser.
 
Du darfst Zugriffsmuster von Benches nicht mit dem Zugriffsmuster von VMs kurzschließen.

Fakt ist, dass bei tiefer queue der Anstieg der IOPs mit der Anzahl der Platten ganz gut skaliert. Aber wie gesagt, bei TIEFER queue.

Die Zugriffe lassen sich aber bei einem VM host kaum in einer Queue arrangieren, somit ist die Queue sehr kurz und gerade in diesem Bereich skaliert ein RAID (egal welches) schlecht. Somit ist ein Performancegewinn durch Erhöhung der Plattenanzahl nicht zu erzielen.

Daher ist bei einem VMhost das Storagesystem der Knackpunkt schlecht hin. Durch ein RAID wird so gut wie garnichts an der Performance verbessert, hier dient es lediglich der Redundanz.
Die möglichen Ansätze zum Verbessern der VM-Performance habe ich genannt.
 
Durch ein RAID wird so gut wie garnichts an der Performance verbessert, hier dient es lediglich der Redundanz.

Hm da bin ich anderer Meinung.
Es spielt doch eine große Rolle wie viele Platten in die Operationen miteingebunden werden. Bei einem richtigen Controller wird z.B. bei einem RAID1 von allen Platten gelesen.
Warum sollten mehr IOPS und höhere sequentielle Transferraten nicht die Gesamtperformance verbessern?
(Klar die Zugriffszeit ändert sich nicht.)
In Sachen Queue verstehe ich deine Argumentation nicht. Der Controller hat doch seine eigene Queue. Vorher regelt die Virtualisierungsschicht und das Host-Betriebssystem den Zugriff auf das Array.
 
Klar werden bei den IOs von mehrere Platten gelesen, damit dass aber passiert muß die Queue ausreichend groß sein, damit der Zugriff eben verteilt werden kann.

Bei den "billig" VMs funktioniert aber das queueing mehr schlecht als recht(auch das Erzeugen von IOs an sich), Folge davon ist, dass die Queue sehr klein ist, wodurch ein Performancegewinn durch mehr HDDs vereitelt wird.
Die großen VMs ala ESX hingegen habe eine wesentlich bessere Queue-Verarbeitung. Wodurch hier ein Effekt durch mehr HDDs zu erzielen ist, sofern es der Controller bewerkstelligen kann.

Das ist das eine Problem. (Queueing auf Seiten der VMs)

Das Queueing auf Seiten des Controller funktioniert in der Regel einwandfrei und ist selten der Engpass. Hier liegt der Engpass an ganz anderer Stelle, bei der RAW-Performance des Arrays.

Dein 3ware ist sicherlich nicht von schlechten Eltern, bei einer gut arbeitetenden Queue kommt der auf ca 300IOPs bei 4x 10k Platten @RAID5. Ein RAID 0 zB hat hier aber dennoch ~50% mehr zu bieten.

Deine 7,2k Platten haben nur ca 66% einer guten 10k Platte (und ca 50% einer 15k Platte, und ca <10% einer SSD) zu bieten. Hinzukommen dann noch die Zugriffszeiten an sich.

Unterm Strich hast du mit einem RAID5 @7,2k nur ca 25% der Performance eines RAID0 mit 15k Platten zu bieten. Das sind schonmal schlechte Vorraussetzungen.

In Produktivumgebungen werden SANs eingesetzt, die eben auf maximal Performance hin optimiert wurden. Und genau SOWAS braucht man für VMs.

All zu viele Möglichkeiten hast du nicht.
1. ESX (oder ähnlich) einsetzen um zummindest die Storageperformance der VM an sich zu verbessern
2. Dein Storage umzustricken. Massiv mehr Platten (gepaart mit 1) oder aber wesentlich bessere "Platten".

Weitere Möglichkeit wäre RAMDISK.
So mach ich das zB:
RAMDISK für die SystemHDDs der VMs und RAID5 für das Storage der VMs.
Erfordert aber dann ein gewisses Kontingent an RAM, da du ja auch noch RAM für die VMs brauchst.

PS:
ESX kann bei 16VMs über 100k IOPs generieren.
 
Zuletzt bearbeitet:
Hm da bin ich anderer Meinung.
Es spielt doch eine große Rolle wie viele Platten in die Operationen miteingebunden werden. Bei einem richtigen Controller wird z.B. bei einem RAID1 von allen Platten gelesen.
Warum sollten mehr IOPS und höhere sequentielle Transferraten nicht die Gesamtperformance verbessern?
(Klar die Zugriffszeit ändert sich nicht.)
In Sachen Queue verstehe ich deine Argumentation nicht. Der Controller hat doch seine eigene Queue. Vorher regelt die Virtualisierungsschicht und das Host-Betriebssystem den Zugriff auf das Array.
Naja das Problem ist ja nicht, dass die Virtual Guests ihre Daten nicht schnell genug losbekommen - das saugt der Controller-RAM ja alles sofort auf.

Das Problem wird eher sein, dass alle Guests ihre Daten nicht schnell genug bekommen. Stell dir mal das Seek-Muster einer einzelnen Platte vor, wenn sie ein OS bedient. Da hat der Lesekopf je nach Fragmentierungsgrad schon gut zu tun. Und jetzt greifen mehrere OSes auf einen virtuellen Datenträger zu (sicher, der ist durch die vielen Platten darunter recht flott, aber die Seeks sind jetzt für alle gleich), d. h. jeder Zugriff für jedes OS wird mit einem Seek von allen Platten verschwendet, nur damit jede Platte dann ein klitzekleines Datenfitzelchen dem Controller überreichen kann, der dann die paar KB große Datei zusammenfriemelt.. das ist höchst ineffizient.
Als wir die max. ca. 8 Maschinen damals auf dem Raid5 laufen hatten ging eigentlich auch alles recht flott, bis auf die ständigen Freezes.. :d und die waren dann fast so lange wie die Phasen danach, in denen wieder alles recht flott ging.

Aber um die ganze Theorie mit Daten zu belegen, kannst du das gerne alles durchmessen! ;)
Das wäre bei deiner Skalierung durchaus interessant.

Eins ist aber sowieso klar: egal wie schnell der einzelne Datenträger oder der Datenträgerverbund sind, erzeugt eine VM maximale IO-Last (z. B. beim Runter- oder Hochfahren der sonstwas Plattenintensives), beeinträchtigt das alle VMs die auf diesem Datenträger laufen. Das spürt man.


PS: Das mit den Einzelplatten funktioniert jetzt bei uns aber übrigends recht gut. Nachteil ist halt die Datensicherheit. Wir haben jetzt also das Raid 5 mit drei Platten plus 5 Einzelplatten (wovon grad eine in RMA geht) und da laufen mit 16 GB RAM problemlos 18 VMs drauf. Mehr geht wahrscheinlich auch noch, aber war bisher noch kein Bedarf.. aber die Anzahl der VMs ist ja sowieso nicht so aussagekräftig da es ja auch drauf ankommt wieviel Performance die einzelnen Guests so brauchen. Die erwähnten PBXen machen ja kaum was, ne andre Cisco UCCX dagegen hat so eine derbe Plattenbeanspruchung, die zählt gleichmal für 3 normale Guests.. :haha:
 
Zuletzt bearbeitet:
@underclocker2k4

Ich bin VMware Certified Professional ;)
Mit ESX, Virtualisierungsumgebungen und allg. SAN-Storage kenne ich mich also sehr gut aus.
Aber leider fehlen mir ein paar Erfahrungen im Low-Cost Privat-Bereich. Klar könnte ich durch viel Geld immer mehr in Richtung Mid-Business gehen...
Massiv mehr Platten (gepaart mit 1)
Was meinst du mit "gepaart mit 1" ?
 
Massiv mehr Platten im RAID, gepaart mit Punkt 1, also ESX.

Ansonnsten muß man eben auf mehrere HDDs umswitchen, wie 7 anmerkt. Vorher sollte man sich überlegen, welche VMs welche Performance erzeugen und die mit weniger Performance zusammenfassen und die mit viel Performance aufteilen.
 
Die Tage werde ich mein Raid 5 (4x 1TB Samsung F1) um 2 HDDs auf Raid 6 erweitern.
Ich überlege auch, ob ich dieses Raid zusätzlich noch sichere. Weiss nur noch nicht wie!?

Entweder per NAS mit "Thecus 5200 Pro" oder aber die noch 6 freien Ports am Areca ARC-1261D-ML nutzen. Was denkt ihr?
 
Zuletzt bearbeitet:
Was für Raid Controller sind den zu empfehlen für 2 SSD´s wenn man den preis auf max 150€ festlegt?
Gibts in der preisklasse überhaupt was brauchbares?
 
Nicht wirklich...
Gute ext. Controller machen erst ab PCIe x4 + Cache Sinn. Also ab 230€ aufwärts.
 
ich bräucht halt irgendwas was einen deutlichen fortschrit zum onboard ICH9R macht.
Also irgendwas mit eigenem speicher (denke 256MB würden schon reichen, vielleicht sogar 128MB) usw. ich brauch jetzt keinen controller mit dem ich irgendwelche rekorde breche.
Ich merk halt nur das mein onboard quatsch die leistung doch sehr beschneidet die die beiden Vertex bringen könnten.
Möchte aber halt auch nicht unbedingt mehr als 150€ ausgeben.
 
Dann spar dir lieber die 150€ und such nach einem guten, gebrauchten Controller.
 
da waren sie wieder meine 3 probleme ^^ ne nur eins aber das hats in sich..
Gebraucht schön und gut, nur hab ich von den teilen null komma garkeine ahnung und wüsste garnicht auf was ich achten müsste um einen guten gebrauchten Controller zu erkennen ^^
 
Highpoint 3510
Areca ARC-1210
Dell Perc 5

Also min. PCIe x4 und min. 128MB Cache
 
Zuletzt bearbeitet:
ok damit kann ich ja schonmal was anfangen ;)
Danke

Da hab ich sogar einen gesehen der unter 200 neu kostet.
wäre der was?

Adaptec SATA/SAS RAID 2405 Single 4-port Controller RAID PCI-Express x 8 4 x SAS intern 128 Devices
http://www.adaptec.com/en-US/products/Controllers/Hardware/sas/entry/SAS-2405/
Oder hab ich was übersehen ?

Den gäbs jedenfalls schon ab 179€

Achja, ich hab da ja echt null plan davon, kann man von den dingern (zb dem gerade verlinkten) denn auch booten?
 
Zuletzt bearbeitet:
hi,
ich habe mal meine Raidconfig wieder an das MAinboard geklemmt....
Leider kommt nach ca 30 seks ein klackern und piepsen vom Raid-controller auf dem Board...
X38 Extreme
x6800
2xSeagate Raid 0

hat vorher wunderbar geklappt, nu kommt dieses geräusch..
Vllt hat jmd ne idee
thx
cheers
 
sicher das da das Board klackert und nicht eine der Festplatten?
Klackernde Boards sind mir noch nicht unter gekommen aber ne kaputte platte kann schonmal klackern und anschließend fiepsen, wieder klackern usw usw usw
 
hi, danke für den Hinweis, hatte mal alle platten abgeklemmt... HAt sich leider herausgestellt das die Backupplatte klackert..... Sehr ärgerlich
danke ;)
cheers
:wink:
 
moin moin zusammen,

ich hoffe mal, dass ich mich hier in den richtigen thread verirrt habe.
Ich möchte meinen Spiel-PC noch ein wenig mehr leistung verabreichen. Daher dachte ich an Raid 0. Geplant ist das ganze schon lange. Hatte nur leider bisher kaum Zeit mich mit dem Thema zu beschäftigen. Datensicherung spielt bei der Geschichte eigentlich keine Rolle. Alles wichtige habe ich auf anderen Rechnern verstaut.
Meine Überlegung war es für mein Raid 0 folgende Platten zu verwenden:

2 x WD VelociRaptor 150GB WD1500HLFS 10kU/m 16M

Macht das Sinn bzw. würdet ihr mir spontan davon abraten? Oder kann man das getrost empfeheln? Hab mir schon ein paar Texte zum Thema Raid durchgelesen. Allerdings würd ich mich hier keinesfalls als Experte bezeichnen. Wie gesagt: Datensicherung spielt hier für mich keine Rolle! Wenns kaputt geht hab ich halt Pech gehabt!
Raid ist für mich halt noch sowas wie Neuland.

Würd mich freuen, wenn der eine oder andere vieleicht seine Meinung bzw. Erfahrungen mit mir teilt!!!

Besten Dank im Voraus!


Edit:

Grund für die Änderung ist übrigens, dass meine alte "single" Raptor-Platte den Geist aufgegeben hat. Weitere Platten sind nicht geplant!
 
Zuletzt bearbeitet:
Ein RAID0 bringt bei deinen Anforderungen keinen signifiktanten Geschwindigkeitsvorteil.

Raptor ist schon der richtige Weg, SSD wäre noch richtiger.

RAID0 bringt dir so gut wie nichts.
 
Status
Für weitere Antworten geschlossen.
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