[Sammelthread] ZFS Stammtisch

Wieso Resilver? Ist ne Platte defekt? Würde erstmal einen Scrub laufen lassen und schauen, ob der alles richten kann.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Moin,
ich hab mir letztens ne 10gb nic in die Windows Kiste verbaut und da ist mir aufgefallen das mein OmniOS 151038 filer ne ziemlich miese smb performance liefert. Ein SSD Pool schafft gerade mal ~200MB/s. Über NFS schafft der selbe Pool ~800MB. Momentan ist noch kein performancetuning vorgenommen, aber 200MB/s sollten trotzdem viel zu wenig sein.

Erst dachte ich das Problem liegt bei der Windows Kister aber von nem FreeBSD filer mit samba bekomme ich ~450MB/s (Was die lokale Sata SSD halt so schafft). Das Problem muss also beim OmniOS smb kernel server liegen.

Hat jemand vielleicht ne Idee woran das liegen könnte?
 
Bei meinen früheren SMB Tests hatte ich auch mal ain ähnliches Problem (Intel 540)
Beheben konnte ich es durch aktuelle Nic Treiber (Intel Homepage) + Treiber Einstellung int throttelling=disabled. Damit war ich bei ca 500 MB/s. Auf 800 MB/s gings dann mit Jumbo aktiviert.

Ansonst: tcp buffers erhöhen, defaults sind eher für 1G nics

Ansonst: Pool Performance (napp-it Pool > Benchmark) vs Netzperformance (iperf) vs SMB Performance (z.B AjA) vergleichen damit man sieht was geht.
 
Über SMB und Intel X540 kann ich von meinem Windows 10 Desktop (Ryzen 4750G @ B550) 1,1GB/s vom und zum SMB-Server lesen und schreiben. Hängt dann natürlich von den Files ab, was wo liegt, wie groß und was z.B. schreibend noch in den ARC passt und wie gut komprimierbar (LZ4). Ohne manuelle Einstellungen war der Durchsatz _deutlich_ niedriger.
=> Am Netzwerkzugriff selber liegts dann nicht mehr, was im realen Betrieb nutzbar ist. :-)

Server ist eine ESXI-VM mit Xigmanas 11.2 (also FreeBSD + Samba), durchgereichter HBA, VMXNet3 hinter einer X550, in der Portgruppe und Vswitch hängt für diese Verbindung nur dieser 1 Port).

In Windows musste ich wie gea schon schrieb, die Interrupt-Moderation deaktivieren, Jumbo-Frames aktivieren und die Send/Receive-Puffer in den Treibereinstellungen etwas erhöhen (ich meine ich hab die jeweils auf 2048 gestellt, default war 512). Auf der Serverseite sind die Puffer auch vergrößert.

Bzgl. anderen Karten/Chipsätzen für 10G Kupfer ausser X540+X550 kann ich nicht mit Erfahrung dienen, da hab ich ausschliesslich und bewusst auf Intel gesetzt.

Mit FreeBSD hab ich eher den Fall, dass dieses M.2 NVME-Karten (970 Evo Plus) bei mir nicht über 2GB/s bringt, während Solaris, Proxmox oder Windows auf der gleichen Maschine die 3,x GB/s schafften. An der PCIE-Anbindung liegts also nicht.
 
Zuletzt bearbeitet:
Mal eine kleine Anekdote am Rande: ich versuche jetzt ungelogen seit einem halben Tag, als Privatperson an einen Oracle-Support-Vertrag zu kommen, inklusive Kaufen / gegen Geld. Erfolglos.

Selbst die verschiedenen Hotlines bei Oracle zeigen sich völlig plan- und hilflos. Die wollen mein Geld nicht. :d Dummerweise: helfen wollen/können sie mir auch nicht. Dabei will ich doch nur die ConnectX-4/5-Treiber aus dem SRU21...

EDIT: ich glaub, ich hab's gefunden: https://shop.oracle.com/apex/f?p=DSTORE:PRODUCT:::NO:RP,6:P6_LPI,P6_PPI:27242443094470222098916
 
Zuletzt bearbeitet:
Ich hab jetzt mal die buffer angepasst und interrupt throttling deaktiviert. Hat leider nichts gebracht.

