Exploitation

Introduction

Ce manuel contient des informations concernant des opérations d'installation et de maintenance (sauvegardes, mises à jour, ...) d'Ametys ODF. Il contient aussi diverses astuces qui pourront vous être utiles.

Il est conseillé de lire auparavant le manuel d'installation (version de démonstration ou serveur) de votre application, afin d'en connaître tous les concepts énoncés ici. Merci de lire également, s'il existe, le manuel d'installation complémentaire lié à votre projet, afin d'en connaître les spécificités : dans certains cas, des informations présentes ici peuvent ne pas être applicables.

Public visé

Ce manuel a été écrit pour les personnes souhaitant administrer le Ametys ODF, c'est-à-dire effectuer les opérations de maintenance telles que la sauvegarde, les mises à jour, etc...

Commentaires

Si vous avez besoin d'aide, ou si vous souhaitez nous faire part de vos suggestions, critiques, éloges, n'hésitez pas à demander de l'aide sur les forums. Vous pouvez aussi contribuer à l'amélioration de cette documentation en ajoutant vos propres commentaires.

Types de données

Ametys gère deux types de données.

Données principales (JCR)

Les données principales concernent les contenus, leurs méta-données, leurs pièces jointes, l'organisation des pages, le workflow... Elles sont gérées par l'API JCR 2.0 (JSR 238).
L'implémentation Apache JackRabbit (http://jackrabbit.apache.org) est utilisée car le stockage physique peut être réalisé de différentes manières : système de fichiers, base de données embarquée (DERBY), base de données classique (MySQL), ...
Afin de connaître toutes les implémentations et la manière de les configurer, vous pouvez consulter le site de JackRabbit.

Le fichier de configuration du Repository JackRabbit est WEB-INF/param/repository.xml.

Par défaut, Ametys utilise Derby et le système de fichiers, tout étant stockée dans le répertoire configuré (voir la page de configuration).

Données secondaires (SQL)

Les données secondaires peuvent être (selon la configuration de votre application) :

• les utilisateurs
• les groupes d'utilisateurs
• la gestion des droits
• ...

Elles sont stockées dans une base de données SQL (MySQL par exemple). La base de données choisie est visible dans les paramètres de configuration (voir la page de configuration).

Sauvegarder et Restauration

Sauvegarde

Pour sauvegarder les données, il est nécessaire de sauvegarder tous les types de données simultanément. Il faut effectuer les opérations suivantes :

