[Sammelthread] ZFS Stammtisch

[gea]

In den Logs gibt es zwei Angaben, die die vermutliche Ursache zeigen

1. Replikations Einstellungen:
id=1424890615
src_interface=/usr/bin/nc -w 20 192.168.2.220 51135
src_interface2=/var/web-gui/data/tools/nc/nc -b 262144 -w 20 192.168.2.220 51135
snap_name1=pool_aio/aio_vmfs@1424890615_repli_zfs_ripley_nr_56
snap_name2=pool_aio/aio_vmfs@1424890615_repli_zfs_ripley_nr_57
send_inc=-i
snap_rec=
send_rec=
send_dedup=
send_i=-I
transfer_zero=

hier vor allem die Einstellung
send_i=-I

Die bedeutet, dass nicht nur geänderte Daten (56->57) sondern eventuelle Zwischensnaps übertragen werden

2. Receiver Message
<- &my_run line 125 error;, receiver message
cannot restore to pool_ripley/a_aio/aio_vmfs@1424970809_repli_zfs_arche_nr_4: destination already exists

Bei der Replikation versucht zfs receive diesen Zwischensnap anzulegen.
Das scheitert weil es diesen schon gibt - vermutlich weil bei einer früheren Replikation dieser Snap
angelegt wurde, die Replikation insgesamt aus irgendeinem anderen Grund aber scheiterte.

Optionen:
- diesen Zwischensnap löschen
- die Replikation von -I auf -i setzen.

Dann werden keine Zwischensnaps angelegt. Es gibt auch nur wenige Szenarien, wo man alle Snaps die auf dem Quellsystem zwischen den Replikationen angelegt wurden auch auf dem Backupsystem braucht

 

[layerbreak]

In den Logs gibt es zwei Angaben, die die vermutliche Ursache zeigen

1. Replikations Einstellungen:
id=1424890615
src_interface=/usr/bin/nc -w 20 192.168.2.220 51135
src_interface2=/var/web-gui/data/tools/nc/nc -b 262144 -w 20 192.168.2.220 51135
snap_name1=pool_aio/aio_vmfs@1424890615_repli_zfs_ripley_nr_56
snap_name2=pool_aio/aio_vmfs@1424890615_repli_zfs_ripley_nr_57
send_inc=-i
snap_rec=
send_rec=
send_dedup=
send_i=-I
transfer_zero=

hier vor allem die Einstellung
send_i=-I

Sorry, aber was für ein Vollpfosten von den ZFS Entwicklern hat die Buchstaben klein-i und groß-I für diese Option ausgewählt? Mag sein, dass das i für incremental steht, aber er sollte doch auch gewusst haben, dass die Lesbarkeit weniger Buchstaben Schwierigkeiten bringen können.

Was ist jetzt der Unterschied im Log zwischen
send_inc=-i und
send_i=-I

Eingestellt von mir ist groß-I im Setting dieses Snaps.

Die bedeutet, dass nicht nur geänderte Daten (56->57) sondern eventuelle Zwischensnaps übertragen werden

Was sind Zwischensnaps?
Ich hatte es so verstanden, dass bei klein-i ein Snap erstellt wird, der nur die Datenänderungen zwischen Quelle und Ziel erfasst und dann als Repli überträgt.
Groß-I beinhaltet dann noch zusätzlich, die auf dem Quellsystem erstellten Snaps.
z.B. Bei einem aio-FS erstelle ich stündlich einen Snap, also ein Autosnap, auf aio. Abends 22:00 läuft ein RepliJob auf ripley, der dieses FS dann wegsichert.
Ich dachte jetzt so, dass mit der Option groß-I ich ein Backup dieses FS habe und ich bei Bedarf sogar auf einen Datenstand um 13o Uhr oder 17:00 Uhr usw. zurückgreifen könnte.

Du siehst an meiner obigen Post, dass alle Repli-Jobs, welche aio wegsichern, groß-I eingestellt sind.

2. Receiver Message
<- &my_run line 125 error;, receiver message
cannot restore to pool_ripley/a_aio/aio_vmfs@1424970809_repli_zfs_arche_nr_4: destination already exists

Bei der Replikation versucht zfs receive diesen Zwischensnap anzulegen.
Das scheitert weil es diesen schon gibt - vermutlich weil bei einer früheren Replikation dieser Snap
angelegt wurde, die Replikation insgesamt aus irgendeinem anderen Grund aber scheiterte.

Optionen:
- diesen Zwischensnap löschen
- die Replikation von -I auf -i setzen.

