Exigences en matière de stabilité du réseau et d’intégrité des données pour les déploiements cloud de Tulip

Présentation

Une connexion réseau stable et de haute qualité est nécessaire pour les déploiements de Tulip Cloud afin de garantir les performances en temps réel et l’intégrité des données. Cet article définit les exigences réseau quantifiables — bande passante, latence, gigue et perte de paquets — auxquelles un déploiement Tulip doit satisfaire, explique les risques techniques liés à l’instabilité du réseau (notamment la perte de données dans la file d’attente des déclencheurs et les défaillances de conformité ALCOA), et fournit des recommandations aux niveaux physique, logique et applicatif pour atténuer ces risques.

La stabilité prime sur la vitesse brute : une connexion instable présentant une forte gigue ou des pertes de paquets intermittentes peut entraîner une perte de données silencieuse et permanente, même sur des liaisons à haut débit. Pour répondre aux exigences décrites dans cet article, une approche en deux volets est nécessaire : une infrastructure informatique et réseau robuste, associée à une architecture d’application résiliente, fonctionnant de concert.

Pour obtenir la liste des domaines et adresses IP spécifiques à ajouter à la liste blanche de votre instance Tulip Cloud, consultez les exigences réseau pour le déploiement de Tulip Cloud.

À qui s’adresse cet article ?

Cet article s’adresse principalement aux utilisateurs avancés de Tulip qui déploient la solution dans des environnements à grande échelle. Si vous venez de déployer Tulip au sein de votre organisation ou si vous êtes actuellement en période d’essai, ces informations sont probablement plus avancées que vos besoins actuels.

Utilisez les liens à droite pour accéder au contenu correspondant au sujet souhaité.

Résumé

Ce document présente les exigences réseau essentielles pour garantir les performances, la stabilité et l’intégrité des données d’un déploiement Tulip Cloud.

Points clés

La stabilité prime sur la vitesse: une connexion filaire stable de 15 Mbps est largement supérieure à une connexion instable de plus de 100 Mbps présentant une forte gigue ou des pertes de paquets.

L'instabilité du réseau entraîne des pertes de données: les connexions intermittentes, la latence élevée ou la perte de paquets ne se traduisent pas seulement par une « lenteur ». Elles provoquent l'engorgement de la file d'attente de déclenchement et la perte d'événements, ce qui conduit à des pertes de données irréversibles et à des défaillances critiques de l'intégrité des données (ALCOA).

Pour y remédier, une solution en deux volets est nécessaire: une infrastructure informatique robuste (répondant aux exigences ci-dessous) et une architecture d’application résiliente (par exemple, le découplage de la logique grâce aux automatisations) sont toutes deux indispensables.

Politiques relatives aux infrastructures critiques

Utilisation par défaut de l’Ethernet filaire: tous les Tulip Players fixes doivent utiliser une connexion Ethernet filaire blindée.

Configurer et surveiller les proxys et les pare-feu: tous les domaines Tulip figurant dans la liste blanche doivent être configurés pour le passage de SSL/TLS (voir Liste blanche). L’inspection approfondie des paquets (DPI) doit être réduite au minimum, et les performances des pare-feu et des proxys doivent faire l’objet d’une surveillance proactive.

Liste de contrôle de l'état de préparation du réseau par poste

Pour chaque poste équipé d’un Tulip Player, vérifiez :* [ ] Type de connexion: les Tulip Players fixes utilisent une connexion Ethernet filaire blindée (STP, Cat6a ou supérieure).* [ ] Bande passante: au moins 15 Mbps disponibles en débit descendant et montant ; jamais moins de 10 Mbps par poste actif ou que le minimum calculé (voir Exigences réseau quantifiables)* [ ] Latence: la latence aller-retour (RTT) moyenne vers your-instance.tulip.co est inférieure à 80 ms; la RTT maximale est inférieure à 100 ms*[ ] Gigue: La gigue ($RTT_{max}-RTT_{avg}$) est inférieure à 10 ms (et toujours inférieure à 30 ms)* [ ] Perte de paquets: la perte de paquets mesurée est de 0 % en fonctionnement normal, et inférieure à 0,1 % lors des tests en conditions extrêmes.* [ ] Disponibilité: le chemin entre le lecteur et Tulip Cloud ne repose pas sur des liaisons instables (Wi-Fi ad hoc, réseaux invités, VPN présentant de fréquentes coupures, etc.)* [ ] Proxys / pare-feu: Tous les domaines Tulip figurant dans la liste blanche sont configurés pour le passage SSL/TLS sans interception SSL, réécriture de protocole, altération ou mise en cache, et de préférence sans DPI.* [ ] WebSockets: les proxys et pare-feu autorisent les connexions WebSocket de longue durée sur le port 443 sans problèmes de délai d’inactivité ou de réinitialisation de connexion.
[ ] Activité des processus*: les appareils (en particulier les mobiles) sont configurés pour* éviter une mise en veille agressive des processus en arrière-plan*, l’optimisation de la batterie ou les politiques du système d’exploitation qui suspendent le Tulip Player, ou qui limitent les requêtes réseau, les connexions TCP ou les connexions WebSocket pendant leur utilisation.* [ ]* Applications résilientes*: les applications critiques sur cette station respectent les* modèlesd’architecture d’applications résilientes*(réduire au minimum le taux d’événements et les appels API dans les chemins de déclenchement critiques pendant le workflow de l’opérateur, donner la priorité aux Tulip Tables et limiter au maximum les connecteurs à exécution longue).

