ネットワークの構成が変化したら

ネットワークの規模が小さく、全体が単一のTCP/IPネットワークに収まる程度の規模であれば、Active Directoryの導入・運用に、それほど難しい点はないといえる。しかし、組織の規模拡大に伴ってネットワークの規模が大きくなると、途中で構成をいじらなければならない。

たとえば、増床や拠点の増加はたいていの場合、ルータやレイヤー3スイッチを介してネットワークを拡張する事態につながる。すると、TCP/IPネットワークの数が増えるため、DNSサーバの設定を変更しなければならない。また、(あまり推奨できない話だが)フォレストやドメインを増やさなければならない場合もある。たとえば、分社化や合併・吸収といった事態がそれだ。

そういった、ネットワーク構成に変化につながるような事態が発生したときに、Active Directoryの側でどのように対処しなければならないかについて、解説していくことにしよう。そこで、どういった場面でActive Directoryの設定変更が必要になるかについて整理する。

ネットワーク構成の変化がActive Directoryに影響するケース

ルータやレイヤー3スイッチを介する形でLANの規模を拡大した場合、TCP/IPネットワーク(と、使用するネットワークアドレス)の数が増える。すると、以下の点で影響が生じる。

• DHCPサーバ : 追加したTCP/IPネットワークにDHCPクライアントを配置する場合、対応するスコープを追加する必要がある。また、DHCPサーバを個別のネットワークごとに配置しないで集約化する場合、境界に入るルータやレイヤー3スイッチではDHCPリレーエージェントを動作させる必要がある
• DNSサーバ : TCP/IPネットワークを追加する場合、対応する逆引き参照ゾーンの追加が必要になる

ネットワークの規模が拡大したからといって、いちいちDNSサーバを増設する必然性は薄いと考えられる。場所によってDNSサーバアドレスの設定が異なると、クライアントPCのTCP/IP構成管理が煩雑になるし、DNSサーバ同士でゾーン情報の整合性をとったり、フォワーダを互いに設定したりするのも煩雑だ。

むしろ、DNSサーバは全体で合計2台程度にまとめて、負荷がかかるようならコンピュータの性能を上げる方が合理的ではないだろうか。(ただし、管理の委任を行いたい等の事情から、スタブDNSを利用してDNSサーバを増設する場面も考えられる)

一方、Active Directoryのドメインコントローラについては話が違う。特に、相対的に低速なWAN回線を介する形で拠点を増やした場合、追加した拠点の側にもドメインコントローラを配置して、WAN回線の負荷軽減とレスポンスの向上を図るようにしたい。その場合、同期負荷軽減のためにはサイトの構築(第88～91回を参照)が、維持管理の負担軽減のためには読み取り専用ドメインコントローラの設置(第26～27回を参照)が、それぞれ必要になるだろう。

反対に、ネットワークの整理統合によって構成が変わり、TCP/IPネットワークの数が減った場合には、対応する逆引き参照ゾーンやDHCPスコープを削除することになる。ただし、使わないDNSゾーンが残っているからといって動作に支障をきたすわけではないから、さしあたっては削除したTCP/IPネットワークに対応する逆引き参照ゾーンを残したままにして、様子を見て「問題ない」と判断した時点で削除する方が無難だろう。

DHCPスコープについても、アクティブになったままでは間違ったアドレス割り当てを行う結果になって具合が悪いので、こちらもさしあたっては非アクティブ化しておき、しかる後に削除するのがよいだろう。

ドメイン構成の変化がActive Directoryに影響するケース

できれば避けたい話だが、ドメインやフォレストを追加しなければならない場面も考えられる。たとえば、親会社と子会社で同じネットワークを共用しており、それぞれでドメインを分けたいという場面が考えられる。その場合、同じフォレストの中で、子会社に対応する子ドメインを増設することになるだろう(第14～16回を参照)。

子ドメインの増設に際しては、必ずしもDNSサーバの設定を変更する必要はない。追加する子ドメインに対応するドメインサブフォルダは、ドメインツリーの最上階層に対応する前方参照ゾーンの動的更新が有効になっていれば、その下に自動的に追加されるからだ。

一方、M&Aなどの事情から異なる組織をひとつにした場合、出自の違いから、別々のフォレストが同居することになるかもしれない。その場合、暫定的な措置としてフォレスト間信頼を設定して、相互にアクセス権を設定できるようにするのが合理的ではないだろうか(第83～87回を参照)。

