ワークフォルダーの実装

ITproさんで「Windows Server 2012 R2で実現するBYOD/リモートワーク」という記事を執筆させていただきました。Windows Server 2012 R2では、いつでも、どこでも、どんなデバイスでも仕事ができるワークスタイルを実現するために利用できる機能が色々と増えており、選択肢が増えたという点で様々な企業で導入しやすくなったのではないかと思います。

記事の中から、興味のある機能があれば、ぜひお試しいただきたいと考えているのですが、ワークフォルダーについて、あまり実装方法が書かれたものを見かけることができなかったので、ここで実装方法を載せておきます。

 

ワークフォルダーとは?

一言で言うなら「オンプレミス版SkyDrive」ってところでしょうか。
ワークフォルダーはクライアントPC(Windows8.1)に用意されたフォルダーにファイルを保存すると、自動的にサーバー(Windows Server 2012 R2)に用意されたフォルダーと同期を行います。これにより、

・サーバーに接続できないような外出先にいるときにサーバーに保存したファイルに
アクセスしたい
・クライアントPCに保存しているファイルをサーバーにバックアップしておきたい
・自分が利用する別のコンピューターから同じファイルにアクセスしたい

のようなときに効果を発揮します。

ワークフォルダーはSkyDriveと同じように、ユーザー単位でフォルダーが独立して管理されているため、同じユーザーであれば、どこにいようともファイルサーバーにアクセスできれば、ワークフォルダーとの同期ができます。

Workfolder

また、ファイルサーバーを外部に公開していないため、同期ができない場合でも、同期したワークフォルダーのコンテンツはローカルに残されるので、どこにいてもアクセスできるメリットがあります。

 

 

設定方法 – 概要

行うことは全部で7つあります。

1.サーバーの用意
2.ワークフォルダーの役割インストール
3.SSLサイトの実装
4.共有フォルダーの設定

5.グループポリシーの設定
6.クライアントの設定(ドメイン参加PCの場合)
7.クライアントの設定(ドメイン未参加PCの場合)

以上の手順を順番に確認していきましょう。

 

 

1.サーバーの用意

役割として、ドメインコントローラー、Webサーバー、ファイルサーバー、証明書サービス、ワークフォルダーの役割が必要になりますが、1台のサーバーにまとめることが可能です。
(Webサーバー、ファイルサーバー、ワークフォルダーは同じサーバーでなければなりません。)
ここではドメインコントローラー、Webサーバー、証明書サービスの役割のインストール方法については省略するので、事前にインストールしておいてください。
なお、Webサーバー(IIS)は、ワークフォルダーの役割をインストールする前にインストールしておく必要があります

 

2.ワークフォルダーの役割インストール

Webサーバー、ファイルサーバーとなっているサーバーにワークフォルダーの役割をインストールします。役割と機能の追加ウィザードから[ファイルサービスと記憶域サービス]-[ワークフォルダー]を追加します。

image

 

3.SSLサイトの実装

既定の設定で作られるWebサーバーのサイトはHTTPのサイトです。ワークフォルダーではSSLサイトが必要になるので、バインドの追加でSSLサイトを作成しておきます。

詳細なSSLサイトの作成手順は省きますが、大まかには次の設定を行っていれば結構です。

・サーバー証明書の追加
・Default Web Siteのバインドの設定でSSLサイトを追加し、追加した証明書を利用するように設定

このとき、SSLサイトで使われる証明書を発行した証明機関(認証局)の情報がワークフォルダーを利用するクライアントコンピューターの[信頼されたルート証明機関]に登録されていることが必須です。そのため、ドメイン参加のコンピューターを対象に使うのであれば、証明機関にはエンタープライズCAを使うことをお勧めします(グループポリシーを通じて自動的に[信頼されたルート証明機関]の情報を書き換えてくれるので)。

 

4.共有フォルダーの設定

ワークフォルダーで使用する共有フォルダーを作成します。

共有フォルダーの作成はサーバーマネージャーの[ファイルサービスと記憶域サービス]-[共有]から[新しい共有]をクリックして作成を開始します。

image

dc072

dc073

WFSyncShareという名前の共有フォルダーを作成します。

dc074

[アクセス許可設定に基づいた列挙を有効にする]にチェックをつけてください。
これにより、他人のワークフォルダーが見えなくすることが可能です。

dc075

ワークフォルダーを利用するユーザーに対する変更アクセス許可を割り当てます。
ここでは全員を意味するAuthenticated Usersグループに割り当てておきます。

dc076

dc077

共有フォルダーの作成が完了したら、続いて共有フォルダーをワークフォルダーとして利用するための設定を行います。

image

cmr2033

サーバー名を選択します。

cmr2034

前の手順で作成した共有フォルダーを選択します。

cmr2035

ここで選択するのは共有フォルダー内に作成される、各ユーザー用のフォルダーの名前の付け方です。

cmr2036

cmr2037

同期を許可するユーザーを選択します。共有フォルダーを作成するときにすべてのユーザーを選択したので、ここでもすべてのユーザーを選択しておきます。

cmr2038

セキュリティの設定です。すみません、ここの設定はまだキャッチアップしていないです。

cmr2039

cmr2040

cmr2041

 

5.グループポリシーの設定

ドメインに参加しているコンピューターの場合、ワークフォルダーの設定はグループポリシーを通じて受け取ることができます。
ワークフォルダーの同期にはWebサーバーのSSLサイトを通じて行われるので、ここではサイトのURLをグループポリシーに登録します。

グループポリシーの編集画面から、[ユーザーの構成]-[ポリシー]-[管理用テンプレート]-[Windowsコンポーネント]-[Work Folders]から[Work Foldersの設定を指定する]を開きます。

image

設定画面で、Work FoldersのURLにSSLサイトのURLを入力します。また、[自動セットアップを強制する]にチェックをつけておけば、クライアント側での初期設定は不要になります。

image

 

6.クライアント側の設定(ドメイン参加PCの場合)