Risques d’instabilité et intégrité des données

Cette section explique pourquoi une connexion stable est essentielle et quels sont les risques techniques qui affectent les performances et l’intégrité des données.

Au-delà du simple retard de transmission des messages, une connectivité intermittente ou la perte de paquets peuvent entraîner deux problèmes principaux : 1. Perte d’événements et perte de données : lorsquele réseau est instable ou hors ligne, les actions de l’opérateur (telles que les pressions sur des boutons, les entrées provenant d’appareils ou la lecture de codes-barres) continuent de générer des événements. Ces événements s’accumulent dans une file d’attente. Cette file d’attente ayant une capacité limitée (100 événements par défaut), si cette limite est dépassée pendant l’attente du rétablissement du réseau, tous les nouveaux événements entrants sont ignorés et définitivement perdus. 2. Surcharge du système et ralentissement dû au « rattrapage » : lorsquela connectivité est rétablie après une interruption, l’ensemble des événements en attente (jusqu’à 100) tentera de s’exécuter en succession rapide. Cela peut entraîner une charge soudaine et massive sur la plateforme Tulip et sur tout système tiers connecté (via Connector Functions). C’est particulièrement le cas lorsque plusieurs stations se reconnectent simultanément en raison d’un problème de connectivité réseau partagé. Ce flux de « rattrapage » peut être à l’origine d’un ralentissement et d’une surcharge importants, et peut également entraîner une limitation de l’API (erreurs HTTP 429) ainsi que d’autres défaillances.

Comment les problèmes réseau entraînent une perte de données dans la file d’attente des déclencheurs

Pour comprendre ce risque, il est essentiel de savoir comment s’exécutent les déclencheurs. Voir la section « Déclencheurs » pour plus de détails.* File d’attente à thread unique: le moteur d’exécution des déclencheurs de Tulip fonctionne sur une file d’attente séquentielle à thread unique. Chaque événement de déclenchement (par exemple, « bouton enfoncé ») est ajouté à cette file d’attente et doit mener à bien toutes ses actions avant que l’événement suivant dans la file d’attente ne puisse même commencer.* « Engorgement » du réseau: une panne de réseau ou une instabilité grave provoque le blocage des actions au sein d’un déclencheur (comme « Créer un enregistrement de table » ou « Exécuter Connector Function ») ou les fait entrer dans un état de réessai prolongé. Par exemple, à partir de la version LTS15, une action de table ayant échoué sera réessayée pendant un maximum de 2 minutes.* Le goulot d’étranglement: ce déclencheur unique et lent bloque l’ensemble de la file d’attente. Tant qu’elle est bloquée, les actions suivantes de l’opérateur (par exemple, 99 autres pressions sur le bouton) viennent remplir la file d’attente.* Événements ignorés: une fois la limite de la file d’attente atteinte (100 événements par défaut), tous les événements supplémentaires sont annulés et ignorés. Cela signifie que si un opérateur scanne un 101e article pendant la panne de réseau, cet événement est perdu à jamais et ne sera pas traité lorsque le réseau sera rétabli.

Même lorsque la file d’attente n’est pas pleine, l’instabilité générale du réseau peut entraîner l’échec d’ Connector Functions s individuelles (appels API). Ces actions ne font pas l’objet d’une nouvelle tentative (contrairement aux actions sur les tables dans LTS15) et peuvent entraîner des pertes de données silencieuses et des problèmes d’intégrité.

