FLASH INFORMATIQUE FI



Infrastructure du CMS de l’EPFL : derrière les décors de Jahia


Le système de gestion de contenu (CMS) Jahia 6.1 est en exploitation à l’EPFL depuis juin 2010. Hébergeant actuellement plus de 31’000 pages réparties sur 720 sites Web, disponible 7 jours/7, 24heures/24, il repose sur une infrastructure sophistiquée, présentée dans cet article.



Jahia 6.1, the corporate content management system, at EPFL, has been in use since June 2010. Hosting more than 31000 pages spread over 720 web sites, avalaible 7/7, 24/24, Jahier uses a complex infrastructure, presented in this paper.



Maciej MACOWICZ


Introduction

En 2002, l’EPFL s’est dotée de la première charte graphique institutionnelle pour les sites Web (Web 2000), élaborée dans le cadre du projet e-PFL [1] ; afin de simplifier l’édition des pages Web et garantir leur conformité avec la charte, celle-ci fut accompagnée d’un système de gestion de contenu (CMS) Jahia. Depuis sa mise en place, le CMS a rapidement gagné du terrain, en 2008 il gérait environ 20000 pages réparties sur 500 sites Web de l’École.
En 2008, le KIS a commencé l’élaboration de la charte graphique Web 2010 [2], ce fut pour nous une occasion de faire une évolution majeure du CMS ; à l’issue d’une vaste évaluation des solutions disponibles [3] nous avons retenu le CMS Jahia en version 6.1.
La mise en ligne des sites conformes à la charte Web 2010 a été prévue pour l’été 2010, les travaux sur le nouveau CMS avaient commencé au printemps 2009. Le projet Jahia 6 comportait trois volets : l’élaboration de l’architecture matérielle, le développement des chablons de présentation des contenus (templates), et finalement la migration (semi-automatique) des contenus depuis la version précédente de Jahia.
Plus de deux ans après la mise en production de Jahia 6, force est de constater que ce CMS est largement adopté par la communauté de l’EPFL (actuellement plus de 31000 pages réparties sur plus de 720 sites, dont les sites critiques tels les sites des facultés, de la Direction, des instituts, laboratoires et diverses unités d’administration) ; le CMS est actuellement stabilisé et fournit des performances satisfaisantes.
Dans cet article nous voudrions donner un aperçu de l’infrastructure que nous avons conçue pour le CMS de l’EPFL. Nous commencerons par une brève présentation du système Jahia et de ses évolutions, par la suite nous soulignerons quelques points d’implémentation de Jahia 4 qui nous ont permis d’identifier les besoins en matière de CMS institutionnel qui ont servi de cahier de charges. Dans la partie suivante, nous détaillerons l’architecture choisie pour Jahia 6 et présenterons ses performances, nous concluerons sur l’adéquation des solutions retenues par rapport au cahier des charges ainsi que par un aperçu de travaux en cours.

CMS Jahia

Jahia, le système de gestion de contenu institutionnel de l’EPFL a été élaboré par l’éditeur genevois Jahia Solutions. La version 6.1 du CMS se décline en deux éditions : l’édition communautaire est gratuite, mais offre des fonctionnalités assez limitées ; elle bénéficie du support de la communauté des utilisateurs. L’édition professionnelle offre des fonctionnalités nécessaires pour le déploiement dans l’entreprise ainsi que le support commercial. Le code source de Jahia est disponible sous une licence spécifique JSEL (Jahia Sustainable Enterprise License).
Le CMS Jahia a beaucoup évolué depuis le début des années 2000 : basé sur un serveur de contenu unique en version 3 [sortie en 2001, installé à l’EPFL pour la charte Web 2000 en 2002] et en version 4 [sortie en 2003, installé à l’EPFL en 2004 également pour Web 2000], il s’est progressivement ouvert aux hautes performances en offrant des architectures de cluster applicatif asymétriques (dont les noeuds peuvent jouer des rôles différents) dès la version 5. En termes de fonctionnalités, Jahia en version 3 permettait de gérer le contenu monolingue et ne proposait aucun workflow de publication. La version 4 de Jahia a introduit la gestion du contenu multilingue ainsi que les workflows de publication ; à partir de la version 5, Jahia proposait les fonctionnalités de copier/coller du contenu, la gestion avancée des sites (import/export conforme à la spécification JSR-170) et était censé améliorer la réactivité face à l’utilisateur en introduisant les processus asynchrones pour exécuter les tâches longues (par exemple pour publier le contenu).
La version actuellement installée à l’EPFL (6.1) améliore les interfaces utilisateurs (Ajax), introduit la publication planifiée et s’appuie sur l’architecture interne repensée, et utilise le répertoire Apache Jackrabbit (implémentation de référence de la spécification JSR-170) pour le stockage de documents. Elle permet également la mise en place de clusters synchronisés par le cache distribué ehcache.
Jahia est une application Java/J2EE lourde, la version 6.1 compte plus de 500’000 lignes de code source Java et utilise plusieurs frameworks Java/J2EE (Spring, Compass/Lucene, Hibernate, Pluto/JSR-168, Quartz, Jackrabbit/Java Content RepositoryJSR-170, Struts, GWT et bien d’autres).

