Présentation des facteurs de haute disponibilité

 

S’applique à : Exchange Server 2010 SP2, Exchange Server 2010 SP3

Dernière rubrique modifiée : 2015-03-09

Lors de la planification d’une architecture de serveur et de base de données de boîtes aux lettres à haute disponibilité, certaines décisions de conception s’imposent, comme par exemple :

• Envisagez-vous de déployer plusieurs copies de base de données ?

• Combien ?

• Votre architecture offrira-t-elle une résilience de site ?

• Quel type de modèle de résilience de serveur de boîtes aux lettres déploierez-vous ?

• Combien de serveurs de boîtes aux lettres déploierez-vous ?

• Comment distribuerez-vous les copies de base de données ?

• Quel modèle de sauvegarde utiliserez-vous ?

• Quelle architecture de stockage utiliserez-vous ?

Microsoft Exchange Server 2010 vous permet de déployer votre architecture de serveur de boîtes aux lettres à partir de serveurs de boîtes aux lettres autonomes ou de serveurs de boîtes aux lettres configurés pour la résilience. Ces types de serveurs emploient un groupe de disponibilité de base de données (DAG) contenant plusieurs copies de base de données distribuées de façon équitable. En déployant plusieurs copies de base de données, vous pouvez :

• Concevoir une solution qui va à l’encontre des raisons les plus courantes justifiant l’utilisation d’une sauvegarde. Les copies de base de données offrent une protection contre les défaillances matérielles, logicielles ou du centre de données.

• Augmenter la taille de vos bases de données jusqu’à 2 téraoctets, car votre mécanisme de récupération est une autre copie de base de données et non une restauration depuis une sauvegarde.

• Envisager d’autres architectures de stockage qu’une configuration RAID classique, comme par exemple, JBOD (Just a Bunch of Disks), si vous déployez au moins trois copies de base de données. La combinaison de JBOD et de disques moins onéreux peut se traduire par d’importantes économies pour votre organisation.

En répartissant des bases de données actives sur tous les serveurs appartenant à un groupe de disponibilité de base de données (DAG), vous pouvez optimiser l’efficacité du matériel.

Pour des informations détaillées, consultez les rubriques Planification d'une haute disponibilité et d'une résilience de site et Présentation de la sauvegarde, de la restauration et de la récupération d'urgence.

Contenu de cette rubrique

Planification du nombre de copies de base de données à déployer

Types de copies de base de données

Résilience de site

Planification du modèle de résilience du serveur de boîte aux lettres

Planification du nombre de serveurs de boîtes aux lettres à déployer

Planification de la disposition de la copie de base de données

Planification de l’architecture du modèle de sauvegarde

Planification de l’architecture du modèle de stockage

Souhaitez-vous rechercher des tâches de gestion liées à la haute disponibilité ? Voir Gestion de la haute disponibilité et de la résilience de site.

Planification du nombre de copies de base de données à déployer

Comme décrit au chapitre Présentation des copies de bases de données de boîtes aux lettres, un membre DAG peut héberger une seule copie de chaque base de données de boîtes aux lettres, avec un maximum de 100 bases de données par serveur dans l’Édition Entreprise du produit (les copies actives et passives sont prises en compte dans cette limite). Cela signifie qu’un groupe de disponibilité de base de données comptant 16 serveurs peut prendre en charge jusqu’à 1 600 bases de données (100 copies de base de données par serveur × 16 serveurs par DAG ÷ 1 copie par base de données = 1 600 bases de données par DAG).

Dans une configuration à haute disponibilité, il est inutile de déployer une copie unique de base de données, car elle n’assure pas la redondance des données. Vous utilisez une formule pour déterminer le nombre de bases de données pouvant être prises en charge par un groupe de disponibilité de base de données spécifique. Par exemple, si vous définissez D comme nombre de bases de données déployées, C comme nombre de copies de chaque base de données et S comme nombre de serveurs, la règle suivante s’applique :

• D × C = nombre total de copies de base de données dans le DAG

• (D × C) ÷ S = nombre de copies de base de données par serveur

Remarque :
Le nombre de bases de données obtenu par serveur doit être inférieur ou égal à 100 dans l’Édition Entreprise et inférieur ou égal à 5 dans l’Édition Standard.

