Partager via

Planification de capacité – Oui, l’espace des journaux de transactions est critique pour l’intégrité et le montage de vos bases de données

  • Article

Article d’origine publié le mercredi 09 novembre 2011

L’autre jour, je bavardais avec l’un de nos responsables des programmes de gestion du support, Nino Bilic, quand il mentionna quelque chose d’assez inquiétant ; la principale raison pour laquelle nos clients Premier signalent des problèmes graves avec Exchange 2010 est le démontage de bases données de boîtes aux lettres causé par un manque d’espace disque sur le LUN du journal des transactions.

Imprégnons-nous bien de cette information. Naturellement, je tombe des nues… et pour être parfaitement honnête, je pensais qu’avec le calculateur de spécifications de boîte aux lettres et nos conseils sur TechNet, ce problème n’en était plus un depuis longtemps. Après m’avoir communiqué cette information, Nino décida que c’était à moi, et non à lui, d’écrire un billet sur la planification des capacités du journal des transactions (merci Nino !).

Planification des capacités 101

Pour planifier correctement un LUN de journal des transactions, il est important de comprendre deux ou trois choses sur l’environnement :

  1. Combien de boîtes aux lettres résideront dans la base de données ?
  2. Quel est le profil de message des boîtes aux lettres de la base de données ?
  3. Quelle est la taille moyenne des messages ?
  4. Quelle est la taille moyenne des boîtes aux lettres ?
  5. Combien de boîtes aux lettres sont déplacées chaque jour ?
  6. Quelle est la solution de sauvegarde et de restauration ?
  7. La solution doit-elle prendre en compte d’autres scénarios de panne, comme les pannes de réseau ?

Pour les besoins de cette discussion, partons du principe que chaque base de données héberge 250 boîtes aux lettres. Chaque boîte aux lettres envoie/reçoit 150 messages par jour, pour une taille moyenne de 100 Ko. D’après le tableau présenté dans Présentation des facteurs de capacité des journaux et des bases de données de boîtes aux lettres, nous savons qu’un profil de 150 messages d’un poids moyen de 75 Ko génère 30 journaux de transactions par jour (sur une période de 24 heures). Étant donné que notre taille de message est supérieure à 75 Ko, nous allons devoir en tenir compte dans notre génération de journaux de transactions par boîte aux lettres. Le conseil stipule ceci :

Si la taille moyenne des messages double à 150 Ko, les journaux générés par boîte aux lettres augmentent d’un facteur de 1,9. Cette valeur représente le pourcentage de la base de données qui contient les pièces jointes et les tables de messages (corps de message et pièces jointes).

Par conséquent, nous pouvons déterminer l’impact de notre taille moyenne de message de 100 Ko avec cette formule :

150 / 1,9 = [taille moyenne des messages du profil] / x

x = (100 * 1,9) / 150

x = 1,266666666666667 ~ 1,27

Ainsi, avec une taille de message supérieure de 25 Ko par rapport à la ligne de base, le nombre de journaux de transactions générés quotidiennement par boîte aux lettres augmente d’un facteur de 1,27. Par conséquent, 30 journaux de transactions * 1,27 = 39 journaux de transactions / jour / boîte aux lettres. Cela signifie que pour une base de données de 250 boîtes aux lettres, chaque base de données génère 39 * 250 = 9 750 journaux de transactions générés par boîte aux lettres / jour / base de données.

Les déplacements de boîtes aux lettres génèrent également des journaux de transactions. Les boîtes aux lettres déplacées vers la base de données de destination génèrent des journaux (à la destination, pas à la source) d’une taille plus ou moins équivalente à leur propre taille (y compris le contenu des dossiers des éléments récupérables). Par exemple, déplacer 1% des boîtes aux lettres par jour signifie que 2,5 boîtes aux lettres sont déplacées dans une base de données par jour. Si chaque boîte aux lettres a une taille moyenne de 5,4 Go (en comptant les 14 jours de conservation des éléments supprimés avec l’option de récupération d’élément unique activée), alors 2,5 * 5,4 Go / 1024 = 13 888 journaux de transactions de déplacement de boîte aux lettres / jour / base de données.

