2012年12月28日に米国南部地域で発生したWindows Azureストレージのサービス中断の詳細

Posted: 2013/01/17 カテゴリー: Uncategorized
タグ:, , , ,

昨年末に米国南部地域で発生したWindows Azureストレージの障害報告のブログ ポストを、ざっくり訳しました。完全訳は、日本の公式ブログへのポストをお待ちくださいませ。

はじめに

2012年12月28日に、Widnows Azureストレージ アカウントの1.8%に影響を与えるサービス中断が発生。影響を受けたストレージ アカウントは、米国南部地域の1つのストレージ スタンプ (クラスター) に存在したもの。サービス中断の根本原因、回復プロセス、学び、改善点に関する情報を提供したい。影響を受けたお客様には、サービス クレジットを発行。品質改善のため、今回の問題で学んだことを実装中。

Windows Azure概要

Windows Azureは、異なる地域にある異なるデータ センターで、Windows Azureストレージを含む多数のクラウド サービスを稼働。地域ごとに、「スタンプ」(英語 / 日本語 (機械翻訳)) と呼ばれる複数のストレージ サービスがデプロイされている。各ストレージ スタンプには、ストレージ ノードのラックが複数ある。今回の問題は、米国南部地域の1つのストレージ スタンプに影響を与えた。

「Windows Azureファブリック コントローラー」は、H/Wを管理し、Windows Azure上のクラウド サービスに対するリソース管理、デプロイ/アップグレード、管理を提供する、リソース プロビジョニング/管理レイヤー。複数スタンプに影響を与えるエラーを避けるため、ストレージ スタンプごとに異なるファブリック コントローラーが存在。これが、今回の問題で役に立った。

ファブリック コントローラーは、ストレージ スタンプに対して、ノード管理、ネットワーク構成、健全性監視、サービス インスタンスの起動/停止、サービスのデプロイを提供。さらに、スタンプは、ファブリック コントローラーから、ネットワーク トポロジー情報、ノードの物理レイアウト、ストレージ ノードのH/W構成を取得。ストレージ サービスは、ディスク間のレプリケーション/データ配置の管理、ストレージ クラスターでのデータ/アプリ負荷の負荷分散に責任を持つ。

ファブリック コントローラーが誤って (ディスクの再フォーマットのような) 処理を実行することを避けるため、ファブリック コントローラーには、「ノード保護」と呼ばれる一連の防御機能がある。ストレージ サービスは、この機能を活用して全ノードを保護する。ストレージ スタンプは常に保護されているべきだが、特定のストレージ ノードの保護を無効にしたい正当なシナリオがある (マシン修理時など)。修理後、ノードがファブリックに取り込まれる準備ができるまで、保護は無効化されている。準備処理の完了後、そのストレージ ノードに対するノード保護が有効化される。

根本原因

3つの問題の組み合わせが、サービス中断を引き起こした。

(1) 影響を受けた1つのストレージ スタンプ内で、一部のストレージ ノードが修理後にノード保護が無効化されたまま運用環境に戻った。これは人的エラーによるもので、スタンプ内のストレージ ノードの約10%が、ノード保護なしで稼働していた。

(2) 修理後にストレージ ノードを戻す際の構成エラーを検出する監視システムに欠陥があり、警告とエスカレーションに失敗。

(3) 12月28日午前7時9分 (PST) に、ストレージ スタンプのファブリック コントローラーで、新規プライマリ ノードへの遷移が始まった。新規プライマリ ノードへの遷移は、通常のメンテナンスやH/W更新などの理由で、しばしば発生するもの。新規プライマリの構成中に、ファブリック コントローラーは既存クラスターの状態をロードした。ここでファブリック コントローラーのバグに遭遇し、保護されていないストレージ ノードに対して誤って「準備」処理をトリガー。準備処理は、保護されていないストレージ ノードを利用可能にするもので、ノード上のドライブのクイック フォーマットを行う。ノード保護は、ファブリック コントローラーが保護されているノードを決してフォーマットしないことを保証するもの。残念ながら、スタンプ内でアクティブなストレージ ノードの10%が誤って非保護フラグを設定され、準備処理でフォーマットされてしまった。