Facteurs de risque de perte de données

Le risque de perte de données en cas de mauvaise connectivité réseau n’est pas uniforme. Il est considérablement accru par les architectures d’applications « riches en événements ». Découvrez ici les bonnes pratiques pour ces applications.

Vous courez un risque bien plus élevé si vos applications présentent les caractéristiques suivantes :* Un taux d’événements élevé: applications générant de nombreux événements en peu de temps. Cela inclut la lecture rapide de codes-barres, les saisies fréquentes sur les appareils ou les déclencheurs de minuterie s’activant à intervalles courts (par exemple, toutes les 30 secondes).* Des déclencheurs complexes: des déclencheurs qui exécutent de nombreuses actions séquentielles, en particulier des appels API multiples (Connector Functions) ou des écritures dans des tables. Chaque action dépendante du réseau augmente le temps de « blocage » potentiel en cas de panne.* Recours à l’ Connector Functions: utilisation de l’ Connector Functions pour la saisie de données critiques. Une Connector Function qui échoue en raison d’un incident réseau ne sera pas réessayée et entraînera l’échec du déclencheur, ce qui peut interrompre le processus ou entraîner une perte de données. Utilisez des automatisations (et/ou des fonctions) dans la mesure du possible.

Conformité ALCOA pour les sciences de la vie

Pour les clients du secteur des sciences de la vie et d’autres environnements réglementés par les normes GxP, ces risques liés au réseau ne constituent pas seulement des problèmes de performances ; ils représentent des menaces directes pour l’intégrité des données et la conformité.

Les risques techniques décrits ci-dessus correspondent directement aux principes ALCOA :* Inexact et incomplet: lorsque la limite de la file d’attente des déclencheurs est atteinte pendant une panne, tous les événements suivants sont définitivement perdus. Si un opérateur scanne un 101e élément, cet événement est perdu à jamais. Le dossier de lot qui en résulte est fondamentalement inexact et incomplet.* Non contemporain: Lorsque la connectivité est rétablie, le « rattrapage » exécute en masse les événements en attente, souvent plusieurs minutes après que l’opérateur a effectué l’action. Un auditeur examinant un ensemble d’horodatages manifestement décalés par rapport au processus réel remettrait en cause l’intégrité de la contemporanéité de l’enregistrement.* Inexact (entre les systèmes): Connector Functions (appels API) ne disposent pas de mécanismes de réessai intégrés. Une brève interruption du réseau peut entraîner qu’un déclencheur écrive correctement dans une table Tulip (l’enregistrement d’origine), mais échoue à mettre à jour un MES ou un QMS externe. Il en résulte un état des données inexact et désynchronisé entre vos systèmes validés.

Il est essentiel de suivre les recommandations architecturales présentées dans la section suivante pour mettre en place un processus robuste et validable, capable de prévenir les défaillances en matière d’intégrité des données.

Exigences réseau quantifiables

Pour éviter les blocages de la file d’attente des déclencheurs, les événements perdus et les défaillances d’intégrité des données évoqués précédemment, chaque station Tulip Player doit maintenir une connexion persistante de haute qualité. Les quatre dimensions suivantes définissent cette exigence.

Bande passante (débit)

Il s’agit de la « taille » de la connexion, qui permet d’éviter la saturation. Bien que les charges utiles des données d’application soient souvent faibles, une bande passante insuffisante entraîne une latence et une perte de paquets, ce qui bloque à son tour la file d’attente des déclencheurs.

• Recommandation : 15 Mbps par station active.
• Minimum absolu : 10 Mbps par station active, ou la bande passante requise calculée, la valeur la plus élevée étant retenue.
• Limite quantifiable : la bande passante minimale doit dépasser le débit de données de base (BDR) de l’application, multiplié par un facteur de marge ($H$) d’au moins 2,0 (100 %) afin de tenir compte de la surcharge du réseau et des retransmissions.
  • $R_{peak}$ = Taux d’événements de pointe (événements par seconde)
  • $S_{event}$ = charge utile moyenne par événement (octets, incluant toutes les données envoyées et reçues par le déclencheur)
  • $H$ = facteur de marge (sans dimension), pour lequel une valeur de $H > 2,0$ est recommandée

Commencez par calculer le débit de données de base (BDR) en bits par seconde :* $BDR (bps) = R_{peak} \times S_{event} \times 8$

