vowe.net outage :: This was a big one
by Volker Weber
A bit of history. The site used to run in shared hosting at 1&1. When that broke, Stefan let me host on his server. The site got faster, much faster actually, and he added SSL via LetsEnrcypt.
Once in a while the site crashes. When that happens, Stefan has to restart it. If it happens at night or while he is working, it may take a few hours, but then it's coming back. I like to phrase it as "vowe.net is taking a bath and will come back squeaky clean".
Well, not this time.
The server hardware was failing. More precisely, the storage was failing. It’s a simple RAID 1 setup. Two drives, one holds a copy of the other. When a drive fails, which does happen more often than you think, you just replace it, the data gets synced back and everything is back in good shape.
Well, not this time.
While the RAID was rebuilding, the other drive failed as well. Again, this is more common than you might think, especially if you have Seagate Barracuda drives. (Hint: not recommended). Rebuilding puts a lot of stress on the old drive, and this time around it failed. If you followed along, that means catastrophic failure. Everything is lost.
Not, if you are Stefan.
Stefan has been doing server farms for more than a decade, on a very large scale. When a RAID drive fails, you don’t replace it. You take it offline so that nothing writes to it. Then you make a fresh backup. Only then do you start replacing the failed drive and rebuilding the RAID.
So this happened. Both redundant drives failed. Both have been replaced. The RAID synced. The hoster put on a clean o/s. And then the real work started. Stefan installed all the server software and moved some 70 GB of data from his home back to the server. He is still ironing out the details. That sounds easier than it is, if you are already living a 25 hour day.
The real hero here is Stefan. Under normal circumstances, this site would have died this week.
Comments
Und nun? Was ist nun die empfohlene HD? Ich habe allein WD am Start ...
Seagate = "Sie geht - oder sie geht nicht"
Bei mir sind die auch gut. Aber wichtiger: niemals zwei gleiche ins RAID bauen, und schon gar nicht aus dem gleichen Los.
proven once again Raid is no Backup
Kristof: Ich nehme wenn möglich nur Hitachi drives. Gehören zwar mittlerweile auch zu WD, aber zumindest in den ersten Jahren hat es WD nicht geschafft, die Stabilität von Hitachi auch in die eigenen Serien einfliessen zu lassen. Ich höre, dass die neusten WD Reds da aufgeholt haben oder gleichwertig sein sollen. Ich konnte mich trotzdem bislang nicht zu einem Experiment hinreissen lassen und bleibe weiter bei Hitachi.
Felix: alle Seagates die ich je hatte sind tot. Ein Bekannter hat in einem 4-Bay-RAID erstmal 24 Seagates sterben lassen (alle während der Garantiezeit), bevor er auf Platten umgestellt hat, die *nicht* auf der HCL standen. Die laufen jetzt seit Jahren problemlos. Ergo: "Sie geht nicht".
Kai: I never thought it was ;)
Hitachi war mal und wäre auch noch meine Wahl, für privat aber waren die irgendwie immer zu teuer. Anyway, seit ich die WD-Red benutze habe ich nicht eine Platte mehr verloren. Die ältesten (ins Backup-Nas ausgelagert) sind jetzt sechs Jahre alt.
Ich bin geneigt zu behaupten, dass die in Ordnung sind.
WD Red hier ebenfalls. 4 Stück a 2TB im Raid 5 laufen seit Jahren wunderbar im Qnap.
Ich hatte in meinem RAID zunächst WDs, die offiziell für den Dauerbetrieb zugelassen waren.
Nachdem innerhalb des ersten halben Jahres zwei von drei hinüber waren (zum Glück mit etwas Abstand) und ich Ersatz bekam, waren die plötzlich nur noch für den Desktopbetrieb freigegeben.
Insgesamt habe ich ungefähr 10 RMAs gehabt, bis die WD Reds mit 3TB raus kamen -> keinen einzigen Ausfall seit dem.
Die naheliegendste Frage ist doch nun: hat Stefan auch eine Wunschliste bei Amazon oder so?
es gibt übrigens eine (natürlich nicht perfekte) Liste über die Ausfallraten diverser Festplatten bei backblaze https://www.backblaze.com/blog/hard-drive-failure-stats-q2-2017/
Erinnert mich irgendwie an diese Szene
https://www.youtube.com/watch?v=RBK7QnjyE4Q
"Gute Leute muss man haben...".
Hat`s off to Stefan!
Samuel: Danke für den Link, dann teste ich die doch auch gleich noch mit für's Backup des Backups.
Der letzte Satz hat mich doch etwas schockiert.
Ein Leben ohne vowe.net ist möglich, aber nicht sinnvoll ;-)
vowe is good mother
Und Stefan gebührt Dank und Respekt.
Hmm... ohne Stefans Leistung und Knowhow abwerten zu wollen, aber bucht man nicht genau aus solchen Gründen eine AWS EC2 Instanz oder ähnliches bei Azure? Um sich eben nicht mehr um Hardware, Backup oder Raid kümmern zu müssen? Performance ist eine Frage der Kosten und bei Hardwareausfall beschränkt sich die Konsequenz auf den Reboot, wenn die Instanz auf anderer Hardware wieder startet.
Kann man machen. Aber dann hat man sehr variable Kosten für den Traffic.
> aber bucht man nicht genau aus solchen Gründen eine AWS EC2 Instanz oder ähnliches bei Azure?
Die Überlegung ist nicht falsch, aber in der Praxis dann doch komplizierter. Diese Anbieter ticken oft anders als Lösungen die man aus der klasischen Firmen-IT mit VMware etc. kennt. Zunächst sind genau die beiden manchmal sogar eher teuer, wenn man nur ein paar normale VMs (virtueller Server statt Blech) haben möchte. EC2 und Azure haben andere Zielgruppen: Die sind sind zum einen die "Voll-Sortimenter" der Cloud-Branche, bei denen man so ziemlich alles vom Datenbankserver über den Loadbalancer bis zu spezialisierter Hardware auf Knopfdruck bekommen kann. Amazon hat über Hundert Dienste im Katalog. Das skaliert dann zudem noch rauf und runter, soweit es Geldbeutel und Anwendung hergeben.
Wenn das Ziel Ausfallsicherheit bedeutet, ist ein "1:1"-Ersatz der Lösung für vowe.net mit hoher Wahrscheinlichkeit kontraproduktiv: Diese Anbieter kalkulieren preislich eng und nehmen in Kauf, das immer mal irgendwo was in Rauch aufgeht. Das wissen die Kunden in der Regel auch. Eine VM wird dann aber oft gar nicht auf neuer Hardware hochgefahren. Man bekommt stattdessen häufig eine neue Instanz und muss damit klar kommen, das die alte mindestens temporär weg ist. Das hilft aber nur, wenn man seine Arbeitsweise daran anpasst:
Ein typisches "Cloud-Setup" trennt meisten Storage und Applikation. Storage gibt es dort in verschiedenen Geschmäckern hochverfügbar, z.B. Amazon S3. Dann erst wird man bei der Verfügbarkeit "besser" als mit handgepflegten einzelnen Servern. Um die Applikation (Webserver, PHP/Java/Ruby/whatever) hochverfügbar zu machen, baut man entweder mehrere VM-Instanzen und packt einen Loadbalancer davor oder man verwendet andere Technologien (Docker, FaaS/Serverless), die hier endgültig den Rahmen sprengen. :-)
Ghost im Docker Image auf Beanstalk war so eine Idee.
Ja, das ist eine von vielen möglichen Varianten, was ich nicht wertend meine. Man trennt Datenhaltung von der Applikation, damit man beide effizienter redundant ausführen kann. Die Idee ist ja auch außerhalb der Cloud nicht neu.
Noch ein kleines Beispiel warum normale Server bei EC2 nicht jeden glücklich machen: Man bekommt dort gelegentlich eine Mail, das die Hardware abgekündigt oder defekt ist, auf der eine VM läuft. Die stellen dann einfach parallel eine neue hin. Live Migration oder überhaupt einen Umzug gibt es nicht. Wenn man sein Setup schnell umtopfen kann, stört das nicht groß. Bei mühsam handgedengelten Installationen oder fehlender Übung ist das aber eher nichts.
@Vowe: ECS ist hier sicher eine schöne Alternative. Wenns mal akut wird: eine Kollegin macht den ganzen Tag nix anderes :-)
@Bernd: Zustimmung zu allem, was du sagst. Ich war unpräzise mit meinen Post. Genauer hätte ich sagen müssen, dass man (bei AWS) die Applikation in DB und (stateless) App Server aufteilt - wie Du schreibst.
Die DB kommt in einen gemanagten Service wie RDS wenn Tabellen oder eben Dynamo DB wenn unstrukturiert.
Auf der App Seite bedient man sich Spot-Instanzen einer eher kleinen Größe und lässt diese hinter einem LoadBalander skalieren. Wenn einem eine Spotinstanz weggenommen wird, weiss man das ein par Minuten vorher, so dass der ELB eine neue dazubaut bevor die alte weggeht. Das ist eine recht gute Lösung, wenn man nicht gerade mit Bestellsystemen / sticky Sessions umgehen muss.
Das klingt erst mal kompliziert, ist es aber nicht und man ist die Themen Redundanz, Verfügbarkeit und Skalierung (rauf UND runter) erst mal los. Ob sich das für Vowe.net rentiert - keine Ahnung. Aber wir reden hier ja erst mal über technische Ansätze ohne den RoI zu bewerten :-)
Why not use an Azure Web App. Just create it in the cloud. The basic setup is free. If you wanna go with your own domain, pay 10€/month. If you wanna scale you've got two options: First go for a bigger server. Second go for an automated horizontal scale-out. This is configured within seconds and only costs money if you have a lot of traffic.
And all the stories about running two VMs at the same time if the underlaying hardware fails are gone.
Amazon offers the same fully managed service. Also Google does.
I've been visiting the German system houses congress (Systemhauskongress) this year and it is hard to understand why still so many people want to build and manage they're own servers.
We are a liveblogging SaaS company. We can have a million PIs on a single day on our servers. We would be bee foolish to take care about every server we use.
Just calculate the time you need to figure out that ubuntu and database server stuff, to keep your system updated …
The cloud is just awesome – get it in your heads :)
> Ich war unpräzise mit meinen Post.
Kein Problem, das passiert mir dauernd. :-) Mir ging es da nicht um Kritik: "Cloud" ticket gerade bei den großen Anbietern oft anders, als man anfangs vermutet. Das ist erstmal nicht besser oder schlechter, sondern anders. Eine manchmal höhere Wahrscheinlichkeit für Fehler in einzelnen Instanzen/VMs ist nicht unbedingt das, was man spontan gerne nimmt. Probleme wie noisy neighbours kommen manchmal unerwartet, wenn man sich nicht vorher mit dem Kleingedruckten oder den besseren Blog-Beiträgen beschäftigt.
Falls man das akzeptiert, kann man damit umgehen. Man baut selbst Redundanz und Robustheit in seine Dienste oder man überlässt dem Anbieter die Aufgabe, das es im vereinbarten Maß verfügbar ist und skaliert.