ストレージ スタンプ内では、3つの異なる障害ドメイン (異なる電源供給、ネットワーク、ラック) にわたって、データの3つのコピーを維持。これによって、スタンプ内での2ノードの同時障害に対応可能。しかし、再フォーマットされたノードは全障害ドメインにわたっており、データの3つのコピー全てが利用不可能になる場合もあった。

ストレージ サービスの回復

ノードが再フォーマットされたと判断し、サービス回復のために2つのアプローチを検討した。

  • 米国南部地域でインプレースでデータを回復 (プランA) – データ損失なしに可用性を回復するため、ストレージ スタンプ上の全ディスクのボリュームを回復
  • 米国北部地域に地理的フェイルオーバー (プランB) – 可用性を回復するため、ストレージ スタンプ内のお客様を、米国南部地域から米国北部地域 (地理的レプリケーション先) にフェイルオーバー (英語 / 日本語 (機械翻訳))。これにより、次のことが起こる。
    • Windows AzureのBLOBおよびテーブルに対する直近の更新の損失 (地理的レプリケーションは非同期のため)
    • Windows Azureキューのデータ損失 (現時点で、Windows Azureキューはローカル冗長のみのため)
    • 地理冗長ストレージではなくローカル冗長ストレージ (英語 / 日本語) を選択していたお客様のデータ損失

我々の目標はお客様のデータを保護することなので、(ある程度の期間内にプランAを実行できない場合は、プランBにフォールバックする考えで) プランAを選択

次に、ストレージ サービスをインプレースで回復するために行った手順を説明し、地理的レプリケーションとフェイルオーバーのプロセスの詳細に踏み込む。

インプレースでのデータ回復 (プランA)

インプレースでのボリューム上のデータ回復のアプローチを設計する必要があった。効率性のため、ドライブ間のデータ コピーを避ける必要もあった。

ファブリック コントローラーが実行した「クイック フォーマット」は、MFT (マスター ファイル テーブル) の先頭に新規メタデータを作成するので、先頭のいくつかのレコード以外は回復できた。MFT回復後に「chkdsk /f」を実行して、ボリューム全体を再作成。

失われた先頭のMFTレコードには、ボリューム ディレクトリー構造のルートが含まれていた。エクステント (英語 / 日本語 (機械翻訳)) (顧客データを含むファイル) の命名規則によって、元の構造を回復できた。

ストレージ ノードへの書き込むを高速にコミットするために使われる「ジャーナル ドライブ」(英語 / 日本語 (機械翻訳)) 向けには、ジャーナル ファイル シグネチャを見つけるためのツールを書く必要があった。

問題発生の32時間後、テスト環境でこれらのテクニックを使ってボリュームを回復できることを確認。

ボリューム回復のためにはボリュームをロックする必要があったが、ファブリック コントローラーは、ボリュームがロックされていると、ノードに問題があると判断し、再起動してしまう。そのため、データ回復中はノードをファブリック コントローラー管理外にする必要があった。

通常、ファブリック コントローラーは問題のあるディスクを持つノードが運用環境に復帰させないが、今回は問題のあるディスクを持つノードを復帰させるため、ファブリック コントローラーにhotfixを展開した。

2012年12月30日午後2時 (PST)、すべてのツールとプロセスが確認され、運用環境のストレージ スタンプの完全回復を開始できるようになった。

ストレージ回復は全ストレージ ノードで整然と実行され、二重チェックされ、ファブリック コントローラー管理に戻された。それから、ストレージ スタンプの全パーティションをロードした。2012年12月30日午後9時32分 (PST) には、ストレージ スタンプは正常動作し、お客様向けのトラフィックを処理し始めた。

我々はストレージスタンプ内のエクステントの一覧を持っており、全てのエクステントが回復された。加えて、スタンプ上のエクステントの全てのチェックサムを検証し、データ損失なしに全データが回復されたことを確認した。

