die Gastsysteme nicht zu rebooten, sondern in den 'Suspend-to-Disk' zu schicken?
Ich wäre da vorsichtig. Bei dem Update könnte sich die "Hardware", welche von KVM "emuliert" wird, ändern. Da könnte sich so ein pausiertes System dran verschlucken. Korrekt herunterfahren sollte immer die beste Maßnahme sein.
Wir wissen ja schließlich nicht, was netcup genau macht. Ob einfach nur ein Patch eingespielt wurde, oder ob eine komplett neue Kernelversion ausgerollt wird.
Es wurde ja auch die KVM Version geupdatet. Da muss die VM immer komplett herunter gefahren und wieder gestartet werden, damit diese Änderungen für die VM wirksam werden.
klar ein wesentlicher Unterschied besteht, ein 'Suspend-to-Disk' kann bei großen vServern in Summe länger dauern, weil nicht zwingend parallelisiert werden kann,
aber das ACPI-Signal zum Shutdown bekommen alle glztg. und nach 5 Minuten und ein paar Sekunden kann der eigentliche Reboot des Wirtsystems stattfinden;
Das könnte manchen Gastsystemen aber noch weniger gefallen als ein ACPI-Signal… 
verschoben
würde es denn Sinn machen, die Gastsysteme nicht zu rebooten, sondern in den 'Suspend-to-Disk' zu schicken?
Bei anschließenden Auftauen der Maschinen würde dann allerdings die Systemzeit innerhalb des vServers um die vergangene Zeitspanne nach vorne springen. Ob damit jede Software klar kommt, kann ich nicht einschätzen.. Ich bin daher für einen sauberen ACPI Reboot. Mich verwundert aktuell nur die Menge an Leuten, die sich hier mit dem Hinweis melden, dass das mit dem Stichwort "sauber" bei ihnen nicht geklappt haben soll..
Zuerst mal vielen Dank an Netcup für den tollen, professionellen Service, und die offene Kommunikation, die sie hier bieten. Weiter so 
Bezüglich der "nicht sauber" heruntergefahrenen Gastsysteme:
Könnte es sein, dass dadurch, dass alle VMs den ACPI Befehl (fast) gleichzeitig bekommen es auf manchen Hosts zu Überlastungen kommt? Also besonders auf Systemen mit SAS-Platten. Wenn die CPU-Last dann hoch ist, und viele VMs gleichzeitig noch versuchen Daten auf die Platte zu schreiben, könnte ich mir vorstellen, dass es zu ordentlichen Verzögerungen kommt. Ob die so groß sind, dass die 5 Minuten, die Netcup wartet, überschritten werden, das ist natürlich eine andere Frage.
Vielleicht kommt es ja zu einer unglücklichen Verkettung von mehreren Umständen.
z.B. habe ich gelesen, dass einige HPE Raids Probleme hatten.
Könnte es sein, dass diese vielleicht noch Daten im Cache hatten, die noch nicht auf die Platte geschrieben wurden?
Grüße,
Andreas
Display More
Bezüglich der "nicht sauber" heruntergefahrenen Gastsysteme:Könnte es sein, dass dadurch, dass alle VMs den ACPI Befehl (fast) gleichzeitig bekommen es auf manchen Hosts zu Überlastungen kommt? Also besonders auf Systemen mit SAS-Platten. Wenn die CPU-Last dann hoch ist, und viele VMs gleichzeitig noch versuchen Daten auf die Platte zu schreiben, könnte ich mir vorstellen, dass es zu ordentlichen Verzögerungen kommt. Ob die so groß sind, dass die 5 Minuten, die Netcup wartet, überschritten werden, das ist natürlich eine andere Frage.
Vielleicht kommt es ja zu einer unglücklichen Verkettung von mehreren Umständen.
z.B. habe ich gelesen, dass einige HPE Raids Probleme hatten.
Könnte es sein, dass diese vielleicht noch Daten im Cache hatten, die noch nicht auf die Platte geschrieben wurden?
Grüße,
Andreas
Diese Vermutung hatte ich auch bereits. Das würde sich aber mit der Aussage der betroffen beißen, dass die Server gar kein Signal erhalten hätten. Ist jetzt natürlich die Fragen, ob das nur dessen Vermutung aufgrund beschädigter Dienste ist, oder ob sie wirklich im Syslog keinen Eintrag für das erhaltene ACPI-Signal stehen haben ...
..., ob das nur dessen Vermutung aufgrund beschädigter Dienste ist, oder ob sie wirklich im Syslog keinen Eintrag für das erhaltene ACPI-Signal stehen haben ...
wenn dem so ist, daß zwar alle das Signal bekommen, und eben manche schneller sind, und das System derart beanspruchen, dann wäre es durchaus denkbar, daß zwar das Signal ankommt, aber es im Syslog nicht auftaucht, weil durch die Beanspruchung des Wirtsystems kaum Resourcen an den einen oder anderen Gast verteilt werden, und diese dann hart abgeschalten werden ...
von daher wäre es von Vorteil das Signal nicht glztg. an alle vServer sondern in Tranchen versetzt um 20-30 Sekunden;
wobei wieviele Gastsysteme sind auf einem Knoten/Wirtsystem?
Also von mir wurde bisher ein Server neugestartet (Nameserver, Debian Stretch). Leider auch abgewürgt, was ich am tuptime Status erkenne (1 bad shutdown). Ein weiteres Indiz waren die von Fail2ban erhaltenen Mails über gestartete Jails, normalerweise erhalte ich Mails über gestoppte UND gestartete Jails. Server hatte also keine Zeit/Chance den Dienst zu beenden.
Hat meinen System zum Glück nicht geschadet.
Also von mir wurde bisher ein Server neugestartet (Nameserver, Debian Stretch). Leider auch abgewürgt, was ich am tuptime Status erkenne (1 bad shutdown). Ein weiteres Indiz waren die von Fail2ban erhaltenen Mails über gestartete Jails, normalerweise erhalte ich Mails über gestoppte UND gestartete Jails. Server hatte also keine Zeit/Chance den Dienst zu beenden.
Hat meinen System zum Glück nicht geschadet.
das ist ein Einzellfall, in diesem Thread wird ebenso ueber abgeschossenen Server gesprochen:
https://forum.netcup.de/admini…eltdown-spectre/?pageNo=8
Es ist nur eine Frage der Zeit wann die ersten abgeschossenen Server nicht sauber hochfahren, besonders wenn in den Naechsten Wochen weitere Reboots von Seitens NC erfolgen
Ich wollte mit meinem Beitrag auch eher aussagen, dass ich ein kleines Setup habe (Debian + NS), welches beim Shutdown keine lange Zeit benötigt, um die Dienste zu beenden und herunterzufahren. Es reagiert instant auf ACPI-Befehle und ist down.
Dementsprechend ist es komisch, dass trotz ACPI mein System offensichtlich abgeschossen wurde, was die Annahme weiterer User bekräftigt, dass beim Massenshutdown per ACPI scheinbar Probleme auftreten, die netcup wohl bisher noch nicht nachvollziehen konnte.
Wäre ja eigentlich jetzt die Gelegenheit für netcup, der Ursache auf den Grund zu gehen.
mein vServer (CentOS) hat folgende Dienste
- named (DNS)
- httpd (Apache)
- opendkim
- opendmarc
- openvpn
- squid
- mysqld
- postfix
wenn ich den mit shutdown -r now neu starte ist der binnen 1-2 minuten wieder neu gestartet ...
Guten Morgen,
das mit dem "Suspend-to-Disk" geht bei einem einzelnen System. Wenn ein ganzer Node mit mehreren hundert GB RAM suspended wird, wird dieses längere Downtimes mit sich bringen.
Hinsichtlich der ACPI-Shutdown-Probleme forschen wir jetzt weiter. Auch wird es ab heute E-Mails geben, kurz bevor der Reboot durchgeführt wird.
Sehr spannend zur Thematik Spectre im Linux-Kernel ist folgender Artikel: http://kroah.com/log/blog/2018/01/06/meltdown-status/
Z.B. Red Hat / CentOS bringen angeblich Fixes gegen Spectre mit. Es deutet vieles darauf hin, dass diese nicht ausreichend sind. Allerdings ist Spectre an sich in der Tat sehr schwer ausnutzbar.
Viele Grüße
Felix
Hallo,
kann es sein, daß das Image f. CentOS 6 den ACPI Dienst/daemon nicht mit an Board hat?
hatte es vorhin installiert und gestartet ...
Nochmals ein ganz klares 
dafür!
Quote from Information zum Server v2201801123499999Display MoreGuten Tag Max Mustermann,
wie bereits am vergangenen Freitag angekündigt, ist ein Neustart Ihres Servers
v2201801123499999
erforderlich.
Dieser Neustart wird innerhalb der nächsten 60 Minuten ausgeführt werden.
Vielen Dank für Ihr Verständnis!
Mit freundlichen Grüßen / best regards
Ihr netcup Team
Danke netcup.
Dort stand jetzt aber nicht "Max Mustermann", oder? 
Nein, natürlich nicht. v2201801123499999 ist genauso frei erfunden…
Hui, Schrecksekunde vorüber!
Danke für die Aufklärung!
Zu Spectre und Meltdown
Erstmal vielen Dank [netcup] Felix P., dass er sich hier so engagiert und uns beruhigt und Updates bringt und vielen herzlichen Dank @Netcup-Team, dass sie so hart arbeiten um unsere Systeme sicher zu halten.
Ich bin bei dem ganzen Thema allerdings etwas anderer Meinung als felix. Zum einen bin ich nicht sicher, ob das alles so dringend sein muss, da noch niemand von Implementierungen spricht, die die Lücke nutzen. Gepatcht werden muss natürlich zeitnah, was ich aber als "Wochen" und nicht als "Tage" auffasse. Ich werde meine Server sicher diese Woche noch patchen, mache mir deshalb aber keine schlaflosen Nächte. Zum anderen gehe ich, aufgrund der Natur der Probleme, schon davon aus, dass es, statistisch gesehen, zu prozentual zweistelligen Leistungseinbußen kommt. Ob diese "spürbar" sind, steht auf einem anderen Blatt. Allerdings bin ich kein Experte. [netcup] Felix P. weiß eher wovon er redet als ich.
Meine Links zu dem Thema. Einmal eine einfache Erklärung (englisch):
https://ds9a.nl/articles/posts/spectre-meltdown/
Und dann ein paar Kommentare aus einem Interview mit Theo de Raadt (OpenBSD):
https://www.itwire.com/securit…d-openbsd-s-de-raadt.html
Theo ist, genau wie viele andere aus der Community, ziemlich ungehalten darüber, wie Intel und Google mit dem Problem umgehen. Auch wenn Netcup das hier bravourös managt, wird uns diese Geschichte noch eine ganze Weile beschäftigen.
