A プラットフォーム固有のデプロイに関する考慮事項
この付録の内容は次のとおりです。
- Oracle HotSpot JVMへのデプロイ
CoherenceをOracle HotSpot JVMへデプロイする際に注意する問題 - IBM JVMへのデプロイ
CoherenceをIBM JVMへデプロイする際に注意する問題 - Linuxへのデプロイ
CoherenceをLinuxへデプロイする際に注意する問題 - Solarisへのデプロイ
CoherenceをSolarisへデプロイする際に注意する問題 - Windowsへのデプロイ
CoherenceをWindowsへデプロイする際に注意する問題 - OS Xへのデプロイ
CoherenceをOS Xへデプロイする際に注意する問題 - z/OSへのデプロイ
Coherenceをz/OSへデプロイする際に注意する問題 - AIXへのデプロイ
CoherenceをAIXへデプロイする際に注意する問題 - 仮想マシンへのデプロイ
Coherenceを仮想マシンへデプロイする際に注意する問題 - Cisco社製スイッチへのデプロイ
CoherenceをCisco社製スイッチへデプロイする際に注意する問題 - Foundry社製スイッチへのデプロイ
CoherenceをFoundry社製スイッチへデプロイする際に注意する問題 - IBM BladeCentersへのデプロイ
CoherenceをIBM BladeCentersへデプロイする際に注意する問題
Oracle HotSpot JVMへのデプロイ
ヒープ・サイズ
Coherenceでは、JVM当たりのヒープ・サイズを1 - 8GBに保つことをお薦めします。ただし、多数の小さなJVMから得られるパフォーマンスのメリットよりも、少数の大きなJVMから得られる管理の簡易化の方が重要になる一部のアプリケーションには、大きなヒープ・サイズ(最大20GB)が適しています。複数のキャッシュ・サーバーを使用すると、1台のコンピュータでより高い処理能力を実現できます。オラクル社のJVMには8GBを超えるヒープ・サイズが適していますが、GCの一時停止時間を最小限にするために、GCチューニングをお薦めします。Java Platform, Standard Edition HotSpot仮想マシン・ガベージ・コレクション・チューニング・ガイドの概要を参照してください。また、サイズの固定されたヒープでは通常、GC時間が短縮されるため、そのようなヒープで実行することもお薦めします。「JVMのチューニング」を参照してください。
親トピック: Oracle HotSpot JVMへのデプロイ
AtomicLong
使用可能なCoherenceが、並行性の高いAtomicLongクラスを利用すると、Long値に対して並行アトミック更新が可能となり、同期化は不要です。
サーバー・モードで実行し、安定した並行性の高いバージョンを確実に使用できるようにすることをお薦めします。JVMをサーバー・モードで実行するには、Javaコマンド行に-serverオプションを追加します。
親トピック: Oracle HotSpot JVMへのデプロイ
OutOfMemoryError
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
親トピック: Oracle HotSpot JVMへのデプロイ
IBM JVMへのデプロイ
OutOfMemoryError
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へのデプロイ
ヒープ・サイズの設定
IBM社では、JVMに固定サイズのヒープを割り当てることを推奨していません。ほとんどの場合は、-Xms
にデフォルト値を使用することをお薦めします(つまり、この設定を省略して-Xmx
のみを設定します)。詳細は、次のリンクを参照してください。
http://www.ibm.com/developerworks/java/jdk/diagnosis/
OutOfMemoryError
がスローされた場合は、エラーの根本原因の調査に役立てるために、ヒープ・ダンプを生成するようにJVMを構成することをお薦めします。IBM JVMでは、デフォルトでOutOfMemoryError
にヒープ・ダンプが生成されます。さらに構成を行う必要はありません。
親トピック: IBM JVMへのデプロイ
Linuxへのデプロイ
TSC高分解能タイムソース
Linuxには選択可能な高分解能タイムソースがいくつか用意されていますが、残念なことに、最速のタイムスタンプ・カウンタ(TSC)でも常に信頼性があるとはかぎりません。LinuxではTSCがデフォルトで選択され、起動時のチェックで非一貫性が検出されると、より低速で安全なタイムソースへの切替えが行われます。低速なタイムソースでは、問合せの実行にTSCタイムソースの10 - 30倍のコストがかかることがあり、Coherenceのパフォーマンスに多大な影響を与える可能性があります。TSCの詳細は、次を参照してください。
https://lwn.net/Articles/209101/
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タイムソースを使用可能にすることをお薦めします。
親トピック: Linuxへのデプロイ
Solarisへのデプロイ
親トピック: プラットフォーム固有のデプロイに関する考慮事項
Solaris 10(x86とSPARC)
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
親トピック: Solarisへのデプロイ
Solaris 10のネットワーキング
Solaris 10上で実行している場合は、パケットの破損およびマルチキャスト接続の切断について、前述の「Solaris 10 (x86とSPARC)」の問題を確認してください。これらは多くの場合、EOFExceptions、パケット・データ読取り時の大きなギャップの警告または頻繁なパケット・タイムアウトとして顕在化します。Solaris 10システム上でCoherenceを使用する場合は、これら両方の問題に対するパッチの適用を強くお薦めします。
親トピック: Solarisへのデプロイ
Solarisネットワーク・インタフェース・カード
Solaris Mシリーズ・システムには、オンボードNIC (bge
)およびPCI接続のNIC (nxge
)が含まれます。オンボード・ギガビット・イーサネット・ポートは、ドメインの低帯域幅の管理ネットワーキング接続に使用され、トラフィック需要が大きい高パフォーマンス・クラスタ相互接続負荷用ではありません。Coherenceクラスタ・メンバーは、高帯域幅のクラスタ相互接続には常に専用のPCIe NICを使用する必要があります。
親トピック: Solarisへのデプロイ
Solarisリンク・アグリゲーション
Solaris 11では、トランク・アグリゲーションとデータリンク・マルチパス(DLMP)アグリゲーションの2つのタイプのNICリンク・アグリゲーションがサポートされています。トランク・アグリゲーションではネットワーク・スイッチの使用が必要であり、これはリンク・アグリゲーション・コントロール・プロトコル(LCAP)をサポートしている必要があります。DLMPアグリゲーションでは、少なくとも1つのネットワーク・スイッチの使用が必要です。ただし、DLMPアグリゲーションを使用するときは、トランク・アグリゲーションをLCAPとともに使用するように構成されているスイッチがないことを確認してください。トランク・アグリゲーションからDLMPアグリゲーションに変更する場合、トランク・アグリゲーション用に以前作成したスイッチ構成を削除する必要があります。そのようにできなかった場合、パケットが失われ、ネットワーク帯域幅の利用が低くなる可能性があります。
親トピック: Solarisへのデプロイ
Windowsへのデプロイ
パフォーマンス・チューニング
デフォルトのWindows構成は、バックグラウンド処理、重いネットワークの負荷およびネットワーク割込みに対して最適化されていません。最適化するには、Coherenceインストールのbin
ディレクトリに含まれているoptimize.reg
スクリプトを実行します。「オペレーティング・システムのチューニング」を参照してください
親トピック: Windowsへのデプロイ
個人用ファイアウォール
コンピュータでファイアウォールを実行している場合は、複数のコンピュータで構成されるクラスタの形成が難しくなることがあります。これは、次のいずれかを実行すると解決できます。
-
ファイアウォールの無効化。ただし、これは通常はお薦めしません。
-
Coherenceを実行するJava実行可能ファイルに対する完全なネットワーク・アクセス権の付与。
-
Coherenceに対する個別アドレスとポートの開放。Oracle Coherenceでのアプリケーションの開発のクラスタ・メンバーのファイアウォールの構成を参照してください。
親トピック: Windowsへのデプロイ
切断されたネットワーク・インタフェース
Microsoft Windowsでは、ネットワーク・インタフェース・カード(NIC)がネットワークから取り外されると、そのカードに関連付けられたIPアドレスをオペレーティング・システムが無効にします。この結果、そのIPアドレスにバインドされているソケットがエラー状態になります。これにより、Coherenceノードがクラスタを終了し、NICがネットワークに再接続されるまでエラー状態になります。物理的に停止している間に、複数の連結されたJVMのクラスタ化を保持できるようにすることが望ましい場合は、IPアドレスを無効化しないようにWindowsを構成する必要があります。
このパラメータを調整するには:
キーワードの名前にDHCPが含まれていますが、この設定は静的IPアドレスと動的IPアドレスの両方に反映されます。詳細は、「Microsoft Windows TCP/IP Implementation Details」を参照してください。
http://technet.microsoft.com/en-us/library/bb726981.aspx#EDAA
親トピック: Windowsへのデプロイ
OS Xへのデプロイ
マルチキャストとIPv6
OS Xは、デフォルトで、IPv4ではなくIPv6を使用してマルチキャストを実行するように設定されています。IPv6とIPv4が混在した環境で実行する場合には、IPv4を明示的に使用するようにJVMを構成します。それには、Javaコマンド行でシステム・プロパティjava.net.preferIPv4Stack
をtrue
に設定します。
親トピック: OS Xへのデプロイ
ソケット・バッファのサイズ設定
通常、Coherenceでは2MB以上のバッファが必要ですが、OS Xの場合、このバッファ・サイズにするとカーネルのCPU時間が予想外に高くなり、スループットが低下する可能性があります。OS Xの推奨バッファ・サイズは768KBです。ただし、独自にチューニングして、より適したサイズを見つけることもできます。Oracle Coherenceでのアプリケーションの開発のパケット・バッファのサイズの構成を参照してください。
親トピック: OS Xへのデプロイ
z/OSへのデプロイ
親トピック: プラットフォーム固有のデプロイに関する考慮事項
EBCDIC
デフォルトの文字セットがASCIIではなくEBCDICである環境にCoherenceをデプロイする場合、JARファイルからロードされる構成ファイルまたはクラスパスの構成ファイルがASCII形式であることを確認してください。ファイル・システムから直接ロードされた構成ファイルは、システムのネイティブ形式であるEBCDICで格納する必要があります。
親トピック: z/OSへのデプロイ
マルチキャスト
状況によっては、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で実行する必要があります。または、ウェル・ノウン・アドレス機能を使用することもできます。Oracle Coherenceでのアプリケーションの開発のウェル・ノウン・アドレスの使用を参照してください。
親トピック: z/OSへのデプロイ
AIXへのデプロイ
マルチキャストとIPv6
AIX 5.2以降では、デフォルトで、IPv4ではなくIPv6を使用してマルチキャストを実行するように設定されています。IPv6とIPv4が混在した環境で実行する場合には、IPv4を明示的に使用するようにJVMを構成します。それには、Javaコマンド行でシステム・プロパティjava.net.preferIPv4Stack
をtrue
に設定します。詳細は、『IBM 32-bit SDK for AIX User Guide』を参照してください。
親トピック: AIXへのデプロイ
仮想マシンへのデプロイ
Oracle Coherenceは、Oracle Fusion Middlewareのサポート・ポリシーに従います。Oracle Fusion Middlewareでサポートされている仮想化およびパーティション化テクノロジを参照してください。
マルチキャスト接続
仮想化によりネットワーク・トポロジに別のレイヤーが追加されるため、マルチキャスト・ネットワーキングをサポートするように適切に構成する必要があります。Oracle Coherenceでのアプリケーションの開発のマルチキャスト通信の構成を参照してください。
親トピック: 仮想マシンへのデプロイ
パフォーマンス
仮想オペレーティング・システムで実行されるプロセスがギガビット・イーサネットを完全に使用できることはあまりありません。これはCoherenceに特有なことではなく、ネットワーク集中型の仮想アプリケーションの大半に当てはまります。
親トピック: 仮想マシンへのデプロイ
フォルト・トレランス
エントリ・キャッシュのバックアップが物理的に別個のハードウェアに存在するようにするには、追加の構成が必要になります。Oracle Coherenceでのアプリケーションの開発のクラスタ・メンバーのアイデンティティの指定を参照してください。
親トピック: 仮想マシンへのデプロイ
Cisco社製スイッチへのデプロイ
バッファ・スペースとパケットの一時停止
一部の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社製スイッチへのデプロイ
大規模ネットワークでのマルチキャスト接続
Cisco社のデフォルトのスイッチ構成では、IGMPスヌーピングを使用しているため、スイッチ間でのマルチキャスト・パケットの適切なルーティングがサポートされていません。この問題およびその解決策に関するCiscoのドキュメントを参照してください。
親トピック: 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=192.168.1.101, Port=8088, MachineId=48991)) to this member (Member(Id=1, Timestamp=Sat Sept 13 11:51:11 EST 2008, Address=192.168.1.101, Port=8088, MachineId=49002)) as recently as 5 seconds ago.
この問題を確認するには、実行中のクラスタと同じマルチキャスト・アドレスとポートを使用します。この問題がマルチキャスト・テスト・ノードに影響する場合は、マルチキャスト・テスト・メッセージの受信が突然停止したことが、そのログに記録されます。「マルチキャスト接続テストの実行」を参照してください。
次のテスト・ログはこの問題を示しています。
例A-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社のテクニカル・サポートに連絡してください。または、ウェル・ノウン・アドレス機能を使用して、ユニキャストのみの構成に変更することも検討してください。Oracle Coherenceでのアプリケーションの開発のウェル・ノウン・アドレスの使用を参照してください。
親トピック: Cisco社製スイッチへのデプロイ
マルチキャストの存続時間
Cisco 6500シリーズのルーターは、TTL(存続時間)の値が1のパケットを過剰に受信すると過負荷の状態になることがあります。さらに、TTLの設定が低いと単一グループのメンバーが過負荷になることもあります。CoherenceマルチキャストのTTL設定を、少なくともマルチキャスト・ドメインのサイズ(127または255)に設定し、クラスタが重複グループを使用していないことを確認してください。Oracle Coherenceでのアプリケーションの開発のマルチキャスト存続時間の指定を参照してください。
親トピック: Cisco社製スイッチへのデプロイ
Foundry社製スイッチへのデプロイ
親トピック: プラットフォーム固有のデプロイに関する考慮事項
マルチキャスト接続
Foundry社製スイッチでは、マルチキャスト・トラフィックの処理が困難です。Foundry社製スイッチを使用してデプロイするときには、Coherenceクラスタに属するすべてのコンピュータがマルチキャスト通信できることを確認してください。「マルチキャスト接続テストの実行」を参照してください。
マルチキャストに関する問題が発生した場合は、well-known-addresses機能を使用してユニキャストのみの構成に変更することも検討してください。Oracle Coherenceでのアプリケーションの開発のウェル・ノウン・アドレスの使用を参照してください。
親トピック: Foundry社製スイッチへのデプロイ
IBM BladeCenterへのデプロイ
MACアドレスの均一性とロード・バランシング
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 BladeCentersへのデプロイ