Migration auf Software RAID1 mit SATA: Unterschied zwischen den Versionen
Niki (Diskussion | Beiträge) |
Niki (Diskussion | Beiträge) |
||
Zeile 29: | Zeile 29: | ||
== Die Migration auf RAID == | == Die Migration auf RAID == | ||
− | Die Migration auf das RAID habe ich mit minimaler Downtime geschafft | + | Die Migration auf das RAID habe ich mit minimaler Downtime geschafft. |
=== Ist-Zustand === | === Ist-Zustand === | ||
Zeile 36: | Zeile 36: | ||
* 160 GB an Primary Slave. Darauf ist ein LVM mit den Daten (/home etc.) sowie den virtuellen OpenVZ-Servern (/vz) | * 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 | * 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+5 Minuten. | ||
+ | |||
+ | === 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. | ||
== Test == | == Test == |
Version vom 2. Mai 2009, 19:22 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+5 Minuten.
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.
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