Projet Socle ENT
Pages enfant
  • Load Balancing (esup 4)

Comparaison des versions

Légende

  • Ces lignes ont été ajoutées. Ce mot a été ajouté.
  • Ces lignes ont été supprimées. Ce mot a été supprimé.
  • La mise en forme a été modifiée.
Commentaire: Migrated to Confluence 5.3
Avertissement
title [INTERNAL_esupv4] Validation de la page

État
colourRed
titleEn attente.

#ValidateurDateComments
1Julien Gribonvald14/02/2013 (matin)

En attente décision interne ESUP si on précise les noms des fichiers de configuration apache

2   

Principe du Load Balancing

Le load balancing va peut permettre à un serveur Apache

  • de répartir la charge de requêtes entre différents serveurs applicatifs Tomcat.
  • de faire du failover

Info
titleQuelques explications à propos du schéma ci-dessus
  • Les flèches représentent les liens et le protocole utilisé
  • Le texte en couleur représente l'adresse de l'entité de la même couleur
  • L'emplacement des "mod_..." et des propriétés définies dans le filtre (uportal.procotol, uportal.server, ...) représente représentent l'emplacement de stockage de l'information
  • Le source du schéma est disponible en PJ (Logiciel DIA nécessaire)

La mise en place de ce système est assez très similaire à la configuration d'un serveur frontal Apache.

Remarque
titleAttention

La configuration d'un frontal Apache et de load balancing ne peuvent pas être actives en même temps, le load balancing gérant déjà la redirection des requêtes vers un autre serveur. Si un serveur frontal Apache à déjà été configuré, il convient donc de commenter ou de supprimer les lignes décrites sur la page Apache frontal (esup 4)

Serveurs Tomcat

Chacun des serveurs Tomcat devra être configuré en effectuant les modifications suivantes dans le fichier server.xml.

Dans un premier temps, on va commenter le connecteur du port http par défaut (8080) :

Bloc de code
languagehtml/xml
titleserver.xml
...
<!-- <Connector port="8080" protocol="HTTP/1.1" 
               connectionTimeout="20000" 
               redirectPort="8443" emptySessionPath="true"/> -->
...

On va ensuite rajouter un connecteur AJP qui permettra de connecter le serveur Tomcat avec le serveur Apache :

Bloc de code
languagehtml/xml
titleserver.xml
...
<Connector port="8009" address="127.0.0.1"
           enableLookups="false" redirectPort="8443" protocol="AJP/1.3" emptySessionPath="true" />
...

...

Avertissement
titleSécurité

Si le serveur Apache est situé sur la même machine que le serveur Tomcat, la valeur 127.0.0.1 assurera plus de sécurité que la valeur par défaut (0.0.0.0).

...

titleTomcat

...

, merci de vous y référer dans un premier temps : on décrira ici simplement la façon d'ajouter un nouveau Tomcat en plus du premier déjà configuré. 

Serveurs Tomcat

Si plusieurs serveurs Tomcat sont hébergés sur la même machine, il faudra ajuster les ports 8005, 8009 (et 8080 si vous le laissez actif) dans conf/server.xml de chaque tomcat. L'idée est de donner des ports différents à chaque.

Exemple :

  1. ent1: 8105, 8180, 8109 
  2. ent2: 8205, 8280, 8209 
  3. etc...

 

On note également que contrairement à beaucoup de documentations, on n'utilisera pas ici la jvmRoute pour permettre à Apache de router et attacher un tomcat spécifique à une session utilisateur.
On utilisera en effet ici une procédure à configurer au niveau du Apache.
La technique du jvmRoute est en effet à considérer lorsque qu'on utilise également la notion de cluster Tomcat, chose qu'on ne décrira pas ici (pour l'instant en tout cas, ... appel à contributions (clin d'œil) ).

 

Enfin, on va rajouter un nom de route pour différencier les serveurs Tomcat auprès du serveur Apache. Trouvez la ligne :

Bloc de code
languagehtml/xml
titleconf/server.xml
...
<Engine name="Catalina" defaultHost="localhost">
...

