Windows 2000 インフラストラクチャ サービスの設計と導入 : Microsoft 社内での DNS、DHCP、および WINS の導入

トピック

 概要
 導入環境
 動的 DNS の導入
 DHCP の導入
 WINS の導入
 結論
 詳細情報
 付録

概要

Microsoft は Microsoft WindowsR 2000 オペレーティング システムが以前のバージョンの Windows よりも高い品質を持ち、ビジネスにおいてより高い価値を提供することを保証することを使命としています。この使命のために、Microsoft は Windows 2000 のベータ版を自社環境に導入し、デスクトップ用の Windows 2000 Professional、およびバックエンド用の Windows 2000 Advanced Server がほかの大企業のビジネスにおける要求に合致する拡張性を持つことを確認しました。

Microsoft の Information Technology Group (ITG) は、社内で 2 つの主な役割を担っています。第 1 の役割は、Microsoft の日常業務を実行するコンピュータおよびソフトウェア アプリケーションの管理、監視、および保守です。第 2 の役割は、ベータ版ソフトウェアを自社のコンピュータ環境に導入し、ベータ版ソフトウェアがリリース可能な品質であることを確認することです。

この文書では、ITG が Microsoft 自社内の環境に Windows 2000 Advanced Server を導入した経験について詳細に解説します。中心となる内容はインフラストラクチャ サービスの導入によって得られた戦略、目標、および教訓についてです。

インフラストラクチャ サービスは、Microsoft 社内で実行しているほかのアプリケーションの基礎となるソフトウェアとサービスのフレームワークを構成するために使用され、Microsoft のコンピュータ情報環境のバックボーンを構成しています。Microsoft はコンピュータ インフラストラクチャから多大なメリットを得ています。Microsoft が内部業務の多くをコンピュータに依存していることから、業務処理においては、信頼性が高く、スケーラブルなコンピュータ インフラストラクチャがきわめて重要です。この文書では、Microsoft 社内でのドメイン ネーム システム (DNS)、動的ホスト構成プロトコル (DHCP)、および Windows インターネット ネーム サービス (WINS) という 3 つの重要なインフラストラクチャ サービスの展開を中心に解説します。

Windows 2000 Advanced Server には、Microsoft 社内へのサーバーの導入を最適化するために使用された機能と拡張性が含まれています。たとえば、動的 DNS を戦略的な名前空間として使用する場合、Active Directory・サービスの統合モードで実行することで高いパフォーマンスを得ることができます。Active Directory の統合化機能と複製機能により、コンピュータ名は動的 DNS に自動的に登録されます。この自動的な登録によって、ITG は新しい動的 DNS サーバーを容易に導入することができ、同時に Windows 2000 Professional オペレーティング システムを実行しているクライアント コンピュータから DNS のメリットを十分に活用することができました。

Windows 2000 Advanced Server には、DHCP の最新バージョンが付属しています。Microsoft は、IT 管理者が手動でコンピュータ名とアドレスを追跡する必要をなくすために DHCP を開発しました。最初の DHCP は、自動構成、割り当て、および IP アドレスの追跡機能を提供していました。Windows 2000 Advanced Server に付属される最新バージョンの DHCP では、パフォーマンス カウンタ、および清掃と Tomstone (廃棄) 機能などの便利な管理機能が追加されています。Windows 2000 Advanced Server で DHCP を使用することで、ITG は DHCP を実行しているサーバーの動作を調整し、全社の従業員に対する利便性を向上させることができるようになりました。

この文書では、Microsoft 社内に Windows 2000 Advanced Server を導入した結果より ITG のインフラストラクチャ エンジニアリング グループが得た知識について解説します。この文書で解説されている経緯は、このグループが導入計画を作成するために行った作業に加えて、後で DNS、DHCP、および WINS を実行するためにサーバーを構成した方法が含まれます。ITG が得た経験を顧客と共有することで、顧客がその知識を学び、適切であればその知識を活用して、自分たちの組織に Windows 2000 Advanced Server をベースとしたインフラストラクチャ サービスを正しく導入するためのガイドとすることができます。

 ページのトップへ

導入環境

企業の環境はそれぞれ異なっているので、Windows 2000 オペレーティング システムの多くのビジネス指向の機能を十分に活用するためには、それぞれの会社に適した計画を構築する必要があります。DNS、WINS、および DHCP の導入を計画する際のもっとも重要な考慮点は、サービスの層、ネットワーク トポロジ、データ センターの分類、チームの構造、およびアップグレード計画を検討することです。以下の項では、特定の各分野が ITG の実装においてどのような意味を持っていたのかを説明します。

サービスの層

サービスの層は、単一のサーバー上で展開されている Windows 2000 ベースのサーバー サービスの数を説明するために ITG で使用している用語です。Windows 2000 Advanced Server には多くのサービスを同時に実行できる拡張性が備わっているので、複数のサービスの高度な層を持つことが可能です。同時に、ITG が単一のサーバーに展開したサービスの実数を決定するには、同時ユーザー数、プロセッサ数、物理メモリ、ネットワーク性能などの要素をすべて検討することが必要でした。Windows 2000 Advanced Server を実行しているサーバーのパフォーマンス特性を解析するために ITG が使用したパフォーマンス カウンタの詳細な一覧については、「付録」を参照してください。

効率的なサービスの層は、ITG の拡張計画にきわめて重要であり、ITG の作業効率を決定する中心的な要因でした。コンピュータ リソースにアクセスしている Microsoft の従業員は、リソースの安定した使用および要求の迅速な処理を求めています。結果として、ITG はインフラストラクチャ サーバーが設置されたすべての場所について、何人の従業員の使用が予想されるのかを検討しました (Active Directory に高度に依存したので、DNS サーバーの設置場所はドメイン コントローラの配置と一致させました)。作業している従業員の数が少なく、サーバー利用率が高くない部門では、Windows 2000 Advanced Server の拡張性を活用して、同じサーバーに DNS、WINS、および DHCP をインストールすることが可能でした。社内のほかの部門で、サーバー利用率がきわめて高い場所では、サーバー負荷に応じて、DNS、WINS、および DHCP サービスが別のサーバーで実行されるように構成しました。この構造により、1 か所での障害が内部のユーザーに広範囲な影響を及ぼさないことを保証することができました。

Windows 2000 Advanced Server のモジュール化設計によって、分散された従業員のさまざまな要求事項に対応してサーバー構成を設計し、導入するだけで、サーバーを効率的に選択することが可能です。ITG は 導入計画において Windows 2000 Advanced Server のモジュール化設計を十分に活用し、展開したコンピュータから従業員が高速で信頼性の高いサービスを受けられることを保証しました。

ネットワーク トポロジ

DNS、DHCP、および WINS のサービスの機能はすべて、信頼性の高いスケーラブルなネットワークに依存しているために、これらのサービスの導入にあたっては、ネットワーク設計を考慮に入れることが特に重要でした。Microsoft のコンピュータ ネットワークは伝統的な ATM (非同期転送モード) ネットワーク トポロジにより互いを結合しています。従業員が集中している部門は、ネットワーク トポロジのハブを構成しています。従業員が比較的少ない部門は、ネットワーク トポロジのスポークに当たります。ネットワーク トポロジを確認することで、ITG は導入されたサーバーが相互に十分なネットワーク接続性を持つことを確認できました。単純化されたスポークとハブによるネットワーク トポロジを図 1 に示します。

図 1: Microsoft の ATM ネットワークのスポークとハブによるトポロジ (概略)

データ センターの分類

Microsoft のデータ センターの分類に関した方針と基準は、常に修正されて更新されています。1993 年に Microsoft が初めて Windows NTR Server オペレーティング システムを導入したときは、2 つのドメイン間でセキュリティ保護された通信チャンネルを提供する "信頼関係" と呼ばれる機能によって、ITG がサーバーの配置を変更し、集中管理を可能にすることができました。再配置が発生するにつれ、ITG は Microsoft のコンピュータ情報環境を高度に分散され集中管理されていないモデルから、高度に整理され集中管理されたサーバーで構成されるモデルに移行しました。ITG が DNS、DHCP、および WINS の展開計画の促進するためにデータ センターの配置の確認を開始したのは、この後者の設計からです。

ITG のデータ センター分類法では、データ センターをエンタープライズのデータ センター、地域のデータ センター、およびサイトのデータ ルームの 3 つの異なるクラスに分類していました。これらのデータ センターの地理的な配置は、Microsoft のスポークとハブによる ATM ネットワーク トポロジに対応しています。エンタープライズのデータ センターは、多数の従業員が勤務する場所に配置されています。地域のデータ センターは地理的に分散していて、サイトのデータ ルームをエンタープライズのデータ センターと接続するために必要なネットワーク設備を保持するための施設として機能しています。サイトのデータ ルームは、一般に Microsoft の各支社に配置されています。サイトのデータ ルームの大部分は、256Kbsp 以上の速度を持つネットワークによって、地域のデータ センターに直接接続されています。

DNS および DHCP サービスがサイトのデータ ルームに展開された場合、その場所で Windows 2000 Professional オペレーティング システムを実行しているクライアントは、その場所の DNS、WINS、および DHCP サーバーを使用することができます。これらのサービスが利用できない場合には、支社の従業員は地域のデータ センターに配置された DNS、WINS、および DHCP サービスにアクセスします。DNS ゾーンの Active Directory マルチマスタ複製によって、それぞれのサーバーが自動的に更新された最新のレコードを持つことが保証されます。

図 2 は、多数の従業員が物理的にエンタープライズのデータ センターに最も近い状況を示しています。同時に、大多数のサイトのデータ ルームが、地域のデータ センターによってエンタープライズのデータ センターに物理的に接続されていることも示しています。これらの要因のそれぞれは、ITG がサーバーを導入する最良の場所を決定する重要な考慮点でした。

図 2: データ センターの場所と従業員の場所の関係

ここでは、データ センターの種類ごとの基本的な相違点と、主要な役割について詳しく解説します。

エンタープライズのデータ センター - Microsoft には 2 つのエンタープライズのデータ センターがあり、その 1 つはアメリカ合衆国ワシントン州のレッドモンド、もう 1 つはアイルランドのダブリンにあります。エンタープライズのデータ センターには、毎日 24 時間スタッフが待機しています。ほとんどの従業員はエンタープライズのデータ センターに物理的に近い場所で勤務しているので、これらの施設は大部分の従業員にサービスを提供しています。

エンタープライズのデータ センターには、多数のサーバーが配置され、Windows 2000 ベースのサーバー サービス層はほとんど存在しません。また、多数の大規模な業務に沿ったアプリケーションがスタンドアロンのサーバーで実行されています。エンタープライズのデータ センターに配置されたサーバーを使用する多数の従業員は、ITG が単一のサーバー上で構成するサービスの数を制限することを認可しています。たとえば、エンタープライズのデータ センターに DNS、WINS、および DHCP サーバーを構成する場合、サーバーを DNS サーバー、WINS サーバー、または DHCP サーバーとして構成できますが、同じサーバーをそのすべてに構成することはできません。この規則は、同時ユーザー数、ハードウェアのパフォーマンス特性、およびシステムが長時間使用不能になった場合に会社に与える影響を考慮して決定しました。

地域のデータ センター - 多数の従業員はワシントン州のレッドモンドにある Microsoft 本社で勤務しているので、これらのデータ センターにはエンタープライズのデータ センターよりも少ない数のサーバーが配置されています。地域のデータ センターは一般に、より小規模に分散されたアプリケーションを実行しています。これらのデータ センターは、インターネットへのゲートウェイとしても使用されます。これらの各施設には通常その場所で勤務している専任のスタッフはいないため、サーバー サポートの大部分はエンタープライズのデータ センターから遠隔作業で行われます。

地域のデータ センターでの DNS および DHCP サーバーの構成では、機材の利用率を上げるために、両方のサービスが同一のサーバーで実行されます。地域のデータ センターにアクセスする従業員は比較的少ないので、配置されているサーバーはエンタープライズのデータ センターのものほど多くは使用されません。

サイトのデータ ルーム - 社内のほとんどの支社オフィスには、数台のコンピュータを安全に格納できるサイトのデータ ルームが存在します。サイトのデータ ルームに格納されているサーバーは、その場所で勤務している従業員の必要に応じるための小規模なインフラストラクチャを展開するために使用されています。たとえばプエルトリコの販売オフィスには、従業員が安全にネットワークにログオンし、さらに大規模な施設へのネットワーク接続性がある状態、またはない状態で共有データへのアクセスおよび文書の印刷を行うための最小限のコンピュータ インフラストラクチャが配備されています。

サイトのデータ ルームに導入されているサーバーでは、機材の利用率を向上させるために、大規模なサービスの層が使用されています。サイトのデータ ルームの一般的なサーバーは Windows 2000 Advanced Server オペレーティング システムを実行し、同時にドメイン コントローラ、グローバル カタログ サーバー、DNS サーバー、および DHCP サーバーとして機能するように構成されています。多くの場合、これらのサーバーは印刷サービスなど、ほかのサービスも同時に提供するように構成されています。

