Onderwerp: Megastoring Amazon EC2 door menselijke fout

Door een beheerblunder implodeerde een deel van Amazon EC2. Wat volgde was een dagenlange 're-mirroring storm' die de Amazoncloud teisterde. Klanten krijgen compensatie.

De enorme storing die de cloudcomputingdiensten van Amazon vorige week trof, is veroorzaakt door een fout uitgevoerde upgrade.

Tijdens een opschalingsoperatie in het datacenter in Virginia werd het verkeer per ongeluk omgeleid naar een reserverouter in plaats van de primaire router van Elastic Block Store (EBS), de opslagmodules die horen bij de Elastic Compute Cloud (EC2) van Amazon. Dat staat te lezen in het bijzonder gedetailleerde ‘post-mortem’ verslag dat Amazon eindelijk heeft vrijgegeven.
Interne DoS-aanval

De redundante router had echter veel minder capaciteit en crashte door deze interne DoS-aanval. En omdat de primaire router niet gebruikt werd, raakten veel EBS-nodes volledig geïsoleerd. De nodes zijn zo geprogrammeerd dat als ze contact verliezen met hun mirror, ze automatisch een nieuwe mirror gaan aanmaken.

Het gevolg was dat alle nog beschikbare opslag in een mum van tijd was bezet, waarna de nodes, op zoek naar vrije opslag, in een paniekaanval raakten. Hierdoor schoot de hele EBS beheerinterface in de stress, waardoor ook EBS API's van andere zogenaamde Availability Zones binnen de regio faalden. Ook een andere dienst, Amazon Relational Database Service (RDS) werd getroffen.
Servers bijprikken

Technici van Amazon waren vervolgens dagen bezig om al deze cloudbrandjes te blussen. Zo is het bedrijf als een gek fysiek servers gaan verplaatsen en installeren om de 're-mirroring storm' van EBS-nodes te kunnen luwen.

Amazon biedt zijn excuses aan en belooft maatregelen. Het upgradeproces zal verder worden geautomatiseerd, zodat er minder ruimte is voor menselijk falen. Ook erkent het concern dat de communicatie tijdens de storing beter kon. Alle klanten die instances en volumes hadden in de getroffen Zone, ook al hadden ze geen downtime, krijgen krediet voor 10 dagen.
Naïeve klanten

Het is duidelijk dat Amazon hard heeft gefaald. Maar dat veel klanten dagenlang plat lagen, is gedeeltelijk ook hun eigen schuld. Anderen, die zelf een doordachte architectuur hebben voor hun applicaties in de cloud, hadden namelijk geen last en bleven online.

Ligt het nu aan mij of moeten ze die beheerder maar gelijk de laan uitschoppen? Dit is wel een heel duur foutje.

Oorspronkelijk geplaatst door Jimmy1987

Ligt het nu aan mij of moeten ze die beheerder maar gelijk de laan uitschoppen? Dit is wel een heel duur foutje.

Iedereen maakt fouten, om hem direct te ontslaan vindt ik wel een beetje ver gaan.

Maar wat ik niet snap van een bedrijf als amazon is dat ze hun redundante setup niet gelijkwaardig uitvoeren, wie komt er nu op het idee om backup routers met minder capaciteit neer te zetten. Dat is volgens mij al om problemen vragen, dat is net zoals zeggen laten we even een 512MB vps als backup nemen voor een dedicated quad core met 16GB ram en hopen dat hij het aan kan.

Ontslaan gaat waarschijnlijk wat te ver ja, maar ik denk dat deze persoon toch wel tot de orde geroepen is Verder heb je natuurlijk gelijk wat betreft hun setup.

(over Amazon outage, met als oorzaak een beheerdersfout tijdens een upgrade)

Oorspronkelijk geplaatst door Jimmy1987

Ligt het nu aan mij of moeten ze die beheerder maar gelijk de laan uitschoppen? Dit is wel een heel duur foutje.

De gevolgen zijn inderdaad groot, maar of de fout ook groot en heel erg verwijtbaar is, is niet op te maken uit deze samenvatting.
Als hij zich op een heel simpele manier vertypt heeft tijdens normaal geplanned onderhoud, lijkt ontslag me vooral een zondebok en "cover your ass" geval in plaats van een terechte sanctie;
In dat geval moet je toch stellen dat het design/tools/procedures zodanig zouden moeten zijn dat een enkele en 'normale' fout niet een dergelijke impact mag hebben.

Als het echter meer een geval is van iemand die bewust uit eigenwijsheid/arrogantie/zelfoverschatting zo'n fout maakt ('navragen bij derde lijn - rot op, doe ik zelf wel ff, dan kan ik snel naar huis' ofzo) dan is ontslag natuurlijk volkomen terecht.

