[Sammelthread] ZFS Stammtisch

[gea]

Ich hatte noch keinen 9300-16.
Ich habe aber mehrere 9300-8i. Damit hatte ich noch keine Probleme.
Man bräuchte jetzt halt ein zweites Exemplar um einen Defekt auszuschließen.

Alternativ könnte man noch eine andere Firmware probieren, zumal im Log ein Firmware Fault steht.

 

[effemmess]

Ach menno!

Ein 2. Exemplar hab ich natürlich nicht in der Schublade...
Hab jetzt Firmware 10,11,12 durchprobiert, OmniOS stable und bloody, verschiedene Mobo-BIOS-Einstellungen und und und... immer der selbe Mist...
Hab den HBA mal zwischnzeitlich in einem HP-Server eingesetzt - ohne Probleme. Allerdings weiß ich grad nicht mehr, ob ich da auch genug Daten geschaufelt habe - das Problem tritt ja erst nach einer bestimmten Zeit auf. Auch weiß ich grad nicht, ob der HBA dort in einem PCIe 2.0 oder 3.0 Slot saß. Auf dem Supermicro sitzt er in Slot3 PCIe 3.0 X16. Ob es daran liegt???

@gea
Hast du deinen 9300-8i per passthrough durchgereicht? Hast du besondere BIOS-Einstellungen?

 

[gea]

Ich habe 2 x 9300-8, einen in einem Barebone System und einen in einem Testsystem. Da hatte ich auch schon kurz ein AiO Sysem mit pass-through, habe da aber lediglich einen NVMe Test gemacht. Den muss ich nach meinem Urlaub widerholen. Es gibt ja einen NVMe Treiberupdate in der aktuellen OmniOS Bloody.

Insgesamt sind aber zumindest in den diversen Foren und Maillisten keine Probleme mit 9300-8 bekannt. Der 8er ist sehr gängig, der 16er aber eher selten. Es sollten aber "eigentlich" keine Unterschiede bestehen. Was ich noch probieren würde, ist ein Test ohne die SSD. Die Fastpath Meldung scheint sich ja auf die SSD zu beziehen. Irritierend ist lediglich der Firmware Error.

Aber in der Tat, wenn es die SSD nicht sind, bräuchte man einen zweiten Controller für einen A-B Vergleich, alternativ der Test in einem anderen System oder OS um Probleme damit auszuschließen.

 

[fr34k4d3113]

Anderes Thema:
Da ich immer total wankelmütig bin, überlege ich gerade meinen SSD Raid1 für die VMs aufzulösen und die VMs auf das RaidZ2 der HDDs zu legen. Die Consumer SSDs dann als ZIL und LARC2 zu verwenden. Wäre da die Performance mit ca. 10 VMs noch okay, oder darf ich mit bootzeiten von 2 min für ne Linux VM rechnen?

Hast du das Thema bereits weiterverfolgt? Ich stehe so ein bisschen vor der gleichen Frage für einen ähnlichen Use Case (VMs auf SSD oder mit auf das RaidZ2 aber dann mit ZIL/L2ARC) und bin mir noch unschlüssig. Bei mir ist zusätzlich noch der Fall, dass die SSDs für meine VMs eher zu klein sind und ich daher trotzdem noch das Z2 als zusätzlichen Storage einbinden müsste.

 

[gea]

Wenn es nicht nur darum geht Altmaterial weiterzuverwenden ist ganz klar

Eine Platte hat ca 100-200 iops, eine SSD 5000-50000
Performance besonders für VM Umgebungen geht daher nur über SSD Pools

Ein L2ARC ist ein sehr schlechter und langsamer Ersatz für ARC (rambasierter Cache).
Macht nur Sinn wenn mehr RAM nicht geht und selbst dann ist es oft unsinnig da kaum genutzt (ARC/L2ARC Auslastung prüfen)

Ein Slog als ZIL macht um so mehr Sinn, je langsamer der Pool.
Ein Pool aus guten SSD braucht das nicht und ist dennoch schneller als eine einzelne SSD als Slog.

Die sinnvollste Option ist
- SSD only Pool aus guten SSD (high iops, powerloss Protection) für VMs - ohne L2ARC und Slog.
- Diskpool als Backup und general use/Filer

 

[effemmess]

Ich habe 2 x 9300-8, einen in einem Barebone System und einen in einem Testsystem. Da hatte ich auch schon kurz ein AiO Sysem mit pass-through, ...