Par exemple, supposons que votre DAG compte 6 serveurs et 84 bases de données de boîtes aux lettres, ainsi que 3 copies de chaque base de données (notez que les 6 serveurs sont un entier multiple de 3 copies). La règle suivante s’applique :

• 84 bases de données × 3 copies = total de 252 bases de données

• 252 bases de données ÷ 6 serveurs = 42 copies de base de données par serveur

Dans un autre exemple, un DAG compte 4 serveurs et 136 bases de données de boîtes aux lettres, ainsi que 3 copies de chaque base de données. La règle suivante s’applique :

• 136 bases de données × 3 copies = total de 408 bases de données

• 408 bases de données ÷ 4 serveurs = 102 copies de base de données par serveur

102 étant supérieur à 100, le scénario proposé ne correspond pas à une conception de DAG valide.

Retour au début

Types de copies de base de données

Il existe deux types de copies de base de données :

• Copies de base de données à haute disponibilité

• Copies de base de données retardées

Les copies de base de données à haute disponibilité sont des copies configurées sans aucun délai d’attente de relecture. Comme leur nom l’indique, les copies de base de données à haute disponibilité sont maintenues à jour par le système, elles peuvent être activées automatiquement par le système et elles sont utilisées pour assurer une disponibilité élevée du service et des données de boîte aux lettres.

Les copies de base de données retardées sont des copies configurées pour retarder la relecture du journal des transactions pendant une période donnée. Les copies de base de données retardées sont conçues pour offrir une protection ponctuelle contre l’altération logique de la banque d’informations, les erreurs administratives (par exemple, la suppression ou la purge d’une boîte aux lettres déconnectée) et les erreurs d’automatisation (telles que la purge en bloc des boîtes aux lettres déconnectées).

En règle générale, les copies de base de données retardées ne sont pas activées en raison de l’algorithme de sélection de la meilleure copie par le gestionnaire Active Manager. Dans la mesure où les copies de base de données retardées sont déployées pour limiter les risques opérationnels, il convient de ne pas les activer. Si elles sont activées et si une demande de montage est émise, la relecture des journaux est lancée, en incluant tous les fichiers journaux nécessaires pour actualiser la base de données et la mettre dans un état d’arrêt correct, vous faisant ainsi perdre la capacité de récupération à un point dans le temps.

Pour plus d’informations sur la procédure de blocage de l’activation au niveau du serveur de boîte aux lettres ou de suspension de l’activation d’une ou de plusieurs copies de base de données pour empêcher l’activation automatique d’une copie de base de données (telle qu’une copie de base de données retardée), consultez les sections Set-MailboxServer et Suspend-MailboxDatabaseCopy.

Retour au début

Résilience de site

Votre environnement peut comporter plusieurs centres de données. Dans le cadre de votre conception Exchange 2010, déterminez si vous souhaitez déployer l’infrastructure Exchange dans un centre de données unique ou la répartir sur plusieurs centres de données. Les contrats de niveau de service (SLA) de récupération de votre organisation doivent définir le niveau de service désiré suite à une défaillance du centre de données principal.

Si votre déploiement Exchange englobe plusieurs centres de données pour répondre aux objectifs de résilience de site, réfléchissez au modèle de distribution utilisateur le mieux adapté. Il existe deux types de modèles de distribution utilisateur, selon l’emplacement de la boîte aux lettres par rapport au centre de données :

• Modèle de distribution utilisateur actif/passif

• Modèle de distribution utilisateur actif/actif

Si plusieurs boîtes aux lettres sont principalement situées dans un centre de données unique (ou si les utilisateurs accèdent à leurs données via un centre de données unique) et s’il est mentionné dans le contrat de niveau de service que les utilisateurs continuent d’accéder à leurs données par le biais du centre de données principal dans des conditions de fonctionnement normales, votre architecture est un modèle de distribution utilisateur actif/passif.

Si les boîtes aux lettres utilisateur sont réparties sur plusieurs centres de données et que le contrat de niveau de service exige que les utilisateurs continuent d’accéder à leurs données par le biais du centre de données principal dans des conditions de fonctionnement normales, votre architecture correspond à un modèle de distribution utilisateur actif/actif.

Dans un modèle de distribution utilisateur actif/passif, vous pouvez déployer votre architecture comme l’illustre la figure suivante, dans laquelle les boîtes aux lettres actives sont hébergées dans le centre de données principal, mais où les copies de base de données sont déployées dans le centre de données secondaire.

