Titre du livrable : Rapport sur le support plate-forme FAME2 avec indices de disponibilité (période 2006).

Transcription

1 Titre du livrable : Rapport sur le support plate-forme FAME2 avec indices de disponibilité (période 2006). Partenaire émetteur : Bull Auteur : Guy Hiot Date : 3 Janvier /1

2 Table des matières 1 La maquette Fame Eléments constitutifs de la maquette Cluster HPC Fame Interconnect Architecture d E/S Choix des sous-systèmes disque Cartes accélératrices Schéma global du cluster Fame Accès réseau Structure réseau d accueil des partenaires de Fame Gestion des demandes de Connexions à Fame Gestion des utilisateurs Administration système Règles d accès aux nœuds de calcul Accès aux fichiers et aux ressources Packaging en armoires Calendrier de mise en place Installation du cluster Fame Installation du matériel Mise en place de l administration du cluster Les compilateurs Intel Les débogueurs Bibliothèques de communication Système de fichier Lustre Outils divers Outil de mesure des compteurs hardware : pfmon Autres outils de performance Visualisation de l activité du cluster Installation du nœud CEA pour les tests Clearspeed Tests de validation de la plate-forme Objectifs de l outil Valtera Test du cluster Fame Tests de validation des connexions réseau Indice de disponibilité de la plate-forme FAME /2

3 1 La maquette Fame2 L objectif de la maquette est, en 2006, de mettre à disposition des partenaires de Fame2 et des projets associés (tels que PARA) une configuration de test composée de serveurs hébergeant des processeurs Intel Montecito double cœurs. Cette maquette est destinée à permettre aux partenaires de se familiariser avec les dernières versions de processeurs Intel, d analyser leur comportement et d anticiper les performances atteignables avec les futurs serveurs développés dans le cadre de la convention Fame2. Cette maquette est située dans les locaux de Bull aux Clayes sous Bois, dans le département des Yvelines. Elle a aussi pour vocation de servir de vitrine technologique et, dans cette perspective, à être utilisée pour la réalisation de grands challenges nécessitant une puissance de calcul élevée. 2 Eléments constitutifs de la maquette 2.1 Cluster HPC Fame2 Fin 2006, le cluster Fame2 est composé des équipements suivants: Un serveur NovaScale 5165 doté de deux modules (soit 2x8 sockets destinés à recevoir des processeurs Montecito double cœur) et 128 GB de mémoire. Ce serveur peut donc être équipé de 16 processeurs physiques et peut être configuré de 1 à 4 domaines (4 nœuds de calcul). Huit serveurs NovaScale 3045 quadri-processeurs de la génération suivante, équipés de bus PCI-Express. Ces serveurs constituent 8 nœuds de calcul. Un serveur NovaScale 4040 utilisé comme nœud de Management du cluster. Le nom du cluster, reflété dans la base d administration, est fmd. Un serveur NovaScale 5085 mono-module utilisé comme nœud d entréesortie. Ce serveur est utilisé, selon les demandes, comme serveur de fichiers Lustre ou comme serveur NFS V4. Ce serveur est connecté à un espace disque utile de 50 Téraoctets. Un Switch 3COM de 24 ports utilisé pour constituer un réseau d interconnexion gigabit Ethernet privé au cluster Fmd. Un interconnect Quadrix mono-rail. Cet équipement est destiné à réaliser une interconnexion à haut débit entre les nœuds de calcul et le nœud d entréesortie 3/3