Zum test hab ich auch mal das smb share auf nem Linux Client gemountet und da ein benchmark gemacht. Das Ergebnis:
read: ~525MB/s write: ~350MB/s
Das sind immerhin ähnliche Werte wie gea erreicht hat (für nicht aktivierte Jumbo frames)

Also Fazit:
Windows->Samba: ok
Windows->Smb kernel server: lahm
Linux->Smb kernel server: ok

Jetzt ist die frage warum die Kombination Windows und Smb kernel server so lahm sind. Die verwendete Smb Version ist 3.1.1. Der NIC in der Windows Kiste ist ein AQC107 Chip/Asus xg-100c also nicht grad der beste.

Selbst die verschiedenen Hotlines bei Oracle zeigen sich völlig plan- und hilflos. Die wollen mein Geld nicht. :d Dummerweise: helfen wollen/können sie mir auch nicht.
Lustigerweise hab ich von einer Quelle die ich jetzt nicht genauer nennen will mal gehört, das es mit Geschäftskunden da auch nicht viel anders sein soll :LOL:.
 
Heya, Frage zum meinem ZFS-Z2raid:
Ich kriege große Dateien (>10gig) nicht von meiner (Linux)Workstation auf das via NFS gemountete ZFS kopiert.
Es besteht aus 5 Exos x16 und läuft auf einem TrueNAS virtualisiert. Angebunden ist es mit einer virtualisierten Intel x520 Gigabit Karte (bzw. der Hälfte davon). Meine Workstation hat eine Mellanox Karte eingebaut. iperf sagt
Code:
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  10.8 GBytes  9.25 Gbits/sec
So sieht der mountpoint aus:
Code:
truenas:/mnt/Datapool_on_TrueNAS/blub /blub_on_TrueNAS nfs noauto,user,bg,rw,_netdev,soft,timeo=60,x-gvfs-show
So, "schlechte" Schreibperformance auf ein ZFS ab bestimmter Größe ist etwas mit dem ich gerechnet habe. Aber komplett abbrechen? Woran liegt das?
 
(Stable) RAIDZ Expansion wäre ein Grund, aus den Fängen von Oracle zu entfliehen, aber ich hab ja erst kürzlich auf ein größeres v44-Z2 (10x 3TB) geupgradet...:unsure:

Ja, jedenfalls ist mir derzeit zu kalt in der Wohnung, daher läuft jetzt der Server, obendrein mit nem scrub. Und weil zwei verschiedene leere SSDs eingebaut sind, hab ich endlich mal ein SLOG eingerichtet.
Frage: Komme ich per Single-User mit NFS über GbE jemals in Sphären, in denen ich eine MZVLB256HAHQ (Samsung PM981 256GB) so überrumple, dass sie unterhalb der alternativen SSDSC2BA100G3 (Intel DC 3700 100GB) einbricht? So 08/15-Tests mit dd lassen die Intel nicht wirklich gut aussehen. Zeiten jeweils in Sekunden.

lokalZFSZFS+IntelZFS+Samsung
bs=4k count=100000​
1.22​
3.82​
6.67​
4.36​
bs=1M count=1000​
3.30​
9.84​
11.31​
9.95​
bs=4k count=100000 conv=fdatasync​
4.12​
4.53​
6.43​
4.75​
bs=1M count=1000 conv=fdatasync​
8.06​
10.10​
13.92​
9.74​
bs=4k count=1000 oflag=dsyn​
6.04​
16.63​
0.65​
0.51​
bs=1M count=1000 oflag=dsync​
19.30​
37.37​
15.81​
13.65​

PLP ist ne ganz andere Sache und wie das an 10GbE aussieht, ebenfalls.
 
Ahoy, habe ein Problem.
Habe FreeNAS in einer VM am laufen gehabt mit Fedora Host, LSI HBA durchgereicht an die VM, hat auch alles super geklappt.
Ab und zu kam es jedoch vor, dass 1-2 HDDs "reconnected" sind, konnte man dann im dmesg sehen dass diese in FreeNAS wieder erkannt wurden. (Wie kann sowas passieren? Power Drop, oder Problem mit dem HBA?)
Aufjedenfall ist mein Pool mir dann irgendwann mal "abgefackelt", weil mehr HDDs rausgeflogen sind als die Redundanz hergegeben hat, ja gut. Kein Problem, will den Pool wieder einbinden, das klappt auch manchmal, dann sind sogar wieder alle Platten online, und der resilvert. Das Problem ist jedoch inzwischen: Ich kriege die Kiste nicht resilvert, bzw. habe irgendein anderes Problem. Wenn das resilvern anfängt, ist die Kiste nicht mehr ansprechbar, ich kann weder ein "zpool status" abfragen, noch irgendwelche Sachen die Storagebezogen sind in FreeNAS ausführen.

