TrueNAS Scale: eure Erfahrungen, Zugriff mit unterschiedlichen Betriebssystemen, Tape Bibliothek in VM durch reichen?

jb_alvarado

Lt. Junior Grade
Registriert
Sep. 2015
Beiträge
492
Hallo Allerseits,
ich plane zurzeit einen Fileserver auszutauschen. Bis jetzt lief darauf immer ein Rhel basiertes OS mit Samba, NFS und AFP Servern. Zusätzlich liefen noch ein paar kleinere Dienste drauf, wie unter anderem eine selbst entwickelte Tape Backup-Software.

Wir sind damit immer gut gefahren, in den letzten ~5 Jahren hatte ich zweimal Probleme mit einem ZFS Update, was aber spätesten beim nächsten Update gefixt werden konnte. Finde ich persönlich völlig in Ordnung, weil jeder Zeit der Vorgänger Kernel gebootet werden konnte, und dort alles wie gewohnt gelaufen ist. Einmal gab es in der Zeit ein Problem mit der neusten Netatalk Version, was etwas nerviger war, aber auch behoben werden konnte.

Beim neuen Fileserver liebäugle ich aktuell mit TrueNAS Scale und wollte hier mal fragen ob jemand damit Erfahrungen hat? Wie schnell reagieren die Entwickler, wenn es Bugs gibt? Hattet ihr selbst schon Probleme damit und konnte diese gut lösen?

Bei uns ist es so, dass mit Linux, Windows und MacOS drauf zugegriffen wird. Offiziell ist bei Mac AFP veraltet und Samba sollte der neue Standard sein. Samba hat bei uns aber immer Probleme gemacht, deshalb hatten wir weiterhin AFP genutzt. Ein Problem war z.B. das unter MacOS oft die Meldung kam, dass eine Datei schon von woanders geöffnet sei, und deshalb nicht gespeichert werden konnte. Also Filelook hat nicht richtig funktioniert, Time Maschine ging in der Vergangenheit auch nicht. Wie sind hier eure Erfahrungen mit TrueNAS klappt dort Samba für MacOS? AFP gibt es ja hier unter Scale auch nicht mehr.

Ein weiterer Knackpunkt ist, dass wir eine Bandlaufwerk-Bibliothek haben. Diese hat zwei Laufwerke welche über externe SAS Anschlüsse an den aktuellen Server angeschlossen sind. TrueNAS selbst unterstützt Tapelaufwerke nicht, aber ich dachte mir, vielleicht könnte ich die in eine VM durch reichen und dort meine Software betreiben. Haltet ihr das für realisierbar?
 
jb_alvarado schrieb:
Wie schnell reagieren die Entwickler, wenn es Bugs gibt?
Wir bei jedem mehr oder weniger Open Source Projekt nach Best Effort per Community. Support durch iXsystems nur bei Truenas Enterprise, steht aber auch so auf der Webseite...
Besteht dein Problem bei einem der verwendeten Dienste, kann iXsystems da auch wenig machen sondern nur bei deren Hardware bzw der selbst entwickelten Middleware.

jb_alvarado schrieb:
dachte mir, vielleicht könnte ich die in eine VM durch reichen und dort meine Software betreiben. Haltet ihr das für realisierbar?
Lesen der Doku hätte deine Frage beantwortet...
https://www.truenas.com/docs/scale/...reens/#add-device-type-pci-passthrough-device
Brauchst halt einen PCIe HBA mit externen SAS Ports deiner Wahl und den HBA reichst dann an eine VM weiter.