Et rajoutez-y le paramètre jvmRoute de cette façon :

Bloc de code
languagehtml/xml
titleconf/server.xml
...
<Engine name="Catalina" defaultHost="localhost" jvmRoute="tomcat1">
...

 

Réglages applicatifs

Chaque Tomcat ainsi configuré va héberger une instance de l'application uPortal. Chacune de ces instance devra pourra être configurée de façon différente, pour refléter l'adresse réelle du serveur Tomcat, en modifiant le filtre esup.properties.

...

La ligne environment.build.real.uportal.server désigne l'adresse réelle de l'application, à savoir l'adresse et le port du serveur applicatif où ce situe cette instance.

Remarque/rappel : on pourra utiliser un system property java pour environment.build.real.uportal.server ce qui nous évitera ici justement d'avoir des configurations distinctes pour chaque instance !!
CF  Apache frontal (esup 4)#Bonnepratique

 

Info

Ce réglage real réglage real est nécessaire dans le cadre de la mise en place du load balancing et pour que le Proxy CAS puisse fonctionner : il permet de communiquer avec le portail sur un serveur précis. Elle va indiquer au CAS une URL d'accès sur l'ENT précis sur lequel l'utilisateur (session) est accroché.
environment.build.real.uportal.server indique donc un virtual host où il n'y a pas de répartition de charge, et lié à une seule instance du portail (on contourne ainsi le load balancing pour communiquer directement avec le serveur qui a émis la requêteun ENT spécifique).
Il conditionne le bon fonctionnement du proxy CAS.

 

...

.

...

URLs
Remarque
title

Les lignes environment.build.real.uportal.server et environment.build.real.uportal.context devront varier d'un serveur Tomcat à l'autre. Les autres lignes resteront identiques pour chaque instance.

...

Serveur Apache

En plus du mod_proxy et mod_proxy_ajp préalablement utilisés, on va utiliser ici

 

Serveur Apache

Une fois que chaque Tomcat sera configuré correctement et hébergera une instance adaptée de l'application, il ne reste plus qu'à configurer le serveur Apache pour répartir la charge entre les différents serveurs.

Pour cela, on utilisera 3 modules :

...

le mod_proxy_balancer qui assurera le transfert de charge.

L'activation de ces modules se fera en dé-commenter les trois lignes suivantes, ou en les ajoutant si elles ne sont pas présentes On s'assure que les modules sont bien activés par la présence de ce type de configuration :

Bloc de code
languagehtml/xml
titleConfiguration Apache
...
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
...

A la fin de ce fichier, on rajoutera ensuite le bloc de configuration du mod suivant :En lieu et place de 
ProxyPass         / ajp://tomcat1.ent.fr:8009/
dans la configuration du virtualhost on pourra préciser la configuration suivante 


Bloc de code
languagehtml/xml
titleConfiguration Apache
<VirtualHost *:80>       
    ...
 
#Configuration    du load balancing
<VirtualHost *:80>ProxyPass /balancer-manager !
    #Configuration du load  balancing
 
    ProxyRequestsProxyPass Off / balancer://mycluster_uPortal/ 

    <Proxy balancer://portal>mycluster_uPortal>
        # BalancerMember ajp://tomcat1tomcat0.entuniv.fr:8009 route=tomcat1 loadfactor=ent0 timeout=60 retry=1 lbset=1
        BalancerMember ajp://tomcat2tomcat1.entuniv.fr:80108009 route=ent1 timeout=tomcat260 loadfactorretry=1 
        ProxySet lbmethod=bytraffic
    BalancerMember ajp://tomcat2.univ.fr:8009 route=ent2 timeout=60 retry=1 
	     ProxySet stickysession=ROUTEID=TOMCAT_STICKY nofailover=Off 
    </Proxy>
    Header ProxyPassadd / balancer://portal/  Set-Cookie "TOMCAT_STICKY=sticky.%{BALANCER_WORKER_ROUTE}e;path=/;" env=BALANCER_ROUTE_CHANGED
    
     <Location /balancer-manager>
        Order deny,allow
        Deny from all
        Allow from 127.0.0.1 
        SetHandler balancer-manager
    </Location>
    ...