クライアント側の設定はドメインに参加している場合と参加していない場合で異なります。
ここではドメインに参加している場合の設定について確認します。

コントロールパネルのワークフォルダーを開き、

WF1 

グループポリシーの設定を受け取っていれば、初期設定は自動的に行われるので、
最初から以下のような画面が表示されます。

WF2

ワークフォルダーはPC(以前のOSでいうところのマイコンピューター)の中にWork Foldersという名前のフォルダーができるので、このフォルダーにファイルを保存することで、自動的にサーバーの共有フォルダーとの間で同期が行われます。
もちろん、同期はショートカットメニューから手動で行うことも可能です。

WF3

同期が行われると、サーバー側にはユーザーごとにフォルダーを作成し、ファイルを保存します。
それぞれのフォルダーは本人しかアクセスできないようにアクセス許可が設定されています。

WF4

※ちなみにMetadataフォルダーにはEDBファイルが保存されていたので、Active Directoryでおなじみのデータベースの方式を使用してファイルのバージョン管理等を行っているのだと思います。(推測)

 

7.クライアントの設定(ドメイン未参加PCの場合)

ドメインに参加していないPCの場合、グループポリシーから設定を受け取れないので、ワークフォルダーの初期設定を自分で行う必要があります。
初期設定として行うことは大きく分けて2つあり、

1つはSSLサイトで使用する証明書に対する証明機関の情報を[信頼されたルート証明機関]に登録すること、
もう1つはワークフォルダーのセットアップです。

ここでは、ワークフォルダーのセットアップについて紹介しておきます。

コントロールパネルのワークフォルダーから、ワークフォルダーのセットアップをクリックし、

WF5 

ワークフォルダーへのURLと、SSLサイトにアクセスする際の資格情報を入力します。ここで入力した資格情報はワークフォルダーにアクセスするユーザー名になります。

図4

ここまでの設定で出来上がりです。

 

まとめ

ワークフォルダーはWindows Server 2012 R2とWindows8.1の組み合わせでしか、現在のところ利用できないので、普及するまでには相当時間がかかると思いますが、ドメイン参加の有無は関係なく利用できるので、利用可能なデバイス種類が増えてくると利用される機会も多くなるのではないかと思います。SkyDriveやDropboxに代わる、なおかつクラウドを利用しない、安全なストレージ活用方法として覚えておいて損はなさそうです。

Windows Server 2012 R2のロック解除

今日はちょっとした小ネタを。
Windows Server 2012 R2を利用していると、次のような画面に出くわすことがあります。

image

一定時間コンピューターを操作していないとロック画面に移行するため、上のような画面が出てくるのです。セキュリティ的には適切な設定なんだけど、テスト環境などでちょっと手を離したスキに出てくるのは案外面倒くさい。そう思って今までのバージョンのようにスクリーンセーバーの設定を開いたら、スクリーンセーバーの設定で画面ロックをしているのではないのですね。

取り急ぎロックを二度としないように設定しようと思い、操作していたら、コントロールパネルの電源オプションからプラン設定の変更でディスプレイの電源を切らないように設定することで、ロックされないように構成できました。

image

おわり。

【101シリーズ】パフォーマンスモニタ徹底攻略 ~ パフォーマンス計測編

前回の投稿ではハードウェアコンポーネント別にパフォーマンスの計測・確認の方法を紹介しました。今回は、標準的なパフォーマンスカウンタ以外に利用可能なカウンタの紹介や、前回紹介したカウンタの具体的な活用方法を紹介したいと思います。

■ ■ ■

 

Active Directoryドメインサービスのパフォーマンス確認

データコレクタセット(データコレクタセットについては下記コラム参照)には、管理者が手動で作成する「ユーザー定義」と呼ばれるものと、あらかじめシステム側で定義されている「システム」がある。「システム」のデータコレクタセットには、目的別に見るべきカウンタの一覧が並んでおり、言ってみればパフォーマンス計測を行うときのノウハウが詰まっている。そのため、これを使わない手はないだろう。

ここでは、システムデータコレクタセットからActive Directoryドメインサービスのパフォーマンスを確認する「Active Directory Diagnostics」というデータコレクタセットを使ってみよう。システムデータコレクタセットのプロパティを開くと、下の画面のように最初からいくつかのカウンタが入っていることが確認できる。そのため、ドメインコントローラーのサーバー上で、このデータコレクタセットをそのまま開始すれば、Active Directoryドメインサービスのパフォーマンスの計測が開始できる。

 画面16

ちなみに、データコレクタセットに含まれる、代表的なActive Directoryドメインサービスのカウンタを紹介しておく。

・DirectoryServices\DS Client Binds/Sec

ドメインコントローラに接続(バインド)したクライアントの数を表す(1秒あたり)。この数を見ることで、ドメインコントローラを利用するクライアントの数を見ることができ、ドメインコントローラに求められるパフォーマンスを確認することができる。ベースラインと比較をすれば、サービス開始当初に比べてどの程度のクライアントがドメインコントローラを利用するようになったかという増加を見ることができ、サーバー増強の必要性なども間接的に確認できるようになる。

1秒あたりのドメインコントローラに対する読み取りアクセス数を確認するときはDirectoryServices\DS Directory Reads/Secカウンタが利用できる。

・DirectoryServices\DRA Inbound Bytes/Sec

ドメインコントローラが他のドメインコントローラからレプリケーションによって受信したデータのバイト数です(1秒あたり)。Active Directoryドメインサービスでは、定期的に他のドメインコントローラとの間でレプリケーションが行われる。このときに1秒間にどのくらいのデータを受信したかを見ることで、レプリケーションが正しく行われているか、レプリケーションのパフォーマンス、そしてレプリケーションの傾向を知ることができる。

サイト内とサイト間でわけてレプリケーションデータのバイト数を確認した場合、サイト内はDirectoryServices\DRA Inbound Bytes Not Compressed (Within Site) /Secカウンタ、サイト間はDirectoryServices\DRA Inbound Bytes Compressed (Between Sites, After Compression)/Secカウンタでそれぞれ計測できる。

・Process\%Processor Time – インスタンス:Lsass

Lsassはドメインコントローラの基礎となるプロセスで、このプロセスによってプロセッサの使用率が高くなっている場合には、ドメインコントローラが過負荷な状態にあると判断できる。原因は色々あるが、主なところでは、自身がブリッジヘッドサーバーであることによるサイト間レプリケーションの処理、PDCエミュレータとしての処理が過負荷の原因として挙げられる。そのため、ブリッジヘッドサーバーの役割やPDCエミュレータの役割などを他のドメインコントローラへ移動させて、Lsassプロセスに変化があるかチェックするとよいだろう。

 

ファイルコピーのパフォーマンス確認

次は実際に計測した情報から、パフォーマンスを確認する方法を紹介したい。
ここでは、ファイルコピーのスピードが遅くなるケースを取り上げる。

ファイルコピーを行っているときに、一定のスピードでファイルコピーが行われていたのに、 突然ファイルコピーのスピードが遅くなってしまうケースがある。
(100MB/s程度で推移していたファイルコピーが16.1MB/sまで低下している)

image 

上の画面だけを見れば、利用できるネットワークの帯域が少なくなったと考えるかもしれない。 しかし、パフォーマンスモニタを使えば、もっと違うことが見えてくる。

では、実際にパフォーマンス計測を行う。
ここでは、4つのハードウェアから1つのカウンタを採用し、計測することとしよう。

・Processor\%Processor Time
・Memory\Pages/Sec
・Physical Disk\%Disk Time
・Network Interface\Bytes Total/Sec

計測を開始してから、ファイルコピーを開始する。
すると、次のようなグラフが現れた。
まずは、Network Interface\Bytes Total/Secから(グラフ太字参照)。
12:49:45からグラフの最後(12:51:11)までファイルをコピーしている。

network

ファイルコピーのスピードが遅くなった12:50:25あたりから、グラフが下がっていることが確認できる。

続いて、ディスクのPhysical Disk\%Disk Timeについて。

disk

ファイルコピーを開始した12:49:45の直後から、激しくディスクアクセスが発生していることが確認できる。
しかも、ネットワークのスピードが遅くなった12:50:25以降も同じようなアクセスを繰り返している。
本来であれば、ネットワークが遅くなり、受け取るデータ量が少なくなれば、ディスクへの書き込みは待ち状態になる(ディスクアクセスが減る)のに、そうなっていないところを見ると、少なくともネットワーク遅延がボトルネックになっているわけではないのだろうか?という予測ができる。

続いてメモリ(Memory\Pages/Sec)を見てみよう。

memory

ファイルコピーのスピードが低下した12:50:15あたりから、ページングが激しく起きていることが確認できる。ページングは物理メモリから仮想メモリへ(もしくは仮想メモリから物理メモリへ)のデータ移動の回数を表しているため、ファイルコピーに必要な物理メモリが足りなくなって、仮想メモリを使うことになった。

そして、仮想メモリにアクセスしなければならない時点で、パフォーマンスは落ちるので、全体として、ファイルコピーのスピードが遅くなってしまったのではないか?
という予測がたてられるのである。

ちなみに、Processor\%ProcessorTimeカウンタはご覧のとおり、ファイルコピーに何の影響も及ぼしていないことが確認できる。

processor

ここまでのところでファイルコピーをケースにパフォーマンス計測とその分析方法を見ていただいた。
ファイルコピーのスピードが遅くなった場合、表面的な部分だけを見て
「ネットワークが遅い」などと判断するのではなく、パフォーマンスモニタを使えば、問題の本質に切り込めることがおわかりいただけるだろう。

 

コラム:チューニングが必要なサーバーコンポーネント

サーバーアプリケーションによっては、設定ファイルを開いてパラメータを変更したり、レジストリを変更したり、と様々なチューニングが行われる。そうしたチューニングを行ったときに、どの程度のパフォーマンスの改善があるのかを確認したい場合、データコレクタセットの「構成データコレクタ」を利用することをお勧めする。

データコレクタセットではこれまで、システムコンポーネントのパフォーマンスを計測するために利用してきたが、同じくデータコレクタセット内の構成データコレクタを使うと、レジストリやファイルの情報を追跡することもできる。

画面14 

また、構成データコレクタで収集可能なデータは次のとおりだ。

収集可能なデータ 説明
レジストリ 特定のレジストリキー内に格納されているデータを収集
管理パス WMIクエリを実行し、コンピュータの状態情報を収集
ファイルキャプチャ データコレクタセットを実行した時点での、コンピュータ内にある特定のファイルを収集(ファイルごとコピー)
状態のキャプチャ コンピュータに接続されているNICの状態(プロパティ内の情報)を収集

 

データコレクタセットで収集した情報はレポートを通じてその結果を確認することができる。レポートは「信頼性とパフォーマンス」管理ツールの「レポート」から参照することができる。

画面15 

データコレクタセットは、パフォーマンス計測を行う「Performance Counter」と構成情報を収集する「Configuration」の2つがセットになって構成されているので、パフォーマンス計測したデータとその時点での構成データコレクタ情報がまとめて保存されることになる。前述のように、レジストリを修正しながらパフォーマンスチューニングをするような場合、パフォーマンス計測をしながらその時点でのレジストリ値を保存することができる。そうすれば、どの時点でのレジストリ値がパフォーマンスを考慮した場合に良い設定なのかを後から振り返ることができる。

【101シリーズ】パフォーマンスモニタ徹底攻略 ~ パフォーマンスの確認編

前回の基礎編では、パフォーマンスモニタそのものの使い方について紹介してきました。
今回は、パフォーマンスモニタの使い方を受けて、どのようにパフォーマンスに関する情報を収集し、どのようにパフォーマンスの確認をすればよいか、について私なりの方法をまとめてみました。

■ ■ ■

