Active Directory 東北電力株式会社 運用事例

トピック

 はじめに
 目的
 総括
 Active Directory 構成
 ベンチマーク環境
 ベンチマーク結果
 まとめ
 付録

はじめに

東北電力は 2001 年2 月、同社のコミュニケーション プラットフォーム「WING」のコンピュータ14,000 台を全面的にWindows 2000 Professionalに置き換えました。WING は、メール システムから、OA アプリケーション、ホスト連携など、すべての社内情報を連携するための基盤となっているシステムです。今回設置したのは、クライアント パソコン約14,000 台と、サーバー9 台です。そこで東北電力にご協力いただき、運用時のドメインコントローラにどれだけ負荷がかかるのかを調査しました。
本ホワイトペーパーは、ユーザーのログオンにかかる時間、ドメイン コントローラのパフォーマンスおよびネットワーク トラフィックという実測値を記載しており、ドメイン コントローラの性能を決定する支援ツールActive Directory Sizer Tool導入時の参考にしていただけます。

本技術文書の製作にあたり、東北電力様、東北インフォメーションシステムズ様、栗菱コンピュータズ、富士ソフトABC様の多大なるご協力をいただきました事を心より感謝いたします。

マイクロソフト株式会社 コンサルティング本部 坂本 肇

 ページのトップへ

目的

東北電力では管理が煩雑になってしまった既存のWindows NTドメインを統合してユーザー アカウントを一括管理することを第一段階の目的として、Active Directory により複数の既存ドメインの統合を考えました。
しかし、Active Directory でユーザーを管理するために利用するサーバーは、どの程度のスペックが必要か検討する必要がありました。そこで、マイクロソフトがActive Directory 構築を支援するツールとして提供しているActive Directory Sizer Tool を利用し、14,000 クライアントを処理するためにサーバーに求められるスペックとドメイン構成に関する情報を算出しました。
Active Directory Sizer Tool は必要な情報を入力することにより、ドメイン モデル、サーバー推奨スペック、ドメイン コントローラ数、サイト構成など、Active Directory 構築に必要なデータの推奨値を提供します。東北電力は、この値を参考にドメイン コントローラの台数およびシステム構成を決定し導入して運用しています。本ホワイトペーパーは実環境におけるドメイン

コントローラの性能に関して調査し、測定された値を元にActive Directory Sizer Tool で算出された構成が妥当なのかどうかを検証することを目的として作成しています。

注) Active Directory Sizer Toolの詳細は、下記URLを参照して下さい

https://www.microsoft.com/downloads/details.aspx?FamilyID=77c0a895-3dfc-469f-be40-6a0ee594821c&displaylang;=en(英語)

 ページのトップへ

総括

• ドメイン構成は、シングルドメイン

• サイト構成は、シングルサイト

• ドメインコントローラ数は、4 台

という構成が推奨されました。東北電力はこの値を参考に、シングルドメインかつシングルサイトの構成でドメインを再構築することにしました。ドメインコントローラだけは、FSMO(Flexible Single Master of Operations) が設定されているサーバーの負荷を下げるために、算出された4台ではなく6台で運用しています。 2001 年2月に導入が完了し、実運用に入って半年を経過しています。そこで導入した6台のドメインコントローラが14,000 クライアントのログオン要求を受けている時間帯におけるサーバー パフォーマンスを測定しました。

14,000 クライアントを管理するドメイン コントローラの負荷測定をログオンが集中する7:30 ～10:00 の間にパフォーマンス モニタ、ネットワーク モニタなどを用いて調査しました。

• ユーザーがログオン処理にかかる時間

• ログオン処理時のサーバー負荷

• ログオン処理時のネットワークトラフィック

を対象に実施しました。 測定した結果、Active Directory Sizer Tool によって推奨された構成のドメイン コントローラで14,000 クライアントのログオン要求を十分処理していることが解かりました。

 ページのトップへ

Active Directory 構成

ドメイン規模のサイジング

