Konzept gesucht für 2x Microserver gen8, Virtualisierung und napp-it

martingo

Experte
Thread Starter
Mitglied seit
17.01.2017
Beiträge
1.300
Hallo zusammen,

ich bin mit meiner aktuellen Serversituation nicht so ganz zufrieden und bin auf der Suche nach einem Neukonzept für die Zukunft.
Aktuell habe ich zwei Microserver Gen8. Auf einem läuft WSE2016 baremetal, der andere ist ungenutzt. Auf WSE werden Storage Spaces verwendet (1x Mirror aus 2x 8TB)

An Hardware ist vorhanden:
2x Microserver Gen8 (1x G1610T, 1x E3-1230v2)
2x 4GB RAM, 1x 8GB RAM
2 SSD Platten (1x 128GB, 1x 256GB)
4x WD Red (2x 8TB, 1x 3TB, 1x 2TB)
diverse 3,5" Desktop Platten
Router mit 2x SFP+

Wünschen würde ich mir:
- Storage Server mit napp-it und ZFS.
- Virtualisierung: ESXi als Level1 und falls möglich on-top Proxmox (falls die Perfomanceeinbußen nicht zu arg)
- schnelle Verbindung zwischen den beiden Servern

Ich habe weder mit napp-it noch ZFS noch ESXi irgendwelche Erfahrungen.

Was ich mir nun überlegt habe:
Einen der beiden Server als dedizierten Storage Server zu nutzen, also z.B. napp-it drauf zu installieren. Eine Frage ist: besser bare-metal oder mit ESXi als Hypervisor?
Den zweiten Server als Applicationserver mit VMs zu nutzen. Bisher habe ich ausschließlich mit Proxmox und Hyper-V virtualisiert. Die Performancevorteile der LXC-Container würde ich gerne mitnehmen, also z.B. ESXi als Basissystem und darauf einen Proxmox. Weitere VMs dann sowohl in ESXi als auch in Proxmox.
Die beiden Server über zwei Mellanox ConnectX-2 zu koppeln. Entweder direkt miteinander oder über den Router.

Als Festspeicher im Storageserver reichen mir vorerst 8TB.

Habt ihr Vorschläge, wie ich das am geschicktesten umsetzen könnte? Auch im Hinblick auf die Besonderheiten im gen8 (Boot nur über USB/microSD, kein separater Zugriff auf SATA5 bei Durchreichen des B120i, kein Platz für zusätzlichen HBA, wenn die SFP+ Karten verbaut werden usw.)
Lege ich die VM-Images besser auf den Storageserver oder auf den Applicationserver? Aus Performancesicht wahrscheinlich besser Applicationserver, aber dann liegen die halt wieder nicht auf ZFS.
Wenn beide Server ESXi virtualisiert wären, wäre es im Falle eine Defekts natürlich leichter, wieder arbeitsfähig zu werden.

Viele Grüße
Martin

Edit: ich muss nicht zwingend beide Microserver verwenden. Wenn es besser ist, alles auf eine Kiste zu konzentrieren, ist das auch gut.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Warum zum Teufel willst du zwei Virtualisierungshosts übereinander installieren?? Warum nicht einfach Proxmox Baremetal und auf dem schwächeren ein FreeNAS oder sowas? Alternativ installiere auf beiden Proxmox und erstelle auf dem schwächeren per Shell ein ZFS. Vorteil: Du kannst beides über eine GUI steuern. Alternativ würde sich auch Ceph oder GlusterFS anbieten.

Problematisch ist auch die unterschiedliche HDD-Größe, die du hast. Ein ZFS mirror würde noch funktionieren.
 
Prinzipiell ist ein leistungsfähiger AiO mit dem G8 schwierig, insbesondere wenn man den einzigen PCI Slot für eine 10G Karte benötigt. Was dann ginge wäre allenfalls das Booten von ESXi z.B. mit der 120GB SSD und darauf dann noch die Solaris Storage VM ablegen. Da man keinen zweiten Controller hat, muss man dann weitere Platten z.B. einen 8GB Mirror und die 256 GB SSD für weitere VMs per Physical RDM an die Storage VM durchreichen. Tricksen mit USB Storage mag ich nicht so.

