Laporan Akhir Google Cloud tentang Gangguan London: Hanya Satu Bekalan Utiliti Hidup Semasa Penyelenggaraan, dan Pengawal Mengesan Voltan di Hulu Pemutus Litar yang Terbuka, Jadi Penjana Tidak Pernah Menerima Isyarat Mula

Pada 26 Oktober kami melaporkan, berdasarkan laporan awal, gangguan bekalan elektrik yang melumpuhkan zon europe-west2-b Google Cloud di London. Pada 4 November, Google Cloud menyiarkan laporan insiden akhirnya di halaman status, dengan punca yang jauh lebih terperinci berbanding laporan awal. Menurut laporan akhir, kesan utama diselesaikan dalam tempoh 6 jam 8 minit (laporan awal menyebut 6 jam 10 minit).

Punca: Keadaan Penyelenggaraan dan Kedudukan Satu Penderia

• Kemudahan itu menggunakan reka bentuk utiliti 2N: dua bekalan utiliti bebas, A dan B, disokong oleh sekumpulan penjana voltan tinggi yang diurus oleh Pengawal Logik Boleh Atur Cara (PLC) dwi-lewah. Bateri UPS bertahan kira-kira lima minit, cukup untuk PLC mengesan voltan rendah, menghidupkan dan menyegerakkan penjana diesel serta memindahkan beban.
• Ujian beban penjana suku tahunan pada 14 Oktober menemui masalah, dan untuk membaiki bekalan B, pemutus litarnya dibuka, menjadikan kemudahan itu berada dalam keadaan penyelenggaraan sementara satu bekalan (1N) dengan bekalan A menanggung keseluruhan beban kritikal.
• Pada 22:53 waktu Pasifik, 19 Oktober (06:53 BST pada 20 Oktober), bekalan A terputus akibat kerosakan kabel bawah tanah pada rangkaian utiliti di luar kemudahan. Penderiaan voltan rendah PLC disambungkan di hulu pemutus litar bekalan: pemutus bekalan B terbuka, tetapi talian di atasnya masih bertenaga, jadi kedua-dua PLC aktif dan siap sedia, yang menjalankan logik yang sama, melihat "sumber utiliti yang sihat" dan tidak pernah mengarahkan penjana bermula. Apabila pasukan di tapak cuba memindahkan beban dari jauh melalui PLC, bacaan yang sama menghalangnya.
• Menilai bahawa UPS akan kehabisan sebelum operasi jauh dapat dibereskan, pasukan memindahkan kemudahan ke sumber utiliti siap sedia, tetapi bateri habis semasa pemindahan dan dewan data kehilangan bekalan elektrik.

Mengapa Pemulihan Mengambil Masa Enam Jam

• Semua masa dalam BST: kesan bermula pada 07:00; bekalan utiliti siap sedia dipulihkan pada 07:54, dewan data mendapat semula bekalan elektrik pada 08:20, kelompok mula pulih pada 08:40 dan peranti rangkaian kembali pada 08:45.
• Storan ialah bahagian yang perlahan: kehilangan kuasa secara mengejut menyebabkan sejumlah besar peranti storan tertutup secara tidak bersih, yang mula pulih pada 08:50, dan pasukan respons sengaja menangguhkan perkhidmatan yang boleh memburukkan keadaan. Dengan begitu banyak peranti, ini mengambil masa yang lama; storan hanya cukup pulih pada 11:13, dan trafik dimasukkan semula secara beransur-ansur mulai 11:45.
• Perkhidmatan dan API Google Cloud tersedia sepenuhnya pada 12:11 (sesetengah mesin maya GCE masih belum kembali), gangguan teras platform berakhir pada 12:29, pada 13:08 99.5% mesin maya GCE sihat dan mesin baharu boleh dicipta, dan notis penutupan dikeluarkan pada 15:03.
• Dua zon lain turut terjejas: panggilan merentas zon ke zon yang luar talian tamat masa, dan beban yang dialihkan oleh failover memenuhi kapasiti pengkomputeran zon yang tinggal, menyebabkan ralat 500 dan 503 berselang-seli di seluruh rantau.

Pembaikan Google, dan Pengajaran untuk Pelayan Anda Sendiri

Tindakan Google termasuk: PLC dikonfigurasi semula dan disahkan pada 20 Oktober dan sekali lagi pada 26 Oktober, ketika ujian pemindahan penjana dengan beban kritikal penuh turut disiapkan; syarikat utiliti mengenal pasti lokasi kerosakan kabel pada 26 Oktober, menjangka membaiki bekalan A menjelang 13 November, dan menjelang 17 November kemudahan itu sepatutnya kembali menggunakan bekalan A dan B dengan satu lagi ujian beban penjana; dan semakan penuh kod PLC dijadualkan menjelang 6 November. Untuk pelayan kita sendiri, tiga perkara wajar diingat: kelewahan diam-diam menjadi titik kegagalan tunggal semasa penyelenggaraan, kerana ketika satu mesin diselenggara, mesin lain ialah satu-satunya; pemantauan patut menyemak keadaan sebenar, bukan satu isyarat hulu; dan selepas kehilangan kuasa secara mengejut, bahagian yang paling perlahan selalunya pemulihan storan, jadi simpan salinan data anda di tempat lain menggunakan salah satu strategi sandaran ini. Untuk pemikiran di sebalik persediaan berbilang rantau lihat mengapa satu nod tidak mencukupi, dan untuk memilih lokasi lihat memilih nod pusat data berkependaman rendah.