地理冗長ストレージと地理的フェイルオーバー (プランB)

今回のサービス停止に関してお客様から数多くいただいた問い合わせは、サービス停止の影響を理解したら、何故即座にサービスの地理的フェイルオーバーを開始しなかったのかというもの。これに答えるため、最初に地理的レプリケーション ストレージの概要を紹介する。

地理冗長ストレージとは何か?

ストレージ アカウント作成時に、地理的レプリケーションが構成される。お客様が選択した地域が「プライマリ」になり、お客様のデータが地理的レプリケーションされる地域が「セカンダリ」になる。セカンダリの地域は、プライマリの地域を基に自動的に決定される (英語 / 日本語 (機械翻訳))。

地理冗長ストレージは、2つの地域 (プライマリと、プライマリから数百㎞離れたセカンダリ) にお客様のデータをデータを格納することで、最高レベルの持続性を提供。BLOBおよびテーブル データは地理的レプリケーションされる。現時点では、キューのデータは地理的レプリケーションされない (英語 / 日本語 (機械翻訳))。地理冗長ストレージでは、お客様のデータの3つのコピー (レプリカ) をプライマリ、セカンダリ両方で維持する (合計6つのコピー)。これによって、各データ センターでは、一般的なH/W障害 (問題のあるドライブ、問題のあるノード、ラック障害、ネットワークた電力の問題) から回復可能。また、深刻な災害に備えて、セカンダリのデータ センター内に、地理的レプリケーションされたデータのコピーを提供。地理的レプリケーションは、バックグラウンドで行われる非同期レプリケーションを使っているので、ストレージ アカウントで更新のパフォーマンスに影響を与えない。2つの地域は、更新データを互いに地理的レプリケーションするためだけに通信し、回復時には通信は必要ない。プライマリからセカンダリ 巣アンプへの即時のフェイルオーバーを実行する必要がある場合、地理的レプリケーションを介してセカンダリでコミット済みの全データは、既にそこで持続的であり、お客様のアプリは、地理的レプリケーションされていない直近の変更によるデータ損失だけを扱う必要がある。

フェイルオーバー プロセス

フェイルオーバーとは、お客様のストレージ アカウントのプライマリの地域を、これまでプライマリのストレージ スタンプがあった地域から、セカンダリのストレージ スタンプの地域に変更すること。

現在運用されている地理的レプリケーションでは、フェイルオーバーは、ストレージ アカウントのレベルではなくストレージ スタンプのレベルで行われる。地理的フェイルオーバーを行う必要がある場合は、1つのストレージ スタンプ内の全てのお客様を、古いプライマリ スタンプからセカンダリ スタンプ (新しいプライマリ) にフェイルオーバーすることになる。我々はお客様のデータ損失を最小化しようと努めているので、プライマリで深刻な災害が発生し、数日以内で回復できない場合にのみ、フェイルオーバーを行う。

何故、今回のサービス中断で地理的フェイルオーバーを行わなかったのか?

地理的レプリケーションは非同期なので、米国南部地域から米国北部地域にフェイルオーバーした場合、ストレージ アカウントへの直近の更新が失われる。今回影響を受けたストレージ スタンプでは、スタンプ内のお客様全てで8GBの直近のデータ更新が失われると見積もった。加えて、Windows Azureキューは地理的レプリケーションされていない (2013年内にサポート予定)。そのため、フェイルオーバーを実行した場合、影響を受けたストレージ スタンプ内のストレージ アカウントのWindows Azureキューのデータが失われてしまう。さらに、ローカル冗長ストレージを選択していた全てのお客様のデータが失われてしまう。

可用性よりデータ持続性を重視してインプレースのスタンプ回復を求めるお客様も、可用性を重視して迅速なフェイルオーバーを求めるお客様もいた。数日以内でデータ損失なしにべ国南部地域のプライマリ ストレージ スタンプを回復できると信じていたので、我々はデータ持続性を優先した。