4 Un interconnect Port server interconnectant par des liens série les différents équipements à des fins de maintenance. Ce cluster héberge également un serveur prototype investi par le CEA à base d un module NovaScale (2 QBB, 4 processeurs Montecito), avec opérateurs programmables. 2.2 Interconnect On envisage de tester plusieurs types d interconnexion dans le cadre de Fame2. Le réseau Gigabit Ethernet est utilisé avec NFS V4, réputé amener des gains de performances significatifs en comparaison avec la version V3 surtout lors de la manipulation de beaucoup de fichiers de petites tailles. Ce type d interconnexion offre l avantage d être beaucoup moins coûteux qu une solution à base de Quadrix. Un deuxième type d interconnexion est réalisé à base de Quadrix avec des cartes Elan4 pour bus PCI-X. Une alternative Infiniband est investiguée par Bull à Echirolles et Phoenix. Les fournisseurs potentiels sont : Cisco/Topspin, Mellanox et Voltaire. Phoenix a présélectionné Cisco/Topspin. Un fournisseur potentiel est QLogic/PathScale avec le produit InfiniPath. Infiniband par rapport à Quadrix est environ deux fois moins cher (cartes et switch) mais les temps de latence sont plus élevés. 2.3 Architecture d E/S Choix des sous-systèmes disque L engagement de Bull pour Fame2 est de fournir l accès à au moins 20 Téraoctets d espace disque, notamment pour permettre d implanter et tester une grosse base multimédia. Le choix a été fait d offrir 50 Téraoctets utiles et de tester la scalabilité et les temps de réponse avec une base de 10, 20 et 40 Téraoctets. Nous avons choisi de mettre en place un serveur NovaScale avec 8 processeurs Montecito comme nœud d entrée/sortie. Cette configuration multi-processeurs devrait permettre de gérer efficacement la multitude de petites trames IP générées dans le cas où on utilise NFS V4. Quand ce nœud est configuré avec Lustre, 8 cœurs sont dédiés à MDS (serveur de métadonnées) et 8 cœurs à OSS (serveur de données). La configurabilité du bus E/S d un tel serveur est également idéale pour permettre d implanter tous les HBA fibre et les cartes télécommunication nécessaires pour obtenir une configuration équilibrée (entre les accès fibre vers les disques d un côté et les interconnects entre nœuds de calcul de l autre). Deux raisons importantes conduisent au choix d'un sous-système offrant la fonction RAID 5 et des caches importants au niveau contrôleur d E/S (SP : Storage Processor): 4/4

5 d'une part la taille importante ( 40 TB) de base de donnée visée et le long temps de chargement associé impliquent de sécuriser les données par la technologie RAID afin d éviter d'avoir à recharger la base à la suite d'un incident matériel simple (perte d'un disque physique) d'autre part le nombre très important de petits fichiers manipulés lors des différents accès impose de disposer de gros caches au niveau des SP afin d'optimiser les temps d'accès en exploitant une bonne localité Le choix a été fait de deux sous-systèmes FDA 2500, chacun équipé de 105 disques de 300 GB, d un cache de 8 GB et de deux SP. Chaque SP peut être accédé depuis le nœud d E/S via 4 ports FC 4 Gbits, ce qui offre une bande passante théorique de 2 Gigaoctets par seconde par FDA, soit 4 Gigaoctets par seconde en tout. En pratique, la bande passante effective est inférieure et limitée par l architecture intrinsèque des sous-systèmes (le backend est réalisé en 2 Gigaoctets/s). 2.4 Cartes accélératrices La maquette Fame2 est également utilisée pour expérimenter des cartes accélératrices programmables. Un premier type de cartes testé est la carte Clearspeed sur bus PCI-X. Le prototype CEA, évoqué plus haut, est utilisé à cet effet. Ultérieurement, il est envisagé de tester des cartes sur bus PCI-Express. 5/5

6 3 Schéma global du cluster Fame2 NS5165 (4 computing nodes) 16 Montecito (32 cores), 128 GB, 4 IOC, N1 N2 N3 N4 F8 F7 F6 F5 F4 8 computing nodes of new generation (NS3045) F3 F2 F1 Gb Ethernet Network accesses Configuration fin 2006 NS5165 equipped with Clearspeed cards Switch 3COM (24 ports) Quadrics (16 ports) NS5085 (I/O Node) 8 Montecito (16 cores) NFS-V4 64 GB, 2 IOC Lustre MDS/OS NS4040 Mgt Node (4 Montecito) Comprehensive administration environment from a single point of control. F I R E W A L L FDA 2500 (25 TB) FDA 2500 (25 TB) 4 Accès réseau Tous les partenaires accèdent la maquette Fame2 à travers Internet. 4.1 Structure réseau d accueil des partenaires de Fame2 L architecture réseau mise en place est la suivante : 6/6

7 SERVEUR FAME2 Internet Transpac concentrateurs Cisco connexion bullnet connexion internet direct filtrée connexion vpn client In t ran e t Bu ll Le choix a été fait d utiliser autant que possible des connexions VPN sécurisées. Connexions VPN : Un double login réseau est demandé à tous les utilisateurs VPN : le premier est commun et correspond au projet Fame2, le deuxième est propre à chaque partenaire et autorise 4 connexions simultanées. L intérêt de ce choix, outre l isolation de la connexion dans un tunnel et la sécurité apportée par le cryptage des échanges, est que les abonnements VPN affectés aux partenaires peuvent être utilisés à leur guise par différentes personnes chez ce partenaire sans que Bull ait à connaître leurs adresses IP individualisées. Le cas échéant, Bull fournit le client VPN Cisco si le partenaire en fait la demande. Dans certains cas, une liaison VPN site à site pourra être mise en place entre un partenaire et Bull : c est l architecture recommandée par Bull pour les liaisons avec des partenaires industriels. 7/7