Calculez ensuite la bande passante requise: * $Bande passante requise (bps) = BDR \times H = R_{peak} \times S_{event} \times 8 \times H$

En pratique, si cette valeur calculée est inférieure à 10 Mbps, vous devriez tout de même prévoir au moins 10 Mbps par station active (et de préférence 15 Mbps) afin d’assurer la pérennité du système, de disposer d’une marge suffisante et de tenir compte des autres types de trafic sur la même liaison.

Exemple

Si le taux d’événements de pointe dans le pire des cas de votre application est de $R_{peak}=2\text{ événements}/s$ et que chaque événement envoie et reçoit environ $S_{event}=5 000\ \text{ octets}$, alors :* $BDR = 2 \times 5 000 \times 8 = 80 000 bps$* $Bande passante requise (H = 2,0) = 160 000 bps = 0,16 Mbps$

Même si le besoin calculé est faible, nous prévoyons tout de même au moins 10 à 15 Mbps par station.

Latence (temps aller-retour)

Il s’agit du délai mis par un paquet pour aller jusqu’au serveur et revenir. Une latence élevée augmente directement le temps d’exécution de chaque action déclenchée dépendante du réseau (comme une écriture dans une table ou une connector function), rendant l’ensemble de la file d’attente vulnérable au blocage.

• Recommandation : < 80 ms
• Limite maximale absolue : 100 ms (vers votre domaine [instance].tulip.co).
• Limite quantifiable : la latence détermine directement la durée des actions dépendantes du réseau au sein d’un déclencheur. Pour éviter l’engorgement de la file d’attente des déclencheurs, le temps total d’exécution des déclencheurs lié aux actions réseau doit être nettement inférieur au temps entre les événements.

Soit :* $R_{peak}$ = taux de pointe des événements (événements par seconde)* $T_{between}$ = intervalle entre les événements (secondes).* $N_{net}$ = nombre d’actions réseau séquentielles dans le déclencheur (par exemple, écritures dans une table, appels de connecteur)* $RTT_{avg}$ = latence aller-retour moyenne (en secondes)

L'intervalle entre les événements est :* $T_{between}=\frac{1}{R_{peak}}$

Une approximation simple du temps de déclenchement dû à la latence réseau est :* $T_{trigger,net}=N_{net}\times RTT_{avg}$

Pour maintenir une file d’attente saine, il faut que le temps de déclenchement lié au réseau soit nettement inférieur à l’intervalle entre les événements.Une règle empirique pratique est la suivante :* $N_{net}\times RTT_{avg}\leq 0,25\times T_{between}$* $N_{net}\times RTT_{avg}\leq \frac{0,25}{R_{peak}}$

En d’autres termes : la somme de tous les allers-retours réseau consécutifs dans un déclenchement doit être inférieure à un quart du temps prévu entre les événements de l’opérateur en charge de pointe. Si cette condition n’est pas remplie, la file d’attente s’allongera progressivement et finira par atteindre la limite de 100 événements. Pour obtenir les performances les plus fiables, veillez à respecter la condition suivante : $N_{net}\times RTT_{avg}\lt \lt \frac{0,1}{R_{peak}}$

Gigue (variation de latence)

Il s’agit de la variation de la latence. Une connexion à forte gigue est instable ; un pic de latence soudain sur un seul paquet peut bloquer un déclencheur tout aussi efficacement qu’une latence moyenne élevée, bloquant ainsi la file d’attente et entraînant des blocages « aléatoires » et des événements perdus.

• Limite quantifiable : la gigue correspond à la variation de la latence dans le temps. Un seul pic de latence peut bloquer un déclencheur tout aussi efficacement qu’une latence élevée constante.

Soit :* $RTT_{avg}$ = latence aller-retour moyenne sur une fenêtre d’échantillonnage (en secondes)* $RTT_{max}$ = latence aller-retour maximale observée sur la même fenêtre (en secondes)

Nous définissons :* $Jitter = RTT_{max} - RTT_{avg}$

Cette valeur doit être maintenue à un niveau bas pour garantir des performances prévisibles des déclencheurs. Pour les déploiements Tulip :* Recommandation : $Jitter$ < 10 ms * Maximum absolu : $Jitter$ < 30 ms

Si la gigue mesurée approche ou dépasse 30 ms, les opérateurs constateront des blocages « aléatoires » et les déclencheurs risquent de rester en état d’exécution suffisamment longtemps pour bloquer la file d’attente.