Expériences Jahia 3 et 4 à l’EPFL

Jahia en version 3, installé en 2002, a commencé à poser des problèmes de performances déjà après quelques mois d’utilisation, notre unique serveur est arrivé au point de saturation après la création de 130 sites et 8’000 pages. Hélas, Jahia 3 ne supportait pas d’architectures modulaires (clusters), cela nous a obligés à installer un deuxième serveur en scindant (manuellement) les contenus en deux. Le même problème s’est posé plus tard avec le deuxième serveur, nous nous sommes finalement retrouvés avec trois serveurs indépendants, dont chacun servait une partie de sites Web, était muni de sa propre base de données et de son propre espace disque pour le stockage de fichiers.
Lors de l’exploitation de Jahia 3, puis de Jahia 4 nous avons identifié un certain nombre de problèmes que nous voulions éviter dans la prochaine version du CMS. Parmi les plus importants, citons :

  • robustesse, performances et tenue en charge : les serveurs Jahia 3/4 étaient peu fiables, les saturations et les pannes étaient très fréquentes. La situation était partiellement due à l’obsolescence de la machine virtuelle Java (JVM, version 1.4) et du serveur d’application J2EE (Tomcat 4), et s’est considérablement améliorée après le passage à la JVM 1.6 et Tomcat 5 ;
  • manque de scalabilité : avec la croissance du contenu, les performances du serveur se dégradaient ;
  • peu de souplesse : impossibilité de migrer les sites entres les serveurs ;
  • difficultés de garantir la disponibilité du contenu 7j/7 et 24h/24 : nous avons dû ajouter un serveur de secours (failover) qui récupérait et servait les versions statiques du contenu en cas d’indisponibilité de serveurs de production. Le basculement entre les serveurs de production et de secours se faisait alors à la main, à travers une application Web dédiée.

Évolution du CMS – vers Jahia 6

En 2008, nous avons commencé la préparation de l’évolution du CMS ; dans le cahier des charges, nous avons (entre autres) identifié les besoins suivants :

  • Disponibilité du contenu en consultation : 24h/24, 7j/7, basculement automatique entre les serveurs de production et les serveurs de secours en cas de panne.
  • Scalabilité et possibilité de migration des sites entre les serveurs.
  • Volumétrie du contenu : 40’000 pages (dont 30% protégées), réparties sur mille sites
  • Charge en consultation : 7’000’000 pages/mois, 300’000 pages/jour, pic de 25 pages/s, 20% d’accès authentifiés, temps de réponse <= 1s.
  • Charge en contribution : 5’000 éditeurs, 180’000 opérations/mois, pic de cent éditions simultanées, temps de réponse <= 3s pour les opérations courantes d’édition.

Nous avons commencé la mise en place du cluster Jahia 6.1 en septembre 2009, la mise en production interne a eu lieu le 18 juin 2010 pour permettre la migration des sites depuis Jahia 4 pendant les vacances d’été, la mise en production officielle a finalement eu lieu le 6 septembre 2010. En novembre 2011 nous avons fermé tous les services Jahia4 [4], la plupart des contenus ayant été migrés vers Jahia6 ; à ce jour Jahia 6 gère plus de 31’000 pages réparties sur 720 sites Web.

architecture du cluster Jahia6 à l’EPFL

Infrastructure de Jahia 6 à l’EPFL

Jahia 6 permettant la mise en place des clusters composés de plusieurs machines, nous avons implémenté une architecture asymétrique à trois noeuds, dont deux servent le contenu en consultation (lecture) seule, et dont un permet l’édition du contenu. Tous les noeuds Jahia sont des serveurs physiques, dotés de deux processeurs Xeon Quad Core cadencés à 3.33 GHz et de 16GB de mémoire vive. Pour améliorer la résilience, les serveurs de consultation sont placés dans deux salles serveurs différentes (IN-J et MA).
Les noeuds du cluster Jahia partagent deux ressources communes :

Afin de garantir la disponibilité du contenu 24h/24 et 7j/7, en particulier pendant les périodes de maintenances/pannes, le cluster Jahia est accompagné de deux noeuds de secours (failover, machines virtuelles), qui récupèrent chaque nuit tous les contenus publics (pages et fichiers) hébergés sur les serveurs Jahia dans un espace disque accessible via un serveur httpd (apache). Les noeuds de secours répondent aux mêmes requêtes que les noeuds Jahia de consultation, et sont également redondants, placés dans deux salles serveurs différentes.

