Samenvatting van de Amazon EC2 en Amazon RDS storing in de VS East Region

Origineele engelse tekst:
http://aws.amazon.com/message/65648/

Nu we volledig zijn functionaliteit voor alle betrokken diensten hersteld, we zouden graag meer details te delen met onze klanten over de gebeurtenissen die hebben plaatsgevonden met de Amazon Elastic Compute Cloud ("EC2") vorige week, om onze inspanningen te herstellen van de diensten, en wat we doen om dit soort problemen te voorkomen weer. We zijn erg van bewust dat veel van onze klanten aanzienlijk werden beïnvloed door deze gebeurtenis, en zoals met alle belangrijke service issue, onze bedoeling is om het aandeel van de details van wat er gebeurd is en hoe we de service voor onze klanten te verbeteren.

De kwesties die EC2 klanten vorige week de eerste plaats betrekking op een subset van de Amazon Elastic Block Store ("EBS") volumes in een enkele Beschikbaarheid Zone binnen de VS East Region, dat werd niet in staat om service en lezen en schrijven operaties. In dit document, zullen we refereren aan deze als "vast" volumes. Dit veroorzaakte gevallen proberen om deze getroffen volumes gebruiken om ook te krijgen "vast" als ze probeerden te lezen of om ze te schrijven. Om deze volumes te herstellen en stabiliseren van de EBS-cluster in die Beschikbaarheid Zone, wij gehandicapten alle controle-API's (bijv. Volume maken, Volume, Maak Volume en Momentopname maken Bevestig) voor EBS in de getroffen Beschikbaarheid zone voor een groot deel van de duur van de evenement. Voor twee perioden tijdens de eerste dag van de uitgifte, het gedegradeerde EBS cluster van invloed op de EBS API's en veroorzaakt hoge foutenpercentages en latencies voor EBS oproepen naar deze API's in de hele VS-Oosten. Zoals met alle ingewikkelde operationele vraagstuk, werd deze veroorzaakt door verschillende oorzaken interactie met elkaar en daarom geeft ons veel mogelijkheden om de dienst te beschermen tegen soortgelijke gebeurtenis terugkerende.

Overzicht van de EBS-systeem
Het is nuttig om de EBS architectuur, zodat we beter kunnen uitleggen het evenement te begrijpen. EBS is een gedistribueerd, gerepliceerde blok gegevens op te slaan die is geoptimaliseerd voor de samenhang en de lage latency te lezen en de toegang van de EC2-uitbreidingen te schrijven. Er zijn twee belangrijkste onderdelen van het EBS dienst: (i) een reeks van EBS clusters (die elk geheel binnen loopt van een Beschikbaarheid Zone) dat gebruikersgegevens opslaat en verzoeken dienen om EC2 instances, en (ii) een set van control plane diensten die worden gebruikt om verzoeken van gebruikers te coördineren en ze doorgeven aan de EBS-clusters uitgevoerd in elk van de Beschikbaarheid Zones in de regio.

Een EBS cluster bestaat uit een set van EBS knooppunten. Deze knooppunten te slaan replica's van EBS volume data en serveer lezen en schrijven verzoeken om EC2 gevallen. EBS volume gegevens worden gerepliceerd naar meerdere EBS knooppunten voor duurzaamheid en beschikbaarheid. Elke node EBS maakt gebruik van een peer-to-peer gebaseerde, snelle failover strategie die agressief bepalingen nieuwe replica's als een van de exemplaren ooit uit krijgt van sync of niet meer beschikbaar is. De nodes in een cluster EBS zijn met elkaar verbonden via twee netwerken. Het primaire netwerk is een netwerk met hoge bandbreedte gebruikt in de normale werking voor alle noodzakelijke communicatie met andere nodes EBS, met EC2 gevallen, en met de EBS control plane diensten. Het secundaire netwerk, de replicatie-netwerk, is een lagere capaciteit netwerk dat wordt gebruikt als een back-up-netwerk mogelijk te maken EBS nodes om betrouwbaar te communiceren met andere nodes in het cluster en EBS extra capaciteit voor data replicatie bieden. Dit netwerk is niet bedoeld om alle verkeer van het primaire netwerk behandelen, maar wel uiterst betrouwbare verbindingen tussen knooppunten EBS binnenkant van een EBS cluster.

Wanneer een node verbinding met een node waarop het kopiëren van gegevens naar verliest, neemt de andere node is mislukt. Te behouden duurzaamheid, moet het vinden van een nieuwe node waarvan kan repliceren zijn gegevens (dit heet re-mirroring). Als onderdeel van de re-mirroring-proces, de EBS node zoekt haar EBS cluster voor een ander knooppunt met voldoende beschikbare ruimte op de server, stelt de verbinding met de server, en propageert het volume gegevens. In een normaal functionerende cluster, het vinden van een locatie voor het nieuwe replica gebeurt in milliseconden. Terwijl er data wordt opnieuw gespiegeld, alle knooppunten dat kopieën van de gegevens vasthouden van de gegevens tot ze kunnen bevestigen dat een ander knooppunt heeft de eigendom van hun portie. Dit biedt een extra niveau van bescherming tegen de klant verlies van gegevens. Ook wanneer de gegevens op het volume van een klant wordt opnieuw gespiegeld, is toegang tot die gegevens geblokkeerd totdat het systeem heeft een nieuwe primaire (of beschrijfbare) replica. Dit is noodzakelijk voor de consistentie van EBS volume gegevens op grond van alle potentiële faalwijzen. Vanuit het perspectief van een EC2 bijvoorbeeld proberen om I / O te doen op een volume, terwijl dit gebeurt, zal het volume verschijnt "geplakt".

