[SOLVED] PBS / PVE --> iSCSI Speicher nach Netzwerkausfall nicht mehr verfügbar

[Benny2]

Hallo zusammen.
Wir haben den externen Speicher per iSCSI an den PBS angebunden.
Super Geschwindigkeit, zuverlässig usw.
Das lief die letzten Monate echt super, bis jetzt innerhalb von 1 Woche 2x kurz (unter einer Minute) der Strom weg war.
In diesem Fall heißt das, dass die Synology nur vom Netzwerk getrennt wurde, da der Switch nicht an einer USV hängt.
Jetzt zum eigentlichen Problem.
Nachdem alles wieder erreichbar war, war der iSCSI Speicher auf dem PVE nicht mehr verfügbar und im PBS war das ZFS weg.
Somit leider auch die Backups.
Hat jemand eine Idee wie man sowas vorbeugen kann, oder warum das iSCSI Laufwerk nicht mehr eingebunden werden kann?
Auch ein kompletter Neustart hat nichts gebracht.

Vielen Dank

 

[Falk R.]

Zuerst, benutze niemals ZFS auf iSCSI Volumes!!!
Zweitens benutze am besten niemals per Netzwerk angebunden Speicher am PBS.
Naja zu NAS Systemen und iSCSI sage ich mal lieber nix.

Sieht der PBS die iSCSI Disk wieder?
Siehst du da Daten drauf?
Was sagt ein ZFS Pool Import?

 

[Benny2]

Danke für die Hinweise. Das wird so definitiv nicht mehr aufgebaut und iscsi kann mich auch mal ....
Der PBS sieht die iSCSI Disk aber keinen Inhalt.
Der ZFS Pool Import hat nicht funktioniert. Auch eine Reparatur war erfolglos.
Ist jetzt aber auch egal, da der neue Aufbau nicht mehr über den PBS läuft.
Wir hatten damit zu viele Probleme. Auch mit einem Hardware PBS mit 40TB internen Speicher.
Der lief auch eine ganze Zeit einwandfrei und auf einmal ist die Geschwindigkeit auf ein nicht erträgliches Level eingebrochen, so dass Jobs
mehrere Stunden brauchten, die vorher in ein paar Minuten fertig waren. So kam es dann zu o.g. Lösungsweg. Sollte nur eine Übergangslösung sein, bis das Problem am eigentlichen PBS gelöst wurde.

 

[Falk R.]

Danke für die Hinweise. Das wird so definitiv nicht mehr aufgebaut und iscsi kann mich auch mal ....
Der PBS sieht die iSCSI Disk aber keinen Inhalt.
Der ZFS Pool Import hat nicht funktioniert. Auch eine Reparatur war erfolglos.
Ist jetzt aber auch egal, da der neue Aufbau nicht mehr über den PBS läuft.
Wir hatten damit zu viele Probleme. Auch mit einem Hardware PBS mit 40TB internen Speicher.
Der lief auch eine ganze Zeit einwandfrei und auf einmal ist die Geschwindigkeit auf ein nicht erträgliches Level eingebrochen, so dass Jobs
mehrere Stunden brauchten, die vorher in ein paar Minuten fertig waren. So kam es dann zu o.g. Lösungsweg. Sollte nur eine Übergangslösung sein, bis das Problem am eigentlichen PBS gelöst wurde.

Da würde mich mal dein Setup des internen Speichers interessieren. Etwas langsamer ist normal, aber niemals so extrem.

 

[Benny2]

Es sind 7x 4TB Festplatten verbaut (nicht ganz die 40 die ich oben geschrieben hatte). Das Dateisystem ist ZFS.
Als Hardware verwenden wir einen HP DL380 Gen10

 

[Benny2]

So sieht das ganze aus. Dabei ist es egal, ob fleecing ein- oder ausgeschaltet ist.
Der Start ist gut und dann sackt es immer mehr ab (bis auf 2-3 MiB/s)

 

[UdoB]

Es sind 7x 4TB Festplatten verbaut

Welche Topologie? zpool status.

Das Dateisystem ist ZFS.

Auf dem Target, nehme ich an. Richtig?

Mit oder ohne schnellem "Special Device"? Ohne ist Blech meiner Meinung (und eigener Erfahrung) nach nicht für PBS tauglich.

Welches Format hat das PBS-lokale Dateisystem auf dem iSCSI-Device?

Falls das ZFS ist --> #2

 

[news]

