検証システムの構成のように、ネットワークやIPCOMの二重化により、pingではエラーを検出する場合もあるものの、TCP層のリトライで回避できるため、利用者にはシステム停止がわからない範囲になることから、非常に高信頼なシステムであるといえます。 特に、深夜でもサービスをし続ける必要のあるWEBのショッピングサイトでは、このような高信頼なシステムは必須となります。

   今回、センタのスイッチはL2スイッチとし、IPCOM/サーバ間で監視を行いましたが、より高パフォーマンスなL3スイッチを使えば、VLANごとにIPを設け、IPCOM・スイッチ、サーバ・スイッチ間の監視を行うことにより監視箇所が局所化できるため、よりよいシステムになるものと推測されます。 また、Oracle Application Server 10gでは、今回の検証の中で、既存クラスタメンバへの影響と回線ダウンの回復時の動作の2 点に着目して動作確認を行いました。 検証の結果、どちらの場合についてもユーザにエラーが戻ることなく処理が継続できることが確認できました。 Oracle Application Server 10gではクラスタ追加の場合に、以下に示す動作も行なわれてはいますが、全てにおいてサービス停止を伴うオペレーションを実施する必要はありません。

• 既存クラスタで稼動中のOC4Jインスタンスを新規OracleASへ反映する
• 既存クラスタで稼動中のアプリケーションを新規OC4Jへ自動デプロイする
• アプリケーション毎で保持するユーザセッションのステート情報を新規OC4Jへ反映する
• 新規OC4Jへのリクエスト振り分けを有効化する

OC4Jインスタンスへのリクエスト振り分けはOracle HTTP Server（mod_oc4j）によって行なわれ、このように新規OC4Jインスタンスが稼働状態になったことは下位のOPMNプロセス間通信によって伝播されます。 この伝播はイベント発行毎に即時適用されるために、新規OC4Jインスタンス追加からリクエストを振り分け可能になるまでの時間差はほとんどありません。

ただし、mod_oc4jの振り分け設定については幾つか種類があるため、Oracle Application Server 10g 利用者は配置を考える場合にその指定方法を考慮する必要があります。 通常、Oracle HTTP Serverから特定のクラスタリングされたOC4Jインスタンスへリクエストを振るためには「cluster:// ＜クラスタ名＞：＜ OC4J インスタンス名＞」という指定するだけで比較的簡単にノード追加に対応できるので、推奨される設定と言えます。
また、Oracle HTTP ServerとOC4J間のネットワーク障害については、現時点ではTCP レベルでの障害検出に依存しています。 今回の回線ダウン時の動作確認はその中でも最もシンプルなパターンで再現確認したものですが、想定通りにTCPレベルのprobe packetが何度か再送され、回線が回復した時点でユーザへの応答も再開できることを見て取ることができました。 Oracle Application Server10gの将来バージョンでは、OC4JへのAJPセッションの待ち時間に合わせたタイムアウトを指定できるようになるため、今回のTCPレベルの障害検出に依存することなく Application レイヤーのレベルで対応することができるようになると予想されます。