Instructions de déploiement pour la réplication de données multisites d'Exchange Server

Article
10/25/2013

Dernière rubrique modifiée : 2006-09-01

La technologie de réplication garantit une disponibilité des données Microsoft ® Exchange Server élevée. L'objectif de cette rubrique est de vous aider à mieux comprendre la technologie de stockage de réplication, ainsi que la façon dont elle est utilisée dans un environnement Exchange Server.

La réplication dispose de données redondantes sur plusieurs sites et garantit ainsi une disponibilité élevée, ce qui n'empêche pas l'altération des données. Si des données incorrectes sont écrites sur le périphérique de stockage principal et endommagent la base de données, les mêmes données incorrectes seront répliquées sur les sites distants et altéreront leurs bases de données. Par conséquent, la réplication de données ne remplace pas les processus de maintenance de base de données tels que la sauvegarde, qui valide régulièrement l'intégrité des bases de données.

Cette rubrique présente le type de données auxquelles l'exécution des services Exchange permet d'accéder, tel qu'une requête d'E/S d'écriture effectuée par un processus Exchange. La réplication des données système/du système d'exploitation n'est pas abordée ici.

Microsoft possède des stratégies de support pour différents types de solutions de réplication. Pour plus d'informations sur ces stratégies de support, reportez-vous à l'article 895847 de la Base de connaissances Microsoft, « Multi-site data replication support for Exchange 2003 and Exchange 2000 ».

Remarque :
Téléchargez le document sur les instructions de déploiement pour la réplication des données de Microsoft Exchange Server 2003 sur plusieurs sites pour l'imprimer ou le lire en mode hors connexion.

Mécanismes de réplication

L'objectif de la réplication de données est de conserver les réplicas des données actuels sur des sites distants. Les serveurs Exchange peuvent utiliser les réplicas sur le site distant afin de garantir la continuité du service de messagerie en cas de panne de stockage ou du site à l'emplacement principal. La réplication de données peut se propager de manière synchrone ou asynchrone. Par définition, si les données sont répliquées de manière synchrone, les hôtes n'obtiendront une réponse complète d'écriture du stockage que lorsque les écritures d'E/S seront validées tant dans les emplacements locaux que distants. En d'autres termes, le stockage étendu et le stockage local doivent implémenter la modification avant que la réussite de l'écriture soit confirmée à l'hôte. En mode asynchrone, l'hôte obtiendra de la part du stockage une écriture complète lorsque l'écriture aura été validée dans le stockage local, sans avoir à attendre d'accusé de réception du stockage étendu stipulant qu'il a également mis à jour le réplica.

Réplication asynchrone

En ce qui concerne la latence d'écriture, la sensibilité de l'application hôte à la distance de réplication est plus importante en mode de réplication synchrone qu'en mode asynchrone. Toutefois, lorsque vous déployez la réplication asynchrone, vous devez être conscient des problèmes suivants :

La perte de données Selon la fréquence de réplication des données, les modifications de données sur le site distant peuvent retarder les modifications apportées au site principal. Dans le cas d'une panne du site principal, le réplica du site distant ne sera pas totalement actif. Bien que ce délai soit configurable sur toutes les solutions de stockage, vous devez être conscient de l'éventualité d'une perte de données en raison de ce comportement.
**L'intégrité des données (préservation de la commande d'écriture)**Exchange comprend des dépendances de commande d'écriture entre la base de données et les journaux de transactions associés. Exchange écrit toujours les modifications dans les fichiers journaux avant de les valider dans les fichiers de base de données. En mode de réplication asynchrone, l'application contrôle l'ordre d'écriture. Toutefois, en mode asynchrone, la solution de réplication contrôle le moment où les données sont répliquées. Si la solution ne conserve pas l'ordre d'écriture au cours de la réplication, elle peut endommager les fichiers de base de données et empêcher le montage des bases de données lorsqu'une catastrophe se produit sur le site principal.
L'impact sur les performancesNombre de fournisseurs prétendent que leurs solutions asynchrones n'affectent pas les performances de stockage. En réalité, une dégradation des performances se produira lors de l'exécution de la réplication asynchrone. Selon l'implémentation de la solution, plusieurs chiffres permettent de décrire les attentes en matière de performances. Par conséquent, les clients doivent tester la solution avant le déploiement, l'objectif étant de s'assurer que la solution peut fournir des performances de stockage appropriées aux utilisateurs Exchange.