Les noeuds Jahia et les noeuds de secours sont placés derrière le répartiteur de charge (Content Switch) [5] et regroupés en trois pools :

  • pool de consultation (noeuds Jahia de consultation en lecture seule) ;
  • pool de contribution ( noeud Jahia de contribution en lecture/écriture) ;
  • pool de secours (noeuds de failover statique en lecture seule).

Le répartiteur de charge distribue les requêtes sur les noeuds en fonction de la charge et de la disponibilité de ceux-ci ; pour déterminer la disponibilité, il applique des règles suivantes :

  • l’état de chaque noeud est testé toutes les deux minutes. Si un noeud n’est pas disponible pendant 6 minutes (3 tentatives), il est exclu du pool et ne reçoit plus de requêtes. S’il ne reste plus aucun noeud actif dans un pool, celui-ci est automatiquement désactivé et le répartiteur de charge bascule le trafic sur le pool de secours ;
  • le répartiteur de charge remet un noeud dans un pool si celui-ci devient actif en activant le pool le cas échéant ;
  • une requête ne nécessitant pas l’authentification est envoyée sur un noeud de consultation (le répartiteur de charge choisit alors le noeud le moins chargé). Le noeud renvoie alors un cookie de session, qui lie le client au serveur donné pendant cinq minutes ;
  • une requête nécessitant l’authentification (identifiée par l’URL) est redirigée sur le serveur de contribution, qui procède à l’authentification de l’utilisateur (via le système SSO Tequila) et renvoie au client un cookie de session, qui le lie au serveur pendant 30 minutes (durée de session utilisateur en contribution).

Les responsables d’exploitation du CMS sont avertis par mail en cas de changement d’état du cluster (indisponibilité d’un noeud et/ou d’un pool) ; en plus, chaque noeud du CMS est constamment surveillé par le système Nagios ; celui-ci envoie des mails (ou des SMS en cas d’anomalie prolongée au-delà de 4 heures) d’avertissement en cas de :

  • indisponibilité de Jahia sur un noeud (panne Jahia), c’est-à-dire incapacité à répondre aux requêtes ;
  • problèmes d’accès à la base des données ;
  • problèmes d’accès aux fichiers sur le NAS.

L’infrastructure de production de Jahia utilise également les différents services de l’EPFL, tels que le système d’authentification Tequila, le répertoire institutionnel LDAP, et les moteurs de recherche search.epfl.ch et Google Search Appliance.

Afin de pouvoir effectuer des tests de charges, des tests fonctionnels divers et le débogage, nous avons conçu une infrastructure de test très similaire à celle de production, comportant également cinq noeuds (consultation x2, contribution, failover x2, machines virtuelles).

Performances

À ce jour (12.10.2012) le CMS Jahia gère exactement 31’049 pages, dont 2’189 protégées, réparties sur 722 sites. Les résultats présentés ci-dessous proviennent de la période du 10.09 au 11.10.2012.

Les performances du CMS en consultation :

  • nombre d’accès : en moyenne 226’000 pages consultées par jour, tous accès confondus (consultation directe, passage de robots des moteurs de recherche, construction du failover et les accès du moniteur Nagios), donc environ 6’800’000 accès par mois ;
  • la charge observée est comprise entre 0 et 83 pages/s, la moyenne est de 2.6 pages/s ; les pics de charge sont souvent causés par des tentatives d’attaque. Notons que les requêtes sont mesurées après leur exécution, les pics peuvent également représenter les fins des périodes de saturation ;
  • nous avons pu constater 159 brèves (< 2 minutes) périodes de saturation (non-disponibilité) de noeuds de consultation. Dans 12 cas le problème affectait deux noeuds de consultation simultanément, causant des temps de réponse longs aux clients. Le cluster Jahia a cependant pu récupérer sans redémarrage ;
  • les temps de réponse en consultation sont compris entre 1ms et 4 minutes, la moyenne s’élève à 400ms ; la moitié des accès (médiane) se fait en moins de 20ms, 90% des accès en 1.1s ; 98.5% de requêtes sont servies en moins de 3s, et 99.5% - en moins de 5s, et finalement 99.9% en moins d’une minute. Les accès lents sont souvent dus soit à la lenteur d’inclusion dynamique de fragments HTML et/ou de flux XML provenant des serveurs tiers dans les pages Jahia, soit à la saturation temporaire des noeuds Jahia.

