[Kaufberatung] Homeserver mit Storage VM - Hardwareoptionen?

Dann bleibt noch die Frage, was es bedeutet wenn dort steht VGA for IPMI beim Board Supermicro X11SAE-F retail (MBD-X11SAE-F-O).

Bedeutet das, dass ich den VGA port nur nutzen kann wenn ich per IPMI draufschalte und sollte man den Server als nicht headless steuern, das Bildsignal nur über DVI/HDMI/DP ausgegeben werden kann?

Danke für die Hilfe mit Napp-it, da werde ich denke ich einen Blick drauf werfen, wenn die Teile alle da sind.
Dann wäre jetzt die Frage ob es insgesamt stimmig ist:


Der RAM wird auf der Seite von SM als unterstützt angegeben: Memory List

Diesmal hab ich glaub ich auch einen M.2 Port drin ;) und da ich die Argumentation des ATX Formats sinnig fand, hab ich hier auch jegliche Baugrößen dabei.

Ich denke mal, dass ich da mit dem ESXi auch erstmal in keine großen Fallen tappen werde oder?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Über den VGA Port kann man normal einen Monitor anschliessen.
Die Ausgabe die hier anliegt kann man aber auch per IPMI zum Fernbedienen per Browser nutzen

ps
Warum dieses Board für ESXi?
Ich fände für den Preis eine X11SSL-CF | Motherboards | Products - Super Micro Computer, Inc. besser. Kein M2 (für NVMe bräuchte man eine PCI-e Version), dafür aber einen LSI HBA zum Durchreichen von 8 SAS/Sata Ports fürs Storage. M2 ist dagegen eher weniger wichtig da eine kleine Sata SSD für ESXi und eine Storage VM völlig reicht. Durchreichen einzelner Platten per RDM ist eher Murks.

Gäbs alternativ als X11SSH-CTF | Motherboards | Products - Super Micro Computer, Inc. auch mit 10 GbE.
Wenn man nicht wirklich CPU Power braucht, täts auch eine kleinere CPU ab G4400 aufwärts. Die können auch ECC und Pass-through

ps
bezüglich Speicher kann man auch bei Kingston schauen
Speichersuche – Zum Finden des richtigen Speichers | Kingston
 
Zuletzt bearbeitet:
Den fehlenden m2 (PCIe) Slot kann man grds. auch easy mit einem Adapter PCIe-->m.2 ersetzen, entsprechend freien "normalen" PCIe Slot vorausgesetzt.
 
Tja...
Warum nicht das von dir vorgeschlagene Board... Ich hatte auf den Controller verzichten können und wollte die M.2 nativ auf dem Board haben.

Kann man denn mit DeLOCK PCIe Card 1xinternal M.2 NVMe die M.2 anschließen und auch von dort die VMs booten? Die Karte müsste ja eigentlich nur im ESXi erkannt werden.

Auf dem Board Supermicro X11SSL-CF ist ja ein Slot frei. Dann wäre hier sogar der passende Controller integriert, mit dem man die HDDs einzeln weiter reichen kann und die SAS/SATA Erweiterbarkeit auf mehr als 8 Platten ist gegeben (Hier müsste man dann eine entsprechende Backplate Cremax Icy Dock MB453IPF-B anschaffen richtig?)

Was den Kingston RAM angeht, wieso wird der nicht auf der Supermicro Seite gelistet? Wenn mir die Kingston Seite aber versichert, dass Kingston ValueRAM DIMM 16GB DDR4-2400 kompatibel ist, ist davon auszugehen, dass es auch funktioniert?
 
Was soll die NVMe bringen?
Für ESXi und die Storage VM ist das unnötig und weitere VMs liegen üblicherweise eh auf der Storage VM. Die kann storagemäßig um Welten mehr als ESXi. Für das Storage nimmt man dann SSDs oder Platten. Wenn NVMe dann könnte man daraus einen High-Performance Mirror für VMs oder einen Lese-Cache oder ein Logdevice für sicheres Schreiben bauen. Bei letzterem wäre aber Powerloss Protection angesagt, z.B. mit einer Intel P750

Das ICY Dock wäre ok, ich würde wohl die Variante für 4 Platten nehmen, eventuell einen 2ten mit 2,5".
Kingston RAM entsprechend Speichersuche ist ok

