UnoEuro drives på en række SAN-systemer. Et SAN er en kæmpe samling diske som bruges fælles på tværs af mange maskiner. SAN14, som er det SAN der havde problemer, har eksempelvis over 245 harddiske (i alt 213 TB).

Normalt er al data på et SAN spredt ligeligt ud over alle disse diske, for at sikre optimal performance og redundans.

På et tidspunkt fredag aften dør der en disk i SAN14. Det er normalt aldrig et problem, men denne gang får det desværre alvorlige konsekvenser. Da SAN’et gerne vil rebuilde data, pga. den døde harddisk, rebuilder den det forkert, så alle skrivninger på hele SAN’et lander på 2 diske, i stedet for på 140 diske. Dette alene, gjorde at servere på SAN14 blev langsomme.

For at løse problemet, med de 2 diske, beder Dell os ‘prune’ disse diske, dvs. tømme dem og dermed sprede data ud over hele SAN’et igen. Da disse 2 diske er ekstremt pressede, pga. alle de skrivninger der laves til dem, er denne ‘prune’-process enormt langsom. Da prune-processen starter bliver svartiden på SAN’et med det samme eksponentielt dårligere, så data derpå bliver praktisk talt ubrugeligt. Dette betyder at mange UnoEuro servere enten går ned eller bliver langsomme, inkl mailsystemet som også ligger på det SAN. Der er tale om cirka 49 webservere (blandet PHP og ASP) og 9 MySQL servere.

Mailsystemet kommer dog forholdsvis hurtigt i normal drift igen, da det ligger godt i forhold til prune-processen.

Efter cirka 50% kan vi pludselig se at prune-processen kommer til at tage lang tid, på et tidspunkt var ‘estimate’ omkring 4000 timer, hvilket selvfølgelig var helt uacceptabelt. For at give flere ressourcer til at SAN’et kunne færdiggøre prune-processen, og derved komme tilbage til normal performance, blev vi derfor nødt til både at slukke for en masse maskiner på SAN’et samt flytte en masse maskiner væk til andre SAN-systemer. Flytningen af servere var naturligvis også langsom, da SAN’et stadig var langsomt. I det hele taget en helt forfærdelig situation at stå i.

Selv efter serverne er kommet op igen lørdag aften, er performance stadig uacceptabel. Samtidig er SAN14 endnu ikke ‘healthy’, dvs. vi stoler ikke på det kan køre stabilt i den tilstand det er i, og vi er bekymret for mulig fremtidig datatab. Natten til søndag vælger vi derfor at slukke for alle ikke-systemkritiske servere der bruger SAN14, for at give SAN’et natten over til at færdiggøre prune-processen. Søndag morgen er performance tilbage til omkring 90% og de sidste 10% forventer vi at have klar inden for et par dage. Ingen data er gået tabt i processen.

For at gøre det hele værre, havde vi allerede planlagt at flytte alt væk fra SAN14 inden for de næste 6 måneder, da vi er ved at udskifte den bagvedliggende infrastruktur. Det er selvfølgelig en process som vil blive fremskyndet efter weekendens hændelser.

Store systemer, store problemer.

Alt dette er en forholdsvis simplificeret version af hvad der skete, der er selvfølgelig sket en masse komplicerede ting og beslutninger undervejs, som er svære at beskrive eller blot glemt i farten :)
Vi er klar over vores kunder har været frustreret, det har vi også været. Vi håber denne driftsrapport viser at vi har gjort alt hvad vi kan for at mindske nedetid, datatab og for at komme dette problem til livs så hurtigt som muligt. At drive webhosting er ikke så simpelt som skulle tro :)

Tidslinje

Fredag 20:06
En disk dør i SAN14 og SAN’et starter automatisk en rebuild.

Fredag 23:50
Alle servere på SAN14 begynder at køre dårligt fordi SAN’et er ved at køre et restripe, som resultat af den døde disk.

Lørdag 10:01
Vi vælger at slukke en række webservere for at sætte fart på at SAN’et får ‘rebuildet’ færdigt.

Lørdag 10:52
Dell melder at prune-processen er på 95135/139693, ETA 6 timer (hvis bare).
(Det er meningen det skal være 0/139693)

Lørdag 11:42
Vi begynder at se forbedringer i performance nu, især mailsystemet kører bedre.

Lørdag 11:55
Mail lader til at være fuldt kørende igen. Den kø der er opstået er ved at blive afviklet nu.

Lørdag 12:27
Mailkøen er afviklet og al mail er i normal drift igen

Lørdag 12:34
Vi er ved at diskutere med Dell om vi kan tænde for webserverne igen.