In aanvulling op de EBS clusters, is er een set van control plane diensten die de gebruiker verzoeken accepteert en propageert ze naar de juiste EBS cluster. Er is een set van EBS control plane diensten per EC2 Gewest, maar de controle vliegtuig zelf is zeer verdeeld over de beschikbaarheid Zones in om de beschikbaarheid en fouttolerantie te bieden. Deze control plane diensten ook fungeren als de autoriteit die de EBS clusters als ze kiest primaire replica's voor elk volume in het cluster (voor de samenhang, er moet slechts een enkele primaire replica voor elk volume op elk moment). Terwijl er een paar verschillende diensten die de control plane omvatten, zullen we gezamenlijk naar te verwijzen als de "EBS control plane" in dit document.

Primaire Stroomonderbreking
Om 12:47 AM PDT op 21 april, was een netwerk te veranderen uitgevoerd als onderdeel van onze normale AWS schaalvergroting activiteiten in een enkele Beschikbaarheid Zone in de VS-Oosten. De configuratie te wijzigen was de capaciteit van de primaire netwerk te upgraden. Tijdens de overstap, een van de standaard stappen is om het verkeer shift van een van de redundante routers in de primaire EBS-netwerk om de upgrade te gebeuren. Het verkeer shift is onjuist en in plaats van het routeren van het verkeer naar de andere router op het primaire netwerk uitgevoerd, het verkeer werd omgeleid naar de lagere capaciteit overbodig EBS-netwerk. Voor een deel van de EBS cluster in de getroffen Beschikbaarheid Zone, betekende dit dat zij niet een goed functionerende primaire of secundaire netwerk hebben, omdat het verkeer werd doelbewust verschoven van het primaire netwerk en de secundaire netwerk kan niet omgaan met het verkeer niveau werd ontvangen . Als gevolg daarvan werden veel EBS knooppunten in de getroffen zone Beschikbaarheid volledig geïsoleerd van andere EBS knooppunten in de cluster. In tegenstelling tot een normale netwerk onderbreking, deze verandering verbroken zowel de primaire als secundaire netwerk tegelijkertijd, waardoor de getroffen knooppunten volledig geïsoleerd van elkaar.

Wanneer dit netwerk connectiviteit probleem zich voordeed, een groot aantal van EBS knooppunten in een cluster EBS verloren verbinding met replica's daarvan. Wanneer de verkeerde verlegging van het verkeer terug was gerold en netwerkverbindingen werd gerestaureerd, deze knooppunten snel begon te zoeken van de EBS cluster naar beschikbare ruimte op de server waar ze konden opnieuw spiegel gegevens. Nogmaals, in een normaal functionerende cluster, dit gebeurt in milliseconden. In dit geval, omdat de kwestie getroffen zoals een groot aantal volumes gelijktijdig, de vrije capaciteit van de EBS cluster werd al snel uitgeput, waardoor veel van de knooppunten "vast" in een lus, voortdurend op zoek van het cluster voor de vrije ruimte. Dit leidde al snel tot een "re-mirroring storm", waar een groot aantal volumes effectief waren "geplakt", terwijl de knooppunten doorzocht het cluster voor de opslagruimte nodig had voor zijn nieuwe replica. Op dit punt, ongeveer 13% van de volumes in de getroffen zone Beschikbaarheid werden in deze "vast" staat.

Na de eerste reeks van gebeurtenissen zoals hierboven beschreven, het gedegradeerde EBS cluster had een onmiddellijke impact op de EBS control plane. Wanneer de EBS cluster in de getroffen Beschikbaarheid Zone de re-mirroring storm ingevoerd en uitgeput haar beschikbare capaciteit, de cluster werd niet in staat om service API-aanvragen "volume te creëren". Omdat de EBS control plane (en het zorgen voor volume API in het bijzonder) is geconfigureerd met een lange time-out periode, deze langzame API calls begon een back-up en resulteerde in thread hongersnood in de EBS control plane. De EBS control plane is een regionale pool van beschikbare onderwerpen die zij kan gebruiken om verzoeken service. Wanneer deze discussies volledig werden opgevuld door het grote aantal aanvragen in de wachtrij, de EBS control plane had geen mogelijkheid om API-aanvragen dienst en begon te API-aanvragen voor andere Beschikbaarheid gebieden in deze regio ook mislukken. Om 2:40 AM PDT op 21 april, het team ingezet van een verandering die gehandicapten alle nieuwe aanvragen Deel in de getroffen zone Beschikbaarheid maken, en door 02:50 PDT, latencies en foutenpercentages voor alle andere EBS gerelateerde API's hersteld.