Insgesamt sind aber zumindest in den diversen Foren und Maillisten keine Probleme mit 9300-8 bekannt. Der 8er ist sehr gängig, der 16er aber eher selten. Es sollten aber "eigentlich" keine Unterschiede bestehen. Was ich noch probieren würde, ist ein Test ohne die SSD. Die Fastpath Meldung scheint sich ja auf die SSD zu beziehen. Irritierend ist lediglich der Firmware Error.

Aber in der Tat, wenn es die SSD nicht sind, bräuchte man einen zweiten Controller für einen A-B Vergleich, alternativ der Test in einem anderen System oder OS um Probleme damit auszuschließen.

Ich konnte den Fehler insoweit eingrenzen, dass er in Slot 3 (PCIe 3.0 X16 an CPU1) reproduzierbar ist. Im Gegensatz dazu tritt er in Slot5 (PCIe 3.0 X16 an CPU2) und Slot6 (PCIe 3.0 X8 an CPU2) nie auf - auch nicht nach 20min Dauerbefeuerung über Infiniband. Ich hatte ja erst auf ein Hitzeproblem getippt, da das Teil super-heiß wird. Allerdings gab es bei den Tests in Slot5 und 6 auch ohne extra Lüfter keine Probleme. Auch die Tests ohne SSDs liefern dieselben Ergebnisse.
Naja, nach 50h Fehleranalyse warte ich nun auf Rückmeldungen vom Lieferanten/Hersteller...

Da hatte ich auch schon kurz ein AiO Sysem mit pass-through, habe da aber lediglich einen NVMe Test gemacht. Den muss ich nach meinem Urlaub widerholen. Es gibt ja einen NVMe Treiberupdate in der aktuellen OmniOS Bloody.

Ja, das habe ich auch gesehen. Aber ich hab auch gesehen, dass Hans nach der Bloody-Veröffentlichung weitere Bugs entfernt hat. Wie bekomm ich denn diese Änderungen in mein System - per pkg update kommen die nicht. Aber ich komm eh grad nicht dazu dies zu testen - zumal Hans' Extra-Spezial-nur-für-mich-privat-Hack bisher bestens funktioniert.


PS: Urlaub wird überbewertet!

 

[gea]

Ich konnte den Fehler insoweit eingrenzen, dass er in Slot 3 (PCIe 3.0 X16 an CPU1) reproduzierbar ist. Im Gegensatz dazu tritt er in Slot5 (PCIe 3.0 X16 an CPU2) und Slot6 (PCIe 3.0 X8 an CPU2) nie auf - auch nicht nach 20min Dauerbefeuerung über Infiniband. Ich hatte ja erst auf ein Hitzeproblem getippt, da das Teil super-heiß wird. Allerdings gab es bei den Tests in Slot5 und 6 auch ohne extra Lüfter keine Probleme. Auch die Tests ohne SSDs liefern dieselben Ergebnisse.
Naja, nach 50h Fehleranalyse warte ich nun auf Rückmeldungen vom Lieferanten/Hersteller...

Sehr seltsam. Bin gespannt ob es am Ende ein Incompatibilität in bestimmten Slots oder ein defekter HBA ist.

Ja, das habe ich auch gesehen. Aber ich hab auch gesehen, dass Hans nach der Bloody-Veröffentlichung weitere Bugs entfernt hat. Wie bekomm ich denn diese Änderungen in mein System - per pkg update kommen die nicht. Aber ich komm eh grad nicht dazu dies zu testen - zumal Hans' Extra-Spezial-nur-für-mich-privat-Hack bisher bestens funktioniert.

Erst werden Fehler beseitigt. Dann wird der Fix von anderen begutachtet und landet dann in Illumos. OmniOS übernimmt die Änderungen dann meist zuerst in die Bloody dann in die Stable. Erst ab dann sind sie im Repository und per Update verfügbar.

Da Software aber nie fertig ist, wird immer etwas nachkommen. Es würde reichen wenn ESXi Passthrough mit NVMe problemlos läuft.

PS: Urlaub wird überbewertet!

Urlaub ist schön. Hatte aber auch drei Wochen Zeit, die Funktion Appliance Sync mit Storage und Service Failover anzugehen. Das ist volle Redundanz und Ausfallsicherheit einer kompletten Storage Appliance und/oder mehrerer Storage Nodes via iSCSI LUNs statt des beim bisherigen HA üblichen gemeinsam genutzten mpio SAS Shelfs bei dem der nicht ausfallen darf.

