Procédure de mise à jour
Pendant la mise à jour d'un cluster TPE Haute Disponibilité (HA) :
- Les paquets Uplink des capteurs finaux seront mis en file d'attente par les passerelles pendant la mise à jour et envoyés aux serveurs d'application avec une latence plus élevée que d'habitude.
- Les API (y compris les downlinks de DX API) et les accès GUI ne sont pas disponibles pendant la procédure de mise à jour.
- Les sessions actives API et GUI sont fermées au début de la procédure, et les utilisateurs peuvent avoir à ré-entrer les informations de connexion dans GUI ou API après la mise à jour.
- Les Downlinks provenant des connecteurs cloud peuvent être perdus si les brokers cloud ne fournissent pas de capacités de mise en mémoire tampon (les clouds AWS/Azure prennent déjà en charge la mise en mémoire tampon des messages).
- La livraison des uplinks aux connecteurs cloud peut être retardée jusqu'à ce que le service soit démarré.
- Le module Terminal Cockpit NE DOIT PAS être utilisé pour effectuer des mises à jour en ligne de commande.
- Pour toute mise à jour de ThingPark Enterprise utilisant des médias locaux, veuillez vous assurer qu'aucun proxy HTTP n'est configuré pour l'accès au dépôt d'installation. Si ce n'est pas le cas, retirez d'abord le proxy HTTP dans la configuration TPE avant de commencer la procédure de mise à jour.
Chemins de mise à jour validés
Pour une mise à jour vers ThingPark Enterprise 8.0, les chemins suivants ont été validés :
- De TPE 7.3 à 8.0
La validation a été faite dans les deux modes : en utilisant le dépôt distant ou en utilisant des médias locaux.
Si vous souhaitez mettre à jour à partir d'une ancienne version du TPE, vous devez d'abord mettre à jour votre instance TPE vers la version 7.3, puis vers la version 8.0.
Durée de la mise à niveau du TPE et impact sur le traitement des paquets
Lors d’une mise à niveau du TPE, les services du chemin de données sont redémarrés plusieurs fois.
Les images ci-dessous montrent les différentes étapes principales de la procédure de mise à niveau du TPE et leur durée, y compris les périodes où les paquets UL pourraient être retardés et le traitement des paquets DL indisponible.
La durée minimale a été évaluée pour les options suivantes :
- Sur le segment S du TPE (l'utilisation d'un segment plus grand ralentit la procédure de mise à niveau).
- Utilisation du dépôt distant Actility avec une bande passante d'environ 60 Mo/s (l'utilisation d'un support local accélère la procédure de mise à niveau).
- Utilisation des passerelles avec la sécurité IPSec/TLS pour accéder à l'instance TPE (ne pas utiliser de cadre de sécurité accélère la procédure de mise à niveau et réduit le temps pendant lequel les paquets UL sont retardés).
- Le connecteur MQTT est utilisé pour connecter AS (l'utilisation de l'interface de tunneling HTTP générique réduit le temps pendant lequel les paquets UL sont retardés et le traitement des paquets DL est indisponible).
Mise à jour de TPE 7.3 ou supérieur à 8.0.x en mode autonome
(*) Pendant cette étape, les paquets peuvent être retardés jusqu'à 15 minutes.
En fonction des conditions de fonctionnement (par exemple, la bande passante réseau disponible pour télécharger les images, le nombre de capteurs et passerelles provisionnés...) La durée exprimée dans l'échéancier ci-dessus peut être augmentée d'un facteur de 2.
Mise à jour de TPE 7.3 à 8.0.x en mode HA
(*) Pendant cette étape, les paquets peuvent être retardés jusqu'à 15 minutes.
En fonction des conditions de fonctionnement (par exemple, la bande passante réseau disponible pour télécharger les images, le nombre de capteurs et passerelles provisionnés...) La durée exprimée ci-dessus peut être augmentée d'un facteur de 2.
Migration de DATA
La mise à jour de TPE de la version 7.3 à 8.0.x inclut une étape de migration de DATA obligatoire. Cette migration introduit un modèle de traitement des DATA plus évolutif. Pour plus de détails, consultez Compaction de la plateforme dans la note de version TPE 8.0.
L'étape de migration est requise et prend un temps non négligeable en fonction du nombre de capteurs hébergés.
Le tableau suivant fournit un temps d'exécution estimé pour la migration de DATA :
| Nombre de capteurs hébergés | Durée estimée pour la migration |
|---|---|
| < 1 000 | ~10 minutes |
| 2 000 | ~20 minutes |
| 5 000 | ~30 minutes |
| 10 000 | ~40 minutes |
| 20 000 | ~1 heure |
| 50 000 | ~3 heures |
| 100 000 | ~6 heures |
Note : Pour limiter la durée de mise à jour, seul l'historique des 7 derniers jours est conservé après la mise à jour à la version 8.0.
Note : Ces valeurs de temps sont indicatives et peuvent varier en fonction des performances du système et de la configuration matérielle.