Dat was even hard werken. We kregen dinsdagochtend in de vroegte te maken met een storing die veel erger bleek dan we in eerste instantie dachten. Bij onze hostingprovider (XLS Hosting) viel één van onze servers uit, waardoor een deel van onze klanten ineens hun website niet meer konden bereiken. Wij ook niet trouwens. Gedurende de hele dinsdag werden we redelijk (via Twitter) op de hoogte gehouden van de vorderingen bij de provider, het leek erop of alles binnen een paar uur weer in orde zou zijn. Er zou ook geen dataverlies optreden, zo werd gezegd.
Intussen hebben wij als de bliksem een online vragenlijst gemigreerd naar een andere server, zodat we in de loop van dinsdag daarop al weer nieuwe mensen konden toelaten. Voor de websites leek dit niet nodig, alles zou immers snel weer in orde zijn.
Woensdag waren de mensen bij XLS Hosting alles aan het controleren en eindelijk, aan het einde van de middag kregen wij te zien wat er aan de hand was: er bleek enorm veel schade te zijn, veel databases waren gevuld met onherkenbare tekens, waardoor de websites niet of slecht functioneerden en op sommige plaatsen onzin bevatten. De hele donderdag zijn we in touw geweest de backup die we op koninginnedag gemaakt hadden terug te zetten en alles weer werkend te krijgen. Jan heeft wonderen verricht!
Gelukkig was het deze week relatief rustig vanwege vakanties, die van ons zijn er helaas een beetje bij ingeschoten...
Mooie les voor het vervolg: niet alleen kijken naar regelmatige backups (we maken van de website dagelijks backups van alle databases), maar ook een volledig ander platform inrichten, dat het werk van onze server binnen korte tijd (maximaal een paar uur) kan overnemen, bij storing.
Hier is de email die we woensdag kregen van XLS Hosting, voor de technisch geinteresseerden. Aan het eind zeggen ze dat alles weer in orde is, helaas hebben wij daarna nog een hoop werk eraan gehad.
Gisteren hebben wij een grote storing gehad op het cluster met VPS nummers 5000 tot 5999. Sommige VPSen zijn vanaf de ochtend tot 's avonds laat down of langzaam geweest, sommige virtuele servers zijn in de avond enkele uren down geweest.
De oorzaak was een serie problemen in het storage-netwerk van het cluster. Onderaan deze mail staat een gedetailleerde tijdlijn. Uiteindelijk hebben wij de onderstaande, elkaar versterkende, oorzaken aan kunnen wijzen voor de lange downtime:
- Een storage machine (SAN) probeerde een harddisk te vervangen met een disk die vervolgens zelf kapot ging. Hierna was een handmatige actie vereist gevolgd door een rebuild van de betrokken redundante disk groep (RAID-groep) die vrij veel CPU load binnen de SAN veroorzaakte.
- Eén van de RAID controlers op deze SAN (kaarten die de toegang tot de schijven regelen) ging vervolgens op een ongelukkig moment kapot. Samen met de rebuild veroorzaakte dit heel erg veel load op de SAN en errors in the storage netwerk.
- Een gedeelte van het management en failover systeem van dit cluster maakte gebruik van de getroffen RAID-groep. Dit en de extreme load op de SAN maakte het moeilijk om te troubleshooten.
De maatregelen die wij gaan nemen naar aanleiding van deze gebeurtenissen:
- Eerder mailen, veel klanten misten in eerste instantie de updates die gedaan werden via de site en twitter.
- De verstoorde informatie uit ons cluster management systeem heeft vrij veel vertraging veroorzaakt bij het oplossen van het probleem. Als wij normale informatie uit het cluster management systeem hadden gehad dan hadden we beide hardware problemen waarschijnlijk binnen enkele uren op kunnen lossen. We hadden dan ook direct maatregelen kunnen nemen die de overlast van de falende RAID-controler enorm beperkt zouden hebben. Wij hebben nu besloten dit gedeelte van het management systeem over beide SANs te verspreiden of op twee aparte machines per cluster.
- Wij zijn nog met onze SAN leverancier aan het onderzoeken waarom het systeem errors is gaan genereren die problemen binnen het storage netwerk veroorzaakten. Wij snappen dat extreme load kan voorkomen bij intensieve rebuild van de RAID-groep gecombineerd met het falen van één van de raid controllers. Wat wij niet willen is ook een combinatie met error messages die de problemen significant erger maken. Als het antwoord niet bevredigend is zullen wij onze klanten actief wegmigreren van dit merk SAN.
Gisteren is voor XLS en haar klanten de slechtste dag geweest qua hosting performance. Wij zijn doorgaans met recht trots op onze infrastructuur waarvan wij de software voor het grootste gedeelte zelf hebben gebouwd. De uiteindelijke oorzaak was een combinatie van hardware problemen maar het bleek ook dat onze eigen software beter met de gevolgen om had kunnen gaan. Wij hebben gisteren allereerst onze eigen klanten zo snel mogelijk weer online willen brengen, maar we zullen er de komende weken voor gaan zorgen dat dit niet meer kan gebeuren.
Na eerder dit jaar een gevoeligheid voor DDoS-aanvallen gehad te hebben kunnen wij het ons voorstellen dat klanten zich afvragen of onze cloud wel de beste keuze is. Wij willen u ervan verzekeren dat wij problemen extreem snel en serieus oppakken. Het DDoS-probleem is met slimme filters aangepakt en tevens zijn wij zijn vorige week begonnen ons hele interne netwerk naar 10 Gigabit aan het upgraden. Op dezelfde manier zullen wij ervoor zorgen dat het probleem van gisteren en gerelateerde problemen niet meer voor kan komen. Hierbij is het een voordeel dat wij onze clustersoftware zelf ontwikkelen, hierdoor kunnen wij snel aanpassingen maken om ons aan nieuwe inzichten en situaties aan te passen. Dit is de manier waarop wij de grootste VPS-hoster van Nederland zijn geworden met nog steeds enorm goede uptime-statistieken.
Wij willen onze klanten in ieder geval bedanken voor de vele positieve reacties tijdens en na de storing. Negatieve reacties begrijpen wij. Down zijn is vreselijk en er zelf niets aan kunnen doen helemaal. Dit geldt zeker voor relatief nieuwe klanten die nog geen langere ervaring met ons hebben. Wij hopen u met goede uitleg en de juiste maatregelen onze blijvende waarde voor u te kunnen bewijzen.
Uiteraard is er een maand kortingssaldo voor de getroffen vpsen aan uw account toegevoegd.
Vriendelijke Groet,
XLS Hosting System Administration & Support
== Storing Tijdlijn ==
- Om 3.27 ontstonden er problemen op één van de twee storage nodes binnen het cluster. De SAN probeerde een schijf in gebruik te nemen als vervanging van een schijf die eerder kapot was gegaan, deze schijf ging vervolgens onmiddelijk kapot.
- Dit leidde voor ongeveer 70 vpsen op deze groep schijven tot extreem langzame schijftoegang of downtime. Een onderdeel van het cluster management systeem maakte echter ook gebruik van deze RAID-groep. Dit creeerde de nodige problemen bij het trouble shooten. We probeerden via de SAN en cluster management systeem de situatie op de schijfgroep te stabiliseren maar dit lukte niet.
- Om 10.10 uur heeft iemand op het datacenter handmatig de juiste disken op de SAN in gebruik genomen. De RAID-groep ging vervolgens zijn redundantie herbouwen met de juiste schijven. Om 11.14 uur konden we weer vpsen gaan booten en gaan controleren of ze goed up zouden komen.
- Rond 12.30 uur zagen wij opeens een grote hoeveelheid harddisk IO fouten in virtuele servers. Na onderzoek kwamen wij er echter achter dat één van de twee RAID controllers in de SAN niet goed functioneerde. Dit onderzoek werd bemoeilijkt doordat de load van het rebuilden samen met de falende RAID controller het functioneren van onze cluster management software wederom onder druk zette. Deze hoge load en de errors op het storage netwerk zorgden voor downtime of traagheid bij ongeveer 150 virtuele servers.
- Om 16.30 uur zijn wij de bekabeling en de switching van het storage netwerk gaan testen omdat de harddisk IO errors ook op ander probleem in de verbinding naar de storage machines konden wijzen. Wij kwamen hierbij tot de conclusie dat wij voor de zekerheid ook het grootste deel van het fibrechannel netwerk tussen de storage machines en de servers wilden vervangen. Vervolgens zijn wij het groot onderhoud gaan voorbereiden om de problemen binnen het cluster op te lossen.
- Om 19.07 hebben wij besloten het groot onderhoud onmiddelijk in te zetten omdat meer virtuele servers bij de problemen betrokken leken te raken. Vanaf dit moment waren 320 virtuele servers volledig down. Gedurende het groot onderhoud is de problematische RAID controller geboot en hij kwam vervolgens weer correct online. Tevens zijn de fibers en een fiber channel switch tussen de SANs en de servers vervangen en zijn alle fysieke servers gecontroleerd en gereboot. Vervolgens is er een SAN compleet gereboot. Na een uitgebreide controle van de systemen bleek dat de RAID controller op de SAN en het storage netwerk weer goed functioneerden en dat alle harddisk IO errors waren verdwenen.
- On 23.15 uur waren we tevreden over de status van het storage netwerk en konde we konden we de servers, het cluster management systeem en vervolgens de vpsen weer gaan rebooten. Hierna is een team van 4 man begonnen alle vpsen die in filesystemchecks en dergelijke zaten te begeleiden.