Wow, das ist jetzt das Nächste. Dieser Repli-Job wird vom 3. Server arche einmal monatlich erzeugt und nicht vom 2. Server ripley. Quelle ist ja aio.
Der einzige Unterschied zu den vorigen monatl. Repli-Jobs war, dass ich vorher alle ESXi-VMs runtergefahren hatte und dann auf arche den Job angestoßen habe.
Vielleicht erklärt das jetzt auch, dass der Job ripley-aio 3633 Sekunden dauert.
Wo auf welcher Maschine soll ich jetzt diesen Snap löschen?

Dann werden keine Zwischensnaps angelegt. Es gibt auch nur wenige Szenarien, wo man alle Snaps die auf dem Quellsystem zwischen den Replikationen angelegt wurden auch auf dem Backupsystem braucht

Kann ich so einfach die bestehenden Jobs so abändern? Oder ist es besser und sicherer, wenn ich das Ziel-FS neu aufbaue?

 

[gea]

Was ist jetzt der Unterschied im Log zwischen
send_inc=-i und
send_i=-I

send_i legt den send-parameter fest (zfs send -i oder zfs send -I)

Was sind Zwischensnaps?
Ich hatte es so verstanden, dass bei klein-i ein Snap erstellt wird, der nur die Datenänderungen zwischen Quelle und Ziel erfasst und dann als Repli überträgt. Groß-I beinhaltet dann noch zusätzlich, die auf dem Quellsystem erstellten Snaps.
z.B. Bei einem aio-FS erstelle ich stündlich einen Snap, also ein Autosnap, auf aio. Abends 22:00 läuft ein RepliJob auf ripley, der dieses FS dann wegsichert. Ich dachte jetzt so, dass mit der Option groß-I ich ein Backup dieses FS habe und ich bei Bedarf sogar auf einen Datenstand um 13o Uhr oder 17:00 Uhr usw. zurückgreifen könnte.

zfs send -I überträgt clones und snaps mit, die zwischen den beiden Auto-Replikationssnaps angelegt wurden.
Die sind aber ausserhalb der Kontrolle des Replicationsscriptes. Der Parameter -I eignet sich eher für einzelne manuelle Transfers. Für normale Auto-Replikationen -i (das ist die Voreinstellung) benutzen

Um eine Snap-Historie auf dem Backupsystem zu halten, eignet sich -I nicht. Dazu besser z.B. stündlich eine Replikation machen und entsprechen viele Snaps auf dem Backupserver mit Hilfe des hold-Parameters (hold n days) halten.

Wo auf welcher Maschine soll ich jetzt diesen Snap löschen?

ZFS receive meldet dass dieser Snap nicht angelegt werden kann, weil es ihn bereits gibt. Als auf dem Backupserver löschen

Kann ich so einfach die bestehenden Jobs so abändern? Oder ist es besser und sicherer, wenn ich das Ziel-FS neu aufbaue?

Einfach den Zwischen-Snap der die nächste Replikation blockiert löschen oder umbenennen, dann den Parameter auf -i stellen und Replikation erneut starten.

 

[layerbreak]

send_i legt den send-parameter fest (zfs send -i oder zfs send -I)

Und was legt send_inc fest?

zfs send -I überträgt clones und snaps mit, die zwischen den beiden Auto-Replikationssnaps angelegt wurden.

Dann stimmt aber meine Grundüberlegung doch?

Die sind aber ausserhalb der Kontrolle des Replicationsscriptes. Der Parameter -I eignet sich eher für einzelne manuelle Transfers. Für normale Auto-Replikationen -i (das ist die Voreinstellung) benutzen

Um eine Snap-Historie auf dem Backupsystem zu halten, eignet sich -I nicht. Dazu besser z.B. stündlich eine Replikation machen und entsprechen viele Snaps auf dem Backupserver mit Hilfe des hold-Parameters (hold n days) halten.

Danke, guter Vorschlag.
Nur ist es bei mir so, dass der Backupserver nur ein oder zwei Mal pro Monat läuft. Dann werden Backups von aio und ripley von allen FSs gemacht.
ripley läuft nur von 18:00 bis 02:00 Uhr. In der Zeit werden dann die täglichen Repli-Jobs von Server aio getätigt.
Bei deinem Vorschlag müsste ripley dann aber auch den ganzen Tag am Laufen sein.

ZFS receive meldet dass dieser Snap nicht angelegt werden kann, weil es ihn bereits gibt. Als auf dem Backupserver löschen
Einfach den Zwischen-Snap der die nächste Replikation blockiert löschen oder umbenennen, dann den Parameter auf -i stellen und Replikation erneut starten.

