Ezért állt az Amazon felhője
Egy egyszerű elírás miatt állt le a héten az Amazon egyik legfontosabb régiójában a tárolós alrendszer. A kiesés tömör történetét és a levont konklúziókat most közölte a cég.
Egy tévesen megadott paraméter rántotta magával a héten az Amazon felhős szolgáltatásának egy jelentős részét - közölte a cég posztmortem-jelentése. Eszerint a leállás helyi idő szerint 9:37 perckor kezdődött és egészen 13:54-ig tartott, ekkor sikerült a szolgáltatást teljesen helyreállítani. A kiesés alatt az AWS egyik kritikus eleme, az S3 tárolórendszer vált elérhetetlenné az egyik legfontosabb, US-EAST-1 régióban.
A kiesésre egy normális karbantartási feladat nyomán került sor, az S3-as tárolószolgáltatást üzemeltető csapat épp a számlázási rendszer lassúságának okát kutatta, eközben adott ki az egyik üzemeltető egy parancsot, amelynek ki kellett volna vonnia néhány szervert az S3-at alkotó egyik alrendszerből. Azonban elírás miatt jóval nagyobb számú szervert húzott ki a szolgáltatás alól, ezzel két kritikus alrendszer kapacitása is a szükséges minimum alá esett. Az egyik ilyen alrendszer az indexelésért felel, kezeli a tárolók metaadatait és számon tartja, hogy melyik adat pontosan hol található, működése kritikus a GET, LIST, PUT és DELETE parancsok végrehajtásához. A második alrendszer, az elhelyezésért felelős egység az új tárolókapacitás kiosztását végzi és működésének feltétele az indexelés.
Ünnepi mix a bértranszparenciától a kódoló vezetőkig Négy IT karrierrel kapcsolatos, érdekes témát csomagoltunk a karácsonyfa alá.
Az Amazon közlése szerint a szerverek eltávolításával mindkét alrendszer működésképtelenné vált és teljes újraindítás vált szükségessé. Eközben a fent említett S3-as parancsok végrehajtása leállt, de vele együtt leálltak régión belül az AWS azon funkciói is, amelyek szintén az S3-asra épülnek - például az új virtuális gépek felpörgetése, az S3 konzol, az Amazon Elastic Block Store vagy az AWS Lambda.
Már önmagában a hiba (és annak hatása) is váratlanul érte az üzemeltetőket, de váratlanul hosszúra nyúlt a helyreállítás, a két említett rendszer újraindulása is. A két fent említett alrendszert ugyanis évek óta nem indították újra, az S3 gyors ütemű növekedésével pedig tárolt metaadatok integritásának ellenőrzése látványosan megnyúlt. A két rendszer közül először az indexelés állt fel, 12:26-ra kezdte el kiszolgálni a beérkező parancsokat, 13:18-ra pedig teljesértékűvé vált a szolgáltatás. Ekkor indították be az üzemeltetők a második alrendszert is, ez végül 13:54-re nyerte vissza rendeltetésszerű működését, így sorban a többi S3-as (és arra épülő) szolgáltatás is elindulhatott.
Tanulni belőle
"Az esemény nyomán néhány változást eszközölünk" - mondja az Amazon. A kapacitást újraosztása alapvető funkcionalitás, de az ezt végző eszköz az adott esetben túl nagy kapacitást vont el túl gyorsan. Az eszköz módosított változata lassabban dolgozik majd, és biztonsági korlátot is kap, így az egyes alrendszereket nem zsugoríthatja a működéshez elengedhetetlen minimum szint alá. Ezzel együtt az Amazon a többi üzemeltetői eszközt is auditálja és ellenőrzi, hogy mindenik rendelkezik ilyen biztonsági korlátokkal, így egy elírt paraméter nem okozhat majd leállást.
A leállás másik tanulsága, hogy a kiesést okozó hiba elhárítása után az S3 túl lassan állt fel újra. Ugyan az S3-at alkotó alrendszereket a fejlesztőcsapatok folyamatosan egyre kisebb darabokra particionálják, pont a gyorsabb indulás érdekében, az indexelést végző alrendszer mégsem teljesített jól. Ennek újraírása egyébként tervben volt 2017-re, a fejlesztők ezt most magasabb prioritással kezelik és azonnal munkához látnak.
Végezetül az AWS Service Health Dashboard (SHD) is módosul: ez a felület mutatja a felhős rendszer bizonyos kimaradásait, kisebb-nagyobb problémáit, így értelemszerűen ez volt hivatott informálni az AWS-felhasználókat a fenti kimaradásról is. Azonban ez a szolgáltatás is az S3-as tárolón alapszik, annak kiesésével pedig az AWS üzemeltetői sem tudták frissíteni az információkat - maradt így a Twitter és az SHD-re kitett kis szöveges banner. A jövőben ez a függőség megszűnik, az SHD-t ezután több régióból is ki tudja az AWS szolgálni, így egy régió kiesése nem húzza majd magával.