ps
Man kann per Pass-through keine einzelnen Platten weiterreichen sondern nur den kompletten LSI HBA Controller mit allen 8 Ports.

Ich mache das immer folgendermassen: http://napp-it.org/doc/downloads/napp-in-one.pdf
 
Zuletzt bearbeitet:
Was genau meinst du mit
gea schrieb:
und weitere VMs liegen üblicherweise eh auf der Storage VM. Die kann storagemäßig um Welten mehr als ESXi. Für das Storage nimmt man dann SSDs oder Platten.
Zum Vergrößern anklicken....
?

Ich hatte hier folgendes beschrieben:
hoyohayo schrieb:
Aber genau deshalb war die Virtualisierung als Basis und nicht der Storage als Basis gedacht.
Zum Vergrößern anklicken....

Also wollte ich eigentlich ein VMmanager (vSphere Center sprich ESXi) einsetzen. Hier habe ich die Möglichkeit, VMs zu erstellen, zu verwalten und von überall aus dem Heimnetzwerk aufzurufen. Diese VMs sollen auf einer SSD gespeichert werden (aus Performance Gründen) und dann erweiterbaren Speicher kriegen (die HDDs können eingebunden werden, wie auch immer ob mit LSI, AHCI oder RDM sei erstmal dahin gestellt).

Es soll eine VM als StorageVM dienen (die soll auch 24/7 laufen). Hier liegen alle HDDs parat (durchgereicht über den Controller), man kann aber jeder VM dennoch ca 20GB lokal Platz geben auf der SSD, dann ist erstmal gut vorgesorgt und bei Bedarf werden die HDDs aus der StorageVM per iSCS in die anderen VMs eingebunden.

Jede VM kriegt ein eigenes OS, die StorageVM war ursprünglich XPEnology gedacht, hier kann aber eben auch Napp-it, NAS4Free, OMV, FreeNAS... verwendet werden.
Weitere VMs wie ein wegwerf Windows, eine Ubuntu VM oder ähnliche Spielwiesen, die nicht wie die StorageVM 24/7 am laufen sein werden, können dann auf dem ESXi einfach eingerichtet werden, sind performant dank SSD und können mit an den Speicher eingebunden werden.

Ich hoffe das wir jetzt nicht aneinander vorbei geredet haben. Meinst du das ist ne sinnvolle Lösung oder wie sähe dein Vorschlag dazu aus?
 
Zuletzt bearbeitet:
Ich Versuch auch noch einmal eine grundlegende Idee klarzustellen. Was gea meint, ist folgendes:

Du hast am Ende zwei grundlegende "Speicherplätze" im ESXi.

Nr. 1: wird "nativ" von ESXi verwaltet und dort liegt zum einen ESXi selbst und zum zweiten der "OS-Teil" der Storage VM (vergleichbar mit Laufwerk C: in der klassischen Windows-Welt). Sonst NIX.

Nr. 2: ist ein Speicherplatz, den die Storage VM ESXi "zurück" gibt, der also primär von der Storage VM verwaltet wird und ESXi ist nur "Gast" dort. Das erreicht man, indem die Storage VM auf den von ihr verwalteten Platten (oder SATA- bzw. PCIe-SSDs) ein NFS-Share freigibt, was sich dann über das "Host-interne virtuelle Netz" wieder bei ESXi als "Netzwerkspeicher" einbinden und dank der ESXi "hauseigenen" Funktionalität dazu von ESXi wie ein lokaler Speicher nutzen lässt. Die Technik dient eigentlich dazu, Storage auf anderen physischen Systemen (Stichwort SAN) zu nutzen, wie es im Datacenter übliche Praxis ist, da dort eben Funktionalitäten verfügbar sind, deren "Einbau" in ein und den gleichen Host einen Hypervisor überfrachten würden.

Wir haben also hier eben fast "SAN-Class" Funktionalität in einem "all in one" auf nur einem Blech und müssen dafür nur die Kröte schlucken, dass a) wir diese tolle Funktionalität eben nicht auch für die Storage VM selbst haben können und b) wir z.B. nach einem Reboot des Hypervisors die anderen VMs erst starten können, wenn die Storage VM wieder läuft (und damit von dieser bereitgestellter Speicherplatz für alle anderen VMs überhaupt wieder erst für ESXi zur Verfügung steht).