Active Directory Sizer Toolを用いてサイジングする場合、下記の項目についてデータを入力する必要があります。

• ユーザー アカウント数

• クライアントPC 台数

• ユーザー オブジェクトへの追加属性

• 平均グループ数

• ピーク ログオン レート

• パスワード変更期間

• ユーザー オブジェクトへの追加ACE数

そこで東北電力は、表１に示すデータを用いてサイジングを行いました。

表 1 サイジングに利用した値

ユーザー アカウント数	15,000
クライアントPC 台数	15,000
ユーザー オブジェクトへの追加属性	25 属性 (Default値)
平均グループ数	25 グループ (Default値)
ピーク ログオン レート	15 回/秒(*)
パスワード変更期間	180 日
ユーザー オブジェクトへの追加 ACE 数	25 (Default値)

* ピーク ログオン レートの算出 ユーザー数×ログオン率÷15 (分) ÷ 60 (秒) その結果、表 2 に示す値がActive Directory Sizer Tool によって算出されています

表 2 サイジング結果

サイト構成	シングル サイト
ユーザー数	15,000
サーバー総数	4
CPU	450MHz
CPU 数	2CPU
メモリ数	256MB

FSMO が設定されているサーバーへの高負荷が想定されるため、FSMO サーバーの負荷低減やドメイン コントローラの冗長性を考慮し、ドメイン コントローラを 2 台追加して、全体で 6 台を配置して運用することにしました。

システム構成

ドメイン コントローラに用いるハードウェアのシステム構成は、Active Directory Sizer Tool の結果を参考に、富士通社製GRANPOWER モデル680 GP568M2P2 を6 台導入しています。システム構成の詳細は、表3に示す通りです。

Active Directory Sizer Toolの結果では、必要なメモリサイズは256MB という結果でしたが、実際には2GB のメモリを搭載しています。Active Directoryを導入したドメイン コントローラは既存環境をそのまま利用しており、従来のドメイン コントローラにはすでに2GB のメモリが搭載されていたため、メモリを減らさずにそのまま利用しているためです。

表 3 ハードウェアシステム構成

OS	Windows 2000 Server Service Pack 1
CPU	Pentium Ⅱ Xeon 450MHz
CPU 数	2CPU
メモリ	2 GB (EDO DIMM)
SCSI アレイコントローラ	UltraWide SCSI (GP5B144)
ディスク (システム)	18 GB (GP5 HDH87)×2 (RAID1)
ディスク (データ)	18 GB (GP5 HDH87)×8 (RAID0+1)
ディスクフォーマット	NTFS
ネットワーク	100BASE-TX/10BASE-T

※GRANPOWER モデル680 GP568M2P2

ドメインモデル

ドメイン モデルにはシングル ドメイン、マルチ ドメインの2種類のモデルを選択できます。東北電力では管理コストの削減、アカウントの一元管理がドメイン再構築のテーマのため、ドメイン モデルも管理が容易になるシングル ドメインを採用しました。

サイト構成

Active Directoryを導入する上で拠点数が多い場合、複数のサイトを構築して運用することが検討されます。

これは、

• 拠点同士のネットワーク トラフィックの軽減

• ログオン時間の短縮

• 冗長性

などを意識しているものですが、東北電力ではサイトを複数構成にせず、シングル サイトで運用しました。
既存のWindows NTドメインでは各拠点にドメインが分散していため、アカウント管理だけでも大変な管理コストを必要としていました。拠点ごとにドメイン コントローラを配置すると、管理者を配置する必要があります。管理者を配置せずリモートで管理する手段もありますが、ハードウェアに対するトラブルなどリモートで管理できない項目に関する管理コストを抑えられません。
東北電力ではネットワーク回線が既に高速化されており、遠隔地にいるユーザーがストレスなくドメインに参加できると考えました。
その結果シングルサイト構成を採用してActive Directoryドメインで利用するすべてのドメイン コントローラを電算センター一箇所に集約し、アカウントおよびサーバー管理を一元化した運用を実施しています。

