-Nuke-
Well-Known Member
Heyho,
ich finde solche Berichte immer spannend und lehrreich, darum schreibe ich auch mal einen.
Hier mal ein Bericht über meinen Weg, das RAIDZ2 auf meinem Server neu zu machen, um effizient mehr Speicher zu bekommen. Ergo: 4 weitere Platten hinzufügen. Dazu muss das RAID komplett neu aufgebaut werden. Daher müssen die Daten ja irgendwo hin. Knapp 8TB in der Summe.
Zum Glück hatte ich noch einen älteren Server, der 9TB fassen konnte. Der musste zwar erst mal durchs halbe Land transportiert werden, aber schließlich war er da. Leider war das RAIDZ1 im System nicht zusammengefasst. Es waren also zwei Pools. Weiterhin ging der Server auch nicht so den Weg des "Best Practise". Raw Disc ohne Partition, unsinnige Labels und ashift von 9.
Also als erstes den alten Server komplett neu machen, das RAID dort neu aufbauen in "richtig". Dazu habe ich erst mal die Daten die nicht schon auf meinem neuen Server waren, auf ihn Übertragen. Mit rsync. Wie sich herausgestellt hat war der alte Athlon II X2 mit der Verschlüsselung von SSH sehr stark überfordert. Knapp 50MB/s und 90% CPU Last. Aber egal, zweiten rsync-Prozress gestartet, nun zwei mal 50M/s und der Lüfter heulte
Dann das RAID neu gemacht. Erst mal mit zpool destroy, glabel destroy und gpart destroy um mich geworfen und alles gesäubert. Die gpt Labels waren nun die Seriennummer der Festplatten und die Größe der Partition war so groß wie minimal angegeben. D.h.
usw. So kann man beim Defekt sorglos die Platte tauschen. Anschließend einen großen Pool erzeugt aus 2 raidz1. Ist nötig, weil dort 3x1.5TB und 3x3TB verbaut ist.
Nun müssen die Daten ja wieder rüber, damit ich meinen neuen Server neu machen kann. Da ich ja nun gelernt habe, dass für die alte CPU die SSH-Verschlüsselung keine NOOP ist, habe ich den Weg über netcat genommen.
Auf dem Empfänger also folgendes gestartet:
Auf dem Sender nun erst mal einen Snapshot gemacht:
Und nun rüber mit den Daten:
Das dauerte nun etwas über einen Tag.
Nun liest man im Netz so einige Horrorgeschichten über zfs send und recv... Berichte von kaputten Pools nach der Übertragung, die ZFS nicht bemerkt. Kaputte Datenstrukturen etc. pp. Auch wenn ich nicht vermutet habe, dass mir das passiert, weil der Bericht schon etwas älter war und vllt falsch ausgeführt wurde, wollte ich auf Nummer sicher gehen. Ich wollte alle Daten auf meinem Pool katalogisieren und mit ihrer SHA512 Checksumme vermerken. Das war nach langem hin und her dann doch möglich (der print0 Parameter war die Magie) :
So kann ich nach der Übertragung prüfen ob alles richtig ist:
Das dauert dann zwar wieder eine halbe Ewigkeit, aber sicher ist sicher!
Jetzt waren die Daten also auf dem zweit-Server. Somit also die Platten in den neuen Server einbauen und das RAID im gleichen Sinne neu aufbauen, nur auf dem neuen Server.
Da ich aber nun auf dem neuen Pool die Daten global mit lz4 Kompression speichern wollte, konnte ich natürlich nun nicht einfach wieder zfs send/recv nehmen. Also ein aderer Weg, der nicht rsync ist, wegen der Performance.
Der Weg hieß zunächst tar.
Auf dem Empfänger also folgendes gestartet:
Auf dem Sender nun:
So, das brach nun nach einer ganzen Weile ab, weil ihn ein paar Sonder/Steuerzeichen in einigen Dateinamen wohl durcheinander gebracht hat. Zumindest wurde mir ein korrupter tar-Header um die Ohren geworfen. Ich hab mich dann erst mal auf die Suche nach Dateien gemacht, welche irgendwelche Sonderzeichen beinhalten. Das konnten eigentlich gar nicht so viele sein. Also:
Das zeigt natürlich auch Datein an welche ein äöüß usw. im Namen haben. Aber wie vermutet, war das jetzt nicht die Welt und einige wenige Dateien hatten wirklich noch irgendwelche Copy&Paste Steuerzeichen drin (Windows kriegt sowas immer toll hin!). Naja, jetzt wollte ich aber nicht wieder tar nehmen, weil der hätte ja von vorne angefangen. Also geschaut, wie ich ggf. rsync beschleunigen kann. Und es ging sogar!
Die "arcfour" Verschlüsselung tat der schwachen CPU im anderen Server besser und ich erreichte auch mit rsync so 95-110MB/s.
So, damit war der Umzug abschlossen. Die globale lz4 Kompression sparte in etwa 30GB ein. Das ist jetzt bei knapp noch 13TB freien Speicher sicherlich nicht die Welt, aber warum verschenken? Jetzt läuft noch die Checksummenprüfung, aber bisher ist alles i.O. Aber das hab ich bei dem zuletzt verwendeten rsync auch erwartet.
Als Sidenote:
Die Inbetriebnahme des SAS Controllers stellte sich dann doch etwas als Herausforderung heraus. Das BIOS/EFI stellte nach dem Einbau mal einfach das Booten ein. Nach dem BIOS-Boot Auswahl-Menü passierte einfach nichts, egal von was man booten wollte. Nach kurzer Recherche liegt es wohl daran, dass es zu viele Option ROMs gab. Mit SATA Controller auf dem Board, der SAS-Karte, der zwei GBit NICs auf dem Board und USB war das wohl übergelaufen. Ich hatte dann das Booten von den NICs und das PCIe Option ROM im EFI deaktiviert und dann fuhr das System wenigstens hoch. Als erste Maßnahme hab ich dem Controller auch gleich das aktuelle BIOS aufgespielt und mit einem Trick auch gleich das interne RAID-Zeug ausgetrieben. Anschließend hat FreeBSD den Controller und die Platten daran tadellos erkannt.
ich finde solche Berichte immer spannend und lehrreich, darum schreibe ich auch mal einen.
Hier mal ein Bericht über meinen Weg, das RAIDZ2 auf meinem Server neu zu machen, um effizient mehr Speicher zu bekommen. Ergo: 4 weitere Platten hinzufügen. Dazu muss das RAID komplett neu aufgebaut werden. Daher müssen die Daten ja irgendwo hin. Knapp 8TB in der Summe.
Zum Glück hatte ich noch einen älteren Server, der 9TB fassen konnte. Der musste zwar erst mal durchs halbe Land transportiert werden, aber schließlich war er da. Leider war das RAIDZ1 im System nicht zusammengefasst. Es waren also zwei Pools. Weiterhin ging der Server auch nicht so den Weg des "Best Practise". Raw Disc ohne Partition, unsinnige Labels und ashift von 9.
Also als erstes den alten Server komplett neu machen, das RAID dort neu aufbauen in "richtig". Dazu habe ich erst mal die Daten die nicht schon auf meinem neuen Server waren, auf ihn Übertragen. Mit rsync. Wie sich herausgestellt hat war der alte Athlon II X2 mit der Verschlüsselung von SSH sehr stark überfordert. Knapp 50MB/s und 90% CPU Last. Aber egal, zweiten rsync-Prozress gestartet, nun zwei mal 50M/s und der Lüfter heulte
Dann das RAID neu gemacht. Erst mal mit zpool destroy, glabel destroy und gpart destroy um mich geworfen und alles gesäubert. Die gpt Labels waren nun die Seriennummer der Festplatten und die Größe der Partition war so groß wie minimal angegeben. D.h.
Code:
gpart add -a 4K -s 3000000000000B -t freebsd-zfs -l WD-12345 ada0Nun müssen die Daten ja wieder rüber, damit ich meinen neuen Server neu machen kann. Da ich ja nun gelernt habe, dass für die alte CPU die SSH-Verschlüsselung keine NOOP ist, habe ich den Weg über netcat genommen.
Auf dem Empfänger also folgendes gestartet:
Code:
nc -l 8080 | zfs receive -vFd datatankAuf dem Sender nun erst mal einen Snapshot gemacht:
Code:
zfs snapshot -r datatank@migrationUnd nun rüber mit den Daten:
Code:
zfs send -R datatank@migration | nc 192.168.123.30 8080Das dauerte nun etwas über einen Tag.
Nun liest man im Netz so einige Horrorgeschichten über zfs send und recv... Berichte von kaputten Pools nach der Übertragung, die ZFS nicht bemerkt. Kaputte Datenstrukturen etc. pp. Auch wenn ich nicht vermutet habe, dass mir das passiert, weil der Bericht schon etwas älter war und vllt falsch ausgeführt wurde, wollte ich auf Nummer sicher gehen. Ich wollte alle Daten auf meinem Pool katalogisieren und mit ihrer SHA512 Checksumme vermerken. Das war nach langem hin und her dann doch möglich (der print0 Parameter war die Magie) :
Code:
find /datatank/ -type f -print0 | xargs -0 shasum -a 512 -b >> ~/datatank.sha512So kann ich nach der Übertragung prüfen ob alles richtig ist:
Code:
shasum -c ~/datatank.sha512Das dauert dann zwar wieder eine halbe Ewigkeit, aber sicher ist sicher!
Jetzt waren die Daten also auf dem zweit-Server. Somit also die Platten in den neuen Server einbauen und das RAID im gleichen Sinne neu aufbauen, nur auf dem neuen Server.
Da ich aber nun auf dem neuen Pool die Daten global mit lz4 Kompression speichern wollte, konnte ich natürlich nun nicht einfach wieder zfs send/recv nehmen. Also ein aderer Weg, der nicht rsync ist, wegen der Performance.
Der Weg hieß zunächst tar.
Auf dem Empfänger also folgendes gestartet:
Code:
nc -l 8080 | tar -xpf -Auf dem Sender nun:
Code:
tar -cf - /datatank | nc 192.168.123.30 8080So, das brach nun nach einer ganzen Weile ab, weil ihn ein paar Sonder/Steuerzeichen in einigen Dateinamen wohl durcheinander gebracht hat. Zumindest wurde mir ein korrupter tar-Header um die Ohren geworfen. Ich hab mich dann erst mal auf die Suche nach Dateien gemacht, welche irgendwelche Sonderzeichen beinhalten. Das konnten eigentlich gar nicht so viele sein. Also:
Code:
find . | perl -ne 'print if /[^[:ascii:]]/'Das zeigt natürlich auch Datein an welche ein äöüß usw. im Namen haben. Aber wie vermutet, war das jetzt nicht die Welt und einige wenige Dateien hatten wirklich noch irgendwelche Copy&Paste Steuerzeichen drin (Windows kriegt sowas immer toll hin!). Naja, jetzt wollte ich aber nicht wieder tar nehmen, weil der hätte ja von vorne angefangen. Also geschaut, wie ich ggf. rsync beschleunigen kann. Und es ging sogar!
Code:
rsync -avP -e "ssh -c arcfour" FreeBSDServer:/datatank/music /datatank/Die "arcfour" Verschlüsselung tat der schwachen CPU im anderen Server besser und ich erreichte auch mit rsync so 95-110MB/s.
So, damit war der Umzug abschlossen. Die globale lz4 Kompression sparte in etwa 30GB ein. Das ist jetzt bei knapp noch 13TB freien Speicher sicherlich nicht die Welt, aber warum verschenken? Jetzt läuft noch die Checksummenprüfung, aber bisher ist alles i.O. Aber das hab ich bei dem zuletzt verwendeten rsync auch erwartet.
Als Sidenote:
Die Inbetriebnahme des SAS Controllers stellte sich dann doch etwas als Herausforderung heraus. Das BIOS/EFI stellte nach dem Einbau mal einfach das Booten ein. Nach dem BIOS-Boot Auswahl-Menü passierte einfach nichts, egal von was man booten wollte. Nach kurzer Recherche liegt es wohl daran, dass es zu viele Option ROMs gab. Mit SATA Controller auf dem Board, der SAS-Karte, der zwei GBit NICs auf dem Board und USB war das wohl übergelaufen. Ich hatte dann das Booten von den NICs und das PCIe Option ROM im EFI deaktiviert und dann fuhr das System wenigstens hoch. Als erste Maßnahme hab ich dem Controller auch gleich das aktuelle BIOS aufgespielt und mit einem Trick auch gleich das interne RAID-Zeug ausgetrieben. Anschließend hat FreeBSD den Controller und die Platten daran tadellos erkannt.
Weil wenn ich einen gzip-9 Pool habe, dann kann es sein, dass die Daten auf einem nicht-gzip-9 Pool gar nicht draufpassen.