Daher habe ich mir gedacht: Ok, mein Setup ist Schrott, ich baue ein neuen Server auf auf Basis von 2011-2 mit Ivy Bridge, dem gleichen HBA und dem gleichen Expander wie aus dem ersten Setup. Jedoch neue FreeNAS Installation. Weiterhin gleicher Pool und gleiche HDDs.
Dort ist beim Resilvern jedoch das gleiche Problem, bzw. das System ist nicht mehr ansprechbar, und alle zfs bezogenen Commands gehen nicht mehr. Ich kriege jedoch auch hier am Anfang den Pool kurz komplett online.

Woran kann das liegen? Ist vielleicht der HBA Fritte? Dem Ausschlußprinzip nach kann es ja nur eins von folgenden Dingen sein: HBA kaputt, Expander kaputt, Pool kaputt.
Weiterhin fallen mir im IPMI Log von meinen Systemen ab und zu PCIe #SERR auf, kann es da eventuell einen Zusammenhang geben? Ich habe da schließlich bisher noch nicht das verursachende PCIe Device gefunden.

Ich nutze einen LSI 9211 8i, ich habe einen M5110 den ich noch testweise mal auf IT Firmware umflashen kann um zu testen ob es der HBA ist.
Langsam habe ich daher das Gefühl, dass mein Setup Nummer 1, mit der Virtualisierung, doch garnicht so falsch war.

EDIT:
Nach 1 Stunde ist "zpool status" durchgelaufen, folgendes unplausibles Ergebnis.

Der sagt auch, "POLLHUP detected on devd socket"

root@freenas[~]# zpool status pool: data state: UNAVAIL status: One or more devices could not be opened. There are insufficient replicas for the pool to continue functioning. action: Attach the missing device and online it using 'zpool online'. see: http://illumos.org/msg/ZFS-8000-3C scan: none requested config: NAME STATE READ WRITE CKSUM data UNAVAIL 0 0 0 raidz2-0 UNAVAIL 0 0 0 1626352819212922408 UNAVAIL 0 0 0 was /dev/gptid/5168a444-cacf-11eb-891f-133dff369a55.eli 2252268794190276348 UNAVAIL 0 0 0 was /dev/gptid/9155711b-6596-11eb-a75c-8f89b0c061c4.eli 13032312712921767360 UNAVAIL 0 0 0 was /dev/gptid/86b9fa2f-6596-11eb-a75c-8f89b0c061c4.eli 15819523336493928030 UNAVAIL 0 0 0 was /dev/gptid/9285ff04-6596-11eb-a75c-8f89b0c061c4.eli 38866582036668272 UNAVAIL 0 0 0 was /dev/gptid/9411f31f-6596-11eb-a75c-8f89b0c061c4.eli spare-5 UNAVAIL 0 0 0 12219767935346166654 UNAVAIL 0 0 0 was /dev/gptid/9b4a1344-6596-11eb-a75c-8f89b0c061c4.eli 336223762456561297 UNAVAIL 0 0 0 was /dev/gptid/0cea51b3-6caf-11eb-aa19-19444082b40a.eli 12490430271123041723 UNAVAIL 0 0 0 was /dev/gptid/aab972e4-6596-11eb-a75c-8f89b0c061c4.eli 15244943219702717528 UNAVAIL 0 0 0 was /dev/gptid/ae626c03-6596-11eb-a75c-8f89b0c061c4.eli logs 12893365534936794026 UNAVAIL 0 0 0 was /dev/gptid/080a5406-7e88-11eb-bffa-b95a0a9e4218.eli pool: freenas-boot state: ONLINE scan: none requested config:
 