Guten Morgen Benny2, bitte veröffentlich doch mal alle Informationen zu deinem ZFS Setup, dem dataset und wie du dieses eingerichtet hattest. UNd sind das ausschließlich HDDs oder auch ein ZFS special die weiß im Einsatz?

 

[Benny2]

Welche Topologie? zpool status.

Auf dem Target, nehme ich an. Richtig?

Mit oder ohne schnellem "Special Device"? Ohne ist Blech meiner Meinung (und eigener Erfahrung) nach nicht für PBS tauglich.

Welches Format hat das PBS-lokale Dateisystem auf dem iSCSI-Device?

Falls das ZFS ist --> #2

Moin.
Ergebnis zpool status


Das Targetsystem ist ZFS.
Was meinst Du mit "Special Device"?

 

[news]

Wie groß ist die Bocksize vom dem zfs raidz1 pool?

 

[Benny2]

Wie groß ist die Bocksize vom dem zfs raidz1 pool?

128k

 

[UdoB]

Ergebnis zpool status

Okay. RaidZ1. Das ist aus meiner Sicht der worst case.

(( Empfohlen ist hier eigentlich immer "striped mirror" (ähnlich Raid10). Nur falls "eine Platte darf ausfallen" nicht genügt, nimmt man RaidZ2 oder Z3 - niemals Raidz, nicht bei den heute üblichen Plattengrößen. ))

Ein RaidZ1 liefert die IOPS einer Festplatte. PBS empfiehlt aus guten Gründen SSDs für den ".chunks"-Ordner. PBS braucht IOPS, IOPS und IOPS.

Was meinst Du mit "Special Device"?

Einen ZFS-Pool-internen "Nachbrenner", der Metadaten (und möglicherweise "kleine Blöcke") aufnimmt.

Das Ding beschleunigt den Zugriff auf einen solchen Pool aus Blech nennenswert. Ich behaupte - ohne konkreten Beleg - dass ich einen Faktor drei bis zehn "spüren" kann.

Da alle Metadaten auf dem SD landen, reduziert sich die Anzahl der notwendigen mechanischen Bewegungen der Platten drastisch.

Such mal nach "Special Device", das wurde vielfach thematisiert, allerdings meist in englisch.

 

[news]

128k

Ok, danke. UdoB hat es schon ausgeführt, dass die Metadaten/ Verwaltungsdaten (und mehr=) auf der SSD landen und die antwortet "sofort".
Dass dann noch alles HDDs bewegt werden und dort für einen Block 128k über 6 Disks + 1 Parity Disk die 128k Daten geschrieben werden, ergibt sich aus dem Design.
Welche Festplatten sind dies nun im detail und sind sie mint SATA II bzw. SATA III angeschlossen?

 

[news]

Wenn ich die ZFS Recorsize Berechnung richtig verstehen, werden die 128k Recorsize in 32 x 4k Blöcke geschrieben.
Auf den 6 Datendisk passen die Daten aber nur im folgenden Format darauf: 6 x 6 x 4k = 36 * 4k.
Somit wird der Speicherplatz auch nicht optimal genutzt.

 

[Benny2]

Ok, danke. UdoB hat es schon ausgeführt, dass die Metadaten/ Verwaltungsdaten (und mehr=) auf der SSD landen und die antwortet "sofort".
Dass dann noch alles HDDs bewegt werden und dort für einen Block 128k über 6 Disks + 1 Parity Disk die 128k Daten geschrieben werden, ergibt sich aus dem Design.
Welche Festplatten sind dies nun im detail und sind sie mint SATA II bzw. SATA III angeschlossen?

bei den Festplatten handelt es sich um SSD`s (Crucial BX500).
Welcher Anschluss am DL380 ist, kann ich nicht sagen.

Wie schon im ersten Post geschrieben, lief das ganze mehrere Monate einwandfrei.

 

[UdoB]

bei den Festplatten handelt es sich um SSD`s (Crucial BX500).

Oh! Das ist gut! (Die hat allerdings kein PLP, wenn ich das richtig sehe. Somit taugt sie nur sehr bedingt.)

Meine Hinweis "liefert IOPS einer Platte" gilt natürlich dennoch - und zwar der langsamsten aller SSDs.

Wie schon im ersten Post geschrieben, lief das ganze mehrere Monate einwandfrei.

Vielleicht ist der Füllstand gestiegen? Und nun sind Caches, die bisher groß genug waren, plötzlich zu klein.

