Penutup The Azure Outage Post-Mortem Bagian 3

Posting blog saya sebelumnya, Azure Outage Post-Mortem – Bagian 1 dan Azure Outage Post-Mortem Bagian 2, membuat beberapa asumsi berdasarkan informasi terbatas yang berasal dari posting blog dan twitter. Saya baru saja menghadiri sesi di Ignite yang memberikan sedikit lebih banyak kejelasan tentang apa yang sebenarnya terjadi. Suatu saat besok Anda harus dapat melihat sesi untuk diri sendiri. BRK3075 – Mempersiapkan yang tak terduga: Anatomi pemadaman Azure Analisis Root Cause resmi akan segera diterbitkan. Sementara itu, berikut beberapa informasi yang dikumpulkan dari sesi.

Penyebab

Dari kematian pos pemadaman biru, pemadaman itu TIDAK disebabkan oleh sambaran petir seperti yang dilaporkan sebelumnya. Sebaliknya, karena sifat dari badai, ada badai listrik melorot dan membengkak. Akibatnya, tanaman chiller terkunci di pusat ^data pertama. Selama pemadaman pertama ini, mereka dapat memulihkan chiller dengan cepat tanpa dampak yang nyata. Tak lama kemudian, ada pemadaman kedua di pusat data kedua yang tidak pulih dengan benar. Itu memulai serangkaian peristiwa yang tidak menguntungkan.

2 Habis

Selama pemadaman ini, Microsoft menyatakan bahwa “Insinyur tidak melakukan triase peringatan dengan benar – pemulihan pabrik chiller tidak diprioritaskan”. Ada banyak peringatan yang dipicu saat ini. Sayangnya chiller sedang offline tidak menerima prioritas yang seharusnya. RCA tentang mengapa itu terjadi masih diselidiki. Microsoft menyatakan bahwa tentu saja sistem chiller redundan sudah tersedia. Namun, sistem pendingin tidak diatur ke failover otomatis. Baru-baru ini dipasang peralatan baru belum sepenuhnya diuji. Jadi itu diatur ke mode manual sampai pengujian telah selesai. Setelah 45 menit, pendinginan ambien gagal, shutdown perangkat keras, penangan udara mati karena mereka mengira ada kebakaran. Staf telah dievakuasi karena alarm kebakaran palsu. Selama ini suhu di pusat data semakin meningkat. Beberapa perangkat keras tidak dimatikan dengan benar, menyebabkan kerusakan pada beberapa penyimpanan dan jaringan. Setelah secara manual mengatur ulang chiller dan membuka penangan udara, suhu mulai kembali normal. Butuh sekitar 3 jam dan 29 menit sebelum mereka memiliki gambaran lengkap tentang status datacenter. Masalah terbesar adalah kerusakan pada penyimpanan. Perhatian utama Microsoft adalah perlindungan data. Microsoft akan bekerja untuk memulihkan data untuk memastikan tidak ada kehilangan data. Ini tentu memakan waktu, yang memperpanjang panjang keseluruhan pemadaman. Kabar baiknya adalah tidak ada data pelanggan yang hilang. Kabar buruknya adalah sepertinya butuh 24-48 jam agar semuanya kembali normal. Ini berdasarkan apa yang saya baca di Twitter dari pelanggan yang mengeluh tentang pemadaman berkepanjangan.

Asumsi

Semua orang berharap pemadaman ini akan berdampak pada pelanggan yang dihosting di Wilayah Tengah Selatan. Tapi apa yang mereka tidak harapkan adalah pemadaman itu akan berdampak di luar wilayah itu. Dalam sesi tersebut, Microsoft membahas beberapa jangkauan pemadaman yang diperpanjang.

Azure Service Manager (ASM)

Ini mengontrol sumber daya “Klasik” Azure, AKA, sumber daya pra-ARM. Siapa pun yang mengandalkan ASM bisa terkena dampak. Tidak jelas bagi saya mengapa ini terjadi. Tampaknya Wilayah Tengah Selatan memiliki beberapa komponen penting dari layanan tersebut yang menjadi tidak tersedia.

Visual Studio Team Service (VSTS)

Sekali lagi, tampaknya banyak sumber daya yang mendukung layanan ini di-host di Wilayah Tengah Selatan. Pemutusan ini dijelaskan dengan sangat terperinci oleh Buck Hodges (@tfsbuck), Direktur Teknik, Azure DevOps pos blog ini.

POSTMORTEM: VSTS 4 SEPTEMBER 2018

Azure Active Directory (AAD)

Ketika kawasan Tengah Selatan gagal, AAD melakukan apa yang dirancang untuk jatuh tempo dan mulai mengarahkan permintaan otentikasi ke wilayah lain. Ketika Pantai Timur mulai bangun dan online, lalu lintas otentikasi mulai meningkat. Sekarang biasanya AAD akan menangani peningkatan lalu lintas ini melalui penskalaan otomatis. Tapi autoscaling memiliki ketergantungan pada ASM, yang tentu saja offline. Tanpa kemampuan autoscale, AAD tidak dapat menangani peningkatan permintaan otentikasi. Situasi yang menjengkelkan adalah bug di klien Office yang membuat mereka memiliki logika mencoba-coba yang sangat agresif, dan tidak ada logika backoff. Lalu lintas autentikasi tambahan ini akhirnya membawa AAD ke lututnya. Mereka kehabisan waktu untuk membahas ini lebih lanjut selama sesi Ignite. Satu fitur yang akan mereka perkenalkan akan memberi pengguna kemampuan untuk failover Storage Accounts secara manual di masa depan. Jadi dalam kasus di mana waktu pemulihan obyektif (RTO) lebih penting daripada (RPO), pengguna akan memiliki kemampuan untuk memulihkan penyimpanan geo-redundansi asynchronous direplikasi mereka di pusat data alternatif jika Microsoft mengalami pemadaman panjang lagi di masa depan.

Apa yang Dapat Anda Lakukan Sekarang

Sampai saat itu, Anda harus bergantung pada solusi replikasi lain seperti SIOS DataKeeper Azure Site Recovery. Atau solusi replikasi khusus aplikasi yang memiliki kemampuan untuk mereplikasi data di seluruh wilayah dan menempatkan kemampuan untuk memberlakukan rencana pemulihan bencana Anda dalam kendali Anda. Baca lebih lanjut tentang post mortal emisi azure kami Direproduksi dengan izin dari Clusteringformeremortals.com