Copyright 2008 © Consortium ESUP-Portail

ESUP-Days 9, Paris, 5 février 2010

Etude technique « performance et haute disponibilité »

de l’ENT de l'Université Paris DescartesDominique Houdet-joly Pascal AubryYves Gerday Julien MarshallOlivier WaldekRichard Vatré

Copyright 2008 ©

L’ENT à l’université Paris Descartes

• Université pluridisciplinaire– répartie sur 9 Ufr (ou facultés ) et 1 IUT

• 35000 étudiants

• 8000 personnels– Enseignants, chercheurs, BIATOSS

• le point d’entrée unique vers les services numériques– depuis fin 2008

ESUP-Days 7, Paris, 3 février 2009

Copyright 2008 ©

Contexte de l’étude

• Installation de ESUP uPortal 2.6-dlm– au 15-12-2008 : 30 services dont 3 portlets

• Montée en charge sans problème sur le début l’année 2009– en moy. 15000 consultations différentes par mois

– 35% des utilisateurs

• Nécessité de fiabiliser et de rendre évolutive l’architecture

• Un contexte de risque de crise pandémique

• Plusieurs incidents bloquants (sept/oct 2009)

ESUP-Days 7, Paris, 3 février 2009

Copyright 2008 ©

Architecture avant l’étude

• Architecture– Frontal web : 1 serveur virtuel

OpenVZ Debian - 256 Mo RAM - 4 Go disque

– Serveur d’application : 1 serveur virtuel VmWare Debian 64 bits - 8 Go RAM - 20 Go disque

• JVM– Architecture 64 bits permettant une

meilleure utilisation de la mémoire disponible

• Frontal– Serveur d’application protégé par le

frontal apache mod_ajp– Les connections au serveur

d’application se font par le protocole ajp

• Bases de données– Un serveur mutualisant les bases

Mysql et Oracle

ESUP-Days 7, Paris, 3 février 2009

MOD_AJP

CLIENTS

MySQL v4

HTTPS

ESUP uPORTAL

CAS v2

Oracle 9i

CAS v2

Copyright 2008 ©

Les incidents (sept-oct 2009)

• Bug Oracle 9i– un fichier de log a rempli la partition data (effet de

bord de la mutualisation de MySql et Oracle)

• Surcharge du serveur MySQL– dû à des requêtes mals formées

• Serveur CAS v2– JavaOutOfMemory Exception

• Page blanche sur le portail– Cause probable : deadlock de la portlet esup-

lecture v1.3.0 (le portail ne pouvait plus s’allouer de thread pour le rendu)

ESUP-Days 7, Paris, 3 février 2009

Copyright 2008 ©ESUP-Days 7, Paris, 3 février 2009

Pourquoi cette étude ?

• ENT– Mise en œuvre + optimisation + évolution– P5 : une mise en œuvre rapide

• Compétences nécessaires– Nombreuses– Transversales

• Meilleures solutions– Souvent empiriques– Issues de l’expérience

• Un œil externe

Copyright 2008 ©ESUP-Days 7, Paris, 3 février 2009

Qui ?

• Deux experts ESUP-Portail– Pascal Aubry (Université de Rennes 1)– Julien Marchal (Université de Nancy 2)

• L’équipe de Paris Descartes– Yves Gerday– Dominique Houdet-Joly– Richard Vatré– Olivier Waldek

Copyright 2008 ©

Comment ?

• Méthodologie– Analyse– Recommandations– Intervention (transfert de compétences)– Synthèse

• Objectifs– Détecter et réparer les dysfonctionnements– Consolider l’existant– Préparer les évolution futures

ESUP-Days 7, Paris, 3 février 2009

Copyright 2008 ©

Quand ?

• Appel le 15 octobre– Demande de la DSI

• Durée : trois semaines– 26/10 : prise de contact (visio-conférence)– 27/10 : transmission du plan d’action– 29/10 : analyse du système (sur place)– 2/11 : émission de recommandations– 3-8 : premières modifications du système– 9-10/11 : intervention sur le système

• Fin le 13 novembre– Synthèse et dernières recommandations

ESUP-Days 7, Paris, 3 février 2009

Copyright 2008 ©

Plan d’action

