Version 25.3.9469

• 概要
• クラスタリングのためのArc の設定
  • ライセンス
  • アプリケーションデータベース
    • .NET 版
    • 組み込みJava サーバー
    • 外部Java サーバー
  • アプリケーションデータディレクトリ
    • .NET 版
    • 組み込みJava サーバー
    • 外部Java サーバー
  • ロックおよび同時実行
  • リバースプロキシの設定
    • クロスプラットフォーム版
    • .NET 版
    • Example: Setting a Reverse Proxy Using an nginx Proxy

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

概要

Arc でサポートされている高可用性とフェイルオーバー機能を利用するには、同じサーバーファーム（同じクラスター）の複数のシステムにアプリケーションをインストールする必要があります。次に、ロードバランサーは、Arc インスタンスをホストしている複数のシステムに受信トラフィックを分散します。

クラスタリング用に構成されている場合、サーバーファーム内の各Arc インストールは同じアプリケーション構成を使用し、ディスク上の同じ場所への / からのデータを処理し、同じデータベーステーブルにトランザクションを記録します。

その結果、アプリケーションの複数のインスタンスが1つのインスタンスのように動作し、特定のインスタンスが落ちてもクラスターのパフォーマンスを低下させることはありません。

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

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

ライセンス

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

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

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

.NET 版

.NET 版でアプリケーションデータベースを設定するには、AppDb 環境変数が適切な接続文字列とプロバイダーを含むよう設定する必要があります。これを実現するには、インストールディレクトリ内のwww フォルダにあるWeb.Config ファイルを編集します。このファイルには、connectionStrings と呼ばれるコメントアウトされたXML 要素があります。次に例を示します。

<!-- connectionStrings>
 <add 
  name="AppDb" 
  connectionString="server=SQLSERVER_LOCATION;database=DATABASE_NAME;uid=USER_ID;password=PASSWORD;" 
  providerName="System.Data.SqlClient"
 />
</connectionStrings -->

このconnectionStrings 要素のコメントを解除し、connectionString およびproviderName 属性を目的のデータベースの適切な接続パラメータに設定します。Arc がこの接続文字列で正常に接続を確立できる場合、このデータベースをアプリケーションデータベースとして使用します。

組み込みJava サーバー

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

<Call name="setInitParameter">
 <Arg>APP_DB</Arg>
 <Arg>jdbc:cdata:mysql:Server=MySQLServer;Port=3306;Database=mysql;User=user;Password=password</Arg>
</Call>

Arc がAPP_DB 接続文字列で正常に接続を確立できる場合、そのデータベースをアプリケーションデータベースとして使用します。

外部Java サーバー

クロスプラットフォーム版を外部のJava サーブレット（アプリケーションに含まれるJetty サーバー以外のサーバー）で使用する場合、アプリケーションのデータベースの設定の詳細は使用する特定のサーブレットに依存します。サーバーを構成するときは、特定のサーブレットに適した構文を使用して、次のいずれかのアプローチを使用する必要があります。

• ターゲットデータベースの接続プロパティを含むJNDI データソースを定義。
• APP_DB 環境変数をJDBC 接続文字列に設定。

Arc がJNDI データソースまたはAPP_DB 接続文字列を使用してデータベースに接続できる場合、そのデータベースをアプリケーションデータベースとして使用します。

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

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

.NET 版

.NET 版でアプリケーションデータディレクトリを設定するには、AppDirectory 環境変数に、ディレクトリを作成するパスを設定する必要があります。これを実現するには、インストールディレクトリ内の’www’ フォルダにあるWeb.Config ファイルを編集します。このファイルには、AppDirectory と呼ばれるコメントアウトされたXML 要素があり、その下にカスタムデータディレクトリの場所を指定できるappSettings という要素があります。

<!-- appSettings>
 <add key="AppDirectory" value="C:\\directory\\subdirectory\\subdirectory\\" />
</appSettings -->

このappSettings 要素のコメントを解除し、AppDirectory キー値をデータディレクトリのディスク上の適切なパスに設定します。Arc がパスを見つけることができ、指定されたパスで読み取りと書き込みを行う適切な権限を持っている場合、指定されたディレクトリにデータフォルダが作成されます。

組み込みJava サーバー