8 Les serveurs VPN N mutualisés de Bull sont utilisés pour accueillir les connexions. Celles-ci sont ensuite acheminées vers le réseau privé Fame2 (DMZ) à travers un parefeu et deux switches à 100 Mbits. L utilisation de pare-feu permet d éviter les rebondissements intrusifs vers le réseau Bullnet. Les droits d accès à la plate-forme Fame2 proprement dite sont ensuite gérés individuellement au niveau de l administration de Fame2. Connexions SSH directes filtrées : La mise en place de connexion VPN posant problème chez certains partenaires à cause de leur architecture réseau et leurs règles de sécurité, on autorise également des connexions SSH directes. Ces connexions, by-passant les serveurs d accès VPN, ont besoin d être identifiées nominativement au niveau du pare-feu d accès de Bull. Les utilisateurs désireux de travailler dans ce mode doivent alors décliner leur adresse IP source. Un délai de plusieurs jours est alors nécessaire pour que France Télécom ajoute sélectivement une nouvelle règle d accès au niveau du pare-feu. 4.2 Gestion des demandes de Connexions à Fame2 Toutes les demandes de connexion à Fame2 sont faites en utilisant un formulaire qui a été communiqué à tous les partenaires en mars 2006 et est réactualisé en août Les partenaires doivent préciser s ils désirent accéder le cluster Fame2 proprement dit ou le nœud CEA (fmd-cea). Le temps alloué est au niveau de la semaine, les demandes sont à faire parvenir le jeudi soir au plus tard pour la semaine suivante. 4.3 Gestion des utilisateurs Administration système Le projet Fame2 accepte des demandes de connexions des partenaires de Fame2, mais également des projets associés : PARA, NUMASIS et CHOC. La confidentialité entre partenaires et entre projets est assurée par utilisation des droits d accès du système Règles d accès aux nœuds de calcul C est PCC (Centre de Calcul de Bull aux Clayes sous Bois) qui possède les droits root et administre l ensemble des ressources du cluster. A la réception de la demande d accès d un nouvel utilisateur autorisé pour Fame2, un compte utilisateur et de l espace disque lui est alloué. Les comptes créés sont nominatifs et propres à un partenaire. 8/8

9 Chaque utilisateur est associé à un groupe qui correspond à la société partenaire (CEA, UVSQ, IFP,...). Comptes utilisateurs et groupes sont configurés par PCC au niveau de l'administration du cluster fame2. Les nœuds de calcul sont groupés dans des partitions disjointes: une partition (au sens RMS Quadrics) c'est de 1 à N nœuds. PCC fait évoluer la configuration des partitions en fonction des demandes formulées par l ensemble des utilisateurs. Les utilisateurs soumettent leurs travaux dans telle ou telle partition à l'aide de la commande PRUN en précisant éventuellement le nombre de nœuds ou le nombre de processeurs qu'ils veulent utiliser au sein de la partition. Une partition n'a pas de granularité plus fine qu'un nœud: en particulier, une partition ne peut pas être définie comme un ou plusieurs processeurs. Pour la maquette Fame2 des Clayes, les nœuds sont des domaines (au sens PAM) de NovaScale (1 domaine = 1 QBB + 1 IOR). Toutes les connexions réseau à Fame2 aboutissent d abord sur le nœud de management. Cette centralisation des accès permet aux administrateurs, le cas échéant, d interdire certains accès dans le cadre de la politique d accès en vigueur. Si la connexion est validée pour la période considérée, le routage est alors effectué vers les ressources (nœuds de calcul) affectées ou autorisées pour cet utilisateur Accès aux fichiers et aux ressources Les fichiers sont créés pour un utilisateur donné sous son répertoire d accueil (home_nfs). Certains peuvent être définis comme accessibles par les autres utilisateurs du même groupe. Mais il y a étanchéité entre les groupes: un groupe ne peut pas accéder les fichiers des autres groupes. Cependant, les utilisateurs d'un groupe peuvent lister les répertoires d accueil (home directory) des autres groupes, même s'ils ne peuvent pas y accéder. Les utilisateurs créent leurs fichiers dans leur home directory. Ils peuvent demander à PCC que ces fichiers soient sauvegardés. Ces sauvegardes sont actuellement gérées manuellement sur LTO. PCC va étudier comment les automatiser. Pour Fame2, on utilise également le système de fichier parallélisé Lustre. Plusieurs instances de Lustre (plusieurs filesystems) ont été créées pour isoler l'espace affecté aux utilisateurs (home_lustre) de l'espace utilisé pour les expérimentations Xedix. A titre expérimental et après avoir recueilli l avis des partenaires, on a également mis en place, dans la période septembre-octobre 2006, le logiciel Synfiniway de Fujitsu dont la vocation est d administrer globalement et de façon transparente l ensemble des ressources réparties sur plusieurs serveurs. Synfiniway virtualise les ressources physiques que les utilisateurs accèdent à travers une interface standardisée (simple accès Web utilisé pour lancer et contrôler leurs chaînes de travaux). 9/9

