Manuel du Système mondial de ... - E-Library - WMO

II-15/30
PROCéDURES D’EXPLOITATION DU SMT
Sessions FTP
Pour limiter la charge imposée aux systèmes émetteurs et récepteurs, il ne faudrait pas qu’il
y ait plusieurs sessions FTP à la fois par type de fichier. Si, par exemple, le centre A souhaite envoyer au
centre B deux fichiers du même type (mettons .ua), il ne doit pas envoyer le deuxième fichier avant que
la transmission du premier soit achevée. Les centres devraient limiter à cinq au maximum le nombre de
sessions simultanées avec un centre donné.
La temporisation de repos pour fermer la session FTP devrait être comprise entre l’heure de la
fin de l’accumulation de messages (maximum 60 secondes) et un délai maximal de 3 minutes.
Exigences locales concernant le protocole FTP
Tous les centres émetteurs doivent prévoir des commandes FTP “statiques” supplémentaires
dans les commandes FTP qu’ils émettent. Par exemple, certains centres utilisant le système MVS peuvent
avoir besoin de commandes “SITE” pour définir la longueur des enregistrements et des blocs. Les centres
devraient accepter les commandes FTP indiquées dans RFC959 à l’exception de celles qui sont exclues par
accord bilatéral. Il se peut qu’il soit également nécessaire de convenir de procédures et de commandes à
l’échelon bilatéral.
C’est aux centres récepteurs de supprimer les fichiers une fois qu’ils ont été traités.
Compression de fichiers
Il est souvent souhaitable de comprimer les fichiers volumineux avant de les envoyer.
Les centres ne doivent comprimer des fichiers que s’il existe un accord bilatéral à ce sujet.
Sauvegarde sur le SMT fondé sur IP
Une dernière considération est celle de la sauvegarde du SCM. Le nouveau SMT va utiliser
des adresses IP, où une adresse donnée n’est généralement associée qu’à un système. Si un système tombe
en panne et qu’une autre solution est employée, les centres émetteurs doivent considérer des questions de
mise en œuvre. Idéalement, un centre émetteur ne devrait pas être affecté par les dispositions de sauvegarde
d’un centre récepteur. Il s’agit là d’un bon principe, auquel tous les centres devraient s’efforcer d’adhérer.
Cependant, il n’est pas toujours possible d’obtenir une transparence IP complète. Si tel est le cas, les centres
émetteurs doivent être en mesure d’essayer une autre adresse IP. Après cela, ils doivent essayer périodiquement
la première adresse. Il est proposé d’établir cette périodicité par accord bilatéral entre centres, car elle sera
fortement influencée par la stratégie de sauvegarde de chaque centre.
5. Dépannage et solution de problèmes
Outils de couche IP
Dans un grand réseau IP, tous les routeurs qui acheminent des données entre deux serveurs
doivent connaître le prochain point à atteindre afin de gagner l’adresse de destination. Comme tout routeur
et/ou lien peut tomber en panne, il est très important de déterminer rapidement où se situe le problème et
comment le résoudre.
Voici quelques moyens de résoudre ce type de problème (les mesures proposées ne doivent pas
être forcément appliquées dans l’ordre indiqué):
a) Contrôler le fonctionnement du centre éloigné (si les dispositifs de sécurité de ce centre le permettent);
b) Vérifier si la liaison avec le réseau “extérieur” est accessible;
c) Contrôler le réseau local en essayant d’atteindre la passerelle la plus proche ou la passerelle par
défaut;
d) Vérifier l’ensemble des procédures locales liées au protocole IP et leur configuration.
On trouvera ci-dessous une description de quelques outils de base qui peuvent être utilisés tels
que PING, TRACEROUTE et NETSTAT. PING et TRACEROUTE fournissent des informations sur les trajets de
transmission entre serveurs. Ils utilisent tous les deux le protocole ICMP (traceroute a également besoin du
protocole UDP) mais il convient de noter que de nombreux sites bloquent les paquets ICMP dans le cadre
de leurs mesures de sécurité pare-feu. Pour pouvoir localiser les problèmes qui se posent sur un réseau, il est
nécessaire d’avoir une documentation précise sur ce dernier.
Édition 2009