[SOLVED] ZFS trim und Geschwindigkeit

[Thomas Stofer]

Einen recht schönen guten Abend,

ich wollte wissen wie ich meine Server für einen Kunden am besten einrichte. Also habe ich ein wenig rum getestet. Da die Server da sind, aber ich wissen wollte was der beste Kompromiss zwischen günstigem Preis für Festplatten und Geschwindigkeit durch den Einsatz von SSD ist, habe ich auf meinem System folgende Dinge getestet:

 pool: rpool
 state: ONLINE
  scan: scrub repaired 0B in 0h13m with 0 errors on Sun Nov 12 00:37:19 2017
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sdb2    ONLINE       0     0     0
            sda2    ONLINE       0     0     0

Das ist der rpool und der besteht aus zwei ssds (Samsung EVO Pro). Daneben habe ich noch folgenden Pool:

 pool: speicher01
 state: ONLINE
  scan: resilvered 48K in 0h0m with 0 errors on Fri Dec  1 00:09:40 2017
config:

        NAME                        STATE     READ WRITE CKSUM
        speicher01                  ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            wwn-0x5000c5007bcf73d1  ONLINE       0     0     0
            wwn-0x5000c5006e4b6f59  ONLINE       0     0     0
        cache
          sdc                       ONLINE       0     0     0