10 Le 19 octobre 2006, les modules client Synfiniway, pour Windows et Linux-Unix, ont été mis à disposition des partenaires sur un serveur FTP. 10/10

11 5 Packaging en armoires La répartition des éléments de la maquette dans les différentes armoires est la suivante : NS3045 NS3045 NS3045 NS3045 NS3045 (fmd13) nœud de calcul (2 montecito) (fmd12) nœud de calcul (2 montecito) FDA 2500 NS 5085 (fmd5) nœud d'i/o (8 montecito, 32 GB mem) KVM 24 (fmd11) PAP 23 nœud de 22 calcul (2 console montecito) PAP (fmd10) KVM 19 nœud de ecr/clav/sou KVM 18 calcul (2 PAP montecito) 17 Fmd4 16 (fmd9) nœud de mngt 15 nœud de contrôleur (4 montecito) 14 calcul (2 montecito) 13 LTO Fmd3 12 nœud de calcul 11 (4 montecito) NS3045 NS3045 NS3045 (fmd8) nœud de calcul (2 montecito) (fmd7) nœud de calcul (2 montecito) (fmd6) nœud de calcul (2 montecito) NS4040 (fmd0) nœud de management (4 montecito) switch 3COM Port Serveur switch QsNet NS 5165 bi-module avec 4 domaines fmd2 nœud de calcul (4 montecito) Fmd1 nœud d'i/o provisoire (4 montecito) Plat. de cabl. FDA2500 contrôleur NS mono-module standalone- (CEA) fmd-cea nœud standalone (4 montecito) 6 Calendrier de mise en place La maquette Fame2 des Clayes sous Bois, à base de processeurs Montecito, est déployée en plusieurs étapes : 11/11

12 Première étape (juin 2006) : Deux nœuds de calcul Un nœud de management Un nœud d entrée-sortie hébergeant le système de fichier Lustre et connecté à 25 Téraoctets d espace disque sécurisé en RAID 5 Le serveur prototype du CEA équipé de Clearspeed Plusieurs réseaux d interconnexion : Gigabit Ethernet, liens série et Quadrix Mise en place des accès VPN pour les partenaires Mise en place de l administration du cluster Deuxième étape (septembre 2006) : 25 Téraoctets d espace disque supplémentaire Deux nœuds de calcul supplémentaires Troisième étape (4 ème trimestre 2006) : Huit nœuds de calcul (de nouvelle génération) supplémentaires 7 Installation du cluster Fame2 7.1 Installation du matériel La mise en place de la configuration initiale s est déroulée à partir de mai Elle a commencé avec la livraison le 9 mai du premier système NovaScale bi-module. La livraison du 2 ème NovaScale (nœud d E/S) ayant été reportée à juillet, on a demandé de faire livrer isolément l armoire faisant partie de cette commande afin de pouvoir y installer le FDA. 27 juin : Recette par le CEA de leur serveur équipé de cartes Clearspeed. En juin, configuration du premier sous-système disque FDA. Le FDA est configuré pour que 1 Téraoctets soit utilisé par les répertoires d'accueil des utilisateurs et 25 Téraoctets gérés par le système de fichiers Lustre. En parallèle, mise en place de l interconnect Quadrics, du réseau gigabit Ethernet et des liens série. En octobre, réception du complément de la configuration Fame2. Il s agit de la 2 ème partie de la configuration disque (pour passer de 25 à 50 TB) et de huit serveurs NovaScale Plusieurs problèmes matériels ont retardé la mise à disposition de l ensemble du cluster. Citons notamment une carte contrôleur du premier FDA, le module central du nœud d entrée-sortie, la carte mère d un serveur NovaScale 3045 et une connecteur du Quadrix. Pour chaque incident, un palliatif a été appliqué permettant de préserver l accès des partenaires à la partie opérationnelle de la configuration. Toutefois, début décembre 2006, l ensemble des éléments est opérationnel. 12/12