Speicher ist auch ein Problem da der G8 nur max 16GB kann. Für ESXi selber kann man 1-2 GB RAM abziehen. Die Storage-VM sollte auch 4 GB haben, gerne mehr. Je nach sonstigen VMs kann das knapp werden. Der G8 sollte schon 16GB haben. Ob man darauf sinnvollerweise noch Proxmox packt wage ich zu bezweifeln (ausser zu Lerneffekten) . Wenn man lediglich 1-3 Linux VMs braucht, bringen Container keinen Vorteil. Diese VMs wären mit Vollvirtualisierung direkt unter ESXi schneller und einfacher. Der Platzvorteil von Containern ist dann eher unerheblich. Für nicht-Linux Gäste ist ohnehin ESXi erste Wahl.

Die Alternative wäre ein reiner Barebone Storageserver mit dem Celeron und den 8GB Platten und min 4 GB RAM. Den dann per 10G an den Switch anbinden. Das ist ein fixer Filer. Für den Anwendungsserver würde ich auf 10G verzichten und VM Storage lokal halten. Ideal wäre Booten (ESXi + Solaris VM) von Sata und schnelle SSD an dem HBA zum Speichern der VMs auf ZFS. Da für VMs lokaler Speicher benutzt wird ist 10G extern nicht so wichtig.


Option 3
Der G8 ist ein gesuchter Server für kleine Filer oder Backup Systeme.
Einen oder beide verkaufen und ein neues leistungsfähigeres 1151 System mit max 64GB RAM, 10G und HBA onboard + IPMI Fernwartung (SuperMicro X11 etc) kaufen wäre die Alternative siehe http://www.napp-it.org/doc/downloads/napp-it_build_examples.pdf
 
Zuletzt bearbeitet:
Sehe ich auch so. Der taugt eigentlich vor allem als (reiner) baremetal File-Server und es limitiert der Umstand, dass man nur einen PCIe-Slot hat. Da hilft es dann auch nicht, wenn man zwei von den Kisten hat, weil dann braucht man den Slot ja eben für die schnellen NICs. =) Und für einen "all-in-one" ist der Speicher eben arg knapp bemessen. Wenn der reicht, dann mag es gehen.
 
Hallo zusammen,

ich bin mit meiner aktuellen Serversituation nicht so ganz zufrieden

Moin, also das solltest du wohl am ehestens mal erläutern was das Problem ist bzw. was dich nicht zufrieden stellt.

Brauchst du 10G oder reichen dir 1G? Wie viele VM's? wie viel Speicher brauchst du?

Evtl, mit etwas Virtualisierung langt der Xeon im G8, und macht einen flexible (Storage VM + Application VM + evtl. Container VM) genug sonst -> Neukauf von was größerem und die beiden G8 verkaufen.

Wie vorher schon geschrieben PVE auf ESXi ist sehr komisch: LXC hat dann genau die geiche Performace, wie die VM. Container können aber durchaus Sinn machen.
 
Hi,

