Verständnis Fragen ESXI / Proxmox / ZFS / NAS

lustig, den letzten Artikel lese ich eben. Genau das bestätigt, dass ich meinem Bauchgefühl für ZFS und ESXi vertraute. Das mit den Snaps habe ich nun halbwegs verstanden. Jetzt weiß ich auch, was mit Windows letzte Funktion gemeint ist. Habe da ein wenig auf dem Schlauch gestanden. Darf ich dich noch fragen, wo die Snaps denn liegen? Im jeweiligen Ordner unter .zfs oder in einem versteckten root Ordner? Mit root Login auf WinSCP und SSH müsste ich doch darauf zugreifen können, oder? Wobei ich mit der "früheren Version" auch klar kommen werde.
Muß man das ZFS auch Defragmentieren? Dumme Frage, oder gibt´s das bei ZFS nicht?

Danke GEA!!!!
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Im Dateisystem kann man auf Snaps im Ordner /pool/dateisystem/.zfs/snapshots/snapshot zugreifen.

Physikalisch bleiben sie da wo sie zum Zeitpunkt der Erstellung des Snapshots liegen. Es wird ja nichts verschoben oder umkopiert. Lediglich löschen oder ändern ist nicht möglich. Nur ein zfs destroy snap zerstört einen einmzelnen Snapshot.

Da Snaps im Dateisystem enthalten sind, werden Snaps auch mit dem Dateisystem gelöscht. Das gab schon böse Überraschungen wenn man das nicht beachtet oder gewußt hat. (Ich habe das Dateisystem gelöscht, wo sind jetzt meine Backup Snap????). Weg natürlich!


ps
Vor allem in Kombination mit dem Solarish SMB Server ist Windows "vorherige Version" genial.
Mit der rechten Maustaste auf einen Ordner klicken und Eigenschaft > vorherige Version wählen. Dann sieht man einen Ordner mit Datum je Snap, kann daraus die Dateien herauskopieren oder wiederherstellen.
 
Zuletzt bearbeitet:
göttlich!!! werde ich wieder testen.

Eine Frage noch: ESXi spuckt eine Warnung bzgl. RAM der nappit Storage VM aus. Dieser sei am Limit. Ich habe der nappit VM 10GB (voll) zugewiesen. Ist das zuwenig oder normal, dass nappit den vollen RAM verwendet? Ist mir nur mal so am Rande aufgefallen, als ich auf den ESXi Host schaute.
 
Mit pass.through vergibt ESXi den Speicher nicht dynamisch sondern fest.
Mit ZFS ist das aber eh die einzig sinnvolle Option. ZFS nutzt eh was da ist.

Für den Schreib/ Lesecache nutzt ZFS einen Großteil des zur Verfügung stehenden Speichers sofern der nicht von anderen Prozessen angefordert wird. Wäre ja auch schade um freien, ungenutzten und teuren Speicher wenn man den nicht nutzen würde. ZFS zieht daraus seine Performance. Wollen andere Prozesse RAM, gibt ZFS den frei.
 
meine Storage-VM auf Xigmanas Basis nutzt auch die vollen 48G zugeteilten RAM. - an sich ist auch alles schön schnell - ab und an kommt es aber vor, das Kopieren auf das Storage in die KB-Bereiche einbricht - dann ist eine Zeit lang "Ruhe" bevor er mit Wirespeed (entweder max. 1G vom Client oder wie neulich von der USB-Platte limitiert) weiterkopiert.
eine SSD als zusätzlichen Cache am Storagepool ist eingerichtet, müsste nochmal nachschauen als was genau - aber wenn ich in die Prozessliste schaue, sehe ich das er ~39GB als Cache vom RAM nutzt.

Lesen geht schnell - auch bei vielen parallelen Zugriffen.
 
gea schrieb:
Mit der rechten Maustaste auf einen Ordner klicken und Eigenschaft > vorherige Version wählen. Dann sieht man einen Ordner mit Datum je Snap, kann daraus die Dateien herauskopieren oder wiederherstellen.
Zum Vergrößern anklicken....
Ich hab das neulich mal gemacht (machen müssen). Dabei hatte ich allerdings das Problem, dass mein normaler Win-SMB-User-Zugriff keine passenden Rechte für das VM-Storage-Dateisystem hatte - ich musste daher erst über SSH und sudo mc in die .zfs snapshot Verzeichnisse, das manuell woanders hin kopieren und dann zurückspielen. Das war - vermutlich - ein Fehler meinerseits bei der Rechtevergabe für das VM-Storage-Dateisystem (das per NFS geteilt wird) - ESXi setzt ja wohl über NFS keine unixoiden Rechte? Aber in jedem Falle störend.

