[Kaufberatung] Mein erster NAS Eigenbau - Bitte um Kaufberatung

@jonofe: Ja das geht mit der 900P U.2. Kannst Du wie ne normale M.2 PCIe an ne Adapterkarte packen. Hab ich selber so; M.2-Adapterkabel war bei meiner 900p auch dabei (die 900p U.2 gibts in 2 Varianten mit U2-Kabel und U2-Adapterkabel auf M.2).
Hab die U.2-Version genommen, weil ich mit der einfach flexibler bin als in der Steckkartenvariante.

Ja das sehe ich jetzt auch so ;)

Leider hab ich die PCIe Variante schon gekauft und zwar vorgestern in Prag, da sie dort mehr als 100€ günstiger war, als das günstigste Angebot hierzulande.
Die U.2 Version kostet hier so ziemlich dasselbe wie die PCIe in Tschechien. Dumm gelaufen...
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ah okay, hatte gar nicht realisiert, dass es die 900p überhaupt in einer anderen Version als der PCIe Karte gibt. Hätte ich die U2 Version mit dem Adapter dann auch an eine "normale" PCIe M2 NVMe Adapterkarte anschließen können?

Ja
M.2, U.2 und PCI-e ist bei NVMe alles prinzipiell das gleiche,
nur jeweils andere Steckfassung
 
Hallo zusammen

Ich bin im Entscheidungsprozess ein wenig weiter und möchte mir mit folgender Hardware einen ESXi Host mit FreeNas & weiteren VMs zusammenstellen.
Gerne hätte ich nochmals eure Meinung dazu und 2-3 offene Fragen habe ich auch:

CPU: INTEL Xeon E3-1240 v6

Mainboard: Supermicro X11SSL-CF

Gehäuse: 4U - IPC-E420 bzw .Genesys E420B (ich habe mich für dieses Gehäuse entschieden, dass es nur 355mm tief ist, mein Rack hat nur 600mm Aussentiefe hat), 19" Server Gehäuse 4HE / 4U - IPC-E420 - Frontaccess / 35,5

RAM: Kingston ValueRAM Server Premier (2x) 16GB, DDR4-2400, DIMM 288) - das sollte zu Mainboard oben passen - oder? Muss ja unbuffered ECC sein.

Festplatten: Starten möchte ich mit 3x10TB als RAIDZ1 starten - die wichtigen Daten werden sowieso gebackuped. Das Ganze solle am SAS Controller vom Mainboard angeschlossen werden. Dazu benötige ich extra Kabel - oder? Bis jetzt hatte ich nie mit SAS Anschlüssen etwas zu tun.

Bootdevice: Ich hätte noch eine 2.5 Zoll SATA 256GB Samsung SSD - die könnte ich als Boot/Installation Device für ESXi und die Storage VM (sprich FreeNas) verwenden - mach das Sinn?

Netzteil: Für die Konfiguration sollte eine 300W NT reichen - oder? Evtl. kommen später nochmals 3-4 Disks dazu

Kühler für CPU: Taugt der Boxed Kühler etwas? Lärm spielt nicht so eine Rolle, da der Server im Keller stehen wird.




Vielen Dank für eure Hilfe.

Gruss
Alen
 
Das Problem bei dem Gehäuse ist halt, dass man 19" hat aber trotzdem keine schnell zugänglichen Backplanen für die Platten hat. Gleichzeitig auch keine Luftfilter.
Boxed Kühler sollte reichen.
NT kommt drauf an; Platten ziehen beim Anlaufen ziemlich. Ausserdem wird die Auswahl hocheffizienter NTs dünn bei 300W. Mein Standard-NT ist bislang immer ein Bequiet 400W Straight Power gewesen.
Ram brauchst Du unregistered, ja. Bei der Auswahl hab ich mich bei Supermicro bislang immer an deren Testliste zu nem Board gehalten.