Anhänge

  • Screenshot from 2021-06-20 21-26-53.png
    Screenshot from 2021-06-20 21-26-53.png
    10 KB · Aufrufe: 69
  • Screenshot from 2021-06-20 21-26-40.png
    Screenshot from 2021-06-20 21-26-40.png
    15,3 KB · Aufrufe: 78
  • Screenshot from 2021-06-20 21-26-17.png
    Screenshot from 2021-06-20 21-26-17.png
    16,2 KB · Aufrufe: 81
Zuletzt bearbeitet:
Sind das SMR Platten?
Nene, das sind CMR Platten, ne SMR ist kürzlich rausgeflogen, deswegen muss die ersetzt werden, daher muss ich mal zuende resilvern.

Gerade geschaut, unter TrueNAS gibt es das Problem nicht, habe gerade geupgraded, und da reagiert das System dann immerhin noch.
Bin mal gespannt was ich da noch von meinem Pool runterkriege, bei 3 Datasets gab es schon Errors beim Importieren wegen "I/O Error".
Heftig was so ein subsecond Aussetzer von dem HBA schon bewirken kann.
Data errors sind im 3 stelligen Millionenbereich.
CKSUM Fehler steigen bis auf 1 HDD (Die auf 0 ist) auf über 100k an.
Der braucht 3 Tage zum resilvern.

Warning: settings changed through the CLI are not written to the configuration database and will be reset on reboot. root@freenas[~]# zpool status data pool: data state: DEGRADED status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scan: resilver in progress since Sun Jun 20 10:54:34 2021 11.7T scanned at 38.2G/s, 73.2G issued at 238M/s, 16.6T total 5.37M resilvered, 0.43% done, 20:11:27 to go config: NAME STATE READ WRITE CKSUM data DEGRADED 0 0 0 raidz2-0 DEGRADED 0 0 0 gptid/5168a444-cacf-11eb-891f-133dff369a55.eli ONLINE 0 0 797 (resilvering) gptid/9155711b-6596-11eb-a75c-8f89b0c061c4.eli ONLINE 0 0 187 (resilvering) gptid/86b9fa2f-6596-11eb-a75c-8f89b0c061c4.eli ONLINE 0 0 120 (resilvering) gptid/9285ff04-6596-11eb-a75c-8f89b0c061c4.eli ONLINE 0 0 163 (resilvering) gptid/9411f31f-6596-11eb-a75c-8f89b0c061c4.eli ONLINE 0 0 797 (resilvering) spare-5 DEGRADED 0 0 279 gptid/9b4a1344-6596-11eb-a75c-8f89b0c061c4.eli ONLINE 0 0 0 (resilvering) 336223762456561297 UNAVAIL 0 0 0 was /dev/gptid/0cea51b3-6caf-11eb-aa19-19444082b40a.eli gptid/aab972e4-6596-11eb-a75c-8f89b0c061c4.eli ONLINE 0 0 169 (resilvering) gptid/ae626c03-6596-11eb-a75c-8f89b0c0
 
Zuletzt bearbeitet:
Soweit ich hinsichtlich Expander mal gehört hatte, sollten dafür bevorzugt SAS-Platten verwendet werden. Auf der anderen Seite hast du Fehler mit "PCIe #SERR" und agierst im 3-stelligen Millionenbereich bei Data-Errors. Ich würde das Resilvern erstmal einstellen und die HW überprüfen. Google ich nach "POLLHUP detected on devd socket" lande ich immer wieder bei FreeBSD, TrueNAS etc. Scheint dort nix gänzlich unbekanntes zu sein oder du hast einen Bug gefunden.
Ausgehend von WD-WCC7abc sind deine WD-Red-Pro auch nicht unbegrenzt beschreibbar, mehr als ich meine 300TB pro Jahr sieht WD da für den garantiekonformen Betrieb nicht vor. Das sind zwar ganze 120TB mehr als bei den normalen WD-Red, das könnte dennoch zum Problem werden beim Resilvern grösserer Pools. Mir fehlt leider die Erfahrung darin, wie sinnvoll es prinzipiell ist, grössere ZFS-Pools zu Resilvern und nicht direkt den Weg wie bei grösseren Raid-5/6 zu gehen sprich Backuppen und Neuaufsetzen. Ich habe hier nur einen ZFS-Mirror mit vollen 3.5 von 4TB am Werkeln und ein Scrub dauert inzwischen gut 10 Stunden. Deine 3 Tage könnten also für dein Raidz-Setup und Pool-Grösse völlig normal sein...
 
