[Kaufberatung] Hardware für Selbstbau NAS mit ZFS + Napp-IT

keijko

Neuling
Thread Starter
Mitglied seit
15.03.2019
Beiträge
11
Moin,
ich möchte meine Synology DS1511+ durch ein Selbstbau-NAS ersetzen. Ich nutze die Synology außer als Datengrab noch über Docker

- Kopano
- OnlyOffice
- ein Tool für OCR-Scan von PDFs (SynOCR)

außerhalb vom Docker also über deren OS (DSM)

- Fotoshare-App (DS Photo)
- Nextcloud
- TV-Headend
- fürs Homebanking den Hibiscus Payment-Server
- für die vorher genannten Dienste benötige ich auch den LDAP-Server, Webserver und MariaDB

Diese Dienste soll das neue System übernehmen und wenn ich schon ablöse, soll das neue System auch noch DHCP, DNS und Pihole vom Raspberry anbieten.

Ich habe mir folgende Hardware zusammengestellt. Und möchte einmal eure Meinung dazu hören:

- Gigabyte B360M DS3H Intel B360 So.1151
- Intel Core i5 8400 6x 2.80GHz So.1151
- 2x 16GB Corsair Vengeance LPX DDR4-2400 DIMM CL16 Dual Kit
- 1x 250GB Crucial MX500 2.5" (CT250MX500SSD1)
- 3x 4000GB WD Red WD40EFRX

Der Chipsatz kann vt-d, es handelt sich aber nicht um eine Variante mit ECC. Da bin ich mir unschlüssig! Einerseits habe ich bis dato noch nie den Fall von korrupten Dateien oder Fehlfunktionen von Services gehabt. Anderseits frage ich mich, ob ich bei der Investitionssumme nicht am falschen Ende spare. Was meint ihr dazu?

Wenn ich mit napp-it zu recht komme, würde ich damit auch im Blick nehmen wollen, mit einem virtuellem Schmalspur-Windows und einem Kali-Linux das eine oder andere auszutesten, was mir auf Arbeit über den Weg läuft und könnte das konfigurationstechnisch so absichern, dass Kali nur sich selbst, das Internet und die Testmaschine sieht. Zusätzlich würde ich mir auch Sprachassistenzssysteme ohne Cloudanbindung a la OpenHab, Calaos, Snip etc. anschauen wollen. Daher hoffe ich, dass die Hardware auch für diese Dienste ausreichend ist.

Gruß
keijko

[Edit: Finaler Kauf]
Supermicro X11SCA-F
Intel Xeon E-2176G
2x 16GB Kingston Server Premier KSM24ED8/16ME
LSI Logic SAS 9300-8i SGL 2 Port Multi-lane PCIe 3.0 x8 Low Profile

128GB Transcend 110S M.2 2280 PCIe 3.0 x4 3D-NAND TLC (TS128GMTE110S)
4x 6000GB Seagate IronWolf NAS ST6000VN0033
2x 480GB Intel DC S4500 2.5" (6.4cm) SATA 6Gb/s 3D-NAND TLC (SSDSC2KB480G701)

be quiet! Dark Base 900
EKL Alpenföhn Brocken 2 PCGH-Edition
550 Watt be quiet! Straight Power 11 Modular 80+
2x 1.00m Startech SAS 6Gb/s Adapterkabel SFF-8643 Stecker auf 4xSATA Stecker
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Tausend Wege führen nach Rom

Mit dem System könnte man z.B. OmniOS installieren das Storage anbietet und die anderen Dienste mit Linux/LX Container bzw. Bhyve virtualisieren. Nachteil: Wenn irgendwas zickt, steht alles und Sichern/ Wiederherstellen ist aufwändig.

Würde ich persönlich nie so machen. Wenn man einen Type-1 Virtualisierer wie ESXi unter alle VMs legt, so laufen alle VMs/Dienste völlig unabhängig vom Virtualisierer und sind schnellstens wiederhergestellt, egal ob Storage VM oder weitere auf ZFS.

Ich würde ein SuperMicro Serverboard nehmen (teurer, mit ECC) und dafür eher eine kleinere CPU zum Ausgleich (2C/4H), 7th Generation Intel® Coreâ„¢ i3 Processors Product Specifications. Das mit den Speicherfehlern (gegen die ECC schützt) ist ohnehin so. Ohne ECC bekommt man davon nichts mit (verdächtigt allenfalls Microsoft bei Abstürzen) und dazu gilt, je mehr Speicher desto höhere Fehlerwahrscheinlichkeit, desto wichtiger ECC. Dazu IPMI Fernwartung.

