RAID1: Dedizierter Controller wirklich besser (statt mdadm)?

dev

Registered User
Guten Morgen,

ich muss mich heute für oder gegen die Nutzung eines vorhandenen Hardware RAID-Controllers entscheiden und brauche Eure Hilfe:

Habe einen Server mit eingebautem Hardware-RAD Controller (LSI Logic / Symbios Logic SAS1068E PCI-Express), an dem hängen 2 normale SATA-Disks.

Ich tendiere im Moment mehr dazu, das RAID mit mdadm aufzusetzen und die RAID-Funktionalität des Controllers nicht zu nutzen. Warum?

Monitoring: Ich muss extra ein Skript schreiben, dass den Zustand überwacht, bei mdadm muss man nur eine E-Mail angeben und den Monitor-Dienst starten.

Erfahrung: Mit mdadm habe ich ausreichend Erfahrung, um im Problemfall adäquat reagieren zu können. Das Hardware-RAID kann ich nicht probeweise "degraden", um den Fehlerfall durchzuspielen. So wäre alles nach Ticketeröffnung -> Festplattentausch Herumprobiererei.

Festplattenzustand: Benutze ich den Hardwarecontroller, habe ich keinen differenzierten SMART-Zugriff auf die Platten. Ich bekomme nur "Status: ok" bzw. "Status: online" zurück. Mit den Smartmontools kann ich bei Festplattenproblemen die SMART-Werte auslesen und beurteilen.

Ich sehe im Moment mehr Nachteile. Mit hdparm durchgemessen schaffen die Platten am Controller im Hardware-RAID1 ca. 61 MB/s. Das ist ziemlich mittelmäßige Wald- und Wiesenperfomance (halt das, was die Platten schaffen) - dafür brauche ich auch kein Hardware-RAID.

Übersehe ich irgendwelche Vorteile?
 
Für das Monitoring kannst du mpt-statusd nehmen, der schickt auch Mails. ;)

Die Prozedur um eine defekte Platte zu tauschen, ist bei dem HW-Raid wesentlich einfacher als beim Software-Raid.
Platte raus, neue Platte rein. Rebuild startet automatisch. Kein manueller Rescan, klonen der Partitionstabelle, einhängen ins Raid, usw erforderlich. ;)

SW-Raid macht auch gern mal Probleme, weil vergessen wird, den Bootloader auf beide Platten zu schreiben. Swap auf einem Software-Raid ist ebenfalls etwas problematisch. Entweder hast du 2 getrennte Swap Partitionen, dann fliegen dir die Anwendungen um die Ohren, dessen Daten auf der Swap Partition der defekten Platte liegen oder du packst den Swap mit in das Software Raid, dann musst du aber IMHO nach wie vor den Swap für den Sync des Raids abschalten.
Detaillierter Festplattenzustand kann dir in dem Falle eines Mietservers (ich gehe mal davon aus, wenn du von Ticketerstellung sprichst) doch völlig egal sein, wenn eine defekt ist, wird sie getauscht und gut. Sind beide defekt, hilft dir auch kein SMART mehr. ;)
 
Na, das ist doch mal eine Antwort, super :)

Ja, ist ein Mietserver.

mpt-statusd - wo finde ich das Paket? mpt-status ist installiert (und liefert mir meine Daten auf der Konsole, ist der Daemon mit dabei? Ich kann leider nicht nachsehen im Moment...

Firewire2002 said:
Swap auf einem Software-Raid ist ebenfalls etwas problematisch. Entweder hast du 2 getrennte Swap Partitionen, dann fliegen dir die Anwendungen um die Ohren, dessen Daten auf der Swap Partition der defekten Platte liegen oder du packst den Swap mit in das Software Raid, dann musst du aber IMHO nach wie vor den Swap für den Sync des Raids abschalten.

Das verstehe ich nicht ganz?! Ich selbst richte den Swap immer mit auf einem md-Device ein, also auch gespiegelt. Bisher gab es noch nie Problem. Ist das nicht eh hinfällig, wenn das System zum Plattentausch gebootet wird? Der Swap ist doch dann leer nach dem Boot?
 
mpt-statusd ist zumindest im Debian Lenny Package bei mpt-status mit drin.

Je nach Controller können auch bei einem Software Raid die Platten im Betrieb getauscht werden. ;)
Aber auch wenn du den Rechner dazu runterfährst/runterfahren lässt, sollte der Swap danach nicht aktiviert werden, solang das Raid noch am syncen ist. Swap auf einem inkonsistenten Software-Raid kann zu einem sehr instabilem System führen.
Details müsst ich nun auch erst wieder raussuchen. Aber googlen kannst du ja auch selbst. :)
 
Swap auf einem Software-Raid ist ebenfalls etwas problematisch. Entweder hast du 2 getrennte Swap Partitionen, dann fliegen dir die Anwendungen um die Ohren, dessen Daten auf der Swap Partition der defekten Platte liegen oder du packst den Swap mit in das Software Raid, dann musst du aber IMHO nach wie vor den Swap für den Sync des Raids abschalten.

