Operation

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.

Target audience

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...

Comments

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.

Data types

Ametys gère deux types de données.

Main data (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).

Secondary data (SQL)

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

• the users
• user groups
• rights management
• ...

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

Backup

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 :

• Stop the Tomcat server to ensure data consistency.
• 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.
• Delete old backups to conserve disk space.
• Restart the server 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.

Catering

To restore data, perform the following steps:

• Stop the server Tomcat.
• Unzip the backup file whose name is specified in the parameter.
• Copier ce nouveau répertoire dans data.
• Importer le dump de la base de données.
• Restart the server 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.

It is also advisable to make a backup just before the restore, in case the restoration goes badly.

Update

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
• Change from current version to new version.
• Restart 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.

Before executing an update, it is important to check the available disk space. For a 70 MB application, for example, you need 150 MB of available space, because once the 70 MB file has been downloaded, it will be unzipped to form the application.

Downloaded zips and old versions are kept on disk: if after installing the new version you need to go back to the previous version, you need to shut down the services and switch the symbolic links back to the old directory.

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.

Start / Restart

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.

Sometimes, the shutdown call is not completed correctly. After a few seconds, check that the server has really stopped, by looking at the processes still running.

Cover

Cover for tomcat

You'll find the JavaScript and CSS files already served.

Empty the tomcat

Site cache

These are mainly pages generated by the CMS application to be served statically from the SITE application.

Vider le cache du site

System status check

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é.

DNS check

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

Application logs

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).

System logs

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.

System resources

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

Processor

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.

Memory

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é.

Example of memory settings

For more details on JVM configuration, please refer to the JDK6/Virtual Machine documentation.

Disk space

The disk space used by the entire system is difficult to predict. It consists of :

• system components (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.