Stromsparender Server mit mind. 5x 3.5" oder 10x 2.5"?

Cantello schrieb:
Momentan sind 3x10TB verbaut als RAIDZ1. Davon ca. 17TB belegt, demnächst käme eventuell noch eine Platte dazu.
Sehr schlechte, wenn nicht sogar dämliche Idee also sofern du den Pool mit der raidz1 vdev mit der einzelnen neuen Platte erweitern willst. Dann hast einen Pool aus einem raidz1 und einem single vdev. Raucht das single-vdev ab, ist der gesamte Pool futsch. Willst du erweitern entweder alle Daten sichern, den Pool & vdev zerstören, neues raidz1 vdev mit 4x HDDs anlegen und damit den Pool erzeugen. Alternativ direkt 3 neue HDDs anschaffen, daraus auch ein raidz1 erstellen und dem Pool geben.

Cantello schrieb:
Allerdings ohne Speicher.
Solltest du ziemlich schnell nachrüsten bzw. die Planung dazu jetzt in Angriff nehmen.

Cantello schrieb:
Vorschläge oder Ideen?
Fahre das System herunter, wenn du es nicht brauchst. Hast du VMs oder Container, die du 24x7 brauchst oder möchtest, dann versuche diese Systeme so leicht und klein zu bekommen, wie nur möglich und lagere diese ggf. auf einen Raspi 4 oder gebrauchten NUC aus.
Der stromhungrige Server kann dann laufen, wenn er gebraucht wird und sonst ist er aus.
 
  • Gefällt mir
Reaktionen: andy_m4
Cantello schrieb:
Es klappt einfach nicht.
"Es klappt nicht" ist jetzt nicht gerade eine Fehlerbeschreibung, mit der man was anfangen kann. :-)
Was klappt denn konkret nicht?
Gehen die Festplatten nicht in den Standby? Oder wachen Sie ständig wieder auf? Oder klappt das mit dem Timer nicht?

Ein simplen Test ob die betreffende Platte grundsätzlich in den Standby geht kann man mit
camcontrol standby ada1
machen
(für ada1 die entsprechende Platte einsetzen; eine Liste aller Platten kriegt man mit camcontrol devlist)

Wobei das Standby bzw. Spin-Down immer auch ein bisschen vorsichtig sein sollte. Bei Desktop-Platten ist das i.d.R. kein Problem, weil die eher darauf ausgelegt ist. Server- und NAS-Platten sind eher dafür gebaut das sie durchlaufen. Denen tut zu häufiges Spin-Down nicht so gut.
 
andy_m4 schrieb:
"Es klappt nicht" ist jetzt nicht gerade eine Fehlerbeschreibung, mit der man was anfangen kann. :-)
Was klappt denn konkret nicht?
Gehen die Festplatten nicht in den Standby? Oder wachen Sie ständig wieder auf? Oder klappt das mit dem Timer nicht?
Die Festplatten gehen auch nach der eingestellten Standby-Zeit nicht in den Spindown, nicht einmal nach mehreren Stunden.
Geprüft mit z.B. camcontrol epc da5 -c status -P oder camcontrol modepage da3 -m 0x1a für die einzelne SAS-Platte. Per smartctl -a /dev/da4 kann ich ja auch den Load_Cycle_Count sehen und der bleibt auch nach Tagen gleich, also kein Spindown/-up. Grundsätzlich klappt Spindown mit dem entsprechenden camcontrol-Kommando wunderbar.
 
Hat die TrueNAS VM zu wenig RAM und muss swappen? Der liegt nämlich über alle HDDs des ersten Pools verteilt.
Liegt das system-dataset auf dem Pool? Wird afaik auch standardmäßig auf dem ersten Pool abgelegt.
Laufen irgendwelche bhyve VMs, Jails oder Plugins, die IO auf dem Pool erzeugen?
Nutzen deine sonstigen VMs und Container den von TrueNAS bereit gestellten Storage?
Irgendwoher kommten halt dauernd Zugriffe. Wenn du diese finden und abstellen kannst, sollte auch Standby/spindown funktionieren. Ich bleibe aber dabei: wirklich sparen wirst erst wenn das System nur noch bei Bedarf läuft.
 
  • Gefällt mir
Reaktionen: guzzisti
Die TrueNAS VM swappt (im Allgemeinen) nicht, aber selbst wenn, wäre die Swap-Partition auf der gleichen SSD wie das System Dataset, sollte also den Pool mit den rotierenden Platten nicht berühren. Dein anderer Punkt sieht schon sehr viel mehr nach dem Grund aus, die TrueNAS-VM gibt den Speicher ja auch für die anderen VMs frei und dort kommt es möglicherweise gerade bei der Kameraüberwachung zu häufigeren Zugriffen (wobei die auch erst auf der SSD gesammelt werden sollten und dann täglich verschoben). Werde ich einmal prüfen und schauen, ob mit abgeschalteten weiteren VMs der Spindown klappt.
Nach Bedarf anschalten wollte ich eigentlich vermeiden, da noch einige externe Benutzer:innen dranhängen (Plex mit der Familie, Foundry Online-RPG, Wikis).
 
einfach keine 24Stunden am Tag laufen lassen! Eher 1/3 des Tages an und rest der Zeit aus.
Meine 2x SYNOLOGY DS920+ mache ich um 16:00 an und um 00:00 aus ;)
Somit habe ich ca. 50€ Stromkosten im Jahr! 365 x 8h x 0,055kW = 160kWh --> 160 kWh x 0,3€ = 48€
 
Cantello schrieb:
wäre die Swap-Partition auf der gleichen SSD wie das System Dataset
wäre klingt nach Vermutung.
Cantello schrieb:
Plex mit der Familie
Das muss auch vormittags um halb 11 unter der Woche zur Verfügung stehen?^^ Falls ja sollen sich die Nutzer halt an den Betriebskosten beteiligen oder mit Verfügbarkeit nur von x bis y Uhr leben.
Cantello schrieb:
Foundry Online-RPG
Läuft sogar offiziell unterstützt auf einem Raspi.
Cantello schrieb:
Ebenfalls Raspi.

Du müsstest nicht einmal deine VMware ESXi Welt verlassen: https://raspberrytips.com/install-vmware-esxi-raspberry-pi/
Naja wobei ich ehrlicherweise das Spiel und ein Wiki einfach so auf dem Raspi installieren würde.

Alternativ das Spiel & Wiki auf einem kleinen gemieteten vServer laufen lassen. Da tauscht dann Anschaffungs- & Stromkosten gegen Servermiete. Je nach Anforderungen wirst da bei ~5€/Monat landen vermute ich.

Steht und fällt jetzt damit ob Plex und der Storage dafür 24x7 erreichbar sein muss oder z.B. nur Mo-Fr 16-24 Uhr und Sa-So 0-24 Uhr (beispielhaft).
 
Maxminator schrieb:
einfach keine 24Stunden am Tag laufen lassen! Eher 1/3 des Tages an und rest der Zeit aus.
Meine 2x SYNOLOGY DS920+ mache ich um 16:00 an und um 00:00 aus ;)
Zumindest bei mir keine Option ohne auf laufendes Datenlogging zu verzichten, was ich ungerne tun würde.
Außerdem schaue ich auch schonmal tagsüber auf meinen Kalender oder meine Daten, dafür sollte dann Nextcloud auch laufen.

Außerdem laufen meine Backups dann wenn ich die nicht hören kann: ab 2 Uhr morgens.

Ist also nicht immer so eindeutig wenn man mehr als nur eine Datenfreigabe und einen Plex Server laufen hat...
 
ok, du hast viel von deiner NAS, bzw. du dutzt ja deine NAS voll aus: dann musst du mit der erhöhtem Stromverbrauch auch leben - nichts gibt es umsonst ;)
 
  • Gefällt mir
Reaktionen: guzzisti
wäre klingt nach Vermutung.
Klang nur so, ich weiß ja, wo die Swap-Partition liegt (aber hauptsächlich nur deshalb nicht auf den Datenplatten, weil sie von XigmaNas importiert wurden. TrueNAS macht das ja standardmäßig leider auf alle Datenplatten.) Geswappt wird aber nicht:
2022-08-27 19_37_48-TrueNAS - 192.168.1.11 - Vivaldi.png


snaxilian schrieb:
Steht und fällt jetzt damit ob Plex und der Storage dafür 24x7 erreichbar sein muss oder z.B. nur Mo-Fr 16-24 Uhr und Sa-So 0-24 Uhr (beispielhaft).
Das muss natürlich nicht sein, ich tue mich nur etwas schwer, die genauen Zeiten festzulegen, manchmal wird halt etwas um 14h gefordert und manchmal erst ab 19h. Mit der Zahl der Nutzer ist leider auch die Nutzungszeit deutlich heterogener... Eventuell ist es doch sparsamer, die 'kleinen' Dienste (Foundry, Wikis,
 
Zuletzt bearbeitet:
Cantello schrieb:
Werde ich einmal prüfen und schauen, ob mit abgeschalteten weiteren VMs der Spindown klappt.
Hast Du das denn mal ausprobiert oder zumindest mal tracken lassen ob und wer auf die Platten zugreift?
 
andy_m4 schrieb:
Hast Du das denn mal ausprobiert oder zumindest mal tracken lassen ob und wer auf die Platten zugreift?

Alle VMs abgeschaltet und dann überwacht, zuerst dachte ich, es klappt, dann aber sind die Platten wieder auch nach längerer Zeit nicht heruntergefahren. Wie könnte ich denn loggen, wer/was zugegriffen hat, gibt es da unter BSD Möglichkeiten?
 
Cantello schrieb:
Wie könnte ich denn loggen, wer/was zugegriffen hat, gibt es da unter BSD Möglichkeiten?
Aktuell geöffnete Dateien kann man mit lsof (ist aber möglicherweise nicht installiert) oder fstat rauskriegen.
Damit kriegt man aber halt nur die Dateien die gerade offen sind. Viele Dateioperationen sind ja mehr so ein: Öffnen, Lesen_od_schreiben, Schließen.

Dafür könnte man dtrace zu Hilfe nehmen und zum Beispiel nachgucken, wer den Systemaufruf open benutzt. Ist ein bisschen tricky weils auch noch den Aufruf openat gibt und da auch die Parameter für den Dateinamen an unterschiedlichen Stellen stehen.
Deshalb ist es ein etwas längerer Aufruf:
dtrace -n 'syscall::open:entry { printf("%s %s", execname, copyinstr(arg0)); }' -n 'syscall::openat:entry { printf("%s %s", execname, copyinstr(arg1)); }'

Da hakt man sich in den Syscall open bzw openat ein und execname ist halt der Name des Programms von dem der Aufruf kommt und arg0 bzw. arg1 ist halt der Parameter gemäß des open-Aufrufes (also der Dateiname der geöffneten Datei).

Es wird dann immer eine Zeile ausgegeben, wenn ein Aufruf stattfindet. Dann muss man halt gucken, ob der betreffende Pfad dabei ist. Man kann die Ausgabe auch in eine Datei schreiben lassen:
dtrace -o /path/to/dtrace.log -n 'syscall::open:entry { printf("%s %s", execname, copyinstr(arg0)); }' -n 'syscall::openat:entry { printf("%s %s", execname, copyinstr(arg1)); }'
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: snaxilian
Zurück
Oben