Aber: die Storage VM ist im Falle des Falles recht simpel wieder hergestellt oder ganz neu aufgesetzt, jedenfalls wenn man die Funktion dieser VM eben auf reines Storage beschränkt. Alles andere liegt ja schön sicher auf den anderen Platten (SSDs) mit allen Vorzügen, die ZFS und Solarish mit sich bringen. Auch braucht die kaum Platz (ESXI und so eine VM brauchen zusammen nicht mehr als 32 GB) und schnell muss der Speicher Nr 1 dafür auch nicht wirklich sein. Willst Du auf Nummer sicher gehen, nimmste halt auch für Storage Nr. 1 noch ein Raid1 aus kleinen besseren SSDs (2x120GB z.B.).

Daher kommen also die ganzen Anmerkungen, dass eine große (einzelne) SSD keinen Sinn macht, weil alle davon ausgehen, dass alles andere als ESXi und die Storage VM eben auf Datenträgern liegt, die von der Storage VM gemanaged werden (Speicherplatz Nr. 2), die also schlicht und ergreifend am extra dafür durchgereichten Controller hängen mit einer entsprechend ausfallsicheren Raid-Konfiguration (mirror bzw. Z1-3 oder lustige Kombinationen davon).

Dann braucht es auch keine "lokalen 20GB" für VMs mehr irgendwo anders - den Sinn/Gedanken dahinter habe ich ehrlich gesagt überhaupt nicht verstanden.

Und noch einmal: Wichtig an der ganzen Idee ist, dass die Storage VM als konzeptionell "gefährdetste" VM möglichst minimalistisch konzipiert ist: Beschränkt auf Storage Funktionen, die eben bei Solarish in sensationeller Form ohne große Konfiguration von Haus an Bord sind (mit napp-it als de facto GUI als einziges Addon). Geht da was schief, ist es auch im Supergau-Szenario flottt wieder neu installiert - zur Not auf ganz anderem Metall und sobald ESXi mit der Storage VM wieder läuft, laufen quasi sofort auch alle anderen VMs wieder.
 
Zuletzt bearbeitet:
hoyohayo schrieb:
Was genau meinst du mit

?
Zum Vergrößern anklicken....

ESXi wird meist im Enterprise Umfeld eingesetzt. Da nutzt man einen zentrales SAN Storagepool z.B. per NFS als Storage für VMs und deren virtuelle Platten. Speicher wird als Pool bereitgestellt und per Quotas und Reservierung verwaltet, nennt sich Speichervirtualisierung. Lokale Platten in ESXi sind ohne Schreib/Lese Cache, daher immer langsam, haben nur sehr eingeschränkte Kurzzeit-Snapshot Optionen und bieten keinen Komfort was Copy/Move/Clone/Backup oder Versionierung angeht und sind was Sicherheit angeht modernen Dateisystemen wie ZFS himmelweit unterlegen. Einzelne lokale Platten je einer VM zuzuweisen ist schlicht ein NoGo.

Die Storage VM dient nun genau dazu, genauso zu arbeiten wie mit einem SAN Storage. Dieses ist hier aber kein separater Server sondern wird von ESXi selbst als VM bereitgestellt. Funktional ist das wie ein VM Server und ein getrenntes SAN/NAS.
 
Zuletzt bearbeitet:
gea schrieb:
Die Storage VM dient nun genau dazu, genauso zu arbeiten wie mit einem SAN Storage. Dieses ist hier aber kein separater Server sondern wird von ESXi selbst als VM bereitgestellt. Funktional ist das wie ein VM Server und ein getrenntes SAN/NAS.
Zum Vergrößern anklicken....

Ahaaaa! Das hatte ich nicht verstanden. Bei mir war immer der Gedanke, dass es am sinnvollsten ist jede VM in einer Sandbox zu haben, da Ausfallsicherheit nicht unbedingt zu 100% nötig ist bei mir. Und ich war bis jetzt auch immer davon ausgegangen, das ESXi auf nen bootbaren USB Stick (siehe HP G8) installiert werden sollte, oder aber eben auf eine SSD, damit das ganze schnell angebunden ist.

Was sagen denn die HDDs zu einer dann doch relativ hohen R/W Rate, wenn ich den Storage an den ESXi weitergebe?