Certains fournisseurs de solutions utilisent des technologies différentes pour adresser le problème de préservation de la commande d'écriture. Pour déployer correctement une solution répliquée de façon asynchrone, le client doit collaborer avec le fournisseur afin de s'assurer que sa technologie asynchrone répond aux critères suivants :

Elle peut maintenir la cohérence de la commande d'écriture de tous les périphériques dans un groupe de stockage, tout en étant cohérente avec les autres en permanence.
Elle est de préférence récupérable aussi bien dans un atelier que dans un environnement de production.
Elle est transmise par un fournisseur, avec un projet de support pour les données répliquées.

Réplication synchrone

La préoccupation principale concernant la réplication synchrone dans le déploiement Exchange est liée aux performances. Des tests ont montré que l'expérience client est étroitement liée à la latence d'écriture. Avec une solution de réplication synchrone, le nombre de boîtes aux lettres pouvant être hébergées par Exchange Server est réduit. L'impact sur les performances dépend dans une large mesure de la distance de réplication, de la bande passante réservée à la liaison de réplication et de son utilisation. La réplication synchrone peut entraîner une réduction de 75 % de l'évolutivité du serveur et des boîtes aux lettres. Vous devez tenir compte de ce facteur de réduction de l'évolutivité lorsque vous travaillez sur votre méthodologie de planification de capacité Exchange. Pour plus d'informations, consultez la section « Planification du déploiement pour la réplication synchrone » qui figure dans cette rubrique.

La réplication synchrone est généralement considérée comme une solution garantissant une absence de pertes de données, car les réplicas sont totalement synchronisés avec les fichiers de données de stockage principaux. Contrairement à cette idée reçue, il existe des cas où les solutions de réplication synchrone donnent lieu à une perte de données. L'exemple ci-dessous en est la parfaite illustration.

En général, les solutions de réplication de données de stockage gèrent les échecs de liaison de réplication de l'une des deux façons suivantes :

Elles continuent à valider la fonction d'entrée/sortie d'écriture uniquement sur le périphérique de stockage principal, elles enregistrent toutes les modifications apportées à tous les périphériques qui utilisent la liaison de réplication dans un fichier journal et enregistrent le fichier journal dans le stockage principal.
Elles font échouer l'opération d'écriture afin que l'application gère l'échec comme si le disque avait échoué.

Si la solution de réplication utilise la première méthode de gestion, une perte de données est possible. Lors d'un échec de liaison suivi d'une défaillance du site principal, les données qui ont été validées après l'échec de liaison ne seront pas répliquées. Elles seront perdues avec l'échec du stockage principal. Lorsque vous concevez la solution de réplication de stockage, gardez ces différentes conditions d'échec à l'esprit. Vous pourrez ainsi générer le système de façon à réduire de telles occurrences. Dans cet exemple, le client envisage peut-être de déployer des liaisons de réplication redondantes pour réduire le risque de perte de données.

Solutions de réplication synchrone

Les solutions de réplication synchrone sont classées en fonction de l'endroit où la réplication se produit, qu'il s'agisse d'une réplication basée sur l'hôte ou sur le stockage. En général, une réplication basée sur l'hôte utilise un logiciel basé sur l'hôte (pilote de filtre) pour interrompre le flux d'E/S afin de gérer la réplication. La réplication basée sur le stockage se produit hors hôte, au niveau du périphérique de stockage. Deux solutions de réplication peuvent être déployées dans le cadre de l'une des procédures suivantes :

**Clustering dispersé géographiquement (Geocluster)**Dans cette catégorie, les nœuds qui appartiennent au même cluster sont placés dans des sites différents. En général, les serveurs Exchange sont activement hébergés par les nœuds sur le site principal. Les solutions fournissent une réplication synchrone des données Exchange sur le ou les sites distants. Si une catastrophe se produit sur le site principal, les serveurs virtuels Exchange basculent vers les nœuds passifs sur le site distant et se mettent en ligne en utilisant les données Exchange répliquées.
Le catalogue Microsoft Windows ® Server Catalog présente une catégorie pour les solutions de cluster dispersé géographiquement. Vous pouvez rechercher les solutions de cluster dispersé géographiquement WHQL (Windows Hardware Qualified Labs) à l'adresse suivante : https://go.microsoft.com/fwlink/?LinkId=28572.
Autres Cette catégorie inclut tous les autres types de déploiements de réplication synchrone qui n'utilisent pas le clustering dispersé géographiquement. Ces solutions reposent sur d'autres moyens d'utilisation des données Exchange répliquées sur le ou les sites distants en cas de panne du site principal (par exemple une solution en attente, une réplication associée à des processus de récupération d'urgence).

