失敗が発生した場合に予期される動作
このトピックでは、1 つ以上のコンポーネントの失敗に対応するために ThingWorx クラスタ構成で発生する処理について説明します。
ロードバランサーの失敗
処理と結果は展開されているロードバランサー HA ソリューションによって異なります。ロードバランサーのすべてのノード間でセッションのコンテンツを共有する能力がロードバランサーに備わっている場合、アクティブなセッションが中断されてはなりません。
HAProxy サーバーの失敗
1 つしかない HAProxy ノードが失敗したかすべての HAProxy ノードが失敗した場合、以下の処理が行われます。
• ThingWorx リーダーにはその IP アドレスを介して引き続きアクセスできますが、HAProxy IP アドレスを介してはアクセスできなくなります。
• HAProxy を介した ThingWorx へのリクエストは ThingWorx に届きません。
複数の HAProxy ノードのいずれかが失敗した場合、以下の処理が行われます。
• バックアップ HAProxy が新規マスターになると、既存のユーザーセッションが ThingWorx Composer で認識されます。ユーザーが再びログインする必要はありません。
• バックアップ HAProxy がマスターになるまでマッシュアップはロードされません。
• バックアップ HAProxy がマスターになるまで Composer でブラウズ中のエンティティはロードされません。
• バックアップ HAProxy がマスターになるまでリクエストは ThingWorx に届きません。
ThingWorx サーバーの失敗
ThingWorx サーバーの失敗が発生した場合、次の処理が行われます。
• 正常性チェックの ping が失敗するので、そのサーバーがロードバランサーから除去されます。除去のタイミングはチェックの頻度によって異なります。
• ZooKeeper はサーバーが失敗したことを検出し、そのサーバーを内部サービス検出から除去し、接続サーバーなどのウォッチャーに通知します。
• サーバーがシングルトンサーバーである場合、ZooKeeper はほかのサーバーに通知し、新しいシングルトンサーバーを選択します。
そのサーバーに接続されているクライアントは、切り替え時にエラーを受信することがありますが、その後で新規サーバーに再接続します。
サーバーが失敗したりサーバーが強制終了されたりした場合、データが失われる可能性があります。このような場合、バッチキュー内のデータは失われます。サーバーが失敗したのではなくシャットダウンした場合、サーバーの登録解除によって上記の処理が行われ、バッチキューがドレインされます。
ThingWorx Platform ノードがダウン
少なくとも 1 つの Platform インスタンスが正常な状態であれば、システムに影響を与えることなくほかのノードを再起動できます。ただし、すべての Platform ノードがダウンしているか正常でない場合、Ignite に保存されている状態が不一致になります。この場合、すべての Platform ノードを停止し、すべての Ignite ノードを停止してから、再起動する必要があります。
1. すべての Platform ノードを停止します。
2. すべての Ignite ノードを停止します。
3. すべての Ignite ノードを再起動します。
4. すべての Platform ノードを再起動します。
Ignite を再起動しなかった場合、Ignite に保存されているバインドマップやその他のデータが正しくなくなり、時間の経過とともに異常な動作が発生するようになります。
ZooKeeper の失敗
ノードの失敗
いずれかの Zookeeper ノードが失敗した場合、以下の処理が行われます。
• その他の Zookeeper ノードは失敗を検出して応答します。
• 失敗したノードが現在のリーダーである場合、新規 Zookeeper リーダーが選出されます。
複数のノードの失敗
複数のノードが失敗し、ZooKeeper がその定足数を満たさなくなった場合、読み取り専用モードになり、変更リクエストを却下します。
• 本来の 3 ノード ZooKeeper 設定では定足数を満たすために 2 台のサーバーが利用可能であることを前提としているので、ZooKeeper のリーダー選出は行えません。許容される失敗の最大数 = ceil(N/2) - 1
• 残りの ZooKeeper インスタンスはリーダーでもスタンバイでもありません。
• すべてのクライアントが SUSPENDED を受信し、最終的に LOST 状態になります。
ThingWorx サーバー
• SUSPENDED 状態の間、シングルトンの役割は未割り当てになります。この間、タイマーやスケジューラは実行されません。
• LOST ステータスでは、すべてのノードがシャットダウンします。
• システムがタイムアウトになる前に ZooKeeper が回復した場合、新しいシングルトンが選出され、処理が続行されます。
Connection Server
• 接続サーバーが ZooKeeper から LOST 状態を取得した場合、ThingWorx サーバーのステータスがわからないのでシャットダウンします。
Ignite
• ZooKeeper クラスタはクラスタ内のすべてのノードに常に表示されているものと見なされます。ノードが ZooKeeper から切断された場合、そのノードはシャットダウンし、ほかのノードはそのノードを失敗したノードまたは切断されたノードと見なします。
Ignite の失敗
Ignite の失敗の影響はデータレプリケーションレベルに基づきます。Ignite は必ず、クラスタ内の少なくとも 2 つのノードにデータを保存するように設定されている必要があります。したがって、いずれか 1 つのノードが失われた場合、システムには影響がありません。
複数のノードが失われた場合、データが失われる可能性があり、これによってシステムが一貫していない状態になることがあります。これが発生した場合、Ignite と ThingWorx を完全にシャットダウンすることをお勧めします。その後で、Ignite を再起動し、ThingWorx を再起動できます。Ignite はアプリケーションメモリであり、これが失われた場合、処理の動作が非常に一貫していない状態になることがあります。
Ignite 全体が失敗して ThingWorx がどの Ignite ノードにも接続できない場合、ThingWorx はシャットダウンします。
データのバックアップについては、以下を参照してください。
PostgreSQL の失敗
PostgreSQL の失敗に関する説明は以下の構成に基づいています。
• 3 つの PostgreSQL ノード (ライター、リーダー、スタンバイ)
• PostgreSQL ノード間でストリーミングレプリケーションを使用
• PostgreSQL ノードへのクライアントアクセスの管理と PostgreSQL 回復プロシージャの管理を行う 2 つの Pgpool-II ノード
PostgreSQL サーバーが失敗した場合、アクティブな Pgpool-II ノードが失敗を検出し、そのサーバーへのリクエストのルーティングを停止します。失敗前に情報がコミットされてほかのノードにレプリケーションされていない場合、失敗時に保存中であったユーザーデータまたはデバイスデータは失われる可能性があります。
マスター PostgreSQL ノードが失敗した場合 (同期ノードと潜在ノードが動作していることを前提として)、以下の処理が行われます。
• Pgpool-II を介して同期ノードへのフェールオーバーが発生します。潜在ノードが新規マスターノードとの同期ノードになります。データベースへの書き込みは引き続き可能です (新規エンティティの作成や BDWS へのデータの書き込みなど)。
• 元のマスターが復帰した場合、手動でクリーンアップし、元のマスターを使用するように環境を設定する必要があります。
両方のスタンバイノードが失敗した場合 (マスターノードが動作していることを前提として)、以下の処理が行われます。
• フェールオーバーは発生せず、マスターノードのレプリケーション用ノードの数がゼロになります。
• Composer は引き続きアクセス可能です。エンティティがロードされ、表示できますが、保存はされません。ログを表示できます。
• PostgreSQL がデータをスタンバイノードにレプリケーションしなければならないので、データベースへの書き込みを必要とする操作 (エンティティの作成と保存、永続化プロパティへの値の設定、ストリームエントリの追加など) は成功しません。
マスターノードおよび同期スタンバイノードが失敗した場合、以下の処理が行われます。
• 潜在ノードへのフェールオーバーが発生します。潜在ノードがマスターノードになり、レプリケーション用ノードの数がゼロになります。
• Composer はアクセス可能です。エンティティがロードされ、表示できますが、保存はされません。ログを表示できます。
• 書き込みがハングして最終的に失敗するので、データベースへの書き込みを必要とする操作 (エンティティの作成と保存、永続化プロパティへの値の設定、ストリームエントリの追加など) は成功しません。
3 つのノードすべてが失敗した場合、以下の処理が行われます。
• 使用可能なノードがないので、フェールオーバーは発生しません。
• Composer はデータベースにアクセスできなくなります。したがって、エンティティはロードされず、ほとんどのサービスは動作せず (プラットフォームサブシステムなどのサブシステムサービスは引き続き動作する場合があります)、システムの機能が制限されます (ログ、システム監視、マッシュアップは動作する場合があります)。
• データベースへの書き込みおよびデータベースからの読み取りができなくなります。
ThingWorx および PostgreSQL の失敗
ThingWorx リーダーおよび PostgreSQL マスターの両方が失敗した場合、以下の処理が行われます。
• ThingWorx リーダーがダウンした後でスタンバイ ThingWorx インスタンスがリーダーになり、PostgreSQL データベースの同期ノードが PostgreSQL マスターノードになります。
◦ PostgreSQL データベースの潜在ノードが新規同期ノードになります。
◦ ThingWorx Composer は使用可能であり、PostgreSQL データベースへの書き込みを行えます (エンティティを作成、編集、および削除でき、データを追加できます)。
• 元の PostgreSQL マスターノードをマスターノードとしてリセットしなければならない場合、PostgreSQL ノードおよび Pgpool-II を手動でクリーンアップしなければなりません。
Pgpool-II ノードの失敗
アクティブ Pgpool-II ノードの失敗
アクティブ Pgpool-II ノードが失敗した場合、バックアップがこれを検出し、PostgreSQL サーバーへのすべてのリクエストの処理を継承します。アクティブな ThingWorx サーバーにログオンしているユーザーはそのアプリケーションで遅延が生じることがあり、Pgpool-II ノードの失敗が発生したときに保存中であったユーザーデータまたはデバイスデータが失われる可能性があります。
すべての Pgpool-II ノードの失敗
Pgpool-II のすべてのインスタンスが失敗した場合、ThingWorx は PostgreSQL のコンテンツにアクセスできなくなり、ほとんどの機能が失敗します。以下の領域ではいくつかの制限された機能を使用できます。
• ログ作成 - アプリケーションログでは引き続きエラーメッセージが更新されます。
• システム監視 (MonitoringPlatformStats マッシュアップなど)
• マッシュアップ - データベースのサービスまたはデータに依存しないウィジェットは引き続き動作します。
• 非永続化プロパティのプロパティ値
• データベースを利用しないサービス。
ThingWorx および Pgpool-II の失敗
ThingWorx リーダーインスタンスおよび Pgpool-II マスターインスタンスが同時に失敗した場合、以下の処理が行われます。
• ThingWorx リーダーはリーダシップを失い、スタンバイノードのいずれかがリーダーになります。
• Pgpool-II マスターは仮想 IP アドレスを失います。Pgpool-II スタンバイノードのいずれかがマスターになり、これに仮想 IP アドレスが再割当されます。
• ThingWorx スタンバイサーバーがデータベースへの完全な接続を試み、新規 Pgpool マスターが確立されると接続に成功します。
• ThingWorx リーダーの失敗で示されているプロシージャと動作が適用されます。
Pgpool-II および PostgreSQL の失敗
PostgreSQL および Pgpool-II が失敗した場合、以下の処理が行われます。
• PostgreSQL スタンバイノードがマスターノードになります。
• Pgpool-II スタンバイノードがマスターノードになり、これに仮想 IP アドレスが移されます。
• フェールオーバー中、サービスが一時的に使用できなくなります。