"Heimserver" mit Proxmox virtualsieren

PCGamer007

Lt. Junior Grade
Registriert
Okt. 2013
Beiträge
482
Hallo zusammen,
ich Betreibe zuhause einen kleinen "Server" der mehrere Funktionen beinhaltet. Unter anderem ist hier ein Adaptec 81605ZQ RAID Controller verbaut. Der braucht jedoch ca 20-25W und daher würde ich den gern los werden.
Der Server selbst ist ein Ryzen 2700 auf einem Asrock X470D4U2-2T und 16GB ECC RAM (+Paar HDDs und SSDs im). Außerdem eine DD MaxS8 und Duoflex CI PCIe Karte.
Aktuell dient er als Datenspeicher und Backupziel für mehrere Clients (meistens mit Veeam) und Verbindung zur HiDrive Cloud. Außerdem läuft darauf der DVB Viewer Media Service zum Streamen, ein Plex Server und VMs mit piHole und ioBroker.

Meine Überlegung war, mit Proxmox RAIDZ Pools zu erstellen und diese dann in einer VM mit OpenMediaVault zu verwalten.
Dabei sollen zwei RAIDZ1 aus (mind4) HDDs und ein RAIDZ1 aus (mind3) SSDs genutzt werden.
Welche Schreibgeschwindigkeit kann ich denn unter Proxmox erwarten bzw. was sind denn für Schreib und Leseraten mit ZFS Pools machbar? Mir geht es dabei um die Geschwindigkeit, mit der ich auf die Freigaben von OMV schreiben kann.
Dank dem Controller bin ich recht verwöhnt was das angeht und möchte ungern deutliche abstriche machen. Die HDD Pools dienen dabei für Veeam-Backups und Filme.

Außerdem soll der DVB Media Server und HiDrive in einer Win10 VM laufen. Kann ich dabei ohne Probleme die zwei PCIe Karten an die VM durchreichen ohne Probleme?

Die VMs selber sollen auf einer M.2 SSD laufen, damit die RAIDZ Pools nur für OMV sind.

Backups hätte ich direkt in Proxmox mit Veeam auf einen externen USB Speicher realisiert (wenn das machbar ist).

Viele Grüße
 
Hi,

Die Schreib/Lesegeschwindigkeit von ZFS hängt stark von der verwendeten CPU/MB/RAM-Kombination ab, da diese ja alle fürs RAID notwendigen Berechnungen ausführen müssen. Das Problem sind aber eher Dualcores und ältere HW, der Ryzen 7 2700 sollte dafür aber mehr als ausreichen. Dazu solltest du mindestens 8GB RAM nur für den Betrieb von ZFS einplanen.
Generell verwendet ZFS jeglichen freien RAM als Lese-Cache. Alles was aus dem Cache kommt, ist entsprechend schnell.

Andererseits hängst du an den Schreib-/Leseraten der einzelten Drives. Welche würdest du denn verwenden wollen?

Und welche Geschwindigkeit ist das Ziel? Verwendest du 1GBit LAN oder schon 10GBE, WLAN etc.?

Gruß,
süchtla
 
An RAM soll es nicht scheitern, da ich sowieso auf 32 GB gehen würde. Die HDDs sind aktuell alte WD greens und nicht wirklich schnell. Die Sollen aber durch WD Red oder Ironwolf ersetzt werden.

Super wäre, wenn ich 10Gbit ausnutzen könnte. Aber das ist kein muss, sondern ich hätte gerne zumindest annähernd die Performance von meinem RAID Controller.
Es wird auch nur 1 PC per 10 Gbit angebunden sein. Die restlichen Clients bleiben bei 1Gbit, jedoch sollen die Backups zeitgleich ablaufen.

Mir bereitet nur Kopfschmerzen, wie ich möglichst viele Platten anschließen kann, da ich nur 3 PCIe Slots habe, wobei 2 belegt sind. Und ob die DVB Karte und die CI-Modul Karte noch einwandfrei funktionieren, wenn sie in eine VM durchgereicht werden.


Ich frage mich auch, ob man HDDs auch an Hyper-V durchreichen kann und dann in Hyper-V ein FreeNas oder OMV aufsetzten kann mit ZFS? Oder gibt das Probleme?
 
PCGamer007 schrieb:
Ich frage mich auch, ob man HDDs auch an Hyper-V durchreichen kann und dann in Hyper-V ein FreeNas oder OMV aufsetzten kann mit ZFS? Oder gibt das Probleme?

Also von Haus aus kann Hyper-V auch Linux oder FreeBSD, also sollte Freenas und OMV laufen. Ich hab beide Systeme auch zuletzt mal getestet, jedoch unter VMWare ESXi bzw. direkt nativ installiert.
Festplatten direkt "durchreichen" macht man nicht, sondern man erstellt virtuelle Festplatten Dateien (die dann auf der betreffenden Festplatte liegen) und bindet diese in die virtuelle Maschine ein. Also die Hyper-V Gast Maschine interessiert sich nicht dafür was da für Festplatten an welchem Controller (Raid, etc.) angeschlossen sind.
 