De motivatie van collega's gaat er meestal ook niet op vooruit bij een verkeerde sanctie (dwz, wanneer een goede collega zondebok gemaakt wordt voor iets wat iedereen had kunnen overkomen, danwel wanneer de eigenwijze %$#% prutser door wie het hele team er slecht op staat gewoon mag blijven).

De "voor dummies" samenvatting die gepost is leest als "hoe dom kun je zijn" (backup router zonder voldoende capaciteit).
In de volledige post mortem die Amazon gepost heeft kun je lezen dat het niet zo simpel lag. http://aws.amazon.com/message/65648/
Er was wel een (goede)backup router met voldoende capaciteit, maar ook een ander backup netwerk met minder capaciteit. Door een foutje (gok: typo bij omzetten van gateway adres) werd het verkeer daarheen gestuurd.
Die fout werd blijkbaar redelijk snel gecorrigeerd, maar toen begon een heel grote storm van servers die dachten te moeten re-mirroren nadat ze een tijdje geisoleerd geweest waren.
De post-morten leest wat mij betreft niet als ontslag grond, maar als een behoorlijk onverwacht gevolg van een situatie die niet voorzien was en ontstond door een kleine fout.

Lees inderdaad eerst even het volledige verslag, daaruit kan je opmaken dat het geen issue was met een te lichte router, maar een lichter netwerk (wat normaal niet gebruikt wordt voor die hoeveelheid verkeer (alle verkeer), normaal enkel voor replicatie-verkeer), dat by-design lichter was, en met een goede reden.

Een menselijke fout, tenzij het opzettelijk was, zou ook nooit tot ontslag mogen leiden (ik vermoed dat dat zelfs geen reden tot ontslag kan zijn in België, geen idee voor Nederland). De regels in de US zijn natuurlijk iets anders. Lessen trekken en procedures aanpassen is de juiste reflex.

Oorspronkelijk geplaatst door wonko

Lees inderdaad eerst even het volledige verslag, daaruit kan je opmaken dat het geen issue was met een te lichte router, maar een lichter netwerk (wat normaal niet gebruikt wordt voor die hoeveelheid verkeer (alle verkeer), normaal enkel voor replicatie-verkeer), dat by-design lichter was, en met een goede reden.

Dan nog vraag ik me af hoe je dat verkeer (alle verkeer dus) op dat netwerk kunt krijgen, er zijn volgens mij genoeg technieken voor handen om dat juist te voorkomen. Al dan niet door gewoon het netwerk volledig onafhankelijk te zetten. Het gaat er mij gewoon om hoe zo iets klein zulke grote gevolgen kan hebben, lijkt me eerder iets in de zin van laten we het opzetten en niet eerst even testen voor we het lanceren. Als een kleine provider zo een fout maakt wordt hij direct afgestraft, maar blijkbaar is amazon een uitzondering en kan die er wel mee weg komen. Net zoals het op klanten steken en zeggen ze hadden zelf maar hun setup wat redundanter moeten maken, ik zou zelf ook niet inzien waarom ik dat zou moeten doen als het bedrijf waar ik het afneem mij 99,999% uptime belooft. Tenzij je zelf natuurlijk 100% uptime wenst voor jezelf en je klanten, maar vergeet niet dat het grootste deel van de amzon klanten ook maar gewoon/simpele mensen/bedrijven zijn en geen multinationals zoals netflix.

Dat het niet had mogen gebeuren, en dat het vreemd is dat het gebeurd is, zullen ze bij Amazon ook wel weten.

Het netwerk dubbel uitrollen op dezelfde apparatuur lijkt me niet zo vreemd. Om het even simpel te stellen neem ik aan dat er doorheen een DC of cluster er wel twee switches per rack zitten, elk voor een netwerk, maar dat deze intern wel ergens samenkomen in core-switches. Het is niet zo moeilijk om met fout verkeer een netwerk plat te krijgen, denk maar aan alle ARP-verkeer dat ontstaat als je een heleboel foutieve IP's daarnaartoe gaat routeren. Opeens heb je voldoende broadcast verkeer...

Ik vind het persoonlijk goed. De kleine spelers gaan wel nu eens twee keer nadenken als "de cloud" bij een verre partij de oplossing is wat ze nodig hebben. Een telefoontje kunnen plegen en zekerheid hebben dat er ook naar hun machine gekeken wordt ipv stilletjes zitten hopen dat het ooit wel weer goed komt, dat zal nu wel hoger op hun lijstje komen.

De groten der aarde (foursquare, netflix,...) moeten zelf hun conclusies trekken. 99.999 wil niet zeggen dat het nooit down gaat gaan, en dat je zelf niet moet investeren in noodscenario's. Blijkbaar iets teveel vertrouwen in "de cloud". Als enkel al de data gerepliceerd was naar een twee zone, en als hun deployment en provisioning geautomatiseerd zou zijn, zouden ze binnen de kortste keren terug online kunnen zijn. Gewoon even een andere zone aanduiden waar hun cluster online gebracht moet worden, en op "deploy" drukken (ok, zal wel niet zo eenvoudig zijn, maar toch...).