Meine "Goldene" Regel: ab 8TB nur Platten für Storage / im RAID mit einer UBER von 1:10^15 und Raid6 bzw. RaidZ2. Hilft hier im Zweifel allerdings auch nicht (mehr)...
 
Ich danke euch. Das ganze ist sehr interessant, ich musste den Pool per Hand "degraden" indem ich eine HDD rausgenommen habe, dann war er wieder zugreifbar, aktuell lasse ich einen Scrub drauflaufen.
Ich konnte so bereits alle Daten sichern, jedoch ist der Pool wohl schrott, und ich muss alle Platten wipen, und neu aufsetzen.
Zu den 300TB, ich habe die Platten ca. 3 Monate, und die haben jetzt schon ca. 240TB geschrieben.
Bald kommen weitere 4x 4TB Platten dazu.

Früher hatte ich 16x2TB Platten, und habe da einen "RAID 10" gefahren mit ZFS, also mirrored + striped, ich denke das war garnicht so schlecht.
Weiterhin habe ich mal überlegt ob ich nicht eine 4TB SSD einbaue als Hot-Spare, da wäre Redundanz dann deutlich schneller hergestellt, aber da ist die Frage ob da RAID 6, bzw. RAID 10 dann besser wäre.
 
Zuletzt bearbeitet:
Dann bräuchtest Du aber eine SSD, die ein Rebuild abkann. Mit den billigen Dram-less, QLC oder TLC-SSDs mit nur kleinem SLC-Cachebereich brauchst da mutmasslich nicht groß anrücken.
D.h. Du landest da z.B. bei einer 870 Evo 4TB. Macht 350-400 Euro.

