Windows Azure

Windows Azureアプリケーションのデバッグを通して、Azureプラットフォームでのデバッグテクニックを蓄積しました。Windows Azureのトラブルシュートの為に使用している情報の多くを共有するためのBlogシリーズを投稿する予定です。
シリーズの最初は、Azure VMにリモートデスクトップで接続し、確認することができるリソースを紹介したいと思います。

VM上のリソース

問題の解決の為に重要なことの一つは、環境全体と提供されているリソースとログファイルについて理解することです。
Cドライブは設定情報とローカルストレージを格納します。
Dドライブは、WindowsとWaAppAgentログを格納します。
Eドライブは、顧客のロールコードを格納します。

Cドライブ:ログファイル、ローカルストレージフォルダー

デバッグ(例えば、WinDBG、ツール、ダンプファイル、ログファイルなど)している間、ローカルの一時領域としてCドライブを使用できます。すべてのトラブルシューティングツールが読み込むためにC:\Scratchを作成します。

  • C:\Config サービス設定情報
    • <DeploymentID>.<RoleName>.<index>.xml
      これは、ユーザロール用メインの設定情報です。サービス設定ファイル(管理ポータルで設定を更新したり、更新を再配置など)を更新したら、複数のコピーされたXMLファイルが格納され、<index>カウンターは、新しい設定バージョンが1つ追加されます。
      • デプロイ名
      • サービス名
      • 証明書
      • ホストプロセス
      • cscfg設定と値
      • ローカルストレージフォルダー
      • InputEndpoint、InternalEndpoinとポートのマッピング
    • <GUID>.ccf
      • OSバージョン
      • クラスター名
      • デプロイID
      • VMサイズ(<ProcessorCount>を探してください)
      • ipconfig情報
  • C:Resources ローカルストレージ、ログファイル、AspNetTemp
    • ディレクトリ\<GUID>.<RoleName>.DiagnosticStore – IISログ、失敗したリクエスト(freb)ログ
    • ディレクトリ\<guid>.<role>.DiagnosticStore\Monitor\Tables – Azure 診断モニターが収集したすべての調査情報(イベントログ、ロールログ、WAD調査情報など)。table2csv.exeを使用して.tsfファイルを収集する方法は、Getting Azure Diagnostic Information from a VMを参照してください。
    • Temp\<GUID>.<RoleName>\RoleTemp – ホストプロセスログ
    • Directory\<GUID>.<RoleName>.<LocalStorage name> – サービスモデル(.csdef)で定義されている<LocalStorage>フォルダーです。

Dドライブ:Windows(%SystemDrive%、%SystemRoot%など)、エージェントログ

  • D:\Packages\GuestAgent – エージェントログ
    • このロケーションからWaAppAgent.exeが開始されます。
    • WaAppAgent.exe.log – インスタンスのスタートアップ詳細を記録するエージェントログファイル
    • WaAppAgent.<index>.log – 履歴ログファイル

Eドライブ:サービスパッケージを含む仮想ドライブ

ゲストエージェントがサービスパッケージを配置したとき、このドライブが作成されます。これは動的に生成され、落ち着くまでFドライブ、Gドライブとなります。

  • _entrypoint.txt – ホストプロセスが呼び出すエントリポイントを含むDLL
  • RoleModel.xml – <Startup>タスクと<Sites>設定エレメントを含むXMLファイルです。また、MSBuild情報とターゲット.NET Frameworkのバージョンを含みます。
  • <GUID>.csman – PackageManifestは、パッケージのすべてのファイル一覧(Visual Studioにコピー&ペーストできる形式)を記録しています。
  • \Base\x64 – サービスコードで動作するホストプロセス
  • \Approot – 顧客のコード、aspxページ、DLLなど
  • \Sitesroot\<index> – Full IISサイトの動作起点のフォルダーです。
    ロールがデプロイされたとき、\Approot から、この\Sitesroot へファイルがコピーされ、IISは、\Sitesrootから動作するように設定されます。一時的なテストの為に、ロールを変更する(web.configの変更、新しいDLLなど)場合には、ここを置き換えなければなりません。

Windows Azure

