XtremWeb-HEP 7

• Corrections
  1. un bug corrigé dans la mis à jour des works;
  2. un bug corrigé dans la soumission des jobs.
• Nouvelles fonctionnalités
  • aucune

• Corrections
  1. l’utilisation des archives Zip refuse désormais les path commençant par ‘/’ ou contenant “../” (e.g. “/var/log/dummy.log” et “/home../var/log/dummy.log” sont remplacés par “dummy.log”);
  2. la génération des archives résultats par les workers n’ajoutent plus de “/” au début des noms des entrées compressés;
  3. afin d’éviter d’éventuels problèmes de compatibilité, les workers ne présentant pas la même version que le serveur ne recoivent plus de jobs.
• Nouvelles fonctionnalités
  • aucune

• Corrections
  1. les scripts sont compatible avec dash
  2. la suppression des données a été améliorée
  3. le paquet d’installation du bridge a été corrigé
• Nouvelles fonctionnalités
  • le URI passthrough pour EDGI JRA1

• Corrections
  1. compatible windows XP et 7 (Vista non testé)
  2. au niveau du serveur : les journaux d’accés sont maintenant dans le répertoire “HomeDir” tel que défini dans le fichier de config; un bug corrigé dans la gestion des groupes; les accès DB ont été améliorés
  3. les espaces inutiles sont automatiquement supprimés dans la ligne de commandes des jobs
  4. le protocole de communication a été amélioré afin que le client soit clairement informé des éventuelles erreurs côté serveur
  5. le protocole worker-serveur a été débuggé afin que le worker puisse prendre une décision en cas d’erreur FS côté serveur. Ceci existe depuis XtremWeb 1.6 (par l’INRIA) mais était buggé
  6. la GUI du client améliorée
  7. un trou de sécurité corrigé dans la suppression d’objet
  8. le serveur s’installe et fonctionne correctement sur Mac OS X. Il y a encore deux inconvénients : le serveur ne démarre pas automatiquement au boot de la machine et il tourne sous le compte “root”.
  9. Attic n’est plus pris en charge jusqu’à nouvel ordre: Attic peut crasher le worker sous certaines conditions.
• Nouvelle fonctionnalités
  • les connections clients peuvent être maintenant challengées si le client utilise un certificat X509.
  • le client accepte “–xwout” pour spécifier le fichier de sortie (avec xwresults et xwdownload)
  • le client peut maintenant obtenir les applications par leur nom et les utilisateurs par leur login

• Corrections
  1. worker, server: xtremwebconf.sh corrigé : ‘status’ est maintenant correctement pris en compte
  2. worker, server: au lancement, il n’y a plus l’affichage “ls: *.zip: No such file or directory”
  3. worker, server : les journaux sont maintenant dans /var/log
  4. server : un bug corrigé au niveau du cache DB
  5. client : un bug corrigé dans la commande xwversion
  6. client : un message est maintenant affiché si le fichier de conf est introuvable
  7. client : le fichier de conf n’est plus modifié car l’utilisateur s’y perdait
  8. les tables works et datas ont été modifiées pour être utilisable par le 3G bridge
  9. un bug corrigé dans la gestion des job de groupe
• Nouvelles fonctionnalités
  1. aucune

Cette version introduit des corrections et de nouvelles fonctionnalités qui permettent d’améliorer les performances.

Nous avons procédé à des tests sur Grid5000 avec 1 client et 1 server gérant plus de 2,000 workers.

Le temps nécessaire pour soumettre 10,000 jobs avec un seul fichier “macro” est réduit de 40% comme on le voit dans le graph suivant comparant XWHEP 7.3.2 et 7.4.0

Ce qui suit correspond à un run avec XWHEP 7.4.0

Le graph suivant montre les dates d’arrivée des jobs (en vert), les dates de prise en charge des jobs par les workers (en bleu) et les dates de complétions (en rouge).
La soumission des 10K jobs a pris moins de 30mn pour un temps d’exécution total de 45mn.

Le dernier graph montre un équililbrage de charge correct entre les 2323 workers.