Es wäre einfach nett von dir, wenn du es genau benenne könntest, dann verstehe auch ich Dummie es.
Welchen Snap auf dem welchem Backupserver löschen?
Welchen Zwischen-Snap meinst du und wo löschen?

Jetzt rate ich mal - meintest du diesen Snap hier: pool_ripley/a_aio/aio_vmfs@1424970809_repli_zfs_arche_nr_4
Wenn ich aber Diesen lösche, dann funktioniert der Repli-Job ausgehend von arche nicht mehr.

Btw, ich hatte gestern noch gefragt:
Bei Jobs-remote welche Eingaben werden da alles akzeptiert, außer JobID und send?
Vermutlich hattest du es überlesen.

 

[layerbreak]

Sorry, jetzt bin ich aber etwas aufgeschreckt und suche danach, ob meine Backups auch alle richtig funktionieren und vollständig sind.

z.B.
Quelle:
pool_ripley/data@1396803369_repli_zfs_arche_nr_3 Sun May 31 16:27 2015 6.83G - 16.9T
pool_ripley/data@1396803369_repli_zfs_arche_nr_4 Sun Jun 28 16:18 2015 574M - 17.0T
pool_ripley/data@1396803369_repli_zfs_arche_nr_5 Thu Aug 06 21:22 2015 15.1G - 17.4T

Ziel:
p_arche/a_ripley/data@1396803369_repli_zfs_arche_nr_3 Sun May 31 16:27 2015 6.92G - 17.0T
p_arche/a_ripley/data@1396803369_repli_zfs_arche_nr_4 Sun Jun 28 16:18 2015 643M - 17.0T
p_arche/a_ripley/data@1396803369_repli_zfs_arche_nr_5 Thu Aug 06 21:22 2015 0 - 17.4T

Stutzig macht mich jetzt, dass die Werte von used und auch Refer sich unterscheiden, dann noch zusätzlich, dass beim Backup nr 5 used 0 ist.

Ist da alles OK?
Gibt es außerhalb von napp-it eine Möglichkeit auf der Console die beiden Datenbestände zu vergleichen und wenn Unterschiede vorhanden sind zu zeigen welche?

 

[gea]

- send_inc ist obsolet und nur noch wegen der Kompatibilität älteren napp-it Versionen drin

- bei mehreren parallelen Replikationen ist fortlaufendes zfs send -I keine gute Idee.
Replikation fürs Backup mit zfs send -i und dazu Autosnaps auf dem Quellserver für normales undo ist ok

- Backup nur zweimal pro Monat ist immer problematisch.
Bei echten Problemen ist das Backup entsprechend alt. Die Zwischensnaps bringen dann nichts.

- zum Snap löschen - die Fehlermeldung auf dem Backupserver lautet
cannot restore to pool_ripley/a_aio/aio_vmfs@1424970809_repli_zfs_arche_nr_4: destination already exists

Dieser Snap verhindert den Lauf von zfs send -I
Also diesen Snap auf dem Backupserver löschen oder einfach die Replikation auf -i stellen.
Dann wird dieser Snap nicht nochmal übertragen und stört nicht. Am einfachsten alle Replikationen auf -i stellen

- zum Filtern der Anzeige von Jobs-remote
da kann man jede Zeichenkette benutzen. Die Eingabe z.B. von 123 zeigt alle Logeinträge bei denen 123 steht.


- zu used und refer
Das neue Dateisystem kann andere Einstellungen z.B. zu compress haben. Es hat eine andere Fragmentierung.
Die Angaben sind daher nicht identisch

- zu used=0
Das passiert, wenn es keine Datenänderung zum vorherigen Snap gegeben hat, also alles ok

-Unterschiede in snaps zeigen (zfs diff)
Overview of ZFS Snapshots - Oracle Solaris ZFS Administration Guide

alternativ ein Compare tool für SMB oder NFS shares.
Wenn zfs receive aber einen Snap mit einer höheren Nummer anlegt ist alles ok.

 

[layerbreak]

- bei mehreren parallelen Replikationen ist fortlaufendes zfs send -I keine gute Idee.

Ist es OK, wenn ich die täglichen Repl-Jobs von aio auf ripley mit -i mache und nur von aio auf arche das mit -I mache??
Oder anderst gefragt, wann ich die Option -I eine gute Idee?

Replikation fürs Backup mit zfs send -i und dazu Autosnaps auf dem Quellserver für normales undo ist ok

- Backup nur zweimal pro Monat ist immer problematisch.
Bei echten Problemen ist das Backup entsprechend alt. Die Zwischensnaps bringen dann nichts.

