Virtualisierungsplattform für Heimbetrieb

apfel

Enthusiast
Thread Starter
Mitglied seit
17.10.2006
Beiträge
369
Ich wollte mir einen kleinen Homeserver zulegen, auf dem folgende VMs produktiv laufen sollen:
freeNAS (2vCPUs, 8GB RAM) (VM Snapshots, vDisks???, Datastorage (1TB))
pfsense (2vCPUs, 4GB RAM)
piHole (1vCPU, 512MB RAM)
Docker (4vCPUs, 16GB RAM) (als Untersützung bei kleineren Entwicklungsprojekten im angluar und java Umfeld für Buildpipeline und Testumgebungen)
Windows 10 (2vCPUs, 4GB RAM)

Bisher kommt für mich der Dell T40 in die engere Auswahl zusätzlich würde ich noch folgende Komponenten nachrüsten:
2x4TB Ironwolf oder besser 3x4TB im RAID5 ??? - Die Platten würde ich gerne mit dem OnBoard-Controller direkt zum freeNAS durchschleifen.
2x16GB ECC RAM
250GB NVMe Storage - Welches?
PCIe zu NVMe Adapter - Welcher?
Ethernetadapter mit 2x1GBit - Welcher?

Folgende Punkte habe ich noch offen bzw, würde ich gerne nochmal abklopfen lassen:
Gibt es bessere Alternativen zum T40 für die Anstehenden Aufgaben?
Muss ich beim PCIe zu NVMe Adapter irgendetwas beachten oder sind prinzipiell alle Adapter kompatibel?
Welche NVMe Karte für einen 24/7 Betrieb?
Ist das Konzept so einigermaßen stimmig?
Ist das Sizing der VMs ok?
Sollte man die vDisks der VMs besser auf dem Speicher des freeNAS ablegen oder direkt auf dem NVMe Storage?
Sollte ich ein RAID5 mit 3 Platten in Erwägung ziehen oder reicht das RAID1 hier aus?
Habe ich noch einen Puffer für kleinere zusätzliche Testmaschinen?
Ich lese im Forum immer wieder ESXi und Proxmox, bin bei meinen Recherchen zusätzlich auf XCP-NG/XENServer gestoßen wäre dieser eine Alternative oder ist der Hypervisor eher eine Glaubenssache?
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
FreeNAS sieht als Systemvoraussetzung 8GB vor. Das nur als Hinweis.

Für Ethernet: Intel Pro 1000 Quad. Die kosten keine 30€ und laufen super stabil.
 
FreeNAS selber ist auch relativ "fett". Wenn da wirklich nur ZFS, SMB und NFS laufen soll, dann auch mal Xigmanas anschauen, Basiert auch auf FreeBSD, ist aber puritanischer und braucht weniger Ressourcen für sich selbst.
Xigmanas könnte ggf. auch mit 4GB laufen, das wird aber nicht sonderlich performant.
8GB machen Sinn, bei FreeNas eher mehr.

Bei der W10-VM kommt es drauf an, was die tun soll. Für ein nacktes W10 reichen 4GB, je nach genutzter Sw wird das nicht lange reichen.
VMs willst Du nicht mehr wirklich auf nem HDD-Array haben, wenn die regelmässig zugreifen. Ich hab daher einen Datenpool für große Files und Archiv auf HDD und einen SSD-Pool für VMs und permament im Zugriff befindliche Arbeitsdateien.
Beim Ram auch bedenken, dass der Hypervisor auch was wegschluckt. etwa 2GB bei ESXI . 32GB wird da potentiell schon knapp werden. Zumindest nicht luxoriös.

Den OnBoard-Sata Chip durchzureichen kann funktionieren bei ESXI, muss aber nicht. Funktioniert nur über Tricks und die gehen je nach Board oder ESXI-Version auch nicht gesichert. Ein ESXI-Update kann Dir das schon unmöglich machen. Passthrough von einzelnen Sata-HDDs ist nicht ebenfalls nicht supportet. Meist gehts, manchmal gehts nicht.


