Développement d’une technique robuste de transmission de données synchronisées en temps réel d’un Observatoire Magnétique vers un GIN INTERMAGNET

Étant donné que la disponibilité d’Internet au CPL est très limitée en raison de son emplacement éloigné d’une ville, nous avons approché une configuration de fibre optique permanente fiable de BSNL (Bharath Sanchar Nigam Limited) maintenue par le gouvernement. ou l’Inde. Mais il était trop coûteux à mettre en place et à entretenir, nous avons donc utilisé les installations d’un fournisseur de services local, avec une bande passante maximale de 20 Mbps pour lancer la technique de transfert de données.

Configuration initiale

Le transfert de données en ligne de CPL vers l’observatoire HYB a commencé à l’aide d’une transmission de données multiplateforme car les ressources du FAI (fournisseur d’accès Internet) n’étaient pas disponibles. Comme le fournisseur de services n’a pas pu résoudre quelques problèmes au niveau du réseau TCP/IP concernant la transmission de données d’une machine Linux à une autre machine Linux distante, nous avons dû procéder à un processus de transmission de données multiplateforme, car les données finales devaient être traitées sur des codes Matlab basés sur Windows.

Initialement, nous avons mis en place des scripts shell, des tâches cron et le protocole rsync pour transférer les données de l’enregistreur de données Magrec-4B vers une machine Linux intermédiaire (Centos) déployée au CPL. Les données ont été transférées de Magrec-4B vers la machine Linux (stockage de sauvegarde) à la salle de contrôle CPL avec une latence de 5 min, puis elles ont été transférées vers une machine Windows (client) à HYB Observatory en utilisant des codes, des scripts développés par nous et , des outils tiers (Fig. 2). La bande passante étant faible, nous avons décidé de transférer les données de la machine Linux vers le pc Windows chez HYB-NGRI avec un time-lapse de 1 min.

Figure 2

Système de transfert de données multiplateforme du PC Linux (déployé au CPL) au PC Windows (déployé au HYB) et pourcentage de transmission de données réussie entre les systèmes.

Nous avons installé un fichier batch avec l’option “Abort” et confirmé avec l’option “Off” pour vérifier la santé de la connexion côté client (PC Windows), réitéré pour un délai par défaut de 120 s. La session commence en vérifiant le nom d’utilisateur de l’ID d’hôte et le mot de passe pré-saisi authentifié avec la clé RSA (Rivest, Shamir et Adelman) via SFTP (Secured File Transfer Protocol). Les termes ‘Comparaison’ et ‘Synchronisation’ dans la figure montrent les détails de la transmission de données de l’hôte à la machine cliente à des intervalles conventionnels avec un intervalle de temps de 120 s.

À partir de Magrecc-4B, nous avons sélectionné 9 paramètres de données, comme indiqué sur la Fig. 2, pour transmettre des données en temps réel à la machine cliente. Les détails de la taille du fichier, de chaque paramètre de données et de la rapidité avec laquelle les données sont transmises de l’hôte à la machine cliente sont inclus. Les pourcentages de la colonne 5 de la fig. 2 montrent le processus de transmission et de mise à jour des données de la machine cliente. Le transfert de données à 100 % n’est atteint que lorsque les données sont copiées avec les derniers enregistrements de 120 s. De plus, la machine cliente revérifie les données en synchronisant les enregistrements antérieurs de la journée en cours. L’exemple du processus de transmission de données perpétuelles avec les derniers enregistrements et le processus de mise à jour est également illustré à la ligne 9 de la Fig. 2. Une fois les données synchronisées avec les derniers enregistrements (par exemple, le nom de fichier de la ligne 9 dans la Fig. 2), les 23 % de transmission de fichiers deviendront 100 % à la fin de cette tâche, en se synchronisant davantage avec les données enregistrées précédemment. La taille de fichier desdits neuf paramètres ci-dessus continue d’augmenter toutes les 120 s des données mises à jour sur la machine hôte. L’ensemble du processus est réitéré pour chaque cycle de 120 s jusqu’à ce que la journée soit terminée.

Comme une grande quantité de données des deux observatoires doit être transférée et nécessite un stockage dédié pour sauvegarder les données au quotidien, nous avons mis en place un serveur à l’observatoire HYB. Et aussi, chez CPL, les services de réseau Internet ont été récemment mis à niveau avec l’augmentation de la bande passante de 50 Mbps (qui est la bande passante maximale disponible à ce jour), ce qui nous a permis de configurer la technique de transmission de données robuste automatisée à GIN et les détails de ceux-ci sont discuté ci-dessous.

Configuration finale

Étant donné que notre objectif principal était d’obtenir une transmission automatisée des données en 1 minute des observatoires HYB et CPL vers GIN, nous avons dû faire des efforts de R&D supplémentaires pour développer une configuration robuste concernant à la fois le matériel (c’est-à-dire, poste de travail haut de gamme, configuration du routeur pare-feu) et le logiciel. Ainsi, le code Python, les scripts shell, les tâches cron et le protocole rsync ont été développés pour prendre en charge la transmission des données sans perte de données. Même en cas de déconnexion des services Internet, une fois les services Internet restaurés, le code Python revérifiera les données du dernier fichier transmis avec succès.

