[Kaufberatung] Mein erster NAS Eigenbau - Bitte um Kaufberatung

[alen]

Hallo zusammen
Mein in die Jahre gekommenes – und nicht mehr updatefähige Synology NAS soll ersetzt werden mit einem NAS Eigenbau – wahrscheinlich basierend auf FreeNAS

Wozu ich das NAS verwenden möchte

• Datengrab für Filme, Photos, Speicher für VM’s, Datenbank etc. (Starte würde ich gerne mit 10TB-15TB)
• Filme abspielen via Plex/TV
• Filme via Dreambox aufzeichen
• Diverse Überwachungskameras soll ebenfalls aufs NAS aufzeichen
• Diverse kleinere Linux VMs sollen ebenfalls auf/in Freenas laufen (als VM in Bhyve oder jails),z.B. für Hausautomatisierungsprojekte mittel FHEM, iobroker etc
• Evtl auch ein VM in der Window Server läuft (zum "Rumspielen") => Tendenz für 32GB RAM?
• Vielleicht auch pfSense...

Was ich denke was ich an Hardware brauche, bzw. wo ich noch Fragezeichen haben:


MAINBOARD
Ich habe das Supermicro X11SSL-F gemäss Hardware Guide 2018 ins Auge gefasst. Ich möchte unbedingt IPMI. Das NAS wird einem Keller in ein Rack eingebaut. Ich möchte dort keine Tastatur/Maus anschliessen müssen. Auch soll das Mainboard die VT/VT-d, da ich bin mir aber nicht ganz sicher ob das das X11SSL-F kann?!

CPU:
Benötige ich für meine Anforderungen einen der günstigeren Xeon X3? Eigentlich möchte auch noch ein wenig Luft nach oben haben. Oder würde evtl. sogar ein Celeron, z.B. G4900 reichen?

Noch eine ganz wichtige Frage zur CPU im Zusammenhang mit dem IPMI. Benötige ich diesem Fall überhaupt noch eine CPU mit GPU? Wenn ich es richtig verstehe sollte das Supermicro Mainboard mit IPMI ja eine intergrierte Onboard GPU haben, stimmt das?


MEMORY:
RAM starten würde ich mit 1x 16GB ECC RAM oder evtl. 32GB (also 2x). Wenn ich auf dem Sockel 1150/1151 bleibe wären ja maximal 64GB möglich, oder? Welches RAM würdet ihr mir konkret empfehlen für das Supermicro Mainboard?


GEHÄUSE
Ich habe ein Digitus Rack im Keller mit 20HE. Dort wäre noch reichlich Platz für ein Gehäuse im 19‘‘ Format (z.B. HE). Das Problem ist jedoch die Einbautiefe. Das Rack ist 600mm tief. Ich denke die verfügbare Einbautiefe (netto) wäre maximal 400-450mm. Welches Rackgehäuse könntet ihr mir in diesem Bereich empfehlen? Z.B. so was:
19" Server Gehäuse 4HE / 4U - IPC-E420 - Frontaccess / 35,5
Lautstärke spielt keine Rolle. Weil das Ding im Keller steht..und Hitzeentwicklung hoffentlich auch nicht…weil es im Keller eher kühl ist.

Was haltet ihr von dieser Zusammenstellung ? Bin ich auf dem richtigen Weg…oder gibt es Verbesserungsvorschläge?

(Ich mich mir auch noch Gedanken machen, welche Disks, Netzteil und Systemdisk ich nehmen soll)

Lieber Gruss
Alen

 

[gea]

Beste Unterstützung für beliebige Gäste und den geringsten Resourcenverbrauch für die Virtualisierung bietet ESXi

Ob ein Celeron reicht?
Klar reicht der so wie ein Golf es auch tut. Ein Audi/BMW/Porsche ist halt schneller

Alle SuperMicro mit Intel C- Chipsatz können ECC und vt-d
Zum Speicher: Speichersuche – Zum Finden des richtigen Speichers | Kingston

FreeNAS braucht eventuell mehr RAM als andere NAS VMs.
Ich würde aber keine Extra Dienste auf die NAS VM packen sondern auf eigene VMs.
NAS läuft dann immer auch dann wenn alles andere zickt.

 

[XN04113]

wenn vier 3.5" HDD Plätze reichen: 2U 2404S - Inter-Tech GmbH
sollen es acht sein: 4U 4408 - Inter-Tech GmbH

 

[alen]

Beste Unterstützung für beliebige Gäste und den geringsten Resourcenverbrauch für die Virtualisierung bietet ESXi



FreeNAS braucht eventuell mehr RAM als andere NAS VMs.
Ich würde aber keine Extra Dienste auf die NAS VM packen sondern auf eigene VMs.
NAS läuft dann immer auch dann wenn alles andere zickt.

Freenas in ESXi laufen zu lassen ist somit überhaupt kein Problem? Gibt es diesbezüglich etwas Spezielles zu beachten, insbesondere soll ja auch ZFS funktionieren und RAID

 

[gea]

Alls ich vor 10 Jahren die Idee eines virtualisierten Storage für Solarish (AiO) vorstellte kam aus dem FreeNAS Lager völlige Ablehnung dieses Konzepts. Inzwischen ist die Idee auch unter FreeNAS üblich. Man sollte bei FreeNAS aber mit etwas mehr RAM rechnen als bei Solarish basierten Lösungen.

 

[wenzilinho]

Gibt es diesbezüglich etwas Spezielles zu beachten, insbesondere soll ja auch ZFS funktionieren und RAID

Du musst der VM einen eigenen Sata-Controller durchreichen, damit sie direkt auf die Platten zugreifen und das ZFS RAID erstellen kann.

 

[gea]

Eine VM hat drei Möglichkeiten auf Platten zuzugreifen

1. virtuelle Platten (ESXi vmdk). Das sind Dateien auf dem ESXi Datastore
2. Physical Raw Disk Mapping. Eine VM hat direkten Plattenzugriff über den Umweg ESXi Plattentreiber
3. Pass-through. Hier wird ein Plattencontroller direkt an die VM gegeben. Die nutzt den eigenen Treiber für den Controller

Für ein NAS kommt eigentlich nur 2. und 3. in Betracht. Für professionelle Ansprüche nimmt man 3.
Bei 2. und 3. hat man idealerweise einen LSI SAS HBA.

Bei 2. kann man mit einem SAS HBA Platten (Sata oder SAS) direkt in der Web-Gui bereitstellen (VM Eigenschaft, add raw disk).
Raw disk mapping für Sata wird von ESXi nicht unterstützt, geht aber über die Console.

 

[BOFH_90]

Ich würde einfach Proxmox mit ZFS nehmen. Damit ist das NAS in den Hypervisor integriert und alles opensource im vergleich zum esxi.

 

[jonofe]

Ich hatte mehr oder weniger dieselbe Herausforderung und habe es mit folgender Konfiguration gelöst:

https://geizhals.de/?cat=WL-879616

Das X11SSL-CF Board hat den Vorteil, dass es einen HBA on board mitbringt, den man an die NAS VM durchreichen kann. Funktioniert aber inzwischen mit ESXI 6.7 auch wieder mit dem on board SATA Controller. Ich bin super zufrieden und habe den Speicher inzwischen auf 48GB ausgebaut, so dass jetzt ca. 10VMs problemlos laufen.

In der Liste kannst du auch den kompatiblen RAM sehen.

 

[gea]

Damit ist das NAS in den Hypervisor integriert und alles opensource im vergleich zum esxi.

Genau diese Integration ist etwas was ich unbedingt vermeiden möchte. Egal ob mit Proxmox oder jeder anderen Lösung wie Virtualisieren auf dem NAS, egal ob FreeNAS oder OmniOS, selbst mit Bhyve oder Linux Zonen.

