Beiträge von peda

Zitat von [netcup] Felix

Wir können leider nicht zu 100% den genauen Zeitpunkt nennen. Da die Reboots aber nacheinander stattfinden, stellen wir hier sicher das sie nicht genau zusammen stattfinden. In dem Zeitfenster haben wir ja eine kleine Zeitspanne für die eigentliche Nichterreichbarkeit genannt.

Zitat von rbrt.mrz

Entgegen der Darstellung in einigen Beiträgen hier sollen meine beiden RS 500 (selbes Produkt) in einem sich überschneidenden Zeitfenster neu gestartet werden. Ironischerweise habe ich tatsächlich vor, beide zu einem Cluster zusammenzuschalten, was in diesem Fall aber leider nicht helfen wird. Die Server IDs kann ich bei Bedarf gerne mitteilen, die beiden Zeitfenster sind

Diesmal habe ich mehr Glück mit meinen Zeiten (Abstand von mehreren Stunden bzw. Tagen zwischen den Servern) als beim letzten Update und die Vorlaufzeit ist auch deutlich länger (hatte das letzte Mal nicht ganz 24 Stunden, diesmal sind es mehrere Wochen) - dafür schon mal ein großes Danke an Netcup

Ich hatte beim letzten Update fast das gleiche Problem wie rbrt.mrz - der Abstand zwischen meinen Servern betrug exakt 10 Minuten - das ist auch mit einem HA-Cluster (wie in unserem Fall) ein Risiko. Zur Sicherstellung der Datenintegrität braucht man in bestimmten Fällen N/2 + 1 Nodes in Betrieb.

Der Neustart dauert ca. 5-7 Minuten, d.h. für den Rebalance bleiben 3-5 Minuten bevor die nächste Node runter fährt - das kann zu wenig sein und wenn das der Reihe nach so geht, kann es passieren, dass man am Ende mit weniger als N/2 + 1 Nodes mit aktuellem Datenbestand dasteht.

Wir mussten deshalb beim letzten Update einige zusätzliche Cloud-Server für die Zeit der Wartung anmieten und unseren HA-Cluster vergrößern, damit die Netcup Nodes weniger als N/2 Nodes darstellen.

Das wäre zwar am Ende nicht notwendig gewesen, da die Reboots sofort am Beginn des Zeitfensters erfolgt sind (und auch nur wenige Minuten dauerten) aber Vorsicht ist nun mal besser als Nachsicht.

@ felix

Wie bereits beim letzten Mal erwähnt, vielleicht kann man den Algorithmus dahingehend optimieren, dass zwischen Nodes des gleichen Kunden in der gleichen Generation zumindest 20-30 Minuten liegen - das sollte für (fast) jede Art von HA-Clustern reichen.

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

Zitat von sven88

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.

Zitat von H6G

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.

Zitat von H6G

Ich verstehe nicht, warum man Systeme manuell aus einem Cluster nehmen muss und sie dann wieder manuell einhängen muss.

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) - Ein Rebalance zu Stoßzeiten hätte dann einen direkten Performance-Impact auf den laufenden Betrieb. Wenn ich die betroffenen Server aber in der Nacht davor manuell rausnehme und der Nacht darauf manuell wieder rein hänge, dann habe ich den Rebalance in der Nacht und nicht während der Stoßzeiten.

Zitat von absence

Etwas mehr Vorlaufzeit hätte ich mir schon gewünscht, von den betroffenen Kunden hatten nur etwa die Hälfte unsere Ankündigung bis dato mitbekommen.

War bei uns nicht anders und ich kann inzwischen auch bestätigen, dass die Vorlaufzeit für die weiteren Server genau so knapp ist - habe heute um ca. 18:25 (also nach Dienstschluss) einige E-Mails von Netcup bekommen, dass die restlichen Server am Freitag Vormittag dran sind. Das ist etwas was ich bei der Kommunikation nun wirklich nicht verstehe warum die Server die später dran kommen auch nur einen Werktag Vorlaufzeit haben - das kann man definitiv besser planen und kommunizieren. netcup - bitte in Zukunft (zumindest bei den Servern die nicht als erstes dran kommen) mehr Vorlaufzeit

Zitat von gunnarh

Per Default ist alles angehakt. Diejenigen die einen Zeitpunkt bewusst aussparen möchten können die betreffenden Zeiten de-selektieren und sich so "wünschen" in dieser Zeit verschont zu werden. Je nach Dringlichkeit könnte Netcup das dann berücksichtigen. Leute die einen Cluster betreiben können sich so bewusst disjunkte-Zeitpläne einrichten mit ausreichend Zwischenraum.

Das wäre natürlich perfekt und auch sehr ähnlich zu dem was Google bzw. Amazon anbieten wenn man bei Ihnen einen Datenbankserver betreibt - bei denen kann man auch auswählen in welchem (von einigen vorgegebenen Zeiträumen) ein Restart erfolgen kann. Bei einem Cluster sind die Zeiten selbstverständlich unterschiedlich gewählt.