Der besteht aus zwei Seagate Festplatten (Enterprice) mit je 3Terrabytes und einer Samsung EVO Pro als Cache Platte.
Nun habe ich ein Windows10 als Gast auf rpool/data installiert und dort eine Platte eingebunden die auf dem speicher01 Pool liegt. Mit Christal Mark gemessen ist der pool mit den Festplatten und der SSD als cache wesentlich schneller.
Frage: Ist das normal? Sprich: Ist es schlauer gute Festplatten mit SSD als Cache Laufwerke zu betreiben, oder liegt das jetzt daran das die ssd keine Server SSDs sind?
Darüber hinaus habe ich leider discard bei beiden Laufwerken nicht aktiviert. Geht wohl (zumindest über die Gui) nicht nachträglich. Wie entscheidend ist das mit dem Trimen? Ich habe lange in den Englischsprachigen Foren gelesen, aber da reicht mein Englisch wohl nicht ganz aus :-(.
So wäre ich dankbar wenn mir jemand zum Thema SSD, Trimen bei Proxmox mit zfs auf die Sprünge helfen könnte!
(Die Server bekommen keine Consummer ssds ... )

LG
Thomas

 

[wolfgang]

Hallo,

es gibt leider noch kein trim für ZFS on Linux.

 

[Thomas Stofer]

Hallo Wolfgang,

das ist mir schon klar.
Aber was bedeutet das jetzt genau?
Ich habe jetzt mal 4GB große Dateien im Gast gelöscht. Unter zfs wird kein Speicherplatz frei. Auch nicht über Nacht weil ich gelesen habe, das moderne ssds das irgendwie wohl auch lösen? Nur nicht so schnell, deshalb wäre trim jetzt nicht so wichtig... ?????
Kann ich das mit einem Cronjob auch anstoßen, dass als gelöscht markierte Sektoren frei werden? Wenn ja wie? Wenn nein, wie kann ich es dann lösen?
Was ist mit ssd als Cache Speicher? Selbes Problem?
I

LG
Thomas

 

[elurex]

https://github.com/zfsonlinux/zfs/pull/5925#issuecomment-348807407

fast bereit für öffentliche Tests

 

[Thomas Stofer]

Hallo Elurex,

Danke!
Aber mein Englisch reicht dafür leider nicht ganz ...
Ich verstehe so viel das da wohl dran gearbeitet wird und man selber irgend was basteln kann, oder?
Aber das hilft mir nicht, weil da auch meine Linux Kenntnisse nicht ganz für reichen.
Die Frage war eher wie kann ich denn mit dem Problem am Besten umgehen, ohne mir Tagelang was zu bauen von dem ich (leider) keine Ahnung habe.
Ist das Problem überhaupt so groß? Was passiert denn wenn die Platte volläuft, wird das dann langsam oder geht es gar nciht mehr? Kann man von Hand (z.B 1x im Monat, oder Sonntags? einen Cronjob einrichten der die zum Löschen markierten Dateien löscht?
Wenn nur großer umbau des ZFS mit Compilieren und so geht, dann besser nicht zfs?
LG
Thomas

 

[udo]

Hi,
ich kann nur von dem Betrieb der EVOs im Server dringend abraten!
Sowas hat in einem Server nichts zu suchen. Sie werden zuerst super gute Werte liefern, aber irgendwann halt nicht mehr - wenn Du Glück hast nur das. Wenn Du Pech hast, sterben sie dir ohne Vorwarnung weg, wenn zuviel drauf geschrieben wurde.

Bei den Datacenter-Versionen gibt es auch welche die nicht "wahnsinnig" teuer sind, weil die TBW nicht zu hoch ist...

Nur so meine Meinung.

Udo

 

[Thomas Stofer]

Hi Udo,

So wäre ich dankbar wenn mir jemand zum Thema SSD, Trimen bei Proxmox mit zfs auf die Sprünge helfen könnte!
(Die Server bekommen keine Consummer ssds ... )

sehe ich auch so!
Das ist schon klar. Aber im Moment um mal rauszufinden was Geschwindigkeitsmäßig mit und ohne ssd so für Unterschiede aufschlagen, sollte das einen ersten Überblick geben...
Aber die für den Server sind noch nicht da, bzw ich muss sie noch bestellen. Aber dazu sollte ich etwas mehr darüber wissen, was man am besten wie Konfiguriert. Ich bin mir auch nicht sicher was wirklich Sinn macht.
Ich hab auf den Servern jeztzt mal einen Pool mit 10 Platten erstellt. Da bekomme ich schon ohne ssd ordentliche Schreib und Leseraten hin. Wenn ich dann noch auf writeback stelle, dann geht das richtig ab. Aber wie hoch ist das Risiko bei einem Server mit redunanten Netzteilen und mit USV...???
Oder eben bei SSD: Wie wirkt sich das zfs fehlende trimen aus?
Wie wird das am besten konfiguriert?

LG
Thomas

 

[udo]

Hi Udo,
... Aber wie hoch ist das Risiko bei einem Server mit redunanten Netzteilen und mit USV...???

Hallo Thomas,
sorry, dass die EVOs nur zum testen sind und nicht in der richtigen Konfig landen, hatte ich überlesen.

Redundantes Netzteil und USV schützt in Maßen vor einen ungewollten Stromausfall, aber das sind bei weitem nicht alle Fälle, wo man eine DC SSD mit Kondensator zur Cache-Sicherung haben möchte.
Zum Beispiel hilft dies nicht bei einer Kernel Panic oder menschlichen Versagen (eigentlich wollte ich den Server darunter ausschalten...).
In meiner Zeit als Admin hatte ich bis jetzt mehr Fälle, wie Kernel Panic, 17kva-USV wirft kurzzeitig die zu schützende Last ab, defektes redundantes Netzteil lässt Server einfrieren, usw. als Fälle wo ein Netzteil friedlich entschlafen ist oder die USV den Stromausfall puffern musste (geschätzt 'ne handvoll).

Von daher bewerte ich das Risoko als vorhanden...

Udo

 

[Thomas Stofer]

Hi Udo,
ok, das sind durchaus Argumente für die "DC SSD".
Damit meinst Du ssds für server die als Protokolliergeräte in zfs pools eingebunden werden, oder?
Und wie richtest Du so was ein?
Server mit Enterpriceplatten und ssd als cache und ssd als Protokolliergerät?
Oder doch den Pool mit den Maschinen gleich ganz als ssd?
Mir ist schon klar, dass das auf die Anforderungen ankommt. Aber irgendwie wüsste ich schon gerne wie das mit dem Trimen zu bewerten ist. Laufen die SSDs dann voll und werden dann langsam weil vor dem Schreiben erst Platz geschaufelt werden muss?

LG
Thomas

 

[udo]

Hi Udo,
ok, das sind durchaus Argumente für die "DC SSD".
Damit meinst Du ssds für server die als Protokolliergeräte in zfs pools eingebunden werden, oder?
Und wie richtest Du so was ein?
Server mit Enterpriceplatten und ssd als cache und ssd als Protokolliergerät?
Oder doch den Pool mit den Maschinen gleich ganz als ssd?
Mir ist schon klar, dass das auf die Anforderungen ankommt. Aber irgendwie wüsste ich schon gerne wie das mit dem Trimen zu bewerten ist. Laufen die SSDs dann voll und werden dann langsam weil vor dem Schreiben erst Platz geschaufelt werden muss?

LG
Thomas

Hi,
bis jetzt habe ich ein paar Server mit jeweils zwei SSDs als zmirror eingerichtet, und auf dem Storage laufen dann latenzkritische VMs.
Ansonsten habe ich ein Ceph-cluster mit SSDs am laufen.
SSDs als cache für zfs habe ich mal getestet, aber das Ergebnis entsprach überhaupt nicht meiner Vorstellung - von daher kann ich nicht viel dazu sagen.
Um Trim kümmer ich mich bei Enterprise-SSDs eigentlich nicht.

Udo

 

[Thomas Stofer]

Danke! Das ist ja mal wenigstens eine Aussage zu dem Thema
Dann nehme ich mal an, Du hälst auch nichts von writeback in den Cache Einstellungen von Proxmox bei HDs, oder?
So bei großen Datengräbern.... hätte das ja schon was.
Thomas

 

[fireon]

Ich werf hier auch mal kurz ein: Wir hatten auch mal EVO's als Systemdisks im Cephcluster laufen. Dort drauf war PVE auf ZFS im Raid1. Die Teile waren nach nicht mal nem halben Jahr auf 92% verbraucht. Jetzt nach über einem Jahr die Enterprise wo täglich 100erte Gigabytes an Daten drüber gehen, gerade mal 1%

 

[Thomas Stofer]

OK
@fireon: Rein interesse halber, wurdest Du das dann auch für einen "Heimserver" mit vielleicht einem Virtuellen Terminalserver oder Windows, bei dem sich die Daten die drüber gehen eher so im Berich von unter 20GB am Tag bewegen, sehen. Also auch da Enterprice SSD?
Kannst Du vielleicht auch noch was zum Thema SSD Trim bei zfs, oder writeback bei HDDs sagen? Wäre super wenn ich da noch mehr Erfahrungen hören könnte!
LG
Thomas

 

[LnxBil]

Ich werf hier auch mal kurz ein: Wir hatten auch mal EVO's als Systemdisks im Cephcluster laufen. Dort drauf war PVE auf ZFS im Raid1. Die Teile waren nach nicht mal nem halben Jahr auf 92% verbraucht. Jetzt nach über einem Jahr die Enterprise wo täglich 100erte Gigabytes an Daten drüber gehen, gerade mal 1%

Kann ich bestätigen. Hatte auch eine EVO im Laptop mit PVE mal getestet und nach einem Monat waren 15% verbraucht. Problem ist hier write amplification und das ständige synchronisieren von /etc/pve - eigentlich die gleichen Gründe, die auch gegen USB oder MicroSD sprechen.

 

[LnxBil]

Ich habe jetzt mal 4GB große Dateien im Gast gelöscht. Unter zfs wird kein Speicherplatz frei. Auch nicht über Nacht weil ich gelesen habe, das moderne ssds das irgendwie wohl auch lösen? Nur nicht so schnell, deshalb wäre trim jetzt nicht so wichtig... ?????
Kann ich das mit einem Cronjob auch anstoßen, dass als gelöscht markierte Sektoren frei werden? Wenn ja wie? Wenn nein, wie kann ich es dann lösen?

Entweder hab ich die Antwort überlesen oder es hat zu dem Thema noch keiner geantwortet:

Wenn du TRIM im Gast möchtest, musst du es auch im Gast ausführen. Klappt gut und der Speicher wird ein paar Sekunden verzögert (je nach Größe des freigewordenen Speichers) direkt im ZFS sichtbar. Gleiches gilt für Schreiben von Nullen, falls du mal kein TRIM zur Hand hast.

 

[fireon]

Wenn du TRIM im Gast möchtest, musst du es auch im Gast ausführen. Klappt gut und der Speicher wird ein paar Sekunden verzögert (je nach Größe des freigewordenen Speichers) direkt im ZFS sichtbar. Gleiches gilt für Schreiben von Nullen, falls du mal kein TRIM zur Hand hast.

Ja, ist bei Windows und UbuntuLinux default aktiviert. Bei Ubuntu läufts glaub ich einmal in der Woche. Kann man aber auch manuel ausführen.

 

[Thomas Stofer]

Hallo, und danke für die Antworten!!!!!

Das hört sich schon mal gut an...
Bei Windows ist es dann aktiv, wenn Windows eine ssd erkennt, was es wohl bei einer Virtuellen Maschine auf Proxmox -
staun, habs nachgeschaut - auch aktiv ist.
Muss dafür der "discard" Hacken für das Laufwerk in Proxmox gesetzt werden?
Wenn ja: Beim virto Treiber ist das ausgegraut ... wohl Standard, oder?
LG
Thoams

 

[fireon]

Muss dafür der "discard" Hacken für das Laufwerk in Proxmox gesetzt werden?

Ja muss es. Bei Virtio geht das Feature nicht. Musst auf SCSI wechseln. Ist aber kein Problem. Einfach in Windows ein Laufwerk hinzufügen. Treiber von der ISO installieren und dann die anderen auch umstellen. Bei Linux VM's gehts natürlich out of the box.

 

[Thomas Stofer]

Hm,
da stolper ich wo anders drüber, aber zuerst, mit der Antwort ist die Frage beantwortet! Danke!
Ich habe hier auf meinem System eine virtuelle Maschine mit einem IDE Laufwerk installiert. Ändern auf scsi geht in der Gui nicht. Wenn ich es in der Konfig mache bootet die VM nicht mehr (Bootreihenfolge angepasst). Das gleiche passiert mir beim Wechsel von virto Treiber auf scsi bei einer anderen VM auch. Das Proxmox Bios findet dann kein Bootlaufwerk ... :-(
Gibt es da ne Lösung für?
LG
Thomas

 

[HBO]

Lass die VM auf IDE, füge eine 2. HDD mit SCSI hinzu. Die kannste dann nicht nutzen da der Treiber fehlt, also von der VirtIO ISO installieren. Festplatte in Windows einbinden und einmal neustarten. Danach VM runterfahren, die IDE Festplatte löschen (keine Sorge Daten bleiben erhalten, die steht dann als "unused" im GUI). Anschließend die "unused" HDD bearbeiten und auf SCSI stellen, Bootreihenfolge ändern, starten, freuen.