サイトのデータ ルームは、ITG の導入計画で中心的な要素でした。また、サイトのデータ ルームは、従業員が遠隔地の DNS サービスに依存する必要性を排除したことで、ネットワーク トラフィックを分離する役割を果たしています。

チームの構造

ITG は、Windows 2000 ベースの DNS、WINS、および DHCP の導入を監視、管理、および保守するために、次のようなサポート構造を使用しました。

インフラストラクチャ エンジニアリング - 従来の環境を調査し、新しい Windows 2000 ベースの DNS、WINS、および DHCP 環境を設計しました。このチームは、インフラストラクチャ サービス管理グループから問題の委託を受けます。

インフラストラクチャ サービス管理者 - DNS および DHCP の導入を実行する責任を負っています。このチームは、フィールド サービス技術者およびサイトのオペレーション担当者から問題の委託を受けます。

フィールド サービス技術者 - 支社オフィスを訪問して、サーバーのハードウェアをインストールします。このチームは、サイトのオペレーション担当者と密接に連携し、ヘルプデスク、およびデータ センターのオペレーション担当者から問題の委託を受けます。

サイトのオペレーション担当者 - 地域のデータ センター、およびエンタープライズ データ センターのサポートを監視しています。このチームは、フィールド サービス技術者と密接に連携し、ヘルプデスクおよびデータ センターのオペレーション担当者から問題の委託を受けます。

ヘルプデスク - Windows 2000 Professional オペレーティング システムを実行しているデスクトップ コンピュータのサポートを行います。このチームは、従業員のアシスタントとして、大部分の問題点を電話で解決しますが、修理のために従業員のオフィスを訪問することもあります。

データ センターのオペレーション担当者 - エンタープライズのデータ センターおよび地域のデータ センターに配置されたサーバーの大部分について、週 7 日の日常的なサポートと保守を行います。

図 3 は、サポートの各部門間の関係を示したものです。たとえば、ヘルプデスクとデータ センターのオペレーション担当者は共同でトラブルシューティングを行いますが、サイトのオペレーション担当者やフィールド サービス技術者に問題を委託することもできます。

図 3: DNS、WINS、および DHCP の導入におけるチーム構造

アップグレード計画

ITG の インフラストラクチャ エンジニアリンググループによって、Windows NT Server 4.0 ベースのコンピュータを Windows 2000 Advanced Server にアップグレードする手順は、比較的単純であることが明らかになりました。

DNS および DHCP の展開計画と、複数のステップを必要とするタスクの実装はより困難な作業でした。ITG は、最初に動的 DNS、WINS、および DHCP の導入における論理的なロード マップとして機能する Windows 2000 ドメイン名前空間を設計する必要がありました。この名前空間の設計は、地理的な場所に重ねられたドメインの図表的な表現で構成されています。この名前空間は、コンピュータを導入の適切な時期に適切なドメインに結合させるために使用されました。

図 4 は、Microsoft の Windows 2000 ドメイン名前空間を簡略化して表したものです。三角形はアジア、レッドモンド、ヨーロッパなどのドメインを示します。丸はドメイン内に作成された組織単位です。図の左側にある矢印は、Windows 2000 Advanced Server の導入が行われたステップを示しています。

図 4: Microsoft のドメイン 名前空間の実装

次のセクションでは、ITG による Microsoft 社内への動的 DNS、DHCP、および WINS の導入の詳細について説明します。それぞれを導入するためには、Windows 2000 Professional および Active Directory サービスが導入されていることが必要でした。

 ページのトップへ

動的 DNS の導入

ドメイン ネーム システム (DNS) は、インターネットの初期において、インターネットが国防省で研究目的に設立された小さなネットワークであった頃に導入されたものです。このネットワーク内のコンピュータのホスト名は、集中管理されたサーバーに配置された単一の HOSTS ファイルを使用することで管理されていました。ネットワーク上でホスト名の解決を必要とするそれぞれのサイトは、このファイルをダウンロードしていました。インターネット上のホスト数が増大するにつれ、更新手順によって生成されるトラフィックは、HOSTS ファイルのサイズと共に増大し、拡張性、分散管理、さまざまなデータ タイプのサポートなどの機能を提供できる新しいシステムの必要性が明確になりました。

従来の DNS の実装では、権限に関する情報を変更することが必要な場合には、ネットワーク管理者が対応するゾーン ファイルを手動で編集しなければなりませんでした。DNS は本来、静的に構成されたデータベースに対してのクエリをサポートするように設計されたものです。データベース ファイルが変更されることは予想されていましたが、その変更は頻繁ではないことが前提でした。しかし、動的ホスト構成プロトコル (DHCP) によるクライアントへの動的なアドレス割り当てが出現したことで、手動での DNS レコード更新は事実上不可能になりました。ネットワーク管理者は、動的にネットワーク アドレスを構成する機能を持ったクライアントの数に対応できなくなり、DHCP を使用したアドレス割り当ては、動的な DNS 更新と統合されなければならないことが明らかになりました。

これらの問題に対処するため、Microsoft は DNS の新しいバージョンを大きく拡張しました。Windows 2000 Advanced Server に含まれている動的 DNS は、戦略的な名前空間で、以前のバージョンの Windows NT で使用されていた NetBIOS を置き換えるネーム サービスとなります。Windows 2000 オペレーティング システムを実行しているコンピュータでは、Windows 2000 ベースの DNS に動的に登録を行うことが可能になりました。

従来環境

Microsoft 社内への Windows 2000 ベースの動的 DNS の展開前には、ITG はきわめて限定された形式で DNS を使用していました。DNS は dns.ms.com という 1 つのゾーンを使用するように構成されていました。このゾーンは WINS (Windows インターネット ネーム サービス) を実行しているサーバーへのすべての DNS 参照を指すために使用されていました。初期バージョンの DNS ゾーンは、登録や更新は一切行いませんでした。WINS のみに存在する名前への DNS クエリを解決するためには、DNS 名クエリを WINS に転送する方法が使用されていました。従来の DNS 環境は、WINS に格納されている名前を DNS に移行する必要性を軽減するために使用されました。

Microsoft 社内のコンピュータの大部分は、ネーム サービスとして NetBIOS を使用するように構成されています。従来の環境は、Windows NT Server 4.0 オペレーティング システムを実行している 8 台の DNS サーバーで構成されていました。DNS データベース内の名前は、ドメイン名前空間と呼ばれる階層的なツリー構造を形成しています。内部的な DNS ドメインは、必要になる管理のオーバーヘッドの理由から、内部名前空間のすべてのレコードを反映する更新は行われていませんでした。

それぞれの DNS サーバーは、主に Web ベースのアプリケーションなどの従来型システムによって、および社内全体に配置されたネットワーク ルーターの逆引き参照の実行に使用されていました。従来の DNS 名前空間はフラットなもので、インターネットからはアクセスすることはできませんでした。従来の名前空間には独自のルート ドメインが存在し、それぞれの名前空間が完全に分離された実体であったため、内部名前空間と外部名前空間の間には関連性は存在しませんでした。従来の DNS 名前空間を図 5 に示します。

図 5: Microsoft の従来の DNS 名前空間

従来の環境での NetBIOS ネーム クエリを解決するため、40 台以上の WINS サーバーが ITG によって導入されました。それぞれの WINS のレコードは、そのすべてが正確で、最新の状態のレコードであることを保証するために、それぞれの WINS サーバー間で複製されます。社内での WINS サーバーは、ネットワーク接続性、および社内の各部分で勤務する予想従業員数に基づいて配置されました。

Windows 2000 ベースのインフラストラクチャでの名前解決は、動的 DNS が優先される方法です。ITG は、NetBIOS サポートを必要とする従来のオペレーティング システム (Windows 3.x、Windows 95/98、および Windows NT) については引き続き WINS を使用します。社内の標準デスクトップ プラットフォームは Windows 2000 Professional になりましたが、従来のオペレーティング システムは、従業員が下位互換性と相互運用性を保証するテストを行うために必要です。

Microsoft はネーム サービスに WINS を使用していたため、内部的な名前空間はフラットなものでした。動的 DNS の導入によって、フラットな名前空間が地理的な境界をベースとする階層的な名前空間に変更されました。動的 DNS の導入については、以下のページで解説します。Microsoft 社内での WINS の使用に関する詳細については、「WINS の展開」の項を参照してください。

導入の目標

Windows 2000 ベースの DNS の導入を開始する前に、ITG は以下の導入の目標を定めました。

• Active Directory の使用による管理 オーバーヘッドを最小限にする。

• インターネットおよびイントラネット ベースのリソースを区別するために内部的な corpnet.ms.com 名前空間を実装する。

• WINS で使用される名前から DNS で使用される完全修飾ドメイン名 (FQDN) への変換を容易化する。

• ネットワーク帯域幅のより効率的な使用により、従業員が高速なネーム クエリのメリットを受けられるようにする。

• DNS が適切な部分では DNS を活用し、従来のサポートには WINS を使用することで、管理オーバーヘッドを減らす。

• 全社において、従来の WINS インフラストラクチャを DNS に置き換えられるようにする。

動的 DNS の概要

ここでは、配置前に ITG が習得した動的 DNS の機能の一部について概要を示します。動的 DNS のより詳細な情報については、「詳細情報」の項を参照してください。

動的 DNS のレコード
DNS データベースはリソース レコードで構成され、それぞれのリソース レコードはデータベース内で特定のリソースを識別します。DNS には各種のリソース レコードが存在します。一般に使用されるリソース レコードの多くの構造を表 1 に示します。

表 1. 一般に使用されるリソース レコード

説明	クラス	TTL (Time To Live)	タイプ	データの説明
SOA (Start of Authority)	インターネット (IN)	既定の TTL は 60 分	SOA	所有者名、プライマリ名、サーバー DNS 名、シリアル番号、更新間隔、再試行間隔、有効期限、最小 TTL
ホスト	インターネット (IN)	ゾーン (SOA) TTL	A	所有者名 (ホスト DNS 名)、ホスト IP アドレス
Name Server	インターネット (IN)	ゾーン (SOA) TTL	NS	所有者名、ネーム サーバー DNS 名
Mail Exchanger	インターネット (IN)	ゾーン (SOA) TTL	MX	所有者名、メール エクスチェンジ サーバー DNS 名、優先度番号
Canonical Name (an alias)	インターネット (IN)	ゾーン (SOA) TTL	CNAME	所有者名 (エイリアス名)、ホスト DNS 名

 

ITG の導入計画の主要なリソース レコードについて、以下に簡単に説明します。

サービス ロケーション (SRV) レコード - SRV レコードは、Windows 2000 Advanced Server オペレーティング システムを実行し、NetLogon、クラスタリング、Telnet、FTP (ファイル転送プロトコル) などのサービスを提供しているコンピュータ名を指定したものです。Windows 2000 ベースのドメイン コントローラでの NetLogon サービスは、アンダースコア (_) を前に付ける形式で SRV レコードを登録します。たとえば "_ldap._tcp.dc.msdcs.corpnet.ms.com" というクエリは、corpnet.ms.com ドメインに存在するすべてのドメイン コントローラの名前とアドレスを返します。

ホスト レコード (A) - ホスト レコードは、コンピュータから IP アドレスへの変換に使用されます (前方参照)。

ポインタ (PTR) レコード - PTR レコードは、IP アドレスからコンピュータ名への変換に使用されます (逆引き参照)。

ネーム サーバー (NS) レコード - NS レコードは、ドメイン内で権限を持つコンピュータの識別に使用されます (委任に使用されます)。

SOA (Start of Authority) レコード - SOA レコードは、ゾーン ファイルの所有者名、プライマリ ネーム サーバー、およびシリアル番号の識別に使用されます。最小の TTL (Time To Live) および有効期限の識別にも使用されます。

動的 DNS の登録
ITG は DNS 名前解決の 2 つの方法であるクライアント登録 (DHCP を使用する Windows 2000 Professional ベースのクライアント) および従来のクライアントのサポート用の DCHP サーバー ベースの登録について詳しく調べました。

Windows 2000 ベースの DCHP クライアントが初期化されるときには、DHCP サーバーで動的な更新プロシージャとの通信が行われます。既定では、Windows 2000 ベースのクライアントはホスト レコードまたは "A" レコードの更新を試みます。この間に、Windows 2000 Advanced Server を実行しているサーバーと、DHCP サービスによってクライアントの PTR リソース レコードの更新が試みられます。

Windows 2000 ベースの DHCP サーバーは、"クライアント要求に従って DNS サーバーを更新する"、または "常に前方および逆引き参照 (後方参照) を更新する" ように構成することができます。DHCP サーバーが "前方および逆引きを常に更新する" ように構成されている場合、DHCP クライアントの要求にかかわりなく A および PTR リソースの両方がサーバー自身によって更新されます。DHCP サーバーが動的更新を行うように構成されていない場合、DHCP クライアントによって A および PTR リソースの両方の更新が試みられます。

DHCP サーバーがクライアント コンピュータの能力に応じて前方および逆引き参照ゾーンと相互動作する方法について、以下に簡単に説明します。

