NetApp Tech OnTap

Optimiser la réplication avec Exchange 2007

Meilleures pratiques pour SP1

Il y a un an environ, j’ai rédigé un article publié dans Tech OnTap qui parlait, entre autres, des nouvelles capacités de réplication de Microsoft® Exchange Server 2007. La dernière version d’Exchange 2007 Service Pack (SP1) ne se contente pas de résoudre les bugs et d’améliorer les possibilités que j’ai décrites, mais comprend également de nouvelles fonctions importantes ; elle a également un impact sur la façon dont vous allez concevoir l’architecture de votre stockage NetApp® pour Exchange. Le présent article aborde les modifications qui ont le plus fort impact sur le stockage et passe en revue les meilleures pratiques de conception d’un stockage Exchange. Pour plus d’informations sur ces aspects, consultez le rapport technique que j’ai publié récemment sur “Microsoft Exchange 2007 SP1 Continuous Replication Best Practices Guide .”

Evolutions importantes et nouvelles fonctions

Parmi les nombreuses modifications intervenues dans Exchange 2007 SP1, il en existe cinq que vous devez absolument connaître.

SP1 est la seule version d’Exchange 2007 compatible avec Windows® Server 2008. Windows Server 2003 l'est toujours également.

SP1 offre une nouvelle option de réplication, la réplication continue de secours (Standby Continuous Replication ou SCR). La réplication SCR vous permet de séparer la haute disponibilité et les fonctions de résilience du site et de créer un grand nombre de nouveaux scénarios de redondance. Son utilisation peut être configurée pour n’importe quel serveur Exchange tant qu'il n'est pas configuré pour une réplication locale continue (Local Continuous Replication ou LCR) (vous ne pouvez pas utiliser une réplication LCR sur des serveurs cible SCR non plus). Chaque groupe de stockage peut avoir plusieurs cibles de réplication SCR. Vous pouvez avoir par exemple à la fois une copie locale et une copie à distance. Vous pouvez également configurer un seul serveur de réplication SCR comme cible de plusieurs serveurs source.

SP1 a été complètement refondu au niveau de l’utilisation du stockage sur les cibles de réplication pour améliorer considérablement son efficacité. Les entrées et sorties sur toutes les cibles de réplication (LCR, CCR et SCR) ont été extrêmement réduites par rapport à la version initiale d'Exchange 2007. Auparavant, sur les cibles de réplication, les entrées/sorties des bases de données pouvaient être supérieures de 200 à 300 % à la source. Avec SP1, les entrées/sorties de la base de données sur la cible sont maintenant inférieures de 78 % par rapport à la source. Les entrées/sorties du fichier journal de la cible ont également été réduites dans SP1.

La défragmentation en ligne est moins agressive et fait l’objet d’une surveillance. Vous pouvez désormais savoir combien de temps dure un passage de défragmentation et quand la base de données a été intégralement défragmentée. Ces informations peuvent vous servir à ajuster la période de maintenance en ligne pour réduire une utilisation excessive du disque qui affecte Snapshot™ en terme de consommation d'espace.

Le balayage de la base de données pour vérifier les problèmes de corruption peut maintenant être effectué pendant la maintenance en ligne. Auparavant, la seule façon de vérifier qu’une base de données n’était pas corrompue sans la mettre hors ligne était d'effectuer une sauvegarde en ligne en continu, ce qui obligeait à lire et à vérifier toutes les pages de la base de données. C’était également le seul moyen de forcer la remise à zéro des pages supprimées imposée par certains scénarios de sécurité. Si vous avez effectué des sauvegardes VSS sur un réplica plutôt que sur une base de données active, cela implique certainement que votre base de données de production n’a jamais été intégralement vérifiée.

En pratique, NetApp et Microsoft recommandent tous deux l'utilisation de Visual SourceSafe® (VSS) pour les sauvegardes. Cette application de sauvegarde vérifie les données de sauvegarde, mais une fois encore, les données en temps réel ne sont jamais réellement contrôlées. Il existe donc un risque réel, même s’il est faible, de corruption de la base de données.