Microsoft recommande vivement aux clients d'obtenir des garanties de la part de leurs fournisseurs de solutions de réplication en ce qui concerne les problèmes suivants :

La solution se trouve-t-elle dans une catégorie de solution de clustering dispersé géographiquement ? Si tel est le cas, est-elle certifiée WHQL ? Si ce n'est pas une de ces solutions, le périphérique de stockage est-il listé dans une solution décrite dans la section Solutions de cluster, Solution de clustering dispersé géographiquement du catalogue Windows Server ?
La solution de réplication éliminera-t-elle les risques de perte de données à moins d'une panne simultanée sur tous les sites ?
Quelles sont les procédures à suivre pour effectuer un basculement et un retour en arrière ?
La solution de réplication et la latence attendue peuvent-elles gérer la charge utilisateur Exchange planifiée et fournir ainsi une expérience client de qualité ?

Données Exchange à répliquer

Exchange est une application serveur centrée sur les données. La réplication de données Exchange sur un site secondaire permet une redondance en cas d'échecs liés au stockage. Il s'agit d'une décision commerciale visant à déterminer exactement le type de données à répliquer. Vous devez évaluer votre tolérance commerciale en ce qui concerne la perte des différents types de données décrits dans ce document.

Données obligatoires à répliquer

Les données suivantes doivent être répliquées :

Les fichiers de base de données des boîtes aux lettres Exchange stockent des données de message. Chaque base de données est constituée de deux fichiers :
- Un fichier de base de données (.edb) composé de messages et d'un contenu MAPI.
- Un fichier de diffusion en continu (.stm) composé d'un contenu natif non-MAPI.
Des fichiers journaux de transactions (.log), qui enregistrent chaque transaction validée dans la base de données.
Des fichiers de point de contrôle (.chk) qui contiennent des informations sur les entrées des fichiers journaux qui ont été écrites sur le disque.

Tous ces fichiers sont essentiels pour permettre aux clients l'accès à leur serveur de boîtes aux lettres, de même que pour la récupération logicielle des modifications de la base de données en mémoire et qui peuvent être perdues si les banques d'informations du serveur Exchange ne sont pas fermées correctement, notamment lors d'une coupure d'électricité. En raison de l'aspect critique de ces fichiers, ce jeu de données doit être répliqué. Les chemins d'accès des fichiers de base de données sont spécifiés sur la page de propriétés de base de données et chaque base de données dispose d'un chemin d'accès. Toutes les bases de données du groupe de stockage dépendent des chemins d'accès du fichier journal de transactions et du fichier de point de contrôle spécifiés sur la page de propriétés de ce groupe de stockage.

La décision de répliquer des bases de données de dossiers publics est plus difficile à prendre. Cette décision dépend en partie de la conception de la topologie Exchange de votre déploiement. Contrairement aux données de boîtes aux lettres, les données de dossiers publics peuvent être répliquées directement par Exchange Server. Vous pouvez avoir plusieurs réplicas de banques de dossiers publics qui répliquent les modifications (contenu). Cette réplication de données n'est pas effectuée de manière synchrone.