Les performances en contribution sont plus difficiles à mesurer : certains traitements se font de manière asynchrone (publication des pages) et les données relatives aux performances ne sont pas encore collectées. Les statistiques du noeud de contribution :

  • nombre moyen d’opérations d’édition par jour s’élève à 4050, soit 125’000 opérations par mois. Ce nombre ne tient pas compte de processus asynchrones lancés par Jahia pour les tâches longues (par exemple pour publier une collection de pages) ;
  • nous avons constaté 18 brèves périodes de saturations du noeud ;
  • les temps de réponse du serveur se situent entre 1ms et 7 minutes. La médiane est s’élève à 256ms, la moyenne à 1.1s. 90% de requêtes sont servies en moins de 2.3s, 92.6% en moins de 3s, 98.25% moins de 10s ; et finalement 99.97% en moins d’une minute.

Soulignons que ces données sont collectées dans les logs des serveurs, donc représentent les performances brutes des serveurs, le temps mesuré par l’utilisateur devrait tenir compte de trafic réseau, inclusion des feuilles de style ou script Javascript etc.

Conclusion et travaux en cours

L’infrastructure du CMS que nous avons mise en place correspond grosso modo au cahier de charges défini ; en reprenant les principaux points :

  • disponibilité du contenu en consultation : 24h/24, 7j/7 est assuré par les serveurs de secours, le basculement est entièrement automatique grâce au répartiteur de charge.
  • volumétrie du contenu : nous en sommes actuellement à 75% des chiffres définis dans le cahier de charges, tant en nombre de pages qu’en nombre de sites. La proportion des pages protégées est plus faible qu’assumée au départ (7% au lieu de 30%).
  • charge en consultation : nous approchons de chiffres assumés, les temps de réponse sont satisfaisants, mais les lenteurs doivent être cernées et les éléments en cause optimisés.
  • nous devons mettre en place un monitoring plus détaillé du noeud de contribution, ce que nous pouvons observer nous semble satisfaisant, sachant que les opérations asynchrones ne sont pas prises en compte ;
  • notons que la migration de sites entre serveurs n’a plus de sens dans l’infrastructure actuelle : tous les sites sont gérés par tous les serveurs.

Nous avons actuellement deux problèmes majeurs avec l’infrastructure Jahia : (1) les saturations évoquées ci-dessus, et (2) la lenteur du démarrage du cluster Jahia : actuellement le démarrage d’un noeud prend près d’une heure, et les noeuds doivent être démarrés l’un après l’autre.
Nous mettons en place un système de monitoring permanent de performances du CMS, collectant des données plus détaillées sur différents éléments (à savoir les machines virtuelles Java, l’application Java/J2EE Jahia, la base des données, ...). Les données ainsi collectées nous permettront d’optimiser ces éléments et d’améliorer la qualité de service Jahia à l’EPFL.

Références

[1] MEYSTRE Natalie. Recommandations pour l’édition et la mise en page des sites Internet de l’EPFL. FI4/2002, EPFL 2002.
[2] MEYSTRE Natalie, MELLIER Pierre, GROSSE Jérome. Web 2010. FI5/2010. EPFL 2010.
[3] MEYSTRE Natalie. Content Management System de l’EPFL, serez-vous tous contents ? FI4/2009, EPFL 2009.
[4]MEYSTRE Natalie. Avis de décès de Jahia4. FI7/2011, EPFL 2011.
[5]GRANDJEAN Daniel, AUBRY Georges. Server Load Balancing, le réseau s’en charge. FI6/2008, EPFL 2008.



Cherchez ...

- dans tous les Flash informatique
(entre 1986 et 2001: seulement sur les titres et auteurs)
- par mot-clé

Avertissement

Cette page est un article d'une publication de l'EPFL.
Le contenu et certains liens ne sont peut-être plus d'actualité.

Responsabilité

Les articles n'engagent que leurs auteurs, sauf ceux qui concernent de façon évidente des prestations officielles (sous la responsabilité du DIT ou d'autres entités). Toute reproduction, même partielle, n'est autorisée qu'avec l'accord de la rédaction et des auteurs.


Archives sur clé USB

Le Flash informatique ne paraîtra plus. Le dernier numéro est daté de décembre 2013.

Taguage des articles

Depuis 2010, pour aider le lecteur, les articles sont taggués:
  •   tout public
    que vous soyiez utilisateur occasionnel du PC familial, ou bien simplement propriétaire d'un iPhone, lisez l'article marqué tout public, vous y apprendrez plein de choses qui vous permettront de mieux appréhender ces technologies qui envahissent votre quotidien
  •   public averti
    l'article parle de concepts techniques, mais à la portée de toute personne intéressée par les dessous des nouvelles technologies
  •   expert
    le sujet abordé n'intéresse que peu de lecteurs, mais ceux-là seront ravis d'approfondir un thème, d'en savoir plus sur un nouveau langage.