Du point de vue de la sauvegarde/restauration, nous devons prendre en compte le type d’architecture de sauvegarde sur lequel nous nous appuyons. Avec chaque scénario de sauvegarde, il y a un nombre de jours supplémentaires recommandé que vous devez prévoir en termes de capacité pour vos journaux de transactions générés par boîte aux lettres. En prévoyant de l’espace supplémentaire, vous survivrez à de nombreuses pannes sans subir d’immobilisation. Pour plus d’informations sur la troncation des journaux de transactions, consultez Présentation de la sauvegarde, de la restauration et de la récupération d’urgence.

  Troncation des journaux de transactions Protection recommandée contre les pannes de sauvegarde
Sauvegarde complète quotidienne Chaque jour 3 jours
Sauvegarde complète hebdomadaire / incrémentielle quotidienne Chaque jour 3 jours
Sauvegarde complète hebdomadaire / différentielle quotidienne Hebdomadaire 7 jours
Sauvegarde complète bi-mensuelle / incrémentielle quotidienne Chaque jour 3 jours
Protection des données native Exchange Puisque les journaux ne sont plus requis 3 jours

Bien entendu, il existe d’autres scénarios qu’il est intéressant d’envisager. Par exemple, si vous déployez un groupe de disponibilité de base de données étendu sur deux centres de données, la troncation de journal ne se produira que si la liaison réseau entre les deux centres de données est opérationnelle et que les copies des bases de données sont intègres. Sachant qu’une panne de la liaison du réseau étendu (WAN) peut nécessiter 5 jours de réparation, vous devez paramétrer votre protection contre les pannes de sauvegarde en fonction de ce délai.

Dans le cadre de notre scénario, partons du principe que nous n’avons besoin de garantir qu’une période de survie de 3 jours en cas d’échec de troncation. Cela signifie qu’il nous faut 9 750 / 1024 * 3 = 28,5 Go d’espace disque pour nos journaux de transactions générés par boîte aux lettres.

De plus, nous devons tenir compte de la quantité d’espace disque requise pour nos événements de déplacement de boîte aux lettre pour l’ensemble de la semaine : 13 888 / 1014 * 7 jours = 94,9 Go d’espace disque pour nos opérations de déplacement de boîte aux lettres.

En fin de compte, cela signifie que chaque base de données a besoin de 123 Go d’espace disque pour ses journaux de transactions. Nous ne devons pas non plus oublier un facteur de surcharge, pour prendre en charge tout phénomène inexpliqué susceptible de se produire : 123 Go * 1,2 = 148 Go d’espace disque pour les journaux de transactions.

Si nous déployions un LUN dédié aux journaux de transactions, nous ne configurerions pas un LUN de 150 Go, car cela signifierait que nous pourrions utiliser la totalité de l’espace disque en cas d’échec de sauvegarde ou de déplacements excessifs de boîtes aux lettres. En règle générale, il vaut mieux que chaque LUN soit paramétré de sorte que seule 80% de la capacité du disque soit utilisée. La formule est la suivante :

Espace du LUN = [utilisation d’espace disque projetée] / (1 – [pourcentage d’espace disque libre voulu])

Espace du LUN = 148 Go / (1 – 0,2) = 148 Go / 0,8 = 185 Go d’espace de LUN pour le volume de journal de transactions dédié

Si vous déployez les journaux de transactions sur le même LUN que la base de données, il vous suffit de combiner les spécifications d’espace disque des journaux de transactions avec les spécifications d’espace disque des bases de données pour la valeur [d’utilisation d’espace disque projetée].

Comment puis-je éviter de consommer la totalité de mon espace disque réservé aux journaux de transactions ?

En premier lieu, vous devez fixer une ligne de base de votre environnement pour déterminer votre taux quotidien typique de génération de journaux. De plus, vous devez configurer la surveillance et répondre à chaque alerte générée. La surveillance doit analyser les scénarios suivants :

  1. Espace disque du LUN des journaux de transactions. Définissez plusieurs seuils et différents mécanismes d’alerte. Votre première alerte ne doit pas être celle qui indique que 90% de votre disque a été consommé. Si vous connaissez votre ligne de base de génération moyenne de journaux, vous pouvez définir un seuil qui vous avertit si vous le dépassez de 20%, par exemple.
  2. Surveillez le bon déroulement de vos sauvegardes (si vous n’utilisez pas la Protection des données native Exchange). Votre première indication d’échec de sauvegarde ne doit pas avoir lieu lorsque vous vous trouvez à court d’espace disque.
  3. Surveillez les événements de troncation dans le journal des applications.
  4. Surveillez l’intégrité de la réplication de votre base de données.

