chr.istoph, der Blog

Frage:

Ich habe durch Google Ihre Webseite gefunden, da ich Informationen brauchte. Und da dachte ich mir, vielleicht können sie mir Weiterhelfen.

z.Z benutze ich einen NAS Speicher zyxel-nsa-220
bin damit aber gar nicht mehr zufrieden.
Also dachte ich mir, mach ich doch nen Debian 7 Server und baue die Platte da rein. Leider laufen die Platten als JBOD soweit ich das gelesen habe ist das Kein RAID. Aber auf dem NAS ist es wohl mit „mdadm“ Konfiguriert und da dachte ich das muss auch unter Debian laufen.

Jetzt ist meine frage, ist es möglich die Platten wieder zu Mounten oder geht das gar nicht und ich müsste von den 2×1 TB Platten erst einmal ein
Backup machen ?

P.s: ich hoffe ich belästige sie nicht damit.

LG
Marco

Antwort:

Hallo Marco,
mit Freuden habe ich deine E-Mail erhalten und gebe Privat läuteten gerne Auskunft. Für alle Business Kunden verweise ich hier mal auf meinen Beratervertrag 😉
Zu erst mal ist deine Vermutung das JBOD kein Raid ist, völlig richtig. Die Übersetzung davon ist „Just a Bunch of Disks“, also: Nur ein Haufen Festplatten. Qeulle wikipedia.org

Das Problem was du hast ist das dein Kernel/initrd vor /dev/sda booten wird und nicht von einem MD Device wie /dev/md0. Um das umzustellen habe ich folgende einfachen Ansatz.
Du machst eine Neuinstallation auf der zweiten Platte und gibst bei der Installation, während der Partitionierung an, das du ein RAID erstellen möchtest lässt aber deine aktuelle Systemplatte aus (Spare). Nach der Installation kannst du deine Daten von der dann alten Systemplatte auf die neu installierte Platte kopieren und anschließend die Platte ins RAID mit aufnehmen. Dafür empfehle ich dir den MBR mittels sfdisk zu kopieren.
sfdisk -d /dev/sdX > /dev/sdY
Quelle: Partitionstabelle-sichern
Dann kannst du die Platte, nach einem Reboot, mittels mdadm --add /dev/md0 /dev/sdX1 in den Verbund mit aufnehmen.

Grundsätzlich geht das auch ohne Neuinstallation ist aber nicht ganz trivial.

Gruß Christoph

Vergangene Woche hatte ich das Problem, das ein Server mit einem degraded Raid nicht mehr Booten konnte. Dort erschien folgende Frage die nach 15 Sekunden Timontete und in initramfs landete.

Do you wish to start the degraded RAID? [y/N]:

Damit diese Abfrage nicht mehr kommt, kann man folgende Einstellung vornehmen.
/etc/initramfs-tools/conf.d/mdadm
BOOT_DEGRADED=true


Danach muss man die initramfs neu bauen:
update-initramfs -k all -u

Bei einem Server reagierte während des Dialoges die Tastaturabfrage nicht. Diese könne ich umgehen indem ich im GRUB die Option bootdegraded hinter die initrd Zeile geschrieben habe.
Quelle: SoftwareRAID

Vor einem Jahr habe ich wegen Performance Problemen im Forum mal Leitungstest mit dem IO Scheduler gemacht. Meine Testumgebung dafür war ein Syncendes RAID. Da ich gerade festgestellt habe das ich diesen Artikel nie veröffentlicht habe stelle ich ihn hier mal online. Leider habe ich vergessen zu Dokumentiert mit welchem Kernel ich das gemacht habe. Dem entsprechend muss das was ich hier gemacht habe eh noch mal wiederholt werden.

Mittels speed_limit habe ich das Syncen der HDs auf Maximum gestellt.

Dann habe ich den Scheduler verstellt.
cat /sys/block/sd*/queue/scheduler

Dabei kamm folgendes raus:

deadline 5500K/sec
noop 5200K/sec
anticipatory 45000K/sec
cfq 39000K/sec

Wobei ich von cfq sehr erschrocken war. Und dies bei Gelegenheit unter anderen umstehenden noch mal überprüfen werde.

(Geschreiben am: 17.02.2010)

Beim starten des md Raid waren 2 Platten beim Starten nicht hochgekommen.

# mdadm --stop /dev/md0
mdadm: stopped /dev/md0
# mdadm --assemble /dev/md0 /dev/sda2 /dev/sdb2 /dev/sdc2 /dev/sdd2
mdadm: cannot open device /dev/sdb2: Device or resource busy
mdadm: /dev/sdb2 has no superblock - assembly aborted

Sie wurden bereits benutzt. Allerdings nicht von eine Userspace Programm / Mount wie fuser „nicht anzeigt“.
# fuser -v /dev/sdb2

An dieser Stelle haben wir vermutet das es sich um ein Fake Raid handelt. Also mal einen Blick in die device mapper blockdevices werfen…
# dmsetup table
isw_ddjcbgeaib_Volume12: 0 1875395970 linear 252:0 78124095
isw_ddjcbgeaib_Volume11: 0 78124032 linear 252:0 63
isw_ddjcbgeaib_Volume1: 0 3907039744 striped 2 256 8:16 0 8:48 0

# ls -l /dev/sdb
brw-rw---- 1 root disk 8, 16 2011-08-03 23:32 /dev/sdb

In der Tat /dev/sdb wird von device mapper verwendet.

Um das Fake Raid aufzulösen haben wir die brachial Methode genommen. Hier wird mit dem Devicemapper alle Einstellungen Deaktiviert. Somit sind die platten wieder freigegeben.

# dmsetup remove_all
# dmsetup table
No devices found

Anschießend konnte das md Software Raid wieder ordentlich gestartet werden
# mdadm --assemble /dev/md0 /dev/sda2 /dev/sdb2 /dev/sdc2 /dev/sdd2
mdadm: /dev/md0 has been started with 4 drives.

Im Endeffekt hat auf die Platten ein „Facke Raid“ mittels dmraid zugegriffen. Was auch erklärt warum die „Partitionen für den Kernel verschwunden“ waren.

apt-get autoremove dmraid

Da debian squeeze Software Raid 1 bei der Installation nicht unterstützt habe ich gerade selber Hand anlegen müssen.

Zuerst habe ich das System ganz normal installiert. Die Plattenzuordnung habe ich im installer festlegen lassen.

Device Boot Start End Blocks Id System
/dev/sda1 1 120122 964879933+ fd Linux raid autodetect
/dev/sda5 120123 121601 11880036 82 Linux swap / Solaris

Nach der Installation habe ich mdadm installiert und Einstellungen in der fstab von sda nach md0 vorgenommen und mittels
mdadm --create --verbose /dev/md0 --auto=yes --level=1 --raid-devices=2 missing /dev/sda1

Anschließend habe ich das System neu gestartet und noch mal von der Installation CD in den Rescue modus gewechselt. Dort konnte ich über
mdadm --add /dev/mdxx /dev/sdb1
die fehlende Platte hinzufügen.
Nach dem Syncen der Platten habe ich das System vom Raid 1 gestartet und den Bootloader Grub noch auf beiden Platten installiert.