Das heißt, ein Setup sähe dann folgendermaßen aus:

Ich habe auf SATA Platz 1&2 (Ich nehme jetzt einfach mal die Bootreihenfolge) 2 relativ kleine SSDs in einem RAID1 laufen (oder wenn es mir mit der Ausfallsicherheit nicht so wichtig ist und ich kein Problem mit Datenverlust habe hier sogar nur eine SSD). Auf diesen SSDs wird zuerst der ESXi geladen. Im ESXi setze ich dann eine VM auf, die von mir aus zB napp-it als OS laufen hat. Im ESXi sage ich in den Einstellungen, dass diese VM die HDDs auf SATA Platz 3,4,5,6 als Speicher zugewiesen bekommt (also alle HDDs die am Controller LSI hängen und den Controller durchreiche an die VM mit napp-it und in der VM dann den Storage konfiguriere).
Dann kann ich den eingerichteten Speicher per NFS oder iSCSI im ESXi einbinden und finden, solange die VM am laufen ist.
Jetzt kann VM Nr.2 aufgesetzt werden (angenommen Ubuntu). Diese wird im ESXi aufgesetzt, bekommt als Speicherplatz allerdings den eingebundenen iSCSI Speicher aus der StorageVM zugewiesen.
Soweit habe ich euch richtig verstanden oder?

Wenn die VMs dann bei Bedarf ein und ausgeschaltet werden (alle bis auf die StorageVM natürlich), erzeugt das doch relativ hohe R/W Raten auf den HDDs oder? Und wäre es hierbei nicht schneller, SSDs zu nutzen, damit die VMs schneller verfügbar sind?

Also könnte man dann quasi zwei Pools einrichten (ähnlich dem Partitionieren des Windowssystems?), sodass an SATA3&4 des LSI Controller 2 SSDs hängen, die als ein performanter Speicher für die VMs dienen und hohe R/W Raten vertragen und an SATA 5&6 HDDs hängen, die dann für Storage der restlichen Dateien dienen?

Oder ist die Idee aus dem Grund quatsch, dass das Dateisystem ZFS sowieso die höchste Geschwindigkeit aus einem Pool (egal ob HDDs, SSDs oder Kombination der beiden) rausholt und dabei die R/W Last gleichmäßig verteilt?
 
hoyohayo schrieb:
Ahaaaa! Das hatte ich nicht verstanden. Bei mir war immer der Gedanke, dass es am sinnvollsten ist jede VM in einer Sandbox zu haben, da Ausfallsicherheit nicht unbedingt zu 100% nötig ist bei mir. Und ich war bis jetzt auch immer davon ausgegangen, das ESXi auf nen bootbaren USB Stick (siehe HP G8) installiert werden sollte, oder aber eben auf eine SSD, damit das ganze schnell angebunden ist.

Was sagen denn die HDDs zu einer dann doch relativ hohen R/W Rate, wenn ich den Storage an den ESXi weitergebe?

Das heißt, ein Setup sähe dann folgendermaßen aus:

Ich habe auf SATA Platz 1&2 (Ich nehme jetzt einfach mal die Bootreihenfolge) 2 relativ kleine SSDs in einem RAID1 laufen (oder wenn es mir mit der Ausfallsicherheit nicht so wichtig ist und ich kein Problem mit Datenverlust habe hier sogar nur eine SSD). Auf diesen SSDs wird zuerst der ESXi geladen. Im ESXi setze ich dann eine VM auf, die von mir aus zB napp-it als OS laufen hat. Im ESXi sage ich in den Einstellungen, dass diese VM die HDDs auf SATA Platz 3,4,5,6 als Speicher zugewiesen bekommt (also alle HDDs die am Controller LSI hängen und den Controller durchreiche an die VM mit napp-it und in der VM dann den Storage konfiguriere).
Dann kann ich den eingerichteten Speicher per NFS oder iSCSI im ESXi einbinden und finden, solange die VM am laufen ist.
Jetzt kann VM Nr.2 aufgesetzt werden (angenommen Ubuntu). Diese wird im ESXi aufgesetzt, bekommt als Speicherplatz allerdings den eingebundenen iSCSI Speicher aus der StorageVM zugewiesen.
Soweit habe ich euch richtig verstanden oder?

