Folgende Situation: Ein neuer Server mit SATA II Disks soll unter Linux im RAID1 Verbund laufen aber der sogenannte RAID-Controller vom Motherboard wird nicht unterstützt. Da nur RAID1 benötigt wird und Linux das einzige System werden soll, tut es auch die Linux-Software-Raid Unterstützung. Das MoBo hat den Intel ICH7 Chipset onboard, welcher AHCI mit HotPlug und NCQ (Native Command Queuing) unterstützt – also soll dieses idealerweise aktiviert werden. Soweit die Zielsetzung – doch bevor ich das umsetzen konnte musste ich erstmal etwas Hintergrundwissen aufsaugen und einige Hürden nehmen:
Die erste Hürde: Das Asus P5WDB2 WS PRO MoBo bootet die Debian Etch PreRelease mit Stand vom 02.01.2007 nicht sondern bleibt sehr früh hängen. Erst nachdem ich im BIOS bei den Advanced-Einstellungen den Marvell SATA Controller für den zweiten sog. zweiten onboard Raid-Controller deaktiviert habe, kommt der Debian Etch-Installer überhaupt weiter.
Allgemeine Hintergrund-Info zu RAID im allgemeinen und auch Hardware-RAID vs. Software-RAID gibt es hier.
SATA RAID (oft auch als FakeRAID bezeichnet) unter Linux ist offenbar ein Thema was in letzter Zeit immer mehr nachgefragt wird, weil nahezu alle aktuellen MoBos RAID für SATA versprechen, die aber bei genauerem Hinschauen dann oft doch nur Software-RAID-Lösungen im Bios sind, die dazu noch einen Treiber benötigen, den es oft für Linux noch nicht gibt..
Diese Lösungen sind also für Windows entwickelt und greifen auf Treiber zurück, die es für Linux i.d.R. noch nicht gibt.
Ich denke, man sollte generell diese FakeRAID Lösungen für Linux meiden und die RAID-Unterstützung im BIOS deaktivieren und statt dessen auf das gut erprobte Linux Software-Raid dmraid zurückgreifen. Da FakeRaid kein echtes Hardware-RAID ist, bringt es auch keine Vorteile gegenüber dem Linux-Softwareware-RAID. Im Gegenteil: Man greift auf herstellerspezifische Lösungen zurück, die an diese Produktversionen binden (vergleich auch den berits oben verlinkten Wikipedia Artikel über Hardware-RAID).
AHCI im Bios aktivieren:
Also habe ich im BIOS des Asus P5WDG2 WS PR MoBos die IDE Configuration aus diesen Gründen nicht auf RAID eingestellt. Auch die Einstellung beim Intel ICH7 basierten SATA Controller auf “Standard IDE” wäre nur eine Notlösung, wenn der Kernel nicht das AHCI unterstüzten würde. Mit “Standard IDE” bekommt man zwar auch das gewünschte RAID1 Software-Array unter Linux aufgesetzt, hat dann aber keine Hotplug/Hotswap Funktionalität, weil der ICH7 Chipset im Standard-IDE Modus dieses nicht leistet. Weiterhin wird im Standard-IDE Modus kein NCQ unterstützt. Standard-IDE kommt also ohne die zusätzlichen Features von SATA oder SATA II daher.
NCQ wird aber vom ICH7 Chipset und den WD5000YS Laufwerken unterstützt und sollte daher auch zur Leistungssteigerung aktiviert werden, zumale im aktuellen Kernel von Etch der Version 2.6.18-3 AHCI auch unterstützt wird (laut http://linux-ata.org/driver-status.html#ahci wird AHCI ab Kernel >= 2.6.18-git5 unterstützt). Ich habe also im BIOS auf AHCI gestellt (Full NCQ support, full SATA control including hotplug and PM., AHCI is a nice, open design.) und auch ALPE (Agressive Link Power Management) und ASP (Agressive Slumber/Partial) enabled. Damit wird der SATA Controller in den nativen Modus geschaltet und unterstützt auch Hotplug sowie das Permance-Steigernde NCQ. Wenn später alles installiert ist, kann man nach dem Reboot das dmesg angeschauen um, zu prüfen, dass AHCI und NCQ aktiviert sind:
[CODE]
ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode
ahci 0000:00:1f.2: flags: 64bit ncq pm led clo pio slum part
ata1: SATA max UDMA/133 cmd 0xF88AE900 ctl 0x0 bmdma 0x0 irq 58
ata2: SATA max UDMA/133 cmd 0xF88AE980 ctl 0x0 bmdma 0x0 irq 58
ata3: SATA max UDMA/133 cmd 0xF88AEA00 ctl 0x0 bmdma 0x0 irq 58
ata4: SATA max UDMA/133 cmd 0xF88AEA80 ctl 0x0 bmdma 0x0 irq 58
scsi0 : ahci
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: ATA-7, max UDMA/133, 976773168 sectors: LBA48 NCQ (depth 31/32)
ata1.00: ata1: dev 0 multi count 16
ata1.00: configured for UDMA/133
scsi1 : ahci
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: ATA-7, max UDMA/133, 976773168 sectors: LBA48 NCQ (depth 31/32)
ata2.00: ata2: dev 0 multi count 16
ata2.00: configured for UDMA/133
scsi2 : ahci
ata3: SATA link down (SStatus 0 SControl 300)
scsi3 : ahci
ata4: SATA link down (SStatus 0 SControl 300)
Vendor: ATA Model: WDC WD5000YS-01M Rev: 07.0
Type: Direct-Access ANSI SCSI revision: 05
Vendor: ATA Model: WDC WD5000YS-01M Rev: 07.0
Type: Direct-Access ANSI SCSI revision: 05
[/CODE]
Es ist nun also alles vorbereitet für das eigentlich Einrichten das RAID1 und die Installation von Linux.
Leider ist die Installation des Software-Raids nicht so leicht. Für Ubuntu ist es offenbar überhaupt nicht vorgesehen, so dass man über einen Trick mit der Live-CD ein Raid einrichten muss und dann in das “on the fly” eingerichtete RAID hineininstalliert. Wer diesen Weg gehen möchte finde hier eine Anleitung: http://www.ubuntu-in.org/wiki/SATA_RAID_Howto.
Fedora soll da mit dem Installer schon weiter sein, aber ich würde gerne Debian oder zumindest Ubuntu einsetzen.
Debian Etch ist zwar immer noch nicht offiziell released worden, aber die Debian Testing gilt immer schon als sehr stabil, so dass ich mich für den aktuellen Build von Etch entscheide. Hierbei orientiere ich mich an “Install Debian Etch on a Software Raid 1 with S-ATA disks“:
[CODE]
# Boot the Debian Etch installer.
# If the installation comes to “Partition method”, use “Manual”.
# In the following menu, scroll to your first disk and hit enter: the partitionier asks you, if you want to create an empty partition table. Say “yes”. (Hint: this will erase your existing data, if any.)
# The partitioner is back in the disk overview, scroll one line downwards over the line with “FREE SPACE” and hit enter.
# Create a partition with the size you need, but remember the size and the logical type.
# In the “Partition settings” menu, go to “Use as” and hit enter.
# Change the type to “physical volume for RAID”.
# Finish this partition with “Done setting up the partition”.
# Create other partitions on the same disk, if you like.
# Now repeat all the steps from the first disk for the second disk.
# After this, you should have at least two disks with the same partition schema and all partitions (beside swap) should be marked for RAID use.
# Now look at the first menu entry in the partitioner menu, there is a new line: “Configure software RAID”. Go into this menu.
# Answer the question, if you like to write the changes, with “Yes”.
# Now pick “Create MD device”.
# Use RAID1 and give the number of active and spare devices (2 and 0 in our case).
# In the following menu, select the same device number on the first and second disk and Continue.
# Repeat this step for every two devices until you are done. Then use “Finish” from the Multidisk configuration options.
# You are back in the partitioner menu and now you see one ore more new partitions named as “Software RAID Device”. You can use this partitions like any normal partition and continue installing your system.
[/CODE]
Eine weiterführende Variante berücksichtigt auch noch die Einrichtung von LVM “Installing root on LVM + RAID with debian-installer”: http://dev.jerryweb.org/raid/
Nachdem das RAID1 eingerichtet ist und in das frisch installierte System gebootet wurde, kann via mdadm das Raid geprüft (mdadm –detail /dev/md0) , überwacht und administriert werden. Siehe dazu “man mdadm” oder auch im Software-RAID-HowTO. Dort werden wichtige Kommando zum Entfernen (z.B. mdadm /dev/md0 -r /dev/sdc2) und hinzufügen (z.B. mdadm /dev/md0 -a /dev/sdc2) zum Array erläutert.
Es empfiehlt sich, die SATA Kabel zu beschriften, damit man bei einem Ausfall einer Platte diese später leicht identifizieren kann. Ich habe den Ausfall jeweils eines Laufwerks erfolgeich simmuliert. Der Ausfall im laufenden betrieb wird erkannt und via “mdadm –detail /dev/md0” korrekt ausgewiesen. Die Platte kann dann wieder mit “mdadm /dev/md0 -a /dev/sdxxx” eingehängt werden worauf der rebuild started.
Weiterführende Hilfreiche Infos habe ich hier gefunden: Serial ATA (SATA) chipsets — Linux support status.
Moin,
vielen Dank für das Tut, echt nett gemacht. Vorallem der Link “”Install Debian Etch on a Software Raid 1 with S-ATA disks”:” war sehr hilfreich. Nun, ich habe eine Frage, ich habe auch ein Raid 1 laufen wird auch korrekt von mdadm –detail /dev/md0 angezeigt, leider hatte ich bei dem Festplatten ausfall einen Fehler, bzw. es lief glaub ich nicht so wie es sein sollte:
Als ich das SATA Kabel einer Festplatte entfernte lief das System instabil, ich konnte mich mit dem Server zwar per Putty noch verbinden aber konnte kaum noch was machen, auch mit Samba konnte ich mich nicht mehr verbinden.
Woran kann das liegen?
PS: Wenn ich den Server herunterfahre ein Kabel entferne erkennt er es und startet von der funktionierenden Platte.
Sorry Jonas, da kann ich aus der Ferne nichts zu sagen. Wenn ich bei meinem Setup (AHCI mit HotPlug und NCQ) einen Ausfall simuliere läuft das System stabil weiter. Alle Daemons bleiben unbeeindruckt.
Schaue doch mal in Dein /var/log/syslog ob Du dort weitere Hinweise für das Verhalten findest.
Bei mir läuft das System seit Monaten Stabil. Die einzige Auffälligkeit über die ich mal gestolpert bin sind regelmäßige Einträge im syslog:
Sep 2 01:06:02 aurora mdadm: RebuildStarted event detected on md device /dev/md0
Sep 2 01:38:02 aurora mdadm: Rebuild20 event detected on md device /dev/md0
Sep 2 02:11:02 aurora mdadm: Rebuild40 event detected on md device /dev/md0
Sep 2 02:44:02 aurora mdadm: Rebuild60 event detected on md device /dev/md0
Sep 2 03:22:01 aurora mdadm: Rebuild80 event detected on md device /dev/md0
Sep 2 04:18:57 aurora mdadm: RebuildFinished event detected on md device /dev/md0
Ein manueller Rebuild wurde nicht in Auftrag gegeben. Die Ursache kommt aus /etc/cron.d/mdadm:
Warum nun jedoch der periodic redundancy check wie ein rebuild ausgewiesen wird, beschäftigt auch andere Blogger. Conclusion:
“check’ is a read-only operation, even though the kernel logs may suggest otherwise (e.g. /proc/mdstat and several kernel messages will mention “resync”).”
und
“In short: it’s a bug. checkarray is actually not a resync, but the kernel does not distinguish between them.”
Meinst du es könnte daran liegen, das ich das SATA Kabel währned des Betriebes raus gezogen habe, muss ich es mit dem Stromstecker versuchen?
MfG Jonas
PS: Habe den Server gerade nicht hier, kann es also jetzt nicht ausprobiern, deswegen vorab die Frage.
Nein Jonas, ich ziehe hier auch den SATA Stecker am SATA II Laufwerk um einen Plattenausfall zu simmulieren. Ich meine, dass Deine Hardware evtl. kein Hotplug unterstützt. Du kannst dann auch mit mdadm und dem Parameter –fail oder –set-faulty eine Platte als defekt markieren (siehe man mdadm). Oder Du fährst den Rechner runter und ziehst dann die Kabel.
Vielleicht hilft Dir folgende Seite weiter:
http://www.linux-magazin.de/heft_abo/ausgaben/2006/09/kalte_platte?special=Storage&category=13791
Ich glaube wir reden aneinander vorbei. Ich meine wenn ich einen Plattenausfall simulieren will ziehe ich einfach den SATA stecker. Dann müsste doch die andere Festplatte einspringen?
Oder meinst du genau das selbe?
Brauch man dafür Hotplug fähige Hardware?
Jonas, ich denke wir meinen das gleiche. Aber bitte lies doch mal den Artikel auf den ich verlinkte habe:
“Der Serial-ATA-Bus ist von Haus aus Hotplug-fähig. Wer aber glaubt, dass jeder SATA-Controller diese Eigenschaft erbt und man im laufenden Betrieb Platten entfernen und einstecken darf, hat weit gefehlt.” … “Denn natürlich liegt es im Interesse eines jeden Administrators, ausgefallene Platten schnell im laufenden Betrieb wechseln zu können, um die Verfügbarkeit hoch zu halten. Doch um es gleich vorweg zu sagen: Die Sache ist so einfach nicht, der Teufel steckt wie immer im Detail, und zwar im Treiber.” … “Um ein internes, Hotplug-fähiges Raid aufzubauen, ist zunächst einiges an Recherche nötig. Dieser Artikel fasst die Ergebnisse einer solchen zusammen.”
Ich denke der Artikel dürfte zum Verständnis Deiner Probleme führen.
Dieser Tabelle:
kannst Du entnehmen, was mit Deiner Hardware möglich ist.
Im ersten Teil meines Blogs schreibe ich ja auch recht ausführlich was in meinem konkreten Fall zu tun war um das Optimum aus der bei mir vorhandenen Hardware herauszuholen. In meinem Fall wird ja AHCI mit HotPlug explizit verwendet, so das ich einen Plattenausfall durch das Entfernen des SATA Kabels problemlos testen kann und ein evtl. wirklich ausgefallenes Laufwerk im laufenden Betrieb austauschen kann. Echts HotPlug ist hier also möglich – aber nicht jedes SATA Setup kann das…
Und nicht entmutigen lassen. In dem referenzierten Artikel heißt es so schön:
“Ein internes Hotplug-fähiges SATA-Raid aufsetzen erfordert, die Hardware klug auszuwählen und die neueste Software einzusetzen. Die letzte Forderung visiert zudem ein bewegliches Ziel an. Seit längerem ändert sich von einer Kernelversion zur nächsten viel an den SATA-Treibern – in der Regel sind es Verbesserungen. Da heißt es auch für Admins, denen das Kunststück gelungen ist, ein Raid in Betrieb zu nehmen, stets am Ball zu bleiben – die in diesem Artikel genannten Links werden zum großen Teil liebevoll gepflegt. Als Lohn der Mühe winken Performance-Verbesserungen oder eine neue Teilfunktionalität.”
Das sagt mir SysLog dazu:
http://www.we-provide.de/syslog1.JPG
Achso noch eine Frage: Ich habe keine raidtab Datei im ordner /etc … wird diese nicht (mehr) benötigt oder muss man die nach einer Debian Installation immer per Hand hinzufügen?
Hallo Jonas, ich hoffe Du hast Verständnis, dass ich keinen zeitaufwendingen und kostenlosen Fern-Support für Deinen konkreten Einzelfall machen kann.
Hast Du denn schon mal in der o.g. Tabelle nachgeschaut, ob Deine Hardware es überhaupt können soll?
Ich kann Dir mit den o.g. Informationen nur einen Fingerzeig geben in welche Richtung Du recherchieren und bugtracken kannst. Ich wünsche Dir dabei viel Erfolg. Wenn Du etwas allg. gültiges herausgefunden hast, würde ich mich über einen Kommentar auf dieser Seite freuen, so dass ggf. auch andere Hilfesuchende den richtigen Fingerzeig bekommen können.
Die erste Zeile Deines Syslogs (“mdadm: SpareActive event detected on md device”) sagt laut man page aus: SpareActive = A spare component device which was being rebuilt to replace a faulty device as been successfully rebuild and has been made active.
Dieser Event passt eigentlich nicht so recht in Dein Szenario wo Du das SATA Kabel ziehst. Du siehst – es ist für mich quasi unmöglich mit den wenigen Infos konkret helfen zu können.
Danach wirft der Kernel diese ATA Fehler aus. Hierzu musst Du mal Google bemühen oder in einen spezialisierten Forum eine Anfrage starten. Tut mir leid, dass ich Dir hier nicht weiterhelfen kann.
Zu Deiner zweiten Frage:
“The old /etc/raidtab is completely ignored by the new mdadm package”…
Quelle: http://lwn.net/Articles/139887/
Okay trotzdem vielen Dank für die Hilfe.
Laut der Tabelle unterstützt meine Hardware dies.
Aber ich möchte jetzt hier niemanden mehr damit aufhalten. :-)
Danke für die vielen Tips.