Konzept:
http://www.napp-it.org/doc/downloads/z-raid.pdf

 

[besterino]

Maaaaaan, Gea! Mein Konzept (nur) mit Replikation läuft jetzt seit Wochen stabil und ich habe den letzten Schönheitsfehler (dass der Switch immer an sein müsste) kürzlich auch beseitigt. Dann habe ich erst heute stolz einem Kollegen zugerufen, mein Home-Storage sei jetzt für die nächste Zeit fertig...

Jetzt muss ich mir das wohl mal ansehen und ich fürchte das Schlimmste... (...es wird demnächst wieder spät...)

 

[gea]

Das Bessere ist des Guten Feind.
Wobei sich Z-Raid mit kompletter Appliance Redundanz durch Storage und Service Failover erst noch bewähren muss und sicher noch etwas Feintunings bedarf. Auch braucht man nicht immer volle Redundanz und Verfügbarkeit mit aktuellsten Daten.

Mir ist übrigens heute mal wieder ein Artikel zum Strato Crash 2001 in die Hände gefallen
Ich erinnere mich gut daran. Damals war ein erheblicher Teils des deutschen Internets tagelang Offline und der aktuelle Stand vieler Websites komplett verloren da das Backup eben nicht aktuell genug war, Bänder nicht lesbar waren und Komplettrestore aus Bändern furchtbar langsam war.

Ursache war ein Crash in einem Sun Storage Cluster. Das Filesystem war dann hinüber und mehrere fschk die jeweils mehrere Tage dauerten waren nötig um auch nur einen Teil wiederherzustellen. Ich gehe ganz stark davon aus, daß das der Anlass bei Sun war ZFS zu entwickeln. War ja auch zu peinlich. Sun war damals ja DIE Serverfirma schlechthin mit den absolut besten Entwicklern seinerzeit. Jeder gute Ingenieur wollte damals zu Sun.

RZ-Online: Hardware-Crash bei Strato

 

[fdiskc2000]

Moin, morgen begrüßt mich die Konsole mit:

Sep  5 00:22:55 CREST pcplusmp: [ID 805372 kern.info] pcplusmp: ide (ata) instance 0 irq 0xe vector 0x44 ioapic 0x2 intin 0xe is bound to cpu 1
Sep  5 00:22:55 CREST pcplusmp: [ID 805372 kern.info] pcplusmp: lp (ecpp) instance 0 irq 0x7 vector 0x44 ioapic 0x2 intin 0x7 is bound to cpu 0
Sep  5 00:22:55 CREST isa: [ID 202937 kern.info] ISA-device: ecpp0
Sep  5 00:22:55 CREST genunix: [ID 936769 kern.info] ecpp0 is /pci@0,0/isa@7/lp@1,378
Sep  5 00:22:55 CREST pcplusmp: [ID 805372 kern.info] pcplusmp: asy (asy) instance 0 irq 0x4 vector 0xb0 ioapic 0x2 intin 0x4 is bound to cpu 1
Sep  5 00:22:55 CREST isa: [ID 202937 kern.info] ISA-device: asy0
Sep  5 00:22:55 CREST genunix: [ID 936769 kern.info] asy0 is /pci@0,0/isa@7/asy@1,3f8
Sep  5 00:22:55 CREST pcplusmp: [ID 805372 kern.info] pcplusmp: asy (asy) instance 1 irq 0x3 vector 0xb1 ioapic 0x2 intin 0x3 is bound to cpu 0
Sep  5 00:22:55 CREST isa: [ID 202937 kern.info] ISA-device: asy1
Sep  5 00:22:55 CREST genunix: [ID 936769 kern.info] asy1 is /pci@0,0/isa@7/asy@1,2f8
Sep  5 00:22:55 CREST fdc: [ID 114370 kern.info] fd0 at fdc0
Sep  5 00:22:55 CREST genunix: [ID 936769 kern.info] fd0 is /pci@0,0/isa@7/fdc@1,3f0/fd@0,0
Sep  5 00:22:55 CREST pseudo: [ID 129642 kern.info] pseudo-device: fcp0
Sep  5 00:22:55 CREST genunix: [ID 936769 kern.info] fcp0 is /pseudo/fcp@0
Sep  5 00:22:55 CREST pseudo: [ID 129642 kern.info] pseudo-device: fcsm0
Sep  5 00:22:55 CREST genunix: [ID 936769 kern.info] fcsm0 is /pseudo/fcsm@0
Sep  5 00:22:55 CREST pseudo: [ID 129642 kern.info] pseudo-device: fct0
Sep  5 00:22:55 CREST genunix: [ID 936769 kern.info] fct0 is /pseudo/fct@0
Sep  5 00:22:56 CREST pseudo: [ID 129642 kern.info] pseudo-device: llc10
Sep  5 00:22:56 CREST genunix: [ID 936769 kern.info] llc10 is /pseudo/llc1@0
Sep  5 00:22:56 CREST pseudo: [ID 129642 kern.info] pseudo-device: lofi0
Sep  5 00:22:56 CREST genunix: [ID 936769 kern.info] lofi0 is /pseudo/lofi@0
Sep  5 00:22:56 CREST pseudo: [ID 129642 kern.info] pseudo-device: ramdisk1024
Sep  5 00:22:56 CREST genunix: [ID 936769 kern.info] ramdisk1024 is /pseudo/ramdisk@1024
Sep  5 00:22:56 CREST pseudo: [ID 129642 kern.info] pseudo-device: ucode0
Sep  5 00:22:56 CREST genunix: [ID 936769 kern.info] ucode0 is /pseudo/ucode@0
Sep  5 00:22:56 CREST pseudo: [ID 129642 kern.info] pseudo-device: bpf0
Sep  5 00:22:56 CREST genunix: [ID 936769 kern.info] bpf0 is /pseudo/bpf@0
Sep  5 00:22:56 CREST pseudo: [ID 129642 kern.info] pseudo-device: fssnap0
Sep  5 00:22:56 CREST genunix: [ID 936769 kern.info] fssnap0 is /pseudo/fssnap@0
Sep  5 00:22:56 CREST pseudo: [ID 129642 kern.info] pseudo-device: nsmb0
Sep  5 00:22:56 CREST genunix: [ID 936769 kern.info] nsmb0 is /pseudo/nsmb@0
Sep  5 00:22:56 CREST pseudo: [ID 129642 kern.info] pseudo-device: pm0
Sep  5 00:22:56 CREST genunix: [ID 936769 kern.info] pm0 is /pseudo/pm@0
Sep  5 00:22:56 CREST pseudo: [ID 129642 kern.info] pseudo-device: signalfd0
Sep  5 00:22:56 CREST genunix: [ID 936769 kern.info] signalfd0 is /pseudo/signalfd@0
Sep  5 00:22:56 CREST pseudo: [ID 129642 kern.info] pseudo-device: timerfd0
Sep  5 00:22:56 CREST genunix: [ID 936769 kern.info] timerfd0 is /pseudo/timerfd@0
Sep  5 01:00:12 CREST scsi: [ID 107833 kern.notice] /pci@0,0/pci15ad,7a0@16/pci1000,3020@0 (mpt_sas7):
Sep  5 01:00:12 CREST 	Timeout of 8 seconds expired with 3 commands on target 11 lun 0.
Sep  5 01:00:12 CREST scsi: [ID 107833 kern.warning] WARNING: /pci@0,0/pci15ad,7a0@16/pci1000,3020@0 (mpt_sas7):
Sep  5 01:00:12 CREST 	Disconnected command timeout for target 11 w50014ee20c5c5ae0, enclosure 1

Faulty sagt dazu:

Sep 05 2016 01:00:12.782492893 ereport.io.scsi.cmd.disk.dev.rqs.derr
nvlist version: 0
	class = ereport.io.scsi.cmd.disk.dev.rqs.derr
	ena = 0xc4d309372f100001
	detector = (embedded nvlist)
	nvlist version: 0
		version = 0x0
		scheme = dev
		device-path = /pci@0,0/pci15ad,7a0@16/pci1000,3020@0/iport@10/disk@w50014ee20c5c5ae0,0
		devid = id1,sd@n50014ee20c5c5ae0
	(end detector)

	devid = id1,sd@n50014ee20c5c5ae0
	driver-assessment = retry
	op-code = 0x28
	cdb = 0x28 0x0 0x8 0xd8 0x24 0x50 0x0 0x0 0x80 0x0
	pkt-reason = 0x0
	pkt-state = 0x3f
	pkt-stats = 0x0
	stat-code = 0x2
	key = 0x6
	asc = 0x29
	ascq = 0x0
	sense-data = 0x70 0x0 0x6 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x29 0x0 0x0 0x0 0x0 0x0 0x0 0x0
	__ttl = 0x1
	__tod = 0x57cca77c 0x2ea3e4dd