32GB RAM (2 x 16) ist ok, man hat die spätere Optione für mehr
Speichersuche

Wenn man aber auf ESXi als Basis setzt, so braucht man ein ESXi Bootlaufwerk (idealerweiser Sata oder M2, ab 50GB) auf der auch die Storage VM liegt. Für das eigentliche Storage ist am besten ein LSI SAS HBA geeignet (den kann man komplett für Storage nutzen oder einzelne Platten an VMs geben) oder alternativ z.B. von M2 booten und Sata komplett an die Storage VM geben.

Boards z.B. (die bisherigen Klassiker)
X11SSL-CF | Motherboards | Products - Super Micro Computer, Inc. (mit SAS HBA) oder
X11SSH-F | Motherboards | Products - Super Micro Computer, Inc. (M2)

Das X11 gibt es als X11SSH-CTF auch mir SAS HBA und 10G onboard.

Als 2 x M2 Alternative auch die neueren 1151 Boards für gen8 i3 CPUs
X11SCH-F | Motherboards | Products - Super Micro Computer, Inc. (die gibts leider noch nicht mit onboard SAS oder 10G man hat dafür aber noch 2 freie pcie Slots) mit CPU 8th Generation Intel® Coreâ„¢ i3 Processors Product Specifications z.B. 4Core i3-8100
 
Zuletzt bearbeitet:
Moin,

und danke für eure Hinweise. Wenn ich es ausprobiere möchte ich schon so bauen, dass ESXi die Basis ist. Sprich, dass es unter allen VM's liegt.

Die Boards von gea sind preislich recht intensiv. Deswegen will ich da momentan noch nicht ran. Mir ist aber unklar, warum das mit dieser Konfiguration nicht möglich ist?
Das ausgesuchte Board besitzt einen M.2-Slot. Wenn ich diesen Slot beispielweise mit einem

128GB Intel 600p M.2 2280 PCIe 3.0 x4 32Gb/s 3D-NAND TLC

belege, könnte ich doch wie von gea als Alternativ-Option von dort booten und Sata komplett an die Storage VM geben. Oder bin ich da auf den Holzweg?

Bezüglich ECC-RAM könnte ich mir zwei von diesen Riegeln vorstellen:
16GB Kingston KTH-PL424E/16G DDR4-2400 ECC

@geimist
Falls du der selbe wie aus der Syno-Community bist: Danke für deine Arbeit! Du hast da ein wirklich tolles Paket am Laufen!
Danke für deine Info. Das war vielleicht etwas missverständlich formuliert. Die Auflistung sollte als Überblick dienen, was ich derzeit nutze und somit als Dienste weiterhin genutzt werden soll. Dass ich da nichts 1:1 migrieren kann, ist mir klar.
 
Zuletzt bearbeitet:
Das ausgesuchte Board besitzt einen M.2-Slot. Wenn ich diesen Slot beispielweise mit einem
128GB Intel 600p M.2 2280 PCIe 3.0 x4 32Gb/s 3D-NAND TLC
belege, könnte ich doch wie von gea als Alternativ-Option von dort booten und Sata komplett an die Storage VM geben. Oder bin ich da auf den Holzweg?
M2 würde gehen, aber Du kannst vermutlich nicht den "on-board" SATA Controller direkt an die VM durchgeben.

Bezüglich ECC-RAM könnte ich mir zwei von diesen Riegeln vorstellen:
16GB Kingston KTH-PL424E/16G DDR4-2400 ECC
Muss Board/CPU dann auch unterstützen, bei Deiner bisherigen Wahl ist das nicht der Fall.

Ob ECC oder nicht, hängt auch von Deinem Budget ab. Neben den Supermicro-Boards gibt es teilweise günstigere Alternativen von z.B. Asus.
 
Zuletzt bearbeitet:
Du könntest für manche Dienste das DSM im ESXI virtualisieren ->XPEnology.Nur Updates (DSM) sollte man dann nicht mehr einfach durchklicken ^^
 
M2 würde gehen, aber Du kannst vermutlich nicht den "on-board" SATA Controller direkt an die VM durchgeben.

