Bascule CCRT vers TGCC

Page débutée en Août 2011

Prochaine telco : 12 octobre 2012 11h. Numéro d'appel : 0821 230 749

Voir la page qui contient les résultats des journées de brainstorming sur la migration CCRT-TGCC

Cette page décrit les étapes nécessaires pour intégrer dans nos chaines de calcul les évolutions dues à la bascule du CCRT vers le TGCC.

Constat

L'utilisation de /dmnfs comme espace de stockage est à revoir. Au TGCC, l'espace fichier : $STOREDIR est un espace d'archivage. Son utilisation doit être l'archivage de fichiers de grande taille.

Le travail à faire est important et un soutien ingénieur est demandé. Il faut convertir la chaine, la tester en grandeur nature, convertir les données existantes et former à tout cela l'ensemble des acteurs.

Evolution de la chaine de calcul

• Utilisation de l'espace /scratch par les simulations en cours d'execution,
• Gestion/ménage de l'espace /scratch par la chaine,
• Output : Ajout d'étape de compactage des fichiers Output (voir outil create_pack).
  • On essaye par 10 ans. Voir calcul dimension.
  • Stockage du résultat dans STOREDIR
• Analyse : Stockage des fichiers Analyse tels quels sur STOREDIR.
  • Création depuis /scratch ou depuis fichiers Output compactés sur STOREDIR
  • Prévoir accès par dods des fichiers SE et TS.
• Restart : prévoir sélection d'un fichier par an dans /scratch avant stockage dans STOREDIR
• Debug :
  • fichiers gardés sur /scratch seulement?
  • seulement les 10 premières années compactés et gardés?
• ATLAS et MONITORING :
  • fichiers gardés sur /work avec accès par dods.
  • tar et stockage sur STOREDIR
• Rappel (ajout après relecture 2/8/2011) : besoin d'un espace $TMPDIR par job. Créé et vide au début du job, détruit en fin de job. Besoin pour chaque job de type exécution ou pré/post-traitement.

Questions

• Est-ce qu'on sait manipuler avec nccat des fichiers de 30, 40 70 et 120 Go?
• Où peut-on faire des essais? sur curie?

Transition

• Déplacement des simulations de /dmnfs vers STOREDIR
• Faut-il avoir toutes les variables (1D et HF) en TS?
• Output : Besoin d'un outil de type Pack_checker qui prend les répertoires depuis /dmnfs et lance l'outil create_pack pour compacter les répertoires Output
• Analyse : Besoin d'outils de transferts pour le répertoire Analyse
• Debug : ménage
• Restart : sélection de 1/12 et transfert

Dimension des ressources

• dimension espace /scratch pour les simus : 6 fois 50 ans soit 30 To au départ. Prévoir 50 To l'année suivante.
• dimension dods ATLAS et MONITORING : 10 To

Outils

• create_pack :
  • Basé sur create_SE
  • prend 10 ans, fait les nccat, stocke sur STOREDIR
  • extension possible pour les simulations prolongées dans un 2ème temps
  • utilisation depuis /scratch dans la nouvelle chaine ou depuis /dmnfs pour les transferts
• unpack :
  • basé sur ncks pour extraire et éclater les fichiers selon nomenclature /scratch
• pack_checker :
  • vérification de l'existence des fichiers Output packés sur STOREDIR
  • lance create_pack depuis /dmnfs

Planning

• dimension espaces : août 2011
• test outils :
  • nccat sur fichiers de 148 Go, avec netcdf4 compressé en sorties,
• présentation IPSL : septembre 2011
• prototypes outils : septembre/octobre 2011

Evolution à moyen terme

• faire les simus par an
• utilisation de l'ioserver pour éviter l'étape rebuild
• stockage en netcdf4 compressé

Création des scripts

Résumé (23/02/2012)

J'ai mis les dernières versions des scripts dans le répertoire /home/cont003/p86cozic/SCRIPTS_DEM/FINAL/

• find_directory_simul.job :
  • prend en entrée un fichier texte du même type que celui donné à ccc_archive -ipsl_pack. Ce fichier contient donc le path de plusieurs simulation, ou d'un répertoire maître (IGCM_OUT, IGCM_OUT/IPSLCM5A/ etc...) Exemple /home/cont003/p86cozic/SCRIPTS_DEM/FINAL/param_AC.txt.
  • crée un fichier liste_simul_.... (dans mon exemple liste_simul_param_AC.txt) qui contient le path de toutes les simulations découlant du fichier de paramètres.

• create_config_card.job
  • prend en entrée un fichier texte de type liste_simul_... créé par find_directory_simul.job
  • crée pour chaque simulation contenue dans liste_simul_... un fichier config_card$JobName stocké dans un répertoire $SCRATCHDIR/tmp_$JobName/. Ce fichier contient les infos suivantes : JobName, DateBegin, DateEnd, PATH_SIMUL(=$R_OUT/$JobName)

A faire ou corriger :

• ajouter le calendrier. Difficile de faire la différence entre leap et noleap si il n'y a pas d'année bissextile dans la simulation (mais dans ce cas là la différence n'est pas vraiment utile ... sauf si l'on veut prolonger la simulation)
• il y a un bug dans DateBegin, elle indique le dernier jour du premier mois et non pas le premier jour. Cela dit vu qu'après on ne travaille jamais avec les jours cela ne doit pas poser de problèmes. DateBegin? est trouvée à partir des dates indiquées dans les fichiers de restart, car il peut y avoir des trous dès la première période dans les outputs. Pour connaître le premier jour il faut tenir compte du periodlength (1D, 5D, 1M, 1Y), et pour le connaître il faut analyser le nom d'un fichier d'output.

• archive_restart.job
  • prend en entrée $1 un fichier config_card créé par create_config_card.job et $2 une période pour les pack de type 5M ou 20Y
  • crée un répertoire $SCRATCHDIR/ARCHIVE_RESTART_${JobName} dans lequel seront contenus les tar des restarts (renommés) par période_pack

Note :

• Sébastien a remanié ce job pour l'introduire à libIGCM et il m'avait dit qu'il l'avait optimisé, cela vaut certainement le coup de récupérer sa version.