Modèle de distribution utilisateur actif/passif avec deux centres de données

L’architecture présentée dans la figure suivante peut être éventuellement utilisée pour un modèle de distribution utilisateur actif/actif.

Modèle de distribution utilisateur actif/actif avec deux centres de données

Cependant, l’architecture décrite dans la figure précédente comporte un risque. Le réseau étendu (WAN) est un point de défaillance unique pour le groupe de disponibilité de base de données. La perte de connexion du réseau étendu entraîne la perte de quorum pour les membres du DAG dans le centre de données secondaire. Dans cet exemple, le cluster de basculement Windows inclut au total cinq votes (quatre membres de DAG plus le serveur témoin), et exige la disponibilité permanente de trois votes pour rester opérationnel. Trois de ces votes sont situés dans le centre de données de Redmond et deux sont situés dans le centre de données de Portland. La perte de la connexion du réseau étendu entraîne l’hébergement de deux des votes dans le centre de données de Portland, ce qui est insuffisant pour maintenir le quorum. Le centre de données de Redmond inclut trois votes, et peut donc maintenir le quorum et continuer de servir les boîtes aux lettres actives (dès lors que ces trois votes sont opérationnels).

Pour minimiser ce risque dans les modèles de distribution utilisateur actif/actif, il est recommandé de déployer deux groupes de disponibilité de base de données, comme illustré dans la figure suivante.

Deux groupes de disponibilité de base de données pour le modèle de distribution utilisateur actif/actif

DAG1 héberge les boîtes aux lettres actives pour le centre de données de Redmond et est mis en œuvre en tant que modèle de distribution utilisateur actif/passif, avec les copies de base de données passives déployées dans le centre de données de Portland. DAG2 héberge les boîtes aux lettres actives pour le centre de données de Portland et est mis en œuvre en tant que modèle de distribution utilisateur actif/passif, avec les copies de base de données passives déployées dans le centre de données de Redmond.

Cette architecture peut surmonter la perte de connexion du réseau étendu :

• Dans le centre de données de Redmond, les membres du serveur de boîte aux lettres pour DAG2 sont mis hors service en raison d’une perte du quorum, alors que les membres du serveur de boîte aux lettres actif pour DAG1 restent opérationnels et sert les utilisateurs.

• Dans le centre de données de Portland, les membres du serveur de boîte aux lettres pour DAG1 sont mis hors service en raison d’une perte du quorum, alors que les membres du serveur de boîte aux lettres actif pour DAG2 restent opérationnels et sert les utilisateurs.

Pour plus d’informations, consultez la rubrique Planification d'une haute disponibilité et d'une résilience de site.

Retour au début

Planification du modèle de résilience du serveur de boîte aux lettres

Un aspect majeur de la planification de la capacité du serveur de boîte aux lettres Exchange 2010 consiste à déterminer le nombre de copies de base de données que vous envisagez d’activer par serveur lorsque ce dernier est configuré pour la résilience de boîte aux lettres. Un large éventail de conceptions est disponible. Toutefois, deux modèles sont particulièrement recommandés, comme décrit dans les sections suivantes.

Modèle pour toutes les copies de base de données activées

Vous pouvez concevoir l’architecture de votre serveur de façon à ce que la totalité des copies de base de données hébergées soient actives. Par exemple, si votre serveur héberge 35 copies de base de données, vous concevez le processeur et la mémoire de façon à contenir les 35 bases de données actives durant la période de pointe de l’activité utilisateur. Cette solution est généralement déployée par paire. Par exemple, si vous déployez quatre serveurs, une paire inclut les serveurs 1 et 2, et la deuxième paire comprend les serveurs 3 et 4. En outre, lors de la conception de ce scénario, vous dimensionnez chaque serveur pour une disponibilité maximale de 40 % des ressources dans des conditions d’exécution normales.

Des deux modèles abordés dans cette rubrique, celui-ci présente le nombre de serveurs le plus élevé.

Modèle pour les scénarios de défaillance ciblée

Vous pouvez concevoir votre architecture serveur de manière à ce qu’elle gère la charge de boîte aux lettres active au cours du pire scénario de défaillance que vous prévoyez d’intégrer. Plusieurs facteurs sont à prendre en compte dans ce modèle, notamment la résilience de site, le stockage RAID par rapport à JBOD, la taille du groupe de disponibilité de base de données et le nombre de copies de base de données. Ce modèle de planification de capacité offre un équilibre entre le capital, la disponibilité et les caractéristiques en termes de performances client.