Les solutions Geocluster nécessitent une réplication synchrone des dossiers publics du cluster. Cette exigence est nécessaire pour que le cluster soit totalement fonctionnel sur le site secondaire. Les bases de données de boîtes aux lettres au sein du cluster doivent pointer vers la banque de dossiers publics (« Banque publique par défaut ») qui fait également partie de ce cluster, de sorte que les clients puissent se connecter immédiatement une fois le cluster disponible sur le site secondaire. Les dossiers publics du Geocluster doivent uniquement héberger la hiérarchie, et pas nécessairement tout le contenu, pour faciliter l'ouverture de session de la boîte aux lettres lors d'une condition d'échec. Le choix d'héberger le contenu complet du dossier public et de le répliquer de manière synchrone dans les dossiers publics hébergés dans le Geocluster relève d'une décision commerciale. Si les données des dossiers publics sont essentielles pour les activités principales des entreprises, ce qui signifie que seule une quantité minimale de données perdues est acceptable, vous devez envisager d'utiliser une solution de Geocluster plutôt qu'un mécanisme de réplication des dossiers publics Exchange Server. Si vous n'avez pas besoin de ce niveau de disponibilité des données de dossiers publics, vous pouvez utiliser une solution de réplication synchrone non-Geocluster pour les données de boîtes aux lettres, combinée au mécanisme de réplication trouvé dans les dossiers publics Exchange.

Données recommandées à répliquer

Les données de file locale (répertoire Mailroot) du protocole SMTP se trouvent temporairement dans le périphérique de stockage pendant qu'Exchange Server les analyse. Cette conception évite une perte de données en cas d'échec du serveur. Par exemple, lorsqu'un serveur de destination est inaccessible, les messages devant être routés vers ce serveur sont stockés dans le répertoire de file d'attente du serveur local jusqu'à ce qu'ils puissent être remis. Si un échec se produit sur le disque qui stocke les données de file d'attente, tous les messages de la file d'attente sont perdus. En raison de la nature transitoire des données de file d'attente, aucun processus de sauvegarde des files d'attente de messagerie n'est défini comme c'est le cas pour la sauvegarde des bases de données Exchange Server. Une tolérance de panne et/ou des solutions de disponibilité élevée pour le stockage des informations de file d'attente peuvent vous protéger d'une éventuelle perte de données. Nous vous conseillons de répliquer les données de file d'attente MTA (répertoire MTADATA) dans des environnements où les messages transitoires ne risquent pas d'être perdus en raison de défaillances de site.

Le chemin d'accès à SMTP Mailroot (notamment les répertoires Queue et Badmail par instance de serveur virtuel) est spécifié sous l'onglet Messages de la page des propriétés du serveur virtuel SMTP dans le Gestionnaire système Exchange et de la page des propriétés X.400 pour le chemin d'accès à la file d'attente de l'Agent de transfert des messages. Vous devez examiner votre profil pour déterminer s'il est nécessaire de répliquer les données de file d'attente Exchange. Si vous avez une topologie Exchange existante, vous pouvez déterminer si vous pouvez tolérer la perte de données dans la file d'attente locale. Vous pouvez mesurer la quantité attendue de données dans la file d'attente locale à l'aide de la longueur de la file d'attente locale dans l'Analyseur de performances (Perfmon.msc) ou l'Afficheur des files d'attente dans le Gestionnaire système Exchange pendant des périodes de chargement de pointe. Si la réplication est requise pour les données de file d'attente, il est important de tester les performances du traitement des messages dans l'environnement de réplication, afin que la latence de réplication introduite n'engendre pas un goulet d'étranglement dans le transport. Vous pouvez utiliser l'outil ESP (Exchange Server Stress and Performance) 2003 pour tester le débit de transfert dans un environnement de réplication synchrone où les données de file d'attente sont répliquées. Vous pouvez télécharger l'outil à partir du site Web Exchange Server Stress and Performance 2003.

Données facultatives à répliquer

Les journaux de suivi des messages contiennent des informations sur tous les messages provenant d'un serveur Exchange ou à destination de ce même serveur. Ces données peuvent être importantes en vue d'un diagnostic. Par défaut, le suivi des messages n'est pas activé. Toutefois, si ces données sont importantes pour votre entreprise, elles peuvent être répliquées pour éviter toute perte en cas de sinistre. Le chemin d'accès au journal de suivi des messages est spécifié sur la page de propriétés Exchange Server dans ESM.

Meilleures pratiques pour la configuration des mécanismes de réplication

Chaque fournisseur a différentes implémentations propriétaires des mécanismes de réplication qui fournissent des options de réplication différentes. Vous devez examiner les détails de la solution avec votre fournisseur afin de déterminer si la solution qu'il propose est la mieux adaptée à vos exigences organisationnelles et au contrat SLA (Service Level Agreement) pour la récupération d'urgence. Les recommandations suivantes peuvent s'appliquer uniquement à certaines solutions de réplication :

