Bitte den Virtualisierungsaufbau checken (ESXI mit Unraid & Napp-it als Guests)

GammaRAID

Enthusiast
Thread Starter
Mitglied seit
28.11.2012
Beiträge
395
Moin Moin,

ich habe mir in der Theorie folgendes Konstrukt überlegt und brauche von den Virtualisierungsspezis hier einen Check, ob das a) sinnvoll und b) möglich ist.

Als Basis sollte ESXI dienen.

Storage:
- UnRaid virtualisiert: Der Grund für UnRaid ist, dass ein Großteil der Daten Mediafiles sind, die teilweise Monate nicht benötigt werden. Bei UnRaid dreht immer nur die eine Platte, von der die Dateien gelesen werden. Das spart Strom ;) Die Geschwindigkeitseinbußen beim Schreiben sind für mich eher Nebensache und zudem sind die Dateien noch als Original BR vorhanden.
- Napp-it ZFS: Auf diesem Storage soll der Cloudserver und die Backups der Laptops etc. laufen.

Hinzu kommen verschiedene BS, auf denen dann die von mir benötigten Services laufen.

Nun meine Fragen dazu:

a) ist Unraid als ESXI Guest sinnvoll und praktikabel?
b) ist es möglich sowohl Unraid, als auch Napp-it laufen zu lassen? Kann ich also die einzelnen HDDs diesen beiden Maschinen zuweisen?
c) hat jemand einen besseren Vorschlag, wie ich die Storagefrage beantworten kann? Mir ist wichtig, dass die Mediadaten auf Spindownplatten liegen die nur einzeln angesprochen werden und dennoch hätte ich gerne eine gewisse Redundanz.

Vielen Dank für eure Hilfe ;)
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hi,

wenn sich an dem Status nichts geändert hat (bitte Quelle) ist Unraid virutalisiert nicht supportet. Heißt du gibts Geld für die Lizenz aus, bekommst aber kein Support wenn was sein sollte. Daher solltest du dir das zwei mal überlegen. Evtl. ist das bei Snapraid oder so möglich (noch nie angeschaut).

Du willst die HDDs einzeln per RDM durchreichen? Geht zwar, soll aber auch häufig Probleme machen, wenn die Hardware die drunter liegt (und dazu hast du nix geschrieben) das anständig verarbeitet.

Wie viele Disks sollen denn dann mit ZFS verwaltet werden? Wenn da VMs drauf kommen gehe ich mal von SSDs aus. Backups auf SSDs zu legen, kann man zwar machen, finde ICH allerdings total unnötig (für daheim).

Hast du dir mal ausgerechnet wie viel Geld du mit dem Aufwand des Spindown wirklich sparst? Evtl. ist die Anschaffung für die Hardware die du dafür benötigst erst nach 5 - 8 Jahren (Zahlen einfach in den Raum geworfen) amortisiert.
 
Hi Teddy,

Also der Aufbau ist wie folgt:

unraid 8x 10tb mediadaten (von einem M1015)
zfs 3x 4tb cloud, laptopbackup, VM Backup (direkt vom MB)
1x 1tb SSD für die VMs (direkt vom MB)
1x 1tb SSD dediziert für eine spezielle VM (direkt vom MB)

Spindown: 0,8W (Spindown) vs. 5W (idle) pro HDD (8*4,2*24*365)/1000 -> 294,3 kw/h also ca. 80EUR pro Jahr.

Ich hatte leider keine Ahnung, dass Unraid virtualisiert nicht supported wird. Das ist natürlich schade... Vielleicht hat noch jemand Erfahrung damit.

Tante Edit sagt: Snapraid wäre wohl eine alternative, wenn auch nicht so komfortabel.
 
Zuletzt bearbeitet:
Nicht unterstützt muss ja nicht heißen dass es nicht läuft.

Prinzipiell hätte ich eher Sorgen, dass es mit Onboard Sata Probleme gibt. RDM läuft ja nur mit viel Fummelei und Pass-through macht gerne mal Probleme. Auch braucht mal ja einen lokalen Datastore für die Storan VMs.

