[Sammelthread] ZFS Stammtisch

Wäre eine einzelne 860 Evo okay für ein ZIL/SLOG?

Definitiv nein.
Keine Powerloss Protection, damit untauglich für ein Slog das den Ramcache bei einem Absturz/Stromausfall sichern soll. Dazu kommt dass die Desktop NVMes bei dauerhaftem Schreiben in der Performance nach einiger Zeit heftig einbrechen. Latenz und iops sind auch nicht berauschend.

Wenn man ein billiges Slog braucht, dann eine gebrauchte Intel Sata SSD DC 3700 suchen. Bei SAS ist eine WD SS530 top und bei NVMe eine Intel Optane ab Optane 800, besser 900 wegen der besseren Langlebigkeit/ erlaubte Schreibmenge eine ordentliche Option für Home/Lab. Eine Intel DC 4801x ist das Mass der Dinge für ein Slog wenn man produktiv damit arbeiten möchte.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.

Bei den Preisen für die kleine Optane lohnt es nicht wirklich was anderes zu suchen...wenn man damit leben kann dass man Ggf noch Adapter bzw Kabel kaufen muss - je nach Board und Bestand.

Quasi die Raptor unter den SSD. ;)
 
Zuletzt bearbeitet:
Wir sind hier noch immer im Home-Bereich. D.h. ich will nicht Unmengen an Geld für ein wenig Nerd-Faktor ausgeben. Ich habe halt noch einen einzelnen Platz in meinem R710 frei (im CD-ROM Schacht) und würde den gerne sinnvoll nutzen. Habe 4 evo 860 im Striped Mirror und noch 4x 3 TB 2.5" HDDs, ebenfalls im Striped Mirror.
 
Das mag schon sein, nur ist ein SLOG device halt der falsche Punkt um den Rotstift anzusetzen, wenn man nicht den Daten „bitweise“ beim Schreiben zusehen möchte.

Gerade weil es die optane relativ günstig gibt.

Aber teste es mit der 860 -vlt langt dir ja die Performance.
 
@MisterY
IMHO wird das Thema slog meistens völlig falsch verstanden, es handelt sich nicht um einen schreib-cache, ein schnelles slog hilft überhaupt nur dann, wenn synchrones schreiben angefordert wird. Und dann muss man sich noch fragen, ob man es wirklich braucht, grade im Home Bereich. Schneller als zfs set sync=disabled gehts nämlich nicht.
Hast du überhaupt eine Anwendung für synchrones schreiben?
 
Ein Slog ist ein Highend Storage Feature, vergleichbar zu einem teuren Hardware Raidcontroller mit Cache Absicherung per BBU/Flash. Ein Slog braucht man nur dann wenn man sicheres sync Schreiben haben möchte (kein Datenverlust bestätigter Schreibvorgänge beim Absturz während einer Schreibaktion).

Da sync normalerweise einem massiven Einbruch der Schreibleistung zur Folge hat (Platten Pool async: 1000 MB/s und mit Sync 50 MB/s) setzt man ein schnelles Slog zur Protokollierung ein. In obigem Pool landet man dann mit einem sehr schnellen Slog vielleicht bei 500-800 MB/s sync write.

Ergo:
Selbst ein ultraschnelles Slog, nochmal schneller als eine Optane NVMe 4801 wie Optane persistent memory, https://www.intel.de/content/www/de/de/architecture-and-technology/optane-dc-persistent-memory.html würde immer noch bedeuten dass ein Pool mit sync und einem derartigen Slog langsamer ist als ein pool ohne sync (Slog egal da nicht genutzt).

Insgesamt muss man aber das Gesamtsystem beachten. At home, mit einem SSD pool ohne powerloss protection muss man eh Abstriche in der Sicherheit hinnehmen. Auch ein Slog mit powerloss protection sorgt da ja nicht dafür dass der Pool garantiert alles enthält was geschrieben und bestätigt wurde. Da sync deaktivieren oder auf den Evo aktivieren und die onpool ZIL Protokollierung nutzen. Ein extra Slog auf dem evo pool bringt wenig zusätzliche Performance und Sicherheit.

Für den Plattenpool könnte ein Slog sync write erheblich beschleunigen. Da man da aber meist keine VMs oder Datenbanken liegen hat, ist ein Slog wenig sinnvoll. Da einfach sync deaktivieren und volle Performance haben.
 