En admettant que les copies de base de données soient distribuées de façon aléatoire et équitable :

• Concevez un modèle pour une défaillance automatique sur serveur membre unique dans des configurations de DAG à deux ou trois membres avec deux copies de base de données hautement disponibles par base de données de boîtes aux lettres.

• Concevez un modèle pour une défaillance sur deux serveurs membres (activation manuelle après la deuxième défaillance) dans des configurations de DAG à trois membres avec trois copies de base de données hautement disponibles par base de données de boîtes aux lettres.

• Concevez un modèle pour des défaillances automatiques sur deux serveurs membres où le groupe de disponibilité de base de données comporte au moins quatre membres et trois copies de base de données hautement disponibles par base de données de boîtes aux lettres.

Si vous choisissez ce modèle de planification de capacités, il est vivement recommandé de restreindre le nombre de bases de données pouvant être activées par serveur afin de ne pas surcharger un serveur unique et d’être confronté à des problèmes de performances client.

Vous pouvez limiter le nombre de bases de données en définissant la valeur maximale de bases de données actives. Vous pouvez définir cette limite dans l’environnement de ligne de commande Exchange Management Shell en exécutant Set-MailboxServer -MaximumActiveDatabases. Définissez cette limite sur chaque serveur dans le groupe de disponibilité de base de données afin qu’elle corresponde au nombre maximal de bases de données actives prises en charge dans votre déploiement.

Pour plus d’informations, voir Exemples de création de groupe de disponibilité de base de données.

Retour au début

Planification du nombre de serveurs de boîtes aux lettres à déployer

Lorsque vous déterminez le nombre de serveurs de boîtes aux lettres à déployer, utilisez un multiple du nombre de copies de base de données déployées. Par exemple, si vous prévoyez de déployer trois copies de base de données, démarrez la conception avec 3, 6, 9, 12 ou 15 serveurs.

Après avoir déterminé le point de départ pour le nombre de serveurs dans le DAG, mettez les membres du DAG à l’échelle de façon appropriée selon le nombre de boîtes aux lettres, le modèle de conception de défaillance et d’autres contraintes de conception qui peuvent augmenter ou diminuer le nombre de serveurs de boîtes aux lettres nécessaires.

Le nombre maximal de boîtes aux lettres pouvant être placées sur un serveur est l’une des contraintes de conception les plus fréquemment rencontrées par les organisations. Par exemple, si une organisation détient 20 000 boîtes aux lettres et seulement 25 pour cent d’entre elles peuvent être touchées lors d’une panne, le nombre maximal de boîtes aux lettres pouvant être déployées sur un serveur unique est de 5 000. Pour cela, au moins quatre serveurs de boîtes aux lettres doivent être déployés.

Le matériel de serveur et le modèle de stockage retenus peuvent également entraîner un ajustement du nombre de boîtes aux lettres ou de copies de base de données déployées par serveur, ce qui peut influencer le nombre total de serveurs de boîtes aux lettres.

Serveurs à rôles multiples et serveurs à rôles autonomes

Dans Exchange Server 2007, les rôles serveur d’accès au client et de transport Hub doivent résider sur des serveurs distincts des serveurs de boîtes aux lettres en cluster. Dans Exchange 2010, les serveurs de boîtes aux lettres en cluster n’existent plus et cette restriction n’est donc plus valide. Les rôles serveur d’accès au client et de transport Hub peuvent être hébergés sur des membres DAG, offrant ainsi de meilleures options de déploiement.

Lors du déploiement des serveurs à rôles multiples (rôles serveur de boîte aux lettres, d’accès au client et de transport Hub situés sur le même serveur), la plupart des architectures sont simplifiées. À l’exception des serveurs de transport Edge et de messagerie unifiée, tous les serveurs Exchange 2010 peuvent être identiques. Ces serveurs peuvent avoir un matériel, un processus d’installation de logiciels et des options de configuration identiques. La cohérence sur les serveurs peut simplifier l’administration de la mise en œuvre d’Exchange.