• find_size_pack.job
  • prend en entrée $1 un fichier config_card créé par create_config_card.job et $2 le path d'un fichier information_dmnfs_2011-09-21
  • calcule si 20 ans c'est une période de pack acceptable pour avoir au final des fichiers de taille comprise entre 20G et 70G, ou sinon calcul la nouvelle période de package. Cette période (20 ans ou nouvelle période) est écrit dans un fichier $SCRATCHDIR/tmp_${JobName}/period_pack.txt

Note :

• Si la simulation analysée fait moins de 20 ans cela sera pris en compte
• Si la simulation analysée fait moins d'un an ça plante pour l'instant (testé sur une simulation de 1 mois)
• le calcul de la période est fait en analysant 10 périodes de 20 ans, cela n'a de sens que si il y a des fichiers non-homogènes dans les sorties. Sinon l'analyse d'une seule période suffit. Est-ce que cela vaut le coup ?

• write_liste_pack.job
  • prend en entrée $1 config_card et $2 information_dmnfs_2011-09-21
  • pour la période calculée dans find_size_pack.job crée les listes des fichiers à concaténer avec ncrcat et repère si il y a des trous auquel cas transforme la liste ncrcat en liste tar dans $SCRATCHDIR/tmp_$JobName?. Si jamais il y a des fichiers manquants un fichier ${type_file}_manquant.list sera créé (ex: 1M_histmth.nc_manquant.list) dans $SCRATCHDIR/tmp_$JobName.

Note :

• Comment gérer les fichiers non-homogènes ? Il faut vérifier que ncrcat file1 file2 renvoie bien un warning si file1 contient moins de variables que file2.

Notes précédentes (janvier et février 2012)

• Pour l'archivage des restarts
• Pour l'archivage des fichiers Output

Dimension et nombre de fichiers pour une simulation historical : 156 ans

Résolution		Pack par 120 mois	Pack par 60 mois
96x95x39	nb fichiers	3852	4339
	nb fichiers Restart	1404	1404
	espace fichiers Restart	88 Go	88 Go
	le plus gros	65 Go	32 Go
	moyenne	3,5 Go	3 Go
	Total espace	13 To	13 To
144x142x39	nb fichiers	3852	4339
	nb fichiers Restart	1404	1404
	le plus gros	148 Go	73 Go
	moyenne	7 Go	6 Go
	Total espace	25 To	25 To
	espace fichiers Restart	100 Go	100 Go

notes telco 3/8/2011

• tests faisables sur curie, avec login projet COUAC pour commencer
• Pas de classe mono particulière, mettre dans les files d'attente par défaut les tests et les post-traitements
• TMPDIR existera sur curie. Il faudra, bien sûr, faire cd $TMPDIR
• créer une simu de travail de type historical sur /scratchdir sur curie :
  • avec fichiers vides. Voir (~foujolsm/create_simu_bidon ou ~p86maf/pub/etc/create_simu_bidon) qui crée le répertoire BIDON/$1 avec 91500 fichiers selon l'arborescence IGCM_OUT. Il manque juste le répertoire des ATLAS.
  • avec fichiers remplis par une vraie simu quand on aura lancé une vraie simu de prod sur curie
• sept/oct : accès aux répertoires CCRT depuis TGCC et TGCC depuis CCRT ie logins CCRT ouverts

notes telco 7/10/2011

• TGCC :
  • Voir présentation COMUT
  • STOREDIR, WORKDIR communs aux machines,
    • STOREDIR : archivage in fine des fichiers en nombre réduits et très gros ( 1-> 100 Go)
    • WORKDIR : 1 TO, genre HOME collectif
  • SCRATCHDIR local à chaque machine. Besoin estimé à 50 To par login faisant des simus de production (30 pour commencer?)
    • sur curie :
      • simulations
      • utilisation de SCRATCHDIR pour stockage des simus pendant toute leur vie,
      • utilisation de SCRATCHDIR par les jobs de post-traitements tournant sur curie aussi, stockage des résultats sur STOREDIR
      • chaine modifiée avec outil de pack inclus, stockage des résultats sur STOREDIR
  • dods . Besoin identifié de 3 serveurs :
    • dods petits fichiers stockés sur WORK (et sous forme tarés sur STOREDIR)
    • dods fichiers entre 1 et 100 Go depuis STOREDIR
    • dods/datanode pour publication, des fichiers au format CMOR, sous le login p86cmip5
• Outil pack :
  • besoin de décrire le besoin en détail et le design :
    • simus longues et très longues, simus haute résolution , ...
    • create_pack, check_pack,
    • TS depuis pack, SE depuis pack, ...
    • IGCM_OUT et SORTIES_CPL_IPSL
    • travail collectif à prévoir mi-octobre/novembre
• Période intermédiaire :
  • simulation sur titane ou mercure,
  • utilisation de STOREDIR et WORKDIR communs, STOREDIR selon nouvelles règles
  • accès à /dmnfs en lecture seulement
• Déménagement :
  • Dès l'ouverture des accès à STOREDIR, déménager les fichiers utilisés par le serveur dods/datanode
  • le CCRT déménagera les fichiers des autres communautés : 1,5 Po
  • Pour nous, déménagement avec inclusion outil pack dans un 2ème temps, à commencer au plus tard en février 2012
  • login exemple : p24luc
• Soucis actuels :
  • surcharge ponctuelle de cesium en interactif. trop de find, ls , rsync simultanés Vérification de l'ouverture des accès vers ciclad depuis noeuds de calcul cesium
  • surcharge structurelle permanente :
    • transferts cesium et SX9 -> /dmnfs majoritaires
    • ccc_archive va être suspendu pour voir si cela va mieux (retour à situation été 2010?)
  • ccc_archive : enregistrement des commandes et passage ultérieur, sous le monitoring du CCRT pour limiter le nb de lecteurs utilisés. Explication à faire aux utilisateurs de ccc_archive
  • déménagement : tar par sous-répertoires pour limiter les fichiers résultats (entre 1 et 100 Go)

Notes telco lundi 14 novembre 2011

Participants : GW, PL, OM, ACa, ACo, MAF

• DMF se porte bien mieux depuis l'arrêt de ccc_archive. La nouvelle mouture de ccc_archive (qui enregistre les demandes pour les faire plus tard) sera disponible très prochainement.
• A signaler le login labetoul sur /dmnfs13 très petit. Aucune modification d'espace /dmnfs prévue.
• Logins GENCI au TGCC : en janvier 2012
• Pérenniser les données créées sur Curie lors des Preparatory Access sur les espaces des comptes CCRT classiques.
• Accès aux nouveaux répertoires TGCC depuis les machines du CCRT (titane, platine, cesium, mercure) à partir de la semaine prochaine. $CCCWORKDIR et $STOREDIR. Voir infos dans CR Comut et message à venir à tous les utilisateurs et à JL Dufresne.
  • En résumé :
    • à partir de la semaine prochaine sur les machines titane, platine, cesium et mercure, on peut utiliser les répertoires CCCWORKDIR et STOREDIR pour se faire la main
    • à partir de fin février, certains n'auront plus l'accès en écriture sur /dmnfs . Cela se fera par /dmnfsxxx et s'étalera sur 3 mois.
    • utilisation du script spécial libIGCM pour migrer/rassembler les résultats de simus.
    • fin de la migration en décembre 2012.
    • IPSL : besoin de travailler sur libIGCM. voir journées libIGCM et cahier des charges aide CCRT à écrire pendant ces journées.
• Participation du CCRT au brainstorming libIGCM. Sans doute une partie, en attente de l'ODJ.
• Affaires courantes : filtrage ciclad[2] avec les noeuds de calcul Césium. Devrait se débloquer. Promis.
• scratchdir sur Titane : catastrophe. Pourquoi ? Des solutions ? Comment ce dysfonctionnement va t'il apparaître dans les statistiques présentées au COMUT, au COPIL et à GENCI ?
  • un correctif pour les soucis de No space left on device sur scratchdir titane a été appliqué.
  • il reste une erreur (ce matin) d'écriture netcdf. Ne se produit pas en WORKDIR. A suivre.
  • Discussion sur les indicateurs de fonctionnement. A suivre.
• scratchdir sur curie
  • Discussion sur la nouvelle chaine qui utilisera largement scratchdir pour les simus en route et stockera des fichiers paqués sur STORE. Si perte de scratchdir, perte de longs morceaux de simulation
• discussion sur les copies en double sur médias différents.
  • rien de prévu à ce jour
  • première réponse : trop lourd de dupliquer sur 2 centres, mais le besoin reste
  • étude du prix pour dupliquer sur media différents 500 To de fichiers (p86cmip5), 1 Po, 1,5 Po
  • 5000 cassettes dmf à ce jour
• utilisation de la frontale tx7 de SX9 aussi longtemps que le SX9
• discussion sur la fin de cesium.
  • pas de souci a priori si après arrêt SX9.
  • sur curie, le post-traitement représentera 10 à 20 % du temps calcul, sera composé d'un grand nombre de jobs scalaires (800 jobs 1 proc pour 40 jobs de calcul 32 procs) . Voir estimatif vargas là : ​https://forge.ipsl.jussieu.fr/igcmg/wiki/PerformancesIPSLCM5A#IDRISIBMvargas

Notes telco jeudi 15 décembre 2011

Participants : Gilles Wiber, Patrice Lucas, Thomas Leibovici, Kilian Cavalotti, Anne Cozic, Sébastien Denvil, Arnaud Caubel

• Maintenance des machines du 13 décembre
  • Les problèmes suivants sont apparus au redémarrage des machines :
    • mercure : variables d’environnement mal positionnées. Origine du pb : modifs effectuées sur le "ccc_home".
    • titane : un "cd ~" a été ajouté dans profile.local.
    • Ces problèmes ont entrainé l’arrêt de la production IPSL sur mercure et titane jusqu’au 14 décembre après-midi. Tout semble rentré dans l’ordre. Ces pbs étaient dus à la situation exceptionnelle de fusion du CCRT et TGCC.
      • CCRT : des tests sur les variables d’environnement seront ajoutés lors des procédures de check passées pour valider les maintenances.
      • IPSL : necessité de fournir un bench type au CCRT à passer après chaque maintenance (et régulièrement ?) pour s’assurer d’une non régression de la chaîne.
  • /home/cont003/p86caub devient /ccc/cont003/home/dsm/p86caub.
    • A voir quelles permissions mettre sur les groupes dsm et genci*.
    • Rappel des standards d’utilisation : un seul login par utilisateur imputé sur plusieurs groupes.
• Divers
  • Arrêt mercure SX8 : arrêt de la production au 31/12/2011 mais délai de connexion de 3 mois. Plus de ménage sera fait par les anciens utilisateurs, plus d'espace sera dispo pour les utilisateurs actuels.
  • Un seul login utilisateur sur Curie (et ailleurs !) : pour les utilisateurs qui avaient un compte en avance (type preparatory access) le compte sera supprimé et les données transférés sur le seul compte de l’utilisateur sur demande.