Sep 05 2016 01:00:12.782492334 ereport.io.scsi.cmd.disk.recovered
nvlist version: 0
	class = ereport.io.scsi.cmd.disk.recovered
	ena = 0xc4d309372f100001
	detector = (embedded nvlist)
	nvlist version: 0
		version = 0x0
		scheme = dev
		device-path = /pci@0,0/pci15ad,7a0@16/pci1000,3020@0/iport@10/disk@w50014ee20c5c5ae0,0
		devid = id1,sd@n50014ee20c5c5ae0
	(end detector)

	devid = id1,sd@n50014ee20c5c5ae0
	driver-assessment = recovered
	op-code = 0x28
	cdb = 0x28 0x0 0x8 0xd8 0x24 0x50 0x0 0x0 0x80 0x0
	pkt-reason = 0x0
	pkt-state = 0x1f
	pkt-stats = 0x0
	__ttl = 0x1
	__tod = 0x57cca77c 0x2ea3e2ae

Kann das jemand übersetzen? Ich würde raten es gab Probleme mit einer der Platten, aber die Device ID finde ich in der Platten-Übersicht nicht wieder?!
Pool und Platten zeigen aktuell auch keinen Fehler.

------ UPDATE -----
Ok ich denke ich habe die Platte gefunden, die ID´s sind irgendwie nicht überall 1:1 zu erkennen.
Die Platte scheint aber ok zu sein. Ich lasse gerade mal einen langen Smartcheck laufen. Aber merkwürdig ist das ganze schon.

 

[gea]

die entscheidende Passage im Log ist

Timeout of 8 seconds expired with 3 commands on target 11 lun 0.
Sep 5 01:00:12 CREST scsi: [ID 107833 kern.warning] WARNING: /pci@0,0/pci15ad,7a0@16/pci1000,3020@0 (mpt_sas7):
Sep 5 01:00:12 CREST Disconnected command timeout for target 11 w50014ee20c5c5ae0, enclosure 1

Eine Platte hat also innerhalb der Timeout Zeit von 8s beim Lesen nicht geantwortet. Diese kurze Timeout Zeit ist bei Hardwareraid üblich, könnte man etwas höher ansetzen. Ich nehme aktuell 15s (default 60s)

Die Frage ist jetzt, welche Platte.
Üblicherweise nutzt Solaris bei aktueller Hardware ausschliesslich WWN als Platten-Bezeichner. Das ist eine vom Hersteller aufgebrachte genormte und weltweit garantiert eindeutige Kennung (im Gegensatz zur Seriennummer), damit ideal für Storage. Manche Treiber sehen aber nur den physikalischen Port oder Expanderanschluß und geben den dann aus.

Es gibt jetzt zwei Kennungen im Log

1.
50014ee20c5c5ae0
Wenn man eine Platte mit der WWN Kennung in zpool status findet, dann wars die

2.
target=11
Das ist der physikalische Port der von ZFS nicht gezeigt wird.
In napp-it Pro übersetze ich den unter Disks > Disk Location

Wenn der Pool jetzt aber keine Fehler zeigt, dann wurde der Datenblock nach dem Timeout aus dem Raid ermittelt und der Datenblock auf der Platte neu geschrieben (ZFS Self Healing). Wenn derartiges nicht häufiger auftritt muss man nichts machen.

Tritt das nochmal auf, würde ich die Platte durch eine andere ersetzen und mit einem Herstellertool intensiv testen. Ist das ok kann man sie weiter nutzen. Ich notiere das dann immer auf der Platte. Spätestens beim dritten Mal fliegt sie in den E-Schrott da solche Timeouts, selbst wenn sie behebbar sein sollten die Pool Performance ruiniert. ZFS selber ist da toleranter. Da müssen mehr Fehler auftreten bis sie wegen too many errors automatisch aus dem Raid genommen wird.

 

[besterino]

Bei mir gab es mit einem Pool, in dem eine "latent defekte" Platte mit lief, ähnliche Fehler.

Äußerte sich durch IOstat-Fehler und diverse Fehler in den Logs (errors):

