Megsült tárolók miatt hasalt el az Azure
Masszív, egy napot is meghaladó leállást okozott egy vihar a Microsoft Azure szolgáltatásában. A vállalat most publikálta az ok-okozatot feltáró post mortem jelentését.
"Az incidens nagy energiájú villámlásokkal és viharokkal kezdődött, amelyek Dél-Texas környékén csaptak le, a South Central US adatközpontjai mellett." - mondja a Microsoft. Ez a helyi villamos hálózaton jelentős feszültségfluktuációt eredményezett, ennek következtében az egyik adatközpont egy része automatikusan levált a hálózatról és generátorra állt át.
Az igazi problémát a hűtőrendszer leállása okozta, amely a védelem ellenére túláramot kapott és lekapcsolt. Erre az esetre felkészülve az adatközpont rendelkezik bizonyos hőpufferrel, vagyis bizonyos ideig tudta tartani a biztonságos működési hőmérsékletet, ez lehetőséget biztosít, hogy bizonyos hőmérsékleti küszöbértéket meghaladva a rendszer rendezett leállást tudjon eszközölni. Ebben az esetben azonban a puffer annyira gyorsan fogyott el, hogy nem volt idő a leállást végrehajtani. Ennek következtében "jelentős számú" tárolószerver károsodott, kis számú hálózati egységgel és tápegységgel együtt. A Microsoft beszámolója szerint a helyszíni üzemeltető csapat több lépést is tett a károk megakadályozására, például a teljes adatközpontot generátorra állították át.
Visszaállítás - nehéz döntésekkel
A visszaállás során először az Azure SLB-k (Software Load Balancer) egységeket állították vissza, ezek felelnek a platform és a felhasználók forgalmának irányításáért is, emiatt az Azure platform kritikus elemeinek számítanak. A következő lépés a tárolószervereket érintette - ez viszont fájdalmas választás elé állította az üzemeltetőket. Az egyik megoldás a failover egy másik adatközpontra, ez viszont némi adatvesztéssel jár, a georeplikáció aszinkron volta miatt. Emiatt az a döntés született, hogy a károsodott adatközpont álljon újra fel, ami jóval több időt vett igénybe, de adatvesztéssel nem járt. A leállás hosszúságát itt a károsodott szerverek nagy száma és az adatvisszatöltés-adatvalidáció indokolta - az ügyféladatokat végül sikerült hibátlanul visszaállítani.
Machine recruiting: nem biztos, hogy szeretni fogod Az AI visszafordíthatatlanul beépült a toborzás folyamatába.
A Microsoft közlése szerint a leállás szeptember 4-én 9:29 (UTC) és szeptember 5 11:00 (UTC) között (tehát több, mint egy napon át) tartott, az utóbbi időpontra a South Central US régió legtöbb szolgáltatása elindult, de a teljes szolgáltatáshalmaz csak szeptember 7 8:40-re (UTC) állt helyre.
A leállás sok Azure szolgáltatást érintett, amelynek hatása ráadásul a régiótól nagyon messze is érezhető volt. Az egyik különösen érintett a Microsoft fejlesztői platformja és ezen belül a Visual Studio Team Services (VSTS), amely (nyilván) leállt azon szervezetek számára, amelyek itt tárolták adataikat. De ez a régió bizonyos alap szolgáltatásokat nyújtott más régiók számára is, ezek kiesésével lassulások, a VSTS Dashboard funkcionalitásának hibái jöttek elő, illetve az érintett régióban tárolt profiladatok elérhetetlenné váltak. A legcifrább, hogy a VSTS státuszoldala, amelyen követni lehetett a szolgáltatás minőségét, nem tudott frissülni, mivel az ehhez szükséges adatok és az állapotfrissítéshez szükséges eszközök az érintett adatközpontban futottak.
A Microsoft fejlesztői divíziója ezért saját postmortemet írt, amelyben külön magyarázzák a nem túl díszes bizonyítványt. A bejegyzés szerint a failovert szintén az adatvesztés elkerülése magyarázta (nyilván összefüggésben a fent említettekkel), viszont belemegy érdekes részletekbe. Eszerint a cég adatbiztonsági stratégiája előírja, hogy az adatokat két régióban tárolja, az Azure SQL DB Point-in-time Restore (PITR) backup és Azure Geo-redundant Storage segítségével., amely folyamatos adatreplikációt eredményez. Ez azonban komoly fejtörést okozott: a backupok read-only módban érhetőek el, a failover elérhetővé tette volna az adatokat, írást azonban nem, vagyis a legtöbb VSTS-funkció így sem működött volna. Ráadásként a fent már említett adatvesztés problémája is fennáll, az aszimmetrikus adatreplikáció késleltetéssel dolgozik, ami azt jelenti, hogy a közvetlenül a leállás előtt kiírt adatok elvesztek volna.
AZ lesz a megoldás
A Microsoft szerint a fent említett replikációs problémára az Availability Zones (AZ) bevezetése lesz a megoldás. Az AZ-t elérhető szolgáltatásként idén márciusban indította el a cég, pont erre a célra, olyan magas rendelkezésre állást nyújtó megoldás, amely különböző (de azonos régióban található) helyszínek között biztosít gyors átállást. Ezek a helyszínek teljesen függetlenek egymástól villamos energia, hűtés és hálózat szempontjából is, így pont erre a fenti problémára immúnisak. Az AZ lényege, hogy szinkron replikációt használ, amit az adatközpontok közötti nagyon magas sávszélességű, alacsony késleltetésű hálózat tesz lehetővé.
A közeljövőben ezt a technológiát fogja a cég a VSTS (illetve immár Azure DevOps) alatt is használni, így a következő leálláshoz már sokkal-sokkal nagyobb természeti csapás, egy teljes régió adatközpontjainak kiesése kellene. Ezt kiegészítendő a Microsoft vizsgálja a régiók közötti szinkron replikáció lehetőségét is, ami garantálná, hogy még ebben az extrém esetben is fennmaradna a szolgáltatás. Szintén opció az aszinkron replikáció régiók között, bizonyos korlátozások feloldása mellett, például a read-only backupok írhatóvá tételével.
További részletek a VSTS blogon és az Azure Status History oldalán (archivált verzió).