vielen lieben Dank für Eure bisherigen Anregungen. Ich ergänze Folgendes:
  • besonders leistungsfähig muss der Server nicht sein. Mein WSE2016 idlet 98% der Zeit. Das aufwendigeste was er so zu tun hat, ist gelegentlich mal einen Plex Stream zu transcodieren. Und das könnte man durch persistentes Transcoding im Hintergrund auch weiter reduzieren.
  • ESXi will ich probieren, weil meine Erfahrungen mit einer Windows VM auf einem Proxmox Server recht bescheiden waren. Proxmox im Gegenzug will ich, weil mich die Container Variante immer wieder positiv überrascht. An anderer Stelle habe ich einen alten DL380g5 mit dem bereits ausgelaufenen Proxmox 3.4, auf dem ca 25 openVZ Debian Container und zwei qemu VMs laufen. Die Grundlast der beiden VMs ist höher als die der 25 Container zusammen.
  • Ich will auf dem Microserver keine 25 VMs laufen lassen, aber wenn die Container Variante möglich wäre, würde ich meine lokalen Dienste in eigene Container auslagern. Das ist aber kein Muss, dann können die Dienste eben nicht so granular verteilt werden.
  • An Storage Spaces haben mich mäßige Schreib-/Lese-Performance und sehr sehr aufwendiges Recovery gestört (Ja, ich habe (ausgelagerte) Backups für wichtige Daten. Nein, ich habe keine redundanten Backups für eingelesene DVDs, Blurays, CDs usw. Ja, ich weiß, dass das besser wäre. Nein, für wiederbeschaffbare Daten, werde ich meinen Aufwand nicht deutlich erhöhen. Wenn der Blitz einschlägt und all meine Server und Platten himmelt, dann kann ich damit leben, dass ich Aufwand treiben muss, um die Filme usw. wieder einzulesen. Aber ich erwarte vom Filesystem, dass es mir den Aufwand nicht "einfach so" auferlegt).
  • Eine 10G Verbindung zwischen den beiden Servern hätte für mich den Charme, dass Snapshots/Backups sehr schnell zu machen wären.
  • Falls möglich würde ich gerne zu Gunsten 10G auf HBA verzichten
  • Dass der MS kein Funktions- und Performance Riese ist, ist klar. Aber ich mag die Zwerge einfach und würde sie aktuell gerne behalten :)

Ableiten würde ich z.B. folgende Szenarien:
  • MicroServer #1: Hauptserver
    • HW: Xeon, 1x 8GB, bei Gelegenheit aufstocken auf 2x 8GB
    • ESXi als Hypervisor, Proxmox lasse ich erstmal außen vor und werde es höchstens mal testen
    • ESXi in auf SSD in Slot1 würde Bootstick sparen
    • Die VMs würde ich ebenfalls auf der lokalen SSD lassen und nur auf den Storage Server sichern? Vorteil: Ausfall eines Servers legt nicht alles lahm. Nachteil: VMs können ZFS-Vorteile nicht nutzen?
  • MicroServer #2: Storageserver
    • HW: G1610T, 2x 4GB, 2x WD Red 8TB
    • napp-it ToGo: ich habe im Setup Leitfaden gelesen, dass die Grundinstallation quasi kaum Konfiguration hat, sondern die Konfiguration auf den ZFS Pools liegt. Also im Fehlerfall recht einfach wiederherzustellen ist.
    • bzgl. Virtualisierung bin ich etwas hin- und hergerissen:
      1. nicht virtualisiert: einfach. Napp-it auf SSD an SATA5; ZFS Mirrorpool auf den beiden 8TB. Oder: Napp-it nicht auf SSD, sondern direkt auf zu erstellenden ZFS Mirror installieren?
      2. virtualisiert: Vorteil: virtualisiertes napp-it kann bei Server Ausfall auf anderen Server umgezogen werden
        • Boot von USB; Installation von ESXi und napp-it-VM auf eine SSD an SATA5. Nachteil: Controller kann nicht durchgereicht werden; welche Probleme entstehen durch Physical RDM? Soweit ich gelesen habe, schränkt das ZFS-Features ein?
        • Installation von ESXi und napp-it auf USB oder SD. Wie I/O lastig ist napp-it? Wenn das Booten länger dauert, ist mir das egal, aber wie ist das im laufenenden Betrieb? ESXi auf USB geht wohl, frisst dann aber 512MB RAM für temporäre Dateien und Logs, die bei Reboot dann auch weg sind. In Summe scheint mir diese Lösung nicht so glücklich.
    • Ist eine Verschlüsselung der Platten mit der kostenlosen napp-it Version möglich? Eigentlich scheint das ein Pro Feature zu sein, aber teilweise lese ich auch "kostenlos für Home-Use". Verschlüsselung des Application VM Pools würde für eine Auslagerung der VMs auf den Storage Server sprechen.

