Frage zur Stabilität von swraid
Hallo, nachdem ich auf einem meiner Systeme keine guten Erfahrungen mit swraid gemacht habe, frage ich lieber bevor ich es nochmal einsetze. Ich wäre nämlich bereit zu akzeptieren, daß es bei diesem bestimmten System an der Hardware lag, daß sich das raid nach ca 1 Monat regelmäßig verabschiedete. Also, ich habe einen Server mit 2 solchen SCSI Controllern: 0000:00:05.0 SCSI storage controller: Adaptec AHA-3960D / AIC-7899A U160/m (rev 01) Subsystem: Compaq Computer Corporation Compaq 64-Bit/66MHz Dual Channel Wide Ultra3 SCSI Adapter Die haben schon einige Jahre auf dem Buckel, daher denke ich, daß sie recht gut unterstützt sind. Nun möchte ich an jeden eine Platte hängen und daraus ein raid1 für / und swap bauen. (Die Anwendungsdaten liegen schon woanders). Hat jemand positive oder negative Erfahrungen mit einem ähnlichen Setup? Danke, Torsten
On Thu, 3 Aug 2006 21:32:49 +0200 Torsten Foertsch <torsten.foertsch@gmx.net> wrote:
Im Grunde genommen habe ich gute Erfahrungen gemacht. Ich hatte zwar kürzlich mal ein Problem mit dem mdadm beschrieben, also dem zentralen Werkzeug für SW-RAID unter Linux, aber das soll nicht darüber hinwegtäuschen, dass hier mehrere RAID-1 und ein RAID-5 trotz diverser "unexpected shutdowns" :-) sauber laufen. Auch von der Performance her kann ich nicht klagen, aber natürlich ist das ein Aspekt, den man bei hoch belasteten Servern berücksichtigen sollte. Bei klassischen Fileserver ist das eher kein Problem, weil hier eher der IO-Durchsatz und nicht die CPU-Last den Engpass bilden.
Nun möchte ich an jeden eine Platte hängen und daraus ein raid1 für / und swap bauen. (Die Anwendungsdaten liegen schon woanders).
Mit Deinen Adaptecs habe ich keine Erfahrung, sondern nur mit "Billig-SCSI" a la Tekram sowie verschiedene IDE-Adapter von SIS bis Promise. Ich denke aber, dass es keine Probleme mit AIC geben sollte. Bei aller Begeisterung für HW-RAID wird gerne unterschlagen, dass Systeme wie Novell Netware schon vor 15 Jahren sehr erfolgreich und stabil RAID-1 betrieben haben. Nur das sich das damals Mirroring oder Duplexing (wenn man über zwei SCSI-Host-Adapter arbeitet) nannte. Du musst für /boot eine Non-RAID-Partition vorsehen. Eine Methode zur Sicherung der Redundanz könnte sein, daß Du die /boot auf beiden Platten(-stapeln) vorsiehst und "zu Fuß" spiegelst. Bei SCSI sucht sicht das System ja selber eine geeignete Bootpartition, was die Angelegenheit gegenüber IDE vereinfacht. Mußt es halt dann bei einem Kernel-Update manuell "spiegeln". Gruß, Tobias.
On Friday 04 August 2006 12:14, Tobias Crefeld wrote:
Du musst für /boot eine Non-RAID-Partition vorsehen.
Das stimmt nicht. Du kannst auch /boot auf ein RAID1 legen. Bei einem RAID1 werden die Daten gespiegelt. Am Ende der beiden Partitionen steht der RAID-Superblock. Damit ist der Anfang genau gleich zu einer normalen Partition. Nur ist sie eben doppelt. Du kannst grub eine beliebige davon als Boot-Partition geben. Du kannst auch beide über das Boot-Menu auswählbar machen. Dabei solltest Du aber auf die Grafik verzichten und das Boot-Menu im normalen Text-Modus verwenden. Sonst könnte es nämlich sein, daß grub versucht das Bild gerade von der Platte zu laden, die kaputt ist. Dann brauchst Du nur noch eine Möglichkeit, dem BIOS zu sagen, von welcher Platte es booten soll. Falls Deine üblich Boot-Platte kaputt ist, benutzt Du halt die andere, die gespiegelte. Genau das hatte ich mit meinem Server zuhause gemacht (http://foertsch.name/Artikel/SWRAID/index.shtml). Und es funktionierte auch richtig, nur daß immer nach ca. 1 Monat plötzlich eine Platte als fehlerhaft bezeichnet wurde. Das erste Mal habe ich sogar das Mutterbrett vom Hersteller ausgetauscht gekriegt. Nach einigen Monaten hatte ich das Spiel satt und habe mich vom Raid entfernt. Seitdem läuft der Rechner ohne Probleme durch. Torsten
Hallo Tobias,
Kleiner Vorschlag: Partition 1: ca. 30 - 50 MByte, ext 2, RAID-1, als /boot Partition 2: ca. 1 GByte, swap Partition 3: ca. 8 GByte, ext 3, RAID-1, als / Partition 4: der Rest, ext 3, RAID-1, z.B. für /home oder was sonst so gebraucht wird. Bei beiden Platten richte ich je ein GByte als swap ein, also kein RAID!! Das würde auch nur das Ganze bremsen, und im swap machr sich ein Plattenfehler auch nicht so drastisch bemerkbar. Maximal kann die Apllikation oder der Server sterben - aber das sind dann auch eher Fälle für high availability Lösungen. Grub kann aber nicht von einem Soft-RAID-5 booten !!!! Alle RAID's laufen ganz anständig bei mir und ich habe bestenfalls mal Probleme mit schlechten IDE-Kabeln gehabt - dank RAID führt das aber nur zu ein paar zusätzlichen Einträgen in der /var/log/message. -- So long Bernd
On Fri, 04 Aug 2006 20:46:12 +0200 Bernd Glueckert <bernd.glueckert@ot-soft.de> wrote:
Ist mir neu. Mal sehen, vielleicht probiere ich es mal aus.
Ich bin mittlerweile Fan von LVM. Je nach Aufgabe des Rechners richte ich eine volume-group aus RAID-1/RAID-5 und eine aus nicht-redundanten devices ein und teile dann aus dem Pool "/", "/home", "/pub/mirror", etc. zu. Da ist man flexibler. Lediglich "/boot" und "swap" werden direkt physikalischen devices zugewiesen.
Grub kann aber nicht von einem Soft-RAID-5 booten !!!!
Hm, muss mal nachgucken, aber zumindest auf einem Rechner ist noch LILO installiert. Obwohl das ja theoretisch trotzdem funktionieren müsste. Gruß, Tobias.
Tobias Crefeld schrieb:
Es geht, habe ich letztens auch gemacht, aber nur mit RAID1. Ich nehme dann lieber lilo als Bootloader, der kann damit umgehen, dass der Bootcode auf beiden /dev/hdxx geschrieben werden muss, und nicht auf /dev/mdx. Hier in /etc/lilo.conf: ... boot = /dev/md0 raid-extra-boot=/dev/hda,/dev/hdc ...
Allerdings würde ich /etc nicht auf ein lv legen, weil unter /etc/lvm/ steht, wie der LVM konfiguriert ist. Andererseits macht Redhat AS4 es trotzdem so, vielleicht ist meine Meinung hierzu antiquiert? Zu /boot siehe oben. Und swap muss natürlich auch redundant sein, sonst bleibt die Maschine im Ernstfall stehen. -- Viele Grüße ------------------------------------------------------------------------ Michael Behrens
participants (4)
-
Bernd Glueckert -
Michael Behrens -
Tobias Crefeld -
Torsten Foertsch