3 マルチキャスト接続テストの実行

Coherenceにはマルチキャスト・テスト・ユーティリティが含まれ、ネットワーク環境がマルチキャスト通信をサポートしているかどうかを確認できます。本番デプロイメントの前に、マルチキャスト・テストの実行が成功する必要があります。

この章の内容は次のとおりです。

マルチキャスト・テスト・ユーティリティの実行

Coherenceマルチキャスト・テスト・ユーティリティは、2台以上のコンピュータ間でマルチキャストが有効にされているかどうかを判断するために使用します。このユーティリティは、負荷についてはテストしません。デフォルトでは、各インスタンスは2秒ごとに1つのマルチキャスト・パケットを送信します。ネットワーク負荷テストについては、ネットワーク・パフォーマンス・テストの実行を参照してください。

マルチキャスト・テスト・ユーティリティを実行するには、コマンド行からcom.tangosol.net.MulticastTestクラスを使用するか、COHERENCE_HOME/binディレクトリにあるmulticast-testスクリプトを実行します。スクリプトは、WindowsベースのプラットフォームとUNIXベースのプラットフォームの両方に用意されています。

次の例では、MulticastTestクラスを使用してユーティリティを実行します。

java com.tangosol.net.MulticastTest <command value> <command value> ...

次の例では、スクリプトを使用してユーティリティを実行します。

multicast-test <command value> <command value> ...

表3-1では、マルチキャスト・テスト・ユーティリティで利用できるコマンド行オプションについて説明しています。

表3-1 マルチキャスト・テスト・ユーティリティのコマンド行オプション

コマンド 必須/オプション 説明 デフォルト値

-local

オプション

送信を行うNICのアドレス、IPアドレスとして指定

localhost

-group

オプション

使用するマルチキャスト・アドレス、IP:ポートの形式で指定

237.0.0.1:9000

-ttl

オプション

マルチキャスト・パケットの有効時間

4

-delay

オプション

パケット送信間の遅延、秒単位で指定

2

-packetSize

オプション

送信するパケットのサイズ(デフォルトは、ローカルMTUに基づきます)

MTU

-display

オプション

予期しないパケットから表示されるバイト数

0

-translate

オプション

マルチキャスト・トラフィックのリッスンとパケットの変換

なし

マルチキャストのテスト方法

マルチキャストのテストにはステップが2つあります。個々のサーバーでマルチキャストが正しく機能していることの確認およびサーバー間でマルチキャストが正しく機能していることの確認です。

この項で示す例では、マルチキャスト・アドレス237.0.0.1、ポート9000(テストのデフォルト)で、サーバーA (IPアドレス195.0.0.1)とサーバーB (IPアドレス195.0.0.2)の2台のサーバー間でメッセージが送信できるかどうかをテストする方法について説明します。

ノート:

テストで使用されるデフォルトのマルチキャスト・アドレスおよびポートは、Coherenceのデフォルトのアドレスおよびポートとは異なります。テストは、実際のCoherenceプロセスで使用されている同じアドレスおよびポートを使用して実行する必要があります。マルチキャスト用のデフォルトのアドレスおよびポートが成功するが、Coherenceのデフォルトが失敗する可能性があります。この原因としてよくあるのが、ローカル・ネットワーク・ポリシーの構成です。

最初にサーバーAで、このコンピュータまたはインタフェースを次のように単独でチェックして、195.0.0.1で使用可能なマルチキャスト・アドレス237.0.0.1、ポート9000があるかどうかを判定します。

コマンド・プロンプトで、次のコマンドを入力します。

multicast-test.sh -ttl 0

[Enter]を押すと、ユーティリティによって、順次マルチキャスト・パケットの送受信状況が表示されます。例3-1にサンプル出力を示します。

例3-1 マルチキャスト・テスト・ユーティリティによって送信される順次マルチキャスト・パケット

Starting test on ip=servera/195.0.0.1, group=/237.0.0.1:9000,ttl=0
Configuring multicast socket...
Starting listener...
Tue Mar 17 15:59:51 EST 2008: Sent packet 1.
Tue Mar 17 15:59:51 EST 2008: Received test packet 1 from self.
Tue Mar 17 15:59:53 EST 2008: Sent packet 2.
Tue Mar 17 15:59:53 EST 2008: Received test packet 2 from self.
...

約5分間テストを実行し、障害がないことを確認します。テストを停止するには、[Ctrl]を押しながら[C]を押します。

前述のように表示されない場合は、マルチキャストが機能していません。また、TTLに0を指定することで、マルチキャスト・パケットがサーバーAから送信されないようにしていることに注目してください。

同じテストをサーバーBでも実行して、このポートの組合せでもマルチキャストが有効になっていることを確認できます。