TIME                 CLASS
Mar 28 08:04:12.8742 ereport.io.scsi.cmd.disk.dev.rqs.merr.read
Apr 04 04:22:40.5505 ereport.io.scsi.cmd.disk.dev.rqs.merr.read
Apr 11 03:09:21.0557 ereport.io.scsi.cmd.disk.dev.rqs.merr.read
Apr 18 03:19:11.7120 ereport.io.scsi.cmd.disk.dev.rqs.merr.read
Apr 25 07:08:52.8020 ereport.io.scsi.cmd.disk.dev.rqs.merr.read
Apr 25 08:17:47.9643 ereport.io.scsi.cmd.disk.dev.rqs.merr.read
May 02 07:13:31.1959 ereport.io.scsi.cmd.disk.dev.rqs.merr.read
May 02 10:51:23.9680 ereport.io.scsi.cmd.disk.dev.rqs.merr.read
May 03 00:17:16.7670 ereport.fs.zfs.vdev.dtl         
May 04 09:30:36.5940 ereport.io.scsi.cmd.disk.dev.rqs.merr.read
May 04 09:30:46.2712 ereport.io.scsi.cmd.disk.dev.rqs.merr.read
May 04 09:30:59.8594 ereport.io.scsi.cmd.disk.dev.rqs.merr.read
May 04 09:30:59.8595 ereport.fs.zfs.data             
May 04 09:31:13.6698 ereport.io.scsi.cmd.disk.dev.rqs.merr.read
May 04 09:31:27.2357 ereport.io.scsi.cmd.disk.dev.rqs.merr.read
May 04 09:31:27.2358 ereport.fs.zfs.data             
May 04 09:31:46.9903 ereport.io.scsi.cmd.disk.dev.rqs.merr.read
May 04 09:32:12.5445 ereport.io.scsi.cmd.disk.dev.rqs.merr.read
May 04 09:32:26.4660 ereport.io.scsi.cmd.disk.dev.rqs.merr.read
May 04 09:32:26.4660 ereport.fs.zfs.data             
May 04 09:32:54.5978 ereport.io.scsi.cmd.disk.dev.rqs.merr.read
May 06 02:37:12.9580 ereport.fs.zfs.data             
May 06 03:37:00.4375 ereport.fs.zfs.data             
May 06 03:37:36.3954 ereport.fs.zfs.data             
May 06 03:38:58.6365 ereport.fs.zfs.data             
May 06 03:40:54.6760 ereport.fs.zfs.data             
May 06 03:42:04.6175 ereport.fs.zfs.data             
May 06 03:42:39.2747 ereport.fs.zfs.data             
Jun 16 03:17:11.9828 ereport.fs.zfs.vdev.open_failed 
Jun 16 03:19:36.5027 ereport.fs.zfs.vdev.dtl

Platte raus --> Fehler weg (seit Mitte Juni). =)

 

[fdiskc2000]

Danke Euch beiden, das war flott.
Wenn man dann erkennt wonach man schauen muss, ist es gar nicht so schwer die Platte zu erkennen

S:0 H:2 T:0 in der Appliance Map ist auch durch orange gut zu erkennen!

Ich werde die Platte im Auge behalten, ein cold spare liegt daneben.

Bleiben für mich 2 Punkte:

1. wie kann ich die iostat message resetten?
2. wo kann ich den timeout ändern? Ich wüsste nicht, dass ich irgendwo 8s eingestellt hatte, wenn eigentlich 60s default sein sollen?

 

[gea]

1. wie kann ich die iostat message resetten?
2. wo kann ich den timeout ändern? Ich wüsste nicht, dass ich irgendwo 8s eingestellt hatte, wenn eigentlich 60s default sein sollen?

1. garnicht
Iostat protokolliert grundsätzlich ab bootup

2.
Die default 60s machen nur Sinn wenn man kein Raid hat und den Platten-Internen Reparaturmöglichkeiten maximal lange Zeit geben möchte. Das Problem ist halt dass der Pool dann 60s stehen kann ohne Daten zu liefern.

8s wie bei Hardwareraid ist ein guter Wert für wenige Platten. Mit vielen Platten kann das aber auch Probleme machen. Ich hatte kürzlich einen Petabyte Pool mit sehr vielen Platten wo es dadurch zu extrem vielen iostat Fehlern kam. Seitdem nehme ich 15s als default - davor hatte ich in napp-it Appliance-Tuning 8s.

Einstellen kamm man das in /etc/system oder durch napp-it Appliance-Tuning

 

[fdiskc2000]

