ThingWorx デプロイメントのアーキテクチャ
以降の各セクションには一般的な ThingWorx デプロイメントの図が含まれています。アーキテクチャは、単純な開発システムからマルチノードクラスタ、グローバルフェデレーション型の本番システムまで多岐にわたります。ThingWorx のコンポーネントについては、ThingWorx Foundation デプロイメントのコンポーネントを参照してください。
 |
ハイブリッドおよびマルチサイトデプロイメントで ThingWorx をデプロイするには、分散 ThingWorx デプロイメントを参照してください。
|
|
|
ThingWorx サーバーと Azure PostgreSQL フレキシブルサーバーを地理的に同じ場所に配置することをお勧めします。
|
デプロイメントオプション
• PTC クラウドサービス - マネージドサービスデプロイメントでは、ThingWorx アプリケーションはサードパーティのサーバー (通常はプライベートクラウド) でホストおよび管理されます。必要なインフラストラクチャの管理とパフォーマンスの確保については外部の組織が責任を負います。
ThingWorx の管理に必要な IT の負担と専門知識に不安がある企業向けに、PTC はマネージドサービスデプロイメントオプションを提供しています。PTC クラウドサービスを利用することで、ThingWorx を購入した企業は、デプロイメントを迅速化し、IT のコストと要件を最小限に抑え、継続的にパフォーマンスを向上させることができます。PTC クラウドサービスは、アプリケーション管理、パフォーマンスチューニング、アップデートが継続的に行われる商用クラウドサービス内の安全な環境で ThingWorx ソリューションをホストします。詳細については、www.ptc.com/services/cloud を参照してください。
• オンプレミスデプロイメント - オンプレミスデプロイメントを使用するということは、ThingWorx ソフトウェアを独自のサイトまたはデータセンターのサーバーにインストールして実行することを意味します。インフラストラクチャとソフトウェアアプリケーションの調達、インストール、メンテナンスと、それらの正常性、可用性、パフォーマンスについての継続的なサポートを自社で行います。
オンプレミスデプロイメントでは、自分自身でデプロイメントを実行することも、PTC Professional Services (または PTC 認定パートナー) にデプロイメントの管理を依頼することもできます。このオプションは、しっかりした IT 組織があり、社内の管理下に置くことを強く希望する企業に適しています。
その他の詳細については、以下のセクションを参照してください。
• システム要件
• 永続化プロバイダ
ThingWorx Foundation の基本的な生産システム
基本的な生産システムでは、データベースを別個のサーバーで運用するために別個のサーバーを使用することをお勧めします。これは小規模から中規模のエンタープライズシステム、または中規模から大規模の製造システムに適しています。
コンポーネントのリスト | コンポーネントの数 |
|---|---|
ロードバランサー | 1 |
ThingWorx Connection Server | 1 |
ThingWorx Foundation サーバー | 1 |
接続型または NAS ファイルストレージ | 1 |
データベース | 1 |
ThingWorx Foundation の大規模生産システム (非 HA)
大規模な生産システムには、より多くの接続デバイスとより高いデータ取得レートをサポートするために追加のコンポーネントが組み込まれています。
大規模な生産システムには、プラットフォームコンポーネントのほかに、ThingWorx Connection Server と InfluxDB 時系列データベースが含まれていることがあります。
InfluxDB システムはアセットからのデータを取得し、ThingWorx はこれを記録された値ストリームコンテンツとして管理します。
ThingWorx モデルを管理するため、リレーショナルデータベースも必要です。
InfluxDB は取得と高可用性の要件に基づいて単一ノードまたはマルチノード (Enterprise) 構成でデプロイできます。詳細については、永続化プロバイダとしての InfluxDB の使用を参照してください。
コンポーネントのリスト | コンポーネントの数 |
|---|---|
ロードバランサー | 1 (複数の接続サーバーにデバイストラフィックを分散) |
ThingWorx Connection Server | 2..n (デバイスの数による) |
ThingWorx Foundation サーバー | 1 |
リレーショナルデータベース | 1 |
InfluxDB (単一ノード) | 1 |
ThingWorx 本番環境クラスタ
高可用性 (HA) デプロイメントでは、アプリケーションレイヤーとデータレイヤー内の単一障害点をなくすためにさらにコンポーネントが追加されます。ThingWorx プラットフォームに以下のコンポーネントが必要です。
• 高可用性ロードバランサー。接続サーバーと Foundation サーバーのどちらのノードグループでも、負荷を分散するためにロードバランサーインスタンスが必要です。Influx Enterprise クラスタが使用されている場合にはこれにもインスタンスが必要です。ロードバランサーのオプションの多くは複数のインスタンスに対応しており、適切に設定した場合、1 台の装置を使用して 3 つのインスタンスすべてに対応できます。
• 2 つ (以上) の ThingWorx Connection Server。クラスタ構成の運用では、デバイスの負荷をクラスタ全体に分散したり、ノードで障害が発生した場合に分散し直したりするために、接続サーバーが必要です。
• 2 つ (以上) の ThingWorx Foundation インスタンス。各ノードがアクティブであれば、それらのノードに負荷が分散されます。
• ThingWorxStorage は (各ノードからアクセス可能な) ディスク上の共有ストレージです。
| | 完全な高可用性デプロイメントでは、ロードバランサーと共有の ThingWorxStorage にも冗長性が実装されている必要があります。 |
• ThingWorx Foundation ノード用の共有キャッシュを提供する Apache Ignite ノード。
• 3 つの Apache ZooKeeper ノード。ZooKeeper は ThingWorx ノードを監視して、各ノードが予想どおりに応答し、機能しているかどうかを判別します。ZooKeeper ノードはクォーラムを形成し、ThingWorx ノードがオフラインであるかどうかを判別します。ThingWorx Foundation ノードがオフラインになると、ZooKeeper はほかの Foundation ノードにトラフィックを送信するように ThingWorx ロードバランサーを再設定します。
PostgreSQL データベースに以下のコンポーネントが必要です。
• PostgreSQL サーバーノード - 少なくとも 2 つ (理想的には 3 つ) のノードが使用されます。
• pgpool-II ノード - PostgreSQL サーバーで障害が発生した場合にフェールオーバータスクとリカバリタスクを実行する、少なくとも 2 つ (理想的には 3 つ) のノード。これらのノードは、クライアント (ThingWorx) とサーバー (PostgreSQL) 間の接続を維持し、PostgreSQL サーバーノード間でのコンテンツのレプリケーションを管理します。
InfluxDB Enterprise システムに以下のコンポーネントが必要です。
• InfluxDB Enterprise メタノード - クォーラムに達し、いずれかのノードで障害が発生した場合でもクラスタが動作を続行できるようにするには、3 ノード設定が推奨されます。
• InfluxDB Enterprise データノード - 1 つでも構いませんが、2 つ以上をお勧めします。InfluxDB レプリケーション係数によって割り切れるノード数にすることをお勧めします。
高可用性環境での ThingWorx のデプロイの詳細については、ThingWorx 高可用性を参照してください。
ハイスケール + 高可用性クラスタ
この図では、クラスタの各コンポーネントが独自の物理マシン、仮想マシン、またはコンテナにあります。これにより、各種コンポーネントグループそれぞれを個別に拡張できるという点で最も高い柔軟性が得られます。
コンポーネントのリスト | コンポーネントの数 |
|---|---|
ThingWorx Connection Server | 2..n (デバイスの数に基づく) |
ロードバランサー | 2 または 3 インスタンス: • 複数の接続サーバーにデバイストラフィックをルーティングします • ThingWorx ノード間でトラフィックをルーティングします • InfluxDB Enterprise データノード間でトラフィックをルーティングします (使用されている場合) |
ThingWorx Foundation サーバー | 2 ..n: 高可用性とスケーラビリティの要件に基づく |
ネットワーク/エンタープライズストレージ | すべての ThingWorx Foundation サーバー間で共有される ThingWorx ストレージリポジトリ用ディスク領域。 |
Ignite | 2 つのオプション: • Foundation プロセス内に埋め込み • 2 つ以上の別個のノード (HA 要件による) |
ZooKeeper | 最低 3 つ。奇数での割当を行う必要があります。 |
データベース | データベースによる: • PostgreSQL: 3 データベースノード + 2 pgpool-II ノード • MS SQL Server (図なし): フェイルオーバー構成の一部として最低 2。 |
InfluxDB Enterprise | 5 (またはそれ以上): • 3 つのメタノード • 2 つ以上のデータノード (合計数はレプリケーション係数によって割り切れる数でなければりません) |
最小クラスタフットプリント
この図では、コンポーネントが物理/仮想マシンの 1 つの小さなセット (コンテナ) にグループ化されています。
この構成でも高可用性を実現できますが、コンポーネントがリソースを共有しているので、分散構成と比較するとスケーラビリティは低くなります。
この図では、複数の独立した ThingWorx デプロイメントが同じ共有インフラストラクチャ (ZooKeeper、DB、ネットワークストレージ) を利用するデプロイメントを確認することもできます。
コンポーネントのリスト (クラスタノード当り) | コンポーネントの数 |
|---|---|
ThingWorx Connection Server | 1 (クラスタノード当り) |
ThingWorx Foundation サーバー | 1 (クラスタノード当り) |
Ignite | なし - 各 Foundation サーバープロセス内で埋め込みモードで実行します。 |
コンポーネントのリスト (共有) | コンポーネントの数 |
|---|---|
ロードバランサーインスタンス | 2 または 3 インスタンス: • 複数の接続サーバーにデバイストラフィックをルーティングします。 • ThingWorx ノード間でトラフィックをルーティングします。 • InfluxDB Enterprise データノード間でトラフィックをルーティングします (使用されている場合)。 |
ZooKeeper | 最低 3 つ。奇数での割当を行う必要があります。 |
データベース | 上の図を参照してください。 |
ネットワーク/エンタープライズストレージ | すべての ThingWorx Foundation サーバー間で共有される ThingWorx ストレージリポジトリ用ディスク領域。 |