Lørdag 13:03
Vi er så småt ved at starte webservere nu.
Prune-processen er på 84765/139693.

Lørdag 13:30
Prune-processen er på 84732/139693.

Lørdag 14:18
Der er stadig problemer med dele af det beskadiget array, så mange webservere kan ikke komme online før rebuild er færdig. Vi prøver at få så mange servere op som vi kan.
Prune-processen er på 84711/139693.

Lørdag 14:50
Prune-processen er på 84698/139693 (Ja, det går fucking langsomt).

Lørdag 15:20
Prune-processen er på 84682/139693.

Lørdag 16:51
Vi er ved at flytte maskiner væk fra det berørte SAN for at frigøre kapacitet til at starte flere webservere.

Lørdag 17:59
Vi er stadig ved at frigøre ressourcer til at kunne få de sidste servere online.
Prune-processen er på 72733/139693.

Lørdag 18:35
Nogle flere servere er startet.

Lørdag 19:40
Alle servere er startet og i drift. Der er stadig nedsat performance.

Søndag 00:30
For at kunne rebuild SAN’et er vi desværre nødt til at slukke for nogle servere natten over.

Søndag 07:30
Alt online igen.

The post Incident report 24-06-2017: SAN nedbrud appeared first on Simply.com blog.

Selv om MySQL 5.7 har været i stable-release i næsten 2 år inden vi opgraderede, så er den åbenbart stadig plaget af underlige (og kendte) crash-fejl, som vi har fundet uløste bug-reports på der er flere år gamle.

Det har betydet en helt elendig og ustabil drift på vores MySQL servere, og det er vi ekstremt kede af.

Vi har siden problemerne begyndt, forsøgt at optimere og justere os ud af problemet samt opgraderet storage og hardware, men det har ikke hjulpet.

For at komme de mange problemer til livs, har vi derfor udskiftet MySQL med Percona Server.

Percona er en fork af MySQL (på samme måde som MariaDB), hvor der er lavet en masse fejlrettelser og optimeringer ifht. til mainstream versionen af MySQL. Percona er fuldt ud kompatibel med MySQL, så det har ingen negativ betydning for hvordan du forbinder eller bruger MySQL. Til gengæld har vi set en betydelig forbedring i både hastighed og stabilitet, som kommer alle kunder til gode.

Vi håber derfor at den seneste tids stabilitetsproblemer er løst, og at vi kan vende tilbage til den stabile drift som vi er kendt for.

The post Incident report: MySQL 5.7 driftproblemer appeared first on Simply.com blog.

Onsdag nat samt Onsdag morgen, har vi haft udfald på vores netværksinfrastruktur der driver vores storage og VMware-platforme. Som konsekvens af dette har vi haft nedsat tilgængelighed til hele den virtuelle infrastruktur i vores datacenter.

Uddybning

Fejlen er lokaliseret til 4 centrale switch-enheder der driver en stor del af vores VMware platform.

Der er opstået et loop i en del af netværket, som normalvis ville være mitigeret af de indbyggede funktioner i switchene, men i stedet for at løse problemet har disse fået switchene, der forwarder trafikken til resten af netværket, til at gå i stå.

Den helt præcise fejlkilde undersøges stadig og samtidig er der kommunikation med switchleverandøren for at undersøge hvorfor enheden ikke agerede som planlagt.

Fra afbrydelserne i nat overvågede vores teknikere netværket tæt og fejlsøgte på problematikken. Ingen af problemerne har nogen sammenhæng med det der er sket om morgenen, så vidt logs og overvågning viser os, men vi udelukker naturligvis intet endnu.

00.45 – 00.50: Kort udfald på netværks infrastruktur

04.48 – 04.53: Kort udfald på netværks infrastruktur

07.34 – 08.01: Udfald på central netværkscore, der understøtter hele vores VMware infrastruktur. Fejlen betød at intern samt ekstern trafik mellem servere stoppede med at fungere.

08.30 – 08.40: Omlægning af trafikken på shared service betød afbrydelser til enkelte services i dette tidsrum.

09.00: Al drift normal

The post Incident report 31-08-2016: Netværksudfald appeared first on Simply.com blog.

Strømafbrydelsen betød, at alle UnoEuro servere og services, var utilgængelige fra kl. 20.50 og frem. De første services kom online igen kl. 23.34, og al drift var normaliseret igen kl. 01.03.

