Bil

Amazon avslöjar orsaken till förra veckans stora AWS-avbrott

Utlösaren för tjÀnstavbrottet var ett litet kapacitetstillskott till Amazon Kinesis, men problemet snöade dÀrifrÄn.

Bild: Getty Images/iStockphoto

Förra veckans enorma AWS-avbrott som knĂ€ckte en mĂ€ngd Internet of Things (IoT)-enheter och onlinetjĂ€nster orsakades av ett problem med en Amazon-tjĂ€nst som heter Kinesis. Med uppgiften att samla in och analysera strömmande data i realtid pĂ„ AWS, hickade Kenesis efter att Amazon började lĂ€gga till en liten kapacitet till den. Även om det pĂ„verkade ett brett utbud av enheter och tjĂ€nster, intrĂ€ffade störningen specifikt vid AWS-anlĂ€ggningen i Amazons norra Virginia, US-East-1, region.

SER: Hantera multimolnet (ZDNet/TechRepublic specialfunktion) | Ladda ner den kostnadsfria PDF-versionen (TechRepublic)

Moln: MÄste lÀsa tÀckning

I sin lĂ„nga och komplexa förklaring hĂ€nvisade Amazon till det lilla tillskottet av kapacitet till Kinesis som utlösaren men inte grundorsaken till problemet. Företaget beskrev sökvĂ€gen som anvĂ€ndes för denna tjĂ€nst och sa att Kinesis anvĂ€nder en rad “back-end” cellkluster som bearbetar strömmar.

Dessa strömmar sprids över baksidan genom en skĂ€rningsmekanism som Ă€gs av en “front-end”-flotta av servrar. FrontĂ€ndens jobb Ă€r att hantera autentisering, strypning och förfrĂ„gningsdirigering till rĂ€tt strömskĂ€rvor pĂ„ back-end-klustren. Den extra kapaciteten gjordes till denna front-end-flotta.

Varje server i front-end-flottan cachar viss data, inklusive medlemsinformation och shard-Àgande för back-end-klustren. Varje front-end-server skapar operativsystemtrÄdar för var och en av de andra servrarna i front-end-flottan. NÀr ny kapacitet lÀggs till tar de servrar som redan ingÄr i flottan sÄ lÄng tid som en timme att lÀra sig om eventuella nya deltagare.

De första varningsklockorna ringde klockan 5:15 PT dagen före Thanksgiving den 25 november, vilket indikerar fel med Kinesis-posterna. Den nya kapaciteten var troligen misstÀnkt för felen, vilket fick Amazon att börja ta bort den men samtidigt undersöka andra potentiella orsaker.

Vid 09:39 PST hade Amazon spikat sin boven och upptÀckt att den nya kapaciteten hade fÄtt alla servrar i flottan att överskrida det maximala antalet trÄdar som tillÄts av en operativsystemkonfiguration. Eftersom denna grÀns fortsatte att överskridas, fortsatte cachekonstruktionen att misslyckas, och sÄ kunde front-end-servrarna inte dirigera förfrÄgningar till back-end-kluster.

För att lösa problemet startade Amazons ingenjörer om front-end-servrarna efter att den extra kapaciteten som startade kollapsen togs bort. Den första gruppen servrar lades till klockan 10:07 PST. DÀrifrÄn lade Amazon lÄngsamt till servrar, bara nÄgra hundra per timme. NÀr trafiken gradvis lades till började felfrekvensen sjunka stadigt, vilket lÀmnade Kinesis helt uppe och ÄterstÀllde som normalt kl. 22:23 PST.

Som med alla typer av serviceavbrott finns det lÀrdomar och korrigeringar som mÄste göras. Amazon ber om ursÀkt för pÄverkan pÄ sina AWS-kunder och beskrev flera ÄtgÀrder för att sÀkerstÀlla att den hÀr typen av hÀndelser inte kommer att hÀnda igen.

Först kommer företaget att flytta Kinesis till större CPU- och minnesservrar för att minska det totala antalet servrar som krÀvs. För det andra sa företaget att det lÀgger till finkornig alarm för trÄdförbrukning i tjÀnsten. För det tredje planerar Amazon att öka grÀnserna för antal trÄdar nÀr de nödvÀndiga testerna Àr klara. För det fjÀrde gör företaget Àndringar för att förbÀttra kallstartstiden för front-end-flottan, som att flytta front-end-servercachen till en dedikerad flotta och flytta stora AWS-tjÀnster som CloudWatch till en separat front-end-flotta.

Att varna kunderna om problemet var ocksÄ en uppgift som inte gick sÄ bra.

“Utöver serviceproblemen upplevde vi vissa förseningar i att kommunicera servicestatus till kunder under den tidiga delen av detta evenemang,” sa Amazon och pĂ„pekade att man anvĂ€nder sin Service Health Dashboard för att uppmĂ€rksamma kunder om breda driftsproblem och sin Personal Health Dashboard att kommunicera direkt med berörda kunder.

I den hĂ€r typen av hĂ€ndelser gör Amazon vanligtvis inlĂ€gg pĂ„ sin Service Health Dashboard. Det hĂ€r verktyget kunde dock inte uppdateras pĂ„ vanligt sĂ€tt eftersom det anvĂ€nder en tjĂ€nst som heter Cognito, som sjĂ€lv pĂ„verkades av avbrottet. Även om företaget anvĂ€nde en manuell sĂ€kerhetskopieringsmetod för att uppdatera den hĂ€r instrumentpanelen, försenades uppdateringarna eftersom Amazons supporttekniker inte var tillrĂ€ckligt bekanta med detta verktyg.

“Framöver har vi Ă€ndrat vĂ„r supportutbildning för att sĂ€kerstĂ€lla att vĂ„ra supporttekniker regelbundet utbildas i sĂ€kerhetskopieringsverktyget för att skicka inlĂ€gg till Service Health Dashboard,” tillade Amazon.

Eftersom fler organisationer och individer förlitar sig pÄ molnet för att anvÀnda viktiga enheter och tjÀnster, pÄverkar en hÀndelse som denna oundvikligen ett vÀxande antal mÀnniskor. AWS-kunder Àr sÀrskilt mottagliga eftersom Amazons molnprodukt Àr bland de mest populÀra och vanligaste. Detta innebÀr att organisationer mÄste förbereda sig för onlinestörningar precis som de skulle förbereda sig för problem med tjÀnster pÄ plats. Och det krÀver en korrekt dataskydds- och ÄterstÀllningsplan för att sÀkerstÀlla att ditt eget företag inte lider nÀr problem uppstÄr i molnet.

BotĂłn volver arriba

Annonsblockerare upptÀckt

Du mÄste ta bort AD BLOCKER för att fortsÀtta anvÀnda vÄr webbplats TACK