Btw, bei dem Vorhaben auch das Budget nicht unterschätzen. Performance und Serverhardware kosten schnell.
Genereller Ratschlag: Halte dich von billigen Harddisks mit SMR-Aufzeichnungsmethode fern, die "spucken" gern mal mit ZFS (insbesondere bei umfangreichen Resilverings). Bei SSDs keine billigen Consumer-SSDs ohne Dram-Cache nehmen und auch "HostMemoryBuffer" meiden. Was genau da empfehlenswert ist, kommt immer genau auf die Anforderungen an.
 
Zuletzt bearbeitet:
Die Windows 10 VM läuft gerade als Dropbox VM und 4GB reichen, ist nur das "Notfall" Windows, da meine Geräte sonst nur mit Linux laufen.

Es sind von Haus aus ja schon 8GB RAM im T40 verbaut und die 2x16GB würden zusätzlich dazu kommen. Ein bisschen Luft zum Ausbau, wenns eng wird wäre mit max. 64GB auch noch drin.

OK, das mit dem Controller Passthrough wusste ich nicht, zur Not muss dann eben noch eine PCIe Karte dazu, würde ich zuerst mal auf einen Versuch ankommen lassen.

Budget und Qualität der Hardware ist mir bewusst, die Seagate IronWolfs, die ich hier noch habe sollten aber reichen. Welche SSDs und NVMes sind für 24/7 denn empfehlenswert? Aktuell tendiere ich zur Samsung EVO Serie.

Du spricht einen Punkt an, den ich nicht auf dem Schirm hatte. SSD im freeNAS für die vDisks. Ich habe jetzt für mich daraus 2 Optionen abgeleitet:
1. NVMe/SSD mit 500GB für Hypervisor und alle VMs im Local Storage
2. NVMe/SSD mit 128GB für Hypervisor und freeNAS im Localstorage zusätzlich SSD Pool im freeNAS für alle anderen vDisks.

Ich erkenne aber im Moment noch nicht den Mehrwert von Option 2.
 
Zuletzt bearbeitet:
Der Mehrwert der SSDs als ZFS-Pool? Du hast sämtliche ZFS-Vorteile für die Vdisks: Datenintegrität, Snapshots (und damit Versionierung und einfaches Backup durch zfs send/receive der Snapshots), LZ4-Kompression (bringt je nach OS ziemlich viel und braucht sehr wenig CPU-Leistung), Ram-Cache (Arc) des ZFS-Systems. Damit Du Redundanz bekommst, brauchst natürlich entweder Mirror- oder Raidz-Pools auch für die SSDs.

Ich hab für große Files (Archiv, Mediafiles, ISOs) mit überwiegend sequentiellen Zugriff einen HDD-Pool (6xHC530 im Raidz2) und für vdisks und täglich genutzte Arbeitsdateien und Random I/O nen SSD-Pool (6*Samsung SM863 960GB in einem Pool aus 3 Mirror-Pärchen).


Wenn Du eh nen HBA dazunimmst, reicht Dir zum Booten von ESXI eine kleine Sata-SSDs. Da drauf kommt dann auch die Storage-VM (diese muss ja local für den Hypervisor erreichbar sein). Der Rest kommt bei Option 2 dann auf die ZFS-Pools. Den Rest des Sata SSD Speichers kannst Du dann z.B. für ISOs nutzen.


Die Evo's kannst Du nehmen, wenn sehr wenig I/O auf den VMs ist. Wenn die permanent Schreiblast erzeugen: no go. Dann willst Du servergrade SSDs, denn die Consumer SSDs können ihre ach so tollen beworbenen Schreibleistungen nur kurz erbringen. Auch NVME-SSDs. ZFS mit aktivem Sync (was bei NFS-Protokoll der Standard ist und aus Gründen der Datenintegrität auch empfehlenswert ist) zieht Dir Consumer-SSDs nach relativ kurzer Zeit teilw. auf wenige MB/s runter. Server-SSDs dagegen können je nach Typ höhere Leistungen unter Dauerlast erbringen und haben höhere TBWs.
User hier im Forum haben schon Pools aus 850pro (und die sind bekanntlich ziemlich gute Consumer SSDs) auf wenige MB/s gehabt.

