Amazon lijkt nasleep storing nog niet overwonnen te hebben

Volgens Amazon zouden de gevolgen van de storing die de clouddienst van het bedrijf in de nacht van zondag op maandag lamlegde, maximaal twee dagen duren. Dat blijkt echter niet gehaald te zijn; nog niet alle klanten zijn weer online.

De stroomstoring ontstond nadat een transformatorhuisje van het Amazon-datacenter in Dublin werd geraakt door blikseminslag. Door de inslag ontstond een explosie, gevolgd door brand. Als gevolg daarvan waren veel websites die in dat deel van de Elastic Compute Cloud van Amazon werden gehost offline. Het verhelpen van de storing bleek door een samenloop van omstandigheden aanzienlijk langer te duren dan verwacht. Hoewel de stroomvoorziening redelijk snel was hersteld, bleek het terug online krijgen van diverse volumes een probleem. Maandag liet Amazon weten dat het bedrijf verwachtte nog 24 tot 48 uur nodig te hebben voor alle noodzakelijke stappen om de storing voor alle klanten op te lossen.

Naar nu blijkt, heeft Amazon ook deze 'deadline' van 48 uur niet gehaald. Naar verwachting kan bovendien niet iedere klant de storing zonder verlies van data uitzitten. In enkele gevallen kwamen Elastic Block Storage-servers zonder stroom te zitten voordat de gegevens fatsoenlijk waren weggeschreven. In die gevallen zal Amazon een snapshot van een herstelkopie terugzetten, die dus misschien niet helemaal actueel is.

In de praktijk blijkt dat het maken van die snapshot ook niet altijd goed gaat. Amazon heeft in ieder geval met een deel van de getroffen klanten contact gehad. Naar verluidt wordt met deze klanten gesproken over een vorm van compensatie, al is niet bekend of deze zich beperkt tot de reguliere compensatieregeling of ruimer van opzet is.

Klanten die Amazon op basis van de service level agreements willen aanspreken op zijn verantwoordelijkheden, komen mogelijk niet allemaal in aanmerking voor compensatie. Amazon heeft als voorwaarde in zijn SLA opgenomen dat, om in aanmerking te komen voor de compensatieregeling, de storing diverse Availability Zones moet hebben getroffen. Bovendien moet de beschikbaarbeid op jaarbasis beneden de 99,95 procent zijn gezakt, wat neerkomt op ruim 4 uur downtime.

Hoewel de storing zich in een datacenter voordeed, beschikt de faciliteit in Dublin over drie van dergelijke Availability Zones. Het is niet bekend of al deze drie zones gelijktijdig en langdurig onbeschikbaar zijn geweest. Amazon adviseert overigens om een failover in te richten in een datacenter in een andere geografische regio om downtime als gevolg van een storing in een andere regio te beperken, al betekent dit voor veel bedrijven een forse kostenstijging.

Dit is de tweede storing bij Amazon in korte tijd. In april dit jaar werd de aanbieder ook al getroffen door een forse downtime van zijn clouddiensten. De problemen bij het Elastic Compute Cloud-platform van Amazon zouden destijds zijn ontstaan door een foutieve upgrade-procedure, vermoedelijk het gevolg van een menselijke fout.

Reacties (27)

[Longbeard]

Waar eerst de automatische recovery processen van de EBS cloud het probleem waren, blijken nu de recovery tools van Amazon eveneens niet goed te functioneren.

Nu degradeert de cloud niet omdat de automatische 'remirroring' het interne netwerk plat leggen, maar blijkt het interne netwerk wederom niet voldoende bandbreedte te beschikken om de data snel terug te zetten zodat de cloud weer functioneel is.

Zoals Amazon al in haar voorwaarden vermeld is de Amazon cloud alleen veilig te gebruiken, wanneer klanten de applicatie over de Availablity Zones in de regio zelf implementeert. Echter zoals de vorige downtime bleek, is dat niet voldoende. De vorige keer was de gehele regio N. Virginia getroffen waardoor klanten moesten uitwijken naar andere regionen.

Het begint er op te lijken dat de cloud dienst van Amazon alleen veiligheid bied wanneer de klant minimaal voor een dubbele-dubble oplossing kiest. De applicatie minimaal in twee Availablity Zones en minimaal in twee regionen laat draaien.

[mkools24]

Dit kan Amazon nog wel wat centjes gaan kosten als ze SLA's hebben afgesloten die een bepaalde uptime garanderen.

Net even nagezocht en het lijkt mee te vallen voor ze:

If the Annual Uptime Percentage for a customer drops below 99.95% for the Service Year, that customer is eligible to receive a Service Credit equal to 10% of their bill

Bron: http://aws.amazon.com/ec2-sla/

Lekker vaag, dus bij 40% uptime krijg je 10% van je geld terug

[Reactie gewijzigd door mkools24 op 23 juli 2024 10:08]

[Snow_King]

Als je het bericht gelezen hebt staat daar ook in dat de SLA het alleen dekt wanneer je in meerdere zones diensten af neemt.

Als een klant er bewust voor kiest in een enkele zone zijn VM te draaien en Amazon helder (dat weet ik niet!) communiceert/adviseert dat niet te doen, dan kan niet alle schuld richting Amazon worden geschoven.

Een tijdje terug speelde het zelfde, KPN had een vreselijke ADSL storing en toen bleken diverse bedrijven hun hele kantoor achter een consumenten lijn te draaien, ook daar was KPN niet verantwoordelijk voor.

Je moet nooit op één paard wedden is mij geleerd.

Indien de dienst je ZO belangrijk is, dan tref je de maatregelen dat je bij uitval een backup plan hebt. 100% uptime bestaat niet en kan niemand, maar dan ook niemand op deze wereld je garanderen.

[Reactie gewijzigd door Snow_King op 23 juli 2024 10:08]

[Verwijderd]

Nee. Ben ik niet mee eens. Je gaat juist op de cloud zodat je je niet zorgen hoeft te maken over redundancy en backups en alles. Dat moeten zij regelen voor je, daar betaal je voor. Niet (zozeer) voor de servers of CPU tijd.

[awulms]

Je kunt veel redenen hebben om naar de cloud te gaan. Het niet hoeven te beheren van een eigen computerpark is er slechts een van. Een andere reden kan zijn om meer flexibiliteit te hebben in de applicatie belasting, door een 'pay per usage' model te hanteren. Iets waar amazon sterk in is. Maar zelfs als je naar de cloud gaat zul je nog altijd goede afspraken met je leverancier moeten maken over de strategie die de leverancier hanteert om de data te beschermen tegen calamiteiten, zoals het repliceren naar meerdere data centers. Als je daar geen afspraken over maakt dan moet je ook niet verbaasd zijn als alles in slechts een data center staat vanwege kosten overwegingen. Bij amazon zijn dergelijke zaken makkelijk contractueel te regelen. Het kost je alleen meer als je wilt dat je data in meerdere data centers staan. Dat is dus een keuze die je als bedrijf moet maken. Meer betalen voor een lager risico op data verlies of voor de goedkoopste oplossing gaan en het risico op de koop toe nemen.

[dcm360]

Dat hangt natuurlijk geheel af van welk product je gaat afnemen. Jouw idee van wat een clouddienst moet bieden, bieden ze ook gewoon aan. De goedkoopste optie is het echter niet.

[bbob]

Aangezien ze het over jaarcijfers hebben zal die 10% op van toepassing zijn op je jaarlijkse rekening lijkt me.

In dat geval kun je dus iets meer dan 1 maand schadevergoeding krijgen.

Maar het ene en ander zal ook wel afhangen hoe groot je als klant bent en of je dreigt om ergens anders heen te gaan.

[barber]

Microsoft is ook getroffen door dezelfde storing. Ik heb daar een BPOS accountje. Helaas lag alles eruit van 20:30 tot 2:30 of zo. Maar kreeg gisteren een mailtje dat ik op een volgende maandelijkse factuur 25% korting krijg.

[Verwijderd]

En dat is nou het grootste probleem van een 'cloud', je kan niet altijd bij jouw gegevens. Stel je voor dat je een internet-based laptop hebt voor je werk en alle belangrijke data voor je presentatie op zo'n 'cloud' hebt staan. Dan ben je mooi in de aap gelogeerd als er een storing is.

Nee, blijf gewoon lekker bij je eigen HDD, waar je relatief veilig altijd bij de data kan komen!

[LessRam]

Tjemig +2..... hier op en door Tweakers
Hoe groot is de kans dat The Cloud eruit vliegt afgezet tegen de kans dat je HDD er uit klapt. Ik heb zo'n vermoeden dat je HDD het aflegt.

Klinkt als iemand die liever met de auto op vakantie gaat dan met het vliegtuig "omdat er zoveel vliegtuig ongelukken zijn"

[Precision]

Dan zorg je toch altijd voor een offline back-up? usb stick en nog eens mailen naar jezelf (is de enigste reden waarom ik gmail heb overigens). Als je hdd het begeeft kun je nog altijd een laptop lenen om je presentatie te geven.
Edit:
+ Als je een presentatie wil geven, weet je toch al wat je gaat zeggen. Desnoods zonder projector/laptop en old skool met de stif/krijt wat aantekenen maken. Mijn voorbereiding is gewoon een soort kapstok van wat ik wil zeggen, ik heb zelfs een hekel aan presentaties omdat wat ik wil zeggen dan al vastligt, wat overigens niet wil zeggen dat ik over tijd ga als ik één moet geven

[Reactie gewijzigd door Precision op 23 juli 2024 10:08]

[Patriot]

[quote]
En dat is nou het grootste probleem van een 'cloud', je kan niet altijd bij jouw gegevens. Stel je voor dat je een internet-based laptop hebt voor je werk en alle belangrijke data voor je presentatie op zo'n 'cloud' hebt staan. Dan ben je mooi in de aap gelogeerd als er een storing is.[quote]

Je begint prima..

Nee, blijf gewoon lekker bij je eigen HDD, waar je relatief veilig altijd bij de data kan komen!

Oeioeioei! Slecht advies! De kans dat dát een keer fout gaat is namelijk ook aanwezig. Je creëert hoe dan ook een single point of failure. Als je gegevens wilt bewaren doe je er goed aan dit op meerdere plekken te doen, zowel 'logisch' (dus bijv. twee verschillende schijven in de PC) maar ook fysiek (op meerdere locaties, dus bijv. een kopietje in de cloud). Dan is de kans op dataverlies minder groot als er maar 1 ding verkeerd gaat.

Natuurlijk is zo'n methode nooit te perfectioneren, maar een single point of failure creëeren is vragen om problemen.

[Zware Unit]

Had Amazon zich beter moeten voorbereiden of valt dit onder an 'act of God'? (link)

Blijft natuurlijk behoorlijk pijnlijk als dit de core business treft.

[Verwijderd]

Geen enkele dienst is altijd 100% online. Dit geld voor alle cloud partijen tot aan je eigen HDD. De enige manier om in de buurt te komen van 100% is niet alles te plaatsen op 1 locatie en te zorgen voor een werkende redundantie.

Ik werk zelf voor een cloud partij en we raden klanten die 100% willen altijd aan om minimaal over 2 fysiek gescheiden locaties te staan.