この場合、単一のドメインツリーが存在するところに別のドメインツリーが加わる形になるので、新たに加わるドメインツリーに対応する前方参照ゾーンを追加する形でDNSサーバだけでも集約するか、あるいは相互にフォワーダを設定する必要がある。

また、それまで別々の場所で動作していたサーバを集約する場合、移設したサーバについてはTCP/IP設定の変更が必要になると考えられる。そのため、IPアドレスの割り当て計画を事前に行い、混乱がないようにしたい。サーバに割り当てる固定IPアドレスの範囲が飛び飛びになるような事態は、できれば避けたい。

ドメインの整理統合を行った場合

ただし、複数のフォレストやドメインツリーが同居した状態を続けていると、管理が煩雑なままになってしまう。そのため、あくまで複数ドメインの共存は暫定措置と割り切り、段階的にドメインを整理統合する方向で考えたい。

整理統合に際してはユーザーアカウント・グループ・コンピュータアカウントの配置替えが必要になる。ADMT(Active Directory Migration Toolkit)のような移行支援ツールを使って移動する方法と、統合先のドメインで新たにアカウントを作り直す方法が考えられる。

しかし、どちらにしてもユーザー側に何も影響が出ないわけではない。クライアントPCが所属するドメイン、ユーザーがログオンするドメインは、いずれにしても変わることになる。

すると、ログオン先の設定を変更したり、クライアントPCをドメインに参加する作業をやり直したりといった作業は必要になる。それであれば、統合先のドメインを新たに用意するか、あるいは既存ドメインのうちのひとつを統合先に指定して、そちらでアカウントを作り直す方が分かりやすく、トラブルが少ないかもしれない。

ともあれ、ドメインを整理統合する場合には不要になったドメインの廃止が発生するので、子ドメインやドメインツリーが増えた場合とは逆の作業が必要になる。たとえば、フォレストやドメインツリーを廃止するのであれば、対応する前方参照ゾーンを削除することになる。また、子ドメインを廃止するのであれば、対応するドメインサブフォルダを手作業で削除することになる。いずれも[DNS]管理ツールでの仕事だ。

実際の整理統合作業では、ドメインがらみの作業だけでなく、TCP/IPネットワークの構成変更を伴うことが少なくないだろう。そのため、「作業漏れ」や「うっかり削除」といった事故を防ぐために、必要な作業をリストアップした上でチェックリストを作成して、一段階ずつ確認しながら切り替え作業を進めるようにしたい。

DNSゾーンの同期範囲とは

ドメインコントローラとDNSの話が出たところで、Active Directory統合DNSの同期について簡単に触れておこう。

Windows Server 2008から、Active Directory統合DNSを使用するように指定したときに、同期の対象範囲を選択できるようになった。従来はドメインコントローラすべてがDNSゾーン情報の同期対象になっていたが、Windows Server 2008以降はDNSサーバを兼用しているかどうかで同期対象を区別できる。選択肢ごとの動作内容は、以下のようになる。

• このフォレストのすべてのDNSサーバ : フォレスト全体で、同じ設定のDNSサーバを共用する場合の選択肢。DNSゾーン情報は、DNSサーバの役割を持っているドメインコントローラにだけ同期する
• このドメインのすべてのDNSサーバ : ドメインごとに別々にDNSサーバを設置する場合の選択肢。DNSゾーン情報は、DNSサーバの役割を持っているドメインコントローラにだけ同期する。ドメインがひとつしかない場合には、[このフォレストのすべてのDNSサーバ]と同じ意味になる
• このドメインのすべてのドメインコントローラ : Windows Server 2003までと同じ。

単一ドメイン構成で、かつ、すべてのドメインコントローラがDNSサーバを兼ねている場合には、どれを選択しても同じことになる。しかし、ドメインコントローラの台数が増えてきたり、WAN経由で別の拠点を増設して、そちらにドメインコントローラだけを設置したり、ということになると、状況が変わってくる。

DNSのゾーン情報を同期対象に含めれば、当然ながら同期すべきデータの量が増える。これは、ドメインコントローラのストレージやネットワークの負荷増大につながる。そのため、DNSサーバでしか必要としないDNSゾーン情報については同期範囲を制限することで、負荷軽減を期待できる。

ただし、少なくとも2台のドメインコントローラ(DNSサーバ兼用)を用意しておかないと、DNSゾーン情報の冗長性がなくなるので注意が必要だ。