パフォーマンスモニタとデータコレクタの利用方法が確認できたら、今度はパフォーマンスを実際に測定してみよう。パフォーマンスを測定するときは、パフォーマンスに問題があるときに測定して、問題の原因を探る方法もある。しかし、正常な状態のときにも測定しておけば、比較することにより問題の原因を特定しやすくなる。このようなサーバーの基本となるパフォーマンスの状態を「ベースライン」と呼び、パフォーマンス測定によるトラブルシューティングを行うときには是非とも持っておきたい情報だ。

 

ベースラインを測定する

ベースラインは、システムが正常な状態にあるときのパフォーマンスデータである。そのため、パフォーマンス上のトラブルが発生する前に測定しておかなければならない。具体的には、次のようなタイミングである。

・ 実装直後

OSのインストール後、アプリケーションのインストール後、サービスのインストール後など、実装の直後にパフォーマンスを測定することで、初期状態のパフォーマンスを保存しておくことが出来る。これはパフォーマンス上のトラブルが発生したときに、初期状態と比べてどのようなパフォーマンス上の変化があったかを見ることが出来る。

・ 一般的な利用時

サービスのアクティビティに沿ったパフォーマンスの測定を行う方法だ。例えば、サーバーのサービスを利用するときに、アクセスが集中する時間帯、平均的なアクセスがある時間帯、閑散している時間帯と分けることが出来る。これらの時間帯ごとにパフォーマンスを測定すれば、パフォーマンス上のトラブルが発生したときに、どの時間帯でトラブルが発生しているかによって比較するデータを変えることができ、より正確な判断を下すことができるようになる。

・ テスト環境

実装を行う前にテストとなるシステム環境を構築し、そこでパフォーマンステストなどを行うときがある。このときに、想定されるクライアント数でのパフォーマンステストを行い、その結果をベースラインとして保存する。この方法であれば、実環境でパフォーマンス測定を行うこともなく、実環境に負担がかからない測定が可能だ。

以上のタイミングで、あらかじめベースラインを取得しておけば、パフォーマンスの問題が発生したときに、問題の原因を見つけやすくなる。たとえば、以前に比べて「処理が遅い」という報告を受けたとする。そのときには、パフォーマンスコンソールを使って現在の状態を計測し、ベースラインとの比較を画面7のように行う。

画面7では利用可能なメモリ領域(Memory\Available Mbytes – 黒太字表示)について、ベースライン(画面7上)ではほとんど一定の線を描いているのに対し、「処理が遅い」ときは徐々にだが確実に右下がり、つまり利用可能なメモリ領域が徐々に少なくなっていることがわかる。

 

画面7-1
画面7-2
画面7●上がベースライン、下が「処理が遅い」ときの結果

以上のことから判断して、「メモリリークが起きているのではないか?」と判断することができる。もちろん、下のグラフだけで判断することもできるが、ベースラインと比較してみることにより、より鮮明に問題の原因を突き止めることができるだろう。

 

問題の特定

パフォーマンス上のトラブルが発生した場合、その原因はさまざまだ。しかし、一般的なパフォーマンスの低下の原因はプロセッサ(CPU)、メモリ、ディスク、ネットワークのいずれかに分類される。そのため、この4種類のパフォーマンスについて監視を行い、トラブルの原因を探っていく。

 

メモリ

メモリがボトルネックとなることは多い。Windowsのアプリケーションで大量のメモリを利用することに加え、「仮想メモリ」の利用がシステム全体のパフォーマンスに大きな影響を及ぼすからだ。特に、仮想メモリについてはメモリのパフォーマンスを計測する上で重要な要素となるので、簡単に確認しておこう。

Windowsでは物理メモリと仮想メモリの2つのメモリを利用する。物理メモリに配置できるデータ領域がいっぱいになると、物理メモリに保存されているデータのうち、使用していないデータを仮想メモリ(=ハードディスク)に移動する。仮想メモリに配置されたデータが再び必要になると、今度は仮想メモリから物理メモリに移動して利用する。このときに仮想メモリと物理メモリの間を行き来する処理のことを「ページング」と呼ぶ(図2)。ページングが発生すると、物理メモリよりもI/Oのスピードが遅い仮想メモリでデータを扱わなければならないため、システム全体のパフォーマンスに影響が出る。

 

図2
図2●仮想メモリの実体はハードディスクなので、物理メモリに比べると処理の遅さが目立つ

では、以上を踏まえて、具体的にメモリがボトルネックであるか、確認するときに利用できるカウンタについて紹介しよう。

Memory\Available MBytes

Available MBytesは利用可能なメモリ領域をメガバイト(MB)数で表したものだ。Available Mbytesの値をバイト数単位で表すAvailable bytesカウンタもあるが、ここでは後でグラフ化したときに見栄えのするAvailable MBytesを紹介したい。

Available MBytesは利用可能なメモリ領域を表すので、このサイズが大きければ、アプリケーションに大きくメモリを割り当てることができる。逆に、メモリがボトルネックになっている場合、Available MBytesは小さな値になり、アプリケーションに割り当てるメモリの余力が少なくなる。このように、メモリのボトルネックを判断する上で、もっともわかりやすい指標と言えるだろう。

一般的には、物理メモリサイズの5%以下になる場合、メモリがボトルネックだと判断される。また、ベースラインのAvailable MBytesと比較をすれば、どの程度少なくなったかがわかる。

また、Available MBytesカウンタの推移もチェックして欲しい。メモリリークが発生しているならば、前述のようにAvailable MBytesカウンタは徐々に少なくなるグラフになるはずだ。ただし、このカウンタの値が徐々に少なくなるときは、メモリリークが発生しているときだけとは限らない。そのため、他のカウンタとも平行して確認しながら判断しよう。

・Memory\Pages/Sec