Die 256er SSD (welcher Typ? einzig 840 Basic oder 840Evo wär ich etwas skeptisch für langfristige Zwecke; 840pro, jede 850, jede 860) kannst Du normal problemfrei als Boot und Datastore für die Storage-VM nehmen. Kannst dann dort ja auch ISO-Kopien für schnelle Installation von VMs ablegen oder ggf. auch temporäre VMs draufpacken; hin- und wieder hab man zum Spielen da mal schnell sachen die nicht über ZFS gesichert und verwaltet werden müssen.
Beachte jedoch, dass wenn Du vom Onboard-Sata bootest, kannst Du den Onboard-Satacontroller nicht mehr in die Storage-VM durchreichen. D.h. alle 5 restlichen Sata-Ports sind für ZFS verloren *1. Für den Fall, dass Du mal mehr Ports als die vom SAS brauchst. Insbesondere, wenn Du mit SSDs mal nen ZFS-Pool für viel Random-I/O bauen willst, werden die Sata-Ports dann interessant für ZFS, weil die Latenz für kleine I/O-Blocks besser ist als via SAS-Controller.


*1) es sei denn, Du stoppselst mit Sata-RDM (einzelne Platten in die VM reichen) rum. Das kann funktionieren, muss aber nicht. Ist nicht wirklich ratsam bei Sata.
 
Zuletzt bearbeitet:
Der große Nachteil von einem Datastore der via iSCSI vs NFS ist von einer Storage-VM bereitsgestellt wird ist, daß bei einem Reboot von ESXi dieser noch nicht verfügbar ist, da ja die Storage-VM erst gestartetd werden kann, wenn ESXi fertig gebootet ist.
Schon mal probiert eine Autostartreihenfolge mit Verzögerungen festzulegen, so dass die Storage-VM läuft, wenn die nutzenden VMs gestartet werden?
 
Schon mal probiert eine Autostartreihenfolge mit Verzögerungen festzulegen, so dass die Storage-VM läuft, wenn die nutzenden VMs gestartet werden?
Klappt bei NFS aber bei iSCSI wartest du auf den Sankt Nimmerleinstag, denn bei NFS wird der Storage auch bei verzögerter Verfügbarkeit automatisch verbunden.
Bei iSCSI muß das Target beim Start von ESXI Online sein, es wird nicht automatisch bei verzögerter Verfügbarkeit verbunden und muß in dem Falle manuell wieder neu verbunden werden.
 
Die 256er SSD (welcher Typ? einzig 840 Basic oder 840Evo wär ich etwas skeptisch für langfristige Zwecke; 840pro, jede 850, jede 860) kannst Du normal problemfrei als Boot und Datastore für die Storage-VM nehmen. Kannst dann dort ja auch ISO-Kopien für schnelle Installation von VMs ablegen oder ggf. auch temporäre VMs draufpacken; hin- und wieder hab man zum Spielen da mal schnell sachen die nicht über ZFS gesichert und verwaltet werden müssen.
Beachte jedoch, dass wenn Du vom Onboard-Sata bootest, kannst Du den Onboard-Satacontroller nicht mehr in die Storage-VM durchreichen. D.h. alle 5 restlichen Sata-Ports sind für ZFS verloren *1. Für den Fall, dass Du mal mehr Ports als die vom SAS brauchst. Insbesondere, wenn Du mit SSDs mal nen ZFS-Pool für viel Random-I/O bauen willst, werden die Sata-Ports dann interessant für ZFS, weil die Latenz für kleine I/O-Blocks besser ist als via SAS-Controller.


*1) es sei denn, Du stoppselst mit Sata-RDM (einzelne Platten in die VM reichen) rum. Das kann funktionieren, muss aber nicht. Ist nicht wirklich ratsam bei Sata.

Ich glaube es ist eine 850er. Muss mal nachschauen.

Aber du hast Recht, es macht wohl mehr Sinn, den SATA Controller nicht für das ESXI zu benutzen/"verschwenden".

