[Kaufberatung] Homeserver mit Virtualisierung über ESXi

KarlN4p

Neuling
Thread Starter
Mitglied seit
03.11.2015
Beiträge
7
Hallo liebe Community,

kurz zu meiner Person. Ich bin studierter ITler, jedoch nicht in diesem Bereich tätig (Bei der BW). Ich habe durchaus fundiertes Wissen im Bereich Informationstechnik und beschäftige mich auch mit der Materie. Jedoch ist mein Steckenpferd die hardwarenahe Programmierung bzw. auf der anderen Seite die JavaScript-Programmierung. Nun bin ich seit einigen Tagen im Forum unterwegs und lese mir einige Kaufempfehlungen anderer Nutzer durch. Jedoch umso mehr ich lese, umso weniger weiß ich mittlerweile was ich nehmen soll.

Was will ich denn überhaupt machen:
Ich würde gerne mehrere Anwendungsbereiche auf einem Server mit ESXi virtualisieren.
  1. Ich möchte meine Geräte (Laptop, PC) gerne zentral sichern. Hier hatte ich ursprünglich an einen Windows Server gedacht, da meine Rechner auch mit Windows arbeiten. In vielleicht nicht allzu ferner Zukunft mit Windows 10. Dabei habe ich auch an eine Domäne gedacht. Mittlerweile bin ich von dem Gedanken (Windows Server 2012 R2) nicht mehr so überzeugt. Ich habe zwar eine Serverlizenz aber mehr auch nicht. Der Gedanke dahinter war es, dass, wenn mal ein Client nicht mehr von Seiten des BS läuft, ich mittels des Servers das Gerät neu bedampfen kann.
  2. Ich würde mir gerne eine eigene Cloud einrichten. Darüber habe ich noch nicht allzu viel nachgelesen. Entschuldigt meine Unwissenheit. Ich würde dabei gerne eine eigene Netzwerkschnittstelle und einen eigenen Festplattenspeicher (z.B.500 GB) dafür separieren. Sprich, falls mal ein unbefugter Zugriff auf diese Cloud stattfindet, nicht gleich das ganze System offen liegt. Sondern nur das Betriebssystem der Cloud und die Daten die darin liegen.
  3. Zentraler Datenspeicher im Netzwerk. Ich habe noch vier 1,5TB Festplatten aus einem alten DAS, die ich gerne verwenden würde. Vielleicht mit der Möglichkeit, dass ganze später noch zu erweitern.
  4. Mittels Linux einen dedizierten Spieleserver für verschiedene Steam-Spiele betreiben.
  5. Mal den eine oder anderen Linux-Server antesten.

Das Budget liegt bei ca. 1000€.
Hatte länger mit dem HP Microserver Gen8 geliebäugelt, bin aber mittlerweile davon ab, da er ja limitiert ist, was die Festplattenanzahl angeht.

Ich hoffe ich konnte meinen Eindruck von dem gesuchten vermitteln und würde mich über ein paar Antworten freuen.

MfG
Karl
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
KarlN4p: du legst als Nachteil dar das die Anzahl der Festplatten limitiert ist. Du kannst mit der Backplane 4 3.5" Festplatten anschliessen, in den ODD Schacht passt 1 SSD. Brauchst du wirklich so viele Festplatten?

Ansonsten kannst du mit der Maschine "schön" alles mögliche von Storage über Owncloud etc. virtualisieren.
Falls du mehr Leistung brauchst wäre evtl. der ML310e oder Nachfolger interessant. Oder du rüstest eine größere CPU nach. Der Microserver kann bis zu 16 GB Ram, der ML310e bis zu 32 GB (evtl. auch mehr bei 16 GB Modulen)
 
Zuletzt bearbeitet:
Hi Opticum,

mein Gedanke war es, die vier Festplatten in einem Raid zu betreiben und die ESXi-Daten sowie Cloud-Daten auf zwei weiteren Festplatten abzulegen. Somit würde mir ein Platz fehlen.
Den ML310e werde ich mir mal genauer anschauen.
Das Grundsätzliche Trennen von der Cloud vom Rest ist aber so wie ich mir das gedacht habe möglich, oder?
 
KarlN4p: schau dir mal einen integrierten Storage a la Napp-It an. Kann ich nur wärmstens empfehlen. Die VMs liegen dann alle zusammen auf dem ZFS Storage. Dort kannst du auch die VM für die Cloud ablegen, die ist dann ein isolierter VMDK Container.
 
@Opticum
Erst einmal Danke für deine Unterstützung.
Aber ich glaub ich hab das nicht richtig verstanden. Meinst du, ich soll auf dem RAID die VMs speichern/ablegen? Nicht auf der Festplatte auf der der Hypervisor liegt? Dann müsste ich ja erst den virtuellen Server mit dem ZFS Dateisystem laden und dann die anderen Server nachträglich? Ich glaub da hab ich was nicht kapiert. Sorry, aber das mit der Virtualisierung ist noch Neuland für mich.
 