Que faire en cas de croissance inexpliquée dans les journaux des transactions ?

Mon ami, Mike Lagase, a écrit un article très intéressant sur les options de dépannage dans cette situation - https://blogs.technet.com/b/mikelag/archive/2009/07/12/troubleshooting-store-log-database-growth-issues.aspx (notez que cet article a été écrit principalement pour les utilisateurs Exchange 2007 de l’époque. Pour cette raison, nombre des outils et/ou recommandations peuvent ne plus fonctionner avec Exchange 2010). En plus des mesures recommandées par Mike, vous pouvez utiliser les suivantes dans Exchange 2010 pour déterminer la croissance inexpliquée des journaux de transactions (merci à Todd Luttinen d’avoir compilé cette liste) :

  1. Vous pouvez utiliser l’applet de commande de statistique d’utilisation (get-StoreUsageStatistics avec DigestCategory = ‘LogBytes’) pour identifier les boîtes aux lettres générant un volume d’octets important. Notez que cela ne fonctionne pas toujours dans les situations où les octets des journaux ne sont pas générés par le propriétaire de la boîte aux lettres ou lorsque l’opération est effectuée pour le compte d’un client (comme CopyOnWrite) et que les octets de journaux générés par les services système (rapportés dans Event ID 9826) ne sont pas inclus. Ces statistiques offrent un résumé des 10 dernières minutes d’activité des principales boîtes aux lettres générant des journaux (jusqu’à 6 échantillons au cours de l’heure écoulée). Les données suivantes montrent comment utiliser les statistiques d’utilisation du magasin afin d’identifier les principales boîtes aux lettres générant des octets de journaux au cours de la dernière heure :

    [PS] C:\>$stats = Get-StoreUsageStatistics –Database <Nom de la base de données>
    [PS] C:\>$stats | ? {$_.DigestCategory -eq ’LogBytes’} | group MailboxGuid |sort count -Descending | Select -first 1 -ExpandProperty Group | sort SampleTime | ft -a MailboxGuid,Sample*,Log*

    MailboxGuid SampleID SampleTime LogRecordCount LogRecordBytes
    c007c87a-e030-4414-b741-9cf61e88b9de 5 11/7/2011 4:25:05 PM 237 274163
    c007c87a-e030-4414-b741-9cf61e88b9de 4 11/7/2011 4:35:05 PM 451 387362
    c007c87a-e030-4414-b741-9cf61e88b9de 3 11/7/2011 4:45:06 PM 483 144999
    c007c87a-e030-4414-b741-9cf61e88b9de 2 11/7/2011 4:55:06 PM 734 293433
    c007c87a-e030-4414-b741-9cf61e88b9de 1 11/7/2011 5:05:06 PM 933 411485
    c007c87a-e030-4414-b741-9cf61e88b9de 0 11/7/2011 5:15:06 PM 247 209987

  2. Des événements d’application sont aussi générés pour des clients administratifs (Event ID 9826). Ces statistiques représentent deux heures d’activité :

    À partir de <date/time> le service <nom> a effectué cette activité sur le serveur :
    Opérations RPC : 24168.
    Pages de base de données lues : 1329 (dont 629 prélues).
    Pages de base de données mises à jour : 12418 (dont 11555 pages remises à jour).
    Enregistrements de journaux de base de données générés : 13906.
    Octets d’enregistrements de journaux de base de données générés : 660331.
    Temps dans serveur : 19142 ms.
    Temps en mode d’utilisateur : 6100 ms.
    Temps en mode kernel : 63 ms.

  3. Le compteur du moniteur de performance “MSExchangeIS Client(*)\JET Log Record Bytes/sec” peut être utilisé pour identifier le type de client cause la croissance des journaux.

Je pense que nous comprenons tous la nécessité absolue de veiller à disposer de suffisamment de capacité pour garantir la disponibilité de sa base de données. J’espère que ce billet vous aidera à planifier vos capacités pour les journaux de transactions.

Ross Smith IV
Responsable de programme principal
Expérience Client Exchange

Ce billet de blog a été traduit de l’anglais. Vous trouverez la version originale à la page Capacity Planning – Yes Transaction Log Space is Critical to Keeping your Databases Healthy and Mounted