Frage zur Strukturierung - TrueNAS SCALE vs Proxmox

sandreas

Lieutenant
Registriert
Juli 2012
Beiträge
551
Hallo zusammen,

ich habe mir hier einen kleinen Home-Server zum rumspielen aus vorhandenen Materialien gebaut. Das ganze wird zwar 24 / 7 laufen, aber wenns weg ist, ist es weg - Backups der Daten sollen natürlich gemacht werden, Redundanz und Hochverfügbarkeit ist aber nicht nötig, Betriebssystem-Backups auch nicht. Fokus liegt auf Stromsparen und vernünftiger Leistung bei geringen Kosten und einigermaßen vertretbarem Verwaltungsaufwand.

Aktuell läuft dieses Homelab auf einem Intel NUC 6 mit Ubuntu 18.04 als Docker-Host - stromsparender gehts kaum, aber der hat langsam zu wenig Power und ist recht Wartungsintensiv, da alles handgeklöppelt ist (Docker mit Photoprism, NGINX, OpenVPN und alle dienste manuell installiert und eingerichtet).

Kurz zusammen gefasst die neue Hardware:
  • ASRock C236 WSI
  • Intel XEON 1225 (4 Cores 4 Threads)
  • 32GB ECC RAM
  • 2TB Samsung 980 Pro

Was soll drauf laufen:
  1. OpenVPN Server
  2. Ubuntu Desktop 22.04 als virtuelle xrdp Remote-Workstation und Audio + Video-Encoding (ich möchte mich von unterwegs drauf einloggen und Software entwickeln)
    1. Hier wird schon etwas Leistung gebraucht, es ist kein 4K Material, aber ein bisschen was unter der Haube wäre schön - insbesondere schnelles IO wäre gut, daher die NVMe Platte
  3. Windows VM für iTunes zum Sync meiner iPods mit USB-Passthrough
    1. Hier reicht ein bisschen Leistung - soviel das iTunes mit einer mittelgroßen Bibiothek noch halbwegs umgehen kann
    2. Der iPod muss angeschlossen werden können und zuverlässig erkannt werden.
  4. Weitere Services wie Photoprism, eventuell NextCloud, etc.

Mein aktueller Plan sieht so aus:
  • TrueNAS SCALE als Host mit 14GB verfügbarem RAM, der nicht an VMs gebunden ist.
    • VM1: Ubuntu, 3 Cores, 12GB RAM
    • VM2: Windows 10, 1 Core, 6GB RAM, 60GB SSD
    • OpenVPN über TrueNAS Dienste integriert
    • Photoprism über TrueNAS als "App" (Docker / Kubernetes)
    • 50GB als schneller SMB Shared Storage für unkomplizierten Gast-Dateiaustausch zwischen Geräten
    • 150GB als SMB mit Home-Share funktion inkl. Berechtigungsverwaltung
Problem ist nun:
  • VM1 (Ubuntu) macht auch das Encoding von meinen Musik und Hörbuch-Dateien, folglich muss die Windows-VM auf den Storage der Ubuntu VM zugreifen können
  • Ein gemeinsames Netzwerk-Share über TrueNAS wäre "die richtige" Lösung, allerdings würde das die Bandbreite des Storages doch arg beschneiden (auf 1Gbit wegen Netzwerk) und das wäre für die encoding-VM richtig blöd
Lösungs-Ansatz 1:
  • VM1 bekommt ca. 1,5TB vom SSD Storage (also was nach dem 200GB Share und 60GB Win10-VM übrig ist) und hat unter Ubuntu ein eigenes kleines Samba-Share verpasst, worauf die Windows VM dann zugreift.
    • Vorteil: Schneller Storage in Encoding-VM, Zugriff von Windows möglich
    • Nachteil: Zusätzlicher Einrichtungsaufwand des Samba-Shares unter Ubuntu, Latenzen bzw. Performance Verlust durch Dopplung der SMB Services
    • Die Frage, die man sich dann stellen muss: Überhaupt noch mit Truenas virtualisieren, oder knallt man einfach wieder ein Ubuntu-Desktop auf die Hardware und installiert portainer manuell dort?
Lösungs-Ansatz 2 (Idee - VirtFS / VirtioFS / 9p):
  • TrueNAS stellt einen Storage bereit, der in VM1 und in VM2 gleichermaßen als Passthrough-Storage gemounted wird (nicht über Netzwerk, sondern als echter Storage - das soll wohl über zvol und einige freaky Einstellungen machbar sein) - Stichwort ist hier "VirtFS" oder "virtiofs" oder "Virtio-fs" oder 9p (siehe auch hier) - mit Proxmox scheint das schon zu gehen. Noch mehr infos hier
    • Vorteil: Schneller Storage für beide VMs, Zugriff von Windows möglich
    • Nachteil: Machbarkeit fraglich, Stabilität?, Verlässlichkeit?
