Nouvelles fonctionnalités spécifiques à ThingPark Enterprise SaaS

Processus de mise à niveau du réseau central en mode canari RDTP-8958

Avant la version 7.0 : lorsque la plateforme est mise à niveau d'une version n à une version n+1, les deux network servers (également connus sous le nom de serveur LRC dans l'architecture ThingPark) dans le cluster réseau central haute disponibilité doivent être mis à niveau vers la version n+1 en même temps.

À partir de la version 7.0 :

• Lorsqu'une plateforme est mise à niveau d'une version n à une version n+1, seul LRC2 (nœud de sauvegarde) est mis à jour vers la version n+1, LRC1 (nœud maître) reste sur la version n.

• Une proportion du trafic des capteurs est dirigée vers LRC2. Ce rapport est contrôlé par l'administrateur de la plateforme, en définissant un facteur modulo à appliquer sur DevAddr et DevEUI : par exemple, modulo 2 transférerait statistiquement la moitié du trafic LoRaWAN® vers la version n+1, modulo 4 transférerait 25 %, etc...

• L'objectif est de transférer progressivement le trafic LoRaWAN® vers la version n+1 et de surveiller les indicateurs clés de performance (ICP) et la stabilité du système en conséquence, avant de procéder finalement à la mise à jour complète du cluster LRC vers la version n+1.

• En cas de dégradation des performances/stabilité pendant la mise à niveau partielle, LRC2 (nœud de sauvegarde) doit être immédiatement rétabli à la version n.

note

Le redirectionnement du trafic de LRC1 (nœud maître, exécutant la version n) vers LRC2 (nœud de secours, exécutant la version n+1) est géré du côté LRC sans impact sur le LRR. En d'autres termes, LRC1 transfère le trafic LoRaWAN® des capteurs canaries à LRC2, sans que LRR ne soit impliqué dans la décision d'orientation du trafic et quel que soit le nœud LRC auquel chaque LRR est connecté.

Plus de détails

Dans les diagrammes de flux illustratifs ci-dessous, la passerelle (LRR) est connectée à LRC1 (nœud maître) et le ratio de trafic contribuant au canary est réglé à 10% par l’administrateur de la plateforme (modulo 10) :

Par conséquent, pour un capteur donné, le traitement canari peut ne pas être symétrique ; par exemple, la procédure canari peut s'appliquer au traitement UL/DL d'un capteur donné, mais pas à la Join-Request pour ce même capteur.

Principaux avantages pour les clients

Grâce à cette fonctionnalité, les clients ThingPark et les administrateurs de plateforme disposent de mécanismes efficaces pour mettre à niveau en toute sécurité le cluster de cœur de réseau tout en minimisant tout risque de dégradation des performances sur le chemin des données. Avec la mise à niveau partielle du cluster LRC, exploitant l'architecture haute disponibilité avant-gardiste de ThingPark, tout impact négatif sur la production réseau est fortement atténué. Des actions correctives sont rapidement prises pour annuler la mise à niveau du réseau de base si nécessaire.

Activation de la fonctionnalité

Cette fonctionnalité est désactivée par défaut, l'activation reste sous la responsabilité de l'équipe NetOps d'Actility.

Comme condition préalable, la version initiale (n) doit déjà supporter le mode canary, donc n ne peut pas être inférieure à la version 7.0.

Le processus global consiste à activer le mode canari pour une période définie ; ensuite, surveiller la stabilité du réseau avant de décider de l'étape suivante : Soit poursuivre avec la mise à niveau complète du cluster LRC (dénommée procédure "Commit") soit revenir à la version précédente de LRC2 (n) en cas de dégradation des performances avec la version n+1.

note

Bien que le ratio de capteurs contribuant au mode canari soit contrôlé par l'administrateur de la plateforme (en supposant une répartition statistiquement homogène des plages DevEUI/DevAddr dans le périmètre de l'opérateur), l'ensemble réel de capteurs contribuant au mode canari est censé être aléatoire pour fournir une évaluation impartiale / statistiquement pertinente de la stabilité du système en version n+1.

Limitations de la fonctionnalité

Aucune.

Connexion sécurisée utilisant l'authentification à deux facteurs

À partir de la version 7.0, tous les utilisateurs doivent utiliser l'authentification à deux facteurs pour se connecter à ThingPark Enterprise SaaS.

Plus de détails

L'authentification à deux facteurs est basée sur un code à usage unique généré par une application mobile, en plus du mot de passe de l'utilisateur.

Avantages clés pour les clients

Désireux d'offrir une sécurité de pointe aux utilisateurs de ThingPark, l'authentification multifactorielle atténue le risque d'accès non autorisé aux comptes utilisateurs, par exemple en raison de mots de passe compromis.

Activation de la fonctionnalité

Pour configurer l'authentification à deux facteurs pour chaque utilisateur, lors de sa première connexion après la mise à niveau vers la version 7.0, il doit configurer un code à usage unique comme dans l'exemple suivant :

1. Les utilisateurs doivent installer l'une des applications mobiles suivantes pour configurer un cadre d'authentification mobile. Les deux applications sont disponibles pour les smartphones Android (téléchargeables depuis Google Play Store) et iOS (disponibles sur l'App Store) :

   • FreeOTP

   • Google Authenticator

2. Ensuite, l'utilisateur devra scanner le code QR affiché sur la page de connexion TPE.

3. L'utilisateur doit ensuite entrer le code à usage unique généré par l'application sur la page de connexion TPE.

4. La prochaine fois que l'utilisateur se connectera à TPE, il/elle sera invité(e) à entrer un code à usage unique pour valider sa connexion, en utilisant la même application liée à son compte à l'étape 1 ci-dessus.

   

Dans le cas où l'utilisateur ne peut pas générer le code à usage unique, il/elle peut le réinitialiser via le processus de récupération de mot de passe (mot de passe oublié).

Limitations de la fonctionnalité

L'authentification à deux facteurs ne peut pas être activée/désactivée de manière sélective pour chaque abonnement TPE : il s'agit d'une configuration globale applicable à tous les abonnements TPE de chaque plateforme SaaS.

Mise à niveau du logiciel d'infrastructure RDTP-4764

Les composants suivants de l'infrastructure ThingPark Enterprise SaaS sont mis à niveau dans la version 7.0. Le composant marqué d'un * peut être mis à niveau avant la mise à niveau du logiciel TPW 7.0, afin de réduire la durée de la mise à niveau TPE SaaS 7.0.

• Kafka*: mise à niveau de v1.0 à v2.4,

• MariaDB*: mise à niveau de 10.0.20 à 10.4.13,

• MongoDB*: mise à niveau de 3.4 à 4.2,

• Système d'exploitation Linux : passage de CentOS 6.x à CentOS 8.3.

  Remarque Actility passe à la distribution AlmaLinux à partir de la version 7.1 de TPE.

Plus de détails

Principaux avantages pour les clients

Aucune.

Activation de la fonctionnalité

Non applicable.

Limitations de la fonctionnalité

Aucune.