Wenn die VMs dann bei Bedarf ein und ausgeschaltet werden (alle bis auf die StorageVM natürlich), erzeugt das doch relativ hohe R/W Raten auf den HDDs oder? Und wäre es hierbei nicht schneller, SSDs zu nutzen, damit die VMs schneller verfügbar sind?

Also könnte man dann quasi zwei Pools einrichten (ähnlich dem Partitionieren des Windowssystems?), sodass an SATA3&4 des LSI Controller 2 SSDs hängen, die als ein performanter Speicher für die VMs dienen und hohe R/W Raten vertragen und an SATA 5&6 HDDs hängen, die dann für Storage der restlichen Dateien dienen?

Oder ist die Idee aus dem Grund quatsch, dass das Dateisystem ZFS sowieso die höchste Geschwindigkeit aus einem Pool (egal ob HDDs, SSDs oder Kombination der beiden) rausholt und dabei die R/W Last gleichmäßig verteilt?
Zum Vergrößern anklicken....

Du hast es schon richtig verstanden, am besten machst du es so:

Eine SSD oder einen USB-Stick, darauf installierst du ESXi. In ESXi erstellst du eine VM (Storage VM, z.B. napp-it) und legst die VM auch auf diese SSD bzw. den USB-Stick ab. Hier ist kein Raid nötig, weil ohnehin keine großen Konfigurationen hier gemacht werden. Außerdem muss ESXi den Controller unterstützen, das ist oft schwierig bei den Mainboard Controllern. Zusätzlich ist das ganze relativ unsicher, wenn bei nem Write ein z.B. Stromausfall war und sich die Daten auf den beiden SSDs unterscheiden.

Dann gibst du den LSI Controller an die VM weiter (PCIe Passthrough) und nun kann die Storage VM alle angeschlossenen Platten verwalten. In der Storage VM erstellst du nen NFS Share und bindest diesen in ESXi ein.

Wenn du jetzt VMs erstellst legst du diese auf den eingebunden NFS Share ab.


Und die Geschichte mit den SSDs hast du bzgl. Geschwindigkeit richtig erkannt. Ich würde auch alle VMs und Daten die oft benötigt werden auf SSDs legen (Mirror in napp-it und diesen bindest du in ESXi ein).

Bzgl. read/write würde ich mir eher bei den SSDs Gedanken machen. So ne HDD verträgt schon recht viel.
 
Zuletzt bearbeitet:
morumbinas schrieb:
Mirror in napp-it und diesen bindest du in ESXi ein
Zum Vergrößern anklicken....

Das ist dann wie eine eigene Partition oder wie habe ich mir den Mirror gerade vorzustellen? (Sorry, keine Erfahrung mit napp-it und noch relativ neu im Server Bereich, daher die vielen Begrifflichkeitsschwierigkeiten)

Dann würde ein Hardware Setup also folgender Maßen aussehen:


So kann ich dann den Storage im napp-it verwalten und mir die zusätzlichen VMs auf die SSD legen und falls diese Speicher benötigen kann man hier die HDDs einbinden.

Sind die Überlegungen soweit richtig?

Reichen denn für ein ZFS Storage 32GB RAM? Bzw habe ich ja keine vollen 32GB wenn ich noch weiter VMs anbinden will. Da würden wahrscheinlich nur 16GB für die napp-it VM anfallen und die restlichen 16GB für die weiteren VMs genutzt werden.

Was die Unterstützung des ESXi für den Controller angeht... Da bereitet mir die VMware Compatibility Guide Seite doch einige Probleme. Hier ist LSI gar nicht als Partner gelistet und suchen nach dem LSI3008 lässt sich auch nicht... Heißt das der ist inkompatibel?
 
Zuletzt bearbeitet:
Der LSI 2008 und 2308, habe ich selber in Benutzung, läuft out-of-the-box mit ESXI und auch auf einigermaßen aktuellen FreeBSD oder Solarish. 3008 hab ich noch keine Erfahrung.
Wenn Du den Controller vom ESXI in eine VM durchreichst, ists eh wurscht ob ESXI den ansprechen kann; er wird für ESXI dann ausser in der Passthrough-Einstellung quasi unsichtbar.