Le serveur à rôles multiples (dans les environnements à grande échelle) permet une utilisation plus efficace des serveurs à plusieurs cœurs, qui offrent des capacités de mégacycle élevées. Lorsqu’il est déployé de façon individuelle, chaque rôle comporte un nombre maximal recommandé de deux sockets de processeur utilisés. En cas de combinaison des rôles, il est recommandé d’utiliser jusqu’à quatre sockets de processeur. Les serveurs peuvent supporter des charges de travail plus importantes, ce qui permet de réduire le nombre global de serveurs dans une organisation. Le déploiement d’un nombre moins important de serveurs réduit les coûts de gestion de ces derniers, car le serveur à rôles multiples transforme le coût d’une dépense d’exploitation périodique en dépense en immobilisations unique. Un nombre moins important de serveurs peut se traduire par des réductions significatives de la puissance, du refroidissement et de l’espace du centre de données, permettant ainsi de réduire davantage les dépenses d’exploitation périodiques.

Bien que le concept de rôle serveur multiple soit efficace, les rôles serveur autonomes peuvent toujours être appropriés. Par exemple, les déploiements de rôles autonomes peuvent être adaptés à certains environnements virtualisés ou lorsque certaines architectures matérielles (par exemple, une infrastructure de serveur lame dans laquelle il est impossible d’isoler correctement le matériel) sont utilisées.

Lors du déploiement de serveurs à rôles multiples, vous devez concevoir l’architecture du processeur et de la mémoire de façon appropriée. Du point de vue du processeur, vous devez vous assurer que le rôle serveur de boîte aux lettres n’utilise pas plus de 40 % des mégacycles disponibles en mode défaillance, afin de réserver 40 % aux rôles serveur de transport Hub et d’accès au client. Pour vous assurer que la mémoire adéquate est disponible pour tous les rôles serveur, suivez les recommandations relatives à la mémoire définies dans la section Présentation du cache de la base de données de boîtes aux lettres.

Pour plus d’informations, consultez la rubrique Présentation des configurations de rôle serveur multiples dans la planification des capacités.

Retour au début

Planification de la disposition de la copie de base de données

Dans une conception à haute disponibilité, vous devez prévoir une disposition équilibrée de la copie de base de données. Les principes de conception suivants doivent être respectés lors de la planification de la disposition de la copie de base de données :

• Veillez à limiter les échecs de copies multiples d’une base de données de boîtes aux lettres spécifique en isolant chaque copie. Par exemple, ne placez pas plus d’une copie unique de base de données de boîtes aux lettres spécifique dans le même rack de serveur ou dans la même baie de stockage. Sinon, la défaillance d’un rack ou d’une baie entraînera l’échec de plusieurs copies de la même base de données et risque de compromettre la disponibilité de la base de données.

• Disposez les copies de base de données d’une manière cohérente et équitable pour vous assurer que les bases de données de boîtes aux lettres actives soient uniformément distribuées après une défaillance. La somme des préférences d’activation de chaque copie de base de données sur un serveur donné doit être égale ou quasiment égale, afin de permettre une répartition égale approximative après la défaillance, en supposant que la réplication soit intègre et mise à jour.

Pour plus d’informations, consultez la rubrique Conception de la disposition des copies de bases de données.

Retour au début

Planification de l’architecture du modèle de sauvegarde

Exchange 2010 inclut plusieurs fonctionnalités et modifications architecturales qui, lorsqu’elles sont déployées et configurées correctement, peuvent assurer une protection des données natives, mettant ainsi fin au besoin de réaliser des sauvegardes traditionnelles de vos données. À l’aide du tableau suivant, déterminez si vous souhaitez toujours utiliser un modèle de sauvegarde classique ou si vous pouvez mettre en œuvre les fonctionnalités de protection des données natives dans Exchange 2010.

Problème	Réduction
Pannes logicielles	Résilience de boîte aux lettres (plusieurs copies de base de données)
Pannes matérielles	Résilience de boîte aux lettres (plusieurs copies de base de données)
Pannes du site ou du centre de données	Résilience de boîte aux lettres (plusieurs copies de base de données)
Suppression accidentelle ou malveillante d’éléments	Récupération des éléments uniques et rétention des éléments supprimés dans une fenêtre répondant aux conditions du contrat de niveau de service de récupération d’éléments
Scénarios d’endommagement physique	Restauration de page unique (copies de base de données à haute disponibilité)
Scénarios d’endommagement logique	Récupération d’élément unique Assistant Réparation du calendrier Déplacements de boîtes aux lettres Cmdlet New-MailboxRepairRequest Sauvegarde à un point dans le temps
Erreurs administratives	Sauvegarde à un point dans le temps
Erreurs d’automatisation	Sauvegarde à un point dans le temps
Administrateurs non autorisés	Sauvegarde à un point dans le temps (isolée)
Exigences de conformité d’entreprise ou réglementaire	Sauvegarde à un point dans le temps (isolée)

