Awarie w usługach chmury obliczeniowej także się̨ zdarzają̨

13 października 2021 roku około godziny 8:30 polskiego czasu miała miejsce jedna z poważniejszych awarii usług chmury obliczeniowej firmy Microsoft w ostatnich latach. Postanowiłem opisać ten przypadek jako przestrogę.

Użytkownicy maszyn wirtualnych pracujących pod kontrolą microsoftowych systemów operacyjnych, którzy poprzedniego dnia wyłączyli swoje urządzenia, następnego ranka nie mogli ich uruchomić. Nie dało się również stworzyć nowych maszyn. Problem nie dotyczył  narzędzi z systemami Linux oraz tych, które pracowały bez przerwy.

Platforma raportowała o problemach ze starem i tworzeniem maszyn wirtualnych, wyświetlając poniższy komunikat:

Po kilkudziesięciu minutach na stronie http://status.azure.com pojawiła się informacja o wykryciu błędu na platformie Microsoft Azure i rozpoczęciu prac dążących do zminimalizowania zasięgu awarii oraz jej rozwiązania.

Mijały godziny, a sytuacja nadal nie ulegała poprawie. Po pewnym czasie powiedziano, że przyczyną awarii są problemy z migracją klasycznych zasobów do usługi Azure Resource Manager. Jak się później okazało, o godzinie 8:27 dostarczono używany podczas wykonywania migracji szablon ARM. Narzędzie dostarczające szablon nie uwzględniło pewnych warunków,  w około 80% przypadków powodując kłopoty z rozszerzeniem Windows VM Agent. W rezultacie po otrzymaniu zerowych wyników z regionalnych repozytoriów obrazów platformy operacje zarządzania maszynami wirtualnymi zaczęły kończyć się niepowodzeniem. Działania związane z zarządzaniem usługami  – uruchamianie, zatrzymywanie, tworzenie, usuwanie itp. –  na klientach z maszyną windowsową nie były w stanie zlokalizować rozszerzenia Windows VMAgent, a zatem nie mogły zakończyć się pomyślnie.

Maszyny wirtualne z systemem Windows korzystają z rozszerzenia Windows Virtual Machine Agent (VM Agent), które służy do zarządzania interakcjami między maszyną a usługą Azure Fabric.

Jak Microsoft zareagował na te wydarzenia? Po ustaleniu pochodzenia problemu i sprawdzeniu dostępnych opcji łagodzenia skutków awarii udało się najpierw upublicznić rozszerzenie w jednym regionie. Po weryfikacji zaczęto wprowadzać zmianę w kolejnych. Inżynierowie monitorowali wskaźnik sukcesu platformy dla operacji po zakończeniu zmian.

Po naprawie awarii podjęto decyzję o wstrzymaniu migracji maszyn wirtualnych pracujących pod kontrolą systemów Linux do czasu przeprowadzenia wszelkich napraw i testów. Mają zostać opracowane dodatkowe systemy testów i kontroli.

Jak widać, awarie zdarzają się nawet u najlepszych. I jak tu nie wierzyć w pechową trzynastkę ;).