• Migration des données
  • Calendrier :
    • Depuis fin nov 2011 : accès aux nouveaux espaces CCCWORKDIR et CCCSTOREDIR depuis les machines CCRT. Une indisponibilté prolongée du cccworkdir comme celle qui a eu lieu avant la maintenance ne se reproduira pas.
    • 3 mois pour migrer la production et préparation d’archive (ccc_archive).
    • Passage read-only :
      • 7 fevrier : comptes dormants + utilisateurs volontaires
      • Mars : dmnfs 1,2,3 et 13
      • Avril : dmnfs 4 à 12
    • Accès en read-only au dmnfs jusqu'à la fin des dmnfs (fin 2012 ?)
  • Espace tampon :
    • Deux espaces tampons à définir :
      • Espace utilisé pour la migration : 4Po situé sur le storedir mais NON VISIBLE par l’utilisateur
      • Espace utilisé pour le « pack » au cours de la production :
        • Mercure : scratchdir (partagé entre climat SX9 et utilisateurs SX8), on part sur 20TB, devrait être suffisant. Possibilité de quota par groupe plutôt que par utilisateur ? Taille de scratch nécessaire à affiner. STOREDIR = dernier recours car :
          • Pas fait pour ça
          • Montage NFS depuis mercure et titane
        • Titane : scratchdir, devrait être suffisant. Projection IPSL à affiner. Dernier recours : STOREDIR
        • Curie : scratchdir, quota à affiner, nombre de power-user
    • Trouver une variable d’ajustement avec toutes ces contraintes :en fonction de la taille des fichiers requises, du nombre de fichiers limité sur le Storedir, de la tailles de scratch nécessaire et disponible sur mercure et titane,…
  • Le passage de titane vers curie pour l’IPSL sera progressif mais le début d’année 2012 se fera sur titane car la production sur curie nécessite :
    • l’utilisation du pack dans la chaîne
    • le portage des différents outils (compilation,soumission,…) et la validation des modèles
  • Commande ccc_archive :
    • Anne a remonté quelques soucis sur la version actuelle. Des tests vont être refaits.
    • Le flag pour être "ipsl_packé" se fera via la commande ccc_archive. L’IPSL doit fournir ce qu’il faut intégrer dans le ccc_archive. A faire rapidement (idéalement avant les vacances, mi-janvier dernier délai).
    • Recommander d’utiliser le fichier « à plat » du cscratchdir avant l’utilisation du ccc_archive
    • Pas de limite (en nombre) d’archives demandées
  • Affectation des ressources calcul (heures) Curie. Estimer les ressources nécessaires et les affecter clairement à cette migration. Estimation : (8 CPUs sur 3 mois). Voir ​informations complètes sur la concaténation ipsl/vivaipsl
  • Cahier des charges :
    • Calendrier : dépôt fin janvier pour début de prestation début mars.
    • Toutes les parties listées dans le document sont pour une seule et même prestation.
    • Jean-Noël Richet et Bruno Froge s’occupent de ça.
  • Datanode : ouverture de filtrage OK, Dieter a avancé et voit avec Sébastien par mail pour continuer.
  • Dods : pas abordé.

Notes telco jeudi 19 janvier 2012

Participants : Gilles Wiber, Patrice Lucas, Thomas Leibovici, Anne Cozic, Sébastien Denvil, Olivier Marti, Marie-Alice Foujols, Laurent Crouzet.

• Datanode ou dods1 :
  • Filtres nécessaires, ouverts,
  • François Valley recruté au CEA suit cette installation
  • Installation à refaire à partir de scratch
  • Aide IPSL attendue si souci. OK puisque installation complète à l'IPSL en cours avec rédaction d'un mode d'emploi
  • Datanode CCRT/TGCC nécessaire pour publier les données depuis le CCRT
    • pour le moment publication depuis l'IPSL et accès des demandeurs aux fichiers IPSL
    • besoin de ce datanode CCRT pour publier les données les plus volumineuses (HF 6H et 3H)
    • la publication depuis l'IPSL correspond à un palliatif temporaire. Ce datanode reste l'action CCRT/TGCC la plus prioritaire.
  • Attention : tout changement de nom (path complet inclus dans database) d'un fichier publié impose de le dépublier puis de le republier
• Bascule fichiers /dmnfs sur espace CCC_STOREDIR pour login prêt : p86cmip5
  • OK pour inclure ce compte dans la liste des migrations du 7 février. A priori pas de compactage. < 200 000 fichiers et 150 TO
  • Une fois les fichiers sur STOREDIR, on pourra les publier de là sur le datanode TGCC/CCRT dods1.
  • Si la migration dépasse 4 (OK?) semaines, on publiera depuis DMNFS avant de dépublier/republier depuis STOREDIR mais ce serait mieux d'éviter cela.
  • Une fois /dmnfs en lecture seule, faire la CMORISATION directement sur CCCSTOREDIR
• Bascule fichiers /dmnfs sur espace CCC_WORKDIR pour login prêt : p24data (TGCC/CCRT)
  • OK pour inclure ce login dans la liste du 7 février. Compactage souhaité.
  • Migration avec compactage sur CCCSTOREDIR par le CCRT.
  • Anne fera les tar xvf en CCC_WORKDIR
• ouverture serveurs dods pour mise à disposition petits fichiers de type Atlas et Trusting et ouverture serveur dods pour mise à disposition gros fichiers de type Analyse stockés sur CCC_STOREDIR
  • donner accès depuis le serveur dods.extra existant à un répertoire dods sur CCCSTOREDIR et à un autre répertoire dods sur CCCWORKDIR, accès en lecture seule (TGCC/CCRT)
    • Fait le 2 février 2012.

      /ccc/work/cont003/dods/public/monlogin ===>   http://dods.extra.cea.fr/work/monlogin
      /ccc/store/cont003/dods/public/monlogin ===>  http://dods.extra.cea.fr/store/monlogin
      

      /ccc/work/cont003/dods/prive/monlogin ===>   http://dods-prive.extra.cea.fr/work/monlogin (avec filtres IP)
      /ccc/store/cont003/dods/prive/monlogin===>  http://dods-prive.extra.cea.fr/store/monlogin (avec filtres IP)
      

  • ajouter les commandes permettant de faire les liens hard pour les fichiers sur CCCSTOREDIR et CCCWORKDIR que l'on veut rendre visible : dods_cp à compléter (IPSL?)
• p86ipsl : bascule fichiers /dmnfs sur espace CCC_STOREDIR pour login prêt une fois la distinction fichiers pour dods faites
  • bascule en mars
  • Répertoire IGCM synchronisé entre $DMFDIR et $CCCWORKDIR
  • migrer auparavant les pages du trusting sur le répertoire CCCWORKDIR et rendre ce qu'il faut visible sur dods. Voir ​http://webservices.ipsl.jussieu.fr/trusting/
  • Cible souhaitable : CCC_WORKDIR, donc compactage puis tar comme p24data
• Liste des comptes dormants susceptibles de migration précoce : le CCRT est en train de la préparer et l'envoie très vite.
• Installation des logiciels utiles sur titane (CCRT OK),
  • OK pour la liste, reste à valider les options.
  • utilisation de titane pour post-traitements au lieu de cesium,
    • test en production en cours, avec libIGCM revu (1ère étape : aucun transfert de fichier direct sur DMNFS)
    • attention à la facturation des noeuds complets (*8!)
