INCIDENTRAPPORT FÖR DRIFTSTÖRNING VÄSTBERGA DATACENTER, ZON 1

Transkript

1 1/5 INCIDENTRAPPORT Falkenberg INCIDENTRAPPORT FÖR DRIFTSTÖRNING VÄSTBERGA DATACENTER, ZON 1 Nedan följer information om vad som orsakade det omfattande driftavbrottet i Zon 1 av Västberga Datacenter onsdagen den 22 oktober 2014 BAKGRUND Vårt datacenter i Västberga, Stockholm (fortsatt kallat VBDC) är planerat i flera olika delar, där vi än så länge endast har tagit Zon 1 i drift. Varje zon planeras med egen redundans för UPS, kyla och distributionsswitchar. För att kunna erbjuda full redundans ut till ett rackskåp används dubbla distributionsswitchar. Tillvägagångssättet för att bygga denna typ av redundans bygger på gängse branchstandard och det är så vi bygger nätverk i samtliga av våra datacenters respektive zoner. Driftstörningen drabbade endast Zon 1 i Stockholm, men fick stora konsekvenser då många kunder är placerade där.

2 2/5 INCIDENTRAPPORT 1 HÄNDELSEFÖRLOPP Fas 1 14:08 Vi får ett larm i vår övervakning om att tjänster slutar svara. Övervakningen visar tydligt att alla berörda larm är koncentrerade till VBDC, Zon 1. 14:11 Vi konstaterar att vi helt tappat kontakten med en av våra distributionsswitchar. 14:15 Tekniker är på plats och felsöker problemet fysiskt. 14:20 Switchen har hög CPU-belastning och vi misstänker DDoS-attack. 14:35 Switchen visar inga tecken på hårdvarufel, men mår väldigt dåligt och CPU-belastningen är forsatt hög. Inga tecken på DDoS kan upptäckas. Ett beslut fattas att starta om switchen. Tekniker väljer rutinenligt att spara switchens konfiguration innan omstart, detta visar sig vara fatalt. Då switchen har hög CPU-belastning, tar sparandet av nuvarande konfiguration väldigt lång tid (det tar normalt bara ett par sekunder). Eftersom läget är kritiskt, så väljer vi att starta om switchen när inget har hänt på 5 minuter. 14:40 När switchen ska starta upp, är hela konfigurationen trasig. Switcharna innehåller flera tusen rader med konfiguration. Den berörda switchen hade ca 110 aktiva portar, varje port med sin egen konfiguration. Varje natt tar vi därför backup på våra switchar. En återläsning av den senaste backupen påbörjas. 15:02 Switchen startar upp men något har gått fel vid återläsningen av backupen. All konfiguration har inte följt med. Vi beslutar att göra en ny återläsning och en ny omstart. 15:15 Switchen startas om igen efter att konfigurationen lästs in korrekt från backupen. 15:25 Omstart och återläsning har gått bra och tjänster börjar fungera igen som planerat. 1 En del tidsangivelser saknas i incidentens logg och är därför uppskattade.

3 3/5 INCIDENTRAPPORT Fas 2 15:36 Vi ser exakt samma händelseförlopp som tidigare, vi börjar tappa kontakten med tjänster igen. 15:40 Vi försöker begränsa vissa tjänster i switchen. Switchen indikerar även i vår felsökning att det är något med IPv6 som är orsaken till den höga belastningen, varvid vi börjar med att stänga ner IPv6-trafik. 15:50 Efter att ha begränsat flera tjänster, väljer vi att göra en ny omstart, då switchen inte visat några direkta tecken på att må bättre. 16:00 Efter omstart ser vi tecken på att switchen mår något bättre. Det är extremt svårt att hitta fel då den höga CPU-belastningen gör att vi inte kan felsöka normalt. En SUP är kontrollerkortet i en bladbaserad switch och de finns i olika versioner med olika kapacitet. Vi har kraftfullare SUP:ar på lager och då det verkar vara ont om CPU-kraft, väljer vi att ersätta nuvarande SUP:ar med den kraftfullaste vi har tillgänglig. 16:08 Switchen startar upp med en ny kraftfullare SUP. 16:25 Det tar längre tid för switchen att sluta fungera, men vi ser att samma problem som tidigare fortfarande existerar. 16:30 Vi håller ett kort möte, och påbörjar två parallella spår. Ett team jobbar på att försöka hitta problemet i switchen, och ett annat team jobbar på att sätta upp en helt ny switch som vi kan börja flytta över trafik till. Vi kallar även in mer arbetskraft som kan hjälpa till både fysiskt och med relaterade supportärenden. 16:50 Genom att stänga ner samtliga portar och VLAN i switchen kan vi få den att må bättre. Detta gör dock att samtliga tjänster som går genom switchen slutar att fungera helt. Vi börjar ett mödosamt arbete med att ta upp port för port i switchen, för att sedan mäta om CPU-belastningen blir högre än förväntat. Sakta men säkert börjar rack för rack i Zon 1 att komma tillbaka i normaldrift. 17:20 Nu har ca 80% av berörda kunder i Zon 1 fått tillbaka sin anslutning. Vi har dock inte hittat källan till problemet, men vi övervakar situationen hela tiden.