サービスの改善

問題発生後、時間をかけて今回の問題と、我々のエンジニアリング、運用、コミュニケーションを改善できる方法を分析した。出来る限り学ぶため根本原因分析を行い、プラットフォームの信頼性を改善するために問題の全ての側面を分析した。

この分析は、(問題のライフサイクルの各パートと、それに先立つエンジニアリング プロセスを表す) 4つの主要領域に分類されている。

  • 検出 – どのように迅速に障害を表面化させ、回復の優先順位付けをするか?
  • 回復 – どのように回復時間とお客様への影響をを削減するか?
  • 回避 – どのようにシステムが障害を回避し、障害を隔離し、障害から回復できるか?
  • 応答 – 問題発生中に、どのようにお客様をサポートするか?

検出

修理後にストレージ ノードを戻す際の構成エラーを検出する監視システムを修正した。

回復

主要な作業項目は、お客様が持続性と可用性との間で選択できるようにし、お客様が回復力のあるアプリを構築できるようにすること。これに向かって、次の機能を今度提供すすべく作業中。

  • キューの地理的レプリケーション – Windows Azureストレージ アカウントのキュー データに対して、地理的レプリケーションを有効化する予定。
  • 地理的レプリケーションされたストレージ アカウントに対する、読み取り専用アクセス – セカンダリでのお客様のストレージ アカウントへの読み取り専用アクセスを有効化する予定。
  • 地理的レプリケーションされたストレージ アカウントに対する、お客様制御のフェイルオーバー – お客様が、それぞれのビジネス ニーズを基に、データ持続性よりサービス可用性を優先できるようにする予定。お客様がストレージ アカウントのフェイルオーバーをトリガーできるAPIを提供予定。

回避

ストレージ ノードが「準備」状態になってしまうファブリック コントローラーのバグを修正した。また、適切なトレーニングが継続され、そのプロセスが継続的に改善していくことを保証するために、運用プロセスを見直している。

応答

2012年12月28日午前7時30分 (PST) から午前9時 (PST) までに、(影響を受けたストレージ 巣スタンプ内のデータに依存していたため) プライマリのサービス健全性ダッシュボードが利用不可能になっていた。今回のサービス停止に関連するダッシュボードの最初の更新を、午前8時45分 (PST) に試みたが失敗。ダッシュボードのフェイルオーバー サイトは、午前8時45分 (PST) にアクティブ化され、午前9時1分 (PST) に成功。

同様の問題の発生に備えて影響を軽減するため、Azureサービス ダッシュボードの複数レベルのフェイルオーバー手順を既に改善した。

Windows Azureダッシュボード上にリアルタイムで我々が知っていることを投稿すべく、最善を尽くす。

運用中のサイトの問題が将来、同様のトリガー条件を発生させないことを保証するために、Windows Azureと我々のプロセスを改善するために、継続的に進めていく。これらの改善の多くは、修正、監視と警告の改善、全体的なプラットフォームの回復性を対象にしているが、サービス停止中により詳細で時宜を得たコミュニケーションの提供についても改善。これらの改善は、解決までのETA (予定時刻) に関する可視性向上にも役立つ。

サービス クレジット

今回のサービス中断は、影響を受けたお客様に重大な影響を与えたと、我々は認識。今回の問題の異例な特質と発生期間のため、影響を受けたお客様全てに対して、影響を受けた月次請求期間の全てのストレージ容量とストレージ トランザクションの料金に関して、100%のサービス クレジットを提供。

このクレジットは自動的に適用され、影響を受けた請求期間の次の請求期間で反映される。質問は、Windows Azureサポートまで。

結論

Windows Azureチームは、今後数週間、前述の問題とお客様への影響を精査し続け、サービス改善のための全ての手順を進める予定。今回のサービス停止がお客様に与えた影響を大変申し訳なく思い、お客様のビジネスニースを満たす可用性の高いサービスを提供するために、熱心に作業を継続する予定。

関連情報

 

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中