• Installation des logiciels utiles sur curie. A faire une fois la vérification sur titane OK.
• Point sur le développement de ipsl_pack, inclus dans évolution libIGCM en cours. Voir document brainstorming sur la migration CCRT-TGCC
• Commande ccc_archive :
  • réponse à la demande de correspondant dédié, hotline pour infos sur la commande, telco pour les internes. 500 Go visé.
  • ccc_archive en pleine action en ce moment pour p24previ, mail au début puis mail à la fin.
  • un lecteur monopolisé pour les lectures de bandes. Travail bande par bande.
  • discussion pour ajout option ipsl_pack avec Thomas Leibovici : passer à Thomas le prototype d'appel
• Point sur la rédaction du cahier des charges, attente retour Arnaud. L'IPSL et Laurent Crouzet insistent sur la nécessité d'inclure les tests systématiques sur IDRIS. Le CCRT émet de fortes réserves. Gilles Wiber va réétudier la question.
• Autres points :
  • facturation noeud titane complet (8 procs) pour les jobs mono donc les jobs de post-traitement
  • process fantômes sur les noeuds de calcul. Déséquilibre le parallélisme, fait partir les jobs en time limit, .... *Code AbInit? dans une configuration spécifique à l'origine de ces soucis repéré, actions en cours pour corriger le code et limiter les impacts.

Prochaine telco début février : doodle à lancer. Est-il possible de faire des visio, par rms par exemple? OK à Jussieu, LSCE?, TGCC?

Notes telco 16 février 2012

Présents : Laurent Crouzet, Patrice Lucas, Kilian Cavalotti , Gilles Wiber, Anne Cozic, Sébastien Denvil, Marie-Alice Foujols

On a commencé par le point 6).

• 6) production sur CCCWORKDIR/CCCSTOREDIR.
  • Ces soucis empêchent d'avancer sur les tests systématiques des versions successives de liIGCM. Pas de test = développements stoppés.
  • 6.1) SX9 : OK depuis ce jour. A retenir : cp possible mais pas ls.
  • 6.2) titane : Soucis déjà signalés.
    • cp de fichiers, avec original en accès 444, ne marche pas. Correctif attendu en mars seulement. Nécessaire pour la chaîne : empêche les erreurs comme retourner une simulation de même nom.
    • rm -rf de répertoires ne fonctionne pas avec une liste de 75 fichiers (trusting_xxx) (directory not empty!)
    • ls -l prend plusieurs minutes (à refaire une fois les file system curie stabilisés)
• Les files system CCC de curie ont été très instables depuis le passage en Lustre 2.1 et il y a eu des très gros soucis d'alimentation électrique. Les machines du CCRT (titane et SX9) ont été préservées autant que possible. Néanmoins, les arrêts des CCCWORKDIR et CCCSTOREDIR ne peuvent pas passer inaperçus dans ce contexte.
  • Les files system de curie (CCCWORKDIR et CCCSTOREDIR) sont visibles par NFS depuis les machines du CCRT. Pb de dialogue avec le NFS de NEC SX-9 des noeuds de calcul. Une solution de contournement a été mise en place ce jour
  • On insiste sur le besoin de nous expliquer ce qui se passe, surtout en amont des opérations prévues. On est demandeurs de plus d'informations sur les évènements impactants l'environnement de calcul et de réactivité par rapport aux changements impromptus : variables environnements fausses ou vides, ... Est-ce que les soucis transmis à la hotline remontent bien?
  • La communication sur les pannes se fait au moment de la panne et au moment du redémarrage. Très bien.
  • Attention à bien prendre en compte dans les rapports de fonctionnement l'ensemble de la chaine. C'est ce qui est fait.

    SX9 :
    ---------X---------X-------------  2/31
    cesium :
    ----XX-----XX--X---------XX-----  7/31
    dmnfs :
    ------X---------X--------XXXX---- 6/31
    Bilan total :
    ----XXX--X-XX--X--X-----XXXX---- 12/31
    

• 1) discussion sur la procédure de déménagement du compte p25luc. reporté car le listing n'est pas disponible.
  • prévoir le temps nécessaire aux uns et aux autres pour passer les commandes ccc_archive
  • La proposition de noms de fichiers à plat n'est pas satisfaisante: ~/dmf_import/IGCM_OUT-part0001.tar , suggestion : IGCM_OUT+IPSLCM5A+PROD+piControl+piControl2+OCE+Output+MO-part001 …
  • 1.3) Point sur le développement de ipsl_pack, date attendue pour ipsl_pack : 15 mars 2012. Le développement des actions de bases de ipsl_pack a commencé. restart, Textes, ATLAS et MONITORING. reste un gros morceau avec les fichiers Output
• 2) comptes en read-only ou plutôt comptes figés : p86cmip5, p24data
  • Rappel : le passage en read-only par login n'est pas possible. C'est un accord oral de non mouvement de fichiers sur un compte donné. Les mouvements (création, destruction, ...) de fichiers ne seront pas repris et donc perdus.
• 3) p86ipsl prévu pour mars. Reste à finir de basculer les calculs de trusting produisant actuellement sur DMFDIR. En attente version beta de chaine libIGCM produisant sur CCCSTOREDIR/CCCWORKDIR sur SX9 et sur titane.
• 4) serveur dods sur espaces CCCWORKDIR et CCCSTOREDIR. OK avec en plus distinction public/prive. Vérifier les performances une fois les filesystem CCCWORKDIR/CCCSTOREDIR stabilisés.
  • l'IPSL a modifié les commandes dods_cp et dods_rm pour en tenir compte. dods_cp dods_rm OK. A finir.
• 5) Installation des logiciels utiles sur titane (CCRT OK), Besoin de support sur fonctionnement en vrai des outils. Demander au support applicatif.
  • 5.1) OK pour la liste, reste à valider les compatibilités entre outils. Souci netcdf par exemple.
  • 5.2) utilisation de titane pour post-traitements au lieu de cesium,
    • test en production en cours, avec libIGCM revu (2ème étape 1) aucun transfert de fichier direct sur DMNFS, 2) accès aux fichiers de forcages depuis CCCWORKDIR-p86ipsl ))
    • attention à la facturation des noeuds complets (*8!) Visible sur la compta?
    • Attention, il faut travailler sur l'environnement des utilisateurs IPSL (p86ipsl) pour séparer session de compilation/calcul (avec netcdf 3.6.3) ou session de post-traitement (netcdf4) car les executions avec netcdf4 plantent sur titane. Exemple de souci de compatibilité entre les outils. A faire par IPSL et support applicatif si on leur demande.