Muss Board/CPU dann auch unterstützen, bei Deiner bisherigen Wahl ist das nicht der Fall.
Stimmt das hatte ich nicht beachtet. Meinst du mit günstigen ASUS z.B. das Asus Q87M-E (C2)? Da müsste ich mit den RAM auf DDR3 schwenken, womit ich zumindest keine Problem hätte. Aber ich möchte schon 16GB pro Einzelmodul haben. Auf was müsste ich achten, um den SATA-Controller an die VM's durchgeben zu können?

Du könntest für manche Dienste das DSM im ESXI virtualisieren
ESXi -> VM mit DSM (oder noch eine Stufe weiter) -> Docker ist keine Alternative für mich. Denn ESXi, napp-it usw. wäre genau deswegen interessant für mich, da ich eben die OS'ses frei wählen und einrichten kann. Ich möchte gerade nicht mehr diese Einschränkungen haben, und verzichte lieber auf den Kauf von Komfort bei Synology, QNAP & Co.
 
Zuletzt bearbeitet:
Beim Durchreichen von SATA ist das mit Passthrough Glückssache und offiziell unterstützt wird es sowieso nicht. Verstehe ich das Problem richtig?
D.h. wenn ich auf der sicher(er)en Seite sein will, sollte ich die von gea empfohlen Supermicro-Boards nehmen. Das hieße bei M.2 - Variante mit Intel 8. Generation beispielsweise

Supermicro X11SCH-F
Intel Core i3 8100 4x 3.60GHz So.1151
2x 16GB Kingston KSM24ED8/16ME DDR4-2400 ECC DIMM CL17 oder
2x 16GB Transcend DDR4-2133 ECC DIMM CL15
128GB Intel 600p M.2 2280 PCIe 3.0 x4 32Gb/s 3D-NAND TLC (SSDPEKKW128G7X1)

als Basis?

Irgendwie habe ich bei einem i3 Angst, dass ich schnell an irgendwelche Grenzen stoße, wenn ich doch mal ein oder zwei Systeme mit Grafischer Oberfläche virtualisieren will. Ist das berechtigt?
 
Irgendwie habe ich bei einem i3 Angst, dass ich schnell an irgendwelche Grenzen stoße, wenn ich doch mal ein oder zwei Systeme mit Grafischer Oberfläche virtualisieren will. Ist das berechtigt?
In so einem Fall kannst Du m.W.n. auch eine Grafikkarte an die VM durchgeben.
Aus meiner Sicht hat der i3 ein wirklich gutes Preis-/Leistungs-Verhältnis.

Könntest natürlich auch gebraucht nach einen Xeon E3 (v5,v6) samt Board Ausschau halten. Damit lässt sich auch nochmal Geld sparen.
 
Wenn ESXi die Basis sein soll
- ESXi ist eine Diva, geht nicht mit jedem; mit einer Realtek Nics wirds wohl nicht mal installieren wollen.
 
mit einer Realtek Nics wirds wohl nicht mal installieren wollen.
Bezieht sich deine Antwort auf die Hardwareauswahl von ersten Thread oder den von vorhin, wo ich mir Hardware auf Basis eines von dir empfohlen Supermicro-Boards ausgesucht habe? Denn bei denen ist Intel drauf. Oder bin ich jetzt völlig auf dem Holzweg?
 
Mit dem System könnte man z.B. OmniOS installieren das Storage anbietet und die anderen Dienste mit Linux/LX Container bzw. Bhyve virtualisieren. Nachteil: Wenn irgendwas zickt, steht alles und Sichern/ Wiederherstellen ist aufwändig.
gea, ist die Kritik aber wirklich gerechtfertigt so? Ich kann doch in OmniOS /SmartOS die zones/VMs genauso in einem ZFS pool speichern und dann in einem neu installierten OmniOS /SmartOS wieder importieren, wie ich das mit ESXi neu + OmniOS neu + VMs importieren auch könnte. Das ist doch gerade bei SmartOS das reguläre update-Konzept.

ProxMox macht es ja letztlich auch so (nutze ich nicht).
 
Ist eine Frage des Konzepts.

Man kann den Virtualisierer unterhalb aller Gäste ansiedeln (Type-1 wie ESXi oder Xen), innerhalb des OS (Zonen, KVM. Container) oder als Applikation oben drauf (Virtual Box, Virtual PC). Jedes Konzept hat so seine Vor und Nachteile.