13 7.2 Mise en place de l administration du cluster Plusieurs itérations sont nécessaires avec les équipes Bull d Echirolles pour faire créer la base d administration (clusterdb) du cluster Fame2 dans un état satisfaisant et correspondant à la version souhaitée de l OS (BAS4 V4.2). Des modifications, non standard en version BAS4 V2, sont faites dans la clusterdb pour Fame2 (notamment pour accepter des partitions de NovaScale comme nœuds de calcul). On finit d installer le nœud de management et de déployer l image sur l autre nœud de calcul (avec Ksis) et le nœud provisoire d entrée-sortie. Une difficulté venait des labels des disques internes du NovaScale (MS/DOS au lieu de GPT) qui n étaient pas conformes pour IA64. Création des comptes pour les développeurs de l équipe de développement Bull de Florence Vallée puis création progressive des comptes des partenaires émettant des demandes de connexion. Passage à la version d OS BAS4 V4.3 en octobre Cette version amène notamment le support des nouveaux serveurs NovaScale Les compilateurs Intel La dernière version des compilateurs d Intel a été installée sur le cluster FAME2 : - version du compilateur C, - version du compilateur Fortran. 7.4 Les débogueurs Deux débogueurs sont installés sur le cluster FAME2. Le premier (gdb) est livré avec la distribution. Le second (idb) est installé en même temps que les compilateurs Intel. 7.5 Bibliothèques de communication Sur le cluster Fame2 est installée la dernière version de la librairie MPI (version 1.5.5) incorporant les dernières optimisations développées par l équipe MPI Bull. La distribution MPI est fondée sur la bibliothèque MPICH. L usage de la bibliothèque MPI Bull ne nécessite pas de modification des codes ni de configuration particulière. Les scripts de compilation mpicc (pour les codes C et C++), mpif90 et mpif77 sont disponibles. Le lancement des applicatifs se fait via la commande prun. 13/13

14 7.6 Système de fichier Lustre Lustre est un système de fichier distribué haute performance conçu pour répondre aux besoins des grands clusters de calcul. Lustre est un produit Open Source (sous licence GPL) maintenu par Bull. Lustre tire pleinement parti du réseau QsnetII puisque les communications concernant aussi bien les métadonnées que les données passent par cet interconnect à haut débit et très faible latence. Configuration du système de fichier Lustre sur les deux nœuds de calcul. Au cours de la mise en œuvre du système de fichiers Lustre, il s'avère qu'il est impossible de le monter sur un des nœuds. Après investigations, un problème hardware sur la carte Quadrics de ce nœud est détecté. 7.7 Outils divers Outil de mesure des compteurs hardware : pfmon Pfmon permet d accéder aux registres de performance de l Itanium 2, la Performance Monitoring Unit (PMU) de l architecture IA 64 et ainsi de caractériser une charge en vue d identifier des goulots d étranglement. L outil pfmon gère tous les évènements de l Itanium 2. La commande «pfmon show-events» en visualise environ Autres outils de performance Bull a développé un outil (pfb) qui est un complément au pfmon standard. Cet outil est incorporé dans l outil top pfb pour la mesure de la bande passante et le taux de localisation de la mémoire en fonction des QBBs. L usage de top_pfb se fait de la même manière que l outil standard top (montrant l utilisation des ressources système et toujours disponible sur nos machines) Visualisation de l activité du cluster L outil Ganglia est utilisé à cet effet. C est un outil de supervision, permettant de connaître l activité (CPU, mémoire, réseau,..) de l ensemble des systèmes constituant le cluster. Ces informations sont données sous forme graphique et sont consultables immédiatement ou à l heure, mais aussi à la journée, au mois et à l année. Exemples de vue : 14/14

15 15/15

