外部の水冷漏れにより、パリの OVH データセンターの Dell EMC VNX アレイがクラッシュし、50,000 以上の Web サイトが 24 時間利用不能になりました。
OVH は世界第 3 位のインターネット ホスティング会社であり、17 か国の 20 のデータ センターに 260,000 台のサーバーを保有し、約 1,800 万の Web アプリケーションをホストしています。
障害は6月29日午後7時頃、OVHのP19データセンターで発生した。ここはOVHが2003年に開設した最初のデータセンターだった。その後、40万台のサーバーを収容できるヨーロッパ最大のグラブリーヌ・データセンターに規模で抜かれた。
OVHは独自の液冷コンセプトを開発し、P19施設で採用しています。このコンセプトでは、冷却剤をサーバーラックやその他のコンポーネントの中心部に循環させ、ラック上部のウォーターブロック型熱交換器に接続されたコンポーネントレベルの熱交換器を介して冷却します。加熱された水は、その後、地下水との熱交換によって冷却されます。この方式により、エアコンの使用を回避し、電力を節約できます。
OVHラック液体冷却
事件記録によると、P19 は地下に機材を保管しており、外気による冷却が困難であったため、水冷式の開発に至った。
OVHはその後、EMCからVNX 5400アレイを複数購入しました。問題のアレイは、3つのシャーシに96台のSSD、15台のローカルディスクシェルフ、そして標準的なアクティブ/アクティブ構成のコントローラーペアで構成されていました。OVHは次のように述べています。「このアーキテクチャは、データのローカル可用性を確保し、データコントローラーとディスクの両方の障害に耐えられるように設計されています。」
それ以来、グラヴリーヌではCephとZFSを用いた非プロプライエタリなコモディティアレイの利用を開発し、プロプライエタリ機器からの移行を進めてきました。パリにある2台のうちの1台である、影響を受けたアレイは、すぐに姿を消しました。2台はデータベースサーバーとして機能し、ホストされているウェブサイトの動的ページのデータ、ユーザー関連情報、そしてブログの場合は記事本文とコメントを提供していました。
事件の概要には次のように記されている。「6月29日木曜日午後6時48分、P19データセンターの3号室で、水冷システムの軟質プラスチックパイプの亀裂により、冷却剤が漏れて液体がシステム内に侵入しました。
2つの専用ストレージベイ（ラック）のうち1つは、この方法で冷却されていませんでしたが、非常に近接していました。このことが直接的な原因となり、電気系統の故障が検出され、ベイが完全にシャットダウンされました。
OVHは、水冷式サーバーと同じ部屋に設置したのは間違いだったと認めている。「判断ミスでした。当社の全拠点と同様に、これらのストレージ施設には最高レベルの保護を施すべきでした。」
欠点の上に欠点
その後、音声警報システムの不具合により危機はさらに深刻化しました。ラック内の液体を検知できるプローブがデータセンター全体に音声メッセージを発信したのです。しかし、多言語対応のためのアップデートが失敗し、技術者が漏洩の警告を受け取ったのは発生から11分後のことでした。
午後6時59分、アレイの再起動を試みた。午後9時25分になっても成功しなかったため、故障したアレイの再起動（プランA）を継続するとともに、バックアップを使用して別のシステムにデータを復元する（プランB）ことを決定した。
プランA
Dell EMCのサポートは午後8時に連絡を受け、最終的にアレイを再起動しましたが、20分後に安全機構が作動して停止しました。そこでOVHの技術者は、ルーベの拠点から3台目のVNX 5400を調達し、電源モジュールとコントローラーを使用して、故障したマシンのディスクドライブをこの新しいシャーシに移設することにしました。
ルーベからのシステムは午前4時30分に到着し、故障したシステムのディスクはすべて午前6時までに移行されました。システムは午前7時に起動しましたが、なんとディスク上のデータには依然としてアクセスできませんでした。午前8時にDell EMCサポートに再度連絡し、オンサイト訪問を手配しました。
プランB
プラン B では毎日のバックアップがリソースとして使用され、OVH は次のように指摘しています。「これは、当社のビジネス復旧プランの一環として実行されるグローバル インフラストラクチャのバックアップであり、お客様が顧客スペースでアクセスできるデータベースのスナップショットではありません。」
データの復元とは、コールドストレージから共有ホスティング技術プラットフォームの空き領域にバックアップデータを移行するだけではありません。本番環境全体を再構築することを意味します。
つまり、データを復元するには、次のことが必要でした。
- 既存のサーバーの空きスペースをP19で探す
- サポート サービスの完全な環境 (データベースを実行する VM、そのオペレーティング システム、特定のパッケージと構成) を移行します。
- 新しいホストインフラストラクチャにデータを移行する
このプロセスは原理的にはテスト済みでしたが、5万ウェブサイト規模のテストは実施されていませんでした。手順がスクリプト化され、翌日の午前3時にソーステンプレートからのVMのクローン作成が開始されました。
午前9時時点で、インスタンスの20%が復旧していました。数時間経過し、「23時40分、（最後の）インスタンスの復旧が完了し、MySQL 5.1インスタンスでホストされていたデータベースをMySQL 5.5で復旧した少数のユーザーを除き、すべてのユーザーがサイトを利用できるようになりました。」
後知恵
影響を受けたアレイの災害復旧手順が不十分であったことは明らかであり、このような状況下では、OVH のテクニカル サポート スタッフは英雄的な仕事をしましたが、そうする必要はなかったはずです。
VNXアレイは間違った部屋に設置されていたにもかかわらず、フェイルオーバー対策は講じられていませんでした。アクティブなDR計画とテストも不十分でした。
影響を受けたユーザーとのコミュニケーションは批判を受け、OVHはこれを受け入れました。「事故の原因、すなわち当社の水冷システムからの冷却剤漏れをめぐる混乱については、誠意をもって謝罪いたします。」
そして私たちは何を学んだのでしょうか?
- ストレージアレイと水を混ぜないでください
- すべての重要なシステムコンポーネントに対して完全なDR計画とテストを実施する
- システムコンポーネントの変更に応じて定期的に繰り返す
- 更新手順が確実にテストされていない限り、重要なシステムコンポーネントを更新しないでください。
®