L’endommagement logique est généralement un scénario exigeant une sauvegarde à un point dans le temps. Cependant, Exchange 2010 inclut plusieurs options pouvant limiter la nécessité d’une sauvegarde dans le temps :

• Dans une récupération d’élément unique, si l’utilisateur modifie certaines propriétés d’un élément dans un dossier de boîte aux lettres, une copie de l’élément est enregistrée dans le dossier Éléments récupérables avant que la modification ne soit écrite dans la base de données. Si la modification du message donne lieu à une copie endommagée, l’élément d’origine peut être restauré.

• L’Assistant Réparation du calendrier détecte et corrige automatiquement les incohérences qui se produisent sur les éléments uniques et périodiques pour les boîtes aux lettres hébergées sur ce serveur de boîte aux lettres. Ainsi, les destinataires ne manquent pas les annonces de réunion ou ne reçoivent pas d’informations inexactes sur les réunions.

• Lors de déplacements de boîtes aux lettres, le service de réplication de boîte aux lettres Microsoft Exchange détecte les éléments endommagés et ne les déplace pas vers la base de données de boîtes aux lettres cible.

• Exchange 2010 Service Pack 1 (SP1) inclut la cmdlet New-MailboxRepairRequest, qui peut résoudre les problèmes d’endommagement de dossiers de recherche, de comptages d’éléments, de vues de dossiers et de dossiers parents/enfants.

Une sauvegarde à un point dans le temps peut être une sauvegarde traditionnelle ou une copie de base de données retardée, offrant toutes deux les mêmes fonctionnalités. Le choix entre les deux dépend de votre contrat de niveau de service de récupération. Le contrat de niveau de service de récupération définit l’objectif du point de récupération (en cas de sinistre, les données doivent être restaurées dans un certain délai), ainsi que la durée de rétention nécessaire des sauvegardes. Si la durée du contrat de niveau de service de récupération est inférieure à 14 jours, vous pouvez utiliser une copie de base de données retardée. Si elle s’étend au-delà de 14 jours, une sauvegarde traditionnelle doit être utilisée. Dans les scénarios d’administrateur non autorisé et de conformité d’entreprise ou réglementaire, la sauvegarde à un point dans le temps est généralement gérée séparément de l’infrastructure de messagerie et le personnel informatique de messagerie, qui impose une solution de sauvegarde classique.

Si vous choisissez de conserver une sauvegarde à un point dans le temps, plusieurs aspects de la conception peuvent changer :

• Le déploiement de copies de base de données retardées a des implications sur le stockage. En effet, vous devez allouer de l’espace supplémentaire aux journaux de transactions sur la copie de base de données retardée en raison des paramètres de ReplayLagTime. De plus, l’emplacement de la copie de base de données retardée peut affecter votre architecture de stockage (pour de plus amples informations, consultez la section « Planification de l’architecture du modèle de stockage » plus loin dans cette rubrique).

• Le déploiement d’une solution de sauvegarde traditionnelle a des répercussions sur la disposition du numéro d’unité logique (LUN), selon le type de solution VSS (service de cliché instantané de volume), car les solutions de clonage VSS basées sur du matériel requièrent deux numéros d’unités logiques par architecture de base de données.

En fonction de l’architecture de stockage, le recours à une solution de sauvegarde traditionnelle peut exiger la réduction significative des tailles de boîtes aux lettres utilisateur désirées pour respecter la période de sauvegarde et de restauration définie dans vos contrats de niveau de service.

Lors du déploiement de la protection des données natives d’Exchange, vous activez la journalisation circulaire sur les bases de données de boîtes aux lettres. Ce faisant, veillez à intégrer une capacité suffisante dans le système afin que la solution puisse surmonter les incidents qui empêchent la troncation des journaux. Vous devez pour cela prévoir une durée de conservation des journaux de transaction de trois jours minimum (exigences relatives aux copies retardées non comprises). Pour de plus amples informations sur le principe de fonctionnement de la journalisation circulaire avec la réplication continue, consultez la rubrique Présentation de la sauvegarde, de la restauration et de la récupération d'urgence.