Oder das Wear-Levelling konnte bisher aus dem Vollen schöpfen und muss nun aktiv kämpfen, um angeforderte freie Blöcke zu liefern.

Oder das Fehlen von PLP macht sich eben doch so bemerkbar, wie viele Leute hier behaupten.

Oder der Pool ist einfach voller als ~90 Prozent. (Max. sollte 80% sein.)

Oder ein Device hat "Macken", die "zpool status" nicht sehen kann und ZFS einfach ausbügelt - nach einiger Zeit und mehrfachen Versuchen.

Oder der SMART-selftest ist schon lange her.

Oder das Netzwerk läuft nur noch mit 100 MBit/s statt 10 GBit/s.

Oder die allgemeine Systemlast auf PVE oder PBS ist heute viel größer als damals.

Oder...


Disclaimer: wahllose Hinweise - es kann nicht nur einen Grund geben...

 

[Benny2]

Oh! Das ist gut! (Die hat allerdings kein PLP, wenn ich das richtig sehe. Somit taugt sie nur sehr bedingt.)

Meine Hinweis "liefert IOPS einer Platte" gilt natürlich dennoch - und zwar der langsamsten aller SSDs.



Vielleicht ist der Füllstand gestiegen? Und nun sind Caches, die bisher groß genug waren, plötzlich zu klein.

Oder das Wear-Levelling konnte bisher aus dem Vollen schöpfen und muss nun aktiv kämpfen, um angeforderte freie Blöcke zu liefern.

Oder das Fehlen von PLP macht sich eben doch so bemerkbar, wie viele Leute hier behaupten.

Oder der Pool ist einfach voller als ~90 Prozent. (Max. sollte 80% sein.)

Oder ein Device hat "Macken", die "zpool status" nicht sehen kann und ZFS einfach ausbügelt - nach einiger Zeit und mehrfachen Versuchen.

Oder der SMART-selftest ist schon lange her.

Oder das Netzwerk läuft nur noch mit 100 MBit/s statt 10 GBit/s.

Oder die allgemeine Systemlast auf PVE oder PBS ist heute viel größer als damals.

Oder...


Disclaimer: wahllose Hinweise - es kann nicht nur einen Grund geben...

Ich habe eben den PBS (mehrfach) neu aufgesetzt.
Start läuft super fix und nach ein paar Minuten wieder sehr träge.
Dabei ist das Raid auch egal. Habe fast alle durch ;-)

Die Bootpartition ist allerdings eine 128GB Intenso SSD.
Teste gleich nochmal die Bootpartition auf einer 4TB.


Die Netzwerkanbindung läuft per 10G und wird auch so angezeigt.
Der PBS sowie die PVE`s langweilen sich.

 

[UdoB]

Du kannst auch mal testen, ob sich der ZFS pool so verhält, wie du erwartest. Lege dazu einen neuen Dataset an (zfs create -o compression=off pbspool/fio) und dann teste mit so etwas ähnlichem wie

fio --name=randrw --ioengine=libaio --direct=1 --sync=1 --rw=randrw --bs=4k --numjobs=1 --iodepth=1 --size=20G --runtime=120 --time_based --rwmixread=75

Das ist nur ein Beispiel; je nach "iodepth", "bs" usw. variiert das Ergebnis drastisch. "size" sollte immer nennenswert größer als der ARC sein.

 

[ThoSo]

bei den Festplatten handelt es sich um SSD`s (Crucial BX500).

Die Bootpartition ist allerdings eine 128GB Intenso SSD.

Das sind beides Konsumer, Desktop SSDs, die nicht für den Servereinsatz durch die Hersteller spezifiziert sind, geschweige den für so intensives ZFS Blocksysteme. Crucial gibt da keine Garantie für und Intenso kann alles verbaut sein.
Was haben die noch für eine Lebenserwartung ?
Mich wundert dann auch der Performanceabfall nicht.

 

[Falk R.]

bei den Festplatten handelt es sich um SSD`s (Crucial BX500).

Das erklärt ganz deutlich warum das ganze so einbricht. Da die SSD keinen PLP hat, nutzt diese eine Weile die TLC Zellen als SLC Zellen um den Write zu cachen. Wenn der Cahe voll ist, sinkt die Performance in der Regel unter HDD Niveau, weil das TLC schreiben sehr Zeitintensiv ist.
Wennd ie SSD voller wird, wird auch automatisch der Cache kleiner. Daher wird es auch nur noch langsamer werden.