Remarque :
Le terme « point de réplication » est défini comme étant l'endroit où se produit la réplication. Selon la solution, l'emplacement peut se trouver au niveau du pilote de filtre de l'hôte ou sur un secteur du disque dans un ensemble de stockage.

Configurez la réplication au niveau du volume de points logiques/de montage.
Bien que les données devant être répliquées se trouvent dans les fichiers décrits dans la section « Données Exchange à répliquer » de cette rubrique, vous devez vous assurer que la réplication est configurée pour l'unité d'un volume de points logiques/de montage au niveau de l'hôte. Par exemple, si le chemin d'accès des données de boîte aux lettres est G:\MDB1\MDB1.EDB ; le lecteur G doit être l'unité de base effectuant la réplication. Par conséquent, toutes les données du lecteur G seront répliquées. L'exécution de la réplication au niveau des fichiers ou des sous-répertoires est sujette à l'erreur humaine et n'est pas prise en charge par Microsoft.
Créez plusieurs points de réplication.
Pour réduire la mise en file d'attente de plusieurs E/S destinées au même point de réplication, configurez le stockage afin de créer le plus de points de réplication possible. Équilibrez la charge de la fonction d'entrée/sorite à travers plusieurs points de réplication. Selon la solution de réplication/stockage, cette approche peut réduire la latence globale de lecture/d'écriture d'E/S en raison d'une file d'attente d'E/S réduite.
Conservez les journaux de transactions sur des volumes logiques différents.
Lorsque les données sont répliquées, chaque requête d'E/S d'écriture est mise en file d'attente au niveau du point de réplication. Exchange rédige des journaux dans un modèle séquentiel et, si ces E/S sont destinées au même point de réplication, il existe une possibilité significative que chaque E/S soit placé en file d'attente pour écriture. Cette situation contribuerait à prolonger les temps de réponse d'écriture de journaux, ce qui peut être un facteur négatif considérable pour l'évolutivité et les performances Exchange. C'est pour cette raison que Microsoft vous recommande de segmenter des journaux de transactions à partir de groupes de stockage différents sur des volumes logiques différents avec des points de réplication différents.
Utilisez plusieurs liens de réplication.
Vous pouvez améliorer l'évolutivité et les performances de la solution de réplication en configurant plusieurs liens de réplication entre le site principal et le site secondaire. L'implémentation de cette approche peut être onéreuse et elle n'est pas requise pour la réplication de données Exchange. Toutefois, il existe des déploiements qui doivent implémenter plusieurs liens de réplication pour obtenir l'évolutivité et les performances souhaitées pour une solution de réplication de données Exchange donnée. Il peut être également nécessaire d'équilibrer la charge des points de réplication à travers les liaisons de réplication disponibles pour un débit de réplication optimal.
Dans la mesure où Exchange possède une dépendance de commande d'écriture entre des bases de données et les journaux de transaction associés, il est important de configurer un groupe de points de réplication sauvegardant les volumes logiques du groupe de stockage (qui incluent le numéro d'unité logique de base de données (LUN) et le journal LUN) pour utiliser la même liaison de réplication. Cette configuration est nécessaire pour conserver l'ordre d'écriture au niveau du groupe de stockage, ce qui est essentiel pour préserver l'intégrité des données sur le site distant en cas d'échecs tels qu'un échec de liaison.
L'utilisation de plusieurs liaisons de réplication avec plusieurs points de réplication peut constituer une approche efficace pour mettre à l'échelle une solution de réplication des données Exchange. Cette approche peut également réduire le risque de perte de données, problème traité dans l'exemple de la section précédente « Réplication synchrone »

Méthodes à suivre pour la configuration d'Exchange pour une réplication synchrone

Lorsqu'Exchange est déployé dans un environnement de réplication synchrone, quelques modifications de configuration amélioreront l'évolutivité et les performances du serveur. Il est important de comprendre ces modifications dès la phase de planification afin qu'elles puissent être implémentées pendant la conception du stockage et de la réplication. Les conseils à suivre pour une meilleure configuration sont les suivants :