Soweit meine etwas ungeordnete Gedanken. Ihr seht, ich weiß noch nicht so recht was ich will und hoffe, Ihr helft mir bei der Entscheidungsfindung ;)

Viele Grüße
Martin
 
In Deinem Szenario würde ich wohl MS#2 baremetal machen, alles HDDs da rein inkl. die SSD für VM-Storage.
Den "ZFS-Pool" auf der SSD gibst Du per NFS an den ESXi auf MS#1 als Speicherplatz. Mit bis zu 2x10Gbit zwischen den beiden Kisten hast Du recht viel Luft...da sollte dann wohl kaum das Netz limitieren. =)

Dann kannst Du z.B. die SSD auf den HDD-Pool mit ZFS-Replikation "lokal" sichern. Oder eben auf Wunsch ab und an auch noch extern auf eine (oder mehrere) USB-Platte(n), die du nur bei Bedarf anklemmst, so dass nicht gleich alles weg ist, wenn z.B. einmal der Blitz einschlägt. Mach ich auch so, ich nehme dafür die 4TB WD Passport.

Kommen wir zu MS#1: da würde ich wohl ESXi auf den Boot-Stick packen. Dann bindest Du den Speicherplatz auf der SSD im MS#2 per NFS im ESXi und kannst da deine VMs drauf ablegen. Der Clou: du könntest dann theoretisch auch noch den onboard-Controller per PCIe-passthrough an eine Solarish-VM durchreichen (die liegt ja per NFS auf der SSD im MS#2) und da drin mit einer weiteren HDD ein aus Sicht des MS#2 "separates externes" Backup per Replikation fahren. Theoretisch sogar INKLUSIVE der StorageVM selbst (die du allerdings im laufenden Betrieb snapshotten/replizieren musst... ;) ... hab ich so aber auch noch nicht ausprobiert. :d
Aber selbst wenn Du die Storage-VM selbst nicht sicherst: Solaris+Nappit ist sehr fix wieder aufgesetzt, da a) alle wesentlichen Settings für den Fileserver eigentlich auf den Storage-Pools liegen und b) du die Nappit-Settings über die integrierte Backup-Funktion auch noch auf den Pool sichern kannst. Solange also die Daten-HDDs noch funktionsfähig sind, bist du razzfazz wieder online.
 
Ich bedanke mich schon mal herzlichst für den Verzicht, mir Beratungsresistenz vorzuwerfen :wink: Ich weiß, dass es schwer fiel :d

Deine Anpassung meines Szenarios hört sich toll an :bigok:

Ein paar Dinge dazu noch:
  • "ZFS-Pool auf der SSD": Damit meinst Du erstmal eine Single SSD, oder? Darauf dann napp-it ToGo mit ZFS-Filesystem installieren und zusätzlich die VMs ablegen oder?
  • Backup ist eh klar. Wichtige Sache werden regelmäßig gesichert und auch ausgelagert. Wenn die nächsten Wochen endlich die Glasfaser eingeblasen wird, kann ich auch endlich wieder dem Plan nachgehen, mit Amazon Glacier tagesaktuelle Sicherungen wichtiger Dinge außer Haus zu haben. Nach dem Drama mit StorageSpaces habe ich sicherheitshalber auch mal Wiederbeschaffbares extern gesichert.
  • Oben genannte SSD würdest Du im MS#2 wo einbauen? Slot1 und Slot2 sind ja mit 6GBit, die andern mit 3GBit angebunden, theoretisch wäre die SSD in einem dieser Ports also gut aufgehoben. Wobei ich nicht glaube, dass meine ConsumerSSDs überhaupt so viel schaffen :) Insofern hätte der Einbau im ODD-Slot den Charme, dass ich alle vier 3,5" WD Red Platten in die Trays packen könnte.
  • ESXi auf Bootstick, VMs über NFS hört sich vernünftig an. Ob ich das tmpfs im RAM gut finde, weiß ich noch nicht genau. Deine Überlegung bzgl. Passthrough hört sich ebenfalls schlüssig an, das wäre etwas, das ich evtl. testen würde, wenn es soweit ist.
  • Danke für die Erläuterung bzgl. Installation und Konfiguration von napp-it. Das deckt sich im Wesentlichen mit dem, was ich gelesen habe. napp-it zu virtualisieren ist damit passé, denke ich.
 