Pour de plus amples informations sur la planification des sauvegardes, consultez les rubriques suivantes :

• Présentation de l'architecture des numéros d'unité logique d'Exchange 2010

• Présentation des facteurs de capacité des journaux et des bases de données de boîtes aux lettres

• Présentation de la réparation du calendrier

• Présentation des éléments récupérables

Retour au début

Planification de l’architecture du modèle de stockage

Exchange 2010 offre une solution de stockage extrêmement flexible. Exchange 2010 optimise les performances, la fiabilité et la haute disponibilité, permettant ainsi aux organisations d’exécuter Exchange sur une vaste gamme de périphériques de stockage. S’inspirant des améliorations apportées à l’entrée/sortie (E/S) sur disque d’Exchange 2007, la dernière version d’Exchange exige moins de performances de stockage et est plus tolérante aux échecs de stockage.

Choisissez une plate-forme de stockage qui assure un équilibre entre les besoins de capacité et les exigences d’E/S, tout en veillant à ce que la solution offre une latence de disque acceptable et une expérience utilisateur réactive.

RAID ou JBOD

Déterminez si la plate-forme de stockage doit être mise en œuvre à l’aide de la technologie RAID ou d’une approche JDOB (en supposant que la plate-forme de stockage autorise les configurations JODB). Du point de vue Exchange, JBOD permet de stocker la base de données et les journaux correspondants sur un disque unique. Pour un déploiement sur un système de stockage JBOD, vous devez déployer au moins trois copies de base de données à haute disponibilité. L’utilisation d’un disque unique est un point de défaillance unique, car en cas de défaillance du disque, la copie de base de données qui réside sur ce dernier est perdue. En prévoyant au moins de trois copies de base de données, vous garantissez une meilleure tolérance aux pannes, car vous disposez de deux copies supplémentaires en cas de défaillance de la copie (ou du disque). Toutefois, l’emplacement de trois copies de base de données à haute disponibilité, ainsi que l’utilisation de copies de base de données retardées, peut avoir des conséquences sur la conception de stockage. Le tableau suivant résume les recommandations concernant les aspects de RAID ou de JDOB à prendre en compte.

Aspects de RAID ou JBOD à prendre en compte

Serveurs du centre de données	Deux copies hautement disponibles (total)	Trois copies hautement disponibles (total)	Au moins deux copies hautement disponibles par centre de données	Une copie retardée	Au moins deux copies retardées par centre de données
Serveurs du centre de données principal	RAID	RAID ou JBOD (2 copies)	RAID ou JBOD	RAID	RAID ou JBOD
Serveurs du centre de données secondaire	RAID	RAID (1 copie)	RAID ou JBOD	RAID	RAID ou JBOD

Pour un déploiement sur le système JDOB avec les serveurs du centre de données principal, le groupe de disponibilité de base de données doit inclure au moins trois copies de base de données à haute disponibilité. Si vous associez des copies retardées sur le même serveur hébergeant des copies de base de données à haute disponibilité (en n’utilisant pas de serveurs de copie de base de données retardée dédiés, par exemple), vous avez au moins besoin de deux copies de base de données retardées.

Pour que les serveurs du centre de données secondaire utilisent JDOB, le centre doit au moins compter deux copies de base de données à haute disponibilité. La perte d’une copie dans le centre de données secondaire ne vous obligera pas à effectuer un réamorçage sur le réseau étendu ou à avoir un point de défaillance unique en cas d’activation du centre de données secondaire. Si vous associez des copies de base de données retardées sur le même serveur hébergeant des copies de base de données à haute disponibilité (en n’utilisant pas de serveurs de copie de base de données retardée dédiés, par exemple), vous nécessitez au moins de deux copies de base de données retardées.

Pour les serveurs de copie de base de données retardée dédiés, vous devez ajouter au moins deux copies de base de données retardées dans un centre de données pour pouvoir utiliser JDOB. Sinon, la perte du disque entraîne la perte de la copie de base de données retardée, ainsi que la perte du mécanisme de protection.

Pour plus d’informations, consultez la rubrique Présentation de la configuration de stockage.

Retour au début

 © 2010 Microsoft Corporation. Tous droits réservés.