Wäre diese SSD etwas für mich? Ich glaube 128GB sollten reichen für ESXI und die FreeNas-VM - oder?

Intel SSD 600p 128GB ab Preisvergleich Geizhals Deutschland


Aber wie würde ich das Ding bei meinem Mainboard Supermicro X11SSL-CF anschliessen - das hat ja keinen M.2 slot

IMHO gäbe dann zwei Möglichkeiten
  • ich könnte die SSD via einem PCI - M.2 Adapter anschliessen
  • Oder ich stecke die SSD in ein USB Case/Stick und schliesse es dann an einem USB 3 Port?

Was ist sinnvoller?

Oder würde einfach ein "normaler" USB Stick reichen, um EXSI und die FreeNas VM zu hosten?

Lieber Gruss
Alen
 
Klappt bei NFS aber bei iSCSI wartest du auf den Sankt Nimmerleinstag, denn bei NFS wird der Storage auch bei verzögerter Verfügbarkeit automatisch verbunden.
Bei iSCSI muß das Target beim Start von ESXI Online sein, es wird nicht automatisch bei verzögerter Verfügbarkeit verbunden und muß in dem Falle manuell wieder neu verbunden werden.
Das sollte aber ein lösbares Problem sein.

Unter Windows mit der PowerCLI würde ich das so lösen:
Code:
Get-VMHost | Get-VMHostStorage -RescanAllHba
PowerCLI One-Liner Rescan All HBA vBrownBag

Das müsste mit esxcli aber genauso gehen. Also aus der VM heraus ein Rescan auf dem Host antriggern, sobald das Target bereitsteht.

Für die nicht kommerziellen Versionen würde ich ssh verwenden und den Aufruf dann quasi lokal machen.

Die Automatisierungs-APIs sind eine der großen Stärken von ESX. Es gibt praktisch nichts, was man damit nicht verwirklichen kann. Das macht man dann idealerweise nicht auf dem Host sondern in einer Appliance-VM.

Für mich war das Rescan nie ein echtes Problem da der ESX-Host sowieso nur extrem selten und dann kontrolliert für Wartungszwecke im Wartungsmodus gebootet wird. Da sind sowieso ein paar händische Schritte notwendig.

Für eine gute ESX-Integration des Speichers ist es wichtig, dass der Storage-Anbieter die VAAI Schnittstelle möglichst gut bedient. Leider gibt es das nicht in der kostenfreien Variante von ESX. Das ist einer der Gründe, warum ich immer wieder bei iSCSI gelandet bin, weil ich dort wenigstens das Write Same/Block Zero über das Dateisystem vmfs geschenkt kriege.
 
Schon mal probiert eine Autostartreihenfolge mit Verzögerungen festzulegen, so dass die Storage-VM läuft, wenn die nutzenden VMs gestartet werden?
Bei mir (AIO mit ESXi 6.5 sowie OmniOS-VM als storage) funktioniert das nicht recht, da ESXi immer schon alle VMs starten möchte, sobald OmniOS gebootet wurde - dann findet er sie aber natürlic noch nicht. Habe da verschiedene Werte ausprobiert ohne Erfolg - was ist denn Deine funktionierende Konfiguration? Ich kann gerne ein paar Minuten warten, bis alle VMs online sind ...
 
Bei mir (AIO mit ESXi 6.5 sowie OmniOS-VM als storage) funktioniert das nicht recht, da ESXi immer schon alle VMs starten möchte, sobald OmniOS gebootet wurde - dann findet er sie aber natürlic noch nicht. Habe da verschiedene Werte ausprobiert ohne Erfolg - was ist denn Deine funktionierende Konfiguration? Ich kann gerne ein paar Minuten warten, bis alle VMs online sind ...
Du musst für die OmniOS VM ein langes Startup Delay konfigurieren. Z.B. 720 Sekunden. D.h. vom Start der OmniOS VM gemessen wird 720 Sekunden später die nächste VM in der Startreihenfolge gestartet. Ab da kannst Du dann wieder kleinere Werte angeben.