Richtig wichtige Daten sind ausschliesslich auf dem Server aio, da mache ich ja auch täglich meine Repli-Jobs auf Server ripley und noch zusätzlich auf meine Win-Kiste.
Auf dem Server arche werden monatlich oder auch alle 2 Wochen die Daten von ripley weg gesichert, wenn da was zwischen den Datenständen verloren geht ist es nicht so tragisch und verkraftbar. Doppelt gemoppelt ist die Sicherung von aio auf arche.

- zum Snap löschen - die Fehlermeldung auf dem Backupserver lautet
cannot restore to pool_ripley/a_aio/aio_vmfs@1424970809_repli_zfs_arche_nr_4: destination already exists

Dieser Snap verhindert den Lauf von zfs send -I
Also diesen Snap auf dem Backupserver löschen oder einfach die Replikation auf -i stellen.
Dann wird dieser Snap nicht nochmal übertragen und stört nicht. Am einfachsten alle Replikationen auf -i stellen

Sodele, wie wir beide Schwaben sagen, jetzt ist der Fehler so weit eingegrenzt und eine echte Lösung hier für die Nachwelt hinterlegt.
Vielen Danke @gea für diese Hilfe.

- zu used und refer
Das neue Dateisystem kann andere Einstellungen z.B. zu compress haben. Es hat eine andere Fragmentierung.
Die Angaben sind daher nicht identisch

- zu used=0
Das passiert, wenn es keine Datenänderung zum vorherigen Snap gegeben hat, also alles ok

Nein keine anderen Einstellungen, bei allen drei Servern gleich - aber ganz sicher hat jeder Server eine andere Fragmentierung und daran wird es liegen, denn ...

-Unterschiede in snaps zeigen (zfs diff)
Overview of ZFS Snapshots - Oracle Solaris ZFS Administration Guide

alternativ ein Compare tool für SMB oder NFS shares.
Wenn zfs receive aber einen Snap mit einer höheren Nummer anlegt ist alles ok.

... ich habe zwar diff als Tool gefunden, aber nicht wie diff über 2 getrennte Server funktioniert, also hab ich einen Vergleich über SMB gemacht und das zeigt mir an, dass beide Datenbestände gleich sind.

Ich liebe Omnios+napp-it+zfs, aber bin einfach zu wenig in der Materie drinne und dadurch gleich immer unsicher und nervös.

 

[gea]

Ist es OK, wenn ich die täglichen Repl-Jobs von aio auf ripley mit -i mache und nur von aio auf arche das mit -I mache??
Oder anderst gefragt, wann ich die Option -I eine gute Idee?

Das Beispiel zeigt gut Vor- und Nachteile
Bei der normalen Replikation mit -i werden zwei Dateisysteme zum Zeitpuunkt der Replikation syncronisiert.
Wurde auf dem Quelldateisystem in der Zwisachenzeit z.B. ein Clone angelegt, so wird der nicht mit übertragen.

Genau dafür ist -I da. Man fällt aber damit z.B. auf die Nase, wenn damit eine Snap übertragen werden soll, der schon zuvor schon durch einen anderen Vorgang angelegt oder übertragen wurde. Auch werden diese Zwischensnaps oder Clone nicht automatisch gelöscht. Das muss manuell geschehen. Insgesamt ist -I ein Sonderfall.

Ich liebe Omnios+napp-it+zfs, aber bin einfach zu wenig in der Materie drinne und dadurch gleich immer unsicher und nervös.

ZFS ist State of the Art, die Formel 1 sozusagen. Bei den gebotenen Funktionen und Features ist es sogar extrem einfach, übersichtlich und überlegt. Für viele andere High-End Technologien gibt es eine Ausbildung und Zeugnisse zum certified (Cisco|Netapp|Novel|Microsoft|whatever) engineer. Nicht immer notwendig, aber Zeichen der Komplexität.

Anfang des Jahrtausends war Sun die technologisch führende Ideenschmiede. 10 Jahre Solaris und ZFS Entwicklung haben nicht nur ZFS als Dateisystem hervorgebracht, sondern extrem viele Funktionen in Solaris und ZFS integriert. Diese Funktionsvielfalt ist es, die einen am Anfang erschlägt. Das was ich in napp-it integriere ist nur der Teil, den man oft braucht. Auch die -I Funktionalität war in früheren Versionen von napp-it noch nicht drin.

 

[layerbreak]

@gea
Nur zur Info:
Beim händischen löschen der Snaps stieg napp-it nach dem 521 Task aus und hat den Rest nicht mehr gelöscht.
Schätze, dass es ein timeout war.

 

[gea]

