Ezért állt az Azure csütörtökön
Single point of failure került az Azure architektúrájába, ez rántotta magával gyakorlatilag a teljes felhős szolgáltatást múlt csütörtökön. A Microsoft igyekszik tanulni a hibából, redundanciát kap ez a vezérlősík is.
Több órán keresztül állt a Microsoft felhője csütörtökön, szeptember 15-én, a cég időközben a leállás okait is közzétette. A posztmortem bejegyzés szerint magyarországi idő szerint 12:18 körül hirtelen megnövekedett a hálózati forgalom, ezt pedig egy, a hálózati eszközökben található hiba miatt a rendszer nem tudta helyesen lekezelni. Ennek következményeként a rendes DNS-lekérdezéseket a kiszolgáló nem fogadta el, köztük azokat sem, amelyek a belső Azure végpontok azonosítására vonatkoztak.
Ezzel az Azure szolgáltatások több régióban azonnal összeomlottak, hiszen rengeteg szolgáltatás függ a belső névszerverektől és a DNS-lekérések megfelelő feldolgozásától. A hibát a hálózat konfigurációjának megváltoztatásával a Microsoft elhárította, a DNS-lekérések feldolgozása pedig 14:00 körül helyreállt. A leállás szinte az összes Azure szolgáltatást érintette, a listán az Azure SQL Database, a Datawarehouse (DW), a HDInsight, az App Service - Web Apps, a Service Bus, a Redis Cache, az Azure Backup, a Visual Studio Team Services, az Azure RemoteApp, az Azure Media Services, az Azure Search, az Application Insights, az IoT Hub, az Azure Log Analytics, az Azure Automation és a Data Movement volt érintett.
Elestem és nem tudok felállni
Hiába állt helyre viszont a DNS-alrendszer, az Azure SQL Database, és az attól függő szolgáltatások, mint a Datawarehouse, a Media Services és a HDInsight a US Central régióban továbbra is működésképtelenek maradtak. A Microsoft szerint a kiszolgálókra hirtelen rászakadó csatlakozási kérések tömegét az adatbázisok szinte minden régióban kibírták, a US Central azonban megadta magát. A beérkező kérések korlátozásával végül itt is fel tudott állni a szolgáltatás, azonban csak 18:15-re sikerült az Azure SQL Database-t működő állapotba hozni, nem sokkal később pedig a rá épülő szolgáltatások is beindultak.
Nyerd meg az 5 darab, 1000 eurós Craft konferenciajegy egyikét! A kétnapos, nemzetközi fejlesztői konferencia apropójából a HWSW kraftie nyereményjátékot indít.
A Microsoft szerint a kliensek nem sokat tehettek volna az eredeti leállás elkerülése érdekében, az általános szolgáltatáskiesés ellen (geo)redundancia sem védte volna meg a felhőben futó alkalmazásokat. A DNS-alrendszer helyreállítása után azonban már lett volna létjogosultsága egy ilyen megoldásnak, mivel az csak a US Central régiót érintette, így a failover megoldások minimalizálni tudták volna a további leállás hatását.
Okok és következmények
A leállást tehát a Microsoft mérnökei szerint az egyik, az Azure-ban széles körben használt hálózati eszköz szoftverhibája okozta, ami miatt a rendszer nem tudott lekezelni egy terhelési tüskét, ez pedig a DNS-lekérések megtagadásához vezetett. Az Azure architektúrájában pedig ez egy kritikus pont, a rendszerben az egyes elemek ezen keresztül találják meg egymást. Az SQL Server és a Datawarehouse elérése például két DNS-lekérést is tartalmaz - előbb a kapcsolódni kívánó kliens a központi control ringtől megkapja az elsődleges IP-címet, amelyet a belső nyilvántartásban egy másik IP-címhez irányít egy másik lekérdezéssel a rendszer, ez pedig már a megfelelő erőforráshoz irányítja a klienset.
A leállás gyökerének feltérképezése után a Microsoft azokat a kezdeményezéseket is listázza, amelyek a hasonló leállások elkerülését célozzák. Eszerint (értelemszerűen) elsődleges a hálózati eszköz hibájának kijavítása, ez jelenleg validációs fázisban van és hamarosan élesedhet. Ezen felül is van azonban tennivaló az Azure "ütésállóságának" növelésére. Az első körben a riasztás fog gyorsulni, így az üzemeltetők hamarabb felfigyelhetnek a DNS szolgáltatás leállására. További (már implementált) változás, hogy a kliensek hosszabb ideig megjegyzik a már feloldott IP-címeket - mivel a belső nevek és IP-címek egymáshoz rendelése viszonylag stabil, és csak jelentősebb konfigurációváltásnál szokott változni, ennek nem lesz negatív vonzata.
Fontosabb probléma, hogy a központi DNS-kiszolgálással és a központi control ringgel bekerült a rendszerbe egy single point of failure, vagyis egyetlen alrendszer kiesése magával tudja rántani a teljes felhős infrastruktúrát. Ezt felismerve a Microsoft úgy döntött, hogy régiónként a jövőben több control ring lesz majd (aktív/aktív elrendezésben), ami nagyban csökkenti majd a fentihez hasonló leállások esélyét.