Twee factoren de oorzaak van de situatie in dit cluster EBS verder afgebroken tijdens het eerste deel van het evenement. De eerste plaats de knooppunten niet om nieuwe knooppunten kwam niet terug uit agressief genoeg wanneer ze niet konden ruimte te vinden, maar in plaats daarvan bleef herhaaldelijk zoeken te vinden. Er was ook een race-conditie in de code op de EBS knooppunten die, met een zeer lage waarschijnlijkheid, veroorzaakt hen om te falen als ze gelijktijdig waren een groot aantal verzoeken voor replicatie sluiten. In een normaal functioneert EBS cluster, zou dit probleem leiden tot zeer weinig of geen node crashes, maar tijdens deze re-mirroring storm, de omvang van de verbindingspogingen was extreem hoog, dus het begon triggering dit probleem vaker. Knooppunten begon te mislukken als gevolg van de bug, wat resulteert in meer volumes links hoeft te re-spiegel. Dit creëerde meer "vast" volumes en meer verzoeken toegevoegd aan de re-mirroring storm.

Door 5.30 am PDT, foutenpercentages en latencies opnieuw verhoogd voor EBS API-aanroepen in de hele regio. Wanneer gegevens voor een volume moet opnieuw worden gespiegeld, moet een onderhandeling plaats tussen de EC2 bijvoorbeeld de EBS knooppunten met het volume gegevens, en de EBS control plane (die fungeert als een autoriteit in dit proces), zodat slechts een exemplaar van de gegevens is aangewezen als de primaire replica en erkend door de EC2 bijvoorbeeld als de plaats waar alle toegangen moet worden gezonden. Dit zorgt voor sterke samenhang van de EBS volumes. Naarmate er meer EBS knooppunten verder te mislukken vanwege de race-conditie hierboven beschreven, de omvang van deze onderhandelingen met de EBS control plane toegenomen. Omdat de gegevens niet werd met succes opnieuw gespiegeld, het aantal van deze gesprekken verhoogd als het systeem geprobeerd en nieuwe aanvragen kwam binnen De belasting veroorzaakt een bruine uit de EBS control plane en opnieuw getroffen EBS API's in de hele regio. Op 08:20 PDT, begon het team uitschakelen van alle communicatie tussen de aangetaste EBS cluster in de getroffen Beschikbaarheid Zone en de EBS control plane. Terwijl dit voorkomen alle EBS API-toegang in de getroffen Beschikbaarheid Zone (bespreken we de terugvordering van dit in de volgende paragraaf), andere latencies en foutenpercentages weer normaal voor EBS API's voor de rest van het Gewest.

Een grote meerderheid van de volumes in het gedegradeerde EBS cluster waren nog goed functioneren en de focus was om de cluster te herstellen zonder dat dit invloed meer volumes. Om 11:30 AM PDT, het team ontwikkelde een manier om EBS-servers in het gedegradeerde EBS cluster voorkomen vergeefs contact met andere servers (die wel vrije ruimte niet hebben op dit moment toch) zonder dat de andere essentiële communicatie tussen knooppunten in het cluster. Na deze wijziging is aangebracht, het cluster gestopt vernederende verder en additionele volumes waren niet langer het risico lopen "geplakt". Vóór deze wijziging werd ingezet, de mislukte servers die voortvloeien uit de race condition geresulteerd in een extra 5% van de volumes in de getroffen zone Beschikbaarheid steeds "geplakt". Echter, volumes werden ook langzaam weer mirroring zoals sommige capaciteit beschikbaar was gesteld waardoor bestaande "geplakt" volumes te worden "los te". Het netto resultaat was dat toen deze verandering werd ingezet, de totale "vast" volumes in de getroffen Beschikbaarheid Zone was 13%.

Klanten ook ervaren verhoogde foutenpercentages tot het middaguur PDT op 21 april bij een poging om nieuwe EBS-backed EC2 gevallen Beschikbaarheid andere zones dan het getroffen gebied te starten. Dit gebeurde voor ongeveer 11 uur, vanaf het begin van de storing tot het middaguur PM PDT op 21 april. Behalve voor de periodes van bredere API problemen hierboven beschreven, waren de klanten in staat om EBS-backed EC2 instances te creëren, maar ervoeren significant verhoogde-foutenpercentages en latencies. Nieuwe EBS-backed EC2 lanceert werden beïnvloed door een specifieke API in de EBS-controle vliegtuig dat alleen nodig is voor het vastmaken van nieuwe gevallen van volumes. Aanvankelijk onze alarmerend was niet fijnkorrelig genoeg voor deze EBS control plane API en de lancering fouten werden overschaduwd door de algemene fout van de gedegradeerde EBS cluster. Om 11:30 AM PDT, een wijziging van de EBS control plane vaste deze kwestie en latencies en foutenpercentages voor nieuwe EBS-backed EC2 gevallen daalde snel en keerde terug naar de buurt-normale at Noon PDT.