SmartOS z.B. ist als reine Startplattform für VMs zu sehen, fast so wie ESXi nur dass die Virtualisiserung gut gekapselt innerhalb des OS abläuft - mehr oder weniger gut gekapselt von dem Basis-OS und mit gewissen Abhängigkeiten vom Basis OS. Ein OS Update z.B. kann durchaus Auswirkungen auf die Gäste haben (neue/wegfallende Features, Inkompatibilitäten etc). Die Auswirkungen sind zwar geringer als bei einem vollwertigen OS bei den auch andere Dienste laufen (Storage Appliance, Webserver, Mediaserver etc) aber dennoch. Wenn man aber neben dem Starten von VMs weitere, teils komplexe Dienste hat, sind die Abhängigkeiten und auch der Aufwand des Aufsetzens oder Wiederherstellens erheblich.

Bei einem Type-1 Virtualisierer entfallen alle Abhängigkeiten. Auch muss man sich nicht entscheiden ob man Linux als Container haben möchte oder für eine Vollvirtualisierung eher KVM, Bhyve oder Virtualbox jeweils geeigneter ist oder es dabei wieder Ungereimtheiten gibt. Ein minimalistischer Virtualisierer wie ESXi und ein minimalistisches Storage OS wie OmniOS + alle anderen VMs unabhängig davon gibt halt die wenigsten Abhängigkeiten und die beste Verfügbarkeit. Dazu hat man auch die beste Unterstützung beliebiger Gast-Betriebssysteme.
 
Wenn ESXi die Basis sein soll
- ESXi ist eine Diva, geht nicht mit jedem; mit einer Realtek Nics wirds wohl nicht mal installieren wollen.

Geht auch bei einigen Intel consumer NICs nicht. Man kann jedoch auch die Realtek-treiber in ESXi einbinden.
 
ESXi -> VM mit DSM (oder noch eine Stufe weiter) -> Docker ist keine Alternative für mich. Denn ESXi, napp-it usw. wäre genau deswegen interessant für mich, da ich eben die OS'ses frei wählen und einrichten kann. Ich möchte gerade nicht mehr diese Einschränkungen haben, und verzichte lieber auf den Kauf von Komfort bei Synology, QNAP & Co.


Ich wollte damit nur darauf Hinweißen, dass du (scheinbar) liebgewonnen Tools nicht unbedingt verlieren musst (SynoOCR), da man DSM in ESXi betreiben kann - neben all den anderen OS die in ESXi laufen.Eine Einschränkung sehe ich hier nicht, eher im Gegenteil -> liebgewonnene Programme weiter nutzen und noch mehr.
 
Moin,

@Luckysh0t
Ich bin dir für deinen ursprünglichen Hinweis dankbar. Mein Hinweis sollte nur noch einmal klar stellen, dass ich meine bisherigen Systeme nicht 1:1 virtualisieren möchte, nur das dann halt ESXi unter allem liegt.

Wenn ich das schon haben möchte, ist es mein Ziel, ESXi und OmniOS als Basis zu nutzen, sodass ich bei den anderen VM's möglichst unabhängig von dieser Basis bin.

Ich bin auch nochmal die extrem gute Installationsanleitung von Napp-IT durchgegangen. Hier sehe bei meinen Vorhaben momentan nur ein Fragezeichen bei der Rechtevergabe via LDAP. Denn in der Anleitung wird zwar erwähnt, dass LDAP möglich ist, aber die Beschreibung selbst zielt auf Active Directory ab. Ich denke aber, dass ist der Tatsache geschuldet, dass AD am häufigsten als LDAP-basierter Dienst genutzt wird und es daher wichtig war, dass Interessierte das direkt lesen können. Hier werde ich beim Einrichten darauf achten müssen, dass beim Neustart die VM mit LDAP da ist, bevor andere VMs starten. Denn sonst würden andere Dienste wie Kopano oder Nextcloud, die sich ihre Datenverzeichnisse mit LDAP-Credentials von der Storage-VM mappen sollen, ins Leere greifen.

Aber das ist erstmal der zweite Schritt. Zunächst muss ich mir über die Hardware im klaren sein und angeschafft haben.
 
Zuletzt bearbeitet:
Bezüglich der benötigten Plattenkapazität sieht es so aus, dass ich aktuell mit einem Raid 5 arbeite und momentan 4 TB aktiv nutze. Ich denke nicht, dass in absehbarer Zeit die Datenkapazität erheblich ansteigt. Meine Backupstrategie besteht aus einem täglichen Backup via rsync und einem monatlichen Backup auf USB-HDD an zwei verschiedenen Orten. Aus Sicht vom NAS werden diese Backups außer Haus vorgehalten.