ドメインコントローラ構成図
東北電力では、ドメイン コントローラ6 台のシングルサイト、シングル マスタ ドメインで構築されています。サイト内のみのレプリケーションで済むため、更新されたディレクトリ情報がすぐに反映されます。

ドメイン コントローラは6台のうち1台にFSMO機能を集中させ、それ以外はアカウント ドメインとして利用しています。
ドメイン コントローラは2つのセグメントに配置されており、効率よくログオンできる環境を構築しています。

図 1: 電算センター内ドメインコントローラ配置

名前解決

Active Directoryでは、ドメインとコンピュータの名前をDNS の名前付け規則に従って管理しています。ログオンする際などドメイン内にあるサーバーやクライアントにアクセスする場合、必ずDNS サーバーによって名前解決する必要があります。
東北電力では、従来のWindows NTドメインで名前解決する手段としてhostsファイルとlmhostsファイルをクライアントに配布していました。ドメインごとの規模が小さかったため、hostsファイルとlmhostsファイルで名前解決することが可能でした。今回はドメイン規模が大きくなってしまったため、hostsファイルとlmhostsファイルに登録するデータが増大することになりました。ファイル配布によるネットワークコストやファイルのメンテナンスにかかる管理コストも増大してしまいます。
名前解決する手段を提供しなければ、ネットワーク資源を利用できません。ドメインに参加しているクライアントがWindows 2000 Professionalだけであれば、名前解決の手段としてDNSサーバーを提供すればよいのですが、従来からのWindows 95 やWindows 98 などのクライアントが残っているため、これらのクライアントが名前解決する手段も提供する必要があります。
そこでローカル ドメイン用のDNS サーバーとWINS サーバーを新たに構築し、名前解決に利用しています。DNS サーバーは6 台すべてのドメイン コントローラ上で稼動させ、NetBIOS名を解決させるためにWINS サーバーも別マシン上に3 台導入しています。
導入したDNS およびWINS サーバーは、Windows 2000 Serverに標準で装備されているものを採用しています。

組織単位 (Organization Unit)

組織単位(OU) は、コンピュータ オブジェクトを管理するためのOU とユーザーを管理するためのOUの2つに分かれています。

コンピュータ オブジェクトを管理するためのOUには、

• クライアントOU

• モバイルOU

• サーバーOU

• プリンタOU

の４つがあり、リソースごとに分けて管理しています。それぞれのOU に本店、支店の8つがあり、クライアント マシンやプリンタなどそれぞれのネットワーク オブジェクトが登録されています。

ユーザーを管理するためのOU には東北電力におけるコンピュータの利用形態によって分類しており、トップに８つのOU が構成されています。

ネットワーク構成

東北電力では、図 2 に示すネットワーク構成を実現しています。拠点となる泉電算センター・連坊電算センター、本店および支店間は、ATM(非同期転送モード)で接続されており、135M の高速接続が実現されています。次に 7 つある支店と営業所間は ６M の速度で接続されています。その他に専用線(128K) を利用してサービスセンターと営業所を結んでいる拠点も存在しています。

図 2: 拠点間接続図

ソフトウェア構成

各ドメイン コントローラ上で稼動しているソフトウェアは、Windows 2000 Server以外にドメインの名前解決に利用するDNS Server、データのバックアップとしてコンピュータ アソシエイツ社製ARCserve Enterprise Edition、運用管理用の富士通社製System Walker Operation Manager, Centric Managerが稼動しています。

システム設定

パフォーマンスの向上を図るためページング ファイル設定の一部を変更しています。ドメイン コントローラに搭載されている2GBのメモリ サイズでページングが発生する確率は低いのですが、メモリダンプできるようにするためにページング サイズを実メモリより大きく確保しておく必要があり、ページング ファイルの設定をデフォルト設定から変更しています。設定値は、メモリ サイズの3 倍のページング サイズを確保しています。ページング ファイルは1 ドライブあたり2,048MB で３ つのドライブに対して設定しており、 ドメイン コントローラ上に合計6,144MB となっています。 ドメインコントローラはログオン処理が主機能であるため、アプリケーションの応答の設定を「バックグラウンド サービスを優先させる」に変更しパフォーマンスの向上を図っています。

