- Introduction
- Public visé
- Types de données
- Sauvegarde et restauration
- Mise à jour
- Démarrage / Redémarrage
- Cache
- Vérification de l’état du système
- Logs
- Ressources système
Introduction
Ce manuel contient des informations concernant des opérations d'installation et de maintenance (sauvegardes, mises à jour, ...) du CMS Ametys V4. Il contient aussi diverses astuces qui pourront vous être utiles.
Il est conseillé de lire auparavant les pages précédentes de ce manuel, ou d'avoir lu le manuel d'administration 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.
Cette section possède des annexes documentant la Duplication d'environnement et de données et les Modifications d'URL
Public visé
Ce manuel a été écrit pour les personnes souhaitant administrer le CMS, 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
Le CMS 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é dans le dossier data de la variable d'environnement AMETYS_CMS_HOME. Ametys offre aussi la possibilité d'utiliser une base de données pour stocker ses données principales.
Données secondaires (SQL)
Les données secondaires peuvent être (selon la configuration de votre CMS) :
- les utilisateurs
- les groupes d'utilisateurs
- la gestion des droits
- ...
Elles sont stockées dans une base de données SQL (MySQL par exmple). La base de données choisie est visible dans les paramètres de configuration (voir le manuel d'administration du CMS, rubrique configuration).
Sauvegarde 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.
- Effectuer un dump des différentes bases de données utilisées dans votre application (voir la configuration de l'application).
- Faire une archive avec le contenu du répertoire indiqué par la variable d'environnement AMETYS_CMS_HOME et les dumps de base de données.
- 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 de survenir : 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 serveur Tomcat par exemple).
Vous avez la possibilité d'effectuer une sauvegarde toutes les nuits en utilisant une tâche CRON et un script pour automatiser la tâche.
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.
- Remplacer le contenu du répertoire défini dans AMETYS_CMS_HOME par les données de votre archive.
- Importer les dumps de 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 de survenir : 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 serveur Tomcat par exemple).
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 le CMS Ametys, il faut suivre les étapes suivantes :
- Installation les nouvelles versions des applications CMS, SITE et Solr.
- Arrêt des services CMS, Site et Solr.
- 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 (se référer au Manuel de Mise à jour).
L'installation d'une nouvelle instance du CMS (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.
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 « service 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
# Effacer le répertoire work (tomcat doit être arrêté) rm -rf /opt/tomcat/current/tomcat/work # Effacer le contenu du répertoire temp (et non le répertoire en lui-même) rm -rf /opt/tomcat/current/temp/*
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 (en ligne de commande)
cd $AMETYS_CMS_HOME rm -rf cache
Cette opération peut être réalisée depuis l'espace d'administration du back-office (<url backoffice>/_admin)
Vérification de l’état du système
Vérifier Tomcat
ps waux | grep 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
ping <mon_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 $AMETYS_CMS_HOME/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 : Journaux de l'application).
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 supprimer l'espace disque.
Afin de prévenir un disque plein qui pourrait provenir 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 du cms.
Ressources système
Nous vous conseillons de consulter la page 2. Pré-requis et recommandations
Le CMS, SITE et Solr sont des applications web JAVA.
Processeur
Mis à part des projets particuliers, le CMS 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 CMS peut devenir gourmand en mémoire en fonction du nombre d'utilisateurs (devrait être entre 4G et 12G pour plusieurs utilisateurs).
Le SITE n'est pas gourmand en mémoire (1G à 2G).
Solr peut également être gourmand en mémoire en fonction du nombre d'utilisateurs, notamment au moment du lancement où un cache est calculé pour être optimal par la suite, la configuration par défaut est souvent suffisantes (1G, mais il peut être nécessaire de l'augmenter jusqu'à 6G via la variable d'environnement SOLR_HEAP).
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 (page Etat du système).
Dans le cas d'une OutOfMemoryException retournée par Java:
- mémoire du programme (celle dont on parle habituellement). En général on utilise 4G à 13G. 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
-Xms2G -Xmx6G
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 250Mo par version). Donc si vous mettez en place 5 mises à jour, vous allez utiliser 250 * 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 1G 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 3G voir beaucoup plus lors du stockage de fichiers PDF, vidéos.... La taille du disque doit donc être extensible.
- des index pour l'application Solr
Retour en haut