1秒あたりに行われたページングの回数を表す。ページングの処理が発生すると、メモリ内のデータの処理に時間がかかってしまう。そのため、ページングの回数は少ない方が望ましい。また、物理メモリが大きく用意されていれば、仮想メモリへの移動、つまりページングの処理は少なくなる。このように考えると、ページングの回数が多いということは物理メモリの容量が足りていないと考えることが出来る。そのためPages/Secカウンタで、多くのページングが行われている場合には物理メモリが少ない(=ボトルネック)と判断できる。一般的には、Pages/Secの値が常に20を超えるような場合にはメモリがボトルネックであると判断される。

・Paging File\%Usage

仮想メモリ(ページングファイル)がどの程度使われているかをパーセンテージで表したものが%Usageである。仮想メモリの容量は「コントロールパネル」の「システム」であらかじめ決められており、その容量の範囲内で仮想メモリのサイズが決まる。%Usageカウンタは最大容量のうち、どの程度の仮想メモリサイズを使っているかを確認する。もし、最大容量に近づいている場合には、仮想メモリサイズを変更するか、物理メモリの容量を増やすなどの対策が必要となる。

・Paging File\%Usage Peak

前述の%Usageカウンタのうち、これまでに使われた最大容量を表したものが%Usage Peakカウンタである。%Usageカウンタと同様に、仮想メモリの最大容量に近づくような高い値を示している場合、仮想メモリが十分なサイズに設定されていないことが考えられるので、仮想メモリサイズを変更するなどの対策が必要となる。

・Physical Disk\%Disk Time

%Disk Timeはディスクの使用率を確認するためのカウンタである。ディスクの使用率がなぜメモリに関係してくるかというと、仮想メモリの利用状況の確認にある。仮想メモリはディスクを使用するため、仮想メモリの利用が多いと、ディスクの使用率も上がる。そのため、ディスクの使用率が高いときにはそれだけで、ディスクがボトルネックと決めるのではなく、仮想メモリと併せて確認することをお勧めする。

 

プロセッサ

メモリと同様にプロセッサもボトルネックになりうる箇所のひとつだ。プロセッサの処理能力以上に処理命令があったときには、処理時間に影響する。そのチェックは以下のカウンタを使って調べるとよい。

・Processor\%Processor Time

プロセッサの使用率を表すカウンタが%Processor Timeである。%Processor Timeは「CPU使用率」としてタスクマネージャでも同じ情報が得られるが、パフォーマンスモニタでも長期的な傾向をつかむためによく利用される。プロセッサの使用率は、一般的に85%を常に超える場合にプロセッサがボトルネックであると言われる。

・Processor\%User Time

プロセッサの使用率のうち、ユーザーモードでの処理に費やした時間をパーセンテージで表したものが%User Timeである。プロセッサの使用率が高いときには、どのような処理によってプロセッサが多く使われているかを確認することがある。そのときに、%User Timeカウンタを参照し、%Processor Timeカウンタと同様に高い値を示すときには、ユーザーモードでの処理にプロセッサが多く使われているとわかる。ユーザーモードの処理は、主にアプリケーションの動作を担当するので、ユーザーモードの処理がプロセッサを圧迫しているなら、起動するアプリケーションを減らすなどの対策が考えられる。画面9はサーバーで動作させているアプリケーションがプロセッサを圧迫している典型的なケースである。

・Processor\%Privileged Time

プロセッサの使用率のうち、カーネルモードでの処理に費やした時間をパーセンテージで表したものが%Privileged Timeである。%Privileged Timeカウンタの値が%Processor Timeカウンタの値と同様に高い値を示すときにはカーネルモードでの処理にプロセッサが多く使われていることがわかる。カーネルモードの処理は、主にオペレーティングシステムの基本動作を担当するので、起動するサービスを減らすなどの対策はあるものの、ユーザーモードに比べると対策として出来ることは限られている。

 

画面9
画面9●Processorオブジェクトのカウンタである、%Processor Time(緑)、%User Time(青)、%Privileged Time(赤)を計測した様子。

 

・Processor\Interrupts/Sec

プロセッサが処理した1秒あたりのハードウェア割り込みの回数を表す。割り込みが発生すると、それまで行っていたプロセッサの処理が中断されるため、頻繁に発生するとプロセッサの処理効率が悪くなる。ベースラインと比較して大きな変化がある場合には、最近追加したデバイスドライバを一時的に無効にするなどして、Interrupts/Secカウンタの値が変化するか確認してみよう。もし、変化するようであれば、そのデバイスドライバを通じて行われる割り込みがCPUをボトルネックにさせている原因と考えることができる。

・System\Processor Queue Length

プロセッサでの処理を待っているスレッドの数を表すカウンタがProcessor Queue Lengthである。処理待ちの数が常に2を超えるような場合、一般的にプロセッサがボトルネックと判断する。Processor Queue Lengthカウンタの値が高い場合、一般的にプロセッサの使用率も高いため、画面10のように2つのカウンタ共に高い値を示す。

 

画面10
画面10●Process Queue Lengthカウンタ(水色)の値が4~10の間を行き来しているところから、プロセッサがボトルネックと判断できる。ちなみに黒太線は%Processor Timeカウンタ。

 

ディスク

SSDに代表されるように、ディスクの高速化はめざましいものがある。Hyper-Vホストで仮想マシンを動かすときに、内蔵のディスクがハードディスクなのか、それともSSDなのか、では明らかにパフォーマンスの差が出る。そうしたパフォーマンスの差はパフォーマンスモニタを使って、確固たる証拠として残しておきたいところだろう(そうすれば、SSD購入に関する会社の承認も通りやすくなるかもしれない?)。ということで、ディスクのパフォーマンスを計測するときには、次のカウンタを中心にチェックしよう。

その前に一点だけ。
ディスクをチェックするときに使うパフォーマンスモニタのオブジェクトはPhysical Diskになるが、Physical Diskオブジェクトの場合、すべてのディスクの平均を参照する方法と、物理ディスクごとに参照する方法がある。これらはインスタンスで設定することが可能だ(画面11)。