16 7.8 Installation du nœud CEA pour les tests Clearspeed Réception du NovaScale 5085 mono-module du CEA le 1 er juin On remarque un problème d'adéquation du matériel. Le clavier et la souris livrés sont en connexion USB alors que le branchement sur le KVM doit être en PS2. Du matériel adapté est utilisé pour résoudre le problème. Le serveur est configuré en un seul domaine regroupant les 4 processeurs Montecito dual-core du module avec suppression de la fonction multithreading. Installation du système d'exploitation Linux HPC BAS4 V2 en mode 'standalone'. Installation des logiciels Intel: compilateur C++; compilateur Fortran, l'outil Trace Analyseur, les librairies MKL et IPP avec des licences d'évaluation. Préparation de l'environnement pour la recette des cartes ClearSpeed sur la machine du CEA: Le NovaScale 5085 est configuré avec une seule QBB, une seule IOC et sans la fonction multithreading. Installation provisoire d'un serveur IA32 sur lequel sont installés le système Linux RedHat AS4 et le logiciel SDK. Configuration provisoire du réseau pour qu'une personne des études à Echirolles, participant à la recette, puisse préparer l'environnement pour la recette ClearSpeed. La recette ClearSpeed a lieu à la date prévue le 27 juin Intégration du NovaScale du CEA dans le cluster Fame2 dans le but de faciliter l'administration des systèmes. Tous les comptes utilisateurs sont regroupés sur le nœud de management du cluster qui est vu comme un nœud d'accueil. Les comptes des utilisateurs pour ClearSpeed sont reproduits sur le NovaScale du CEA. Installation des licences permanentes pour les logiciels Intel. Préparation de l'environnement pour la formation à l'utilisation des cartes ClearSpeed donnée du 19 au 21 juillet par le producteur (Clearspeed UK): Un serveur frontal IA32 est installé sur lequel est installé le système Linux RedHat AS4 ainsi que le logiciel SDK (qui n est pas encore disponible sur plate-forme IA64) avec demande de licence permanente. Des licences temporaires SDK sont obtenues pour cette formation. Création, pour les participants, de 16 comptes d'accès provisoire au NovaScale du CEA (fmd-cea) et au serveur IA32 (fmd-cea2). Réception d'une licence permanente pour le SDK Clearspeed le 28 juillet Mise en œuvre le 3 août. 16/16

17 8 Tests de validation de la plate-forme Des tests préliminaires mettent en évidence un problème de désynchronisation d'horloge sur un des nœuds du cluster Fame2. Ce problème, déjà connu, a conduit à une mise à jour du bios. Des tests visant à contrôler la bonne installation des logiciels pour HPC sont prévus en utilisant un outil de validation développé par Bull (Valtera). 8.1 Objectifs de l outil Valtera L objectif de Valtera est de vérifier la bonne installation de tous les produits qui doivent être présents sur chaque nœud d une machine correspondant à l offre HPC et, en particulier, l environnement de programmation parallèle. Cet outil permet de valider la cohérence et le bon fonctionnement de la distribution HPC BAS sur l ensemble des nœuds du Cluster. Dans un premier temps, l outil Valtera, permet de vérifier que le produit MPI et l environnement de programmation qui lui est nécessaire sont correctement installés. Il vise en particulier les objectifs suivants : vérifier la présence de tous les outils de développement prévus vérifier la cohérence de l environnement de compilation et d édition des liens (compilateurs GNU ou Intel, en langage C/C++ ou Fortran, avec et sans optimisation) vérifier la présence des bibliothèques incluses dans l offre HPC (MKL, MPI, PVM, ) vérifier la cohérence de l environnement pour l utilisation des outils débogueurs fournis en standard vérifier l installation des outils d analyse de performance inclus dans l offre HPC cet outil, fortement dépendant des outils qu il teste, est facilement modifiable pour s adapter aux nouvelles distributions HPC (TERA10, Fame2 et autres). Valtera suppose que sur le cluster la distribution HPC BAS a été installée telle que décrite dans le document «HPC Bas4 Installation & Configuration Guide». 8.2 Test du cluster Fame2 Il s agit de tester la présence opérationnelle des logiciels installés sur le cluster Fame2 de machines NovaScale conformément à la documentation «HPC Bas4 17/17