Edit: Wenn es aber funktioniert - super einfach und entspannt, alte Versionen wieder herzustellen. Da gebe ich gea völlig Recht.
 
Zuletzt bearbeitet:
asche77 schrieb:
Ich hab das neulich mal gemacht (machen müssen). Dabei hatte ich allerdings das Problem, dass mein normaler Win-SMB-User-Zugriff keine passenden Rechte für das VM-Storage-Dateisystem hatte - ich musste daher erst über SSH und sudo mc in die .zfs snapshot Verzeichnisse, das manuell woanders hin kopieren und dann zurückspielen. Das war - vermutlich - ein Fehler meinerseits bei der Rechtevergabe für das VM-Storage-Dateisystem (das per NFS geteilt wird) - ESXi setzt ja wohl über NFS keine unixoiden Rechte? Aber in jedem Falle störend.

Edit: Wenn es aber funktioniert - super einfach und entspannt, alte Versionen wieder herzustellen. Da gebe ich gea völlig Recht.
Zum Vergrößern anklicken....

Einfach als root per SMB verbinden.
Der darf (local und per SMB) immer und auf alles zugreifen. Lediglich bei einem NFS Share muss man den Root Zugriff per NFS explizit erlauben. (Oder halt Dateirechte auf everyone@=modify) setzen.
 
ok. Autosnaps laufen. Windows vorherige Version klappt auch, so wie ich das sehe.
Frage zu nappit: ntp Server? Kann ich den auch wo einstellen? Damit die Zeiten identisch zum anderen System sind? Und wegen root Zugriff und SSH: ich komme mit WinSCP nicht auf mein nappit. Weder mit sFTP noch SCP Protokol. SSH ist enabled. Den SSH Server in nappit habe ich auch schon neugestartet. User root und passwort, welches ich gewählt habe. Ich habe meinen SMB User auch schon unter SSH Users hinterlegt. Das klappt auch nicht. Muß ich noch was einstellen?
 
ntp:
Menü Jobs > Other
Als Aktion z.B. ntpdate pool.ntp.org (ignoriere Rückmeldung)

SSH als root ist bei Solaris per default deaktiviert
Menü Service > SSH > allow root
 
wann wird überhaupt der readonly Block eines Snapshots wieder freigegeben? Ich habe jetzt mal die Daten von vor 2 Std. testweise zurückgeholt, nachdem ich einen DVD Ordner gelöscht habe. D.h. der Block ist ja durch den Snap geblockt und belegt dann allerdings einen blockierten Speicher auf dem Filesystem. Wann wird dieser wieder freigeben? Ich habe meine Autosnaps nun so erstellt:
snapjob.jpg
Damit wäre ich in der Lage, auf 1 Jahr zurückzugreifen. Interval ist jede 15min einen Snapshot, dann jede Stunde, 7 Tage, 4 Wochen, 12 Monate. Und das auf den kompletten Pool. So kann ich Files aus dem Storage und aus dem VM Dataset zurückholen.
 
Ingrate schrieb:
wann wird überhaupt der readonly Block eines Snapshots wieder freigegeben? .
Zum Vergrößern anklicken....

Wenn man alle Snapshots gelöscht hat die einen gesperrten Datenblock zum Wiederhesrtellen benötigen würden, dann ist die Sperre aufgehoben und der Block kann wieder für neue Schreibvorgänge genutzt werden.

- - - Updated - - -

konfetti schrieb:
ganz ehrlich, genau dafür nimmt man aber Backups - denn die ZFS Snaps sind halt kein Backup...
Zum Vergrößern anklicken....

Nein. Genau dafür macht man Snaps. Die Menge und Feinheit der Versionierung geht nicht mit Kopier-Backup (z.B. alle 15 Minuten der letzten Stunde bei X Terabyte oder Petabyte). Mit ausreichend Raid-Sicherheit und ZFS ist das bereits sehr sicher und ist die erste,wichtigste und feinste Sicherung gegen Datenverlust. Dazu benutzt man dann die Snaps für Replikation auf einen zweiten online Pool/Server (z.B. täglich) und das ist dann ZFS Backup Stufe 1. Da gibts eventuell auch weniger Snaps/Versionen.