ベンチマーク方針
ログオンを処理するドメイン コントローラが既存システム構成で十分なのかどうかを検証することを目的とし、Active Directory Sizer Toolにより示された情報との差異を検証します。

ベンチマーク範囲

ドメイン コントローラの性能評価を目的としているため、ドメイン コントローラの役割において重要なログオン処理における性能評価に焦点を合わせ、

• ログオン所要時間

• ドメイン コントローラごとのログオン数

• ネットワーク トラフィック

• CPU稼働率

• メモリ使用量

の5項目を対象としてデータを収集しています。

ログオン所要時間
ログオン所要時間のベンチマークを行う範囲は、ユーザーがログオンを実行した後、行われる下記の処理が完了するまでの時間を対象としています。

• ユーザー認証

• ドメイン ポリシーの適用

• OU ポリシーの適用

• ログオン スクリプト実行

それぞれの処理で用いられるオブジェクトやファイルサイズを表4に示します。

表 4 サイズ

オブジェクト	サイズ (バイト)
クライアント コンピュータGPO	741,688
ユーザーGPO	776,793
レガシー スクリプト (logon.bat)	8,651 (207ライン)

ドメインコントローラへのログオン数
各ドメイン コントローラのイベント ビューアに記録されたログオン ログを対象にログオン数を収集します。

ネットワークモニタの対象範囲
ドメインへのログオン処理時に発生するパケット(表5)を測定対象としています。

表 5 対象パケット

ETHERNET	SMB	IP
ICMP	UDP	NBT
TCP	DNS	MSRPC
NetLogon	R_Logon	LDAP

パフォーマンスモニタの対象範囲
パフォーマンス モニタによりモニタリング可能な下記のパフォーマンス オブジェクトを測定対象とし、CPU、メモリおよびページング ファイルの値を測定しています。

CPU

• Processor

• Server Work Queue

メモリ

• Server

• Memory

• PhysicalDisk

ページングファイル

• Paging File

• Memory

 ページのトップへ

ベンチマーク環境

利用ツール

ドメイン コントローラに関するベンチマークに使用するツールは、Windows 2000に標準で装備されているツールを用いました。

• イベント ビューア

• パフォーマンス モニタ

• ネットワーク モニタ

イベント ビューアは、ドメイン コントローラへのログオン数の集計、パフォーマンス モニタは、ドメイン コントローラのハードウェア的なパフォーマンスの測定、ネットワーク モニタではログオン時に占有されるネットワーク帯域を測定するために利用しています。

測定方法

ログオンの集中する7:30 から10:00 までの時間帯150分間を対象に、2日間測定しています。

各ドメイン コントローラ上にパフォーマンス モニタを起動し、7:30 から10:00 までの間をモニタリングしています。
ネットワーク モニタは、トラフィックが集中する時間帯である8:30 から9:00 まで1分間の測定を5分ごとに監視しました。

ログオン所要時間

クライアント ログオン所要時間は、6台のクライアント マシンを別途持ち込み、5分に1回ドメインにログオンして、ストップウォッチを用いて計測しています。

計測は、2日に分けて実施していますが、1日目と2日目では、計測時の条件が若干変わっています。

• 1日目 ログオンスクリプト実行時間を含む

  ログオン スクリプトが配布・実行されコマンド プロンプトが消えるまでの時間

• 2日目 ログオンスクリプト実行時間を含まない

  ログオン スクリプトを計測対象外として、デスクトップが表示されるまでの時間

パフォーマンスモニタ

ドメイン コントローラの稼働率は、ドメイン コントローラ6台でパフォーマンスモニタを使い、測定対象となったオブジェクトは、ハードウェアのボトルネックを検出するために重要となるProcessor、Memory、Server Work QueueおよびPhysicalDiskオブジェクトを中心に表6にあらわすオブジェクトを対象として測定しました。

