| Oracle Coherence開発者ガイド リリース3.5 B56039-01 |
|
 戻る |
 次へ |
この付録の次の項では、各種プラットフォームへのCoherenceのデプロイについて説明します。
AIXにCoherenceをデプロイする場合は、次の事項に留意してください。
IBMのAIX用JVM 1.4.2および1.5では、64Kを超えるソケット・バッファを割り当てられないという問題があります（Oracleでは2MBを推奨）。この問題は、IBMの1.4.2 SR7 SDKおよび1.5 SR3 SDKで解決されています。「オペレーティング・システムのチューニング」を参照してください。
AIX 5.2以降では、デフォルトで、IPv4ではなくIPv6を使用してマルチキャストを実行するように設定されています。IPv6とIPv4が混在した環境で実行する場合には、IPv4を明示的に使用するようにJVMを構成する必要があります。それには、Javaコマンドラインでシステム・プロパティjava.net.preferIPv4Stackをtrueに設定します。詳細は、『IBM 32-bit SDK for AIX User Guide』を参照してください。
AIXでは、Coherenceの各クラスタで一意のマルチキャスト・アドレスとポートを使用することをお薦めします。AIXのバージョンによっては、パケット配信時にアドレスとポートのどちらも考慮されないためです。アドレスの構成の詳細は、「multicast-listener」を参照してください。
JRockit JVMにCoherenceをデプロイする場合は、次の事項に留意してください。
Linux上でJRockitを実行する場合は、2.6カーネルを使用してNPTLを有効にしておくことをお薦めします。この問題については、Oracleのドキュメントを参照してください。
使用可能なCoherenceが、並行性の高いAtomicLongクラスを利用すると、長い値に対して並行アトミック更新が可能となり、同期化は不要です。JRockit 1.4 JVMでは、AtomicLongを完全にサポートしているわけではありません。そのため、JRockit 1.4 JVM上でAtomicLongが実行されていることがCoherenceにより検出された場合、AtomicLongは安全ではあるが処理の遅い同期化された実装にデフォルトで設定され、次のログ・メッセージが出力されます。
sun.misc.AtomicLong is not supported on this JVM; using a synchronized counter.
JRockit 1.5にアップグレードすると、並行性の高い実装を使用できるようになります。
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.
この問題を確認するには、実行中のクラスタと同じマルチキャスト・アドレスとポートを使用して実行できます。この問題がマルチキャスト・テスト・ノードに影響する場合は、ある時点でマルチキャスト・テスト・メッセージの受信が突然停止したことが、そのログに記録されます。第15章「マルチキャスト接続テストの実行」を参照してください。
次のテスト・ログはこの問題を示しています。
例M-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クラスタに属するすべてのマシンがマルチキャスト通信できるようにしておくことをお薦めします。第15章「マルチキャスト接続テストの実行」を参照してください。
マルチキャストに関する問題が発生した場合は、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には当てはまりません。この状況の対応策は次のとおりです。
IPアドレスが同じ偶数/奇数パターンを踏襲しないという前提で、レイヤー3（IPベース）のロード・バランシングを使用します。
この設定は、クラスタ・トラフィックの伝送を行うすべてのスイッチに適用する必要があります。
マシン交互に1番目と2番目のNIC間でMACアドレスを入れ替えることにより、MACアドレスの割当てをランダムにします。
Linuxでは、ifconfigコマンドを使用してNICのMACアドレスを変更できます。
その他のオペレーティング・システムでも、カスタム・ツールを使用して同様のタスクを実行できる場合があります。
IBM JVMにCoherenceをデプロイする場合は、次の事項に留意してください。
IBMのJVM 1.4.2および1.5では、64Kを超えるソケット・バッファを割り当てられないという問題があります（Coherenceには2MBのバッファを推奨）。この問題は、IBMの1.4.2 SR7 SDKおよび1.5 SR3 SDKで解決されています。パフォーマンス上の理由により、パッチの適用をお薦めします。
JVMでOutOfMemoryErrorが発生すると、エラーが未解決の状態のままになることがあり、クラスタに悪影響を与える可能性があります。OutOfMemoryErrorが発生した場合は、JVMでリカバリを試みられるようにするのではなく、JVMを終了するように構成することをお薦めします。IBM JVM（1.5以降）でこのような設定を構成するためのパラメータは次のとおりです。
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"
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タイムソースを使用可能にすることをお薦めします。
OS XにCoherenceをデプロイする場合は、次の事項に留意してください。
OS Xは、デフォルトで、IPv4ではなくIPv6を使用してマルチキャストを実行するように設定されています。IPv6とIPv4が混在した環境で実行する場合には、IPv4を明示的に使用するようにJVMを構成する必要があります。それには、Javaコマンドラインでシステム・プロパティjava.net.preferIPv4Stackをtrueに設定します。
OS Xでは、Coherenceの各クラスタで一意のマルチキャスト・アドレスとポートを使用することをお薦めします。OS Xのバージョンによっては、パケット配信時にアドレスとポートのどちらも考慮されないためです。アドレスの構成の詳細は、「multicast-listener」を参照してください。
通常、Coherenceでは2MB以上のバッファが必要ですが、OS Xの場合は、このバッファ・サイズにすると、カーネルのCPU時間が予想外に高くなり、スループットが低下する可能性があります。OS Xの推奨バッファ・サイズは768KBです。ただし、独自にチューニングして、より適したサイズを見つけることもできます。Coherenceで要求されるバッファ・スペースのサイズ指定の詳細は、「packet-buffer」を参照してください。
SolarisにCoherenceをデプロイする場合は、次の事項に留意してください。
Intelギガビット・ネットワーク・インタフェース・カード（NIC）にe1000gドライバを使用するSolaris 10システムに、データ整合性の問題が発生する可能性があります。
パッチ118822-21（SPARC）または118844-21（x86またはx64）以降がインストールされているSolaris 10システムから送信される場合、IGMP（1）パケットにはIPルーター警告オプションが含まれていません。
Sun JVMにCoherenceをデプロイする場合は、次の事項に留意してください。
1.4 JVMでは、JVM当たりのヒープ・サイズを1GB未満にすることをお薦めします。複数のキャッシュ・サーバーを使用すると、1台のマシンでより高い処理能力を実現できます。Sun 1.5 JVMでは、1GBを超えるヒープ・サイズが適していますが、GCの一時停止時間を最小限にするためにGCチューニングをお薦めします。チューニングの詳細は、Sunの『GC Tuning Guide』を参照してください。また、サイズの固定されたヒープでは通常、GC時間が短縮されるため、そのようなヒープで実行することもお薦めします。
使用可能なCoherenceが、並行性の高いAtomicLongクラスを利用すると、長い値に対して並行アトミック更新が可能となり、同期化は不要です。Sun 1.4クライアントJVMには、一部のマルチプロセッサ・システムでは安定しない実装が含まれています。Coherenceにより、Sun 1.4クライアントJVM上でAtomicLongの実行が検出された場合は、安全ではあるが処理の遅い同期化された実装にデフォルトで設定され、次のログ・メッセージが出力されます。
sun.misc.AtomicLong is not supported on this JVM; using a synchronized counter.
1.4 JVMをサーバー・モードで実行し、安定した並行性の高いバージョンを確実に使用できるようにすることをお薦めします。JVMをサーバー・モードで実行するには、Javaコマンドラインに-serverオプションを追加します。
JVMでOutOfMemoryErrorが発生すると、エラーが未解決の状態のままになることがあり、クラスタに悪影響を与える可能性があります。OutOfMemoryErrorが発生した場合は、JVMでリカバリを試みられるようにするのではなく、JVMを終了するように構成することをお薦めします。Sun JVMでこの設定を構成するパラメータは次のとおりです。
UNIXの場合:
-XX:OnOutOfMemoryError="kill -9 %p"
Windowsの場合:
-XX:OnOutOfMemoryError="taskkill /F /PID %p"
|
注意: 注意: 2008年12月の時点では、1.4.2および1.6の新バージョンでこのフラグが使用できますが、バージョン1.5は未対応です。 |
仮想化を使用すると、ネットワーク・トポロジに別のレイヤーが追加されるため、その他すべてのレイヤーと同様、マルチキャスト・ネットワーキングをサポートするように適切に構成する必要があります。「multicast-listener」を参照してください。
仮想OSで実行されるプロセスがギガビット・イーサネットを完全に使用できることはあまりありません。これはCoherenceに特有なことではなく、ネットワーク集中型の仮想アプリケーションの大半に当てはまります。
非仮想OSと比較したネットワーク・パフォーマンスについて記述したVMWare社の記事を参照してください。
Coherenceのフォルト・トレランスの見地からすると、キャッシュ・エントリのバックアップが物理的に別々のハードウェアに格納されるようにするためには、さらなる構成が必要です。Coherenceでバックアップがプライマリと同じ物理マシンに不注意に格納されることがないように、マシンIDを手動で構成する必要があります。これは、オペレーション・コンフィギュレーション・ファイル内でmachine-id要素を使用することで構成できます。詳細は、「unicast-listener」の構成を参照してください。
WindowsにCoherenceをデプロイする場合は、次の事項に留意してください。
出荷時点のWindowsは、バックグラウンド・プロセスや重いネットワーク負荷に合せて最適化されているわけではありません。最適化するには、Coherenceインストールのbinディレクトリに含まれているoptimize.regスクリプトを実行します。実行する最適化の詳細は、「オペレーティング・システムのチューニング」を参照してください。
マシンでファイアウォールを実行している場合は、複数のコンピュータで構成されるクラスタの形成が難しくなることがあります。これは、次のいずれかを実行すると解決できます。
ファイアウォールの無効化。ただし、これは通常はお薦めしません。
Coherenceを実行するJava実行可能ファイルに対する完全なネットワーク・アクセス権の付与。
Coherenceに対する個別アドレスとポートの開放。
Coherenceのデフォルト設定では、8088以降のTCPポートおよびUDPポートが使用されます。同一マシン上の後続のノードでは、それより大きいポート番号が使用されます。Coherenceはマルチキャスト通信もできます。デフォルトのアドレスとポートは、リリースによって異なります。アドレスとポートの構成の詳細は、「unicast-listener」および「multicast-listener」を参照してください。
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」を参照してください。
