Wie Studien gezeigt haben, fallen Festplatten gleicher Fertigungscharge häufig kurz nacheinander aus. Wenn Sie also ein Raid-Array aus Gründen der Datensicherheit betreiben und eine Platte fällt aus, so können Sie, falls alle Platten gleichzeitig angeschafft wurden, fast sicher sein, dass kurz nach dem ersten Ausfall der zweite Ausfall folgen wird. Da leider Serverhersteller nicht davon zu überzeugen sind, Platten unterschiedlicher Chargen in Ihre Systeme einzubauen, sind hier Probleme vorprogrammiert.
Auch wir waren wiederholt von solchen Problemen betroffen. Und besonders problematisch ist eine solche Situation, wenn die zweite Raidplatte ausfällt, solange der Synchronisationsprozess noch nicht abgeschlossen ist – oder die zweite Platte schon bisher nicht aufgefallene Fehler aufweist, die eine Resynchronisation verhindern.
Genau dies ist uns in der letzten Woche passiert: Bei einem mit einem Linux-Software-Raid-1 versehenen System ist eine Platte ausgefallen. Die andere Platte übernahm reibungslos und die ausgefallene Platte wurde getauscht. Die Resynchronisation brach jedoch nach gut 24 Stunden – das System hatte eine recht hohe I/O-Last und die Platten waren jeweils 2TB groß – mit einem Lesefehler auf der „eigentlich“ gesunden zweiten Platte ab. Bei einem solchen Abbruch ist natürlich einerseits das System nicht komplett redundant, obwohl das Linux-Softwareraid anscheinend, wie Experimente gezeigt haben, die schon synchronisierten Plattenbereiche synchron hält. Andererseits ist es aber so mit dem Verwaltungswerkzeug mdadm nicht möglich, das Raid komplett wieder aufzubauen.
Eine Möglichkeit wäre es nun, das System herunterzufahren und mit klassischem „dd“ die Platten zu kopieren, hierbei die Lesefehler zu ignorieren und die beschädigte Platte nicht mehr in Betrieb zu nehmen. Auf Grund der Plattengröße hätte eine solcher Kopiervorgang jedoch sehr lange gedauert und sollte daher vermieden werden.
Glücklicherweise betrieben wir auf dem Raid-Array ein LVM2-System, also logische Volumes. Und somit war folgende Lösung möglich. Nennen wir der Einfachheit halber das alte Raid-System /dev/md1
- Einrichten eines neuen Raid-1-Systems mit fehlender Spiegelplatte auf der ersetzten Platte, also einrichten von /dev/md2
- Einrichten eines neuen physischen Volumes auf dem neuen, unvollständigen /dev/md2 mittels pvcreate
- Hinzufügen des neuen pvs zu der Volumegroup, zu der auch das andere, teildefekte Raidarray gehört mittels vgextend
- Verschieben aller logischen Volumes vom teildefekten physischen Volume auf das neue physische Volume mittels pvmove. Hierbei hatten wir sogar Glück, dass alle defekten Sektoren nicht belegt waren, also keine Lesefehler auftraten.
- Entfernen des defekten physischen Volumes aus der Volumegroup mittels vgreduce.
- Entfernen der LVM-Kennung auf dem defekten Raid mittls pvremove
- Stoppen des defekten Raid mittels mdadm –stop
Auf diese Weise kann dann die nun unbenutzte, defekte Platte getauscht und das Raid-Array dann wieder aufgebaut werden.
Damit ein solcher schleichender Tod einer Platte im Linux-Software-Raid möglichst früh auffällt, machen die meisten Distributionen einmal monatlich einen crontab-gesteuerten Abgleich der Platten. Hierbei werden alle Blöcke des Raid-Systems gelesen und miteinander abgeglichen. Doch fallen Sektoren zwischen diesen Abgleichen aus, fällt das natürlich dem System nur auf, wenn die Sektoren gelesen oder beschrieben werden.