Migration auf Software RAID1 mit SATA - Versionsgeschichte

Niki am 2. Mai 2009 um 20:54 Uhr

2009-05-02T20:54:31Z

Niki am 2. Mai 2009 um 20:26 Uhr

2009-05-02T20:26:48Z

Niki am 2. Mai 2009 um 20:16 Uhr

2009-05-02T20:16:33Z

Niki am 2. Mai 2009 um 20:15 Uhr

2009-05-02T20:15:06Z

Niki: hat „SATA RAID“ nach „Migration auf Software RAID1 mit SATA“ verschoben

2009-05-02T20:08:04Z

hat „SATA RAID“ nach „Migration auf Software RAID1 mit SATA“ verschoben

Niki am 2. Mai 2009 um 20:07 Uhr

2009-05-02T20:07:02Z

Niki: /* Migration von /home */

2009-05-02T20:04:52Z

Migration von /home

Niki: /* Konfiguration von grub */

2009-05-02T20:03:27Z

Konfiguration von grub

Niki: /* Migrieren der OpenVZ VEs */

2009-05-02T20:02:35Z

Migrieren der OpenVZ VEs

Niki am 2. Mai 2009 um 20:01 Uhr

2009-05-02T20:01:02Z

@@ Zeile 8: / Zeile 8: @@
-== Das System ==
+= Das System =
 Auf dem Host System kommt Debian Lenny zum Einsatz. Zu beachten ist dass das RAID-Howto mit den "alten" RAID-Tools arbeitet; in Debian ist jedoch nur mehr das Tool '''mdadm''' enthalten.
@@ Zeile 19: / Zeile 19: @@
-== Der Controller ==
+= Der Controller =
 Als SATA Controller habe ich mich für den '''Promise SATA300 TX2''' entschieden. Der Controller wird lückenlos von Linux unterstützt, das Modul '''sata_promise''' ist im Standardkernel enthalten. Es wird soweit ich weiss TCQ/NCQ unterstützt und es wird Hot-Plugging unterstützt!
@@ Zeile 35: / Zeile 35: @@
 Ich habe auch bereits probiert eine Platte im RAID einfach rauszuziehen; das System ist problemlos weitergelaufen. Nach einem Bus-Rescan wurde die Platte wieder gefunden und problemlos wieder ins RAID eingefügt. Bei dieser Konstellation kann ich also - wie bei einem Hardware RAID - im laufenden Betrieb die Festplatten austauschen und eine Platte kann auch ohne Absturz des Systems kaputt werden.
-== Die Festplatten ==
+= Die Festplatten =
 Zum Einsatz kommen zwei idente Samsung Spinpoint F2EG mit jeweils 1GB und langsamen 5400rpm. Die "Ecoline" hat den Vorteil dass sie wirklich sehr wenig Strom verbrauchen.
@@ Zeile 41: / Zeile 41: @@
 Leider habe ich nicht beachtet dass die Platten normalerweise von unterschiedlichen Herstellern sein sollten falls ich einem Serienfehler zum Opfer fallen sollte.
-== Die Migration auf RAID ==
+= Die Migration auf RAID =
 Die Migration auf das RAID habe ich mit minimaler Downtime geschafft.
-=== Ist-Zustand ===
+== Ist-Zustand ==
 * 30 GB Barracuda an Primary Master. Darauf ist das System und per LVM /var
@@ Zeile 51: / Zeile 51: @@
 * 320 GB an Secondary Master. Backup Platte
-=== Vorbereitungen ===
+== Vorbereitungen ==
 # Einbau des SATA Controllers. Downtime: Ein reboot. Der Controller wurde anstandslos erkannt.
 # Einbau der SATA Platten (etwas später weil ich den Controller früher hatte). Die Platten wurden anstandslos als sda und sdb erkannt. Downtime: Ein reboot.
-=== Soll-Zustand ===
+== Soll-Zustand ==
 * Beide Platten mit 1TB gespiegelt
@@ Zeile 75: / Zeile 75: @@
 :Auch SWAP wollte ich ursprünglich separat auf jede Platte legen (mit gleicher Priorität). Aber das ist gar keine gute Idee, da beim Ausfall einer Platte das System abstürzen würde. Meine Experimente mit dem "Platten einfach herausziehen" hätte das System sofort mit einem Absturz quittiert. Swap auf RAID1 ist zwar ein bisschen langsamer, aber da Swap ohnehin um 10er-Potenzen langsamer ist als der RAM Zugriff ist diese minimale Differenz vernachlässigbar, da ist mir die Systemstabilität dann doch wichtiger. Und auch das Argument mit dem Speicherplatz zählt bei zwei 1TB Platten nicht mehr wirklich.
