Connexion aux serveurs interactifs

Le CC-IN2P3 met à disposition des utilisateurs ayant un compte calcul deux clusters de serveurs interactifs permettant la préparation des tâches à destination de la plateforme de calcul : développement, test, etc. Le cluster généraliste cca et le cluster ccahm, offrant une plus grande quantité de RAM et une partition local sur disque SSD /scratch_ssd.

Les clusters interactifs sont accessibles avec la syntaxe suivante :

% ssh -Y <username>@cca.in2p3.fr

ou

% ssh -Y <username>@ccahm.in2p3.fr

cca.in2p3.fr et ccahm.in2p3.fr sont des alias qui redirigent l’utilisateur vers le serveur le moins chargé de chaque cluster ;
l’option -Y active le transfert X11 sécurisé ;
pour les utilisateurs Microsoft Windows nous conseillons le client SSH PuTTY.

Important

En cas d’erreur de connexion avec la commande SSH, veuillez envoyer un ticket au support utilisateurs avec le retour de la commande en mode débogage :

% ssh -vvv <username>@cca.in2p3.fr

Autres moyens de connexion

Bonnes pratiques d’utilisation

Chaque serveur interactif est partagé par plusieurs utilisateurs, nous préconisons un certain nombre de bonnes pratiques pour garantir une utilisation optimale à l’ensemble des utilisateurs.

Attention

Le non respect des règles suivantes peut entraîner l’arrêt autoritaire des processus concernés.

Un seul processus de calcul est permis par serveur interactif et 3 processus au maximum sur l’ensemble de la plateforme interactive. Des limites de temps s’appliquent :
- 24 heures de temps CPU au maximum pour un processus et 1 heure de temps CPU pour un processus multi-coeurs ;
- les processus inactifs depuis plus de 24 heures sont arrêtés.
les processus parallèles avec l’utilisation intensive à la fois en CPU et en lecture/écriture ne sont pas permis (exemple : make -j, scons, b2, ninja, etc.). Il est toutefois possible d’exécuter ce genre de processus via des jobs interactifs (voir job interactif) ;
éviter une consommation excessive de mémoire qui pourrait avoir un impact sur le système, dans ce cas utilisez de péférence le cluster ccahm. La commande htop -u username peut être utile pour surveiller la consommation en terme de mémoire ;
il est interdit d’exécuter des tâches en mode « batch » (exemple : traitement d’une grande quantité de fichiers en boucle) ;
le /scratch n’est pas un espace de stockage permanent : les données peuvent être supprimées à tout moment afin de libérer de l’espace. Normallement les données sont effacées au bout de 14 jours. De plus, évitez de stocker des données volumineuses ;
un seul processus de transfert est autorisé par serveur (exemple : scp, rsync ou dq2-get) et 3 processus sur l’ensemble des serveurs interactifs ;
les processus détachés et persistants après la déconnexion de l’utilisateur ne sont pas permis.
- Le logiciel Screen déroge à cette règle, mais son utilisation n’est pas destinée à se substituer au système de batch, ni à exécuter des services ou encore à accaparer des ressources limitées (comme les noeuds de calcul interactif avec des GPU) ;
- le cas d’usage de Visual Studio Code est expliqué ci-dessous dans son paragraphe dédié.
Pour garantir la confidentialité des données utilisateurs, l’utilisation de rmate (ou autre éditeur similaire) nécessite d’utiliser un port TCP aléatoire au lieu d’un port fixe.

Transférer des fichiers

Seul le protocole SSH est autorisé pour les connexions ou les transferts de fichiers vers ou à partir des serveurs interactifs du CC-IN2P3. Deux modes d’authentifications sont disponibles : par mot de passe, ou par ticket Kerberos (via GSS-API). Une authentification de type RSA/DSA (clé SSH) vous permettra l’accès, mais elle n’initialisera pas votre ticket Kerberos.

Pour copier des fichiers :

