Verständnis Fragen ESXI / Proxmox / ZFS / NAS
- Ersteller fdiskc2000
- Erstellt am
Trambahner
Urgestein
Was hast Du für eine Nvme-SSD für Cache und Slog, wo die vDisks drauf sind? Keinesfalls übliche normale Consumer-SSD für Slog nehmen. Wird sehr schnell sehr langsam (und kaputtgeschrieben) und untergräbt die Integrität wenn es Flash-SSD ohne Powerloss-Protection sind.
=> nur machen mit Optanes 800p und höher.
=> nur machen mit Optanes 800p und höher.
Zuletzt bearbeitet:
wenn du mich meinst: https://www.wd.com/de-de/products/internal-ssd/wd-black-sn750-nvme-ssd.html#WDS250G3X0C
Western Digital Black nvme 250gb
Western Digital Black nvme 250gb
Trambahner
Urgestein
Ok. Schlechte Idee als Slog.
Ich wollte eben meine Daten von einer USB Platte auf das Napp-it ZFS kopieren, als plötzlich alles stand und ich in ESXi die Frage beantworten musste. Anscheinend ist der L2ARC vollgelaufen???
Aufgebaut ist das ganze wie schon erwähnt als 7x2TB raidZ2, 25GB slog und 125GB L2ARC. Beide als vDisk an napp-it weitergereicht. slog als write log in den Pools mit Sync always und L2ARC dem Pool read cache hinzugefügt.
Geschwindkeit war jetzt auch nicht ganz so berauschend. Ich kopierte von einer USB3.0 direkt am Host Rechner. Die Platte ist in Windows 10 VM gemounted. In Windows 10 kopiere ich mit FastCopy. Es sind viele Files mit 1MB-4GB Files. Als Schnittstelle zwischen Nappit und Win10 ist die schnelle virt. 10GBIT Schnittstelle/LAN eingerichtet.
Mein Problem betrifft vorwiegend den Fehler des L2ARC. Da vCenter und Win10 auf nappit Storage liegen. Beide stehen plötzlich still.
Und komischerweise komme ich nun auch nicht mehr auf das nappit Portal. der hostname in ESXI wird erkannt, aber die IP 192.168.196.10 nicht mehr. Ping funktioniert auch nicht. Die NFS Freigabe funktioniert allerdings, da ich die beiden VM´s auf dem Host starten kann (beide liegen auf nappit).
Nach neuem Start habe ich mal einen Screenshot der ESXI Console gemacht. Was mir auffällt:
- hma_vmx_init CPU does not support VMX
- smbsrv... share not found
- nappit meldet sich zwar mit dem Hostname, aber nicht mit der eingestellten IP. Ich komme leider nicht auf die Weboberfläche
Der Reihe nach
Ein L2Arc kann nicht vollaufen.
Die zugrundeliegene Platte auf der die ESXi virtuellen Platten liegen aber schon wenn man die Platten Thin provisioned anlegt und die Platte überbucht. Insbesondere für Slog und L2Arc sollte man immer Thick wählen, schon wegen der besseren Performance
Der letzte Screen
VMX ist eine Option zum Virtualisieren unter OmniiOS, ganz normal, nicht relevant
OmniOS scheint aber nicht komplett zu booten, sondern bleibt hängen. Die SMB Meldung bedeutet dass ein nicht erfolgloser Zugriffsversuch per SMB (user guest auf das angegeben Share) erfolgte. Damit ist klar dass zumindes das Mounten des Pools noch geklappt hat.
Entscheidend wird sein, das "vollgelaufene, defekte" L2Arc zu entfernen. Wenn OmniOS nicht mehr bootet dann unter ESXi die virtuelle Platte entfernen und neu booten. ZFS wird die fehlende Platte zwar anmosern, man kann die dann aber entfernen. Ein fehlendes Slog/L2Arc ist unkritisch.
Ein L2Arc kann nicht vollaufen.
Die zugrundeliegene Platte auf der die ESXi virtuellen Platten liegen aber schon wenn man die Platten Thin provisioned anlegt und die Platte überbucht. Insbesondere für Slog und L2Arc sollte man immer Thick wählen, schon wegen der besseren Performance
Der letzte Screen
VMX ist eine Option zum Virtualisieren unter OmniiOS, ganz normal, nicht relevant
OmniOS scheint aber nicht komplett zu booten, sondern bleibt hängen. Die SMB Meldung bedeutet dass ein nicht erfolgloser Zugriffsversuch per SMB (user guest auf das angegeben Share) erfolgte. Damit ist klar dass zumindes das Mounten des Pools noch geklappt hat.
Entscheidend wird sein, das "vollgelaufene, defekte" L2Arc zu entfernen. Wenn OmniOS nicht mehr bootet dann unter ESXi die virtuelle Platte entfernen und neu booten. ZFS wird die fehlende Platte zwar anmosern, man kann die dann aber entfernen. Ein fehlendes Slog/L2Arc ist unkritisch.
ok, dann liegt das mit thin provision zusammen. Ich habe nun die beiden vDisk gelöscht. Dann im Dateibrowser auf der NvME die vmdk für slog und l2arc gelöscht.
Jetzt möchte ich der nappit appliance wieder zwei vDisks hinzufügen. Dort gibt es kein ThickProvisioning
- - - Updated - - -
jetzt habe ich die beiden vDisk gelöscht und nappit gestartet. wie erwartet kommt jetzt ein Error.
zpool status
Assertion failed: reason == ZPOOL_STATUS_OK, file zpool_main.c, line 4992
pool: esx1_ZFS
state: UNAVAIL
Jetzt möchte ich der nappit appliance wieder zwei vDisks hinzufügen. Dort gibt es kein ThickProvisioning
- - - Updated - - -
jetzt habe ich die beiden vDisk gelöscht und nappit gestartet. wie erwartet kommt jetzt ein Error.
zpool status
Assertion failed: reason == ZPOOL_STATUS_OK, file zpool_main.c, line 4992
pool: esx1_ZFS
state: UNAVAIL
Provisioning läßt sich nicht nachträglich ändern, lediglich beim Anlegen hat man die Option Thick (eagerly).
Pool Status unavail macht mir Sorgen, da sollte degraded stehen (funktioniert aber Slog und L2Arc fehlen). Wie ist denn der Status in napp-it (Menu Pool > clear ausführen).
Wenn unavail bleibt, Pool exortieren und importieren (Pool > import) mit der Option fehlendes Slog eventuell als readonly oder mit der Option -F (älterer Stand vor letzter Transaktion). Geht das auch nicht so ist der Pool defekt (Neu erstellen).
Pool Status unavail macht mir Sorgen, da sollte degraded stehen (funktioniert aber Slog und L2Arc fehlen). Wie ist denn der Status in napp-it (Menu Pool > clear ausführen).
Wenn unavail bleibt, Pool exortieren und importieren (Pool > import) mit der Option fehlendes Slog eventuell als readonly oder mit der Option -F (älterer Stand vor letzter Transaktion). Geht das auch nicht so ist der Pool defekt (Neu erstellen).
Pool > clear? Erase gibt es.
bei pool info:
Pool Properties:
NAME PROPERTY VALUE SOURCE
esx1_ZFS size - -
esx1_ZFS capacity - -
esx1_ZFS altroot - default
esx1_ZFS health FAULTED -
esx1_ZFS guid 16207123864374558005 -
esx1_ZFS version - -
esx1_ZFS bootfs - -
esx1_ZFS delegation - -
esx1_ZFS autoreplace - -
esx1_ZFS cachefile - default
esx1_ZFS failmode - -
esx1_ZFS listsnapshots - -
esx1_ZFS autoexpand - -
esx1_ZFS dedupditto - -
esx1_ZFS dedupratio - -
esx1_ZFS free - -
esx1_ZFS allocated - -
esx1_ZFS readonly - -
esx1_ZFS comment - default
esx1_ZFS expandsize - -
esx1_ZFS freeing - -
esx1_ZFS fragmentation - -
esx1_ZFS leaked - -
esx1_ZFS bootsize - -
esx1_ZFS checkpoint - -
esx1_ZFS feature@async_destroy disabled local
esx1_ZFS feature@empty_bpobj disabled local
esx1_ZFS feature@lz4_compress disabled local
esx1_ZFS feature@multi_vdev_crash_dump disabled local
esx1_ZFS feature@spacemap_histogram disabled local
esx1_ZFS feature@enabled_txg disabled local
esx1_ZFS feature@hole_birth disabled local
esx1_ZFS feature@extensible_dataset disabled local
esx1_ZFS feature@embedded_data disabled local
esx1_ZFS feature@bookmarks disabled local
esx1_ZFS feature@filesystem_limits disabled local
esx1_ZFS feature@large_blocks disabled local
esx1_ZFS feature@sha512 disabled local
esx1_ZFS feature@skein disabled local
esx1_ZFS feature@edonr disabled local
esx1_ZFS feature@device_removal disabled local
esx1_ZFS feature@obsolete_counts disabled local
esx1_ZFS feature@zpool_checkpoint disabled local
esx1_ZFS feature@spacemap_v2 disabled local
zpool status -v esx1_ZFS
Assertion failed: reason == ZPOOL_STATUS_OK, file zpool_main.c, line 4992
pool: esx1_ZFS
state: UNAVAIL
Pool details zdb -C esx1_ZFS
bei pool info:
Pool Properties:
NAME PROPERTY VALUE SOURCE
esx1_ZFS size - -
esx1_ZFS capacity - -
esx1_ZFS altroot - default
esx1_ZFS health FAULTED -
esx1_ZFS guid 16207123864374558005 -
esx1_ZFS version - -
esx1_ZFS bootfs - -
esx1_ZFS delegation - -
esx1_ZFS autoreplace - -
esx1_ZFS cachefile - default
esx1_ZFS failmode - -
esx1_ZFS listsnapshots - -
esx1_ZFS autoexpand - -
esx1_ZFS dedupditto - -
esx1_ZFS dedupratio - -
esx1_ZFS free - -
esx1_ZFS allocated - -
esx1_ZFS readonly - -
esx1_ZFS comment - default
esx1_ZFS expandsize - -
esx1_ZFS freeing - -
esx1_ZFS fragmentation - -
esx1_ZFS leaked - -
esx1_ZFS bootsize - -
esx1_ZFS checkpoint - -
esx1_ZFS feature@async_destroy disabled local
esx1_ZFS feature@empty_bpobj disabled local
esx1_ZFS feature@lz4_compress disabled local
esx1_ZFS feature@multi_vdev_crash_dump disabled local
esx1_ZFS feature@spacemap_histogram disabled local
esx1_ZFS feature@enabled_txg disabled local
esx1_ZFS feature@hole_birth disabled local
esx1_ZFS feature@extensible_dataset disabled local
esx1_ZFS feature@embedded_data disabled local
esx1_ZFS feature@bookmarks disabled local
esx1_ZFS feature@filesystem_limits disabled local
esx1_ZFS feature@large_blocks disabled local
esx1_ZFS feature@sha512 disabled local
esx1_ZFS feature@skein disabled local
esx1_ZFS feature@edonr disabled local
esx1_ZFS feature@device_removal disabled local
esx1_ZFS feature@obsolete_counts disabled local
esx1_ZFS feature@zpool_checkpoint disabled local
esx1_ZFS feature@spacemap_v2 disabled local
zpool status -v esx1_ZFS
Assertion failed: reason == ZPOOL_STATUS_OK, file zpool_main.c, line 4992
pool: esx1_ZFS
state: UNAVAIL
Pool details zdb -C esx1_ZFS
Das Menü Pools listet die Pools auf.
Für jeden Pool gibt es die Option "clear error"
Pool > Destroy löscht den Pool (man kann ihn aber dennoch importieren wenn alle Platte noch da sind)
Ich gehe aber nicht davon aus, dass das hilft.
Der Pool ist strukturell beschädigt. Import mit seinen Optionen wird die letzte Möglichkeit sein.
Für jeden Pool gibt es die Option "clear error"
Pool > Destroy löscht den Pool (man kann ihn aber dennoch importieren wenn alle Platte noch da sind)
Ich gehe aber nicht davon aus, dass das hilft.
Der Pool ist strukturell beschädigt. Import mit seinen Optionen wird die letzte Möglichkeit sein.
wenn ich einen neuen Pool aufsetze und ZFS wieder erstelle, ist alles weg? Auch die beiden VM´s die ich frisch erstellt habe?
- - - Updated - - -
so, ich habe den Pool gelöscht und neu erstellt. Wieder slog und L2ARC hinzugefügt. nun ist ZFS weg??? Ich habe vorher noch einen ZFS Snap gemacht. Kann ich diesen wieder importieren und wie? Sind die Daten alle weg?
- - - Updated - - -
so, ich habe den Pool gelöscht und neu erstellt. Wieder slog und L2ARC hinzugefügt. nun ist ZFS weg??? Ich habe vorher noch einen ZFS Snap gemacht. Kann ich diesen wieder importieren und wie? Sind die Daten alle weg?
Ja
Wenn ein Import mit den genannten Optionen, trotz doppelten Metadaten bei ZFS und den Reparaturoptionen eines aktuellen OmniOS nicht mehr geht, steht man vor dem Rührei Problem. Es ist noch alles da aber ein Ei kann man daraus nicht mehr machen. Eine professionelle Datenrettungsfirma könnte noch Fragmente restaurieren.
Hatte der Pool denn Redundanz (Raid). Daraus kann ZFS dann verlorene Informationen meist wiederherstellen. Ansonsten nennt sich das SuperGau, also ein nicht mehr beherrschbares Problem, ein Disaster. Dafür braucht man auch bei ZFS Disasterbackup.
Hatte ich auch kürzlich und das zum erstenmal und bisher einzigen Mal in den 10 Jahren seit ich ZFS nutze. Ein kompletter Stromausfall in unserer Stadt hat wohl Spannungsspitzen erzeugt bei dem mit einiges kaputtging, inkl eines 3way Mirrors den ich nicht mehr importieren kann. Für den Mirror gilt normalerweise eine Ausfallwahrscheinlichkeit nahe Null. Nützt aber nichts wenn die Hardware Amok läuft. Hatte aber da ein tagesaktuelles Backup.
ps
Snaps sind frühere Dateizustände eines Dateisystems. Löscht man das Dateisystem sind natürlich auch alle Snaps weg.
Wenn ein Import mit den genannten Optionen, trotz doppelten Metadaten bei ZFS und den Reparaturoptionen eines aktuellen OmniOS nicht mehr geht, steht man vor dem Rührei Problem. Es ist noch alles da aber ein Ei kann man daraus nicht mehr machen. Eine professionelle Datenrettungsfirma könnte noch Fragmente restaurieren.
Hatte der Pool denn Redundanz (Raid). Daraus kann ZFS dann verlorene Informationen meist wiederherstellen. Ansonsten nennt sich das SuperGau, also ein nicht mehr beherrschbares Problem, ein Disaster. Dafür braucht man auch bei ZFS Disasterbackup.
Hatte ich auch kürzlich und das zum erstenmal und bisher einzigen Mal in den 10 Jahren seit ich ZFS nutze. Ein kompletter Stromausfall in unserer Stadt hat wohl Spannungsspitzen erzeugt bei dem mit einiges kaputtging, inkl eines 3way Mirrors den ich nicht mehr importieren kann. Für den Mirror gilt normalerweise eine Ausfallwahrscheinlichkeit nahe Null. Nützt aber nichts wenn die Hardware Amok läuft. Hatte aber da ein tagesaktuelles Backup.
ps
Snaps sind frühere Dateizustände eines Dateisystems. Löscht man das Dateisystem sind natürlich auch alle Snaps weg.
Zuletzt bearbeitet:
Das ist ein Bug in der Internationalisierung der ESXi Web-Oberfläche. Die beiden letzten Checkboxen sind Thick, die erste Thin.
Schalte mal auf Englisch um, dann siehst du den korrekten Text.
Pool export + Pool import mit den Reparaturoptionen wäre ein Versuch wert gewesen.
Ansonst braucht man ein recht massives Ereignis um ZFS kaputtzumachen. Es ist deutlich robuster wie jede andere Alternative. Backup braucht man aber dennoch. Normales Recvovery geht zwar aus Snaps aber ab und an (extrem selten wenn man ZFS richtig macht) brauchts das halt doch.
Wie bei jeder Technik brauchts aber etwas Verständnis um die Funktion und Grenzen zu erfassen. Ist wie beim Auto. Trotz ABS uns ESP kann man aus der Kurve fliegen.
Ansonst braucht man ein recht massives Ereignis um ZFS kaputtzumachen. Es ist deutlich robuster wie jede andere Alternative. Backup braucht man aber dennoch. Normales Recvovery geht zwar aus Snaps aber ab und an (extrem selten wenn man ZFS richtig macht) brauchts das halt doch.
Wie bei jeder Technik brauchts aber etwas Verständnis um die Funktion und Grenzen zu erfassen. Ist wie beim Auto. Trotz ABS uns ESP kann man aus der Kurve fliegen.
Trambahner
Urgestein
OT: Taugt eine Line-Interactive USV ausreichend als Blitzschutz? Online-USV ist klar. Oder sind da die zu erwartenden Spannungsspitzen aus dem Netz so groß, dass die Spannungsregulierung in der LI das nicht mehr abfangen kann?
Bzgl. Weg übe V/ADSL würde ich eigentlich (zu naiv?) erwarten, dass es maximal Modem/Router noch trifft, von dort übers LAN aber nix mehr kommt.
Bzgl. Weg übe V/ADSL würde ich eigentlich (zu naiv?) erwarten, dass es maximal Modem/Router noch trifft, von dort übers LAN aber nix mehr kommt.
Zuletzt bearbeitet:
Bei einem direkten Blitzschlag hilft vermutlich nichts. Der Blitz hat bereits mehrere Kilometer Luftweg hinter sich. Der geht überall durch. Da hilft nur alles ausstecken.
Bei einem entfernten Blitzschlag oder kürzlich wie bei mir bei einem weiträumigen Stromausfall mit seinen dadurch entstehenden Spannungsspitzen kann ein guter Blitzschutz allein schon helfen. Der Rest ist Statistik. Ein bestimmer Prozentanteil der Geräte geht kaputt. Manches ist robuster und der Rest ist Kismet.
ps
Selbst eine Online USV hilft nichts wenn die Spannungsspitzen übers LAN Netz kommen.
Bei einem entfernten Blitzschlag oder kürzlich wie bei mir bei einem weiträumigen Stromausfall mit seinen dadurch entstehenden Spannungsspitzen kann ein guter Blitzschutz allein schon helfen. Der Rest ist Statistik. Ein bestimmer Prozentanteil der Geräte geht kaputt. Manches ist robuster und der Rest ist Kismet.
ps
Selbst eine Online USV hilft nichts wenn die Spannungsspitzen übers LAN Netz kommen.
Zuletzt bearbeitet:
also gestern habe ich die Daten von der Backup Platte wieder zurückkopiert. Geschwindigkeit bei vielen Fotodateien lag bei ca. 30Mb/s einer USB2.0 Festplatte und ca. 50MB/s einer USB3.0 Platte (beide SATA consumer Platten). Ich habe nun das nappit All in One neu aufgesetzt (nach meinem Crash). Mein Fehler war, dass ich aus ESXi die NvME mit mit zwei vDisks (für SLOG/L2ARC) als Thin Provision durchgereicht habe. Da kam es zu einem Crash. Danke dir gea für den Tipp mit Thick Provision. Kopiert habe ich direkt am Hostrechner. Dazu habe ich die Platte an den USB3 Controller angeschlossen, in einer Windows10 VM gemounted und von Windows 10 VM auf Nappit kopiert.
Auf der nappit ist nun ein ZFS raid2 Pool (7x2TB SATA 7200rpm) angelegt mit einem ZFS system für VMs (NFS,SMB aktiv) und eines für Storage (SMB aktiv). Beide mit Sync always und dem Pool habe ich 125GB L2ARC (aus der NvME) zugeteilt. Das nappit Basic Tuning habe ich danach ausgeführt.
Im ESXi ist nappit mit VMXNET3 und MTU9000 angeschlossen. Aus dem PC gehen im Moment 2x2 1GBit im Redundanzverfahren in den externen Switch. Eine 10GBit Karte habe ich auch eingebaut, welche ich direkt mit einem anderen Hostrechner verbinde. (ich habe noch kein 10GBit fähiges externes Switch). Geht das überhaupt? ziel soll sein, dass der Austausch im VMWare Netz schneller geht.
Nochmals zu sLog und L2ARC, da ich noch nicht ganz durchgestiegen bin: bringt das slog bei 1Gbit Netz was und bei Copy Jobs mit kleinen Dateien (RAW Bilder, Vorschaudateien, ect.)? Oder ist es sinnvoll, das slog nur auf der Zfs-VM Freigabe zu aktivieren (also für NFS/SMB)? Dort liegen meine VMWare Virtualisierungsrechner.
und L2ARC? Sinnvoll? Der nappit Appliance sind 10GB RAM zugeteilt.
Im Falle eines Falles: kann ich die NvME wieder ausbauen und dem Pool L2ARC und slog wegnehmen, ohne dass das raidz2 kaputt geht? Und wenn ja, wie?
Sorry für die Anfängerfragen, aber ZFS ist absolut Neuland für mich. Und in VMWare arbeite ich mich auch erst ein. Danke EUCH allen, für die bisherige Hilfe
Auf der nappit ist nun ein ZFS raid2 Pool (7x2TB SATA 7200rpm) angelegt mit einem ZFS system für VMs (NFS,SMB aktiv) und eines für Storage (SMB aktiv). Beide mit Sync always und dem Pool habe ich 125GB L2ARC (aus der NvME) zugeteilt. Das nappit Basic Tuning habe ich danach ausgeführt.
Im ESXi ist nappit mit VMXNET3 und MTU9000 angeschlossen. Aus dem PC gehen im Moment 2x2 1GBit im Redundanzverfahren in den externen Switch. Eine 10GBit Karte habe ich auch eingebaut, welche ich direkt mit einem anderen Hostrechner verbinde. (ich habe noch kein 10GBit fähiges externes Switch). Geht das überhaupt? ziel soll sein, dass der Austausch im VMWare Netz schneller geht.
Nochmals zu sLog und L2ARC, da ich noch nicht ganz durchgestiegen bin: bringt das slog bei 1Gbit Netz was und bei Copy Jobs mit kleinen Dateien (RAW Bilder, Vorschaudateien, ect.)? Oder ist es sinnvoll, das slog nur auf der Zfs-VM Freigabe zu aktivieren (also für NFS/SMB)? Dort liegen meine VMWare Virtualisierungsrechner.
und L2ARC? Sinnvoll? Der nappit Appliance sind 10GB RAM zugeteilt.
Im Falle eines Falles: kann ich die NvME wieder ausbauen und dem Pool L2ARC und slog wegnehmen, ohne dass das raidz2 kaputt geht? Und wenn ja, wie?
Sorry für die Anfängerfragen, aber ZFS ist absolut Neuland für mich. Und in VMWare arbeite ich mich auch erst ein. Danke EUCH allen, für die bisherige Hilfe
Sync und Slog ist eine Absicherung des Ramcaches. Hat die gleiche Aufgabe wie Batterie oder Flashsicherung bei Hardware Raid. Sync macht für VMs absolut Sinn. Da könnte ein Crash sonst das Dateisystem einer VM beschädigen.
Bei einem einen ZFS SMB Filer sieht es anders aus. Bei einem Crash wird ZFS nicht beschädigt und der Sicherheitsagewinn von sync ist relativ gering, der Performanceverlust aber hoch - auch mit Slog. Da würd ich sync auf default setzen (bei SMB bedeutet das aus).
Slog ist eben kein Ramcache und bringt keinen Performancegewinn. Es sorgt nur dafür des der Performanceverlust von sync write gering bleibt.
Ein Slog und L2Arc kann man jederzeit vom Pool entfernen (Menü Disk > Remove)
Direktverbindungen zwischen Nics sind kein Problem. Man braucht halt ein gekreutzes LAN Kabel (oder Netzwerkkarten die das automatisch können, ist aber nur bei Switches üblich)
Bei einem einen ZFS SMB Filer sieht es anders aus. Bei einem Crash wird ZFS nicht beschädigt und der Sicherheitsagewinn von sync ist relativ gering, der Performanceverlust aber hoch - auch mit Slog. Da würd ich sync auf default setzen (bei SMB bedeutet das aus).
Slog ist eben kein Ramcache und bringt keinen Performancegewinn. Es sorgt nur dafür des der Performanceverlust von sync write gering bleibt.
Ein Slog und L2Arc kann man jederzeit vom Pool entfernen (Menü Disk > Remove)
Direktverbindungen zwischen Nics sind kein Problem. Man braucht halt ein gekreutzes LAN Kabel (oder Netzwerkkarten die das automatisch können, ist aber nur bei Switches üblich)
also slog für VM aktiv und für Filestorage deaktiviere -> dein Ratschlag.
L2ARC kann ich bei beiden aktiv lassen. Die L2ARC ist dem Pool zugeordnet.
Snapshots: sind in ESXi Snapshots noch wichtig, wenn ich Autosnap im ZFS einstelle? Oder wie muß ich mir das vorstellen?
L2ARC kann ich bei beiden aktiv lassen. Die L2ARC ist dem Pool zugeordnet.
Snapshots: sind in ESXi Snapshots noch wichtig, wenn ich Autosnap im ZFS einstelle? Oder wie muß ich mir das vorstellen?
Eigentlich sind die ESXi Snaps unerreicht leistungsfähig. So ein Snap enthält auf Wund den Memory Status das bedeutet das man auf eine laufende Maschine zu einem bestimmten Zeitpunkt zurückkann.
ZFS Snaps kann man dagegen so sehen wie wenn man bei einem Computer oder einer festplatte den Stecker zieht. Der Stand auf Platte entspricht genau dem Stand zu diesem Zeitpunkt. Ist eine laufende VM auf einem ZFS Snap so kann es sein dass der Snap korrupt ist. Eben genau das was einem laufendem Computer z.B. Windows bei einem Stromausfall passieren kann. Meist steckt das OS das weg aber eben nicht immer.
Leider funktionieren ESXi Snaps so, dass nach Anlegen des Snaps eine Datei angelegt wird in der alle Änderungen protokolliert werden. Je älter der Snap umso größer die Protokolldatei und umso langsamer die VM. ESXi Snaps kann man daher nur vereinzelt anlegen und sollte sie so schnell wie möglich wieder löschen.
ZFS Snaps frieren dagegen einen Dateistand ein und schützen vorhandene Daten beim Ändern lediglich gegen überschreiben. Deshalb werden ZFS Snaps auch praktisch verzögerungsfrei erstellt, verbrauchen keinen Platz (lediglich der auf Platte gesperrte Platz nimmt mit Änderungen zu) und können zu Tausenden erstellt werden ohne dass das Probleme macht.
Der Königsweg ist es erst einen ESXi Snap zu erstellen, dann einen ZFS Snap der den ESXi Snap (die Protokolldatei von ESXi) enthält und dann den ESXi Snap wieder löschen. Nach Wiederherstellen des ZFS Snaps kann man aber anschließend in einer VM auf den ESXi Snap zurückgehen. Ist halt etwas komplexer.
ZFS Snaps kann man dagegen so sehen wie wenn man bei einem Computer oder einer festplatte den Stecker zieht. Der Stand auf Platte entspricht genau dem Stand zu diesem Zeitpunkt. Ist eine laufende VM auf einem ZFS Snap so kann es sein dass der Snap korrupt ist. Eben genau das was einem laufendem Computer z.B. Windows bei einem Stromausfall passieren kann. Meist steckt das OS das weg aber eben nicht immer.
Leider funktionieren ESXi Snaps so, dass nach Anlegen des Snaps eine Datei angelegt wird in der alle Änderungen protokolliert werden. Je älter der Snap umso größer die Protokolldatei und umso langsamer die VM. ESXi Snaps kann man daher nur vereinzelt anlegen und sollte sie so schnell wie möglich wieder löschen.
ZFS Snaps frieren dagegen einen Dateistand ein und schützen vorhandene Daten beim Ändern lediglich gegen überschreiben. Deshalb werden ZFS Snaps auch praktisch verzögerungsfrei erstellt, verbrauchen keinen Platz (lediglich der auf Platte gesperrte Platz nimmt mit Änderungen zu) und können zu Tausenden erstellt werden ohne dass das Probleme macht.
Der Königsweg ist es erst einen ESXi Snap zu erstellen, dann einen ZFS Snap der den ESXi Snap (die Protokolldatei von ESXi) enthält und dann den ESXi Snap wieder löschen. Nach Wiederherstellen des ZFS Snaps kann man aber anschließend in einer VM auf den ESXi Snap zurückgehen. Ist halt etwas komplexer.
Zuletzt bearbeitet:
lassen wir die Königsklasse mal weg. Sprich ich habe ein ZFS Filesystem für die VMs. Darauf laufen im Moment eine VM für Windows und eine für das vCenter. (wird alles erst aufgebaut). Nun habe ich einen Snapjob angelegt.
Ich möchte gerne Snaps jede Stunde/proTag/proWoche/proMonat anlegen.
Bestenfalls:
jede Stunde
dann einmal pro Tag (vorhalten 1 Woche)
einmal pro Woche (vorhalten für 2 Wochen)
einmal pro Monat (vorhalten 2 Monate)
irgendwie so, dachte ich. die snaps sollen selbstständig erzeugt werden und gelöscht werden. Wieviel Speicherplatz nehmen diese ein, wo liegen diese und wie muß ich mir das vorstellen? Angenommen, ich möchte nur die WIndows VM zurücksetzen. (nicht den vCenter) kann ich der virtuellen Maschine einfach eine neue disk zuweisen oder eine neue VM mounten mit der alten Snapshot Version?
Ich möchte gerne Snaps jede Stunde/proTag/proWoche/proMonat anlegen.
Bestenfalls:
jede Stunde
dann einmal pro Tag (vorhalten 1 Woche)
einmal pro Woche (vorhalten für 2 Wochen)
einmal pro Monat (vorhalten 2 Monate)
irgendwie so, dachte ich. die snaps sollen selbstständig erzeugt werden und gelöscht werden. Wieviel Speicherplatz nehmen diese ein, wo liegen diese und wie muß ich mir das vorstellen? Angenommen, ich möchte nur die WIndows VM zurücksetzen. (nicht den vCenter) kann ich der virtuellen Maschine einfach eine neue disk zuweisen oder eine neue VM mounten mit der alten Snapshot Version?
Für einen Snapjob kann man die Zeit des Erstellens (jede Stunde, jeden Samstag, jeden 1. etc) und die Anzahl der Snaps (keep) und optional Tage (hold) vorgeben. Setzt man beides wie keep=2 und hold=5 muss man das lesen wie lösche Snaps älter als 5 Tage - behalte aber auf jeden Fall die letzten 2. Man legt also mehrere Jobs an, bei obigem Wunsch drei Autosnap Jobs.
Wenn man ZFS nicht kennt, könnte man meinen Snaps sind quasi Backups und erzeugen Kopien der Daten. Da ein Snap aber ohne Zeitverzug erstellt wird und nachher genausoviel Platz ist muss es anders gehen.
Der Schlüssel hier ist CopyOnWrite bei ZFS. Wenn man bei einem alten Dateisystem etwas ändert z.B. in einem Text aus einem Hans ein Haus macht, so wird meist nur der eine Buchstabe in der Datei ersetzt. ZFS schreibt das Haus komplett neu (oder den ZFS Block der das Wort enthält) und gibt nach erfolgreichem Schreiben den alten Block zum Überschreiben frei. Das hat zwei Konsequenzen. Erstens gibt es nur komplette Schreibaktionen (Daten und Metadaten) oder bei einem Absturz bleibt der alte Datenstand (Crashsicherheit). Der zweite ist dass der Zustand vor einer Änderung immer noch auf Platte ist. Ein Snap bewirkt hier nur dass ein älterer Stand gesperrt wird. Das verbraucht zunächst keinen Platz. Für künftige Änderungen steht aber der Platz der Vorversionen nicht mehr zur Verfügung. Je mehr Änderungen desto mehr blockierter Speicher. Damit bedeutet Platzverbrauch bei ZFS Snaps das Bereithalten früherer Versionen.
Auf frühere Versionen eines Dateisystems kann man per Rollback zurückgehen. Man kann auch aus einem Snap ein Clone erzeugen oder man benutzt Windows SMB und "vorherige Version" um einen älteren Stand zu kopieren oder wiederherzustellen.
Wenn man ZFS nicht kennt, könnte man meinen Snaps sind quasi Backups und erzeugen Kopien der Daten. Da ein Snap aber ohne Zeitverzug erstellt wird und nachher genausoviel Platz ist muss es anders gehen.
Der Schlüssel hier ist CopyOnWrite bei ZFS. Wenn man bei einem alten Dateisystem etwas ändert z.B. in einem Text aus einem Hans ein Haus macht, so wird meist nur der eine Buchstabe in der Datei ersetzt. ZFS schreibt das Haus komplett neu (oder den ZFS Block der das Wort enthält) und gibt nach erfolgreichem Schreiben den alten Block zum Überschreiben frei. Das hat zwei Konsequenzen. Erstens gibt es nur komplette Schreibaktionen (Daten und Metadaten) oder bei einem Absturz bleibt der alte Datenstand (Crashsicherheit). Der zweite ist dass der Zustand vor einer Änderung immer noch auf Platte ist. Ein Snap bewirkt hier nur dass ein älterer Stand gesperrt wird. Das verbraucht zunächst keinen Platz. Für künftige Änderungen steht aber der Platz der Vorversionen nicht mehr zur Verfügung. Je mehr Änderungen desto mehr blockierter Speicher. Damit bedeutet Platzverbrauch bei ZFS Snaps das Bereithalten früherer Versionen.
Auf frühere Versionen eines Dateisystems kann man per Rollback zurückgehen. Man kann auch aus einem Snap ein Clone erzeugen oder man benutzt Windows SMB und "vorherige Version" um einen älteren Stand zu kopieren oder wiederherzustellen.
Zuletzt bearbeitet:
konfetti
Urgestein
Für mich klingt das ja nach nem Backup-Job - da ist die Frage, warum das nicht mit den Boardmitteln machen? - VMware bietet dafür ja die VDP an - die kann genau das!
Wäre aus meiner Sicht sinniger, als auf die Snapshot mit einem ggf. koruppten Dateisystem zu vertrauen.
In der VDP kann man dann unter Umständen auch einzelne Files des Gastes wiederherstellen...
Die Sicherheit von ZFS macht aber für die VMDK der VDP durchaus Sinn!
Es ist ja kein Problem, ESXi konsistente ZFS Snaps zu machen (eben solche die ESXi Snaps enthalten) - entweder rmanuell oder als Option des Snapjobs. Backup, das ist eine Notlösung für diejenigen die kein vernünftiges Storage oder SAN haben - auf Blech oder wie hier virtualisiert.
Entscheidend ist aber
Ein ZFS Snap erstellen dauert 0,n Sekunden, ein Backup je nach Datenmenge und Kopiergeschwindigkeit in Größenordnung mehr. Mit ZFS kann man tausende Snaps machen, jede Minute einen. Und nur mit ZFS kann man einen Hochlastserver im Petabyte Bereich auf einen zweiten Server syncronisieren.
Entscheidend ist aber
Ein ZFS Snap erstellen dauert 0,n Sekunden, ein Backup je nach Datenmenge und Kopiergeschwindigkeit in Größenordnung mehr. Mit ZFS kann man tausende Snaps machen, jede Minute einen. Und nur mit ZFS kann man einen Hochlastserver im Petabyte Bereich auf einen zweiten Server syncronisieren.
Je nach Applikation sollte man vor einem Snapshot zB per Guest Agent einen konsistenten Zustand sicherstellen. Konsistent ist ansonsten ggf nur das ZFS Filesystem und nicht die Daten innerhalb der VM/Applikation.
danke euch für die Erklärungen. Nur ein paar Dinge sind mir noch nicht ganz logisch.
- ich habe ja ein Dataset "zfs VM". Auf dieser liegen meine virtuellen Rechner. Hier wäre es nun logisch, automatisch Snaps zu erstellen. Wenn nun z.B. in einer VM was schief geht, die andere aber munter weiterläuft und alles gut ist, wie kann ich dann nur die eine VM (sagen wir Windows) wieder herstellen, während sich vielleicht in der anderen was ändert? Dann müsste ich ja für jede VM Snapshots separat erstellen, oder? Also auf ZFS Basis (nicht in ESXi)?
- Und wie kann ich dann in ESXi die alte Version wieder reinladen? Einfach mittels WinSCP in den Snap Ordner gehen, die alte Snap in den VM Ordner kopieren und gut ist?
- macht es sinn, bei einem Filersystem (also Fotoarchiv) auch Snapjobs anzulegen? Da wir hier von Archiv reden, sind viele Daten unberührt am selben Platz und es kommen eben von Zeit zu Zeit neue hinzu. Abundzu wird dann was verändert.
- Wenn ich das richtig verstanden habe, ist die Dateigröße eines Snaps nur so groß, wie der "Änderungsblock". Bei Dateien mit vielen Änderungen wird der Snap allerdings sehr groß, oder? Sprich bei laufender VM ändert sich ja immer etwas, sofern auf der VM gearbeitet wird.
- Aus ESXi kann ich ja auch Snap erstellen, allerdings nur, wenn kein PCI Passthrough aktiviert wurde. Jetzt habe ich aber z.B. meine GPU durchgereicht, in einer VM einen USB Controller, ect. - dann kann ich nur bei deaktivierter VM einen ESXi Snap erstellen. D.h. automatischer ESXi Snap funktioniert nicht. Dann wird das auch nichts mit aus napp-it gesteuerter ESXiAutosnap Funktion? Aber der ZFS Snap funktioniert? Es soll ja kein "richtiges" Backup sein, aber ein "on-the-fly" Sicherheitssystem. Ich backupe meine Fotos und VM´s dann noch separat mittels "normalen" Backup-Programmen und/oder Auslagerung in die Cloud. Noch fehlt eine Spiegelung (sep. NAS/Server) um eine Replikation zu erstellen. Benötige ich im Heimgebrauch auch nicht wirklich. Im Rechenzentrum oder im Unternehmen sicherlich wichtig.
- Außerdem laufen mein napp-it Server nicht 24/7 durch. Ich fahre das System bei Nichtgebrauch runter und starte den Rechner über WoL oder iKVM, wenn ich ihn benötige. Die Startsequenz von ESXi und nappit kann ich abwarten. Wie gesagt: Heimgebrauch. Da müssen die Kisten nicht durchgehend laufen. Bis mein Laptop hochgefahren ist und ich meinen Kaffee gemacht habe, ist nappit auch schon wieder am Start. Doch wie verhält sich das mit den Autosnaps? Da fehlen ja dann beim ausgeschalteten Zustand ettliche Snaps. Kommt da nappit durcheinander?
Last but not least: gibt es eine ausführliche und leichtverständliche Anleitung zu Snaps? Bzw. ein How-to-Tutorial-Video von nappit? Habe noch nichts gefunden. ZFS rocks hat sowas von Freenas im Angebot. Echt nicht schlecht. Wäre klasse, wenn es sowas von napp-it gäbe ;-) Also DANKE nochmals für die vielen Antworten.
-
- ich habe ja ein Dataset "zfs VM". Auf dieser liegen meine virtuellen Rechner. Hier wäre es nun logisch, automatisch Snaps zu erstellen. Wenn nun z.B. in einer VM was schief geht, die andere aber munter weiterläuft und alles gut ist, wie kann ich dann nur die eine VM (sagen wir Windows) wieder herstellen, während sich vielleicht in der anderen was ändert? Dann müsste ich ja für jede VM Snapshots separat erstellen, oder? Also auf ZFS Basis (nicht in ESXi)?
- Und wie kann ich dann in ESXi die alte Version wieder reinladen? Einfach mittels WinSCP in den Snap Ordner gehen, die alte Snap in den VM Ordner kopieren und gut ist?
- macht es sinn, bei einem Filersystem (also Fotoarchiv) auch Snapjobs anzulegen? Da wir hier von Archiv reden, sind viele Daten unberührt am selben Platz und es kommen eben von Zeit zu Zeit neue hinzu. Abundzu wird dann was verändert.
- Wenn ich das richtig verstanden habe, ist die Dateigröße eines Snaps nur so groß, wie der "Änderungsblock". Bei Dateien mit vielen Änderungen wird der Snap allerdings sehr groß, oder? Sprich bei laufender VM ändert sich ja immer etwas, sofern auf der VM gearbeitet wird.
- Aus ESXi kann ich ja auch Snap erstellen, allerdings nur, wenn kein PCI Passthrough aktiviert wurde. Jetzt habe ich aber z.B. meine GPU durchgereicht, in einer VM einen USB Controller, ect. - dann kann ich nur bei deaktivierter VM einen ESXi Snap erstellen. D.h. automatischer ESXi Snap funktioniert nicht. Dann wird das auch nichts mit aus napp-it gesteuerter ESXiAutosnap Funktion? Aber der ZFS Snap funktioniert? Es soll ja kein "richtiges" Backup sein, aber ein "on-the-fly" Sicherheitssystem. Ich backupe meine Fotos und VM´s dann noch separat mittels "normalen" Backup-Programmen und/oder Auslagerung in die Cloud. Noch fehlt eine Spiegelung (sep. NAS/Server) um eine Replikation zu erstellen. Benötige ich im Heimgebrauch auch nicht wirklich. Im Rechenzentrum oder im Unternehmen sicherlich wichtig.
- Außerdem laufen mein napp-it Server nicht 24/7 durch. Ich fahre das System bei Nichtgebrauch runter und starte den Rechner über WoL oder iKVM, wenn ich ihn benötige. Die Startsequenz von ESXi und nappit kann ich abwarten. Wie gesagt: Heimgebrauch. Da müssen die Kisten nicht durchgehend laufen. Bis mein Laptop hochgefahren ist und ich meinen Kaffee gemacht habe, ist nappit auch schon wieder am Start. Doch wie verhält sich das mit den Autosnaps? Da fehlen ja dann beim ausgeschalteten Zustand ettliche Snaps. Kommt da nappit durcheinander?
Last but not least: gibt es eine ausführliche und leichtverständliche Anleitung zu Snaps? Bzw. ein How-to-Tutorial-Video von nappit? Habe noch nichts gefunden. ZFS rocks hat sowas von Freenas im Angebot. Echt nicht schlecht. Wäre klasse, wenn es sowas von napp-it gäbe ;-) Also DANKE nochmals für die vielen Antworten.
-
Snap macht man immer und möglichst viele.
Das ist ja die erste Sicherung gegen Datenverlust oder Trojaner die einem die Platte gegen Lösegeld verschlüsseln wollen
Die einfachste Art auf die Snaps zuzugreifen ist Windows und SMB.
Dazu einfach das per NFS freigegebene Dateisystem auch per SMB freigeben. Mit "vorherige Version" kann man dann ganz einfach einzelne Dateien oder Order aus dem ZFS Snap kopieren oder wiederherstellen. Eine VM ist ja unter ESXi einfach ein Ordner auf NFS.
Ein Snap verbraucht keinen Platz!
Zu dem Zeitpunkt an dem man den Snap erstellt ist der Inhalt des aktuellen Dateisystems und des Snaps identisch. Auch 10000 Snaps nacheinander erstellt brauchen praktisch keinen Platz außer ein paar Byte Verwaltungsaufwand. Alle Datenblöcke erhalten durch den Snap lediglich einen Sperrvermerk. Wird ein Datenblock geändert so wird der vorherige Datenblock daher nicht zum Überschreiben freigegeben. Da die geänderten Datenblöcke Platz brauchen und der vorherige nicht wiederbenutzt werden kann sinkt die Kapazität.
ESXi Snaps mit Pass-through gehen nur offline. Mit der Storage VM kein Problem, die macht ja wegen ZFS eigene bootfähige Snaps (Bootumgebung, BE). ZFS Snaps ist das alles egal. Auch offene Dateien sind mit aktuellem Stand im Snap enthalten.
bzgl. Autosnaps
Wenn der Rechner an ist werden Snaps gemacht, wenn er aus ist eben nicht. Wo ist das Problem? Man hat einen Snap zu einem bestimmten Tag/ Stunde oder man hat eben keinen.
ZFS Snaps sind eigentlich genial einfach. Lediglich wenn man traditionelle Backupverfahren im Hinterkopf hat, dreht sich einem der Kopf. Da konnte man sowas elegantes halt einfach nicht machen.
Overview of ZFS Snapshots - Oracle Solaris Administration: ZFS File Systems
Als Backup dient ein Schnappschuss - ZFS ausprobiert: Ein Dateisystem frs Rechenzentrum im privaten Einsatz - Golem.de
Das ist ja die erste Sicherung gegen Datenverlust oder Trojaner die einem die Platte gegen Lösegeld verschlüsseln wollen
Die einfachste Art auf die Snaps zuzugreifen ist Windows und SMB.
Dazu einfach das per NFS freigegebene Dateisystem auch per SMB freigeben. Mit "vorherige Version" kann man dann ganz einfach einzelne Dateien oder Order aus dem ZFS Snap kopieren oder wiederherstellen. Eine VM ist ja unter ESXi einfach ein Ordner auf NFS.
Ein Snap verbraucht keinen Platz!
Zu dem Zeitpunkt an dem man den Snap erstellt ist der Inhalt des aktuellen Dateisystems und des Snaps identisch. Auch 10000 Snaps nacheinander erstellt brauchen praktisch keinen Platz außer ein paar Byte Verwaltungsaufwand. Alle Datenblöcke erhalten durch den Snap lediglich einen Sperrvermerk. Wird ein Datenblock geändert so wird der vorherige Datenblock daher nicht zum Überschreiben freigegeben. Da die geänderten Datenblöcke Platz brauchen und der vorherige nicht wiederbenutzt werden kann sinkt die Kapazität.
ESXi Snaps mit Pass-through gehen nur offline. Mit der Storage VM kein Problem, die macht ja wegen ZFS eigene bootfähige Snaps (Bootumgebung, BE). ZFS Snaps ist das alles egal. Auch offene Dateien sind mit aktuellem Stand im Snap enthalten.
bzgl. Autosnaps
Wenn der Rechner an ist werden Snaps gemacht, wenn er aus ist eben nicht. Wo ist das Problem? Man hat einen Snap zu einem bestimmten Tag/ Stunde oder man hat eben keinen.
ZFS Snaps sind eigentlich genial einfach. Lediglich wenn man traditionelle Backupverfahren im Hinterkopf hat, dreht sich einem der Kopf. Da konnte man sowas elegantes halt einfach nicht machen.
Overview of ZFS Snapshots - Oracle Solaris Administration: ZFS File Systems
Als Backup dient ein Schnappschuss - ZFS ausprobiert: Ein Dateisystem frs Rechenzentrum im privaten Einsatz - Golem.de
Ähnliche Themen
[Kaufberatung]
Einsteiger Homelab für HA, Docker, VMs, Plex etc.