Nach der gestrigen Kritik auch von meiner Seite ein Lob an das Netcup-Team - die Server wurden 1 bis 3 Minuten nach Beginn des angekündigten Wartungsfensters ordnungsgemäß heruntergefahren und 28 bis 32 Minuten danach wieder neu gestartet. Die Sicherheitslücken wurden geschlossen und die Server laufen inzwischen wieder einwandfrei.

@netcup-felix

Wie im ersten Beitrag von dir erwähnt wird es ja einige Zeit in Anspruch nehmen bis alle Server aktualisiert wurden - wisst ihr bereits ob für die weiteren Server die Ankündigung ebenfalls so kurzfristig (1 Werktag) vorher rausgeht oder ob die Ankündigungen für diese Server etwas mehr Vorlaufzeit haben?

PS: noch eine Anregung für die Zukunft - ideal wäre es natürlich wenn geplante Wartungsarbeiten auch im SCP beim jeweiligen Server angezeigt werden

Zitat von [netcup] Felix

Sicherheitskritische Updates spielen wir so bald wie möglich ein. Dabei müssen wir abwägen, wann dieser Zeitpunkt ist und wie viel vorher wir ihn ankündigen können.

...

Wenn wir uns anschauen wie lange am Kernel gearbeitet wurde, war es sicherlich gut, dass wir nicht das aller erste Update eingespielt haben. Hier haben wir von den Updates bzgl. Meltdown gelernt.

Diese zwei Sätze widersprechen sich doch deutlich ... wenn man einige Woche warten kann bis die Updates stabil laufen und man sie ausreichend getestet hat, dann kann man das Update auch 2 Werktage (anstatt 1 Werktag) vorher ankündigen. Der Neustart von über 40 000 VMs erfordert bestimmt auch mehrere Tage Vorbereitung und Planung und vielleicht hätte man die Kunden doch einen Tag früher informieren können.

Zitat von [netcup] Felix

Dabei berücksichtigen wir, dass VMs der gleichen Generation nicht parallel neu gestartet werden, um HA-Cluster nicht zu gefährden.

Um die 10 Minuten zwischen den Wartungsfenstern von VMs der gleichen Generation sind aber nicht wirklich ausreichend um die Funktion der neu gestarteten Node zu validieren und die Node wieder in den HA-Cluster einzuhängen. Wenn es 30-60 Minuten wären hätte ich auch gar nix gesagt, aber ungefähr 10 sind ein echtes Glücksspiel - das kann gehen oder aber auch nicht. Wenn es sich nicht ausgeht und der HA-Cluster fällt unter die kritische Anzahl von Nodes ist der HA-Cluster down und es bleibt nur ein Fail-Over auf die Notfall-Infrastruktur inkl. möglichem Datenverlust.

Zitat von [netcup] Felix

Wir werden unseren hier vorgegebenen Prozess nicht ändern

Ich verstehe durchaus, dass der Prozess für dieses Update nicht mehr geändert wird bzw. nicht mehr geändert werden kann. Aber da momentan vermehrt auf dem Gebiet geforscht wird war das bestimmt nicht die letzte Sicherheitslücke in Intel CPUs. Vielleicht kann man beim nächsten Update versuchen, dass der zeitliche Abstand zwischen VMs der gleichen Generation etwas länger ist um HA-Clustern die Möglichkeit zu geben die Node wieder einzuhängen und ein Rebalance zu machen.

Von meiner Seite war es das aber jetzt auch dazu ... da es für das Update morgen ohnehin nichts mehr ändert ... war einfach eine kleine Anregung zur Planung von zukünftigen Updates.

Zitat von 03simon10

Ich betreibe keinerlei Geschäft mit solchen Dienstleistungen, aber in der IT-Branche sollte man immer mit so etwas rechenen... Es könnte ja auch von jetzt auf gleich mal der Strom ausfallen - da muss auch unangekündigt jemand ran.

Für Stromausfälle gibt es Notstromaggregate - das sollte eigentlich in keinem modernen Rechenzentrum zu Problemen führen. Und wer lesen kann hat auch schon erkannt, dass unsere Infrastruktur redundant und als Cluster ausgelegt ist. Normalerweise sollte es dadurch bei uns zu keinen Ausfällen sondern lediglich zu eingeschränkter Performance kommen. Es gibt darüber hinaus auch eine komplette Notfall-Infrastruktur (mit weniger Leistung) bei einem anderen Anbieter auf die wir umschalten können.

Aber das ist halt ein Notfall-System (mit weniger Leistung) - darauf in der normalen Arbeitszeit (mit viel Last) geplant umzuschalten möchte ich meinen Kunden eigentlich nicht zumuten.