würde den gerne sinnvoll nutzen.
Das ist der Punkt - brauchst Du sync writes? Wenn ja, brauchst Du schnelle sync writes? Wenn beides ja: Kauf eine geeignete SSD mit full powerloss protection. Wenn nur erste Frage ja oder beide nein: lass es wie es ist, ein slog ist nicht notwendig/sinnvoll.
 
Hi

Ich habe einen ESXi AiO mit napp-it und NFS. Am napp-it habe ich zwei Netzwerkadpter, einmal das management VLAN und einmal das normale LAN. Das management VLAN hat keinen Zugriff ins Internet, und da drüber läuft auch NFS.

Nun kann ich napp-it nicht mehr updaten, die Seite läd ewig mit "wird berbeitet", oder so. Ich nehme an, napp-it versucht über die falsche NIC raus zu funken. Wie bringe ich napp-it dazu, den zweiten Adapter fürs update zu nutzen?

Und kann ich napp-it updaten, wenn die VMs auf dem NFS share am laufen sind? Oder muss ich da alle VMs runter fahren?

Gruss und danke
 
napp-it ist "nur" eine Oberfläche und die läßt sich problemlos updaten.

Hinsichtlich Gateway bin ich wegen VLAN überfragt.
 
Napp it Update ist unabhängig von NFS Zugriff auf das zugrundeliegende OS (vermutlich: OmniOS). VMs können also weiterlaufen.

Mal probiert, napp-IT neu von der Kommandozeile zu installieren?
 
Um napp-it upzudaten (oder zu installieren) brauchts Internetzugriff. Egal ob mit mehreren Nics oder mit vnics und vlans, eine der Nics muss im Netz des Internetrouters sein und dafür muss das Gateway (ip des Routers) gesetzt sein.

Ansonsten lauschen alle Dienste auf allen Nics solange man das nicht per Firewall eingrenzt bzw. den napp-it Management Zugang in den Einstellungen auf ein bestimmtes Netz begrenzt.

Ob Internet geht kann man durch einen Ping auf eine Adresse testen, z.B. "ping 8.8.8.8". Da antwortet der Google DNS Server.

Alle Dienste laufen unabhängig von napp-it. Man kann napp-it updaten oder deaktivieren ohne dass Dienste betroffen sind.
 
Ja danke!

Beim per SSH Ping wird folgendes ausgegeben:

Code:
Last login: Wed Jul  8 23:17:42 2020 from 192.168.xxx.xxx
OmniOS 5.11     omnios-r151026-673c59f55d       May 2018
root@napp-it-026:~# ping 8.8.8.8
8.8.8.8 is alive

Das mit der Antwort "8.8.8.8 alive" habe ich noch nie gesehen. Müsste der Ping nicht paarmal die Antwort vom Server und die ms zurückgeben?

Früher gabs im napp-it Webadmin mal eine eigene cmd/shell Seite. Gibts die nicht mehr? Den cmd Button oben rechts habe ich entdeckt.

Edit: hmmm, habe mal die management vNIC deaktiviert, dann geht das Update. War wohl eine dumme Idee mit laufenden Gästen. Lustigerweise laufen die VMs immer noch, aber kurzeitig flog ein Client raus aus ner Server VM.

Verstehe wer will, ich geh mal chillen.
 
Zuletzt bearbeitet:
CLI Befehle kann man direkt in der webui eingeben (rechts oben im cmd Feld) sofern man als admin angemeldet ist. Da der Ping funktioniert (je nach OS antwortet der unterschiedlich), ein Update aber nicht, fehlt vermutlich der DNS Eintrag. Den liefert ein DHCP Server oder bei manueller Konfiguration trägt man den in System > Network Eth > DNS ein (Telekom Router ip oder Google 8.8.8.8)

Zieht man den VMs den Storage unter den Füßen weg, laufen die noch bis zum ersten Schreib/Leseversuch.


Zum Update auf ein aktuelles OmniOS, erst auf 151030 lts gehen, dann auf die aktuelle 151034
Siehe Punkt 4. in https://napp-it.org/manuals

oder ein aktuelles ova Template mit OmniOS 151034 importieren
 
Hi

Ich habe einen ESXi AiO mit napp-it und NFS. Am napp-it habe ich zwei Netzwerkadpter, einmal das management VLAN und einmal das normale LAN. Das management VLAN hat keinen Zugriff ins Internet, und da drüber läuft auch NFS.

Nun kann ich napp-it nicht mehr updaten, die Seite läd ewig mit "wird berbeitet", oder so. Ich nehme an, napp-it versucht über die falsche NIC raus zu funken. Wie bringe ich napp-it dazu, den zweiten Adapter fürs update zu nutzen?

Und kann ich napp-it updaten, wenn die VMs auf dem NFS share am laufen sind? Oder muss ich da alle VMs runter fahren?

Gruss und danke

Wie hast Du die NICs konfiguriert? OmniOS ist mega zickig, wenn Du einfach zwei Portgruppen von einem vSwitch nimmst. Da ist das Routing absoluter Murks.

Am Besten einen neuen vSwitch für SAN erstellen ohne Uplink! Dazu dann eine vKernel-NIC mit VLAN und fester IP. Dann zusätzlich eine Portgruppe mit gleichem VLAN. Die weisst Du der napp-it zu. Der vergibst Du dann eine feste IP aus dem Bereich der vKernel-NIC und connectest dann im ESXI das NFS Filesystem auf die feste IP der napp-it. Dann läuft das nur über den ESXI und nicht mehr übers Netz.

Die zweite NIC konfigurierst Du mit einer Portgruppe aus Deinem Netz und vergibst auch eine feste IP aus dem Subnetz. Darüber läuft dann das Webif, cifs, nfs und was Du noch so alles anbietest. Und natürlich der Inet-Zugriff.

Ist nen bischen Arbeit, aber lohnt sich. Performance gefühlt x3 und ich hab hier netztechnisch professionelle 19“ Geräte, aber hatte immer mal wieder Latenzprobleme mit dem NFS. Mit zwei NICs hat es vorher NIE sauber funktioniert.
 
Zuletzt bearbeitet:
Ich habe zwei vNICs am napp-it, einmal das managment Netz auf einem vSwitch, einmal LAN am anderen vSwitch. Am Management vSwitch hängt noch der vmKernel für den vSphere Zugriff, und da gibts kein Internet nach draussen. Aber hängt schon auch an der Firewall, und ist einfach vom LAN aus da drauf beregelt.

Fixe IP gibts bei mir systemweit nirgends, da wird alles per DHCP bezogen (ohje, an 17 vSwitches am Mainserver, Ali Du Messie...).

Naja, zuerst hatte ich nur das management Netz am napp-it, und vom LAN für SMB dahin beregelt. Da war mir der SMB Zugriff aber zu lahm geroutet. Da liefs nur noch mit 50 MB/s beim kopieren vom VM Storage. Aber das wär mir die liebste Lösung so. Läuft an einer Zywall 110, die sollte eigentlich genug Dampf haben. VM Storage ist auch lahm, vor allem beim schreiben. 2TB Consumer Crap SSD, da gehts in den VMs echt lahmarschig zu und her. Nur leider in nächster Zeit ganz andere Pläne als die zu ersetzen.

Mit Deiner drei vSwitches Variante tönt auch noch interessant, hab ich noch nie so gehört. Da müsste ich einfach einen dritten vSwitch erstellen ohne Uplink, und NFS dahin verfrachten?

Dazu dann eine vKernel-NIC mit VLAN und fester IP. Dann zusätzlich eine Portgruppe mit gleichem VLAN.

Für was brauche ich da VLANs und eine zweite Portgruppe? Du meinst den NFS vSwitch ohne Uplink, oder?

Ich glaube, ich werde zum testen mal die Reihenfolge der NICs tauschen, dann gehts sicher mit den Updates. Aber vorläufig kann ich keine downtime gebrauchen, ich warte da noch ein paar Wochen. Und dann werde ich halt die LAN vNIC bei Bedarf für Updates und Samba von Hand aktivieren. Brauch ich nicht so oft, gesichert wird da selten. Ist mehr so ein Anwendungsserver, das macht er aber ganz passabel.

btw. fand ich die Netzwerk Konfiguration mit dem alten vSphere Client intuitiver und einfacher. Da die Netzwerkübersicht, wo man alle vSwitches übereinaner sieht, die vermisse ich echt.
 
