> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arc.cdata.com/llms.txt
> Use this file to discover all available pages before exploring further.

# クラスタリング

> 高可用性とスケーラビリティのために複数のCData Arc インストールを連携して動作させるように設定する方法。

export const siteNameShort = "Arc";

export const siteName = "CData Arc";

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

## 概要

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

<img src="https://mintcdn.com/cdata-arc/-adMVRA2NGLWRgFp/public/images/clustering_load_balancer.png?fit=max&auto=format&n=-adMVRA2NGLWRgFp&q=85&s=314326f21a649b5fb614e088d1931c16" alt="ロードバランサーの背後にあるクラスター" width="350" data-path="public/images/clustering_load_balancer.png" />

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

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

## クラスタリングのための{siteNameShort} の設定

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

### ライセンス

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

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

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

#### .NET 版

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

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

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

#### 組み込みJava サーバー

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

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

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

#### 外部Java サーバー

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

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

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

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

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

#### .NET 版

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

```xml theme={null}
<!-- appSettings>
 <add key="AppDirectory" value="C:\\directory\\subdirectory\\subdirectory\\" />
</appSettings -->
```

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

#### 組み込みJava サーバー

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

```xml theme={null}
<Call name="setInitParameter">
 <Arg>AppDirectory</Arg>
 <Arg>/mnt/shared/arc</Arg>
</Call>
```

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

#### 外部Java サーバー

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

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

### ロックおよび同時実行

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

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

### リバースプロキシの設定

リバースプロキシは、クライアントとバックエンドサーバーの間に位置するサーバーで、受信トラフィックを傍受して適切な宛先に転送します。適切に設定すると、リバースプロキシは、バックエンドのインフラストラクチャを直接の露出から保護しながら、ヘッダー転送を通じて実際のクライアントIP アドレスを保持できます。このアーキテクチャは、ロードバランシング、セキュリティの向上、キャッシュ、SSL ターミネーションといったメリットを提供します。

リバースプロキシが`X-Forwarded-For` のようなヘッダーを通じてクライアント情報を転送する場合、どのプロキシを信頼するかを制限することが重要です。既知のプロキシIP アドレスのみを明示的に信頼しないと、悪意のあるユーザーがこれらのヘッダーを偽造して自身の発信元を偽装し、セキュリティ制御やログ記録の仕組みを回避できてしまう可能性があります。

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

クロスプラットフォーム版でリバースプロキシを設定するには、`arc.properties` ファイルの[proxyMode](../installation/arc-properties-configuration#cdata-http-proxymode) 設定を、次の文字列に示すようにtrue に設定します：`cdata.http.proxyMode=true`。

`proxyMode=true` の場合、組み込みJetty サーバーは`ForwardedRequestCustomizer` を使用して、転送されたヘッダーから実際のクライアントIP を抽出して適用します。

外部のJava サーブレットコンテナを使用している場合は、転送されたヘッダーを適切に処理するために、サーブレットレベルでリクエストの書き換えを設定します。

#### .NET 版

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

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

転送されるIP アドレスに使用されるヘッダーをクライアントが偽装できないようにするのは、プロキシの責任です。この例は、リバースプロキシ設定を含むプロキシ設定を示しています。

```
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
  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
```

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