Long story short: wenn ihr aus Compliance oder cover-your-ass Gründen Support braucht dann nur auf iXsystems Hardware und Truenas Enterprise (wahlweise dann mit "core" oder "Scale" als Unterbau zur Wahl aber keine Ahnung ob die überhaupt in EU oder DE tätig sind...
 
  • Gefällt mir
Reaktionen: andy_m4
snaxilian schrieb:
Wir bei jedem mehr oder weniger Open Source Projekt nach Best Effort per Community. Support durch iXsystems nur bei Truenas Enterprise, steht aber auch so auf der Webseite...
Besteht dein Problem bei einem der verwendeten Dienste, kann iXsystems da auch wenig machen sondern nur bei deren Hardware bzw der selbst entwickelten Middleware.
Die Nähe zur Community unterscheidet sich ja von Projekt zu Projekt teils sehr stark. Bei manchen Projekten ist der einzige Berührungspunkt der Bugtracker, bei Anderen sind die Entwickler auch in den User Foren unterwegs. Da hätte es mich mal interessiert wie es bei iXsystems ist. Das Bezahlkunden immer Vorrang haben, ist klar und absolut legitim.

snaxilian schrieb:
Brauchst halt einen PCIe HBA mit externen SAS Ports deiner Wahl und den HBA reichst dann an eine VM weiter.
Von PCI Passthrough hatte ich gelesen, hatte nur gehofft ich könnte vielleicht drauf verzichten den ganzen Kontroller durchreichen zu müssen. Hätte gerne nur einen verbaut mit 4 Anschlüssen, anstatt zwei mal zwei. USB und Festplatten lassen sich ja auch in eine VM durchreichen.
snaxilian schrieb:
Long story short: wenn ihr aus Compliance oder cover-your-ass Gründen Support braucht dann nur auf iXsystems Hardware und Truenas Enterprise (wahlweise dann mit "core" oder "Scale" als Unterbau zur Wahl aber keine Ahnung ob die überhaupt in EU oder DE tätig sind...
Danke für den Hinweis! Mir war nicht bewusst, dass Support nur auf eigener Hardware angeboten wird. Fand den Gedanken bei Scale interessant, dass man die Möglichkeit hätte bezahlten Support zu bekommen, wenn nötig.
 
jb_alvarado schrieb:
bei Anderen sind die Entwickler auch in den User Foren unterwegs. Da hätte es mich mal interessiert wie es bei iXsystems ist.
Naja >90% der User Fragen oder Probleme sind idR genereller Natur und nicht Produkt-spezifisch oder lassen sich durch lesen der Dokumentation lösen^^
Als kommerzielles Unternehmen würde ich da nur ungern meine Devs für verheizen in ihrer Zeit im Forum zu sein.
Es gibt aber einige Mitarbeiter die aktiv im Community Forum sind mit einer 4-stelligen Anzahl von Beiträgen. Im Zweifel selbst einen Blick ins Forum werfen und eine eigene Meinung bilden.

Wenn du aber eigene Hardware nimmst und das Problem im Zweifelsfall nicht auf anderer Hardware reproduzieren kannst, wird es schwer werden mit Support da es eben auf deine Hardware hin deutet. Gleiches gilt wenn du Änderungen an TN Scale vorbei vornimmst.

Naja sehr viele Probleme lassen sich auf die Hardware zurück führen, da kann iXsystems halt nicht alles und jeden supporten, v.a. wenn es ggf. irgendwas exotisches ist und es da keine Treiber oder bekannte Probleme gibt mit Debian/Linux was ja unter Scale als OS läuft und da hat iXsystems natürlich keinen Einfluss drauf. Ist doch aber bei anderen Anbietern nicht anders.
Versuch mal bei VMware Support zu bekommen für vSphere wenn die Hardware deiner Hypervisoren nicht auf der VMware HCL steht. Gleiches gilt für den verwendeten Storage bzw. das SAN bei VMware und bei anderen Lösungen sieht es ähnlich aus.


Du kannst auch einzelne Laufwerke oder sonstige Devices an eine VM durch reichen: https://pve.proxmox.com/wiki/Passthrough_Physical_Disk_to_Virtual_Machine_(VM)
Ja, da steht Proxmox aber Proxmox und TN Scale nutzen am Ende beide ja nur kvm/qemu als Hypervisor. Ist halt Gefrickel und Config an der GUI vorbei. Bei allen Updates/Änderungen per GUI musst du als Verantwortlicher also sicherstellen, dass dein Gefrickel anschließend auch noch funktioniert.
Noch ein Fund speziell zu SCSI Tape Laufwerken: https://k1024.org/posts/2019/2019-02-22-qemu-scsi-tape-passthrough/
 
  • Gefällt mir
Reaktionen: andy_m4 und jb_alvarado
Macht alles Sinn, was du sagst! Ich denke nach wie vor, dass TrueNAS eine gute Lösung ist, tendiere aber doch zu einer gewöhnliche selbst konfigurierten Lösung. Eine GUI für alles zu haben ist schon verlockend, aber wenn es um Fehlerbehebung geht fühle ich mich in der Konsole und einzelnen Anwendungen doch etwas wohler. Problematisch ist es vor allem wenn man einen Anwendungsfall hat, der so nicht vorgesehen ist, wie eben diese Tape-Backup-Geschichte. Habe da ein ungutes Gefühl bei, das zu virtualisieren.
 
Hast ja weiterhin SSH Zugriff für Fehlersuche nur Behebung an der Middleware vorbei würde ich halt nicht machen sondern das dann eher per Bugreport in der Middleware fixen lassen ;)

Aber ja: Appliances können einem das Leben erleichtern solange man keine nicht vorgesehenen Anwendungsfälle hat, dann muss man halt selbst aktiv werden oder eine passendere Appliance suchen.
 
  • Gefällt mir
Reaktionen: andy_m4
jb_alvarado schrieb:
Offiziell ist bei Mac AFP veraltet und Samba sollte der neue Standard sein.
Das Protokoll heißt SMB. Samba ist eine Software, die von macOS schon seit Ewigkeiten nicht mehr genutzt wird. Apple hat wegen der GPL3 eine eigene Implementierung von SMB geschrieben, die zufällig genauso so heißt wie der Serverdienst von Samba, nämlich smbd. Die haben außer dem Namen aber nichts gemein. Also tu dem guten Samba-Projekt bitte nicht unrecht. 🙂
 
Hast recht, habe mich falsch ausgedrückt. Das erwähnte Problem bestand halt trotzdem. Damit möchte ich jedoch nicht Samba die Schuld geben, die können da am wenigsten für. Fairer Weise muss man auch sagen, dass die Leute hinter Samba die letzten Jahre viel getan haben, um MacOS besser zu unterstützen.
 
Ich betreibe seit etwa einem Jahr privat ein selbstgebautes NAS mit TrueNAS Scale.
Die reinen Fileshares laufen 1a, sei es NFS oder SMB.
Der SMB-Share läuft bei mir sowohl auf Windows, Linux als auch MacOS zuverlässig.

Support hol ich mir meist auf den Community Discords von TrueNAS und TrueCharts, hat bisher immer geklappt.
Einziges was nicht immer perfekt läuft ist, dass das k3s manchmal nach Reboots etwas Probleme macht.
 
Danke @Mordenkainen, für deinen Erfahrungsbericht! Meinst du, du könntest hier mal deine Samba Config posten? Würde mich sehr interessieren, welche Werte TrueNAS verwendet. Wird man nicht eins zu eins übernehmen können, weil sie Inhouse eigene Module entwickeln, aber so bekommt man zumindest eine Idee für optimale Einstellungen.
 
...ist tatsächlich sehr simpel:
1682374859297.png
 
Ich danke dir! Mich hätte mehr der Inhalt von /etc/samba/smb.conf interessiert, aber ich kann mir auch eine Testversion installieren und dort noch mal schauen.

Edit:
smb.conf existiert so nicht, wie bei einer gewöhnlichen Installation, aber mit testparm kann man sich die Parameter anzeigen lassen:

Code:
[global]
    bind interfaces only = Yes
    disable spoolss = Yes
    dns proxy = No
    load printers = No
    logging = file
    max log size = 5120
    passdb backend = tdbsam:/var/run/samba-cache/passdb.tdb
    printcap name = /dev/null
    registry shares = Yes
    restrict anonymous = 2
    server multi channel support = No
    server string = TrueNAS Server
    winbind request timeout = 2
    workgroup = WORKGROUP
    idmap config * : range = 90000001 - 100000000
    fruit:zero_file_id = false
    fruit:nfs_aces = false
    rpc_server:mdssvc = disabled
    rpc_daemon:mdssd = disabled
    idmap config * : backend = tdb
    create mask = 0775
    directory mask = 0775


[share1]
    ea support = No
    kernel oplocks = Yes
    path = /mnt/pool/share1
    read only = No
    smbd max xattr size = 2097152
    vfs objects = streams_xattr shadow_copy_zfs acl_xattr zfs_core io_uring
    tn:vuid =
    fruit:time machine max size = 0
    fruit:time machine = False
    tn:home = False
    tn:path_suffix =
    tn:purpose = MULTI_PROTOCOL_NFS

Interessant ist, dass trueNAS gar nicht alle Parameter verwendet, die das Samba Wiki empfiehlt und trotzdem läuft es anscheint sauber bei dir @Mordenkainen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Mordi
@jb_alvarado Ach so. Hier meine parameter, aber die werden kaum groß abweichen.
Code:
[global]
        bind interfaces only = Yes
        disable spoolss = Yes
        dns proxy = No
        load printers = No
        logging = file
        max log size = 5120
        passdb backend = tdbsam:/var/run/samba-cache/passdb.tdb
        printcap name = /dev/null
        registry shares = Yes
        restrict anonymous = 2
        server multi channel support = No
        server string = TrueNAS Server
        winbind request timeout = 2
        idmap config * : range = 90000001 - 100000000
        fruit:zero_file_id = false
        fruit:nfs_aces = false
        rpc_server:mdssvc = disabled
        rpc_daemon:mdssd = disabled
        idmap config * : backend = tdb
        create mask = 0775
        directory mask = 0775


[share]
        ea support = No
        kernel oplocks = Yes
        level2 oplocks = No
        nt acl support = No
        oplocks = No
        path = /mnt/Storage/truenas
        read only = No
        smbd max xattr size = 2097152
        strict locking = Yes
        vfs objects = fruit streams_xattr shadow_copy_zfs acl_xattr zfs_core io_uring
        tn:vuid =
        fruit:time machine max size = 0
        fruit:time machine = False
        fruit:resource = stream
        fruit:metadata = stream
        tn:home = False
        tn:path_suffix =
        tn:purpose = MULTI_PROTOCOL_NFS
 
  • Gefällt mir
Reaktionen: jb_alvarado
Zurück
Oben