-=== Die Migration ===
+== Die Migration ==
-==== Software Installation ====
+=== Software Installation ===
 Im ersten Schritt wurde die passende Software installiert. Das ist mit Debian ja sehr einfach:
@@ Zeile 84: / Zeile 84: @@
 Auf die Frage "Für das Wurzelverzeichnis benötigte MD Verbünde" habe ich "all" gewählt. Das ist wichtig weil sich mein System nun auf einem RAID1 befinden wird. Die letzten Fragen habe ich ebenfalls standard gewählt (monatliche Konsistenzprüfung sowie Monitoring-Daemon).
-==== Partitionierung ====
+=== Partitionierung ===
 Im zweiten Schritt habe ich auf sda mit fdisk die gewünschten Partitionen erstellt:
@@ Zeile 114: / Zeile 114: @@
 auszuführen und die Partitionstabelle mit "w" zu speichern, damit der Kernel die neue Partitionstabelle auch übernimmt.
-==== Erstellung der RAID Devices ====
+=== Erstellung der RAID Devices ===
 Die drei RAIDs wurden wie folgt erstellt:
@@ Zeile 128: / Zeile 128: @@
 Ein cat /proc/mdstat sagt nun, dass das Array synchronisiert wird.
-==== Migrieren der OpenVZ VEs ====
+=== Migrieren der OpenVZ VEs ===
 Im ersten Schritt möchte ich die virtuellen Server auf das RAID migrieren. Deshalb erstelle ich gleich das LVM auf /dev/md1:
@@ Zeile 174: / Zeile 174: @@
   lvremove /dev/vgdata/vserver
-==== Migration von /home ====
+=== Migration von /home ===
 Als nächstes kommt /home an die Reihe. Da /home groß ist möchte ich nicht alle VEs die /home verwenden herunterfahren. Die Maildirs liegen auf /home; so habe ich den Mailserver heruntergefahren und meinen Backup MX auf slave.nobaq.net gestartet. Auf den anderen Servern habe ich lediglich alle Dienste beendet die die Datenintegrität auf /home gefährden würden.
@@ Zeile 203: / Zeile 203: @@
 Noch ist ein problemloser Reboot des ganzen Systems möglich, da erst die Daten auf die neuen Platten kopiert wurden.
-==== Migration von swap ====
+=== Migration von swap ===
 Der nächste Schritt, der swap ist relativ einfach:
@@ Zeile 213: / Zeile 213: @@
 ...sowie wieder die /etc/fstab ändern.
-==== Migration des Systems ====
+=== Migration des Systems ===
 Der letzte Schritt - Das Kopieren des Root-Systems müsste normalerweise mit einer Boot-CD ausgeführt werden, damit das System in einem konsistentem Zustand kopiert wird. Da aber am Hostsystem ohnehin keine Services mehr laufen habe darauf verzichtet und direkt kopiert.
@@ Zeile 224: / Zeile 224: @@
 Vor dem reboot muss allerdings noch der Bootloader (grub) konfiguriert werden.
-==== Konfiguration von grub ====
+=== Konfiguration von grub ===
 Wie ich bereits oben erwähnt habe, kann Linux auch einem RAID Device gestartet werden, sofern durch die Installation von mdadm bereits eine passende initrd erstellt worden ist. Im Prinzip muss also nur der root-Parameter geändert werden:
@@ Zeile 263: / Zeile 263: @@
   grub-install /dev/disk/by-id/scsi-SATA_SAMSUNG_HD103SIS1VSJ1KS300505
-=== Ausbau der alten Platten ===
+== Ausbau der alten Platten ==
 Es folgt ein reboot bei dem man sich davon überzeugen kann dass das neue Setup funktioniert. Im letzten Schritt wird das System heruntergefahren und die alten PATA-Platten ausgebaut. Downtime: ca. 5 Minuten.
-== Test ==
+= Test =
 Mit einem echten Hardware-Test habe ich gleich sowohl die Hot-Plugging Fähigkeit als auch das RAID getestet: Ich habe einfach im laufenden Betrieb eine der beiden Platten abgestöpselt!
@@ Zeile 302: / Zeile 302: @@
 Der Test hat mir also gezeigt: Gleich wie bei einem professionellen Hardware RAID kann eine Platte im laufenden Betrieb ausfallen ohne das System zu beeinträchtigen! Und noch besser: Im laufenden Betrieb kann die Platte ausgetauscht werden.
-<comments />
+= Kommentare =
 [[Kategorie:Weblog]]
 [[Kategorie:Linux]]

