| Oracle® Coherence管理者ガイド リリース3.7.1 B71688-01 |
|
 前 |
 次 |
この章では、様々なプラットフォームにCoherenceをデプロイする際に考慮する問題を識別します。可能な場合は、その解決策も示します。
この章には次の項が含まれます:
AIXにCoherenceをデプロイする場合は、次の事項に留意してください。
AIX 5.2以降では、デフォルトで、IPv4ではなくIPv6を使用してマルチキャストを実行するように設定されています。IPv6とIPv4が混在した環境で実行する場合には、IPv4を明示的に使用するようにJVMを構成します。それには、Javaコマンドラインでシステム・プロパティjava.net.preferIPv4Stackをtrueに設定します。詳細は、『IBM 32-bit SDK for AIX User Guide』を参照してください。
Cisco社製スイッチを使用してCoherenceをデプロイする場合は、次の事項に留意してください。
UDPパケットの負荷が重いと、一部のCisco社製スイッチでは、バッファ・スペースが不足し、数秒間の通信停止が頻繁に発生する場合があります。このような通信の停止は、ローカルまたはリモートのGCに起因しない複数ノードでの通信の遅延を指す、一連のCoherenceログ・メッセージにより特定できます。
Experienced a 4172 ms communication delay (probable remote GC) with Member(Id=7, Timestamp=2008-09-15 12:15:47.511, Address=xxx.xxx.x.xx:8089, MachineId=13838); 320 packets rescheduled, PauseRate=0.31, Threshold=512
Cisco 6500シリーズでは、各イーサネット・ポートまたはASICで使用可能なバッファ領域の容量を構成できます。負荷の高いアプリケーションでは、デフォルトのバッファ領域の増大が必要になる場合があります。これを実現するには、次を実行します。
fabric buffer-reserve high
この設定の詳細は、Ciscoのドキュメントを参照してください。
Cisco社のデフォルトのスイッチ構成では、IGMPスヌーピングを使用しているため、スイッチ間でのマルチキャスト・パケットの適切なルーティングがサポートされていません。この問題およびその解決策に関するCiscoのドキュメントを参照してください。
一部のCisco社製スイッチでは、マルチキャスト・グループのメンバーシップの維持が難しいため、既存のマルチキャスト・グループのメンバーが、通知されることなくマルチキャスト・グループから削除されることがあります。これにより、関連付けられたCoherenceノードに部分的な通信切断が発生し、クラスタからの離脱と再参加が強制的に行われます。このような停止はほとんどの場合、部分的な通信上の問題が検出されたことを示す次のCoherenceログ・メッセージによって識別できます。
A potential network configuration problem has been detected. A packet has failed to be delivered (or acknowledged) after 60 seconds, although other packets were acknowledged by the same cluster member (Member(Id=3, Timestamp=Sat Sept 13 12:02:54 EST 2008, Address=xxx.xxx.x.xxx, Port=8088, MachineId=48991)) to this member (Member(Id=1, Timestamp=Sat Sept 13 11:51:11 EST 2008, Address=xxx.xxx.x.xxx, Port=8088, MachineId=49002)) as recently as 5 seconds ago.
この問題を確認するには、実行中のクラスタと同じマルチキャスト・アドレスとポートを使用します。この問題がマルチキャスト・テスト・ノードに影響する場合は、マルチキャスト・テスト・メッセージの受信が突然停止したことが、そのログに記録されます。第5章「マルチキャスト接続テストの実行」を参照してください。
次のテスト・ログはこの問題を示しています。
例2-1 マルチキャストの停止に関するログ
Test Node 192.168.1.100: Sun Sept 14 16:44:22 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ??? Sun Sept 14 16:44:23 GMT 2008: Received test packet 76 from ip=/192.168.1.101, group=/224.3.2.0:32367, ttl=4. Sun Sept 14 16:44:23 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ??? Sun Sept 14 16:44:23 GMT 2008: Sent packet 85. Sun Sept 14 16:44:23 GMT 2008: Received test packet 85 from self. Sun Sept 14 16:44:24 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ??? Sun Sept 14 16:44:25 GMT 2008: Received test packet 77 from ip=/192.168.1.101, group=/224.3.2.0:32367, ttl=4. Sun Sept 14 16:44:25 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ??? Sun Sept 14 16:44:25 GMT 2008: Sent packet 86. Sun Sept 14 16:44:25 GMT 2008: Received test packet 86 from self. Sun Sept 14 16:44:26 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ??? Sun Sept 14 16:44:27 GMT 2008: Received test packet 78 from ip=/192.168.1.101, group=/224.3.2.0:32367, ttl=4. Sun Sept 14 16:44:27 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ??? Sun Sept 14 16:44:27 GMT 2008: Sent packet 87. Sun Sept 14 16:44:27 GMT 2008: Received test packet 87 from self. Sun Sept 14 16:44:28 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ??? Sun Sept 14 16:44:29 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ??? Sun Sept 14 16:44:29 GMT 2008: Sent packet 88. Sun Sept 14 16:44:29 GMT 2008: Received test packet 88 from self. Sun Sept 14 16:44:30 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ??? Sun Sept 14 16:44:31 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ??? Sun Sept 14 16:44:31 GMT 2008: Sent packet 89. Sun Sept 14 16:44:31 GMT 2008: Received test packet 89 from self. Sun Sept 14 16:44:32 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ??? Sun Sept 14 16:44:33 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ??? Test Node 192.168.1.101: Sun Sept 14 16:44:22 GMT 2008: Sent packet 76. Sun Sept 14 16:44:22 GMT 2008: Received test packet 76 from self. Sun Sept 14 16:44:22 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ??? Sun Sept 14 16:44:22 GMT 2008: Received test packet 85 from ip=/192.168.1.100, group=/224.3.2.0:32367, ttl=4. Sun Sept 14 16:44:23 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ??? Sun Sept 14 16:44:24 GMT 2008: Sent packet 77. Sun Sept 14 16:44:24 GMT 2008: Received test packet 77 from self. Sun Sept 14 16:44:24 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ??? Sun Sept 14 16:44:24 GMT 2008: Received test packet 86 from ip=/192.168.1.100, group=/224.3.2.0:32367, ttl=4. Sun Sept 14 16:44:25 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ??? Sun Sept 14 16:44:26 GMT 2008: Sent packet 78.Sun Sept 14 16:44:26 GMT 2008: Received test packet 78 from self. Sun Sept 14 16:44:26 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ??? Sun Sept 14 16:44:26 GMT 2008: Received test packet 87 from ip=/192.168.1.100, group=/224.3.2.0:32367, ttl=4. Sun Sept 14 16:44:27 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ??? Sun Sept 14 16:44:28 GMT 2008: Sent packet 79. Sun Sept 14 16:44:28 GMT 2008: Received test packet 79 from self. Sun Sept 14 16:44:28 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ??? Sun Sept 14 16:44:28 GMT 2008: Received test packet 88 from ip=/192.168.1.100, group=/224.3.2.0:32367, ttl=4. Sun Sept 14 16:44:29 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ??? Sun Sept 14 16:44:30 GMT 2008: Sent packet 80. Sun Sept 14 16:44:30 GMT 2008: Received test packet 80 from self. Sun Sept 14 16:44:30 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ??? Sun Sept 14 16:44:30 GMT 2008: Received test packet 89 from ip=/192.168.1.100, group=/224.3.2.0:32367, ttl=4. Sun Sept 14 16:44:31 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ??? Sun Sept 14 16:44:32 GMT 2008: Sent packet 81.Sun Sept 14 16:44:32 GMT 2008: Received test packet 81 from self. Sun Sept 14 16:44:32 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ??? Sun Sept 14 16:44:32 GMT 2008: Received test packet 90 from ip=/192.168.1.100, group=/224.3.2.0:32367, ttl=4. Sun Sept 14 16:44:33 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ??? Sun Sept 14 16:44:34 GMT 2008: Sent packet 82.
16:44:27に、最初のテスト・ノードで、他のコンピュータからのマルチキャスト・パケットの受信が停止しました。オペレーティング・システムにより、同一コンピュータ上のその他のプロセスからのマルチキャスト・トラフィックは、引き続き適切に転送されましたが、2番目のテスト・ノードからのテスト・パケット(79以降)は受信されませんでした。また、テスト・パケットおよび最初のノードによって生成されたクラスタのマルチキャスト・トラフィックは両方とも、引き続き2番目のノードに配信されました。これは、最初のノードがマルチキャスト・グループから通知なく削除されたことを示します。
このマルチキャストに関する問題が発生した場合は、Cisco社のテクニカル・サポートに連絡してください。または、Coherenceのwell-known-addresses機能を使用して、ユニキャストのみの構成に変更することも検討してください。アドレス構成の詳細は、<well-known-addresses要素を参照してください。
Foundry社製スイッチを使用してCoherenceをデプロイする場合は、次の事項に留意してください。
Foundry社製スイッチでは、マルチキャスト・トラフィックの処理が困難です。Foundry社製スイッチを使用してデプロイするときには、Coherenceクラスタに属するすべてのコンピュータがマルチキャスト通信できることを確認してください。第5章「マルチキャスト接続テストの実行」を参照してください。
マルチキャストに関する問題が発生した場合は、well-known-addresses機能を使用してユニキャストのみの構成に変更することも検討してください。アドレス構成の詳細は、<well-known-addresses要素を参照してください。
IBM BladeCenterにCoherenceをデプロイする場合は、次の事項に留意してください。
BladeCenterへの通常のデプロイには、それぞれ管理用とクラスタ・トラフィック用の2つのNICを備えたブレードが使用されます。デフォルトでは、BladeCenterのブレードに割り当てられるMACアドレスには均一性があるため、通常最初のNICには偶数のMACアドレスが、2番目のNICには奇数のMACアドレスが割り当てられます。また、中央のスイッチへのBladeCenterのアップリンクにも偶数個のチャンネルがある場合は、レイヤー2 (MACベース)のロード・バランシングにより、使用可能なアップリンクの全帯域幅が1セットのNICで消費されないように調整されます。すべてのNICは、偶数個または奇数個のチャンネルのどちらかにバインドされるためです。この問題は、スイッチではMACアドレスが基本的にランダムであるという前提によるものですが、BladeCenterには当てはまりません。この状況の対応策は次のとおりです。
レイヤー3 (IPベース)のロード・バランシングを使用します(IPアドレスが同じ偶数/奇数パターンを踏襲しない場合)。
この設定は、クラスタ・トラフィックの伝送を行うすべてのスイッチに適用する必要があります。
代替コンピュータの1番目と2番目のNIC間でMACアドレスを入れ替えることにより、MACアドレスの割当てをランダムにします。
Linuxでは、ifconfigコマンドを使用してNICのMACアドレスを変更できます。
その他のオペレーティング・システムでも、カスタム・ツールを使用して同様のタスクを実行できる場合があります。
IBM JVMにCoherenceをデプロイする場合は、次の事項に留意してください。
JVMでOutOfMemoryErrorが発生すると、エラーが未解決の状態のままになることがあり、クラスタに悪影響を与える可能性があります。OutOfMemoryErrorが発生した場合は、JVMでリカバリを試みられるようにするのではなく、JVMを終了するように構成することをお薦めします。IBM JVMでこの設定を構成するパラメータは次のとおりです。
UNIXの場合:
-Xdump:tool:events=throw,filter=java/lang/OutOfMemoryError,exec="kill -9 %pid"
Windowsの場合:
-Xdump:tool:events=throw,filter=java/lang/OutOfMemoryError,exec="taskkill /F /PID %pid"
IBM社では、JVMに固定サイズのヒープを割り当てることを推奨していません。ほとんどの場合は、-Xmsにデフォルト値を使用することをお薦めします(つまり、この設定を省略して-Xmxのみを設定します)。詳細は、次のリンクを参照してください。
http://www.ibm.com/developerworks/java/jdk/diagnosis/
OutOfMemoryErrorがスローされた場合は、エラーの根本原因の調査に役立てるために、ヒープ・ダンプを生成するようにJVMを構成することをお薦めします。IBM JVMでは、デフォルトでOutOfMemoryErrorにヒープ・ダンプが生成されます。さらに構成を行う必要はありません。
LinuxにCoherenceをデプロイする場合は、次の事項に留意してください。
NPTLの初期のバージョンでは、特に2.4 Linuxカーネルと組み合せた場合に、デッドロックが発生する傾向がありました。カーネルのバージョンおよびNPTLのバージョンは、次のコマンドを実行して取得できます。
uname -a getconf GNU_LIBPTHREAD_VERSION
2.4カーネルで実行する場合は、いずれのバージョンのNPTLも使用しないで、LinuxThreadsライブラリの使用に戻すことをお薦めします。これは、Javaの起動前に環境変数LD_ASSUME_KERNELを設定することで実行できます。
export LD_ASSUME_KERNEL=2.4.19 getconf GNU_LIBPTHREAD_VERSION
2.6カーネルで実行する場合は、バージョン1.0以降のNPTLを使用することをお薦めします。NPTLのバージョンのアップグレードができない場合は、LinuxThreadsライブラリに切り替えることをお薦めします。
NPTLに関連する問題は、Red Hat Linux 9およびRed Hat Enterprise Linux 3で発生することがわかっています。また、バックポート・バージョンのNPTLを使用した2.4ベースのLinux分散にも影響する可能性があります。この問題の詳細は、http://java.sun.com/developer/technicalArticles/JavaTechandLinux/RedHatを参照してください。
Linuxには選択可能な高分解能タイムソースがいくつか用意されていますが、残念なことに、最速のタイムスタンプ・カウンタ(TSC)でも常に信頼性があるとはかぎりません。LinuxではTSCがデフォルトで選択され、起動時のチェックで非一貫性が検出されると、より低速で安全なタイムソースへの切替えが行われます。低速なタイムソースでは、問合せの実行にTSCタイムソースの10 - 30倍のコストがかかることがあり、Coherenceのパフォーマンスに多大な影響を与える可能性があります。Coherenceおよび基礎となるJVMでは、オペレーティング・システムで使用しているタイムソースを認識しないことに注意してください。システム・ログ(/var/log/dmesg)をチェックして、次のメッセージが記載されていないかどうか確認することをお薦めします
kernel: Losing too many ticks! kernel: TSC cannot be used as a timesource. kernel: Possible reasons for this are: kernel: You're running with Speedstep, kernel: You don't have DMA enabled for your hard disk (see hdparm), kernel: Incorrect TSC synchronization on an SMP system (see dmesg). kernel: Falling back to a sane timesource now.
ログ・メッセージによると、これが、CPU使用率の変動(SpeedStep)、DMAの無効化、またはマルチCPUコンピュータに対する誤ったTSCの同期化などに起因して発生していることを示しています。前述のメッセージが存在する場合は、システム管理者に問い合せてその原因を特定し、TSCタイムソースを使用可能にすることをお薦めします。
JRockit JVMにCoherenceをデプロイする場合は、次の事項に留意してください。
Linux上でJRockitを実行する場合は、2.6カーネルを使用してNPTLを有効にしておくことをお薦めします。この問題については、オラクル社のドキュメントを参照してください。
JVMでOutOfMemoryErrorが発生すると、エラーが未解決の状態のままになることがあり、クラスタに悪影響を与える可能性があります。OutOfMemoryErrorが発生した場合は、JVMでリカバリを試みられるようにするのではなく、JVMを終了するように構成することをお薦めします。JRockit JVMでこの設定を構成するパラメータは次のとおりです。
-XXexitOnOutOfMemory
また、OutOfMemoryErrorがスローされた場合は、エラーの根本原因の調査に役立てるために、ヒープ・ダンプを生成するようにJVMを構成することをお薦めします。JRockitでこの機能を有効にするには次のフラグを使用します。
-Djrockit.oomdiagnostics=true -Djrockit.oomdiagnostics.filename=<path to file>
Oracle JVMにCoherenceをデプロイする場合は、次の事項に留意してください。
Coherenceでは、JVM当たりのヒープ・サイズを1 - 4GBに保つことをお薦めします。ただし、多数の小さなJVMから得られるパフォーマンスのメリットよりも、少数の大きなJVMから得られる管理の簡易化のほうが重要になる一部のアプリケーションには、大きなヒープ・サイズ(最大20GB)が適しています。複数のキャッシュ・サーバーを使用すると、1台のコンピュータでより高い処理能力を実現できます。オラクル社のJVMには4GBを超えるヒープ・サイズが適していますが、GCの一時停止時間を最小限にするために、GCチューニングをお薦めします。チューニングの詳細は、オラクル社のGCチューニング・ガイドを参照してください。また、サイズの固定されたヒープでは通常、GC時間が短縮されるため、そのようなヒープで実行することもお薦めします。詳細は、「JVMのチューニング」を参照してください。
使用可能なCoherenceが、並行性の高いAtomicLongクラスを利用すると、Long値に対して並行アトミック更新が可能となり、同期化は不要です。
サーバー・モードで実行し、安定した並行性の高いバージョンを確実に使用できるようにすることをお薦めします。JVMをサーバー・モードで実行するには、Javaコマンドラインに-serverオプションを追加します。
JVMでOutOfMemoryErrorが発生すると、エラーが未解決の状態のままになることがあり、クラスタに悪影響を与える可能性があります。OutOfMemoryErrorが発生した場合は、JVMでリカバリを試みられるようにするのではなく、JVMを終了するように構成することをお薦めします。Sun JVMでこの設定を構成するパラメータは次のとおりです。
UNIXの場合:
-XX:OnOutOfMemoryError="kill -9 %p"
Windowsの場合:
-XX:OnOutOfMemoryError="taskkill /F /PID %p"
また、OutOfMemoryErrorがスローされた場合は、エラーの根本原因の調査に役立てるために、ヒープ・ダンプを生成するようにJVMを構成することをお薦めします。Sun JVMでこの機能を有効にするには次のフラグを使用します。
-XX:+HeapDumpOnOutOfMemoryError
OS XにCoherenceをデプロイする場合は、次の事項に留意してください。
OS Xは、デフォルトで、IPv4ではなくIPv6を使用してマルチキャストを実行するように設定されています。IPv6とIPv4が混在した環境で実行する場合には、IPv4を明示的に使用するようにJVMを構成します。それには、Javaコマンドラインでシステム・プロパティjava.net.preferIPv4Stackをtrueに設定します。
OS Xでは、Coherenceの各クラスタで一意のマルチキャスト・アドレスとポートを使用することをお薦めします。OS Xのバージョンによっては、パケット配信時にアドレスとポートのどちらも考慮されないためです。アドレスの構成の詳細は、「multicast-listener」を参照してください。
SolarisにCoherenceをデプロイする場合は、次の事項に留意してください。
Solaris 10上で実行している場合は、パケットの破損およびマルチキャストの切断に関する既知の問題があります。これらは多くの場合、EOFExceptions、パケット・データ読取り時の大きなギャップの警告または頻繁なパケット・タイムアウトとして顕在化します。Solaris 10システム上でCoherenceを使用する場合は、後述の両方の問題に対するパッチの適用を強くお薦めします。
Intelギガビット・ネットワーク・インタフェース・カード(NIC)にe1000gドライバを使用するSolaris 10システムに、データ整合性の問題が発生する可能性があります。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=ALERT&id=1000972.1
パッチ118822-21 (SPARC)または118844-21 (x86またはx64)以降がインストールされているSolaris 10システムから送信される場合、IGMP (1)パケットにはIPルーター警告オプションが含まれていません。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=ALERT&id=1000940.1
仮想マシンにCoherenceをデプロイする場合は、次の事項に留意してください。
Coherenceは仮想マシン環境でサポートされており、仮想マシン環境で実行される場合と非仮想化オペレーティング・システムで実行される場合に機能上の差異は見られません。
現在、Windows 2003またはWindows XP VMイメージでJRockitを起動するとCoherenceがハングするというVMWareのパフォーマンス・カウンタのクエリ機能に関する問題があります。この問題を回避するには、boot.iniファイルから/usepmtimerスイッチを削除して、仮想マシンを再起動します。この問題については、次のVMWareのナレッジ・ベースの記事で説明されています。
仮想化を使用すると、ネットワーク・トポロジに別のレイヤーが追加されるため、その他すべてのレイヤーと同様、マルチキャスト・ネットワーキングをサポートするように適切に構成する必要があります。マルチキャストの構成の詳細は、<multicast-listener要素を参照してください。
仮想化オペレーティング・システムで実行されるプロセスがギガビット・イーサネットを完全に使用できることはあまりありません。これはCoherenceに特有なことではなく、ネットワーク集中型の仮想化アプリケーションの大半に当てはまります。
非仮想化オペレーティング・システムと比較したネットワーク・パフォーマンスについて記述したVMWare社の記事を参照してください。
WindowsにCoherenceをデプロイする場合は、次の事項に留意してください。
出荷時点のWindowsは、バックグラウンド・プロセスや重いネットワーク負荷に合せて最適化されているわけではありません。最適化するには、Coherenceインストールのbinディレクトリに含まれているoptimize.regスクリプトを実行します。実行する最適化の詳細は、「オペレーティング・システムのチューニング」を参照してください。
コンピュータでファイアウォールを実行している場合は、複数のコンピュータで構成されるクラスタの形成が難しくなることがあります。これは、次のいずれかを実行すると解決できます。
ファイアウォールの無効化。ただし、これは通常はお薦めしません。
Coherenceを実行するJava実行可能ファイルに対する完全なネットワーク・アクセス権の付与。
Coherenceに対する個別アドレスとポートの開放。
Coherenceのデフォルト設定では、8088以降のTCPポートおよびUDPポートが使用されます。同一コンピュータ上の後続のノードでは、それより大きいポート番号が使用されます。Coherenceは、マルチキャスト通信もできます。デフォルトのアドレスとポートは、リリースによって異なり、リリースのバージョン番号に基づいています。アドレスおよびポートの構成は、<unicast-listener要素と<multicast-listener要素を参照してください。
Microsoft Windowsでは、ネットワーク・インタフェース・カード(NIC)がネットワークから取り外されると、そのカードに関連付けられたIPアドレスをオペレーティング・システムが無効にします。この結果、そのIPアドレスにバインドされているソケットがエラー状態になります。これにより、Coherenceノードがクラスタを終了し、NICがネットワークに再接続されるまでエラー状態になります。物理的に停止している間に、複数の連結されたJVMのクラスタ化を保持できるようにすることが望ましい場合は、IPアドレスを無効化しないようにWindowsを構成する必要があります。
このパラメータを調整する手順は次のとおりです。
レジストリ エディタを実行します(regedit)。
次のレジストリ・キーを見つけます。
HKLM\System\CurrentControlSet\Services\Tcpip\Parameters
次の新しいDWORD値を追加またはリセットします。
Name: DisableDHCPMediaSense Value: 1 (boolean)
再起動します。
キーワードの名前にDHCPが含まれていますが、この設定は静的IPアドレスと動的IPアドレスの両方に反映されます。詳細は、「Microsoft Windows TCP/IP Implementation Details」を参照してください。
http://technet.microsoft.com/en-us/library/bb726981.aspx#EDAA
z/OSにCoherenceをデプロイする場合は、次の事項に留意してください。
デフォルトのキャラクタ・セットがASCIIではなくEBCDICである環境にCoherenceをデプロイする場合、JARファイルからロードされる構成ファイルまたはクラスパスの構成ファイルがASCII形式であることを確認してください。ファイル・システムから直接ロードされた構成ファイルは、システムのネイティブ形式であるEBCDICで格納する必要があります。
状況によっては、IBM zSeriesのz/OS上の同じ論理パーティション(LPAR)内で実行されるCoherenceクラスタ・ノードは、相互に通信できません(この問題は、zSeriesがLinux上で実行されている場合には発生しません)。
根本的な原因としては、z/OSでは、Coherenceで使用されるMulticastSocketを自動的に割り当てられたポートにバインドする可能性がある一方、Coherenceでは、クラスタ検出が適切に動作するように特定のポートを使用する必要のあることが挙げられます(Coherenceでは、必要なポートの使用のためにjava.net.MulitcastSocketを明示的に初期化しますが、同一のLPAR内で実行されるCoherenceのインスタンスが存在する場合は、その情報がz/OS上で無視されているように見えます。)
この解決策は、z/OS LPAR内ではCoherenceのインスタンスを1つのみ実行することです。複数のインスタンスが必要な場合は、Coherenceの各インスタンスを別々のz/OS LPARで実行する必要があります。または、well-known-addresses機能を使用することもできます。アドレス構成の詳細は、<well-known-addresses要素を参照してください。
