Hallo Zusammen,
ich baue mir einen neuen TrueNAS Scale Server auf. Zum Einsatz kommt ein DL380 Gen9 mit 128GB Ram und 48x (+2 Spare) 900GB 15k SAS über einen 16e HBA. Angebunden über momentan noch 10Gbit
Ich stelle mir gerade die Frage wie genau ich den Storage-Pool konfigurieren soll?
12 VDEVs Z1 mit je 4 Platten oder
4 VDEVs Z2 mit je 12 Platten
beides kommt von der Kapazität ungefähr auf´s gleiche raus
Wie verhält es sich mit Cache- und LOG VDEVs? Zur Verfügung würde mir eine HP (Samsung 1725a) 1.6TB NVMe PCIe Karte zur verfügung stehen. Würde dies für folgenden Einsatzzweck Sinn ergeben?
Mein Anwendungen sind sehr gemischt. ESXi und Proxmox Virtualisierung für Cloud-, Medien- und Datenbankserver. Protokolle: iSCSI, NFS und SMB Shares
Über ein paar Tipps würde ich mich sehr freuen.
Viele Grüße Simone
ESXi, Proxmox und Datenbanken würde ich mir keine HDDs antun, auch keine 15k SAS. Trotz SLOG wirst du vermutlich mit 3way mirror SSDs besser fahren und vermeidest auch eventuelle RAIDZ Effizienz und rw amplification Probleme.
Z1 ist kleines Risiko, weil dir nur eine Platte ausfallen darf, resilver sollte aber immerhin schnell sein weil deine Platten so klein sind. Wäre mir zu heiss.
Wie gross sind deine Speicherbedürnisse, wenn Daten und Anwendungen getrennt sind?
Ohne diese Infos würde ich folgendes vorschlagen:
Ich würde also mir einen 3way SSD mirror aufbauen für VMs und iSCSI und HDDs für SMB und NFS.
Eventuell, wenn die SAS Platten eh schon rumliegen, keine hohen write Anforderungen da sind und der HBA nicht limitiert, damit 8 RAIDZ2 die 6 wide sind anlegen die Samsung SSD als SLOG.
vielen Dank für deine Antwort. Z1 war der Gedanke weil nur 4 Platten im gleichen Verbund laufen, wie hoch ist die Wahrscheinlichkeit, dass 2 von 4 Platten gleichzeitig ausfallen? Klar das Z1 macht mir auch Bauchschmerzen und von der Sicherheit würde ich auch eher zu 4 x 12 Z2 tendieren, was aufgrund der wenigen VDEVs schlechter für die IOPS ist.
Momentan liegt der Platzbedarf bei knapp unter 10TB Für “normale” Daten, davon eich Großteil Mediendateien und 2,5TB für VMs, Datenbanken machen da aber nur mit einigen geschätzten 100MB bis max 1GB den Bruchteil aus. ansonsten ist der Rest auf dem VMs auch nur Webdienste, Cloud-Dienste und ein bisschen Business-Software (sprich Windows Terminal-Server).
Meine Priorität liegt ganz klar bei Datensicherheit und nicht bei Performance. Momentan läuft das ganze auf 24 x 1TB 7200U/min 6G SAS Platten im Raid 60 mit 2GB Hardwarecache auf dem Controller. Die Performance ist gar nicht sooo schlecht (knapp 980MB/s Lesen & 850MB/s schreiben). Die neuen Disc-Enclosures sind alle mit 12G SAS Dual-Domain angebunden. Wenn ich etwas Performance Zuwachs dadurch habe, welchen ich mir auch nochmal durch die 1,6TB NVMe erhoffe, dann bin ich zufrieden, denn den größten Vorteil den ich bei Truenas und ZFS sehe ist die Skalierbarkeit, die ich mit meinem jetzigen Aufbau kaum habe.
Die wichtigsten Daten sollen dann auf das “alte” Raid 60 (P4) Array gesichert werden.
Um nochmal ein 3way SSD Mirror aufbauen zu könne würde dies bedeuten, dass ich nochmal in eine Disc-Enclosure und in die SSDs investiern müsste, was bei Enterprise-Hardware (auch wenn es aus dem refurbished Markt) stammt, doch etwas in´s “Kleingeld” geht. 800GB 12G SAS SSDs kosten pro stück so um die 350EUR, Aber ja zukünftig wäre es aufgrund der einfachen Skalierbarkeit eine Überlegung wert und werde da deinen Ratschlag auf jeden Fall befolgen.
Soll die alte Hardware weiterverwendet werden? Oder kaufst Du neu und migrierst?
Habe mal unter der Annahme der Migration geschrieben.
Gar nicht so tief, wie man glauben mag. Dafür gibt es zwar Rechner online, ein Punkt wird dabei aber nicht berücksichtigt:
Aktuell, genau jetzt, mag die Wahrscheinlichkeit tief sein für zwei Ausfälle. Wie sieht es aus in 5 Jahren? Wenn die Platten schon ziemlich alt sind und einige Stunden auf dem Buckel haben? Dann ändert sich die AFR. Das wird in diesen Rechnern aber nicht berücksichtigt.
IOPS ist sowieso “schlecht”, egal ob es nun 4 oder 12 vdevs sind. Selbst ein einzelner SSD mirror wird Runden rennen um dein 12 vdev.
Dann stellt sich mir noch die Frage, warum 4x 12 Z2 und nicht 8x 6 Z2?
Die Pool Geometrie und natürlich die Performance wäre bei 8x 6 Z2 besser.
Weiss nicht ob Du blockstorage und welche volblocksize und welchen workload du hast, aber bei 16k volblocksize ist die Speichereffizienz zwischen den beiden identisch.
Das hört sich erst mal seltsam an, hat aber damit zu tun wie Daten in ZFS gespeichert werden. In diesem Link, die Tabelle RAIDZ2, die Spalte 16k, wirst Du sehen, Speichereffizienz ist identisch. Klar kannst du eine volblocksize von 64k verwenden, hast dann aber amplification, wenn dein workload kleiner ist. Noch besser wäre auf blockstorage zu verzichten und datasets anstelle von zvols zu verwenden. Geht vermutlich nicht für Deine VMs, aber für Deine Mediendaten.
Verständlich, der 2GB write cache wird vermutlich viel helfen. Wie ist der Performance nach 2GB schreiben? Wie sieht es aus bei nicht sequentiell, sondern random 4k?
Du wirst KEINEN Performancezuwachs mit SLOG bekommen!
SLOG ist KEIN write cache!
SLOG ist einzig und alleine ein Zwischenspeicher für den ZIL. Bei sync writes, und nur bei sync writes, wird der pool entlastet, indem der ZIL nicht auf den pool sondern auf das SLOG geschrieben wird.
Bei async writes verändert ein SLOG genau gar nichts!
Das ist in keinster weise mit deinem aktuellen 2GB Hardwarecache vergleichbar!
Dein Cache ist ein write cache, SLOG ist kein write cache!
Was du machen könntest, ist deinen Hardwarecache vor einer HDD als SLOG zu brauchen. Vergiss aber nicht alle anderen HDDs in IT mode zu setzten, damit ZFS direkten Zugriff auf die Platten hat. Vielleicht geht dies mit Deinem Kontroller gar nicht. Wenn wir schon dabei sind, erlaubt Dein Kontroller überhaupt direkten Zugriff auf die Platten?
Skalierbarkeit inwiefern? Falls du Speicherplatz meinst, RAIDZ zu erweitern ist eine nervige Angelegenheit. Dann besser mirror.
Angenommen du brauchst nur 4TB für VMs.
Du könntest neu 6x Samsung PM1643a 2TB für ca. 2400€ kaufen und im 2x 3way verwenden. Refurbished vermutlich noch weniger.
Die Mediendaten könntest du dann auf deinen alten SAS Platten speichern. 3x RAIDZ2 8 wide performt für Mediendaten super.
So ganz generell, würde ich mir ein System gut überlegen, aufschreiben, hier posten.
Vor dem Einsatz unbedingt erst testen!
Das alte TrueNAS Forum war voll mit enttäuschten Usern. Um eine anständige Performance zu haben, darfst du für VMs zum Beispiel bei RAIDZ den pool nicht über 50% füllen. Und der von mir verlinkte Link bezüglich Speichereffizienz bei zvols, ist auch eine Falle in die häufig getreten wird. Hypervisor wie Proxmox gehen so weit und raten wegen den vielen Stolpersteinen grundsätzlich von RAIDZ ab und empfehlen mirror. RAIDZ kann fast nur in die Hose gehen für blockstorage.
Hoffe ich habe Dich nicht überrumpelt mit Infos
Hoffe ich habe verständlich geschrieben, ansonsten gerne nachfragen.
ja mittlerweile habe ich schon etwas mit dem System rumspielen können. Nachdem ich trauriger weise feststellen musste dass TrueNAS keine redundanten SAS-Uplinks (mehr) unterstützt. Mein produktives TrueNAS-Cobia scheint dies noch zu können. Das Aktuelle Dragonfish hatte schon bei der Installation ein Kernelpanic. Kabel aus den 2nd Controllern ausstecken hilft. Wenn ich die Links nach der Installation erst wieder einstecken werden mir keine Platten mehr im TrueNAS angezeigt. Der Befehl lsblk und alles was mir noch so eingefallen ist, listet aber alle Platten in der Shell korrekt auf. Ich will ja nichts unterstellen aber ich glaube iXsystems macht es wie viele andere Softwarehersteller erst ein großen Funktionsumfang in der Community-Edition anbieten und dann von Version zu Version immer weiter limitieren, damit man auf ein Bezahlmodell “upgradet”
Momentan bin ich aber mit einem anderen Problem am Kämpfen.
Egal wie ich die Pool gestalte und egal mit welchen Platten (48xHDD im Stripe oder verschiedene RaidZ Kombis, Hardware-Raid, oder PCIe Slot NVMe) ich komme nicht über 490MB/sek beim Lesen und/oder Schreiben hinaus. Installiere ich ein Win2019 Server und verwende ähnliche Konfigurationen (abgesehen von ZFS) erreiche ich Datenraten von 1500 MB/sek (r&w) bis 3600MB/sek (HPE - Samsung 1725a Datenblatt
Momentan beobachte ich auch das seltsame Verhalten, dass wenn ich eine Singledrive Stripe anlege (weil Hardware Raid). Sind dort im Dataset immer nur 538,75GB nutzbar, egal wie groß der Pool ist.
So langsam kommt mir der Gedanke, dass ich mich mit Cephstorage auseinandersetze. Allein die nicht funktionierenden redundanten SAS-Links sind fast ein K.O. Kriterium.
Ansonsten hast du mir wirklich sehr hilfreiche Infos gegeben wofür ich mich sehr bedanke. Und nein du hast mich mit deinen Infos nicht überrumpelt
Dual controller scheint tatsächlich der Enterprise Version vorbehalten zu sein.
Fairerweise muss ich zugeben, wer ein redudanter Controller zusätzlich zu scale-out benötigt, ist schon eher Enterprise Kunde. Oder wie du richtig angemerkt hast, vielleicht eher CEPH das passende System.
Deine Benchmarks und die Grösse der Datasets ist schon sehr krumm. Ist der Controller wirklich im IT oder HBA mode und nicht im RAID mode?
Ich habe mit beidem rum experimentiert. Raid-Mode sowie HBA-Mode.
Der Serverinterne Controller (SmartArray P420i) muss zwangsweise im Raid-Mode betrieben werde da ich sonst nicht von den Platten booten kann (lässt das Bios der Proliant Server nicht zu). Der andere Controller (SmartArrayP841) läuft natürlich im HBA Mode. Da werden mir ja auch alle Platten präsentiert. Ich werde mal Versuchsweise eine ältere Version von TrueNAS installieren um zu schauen wie sich das System dann verhält.
Ich habe noch den Verdacht das mein HPE EthernetNic mit QLogic Chip der Flaschenhals ist.
Ceph als Single-Node Lösung ist halt auch nicht so das Gelbe vom Ei.
“Controller im HBA Mode” ist kein echter HBA. Nur letzteres wird unterstützt und führt nicht mit hoher Wahrscheinlichkeit zu Datenverlust.
Alles andere als einen LSI-HBA mit IT-Firmware sollte man für ein produktives TrueNAS im unternehmenskritischen Einsatz nicht verwenden. Das Thema wurde hier im Forum schon hundertmal und wirklich abschließend durchgekaut.
RAID-Controller nur zum Booten wäre ok, aber auch wirklich nur für den Boot Pool.
Tut mir leid, dass ich das sage, aber ein Controller im HBA mode macht genau das, was es aussagt, nämlich ein passthrough der SAS Lanes bzw. LUNs. Sämtliche befehle, die einen physikalischen zugriff benötigen wie “smartctl” lassen sich problemlos ausführen und liefern die gewünschten Resultate, alle mit dem Raidmodus verfügbaren features sind dann natürlich auch nicht verfügbar. Also sorry, wenn es so riskant wäre eine Enterprise Controller im HBA mode laufen zu lassen, was mit hoher Wahrscheinlichkeit zu Datenverlusten führt, dann ist salopp gesagt TrueNAS ein schlechtes system. Ich glaube HPE würde keinen Modus anbieten der riskant ist und nicht das tut was es sagt. Ja ich habe die aussage schon öfters gelesen aber ausreichend begründet wurde es nie! Also wäre ich sehr dankbar um ein paar aussagekräftige und fundamentierte Argumente oder Links, warum der HBA-Mode kein echter HBA sein soll. Mit den LSI-Karten passiert ja auch nichts anderes sie werden durch die Firmware auch nur in einen entsprechenden Modus versetzt! Hardwaremäßig können die LSI-Karten auch beides, nur dass HPE eben einen Möglichkeit implementiert hat, dies ohne umflashen der Firmware umzustellen.
Natürlich gehe ich davon aus, dass diese Hinweise gelesen wurden
Beim SmartArrayP841 ist vermutlich nur schon PCIe 8x ein stark limitierender Faktor für hohen Durchsatz.
Nee, glaube 3 sind das Minimum. Wenn aber HA so wichtig ist, dass sogar dual SAS entscheidend ist, ist es heute modern gleich die ganzen nodes redundant zu haben. Darum war mein Vorschlag Ceph.
Hat nichts zu tun mit TrueNAS sondern mit ZFS.
ZFS hat wie alles im Leben vor und Nachteile. Ich persönlich finde es befreiend mich nicht mit RAID Karten rumschlagen zu müssen und mit ZFS ein Software RAID gefunden zu haben. Andere finden es doof, ihre alten Kontroller nicht mehr weiterverwenden zu können.
Doch, wenn HPE offiziell nur Windows Server und Red Hat unterstützt und nicht damit rechnet, dass ein User darauf ZFS benutzt.
Leider kenne ich mich zuwenig aus mit HPE Kontrollern um da eine Antwort zu liefern. Es liegt an Dir, die Kompatibilität sicherzustellen. Wer das nicht möchte, kann zu einem fixfertigen System von iXsystems greifen.
[quote=“Simone-Alicia, post:10, topic:2919, full:true”]
Also sorry, wenn es so riskant wäre eine Enterprise Controller im HBA mode laufen zu lassen, was mit hoher Wahrscheinlichkeit zu Datenverlusten führt, dann ist salopp gesagt TrueNAS ein schlechtes system. Ich glaube HPE würde keinen Modus anbieten der riskant ist und nicht das tut was es sagt. Ja ich habe die aussage schon öfters gelesen aber ausreichend begründet wurde es nie![/quote]
HPE unterstützt TrueNAS nicht. Sie verkaufen ihre Hardware mit Support für Windows und wasweißichgeradenicht für eine Linux-Distribution. Alles andere ist “good luck”.
ZFS wurde von Sun Microsystems mit etlichen Personenjahren und für etliche Millionen designed und implementiert, einzig und allein zu dem Zweck, “Hardware-RAID” ein für alle mal abzuschaffen. Man benutzt ZFS anstelle von RAID- oder “Enterprise”-Controllern, nicht mit.
Natürlich würde ich eine solche Konfiguration nicht in einer hochkritischen Datacenteranwendung einsetzen, in dem Fall sehe ich aber rein praktisch keinen Unterschied ob es ein LSI-Controller mit IT-Firmware oder ein HP Controller im HBA Mode ist. Wie oben schon ergänzt, alle Befehle die einen “echten” physikalischen Plattenzugriff benötigen, lassen sich ausführen und bringen die zu erwartenden Resultate, was darauf hinweist das tatsächlich keine weitere Verarbeitung durch den Controller stattfindet.
Klar hat PCIe gen3 8x seine grenzen aber laut Spezifikation müssten 7,8GB/sek machbar sein, klar praktisch wird es etwas weniger sein. Aber über andere Betriebssysteme erreiche ich ja bis zu 3600MB/sek auf der NVMe
Ich habe nun auch auf dem TrueNAS system mal etwas mit dd auf den entsprechenden Pool rumgespielt, und siehe da ich bekomme auch raten von 1500 bis 3000MB/sek hin. Auch wenn dd eventuell nicht ganz aussagekräftig ist zeigt es mir doch, dass es wohl am Ethernetnic liegen muss.
RAID controllers typically aggregate several disks into a Virtual Disk abstraction of some sort, and even in “JBOD” or “HBA mode” generally hide the physical device. If you cannot see the type of device (such as “ST6000DX000-1H217Z” in “camcontrol devlist”, you DO NOT HAVE A TRUE HBA. If you cannot get the output of “smartctl” for a device, you DO NOT HAVE A TRUE HBA. A true HBA passes communications through itself directly to a drive without further processing.
Und genau das ist mein Argumentationspunkt. Ich kann smart Befehle mit smartctl direkt auf dem SCSI Generic Device (sgX) ausführen, ich erhalte alle HDD-Infos. auch mit lsblk --scsi -r erhalte ich alle hardwarespezifischen Daten. Ich benutze die HP SmartArray Controller viele Jahre in sämtlichen Linuxdistributionenen und hatte nie Treiberprobleme. Also was spricht dann noch gegen diesen Controller?
Leider kann ich mich zu HPE nicht äussern, da ich diese Kontroller überhaupt nicht kenne.
Noch nie habe ich von HPE Kontrollern gelesen im Zusammenhang mit ZFS, wage darum zu bezweifeln, dass die überhaupt supported sind.
Ob lsblk alleine eine aussagekräftige Quelle ist kann ich auch nicht beurteilen. Die von Dir Zitierte Quelle heisst für mich übersetzt:
Wenn lsblk nicht den Typ gibt, hast du kein HBA.
Daraus aber im Umkehrschluss zu schliessen, wenn lsblk den Typ ausgibt, habe ich einen direkten Zugriff auf die Platten, halte ich für einen Trugschluss.
Deine Benchmarks sind leider auch wenig aussagekräftig. Normalerweise würdest du lokal und nicht über Netzwerk testen, ansonsten kommen zu viele Variablen dazu. Dann noch die Frage, ob du datasets oder zvols getestet hast, welche settings, welche pool config und ca. 20 weitere Dinge. Zudem stellt sich halt auch die Frage, was genau getestet werden soll. Sequential rw für VMs ist nicht gerade ein aussagekräftiger Test. Random rw 4k fände ich spannender. Kommt aber halt auf den use case an.
bei lsblk kommt es natürlich drauf an mit welchen Parametern man den Aufruf macht. Aber spätestens die Smarttools wie smartctl würden nicht mehr funktionieren, wenn der Controller dazwischen funken sollte.
Es wird wahrscheinlich ok sein, du bekommst bei evtl. Problemen nur weder Unterstützung von HPE, noch besonders gut hier, weil all die erfahreneren Leute solche Setups eben meiden wie der Teufel das Weihwasser.
Wenn man bei HPE kein support agreement hat, so auch bei den meisten anderen Enterprise Hardwareherstellern, bekommt man eh keinen support.
Also ich habe mir jetzt nochmal viele Beiträge unter anderem auch den von dir verlinkten Beitrag genau durchgelesen. Selbst im offiziellen Hardware Guide von iXsystems ist lediglich die rede das ein Controller im Raid modus nicht empfohlen wird und dadurch einige Einschränkungen entstehen. iXsystem sagt aber auch selber das ein Controller der den HBA Mode unterstützt in Ordnung ist, wenn er auf physischer Ebene den zugriff auf die drives gewährleistet und die u.a. von mir erwähnten Operationen auf den Platten ausgeführt werden können. Also nach allem was ich jetzt in diversen Foren gelesen habe schein es ein Community gemachtes problem sein. Rein technisch spricht nichts dagegen wenn der Kernel grundsätzlich den Controller unterstützt. Bei TrueNAS Core auf BSD basis mag das natürlich mit der Treiberunterstützung anders aussehen. Eventuell resultieren auch daher noch diese Mythen um die Unterstützung der Controller, aber spätestens seid SCALE auf Linux-Basis sollte dieses Thema eigentlich gegessen sein.
Laut manual von HPE, scheint HBA mode (oder Port mode in neuen Kontrollern) tatsächlich sämtliche RAID Funktionen zu deaktivieren und direkten Zugriff auf die Platte zu geben.
Wenn du HPE glaubst und deren Firmware keine Fehler hat
Es sprechen zumindest alle meine Tests dafür, dass es tatsächlich so ist. Und ja wie du schon sagtest: In den neueren Controllern… In den älteren Modellreihen, gab es die Option hbamode=on gar nicht. Somit hatte man wirklich keine Chance da irgendwas physisch ans laufen zu kriegen.
