ThingWorx HA での最終的な一貫性
クラスタモードで ThingWorx を実行している場合、最終的にはモデルの変更がクラスタ全体で一貫して行われます。サーバー A での変更がサーバー B、C などと同期化されるまで少しの時間を要します。変更ウォッチャーが設定可能な頻度 (デフォルトは 100 ms) で動作し、エンティティに変更がないか監視します。変更ウォッチャーはそのデータベースが正しい情報源であるものとして、そのサーバーで変更されたエンティティをアンロードしてから再ロードします。この最終的な一貫性はモデルとコンフィギュレーションの変更のみに適用され、状態はただちに一貫性が保証されます。
• HTTP - HTTP では、個々のユーザーが単一のマシンに関連付けられるように、スティッキーセッションが使用されます。これにより、ユーザーにはすべての変更がただちに表示されます。ほかのサーバー上でほかのユーザーが行った変更は最終的に一貫した状態になります。
• WebSocket - WebSocket を介してモデルの変更が行われた場合、モデルの最新バージョンが WebSocket セッションに保存されます。WebSocket リクエストは負荷分散のために常にラウンドロビン方式で行われます。その WebSocket セッションで行われた次のリクエストは、接続先のサーバーがセッションに保存されているバージョン以上になるまで一時停止します。サーバーがおおよそ 1 秒以内に同期化できない場合、タイムアウトになります。
次のシナリオでは、ユーザーへの影響を軽減する方法について説明します。
• シナリオ 1: HTTP
デバイス > HAProxy > Platform1..N
このシナリオでは、platform 1 に接続してモデルの変更を行います。別のユーザーを platform 2 に接続し、変更の有無をチェックすると、最終的には変更内容が表示されます。同期化プロセスを使用することで、このクラスタはモデルの変更について最終的に一貫した状態になります。この使用例では、変更が有効になるまで待機する再試行を組み込む必要があります。
• シナリオ 2: WebSocket
デバイス > HAProxy > CXServer1..N => Platform1..N
このシナリオでは、デバイスは接続サーバーとポイントツーポイントです。プラットフォームリクエストはラウンドロビン方式になります。デバイスがモデルの変更を行った後、別のサーバーに対して別のリクエストを行った場合、処理の前に最初の変更が同期化されます。モデルのバージョンが、変更が加えられたバージョン以上と同期化されるまで、リクエストは遅延します。一定時間内に同期化できない場合、リクエストはタイムアウトになります。したがって、このデバイスはどのサーバーとも通信でき、適切な応答が得られます。
1 つ目のデバイスによる変更を監視させるために 2 つ目のデバイスを接続している場合、2 つ目のデバイスにも最終的な一貫性が適用されます。このシステムは単一の接続で変更を待機することのみが保証されています。
• シナリオ 3: モデル変更の HTTP リクエストが接続先デバイスへの通知をトリガー
デバイス > HAProxy > CXServer1..N => Platform1..N
ユーザーはモデルの変更を行い、デバイスはその変更について通知を受けるので、定義を再度取得できます。デバイスは変更がまだ反映されていないサーバーからデータを取得する可能性がありました。現在では、モデルバージョンが WebSocket セッションに注入されるので、下位バージョンのモデルが保存されているサーバーに対してリクエストが行われた場合、そのバージョン以上のモデルと同期化されるのを待ってからモデルを返します。一定時間内に同期化できない場合、リクエストはタイムアウトになります。
このため、新しい postCommitEventQueue が追加されました。プロパティ変更などの追加イベントは、トランザクションが完全にコミットされ、新しいモデルバージョンが既知になったときに発生します。デバイスに通知が送信されると、モデルバージョンが WebSocket セッションに注入され、そのデバイスからの以降のリクエストは、サーバーが元の変更と一貫した状態になるまで待機します。