前方参照 - DHCP サーバーはクライアントの能力に応じて、"A" レコードを前方参照ゾーンに登録することができます。クライアントが動的 DNS をサポートしている場合、DHCP は登録作業をクライアントに任せます。Windows 9x および Windows NT Server 4.0 などの従来システムについては、DHCP が登録を行うように構成されていれば、DHCP が自動的にクライアントに代わってリソース レコードを登録します。この場合、DHCP サーバーが DNS レコードを所有することになります。このため、DNS ゾーンでセキュリティ保護された更新を使用するように構成しなければならない場合には問題が生じます。詳細については、「DHCP の展開」の項を参照してください。

逆引き参照 - 逆引き参照が有効になっている場合、クライアントの PTR レコードは DHCP サーバーによって逆引き参照ゾーンに登録されます。クライアントのリース期限が終了した場合には、DHCP サーバーを使用して DNS レコードを削除することができます。したがって、in-addr.arpa ゾーンは更新が可能な状態で実行することが必要です。

Windows 2000 ベースの DHCP の詳細については、「DHCP の展開」および「詳細情報」のセクションを参照してください。

動的 DNS ゾーン
DNS データベースは、複数のゾーンに分割することができます。ゾーンとは DNS 名前空間の連続した部分に属するリソース レコードと所有者名を格納する DNS データ ベースの一部です。ゾーン ファイルは DNS サーバー上で保守されます。単一の DNS サーバーは、0、1、または複数のゾーンを持つように構成できます。

ゾーンには、そのゾーンのドメイン名で終わるほとんどの名前についての情報が格納されています。DNS サーバーは、ある名前を含むゾーンを読み込む場合には、その名前についての権限を持つと見なされます。すべてのゾーンについて、最初のレコードは SOA (Start of Authority) リソース レコードです。SOA リソース レコードは、そのゾーンに含まれるデータについての最良の情報源、およびゾーンの更新を行うサーバーとして、そのゾーンの主要 DNS ネーム サーバーを識別しています。

ゾーン内の名前は、ほかのゾーンに委任することもできます。委任は、DNS 名前空間の一部についての責任を別のエンティティに割り当てる手順です。この別のエンティティは、別の組織、または組織内のワークグループの部門です。本質的には、委任は DNS ネームスペースの一部に関する権限をほかのゾーンに割り当てることを意味します。NS レコードは、委任されたゾーンと、そのゾーンに権限を持つサーバーの DNS 名を指定することでこの委任を表現しています。複数のゾーンにまたがる委任は、DNS に関する最初の設計目標の一部でした。DNS 名前空間を委任する主な理由は以下のとおりです。

• DNS ドメインの管理を多数の組織または組織内の部門に委任するため。

• 複数のネーム サーバーにまたがる 1 つの大規模 DNS データベースの保守を分散し、名前解決のパフォーマンスを向上すると共に、DNS の障害に対してフォールト トレランスを備えた環境を作成するため。

• ホストを適切なドメインに含め、ホストが組織的に協力できるようにするため。

BIND や Windows NT Server 4.0 ベースの DNS サーバーなど、DNS の標準の実装では、サーバー データベースをゾーンに分割する機能が提供されています。それぞれのゾーンはプライマリ ゾーン (新規登録を受け付けるもの)、またはセカンダリ ゾーン (プライマリ ゾーンからゾーン情報が転送されるもの) として構成することができます。

以前のバージョンの DNS によって提供される標準の構成に加えて、Windows 2000 Advanced Server では DNS ゾーン情報を Active Directory に統合し、各ゾーンを Active Directory に統合されたプライマリ ゾーンとして実行する機能が提供されています。この機能によって、各 DNS サーバーは Windows 2000 Professional オペレーティング システムから登録と更新を受け付けることができます。このオプションは、DNS を実行するように構成されているサーバーが、同時に Windows 2000 ドメイン コントローラである場合にのみ使用できます。

ITG の動的 DNS 設計では、すべてのゾーンにおいて動的 DNS が Active Directory に統合されたモードで実行されるように構成することが必要でした。Active Directory サービスとの統合によって、以下のメリットが得られました。

• それぞれの動的 DNS ゾーンは、Active Directory に統合されたプライマリ ゾーンとして実行されているため、動的な登録を受け付けることができます。このため、従来バージョンの DNS で、従来のプライマリおよびセカンダリ ゾーンの構成で発生していた、1 か所の障害による問題が排除されました。

• DNS 複製は、ゾーン情報の正確で信頼性の高い表現を提供する Active Directory によって実行されます。

• ゾーン情報が任意のドメイン コントローラで更新可能なため、競合は更新タイムスタンプによって解決されます。これらのチェックは、Active Directory の複製作業の一部として実行されます。

• 動的 DNS の統合されたゾーンは、セキュリティ保護 (Secure)、更新する (Allow Updates)、および更新しない (No Updates) の 3 つのモードで実行できます。

動的 DNS の展開

ITG は動的 DNS を展開する前に、ドメイン名前空間の設計、動的 DNS とプロキシ サーバーの統合、サーバーの配置、逆引き参照ゾーン、サイト構成、クライアント構成、および動的 DNS サーバー構成について検討しました。

ドメイン名前空間の検討
ドメイン ネーム システムは階層構造の分散されたデータベースとして実装され、このデータベースには corpnet.ms.com などのホスト名とドメイン名を含む、さまざまな種類のデータが含まれます。

完全修飾ドメイン名 (FQDN) は、参照されたホストからルートへのパスをドットで区切られた名前の一覧で指定することで、DNS 階層ツリー内のホストの位置を固有に示します。

ITG の動的 DNS 名前空間では、この階層設計が活用されています。それぞれの DNS ゾーンは主に地理上の業務的な境界に基づき、いくつかのゾーンは業務上の必要性に基づいています。名前は、Windows 2000 ドメイン名前空間の設計から決められたものです。名前の決定には、それぞれの地域の管理者からのフィードバックの要因も関係しています。

イントラネット ベースのリソースとインターネット ベースのリソースを区別するため、ITG はイントラネット ベースのゾーンを corpnet.ms.com ゾーンの下に作成し、後でインターネット ベースのゾーンを ms.com ゾーンの下に作成しました。後から作成されたすべてのゾーンは、上記のどちらかのゾーンをベースにしています。

図 6 は、corpnet.ms.com の動的 DNS 名前空間を示しています。この名前空間には、以下のゾーンが含まれます。

SelfHost - このゾーンは、Windows 2000 オペレーティング システムの開発を分離するために作成されたものです。製品開発には、そのゾーンの制御を任され、開発者がゾーンを管理できることが必要です。

DNS - ITG は、従来の DNS 環境を Windows 2000 ベースの名前空間と結合しました。このゾーンの主要な機能は、従来のクライアントからの NetBIOS 要求を名前解決のために WINS に転送することです。従来の DNS 環境は、Windows 2000 Professional および Windows 2000 Advanced Server の導入によって影響を受けません。ITG は単に従来のゾーンを新規名前空間と結合しただけです。

図 6: corpnet.ms.com の動的 DNS 名前空間

プロキシの構成
外部 DNS サーバーには、インターネットのコンピュータからアクセス可能なレコードが含まれます。内部 DNS 名前空間には、プライベート ルートが含まれる場合があります。この場合には、内部クライアントがクエリを内部 DNS サーバーに、またはクエリを外部的に解決するプロキシ サーバーに転送するように構成することができます。クライアントがプロキシ サーバーにクエリを転送するように構成するには、プロキシの自動構成ファイル (Proxy Auto Configuration File) や Windows プロキシ自動検出 (Proxy Auto Detection) などの方法があります。別の方法として、内部 DNS サーバーが未解決のクエリをインターネットに転送するように構成することもできます。DNS 名前解決を必要とするクライアントの種類によって、DNS の構成は大きく異なる場合があります。

Microsoft の社内イントラネットの名前空間は、corpnet.ms.com (従来のクライアントのサポートについては dns.ms.com) の下に作成されているので、これらのドメイン サフィックスに含まれないホストへのすべての複数ラベル クエリは、インターネット上の DNS サーバーによるクエリ解決を可能にするために、Windows 2000 ベースのプロキシ サーバーに送信されます。ITG はインターネットへのプロキシによってクエリを解決するようにクライアントを構成する 4 つの方法を検討し、DHCP を使用した自動検出が最良の方法であると結論をだしました。検討された 4 つの方法は以下のとおりです。

Winsock プロキシ - プロキシ サーバーがクエリをインターネットに転送するようにプロキシ サーバーの mspclnt.ini というファイルを構成するために使用します。

スクリプトによる自動構成 - Microsoft Proxy Server 管理ツールを利用して、自動構成を容易にします。

手動構成 - 特定のドメイン名に対してプロキシ サーバーを構成するため、いくつかのサードパーティ製ツールが利用できます。ITG はサードパーティ製アプリケーションの WS_FTP を使用してプロキシ サーバーを構成しました。

自動検出 - WPAD (Windows プロキシ自動検出) によって、プロキシ サーバーを検出する手順が自動化されます。WPAD のエントリは、DHCP 通知を使用して DHCP クライアントにプロキシ サーバーを通知することができます。または、DNS ドメインの CNAME によって WPAD を割り当てることもできます。ITG は、DHCP 通知による方法を採用しました。これは、クライアント コンピュータが DHCP を使用してプロキシ サーバーにクエリを転送することが可能になるためです。

逆引き参照ゾーン
逆引き参照ゾーンには、IP アドレスをコンピュータ名に変換するために使用される PTR レコードが含まれます。ITG の動的 DNS 設計では、完全に分散された逆引き参照ゾーンが必要になりました。この設計上の要件に対応するため、ITG は各ドメインのそれぞれの動的 DNS サーバーを、そのドメインが担当するネットワーク サブネットに対して権限を持つように構成しました。

たとえば、Microsoft ヨーロッパの動的 DNS サーバーは、ヨーロッパの各サイトにあるネットワーク サブネットに対して権限を持つように構成されています。この構成には、それぞれの逆引き参照ゾーンがクライアントと、それを登録した DHCP サーバーに近い場所に配置されていることが必要でした。

逆引き参照ゾーンの構成は、Windows 2000 のドメイン構造をベースとするものではなく、会社に割り当てられた IP アドレス範囲をベースとするものです。たとえば、企業に 172.56.X.Y などの B クラス IP アドレスを割り当てられている場合には、逆引き参照ゾーンとして 56.172.in-addr.arpa が作成されます。

サイト構成
ITG は、サポートするそれぞれの種類のデータ センターについて、動的 DNS 構成を決定しました。ここでは、ITG が動的 DNS の導入に使用したそれぞれのサイト構成について解説します。

エンタープライズのデータ センターの DNS 構成 - この分類に属する各データ センターは、WINS、動的 DNS、グローバル カタログ、およびドメイン コントローラのトラフィックが発生します。それぞれのエンタープライズのデータ センターに配置された Windows 2000 ベースのドメイン コントローラと動的 DNS サーバーの権限ドメイン、役割、および WINS 参照を表 2 に示します。

表 2. エンタープライズのデータ センターの動的 DNS 構成

権限ドメイン	役割	WINS 参照
ルート "."	Active Directory に統合されたプライマリ 更新なし	ローカル WINS サーバー
Corpnet.ms.com	Active Directory に統合されたプライマリ セキュリティ保護された更新のみを許可する	なし
ローカル ドメイン	Active Directory に統合されたプライマリ セキュリティ保護された更新のみを許可する	なし
dns.corpnet.	プライマリ	ローカル WINS サーバー
サイトに関連付けられたサブネットの in-addr.arpa ゾーン	Active Directory に統合されたプライマリ 更新を許可する	なし

 

地域のデータ センターの DNS 構成 - これらのデータ センターは、地理的に世界中に分散して配置されています。これらの地域のデータ センターに配置された Windows 2000 ベースのドメイン コントローラおよび動的 DNS サーバーの権限ドメイン、役割、および WINS 参照を表 3 に示します。

表 3. 地域のデータ センターの動的 DNS 構成

権限ドメイン	役割	WINS 参照
ローカル ドメイン	Active Directory に統合されたプライマリ	なし
dns.corp.	セカンダリ	ローカル WINS サーバーがプライマリ、データ センター サーバーがセカンダリ
サイトに関連付けられたサブネットの in-addr.arpa ゾーン	Active Directory に統合されたプライマリ	なし

 

サイトのデータ ルームの DNS 構成 - これらのデータ ルームは一般に、現地の販売オフィスに配置されています。サイト データ ルームに配置された Windows 2000 ベースの動的 DNS サーバーとドメイン コントローラの管理ドメイン、役割、および WINS 参照を表 4 に示します。

表 4. サイトのデータ ルームの動的 DNS 構成

サーバー	権限ドメイン	役割	WINS 参照
ローカル ドメイン コントローラ	ローカル ドメイン	Active Directory に統合されたプライマリ	なし
ローカル ドメイン コントローラ	サイトに関連付けられたサブネットの in-addr.arpa ゾーンに対する権限	Active Directory に統合されたプライマリ	なし

 

ハードウェアの標準
それぞれの DNS サーバーは、以下のコンポーネントを使用するように構成されました。