18 Installation and Configuration Guide» définis dans le cadre de l offre HPC de BULL. L exécution du test complet se fait sur une machine de référence (FMD0 par exemple) pour un état technique de livraison défini. Cette exécution est totalement automatisée (paramètres intégrés), elle sert de base à toute campagne de test de non régression ultérieure pour cette version de la livraison. Ces tests (environ 100) sont composés de «scripts» en «bash» : les «scripts» de chaque test unitaire et les «scripts» d initialisation et de gestion de l ensemble du produit. Pour les besoins de test, des fichiers source, correspondant à chacun des langages supportés, sont associés au produit. L exécution de VALTERA génère un fichier de «log» et, éventuellement, un fichier résultat. Une fois l installation faite sur le nœud d administration du Cluster et le produit VALTERA convenablement configuré en renseignant ces variables, la phase d activités principales est lancée par activation du «script» de lancement («TR442» par exemple pour la livraison HPC Bas4 v4.2) sur la console (locale ou distante par liaison «ssh»). Ensuite, la tâche de l opérateur se réduit, éventuellement, à la lecture des diagnostics : il n y a aucune intervention à effectuer. Si le fichier de rapport d exécution a été demandé, il pourra être consulté ou recopié à la fin du traitement (édition d une bannière de fin). De manière automatique, les tests s exécutent en premier lieu sur le nœud d administration (compilation sur ce nœud, et exécution sur ce nœud par «prun» [ou «bullprun»] (mode distribué)). Puis, quelque soit le premier diagnostic, les tests sont exécutés, sur le nœud de référence (choisi à l installation et renseigné dans une variable interne globale, les tests sont lancés par «pdsh w»). En interne, par exemple, le nœud d administration est nommé «fmd0» et le nœud de référence est nommé «fmd1», les nœuds de calcul et d Entrées/Sorties allant de «fmd1» à «fmd4». Dans un troisième temps, les tests sont lancés, sur l ensemble du Cluster, à partir du nœud d administration, afin de valider tous les nœuds indépendamment de leur type. Le déploiement, par famille de tests, est réalisé par «pdsh a» (transmission du «script» de lancement de chaque famille à tous les nœuds définis dans le fichier système de configuration construit à l installation du Cluster), mais le lancement de l exécutable, dans chaque test, est toujours fait par «prun» sur le nœud en cours. Dans ce dernier cas, pour éviter toute concurrence d accès à un même fichier, avant d être exécuté, chaque «script» est copié dans une bibliothèque privée à chaque nœud. Un «script» intermédiaire crée cette bibliothèque et effectue la copie à partir du répertoire partagé. 18/18

19 Le lancement se faisant par famille de tests, chaque famille est lancée, sur chaque nœud du Cluster, par le «scheduler» RMS, séquentiellement de manière asynchrone, mais la famille de tests suivante ne sera lancée que lorsque tous les nœuds auront terminé l exécution du dernier test de la famille en cours. Un fichier de «log» est systématiquement constitué, il comporte le nom de tous les tests en erreur. 8.3 Tests de validation des connexions réseau La mise en place et les tests des accès réseau pour les partenaires se sont faits selon les étapes suivantes : Etablissement d une connexion réseau temporaire vers le serveur du CEA (fmdcea) afin de préparer la recette de ce nœud. Mise en place par les services d Expertel du switch matérialisant la DMZ Fame2 et permettant le raccordement au serveur VPN de Bull et au pare-feu. Toutefois, le raccordement au serveur VPN d établissement ne sera pas réalisé tout de suite car cette demande de travail doit s inscrire dans le déploiement du projet DEVO2 de transfert aux Clayes de la structure d accueil du réseau Bull. Le responsable Sécurité réseau de Bull fait savoir qu il n est pas d accord avec l approche d avoir un seul compte banalisé pour tous les utilisateurs de Fame2 et il exige d établir et de gérer des logins différentiés. Il fait créer quatre premiers comptes virtuels dans l annuaire de Bull et demande à France Télécom de créer les abonnements VPN correspondants afin de permettre de démarrer les tests rapidement. France Télécom nous fait parvenir les quatre premiers abonnements ainsi que les informations (adresse IP du serveur VPN, nom et mot de passe du groupe Fame2, etc ) permettant de faire les premiers tests. Nous sollicitons le CEA et UVSQ pour être candidats à tester la liaison VPN vers la maquette Fame2. Tous deux répondent positivement. Obtention des clients VPN pour Windows et Linux et premier test de connexion VPN réalisé aux Clayes avec l aide de France Télécom (Mr Fosse). France Télécom nous a communiqué l url d un site Web permettant de modifier les mots de passe associés aux abonnements. Toutefois, la procédure ne fonctionne pas. Apparemment, ceci est dû au fait que les abonnements créés par France Télécom concernent des utilisateurs externes à Bull qui ne sont pas connus au niveau du serveur Radius qui gère les authentifications. Une solution est demandée à France Télécom via notre correspondant Stéphane Dulong. La Sécurité Bull nous demande des informations complémentaires pour paramétrer le pare-feu. Nous disposons d un document relatif à la mise en œuvre du «client VPN» pour Windows. Par contre, nous manquons d informations pour la configuration et la mise en œuvre du «client VPN» Linux. Estimant que nous ne sommes pas 19/19