Zuletzt bearbeitet:
Sehe ich auch so. Der taugt eigentlich vor allem als (reiner) baremetal File-Server und es limitiert der Umstand, dass man nur einen PCIe-Slot hat. Da hilft es dann auch nicht, wenn man zwei von den Kisten hat, weil dann braucht man den Slot ja eben für die schnellen NICs. =) Und für einen "all-in-one" ist der Speicher eben arg knapp bemessen. Wenn der reicht, dann mag es gehen.
Du kannst auch beides haben:

How To Create A NAS Using ZFS and Proxmox (with pictures) - Open Source Web-Based - Level1Techs Forums

Für mich gerade die aktuelle Konfiguration daheim. Rennt mit einer ucs VM und einem Server 2012r2 rockstable und bietet 400-450mb/s lesend / schreibend. Mehr kann ich nicht herauskriegen, weil die Client SSD zum benchen limitiert.
Dann noch iscsi Targets drauf und voila - ich brauche nie wieder n es SSD > 256gb in den clients ;))

Gesendet von meinem XT1635-02 mit Tapatalk
 
Also ich verstehe nich warum du dein System auf beide Microserver ausdehnen willst?
Wenn du 10G nicht für dein Heimnetz brauchst spaarst du dir halt viel komplexität, auch noch etwas Strom usw dazu.

Um etwas "Ordnung" zu halten und fürs schnelle ausrollen, finde ich aber Container auf nem ESXi-Gast ganz sinnvoll, sei es Docker oder LXC. Nur würde ich dann vll nicht zu PVE greifen sondern was "leichters" nehmen.

Den 2. kann man denn noch als "Backup Server" benutzen. Auch wenn ich das bei ZFS noch nicht gemacht habe sollten doch auch hier Snapshots übers Netzwerk gehn (mache ich bei BTRFS), und sofern man nicht große daten Mengen schreibt, sollte das dann auch über 1G ganz schnell gehen nach dem ersten erstellen.
Oder du monetarisierst ihn und steckt das denn in den anderen.
 
In dem von mir skizzierten Szenario könntest du den ESXi komplett Disk-frei betreiben. USB-Bootstick würde reichen.

Und ja, die SSD im Storage-MS wäre dann in einem „simple“ Pool, d.h. ohne jede Redundanz. Und gleichzeitig würde da eben je nach Wunsch auch das OS drauf liegen. Für den VM-Storage kannst du dann ein eigenes ZFS dataset darauf anlegen. Wegen der fehlenden Redundanz würde ich die SSD in jedem Fall mindestens 1x täglich auf den HDD-Pool replizieren (nachts oder so).
 
Spräche denn etwas dagegen, Napp-It auf MicroSD zu packen? Besonders I/O-lastig wird das nach dem Booten nicht mehr sein, oder?

Und weiter: gibt es Gründe, die gegen Napp-It to-go sprechen? Ich frage, weil doch einige selbst ein Solaris installieren und Napp-It on-top packen.
 
1.
Die Storage VM macht recht wenig Last auf der Systemplatte.

2.
Das OVA template basiert auf OmniOS, einem freien Solaris Fork.
Oracle Solaris ist ein kommerzielles OS das man nur bei Oracle erhält (kostenlos für noncommercial Demo und Softwareentwicklung). Will man also Solaris muss man es manuell installieren und dann napp-it anschliessend per wget Installer installieren (+ VMware Tools die man bei Vmware für Solaris herunterladen kann)
 