Fragen:
  • Was meint ihr zu dem Gesamtkonzept?
  • Wozu würdet ihr mir raten?
  • Gibt es vielleicht einen anderen Weg, die 1GBit Netzwerk Beschränkung für Shares INNERHALB der TrueNAS SCALE Maschine zu umgehen (z.B. ein virtuelles 100Gbit Netzwerk Interface, was nur intern verwendet wird)?
  • Wäre Proxmox eine sinnvolle Alternative - z.B. wegen besserer Ausgereiftheit? (Insbesondere wegen virtiofs)
 
Zuletzt bearbeitet:
Ich lausche, da ich auch von Proxmox mit alter Hardware auf TrueNAS scale gehen will mit Nextcloud & Plex 😁
 
  • Gefällt mir
Reaktionen: sandreas
Da ich Proxmox nur oberflächlich und TrueNAS garnicht wirklich kenne, kann ich der primären Diskussion leider wenig beitragen, sorry.

Ein paar Anmerkungen habe ich trotzdem:
sandreas schrieb:
VM2: Windows 10, 1 Core, 6GB RAM, 60GB SSD
Overprovisioning von CPU-Ressourcen ist bei keinem mir bekannten Hypervisor ein Problem. Ich würde der Windows VM mindestens 2 Kerne zuordnen, sonst ist mit der zu arbeiten eine Qual.

sandreas schrieb:
Ein gemeinsames Netzwerk-Share über TrueNAS wäre "die richtige" Lösung, allerdings würde das die Bandbreite des Storages doch arg beschneiden (auf 1Gbit wegen Netzwerk) und das wäre für die encoding-VM richtig blöd
mWn sollte man eigentlich bei jedem brauchbaren Hypervisor einen internen virtuellen Switch erstellen können, der nicht an die Geschwindigkeit des physischen Netzwerkadapter gebunden ist.

Bei den VMs die untereinander kommunizieren diesen als zweite Netzwerkschnittstelle hinterlegen damit darüber SMB laufen kann...
https://forum.proxmox.com/threads/how-to-get-maximum-network-speed-between-ct-vm.62556/

(Wie weit das für TrueNAS gilt fehlt mir die Erfahrung, ich habe mit FreeBSD noch nicht gearbeitet)

sandreas schrieb:
Lösungs-Ansatz 2 (Idee):
  • TrueNAS stellt einen Storage bereit, der in VM1 und in VM2 gleichermaßen als Passthrough-Storage gemounted wird (nicht über Netzwerk, sondern als echter Storage - das soll wohl über zvol und einige freaky Einstellungen machbar sein) - Stichwort ist hier "VirtFS"
    • Vorteil: Schneller Storage für beide VMs, Zugriff von Windows möglich
    • Nachteil: Machbarkeit fraglich, Stabilität?, Verlässlichkeit?
VirtFS kenne ich jetzt garnicht, und wirklich viel Dokumentation habe ich spontan nicht gefunden.

Zumindest von Windows aus sollte der Zugriff vermutlich read-only sein, sonst wird das vermutlich wie Multi-Zugriff per iSCSI enden: in Tränen (?)

Ich mein - kannste gerne ausprobieren, aber würde ich nicht auf etwas machen was 'einfach laufen soll'.

sandreas schrieb:
Wäre Proxmox eine sinnvolle Alternative - z.B. wegen besserer Ausgereiftheit?
Zumindest geht das da mit dem internen Switch (Bridge) definitiv :D
 
  • Gefällt mir
Reaktionen: sandreas
Rickmer schrieb:
Overprovisioning von CPU-Ressourcen ist bei keinem mir bekannten Hypervisor ein Problem. Ich würde der Windows VM mindestens 2 Kerne zuordnen, sonst ist mit der zu arbeiten eine Qual.
Guter Punkt, das sollte ich machen.
Rickmer schrieb:
mWn sollte man eigentlich bei jedem brauchbaren Hypervisor einen internen virtuellen Switch erstellen können, der nicht an die Geschwindigkeit des physischen Netzwerkadapter gebunden ist.
Virtueller Switch... natürlich, das ist auch ein guter Punkt bzw. ein gutes Stichwort. Ich werde mal sehen, ob TrueNAS SCALE sowas kann. Danke.