• Compaq ProLiant 1850R、512K キャッシュ、128MB RAM

• Compaq Smart Array 3200 コントローラ、PCI、64MB キャッシュ

• Compaq NC3120 10/100 TX PCI Intel UTP 100BASE-T、全二重

• Compaq 9.1GB Pluggable Wide-Ultra2 SCSI 10,000RPM ハード ディスク、1.0" (LVD)

クライアント構成とサイトの検討点
ITG は、Windows 2000 Professional ベースのクライアントが適切な DNS ゾーンを使用するように構成するために、DHCP を使用しました。選択された DNS ゾーンは、Windows 2000 ドメインでのクライアントのメンバシップに基づいています。

DHCP は、各サイトに配置されたクライアントを構成するために、以下の規則を使用するように構成されました。

• レッドモンドおよびヨーロッパ ドメインに属するクライアント コンピュータは、それぞれワシントン州のレッドモンドまたはアイルランドのダブリンに存在するエンタープライズのデータ センターに配置されたプライマリおよびセカンダリ DNS サーバーの両方を使用するように構成されました。社内の大部分の Windows 2000 Professional ベース クライアント コンピュータは、これらの地域に存在します。

• 地域のデータ センターに配置されたドメイン コントローラに対して認証を行うクライアント コンピュータは、最も近い地域データ センターに配置された DNS サーバー、およびエンタープライズのデータ センターに配置された DNS サーバーを使用するように構成されました。地域のデータ センターに配置された DNS サーバーが優先され、エンタープライズのデータ センターに配置された DNS サーバーが代替となります (この構成では、クライアントが最も近い DNS サーバーの使用を最初に試みた後、より遠い DNS サーバーの使用を試みることに注意してください)。このような構成のアプローチにより、地域の DNS トラフィックの大部分が、その地域に配置された DNS サーバーによって解決されることが保証されました。

• DNS トラフィックは、従業員に近いサイトのデータ ルームに追加の DNS サーバーを配置することで、さらに分離されます。社内のこれらの部分では、コンピュータは、ローカルのサイトのデータ ルームに配置されたサーバーに対して最初にDNS クエリを解決するように構成されています。ローカル DNS サーバーが利用できない場合、クライアント コンピュータは、上位レベルの地域のデータ センター レベルに配置されたサーバーに対してDNS クエリを解決します。

各クライアントは、それぞれの地域に配置された優先動的 DNS サーバーを最初に使用し、その後で別の場所に配置された動的 DNS サーバーの使用を試みるように構成されています。多くの場合には、優先 DNS サーバーは代替サーバーよりも、物理的にクライアントに近くなります。この戦略によって、ITG はそれぞれの地域から発正するネットワーク トラフィックの量を最小化することができました。優先動的 DNS サーバーと代替動的 DNS サーバーを使用したクライアントの構成設定を図 7 に示します。

図 7: サイトでの優先動的 DNS サーバーと代替動的 DNS サーバーを使用した構成設定の使用

動的 DNS サーバーの構成
ITG の動的 DNS 設計では、以下の既定構成が必要になります。

セキュリティ保護された更新のみを許可 (Allow Only Secure Update) - この機能は、すべての前方参照ゾーンについて有効になっています。この構成によって、クライアント コンピュータが既に動的 DNS に記録されているコンピュータ名を使用することを防止できます (注 : クライアントのレコードが DHCP によって登録された場合、そのレコードは DHCP サーバーに所有されます。従来のクライアントが後で Windows 2000 にアップデートされると、そのクライアントは自分のレコードを更新できなくなります)。

更新を許可 (Allow Updates) - この機能は、すべての逆引き参照ゾーンで有効になっています。この構成によって、DHCP サーバーと DHCP クライアントの両方が、新しい IP アドレスを受け取った後でレコードを変更できます。

アクセス制御リスト (ACL) - ACL は、ルート、corpnet.ms.com、および corpnet.ms.com のすべてのサブゾーンでセキュリティを保護するために使用されます。この予防策は、認定された動的 DNS 技術者以外のユーザーがルートおよび corpnet.ms.com DNS ゾーンにレコードを追加することを防止するために講じられています。アクセス制御リスト (ACL) は、認証されたユーザーが自分のドメインに DNS レコードを作成できないように修正されています。

レコード エイジングと清掃 - この機能は、Active Directory に統合された任意の前方参照 DNS ゾーンで Tombstone (破棄) を使用するために有効になっています。

教訓

動的 DNS の導入から ITG が学んだ重要な教訓のいくつかを以下に示します。

名前空間の設計は論理上の問題を解くガイドラインになる - ITG は、Windows 2000 ドメイン名前空間の設計文書が、後で動的 DNS を展開するガイドラインになることを学びました。この文書は、内部 DNS 名前空間を展開するための必要な適切な手順を判定するうえでも有用でした。ITG はこの文書に従って、最初にドメイン名前空間のルートから始め、それからツリー構造を下にたどって、階層ツリー構造のブランチを実装しました。ブランチは、地域内にサーバーを展開し、それから各データ センターのために開発された標準に従ってサーバーを構成することで実装されました。

多くの場合、Windows 2000 Advanced Server を使用しているサーバーを、必要な動的 DNS を実行するように構成するには、Windows 2000 Advanced Server に含まれる dcpromo.exe を実行し、サーバーを適切な Windows 2000 ドメインに昇格するだけで済みました。この作業の後で、動的 DNS サーバーは Active Directory に保存されている情報を使用して、構成の多くを実行しました。

動的 DNS を習熟することがきわめて重要である - 社内に広く動的 DNS を展開するのは、ITG にとって Windows 2000 Advanced Server の展開以前に経験していなかったことでした。開発チームは、その技術を展開する前に、DNS を理解する必要がありました。DNS を習熟したことで、後になって展開のサポートに大きな助けになりました。DNS の習得は難しくはありませんでしたが、ITG はそれに対応して計画を立てる必要がありました。

複数マスタの複製によって DNS サーバーの展開が容易になる - 階層ドメイン名前空間をサポートするために DNS を展開するときに、ITG は複数マスタの複製によって、インストール時に手動で入力が必要な情報の量を大幅に減らせることにが解りました。DNS 構成の大部分は、結合する DNS ドメイン名を指定した後で自動的に行われます。

 ページのトップへ

DHCP の導入

ネットワーク管理者にとっての長期的な問題を解決するため、Microsoft は動的ホスト構成プロトコル (DHCP) を Windows NT に統合しました。DHCP サービスのリリース前には、ネットワーク管理者はコンピュータが TCP/IP (Transmission Control Protocol/Internet Protocol) プロトコル を利用できるようにするために、コンピュータを手動で 1 つずつ構成する必要がありました。この手動構成の手順には時間を要する上にエラーが発生しやすく、多くの場合そのエラーを解決するためにもかなりの時間が必要でした。これらのエラーと、管理者が手動で多数のコンピュータを構成するために必要な時間のため、多くの大規模な組織は TCP/IP を採用していませんでした。

Microsoft では、DHCP サービスのリリースによって Information Technology Group (ITG) が全社に TCP/IP を展開することが可能になりました。展開が完了した後では、ITG は多くの古い不十分なネットワーク プロトコルの使用を排除し、ネットワーク リソースの効率的な利用を可能にしました。DHCP サービスを使用することで、現在では構成の管理と選択が容易になり、社内のネットワーク管理者はネットワークをより適切に制御することができます。

Windows 2000 Advanced Server に付属するバージョンの DHCP がより大きな業務上の価値を提供することを保証するため、ITG はソフトウェアがベータ テストの段階にある間に全社に展開しました。古いバージョンの DHCP を最新のバージョンにアップグレードする代わりに、ITG は既存の環境を十分に評価し、信頼性を向上させ、会社に利益をもたらすために、Windows 2000 ベースの DHCP をどのように構成すべきかを判定しました。以下に、従来の DHCP 環境、ITG が検討した改良点、および社内で Windows 2000 ベースの DHCP を構成した方法について説明します。

従来環境の確認

Windows 2000 ベースの DHCP を社内に展開する前に、ITG は既に旧バージョンの製品を全社にわたって使用していました。従来環境は 150 台以上の DHCP サーバーと 100,000 台以上の DHCP クライアントで構成されていました。

DHCP の導入により、ITG が LMHOSTS ファイルを更新し、全社の多数のコンピュータに配信することは不要になりました。DHCP と動的 DNS を使用することで、ITG は大部分のデスクトップ コンピュータを中央の場所から管理することができます。DHCP サーバーは全社のエンタープライズのデータ センター、地域のデータ センター、およびサイトのデータ ルームに展開されています。ただし、80,000 台を超える DHCP クライアントは、本社に配置されたわずか 5 台の DHCP サーバーを使用しています。

従来の DHCP 環境は、ITG が Windows 2000 Advanced Server を展開した方法に大きな影響を与えました。Windows 2000 Advanced Server ベースの DHCP 環境は、従来環境で提供されていた同じ機能を提供しなければならないことは明らかでした。さらに重要なこととして、ITG はそれらの機能を改良することを決めていました。しかしながら、改良を加える前に、ITG は Windows 2000 ベースの DHCP における拡張機能について調べる必要がありました。

ITG は Windows 2000 ベースの DHCP を利用して環境を改良する必要があり、従来の DHCP 環境の調査を実行しました。

DHCP スコープの実装
ITG が最初に調査した部分の 1 つは、従来環境でスコープがどのように実装されているかでした。調査の結果、ITG は DHCP スコープの従来の実装は正しく分散されていないことを発見しました。

コンピュータの大部分は、ワシントン州のレッドモンドにある本社キャンパスに配置されています。ここに配置された DHCP サーバーは、80,000 を超える TCP/IP アドレスを取り扱います。ここに配置された DHCP サーバーの 40% が、必要な TCP/IP アドレスの最大 71% を受け持っていました。DHCP サーバー間の負荷を分散していなかったことと、DHCP サービスを実行しているハードウェアが不十分であったことから、2 つの DHCP サーバーがほかのものに比べて性能が不十分でした。

表 5 は、従来の DHCP スコープの分散と、社内で最も多く使用されていた 5 つの DHCP サーバー上のアドレスを示したものです。

表 5. 従来の DHCP スコープと IP アドレスの数

システム名	スコープ	アドレスの総数	使用されているアドレス数
DHCP-1	69	51000	25852
DHCP-2	56	61960	31333
DHCP-3	54	26058	13191
DHCP-4	27	18842	10097
DHCP-5	126	3119	2197

 

従来の DHCP スコープを解析したことで、ITG は性能上の小さな障害までを見つけ出し、それらの障害を解消する展開計画を立案することができました。ITG は、利用可能なすべての DHCP サーバーにアドレス数が等しく分散されていれば、サーバーの性能が向上すると判断しました。

DHCP サーバーの場所
従来環境の調査は、社内で DHCP サーバーがどのように配置されているかという点についてさらに続けられました。ネットワークの解析とネットワーク遅延の観察に基づいて、ITG は社内の数か所では DHCP サーバーの設置場所が従業員から遠すぎると判断しました。

社内で DHCP サーバーの配置が不適切な場合、ネットワーク遅延が発生する可能性が高くなります。さらに、社内でサーバーが適切に配置されていない場合には、適切に配置されている場合と比較して、ネットワーク停止が多くの従業員に影響を与える可能性が高くなります。適切にサーバーを再分散するために、正しいサーバーの配置についての解析と調査が行われ、これによって有用性と信頼性の向上が保証されました。

フォールト トレランスと冗長性
ITG は、ネットワークが停止した場合に会社に広範囲の影響を及ぼす設計上の部分を判定するために、従来環境を調査しました。従来の DHCP サービスのハードウェアに破壊的な障害が発生した場合、従業員が業務を遂行するうえで大きな影響になることが結論付けられました。

ITG は、このような障害発生時のための障害回復計画は、実行に必要な時間が長すぎると判断しました。ITG の障害回復計画では、新しい DHCP サーバーを構築し、新しいスコープに合わせて構成し、影響を受けた場所のネットワーク ルーターを新しいサブネット情報で構成することが必要でした。さらに、ネットワーク ルーターが UDP ポート 67 のブロードキャストを新しい DHCP サーバーに転送するように構成し、新しいアドレスを発行できるようにすることも必要になりました。この計画では、ITG が環境の制御を取り戻した後で、一時的なサブネットを取り除き、ネットワーク ルーターを再構成する環境浄化作業を行うことになっていました。これらの計画を将来使用することは可能でしたが、ITG の DHCP 環境の規模増大に対応できないものでした。たとえば、重要な DHCP サーバーに破壊的なハードウェア障害が発生した場合、ITG はこの計画を繰り返し使用して、70 のネットワーク ルーターを手動で構成しなければならないことになっていました。

従来環境におけるフォールト トレランスと冗長性の調査により、ITG は社内で高い有用性を保持することが必要な部分を突き止めました。ITG の構成では、このような部分について DHCP サーバーの信頼性と有用性を向上させるため、Windows クラスタリングを展開することが必要になりました。

