システムは、システムのパフォーマンスを向上させるのに役立ちます:

  • ロードバランシング:詳しくは以下をご覧ください;

  • フェイルオーバー:詳しくは以下をご覧ください;

  • Distributions caching: これはdvserver-standalone-cluster.xml設定ファイルで自動的に行われます;

  • イベントの配布:メタデータとデータの変更は、すべてのクラスタメンバーに配布されます。

Load Balancing

JDBC

最も単純な形でロードバランシングを有効にするには、URL接続文字列で複数のホスト名とポート番号の組み合わせを指定します。以下はその例です:

jdbc:cdatavirtuality:<vdb-name>@mm://host1:31000,host1:31001,host2:31000;version=2

データソースを使用して CData Virtuality Server に接続する場合は、AlternateServersプロパティ/メソッドを使用してフェールオーバー サーバーを定義します。また、ホストとポートの組み合わせをカンマで区切ったリストも指定します。

クライアントはリストからランダムに1つのサーバーを選び、そのサーバーとセッションを確立します。このサーバーに接続できない場合、残りの各サーバーにランダムな順序で接続が試みられます。これにより、接続時間のフェイルオーバーとランダムなサーバー選択の負荷分散の両方が可能になります。

HAProxy

ロードバランシングと高可用性を有効にするもう1つの方法は、HAProxyを使用することです。HAProxy の詳細については、this articleおよび Luigi Fugaro’s exampleを参照してください。

ロードバランサーは、CData Virtuality Server セッションが元のホストに固有であるため、スティッキー接続をサポートするアルゴリズムを使用する必要があります。HAProxy では、leastconnまたはsourceを使用することをお勧めします。

Failover

JDBC URL のautoFailover接続プロパティがTRUEに設定されている場合、ポスト接続フェイルオーバーが使用されます。ポスト接続フェイルオーバーは、使用前に接続をテストするために、最大で1秒ごとにpingを送信することで機能します。Pingが失敗した場合、操作を試みる前に新しいインスタンスが選択されます。

これは、クライアントがトランザクション/クエリを再起動したり、セッションをスコープした一時テーブルを再作成したりしないため、本当の「透過的なアプリケーション・フェイルオーバー」ではありません。

Running the CData Virtuality Server in Cluster Mode

CData Virtuality Server をクラスタモードで実行するには、以下の手順に従ってください。

Note that all nodes need to be connected to the same dvconfig database.

Single-server Clustering Sandbox Configuration

1. dvserverの2番目のコピーを作成し、dvserver-clusterスクリプトの最後の行のコメントを解除して、最初のdvserver上で、dvserver-clusterが次のようになるようにします:

  • Windows ( dvserver-cluster.bat ):

cd /d "%~dp0%"
"%~dp0%\standalone.bat" --server-config=dvserver-standalone-cluster.xml -Djboss.node.name=dvserver1
  • Linux ( dvserver-cluster.sh ):

./standalone.sh --server-config=dvserver-standalone-cluster.xml -b 0.0.0.0 -Djboss.node.name=dvserver1

そして、2番目のdvserverでは、このようにします:

  • Windows ( dvserver-cluster.bat ):

cd /d "%~dp0%"
"%~dp0%\standalone.bat" --server-config=dvserver-standalone-cluster.xml -Djboss.node.name=dvserver2 -Djboss.socket.binding.port-offset=100
  • Linux ( dvserver-cluster.sh ):

./standalone.sh --server-config=dvserver-standalone-cluster.xml -b 0.0.0.0 -Djboss.node.name=dvserver2 -Djboss.socket.binding.port-offset=100

2. dvserver-clusterスクリプトを使用して、最初のdvserverを実行します。

3. 最初のdvserverはコーディネータとして構成されます。サーバが完全に起動するのを待ちます: コーディネータプロセスによってクラスタに接続されます。

4. 2台目のdvserverを実行します。1台目のdvserver上のコーディネータプロセスにより、クラスタに接続されます。

5. プライマリ dvserver に障害が発生した場合、コーディネータ業務はシステム内で次に使用可能なサーバーに自動的に引き継がれます。

6. 最初のdvserverのJDBCホストは以下のようになります:localhost:31000また、2番目のサーバーのJDBCホストは次のようになります:localhost:31100 .

Multi-server Clustering Configuration

高可用性構成では、デフォルトのマルチキャストアドレスが230.0.0.4に設定されています。また、dvserver-standalone-cluster.xmlファイルの socket-binding セクションでも変更できます。あるいは、-u 230.0.1.2のようにパラメータとして追加することもできます。

1. dvserverの2番目のコピーを作成し、dvserver-clusterスクリプトの最後の行のコメントを解除して、最初のdvserver上で、dvserver-clusterが次のようになるようにします:

  • Windows ( dvserver-cluster.bat ):

cd /d "%~dp0%"
"%~dp0%\standalone.bat" --server-config=dvserver-standalone-cluster.xml -b 172.16.0.1 -u 230.0.0.4 -Djboss.node.name=dvserver1
  • Linux ( dvserver-cluster.sh ):

./standalone.sh --server-config=dvserver-standalone-cluster.xml -b 172.16.0.1 -u 230.0.0.4 -Djboss.node.name=dvserver1

そして、2番目のdvserverでは、このようにします:

  • Windows ( dvserver-cluster.bat ):

cd /d "%~dp0%"
"%~dp0%\standalone.bat" --server-config=dvserver-standalone-cluster.xml -b 172.16.0.2 -u 230.0.0.4 -Djboss.node.name=dvserver2 -Djboss.socket.binding.port-offset=100
  • Linux ( dvserver-cluster.sh ):

./standalone.sh --server-config=dvserver-standalone-cluster.xml -b 172.16.0.2 -u 230.0.0.4 -Djboss.node.name=dvserver2 -Djboss.socket.binding.port-offset=100

In the examples above, -b 172.xx.xx.xx is the IP address of the computer the CData Virtuality Server is running on.

2. dvserver-clusterスクリプトを使用して、最初のdvserverを実行します。

3. 最初のdvserverはコーディネータとして構成されます。サーバが完全に起動するのを待ちます: コーディネータプロセスによってクラスタに接続されます。

4. 2台目のdvserverを実行します。1台目のdvserver上のコーディネータプロセスにより、クラスタに接続されます。

5. プライマリ dvserver に障害が発生した場合、コーディネータ業務はシステム内で次に使用可能なサーバーに自動的に引き継がれます。

6. 最初のdvserverのJDBCホストは以下のようになります:172.16.0.1:31000、2つ目は以下のとおり:172.16.0.2:31100.

Limitations

SELECT INTO操作が失敗した場合、メタデータはすべてのノードから自動的に削除されません。そのため、個々のノードに対して手動でリフレッシュする必要があります。

JDBC connection string changed in v4.10: both jdbc:datavirtuality and jdbc:cdatavirtuality are acceptable