Ekstrabladet.dk nede i syv timer med SAN-fejl
Først var websiderne helt væk. Og så blev læserne mødt med flere år gamle historier. Ekstrabladet.dk bød i lørdags de mange hundredetusinde brugere på en alternativ avisoplevelse, da teknikken bag Danmarks mest læste netavis svigtede lørdag morgen.
Det SAN (Storage Area Network), der fodrer websiden med data, gik ned, og redningsarbejdet gav problemer.
»Det var et SAN, der fik det rigtig skidt, og Linpro, der har applikationsdriften hos os, går i gang med at få det op igen. Men her sker der også nogle ting, så det ikke går så glat,« fortæller Per Palmkvist Knudsen, it-direktør i JP/Politikens Hus.
Problemet opstår kl. 8.45 lørdag, og i nogle timer er websiderne helt væk og viser kun en fejlmeddelelse. Leverandøren Redpill Linpro er i gang med at genoprette filsystemet, men en skanning af de 279 gigabyte tager noget tid.
Herefter dukker det gamle design af Ekstra Bladets websider op på ekstrabladet.dk, med elementer placeret lidt hulter til bulter, og med historier der er både to og tre år gamle. Forklaringen er, at forbindelsen mellem publiceringssystemet, som journalisterne skriver i, og Ekstra Bladets CMS ikke er kommet på plads.
»Da selve hovedfilsystemet var kommet op igen, var det ikke alle inboards, der virkede, som de skulle. De var blevet ustabile af den manøvre,« forklarer it-direktøren.
Først cirka syv timer efter nedbruddet ligner ekstrabladet.dk nogenlunde sig selv igen, men i løbet af weekenden er der stadig små problemer med, at de forkerte data bliver trukket til websiden. Alt skulle dog fungere normalt mandag.
I dag har Per Palmkvist Knudsen travlt med at finde ud af, hvorfor det skulle tage så lang tid at komme på fode igen. Eftermiddagen er sat af til et møde med leverandøren, norske Redpill Linpro.
»Det er ikke nogen skam at gå ned. Det gør alle en gang imellem, også Google og Amazon. Men det er utroligt vigtigt at komme op igen lynhurtigt, når det sker, og den del var ikke god nok. Vi var ikke hurtige nok til at komme tilbage igen,« siger Per Palmkvist Knudsen, der vil gå alle processerne for den slags fejl igennem igen.
Servere og resten af udstyret til ekstrabladet.dk står hos Ekstra Bladet, men bliver drevet af Redpill Linpro, der også driver teknikken bag flere store norske netaviser. Ekstrabladet.dk kører på CMS'et Escenic, der er målrettet online-medier, på en Apache Tomcat-server.
Udover at være Danmarks mest læste netavis, er ekstrabladet.dk den webside i Danmark med næstflest besøg ifølge FDIM's statistik for marts måned. 1,4 millioner brugere lagde i løbet af måneden vejen forbi ekstrabladet.dk, hvilket gav i alt 26 millioner besøg.
Kommentarer (6)
»Det er ikke nogen skam at gå ned. Det gør alle en gang imellem, også Google og Amazon. Men det er utroligt vigtigt at komme op igen lynhurtigt, når det sker, og den del var ikke god nok. Vi var ikke hurtige nok til at komme tilbage igen,« siger Per Palmkvist Knudsen, der vil gå alle processerne for den slags fejl igennem igen.
Det er altid godt at gennemgå begivenhederne og sine procedurer efter et større nedbrud men man bør også tænke på at et nedbrud der sender en service i sort (uanset størrelsen af servicen) er så krittisk en begivenhed at man, i kraft af at nedbrudet jo rent faktisk er sket, ikke har kunne gardere sig imod den. Derfor er det også omsonst at sige at det skal gå hurtigere at komme på benene næste gang da samme fejl ikke bør ske igen, så har man jo ikke lært noget af denne episode! Næste gang er det jo noget helt andet der er gået galt.
Jeg tror det er svært at forestille sig situationen hvor man har ansvaret for en service der går ned på denne måde hvis man ikke har stået i den. Det er oftest en uforudset situation der ikke matcher nogle senarier man har forestillet sig og derved ikke har procedurer til at håndtere. Det kræver is i maven og et køligt overblik da de ting man gør er improviserede og i værste tilfælde kan forvolde endnu mere skade på systemet. Derfor kan "simple" operationer også tage en del tid da man er nød til at være ekstra sikker på de ting man gør.
Så jeg syntes (ud fra hvad jeg læser om nedbrudet mellem linierne) at 7 timer er en ok tidsramme for at få systemet på benene igen.
-
0 -
0
Det er altid godt at gennemgå begivenhederne og sine procedurer efter et større nedbrud[...]
Det er mere end "godt", det er pinedød nødvendigt, for ellers lærer man ikke a sine fejl.
Poul-Henning
-
0
-
0
Som jeg ser det er 99.9% af data (set fra www.eb.dk) statisk, så det ville være langt smartere at den centrale del "skubbede" ny artikler/opdateringer (tekst og billeder), ud til de noder som ligger i deres "cluster/proxy" lag. Så er det meget mere skalerbart i stressede situationer, hvor man reelt kan hot-plugge nye noder ind uden at belaste online delen. De enkelte noder har så alt lokalt, og kan leve deres eget liv.
Hvis en node går ned, vil alle de andre køre videre. Og hvis den centrale del (fx SAN'et) går ned vil alle noderne stadig fungere, så kommer der bare ikke nogen opdatering indtil del centrale del (SAN'et) er oppe igen.
Deres community er jo en 80/20 læsning/skrivning. Der har de fint splittet det op, så hvis community delen ikke er online, kan man stadig læse artiklen.
De skal så bare tænke modellen et skridt videre...
-
0
-
0
Ja, jeg undrede mig lidt over det, da jeg fik en fejl om, at der ikke kunne opnås forbindelse til serveren på eb.dk i lørdags. Men jeg tænkte ikke videre over det (så nødvendig er EB heller ikke ;-D ), den slags fejl kan jo skyldes mange ting...
Mvh
Tine
-
0
-
0
langt smartere at den centrale del "skubbede" ny artikler/opdateringer (tekst og billeder), ud til de noder som ligger i deres "cluster/proxy" lag
Med mindre du bruger ESI includes, så har dit content en forholdsvis kort levetid, fordi sideelementer som "seneste nyheder" og lignende skal opdateres regelmæssigt, så det ville ikke have reddet EB.dk i mere end fem-10 minutter.
Med ESI includes, kunne du cache dit primære content med TTL på måneder, og det ville næsten løse problemet.
Kun næsten, fordi dine ESI elementer ville fejle hvis backend'en var nede, og hvis nogen prøvede at hente en gammel artikel der ikke var i cache, ville du ikke kunne hente den.
Poul-Henning
-
0
-
0
Vi er ikke langt fra hinanden, da vi reelt taler om cache begge to. Jeg vil dog persistere cachen lokalt på noden og derved undgår at være afhængig af backenden - når den går ned. Derved kan der altid vises indhold på eb.dk backend eller ej, og det er vel alt andet lige bedre end at vise en "5xx server not responding..."
Contents levetid vil altid være den samme uanset hvilken metode der benyttes for indlæsning/eksponering. En artikel har typisk en meget lang levetid, imens Breaking News og Lastest News har en kort levetid, men noden skal ikke forholde sig til disse opdaterings frekvenser, den skal "bare" vise seneste nyt (cachen) hele tiden. Man kan så definere TTL på fx Breaking News, så den ikke vises i flere dage selv om backend skulle være ende i samme tidsrum.
Det central system/backenden vil så "skubbe"/opdatere når der er noget nyt, enten direkte på noden eller indirekte igennem fx et kø system.
Det giver en meget simpel applikation og proces arkitektur, og få online afhængigheder imellem de forskellige led i "fødekæden".
-
0
-
0
Tilføj kommentar