Fiabilité (perte de paquets et disponibilité)

Il s’agit de l’aspect le plus critique pour l’intégrité des données. La perte de paquets entraîne des retransmissions, ce qui peut bloquer un déclencheur pendant plusieurs secondes, provoquant ainsi de graves engorgements de la file d’attente. Les déconnexions (pannes de disponibilité) sont catastrophiques : elles entraînent un remplissage complet de la file d’attente (100 événements) et la perte définitive de toutes les données suivantes, ce qui garantit des enregistrements incomplets.

• Recommandation : 0 % de perte de paquets et disponibilité constante.
• Limite maximale absolue : < 0,1 % de perte de paquets.
• **Limite quantifiable :**la file d’attente des déclencheurs ne peut contenir qu’un nombre limité d’événements. Lorsque le réseau est hors service, les actions de l’opérateur continuent de générer des événements jusqu’à ce que la file d’attente soit pleine. Une fois que la file d’attente atteint sa limite, tous les événements suivants sont rejetés et définitivement perdus.

Soit :* $Q_{max}$ = taille maximale de la file d’attente (événements). Actuellement, $Q_{max}=100$ par défaut.* $R_{peak}$ = débit maximal d’événements pendant une panne (événements par seconde).

La durée maximale tolérable de la panne avant que les événements ne commencent à être rejetés est :* $T_{outage,max}=\frac{Q_{max}}{R_{peak}}$

Exemple: pour une application présentant un taux d’événements élevé de $R_{peak}=2$ événements/seconde (par exemple, des valeurs de couple en évolution rapide) :* $T_{outage,max}=\frac{100}{2}=50$ secondes

Dans cet exemple, toute interruption réseau continue de plus de 50 secondes entraînera une perte de données : tous les événements au-delà des 100 premiers seront ignorés et ne seront jamais traités, même après le rétablissement du réseau.

Cette relation simple est cruciale pour l’évaluation des risques : les applications à taux d’événements élevé ne tolèrent que des interruptions très courtes avant que l’intégrité des données ne soit compromise.

Recommandations relatives à l’infrastructure physique

Le respect des exigences réseau quantifiables ne dépend pas uniquement de votre FAI ; il dépend fortement de l’infrastructure réseau physique interne de vos locaux.

Recommandation par défaut : Ethernet filaire

Pour atteindre les niveaux de stabilité, de fiabilité et de faible latence définis dans la section précédente, une connexion Ethernet filaire est la recommandation forte et par défaut pour toutes les stations Tulip Player fixes.

Cependant, il ne s’agit pas d’une solution « à configurer une fois pour toutes ». La couche physique est un point de défaillance courant et souvent négligé qui peut entraîner une perte de paquets intermittente et difficile à diagnostiquer.

• Intégrité physique des câbles : les équipes informatiques et d’exploitation doivent gérer cette infrastructure de manière proactive. Inspectez régulièrement les câbles pour détecter d’éventuels défauts, effilochages ou connexions desserrées. Une source courante de défaillance est un chariot roulant à plusieurs reprises sur un câble non blindé ou mal acheminé.
• Interférences électromagnétiques (EMI) : dans un atelier de production, les machines à fortes vibrations, les moteurs ou les équipements haute tension peuvent provoquer des interférences importantes. Utilisez des câbles Ethernet blindés (par exemple, STP, Cat6a ou supérieur) dans ces environnements pour éviter la dégradation du signal.

Considérations relatives au Wi-Fi et aux appareils mobiles

Nous sommes conscients que de nombreux clients utilisent des appareils mobiles (tablettes, téléphones) ou des chariots mobiles lorsque la connexion filaire n’est pas envisageable. Dans ces cas de figure, une connexion Wi-Fi stable est une condition préalable à l’intégrité des données.

• Conception du réseau : vous devez vous assurer de disposer d’un réseau sans fil robuste et conçu par des professionnels. L’objectif est d’obtenir une couverture homogène, sans zones d’ombre (qui provoquent des déconnexions) et avec un chevauchement minimal entre les points d’accès (PA). Un chevauchement excessif peut amener un appareil à « errer » d’un point d’accès à l’autre, forçant une renégociation DHCP et provoquant un blocage du réseau qui interrompt la file d’attente de déclenchement.
• Interférences : le Wi-Fi est également très sensible aux interférences électromagnétiques (EMI) provenant des machines. La conception de votre réseau doit en tenir compte.
• Risque accru : une connexion sans fil étant par nature moins stable qu’une connexion filaire, il est d’autant plus crucial que les applications sur ces appareils respectent les recommandations de l’architecture d’application résiliente (comme le découplage de la logique) afin de se prémunir contre les inévitables perturbations du réseau.
• Les systèmes d’exploitation mobiles peuvent suspendre ou limiter de manière agressive les applications en arrière-plan afin d’économiser la batterie. Tulip Player doit être exempté de ces politiques lorsqu’il est utilisé (le mode kiosque/application verrouillée est préférable).

