A new version of the middleware : XtremWeb-HEP 7.6.0
Month: September 2011
XtremWeb-7.6.0 publié
Une nouvelle version publiée : XtremWeb-HEP 7.6.0
XtremWeb-HEP 7
Documentation
The documentation is available here.
Bug tracking
You can glance at our trac server.
Versions
- Dec 12th, 2011 : XWHEP 7.6.4
- Corrections
- a bug corrected on work update (e.g. on completion)
- a bug corrected on submission
- New features
- none
- Corrections
- Oct 22nd, 2011 : XWHEP 7.6.3
- Corrections
- usage of Zipper.java modified so that we now use file name only for entries having a path starting with a ‘/’ or containing “../” (e.g. “/var/log/dummy.log” or “/home../var/log/dummy.log” are compressed as “dummy.log”);
- a bug corrected in Zipper.java so that compressed entries don’t start with ‘/’ any more
- to avoid misbehavior, a worker not presenting the same version as the server receives no job
- New features
- none
- Corrections
- Oct 4th, 2011 : XWHEP 7.6.2
- Corrections
- scripts are now compatible with dash
- data removal improved
- the bridge installation package corrected
- New features
- URI passthrough implemented to comply to EDGI JRA1
- Corrections
- July 18th, 2011 : XWHEP 7.5.0
- Corrections
- windows XP and 7 supported (Vista not tested)
- on server side : access logs are now stored in HomeDir as found in config file and not in /tmp; a bug corrected in group management; DB access improved
- remove leading and trailing spaces from job command line
- the communication protocol has been improved so that the server always sends an answer, especially on error.
The client now displays errors received from the server, if any.
The client also sets its return code accordingly. - the worker-server communication protocol has been corrected so that the worker keeps a chance to upload results, even on server FS error.
This feature exists for long (since INRIA XtremWeb 1.6) but was buggy. - client GUI improved
- a security hole corrected on object removal
- on Mac OS X, the server is now correctly installed and works well.
We don’t use Mac OS X specific stuffs, like StartupItems or LaucnhDaemons, since we have some problems with them.
Instead, we use linux like scripts : xtremweb.server [start | stop | restart | status].
There are two drawbacks : the server does not automatically starts at boot time and the server runs as root under Mac OS X. - Attic removed until further notification : Attic may crash the worker under certain circumstances
- New features
- client can connect using its certificate and associated private key.
The client-server connection is challenged using this key pair.
The client certificate must be certified by a CA cert path known by the server. - client accepts a new –xwout command line option to set the output file name (used with xwresults and xwdownload)
- client can now retrieve applications by their name and users by their login
- client can connect using its certificate and associated private key.
- Corrections
- May 12th, 2011 : XWHEP 7.4.1
- Corrections
- worker, server: xtremwebconf.sh corrected (‘status’ param now accepted)
- worker, server: launching services do not display any more “ls: *.zip: No such file or directory”
- worker, server : log files are now stored in /var/log
- server : a bug corrected on DB cache usage
- client : a bug corrected on xwversion command
- client : a message is now displayed if config file not found
- client : the config file is not modified since it appeared to be too confusing for the user
- works and datas tables modified as needed for the 3G bridge plugin : label and name set to char(150)
- a bug corrected on group jobs management
- New features
- none
- Corrections
- Mar 25th, 2011 : XWHEP 7.4.0
This version introduces corrections and new features to dramatically improve performances.
We have benchmarked our versions using Grid5000. The runs were sent from 1 client to 1 server managing more than 2,000 workers.
Time necessary to submit 10,000 jobs from one client macro file is reduced by up to 40% as shown in the next graph comparing XWHEP 7.3.2 and 7.4.0
The following are extracted from run using 7.4.0
Next graph shows jobs submission times (in green), job launch times on worker side (in blue) and completed times in (red). Submitting 10K jobs took less than 30mn for a total execution time about 45mn for these 10K jobs.
The last graph shows a good load balancing within the 2323 connected workers.
- Corrections
- The communication layer now accepts both connected and non connected mode. The default is as it used to be : non connected mode (one message per socket), but the communication layer can now be used in connected mode : it accepts up to 2000 messages per socket.
To protect the platform against too easy DoS attacks, the server :
- closes socket after 2000 messages (the client is written so that it is transparent) [this is why there are steps on green line in 1st graph : these are reconnection times every 2000 messages]
- sets a socket time out (SOTIMEOUT from config file)
- The communication layer now accepts both connected and non connected mode. The default is as it used to be : non connected mode (one message per socket), but the communication layer can now be used in connected mode : it accepts up to 2000 messages per socket.
- New features
- amount of simultaneous connections to DB is now read from server config file
- introducing SORETRIES (from config file) : max times trying to connect on socket error
- reintroducing (from former versions 5) write through cache in front of DB to improve perfs
- reintroducing (from former versions 5) pool of TCP and DB handlers to reduce malloc/dealloc
- Corrections
- Feb 10th, 2011 : XWHEP 7.3.2
- Corrections
- a bug corrected on URL usage
- New features
- none
- Corrections
- Feb 8th, 2011 : XWHEP 7.3.1
- Corrections
- a bug corrected on communication proxy usage
- New features
- none
- Corrections
- Feb 8th, 2011 : XWHEP 7.3.0
- Corrections
- a bug corrected on communication layer
- a bug corrected on meta data usage
- New features
- we can define a proxy in client and worker configuration file. This allows resource aggregation from Grid5000
- Corrections
- Feb 2nd, 2011 : XWHEP 7.2.2
- Corrections
- a bug on job management introduced in 7.2.1 has been corrected
- New features
- none
- Corrections
- Jan 19th, 2011 : XWHEP 7.2.1
See details at Trac Report
- Corrections
- xwconfigure corrected so that DB reset now works corretly
- client corrected : it now correctly display access rights in hexadecimal and not in decimal
- New features
- none
- Corrections
- Jan 20th, 2011 : two bugs found in XWHEP 7.2.0
- the xwconfigure is erroneus on the database resetting,this may lead to some misbehaviours.
To reset the DB, please do it manually and relaunch the xwconfigure script.
- on client side, access rights are displayed in decimal and not in octal.
- the xwconfigure is erroneus on the database resetting,this may lead to some misbehaviours.
- Jan 19th, 2011 : XWHEP 7.2.0
See details at Trac Report
- Corrections
- xwconfigure corrected
- server now handles SSL handshake error correctly and does not hang any more
- on client side, if valid the X509 proxy is used even if there are login/password
- New features
- batch job management for EDGI/JRA2 SpeQuLoS
- Corrections
- Nov 8th, 2010 : XWHEP 7.1.1
- Corrections
- the server RPM installation package has been corrected
- New features
- none
- Corrections
- Nov 23rd, 2010 : XWHEP 7.1.0
- Corrections
- hsqldb usage restored (http://hsqldb.org).
hsqldb is a relational DB written in java.
it is embedded in the XWHEP server.
this has not been tested in production
(I mean it works but I can’t say a word on scalabitity and performances).
embedding hsqldb enables quick deployment.
this specifically allows EDGI SA1 and SA2 to create quick demo and virtual disks.
- hsqldb usage restored (http://hsqldb.org).
- New features
- a new script make-distribs.sh to manage several worker configurations
- Corrections
- Nov 10th, 2010 : XWHEP 7.0.3
- Corrections
- server installation packages corrected
- Corrections
- Nov 5th, 2010 : XWHEP 7.0.2
- Corrections
- forgot to clean some little things… corrected
- Corrections
- Nov 3rd, 2010 : XWHEP 7.0.0
- Corrections
- on client side, a bug corrected when creating object from XML file
(using ‘–xwxml’ command line paramter) - logger rewritten
- a bug corrected in cache; it now uses URI as key
- the bridge registers only once
- standard users can retrieve their own works, datas and tasks. Advanced privileges are needed to retrieve all works, datas or tasks.
This aims to improve scalability by decreasing amount of unecessary communications.
- a bug corrected on client side : some problems occured on file access if two users were using the same client config file.
(e.g. ‘sudo xwworks’ followed by ‘xwworks’…)
- on worker side, concurrent file acces problems corrected the worker can then now manage several simultaneous jobs
(min = 1; max = amount of detected CPUs)
- client GUI simplified and functionnal
- on client side, a bug corrected when creating object from XML file
- New features
- on worker side, introducing the Apple sandbox usage
- full usage of X509 certificates : credentials can be either login/password or X509 ceritifcate.
The X509_USER_PROXY environment variable must be set before using the client.
In conjonction with XtremWeb-HEP, users are encouraged to use jlite by Oleg Sukhoroslov – http://code.google.com/p/jlite .
The X509_USER_PROXY may contain an X509 proxy as well as an X509 certificate “only”.
This makes no difference to connect to XWHEP server. But an X509 proxy allows EGEE ressources usage, whereas an X509 certificate don’t.
This is transparent for the end user. Ressource usage is still on best effort mode.
The X509_CERT_DIR variable must be set in server config file and points to the directory of CA certificates.
The server validates certificates through its known certificate paths created from X509_CERT_DIR.
This clearly means that self signed user certificates are not allowed. Users with an X509 certificate that can
be validated through the XW server CA cert paths are automatically registered with STANDARD_USER user rights.
While users using login/password still need to be registered by the XW administrator.
- introducing _history tables to decrease production tables sizes by moving row beeing deleted into _history tables
- introducing more logging levels (FINEST, CONFIG) to decrease debug outputs (for Gilles 😉 )
- in prevision of a new improved DG QoS, database now stores (but this is not used yet)
- amount of pending, running and erroneus jobs per application
- amount of pending, running and erroneus jobs per worker
- amount of pending, running and erroneus jobs per user
- usedcputime per user
- webpage per application
- webpage per usergroup
- new columns in hosts table
- totaltmp : total space available in the partition used by the worker
- freetmp : free space available in the partition used by the worker
- poolworksize : the amount of job the worker can run simultaneously
- sgid : Service Grid Identifier. This deprecates pilotjob field (even if it is still used for the moment)
This is automatically set by worker from System.getenv(“GLITE_WMS_JOBID”) this can still be faked by a malicious (just as “pilotjob” field is)
but the monitoring has the opportunity to check if this is a valid SGID or not
which was not the case with the field “pilotjob”
- the client accepts a new parameters : “–xwshell” that instanciates a daemon client.
This daemon accept incoming connections on port 4327 and forwards received XMLRPCCommand
to the server (and sends answers back). This specifically aims to improve bridges performances.
- worker accessrights reflects confinement
- a public worker has a 0X755 accessrights
- a group worker has a 0X750 accessrights
- a private worker has a 0X700 accessrights
- a new REST interface. User can now connect to server through HTTPS. Example :
To retrieve work UIDs
http://an_xwhep_server/?xwcommand=
This gets :...
Then to retreive a given work
http://an_xwhep_server/?xwcommand=
This gets : - introducing intel itanium for linux
- Corrections
XtremWeb-HEP 7
Documentation
La documentation est disponible ici.
Suivi de bugs
Vous pouvez accéder à notre serveur trac.
Versions
- 12 décembre 2011 : XWHEP 7.6.4
- Corrections
- un bug corrigé dans la mis à jour des works;
- un bug corrigé dans la soumission des jobs.
- Nouvelles fonctionnalités
- aucune
- Corrections
- 25 octobre 2011 : XWHEP 7.6.3
- Corrections
- 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”);
- 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;
- 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
- 30 septembre 2011 : XWHEP 7.6.2
- Corrections
- les scripts sont compatible avec dash
- la suppression des données a été améliorée
- le paquet d’installation du bridge a été corrigé
- Nouvelles fonctionnalités
- le URI passthrough pour EDGI JRA1
- Corrections
- 18 juillet 2011 : XWHEP 7.5.0
- Corrections
- compatible windows XP et 7 (Vista non testé)
- 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
- les espaces inutiles sont automatiquement supprimés dans la ligne de commandes des jobs
- le protocole de communication a été amélioré afin que le client soit clairement informé des éventuelles erreurs côté serveur
- 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é
- la GUI du client améliorée
- un trou de sécurité corrigé dans la suppression d’objet
- 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”.
- 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
- 12 mai 2011 : XWHEP 7.4.1
- Corrections
- worker, server: xtremwebconf.sh corrigé : ‘status’ est maintenant correctement pris en compte
- worker, server: au lancement, il n’y a plus l’affichage “ls: *.zip: No such file or directory”
- worker, server : les journaux sont maintenant dans /var/log
- server : un bug corrigé au niveau du cache DB
- client : un bug corrigé dans la commande xwversion
- client : un message est maintenant affiché si le fichier de conf est introuvable
- client : le fichier de conf n’est plus modifié car l’utilisateur s’y perdait
- les tables works et datas ont été modifiées pour être utilisable par le 3G bridge
- un bug corrigé dans la gestion des job de groupe
- Nouvelles fonctionnalités
- aucune
- Corrections
- Mar 25th, 2011 : XWHEP 7.4.0
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
- 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
- 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.
- 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
- 25 mars 2011 : XWHEP 7.4.0
- Corrections
- un bug corrigé dans l’utilisation d’URL
- Nouvelles fonctionnalités
- aucune
- Corrections
- 10 février 2011 : XWHEP 7.3.2
- Corrections
- un bug corrigé dans l’utilisation d’URL
- Nouvelles fonctionnalités
- aucune
- Corrections
- 8 février 2011 : XWHEP 7.3.1
- Corrections
- un bug corrigé dans l’utilisation des proxys de communication
- Nouvelles fonctionnalités
- aucune
- Corrections
- 8 février 2011 : XWHEP 7.3.0
- Corrections
- un bug corrigé au niveau de la couche communication
- un bug corrigé dans l’utilisation des méta datas
- Nouvelles fonctionnalités
- 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
- 2 février 2011 : XWHEP 7.2.2
- Corrections
- un bug au niveau de la gestion des jobs, introduit dans la 7.2.1, a été corrigé
- Nouvelles fonctionnalités
- aucune
- Corrections
- 26 janvier 2011 : XWHEP 7.2.1
Plus de détails dans Trac
- Corrections
- la remise à zéro de la base de donnees a été corrigée.
- au niveau du client, les droits d’accès s’affichent en octal.
- Nouvelles fonctionnalités
- aucune
- Corrections
- 20 janvier 2011 : deux bugs trouvés dans XWHEP 7.2.0
- 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. - au niveau du client, les droits d’accès s’affichent en décimal et non pas en octal.
- il y a une erreur dans le script xwconfigure : la remise à zéro de la base de donnees ne s’exécute pas correctement,
- 19 janvier 2011 : XWHEP 7.2.0
- Corrections
- xwconfigure corrigé
- le serveur gère maintenant correctement les erreurs SSL
- au niveau du client, l’utilisation des certificats X509 a été corrigé
- Nouvelles fonctionnalités
- gestion des jobs par batch pour EDGI/JRA2 SpeQuLoS
- Corrections
- 8 décembre 2010 : XWHEP 7.1.1
- Corrections
- le paquet RPM d’installation du serveur a été corrigé
- Nouvelles fonctionnalités
- aucune
- Corrections
- 23 novembre 2010 : XWHEP 7.1.0
- Corrections
- 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.
- restauration de l’utilisation de hsqldb (http://hsqldb.org).
- Nouvelles fonctionnalités
- un nouveau script, make-distribs.sh, permet de générer plusieurs configurations
- Corrections
- 10 novembre 2010 : XWHEP 7.0.3
- Corrections
- les paquets d’installation du serveur ont été corrigés
- Corrections
- 5 novembre 2010 : XWHEP 7.0.2
- Corrections
- j’avais oublié de nettoyer le script xwconfigure script… c’est corrigé
- Corrections
- Nov 3rd, 2010 : XWHEP 7.0.0
- Corrections
- un bug corrigé au niveau du client quant à l’utilisation du parametre ‘–xwxml’
- le système de log a été réécrit
- un bug corrigé au niveau du cache
- le bridge DG->SG s’enregistre désormais correctement au niveau du serveur
- 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.
- 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’…)
- 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)
- le client GUI aété simplifié et corrigé
- Nouvelles fonctionnalités
- sous Mac OS X, le worker exécute désormais les jobs dans la sandbox de Apple.
- 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.
- 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.
- introduction de nouveaux niveaux de log (FINEST, CONFIG) to decrease debug outputs (pour Gilles 😉 )
- 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
- 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.
- 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.
- 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
- 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:
- introduction de Intel itanium pour linux
- Corrections
FAQ
Une page d’aide : la FAQ
FAQ
A new page : the FAQ
FAQ
Foire Aux Questions
- Comment savoir si la dernière version est stable?
- Penser à vérifier si elle a été déployée au LAL
- Comment tester la plate-forme?
- Nous vous proposons des paquets prêts à l’emploi
- Où trouver le LiveCD?
- Vous pouvez télécharger le LiveCD
FAQ
Frequently Asked Questions
- How stable is the last version?
- Please check if that version has been deployed at LAL
- How to test the platform?
- We are glad to propose ready to use packets
- Where is the LiveCD?
- You can download the LiveCD