Rickmer schrieb:
VirtFS kenne ich jetzt garnicht, und wirklich viel Dokumentation habe ich spontan nicht gefunden.
Ja, ist auch irgendwie shady für mich. Klingt nicht, als würde ich das auf meiner Spielwiese haben wollen, geschweigedenn in der Produktion.

Vielen Dank für den sehr nützlichen Beitrag!
 
  • Gefällt mir
Reaktionen: Rickmer
sandreas schrieb:
Virtueller Switch...
Scheint zu gehen: https://www.truenas.com/community/t...e-create-an-virtual-switch.95269/#post-660910

You can have a bridge without an IP address. I currently have two bridges and 4 physical interfaces on my TrueNAS SCALE machine. I have one of my bridges configured with 1 physical interface as a member and no IP address. This bridge (br0) is my "VM virtual switch" and is the interface that I assign all my VMs to. I also have another bridge (br1) without any physical interfaces and no IP address as a "host only" virtual switch. Note that the physical interface I assigned to br0 is NOT my main physical interface (the one that is running the GUI and NAS services such as SSH, SMB, NFS, etc.). I tried this once and was not able to talk to the TrueNAS GUI, so it rolled back. So my setup is close to what you show in your first post.

Also so wie es aussieht und ich es richtig verstanden habe, muss man
  1. Eine Bridge ohne IP konfigurieren (br0)
  2. Diese muss ein physikalisches Interface ohne IP-Adresse als Member haben
  3. Alle VMs müssen diesem Interface (br0) zugewiesen werden
https://www.truenas.com/community/t...te-an-virtual-switch.95269/page-2#post-673248

Here's what I have set up and working:

br0 - For VMs that need to be on my main network at home
  • members: A physical interface on my NAS that is plugged into my main switch, but does not have an IP address and is not used for anything else (GUI, File Sharing, etc.). VMs on this bridge act just like any other machine on my network.
  • IP address: none

br1 - For VMs that need to be completely isolated (no access to anything on my network or the NAS)
  • members: none
  • IP address: none

br2 - For VMs that don't need access to my main network but need access to the NAS
  • members: none
  • IP address: an IP address that is NOT part of my main network. So if my main network is 192.168.0.0/24, this bridge could be assigned to 192.168.1.1/24. Other VMs on this bridge will also be on the 192.168.1.0/24 network and will have access to the NAS on 192.168.1.1 but that's it. No internet, no other network access (unless you do some routing/bridging with another VM).

Eine Alternative Variante beschreibt jemand hier: https://www.truenas.com/community/t...te-an-virtual-switch.95269/page-2#post-674816


Noch habe ich zwar nichts davon getestet, aber so ganz einfach scheint es nicht zu sein. Viele beschreiben Probleme mit der Konfiguration. Die Performance hat niemand erwähnt. Bin gespannt, ob hier jemand einen Weg kennt, wie es gehen könnte.

Update - VirtIO hab ich gefunden, meine bisherigen Erkenntnisse: Folgende Variante funktioniert bei mir bisher (Performance-Tests stehen noch aus):
  • Statische IP für das physikalische Interface vergeben (enp0s3343, IP: 192.168.1.202)
  • Interface hinzufügen (Add), Type: Bridge, Name: br0 mit DHCP und ohne IP anlegen
    • Member: ein physikalisches Interface (z.B. enp0s3343)
  • Unter Virtualization eine existierende Maschine auswählen (oder halt eine neue anlegen)
    • unten auf Devices gehen
    • bei NIC die 3 Punkte rechts, dann Edit auswählen
    • Adapter Type=VirtIO
    • Nic to attach=br0
  • Oben im Menü wackelt dann das Netzwerk-Symbol, weil man die gemachten Änderungen übernehmen muss
  • Wenn der Test funktioniert, dann kann man die Änderungen speichern
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Rickmer
Zusatzinfo: Windows hat funktioniert, mit einem Ubuntu 22.04 Client funktioniert es noch nicht, irgendwie kann er sich nicht verbinden. Nach einem weiteren Test hat sich herausgestellt, dass immer die ERSTE VM die man startet eine IP bekommt, die weiteren nicht.

  • Unter Windows bekommt man schlicht keinen Netzwerkadapter angezeigt (und natürlich auch keine IP)
  • Unter Linux schlägt das Festlegen einer IP einfach fehl

Durch die Bridge-Konfiguration scheint das ein Problem zu sein. Das heißt also nicht nur kein "Internet", sondern auch keine Verbindung zu den Shares... Als nächstes möchte ich versuchen, dem Problem hiermit bei zu kommen (MACVLAN):