@@ Zeile 301: / Zeile 301: @@
 Der Test hat mir also gezeigt: Gleich wie bei einem professionellen Hardware RAID kann eine Platte im laufenden Betrieb ausfallen ohne das System zu beeinträchtigen! Und noch besser: Im laufenden Betrieb kann die Platte ausgetauscht werden.
 [[Kategorie:Weblog]]
 [[Kategorie:Linux]]

← Nächstältere Version		Version vom 2. Mai 2009, 20:16 Uhr
Zeile 1:		Zeile 1:
	<section begin="head" />		<section begin="head" />
		+	[[Bild:tux.png\|left]]
	Nachdem der Festplattenspeicherplatz auf meinem Server langsam aber doch zu Neige ging habe ich mich entschlossen gleich auf SATA umzurüsten und ein RAID1 aufzusetzen. Das ist bei den heutigen Festplattenpreisen kein Problem mehr. Ich erhoffe mir dadurch einerseits erhöhte Performance (durch SATA und den neuen Platten) und andererseits erhöhte Ausfallsicherheit.		Nachdem der Festplattenspeicherplatz auf meinem Server langsam aber doch zu Neige ging habe ich mich entschlossen gleich auf SATA umzurüsten und ein RAID1 aufzusetzen. Das ist bei den heutigen Festplattenpreisen kein Problem mehr. Ich erhoffe mir dadurch einerseits erhöhte Performance (durch SATA und den neuen Platten) und andererseits erhöhte Ausfallsicherheit.

← Nächstältere Version		Version vom 2. Mai 2009, 20:15 Uhr
Zeile 10:		Zeile 10:

	Auf dem Host System kommt Debian Lenny zum Einsatz. Zu beachten ist dass das RAID-Howto mit den "alten" RAID-Tools arbeitet; in Debian ist jedoch nur mehr das Tool '''mdadm''' enthalten.		Auf dem Host System kommt Debian Lenny zum Einsatz. Zu beachten ist dass das RAID-Howto mit den "alten" RAID-Tools arbeitet; in Debian ist jedoch nur mehr das Tool '''mdadm''' enthalten.
		+
		+	Ein kurzes Wort noch zu Software RAID vs. Fake-RAID: Obwohl praktisch alle verfügbaren SATA Controller vorgeben RAID-Controller zu sein, sind diese in Wirklichkeit keine. Ähnlich wie bei Win-Modems oder GDI-Druckern managed das gesamte RAID der Treiber in Software und damit die CPU. Lediglich die Administration geschieht über das BIOS des Controllers. Damit kann natürlich ein RAID System sehr konstengünstig hergestellt werden.
		+
		+	Vorteile bietet das System gegenüber Linux Software RAID aber kaum (erst Recht nicht bezüglich Geschwindigkeit), ganz im Gegenteil: Die Systeme sind proprietär. Mit Linux Software RAID ist es nicht nur egal welchen Controller ich verwende sondern sogar egal wo die Blockdevices liegen mit denen ich das RAID zusammenbastle. So kann durchaus ein RAID zusammen aus SCSI, FC oder IDE Platten bestehen. Ausserdem ist es im Falle des Falles sehr einfach zu seinen Daten zu gelangen: Eine Linux Software RAID Partition kann read-only direkt mit dem darunterliegenden Dateisystem gemountet werden und so im Notfall von einem anderen System (das kein RAID kann) gelesen werden.
		+
		+	Faker-RAID wird für die meisten Controller zwar mit dem Programm '''dmraid''' unterstützt (dieses mappt lediglich die Platten zu md-Devices). Ich rate aber eindringlich dazu auf diesen Marketing-Gag zu verzichten und das Linux Software-RAID zu verwenden.
		+

	== Der Controller ==		== Der Controller ==

← Nächstältere Version		Version vom 2. Mai 2009, 20:07 Uhr
Zeile 293:		Zeile 293:

	Der Test hat mir also gezeigt: Gleich wie bei einem professionellen Hardware RAID kann eine Platte im laufenden Betrieb ausfallen ohne das System zu beeinträchtigen! Und noch besser: Im laufenden Betrieb kann die Platte ausgetauscht werden.		Der Test hat mir also gezeigt: Gleich wie bei einem professionellen Hardware RAID kann eine Platte im laufenden Betrieb ausfallen ohne das System zu beeinträchtigen! Und noch besser: Im laufenden Betrieb kann die Platte ausgetauscht werden.
		+
		+	[[Kategorie:Weblog]]
		+	[[Kategorie:Linux]]

← Nächstältere Version	Version vom 2. Mai 2009, 20:08 Uhr
(kein Unterschied)

@@ Zeile 180: / Zeile 180: @@
 Die neuen Einträge in der fstab lauten nun:
-  #/dev/vgdata/lvhome             /home                     xfs             defaults,noatime 1 2
+  #/dev/vgdata/lvhome    /home     xfs      defaults,noatime 1 2
-  /dev/raid1/home                 /home                     xfs                     defaults,noatime        1 2
+  /dev/raid1/home        /home     xfs      defaults,noatime 1 2
 Nun werden alle VEs heruntergefahren die /home benutzen und das neue /home gemountet. Die alte VE kann ggf. wieder entfernt werden:

@@ Zeile 222: / Zeile 222: @@
   title radix (OpenVZ) [Debian lenny, sda]
           root (hd0,0)
-          kernel /boot/vmlinuz-2.6.26-2-openvz-686 root=/dev/md0 apm=off console=tty0 console=ttyS0,9600n8
+          kernel /boot/vmlinuz-2.6.26-2-openvz-686 root=/dev/md0 \
           read-only
           initrd /boot/initrd.img-2.6.26-2-openvz-686
@@ Zeile 230: / Zeile 231: @@
   title radix (OpenVZ) [Debian lenny, sdb]
           root (hd1,0)
-          kernel /boot/vmlinuz-2.6.26-2-openvz-686 root=/dev/md0 apm=off console=tty0 console=ttyS0,9600n8
+          kernel /boot/vmlinuz-2.6.26-2-openvz-686 root=/dev/md0 \
           read-only
           initrd /boot/initrd.img-2.6.26-2-openvz-686

@@ Zeile 130: / Zeile 130: @@
   vgcreate raid1 /dev/md1
-Dieser Befehl sagt, dass das Physical Volume auf /dev/md1 zur Volume Group "raid1" gehören soll. Schließlich wird der eigentliche Datenbereich - das Logical Volume erstellt. Für die VServer reichen vorerst 50GB, durch LVM und ext3 kann der Bereich ja im Nachhinein problemlos erweitert werden.
+Dieser Befehl sagt, dass das Physical Volume auf /dev/md1 zur Volume Group "raid1" gehören soll. Schließlich wird der eigentliche Datenbereich - das Logical Volume erstellt. Für die VServer reichen vorerst 50GB, durch LVM und ext3 kann dr Bereich ja im Nachhinein problemlos erweitert werden.
   lvcreate -L +50G --name vz raid1
@@ Zeile 154: / Zeile 154: @@
 Nachdem alle VEs kopiert waren, habe ich die neue in die fstab eingetragen:
-  #/dev/vgdata/vserver            /var/lib/vz/private             ext3            defaults,noatime,acl 1 1
+  #/dev/vgdata/vserver   /var/lib/vz/private   ext3    defaults,noatime,acl 1 1
-  /dev/raid1/vz                   /var/lib/vz/private             ext3            defaults,noatime,acl 1 1
+  /dev/raid1/vz          /var/lib/vz/private   ext3    defaults,noatime,acl 1 1
 Nun noch einmal alle VEs beenden (am besten ganz OpenVZ), die Partition ummounten und die alte LV entfernen:

← Nächstältere Version		Version vom 2. Mai 2009, 20:01 Uhr
Zeile 1:		Zeile 1:
		+	<section begin="head" />
	Nachdem der Festplattenspeicherplatz auf meinem Server langsam aber doch zu Neige ging habe ich mich entschlossen gleich auf SATA umzurüsten und ein RAID1 aufzusetzen. Das ist bei den heutigen Festplattenpreisen kein Problem mehr. Ich erhoffe mir dadurch einerseits erhöhte Performance (durch SATA und den neuen Platten) und andererseits erhöhte Ausfallsicherheit.		Nachdem der Festplattenspeicherplatz auf meinem Server langsam aber doch zu Neige ging habe ich mich entschlossen gleich auf SATA umzurüsten und ein RAID1 aufzusetzen. Das ist bei den heutigen Festplattenpreisen kein Problem mehr. Ich erhoffe mir dadurch einerseits erhöhte Performance (durch SATA und den neuen Platten) und andererseits erhöhte Ausfallsicherheit.

	Hier beschreibe ich nun, wie ich mein altes System (PATA) auf das neue SATA-Software RAID System migriert habe. Bemerkenswert: Fast die gesamte Migration konnte ich von unterwegs mit ssh in einer screen-Session durchführen. Lediglich zum Einbau des SATA Controllers und der Platten musste ich den Server besuchen.		Hier beschreibe ich nun, wie ich mein altes System (PATA) auf das neue SATA-Software RAID System migriert habe. Bemerkenswert: Fast die gesamte Migration konnte ich von unterwegs mit ssh in einer screen-Session durchführen. Lediglich zum Einbau des SATA Controllers und der Platten musste ich den Server besuchen.
		+	<section end="head"/>