Liste de contrôle de l’infrastructure physique

Postes câblés

• [ ] Type de câble: tous les Tulip Players fixes utilisent un câble Ethernet blindé (STP, Cat6a ou supérieur) dans les zones à fortes interférences électromagnétiques (moteurs, variateurs, posteuses, etc.).
• [ ] Acheminement des câbles: aucun câble ne passe à un endroit où des chariots, des chariots élévateurs ou des chaises risquent de rouler dessus régulièrement ; les câbles sont acheminés dans des chemins de câbles, des gaines ou en hauteur lorsque cela est possible.
• [ ] État des câbles: un calendrier d’inspection documenté (par exemple, trimestriel) est en place pour vérifier l’absence d’effilochage, de pliures, de gaines écrasées et de connexions desserrées.
• [ ] Raccordements: tous les connecteurs et panneaux de brassage sont correctement raccordés et protégés contre les tractions ; aucun câble de raccordement « temporaire » n’est utilisé comme câblage permanent.
• [ ] Ports de commutateurs: les ports des terminaux sont verrouillés sur la vitesse et le mode duplex appropriés, et ne partagent pas de liaisons montantes surchargées qui atteignent régulièrement leur saturation.
• [ ] Alimentation / PoE: en cas d’utilisation du PoE, le budget de puissance du commutateur n’est pas surchargé ; les baisses de tension ou les réinitialisations sont surveillées et déclenchent des alarmes.
• [ ] Surveillance: la surveillance de base des commutateurs (CPU, mémoire, erreurs d’interface et utilisation) est activée et vérifiée périodiquement.

Wi-Fi et appareils mobiles

• [ ] Conception professionnelle: le réseau sans fil a été conçu (ou au moins étudié) par des professionnels pour la zone de production où les appareils Tulip sont utilisés.
• [ ] Couverture: l’intensité du signal mesurée tout au long du parcours complet de l’opérateur (le « parcours à pied ») montre une couverture continue, sans zones mortes provoquant des déconnexions ou des « chutes libres » lors de l’itinérance.
• [ ] Chevauchement des points d’accès: les points d’accès sont placés de manière à minimiser tout chevauchement excessif ; les clients ne « cherchent » pas d’autre point d’accès lorsqu’ils sont à l’arrêt.
• [ ] Comportement en itinérance: les seuils d’itinérance et le « band steering » sont réglés de manière à ce que les appareils changent de point d’accès en douceur, sans renégociations DHCP répétées ni brèves coupures.
• [ ] Interférences: les sources connues d’interférences électromagnétiques (machines, posteuses, gros moteurs, liaisons micro-ondes, etc.) ont été prises en compte dans la planification des canaux.
• [ ] Segmentation: les appareils Tulip sont sur un SSID/VLAN dédié aux systèmes de production, sans être mélangés au Wi-Fi invité ou aux appareils grand public à fort taux de rotation.
• [ ] Backhaul: les points d’accès disposent de liaisons montantes fiables et non encombrées ; le Wi-Fi géré par un contrôleur ou dans le cloud ne fonctionne pas à pleine capacité.
• [ ] Applications résilientes: les applications exécutées sur des appareils Wi-Fi ou mobiles respectent plus strictement l’architecture des applications résilientes afin de tenir compte du risque intrinsèquement plus élevé lié à la connectivité sans fil.

Test

Parcourez un itinéraire avec un « Player » exécutant networkCheck et vos propres outils de diagnostic, et assurez-vous qu’il n’y a pas de déconnexions ni de pics dépassant le seuil pendant 10 minutes.

Infrastructure logique et de sécurité (proxys, pare-feu et DPI)

Au-delà des câbles physiques, votre infrastructure logique de sécurité réseau est la source la plus courante de latence « mystérieuse », de gigue et d’échecs de connexion.

