さて3回も続くとは思いませんでしたが Windows Azure をSCOMで管理しよう、の第3回です。（ その1・その2）
今回は実際に監視を始めるところまでをやりたいと思います。（なんと、終わりませんでした）

※ちなみにこの記事書いてる時点で Windows Azure 管理パックのダウンロードリンクが無くなっているので、ひょっとしたら不具合等あるのかもしれません。もし実践してみる方は自己責任でお願いします。（というかやめておいたほうがいいのかな…？）

 

まえがき

さて環境は前回までの続きですので、あらかじめそちらを参照しておいて下さいね。

では、Windows Azure の管理の前段階ということで証明書の準備からはじめます。

証明書の作成

Visual Studio コマンドプロンプト等を立ち上げて、下記コマンドを実行して自己署名証明書を作成します。

makecert -r -pe -a sha1 -n "CN=Windows Azure Authentication Certificate" -ss My -len 2048 -sp "Microsoft Enhanced RSA and AES Cryptographic Provider" -sy 24 testcert.cer

※実行フォルダは書き込み権限が無いとエラーになりますので注意。
※コマンドの内容はスルーしますが Windows Azure 側の条件に従って2048ビット長、RSA/AESで作成します。

Windows Azure 開発者ポータルで証明書の登録

証明書ができたら Windows Azure 開発者ポータルで証明書を登録します。

Account タブの Manage My API Certificates を選択します。

参照ボタンをクリックして先ほど作成して証明書（.cerファイル）を指定してアップロードします。

アップロードが完了すれば Installed Certificates 欄にアップロードした証明書が記載されます。

証明書のエクスポート

さて、Management APIを使用する Azure MMC等と同じように、SCOMも先ほど登録した証明書＋秘密鍵が必要になります。（これはManagement APIを使う場合の必須条件なのでしょうがないですね）

さて先ほど作成した証明書（.cer）は公開鍵しか含んでおりませんので、証明書を作成したPC上で秘密鍵付でエクスポートする必要があります。
※Windowsの場合、秘密鍵は触れないところにあるのでもし作成したPCが無くなると、証明書の作り直しが発生します。（秘密鍵がなくなるので）

ではエクスポートしましょう。
コマンドの実行で certmgr.msc を起動します。
先ほど何も意識せずに作成した場合は [個人]-[証明書]にストアされてるはずですので、作成した際につけた名前の証明書を右クリックしてエクスポートを選択します。

今回、秘密鍵が必要ですので[はい、秘密キーをエクスポートします]を選択します。

ファイルの形式は秘密鍵を含んだ場合、PKCS #12しか選べませんのでそのままで。チェックのオプションは[証明のパスにある証明書を可能であればすべて含む]と[すべての拡張プロパティをエクスポートする]にチェックを付けます。

※もし秘密鍵含めて証明書を移動させる場合は秘密キーの削除にもチェックを入れてください。（秘密鍵がいろんなところにあるのはよろしくないですね）

秘密鍵付で証明書をエクスポートする場合、秘密鍵を保護するためにパスワードが必要ですので、任意のパスワードを入力します。このパスワードは、後程SCOM側（要は証明書を利用する側）で解除するのに必要なので、忘れないようにしてください。

証明書（.pfxファイル）がエクスポートされたら、大事にこのファイルをSCOMサーバーに移しておいてください。

まぁここまでは Azure MMCとか使う場合でも変わらないので、それほど変わった話でもないかと思います。

実行アカウントの作成（3種類）

SCOMには実行ユーザーと、実行ユーザーが動作する環境を表すプロファイルといった概念があります。
実行ユーザーはWindowsのユーザーだけでなく、基本認証やバイナリ認証といった項目が使えますので、Webアプリの認証などもOKですね。多様なシステムを管理するための仕組みだと思います。

さて Windows Azure 管理パックを利用するにあたっては、ドキュメントに記載のある通り3種類の実行アカウントを作成する必要があります。

Windows Azure Run As Profile Blob の作成

実行アカウントの作成はSCOMの Operations Console から[管理]パネルを選択し、右クリックメニューから[実行アカウントの作成]を選択します。

作成ウィザードが表示されるので、実行アカウントの種類を”バイナリ認証”、表示名をドキュメントにのっとって’”Windows Azure Run As Profile Blob”にします。

バイナリ認証の場合、証明書を聞かれるので、先ほどエクスポートした秘密鍵付の証明書（.pfxファイル）を指定します。

配布セキュリティは可能であれば [高セキュリティ]を選択します。

※検証環境なら低セキュリティでもいいのですが、推奨は高セキュリティです。

以上で実行アカウントが作成されました。
同様に残り2種類も作成します。

Windows Azure Run As Profile Password の作成

基本認証で作成します。

基本認証の場合はアカウント名とパスワードの入力を求められます。

今回作成するこの実行ユーザーは、証明書にアクセスするための実行ユーザーになります。（ちょっと複雑です）
ここで入力するパスワードは、秘密鍵付証明書（.pfxファイル）をエクスポートする際に設定したパスワードになります。
SCOM側で監視する際に証明書の情報が必要になるので、ここで指定された実行ユーザーでアクセスするというわけです。
ですので、実際にはアカウント名は利用しませんので、何でも可です。（空欄はNGなので、何かしら埋めておきます）

Windows Azure Run As Profile Proxy の作成

最後に実行アカウントの種類がWindowsで作成します。