• Stopper le serveur Tomcat pour assurer la cohérence des données.
• Copier le répertoire ‘data’ contenant les données principales (le chemin de ce répertoire est défini dans les paramètres de configuration de l'application).
• Effectuer un dump de la base de données contenant les données secondaires.
• Archiver l’ensemble des données en un fichier.
• Effacer les anciennes sauvegardes pour conserver l’espace disque.
• Relancer le serveur Tomcat.

Il est très important que tout soit sauvé simultanément, sinon des incohérences applicatives risquent d’arriver : il est donc conseillé d’effectuer ces opérations lorsqu’aucun utilisateur n’est connecté et qu’aucun travail automatique n’est en cours (en coupant le tomcat par exemple).

Il est conseillé d’effectuer une sauvegarde toutes les nuits, en utilisant un cron par exemple.

Restauration

Pour restaurer les données, il faut effectuer les opérations suivantes :

• Stopper le serveur Tomcat.
• Décompresser le fichier de sauvegarde dont le nom est en paramètre.
• Copier ce nouveau répertoire dans data.
• Importer le dump de la base de données.
• Relancer le serveur Tomcat.

Il est très important que tout soit restauré simultanément, sinon des incohérences applicatives risquent d’arriver : il est donc conseillé d’effectuer ces opérations lorsqu’aucun utilisateur n’est connecté et qu’aucun travail automatique n’est en cours.

Il est également conseillé de faire une sauvegarde juste avant la restauration, dans le cas où cette restauration se déroulerait mal.

Mise à jour

Pour mettre à jour Ametys ODF, il faut suivre les étapes suivantes :

• Installation les nouvelles versions des applications CMS et SITE
• Copie des fichiers de configuration et de données de la version précédente vers la nouvelle version
• Changement de la version courante vers la nouvelle version.
• Redémarrage des services.

Il peut également être nécessaire d'effectuer d'autres opérations, selon les indications du fournisseur de la mise à jour : scripts SQL par exemple (se référer au Manuel de Migration).
L'installation d'une nouvelle instance de l'application (sans données) est immédiatement réalisée avec la version la plus récente, et ne nécessite aucune mise à jour.

Avant d’exécuter une mise à jour il est important de vérifier l’espace disque disponible. Pour une application de 70 MO par exemple, il faut avoir 150 MO d’espace disponible, car une fois le fichier de 70 MO téléchargé il sera dé-zippé pour former l’application.

Les zips téléchargés et les anciennes versions sont conservés sur le disque : si après installation de la nouvelle version il est nécessaire de revenir à la version précédente, il faut couper les services et refaire basculer les liens symboliques sur l’ancien répertoire.

Il est rarement nécessaire de conserver plus de 2 anciennes versions : vous pouvez donc effacer les anciens répertoires (et fichiers zip) pour gagner de l’espace disque. Attention ! Les journaux ne sont pas conservés lors d’une mise à jour.

Démarrage / Redémarrage

Si vous avez suivi notre procédure d'installation, il faut utiliser les services correspondants (Apache Tomcat, Apache HTTPD…) par exemple en lançant la commande « /etc/init.d/tomcat start ».

Sinon, les processus de démarrage, arrêt et redémarrage dépendent de votre installation et de votre moteur de servlets. Par exemple sur Tomcat, il vous faudra surement exécuter les scripts de démarrage et d'arrêt (startup / shutdown) dans le répertoire bin.

Il arrive que l'appel au shutdown ne se termine pas correctement. Il faut donc vérifier après quelques secondes que le serveur est réellement arrêté, en regardant les processus qui tournent encore.

Cache

Cache du tomcat

On y trouve le fichiers JavaScript et CSS déjà servis.

Vider le cache du tomcat

Cache du site

On y trouve principalement les pages générées par l'application CMS pour être servies statiquement depuis l'application SITE.

Vider le cache du site

Vérification de l’état du système

Vérifier le tomcat

Il se peut que plusieurs tomcat tournent sur la même machine. Le retour de la commande permet de savoir le nombre de tomcat qui tournent, ainsi que leur « identité ».
Cette commande permet de s’assurer qu’un tomcat stoppé s’est bien arrêté.

Vérification des DNS

Si un serveur http est configuré : wget <mon_url> et vérifier que la page a bien été écrite.
Il arrive parfois qu’un serveur ait des problèmes d’accès aux autres machines réseaux, cela permet de vérifier que les serveurs ont bien accès entre eux.

Logs

Logs applicatifs

Les erreurs fonctionnelles sont généralement contenues dans les logs applicatifs. Ces logs sont configurés via le fichier WEB-INF/log4j.xml et stockés dans le répertoire WEB-INF/logs (voir le site de log4j pour plus de détails).
Ils peuvent être téléchargés directement depuis dans l'espace d'administration (voir la page dédie du manuel d'administration pour plus de détails).

Logs Système

Les erreurs d'Apache Tomcat sont stockées dans le répertoire Tomcat/logs. Le fichier catalina.out contient les informations de la console (notamment les informations de démarrage). Tomcat utilise aussi log4j.
Ces logs doivent être suivis et supprimés régulièrement, afin de ne pas remplir l'espace disque.

Afin de prévenir un disque plein qui pourrait povvenir de l’accroissement régulier des fichiers de logs (tomcat, CMS…) il est recommandé de supprimer les fichiers logs inutiles. Cette opération est disponible de l'espace administrateur.

Ressources système

Les applications ODF back-office et front-office sont des applications web JAVA.

Processeur

Mis à part des projets particuliers, Ametys ODF n'a pas besoin de beaucoup de CPU mais il peut être intéressant d'utiliser un multiple processors and multi-heart.

Mémoire

Le back-office peut devenir gourmand en mémoire en fonction du nombre d'utilisateurs (devrait être entre 512MB et 1GB pour plusieurs utilisateurs).
Le front-office n'est pas gourmand en mémoire quand il est principalement statique : dans ce cas, Tomcat est utilisé uniquement lors des recherches ou lors de la génération des autres pages dynamiques.

Au lancement, les options -Xms et -Xmx spécifient le minimum et le maximum de mémoire allouée. La JVM de Sun prend l'espace minimum et, chaque fois que c'est nécessaire, augmente l'espace sans dépasser la taille maximum; cependant il ne rend jamais la mémoire au système : il est donc important de considérer que cette mémoire n'est pas partageable. Si vous souhaitez savoir comment la mémoire est réellement utilisée par la JVM, vous pouvez regarder dans l'espace d'administration).

Dans le cas d'une OutOfMemoryException retournée par Java, cela peut venir de 2 types de mémoire :

• mémoire interne pour charger les classes allouées avec l'option maxPermSize. Elle dépend du nombre de librairies (fichiers jar) et de classes java chargées. Plus il y a d'applications utilisées dans Tomcat, plus cette mémoire doit être importante. En général on utilise 128 à 192Mo.
• mémoire du programme (celle dont on parle habituellement). En général on utilise 512Mo à 2 Go. Java ne sait pas comment gérer plus de 32Go sur des machines 32 bits. Chaque utilisateur qui effectue une requête sur le serveur a besoin de mémoire (qui dépend du type de requête) : il est donc impossible de prévoir l'espace nécessaire; seule notre expérience nous permet d'estimer la taille. Par exemple 50 petites requêtes utiliseront certainement moins de mémoire que 10 grosses. Il est possible de modifier le nombre de requêtes permises simultanément sur Tomcat, afin de résoudre certains problèmes. Les utilisateurs en attente auront un message du type serveur occupé.

Exemple de configuration des options relatives à la mémoire

Pour plus de détails à propos de la configuration de la JVM, reportez à la documentation JDK6/Virtual Machine.

Espace disque

L'espace disque utilisé par tout le système est difficile à prévoir. Il est constitué :

• des composants du système (Tomcat, Apache...)
• de l'application (environ 70Mo par version). Donc si vous mettez en place 5 mises à jour, vous allez utiliser 70 * 5 * 2 (taille de l'application * nombre de mises à jour * (cms + site)) + les fichiers zip téléchargés. Ceci peut prendre beaucoup de place. Les anciennes versions doivent donc être archivées ailleurs.
• de la base de données JCR, qui est gourmande est en espace disque. En effet, elle stocke toutes les versions successives de tous les contenus, donc elle grandit sans cesse. Un site web classique peut facilement prendre 100Mo uniquement avec des textes (donc sans les images et pièces jointes) pour une seule version du contenu. Après les 1ers mois d'utilisation (qui sont les plus intensifs), il est commun d'atteindre 500Mo. La taille du disque doit donc être extensible. Si le projet gère des vidéos, il faut le prendre en compte dans la prévision de l'espace disque.