Wie es der Zufall (und die Hardware) so will, sind wir bei uns in der Firma dabei, einen neuen Server anzuschaffen - nach aktueller Planung auch ein AMD Epyc. Aufgrund einiger Vorkommnisse in der Vergangenheit halten wir es für sinnvoll, von Hardware-RAID auf Software-RAID umzusteigen, jedenfalls auf der neuen Maschine.
Ist-Zustand:
- Hardware-RAID durch LSI-basierten Controller (8300 XLP), 2x 2 HDDs jeweils im RAID-1
- Ubuntu 14.04
- Grub Legacy
- Root-Partition ext3
Ziel-Zustand auf der neuen Maschine:
- Software-RAID, 2x 2 SSDs mit insgesamt 4x RAID-1 (root, repos, home und daten)
- Ubuntu 14.04 - ja, es ist uns bekannt und bewusst, dass dessen Support in einigen Monaten endet, aber für die Aufgabenstellung spielt das keine Rolle (und Systemupgrade oder Neuinstallation fällt aktuell aus)
- Grub2
- Root-Partition ext4
Mein bisher ausgetüfteltes Vorgehen sieht grob so aus:
Diese Schritte habe ich schon erfolgreich in zwei VMs nachvollzogen. Alles funktioniert soweit.
- Auf dem bestehenden System Pakete grub2 & mdadm installieren und einstellen, damit RAID zur Verfügung steht und davon gebootet werden kann.
- Image des bestehenden Systems erstellen mit fsarchiver, von einem Live-System aus
- Neue Maschine mit Live-System booten
- dort die nötigen Partitionen erstellen
- mit mdadm die RAIDs über die erstellten Partitionen erzeugen
- Image des alten Systems mit fsarchiver in das RAID als ext4 wiederherstellen
- update-grub, grub-install in alle am RAID beteiligten Platten, mdadm.conf erzeugen, update-initramfs -u
- Kleinigkeiten wie UUIDs in der fstab anpassen usw.
Dennoch habe ich einige Fragen, die ich im Vorfeld klären möchte:
- Gehe ich recht in der Annahme, dass ein fsck auf /dev/md/root korrekt ist, wenn das ext4 dort liegt?
- Funktioniert TRIM sauber, wenn auf den SSDs ein oder mehrere RAID-1 liegen? Bisher habe ich gelesen, dass TRIM wohl ab Kernel 3.7 oder 3.8 durch das mdadm (RAID-1) durchgereicht wird.
- Auf welches Device oder Dateisystem muss man ein fstrim anwenden? Ist dort ebenfalls /dev/md/root richtig?
- Die Nummerierung von mdadm ist ... wie formuliere ich das möglichst höflich... dämlich. Geht das irgendwie so zu gestalten, dass die Devices DETERMINISTISCH nummeriert werden? Mal ist die Root-Partition /dev/md127, dann wieder /dev/md126 (/dev/md/root ist ja nur ein Symlink, der auf eines der beiden zeigt).
Warum ist das wichtig? Die Ausgaben von mount und df zeigen /dev/md127 und /dev/md126. Das an sich ist schon unschön, weil man immer erst prüfen/überlegen muss, wofür die Nummer nun aktuell grade steht. Außerdem greift Munin auf diese Ausgaben zurück, sodass nach jedem Reboot die Devices vertauscht sein können, was zu Änderungen an den Graphen führt - sowas geht gar nicht! Am liebsten wäre mir, wenn die Ausgaben von mount und df so gestaltet werden könnten, dass dort /dev/md/root und /dev/md/repos als Device/Dateisystem zu sehen sind. Wo kann/muss ich da eingreifen? mdadm, udev oder woanders?
- Gibt es noch weitere Dinge zu beachten oder bestimmte Fallstricke?
Grüße
Dalai
Ergebnis 1 bis 10 von 10
-
27.06.2018, 19:45 Beitrag #1 ↑Grand Admiral
Themenstarter
Special
- Registriert seit
- 14.06.2004
- Ort
- Meiningen, Thüringen
- Beiträge
- 6.993
- Danke
- 390
- Danke
- 49
Umzug von Hardware-RAID auf Software-RAID
-
28.06.2018, 05:45 Beitrag #2 ↑
wenn deine rstelltes rais als md126 oder 127 etc erkannt wird hast du einen wichtigen schritt nach dem erstellen vergessen.
Code:#benötigte programme installieren apt-get install initramfs-tools mdadm #partitionen und raid erstellen wie angedacht, wenn die gesamte Platte genutzt werden soll empfiehlt es sich ganz auf Partitionen zu verzichten. mdadm --create /dev/mdX --level=1 --raid-devices=2 /dev/sdX /dev/sdY #mdadm config schreiben mdadm --detail --scan > /etc/mdadm/mdadm.conf #tramfs updaten damit die raidpartionen auch nach einem reboot den namen behalten update-initramfs -u
Auch wenn du von einem Raid booten willst oder bestimmte Ordner einfach vom raid gemoiuntet werden sollen muss dies in der fstab stehen. dort sollte immer die UUID des jeweiligen raids eingetragen sein und keine namen der devices. Helfen tut dir da das programm "blkid"
Ein Eintrag sieht dann wie folgt aus:
Code:UUID=<BLKID> /ZIELVERZEICHNIS ext4 defaults 0 1
Filesystemchecks etc immer auf der /dev/mdX anwenden nie auf den einzelnen Platten des Raids.
mdadm macht jeden ersten Sonntag eines Monats einen ausführlichen raidcheck mit resync. also nicht wundern wenn da die load oder festplattenauslastung hochgeht.Geändert von tspoon (28.06.2018 um 06:49 Uhr)
-
28.06.2018, 16:33 Beitrag #3 ↑Grand Admiral
Themenstarter
Special
- Registriert seit
- 14.06.2004
- Ort
- Meiningen, Thüringen
- Beiträge
- 6.993
- Danke
- 390
- Danke
- 49
Danke für deine Antwort!
Nein, vergessen habe ich das nicht. Die mdadm.conf existiert und enthält die richtigen Angaben:Code:ARRAY /dev/md/root metadata=1.2 UUID=blah-blub
For version 1.2 superblocks, the preferred way to create arrays is by using a name instead of a number. For example, if the array is your home partition, then creating the array with the option --name=home will cause the array to be assembled with a random device number (which is what you are seeing now, when an array doesn't have an assigned number we start at 127 and count backwards), but there will be a symlink in /dev/md/ that points to whatever number was used to assemble the array. The symlink in /dev/md/ will be whatever is in the name field of the superblock. So in this example, you would have /dev/md/home that would point to /dev/md127 and the preferred method of use would be to access the device via the /dev/md/home entry.Zitat von tspoon
.
Und hinzu kommt noch die nicht deterministische Vergabe der Nummern beim Booten, wenn mehrere RAID Arrays vorhanden sind, wie schon erwähnt. Munin ist also nicht das einzige, was hier Probleme bekommt, sondern auch der Nutzer. Momentan sehe ich nur die Möglichkeit, die RAID Arrays mit Namen zu erstellen, sie aber als /dev/md0, /dev/md1 usw. in der mdadm.conf einzubinden. Dann sind die Namen vorhanden und die Nummern fest. Bescheuert bleibt es dennoch.
Bezüglich der Devices statt Partitionen: Nachdem ich anfing zu lesen, wie (man mit) mdadm arbeitet, hab ich mich gefragt "Warum zum Teufel verwenden die alle Partitionen und nicht gleich das ganze Device für das RAID?", aber die Antwort ist einfach: Eine Ersatzplatte muss mindestens genauso groß sein wie die im RAID. Ist das nicht der Fall, klappt der Rebuild/Resync nicht. Daher werden wir auf Verwendung ganzer Devices verzichten und stattdessen einzelne Partitionen benutzen, die eine definierbare Größe haben. Ich hab ja schon die Zahl der RAID Arrays auf die nötigen reduziert; es waren ursprünglich 6, aber es stellte sich heraus, dass 4 ausreichen.
Ein Eintrag sieht dann wie folgt aus:
Code:UUID=<BLKID> /ZIELVERZEICHNIS ext4 defaults 0 1
Ein Trim musst du eigentlich nicht von Hand auslösen, da sollte sich die SSDs selbst drum kümmern.
Filesystemchecks etc immer auf der /dev/mdX anwenden nie auf den einzelnen Platten des Raids.
mdadm macht jeden ersten Sonntag eines Monats einen ausführlichen raidcheck mit resync. also nicht wundern wenn da die load oder festplattenauslastung hochgeht.
Grüße
Dalai
-
29.06.2018, 03:30 Beitrag #4 ↑
achso du hast deine raids namen geben und keine nummer zB /dev/md0.
das ist natürlich etwas ungewöhnlich und macht man eigentlich nicht, dafür gibt es LABEL für die Platten oder Partitonen.
mount beherrscht auch dies. https://wiki.ubuntuusers.de/Labels/
dennoch sollte "update-initramfs -u" dafür sorgen, das linux die raidpartitions-namen Bsp: /dev/md0 nicht vergisst nach einem reboot.
was in der mdadm.cnf steht ist fast egal da mdadm ein scan beim start macht und versucht alle raids die es erkennt zustarten.
raids die es nicht eindeutig kennt, werden dann mit nummern ab /dev/md126 versehen.
mit den "trim per hand" mein ich das dies zum beispiel ubuntu von sich aus macht. es sollte sich also kümmern wenn eine ssd im system erkannt wird.
Automatisches TRIM ab Ubuntu 14.04 LTS
Mit Ubuntu 14.04 wurde ein wöchentlicher automatischer TRIM bei einigen SSD eingeführt. Dazu wird die Datei fstrim im Verzeichnis /etc/cron.weekly erstellt, die wiederum das Skript fstrim-all ausführt. Dieses durchläuft alle aktiven Dateisysteme auf der Suche nach einer SSD. Stellt es fest, dass sich ein oder mehrere Dateisysteme auf einer SSD befinden, wird fstrim automatisch gestartet.
Automatisches TRIM ab Ubuntu 14.10
Mit Ubuntu 14.10 wird ein wöchentliches, automatisches TRIM ausgeführt. Dazu gibt es das Skript fstrim im Verzeichnis /etc/cron.weekly, das wiederum /sbin/fstrim startet. Man kann dieses Skript, wie unter TRIM_per_Batched_Discard TRIM per Batched Discard beschrieben, ändern, so dass man die dort beschriebene Log-Datei erhält:Geändert von tspoon (29.06.2018 um 03:33 Uhr)
-
29.06.2018, 05:14 Beitrag #5 ↑Grand Admiral
Themenstarter
Special
- Registriert seit
- 14.06.2004
- Ort
- Meiningen, Thüringen
- Beiträge
- 6.993
- Danke
- 390
- Danke
- 49
Die Namen der Arrays sind von den Nummern unabhängig. Naja, nicht ganz, denn wenn man einen "Namen" wie "1" vergibt, wird das Array automatisch als /dev/md1 erscheinen.
das ist natürlich etwas ungewöhnlich und macht man eigentlich nicht, dafür gibt es LABEL für die Platten oder Partitonen.
Labels der Dateisysteme sind eine andere Baustelle. Natürlich haben die Dateisysteme selbst eine Bezeichnung, aber die hat erstmal keine Beziehung zum RAID Array. Die Benennung der Arrays hilft auch sehr dabei, in einem Live-System die einzelnen Teile der Arrays zu finden, unabhängig davon, ob und welche Dateisysteme darin enthalten sind.
mount beherrscht auch dies. https://wiki.ubuntuusers.de/Labels/
dennoch sollte "update-initramfs -u" dafür sorgen, das linux die raidpartitions-namen Bsp: /dev/md0 nicht vergisst nach einem reboot.
was in der mdadm.cnf steht ist fast egal da mdadm ein scan beim start macht und versucht alle raids die es erkennt zustarten.
raids die es nicht eindeutig kennt, werden dann mit nummern ab /dev/md126 versehen.
mit den "trim per hand" mein ich das dies zum beispiel ubuntu von sich aus macht. es sollte sich also kümmern wenn eine ssd im system erkannt wird.
Grüße
Dalai
-
29.06.2018, 07:54 Beitrag #6 ↑
Im Grunde hättest du hier statt fsarchiver auch einfach rsync nehmen können, genauer gesagt rsync -av.
Wenn du dein root als bind irgendwo mountest, dann kannst du das sogar aus dem laufenden System heraus machen, also z.B.
Code:mount / /mnt/oldroot -o bind rsync -av --exclude=lost+found /mnt/oldroot/ /mnt/newroot
[*]update-grub, grub-install in alle am RAID beteiligten Platten, mdadm.conf erzeugen, update-initramfs -u
Wenn sie dracut nutzen, dann vermutlich über /etc/dracut.conf oder /etc/dracut.conf.d oder evtl. auch /etc/default/
[*]Gehe ich recht in der Annahme, dass ein fsck auf /dev/md/root korrekt ist, wenn das ext4 dort liegt?
[*]Funktioniert TRIM sauber, wenn auf den SSDs ein oder mehrere RAID-1 liegen? Bisher habe ich gelesen, dass TRIM wohl ab Kernel 3.7 oder 3.8 durch das mdadm (RAID-1) durchgereicht wird.
[*]Auf welches Device oder Dateisystem muss man ein fstrim anwenden? Ist dort ebenfalls /dev/md/root richtig?
Code:discard/nodiscard Controls whether ext4 should issue discard/TRIM commands to the underlying block device when blocks are freed. This is useful for SSD devices and sparse/thinly-provisioned LUNs, but it is off by default until sufficient testing has been done.
[*]Die Nummerierung von mdadm ist ... wie formuliere ich das möglichst höflich... dämlich. Geht das irgendwie so zu gestalten, dass die Devices DETERMINISTISCH nummeriert werden? Mal ist die Root-Partition /dev/md127, dann wieder /dev/md126 (/dev/md/root ist ja nur ein Symlink, der auf eines der beiden zeigt).
Aber ja, ein bisschen unschön ist das schon, war auch einer der Gründe, weshalb ich von mdadm auf btrfs gewechselt bin (aber bei weitem nicht der wichtigste).
[*]Gibt es noch weitere Dinge zu beachten oder bestimmte Fallstricke?
Zudem unbedingt bei grub die geladenen Module überprüfen sowie die ids, die in der cmdline stehen.
-
29.06.2018, 15:41 Beitrag #7 ↑Grand Admiral
Themenstarter
Special
- Registriert seit
- 14.06.2004
- Ort
- Meiningen, Thüringen
- Beiträge
- 6.993
- Danke
- 390
- Danke
- 49
Theoretisch. Praktisch leider nicht so einfach möglich. Das vorhandene System nutzt wie schon gesagt einen 8300 XLP, was ein PCI-X Controller ist. Laut megacli unterstüzt der Controller keine SSDs. Situation ist also, dass der Controller nicht einfach in den neuen Server mitgenommen werden kann, da der kein PCI-X hat (Risiko mal außen vor gelassen) und die SSDs des neuen nicht einfach im alten System benutzt werden können.
Also muss das System irgendwie übers Netzwerk übertragen werden. Ja, rsyncd wäre noch ein Weg, aber auf die kurze Downtime für die Erzeugung des Image (30 Min oder sowas) kommt's auch nicht mehr an, zumal fsarchiver sowieso der bisher benutzte Weg zur Sicherung der Linux-Systeme ist.
Hier musst du sicherstellen, dass die Treiber für den software raid auch in der initrd drin sind. Leider kann ich dir da bei Ubuntu nichts dazu sagen, wie man das macht.
Wenn sie dracut nutzen, dann vermutlich über /etc/dracut.conf oder /etc/dracut.conf.d oder evtl. auch /etc/default/
Eigentlich ist das nichts, was du selbst machen solltest, vielmehr ist das Aufgabe des Dateisystems und kann über die Mountoptionen eingestellt werden.
Wenn du fixe Nummern haben willst musst du das in der mdadm.conf eintragen. So hängt es halt davon ab welches von mdadm zuerst geladen wird.
Zudem unbedingt bei grub die geladenen Module überprüfen sowie die ids, die in der cmdline stehen..
Grüße
Dalai
-
29.06.2018, 23:16 Beitrag #8 ↑
Ok, wenn du die SSD nicht anschließen kannst geht es natürlich nicht. Davon bin ich eigentlich erst mal ausgegangen. Aber ist auch egal.
Das funktioniert automatisch. Nachdem das Paket mdadm installiert wurde, steht das Modul zur Verfügung und kann mit in die initrd eingebaut werden (weiß jetzt nicht, ob die sogar automatisch neu gebaut wird).
Wenn deine Distribution das alles so eingerichtet hat, dann ist das gut möglich, dass es automatisch und korrekt umgesetzt wurde, aber sicher kann man da nicht sein (es sei denn man hat es schon mal ausprobiert).
Ich erinnere mich auch an einen Fall, ich glaube da habe ich eine root Partition für Fedora ausgetauscht, da musste ich das auch manuell einstellen, weil er neue Treiber nicht automatisch eingebunden hat.
Ja, ich kenne die Mount-Option discard. Da ich sie aber nicht benutzen möchte, weil sie mir zu unsicher ist (wie die Manpage und das UU Wiki sagen), und weil auf dem Server permanent viele sehr kleine Dateien geschrieben werden, wird das vermutlich zu einem Leistungseinbruch führen. Auf einem Desktop oder Laptop wäre es wohl egal. Auf dem existierenden NAS mit SSD (ist nicht der alte Server aus dem OP) habe ich damals in Ubuntu 12.04 das fstrim so in den Cron eingetragen, dass die Ausgabe davon in einem Log landet. Das möchte ich auf dem neuen Server auch haben. Deswegen meine Frage nach dem "Ziel" des fstrim.
Oder geht es dur nur um Fehleranfälligkeit?
gut, da kann ich zu ext4 nichts sagen, aber mit btrfs nutze ich discard inzwischen seit 6 oder 7 Jahren ohne Probleme und ext4 ist ja eigentlich deutlich älter als btrfs.
Generell bin ich mit ext4 nie wirklich grün geworden. Zu oft hatte ich Datenverlust auf den Datenträgern auf denen ich es eingesetzt habe (meist externe Festplatten).
-
29.06.2018, 23:53 Beitrag #9 ↑Grand Admiral
Themenstarter
Special
- Registriert seit
- 14.06.2004
- Ort
- Meiningen, Thüringen
- Beiträge
- 6.993
- Danke
- 390
- Danke
- 49
Deswegen mach ich bei solchen großen Dingen, mit denen ich bisher nichts zu tun hatte, vorher Tests, um mich einerseits damit vertraut zu machen und andererseits eine Anleitung für mich zusammenzuschreiben, die ich dann am Produktivsystem benutzen kann.
hm, da sehe ich jetzt den Vorteil nicht. Wenn dir discard zu unsicher ist, dann darfst du eigentlich gar kein trim verwenden, auch nicht per cron job.
Ich bin in vielerlei Hinsicht konservativ, jedenfalls was Software, Hardware, Dateisysteme und das Zusammenspiel von Hard- & Software angeht. Denn wenn es Probleme gibt, will ich etwas zu dem Problem finden können und nicht einer der ersten sein, der damit konfrontiert ist und schnell eine Lösung finden muss (die fast nie schnell umgesetzt werden kann).
Grüße
Dalai
-
30.06.2018, 11:06 Beitrag #10 ↑
Wenn der trim Befehl genutzt wird, dann kann ein Verschlüsselungslayer in der Ebene über dem Dateisystem kompromittiert werden. Ein entsprechender Proof-of-Concept existiert.
Aus dem Schema, welches durch das Trimmen auf der Festplatte entsteht können mindestens Rückschlüsse auf das verwendete Dateisystem, ggf. aber auch mehr geschlossen werden.
Es besteht also ggf. ein Sicherheitsrisiko, weshalb meines Wissens der trim Befehl nur eingeschränkt empfohlen wird.
Dazu kommt, dass es Performanceprobleme geben kann, wenn eben – wie von dir befürchtet – der trim Befehl immer sofort ausgeführt wird.
Allerdings würde es mich wurdern, wenn die SSDs das einfach so ausführen würden. Wahrscheinlicher ist, dass die trim Befehle gesammelt und dann irgendwann in einem ausgeführt werden. d.h. nicht so anders als mit fstrim.
Insbesondere vor dem Hintergrund, dass Windows ja scheinbar auch trim Befehle schickt und viele SSDs mit Windows betrieben werden.