表 6 パフォーマンスオブジェクト

オブジェクト名	対象カウンタ
Memory	Available Bytes Cache Byte Page Read/sec Pages/sec
Paging File	%Usage %Usage Peak
Process	Working Set(_total)
PhysicalDisk	Avg. Disk Queue Length Avg. Disk sec/Transfer
Processor	%Processor Time %User Time
Server Work Queues	Queue Length(0) Queue Length(1) Queue Length(Blocking

ネットワークモニタ

ネットワーク モニタを用いてネットワーク パケットを監視しました。測定対象となったパケットは表7に示すパケットになります。

ログオンが集中する8:30 から9:00 間に5 分間隔で約1分間のネットワーク トラフィックを測定しています

表 7 対象パケット

LDAP	R_LOGON	NetLogon
MSRPC	DNS	TCP
NBT	ICMP	IP
SMB	ETHERNET

 ページのトップへ

ベンチマーク結果

ログオン

ログオン ユーザーが最も多い時間帯は8:30 頃で、この時間帯に約10,000クライアントのユーザーがドメインにログオンしています。この時間帯のログオン時間はアクセスが集中している為、ログオンに最も時間がかかっています。

図 3: 時間帯別ログオン数

ユーザーがログオンに要した時間(ログオンスクリプトの実行時間を含まない)は、

• 最短ログオン所要時間 1秒

• 最長ログオン所要時間 26秒

• ログオン所要時間 平均6.2秒

という測定結果が出ています。

最長時間はログオンが集中する8:20 に計測された26 秒、最短時間はログオン数が最も少なくサーバー負荷の低い7:00～8:00、9:00～10:00の間に1 秒が記録されています。

図 4: 平均ログオン所要時間 (ログオン スクリプト実行時間を含まない)

また、ログオンスクリプトの実行時間を含めた場合にユーザーがログオンに要した時間は、

• 最短ログオン所要時間 12秒

• 最長ログオン所要時間 53秒

• ログオン所要時間 平均25.4秒

という測定結果が出ています。

最長時間はログオンが集中する8:35 に計測された53 秒、最短時間はログオン数が最も少なくサーバー負荷の低い10:00前で16 秒という数値が記録されています。

図 5: 平均ログオン所要時間 (ログオン スクリプト実行時間を含む)

ユーザーがドメインにログオンしている間にログオン処理を行うドメイン コントローラへの負荷を測定しメモリ、CPU、ページング ファイルへのアクセスおよびネットワーク トラフィックについてのデータを収集した結果、サーバーには次に示す負荷がかかっています。

ドメインコントローラへの負荷

今回実施したベンチマークの結果、メモリ容量、ページン グファイル、CPUへの負荷およびネットワーク トラフィックなどドメイン コントローラへの負荷に関する実測値を収拾できました。 CPUの処理能力ですが、Processorオブジェクトを用いて測定しました。
Processor\%Processor Time ですが最大39％、平均7.5% の測定結果が得られています。この値が持続的に85% を超えているようであればプロセッサを追加したり、負荷分散したりする必要がありますが、平均7.5%なので既存のCPUで十分です。
プロセッサの処理能力を測る上で測定する必要があるのがProcessor\%User Time とServer Work Queue\Queue Length です。
Processor\%User Time は 、ユーザー モードで消費されたプロセッサ時間をモニタするカウンタです。このカウンタが持続的に高い数値を示すようであればプロセッサを追加する必要があるのですが、測定結果は最大20.5%、平均3.8%と50% を超えることはありませんでした。50％以上の値が計測されていないので、既存構成で十分であることが伺えます。
最後にServer Work Queue\Queue Length についてですが、このカウンタはキューの長さをモニタするカウンタです。この値が一定期間4を超える場合、プロセッサに渋滞が発生している可能性があります。ベンチマークの結果はCPU0 とCPU1 ともに4 以上の値が記録されています。平均値やグラフを見ても一時的に４ を超えていますが平均0.03～0.04 と低い数値です。一時的に渋滞が発生している可能性はありますが、ほとんどプロセッサに渋滞は発生していないと考えられます。

表 8 Processor オブジェクトの測定値

カウンタ オブジェクト	最小値	最大値	平均
Processor\%Processor Time	0.503167	39.032	7.530833
Processor\%User Time	0.1955	20.52067	3.804667
Server Work Queue\ Queue Length (CPU0)	0	4.166667	0.037667
Server Work Queue\ Queue Length (CPU 1)	0	4.5	0.040167

メモリの空バイトを示すMemory\Available Bytes の値は、平均約1.4GB(1,376,324,927 Byte)の空き容量を示しています。この値が少なければメモリを追加する必要がありますが、この値を見る限り平均約1.4GB の空き容量が確保されています。メモリ使用量を計算すると約600MB のメモリが常時利用されていることになります。メモリ使用量をシステム ワーキングセットとプロセス ワーキングセットの観点から見てみます。システム ワーキングセットの合計サイズを示すMemory\Cache Bytes は、平均250MB前後です。プロセス ワーキングセットの値を示すProcess\working set の平均値は、430MBで、この2つの値の合計は約700MB という結果になりました。この結果から見てもメモリが充分足りていることが伺えます。Memory\Available Bytes から計算したメモリ使用量とワーキングセットの合計値には約100MB の差があります。これは、Process\working set の値が、プロセス間で共有されている使用量をプロセスごとにカウントしてしまうため、メモリの使用量が多くなってしまうのです。

コンピュータとネットワーク間の送受信バイト数を示すServer\Bytes Total/sec オブジェクトですが、持続的に最大値(965,020)の前後の値が計測されているのであればメモリを追加する必要があります。平均値(165,142)の前後で推移しており、持続的に高い数値が記録されていないので特に問題はありません。

Memory\Page Read/sec、Physical Disk\%Disk Time およびPhysical Disk\Avg. Disk Queue Length に関しては、一緒に見ることにします。Physical Disk\Avg. Disk Queue Length が増加する一方でMemory\Page Read/secが減少していない場合、メモリが不足している可能性が高いと判断できます。しかし計測した結果は、Physical Disk\%Disk Time およびPhysical Disk\Avg. Disk Queue Length の値が増加している時、Memory\Page Read/secの値は平均0.075とほとんど読み込まれていません。この結果から、メモリが不足していないことが得られています。3つの観点からメモリに関して調査を行いましたが、どの観点からも既存メモリサイズで不足しているような結果は得られていないため、メモリに関しては十分という結果になっています。

表 9 Memory オブジェクトの測定値

カウンタオブジェクト	最小値	最大値	平均
Memory\Available Bytes	1000000000	1378275328	1376324927
Memory\Cache Bytes	250067627	253054976	251528938
Process\Working set (_total)	419307520	421993131	421189390
Server\Byte Total/sec	1211	965020	165142
Memory\Page Read/sec	0.000	1.533	0.075
Physical Disk\%Disk Time	0.304	23.683	1.833
Physical Disk\Avg. Disk Queue Length	3536	9006	5648

メモリと密接な関係のあるページング ファイルの実測値ですが、%Usage の値を見ると平均1%未満、最大でも1%とほとんどページングが発生していないことがわかりました。Memory\Pages/sec とPhysical Disk\Avg. Disk sec/Transferの値の積が0.1 を超えるとディスクアクセス時間の10%以上がページングに使われていると言われていますが、この値は平均約0.003 となっています。メモリが十分なため、14,000クライアントのログオン処理を行う上でページングはほとんど発生していない結果となっています。

表 10 Paging File オブジェクトの測定値

カウンタオブジェクト	最小値	最大値	平均
Paging File\%Usage	0.998667	1.001	0.999333
Paging File\%Usage Peak	1.271667	1.271667	1.271667
Memory\Pages/sec	0.000	14.445	0.097
PhysicalDisk\Avg. Disk sec/Transfer	0.006	0.018	0.032

ネットワークの負荷

ドメイン コントローラに対するパケット量を5分間隔で採取したデータを時系列にグラフに表したものが図６です。

図 6: 時間帯別パケット量

これを見るとDC1(FSMO)とDC5に対するパケット量が非常に多いことがわかります。その他のドメイン コントローラに対するパケット量が低くなっており、ドメイン コントローラによって偏りが発生しています。 DC1(FSMO)が取り扱うデータを時系列に表したものが図７です。 今回のドメイン コントローラは、ログオン プロセスの中にWindows NT 4.0で使用していたログオン スクリプトなどの処理も含まれています。

図 7: プロトコル別パケット量

この中で目立つのはNBTとSMBです。 NBTはNetBIOS over TCP/IPの略です。これまでコンピュータ間の通信で使用されていたNetBEUIはルータを越えることはできません。同様にコンピュータとアプリケーションの間を取り持つNetBIOSも利用できなくなります。これによって、 Windows NetworkのインターフェースであるSMB(Server Message Block)による通信はできません。SMBはNetBIOSを使用してファイル共有やプリンタ共有などを提供していたため、これらを使用するアプリケーションが利用できなくなるのです。(図 8)

このためSMBをTCP/IPでラップして通信する方法が利用されるようになり、これがNBTです。ルータを越えることができないNetBEUIの代りにTCP/IPを使用することにより、ルータを越える通信でもSMBおよびNetBIOSが利用できるようになりました。 NBTとSMBが大量に発生するとログオンの障壁となってしまい、ドメイン コントローラの負荷増大につながることになります。特に、大量のログオンを受け付けるドメイン コントローラではNBTとSMBを減らす方策を立てる必要があります。

図 8: プロトコル階層

 ページのトップへ

まとめ

東北電力の大規模ドメインで 2 日間にわたり、14,000クライアントのログオン所要時間、ドメイン コントローラのパフォーマンス、ネットワーク トラフィックを対象にベンチマークを実施しました。その結果、ベンチマークの対象としたログオン所要時間は、実測から平均6.2秒でログオンが行われていることが確認することができました。また、ドメインコントローラのパフォーマンス測定の結果も導入したシステム構成で十分処理できているという結果を得ることができました。

その結果、Active Directory Sizer Toolにより試算されたサイト構成、ドメイン モデルやシステム構成を採用しドメイン構築を行っても充分処理が可能ということがいえます。しかし、ログオン処理数を減らすよう設定していたFSMOサーバーの負荷が高いこともわかりました。
このことからActive Directory Sizer Toolで出されるドメイン コントローラ数だけではなくFSMOを設定するサーバーは、別に用意する必要があることが伺えました。Active Directory Sizer Toolで推奨されたドメイン コントローラ数だけで運用していたら、このような結果にはならなかったかもしれません。 結果としてFSMOの部分に関して注意を必要としますが、Active Directoryドメインを構築する際にActive Directory Sizer Toolを用いて試算した値を元にドメイン構築を行っても、実運用で十分耐えうる結果が得られることが実証されたと言えるでしょう。 Active Directory Sizer Toolの値だけを鵜呑みにするのではなく、既存ドメインの状況調査が重要であるということも付け加えておきます。

既存ドメイン環境の調査では、

• ピーク時にどれだけのクライアントがログオンするのか

• 既存ドメイン コントローラへのログオン ユーザー数

• ネットワーク トラフィック

などのさまざまな項目を調査し、現状をきっちりと把握することが重要です。

東北電力では、これら既存ドメインに関する情報を正確に押さえた上で、Active Directory Sizer Toolによる理論値と照らし合わせ、システム構成をプランニングして導入しました。その結果、14,000クライアントを管理する大規模なActive Directoryドメインを問題なく運用できていると言えるでしょう。 最後にここで得られたデータはあくまでも東北電力の環境下での数値であり、必ずしも同等の結果が得られるわけではありません。自社の環境を十分に調査し、マシン導入の目安としてActive Directory Sizer Toolを使用することにより東北電力のような大規模ドメインを構築することが可能となります。

 ページのトップへ

付録

付録 A: ログオンに関するグラフ

時間帯別ログオン数

ログオン所要時間

付録 B: パフォーマンス データ (その 1)

CPUデータ (最大値、最小値、平均値)

ページング ファイル

付録 C: マシン別パフォーマンス

モニタ グラフ ドメイン コントローラ１(FSMO)

ドメイン コントローラ2

ドメイン コントローラ3

ドメイン コントローラ4

ドメイン コントローラ5

ドメイン コントローラ6

表 11 ログオン時間計測結果（1日目：ログオンスクリプト実行時間を含む）

	クライアント
時間	1	2	3	4	5	6	平均（秒）
8:10		15	17
8:15	30	13	22	17	30	49	26.8
8:20	31	32	37	30	33	23	31
8:25	20	22	19	26	30	28	24.2
8:30	23	21	26	21	29	42	27
8:35	27	24	24	20	53	32	30
8:40	17	30	27	27	35	27	27.2
8:45	24	19	15	26	26	35	24.2
8:50	19	27	29	27	31	21	25.7
8:55	19	19	16	27	32	25	23
9:00	17	19	25	20	31	40	25.3
9:05	27	26	33	26	43	43	33
9:10	20	13	22	26	26	26	22.2
9:15	28	24	21	28	24	29	25.7
9:20	19	21	13	25	25	21	20.7
9:25	25	22	22	24	22	21	22.7
9:30	25	27	17	19	22	22	22
9:35	28	22	12	17	30	21	21.7
9:40	27	29	19	22	26	26	24.8
9:45	18	28	19	21	28	24	23
9:50	16	25	27	25	22	22	22.8
9:55	25	26	18	18	24	24	22.5
10:00	36	39	27	36	41	33	35.3
平均	23.7	23.6	22	24	30.1	28.8	25.4
最大	36	39	37	36	53	49	41.7
最小	16	13	12	17	22	21	16.8

表 12 ログオン所要時間（ 2 日目ログオンスクリプト実行時間を含まない）

	クライアント
時間	１	2	3	4	5	6	平均（秒）
7:35	8	1	2	3	16	8	6.3
7:40	1	1	1	26	21	1	8.5
7:45	4	4	2	2	4	6	3.7
7:50	3	3	1	2	2	10	3.5
7:55	1	4	3	5	2	1	2.7
8:00	2	2	4	9	11	7	5.8
8:05	2	10	2	9	3	7	5.5
8:10	5	15	8	3	6	2	6.5
8:15	3	24	9	21	6	4	11.2
8:20	5	4	26	6	3	3	7.8
8:25	4	3	2	15	2	22	8.0
8:30	14	9	9	2	2	5	6.8
8:35	2	11	4	17	4	4	7.0
8:40	2	5	4	5	9	13	6.3
8:45	12	1	10	10	2	12	7.8
8:50	2	2	3	6	4	28	7.5
8:55	4	16	14	2	15	7	9.7
9:00	5	14	7	3	9	3	6.8
9:05	6	16	1	2	7	3	5.8
9:10	6	6	1	1	2	18	5.7
9:15	3	1	1	4	2	5	2.7
9:20	3	3	9	5	1	1	3.7
9:25	1	3	1	1	3	16	4.2
9:30	1	24	3	9	10	20	11.2
9:35	4	1	2	5	5	8	4.2
9:40	3	2	3	1	8		3.4
9:45	1	22	3	5	1	2	5.7
9:50	9	3	5	3	5	4	4.8
9:55	7	3	9	7	1	7	5.7
10:00	2	3	2	4	1	22	5.7
平均	4.2	7.2	5.0	6.4	5.6	8.6	6.2
最大	14.0	24.0	26.0	21.0	15.0	28.0	21.3
最小	1.0	1.0	1.0	1.0	1.0	1.0	1.0

 ページのトップへ