@gea
Nur zur Info:
Beim händischen löschen der Snaps stieg napp-it nach dem 521 Task aus und hat den Rest nicht mehr gelöscht.
Schätze, dass es ein timeout war.

CGI Applikationen haben ein Timeout.

Für lange Laufzeiten benötigt Background-Tasks (napp-it pro) oder
man muss den Task mehrfach anstossen

 

[Opticum]

gea: bei dem fertigen vmware image von deiner Seite wäre es toll, wenn die HD thin provisioned wäre um nicht 30 GB auf den ESXi schieben zu müssen wenn grad mal 1.5 GB wirklich belegt sind falls möglich, schon mal ein Danke von mir!

 

[layerbreak]

CGI Applikationen haben ein Timeout.

Für lange Laufzeiten benötigt Background-Tasks (napp-it pro) oder
man muss den Task mehrfach anstossen

Ich habe für alle Server die pro-Version und trotzdem wurde abgebrochen.

Anderes Thema:
Bei meinen normalen Snaps hab ich es so eingestellt, dass keep=60 und hold=60 ist.
Ich vermute mal, dass du es so programmiert hast, dass wenn ein neuer Snap angelegt wird, der 61. Snap gelöscht wird und das Programm es nicht so macht, dass alle Snaps die > 60 sind gelöscht werden, denn ich habe jeweils 144 Snaps, die zurück gehen bis Dez. 2014. Vermutlich sind die noch aus der Zeit bevor du die Option keep und hold mit rein genommen hast.

Dann noch eine Frage, beissen sich die zwei Optionen keep und hold nicht gegenseitig? Müsste es nicht richtigerweise entweder keep oder hold heißen? Was macht napp-it, wenn das eine erreicht wird und das zweite noch nicht bzw. vice versa.

 

[gea]

Ich habe für alle Server die pro-Version und trotzdem wurde abgebrochen.

Anderes Thema:
Bei meinen normalen Snaps hab ich es so eingestellt, dass keep=60 und hold=60 ist.
Ich vermute mal, dass du es so programmiert hast, dass wenn ein neuer Snap angelegt wird, der 61. Snap gelöscht wird und das Programm es nicht so macht, dass alle Snaps die > 60 sind gelöscht werden, denn ich habe jeweils 144 Snaps, die zurück gehen bis Dez. 2014. Vermutlich sind die noch aus der Zeit bevor du die Option keep und hold mit rein genommen hast.

Dann noch eine Frage, beissen sich die zwei Optionen keep und hold nicht gegenseitig? Müsste es nicht richtigerweise entweder keep oder hold heißen? Was macht napp-it, wenn das eine erreicht wird und das zweite noch nicht bzw. vice versa.

zum timeout
ein einfaches Snapshot löschen geht immer als cgi-Anwendung
Unter Mass-Delete kann man aber das Löschen als Background Task als Option aktivierem

keep vs hold
Normalerweise setzt man nur keep und legt damit fest, wieviel Snapshots man behalten möchte.
Alternativ kann man zusätzlich einen hold (Tage) Wert setzen.

Gelöscht wird nur dann, wenn beide Werte das zulassen.
z.B. Keep=60 und hold=30 ist so zu verstehen
Halte (mindestens) 60 Snaps, lösche ältere aber nur wenn ein Snap älter ist als 30 Tage (behalte mindestens letzte 30 Tage)

- - - Updated - - -

gea: bei dem fertigen vmware image von deiner Seite wäre es toll, wenn die HD thin provisioned wäre um nicht 30 GB auf den ESXi schieben zu müssen wenn grad mal 1.5 GB wirklich belegt sind falls möglich, schon mal ein Danke von mir!

Eine aktualisierte Version mit aktuellem OmniOS 151014 Stand Juli (mit BE der April-Version) und napp-it 0.9f6 pre
ist als .OVA verfügbar. Import in vsphere mit Menu Datei >> Deploy OFV Template (thin prov)

 

[layerbreak]

zum timeout
ein einfaches Snapshot löschen geht immer als cgi-Anwendung
Unter Mass-Delete kann man aber das Löschen als Background Task als Option aktivierem

keep vs hold
Normalerweise setzt man nur keep und legt damit fest, wieviel Snapshots man behalten möchte.
Alternativ kann man zusätzlich einen hold (Tage) Wert setzen.

Gelöscht wird nur dann, wenn beide Werte das zulassen.
z.B. Keep=60 und hold=30 ist so zu verstehen
Halte (mindestens) 60 Snaps, lösche ältere aber nur wenn ein Snap älter ist als 30 Tage (behalte mindestens letzte 30 Tage)