Alles klar, danke. Da das Raidz1 nur aus 3 Platten besteht sollten die 8s ja passen. Ich werde das mal weiter beobachten.

 

[oyster]

ZFS Performance (single SSD vs. RaidZ2 Pool mit ZIL)

Hi,

ich Experimentiere aktuell mit den Datastore für meinen ESXi All-in-One (angebunden per NFS, ZFS unter Ubuntu 16.04).

Ich habe einen RaidZ2 Pool mit 6x3 TB und eine 10 GB Partition auf einer Samsung 840 Pro als SLOG/ZIL. In einer Windows 10 VM habe ich die folgenden Ergebnisse mittels Crystal Disk Mark:

Hier noch die bonnie++ Ergebnisse direkt im RaidZ2-Filesystem auf dem ZFS-Host:

Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
fileserver   15960M   171  99 184059  24 99752  19   513  90 238521   9 185.2   4
Latency               238ms     572ms    1191ms     432ms     273ms     329ms
Version  1.97       ------Sequential Create------ --------Random Create--------
fileserver          -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files:max:min        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
10:102400:1024/1024  1968  22 14351  34 +++++ +++  1328  20 12646  45 17851  81
Latency             67020us   34492us     838us     240ms     214ms     170ms

Auf einer weiteren Partition auf der 840 Pro habe ich einen separaten Datastore eingerichtet umd dort die Performance zu testen. Leider ist die Performance nur relativ geringfügig besser. Mich wundern vor allem die relativ geringen IOPS. In dem Zusammenhang fallen natürlich auch die für eine SSD sehr sehr niedrigen Geschwindigkeiten bei Random Reads und Writes auf. Als ich die SSD als dedizierten Datastore laufen hatte, gab es quasi fast keinen Unterschied zur nativen Verwendung als lokaler Datastore unter ESXi und auch nur einen geringfügigen Unterschied zum RaidZ2 Diskpool. Ein sync=disable auf dem SSD-Datastore hat leider auch keine merkliche Besserung gebracht. Die SSD Ergebniss im folgenden Bild:

Hier noch die bonnie++ Ergebnisse direkt im SSD-Filesystem auf dem ZFS-Host:

Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
fileserver   15960M   211  99 462665  42 161299  16   604  99 493181  17  3855  41
Latency               602ms     397ms     322ms     187ms     124ms    8502us
Version  1.97       ------Sequential Create------ --------Random Create--------
fileserver          -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files:max:min        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
10:102400:1024/1024 10816  87 +++++ +++ +++++ +++ 10464  84 +++++ +++ +++++ +++
Latency              8166us    2756us    8260us    7585us    9649us     430us

Ist das ein normales Verhalten für ZFS im Zusammenhang mit SSDs?

Edit: Weitere Infos zum System:
- Pentium G4400
- 32 GB ECC
- Supermicro X11SSL-F
- Die VM nutzt 8 GB Ram derzeit
- Ein M1015 im IT-Mode geht direkt an die VM per VT-d

 

[oyster]

Alternativ würden mich auch Benchmarks (speziell ChrystalDiskMark) einer Windows VM auf einem ESXi AiO mit ZFS Storage anderer User interessieren. Speziell natürlich auch wenn es sich um SSDs handelt.

 

[affabanana]

wenn ich morgen dran denke, kann ich von meiner Kiste mal ein paar Benchmarks machen.


Gesendet von iPhone mit Tapatalk

 

[morph027]

Kann nur ohne VMware beitragen. Aber hier eine Windows VM auf ZFS (on Linux) mit SSDs: HDD Speed Proxmox vs Vmware

 

[besterino]

@oyster: ich hatte hier, hier und vor allem hier ab hier eine gewisse Testorgie veranstaltet... zwar primär im Hinblick auf Netzwerk-Flaschenhälse, aber da ist einiges an Infos rund um ZFS (auch ZFSonLinux) dabei...

Konkret mit einem ESXi/Napp-it allinone auf Solaris 11.3 mit Windows10Pro-VM komme ich auf einem Consumer-SSD-Pool(Raid0 aus 4x Adata Premier Pro SP920), eingebunden über NFS als ESXi Datastore (Achtung Besonderheit: Die Solaris-VM mit dem SSD-Pool liegt auf einem anderen ESXi Host als die Win10-VM! Verbunden sind die beiden Kisten über ein 10Gigabit-Netz.):

 

[affabanana]