1.
Okay, vielen Dank. Dann werde ich mal versuchen, napp-it auf MicroSD zu installieren. Ich würde zwar Bare-Metal installieren, aber wenn es als VM geht, dann sicher auch Bare Metal.

2.
Den Unterschied ist soweit klar, meine Frage zielte darauf ab: Gibt es einen Grund, Solaris händisch zu installieren und Napp-It on top. Anstelle von Napp-it to-go basierend auf OmniOS. Vorausgesetzt, dass diese Maschine ausschließlich für Napp-It genutzt wird. Was kann Solaris besser als OmniOS? Ein Grund gegen OmniOS könnte sein, dass die Entwicklung letztes Jahr eingestellt wurde und der Fork OmniOS Community Edition noch nicht für Napp-It verwendet wird, wenn ich das richtig sehe.

3.
Gibt es einen Sammelthread/Fragenthread für Napp-It? Bisher habe ich keinen gefunden und vielleicht wäre das doch sinnvoll, nachdem Napp-It im Forum immer mehr Verbreitung findet? Wenn nicht, wäre es eine Option, dass Du (gea) einen eröffnest? Dann könntest Du falsch von Dir gewünscht und Du Dir die Arbeit machen willst, auch eine kleine FAQ im Startthread machen (neben der auf napp-it.org)

Viele Grüße
Martin
 
2.
Unterschiede OmniOS vs Solaris siehe Oracle Solaris 11.4 | ServeTheHome and ServeThe.Biz Forums

Ansonsten basiert das aktuelle ESXi Template auf OmniOS CE 151024.
OmniOS wird auch nur bei OmniOS-CE weiterentwickelt (stecken übrigens zwei Firmen aus der Schweiz und UK dahinter). Seit neuem gibt es auch wieder kommerziellen Support für OmniOS CE

3.
Die wenigsten Fragen sind napp-it spezifisch sondern betreffen meist ZFS ganz allgemein oder aber eher das Basis-OS wie OmniOS, OpenIndiana oder Solaris. Dann müsste ich für jedes Thema einen Thread aufmachen. Dennoch blieben viele Themen redundant. Der ZFS Stammtisch mit einem eigenen Thread bei Bedarf ist schon sinnvoll.

Bei STH sieht es etwas anders aus. Da gibt es einen eigenen Haupt-Thread zu Solarish und napp-it mit Stickies und einem Thread je OS (Solaris, Nexenta, OpenIndiana, and napp-it | ServeTheHome and ServeThe.Biz Forums). ZFS in den USA auch viel populärer als in DE und ein Blick über den Teich meist auch hilfreich auch wenn HardwareLuxx im deutschsprachigen Bereich führend ist was ZFS angeht.
 
Um mal einen Zwischenstand abzuliefern: Die Verteilung auf zwei Geräte habe ich mangels Notwendigkeit zurückgestellt.
Den Xeon habe ich mit 2x8GB ausgestattet und die vier WD Red Platten sowie die große SSD reingepackt.
ESXi 6.5U1 läuft auf einer 64GB microSD zusammen mit einer Solaris 11.4 VM mit napp-it.
gea war dankenswerterweise bereit, meine Patches in den dev Zweig einzupflegen, dass nun alles zu meiner Zufriedenheit läuft. Naja, fast. Die vmware-tools laufen auf 11.4 noch nicht, aber auch der E1000 Treiber bringt 1GBit problemlos durch. Kommt hoffentlich noch, auch wenn es nichts mit napp-it zu tun hat.

Der B120i mit allen fünf Platten wird an napp-it weitergereicht.
Weitere VMs liegen auf der SSD. An ESXi VMs bisher nur einmal RancherOS mit Rancher Server für Docker Container. Außerdem liegen auf der SSD die Plex-Container Library sowie das Transcode Verzeichnis. 2x8TB Mirror für die Produktiv Deten und die 2/3TB Platten sind aktuell ungenutzt.

Bisher sehr zufrieden mit dieser Lösung!
 
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