Dimensionnement du matériel
Basez-vous sur les recommandations pour les noeuds ThingWorx Foundation et la ou les bases de données souhaitées. Les options de fournisseur de Cloud possibles et les recommandations en matière de vitesse de stockage sont fournies à la suite de la table.
 |
Les recommandations ont été formulées sur la base de tests effectués sur des machines virtuelles Azure Linux Fsv2 (Ubuntu 18.04 LTS). Des disques SSD Premium ont été utilisés pour toutes les instances de base de données. Les résultats pourront différer avec d'autres fournisseurs de Cloud, un matériel physique différent ou d'autres systèmes d'exploitation.
|
|
Taille
|
ThingWorx Foundation (chaque noeud)
|
BD relationnelle
(SQL Server ou PostgreSQL)
|
Noeud(s) de données BD temporelle
(InfluxDB)
|
|---|---|---|---|
|
Très petite taille H2*
(BD H2 en mémoire)
|
4 vCPU
8 Gio de RAM
|
||
|
Petite taille H2*
(BD H2 en mémoire)
|
8 vCPU
16 Gio de RAM
|
||
|
Petite taille(SGBDR uniquement)
|
8 vCPU
16 Gio de RAM
|
8 vCPU
16 Gio de RAM
|
|
|
Petite taille +(avec InfluxDB**)
|
8 vCPU
16 Gio de RAM
|
4 vCPU
8 Gio de RAM
|
4 vCPU
8 Gio de RAM
|
|
Taille intermédiaire(SGBDR uniquement)
|
16 vCPU
32 Gio de RAM
|
16 vCPU
32 Gio de RAM
|
|
|
Taille intermédiaire +(avec InfluxDB**)
|
16 vCPU
32 Gio de RAM
|
8 vCPU
16 Gio de RAM
|
8 vCPU
16 Gio de RAM
|
|
Grande taille(SGBDR uniquement)
|
32 vCPU
64 Gio de RAM
|
32 vCPU
64 Gio de RAM
|
|
|
Grande taille +(avec InfluxDB**)
|
32 vCPU
64 Gio de RAM
|
16 vCPU
32 Gio de RAM
|
16 vCPU
32 Gio de RAM
|
|
Rappel : les recommandations du guide de dimensionnement sont destinées à servir de base initiale pour le dimensionnement des implémentations ThingWorx. Les résultats réels peuvent varier en fonction de la configuration Edge, de la charge de l'application, etc.
|
|||
|
* La base de données H2 en mémoire n'est pas prise en charge pour les implémentations de production.
** ThingWorx peut être utilisé avec la version open source sur serveur unique d'InfluxDB ou avec un cluster InfluxDB Enterprise pour une haute disponibilité et des performances accrues. La version open source d'InfluxDB est celle qui a été utilisée pour ces tests de dimensionnement. Pour le dimensionnement sur InfluxDB Enterprise, planifiez deux noeuds de "données" InfluxDB comme indiqué, plus trois noeuds "méta", avec typiquement 1 à 2 vCPU et 0,5 à 1Gio de RAM chacun. Pour plus d'informations sur le dimensionnement d'InfluxDB, consultez la page https://docs.influxdata.com/influxdb/v1.8/guides/hardware_sizing/.
|
|||
Microsoft Azure
Azure fournit un certain nombre de types d'instance couvrant de nombreux cas d'utilisation. PTC recommande des instances optimisées en capacité de calcul et hyper-threadées pour la plupart des cas d'utilisation, et en particulier la série Fsv2.
Microsoft décrit les instances de la série Azure Fsv2 comme des machines virtuelles qui "prennent en charge 2 Gio de RAM et 8 Go de stockage temporaire local (SSD) par processeur virtuel" et qui "sont optimisées pour les charges de travail nécessitant beaucoup de ressources système".
D'autres types d'instance, tels que les VM à usage général de la série Dsv3 peuvent également être envisagées en fonction des exigences de l'application déployée :
• Les VM de la série F (optimisées en capacité de calcul) sont souvent les mieux adaptées pour l'ingestion de données à haut débit avec une logique applicative ou un traitement des événements moins complexes.
• Les VM de la série D (à usage général) conviennent souvent bien pour les applications ThingWorx qui priorisent la prise en charge d'une grande quantité d'appareils dont les états doivent être conservés en mémoire.
La vitesse d'horloge du CPU doit être prise en compte dans votre cas d'utilisation. Les VM Fsv2 présentent des vitesses d'horloge CPU légèrement plus élevées que celles de la série Dsv3, ce qui peut avoir un impact sensible pour les charges de travail qui impliquent le traitement rapide de grandes quantités d'événements.
La dénomination de chaque modèle de VM Azure utilise un chiffre qui indique sa taille en termes de nombre de coeurs CPU. Ces dénominations sont de la forme "F2s_v2", "F4s_v2", "F8s_v2", etc., où le premier chiffre indique le nombre de coeurs CPU de la VM.
En suivant la logique de ces dénominations, un système ThingWorx Platform de petite taille utilisant une base de données H2 pourra être dimensionné pour s'exécuter sur une VM F8s_v2, mais selon vos exigences, vous pourrez choisir de déployer une D8s_v3 si votre application nécessite une empreinte mémoire plus importante par noeud ThingWorx Foundation.
Microsoft ajuste et améliore par ailleurs régulièrement ses offres de VM. Pour plus d'informations sur les caractéristiques des VM Azure, consultez le site Web d'Azure : https://azure.microsoft.com/en-us/pricing/details/virtual-machines/series/.
Terminologie métier traditionnelle
Les tailles de matériel sont traditionnellement décrites en termes de nombre de coeurs CPU pour la puissance de traitement et de quantité de RAM pour la capacité mémoire. Par exemple, un petit système ThingWorx Platform utilisant une base de données H2 pourra être dimensionné à 8 coeurs CPU et 16 Go de RAM.
Il est recommandé de doter la base de données de son propre serveur afin d'éviter tout point de défaillance unique dans la configuration de l'application.
Terminologie Amazon Web Services (AWS)
Pour les instances EC2, AWS propose une sélection de types d'instance. PTC recommande des instances optimisées en capacité de calcul, les dernières en date étant celles de la série C5d. AWS indique que ces instances "sont optimisées pour les charges de travail qui nécessitent une importante capacité de calcul" et qu'elles "offrent des performances élevées très rentables pour un rapport prix/calcul avantageux".
La dénomination du modèle d'instance EC2 utilise un code qui indique sa taille en termes de nombre de coeurs CPU et de capacité mémoire. Ces codes de taille sont de la forme "large", "xlarge", "2xlarge", etc.
En suivant la logique de ces dénominations, un système ThingWorx Platform de petite taille utilisant une base de données H2 pourra être dimensionné pour s'exécuter sur une instance EC2 C5d.2xlarge. Des instances EC2 d'autres types, à usage général (M) ou optimisées en capacité mémoire (R), peuvent également être envisagées en fonction des ratios CPU/mémoire nécessaires pour la charge de votre application, mais celles-ci ne sont pas couvertes dans ce guide.
Pour plus d'informations sur les caractéristiques des types d'instance Amazon EC2, consultez le site Web d'AWS : https://aws.amazon.com/ec2/instance-types/.
Stockage à haut débit
En général, PTC recommande l'utilisation d'un stockage à haut débit pour ThingWorx pour la prise en charge simultanée de l'ingestion, du traitement et de la visualisation des données.
Les options de stockage plus lentes peuvent entraîner des problèmes de performances et d'évolutivité difficiles à diagnostiquer pour ThingWorx et les bases de données sur lesquelles il repose. Ces problèmes peuvent également avoir des effets externes inattendus, tels que des sauvegardes système, des fragmentations de données au niveau du système d'exploitation ou de la base de données, ou encore des activités de nettoyage exécutées sur le même périphérique de stockage ou contrôleur.
Des options de disques SSD sont disponibles pour chacun des fournisseurs de Cloud recommandés, qu'il convient d'envisager dans la mesure du possible tant pour la plateforme que pour les implémentations de base de données.
Des options de disques SSD à grande vitesse peuvent également être pertinentes, notamment pour les données qui seront modifiées ou qui seront consultées moins fréquemment.
Pour plus d'informations, reportez-vous au détail de la Configuration requise pour ThingWorx.