Bei meinen Heim-Servern steht die Virtualisierung im Vordergrund. Daher möchte ich das knappe RAM nicht für Storage VMs einsetzen. Folglich kommen bei mir gebrauchte MegaRAID Controller mit Cache zum Einsatz. VMs landen auf einem SSD-RAID, Datenmassen auf einem HDD-RAID. Die Idee mit der Storage-VM finde ich aber spannend und da die Hardware-Limits hinsichtlich RAM immer weniger einschränken, auch zunehmend interessanter. Aber hier ging es ja um den Bau eines NAS. Von daher ist mein Setup da nicht repräsentativ.
 
Du musst für die OmniOS VM ein langes Startup Delay konfigurieren.
Danke! Ich habe es immer "falsch herum" gemacht: kurzes delay für OmniOS, langes delay für die weiteren VMs, weil ich dachte, das sei die Verzögerung bis zum Start der betreffenden (und nicht der nachfolgenden) VM. Merci und Entschuldigung für das Kapern des threads.
 
Schon richtig mit kurzem Delay für OmniOS

Das Problem ist doch.
Sobald ESXi gestartet ist, möchte es seine Datastores mounten und dann die VMs hochfahren.

Die Storage-VM kann sofort gestartet werden. Die liegt ja auf lokalem Datastore. Die anderen VMs liegen jedoch auf ZFS SAN Storage (NFS oder iSCSI). Bei NFS ist es so, dass das entsprechende Datastore von ESXi gemounted wird, sobald es (verzögert von OmniOS) zur Verfügung gestellt wird. Die darauf liegenden VMs können dann automatisch und mit etwas Verzögerung hochgefahren werden.

Ein iSCSI Datastore wird nicht automatisch verzögert gemountet (so war es zumindest bisher bei ESXi, egal wie lange man wartet). Wenn das beim Start von ESXi nicht zur Verfügung steht (was nicht geht da es erst von der OmniOS VM mit Verzögerung bereit gestellt wird), muss es anschließend manuell gemountet werden. Wenn da VMs drauf liegen können die natürlich immer erst gestartet werden nachdem der Datastore zur Verfügung steht.
 
Schon richtig mit kurzem Delay für OmniOS

Das Problem ist doch.
Sobald ESXi gestartet ist, möchte es seine Datastores mounten und dann die VMs hochfahren.

Die Storage-VM kann sofort gestartet werden. Die liegt ja auf lokalem Datastore. Die anderen VMs liegen jedoch auf ZFS SAN Storage (NFS oder iSCSI). Bei NFS ist es so, dass das entsprechende Datastore von ESXi gemounted wird, sobald es (verzögert von OmniOS) zur Verfügung gestellt wird. Die darauf liegenden VMs können dann automatisch und mit etwas Verzögerung hochgefahren werden.

Ein iSCSI Datastore wird nicht automatisch verzögert gemountet (so war es zumindest bisher bei ESXi, egal wie lange man wartet). Wenn das beim Start von ESXi nicht zur Verfügung steht (was nicht geht da es erst von der OmniOS VM mit Verzögerung bereit gestellt wird), muss es anschließend manuell gemountet werden. Wenn da VMs drauf liegen können die natürlich immer erst gestartet werden nachdem der Datastore zur Verfügung steht.

So wie ich asche77 verstanden habe, ging es gar nicht um NFS oder iSCSI, sondern darum, dass der Autostart der VMs die auf dem SAN liegen nicht funktioniert hat. Das klappt nicht, wenn das Startkommando kommt, bevor der Speicher bereit ist. Daher muss die Storage-VM ein Start delay bekommen das lang genug ist für das Hochfahren und die maximale Zeit, die das NFS-Polling des Hosts benötigt, um den Speicher als Bereit zu melden.