Bzgl. M.2-Slot: Gerade bei den X11-Supermicro eher nicht so wichtig, da es von SM eine günstige Risercard mit 2*M.2 für einen PCIe 16x/8x-Slot gibt; Du kannst damit 2 NVMEs betreiben, an eine ZFS-Storage-VM durchreichen und dort als Highperformance Mirror-Pool betreiben. => D.h. lieber einen vollwertigen 4x/8x/16x PCIe-Slot mehr und dafür keinen M.2 Steckplatz nehmen, wenn wie bei Micro-ATX der Platz knapp ist. Dafür den HBA direkt drauf.

D.h. auch ein nackertes X11 (X11SSM-F) ohne HBA und ohne 10Gbit kann interessant sein. Das X11SSH-CTF hat den Charme, das mehr oder weniger alles wichtige gleich drauf ist und dafür sehr günstig ist. Daher wäre es meine Wahl für einen kleinen ESXI mit Micro-ATX. Dafür hat es halt nur noch einen 8x PCI und einen 2x. D.h. nen 2. SAS-Controller oder eben obige 2* M.2 Risercard geht noch rein und dann ist noch ein kleiner Steckplatz für ne NIC oder sonstiges Interface. Mehr geht auf der 115x-Plattform eh nicht mangels genug PCIe-Lanes. Für mehr ist dann Sockel 2011-3 gefragt.

Bzgl. ZFS: ich hab als Einzelnutzer derzeit 12GB Ram der Storage-VM zugewiesen, mit 8GB gings aber auch schon gut. (Durch Haswell kann ich eh nur 32GB maximal, mit aktuellen CPUs geht auf den X11-Boards ja 64GB).
Der Rest dann für VMs (eine Windows 64bit -VM bekommt bei mir z.B. 4GB Ram).
 
Zuletzt bearbeitet:
War mir nicht bewusst, dass es so ne Riser Karte gibt. Ich bin allerdings auf der Suche danach ins Leere gelaufen. Selbst auf der Suche auf der SM Seite (Supermicro Riser Karten) konnte ich mit dem Filter nach M2 Slots nicht fündig werden.

Das von dir vorgeschlagene X11SSH-CTF ist mir leider ein wenig zu teuer und ich würde auch sagen, dass ich die 10Gbit nicht brauche. Klar hier ist der M.2 slot direkt und auch der SAS Controller vorhanden. Aber man kann doch auf dem von mir vorgeschlagenen X11SSL-CF ebenfalls die Riser Karte aufbauen oder?
 
hoyohayo schrieb:
Was die Unterstützung des ESXi für den Controller angeht... Da bereitet mir die VMware Compatibility Guide Seite doch einige Probleme. Hier ist LSI gar nicht als Partner gelistet und suchen nach dem LSI3008 lässt sich auch nicht... Heißt das der ist inkompatibel?
Zum Vergrößern anklicken....

Ich habe das X10SRH-CLN4F im Einsatz, mit dem gleichen Controller. Läuft unter ESXI 6.5 mit IT Firmware einwandfrei.


PS: Was ich noch nicht verstanden habe, ist, warum du auf M.2 für das OS und die napp-it VM gehen möchtest? Beides läuft nach dem Start eh weitestgehend im RAM, meine ich zu glaubenwissen :d. Reicht da nicht eine einfache SSD (64GB oder so)?

Das, was Performance benötigt, ist am Ende das Storage an sich. Und das liefe ja eh über den an die Storage-VM weiter gereichten LSI3008 mit seinen x Ports. Daran einen Pool aus SSD(s) für VMs (per NFS als ESXI Datastore) und einen aus den von dir genannten HDs für Data-Storage.

Bei mir sieht es so aus:
ESXI/napp-it auf Samsung EVO SATA SSD am Standard SATA port auf dem Mainboard.
LSI 3008 an napp-it VM durchgereicht.
2 x SSDs als mirror für VMS und 2x 2 HDs als mirror (WD 6TB Red) als Data-Pool, alle an den Ports des LSI 3008.
 
Zuletzt bearbeitet:
hoyohayo schrieb:
Das von dir vorgeschlagene X11SSH-CTF ist mir leider ein wenig zu teuer und ich würde auch sagen, dass ich die 10Gbit nicht brauche.
Zum Vergrößern anklicken....

