失敗が発生した場合に予期される動作
このセクションでは、1 つ以上のコンポーネントの失敗に対応するために ThingWorx HA 構成で発生する処理について説明します。
ThingWorx サーバーの失敗
ThingWorx リーダーノードが失敗
実行される HA のプロシージャ
1. ZooKeeper はリーダーからの応答を受信しなくなります。
2. ZooKeeper はスタンバイ ThingWorx サーバーのプールから新規リーダーを選出します。
3. ZooKeeper はそのスタンバイノードにリーダーになるように通知します。
4. 新規リーダーはデータベースに完全に接続して ThingWorx モデルを初期化します。
5. 新規リーダーはすべての ThingWorx リクエストをルーティングさせるようにロードバランサーに確認を送信します。
6. ロードバランサーはすべての ThingWorx トラフィックを新規リーダーにルーティングします。
ロードバランサーの失敗
処理と結果は展開されているロードバランサー HA ソリューションによって異なります。ロードバランサーのすべてのノード間でセッションのコンテンツを共有する能力がロードバランサーに備わっている場合、アクティブなセッションが中断されてはなりません。
HAProxy サーバーの失敗
1 つしかない HAProxy ノードが失敗したかすべての HAProxy ノードが失敗した場合、以下の処理が行われます。
• ThingWorx リーダーにはその IP アドレスを介して引き続きアクセスできますが、HAProxy IP アドレスを介してはアクセスできなくなります。
• HAProxy を介した ThingWorx へのリクエストは ThingWorx に届きません。
複数の HAProxy ノードのいずれかが失敗した場合、以下の処理が行われます。
• バックアップ HAProxy が新規マスターになると、既存のユーザーセッションが ThingWorx Composer で認識されます。ユーザーが再びログインする必要はありません。
• バックアップ HAProxy がマスターになるまでマッシュアップはロードされません。
• バックアップ HAProxy がマスターになるまで Composer でブラウズ中のエンティティはロードされません。
• バックアップ HAProxy がマスターになるまでリクエストは ThingWorx に届きません。
Zookeeper ノードの失敗
1 つの Zookeeper ノードの失敗
3 つの Zookeeper ノードのうちの 1 つが失敗した場合、以下の処理が行われます。
• その他の Zookeeper ノードは失敗を検出して応答します。
• 失敗したノードが現在のリーダーである場合、新規 Zookeeper リーダーが選出されます。
• ThingWorx サーバーはいずれも影響を受けません。これらはアクティブでアクセス可能なままとなります。
2 つの Zookeeper ノードの失敗
• 本来の 3 ノード ZooKeeper 設定では定足数を満たすために 2 台のサーバーが利用可能であることを前提としているので、ZooKeeper のリーダー選出は行えません。許容される失敗の最大数 = ceil(N/2) - 1
• 残りの ZooKeeper インスタンスはリーダーでもスタンバイでもありません。
• ThingWorx リーダーはリーダー選出のための ZooKeeper との通信を行えないのでシャットダウンします。
• ThingWorx スタンバイサーバーはほかの 1 つ以上の ZooKeeper ノードが復帰するまで ZooKeeper との通信を何度も試みます。
• 2 つ以上の ZooKeeper ノードがオンラインに戻ると、ZooKeeper リーダー選出が行われます。ThingWorx スタンバイノードは ZooKeeper に再接続して新規リーダーとして復帰します。
• 以前の ThingWorx リーダーを再起動してスタンバイさせなければなりません。
ThingWorx および ZooKeeper の失敗
ZooKeeper および ThingWorx の両方のリーダーが失敗した場合、以下の処理が行われます。
• 「1 つの Zookeeper ノードの失敗」で示されているすべての状態。新規 ZooKeeper リーダーによって新規 ThingWorx リーダーが選出されるので、先に新規 ZooKeeper リーダーを決定しなければなりません。
• 「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 マスターが確立されると接続に成功します。
Pgpool-II および PostgreSQL の失敗
PostgreSQL および Pgpool-II が失敗した場合、以下の処理が行われます。
• PostgreSQL スタンバイノードがマスターノードになります。
• Pgpool-II スタンバイノードがマスターノードになり、これに仮想 IP アドレスが移されます。
• フェールオーバー中、サービスが一時的に使用できなくなります。