4 4/5 INCIDENTRAPPORT 17:45 Vid aktivering av en port, ser vi direkt att problemet börjar komma tillbaka. Vi stänger ner nätverksporten och kan se att CPU-belastningen långsamt sjunker igen. Direkt när vi aktiverar porten igen ser vi att problemet återkommer. Detta gör att vi känner oss säkra på att vi har hittat orsaken till hela driftstörningen. Vi isolerar porten och aktiverar övriga portar. 17:50 Trafik är tillbaka i normalläge, så när som på IPv6 som togs ner vid felsökningen. Vi har även mindre kapacitet till switchen, då vi även vid felsökning tagit ner en del länkar mot våra Core-routrar. SLUTSATS Själva orsaken till felet berodde på en felkonfigurerad port från vår sida. Vi hade missat att aktivera skyddet för rundgång vid redundanta vägar. Konfigurationen gjordes 3 veckor tidigare, men felet uppkom först när en kund till oss kopplade in utrustning i sitt Colocationskåp och skapade rundgång. Det långa gapet mellan när konfigurationen gjordes och när felet inträffade, samt att det inte var vi själva som anslöt utrustningen till vårt nät, gjorde att vi felsökte på fel ställen. Vi har nu undersökt alla våra konfigurationer, och felet har påträffats på 2 andra ställen, av totalt 158 möjliga. Felen är rättade, och vi har upprättat en ny tydligare rutin för hur portar ska konfigureras. I detta fallet ser vi inte att det är felkonfigureringen av porten i sig som är det största problemet i denna incident (även om det var den direkta orsaken). Vi måste alltid vara beredda på att den mänskliga faktorn kan orsaka fel. Vi anser dock själva att driftstörningen tog för lång tid att felsöka och åtgärda, samt att problemet fick för stor omfattning med många berörda kunder. Därför kommer vi att dela in vårt nätverk i varje Zon i mindre grupper, så att vi enklare vet vilket system som i framtiden kan vara orsaken till liknande problem. Hade vi haft detta upplägg idag hade troligtvis åtgärdstiden kunnat mer än halveras, samt att inte lika många kunder hade drabbats samtidigt. Beslut är taget och detta kommer rullas ut i serverhallen under Januari Vidare tror vi att om vi hade haft en bättre metodik i vår felsökningsprocess hade felsökningstiden kunnat kortas ner ytterliggare. Vi måste därför öva mer än vad vi gör idag på att felsöka liknande scenarier.

5 5/5 INCIDENTRAPPORT Tillsammans med de nya rutinerna för portkonfiguration, känner vi att vi tagit de åtgärder vi kan för att förhindra i största möjliga mån att detta ska hända igen. Om något liknande trots allt skulle hända, så kan vi idag begränsa skadan och lösa problemet snabbare. Avbrottet inträffade vid sämsta tänkbara tidpunkt, mitt under kontorstid. Vi vill passa på att be hemskt mycket om ursäkt för de problem och det merarbete som driftstörningen har orsakat er. Avslutningsvis är vi tacksamma för det stöd och det tålamod som många av er har visat. Om du som kund har några frågor eller kommentarer kring ovanstående händelse, kontakta oss gärna på support@glesys.se. Med vänliga hälsningar, Glenn Johansson, VD GleSYS Internet Services AB