Viel Problemfreier wäre Sata als Bootoption für ESXi und lokalem Datastore und ein zweiter LSI HBA für die ZFS Platten und SSDs. Darüber wäre dann auch Pass-through einzelner Platten per ESXi 6.7 GUI möglich.
 
Hallo Gea,

also würdest du einfach 2 m1015 nehmen und die HDDs dort dranhängen? Der Aufpreis dafür ist ja recht überschaubar.
Generell wird es ein 1151 SM System mit nem Xeon E3 v6 und 32GB RAM.

Ich habe bisher keine Erfahrung mit Virtualisierung.
Wenn ich das richtig verstanden habe, dann benötige ich für jede VM, die eine HDDs zugewiesen bekommen soll, auch einen kompletten Controller, richtig?
Also wäre es sinnvoll Controller 1 an unraid durchzureichen und Controller 2 an Napp-it. Napp-it stellt dann die 1TB SSD für die eine VM zur Verfügung und auf diesen Share kann die VM dann zugreifen.
Die zweite 1TB SSD, auf der die ganzen VMs liegen sollen, schließe ich direkt ans MoBo an und installiere dort auch ESXI? Oder muss die auch über Napp-it laufen?
 
Geht noch einfacher: du gibst die 1TB SSD für die VMs auch der napp-it VM und die gibt den Speicherplatz mit allen ZFS-goodies an ESXi per NFS zurück.

Da kannste dann auch Unraid drupp packen.

Die andere 1TB SSD für eine Spezial VM wird dann kniffliger, wenn je die Nappit (Solarish) VM und Unraid VM je einen von 2 HBA bekommen sollen; Irgendwo muss ESXi und die Napp-it Solarish VM liegen. Je nachdem was besser realisierbar ist entweder a) beides auf eine kleine SATA-SSD und dann eine 1TB PCIE SSD durchreichen, oder b) beides auf eine kleine PCIE SSD und den SATA-Controller durchreichen. Oder eben 1TB als VMDK auf einer an Napp-it/Unraid gegebenen SSD, die man per NFS an esxi zurückgegeben hat, oder direkt von nappit/unraid an die andere VM über SMB/NFS/iSCSI entsprechend Platz zur Verfügung stellen...

Möglichkeiten gibt es viele, ist eine Frage was in dieser einen VM genau passieren soll, die 1TB SSD-Speicher braucht.
 
Zuletzt bearbeitet:
Ich würde auch eine kleinere SSD für ESXi und die Storage VM(s) nehmen.
Dann die beiden 1 TB SSDs als ZFS Mirror für sonstige VMs nutzen (per NFS Datastore).

Ich würde auch onboard Sata für ESXi und einen zweiten HBA für die Datenplatten nutzen (pass-through oder RDM)

ps
Wenn man aus Performancegründen oder wegen höherer Ansprüche an Datensicherheit Platten physikalisch an eine VM geben möchte, so ist pass-through der Königsweg. Die VM kann dann mit eigenen Treibern direkt auf den Controller und die Platten zugreifen.

Alternativ kann man physical RDM (raw disk mapping) machen. Dadurch wird die Platte zwar durch ESXi und ESXi Treiber angesprochen und per virtuellem Disk Treiber an die VM gereicht. Die formatiert und nutzt die Platte aber wie eine physikalisch angeschlossene Platte. Nachteil ist der zusätzliche Umweg über einen virtuellen Plattentreiber und den ESXi Treiber. Auch hat die VM keine Kontrolle über einen eventuellen Plattencache.
 
Na dann wird es Zeit, dass ich meinen alten Dell Monitor ausm Keller hole und entstaube ;)

Vielen Dank für die Tipps!

Also ich fasse nochmal abschließend zusammen:

1 kleine SSD (120gb) für ESXI, Unraid und Napp-it
1x m1015 passtrough an Unraid (8x 10TB)
1x m1015 passtrough an Napp-it (2x 1TB SSD, 3x 4TB) also noch 3 in Reserve