Klassisches Backup bei ZFS ist Disasterbackup und Stufe 2, z.B. für Feuer, Diebstahl, Blitzschlag oder Sabotage auf entfernte Systeme/offline Platten. Das macht man viel seltener und braucht es hoffentlich nie. Snaps auf dem Originalsystem und Snaps auf dem Backup Pool verhindert Datenverlust und sichert gegen Ransomware in nahezu allen Fällen. Sowas dann eventuell wöchentlich oder monatlich

Gar kein externes Zweitsystem oder Backup Pool auf externen Platten ist aber auch mit ZFS nicht sicher genug.
 
Das wäre dann ja der nächste Punkt. Autosnap (Stufe "0") läuft dann schon mal. Stufe 2 mit dem Backup auf ext. Platte/Cloud/ect. betreibe ich schon. Zu deiner Stufe 1 mit Replikation? D.h. du legst auch einen Replikations-Autojob an? Da werden nur die Snaps weggesichert? Der Originalbestand nicht? Oder reden wir von einer kompletten Spiegelung der Daten auf einen zweiten Server/NAS?
 
Was ist denn ein Snap?

Ein Snap repräsentiert den kompletten Datenbestand zu einem bestimmten Zeitpunkt inkl dem aktuellen Stand offener Dateien. Das erstmalige Replizieren eines Dateisystems basierend auf einem Snap erstellt eine exakte und komplette Kopie auf einem anderen ZFS Pool der auf dem gleichen oder anderem Server liegt.

Ein erneutes Starten der Replikation kopiert allerdings dann nur noch die Differenz zum folgenden Snap der die Änderungen enthält. Das sind dann im Verhältnis zum ganzen Datenbestand extrem kleine Datenmengen. Gerade dadurch schafft ZFS es ja, ein Storage und einen Backupserver mit geringster Verzögerung z.B. einer Minute syncron zu halten, auch wenn es sich um Petabytes und ein Hochlastsystem handelt. Das Backupsystem kann dann seine eigene Snaphistorie halten.

Lokales Backup auf eine externe Platte ginge per copy order rsync. Dabei wird aber der komplette Datenbestand übertragen oder bei sync abgeglichen. Das kann Stunden dauern während incrementelle Replikation ein komplettes re-sync in Sekunden erledigt - inkl. offener Dateien. Es ist also viel effektiver auf der lokalen Backupplatte ZFS zu nutzen und darauf zu replizieren um die Platte anschließend zu entfernen. Als Bonbon hat man dann dabei noch die ZFS Prüfsummenkontrolle.

Im produktiven Einsatz hat man dazu einen Backupserver zumindest in einem anderen Brandabschnitt. Ich selber habe einen weiteren zweiten Backupserver mit SFP+ im Nebentrakt der nur zum Backup ans Stromnetz geht und damit blitschlagsichere wöchentlich oder monatliche Disasterbackups hält - zum Schutz unserer wichtigsten Archiv und Langzeitdaten.
 
d.h. aber, dass ich z.B. meine USB Backupplatte mit dem ZFS Filesystem "formatieren" muß. Von einem anderen Rechner (z.b. Windows) kann ich die Daten aber nicht sehen/bearbeiten/ect.? Außer das System kann ZFS lesen.
Im Moment mache ich das richtig Oldschool: entweder über Acronis Backup oder über Goodsync einen Syncjob der Daten in die Cloud, bzw. auf USB Platte. bei deiner inc. Replikation müsste die Platte aber immer am System hängen? Bestenfalls mehrere im Wechsel?
 
Ingrate schrieb:
. bei deiner inc. Replikation müsste die Platte aber immer am System hängen? Bestenfalls mehrere im Wechsel?
Zum Vergrößern anklicken....

Nein muss nicht. Man kann den Pool nach der Replikation exportieren und die Platte abstecken und vor der nächsten Replikation wieder anstecken und importieren und den Job dann manuall starten.

Daten auf NTFS würde nur Sinn machen wenn man die woanders zum Bearbeiten mitnehmen möchte. Das ist kein Backup sondern Datentransport (ohne ZFS Sicherheit)
 
