Vermeiden eines Neustarts vor FW-Update

    Ich möchte mal folgenden Gedanken zur Diskussion stellen.


    Nach schon geringer Laufzeit empfiehlt QNAP, vor einem Update der FW das NAS neu zu starten. Damit soll verhindert werden, dass irgend etwas im Hintergrund läuft und das Update blockieren könnte. Klingt erst ja Mal logisch. Allerdings werden ja andererseits auch sofort nach Neustart die Dienste wieder gestartet. Könnte also theoretisch ja auch dann schon etwas wieder im Hintergrund unbemerkt störend für das Update sein.


    Seit einiger Zeit will ja mein NAS aus unerklärlichen Gründen nach jedem Neustart, dass ich das Filesystem meines Volume0 ("System-"Volume) checken lasse - ist lästig. Daher habe ich mir angewohnt, erst man manuell mittels /etc/init.d/services.sh stop alle Dienste selber zu beenden. Dann "umounte" ich auch gleich alle CACHEDEVs. Damit hatte ich dann das genannte Problem nicht mehr. Ist aber an sich eine andere Geschichte.


    Jetzt der Gedanke: Wäre es nicht sinnvoll oder zumindest auch denkbar, dieses Vorgehen einem kompletten Neustart des NAS vorzuziehen?


    Ich hatte es ja beim letzten Update die Tage genau so gemacht, hatte dann aber das Phänomen, dass das Gerät am Punkt "Mounte Volume" ewig hängen blieb. Kann es mir zwar nicht vorstellen, aber vielleicht gibt es einen Zusammenhang.

    Ich vermute, das ist zuviel Aufwand, das Update Prozedere derart umzugestalten.

    Und für viele ist allein schon der Gedanke per CLI ein Kommando abzusetzen eine Horrorvorstellung.

    Beim letzten Update (Downgrade) von 5.0.1 auf 5.0.0.2055 und wieder zurück habe ich auf den "Vorher" Boot verzichtet (ok, zwischen 2055 und 5.0.1 lagen auch nur 40 Minuten).


    Ich vermute aber auch, das es nicht nur die Dienste sind, sondern das durch den reboot auch wieder Speicher freigegeben wird/werden soll und das Update dann reibungslos durchläuft.


    Gruss

    Zitat von FSC830

    sondern das durch den reboot auch wieder Speicher freigegeben wird/werden soll

    Genau das verbinde ich auch mit dem Neustart. Da ich das sowieso einmal wöchentlich per Zeitplan mache ist bei mir nicht viel zu erkennen, ich denke aber bei längerer Laufzeit und anderer Nutzung könnte das durchaus anders aussehen:


    pasted-from-clipboard.png


    Rot markiert sind zwei Reboots, danach sind Buffer und Cache immer runtergefahren, kommen im Laufe der Woche dann wieder und würden bestimmt weiter ansteigen.


    Ist zwar nicht vergleichbar, aber bei meiner Firewall sieht man das deutlicher:

    pasted-from-clipboard.png

    Naja, Buffer und Cache leeren geht ja auch ohne kompletten Neustart, oder? Aber zugegeben, ab und an kämpfe ich auch mit auf unerklärliche Weise blockierten RAM abseits von den beiden. Da hilft dann natürlich der Reboot.

    Hab bisher immer auf einen Neustart vor Update verzichtet, da der Neustart so um die 30 Minuten dauert.


    Lediglich die laufende VM wurde manuell beendet. Bisher hat's immer gut funktioniert.

    30 Minuten?! 8| Ich ärgere mich schon über 10min.

    Dauert das Herunterfahren oder das Hochfahren so lange, dass diese Zeit zustande kommt? Und was läuft darauf alles?

    Ob's jetzt 30 Minuten bei mir sind kann ich jetzt nicht sagen, aber insbesondere Anwendungen mit Nutzung von Datenbanken scheint mir, dass die besonders lange brauchen zum Beenden. Beispielsweise Surveillance Station dauert bei schon mal recht lange.

    Gefühlt sind es 30 Minuten.


    Es dauert halt sehr lange. Andere Hersteller schaffen den reboot in unter 5 Minuten und sind danach bereits nutzbar. Beim Qnap brauchen die Dienste allein eine gefühlte Ewigkeit zum Start.


    Dazu kommt, kein anderer Hersteller fragt nach einem Neustart des Geräts vor der Ausführung eines Updates. Zumindest kenne ich keinen.

    Das Thema (Neustart vor Update) wurde übrigens recht frisch erst im US Forum angesprochen: https://forum.qnap.com/viewtopic.php?t=165882


    Unterm Strich ist das im Supportfall bestimmt sowas wie Disks die nicht auf der Kompatibilitätsliste stehen. Geht was schief und hast Du vorher keinen Neustart gemacht, dann lag es sicherlich genau daran, schließlich hast Du Dich nicht an die Vorgaben (na gut, Empfehlung) gehalten.

    Meine Syno schafft es >3 Minuten. Da sind auch bereits alle Dienste geladen.

    Ich wollte hier eigentlich keinen Wettbewerb à la "Meiner ist schneller" initiieren. ;)

    Für sowas müssten auch belegbare Angaben zu den jeweiligen Diensten/Anwendungen herangezogen werden.

    Geht auch nicht um den Wettbewerb ^^.

    Aber sowohl bei meinen alten Cat1 NAS als auch den Celvins dauert Boot/Shutdown jeweils ca. 5 Minuten. Wobei der Shutdown gefühlt schneller ist, als der Bootvorgang.


    Auf dem TS-473A dauert beides deutlich länger, mind. 10 Minuten, wenn nicht sogar 15 Minuten, ein Reboot also 20-30 Minuten.

    Das ist für ein NAS schon etwas "suboptimal" und m.E. eigentlich mehr als grenzwertig (da kommen wir wieder zu meinem Lieblingsthema "QNAP taugt nicht für geschäftlichen Einsatz" :S).

    Das war schon seit der ersten 5.0 beta (soweit ich mich erinnere).

    Aber da laufen eine eine ganze Reihe unnötiger Dienste mit, wie die QuFirewall, Security Counselor, VS, usw. usw.

    Die laufen dort nur, weil ich das System zum testen nutze.


    Wenn ich unsere Enterprise Storage Büchsen mit über 1.000 HDDs einschalte, dann sind die in weniger als 15 Minuten einsatzbereit.


    Allerdings werden die auch online (soll heißen im Betrieb) mit neuer Firmware versorgt, die sind HA-ausgebaut. 8)

    Ausgeschaltet werden die nur zum Umzug in ein anderes RZ.


    Gruss

    Auf Wettbewerb will ich auch nicht hinaus. Nur sagen, daß es schon möglich wäre den Start,- Shutdown-Prozess bei QNAP zu optimieren.

    Um Deine -Anmerkung nicht gänzlich unbeantwortet zu lassen:


    Syno dient als Mai,- Web und DB -Server und Sicherungsziel (rsync). Beherbergt u. a. 16TB Daten.

    Wird im LAN als Medienserver und für etliche andere Sachen missbraucht

    Außerdem laufen 3 VMs.


    Wie gesagt, Startzeit unter 3 Minuten.


    QNAP genutzt als Storage. 8 TB Nutzdaten. Dienste SMB, SNMP.und VS mit einer VM und rsync

    Startzeit etwa 7 Minuten.

    Zitat von rednag

    Syno dient als Mai...

    Ja dann, ich benutze das NAS das ganze Jahr über... :D


    SCNR

    Das ist alles schön und gut. Nur dass ich jetzt deswegen nicht mein einziges NAS, die TVS-882, durch irgend etwas anderes ersetzen werde. Da bin ich bestimmt nicht der einzige hier im Forum. Daher war mein Anliegen mit dem Start dieses Themas, die Möglichkeit eines beschleunigten Wiederauflebens des NAS bei einem Update der FW zu diskutieren. Den Weg: "Verscherble Dein QNAP und ersetze es durch ein Syno/Windows Server oder was es sonst noch gibt" halte ich dabei nicht für die Lösung.


    Ansonsten mag die Diskussion über unterschiedliche Systeme und deren jeweiligen Vorzüge und Schwächen natürlich durchaus interessant sein. Vielleicht würde ich mich bei einem Neukauf heute auch anders entscheiden, aber im Großen und Ganze bereue ich meine Entscheidung seinerzeit für mein erstes QNAP absolut nicht.

    Also, ob "3" oder "30" Minuten ist doch subjektiv gefühlt, egal.

    Bei Werbepausen beim Fernseh schauen, macht man ja auch:----pinkeln, rauchen, Bier aus dem Keller holen, oder sonst was.


    Bitte als spaßige Anektode sehen.


    Perönlich ist mir die Laufzeit der Update's egal, Haupsache alles funzt danach!

    Diesbezüglich habe ich noch keine Schwierigkeiten zu vermelden.

    Zitat von duke-f

    Seit einiger Zeit will ja mein NAS aus unerklärlichen Gründen nach jedem Neustart, dass ich das Filesystem meines Volume0 ("System-"Volume) checken lasse - ist lästig.

    Ich bin nach wie vor der Meinung, dass du auf dem NAS eine Drittanbieter App installiert hast, die den Unmount der Platten blockiert.

    Der Meinung bin ich eigentlich auch - kann sie nur nicht ausmachen, ohne alles nochmal von vorne aufzuziehen. Es scheint mir so zu sein, dass nicht die Drittanbieter-App direkt selber den Ausschlag gegeben hat, sondern sich die Inkompatibilität erst mit einem den nachfolgend aktualisierten QNAP-Apps ergeben hat.


    Lass uns aber lieber aufpassen, sonst wird's off topic, das mag der Moderator nicht.:P


    Nein, im Ernst. Ich habe da meine TVHeadend-Installation im Blick. Diese hat gewisse Eigenschaften, die sicher nie hinsichtlich genau meines NAS entwickelt wurden. Allerdings lief dies jahrelang in genau dieser Konstellation ohne Anstand. Und leider ist genau dies für mich eine meiner meistgenutzten Hauptanwendungen neben den sonstigen Server-Aufgaben und den VMs.