Herstellende EBS in de getroffen Beschikbaarheid Zone
Door 12:04 CET op 21 april, was de storing bevatte de ene getroffen Beschikbaarheid Zone en het gedegradeerde EBS cluster werd gestabiliseerd. API's waren goed te werken voor alle andere Beschikbaarheid Zones en additionele volumes waren niet langer worden "geplakt". Onze focus verlegd naar de voltooiing van het herstel. Ongeveer 13% van de volumes in de zone Beschikbaarheid bleef "hangen" en de EBS API's werden uitgeschakeld in die ene getroffen Beschikbaarheid Zone. De hoogste prioriteit werd om extra opslagcapaciteit online om de "steken" volumes voldoende ruimte om nieuwe replica's te maken te vinden.

Het team geconfronteerd met twee uitdagingen die vertraging krijgt capaciteit online. Ten eerste, als een knooppunt mislukt, hoeft het EBS cluster niet opnieuw de mislukte node tot alle gegevens replica is met succes opnieuw gespiegeld. Dit is een bewuste keuze, zodat we gegevens kunnen herstellen als er een cluster niet te gedragen zoals ontworpen. Omdat we niet willen opnieuw gebruiken, dit mislukte capaciteit totdat we zeker wisten dat we konden gebruiker volumes herstellen getroffen op de mislukte knooppunten, moest het team een ​​grote hoeveelheid extra nieuwe capaciteit te installeren dat de capaciteit in het cluster te vervangen. Dit vereist het tijdrovende proces van fysieke verplaatsing overtollige server capaciteit uit de hele VS East Region en het installeren van dat de capaciteit in de aangetaste EBS cluster. Ten tweede, als gevolg van de wijzigingen die zijn aangebracht om het knooppunt naar knooppunt communicatie gebruikt worden door collega's te beperken tot nieuwe capaciteit (dat is wat gestabiliseerd het cluster in de stap hierboven beschreven) te vinden, het team had moeite om het nieuwe capaciteit in de cluster. Het team moest voorzichtig wijzigingen in hun onderhandelingen gaskleppen om onderhandelingen aan met de nieuw gebouwde servers plaatsvinden zonder opnieuw overstroomt de oude servers met verzoeken die zij niet konden service. Dit proces duurde langer dan we verwacht als het team had een aantal onderwerpen te navigeren als ze gewerkt rond gehandicapten communicatie. Om ongeveer 02:00 CET op 22 april, het team met succes begonnen met het toevoegen significante hoeveelheden van nieuwe capaciteit en werken via de replicatie achterstand. Volumes werden steeds weer voor de komende negen uur en alle, maar ongeveer 2,2% van de volumes in de getroffen zone werden Beschikbaarheid vóór 12:30 PM PDT hersteld op 22 april. Terwijl de herstelde volumes waren volledig gerepliceerd, niet allemaal meteen werd "unstuck" vanuit het perspectief van de bijgevoegde EC2 gevallen omdat sommige werden geblokkeerd wachten op de EBS-controle vliegtuig naar bereikbaar, zodat ze veilig zouden kunnen opnieuw een verbinding met het tot stand EC2 aanleg en kiest een nieuwe beschrijfbare kopiëren.

Ooit was er voldoende capaciteit toegevoegd aan het cluster, het team gewerkt aan het herstel van EBS control plane API-toegang tot de getroffen Beschikbaarheid Zone en het herstellen van de toegang tot de resterende "geplakt" volumes. Er was een grote achterstand van de staat veranderingen die moesten worden gepropageerd zowel vanuit het gedegradeerde EBS knooppunten aan de EBS control plane en vice versa. Deze inspanning werd geleidelijk gedaan om de gevolgen te voorkomen aan de herstelde volumes en de EBS control plane. Onze eerste pogingen om API-toegang tot de online beïnvloed Beschikbaarheid Zone te brengen gericht op het smoren van de toestand van het zeeoppervlak om te voorkomen dat overweldigend de EBS control plane. We hebben ook begonnen met het bouwen van een afzonderlijk exemplaar van de EBS control plane, die we konden houden verdeeld aan de getroffen Beschikbaarheid Zone om te voorkomen dat gevolgen heeft voor andere Beschikbaarheid zones in de regio, terwijl we verwerkt de achterstand. We snel ontwikkeld gaskleppen dat bleek te grofkorrelige toe te staan ​​het recht verzoeken te passeren en het systeem te stabiliseren. Door de avond van 22 april in de ochtend van 23 april, hebben we gewerkt aan de ontwikkeling van fijnere korrel gaskleppen. Op zaterdag ochtend, hadden we het volbrachte werk op de speciale EBS control plane en de fijnere korrel gaskleppen. De eerste tests van het verkeer tegen de EBS control plane aangetoond vorderingen en kort na 11.30 uur PDT op 23 april begonnen we gestaag de achterstand verwerking. Door 15 uur 35 PDT, zodat we klaar toegang tot de EBS controle vliegtuig naar het verslechterde Beschikbaarheid Zone. Hierdoor kon het merendeel van de resterende volumes, die zaten te wachten op de EBS control plane te helpen die replica zou schrijfbaar te onderhandelen, om nogmaals gebruikt kunnen worden van hun aangesloten instanties. Om 6:15 PM PDT op 23 april, werd API-toegang tot EBS middelen gerestaureerd in de getroffen Beschikbaarheid Zone.