Créez le nombre maximal de groupes de stockage par serveur Exchange.
L'augmentation du nombre de groupes de stockage dans une solution Exchange répliquée de manière synchrone peut être avantageuse pour l'évolutivité et les performances du déploiement en équilibrant la charge des transactions d'écriture de journaux à travers plusieurs volumes logiques et, par la suite, de plusieurs points de réplication. En général, il y aura plus de processus d'écriture de journaux parallèles, ce qui peut réduire la latence d'écriture des journaux de transactions (file d'attente d'E/S réduite) dans environnement de réplication synchrone. Exchange Server 2003 Enterprise Edition permet quatre groupes de stockage par serveur Exchange.
Augmentez la taille de tampon de journal des transactions.
La latence d'E/S d'écriture dans le journal est un facteur d'évolutivité significatif dans les solutions Exchange de réplication synchrone. Les fonctions d'E/S d'écriture de journaux sont séquentielles et, en mode mono-thread, la latence d'E/S de journal est par conséquent susceptible de représenter un engorgement pour le système. Les E/S de journal sont tout d'abord écrites sur les tampons de journal, lesquels sont ensuite supprimés soit à l'aide d'une validation en temps réel, soit à l'aide d'une validation de capacité. Une validation en temps réel signifie que le tampon journal est immédiatement écrit sur le disque. Une validation de capacité signifie que le tampon journal est écrit sur le disque lorsque le tampon est plein.
L'augmentation de la taille du tampon journal réduit la fréquence des vidages de capacité, augmente la taille d'écriture du journal et réduit par la suite la latence globale d'écriture du journal. La réduction de la latence d'écriture d'E/S du journal représente un excellent moyen d'améliorer l'évolutivité et les performances du déploiement Exchange.
Nous vous conseillons en général d'augmenter la taille du tampon jusqu'à 9 000 si la réplication est effectuée via des canaux fibres. En ce qui concerne les liens de bande passante faibles, tels que les liens TCP/IP, il est difficile de déterminer une valeur optimale pour ce paramètre. Si le lien indique une saturation de l'augmentation de la taille d'écriture des journaux, ce qui ralentit la réplication, vous devez effectuer des tests approfondis pour déterminer la taille de tampon journal optimale minimisant la latence d'écriture dans le journal. Pour connaître la procédure sur la modification de ce paramètre, voir l'article 328466 de la Base de connaissances Microsoft sur le fait que les tampons de journal ESE réglés trop lentement peuvent entraîner une absence de réponse de la part du service de banque d'informations de Microsoft Exchange. Consultez également votre fournisseur de solutions au sujet de cette configuration.

Planification du déploiement pour la réplication synchrone

Même si la solution de stockage de réplication synchrone est conforme à toutes les recommandations précédentes, elle peut quand même poser des problèmes de performances pour les clients Exchange si la solution n'a pas été minutieusement testée avant le déploiement. Il n'existe aucune règle définitive quant aux effets négatifs sur l'évolutivité et les performances de l'implémentation de la réplication synchrone avec Exchange. Chaque solution de réplication Exchange présente des facteurs de performances différents qui peuvent inclure les éléments suivants, sans pour autant s'y limiter : la distance entre sites, le mécanisme de transfert de réplication, le nombre de liaisons de réplication, le nombre de points de réplication, le nombre de groupes de stockage Exchange, les paramètres de configuration de journaux/de bases de données Exchange, l'architecture de réplication et de stockage et le profil client Exchange. Chaque solution est unique et nécessite une planification étendue et des tests pour un déploiement réussi.

La latence d'écriture d'E/S attribuée aux solutions de réplication synchrone est le facteur clé de la limitation de l'évolutivité Exchange. Cette latence d'E/S augmentée génère une charge sur le serveur qui peut sérieusement affecter l'expérience client Exchange. Une latence d'écriture élevée provoque précisément une augmentation de la latence RPC et ralentit les opérations effectuées par le client. Bien que la réplication synchrone fournisse une disponibilité des données Exchange élevée, elle entraîne également une baisse significative des performances d'E/S. Cette baisse de performances de l'écriture d'E/S, et parfois de la lecture, est un facteur essentiel dans la définition du nombre maximal d'utilisateurs pouvant être pris en charge sur une plateforme donnée.

Lors de la phase de planification, effectuez les opérations suivantes pour valider la conception :