IMHO ist es dann aber suboptimal, wenn in deinen Standardeinstellungen keep=10 und hold=30 vorgegeben ist.

 

[Opticum]

Eine aktualisierte Version mit aktuellem OmniOS 151014 Stand Juli (mit BE der April-Version) und napp-it 0.9f6 pre
ist als .OVA verfügbar. Import in vsphere mit Menu Datei >> Deploy OFV Template (thin prov)

1000 Dank Gea. Wird zeit das ich mal wieder spende Bitcoin möglich? )

 

[gea]

IMHO ist es dann aber suboptimal, wenn in deinen Standardeinstellungen keep=10 und hold=30 vorgegeben ist.

Das bedeutet lediglich, dass unabhängig von den Timereinstellungen mindestens die letzten 10 Snaps behalten werden. Ausserdem werden Snaps nur gelöscht wenn sie älter als 30 Tage sind.

Man kann aber auch den hold Wert weglassen. Dann bleiben nur die letzten 10 Snaps. Bei einem Snap pro Stunde wären das die letzten 10 Stunden, bei einem Snap pro Tag wären das dann die letzten 10 Tage.

 

[gea]

1000 Dank Gea. Wird zeit das ich mal wieder spende Bitcoin möglich? )

Freut mich dass es gefällt.
Ich habe eben das .ova template nochmal upgedatet und die ESXi tools auf 6.0.0b aktualisiert.
Die Tools von 6.0.0 haben bei shutdown via vsphere einen Kernel Panic erzeugt.

 

[Opticum]

gea: ist der Spenden Button auf deiner Seite verschwunden oder macht es mehr Sinn die Pro für Privat zu erwerben? Ich möchte nur kein Abo da ich das nur als kleine Dateiablage bei mir verwende. Hab letztes mal glaub ich einfach auf deiner Seite einen Paypal Button gehabt.

 

[UweObst]

Hallo Leute,

ich hoffe hier richtig zu sein. Ich betreibe seit ein paar Jahren einen Debian-Server. So weit funktioniert auch alles prima, ZFS, Minidlna, VPN etc. Nun hätte ich aber eine Frage zu ZFS. Als ich den Server aufgebaut hatte, lag meine Priorität bei der Kapazität, so dass ich einen Pool mit 4 HDD in RAIDZ2 eingerichtet habe. Da ich das Volumen nun nicht mehr benötige, mich auch das Aufwecken der Platten nervt, nachdem diese durch hdparm schlafen gegangen sind, und ich einfach Speed brauche, kam mir die Überlegung auf SSD umzusatteln, also ein SSD only Pool. Bei der Suche im Netz bin ich da nicht so fündig geworden, v.a. was die Einrichtung (mirror oder RaidZn) betrifft. Hat jemand von Euch vielleicht Erfahrungen mit einem SSD only Pool und kann mir ein paar Tipps geben?

 

[gea]

gea: ist der Spenden Button auf deiner Seite verschwunden oder macht es mehr Sinn die Pro für Privat zu erwerben? Ich möchte nur kein Abo da ich das nur als kleine Dateiablage bei mir verwende. Hab letztes mal glaub ich einfach auf deiner Seite einen Paypal Button gehabt.

Bei bis zu 1000 Downloads pro Monat waren die Spenden zwischen 20 und 50 Euro/Monat.
Ich hab das daher weggelassen.

Ansonsten ist napp-it Pro kein Abo sondern eine Subscription ohne automatische Verlängerung.
In der Laufzeit gibt es Extrafunktionen und Support/Zugang zu dev und Bugfix Versionen.
Anschliessend ist es einfach wieder die free.

- - - Updated - - -

Hallo Leute,

ich hoffe hier richtig zu sein. Ich betreibe seit ein paar Jahren einen Debian-Server. So weit funktioniert auch alles prima, ZFS, Minidlna, VPN etc. Nun hätte ich aber eine Frage zu ZFS. Als ich den Server aufgebaut hatte, lag meine Priorität bei der Kapazität, so dass ich einen Pool mit 4 HDD in RAIDZ2 eingerichtet habe. Da ich das Volumen nun nicht mehr benötige, mich auch das Aufwecken der Platten nervt, nachdem diese durch hdparm schlafen gegangen sind, und ich einfach Speed brauche, kam mir die Überlegung auf SSD umzusatteln, also ein SSD only Pool. Bei der Suche im Netz bin ich da nicht so fündig geworden, v.a. was die Einrichtung (mirror oder RaidZn) betrifft. Hat jemand von Euch vielleicht Erfahrungen mit einem SSD only Pool und kann mir ein paar Tipps geben?