% scp <mon fichier> <username>@cca.in2p3.fr:~/<mon repertoire>/

% sftp <username>@cca.in2p3.fr

Pour plus d’informations, veuillez vous référer aux pages de manuel (man <commande>) des commandes ci-dessus.

Changer de shell

Pour changer le shell par défaut, utilisez la commande changesh avec la syntaxe suivante :

% changesh --help

Usage: changesh --help  | -h
       changesh <shell>

Où <shell> peut être bash, csh, ksh, tcsh or zsh.

Utilisation de Visual Studio Code

Visual Studio Code (VS Code) est un environnement de développement intégré développé par Microsoft pour Windows, Linux, macOS et les navigateurs web. Veuillez trouver ci-dessous des recommandations d’utilisation dans l’écosystème du CC-IN2P3.

Répertoire de travail

Lorsque VS Code démarre, il lance la commande git status -z -uall dans son répertoire de travail. Cette commande n’est pas optimisée pour un répertoire contenant beaucoup de fichiers et/ou des fichiers de taille importante : veuillez lancer VS Code à partir d’un répertoire contenant un faible nombre de fichiers.

En règle générale, veuillez privilégier un sous-répertoire de votre répertoire personnel (HOME) plutôt qu’un de votre répertoire GROUP.

Serveur Jupyter Notebook

VS Code permet de lancer un serveur Notebook Jupyter intégré. Si le serveur Jupyter intégré est lancé lors d’une connexion à un serveur interactif cca, son utilisation peut provoquer le dépassement des limites acceptés et son exécution sera interrompue.

Pour exécuter vos notebooks Jupyter, nous vous conseillons de privilégier l’utilisation de la Plateforme de Notebooks Jupyter proposée par le CC-IN2P3.

Perte de connexion

Si la connexion internet de votre poste de travail peut être interrompue par la mise en veille de votre écran (cas des utilisateurs Mac avec une connexion Thunderbolt, c’est-à-dire une connexion au réseau Ethernet filaire dans l’écran), vos fenêtres VS Code seront fermées par le manque de connexion. Voici ci-dessous la description de ce qu’il se passe :

VS Code crée une connexion SSH vers un serveur cca et lance (sur cet interactif) Node.js ;
l’utilisateur interrompe temporairement de son activité ;
le poste de travail détecte le manque d’activité et met l’écran en veille: la connexion réseau est coupée et
- la connexion SSH disparaît ;
- mais le Node.js de VS Code persiste ;
- le VS Code fantôme est détecté par le monitoring des interactifs (et tué).

Optimiser la performance

Pour résoudre certains problèmes de performance avec VScode depuis un serveur interactif, vous pouvez ajouter les lignes ci-dessous dans votre fichier de configuration ~/.vscode-server/data/Machine/settings.json.

{
   "files.watcherExclude": {
      "**/.git/objects/**": true,
      "**/.git/subtree-cache/**": true,
      "**/node_modules/*/**": true,
      "**/.cache/**": true,
      "**/.conda/**": true,
      "**/.local/**": true,
      "**/.nextflow/**": true
   }
}

Bien évidemment, vous pouvez modifier ou ajouter des répertoires à la liste.

Sur-exploitation des ressources

Par défaut lors de son démarrage, VS Code recherche les noms des symboles du code source pour ses fonctions d’auto-complétion. Pour se faire, il utilise ripgrep qui utilise tous les cœurs de la machine pour faire un scan rapide.

Attention

Il est recommandé, si possible, de désactiver cette collecte avec ripgrep (ou de la configurer pour être moins agressive) pour éviter la charge trop importante sur le serveur interactif.

Pour désactiver ripgrep, ajoutez la ligne suivante au fichier de configuration de VS Code :

"search.useRipgrep": false

Localisation du fichier de configuration :
- sur Linux : $HOME/.config/Code/User/settings.json
- sur macOS : $HOME/Library/Application Support/Code/User/settings.json