Unrandom

Check. So schnell muss es hier dann doch nicht sein und dutzendweise TBs brauchts auch nicht. Das wäre vielleicht noch eine gute Information für den Eingangspost gewesen...

Ich wollte aus der Sicht des Energiesparens argumentieren, dass Festplatten ja nicht zwingend beim Herunterfahren des Servers abschalten müssen, wenn der Server ohnehin immer läuft. Das bedeutet doch nicht, dass man den Server für Wartung, Umbau und Urlaubsreise nicht herunterfahren und die Festplatten dann abschalten kann. (Für Wartung und Umbau steht man doch ohnehin vor dem Server und zieht vorher den Stecker aus der Steckdose.) Vielen Dank für den Hinweis besser auf SMR zu verzichten. Mir fällt es ohnehin gerade schwer 2,5“ HDDs (die nicht von Seagate sind) größer 2TB zu finden. Gleiches gilt für CMR, hier scheint bei 2TB Schluss zu sein. Vielleicht wäre es besser auf ein SSD Raid1 Pool umzuschwenken. Lässt sich zwar nicht so toll erweitern wie das Array, aber 2x4TB mit 4TB Nutzdaten ist für meinen Use Case die nächsten Jahre auf jeden Fall ausreichend. Sind energetisch auch einfacher zu handeln. Bei maximal 0,3A pro SSD kann ich beide über den internen USB 2.0 Header (1A) bestromen. Der schaltet sogar beim Herunterfahren ab ;-) Da die Geschwindigkeit immer wieder mal angesprochen wird. Lässt man interne Schreibvorgänge mal außen vor, ist das 1 Gigabit Netzwerk der Flaschenhals. Selbst die angesprochene so langsame PCIe 3.0 1x Schnittstelle ist grob 8x schneller.

Das ist doch super. Da der Server immer läuft und die Festplatten immer mit Spannung versorgt werden (und sich ggf. im Spindown befinden), vereinfach das die Spannungsversorgung enorm. Dann muss ich bei meinem NUC-Unraid-Server bei Verwendung von 2,5" HDDs nur dafür sorgen das sie dauerhaft mit 5V versorgt werden. Letztlich nicht anders als bei externen 2,5" USB Festplatten, nur das die Kommunikation statt über USB, über SATA geht, was für ein Array von großem Vorteil ist.

Vielen Dank für eure Beharrlichkeit. Ich liege falsch. Meine Schlussfolgerung aus der Messung war, dass Selbsthaltung und Taster parallel liegen müssen. Hätte ich etwas länger darüber nachgedacht wäre mir aufgefallen das dies ja gar nicht der Fall sein kann, da dann erneutes Drücken des Tasters nicht mehr wahrgenommen werden könnte. Und dies ist ja ganz offensichtlich falsch. Weiterhin bedeutet dies, dass an diesem Pin nicht das PS_ON Signal anliegen kann und deshalb natürlich auch nicht zur picoPSU geführt werden sollte. Bevor ich mich jetzt aber auf eine alternative Versorgung stürze zunächst eine andere Frage. Eine HDD die gerade weder schreibt noch liest benötigt in einem Unraid genauso viel Energie wie in einem Synology Nas? Und ein Unraid fährt man genauso wie ein Synology Nas nie komplett runter, damit die Festplatten jederzeit aufgeweckt werden können um auf die Daten zugreifen zu können? Welche Rolle spielt dann der Energieverbrauch eines heruntergefahrenen Servers oder dessen Festplatten wenn er nie herunter gefahren wird? Was habe ich übersehen?

Vielleicht hilft ein Beispiel mit der 5V Spannung. Im klassischen Tower PC überprüft das ATX Netzteil im laufenden Betrieb die 5V Spannung. Liegt ein Fehler vor sendet das ATX Netzteil kein Power OK Signal mehr an das Mainboard. Das Mainboard kann dann das Senden des PS_ON Signals an das Netzteil abbrechen. Das Netzteil schaltet hab. Im NUC werden die 5V auf dem Mainboard des NUCs (aus 12-20V) erzeugt. Im NUC überprüft das Maoinboard des NUCs im laufenden Betrieb die 5V Spannung. Liegt ein Fehler vor sendet das NUC Mainboard kein Power OK Signal mehr an sich selbst / das NUC Mainboard. Das Mainboard kann dann das Senden des PS_ON Signals an die PicoPSU abbrechen. Die PicoPSU schaltet hab. Zum Taster kann ich nur sagen dass dieser kurzzeitig ein Signal an ein Mainboard gibt. Das Mainboard entscheidet dann wie lange der PC eingeschaltet bleiben soll (PS_ON an Netzteil). Dieses Verfahren unterscheidet sich beim NUC imho nicht vom Tower PC. Kann natürlich sein das ich damit total danebenliege, aber so mein aktuelles Verständnis.

Hier nochmal der Plan mit Bild. 1. Zum Einschalten des PCs drückt man den im Gehäuse verbauten Power Button. Ist hier wie bei jedem anderen PC. 2. Das Mainboard empfängt den Einschaltbefehl des Tasters und gibt ihn an das Netzteil weiter (PS_ON) bis der PC heruntergefahren wird. Auch hier wie bei jedem anderen PC, nur dass eine einzelne Leitung vom Front Panel Header zur PicoPSU dazu kommt. 3. Das Netzteil versorgt den PC. Herkömmliche Computer erhalten vom Netzteil die diversen zum Betrieb benötigten Spannungen. Der NUC wird klassisch über ein 19V Tischnetzteil versorgt. Oder über den oben gezeigten Internal Power Header mit 12-20V. In beiden Fällen erzeugt das Mainboard (und nicht das Netzteil) alle Spannungen. Das Mainboard überprüft diese Spannungen gezwungenermaßen selbst und gibt sich das Power OK Signal quasi selber. Weder das Tischnetzteil noch die PicoPSU sind beim NUC am Power OK Signal beteiligt.

Gut, fassen wir das mal zusammen. Ein Taster wird gedrückt und legt den ATX Pin auf Masse. Sobald der Taster losgelassen wird sorgt eine im Mainboard integrierte Selbsthaltung dafür dass dieser Pin weiter mit Masse verbunden bleibt und damit das Netzteil und der PC eingeschaltet bleiben. Da Taster und Selbsthaltung im NUC bereits integriert sind sollten diese doch auch für ein neues Netzteil weiter verwendet werden können. Der NUC hat einen Front Panel Header an dem nichts angeschlossen ist. Hier würde man bei Bedarf einen Taster anschließen um den NUC zu starten. Umgekehrt kann aber auch der im NUC-Gehäuse verbaute Taster abgegriffen werden. Hier habe ich in gedrücktem Zustand gerade 200 Ohm gemessen (PC vom Tischnetzteil getrennt). Ich nehme an der Widerstand ist so hoch da man hier bereits die Selbsthaltung (Innenwiderstand des Transistors!?) misst und nicht den Taster. Sollte dem so sein, müssen nur vom Front Panel Header die Verbindung des Tasters zur PicoPSU.

Mein NUC lässt sich statt mit dem 19V Tischnetzteil auch mit 12V direkt über das Bord versorgen. Da die PicoPSU viel gelobt wird, darf die vermutlich ran.

Ja, gemäß Intel unterstützt dieser Key-B Sockel SATA, USB 3.2 und PCIe 3.0 x1. Das ist eine gute Idee. Wenn es ohnehin nicht ohne Key-Adapter funktioniert, kann ich ja auch diesen hier nehmen und die Key M -> SATA Platine fixieren: Wenn man den ASM1166 hier einsetzt, hat man das Problem nicht. Ich bin nicht sicher ob ich das richtig verstanden habe. Ich dachte der ASM1166 (und auch JMB585) kommunizieren per PCIe mit dem Mainboard. Gemäß Intel unterstüzt dieser Key-M Slot nur NVMe. Ich habe das so verstanden, dass dieser Slot nur über das NVMe Protokoll mit Erweiterungskarten kommunizieren kann (auch wenn NVMe über die PCIe Schnittstelle kommuniziert). Daher war meine Schlussfolgerung das die Chips über diese Schnittstelle nicht mit dem Mainboard kommunizieren können. Check. Mehr ginge nur wenn ich vom NUC Abstand nehmen würde. Da hast du sicher recht. Manchmal sieht man die Keys vor lauter Ports nicht mehr. @MPC561 Check. Wenn man von dem kleinen Umstand absieht das ich einen Adapter brauche, ist der ASM1166 doch eine gute Wahl.

Hallo zusammen, ich suche eine M.2 Key B Platine mit ASM1166 und 6x SATA. Meine Lösung sähe aktuell so aus (Key-Adapter Key B -> Key M + Platine Key M -> SATA): Kennt jemand ein Produkt das ohne Key-Adapter auskommt? Details: Als mein erstes Unraid Projekt möchte ich gerne meinen Netzwerkspeicher von einem Synology NAS auf einen Unraid-Server umziehen. Mit 3 HDDs im Array (Ausbaumöglichkeit auf 6 HDDs), davon 1x Parität und 2 SSDs im Raid1 als Cache im Pool. Auf den SSDs soll später noch Hausautomation mit MySQL o.Ä. stattfinden. Unraid liegt auf einem Swissbit U-56n und kommt intern an einen USB-Header. Hardwarebasis ist ein Intel NUC (12WSKi30002 i3-12220P) da der bereits vorhanden ist. Lässt man USB und TB4 außen vor, bleiben 3 Schnittstellen für Festplatten: 1. 1x M.2 Key M (NVMe) Dies ist ein NVME-only Slot. Adaptierung auf SATA leider nicht möglich. Hier landet Cache-SSD-1. 2. 1 x M.2 Key B (unterstützt neben SATA und USB 3.2 auch PCIe 3.0 x1) Hier soll auf 6x SATA für das Array adaptiert werden. 3. 1 x SATA III (6 Gbit/s) Hier landet Cache-SSD-2. Zurück zur Frage: Gefunden habe ich ein Umweg von M.2 über PCIe-Karte. Den finde ich aber nicht so ideal da es viele Steckverbindungen und lange Leitungswege beinhaltet. Dann habe ich Key B Platinen mit ASM1166 gefunden aber mit maximal 5x SATA. Und ich habe Key B Platinen mit 6x SATA aber anderem Chip gefunden. Kennt jemand ein Produkt mit Key B und ASM1166 und 6x SATA? Habt Dank und Grüße, Stefan