Ein sehr schnelle Festplatte hat bestenfalls einige Hundert iops/s, eine sehr schnelle SSD einige 10000 iops. Man muss also nicht auf mirrors/ Raid-10 setzen um viele iops zu erhalten. Ein kapazitätsoptimierter Raid-Z Aufbau ist daher ok. Ob Raid-Z1,2 oder 3 hängt von den Sicherheitsanforderungen ab.

Die Probleme mit SSD Raid Pools
- deutlich niedrigere Performance mit small random write (Problem vor allem mit ZFS sync=on)
im Vergleich zu small random read.
- Die allgemeine ZFS Performance geht bei hohem Füllgrad (z.B. 80%) deutlich zurück
Mit SSDs im Raid wird dies deutlich verstärkt. Professionelle SSDs nutzen daher nicht die volle Kapazität.
Eine 480 GB SSD hat oft meist genauso viel Flash eingebaut wie eine andere mit 512 GB.
Erstere hält oft die Schreibperformance auch unter Last

Man kann diese Extra Reservierung auch selber z.B. per HPA/ host protected area aufbringen.
Besser ist es gleich eine entsprechende SSD z.B. bessere Intels oder Sandisk Extreme Pro zu nehmen.

 

[Opticum]

Bei der 1. August OVF hatte ich nun 2x das Problem das der ESXi Host die Verbindung zum NFS Datastore der Napp-IT verloren hat. (Die VMs auf den NFSs verlieren dabei natürlich die Verbindung)

in der Konsole bekomme ich beim Neustart der Napp-IT die Meldung "nfsauth mountd has no established door"
Habe an der gesamten Konfig nur Napp-IT ausgetauscht, ansonsten alles gleich gelassen (ESXi Version nicht geändert)

Gibt es da ein bekanntes Problem?

 

[UweObst]

Ein sehr schnelle Festplatte hat bestenfalls einige Hundert iops/s, eine sehr schnelle SSD einige 10000 iops. Man muss also nicht auf mirrors/ Raid-10 setzen um viele iops zu erhalten. Ein kapazitätsoptimierter Raid-Z Aufbau ist daher ok. Ob Raid-Z1,2 oder 3 hängt von den Sicherheitsanforderungen ab.

Die Probleme mit SSD Raid Pools
- deutlich niedrigere Performance mit small random write (Problem vor allem mit ZFS sync=on)
im Vergleich zu small random read.
- Die allgemeine ZFS Performance geht bei hohem Füllgrad (z.B. 80%) deutlich zurück
Mit SSDs im Raid wird dies deutlich verstärkt. Professionelle SSDs nutzen daher nicht die volle Kapazität.
Eine 480 GB SSD hat oft meist genauso viel Flash eingebaut wie eine andere mit 512 GB.
Erstere hält oft die Schreibperformance auch unter Last

Man kann diese Extra Reservierung auch selber z.B. per HPA/ host protected area aufbringen.
Besser ist es gleich eine entsprechende SSD z.B. bessere Intels oder Sandisk Extreme Pro zu nehmen.

Ok, im Netz ließt man oft, dass ein SSD only Pool nur als Mirror laufen sollte. Warum konnte ich leider nicht herausfinden. Aber es ist gut, wenn auch RaidZn geht. Ich dachte an RaidZ2 mit 6 SSDs (entweder 250 oder 500GB). Viel Speicherplatz brauche ich nicht und die kleineren SSDs sind günstiger. Momentan ist mein Pool 14,6TB groß, aber nur 100GB benutze ich effektiv.

Mit der Sandisk Extreme Pro habe ich schon einige Erfahrung. Sie verrichtet ihren Dienst als Systemplatte. Welche Intel würdest Du empfehlen?

 

[gea]

Bei der 1. August OVF hatte ich nun 2x das Problem das der ESXi Host die Verbindung zum NFS Datastore der Napp-IT verloren hat. (Die VMs auf den NFSs verlieren dabei natürlich die Verbindung)

in der Konsole bekomme ich beim Neustart der Napp-IT die Meldung "nfsauth mountd has no established door"
Habe an der gesamten Konfig nur Napp-IT ausgetauscht, ansonsten alles gleich gelassen (ESXi Version nicht geändert)

Gibt es da ein bekanntes Problem?

ESXi + NFS shared Storage ist genial einfach im Handling, insbesondere in Kombination
mit ZFS, Snaps und parallelem SMB for Copy/Backup/Clone und mit Zugriff auf Snaps mit Windows Previous Versions.