@Opticum
Erst einmal Danke für deine Unterstützung.
Aber ich glaub ich hab das nicht richtig verstanden. Meinst du, ich soll auf dem RAID die VMs speichern/ablegen? Nicht auf der Festplatte auf der der Hypervisor liegt? Dann müsste ich ja erst den virtuellen Server mit dem ZFS Dateisystem laden und dann die anderen Server nachträglich? Ich glaub da hab ich was nicht kapiert. Sorry, aber das mit der Virtualisierung ist noch Neuland für mich.

Genauso geht das.

Der Grund liegt darin, dass lokales ESXi Storage
- keinen Cache unterstützt - weder RAM noch SSD (daher langsam ist)
- Snaps nur als Kurzzeitoption bietet
- die Anzahl der Snaps begrenzt ist
- keine Prüfsummen bietet
- nicht crashresistent ist (da brauchts CopyOnWrite wie bei ZFS)
- kein Sharing bieter (iSCSI, NFS, SMB)
+ tausend andere SAN Features wie Replikation oder ZFS Features wie
Software Raid ohne Write Hole Probleme

kurzum, es fehlt alles, was modernes Storage ausmacht.
Daher der Ansatz:
- Ein ZFS NAS/SAN als Storage VM (die VM selber liegt auf lokalem Datastore)
die stellt per NFS Storage bereit, auf dem die anderen VMs liegen

Wichtig ist da nur, dass die Storage VM direkten Zugriff auf Controller und Platten hat-
daher brauchts pass-through und den Extra LSI Controller auf dem Mainboard

siehe mein HowTo mit OmniOS (freier Solaris Fork)
http://www.napp-it.org/doc/downloads/napp-in-one.pdf

ps
Das Supermicro X10SL7-F ist perfekt
 
Zuletzt bearbeitet:
OK,

dann versuch ich mal auf der Information aufzusetzen.
Meine Idee jetzt:
- Das ESXi und die Storage VM laufen auf einer kleineren Festplatte (60GB) am SATA 6Gb/s
- Die Storage VM verwendet zwei 250GB Festplatten (am SATA 3Gb/s) im RAID 1 für die weiteren VM
- Eine Virtuelle Maschine erhält den SAS Controller für den eigentlichen NAS, der aus den 4 bzw. 5 1,5TB Festplatten besteht.

Macht das so Sinn? Die VMs auf einem extra Speicher abzulegen? Oder ist das nur eine Verschwendung von Ressourcen? Ich bin irgendwie ein Freund von klarer Trennung der Bereiche.
Ist denn auch die Zuordnung der SATA Controller so sinnig? Ich vermute fast, dass es andersherum sinnvoller ist.
 
Zuletzt bearbeitet:
Nein, funktioniert so nicht.
ESXi + Storage VM mit einer 60 GB Platte an Sata 6G ist ok

Raid-1 an Sata 3G über die Storage VM macht keinen Sinn da die Storage VM keinen direkten Zugriff auf Sata hat.
Das ginge nur über virtuelle Platten oder Raw Disk mapping. (3G und 6G Sata sind nicht getrennt nutzbar, das ist ein PCI-e device)

Also besser auf dem durchgereichten HBA zwei Pools anlegen, einen kleinen, schnellen ZFS Mirror für VMs (ideal wären SSD) und einen größeren für als allgemeiner Storage z.B. als Raid-Z(1-3).
 
ich hätte auch mal eine Verständnisfrage dazu:
Wenn ich in ZFS ein Dataset (auf SSD) mit NFS für Esxi als Datastore-Ablage freigebe, greift dann Esxi direkt darauf zu oder legt Esxi darauf nochmal sein eigenes Filesystem an? Falls nein, dann würde ich, wenn ich zB Windows als VM drauf habe, in ZFS/OmniOS unter diesem Dataset die "echte" Windows-Ordnerstruktur sehen und könnte darauf zugreifen können? Sprich die VM's würden nativ auf ZFS liegen und man hat nicht Filesystem (VMFS) über Filesystem (ZFS) etc...

Edit: Ich glaub ich hatte da ein Denkfehler oder? Denn jedes Gast-OS wie zB windows braucht ja trotzdem sein eigenes Filesystem (NTFS), wodurch dann ja doch oberhalb von ZFS NTFS läuft und somit nicht driekt aus OmniOS auf die Windows Ordnerstruktur zugeriffen werden kann.
Man würde lediglich das VMFS sparen..? Richtig???
 
Zuletzt bearbeitet:
Wenn man ein ZFS Dateisystem per NFS oder SMB freigibt, kann man darauf Dateien ablegen.
ESXi legt dann für jede VM einen Ordner mit Konfigurationsdateien und virtuellen Platten in Form von (thin provisioned) Dateien ab. Die Basis ist also ZFS mit allen Sicherheits und Performancefeatures.

Die ESXi Gäste formatieren diese virtuellen Platten dann mit ihrem Dateisystem.
Mit ZFS snaps kann man die aber versionieren.

