Mein ZFS pool ist beim gestrigen Node-Ausfall gestorben, was kann ich das nächste Mal besser machen?

    Hallo,


    gestern gab es einen Ausfall, der das Servernode betroffen hat, auf dem mein vServers VPS 2000 G11 gehostet ist. Nach der Wiederherstellung des Nodes seitens Netcup bootet mein vServer nicht mehr. Der ZFS pool meines FreeBSD ist korrupt und lässt sich nicht mehr reparieren, da kein Mirror o.ä.


    Nun meine Frage:

    Das Produkt hat ja nur eine Festplatte (512 GB), so dass ich keinen ZFS pool als Mirror von zwei Festplatten erstellen kann. In einem physischen Rechner hätte ich zwei SSD eingebaut und einen Mirror erzeugt. Fällt Euch eine Alternative ein, um das nächste Mal gegen eine korrupte Festplatte dieser Art im vServer gewappnet zu sein?


    Edit:

    Was ich gerade noch mal zu den Speicherplatz der vServer lese: "Die vServer verfügen über eine Festplatte, die über ein schnelles und sicheres RAID bereit gestellt wird." Da würde ich ja erst mal annehmen, dass es nicht zu einem korrupten ZFS pool kommen sollte, wenn das unterliegende Block Device schon mittels RAID abgesichert ist, oder mache ich einen Denkfehler?

    Ein RAID schützt ausschließlich bei einem HW Defekt eines der am RAID beteiligten Laufwerke. Gegen korrumpierte Daten, z.B nach einem kapitalen Systemcrash, ist ein RAID völlig machtlos.


    Erzeuge ein Backup, mit dem du die relevanten Daten mit vertretbarem Aufwand wiederherstellen kannst. Ein frisches Aufsetzen des Servers wird dir aber nicht erspart bleiben. Ob ZFS empfindlicher gegen Filesystemkorruption ist, als z.B. ext4, kann ich nicht sagen.

    Mir ist klar, dass das RAID gegen Hardware Ausfälle absichert.


    Das ist ja der Punkt. Trotz Raid ist das Blockdevice (vServer Festplatte) korrupt. Das sagt mir ja das ZFS darauf. Dank Copy-On-Write ist es ja immun gegen spontanes abschalten des Servers, gegen Lesefehler durch das fehlerhafte Blockdevice ist es aber ohne Mirror nicht immun.


    Klar kann ich jetzt den Server neu aufsetzen, aber ohne zweite Festplatte kann ich schlecht ein ZFS mirror aufsetzen, um das nächste Mal gegen so einen Vorfall gewappnet zu sein.


    Weiß jemand, ob der Local Block Storage als zweite Festplatte im vServer zur Verfügung steht und ob der auf einem anderen Hardware RAID von Netcup läuft?

    Ich habe den Eindruck, du verwechselst da das Host-Laufwerk mit deinem VPS.

    Quote from bw1faeh0

    Trotz Raid ist das Blockdevice (vServer Festplatte) korrupt.

    Das Blockdevice ist ein rein virtuelles Laufwerk und hat nichts mit dem RAID des Hosts zu tun. Das ist eine Datei auf der Platte, und die kann natürlich auch bei einem Crash beschädigt werden.


    Quote from bw1faeh0

    Dank Copy-On-Write ist es ja immun gegen spontanes abschalten des Servers,

    Gegen hartes Abschalten schon, nicht aber gegen das Schreiben korrupter Daten ins Image.


    Quote from bw1faeh0

    aber ohne zweite Festplatte kann ich schlecht ein ZFS mirror aufsetzen, um das nächste Mal gegen so einen Vorfall gewappnet zu sein.

    Bei dieser Art Zwischenfall rettet dich auch ein ZFS Mirror nicht. Da wären anschließend beide Instanzen kaputt.

    Das Problem ist, dass ZFS innerhalb Deiner VM keine Kontrolle über mehrere wichtige Ebenen darüber hat:

    1. Einen wahrscheinlich vorhanden Cache des Hostsystems. Der könnte lügen, was wirklich schon auf die SSD geschrieben wurde.
    2. Das Software/Hardware RAID des Hostsystems. Dieses könnte inkonsistente Daten auf einzelne SSDs schreiben.

    Meiner bisherigen Erfahrung nach durch diverse Tests ist ZFS sehr robust gegen Totalausfälle, wenn es alles selbst kontrollieren kann. Bei einer VM ist das halt leider nicht der Fall. Nicht ohne Grund soll man keine Hardware-RAID-Controller verwenden, wenn ZFS zum Einsatz kommt.


    Verstehe mich nicht falsch, ich verwende selbst ZFS auf 1-2 netcup vServern und darüberhinaus auch in anderen VMs auf diversen Systemen. Aber ich bezweifle, dass man einen beschädigten Pool in so einer virtualisierten Umgebung garantiert vermeiden kann. Selbst mit einer Spiegelung auf ein LBS (Local Block Storage) könnte das meiner Ansicht nach theoretisch wieder passieren. Die beste Absicherung bleibt wohl ein zweites System (im Idealfall in einem anderen RZ), zu dem man Snapshots häufig synchronisiert.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Edited 2 times, last by KB19 ().

    Like 2
    Quote from frank_m

    Das Blockdevice ist ein rein virtuelles Laufwerk und hat nichts mit dem RAID des Hosts zu tun. Das ist eine Datei auf der Platte, und die kann natürlich auch bei einem Crash beschädigt werden.

    Das ist mir schon bewusst. Ich hatte jedoch angenommen, dass Netcup durch ihr Raid im Hintergrund in der Lage sind, korrupte Dateien, die meine virtuelle Festplatte abbilden, zu verhindern.

    Quote from frank_m

    Gegen hartes Abschalten schon, nicht aber gegen das Schreiben korrupter Daten ins Image.

    Ja, das habe ich mir jetzt auch so zusammen gereimt. Wenn das Raid/Hostsystem im Hintergrund Mist macht aber an den virtuellen Client meldet, dass alles korrekt geschrieben wurde, dann hilft mir auch das ZFS nichts.

    Quote from frank_m

    Bei dieser Art Zwischenfall rettet dich auch ein ZFS Mirror nicht. Da wären anschließend beide Instanzen kaputt.

    Quote from KB19

    Nicht ohne Grund soll man keine Hardware-RAID-Controller verwenden, wenn ZFS zum Einsatz kommt.

    Ich nehme an, dass mir da nur ein dedizierter Server mit zwei echten physischen Platten hilft, die ich dann nur mittels ZFS zu einem Mirror verschalte und nicht mittels eines HW Raids.

    Quote from KB19

    Verstehe mich nicht falsch, ich verwende selbst ZFS auf 1-2 netcup vServern und darüberhinaus auch in anderen VMs auf diversen Systemen. Aber ich bezweifle, dass man einen beschädigten Pool in so einer virtualisierten Umgebung garantiert vermeiden kann. Selbst mit einer Spiegelung auf ein LBS (Local Block Storage) könnte das meiner Ansicht nach theoretisch wieder passieren.

    Ok, dann mache ich also weiter wie gehabt.

    Dann hatte ich jetzt nach 10 Jahren einfach mal nur Pech.


    Danke für Euren Input!

    Quote from KB19

    Die beste Absicherung bleibt wohl ein zweites System (im Idealfall in einem anderen RZ), zu dem man Snapshots häufig synchronisiert.

    Ich mache das auch so. Allerdings nicht mit den netcup-snapshots, sondern mit rsync. Da brauche ich dann auf dem Backupserver nur so viel Platz wie das Quellsystem tatsächlich belegt und es passen die syncs mehrer Server drauf.

    Funktioniert recht gut. (Ja auch das Restore. ;) Mehrfach getestet)

    Quote from bw1faeh0

    Das Produkt hat ja nur eine Festplatte (512 GB), so dass ich keinen ZFS pool als Mirror von zwei Festplatten erstellen kann. In einem physischen Rechner hätte ich zwei SSD eingebaut und einen Mirror erzeugt. Fällt Euch eine Alternative ein, um das nächste Mal gegen eine korrupte Festplatte dieser Art im vServer gewappnet zu sein?

    Ich sehe da zwei potentielle Möglichkeiten, um das System besser abzusichern (allerdings noch selbst nicht ausprobiert) :

    • Sofern man nicht 100% der Kapazität des virtuellen Laufwerks verwendet (durch Partitionierung von bspw. 99% der Kapzität), sollte sich mittlerweile ein ["Netcup"-]Snapshot via SCP erzeugen lassen (der in einer separaten Datei abgelegt und danach im laufenden Betrieb nicht mehr verändert wird), von welchem man einen alten Stand restaurieren können sollte.
    • Durch Zubuchung von "Local Block Storage" sollte sich ein zusätzliches ZFS-Volume erzeugen lassen ("Local Block Storage ist verfügbar für unsere Produkte Root-Server ab G9, VPS x86 ab G10 und ARM64 G11 (bis max. 8 TB)"), wodurch sich theoretisch somit auch ein Spiegel definieren lassen können sollte. Auch dieser zusätzliche virtuelle Speicherbereich teilt sich nicht dieselbe Datei mit dem virtuellen Primärlaufwerk, wenngleich er natürlich im "Spiegel-Szenario" dauerhaft im Zugriff ist.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE

    Edited 4 times, last by m_ueberall ().

    Like 1