Zuletzt bearbeitet:
Ich habe aktuell ein Snapshot-Problem.
Ich mache täglich über die ESXi-Snaphots in napp-it einen Snap meiner ESXi-VMs, einmal wöchentlich jedoch per Script einen Snap mit allen VMs in ausgeschaltetem Zustand. Diesen Snap schicke ich dann per ZFS SEND im ersten Schritt auf einen anderen Pool (WDBLACK) und regelmäßig von dort aus auf einen Backup-Server. Nun habe ich allerdings das Problem, dass es - warum auch immer - auf dem Snapshot auf dem Pool WDBLACK Veränderungen gegeben hat (in der Liste der Snaps werden 153K angezeigt). Üblicherweise fange ich das in meinem Backup-Script ab, in dem ich auf dem Ziel-Snapshot (also Pool WDBLACK) ein Rollback auf dem letzten Snap mache. Dies gelingt mir nun weder mit meinem Script, noch per "zfs rollback -r WDBLACK/snapname". Auch aus napp-it heraus werden nach dem Rollback weiterhin 153K "used" angezeigt.
Fehlermeldungen erhalte ich keine.
Ein "zfs send" auf den entsprechend veränderten Snap ist somit natürlich nicht möglich.

Jemand eine Idee, warum der Rollback nicht funktioniert?
 
Das Problem ist hier, dass eine Daisy-Chain Replikation A > B > C versucht wird. Das geht nicht so einfach (Ich bin geade dabei mir ein Verfahren zu überlegen). Das Problem ist ja dass bei einer Replikation A > B das B Dateisystem vor einer Replikation auf den gemeinsamen Snap A/B zurückgesetzt wird. Hatte man davor eine Replikation B > C gestartet so wird dabei auf B der gemeinsame Snap B/C durch das Rollback gelöscht. Die Replikation A > B müsste also dafür sorgen dass B > C funktionieren kann und B > C selber keine Snaps auf B anlegt sondern einfach den letzten auf B benutzt.

Workaround üblicherweise: Kein Daisy Chain sondern A > B und A > C Replikation.
 
