nrk.no

Nedetid på strømmetjenestene, 1. mai 2014

Kategorier: Dev & Nett-tv

503 Service Unavailable :(
Beklager, teknisk feil

1. mai opplevde nok flere at en del av strømmetjenestene for video og radio på nrk.no var nede fra kl 10 og helt til kvelden i 20-tiden. Dette er beklagelig, og vi har begynt å se på årsaker samt tiltak til forbedringer.

Nettjenestene som var berørte av nedetid i går var

  • tv.nrk.no
  • radio.nrk.no
  • tv.nrksuper.no
  • Enkelte interne APIer som benyttes av bl.a. www.nrk.no for å vise bl.a videoklipp i artikler

Alle systemene som ble berørt kjører i Microsofts nettsky, Azure. I Azure er det mulig å konfigurere hvilket geografisk datasenter løsningene skal kjøres på, og i NRKs tilfelle ligger disse på regionen “West Europe”. NRK benytter både Cloud Services, SQL-databaser og Table Storage i skyen for disse løsningene. De kjører i samme geografiske region for å holde svartidene på et lavest mulig nivå ut mot brukerne. Dette er i utgangspunktet en fin idé – med unntak av dersom hele datasenteret skulle gå ned i samme region. Slik det gjorde i går 1. mai.

Når NRK for et par år siden startet på nettsky-satsningen for disse tjenestene, ble det vurdert som en lav risiko at et helt datasenter i Azure skulle gå ned. Kostnaden ved å kjøre et parallelt produksjonsmiljø (redundans) på en annen geografisk lokasjon (f.eks. “North Europe”) ble også vurdert som for høy. Vi kan således ikke skylde på andre enn oss selv. Valget om å kjøre i nettskyen uten et fungerende gjennomtestet fallback ligger hos oss, så det er bare å beklage.

Azure har en SLA på minimum 99,9% oppetid [1], som er innenfor akseptable krav på tjenestene våre ut mot publikum, og har vært ellers et produkt vi er veldig fornøyde med. At et helt datasenter går ned hører så langt med til sjeldenhetene, men er helt klart en ripe i både NRK- og Microsoft-lakken [2]. Vi venter spent på om de frigjør noe informasjon rundt feilen i tiden som kommer.

Beklager nedetiden!

[1] http://azure.microsoft.com/en-us/support/legal/sla/

[2] http://www.theregister.co.uk/2014/05/01/microsoft_azure_cloud/

9 kommentarer

  1. 8760t i året
    10t nede

    oppetid på 99,8858% om ikke noe mer nedetid i år.

    litt usikker på hvor dere vil med å nevne disse tallene.

    det er altså ille med 10t nedetid, mens garantien på 99.9% er meget knapt brutt.

    dere har kanskje ikke regna veldig på hvor mye 0,1% i nedetid er? 8t42m er 0,1%.

    så om bare de hadde klart å få på bena moroa igjen innafor denne fristen på 8t42m så hadde vi ikke sett denne artikkelen?

    hvorfor blir folk alltid overraska av små tall ganga med store tall, gitt store nok tall, fortsatt gir ett stort tall?

    Svar på denne kommentaren

    • Navn? (svar til navn)

      Navn, du har kanskje ikke regnet så mye på SLA før?

      MS’ SLA spesifiserer månedlig avregning, dvs 98,66% oppetid for mai.

      (Og tipper denne artikkelen ikke er avhengig av om MS har brutt SLA’en eller ikke.)

    • Hei navnebrødre!

      Ja, det stemmer. Azures SLA beregnes månedlig, ref. http://azure.microsoft.com/en-us/support/legal/sla/

      Som jeg skrev, så er 99,9 % absolutt akseptabelt og vi er godt fornøyde med Azure. Det har skjedd at vi har hatt mindre episoder med nedetid, men vi har tidligere ikke opplevd en så lang sammenhengende periode med nedetid på tjenestene i Azure. Artikkelen var således ment kun som en liten innsikt i hva som foregikk bak feilene vi gav brukerne våre 1. mai – for de som interesserer seg for de tekniske årsakene bak. Og det pleier det være en del av her på nrkbeta 🙂

      Håper det gav svar!

    • var vel egentlig lite tekniske årsaker nevnt her?

      annet enn at leverandørs ene «node» tryna og at NRK var passe happy med 99.9% nedetid, og var for kjipe til å dobbelsikre seg…

  2. Hvorfor sender NRK (meta-) kundedata, brukeradferd og vårt innholdskonsum ut av Norge og til amerikanske leverandører underlagt FISA og NSA overvåkning? (Akamai, Microsoft)

    Svar på denne kommentaren

    • Heisann!

      Det er mange gode argumenter (og nesten en egen bloggpost i seg selv) for å kjøre denne løsningen i nettskyen, men etter min mening er hovedfordelen at vi veldig enkelt kan skalere etter trafikken løsningen opplever. Vi kan enten manuellt justere hvor mange instanser vi skal bruke, eller så støtter Azure også automatisk skalering basert på CPU/Ant. requests – hvor dette kan settes opp grenser på når vi vil at det skal skaleres automatisk; enten opp eller ned. Dette er kjekt f.eks. under store idrettsarrangementer, eller under valgdagssendingene hvor vi ser at trafikken er høyere enn normalen. Autoskalering gjør også at vi ikke kjører løsningen på flere instanser enn nødvendig under lav trafikk.

      For Azure sin del, så kan du finne mer informasjon om skalering her: http://azure.microsoft.com/en-us/documentation/articles/cloud-services-how-to-scale/

      Skalering er noe de fleste skyleverandørene har i feature-listen:
      – AppHarbor: Tror disse kun tilbyr vertikal-skalering (?)
      – Heroku : https://addons.heroku.com/adept-scale (add-on)
      – Nodejitsu (node.js) https://www.nodejitsu.com/documentation/features/#feature/drones
      – Amazon EC2 http://aws.amazon.com/autoscaling/

      Andre egenskaper vi får automatisk ved å kjøre i Azure:
      – Lastbalansering; med swap-funksjonalitet under utrulling har vi minimalt med nedetid når vi legger ut nye versjoner.
      – Muligheten til å opprette nye miljøer meget raskt, uansett om det er en ny Linux-server med LAMP-stacken eller en Windows Server med .NET-applikasjoner (eller andre – Azure støtter det meste nå til dags).
      – Enkle utrullinger og rollbacks.
      – Overvåking (monitorering).
      – Microsoft tar seg av å holde serverene oppdatert med de siste oppdateringene for Windows.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *. Les vår personvernserklæring for informasjon om hvilke data vi lagrer om deg som kommenterer.