1 1TB SSD zurück an ESXI für die VMs (mit nem täglichen Snapshot auf das 3x4TB Raid
1 1TB SSD per SMB an die eine VM freigeben

Alle VMs sollen über einen OpenVPN-Client gehen, der OpenVPN Server steht in nem Rechenzentrum. Kann man das auch virtualisieren oder muss ich dafür dann eine physische Maschine/Router vorschalten?
 
Öh... bin da jetzt nicht so der Profi, aber ich würd dafür vermutlich eine kleine Router/OpenVPN-VM bauen. Dürfte die Netzwerk-Topologie etwas verkomplizieren und du musst Dir halt überlegen, ob denn alle, die sich auf dem VPN-Server in dem Rechenzentrum einloggen dürfen 1.) auch 1:1 auf alle deine VMs und 2.) in Dein sonstiges Netz zu Hause dürfen.

Wenn du 2. mit "nein" beantwortest, brauchst Du dann im Zweifel schon 2 (zumindest) logisch getrennte Netze zu Hause mit Firewall/Routing dazwischen.
 
Brauchts denn 2 TB schnellen SSD Storage?

Hintergrund
Bei wichtigeren Daten würde ich neben Disasterbackup immer Echtzeitredundanz, also Raid vorsehen und daher die 2 SSD als Mirror mit 1 TB Kapazität betreiben. Ob da VMs oder sondige Daten drauf liegen ist zunächst egal.
 
@besterino

Da hast du einen guten Punkt gebracht! Server + VMs sollen über OpenVPN + lokales Netzwerk gehen. Alle anderen Geräte, die ich zu Hause habe dürfen entweder gar nicht außerhalb vom lokalen Netzwerk agieren (z.B. Smart-TV) oder haben eigene OpenVPN-Clients (Handy, Laptop) oder sind Gäste, die im normalen Guest-WLAN ohne VPN unterwegs sind.

Als ein sinnvoller Aufbau wäre dann:
Internet->0) Fritzbox 1) Gäste-WLAN, 2)WLAN für eigene Geräte, 3) LAN -> 3.1) VMRouter (hier drüber geht der gesamte LAN-Traffic)
Im Endeffekt wird es einfacher sein einen dedizierten Router anzuschaffen, der sich als OpenVPN Client einloggen kann. Ich mach mich mal auf die Suche.

@Gea
ich brauch ca. 1TB für die VMs, weil die Plex-VM relativ groß werden wird. Mir würde ein tägliches Backup reichen. Wenn ich weitgehende Änderung in einer VM vornehme, dann würde ich im Anschluss direkt einen Snapshop erstellen.
Zudem läuft bei mir dann 1x pro Woche ein Transfer der VM-Backups zu einer Offsite-Location.

Die wichtigen Daten, die zum Großteil auf dem 3x4TB Raid liegen haben ja eine Echtzeitredundanz und zudem eben noch das Backup zur Offsite Location.
Die anderen Daten, die auf der zweiten 1TB-SSD liegen, sind unkritisch und können jederzeit wiederbeschafft werden. Hier benötige ich die SSD eigentlich nur aus Zeitgründen.

Ich habe nur festgestellt, dass es schwierig wird diesen Server zu erweitern. Falls die 8x10TB nicht mehr ausreichen haben die 1151 Supermicro Motherboards keinen dritten PCIe x8 für einen weiteren m1015.
 
Bilder sagen immer mehr als 1000 Worte.

vm-netzrouter.png

Dies wäre z.B. ein einfacher Aufbau - Router am Internet - ggf. ein Switch dahinter, dann in den ESXi - 1 vSwitch (0) als das mit dem LAN verbundenen Switch, daran dann die Router-VM.
ein weiteres vSwitch (1) welches die "LAN-Seite" der Router VM bildet und die VMs beherbergt...
 
Dann helfen zur Not Expander, HBA- oder Plattformwechsel.
 
Sauber @Konfetti! Genau so solls sein ;)

@besterino Ich bau in der Regel so alle 5-7 Jahre einen neuen Server und der alte wird dann mein Backupserver. Daher guck ich vorher wo meine Limitierungen sind.

Generell sollte das so passen. Ich bestell den Kram mal und wenn alles da ist gibt es bestimmt noch 1000 Fragen die aufpoppen, wenn man das 1. mal einen Server mit VMs aufsetzt.

Vielen Dank für eure Hilfe!
 
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