Absicherung gegen Spectre-NG: "Foreshadow"

  • Weil ein Big-Data Datenbank Cluster drauf läuft und wenn ich die Server nich vorher rausnehme, dann muss ich während der Geschäftszeiten einen Re-Balance machen um die Integrität im Falle eines weiteren Server-Ausfalls sicher zu stellen (ja, auch während Wartungsarbeiten können andere Server ungeplant ausfallen)

    Du legst also deine geschäftskritischen Datenbanksysteme auf n+1 Redundanz aus?

    Angenommen du hast Rootserver, so darf jeder davon 8h pro Jahr ausfallen, ansonsten musst du deine Redundanz auf n+1 Rechenzentren erhöhen.


    Ins Blaue geraten: Apache Cassandra. Cassandra lässt eine höhere Redundanz zu und so ein Cluster verträgt den kurzfristigen Austieg mehrerer Nodes perfekt.

  • Du legst also deine geschäftskritischen Datenbanksysteme auf n+1 Redundanz aus?

    Angenommen du hast Rootserver, so darf jeder davon 8h pro Jahr ausfallen, ansonsten musst du deine Redundanz auf n+1 Rechenzentren erhöhen.


    Ins Blaue geraten: Apache Cassandra. Cassandra lässt eine höhere Redundanz zu und so ein Cluster verträgt den kurzfristigen Austieg mehrerer Nodes perfekt.

    Nein und nochmal Nein - leider gleich 2 mal falsch geraten :)


    Es gibt N nodes im Cluster und von den Daten gibt es M Replikate - wenn nun aber M Server gleichzeitig ausfallen dann sind einige Datensätze möglicherweise vorübergehend nicht mehr erreichbar. So lange nur M-1 Server ausfallen ist es kein Problem. Aber bereits beim Ausfall von M-1 Servern kann es bei einzelnen Datensätzen zu Verlangsamungen kommen da im Worst-Case nur noch 1 Server diesen Datensatz hält und er somit zum Flaschenhals wird.


    In diesem Fall müsste man aus Gründen der Datensicherheit sofort einen Rebalance machen um im nun verkleinerten Cluster wider M Replikate sicher zu stellen - das würde aber auf dem ohnehin schon stark belasteten Server eine auf jeden Fall spürbare Verlangsamung auslösen. Im Disaster-Fall wäre das natürlich noch immer besser als ein Totalausfall, aber eben nichts was man sich bei geplanten Wartungsarbeiten antut. Deshalb entferne ich lieber vorher die Nodes und füge sie später wieder hinzu. So ist die Zusatzbelastung von einem Rebalance außerhalb der Stoßzeiten.


    Zusätzlich gibt es noch einen 2. Cluster (Notfall-System) bei einem anderen Hoster - dorthin gibt es eine Cross-Data-Center-Replikation - d.h. dort sind alle Daten nochmal vorhanden (bis auf ein ganz kleines Delay - schwankt meist zwischen 30 und 400ms) und wenn am Hauptsystem tatsächlich mehr als M-Nodes gleichzeitig ausfallen würden, so wären die Daten am Notfall-System mit verringerter Leistung noch immer abrufbar.


    Und bei der Datenbank handelt es sich im Couchbase und nicht um Cassandra.

  • Man hat einen Node mit z.b. 10 Kunden mit jeweils einer VM. Jeder Kunde hat andere Zeiträume angekreuzt wodurch es dann quasi keine bzw nur sehr wenige Überschneidungen gibt.


    Verstehe. Ich ging davon aus, dass die VMs im Zuge dieser Wartungsmaßnahmen auf andere Hostsysteme verschoben werden. Also: fertig gepatchtes (leeres) Hostsystem steht bereit, VMs werden heruntergefahren, verschoben auf das vorbereitete Hostsystem und dort wieder gestartet. Sobald ein ungepatchter Host leer geräumt ist wird dieser gepatcht und steht dann für die nächsten VMs als Ziel-Host bereit.

  • Das wäre ja automatisiert möglich :)


    update: Ich hatte das ja auch gehofft. Aber mal so jede VM einmal durch die Gegend schubsen freut sicherlich auch das Netzwerk.

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

  • Verstehe. Ich ging davon aus, dass die VMs im Zuge dieser Wartungsmaßnahmen auf andere Hostsysteme verschoben werden. Also: fertig gepatchtes (leeres) Hostsystem steht bereit, VMs werden heruntergefahren, verschoben auf das vorbereitete Hostsystem und dort wieder gestartet. Sobald ein ungepatchter Host leer geräumt ist wird dieser gepatcht und steht dann für die nächsten VMs als Ziel-Host bereit.

    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ß

  • Es scheint sich was getan zu haben, denn ich habe eben Mails für meine Server bekommen, dass diese am 4. September gewartet werden. Somit wurde wohl die Vorankündigungszeit erhöht.

    Oder es liegt einfach am Wochenende dazwischen ....

    9 von 10 Stimmen in meinem Kopf sagen ich bin nicht verrückt, die letzte summt ständig die Melodie von Tetris.

  • 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ß

    Also zuerst sorry für das Messer in den Rücken, aber bei einer gut geplanten Infrastruktur muss da nicht mal 1 KB an Daten verschoben werden.

    Das setzt natürlich voraus, dass der Storage nicht lokal auf dem Hostsystem läuft, oder zumindest verteilt auf mehrere Systeme. Dann kann via NFS / CIFS / SAN der Storage der VM´s einfach an ein anderes Muttersystem gehängt werden und die VM kann fast ohne Downtime auf das neue System verschoben werden.


    Unsere Server bei Netcup sind natürlich nicht kritisch und können auch mal Tage weg sein, für unsere HA Anforderungen nutzen wir die M. Cloud - dort zahlen wir aber auch ein vielfaches mehr. Dort ist es zum beispiel wie oben gelöst, fällt ein Hostsystem aus, schwenken alle VM´s automatisch auf ein anderes Hostsystem und alles ist gut.

    Sorry aber das konnte ich jetzt nicht so stehen lassen, denn andere Anbieter haben ein vielfaches an Servern, da wird auch nichts kopiert.

  • dort zahlen wir aber auch ein vielfaches mehr

    Sorry aber das konnte ich jetzt nicht so stehen lassen, denn andere Anbieter haben ein vielfaches an Servern, da wird auch nichts kopiert.

    Wie du schon selbst erkannt hast, kosten andere Anbieter aber auch mehr.

    Ich vermute mal, Netcup könnte uns nicht diese Preise bieten, wenn diese Art von Infrastruktur dahinter stecken würde.

    Meine (Netcup) Produkte: S 1000 G7, VPS 200 G8 Ostern 2019, IPs, Failover..

  • Das setzt natürlich voraus, dass der Storage nicht lokal auf dem Hostsystem läuft, oder zumindest verteilt auf mehrere Systeme.

    Ich möchte das Thema hier wirklich nicht ins Offtopic ziehen, aber von der Performance her ist lokal meiner Erfahrung nach meistens um Welten besser. Warum? Weil kein Netzwerk dazwischen hängt mit allen Nachteilen wie zusätzlicher Ressourcenbedarf und Latenz. So ein Setup kann sich außerdem schnell zum SPOF entwickeln, wenn nicht gut geplant wird. Klar, es gibt genügend Anwendungsfälle, wo so ein Setup Sinn macht. Die vServer von netcup würde ich eher nicht dazu zählen. Dafür würden sie zu wenig davon profitieren bzw. das Feature nicht erforderlich machen.


    Bitte bei Bedarf einen neuen Thread dazu aufmachen oder im längsten Thema weiter diskutieren. Sonst wird es hier unübersichtlich… :)

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Also zuerst sorry für das Messer in den Rücken, aber bei einer gut geplanten Infrastruktur muss da nicht mal 1 KB an Daten verschoben werden.

    Das setzt natürlich voraus, dass der Storage nicht lokal auf dem Hostsystem läuft, oder zumindest verteilt auf mehrere Systeme. Dann kann via NFS / CIFS / SAN der Storage der VM´s einfach an ein anderes Muttersystem gehängt werden und die VM kann fast ohne Downtime auf das neue System verschoben werden.

    Bei allen Cloud-Anbietern (egal ob AWS, Google, Azure, Digital Ocean, Rackspace, ...) gibt es lokale Disks und diese werden für vielerlei Anwendung auch verwendet, da sie einfach deutlich schneller sind. Ich kann mir bei den von dir genannten Cloud-Anbietern aber auch Block-Storage holen der dann irgendwo anders liegt. Das mag zwar in Punkte teilweise Datendurchsatz durchaus vergleichbar sein mit lokalen Festplatten die Latenzzeit ist deutlich höher. Für meine Anwendung wäre ein Block-Storage ein totales KO-Kriterium, für andere Anwendungen hingegen mag das durchaus das perfekte Speichersystem sein. Ein Block-Storage kann immer nur eine Ergänzung oder Alternative sein, aber er wird niemals lokale Festplatten ersetzen können.

  • Bei allen Cloud-Anbietern (egal ob AWS, Google, Azure, Digital Ocean, Rackspace, ...) gibt es lokale Disks und diese werden für vielerlei Anwendung auch verwendet, da sie einfach deutlich schneller sind. Ich kann mir bei den von dir genannten Cloud-Anbietern aber auch Block-Storage holen der dann irgendwo anders liegt. Das mag zwar in Punkte teilweise Datendurchsatz durchaus vergleichbar sein mit lokalen Festplatten die Latenzzeit ist deutlich höher. Für meine Anwendung wäre ein Block-Storage ein totales KO-Kriterium, für andere Anwendungen hingegen mag das durchaus das perfekte Speichersystem sein. Ein Block-Storage kann immer nur eine Ergänzung oder Alternative sein, aber er wird niemals lokale Festplatten ersetzen können.

    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 noch mal ich wollte das ganze nicht ins Offtopic ziehen.