https://www.furorteutonicus.eu/2013...uest-networking-with-kvm-macvlan-and-macvtap/

Das wird aber den Eingriff auf der Kommandozeile erfordern. Bisher überzeugt mich "TrueNAS SCALE" noch nicht - einfach ist anders. Zum Performance-Test bin ich noch gar nicht gekommen.
 
Zuletzt bearbeitet:
Ohne eine Bridge kann man vom Gast nicht auf den Host verbinden. Also, wie folgt hat es funktioniert:

  • Network => Global Settings
    • Überprüfen, dass man folgendes eingetragen hat:
    • Default Route
    • Nameserver (hier habe ich erst meinen, 1=192.168.1.1, 2=1.1.1.1 und 3=8.8.8.8)
  • Der primären Netzwerkkarte eine statische IP zuweisen und DHCP entfernen, Apply
  • Änderungen testen und übernehmen
  • Die statische IP der primären Netzwerkkarte wieder entfernen, Apply
  • Ein Bridge Interface anlegen
    • Type: bridge
    • Name: br0
    • DHCP: not checked
    • Bridge-Members: primäre Netzwerkkarte auswählen
    • IP-Adresses: Die statische IP von vorhin eintragen
    • Apply
  • Änderungen testen und übernehmen
    • Vorab: Die Zeitspanne für das zurücksetzen von 60 auf 180 Sekunden erhöhen
    • Wenn hier das Web-Interface zu hängen scheint, einfach einen neuen Tab aufmachen und neu laden, dann sollte der "Save" button auftauchen

Bei den VMs muss nun folgendes ausgewählt werden:
  • Adapter-Type: VirtIO
  • Nic to attach: br0
  • Rest standard
Getested habe ich mit Windows 10 und Ubuntu 22.04 LTS. Zu beachten ist, dass man für Windows noch einen VirtIO Treiber braucht (siehe hier, download the latest stable), mit Ubuntu 22.04 hats ohne weiteres funktioniert.

Schreib-Performance-Test eines via SMB gemounteten Shares auf Samsung 980 Pro 2TB ergibt 1,8GB/s - Gigabyte, nicht Gigabit pro Sekunde (das sind aber ideale Testbedingungen... sequenzielles Schreiben, etc.):

Code:
sudo dd if=/dev/zero of=testfile bs=1G count=10 oflag=direct
10+0 Datensätze ein
10+0 Datensätze aus
10737418240 Bytes (11 GB, 10 GiB) kopiert, 6,00165 s, 1,8 GB/s

Unter Windows mal ein Ubuntu ISO kopiert, da hatte ich zwschen 350 und 400MB / s lesend und schreibend.


Vielen Dank nochmal an @Rickmer - es scheint jetzt so zu funktionieren. Auf den Praxistest bin ich gespannt.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Rickmer
Na dann bin ich mal froh, dass das geklappt hat :)

Danke auch, dass du den Ablauf schrittweise dokumentiert hast. Das wird sicherlich noch jemandem helfen.

Hast du auf den VMs jetzt nur den virtIO Adapter am br0 oder zwei Netzwerkadapter - einen am br0 und einen am primären Nic?
 
  • Gefällt mir
Reaktionen: Blaze1987 und sandreas
Rickmer schrieb:
Danke auch, dass du den Ablauf schrittweise dokumentiert hast. Das wird sicherlich noch jemandem helfen.
Klar, das war auch mit für mich, falls ich das nochmal machen muss :-)
Ergänzung ()

Rickmer schrieb:
Hast du auf den VMs jetzt nur den virtIO Adapter am br0 oder zwei Netzwerkadapter - einen am br0 und einen am primären Nic?
Rickmer schrieb:
Hast du auf den VMs jetzt nur den virtIO Adapter am br0 oder zwei Netzwerkadapter - einen am br0 und einen am primären Nic?
Nur den VirtIO Adapter am br0. Das scheint wunderbar zu funktionieren, solange das Standardgateway am Host gesetzt ist.
 
Weiß jemand von euch mit ZFS Erfahrung, ob es DDR5 mit on-die ECC genauso gut funktioniert wie DDR3/4 mit ECC?
 
Sorry wenn offtopic - ich konnte bis heute keine sinnvolle Aussage für ZFS finden…
Falls DDR5 equivalent zu DDR4 ECC, dann wird AM5 Plattform mein Favorit für den TrueNAS Scale Server
 
Dig.Minimalist schrieb:
Falls DDR5 equivalent zu DDR4 ECC
Ist es nicht
gab's auch schon Artikel drüber, einfach mal googeln
 
Zurück
Oben