Den Ausfall einer Platte hatte ich in all den Jahren schon zweimal und konnte gut damit leben, dass ich bis zum Erhalt der neuen Platte das Risiko eines Totalausfall habe. Von daher würde ich entweder 3 oder 4 Festplatten a 4 TB einsetzen wollen.

Bezüglich den möglichen Varianten mit ZFS gab es hier vor zweieinhalb Jahren schon mal eine interessante Diskussion. Ich beziehe in meine Überlegung diese tabellarische Übersicht mit ein. Diese Werte scheinen von 2017 oder früher zu sein. Ist das noch realistisch und kann ich deren Modell von einem TB pro Platte auf meine Variante überhaupt hochskalieren? Dann würden sich meine Plattenanzahl folgende Varianten ergeben:

KonfigurationIOPS LesenIOPS SchreibenMB/s LesenMB/s SchreibenVerfügbarer SpeicherplatzFehlertoleranz
1x3 Platten Mirror7503502001004 TB (33%)2
1x3 Platten RAID-Z12502502002008 TB (66%)1
2x2 Platten Mirror10005004002008 TB (50%)2 (1 pro VDEV)
1x4 Platten RAID-Z125025030030012 TB (75%)1
1x4 Platten RAID-Z22502502002008 TB (50%)2

Eine generelle, spätere Erweiterung würde ich vermutlich eher darüber realisieren, dass ich alle vorhandenen Platten nach und nach durch Größere austausche als das ich mit drei weiteren Platten ein weiteres VDEV definiere. Von daher stellt sich mir die Frage, was ich im Vergleich mit einem 1x3 Raid-Z1 mit der vierten Platte gewinne. Und da lese ich die Tabelle so, dass

- der 2x2 Mirror von der Ausfallsicherheit wie ein Raid-Z1 zu sehen ist, da mir im Zweifelsfall das System um die Ohren fliegt, wenn im gleichen Pool die zweite Platte ausfällt. Aber ich würde anscheinend einen Perfomancegewinn haben.
- das 1x4 Raid-Z1 bis auf mehr Speicherplatz weder Performancegewinn, noch ein Zuwachs an Sicherheit bedeuten würde und für mich uninteressant ist.
- das 1x4 Raid-Z2 die identische Leistung wie das 1x3 Raid-Z1 bringen würde, ich aber eine Fehlertoleranz von zwei Platten haben würde.

Wäre der Performancegewinn bei einem 2x2 Mirror wirklich spürbar oder wäre das nur etwas um sich an Benchmarkergebnissen zu erfreuen?

In dem anderen Thread wird allerdings auch das Straucheln von einer Platte mit Z1 angesprochen:
[..]RAID-Z1 ist, je nach verwendetem Betriebssystem bei EINER nur zum Teil defekten Platte u.U. nicht mehr in der Lage, die Lese- / Schreibraten aufrecht zu erhalten, die es normalerweise hat. Beispiel: Hast du ein System mit 100MB/s lesen, beginnt eine Platte zu straucheln. Plötzlich hast du zeitweise nur noch 5MB/s. Mach da mal ein Backup... viel Spaß.[..]

Verstehe ich das richtig, dass mir mit einem Raid-Z2 die Lesegeschindigkeit(/Schreibgeschwindigkeit) nicht so derbe einbrechen würde?
 
Zuletzt bearbeitet:
Für die Betrachtung der Performance muss man wahlfreies Lesen/Schreiben kleiner Datenbläcke (Metadaten, kleine Files) und sequentielles lesen/Schreiben großer Files (Video auf leere Platte schreiben) unterscheiden.

Die Performance beim Zugriff auf kleine Dateien und Metadaten wird bei ZFS stark durch den RAM Schreib/Lesecache verbessert. Mit viel RAM kann man ZFS stark von der Poolperformance entkoppeln. Das gilt aber nicht für sequentielles Lesen oder beim erstmaligen Zugriff auf Daten. Das ist nicht im Lesecache. Der Schreibcache (default max 4GB RAM/10% RAM) verbessert die Schreibperformance immer weil damit keine kleinen Random Schreibaktionen stattfinden-

