Læs også:
Cloud computing: Sådan fungerer det
Det er ikke nemt at samle en distribueret it-arkitektur i skyen. Jo flere ressourcer man prøver at samle, jo mere kan gå galt. Og nej, det her handler ikke om Amazon's nylige problemer.
Denne gang gik det ud over VMware, som for nylig har lanceret en betaversion af, hvad firmaet kalder branchens første "åbne platform as a service", som er en slags hosting-service for udviklere.
Den 25. april klokken 06.11 fik tjenesten ifølge InformationWeek et mindre problem med en strømforsyning i et storage-kabinet, som gav huller i driften. I forsøget på at reparere det problem, gik siden helt i sort, og den nedtur varede til godt hen på næste dag.
Hændelsen bliver beskrevet af blogger og Cloud Foundry-administrator Dekel Tankel.
Problemet med strømforsyningen betød, at brugerne ikke kunne få adgang til en "logical unit number (LUN)", eller identifikator af en disk eller et sæt af diske i Cloud Foundry.
Et ventet problem
En fejl i strømforsyningen er ikke en uventet begivenhed. Den slags sker, og det er skyer designet til at opdage og overleve. Enten ved at hente strøm fra en anden kilde eller ved at route sig rundt om problemet og bruge en back up.
I dette tilfælde, skriver Tankel, "var vores software, vores overvågningssystem og vores praktiske procedurer ikke synkroniseret."
Konsekvensen var, at det lille ubetydelige problem blev større og bredte sig som ringe i vandet og ramte The Cloud Controller. Se her hvordan CloudFoundry rent faktisk virker.
Da tjenesten var kommet til hægterne igen, og administratorerne fandt ud af, at der slet ikke var mistet data, skete der følgende:
Cloud-teamet fortsatte uforvarende med at forværre fejlen. De ville lære af hændelsen, så driftsteknikerne gik omgående i gang med at registrere, hvad der gik galt og nedfælde en manual for de korrekte procedurer for at undgå en lignende hændelse i fremtiden.
"Planen var, at det skulle være en på-papir-kun-øvelse, indtil manualen blev evalueret," skriver Tankel.
Mere skulle der ikke til
Uheldigvis skete der det, at en af driftsfolkene med manualen kom til at røre tastaturet, og resultatet var, at hele netværksinfrastrukturen foran Cloud Foundry, gik ned. Mere skulle der ikke til.
Tre dage senere skrev Tankel på sin blog:
"This took out all load balancers, routers, and firewalls; caused a partial outage of portions of our internal DNS infrastructure; and resulted in a complete external loss of connectivity to Cloud Foundry through the next 13 hours, until service was restored at 11:30 a.m. April 26."
VMware's uheld er anderledes end det omfattende nedbrud, Amazon var ude for den 21. april, men der er ikke desto mindre uheldsvarslende lighedspunkter, når det gælder den menneskeligte faktor.
Læs hele den detaljerede beretning på InformationWeeks hjemmeside.