• Corrections
  1. La couche de communication accepte désormais le mode “connecté”, en plus du mode non connecté déjà disponible dans les versions précédentes (et qui reste le mode par défaut). Le mode non connecté fait passer un seul message par socket; le mode connecté peut laisser passer jusqu’à deux milles messages par socket.

     Afin de protéger la plate-forme contre les attaques de type DoS, le serveur:

     • ferme automatiquement une socket après 2000 messages reçus (ceci est transparent pour le client fourni) [cela est visible sur la courbe verte sur le 1er graph : les paliers sont les temps de reconnexion au serveur après 2000 messages]
     • configure les sockets avec un SOTIMEOUT lu depuis son fichier de config
• Nouvelles fonctionnalités
  • le nombre de connections DB est configurable
  • introduction de SORETRIES (depuis le fichier de config) : nombre maximum de reconnexions sur socket error
  • introduction d’un “write through” cache devant la DB
  • introduction de pools de handlers TCP et DB pour réduire les malloc/dealloc

• Corrections
  1. un bug corrigé dans l’utilisation d’URL
• Nouvelles fonctionnalités
  1. aucune

• Corrections
  1. un bug corrigé dans l’utilisation d’URL
• Nouvelles fonctionnalités
  1. aucune

• Corrections
  1. un bug corrigé dans l’utilisation des proxys de communication
• Nouvelles fonctionnalités
  1. aucune

• Corrections
  1. un bug corrigé au niveau de la couche communication
  2. un bug corrigé dans l’utilisation des méta datas
• Nouvelles fonctionnalités
  1. on peut maintenant définir un proxy dans le fichier de configuration du client et du worker. Cette fonctionnalité permet d’agréger des ressource depuis Grid5000

• Corrections
  1. un bug au niveau de la gestion des jobs, introduit dans la 7.2.1, a été corrigé
• Nouvelles fonctionnalités
  1. aucune

Plus de détails dans Trac

• Corrections
  1. la remise à zéro de la base de donnees a été corrigée.
  2. au niveau du client, les droits d’accès s’affichent en octal.
• Nouvelles fonctionnalités
  1. aucune

1. il y a une erreur dans le script xwconfigure : la remise à zéro de la base de donnees ne s’exécute pas correctement,
   ce qui peut entrainer des erreurs dans l’utilisation de la plate-forme.
   Si vous voulez effacer la BD, faites le manuellement et relancez le script xwconfigure.

2. au niveau du client, les droits d’accès s’affichent en décimal et non pas en octal.

• Corrections
  1. xwconfigure corrigé
  2. le serveur gère maintenant correctement les erreurs SSL
  3. au niveau du client, l’utilisation des certificats X509 a été corrigé
• Nouvelles fonctionnalités
  1. gestion des jobs par batch pour EDGI/JRA2 SpeQuLoS

• Corrections
  1. le paquet RPM d’installation du serveur a été corrigé
• Nouvelles fonctionnalités
  1. aucune