=> Du musst also überlegen, wieviel I/O Deine VMs da erzeugen und entsprechend passende SSDs für Performance und Ausdauer auswählen. Eine allgemeingültige Empfehlung gibts da nicht. Gilt natürlich auch, wenn Du sie als Local Storage einhängst.

V.a.: Knausere nicht mit Speicherplatz bei ZFS. Mit ZFS willst man in aller Regel auch gut gebrauch machen von Snapshots, Clones, usw. Daher lieber grosszügig-üppig planen.

Beachte, dass der T40 sehr wenig Platz zum Verbauen von Disks hat. Ferner sind die nicht im Luftstrom, so dass 7200er Disks (und solche der "5400 class") da schnell ein Probllem haben können. Was das Vibrationsverhalten betrifft, kann ich mangels T40 nichts sagen. Aber bei den T20+T30 bringen 7200er Disks das Gehäuse gerne schnell zum Vibrieren/Brummen.
Auch ein späteres CPU-Upgrade könnte problematisch werden; vom Bruder T3630 gibt es Berichte über laute Lüfter bei den stärkeren CPUs. Ferner brauchen die 95W+ CPUs einen anderen Lüfter als der des T40, d.h. ein späteres Upgrade auf einen E-2278 oder E2288 kannst Du mit nem Stock-T40 nicht wirklich machen.
Auch sind die 4 PCIe-Lanes des M.2-Slots vergeudet und nicht nutzbar weil per Bios gelockt. Wo der 1151-Sockel eh schon so wenig PCIe-Lanes bietet,
=> Planst Du also, den T40 bei Bedarf auszubauen, wirst Du sehr schnell an Limits stossen.
 
Zuletzt bearbeitet:
Folgende Entscheidungen habe ich nun getroffen:

Hardware:
  • Dell PowerEdge T30 (konnte ich sehr günstig ergattern, reicht ein Singlsocket bzw. die Cores nicht aus, wäre das ein günstiges Learning gewesen :))
    • CPU Intel Xeon E1225 v5
    • RAM 3x16GB ECC
  • Zusätzlich:
    • HDD 3x4TB Ironwolf
    • SSD Samsung 512GB Pro, hatte ich noch übrig, sollte ich hier Probleme (Platz/Geschwindigkeit) haben, wird diese getauscht
    • HBA Dell Perc H310
    • NIC Intel Quad 1Gbit
Die VMs lege ich erstmal aufs Local-Storage, da mir der Pool keinen Mehrwert bietet
  • günstiger Start, Umstieg auf ZFS Pool später immer noch möglich
  • eine Versionierung der gesamten VMs brauche ich nicht, da die VMs sehr statisch sein werden, die Dynamik findet eher innerhalb der Docker Container statt und diese sollten durch Backup der Konfigurationen und Imagedefinitionen leichtgewichtig zu versionieren und zu sichern sein
Beim Hypervisor habe ich mich für xcp-ng entschieden.
Gegen die anderen sprach für mich persönlich folgendes:
  • ESXi
    • Lizenzmodell
    • Closed Source
  • HyperV
    • Lizenzmodell
    • Microsoft ...
  • Proxmox
    • finde das Konzept den Hypervisor mit zusätzlichen Funktionalitäten (Management GUI, ZFS, Container) zu überladen eine Fehlentscheidung. Als Softwareentwickler bin ich es gewohnt das Prinzip Seperation of Concerns anzuwenden und es fühlt sich für mich einfach falsch an, diese Dinge in den Hypervisor aufzunehmen
Danke Gen8 Runner und Trambahner für die Denkanstöße.
 
Zuletzt bearbeitet:
Wieso sollte das Lizenzmodell vom ESXi ein Nachteil sein ?
Solange du keinen zweiten Server hinstellst brauchst du die ganzen Enterprise Features nicht, da du bei der Free-Variante in kein Limit rennen wirst mit dem T30.
 