Met de openstelling van de API-toegang in de getroffen Beschikbaarheid Zone werden API nu actief in alle Beschikbaarheid Zones in de regio. Het herstel van de resterende 2,2% van de getroffen volumes vereist een meer handmatig proces te herstellen. Het team had snapshotted deze volumes naar S3 back-ups in het begin van het evenement als een extra voorzorgsmaatregel tegen verlies van gegevens, terwijl het evenement werd ontvouwen. Op dit punt, eindigde het team van ontwikkelen en testen van code om volumes van deze snapshots te herstellen en de verwerking batches begon door de nacht. Om 12.30 uur CET op 24 april, hadden we klaar met de volumes die we wel konden herstellen op deze manier en had hersteld, maar alle 1,04% van de getroffen volumes. Op dit punt, begon het team forensisch op de resterende volumes die had geleden defekt en waarvoor we hadden niet in staat geweest om een ​​foto te maken. Om 3:00 PM PDT, begon het team het herstel van deze. Uiteindelijk kon 0,07% van de volumes in de getroffen Beschikbaarheid Zone niet meer hersteld worden voor klanten in een consistente toestand.

Impact op Amazon Relational Database Service (RDS)
Naast het directe effect van deze EBS probleem gehad op EC2 instances, maar ook invloed gehad op de Relational Database Service ("RDS"). RDS is afhankelijk van EBS voor database en log-opslag, en als gevolg daarvan een deel van de RDS-databases gehost in de primaire getroffen Beschikbaarheid Zone werd ontoegankelijk.

Klanten kunnen ervoor kiezen om actief RDS gevallen in een enkele Beschikbaarheid Zone ("single-AZ") of gerepliceerd over meerdere Beschikbaarheid Zones ("multi-AZ"). Single-AZ database-exemplaren worden blootgesteld aan storingen in een Beschikbaarheid Zone. In dit geval zou een single-AZ database-exemplaar zijn getroffen indien een van de EBS volumes zij zich baseerde op heb "geplakt". In de primaire getroffen Beschikbaarheid Zone, was een hoogtepunt van 45% van de alleenstaande-AZ gevallen beïnvloed met "vast" I / O. Dit was een relatief groter deel van de RDS bevolking dan de overeenkomstige EBS volume bevolking omdat RDS database gevallen gebruik maken van meerdere EBS volumes. Dit verhoogt de totale I / O-capaciteit voor database-workloads onder normale omstandigheden, maar het betekent dat een "vast" I / O op een volume voor een single-AZ database-exemplaar kan het onbruikbaar totdat het volume wordt hersteld. Het percentage van "geplakt" single-AZ database-exemplaren in de getroffen zone Beschikbaarheid gestaag gedaald tijdens het evenement als de EBS terugvordering overgegaan. Het percentage van "geplakt" single-AZ database-exemplaren in de getroffen zone Beschikbaarheid daalde tot 41,0% aan het eind van 24 uur, 23,5% bij 36 uur en 14,6% aan het eind van 48 uur, en de rest herstelde gedurende het hele weekend. Hoewel we bijna alle teruggevorderd van de betrokken databank gevallen, 0,4% van de alleenstaande-AZ database-exemplaren in de getroffen zone Beschikbaarheid had een onderliggende EBS opslag volume dat niet kon worden ingevorderd. Voor deze database-exemplaren, klanten met automatische back-ups ingeschakeld (de standaardinstelling) had de optie om te leiden point-in-time database te herstellen operaties.

RDS multi-AZ implementaties bieden redundantie door synchroon kopiëren van gegevens tussen twee database replica's in verschillende Beschikbaarheid Zones. In het geval van een storing op de primaire replica, is RDS ontworpen om automatisch te detecteren en over de verstoring niet aan de secundaire replica. Van multi-AZ database-exemplaren in de VS East Region, heeft 2,5% niet automatisch failover na het ervaren van "steken" I / O. De primaire oorzaak was dat de snelle opeenvolging van het netwerk van onderbreking (waarvan de primaire van de secundaire gepartitioneerd) en "vast" I / O op de primaire replica van een eerder VN-bug ondervonden geactiveerd. Deze bug verliet de primaire replica in een geïsoleerde staat waar het niet veilig was voor onze controle-instantie om automatisch failover naar de secundaire replica zonder gevaar voor verlies van gegevens, en manuele interventie nodig was. We werken actief aan een oplossing om dit probleem op te lossen.

Het voorkomen van het Evenement
De trigger voor dit evenement is er een netwerk configuratie te veranderen. Zullen we controleren onze veranderingsproces en verhoging van de automatisering om deze fout te voorkomen in de toekomst. Echter, richten we ons op het bouwen van software en diensten aan mislukkingen overleven. Veel van het werk dat zal komen van dit evenement zal zijn om de EBS dienstverlening verder te beschermen in het gezicht van een soortgelijke storing in de toekomst.

We zullen het maken van een aantal wijzigingen in een cluster te voorkomen van het krijgen in een re-mirroring storm in de toekomst. Met extra overcapaciteit, zou het gedegradeerde EBS cluster sneller hebben geabsorbeerd het grote aantal van re-mirroring verzoeken en vermeden de re-mirroring storm. We begrijpen nu het bedrag van de capaciteit die nodig is voor grote evenementen en het herstel zal worden tot wijziging van onze capaciteitsplanning en alarmerende zodat we de extra veiligheid die de capaciteit die nodig is voor grootschalige storingen te dragen. We hebben al onze capaciteit verhoogd buffer aanzienlijk, en verwachten dat de nodige nieuwe capaciteit in plaats in een paar weken hebben. We zullen ook de draagwijdte van onze logica in de EBS-server nodes opnieuw proberen om een ​​cluster te voorkomen van het krijgen in een re-mirroring storm. Wanneer een grote onderbreking optreedt, zal ons opnieuw de logica terug uit agressiever en zich richten op het herstel van connectiviteit met vorige replica's in plaats van nutteloos te zoeken naar nieuwe knooppunten waarmee opnieuw spiegel. We zijn begonnen met werken door deze veranderingen en zijn vol vertrouwen kunnen we de oorzaak van de re-mirroring storm adres door wijziging van deze logica. Ten slotte, hebben wij de bron van de race-conditie die hebben geleid tot EBS node mislukking. We hebben een oplossing en zal testen en te implementeren op onze clusters in de komende paar weken. Deze veranderingen geven ons met drie aparte bescherming tegen het hebben van een herhaling van dit evenement.

Impact op meerdere Beschikbaarheid Zones
EC2 biedt twee zeer belangrijke beschikbaarheid bouwstenen: Regio's en Beschikbaarheid Zones. Door het ontwerp, de regio's zijn volledig gescheiden implementaties van onze infrastructuur. Regio's zijn volledig geïsoleerd van elkaar en bieden de hoogste mate van onafhankelijkheid. Veel gebruikers maken gebruik van meerdere EC2 Regio's tot extreem hoge niveaus van fouttolerantie te bereiken. Echter, als u gegevens wilt verplaatsen tussen de regio's, moet u dit doen via uw toepassingen als we geen gegevens tussen de regio's repliceren van onze gebruikers 'rekening. Je moet ook een aparte set van API's gebruiken om elk Gewest beheren. Regio's bieden gebruikers een krachtige beschikbaarheid bouwblok, maar het vergt een inspanning van de kant van applicatie bouwers om te profiteren van dit isolement. Binnen de regio, bieden wij Beschikbaarheid Zones om gebruikers te helpen gemakkelijk te bouwen fout-tolerante applicaties. Beschikbaarheid Zones zijn fysiek en logisch gescheiden infrastructuur die zijn gebouwd om zeer onafhankelijke terwijl de gebruikers met hoge snelheid, lage latency netwerkconnectiviteit, eenvoudige manieren om gegevens te repliceren, en een consistente set van beheer-API's. Bijvoorbeeld bij het uitvoeren van binnen een regio, hebben gebruikers de mogelijkheid om EBS snapshots die kunnen worden hersteld in een Beschikbaarheid Zone en programmatisch kan manipuleren EC2 en EBS middelen met dezelfde API's te nemen. Bieden wij deze losse koppeling, omdat het gebruikers in staat stelt om gemakkelijk te bouwen zeer fout-tolerante applicaties.

Dit evenement had twee verschillende effecten. Eerst was er een schok aan het uitvoeren van toepassingen in de getroffen zone, omdat Beschikbaarheid getroffen EBS volumes werd "geplakt". Vanwege de architectuur van de EBS dienst, om de impact actieve exemplaren is beperkt tot de getroffen Beschikbaarheid Zone. Als gevolg daarvan veel gebruikers die hun applicaties gebruik te maken van meerdere zones Beschikbaarheid nemen geen significant effect beschikbaarheid als gevolg van dit evenement. Sommige klanten gemeld dat zij "vast" EBS volumes in Beschikbaarheid andere gebieden dan de invloed Beschikbaarheid Zone op donderdag. Terwijl onze controle toont duidelijk het effect van de re-mirroring storm op de EBS-control plane en volumes binnen de getroffen Beschikbaarheid Zone, is het niet weerspiegelen de aanzienlijke impact op de bestaande EBS volumes binnen andere Beschikbaarheid zones in het Gewest. We zien wel dat er iets meer "vast" volumes dan we hadden verwacht in de gezonde Beschikbaarheid Zones, hoewel nog steeds een zeer klein aantal. Om dit in perspectief, de piek "geplakt" volume procenten zagen we in de regio buiten de getroffen Beschikbaarheid Zone was minder dan 0,07%. We onderzochten een aantal van deze "vast" volumes. De iets verhoogde-nummer van "vast" volumes in deze niet-getroffen zones werd veroorzaakt door de vertragingen bij het herstel van de normale re-spiegels als gevolg van de toegenomen latencies en foutenpercentages van de EBS control plane hierboven beschreven, er is altijd een achtergrond-tarief van het volume weer spiegeling aan de hand. Wij geloven ook dat het werk hieronder beschreven verder isoleren van de EBS-controle vliegtuig zal ook deze iets verhoogde-tarief als iets dergelijks gebeurd te voorkomen.

Terwijl gebruikers de toepassingen gebruik te maken van meerdere Beschikbaarheid Zone ("multi-AZ") architecturen in staat waren om de impact van deze gebeurtenis te vermijden, was er zeker een impact op de EBS control plane dat het vermogen te creëren en EBS volumes te manipuleren over de getroffen regio . Een van de voordelen van EC2 is het vermogen om snel te vervangen is mislukt middelen. Wanneer de EBS control plane is afgebroken of niet beschikbaar zijn, het maakte het moeilijk voor de klanten met de betrokken volumes aan hun volumes of EBS-opgestart EC2 gevallen in andere gezonde Beschikbaarheid zones te vervangen. Voorkomen dat dit terugkerende is een topprioriteit.

Ook al hebben we een zekere mate van losse koppeling voor onze klanten, onze design doel is om Beschikbaarheid zones te onderscheiden zijn van volledig onafhankelijk. Onze EBS control plane is zo ontworpen dat gebruikers toegang krijgen tot bronnen in meerdere Beschikbaarheid Zones, terwijl nog steeds toleranter voor fouten in afzonderlijke zones. Dit evenement heeft ons geleerd dat we verder moeten investeringen om dit ontwerp te realiseren maken. Er zijn drie dingen die we zullen doen om een ​​enkele Beschikbaarheid Zone voorkomen dat invloed heeft op de EBS control plane over meerdere Beschikbaarheid Zones. De eerste is dat we onmiddellijk zullen verbeteren van onze time-out logica draad uitputting als een Beschikbaarheid Zone cluster is te lang om te verwerken verzoeken te voorkomen. Dit zou hebben verhinderd dat de API impact van 0:50 CET tot 02:40 CET op 21 april. Het aanpakken van de oorzaak van de tweede API impact, zullen we ook de mogelijkheid toe te voegen voor onze EBS controle vliegtuig naar meer beschikbaarheid Zone op de hoogte te worden en schuur laden intelligent als het voorbij is capaciteit. Dit is vergelijkbaar met andere gaskleppen die we al hebben in onze systemen. Daarnaast zien we ook een kans om meer van onze EBS control plane duwen per EBS Cluster Services. Door het verplaatsen van meer functionaliteit uit de EBS control plane en het creëren van per-EBS cluster implementaties van deze diensten (die in dezelfde beschikbaarheid Zone lopen als de EBS cluster ze steunen), kunnen we nog beter Beschikbaarheid Zone isolement voor de EBS control plane bieden .

Waardoor het makkelijker wordt om te profiteren van Multiple Zones Beschikbaarheid Take
We willen ook het gemakkelijker maken voor klanten om te profiteren van meerdere Beschikbaarheid Zones. In de eerste plaats bieden wij meerdere Beschikbaarheid Zones voor al onze diensten, waaronder Amazon Virtual Private Cloud ("VPC"). Vandaag, VPC klanten hebben alleen toegang tot een enkele Verkrijgbaar Zone. We zullen het aanpassen van onze routekaart naar VPC klanten toegang te geven tot meerdere Beschikbaarheid zones zo spoedig mogelijk. Dit zal toelaten VPC klanten zeer beschikbare applicaties te bouwen met behulp van meerdere Beschikbaarheid Zones net zoals EC2 klanten niet met behulp van een VPC doen vandaag.

Een verwante bevinding uit dit evenement is dat we behoefte aan een betere baan van het maken van zeer betrouwbare multi-AZ-implementaties gemakkelijk te ontwerpen en te exploiteren doen. Sommige toepassingen van klanten (of kritische onderdelen van de applicatie zoals de database) worden ingezet in slechts een enkele Beschikbaarheid Zone, terwijl anderen hebben gevallen, verspreid over Beschikbaarheid Zones maar heb nog steeds kritisch, single points of failure in een Beschikbaarheid Zone. In gevallen als deze, kunnen de operationele kwesties negatief effect beschikbaarheid van applicaties als een robuuste multi-Beschikbaarheid Zone inzet zou de toepassing te blijven zonder gevolgen. We zullen kijken naar klanten te voorzien van betere hulpmiddelen om multi-AZ toepassingen die het verlies van een hele Beschikbaarheid Zone kan ondersteunen zonder dat dit invloed beschikbaarheid van applicaties te maken. We weten dat we nodig hebben om klanten te helpen ontwerpen hun applicatielogica gebruikelijke design patterns. In dit geval waren sommige klanten serieus beïnvloed, en weer anderen hadden de middelen die werden beïnvloed, maar zag bijna geen invloed op hun aanvragen.

Om nauw samen te werken meer met onze klanten en partners over de beste praktijken voor het architectuuronderwijs in de cloud, zullen we het hosten van een reeks van gratis webinars Vanaf maandag 2 mei. De eerste onderwerpen die we zullen dekken zullen ontwerpen foutbestendige toepassingen, Architectuur voor de Cloud, en Web Hosting Best Practices. We anticiperen op het toevoegen van meer onderwerpen aan de serie de komende weken, en zal blijven om deze te doen op een frequente permanente basis. De webinars over de komende twee weken zal worden gehost meerdere keren per dag om klanten te ondersteunen onze over de hele wereld in verschillende tijdzones. We zullen vernietiging van een aanzienlijk deel van de webinars voor gedetailleerde Q & A. Follow-up gesprekken voor klanten of partners zullen ook worden geregeld. Deze webinars, evenals een reeks van whitepapers over beste praktijken voor het architectuuronderwijs voor de AWS cloud, zijn verkrijgbaar in een nieuwe architectuur Center op de AWS website. We zullen ook blijven om applicaties te leveren extra diensten zoals S3, SimpleDB en multi-AZ RDS hun die presteren multi-AZ-niveau automatisch balanceren zodat meerdere klanten kunnen profiteren van de beschikbaarheid Zones zonder het doen van een van de zware tillen in.

