17 mai 2012

Equilibrage de charge entre un Apache et deux HRaSpace v7 sous Tomcat



L'objectif est de faire en sorte que Apache répartisse les utilisateurs sur deux serveur Tomcat . Ceci peut être utile pour répartir la charge (load balancing) et sécuriser l'exploitation (crash d'un des serveurs). En revanche, il faudra livrer les mises à jour de l'arborescence du client riche sur chacun des serveurs. Cette configuration n'est donc adaptée qu'aux environnements sans publication par HRStudio.

La configuration initiale du site est la suivante :
  • un Apache en frontal,
  • un Tomcat avec son application HRaSpace v7,
  • une base JetSpeed déportée sur l'instance DB2 de HR Design.
A noter :
  • si un des Tomcat "tombe", HRAccess n'assure pas la persistance de la session des utilisateurs. Ceux initialement affectés au Tomcat défaillant seront basculés sur le rescapé où ils devront se ré-authentifier (ce n'est pas une configuration de "cluster" avec réplication de session).
  • Apache a été compilé avec le module proxy_balancer (présence du fichier /hraxxx/apache/modules/mod_proxy_balancer.so et dans httpd.conf : LoadModule proxy_balancer_module modules/mod_proxy_balancer.so)

  • L'expérience montre qu'un schema JetSpeed unique est suffisant.

Coté Tomcat


Mise en place d'un second tomcat et son fichier de configuration :
  • fermeture et copie de l'arbo tomcat /hraxxx/hraspace dans /hraxxx/hraspace.balancer, 
  • dans le server.xml du nouveau Tomcat, les ports 5208* sont modifiés en 5209* (pour mon test les Tomcat sont "côte à côte" sur le même serveur. Installés sur deux machines distinctes, cette modification serait inutile).
  •  Définition des Routes dans les fichiers "server.xml" de chaque Tomcat :
    <!-- Define the top level container in our container hierarchy
    <Engine name="Catalina" defaultHost="localhost">
    -->


    <Engine name="Catalina" defaultHost="localhost"
    jvmRoute="route1" debug="0">

(et route2 pour le second Tomcat)

Coté Apache


Fermer Apache, puis dans le extra/httpd_hraccess.conf de mon Apache (mon httpd.conf inclue cet extra) :

  • Mise en commentaire du routage initial (Tomcat unique) :