Also ohne Enterprise Plus + OM geht bei dem System Garnichts. Wie soll man auch sonst den Cluster bedienen.
 
Stimmt, für meinen Fall trifft der Nachteil nicht zu. Bleibt aber dennoch Closed Source ;)
 
Und Hyper-V ist dann open source?
Was willst du denn mit open source anfangen? Was willst du denn am ESX z.B. verbessern/debuggen/what ever?

Wenn du nicht grad nen Wunderkind in der IT bist und die Top 1000 Leute bei Google, AWS, IBM und Co. zum Frühstück frisst, sehe ich nicht, was du (oder man) an einem solchen System für Hand anlegen will.
 
Das OpenSource Konzept ist mir sympatischer, es bindet die Community stärker in die Entwicklung mit ein. Bei ähnlichem Angebot bleibt es doch sowieso eine individuelle Entscheidung.

Was kann ESXi denn besser als xcp-ng?
 
Performanter, weniger Probleme mit exotsichen Guests (Wird Solaris z.B. überhaupt als Guest supported ?), stabiler...
 
Stabilität und Performance - Quellen?

Guest Support ist für den Anwendungsfall irrelevant.
 
Ist doch prima, bekommen wir Erfahrungen zu einem weiteren Hypervisor aus erster Hand. :d

Ich jedenfalls kenne den xcp-np nicht. Habe selbst einiges (auch exotischere) ausprobiert und bin dann bei ESXi kleben geblieben. Andere lieben Proxmox und wieder andere finden Hyper-V am hübschesten.

Das Open Source Argument wäre mir total egal, solange ich das Ding so benutzen kann/darf wie ich will. Mir käme es allein (in der Reihenfolge) an auf: stabil, stabil, stabil, hohe Flexibilität, aktive Communities die helfen können, Ease-of-use.

Wenn man aber hardcore Open Source Verfechter ist, kann ich das verstehen (teile das aber wie gesagt nicht ;)) - es schließt aber halt die „gängigsten“ Vertreter kategorisch aus.
 
Ich habe zuletzt auch alles Mögliche ausprobiert. Proxmox, XCP-NG, KVM unter Debian, bin dann aber wieder zurück zu ESXI.

So ein bissl meine Gedanken:

ESXI ist zwar kein Open Source, ja, aber die freie Lizenz gibt es jetzt schon seit Jahr(zehnten)? Und die reicht mir im Homesetup. Und am Code kann ich eh nix ändern, bin Anwender. Das Handling der VMs ist simpel und zu allen Systemen sehr gut dokumentiert, irgendwo im WWW. Das System kümmert sich um nichts Anderes als virtuelle Maschinen zur Verfügung zu stellen. Also Fokus auf eine Kernkompetenz und nicht der krampfhafte Versuch eine Eierlegende-Wollmilch-Sau zu erschaffen.

Bei Proxmox habe ich das Gefühl, da soll möglichst alles auf ein UI geschafft werden. Das ist mir zuviel Overhead und macht die Sache für mich (!) zu intransparent. XCP-NG ist da gefühlt nur ein wenig anders, steht allerdings noch am Anfang. Damit werde ich irgendwann auch wieder spielen, für den Moment fühlt sich ESXI aber für mich richtiger an.

Bei mir sind andere Server-Funktionen dann entweder dedizierte VMs (pfsense, NAS napp-it) oder werden über Docker in einer debian Instanz gefahren. Jede einzelne Funktion macht dann eins und da suche ich mir jeweils das aus, was mir am besten liegt. Pro Dienst eine eigene Instanz/Container, sozusagen.

Zu ESXI gibt es auch eine globale "Community", der OS-Footprint ist extrem schmal auf der Festplatte, die von mir genutzten OSses werden unterstützt (Linux, BSD, Solarish, WIndows, macos) und nach zwei Havarien weiss ich das System binnen 20 Minuten wieder zum Leben zu erwecken, ohne in zwanzig Menüs zu klicken. :-)
 