Auf die virtuellen Platten kann nur mit ESXi (oder speziellen Tools) zugegriffen werden.
Aus Sicht von OmniOS ist eine virtuelle ESXi Platte nur eine .vdmk Datei.
 
Zuletzt bearbeitet:
@gea
Ok, ich glaub jetzt hab ichs verstanden.
Zum Vorgehen:
- Das ESXi und die Storage VM laufen auf einer kleineren Festplatte (60GB) am SATA 6Gb/s
- Den SAS Controller gebe ich an die Storage VM.
Nun kann ich ja in der Storage VM zwei Speicherbereich erzeugen.
Der erste aus zwei 250GB Festplatten für die weiteren VMs
und einen zweiten bestehend aus den 4 x 1,5TB Festplatten als NFS.
Dann kann ich mir ja eine VM, welche ich ja als NFS einrichten wollte sparen, und das ganze über die Storage VM machen.

Ich hoffe, dass ich es jetzt verstanden habe
 
Wenn man ein ZFS Dateisystem per NFS oder SMB freigibt, kann man darauf Dateien ablegen.
ESXi legt dann für jede VM einen Ordner mit Konfigurationsdateien und virtuellen Platten in Form von (thin provisioned) Dateien ab. Die Basis ist also ZFS mit allen Sicherheits und Performancefeatures.

Die ESXi Gäste formatieren diese virtuellen Platten dann mit ihrem Dateisystem.
Mit ZFS snaps kann man die aber versionieren.

Auf die virtuellen Platten kann nur mit ESXi (oder speziellen Tools) zugegriffen werden.
Aus Sicht von OmniOS ist eine virtuelle ESXi Platte nur eine .vdmk Datei.

Ok, also ist NFS quasi doch "nur" eine reine Freigabe (ähnlich wie smb) und ersetzt kein Filesystem. Esxi greift darauf einfach via Netzwerk zu und erstellt dann vmdk's.
ich hatte gehofft man kann dadurch ein Filesystem "einsparen", da die Daten jetzt ja immer durch 3 Filesysteme müssen: ZFS -> VMFS -> NTFS/Btfs (Guest OS)
 
Zuletzt bearbeitet:
NFS ist wie SMB ein Filesharing Protokoll, aber mit sehr wenig Overhead und daher sehr schnell.

VMFS -> NTFS etc braucht man bei Virtualisierung immer. VMFS ist aber weder besonders sicher
noch besonders schnell und man kann nur mit speziellen Backup-programmen oder langsam per SSH
darauf zugreifen. Auch kann es nur einzelne Kurzzeitsnaps. Daher legt man professionell ein SAN oder
NAS z.B. mit ZFS und NFS shared Storage (oder FC/ iSCSI) darunter.

Damit ist NFS/ZFS -> VMFS -> NTFS schneller als nur VMFS -> NTFS
(genügend RAM als ZFS Cache vorrausgesetzt)
 
Hi gea
ich muss dich leider noch einmal belästige
@gea
Ok, ich glaub jetzt hab ichs verstanden.
Zum Vorgehen:
- Das ESXi und die Storage VM laufen auf einer kleineren Festplatte (60GB) am SATA 6Gb/s
- Den SAS Controller gebe ich an die Storage VM.
Nun kann ich ja in der Storage VM zwei Speicherbereich erzeugen.
Der erste aus zwei 250GB Festplatten für die weiteren VMs
und einen zweiten bestehend aus den 4 x 1,5TB Festplatten als NFS.
Dann kann ich mir ja eine VM, welche ich ja als NFS einrichten wollte sparen, und das ganze über die Storage VM machen.

Ich hoffe, dass ich es jetzt verstanden habe
Kann ich das so machen? Wenn ja, kann ich endlich loslegen :)
 
Alle Wege führen nach Rom..

An dem SAS Controller lassen sich bis zu 8 Platten anschliessen.
Die Platten kann man in einem oder mehreren Pools verwalten.

Oft macht man zwei Pools mit All-In-One.
Einen High Performance Pool, z.B. einen SSD Mirror für VMs
auf dem ESXi per NFS seine VMs ablegt -

und einen langsameren Pool als Raid-Z(1-3) aus normalen Platten
für Backup oder normale Fileserver Sachen.

Man könnte aber auch nur einen Pool haben und ein Dateisystem für
ESXi mit NFS/SMB bereitstellen und ein weiteres Dateisystem mit SMB
für den Rest..
 
Das X10SL7-F hab ich auch, wirklich nettes Board für den Preis. Den LSI 2308 auf IT mode geflasht, ESXI 5.5 drauf und den LSI durchgereicht.
Läuft wunderbar. Mit X540 und Intel 750.
Was dabei nicht stabil ging, war die Intel 750 auch noch durchzureichen; Das ging ein paar Minuten bei relativ schlechter Leistung der 750er, dann hats mir den ESXI abgeschossen.
 
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