クラウド・インテグレーションチームの開発者サポートエンジニアの視点からWindows Azure情報を共有するWindows Azure – トラブルシューティング&デバッギング Blogに投稿された「Windows Azure Role Architecture」をざっくり意訳した投稿です。

簡単に自己紹介します。私の名前は、Kevin Williamsdonです。マイクロソフトのコマーシャル・テクニカル・サポートチームの配下にあるAzure開発者サポートをする為のクラウド・インテグレーション・エンジニアリングチームのエンジニアです。Azureを使用している顧客が遭遇する問題のトラブルシューティングとデバッグを担当しています。AzureのCTP版を提供し始めた日からチームに所属しており、Azure開発コミュニティから学んだことをBlogを使用して共有していきたいと思っています。

一般的によく聞かれる質問の一つが、Azureロールインスタンスを起動し実行するまでの様々なステップに関するAzureロールのアーキテクチャについてです。サービスがデプロイされた時に発生する主要なステップの概要と、Azure VM上で動作しているコアプロセッサーの概要について説明をしてみたいと思います。

arc

プロセッサーの情報

A. RDFE/FEE

RDFE / FFE は、ユーザからファブリックへの通信経路です。
RDFE (RedDog Front End)は、管理ポータルやサービス管理API(例えば、Visual StudioやAzure MMCなど)のフロントエンドとして公開されたAPIです。 ユーザからのすべてのリクエストがRDFEを通ります。
FFE (Fabric Front End) は、RDFEからファブリックコントローラーへ転送するためのレイヤーです。
すべてのリクエストはRDFEからFFEを経由して、ファブリックコントローラーへ到達します。

B. Fabric Controller

Fabric controller は、データセンターのすべてのリソースを監視し、維持する役割を担っています。
ファブリックOS上のファブリック・ホストエージェントと通信し、ゲストOSバージョン、サービスパッケージ、サービス設定、サービス状態のような情報を送信します。

C. Host Agemt

Host Agent は、Host OS上で動作し、ゲストOSのセットアップをします。ロールをgoal状態へ移行させるためにGuest Agent (WaAppAgent) と通信したり、ゲストエージェントでハートビートチェックするためにGuest Agent (WaAppAgent) と通信します。
Host Agenetが10分間ハートビートを受信しなかった場合、Host Agenetは、ゲストOSを再起動させます。

D. WaAppAgent

  • ゲストOSのファイヤーウォール、ACLs、ローカルストレージリソース、サービスパッケージ、設定、証明書などを設定します。
  • ロールが動作している配下にあるユーザアカウント用のSIDを設定します。
  • ファブリックとロール状態を通信します。
  • WaHostBootstrapperを開始し、ロールがgoal状態になったことを確認するために監視します。

E. WaHostBootstrapper

  • ロール設定を読み込み、すべての必要なタスクと設定プロセスを開始し、ロールを動作せます。
  • すべての子プロセスを監視します。
  • ロールホストプロセス上で、StatusCheckイベントを伝搬させます。

F. IISConfigurator

IISConfiguratorは、Full IIS Webロールの設定(SDK 1.2 HWCロールは動作しません)がされているときに動作します。

  • 標準的なIISサービスを開始します。
  • web configで、Rewriteモジュールを設定します。
  • サービスモデルで、<Sites>設定でAppPoolを設定します。
  • DiagnosticStore LocalStorageフォルダーを指定し、IISロギングを設定します。
  • 権限とACLsを設定します。
  • ウェブサイトは、e:\sitesroot\0 へコピーし、apppool はIISが動作している場所を指定します。

G. Startup tasks

Startup tasks はロールモデルで定義され、WaHostBootstrapperによって開始されます。
Startup tasksは、非同期でバックグラウンドで動作するように設定でき、host bootstrapperは、Startup taskを開始させ、さらに他のStratup taskを続けて開始させます。

Startup Taskは、シンプルモード(既定)で動作するように設定できます。
シンプルモードは、host bootstrapperが次のstartup taskを続ける前に、startup task の実行が終了し、終了コードSuccess(0)が返ってくるまで処理を待ちます。

H. DiagnosticsAgent/RemoteAccessAgent/RemoteFowarderAgent