Warum dieser riesen Haufen 4TB HDD? Hol Dir lieber, sobald die Preise zurückkommen, hochkapazitive ordentliche DC-Heliumplatten und dafür schluss auch mit diesem Expandergedöns.
Alles nur potentielle Störeinflüsse. KISS-Regel beachten.
Der Trambahner hat einfach einen HBA mit 16 Ports, wo ein Raidz2 mit 6x14TB dranhängt und sowie als zweiter Pool 6 SSD (Stripe über 3 Mirrorpärchen, also (3*2*960GB SSD).
Macht noch 4 Ports frei für andere Aktionen wie SSD-Pool-Erweiterung noch um ein Mirror-vdev oder frei für "zpool replace"-Aktion wenn ich was ersetzen oder Disks inplace erweitern will.

Btw, 2011-2 Ivy als Filer? Ernsthaft? Nope Nope, ausserhalb vom Rumspielen/-probieren viel zu stromdurstig für daheim.
 
Zuletzt bearbeitet:
da wäre Redundanz dann deutlich schneller hergestellt, aber da ist die Frage ob da RAID 6, bzw. RAID 10 dann besser wäre.
Bei einem Raid 6 dürfen dir halt 2 Platten pro vdev ausfallen, bei einem Raid 10 (mit 2 Platten pro vdev) halt nur eine.

Ist halt die Frage was (statistisch) eher eintreten kann - wobei das am Ende auch egal ist, wenn es passiert ist und man den Salat hat..
Wobei du bei einem Raid 10 rebuild nur last auf einer HDD hast, bei Raid 6 halt auf allen aus dem vdev..

Ich wüsste gar nicht, wie zfs bei einem Raid 10 mit 3 Platten pro vdev einen rebuild verarbeitet.Oder generell wie ZFS dann arbeitet bez Checksummen prüfung etc.
 
Zuletzt bearbeitet:
Ich muss das denke ich mal ausprobieren, ich habe eh erstmal ein Backup aller Daten vorliegen, dann werde ich den RAID bald mal auseinanderrupfen.
@Trambahner Ja genau, zumindest übergangsweise wollte ich das mal probieren, aber das Gesamtsystem mit 192GB REG ECC RAM zieht im Idle 300W.
Vorher lief das ganze auf meinem 32 Core EPYC System als VM, hatte den Fedora Host + FreeNAS VM (und 20 andere VMs) was halt super lief, jedoch sind manchmal halt 2 Disks, oder im letzten Fall 3, neu eingelesen worden, bzw. sind aus irgendeinem Grund disconnected, und sofort wieder connected was man im "dmesg" von FreeNAS dann sehen konnte.
Bei meinem EPYC System habe ich 256GB DDR4 2666 REG ECC RAM und ein EPYC-8DT Board von ASRock Rack. Dort hat es mal das BMC zerschossen weil das Log von PCIe #SERR Fehlern vollgelaufen ist, und ich musste den per Hand mit einem externen Flasher neu programmieren.

Ich muss halt ehrlich sagen, rein von der Performance her, und vermutlich auf Effizienz hat mir die Variante mit Storage als VM am besten gefallen, und es hat an sich auch oft monatelang problemlos funktioniert, aber halt nicht immer komplett fehlerfrei.
Was meint ihr, würde mir ESXi einen Vorteil gegenüber Fedora + Cockpit bringen? In meinem Setup hatte ich den HBA durchgereicht an die FreeNAS VM. Wenn ich nur wüsste wie man die aufgetretenen Fehler troubleshooten könnte.
Das durchreichen ist auch kein einfacher Prozess mit KVM, dafür hat KVM praktisch keinen Overhead, was aber eigentlich egal ist, da soviel Performance ungenutzt brach liegt.
Sonst habe ich aktuell einen Ryzen 2600X kostenlos bekommen, alternativ wäre die Überlegung mit einem ASRock X470 D4U + 32GB DDR4 ECC RAM und der CPU den Storage Server zu betreiben.

Weiterhin nutze ich einen 56G Anbindung zwischen meinem Rechner, bzw. meiner Workstation, und dem Storage Server (bzw. vorher dem VM Host).

Die RAID 10 Variante werde ich nochmal probieren, inzwischen habe ich eigentlich immer ein Backup der wichtigsten Daten parat, früher habe ich rein auf den RAID vertraut.
Das Setup mit RAID 10 hatte ich von ca. 2009 bis 2017 in Einsatz, das resilvern ging immer recht zügig, und ohne spürbare Performanceeinbrüche im Pool.


EDIT:
Hier mal Logs vom IPMI beim EPYC System (das alte was vorher das Storage betrieben hat als VM).
Weiss jemand wie man so einen PCIe Fehler troubleshooten kann?
Screenshot from 2021-06-23 19-46-52.png

EDIT2:

Bei der EPYC Kiste hat sich das ASRock Board nun zum 3. mal verabschiedet, diesmal lasse ich es aber mit dem RMA'n.
Ehrlich gesagt will ich wieder zurück auf mein 128GB DDR4 ECC + ASRock X470D4U + Ryzen 1700 zurück. Das Ding hat irgendwie nie Probleme gemacht.
 
Zuletzt bearbeitet:
Ich finde dein EPYC-8DT nicht bei Asrockrack... Buchstabendreher?

Ausgehend von Supermicro pflegen hoffentlich alle Server-Produzenten mehr oder minder umfangreiche Kompatibilitätslisten. Einfach irgendwas zu installieren, wird eher nicht zuverlässig funktionieren und als Bonbon kommt noch PCI/PCIe-Passthru hinzu. Das war, ist und bleibt pingelig. Während reine HBAs fast immer ohne Probleme laufen, sieht es mit anderer HW eher durchwachsen aus. Hat deine System-Config noch jmd mit FreeNAS etc fehlerfrei (soweit bekannt) im Einsatz oder bist du der Drölffzigste, der mit Problemen kämpft und sich an einer Lösung versucht?
 
Ich finde dein EPYC-8DT nicht bei Asrockrack... Buchstabendreher?

Ausgehend von Supermicro pflegen hoffentlich alle Server-Produzenten mehr oder minder umfangreiche Kompatibilitätslisten. Einfach irgendwas zu installieren, wird eher nicht zuverlässig funktionieren und als Bonbon kommt noch PCI/PCIe-Passthru hinzu. Das war, ist und bleibt pingelig. Während reine HBAs fast immer ohne Probleme laufen, sieht es mit anderer HW eher durchwachsen aus. Hat deine System-Config noch jmd mit FreeNAS etc fehlerfrei (soweit bekannt) im Einsatz oder bist du der Drölffzigste, der mit Problemen kämpft und sich an einer Lösung versucht?
Hey ich grüße dich.
Ja das ist ne gute Frage, da hast du wohl Recht, Kompatibilitätslisten habe ich nicht durchforstet, ich habe wirklich wie immer, das Zeug genommen was ich gerade da hatte.
Vorallem beim Durchreichen von anderen PCIe Devices gab es zum Teil saftige Abstürze der Host Maschine nach einiger Zeit.
ASRock Rack EPYCD82T sollte es sein. Bin daher stark am überlegen beides zu trennen, Storage und Virtualisierung auf 2 getrennte Maschinen um da den Großteil der Probleme rauszunehmen.
Meinen Pool habe ich übrigends wieder repariert, musste alle Platten wipen, und dann konnte ich wieder einen neuen erstellen.
 
Als langjähriger ESXi-Nutzer würde ich Storage und Virtualisierung nicht mehr trennen wollen. Es ist zu verlockend einen HBA an @gea sein Nappit-AiO durchzureichen und dann den Platz flexibel per NFS und SMB zu nutzen. Ich würde in deinem Fall erstmal die HWL zum MB befragen und mich dann bei FreeNAS & Co durchlesen. Vielleicht erledigen sich deine Problem ja schon, wenn du wie vom @Trambahner vorgeschlagen den Expander entsorgst...
 
Vielen Dank, ich habe es so durchgezogen, und habe wieder mein "altes" Setup, also ASRock Rack X470D4U mit Ryzen 2700X, LSI HBA und ConnectX Mellanox 2 Karte und 128GB ECC RAM.
Den HBA reiche ich aktuell wieder an meine FreeNAS Maschine durch (Ist glaube ich eh besser so, da die Stromsparmechanismen in BSD eh nicht so prickelnd sind).

Habe jetzt wieder den "RAID 10" Approach gefahren den ich bis vor 2 Jahren ca. 7 Jahre lang genutzt habe, mal schauen wie das so performt. Die Rebuildtime müsste ja deutlich deutlich niedriger liegen als beim RAID-Z2 bzw. RAID-Z3.

Screenshot from 2021-06-28 11-32-13.png

Ich möchte außerdem demnächst von meinem 16 Bay Case was ca. 60kg wiegt, auf ein kleineres 8 Bay Case wechseln, jedoch habe ich da noch die Hot-Spare Platte übrig, wie würdet ihr das mit der Hot-Spare Platte handhaben? Würdet ihr die dann Intern im Case verbauen, oder weglassen? Die 8 Front-Bays werden dann durch die Pool Platten belegt sein.
 
"altes" Setup, also ASRock Rack X470D4U mit Ryzen 2700X, LSI HBA und ConnectX Mellanox 2 Karte und 128GB ECC RAM.
Den HBA reiche ich aktuell wieder an meine FreeNAS Maschine durch (Ist glaube ich eh besser so, da die Stromsparmechanismen in BSD eh nicht so prickelnd sind).

Die Sorgen kennt mein System nicht, da gibts AN, AUS und weniger oder mehr Krach aber weder S3 noch S4 und das unabhängig vom laufenden Host-OS. Die baldige Umsetzung von @Trambahner hinsichtlich Laufwerksanzahl dürfte dir auch auf kurze Sicht mehr Energie-Einsparpotential bringen als irgendwelche OS-Stromsparmechanismen. Auf der einen Seite gehst du mit X470-Chipset samt OC-CPU bei 128GB ECC-RAM und HBA (LSI SAS2008 liegt bei 10-15W) sowie Mellanox (20-25W) heran und auf der anderen Seite willst du Stromsparen.
Wie läuft das bei dir überhaupt, schaltest du deine VMs immer an und aus? Serverbetrieb und Energiesparen läßt sich in meinen Augen kaum vereinbaren, bei mir laufen Feed-Aggregator, Email- und Webserver im 24/7-Betrieb. Nur weil eine Platte mal länger zum Starten braucht, sollte das System nicht gleich einen Resilver hinlegen. Bei 9 Platten muß das NT auch schon etwas stabiler sein, damit es beim Einschalten nicht direkt in Überlast auf einzelnen Spannungsschienen rennt. Das erhöht jedoch die Energieaufnahme bei wenig Last und mit "EuP" wiederum bekommst du den Rechner nicht über Netzwerk aufgeweckt...
 
Ja also ich hätte die Variante hier gehabt mit 2 Systemen , einmal mit Ryzen 2600X + ASRock X470D4U + 32GB ECC RAM für Storage, und System 2. mit Ryzen 2700X + 64GB RAM Non-EC für die VMs.
Daher habe ich mich nun entschieden stattdessen ein System zu nehmen, mit Ryzen 2700X und 128GB ECC RAM, deswegen brauche ich nicht die 2. Storage Kiste mit FreeNAS, sondern virtualisiere das jetzt, und reiche den HBA wieder durch.
Lustigerweise habe ich wieder das gleiche System am Ende, wie ich es vor dem Umstieg auf EPYC hatte.
 
Hinsichtlich der Abstürze hat AMD gefühlt weiterhin das Nachsehen bei den Stabilitätstests gegenüber Intel. Die Testumgebungen und -abläufe bei den Herstellern mußten für Intel größtenteils kaum verändert und für Ryzen dagegen komplett neu entwickelt werden. AMD fehlt aber aufgrund seiner langen Abwesenheit konkurrenzfähiger Produkte auf der einen Seite das Geld und auf der anderen Seite das Personal, um Herstellern bei HW-Tests wie es Intel macht unter die Arme zu greifen. Bei Intel-Systemen bekommt man beispielsweise komplette RAM-Listen, was, wie und in welcher Konstellation unterstützt wird, bei AMD sucht man da deutlich länger oder geht möglicherweise sogar leer aus. Daher werden weiterhin (immer noch) mehr Intel- als AMD-Server verkauft. In einem anderen Forum hatte jmd mal geschrieben, daß er von 10 Angeboten nur 1x AMD angefragt wird und real bestellt würden aber fast nur Intel-Systeme. Es ist halt schwer reine HW zu verkaufen, wenn der Anwender nachher vor einem nicht lauffähigen System stehen könnte. Sowas schreckt Interessenten ab und preistechnisch langen beide CPU-Hersteller bei ihren Dickschiffen ordentlich zu.
 
Unsere komplette Virtualisierungs- und Oracleumgebung besteht aus AMD-Servern (Dell). Da gibt es genau NULL Stabilitätsprobleme.
Die Systeme starten nur neu, wenn man diese manuell rebootet...
Die ältesten von den Dingern laufen bereits seit mehreren Jahren im Dauerbetrieb ohne Probleme und ich habe gerade wieder 6 Stück mit jeweils 2 Epyc 7702 bestellt.

Man sollte vielleicht auch keine fertigen Server eines großen Herstellers mit "selbstgebastelten" Systemen vergleichen, wo Dinge wie Bios, RAM, Netzteil, MB usw reinspielen.

Aber klar, Sagen und Legenden ;)....
 
