Dessiner les échanges utiles à votre application
Pour chaque flux, notez son point de départ, sa destination et la personne qui en a besoin. Ajoutez le protocole retenu, le sens d’ouverture de la connexion, la fréquence et le volume attendu. Un import initial, une connexion d’administration et un service appelé en continu ne se préparent pas avec les mêmes critères. Une destination inconnue reste un point à résoudre, plutôt qu’une autorisation générale à ouvrir.
Cette liste aide votre équipe à décider ce qui doit être accessible et ce qui peut rester fermé. Elle précise aussi qui valide une modification. Les caractéristiques de connectivité ne se déduisent pas du modèle GPU : débit, adresses, ports et modalités d’accès doivent être relevés pour l’environnement effectivement mis à disposition. La matrice ci-dessous représente un projet fictif, pas des services annoncés comme inclus.
| Flux | Critère à préciser | Responsable |
|---|---|---|
| Poste d’administration vers environnement | Protocole, destination et accès autorisé | Responsable des accès |
| Dépôt de données vers travail GPU | Volume initial, fréquence, reprise | Propriétaire des données |
| Application vers dépendance externe | Destination, méthode d’authentification, délai acceptable | Responsable applicatif |
| Résultats vers destination de conservation | Volume final et contrôle de réception | Responsable des livrables |
Mesurer le transfert qui compte pour votre planning
Prenez un échantillon représentatif, avec un nombre et une taille de fichiers proches du travail prévu. Une archive unique et des milliers de petits fichiers sollicitent différemment la procédure. Mesurez import et export séparément, vers les destinations réellement retenues. Conservez le volume utile, le temps écoulé, l’outil, les paramètres et les conditions du test pour pouvoir comparer un second passage.
Un outil tel qu’iperf3 mesure un flux réseau entre un client et un serveur de test. Sa documentation distingue notamment le sens normal et le sens inverse. Un tel essai nécessite deux extrémités autorisées ; il ne prouve pas à lui seul la vitesse d’une copie de fichiers, qui dépend aussi du stockage, du traitement et du protocole. Commencez par le transfert applicatif dont votre calendrier dépend réellement.
Transformer une mesure en fenêtre de transfert
Exemple entièrement fictif : 600 Go doivent être exportés. Ici, 1 Go vaut 1 000 Mo et les débits sont exprimés en Mo par seconde. À 120 Mo/s utiles, la division 600 000 ÷ 120 donne 5 000 secondes, soit 1 h 23 min 20 s. Avec une hypothèse plus prudente de 70 Mo/s, elle donne environ 8 571 secondes, soit 2 h 22 min 51 s. Aucun de ces débits ne décrit une offre Capordia.
Si l’équipe ajoute 45 minutes pour finaliser le paquet et contrôler sa réception, la seconde hypothèse occupe environ 3 h 08. Elle peut retenir un créneau de 3 h 10, puis ajouter séparément la réserve qu’elle juge nécessaire. Cette fenêtre reste conditionnelle : un changement du volume, du nombre de fichiers ou des conditions de transfert exige de refaire le calcul. Ne remplacez pas cette estimation par le débit théorique d’une interface.
| Hypothèse | Durée du transfert seul | Avec 45 minutes de préparation et contrôle |
|---|---|---|
| 120 Mo/s utiles | 1 h 23 min 20 s | 2 h 08 min 20 s |
| 70 Mo/s utiles | Environ 2 h 22 min 51 s | Environ 3 h 07 min 51 s |
Préparer l’accès et la reprise sans ouvrir davantage que nécessaire
Validez d’abord la destination et l’identité de l’hôte avec les informations attendues, puis les autorisations et le chemin de travail. Un refus d’accès ne se résout pas en partageant le mot de passe du compte de commande dans un document collectif. Les accès à l’environnement et la connexion au compte Capordia ont des fonctions distinctes ; consignez leurs responsables sans copier leurs secrets.
Si votre procédure retient OpenSSH SFTP, les transferts passent par SSH. Sa documentation précise aussi qu’une reprise partielle suppose que le fragment déjà présent corresponde au fichier source. Si celui-ci a changé, reprendre aveuglément peut produire une copie incorrecte. Figez donc la version à transférer, identifiez les fichiers partiels et contrôlez le résultat avant de déclarer la livraison terminée.
Diagnostiquer une attente par étapes observables
Si les fichiers arrivent mais que l’application ne répond pas, examinez le flux applicatif plutôt que de modifier toute la configuration. Distinguez résolution du nom, ouverture de la connexion, authentification, lecture de la première donnée et transfert complet. Relevez l’heure, le sens et le message exact utile. Écartez les identifiants, jetons et données du contenu partagé avec l’assistance.
Si la copie démarre puis ralentit, comparez un second passage dans les mêmes conditions et observez les étapes voisines : lecture à la source, préparation d’archive, écriture à destination. Le constat « GPU peu occupé » ne suffit pas à conclure que le réseau est responsable. Le dossier de diagnostic doit indiquer ce qui attend quoi, et quelle observation permettrait de départager les causes possibles.
Séparer accès extérieur et échanges entre GPU
Le réseau utilisé pour joindre l’application et les communications internes d’un calcul multicarte répondent à des besoins distincts. Le guide CUDA décrit une répartition explicite des données et des calculs entre périphériques, avec des possibilités d’accès dépendantes du système. Ni le nombre de cartes ni une bonne copie de fichiers depuis votre poste ne démontrent le fonctionnement d’un traitement distribué.
Décrivez donc le scénario attendu : tâches indépendantes affectées à chaque carte, ou traitement qui échange des données entre elles. Vérifiez ensuite le chemin réellement utilisé par votre logiciel. La réception est terminée lorsque les flux nécessaires fonctionnent, les contrôles sont enregistrés et une personne sait reprendre un transfert interrompu. Les conditions retenues rejoignent alors le dossier de déploiement.
Questions pour décider
Pourquoi distinguer Mo/s et Mb/s dans le planning ?
Un octet contient huit bits. Avec les unités décimales de l’exemple, 70 Mo/s correspondent à 560 Mb/s. Mélanger les deux multiplie ou divise l’estimation par huit. Inscrivez l’unité avec chaque mesure et calculez à partir du débit utile du transfert.
Faut-il tester les deux sens d’un transfert ?
Oui, si le projet importe des données puis exporte des résultats. Les chemins, destinations et conditions peuvent différer. Une bonne mesure d’import ne garantit pas que la récupération finale tiendra dans la même fenêtre ; testez le sens dont dépend chaque échéance.
Un transfert chiffré dispense-t-il du contrôle des fichiers ?
Non. Le transport et la validation du paquet répondent à des questions différentes. Vérifiez aussi les fichiers attendus, leur intégrité et leur ouverture depuis la destination. Une mauvaise sélection de fichiers peut être transférée correctement tout en restant inutilisable.