Consultez « Optimizing Storage for Exchange 2003 » pour savoir comment mieux concevoir et implémenter le stockage pour Exchange.
Utilisez les tests Jetstress pour valider le débit brut du stockage avec la réplication synchrone configurée. Pour télécharger l'outil Jetstress, consultez le site Web Microsoft Exchange Server Jetstress Tool.
Mesurez l'effet de l'augmentation de la latence d'écriture sur le client de messagerie en exécutant un test Exchange Server Load Simulator 2003 (LoadSim) adapté à votre environnement. Pour télécharger LoadSim, consultez le site Web Microsoft Exchange Server 2003 Load Simulator (LoadSim).
Mesurez le débit du disque moyen lorsque vous exécutez LoadSim. Le débit du disque doit être supérieur ou égal au débit moyen maximal attendu dans l'environnement de production que vous simulez (IOPS/Boîte aux lettres). Pour plus d'informations sur la façon de mesurer le débit du disque moyen maximal, consultez « Optimizing Storage for Exchange 2003 ».
Prêtez une attention particulière au compteur de latence moyenne RPC sur le serveur et au temps de réponse du client après avoir exécuté les tests LoadSim. Lorsque vous analysez les résultats de tests, gardez à l'esprit que les trois compteurs doivent répondre aux critères listés ci-dessous.
Latence moyenne RPC
Ce compteur indique le temps moyen nécessaire pour desservir une seule requête d'appel de procédure distante (RPC). L'augmentation de la distance de réplication ou de la charge utilisateur entraînera une augmentation de la latence RPC moyenne. La limite maximale de la moyenne est de 50 ms et la valeur maximale doit être de 100 ms. Si les résultats de tests indiquent une moyenne supérieure à 50 ms, l'expérience client globale peut être lente. Si la moyenne est inférieure à 50 ms, mais qu'elle dépasse parfois 100 ms, l'expérience client sera lente lors des périodes de pointe.
Compteurs de latence de disque
L'équipe produit Microsoft Exchange a testé plusieurs solutions de réplication synchrone matérielle. Les résultats indiquent les connexions entre la latence moyenne RPC et les latences de disque. En règle générale, la solution est en mesure de gérer la charge donnée lorsque la moyenne de latence de lecture de base de données est inférieure à 20 ms et lorsque la moyenne des latences d'écriture et de lecture des journaux est inférieure à 20 ms. Les valeurs maximales de ces latences doivent être maintenues en dessous de 40 ms. Au-delà de ces seuils, les clients auront probablement une réponse lente.
Temps de réponse du client
Vous pouvez confirmer l'expérience client globale en exécutant lslog.exe sur tous les ordinateurs clients. Cette activité renvoie la moyenne pondérée du 95e percentile, la valeur doit être inférieure à 1 000 ms. lslog.exe fait partie de l'outil LoadSim. La documentation LoadSim explique comment utiliser Islog.exe et comment interpréter les résultats qu'il fournit.
Pour plus d'informations sur les performances, consultez « Troubleshooting Exchange Server 2003 Performance ».
Testez la solution de votre profil de boîte aux lettres par rapport à la distance de réplication planifiée. La distance de liaison de réplication a une limitation physique. À mesure que la distance augmente, le temps de réponse du client/serveur ralentit en raison de l'augmentation des latences d'écriture par réplication synchrone sur la distance. En général, le seuil de la réplication de stockage synchrone des données Exchange Server est de 100 km. Ce seuil peut varier selon l'implémentation de la solution.
Créez un plan de sauvegarde qui valide l'intégrité de la base de données à intervalles réguliers. La réplication ne remplace pas le processus de sauvegarde.
Vérifiez que vous disposez d'un plan de récupération d'urgence complet ayant été testé aussi minutieusement que les performances de réplication de la solution. Il existe des méthodes différentes de récupération des données, serveurs et sites Exchange. Vous devez implémenter un plan de récupération d'urgence qui réponde à vos exigences commerciales et au contrat SLA (Service Level Agreement), et qui vous guide de façon rapide et efficace au cours de la phase de récupération en cas de catastrophe. Testez et validez le plan en simulant plusieurs types de conditions d'échec dans un déploiement Exchange à l'aide de la réplication synchrone dans des conditions de charge lourde.