10月20日の朝、ロンドンにあるGoogleのeurope-west2-bゾーンで商用電源が失われた際、無停電電源装置 (UPS) の蓄電池は設計どおり約5分間にわたって負荷を支えました。しかし、発電機に起動指令が届くことはありませんでした。Googleは11月4日に更新版のインシデントレポートを公開し、翌日にThe Registerがこれを報じました。データホールの停電は1時間を大きく超え、ゾーン内のGoogleのクラウドサービスの大半が正常に戻るまでには6時間強を要しました。
片系のフィーダーで運転していた2N構成のサイト
Googleの説明によると、このサイトの受電は2N構成で、互いに独立した2系統のフィーダーAとB、キャンパス全体を手動で切り替えるための予備の商用電源接続、そして二重化されたPLCで制御される中央の高圧発電機群を備えています。しかし実際には片系だけで運転していました。10月14日に実施した四半期ごとの発電機負荷試験で不具合が見つかり、修理のためにフィーダーBの遮断器が開放され、フィーダーAが重要負荷のすべてを担っていたのです。
太平洋時間10月19日22時53分、ロンドン時間では6時53分に電力会社の地中ケーブルが故障し、フィーダーAが停止しました。ここで制御系がサイトを裏切ります。Googleによると、PLCの不足電圧検出入力はフィーダー遮断器の電源側に配線されていました。フィーダーBは遮断器で開放されていたものの、その上流はまだ充電されていたため、同一のロジックで動く2台のPLCはいずれも正常な電圧を検出し、健全な商用電源が使える状態だと判断しました。ロジックは電圧と併せて遮断器の開閉状態を確認しておらず、起動指令は出されませんでした。
現場の担当者はPLCを介した遠隔での負荷切替を試みましたが、フィーダーBの同じ充電状態の読み取り値のためにPLCはこれを受け付けませんでした。次に負荷を予備の商用電源接続へ移しましたが、切替の途中で蓄電池が尽きました。データホールへの給電が回復したのは太平洋時間0時20分で、発電機の自動制御装置をリセットして試験した後のことでした。
約40の製品と復旧の遅いディスク
Compute Engineの仮想マシンから、ゾーンディスク、高可用性構成でないデータベースに至るまで、europe-west2-bのゾーンリソースはアクセスできなくなりました。一部のリージョンサービスは正常にフェイルオーバーせず、ストレージは正常でないシャットダウンの後、復旧に長い時間を要しました。Googleの更新情報では、同リージョンの約40の製品が影響を受けたとされています。The Registerによると、Lloyds、HSBC、Royal Mail、Revolutなどの顧客でサービスが中断しました。
Googleが設備側の対策として挙げる内容は具体的です。PLCは10月20日と26日に設定が変更され、同じ日に発電機の自動起動を伴う全負荷切替試験が実施されました。PLCベンダーとのコードレビュー、同様のサイトの点検、両フィーダーが復帰した状態での再試験は11月に予定されています。使用中の商用電源を失った場合の緊急手順は書き直され、現在は各シフトで2回訓練が行われています。同じ構成のサイトでの計画保守は凍結され、今後は各設備の引き渡し後、四半期以内にGoogleの別チームがPLCのコードをレビューすることになっています。
誰も工程表に書かない試験
レポートにエンジンを問題視する記述はありません。発電設備はそこにあり、運転の指令を受けると実際に運転しました。機能しなかったのは起動を指示する一連の仕組みであり、しかもサイトが保守作業のためにたまたま置かれていた状態でのことでした。多くの受入試験では、他のすべてを通常の状態にしたまま受電を開放します。片方のフィーダーを切り離した状態、遮断器を引き出した状態、切替方式を手動にしたままの状態で同じ試験を繰り返すことは少ないのですが、多くのサイトは保守期間のかなりの部分をまさにそうした状態で過ごしています。試運転計画に加える価値のある問いがあります。各検出点はどの遮断器のどちら側にあるのか、そしてその遮断器が開いているとき、制御装置はどう判断するのか、という問いです。
もう一つの教訓は時間です。蓄電池の5分間では、一度も訓練したことのない手動の回避策を試す余裕はなく、Googleが各シフトで2回の訓練を課したこと自体がそれを物語っています。こうしたサイトの発電機側についてはデータセンターのページで説明しています。バックアップに対するまったく異なる考え方は、発電機を置かないMicrosoftのアトランタのサイトで取り上げました。
