Grote storing Amazon-clouddiensten treft websites

De clouddiensten van Amazon kampen al bijna 24 uur met een storing, waardoor veel websites problemen ondervinden. Grote websites als Reddit en Foursquare waren offline. Nog steeds kampen sommige sites met problemen.

Donderdagmorgen rond half 11 werden de eerste problemen met de Amazon-clouddiensten gemeld. Een van de grootste en belangrijkste serverparken van de dienst kampte met connectiviteitsproblemen. Onder meer instances van Amazons Elastic Cloud-dienst kampten met uitval, maar ook met de database- en statische-opslagdiensten van het bedrijf waren problemen.

Een onbekend aantal websites ging door de problemen offline, waaronder grote sites als HootSuite, Reddit en Foursquare. Ook de website van de Amerikaanse krant The New York Times had problemen. Het was bijvoorbeeld niet mogelijk om op artikelen te reageren. Inmiddels zouden de problemen gedeeltelijk weer zijn opgelost, maar onder andere Reddit heeft nog steeds moeilijkheden. De website werkt tijdelijk in 'read only'-modus. Ook hebben sommige sites nog te maken met downtime, zoals de populaire webcomic Ctrl+Alt+Del.

De storingen bij Amazons clouddiensten zijn pijnlijk voor het bedrijf, dat servercapaciteit verhuurt op basis van een 'pay as you go'-model. De downtime wijst op een nadeel van cloudcomputing. Bedrijven en instellingen kunnen bij storingen bij een externe partij weinig anders doen dan afwachten totdat de problemen zijn opgelost.

Reacties (69)

[Longbeard]

Dit is helaas niet de eerste keer dat de EBS volumes kapot gaan. Afgelopen 25 maart waren er al eerder aanwijzingen dat de EBS fundamentele problemen kent. De uitval van een enkele harde schijf zorgde ervoor dat het geheel RAID systeem down ging. De belofte van Amazon "Each storage volume is automatically replicated within the same Availability Zone. This prevents data loss due to failure of any single hardware component." bleek en blijkt niet waar te zijn. Daarboven op kwam nog het probleem dat de backups eveneens niet goed terug te vinden waren. De meest recente backup werd pas na 10 uur door Amazon "teruggevonden"

Dezelfde problemen die we toen zagen zien we nu weer terug. EBS volumes die niet meer online komen, waarbij al de data verloren is gegaan, waarbij de backup, op een nieuwe EBS volume, vanaf een tape terug moet worden gezet.

Indirect, bijvoorbeeld via de Ruby-on-Rails clouddienst Heroku zijn duizenden applicaties en websites getroffen.

[Arnold]

Is het juist niet het voordeel dat je met cloud tools van Amazon je data kan spreiden over meerdere Amazon datacenters wereldwijd. Als er dan 1 datacenter uitvalt dat je door kan gaan via de andere?

edit:

Amazon EC2 provides the ability to place instances in multiple locations. Amazon EC2 locations are composed of Regions and Availability Zones.

bron: http://aws.amazon.com/ec2/#highlights

[Reactie gewijzigd door Arnold op 25 juli 2024 06:50]

[Hoover]

Behalve als de storing in software zit bijvoorbeeld.

Stel dat je een Vmware vsphere omgeving hebt waar alles redundant is.
En een virtueele windows bak geeft een bluescreen, dan kun je alles nog zo veel redundant hebben uitgevoerd, maar je server ligt nog steeds plat....

[Jogai]

dan moet je ook zorgen dat je een redundant virtueel windows bakje hebt...

[MindStorm]

Die heeft dan dezelfde bluescreen

[Anoniem: 151857]

hoeft niet, want het kan ook geconfigureerd zijn als een failover cluster. Als dan de cluster software doorheeft dat 1 node(aka server) niet goed functioneert dan zal de clustersoftware deze node afschieten en de andere node opdracht geven om de desbetreffende services te starten.