korrigiert mich, wenn ich falsch liege. Aber der SWAP sollte im Normalfall nicht dauerhaft genutzt sein, denn wenn es so ist, sollte man sich mal Gedanken über mehr Arbeitsspeicher machen. Der SWAP ist ja nur dann in Nutzung, wenn der normale Arbeitsspeicher nicht mehr für die Verarbeitung der aktuellen Prozesse ausreicht und dann wird das System auch brachial langsam, denn die Festplatten bringen ja gar nicht die die Datenrate wie der Arbeitsspeicher.

Bislang hatten wir nie Probleme damit, dass man den SWAP Speicher mit jeweils einer eigenen Partition pro Device anlegt. Geht eine der beiden Festplatten kaputt, halbiert sich einfach der zur verfügung stehende SWAP und nachdem Programme nur im Fall des nicht mehr ausreichenden Arbeitsspeichers Swappen, kommt es an dieser Stelle auch nicht zu einem Problem mit den Anwendungsprogrammen.

Ein weitere Vorteil eines Hardware RAID Controllers, der meines Erachten noch nicht angesprochen wurde, ist, dass dieser einen Cache hat und daher unter Umständen schneller aggieren kann als ein normales Software RAID.

Hier einmal zum Vergleich hdparm bei einem Server mit einem 3Ware 8006-2LP und einmal mit MDADM

3Ware 8006-2LP
Code:
s2:~# hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   11568 MB in  2.00 seconds = 5790.60 MB/sec
 Timing buffered disk reads:  172 MB in  3.00 seconds =  57.27 MB/sec
s2:~#

Der controller ist schon etwas älter und macht leider nur 150 MB/s Datenrate, reicht aber für Webanwendungen.

mdadm
Code:
root@s11:~# hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   2838 MB in  2.00 seconds = 1419.02 MB/sec
 Timing buffered disk reads:  356 MB in  3.02 seconds = 118.04 MB/sec
root@s11:~#
 
Bei Raid 1 mag der Performancenutzen gegebenenfalls grenzwertig sein. bei Raid 5 würde er aber deutlichst zu Tage treten.

Noch da ist Dein Controller wohl einer ohne eigenen Cache. Ein "ordentlicher" PCIe Controller hat neben der dedizierten CPU auch noch 128-512 Mb batteriegepufferten Cache. Da geht's dann noch mal ganz anders ab.
 
Ok, habt mich überzeugt. Ist ein PCIe-Controller. Da ist wohl doch ein Cache drin, der bringt 4x soviel wie mdadm an einem anderen Rechner bei gecachten Lesevorgängen. Ich denke mal, dass diese Differenz dadurch zustande kommt, oder?:

hdparm -tT /dev/sda am HW RAID Controller said:
/dev/sda:
Timing cached reads: 18980 MB in 2.00 seconds = 9502.14 MB/sec
Timing buffered disk reads: 186 MB in 3.02 seconds = 61.69 MB/sec


hdparm -tT /dev/sdc an mdadm (anderer Rechner said:
/dev/sdc:
Timing cached reads: 4020 MB in 2.00 seconds = 2009.84 MB/sec
Timing buffered disk reads: 228 MB in 3.00 seconds = 75.97 MB/ses


Gut, jetzt brauche ich nur noch das mpt-statusd Script für CentOS, zum Umschreiben habe ich keine Lust...
 
Wobei der Controller nicht der neuste ist wie Thunderbyte festgestellt hat. Uns geht es bei einigen Servern nur darum, dass überhaupt ein HW RAID generiert wird, da hier das OS kein Software RAID unterstützt.

Neue Controller bringen natürlich noch ein X Faches mehr an Leistung.
 
korrigiert mich, wenn ich falsch liege. Aber der SWAP sollte im Normalfall nicht dauerhaft genutzt sein, denn wenn es so ist, sollte man sich mal Gedanken über mehr Arbeitsspeicher machen. Der SWAP ist ja nur dann in Nutzung, wenn der normale Arbeitsspeicher nicht mehr für die Verarbeitung der aktuellen Prozesse ausreicht und dann wird das System auch brachial langsam, denn die Festplatten bringen ja gar nicht die die Datenrate wie der Arbeitsspeicher.

Deine Logik hat 2 kleine Fehler:
Zum einen ist es nur Theorie und Wunschdenken, dass der Swap nur genutzt wird, wenn der Ram voll ist. Selbst wenn der Ram leer ist, wird auch unter Linux ein kleiner Teil vom Swap genutzt. Praktisch wird er nun mal oft mit einkalkuliert. Ja es wird langsam, trotzdem muss man unter Umständen damit arbeiten.
Zum anderen hat deine Praxis das Problem, was ich weiter oben schon angesprochen habe. Hast du 2 getrennte Swap Partitionen auf 2 Festplatten und eine der Festplatten fällt aus, gehen dir die Daten im Swap verloren, was in der Regel zum Crash von Teilen der damit verbundenen Anwendung oder der ganzen Anwendung führt. Das kann irgendwie nicht Sinn der Sache sein. ;)
Bei mehreren Swap Partitionen führt der Kernel immer ein auf Prioritäten basierendens "Load-Balancing" durch. Aber niemals ein Mirroring. Das musst du schon eine Schicht oder mehrere Schichten unter der Swap Partition realisieren.
 
