ハードウェアのサイジングの選択
ThingWorx Foundation ノードおよび必要なデータベースでの推奨サイズを確認してください。図の下にクラウドプロバイダオプションとストレージ速度に関する推奨事項を記載しています。
* 
推奨サイズは Azure Linux (Ubuntu 18.04 LTS) Fsv2 仮想マシン上で実行されたテストに基づいて割り出されています。すべてのデータベースインスタンスで Premium SSD が使用されています。その他のクラウドプロバイダ、物理ハードウェア、オペレーティングシステムの組み合わせによって結果が異なる場合があります。
サイズ
ThingWorx Foundation (各ノード)
リレーショナル DB
(SQL Server または PostgreSQL)
リレーショナル DB
(Azure PostgreSQL フレキシブル)
時系列 DB データノード
(InfluxDB)
小規模 (RDBMS のみ)
8 vCPU
16 GiB RAM
8 vCPU
16 GiB RAM
16 vCPU
64 GiB RAM
1 TB
小規模 + (InfluxDB 使用**)
8 vCPU
16 GiB RAM
4 vCPU
8 GiB RAM
4 vCPU
8 GiB RAM
中規模 (RDBMS のみ)
16vCPU
32 GiB RAM
16vCPU
32 GiB RAM
16 vCPU
64 GiB RAM
1 TB
中規模 + (InfluxDB 使用**)
16vCPU
32 GiB RAM
8 vCPU
16 GiB RAM
8 vCPU
16 GiB RAM
大規模 (RDBMS のみ)
32vCPU
64 GiB RAM
32vCPU
64 GiB RAM
32vCPU
128 GiB RAM
8 TB
大規模 + (InfluxDB 使用**)
32vCPU
64 GiB RAM
16 vCPU
32 GiB RAM
16 vCPU
32 GiB RAM
大規模 (HA) + Azure Flex HA
48 vCPU
192 GiB RAM
8 TB
備考: Sizing Guide の推奨サイズは、ThingWorx の実装をサイジングするときの初期ベースラインとして使用するためのものです。個々の結果は Edge のコンフィギュレーションやアプリケーションの負荷などによって異なります。
** ThingWorx ではオープンソースの単一ノードバージョンの InfluxDB を使用することも、InfluxDB Enterprise クラスタを使用して高可用性を実現し、パフォーマンスを向上させることもできます。これらのサイジングテストでは InfluxDB オープンソースバージョンが使用されています。InfluxDB Enterprise のサイシングでは、示されている 2 つの InfluxDB "データ" ノードに加え、3 つの "メタ" ノードを計画し、通常はそれぞれに 1-2 vCPU と 0.5-1GiB RAM を割り当てます。InfluxDB のサイジングの詳細については、https://docs.influxdata.com/influxdb/v1.8/guides/hardware_sizing/ を参照してください。
* 
Azure PostgreSQL フレキシブルサーバーは、同様の値ストリームキューレートを実現するために、オンプレミスデータベースよりも多くの計算能力とストレージを必要とします。最大 IOPS や IOPS 帯域幅などのコンポーネントは、計算能力とストレージサイズに依存します。
Microsoft Azure
Azure ではユースケースに合わせてさまざまなインスタンスタイプが用意されています。PTC はほとんどのユースケースにおいて、コンピューティングに最適化されたハイパースレッドタイプのインスタンス (主に Fsv2 シリーズ) を推奨しています。
デプロイするアプリケーションの要件によっては、汎用 Dsv3 シリーズなどのその他のインスタンスタイプを検討してもよいでしょう。
F クラス (コンピューティング最適化) VM は、高速でデータが取得される一方、ビジネスロジックやイベント処理は複雑でない場合に適しています。
D クラス (汎用) VM は、多数のデバイスの状態をメモリ内に維持することを優先する ThingWorx アプリケーションに適しています。
CPU クロック速度は各自のユースケースに応じて検討する必要があります。Fsv2 は Dsv3 よりも CPU クロック速度が若干速いので、高速で大量のイベント処理が必要なワークロードでは著しい効果がもたらされる可能性があります。
Azure では CPU コアの観点から VM を選択するためのパッケージ化された手法が提供されています。一般的なサイズ表記としては F2s_v2、F4s_v2、F8s_v2 などがあり、数値は VM の CPU コアの数を表しています。
上記のオンプレミスのサイズ表記の例に従えば、PostgreSQL データベースを使用した小規模 ThingWorx Platform は F8s_v2 VM で実行可能ですが、アプリケーションで必要とされる ThingWorx Foundation ノード当りのメモリフットプリントが大きい場合、要件に応じて D8s_v3 をデプロイすることもできます。
Microsoft は VM サービスを定期的に調整および改善しています。Azure VM の詳細については、Azure の Web サイト https://azure.microsoft.com/en-us/pricing/details/virtual-machines/series/ を参照してください。
従来のオンプレミスのサイズ表記
従来のオンプレミスのハードウェアサイズは、処理能力については CPU コアの数、メモリ容量については RAM で表されます。たとえば、PostgreSQL データベースを使用する小規模 ThingWorx Platform は、8 CPU コアおよび 16 GB RAM で実行可能です。
アプリケーション構成に単一障害点が存在しないようにするために、データベースに独自のサーバーを用意することをお勧めします。
Amazon Web Services (AWS) のサイズ表記
AWS では、EC2 インスタンスにさまざまなインスタンスタイプが用意されています。PTC はコンピューティング最適化シリーズを推奨しており、その最新が C5d シリーズです。AWS のサイトによれば、これらのインスタンスタイプは "コンピューティング集約型ワークロードのために最適化され、費用対効果の高いハイパフォーマンスを低額のコンピューティング比率あたりの料金で提供します" としています。
AWS では CPU とメモリの観点から EC2 インスタンスのサイズを選択するために T シャツと同じサイズ表記が用いられています。一般的なサイズ表記には large、xlarge、2xlarge などがあります。
上記のオンプレミスのサイズ表記の例に従えば、PostgreSQL データベースを使用した小規模 ThingWorx Platform は C5d.2xlarge EC2 インスタンスで実行可能です。アプリケーションの負荷への対応に必要な CPU とメモリの比率に基づいて、汎用型 (M) やメモリ集約型 (R) などその他の EC2 インスタンスタイプを検討することもできますが、このガイドでは説明していません。
Amazon EC2 インスタンスタイプの詳細については、AWS の Web サイト https://aws.amazon.com/ec2/instance-types/ を参照してください。
高速ストレージ
一般的に、データ取得、処理、ビジュアリゼーションを同時に実行するために ThingWorx では高速ストレージを使用することをお勧めします。
低速ストレージを選択した場合、ThingWorx と使用されるデータベースの両方において、診断が困難なパフォーマンスとスケールの問題が発生することがあります。これらの問題によって、システムバックアップ、オペレーティングシステム、データベースレベルのデータの断片化、同じストレージデバイスやコントローラでクリーンアップアクティビティが実行されるなど、予期しない外部の影響が生じることもあります。
推奨されるクラウドベンダーごとにソリッドステートディスク (SSD) のオプションが存在し、プラットフォームとデータベース実装の両方で利用可能な場合には必ず検討する必要があります。
変更やアクセスの頻度が低いデータの場合には特に、高速ハードディスクドライブ (HDD) のオプションも検討できます。
その他の詳細については、ThingWorx システムの要件を確認してください。
これは役に立ちましたか?