Diese Umschaltung auf das Notfall-System wäre aber nicht notwendig wenn nicht ein Großteil unserer Server in sehr kurzem Abstand die Wartung hätte. Durch diese kurzen Abstände kann ich nämlich nicht garantieren, dass die einen Server schon wieder gestartet und überprüft wurden bevor die nächsten offline gehen. Dadurch besteht das Risiko, dass unser System auf den Netcup-Servern gänzlich ausfällt. In diesem Fall wäre es theoretisch möglich, dass die 2-Wege-Replikation auf die Notfall-Infrastruktur nicht 100%ig auf den letzten Stand ist und es zu einem (wenn auch äußerst geringem) Datenverlust kommt (das lässt sich bei verteilten Systemen leider nie 100%ig ausschließen). Im Disaster-Fall ist das ein notwendiges Übel - bei geplanten Arbeiten aber für uns und unsere Kunden allerdings völlig inakzeptabel. Deshalb müssen wir vorab auf das Notfall-System umschalten. Da unsere Kunden aber fast einen gesamten Arbeitstag am Notfall-System arbeiten müssen wir dort nun eben zusätzliche Kapazitäten hinzufügen.

Was mich daran ärgert ist vor allem die Tatsache, dass man es so kurzfristig ankündigt - weder der Bug noch der zugehörige Bugfix sind erst seit gestern bekannt - sondern bereits wesentlich länger. Man hätte hier durchaus zumindest 2 oder 3 Tage für die Vorankündigung wählen können. Die Information für eine Downtime (am 29. August) am 27. um 18:20 auszuschicken ist äußerst knapp. Die Ankündigung wird am nächsten Arbeitstag (dem 28.) gelesen - dann muss man die Auswirkungen analysiert, dann noch die Kunden informieren und die notwendigen Maßnahmen ergreifen.

Ich habe bereits Systeme für Großkunden mit mehreren tausend, international verteilten, Servern geplant und betrieben und was wie man ausfallsichere Systeme betreibt - ich brauche also keine Belehrung über Risikomanagement bei IT-Systemen.

Zitat von Caspar

Gibt es, sogar genau auf Ihre Anforderungen zugeschnitten -> https://www.netcup.de/professional/

Kostet allerdings 2-3 Euro mehr als nur ~8,- Euro für eine Virtuelle Maschine.

Mir ist das Professional Angebot von Netcup durchaus bekannt und wir verwenden auch nicht die 8 Euro vServer - mir sind allerdings Infrastrukturen lieber die auf einer großen Anzahl von vServern verteilt laufen - da man dadurch eine viel höhere Redundanz (und somit Ausfallsicherheit) erreicht als mit einer geringeren Anzahl Dedicated-Servern. Auch ist es mit virtuellen Servern einfacher, günstiger und schneller möglich kurzfristig oder dauerhaft die Leistung zu erhöhen als mit dedizierten Servern.

Zitat

Wie hast du bisher den Failover bei einem Admin-Fehler, DDOS-Attacke, Crash vom Server, etc gehandhabt? Das hat doch viel mehr Impact als eine angekündigte Downtime von 15min.

Siehe oben - außerdem ist die Downtime nicht 15min sondern das Fenster von Netcup ist je Server mit 1:50 angegeben - mit dem Hinweis, dass die Downtime "30 Minuten" in diesem Zeitfenster beträgt - nur weiß ich halt nicht ob wir am Ende 1:20 oder nur 5 Minuten haben um die Server zu überprüfen bevor die nächsten offline gehen.

Mir ist durchaus klar was virtuelle Systeme sind und dass da mehrere Kunden drauf laufen - aber (fast) alle virtuellen Hosts eines Kunden nacheinander im Abstand von nur wenigen Minuten offline zu nehmen ist nicht nur suboptimal sondern nahezu fahrlässig. Da hilft der beste Fail-Over nichts wenn ich 5-10 Minten zum Restart und Funktionstest meiner Systeme habe.

Und wenn es die Möglichkeit gäbe bei Netcup für diesen Service mehr zu bezahlen wäre ich dazu bereit ... und gleich in die Ankündigung reinzuschreiben: "Anfragen dazu werden nicht von unserem Support per E-Mail beantwortet werden" ist meiner Ansicht nach einfach nur frech.

Alle meine Kunden zu informieren, dass es möglicherweise zu Downtimes mit 24-48 Stunden Vorlaufzeit kommt und mich dann anjammern zu lassen, wenn es wirklich dazu kommt kostet am Ende deutlich mehr.

Wir müssen jetzt jedenfalls kurzfristig Resourcen von anderen Aufgaben abziehen um unseren Cluster um weitere Server bei anderen Cloud-Anbietern zu ergänzen, damit ein Fail-Over für die Kunden bei möglichst gleichbleibender Leistung möglich ist.

Ich finde es auch gut wenn die Restarts außerhalb der Geschäftszeiten wären - meine Kunden finden es nicht gut, wenn ich Ihnen mit weniger als 48 Stunden Vorlauf eine Downtime mitten in der Geschäftszeit ankündige. Unser System ist zwar auf Redundanz ausgelegt aber einige unserer Server haben das Wartungsfenster mit nur 20 Minuten Abstand - wenn da beim Restart des vorherigen Servers etwas schiefgeht stehen die Kunden ohne System da.

Wenn wir selbst Wartungsarbeiten machen so legen wir diese auch immer außerhalb der Geschäftszeiten unserer Kunden um die Störungen möglichst gering zu halten. Wenn schon innerhalb der Geschäftszeiten, da würde ich mir längere Vorlaufzeiten und evtl. ein Mitspracherecht beim Zeitpunkt wünschen ....