• 7) Installation des logiciels utiles sur curie. A faire une fois la vérification sur titane terminée.
  • Nouvelles des accès à curie et transferts de fichiers curie/IDRIS. En cours. Relance IDRIS à faire par GW.
• 8) Cahier des charges. Revu par Arnaud et discuté/transmis à J.N. Richet.
  • Ajout 'audit' chaine de calcul comme proposé en réunion GENCI/TGCC/CCRT/IDRIS/IPSL du 3 février.
  • A noter ajout des temps du bench TS sur titane en MR. Voir : chiffrage ts titane en MR 10 ans historical
  • Ce bench est très pratique pour tester les développements des post-traitements de libIGCM, le pack, les versions des outils, les écritures sur /dmnfs ou CCCworkdir/CCCstoredir, ...
• 9) Datanode ou dods1
  • Une version du datanode est installée.
  • Souci pour publier un cas test au BADC. L'erreur est la suivante. Le BADC dit que cela ne vient pas d'eux. Le CCRT dit que tout les ports sont ouverts.

       raise ProtocolError(self._url, errcode, errmsg, headers)
    esgcet.publish.hessianlib.ProtocolError:<ProtocolError for
    https://cmip-gw.badc.rl.ac.uk/remote/secure/client-cert/hessian/publishingService:
    302 Moved Temporarily>
    ERROR: unable to successfully execute esgpublish
    

  • François Valley (CEA) qui suit le dossier nous a demandé comment faire évoluer les choses.
  • Sébastien propose de suivre la procédure suivante: ​http://forge.ipsl.jussieu.fr/prodiguer/wiki/docs/datanode#MinimalCleanthingsupforreinstallkeepingglobusandconfigurationfiles
  • test prévu avec publication sur gateway de test à l'IPSL. Soit le souci est réglé donc ça vient du BADC soit .... on cherche.
  • L'IDRIS est en train de faire un audit de sécurité du datanode car nous étudions avec eux un scénario de publication sur le noeud ESG depuis une machine sur laquelle on peut se connecter en intéractif. Cette solution est la solution préférentielle de l'IPSL pour utiliser le noeud de données.
  • Cette solution nécessite l'accès à la base SQL et à 2 fichiers du datanode. A valider par TGCC/CCRT.

Notes telco le 10 avril

• point rapide sur la nouvelle chaîne qui produit sur les nouveaux espaces CCCWORKDIR/CCCSTOREDIR (IPSL). Infos détaillées sur stabilité espaces depuis SX9, titane (TGCC/CCRT).
  • chaines de production en cours de test.
    • SX9 :
      • y a-t-il eu des blocages récemment?
      • tar x Restart : reste à faire, sans doute en Post-traitement
      • jobs en classe mono. Besoin de séparer les jobs prioritaires comme rebuild et pack qui permettent de libérer le quota scratch. Le CCRT/TGCC regarde la possibilité d'une classe prio pour rebuild et pack.
    • titane :
      • jobs mono : vérifier la compta
      • montée en charge : suivre les espaces scratch et les jobs mono en attente.
    • curie :
      • chaines de production en cours de test sur NL et NF.
      • performances NF : 60/100, NL 130/100 si titane =100.
      • système Petaflopique installé en 1 mois. Reste des soucis. Les signaler tous systématiquement à la hotline.
• Informations sur échanges de fichiers intra cont003.
  • Demander à mettre en 755 les répertoires home, work et store de type : /ccc/work/cont003/dsm ou /ccc/work/cont003/gen0826
• point détaillé sur la procédure de déménagement.
  • Passage en read only des /dmnfs restants :
    • Le 11 avril passage en read only de /dmnfs04 06 et 07
    • Délai pour /dmnfs10 et 11 pour les prévenir et faire du ménage.
    • Délai supplémentaire pour /dmnfs05 08 09 et 12. Attention : il n'y a plus que 300 To disponibles. Il faut que chacun compte ce qu'il va produire sur /dmnfs.
    • Le 11 avril, passage de tout en read only pour tester, valider et vérifier les performances des procédures.
    • Retour en write vendredi pour /dmnfs10 et 11 (ménage) et /dmnfs05 08 09 et 12 (production minimale).
    • Est-il possible de faire de la place en faisant un rm des fichiers déjà migrés sur CCCSTORE : p24data (non) logins Anne (plus tard)
  • quand seront disponibles les fichiers déjà migrés : p25cmip5 et p24data
    • Commencera après le 11 avril.
  • sous quel login tourneront les procédures : a priori login utilisateur, rm à faire de ce qui a été packé pour laisser faire le ramasse miette à la routine CCRT
  • les procédures tourneront sur curie, une fois l'espace tampon rempli et vérifié.
  • ordre de passage : ipsl_pack puis outil_ccrt pour que outil_ccrt, ramasse toutes les miettes de l'ipsl_pack
  • on dispose de 3 semaines pour finaliser. Besoin confirmé de faire un point précis, prévoir un autre point téléphonique avant le 3 mai? :
  • comment s'organise le travail côté CCRT pour le passage des outils : nb de personnes, suivi, …?, comment sera organisé le travail de suivi : quand ça se passe bien, quand ça se passe mal
  • nous avons les premières briques pour ipsl_pack, qui et comment sera fait l'assemblage final pour former l'outil final qui sera passé par le CCRT sur les fichiers du tampon
  • on s'oriente vers : demander ipsl_pack pour tous les répertoires $DMFDIR/IGCM_OUT par défaut
  • Comment traiter le cas ou l'utilisateur a demandé un ccc_archive sur IGCM_OUT (ou une sous partie de IGCM_OUT) ? Il faut que le ccrt vérifie donc avant de passer le pack qu'il n'y a pas eu une demande spécifique et dans ce cas retirer les répertoires concernés de l'ipsl_pack
  • comment sera vérifié que tous les fichiers /dmnfs seront sur l'espace tampon, check des fichiers présents sur le tampon versus fichiers dmnfs avant le pack, liste tampon nécessaire pour check ?
  • utilisation de leur outil de tar (tar_ccrt) pour faire nos tars a nous : archivage tar + verif archivage
  • que se passera-t-il si une bande ne passe pas?
  • y aura-t-il des rm dans la procédure? Danger!
  • comment seront gérés les arrêts de machine, redémarrage