Lorsqu'ils sont activés dans le registre d'un serveur Exchange avec SP1, le balayage de la base de données et la remise à zéro des pages sont lancés quotidiennement en même temps que la maintenance en ligne, pour vérifier la base de données active et les pages supprimées après remise à zéro.

Meilleures pratiques

C’est à ce moment-là que vous vous dites : « C’est bien tout ça, mais comment profiter de ces nouvelles fonctions dans mon environnement NetApp ? ».

Windows Server 2008. Si vous souhaitez que vos serveurs Exchange utilisent le dernier système d’exploitation, il faut que vous installiez SP1 sur un nouveau serveur équipé de Windows 2008 ; il n’est pas possible d’effectuer de mise à niveau du SE existant d’un serveur. Vous n’avez pas besoin d’installer Exchange 2007 avant d’installer SP1, car tout est inclus dans le Service Pack.

Quel que soit votre SE, je vous conseille la mise à niveau SP1 pour la résolution des bugs et ses évolutions qui ont un impact important sur le stockage.

Configuration de l’unité logique (LUN) pour la réplication. Dans ses meilleures pratiques, Microsoft vous recommande d’utiliser la même configuration de LUN à la fois pour le côté source et le côté cible de chaque copie , et bien sûr, votre but est que la LUN source et la LUN cible soient sur des systèmes de stockage distincts. Compte tenu de la charge importante d’entrées/sorties que la version initiale d’Exchange 2007 plaçait sur les serveurs cible, nous vous recommandions en général de configurer un agrégat du fichier journal et de la base de données pour chaque nœud de cluster. La prise en charge de plusieurs serveurs de réplication (sources et/ou cibles) par un système de stockage lui imposait alors un nombre important d'agrégats indépendants.

Ce n'est plus nécessaire puisque SP1 a réduit la charge des entrées/sorties. Nous vous conseillons toujours de conserver les fichiers journaux et les bases de données dans des agrégats distincts (et également de séparer les stockages source et cible), mais vous pouvez maintenant regrouper plusieurs bases de données issues de différents clusters dans un seul agrégat ; c’est également valable pour les fichiers journaux. Vous éliminez ainsi les « îlots » de stockage, simplifiez votre configuration de stockage et vous pouvez en augmenter l'utilisation.

CCR Cluster

Figure 1) configuration de la LUN pour réplicas avec Exchange 2007 SP1. Les systèmes de stockage source et cible utilisent chacun 1 agrégat pour les bases de données et 1 autre pour les fichiers journaux, ce qui représente 4 agrégats au total (2 par système), contre les 12 auparavant nécessaires.

Défragmentation en ligne. La défragmentation peut avoir un fort impact sur le nombre de blocs que les copies Snapshot de NetApp doivent conserver. Le processus de défragmentation modifie les blocs, et les copies Snapshot de NetApp conservent une image stable et instantanée en préservant les modifications des blocs. Par conséquent, plus vous modifiez de blocs via une défragmentation, plus il vous faut d'espace pour stocker les copies d'instantanés.

C'est là que les nouvelles mesures entrent en scène. Microsoft conseille d'effectuer une défragmentation toutes les deux semaines ; aussi si vous contrôlez les mesures et constatez que la défragmentation a lieu plus tôt, vous pouvez réduire la durée de la maintenance quotidienne en ligne pour réduire l’utilisation quotidienne du disque, et réduire également la consommation d'espace des instantanés.

Pour plus de précisions, deux compteurs peuvent enregistrer les performances pour évaluer l’efficacité de la défragmentation en ligne.

  • Base de données MSExchange ==> Instances\Pages libérées par la défragmentation en ligne par seconde
  • Base de données MSExchange ==> Instances\Lecture de pages par la défragmentation en ligne par seconde.
