Migration auf Software RAID1 mit SATA: Unterschied zwischen den Versionen
Niki (Diskussion | Beiträge) |
Niki (Diskussion | Beiträge) |
||
Zeile 40: | Zeile 40: | ||
# Einbau des SATA Controllers. Downtime: Ein reboot. Der Controller wurde anstandslos erkannt. | # 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 | + | # 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 === | ||
Zeile 60: | Zeile 60: | ||
;SWAP auf RAID1? | ;SWAP auf RAID1? | ||
: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. | :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 === | ||
+ | |||
+ | ==== Software Installation ==== | ||
+ | |||
+ | Im ersten Schritt wurde die passende Software installiert. Das ist mit Debian ja sehr einfach: | ||
+ | aptitude install mdadm | ||
+ | |||
+ | 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 ==== | ||
+ | |||
+ | Im zweiten Schritt habe ich auf sda mit fdisk die gewünschten Partitionen erstellt: | ||
+ | |||
+ | # fdisk -l /dev/sdb | ||
+ | |||
+ | Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes | ||
+ | 255 heads, 63 sectors/track, 121601 cylinders | ||
+ | Units = cylinders of 16065 * 512 = 8225280 bytes | ||
+ | Disk identifier: 0xa6c0462d | ||
+ | |||
+ | Device Boot Start End Blocks Id System | ||
+ | /dev/sdb1 1 1887 15157296 fd Linux raid autodetect | ||
+ | /dev/sdb3 1888 2435 4401810 fd Linux raid autodetect | ||
+ | /dev/sdb4 2436 121601 957200895 fd Linux raid autodetect | ||
+ | |||
+ | Wichtig ist dass die Partionen auf ID 0xFD stehen - Linux Software RAID autodetect, damit die LVMs automatisch beim Systemstart gefunden und eingerichtet werden. | ||
+ | |||
+ | Das "verkorkste" Layout hier ist keine Absicht - ich habe im Nachhinein noch die Partitionstabelle geändert. | ||
+ | |||
+ | Um die gleiche Partitionstabelle nun auf die zweite Platte zu übertragen habe ich | ||
+ | |||
+ | dd if=/dev/sda of=/dev/sdb bs=512 count=1 | ||
+ | |||
+ | verwendet. Wichtig ist danach ein | ||
+ | |||
+ | fdisk /dev/sdb | ||
+ | |||
+ | auszuführen und die Partitionstabelle mit "w" zu speichern, damit der Kernel die neue Partitionstabelle auch übernimmt. | ||
== Test == | == Test == |
Version vom 2. Mai 2009, 19:29 Uhr
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 Festplattenpreisen kein Problem mehr.
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.
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!
SATA Platte aus System entfernen:
echo x > /sys/bus/scsi/devices/0:0:0:0/delete
(0:0:0:0 durch das passende Device ersetzen)
Rescan eines Hosts (Platte müsste danach wieder in /dev erscheinen, ggf. unter anderem Namen):
echo "0 0 0" > /sys/class/scsi_host/host0/scan
(host0 durch den passenden Adapter ersetzen; bei SATA gibt es pro Port einen)
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
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.
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 das RAID habe ich mit minimaler Downtime geschafft.
Ist-Zustand
- 30 GB Barracuda an Primary Master. Darauf ist das System und per LVM /var
- 160 GB an Primary Slave. Darauf ist ein LVM mit den Daten (/home etc.) sowie den virtuellen OpenVZ-Servern (/vz)
- 320 GB an Secondary Master. Backup Platte
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
- Beide Platten mit 1TB gespiegelt
- Eine Systempartition (incl. /boot) auf RAID1 (ca. 15GB)
- Eine SWAP Partition auf RAID1 (ca. 15GB)
- Den Rest mit LVM auf RAID1. Dort sollen dynamisch die Daten rauf (/home) sowie die OpenVZ-Server etc.
Alle Bereiche der Platte sind nun durch eine idente RAID-Partition gespiegelt. Das hat den Vorteil dass wirklich beide Platten komplett ident sind.
- Systemroot
- Ursprünglich habe ich nicht gewusst dass Linux auch problemlos von einem Software RAID booten kann. Mit RAID autodetect kann sich aber der Systemroot problemlos auf einem RAID (md-Device) befinden. Debian liefert dazu die komplette Unterstützung mit: Das Paket mdadm fragt bereits, ob man von einem md-Device booten möchte und baut daraufhin eine neue initrd mit der benötigten Unterstützung.
- Bootpartition
- Ursprünglich wollte ich dann zwei separate Bootpartitionen haben, auf jeder Platte eine, und diese manuell synchronisieren. Aber das ist gar nicht notwendig. Lesend ist eine RAID Partition gleich ansprechbar wie das darunterliegende Dateisystem, da es sich nur durch den RAID-Superblock am Ende der Partition unterscheidet. Es kann also auch /boot problemlos in ein LVM aufgenommen werden; grub kann dann problemlos von der Partition lesen
- SWAP auf RAID1?
- 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
Software Installation
Im ersten Schritt wurde die passende Software installiert. Das ist mit Debian ja sehr einfach:
aptitude install mdadm
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
Im zweiten Schritt habe ich auf sda mit fdisk die gewünschten Partitionen erstellt:
# fdisk -l /dev/sdb Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0xa6c0462d Device Boot Start End Blocks Id System /dev/sdb1 1 1887 15157296 fd Linux raid autodetect /dev/sdb3 1888 2435 4401810 fd Linux raid autodetect /dev/sdb4 2436 121601 957200895 fd Linux raid autodetect
Wichtig ist dass die Partionen auf ID 0xFD stehen - Linux Software RAID autodetect, damit die LVMs automatisch beim Systemstart gefunden und eingerichtet werden.
Das "verkorkste" Layout hier ist keine Absicht - ich habe im Nachhinein noch die Partitionstabelle geändert.
Um die gleiche Partitionstabelle nun auf die zweite Platte zu übertragen habe ich
dd if=/dev/sda of=/dev/sdb bs=512 count=1
verwendet. Wichtig ist danach ein
fdisk /dev/sdb
auszuführen und die Partitionstabelle mit "w" zu speichern, damit der Kernel die neue Partitionstabelle auch übernimmt.
Test
Update der mdadm.conf:
mdadm --examine --scan >> /etc/mdadm/mdadm.conf
Kaputte Platten entfernen:
mdadm --manage /dev/md0 --remove failed
Neue Platte hinzufügen:
mdadm --manage /dev/md0 --add /dev/hdd1