Wenn man z.B. mit VMs arbeitet, so ist die gefühlte Performance sehr stark von den iops abhängig. Eine Verdoppellung oder Vervierfachung beim Lesen eines Raid-10 vs Raid Z [1-3] ist da schon deutlich spürbar.

Ein wichtiger Nebenaspekt ist aber dass der Inhalt des RAM-Schreibcaches bei einem Absturz verlorengeht. ZFS wird wegen CopyOnWrite dadurch nicht beschädigt, eine VM mit einem anderen Dateisystem kann dagegen korrupt werden. Das verhindert man durch sync write. Dadurch sinkt aber die Schreibleistung eines Plattenpools gerne mal von 400MB/s auf 20-50MB/s.

Was ich machen würde:
Bei 4 TB würde ich einen einfachen Mirror aus 2 x 4 oder 6 TB Platten machen. Bei besonders hohen Ansprüchen an Datensicherheit als Dreifach Mirror. Den Pool würde ich für Dateidienste und Backup nutzen.

Für die VMs würde ich einen kleineren extra SSD/NVMe Pool nehmen - auch als Mirror. Bei NVMe muss man aufpassen. Da gibt es sehr gerne Probleme mit Pass-through. Ich bevorzuge da klassische 6G SSDs oder 12G SAS SSDs wenns besonders schnell sein soll (WD Ultrastar SS 530). Die bieten auch Hotplug. Wenn man sicheres Schreiben haben möchte, dann Enterprise SSDs mit Powerloss Protection bevorzugen (z.B. Intel DC, Samsung SM, WD Ultrastar SS)
 
Okay, dann würde ich entweder 4x4TB oder 4x6TB als WD Red oder Seagate Ironwolf für den Datenstore als 2x2 Mirror nehmen. Für die VMs habe ich als einzelnen 2er Pool die

480GB Intel DC S4500 2.5" (6.4cm) SATA 6Gb/s 3D-NAND TLC (SSDSC2KB480G701) oder die
480GB Intel D3-S4510 2.5" (6.4cm) SATA 6Gb/s 3D-NAND TLC (SSDSC2KB480G801) in den Blick genommen.

Letztere hat etwas schnellere Schreibgeschwindigkeit, aber wesentlich höre IOPS. Da will ich mich noch einmal belesen. Aber was meint ihr dazu bzw. habt ihr konrekte Verbesserungsvorschläge.

So! Nun wird es aus meiner Sicht richtig wild. Denn ich liege mit der aktuellen Hardwarekonfiguration finanziell schon einiges über dem, was ursprünglich angepeilt war. Zusätzlich sieht es so aus, dass das neue System von Anfang als Towergehäuse geplant war. Das bedeutet aber auch. Das ein zusätzlicher Tower unter dem Arbeitstisch wandert (da der Tower nicht am Platz vom jetzigen NAS aufgestellt werden kann). Meine Freundin meinte zwar, dass ich vor allem den Arbeitstisch nutze und dort sitze, aber Begeisterung sah anders aus.

Daher stellt sich mir die Frage, ob ich bei der Hardwareaufstellung aus dem 8. Beitrag auf einen Xeon E3 wechsle, meine AMD-Grafikkarte dort mit einbaue und die beiden Systeme meines bisherigen Desktop-PCs (Win10 & Ubuntu) dort gleich mit virtualisiere. Ich nutze keine aufwendigen Grafikprogramme und spiele auch keine Spiele, mir aber mein Dualmonitoring mit je 1920x1200 erhalten wollen.

Eventuell würde ich auch darüber nachdenken das Board nochmal auf ein Supermicro X11SCA oder X11SCA-F und einem E-2XXX Xeon zu ändern, um vielleicht sogar ohne Grafikkarte auszukommen.

Ich habe heute nur kurz geschaut, ob das überhaupt möglich wäre und festgestellt, dass Dualmonitoring via Remote sehr schwierig ist. Aber direkt vom Host zum Gast an der Hardware scheint es möglich zu sein. Daher stellt sich für die Frage, ob es sich lohnt darüber nachzudenken und somit auch noch gleich den Desktop-PC damit abzulösen?
 
Zuletzt bearbeitet:
Moin,

es ist final folgende Hardware geworden:

Supermicro X11SCA-F
Intel Xeon E-2176G
2x 16GB Kingston Server Premier KSM24ED8/16ME
LSI Logic SAS 9300-8i SGL 2 Port Multi-lane PCIe 3.0 x8 Low Profile

