最近PoCでOSBとBPELコンポジット（バックエンドのEJBを呼び出す）を組み合わせて、優れた性能を示すことができました。最後のテストはフェールオーバテストで、その内容は以下のようなものでした。
- OSBを落とし、立ち上げる
- SOA（BPEL）サーバを落とし、立ち上げる
- バックエンドのEJBサーバを落とし、立ち上げる
Step 1 – ビジネスサービスに複数のエンドポイントを追加する
まずは、ビジネスサービスに対して、全ての接続先を指すエンドポイントを作成しましょう。これは、HTTP/ SOAPバインディングのために必要です。理論的にはT3プロトコルを使用している場合、単一のクラスタアドレスで十分であり、T3スマートプロキシが負荷分散を扱うことになります。このシナリオでは、SOAP/HTTPエンドポイントに焦点を当てます。
［ビジネスサービス］＞［構成の詳細］＞［トランスポートの構成］で、エンドポイントのURIを追加します。呼び出し側に失敗を返したくない場合には、再試行回数を0より大きな値にしておきましょう。以下の例では、3個のWebサービスのエンドポイントを設定しています。［最後>>］を押して、変更を保存しておきましょう。
Step 2 – エンドポイントURIのオフライン化と復旧を有効にする
バックエンドサービスのインスタンスが落ちた場合、そのサービスをオフラインにしたい、つまりOSBがリクエストをルーティングする先のインスタンスプールから当該インスタンスを除きたいかと思います。その際は、［ビジネスサービス］＞［操作設定］の［全般的な構成］にて、［オフラインのエンドポイントURI］のチェックボックスをチェックします。これにより、OSBは、トランスポート設定の［アプリケーション・エラーの再試行］が有効になっている場合はエラーを返したり、応答に失敗するバックエンドサービスに対するリクエストをルーティングしないようにすることができます。
サービスのオフライン化がよいのは、使えないエンドポイントに対してリクエストをルーティングしないからですが、もし復旧したら再度有効にしたいと考えるのはよくあることです。そんな場合に、［全般的な構成］の［再試行の反復間隔］をゼロではない値（例えば30秒とか）を指定しておきましょう。 すると、30秒毎にOSBは呼び出しに失敗したエンドポイントをエンドポイントリストに追加します。もしまだリクエストを受け付ける状態にない場合には、再度リストから削除されます。以下の例では、30秒を再試行間隔として指定しています。設定を変更した場合には、変更をコミットすることをお忘れ無く。
再試行回数について
再試行回数について注意すべきことがいくつかあります。
再試行回数にゼロより大きな値を設定している場合、エンドポイントの障害は、OSBクライアントには筒抜けであり、かつ遅延が発生します。しかし、リクエストが推移的である（バックエンドを変更する）場合、リクエストを実行しているのではなく、結果を戻す前にエンドポイントが失敗している可能性があります。その場合、2回オペレーション実行を発行している可能性があります。もしバックエンドサービスがこれに対処できない場合、再試行回数を設定しないでください。保証はありません。
バックエンドサービスが再試行に対処できない場合でも、2個のビジネスサービスを作成することにより、非推移的な要求用の透過的な再試行のメリットを享受することができます。1個のサービスは、非推移的リクエストを処理できるように再試行を有効にし、もう一つは推移的リクエストを処理できるように再試行をゼロに指定しておきます。
オフラインのエンドポイントの再試行間隔について
再試行間隔が短すぎると、障害が発生したエンドポイントが復旧していないことが考えられるので、新しいエンドポイントにフェイルオーバーする前に、そのエンドポイントにルーティングして失敗し、無駄な時間を使ってしまい、クライアントの応答時間が長くなってしまいます。ノードの典型的な計画外停止時間（JVMの停止およびその後の再始動など）を調べておき、追加のクライアント応答時間の遅延と、早くプールにエンドポイントを戻すこととの間をとって、その半分の時間を再試行間隔にするとうまくいくでしょう。
まとめ
［操作設定］の［オフライン設定］を有効にしておけば、フェールオーバテストでもびっくりすることはなｌくなりますよ。
原文はこちら。
http://blogs.oracle.com/reynolds/entry/coping_with_failure
0 件のコメント:
コメントを投稿