Levonta az Azure-kimaradás tanulságait a Microsoft

Összefoglalta a február 29-i Azure-leállás okait és következményeit a Microsoft a szolgáltatás hivatalos blogján. Mint arról korábban beszámoltunk, február utolsó napján számos felhasználó leállást illetve kapacitásproblémákat tapasztalt, az Azure adminisztrációs felülete pedig hosszú időre leállt, így nem volt lehetőség új alkalmazások telepítésére, illetve a régiek módosítására vagy leállítására. A kezdeti problémát a szökőév, pontosabban a február 29-től egy évig hatályos biztonsági tanúsítványok kiadása okozta. A hibás algoritmus ugyanis nemes egyszerűséggel hozzáadott az évszámhoz egyet, így a február 29. éjfél után kiadott egy éves tanúsítványok lejárati dátuma 2013. február 29. lett, amelyet a rendszer nem fogadott el érvényes dátumként.

A vihar előtt

Érdemes azonban előbb röviden áttekinteni az Azure rendszerfelügyeleti elemeinek működését. A felhős szolgáltatás fizikai számítógépeken futó virtuális kiszolgálókat működtet a Microsoft saját adatközpontjaiban. A fizikai szervereket mintegy ezer egységenként fürtökbe szervezik, egy-egy ilyen fürt működéséért a Fabric Controller nevű szoftver felel. A Fabric Controller ellenőrzi az alá tartozó gépek egészségét, a virtuális gépek és a rajtuk futó alkalmazások állapotát is - a feladata például egy szerver meghibásodása esetén az azon futó virtuális gépeket más hardveren újraéleszteni. A rendszer lelkét a virtualizált gépen és a hoszt operációs rendszeren egyaránt futó két agent jelenti, amelyek folyamatosan jelt adnak a szerver, illetve az alkalmazás-virtuális gép megfelelő működéséről. Az agentek közötti kommunikáció titkosítva folyik, ehhez a hoszt operációs rendszer a virtuális gép létrehozásakor tanúsítványt bocsát ki a vendég gép agentje számára. Működő tanúsítvány nélkül tehát meghiúsul az agentek közötti kommunikáció, a rendszer pedig nem tud meggyőződni az újonnan létrehozott virtuális gépek épségéről. Ha a vendég rendszer agentje nem ad életjelet 25 percen belül, akkor azt leállítják és újra létrehozzák.

Az Azure házirendje megkülönbözteti a tiszta VM-eket, amelyeken még nem fut külső kód, csak a Microsoft saját szabványos kódja. Amennyiben az ilyen tiszta VM háromszori létrehozás után sem ad életjelet, a rendszer az alatta lévő hardvert hibásnak bélyegzi, a többi ott futó virtuális gépet is leállítja és újra létrehozza őket egy másik fizikai szerveren. A logika szerint a Microsoft saját kódja elvileg hibátlan, így a virtuális gép létrehozásának kudarca hardverhibát feltételez. Ebben az esetben a többi futó VM-et ki kell menteni és át kell helyezni más fizikai szerverre. A Fabric Controller ezt a szervert úgynevezett Human Investigate, emberi kivizsgálást igénylő státuszba helyezi. Amennyiben a klaszteren belül hardverhibák száma meghalad egy előre beállított küszöböt, a teljes klaszter vészmódba kerül, leállnak a frissítések és a virtuális gépek létrehozása is. A vészüzemmód célja csökkentett működést biztosítani, illetve megállítani a probléma továbbterjedését.

A tanúsítvány kiadására minden olyan esetben sor kerül, amikor új VM jön létre, így új telepítéskor (deployment) és kapacitásbővítéskor (scale out), valamint rendszerfrissítéskor - ilyenkor a működő virtuális gépet leállítja a rendszer és a friss rendszerképből újat hoz létre. Február 29-én az Azure épp egy hosszabb ideje tartó rendszerfrissítés közepén volt, egyes klaszterek már gyakorlatilag végeztek a gépek újraindításával, mások a gördülő folyamat elején voltak.

Beüt a ménkű

A tanúsítványdátumozási hiba éjfél után azonnal aktiválódott, a rendszer által létrehozott új virtuális gépek ettől az időponttól képtelenek voltak a kommunikációra, így azokat a vezérlő rendszer életképtelennek nyilvánította és újra létrehozta. A házirendnek megfelelően a harmadik próbálkozás után a rendszer tömeges hardverhibát jelzett, pontosan 75 perccel éjfél után (5:15 PM PST) pedig elérte a klaszterszintű vészüzemmód státuszt. Az üzemeltető csapat értesítette a fejlesztőket a problémáról, és mintegy másfél óra múlva sikerült is azonosítani a hibát. Erre az időpontra számos alkalmazás egy vagy több virtuális gépe kiesett, a többség azonban alacsonyabb kapacitás mellett tovább üzemelt. Néhány perccel később (6:55 PM PST) a Microsoft úgy döntött, hogy lekapcsolja a szolgáltatás adminisztrációs felületét, ha ugyanis a felhasználók tömegesen manuálisan elkezdik újraindítani virtuális gépeiket, az súlyosbította volna a katasztrófát.

A következő néhány órában elkészült a hibajavítás és annak telepítési terve (10:00 PM PST), valamint gyors ütemben haladt a frissített agentek tesztelése is. A módosított kódot előbb tesztkörnyezetben, majd korlátozott számú éles kiszolgálón is kipróbálták. Az első éles klaszter helyi idő szerint hajnali 2:11 órára átesett a teljes frissítésen és példásan működött, ennek nyomán az Azure többi klasztere is végrehajtotta a frissítést.

A második leállás