128GB Transcend 110S M.2 2280 PCIe 3.0 x4 3D-NAND TLC (TS128GMTE110S)
4x 6000GB Seagate IronWolf NAS ST6000VN0033
2x 480GB Intel DC S4500 2.5" (6.4cm) SATA 6Gb/s 3D-NAND TLC (SSDSC2KB480G701)

be quiet! Dark Base 900
EKL Alpenföhn Brocken 2 PCGH-Edition
550 Watt be quiet! Straight Power 11 Modular 80+
2x 1.00m Startech SAS 6Gb/s Adapterkabel SFF-8643 Stecker auf 4xSATA Stecker

[ESXi]
Den Ruf der Hardware-Diva macht sie alle Ehre! In meinen Vorrechrechen hatte ich das Gefühl, dass ich bezüglich passthrough mit der 6.5er Version besser fahre. War auch so, aber dafür hatte ich mit etlichen anderen Nicklichkeiten zu kämpfen. Daher hatte ich dann die 6.7 genommen und dort sah es bezüglich des SATA-Passthrough an die Storage-VM wie folgt aus:

Mit der 6.7.0U1 vom 16.10.2018 war es möglich. Später habe ich in einem Blog erfahren, wie man relativ simpel via ESXi-Cli und online-Verbindung die Treiber auf den neuesten Stand bringen kann. Nach dem Update vom Blog vie Copy&Paste auf das Treiberpaket von Ende 01.2019, war es nicht mehr möglich. Bei der Suche nach der Problemlösung sah ich bei VMWare selbst, dass es noch ein Update von Anfang 03.2019 gab. Damit wäre es dann wieder möglich gewesen. Das war mir dann aber alles zu unsicher. Denn später im laufenden Betrieb will ich nicht jedes mal zittern, ob nach einem Update der Passthrough noch funktioniert oder mir die VMs und der Datastore um die Ohren fliegt. Deshalb habe mich dann doch für die HBA-Variante entschieden.

Es ist nicht mehr notwendig, aber aus reinem Interesse habe ich eine Frage dazu. Funktioniert der bekannte und beliebte Hack mittels Einträgen in passthru.map in der 6.7 noch? Denn mit der 6.5 hat das funktioniert, aber nicht mehr in der 6.7. Im Internet ist einerseits oft zu lesen, dass diese Art des mapping mit 6.7 nicht mehr läuft und andererseits gibt es etliche Anleitungen, wo damit doch auf einer 6.7 irgendwelche Geräte zum Passthrough überedet wurden.

Wenn jemand die Variante folgt, einen Datenstore mittels Storage-VM und NFS-Share an die ESXi anzubinden, worauf die VMs liegen, so empfehle ich bei Autostart-Konfiguration von ESXi nicht nur die Zeitverzögerungen für das Hochfahren, sondern auch für das Herunterfahren im Blick zu haben. Denn wenn das nicht sauber konfiguriert ist und die Storage-VM gleichzeitig mit allen anderen Maschinen herunterfährt bricht logischerweise der ESXi der Datenspeicher für die anderen VMs weg, während die noch am Herunterfahren sind. Meine die OSs der VMs waren zu diesen Zeitpunkt Ubuntu, Debian und FreeBSD und ich konnte die auftretenden Probleme nach diesen Missglück schnell lösen. Dennoch fanden einige VM-Container sowie die OSes darunter meine Aktion allesamt "uncool".

Insgesamt bin ich glücklich mit ESXi und es gibt mir zusammen mit napp-it als Storage-VM genau die Freiheiten, die ich mir gewünscht habe.


[napp-it]

Hier bewahrheitet sich wieder, meine eigene Erkenntnis, dass tolles Design das erste Anzeichen für fehlende Funktionialität ist! Es ist ein tolles, ausgereiftes System ohne Design-Schnickschnack und die Dokumentationen sowohl für die Installation, als auch Anpassungen, Updates sowie für den laufenden Betrieb (ich sag nur ZFS-Design-Guide) sind allererste Sahne!

Ich habe die napp-it via der all-in-one-Lösung implementiert. Hier gab mir ESXi zu verstehen, dass die VM-Ware-Tools veraltetet sind (verständlich) und ich außer den Hostname null Informationen von der VM bekommen habe. Das ist nicht weiter dramatisch, aber ich konnte napp-it auch nicht herunterfahren, sondern musste es immer hart ausschalten. Da diese Version mit Open-VMware-Tools kommt, hatte ich ein Update versucht, aber es war schon die neueste Version drauf. Also wollte ich via napp-it-Anleitung die orginialen VM-Tools installieren. Dazu einen Hinweis:

Die Erläuterung dafür ist noch für ESXi 5.5. Dort wird empfohlen sich die Tools aus einem Unterordner der ISO von der kompletten ESXi-Installation zu ziehen. Bei meiner ISO für 6.7 und der Free-Licence-Version ist nichts für Solaris enthalten, sondern nur für Linux, Windows und PreVistaWindows. Daher habe ich mir die ISO direkt für die VMware-Tools gezogen (bei Beitragserstellung 10.3.5) und mir dort die benötigen Dateien besorgt. Die Installation selbst kann dann wieder nach Anleitung durchgeführt werden. Die ESXi hat danach nicht mehr herumgemosert. Aber wichtiger ist, ich kann die Storage-VM vernünftig herunterfahren. Seitdem funktioniert auch das Monitoring in napp-it selbst, was ich nicht ganz verstehe, da es nach meinem bisherigen Verständnis für das Weiterreichen der Hardwareinfos von der ESXi egal ist, ob VMware-Tools genutzt wird oder nicht!?

Die LDAP-Anbindung ist nicht implementiert. Daher arbeite bzw. recherchiere ich wie ich das am Besten mit LDAP realisiert bekomme.

In den Beschreibungen ist zu lesen, dass das Passthrough von einer NIC empfohlen wird. Hier frage ich mich, ob das für meine Zwecke wirklich nützlich wäre? Denn ich nutze weniger die direkte Anbindung von Shares an andere, externe Geräte. Bei mir passiert das vielmehr über die diversen Dienste der VMs auf ESXi und von dort aus wird mit anderen Geräten auf Dateien zugegriffen. Wenn ich nun eine NIC zu napp-it durchleite, sähe doch der Weg von Dateien zu den anderen VMs wie folgt: Raus aus der ESXi zum Router und von dort aus wieder rein in die ESXi über die andere NIC. Oder sehe ich das falsch? Bringt mir das irgendeinen Vorteil? Wir reden hier von einem Gigabit- und nicht von einem 10G-LAN.

Nutzt zufällig jemand den Remote Desktop Manager von Devolutions als Admin-Interface für seine Systeme? Denn ich bekomme beim Autologin via Webinterface (Chrome, FF, IE) die Login-Schaltfläche nicht betätigt. Meine Konfiguration bezüglich den HTML-Steuerelementen sieht momentan so aus: Passwort = pass (Eintrag funktioniert), Login-Button = submit oder [SUBMIT] funktioniert beides nicht, obwohl die Schaltfläche so bezeichnet ist. Hat das jemand so konfiguriert bekommen, dass der Login-Klick nicht mehr notwendig ist?


[VMs]
Bisher hatte ich mehrere, im Internet nutzbare Dienste mit einer externen IP-Adresse vom Internetanschluss zur Synology durchgeleitet. Die Weiterleitung zum eigentlichen Dienst wurde dann über den Reverse Proxy vom DSM geregelt. Den Luxus habe ich jetzt nicht mehr und musste mir einen eigenen Reverse-Proxy aufsetzen. Hier empfehle ich bei der Systemplanung zu schauen, ob und wie die bevorzugten Dienste mit einem Proxy harmonieren. Gerade bei Sachen wie Nextcloud und Onlyoffice, wo der eine Dienst den anderen aufruft und dieser wiederum etwas zurückgibt, ist es gut, wenn dafür auch zusätzlich interne IP-Adressen konfiguriert werden können. Wenn nicht wird es gerade in Verbindung zusätzlicher SSL-Verschlüsselung der Dienst schnell kompliziert aber auch das funktoniert.

Ich habe den Reverse-Proxy im Moment mit Apache realisiert. Es ist aber möglich, dass ich auf nginx wechsle. Denn die GeoIP-Funktion habe ich dort noch nicht zum Laufen bekommen und es liest sich mit nginx einfacher zu realisieren. Es ist schließlich nur eine Frage der Zeit, bis einem die Bots auf die Pelle rücken.

Da es in diesem Forum hauptsächlich um Hardware und Serversysteme selbst geht, ist es erstmal genug mit meinem Erfahrungsbericht.

Ich danke euch für eure Tipps und Anregungen.

Gruß
keijko
 
Zuletzt bearbeitet:
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