スコープのリース期限
最適の構成を保証するために、各 DHCP スコープについてさらに従来環境の調査が行われました。その結果、多くの DHCP スコープを発行しているリース期限は、与えられた状況から考えて短すぎることが判明しました。また、従来の DHCP 環境では、すべての DHCP スコープに適用可能な標準化されたリース期限がないことも判明しました。一部のリース期限は、完全に不適切に構成されていました。

さらに、別のスコープではリースに使用できるアドレスが少なすぎるため、数時間ごとにリースが期限切れになるように構成されていました。従来環境では、利用可能なリースがスコープによってほぼ使い果たされた場合に、直ちにリースを期限切れにするようにスコープを構成する必要がありました。この構成は、スコープがいっぱいになることを防止するために、従来の設計で使用されていたものです。理想的には、DHCP スコープにリースのための適切な範囲のアドレスが存在すれば、このような回避策は不要になります。

従来環境の調査と解析により、問題が発生しやすい多くの部分が明らかになりました。ITG の展開計画では、Windows 2000 ベースの DHCP を展開することでこれらの問題が解消できることを保証するため、問題の部分を考慮しました。

UDP ポート 67 の転送
従来環境の調査の一部として、ITG は UDP ポート 67 の転送に関する構成変更により、DHCP サーバーのイベント ログの価値が向上すると判断しました。UDP ポート 67 の転送が不適切に構成されている場合、多くの DHCP サーバーのイベント ログはすぐにいっぱいになることが明らかになりました。

DHCP クライアントは、DHCP サーバーを検索するために、IP ブロードキャスト アドレス 255.255.255.255 を使用します。これらのネットワーク ブロードキャストは、UDP ポート 67 に送信されます。既定では、これらのブロードキャストはルーター間で転送されません。従来環境では、ITG が DHCP サーバーをそれぞれのネットワーク サブネットに配置することは実用的ではありませんでした。その代わりに、ITG はルーターがこれらのブロードキャストをほかのサブネットに存在する DHCP サーバーに転送するように構成しました。DHCP サーバーがブロードキャストを受信して、そのネットワーク サブネットについてのスコープを所有していない場合、DHCP サーバーは NACK (Negative Acknowledgement) を返します。

DHCP サーバーが NACK を返すたびに、DHCP サーバーのシステム イベント ログにイベントが書き込まれます。時間が経過するにつれ、イベント ログに書き込まれるイベントの大部分が NACK になりました。イベント ログは、トラブルシューティングの貴重な道具で、ITG はイベント ログを使用して各サーバーの問題を前もって検出することができます。UDP ポート 67 の転送があまりに多く使用された場合、イベント ログが NACK イベントで埋め尽くされ、トラブルシューティングにおける有用性が少なくなります。また、UDP ポート 67 の転送は、DHCP 公開の数を増加させ、ITG がサーバーと DHCP アドレス割り当てを監視する妨げになります。

調査の結果、UDP ポート 67 の転送の問題が識別され、ITG はこの問題点を考慮に入れて、Windows 2000 Advanced Server 導入の一部として解決する計画を立案することができました。ITG の構成では、UDP ポート 67 は引き続き使用することが必要ですが、計画上 UDP ポート 67 の転送をより制御された方法で使用することが必要になりました。

ネーム サービスの負荷分散
従来環境の調査において、ITG は全社にわたって、DHCP がクライアントを WINS および DHCP サーバーにどれだけ効率的に分散しているか調査しました。DHCP の重要な役割の 1 つは、クライアント コンピュータが WINS や DNS のようなネーム サーバーを使用できるように構成することです。

クライアント構成の一部として、DHCP はプライマリおよびセカンダリ ネーム サーバーを提供しています。クライアントは常に、最初にプライマリ ネーム サーバーの使用を試み、一定時間内に応答が返されない場合には、セカンダリ ネーム サーバーの使用を開始します。

従来環境では、プライマリ ネーム サーバーの使用量が多過ぎた場合を除いて、セカンダリ ネーム サーバーはあまり使用されていませんでした。新しい DHCP 構成では、プライマリおよびセカンダリ サーバーに均等にクライアントを分散し、両方のサーバーが同じ程度に使用されることが要求されました。

展開目標

従来の DHCP 環境の調査により、Windows 2000 ベースの DHCP 展開について、以下のような目標について開発が行われました。

• 内部のユーザーに影響を及ぼさずに、Windows NT Server 4.0 ベースの DHCP から Windows 2000 Advanced Server ベースの DHCP への移行を行う。

• Windows 2000 Advanced Server の Windows クラスタリング機能を使用して、サーバーの信頼性と有用性を向上する。

• IP アドレスがリースされる期間を減少させることなしに、既存の IP アドレス不足を解決する。

• DHCP サーバーとネーム サーバーにわたって、クライアント負荷を効率的に分散する。

• 動的 DNS 登録、ベンダ固有のオプション、ユーザー サポートなど、Windows 2000 Advanced Server の機能を有効に活用する。

Windows 2000 ベースの DHCP の概要

ここでは、Windows 2000 ベースの DHCP で新たに導入された各種の機能について簡単に説明します。これらの機能は、ITG が展開計画を検討するために特に重要であったものです。

DHCP と DNS の統合 - DNS サーバーはネットワーク リソースの名前解決を提供し、DHCP サービスと密接に結び付いています。Windows 2000 では、DHCP サーバーと DHCP クライアントは、DNS に登録を行うことができます。DHCP および DNS の相互動作を管理するための標準は、現在 IETF (Internet Engineering Task Force) によって開発中の段階で、Microsoft はこれらの標準が完成次第サポートすることを約束しています。

DHCP サーバーに関する拡張された監視および統計レポート - Windows 2000 の DHCP サーバーには、拡張された監視および統計レポートが追加されています。この新しい機能によって、IP アドレスがユーザー定義のしきい値以下になった場合に通知することが可能です。たとえば、特定のスコープに割り当てられた IP アドレスの 90% が割り当てられた場合に警告を発行することができます。さらに、IP アドレスのプールが使い尽くされたときに第 2 の警告を発行できます。ネットワーク管理者に警告するため、アドレスが定義されたレベル以下に低下した場合、および完全に使い尽くされた場合には警告が画面に表示されます。

DHCP ベンダ特有およびクラス ID オプションの新しいサポート - ユーザー クラスによって、DHCP クライアントが自分のクライアント タイプを指定し、区別することが可能になります。管理者はその後で DHCP サーバーが、オプションを受信するクライアントの種類に応じて異なるオプションを割り当てるように構成できます。変更可能なオプションには、リース期限や WINS と DNS の設定が含まれます。この機能によって、管理者はクライアントをより柔軟に構成できます。クライアント クラスのオプションが使用されていない場合には、既定の設定が割り当てられます。

マルチキャスト アドレスの割り当て - マルチキャスト アドレスの割り当て機能には、サーバー側とクライアント側の 2 つのコンポーネントが含まれます。サーバー側の実装はマルチキャスト アドレスを送信し、クライアント側の API がマルチキャスト アドレスの要求、更新、および解放を行います。クライアント側の API はアプリケーションから使用できます。この機能を使用するには、最初に管理者が、Windows 2000 Advanced Server に含まれる管理ツールを使用して、マルチキャスト スコープおよび対応するマルチキャスト IP の範囲をサーバー上で構成します。マルチキャスト アドレスはそれ以後、通常の IP アドレスと同様に管理されます。クライアントは API を呼び出すことで、スコープからマルチキャスト アドレスを要求できます。下層の実装では、クライアントとサーバーの間で DHCP プロトコル型のパケット形式が使用されます。

非認証 DHCP サーバー検出 - Windows 2000 ベースの DHCP には、認証されていない導入を防止し、既存の非認証 DHCP サーバーを検出するための管理機能が用意されています。以前は、誰でもネットワークに DHCP サーバーを設立することが可能でしたが、最新バージョンの DHCP を使用している現在では認証手順が必要になります。

Windows クラスタリング - Windows クラスタリングは、アプリケーションまたはサーバーの障害を自動的に検出し、2 番目のサーバーで直ちにアプリケーションを再起動することができます。ユーザーから見て、サービスはわずかな時間しか停止しません。Windows クラスタリングを使用することで、管理者はすべてのクラスタ リソースの状態を迅速に検査し、クラスタ内の 2 番目のサーバーに簡単に作業を移行することができます。この機能は、サーバーのローリング更新時に、重要なデータやアプリケーションを長時間オフラインにする必要をなくすために有用です。

Windows クラスタリングによって、DHCP サーバーを仮想化し、2 ノード クラスタの片方のノードが停止した場合に、名前空間とすべてのサービスを 2 番目のノードで外部に影響を与えずに再起動することができます。これによって、クライアントはクラスタ中のどのノードが DHCP サービスを実行しているかにかかわりなく、DHCP の使用を継続することができます。

DHCP の導入

すべての環境にはそれぞれ異なる点があるため、管理者は DHCP サービスを導入する独自のソリューションを計画する必要があります。ITG が行った DHCP サーバー導入では、標準のクラスタ構成、最適化されたスコープ構成、従来のクライアントの構成、および Windows 2000 Professional ベースのクライアント構成が必要になりました。

クラスタ構成
ITG の構成では、Windows 2000 Advanced Server に含まれる Windows クラスタリングを使用して、DHCP サーバーの信頼性を向上し、フォールト トレランスを改良することが必要でした。Windows クラスタリングでは、2 つのサーバーを単一のシステムとして管理することが可能です。DHCP サーバーは Windows クラスタリングを使用して、高い可用性、管理の容易性、および高度な拡張性を提供することができます。

ITG が導入したクラスタでは、"Active/Passive" 構成を使用します。Active/Passive クラスタ構成には、2 つのノードのそれぞれに DHCP サービスがインストールされていることが必要です。Active/Passive クラスタでは、DHCP は "Active" ノードで実行されます。クラスタの "Passive" ノードは、実行待機状態に置かれます。Passive ノードはこの状態で、Active ノードの状態を監視します。Active ノードが実行されていないことを Passive ノードが検出すると、Passive ノードは DHCP の実行を開始し、"フェールオーバー" を開始します。クラスタの双方のノードは共通のディスクと構成を共有するので、どちらのノードもアドレスのリースを実行できます。Windows クラスタリングと Windows 2000 ベースの DHCP で構成される 2 ノードのクラスタを図 8 に示します。

図 8: Windows クラスタリング環境で実行されている DHCP サービス

Passive ノードは、Active ノードが実行されていないことを検出すると、フェールオーバーを開始します。Windows クラスタリングに含まれるクラスタ管理ユーザー インターフェースを使用している管理者も、フェールオーバーを開始することができます。

Windows クラスタリングを使用して DHCP サービスをクラスタ化することで、ITG は技術者がいつでも Passive ノードで作業を行えるようにすることができ、DHCP を実行しているサーバーの保守とアップグレードが容易になりました。Passive ノードで保守が完了した後で、ITG は DHCP サービスのフェールオーバーを開始します。これによって Active ノードで DHCP が停止され、Passive ノードで開始されます。DHCP が Passive ノードで実行されると、そのノードが Active ノードになります。フェールオーバーの開始により、ITG は保守とアップグレードを Passive ノードで継続することができます。

Microsoft の本社では、これまで使用されていた 5 つのスタンドアロン DHCP サーバーを置き換えるために、4 つの DHCP クラスタが展開されました。社内の従業員の大部分は、これら 4 つの DHCP クラスタのどれかを使用しています。それぞれのクラスタは現在約 20,000 のアクティブなリースを処理しており、必要に応じてこれよりかなり多くのリースを処理できることが推定されています。

ITG は、DHCP クラスタをワシントン州のレッドモンドにある本社に配置し、スタンドアロンの DHCP サーバーを各地域のデータ センター、および社内のほとんどのサイトのデータ ルームに配置しました。これらスタンドアロン DHCP サーバーのそれぞれは、ローカル サブネットを担当しています。ある遠隔地に独自の DHCP サーバーが存在しない場合は、最も近い地域のデータ センターに配置された DHCP サーバーがその場所を担当します。

障害が発生した場合には、DHCP サーバーが通常の場所以外のサーバーに IP アドレスのリースを開始します。80/20 の分割は使用されません。レッドモンド地域の外では、冗長 DHCP サーバーは配置されていません。この決定は、障害発生率の少なさと、それらの場所で会社に及ぼされる影響の解析に基づいて行われました。ほとんどの遠隔地では、単一の DHCP サーバーの障害は比較的小さな障害と見なされ、必要ならばスコープをほかの DHCP サーバーに実装することですばやく対策できます。一方で本社に配置された DHCP サーバーの 1 つに障害が発生することはきわめて重大なため本社にクラスタが配置されています。

サーバー構成
DHCP クラスタ内の各ノードには、以下のハードウェアが使用されています。

• Compaq ProLiant 1850R、512K キャッシュ、128MB RAM

• Compaq ProLiant 1600/1850 Pentium III 500MHz Processor Kit

• Compaq Netelligent 10/100 TX Intel UTP コントローラ、全二重 PCI

• Compaq 9.1GB Pluggable Wide-Ultra2 SCSI LVD ドライブ、10,000RPM ハード ディスク、1.0"

共有外部ディスク システム
それぞれのクラスタには、以下のディスク コンポーネントが使用されています。

• ファイバ チャネル 12 ディスク ドライブ ベイとコントローラ

• ファイバ チャネル ストレージ冗長化電源

• 2 x ファイバ チャネル ホスト アダプタ キット/PCI HBA

• 2 x 4GB Compaq ドライブ

最適化されたスコープ構成
DHCP サーバーからのリースには、通常あらかじめ定められたリース期限があります。リース期限が経過すると、DHCP サーバーはそのアドレスを再取得し、利用可能なリースのプールに戻します。特定のリースを使用しているクライアントは、再更新要求を DHCP サーバーに送信することでそのリースを保持します。

クライアントは、割り当てられたリース期限の半分が経過した後で、DHCP のリースの更新を試みます。リース期限は、1 分から 999 日 23 時間 59 分までです。さらに、無期限リースが可能になるように DHCP スコープを構成するオプションもあります。このオプションでは、特定のスコープについて DHCP リースが一切期限切れにならないようにすることができます。

適切なリース期限を決定するには、クライアント コンピュータがどれだけの頻度で新規に IP リースを取得する必要があるかを考慮します。Microsoft では、多くの従業員がラップトップ コンピュータを持って移動します。これらの従業員が目的地に到着してコンピュータの使用を開始するときには、新規 IP アドレスを取得する必要があります。

多数のコンピュータが頻繁に移動される状況では、ITG は DHCP に短いリース期限を構成する必要がありました。この例として、毎日多数の新しい従業員を迎える会議センターがあります。これらの従業員は自分のラップトップを持ち込み、朝にはネットワークに接続し、その日の終わりには取り外し、何か月もの間出張したままになることもあります。このような状況での適切なリース期限は 12 時間以下です。一方、多数のコンピュータが長い期間同じ IP ネットワークに置かれるような状況では、もっと長いリース期限が有用です。リース期限によって、DHCP スコープがアドレスを再取得し、必要に応じて新規クライアントにリースするように構成することができるので、リース期限は重要な考慮点となります。

Windows NT Server 4.0 には、与えられた状況に応じて DHCP スコープを最適化するためにネットワーク管理者が容易に使用できる解析ツールが含まれていません。Windows 2000 Advanced Server はこの問題に対応して、DHCP にパフォーマンス カウンタを統合しています。ITG は Windows 2000 Advanced Server に含まれるパフォーマンス モニタ、および新しいパフォーマンス カウンタを使用して、Windows 2000 Advanced Server ベースの DHCP サーバー上の詳細な DHCP 解析を実行しました。

解析には、Windows 2000 Advanced Server ネットワーク オペレーティング システムを実行している 2 台のコンピュータ上の 6 つの DHCP スコープで構成される小規模な環境が使用されました。この環境での実験により、スコープのリース期限が 4 日から 8 日に変更されても、サーバー利用率には小さな変化しか見られないことが判明しました。同じ実験で、リース期限が倍になった場合に、利用可能なリースの数もわずかしか減少しないことも明らかになりました。この実験により、パフォーマンス カウントの動作を理解するための経験が得られました。

ほかの実験結果から、これまでもっと長い、または短いリース期限に設定されていたスコープについて、リース期限を 6 日に設定するのが有効であることが判明しました。この結論は、リース期限を 6 日に設定することで、利用可能なリース プールが大きく減少する前に IP アドレスがリース プールに戻されるという実験結果、およびリース期限が延長されると DHCP サーバーの利用頻度が減少するという実験結果に基づいています。この解析を行った技術者は、Windows 2000 ベースの DHCP に含まれるパフォーマンス カウンタは DHCP スコープの動作解析に非常に有用であると結論付けました。

Microsoft の環境には 6 日のリース期限が最良であると ITG の結論でした。6 日の標準を採用する前には、1 日から 8 日までのリース期限が試みられました。パフォーマンス モニタを使用して、環境に最適になるようにスコープのリース期限を調整した結果、次のような付加的なメリットが得られました。

ネットワーク トラフィックの減少 -多くのスコープではリース期限が短すぎたため、クライアントが頻繁にリースを再更新し、膨大なネットワーク トラフィックが発生していました。これらのスコープのリース期限を延長することで、DHCP トラフィックを大幅に減少させることができました。

サーバー パフォーマンスの向上 - リース期限が短かったスコープについてリース期限を延長することにより、クライアントからのリース再更新要求の数が減少し、サーバーのパフォーマンスが向上しました。

ヘルプデスクへのサポート呼び出しの減少予想 - パフォーマンス モニタによって、ITG は DHCP スコープを監視し、スコープに十分なリースが存在することを確認できます。以前には、スコープがいっぱいになった場合、ITG がヘルプデスクの技術者に報告してサポートを得なければならないことが多くありました。Windows 2000 ベースの DHCP を使用することで、技術者がパフォーマンス モニタによって必要な情報を取得し、直ちに対策することが可能になりました。

従来のクライアントの構成
Windows 2000 ベースの DHCP には、従来のクライアントに代わって動的 DNS を更新する機能が追加されています。これによって、従来のクライアントに代わって、前方参照と逆引き参照レコードの両方を動的 DNS に登録することができます。レコードはセキュリティ保護された方法、またはセキュリティ保護されていない方法のどちらでも記録することができます。

ITG は、Windows 2000 ベースの DHCP サーバーが従来のクライアントに代わってレコードを登録する場合に、セキュリティ保護されていない方法を使用するように構成しました。この構成によって、従来のクライアントが Windows 2000 にアップグレードされた場合、またはほかのサブネットに移動された場合には、レコードを自分で更新することができます。セキュリティ保護されたメソッドを使用した場合には、DHCP サーバーが従来のクライアントに代わってレコードを登録した場合、DHCP サーバー自身がレコードの所有者になります。

Windows 2000 Professional ベースのクライアント構成
ITG が Windows 2000 Advanced Server の使用を開始する前には、すべての DHCP クライアントは同等に扱われ、DHCP サーバーは特定のクライアントの種類を認識していませんでした。これは、DHCP サーバーが発行したクライアント構成が、すべての DHCP クライアントについて共通である必要があることを意味します。

例として、従来の環境でネットワーク スコープの利用可能なリースが少なくなった場合、ITG はスコープのリース期限を短縮し、利用可能なリースを増やす必要がありました。リース期限を短縮する方法では、そのスコープを使用しているすべてのクライアントが、最短で 12 時間ごとに IP アドレスを更新することが必要になりました。このために DHCP サーバーの負荷が増大し、DHCP サーバーの応答が停止した場合にクライアントに関連する問題が発生する可能性が増加しました。

従来の環境では、DHCP はクライアント コンピュータの電源が切られているときでも、クライアントがリースを保持することを許可していました。リースの期間が終了するまでは、DHCP サーバーがクライアントのリースを無効にすることはありませんでした。Windows 2000 ベースの DHCP では、クラス ID と呼ばれる機能が導入されました。クラス ID によって、クライアントの種類によって独自の構成を使用することが可能になりました。同時に、クライアントのリースが期限切れになる前に使用されていないアドレスを解放し、アドレス プールに戻すことが可能になっています。

ITG が使用した Windows 2000 ベースの DHCP の構成では、従来アドレスの不足に悩まされていたスコープについて、クラス ID のメリットが活用されました。この構成では、Windows 2000 オペレーティング システムを実行しているクライアント コンピュータが正常にシャット ダウンした場合、そのクライアントが所有していたネットワーク アドレスはアクティブ プールに戻され、アドレスを必要としているほかの Windows 2000 Professional ベースのクライアントが使用することができます。クラス ID によって、短いリース期限を使用した場合と同じメリットが得られ、しかも短いリース期限の持つ問題は発生しません。

教訓

Windows 2000 ベースの DHCP の導入から ITG が学んだ重要な教訓のいくつかを以下に示します。

環境を改良するためには、従来の DHCP 環境の調査が重要である - 従来の DHCP 環境の調査は必須でした。この調査により、従来の環境で問題の解決が必要な部分を識別することができ、ITG は目標を設定することができました。従来の環境を調査し、Windows 2000 Advanced Server に統合された新機能を習得することで、ITG は環境を大きく改善できました。

従来のクライアントのサポートを考慮することは重要である - ITG は、DHCP が、保護されていない方法で従来のクライアントに代わってレコードを登録しないように構成することにしました。この構成により、従来のクライアントが Windows 2000 にアップグレードされるか、ほかのサブネットに移動された場合でも、クライアントが自分のレコードを更新可能であることが保証されます。

DHCP によって、クライアントが DNS を使用するように構成する手順が自動化される - ITG の DNS 設計では、ドメイン名などのネットワーク アダプタ構成設定の関連付けが、それぞれのコンピュータが参加する Windows 2000 ベースのドメイン名と一致していることが必要でした。Windows 2000 のドメインは、本質的にネットワーク サブネットの集合となり、ITG は DHCP を使用して、クライアントが動的 DNS を使用するように自動的に構成することができました。

 ページのトップへ

WINS の導入

WINS (Windows インターネット ネーム サービス) は、ルートされた TCP/IP (Transmit Control Protocol/Internet Protocol) ネットワーク環境での動的なコンピュータ名から IP アドレスへの変換についての登録およびクエリを行う、分散したデータベースを提供します。WINS は、従来の環境で NetBIOS コンピュータ名の動的な登録をサポートし、Windows ベースの TCP/IP ネットワークの構成と管理を容易にするために必要です。WINS は、ドメイン ネーム システム (DNS) のサポートが実用的でない従来環境のサポートを提供するため、Windows 2000 Advanced Server に含まれています。

WINS によって、従業員はそれぞれのコンピュータに関連付けられた IP アドレスの代わりに、静的な覚えやすい名前を使用してコンピュータを参照することができます。同時にネットワーク管理者は LMHOST ファイルなどの静的なマップ ファイルを更新する作業から解放されます。WINS は、DHCP を経由した動的なアドレス割り当ての結果、サブネット間で移動されたコンピュータについて新しい IP アドレスが割り当てられていた場合には、WINS データベースを自動的に更新します。ユーザーおよびネットワーク管理者のどちらも、そのような名前解決を手動で操作する必要はありません。

Windows 95、Windows 98、および Windows NT Server オペレーティング システムを実行しているコンピュータをサポートするためには、Windows 2000 に含まれる最新バージョンの WINS が必要です。Windows 2000 Advanced Server では、インターネットでより広く使用されている標準である動的 DNS が優先名前空間になります。ITG は Windows 2000 Advanced Server のベータ版展開において Windows 2000 ベースの WINS のメリットを活用し、Windows 2000 ベースのコンピュータと旧バージョンの Windows を実行しているコンピュータとの相互運用性をサポートするインフラストラクチャを設計しました。

Windows NT Server、Windows 95、および Windows 98 は、コンピュータ名を IP アドレスに変換するために WINS に依存しています。Microsoft 社内では、WINS は互換性テストに必要な旧バージョンの Windows をサポートするために大変重要です。ここでは、従来の環境のうちで ITG が最初に導入計画のために調査した部分、ITG の設定した目標、および WINS の実際の導入について解説します。

導入計画

ITG は重要な作業として、正確で最新のネットワークおよびサーバー構成の記録をファイルとして常に保持しています。この作業によって、情報の収集に必要な時間が大きく減少されます。ITG の文書には、従来の WINS インフラストラクチャと、関連付けられたネットワーク コンポーネントの配置に関する詳細が含まれています。

この文書には、以下のようなコンポーンネントの配置を示す図が含まれています。

• この文書には、以下のようなコンポーンネントの配置を示す図が含まれています。

• ATM スイッチ

• 地域キャリア ATM スイッチ

• ハブ ルーター

• 専用線

• サテライト ネットワーク

ITG は、社内のコンピュータ インフラストラクチャをアップグレードする前に従来環境の文書を作成しました。この文書は、備品の記録、サーバーの配置、ハードウェアとソフトウェアの標準、および論理的/物理的アーキテクチャの図についての完全で正確な資料で構成されます。この文書と図によって、ITG は Windows 2000 Advanced Server 導入の目標を設定し、十分に考慮され、制御された形式で配置作業を行うことができました。文書にはサーバーの配置、WINS の複製、クライアントの構成、およびサーバーの構成についての詳細情報が含まれます。

従来の WINS 環境は、Windows NT Server 4.0 ベースの WINS サーバー 34 台で構成されていました。これらの WINS サーバーは、ローカル エリア ネットワーク (LAN) 上では 15 分ごと、ワイド エリア ネットワーク (WAN) 上では 1 時間ごとに相互複製を実行するように構成されていました。WINS の複製により、それぞれの WINS サーバーが正確で最新の情報を保持していることが保証されます。

導入目標

従来の WINS 環境の文書を作成し、調査を行ってから、ITG は社内に Windows 2000 ベースの WINS を導入する上で以下のような目標を設定しました。

• 既存のサーバーの配置を変更しない。

• WINS 環境の可用性とフォールト トレランスを向上する。

• 全社にわたって、WINS サーバーの構成を標準化する。

• 動的 DNS が完全に展開されるまで、WINS を名前解決の中間的な解決策として使用する。

