Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (18)
Destaque
Semelhante a Windows Azure で 2/29 に起こった問題のまとめ
Semelhante a Windows Azure で 2/29 に起こった問題のまとめ (20)
Mais de Sunao Tomita
Mais de Sunao Tomita (20)
Último
Último (9)
Windows Azure で 2/29 に起こった問題のまとめ
- 1. Windows Azure で 2/29 に 起こった問題のまとめ Japan Windows Azure User Group Microsoft MVP for Windows Azure はるたま http://twitter.com/harutama
- 2. 自己紹介 @harutama 2
- 3. 本セッションのゴール • 2012年2月29日に発生した障害に関して正 しく理解するため、Windows Azureの内部 構造に関して理解すること。 • 障害自体に関する説明は軽めになります。 詳細は以下のURLを参照してください。 http://www.microsoft.com/japan/wind owsazure/disruption229/ 3
- 4. 参考リソース • Inside Windows Azure: the cloud operating system http://channel9.msdn.com/Events/BUILD/BUILD2011/ SAC-853T • 蒼の王座 Windows Azure Roleアーキテクチャ http://sqlazure.jp/b/windows-azure/568/ • Inside Windows Azure http://www.microsoft.com/switzerland/msdn/fr/techd ays/techdays11.aspx • A Deep Look Inside Windows Azure AND ITS Virtual Machine http://www.slideshare.net/ylew15/a-deep-look-inside- windows-azure-and-its-vm 4
- 5. ところで 5
- 6. Windows Azure として管理されてる コンピューティング リソースって どのくらい？ 6
- 7. People’s ears usually perk-up when they hear Windows Azure uses more server compute capacity than was used on the planet in 1999. http://blogs.msdn.com/b/windowsazure/archive/2012/05/24/datacenter- expansion-and-capacity-planning.aspx 7
- 8. PC Watch 1999年10大ニュース 順位 項目 1 AMD Athlon登場 2 プレイステーション2発表 3 10万円PC登場、大手メーカーまで波及 4 台湾大地震により、国内PC市場に大きな影響 5 Microsoftと司法省の裁判で、Microsoftに不利な事実認定下る 6 アップル、iMacのデザイン盗用で各社を提訴 7 SDRAM価格高騰、128MBで2万円を越える 8 Pentium III登場、年末には0.18μmプロセスの新世代へ 9 Intel 820チップセット発表直前で延期 10 iモード携帯電話、急速に普及 http://pc.watch.impress.co.jp/docs/article/991224/best10.htm 8
- 10. 物理アーキテクチャ データセンター データセンター ラック内部 ルーター PDU ルーターと スイッチ ロードバランサ 物理マシン 10
- 11. 外側から見たラックの様子 11
- 12. ラックの中身 12
- 13. 論理アーキテクチャ • データセンター内の物理マシンは「クラスター」という 単位で分割されている。 – 1つのクラスタは約1000台の物理マシンで構成される – 不具合の影響がクラスター内で閉じ込められるような設計 • 各クラスターは「ファブリックコントローラー(FC)」に よって管理されている。 クラスター ファブリック コントローラー データセンター ファブリック ルーター コントローラー … … 13
- 14. クラスターの内部構造と ファブリックコントローラー ラック内部 他のファブリック コントローラーとは マスター経由で 状態を同期している ラック内部 ルーターと ロードバランサ クラスター内にある ラック内部 1つのファブリック コントローラーは マスターとして動作する ラック内にある1台の物理マシンは ファブリックコントローラー用に予約される 14
- 15. ファブリックコントローラー 15
- 16. ファブリックコントローラーの役目 • データセンターにおけるカーネルの役割 – データセンターの資源の管理 – Azureで動作するアプリケーションの管理 SQL Exchange SQL Office Server Online Azure 物理マシン データセンター 16
- 17. ファブリックコントローラーの仕事 • リソースの割り当て – 新しい仮想マシンの作成（もちろん効率的に） – 仮想マシンのスケールアップ・スケールアウトの対応 • リソースのプロビジョニング – 物理マシンが故障した際は健全なマシンに移動させる • サービスのライフサイクル管理 – アプリケーションのアップデート – ゲストOSの自動アップデート • サービスのヘルスチェック – アプリケーションの死活監視 – ゲストOSの状態管理 17
- 18. 起動の仕組み • ユーティリティファブリックコントローラー により起動される。 – ファブリックコントローラーの複製元 – アップデートの際にも使用される • ユーティリティファブリックコントローラーは 各ファブリックコントローラーのFeed (Datacenter.xml)を購読している。 – 各サーバーのIPアドレス – サービスに割り当てるためにプールされたIP – ネットワーク機器やPDU(Power Distribution Unit) のIPアドレス 18
- 19. ファブリックコントローラーの中身 • 仮想マシンを作成するための仕組みを持っている – 各種のイメージファイル • 物理マシンのメンテナンス用OS • ホスト用OS • ロールインスタンス用OS – 配布するための仕組み ファブリックコントローラー • PXEサーバー • Windows 展開サービス ホスト ロール メンテ (Windows Deployment Services) OS OS OS Windows PXE サーバー 展開サービス 19
- 20. ノード 20
- 21. 3種類の物理マシン クラスター ラック内部 ルーターと ラック内部 ロードバランサ プライマリー ファブリック ラック内部 コントローラー レプリカ ファブリック コントローラー ノード 21
- 22. ノードの中身 • ノード上では、ホストVM(1個)とアプリVM(n個)が 動作している。 • アプリVMとホストVMは、エージェント同士が通信する。 • ファブリックコントローラーには、ホストエージェントから アプリケーションVMの情報が伝えられる。 ノード アプリ ホスト VM OS ゲスト ホスト ファブリック エージェント エージェント コントローラー ハイパーバイザー 22
- 23. ノードの準備が完了するまで 23
- 24. (1)ノードのブート • ノードに電源が投入されると、ファブリック コントローラーが持っているメンテナンスOSで PXEブートされる。 ノード ファブリックコントローラー ホスト ロール メンテ OS OS OS エージェント メンテナンスOS Windows PXE サーバー 展開サービス 24
- 25. (2)ホストOSのインストール • エージェントはホストOSをインストールする – ノードが持つ物理ディスクをフォーマット – ファブリックコントローラーのWindows 展開サービス からインストールされる ノード ファブリックコントローラー ホスト ロール メンテ OS OS OS エージェント メンテナンスOS Windows PXE サーバー 展開サービス 25
- 26. (3)sysprepの実行 • ノードが再起動してホストOSがブートされる。 • sysprepコマンドを実行して新しいSIDを作成。 その後、再び再起動。 ノード ファブリックコントローラー sysprep/specialize ホスト ホスト ロール メンテ OS OS OS OS ハイパーバイザー Windows PXE サーバー 展開サービス 26
- 27. (4)準備完了！ • ホストOS内で動作しているホストエージェントが ファブリックコントローラーとの通信を開始。 ノード ファブリックコントローラー ホスト ホスト ロール メンテ OS OS OS OS ホスト エージェント ハイパーバイザー Windows PXE サーバー 展開サービス 27
- 28. (5)その後 • 各ノードが持っているイメージリポジトリに、 ファブリックコントローラーが持っている OSイメージを配布する。 – 各種ロールのOSイメージやzipファイルなど ノード ファブリックコントローラー ホスト ホスト ロール メンテ OS OS OS OS ホスト エージェント ハイパーバイザー Windows PXE サーバー 展開サービス 28
- 29. 外から見たWindows Azure 29
- 30. 外から見たWindows Azure Windows Azure 管理ポータル PowerShell Cmdlets RDFE ファブリック ファブリック コントローラー コントローラー … データセンター 30
- 31. RDFEって何？ • RedDog Front End の略称 – Windows Azureに対するAPIをインターネットに公開 しているフロントエンド – ユーザからのすべてのリクエストはRDFEを通る • Red Dog って何？ – Windows Azureがまだ開発中だった頃のコードネーム – ちょっと間違えていたらPink Poodleになっていた http://japan.zdnet.com/cio/sp_07microsoft/20384470/ 31
- 32. Pink Poodle? なにそれ? 32
- 33. RDFEの役割 • Windows Azureのフロントエンドとしての役目 – サブスクリプションの管理 – 課金のカウント – 各種サービスの管理 • ストレージとコンピュートのインスタンスを効率 良く運用する – データセンターリージョンの決定 – アフィニティグループの考慮 – データセンターのVirtual IPや ノードの状況も考えつつ 33
- 34. アプリケーションのデプロイ 34
- 35. (1)ユーザーからの指示 • 新しいパッケージをデプロイする際、クライアントから .csdefファイルがRDFEに対してアップロードされる。 ノード クライアント ホスト .csdef OS ファイル ホスト エージェント RDFE ハイパーバイザー ファブリック コントローラー 35
- 36. (2)クラスターの選択 • RDFEは適切な状態にあるデータセンター内のクラスターを 管理しているファブリックコントローラーを選択する。 – 指定されたリージョンのデータセンターの中で、クラスターの負荷 状況やIPの利用状況などなどを考慮する ノード クライアント ホスト OS .csdef ファイル ホスト エージェント RDFE ハイパーバイザー ファブリック コントローラー 36
- 37. (3)ノードの選択 • ファブリックコントローラーはアプリケーションが動作 するのに適切なノードを選択する。 – アプリケーションが要求するインスタンスのサイズや数を考慮 ノード クライアント ホスト OS ホスト エージェント RDFE ハイパーバイザー ファブリック コントローラー 37
- 38. (4)VMの作成 • アプリケーションが動作する仮想マシンを作成する。 これが最終的にロールインスタンスとなる。 – VMの元となるOSイメージ（Dドライブ）はホストにあるイメージ リポジトリ内にある。 – ローカルディスク領域（Cドライブ）とロールが配置される領域 （EもしくはFドライブ）は動的にイメージが生成される。 ノード クライアント アプリ ホスト VM OS ホスト エージェント RDFE ハイパーバイザー ファブリック コントローラー 38
- 39. (5)内部通信の確立 • エージェントの間での通信を確立させる。 このとき通信を保護するための転送証明書をゲスト側で 作成し、公開鍵だけをホスト側に送る。 • エージェント間通信が確立すると、ホストエージェント はゲストエージェントのハートビート監視を開始する。 ノード 秘密鍵 アプリ ホスト 公開鍵 VM OS ゲスト ホスト エージェント エージェント ハイパーバイザー ファブリック コントローラー 39
- 40. (6)外部通信の設定 • 仮想マシンのネットワークを設定する – 外部につながるDynamic IPを割り当てる – 内部のVirtual IPとポートを設定し、外部のDynamic IPを紐付ける – 仮想マシン間の通信にパケットフィルターを適用 – 外部と内部をつなぐロードバランサーの設定を行う ノード ルーター アプリ ホスト VM OS ロードバランサー ゲスト ホスト エージェント エージェント ハイパーバイザー ファブリック コントローラー 40
- 41. サービスの監視 • ファブリックコントローラーは、ソフト・ハードの監視に よって、サービスの可用性を管理する。 – 基本的にハートビートを監視 – 影響のあるノードは自動的に修復される 問題の種類 検出の方法 対処方法 ロールインスタンス ファブリックコントローラーが ・ロールを再起動 のクラッシュ ゲストエージェント経由で監視 ゲストVMやゲスト ホストエージェントがファブリック ・ロールの再起動や、ゲストVMの エージェントの コントローラーにハートビートがな 再起動 クラッシュ くなったことを警告 ホストOSやホスト ファブリックコントローラーが ・ロールの回復を試みる エージェントの ホストエージェントの ・他ノードにロールをマイグレート クラッシュ ハートビートを監視 ホストエージェントが ・他ノードにロールをマイグレート ノードの ファブリックコントローラーに ・ノードに対して“out for repair” ハードウエア障害 警告 とマーキング 41
- 42. 今回の障害について 42
- 43. 障害の原因（その1） • デジタル証明書を生成する際に有効期限 を設定する処理のバグ – 単に現在の年に+1した有効期限で証明書を 作ろうとしてしまっていた。 現在日時 2012年1月1日 現在日時 2012年2月29日 ↓ ↓ 有効期限 2013年1月1日 有効期限 2013年2月29日 ↓ ↓ 問題なし 作られない 43
- 44. 障害発生の直前まで • 新しいバージョンのソフトウエアを展開中 – ファブリックコントローラ – ホストエージェント – ゲストエージェント • 転送証明書の生成が行われやすい状態にあった – 新しい仮想マシンの作成 • 新しい配置を実施したとき • 配置のスケール アウトを行うとき • 配置している仮想マシンの OS を更新したとき – 配置が他のノードにマイグレートされた時 • 「サービス回復」と呼ばれる処理 44
- 45. UTC 2月29日 0:00 • 証明書の作成に失敗すると、ゲストエージェント は終了するためハートビートが返ってこない。 • 25分以内にエージェントの接続が確立しないと、 ホストエージェントは仮想マシンを初期化して 再起動する。（当然状況は改善しない） ノード アプリ ホスト VM OS ゲスト ホスト エージェント エージェント ハイパーバイザー ファブリック コントローラー 45
- 46. ノードレベルの障害 • 3 回連続でエージェント間の接続タイムアウトの後、ホスト エージェントはハードウェア障害があったと判断。 • ホストエージェントはファブリックコントローラーに報告。 • ファブリックコントローラーは対象のノードを 「Human Investigate」という状態に変更した。 ノード エラー報告が無いから ハード障害なんだろうな アプリ ホスト (´・ω・`) VM OS ゲスト ホスト エージェント エージェント ハイパーバイザー ファブリック コントローラー 46
- 47. クラスターレベルの障害 • 「Human Investigate」状態のノードが閾値を超えたため、 ファブリックコントローラーはクラスター全体を 「Human Investigate」の状態に変更した。 • この段階でファブリックコントローラーは、内部で開始され たすべてのソフトウェア更新を停止し、自動サービス回復は 無効化される。 Human Investigateの クラスター ノードが ファブリック 増えすぎたね コントローラー (´・ω・`) ファブリック コントローラー 47
- 48. UTC 2月29日 2:55 • サービスマネージメント機能を停止 – 新しいVMの作成は確実に失敗する • アプリケーションの配置 • スケールアウトの実行 – 稼働中のアプリケーションの保護 • 複数インスタンスで運用して、一部のインスタンス が動作しているアプリケーションを、不用意に操作 することを防ぐため。 48
- 49. 問題の原因（その2） • 新バージョンのソフトウエアを展開中だった7個 のクラスターだけが対象の問題 – 7個のクラスター向けの更新パッケージに ホストエージェントと互換性のないネットワーク プラグインが入っていたため、ネットワーク接続が失 われた。 アプリ ホスト – いくつかのノードは VM OS 個別のエラーが発生 旧ゲスト 旧ホスト エージェント エージェント したため、個別の 対応を行った。 新ネットワーク プラグイン 49
- 50. おわりに 50
- 51. おわりに • 今回の障害でデータロストの問題は生じていない – ストレージサービスやSQL Azureなどのデータロスト は発生していない • 複数のインスタンスで運用していた場合、サービ スの提供は継続できていた可能性が高い – 最大時で、North Central USリージョンの6.7％、 South Central USの28％、North Europeリージョン の37％がサービス障害の対象であった。 http://itpro.nikkeibp.co.jp/article/NEWS/20120301/384015/ 51
- 52. Let’s dream and then let’s build. - Ray Ozzie はるたま (@harutama) http://twitter.com/harutama