Groupe 1B (SSO et gestion des autorisations)
Date de création : 23 juillet 2003
Dernière modification : 16 septembre 2003
Diffusion : internet

Utilisation de UPortal et CAS avec apache et tomcat

Utilisation de UPortal et CAS avec apache et Tomcat Pourquoi utiliser Apache en plus de Tomcat

Le but consiste à utiliser un serveur pour apache et plusieurs autres serveurs pour Tomcat.

On peut ainsi avoir une solution tolérante aux pannes et qui peut monter en charge.

Remarques

Dans ce document on part du principe que l'on utilise une version récente de Tomcat (4.1.24 ici) et du JDK (1.4.01 ici).

Les informations sont données pour Linux mais peuvent être adaptées à d'autres OS.

Chaque service (UPortal, CAS, autre) fonctionne avec un Tomcat dédié. Ceci permet d'utiliser des versions de JVM et de Tomcat différentes pour chaque service si besoin. Il est possible de paramétrer la mémoire utilisée pour la JVM pour chaque service. Certaines Opérations de maintenance qui nécessitent de stopper Tomcat n'impactent que le service concerné.

Références

Apache : http://httpd.apache.org/

Tomcat : http://jakarta.apache.org/tomcat/tomcat-4.1-doc/index.html

mod_jk : http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/index.html

Utilisation de Apache 1 mod_jk 1

Installation de mod_jk 1

Configurer mod_jk dans Apache

Modifier le fichier httpd.conf

Le fichier de paramétrage de mod_jk

worker.uportal.type=lb
worker.uportal.balanced_workers=uportal1, uportal2

Worker de type lb (Load Balancing) vers deux "sous-worker" uportal1 et uportal2

worker.uportal1.type=ajp13
worker.uportal1.port=9508
worker.uportal1.host=svr1.domaine.fr
worker.uportal1.lbfactor=1
worker.uportal1.socket_timeout=300

Worker utilisant le protocole ajp13 pour dialoguer avec le Tomcat de la machine svr1 qui écoute sur le port 9508. lbfactor permet de pondérer les accès entre uportal1 et uportal2. socket_timeout permet de couper les connexions qui ne sont plus utilisées.

worker.uportal2.type=ajp13
worker.uportal2.port=9508
worker.uportal2.host=svr2.domaine.fr
worker.uportal2.lbfactor=1
worker.uportal2.socket_timeout=300

worker.cas.type=ajp13
worker.cas.port=9518
worker.cas.host=svr1.domaine.fr

Worker utilisant le protocole ajp13 pour dialoguer avec le Tomcat de la machine svr1 qui écoute sur le port 9518.

Configurer le site virtuel pour UPortal et CAS

Httpd.conf

Création des sites virtuels pour UPortal et CAS en http et/ou https

<VirtualHost 129.20.131.20:443>
	Options none
	ServerAdmin webmaster@domaine.fr
	DocumentRoot /data/webapps/cas
	ServerName cas.domaine.fr
	ErrorLog logs/cas_error_log
	CustomLog logs/cas_access_log common
	JkMount /* cas
	SSLEngine on
	SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
	# le certificat du serveur cas.domaine.fr
	SSLCertificateFile /etc/httpd/conf/ssl.crt/cert.cas.domaine.fr.pem
	# la clef privée du serveur cas.domaine.fr
	SSLCertificateKeyFile /etc/httpd/conf/ssl.key/key.cas.domaine.fr.pem
	# les certificats de chaque autorité de certification depuis    la racine
	# jusqu'à l'autorité de certification CRU
	SSLCertificateChainFile /etc/httpd/conf/ssl.crt/cachain.igc-pilote-cru.txt
	# les certificats des autorités de certification pré-initialisés dans le
	# navigateur netscape
	SSLCACertificateFile /etc/httpd/conf/ssl.crt/ca-bundle.crt
	SetEnvIf User-Agent ".*MSIE.*" \
	nokeepalive ssl-unclean-shutdown \
	downgrade-1.0 force-response-1.0
	CustomLog logs/ssl_request_log \
	"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>

Remarque

Un dysfonctionnement de la librairie JAVA traitant les connexion SSL fait que la chaine de certification du CRU n'est pas reconnue lors qu'un client java tente une connexion https vers un serveur apache utilisant un tel certificat.

Le fichier comportant la chaine de certification (ici, cachain.igc-pilote-cru.txt) comporte dans l'ordre le certificat de l'ac-racine, suivi du certificat de l'ac-serveur. Il faut inverser cet ordre dans ce fichier.

Configurer le serveur Tomcat

Nous utilisons ici un serveur Tomcat dédié pour chaque service. Vous trouverez ci-dessous le fichier server.xml type.

Le serveur tomcat est lancé en positionnant les variables d’environnement suivantes :

Lancement par la commande $ CATALINA_HOME/bin/startup.sh

server.xml 

<!—
   il vous faut modifier les numeros de port du server, et des connecteurs pour    mettre les memes numeros de port que dans le workers.properties de Apache 
   EXEMPLE : port dans le workers.properties de Apache : 9518
   dans le fichier ci-dessous,
   Server port deviendra 9018
   Connector http deviendra 8818
   Connector ajp13 deviendra 9518
-->
<!-- il vous faut rajouter le contexte Tomcat de votre application -->
<Server port="9018" shutdown="SHUTDOWN" debug="0">
	<Service name="Tomcat-Standalone">
		<Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
			port="8818" minProcessors="5" maxProcessors="75"
			enableLookups="true" redirectPort="8443"
			acceptCount="100" debug="0" connectionTimeout="20000"
			useURIValidationHack="false" disableUploadTimeout="true" />
		<Connector className="org.apache.ajp.tomcat4.Ajp13Connector"
			port="9518" minProcessors="5" maxProcessors="75"
			acceptCount="10" debug="0"/>
		<Engine jvmRoute="cas" name="Standalone" defaultHost="cas.domaine.fr" debug="0">
			<Logger className="org.apache.catalina.logger.FileLogger"
				prefix="catalina." suffix=".log" timestamp="true"/>
			<Realm className="org.apache.catalina.realm.MemoryRealm"/>
			<Host name=" cas.domaine.fr " debug="0" appBase="webapps" unpackWARs="true">
				<Valve className="org.apache.catalina.valves.AccessLogValve"
					directory="logs" prefix="access." suffix=".log" pattern="common"/>
				<Logger className="org.apache.catalina.logger.FileLogger"
					directory="logs" prefix="jsp." suffix=".log" timestamp="true"/>
				<Context path="" docBase="/data/webapps/cas" debug="0" privileged="true" reloadable="true">
				</Context>
			</Host>
		</Engine>
	</Service>
</Server>

Il faut configurer le fichier server.xml sur les x serveurs qui rendent le service Uportal en prenant bien garde de modifier le paramètre jvmroute. Ce paramètre doit correspondre avec le nom du worker dans le fichier workers.properties (ex : cas, uportal1, uportal2).

Il faut aussi configurer le fichier server.xml sur le serveur qui rend le service CAS.

Utilisation de Apache 2 et mod_jk 2

Apache 2 permet d'utiliser mod_jk 1 et/ou mod_jk 2. Cette partie ne traite que l'utilisation de Apache 2 avec mod_jk 2. Pour utiliser Apache 2 avec mod_jk 1 ce référer au chapitre "Utilisation de Apache 1 mod_jk 1" en prenant soin de télécharger la librairie mod_jk pour Apache 2.

Installation de mod_jk 2

Configurer mod_jk dans Apache

Modifier le fichier httpd.conf

Le fichier de paramétrage de mod_jk ( ! A VALIDER !)

Ce fichier se trouve dans le répertoire conf d’apache et porte le nom workers2.properties

Configurer le serveur Tomcat (! A valider !)

Identique à la configuration du serveur Tomcat dans le cadre d'une utilisation avec Apache 1 sauf :

CAS et la tolérance aux pannes

Pourquoi pas de tolérance aux pannes pour CAS

Mode de fonctionnement de la tolérance aux pannes

Utilisation d'un cookie ou d'une réécriture d'URL pour réorienter un client Web vers le serveur Tomcat avec lequel il a initialisé une session (noté ci-après ticket Tomcat). Le ticket Tomcat est constitué d'un numéro de session généré par le serveur Tomcat et d'une chaîne de caractères spécifique à chaque serveur Tomcat (attribut "jvmroute" du connecteur ajp13 en mod_jk1 ou nom du worker en mod_jk2).

Lors d'une première ouverture de session sur un service, il n'y a pas ce ticket Tomcat et la requête est envoyée sur n'importe lequel des serveurs Tomcat disponibles.

Ce principe permet de répartir la charge entre plusieurs serveurs Tomcat mais aussi de garantir une tolérance aux pannes en aiguillant toutes les requêtes vers le ou les serveurs Tomcat qui restent disponibles. C'est mod_jk qui gère cette répartition de charge (grâce au paramétrage lbfactor) et cette tolérance aux pannes.

Pourquoi pas avec CAS

Imaginons un service CAS en répartition de charge et tolérance aux pannes. Parce qu'un utilisateur s'identifie auprès d'un serveur Tomcat donné, il obtient ticket Tomcat spécifique à ce serveur Tomcat. Le service CAS de ce serveur Tomcat mémorise cette identification (liée à un TGC) et se met en attente de demande de ST. L'application qui va demander un ST ne peut pas savoir sur quel serveur Tomcat l'utilisateur s'est identifié. L'application fait un accès vers l'url du service CAS sans ticket Tomcat et peut être orientée vers n'importe quel serveur Tomcat. Si ce n'est pas le serveur Tomcat qui a identifié l'utilisateur il y a nouvelle demande d'identification…

Perspective pour rendre CAS tolérant aux pannes

Propager le ticket Tomcat

Propager le ticket Tomcat vers les applications peut être une solution mais elle semble difficile à mettre en place.

Inconvénients :

Cette solution semble à écarter.

Utiliser mod_jk

Utiliser mod_jk pour sa seule fonctionnalité de tolérance aux pannes seulement et pas l'équilibrage de charge peut être une solution. La "non répartition" de charge évite d'avoir à gérer les ticket Tomcat car on dialogue toujours avec un seul serveur Tomcat.

Avantage :

Inconvénient :

Comment faire ?

A suivre.

Utiliser une solution matérielle

S'il n'est pas possible d'utiliser mod_jk, une alternative (coûteuse et propriétaire), consiste à utiliser une solution matérielle.

Faire évoluer CAS

Faire évoluer CAS pour qu'il utilise un "espace partagé" pour mémoriser les informations liées à la connexion de l'utilisateur est une solution qui permet d'utiliser le service CAS depuis plusieurs serveurs Tomcat.

Inconvénients :

Cette solution n'est à envisager que si la solution avec mod_jk ne fonctionne pas ou ne tient pas la charge.

Tolérance aux pannes du serveur http

Aucune solution n'est encore en production localement mais des solutions sont envisagées pour pallier la faiblesse d'un seul serveur http en frontal de plusieurs serveurs Tomcat.

Dès que nous aurons validé une solution nous la documenterons. Néanmoins voici les grandes lignes que nous allons suivre.

http en actif/actif

Nous ne croyons pas aux solutions ou un serveur http de secours est en attente pour prendre la main en cas de défaillance d'un serveur principal mode (actif/passif). En effet, il arrive toujours un moment où l'on oublie de propager une modification de la configuration du serveur principal sur le serveur de secours.

Le mode de fonctionnement du ticket Tomcat doit permettre de travailler avec x serveurs http durant une même session applicative sans conséquence particulière.

Pour offrir ce mode actif/actif nous pensons simplement utiliser le round robin DNS.

Garantir la tolérance aux pannes

Nous ne pensons pas utiliser de solutions matérielles coûteuses mais seulement des solutions logicielles.

Nous pensons configurer chaque serveur Apache pour qu'il puisse répondre a toutes les adresses IP des autres serveurs http. Il n'existe donc qu'une seule configuration http qui est mise à jour sur un serveur principal et distribué avec les autres serveurs.

Un mécanisme (peut-être Net-Saint) sur un serveur tiers observe le fonctionnement des services http. En cas de non réponse d'un serveur http une commande est lancée à un serveur de secours pour qu'il prenne l'adresse physique (ou les adresses dans le cas de https) du serveur qui est indisponible.

Remarques :

 

Création : Juillet 2003 - Raymond Bourges (Université de Rennes 1)

Modifications :
16 septembre 2003 - Vincent Mathieu . remarque sur le fichier de chaine de certifs du CRU