Dimensionnement du matériel
Planification de la capacité
Avant de sélectionner les ressources d'hébergement, sélectionnez un segment de dimensionnement ThingPark Enterprise pour votre déploiement (S jusqu'à XXL).
Utilisez le tableau suivant pour déterminer le nombre de passerelles et de capteurs, et le débit de trafic uplink/downlink LoRaWAN®.
| _ | Petit (S) | Moyen (M) | Grand (L) | Très Grand (XL) | Double Très Grand (XXL) |
|---|---|---|---|---|---|
| Passerelles | Jusqu'à 10 | Jusqu'à 100 | Jusqu'à 200 | Jusqu'à 500 | Jusqu'à 1000 |
| Capteurs | Jusqu'à 2 000 | Jusqu'à 20 000 | Jusqu'à 50 000 | Jusqu'à 100 000 | Jusqu'à 300 000 |
| Taux moyen de trafic (uplink + downlink) | 1 message/sec | 6 msg/sec | 15 msg/sec | 30 msg/sec | 90 msg/sec |
| Taux de trafic de pointe (1) | 3 msg/sec | 18 messages/sec | 37,5 messages/sec | 60 msg/sec | 135 messages/sec |
(1) La charge de pointe (paquets uplink et downlink par seconde) ne peut pas être maintenue plus d'une minute.
Exigences de calcul
Les exigences de calcul sont exprimées en CPU Cœurs allouables et RAM GiB allouables sur les nœuds de travail Kubernetes. Les ressources de calcul doivent être équitablement distribuées entre 3 zones de disponibilité. Nous fournissons également la demande atomique (pod) CPU et RAM la plus importante qui devrait être allouable sur chaque zone :
| _ | Petit (S) | Moyen (M) | Grand (L) | Très Grand (XL) | Double Très Grand (XXL) |
|---|---|---|---|---|---|
| CPU (cœurs) | À l'étude | 8 | 12 | 15 | À l'étude |
| RAM (GiB) | À l'étude | 28 | 34 | 62 | À l'étude |
| Plus grandes demandes de pod | - 150m CPU / 1316Mi RAM - 350m CPU / 216Mi RAM | - 400m CPU / 2295Mi RAM - 500m CPU / 245Mi RAM | - 600m CPU / 6210Mi RAM - 700m CPU / 356Mi RAM |
Il est recommandé de définir des demandes/limites de ressources RAM pour toutes les charges de travail sur le cluster Kubernetes. Plusieurs charges de travail ThingPark utilisent une mémoire cache récupérable, cette mesure évitera la récupération d'inactive_file (c'est-à-dire le nombre d'octets de mémoire appuyée par fichier sur la liste LRU inactive) dans les situations de pression sur la mémoire du nœud.
Une écriture en cache trop agressive peut causer des problèmes de performance.
Stockage
Aucun approvisionnement en ressources n'est nécessaire, Thingpark Enterprise utilise un approvisionnement dynamique en volume.
| Service | Petit (S) | Moyen (M) | Grand (L) | Extra Grand (XL) | Double ExtraGrand (XXL) |
|---|---|---|---|---|---|
| mariadb-galera | 3 x 5Gi (1)(3) | 3 x 5Gi (1)(3) | 3 x 10Gi (1)(3) | 3 x 15Gi (1)(3) | 3 x 30Gi (1)(3) |
| mongodb | 2 x 5Gi (1)(3) | 2 x 10Gi (1)(3) | 2 x 15Gi (1)(3) | 2 x 20Gi (1)(3) | 2 x 30Gi (1)(3) |
| kafka | 2 x 10Gi (1)(3) | 2 x 15Gi (1)(3) | 2 x 20Gi (1)(3) | 2 x 30Gi (1)(3) | 2 x 40Gi (1)(3) |
| lrc | 2 x 5Gi (1)(3) | 2 x 5Gi (1)(3) | 2 x 5Gi (1)(3) | 2 x 10Gi (1)(3) | 2 x 15Gi (1)(3) |
| zookeeper | 6 x 5Gi (1)(3) | 6 x 5Gi (1)(3) | 6 x 5Gi(1)(3) | 6 x 5Gi (1)(3) | 6 x 5Gi (1)(3) |
| lrc-ftp | 2 x 10Gi (2)(3) | 2 x 10Gi (2)(3) | 2 x 10Gi (2)(3) | 2 x 10Gi (2)(3) | 2 x 10Gi (2)(3) |
(1) Volumes Azure SSD Premium LRS approvisionnés
(2) Volumes Azure SSD Standard LRS approvisionnés
(3) Volumes AWS gp3 approvisionnés