Absicherung gegen Spectre-NG: "Foreshadow"

Quote from sven88

Sorry ich wollte nicht eure Welt auf den Kopf stellen. Ich kenne wirklich kein produktives System bei einem Konzern oder im Mittelstand das auf lokalen Festplatten läuft. Selbst die größten SAP Systeme die ich gesehen habe >30TB laufen auf ner 3Par oder Netapp ohne Probleme, da würde auch keiner auf die Idee kommen das auf lokalen festplatten abzubilden. Ich habe bei Azure z.b gar keine Möglichkeit lokale Festplatten zu verwenden, dass kannst du mir gerne mal zeigen oO?

Die lokalen festplatten werden jetzt erst durch hyper converged sehr interessant z.b Nutanix wäre evtl. was für Netcup.

Sorry, ich will ja dein Weltbild nicht zerstören, aber SAP Systeme egal wie groß haben keine Realtime-Erfordernis - da ist es wirklich egal ob ein paar Millisekunden beim dazukommen, aber es ist nicht egal wenn Daten verloren gehen --> Ergo würde das wirklich niemand auf lokalen Platten laufen lassen, vor allem da darunter eine klassische SQL-Datenbank läuft die sich nur sehr bedingt horizontal skalieren lässt.

Wenn ich aber ein verteiltes Datenbank-System betreibe, das durch seine Verteilung bereits eine Redundanz integriert hat, wäre eine weitere Redundanz bei Disks nur ein unnötiger Overhead der Performance kosten würde --> Ergo betreibt man so etwas auf lokalen Disks

Wenn es bei Systemen um Realtime-Entscheidungen geht (z.B. automatisierte Entscheidungen auf Grund von Aktienkursen) dann setzt man auch auf lokale Disks, denn da ist jede Millisekunde die ich schneller bin als mein Mitbewerber bares Geld.

Für meinen Anwendungsfall ist Performance das allerwichtigste - deshalb bin auch bei Netcup wo es schnelle lokale Festplatten gibt und nicht bei Mitbewerbern die teilweise auf Network-Storages setzen. Natürlich könnte ich auch auf AWS gehen aber da bezahle ich das vielfach für die gleiche Leistung - mein System hat ohnehin eine integrierte Redundanz und da hänge ich bei Netcup lieber ein paar mehr Server dazu und bezahle am Ende noch immer deutlich weniger als bei AWS.