画面11
画面11●Physical Diskオブジェクトのカウンタを選択すると、インスタンスで計測対象となる物理ディスクを選択することができる

 

・Physical Disk\%Disk Time

ディスクアクセスを行おうとしたときに、ビジーだったときの割合をパーセンテージで表したものである。ディスクへのアクセスが過多な状態のときにこの値は大きくなる。ただし、この値が高い場合でも、必ずしもディスクがボトルネックではない。たとえば、低速なネットワークを利用している場合、ディスクからデータを効率よく読み出す(書き出す)ことができなくなる。そのため、%Disk Timeカウンタは必ず単独で参照するのではなく、他のカウンタと共にチェックするようにしよう。特に、Processor\%Processor TimeカウンタやNetwork Interface Connection\Bytes Total/Secカウンタと共にチェックし、%Disk Timeカウンタだけが高い値を示す場合にはディスクをボトルネックと見るべきだろう。

・Physical Disk\Current Disk Queue Length

ディスクアクセス待ちをしている要求の数を表している。瞬間的に要求が集中してディスクアクセス待ちになることは考えられるが、平均して2つ以上のディスクアクセス待ちがある場合には、ディスクがボトルネックと考えるべきだ。また、このカウンタをすべてのディスクで計測すると、すべてのディスクでのアクセス待ち数が表示されるので注意して欲しい。例えば、4つのディスクでそれぞれ1つずつアクセス待ちがあれば、Current Disk Queue Lengthカウンタには4という値が出力される。もう、おわかりのように4という数字だけを見てボトルネックと判定してはならない。

・Physical Disk\Disk Writes/Sec

ディスクへの書き込み速度を表すカウンタである。書き込みのパフォーマンスを計測するときに利用する。この値はシステム構成や利用するサーバーアプリケーションによって許容値が異なるので、ベースラインと比較しながらパフォーマンスの確認を行う。ちなみに、Disk Reads/Secカウンタは読み取りのパフォーマンスを計測するときに利用する。

 

ネットワーク

イントラネットの環境ならギガビット、インターネットの世界でも100Mbpsは当たり前になってきた。そのため、イーサネットによる一般的なネットワークがボトルネックになるケースは少ないように思う。しかし、ネットワークがボトルネックになることが全くないわけではないので、調査方法を確認していくことにしよう。

まず、ネットワークのボトルネックは、大きく次の2つに分類することができる。

1.HUBやルーターなどの中継機器を含めたネットワークインフラ(帯域)がボトルネックとなる場合

2.ネットワークアクセスを大量に必要とするアプリケーションの存在やNICの性能など、コンピュータのネットワーク機能がボトルネックとなる場合

2つのうち、いずれが原因であるかについて、次に紹介するカウンタを使って確認していく。

 

・Network Interface\Bytes Total/Sec

NICが1秒間に送受信したバイト数を表している。サーバーアプリケーションが決められた時間内に送受信したいデータをサーバーのNICが送受信できているかを見ることができる。このとき、他のコンピュータでもBytes Total/Secカウンタを使ってパフォーマンス計測をする。そこで、他のコンピュータでも同様に結果が出てくるようであれば、ネットワークインフラそのものがボトルネックではないかと推測できる。一方、特定のサーバーだけでBytes Total/Secカウンタの値が低ければ、そのサーバーのネットワーク機能がボトルネックではないかと推測することができる。

また、ベースラインと比較をすれば、ベースラインを取得した時期と比べてどの程度ネットワークの使用率が増えたかを見ることもできる。

それから、ネットワーク利用が増えたときに注意しなければならないのが、ハードウェア割り込みの問題である。ネットワークの利用率が増えると、それだけNICはプロセッサに対してハードウェア割り込みを要求するため、Processor\Interruptsカウンタの値やProcessor\%Processor Timeカウンタの値が増える(画面12)。このことを理解したうえでProcessor\%Processor Timeカウンタを見ないと、ボトルネックの本質的な原因を見失いかねない。

画面12
画面12●Bytes Total/Secカウンタ(黒太線)の値が増えると、ハードウェア割り込みが発生するため、Processor\Interrupts/Secカウンタ(青)、%Processor Timeカウンタ(緑)の値も増えている

また、送信だけでバイト数を確認する場合はBytes Send/Secカウンタ、受信だけでバイト数を確認する場合はBytes Received/Secカウンタがそれぞれ用意されている。

 

ボトルネックを特定したら…

ボトルネックを特定したら、もうひとつ確認してほしいことがある。それはボトルネックを発生させているプロセスの特定だ。明らかに特定のプロセスが原因でボトルネックを発生させているなら、そのプロセスを別のサーバーで動作させたり、または利用すること自体をやめてしまうなど、ハードウェアの増強に頼らない解決ができる。プロセスの特定を行うときはProcessオブジェクトのカウンタを利用するとよい。

具体的には次のカウンタを利用しよう。

 

・メモリのボトルネックをさらに追跡する場合 – Process\Working Set

Working Setカウンタはプロセスごとに利用しているメモリの量を確認するために利用する。インスタンスで特定のプロセスを選択できるので、ある程度疑わしいプロセスを選んでチェックしてみよう。例えば、特定のプロセスのメモリリークが問題になっているような場合であれば、画面13のようにメモリを使い続けるようなグラフになるはずだ。

画面13
画面13●Memory\Available MBtyesカウンタ(赤)だけで、メモリリークと判断するのは難しいが、Process\Working Setカウンタ(黒太線)を見れば、メモリ使用量が増え続けていることは明らかだ。

 

・プロセッサのボトルネックをさらに追跡する場合 – Process\%Processor Time

%Processor TimeカウンタはProcessorオブジェクトにも同じものがあるが、こちらはインスタンスでプロセスを選択すると、そのプロセスだけのプロセッサ使用率を表示してくれる。これを利用すれば、すぐにプロセッサを大量に使用しているプロセスを確認できる。

・ディスクのボトルネックをさらに追跡する場合 – Process\IO Data Bytes/Sec