Virtuelle HDDs durchreichen finde ich nicht gut. Denn damit, finde ich, ist es schwerer, ein Desaster-Recovery durchzuführen und die Performance leidet durch den Overhead auch.

Wenn du das Storage-OS (welches auch immer) virtualisieren willst, würde ich mit PCIe-Forwarding arbeiten. Zum Beispiel den gesamten SATA-Controller an die VM übertragen und die kann dann mit den Disks machen, was sie will.

10GBE voll zu machen wird wenn überhaupt nur mit den SSDs gehen. Meine eigenen ZFS-Benchmarks sind schon lange her, aber in den 200-300MB/s -Bereich sequenziell lesend bin ich damals mit 3x WD Green 3,5" HDDs und RaidZ1 gekommen. Schreibend weiß ich leider nicht mehr. Viele einzelne kleine Files sind halt für ZFS ebenso problematisch wie für einzelne HDDs, wenn du ZFS ohne write-cache verwendest. Mit Write-cache wirds aber richtig problematisch bei Stromausfall, daher würde ich das für home-use einfach nicht empfehlen.
 
Kann man den virtuelle Festplatten mit ZFS nutzen in einer VM? Dachte das das nicht immer optimal funktioniert.

Gibt es denn Controller wo mehr als 10 Sata anschlüsse dran sind?
 
ZFS mit virtuellen Drives sollte gehen. ZFS sollte auch mit Image-Files als Drives funktionieren, habe beides aber nie ausprobiert ;)

Ja, 16-fach HBA oder RAID Controller. Alternative sind SAS-Controller und SAS-Expander.

Da du aber deinen RAID-Controller aufgrund des Stromverbrauches los werden willst, wird es schwierig. Normale Mainboard haben ja nur 6 Ports. Du könntest nur die 6 Ports deines Mainboards und zusätzliche USB-HDDs verwenden. Oder einen kleinen extra-Controller für zusätzliche Ports. Und das ZFS dann über die verschiedenen Controller aufbauen, was möglich ist, da ZFS ja ein Software-Filesystem/Software-RAID ist.

Übrigens, der Strom-Mehrverbrauch von 3,5" HDDs gegenüber 2,5" HDDs ist nicht zu vernachlässigen.
 
Der Adapter ist aber für NVMe SSDs und nicht SATA.

Du brauchst schon einen SATA-Controller, wie diesen hier.

Ich habe noch einmal deinen Start-Post gelesen. Da sprichst du von 2 HDD RAIDZ1 Pools. Brauchst du wirklich zwei? ZFS hat ein Krücke en gravierendes Manko: du kannst später nicht die Anzahl der HDDs in einem Pool ändern. Du kannst aber sehr wohl HDDs austauschen, um die Kapazität zu steigern.

Mit wievielen SATA und wieviele NVMe Drives planst du jetzt? Macht es überhaupt Sinn, nach alternativen Controllern zu suchen?
 
Kleine Randbemerkung, Windows cached Schreibzugriffe auch mit RAM, wenn der großzügig vorhanden ist. Hilft natürlich nichts beim Lesen.
 
Ich weiß nur, dass man das in Windows pro Drive einschalten kann. Ist das mittlerweile per default an?
Bring halt das selbe Problem mit dem Stromausfall zurück. Alles was nur im RAM ist, ist weg und die Daten, die gerade geschrieben werden, können potentiell defekt sein.
 
Nur mal so. Desaster recovery ist mit virtuellen Festplatten um ein Vielfaches schneller /einfacher.
Eig nutzt man nur bei einer sehr begrenzten Anzahl an Anwendungsfällen das Durchreichen von Hardware direkt in den Gast. Beispiel FileServer FailOver Cluster über mehrere Nodes.
Ich empfehle dir deswegen klar zu virtuellen Festplatten... Später kannst du so viel einfacher migrieren.
Zu ZFS kann ich leider nichts beisteuern.
 
Moe.Joe schrieb:
Nur mal so. Desaster recovery ist mit virtuellen Festplatten um ein Vielfaches schneller /einfacher.
Von welchem Desaster sprechen wir denn? Meine Annahmen basieren auf einem Hardware-Ausfall, also entweder Drive oder Controller/Server/Mainboard Totalausfall. Da finde ich virtuelle Drives auf Basis mehrerer TB großer Files absolut unhilfreich.
 
Moe.Joe hat schon recht.
Man virtualisiert hauptsächlich damit man einen standardisierten Hardware-Layer hat auf den das ganze aufsetzt, damit man den beliebig wechseln und oder skalieren kann. Durchstößt man das Konzept indem man die Storage-Hardware direkt an Gastsysteme weiterleitet beißt man sich da wieder in den Host mit seiner Hardware fest und muss das im Zweifelsfall so nachbauen / wieder aufbauen.