De servers kunnen de zelfde dienst starten omdat de data van de dienst op het SAN (Storage Area Network) staat. Mocht de SAN het begeven waardoor het hele cluster onderuit flikkert, dan zou je dat kunnen af vangen met een redundant SAN en bijv <schaamteloze reclame> Novell Business Continuity Cluster</schaamteloze reclame> die een heel cluster clusterd zeg maar . (IBM MS en anderen zullen vast en zeker ook zo'n soort oplossing hebben maar dat weet ik allemaal niet).

@Hoover:
je hebt gelijk, maar dat kun je ook afvangen door stukken software als bijv (sorry again) Novell Cloud Manager, waarbij je de VM inhoudelijk kun inspecteren en als je ziet dat daar wat mis gaat een andere VM starten die dezelfde dienst start en/of overneemt. (wederom: MS, IBM anderen zullen vast ook een oplossing hebben die dit kan).

edit:
ontopic:
Wel pijnlijke situatie hoor voor Amazon. Weet iemand misschien of dit eerder is gebeurt?

edit2: servers moest services zijn

[Reactie gewijzigd door Anoniem: 151857 op 25 juli 2024 06:50]

[coolmos]

Reddit ligt er redelijk regelmatig uit, en een van de ex-admins (ketralnis) heeft recentelijk duidelijk gemaakt dat een groot deel van de problemen bij Amazon ligt.

Ze zijn daar al aan het kijken naar alternatieven.

Als je kijkt naar de uptime die Amazon zelf aangeeft onderaan de pagina dan wordt wel duidelijk dat ze de cijfers wat mooier presenteren dan werkelijk waargemaakt wordt.

[Hoover]

Maar wat als je het dieper kijkt.
Kijk een service kan crashen en er zijn genoeg manieren om dit redundant te krijgen.
Maar wat als je app of admin/user een screwup maakt?

Wat men moet doen is:

Hardware failover - OS failover - Database/application failover - database/application return point in time - backup.

Iemand kan ergens een vinkje aangepast hebben waardoor alles onderuit valt.
Dan kun je nog zulke mooie technieken hebben.. dat vinkke blijft aangepast totdat met dat terug draait.

[Hoover]

I know. Daarom gaf ik dit als voorbeeld.
Had er bij moeten zetten dat failover niet alleen in hardware zit, maar ook in software.

Ik werk veel met Vmware, SQL clusters/mirrors e.d. ,maar men vergeet altijd dat een bitje die omgevallen is, met redundant hardware systemen en ook software nog steeds omgevallen is.

Daarom doe ik bijvoorbeeld met SQL altijd een Mirror bouwen met daarnaast een apparte server waar logshipping of een ander mechanisme op draait.

Dit omdat wanneer er een database corrupt raakt en de mirror deze actie klakkeloos heeft overgenomen, ik altijd nog terug kan naar een vorige situatie van bijvoorbeeld 10 minuten eerder.
dus alleen je windows redundant uitvoeren is niet volledig.

[Anoniem: 140398]

Heb je je data mooi redundant staan, valy het redundancybeheerssysteem uit, waardoor je er niet bij kan

[Sijmen]

Het probleem is hier dan in US-East er meerdere availability zones offline zijn, iets dat eigelijk nooit zou moeten gebeuren.

[YDh]

Naast de opmerkingen van de anderen is het ook zo dat je bij een basisafname van de dienst geen geografische replicatie van data krijgt. Dat is een optie die extra kost en waarvoor bedrijven dan ook vaak niet kiezen.

[YopY]

Pijnlijk, en het geeft ook wel aan dat Amazon terug naar de tekentafel mag - een clouddienst moet juist altijd beschikbaar kunnen zijn (tenzij het internet overal uitvalt).

Sterker nog, er zijn zelfs testtools beschikbaar voor cloudapplicaties die volledig at random servers eruittrekt, om de redundantie en dergelijke te testen. Dit zou uitgebreid moeten worden met tests die gehele datacentra eruittrekken.

[YDh]

Ik kan uit de omschrijving van de storing niet afleiden of het hier om een storing in het geheel gaat of om een storing in 1 datacenter. Indien dit laatste het geval is, is het natuurlijk ook voor een groot stuk de schuld van de klanten die niet bereid waren om de extra kosten te betalen om hun diensten in meerdere datacenters te hosten. Dit laatste is een feature die velen er niet bij nemen.

[Wizz15]

Dit is een storing in Noord-Virginia. Californie, Europa en anderen zijn gewoon online. Het is puur 1 datacenter wat problemen heeft.

Wij waren helaas ook getroffen, maar zijn plannen aan het maken om failovers in andere continenten te kunnen starten. Gebruikers die hierop berekend waren door hun instances te spreiden hebben dus eigenlijk niet zoveel last gehad. Enkel gebruikers met instances in een enkel datacenter zijn zwaar de pineut.

[Sorcerer8472]

Dit is hét tricky gedeelte van cloud computing: de software moet perfect werken, maar dit is weer een voorbeeld van waar dat niet zo blijkt te zijn.

En gaat het mis en raken bijvoorbeeld servers overbelast door foute loadbalancing en heen-en-weer pingpong-effecten, dan heb je ook gelijk een groot probleem wat je misschien niet zo makkelijk oplost, mede door de grote complexiteit van de software.

Daarnaast heb je nog eens concurrency-effecten waar je mee te maken hebt bij 'social sites' zoals reddit. Lijkt me ook lastig voor EC2 om mee om te gaan.

Maargoed, misschien haalt dit ook het (deels dus onterechte) 'het draait op een cloud dus het gaat nooit down'-gevoel weg. Zelfde geldt trouwens voor alle virtuele omgevingen: softwarefout kan grote gevolgen hebben; grotere gevolgen dan in een degelijk ingerichte traditionele omgeving waar rekening is gehouden met failover.

[Longbeard]

De initiële problemen zijn verergerd door de automatische processen van de EBS cloud. Geautomatiseerde processen begonnen met het 'remirroring' van een groot aantal van EBS volumes. Dit domino-effect zorgde voor een aanzienlijk degradatie van de EBS (en dus RDS) prestaties en beschikbaarheid.

Today’s EC2 / EBS Outage: Lessons learned
The cause of the outage appears to have been a case of so-called ‘auto-immune disease’. Amazon’s automated processes began remirroring a large number of EBS volumes, which had a knock on effect of significantly degrading EBS (and thus RDS) performance and availability across multiple availability zones.

[ColdRain]

Tijd voor next big thing: http://www.unhosted.org/

[Gé Brander]

Hahahaha, dat meen je toch niet?

On the unhosted web, data is stored per-user, under the user's control. That's where it belongs.

Moet ik hier nog woorden aan vuil gaan maken? Data van een bedrijf is van het bedrijf, en niet van afzonderlijke user's. Het zou toch wat zijn dat als de persoon weggaat, de data van die persoon, die eigenlijk van het bedrijf is, niet meer door het bedrijf te benaderen zou zijn...

[SunnieNL]

dat klopt dan toch nog steeds? Data van een bedrijf sla je op bij het bedrijf.. niet in de cloud van een ander bedrijf.

Maargoed, ben het er ook verder niet mee eens. Cloud kan best handig zijn voor sommige zaken

[totaalgeenhard]

Ik vraag me af hoe de marketeers die al een tijdje cloud lopen te hypen dit goed gaan praten.

Uitbesteden van oplossingen is accepteren dat je een probleem niet zelf meer kunt oplossen.

Uitbesteden aan een groot bedrijf aan de andere kant van de oceaan is accepteren dat je een nietszeggende klant-nummer bent in een groter geheel.

Ik hoop dat er nu eens wat ogen open gaan, want cloud is een gevaarlijke hype.

[Anoniem: 47200]

Ik hoop dat er nu eens wat ogen open gaan, want cloud is een gevaarlijke hype.

Nou nou, dat gaat ook wel wat hard. Dingen die niet critical zijn kun je best in een cloud hosten die aan de andere kant van de oceaan staat. Als je core business echter een website is dan wordt het lastig .

[resma]

Het blijft gewoon een kostenafweging...

Als je op dagbasis tienduizend euro schade lijdt voor downtijd en de kosten voor halvering van de risico reductie zijn op jaarbasis een ton, dan is de keus vaak snel gemaakt.

Voor een kleiner bedrijf is het gebruiken van clouddiensten vaak een methode om tegen beheersbare kosten een (vrij) hoge mate van redundantie te verkrijgen. Dat e.e.a. geen garanties biedt blijkt nu pijnlijk duidelijk.

Amazon praat overigens over 99,95% availability per regio. Dat zijn dus 4,38 uur uitval per jaar. Dat gaan ze dus dit jaar niet waarmaken...

[Elmo_nl]

Hoe vervelend ik het ook vind voor de klanten, dit bewijst maar weer eens waarom ik denk dat de cloud zo geweldig nog niet is. Nog erger zou zijn, en die dag komt echt ooit nog, dat de data van een bedrijf door een beveiligingsfout, configuratiefout etc op straat komt te liggen of toegankelijk is voor onbevoegden. Ik ben benieuwd wat dit gaat doen met het imago van cloud computing.

[Arnold]

Dit heeft weinig met de cloud te maken, maar meer met fouten van Amazon die de redundancy blijkbaar niet goed op orde hebben (wat juist een voordeel hoort te zijn van de cloud!). Als je een fysieke server plaatst in een datacenter ben je even goed offline bij een storing in het netwerk daar (of je eigen server).

[SunnieNL]

Een storing in het netwerk daar zou bij redundantie niet direct offline mogen betekenen.
Gescheiden switches, gescheiden routers, gescheiden isp's die ook nog eens op verschillende punten het gebouw binnen komen en waarvan je eist dat de kabels nergens naast elkaar lopen (dus niet ergens langs dezelfde hop lopen), daarmee vang je een heel groot gedeelte van alle problemen die op netwerkniveau kunnen voorkomen op.

Uiteraard moet je dan ook goede firmware upgrade procedures volgen etc. Anders heb je er nog niets aan....

[Sypher]

Hopelijk leert men hiervan:

• Neem je diensten niet af bij één partij
• Neem je diensten niet af op 1 locatie (availability zone)
• Zorg voor redundantie

Leuk zo'n cloud, maar dat wil niet zeggen dat het niet down kan. En als die down gaat.. zit je met de gebakken peren.

[YopY]

Redundantie behoort hét voordeel van het opslaan in een clouddienst te zijn, en als afnemer verwacht je dat dit altijd het geval is. Dit soort zaken bij twee partijen hosten (dubbele redundantie) kost gewoon heel veel geld. Sowieso zul je ook altijd een verbinding tussen de twee partijen moeten hebben om de enorme hoeveelheden data synchroon te houden.

[Gé Brander]

Assumptions are the mother of all fuckups... Nooit verwachten dat. Zorg dat je weet hoe het geregeld is en weet wat je krijgt voor hetgeen je betaald.
Als je je niet wilt verdiepen in hetgeen je afneemt, moet je niet daarna zeuren dat iets eruit ligt.

[Xubby]

Risico's geen dienst bij cloud:
- internet provider heeft storing
- netwerkkabel (ergens op de planeet) stuk
- cloud provider service onderuit
- cloud provider data "kapot"

Extra risico's t.o.v. program op eigen pc. Dat ook nadelen heeft, uiteraard.

[Cergorach]

Maar zit je dan met meer gebakken peren dan dat je zelf ergens iets host? Dan ben je namelijk ook geheel afhankelijk van de hosting partij. De voordelen van cloud diensten zoals die van Amazon is (de optie voor) redundantie, geen enorme upfront kosten, geen beheer van de servers, snelle/makkelijke scaling en snelle startup tijd. Er kan altijd ergens iets mis gaan, alleen is de kans dat er iets misgaat bij 'zelfbouw' groter dan dat bij enorme diensten zoals Amazon/Google/Microsoft.

[Henkie-Jan]

Ik dacht altijd dat 'de cloud' altijd up and running bleef? Dat is toch eens van de grote voordelen van 'de cloud'? Is dit dan niet gewoon een ordinair serverpark?

offtopic:
het is blijkbaar gaan regenen of onweren of zow :-P

[Reactie gewijzigd door Henkie-Jan op 25 juli 2024 06:50]

[DarkKnight]

Off-topic: Nee, het is te zonnig. Dus zijn er te weinig clouds in the sky om de dienst draaiende te houden.

Maar goed, dit is wel een erg pijnlijk situatie. Al begrijp ik niet helemaal waarom er uberhaupt zoiets kan gebeuren als er alleen connectiviteitsproblemen zijn naar één serverpark. Dan is er natuurlijk ook nog de vraag waarom die problemen er zijn, naast dus het feit dat redundantie faalt.

[ultimasnake]

Ook al staat je dienst in een cloud, het blijven ordinaire serverparken . Alleen de manier waarop (veelal) software matig wordt gewerkt is anders dan je '1 applicatie 1 server' opstelling.

[ctrl-tab]

Is dit dan niet gewoon een ordinair serverpark?

Antwoord: JA (ongeveer)