Alle klokkeslett i norsk tid (CEST).
Kunders VPS-er driftet på virtualiseringsnoden vps07.proisp.no ble utilgjengelige fra internett — SSH (port 22), HTTPS (port 443) og øvrige porter. De virtuelle maskinene fortsatte samtidig å kjøre helt normalt. Dette ble bekreftet både ved tilgang via konsollen i Virtualizor og ved at tjenestene inne i maskinene virket som de skulle.
Feilen var nettverksrelatert og oppsto på hypervisor-nivå, altså på verten VPS-ene kjører på — ikke inne i de enkelte VPS-ene.
Feilen rammet VPS-ene på verten samtidig. Årsaken, som er beskrevet under, fjernet én nettverksregel som gjelder for samtlige VPS-er på verten under ett. Når den regelen forsvant, mistet VPS-ene på verten nettverkstilgangen i samme øyeblikk — uavhengig av hva den enkelte kunde hadde gjort eller ikke gjort, og uavhengig av om VPS-en hadde vært startet på nytt.
| Tidspunkt | Hendelse |
|---|---|
| 23. august, ca. kl. 10:47 | Feilen inntreffer. |
| 23. august, fra kl. 13:59 | De første kundehenvendelsene kommer inn. |
| 24. august, kl. 09:19 | Feilsøkingen starter. |
| 24. august, ca. kl. 13:00 | Det legges inn en retting av ødelagte brannmurregler, og serveren startes på nytt. VPS-ene blir tilgjengelige igjen. Den bakenforliggende årsaken er på dette tidspunktet ikke funnet. |
| 24. august, ca. kl. 20:25 | Feilen kommer tilbake. |
| 25. august, morgenen | Feilen er fortsatt til stede ved rutinekontroll. Brannmurtjenesten på verten stoppes, og VPS-ene blir tilgjengelige igjen. Dette er et strakstiltak, ikke en løsning. |
| 25. august, ca. kl. 10:30 | Den første av to konfigurasjonsfeil rettes: en avvikende kjerneparameter på verten tilbakestilles. Rettingen anses på dette tidspunktet som permanent. |
| 25. august, kl. 18:40 | Feilen kommer tilbake for tredje gang. |
| 25. august, kl. 18:45 | Normal drift er gjenopprettet etter varsling til tekniker. |
| 25. august, om kvelden | Den andre konfigurasjonsfeilen rettes: en ødelagt konfigurasjonsfil som kun fantes på denne verten, fjernes. |
| 26. august | Den faktiske underliggende årsaken er identifisert og løst. |
| 28. august | De endelige forebyggende tiltakene er på plass. |
Årsaken var en arkitektonisk konflikt mellom Virtualizors system for håndtering av nettverksregler og brannmurtjenesten (firewalld) på denne verten.
Virtualizor legger inn tillatende nettverksregler for hver enkelt VPS direkte i systemets rutingtabell, utenom firewalld. Firewalld kjenner derfor ikke disse reglene. Når en kunde på verten lagrer sin brannmurplan i kontrollpanelet — en helt ordinær selvbetjeningsfunksjon som kundene disponerer selv — utløser det firewalld, som bygger om sin del av det samlede nettverksoppsettet for alle VPS-er på verten samtidig. Under denne ombyggingen fjerner firewalld Virtualizor-regelen, fordi den ikke vet at regelen finnes.
Dette ble bekreftet ved en direkte, kontrollert test 26. august: regelens tilstand ble observert før og etter at én kunde lagret sin brannmurplan. Regelen forsvant, og nettverkstilgangen for VPS-ene på verten ble brutt umiddelbart. Det er også dette som forklarer hvorfor så mange kunder ble rammet på én gang.
De to rettingene som ble lagt inn 24. og 25. august gjaldt en avvikende kjerneparameter (net.bridge.bridge-nf-call-iptables) og en ødelagt konfigurasjonsfil (/etc/firewalld/direct.xml). Begge var reelle, uavhengige konfigurasjonsavvik på nettopp denne verten, og de ble riktig rettet. Men som tilbakefallene viste, var de ikke selve årsaken — de var forhold som forsterket virkningen av den underliggende konflikten.
De første symptomene var ikke til å skille fra en feil i nettverksutstyr utenfor verten, og det ledet feilsøkingen bort fra verten selv i den første fasen.
VPS-ene var på dette tidspunktet ikke selv omfattet av overvåkingen — det var kun vertene de kjører på, og disse fungerte etter alle målekriterier normalt gjennom hele hendelsen. Feilen ble derfor oppdaget gjennom kundehenvendelser, ikke gjennom våre egne alarmer.
Etter at feilen var lokalisert til vertsnivå, ble de to konfigurasjonsavvikene funnet og rettet i tur. Hver av rettingene stabiliserte situasjonen, men ingen av dem hindret nye tilbakefall når brannmurtjenesten ble utløst på nytt. Den eksakte årsakssammenhengen ble først fastslått 26. august, gjennom et direkte kontrollert eksperiment sett i sammenheng med aktivitetsloggen i kontrollpanelet.
Kort oppsummert: vi rettet det vi fant, tre ganger, før det var klart at problemet ikke var en enkelt feil som skulle repareres, men en avhengighet som måtte fjernes.
Brannmurtjenesten firewalld er deaktivert på samtlige noder i miljøet vps01–07, og nettverkstrafikken til VPS-ene er lagt over til en modus som er helt uavhengig av denne tjenesten. I denne tilstanden kan det ikke lenger skje at én kundes lagring av en brannmurplan påvirker nettverkstilgangen til andre kunders VPS-er.
Løsningen er verifisert ved kontrolltesting, der betingelsene som tidligere utløste feilen bevisst ble forsøkt gjenskapt.
Det har ikke vært nye avbrudd på vps07.proisp.no siden 25. august kl. 18:45.
vps07.proisp.no.Vi beklager ulempen dette har medført.