</VirtualHost>
...

<VirtualHost> permet de définir un hôte virtuel pour lequel les paramètres de balancing seront appliqués. Plusieurs hôtes peuvent être configurés avec des stratégies différentes.

D'ailleurs pour pouvoir atteindre en https://ent1.univ.fr le tomcat de tomcat1 on configurera un virtualhost 443 avec un ProxyPass direct sur tomcat1 (sans balancer)

La ligne <Proxy balancer> définit un cluster de balancement identifié par le nom situé après Proxy balancer:// . Chaque BalanceMember contenu dans cette balise définit un serveur vers lequel rediriger des requêtes. Ils sont définis via le protocole AJP par l'adresse vers laquelle renvoyer les requêtes et le nom de route défini dans la configuration de chaque serveur. On trouve également le paramètre route qui reprend la route JVM définie pour chaque serveur, et un paramètre loadfactor qui définit le seuil de balancement.

Le paramètre ProxySet lbmethod définit la stratégie de balancement. Elle peut prendre les valeurs suivantes :

...

lbmethod=byrequests : Les requêtes sont réparties entre chaque serveur en fonction du loadfactor. Si les deux serveurs ont le même loadfactor, les requêtes seront réparties également entre les deux. Si le deuxième serveur à un loadfactor deux fois plus importants, alors il traitera deux fois plus de requêtes.

...

lbmethod=bytraffic : Cette fois, ce n'est plus le nombre de requêtes qui est réparti entre le serveurs, mais le nombre de bytes échangés. Selon le même principe, si deux serveurs ont le même loadfactor, le traffic sera réparti également entre les deux. Si un des serveurs à un loadfactor deux fois supérieur à l'autre, il traitera deux fois plus de bytes.

...

route qui permettra via un cookie nommé TOMCAT_STICKY ici de router toujours sur le même serveur les requêtes HTTP issues d'une même session utilisateur. La configuration donnée ci-dessus avec le nofailover=Off permet également de rebalancer l'utilisateur sur un autre tomcat en cas de défaillance de celui-ci (avec perte de session ici puisqu'on ne met pas en place la possibilité de cluster tomcat)

La ligne ProxyPass définit :

Concernant les possibilités de paramétrage (nombreuses), merci de vous référer à la doc officielle (cf références en fin de page). 

 

Info

Le code :

<Location /balancer-manager>
     Order deny,allow
     Deny from all
     Allow from 127.0.0.1
     SetHandler balancer-manager
</Location>

définit une interface graphique permettant de visualiser la répartition des charges. Elle est accessible via l'url http://localhost/balancer-manager .
Le paramètre "Deny from all / Allow from 127.0.0.1" est une règle de sécurité qui restreint l'accès à cette interface graphique à la machine qui héberge le serveur Apache (127.0.0.1) : cela permet d'éviter un accès non voulu à la page qui pourrait entrainer un changement dans la configuration du load balancing.

Notez que /balancer-manager est donc fourni par Apache directement et non par Tomcat. La ligne "ProxyPass / balancer://mycluster_uPortal/" indique cependant à tomcat de faire du proxypass (transmettre) toutes les requêtes / au( x) Tomcat(s) (cela nous évite de de le faire pour chacun des contextes /uPortal, /esup-lecture, etc.). Aussi pour que /balancer-manager soit bien servi par apache et non transmis au Tomcat, on a dû ajouter avant ce "ProxyPass / balancer://mycluster_uPortal/" un "ProxyPass /balancer-manager !".

 

 

Info
titleRéférences

https://wiki.jasig.org/display/UPM40/Load+Balancing
http://httpd.apache.org/docs/2.2/mod/mod_proxy.html
http://httpd.apache.org/docs/2.2/mod/mod_proxy_ajp.html
http://httpd.apache.org/docs/2.2/mod/mod_proxy_balancer.html
Exemple de fichier de configuration