Vielen Dank für das Feedback. Der Ausfall ist jetzt eine Woche her und ich würde gerne resümieren.
Die Ursache war definitiv mehrgleisig. Zuerst einmal war der dümmste Fehler anzunehmen, dass das ZIL auf SSDs die Schreibgeschwindigkeit der im ZFS vorliegenden HDDs ausreichend erhöht. Das gilt wohl nur für synchrone Schreibvorgänge. Asynchrone IO geht mehr oder weniger direkt auf die HDDs durch. Zusätzlich stimme ich Neobin zu, die Backup-Struktur machte wenig Sinn und diese sollte auch nur übergangsweise (die Firma zieht demnächst um, am neuen Standort gibt es Glasfaser) etabliert werden. Dadurch war die verfügbare IO für die Backupvorgänge definitiv zu gering. Insbesondere da diese ohne Backup-Server nicht inkrementell ablaufen.
Der ZFS Pool bestehend aus 2x10 TB (WD Green), 2x 3 TB (WD RED), 2x 2 TB ZIL NVMe SSD (Intel) konnte die bei den Backups oder Restores entstehende IO also nicht aushalten. Das könnte zu IO-Timeouts geführt haben. Diese haben das Filesystem korrumpiert. Generell sollte das vermieden werden. Ich würde den telefonischen Vorschlag weiterempfehlen: OS auf kleine SSDs, VMs auf SSD Pools, Backups auf eigenen Pools (SSD / HDD). Der gravierendste Fehler war es Backups, VMs und Betriebssystem in den gleichen Pool ohne Einschränkung der IO zu legen. Bitte macht diesen Fehler nicht nach
Hinzu kommt, dass die 2x 3 TB WD Red, die ich nach der Recovery zu einem eigenen Pool zusammengefasst habe, um dort temporär VMs auszulagern, ebenfalls Probleme gemacht haben. Beim Migrieren der Festplatten in diesen Pool gab es einen kompletten Absturz des Systems. Offenbar liegt in diesen Platten ein Fehler vor, der gewisse Schreibaufgaben plötzlich auf mehrere Minuten hin verzögert. Da diese Festplatten auch Teil des alten Pools war, kann ich nicht ausschließen, dass dieser Fehler nicht auch maßgeblich zum gesamten Ausfall beigetragen hat. Die Festplatten habe ich entfernt.
Ich habe auch gelesen, dass man unterschiedliche WD bei Raid-Controllern gerne Probleme machen. Ob das auch bei ZFS zutrifft, weiß ich nicht. Könnte aber auch mitgewirkt haben. Zu guter Letzt, hätte ein Proxmox-Backup-Server mit inkrementellen Backups das Problem vermutlich auch eingeschränkt, da dann die IO nicht grenzwertig geworden wäre.
Für die interessierten erkläre ich noch das Recovery und den weiteren Plan:
1. Schritt - Datensicherung vor weiteren Ausfällen
Ich habe alle VMs heruntergefahren, um weitere Datenausfälle zu vermeiden. Die IO der VM Festplatten habe ich dann auf 30M beschränkt. Backups habe ich ebenfalls auf 30M beschränkt. Aus Consumer Hardware (eine SSD + eine USB HDD 4 TB) und einem kleinen PC habe ich einen Proxmox-Backup-Server hochgezogen. Danach habe ich jede VM separat hochgefahren, überprüft, ggf. wiederhergestellt und dann auf den neuen Backup-Server gesichert. (Zum Glück war Wochenende, das hat ewig gedauert).
2. Schritt - Umbau des Systems
Die ganzen alten Backups wollte ich nicht verlieren. Da diese nur auf die 10 TB Platten passen, habe ich beschlossen den rpool auf diese 10 TB Platten einzuschränken. Linux sollte auf 2 ollen HDDs zusammen mit 8 TB Backups klarkommen. Zuerst habe ich also die 2x2TB SSD, die als ZIL im ZFS waren, aus dem Pool entfernt und daraus einen neuen Pool erstellt. Ich nenne ihn "black". Auf black ist jedoch nicht genug Platz für alle VMs. Also habe ich dort die zwei wichtigsten VMs hin transferiert.
Danach war im Hauptpool genug Platz, um die 2x3 TB WD RED zu entfernen. Diese habe ich zum "red" Pool zusammengeschlossen. Dort sollten die unwichtigen VMs ihren Platz finden, bis neue Hardware eingetroffen ist. Leider ist bei der Migration vom rpool nach red das System erneut zusammengebrochen. Scans haben ergeben, dass die WD RED wohl defekt sind. Da inzwischen Samstagnacht war, musste ich improvisieren. Ich hatte noch 4x1TB SATA SSDs. Als Mirror Pool würde der Speicher nicht ausreichen, daher habe ich diese als RAIDZ1 in den ZFS Pool "blue" zusammengefasst. Das ist für die SSDs nicht optimal, aber besser als nichts. Dort habe ich die restlichen VMs hin migriert.
Danach habe ich das System erneut auf den backup-server gesichert, hochgefahren und es läuft seit dem stabil. Die Backups gehen jetzt täglich auf den Consumer-Hardware-Backup-Server. IO-Delay im Schnitt kleiner 2 %.
3. Schritt - Finalisierung des Setups (Ongoing)
Bei einem Online-Hoster habe ich einen Server bestellt und dort ebenfalls ein Proxmox-Backup-Server eingerichtet. Schrittweise ziehe ich aktuell die VM-Backups dorthin um (1.5M Upload...). Die inkrementellen Backups unter der Woche, schafft die Leitung hoffentlich. Wenn nicht, lasse ich mir etwas Neues einfallen. Ich habe neue SSD Festplatten bestellt und werde diese bei Ankunft für das Betriebssystem einsetzen und auch den blue-pool entsprechend wieder abbauen. Die 10 TB HDD verlassen den Server für Schritt 4. Das PVE wird vermutlich einmal komplett neu installiert, damit die Boot-Partitionen auf den richtigen Festplatten liegen und der rpool seine (bis dahin dann 4) Indirektionen wieder loswird.
4. Schritt - Lokale Replikation (Zukunft)
Es wird ein kleiner Server bestellt, 2x64 GB SSD, 16 GB Ram. Dort werden die 2x10 TB Platten eingebaut. Auf diesen Server wird eine lokale Replikation der VM-Festplatten (etwa alle 2h) eingestellt. Bei einem Totalausfall des Hauptservers können dort die zwei wichtigsten VMs (wenn auch eingeschränkt) hochgefahren werden, bis der Totalausfall beseitigt ist. Die anderen VMs liegen aber dort zusätzlich im ausgeschalteten Zustand für eine Rückmigration bereit. Dadurch ist der Datenausfall im Worst-Case auf 2h beschränkt und die Firma bleibt im Fall der Fälle eingeschränkt arbeitsfähig.
Dieses Setup sollte dann wohl ausreichen, bis die Firma in das neue Gebäude umgezogen ist. Mit Glasfaser eröffnen sich dann ganz neue Möglichkeiten. Vielleicht transferiere ich dann alle VMs in die Cloud und stelle nur noch den Domain-Controller lokal zur Verfügung.
Summe der Dinge:
Ein Wochenende Arbeit, viele Ausgaben für neue Hardware, zwei schlaflose Nächte. Positiv: Viel Neues gelernt, die Vorzüge von ZFS besser zu schätzen gelernt und ich würde mich jetzt als Proxmox-Fan bezeichnen.
Ich danke allen für Ihre Hilfe und hoffe, ich kann euch vor meinen Fehlern bewahren. Insbesondere empfehle ich euch, von vorneherein, Proxmox-Backup in Betracht zu ziehen, wenn ihr Proxmox-VE einsetzt. Die Kombination ist einfach genial.
Die Ursache war definitiv mehrgleisig. Zuerst einmal war der dümmste Fehler anzunehmen, dass das ZIL auf SSDs die Schreibgeschwindigkeit der im ZFS vorliegenden HDDs ausreichend erhöht. Das gilt wohl nur für synchrone Schreibvorgänge. Asynchrone IO geht mehr oder weniger direkt auf die HDDs durch. Zusätzlich stimme ich Neobin zu, die Backup-Struktur machte wenig Sinn und diese sollte auch nur übergangsweise (die Firma zieht demnächst um, am neuen Standort gibt es Glasfaser) etabliert werden. Dadurch war die verfügbare IO für die Backupvorgänge definitiv zu gering. Insbesondere da diese ohne Backup-Server nicht inkrementell ablaufen.
Der ZFS Pool bestehend aus 2x10 TB (WD Green), 2x 3 TB (WD RED), 2x 2 TB ZIL NVMe SSD (Intel) konnte die bei den Backups oder Restores entstehende IO also nicht aushalten. Das könnte zu IO-Timeouts geführt haben. Diese haben das Filesystem korrumpiert. Generell sollte das vermieden werden. Ich würde den telefonischen Vorschlag weiterempfehlen: OS auf kleine SSDs, VMs auf SSD Pools, Backups auf eigenen Pools (SSD / HDD). Der gravierendste Fehler war es Backups, VMs und Betriebssystem in den gleichen Pool ohne Einschränkung der IO zu legen. Bitte macht diesen Fehler nicht nach
Hinzu kommt, dass die 2x 3 TB WD Red, die ich nach der Recovery zu einem eigenen Pool zusammengefasst habe, um dort temporär VMs auszulagern, ebenfalls Probleme gemacht haben. Beim Migrieren der Festplatten in diesen Pool gab es einen kompletten Absturz des Systems. Offenbar liegt in diesen Platten ein Fehler vor, der gewisse Schreibaufgaben plötzlich auf mehrere Minuten hin verzögert. Da diese Festplatten auch Teil des alten Pools war, kann ich nicht ausschließen, dass dieser Fehler nicht auch maßgeblich zum gesamten Ausfall beigetragen hat. Die Festplatten habe ich entfernt.
Ich habe auch gelesen, dass man unterschiedliche WD bei Raid-Controllern gerne Probleme machen. Ob das auch bei ZFS zutrifft, weiß ich nicht. Könnte aber auch mitgewirkt haben. Zu guter Letzt, hätte ein Proxmox-Backup-Server mit inkrementellen Backups das Problem vermutlich auch eingeschränkt, da dann die IO nicht grenzwertig geworden wäre.
Für die interessierten erkläre ich noch das Recovery und den weiteren Plan:
1. Schritt - Datensicherung vor weiteren Ausfällen
Ich habe alle VMs heruntergefahren, um weitere Datenausfälle zu vermeiden. Die IO der VM Festplatten habe ich dann auf 30M beschränkt. Backups habe ich ebenfalls auf 30M beschränkt. Aus Consumer Hardware (eine SSD + eine USB HDD 4 TB) und einem kleinen PC habe ich einen Proxmox-Backup-Server hochgezogen. Danach habe ich jede VM separat hochgefahren, überprüft, ggf. wiederhergestellt und dann auf den neuen Backup-Server gesichert. (Zum Glück war Wochenende, das hat ewig gedauert).
2. Schritt - Umbau des Systems
Die ganzen alten Backups wollte ich nicht verlieren. Da diese nur auf die 10 TB Platten passen, habe ich beschlossen den rpool auf diese 10 TB Platten einzuschränken. Linux sollte auf 2 ollen HDDs zusammen mit 8 TB Backups klarkommen. Zuerst habe ich also die 2x2TB SSD, die als ZIL im ZFS waren, aus dem Pool entfernt und daraus einen neuen Pool erstellt. Ich nenne ihn "black". Auf black ist jedoch nicht genug Platz für alle VMs. Also habe ich dort die zwei wichtigsten VMs hin transferiert.
Danach war im Hauptpool genug Platz, um die 2x3 TB WD RED zu entfernen. Diese habe ich zum "red" Pool zusammengeschlossen. Dort sollten die unwichtigen VMs ihren Platz finden, bis neue Hardware eingetroffen ist. Leider ist bei der Migration vom rpool nach red das System erneut zusammengebrochen. Scans haben ergeben, dass die WD RED wohl defekt sind. Da inzwischen Samstagnacht war, musste ich improvisieren. Ich hatte noch 4x1TB SATA SSDs. Als Mirror Pool würde der Speicher nicht ausreichen, daher habe ich diese als RAIDZ1 in den ZFS Pool "blue" zusammengefasst. Das ist für die SSDs nicht optimal, aber besser als nichts. Dort habe ich die restlichen VMs hin migriert.
Danach habe ich das System erneut auf den backup-server gesichert, hochgefahren und es läuft seit dem stabil. Die Backups gehen jetzt täglich auf den Consumer-Hardware-Backup-Server. IO-Delay im Schnitt kleiner 2 %.
3. Schritt - Finalisierung des Setups (Ongoing)
Bei einem Online-Hoster habe ich einen Server bestellt und dort ebenfalls ein Proxmox-Backup-Server eingerichtet. Schrittweise ziehe ich aktuell die VM-Backups dorthin um (1.5M Upload...). Die inkrementellen Backups unter der Woche, schafft die Leitung hoffentlich. Wenn nicht, lasse ich mir etwas Neues einfallen. Ich habe neue SSD Festplatten bestellt und werde diese bei Ankunft für das Betriebssystem einsetzen und auch den blue-pool entsprechend wieder abbauen. Die 10 TB HDD verlassen den Server für Schritt 4. Das PVE wird vermutlich einmal komplett neu installiert, damit die Boot-Partitionen auf den richtigen Festplatten liegen und der rpool seine (bis dahin dann 4) Indirektionen wieder loswird.
4. Schritt - Lokale Replikation (Zukunft)
Es wird ein kleiner Server bestellt, 2x64 GB SSD, 16 GB Ram. Dort werden die 2x10 TB Platten eingebaut. Auf diesen Server wird eine lokale Replikation der VM-Festplatten (etwa alle 2h) eingestellt. Bei einem Totalausfall des Hauptservers können dort die zwei wichtigsten VMs (wenn auch eingeschränkt) hochgefahren werden, bis der Totalausfall beseitigt ist. Die anderen VMs liegen aber dort zusätzlich im ausgeschalteten Zustand für eine Rückmigration bereit. Dadurch ist der Datenausfall im Worst-Case auf 2h beschränkt und die Firma bleibt im Fall der Fälle eingeschränkt arbeitsfähig.
Dieses Setup sollte dann wohl ausreichen, bis die Firma in das neue Gebäude umgezogen ist. Mit Glasfaser eröffnen sich dann ganz neue Möglichkeiten. Vielleicht transferiere ich dann alle VMs in die Cloud und stelle nur noch den Domain-Controller lokal zur Verfügung.
Summe der Dinge:
Ein Wochenende Arbeit, viele Ausgaben für neue Hardware, zwei schlaflose Nächte. Positiv: Viel Neues gelernt, die Vorzüge von ZFS besser zu schätzen gelernt und ich würde mich jetzt als Proxmox-Fan bezeichnen.
Ich danke allen für Ihre Hilfe und hoffe, ich kann euch vor meinen Fehlern bewahren. Insbesondere empfehle ich euch, von vorneherein, Proxmox-Backup in Betracht zu ziehen, wenn ihr Proxmox-VE einsetzt. Die Kombination ist einfach genial.
Last edited:
