Nasleep Amazon-cloudstoring kan nog twee dagen duren

De gevolgen van de stroomstoring die Amazon in de nacht van zondag op maandag trof na blikseminslag, kunnen nog 24 tot 48 uur merkbaar zijn. Nog steeds zijn niet alle sites weer online. In sommige gevallen is ook data verloren gegaan.

Hoewel Amazon direct aan de slag is gegaan met het verhelpen van de storing, blijkt dat dit aanzienlijk langer duurt dan verwacht. Hoewel de storing zondagavond rond 20.00 uur optrad, bleek dat 12 uur later nog niet alle instances van de Elastic Compute Cloud van Amazon weer in de lucht waren. Oorzaak lijkt een opeenstapeling van problemen te zijn.

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. Hoewel een stroomonderbreking doorgaans wordt overgepakt door een noodgenerator, bleek dat de impact zo krachtig was geweest dat ook het controlesysteem van de stroomfases werd lamgelegd. Dit systeem zorgt ervoor dat de noodgenerator wordt gesynchroniseerd. Zonder deze fasesynchronisatie kunnen generators niet automatisch worden ingeschakeld, waardoor een handmatige actie was vereist.

Niet alleen kostte het veel tijd om alle volumes handmatig te herstellen, ook bleek de beschikbare schijfruimte een probleem. Voor het herstellen van de volumes moest Amazon een extra kopie van alle data maken, waardoor nagenoeg alle beschikbare opslagcapaciteit volliep en het herstelproces extra werd vertraagd.

Gedurende de dag heeft Amazon extra opslag toegevoegd om dit probleem te ondervangen. Hoewel de cloudaanbieder stelt dat het leeuwendeel van de volumes gedurende de dag weer wordt hersteld, schat het bedrijf dat het 24 tot 48 uur zal duren voordat het hele proces is afgerond.

Naar verwachting zal niet iedere klant de storing zonder verlies van data kunnen 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.

Reacties (39)

[Vinnybinny]

Bizar dat dit kan gebeuren. Wordt er dan niet realtime gebackupt? Probleem is dat je als bedrijf wanneer je belangrijke data op de cloud hebt staan je nu totaal machteloos bent, en alleen maar kunt afwachten.

[Rob Coops]

Natuurlijk is er een backup beschikbaar en is het terug zetten een kwestie van op een knop rammen en wachten maar... en dat is waar hem de kneep zit. Heb je ooit al eens geprobeerd vele honderden TB aan data te restoren? Het maakt niet uit welk merk product of oplossing je gebruikt TB's aan data van een tape terug halen kost simpel weg aardig wat tijd.

Op de hoeveelheid machines die men daar aan het restoren is zijn ook altijd een aantal machines waar een probleem gevonden wordt na de restore... het gebeurt maar bij 1 op de paar duizend machines of zo maar als ik enkele tienduizenden machines recover dan kun je er donder op tegen zeggen dat er ergens wel een probleem optreed na de restore.

Als klant ben je dan ook erg dom bezig als je voledig op Amazon/RackSpace/<welke andere cloud dienst dan ook> vertrouwd. Als de data zo kritiek is dat je bedrijf niet door kan werken zonder dat je bij de data kan dan hoor je een backup oplossing te hebben die ingeval van nood de data beschikbaar kan maken.
Als klant weet je dat er altijd het risico is dat een IT systeem down gaat wat de SLA ook zegt je het altijd een kans dat deze afspraak niet na gekomen wordt door wat voor onverwachte storing dan ook. Jouw taak als klant is dan om te bedenken wat de schade zou zijn als het fout gaat, als deze bijvoorbeeld 1k per dag is dan kunnen de meeste bedrijven best wel een paar dagen zonder zitten. Het is niet fijn maar overmacht is overmacht... maar als het 100k gaat kosten dan kun je redelijk makkelijk verantwoorden om bijvoorbeeld zelf een backup server te hosten of deze bij een andere cloud boer neer te zetten voor het geval dat...

Als klant kun je je niet beroepen op de SLA alleen je bent zelf verantwoordelijk voor de planning hoe met dit soort dingen om te gaan en om er rekening mee te houden dat dit altijd kan gebeuren ongeacht waar je je data ook host.

[0siris]

Als klant kun je je niet beroepen op de SLA

waarom niet? Je kunt in je SLA toch een RTO afspreken?

[AugmentoR]

Een Service Level Agreement is in welke vorm dan ook slechts een contractuele afspraak...
Als het écht kritisch is, zorg naast je mooie SLA voor nóg een backup in de vorm van iets als een Worldwide Ondemand Realtime Transaction Emergency Layer of een Perpetual Emergency Evacuation Raster

[Reactie gewijzigd door AugmentoR op 24 juli 2024 23:14]

[Rob Coops]

Inderdaad een SLA is geen garantie alleen een overeenkomst dat het doel beschrijft voor bijde partijen. Een doel dat niet noodzakelijkerwijs gehaald hoeft te worden... En dus ondanks dat je misschien een ruime schade vergoeding overeen gekomen bent in de SLA zul je je toch moeten af vragen of je klanten daar baat bij hebben.

Als mijn dienst er een x aantal dagen uit ligt krijg ik van cloud service A 100k euro maar, mijn klanten hobbelen allemaal naar de concurrentie en ik kan ze maar zeer moeilijk weer terug krijgen. Als ik 100k per jaar verdien dan is dat misschien geen gekke optie maar als ik 100k per maand verdien dan is dat onacceptabel.

Je kunt afspreken wat je wilt maar het is geen garantie alleen een streven. Dit is de reden waarom bedrijven een recovery locatie aan de andere kant van de wereld neer zetten omdat als er een ramp gebeurt, het land in chaos veranderd zo als in het midden oosten of bijvoorbeeld de bliksem alle goede voornemens en afspraken nutteloos maakt men toch door kan werken.
Het hangt van de kosten van een outage af of je dat ook echt moet doen. als de kosten hoog genoeg zijn dan is een disaster recovery plan niet langer een optie maar een must.

[Gert]

Waarom moet men alles restoren? Een beetje SAN heeft een batterij en start automatisch een procedure om z'n cache te flushen en netjes af te sluiten.

[borft]

dat helpt niet als de data niet in de cache van de SAN staat, maar nog in bijvoorbeeld kernel cache van het OS

[Verwijderd]

De Cloud is echt een verkoop truck!

Je moet nog steeds zelf inventief zijn in je software om enige failover in te bouwen.

Goede redundancy is niet goedkoop... alleen een POS!

[Sorcerer8472]

In theorie is een multi-locatie-cloud wel degelijk een failover. Echter, de cloud-software moet dan wel 100% kloppen, er mogen geen bugs in zitten en er moet voldoende hardware zijn om bijv. uitval van een volledige locatie aan te kunnen. Ook de software die die uitval dan compenseert moet volledig kloppen.

Als je je software bouwt voor gebruik op een cloud-platform dan moet ook al die software helemaal kloppen en met eventuele uitval om kunnen gaan, al is het maar voor je eigen gemoedsrust, en al is het strikt genomen niet noodzakelijk als je ervanuit gaat dat de cloud-provider geen fouten maakt.

Kortom: de cloud is wel "beter", maar het is zeker geen wondermiddel waar je te allen tijde zomaar op kunt vertrouwen.

[SuperDre]

Tja, en ieder heeft zo zijn eigen definitie van 'cloud'..

[MeZZiN]

Helemaal mee eens cloud based systemen moet je gewoon bouwen op basis van dat ze elke moment kunnen down gaan maar dat er dan wel gelijk nieuwe gestart worden zodat de gebruikers er helemaal niets van merken.

[paknaald]

Tweede keer in een half jaar voor Amazon. Juist van Amazon verwacht je dat ze 'de cloud' inrichten met backup systemen die wellicht mindere performance leveren, maar wel enige beschikbaarheid bieden?

[Verwijderd]

Onvoorstelbaar dat dit soort dingen gebeuren. 2x in een jaar is wel absurd na alle marketing rondom cloud services die opscheppen over de perfecte beschikbaarheid vanwege redundantie etc.

downtime kan een keer gebeuren (geen systeem is onfeilbaar, hoe je het ook mirrored/backupped) maar een dergelijk systeem 2x in een jaar een dag of meer offline zou ik van een kleine webhoster niet eens accepteren.

[Spockz]

Dit is wel iets waar je niet echt rekening mee kan houden. Je kan wel extra redundancy neerzetten maar daar mag je voor betalen. Als je dat niet doet als klant dan mag je ook niet klagen dat er wat stuk gaat.

Bovendien ging hier onverhoopt de backup stroomvoorziening down, aan dit soort dingen kan je weinig doen. Je kan alleen hopen dat het zaakje weer snel herstelt wordt.

[Cergorach]

Amazon heeft die opties, die moet je echter wel apart aanschaffen en daar hangt natuurlijk weer een stevig prijskaartje aan vast. Iets dat een hoop klagers niet willen neerleggen voor de redundantie. cloud != offsite redundantie

[Verwijderd]

The bigger they are, the harder they fall... and the more time it takes to recover....

Dit gaat uiteraard ook op voor Amazone. De groter ze worden des te complexer het wordt. Ik ben allang blij dat ze voldoende schijfruimte hebben om te recoveren (backup maken voor beginnen). Er zijn zat bedrijven die er pas achter komen na een crash dat ze een probleem hebben (niet voldoende schijfruimte voor recoverywerkzaamheden, Memory overcommitment, disastersplan nooit getest, etc.)

[bReChThOu]

Tsja, meer dan 3 maanden na Amazon belooft aanpassingen na langdurige cloudstoring is het toch jammer dat er weer data verloren gaat, of het nu om een menselijke fout gaat of niet, het zou in principe toch niet mogen gebeuren...

[Cergorach]

Heb je gelijk in, maar het heeft twee verschillende oorzaken, de eerste softwarematig, de tweede hardwarematig. Ik ben zeer benieuwd hoe die storage wordt geregeld, als er data verloren gaat omdat alle data nog niet was weggeschreven is er toch hardware matig wat mis. Geen UPS of backup battery voor RAID systemen.

[Pascal Saul]

Probeer maar eens uit de cloud te komen

http://aws.amazon.com/ec2/vmimport/ :"The VM Import process currently supports VMware ESX VMDK images for Windows Server 2008. We plan to import additional operating systems, versions and image formats in the future. In addition, we will enable exporting Amazon EC2 instances to common image formats."

Mijn inziens is het nog geen proven technology...

[MeZZiN]

Tja je kan ook alles verzinnen wij hebben onze 'cloud' ec2 instances zo opgezet dat we zo over kunnen op een andere hosting omdat we by design de config simpel houden. We hadden zelf iets van een klein uurtje last laat op de avond op een zondag. Not a big issue gelukkig voor ons.

Maar verder amazon heeft heel veel zaken heel goed op orde. En als je zelf een multi zone multi region oplossing wilt is dat gewoon te doen en goed te betalen. Amazon is als je het goed opzet net zo duur als je hoster alleen dan heb je wel multi zone multi region en daar die hoster niet tegen op.

Veel vinden de cloud niet verstandig of iets maar je moet gewoon je EC2 opzetten met de gedachte als deze down gaat dan staat er binnen een minut of 2 een nieuwe te pruttelen in productie en als de load te hoog wordt opeens 10 of meer (hoe je het heb opgezet natuurlijk) dit kan gewoon weg niet je 'cloud' hoster op de hoek. We hebben ooit zo gedaan maar blij dat we weg zijn. Het schaalt gewoonweg niet. Voor nu is amazon het best ontwikkeld ik hoop dat er nog een concurrent komt die hetzelfde kan bieden als amazon.

[stijnislike]

Als ik je tekst moet geloven is dit juist in de toekomst wel goed mogelijk....

[Pascal Saul]

Juist in de toekomst maar dat zeggen ze ook al 9 maanden...

Nu doet zich een probleem voor en je kan nu dus niet per direct weg op een 'snelle' manier.

Wat dat betreft is een op VMware gebaseerde cloud omgeving flexibeler waar je wel in en uit kan.

[Verwijderd]

Bedrijven die het niet kunnen veroorloven om down te gaan kunnen gewoon een extra dienst afnemen waarmee hun servers in verschillende volledig bescheidde datacenters kome te draaien. Mensen willen alleen voor dubbeltje op de eerste rang zitten en nemen het risico voor lief. Maar dan wel heel hard gillen als er iets mis gaat, tja, je krijgt waar je voor betaald.

[arjankoole]

Voor veel bedrijven is dat niet acceptabel, omdat die data dan in het buitenland komt te staan.

Je hebt 't nog altijd over bedrijfsgeheim.

[_gibeon_]

Dan moet je maar een Nederlands datacenter zoeken, die zijn er ook gewoon. Maargoed, daar komt het "voor een dubbeltje op de eerste rang zitten" verhaal weer om de hoek.

[Verwijderd]

Dan is er nog het probleem wie de eigenaar van het datacenter is. Als dat bijvoorbeeld een Amerikaans bedrijf is kan de Amerikaanse regering de data opeisen.. Iets wat je niet wil als bedrijf...

[mati1983]

er zijn zát DC's in Nederland, die in handen van Nederlandse/Europese eigenaren zijn hoor..

Verder ken ik de SLA-opties van Amazon niet zo heel goed, dus kan er niet inhoudelijk op reageren.

Wel geldt dat Amazon een prijsvechter is. Leuk voor de groenteboer op de hoek, maar een grote enterprise toko heeft daar voor hun core systemen echt bar weinig te zoeken.. Zowel om Technische, strategische en legal redenen..

Het niet beschikbaar zijn van afdoende opslagcapaciteit is verder natuurlijk belachelijk en kan legal gevolgen hebben voor Amazon. Nogmaals, ik ken de SLAs niet, maar naast de service levels en bijbehorende penalty clauses, staat er ongetwijfeld iets in over het feit dat Amazon haar stinkende best dient te doen om de boel draaiend te houden. Failover verkopen, maar in de praktijk niet kunnen leveren door dat je capacity management crap is, helpt daar niet bij..

Verder ontwerp ik bar weinig DC's, maar ik vind het van de zotte dat een stroomstoring dit kan doen.. Hoezo de impact was "dusdanig krachtig"? Klinkt mij als een tier3(+) constructie in de oren.. Zou niet helemaal moeten kunnen dus :-) Designfoutje ergens?

Grootste probleem voor Amazon in dezen is mijns inziens overigens de deuk die hun image nu oploopt. Amazon is groot geworden door de prijzen en het beeld neer te zetten "niet stuk te kunnen". DMU's staren zich de laatste jaren blind op pricing.. Wellicht dat ze zich door dergelijke verhalen eens achter de oren zullen krabben, alvorens voor een dubbeltje op de eerste rang te willen zitten. Wellicht toch maar een kwartje betalen..?

[ingmaronline]

Speltip #1: spreid je kansen

[Verwijderd]

Wij hebben hier ook een aantal klanten zitten die wel op de terminal server kunnen werken maar niet meer kunnen emailen want de email server ligt dus plat..........

[Verwijderd]

Mooi voordeel van die cloud ttechnologie en allesn ergens vreemd opslaan.

[Commendatore]

Heeft dit eigenlijk nog invloed gehad op de websites van Amazon zelf?

[sumac]

Ik denk het niet, althans niet merkbaar. Zij gebruiken waarschijnlijk alle datacenters die ze hebben, en hebben het natuurlijk zo ingericht dat de diensten direct overgenomen worden door andere datacenters. Dat is de basis van het hele concept, dat ze zelf zo groot werden en zoveel servers nodig hadden, met alle bijbehorende problemen, dat ze uiteindelijk een cloud op zijn gaan zetten en toen inzagen dat ze die cloud ook als product konden verkopen.

Ga er maar vanuit dat alles wat ze jou als klant aanbieden, allang voor zichzelf gebruiken. Als de website van Amazon down was geweest, dan was dát de epic fail geweest, want dan had het nergens meer gewerkt.

[Verwijderd]

Is de cloud van Amazon voor consumenten of bedrijven? Als het bedrijven zijn dan kunnen ze wellicht een flinke schadeclaim verwachten met de SLA's. Ik werk bij een grote multinational en daar willen ze ook veel van hun servers afstoten en onder brengen in de cloud. Ik weet niet of dat een goed idee is..

[mati1983]

"De cloud" is een waanzinnig mooie term, maar zegt eigenlijk opvallend weinig. Wat versta jij onder "clouddiensten"? En (no offence) voor een multinational lijkt me dat een opvallend beroerde strategie! Wat exact is jullie reden om te gaan afstoten? Aangezien je het over een cloud optie hebt, vermoed ik stukje costs saving?

TIP: Probeer niet in oplossingen te denken! Gooi een RFP in de markt met daarin jullie beweegredenen, strategie/visie en huidige situatie. Laat de aanbieders maar met oplossingen komen. Zij hebben hier tenslotte meer ervaring mee.. Wanneer jullie eigen mensen virtualisatie voor ogen hebben, zal dat waarschijnlijk wel daar ergens op uit komen.. Maar sta niet te kijken van een hybride oplossing, met zowel virtuele als classic machines.. Simpelweg doordat niet iedere applicatie zich leent voor virtualisatie. (bv door hoge I/O)

Afstoten betekent ook een stukje loslaten, wat voor zeer veel organisaties, om diversie, begrijpbare redenen, verdomd moeilijk blijkt..

[Verwijderd]

Ehh, juist.

[sumac]

Waarom beroerd? Welke multinational is het? Neem Sony eens. Zij doen vanalles, games, films, muziek, software, hardware. Veel van wat ze aanbieden zijn download- en streamingdiensten, en dat lijkt me ideaal om in de cloud te hosten.

Neem een bank, dan is het misschien wat anders. Neem een Shell olieraffinaderij, waar vast vele servers draaien om vanalles te regelen - dan zou ik het ook niet bij Amazon hosten. Misschien is het dataverlies nog niet zo relevant, maar het feit dat je twee dagen eruit kan liggen is onverteerbaar.

Wat ik wil zeggen: afhankelijk van het soort dienst kan de cloud heel zinnig zijn. En dat heeft niks te maken met de vraag of je een multinational bent of niet.

[mati1983]

Jullie begrijpen mijn punt niet helemaal denk ik .. Natuurlijk kán een cloud oplossing de juiste keuze zijn, maar wellicht ook niet..

Maar een dergelijke uitbesteding is wat anders dan een pak melk kopen. Daarvoor loop je naar de melkboer en specificeer je heel duidelijk "één liter halfvolle melk svp". Bij de casus hierboven (een multinational die veel van hun servers uitbesteedt) ligt dat toch echt ff anders.. Daarbij vertrouw je op de expertise van je leverancier. Je legt je eisen en wensen op tafel.. Of ze dat vanuit de cloud of met telraampjes realiseren zal je een rotzorg zijn.

Dat de oplossing onafhankelijk is van de grootte van de organisatie klopt overigens. Echter, aangezien het hier op een multinational gaat (en daarvan een groot deel van hun servers) ga ik er even vanuit dat daarmee hun core processen geraakt worden. Hadden we het hier over stratenmaker X, dan was het waarschijnlijk wat minder boeiend geweest of z'n websiteje dr een dagje uit lag...

En wat betreft jouw Sony voorbeeld:

Vergeet niet dat de customer frontend waarschijnlijk maar een zeer klein deel is van hun infrastructuur. Maar ook van dit deel zou ik d;r niet zomaar blind vanuit gaan dat het geschikt is voor virtualisatie.. De download- en streamingservices wellicht wel.. Mooie cloudbased CDN en caching services waarschijnlijk.. Maar dat draait waarschijnlijk allemaal op een CMS, die wellicht wel eens wat minder geschikt is voor virtualisatie.. Een grote Tridion omgeving bijvoorbeeld..

Oftewel: Ga geen oplossingen bedenken wanneer je uit gaat besteden, laat ze dat lekker zelf doen. (en dan heb ik het dus over écht uitbestegen.. hosting/TAM(/FAM), en geen housing)