Techniques de reprise sur sinistre de la mémoire de messages de Sun Java System Messaging Server
Joe Sciallo, octobre 2007
Cet article décrit les stratégies de sauvegarde et de restauration générales de la mémoire de messages de Sun Java System Messaging Server, de même que les procédures de récupération à partir de problèmes de mémoire de messages spécifiques rencontrés avec les éléments suivants :
Boîte aux lettres individuelle
Plusieurs boîtes aux lettres sur une seule partition (ou sur une partition entière)
Boîtes aux lettres multiples sur plusieurs partitions (ou sur un hôte de mémoire de messages entier)
Boîtes aux lettres multiples sur plusieurs hôtes de mémoire de messages
Cet article a été rédigé conjointement par des administrateurs système de l'Université du Wisconsin (Madison) et des développeurs de la mémoire de messages de Messaging Server chez Sun.
Cet article technique aborde les sujets suivants :
Présentation de l'architecture de Messaging Server
Un déploiement de Messaging Server se compose de différentes classes de fonctionnalités, notamment d'un annuaire LDAP, d'agents de transfert de messages (MTA, Message Transfer Agent), de multiplexeurs de messagerie (MMP, Messaging Multiplexor) et de mémoires de messages d'arrière-plan. Vous pouvez concevoir l'annuaire LDAP, les MTA et les MMP à des fins de redondance. Ainsi, si un ou plusieurs hôtes deviennent indisponibles, le service reste opérationnel sans que les utilisateurs finaux ne s'aperçoivent d'une quelconque interruption des performances. La couche de mémoires de messages d'arrière-plan se différencie des autres en ceci qu'en cas d'indisponibilité d'une mémoire de messages, les utilisateurs qui se servaient de celle-ci rencontrent une interruption de service. En conséquence, pour assurer la restauration du service suite à une panne, vous devez planifier et documenter des procédures de gestion des problèmes de mémoire de messages.
Présentation de l'architecture de la mémoire de messages
La mémoire de messages contient les boîtes aux lettres des utilisateurs d'une instance spécifique de Messaging Server. La taille de la mémoire de messages augmente en fonction du nombre croissant de boîtes aux lettres, de dossiers et de fichiers journaux. Vous avez la possibilité de contrôler la taille de la mémoire en limitant celle des boîtes aux lettres (quotas de disque) et le nombre total de messages autorisés et en définissant des stratégies d'expiration s'appliquant aux messages contenus dans la mémoire.
La mémoire de messages elle-même se compose d'un certain nombre de bases de données de boîtes aux lettres et de boîtes aux lettres utilisateur. Les bases de données de boîtes aux lettres comprennent des informations sur les utilisateurs, les boîtes aux lettres, les partitions, les quotas et d'autres données liées aux mémoires de messages. Les boîtes aux lettres utilisateur contiennent les messages et les dossiers des utilisateurs. Elles sont stockées dans une partition de la mémoire de messages, une zone d'une partition de disque spécialement dédiée au stockage de la mémoire de messages. Les partitions de mémoire de messages et les partitions de disque sont deux choses différentes, même si, pour faciliter la maintenance, il est préconisé d'utiliser une partition de disque pour chaque partition de mémoire de messages.
Les boîtes aux lettres telles que les boîtes de réception (INBOX) se trouvent dans le répertoire store_root. Voici un exemple de chemin d'accès à ce répertoire :
Implémentation d'une stratégie de sauvegarde et de restauration de mémoire de messages
La sauvegarde et la restauration de mémoire de messages comptent parmi les tâches administratives primordiales de votre déploiement de mémoires de messages. Vous devez implémenter une stratégie relative à ces tâches afin de vous assurer que les données ne seront pas perdues si des problèmes tels que les suivants surviennent :
Panne système
Panne matérielle
Suppression accidentelle de messages ou de boîtes aux lettres
Problèmes lors de la réinstallation ou de la mise à niveau d'un système
Catastrophes naturelles (tremblement de terre, incendie, tempête, etc.)
Migration d'utilisateurs
Les choix suivants s'offrent à vous pour sauvegarder et restaurer la mémoire de messages. Vous devez bien évaluer les aspects positifs et négatifs de chacune de ces solutions afin de choisir la solution la plus indiquée dans le cadre de votre déploiement.
Utilitaires de ligne de commande imsbackup et imsrestore. Ces utilitaires sont lourds en termes d'utilisation de la CPU et d'opérations d'entrée/sortie par seconde, mais ils vous permettent réellement de mettre en parallèle des processus de sauvegarde, de même que de séparer des partitions destinées à plusieurs canaux de sauvegarde. Par défaut, un seul canal de sauvegarde est utilisé, mais vous pouvez modifier ce paramètre pour en utiliser dix au maximum. La principale raison justifiant le choix de cette solution est qu'elle permet de restaurer des services pendant que le système est actif. Ainsi, dans le cas d'une véritable panne catastrophique, vous pouvez afficher une mémoire de messages vide, relancer l'arrivée de nouveaux messages, que les utilisateurs peuvent lire, puis, en l'espace de quelques heures ou jours, vous pouvez restaurer les anciens messages.
« Création d'instantanés » ou autre solution de sauvegarde basée sur les blocs. Ces solutions ont un impact bien moindre sur le serveur que l'utilitaire imsbackup. Toutefois, lors de la restauration des services, vous devez procéder à une restauration complète avant de pouvoir réactiver les services.
Bien que les données de mémoire de messages soient relativement robustes, il peut arriver, en de rares occasions, qu'elles rencontrent des problèmes. Messaging Server consigne dans le fichier journal par défaut les messages d'erreur signalant des problèmes de mémoire de messages. Depuis la version 6.3 de Messaging Server, le logiciel corrige presque systématiquement ce genre de problème de manière transparente. Dans de rares cas, le système consigne un message d'erreur dans le fichier journal lorsque vous devez exécuter l'utilitaire reconstruct.
Appliquez les techniques suivantes dans le cadre d'une approche générale du dépannage d'une mémoire de messages :
Chaque fois que le processus stored est redémarré, consultez le journal par défaut afin d'y repérer d'éventuels messages d'erreur ou instructions d'exécution des commandes de réparation de mémoire (telles reconstruct-m). Les fichiers journaux se trouvent dans le répertoire /opt/SUNWmsgsr/data/log à moins que vous n'ayez modifié le chemin par défaut. Des messages d'erreur s'afficheront probablement lors de l'arrêt et du démarrage de la mémoire de messages. Suivez les instructions figurant dans le journal. Pour plus d'informations, reportez-vous à la section Repairing Mailboxes and the Mailboxes Database du document Sun Java System Messaging Server 6.3 Administration Guide.
Essayez d'isoler le problème en localisant une boîte aux lettres, une partition, un hôte ou une dépendance spécifique. Puis, si nécessaire, appliquez les procédures décrites dans la prochaine section, Récupération à partir de problèmes de mémoire de messages.
Récupération à partir de problèmes de mémoire de messages
Prérequis pour toute tentative de récupération de boîtes aux lettres
Les procédures de récupération de boîtes aux lettres décrites dans cette section supposent que vous maîtrisez :
Vos propres déploiement et configuration de mémoires de messages, notamment les hôtes Messaging Server, la disposition des partitions, les chemins d'accès aux répertoires du logiciel Messaging Server, etc.
Identification d'un compte utilisateur sur un disque à l'aide de la commande hashdir
Utilisation des commandes de Messaging Server telles que reconstruct, mboxutil, start-msg et stop-msg
Vérification des journaux de Messaging Server et du système d'exploitation
Remarque : depuis la version 6.0 de Messaging Server, lorsque des utilisateurs se connectent au logiciel et que leur boîte aux lettres ne figure pas dans le fichier folder.db, le système insère immédiatement la boîte aux lettres dans le fichier folder.db en même temps que d'autres données récupérées. Vous pouvez appliquer la commande reconstruct-r au dossier à ce stade si vous pensez que le fichier store.idx a été endommagé. Sinon, le dossier fonctionnera normalement. Depuis la version 6.0 de Messaging Server, une fonction de correction des erreurs a été ajoutée afin de faciliter la correction du fichier store.idx lors de la connexion d'un utilisateur. Néanmoins, il est vivement recommandé d'exécuter la commande reconstruct en cas de problèmes graves.
Récupération d'une boîte aux lettres individuelle
Cette tâche décrit la procédure d'utilisation de la commande reconstruct en vue de récupérer des boîtes aux lettres individuelles, de même que les différences existant entre Messaging Server 6 et iPlanet Messaging Server 5.
Depuis la version 6.0 de Messaging Server, vous pouvez immédiatement lancer la mémoire de messages et les utilisateurs peuvent se connecter pendant que la commande reconstruct est exécutée à l'arrière-plan. Le processus stored tente d'effectuer les opérations nécessaires en vérifiant si la base de données n'accumule pas de journaux et ainsi de suite. En cas de problème, le processus stored remplace la base de données par un instantané ou supprime la base de données afin d'éviter à l'administrateur de s'en charger.
Dans le cadre d'un déploiement d'iPlanet Messaging Server 5, avant de procéder à la récupération d'une boîte aux lettres particulière ou d'un nombre restreint de boîtes aux lettres, considérez s'il est indiqué ou pas d'autoriser les utilisateurs à accéder au système avant la résolution du problème des boîtes aux lettres. Dans la plupart des cas, cela peut permettre à un grand nombre de personnes de travailler pendant qu'un petit nombre de boîtes aux lettres est indisponible. À première vue, cela semblerait souhaitable, mais n'oubliez pas que les problèmes rencontrés sur des comptes individuels pourraient entraîner une interruption de service à grande échelle. Évaluez ce risque par rapport aux avantages que constitue le maintien de l'accès au système pour la majorité des utilisateurs avant la fin des réparations.
Avant de commencer
La mémoire de messages doit être en cours d'exécution. Les utilisateurs peuvent être connectés et accéder à la mémoire de messages.
Identifiez et reconstruisez les comptes posant problème :
reconstruct -r
où :
-r
répare les zones de spool de toutes les boîtes aux lettres au sein du répertoire de la partition utilisateur.
La commande suivante est appliquée à l'ensemble de la mémoire et recherche les incohérences sans toutefois apporter de modifications. Pour indiquer une partition unique ou un modèle, référez-vous aux exemples suivants :
Dans le dernier exemple, exécutez une telle commande reconstruct pour chaque lettre. Cette commande vérifie uniquement les boîtes de réception.
Exécutez la commande mboxutil afin de déterminer si la boîte aux lettres est absente des bases de données du système de messagerie.
Si tel est le cas, passez à l'étape 3. Sinon, exécutez la commande suivante :
reconstruct -m -p partition -u userid
La mémoire de messages devrait dorénavant fonctionner correctement, y compris pour cet utilisateur.
Si la boîte aux lettres ne se trouve pas dans les bases de données du système de messagerie, procédez comme suit :
Créez la boîte aux lettres.
mboxutil -c user/userid/INBOX
Créez les autres dossiers non système.
mboxutil -c user/userid/foldername
Cela entraîne la génération d'un fichier store.idx vide et d'une entrée de base de données.
Exécutez la commande suivante afin de remplir les fichiers store.idx.
reconstruct -rf user/userid
L'option -f indique à reconstruct d'ignorer les erreurs de décompte d'index.
La mémoire de messages devrait dorénavant fonctionner correctement, y compris pour cet utilisateur.
Récupération de plusieurs boîtes aux lettres sur une partition unique (ou entière)
Avant de commencer
Informez les utilisateurs de la nécessité d'arrêter et de redémarrer la mémoire de messages.
Arrêtez la mémoire de messages et toutes les autres tâches de messagerie afin de désactiver d'éventuels verrous de base de données (DB, database).
stop-msg
Redémarrez la mémoire de messages.
start-msg store
La mémoire de messages tente de s'initialiser et commence à traiter les journaux de transactions. Pendant la progression de la mémoire de messages, vous pouvez démarrer les autres démons de Messaging Server (à l'aide des commandes start-msg ou start-msg imap, start-msg http, etc.), à condition de procéder graduellement.
Si la mémoire de messages ne parvient pas à s'initialiser correctement, le meilleur candidat de sauvegarde de la mémoire est restauré (bases de données et journaux de transactions compris). Vous êtes ensuite invité à exécuter la commande reconstruct-m.
Cette étape est indispensable pour prendre en compte les transactions vidées par la restauration. Si la version restaurée comprend plusieurs journaux de transactions, attendez quelques minutes avant de démarrer progressivement les processus de Messaging Server. Exécutez ensuite la commande reconstruct.
Récupération de plusieurs boîtes aux lettres sur plusieurs partitions (ou sur un hôte de mémoires de messages entier)
La récupération de plusieurs partitions s'apparente à celle d'une partition unique, à ceci près que vous devez choisir de restaurer toutes les partitions simultanément ou d'exécuter une commande distincte pour chacune d'elles.
En présence de plusieurs partitions, choisissez entre les deux commandes suivantes.
L'avantage de la première option consiste à ne contrôler qu'un seul processus. La seconde option prend moins de temps que l'exécution d'un seul processus, car les processus peuvent fonctionner en parallèle. Cependant, vous devez exécuter et contrôler plusieurs processus.
Récupération de plusieurs boîtes aux lettres sur plusieurs hôtes de mémoires de messages
Si plusieurs hôtes rencontrent des problèmes, l'origine se trouve très probablement dans l'infrastructure sous-jacente. Les causes possibles comprennent (sans que cette liste ne soit exhaustive) les suivantes :
Espace de stockage de l'entreprise
Annuaire LDAP
Alimentation ou environnement
Réseau
Système d'exploitation et patchs
Consultez le journal du système de messagerie, situé par défaut dans le répertoire /opt/SUNWmsgsr/data/log.
Un message d'erreur peut vous indiquer l'origine du problème sous-jacent.
Sinon, consultez les journaux système. (Sous Solaris, commencez par ouvrir /var/adm/messages).
L'accumulation de journaux de transactions est symptomatique d'un blocage de base de données dû à un interblocage excessif ou à un verrou orphelin créé par la fermeture inopinée (interruption comprise) d'un processus.
Depuis la version 6.2 de Messaging Server, l'accumulation de fichiers journaux est contrôlée et des messages d'avertissement sont imprimés. Le programme chien de garde enregistre et signale les processus en panne pouvant laisser des verrous orphelins. En outre, une option de redémarrage automatique est disponible.
Remarque : des fonctions de produits en cours de développement devraient permettre de lancer immédiatement la mémoire de messages et de détecter les dossiers détenus par les utilisateurs avant l'exécution de la commande reconstruct-m.
Messaging Server 6.3 comprend un nouveau programme permettant de vérifier les instantanés. Cela permet de résoudre le cas de figure où l'endommagement de la base de données se propage de la base de données active aux instantanés. Si vous exécutez Messaging Server 6.3, les instantanés de base de données sont automatiquement configurés au moyen de l'utilitaire imdbverify. De cette manière, vous automatisez la récupération de bases de données. Le cas échéant, vous pouvez configurer une fréquence d'exécution de la commande imdbverify plus élevée.
Mise en garde : il est très peu probable que la base de données soit endommagée. N'essayez pas de manipuler manuellement la base de données sauf en dernier ressort. Si vous finissez par tenter de corriger la base de données manuellement, n'oubliez pas d'en informer le centre de support de Sun dans le cadre d'une collaboration ultérieure en vue de résoudre ce problème.
Pour identifier une base de données bloquée
Avez-vous rencontré l'un des symptômes suivants ?
Une seule mémoire de messages pose problème.
Les messages se sont accumulés dans le canal ims-ms. (Servez-vous de la commande imsimta qm summarize pour afficher les événements survenant sur le système.)
Certains utilisateurs sont bloqués sur une mémoire de messages. Consultez les journaux présentant des informations de progression.
Certaines tâches de mémoire de messages, telles que les points de contrôle par utilisateur et l'expiration le soir, ne sont pas terminées.
Vérifiez la base de données de la mémoire de messages et les informations de verrouillage.
Messaging Server 6.3 : exécutez la commande imcheck -s pour vérifier le contenu de la base de données de la mémoire de messages et les informations de verrouillage.
Versions de Messaging Server antérieures à la 6.3 : exécutez la commande db_stat. Commencez par vérifier l'emplacement du répertoire /var/chemin/store/tmp à l'aide de la commande configutil -o store.dbtmpdir. Si cette valeur n'est pas définie, la valeur par défaut correspond au répertoire de la base de données de la mémoire, msg_path/data/store/mboxutil/. Dès lors que vous avez identifié l'emplacement du répertoire store/tmp, exécutez la commande db_stat en commençant par basculer sur l'utilisateur de Messaging Server (par exemple, mailsvr) :
su msg_usermsg_path/lib/db_stat -t -h /var/path/store/tmp
À ce stade, vous visualisez plusieurs fichiers journaux de transactions sous la forme log.000000xxxx.
Vérifiez la présence d'éventuels verrous de base de données persistants pouvant signaler un verrou orphelin. Exécutez plusieurs fois la commande afin de voir si des verrous disparaissent.
Pour en savoir plus
Consultez les sources suivantes pour obtenir plus d'informations sur la sauvegarde, la récupération et le dépannage de mémoires de messages :
Print-friendly Version