Réunion suivante le 3 mai à Bruyere. Si besoin prévoir avant un point téléphonique spécial procédure déménagement.

Notes Réunion CCRT-TGCC le 3 mai

Objet de la réunion : Migration DMF pour la communauté des utilisateurs de l'IPSL vers l'espace de stockage mutualisé du CCRT

Date : jeudi 3 mai de 9h30 à 14h

Lieu : TGCC, salle Berlin

Présents IPSL : Arnaud Caubel, Sebastien Denvil, Olivier Marti, Anne Cozic, Marie-Alice Foujols

Présents CEA : Thomas Leibovici, Killian Cavalotti, Gilles Wiber, Véronique Roos, Patrice Lucas

• Mise en place de la nouvelle chaîne de production
  

• Rappel : De la part des calculs de l'IPSL, cette nouvelle chaîne de production vise à optimiser l'utilisation des espaces de données disponibles au CCRT et au TGCC. Cette chaîne vise notamment à améliorer les points suivants : utilisation des systèmes de fichiers locaux comme support des calculs et des espaces globaux d'archivage, archivage des fichiers sous un format limitant le nombre d'inodes et augmentant la taille moyenne des fichiers entreposés.
• La présentation de cette nouvelle chaîne, développée par Sébastien Denvil, a été réalisée aux utilisateurs de l'IPSL les 3 et 4 avril. Les utilisateurs basculent depuis progressivement. Les premiers tests de cette chaîne datent de Décembre 2012.
• Une baisse de charge a effectivement pu être constatée sur DMF attestant l'utilisation de cette nouvelle version de la chaîne par les utilisateurs.
• Mise en place sur SX9
  • Des tests de nouveaux paramètres visant à optimiser les débits des accès SX9 aux systèmes d'archivage globalisés ont provoqué un blocage lors de la dernière semaine d'avril. Il est décidé d'un commun accord de revenir à des paramètres stables mais moins performants.
  • L'architecture de la nouvelle chaîne de calcul entraîne à partir des noeuds vectoriels SX9 plutôt des accès à $CCCWORKDIR qu'à $CCCSTOREDIR.
  • L'IPSL demande la mise en place d'un monitoring plus fin des blocages que peuvent rencontrer les codes de calculs sur SX9 lorsqu'ils font des IOs sur les espaces de stockages mutualisés.
  • L'IPSL demande la mise en place d'une file prioritaire de soumission sur les noeuds scalaires.
• Mise en place sur Titane
  • Des lenteurs ont été constatées ponctuellement sur scratch.
  • Une demande de quota à 3TO sur le scratch de titane est formulée par Marie-Alice Foujols.
  • La simulation millénaire menée par Myriam Khodri, login p25khod, sur titane doit pouvoir se terminer avant la bascule complète des DMF en read-only. Jusqu'au 22 mai si besoin est, l'exploitation positionnera une priorité maximale aux tâches de cette utilisatrice afin qu'elle puisse terminer dans les temps sa simulation.
  • Une réflexion de modification de la comptabilité est en cours sur titane afin de ne facturer qu'un CPU les tâches de post-traitement qui sont effectivement mono-cpu.
  • Olivier Marti signale un bug sur le fonctionnement du code couplé sur titane où l'échec d'une partie des processus ne se répercuterait pas correctement sur les autres processus laissant des tâches portant inactives bloquées en machine.
• Mise en place sur curie
  • Un bon comportement global est constaté mis à part quelques blocages au démarrage.
  • Une documentation explicitant les différentes méthodes de connexion à curie est demandée par l'IPSL.
  • L'IPSL demande également un meilleur fléchage de la documentation "advanced usage" de curie qui existe et contient beaucoup d'informations importantes mais n'est pas très bien indiquée.
• Quotas sur les espaces partagés
  • La nouvelle chaîne IPSL nécessiterait les quotas suivants pour les 20 utilisateurs intensifs : 500 000 inodes par utilisateur sur $CCCSTOREDIR, 3 000 000 inodes par utilisateur sur $CCCWORKDIR.
• Bascule des productions de titane à curie
  • O. Marti confirme que ses utilisateurs sont prêts à basculer sur curie à partir de titane.
    

• Point sur la migration des données
  

• Les premières estimations concernant la première vague de migration positionne une fin de migration des comptes pilotes pour la mi-juin. L'IPSl rapelle les priorités sur la migration des comptes pilotes : p24data pas urgent ok pour mi-juin, p86cmip5 urgent pour traitement et organisation des données au sein des nouveaux espaces, p25luc urgent en tant que support des tests de migration et la chaine IPSL-PACK.
• La migration du login p25luc n'est pas effectuée jusqu'au bout afin de pouvoir tester les outils IPSL_PACK dans le tampon.
• Les détails de l'ensemble de la chaîne de traitement IPSL_PACK ont été abordés en séance. Les questions concernant les interfaces ont été résumé dans l'e-mail de Thomas Leibovici ("Interface avec pack_ipsl", 03 mai 2012). La présentation de l'IPSL est disponible là : point_migration_20120503.pdf​
• L'IPSL demande la fourniture d'un outil de tar adapté.
• L'accès aux espaces tampons doit être mise en place sur curie pour réaliser les actions de tar qui seront effectuées au nom des utilisateurs.
• Le dimensionnement des heures nécessaires sur curie pour la migration reste faible : 8 CPUs en moyenne sur la période de migration.
• Lors de la migration il est décidé d'appliquer les actions de packaging des données selon l'ordre suivant : 1) ccc_archive, 2)IPSL_PACK, 3)tar "mécanique"
• L'IPSL doit fournir la liste exhaustive de l'ensemble des logins pour lesquels l'étape "IPSL_PACK" devra être appliquée.

Notes telco CCRT-TGCC le 13 juin