Ahogy említettük, a káosz beállta előtt az Azure éppen egy globális szoftverfrissítés közepén tartott, melynek során újabb verziójú vendég és hoszt agentek, illetve új hálózati modul élesedett. A leállások pillanatáig számos klaszter teljesen átesett a frissítésen, ezeket a frissítéssel gyorsan vissza lehetett állítani a munkába. Mintegy hét klaszter azonban a frissítés kezdeti fázisában volt a szoftverhiba bekövetkeztekor, ezeken vegyesen futott az új és a régi szoftver - mindkettő tartalmazta a szökőévhibát. Az üzemeltető csapat úgy döntött, hogy a rendelkezésre álláshoz vezető leggyorsabb út, ha a rendszereket egyelőre visszaállítják az előző verzióra, dátumozó hiba nélkül. Mivel a tesztszervereken megfelelően futott a rendszer, a fokozatos frissítés helyett azonnali, átfogó frissítés mellett döntöttek.

A frissítés azonban súlyos hibát tartalmazott, a régi vendég és hoszt modul mellé a frissített hálózati egységet csomagolták, ami nem volt kompatibilis a többi elemmel, így a frissített rendszerek képtelenek voltak csatlakozni a hálózathoz. Az üzemeltető csapat az eredeti teszteket csupán egyetlen szerveren futtatta le, a virtuális gépek hálózati hozzáférését pedig nem vizsgálták. A frissítés eredményeképp a hét klaszter virtuális gépei elvesztették a hálózati hozzáférést és teljesen elérhetetlenné váltak. A hiba nagyságát fokozta, hogy az Azure saját szolgáltatásai közül az Access Control Service és a Service Bus is ezeken a klasztereken futott, az e szolgáltatásokat használó alkalmazások így működésképtelenné váltak. Mintegy két óra múlva elkészült az új, kompatibilis modulokból álló rendszerkép, amelyet alaposabb tesztelés után telepítettek a klaszterekre.

A számos rendszerképváltás és sorozatos újraindítások nyomán bizonyos rendszerek működésében zavar keletkezett, a szolgáltatás legnagyobb része azonban működőképessé vált. Az üzemeltetők a nap fennmaradó részében a hibás rendszerek manuális hibaelhárításával és validációjával foglalkoztak, március elsején hajnali 2:15-re pedig az utolsó problémát is sikerült elhárítani.

Fontos tanulságok

A leállás számos fontos hiányosságra felhívta a figyelmet a Windows Azure-ral kapcsolatban. Ezek közül kiemelkedik a felhasználókkal történő kommunikáció, amelyre az üzemeltetők egész egyszerűen nem voltak felkészülve. A Dashboardon közzétett információk rendkívül semmitmondóak voltak, sem a hiba természetére, sem az elhárítás várható időpontjára nem tettek utalást, így gyakorlatilag azt az egyetlen üzenetet közvetítették, hogy a Microsoft dolgozik a probléma elhárításán. A helyzetet súlyosbította, hogy az Azure üzemállapotát mutató Dashboard túlterhelés és terheléselosztási hibák miatt csak néha működött, így a pánikba eső felhasználók következő lépésben a telefonvonalakat terhelték túl.

A szolgáltatás üzemeltetői két súlyos hibát is vétettek a tesztelésben, előbb a ma már triviálisnak számító szökőévet hibásan kezelő programozási hiba maradt a rendszerben hosszú éveken keresztül, másrészt sikerült kritikus fontosságú klaszterekre alapvető funkcionalitás nélküli rendszerképet kijuttatni, ami a második leálláshullámot okozta. Az infrastuktúra- és platformszolgáltatásokkal kapcsolatos alapvető elvárás a minden körülmények közötti rendelkezésre állás. Az üzleti modell alapja, hogy hatalmas méretű rendszerek működnek, amelyeket kompetens, jól képzett csapat üzemeltet. Ez az ígéret számít a felhő-alapú víziók legfontosabb elemének, és ezt az ígéretet szegte meg most a Microsoft.

A szoftverház azonban blogposztjában kilépett a nyilvánosság elé és alaposan feltárta a leállás pontos okait és következményeit, és alapvető változásokat ígér a rendszer üzemeltetésében. Ennek megfelelően alaposan átdolgozzák a kommunikációs stratégiát is, de a legfontosabb változás az Azure hibatűrésének maximalizálása lesz. A Fabric Controllerek például tévesen feltételezték, hogy a Microsoft saját kódja hibamentes, így a zavar oka minden kétséget kizáróan csak a hardver lehet. További probléma, hogy az autonóm rendszerek háromszor 25 percig próbálták létrehozni a hibás virtuális gépeket, ezután pedig katasztrofális leállást jeleztek. A Microsoft mind a hiba pontosabb jelzésében, mind az észlelés sebességében javulást ígér.

Ü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á.

A hiba teljes elhárítása rendkívüli mértékben elhúzódott, ami részben annak tudható be, hogy a fejlesztők számára nem álltak rendelkezésre a megfelelő szoftvereszközök - ezeket menet közben, sebtében kellett összerakni. A Microsoft a jövőben befektet majd az ilyen eszközök fejlesztésébe, így a különböző üzemzavarok hatékonyabban elháríthatóak lesznek a jövőben.

A kiesésnek pénzügyi vonzata is van, a Microsoft bejelentése szerint a Service Level Agreementben (SLA) rögzítettekhez képest számottevően magasabb, 33 százalékot írnak jóvá a felhasználók következő havi számláján az érintett szolgáltatások esetén (Windows Azure Compute, Access Control, Service Bus, Caching). A jóváírás automatikusan, a szolgáltatás minden felhasználójának jár, függetlenül az érintettség fokától.