was hindert dich dran, ein "einfaches Board" wie Intel Xeon mit Hersteller: Fujitsu, Sockel: Sockel 1151 Preisvergleich Geizhals Deutschland mit (je nach Board passender CPU - z.B. das D3417-B2 + Intel Pentium G4560 (für die CPU exact nur dieses MB!) zu nehmen , eine M2 SSD für die VMs rein (ESXi auf USB oder die M2) und die internen 6 Sata durchzureichen per manuellem Whitelisting (ähnlich dem hier: USB thumb drive datastore + built in Intel Lynx Point AHCI Controller + VT-d = successful AIO | ServeTheHome and ServeThe.Biz Forums - bitte nicht 1:1 kopieren )

Pentium G4560 = 5014 Passmark
Intel Xeon 1230v5 = 9678 Passmark (bei 5 fachen preis)

günstiger kommste erstmal nicht ausbaufähiger und aktueller und sparsamer hin mit ECC :)

aka zusammen: home SV Preisvergleich Geizhals Deutschland - das Netzteil wurde (obwohl massiv überdimensioniert) bewußt gewählt wegen Garantie und Effizienz unter 20W-50W (kannst aber auch günstigere nehmen)

sollte dir das später nicht taugen, dann kannste immernoch z.B. nen AVango/LSI 2008 reinstecken (kosten nicht viel als DELL OEM Karten , meist um die 50€ auf Ebay), die CPU aufrüsten, mehr Ram reinstecken, 10GBit nachrüsten etc


mit proxmox entfällt das Ganze, denn du kannst ZFS direkt im OS nutzen
 
Zuletzt bearbeitet:
hoyohayo schrieb:
Danke für das Update zu Proxmox und Begrifflichkeitsklärung. Ich hatte mir auch mal Microsofts Hyper-v angeguckt, da werd ich noch einige Nachforschungen betreiben um rauszufinden ob zb XPEnology drauf läuft. Allerdings sollte MS ja auf Hardwareunterstützung der Intel Plattformen geachtet haben oder (mal abgesehen von Windows 7 Kaby-Lake)?
Zum Vergrößern anklicken....

Nutz am besten ESXI für Xpenology. Damit läuft es einfach am besten. Wenn du Windows als Host installierst, nutze auf keinen fall Hyper-V, sondern VMware Player noch besser wer VMware Workstation. :)
 
pumuckel schrieb:
was hindert dich dran, ein "einfaches Board" z.B. das D3417-B2 + Intel Pentium G4560 zu nehmen, eine M2 SSD vor die VMs rein (ESXi auf USB oder die M2) und die internen 6 Sata durchzureichen per manuellem Whitelisting
Zum Vergrößern anklicken....

Ich glaube hier hast du tatsächlich Recht und bringst das ganze mal wieder auf den Boden der Tatsachen. Ich bin den Ratschlägen erstmal soweit wie möglich gefolgt und dann kam hier und da immer wieder etwas dazu und wuchs mir doch etwas über den Kopf für den Einstieg. Das ganze braucht glaub ich etwas Einarbeitungszeit und wenn ich doch etwas Neues brauche, kann man es mit der Zeit nachrüsten.

An sich hindert mich also nichts daran; das einzige was mich an dieser Option stören würde, wäre das nicht vorhandene IPMI oder eine ähnliche Möglichkeit zur Fernsteuerung (Ich sehe auch kein Intel AMT?). Ansonsten ist dieses Board von den Basisdaten her eigentlich genau das was ich gesucht habe.
Wobei es wahrscheinlich nicht schlecht wäre dort zeitnah eine NIC erweiterung einzubauen, da nur ein Ethernet-port doch etwas begrenzend ist oder?

Was genau ist das manuelle Whitelisting? Ist damit gemeint, den AHCI von Intel im ESXi sichtbar zu machen und dann durchzureichen?


Xen12 schrieb:
Nutz am besten ESXI für Xpenology
Zum Vergrößern anklicken....
Danke ;) Ich glaub das werde ich auch tun.
Mich noch in Napp-it einzuarbeiten und dann alles aufeinmal haben zu wollen, ist vllt doch etwas viel. Ich denke da werde ich Schritt für Schritt gehen und hab ja damit erstmal eine Basis, auf der ich auch mit Napp-it experimentieren kann.