• Les proxys et les pare-feu comme goulots d’étranglement: les appliances de sécurité (pare-feu, proxys, CASB, etc.) qui effectuent une inspection approfondie des paquets (DPI) ou un déchiffrement SSL/TLS sur l’ensemble du trafic constituent une source majeure d’instabilité. Ce processus d’inspection ajoute en lui-même une latence (gigue) importante et variable à chaque requête réseau, ce qui peut facilement enfreindre les exigences de latence < 100 ms et de gigue < 30 ms.
• Surveiller l’état de santé des appareils: les équipes réseau doivent surveiller l’utilisation du processeur et de la mémoire de ces appareils. Un pare-feu ou un proxy surchargé rejettera des paquets ou introduira de la latence, créant ainsi l’instabilité même qui conduit à la perte de données.
• Ne pas interférer avec le trafic Tulip: la communication client-cloud de Tulip repose sur des protocoles Web spécifiques, notamment les WebSockets sécurisés, pour le transfert de données en temps réel. Certaines solutions de sécurité tentent d’intercepter, de réécrire ou d’« interférer » avec ce trafic HTTPS. Cette interception peut rompre la connexion WebSocket ou classer à tort des appels API standard comme des requêtes inter-origines (CORS), entraînant leur échec.
• Exigence: tous les domaines Tulip (répertoriés dans la section « Liste blanche » ) doivent être configurés pour le passage de SSL/TLS. Le trafic doit être contourné par tout système d’analyse DPI, d’inspection de protocole ou de mise en cache.

Liste de contrôle

• [ ] Domaines Tulip contournés: tous les domaines Tulip répertoriés dans la liste blanche sont configurés pour le passage SSL/TLS et sont exclus du décryptage / de l’interception SSL.
• [ ] Privilégier l’absence de DPI et de réécriture de protocole: l’inspection approfondie des paquets (DPI), la réécriture du protocole HTTP et la mise en cache de contenu sont désactivées pour le trafic Tulip, en particulier pour les WebSockets.
• [ ] Prise en charge des WebSockets: les pare-feu et les proxys autorisent les connexions WebSocket de longue durée sur le port 443 sans délai d’inactivité court ni réinitialisation forcée.
• [ ] Surveillance de la capacité: l’utilisation du processeur, de la mémoire et le débit sur les appliances de sécurité sont surveillés ; des alertes sont mises en place en cas d’utilisation élevée et prolongée susceptible d’entraîner une latence ou une perte de paquets.
• [ ] Règles de sortie: les règles de sortie autorisent explicitement les plages d’adresses IP et les noms d’hôtes Tulip (par identifiant de « garden »), y compris les points de terminaison de stockage des ressources (S3/Blob).
• [ ] Comportement « fail-open »: dans la mesure du possible, le trafic Tulip est configuré pour adopter un comportement « fail-open » (ou avec des erreurs claires et consignées), plutôt que de rejeter les paquets en silence.
• [ ] Contrôle des modifications: toute modification de la configuration du pare-feu ou du proxy susceptible d’affecter Tulip est suivie et, dans l’idéal, testée par rapport à https://your-account.tulip.co/networkCheck pendant les fenêtres de modification.

Architecture d’application résiliente

Cette section explique comment les développeurs peuvent atténuer les risques liés à l’infrastructure.

Les développeurs doivent concevoir des applications résilientes face aux problèmes réseau intermittents. Il est essentiel de prévoir une marge de manœuvre pour la latence réseau et les légères dégradations de la plateforme. Utilisez des automatisations (et/ou des fonctions lorsque cela est possible).

• Donnez la priorité aux écritures dans les tables Tulip : pour toute capture de données critiques, utilisez d’abord les actions natives « Create Record » ou « Store » de Tulip Table dans votre déclencheur. Ces actions sont plus résilientes face aux perturbations réseau et intègrent une logique de réessai (jusqu’à 2 minutes dans LTS15).
• Réduisez au minimum le taux d’événements : réexaminez la conception de votre application. Si un opérateur est raisonnablement susceptible de générer 100 événements (par exemple, des scans) pendant une interruption de réseau de 2 minutes, votre architecture présente un risque élevé. Envisagez de regrouper les entrées par lots ou de simplifier le flux de travail.
• Suivez les bonnes pratiques en matière de performances : respectez les recommandations documentées ici concernant les applications hautes performances. Surcharger la plateforme avec des appels à haute fréquence crée une latence interne qui imite un réseau de mauvaise qualité.

Voir aussi : Déclencheurs d’applications basés sur les événements via la machine « virtuelle » Tulip

