Absicherung gegen Spectre-NG: "Foreshadow"

    Zitat von 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".

    Zitat von 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?

    Zitat von 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 :P

    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.

    • Offizieller Beitrag
    Zitat von Christoph L.

    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.

    Die Server werden per ACPI herunter gefahren. Nur wenn diese 5 Minuten nach absetzen des ACPI Shutdowns noch nicht beendet sind, werden diese hart ausgeschaltet.


    Sofern das Betriebssystem also den ACPI Befehlen nachkommt, wird der Server auch sauber heruntergefahren. Wenn ein Server hart ausgeschaltet wurde empfiehlt sich mal zu prüfen warum das Gastbetriebssystem nicht auf ACPI reagiert.

    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 :)

    Zitat von forum-netcup

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

    Siehe:

    Zitat von [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

    Matrix: @nan0:nan0.dev - IRC: nan0 on hackint.org - Discord? Nein danke!

    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 :)

    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.

    "Security is like an onion - the more you dig in the more you want to cry"