Schnell mal die Container / virtuelle Maschinen aus einen Backup auf einen anderen Host hochfahren, wenn der eine kaputt gegangen ist, ist da dann nicht mehr gegeben.

Das mag ja im Homelab eventuell vertretbar sein... Aber um ehrlich zu sein habe ich aus genau diesen Grund meine Raspberry-Pi Sammlung durch einen Proxmox VE Host mit lauter LXC und VM privat abgelöst.
Immer wenn beim Raspi eine SD ausgestiegen ist, und das war nicht nur einmal der Fall, fing das Recovery-Theater an. Nervt privat leider genau so sehr wie beruflich...

Dazu kommen dann jetzt die ZFS- oder Unraid-Spezialitäten: Hardware ist eh nur noch Software.
Alles nur noch Pools und Volumes und Datasets... Da würde ich niemals etwas "direkt" an die Gäste durchleiten. Da konfiguriert man seinen Workload entsprechend drauf und hantiert da mit seinem VE schön mit virtuellen Festplatten drauf rum.
 
Ja, aber mit ZFS habe ich ja schon einen abstrahierten Layer und bin unabhängig von der Hardware. Da ist egal, ob ich einzelne Disk-Files oder den ganzen Controller durchreiche.

Und hier ging es anfangs primär um einen Storage-Server. Da hat man, finde ich, immer das Henne-Ei-Problem. Eine VM ist schön, snapshot-bar und gut wieder herstellbar, aber sie kann sich nicht wirklich auf ihrem eigenen Storages befinden.
Alle weiteren Services und Dienste würde ich auch Virtualisieren.

ZFS hat aber genau hier einen Haken: ZFS in einem Image-File auf einem anderen Dateisystem erzeugt recht viel Overhead, mehr als übliche Filesysteme.
 
süchtla schrieb:
ZFS hat aber genau hier einen Haken: ZFS in einem Image-File auf einem anderen Dateisystem erzeugt recht viel Overhead, mehr als übliche Filesysteme.
Auf ZFS nutze ich gar kein Image-File was im Dateisystem liegt, sondern ein sogenanntes Volume. Das ist kein vollständiges Dateisystem (im ZFS-Jargon Dataset genannt), sondern quasi ein Image das direkt im zpool liegt. Dort kannst Du beliebige Dateisysteme ablegen (selbstredend auch ein Image für eine virtuelle Maschine), profitierst aber trotzdem von den Funktionen die Dir der zpool mitbringt (Verteilung auf mehrere physische Datenträger, Snapshots, ggf. Kompression etc.)
 
Ehrlich gesagt weiß ich bei dem Szenario nicht zu 100%, wo da die Virtuelle Umgebung vom Storage-System abgetrennt ist. Openmediavault mit ZFS ist ja schon einen SAN ähnlicher als einem NAS.
Hat er dann jetzt einen zweiten Server, auf den die Proxmox-VE läuft und die den Storage vom OMV bereitgestellt nutzt? Dann wäre das ja alles überhaupt kein Problem...

Oder soll das irgendwie alles auf einer Kiste laufen? OMV drauf und daruaf manuell Proxmox installieren um OMV und PVE nebeneinander zu betreiben? Von solchen Spielereien würde ich dann doch eher abraten. Das kann funktionieren aber supporten wird das niemand und das kann dann hässlich werden.
 
Also in einer VM irgendwie ZFS zu erzeugen und dann auf durchgereichten Platten oder gar Image-Files abzulegen (oder ähnliches) ist natürlich weder zielführend noch optimal.
Ich würde es genau andersherum machen.
Das Hostsystem hat die Hohheit über ZFS. Und die VMs die darauf laufen benutzen das dann nur noch.
 
Für VM-Storages sind ZFS datasets natürlich ideal, aber bei dem Punkt geht man von einem funktionierenden Storage aus.
Ich meinte, ein ZFS Pool, bestehend aus virtuellen Drives, welche als Image-Files bestehen, ist umständlich und imperformant.

Der TE möchte alles auf einer Kiste haben. Daher sehe ich das Problem, dass du das Storage-OS nicht als VM auf dem Storage, welches es selbst bereit stellt, speichern kannst.

So wie ich es verstanden habe, möchte der TE Proxmox auf bare-metal und OMV mit ZFS als virtualisiertes Storage-OS. Nur die OMV-VM kann dann nicht auf dem OMV-provided storage laufen.

andy_m4 schrieb:
Das Hostsystem hat die Hohheit über ZFS. Und die VMs die darauf laufen benutzen das dann nur noch.
Ja, das ist der Ansatz, der auch mir am besten gefällt. Allerdings gibt es halt keinen OMV/PVE-Verschnitt mit ZFS aus dem Regal.

Ich hoffe, meine Beiträge sind nun besser einzuordnen.
 
Zuletzt bearbeitet:
Zurück
Oben