Procédure de mise à niveau de ThingPark Enterprise

prudence

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 de l'API et des interfaces graphiques sont fermées au début de la procédure, et l'utilisateur devra peut-être rentrer à nouveau ses informations de connexion dans l'interface graphique ou l'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é.

Matrice des composants de la version ThingPark Enterprise

Comme expliqué dans l'aperçu de l'installation, une version de ThingPark Enterprise se compose de 4 Helm Charts. La mise à niveau doit être effectuée en respectant la version spécifiée dans le Manifest de version

Prérequis

Vous devez examiner les prérequis de la version ThingPark Enterprise avant de commencer la mise à jour.

Préparation du déploiement

La première étape consiste à mettre à jour les paramètres et les informations du référentiel Helm :

1. Récupérez les fichiers de valeurs Helm utilisés pour personnaliser la configuration des déploiements précédents.
2. Utilisez la procédure de configuration pour récupérer le dernier exemple de configuration. Mettez-les à jour avec votre personnalisation et les valeurs des paramètres selon les options de déploiement choisies.

Configuration des référentiels

Configurez le référentiel helm en utilisant InstallationID

helm repo add --username <InstallationID> --password <InstallationID> actility https://repository.thingpark.com/charts
helm repo update

Mises à niveau majeures

prudence

La mise à niveau majeure doit être effectuée à partir de la dernière version de correction précédente

7.3 à 8.0

• Suivez la procédure de mise à niveau 8.0

Mises à niveau des versions de correction et d'entretien

• Les versions de correction 8.0 doivent être installées avec la procédure générique.

Vérifications post-mise à niveau

Attendre la disponibilité de tous les statefulsets et déploiements :

kubectl get -n $NAMESPACE statefulsets.apps,deployments.apps
kubectl get -n $NAMESPACE -w statefulsets.apps
kubectl get -n $NAMESPACE -w deployments.apps

Les procédures post-mise à niveau sont automatiquement déclenchées pour demander des migrations de données après une mise à niveau de l'instance TPE.

Le statut de la procédure post-mise à niveau peut être vérifié à l'aide de l'API Kubernetes :

$ kubectl exec -n $NAMESPACE -it deploy/pum -- /nodejs/bin/node app.js display
2 entrie(s)
uid: 2
     creationTimestamp: '2022-06-23T13:50:33.000Z'
     scope: 'ALL'
     serviceID: 'TWA'
     requestID: 'RDTP-7689-bs-certificate-migration'
     requestPath: '/thingpark/wireless/rest/systems/demons/migrateBsSecurity'
     requestBody: '{ "max" : 10 }'
     state: 'PROCESSED'
     stateTimestamp: '2022-06-27T14:05:11.000Z'
     lastResponse: '{"status":200,"message":"OK","data":{"countOnly":false,"max":10,"result":{"done":6,"remaining":0}}}'
     errorCounter: 0
     iterationCounter: 5
uid: 4
     creationTimestamp: '2022-06-23T13:50:33.000Z'
     scope: 'TPE-OCP'
     serviceID: 'TWA'
     requestID: 'RDTP-18480-alarm-email-notification-migration-for-tpe-ocp'
     requestPath: '/thingpark/wireless/rest/systems/demons/migrateUserAlarmNotifications'
     requestBody: '{ "max" : 100 }'
     state: 'PARTIALLY_PROCESSED'
     stateTimestamp: '2022-06-27T14:14:11.000Z'
     lastResponse: '{"status":250,"message":"Unknown","data":{"operatorID":null,"max":100,"countOnly":false,"result":{"done":0,"remaining":2}}}'
     errorCounter: 0
     iterationCounter: 2

Le script affiche la liste des requêtes post-mise à niveau et pour chaque requête, les détails de la requête, y compris l'état du traitement. Les différents états de traitement d'une demande post-mise à niveau peuvent être :

• INIT: la demande post-mise à niveau a été ajoutée et doit être traitée.
• IN_PROGRESS: un POST HTTP est en cours pour cette demande.
• PARTIALLY_PROCESSED: d'autres itérations sont nécessaires pour compléter la demande post-mise à niveau.
• TRANSIENT_ERROR: le dernier HTTP POST a échoué et doit être réessayé.
• ABORTED: le gestionnaire de post-mise à niveau n'a pas pu compléter la demande post-mise à niveau.
• PROCESSED: la demande post-mise à niveau est entièrement terminée.
• SKIPPED: la demande de post-mise à niveau n'a jamais été appliquée sur ce système (car la procédure a été marquée DÉPRÉCIÉE ou car la portée ne s'applique pas à ce PF).

Les logs de la procédure de mise à niveau peuvent être récupérés sur le stdout de la tâche :

kubectl logs -n $NAMESPACE  jobs.batch/pum-process

Enfin, si pour une raison quelconque vous souhaitez exécuter à nouveau la procédure post-mise à niveau, par exemple, si elle a échoué, vous pouvez le faire de cette manière :

kubectl exec -n $NAMESPACE -it deploy/pum -- restart

astuce

Pour annuler la mise à niveau pour n'importe quelle raison, rendez-vous dans la section de procédure d'annulation