• Analyse des pannes– Corrections rapides pour assurer le service

• Analyse complète du système• Recommandations

– A moyen et long terme• Intervention

– Transfert de compétences• Synthèse

ESUP-Days 7, Paris, 3 février 2009

Copyright 2008 ©

Analyse des pannes

• Symptôme– Page planche

• Cause probable– Thread deadlock (esup-lecture 1.3.0)

• Script de détection des pannes inopérant

ESUP-Days 7, Paris, 3 février 2009

Copyright 2008 ©

Analyse du système

• En collaboration avec l’équipe– Compréhension des choix effectués– Prise en compte des particularités locales

• Approche globale, complète et systématique– Tout est lié !– Portail

• uPortal, applications, frontal– CAS– Webmail– Backends

• LDAP• Bases de données (Oracle & MySql)

ESUP-Days 7, Paris, 3 février 2009

Copyright 2008 ©

Premières recommandations

• 24 recommandations– Description– Importance/urgence– Gains– Effets de bords– Aide des experts

ESUP-Days 7, Paris, 3 février 2009

Copyright 2008 ©

Tout le système concerné

• Architecture– Distribution de la charge, mise à jour frontal

• JVM– Passage en 32 bits, optimisations

• CAS– Mise à jour, redondance

• uPortal– Sécurisation, optimisations

• LDAP– Redondance

• Bases de données– Mise à jour, architecture matérielle, structuration des

donnéesESUP-Days 7, Paris, 3 février 2009

Copyright 2008 ©

Exemple de recommandation

• Frontal Apache : passer à Apache 2 et mod_proxy – Description

• mod_jk (Apache 1.3) utilisé aujourd’hui n’est plus supporté, il doit être remplacé par mod_proxy (Apache 2)

– Importance/urgence • Important, non urgent (à faire avant ou en même temps que le

passage à plusieurs serveurs virtuels). – Gains

• Possibilité de mise à jour pour la suite. – Effets de bord

• Modifier le script de détection de l’activité de Tomcat. – Aide des experts

• Configuration type de mod_proxy :LoadModule proxy_module modules/mod_proxy.soLoadModule proxy_ajp_module modules/mod_proxy_ajp.soProxyPass / ajp://localhost:8009/

ESUP-Days 7, Paris, 3 février 2009

Copyright 2008 ©

Interventions des experts

• Analyse du système– Une journée sur place– Compréhension des contraintes locales– Corrections rapides

• sécurité et continuité de service

– Émission rapide de recommandations

• Améliorations du système– Deux journées sur place– Transfert de compétences– Dernières recommandations (moyen et long terme)

ESUP-Days 7, Paris, 3 février 2009

Copyright 2008 ©

Le point de vue des experts

• Qu’attendre des experts ?– La compétence– Le « savoir-faire »

• Qu’attendent les experts ?– La compétence– La motivation

ESUP-Days 7, Paris, 3 février 2009

Copyright 2008 ©

Architecture suite à l’étude

• Plus robuste– Architecture

• Frontal web : serveur virtuel OpenVZ Debian - 256 Mo RAM - 4 Go disque

• Serveurs d’applications : 3 serveurs virtuels VmWare Debian 32 bits - 2 Go RAM - 10 Go disque

– Frontal• Serveur d’application protégé par le

frontal apache mod_proxy• Load balancing + scripts de

synchronisation

• Plus fiable– Sécurisation du socle et des

applications– Monitoring des applications

• Par Lambda Probe

• Plus évolutive– permet d’augmenter le nombre de

serveurs d’application et de réaliser des migrations simplement

ESUP-Days 7, Paris, 3 février 2009

MOD_PROXY

ENT1 ENT2 ENT3

MySQL v4 Oracle 9i

CLIENTS CAS v2

HTTPS

Copyright 2008 ©

Architecture à venir

• CAS– Passage en v3

• MySql– Passage en v5

• Serveurs de BDD– En « Actif - Actif » entre

MySQL et Oracle • Monitoring

– Cacti/Nagios ou Munin

ESUP-Days 7, Paris, 3 février 2009

MOD_PROXY

ENT1 ENT2 ENT3

MySQL v5 Oracle 10g

H.A.

CAS v3

CLIENTS

HTTPS