noch eine Frage zu ESXi:
mein ESXi bootet von SSD. auf dieser ist auch die napp-it AiO und wird mittels ESXi Autostart beim Hochfahren gestartet. Jetzt habe ich eine Windows VM und eine vCenter TestVM am Start. Diese liegen auf einem NFS freigegeben Dataset des nappit Storage. Beim Start von ESXi wird nappit auch gestartet, jedoch sind Windows und vCenter nicht erreichbar, da sich die nappit AiO erst hochfahren muß. Dann erscheint eine Meldung, dass der Autostart der vCenter VM nicht möglich war. Klar, da ja nappit noch nicht am Start war. Reihenfolge ist richtig gesetzt. zuerst nappit, dann vCenter. Autostart mit 90s. Gibt es da eine "Empfehlung"?
 
Die 90 Sekunden hochsetzen. Bei mir funktioniert das gut mit:

as.jpeg
für die erste VM nach Napp-it
 
Ok, das schein aber schon recht lange zu sein, oder? 300s Startverzögerung? nappit braucht nach ESXi vielleicht gerade mal 60s. Aber da muß ich mich wohl ein wenig herantasten.
 
In der Tat mag das auch kürzer gehen, aber wie oft fährt man denn den ESXI rauf? Sonst kannst Du ja mal die Zeit stoppen, wie lange nach dem Start von Napp-IT bei Dir die VM´s auf dem NFS Storage wieder verfügbar sind.
 
naja - ich möchte für den Heimgebrauch die Kiste nicht 24/7 durchlaufenlassen.
 
ESXi mounted NFS sobald es verfügbar ist automatisch und kann dann die VMs darauf mit Verzögerung autostarten. Wenn der Vsphere Server unbedingt bereits zu Beginn zur Verfügung stehen muss, dann den halt auch auf den lokalen Datastore legen und als erstes noch vor napp-it starten.

Backup der lokalen VMs: Offline als ova Template sichern (bei denen tut sich ja nicht viel)
 
Der Aufwand mit den Snaps und allem, dafür das die Kiste dann ständig aus ist? - ewig viele Plattenstarts sind auch nicht gerade gut für die Disks, sofern das 0815 Platten sind...

Ich hab 240s Start und Stopverzögerung, erst startet die NAS-VM, dann noch die Firewall, die für die Testumgebung mit auf der SSD vom ESX liegt, und dann die anderen VMs, klappt ohne Probleme, hab ich bisher erst 3x gebraucht
 
Wie ich hier andernorts gefragt und gelernt habe (danke!) muss die lange autostart-Verzögerung aber bei der Storage-VM (!!) eingetragen werden und nicht bei den nachfolgend davon startenden VMs.
 
Guten Morgen,

aktuell bin ich am hin- und herüberlegen wie ich meine Storage unter das ESXi bereitstelle.
Und wenn ich es richtig verstanden habe, sollte die hier vorgeschlagene Lösung so wie auf dem Bild dann lauffähig sein. (Sorry ich muss mir sowas immer aufmalen :))
Jetzt ist die Frage, macht es noch Sinn die OS Disk nochmal in einem Mirror Raid zu hängen, wenn man eh schon dabei ist.
 

Anhänge

  • esxi_cluster.png
    esxi_cluster.png
    18,1 KB · Aufrufe: 72
OS Disk kannst nicht sinnvoll Mirrorn, nur wenn du nen HW Raid verwendest.
ESX ist komplett dumm was Arrays betrifft.
 
Deswegen hatte ich mir überlegt den Mirror auf nem Perc 710 laufen zu lassen, also wirklich nur 2 kleine Disks, der Perc wird offiziell unterstützt und "sollte" nativ beim Custom Dell ESXi Image dabei sein (wenn ich es richtig verstanden habe)
Aber das Grundkontrukt sollte so funktionieren, also egal ob mit oder ohne Mirror für die OS Disk?
 
Anmelden, um zu antworten.

Ähnliche Themen

S
Proxmox best practice
Antworten
9
Aufrufe
2K
Str1atum
S
I
Stromverbrauch reduzierbar oder neue HW für NAS?
2 3
Antworten
62
Aufrufe
4K
JVN
J
S
Heimserver / NAS SSD Bestückung
2
Antworten
38
Aufrufe
2K
pwnbert
pwnbert
W
[Kaufberatung] Einsteiger Homelab für HA, Docker, VMs, Plex etc.
Antworten
0
Aufrufe
837
woozaa.™
W
A
Welches Mainboard fuer i5-12400 fuer Home Server/Proxmox Host?
Antworten
8
Aufrufe
1K
s4ndst0rm
S
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh