次の方法で共有

エンタプライズ ネットワークへの WINS の導入

  • [アーティクル]

このシナリオでは、Windows インターネット ネーム サービス (WINS) を実装して、NetBIOS 名の解決機能を提供するように Microsoft® Windows® 2000 Server を構成し、Windows 2000 以前のバージョンの Windows クライアントの存在するネットワークをサポートします。

トピック

目的
設計のロジック
機能するしくみ
実装した方法
セットアップ手順
その他の参考資料

目的

この導入実験シナリオでは、Windows 2000 および以前のバージョンの Windows を実行するクライアントおよびサーバーで構成されるエンタプライズ環境を対象にしています。NetBIOS 名前解決機能では、古いクライアントおよび Windows 2000 クライアントの両方がサポートされます。このようなエンタプライズ向けのソリューションを計画する際に、以下のような目的を確認しました。

  • NetBIOS 名の IP アドレスへの解決を自動化し、管理者による関与を最小限に抑えます。

  • 以前のバージョンの Windows を実行するクライアント コンピュータの NetBIOS 名の解決を可能にします。

  • ワイド エリア ネットワーク (WAN) 接続上のトラフィックを最小限に抑え、名前解決処理のパフォーマンスを向上させます。

  • NetBIOS 名前解決処理で高水準のフォールト トレランス性を提供します。

  • リモート WINS サーバーを使用して、小規模な支社の管理にかかわる作業量とコストを低減させます。

次のセクション「設計のロジック」では、上記の目的をどのようにして達成したか説明します。

設計のロジック

このシナリオでは、エンタプライズ環境全体でリソースの共有を必要とする国際的な企業を想定します。シナリオではこの目的のために、4 つのサイトのみに焦点を当てます。この企業の本社は Seattle にあります。本社では、企業の IT に関する大半の意志決定が行われ、さらにそれが実装されるデータ センターにもなっています。支社は、Vancouver, B.C.、Hong Kong SAR、および Tokyo にあります。

ネットワーク上で NetBIOS 名を解決し、リソースを利用可能にするために、WINS サーバーが導入されています。図 1 にネットワークの構造を示します。

wins-01-01
図 1: エンタプライズのインフラストラクチャ

Windows 2000 以前のバージョンの Windows では一般に、NetBIOS 名によってネットワーク サービスが登録されています。WINS は、ネットワークでクライアントの追加/削除が行われている間、NetBIOS 名と IP アドレスのデータベースを自動的に維持します。WINS の代替手段として使用可能な Lmhosts では、データベースを最新に保つために NetBIOS 名および IP アドレスを手動で入力する必要があり、大規模なネットワークでは非実用的です。したがってこのシナリオでは、NetBIOS 名の解決のために WINS を採用します。これによって、NetBIOS 名の解決機能を提供しながら、管理者の介在を最小限に抑えるという目的を達成できます。

このシナリオの目的には、トラフィックを最小限に抑えながら、名前解決処理のパフォーマンスを向上させることもあります。この理由のために、100 台を超えるクライアントを有するサイトごとに、少なくとも 1 台のプライマリ WINS サーバーを導入しました。このような方法でプライマリ WINS サーバーを使用することによって、クライアントのすべての照会および登録がローカル プライマリ WINS サーバーで対処されるので、WAN 接続を経由する WAN 上のトラフィックを低減させることができます。

さらに、名前解決処理の可用性を非常に高く保つ必要があります。WINS クライアントには、名前の解決時に照会するプライマリおよびセカンダリの WINS サーバーの IP アドレスを構成します。たとえば、Vancouver のクライアントは、名前解決時に Vancouver の WINS サーバーを照会します。Vancouver のサーバーが応答しない場合、Vancouver のクライアントはそのセカンダリ WINS サーバーである Seattle のクラスタ WINS サーバーへの照会を試みます。

ハブアンド スポーク モデルおよび WINS データベースの複製処理によって、WINS のフォールト トレランス性が維持されています。図 2 は、リソース キット導入実験における複製ハブ、スポーク、および複製パートナーの関係を示しています。

wins-01-02
図 2: 複製パートナー

導入実験では、WINS サーバー複製処理の標準モデルとして、ハブアンドスポーク モデルを選択しました。この設計は、WINS 複製パートナーをセットアップするための信頼性の高い手法です。このモデルでは、コンピュータの複製関係が概念的に、車輪の中心とそのスポークに類似しています。Seattle のクラスタ WINS サーバーがハブに相当し、その他の WINS サーバー (Hong Kong SAR WINS サーバー、Seattle プライマリ WINS サーバー、および Vancouver, B.C. WINS サーバー) は、ハブから放射するスポークに当たります。WINS クライアントでは、このスポーク (WINS サーバー) をプライマリ WINS サーバーとして使用します。ハブ (Seattle のクラスタ WINS サーバー) は、クライアントのセカンダリ WINS サーバーとして構成されています。このモデルでは、スポークで名前登録および名前解決を担当し、ハブでその他の WINS サーバーの複製を実行するように WINS トラフィックを分配します。クライアントのプライマリ WINS サーバーの利用が不可能になった場合にのみ、複製ハブによって NetBIOS 名の解決と登録が実行されます。これによって、複製処理のためにハブをより有効に利用できます。

複製パートナーは、プッシュ/プル パートナー (図 2 の矢印で示されています) として構成します。これによって、複製パートナー間で相互の複製物の伝送が保証されます。Seattle のクラスタ WINS サーバーは、Hong Kong の WINS サーバー、Seattle のプライマリ WINS サーバー、および Vancouver, B.C. の WINS サーバーに対してプッシュ/プル パートナーとして構成されています。すべての WINS データベースにすべてのエントリが伝播するまで複製処理が継続されます。

この複製では複製ハブが処理の中心になるので、リソース キット導入実験では Seattle のセカンダリ WINS サーバー用にフェール オーバー クラスタを使用しています。Seattle のフェール オーバー クラスタは 2 台のサーバーから構成され、1 台のサーバーはアクティブなノード、もう 1 台のサーバーは受動的なノードとして構成されます。ネットワーク上でクラスタ WINS サーバーは単一の WINS サーバーになりますが、アクティブなノードが利用不可能になった場合には、受動的なノードがアクティブなノードに自動的に昇格します。このために、WINS の複製処理を中断することなく継続できます。

Tokyo では名前解決を要求するクライアントの台数が 100 未満であるため、WINS サーバーは導入されていません。Tokyo サイトの名前解決機能は、Hong Kong SAR の WINS サーバーによって提供されます。したがって、WINS サーバーを追加した場合にかかるコストと管理作業の発生を回避できます。

Windows 2000 ベースのクライアント、サーバー、およびアプリケーションのみで構成されるネットワークでは、DNS 名だけが使用されるので WINS は必要ありません。しかし、NetBIOS 名前解決を必要とする以前の Windows ベースのクライアントおよびアプリケーション ソフトウェアが依然として広く使用されているので、エンタプライズ コンピューティング環境において WINS は引き続き重要なサービスになっています。エンタプライズ ネットワークにおいて WINS サーバーを適切に導入および構成することによって、フォールト トレランス性の維持、ネットワーク トラフィックの低減、そしてリソースの可用性の向上を実現できます。

機能するしくみ

このシナリオでは、リソース キット導入実験において WINS をどのようにして使用したかを示します。ここでは、クライアントが NetBIOS 名および IP アドレスを WINS データベースに入力する方法、NetBIOS 名前マッピングがエンタプライズ内のその他のすべての WINS データベースに伝播するしくみ、そしてクライアントが WINS を使用して NetBIOS 名から IP アドレスを取得する方法を明らかにします。図 3 に、エンタプライズ環境の全体的なトポロジを示します。

wins-01-01
図 3: エンタプライズのトポロジ

NetBIOS 名の登録、WINS データベースの複製、そして NetBIOS 名前解決の各処理は以下の手順で行われます。

  1. Tokyo のクライアントがネットワークに初めてログオンすると、NetBIOS 名 (toyclient) および IP アドレスを登録するために、WINS サーバーに名前登録要求を送信します。NetBIOS クライアントは図 4 のようにして、動作している各 NetBIOS サービスに名前登録要求を送信します。

    wins-01-12
    図 4: 名前の登録

  2. WINS データベース内に重複した NetBIOS 名が存在しなければ、サーバーは新しい NetBIOS 名前レコードを挿入してそれに NetBIOS 名の種類とバージョン ID を割り当て、NetBIOS 名を所有する WINS サーバーを特定して、タイム スタンプでマークします。図 5 で示すように、名前が登録されたことを通知する名前登録の肯定応答がクライアントに送信されます。

    wins-01-21
    図 5: Hong Kong SAR の WINS データベースの内部

  3. 図 6 の矢印で示すように、Hong Kong SAR の WINS サーバーは、プッシュ/プル複製パートナーである Seattle のクラスタ WINS サーバーに対して、新しい WINS エントリの複製を実行します。

    wins-01-32
    図 6: プッシュ/プル パートナーへの複製

  4. Seattle のクラスタ WINS サーバーは、2 つのノードから構成されていますが、エンタプライズ上ではその機能はほかのサーバーと同じように見えます。しかしクラスタ内では、一方のノード (アクティブなノード) から絶え間なくクラスタ内のもう一方のノード (受動的なノード) に信号が送信されています。この信号が停止すると、受動的なノードがアクティブなノードに自動的に昇格し、サーバーは以前と同じように機能し続けます (図 7 を参照) 。

    wins-01-42
    図 7: 受動的なノードからアクティブなノードへの昇格

  5. Hong Kong の SAR WINS サーバーの複製相手である Seattle のクラスタ WINS サーバーは、新しいエントリを受け取ります。このエントリが Seattle のクラスタ サーバーに追加され、Seattle のプライマリ WINS サーバーおよび Vancouver, B.C. の WINS サーバーにエントリが複製されます。Tokyo の新しいエントリは、図 8 で示すように、プッシュ/プル複製パートナーである Seattle のプライマリ サーバーおよび Vancouver, B.C. のサーバーの両方の WINS データベースに挿入されます。

    wins-01-52
    図 8: ハブは、ほかのスポーク (WINS サーバー) に複製します。

  6. Vancouver, B.C. のユーザーが NetBIOS コマンド (たとえば net use \\toyclient など) を入力した場合を考えてみましょう。この場合、WINS クライアントは既定で H ノードとして構成されるので、NetBIOS 名 (\\toyclient) の名前解決を要求するために、Vancouver, B.C. WINS サーバーに宛てられたデータ グラムを送信します (図 9 を参照) 。

    wins-01-62
    図 9: 名前照会要求パケット

  7. Vancouver, B.C. WINS クライアントからのこの名前照会要求パケットを Vancouver, B.C. WINS サーバーが受け取ると、Vancouver, B.C. WINS サーバーは、そのデータベース内で該当する NetBIOS 名前を探索します。その後、net use コマンドで Tokyo のクライアントにアクセスするために使用した関連する IP アドレスを含む名前解決応答パケットを返します (図 10 を参照) 。

    wins-01-73
    図 10: 名前解決の応答

実装した方法

このシナリオにおいて、コンピュータおよびデバイスを構成するために使用した手続きは、サンプルとして示したものです。実際の各ネットワークでは、類似したコンピュータおよびデバイスを構成する場合でも、必要になる手順はそれぞれのケースで異なります。さらに各シナリオでは、そのシナリオの機能を実現するために必要な手順だけを示しています。

このシナリオでは、エンタプライズ ネットワーク内で WINS を使用して、以下の作業を実施しました。

  1. WINS サーバーのネットワーク アダプタを以下の IP アドレス情報で静的に構成します。

    • IP アドレス

    • サブネット マスク

    • デフォルト ゲートウェイ

    • DNS サーバー

  2. すべての WINS サーバー上で WINS サービスをインストール、構成します。

  3. Seattle クラスタ ノード (SEA-NA-WINS-02 および SEA-NA-WINS-03) 上でクラスタ サービスをインストール、構成します。

  4. WINS サービス用のクラスタ リソースを作成し、クラスタをオンラインにします。

  5. 次に、WINS サーバーを相互に複製するように構成します。

このセットアップ手順では、以下の構成を仮定しています。

  1. 各コンピュータで、管理者の権利とパスワードが必要です。通常 WINS サーバーは、ローカルにセットアップされ、中央で管理されます。

  2. 各コンピュータは、再フォーマットされた後、適切なオペレーティング システムがインストールされ、適切な名前が付けられています。

  3. 動的ホスト構成プロトコル (DHCP) を使用することによって、サーバーから WINS クライアントに IP アドレスを動的に割り当てることができます。この場合、サブネットごとに DHCP スコープを作成します。各スコープには、ログオン時に Windows 2000 クライアントに割り当てられる一連の IP アドレスが含まれています。各 DHCP スコープ内では、最善の慣行あるいは何らかの要件のために静的なアドレスを持つ必要のあるデバイス (WINS サーバーなど) のために、静的な割り当て用の IP アドレスが予約されています。

  4. 既定の設定で DHCP オプション 44 が構成されます。DHCP オプション 44 は、NetBIOS 名の解決のために使用する プライマリ WINS サーバーおよびセカンダリ WINS サーバーの IP アドレス を WINS クライアントに提供します。

  5. DHCP サーバーのスコープごとに、DHCP オプション 46 を選択します。オプション 46 では、NetBIOS over TCP/IP (NetBT) で使用されるクライアント ノードの種類を構成します。ネットワーク上のブロードキャストを最小限に抑えるために、H ノード (Windows 2000 の既定のノードの種類) を選択します。

  6. すべてのオプションの既定の設定を使用して、WINS サーバーを構成します。WINS サーバーのネットワーク アダプタでは、静的な IP アドレスを構成します。WINS クライアントでは、既定の設定の DHCP を使用して、DNS、WINS、および IP のアドレス指定を動的に構成します。

  7. クラスタ WINS サーバーは、Microsoft® Windows® 2000 Advanced Server を実行する 2 つのノードから構成されます。この 2 つのノードにはそれぞれ、2 つのネットワーク アダプタが存在します。各ノードの一方のネットワーク アダプタをエンタプライズ ネットワークに接続します。そしてもう一方のネットワーク アダプタをクラスタ内の別のノードに接続して、クラスタ内でのノード間通信を可能にします。これはプライベート ネットワークです。最善の慣行に従う場合、単一点での障害を抑止するために、この相互接続 (プライベートネットワーク) を 2 つ以上使用する必要があります。

  8. Microsoft Advanced Server のインストール中に、ノード SEA-NA-WINS-02 および SEA-NA-WINS-03 TCP/IP の TCP/IP パラメータを表 1 および 2 の値で構成しました。

    表 1 ノード SEA-NA-WINS-02 の TCP/IP パラメータ

    パラメータ

    値

    IP アドレス

    172.16.32.16

    サブネット マスク

    255.255.252.0

    デフォルト ゲートウェイ

    172.16.32.1

    優先 DNS サーバー

    172.16.4.11

    代替 DNS サーバー

    172.16.8.11

    WINS アドレス

    172.16.32.18

    表 2 ノード SEA-NA-WINS-03 の TCP/IP パラメータ

    パラメータ

    値

    IP アドレス

    172.16.32.17

    サブネット マスク

    255.255.252.0

    デフォルト ゲートウェイ

    172.16.32.1

    優先 DNS サーバー

    172.16.4.11

    代替 DNS サーバー

    172.16.8.11

    WINS アドレス

    172.16.32.18

    WINS サーバーの TCP/IP パラメータの構成例については、「セットアップ手順」の Hong Kong SAR WINS サーバーを構成する手順を参照してください。

  9. Tokyo の WINS クライアントと Vancouver, B.C. の WINS クライアントは、既定の構成で動作する Microsoft® Windows® 2000 Professional です。

  10. サイト Hong Kong SAR および Seattle では、ルーター構成スクリプトで示すように Cisco ルーターが構成されています。詳細については、ルーター構成スクリプトを参照してください。

    注意
    このシナリオで使用している IP アドレスは、プライベート ネットワーク用に予約された IP アドレス範囲内のアドレスです。テスト環境内やファイアウォールの背後ではこれらの IP アドレスを使用することはできますが、インターネット上では使用できません。詳細については、RFC 1918 を参照してください。

表 3 に、リソース キット導入実験のこのシナリオを開発するために使用した、ハードウェアおよびソフトウェアのリストを示します。

表 3 リソース キット導入実験で WINS を導入するために使用したコンポーネント

コンポーネント

ハードウェア

ソフトウェア

Tokyo WINS クライアント

Toyclient

Compaq Desktop コンピュータ

Windows 2000 Professional

Tokyo ルーター

TOY-AC-W2RT-01

Compaq ProLiant サーバー

Windows 2000 Server

Hong Kong SAR WINS サーバー

HKG-AC-DHCP-01

Compaq ProLiant サーバー

WINS サービス

Windows 2000 Server

Hong Kong SAR ルーター

HKG-AC-CISCO-01

Cisco Model 7507 ルーター

Cisco IOS version 12.1 (2)

Seattle クラスタ WINS サーバー

SEA-NA-WINS-04

Compaq ProLiant サーバー (2)

SCSI 記憶装置

WINS サービス

クラスタ サービス

Windows 2000 Advanced Server

Seattle プライマリ WINS サーバー
SEA-NA-WINS-01

Compaq ProLiant サーバー

WINS サービス

Windows 2000 Server

Seattle ルーター

SEA-NA-CISCO-01

Cisco Model 7513 ルーター

Cisco IOS version 12.1 (2)

Vancouver,B.C. WINS サーバー

VAN-NA-DC-01

Compaq ProLiant サーバー

WINS サービス

Windows 2000 Server

Compaq ProLiant サーバー

Vancouver, B.C. WINS クライアント

vanclient

Compaq Desktop コンピュータ

Windows 2000 Professional

Vancouver, B.C. ルーター

VAN-NA-W2RT-01

Compaq ProLiant サーバー

Windows 2000 Server

注意
クラスタ技術を使用する場合、以下の警告および推奨に注意して従うことが重要です。

  • この後で紹介する操作手順については、特定の SCSI 記憶装置を使用して動作確認を行いました。したがって、ファイバ チャネル記憶装置を使用したり、モデルや製造元が異なる SCSI 記憶装置を使用したりした場合には、操作手順が異なります。実際の運用ネットワークとしては、ファイバ チャネル記憶装置を選択することが重要です。

  • ハードウェアを選択する場合には、クラスタ化で使用可能なハードウェアとして推奨されている機種について、Windows 2000 ハードウェア互換性リストを事前に参照し、さらにそのハードウェアの製造元に確認を行ってください。

  • ハードウェアおよびソフトウェアのセットアップ手順において、コンピュータと記憶装置の電源を入れたり切ったりすることが必要になるタイミングは、それぞれの稼働環境のインストールによって異なります。これらの手順を誤ると、記憶装置に保存されているデータを破損する結果になる可能性があるので、十分に注意してください。

Windows 2000 Advanced Server のクラスタ化について詳しくは、導入実験シナリオ "Consolidating File-Share Servers onto One Server Cluster" を参照してください。

セットアップ手順

このシナリオをセットアップするために、以下の作業を実施しました。

  1. Hong Kong SAR WINS サーバー HKG-AC-DHCP-01 の構成

  2. クラスタ WINS サーバー SEA-NA-WINS-04 の構成

  3. Seattle プライマリ WINS サーバー SEA-NA-WINS-01 の構成

  4. Vancouver, B.C. WINS サーバー VAN-NA-DC-01 の構成

  5. WINS サーバー複製パートナーの構成