ディスクI/Oの割合を表したカウンタがIO Data Bytes/Secである。他のカウンタと同様にインスタンスでプロセスを選択できるので、これを利用してディスクI/Oの多いプロセスを特定しよう。ちなみに、読み取りだけで追跡するときはIO Read Bytes/Secカウンタ、書込みだけで追跡するときはIO Write Bytes/Secカウンタがそれぞれ用意されている。

 

以上の操作により、ボトルネックとなっているプロセスを特定し、ソフトウェア的なアプローチで解決できれば、コストもかけずにハッピーエンディングを迎えることができる。しかし、決定的にハードウェアスペックが不足していて、プロセスを終了するなどというやり方では問題解決にはならない場合もあるだろう。そのときは、ハードウェアの増強による解決となる。コストのかかる解決法ではあるが、それでも、どのハードウェアに投資をすればよいか、あらかじめわかっているので、効率の良い投資ができるだろう。

 

次回は、Active Directoryのパフォーマンス計測を中心に実際に計測を行ってみます。
お楽しみに。

【101シリーズ】パフォーマンスモニタ徹底攻略 ~ 基礎編

今回から「101シリーズ」というのを作ってみました。
101シリーズでは、特定のキーワードや概念について、基本的なところを私なりの見立てで解説してみようというものです。
ちなみに、101というのは、USのテクニカルカンファレンスでよく見かける言葉で、基礎とか、「○○のいろは」などの意味があります。

今回は、今は無くなってしまった商用サイトに掲載されていたコンテンツから、パフォーマンスモニタについて取り上げてみたいと思います。

 

サーバーに求められるパフォーマンスとは?

私たちは、よく「パフォーマンスが悪い」などという言葉を使うが、パフォーマンスの善し悪しはサーバーとクライアントでは全く異なるものだ。

クライアントコンピュータの場合、ひとりの利用者が行う命令(処理)が早く実行できればよい。しかし、サーバーの場合、様々な利用者からの要求に答えなければならないため、ひとつの処理だけが早ければよいというものではない。ある決められた時間の中でどれだけの処理が実行できるかがパフォーマンスを判定する要素となる(図1)。このように、サーバーに求められるパフォーマンスは、クライアントと本質的に異なるものなので、パフォーマンス計測を行う方法も異なるのだ。

 

図1
図1●ひとつのタスク処理が早ければ「褒められる」クライアント(左)と、決められた時間内に多くのタスクを処理すれば「褒められる」サーバー(右)

クライアントコンピュータのパフォーマンス計測を行うときには、処理を行っている最中、つまり「今の状態」を見るので、タスクマネージャのCPU使用率やメモリ使用量などを見ることが多いだろう。しかし、サーバーのパフォーマンスを測定するときには、システムの繁忙期、閑散期など、様々な場面での「決められた時間の中での処理」が存在するため、ある特定の場面だけを見て判定するのは適切ではない。

 

パフォーマンスモニタを利用する

パフォーマンスモニタはパフォーマンスの測定を行うときに利用する、Windows Server標準の管理ツールである。パフォーマンスモニタは、現在のシステムパフォーマンスを確認するための機能と、「データコレクタ」と呼ばれるシステムパフォーマンスを計測する機能で取得したデータを表示する機能などから構成される(画面1)。

画面1
画面1●「サーバーマネージャ」からパフォーマンスモニタを開いた様子。パフォーマンスモニタはスタートメニューの「管理ツール」から開くこともできる。

パフォーマンスモニタで計測する項目をカスタマイズするときは、画面の+をクリックする。計測する項目は「オブジェクト」、「カウンタ」、「インスタンス」から構成されている(画面2)。

・ オブジェクト

オブジェクトは計測する項目の「ジャンル」を表す。オブジェクトには、メモリを計測するMemoryオブジェクトやハードディスクを計測するPhysical Diskオブジェクトなどがある。オブジェクトを選んで計測するように設定すると、オブジェクト内のすべての項目が計測対象となる。

・ カウンタ

カウンタはパフォーマンス計測を行う、具体的な項目である。例えば、ディスクの計測を行う場合、読み取りの計測と書き込みの計測という2つのニーズが存在する。どちらか片方だけ計測したい場合、Physical Diskオブジェクトを使うという大雑把な計測方法ではなく、Physical Diskオブジェクト内の特定のカウンタを使って計測すれば、読み取りだけ、もしくは書き込みだけ計測することができる。

・ インスタンス

選んだカウンタから、さらに細かく特定の項目だけ計測したい場合に利用するのがインスタンスである。例えば、CドライブとDドライブがあるディスクの読み取りパフォーマンスを計測するときに、Cドライブのパフォーマンスだけ計測したければ、インスタンスでCドライブを選択することができる。

 

画面2
画面2●カウンタの追加画面

また、「カウンタの追加」画面では計測を行うコンピュータを選択することができる。1カ所から集中的に計測できるので便利だが、ネットワークを介して行うので、ネットワークに関するパフォーマンスは正しく計測できなくなる点に注意したい。

 

パフォーマンスモニタの表示をカスタマイズする

ここまでの方法で、オブジェクトやカウンタを追加すると、パフォーマンスモニタの画面上に追加したカウンタの状態がリアルタイムで表示される。色分けで表示されるので、わかりやすいのだが、もっと見やすくするなら、次の方法を実践することをお勧めする。

・ スケールを合わせる

既定でパフォーマンスモニタのスケール(縦の目盛り)は0~100の範囲に設定されている。そのため、利用可能なメモリの容量(MB)を表すAvailable MBytesで計測した値が114MBだったりすると0~100の範囲に収まらなくなる。そのときは、カウンタを右クリックして「選択したカウンタのスケール設定」をクリックしよう。すると、0~100の範囲に収まるようにスケールが変更される。前述のAvailable MBytesの場合、114MBを0.1倍した数値(つまり11.4)に変換し、グラフに表示してくれる。

画面3-1