次に、サーバーAとサーバーBの間のマルチキャスト通信をテストします。このテストでは、TTLにゼロ以外の値を使用して、それぞれのサーバーからパケットを送信できるようにします。デフォルトのテストではTTLに4が使用されますが、サーバーAとサーバーBの間のパケットのルーティングにさらに多くのネットワーク・ホップが必要な場合は、4より大きな値をTTLに指定します。

次のコマンドをそれぞれのサーバーのコマンド・ウィンドウに入力して[Enter]を押し、サーバーAとサーバーBのテストを開始します。

multicast-test.sh

次の例は、サーバーAのサンプル出力を示しています。

Starting test on ip=servera/195.0.0.1, group=/237.0.0.1:9000, ttl=4
Configuring multicast socket...
Starting listener...
Tue Mar 17 16:11:03 EST 2008: Sent packet 1.
Tue Mar 17 16:11:03 EST 2008: Received test packet 1 from self.
Tue Mar 17 16:11:05 EST 2008: Sent packet 2.
Tue Mar 17 16:11:05 EST 2008: Received test packet 2 from self.
Tue Mar 17 16:11:07 EST 2008: Sent packet 3.
Tue Mar 17 16:11:07 EST 2008: Received test packet 3 from self.
Tue Mar 17 16:11:09 EST 2008: Sent packet 4.
Tue Mar 17 16:11:09 EST 2008: Received test packet 4 from self.
Tue Mar 17 16:11:10 EST 2008: Received test packet 1 from ip=serverb/195.0.0.2, group=/237.0.0.1:9000, ttl=4.
Tue Mar 17 16:11:11 EST 2008: Sent packet 5.
Tue Mar 17 16:11:11 EST 2008: Received test packet 5 from self.
Tue Mar 17 16:11:12 EST 2008: Received test packet 2 from ip=serverb/195.0.0.2, group=/237.0.0.1:9000, ttl=4.
Tue Mar 17 16:11:13 EST 2008: Sent packet 6.
Tue Mar 17 16:11:13 EST 2008: Received test packet 6 from self.
Tue Mar 17 16:11:14 EST 2008: Received test packet 3 from ip=serverb/195.0.0.2, group=/237.0.0.1:9000, ttl=4.
Tue Mar 17 16:11:15 EST 2008: Sent packet 7.
Tue Mar 17 16:11:15 EST 2008: Received test packet 7 from self.
...

次の例は、サーバーBのサンプル出力を示しています。

Starting test on ip=serverb/195.0.0.2, group=/237.0.0.1:9000, ttl=4
Configuring multicast socket...
Starting listener...
Tue Mar 17 16:11:10 EST 2008: Sent packet 1.
Tue Mar 17 16:11:10 EST 2008: Received test packet 1 from self.
Tue Mar 17 16:11:11 EST 2008: Received test packet 5 from ip=servera/195.0.0.1, group=/237.0.0.1:9000, ttl=4.
Tue Mar 17 16:11:12 EST 2008: Sent packet 2.
Tue Mar 17 16:11:12 EST 2008: Received test packet 2 from self.
Tue Mar 17 16:11:13 EST 2008: Received test packet 6 from ip=servera/195.0.0.1, group=/237.0.0.1:9000, ttl=4.
Tue Mar 17 16:11:14 EST 2008: Sent packet 3.
Tue Mar 17 16:11:14 EST 2008: Received test packet 3 from self.
Tue Mar 17 16:11:15 EST 2008: Received test packet 7 from ip=servera/195.0.0.1, group=/237.0.0.1:9000, ttl=4.
...

サーバーAとサーバーBの例では、マルチキャスト・パケットを発行して、自身のパケットと相手方のパケット確認しています。これは、マルチキャストのデフォルトのアドレスおよびポートを使用して、これらのサーバー間でマルチキャストが正しく機能していることを示します。

ノート:

サーバーAは、サーバーBからのパケット1を受信するまでは自身のパケット(1-4)を観測します。

マルチキャスト通信のトラブルシューティング