Bei ESX ist es so, dass die Idee hinter dem "Start Delay" die geschätzte Zeit ist, die eine Maschine zum Hochfahren benötigt. Damit kann man die Startreihenfolge problemlos umsortieren ohne Werte anpassen zu müssen. Das ist erstmal unintuitiv, aber wenn man das Umsortieren mit in die Überlegung aufnimmt durchaus sinnvoll.
 
darum, dass der Autostart der VMs die auf dem SAN liegen nicht funktioniert hat. Das klappt nicht, wenn das Startkommando kommt, bevor der Speicher bereit ist. Daher muss die Storage-VM ein Start delay bekommen das lang genug ist für das Hochfahren und die maximale Zeit, die das NFS-Polling des Hosts benötigt, um den Speicher als Bereit zu melden.
Genau das: Start der nachfolgenden VMs schlug fehl, da der NFS-share noch nicht bereit war (und ESXi sie daher nicht finden konnte). Einmal Start fehlgeschlagen = kein neuer Versuch, auch wenn später der NFS share online kommt und dann automatisch von ESXi gesehen wird.
 
Könnte mir jemand noch betreffend meiner Frage in Post 37 weiterhelfen?

Wie würde ich die M2 SSD: "Intel 600p Series - 128GB" am besten an das Mainboard Supermicro X11SSL-CF anschliessen? Mit einem M2-PCIe Adapter? Welcher? Er muss ja unter ESXi laufen bzw kompatibel sein.

Vielen Dank

Gruss
Alen
 
PCIe ist sinnvoller da 1. (unwichtig) schneller und 2. (wichtig) stabiler als USB und 3. einfacher: ESXI als USB geht gut, VMStore auf USB nur mit etwas "Handarbeit".

Edit: checken ob Du von PCIe booten kannst. Alternativ (Unterstützung Serverzusammenstellung - ESXI / ZFS / NAPP-IT /) den ESXI vom USB Stick booten und den VMStore auf der PCIe SSD ablegen.
 
Zuletzt bearbeitet:
Wie würde ich die M2 SSD: "Intel 600p Series - 128GB" am besten an das Mainboard Supermicro X11SSL-CF anschliessen? Mit einem M2-PCIe Adapter? Welcher? Er muss ja unter ESXi laufen bzw kompatibel sein.

z.B. mit Inter-Tech KT016

Ich habe dasselbe Board mit o.g. Adapter und auch mit der Intel 600p 128GB in Betrieb gehabt. Zu Weihnachten musste diese Kombi einer Intel Optane 900p 280GB weichen.

Meine Server Konfiguration kannst du hier sehen. Alles was du dort siehst läuft perfekt zusammen.
 
Das sollte aber ein lösbares Problem sein.

Unter Windows mit der PowerCLI würde ich das so lösen:
Code:
Get-VMHost | Get-VMHostStorage -RescanAllHba
PowerCLI One-Liner Rescan All HBA vBrownBag

Windows =! ESXi

Das müsste mit esxcli aber genauso gehen. Also aus der VM heraus ein Rescan auf dem Host antriggern, sobald das Target bereitsteht.

Für die nicht kommerziellen Versionen würde ich ssh verwenden und den Aufruf dann quasi lokal machen.

Die Automatisierungs-APIs sind eine der großen Stärken von ESX. Es gibt praktisch nichts, was man damit nicht verwirklichen kann. Das macht man dann idealerweise nicht auf dem Host sondern in einer Appliance-VM.

Für mich war das Rescan nie ein echtes Problem da der ESX-Host sowieso nur extrem selten und dann kontrolliert für Wartungszwecke im Wartungsmodus gebootet wird. Da sind sowieso ein paar händische Schritte notwendig.

Da ein entsprechendes Feature/Script o-ä- nicht einmal bei Gea's Napp-In-One Konzept - geschweigen denn bei FreeNAS, XigmaNAs etc. - zur Verfügung steht, scheint das ganze wohl eher nicht so trivial zu sein wie von dir dargestellt.
Es wäre natürlich durchaus möglich, daß diese Möglichkeit von Gea übersehen wurde - von wegen Wald und Bäume.

