Cache-problemer sendte DR-websites i sort

Danmarks Radio var onsdag formiddag offline i længere tid på grund af problemer med caching af websites.

Et af Danmarks mest besøgte websites, dr.dk, var onsdag formiddag utilgængelig, så de besøgende blot fik en time-out-fejl. Sitet var først oppe igen klokken 14:43.

»Vi er selvfølgelig ærgerlige over, at sådan en fejl kan ske. Det er overhovedet ikke tilfredsstillende,« siger underdirektør i DR Teknologi, Mikkel Müller til Version2.

Problemet var cache-serveren, der er en afgørende del af den infrastruktur, der skal give brugerne adgang til DR's websites.

»Vi er ikke helt i bund med fejlsøgningen, men cirka klokken 11 gik vores cache-server ned. Cache-serverne håndterer næsten hele loadet på dr.dk, så uden den fungerer sitet ikke,« forklarer Mikkel Müller.

Da serveren gik ned, aktiverede teknikerne i DR beredskabet, der indebærer samling af en task force, der skal finde frem til fejlen og løse den. Selvom sitet var oppe igen onsdag eftermiddag, vil task forcen fortsat holde øje med, om problemerne skulle komme igen. Samtidigt undersøges det, hvordan en lignende fejl kan undgås i fremtiden.

»Det er en superalvorlig hændelse, og det har vi en fast procedure for at håndtere. Men desværre tog det lang tid at finde og udbedre fejlen i denne situation,« forklarer Mikkel Müller.

DR benytter Drupal som CMS, men de fleste får vist en cachet version af siderne på DR's website. Det går mange gange hurtigere og belaster systemet en brøkdel i forhold til at skulle generere alle sidevisninger direkte fra CMS'et.

Problemet var i dette tilfælde, at cache-serveren blev overbelastet med for mange aktive connections på grund af et problem med ét af DR's egne, bagvedliggende API'er. Efter fejlen blev identificeret, tog det dog tid at få startet hele infrastrukturen korrekt op igen.

»Vi havde en udfordring med at få startet vores caching op igen, som vi fik ekstern assistance til at løse. Vi var nødt til at starte cachen op langsomt, fordi vi ellers vil lægge den bagvedliggende infrastruktur ned, når alle siderne skal gencaches. Derfor kunne man på et tidspunkt godt komme ind på forsiden af dr.dk, men nogle af artiklerne var endnu ikke cachet,« forklarer Mikkel Müller.

DR's task force arbejdede onsdag eftermiddag fortsat på at sikre, at systemerne igen kørte normalt uden behov for yderligere tiltag.

Version2.dk og søstersitet Ing.dk havde også driftsproblemer onsdag. Ligesom DR kører disse sites også Drupal, men problemerne var et tilfældigt sammenfald. Problemerne på Version2.dk og Ing.dk skyldtes en autogenereret sql-forespørgsel, som skabte en lock-condition på databaseserveren. Til trods for databaseserverens kapacitet, betød det, at Version2.dk i perioder på cirka hvert 20. minut holdt op med at svare.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (7)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jan Heisterberg

Problemet er ikke at det opstod eller hvorfor.
Og ej heller at det tog tid at komme i luften igen.

Problemet er, at dr.dk er en del af Danmarks Radio's Public Service forpligtelse OG at dr.dk i krisesituationer er en vigtig, den vigtigste ?, kommunikationskilde for befolkningen (sammen med radio og TV).

Problemet er derfor: hvorfor er der ikke en simpel, effektiv, fall-back løsning, hvis eneste formål kan være at vise een webside med eet af følgende indhold:
1. Der er en teknisk fejl på dr.dk
2. Der er opstået en uforudset situation. Benyt radio, TV eller et andet website for mere information.

Glem ikke, at cyberkrig er en konkret mulighed - som kan benyttes i tillæg til andre terror- eller krigslignende angreb. Eller bare en ulykke.

Joe Sørensen

Det er kun dejligt at de skriver hvilket problem der ramte dem. Det er jo det vi andre lære af. Men jeg kunne godt tænke mig lidt flere detaljer. De taler som om at de har én server der kører helle loadet. Og det ville imponerer mig. Ved en simpel curl, kan jeg se at de har 4 varnish servere i dag.

Så var der et eller andet der trak alle serverne ned samtidig, eller har de lige investeret i flere cache servere siden i fredags? Det ville også imponerer mig hvis de kan få 4 nye servere i drift så hurtigt.

Så hvordan faldt alle 4 Varnish servere ned samtidig?

Baldur Norddahl

Så hvordan faldt alle 4 Varnish servere ned samtidig?

Det står i artiklen. Det var en bagvedliggende server der trak dem ned.

Det hjælper ikke at øge antal af cache servere hvis problemet er at din cache er udløbet og den bagvedliggende server er død. Der er mange varianter af det problem. Det kan også være dynamiske API kald der ikke kan caches og hvor den bagvedliggende server "hænger". Den tager imod nye forbindelser men den hverken svarer eller lukker disse forbindelser. Dermed får din cache server enormt mange døde forbindelser og det er muligt at operativsystemet løber tør for handles. Du går ned selvom der er massere af CPU og hukommelsesresourcer til rådighed.

Ole Laursen

Vi har tidligere kørt Varnish efter at have haft fornøjelsen af at blive præsenteret for det ved et foredrag af PHK i Prosa tror jeg det var (efterhånden mange år siden).

Efter min mening er det største problem med Varnish og lignende caching-løsninger (f.eks. den i nginx der er noget enklere) at standardopsætningen er utilstrækkelig - ja, vi kunne måske udvide det til at gælde næsten al serversoftware. Defaults matter.

Det er mange gange hundesvært som softwareudvikler at lave en god standardopsætning fordi det har en tendens til at kræve at man bruger en masse tid på at eksperimentere med autodetektion og udvikle de rigtige håndtag at stille på. Men et andet problem er mentaliteten blandt udviklere hvor problemer der kan løses ved konfiguration bagateliseres.

Tidligere (og måske stadigvæk) var der f.eks. et problem i Varnish at Varnish som standard gjorde det forkerte hvis back-enden sendte en Cache-Control-header som man normalt sender med hvis modtager ikke kan cache resultatet (private/no-cache).

Man kunne så konfigurere sig ud af problemet. Når man altså opdagede det.

Og det er ikke fordi den noget enklere cache i nginx er ret meget bedre. Cache-Control kan den godt finde ud af men alligevel skal man måske op på 10 linjers almindelig konfiguration + 30 linjers obskur nginx-conf-scripting for noget som reelt kun burde være måske 1-2 linjer.

Jan Petersen

Lidt tyndt at forklare sig med en "Task Force". Er ikke imponeret!
Som en anden skrev, at der var ingen meldinger fra DR, om hvorfor eller hvad der skete og jeg brugte rigtig meget tid på at finde noget som helst omkring dette nedbrud. Først nu og her på Version2 finder jeg noget. Der var intet i Radio Avisen eller de få andre medier som kørte på DR. Det var og er som om de er fuldstændig ligeglade med deres brugere. Hvad ville DR gøre hvis der skete noget alvorligt?

Log ind eller Opret konto for at kommentere
Brugerundersøgelse Version2
maximize minimize