Steht doch da:
Das komplett neue System besteht nun aus:
2x Load-Balancer (6-Kerner, 2,8 GHz, 8GB RAM)
2x Webserver (jeweils 6-Kerner, 3.1 GHz mit 16GB RAM)
2x DB/Storage (jeweils 6-Kerner, 3,1 GHz mit 32 GB RAM und 3,2 TB Plattenplatz)
1x Backupserver (4-Kerner, 3,1 GHz mit 8 GB RAM, 2x 4TB, automatisierte Backups der DB/Storage-Server)
Als kleine Info:
Üblicherweise haben die Loadbalancer in so einer Plattform eine shared Failover-IP-Adresse. Fällt der eine LB aus, wird die IP auf den anderen geswitcht.
Der jeweils aktive LB verteilt die Anfragen auf die beiden Webserver. Optimalerweise ist das System so dimensioniert, dass bei Ausfall eines Webservers der andere den Betrieb auch allein stemmen kann, wenn auch vielleicht nicht mit der gewohnten Performance. Aber wann fällt so ein Server aus?
Am ehesten geht eine Platte kaputt. Das ist kein Problem, denn üblicherweise setzt man RAID-Controller mit einem redundanten RAID-Level ein (5,1,10). Der Server läuft normal weiter, der Controller schlägt Alarm, die Platte wird getauscht, der Controller rebuildet das RAID im Hintergrund und der Anwender merkt es nicht einmal.
Ein Netzteil geht auch mal kaputt - selten, aber ich habe es schon erlebt. Manche Server haben redundante Netzteile, um das abzufangen, aber Server ohne diese Redundanz sind auch nicht gerade unüblich. Dann würde der Server komplett ausfallen. Das merken die Loadbalancer und leiten Anfragen nur noch an den laufenden Webserver weiter. Im Optimalfalle merkt der Anwender das auch nicht, eventuell leidet die Performance der Seite aber etwas.
Die DB-Server werden mit einer Datenbankreplikation arbeiten und für das gemeinsame Storage wird ein Clusterdateisystem zum Einsatz kommen. Auch hier ist das System so ausgelegt, dass die Anwendung weiterlaufen kann, wenn einer der Server ausfällt.
Sollte ein wichtiger Dienst auf einem der Server nicht innerhalb einer festgelegten Zeitspanne antworten, greift das sog. Fencing. Das bedeutet, der Cluster schaltet den Server, auf dem es aus irgend welchen Gründen gerade Probleme gibt, z.B. per IP-Steckdose ab, damit es keine Dateninkonsistenzen bzw. Split-Brain-Situationen gibt (auf dem einen Server werden andere Daten geschrieben als auf dem anderen).
Das ganze Konstrukt steht in Rechenzentren, zu denen nur Techniker Zutritt haben, die mit USVs und Generatoren immun gegen stundenlange Stromausfälle sind und die mehrfach, meist aus verschiedenen Himmelsrichtungen, mit verschiedenen Providern ans Internet angebunden sind, so dass selbst ein Bagger, der eine Zuleitung durchbaggert, keine Nichterreichbarkeit der Seite verursacht.
Kombiniert man so eine Plattform mit einem guten Monitoring, welches das Personal auch schnell auf eventuelle Probleme aufmerksam macht, hat man schon eine ziemlich hohe Ausfallsicherheit.
Backups sind natürlich auch wichtig, werden aber - bei solchen vergleichsweise ausfallsicheren Plattformen - nur selten benötigt.
Aber, auch wenn die Wahrscheinlichkeit dafür gering ist, auch RAM geht mal kaputt. Und das kann die merkwürdigsten Symptome nach sich ziehen, z.b. für Datenkorruption sorgen, ohne dass das sofort auffallen würde. ECC (Fehlerkorrektur) kann in gewissem Maße davor schützen, aber wie immer gilt, hundertprozentige Sicherheit gibt es nicht. Und es gibt sicher noch andere Möglichkeiten, wie Datenbankinkonsistenzen schleichend entstehen können, ohne dass das sofort auffallen würde.
Warum schreibe ich das?
Hier haben so viele Leute gemeckert, und einige Äußerungen erweckten den Eindruck, dass deren Autoren weniger Fachkenntnis haben als sie denken.
Dies soll Euch einen kleinen Blick hinter die Kulissen geben und verdeutlichen, dass so eine Plattform schon ein wirklich hohes Maß an Ausfallsicherheit hat.
Dieser jüngste, zweite Ausfall war in meinen Augen (ohne Details darüber zu kennen) vermutlich wirklich richtig, richtig großes Pech. Viel sicherer als mit solch einer Plattform kann man kaum fahren, ohne ein Vielfaches des Geldes in die Hand zu nehmen, und solch ein Ausfall ist in meinen Augen (ohne die Gründe zu kennen) extrem unwahrscheinlich, könnte aber - mit der gleichen geringen Wahrscheinlichkeit - genauso gut ein beliebiges anderes Forum treffen.
A propos: diese Server allein kosten einen Haufen Geld, dazu kommt das Management, was bei solch einem Cluster natürlich auch teurer ist als bei einem einzelnen Server. Unterschätzt diese Kosten nicht!
Mich würde aus fachlicher Sicht wirklich interessieren, woran es denn im Endeffekt gelegen hat, also was für die korrupten Daten in der DB verantwortlich war, aber ich hätte Verständnis, falls diese Info, sobald es sie denn gibt, nicht öffentlich gemacht werden würde.
Aber allen Nörglern sei gesagt: Bitte betrachtet die beiden Ausfälle separat. Sie sind bei verschiedenen Hostern (soweit ich das mitbekommen habe) und auf verschiedenen Systemen passiert und stehen in keinem Zusammenhang. Und aus fachlicher Sicht kann ich sagen, mit Blick auf die Plattform, das ist keine exotische Konfiguration; eine solche Plattform ist ein übliches Konzept.
Und bitte schlagt euch den Gedanken aus dem Kopf, man könne da einfach eine zusätzliche Festplatte anschließen und dann sei alles sicher. Das ist in etwa so als würdet ihr sagen, ich baue bei dem Auto einfach noch einen zusätzlichen Zylinder in den Motor und kann dann schneller fahren. Ja, so absurd ist es.
