高可用性サーバー

高可用性サーバーの動作は、個別に使用されるサーバーの動作とは多少異なります。

すべてのサーバーは、同じデータベースと共通のファイル共有を使用します。ファイル共有は、ログとその他のいくつかのディレクトリー (具体的には、logsvar/emailvar/plugins、および var/repository) で使用されます。また、ポートやホストなどの一部の構成情報のように各サーバーが個別に維持するものもあります。データベースは、構成情報、ランタイム・データなどに使用されます。

サーバーはデータベースを共有しているので、すべてのサーバーは同じ間隔で実行されます。

データベースと JMS の接続情報など、一部の構成プロパティーはサーバー上に残ります。データベース構成は製品のインストール中に処理されます。インストール後に追加構成は不要です。

ファイルのインポート (CodeStation)

すべてのサーバーは、コンポーネント・バージョンの変更をポーリングによって問い合わせます。ポーリング間隔は、ユーザー構成パラメーターで指定します (デフォルトは 15 分)。データベースではサーバーの同期を処理します。リポジトリーに書き込む前に、サーバーはデータベースのロックを獲得します。ポーリング時間は、ジョブの終了後にリセットされます。

イベント

イベントは、イベントを起動したサーバーによって処理されます。

ワークフロー・エンジン

ワークフローはアクティビティーで構成されます。アクティビティーは、1 つずつ順番に実行することも、相互に並行して実行することもできます。さらに、その 2 つを組み合わせて実行することもできます。典型的なワークフローは、以下に示すような複数の順次アクティビティーで構成されます。

JMS ベースの通信では、以下に示すような数とおりの方法でエージェントを構成できます。

すべてのサーバーは、常にポーリングによって処理待ちのワークフローがあるかどうかを問い合わせます。したがって、どのサーバーでもワークフローを開始する可能性があります。このワークフローを獲得するサーバーは、以下のタスクを実行します。

  1. アクティビティー A のランタイム・インスタンスを作成し、データベース・ロックを獲得します。
  2. 送信する予定のコマンドをデータベースに記録します。
  3. JMS を介してコマンドをエージェントに送信します。
  4. データベース・ロックを解除します。

処理を完了すると、エージェントは、JMS を介して応答メッセージを送信します。メッセージは、いずれかのサーバーによってデータベースに書き込まれ、次のアクティビティーがいずれかのサーバーによって開始されます。アクティビティー B を開始したサーバーは、上で説明したのと同じステップを実行します。

ここで概略を説明している単純なワークフローでは、複数のアクティビティーをすべて同じサーバーが処理することもあれば、それぞれ異なるサーバーが処理することもあります。さらに、その両方が組み合わされることもあります。もちろん、このワークフローが 3 つの並行アクティビティーで構成されている場合でも、同じことが言えます。

1 つのアプリケーション・ワークフローは、データベースの単一のレコードによって維持されます (1 つのワークフローを同時に処理するスレッドは 1 つのみです)。

障害の処理

アプリケーションの処理中には、コマンドが失敗すると、ワークフローにマークが付けられます。エラー処理は、アプリケーションの作成者の責任です。コンポーネントのロールバックは、ロールバック・コマンド/ステップで処理できます。ここで使用しているロールバックという言葉は、コンポーネントの前のバージョンを再インストールすることを意味しています。

エージェントがコマンドを実行している最中にサーバーが異常終了すると、JMS メッシュはそのワークフローを別のサーバーに割り当てます。

コマンドの実行中にエージェントが異常終了したり消滅したりした場合、(ステップの失敗がエージェント自体の失敗原因にはならないため) サーバーはコマンドがまだ実行中であると見なし、自動タイムアウトにはなりません。 通常、タイムアウト間隔を割り当てることは適切ではなく、現実的でもありません。


フィードバック