30.7. フェイルオーバーモード

JBoss EAP メッセージングクライアントは、すべてのライブサーバーとバックアップサーバーの情報を受け取るように設定できます。そのため、クライアントで接続 (ライブサーバー接続) に失敗すると、クライアントが障害を検出し、バックアップサーバーに再接続します。次に、バックアップサーバーはフェイルオーバーの前に各接続に存在したセッションおよびコンシューマーを自動的に再作成します。そのため、ユーザーは再接続ロジックを手動でコーディングする必要がなくなります。

JBoss EAP メッセージングクライアントは、使用済みの接続の検出 で説明されているように、client-failure-check-period で指定した時間内にサーバーからパケットを受信しないと、接続障害を検出します。

割り当てられた時間内にクライアントがデータを受信しない場合、接続が失敗したと見なし、フェイルオーバーを試みます。ソケットがオペレーティングシステムによって閉じられているとします。たとえば、サーバーハードウェア自体がクラッシュしたのではなく、サーバープロセスが強制終了され可能性がり、クライアントはすぐにフェイルオーバーします。

JBoss EAP メッセージングクライアントは、さまざまな方法でライブサーバーとバックアップサーバーのペアのリストを検出できるように設定できます。たとえば、明示的なエンドポイントを使用して設定できますが、最も一般的な方法は、クライアントが初めてクラスターに接続するときにクラスタートポロジーについての情報を受け取ることです。詳細は、サーバー検出 を参照してください。

デフォルトの HA 設定には、クラスター通信に推奨される http-connector を使用する cluster-connection が含まれます。これは、リモートクライアントがデフォルトの RemoteConnectionFactory を使用してサーバーに接続するときに使用する http-connector と同じです。推奨されていませんが、別のコネクターを使用することもできます。独自のコネクターを使用する場合は、リモートクライアントが使用する connection-factory とクラスターノードが使用する cluster-connection の両方の設定の一部に含まれていることを確認してください。コネクターとクラスター接続に関する詳細は、メッセージングトランスポートの設定 と クラスター接続 を参照してください。

CLI コマンドを使用して、connection-factory と cluster-connection の両方の設定を確認します。たとえば、RemoteConnectionFactory という名前の connection-factory の現在の設定を読み取るには、以下のコマンドを使用します。

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:read-resource

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:read-resource

同様に、以下のコマンドは my-cluster という名前の cluster-connection の設定を読み込みます。

/subsystem=messaging-activemq/server=default/cluster-connection=my-cluster:read-resource

/subsystem=messaging-activemq/server=default/cluster-connection=my-cluster:read-resource

自動クライアントフェイルオーバーを有効にするには、ゼロでない再接続試行を許可するようにクライアントを設定する必要があります。詳細は、クライアントの再接続とセッションの再割り当て を参照してください。デフォルトでは、フェイルオーバーは、ライブサーバーへの接続が少なくとも 1 つ確立された後にのみ発生します。つまり、クライアントが、ライブサーバーへの最初の接続を確立できないと、フェイルオーバーは発生しません。クライアントは、最初の試行に失敗すると、reconnect-attempts プロパティーに従ってライブサーバーへ接続を再試行し、設定された試行回数の後に失敗します。

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=reconnect-attempts,value=<NEW_VALUE>)

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=reconnect-attempts,value=<NEW_VALUE>)

このルールの例外は、ライブ/バックアップサーバーのペアが 1 つのみで、他のライブサーバーはなく、リモート MDB が正常にシャットダウンされたときにライブサーバーに接続される場合です。MDB が @ActivationConfigProperty(propertyName = "rebalanceConnections", propertyValue = "true") を設定している場合、別のライブサーバーへの接続を再度調整し、バックアップにフェイルオーバーしません。

初期接続時のフェイルオーバー

クライアントは最初の接続が確立されるまで完全なトポロジーについてわからないため、バックアップについて不明な時間枠があります。この時点で失敗した場合、クライアントは元のライブサーバーにのみ再接続を試みます。クライアントが試行する回数を設定するには、ClientSessionFactoryImpl または ActiveMQConnectionFactory でプロパティー initialConnectAttempts を設定します。

または、サーバー設定で、クライアントが使用する接続ファクトリーの initial-connect-attempts 属性を設定できます。これのデフォルトは 0 で、つまり、1 回のみ試行します。試行がその回数行われると、例外が出力されます。

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=initial-connect-attempts,value=<NEW_VALUE>)

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=initial-connect-attempts,value=<NEW_VALUE>)

サーバーレプリケーションについて

JBoss EAP メッセージングは、ライブサーバーとバックアップサーバーの間で完全なサーバー状態を複製しません。新しいセッションがバックアップ上に自動的に再作成される場合、そのセッション中に送信済みまたは確認応答済みのメッセージについては認識されません。フェイルオーバー時の in-flight の送信と確認応答も失われる可能性があります。

完全なサーバー状態を複製することで、JBoss EAP メッセージングは、理論的に 100% 透過的なシームレスなフェイルオーバーを提供して、メッセージや確認応答を失うことを防ぐことができます。ただし、これには、キューやセッションを含め、完全なサーバー状態を複製するため、多大なコストがかかります。これには、サーバー状態マシン全体のレプリケーションが必要です。つまり、ライブサーバー上のすべての操作は、一貫したレプリカ状態にするためにまったく同じグローバル順序でレプリカサーバーに複製される必要があります。これは、特に複数のスレッドがライブサーバー状態を同時に変更していることを考慮すると、パフォーマンスの優れたスケーラブルな方法で行うことは非常に困難です。

仮想同期などの手法を使用して完全な状態マシンのレプリケーションを提供することは可能です。しかし、これは拡張性が低く、すべての操作を単一スレッドに効果的にシリアライズするため、同時実行性が大幅に低下します。ロック状態の複製やスレッドスケジューリングの複製など、マルチスレッドのアクティブなレプリケーションには他の手法が存在しますが、これを Java レベルで達成することは非常に困難です。

したがって、100% 透過的なフェイルオーバーのために、パフォーマンスと同時実行性を低下させる価値はありませんでした。100% 透過的なフェイルオーバーがなくても、トランザクションの重複検出と再試行の組み合わせを使用することで、障害が発生した場合でも、一度だけの配信を保証するのは簡単です。ただし、これは、クライアントコードに対して 100% 透過的ということではありません。

場合によっては、自動クライアントフェイルオーバーは行わず、接続障害を自分で処理し、障害ハンドラーに再接続ロジックを手動でコーディングすることもできます。フェイルオーバーはユーザーアプリケーションレベルで処理されるため、これをアプリケーションレベルのフェイルオーバーとして定義します。

JMS を使用する場合にアプリケーションレベルのフェイルオーバーを実装するには、JMS 接続で ExceptionListener クラスを設定します。ExceptionListener は、接続障害が検出された場合に JBoss EAP メッセージングによって呼び出されます。ExceptionListener では、古い JMS 接続を閉じ、場合によっては、JNDI から新しい接続ファクトリーインスタンスを検索し、新しい接続を作成します。

コア API を使用している場合、手順は非常に似ています。コア ClientSession インスタンスで FailureListener を設定します。