Bespoediging van herstel
We zullen ook investeren in het vergroten van onze zichtbaarheid, controle en automatisering om volumes te herstellen in een EBS cluster. We hebben een aantal operationele instrumenten voor het beheer van een EBS-cluster, maar de fijnkorrelige controle en het smoren van het team gebruikt om de cluster zal direct worden ingebouwd in de EBS knooppunten terug te vorderen. Zullen we ook automatiseren het herstel modellen die we gebruiken voor de verschillende typen van het volume herstel dat we moesten doen. Dit zou ons gered veel tijd in het herstel proces. We zullen ook kijken naar welke veranderingen we kunnen maken om het volume te funcionaliteit tijdens perioden van aangetaste cluster operatie, inclusief het toevoegen van de mogelijkheid om een ​​snapshot te nemen van een "vast" volume. Als klanten deze mogelijkheid had, zouden ze in staat zijn geweest om gemakkelijker hun toepassingen te herstellen in andere Beschikbaarheid zones in het Gewest.

Verbetering van de communicatie en service Gezondheid Hulpmiddelen tijdens operationele problemen
In aanvulling op de technische inzichten en verbeteringen die zullen voortvloeien uit dit evenement, naar we ook vastgesteld verbeteringen die moeten worden gemaakt in communicatie met onze klanten. Wij willen graag onze communicatie vaker voor te komen en meer informatie bevatten. We begrijpen dat tijdens een storing, klanten willen zo veel mogelijk details over wat er gaande is, hoe lang het zal duren om te repareren, en wat we doen dit dat het niet weer gebeurt weet. Het merendeel van de AWS team, met inbegrip van de gehele Senior Leadership Team, was direct betrokken bij de hulp te coördineren, het oplossen van problemen en het evenement op te lossen. Aanvankelijk, onze primaire focus lag op doordenken hoe de operationele problemen voor klanten in plaats van op het identificeren van oorzaken op te lossen. We voelden dat onze inspanningen richten op een oplossing en niet het probleem was het juiste ding om te doen voor onze klanten, en dat het ons geholpen om terug te keren van de diensten en onze klanten voor de gezondheid sneller. We bijgewerkt klanten toen we nieuwe informatie die we ervan overtuigd waren was accuraat en afgezien van speculeren, wetende dat als we eenmaal hadden de diensten terug naar gezondheid, dat zouden we snel de overgang naar het verzamelen van gegevens en analyse fase dat deze post mortem zou rijden.

Dat gezegd hebbende, denken we dat we kunnen verbeteren op dit gebied. Zijn we overgestapt op meer regelmatige updates deel van de weg door dit evenement en van plan om verder te gaan met vergelijkbare frequentie van updates in de toekomst. Daarnaast zijn we al bezig met hoe we onze developer support team medewerkers meer expansief in een gebeurtenis als deze, en organiseren een snelle en zinvolle informatie te verstrekken, terwijl het vermijden van speculatie.

We kunnen ook niet een betere baan van maken het makkelijker voor klanten om te vertellen wanneer hun middelen zijn beïnvloed, en we zijn het ontwikkelen van tools waarmee u te zien via de API's als je gevallen worden aangetast.

Bonificatie voor de getroffen klanten
Voor klanten met een bijgevoegde EBS volume of een lopende RDS database bijvoorbeeld in de getroffen Beschikbaarheid Zone in de VS East Region op het moment van de verstoring, ongeacht of hun middelen en de toepassing werden beïnvloed of niet, we gaan een 10-daagse bieden krediet gelijk is aan 100% van hun gebruik van EBS volumes, EC2 instances en RDS database-exemplaren die actief waren in de getroffen Beschikbaarheid Zone. Deze klanten zullen niet om iets te doen om dit krediet te verkrijgen, want het zal automatisch worden toegepast op hun volgende AWS factuur. Klanten kunnen zien of zij in aanmerking komen voor de bonificatie door in te loggen op hun account AWS Activiteit pagina.

In Conclusie
Laatste, maar zeker niet least, we willen verontschuldigen. Wij weten hoe belangrijk onze diensten zijn activiteiten van onze klanten en we zullen alles wat we kunnen om te leren van dit evenement en het te gebruiken om de verbetering rijden over onze diensten doen. Zoals met alle belangrijke operationele vraagstuk, zullen we vele uren in de komende dagen en weken het verbeteren van ons begrip van de bijzonderheden van de verschillende onderdelen van dit evenement en het bepalen van hoe om veranderingen aan te brengen aan onze diensten en processen te verbeteren.

Met vriendelijke groet,
De AWS Team