Für eine gute ESX-Integration des Speichers ist es wichtig, dass der Storage-Anbieter die VAAI Schnittstelle möglichst gut bedient. Leider gibt es das nicht in der kostenfreien Variante von ESX. Das ist einer der Gründe, warum ich immer wieder bei iSCSI gelandet bin, weil ich dort wenigstens das Write Same/Block Zero über das Dateisystem vmfs geschenkt kriege.
Das hat genau was mit dem geschilderten Problem zu tun?
 
Zuletzt bearbeitet:
Für mich stellt sich die Frage so
- Sollte ich Basisfeatures von ESXi in das napp-it Web-UI integrieren?

Für mich ist die Antwort klar nein.
Im ESXi Webclient steckt zu viel drin, das geht nich und VMware macht einem das zu schwer.

- oder sollte napp-it ESXi soweit unterstützen, dass ein ESXi Vsphere Server den Storage zumindest rudimentär managen kann (VAAI). Die Antwort ist für mich auch nein. Sobald es um mehr als VM Management geht, ist der Vspher Server überfordert und man muss eh den Storage direkt managen. ESXi kann und erwartet storagemäßig einfach zu wenig.

Ich trenne VM Server und Storage lieber komplett. Die einzige Stelle wo es Abhängigkeiten gibt sind ESXi Hot Memory Snaps. Sonst trenne ich das lieber komplett - eben KISS - keep it simple. Wenn was nicht geht ist sofort klar wo das Problem liegt.
 
z.B. mit Inter-Tech KT016

Ich habe dasselbe Board mit o.g. Adapter und auch mit der Intel 600p 128GB in Betrieb gehabt. Zu Weihnachten musste diese Kombi einer Intel Optane 900p 280GB weichen.

Meine Server Konfiguration kannst du hier sehen. Alles was du dort siehst läuft perfekt zusammen.

Jonofe, darf ich fragen wieso du dich für E3-1245 (mit intrgrierter GraKa) entschieden hast? Ok kostet ja nur minimal mehr. Ich wollte mir eigentlich den E3-1240 kaufen...weil ja "unser" Mainboard IPMI hat...braucht man da noch eine GraKa??
 
Hallo zusammen

So es ist alles bestellt - nur die Festplattenkabel und das Netzteil fehlen noch.

Betreffend Festplatten Kabel:
Ich möchte ja 3 SATA Disks am SAS Controller des Supermicro X11SSL-CF anschliessen. Welche Stecker brauche ich nun für das Mainboard SAS Controller? SSF-8087 oder SFF-8643?
Wäre so was ok ? D.h. ich könnte damit 4 SATA Disks an einem SAS Port anschliessen?

Netzteil.

Wäre dieses be Quiet! PC Netzteil ATX 400W System Power 9 BN245 / be Quiet! PC Netzteil ATX 400W System Power 9 BN245: Amazon.de: Computer Zubehör ok ?
Also die 400W Version. Ich möchte 3 HDs betreiben und eine kleine 2.5'' SSD. Es muss nicht so leise sein...das Gehäuse steht ja im Rack im Keller.

vielen Dank !

Alen
 
ok danke, ist bestellt...jetzt benötige ich nur noch das Netzteil...
 
ich verbaue nur noch Netzteil mit Kabel Mangement, deshalb "be quiet! Pure Power 11 CM"
in einem Server brauche ich keine GPU Power Kabel und auch andere Anschlüsse
 
Ich überlege mein verhasstes Seagate 2-Bay NAS durch eins Marke Eigenbau zu ersetzen. Auf dem NAS sind nur Bilder, Dokumente und Musik. Laufen soll es im Raid 1.

Vorhanden sind zwei 4TB HDDs die ich verwenden möchte.

Das System:
Mini NAS mit M.2.JPG


Was haltet ihr davon?

Soll ein "Budget" NAS werden ^^
 
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