Meine DS1621+ hat immer was zu tun. Aber warum???

[WasaWasa]

Hallo. Ich ärgere mich gerade über meine NAS.
Und zwar weil das Teil meint ununterbrochen auf den Platten werkeln zu müssen.
Darum muss die DS1621 jetzt auch ihr Dasein im Keller fristen.

Kann mir irgend jemand sagen was das Teil macht?
Und besser noch, wie man das abstellt?

Ich verstehe es halt nicht und das treibt mich in den Wahnsinn.
Es ist nach der Grundinstallation nichts mehr installiert worden.
Ich habe sogar noch weitere Dienste über den ssh Zugang deaktiviert (Indexer, ...).
Ich habe es mit WD red und und mit Seagate IronWolf versucht.
Ich habe das Powermanagement mit SeaChest geprüft (Dafür vielen Dank - hier sind einige feine Anleitungen dazu).
Ich habe das logging deaktiviert und noch viele Dinge aus vielen Listen abgearbeitet.
Das Ergebnis war ernüchternd - die Kiste rappelt immer noch vor sich hin.
Und das tut sie auch, wenn sie vom Netzwerk getrennt ist.

Daneben steht ein Eigenbau und da ist Stille. Der tut nur etwas, wenn eine Anforderung ansteht.
Auf dem laufen sogar Dienste unter Podman. (Wer arbeitet heute noch mit Docker ...)

Wenn man im Internet sucht, findet man dieses Beschwerden seit Jahren.
Ich habe bisher noch keinen Grund für die Plattenaktivitäten gefunden und schon gar keine Lösung.

Ich bin hier für jeden Hinweis dankbar.

 

[Synchrotron]

Eine DS ist ein Server, dafür ausgelegt, ohne viel Admin-Aufsicht die eigene Funktion sicher zu stellen. Dazu gehören Verwaltungsjobs, die man in den meisten Übersichten nicht sieht, aber mitbekommt, wie sie abgearbeitet werden.

Worum es konkret gehen kann, hat Synology in diesem Hilfetext beschrieben. Die Liste der Faktoren, die einen Ruhezustand verhindern können, ist ziemlich lang !

https://kb.synology.com/de-de/DSM/t...Synology_NAS_from_entering_System_Hibernation

 

[tproko]

Podman. (Wer arbeitet heute noch mit Docker ...)

Vielleicht bin ich da nicht mehr 100% aktuell, aber Windows kann nur docker oder?

Und wenn man da richtig weit vorne mitmischen will, ist doch heute eher kubernetes/openshift „in“

 

[WasaWasa]

Danke für den Link! Da stehen noch einige Sachen drin, die ich nicht kannte .
Und bitte nicht falsch verstehen. Ich gestehe einem Server schon zu, dass er interne Verwaltungsjobs hat,
aber meine Synology rödelt ununterbrochen. Da würde ich schon gerne wissen was abgeht.
Auch bin ich mir nicht sicher, ob Hibernation eine gute Idee ist. Das dürfte eine Platte mehr stressen als der Dauerlauf.
Mal sehen wie weit ich da noch komme.

 

[Benares]

Wirf auch mal einen Blick in den Ressourcen-Monitor, Aufgaben-Manager, Dienste und sortiere die Liste nach Lesen bzw. Schreiben.
Dann siehst du, welcher Prozess den I/O verursacht und kannst weiter forschen.

 

[WasaWasa]

Vielleicht bin ich da nicht mehr 100% aktuell, aber Windows kann nur docker oder?

Und wenn man da richtig weit vorne mitmischen will, ist doch heute eher kubernetes/openshift „in“

Ok. Für das Thema müsste man einen eigenen Thread aufmachen . Und mir war klar, dass das nicht unwidersprochen bleibt.
Man kann aber Podman sehr wohl auf Windows laufen lassen. So wie es Windows mit Docker macht. Man installiert es in der WSL(2).
Hier eine ganz gute Anleitung https://www.redhat.com/sysadmin/podman-windows-wsl2
(Aber wer arbeitet heute noch mit Windows ...)
Und ich bin ein großer Freund von Kubernetes. Bei mir läuft ein Cluster und die NAS hat die Aufgabe den Storage zu provisionieren.

 

[tproko]

Ja, das schweift sicher schon ab. Aber jedenfalls mal noch viel Erfolg mit dem Leiser kriegen, vielleicht klappt es ja dann doch noch wie du es dir erhoffst

Oh Gott... "Windows Subsystem for Linux"... Sachen gibts
Naja, da bleib ich lieber für solche Dinge bei Linux (auch wenn ich Windows zum Teil auf Geräten im Haus habe).
docker / podman läuft hier privat. In der Arbeit laufen die meisten unsere Webanwendungen mittlerweile auf openshift. Aber das ist für Zuhause einfach overkill.

 

[WasaWasa]

So. Ein bisschen weiter mit dem unruhigen NAS.
Ich habe das im Log "synoscgi.log" gefunden.

2022-03-17T01:37:02+01:00 ds1621 synoscgi_SYNO.Core.System.SystemHealth_1_get[28417]: SystemInfo/san_status_info.cpp:50 Failed to load lun info for SAN Manager
2022-03-17T01:37:02+01:00 ds1621 synoscgi_SYNO.Core.System.SystemHealth_1_get[28417]: SystemInfo/san_status_info.cpp:66 Failed to load volume info for SAN Manager
2022-03-17T01:38:16+01:00 ds1621 synoscgi_SYNO.Core.System.SystemHealth_1_get[28720]: SystemInfo/san_status_info.cpp:50 Failed to load lun info for SAN Manager
2022-03-17T01:38:16+01:00 ds1621 synoscgi_SYNO.Core.System.SystemHealth_1_get[28720]: SystemInfo/san_status_info.cpp:66 Failed to load volume info for SAN Manager
2022-03-17T01:38:34+01:00 ds1621 synoscgi_SYNO.Core.System.SystemHealth_1_get[28841]: SystemInfo/san_status_info.cpp:50 Failed to load lun info for SAN Manager
2022-03-17T01:38:34+01:00 ds1621 synoscgi_SYNO.Core.System.SystemHealth_1_get[28841]: SystemInfo/san_status_info.cpp:66 Failed to load volume info for SAN Manager