Windows 2000 ベースの WINS の概要

ITG は、導入計画の一部として、最新バージョンの WINS に含まれる新機能を習得し、それらの新機能のメリットを理解し、それらのメリットを活用するように展開戦略を立案する必要がありました。導入において ITG が利用した、WINS の多くの重要な機能について以下に示します。

Windows 2000 Advanced Server に含まれる WINS 管理ツールは、拡張フィルタリング、高速なレコードの検索、動的なレコード削除、改良されたエクスポート機能などが追加され、管理サポート機能が改良されています。ツールには、新しい Microsoft 管理コンソール (MMC) スナップイン、および WINS の管理をスクリプト化するためのコンソール ベースのツールが含まれます。Microsoft 管理コンソール スナップインは、Windows 2000 Advanced Server に含まれ、WINS の管理に使用されるもので、以下のような新機能を提供します。

拡張されたフィルタリングとレコード検索 - この機能によって、WINS のレコードの検索が容易になります。管理者は WINS レコードを、ファイル サーバー (20)、RAS クライアント (21)、ドメイン コントローラ (1C) など、レコードの種類によって検索することができます。レコードをより正確に検索する機能によって、ITG は従来よりも高速にレコードを検索でき、トラブルシューティングが容易になりました。

動的なレコード削除 - この機能によって、多数のレコードを同時に削除する作業が容易になりました。複数選択の機能により、ポイントとクリックのレコード削除機能を使用して、多数のレコードを同時に削除することができます。

エクスポート機能 - この機能によって、WINS データベースに保存されている構成の詳細を、ASCII テキスト ファイルに簡単にエクスポートできます。管理者はデータをエクスポートした後で、そのデータを Microsoft Excel にインポートして、必要なレポートや統計解析を容易に作成できます。

手動 Tombstone ( 破棄 ) - この機能によって、削除されたレコードの状態を記録し、すべての WINS サーバーに複製することができます。また、削除マークが付けられたレコードの再複製を防止します。

Windows 2000 Advanced Server に含まれる最新バージョンの WINS には、固定接続のサポートが組み込まれています。固定接続によって、WINS サーバーは関連付けられた WINS 複製パートナーとの間で常時接続を保持することができます。固定接続によって、従来のバージョンで見られたネットワーク接続の開閉にかかるオーバーヘッドを事実上なくすことができます。ITG は、固定接続により複製のパフォーマンスが向上し、サーバーの複製がより高速に、そして確実に行われることを確認しました。

WINS の展開

Windows 2000 ベースのインフラストラクチャでは、従来の WINS インフラストラクチャに代わって動的 DNS が優先名前空間となっています。DNS はインターネットで使用される名前空間を提供し、Windows 2000 Advanced Server は動的 DNS と共にこの名前空間をネイティブでサポートしています。動的 DNS は、インターネットで広く使用されているものと同じ標準 DNS セットに準拠しています。

しかしながら、Microsoft 社内では従来のクライアントのサポートのため、WINS が必要になります。Windows 2000 Advanced Server には、このような環境をサポートするために WINS が含まれています。ITG は、Windows NT Server 4.0 ベースの WINS サーバーを Windows 2000 Advanced Server にアップグレードすることで、Windows 2000 で向上した拡張性と信頼性を活用し、同時に相互運用性テストで必要な WINS サポートを提供しました。

WINS サポートを必要としないデスクトップ コンピュータは、Windows 2000 Professional にアップグレードしてから、DHCP を使用して動的 DNS を利用するように構成することで、動的 DNS に移行されました。デスクトップ コンピュータが Windows 2000 Professional にアップグレードされ、動的 DNS を利用するように構成されたことで、WINS への依存は減少しました。

サーバー構成に関する標準
Microsoft 社内で Windows 2000 ベースの WINS を導入したことで、WINS サーバーについて 2 つの標準構成を開発することが必要になりました。この構成は、Microsoft 独自のインフラストラクチャに合わせて決定されたものです。

WINS サーバーは、非常に多くのディスク領域を使用します。ITG は、WINS サーバーが、ハードウェア RAID 5 に構成された最低 5 つのスピンドルにデータベースを保存するように構成しました。インターネット データ センターに導入された標準を表 6 に、イントラネット データ センターに導入された標準を表 7 に示します。インターネット データ センターで実行されているコンピュータは、社内のほかの部分とは分離されています。このため、これらのサーバーには別の標準が使用されました。

表 6. インターネット データ センターでの使用のために開発された WINS 標準

値	データ
バックアップ パス	D:\wins_database\backup
シャットダウン時のバックアップ データベース	あり
更新間隔	6 日
廃棄間隔	6 日
廃棄タイムアウト	6 日
検査間隔	24 日
定期的なデータベース整合性チェックの有効化	なし
データベースの変更のログへの記録	あり
詳細イベント ログ	なし
バースト処理の有効化	中
データベースのパス	D:\wins_database\wins.mdb
バージョン カウントの開始	0
パートナーとの間でのみ複製	あり
固定接続のプッシュ/プル	有効
移行	なし
最初の開始時にプル複製を起動	あり

 

表 7. Microsoft 社内からアクセス可能なサーバー用に開発された WINS 標準

値	データ
バックアップ パス	D:\wins_database\backup
シャットダウン時のバックアップ データベース	あり
更新間隔	4 日
廃棄間隔	4 日
廃棄タイムアウト	6 日
検査間隔	24 日
定期的なデータベース整合性チェックの有効化	なし
データベースの変更のログへの記録	あり
詳細イベント ログ	なし
バースト処理の有効化	中
データベースのパス	D:\wins_database\wins.mdb
バージョン カウントの開始	0
パートナーとの間でのみ複製	あり
移行	なし
最初の開始時にプル複製を起動	あり
固定接続のプッシュ/プル	有効

 

Windows 2000 Advanced Server の導入
Microsoft 社内では、Windows NT Server 4.0 ベースの WINS を実行しているコンピュータの大部分は、そのまま Windows 2000 Advanced Server にアップグレードされました。このアップグレード作業は単純で、Windows 2000 Advanced Server のインストール ルーチンによって自動的に実行されました。

ただし、一部の例では ITG が WINS の導入中に Windows 2000 Advanced Server を新規にインストールしました。このような例は、Windows 2000 Advanced Server のより大きな拡張性を活用するため、新規インストールと同時により高速なハードウェアを展開することが必要になった場合です。従来環境からそのままアップグレードすることが実用的でない場合には、重要な WINS 構成設定をバックアップし、再度復元することが必要になりました。

新規ハードウェアの展開が必要な場合には、以下の点に注意しました。ITG は、Windows 2000 Advanced Server ベースの WINS を新規にインストールする前に、従来のサーバー上の重要な WINS 構成情報をバックアップし、スムーズに移行ができるようにしました。このバックアップは、新規インストールを行う前の各 Windows NT Server 4.0 ベースの WINS サーバーに関する以下の情報で構成されました。

• WINS データベース

• HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/WINS レジストリ キー

従来の WINS サーバーがバックアップされたことを確認してから、ITG は新しいハードウェアに Windows 2000 Advanced Server を導入し、Windows 2000 Advanced Server に含まれる Windows コンポーネント ウィザードを使用して WINS をインストールしました。このウィザードによって、WINS のインストールは簡単に実行できました。

ITG は、WINS サービスがインストールされてから WINS サービスを停止し、以前にバックアップした WINS データベースとレジストリ キーを復元してから、WINS サービスを再起動しました。構成作業を完了するため、ITG は表 6 および 表 7 に示した標準に従ってサーバーが構成されていることを確認しました。WINS サービスの監視とトラブルシューティングの詳細については、「付録」を参照してください。

教訓

以下に示すのは、Microsoft 社内に Windows 2000 ベースの WINS を展開することから得た重要な教訓です。

綿密な計画の有用性 - ITG は、社内に目立った混乱なしに Windows NT Server 4.0 ベースの WINS インフラストラクチャを Windows 2000 Advanced Server にアップグレードすることができました。計画段階で作成された文書を使用して、導入作業はきわめて注意深く、制御された形式で実行されました。正確で最新のネットワーク構成図と、ソフトウェアおよびハードウェアの一覧を作成することで、ITG は導入によって社内の従業員に悪影響が及ばないことを保証することができました。

Windows NT 4.0 Server インフラストラクチャからの違和感のないアップグレード - Windows 2000 Advanced Server への移行を開始するために、従来の Windows NT Server 4.0 ベースのインフラストラクチャを変更する必要はありませんでした。ITG は、計画段階の初期に WINS サーバーの配置と WINS 複製マトリックスを注意深く調査しました。WINS インフラストラクチャの変更が必要であるかどうかを判定するために、ベンチマークが実行されました。その結果から、従来のインフラストラクチャにおけるサーバーの配置とネットワーク性能は、Windows 2000 Advanced Server ベースの WINS の導入を開始するために十分であることが示されました。

さらに強固なデータベースによる高い信頼性 - 最新バージョンの WINS に含まれる WINS データベースは、従来のバージョンよりも強固で、信頼性の高いことが判明しました。Microsoft 社内に Windows 2000 Advanced Server ベースの WINS を導入して以降、ITG は WINS サーバーの Jet データベースについてどのような形式の破壊も経験していません。

WINS 管理ツールは大きく向上している - Windows 2000 Advanced Server に含まれる WINS 管理ツールは、従来の WINS 管理ツールと比較して大幅に改良されています。新しい Microsoft 管理コンソールの管理ツールには、フィルタおよびレコード検索のサポートが追加されています。また、新しい NETSH WINS ヘルパーによって、スナップインのすべての機能が提供され、WINS コマンドを簡単にスクリプト化することができます。

 ページのトップへ

結論

Microsoft 社内のコンピュータ環境は、ベータ版の製品を導入展開をして、その製品がほかの大規模な企業に適合していることを保証するための重要なテスト環境でした。ITG は、Windows 2000 Advanced Server および Windows 2000 Professional をリリースする前に、最初に製品を社内に導入することで承認する必要がありました。

Windows 2000 ベースの DNS、WINS、および DHCP を導入することで、ITG は Microsoft 社内のコンピュータ環境を改良する機会を得ました。従来の環境を調査し、Windows 2000 の新機能を習得することで、ITG は Windows 2000 の多くのビジネス向け機能を十分に活用した展開計画を立案することができました。

ベータ版の製品を導入するためには、綿密な計画と制御された形式での導入作業が必要です。ITG は DNS、WINS、および DHCP の展開で得た経験を社内で共有し、適切な場合には顧客がその経験から学ぶことができるようにしました。今後の数か月の間、ITG は、お客様が自分たちの環境に Windows 2000 Advanced Server および Windows 2000 Professional を導入する作業をより適切に行えるように、導入に関する経験をお客様と共有します。

 ページのトップへ

詳細情報

Microsoft Windows 2000 Advanced Server および Windows 2000 Professional の最新情報については、https://www.microsoft.com/japan/windows/ を参照してください。

ほかの IT ショーケース資料については、https://www.microsoft.com/japan/showcase/default.aspx を参照してください。

 ページのトップへ

付録

動的 DNS パフォーマンス モニタ カウンタ

次の表は、動的 DNS サービスを実行するサーバーの詳細な解析を行うために Windows 2000 Advanced Server に含まれているパフォーマンス モニタ カウンタを示したものです。ITG は、Microsoft 社内の環境における動的 DNS の特性を理解するための解析に、これらのカウンタの多くを使用しました。