Also nichts für ungut. Aber dann haben wir komische Linux Systeme, denn unser SWAP steht irgendwie dauerhaft auf 0, solange nicht nachts die großen Backup Operationen anlaufen. Man muss nur aufpassen, denn der SWAP leert sich nicht automatisch, sondern überschreibt einfach die ausgelagerten Daten neu, das aber nur, wenn der RAM voll ausgelastet ist.
Wäre auch dumm von Programmen Daten in den langsameren SWAP zu lagern, wenn genug Arbeitsspeicher zur Verfügung steht.

Daher zeigt der SWAP, auch wenn der RAM nicht ausgelastet ist, Nutzung an, diese Nutzung kann aber durchaus einige Stunden zurückliegen.

http://wiki.ubuntuusers.de/SWAP - unabhängige Quelle :)
 
Wie der Swap bei dir genutzt wird, wissen wir natürlich nicht.
Wenn du auf deinem Server virtualisierst, wäre es für dich ja eventuell eine Option, eine kleine SSD-Festplatte für den Swap-Space einzusetzen. Dann kannst du den Gästen auf deinem System mehr RAM zuweisen, als physikalisch vorhanden ist. Braucht nun ein Gast wirklich so viel Arbeitsspeicher, wird der Swap auf der SSD genutzt, was deutlich schneller ist, als auf der normalen mechanischen Festplatte.

Da du fragtest, ob du Vorteile übersiehst, hätte ich noch einen:
Viele Mainboards unterstützen leider immer noch kein Hot-Swap für SATA.
Wenn dir nun eine der Festplatten um die Ohren fliegt, bleibt im schlechtesten Fall sogar dein Server stehen und du musst einen Reset ausführen.
Bisher habe ich noch keinen HW-RAID-Controller gesehen, der Hot-Swap nicht unterstützt hat - nichtmal uralte IDE-RAID-Controller.
 
Auch eine SSD Festplatte kommt an die Datenrate von Arbeitsspeicher nicht ran, alleine über den Flaschenhals des Controllers. :)

Die Datenrate von Arbeitsspeicher liegt zwischen 2,1 und 6,4 Gbyte/s *hust* SSD zwar schneller als normale mechanische Festplatten, aber nicht so schnell wie richtiger Arbeitsspeicher.
 
Die Datenrate von Arbeitsspeicher liegt zwischen 2,1 und 6,4 Gbyte/s *hust* SSD zwar schneller als normale mechanische Festplatten, aber nicht so schnell wie richtiger Arbeitsspeicher.
Das ist richtig, ich meinte auch "schneller" im Sinne von "geringere Zugriffszeiten" ;)
Und die machen sich meiner Meinung nach tatsächlich bemerkbar - vor allem, wenn auf verschiedene Daten gleichzeitig zugegriffen werden soll.
 
Jungs. Ist doch wurscht. Bleiben wir doch am Besten beim Thema... :o

Nur nochmal zur Einordnung: der oben genannte LSI Controller ist übrigens nicht wirklich toll. Immerhin ists (meine ich) ein "echter" Raid Controller, im Gegensatz zu manchen BIOS-Treiber-Software Raid Controllern, die unter Linux schon mal ordentliche Probleme haben können. Gegen einen ordentlichen Adaptec/Promise/3Ware/HP Raid Controller mit eigener CPU, Cache Speicher und BBU kommt er aber nicht an und bietet auch kein Raid5/6, etc. wie diese. Die Performance dürfte auch weit unter diesen Controllern liegen.
 
Immerhin ists (meine ich) ein "echter" Raid Controller
Ja, ist es.

Gegen einen ordentlichen Adaptec/Promise/3Ware/HP Raid Controller mit eigener CPU
LSI hat ebenfalls "ordentliche" Raid Controller. Sowie die von dir genannten Hersteller auch Controller auf dem 1068er Niveau im Sortiment haben. Bisschen schwach die Aussage. ;)
Zumal bei einem Raid1 die CPU auf dem Controller nun wirklich keine ernsthafte Rolle spielt. ;)

und bietet auch kein Raid5/6, etc. wie diese
Es war von Raid1 die Rede. Wenn Raid5 nicht gefordert ist, ist dieses Feature hinfällig. Oder bezahlst du gern für etwas, dass du nicht brauchst? ;)

Die Performance dürfte auch weit unter diesen Controllern liegen
Jungs. Ist doch wurscht. Bleiben wir doch am Besten beim Thema... :o

Ich würd sagen du hast das Thema ebenfalls ein bisschen verfehlt. ;)
Frage war ob er den 1068er oder ein Software Raid einsetzen soll. Andere Controller spielen hier keine Rolle.

@dev
Wir haben dir nun wohl alle Vor- und Nachteile genannt. Entscheiden musst du schon selbst. ;)
Ich würde den 1068er einem Software Raid vorziehen.
 
Back
Top