ThingWorx 高可用性
ThingWorx 高可用性クラスタの概要
重要なモノのインターネット (IoT) システムの停止時間を削減するため、ThingWorx が高可用性 (HA) 環境のクラスタモードで動作するように設定できます。クラスタでは、すべてのコンポーネントが適切に設定されている場合、スケーラビリティと高可用性が向上します。
 |
HA クラスタは、災害復旧ソリューションには使用しないでください。
|
|
|
HA 展開に複数の可用性ゾーンを使用することはサポートされていません。ThingWorx と Apache Ignite ノードの間で持続的に通信が行われる場合、ゾーン間のネットワークの待ち時間が長すぎる場合があります。
|
以下の各セクションでは、クラスタ環境の設定と構成、および ThingWorx HA 展開での各コンポーネントと考慮事項について概要を説明します。
すべての HA 展開では、機能とスケールの要件を満たすためだけに設計された展開と比べて追加リソースが必要です。これらの追加リソースには、ハードウェアベースのもの (サーバー、ディスク、ロードバランサーなど) とソフトウェアベースのもの (同期化サービスやロードバランサーなど) があります。HA 展開内で単一障害点が存在することがないように追加リソースが構成されます。
すべての HA 展開は、各自の展開におけるアプリケーションのアップタイム要件の分析結果である SLA (サービス品質保証契約) に基づいていなければなりません (たとえば、毎月何時間システムをオフラインにできるか? これはシステムの失敗、アプリケーションのアップグレード、またはその両方で許容される非稼動時間か?)。HA システムに必要な追加リソースの数は、HA システムが達成する必要がある SLA によって異なります。一般に、SLA が高度化するにしたがい、それを実現するためのリソースへのニーズも大きくなります。
用語集
• 高可用性
希望どおり長時間稼動し続けるシステムまたはコンポーネント。
• スケーラビリティ
メモリ、ディスク、CPU を増やしたり、サーバーを追加したりすることで、システムがサポート可能な負荷を増やすことができる能力。
• クラスタ
同時に機能可能な同じアプリケーションの複数のインスタンス。クラスタは高可用性とスケーラビリティを実現します。
• シングルトン
シングルトンサーバーは、タイマーやスケジューラなどのクラスタ間動作を処理する、クラスタ内の 1 つのサーバーです。これにより、タスクはクラスタ内で 1 回だけ実行されます。
• 仮想 IP アドレス
アプリケーションを表す IP アドレス。仮想 IP アドレスを使用するクライアントは、通常はロードバランサーにルーティングされ、ロードバランサーはアプリケーションを実行しているサーバーにリクエストを転送します。
• ロードバランサー
ネットワークトラフィックを受信して、これを受け付ける準備が整っているアプリケーションに分散するデバイス。
• フェールオーバー
バックアップ動作モード。プライマリコンポーネントが失敗またはスケジュールされたダウンタイムによって使用できなくなった場合、システムコンポーネント (プロセッサ、サーバー、ネットワーク、またはデータベース) の機能はセカンダリシステムコンポーネントによって実行されます。
• 最終的な一貫性
変更がクラスタ環境のすべてのサーバーに反映されるまでには時間がかかります。詳細については、最終的な一貫性を参照してください。
• 共有状態
クラスタ内の複数のサーバー間で共有されている状態。どのサーバーから見ても同じであることが保証されます。プロパティデータは共有状態の一例であり、現在のプロパティ値はすべてのサーバーで同じです。
高可用性での ThingWorx 参照アーキテクチャ
以下の図に、クラスタ構成の ThingWorx を示します。
クラスタ展開では以下のコンポーネントが含まれている場合があります。
• ユーザーおよびデバイス - HA 機能におけるロールはありません。これらの観点からは何の変化もありません。プライマリ ThingWorx サーバーに変更があった場合でも、これらは必ず同じ URL と IP アドレスを使用します。
• ファイアウォール - HA 機能はなく、オプションと見なすことができます。ファイアウォールは通常はセキュリティの要件を実装するために配置されます。
• ロードバランサー - ロードバランサーはサポートしているアプリケーションの仮想 IP アドレスを管理します。その仮想 IP アドレスにルーティングされるすべてのトラフィックが、それを受信可能なアクティブなアプリケーションに転送されます。
• ThingWorx Connection Servers - アセットから Web ソケットトラフィックを受信し、ThingWorx Platform にルーティングします。接続サーバーはクラスタ構成で動作できます。アセットが特定の Connection Server に転送された後は、そのアセットは必ず同じ Connection Server を使用します。そのサーバーがオフラインになった場合、使用可能な別の Connection Server にアセットがリダイレクトされなければなりません。
• ThingWorx Foundation - すべてのユーザートラフィックとアセットトラフィックを受信します。
• ThingWorx リポジトリ - ThingworxPlatform、ThingworxStorage、ThingworxBackupStorage などの必須の保存場所や、実装をサポートするために追加された保存場所。クラスタ環境では、ストレージフォルダが共通の保存場所に存在し、すべての ThingWorx サーバーが等しくアクセスできるようにする必要があります。
• Apache ZooKeeper - ZooKeeper は、ThingWorx Connection Server および Ignite によってサービス検出、シングルトン選出、分散調整に使用される一元的調整サービスです。
• Apache Ignite - Ignite はクラスタ内の複数のサーバー間で状態を共有するための分散メモリキャッシュを提供します。
• PostgreSQL - HA 構成では、PostgreSQL はホットスタンバイ構成の 2 つ以上のサーバーノード上で動作します。1 つのノードがすべての書き込みトラフィックを受信し、その他のノードのいずれかがすべての読み取りトラフィックを受信できます。各ノードが最新の状態を維持するため、すべてのノード間でストリーミングレプリケーションがアクティブ化されます。
• Pgpool-II - これは PostgreSQL HA 構成でのみ使用されます。Pgpool-II ノードは ThingWorx リクエスト (読み取りおよび書き込み) を受信して適切な PostgreSQL ノードに転送します。各 PostgreSQL ノードの正常性も監視し、いずれかのノードがオフラインになった場合、フェールオーバータスクとターゲット変更タスクを開始できます。
• Microsoft SQL Server (図には示されていません) - Microsoft フェールオーバーを使用して、少なくとも 1 台の MS SQL サーバーがオンラインで稼動しているようにします。
• InfluxDB - ThingWorx クラスタ構成では InfluxDB の実装は必要ありません。実装の取得要件を満たす必要がある場合、これを HA 構成にします。