Daarbij komt ook nog eens bij dat er factoren zijn (zoals f#cking bliksem) die je uptime in geding brengen. Geloof maar dat het datacenter van Amazon genoeg bliksem afleiders heeft staan.

[PHiXioN]

... en daarom moet je dus periodiek een disaster recovery test uitvoeren.

[Verwijderd]

Ik ben ook klant, koop bij hun wel eens wat, maar heb nergens last van.

[Zware Unit]

Ben jij ook klant van de Cloud? Want op basis van je reactie denk ik eerder dat je een klant bent van de Amazon.com webshop.

[Precision]

Het gaat over hun aws cloud service: http://aws.amazon.com/ec2/ niet over hun webshop.

[analog_]

Waar zijn de cloud predikanten nu?

[LessRam]

Hoeveel Cloud diensten crashen er per dag en hoeveel HDD's crashen er per dag? Zet dat ook even af tegen de kans dat er backups zijn (Cloud 100%, HDD.... stukken minder)

[Reactie gewijzigd door LessRam op 23 juli 2024 10:08]

[Tozz]

Dat is niet relevant. Je eigen HDD failures vang je ook op met RAID. analog_ heeft wel een argument. Door cloud predikanten is altijd gezegd dat de cloud het ultieme middel is, geen omkijken naar je servers, altijd bereikbaar en dataverlies is onmogeiljk.

Eerst bleek dat je feitelijk de producten 2x moest afnemen (Multiple Availability Zones) om redundantie te krijgen. Toen bleek dat ook niet altijd heilig te zijn. En nu zijn er ook klanten hun data kwijt.

Blijkbaar, als je echt je dienst redundant wil hebben moet je 2 cloud operators hebben, maarja dan ben je wel in 1 klap alle voordelen van de cloud kwijt omdat je dan je systeem geschikt moet maken voor 2 systemen. Dan kan je imho net zo goed 't weer in house redundant gaan uitvoeren.

Die cloud begint in mijn optiek een zeepbel te worden. Het is allemaal niet zo heilig als dat het ons voorgeschoteld is.

LessRam z'n statement dat er in de cloud 100% backups zijn klopt niet, want zoals in het bericht genoemd waren er niet altijd backups beschikbaar / backups waren corrupt. MClaey's zijn melding dat er wel 100% backup is, maar dat die soms corrupt is is natuurlijk geen backup. Een backup maken die je vervolgens niet kan terugzetten is natuurlijk geen backup.

[awulms]

Dan kan je imho net zo goed 't weer in house redundant gaan uitvoeren

Als je bescherming wilt hebben tegen zware calamiteiten zoals een blikseminslag die een compleet transformaterhuis eruit knalt, dan zul je ook als je voor 'in house' gaat nog altijd twee data centers moeten op zetten, op twee locaties die vergenoeg van elkaar afliggen zodat ze niet beide door dezelfde calamiteit tegelijk getroffen kunnen worden. Het opzetten van twee data centers is best wel prijzig. Vooral omdat je ook nog real time replicatie van al je data updates wilt hebben zonder dat de server toepassingen te traag worden door dit extra data verkeer. Dat trek je niet met een ADSL lijntje of met een consumenten kabel-internet abbonement. Dan zul je toch voor een duurdere data pijp met de bijhorende SLAs en alles moeten gaan, wat natuurlijk nog boven op de kosten voor je gebouw, servers, systeembeheerders, etc. komt.

Het kan natuurlijk allemaal wel. Maar mischien is het toch goedkoper om naar een cloud of hosting provider te gaan en je goed te informeren over de backup, replicatie en beschikbaarheids strategie van die leverancier en een goed contract af te sluiten zodat je zeker bent dat al die zaken goed geregeld zijn. Een dergelijk contract is natuurlijk ook niet goedkoop maar kan toch nog altijd financieel een stuk interesanter zijn dan je eigen data centers op te zetten, vooral als je maar een klein bedrijf bent zonder de schaalgrootte om meerdere gebouwen, computers, systeembeheerders, etc. te betalen en bezig te houden.

[Reactie gewijzigd door awulms op 23 juli 2024 10:08]

[analog_]

Tijdelijke storingsmethodes genoeg om dat op te vangen, zoals B-feeds en vliegwiel&accu oplossingen, ik gok dat ze 'node' redundantie niet persé hoog vandel is voor een cloud omdat het toch software matig opgevangen wordt, maar dan moet dit wel werken en nu blijkt van weer niet. In het slechtste geval kan je het gooien op kinderziektes en SLAs vangen dingen op, maar uiteindelijk wordt er niemand blij van.

Ik ben er vrij zeker van dat we niet bijzonder veraf staan van een robuste cloud oplossing, hopelijk kan amazon hun zaken inorde krijgen.

[corl]

Lees jij wel? Het blijkt nu dat er juist in de cloud geen 100% back-up is.!! Dat is wel heel erg als je data daar staat.
Als je het zelf beheer weet je tenminste waar je wel een niet back-ups van hebt. In dit geval dus een stuk betrouwbaarder. HDD's crashen normaal niet zomaar en een HDD crash heeft normaal ook geen gevolgen door de raid opzet. Eigen backup's op 1 of meerdere co-locaties blijken door dit voorval veel betrouwbaarder (als het er op aan komt).

[MClaeys]

Er is wel 100% back-up, echter kan het soms mislopen met corrupte image/backups tot gevolg. Dat servers te snel zonder stroom vallen waardoor data niet kon weggeschreven worden daar kan de gebruiker weinig aan doen, Amazon echter wel. Er kan altijd iets mislopen, zelfs met data in de cloud ben ik van mening dat een lokale backup zeer op zijn plaats is. Backups kan je nooit genoeg hebben

[raphidae]

Komen binnen 48 uur aankakken

[DeuTeRiuM]

Het is wel handig als je kort veel reken capaciteit nodig hebt. Waar zijn de datacenter predikanten nu? Even een datacenter bouwen om iets uit te rekenen of te analyseren.

Wat betreft availability.. tjah een datacenter valt ook wel eens uit. Dus als je echt een redelijk bedrijf bent, moet je toch al een fallback locatie hebben.