双方向マルチキャスト通信で障害が発生する可能性のある問題がたくさんあります。障害が発見されたら、最も一般的な問題をトラブルシューティングのヒントで確認します。トラブルシューティングをしてもマルチキャストの問題を解決できない場合、ネットワーク管理者またはシステム管理者に連絡して、原因の調査と状況への対処を依頼してください。
  • ファイアウォール—マルチキャスト・テストを実行するコンピュータのいずれかでファイアウォールが採用されている場合は、ファイアウォールがトラフィックをブロックしている可能性があります。マルチキャスト・トラフィックを許可する方法の詳細は、オペレーティング・システムまたはファイアウォールのドキュメントを参照してください。

  • スイッチ—マルチキャスト・トラフィックを転送するようにスイッチが構成されていることを確認します。

  • 最初の成功後にマルチキャスト・テストが失敗する場合は、Coherenceノートで次を実行してみてください。

    tcpdump -i nic_device igmp
    

    nic_deviceは、NICデバイス名です。IGMP問合せメッセージ(v2またはv3のいずれか)がtcpdump出力に表示されていることを確認します。IGMP問合せメッセージを送受信できるようにスイッチが有効になっていることを確認します。また、定期的なIGMP問合せメッセージに応答するようにNICおよびOSネットワーキングが設定されていることを確認します。最後に、スイッチをチェックして、Coherenceサーバーで"IGMP結合"と"IGMP問合せメッセージ"の両方の確認応答が実行されることを確認します。次のように出力されます。

    07:58:33.452537 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP
     (2), length 40, options (RA))
     
    longcoh06a1-priv.emea.kuoni.int > igmp.mcast.net: igmp v3 report, 1 group
     record(s) [gaddr 192.168.0.5 to_ex, 0 source(s)]
     
    07:58:43.294453 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP
     (2), length 40, options (RA))
     
       longcoh06a1-priv.emea.kuoni.int > igmp.mcast.net: igmp v3 report, 1 group
     record(s) [gaddr 192.168.0.5 to_ex, 0 source(s)]
     
    07:58:51.782848 IP (tos 0xc0, ttl 1, id 3133, offset 0, flags [none], proto
     IGMP (2), length 36, options (RA))
     
       10.241.113.40 > all-systems.mcast.net: igmp query v3 [max resp time 10s]
     
    08:00:56.803800 IP (tos 0xc0, ttl 1, id 3134, offset 0, flags [none], proto
     IGMP (2), length 36, options (RA))
     
       10.241.113.40 > all-systems.mcast.net: igmp query v3 [max resp time 10s]
    …
    

    最初の2行は、マルチキャスト・グループに"参加する"サーバーです。残りの出力は、スイッチを起点とするIGMP問合せメッセージで、数分ごとに継続されます(それらを送信するようにスイッチが構成され、応答するようにNICが構成されている場合)。

  • IPv6—IPv6をサポートするオペレーティング・システムでは、JavaがIPv4ではなくIPv6を介したマルチキャスト・トラフィックのルーティングを試行することがあります。Javaシステム・プロパティjava.net.preferIPv4Stack=trueを指定して、IPv4ネットワーキングを実施してみてください。Coherenceクラスタ・メンバーはすべてIPv4またはIPv6のいずれかを使用する必要があり、両方を混在して使用することはできません。

  • ???の受信—テストで???の受信がレポートされた場合は、マルチキャスト・テスト以外のインスタンスから発信されたマルチキャスト・パケットを受信したことを示します。この状況は、テストを実行するときに、既存のCoherenceクラスタまたはその他のマルチキャスト・アプリケーションと同じマルチキャスト・アドレスを使用した場合に発生します。

  • 複数のNIC—コンピュータに複数のネットワーク・インタフェースが存在する場合は、-local testパラメータを使用して、明示的にインタフェースを指定してください。たとえば、サーバーAにIPアドレスが195.0.0.1と195.0.100.1の2つのインタフェースがある場合、テストのコマンド行に-local 195.0.0.1を含めると、マルチキャスト・パケットが最初のインタフェースを使用するようになります。さらに、マルチキャスト・トラフィックが目的のネットワーク・インタフェースを通じて転送されるように、コンピュータのルーティング表を明示的に構成することも必要になる場合があります。これは、次のコマンドを発行することで実行できます。

    route add -net 224.0.0.0 netmask 240.0.0.0 dev eth1
    

    eth1は、マルチキャスト・トラフィックの送信先になるデバイスです。

  • AIX: AIXシステムでは、マルチキャストに関して次の問題が発生する場合があります。

    • IPv6—java.net.preferIPv4Stack=trueを指定することに加え、IPv4の名前解決を実行するためにオペレーティング・システムに追加の構成が必要になることがあります。/etc/netsvc.confファイルに、hosts=local,bind4を追加してください。

    • 仮想IP (VIPA)—AIXでは、VIPAを使用したマルチキャストがサポートされていません。VIPAを使用する場合は、VIPAでないデバイスにマルチキャストをバインドするか、またはマルチキャストを無効にしてCoherenceを実行します。Oracle Coherenceでのアプリケーションの開発ウェル・ノウン・アドレスの使用を参照してください。

    • MTU—マルチキャスト・デバイスのMTUを1500バイトに構成します。

  • Cisco社製スイッチ—Cisco社製スイッチへのデプロイを参照してください。

  • Foundry社製スイッチ—Foundry社製スイッチへのデプロイを参照してください。