Wenn das Basisbetriebssystem (bei Proxmox sogar ein vollwertiges Debian Linux), Virtualiiserungsumgebung, Gäste und ihre Dienste eine Einheit bilden, so sorgt jedes Problem dafür daß das Gesamtkonstrukt Probleme bekommt und eventuell komplett neu aufgesetzt werden muss und man sich um Disaster Recovery Konzepte Gedanken machen muss.

Das schöne an ESXi + Storage VM + weitere VMs mit Diensten ist ja gerade deren völlige Unabhängigkeit, insbesondere was die Basisfunktionen Virtualisierer und Storage angeht. Die sind so einfach dass man sich für ESXi und Storage VM nicht mal Gedanken um Backup machen muss da sie innerhalb einer Viertelstunde neu aufgesetzt sind. Backup ist nur für VMs nötig und da recht einfach mit ZFS.

 

[VirtuGuy]

Das schöne an ESXi + Storage VM + weitere VMs mit Diensten ist ja gerade deren völlige Unabhängigkeit, insbesondere was die Basisfunktionen Virtualisierer und Storage angeht. Die sind so einfach dass man sich für ESXi und Storage VM nicht mal Gedanken um Backup machen muss da sie innerhalb einer Viertelstunde neu aufgesetzt sind. Backup ist nur für VMs nötig und da recht einfach mit ZFS.

Nachdem du ein Henne-Ei Problem hast, bleibt dir im Fehlerfall nichts anderes übrig außer umständlich neu zu installieren. Wenn der Hypervisor auf ZFS läuft, kann ich im Fall der Fälle einfach einen alten Snapshot nutzen und spare mir den ganzen Aufwand.

 

[gea]

VMs auf ZFS, jedes mit seinen eigenen Snaps/Versionierung ist eine Sache, das OS selber eine andere.

Ich arbeite jetzt seit über 10 Jahren mit ZFS und Bootenvironments unter Solarish, also ZFS Snaps als bootfählge Clones. Ich weiß jetzt nicht inwieweit bootfähige ZFS Snaps jetzt bei Proxmox und ZoL bereits umgesetzt sind aber selbst bei OmniOS wo das perfekt realisiert ist, hatte ich kürzlich das Problem dass nach einem Update auf die neueste 151028 bei dem sowohl Open-SSH wie auch Perl erneuert wurde manches wie TLS Alertmail nicht mehr liefen. Bevor ich mich dem Problem tagelang widme habe ich OmniOS neu installiert (ein paarmal ok klicken und den napp-it Installer starten). Nach 20 Minuten läuft Storage wieder auf Hardware. Unter ESXi hätte ich das Template neu installiert was eher schneller wäre. Selbst ESXi wäre in 10 Minuten neu installiert. Überall nur Minimalstinstallation. Meine Bootenvironments haben da garnichts genützt, ich will ja das Update.

Hätte ich jetzt unter OmniOS noch zig VMs wäre das selbst mit LX Zonen und Bhyve nochmal ein Extra Aufwand. Bei ESXi ist ein VM Import selbst nach kompletter Neuinstallation ein Rechts-Mausklick im ESXi Dateibrowser auf die .vmx Datei der VM. Die VMs liegen bei AiO immer auf ZFS.

 

[alen]

hall zusamme

Noch ein paar Fragen:

1. Nur zur Verständnisfrage, da ich noch ziemlich ein Neuling auf diesem Gebiet bin , was genau meint ihr mit Storage VM? Ist das die VM, in der das NAS OS (z.B. FreeNas) läuft, bzw. wo der meiste Festplattenspeicher hinzugefügt wird?

2. @Gea: In deiner vorgeschlagen Lösung mit ESXi als Hypervisor und diversen VMs als Guests (unter anderem FreeNas)..was würde passieren, wenn die ESXi Installation irgendwie "beschädigt" wird..läuft dann überhaupt noch eine der VM's oder wäre alle tot? Wie würde man die ESXi Installation wieder 'restoren' bzw. flicken, so dass die darunter liegenden VMs wieder laufen?

3. Und noch eine Frage zu den Festplatten und deren Aufteilung.