Présents : Arnaud Caubel, Olivier Marti, Anne Cozic, Marie-Alice Foujols, Thomas Leibovici, Killian Cavalotti, Patrice Lucas

Mise en place de la nouvelle chaîne de production

• espaces communs :
  • demandes de quotas CCCSTORE/CCCWORK. Recenser les logins demandeurs. Faire les demandes au fur et à mesure et globalement dans les demandes d'heures d'Octobre.
• titane :
  • demandes de quotas sur scratch titane. Les faire parvenir au fur et à mesure à la hotline.
  • nb de jobs mono de post-traitements sur titane. La limite de 100 est atteinte régulièrement. Passer à 500 ou 300 jobs.
  • Avec la nouvelle chaine, les post-traitements qui se faisaient sur cesium se font sur les calculateurs (titane, mercure et curie)
• SX9 :
  • les jobs de post-traitements s'accumulent, sans doute à cause des transferts lents.
  • besoin d'une classe prio pour faire passer les REBUILD et PACK avant les TS et SE. En cours d'étude.
  • à la prochaine maintenance, installation d'un serveur NFS en plus.
  • surveiller les transferts, signaler à la hotline tout blocage
  • Il existe des statistiques de transferts entre SX9 et CCCSTORE/CCCWORK.
  • basculer les post-traitements utilisant les fichiers de CCCSTOREDIR : TS et SE sur curie.
• curie :
  • attente des jobs de production. Gestion des jobs par le faire share scheduler. Priorité fonction des consommations. Attention, dans un groupe donné à ne pas pénaliser les utilisateurs de production.
  • Quality of service : en place pour la classe test.
  • Continuer d'étudier le comportement et voir ce qu'on pourrait faire : réservation ou autre pour la production.

• toutes machines:
  • ccc_mpp : ajouter une une option pour avoir les noms des jobs complets et pas tronqués à 8 caractères.

Point sur la migration des données

• la chaîne est bien avancée. Il manque en particulier les tests de redémarrage en cas d'arrêt non prévu avec gestion des erreurs, une commande d'information sur l'état de migration/génération de listes et une parallélisation des scripts pour accélérer la partie "transformation des données" de l'outil. A noter la réunion de lancement de la prestation pour le 13 juin au LSCE. Pour rappel, le lot 1 de la prestation porte sur la consolidation de l'outil de pack IPSL.
• les données de p25luc seront disponibles dans la semaine du 18 juin. Il sera fait une copie de sauvegarde avant de nous les laisser pour tests.
• OK pour interaction directe entre le TGCC et le prestataire
• la migration des données IPSL vers l'espace tampon ne devrait pas commencer avant début juillet. Dans le meilleur des cas la transformation des données commencerait mi-juillet, mais le plus probable est début septembre. Pas de démarrage en aout.

12 octobre 2012

Points :

• déménagement DMFDIR/CCCSTOREDIR :
  • actualité sur la procédure de déménagement , fin du lot 1 de la prestation, RV semaine 43 et 44
    • les premiers tests seront faits sur le bac à sable, bien repérer les taux de réduction d'inodes.
    • besoin d'un fichier d'entrée dans le répertoire ~p86ipsl. Que se passe-t-il si pas là? A regarder (AC)
  • Rappel : ne pas oublier d'augmenter les quotas CCCSTORE du nombre de fichiers déménagés. Sera fait au cas par cas. Stop de la procédure au moment du dépassement de quotas.
• quotas et besoins p86cmip5 :
  • maintien de la demande 500 000
  • longues explications réciproques
  • décisions : voir mail P Lucas 12/10/2012
  • RV journée de travail 15 novembre à Bruyere
• utilisation de CCCSTOREDIR :
  • est-il possible de disposer d'un outil qui donne les chiffrages d'occupation et permet de repérer si on est dans les clous ou pas ? au moins du genre que vous utilisez, quite à ce que ce soit mis à jour une fois par jour.

    user      ,     type,      count,   spc_used,   avg_size,        0,     1~31,   32~1K-,   1K~31K,  32K~1M-,   1M~31M,  32M~1G-,   1G~31G,  32G~1T-,      +1T, ratio(0..1023M)
    xxxxxx    ,     file,     112061,   97.79 TB,    1.60 GB,       71,        1,      987,     5524,     2978,    17779,    51290,    33233,      198,        0, 70.17%
    

    • avec les détails des répertoires et fichiers ce serait mieux ou même plus interactif comme ce qui commence à être utilisé par P Brockmann et M Morgan :
      • ​http://www.youtube.com/watch?v=IR2vOUSv5u8
      • ​http://fishcam.com/fs_blaster/FileSystemVisualizer.html
  • fonctionnalités de cet outil :
    • actuellement le message signalant les dysfonctionnements a été largement complété :
      • 3 indicateurs
      • détails sur ce qui ne convient pas
    • la production d'infos pour ce message correspond à l'outil proposé par le TGCC. Diffuser un message type.
  • est-ce normal qu'on retrouve des petits fichiers (2600 octets) released ie sur bande seulement? Oui. released signale qu'un fichier est au niveau 1 ou 2 de HPSS. Le niveau 0 est signalé par online.
  • quand est-il prévu un outil d'information sur les montages de bandes (nombre, temps d'attente, autre info pertinente, …), comme cela existait pour DMFDIR? pas évoqué à cette telco.
• production sur curie :
  • augmentation de la limite à 128 du nombre de jobs pour les post-traitements. Maintien de la demande.
  • calcul de la priorité de passage sur curie. La calcul actuel empêche la production. Besoin de travailler sur cette question.
  • fiabilité des espaces scratch, /ccc/work et /ccc/store depuis curie. Du mieux depuis le 28 août : on est passé de 13% d'erreurs à 3 %. Tester les codes d'erreurs systématiquement et dupliquer les commandes si besoin.
• production SX9 :
  • Tout se passe bien, sauf exception, depuis les changements réseau du 2 août.
  • Note : On fait une grande partie des post-traitements de la SX9 sur curie, d'où la demande de relever la limite de 128 jobs.
  • Information : Arrêt de la SX9 le 14 décembre 2012
• production titane :
  • limite à 300 jobs pour les post-traitements. Très utile.
• démarrage de l'audit de la chaine de calcul : lot 3 de la prestation (travail entamé)