これらのタスクは、SDKの一部で、ロールのサービス定義(.csdef)で定義されます。
Startup Taskが始まると、DiagnosticsAgentRemoteAccessAgent は、/blockStartup パラメータで定義された2つのStartupタスクで同時に1つしか動作しません。標準的なstartup taskは、ロールが実行している間にバックグラウンドで動作できるように、バックグラウンドstartup task で定義されています。
/blockStartup startup taskは終了するまで、WaHostBootstrapperが続きの処理を待ち続けられるようにSimple taskと定義されています。/blockStartupタスクは、初期化を終了するための決められたタスクを待ち、それが終了したら、 host bootstrapperが処理を継続できるようにします。
このように処理をする理由は、ロールプロセスを開始する前(/blockStartupタスクに対して実行します)に、diagnostics とRDPアクセスができるように設定し、host bootstrapperがスタートアップタスク(これは通常のタスクに対して実行します)が終了した後、diagnostics とRDPアクセスは動作を継続します。

I. WaWorkerHost

WaWorkerHost は、通常のWorkerロール用の標準的なホストプロセスです。
このホストプロセスは、ロールのDLL全てとOnStartやRunのようなエントリポイントをホストします。

J. WaWebHost

WaWebHost は、Hostable Web Core (HWC)に準拠したSDK1.2を使用するように設定したときの、Webロール用の通常のホストプロセスです。
サービス定義(.csdef).から<Sites>エレメントを削除することで、HWCモードをロールで有効にすることができます。このモードでは、すべてのサービスのコードとDLLをWaWebHostプロセスから動作させます。IIS (w3wp)は使用されず、IISはWaWebHost.exeの中でホストされるので、IIS ManagerにAppPoolがありません。

K. WaIISHost

WaIISHost は、Full IISを使用するWebロールのロールエントリポイント用のホストプロセスです。
このプロセスは、RoleEntryPointクラスの実行する際に最初に読み込まれるDLL(このDLLはE:\__entrypoint.txtで定義されています)で、このクラス(OnStart、Run、OnStop)からコードを実行します。幾つかのRoleEnviromentイベント(例えば、StatusCheck、Changedなど)は、このプロセスで発生するRoleEntryPointクラスで作成されます。

L. W3WP

W3WP は、ロールがFull IISを使用するように設定されているときに使用される標準的なIISワーカープロセスです。
これは、IISConfiguratorから設定されたAppPool上で動作します。幾つかのRoleEnviromentイベント(例えば、StatusCheck、Changedなど)は、このプロセスで発生するRoleEntryPointクラスで作成されます。