# Single local Tomcat
# ProxyPass /  ajp://localhost:52085/
# ProxyPassReverse /  ajp://localhost:52085/


  • Mise en place du "répartiteur" avec Proxy balancer,
  • Redirection de chacune des application HRaSpace (merci Stéphane pour le tuyau) sur le cluster  par ProxyPass,
  • Avec stickysession (pour que les requêtes de l'utilisateurs "restent" dirigées sur le serveur qui lui a été attribué lors de sa première transaction),
  • Correction avec ProxyPassReverse des messages retournés pour rétablir l'entête initial :

# Load balancing two local Tomcats

<Proxy balancer://HRaCluster>
   BalancerMember ajp://localhost:52085/ loadfactor=1 route=route1
   BalancerMember ajp://localhost:52095/ loadfactor=1 route=route2
   # byrequests / bytraffic / bybusyness
   # ProxySet lbmethod=bytraffic
</Proxy>

ProxyPass        /hra-space balancer://HRaCluster/hra-space stickysession=JSESSIONID|jsessionid nofailover=On
ProxyPassReverse /hra-space balancer//localhost:52085/hra-space
ProxyPassReverse /hra-space balancer//localhost:52095/hra-space
ProxyPass        /hr-dms    balancer://HRaCluster:52083/hr-dms stickysession=JSESSIONID|jsessionid nofailover=On
ProxyPassReverse /hr-dms    balancer//localhost:52085/hr-dms
ProxyPassReverse /hr-dms    balancer//localhost:52095/hr-dms
ProxyPass        /hr-rich-client balancer://HRaCluster:52083/hr-rich-client stickysession=JSESSIONID|jsessionid nofailover=On
ProxyPassReverse /hr-rich-client balancer//localhost:52085/hr-rich-client
ProxyPassReverse /hr-rich-client balancer//localhost:52095/hr-rich-client
ProxyPass        /hr-portlets    balancer://HRaCluster:52083/hr-portlets stickysession=JSESSIONID|jsessionid nofailover=On
ProxyPassReverse /hr-portlets    balancer//localhost:52085/hr-portlets
ProxyPassReverse /hr-portlets    balancer//localhost:52095/hr-portlets
ProxyPass        /hr-self-service balancer://HRaCluster:52083/hr-self-service stickysession=JSESSIONID|jsessionid nofailover=OnProxyPassReverse /hr-self-service balancer//localhost:52085/hr-self-service
ProxyPassReverse /hr-self-service balancer//localhost:52095/hr-self-service
ProxyPass        /hr-configuration-tool-web balancer://HRaCluster:52083/hr-configuration-tool-web stickysession=JSESSIONID|jsessionid nofailover=On
ProxyPassReverse /hr-configuration-tool-web balancer//localhost:52085/hr-configuration-tool-web
ProxyPassReverse /hr-configuration-tool-web balancer//localhost:52095/hr-configuration-tool-web
ProxyPass        /hr-admin-console balancer://HRaCluster:52083/hr-admin-console stickysession=JSESSIONID|jsessionid nofailover=On
ProxyPassReverse /hr-admin-console balancer//localhost:52085/hr-admin-console
ProxyPassReverse /hr-admin-console balancer//localhost:52095/hr-admin-console
ProxyPass        /hr-online-query  balancer://HRaCluster:52083/hr-online-query stickysession=JSESSIONID|jsessionid nofailover=On
ProxyPassReverse /hr-online-query  balancer//localhost:52085/hr-online-query
ProxyPassReverse /hr-online-query  balancer//localhost:52095/hr-online-query

ProxyTimeout 300

Coté Objet Site HRS

Créer une seconde fonction "Serveur Web" pour pouvoir accéder au second Tomcat sur la console d'administration Web de HRaSpace (je vois que l'on peut créer des "Cluster" de serveur Web mais je n'en connais pas les implications ... A tester).



Pour finir


  • Noter que le "balancer" Apache a sa propre console : http://mon.serveur.apache:52000/balancer-manager


     
  • Vous pouvez tester la répartition en altérant le loadfactor puis en contrôlant avec la console ou par consultation des logs sur quel Tomcat vous êtes redirigé.

3 mai 2012

Corriger par update SQL les ZX00.NUGEST déphasés

Si vous chargez des dossiers ZY et ZX par NOZ sur un environnement possédant déjà des dossiers, il y a de fortes chances que les NUDOSS ZY d'origine soient re-numérotés.Du coup, les NUGEST ZX ne seront plus en phase avec les NUDOSS des dossiers ZY concernés.

Pour faire un constat, exécutez :
select
ZX00.NUDOSS, ZX00.NUGEST, ZX00.SOCCLE, ZX00.MATRIC, ZY00.SOCCLE, ZY00.MATCLE
from ZX00 LEFT OUTER JOIN ZY00 on ZX00.NUGEST=ZY00.NUDOSS
where (
    (ZX00.SOCCLE<>ZY00.SOCCLE or ZY00.SOCCLE is null)
    or
    (ZX00.MATRIC<>ZY00.MATCLE or ZY00.MATCLE is null))

Ci joint un exemple d'update pour corriger ZX00.NUGEST.

Pour Oracle
update ZX00 set ZX00.NUGEST = (
  select coalesce( 
    (select ZY00.NUDOSS from ZY00 where ZX00.SOCCLE=ZY00.SOCCLE and ZX00.MATRIC=ZY00.MATCLE)
    ,0)
    from DUAL);

Pour DB2 remplacez DUAL par SYSIBM.SYSDUMMY1

A noter : Avec cet ordre SQL, les dossier ZX sans correspondance avec des matricules ZY auront un NUGEST nul.

 SQL> select nugest from zx00;
       181
 SQL> select soccle,matric,nugest from zx00;
 SOC MATRIC           NUGEST
 - - - - - - - - - - - - - - - - - -
 FRR FRP1047             181

 SQL> select nudoss,soccle,matcle from zy00 where nudoss = 181;
 no rows selected

 SQL> update ZX00 set ZX00.NUGEST = (select coalesce((select ZY00.NUDOSS from ZY00 where ZX00.SOCCLE=ZY00.SOCCLE and ZX00.MATRIC=ZY00.MATCLE),0) from DUAL);
 1 row updated.

 SQL> select soccle,matric,nugest from zx00;
 SOC MATRIC           NUGEST
 - - - - - - - - - - - - - - - - - -
 FRR FRP1047               0

2 mai 2012

grep et message "Fichier binaire ... concorde"

Vous utilisez la commande "grep" sur un fichier texte et celle ci répond "Fichier binaire ... concorde" au lieu de vous afficher les lignes concernées. Ceci est du au fait que la commande a estimé que le fichier était de type "binaire", donc non affichable.  

Forcez le type du fichier en utilisant une des options suivantes :

grep -a
grep --text
grep --binary-files=text.