Fejlen er blevet lokaliseret til en defekt enhed i nødstrømsgeneratoren i det panel, der bestemmer, om vores datacenter skal køre på strøm fra el-nettet eller på strøm fra generatoren selv. Normalt ved strømafbrydelser sørger denne enhed for datacentrets uafbrudte strømforsyning, ved at aktivere henholdsvis generator eller ekstern strømforsyning.

Vores UPS-anlæg nåede, inden det løb tør for batteristrøm, at udvide fejlsøgningsvinduet med 35 minutter. Normalt ville nødstrømsgeneratoren overtage driften fra UPS-anlægget i løbet af ganske kort tid, men grundet den defekte enhed skete dette desværre ikke, og datacenteret stod derfor uden strøm.

Vores teknikere var til stede i datacentret og i kontakt med leverandøren, inden UPS-anlægget løb tør for strøm. Da fejlen skete i et stærkstrømsområde, var personsikkerhedsrisikoen imidlertid for stor til, at ikke-certificerede fagpersoner måtte arbejde på anlægget, samtidig var der risiko for at fejlhåndtering af situationen kunne lede til en eksplosion i datacenteret (som de professionelle sagde), hvilket selvfølgelig ville være katastrofal.

Den præcise fejl i nødstrømsgeneratoren blev lokaliseret kl. 22.10. Efter anskaffelse af en reservedel kunne elektrikerne kl. 23.10 genetablere strømmen i datacentret. Vores teknikere gik herefter i gang med at starte alle systemerne igen.

På trods af denne yderst kritiske hændelse var al drift genetableret kl. 01:03.

Under hele forløbet har vi holdt kunder opdateret på primært Twitter og Facebook så godt vi kunne.

Vi er selvfølgelig ekstremt kede af at dette kunne ske. At stå i et datacenter uden strøm er praktisk talt vores værste mareridt. Det er en situation vi nogle gange sidder og snakker om ved frokostbordet som en “Det sker aldrig, men hvad nu hvis”-situation. Nu skete det så, og på trods af virkelig træls nedetid, er vi ekstremt stolte over at vores systemer og infrastruktur praktisk talt ‘kom op af sig selv’ da der kom strøm på igen. Det skyldes alene at vi har investeret enorme mængder penge og tid i vores systemer.

Vi håber vores kunder vil tage dette med i deres vurdering. Vi beklager.

Hændelsesforløb

20.14: UPS-anlægget aktiveres. Tilkaldevagt alarmeres.

20.25: Vores teknikere er fremme ved datacentret og inspicerer fejlen. Efter kort samråd med el-vagten tilkaldes to certificerede elektrikere.

20.50: UPS-anlægget løber tør for strøm. Datacentret er nede.

21.15: Første elektriker er fremme ved datacentret og begynder fejlsøgning. Inden for 15 minutter ankommer ekstra elektrikere, så der er 4 mand på opgaven.

21.15-22.10: Fejlsøgning af el står på.

22.10: Fejlen er lokaliseret, og elektrikere går i gang med at fremskaffe den nødvendige reservedel til dieselgeneratoren. ETA er 20 minutter, før den kan leveres onsite.

22.39: Elektrikerne går i gang med udbedre fejlen, lave kontrol-målinger og sikre korrekt procedure for at sikre færrest mulige risici ved opstart af anlæggene.

23.10: Dieselgeneratoren kobles ind, UPS-anlægget startes op igen og der er igen strøm i datacentret.

23.10: Vores teknikere starter infrastruktursystemerne i korrekt rækkefølge for at have så få problemer som muligt efterfølgende (SAN, netværk, hosts, mv.).

01.03: Al drift er genetableret

Spørgsmål

Er jeres setup ikke redundant?

Jo, til et vist punkt. Vi har redundante internetforbindelser, redundante UPS, redundante strømforsygninger i serverne, og vi har offsite backup af vores data. Det eneste vi ikke har redundant er vores nødstrømsgenerator. Det er svært at sige om det havde gjort en forskel i den her situation, grundet omstændighederne, men det er selvfølgelig noget vi vil undersøge nærmere.

Vores navneservere er geografisk adskilt, så DNS drift har ikke været påvirket – men de web- & mailservere som DNS har peget på, har selvfølgelig været utilgængelige.

Tester man ikke sådan en nødstrømsgenerator?

Jo, det gør vi jævnligt, men den enhed som er gået i stykker har formentlig virket perfekt lige indtil den ikke gjorde, hvilket så har forsaget problemet.

Hvad med datatab?

Ingen data er gået tabt og ingen mails er ikke blevet leveret. Mails er dog selvfølgelig blevet leveret med forsinkelse.

The post Incident report 29-07-2016: Strømafbrydelse i datacenter appeared first on Simply.com blog.