Zuletzt bearbeitet:
Meine Erfahrung: Daisy Chain für backups ist in der Tat sehr zickig und scheitert ohne Rollback sehr schnell (siehe zB https://github.com/jimsalterjrs/sanoid/issues/568).

Was allerdings mE schon sinnvoll geht, ist backups replizieren A > B > C, wenn man hinreichend regelmäßige langfristige snaps hat - denn den snap "letzten Sonntag" kann ich sowohl A > B replizieren als dann auch B > C und ein paar Tage später dann den incremental "letzten Sonntag ./. vorgestern" von A > B und weiter B > C. Zuverlässig funktioniert das dann aber auch nur mit rollback.

Mit speziellen replikations-tool-snaps geht das allerdings nicht, da kommt es dann zu den von gea genannten Problemen (sync-snap A/B != sync-snap B/C).
 
Danke für euer Feedback.
Bei mir ist es in der Tat so, dass B unverändert sein sollte. Das hat auch bisher problemlos funktioniert. Der aktuelle Stand von B ist noch gar nicht auf C repliziert, trotzdem kann ich keine neue Replikation A > B anlegen, da der Snap auf B verändert wurde - ich kann zwar den Rollback auf B ohne Fehlermeldung ausführen, trotzdem werden mir aber direkt nach dem Rollback weiterhin 153K als "used" angezeigt und die Replikation scheitert...
 
DAS hat funktioniert - Danke!
Warum allerdings das ganze mit Rollback und unmittelbar danach laufender Replikation nicht geht, erschliesst sich mir nicht. Genauso, warum auf dem eben vor einer Minute angelegten neuen Snap auf "B" schon wieder 128K als "used" angezeigt werden. Anscheinend gibt es da "etwas", dass auf das Filesystem schreibt und unmittelbar nach einem Snap bzw. Rollback etwas verändert. Ideen, wo man da ansetzen kann?
 
Probleme kann ein normaler Autosnap verursachen der auf einem Replikations Ziel läuft, vor allem dann wenn man delzero aktiviert hat. Dabei wird der letzte Replikationssnap (size=0) um einen Autosnap ergänzt. Wird der gelöscht kann das Auswirkungen auf den vorherigen Replikationssnap haben. Auch wenn der folgende Autosnap > 0 ist und man den löscht, kann das Probleme hervorrufen. Daher sollte man Replikations-Versionierung über den Replikationsjob erledigen (keep, hold) und keine zusätzlichen Autosnaps auf einem Replikationsziel laufen lassen.

Die incrementelle Replikation erwartet halt ein exakt identisches Snap-Paar.
 
"B" (und auch "C") sind nicht Ziel von automatisierten Snaps aus napp-it, sondern werden lediglich über einfache Scripts versorgt. Dies läuft ausschliesslich über klassisches "zfs send -i ... | zfs receive...".
Der Ansatzpunkt zur Lösung des Problems ist glaube ich einfacher: Warum gibt es nach einer frischen Replikation Veränderungen im Snap, obwohl "offensichtlich" auf den Snap nicht geschrieben wurde (kein SMB-Share gesetzt, keine NFS Zugriff)...?
 
Napp-it nutzt auch nur klassisches zfs send, es gibt ja auch nichts anderes. Die Prinzipien sind aber immer gleich, egal ob napp-it script oder eigene scripte.

Prinzipiell muss es so sein. Eine inkrementelle Replikation benötigt ein Snappaar snap1 und snap2. Vor der Replikation macht das Ziel ein Rollback auf Snap1, dann wird snap 2 (enthält die veränderten Bytes zu Snap 1) übertragen. Anschließend sind beide Dateisysteme identisch und es wird durch die Replikation ein snap2 auf dem Ziel angelegt. Dieser Snap 2 hat zu dem Zeitpunkt die Größe 0 da es zwischen Snap und Dateisystem keinen Unterschied gibt. Würde man jetzt etwas auf das Ziel Dateisystem schreiben (wäre beim nächsten Replikationslauf verloren wegen rollback), so bliebe der Snap immer noch 0. Nur wenn man etwas löscht ändert sich die Snap size denn dann entspricht die Snapsize den gelöschten Daten da diese ja über den Snap wiederherstellbar sein sollen.

Ein Snap ist nicht beschreibbar, es ist ein Freeze des vorherigen Datenstands eines Copy on Write Dateisystems. Da wird bei einer Schreibaktion ja kein Datenblock überschrieben sondern immer neu angelegt. Der vorherige Stand wird als wieder beschreibbar gekennzeichnet ("frei") oder wenn man einen Snap hat durch diesen Snap gesperrt.

Macht man kein Rollback auf dem Ziel (-F) so läuft die Replikation nur weiter, wenn man das Dateisystem nicht verändert hat. Wenn man eine Daisy Chain Replikation B > C möchte, so muss man ja üblicherweise dafür ein neues Snap auf B anlegen. Dies verändert B so dass ohne Rollback keine Replikation A > B mehr möglich ist. Mit Rollback verliert B > C den Basissnap auf B.
 
Zuletzt bearbeitet:
Wenn man eine Daisy Chain Replikation B > C möchte, so muss man ja üblicherweise dafür ein neues Snap auf B anlegen.
Warum? Ich habe doch schon ein neues snap, nämlich den von A replizierten snap2.

Den kann ich nach C replizieren, ohne B zu verändern.
 
Wenn man das konsequent so beibehält, passt das.
Wenn man das "mit Hirn und Bedacht" macht, kein Problem, Script basiert und automatisiert wird es aufwändiger.
 
Ich sehe es wie asche77. Sofern B nicht verändert wird, spricht ja nichts dagegen, diesen nach C zu replizieren. Wo das Problem liegen soll, das per Script und automatisch zu machen, erschliesst sich mir nicht (immer unter der Voraussetzung, dass auf B nicht gearbeitet wird). Ich habe das seit mehreren Jahren per Script im Einsatz und hatte bisher noch nie Probleme - bis auf das aktuelle Thema von oben.

Das beschriebene Problem liegt - wenn ich nicht alles vollkommen falsch verstehe - auch nicht an der Daisy Chain. B war zum aktuellen Zeitpunkt noch gar nicht auf C repliziert (erfolgt nur unregelmäßig), aber die wöchentliche Replikation A > B ist gescheitert, weil es auf B Veränderungen gab. Diese ließen sich merkwürdigerweise nicht durch ein Rollback entfernen (bzw. es gab scheinbar unmittelbar nach dem Rollback erneute Veränderungen). Bei der Replikation mit Parameter -F hat es dann allerdings funktioniert.

Die Frage für mich ist rückblickend dann eher, wie es zu den Veränderungen auf B kommt. Wie gesagt: B ist ein reines Datengrab, kein SMB, kein NFS - woher kommt die Veränderung?
 
Moin, ich tausche gerade meine WD RED 6TB gegen Seagate Exos X10 mit 10TB in einem Raid-Z2-Pool. Bei Replacen einer Platte liegt man bei knapp 30 Std. Resilvern (2x) und dann noch der Scrub hinterher mit nochmal 15 Std. Schon heftig...

Das Resilvern läuft immer zweimal, ist das normal?

Kann man das irgendwie beschleunigen?
 
Warum kein zfs send | zfs receive?
 
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