連載：いまさら聞けないWindows Serverの開発活用術 第2回　Windows上の開発環境の障害やトラブルへの事前対策 亀川 和史 2012/07/20
Page1 Page2 Page3

■開発中の性能やトラブルに対処する

●Windowsディスク内の無駄ファイルを削除する

　本番環境では、運用前に性能（＝パフォーマンス）のベースラインを取得しておき、ベースラインから外れた状態が長期間続くと、その異常な状態を電子メールやSMSなどの何らかの手段で管理者に通知するという運用になっているだろう。本番環境では、「異常」と判断する基準値はいろいろある。例えばCPU負荷や、メモリ使用量、ディスク空き容量、ディスクI/O性能など、いろいろな基準で性能を監視するだろう（性能の監視については、下記のリンク先を参照してほしい）。

• アプリケーションのギアを上げよう： OS機能によるアプリのパフォーマンス測定
• TechNet： ファースト ステップ ガイド - パフォーマンスの監視
• MSDN： Windows Server 2008 R2 のパフォーマンス チューニング

　開発環境では、どうだろうか？ 性能評価（例えばCPUの負荷状況の測定など）が不要な通常の開発環境であれば、ディスクの空き容量のみを監視しておけばいいだろう。ディスクの空き容量はついルーズになりがちで、何でもファイルを置いた結果、気が付いたら、大きく消費しているということもある。

　特に忘れがちなのが、IISのログ・フォルダだ。通常設定では容量制限は行われず、日ごとにローテーションする（＝日ごとに新しいファイルを作成する）設定になっている。開発するASP.NETアプリケーションだけではなく、Team Foundation ServerやSharePointも（各種クライアントから）Webサービス経由でアクセスされるため、IISのログはかなり肥大化する。当然、アクセスするメンバー数に比例してログ・サイズも大きくなるので、気を付ける必要がある。

　開発環境のTeam Foundation ServerやSharePoint、開発中のASP.NETアプリケーションのログは、長くても1週間程度残して自動的に削除すれば問題ない。何かトラブルがあったら、その日のログだけを手動で退避させるという運用で問題ないだろう。

　筆者は、下記のようなPowerShellスクリプトを作り、タスク・スケジューラに登録してIISのログを削除している。

# 毎週任意のタイミングで実行すれば、実行日から7日以前のIISログを削除する。 # 管理者として実行したPowerShellもしくはタスク・スケジューラから実行する場合は「最上位の特権で実行する」のチェックが必要だ。 import-module WebAdministration $logpath = get-itemproperty 'IIS:\Sites\Default Web Site' -name logfile.directory.value $logpath = [environment]::ExpandEnvironmentVariables($logpath) $files = get-childitem $logpath -include "*.log" -recurse foreach($file in $files) {   if($file.lastwritetime.adddays(7) -lt [Datetime]::Now) {     remove-item $file.fullname   } }

IISのログを削除するPowerShellスクリプトの例

　上記のスクリプトを「c:\users\public\documents\deliislog.ps1」ファイルとして保存したとする。タスク・スケジューラに登録するには、［管理者として起動］したコマンド・プロンプトから、以下のコマンドを実行すればよい。

c:\>schtasks /create /sc weekly /TN "IISログ削除" /TR "c:\windows\system32\windowspowershell\v1.0\powershell.exe -file c:\users\public\documents\deliislog.ps1" /RL HIGHEST /ST 00:00 /RU SYSTEM

タスク・スケジューラに登録するコマンドの例

　ただし、言うまでもないことだがスクリプトでの自動削除は、くれぐれも壊しても問題ない環境でテストを行って不具合がないことを確認したうえで、展開するべきだ。IISのログ・フォルダ内のファイルを削除するには、高い特権で実行する必要がある。高い特権で実行するということは、本来、削除してはいけないようなファイルを削除できるということでもある。

　対象となるサーバ台数が少ない場合は1台ずつ登録すればいいが、台数が多くなると特定のサーバからリモートでスクリプトを実行すればメンテナンスも省力化される。PowerShellではWinRMを構成しておけばよい。WinRMのリモート管理の設定を説明すると少し長くなるので、説明を割愛する。詳しくは、以下の記事を参考にしてほしい

• TechNet： PowerShellのリモート管理

　初期状態ではデジタル署名のないPowerShellスクリプトを実行させられないので、以下のリンク先に示されている手順に従って実行可能にしておくか、グループ・ポリシーで明示的に実行可能にしておく必要がある。

• Windows TIPS： PowerShellスクリプトの実行セキュリティ・ポリシーを変更する

　PowerShellスクリプトが実行できるようになったら、Invoke-commandコマンドレットを使うことでクライアントからPowerShellスクリプトをリモートで実行することもできる（次のリンク先と下記のコードを参照）。

• PowerShellによるシステム管理入門： PowerShell 2.0の新機能（リモート実行）

$computers = "server1","server2","server3","server4" foreach($computer in $computers) {  Invoke-Command -ComputerName $computer {     ……上記のIIS削除用スクリプトをここにコピーする……   } }

PowerShellスクリプトをリモートで実行するためのInvoke-commandコマンドレットの利用例

　上記のスクリプトはコンピュータ名（具体的には「server1」「server2」「server3」「server4」）が決め打ちだが、Active Directoryの特定のOU（＝組織単位）に登録されているコンピュータ名の一覧を取得して、Invoke-commandコマンドレットの処理対象にすれば、ほぼ完全にノーメンテナンスでIISのログを削除できる。