Liste de contrôle

• [ ] Les tables d’abord: toutes les données critiques capturées (analyses, décisions des opérateurs, mesures) sont d’abord enregistrées dans une table Tulip.
• [ ] Pas d’appels API longs dans les déclencheurs destinés aux opérateurs: les déclencheurs destinés aux opérateurs ne contiennent pas d’ Connector Functions s de longue durée ni de logique API externe complexe.
• [ ] Modèle de découplage: les automatisations sont privilégiées pour effectuer des appels d’API externes dans la mesure du possible.
• [ ] Champs d’état : les tables de traitement utilisent des champs d’état clairs (en attente, en cours de traitement, traité, erreur) afin que les échecs puissent faire l’objet d’une nouvelle tentative ou d’une analyse.
• [ ] Fréquence d’événements contrôlée: la conception de l’application ne permet pas aux opérateurs de générer des fréquences d’événements soutenues qui rempliraient la file d’attente lors de brèves interruptions de service (voir le calcul des interruptions ci-dessus).
• [ ] Minuteries et boucles: les déclencheurs de minuterie et les boucles ne se déclenchent pas à des intervalles inutilement courts (par exemple, toutes les 1 à 5 secondes), sauf si cela est absolument nécessaire et validé.
• [ ] Gestion des erreurs des connecteurs: les connecteurs « Connector Functions » susceptibles de rencontrer des défaillances dues à des problèmes réseau disposent de mécanismes de gestion des erreurs et de réessai (de préférence via des automatisations, et non via des déclencheurs opérateur).
• [ ] Bonnes pratiques en matière de performances: les applications respectent les bonnes pratiques de Tulip pour les applications hautement performantes.

Configuration technique et dépannage

Si votre réseau ne répond pas aux exigences quantifiables décrites ci-dessus, ou si vous rencontrez des problèmes de performances que vous soupçonnez d’être liés au réseau, veuillez suivre les étapes décrites dans notre guide détaillé. Ce guide fournit un organigramme hiérarchisé pour diagnostiquer et résoudre les problèmes de performances réseau, depuis les vérifications de base jusqu’à l’analyse avancée au niveau des paquets.

Consultez ici le guide complet de dépannage réseau.

Utilitaire de test du réseau et des WebSockets

Tulip utilise largement les WebSockets, un type de connexion persistante, pour permettre des mises à jour en temps réel. Ces WebSockets utilisent le chiffrement SSL sur le port 443. Certains proxys ne prennent pas en charge ces connexions, et certains outils de surveillance réseau peuvent nécessiter une autorisation explicite pour ces connexions. Veuillez consulter la section ci-dessus pour vérifier la compatibilité.

Un utilitaire simple est disponible pour vous aider à tester la latence de votre connexion réseau et la compatibilité avec les WebSockets :

• https://your-account.tulip.co/networkCheckOR
• https://your-account.dmgmori-tulip.com/networkCheckOR
• https://your-account.tulip-serendie.com/networkCheck

Liste de contrôle pour la mise en service et la surveillance continue

• [ ] Test initial: pour chaque nouvelle station, lancez https://your-account.tulip.co/networkCheck (ou l’URL DMG MORI / Serendie) ainsi que vos propres diagnostics pendant au moins 10 à 15 minutes sous une charge de production normale.
• [ ] Enregistrement des métriques: enregistrez la latence moyenne, minimale et maximale, la gigue et toute perte de paquets observée ; vérifiez qu’elles respectent les seuils indiqués dans cet article.
• [ ] Test en période de charge maximale: répétez le test pendant une période de charge maximale connue sur le réseau de l’usine (changement d’équipe, traitement de lots volumineux) afin de garantir la stabilité en situation de contrainte.
• [ ] Tests de régression après des modifications: relancez le test après toute modification significative de la configuration du réseau, du Wi-Fi, du pare-feu ou du proxy affectant Tulip.
• [ ] Archivage de référence: archivez les résultats des tests (captures d’écran ou exportations) dans le cadre de vos dossiers de validation / mise en service.
• [ ] Revérification périodique: planifiez des retests périodiques (par exemple, tous les trimestres) pour les stations critiques ou lors du déploiement de nouvelles applications présentant des taux d’événements plus élevés.

Avez-vous trouvé ce que vous cherchiez ?

Vous pouvez également vous rendre sur community.tulip.co pour poser votre question ou voir si d’autres utilisateurs ont rencontré un problème similaire !