画面3-2
画面3●スケールを変更していない場合(上)はグラフの上に突き抜けてしまっているが、スケールを変更すると、範囲内にグラフが表示される(下)

・ グラフを強調する

パフォーマンスモニタに多くのカウンタを追加すると、グラフから参照したいカウンタを探すのが難しくなる。そのときは特定のカウンタを強調表示しよう。特定のカウンタを選んでCtrl+Hを押すと、そのカウンタが黒の太字で表示される(画面4)。

画面4
画面4●複数あるカウンタの結果も太字表示されると際だつ

 

データコレクタの活用

ここまで、パフォーマンスモニタでシステムパフォーマンスを確認する方法を見てきたが、サーバーのパフォーマンス測定する上で本当に知りたい情報は、「今の状態」ではなく、ある一定の期間の情報である。パフォーマンスモニタでリアルタイムにデータを追いかけると長期間での傾向をつかみにくくなる。そのため、データコレクタをパフォーマンス測定する方法が一般的になる。

データコレクタとは、パフォーマンス測定の結果をログとして記録する機能で、データコレクタで記録したいオブジェクトとカウンタを設定しておけば、自動的に記録を開始し、その内容を後からパフォーマンスモニタで図示することが出来る。

利用方法は次のとおりだ。

1.データコレクタセットの「ユーザー定義」を右クリックし、「新規作成」から「データコレクタセット」を新しく作成する。データコレクタセットはBasicテンプレートから作成する。

2.1.で作成したデータコレクタセットから「Performance Counter」のプロパティを開き、パフォーマンスモニタのカウンタを追加する(画面5)。カウンタの設定では「サンプルの間隔」を設定することができる。サンプルの間隔とは計測を行う間隔のことで、この間隔を短く設定すると、データコレクタのデータサイズが大きくなるので、そのことを踏まえて設定するとよい。

画面5
画面5●パフォーマンスカウンタの追加はカウンタ単位だけでなく、オブジェクト単位でも可能だ。

3.1.で作成したデータコレクタセットを右クリックして「開始」をクリックする。すると、2.で設定したカウンタが定期的に計測するようになる。停止も同様の操作で行える。開始と停止を自動化するときはデータコレクタセットのプロパティで設定することが可能だ。

以上の操作で記録すると、パフォーマンスモニタの画面に戻って、データコレクタセットのファイルを指定すれば(画面6)、データコレクタセットを開始していた間のデータが表示される。

画面6
画面6●パフォーマンスモニタからデータコレクタセットで作成したログを指定

 

パフォーマンスモニタの使い方が確認できたところで、次回は実際にパフォーマンスの計測を行ってみることにしよう。

.NET Framework 3.5 Featuresの追加

「無駄な時間を過ごしてしまった」

そんなトラブルに遭遇したのでシェアしておきます。
Windows Server 2012では、サーバーマネージャーから[役割と機能の追加]から
様々なツールをインストールできます。しかも、セットアップDVDなしでできます。
このことはWindows Server 2008のときから変わらないと思います。

しかし、サーバーマネージャーから.NET Framework 3.5の機能を追加するときだけは
Windows Server 2012のセットアップDVDが必要なのです。
image

何も考えずに、このまま進めると、こうなります。
image

このようなトラブルにならないように、役割と機能の追加ウィザードの確認画面で、セットアップDVDのsources\sxsフォルダー(2013年3月12日修正)を[代替ソースパスの指定]のリンクから指定する必要があります。
image

だけど、ウィザードをよく見てみると、「代替ソースパスを指定する必要がありますか?」と警告が出ています。
こうした警告をちゃんと見ない、私のような「せっかち」さんに、ありがちなトラブルですね。

Windows Server 2008 R2でWebDAVを構成する

Computerworld.jpさんで連載させていただいている、「IT管理者が押さえておきたいWindows Phone導入のツボ」で
ファイルサーバーにWebDAVを実装するという話が登場します。
ところが、WebDAVの実装は(難しくないけれど)面倒なので、こちらで実装方法の
ステップバイステップを記しておきたいと思います。

■概要 – WebDAV実装のためにやること一覧
1. 共有フォルダーを仮想ディレクトリとして登録
2. WebDAVオーサリングの有効化
3. オーサリング規則の追加
4. 基本認証の有効化

では、順番に見てみましょう。

 

1. 共有フォルダーを仮想ディレクトリとして登録

IISサイトを右クリックし、[仮想ディレクトリの追加]をクリックすると、
現在、共有フォルダーとして利用しているフォルダーをIISの仮想ディレクトリーとして登録できます。
また、ここで登録した仮想ディレクトリへのアクセス許可は、
共有フォルダ―のアクセス許可をそのまま踏襲します。

image

 

2. WebDAVオーサリングの有効化

WebDAV機能はサーバーマネージャーから追加しても、自動的には有効にならず、
WebDAVオーサリングの有効化という設定を行わなければなりません。
WebDAVオーサリングの有効化設定は、IISサイト(Default Web Site)を選択した状態から、
[WebDAVオーサリング規則]をクリックし、[WebDAVの有効化]をクリックします。

image

 

3. オーサリング規則の追加

[オーサリングの有効化]を行った、上の画面で、[オーサリング規則の追加]をクリックして、
WebDAVによるコンテンツの公開方法を設定します。

image

 

4. 基本認証の有効化

普通にWebDAVを公開する場合、Windows統合認証を利用するのが一般的だと思うのですが、
残念ながら、Windows PhoneではWindows統合認証が利用できません。
そのため、代わりに基本認証をIISで有効にし、Windows Phoneからのアクセスを受け付けます。
IISサイト(Default Web Site)をクリックし、[認証]をクリックして、
下の画面から基本認証を有効にします。

image

 

ここまでがWindows PhoneからWevDAV経由でファイルサーバーにアクセスするための
Windows Server 2008 R2側での設定になります。

■参考情報
http://learn.iis.net/page.aspx/350/installing-and-configuring-webdav-on-iis/