Software-Raid vs. Chipset-Raid
-
- Beiträge: 402
- Registriert: 22.10.2006 20:24:59
- Lizenz eigener Beiträge: MIT Lizenz
Software-Raid vs. Chipset-Raid
Hallo,
wir ersetzen auf der Arbeit unseren Windows-Server durch einen Debian-Server und planen z.Zt. die Hardware und Software-Einrichtung.
Von dem IT-Unternehmen, mit dem wir zusammen arbeiten, wird ein Asus P5BV-C Board mit Chipset-Raid angeboten und vorgeschlagen, diese Raid-Funktion zu nutzen.
Ich habe inzwischen ein wenig gelesen (c't Heft 22 vom 13.10. über RAID, etc) und glaube, dass dies gegenüber einem Software-Raid mit mdadm keine Vorteile bietet. Eher Nachteile durch die Treiber-Abhängigkeit, etc.
Ich würde gern Eure Meinung zu dieser Frage wissen. Der Server stellt als Hauptaufgabe für ca. 20 Windows-Clients eine Datenbank für ein Anwendungsprogramm zur Verfügung, also hauptsächlich viele kleinere Lese- und Schreibzugriffe.
Der Prozessor (geplant Intel Quad 2,5GHz) sollte also für das RAID noch genügend Rechenzeit haben? Gedacht haben wir an ein RAID 10.
Selbst habe ich mit Raid bisher wenig Erfahrung, aber ein Test gestern unter Qemu mit einer Debian-Etch-VM und Raid 10 ging ohne Probleme.
Danke und viele Grüße
Theophil
wir ersetzen auf der Arbeit unseren Windows-Server durch einen Debian-Server und planen z.Zt. die Hardware und Software-Einrichtung.
Von dem IT-Unternehmen, mit dem wir zusammen arbeiten, wird ein Asus P5BV-C Board mit Chipset-Raid angeboten und vorgeschlagen, diese Raid-Funktion zu nutzen.
Ich habe inzwischen ein wenig gelesen (c't Heft 22 vom 13.10. über RAID, etc) und glaube, dass dies gegenüber einem Software-Raid mit mdadm keine Vorteile bietet. Eher Nachteile durch die Treiber-Abhängigkeit, etc.
Ich würde gern Eure Meinung zu dieser Frage wissen. Der Server stellt als Hauptaufgabe für ca. 20 Windows-Clients eine Datenbank für ein Anwendungsprogramm zur Verfügung, also hauptsächlich viele kleinere Lese- und Schreibzugriffe.
Der Prozessor (geplant Intel Quad 2,5GHz) sollte also für das RAID noch genügend Rechenzeit haben? Gedacht haben wir an ein RAID 10.
Selbst habe ich mit Raid bisher wenig Erfahrung, aber ein Test gestern unter Qemu mit einer Debian-Etch-VM und Raid 10 ging ohne Probleme.
Danke und viele Grüße
Theophil
- Six
- Beiträge: 8066
- Registriert: 21.12.2001 13:39:28
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Siegburg
Re: Software-Raid vs. Chipset-Raid
Ich würde in diesem Szenario deiner Einschätzung folgen. Hardware-RAID-Controller können nur unter sehr bestimmten Anforderungen einen Mehrwert gegenüber Software-RAIDs erzeugen und die scheinen hier nicht gegeben zu sein. Wenn es sich beim Onboard-RAID-Controller um einen Treiber-gestützten Controller handelt, dann bietet er unter keinem Umstand einen Vorteil, eigentlich ist das die schlechteste Lösung von allen -- und ich habe keine Ahnung, warum die sich so weit verbreitet haben.
Red Hat empfiehlt für die meisten Anwendungsszenarien Software-RAID und selbst Hardware-Hersteller, wie z. B. Adaptec, sehen die Vorteile von Hardware-Controllern nur in komplizierten, high-availability Setups.
EDIT: Achja, Hardware-Controller können, anders als Software-RAID, Schreibzugriffe cachen, aber ich weiß nicht wozu das gut sein soll.
Red Hat empfiehlt für die meisten Anwendungsszenarien Software-RAID und selbst Hardware-Hersteller, wie z. B. Adaptec, sehen die Vorteile von Hardware-Controllern nur in komplizierten, high-availability Setups.
EDIT: Achja, Hardware-Controller können, anders als Software-RAID, Schreibzugriffe cachen, aber ich weiß nicht wozu das gut sein soll.
Be seeing you!
-
- Beiträge: 402
- Registriert: 22.10.2006 20:24:59
- Lizenz eigener Beiträge: MIT Lizenz
Re: Software-Raid vs. Chipset-Raid
Hallo Six,
danke für Deinen Rat. Es handelt sich hier um einen Treiber-abhängigen Controller und wir werden nun den Rechner mit Software-Raid einrichten.
Viele Grüße
Theophil
danke für Deinen Rat. Es handelt sich hier um einen Treiber-abhängigen Controller und wir werden nun den Rechner mit Software-Raid einrichten.
Viele Grüße
Theophil
Re: Software-Raid vs. Chipset-Raid
Es gibt einen simplen Grund warum Hardware-Raid Controller cachen.
Wenn die DB ständig die selben Daten anfoert werden diese gecachet und sind mit der Zugriffszeit des Caches bei der DB (< 1ms) und nicht erst nach 5-15ms die die Platten brauchen.
Wenn viele Prozesse gleichzeitig auf den Disks rumrödeln und einige davon streamen (sequentiell) Arbeiten werden die Daten die als nächsten Angefragt werden schonmal vorweg gelsen (readahead) und im Cache gespeichert bis sie abgefragt werden. In der Zeit bis weiter gelesen werden muss ist "Luft" für andere Prozesse die Daten anfordern.
Wenn die DB ständig die selben Daten anfoert werden diese gecachet und sind mit der Zugriffszeit des Caches bei der DB (< 1ms) und nicht erst nach 5-15ms die die Platten brauchen.
Wenn viele Prozesse gleichzeitig auf den Disks rumrödeln und einige davon streamen (sequentiell) Arbeiten werden die Daten die als nächsten Angefragt werden schonmal vorweg gelsen (readahead) und im Cache gespeichert bis sie abgefragt werden. In der Zeit bis weiter gelesen werden muss ist "Luft" für andere Prozesse die Daten anfordern.
Re: Software-Raid vs. Chipset-Raid
Auf jedefall SW Raid! Diese Fakeraids sind einfach nur Scwhwachsinn für Windowsuser weil dort keine so schönen SWRaid Tools eingebaut sind wie bei Linux
Ein echtes Hardware Raid kann sich schon lohnen. Es entlastet den Prozessor und kann besonders im Rebuilt Fall schneller arbeiten und weniger Resourcen aus dem System nehmen als ein SW Raid. Ausserdem kann man in der Regel höher Durchsätze ererichen, weil die Controller einfach schneller sind als die Onboard Geräte, auch ohne Raid.
In den meisten Fällen ist ein SWRaid aber eine Gute und zuverlässige Lösung.
lg mcdikki
Ein echtes Hardware Raid kann sich schon lohnen. Es entlastet den Prozessor und kann besonders im Rebuilt Fall schneller arbeiten und weniger Resourcen aus dem System nehmen als ein SW Raid. Ausserdem kann man in der Regel höher Durchsätze ererichen, weil die Controller einfach schneller sind als die Onboard Geräte, auch ohne Raid.
In den meisten Fällen ist ein SWRaid aber eine Gute und zuverlässige Lösung.
lg mcdikki
LINUX - Life is too short for reboot!
Samba PDC auf Debian Etch | 2xIntel Xeon 3GHz - 2048 MB RAM - RAID 10 mit 3Ware 9550SX-4LP und 4x80GB HDD SATAII
Samba PDC auf Debian Etch | 2xIntel Xeon 3GHz - 2048 MB RAM - RAID 10 mit 3Ware 9550SX-4LP und 4x80GB HDD SATAII
- Six
- Beiträge: 8066
- Registriert: 21.12.2001 13:39:28
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Siegburg
Re: Software-Raid vs. Chipset-Raid
Klar, bei Lesezugriffen leuchtet mir das schon ein, aber warum bei Schreibzugriffen (sogn. Write-Back)?Bueddy hat geschrieben:Es gibt einen simplen Grund warum Hardware-Raid Controller cachen.
Wenn die DB ständig die selben Daten anfoert werden diese gecachet und sind mit der Zugriffszeit des Caches bei der DB (< 1ms) und nicht erst nach 5-15ms die die Platten brauchen.
Wenn viele Prozesse gleichzeitig auf den Disks rumrödeln und einige davon streamen (sequentiell) Arbeiten werden die Daten die als nächsten Angefragt werden schonmal vorweg gelsen (readahead) und im Cache gespeichert bis sie abgefragt werden. In der Zeit bis weiter gelesen werden muss ist "Luft" für andere Prozesse die Daten anfordern.
Be seeing you!
Re: Software-Raid vs. Chipset-Raid
Wenn deine Applikation/DB etwas schreiben möchte und und auf ein ACK wartet, macht es einen Unterschied, ob du <1ms wartest (Daten im Cache und ein ACK zurück) oder ~10ms bis die Daten auf der Disk sind. Während dieser ~9ms würde die Applikation dann nichts tuen.
Das macht vorallem bei großen udn oder vielen Applikationen/DBs Sinn, weil dass die Leistung drastisch erhöht.
Das macht vorallem bei großen udn oder vielen Applikationen/DBs Sinn, weil dass die Leistung drastisch erhöht.
- Six
- Beiträge: 8066
- Registriert: 21.12.2001 13:39:28
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Siegburg
Re: Software-Raid vs. Chipset-Raid
OK, klingt einleuchtend. Jetzt frage ich mich aber unwillkürlich, ob das nicht zu Inkonsistenzen oder, im Falle eines Brownouts, sogar zu Datenkorruption führen könnte.
Be seeing you!
Re: Software-Raid vs. Chipset-Raid
hi,
Inkonsistenzen gibt's so viel (oder normalerweise so wenig) wie bei jedem Cache, aber ohne Strom gehen natürlich Daten verloren. Deshalb haben richtige Hardware-Raids einen Akku für den Cache.Six hat geschrieben:Jetzt frage ich mich aber unwillkürlich, ob das nicht zu Inkonsistenzen oder, im Falle eines Brownouts, sogar zu Datenkorruption führen könnte.
Beware of programmers who carry screwdrivers.
- 6uellerBelästigungspanda
- Beiträge: 333
- Registriert: 07.02.2007 08:36:58
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Österreich
Re: Software-Raid vs. Chipset-Raid
ich stimme hier Bueddy absolut zu.
der einzige grund wieso man kein hardware raid einsetzen sollte ist die kostenfrage.
das gleiche gilt, wie ebenso sehr oft besprochen, ob SATA oder SAS -> ebenso kostenfrage.
die vorteile beider ist einfach unbestreitbar.
ich sag jetzt einfach mal die einstiegsklasse von HP liegt mit dem e200 auf ca. €270 - bei 20 Clients ist man mit diesem schon gut bedient.
bei einer serverkonsolidierung sind aber viele faktoren, unabhängig ob SW oder HW Controller, zu beachten.
der einzige grund wieso man kein hardware raid einsetzen sollte ist die kostenfrage.
das gleiche gilt, wie ebenso sehr oft besprochen, ob SATA oder SAS -> ebenso kostenfrage.
die vorteile beider ist einfach unbestreitbar.
ich sag jetzt einfach mal die einstiegsklasse von HP liegt mit dem e200 auf ca. €270 - bei 20 Clients ist man mit diesem schon gut bedient.
bei einer serverkonsolidierung sind aber viele faktoren, unabhängig ob SW oder HW Controller, zu beachten.
The nice thing about Windows is - It doesnt' just crash, it displays a
dialog box and lets you press 'OK' first
dialog box and lets you press 'OK' first
-
- Beiträge: 402
- Registriert: 22.10.2006 20:24:59
- Lizenz eigener Beiträge: MIT Lizenz
Re: Software-Raid vs. Chipset-Raid
Inzwischen läuft der Debianserver mit Software-RAID 10 und wir sind bei unseren Anwendungen mit der Leistungsfähigkeit voll zufrieden! Dies obwohl wir wegen des proprietären älteren Datenbank-Programmes keinen Quad-Prozessor sondern einen Core 2 E7400 nehmen mussten.
Verglichen mit dem alten Server (3ware RAID SATA Controller mit RAID 5 konfiguriert, Asus P4PE, Intel 3,06GHz FSB 533) deutlich schneller.
Theophil
Verglichen mit dem alten Server (3ware RAID SATA Controller mit RAID 5 konfiguriert, Asus P4PE, Intel 3,06GHz FSB 533) deutlich schneller.
Theophil
-
- Beiträge: 3472
- Registriert: 30.11.2005 10:32:22
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Wald
Re: Software-Raid vs. Chipset-Raid
Hier [1] hab ich noch einen weitern möglichen Grund für write-caching gefunden (zumindest bei raid5/6):Six hat geschrieben:Klar, bei Lesezugriffen leuchtet mir das schon ein, aber warum bei Schreibzugriffen (sogn. Write-Back)?Bueddy hat geschrieben:Es gibt einen simplen Grund warum Hardware-Raid Controller cachen.
Wenn die DB ständig die selben Daten anfoert werden diese gecachet und sind mit der Zugriffszeit des Caches bei der DB (< 1ms) und nicht erst nach 5-15ms die die Platten brauchen.
Wenn viele Prozesse gleichzeitig auf den Disks rumrödeln und einige davon streamen (sequentiell) Arbeiten werden die Daten die als nächsten Angefragt werden schonmal vorweg gelsen (readahead) und im Cache gespeichert bis sie abgefragt werden. In der Zeit bis weiter gelesen werden muss ist "Luft" für andere Prozesse die Daten anfordern.
[1] http://blogs.sun.com/bonwick/entry/raid_zJeff Bonwick hat geschrieben: There's also a nasty performance problem with existing RAID schemes. When you do a partial-stripe write -- that is, when you update less data than a single RAID stripe contains -- the RAID system must read the old data and parity in order to compute the new parity. That's a huge performance hit. Where a full-stripe write can simply issue all the writes asynchronously, a partial-stripe write must do synchronous reads before it can even start the writes.
Once again, expensive hardware offers a solution: a RAID array can buffer partial-stripe writes in NVRAM while it's waiting for the disk reads to complete, so the read latency is hidden from the user. Of course, this only works until the NVRAM buffer fills up. No problem, your storage vendor says! Just shell out even more cash for more NVRAM. There's no problem your wallet can't solve.