この実行ユーザーは実際に監視を実行するユーザーの情報になります。今回はドメインの管理者アカウントを資格情報として設定しています。

3種類の実行ユーザー作成後は以下のような画面になると思います。

 

実行ユーザーのプロファイルへの割り当て

次に、作成した実行ユーザーをプロファイルに割り当てていきます。
プロファイルそのものは Windows Azure 管理パックをインストールすると作成されていると思いますので、プロファイルを選択してプロパティから割り当てを実施します。
※ひょっとしたらSCOM 2007 R2 CU3 でできてるかもしれませんが…

ウィザードそのものは実行アカウントを追加するだけです。
プロファイルと同名（ドキュメント通りなら）の実行ユーザーを選択し追加していきます。

ウィザードの最後に、実行アカウントの資格情報が配布されていない旨が表示されますので、リンクをクリックして配布します。

忘れず他の2つのプロファイルについても実行ユーザーを追加しておきます。

監視プロファイルの追加

さていよいよ本丸です。
このステップで、実際に監視を行う Windows Azure 上のHosted Service を指定します。

まず、監視対象となる Windows Azure のサブスクリプションIDが必要となりますので、 Windows Azure 開発者ポータルからIDを控えておきます。

次に、SCOM Operations Console の作成パネルから監視の追加ウィザードを起動します。

監視の種類の選択画面にて、[Windows Azure Application]を選択します。

フレンドリ名を入力します。（監視対象がわかる名称でよいと思います）
また管理パックは既定でも問題ないと思いますが、新規で Windows Azure アプリケーション用の管理パックを作成してもよいと思います。（今回は新規作成しました）

アプリケーションの詳細設定で、監視対象となる Windows Azure アプリケーションの情報を入力します。

• ホストされるサービス名
• Hosted Service 作成時に入力した名称（xxx.cloudapp.net の xxx の部分）を入力。
• 配信登録 ID
• 先ほど控えたサブスクリプションIDを入力。
• 監視対象の展開スロット
• プロダクション、ステージングまたは両方から選択します。
• Azure 証明書の実行アカウント
• 先ほど作成した実行ユーザー（Windows Azure Run As Profile Blob）が一覧にあると思いますので、そちらを指定。
• Azure 証明書のパスワードの実行アカウント
• 先ほど作成した実行ユーザー（Windows Azure Run As Profile Password）が一覧にあると思いますので、そちらを指定。

プロキシエージェントは監視を実行するサーバーを指定しますので、参照ボタンから検索して指定します。
またHTTPSの通信にプロキシサーバーが必要な場合はチェックを付けてプロキシサーバーのアドレスを入力します。
※ただし、認証が必要なプロキシサーバーの場合、うまく行きませんでしたので注意が必要です。（ドメインアカウントでWindows認証が使えるならひょっとしたら行けるかもしれませんが、Proxyによって変わりそうです。）

以上で監視対象が作成されました。

もし、ほかにも監視対象の Windows Azure Hosted Services がある場合は同様の手順で追加していきます。
但し、利用する証明書が異なる場合等は実行ユーザーの作成も併せて行っておく必要があります。
（監視対象の証明書と一致していないといけません）

 

確認

さてこれで監視ができるようになりました。
※監視の一覧に表示されるまで少し時間がかかるかもしれません。（即時ではないです）

Operations Console の監視パネルから見てみると、作成した監視対象の Hosted Service が表示されていると思います。

※残念ながらちょっとうまく行かず、メンテナンスモードの画面ですが…

ここまで出来れば、実際にアプリのデプロイを行ってみてダイアグラムを見たり、パフォーマンスを収集したりすることができると思います。

 

トラブルシュート

SCOMを入れる時が悪かったのか、うまく監視されていないな？（いつまでも”監視しない”のままだな？）というときは、イベントログを見てみてください。（結構な量のインフォメーションに埋もれてエラーが出力されている可能性があります）

おいらの環境では、DBへのデータ登録に失敗していたようで、”System Center Data Access”サービスと”System Center Management Configuration”サービスの実行アカウントを Local System からドメインの Administrator に変更しました。（これも無理やりな気がします）

また今日みたいに Azure 側で調子が悪い（Management APIのRESTが500を返すとか）場合もログに出力されますので、何かあった際はイベントログを確認ください。

まとめ

なんとなく書き始めて3回目まで引っ張ってしまいましたが、やっと監視できそう、というところで今回は終わりです。
あとは Diagnostics を有効にした Windows Azure アプリケーションをデプロイし、実際にパフォーマンスを取得したりするだけです。（ そのへんの時間が取れなくて今回はここまで）

後はSCOMの話になってくるわけですが、いまだに動的なインスタンスの増加（JPC等でMS西脇さんがデモしてた内容）等、管理をどこでするのかよく分かってません。ダイアグラムでやってたけどそんなメニューあるのかな…

ただ、SCOM上で監視ができるようになったということは（多少のラグはあるにせよ）今までWindowsサーバー等をSCOMで管理・監視していたIT管理者の方には凄いメリットがあるのではないでしょうか。

使い慣れたインターフェースと、ナレッジの蓄積・共有などIT管理者が望んでる機能が盛りだくさんですので、ITProの方には是非SCOM＋Windows Azure 管理パックを触っていただいて、自社の管理と Windows Azure の展開・利用についての取っ掛かりとなればなぁと思います。

また、この記事が少しでも理解の手助けになれば幸いです。