Sagen wir mein Server hat 3 Festplatten à 10 TB.
- Sinnvoll wäre es dann ESXi auf einem USB Stick oder SD Card zu installieren.Da es relativ wenig Platz benötigt - oder?
- Die 3 Festplatten würde ich dann komplett (sprich 30TB) via SAS HAB der FreeNas VM durchreichen. Diese bilden dann dort einen ZFS/RAID Verbund.
- Wo installiere ich meine anderen VMs (z.B. Windows Server, kleine Linux VM's). Brauche ich dazu weitere physische Festplatten im System? Oder kann ich von den 3 Festplatten nur insgesamt 20 TB an die FreeNAS VM durchreichen und 10 TB für die restlichen VMs benutzen?

Edit:
4.
Wo ich nicht ganz durchblicke ist, wie das ganze Setup bezüglich Ausfallsicherheit bei EINER Festplatte über den ganzen EXSi Server hinweg gesehen funktionieren soll. Meine Anforderung ist eigentlich, dass wenn EINE meiner insgesamt n Festplatten ausfällt, alles normal mal weiterläuft und ich nur die defekte Festplatte durch eine neue ersetzen muss – so halt wie halt bei einem RAID5 System.
Wie genau würde das mit ESXi, eine FreeNas VM und anderem VMs funktionieren?



Vielen Dank und Gruss
Alen

 

[Trambahner]

Das Konzept läuft wie folgt:

1a. ESXI auf USB-Stick installieren, von dem wird gebootet. Alternativ von ner kleinen zuverlässigen Sata-SSD.
1b. Du fügst dem ESXI einen kleinen Datastore hinzu, auf dem die Storage-VM Platz findet. Bei 1a=USB-Stick brauchst Du noch eine Sata-SSD oder eine PCIe-SSD.

2. In der Storage VM installierst Du das Storage-OS. Solarish+napp-it z.B. oder Xigmanas/Freenas. An diese VM reichst Du den SAS-Controller per vt-d Passthrough durch.
Hast Du bei Punkt 1 eine PCIe-SSD, kannst Du ggf. auch den Sata-Controller (kann, muss aber nicht klappen) durchreichen; an dem hängt dann ja kein Datastore des ESXI.

3a. In der Storage-VM richtest Du deine ZFS-Storageumgebung ein und gibts NFS-Shares oder iSCSI-Devices frei. NFS ist gut für den Einstieg.
3b. ESXI fügst Du dann als Netzwerk-Datastore dieses NFS-Share hinzu. ESXI nimmt dies genauso als wie von einem externen Storage-System.

4. Auf diesem Datastore, angebunden durch NFS auf den ZFS-Pool, kannst Du dann Deine restlichen VM's installieren. Da der Netzwerkdatenstrom dann innerhalb der ESXI-Kiste bleibt, auf dem virtuellen Switch, bist Du nicht limitiert durch den Durchsatz der physikalischen Netzwerkkarten sondern nur durch die CPU- und Storageleistung.

Wichtig: ESXI über NFS nutzt sogenannete Synchronous Writes auf den Netzwerkspeicher, in diesem Fall die Storage VM. Sync Writes commitet ZFS erst, wenn wirklich die Daten gesichert auf dem Pool gespeichert sind. Dementsprechend langsam kann das werden. Willst Du das beschleunigen, kannst Du "sync=disabled" setzen (damit hebelst Du aber die Sicherstellung ZFS-Integrität teilw. aus) oder aber kannst ein schnelles sog. SLOG-Device hinzufügen. Eine Intel Optane 800p/900p/905p bietet sich dafür an. Nicht auf die Idee kommen, billige Consumer-SSDs dafür nehmen zu wollen.

Da ESXI und ggf. die Storage-VM schnell installiert sind, und der ZFS-Pool ja die Haupt-VMs und Daten ja weiter beibehält, kann man diese mit wenigen Klicks in eine neue ESXI-Installation wieder einhängen.
So nebenbei kannst Du damit deine "Haupt-VM"s einfach snapshotten, backuppen, zurückrollen; was auch immer ZFS drauf hat. Desweiteren natürlich die bewährte ZFS-Datenintegrität.


PS: Ich hab so ein Setup mit X11SSH-CTF am laufen (dazu einen Dell T20 als Backup-Ziel) . Siehe meine Systeminfo . Dieses Board ist quasi die Supermicro 115x-"Wollmilchsau" der letzten Generation.

Das schöne an dem kleinen Sockel 115x ist, das die Plattform (bei geeigneter Hw-Auswahl) im Leerlauf richtig schön sparsam ist, aber bei Anforderung von Leistung (solange wenige Kerne reichen) trotzdem relativ hoch takten kann. Und das bei überschaubaren Hw-Kosten.
Nachteil: maximal 32-64GB Ram (ggf. demnächst 128GB bei der aktuellen Plattform Xeon E je nach Board), relativ wenige PCIe-Slots/Lanes.

 

[gea]

1. Eine traditionelle Serverlandschaft besteht aus einem oder mehreren Virtualisierungsservern und einem oder mehreren Storageservern. Früher waren das mehrere eigenständige Systeme/Rechner.

Ein All-in-One System fasst nun VM-Server und ZFS Storageserver zusammen indem der Storageserver auch virtualisiert wird. Als ich vor 8 Jahren mit der Idee aufkam wurde das von einigen allen voran aus dem FreeNAS Lager als Schwachsinn und der direkte Weg ins Datenchaos beschrieben. Zwischenzeitlich ist das anerkannt Stand der Technik.

Meine Idee basiert darauf dass nur eine minimalistische Storage VM virtualisiert wird die per pass-through direkten Zugriff auf Storagehardware hat. Nur diese VM wird auf einem ESXi Datastore (lokale Sata Platte) bereitgestellt.

Der eigentliche Storage wird von der ZFS Storage-VM gehandelt. Alle Produktiv-VMs liegen dann auf ZFS das per NFS/Netzwerk Dateisystem bereitgestellt. Das gesamte Storage-Handling macht die darauf spezialisierte VM.


2. Wenn die Storage VM defekt ist (was mit Bootfähigen Snaps vor allem unter Solarish selten passiert), so genügt es unter ESXi das Storage VM Template erneut bereitzustellen und den ZFS Pool zu importieren, NFS zu aktivieren. Wer meinem Ratschlag folgt, keine sonstigen Dienste auf der Storage VM zu installieren ist nach 5-10 Miniten wieder online (nach Crash der Storage VM). Crasht ESXi nimmt man einen vorbereiteten Boot-Clone (auch USB Stick) oder installiert neu (10 Minuten), stellt die Storage VM mit NFS bereit und importiert die VMs (ESXi Dateibrowser, Maus rechtsklich auf die .vmx und ins Inventar aufnehmen)

3. viele Wege führen nach Rom
Ich würde eine Sata SSD zu Booten nehmen (Intel Datacenter DC 3510 ab 80GB o.ä.) mit ESXi darauf und der Storage VM, sonst nichts

Aus den 10TG Platten würde ich einen 3x Mirror bauen (beste iops) oder ein Z1


4. Ausfallsicherheit der Daten betrifft ausschließlich die Storage VM mit ZFS
Wenn man mit Free-BSD arbeiten möchte wäre eventuell XigmaNAS besser (nicht so fett wie FreeNAS, man sollte die NAS "Extras" eh tunlich bei "Produktiv-Storage" meiden wie der Teufel das Weihwasser). Mein Favorit ist natürlich Oracle Solaris (Natives ZFS, da kommts her) oder die freien Solaris Forks wie OmniOS OmniOS Community Edition mit oder ohne mein Management Tool napp-it.

 

[alen]

Hallo ihr beiden

Besten Dank für eure ausführlichen Antworten, langsam fange ich an durchzublicken.
D.h. ich benötige für mein Vorhaben eigentlich 2 Festplattencontroller. Einer für ESXi & NAS VM OS und einen zweiten für meine Datenstorage, den ich in/via der NAS VM (z.B. FreeNas) verwalten möchte, und via Passthrough an die NAS VM durchreichen muss.
D.h. idealerweise suche ich mir ein Mainboard mit 2 Controllern. Sonst muss ich eine separate Controllerkarte kaufen, korrekt?
@Trambahner: Ich habe mir das X11SSH-CTF angeschaut. Das kostet aber ein Schweinegeld (400Euro). Was hat dich dazu bewogen, dieses Mainboard zu kaufen? Ich glaube für mein Vorhaben würde das X11SSL-CF reichen. Ich benötige keine 10GbE Anschlüsse…und dieses Board kostet „nur“ ca. 266 Euros. Oder mache ich etwas falsch damit.

Und dann noch dein Hinweis betreffend „ESXI über NFS nutzt sogenannete Synchronous Writes“. Wäre es dann nicht besser bzw. sicherer den Storage via iSCSI bereitzustellen?

Gruss
Alen

 

[besterino]

Die 10gbit dürften der ausschlaggebende Faktor gewesen sein. Für den Aufpreis von 134 Euro bekommst Du halt keine neue (dual) 10GBase-T Intel NIC.

Ansonsten richtig: Du brauchst dafür 2 selbstständige "Controller", welche auch immer (nur als Beispiel: wenn dein OS / Speicherplatz für die NAS VM auf einer NVME-SSD liegt, kannst Du auch den SATA-Controller durchreichen - ist aber nur semi-supported).

Bei iSCSI kannst Du m.W. nicht ganz so hübsch "snapshotten" und einzeln wiederherstellen.

 

[Digi-Quick]

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.
Ein von der Storage VM via iSCSI bereitgestellter Datastore wird nicht automatisch bei verspäteter Verfügbarkeit eingebunden, daher muß die Verbindung zum Datastore manuell wieder hergestellt werden, wenn die Storage VM läuft.
Bei NFS klappt Das.

Bei separaten Storage- und Virtualisierungshosts ist iSCSI natürlich eine Alternative, da der Storgehost ja dann vor dem VM-Host gestartet werden kann bzw. durchgehend läuft.

 

[gea]

Ein weiterer Aspekt Pro NFS

Da NFS ein normales Filesharing darstellt kann man aus einem ZFS Snap z.B. über SMB und Windows "vorherige Version" einzelne VMs einfach wiederherstellen. Ein iSCSI Target kann nur komplett wiederhergestellt werden. Um damit fast gleiches zu erreichen (ohne den Komfort von Windows vorherige Version) müsste man je VM ein iSCSI Target bereitstellen.

Performancemäßig ist NFS und iSCSI bei gleichen sync Einstellungen ziemlich gleich.

 

[sch4kal]

Beißt sich das nicht, NFSv4 und SMB gleichzeitig auf einem Dataset ?

 

[gea]

Das klappt fantastisch gut.

Man muss sich halt rechtemäßig an NFS orientieren da das viel weniger kann als SMB.
Da NFS (v.3) weder Authentifizierung noch Authorisierung kennt, muss man die Dateisystem-ACL auf everyone@=modify stellen. Wenn man SMB Zugriffsbeschränkungen braucht, muss man die auf Share-ACL abbilden oder die OS Firewall nutzen.

Mit NFS v4 wird es kompliziert - wobei ESXi dann sogar zusätzlich NFS 4.1 erfordert.

 

[alen]

Die 10gbit dürften der ausschlaggebende Faktor gewesen sein. Für den Aufpreis von 134 Euro bekommst Du halt keine neue (dual) 10GBase-T Intel NIC.

Ansonsten richtig: Du brauchst dafür 2 selbstständige "Controller", welche auch immer (nur als Beispiel: wenn dein OS / Speicherplatz für die NAS VM auf einer NVME-SSD liegt, kannst Du auch den SATA-Controller durchreichen - ist aber nur semi-supported).

Bei iSCSI kannst Du m.W. nicht ganz so hübsch "snapshotten" und einzeln wiederherstellen.

Ok, danke für den Hinweis. Ich habe mir jetzt nochmals das Supermicro X11SSL-F vs Supermicro X11SSL-CF im Detail angeschaut, da es doch 100 Euro Preisdifferenz sind. Der einzige grosse Unterschied ist wohl dass das Supermicro X11SSL-CF eben diesen zusätzichen LSI SAS 3008 Controller mitbringt. Ich habe dann geschaut, was diese Controller "einzeln" kosten...200-300 Euro? Kann das sein? Dann macht es ja definitiv Sinn das Supermicro X11SSL-CF zu kaufen, wenn man einen dedizierten SAS Controller will.

 

[craxity]

Ja, die Preise stimmen. Sowohl SAS-Controller als auch 10Gbit-Chips sind günstiger, wenn sie auf dem Board integriert sind. Du musst aber bedenken, dass man sie bei einem Upgrade nicht weiternutzen kann.

 

[gea]

Ja, es gibt das Basismodell mit 1G und IPMI und dann gegen Aufpreis einen 12G SAS Controller und/oder 10G
Onboard sind die viel billiger als separat.

 

[jonofe]

Nach nunmehr einem Jahr Betrieb meines Servers auf Basis des X11SSL-CF ägere ich mich auch schon, dass ich nicht das CTF genommen habe insbesondere, da ich mit einer TV, USB und NVMe Karte inzwischen alle PCIe Slots voll habe.
Allerdings ersetze ich jetzt die 600p NVMe mit einer Optane 900p. Das hätte beim CTF aufgrund von weniger PCIe Slots und stattdessen eines M2 Slots vermutlich nicht funktioniert.

 

[gea]

Allerdings ersetze ich jetzt die 600p NVMe mit einer Optane 900p. Das hätte beim CTF aufgrund von weniger PCIe Slots und stattdessen eines M2 Slots vermutlich nicht funktioniert.

Die 900P in der U.2 Variante kann man an den M.2 Slot anschließen. Das Adapterkabel war bei meinen 900P/U.2 sogar bereits dabei.

 

[jonofe]

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?

 

[alen]

Ja, die Preise stimmen. Sowohl SAS-Controller als auch 10Gbit-Chips sind günstiger, wenn sie auf dem Board integriert sind. Du musst aber bedenken, dass man sie bei einem Upgrade nicht weiternutzen kann.

Interessanter Hinweis. Bei einem Upgrade von WAS? Von ESXi ? Wir dann die 'alte' Hardware nicht mehr unterstützt ?

Gruss
Alen

 

[craxity]

Sorry, ich ahbe mich falsch ausgedrückt. Ich wollte nur auf den Nachteil hinweisen, dass du immer ein Board mit dem gleichen Funktionsumfang brauchst, wenn du aufrüsten musst, weil du kein Teil weiterverwenden kannst. Das empfinde ich als NAchteil, weil man Controller und LAN-Karte eigentlich länger nutzen könnte als Board+CPU.

 

[Trambahner]

Kein Vorteil ohne Nachteil, das stimmt schon.
Aber ein X11SSH-CTF mit E3 kann zumindest als Storage daheim noch recht lange Dienst tun. Und wenn die Hauptmaschine upgraden/ersetzen will, dann kann es als ZFS-Backupfiler noch ziemlich lang ohne Upgrade dienst tun. Oder ein 3. Leben als Server-Versuchskaninchen für alles mögliche.

So schnell ist das Ding nicht zum entsorgen. Und dann nach so einer relativ langen Zeit ist der Bedarf an Bandbreite weiter gestiegen, dass man dann evtl. eh nen neuen Storagecontroller will. Oder beim Lan zufällig ne CX4 100G schiesst.

Notfalls kann man den M.2-Sockel auch per Adapter zu einem klassischen PCIe-Sockel machen.

@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.

Intel weiss das auch, und das die 900P U.2 selbst für Datacenter interessant ist; weswegen es die 900p U.2 lange nur in der kleinen Version gab.