クロスプラットフォーム版を組み込みJetty サーバーで使用する場合、アプリケーションデータベースはインストールディレクトリの”webapp” フォルダにあるarc.xml ファイルに設定されます。このサーバー設定ファイルで、AppDirectory 環境変数に希望するディレクトリのパスを設定する必要があります。次の例は、データディレクトリをマウントされたドライブ上の共有フォルダに設定する場合を示しています。

<Call name="setInitParameter">
 <Arg>AppDirectory</Arg>
 <Arg>/mnt/shared/arc</Arg>
</Call>

Arc がパスを見つけることができ、指定されたパスで読み取りと書き込みを行う適切な権限を持っている場合、指定されたディレクトリにデータフォルダが作成されます。

外部Java サーバー

クロスプラットフォーム版を外部のJava サーブレット（アプリケーションに含まれるJetty サーバー以外のサーバー）で使用する場合、アプリケーションのデータディレクトリの設定の詳細は使用する特定のサーブレットに依存します。特定のサーブレットに適した構文を使用するAppDirectory 環境変数を目的のディレクトリへのパスに設定する必要があります。

Arc がAppDirectory パスを見つけることができ、指定されたパスで読み取りと書き込みを行う適切な権限を持っている場合、指定されたディレクトリにデータフォルダが作成されます。

ロックおよび同時実行

Arc はロックを使用して、複数のインスタンスが互いに干渉したり、同じファイルを2度処理したりしないようにします。クラスタ環境では、スループットを維持し、衝突を防ぐために効率的なロックが重要です。ファイルシステムの遅延が問題になる可能性があるため、複数のサーバーファームにわたってArc インスタンスをクラスタ化しないことを強くお勧めします。

Arc の各インスタンスに共有アプリケーションディレクトリを設定するだけで、各インスタンスで確実にファイルロックが尊重されるようになります。

リバースプロキシの設定

A reverse proxy is a server that sits between clients and backend servers, intercepting incoming traffic and forwarding it to the appropriate destination. When configured properly, reverse proxies can preserve the real client IP address through header forwarding while protecting your backend infrastructure from direct exposure. This architecture provides benefits such as load balancing, improved security, caching, and SSL termination.

When a reverse proxy forwards client information through headers like X-Forwarded-For, it is critical to restrict which proxies are trusted. If you don’t explicitly trust only your known proxy IP addresses, malicious users can fabricate these headers to spoof their origin, potentially bypassing security controls or logging mechanisms.

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

To configure reverse proxies in the Cross-Platform edition, set the proxyMode setting in the arc.properties file to true, as shown in the following string: cdata.http.proxyMode=true.

When proxyMode=true, the embedded Jetty server uses ForwardedRequestCustomizer to extract and apply the real client IP from forwarded headers.

If you are using an external Java servlet container, configure request rewriting at the servlet level to handle forwarded headers appropriately.

.NET 版

To configure reverse proxies in the .NET edition, you must provide a comma-separated list of header names that the app should use to determine the client IP address in the HTTP Forwarded Header field on the Proxy Settings portion of the Security page.

Example: Setting a Reverse Proxy Using an nginx Proxy

It is the proxy’s responsibility to ensure clients cannot spoof the header being used for the forwarded IP address. This example illustrates a proxy setting which includes reverse proxy settings.

location /arc/ {
  proxy_pass http://localhost:8080/;
  proxy_set_header Host              $host;
  proxy_set_header Referer           $http_referer;
  proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_set_header X-Forwarded-Port  $server_port;
  proxy_set_header X-NginX-Proxy     true;
  proxy_redirect http://localhost:8008/ http://$host:8008/arc/;
}
  <!-- Declare all trusted IP or CIDR -->
  set_real_ip_from 192.168.1.100;
  set_real_ip_from 10.0.0.0/8;

  <!-- Define the request header field whose value will be used to replace the client address -->
  <!-- It affects the Nginx interval variable "$remote_addr" -->
  real_ip_header X-Forwarded-For;

  <!-- Enable recursive resolution to skip all trusted proxy IPs from X-Forwarded-For -->
  real_ip_recursive on
  
  <!-- Optionally, set the real client IP to a new header -->
  Jetty_Forwarded-For: $remote_addr

This configuration prevents header spoofing by explicitly trusting only the specified proxy IPs (192.168.1.100 and 10.0.0.0/8). If a malicious user fabricates an X-Forwarded-For header, nginx ignores it and uses the IP closest to the client that came through the trusted proxy.