Merk trouwens op dat hosting-klanten hondstrouw zijn. Je moet al flink je best doen om een klant echt kwijt te raken. Al bij al gaat er niets gebeuren, voorspel ik.

Oorspronkelijk geplaatst door The-BosS

Dan nog vraag ik me af hoe je dat verkeer (alle verkeer dus) op dat netwerk kunt krijgen, er zijn volgens mij genoeg technieken voor handen om dat juist te voorkomen. Al dan niet door gewoon het netwerk volledig onafhankelijk te zetten. Het gaat er mij gewoon om hoe zo iets klein zulke grote gevolgen kan hebben, lijkt me eerder iets in de zin van laten we het opzetten en niet eerst even testen voor we het lanceren. Als een kleine provider zo een fout maakt wordt hij direct afgestraft, maar blijkbaar is amazon een uitzondering en kan die er wel mee weg komen. Net zoals het op klanten steken en zeggen ze hadden zelf maar hun setup wat redundanter moeten maken, ik zou zelf ook niet inzien waarom ik dat zou moeten doen als het bedrijf waar ik het afneem mij 99,999% uptime belooft. Tenzij je zelf natuurlijk 100% uptime wenst voor jezelf en je klanten, maar vergeet niet dat het grootste deel van de amzon klanten ook maar gewoon/simpele mensen/bedrijven zijn en geen multinationals zoals netflix.

Ik moet een beetje speculeren, maar ik meen uit het volledige verslag op te maken dat er wel degelijk connectiviteit moest zijn tussen het kleinere netwerk en het grotere netwerk.
Voorkomen dat er verkeer loopt is dan niet simpel mogelijk.
Alleen de volledige stroom verkeer hoefde en moest er nooit opkomen, en toen dat wel gebeurde raakte het kleinere netwerk overbelast.
(hoe ? ik gok dus op het intypen van een verkeerd gateway adres; twee goede (prim/sec van het grote netwerk), en ook een paar ongeschikte)
Dat is óók nog geen ramp, alleen de automatische reactie van teveel servers om dit verlies van connectiviteit als reden voor een re-mirror te zien werd een cascade.

Overigens lees ik in de storingspagina's hier nu bepaald niet het "meteen afstraffen van kleine providers", ook dan zie je mensen na dagen outage alleen maar 'denken' aan overstappen.

En omdat de primaire router niet gebruikt werd, raakten veel EBS-nodes volledig geïsoleerd. De nodes zijn zo geprogrammeerd dat als ze contact verliezen met hun mirror, ze automatisch een nieuwe mirror gaan aanmaken.

Dat is een probleem dat ik bij veel van die HA oplossingen zie.
Teveel geautomatiseerd en juist te weinig menselijke controle.

Er hoeft bij wijze van spreken maar een kabel stuk te gaan, en beide systemen denken dat de ander down is, en nemen zelfstandig actie.

Oorspronkelijk geplaatst door wonko

Een menselijke fout, tenzij het opzettelijk was, zou ook nooit tot ontslag mogen leiden (ik vermoed dat dat zelfs geen reden tot ontslag kan zijn in België, geen idee voor Nederland)

Daar is in Nederland nu ook een discussie over.
Mag je een brugwachter wel of niet vervolgen als er zware ongelukken gebeuren door het drukken op een verkeerde knop?
Of is de werkgever (overheid) daar ook niet een beetje aansprakelijk voor...

http://www.depers.nl/binnenland/5632...okbruggen.html

Oorspronkelijk geplaatst door wonko

De groten der aarde (foursquare, netflix,...) moeten zelf hun conclusies trekken. 99.999 wil niet zeggen dat het nooit down gaat gaan, en dat je zelf niet moet investeren in noodscenario's. Blijkbaar iets teveel vertrouwen in "de cloud".

Even een correctie, Netflix heeft het juist goed gedaan en had hier al op geanticipeerd. Netflix is dus gewoon up gebleven tijdens de outage.

Some Background
Why were some websites impacted while others were not? For Netflix, the short answer is that our systems are designed explicitly for these sorts of failures. When we re-designed for the cloud this Amazon failure was exactly the sort of issue that we wanted to be resilient to. Our architecture avoids using EBS as our main data storage service, and the SimpleDB, S3 and Cassandra services that we do depend upon were not affected by the outage.

Leest de rest van de interessante post op http://techblog.netflix.com/2011/04/...ws-outage.html

Ik ben benieuwd wat voor impact dit heeft op de reputatie van cloud hosting. Kent iemand nog meer voorbeelden van situaties waarin een cloud zo hard op z`n gat ging?