ワークフローのステップ

  1. 顧客が、.cspkgと.cscfgのアップロードや、ロールの停止処理、設定の変更などのようなリクエストをします。この処理は、Azure管理ポータルもしくは、Visual Studioの配置機能のようなサービス管理APIを使用するツールで処理します。このリクエストは、すべてのサブスクリプションが関連付けられたRDFEに行き、FFEへリクエストを通信します。ワークフローステップの残りは、新しいパッケージの配置やパッケージの開始のプロセスに引き継ぎます。
  2. FFEは、(アフィニティグループまたは、地理的位置のような顧客のインプットや、マシンに提供されているファブリックからのインプットを元にした)現在のマシンプールを探し、マシンプールでマスターファブリックコントローラーと通信します。
  3. fabric controller(ファブリックコントローラー)は、CPUコア上で提供されているホスト(又は新しく起動したホスト)を探します。サービスパッケージと設定をホストにコピーし、ファブリックコントローラーは、(DIPs、Ports、ゲストOSなどの設定した)パッケージをデプロイしたホストOS上のホストエージェントと通信します。
  4. The host agent は、ゲストOSを開始し、ゲストエージェント(WaAppAgent)と通信します。ホストは、ロールがゴール状態に向けて動作していることを確認するために下宇土にハードビートを送信します。
  5. WaAppAgent は、ゲストOS(ファイヤウオール、ACLs、ローカルストレージなど)を設定し、新しいXML設定ファイルをc:\Configへコピーし、WaHostBootstrapperプロセスを開始します。
  6. Full IIS Webロールの為に、WaHostBootstrapperは、IISConfiguratorを開始し、IISからWebロール用の既存のAppPoolを削除するよう指示します。
  7. WaHostBootstrapper は、E:\RoleModel.xmlから<Startup>タスクを読み込み、スタートアップタスクの実行を開始します。 WaHostBootstrapperは、すべてのSimpleスタートアップタスクが終了し、正常終了を返してくるまで待機します。
  8. Full IIS Webロールの為に、WaHostBootstrapperは、IIS AppPoolを設定するためにIISConfigurator へ指示し、E:\Sitesroot\<index>サイトを提示します。<index>は、サービスを定義する<Sites>エレメントの数字を基にした0です。
  9. WaHostBootstrapper は、ロールの種類に応じたホストサービスを開始します。
    1. Worker Role: WaWorkerHost.exe を開始します。WaHostBootstrapperはOnStart()メソッドを実行し、Run()メソッドの実行を開始したことが返ってきたら、同時にロール準備完了をマークし、ロードバランサーの管理に追加します(もしInputEndpointsが定義されている場合は)。WaHostBootsrapperは、ロール状態を巡回確認します。
    2. SDK 1.2 HWC Web Role: WaWebHost を開始します。WaHostBootstrapperOnStart()メソッドを実行し、Run()メソッドの実行を開始したことが返ってきたら、同時にロール準備完了をマークし、ロードバランサーの管理に追加します。WaWebHostは、準備のためのリクエスト(GET /do.__rd_runtime_init__)を発生させます。 すべてのwebリクエストは、WaWebHost.exeに送信されます。WaHostBootsrapperは、ロール状態を巡回確認します。
    3. Full IIS Web Role: WaIISHost を開始します。WaHostBootstrapperが、OnStart() メソッドを実行し、 Run()メソッドの実行を開始したことが返ってきたら、同時にロール準備完了をマークし、ロードバランサーの管理に追加します。WaHostBootsrapperは、ロール状態を巡回確認します。
  10. Full IIS Webロールへのウェブリクエスト要求が来ると、W3WPプロセスを開始するためのトリガーとなり、業務用のIIS環境で動作させた時と同じようにリクエストを処理します。

ログファイルの場所

WaAppAgent

  • D:\Packages\GuestAgent\WaAppAgent.exe.log
  • D:\Packages\GuestAgent\WaAppAgent.log

WaHostBootstrapper

  • C:\Resources\Temp\<guid>.<role>\RoleTemp\WaHostBootstrapper.log

WaWebHost

  • C:\Resources\Temp\<guid>.<role>\RoleTemp\WaWebHost.log

WaIISHost

  • C:\Resources\Temp\<guid>.<role>\RoleTemp\WaIISHost.log

IISConfigurator

  • C:\Resources\Temp\<guid>.<role>\RoleTemp\IISConfigurator.log

IIS Logs

  • C:\Resources\Directory\<guid>.<role>.DiagnosticStore\LogFiles\W3SVC1