Si le ratio lectures/pages libérées est supérieur à 100/1, réduisez la période de maintenance en ligne. Si le ratio lectures/pages libérées est inférieur à 50/1, augmentez la période de maintenance en ligne.

Balayage de la base de données et remise à zéro des pages . Par défaut, le balayage de la base de données peut être activé ou pas. S'il est activé, il s’effectue toutes les nuits pendant la période de maintenance en ligne. C’est bien, mais il faut vous demander si vous avez réellement besoin de vérifier aussi fréquemment votre base de données, car en fait, cette opération lit toute la base de données, bloc par bloc. Et naturellement, cela génère des charges supplémentaires importantes sur les systèmes de stockage.

Si pour vous la remise à zéro des pages n’est pas critique et si vous disposez de NetApp SnapManager® pour Exchange, vous avez également la possibilité de configurer une sauvegarde de copie hebdomadaire sans tronquer vos fichiers journaux. Les corruptions seront ainsi contrôlées et votre base de données active sera vérifiée. Vous pouvez éventuellement la prévoir sur un week-end lorsque la charge est moins importante.

Si vous devez absolument procéder à une remise à zéro des pages, un balayage de la base de données toutes les nuits est le meilleur moyen de vous la garantir. Soyez attentif au fait que si la remise à zéro n’a pas été activée dès le départ pour une base de données, la charge d’entrées/sortie sera extrêmement importante lors du premier lancement. Pour réduire l’impact du premier passage de la remise à zéro des pages, vous pouvez activer la compression.

 

Tirer le meilleur parti de la réplication avec Exchange 2007 SP1

Les évolutions et les nouvelles fonctions d'Exchange 2007 SP1 sont si nombreuses que l'on dirait presque une nouvelle version d'Exchange. En suivant quelques-unes des meilleures pratiques, vous pouvez tirer le meilleur parti de votre installation Exchange associée à votre stockage NetApp. Voici un résumé des meilleurs conseils pratiques actuels de NetApp concernant Exchange 2007 SP1.

Configuration de l’unité logique et réplication
  • Scindez le stockage du serveur actif et du serveur cible sur des systèmes de stockage distincts.
  • Prévoyez les mêmes capacités et performances pour l’unité logique active et l’unité logique cible.
  • Séparez les fichiers journaux des bases de données dans leur propres agrégats.
  • Créez un volume distinct NetApp FlexVol® pour chaque groupe de stockage.
  • Utilisez NetApp RAID-DP® pour plus de performances et de protection.
  • Lancez SnapManager pour les sauvegardes Exchange sur le nœud cible et réglez la période de maintenance en ligne par rapport au nœud actif.
  • Etudiez l'utilisation de NetApp ReplicatorX™ et/ou de SnapMirror® pour obtenir un objectif de point de reprise (RPO, Recovery point objective) inférieur à cinq minutes lors de la réplication de bases de données, des fichiers journaux et des données de transport hub Exchange.
Défragmentation et balayage de la base de données
  • Réduisez la période de maintenance en ligne si un passage est effectué toutes les deux semaines et si le ratio lectures/pages libérées est supérieur à 100/1.
  • Etudiez l’utilisation d’une sauvegarde de copie (qui ne tronque pas les fichiers journaux) et re-contrôlez l’intégrité pour valider l’état général de la base de données par rapport au balayage en ligne de la base de données.
Robert Quimbey

Robert Quimbey
Ingénieur Microsoft Alliance
NetApp

Robert a rejoint NetApp en 2007 après 8 années au sein de l’équipe produit Microsoft Exchange, où il était responsable du stockage et de la haute disponibilité. Depuis son arrivée chez NetApp, ses activités sont toujours centrées autour d'Exchange 2007, et comprennent la conception des meilleures pratiques et l'analyse en profondeur des entrées/sorties de cluster en réplication continue (CCR). Ses récents travaux vont l’amener à créer des architectures de référence pour Exchange.

Explore