Dann wären wir wahrscheinlich wieder bei meinem Vorschlag von Seite 1, mit ein paar kleinen Änderungen und Erweiterungen:

 
"Was genau ist das manuelle Whitelisting?"

geschieht in der "/etc/vmware/passthru.map" (kann man so googlen : /etc/vmware/passthru.map - Google-Suche )

ESXi (im gegensatz zu z.B. Proxmox) "verschweigt" die Passthrue Fähigkeit von manchen Onboard Komponenten (oder anderen, welche nicht als "Servergrade" gelten) aka Sie lassen diese in der schönen bunten GUI nicht auftauchen
das kann man jedoch durch editieren der Files nachhelfen (aka esxi sagen: es geht doch :) )

darum z.B. bevorzuge ich proxmox, die zwar gar keine GUI speziell für Passthrue haben (aber für den Rest einen super GUI), aber auch keine künstlichen Steine in den Weg legen (Ausnahme: wenn man per EvalExperience - 170-200€/Jahr - zusätzlich zu VSphere noch VMWare WS auf dem Rechner betreibt - dann macht esxi sinn)

Pci passthrough - Proxmox VE

kostet ne Stunde (evtl weniger oder mehr je nach Wissensstand) Einlesezeit und etwas Zeit bei Einrichtung, aber lüppt

wobei du ZFS auch direkt auf Proxmox nutzen kannst ohne Passthrou

Bild: 2xvsd6.jpg - abload.de


Was aber erstmal für die reine HW "Whane Schlegel" (!sic) ist :)

Alf ist Wayne Schlegel - YouTube

zu vPro oder iKVM/IMPI ... das setzt du bei 19" Geräten ohne Monitor ein, welche fix verbaut sind ... ein HS, den man fix mal an einen Moni und Tast/Maus klemmen kann interessiert das wenig
die OS verwaltung geht eh über HTML wenn einmal installiert (inkl neustart/reboot)

Sinn macht sowas z.B. bei backup Servern, die nur 1 mal/Woche gestartet werden (und man zu faul ist in den keller zu laufen) --- bei dauerläufern recht egal (oder haste ein Home-NAS schonmal mit KVM gesehen ?)
überwachen tut man die eh per html oder Lösungen wie Nagios, NetData etc

wenn du aber mal mehr als 4-6 Server hast, dann wirds sehr nice
 
Zuletzt bearbeitet:
Danke für die Tipps zu Proxmox. Ich versuche ja meist alles vorher schon zu testen auf dem jetzigen Rechner. Mit Proxmox als VM und stoße ich zwar noch auf ein paar Probleme bei der Einrichtung mit XPEnology, aber das ist hier nicht mehr im Thread zu besprechen. Da werd ich noch ein wenig probieren. Oder mich dann wenn es soweit ist, mit dem Passthrough des ESXi beschäftigen, auch hier danke für den Tipp! :)

Edit: hat sich erledigt, da waren die Probleme auch schon Geschichte. Danke nochmal für den Tipp! Dann wird es am einfachsten sein, wenn ich das ZFS mit Proxmox aufsetze, alles hier verwalte und dann die VMs von hier aus steuere.

Ich denke auch dass es dem ganzen keinen Abbruch beschert wenn kein AMT, ILO, IPMI oder ähnliches vorhanden ist. Eigentlich sollte die Einrichtung ja einmalig geschehen und dann laufen.

Ist ansonsten an der Hardwarekonfiguration noch etwas verbesserungswürdig, was dringend notwendig ist?
 
Anmelden, um zu antworten.

Ähnliche Themen

F
[Kaufberatung] Server in Richtung stromsparend umbauen.
2
Antworten
34
Aufrufe
2K
pwnbert
pwnbert
L
systemwechsel weg vom HP ProLiant DL380p Gen8
Antworten
4
Aufrufe
486
Haldi
Haldi
X
Ersatz für Homeassistant, GooglePhotos und NAS - Passt mein Software-Setup-Idee?
Antworten
8
Aufrufe
554
VirtuGuy
V
H
Ablösung verbastelter Homeserver
2
Antworten
31
Aufrufe
3K
Luckysh0t
Luckysh0t
M
TrueNAS Scale Storage Planung, Homeserver die 100te
Antworten
7
Aufrufe
2K
pwnbert
pwnbert
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