Gefühlt =|= Fakt. Letzteres ist interessant, ersteres allenfalls wenn letzteres nicht zu bekommen ist oder keine Rolle spielt.

Wer will darf Gefühl auch durch Meinung oder ähnliche subjektive Gemengelagen ersetzen.

Zudem hätte das „gefühlt“ wohl besser den ganzen Beitrag erfasst und nicht nur den ersten Satz… ;)
 
Gibt es eigentlich noch Platten mit URE 1 pro 10^16? Meine alten Seagate Savvio 73,4GB 15k Platten hatten URE von 1 pro 10^16.
Meine neuen WD Red haben nur 10^14, und meine HGST MegaScale 10^15.
Daher habe ich mir auch nen mirrored-striped vdev gebaut bzw. ein RAID 10 abgekupfert, die Rebuild Zeiten sind da noch echt annehmbar.
Ich frage mich ja wie hoch die Wahrscheinlichkeit eines Totalausfalls ist, bei einem 16 Platten RAID 6 , bzw. RAID Z2 gegenüber RAID 10, da habe ich bei meinem Ausfall ne Woche rebuilded, und weiteren Ausfall gehabt, und am Ende halt den Totalausfall.
Bald kommen 8TB Platten rein statt 4TB. Beim RAID 10 muss ja nicht viel rebuilded werden, und die URE ist ja dann auch egal. Da wird ja einfach nur gemirrort.
 
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