Und wo kam das her? Ich habe vor einiger Zeit eine LUN über iSCSI angebunden.
Dann habe ich die Verknüpfung zwischen Target und LUN gelöst, aber das Target aktiv gelassen.
Nachdem ich das Target offline gesetzt habe, ist es mit der Diskaktivität deutlich besser geworden.
Dürfte jetzt ehr exotisch sein. Aber vielleicht hilft es ja mal jemand.

 

[WasaWasa]

Habe die Synology noch in ein eigenes Neztsegment umgezogen. Damit lässt sich das Broadcasting ganz gut kontrollieren.
Jetzt ist tatsächlich Ruhe eingekehrt. Nun bin ich wieder etwas glücklicher mit meiner Synology.
Im nächsten Schritt werde ich den Backup wieder konfigurieren, dann ist mit der Ruhe für die Platten wieder vorbei.

 

[Iarn]

Ich habe bei mir im Netzwerk bei allen Synos den SAN Manager gestoppt. Zumindest bei mir ist jetzt wesentlich mehr Ruhe als vorher und die Synos haben weniger Prozessorlast, auf einer Syno hat der SAN Manger auch ziemlich CPU Last erzeugt (warum auch immer, da ich ich dne Service nicht nutze) .

 

[WasaWasa]

Ja. Die Erfahrung habe ich auch gemacht. War aber bei mir etwas Kontraproduktiv.
Ich hatte ja noch ein aktives iSCSCI Target. Das habe ich natürlich erst gesehen, als ich den SAN Manager wieder aktiviert hatte.
Und das Target hat auch für Aktivität gesorgt, weil es von seiner LUN verlassen wurde (siehe meinen Post oben).
Aber ja - den SAN-Manager habe ich gerade wieder deaktiviert.

 

[Nasi]

Oft auch die Indizierung (Fotos) ,kann man pausieren lassen.

 

[Sequoia]

Wie kann ich denn eigentl. diesen SAN Manager raus schmeißen? Ich brauch das Ding nicht. Übers Paketzentrum kann ich ihn weder Stoppen, noch deinstallieren?

 

[Iarn]

Deinstallieren kannst Du das Ding nicht, weil Synology das nicht möchte. Wenn Du das Paket stoppen möchtest (ich musste das bei mir tun, weil es zu viel CPU Last erzeugte), kannst Du das wie folgt tun:
mit ssh auf die Syo gehen
mit "sudo su" zum Superuser (root) werden
und dann eingeben "synopkg stop ScsiTarget"

 

[Sequoia]

Ist das dann dauerhaft, oder nur bis zum nächsten Neustart?

Probleme mit der CPU Last o.ä. habe ich nicht. Aber ich denke einfach, sowas, was ich nie brauchen werde, muss ja nicht mit laufen.

 

[Benares]

Lösch die Flag-Datei /var/packages/ScsiTarget/enabled und boote die DS neu. Das geht auch. An der enabled-Datei (gibt's bei jedem Paket) macht der DSM fest, ob ein Paket beim Booten gestartet wird.
Oder setze in der Datei /var/packages/ScsiTarget/INFO den Parameter ctl_stop von "no" auf "yes" um. Dann lässt sich das Paket auch über die DSM-Oberfläche stoppen und starten.

 

[Sequoia]

Als Jemand, der noch nie per ssh auf die DS ist, ist das nicht sehr einfach.
Da muss ich mich dann mal einlesen, denke ich.
Aber so dringend ist das ja nicht. Meine DS ist normalerweise sehr ruhig & es stört mich ja nicht wirklich.

 

[WasaWasa]

Also. der Paketmanager von Synology kann noch ein bisschen mehr. Die haben irgendwie den Paketmanager mit dem Systemcontrol verheiratet.
Wenn man sich Zugang per ssh verschafft hat, dann kann man sich mal anschauen was das Teil alles kann: "synopkg --help".
Die wichtigsten Befehle dürften "start | stop | status | install | uninstall | list" sein.
Wenn man dann noch die Dienstnamen kennt, kann man damit viel machen. Der SAN-Manager ist "ScsiTarget".
Will man wissen wie es um ihn steht, dann gibt man "synopkg status ScsiTarget" ein.
Was habe ich abgeschaltet? Das hier:
SynoFinder: Universal Search
ActiveInsight: Statistiken bei Multisite Einsatz von NAS Systemen
HybrideShare: Puffer für Cloud Daten
ScsiTarget: SAN Manager

Und ja, ein "stop" ist permanent. So ist meine Erfahrung.

Angehängt ist ein Screenshot, bei dem ich das ScsiTarget gestoppt habe.

Will man eine Liste aller installierten Pakete haben: "synopkg list --name".
Lässt man das "--name" mit, dann bekommt man noch eine ausführliche Beschreibung, die aber die Lesbarkeit deutlich verschlechtert.
Die angezeigten Dienste sind installiert, mussen aber nicht laufen. Das prüft man mit "synopkg status ...".

Und man sollte sich schon im klaren darüber sein, was man abschält.
Damit kann man das NAS softwaremäßig kaputt konfigurieren!

Und noch ein Anhang mit der Lister bei mir installierter Pakete.

Damit soll jetzt mal genug sein. Gleich fängt SchleFaZ an!