　IISのログ以外にも、「%temp%」フォルダに、多くの不要なファイルやクラッシュ・ダンプ・ファイルなどが残っている場合があるだろう。それを定期的に削除する場合には、Windowsに標準搭載のクリーンアップ・マネージャ（cleanmgr.exe）をタスク・スケジューラに登録すればよい（具体的な手順は、下記のリンク先を参照）。

• ディスク クリーンアップを定期的に実行するようにスケジュールする

　注意点として、Windows Server 2008 R2のクリーンアップ・マネージャは、デスクトップ・エクスペリエンス機能を追加しないとインストールされない。よって、デスクトップ・エクスペリエンス機能を有効にするか、以下のリンク先の手順に従って、「cleanmgr.exe」と「cleanmgr.exe.mui」というファイルをコピーする必要があるため注意してほしい。

• TechNet： Disk Cleanup option on drive’s general properties and cleanmgr.exe is not present in Windows Server 2008 or Windows Server 2008 R2 by default（英語）

【コラム】Windows Server 2012のデータ重複除去機能について

IISのログ・ファイルのように、1つ1つは小さいサイズのファイルであっても、それがいつの間にか長期間蓄積された結果、システムに致命的な影響を与えるほどになることもあれば、ISOイメージのように1つのファイルで数Gbytesの空き容量を消費するファイルが複数配置されて容量不足になる場合もあるだろう。このようにシステム内のファイル・データは増大する傾向にある。 　これを改善するための1機能としてWindows Server 2012では、待望の「ブロック・レベルでのデータ重複除去機能」が搭載された。Windows Server 2012が正式版になった後でもよいので、ぜひ試してみてほしい。 TechNet： データ重複除去の概要

●分散ファイル・システムを使用してフォルダ共有をらくらく管理

　フォルダ共有は、「\\＜サーバ名＞\＜共有名＞」という形で使用している人も多いだろう。そのような方は、サーバを何らかの理由で（例えばサーバが壊れた、ディスクの大きいサーバに移行するなどの理由で）交換する必要性が発生したときに、「『\\＜新サーバ名＞\＜共有名＞』に変わるので、アクセス先を変更してください」と開発者全員にメールや掲示板などで通知するという運用を行っているのではないだろうか？ その場合は、Windowsの分散ファイル・システム（Distributed File System。以降、DFS）を使えば、そのような手間から解放される。

　DFSを使うには、Windows Serverの［役割の追加ウィザード］の［サーバーの役割の選択］ページで［ファイル サービス］チェックボックスにチェックを入れて、［役割サービスの選択］ページで［分散ファイル システム］チェックボックスにチェックを入れて、DFSをインストールすれば使用可能となる（次の画面を参照）。

［ファイル サービス］チェックボックスにチェックを入れて［次へ］ボタンをクリック

［分散ファイル システム］チェックボックスにチェックを入れて［次へ］ボタンをクリック

［役割の追加ウィザード］によるDFSのインストール

　分かりやすいようにDFS導入前と導入後で、クライアントから共有フォルダへの接続を図示して比べてみよう。

　DFSを導入していない場合、以下の図のように各クライアントに共有フォルダへの接続先を変更してもらう必要がある。

DFS導入前：「\\＜サーバ名＞\＜共有名＞」という形で接続

管理者も各クライアントの開発者もこのような作業は面倒であり、誰かが接続に失敗したり、古いフォルダにアクセスし続けたりするなどのミスが発生する。クライアントだけならばいいが、サーバのタスク・スケジューラに登録されたタスクがネットワーク共有を使用していると、1つずつ確認および、修正する作業が発生する。また、接続先が存在しないネットワーク・ドライブをログオン時に接続していると、ログオン処理が著しく遅くなる。

　DFSを導入している場合、以下の図のように各クライアントは共有フォルダへの接続先を変更する必要がなく、以前と同じ状態のまま使い続けられる。

DFS導入後：「\\＜DFSのドメイン名＞\＜ルート名＞\＜フォルダ・ターゲット名（＝共有フォルダ名）＞」という形で接続

共有フォルダへの接続先を変更する必要がないので、前述した煩雑な手間から解放される。

　DFSやBranchCacheは、そもそも低速な回線で接続された複数の拠点に同じファイルを複製させるために使う人が多いだろう。今回のように開発環境で利用する場合には、DFSの共有フォルダ名がドメイン名からの階層になる機能だけ使えば十分だ。

　そうしておけば、仮にファイル・サーバをリプレイスすることになっても、DFSの管理ツールからフォルダ・ターゲットを（既存のサーバの共有フォルダから、新しいサーバの共有フォルダに）管理者が変更すれば、キャッシュの期限切れ（既定で15分）の後、各クライアントは自動的に新しいサーバを参照するようになる。このように一度設定するだけで共有先を管理者が一元管理できるので、DFSは大変便利だ。ぜひ使ってほしい。

　続いて次のページでは、イベント・ログの一元化について説明する。

INDEX
	［連載］いまさら聞けないWindows Serverの開発活用術
	第2回　Windows上の開発環境の障害やトラブルへの事前対策
	1．開発サーバのトラブル対応
	2．開発中の性能やトラブルに対処する（1）
	3．開発中の性能やトラブルに対処する（2）

「いまさら聞けないWindows Serverの開発活用術」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）