Szerző: Gálffy Csaba

2018. szeptember 11. 17:45

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.

En ensom person ler ikke lett. (x)

Ibsent csak eredetiben norvégul, de azért pythonban is vannak irodalmi magasságok. Nézd meg Felméri Péter nyelvi tudatformálását, és minden megvilágosodik!

En ensom person ler ikke lett. (x) Ibsent csak eredetiben norvégul, de azért pythonban is vannak irodalmi magasságok. Nézd meg Felméri Péter nyelvi tudatformálását, és minden megvilágosodik!

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ó).

Október végén 8 alkalmas, 24 órás, online képzéseket indítunk, melyekre most early bird kedvezménnyel jelentkezhetsz. A képzések utólag is visszanézhetők, és munkaidő végén kezdődnek.

a címlapról

roller coaster

3

Profit-hullámvasúton a Samsung

2022. október 6. 14:39

A dél-koreai multit elérte válság szele, három év óta először csökkenhet a cég profitja.