Microsoft Windows 2000 テクニカル リファレンス パフォーマンス チューニング ガイド
第 9 章 ‐ Active Directory サービスとチューニング
トピック
.gif "9.1 Active Directory の用語と構造"){kind=icon}
9.1 Active Directory の用語と構造
9.2 Active Directory の導入
9.3 Active Directory の管理
9.4 Active Directory のパフォーマンスに関する問題
9.5 Active Directory 複製
9.6 ネットワークの問題
9.7 Active Directory データベースのサイズと断片化
9.8 Active Directory アクティビティの監視
9.9 まとめ
Windows NT 環境のネットワーク管理者にとって、エンタプライズクラスのディレクトリサービスがないことは頭の痛い問題であった。ローカルエリアネットワーク (LAN) のような小さな環境なら、Windows NT のディレクトリサービスでもリソースを見つけるのはそれほど難しくなかった。デスクトップにある [ネットワークコンピュータ] を使えば、フォルダ、ファイル、サーバー、プリンタを見つけるのに不都合はなかった。このような小さな環境では、ユーザーとドメインを管理する仕事もドメインユーザーマネージャで簡単にできた。しかし、ネットワークが大きくなるにつれて、こうしたリソースを管理する大変さとドメイン関係の複雑さも増大したのである。
Windows 2000 Server と Active Directory サービスがリリースされたことで、管理者はエンタプライズネットワークのニーズに応えられるディレクトリサービスをようやく手に入れた。しかも、このディレクトリサービスは十分にスケーラブルであり、小さなネットワークの管理者も、そのパワフルな機能を利用できる。とはいえ、Active Directory サービスを導入することのマイナス面も考えておかなければならない。後述するが、サーバーをドメインコントローラとして稼働させることと複製トラフィックのオーバーヘッドが、サーバーリソースとネットワークリソースの両方に重い負担をかけることになる。
この章では、Active Directory サービスを導入する際の留意点を解説する。インストールの仕方と環境はみな違っているので、ここで考察するパフォーマンスの問題は、ある特定のネットワークを想定したものであることを承知しておいてほしい。たとえば、LANのネットワーク管理者が遭遇する問題と、複数のサイトと多数のドメインを持つワイドエリアネットワーク (WAN) の管理者が遭遇する問題は同じでない。後者に特有の問題としては、追加的なネットワークデバイス (ルーター、専用回線、ファイアウォールなど) の管理や Active Directory のデザインにかかわる問題 (グローバルカタログサーバーの配置、複製、リソースアクセスなど) がある。
Active Directory テクノロジは新しいものなので、初めに用語、構造、インストール、構成といった、Active Directory の基礎を説明しておきたい。これらの説明を読めば、Active Directory に対する自分の理解度をチェックできるし、このディレクトリサービスの根底にあるパフォーマンス問題について検討するきっかけにもなるだろう。たとえば、Windows NT ディレクトリサービスから Active Directory サービスにアップグレードするときに遭遇するパフォーマンス問題 -- たとえば、Active Directory サービスのニーズに応えられる、もっと堅牢なサービスを実行する必要があること -- を論じることになるだろう。この章の終わりの方の数節では、Active Directory サービスのパフォーマンスを実際にチューニングする方法を解説する。
9.1 Active Directory の用語と構造
この節では、ディレクトリサービスを構成するオブジェクトを記述するための用語を説明する。また、ディレクトリツリーの構造も説明する。Active Directory サービスのパフォーマンスをチューニングしようとするなら、ディレクトリサービスの用語と構造をどうしても理解しておく必要がある。もし自分の車のトラブルを診断しなければならないとしたら、燃料噴射システム、点火プラグ、配電器キャップといった部品のことを理解しているだけでなく、それらが自動車のどこに組み込まれていて、それぞれがどのように関係しているかということも理解している必要があるだろう。
どんなディレクトリサービスを扱うにせよ、ディレクトリツリーの構造を考えるときには、ある程度の複雑さを覚悟しなければならない。ディレクトリサービスの構造は「ディレクトリツリー」と呼ばれるが、これは作成されたディレクトリサービスがツリー状の構造を持つためだ。もしも名前空間内の Active Directory のアーキテクチャを見ることができたなら、ディレクトリツリーにルート (根) とブランチ (枝) とリーフ (葉) があることがわかるだろう。ディレクトリツリーは、後で取り上げるほかの要因とともに、ネットワーク上でのディレクトリサービスのパフォーマンスに影響を及ぼす。Active Directory サービスの背後にある構造と用語を理解すれば、ディレクトリサービスの各部分がどのように関係し、各部分のチューニングが Active Directory サービスの全体的なパフォーマンスにどう影響するかがわかる。
9.1.1 スキーマ
どんなタイプのディレクトリサービスでも、ディレクトリの情報モデルと構造は「スキーマ」の中に明確に定義される。Active Directory スキーマには、ディレクトリサービスに格納できるオブジェクトのタイプ、それらのオブジェクトに対して定義されている全属性、およびそれらのオブジェクトの間の関係についての定義が含まれる。さらに、Active Directory サービス内で使われる階層的な名前付けを制御する規則に関する情報も含まれる。Active Directory サービスをインストールすると、デフォルトのスキーマが組み込まれるが、これは Microsoft 管理コンソール (MMC) の [Active Directory スキーマ] スナップインで表示・変更できる。
9.1.2 オブジェクト
「オブジェクト」は、ディレクトリサービスの中で作成されるリソースまたはエンティティを記述する属性から成る。たとえば、アプリケーションはオブジェクトで表現することができ、オブジェクトは自分を記述するための属性を持つことができる。ユーザーを記述するオブジェクトの場合、ユーザーの氏名、ログオン ID、電話番号といった属性が考えられる。
9.1.3 スコープ
ディレクトリサービスを使っていると、「スコープ」という用語をよく目にする。ディレクトリサービスにおけるスコープとは、各ディレクトリサービスをどれだけのサイズまで拡張できるかを表すものだ。スコープから、そのディレクトリの中にどういうタイプのオブジェクトをいくつ作成できるかを判断できる。
1 つのディレクトリの中に、ネットワーク内でよく使われるリソースを表現したオブジェクトを作成することができる。たとえば、ユーザー、プリンタ、ファイル、ファイルサーバー、ドメインを作成できる。Active Directory サービスは 100 万個のオブジェクトを収容できる。これはたいていのエンタプライズネットワークのニーズに十分応えられる数である。
9.1.4 名前空間
「名前空間」もディレクトリサービスに関係する用語だ。すべてのディレクトリサービスは名前空間であり、Active Directory サービスもそうである。名前空間は名前を解決できる範囲を表す。名前空間の性質を考えるうえでは、電話帳がよい例となる。たとえば、John Fortune という人の電話番号を調べるものとしよう。まず電話帳をめくってラストネームの Fortune を探し、それからファーストネームの John を探せばよい。もし電話帳に載っていれば、これで John Fortune の電話番号にたどりつくはずだ。Active Directory サービスの場合、名前空間はオブジェクトの名前をオブジェクトそのものに対応付ける (解決する)。つまり、ディレクトリから FS1 というファイルサーバーを検索すると、その名前がファイルサーバーオブジェクト FS1 として解決される。
参考
Active Directory サービス内のオブジェクトを検索するというのは、要するに目的のオブジェクトを見つけて、その名前を解決するようディレクトリサービスに依頼することである。ここで Active Directory のパフォーマンスが重要になってくる。Active Directory サービスへの照会を必要とするユーザーは結果がすばやく得られることを期待する。たとえば、ユーザーが FS1 というファイルサーバーリソースを探していて、ディレクトリサービスが検索を行っている間ずっと処理中の砂時計を見ていなければならないとしたら、よい印象を持たないだろう。ユーザーたちにとっては印象がすべてだ。ネットワークが遅ければ、それはすぐさまあなた自身の評価に跳ね返ってくる。あなたの組織に合わせて Active Directory をデザインするときは、検索、追加、削除を考慮に入れておくことが大切だ。よく考えられた Active Directory デザインが、そのほかのパフォーマンスチューニングと相まって、パフォーマンスのよいディレクトリサービスが実現されるのである。この章では、ディレクトリサービスが遅くなるのを避けるための方法をいろいろと説明していく。
| Active Directory サービス内のオブジェクト属性 |
|---|
Windows NT ディレクトリサービス内のオブジェクトと違って、Active Directory のオブジェクトはそのオブジェクトについての詳細な属性を含むことができる。先ほどオブジェクトの説明のところで、ユーザーオブジェクトの属性としてどんなものがあり得るかを述べた。Active Directory サービスにはさまざまな拡張性があるが、その 1 つはディレクトリサービスに含まれているオブジェクトに対して新たな属性を追加できることだ。たとえば、ユーザーオブジェクトの属性として、ユーザーの入社日を保持する属性を作成できる。ディレクトリツリーをパーティションに分割することになれば、複数のパーティションに分散している情報の検索をスピードアップするため、グローバルカタログの使用を検討する必要がある。その際、各オブジェクトのどの属性をグローバルカタログの一部として格納したらよいかという問題も検討しなければならない。したがって、属性を作成するときには、ユーザーが属性に基づいてオブジェクトを検索するときにどんな属性が有用であるかをよく考えるべきだ。ディレクトリサービスのオブジェクトに多数の属性を追加すると、追加した属性によって Active Directory サービスの全体的なパフォーマンスが影響を受ける。たとえば、オブジェクトの属性が多くなるほど Active Directory データベースは大きくなるが、それによって複製に要する時間が長くなり、検索のパフォーマンスも低下する。なお、Active Directory データベースは NTDS.DIT という名前のファイルで、%SystemRoot%\System32 フォルダに置かれている。 |
9.1.5 コンテナ
コンテナは、Active Directory ツリー内に存在し、属性を含むという点で、オブジェクトに似ている。しかし、オブジェクトと違って、コンテナは 1 つのエンティティを表すものではない。コンテナはオブジェクトのグループおよびほかのコンテナを含むことができる。コンテナは共通するオブジェクトをグループ化する方法として利用できる。たとえば、部門別のプリンタを入れるコンテナを作成できる。
9.1.6 ツリー
ツリーはディレクトリサービスの設計図である。ツリーはディレクトリサービスのオブジェクトとコンテナの階層を表現している。また、ツリー構造内におけるノードとエンドポイントの所在も表現している。オブジェクトはエンドポイントと考えられる。コンテナはノードである。
9.1.7 名前
「名前」という用語が Active Directory サービスに関して使われるとき、これは単にディレクトリツリー内でオブジェクトを識別する名前を意味する。オブジェクトは識別名と相対識別名という 2 種類の名前を持つことができる。
識別名
識別名は、オブジェクト、オブジェクトが属するドメイン、および階層内でのオブジェクトの正確な位置を識別するために使われる。次に、ユーザーの識別名の例を示す。
/O=Internet/DC=com/DC=Microsoft/CN=Users/CN=John Fortune
この識別名の各要素の意味は次のとおりである。
O=Internet -- この識別名の属する組織はインターネットである。
DC=com -- インターネットの一部である識別名は net、org、gov、edu、com といったドメインコンポーネント (DC) を持つことができる。
DC= Microsoft - - 識別名は複数のドメインコンポーネントを持つことができる。たとえば、Microsoft には多数の部署があるので、ユーザーは Microsoft というドメインコンポーネントの一部であって、しかも Marketing というドメインコンポーネントの一部でもあり得る。その場合、識別名は次のようになる。
/O=Internet/DC=com/DC=Microsoft/DC=Marketing/CN=Users/CN=John Fortune
CN=Users -- ディレクトリツリー内のたいていのオブジェクトは CN (Common Name：共通名) を持っている。上記の例で言うと、Usersがこのコンテナの共通名である。
CN=John Fortune -- 実際のユーザーオブジェクトは共通名として識別される。
相対識別名
いちいち識別名を使うのは煩わしいという場合、ディレクトリツリー内のオブジェクトを相対識別名で識別することができる。前記の例で言えば、CN=John Fortune が相対識別名である。相対識別名の限界は、オブジェクトの属しているコンテキストがわからないということだ。同じコンテナの中で、2 つのオブジェクトが同じ相対識別名を持つことはできない。たとえば、Users の中にユーザーを作成する場合、2 人のユーザーを CN=John Fortune で識別することはできない。
ユーザープリンシパル名
管理者が Active Directory サービス内でオブジェクトを作成すると、ディレクトリサービスはそのオブジェクトを識別名で識別する。しかし、ユーザーにとって識別名を使うのはとても煩わしく感じるだろう。自分のユーザーオブジェクトやカラープリンタの識別名を正確に覚えているのは困難だ。そのため、Active Directory サービスは、管理者がプリンシパル名によってユーザーを識別できるようにしている。John Fortune を例にとると、jo.fort@microsoft.com といったプリンシパル名を使うことができる。ユーザーは識別名の代わりにプリンシパル名を入力してログオンできる。X.400 アドレス指定を使った電子メッセージ送信を行わなければならなかった者は誰でも、ユーザープリンシパル名のコンセプトを高く評価するだろう。実際のところ、識別名は名刺に記載するにも長すぎる。
連続名
Active Directory サービスの実際の構造を見てみると、ブランチ (枝) やその他の部分を備えたツリー状の構造が見える。この構造はディレクトリツリーと呼ばれる。ディレクトリ全体を展開すると、コンテナおよびコンテナ内のオブジェクトがいろいろな方向に枝分かれしているようすが見てとれる。それぞれのブランチは階層的に結合されたオブジェクトとコンテナから成っている。これらのブランチのいずれかを分離することによって、連続名と呼ばれるもの (たとえば marketing. Microsoft .com) を構成することができる。
9.1.8 ドメインツリー
Active Directory 環境をデザインするときは、これまでどおり組織の中に複数のドメインを作成する必要がある。その場合、ドメインツリーと呼ばれるものを作成することになる。そうなると、まず頭に浮かぶのは、それらのドメインの間で信頼関係を確立することではないだろうか。あなたが Windows NT とともに去ってくれることを願っていた、あの信頼関係である。しかし、安心してほしい。ドメインの概念はなくなっていないが、信頼関係を管理するという困難な部分はなくなったのだ。
ドメインツリーを作成するときには、すべてのドメインが共通のスキーマ (構成とグローバルカタログ) を共有する環境を作成する。ドメインツリーはまた連続的な名前空間を形成する。たとえば、ツリーのルートが .com なら、marketing.microsoft.com は microsoft.com の子ドメインである。ドメインツリー内のドメインは推移的および双方向の信頼関係を通して信頼関係を形成する。これはドメインフォレスト内の任意のドメインで認証することのできるユーザーに変換される (ドメインフォレストについては次項で説明する)。もはや、管理者が各ドメインのユーザーのために個々のユーザー名を作成する必要はない。
注意
信頼関係は 2 つのドメインの間で暗黙のうちに確立されるが、これはユーザーがフォレスト内のすべてのドメインに権利を持つという意味ではない。ユーザーの権利は、ユーザーがアクセスを必要とするドメインごとに管理者が割り当てなければならない。
9.1.9 フォレスト
フォレストとは、連続名を形成しないドメインツリーの集まりのことだ (図 9.1)。フォレストを構成するすべてのツリーは、スキーマ、構成、グローバルカタログなど、いくつかの共通要素を共有している。ドメインを連結させてドメインツリー (詳細については前項を参照) にすると、ドメインの連結に伴う管理負荷がなくなる。これは、ドメインツリー間で推移的な信頼関係が形成されるからだ。
.gif "perftune901")
9.1.10 サイト
これまで Exchange サーバーを管理してきた人にとって、「サイト」という用語は目新しいものではないはずだ。Exchange の場合、サイトは同じ LAN に含まれている 1 つ以上の Exchange サーバーのグループのことを指す。Active Directory サービスの世界では、これと似通った意味で「サイト」という用語が使われる。この場合、サイトは適切に接続された 1 つ以上の TCP/IP サブネットのことを指す (「適切に接続された」という意味は、データを 10Mbps 以上の速度で転送するということだ)。サーバーを分離して同じサブネット内に置くと、ディレクトリサービス内の情報の検索が速くなる。なぜなら、同じサイトにあるコンピュータどうしはネットワーク的に見て近い位置にいるからだ。サイト内のコンピュータどうしの通信は、信頼性が高く、高速で効率的である。ログオン時にローカルサイトを決めることは簡単である。なぜなら、ユーザーのワークステーションが自分のいる TCP/IP サブネットを既に知っており、サブネットは Active Directory サイトに直接変換されるからだ。よく考えられた Active Directory サイトは、LAN および WAN での不必要なトラフィックを減らすことに大いに寄与する。
9.1.11 パーティション
パーティションとは、ディレクトリの中で、ブランチの開始点からツリーの一番下まで (または新しいパーティションの縁まで) の部分を言う。いったんパーティションを作成すると、複製はパーティションラインに沿って行われるようになる。ディレクトリツリーの現在のサイズが大きすぎて管理しにくいと思ったら、パーティションの作成を検討するとよいだろう。パーティションを作成すると、一度に管理するオブジェクトの数が減るので、Active Directory サービスの管理が容易になる。
9.1.12 グローバルカタログ
Active Directory サービスのスコープと、ディレクトリサービス全体に格納できるオブジェクトの数とスコープがどのような関係にあるかは、既に簡単に説明した。また、パーティションがどのようなもので、それがディレクトリサービスの管理にどう役立つかについても触れた。何十万ものオブジェクトを持つディレクトリサービスは、もしそれらのオブジェクトがすべて同じパーティションに含まれているなら、管理がきわめて難しく、まったく実際的でない。
しかし、パーティションを作成すると、2 つのパーティションの間でディレクトリサービスデータを複製するという問題が、直ちにパフォーマンス上の問題となる。パーティションを作成したことで、ツリーの管理作業は全体として削減され、個々の Active Directory データベースのサイズは小さくなり、データの複製に要する時間も短縮されるが、2 つのパーティションの間で情報を複製するという問題が残っている。あるパーティションに置かれているユーザーが、別のパーティションに置かれているオブジェクトにアクセスするという状況では、それらのオブジェクトを情報の複製によって共有するしかない。Active Directory サービスは複製プロセスの一環としてグローバルカタログを作成する。
グローバルカタログには複数のパーティションのディレクトリサービスデータが書き込まれる。グローバルカタログは各オブジェクトのキー属性を格納するので、ユーザーがディレクトリツリーからオブジェクトを探す時間が短縮される。グローバルカタログに格納されるデフォルトの属性は Microsoft によって定義されているが、[Active Directory スキーマ] スナップインを使えば、それらの属性を自由に変更できる。したがって、グローバルカタログに実際に格納される属性を管理者が選べるわけだ。これで Active Directory サービスのさまざまな部分をひととおり説明し終わったので、次は Active Directory サービスをどう導入するかという問題を論じることにする。
.gif "ページのトップへ"){kind=icon}
ページのトップへ
9.2 Active Directory の導入
システムのどの部分をパフォーマンスチューニングするにしても、その部分の動作がよくわかっていなければならない。ここまで、Windows 2000 Server で遭遇するパフォーマンス上のいろいろな問題を考察してきたが、これらの問題はプロセッサボトルネックからファイルシステムのキャッシュまで広範囲にわたっていた。パフォーマンスにかかわる問題は、オペレーティングシステムのチューニングによって改善できるもののほか、建物に張り巡らされたネットワークケーブルに欠陥があるなど、OS 外の問題もあった。そして、それぞれの問題について、その背景や基礎知識を提供してきた。以下では、Active Directory サービスのインストール、構成、および管理について説明する。これらの説明を読むことで、Windows 2000 の新しいディレクトリサービスへの理解がいっそう深まるだろう。
注意
Active Directory サービスのインストールについて既によく理解している読者も、この節は読み飛ばさないでほしい。Active Directory サービスのインストールと Active Directory サービスへのアップグレードをここで取り上げているのは、パフォーマンスのチューニングと最適化に関係があるからだ。
9.2.1 Active Directory のインストール
Active Directory サービスのインストールに当たっては、考慮すべきパフォーマンス上の問題がいくつかある。まず第1に、その環境でどれだけのドメインコントローラを構成する必要があるのかを見定めなければならない。ドメインコントローラとして動作するサーバーには、種々のドメインコントローラサービスを実行するために一定の負担がかかることを忘れてはならない。Active Directory サービスが大きな負担をかけるリソースはプロセッサとディスクである。したがって、各サーバーをドメインコントローラとして構成するのは問題外であり、無用なオーバーヘッドを生むだけだ。一方、ドメインコントローラを 1 つだけにすると、ユーザーがディレクトリサービスに特定のリソースを照会したとき貧弱なパフォーマンスしか提供できない。ユーザーのログオンが速やかに行われない可能性もある。また、ドメインコントローラサービスに付き物のフォールトトレランスを提供する代替サーバーがないので、障害時のリスクも問題になる。
導入のヒント
自分の環境でドメインコントローラをいくつ用意するかを決めるに当たって、とり得るアプローチは 2 つある。その1つは、初めはドメインコントローラを少なめにしておくというものだ。それで Active Directory の応答が遅いと感じたら、既存のサーバーをドメインコントローラにすればよい。ただし、いったんサーバーをドメインコントローラとして構成すると、それをスタンドアロンサーバーに戻すことはできない。もう 1 つのアプローチは、初めから多めのドメインコントローラを用意しておくというやり方である。このやり方なら、応答が速くなるし、規模の拡大にも耐えられる。
Windows NT の世界を経験した人なら、程よい数のドメインコントローラの必要性を痛感しているだろう。Windows NT ディレクトリサービスでは、少なくともプライマリドメインコントローラ (PDC) が必須であった。また、冗長性とパフォーマンスを考えるなら、さらにバックアップドメインコントローラ (BDC) を設けることも必須と言えた。
注意
Windows 2000 と Active Directory サービスのもとでは、BDC はもはや存在しない。ドメインはドメインコントローラから成り、各ドメインコントローラは互いに対等であり、Active Directory サービスのもとでマルチマスタ関係を形成している。
クライアントとサーバーの数に比例してどれだけのドメインコントローラを構成すればよいかと問われても、確固とした答えがあるわけではない。サイトごと、環境ごとに違ってくる。ディレクトリサービスにひっきりなしに照会を行うクライアントがいるかもしれないし、朝早くログオンして、いくつかの文書を開き、終日そのまま作業を続けるクライアントもいるだろう。また、Active Directory サービスに依存するアプリケーションの数も考慮すべき要素である。各アプリケーションがおそらく Active Directory サービスに照会を行うだろうし、ツリーに対してオブジェクト情報の追加、削除、変更、削除を行うかもしれない。ドメインコントローラの数を決めるに当たっては、こうした要素をすべて考慮に入れることが大切だ。
さらに、現在のネットワークインフラストラクチャと、それが Active Directory 機能 (複製、ディレクトリ検索、Active Directory サービスへのアプリケーションの統合など) をサポートできるかどうかという点も検討しなければならない。「9.4 Active Directory のパフォーマンスに関する問題」では、Active Directory サービスでネットワークインフラストラクチャに何が要求されるか、そしてインフラストラクチャを最適化して Active Directory サービスをサポートできるようにするために何ができるかを解説する。
注意
Windows 2000 Server は Windows NT 3.x または 4.0 のドメインで共存できる。Windows NT ドメインの中で、Windows 2000 Server を PDC、BDC、またはスタンドアロンサーバーとして構成することができる。PDC または BDC として構成するときは、すべてのサーバーに同じルールが当てはまる。すなわち、サーバーが備える RAM 容量、ディスク容量、およびネットワークインターフェイスカードを考慮に入れるべきだということだ。これらの要素はどれも、ドメインの中で果たす役割に関してサーバーのパフォーマンスに影響を与える。これらの構成パラメータは、Windows NT ドメインディレクトリサービスから Active Directory サービスに完全に移行するときに特に重要になる。Active Directory サービスでは、より多くの RAM とより高速なプロセッサが要求される。というのも、このディレクトリサービスが環境内で重要な役割を果たすからだ。たとえば、Active Directory サービスはネットワーク上で既に構成されている LDAP (Lightweight Directory Access Protocol) ディレクトリサービスの代わりを果たすことができるが、そのためにデータベースのサイズが増加する。また、Windows NT にはまったくなかった属性とオブジェクトを新たに追加することができる。既存の Windows NT 3.x または 4.0 サーバーを Windows 2000 にアップグレードするときは、必ずハードウェア互換性リストをよく見て、既存のハードウェアが Windows 2000 と互換性があるかどうかを確かめてほしい。
アップグレードの問題
Active Directory サービスを既存の Windows NT 3.51 または 4.0 サーバードメインコントローラにインストールする場合は、アップグレードパスを選択する必要がある。サーバーをアップグレードすると、セキュリティアカウントマネージャ (SAM) が Active Directory サービスで必要とされる形式に変換され、それによって既存のユーザーとグループの情報が維持される。既存のサーバーをアップグレードするときには、アップグレードプロセスに必要なディスク領域があるかどうかを確かめてほしい。Windows NT ドメインと Active Directory サービスからの情報がサーバーに一時的に格納されるからだ。
Windows NT 3.51 から Windows 2000 と Active Directory サービスに直接アップグレードするのは避けた方がよい。Windows NT 3.51 での制限が、Windows NT 4.0 と Windows NT 4.0 Service Pack の組み合わせによって取り除かれるからだ。まず Windows NT 4.0 と最新の Service Pack にアップグレードし、それから Windows 2000 Server と Active Directory サービスへのアップグレードプロセスに進むべきだ。また、Windows NT 3.51 サーバーの現在のハードウェア構成にも注意を払う必要がある。なぜなら、Windows NT 3.51 と Windows 2000 Server とでは、ハードウェア要件が大きく異なるからだ。Windows 2000 Server のハードウェア互換性リストをチェックして、Windows 2000 Server と互換性があるかどうかを確かめてほしい。
インストールプロセス
Active Directory サービスのインストールでは、考慮すべき重要事項がいくつもある。インストールプロセスはさまざまなステップから成っている。また、ここで問題にしているのはパフォーマンスチューニングと最適化である。そのため、インストールについて詳しい情報を提供してくれる種々の情報源を参照することが大切だ。インストールプロセスの理解に役立つ情報源としては、オンラインヘルプ、Windows 2000 Server リソースキット、Microsoft Webサイトやその他のWebサイトがある。Active Directory サービスをインストールしたことのない人は、後述する手順説明に加え、これらの情報源を参照してほしい。インストールプロセスでミスを犯すと、元に戻せなくなることがあり、そうなると Windows 2000 Server を再インストールするしかない。
インストールをセットアップの最中にするか後にするか
Active Directory サービスのインストールは、Windows 2000 Server のセットアップ中に行うことも、Windows 2000 Server のセットアップ後に行うこともできる。オペレーティングシステムをインストールしなくても、Active Directory サービスを構成するために必要な情報がすべて得られるなら、セットアッププロセスの一環として Active Directory サービスを簡単にインストールできる。必要な情報は次のとおりである。
そのサーバーを参加させようとしているドメインの名前。
そのサーバーの静的 IP アドレス。
注意
Windows 2000 のセットアッププログラムは、ネットワーク上で IP アドレスをスニッフィングすることによって、サーバーへの IP アドレスの割り当てを試みる。セットアッププログラムはDHCP割り当ての IP アドレスを使うこともできるが、可用性を高めるために静的 IP アドレスを使ってサーバーを構成することをお勧めする。たとえば、サーバーをWebサービス用に構成してある場合、そのサーバーに新しい IP アドレスが割り当てられ、その情報をドメインネームシステム (DNS) が動的に更新できなかったときに、問題が発生するからだ。
ネットワーク上で既に構成されている DNS サーバーに関する情報、または Active Directory サービスと一緒に DNS サービスを同じサーバーで実行するつもりなら、構成情報。
ネットワークアダプタの種類 (Windows 2000 Server のプラグアンドプレイ機能がそれを検出できなかった場合)。
WINS サーバーの IP アドレス。そのドメインに属していなくて、DNS を使っていない Windows NT サーバーと通信する必要がある場合は、ネットワーク上の WINS サーバーのアドレスが必要になる。
この後は、サーバーの構成プログラムによる Active Directory サービスのインストールと構成のための手順を説明する。Windows 2000 Server の新規インストールの場合、ログオン後に [Windows 2000 サーバーの構成] プログラムが自動的に起動する。
Active Directory インストールの最初のステップは、そのサーバーとドメインに関して管理者権限を持つユーザー ID を使って、サーバーにログオンすることだ。その後、デスクトップにサーバーの構成プログラムが表示されるはずだ。もしログオン後にこのプログラムが表示されなければ、[管理ツール] フォルダから [サーバーの構成] を探してほしい。このプログラムを起動したら、ダイアログボックスの左ペインにある [Active Directory] をクリックする (図 9.2)。
.gif "perftune902")
サーバーの構成プログラムでは、Windows 2000 Server への Active Directory サービスのインストール方法を選ぶことができる。Active Directory サービスをインストールする場合、そのサーバーをネットワークの最初のドメインコントローラとしてセットアップするか、または追加ドメインコントローラとしてセットアップすることができる。あるいは、次のオプションも選択できる。
子ドメイン -- 既存のドメインのサブドメインを作成するつもりなら、[子ドメイン] を選択する。たとえば、microsoft.com のサブドメインとしてmarketing.microsoft.comを作成することができる。
ドメインツリー -- 前に作成したドメインフォレストのメンバとしてドメインをセットアップするときは、このオプションを選択する。このドメインは [子ドメイン] を選択したときと違って、子ドメインにならない。
フォレスト -- 新しいドメインフォレストを作成するときは、このオプションを選択する。このプロセスの終わりに作成される新しいドメインは、そのフォレストの最初のドメインツリーになる。
ここで次の手順を実行して、Active Directory サービスのインストールを開始できる。
サーバーの構成プログラムのウィンドウの一番下に [Active Directory ウィザードを開始します] とある。その [開始します] の部分をクリックする。
Active Directory のインストールウィザードが表示されたら、[次へ] をクリックする。
続いて表示される画面で、そのサーバーの役割を指定する。この例では [新しいドメインのドメインコントローラ] をクリックする。それから [次へ] をクリックする。
この例では新しいドメインツリーを作成するので、[新しいドメインツリーを作成] をクリックする。それから [次へ] をクリックする。
ドメインツリーの新しいフォレストを作成するか、既存のフォレストに参加するかのどちらかを選択できる。既存のフォレストに参加した場合、自分のドメインのユーザーが、そのフォレストのほかのドメインツリーにあるリソースにアクセスできるようになる。この例では [ドメインツリーの新しいフォレストを作成] をクリックする。それから [次へ] をクリックする。
続いて表示される画面で、そのドメインの完全な DNS 名を指定する。完全な DNS 名の 1 例は microsoft.comである。これでjo.fort@microsoft.comなどのユーザープリンシパル名を使うことができる。それから [次へ] をクリックする。
Active Directory サービスは下位互換性を持つため、Windows 2000 以前のサーバーやワークステーションを実行しているユーザーは NetBIOS 名を利用できる。なお、Active Directory のインストールウィザードによってデフォルトの NetBIOS 名が生成されるが、これは変更することもできる。それから [次へ] をクリックする。
注意
Windows 95、Windows 98、および Windows NT Workstation のクライアントは、コンピュータに適切なクライアントサービスがインストールされていれば、Active Directory のクライアントとして動作する。そうでなければ、これらのクライアントは Windows NT ディレクトリサービスのクライアントであるかのようにドメインにログオンすることになる。Windows NT ディレクトリサービスのクライアントとしてログオンした場合、新しい Kerberos 認証プロトコルを使用することができない。Kerberos 認証プロトコルは Windows NT LAN Manager (NTLM) 認証プロトコルよりも堅牢で安全なネットワーク認証プロトコルだ。また、Kerberos プロトコルは NTLM よりも高いパフォーマンスを提供できる。なぜなら、アプリケーションサーバーが認証のためにドメインコントローラに接続しなくてよいからだ。しかも、Active Directory サービスのもとで作成されるドメインの推移性により、ドメイン、ドメインツリー、またはフォレストの中のドメインコントローラでユーザーを認証することができる。
続いて表示される画面で、Active Directory のデータベースとログの格納場所を指定する。データベースは数百メガバイトからギガバイトレベルの大きさに簡単になってしまうものなので、十分な記憶領域がある場所を選択することが大切だ。格納場所を指定したら、[次へ] をクリックする。
参照
Windows 2000 Server のセットアップ CD-ROM の \Clients フォルダにディレクトリサービスクライアント用のインストールファイルが入っている。
前述のディスク領域に関する設定に引き続き、Sysvol フォルダが格納される場所についての指定画面が表示される。Sysvol フォルダはドメインのパブリックファイルのコピーが格納される場所だ。これらのファイルはドメインのほかのコントローラと共有される。Sysvol フォルダのデフォルトの場所は %SystemRoot%\SYSVOL である。
適切に構成された DNS サーバーを TCP/IP 設定の中で指定してあれば、Active Directory サービスのインストールが続行される。そうでなければ、Active Directory サービスに DNS サービスのインストールと構成を任せるか、あるいは自分でインストールする必要がある。[はい] を選択してから [次へ] をクリックする。
このドメインの一部になるかもしれない Windows 2000 以前のサーバーとの完全な互換性を維持したければ、このアクセス許可画面がきわめて重要な意味を持つ。このドメインに Windows 2000 以前のサーバーがある場合は、[Windows 2000 以前のサーバーと互換性があるアクセス許可] をクリックする。このドメインの一部になるのが Windows 2000 サーバーだけだとわかっている場合は、[Windows 2000 サーバーとのみ互換性があるアクセス許可] をクリックする。それから [次へ] をクリックする。
Active Directory 復元モードで使用するパスワードを指定し、[次へ] をクリックする。
続いて表示される画面に、ここまで指定してきた内容がまとめて表示される。設定内容を確認してから [次へ] をクリックする。もし変更したいものがあれば、[戻る] をクリックする。
これらの構成がサーバーに書き込まれる (図 9.3)。この処理にはいくらか時間がかかる。Active Directory サービスがインストールされて構成された後、インストールのDNS部分が完了する。
[完了] をクリックして、Active Directory サービスのインストールを完了し、コンピュータを再起動する。
.gif "perftune903")
ページのトップへ
9.3 Active Directory の管理
Windows NT では、ドメインユーザーマネージャという管理ツールが、Windows NT のもとでユーザーとグループを管理するための主要な方法だった。複数の信頼されるドメインを管理する場合にも、やはりドメインユーザーマネージャがドメイン管理の主要なインターフェイスだった。
「第 4 章 Windows 2000 でのパフォーマンス監視」では、パフォーマンスコンソールの [システムモニタ] MMC スナップインを使って実行できる種々の管理作業を学んだ。システムモニタはスナップインとそれに対応するプログラムの使い方を示すよい例だ。なお、MMC の利点としては (ほかにもあるが)、同時に複数のサービスを管理できること、そして管理を容易にするためにカスタム MMC を作成できることが挙げられる。Active Directory サービスは3つのスナップインを提供しており、それぞれが Active Directory サービスの特定の機能を管理するように作られている。これによって管理作業が個別のスナップインに分割され、Active Directory サービスの管理に対する論理的で構造化されたアプローチが可能になっている。以下では、Windows 2000 ネットワークに数多くの管理機能を提供するMMCスナップインについて説明する。これらのMMCスナップインには、[Active Directory ユーザーとコンピュータ]、[Active Directory サイトとサービス]、[Active Directory ドメインと信頼関係] がある。
9.3.1 Active Directory ユーザーとコンピュータ
Active Directory サービスの日常的な管理で最もよく使うのがこのスナップインだ。[Active Directory ユーザーとコンピュータ] スナップインでは、ユーザー、グループ、コンピュータ、コンテナといったオブジェクトを管理できる。また、オブジェクトとコンテナのアクセス制御リストやグループポリシーを修正することもできる。
9.3.2 Active Directory サイトとサービス
ドメイン、ドメインツリー、およびフォレストでの複製を管理するうえで、このスナップインは重要な役割を果たす。複製内容には、スキーマ、構成、ドメインのパーティションが含まれる。[Active Directory サイトとサービス] スナップインでは、サイトを作成することにより、ネットワークについての物理的な情報を Active Directory サービスに提供する (図 9.4)。Active Directory はこの情報を使って、ネットワーク全体にわたるディレクトリサービスデータの複製の仕方を決定する。サイト、サーバー、サブネットを作成することのほか、サイトリンクとサイトリンクブリッジを指定することもできる。
.gif "perftune904")
9.3.3 Active Directory ドメインと信頼関係
Active Directory サービスの追加とともにドメインの信頼関係という面倒なものもなくなったと思っている人がいるかもしれないが、残念ながらそんなことはない。しかし、ドメインの信頼関係を作成し保守することは、もはや気の遠くなるような作業ではなくなった。それには2つの理由がある。その1つは、Windows 2000 の同じツリー構造に含まれる複数のドメインの間で推移的な信頼関係が確立されるからだ。もう 1 つは、[Active Directory ドメインと信頼関係] スナップインを使って構成された信頼関係の使用により、管理者がコンソールツリーの中で任意のドメインおよびその一部として作成された任意の子ドメインを見ることができるからだ。こうして、管理者は各ドメインの間の信頼関係を簡単に確立したり、削除したり、保守したりすることができる。インターフェイスを通じて、複雑なドメインの信頼関係を論理的かつ系統的な形で把握できるだろう。
9.3.4 ADSI (Active Directory Service Interfaces)
Windows 2000 は、Active Directory 構成のための MMC スナップインとして数多くの有用な管理ツールを提供している。反復的な管理タスクは自動化することで作業量を減らすことができる。タスクを自動化することは管理者としての仕事のやり方を最適化することにつながる。管理者によっては、個別的な管理も含めて、ネットワークのあらゆる面を最適化しようとするだろう。彼らは環境を最適化するだけでなく、自分の仕事も最適化したいと考える。たとえば、ユーザーをドメインに追加する場合は、ユーザー ID をディレクトリツリーに追加するだけでは済まない。そのユーザーをグループに追加し、ホームディレクトリとコンピュータアカウントを作成し、プロファイル設定を指定しなければならない。
ここでは、ADSI (Active Directory Service Interfaces) について説明する。ADSI はアプリケーションが Active Directory サービスと対話できるようにするものだ。たとえば、ディレクトリサービスから情報を取り出し、何らかの処理を行ってから、その情報を SQL Server 7.0 データベースに追加するようなアプリケーションを書くことができる。また、VBScript でスクリプトを書き、ディレクトリツリー内のユーザーの属性にグローバルな変更を行うというタスクを自動化することもできる。
ADSI を通じて対話できるディレクトリサービスは Active Directory サービスだけではない。ADSIを使うと、同じアプリケーションでNetscapeのSuitespot、NetWare NDS (Novell Directory Service)、Windows NT 4.0 など、さまざまなディレクトリサービスとも対話できる。
開発者は新しい ADSI API を使うことで、アプリケーションを Windows 2000 Server ディレクトリサービスと対話させることができる。ディレクトリサービスとの対話は、Windows NT ディレクトリサービスで行っていたものよりずっと簡単になる。次に示す Visual Basic コードは、アクセス制御エントリ (ACE) アクセス許可をオブジェクトに追加するためのものだ。
' 注： オブジェクトを作成する資格が必要。
Dim TheObject As IADs
Dim SecDes As IADsSecurityDescriptor
Dim SecDes As New SecurityDescriptor
Dim Dacl As New AccessControlList
Dim Ace As New AccessControlEntry
' アクセス制御エントリ (ACE) を作成する。
Ace.AccessMask =0
Ace.AceType =1
Ace.AceFlags =1
Ace.Trustee ="cn=Groups,o="
' ACE をアクセス制御リスト (ACL) に追加する。
Dacl.AceCount =1
Dacl.AclRevision =4
Dacl.AddAce Ace
' ACL をセキュリティ記述子オブジェクトの随意 ACL (DACL)
' として設定し、デフォルト値に代わって DACL を使用する。
SecDes.Revision =1
SecDes.OwnerDefaulted =True
SecDes.GroupDefaulted =True
SecDes.DaclDefaulted =False
SecDes.SaclDefaulted =True
SecDes.DiscretionaryAcl =Dacl
' セキュリティ記述子を ADSI オブジェクトにアタッチする。
TheObject.Put "ntSecurityDescriptor ",SecDes
' ディレクトリサービスへの変更をコミットする。
TheObject.SetInfo
' プロパティをプロパティキャッシュに読み込む。
TheObject.GetInfo
' SecurityDescriptorオブジェクトを取得する。
Set SecDesc =TheObject.Get("ntSecurityDescriptor")
開発者は ADSI API のほかに LDAP C API も利用できる。ただし、LDAP C API は C/C++ プログラミング言語でしか使用できない。下位互換性を維持するため、Active Directory サービスは MAPI (Messaging API) もサポートしている。ところで、Windows 2000 のパフォーマンスチューニングを扱っている本で、なぜ Active Directory の API に言及するのか不思議に思われるかもしれない。しかし、パフォーマンスチューニングというのは、オペレーティングシステムの設定を調節したり、サーバーのメモリを増設するだけのことではない。タスクをより効率的に遂行したり、オペレーティングシステムの機能 (API など) を最大限に利用することも、やはりパフォーマンスチューニングに含まれる。上記のサンプルコードは ADSI API を使ってアクセス許可をオブジェクトに適用している。通常、このタスクを管理者が行うには、まずプログラムを起動し、ユーザーを見つけてから、アクセス許可設定をあちこちいじらなければならない。しかし、ADSI API を使用したアプリケーションを使えば、Active Directory サービスの検索と操作をもっとすばやく行える。アプリケーションによって情報が取り出されたら、次にそれを利用することができる。たとえば、ユーザーのデータを取得し、再面談の対象となっている従業員の登録データベースに追加する。そして、再面談の日程が決まったら、各人に電子メールを送るようにする。こうすれば、ディレクトリサービスから該当ユーザーを検索して情報をデータベースに入力する手間が省かれる。1,000 人、5,000 人、1 万人といったユーザーについて、こんな作業を手作業でやったらどうなるかを想像してほしい。
ページのトップへ
9.4 Active Directory のパフォーマンスに関する問題
データベースサーバーを扱っていると、サーバーのパフォーマンスが落ちたとき、そのことに容易に気付くだろう。ユーザーの実行するクエリの応答が遅くなったり、データベースの更新にやたらに時間がかかるようになる。一定期間にわたってデータベースのパフォーマンスが落ちることもある。データベース管理者なら、こうした現象はいずれもパフォーマンスの問題として一般的なものだということを知っている。この節では、Active Directory サービスを導入したときに起こる一般的なパフォーマンス問題をいくつか取り上げることにする。どんなときにパフォーマンスの問題が起こるのかがわかっていれば、ネットワークが遅いという苦情がユーザーたちから寄せられたときに正しく対処できるはずだ。
9.4.1 複製の問題
複製の問題は最も本腰を入れて取り組まなければならないパフォーマンス問題かもしれない。複数のサイトと複数のドメインにまたがる WAN の場合は特にそうだ。複製の問題は予測することが非常に難しい。なぜなら、ディレクトリサービス自体ではなく、ネットワークパフォーマンスの貧弱さに異常の原因があることが多いからだ。Active Directory 環境での複製の詳細については、「9.5 Active Directory 複製」を参照すること。
たとえば、Active Directory データを T1 を通じてグローバルサイトに複製している場合、その T1 を行き交うトラフィックがいつ元の状態に戻るか予測できるだろうか。もちろん、トラフィックが少なくなると思われる夜間の決まった時間に更新を行うようスケジュールすることはできるが、それでも予測が付くとは限らない。複製問題における最悪のケースは、問題に最初に気付いたのがユーザーたちである場合だ。ユーザーたちはヘルプデスクに電話をかけて、自分のサイトのドメインコントローラが更新されていないと訴えたりはしない。自分が気付いた問題 (あるはずのリソースが見あたらないなど) について不平を言うだけである。ネットワーク管理者はユーザーよりも問題をしっかり把握していなければならない。複製の問題に対処するため、ドメインコントローラをチェックし、更新情報の受信中かどうかを調べ、サイトリンクを確認し、サイト間でトラフィックがスムーズに流れていることを確認することが必要だ。ネットワーク全体でデータが間違いなく遅れずに複製されるようにするには、どのような方策がとれるのか、以下で考察する。こうした問題の多くはネットワークと Active Directory をうまくデザインすることで避けられる。
9.4.2 ディレクトリ検索
既に述べたように、ディレクトリツリーや、ドメインツリー、ドメインフォレストのデザインがよくないと、ユーザーがディレクトリを検索するときのパフォーマンスに影響を与える。何十万ものオブジェクトが含まれているディレクトリがある場合、ネットワークにボトルネックがあるなら、ツリーの中で遅れを生じさせる部分をチェックすることだ。複製の問題がユーザーに知れるまでには時間差があるが、ネットワーク上のリソースを見つけようとしているときの遅れは、すぐに問題になる。このような問題は、管理者とその管理するシステムにとって好ましくない。ディレクトリツリーを検索する際のパフォーマンスに影響する要素はいくつかある。こうした要素には、お粗末なネットワークデザイン、お粗末なディレクトリサービスデザイン、そして可用性の低いリソースがある。
お粗末なネットワークデザイン
この問題については「9.6 ネットワークの問題」でもっと詳しく解説する。ここでは、ユーザーの要求への応答のよしあしを左右する要素として、ネットワークデザインがきわめて大きなものであることを指摘しておきたい。たとえば、ユーザーによる単純なファイル要求でも、ネットワークが混雑していれば応答が遅くなる。ファイルと印刷の要求やクライアント/サーバーアプリケーションの応答の遅れによるのと同じ問題が、Active Directory サービスのパフォーマンスに影響を与える。Active Directory サービスと対話するというのは、本質的にデータベースを扱うことだ。そして、どんなデータベースにも言えることだが、応答時間はデータベースとネットワークのデザインに左右される。
お粗末なディレクトリサービスデザイン
お粗末なデータベースデザインが、ユーザーが Active Directory を検索 (照会) したときのディレクトリツリーの応答に影響を与えることは指摘した。データベース管理者は、インデックスを適所に作成すると、照会に対する応答時間が見違えるほどよくなることを知っている。また、データをどうやって取り出すかをよく考えずにテーブルを作成すると、墓穴を掘ることも知っている。
オブジェクトのアクセスにかかわる Active Directory のパフォーマンスを向上させる 1 つの方法は、コンテナとオブジェクトを最も論理的な場所に作成することだ。会社中のプリンタが集中している場所にコンテナを作成するのは最善のデザインとは言えない。プリンタが必ず部門別にアクセスされること、そしてプリンタのコンテナに達するまでツリー内を移動することでネットワークトラフィックが増えることがわかっているのなら、プリンタを部門ごとのコンテナの中に作成すべきだ。そうすれば、ユーザーは自分の部門のコンテナを探すだけでよく、プリンタを見つけるためにツリー内を移動する必要はない。
可用性の低いリソース
可用性の低いリソースと言われても、ちょっとわかりにくいかもしれない。これは基本的にいくつかの要因を指すものであり、「9.4.1 複製の問題」で述べたような複製の問題もその 1 つである。次のような状況を想像してみよう。ユーザーがファイルを探してディレクトリツリーファイルを検索したが、そのリソースは見つからなかった。そこでユーザーはあなたに問い合わせてきた。あなたはそのリソースがセカンダリドメインに置かれていて、複製が問題の原因かもしれないとわかっているので、後でもう一度試してみるようユーザーにアドバイスした。ユーザーはそのとおりにしたが、目的のリソースは表示されなかった。そこで何度も試してみた。こうして無用なネットワークトラフィックがサーバーにかかり、ユーザーのイライラも募る。1 つの問題 (たとえば複製) と取り組めば、ほかの要因 (たとえばリソースの可用性) を改善することにもつながる可能性があるのだ。このように、リソースの可用性にはいろいろな要因が関係しており、お粗末なネットワークデザインやディレクトリサービスデザインもその中に含まれる。これらの要因は、プリンタを見つけるといった単純なことで確認されることもあれば、近くのドメインを見つけるといった複雑なことによって確認されることもある。いずれにせよ、ネットワークのこれらのコンポーネントに関して十分に計画を練り、ユーザーが Active Directory サービスを快適に使えるようにすべきである。
参照
ドメインデザイン、サイトデザイン、組織単位 (OU) デザインなどの Active Directory 仕様を含めた詳細な Active Directory デザインに関して参考になる資料がいろいろある。こうした資料の多くは、Microsoft Press、オンラインホワイトページ、およびサードパーティから入手できる。
9.4.3 Active Directory サービスとアプリケーション
Microsoft の目標は、Windows 2000 のユーザーだけでなく、ネットワーク上のすべてのユーザーのニーズに応えるディレクトリサービスを作成することであった。Active Directory サービスは真に相互運用可能なものとして作られており、NetWare や UNIX などの多様なプラットフォームのユーザーがディレクトリツリーに接続できるようになっている。この目標に基づいて、Active Directory サービスは環境内での Windows 2000 の役割とサーバーで必要なリソースを拡大する。Microsoft はアプリケーションレベルでの認証とディレクトリサービス制御の必要性も認識していたので、開発者がさまざまなAPIを使用できるようにし、ディレクトリ対応アプリケーション、ディレクトリ対応管理、およびディレクトリ対応ネットワークを作成できるようにした。
Active Directory 対応アプリケーションのパフォーマンスの改善
アプリケーションが Active Directory サービスと対話するための方法については、「9.3.4 ADSI (Active Directory Service Interfaces) 」で既に説明した。ここでは、こうしたディレクトリ 対応アプリケーションのパフォーマンスを向上させるための方法を説明する。ただし、まず各タイプのアプリケーションが Active Directory サービスとの対話で何ができるのかを説明しておこう。
ディレクトリ対応アプリケーションの一般的な用途
ディレクトリサービス内のユーザーリソースを見つける。
Windows 2000 のサービスにアクセスするユーザーを認証する。
ユーザー指向の検索のためのインターフェイスを作成する。
ディレクトリサービススキーマをアプリケーション固有のデータ定義で更新する。
ディレクトリ対応管理の一般的な用途
アプリケーションと Active Directory サービスの間でディレクトリサービス情報を同期する。
ディレクトリサービスシステム情報を編集する。
情報を取り出して処理するために、Active Directory サービスに対して実行するレポートを生成する。
ディレクトリ対応ネットワークの一般的な用途
ユーザーの権限を調べるために、ディレクトリサービスへのネットワークリソースのアクセスを可能にする。
特定のネットワークリソースについての情報を公開する。
ネットワークリソースを検出し、各リソースについてのポリシーディレクティブを取得する。
上に挙げたことから、ディレクトリサービスからユーザーまたはリソースに関係する情報を検索することが重要だとわかるだろう。アプリケーションを開発し、アプリケーションの最適なパフォーマンスを実現するために、次のことができる。
独自の属性を使ってオブジェクトを検索する -- 開発者は、検索条件としてクラスを使ってオブジェクトの検索を実行するときに、Microsoft 独自の objectCategory 属性を使うことで得られる利点を認識すべきだ。objectCategory 属性は objectClass 属性と違ってインデックス付けされる。データベース内でインデックス付けされた情報はデータベースに対する検索スピードを高める効果がある。
使用言語に注意する -- Active Directory を使用するときは、SQL 言語ではなく、LDAP 言語を使用する。ただし、SQL Server 7.0 などのデータベースに直接読み書きするアプリケーションは別である。
可能な限りインデックス付けされた属性を検索する -- インデックスの話が何度も出てくるので、まるで SQL Server 7.0 のパフォーマンスチューニングに関する章を読んでいるような気がするかもしれないが、ついでにもう一度言わせてもらいたい。Active Directory サービスへのクエリを記述するときは、インデックス付けされた属性に対するクエリを記述するべきである。クエリの中でORを使うときは特にそうだ。しかし、クエリ文字列の途中または先頭にワイルドカードを使った場合は、インデックス付けによってパフォーマンスが向上することはない。
ページングを使ってネットワークリソースを節約する -- ディレクトリサービスへのクエリは、ことによるとネットワークを飽和状態にし、クライアントに負荷をかけすぎるかもしれない。したがって、ネットワークとクライアントへの負荷を軽くするために結果をページングした方がよいかもしれない。
グローバルカタログとドメインディレクトリを有効に利用する -- グローバルカタログ (GC) は Active Directory サービスに対する検索の応答性をよくするためのものだ。したがって、検索したい属性が GC に含まれているときには、必ず GC をコードの中で使うようにする。検索したい属性が GC に含まれていないときは、ドメインディレクトリに頼ればよい。
検索時に正しい名前を使用する -- Active Directory ツリー内のたいていのオブジェクトの名前付け属性として CN (共通名) が使われることを説明したが、すべてのオブジェクトでこの方法が使われるわけではない。OU (組織単位) や DC (ドメインコンポーネント) などのオブジェクトでは別の名前付け属性が使われる。オブジェクトの名前を検索条件としてオブジェクトを検索するアプリケーションを開発する場合は、そのオブジェクトで使われている名前付け属性を検索する必要がある。
Active Directory サービスに対して高いパフォーマンスを得られるようにアプリケーションをチューニングするときは、検索範囲を設定する、検索結果を並べ替える、属性名パラメータのみを返す、といったことも考慮するとよい。また、アプリケーションの中でオブジェクトを参照するときは、そのオブジェクトの GUID を使用すること。そうすれば、オブジェクトの名前が変更されたり、オブジェクトが移動されたりしても、追跡することができる。
以上、Active Directory サービスと対話するアプリケーションを書くときの注意点を述べた。適切なコーディングテクニックを使えば、アプリケーションと Windows 2000 Server の全体的なパフォーマンスを高めることができる。
ページのトップへ
9.5 Active Directory 複製
Windows 2000 環境における Active Directory サービスの動作の基本的なアーキテクチャは既に説明した。また、Active Directory テクノロジの紹介を通じて、インストールと構成のプロセスにも触れた。ここでは、Active Directory サービス下での複製について説明する。複製はディレクトリサービスの応答性とリソースの可用性に大きな影響を与える。
9.5.1 Windows NT 複製
Windows NT では、ディレクトリサービスデータの複製は緩慢なプロセスになることもあった。Windows NT ドメインで変更を行ったときは、それをセキュリティデータベースに直接マークし、その後で複製を行って、同じドメインのバックアップドメインコントローラ (BDC) に変更内容を反映させる必要があった。このような形の複製は「マスタ/スレーブ複製」と呼ばれた (図 9.5)。プライマリドメインコントローラ (PDC) がマスタとして振る舞い、すべての BDC がそのスレーブとなる。マスタ (PDC) の情報が更新されると、この情報は直ちに各スレーブ (BDC) に複製される。すべてのサーバーが同じ建物の中に置かれているような小さなネットワークや、建物どうしの間に高速の接続がある場合には、このアプローチで不都合はなかった。しかし、1 つまたは複数のマスタドメインに1万人以上のユーザーがいるような大きなネットワークになると、ディレクトリサービス複製が深刻な問題になってくる。
.gif "perftune905")
エンタプライズレベルのネットワークでは、BDC が大学構内や国内の各所に (ときには世界中に) 散在していることがあり、データの複製には、サーバーの数とサーバー間の伝送メディアに応じて数分間から数時間もかかることがある。データの複製の仕方を変更することはできないので、管理者は構造的な変更を考えることになる。たとえば、複製が広域にわたって (たとえば全国規模で) 行われる場合、新たなドメインを作成して、ある地域に置かれている BDC が、別の地域に置かれている PDC からの更新情報を待たなくて済むようにすることができる。
Windows NT でのこの複製問題に対処するためのもう 1 つの方法は、ネットワーク間の帯域幅を大きくすることだ。たとえば、サイト間で 56kbps の回線に代わって T1 回線を使用する。Windows 2000 と Active Directory サービスのもとでは、Windows NT 複製モデルは置き換えられる。違った形になる (分散ディレクトリ構造を利用する) が、引き続き複製は行われる。
Active Directory サービスでは、マスタ/スレーブ複製方式というアプローチがそっくり放棄され、代わりにマルチマスタ複製という方式が採用された。
9.5.2 マルチマスタ複製によるディレクトリ複製
Windows NT ディレクトリ複製のケースで見たように、ディレクトリサービスで使われる複製の方式が、そのままディレクトリサービスの有用性とパフォーマンスを (そしてある程度までスケーラビリティも) 左右する。ネットワーク管理者ができることはディレクトリサービスの展開の仕方に限られており、データ複製の遅れを恐れると、さらなる問題を引き起こす。
ディレクトリサービス複製に対する Windows NT のアプローチには多くの問題があったので、Microsoft は Windows 2000 を通じて Active Directory サービスのマルチマスタ複製を提供することにした。マルチマスタ複製とは、ドメインコントローラ間でディレクトリサービスデータを複製する効率的な方式である。Active Directory データベースの情報を更新すると、変更内容がほかのすべてのディレクトリコピーに自動的に複製される。1つのドメインコントローラから各サーバーに変更内容が送られることで生じる待ち時間はもはや存在しない。たとえば、Active Directory ツリーにユーザーを追加する場合、その操作を完了するとすぐ、ドメインコントローラにその変更が送られる。
注意
距離が差を生むことは、仕方のない事実である。Active Directory の変更が実際に行われたドメインコントローラから物理的に近いところにあるドメインコントローラは、離れたところにあるドメインコントローラよりも早く更新情報を受け取る。これは複製方式の限界によるものではなく、データがメディア上を伝送される速さによるものだ。ネットワークの問題に直接関係する複製の遅れについては、「9.6 ネットワークの問題」でもっと詳しく説明する。
マルチマスタ複製は、Active Directory 環境においてドメインコントローラ間で情報を複製するための中心的な方式だ (図 9.6)。しかし、マルチマスタ複製がディレクトリサービスデータを複製する唯一の方式ではない。たとえば、ユーザーのパスワード変更は、すべての管理者が日々行っていることだ。ユーザーが自分でパスワードを変更することもあれば、代わりに管理者が変更しなければならないこともあるが、どちらにしても、Windows NT では、その変更が直ちに複製されないという問題が常に存在した。ユーザーがログオフしてから再びログオンしようとして、新しいパスワードが有効になっていないことがときどきある。このあまりにありふれた問題は Windows NT のもとでの複製によるものだ。更新情報を受け取っていない BDC もあるために、ユーザーのログオンで偶発的に起こる現象である。
.gif "perftune906")
パスワードを変更したり、ログオンできるユーザーを制限するといった、通常は緊急を要する更新の場合、Active Directory サービスはマルチマスタ複製の代わりにプッシュ複製を使用する。変更の行われたドメインコントローラがプッシュ複製の発信元となり、変更内容を複製パートナー (ネットワーク上のほかのドメインコントローラ) に送信する。
9.5.3 更新の追跡
一時に数百、数千という複製が行われることもあるので、それらの更新を追跡するためのメカニズムとシステムがドメインコントローラに必要になる。Windows NT の場合、すべての更新を 1 か所から発信して、Windows NT ディレクトリサービスがタイムスタンプで更新を追跡できるようになっていた。現在保有しているデータベースのコピーよりもタイムスタンプが新しいことから、BDC は PDC から最後に送られてきた更新情報が最も新しいものであると確認できた。
Active Directory サービスとマルチマスタ複製モデルは、ほかの複製方式と違って、更新を追跡する主な手段としてタイムスタンプを使っていない。タイムスタンプは、複数のドメインコントローラがほかのドメインコントローラに更新情報を送った場合に矛盾を生じ得るものとしてよく知られている。後で述べるように、タイムスタンプは更新を追跡する最後の手段としてのみ使われる。
Active Directory サービスはタイムスタンプの代わりに更新シーケンス番号 (USN) を使って更新を追跡する。それぞれのドメインコントローラが、Active Directory サービスの各オブジェクトごとに一意の USN を格納する。USN とともにバージョン番号も格納される。オブジェクトに変更が行われるたびにバージョン番号が増やされる。こうして、バージョン番号は最新の更新が含まれているオブジェクトの指標として機能する。オブジェクトは各プロパティについて USN とバージョン番号を保持している。プロパティが更新されると、新しい USN が割り当てられ、バージョン番号が増やされる。
複製プロセスにおいて、ドメインコントローラは現在保有しているものより大きな USN を持つ変更に関して複製パートナー (ほかのドメインコントローラ) に更新情報を要求する。複製パートナーはこれを受けて、自分のディレクトリから該当するオブジェクトを探す。複製での衝突を避けるうえでバージョン番号は適当な方法だが、Active Directory サービスは起こり得るどんな形の衝突にも対応すべく、最後の手段としてタイムスタンプも使うことができる。
サイト間での複製は、コストが高くなることがある (図 9.7)。ドメインコントローラがどのように複製を行うかは、実際のネットワークトポロジによって違ってくる。LAN のように、サーバーどうしが同じサイトにある場合、複製は「サイト内」で行われる (サイトの定義については、「9.1.10 サイト」を参照すること)。それに対し、サーバーが複数のサイトに分かれて存在する場合、複製は「サイト間」で行われる。次の 3 つの項では、この 2 つのシナリオ (サイト内とサイト間) でそれぞれ複製がどのように行われるか、そして複製の方法がネットワークの全体的なパフォーマンスにどう影響するかを説明する。
.gif "perftune907")
9.5.4 サイト内複製
同じサイト内にあるドメイン間またはドメインコントローラ間で複製が行われるとき、これをサイト内複製と言う。なお、Active Directory サービスで言うところの「サイト」は、十分な帯域幅で適切に接続されたセグメントのことを指す。LAN 内のドメインがサイトの好例だろう。ドメインコントローラ間の帯域幅は大きい (10Mbps 以上)。この場合、コントローラは IP 上で RPC (リモートプロシージャコール) を使って情報をやり取りする。更新が同じサイト内で行われるので、複製の頻度はより高くなる。これは Active Directory サービスが送信に際して情報を圧縮しなくてよいためだ。このことは同時に、ドメインコントローラの CPU にかかる負荷を減らすことにもなる。
9.5.5 サイト間複製
複数のサイトの間で複製が行われるとき、これをサイト間複製と言う。サイト間の複製トラフィックは比較的低速のリンクを通じて送られるのが普通なので、Active Directory サービスは更新のやり方を調整する必要がある。サイト内複製と違って、サイト間複製ではスケジュールと圧縮が行われる。複製データを圧縮すると、ドメインコントローラの CPU に対する負荷が増大する。そのため、サイト間複製に関与するサーバーのプロセッサ速度を高める必要があるだろう。
サイト間複製は、管理者によってスケジュールされたプル複製として行われる。受信側のドメインコントローラが更新を要求し、ほかのドメインコントローラから更新情報をプルする (引き出す)。更新をスケジュールすると、時間を設定するための複製トラフィックが減少する。たとえば、真夜中から午前 4 時までは通常よりも多くの帯域幅が利用できるとすれば、その時間にだけ複製が行われるようにスケジュールするとよい。サイト間複製に関する設定はすべて [Active Directory サイトとサービス] MMC スナップインで行う。
サイト間複製で幹線トラフィックが効率よく流れるようにチューニングするもう 1 つの方法は、各サイトで複製トラフィックを処理するドメインコントローラを 1 つだけ指定することだ。こうすると、すべての複製トラフィックが 1 つのサーバー (ブリッジヘッドサーバーと呼ばれる) を通るようになる。この方法にはさまざまな利点がある。たとえば、ブリッジヘッドサーバー以外のドメインコントローラについては、CPU 速度を高めなくて済む。
9.5.6 グローバル Active Directory 複製 (エンタプライズネットワーク)
サイト間複製とエンタプライズネットワーク内での複製には、複製のやり方にいくつかの違いがある。エンタプライズネットワーク内の複製の場合、Active Directory サービスは構成コンテナとスキーマコンテナをすべてのコントローラに複製する。また、部分ドメインデータをグローバルカタログサーバーに複製する。構成とスキーマの情報をすべてのドメインコントローラに複製する結果、さらに多くのネットワークトラフィックが生じるので、このぶんのトラフィックを見込んで対策を講じるべきだ。次の節では、複製の効率化を図るうえで考慮しなければならないネットワーク構成について説明する。
ページのトップへ
9.6 ネットワークの問題
これまで見てきたように、複製の問題には、ディレクトリサービススキーマデザイン、サーバー構成、実際の複製設定など、さまざまな要素が関係している。「9.7 Active Directory データベースのサイズと断片化」では、Active Directory データベースサイズというもう 1 つの要素について考察する。この節では、ディレクトリサービスのパフォーマンスに直接影響を与える Active Directory 構成について論じることにする。
9.6.1 サイトリンク
Active Directory サービスにおける「サイトリンク」は、同じようなネットワーク接続が存在している領域を表す言葉である。たとえば、IPで接続された2つのサイトはWANリンクを形成する。サイトリンクにより、サイト間の複製に対するコストを決定できるので、複製を扱うときにはサイトリンクが重要になる。表 9.1 は、一般的なサイトリンクのコストをまとめたものだ。帯域幅の大きい接続ほど、コストが小さくなっていることに注意してほしい。
表 9.1 複製プロセスで利用される接続のコスト値
サイトリンク |
コスト |
|---|---|
バックボーンリンク |
1 |
T1 からバックボーン |
200 |
56 kbps リンク (フレームリレー) |
500 |
支社接続 |
1,000 |
コンチネンタルリンク (国際リンク) |
5,000 |
この表に示したサイトリンクとコストは単なる例である。作成する各リンクに自分で適当と思うコスト値を自由に割り当てることができる。この表でコンチネンタルリンクに 5,000 を割り当てたのは、このトラフィックを制限したいことが主な理由である。筆者の環境では、コンチネンタルリンクを通じて複製トラフィックを流すと、ほかのネットワークデータの妨げになり、ユーザーたちから見たネットワークパフォーマンスが悪化するおそれがあるからだ。
サイト間の複製トラフィックをパフォーマンスチューニングするもう 1 つの方法は、サイトリンクの推移性を利用することだ。サイト A がサイト B に接続されていて、サイト B がサイト C に接続されているとすると、サイト B のリンクを使って、サイト A からサイト C にデータを複製することができる。たとえサイト B にドメインコントローラがない場合でも、これは可能である。この接続のようすを図 9.8 に示す。エンタプライズレベルのグローバルネットワーク全体に Active Directory サービスを展開する必要がある場合、エンタプライズネットワークでの複製に利用できるサイトリンクをきちんと把握することで、ネットワークリソースとサーバーリソースを節約することができる。
.gif "perftune908")
サイトリンクブリッジ
サイトリンクブリッジはサイトリンクどうしを接続するために使われるもので、WAN の中でブリッジとルーターとして扱われる。サイトリンクブリッジを作成するのは、サイトリンクを通じた複製トラフィックをきめ細かく制御したいときだ。サイト間で推移性を無効にすることにより (サイトリンクはデフォルトでは推移性)、サイトリンクをグループ化して、サイトリンクブリッジにできる。こうすると、Active Directory サービスはブリッジに含まれる各サイトリンクのコスト値を使って最適なサイト間複製トポロジとスケジュールを決定する。
| ネットワークトポロジについて考慮すべきこと |
|---|
Active Directory サービスのプランニングでは、ネットワークトポロジをデザインするときに次の点に留意する。
|
サイトリンク |
コスト |
|---|---|
バックボーンリンク |
1 |
T1 からバックボーン |
200 |
56 kbps リンク (フレームリレー) |
500 |
支社接続 |
1,000 |
コンチネンタルリンク (国際リンク) |
9.6.2 Active Directory 複製トラフィック
Active Directory 情報をドメインコントローラ間で複製するのに要する時間を短縮するための方法をいろいろと見てきた。Active Directory のトラフィックを処理すべくネットワークをデザインするときには、さまざまなニーズのバランスをとる必要がある。当面の目標は、ディレクトリサービスの応答性を高め、ドメインコントローラ間での複製にかかる時間を短縮することだろうが、データができるだけ高速で複製されるように Active Directory サービスを構成した後、ネットワークを流れるデータが多すぎることに気付くかもしれない。ネットワーク上を大量のデータが流れているとわかったなら、効率を確保するためにいくつかの対策を講じることができる。最初のステップは、複製でどれだけの帯域幅が消費されているかを把握することだ。ときには、複製間隔の設定が不適切であるために多くの帯域幅が消費されていることもある。複製間隔を15 分ごと (デフォルト) から 4 時間ごとに変更すると、帯域幅の圧迫がいくらか改善されるかもしれない。
状況を分析した結果、複製間隔を大きくしても思ったほどユーザーに影響を与えないとわかるかもしれない。複製にはそれなりの負荷がかかるので、それをどの程度まで受け入れられるのかを見定める必要がある。
複製トラフィックの測定
Windows 2000 のパフォーマンスコンソールまたはネットワークモニタを使うと、Active Directory 複製トラフィックを測定することができる (ネットワークモニタのインストールと構成の詳細については、Windows 2000 のオンラインヘルプを参照)。パフォーマンスコンソールでは、NTDS オブジェクトと以下のカウンタを選択しなければならない。
注意
DRA はDirectory Replication Agent (ディレクトリ複製エージェント) の略語である。
DRA Inbound Bytes Total -- 受信した複製データの総バイト数。これは非圧縮バイトと圧縮バイトを合計したバイト数である。
DRA Inbound Bytes Not Compressed -- 発信元で圧縮されていない複製データのバイト数 (通常これは同じサイトの別のディレクトリシステムエージェント (DSA) から届いたことを意味する)。
DRA Inbound Bytes Compressed (Before Compression) -- 圧縮された受信複製データの元の (圧縮前の) バイト数。
DRA Inbound Bytes Compressed (After Compression) -- 圧縮された受信複製データの圧縮後のバイト数。
DRA Outbound Bytes Total -- 発信した複製データの総バイト数。これは非圧縮バイトと圧縮バイトを合計したバイト数である。
DRA Outbound Bytes Not Compressed -- 圧縮されていない発信複製データのバイト数 (通常これは同じサイトのDSAに送られたか、複製データが 50,000 バイト未満であることを意味する)。
DRA Outbound Bytes Compressed (Before Compression) -- 圧縮された発信複製データの元の (圧縮前の) バイト数。
DRA Outbound Bytes Compressed (After Compression) -- 圧縮された発信複製データの圧縮後のバイト数。
ネットワークモニタで複製トラフィックを測定するためには、まずレジストリを編集して、複製サーバーが使用するIPポートが動的ではなく静的な値となるようにしなければならない。それには、REGEDIT.EXE を実行し、次の場所まで移動する。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\TCP/IP Port
TCP/IP Port の値を 1349 (10 進) またはそのサーバーで有効な任意の値に編集することができる。レジストリの設定が終わったら、このポートを通過するすべてのトラフィックが測定されるようにネットワークモニタを構成する必要がある。
9.6.3 DNSサービス
Active Directory サービスはドメインネームシステム (DNS) と強く結び付けられている。Active Directory サービスは DNS をロケータサービスとして使用している。microsoft.com などの名前を 10.0.0.0 のような IP アドレスに変換するために使われるのがロケータサービスである。
注意
Microsoft の DNS サービスを使うのがよいか、それとも別の DNS 製品を使う方がよいか、という疑問がわくかもしれない。そこで、互換性やパフォーマンスの点で Microsoft の DNS サービスを選ぶ理由があるかどうかを検討してみよう。互換性の点に関しては、Microsoft DNS サービスを実行することに何の問題もない。なぜなら、Microsoft DNS サービスは RFC (Request for Comment) と BIND (Berkeley Internet Name Domain) に準拠した DNS 実装だからだ。Windows 2000 で使用できる DNS は、UNIX を含め、どんなプラットフォームやデバイスでも使用できる。しかし、管理とパフォーマンスの点で、ほかの DNS プラットフォームより Microsoft DNS サービスを選びたくなる理由がいくつかある。パフォーマンスについて言えば、Microsoft DNS サービスではサーバー間で DNS 情報を複製する時間が短縮される。Windows 2000 の DNS は、Active Directory サービス内で DNS データ記憶域を構成できるようになっている。そのため、Active Directory 複製を通じて DNS データを複製できる。この複製プロセスはゾーン転送 (ほかの DNS サーバーで使われている転送方法) より高速である。Windows 2000 Server に含まれている DNS サーバーサービスは Dynamic DNS (DDNS) をサポートしている。名前解決に DHCP と DNS を使っているコンピュータがあるなら、DNS サーバー内のそれらのレコードを管理するのは非常に面倒だ。なぜなら、各コンピュータのIPアドレスが頻繁に変わるからだ。Dynamic DNS は各 DHCP クライアントについてのレコード情報を自動的に更新してくれるので、管理上の負荷がかなり減るはずだ。なお、Windows 2000 DNS は Active Directory DNS 複製やゾーン転送をはじめ、さまざまな機能をサポートしており、Windows 2000 DNS を従来のDNS 構造に統合したり、Windows 2000 DNSの新しい機能を使って新しい DNS 構造を開発できるようになっている。
ページのトップへ
9.7 Active Directory データベースのサイズと断片化
「第 11 章 キャパシティ計画」ではキャパシティの計画について論じる。そこで解説しているように、実際のキャパシティ計画はパフォーマンスのチューニングおよび最適化と一緒に進められる。ネットワーク管理者は、全力を尽くし、どんな環境でも起こる自然な拡大に備えれば、ネットワークオペレーティングシステムやネットワークインフラストラクチャにおけるパフォーマンス上の問題を避けられることに気付くだろう。
今日サーバールームに入り、機器をちょっと点検しただけで、あなたとあなたの環境に求められるかもしれない要求に対して準備ができたと胸を張って言えるだろうか。たとえば、この6か月間ずっと未決になっていた新しいプロジェクトを経営陣がついに承認するかもしれない。このプロジェクトでは、まったく新しい場所が必要になり、現在の場所にも 20 人 (しかも要求の厳しいユーザー) の増員が必要になる。現在のスイッチに 20 人の増員をさばくだけの余裕があるだろうか。サーバーは別の場所からログオンしてくるユーザーをサポートできるように構成されているだろうか。
答えがどうであれ、前もって計画を立てていれば、これからやってくるかもしれない問題に対処する余裕はできる。ネットワーク環境に取り組むときと同様、Active Directory サービスでも細かい点によく目配りする必要がある。将来への備えが大切である。ディレクトリと基本的なオブジェクトとコンテナを作成するだけでは不十分だ。Active Directory サービスは強力なディレクトリサービスであり、強力なアプリケーションやツールの多くがそうであるように、入念に計画を練ることが必要である。
9.7.1 データベースのサイズ
Active Directory データベースのサイズは、データベース内のオブジェクトの数と、それらのオブジェクトに割り当てられた値の数に左右される。オブジェクトの数が等しい Active Directory データベースが2つあるとすれば、オブジェクトの値の数が多いデータベースの方が大きいはずだ。Active Directory データベースに 50 万人のユーザーが格納されていて、必須属性だけが設定されているとすると、そのデータベースサイズはおよそ 1.8 GB になる。これはドメインコントローラとグローバルカタログサーバーでかなり大きなディスク領域を占めることになる (GC にはデータベース全体が格納されるわけではない)。オブジェクトと各オブジェクトの値の数は、それぞれの環境のニーズによって大きく異なる。
ネットワーク管理者はデータベースのサイズをきちんと管理する必要がある。そうしないと、ディレクトリサービスの複製、ディレクトリサービスの検索、および管理全般に悪影響を及ぼす。Active Directory データベースのサイズを管理する方法としては、オブジェクトとその値を管理することに加え、データベースを最適化 (デフラグ) された状態に保つことがある。デフラグを計画的に行うためには、サービスを定期的に止めて、パフォーマンスを最適化する際に Active Directory サービスのサイズと状態を徹底的に調べることが必要だ。
9.7.2 データベースのデフラグ
Exchange サーバーを扱ってきた人なら、Exchange インフォメーションストアをときどきメンテナンスする必要があることを知っている。これにはデフラグも含まれる。デフラグとは、データベース内のデータ -- データベースへの書き込み方の性質上、時とともに断片化していく -- を整理し直すプロセスである。
デフラグされていないデータベースでは読み取りの待ち時間が長くなる。また、サーバーのハードディスクが無駄に消費される。データベースのデフラグはオンラインでもオフラインでも行える。
オンラインでのデフラグ
オンラインでのデフラグとは、ドメインコントローラでディレクトリサーバーサービスが実行されている状態でデフラグプロセスを実行することだ。オンラインでのデフラグは ESE (Extensible Storage Engine) を通じて一定間隔で自動的に行われる。ESE がデフラグを実行している間も、ユーザーはそのサーバーで認証を受けることができる。つまり、ユーザーはそのサーバーでディレクトリサービス情報を検索できるし、その間にサーバーが複製プロセスを実行することもできる。とはいえ、オンラインでのデフラグには弱点がある。それはデフラグプロセスで回復されるディスク領域がファイルシステムに解放されないことだ。サーバーのディスク領域が不足しているためにディスク領域の回復が急務になっている場合は、オフラインでのデフラグを行うべきである。
オフラインでのデフラグ
オフラインでのデフラグはディレクトリサービス復元モードで実行しなければならない。ドメインコントローラをディレクトリサービス復元モードにするには、そのサーバーを再起動して、F8 キーを押す。すると、次のような起動オプションが表示される。その中の 1 つが [ディレクトリサービス復元モード] である。
セーフモード
セーフモードとネットワーク
セーフモードとコマンドプロンプト
ブートのログ作成を有効にする
VGA モードを有効にする
前回正常起動時の構成
ディレクトリサービス復元モード (Windows 2000 DC のみ)
デバッグモード
通常起動する
注意
[ディレクトリサービス復元モード] を選択した後、サーバーは Windows 2000 Server を起動する。しかし、通常モードで再起動するまでドメインコントローラの役割は果たさない。ディレクトリサービス復元モードで実行する前に、Active Directory データベースの完全バックアップを実行して、修復が失敗した場合に備えてほしい。また、ディレクトリサービスの修復を実行する前に、テスト復元を行ってバックアップを検証するようお勧めする。なお、データベースを復元しなければならない場合は、障害が起こる前のデータベースを復元すること。
NTDSUTIL.EXE プログラム (%SystemRoot%\System32 フォルダに入っている) はデフラグオプションを実行し、NTDS.DITファイルを別のフォルダに書き込む。ファイルの作成が終わったら、元の NTDS.DIT ファイルをアーカイブしてから、デフラグされたファイルを NTDS フォルダに移動することができる。このとき、サーバーのハードディスク上に空き領域が増え、データベースファイルのサイズが小さくなっていることに気付くだろう。
ページのトップへ
9.8 Active Directory アクティビティの監視
この章では、Active Directory 複製を中心に、Active Directory サービスのパフォーマンスチューニングについて論じてきた。ディレクトリ複製パフォーマンスを悪化させる要因をいろいろ挙げたが、その中にはDNSサービス、ネットワークインフラストラクチャ、お粗末なディレクトリサービスデザインなどがあった。また、複製の問題を解決するための方法も説明した。パフォーマンス上の問題を引き起こす可能性のある問題は何でも、早期に発見して解決することが大切だ。
あいにく、Active Directory 複製に問題があっても、なかなか気付かないこともあるだろう。ディレクトリにあるはずのオブジェクトがユーザーに表示されないとか、何かのオブジェクトが更新情報に含まれていないといったこと以外、ドメインコントローラがディレクトリ更新情報を受け取りそこなったことを示す徴候が早いうちに現れることはない。認証をディレクトリサービスに頼っている限り、どんなオペレーティングシステムツールにとっても、リソースアドバタイズ、リソース管理、データベースの同期がきわめて重要になる。次に紹介するツールを使うと、同期がとれているかどうかを確かめるために、ドメインコントローラ間での Active Directory サービスの複製の状態を監視することができる。
repadmin は Active Directory サービスに対する強力なコマンドラインインターフェイスである。これを使用するためには、Windows 2000 サポートツールをインストールしなければならない。サポートツールのセットアップファイルは Windows 2000 Server のセットアップ CD-ROM の\SUPPORT\TOOLS フォルダに入っている。SETUP.EXE プログラムを起動すると、サポートツールのインストールが開始される。repadmin ツールは \PROGRAM FILES\SUPPORT TOOLS フォルダにインストールされる。
オプションを付けずに repadmin と入力すると、次のように表示される。
Usage: repadmin <cmd> <args> [/u:{domain\\user}] [/pw:{password|*}]
Supported <cmd>s & args:
/sync <Naming Context> <Dest DSA> <Source DSA UUID> [/force] [/async]
[/full] [/addref] [/allsources]
/syncall <Dest DSA> [<Naming Context>] [<flags>]
/kcc [DSA] [/async]
/bind [DSA]
/propcheck <Naming Context> <Originating DSA Invocation ID>
<Originating USN> [DSA from which to enumerate host DSAs]
/getchanges NamingContext [SourceDSA] [/cookie:<file>]
/getchanges NamingContext [DestDSA] SourceDSAObjectGuid
[/verbose] [/statistics]
/showreps [Naming Context] [DSA [Source DSA objectGuid]] [/verbose][/unreplicated] [/nocache]/showvector <Naming Context> [DSA] [/nocache]/showmeta <Object DN> [DSA] [/nocache]/showtime <DS time value>/showmsg <Win32 error>/showism [<Transport DN>] [/verbose] (must be executed locally)/showsig [DSA]/showconn [DSA] [Container DN | <DSA guid>] (default is local site)/showcert [DSA]/queue [DSA]/failcache [DSA]/showctx [DSA] [/nocache]
Note:- <Dest DSA>, <Source DSA>, <DSA> : Names of the appropriate servers
<Naming Context> is the Distinguished Name of the root of the NC
Example: DC=My-Domain,DC=microsoft,DC=Com
次の例では、あるドメインコントローラに対して repadmin コマンドを実行して、ディレクトリサービス内に新たに作成されたユーザーに関して、現在このドメインコントローラにある複製値を調べている。複製の問題に正しく対処するには、このコマンドをネットワーク上の各ドメインコントローラに対して実行する必要がある。そしてドメインコントローラ間で複製値を比較すれば、すべてのドメインコントローラが同じ複製値を持っているかどうかを確認できる。
この例では、調べたいユーザーオブジェクトが FortuneJ なので、コマンドラインは次のようになる。
repadmin /showmeta "CN=FortuneJ,OU=Finance,OU=Accounting,DC=EASTCOAST,
DC=microsoft,DC=com " ACC1
CN=FortuneJ はユーザーに割り当てられたユーザー名で、OU=Finance は所属している組織単位で、OU=Accounting は組織単位の階層の一部である。DC=EASTCOAST、DC=microsoft、DC=com は、このオブジェクトの完全修飾ドメイン名を構成する要素である。コマンドラインの最後の部分では、このコマンドの対象となるドメインコントローラを指定している。このコマンドラインを実行すると、次のような結果が表示される。
Loc.USN Originating DSA Org.USN Org.Date/Time Ver Attribute
1639 Luxembourg \EMBY 1639 1999-04-23 15:29.37 1 objectClass
1639 Luxembourg \EMBY 1639 1999-04-23 15:29.37 1 cn
1639 Luxembourg \EMBY 1639 1999-04-23 15:29.37 1 sn
1668 Luxembourg \EMBY 1668 1999-04-23 15:37.12 1 c
1668 Luxembourg \EMBY 1668 1999-04-23 15:37.12 1 l
1668 Luxembourg \EMBY 1668 1999-04-23 15:37.12 1 st
1706 Luxembourg \EMBY 1706 1999-04-23 15:38.39 1 title
1667 Luxembourg \EMBY 1667 1999-04-23 15:37.12 2 description
1668 Luxembourg \EMBY 1668 1999-04-23 15:37.12 1 postalCode
1667 Luxembourg \EMBY 1667 1999-04-23 15:37.12 1 physDevOffName
1667 Luxembourg \EMBY 1667 1999-04-23 15:37.12 1 telephoneNumber
1639 Luxembourg \EMBY 1639 1999-04-23 15:29.37 1 givenName
1639 Luxembourg \EMBY 1639 1999-04-23 15:29.37 1 instanceType
1639 Luxembourg \EMBY 1639 1999-04-23 15:29.37 1 whenCreated
1640 Luxembourg \EMBY 1640 1999-04-23 15:29.37 1 displayName
1668 Luxembourg \EMBY 1668 1999-04-23 15:37.12 1 streetAddress
1776 Luxembourg \EMBY 1776 1999-04-23 16:32.44 2 NTSecurityDescriptor
1851 Luxembourg \EMBY 1851 1999-04-23 17:06.09 2 wWWHomePage
1639 Luxembourg \EMBY 1639 1999-04-23 15:29.37 1 name
1649 Luxembourg \EMBY 1649 1999-04-23 15:29.38 3 userAccountControl
1640 Luxembourg \EMBY 1640 1999-04-23 15:29.37 1 codePage
1668 Luxembourg \EMBY 1668 1999-04-23 15:37.12 2 countryCode
1704 Luxembourg \EMBY 1704 1999-04-23 15:38.19 2 homeDirectory
1704 Luxembourg \EMBY 1704 1999-04-23 15:38.19 2 homeDrive
1641 Luxembourg \EMBY 1641 1999-04-23 15:29.37 2 dBCSPwd
1640 Luxembourg \EMBY 1640 1999-04-23 15:29.37 1 scriptPath
1640 Luxembourg \EMBY 1640 1999-04-23 15:29.37 1 logonHours
1640 Luxembourg \EMBY 1640 1999-04-23 15:29.37 1 userWorkstations
1641 Luxembourg \EMBY 1641 1999-04-23 15:29.37 2 unicodePwd
1641 Luxembourg \EMBY 1641 1999-04-23 15:29.37 2 ntPwdHistory
1641 Luxembourg \EMBY 1641 1999-04-23 15:29.37 2 pwdLastSet
1640 Luxembourg \EMBY 1640 1999-04-23 15:29.37 1 primaryGroupID
1643 Luxembourg \EMBY 1643 1999-04-23 15:29.37 1 supplmntlCredentials
1640 Luxembourg \EMBY 1640 1999-04-23 15:29.37 1 userParameters
1669 Luxembourg \EMBY 1669 1999-04-23 15:37.12 2 profilePath
1639 Luxembourg \EMBY 1639 1999-04-23 15:29.37 1 objectSid
1776 Luxembourg \EMBY 1776 1999-04-23 16:32.44 1 adminCount
1640 Luxembourg \EMBY 1640 1999-04-23 15:29.37 1 comment
1640 Luxembourg \EMBY 1640 1999-04-23 15:29.37 1 accountExpires
1641 Luxembourg \EMBY 1641 1999-04-23 15:29.37 2 lmPwdHistory
1639 Luxembourg \EMBY 1639 1999-04-23 15:29.37 1 sAMAccountName
1639 Luxembourg \EMBY 1639 1999-04-23 15:29.37 1 sAMAccountType
1639 Luxembourg \EMBY 1639 1999-04-23 15:29.37 1 userPrincipalName
1704 Luxembourg \EMBY 1704 1999-04-23 15:38.19 1 userSharedFolder
1639 Luxembourg \EMBY 1639 1999-04-23 15:29.37 1 objectCategory
1667 Luxembourg \EMBY 1667 1999-04-23 15:37.12 1 mail
1705 Luxembourg \EMBY 1705 1999-04-23 15:38.39 1 homePhone
Active Directory サービスが USN 番号に基づいて更新を追跡することは既に説明した。上記の出力を見るとわかるが、各属性 (右端の欄) に確かに USN 番号が付けられている。たとえば、homePhone 属性に変更を加えたとすると、次に repadmin コマンドを実行したとき、USN 番号が 1 だけ増加していて、それと一緒にタイムスタンプも変更されていることがわかるはずだ。
ページのトップへ
9.9 まとめ
Windows 2000 Server のパフォーマンスに影響を与える要因はたくさんある。本書では、Windows 2000 Server とそれを実行する環境に最も効果的と思われることを述べている。Active Directory サービスも、Windows 2000 Server のパフォーマンス問題の要因の1つとして考えておく必要がある。というより、Active Directory サービスのパフォーマンスはチューニング項目の一覧の中で高い位置を占めるだろう。なぜなら、Active Directory サービスは、本書で見てきた要因の中でユーザーたちが最もよく対話するものだからだ。ユーザーは自分のワークステーションにログオンするとき、ディレクトリサービスと対話することになる。また、ユーザーが自分の属しているドメインや信頼しているドメインにあるリソースをブラウズするときには、Active Directory の応答がネットワークに対するユーザーの印象に直接影響するだろう。
この章では、Active Directory サービスにかかわる問題として、Windows 2000 サーバーにディレクトリサービスをインストールする段階から意識していなければならない事柄を論じた。その一環として、ディレクトリサービス要求によって生じる負荷にうまく対応できるようにサーバーを構成したり、自分の環境に適したトポロジをデザインしたり、最適な複製が行われるようにサイト間に適切な接続を作成することを検討した。また、repadmin ツールについても解説した。このツールを使えば、ドメイン間の複製を監視し、ドメインコントローラが遅れずに正しい更新情報を受け取っているかどうかを確認できる。
Active Directory サービスはきわめて拡張性の高いディレクトリサービスとして作られている。つまり、Active Directory サービスが柔軟な開発環境を備えているということだ。Active Directory サービスの場合、管理者と開発者が、ほかのどのディレクトリサービスよりも高度な対話ができるようになっている。このことはまた、ディレクトリサービスのパフォーマンスが、ファイルや印刷のレベルだけでなくアプリケーションのレベルでも、ユーザーのディレクトリサービスに対する使用感に影響を与えることを意味する。開発者は自分が作るアプリケーションをディレクトリサービスと連携させたいので、Active Directory サービスに強く依存する。したがって、Active Directory サービスを確実にチューニングし最適化する必要がある。さもないと、ネットワーク全体のパフォーマンスだけでなく、アプリケーションのパフォーマンスも悪くなる。
ページのトップへ