Skip to main content
クラスタリングにより、複数の インストールが連携して動作し、同じデータを同じ構成で処理できるようになります。ワークロードをクラスター化された インストール全体に水平に分散し、スケーラビリティを向上させ、可用性を確保できます。

概要

でサポートされている高可用性とフェイルオーバー機能を利用するには、同じサーバーファーム(同じクラスター)の複数のシステムにアプリケーションをインストールする必要があります。次に、ロードバランサーは、 インスタンスをホストしている複数のシステムに受信トラフィックを分散します。 ロードバランサーの背後にあるクラスター クラスタリング用に構成されている場合、サーバーファーム内の各 インストールは同じアプリケーション構成を使用し、ディスク上の同じ場所への / からのデータを処理し、同じデータベーステーブルにトランザクションを記録します。 その結果、アプリケーションの複数のインスタンスが1つのインスタンスのように動作し、特定のインスタンスが落ちてもクラスターのパフォーマンスを低下させることはありません。

クラスタリングのための の設定

クラスターの各ノードに をインストールした後は、各インストールで同じアプリケーションデータベースおよびアプリケーションデータディレクトリを使用するように設定する必要があります。

ライセンス

クラスタ内の各ノードに固有のライセンスキーを適用する必要があります。各ノードのライセンスページに移動し、いずれかのキーを適用します。アプリケーションにより、クラスタの共有ディレクトリにライセンスファイルが作成されます。ライセンスファイル名には、共有ディレクトリ内の両ノードのマシン名が含まれます。

アプリケーションデータベース

はデータベースを使用して、トランザクション履歴やアプリケーションで発生したエラーを記録します。 の各インスタンスは、処理されたすべてのファイルが最終的にデータベースに統合されるように、同じアプリケーションデータベースを使用するよう構成する必要があります。

.NET 版

.NET 版でアプリケーションデータベースを設定するには、AppDb 環境変数が適切な接続文字列とプロバイダーを含むよう設定する必要があります。これを実現するには、インストールディレクトリ内のwww フォルダにあるWeb.Config ファイルを編集します。このファイルには、connectionStrings と呼ばれるコメントアウトされたXML 要素があります。次に例を示します:
このconnectionStrings 要素のコメントを解除し、connectionString およびproviderName 属性を目的のデータベースの適切な接続パラメータに設定します。 がこの接続文字列で正常に接続を確立できる場合、このデータベースをアプリケーションデータベースとして使用します。

組み込みJava サーバー

クロスプラットフォーム版を組み込みJetty サーバーで使用する場合、アプリケーションデータベースはインストールディレクトリのwebapp フォルダにあるarc.xml ファイルに設定されます。このサーバー設定ファイルで、APP_DB 環境変数に、希望するデータベースの適切な接続パラメータを含むJDBC 接続文字列を設定する必要があります。次に例を示します:
APP_DB 接続文字列で正常に接続を確立できる場合、そのデータベースをアプリケーションデータベースとして使用します。

外部Java サーバー

クロスプラットフォーム版を外部のJava サーブレット(アプリケーションに含まれるJetty サーバー以外のサーバー)で使用する場合、アプリケーションのデータベースの設定の詳細は使用する特定のサーブレットに依存します。サーバーを構成するときは、特定のサーブレットに適した構文を使用して、次のいずれかのアプローチを使用します:
  • ターゲットデータベースの接続プロパティを含むJNDI データソースを定義する。
  • APP_DB 環境変数をJDBC 接続文字列に設定する。
がJNDI データソースまたはAPP_DB 接続文字列を使用してデータベースに接続できる場合、そのデータベースをアプリケーションデータベースとして使用します。

アプリケーションデータディレクトリ

は、すべての設定データおよびアプリケーションデータをデータディレクトリと呼ばれるディスク上のフォルダに保存します。クラスタリングする場合、 の各インスタンスは同じデータディレクトリを使用するように設定する必要があります。これにより、すべてのインスタンスが同じファイルを処理し、同じ設定を使用することが保証されます。

.NET 版

.NET 版でアプリケーションデータディレクトリを設定するには、AppDirectory 環境変数に、ディレクトリを作成するパスを設定する必要があります。これを実現するには、インストールディレクトリ内のwww フォルダにあるWeb.Config ファイルを編集します。このファイルには、AppDirectory と呼ばれるコメントアウトされたXML 要素があり、その下にカスタムデータディレクトリの場所を指定できるappSettings という要素があります:
このappSettings 要素のコメントを解除し、AppDirectory キー値をデータディレクトリのディスク上の適切なパスに設定します。 がパスを見つけることができ、指定されたパスで読み取りと書き込みを行う適切な権限を持っている場合、指定されたディレクトリにデータフォルダが作成されます。