20 encore tout à fait prêts, nous notifions le CEA et l UVSQ que les premiers tests auront lieu un peu plus tard que prévu. Envoi du client VPN Linux au CEA. La première connexion est effectuée le 19 juillet au serveur VPN des Clayes. Mais, pour cela, le CEA a été obligé de créer un poste de travail à Ter@tec, isolé de leur réseau Ocre. Ne trouvant pas cela commode, le CEA demande une entrevue avec les responsables sécurité réseau de Bull. Elle conclut que, pour le court terme, le stagiaire du CEA ayant à travailler sur les cartes accélératrices utilisera le client VPN dans la zone Ter@tec, mais on ouvrira des sessions SSH pour tous les autres utilisateurs du CEA afin qu ils puissent accéder à Fame2 depuis leurs stations connectées à leur réseau Ocre. On demande à France Télécom, au niveau du pare-feu, d ouvrir les accès SSH pour le réseau Ocre du CEA en attendant l établissement à moyen terme d une liaison VPN site à site entre le CEA et Bull. On doit maintenant fournir le client VPN à Mr Acquaviva de l UVSQ. Mais on attend d abord que France Télécom ait mis en place les nouveaux mots de passe qu on leur a demandés. Le 21 juillet, Bertrand Meltz du CEA nous envoie la liste des comptes à créer correspondant aux utilisateurs du CEA ayant besoin d accéder le nœud CEA Clearspeed (fmd-cea). Résolution des questions relatives aux licences (caractère temporaire/permanent) des licences des logiciels et compilateurs installés. Christine Baste apporte un contournement au problème de licence compilateur C++ permettant aux utilisateurs d y accéder au-delà du 27 juillet. Elle règle avec Pierre Michelin le problème des licences des différents logiciels impliqués dans le contrat avec le CEA. Demande à France Télécom de restaurer les accès SSH à Fame2 pour Bull qui ont été supprimés par erreur par France Télécom lors de la reconfiguration du pare-feu. Connexion VPN testée et OK pour Henri-Pierre Charles (UVSQ) après qu il ait demandé une action au niveau de la configuration du routeur de l Université (ouverture du port 500) pour accéder à fmd-cea et fmd-cea2. France Télécom notifie Bull que les accès directs ssh pour le CEA ont été mis en place au niveau du pare-feu et nous demande de valider que les connexions s établissent sans problème. Une erreur de paramétrage est détectée. France Télécom doit modifier le paramétrage du pare-feu, ce qui permet à nouveau les connexions ssh à Fame2 depuis l intranet Bull. Christine Baste valide que chacun des réseaux Bull candidat à accéder Fame2 arrive bien à se connecter et le confirme à France Télécom. 26 juillet : Didier Courtaud demande un accès SSH générique pour les tests Xedix. C est mis en place le 28 juillet. 28 juillet : Christine notifie Bertrand Meltz que les comptes permettant au CEA d accéder les nœuds fmd-cea et fmd-cea2 pour les tests Clearspeed sont créés. 20/20

21 Elle envoie également toutes les informations à Stéphane Réquéna (IFP) lui permettant de se connecter en VPN. 2 août : Pour la 1 ère fois, le CEA (Didier Courtaud, puis Bertrand Meltz) cherche à se connecter directement en ssh depuis leur réseau Ocre. Les tentatives de connexion échouent. Après contact avec France Télécom, il apparaît que les dysfonctionnements viennent du fait que le pare-feu a été paramétré pour des liaisons VPN avec Ocre. Le 2 août en soirée, Pierre Brochard nous notifie qu il arrive maintenant à se connecter. Les premières connexions des partenaires à Fame2 sont donc effectives début août Demande de 25 abonnements VPN à France Télécom pour permettre de satisfaire les futures demandes des partenaires. Tenant compte du retour d expérience et des difficultés rencontrées avec la technique du client VPN par les premiers utilisateurs, on convient en septembre de généraliser les connexions ssh directes (avec filtrage des adresses IP) pour la plupart des partenaires. 9 Indice de disponibilité de la plate-forme FAME2 Les accès réseau à la première partie le la maquette Fame2 ont été ouverts en août 2006 aux partenaires. En 2006, la maquette des Clayes a donc été mise à disposition pendant 5 mois. Deux arrêts ont eu lieu durant cette période : un arrêt programmé en octobre (3 jours d interruption), pour changer de version d'os (migration en BAS4 V4.3), mettre en service un nouveau nœud de management et huit nouveaux nœuds de calcul un arrêt non voulu (3 jours d interruption), dû à une coupure d alimentation électrique prenant son origine dans un problème de climatisation. L indice de disponibilité de la plate-forme a donc été de 98 % durant la période. 21/21