図 11 に、このシナリオで構成したサーバーおよびクライアントを示します。

wins-01-01
図 11: エンタプライズ ネットワーク内で構成されたハードウェア

その他の参考資料

WINS およびそれに関連するトピックについてさらに詳しく調べたい方は、以下の資料を参考にしてください。

導入実験のシナリオ

  • Windows 2000 Advanced Server のクラスタ化について詳しくは、"Consolidating File-Share Servers onto One Server Cluster" を参照してください。

  • DHCP の導入について詳しくは、導入実験のシナリオ『複数のサブネット環境のための DHCP 構成』を参照してください

Microsoft Windows 2000 Server リソース キット

  • WINS について詳しくは、『Microsoft Windows 2000 Server リソース キット 6　TCP/IP ガイド』の「第 7 章 WINS (Windows Internet Name Service) 」を参照してください。

  • DHCP について詳しくは、『Microsoft Windows 2000 Server リソース キット 6　TCP/IP ガイド』の「第 4 章 DHCP (動的ホスト構成プロトコル) 」を参照してください。

ツール

  • Netshell

    Netshell はコンソール ベースの管理機能の代わりに使用できるコマンドライン ツールです。Netshell について詳しくは、『Microsoft Windows 2000 Server リソース キット 6　TCP/IP ガイド』の「第 7 章 WINS (Windows Internet Name Service) 」を参照してください。

  • Ipconfig

    Ipconfig は、WINS クライアントまたは WINS サーバーの TCP/IP 構成設定を表示する コマンドライン ツールです。Ipconfig の詳細については『Microsoft Windows 2000 Server リソース キット 6　TCP/IP ガイド』の「第 3 章 TCP/IP のトラブルシューティング」、および『Microsoft Windows 2000 Professional リソース キット 下』の「第 31 章 トラブルシューティングツールと戦略」を参照してください。

  • Nbtstat

    Nbtstat は、リモート名のためのローカル NetBIOS 名キャッシュを破棄し、クライアントのローカル名を即時に更新して、再登録を強制するコマンド ライン ツールです。Nbtstat の詳細については『Microsoft Windows 2000 Server リソース キット 6　TCP/IP ガイド』の「第 3 章 TCP/IP のトラブルシューティング」、および『Microsoft Windows 2000 Professional リソース キット 下』の「第 31 章 トラブルシューティングツールと戦略」を参照してください。

Windows 2000 Server ドキュメント

RFC (Requests for Comments)

  • NetBIOS の詳細については、RFC Editor Web サイトleave-ms (英語) のRFC 1001、「Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Concepts and Methods」を参照してください。

  • NetBIOS の詳細については、RFC Editor Web サイトleave-ms (英語) の RFC 1002、「Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Detailed Specifications」を参照してください。

導入実験の詳細と協力企業について

リソース キット導入実験シナリオの凡例

  • Microsoft Windows 2000 リソース キット導入実験シナリオのネットワーク図で使用されている略語や記号について詳しくは、『導入実験シナリオの凡例』を参照してください。

リソース キット導入実験のネットワーク図

  • ネットワークの設計、ネットワーク ルーティング設計、ドメイン ネーム システム (DNS) 設計、および Active Directory 階層の高水準の編成については、『導入実験のネットワーク図』を参照してください。

関連資料

注意
このシナリオにおいて、コンピュータおよびデバイスを構成するために使用した手続きは、サンプルとして紹介したものです。実際のネットワークでは、類似したコンピュータおよびデバイスを構成する場合でも、必要になる手順はそれぞれのケースで異なります。さらに各シナリオでは、目的とする機能を実現するために必要な手順だけを示しています。運用ネットワークにおいて必要になる、その他の手順については取り上げていません。すべてのシナリオは、特に表記しない限り Windows 2000 を使用してテストされています。また、ブラウザとして Microsoft Internet Explorer 5 以上を推奨します。