Und auch bei Azure haben die Server lokale Disks (siehe z.B. https://docs.microsoft.com/en-…nes/windows/sizes-general - Spalte "Local SSD: GiB".

Hallo, ich weiß nicht was genau passiert ist. Mein Neustart war von 9-11 Uhr terminiert, hat soweit auch statt gefunden.

Allerdings teilte mir monit schon um 7 uhr mit, ssh nicht mehr erreichen zu können.

Jetzt ist der SSH-Login plötzlich extrem langsam ( ca 5 Sekunden), nachdem das Passwort eingegeben wurde. Selbiges gilt auch wenn ich mit su in irgend einen anderen Nutzer gehe (nachdem ich schon mit ssh drin bin). An der Auslastung auf der Maschine kann es nicht liegen.
Irgendwelche Ideen ? (Außer UseDNS no, was bei su auch nichts bringen kann.)

Bei mir leider nach dem Neustart das gleiche Problem wie nach dem letzten CPU-Hotfix im Januar. Meine Server bekommt vom netcup-DHCP-Server erneut keine IP zugewiesen und ich kann deshalb weder mit dem Server noch der Server mit der Außenwelt kommunizieren.

Kann über die VNC Console zwar noch auf den Server, von dort kann ich jedoch nichtmal den Netcup eigenen Gateway mehr anpingen, immer "Host unreachable".

wordsongoku IPv4 und IPv6 bitte statisch konfigurieren. Damit hat man bessere Karten, auch für die Zukunft.

Quote from H6G

wordsongoku IPv4 und IPv6 bitte statisch konfigurieren. Damit hat man bessere Karten, auch für die Zukunft.

Hatte ich beim letzten Mal alles versucht, hat aber alles keine Abhilfe geschafft bis dann ein Mitarbeiter den Server mit irgendeinem Tool (hab den Namen vergessen) gebootet hat und dort Anpassungen vorgenommen hat.

Quote from wordsongoku

Meine Server bekommt vom netcup-DHCP-Server erneut keine IP zugewiesen und ich kann deshalb weder mit dem Server noch der Server mit der Außenwelt kommunizieren.

Quote from wordsongoku

Hatte ich beim letzten Mal alles versucht

Offenbar nutzt du derzeit die DHCP Server und keine statische Konfiguration

Quote from H6G

Offenbar nutzt du derzeit die DHCP Server und keine statische Konfiguration

Das ist richtig, aber auch das setzten einer statischen IP macht keinen Unterschied. Auch im Rettungssystem (iPXE) kann das Netzwerk nicht konfiguriert werden.

Quote from wordsongoku

Das ist richtig, aber auch das setzten einer statischen IP macht keinen Unterschied.

Nur weil es damals einen Fehler gab, heißt das nicht, dass du das nicht statisch einstellen sollst.

Wenn es trotz statischer Konfiguration einen Fehler gibt?!, dann ist das evtl. ein Fall für den Support.

Gibt es denn aktuell mit einer statischen Konfiguration Fehler?

Quote from H6G

Nur weil es damals einen Fehler gab, heißt das nicht, dass du das nicht statisch einstellen sollst.

Wenn es trotz statischer Konfiguration einen Fehler gibt?!, dann ist das evtl. ein Fall für den Support.

Gibt es denn aktuell mit einer statischen Konfiguration Fehler?

Ja auch mit der statischen Konfiguration kommt keine Verbindung zustande. Muss zudem beim nächsten erfolgreichen Start den Timeout bzgl. "raise network devices" runterstellen, da sowohl bei statischer als auch bei automatischer Zuweisung der Bootvorgang jedes mal bei "raise network devices" stecken bleibt und ich die 5 Minuten abwarten muss

Zum Glück war der Support sehr schnell, Problem konnte behoben werden und der Server mag auch wieder mit der Außenwelt reden Danke!

Hallo, mein FreeBSD Server kam nach dem heutigen Update nicht am automatischen fsck vorbei.

Ich musste fsck wiederholt manuell ausführen.

Fahren Sie die Server denn nicht mittels ACPI Signal herunter?

Ich kann man an das gleiche Problem bei den Spectre Patches erinnern, auch damals haben sich schon Kunden über das sehr ruppige Ausschalten der Server beschwert.

Ein ACPI Shutdown an alle Server fünf Minuten bevor es dann kracht sollte doch möglich sein.

Moin zusammen,

da ich mich ja eher auch nur melde wenn mal etwas nicht geht, wollte ich Heute mal aus der Reihe tanzen

Heute Vormittag sind die letzten Server dem Update zum Opfer gefallen und ich muss sagen, ich bin begeistert.

- Offene Kommunikation mit den Kunden

- Rechtzeitige Vorankündigung (Vorwarnung und auch tatsächlicher Termin)

- Reibungsloser Ablauf

.....und am Ende war alles so als wäre nie was gewesen.

Also mit einem aktuellen CentOS 7 gibt es keine Probleme.

Deswegen vielen Dank an dieser Stelle an das gesamt netcup Team das mit Sicherheit eine Menge Arbeit dadurch hat!

Ihr macht einen sehr guten Job und wenn immer alles richtig laufen würde, dann wäre das auch nicht allen recht

Technische Frage: Warum verschiebt man die KVMs nicht wie bei vmware esxi via vmotion in paar ms auf einen anderen Server?

Quote from forum-netcup

Technische Frage: Warum verschiebt man die KVMs nicht wie bei vmware esxi via vmotion in paar ms auf einen anderen Server?

Siehe:

Quote from [netcup] Felix

Das geht in Einzelfällen und wir tun das ja auch bereits bei Wartungsarbeiten an einzelnen Nodes. Wenn wir jedoch je Node 20 TB an Daten und so in drei Tagen 40000 TB bewegen müssten, würde die IO-Leistung massiv zusammenbrechen und auch der gesamte Migrationsprozess sehr lange dauern. Bei den kleinen schnelles SSD-Nodes sieht das natürlich etwas einfacher aus. Bei den SAS-Nodes würde das leider niemals klappen.

Mit freundlichen Grüßen

Felix Preuß

Bzw. Seite 3

Ein Neustart eben hat statt 30 Minuten ganze 90 Minuten gedauert.

Ich empfand den Zeitraum und die Benachrichtigung seitens Netcup sehr angenehm und angemessen.

Das einzige was bei mir etwas merkwürdig war, war dass der Verbindungsaufbau per ssh, http, und zu ein paar selbstgeschriebenen Diensten merkwürdig lang dauerte. Das hat sich aber mit einem Reboot erledigt scheinbar - merkwürdig. Werd das mal beobachten

Hm. So richtig toll lief das ja nicht. Server wieder hochgekommen, aber mein /var/log-LVM ist leer.

Wie viel % der Server sind den inzwischen durch?

Bei mir lief alles problemlos. Vorher hatte ich per ACPI-Shutdown den Reboot selbst schon mal getestet und bei dem echten Reboot durch netcup lief dann alles wie getetest.