組み込みJava サーバー

クロスプラットフォーム版を組み込みJetty サーバーで使用する場合、アプリケーションデータディレクトリはインストールディレクトリのwebapp フォルダにあるarc.xml ファイルに設定されます。このサーバー設定ファイルで、AppDirectory 環境変数に希望するディレクトリのパスを設定する必要があります。次の例は、データディレクトリをマウントされたドライブ上の共有フォルダに設定する場合を示しています:
がパスを見つけることができ、指定されたパスで読み取りと書き込みを行う適切な権限を持っている場合、指定されたディレクトリにデータフォルダが作成されます。

外部Java サーバー

クロスプラットフォーム版を外部のJava サーブレット(アプリケーションに含まれるJetty サーバー以外のサーバー)で使用する場合、アプリケーションのデータディレクトリの設定の詳細は使用する特定のサーブレットに依存します。特定のサーブレットに適した構文を使用して、AppDirectory 環境変数を目的のディレクトリへのパスに設定する必要があります。 AppDirectory パスを見つけることができ、指定されたパスで読み取りと書き込みを行う適切な権限を持っている場合、指定されたディレクトリにデータフォルダが作成されます。

ロックおよび同時実行

はロックを使用して、複数のインスタンスが互いに干渉したり、同じファイルを2度処理したりしないようにします。クラスタ環境では、スループットを維持し、衝突を防ぐために効率的なロックが重要です。そのため、ファイルシステムの遅延が問題になる可能性があることから、複数のサーバーファームにわたって インスタンスをクラスタ化しないことを強くお勧めします。 の各インスタンスに共有アプリケーションディレクトリを設定するだけで、各インスタンスで確実にファイルロックが尊重されるようになります。

リバースプロキシの設定

リバースプロキシは、クライアントとバックエンドサーバーの間に位置するサーバーで、受信トラフィックを傍受して適切な宛先に転送します。適切に設定すると、リバースプロキシは、バックエンドのインフラストラクチャを直接の露出から保護しながら、ヘッダー転送を通じて実際のクライアントIP アドレスを保持できます。このアーキテクチャは、ロードバランシング、セキュリティの向上、キャッシュ、SSL ターミネーションといったメリットを提供します。 リバースプロキシがX-Forwarded-For のようなヘッダーを通じてクライアント情報を転送する場合、どのプロキシを信頼するかを制限することが重要です。既知のプロキシIP アドレスのみを明示的に信頼しないと、悪意のあるユーザーがこれらのヘッダーを偽造して自身の発信元を偽装し、セキュリティ制御やログ記録の仕組みを回避できてしまう可能性があります。

クロスプラットフォーム版

クロスプラットフォーム版でリバースプロキシを設定するには、arc.properties ファイルのproxyMode 設定を、次の文字列に示すようにtrue に設定します:cdata.http.proxyMode=true proxyMode=true の場合、組み込みJetty サーバーはForwardedRequestCustomizer を使用して、転送されたヘッダーから実際のクライアントIP を抽出して適用します。 外部のJava サーブレットコンテナを使用している場合は、転送されたヘッダーを適切に処理するために、サーブレットレベルでリクエストの書き換えを設定します。

.NET 版

.NET 版でリバースプロキシを設定するには、セキュリティページのプロキシ設定セクションにあるHTTP Forwarded ヘッダーフィールドに、アプリケーションがクライアントIP アドレスを判別するために使用すべきヘッダー名をカンマ区切りのリストで指定する必要があります。

例:nginx プロキシを使用したリバースプロキシの設定

転送されるIP アドレスに使用されるヘッダーをクライアントが偽装できないようにするのは、プロキシの責任です。この例は、リバースプロキシ設定を含むプロキシ設定を示しています。
この設定は、指定されたプロキシIP(192.168.1.100 および10.0.0.0/8)のみを明示的に信頼することで、ヘッダーの偽装を防ぎます。悪意のあるユーザーがX-Forwarded-For ヘッダーを偽造しても、nginx はそれを無視し、信頼されたプロキシを経由してきたクライアントに最も近いIP を使用します。