ALL in ONE HOST


E5-1620
54GB RAM




Storage-VM
FreeNAS 9.10
2 vCPU
6GB RAM
pathtrough LSI HBA
4 x 256GB Samsung 850 Evo SSD als RAIDZ1 lz4 compression eingeschalten




ESX 6.0 u3
Datastore über NFS




Und hier die ChrystaldiskMark Ergebnisse:


Windows10Pro auf Echter Hardware installiert.
Einzelne SSD:

Windows10Pro-VM 1vCPU 2GB RAM


Mit Sync = Standard:

Mit Sync = disable / off:

Und hier noch die Schummelsoftware mit RAM cache eingeschalten:

Leider hab ich beim Rummfummeln doch noch den Pool vermurkst.
Hab ja Backup gemacht.

 

[oyster]

Danke für die Benchmarks. Ich schließe daraus, das ZFS generell bei random Access recht massive Nachteile mit sich bringt. Ist meine Interpretation korrekt oder hängt das in dem Fall eher mit NFS zusammen?

@besteriono: Hast du Sync aktiviert oder noch ein SLOG laufen?

@affabanana: Was ist denn die "Schummelsoftware"?

 

[hoppel118]

Moinsen,

benutzt hier eigentlich noch jemand openmediavault mit zfs?

Dort werden gerade Tester für das neue Plugin für omv3beta gesucht.

Viele Grüße Hoppel

 

[gea]

Danke für die Benchmarks. Ich schließe daraus, das ZFS generell bei random Access recht massive Nachteile mit sich bringt. Ist meine Interpretation korrekt oder hängt das in dem Fall eher mit NFS zusammen?

Warum sollte das so sein.
ZFS hat prinzipielle "Nachteile" weil es Prüfsummen mitführt und damit mehr Daten lesen/schreiben muss.
Das ist der Preis dafür, dass alle Daten verifiziert sind.

ZFS hat auch den "Nachteil" dass beim Ändern von Hans zu Gans nicht nur ein Byte geändert werden muss, sondern immer ein kompletter Datenblock z.B. 128 KB neu geschrieben wird.
Das ist bei CopyOnWrite der Preis dafür dass das Dateisystem immer konsistent ist da entweder Daten + Metadaten upgedated werden oder die Änderung unvollständig ist und verworfen wird. Damit gibt es kein korruptes Dateisystem mehr bei einem Crash oder Powerloss..

Ein Nebeneffekt von CopyOn Write ist dass mit dem Füllgrad die Fragmentierung stärker ist als bei "alten" Dateisystemen. Um dem entgegenzuwirken hatte Sun besonders gute Cacheoptionen (ARC, L2ARC) entwickelt. Das überkompensiert die etwas höhere Fragmentierung sogar da bei einem gut konzipiertem ZFS System über 80% aller Reads aus dem Ramcache kommen.

NFS ist so ziemlich das schnellste (und einfachste) Netzwerkprotokoll. Langsam wird es nur bei sicherem (sync) Schreiben. Das liegt aber an der Deaktivierung aller Schreib-Cache Mechanísmen damit bei einem Crash garantiert kein Byte verloren geht, nicht an NFS.

 

[affabanana]

pssst nicht weitersagen

pernixdata, gibts als Freedom edition kostenlos


wurde letzens von Nutanix gekauft. Glaube das wird der untergang der Software sein.


Gesendet von iPhone mit Tapatalk

 

[the_pi_man]

Hab da mal ne dumme Frage: gehe ich Recht in der Annahme das man ein vdev nicht wieder aus einem Pool (mit 2 oder mehr vdev's) herauslösen kann? Hinzufügen ist ja der normale Weg, aber so ne Aktion rückgängig?
Das es mit Pool zerstören und neu anlegen klappen wird ist mir schon klar. Aber geht so was auch mit intaktem Pool?

 

[gea]

Ja, ein vdev entfernen geht nicht.

 

[Digi-Quick]

pssst nicht weitersagen

pernixdata, gibts als Freedom edition kostenlos


wurde letzens von Nutanix gekauft. Glaube das wird der untergang der Software sein.


Gesendet von iPhone mit Tapatalk

Soll uns jetzt was sagen?

 

[ludwinator]

Noch nicht, aber bald. Siehe https://www.delphix.com/blog/delphix-engineering/openzfs-device-removal

cu

 

[morph027]

Cool, gestern mit einem Kollegen drüber gesprochen