Le transfert de données de CPL et HYB vers le serveur central situé à l’observatoire HYB suit l’algorithme de clé RSH et SSH qui est en soi un algorithme très sécurisé. Nous avons conçu un système pour transférer les données dans un modèle sécurisé et crypté avec des clés SSH et enregistrer le même ensemble de données sur le serveur local du CSIR-NGRI. Nous avons utilisé l’algorithme RSA-SSH (Rivest–Shamir–Adleman), qui est un cryptosystème à clé publique largement utilisé pour une transmission sécurisée des données. La clé générée par le ssh-keygen dans la machine source (MAGREC-DAS) créera deux fichiers à savoir “id_rsa & id_rsa.pub dans le répertoire .ssh, qui est partagé/copié sur la machine de destination (Centos). Il existe donc une poignée de main parfaite entre la machine source et la machine de destination pour le transfert de données. Cette configuration reste la même sauf si le réseau reste le même, c’est pourquoi nous avons attribué une adresse IP statique. En plus des clés ssh, un code a été écrit pour transférer les données à l’aide de ‘l’outil rsync’ et la même chose a été inculquée dans le ‘crontab’ pour continuer à répéter le même avec un délai de 10 s. Désormais, la même technique a également été utilisée à l’observatoire HYB de la machine Centos au serveur pour une transmission de données sécurisée et réussie.

Après le succès des efforts de R & D de transmission de données des deux observatoires vers un serveur Linux haut de gamme dédié, avec une configuration RAID-5 de 24 To à l’observatoire HYB, nous avons créé des comptes d’utilisateurs individuels sur le serveur, c’est-à-dire IMO-CPL , IMO-HYB, pour stocker les données reçues des observatoires respectifs. Le code Python développé transférera plusieurs types de données du DAS et les stockera quotidiennement dans les comptes d’utilisateurs respectifs (Fig. 3). Les scripts développés à partir de chaque PC Linux filtreront les données en fonction des exigences du répertoire (c’est-à-dire, GIN). Les données triées du répertoire individuel seront transmises avec une période de latence de 300 s à INTERMAGNET GIN.

figure 3
figure 3

Transmission de données automatisée en 1 min depuis (un) CPL et (b) HYB Observatories à Edinburgh GIN en utilisant le code Python.

Après une transmission réussie des données des deux Observatoires au GIN, nous avons rencontré quelques problèmes mineurs, et la manière dont nous les avons résolus est discutée en détail :

Numéro-1 Initialement, le code Python a été exécuté à l’aide du « protocole de synchronisation rsync » avec une période de latence minimale de 60 s pour transférer les données en temps réel des deux observatoires. Comme l’ont rapporté les experts du GIN, avec cette période de latence, les mêmes données étaient envoyées à plusieurs reprises au service Web de réception (http://app.geomag.bgs.ac.uk/GINFileUpload/UploadForm.html), Fig. 4a, en raison de laquelle la mémoire de stockage/cache du GIN recevait d’énormes volumes de données des deux observatoires. Cela posait des problèmes à l’ensemble de leur service Web, les fichiers journaux se remplissant très rapidement et le cache des données du service Web était difficile à utiliser car il occupait un espace disque important (Fig. 4b).

Figure 4
chiffre 4

un) Détails de la mémoire cache des données pour les deux Observatoires sur le site INTERMAGNET BGS (b) message d’erreur indiquant “pas d’espace restant” en raison d’un énorme volume de données en double sur le serveur BGS.

La solution Pour résoudre le problème ci-dessus, nous avons créé des démons d’arrière-plan au lieu du “protocole de synchronisation rsync”, de sorte que la revérification des données toutes les 60 s a été remplacée par 300 s. Les démons du backend exécuteront le code Python toutes les 300 s pour une transmission fluide des données en temps réel sans aucune duplication (comme illustré à la Fig. 3).

Numéro-2 Après une transmission réussie des données des deux Observatoires, à quelques reprises, les services de traçage des données à l’INTERMAGENT n’ont pas été pris en compte même si notre matériel et nos logiciels étaient intacts. Nous avons recoupé les journaux de notre côté et constaté que les données ont été téléchargées avec succès sur GIN. Même si les enregistrements de données sont réussis, la raison pour laquelle les données n’ont pas été tracées sur le site Web d’INTERMAGNET était inconnue.

La solution Le problème ci-dessus a été résolu après que les experts BGS ont suggéré un lien (http://app.geomag.bgs.ac.uk/GINFileUpload/UploadForm.html) pour télécharger un fichier d’une journée pour vérifier s’il a réussi ou non ? Comme suggéré par BGS, si le téléchargement des données n’a pas réussi et avec quelques erreurs (Fig. 4), il y a un problème au niveau du serveur INTERMAGNET. Cette vérification nous a permis de constater que le code que nous exécutons fonctionne correctement (Fig. 5).

Figure 5
chiffre 5

Contre-vérification ou (un) CPL et (b) Journaux de données HYB du serveur HYB Observatory au serveur GIN.

Leave a Comment

Your email address will not be published.