システムは、システムのパフォーマンスを向上させるのに役立ちます:
ロードバランシング:詳しくは以下をご覧ください;
フェイルオーバー:詳しくは以下をご覧ください;
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