• Corrections
  1. restauration de l’utilisation de hsqldb (http://hsqldb.org).
     hsqldb est une base de données relationnelle écrite en java.
     hsqldb est embarqué dans le server XWHEP.
     Ca n’a pas été testé en production, je ne peux donc rien dire quant à la mise à l’échelle et aux performances.
     L’embarquement de hsqldb permet des déploiements rapides et simplifiés.
     Ceci est particulièrement utile aux activités SA1 et SA2 du projet EDGI pour créer des distributions tout en un.
• Nouvelles fonctionnalités
  1. un nouveau script, make-distribs.sh, permet de générer plusieurs configurations

• Corrections
  1. les paquets d’installation du serveur ont été corrigés

• Corrections
  1. j’avais oublié de nettoyer le script xwconfigure script… c’est corrigé

• Corrections
  1. un bug corrigé au niveau du client quant à l’utilisation du parametre ‘–xwxml’
  2. le système de log a été réécrit
  3. un bug corrigé au niveau du cache
  4. le bridge DG->SG s’enregistre désormais correctement au niveau du serveur
  5. les utilisateurs STANDARD ne peuvent récupérer que leurs propres objets (works, datas…).

     Les privilèges ADVANCED sont désormais requis pour retrouver tous les objets.

     Ceci afiin d’améliorer la scalabilité en diminuant le nombre de communications non nécessaires.

  6. un bug corrigé au niveau du client : des problèmes pouvaient apparaitre si deux utilisateurs utilisaient le même fichier de config

     (e.g. ‘sudo xwworks’ followed by ‘xwworks’…)

  7. au niveau du worker, les problèmes d’accès concurentiels ont été corrigés.

     Le worker peut donc désormais exécuter plusieurs jobs simultanément.

     (min = 1; max = nombre de CPU détecgtés)

  8. le client GUI aété simplifié et corrigé
• Nouvelles fonctionnalités
  1. sous Mac OS X, le worker exécute désormais les jobs dans la sandbox de Apple.
  2. utilisation complète des certificates X509, en plus des login et mot de passe, toujours utilisables.

     La variable d’environnement X509_USER_PROXY doit être définie avant d’utiliser le client pour pouvoir se connecter avec un certificat X509.

     Les utilisateurs sont invité à utiliser jlite de Oleg Sukhoroslov (http://code.google.com/p/jlite) avec XtremWeb-HEP.

     La variable X509_USER_PROXY peut pointer vers un proxy ou un certificat X509.

     Cela ne fait aucune différence pour se connecter au serveur XtremWeb-HEP.

     Mais en utilisant un proxy X509 l’utilisateur peut gagner accès à des ressources de type EGEE.

     Ceci est transparent pour l’utilisateur. L’utilisation des ressources restant celui du “best effort”.

     La variable d’environnement X509_CERT_DIR doit être positionnée dans le fichier de config du serveur

     et pointer vers le répertoire des certificats des CA.

     Le serveur valide les certificats utilisateurs avec les chemins de certificats trouvés dans cette variable.

     Les certificats auto signés ne sont donc pas acceptés.

     Les utilisateurs avec des certificats X509 que le serveur peut valider sont automatiquement enregistrés avec des droits STANDARD;

     il n’est plus nécessaire de se faire préalablement enregistrer par un administrateur du serveur XtremWeb-HEP,

     comme c’est toujours le cas pour les utilisateurs n’ayant pas de certificat.

  3. introduction des tables _history afin d’améliorer l’utilisation de la DB en production;

     les éléments effacés sont copiés dans un table _history et effacés de la table production.

  4. introduction de nouveaux niveaux de log (FINEST, CONFIG) to decrease debug outputs (pour Gilles 😉 )
  5. en prévision de la nouvelle DG QoS, la DB enregistre désormais (mais ce n’est pas encore utilisé)
     • montant des jobs pending, running et error par application
     • montant des jobs pending, running et error par worker
     • montant des jobs pending, running et error par utilisateur
     • usedcputime par utilisateur
     • webpage par application
     • webpage par usergroup
  6. de nouvelles colonnes dans la table hosts
     • totaltmp : espace total dans la partition utilisée par le worker
     • freetmp : espace disponible dans la partition utilisée par le worker
     • poolworksize : nombre de jobs que le worker peut exécuter simultanément
     • sgid : Service Grid Identifier. Ceci obsolète le champ pilotjob (même si c’est toujours utilisé pour le moment).

       Ceci est automatiquement positionné par le worker grâce à la variable “GLITE_WMS_JOBID” si elle existe.

  7. le client accepts un nouveau paramètre : “–xwshell” qui place le client en mode daemon.

     Ce daemon accepte des communications entrantes sur le port 4327 et les forwarde au serveur (et retourne les réponses).

     Ceci afin d’améliorer les performances, notamment celle du bridge.

  8. worker.accessrights reflète le confinement
     • un worker public a désormais 0X755
     • un worker de groupe a désormais 0X750
     • un worker privé a désormais 0X700
  9. une nouvelle interface REST. On peut se conencter au serveur avec HTTPS. Exemple:
     
     Pour récupérer les UID des works
     http://an_xwhep_server/?xwcommand=

     Ceci retourne:

     ...

     Pour récupérer un work donné
     http://an_xwhep_server/?xwcommand=

     On obtient:

  10. introduction de Intel itanium pour linux