XCP-NG basiert auf XenServer (Citrix) - gibt es mWn auch schon lange auf dem Markt.
Wir freuen uns auch deine Berichte - positive wie auch negative, sofern es da was gibt.
 
Das mit XenServer stimmt, allerdings ist der Fork "XCP-NG" dabei, sich zu entwickeln und zu emanzipieren :d ... positiv: es kommt da regelmässig was Neues. Gestartet hatte das Ganze wohl in Q1/2018.

Was ich empfehlen kann: https://www.youtube.com/user/TheTecknowledge/search?query=xcp-ng - Tom von Lawrence Systems hat mich dazu gebracht, mir das mal anzuschauen. Er präsentiert, wie ich finde, entspannt und sachlich, ist gut zu verstehen und, er setzt die Lösungen auch bei seinen Kunden ein. Was per se schon mal ein wichtiger Aspekt ist, denn er muss die Teile dann auch (remote) warten. Und da trennt sich dann die Spreu vom Weizen. Manche Lösungen kann man nicht wirtschaftlich betreiben, wenn man nicht direkt drauf sitzt ;)

Wichtig: Um nahezu alles chic in Schuß halten zu können, braucht es XEN Orchestra. Das Tool wird von den gleichen Machern zur Verfügung gestellt, wie der Kern. Allerdings ist für die Nicht-Kommerzielle-Version Selbstkompilieren angesagt. Zumindest, wenn man Tom's Empfehlungen folgt. Wenn man aber eh mit Containern arbeitet, ist man mit einem Docker-Container wesentlich schneller am Ziel. Ich habe das Ganze in 5 Minuten am Fliegen gehabt und Updates von XEN Orchestra sind mit Docker, auch ohne Neu-Kompilieren, ebenso schnell am Start.

Wie gesagt, ich schaue mir das noch mal an, allerdings nicht vor Herbst. Das ist eine Interessante Basis. Für mein Homelab nutze ich erst mal ESXI weiter; da läuft alles, was ich brauche. Bei meinen Kunden setzte ich allerdings KVM ein. Das hat für die konkreten Anwendungsfälle einen extrem schmalen Footprint. Storage spielt dabei allerdings keine Rolle ...


EDIT:
- XEN Orchestra - https://xen-orchestra.com/docs/installation.html#xoa
- Docker - https://github.com/Ezka77/xen-orchestra-ce
 
Zuletzt bearbeitet:
Kurzer Zwischenbericht, nachdem sich die Lieferung einzelner Teile etwas verzögert hatte, die SSD für den Hypervisor habe ich erstmal verworfen, da ich mit umstieg auf NVME den OnBoard SATA Controller durchschleifen konnte.

Grundgerüst:
  • T30 mit Xeon E3-1225 v5 (Upgrade auf aktuellstes BIOS und anschließend Downgrade auf 1.0.2 für M.2 Support)
  • 48GB ECC RAM (2x8GB und 2x16GB)
  • 256GB NVMe (M.2 Slot)
  • NIC Intel Quad alle 4 Ports im Bond
  • XCP-NG 8.1 als Hypervisor
VMs:
Aktuelle CPU Auslastung:
  • Idle: 3%
  • bei Maximallast der Windows 10 VM: 40%
Aktueller Verbrauch:
  • Idle: 30 Watt
  • bei Maximallast der Windows 10 VM: 50 Watt

Mögliche Optionen:
  • 2x512GB SSDs als ZFS Mirror im freeNAS für Container volumes und virtuelle Platten
offene Punkte:
  • Feintuning Monitoring
  • Backupkonzept Container Volumes
  • Entwicklungsinfrastruktur
  • Autosync Fotos Smartphone zu freeNAS
  • pfSense
 
Zuletzt bearbeitet:
@apfel Wie sind denn Deine Erfahrungen? Gerad emit Hinblick auf xcp? Ich habe gerade auch etwas getestet, ESXI war mir etwas zu rudimentär, Proxmox gefiel mir da schon besser. Überlege gerade XCP zu testen...
 
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