パフォーマンス カウンタ	説明
AXFRREQUESTRECEIVED	AXFR Request Received は、マスタ DNS サーバーが受信したゾーン全体の転送数の合計です
AXFRREQUESTSENT	AXFR Request Sent は、セカンダリ DNS サーバーが送信したゾーン全体の転送要求数の合計です。
AXFRRESPONSERECEIVED	AXFR Response Received は、セカンダリ DNS サーバーが受信したゾーン全体の転送応答数の合計です。
AXFRSUCCESSRECEIVED	AXFR Success Received は、セカンダリ DNS サーバーが受信して成功したゾーン全体の転送数の合計です。
AXFRSUCCESSSENT	AXFR Success Sent は、マスタ サーバーの成功したゾーン全体の転送数の合計です。
CACHINGMEMORY	Caching Memory は、DNS サーバーが使用しているキャッシュ メモリの合計です。
DATABASENODEMEMORY	Database Node Memory は、DNS サーバーが使用しているデータベース ノード メモリの合計です。
DYNAMICUPDATENOOP	Dynamic Update NoOperation は、DNS サーバーが受信した非操作または空の動的な更新要求数の合計です。
DYNAMICUPDATENOOP/Sec	Dynamic Update NoOperation/sec は、1 秒あたり DNS サーバーが受信した非操作または空の動的な更新要求数の平均です。
DYNAMICUPDATEQUEUED	Dynamic Update Queued は、DNS サーバーがキューに登録した動的な更新数の合計です。
DYNAMICUPDATERECEIVED	Dynamic Update Received は、DNS サーバーが受信した動的な更新要求数の合計です。
DYNAMICUPDATERECEIVED/Sec	Dynamic Update Received/sec は、1 秒あたり DNS サーバーが受信した動的な更新要求数の平均です。
DYNAMICUPDATEREJECTED	Dynamic Update Rejected は、DNS サーバーが拒否した動的な更新数の合計です。
DYNAMICUPDATETIMEOUT	Dynamic Update TimeOuts は、DNS サーバーの動的な更新のタイムアウト数の合計です。
DYNAMICUPDATEWRITETODB	Dynamic Update Written to Database は、DNS サーバーがデータベースに書き込んだ動的な更新数の合計です。
DYNAMICUPDATEWRITETODB/Sec	Dynamic Update Written to Database/sec は、1 秒あたり DNS サーバーがデータベースに書き込んだ動的な更新数の平均です。
IXFRREQUESTRECEIVED	IXFR Request Received は、マスタ DNS サーバーが受信した増分ゾーン転送要求数の合計です。
IXFRREQUESTSENT	IXFR Request Sent は、セカンダリ DNS サーバーが送信した増分ゾーン転送要求数の合計です。
IXFRRESPONSERECEIVED	IXFR Response Received は、セカンダリ DNS サーバーが受信した増分ゾーン転送応答数の合計です。
IXFRSUCCESSRECEIVED	IXFR Success Received は、セカンダリ DNS サーバーが受信した成功した増分ゾーン転送応答数の合計です。
IXFRSUCCESSSENT	IXFR Success Sent は、マスタ DNS サーバーの成功した増分ゾーン転送数の合計です。
IXFRTCPSUCCESSRECEIVED	IXFR TCP Success Received は、セカンダリ DNS サーバーが受信した成功した TCP 増分ゾーン転送数の合計です。
IXFRUDPSUCCESSRECEIVED	IXFR UDP Success Received は、セカンダリ DNS サーバーが受信した成功した UDP 増分ゾーン転送数の合計です。
NBSTATMEMORY	Nbstat Memory は、DNS サーバーが使用している Nbstat メモリの合計です。
NOTIFYRECEIVED	Notify Received は、セカンダリ DNS サーバーが受信した通知数の合計です。
NOTIFYSENT	Notify Sent は、マスタ DNS サーバーが送信した通知数の合計です。
RECORDFLOWMEMORY	Record Flow Memory は、DNS サーバーが使用しているレコード フロー メモリの合計です。
RECURSIVEQUERIES	Recursive Queries は、DNS サーバーが受信した再帰クエリ数の合計です。
RECURSIVEQUERIES/Sec	Recursive Queries/sec は、1 秒あたり DNS サーバーが受信した再帰 クエリ数の平均です。
RECURSIVEQUERYFAILURE	Recursive Query Failure は、再帰クエリ エラー数の合計です。
RECURSIVEQUERYFAILURE/Sec	Recursive Query Failure/sec は、1 秒あたりの再帰クエリ エラー数の平均です。
RECURSIVETIMEOUT	Recursive TimeOuts は、タイムアウトを送信した再帰クエリ数の合計です。
RECURSIVETIMEOUT/Sec	Recursive TimeOut/sec は、1 秒あたりのタイムアウトを送信した再帰クエリ数の平均です。
SECUREUPDATEFAILURE	Secure Update Failure は、DNS サーバーで失敗したセキュリティで保護された更新数の合計です。
SECUREUPDATERECEIVED	Secure Update Received は、DNS サーバーが受信したセキュリティで保護された更新要求数の合計です。
SECUREUPDATERECEIVED/Sec	Secure Update Received/sec は、1 秒あたり DNS サーバーが受信したセキュリティで保護された更新要求数の平均です。
TCPMESSAGEMEMORY	TCP Message Memory は、DNS サーバーが使用している TCP メッセージ メモリの合計です。
CPQUERYRECEIVED	TCP Query Received は、DNS サーバーが受信した TCP クエリ数の合計です。
TCPQUERYRECEIVED/Sec	TCP Query Received/sec は、1 秒あたり DNS サーバーが受信した TCP クエリ数の平均です。
TCPRESPONSESENT	TCP Response Sent は、DNS サーバーが送信した TCP 応答数の合計です。
TCPRESPONSESENT/Sec	TCP Response Sent/sec は、1 秒あたり DNS サーバーが送信した TCP 応答数の平均です。
TOTALQUERYRECEIVED	Total Query Received は、DNS サーバーが受信したクエリの数の合計です。
TOTALQUERYRECEIVED/Sec	Total Query Received/sec は、1 秒あたり DNS サーバーが受信したクエリ数の平均です。
TOTALRESPONSESENT	Total Response Sent は、DNS サーバーが送信した応答数の合計です。
TOTALRESPONSESENT/Sec	Total Response Sent/sec は、1 秒あたり DNS サーバーが送信した応答数の平均です。
UDPMESSAGEMEMORY	UDP Message Memory は、DNS サーバーが使用している UDP メッセージ メモリの合計です。
UDPQUERYRECEIVED	UDP Query Received は、DNS サーバーが受信した UDP クエリ数の合計です。
UDPQUERYRECEIVED/Sec	UDP Query Received/sec は、1 秒あたり DNS サーバーが受信した UDP クエリ数の平均です。
UDPRESPONSESENT	UDP Response Sent は、DNS サーバーが送信した UDP 応答数の合計です。
UDPRESPONSESENT/Sec	UDP Response Sent/sec は、1 秒あたり DNS サーバーが送信した UDP 応答数の平均です。
WINSLOOKUPRECEIVED	WINS Lookup Received は、サーバーが受信した WINS 参照要求数の合計です。

 

以下に示すのは、サーバーの動作に基づいてシステム要件を決定するため、および異常な量のシステム リソースを消費する問題点を特定するために ITG が使用した DNS 固有のオブジェクトとカウンタです。

DNS 固有のトリガ	説明
CACHINGMEMORY	Caching Memory は、DNS サーバーが使用しているキャッシュ メモリの合計です。
DYNAMICUPDATEQUEUED	Dynamic Update Queued は、DNS サーバーがキューに登録した動的な更新数の合計です。
DYNAMICUPDATERECEIVED/Sec	Dynamic Update Received/sec は、1 秒あたり DNS サーバーが受信した動的な更新要求数の平均です。
RECURSIVEQUERIES/Sec	Recursive Queries/sec は、1 秒あたり DNS サーバーが受信した再帰 クエリ数の平均です。
RECURSIVEQUERYFAILURE/Sec	Recursive Query Failure/sec は、1 秒あたりの再帰クエリ エラー数の平均です。
RECURSIVETIMEOUT/Sec	Recursive TimeOut/sec は、1 秒あたりのタイムアウトを送信した再帰クエリ数の平均です。
TCPQUERYRECEIVED/Sec	TCP Query Received/sec は、1 秒あたり DNS サーバーが受信した TCP クエリ数の平均です。
TOTALQUERYRECEIVED/Sec	Total Query Received/sec は、1 秒あたり DNS サーバーが受信したクエリ数の平均です。
TOTALRESPONSESENT/Sec	Total Response Sent/sec は、1 秒あたり DNS サーバーが送信した応答数の平均です。
WINSLOOKUPRECEIVED/Sec	WINS Lookup Received/sec は、1 秒あたりサーバーが受信した WINS 参照数の平均です。
WINSRESPONSESENT/Sec	WINS Response Sent/sec は、1 秒あたりサーバーが送信した WINS 参照応答数の平均です。
WINSREVERSELOOKUPRECEIVED/Sec	WINS Reverse Lookup Received/sec は、1 秒あたりサーバーが受信した WINS 逆引き参照応答の合計数です。
WINSREVERSERESPONSESENT/Sec	WINS Reverse Response Sent/sec は、1 秒あたりサーバーが送信した WINS 逆引き参照応答数の平均です。
ZONETRANSFERFAILURE	Zone Transfer Failure は、マスタ DNS サーバーの失敗したゾーン転送数の合計です。
ZONETRANSFERSUCCESS	Zone Transfer Success は、マスタ DNS サーバーの成功したゾーン転送数の合計です。

 

動的 DNS 固有のイベント ログ エントリ

DNS 固有のイベントは、Windows NT イベント ビューアを使用して表示できます。これらのイベントは DNS イベント ログに書き込まれているので、Windows 2000 イベント ビューアで表示する必要があります。ITG が監視している DNS イベントを以下に示します。

イベント ID	7052
エラー	エラー
説明	DNS サーバーが、{ } 関数の失敗を送信しました。データはエラーです。
アクション	ゾーン転送の中止など、ほかのエラーを確認してください。

 

WINS イベント

WINS サーバーでログに記録されたすべてのイベントについて、そのイベントによって必要となるアクションがあるかどうかを調査する必要があります。ITG で調査する WINS 固有のイベントを以下に示します。

イベント ID	説明
4224	WINS がデータベース エラーを検出しました。これは重大なエラーである可能性、または重大なエラーでない可能性があります。WINS はこのエラーからの回復を試みます。ESEXX ソースのイベント ビューアで [アプリケーション ログ] カテゴリの下のデータベース エラー イベントを表示すると、データベース エラーの詳細を確認することができます。長時間 (数時間) にわたってこのエラーが多数発生する場合には、データベースの復元が必要な可能性があります。エラー番号は、下のデータ セクションで 2 番目の DWORD にあります。このデータベース エラーは、アプリケーション ログに ESENT イベント 404、405、または 406 として登録されます。
4187	何らかのエラーが発生したため、名前登録応答を送信できませんでした。このエラーは名前チャレンジ スレッドで発生しました。
4202	アドレス XXXX.XXXX.XXXX.XXXX を使用してリモート WINS サーバーへの接続を試みた結果、エラーが返されました。利用可能なリモート WINS サーバーが実行されていて、そのサーバーで WINS が実行されていることを確認してください。
4243	WINS プル スレッドが、ほかの WINS にプッシュ通知を送信する手順で例外を検出しました。例外コードは、下のデータ セクションに示されています。
4260	WINS が、複製の登録中にエラーを処理しました。この時点では、この WINS (アドレスはデータ セクションの 4 番目から 8 番目のバイトです。前のログ エントリも確認してください) の複製はこれ以上登録されません。理由については、前のログ エントリを確認してください。このエラーが繰り返し発生する場合 (上記のパートナー WINS と再度複製が行われても同じエラーが発生する場合)、データベースの復元が必要な可能性があります。
4302	WINS がデータベース をディレクトリ d:\wins-database\backup\wins_bak にバックアップ中にエラーが発生しました。

 

WINS 容量トリガ

以下に示すのは、クライアントの動作に基づくシステムの必要条件を測定するために使用できる WINS 特有のパフォーマンス オブジェクトとカウンタです。これらのオブジェクトとカウンタは、Windows 2000 に含まれるパフォーマンス モニタ ツールを使用して参照することができます。

WINS オブジェクトとカウンタ	説明
Failed Queries/sec	Failed Queries/sec の総数です。
Failed Releases/sec	Failed Releases/sec の総数です。
Group Conflicts/sec	WINS サーバーが受け取ったグループ登録が原因で発生した、データベ ースのレコードに対する競合の数です。
Group Registrations/sec	WINS サーバーが受け取るグループ登録の 1 秒あたりの数です。
Group Renewals/sec	WINS サーバーが受け取るグループ書き換えの 1 秒あたりの数です。
Queries/sec	WINS サーバーが受け取る問い合わせの 1 秒あたりの数です。
Releases/sec	WINS サーバーが受け取る解除の 1 秒あたりの数です。
Successful Queries/sec	Successful Queries/sec の総数です。
Successful Releases/sec	Successful Releases/sec の総数です。
Total Number of Conflicts/sec	1 秒あたりの一意名競合とグループ競合の合計で、WINS サーバーが認識した競合の数です。
Total Number of Registrations/sec	1 秒あたりの一意名登録とグループ登録の合計数で、WINS サーバーが受け取る登録の合計です。
Total Number of Renewals/sec	1 秒あたりの一意名書き換えとグループ書き換えの合計数で、WINS サーバーが受け取る書き換えの合計です。
Unique Conflicts/sec	1 秒あたりの一意名書き換えとグループ書き換えの合計数で、WINS サ ーバーが受け取る書き換えの合計です。
Unique Registrations/sec	WINS サーバーが受け取る一意名登録の 1 秒あたりの数です。
Unique Renewals/sec	WINS サーバーが受け取る一意名書き換えの 1 秒あたりの数です。

 

このドキュメントは暫定版であり、このドキュメントに記載されている情報は、このドキュメントの発行日におけるマイクロソフトの見解を示すものです。マイクロソフトは市場の変化に対応する必要があるため、このドキュメントの内容に関する責任をマイクロソフトは問われないものとします。また、発行日以降に発表される情報の正確性を保証できません。

このドキュメントに記載されている内容は情報の提供のみを目的としており、明示または黙示に関わらず、これらの情報についてマイクロソフトはいかなる責任も負わないものとします。

Microsoft、Active Directory、Windows および Windows NTは、米国 Microsoft Corporation の登録商標または商標です。

その他、記載されている会社名､製品名には、各社の商標のものもあります。

© 2000 Microsoft Corporation. All rights reserved.

 ページのトップへ