Leider entwickelt jeder NFS eigenständig weiter was immer wieder zu Problemen führt.
Manche ESXi Versionen sind sogar NFS untauglich, z.B. 5.5U1, auch die 6.0.0 gilt als problematisch.
Sehr gut ist die 5.5U2 (alle meine Produktionssysteme laufen damit). Auch die 6.0.0.b scheint ok zu sein.

Auch mit OmniOS zusammen scheint es nicht immer perfekt zu laufen.
Ich selber nutze OmniOS 151014 (April), die aktuelle July Ausgabe hat hat einige Verbesserungen im NFS RAM Handling. Es gibt aber auch Berichte, wonach die Probleme bereitet.

Insgesamt würde ich folgendes versuchen:

- Rechteproblem ausschließen -> alle Files recursiv auf everyone=modify setzen
- NFS.MaxQueueDepth heruntersetzen
VMware KB: NFS connectivity issues on NetApp NFS filers on ESXi 5.x/6.0

- dann e1000 bzw vmxnet3 tauschen

Wenn das nicht hilft, vorerst auf einem älteren ESXi oder OmniOS bleiben.
Die Probleme hängen oft an einer Release auf einer speziellen Hardware

siehe auch (diese beiden US Foren sollte jeder mitlesen der ZFS, zumindest auf Solaris oder OmniOS nutzt)
OpenSolaris derived ZFS NAS/ SAN (Nexenta*, OpenIndiana, Solaris Express) - Page 345 - [H]ard|Forum
https://forums.servethehome.com/index.php?forums/solaris-nexenta-openindiana-and-napp-it.26/

- - - Updated - - -

Welche Intel würdest Du empfehlen?

Professionelle Intel SSD:

S35x0 wenn es eher um Read-Workloads geht
S37x0 (3700, Nachfolger 3710) wenn besonders gute Schreibperformance gefragt ist, gut auch als ZIL geeignet

S3610, eine günstigere Variante der 3710 Serie mit fast so guten Werten.

 

[Opticum]

@Gea: mist, habe ich die alte Napp-It wohl zu früh gelöscht gibt es die passende noch bei dir zu Laden? Würde das nur einfach gern wieder stabil wie vorher am Laufen haben.. das ich vorher kein Backup gezogen habe von der VM ist natürlich mein eigener Bockmist.

 

[gea]

@Gea: mist, habe ich die alte Napp-It wohl zu früh gelöscht gibt es die passende noch bei dir zu Laden? Würde das nur einfach gern wieder stabil wie vorher am Laufen haben.. das ich vorher kein Backup gezogen habe von der VM ist natürlich mein eigener Bockmist.

Die aktuelle VM (OVA Template) enthält die erste 151014 als BE.
Die vorherige Version mit 151012 gibt es natürlich auch noch als download (aber thick provisioned)

 

[Opticum]

@Gea: die hier für 151012? napp-it_15a_vm_for_ESXi_5.0-5.5.zip

 

[gea]

ja, das war die mit dem vorherigen OmniOS 151012
Vmware 5.5 Tools gehen halt nicht mit Esxi 6 (kein vmxnet3, e1000 ist ok)

 

[Opticum]

@Gea: Danke! vllt. wäre zu dem NFS Problem noch eine Warnmeldung angebracht auf der Downloadseite. Schaut ja bestimmt nicht jeder alles durch hier. Man vermutet zunächst andere Ursachen und fängt dann an zu basteln

 

[gea]

Eine Warnung ist nur angebracht, wenn es üblicherweise NFS Probleme gibt, wie z.B. mit ESXi 5.5U1 wo NFS komplett buggy war. Dass eine Person bei Hardforum/STH Probleme mit OmniOS hat während es mit einem alten OI und Solaris geht, sagt nichts aus.

Ich konnte diese Probleme nicht nachvollziehen und habe auch sonst keine besonderen Problemmeldungen erhalten. Klar ist, ESXi ist eine Diva auf unterschiedlicher Hardware und Vmware bringt alle paar Wochen einen Patch für irgendwas. Genauso ist es bei jedem OS. Das einzige was ich mache ist bekannte und besonders stabile oder unstabile Kombinationen zu benennen.

Bei ganz neuen Versionen (OmniOS July Update, ESXi 6.0.0.b) ist aber immer etwas Vorsicht angebracht. Das einzige was ich selber festgestellt habe ist, dass nach einem Update von OmniOS 151014 vom April-> July ein reboot von ESXi erforderlich war.

 

[Opticum]

ich hab jetzt wieder die alte Napp-IT drauf und keine NFS Probleme mehr. Bei den aktuellen OVFs kann ich die Uhr nach stellen das wieder alles offline geht.