Windows Event Logs

  • D:\Windows\System32\Winevt\Logs

    Windows Azure

    Windows Azure Team Blogの「New Windows Azure Connect Features Add New Locations, Enhance Interface」をざっくり意訳した投稿です。

    Windows Azure Connectは、オンプレミスとWindows Azureリソース間のネットワーク接続を設定できる単純で簡単に管理できるIPを基にしたメカニズムを提供します。既存のオンプレミスのインフラに、直接IPを基にしたネットワーク接続を可能にすることによって、既存のアプリケーションをクラウドへ簡単に移行することを計画できるようにします。
    Windows Azure Connectは、オンプレミスのアプリケーション上で使用しているのと同じツールで、リモート管理やトラブルシューティングができるようにしたサードクラウドに構築した仮想マシンに、直接接続できるように開発者が簡単に設定することができます。

    今日、地理的に近い中継場所を選択できるようにヨーロッパとアジアに新しい中継場所を追加したことを含む、Windows Azure Connectのいくつかの新しい機能追加をしたことを発表できて光栄です。

    その他の追加機能:

    • オンプレミスのセキュアなエンドポイント上に構築されている既存のオンプレミスのPKIインフラを活用できるように、ローカルマシーン用の証明書ベースのエンドポイントの有効化
    • リボンの再構成、エンドポイントバージョン・サポート状態の追加などをした複数の管理UIの強化
    • 調査確認をしやすいようにエンドポイントUIの更新

    Windows Azure ConnectはCTP版での提供です。CTP版の提供が終了するまでは、Windows Azure Connectは課金されない招待性での提供です。招待を要求するには、Windows Azure管理ポータルのBeta Programにアクセスしてください。

    Windows Azure

    Microsoft reorg: Scott Guthrie to head new Azure Application Platform team | ZDNetを抜粋して、ざっくり意訳した投稿です。

    予想されていたように、Microsoftのサーバとツールビジネスの組織変更が、5/2に発表されました。

    現在、マイクロソフトで.NETプラットフォームを担当する副社長のScott Guthrie が、ビジネスプラットフォーム担当の上級副社長Ted Kummertの下で、Azureアプリケーションプラットフォームチームを率いることになりました。

    Windows Azureチームは、サーバ・クラウド担当の副社長Bill Laingの下に残ります。Laingは、マイクロソフトを退職したAmitabh Srivastavaから、先月担当を引き継ぎました。

    開発担当の上級副社長Soma Somasegarが、自分のチームに送ったGuthrieの新しい役割についての内部メモを一部紹介します。

    Azureとクラウドへ集中することを、より鮮明にします。Azureとクラウドはマイクロソフトにとって最も重要な分野です。我々のクラウドアプリケーションプラットフォームを力強く牽引するリーダーが必要です。
    Guthrieが担当するAzureアプリケーションプラットフォームチームは、Webプラットフォーム・ツールチームと、アプリケーションサーバグループと、Windows AzureチームからポータルとLightSwitch担当が一体となったチームです。
    Guthrieの異動後、クライアントプラットフォームチームはKevin Gallo が担当します。

    今まで、Kummertのビジネスプラットフォーム領域は、SQL Server, SQL Azure, BizTalk Server, Windows Server AppFabric 、 Windows Azure platform AppFabric, Windows Communication Foundation, Windows Workflow Foundationを担当していました。これらのプロダクトは、マイクロソフトのプライベートクラウドのコアの戦略と展開を担っていました。

    もう一つの異動関係のニュースで先月発表されたニュースがあります。Tom Caseyの新しいポストは、ビジネスプラットフォームクラウドサービスの副社長です。
    彼の新しい役割は、SQL Azureのすべてのビジネス、エンジニアリング、オペレーションの責任を持つことです。

    Windows Azure

    Using DebugView to Troubleshoot Windows Azure Deployments – Snip/Shot by Toddy Mladenovを元にてけてけっと書いた投稿です。

    Windows Azure のデプロイに失敗する場合に、表面的には何が問題で失敗しているのかがわかりにくく、原因特定に手間取ることがあります。
    しかし、幸運にもリモートデスクトップでロールに接続できる状態の場合は、SysinternalのDebugViewを使用して、問題の発生原因を特定できるかもしれません。

    手順

    1. Windows Azureのデプロイに失敗しているロールにリモートデスクトップで接続します。
      接続手順は、Windows Azure実行環境へのリモート・デスクトップ接続 - @ITを参照。
    2. リモートデスクトップで接続したら、ロール上で直接technetからダウンロードするか、リモートデスクトップのローカル共有を使用して、ファイルを転送します。
      IEは(Windows Server 2008標準設定で)セキュリティ強化されていますので、信頼済みサイトにtechnetを追加しないとファイルがダウンロードできないかも。
      ダウンロード先は、DebugView for Windowsです。
    3. Dbgview.exeを開始し、Captureメニューからキャプチャーしたいものを選択します。ツールバー上のアイコンで、キャプチャーの開始と停止ができます。
    4. 22

    すると上のようなキャプチャーが取れます。
    上の画像のケースはスタートアップタスクでこけていることがわかり、原因解決に役立った・・・・そうです(笑

    参考情報

    Sysinternalで公開されているDebugView for Windows

    DebugView は、ローカル システム、または TCP/IP 経由でアクセスできるネットワーク上の任意のコンピュータにおける、デバッグの出力を監視できるアプリケーションです。カーネル モード デバッグの出力と Win32 デバッグの出力の両方を表示できるので、アプリケーションやデバイス ドライバーから生成されたデバッグの出力をデバッガーで取得する必要がなく、標準以外のデバッグの出力 API を使用するようにアプリケーションやドライバーを変更する必要もありません。