Planification d'une haute disponibilité et d'une résilience de site

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

Dernière rubrique modifiée : 2016-11-28

Microsoft Exchange Server 2010 comporte un nouveau cadre de travail unifié pour la résilience des boîtes aux lettres ; il présente de nouvelles fonctionnalités telles que le groupe de disponibilité de base de données (DAG) et les copies de base de données de boîtes aux lettres. Le déploiement de ces nouvelles fonctionnalités est un processus simple et rapide, mais une planification attentive doit toutefois être effectuée préalablement afin de veiller à ce que toute solution de haute disponibilité et de résilience de site utilisant ces fonctionnalités corresponde à vos attentes et aux besoins de votre entreprise.

Pendant la phase de planification, les architectes, administrateurs et autres intervenants sur le système doivent identifier ce qui est nécessaire pour le déploiement, en particulier les exigences de haute disponibilité et de résilience de site. Certaines configurations sont requises pour le déploiement de ces fonctionnalités. Les configurations de matériel, de logiciel, et de réseau doivent également être remplies. Pour plus d’informations sur les exigences en matière de stockage pour les groupes de disponibilité de base de données, consultez la rubrique Conception du stockage de serveur de boîtes aux lettres.

Contenu de cette rubrique

Conditions requises générales

Configuration matérielle minimale requise

Contraintes de stockage

Configuration logicielle

Configuration réseau requise

Configuration requise pour le serveur témoin

Planification de résilience de site

Planification des basculements de centres de données

Conditions requises générales

Avant de déployer un groupe de disponibilité de base de données et de créer des copies de base de données de boîtes aux lettres, assurez-vous que les recommandations suivantes à l’échelle du système sont prises en compte :

• Un serveur DNS (Domain Name System) doit être exécuté. Idéalement, le serveur DNS doit accepter des mises à jour dynamiques. Si cela n’est pas possible, vous devez créer un enregistrement (A) d’hôte DNS pour chaque serveur Exchange. Dans le cas contraire, Exchange ne fonctionnera pas correctement.

• Chaque serveur de boîtes aux lettres d’un groupe de disponibilité de base de données doit être un serveur membre du même domaine.

• Le système ne prend pas en charge l’ajout d’un serveur de boîtes aux lettres Exchange 2010 qui est aussi un serveur de répertoires pour un groupe de disponibilité de base de données.

• Le nom que vous donnez au groupe de disponibilité de base de données doit être un nom d’ordinateur valide, disponible, unique et composé de 15 caractères maximum.

Configuration matérielle minimale requise

Il n’y a généralement pas de condition spéciale concernant le matériel pour les groupes de disponibilité de base de données ou les copies de bases de données de boîtes aux lettres. Les serveurs utilisés doivent remplir toutes les conditions présentées dans les rubriques Conditions préalables pour Exchange 2010 et Configuration requise pour Exchange 2010. Pour obtenir des informations relatives à la planification de matériel, consultez les rubriques suivantes :

• Présentation des configurations de processeur et des performances d’Exchange

• Présentation des configurations mémoire et des performances Exchange

• Conception du stockage de serveur de boîtes aux lettres

• Présentation des ratios de rôle serveur et des performances d'Exchange

Contraintes de stockage

En général, il n’existe pas de contraintes de stockage spécifiques aux groupes de disponibilité de base de données ou aux copies de base de données de boîtes aux lettres. Les groupes de disponibilité de base de données ne nécessitent pas ou n’utilisent pas le stockage partagé géré par cluster. Le stockage partagé géré par cluster est pris en charge pour l’utilisation dans un groupe de disponibilité de base de données uniquement lorsque celui-ci est configuré pour utiliser une solution qui exploite l’API de réplication tierce intégrée à Exchange 2010. En ce qui concerne les informations de prévision de stockage, voir Conception du stockage de serveur de boîtes aux lettres.

Configuration logicielle

Les groupes de disponibilité de base de données sont disponibles dans l’édition Exchange 2010 Standard comme dans l’édition Exchange 2010 Entreprise. En outre, un groupe de disponibilité de base de données peut contenir une combinaison de serveurs exécutant l’édition Exchange 2010 Standard ou l’édition Exchange 2010 Entreprise.

Chaque membre d’un groupe de disponibilité de base de données doit aussi exécuter le même système d’exploitation. Exchange 2010 est pris en charge sur les systèmes d’exploitation Windows Server 2008 et Windows Server 2008 R2. Tous les membres d’un groupe de disponibilité de base de données doivent exécuter soit Windows Server 2008 soit Windows Server 2008 R2. Ils ne peuvent pas contenir une combinaison de Windows Server 2008 et Windows Server 2008 R2.

En plus des conditions nécessaires à l’installation d’Exchange 2010, le système d’exploitation doit remplir des conditions spéciales. Les groupes de disponibilité de base de données utilisent les technologies de clustering avec basculement Windows et nécessitent de ce fait la version Entreprise de Windows.

Configuration réseau requise

Chaque groupe de disponibilité de base de données et chacun de leurs membres doivent remplir certaines configurations réseau spécifiques. Les réseaux des groupes de disponibilité de base de données sont similaires aux réseaux publics, mixtes et privés utilisés dans les précédentes versions d’Exchange. Cependant, contrairement aux versions précédentes, l’utilisation d’un réseau unique sur chaque membre d’un groupe de disponibilité de base de données est une configuration prise en charge. En outre, la terminologie a un peu changé. À la place des réseaux publics, mixtes et privés, chaque groupe de disponibilité de base de données contient un réseau MAPI unique qui est utilisé par d’autres serveurs (par ex. d’autres serveurs Exchange 2010, serveurs de répertoires, etc.) pour communiquer avec le membre du DAG. Chaque groupe de disponibilité de base de données peut contenir aussi plusieurs réseaux de réplication qui sont des réseaux dédiés à l’envoi de fichiers journaux et à l’amorçage.

Bien qu’un réseau unique soit pris en charge, nous recommandons un minimum de deux réseaux par groupe de disponibilité de base de données : un seul réseau MAPI et un seul réseau de réplication. Cela entraîne une redondance du réseau et du chemin d’accès réseau, et permet ainsi au système de faire la distinction entre une panne de serveur et une panne de réseau. L’utilisation d’une carte réseau unique empêche le système de faire la différence entre ces deux types de défaillances.

Remarque :

Cette rubrique de la documentation est rédigée en supposant que chaque membre de groupe de disponibilité de base de données comporte au moins deux cartes réseau, que chaque groupe de disponibilité de base de données est configuré avec un réseau MAPI et au moins un réseau de réplication, et que le système est capable de faire la distinction entre une défaillance du réseau et une défaillance du serveur.

Prenez en compte les informations suivantes lors de la conception de l’infrastructure réseau de votre groupe de disponibilité de base de données :

• Chaque membre du groupe de disponibilité de base de données doit avoir au moins une carte réseau capable de communiquer avec tous les autres membres du groupe de disponibilité de base de données. Si vous utilisez un chemin d’accès réseau unique, nous vous recommandons d’utiliser le Gigabit Ethernet. Lors de l’utilisation d’une carte réseau unique dans chaque membre du groupe de disponibilité de base de données, le réseau de groupes de disponibilité de base de données doit être activé pour la réplication et devrait être configuré comme réseau MAPI. Comme il n’y a pas d’autres réseaux, le système utilisera aussi le réseau MAPI comme réseau de réplication. En outre, lorsque vous utilisez une carte réseau unique dans chaque membre du groupe de disponibilité de base de données, nous vous recommandons de concevoir la solution générale tout en gardant à l’esprit la carte et le chemin d’accès réseau unique.

• L’utilisation de deux cartes réseau dans chaque membre du groupe de disponibilité de base de données vous procure un réseau MAPI et un réseau de réplication, et entraîne les comportements de récupération suivants :

  • Un basculement de serveur aura lieu en cas de défaillance au niveau du réseau MAPI (s’il y a des copies de base de données de boîtes aux lettres en bon état qui peuvent être activées).

  • En cas de défaillance au niveau du réseau de réplication, si le réseau MAPI n’est pas affecté par la défaillance, l’envoi de fichiers journaux et les opérations d’amorçage se rétabliront pour utiliser le réseau MAPI, même si la propriété ReplicationEnabled du réseau MAPI est définie sur False. Lorsque le réseau de réplication défaillant est à nouveau en bon état et prêt à poursuivre l’envoi de journaux et les opérations d’amorçage, vous devez passer manuellement au réseau de réplication. Pour passer de la réplication sur le réseau MAPI à un réseau de réplication restauré, vous pouvez soit interrompre et poursuivre la réplication continue en utilisant les cmdlets Suspend-MailboxDatabaseCopy et Resume-MailboxDatabaseCopy, soit redémarrer le service de réplication Microsoft Exchange. Nous recommandons l’utilisation des opérations d’interruption et de poursuite pour éviter la brève interruption provoquée par le redémarrage du service de réplication Microsoft Exchange.

• Chaque membre du groupe de disponibilité de base de données doit posséder le même nombre de réseaux. Par exemple, si vous envisagez d’utiliser une carte réseau unique dans un membre du groupe de disponibilité de base de données, tous les membres du DAG doivent aussi utiliser une carte réseau unique.

• Chaque groupe de disponibilité de base de données ne doit avoir qu’un seul réseau MAPI. Le réseau MAPI doit offrir une connectivité à d’autres serveurs et services Exchange, tels que Active Directory et DNS.

• Des réseaux de réplication supplémentaires peuvent être ajoutés si nécessaire. Vous pouvez aussi empêcher les points de défaillance uniques d’une carte réseau unique en utilisant une collaboration de cartes réseau ou une technologie similaire. Cependant, même l’utilisation d’une collaboration de cartes réseau n’empêche pas le réseau lui-même d’être un point de défaillance unique.

• Chaque réseau sur chaque serveur membre du groupe de disponibilité de base de données doit se trouver sur son propre sous-réseau. Chaque serveur du groupe de disponibilité de base de données peut se trouver sur un autre sous-réseau, mais les réseaux MAPI et de réplication doivent pouvoir être routés et offrir une connectivité de manière à ce que :

  • Chaque réseau de chaque serveur membre du groupe de disponibilité de base de données soit sur son propre sous-réseau, séparé du sous-réseau utilisé par chacun des autres réseaux sur le serveur.

  • Chaque réseau MAPI de serveur membre du DAG puisse communiquer avec tout autre réseau MAPI membre du DAG.

  • Chaque réseau de réplication de serveur membre du DAG puisse communiquer avec tout autre réseau de réplication membre du DAG.

  • Aucun routage direct ne permet la transmission de signaux de pulsation du réseau de réplication d’un serveur membre du DAG vers le réseau MAPI d’un autre membre du DAG, ou l’inverse, ou entre plusieurs réseaux de réplication au sein du groupe de disponibilité de base de données.

• Quel que soit leur emplacement géographique par rapport à d’autres membres du groupe de disponibilité de base de données (DAG), chaque membre du DAG doit présenter une latence de réseau en boucle de 500 millisecondes (ms) maximum entre les membres. Lorsque la latence d’aller-retour entre deux serveurs de boîtes aux lettres hébergeant des copies d’une base de données augmente, le potentiel de réplication non actualisé augmente également. Quelle que soit la latence de la solution, les utilisateurs doivent vérifier que le(s) réseau(x) entre tous les membres du DAG sont capables de satisfaire aux objectifs de protection et de disponibilité des données du déploiement. Les configurations présentant des valeurs de latence plus élevées peuvent exiger un réglage spécial des paramètres du DAG, de la réplication et du réseau, tel que l’augmentation du nombre de bases de données ou la réduction du nombre de boîtes aux lettres par base de données, pour atteindre les objectifs escomptés.

• La configuration de latence en boucle peut ne pas être la configuration de bande passante et de latence réseau la plus stricte pour une configuration à centres de données multiples. Vous devez évaluer la charge totale du réseau, qui inclut l’accès au client, Active Directory, le transport, la réplication continue et autre trafic pour déterminer la configuration réseau nécessaire pour votre environnement.

• Les réseaux de groupes de disponibilité de base de données prennent en charge les protocoles IPv4 et IPv6 (Internet Protocol Version). Le protocole IPv6 n’est pris en charge que lorsque le protocole IPv4 est aussi utilisé ; un environnement exclusivement IPv6 n’est pas pris en charge. L’utilisation d’adresses IPv6 et de plages d’adresses IP n’est prise en charge que si les protocoles IPv6 et IPv4 sont activés sur cet ordinateur et si le réseau prend en charge les deux versions d’adresse IP. En cas de déploiement d’Exchange 2010 dans cette configuration, tous les rôles serveur peuvent échanger des données avec des périphériques, des serveurs et des clients utilisant des adresses IPv6.

• APIPA (Automatic Private IP Addressing) est une fonctionnalité de Microsoft Windows qui attribue automatiquement les adresses IP quand aucun serveur DHCP (Dynamic Host Configuration Protocol) n’est disponible sur le réseau. Les adresses APIPA (y compris les adresses attribuées manuellement à partir des plages d’adresses APIPA) ne sont pas prises en charge pour l’utilisation par des groupes de disponibilité de base de données ou par Exchange 2010.

Conditions requises pour le nom et l’adresse IP des groupes de disponibilité de base de données

Lors de la création, chaque groupe de disponibilité de base de données reçoit un nom unique, et est soit affecté à une ou plusieurs adresses IP statiques soit configuré pour l’utilisation de DHCP. Que vous utilisiez des adresses statiques ou dynamiques, toute adresse IP affectée au groupe de disponibilité de base de données doit se trouver sur le réseau MAPI.

Chaque groupe de disponibilité de base de données nécessite au moins une adresse IP sur le réseau MAPI. Un groupe de disponibilité de base de données nécessite des adresses IP supplémentaires quand le réseau MAPI est étendu sur plusieurs sous-réseaux. L’illustration suivante représente un groupe de disponibilité de base de données dans lequel tous les nœuds ont le réseau MAPI sur le même sous-réseau.

Groupe de disponibilité de base de données avec réseau MAPI sur le même sous-réseau

Dans cet exemple, le réseau MAPI dans chaque membre du groupe de disponibilité de base de données est sur le sous-réseau 172.19.18.x. Par conséquent, le groupe de disponibilité de base de données exige une adresse IP unique sur ce sous-réseau.

L’illustration suivante représente un groupe de disponibilité de base de données dont le réseau MAPI s’étend sur deux sous-réseaux : 172.19.18.x et 172.19.19.x.

Groupe de disponibilité de base de données avec réseau MAPI sur plusieurs sous-réseaux

Dans cet exemple, le réseau MAPI de chaque membre du groupe de disponibilité de base de données se trouve sur un sous-réseau distinct. Par conséquent, le groupe de disponibilité de base de données exige deux adresses IP, une pour chaque sous-réseau sur le réseau MAPI.

À chaque fois que le réseau MAPI du groupe de disponibilité de base de données est étendu sur un sous-réseau supplémentaire, une adresse IP supplémentaire pour ce sous-réseau-là doit être configurée pour le groupe de disponibilité de base de données. Chaque adresse IP configurée pour le groupe de disponibilité de base de données est affectée au cluster de basculement sous-jacent du groupe de disponibilité de base de données et utilisée par celui-ci. Le nom du groupe de disponibilité de base de données est aussi utilisé comme nom pour le cluster de basculement sous-jacent.

À n’importe quel moment spécifique, le cluster du groupe de disponibilité de base de données n’utilisera qu’une des adresses IP affectées. La fonction de clustering avec basculement Windows enregistre cette adresse IP dans le DNS quand l’adresse IP du cluster et les ressources de nom du réseau sont mises en ligne. En plus de l’utilisation d’une adresse IP et d’un nom de réseau, un objet nom de cluster (CNO) est créé dans Active Directory. Le nom, l’adresse IP et l’objet réseau de cluster du cluster sont utilisés en interne par le système pour sécuriser le groupe de disponibilité de base de données et à des fins de communication interne. Les administrateurs et les utilisateurs finaux n’ont pas besoin d’interface ni de connexion avec le nom du groupe de disponibilité de base de données ni avec l’adresse IP.

Remarque :

Bien que le nom de réseau et l’adresse IP du cluster soient utilisés en interne par le système, il n’y a pas de dépendance irréversible dans Exchange 2010 pour que ces ressources soient disponibles. Même si l’adresse IP et les ressources de nom de réseau du cluster sous-jacent sont en mode hors connexion, la communication interne a quand même lieu dans le groupe de disponibilité de base de données à l’aide des noms de serveur des membres du groupe de disponibilité de base de données. Cependant, nous vous recommandons de contrôler périodiquement la disponibilité de ces ressources afin de vous assurer qu’elles ne sont pas hors ligne pendant plus de 30 jours. Si le cluster sous-jacent est hors ligne pendant plus de 30 jours, le compte de CNO peut être invalidé par le mécanisme de nettoyage de la mémoire dans Active Directory.

Configuration de la carte réseau pour DAG

Chaque carte réseau doit être configurée correctement selon l’usage prévu. La configuration d’une carte réseau utilisée pour un réseau MAPI n’est pas la même que celle d’une carte réseau utilisée pour un réseau de réplication. En outre, pour configurer correctement chaque carte réseau, vous devez configurer l’ordre de connexion au réseau dans Windows de manière à ce que le réseau MAPI corresponde à l’ordre de préférence le plus élevé. Pour obtenir la procédure détaillée sur la modification de l’ordre de connexion au réseau, consultez la rubrique Modifier l’ordre des liens du protocole.

Configuration de la carte du réseau MAPI

Une carte réseau destinée à l’utilisation par un réseau MAPI doit être configurée comme décrit dans le tableau suivant.

Les propriétés TCP/IP v4 d’une carte de réseau MAPI sont configurées de la manière suivante :

• L’adresse IP du réseau MAPI d’un membre du DAG peut être affectée ou configurée manuellement pour utiliser le protocole DHCP. Si le protocole DHCP est utilisé, nous vous recommandons d’utiliser les réservations persistantes pour l’adresse IP du serveur.

• Le réseau MAPI utilise généralement une passerelle par défaut, bien que ce ne soit pas obligatoire.

• Au moins une adresse de serveur DNS doit être configurée. Pour la redondance, il est recommandé d’utiliser plusieurs serveurs DNS.

• La case Enregistrer les adresses de cette connexion dans le DNS doit être cochée.

Configuration de la carte du réseau de réplication

Une carte réseau destinée à l’utilisation par un réseau de réplication doit être configurée comme décrit dans le tableau suivant.

Les propriétés TCP/IP v4 d’une carte de réseau de réplication sont configurées de la manière suivante :

• L’adresse IP du réseau de réplication d'un membre du DAG peut être affectée ou configurée manuellement pour utiliser le protocole DHCP. Si le protocole DHCP est utilisé, nous vous recommandons d’utiliser les réservations persistantes pour l’adresse IP du serveur.

• Les réseaux de réplication n’ont généralement pas de passerelle par défaut, et si le réseau MAPI en a une, aucun autre réseau ne devrait avoir de passerelle par défaut. Le routage du trafic réseau sur un réseau de réplication peut être configuré à l’aide de routes persistantes et statiques au réseau correspondant sur d’autres membres du groupe de disponibilité de base de données utilisant des adresses de passerelle qui peuvent effectuer le routage entre les réseaux de réplication. Tout autre trafic ne correspondant pas à cette route sera traité par la passerelle par défaut configurée sur la carte du réseau MAPI.

• Les adresses de serveur DNS ne devraient pas être configurées.

• La case Enregistrer les adresses de cette connexion dans le serveur DNS ne doit pas être cochée.

Conditions requises générales

Configuration requise pour le serveur témoin

Un serveur témoin est un serveur extérieur au groupe de disponibilité de base de données qui sert à obtenir et maintenir le quorum quand le groupe de disponibilité de base de données a un nombre de membres pair. Les groupes de disponibilité de base de données ayant un nombre de membres impair n’utilisent pas de serveur témoin. Tout groupe de disponibilité de base de données ayant un nombre de membres pair utilise un serveur témoin. Le serveur témoin peut être n’importe quel ordinateur exécutant Windows Server. Il n’est pas nécessaire que la version du système d’exploitation Windows Server du serveur témoin corresponde au système d’exploitation utilisé par les membres du groupe de disponibilité de base de données.

Le quorum est géré au niveau du cluster, sous le groupe de disponibilité de base de données. Un groupe de disponibilité de base de données a le quorum quand la majorité de ses membres sont connectés et peuvent communiquer les uns avec les autres. Cette notion de quorum est un aspect du concept de quorum dans le clustering de basculement Windows. Parmi les aspects liés et nécessaires au quorum dans les clusters de basculement se trouve la ressource quorum. La ressource quorum est une ressource située dans un cluster de basculement, fournissant un moyen d’arbitrage conduisant à l’état de cluster et aux décisions d’appartenance. La ressource quorum fournit également un stockage permanent pour le stockage des informations de configuration. La ressource de quorum est accompagnée du journal de quorum qui est une base de données de configuration pour le cluster. Il contient des informations telles que les serveurs membres du cluster, les ressources installées dans le cluster et l’état de ces ressources (par exemple, en ligne ou hors connexion).

Il est fondamental que chaque membre du groupe de disponibilité de base de données ait une vue cohérente de la configuration du cluster sous-jacent du groupe. Le quorum agit comme le référentiel définitif pour toutes les informations de configuration relatives au cluster. Le quorum est utilisé pour départager les nœuds afin d’éviter le fractionnement du cluster. Le Split-Brain Syndrome est une situation qui se produit lorsque les membres du groupe de disponibilité de base de données ne peuvent pas communiquer entre eux bien qu’ils soient en fonction. Ce syndrome est évité en exigeant toujours qu’une majorité des membres du groupe de disponibilité de base de données (et dans le cas des groupes de disponibilité de base de données ayant un nombre de membres pair, le serveur témoin du groupe de disponibilité de base de données) soient disponibles et en interaction pour que le groupe de disponibilité de base de données soit opérationnel.

Planification de résilience de site

Chaque jour, de plus en plus d’entreprises reconnaissent que l’accès à un système de messagerie fiable et disponible est essentiel pour leur réussite. Pour de nombreuses organisations, le système de messagerie fait partie des plans de continuité d’activité et la résilience du site doit être conçue dans leur déploiement de service de messagerie. Fondamentalement, de nombreuses solutions de résilience de site impliquent le déploiement de matériel dans un deuxième centre de données.

En définitive, la conception générale d’un groupe de disponibilité de base de données, y compris le nombre de membres du groupe de disponibilité de base de données et le nombre de copies de base de données de boîtes aux lettres, dépendra des accords de niveau du service de récupération (SLA) de chaque organisation pour traiter divers scénarios d’échec. Pendant la phase de planification, les architectes et administrateurs du système identifient les besoins du déploiement, y compris les exigences de résilience de site. Ils déterminent le ou les emplacement(s) à utiliser et les cibles SLA requises pour la récupération. L’accord SLA déterminera les deux éléments spécifiques qui doivent être la base de la conception d’une solution de haute disponibilité et de résilience de site : l’objectif de temps de récupération (RTO) et l’objectif de point de récupération (RPO). Ces deux valeurs sont mesurées en minutes. Le RTO est le temps nécessaire à la restauration du service. Le RPO correspond à l’actualité des données après l’opération de récupération. Un accord SLA peut aussi être défini pour restaurer le centre de données principal pour qu’il fonctionne complètement une fois les problèmes résolus.

Les architectes et administrateurs de la solution identifieront aussi les ensembles d’utilisateurs qui requièrent une protection de résilience de site et détermineront si la solution multi-site doit être une configuration actif/passif ou actif/actif. Dans une configuration actif/passif, aucun utilisateur n’est normalement hébergé dans le centre de données de secours. Dans une configuration actif/actif, les utilisateurs sont hébergés aux deux emplacements, et un certain pourcentage du nombre total de bases de données dans le cadre de cette solution a un emplacement actif préféré dans un deuxième centre de données. Quand le service est défaillant pour les utilisateurs d’un centre de données, ces utilisateurs sont activés dans l’autre centre de données.

L’élaboration des contrats de niveau de service appropriés requiert souvent de répondre aux questions de base suivantes :

• Quel niveau de service est requis suite à un échec du centre de données principal ?

• Les utilisateurs ont-ils besoin de leurs données ou uniquement des services de messagerie ?

• À quelle fréquence les données sont-elles requises ?

• Combien d’utilisateurs doivent être pris en charge ?

• Comment les utilisateurs accèderont-ils à leurs données ?

• Quel est le contrat de niveau de service pour l’activation de centre de données de secours ?

• Comment le service est-il ramené vers le centre de données principal ?

• Les ressources sont-elles dédiées à la solution de résilience de site ?

En répondant à ces questions, vous commencez à donner forme à une conception de résilience de site pour votre solution de messagerie. Une exigence clé en relation avec la récupération suite à une défaillance de site consiste à créer une solution permettant de récupérer les données nécessaires dans un centre de données de sauvegarde hébergeant le service de messagerie de sauvegarde.

Planification de l’espace de noms

Exchange 2010 modifie la manière dont vous planifiez la conception de votre espace de noms lors du déploiement d’une configuration de résilience de site. Une planification d’espace de noms appropriée est essentielle à la réussite des basculements de centres de données. Du point de vue de l’espace des noms, chaque centre de données utilisé dans une configuration de résilience de site est considéré comme actif. Par conséquent, chaque centre de données aura besoin de son propre espace de noms unique pour les divers services Exchange 2010 dans ce site, dont les espaces de noms pour Outlook Web App, Outlook Anywhere, Exchange ActiveSync, Exchange Web Services, l’accès au client RPC, le protocole POP3 (Post Office Protocol version 3), le protocole IMAP4 (Internet Message Access Protocol version 4) et le protocole SMTP (Simple Mail Transfer Protocol). En outre, l’un des centres de données héberge également l’espace de noms pour la découverte automatique. Cette conception vous permet aussi d’effectuer un basculement de base de données unique du centre de données principal vers un centre de données secondaire pour valider la configuration des données secondaires comme partie de la validation et de la pratique pour le basculement de centre de données.

Il est recommandé d’utiliser DNS réparti pour les noms d’hôtes Exchange utilisés par les clients. Le DNS fractionné fait référence à une configuration de serveur DNS dans laquelle des serveurs DNS internes renvoient une adresse IP interne pour un nom d’hôte et les serveurs DNS externes (Internet) renvoient une adresse IP publique pour ce même nom d’hôte. Comme l’utilisation d’un DNS fractionné utilise les mêmes noms d’hôte de manière interne et externe, cette stratégie vous permet de réduire les noms d’hôte dont vous avez besoin.

L’illustration suivante représente la planification de l’espace de noms pour une configuration de résilience de site.

Espaces de noms pour le déploiement d’un DAG de résilience de site

Comme expliqué ci-dessus, chaque centre de données utilise un espace de nom séparé et unique et contient des serveurs DNS dans une configuration de DNS réparti pour ces espaces de noms. Le centre de données Redmond, considéré comme le centre de données principal, est configuré avec un espace de noms protocol.contoso.com. Le centre de données de Portland, lui, est configuré avec un espace de noms protocol.standby.contoso.com. Les espaces de noms peuvent comprendre des attributions de veille, comme dans l’illustration de l’exemple, ils peuvent être basés sur la région (par exemple protocol.portland.contoso.com), ou sur d’autres conventions de dénomination correspondant aux besoins de votre organisation. La condition principale est que chaque centre de données ait son propre espace de noms unique, quelle que soit la convention de dénomination utilisée.

Configuration de la propriété FailbackURL

Certains navigateurs Web, notamment Microsoft Internet Explorer, conservent à chaque session de navigateur un cache de noms DNS distinct du cache DNS fourni par le système d’exploitation. Lors de la restauration du centre de données principal après un basculement de centre de données, l’utilisation de ce cache par le navigateur Web peut provoquer des connexions en boucle pour les utilisateurs d’Outlook Web App, processus par lequel les utilisateurs sont redirigés vers la même URL dans une boucle répétitive.

Lors du processus de restauration, l’adresse IP de l’espace de noms Outlook Web App passe dans le DNS d’un point de terminaison du centre de données de secours au point de terminaison d’origine correspondant dans le centre de données principal. À l’expiration de la durée de vie de l’enregistrement DNS et même après la suppression du cache DNS du système d’exploitation, les navigateurs Web qui gèrent leur propre cache de noms peuvent continuer à se connecter au point de terminaison du centre de données de secours, même si l’espace de noms est hébergé dans le centre de données principal.

En règle générale, la fermeture du navigateur Web suffit pour supprimer son cache de noms et prévenir les connexions en boucle. Cependant, pour réduire ce risque pour tous les navigateurs Web et les utilisateurs d’Outlook Web App, vous pouvez configurer la propriété FailbackURL de votre répertoire virtuel Outlook Web App. Le paramètre FailbackUrl spécifie le nom d’hôte utilisé par Outlook Web App pour se connecter au serveur d’accès au client après la restauration automatique d'un site principal. Cet espace de noms requiert une entrée DNS distincte pointant vers l’adresse IP du serveur d’accès au client d’origine. La valeur du paramètre FailbackUrl doit être différente de celle du paramètre ExternalUrl pour le répertoire virtuel Outlook Web App. Lorsqu’un utilisateur d’Outlook Web App fournit ses informations d’identification, le serveur d’accès au client détermine si l’URL de redirection est identique à celle visitée par l’utilisateur. Si les URL correspondent, le serveur d’accès au client vérifie si le paramètre FailbackUrl est configuré :

• Si le paramètre FailbackUrl est configuré, il redirige l’utilisateur vers cette URL via laquelle il devrait pouvoir accéder à Outlook Web App.

• Si le paramètre FailbackUrl n’est pas configuré, l’utilisateur reçoit un message d’erreur l’informant qu’une modification de la configuration du serveur bloque temporairement l’accès à sa boîte aux lettres. L’utilisateur est alors invité à fermer toutes les fenêtres du navigateur (ce qui provoque la suppression du cache de noms du navigateur) et à réessayer après quelques minutes.

Planification de certificat

Il n’y a pas de considération de conception spéciale ou unique pour les certificats lors du déploiement d’un groupe de disponibilité de base de données dans un centre de données unique. Toutefois, lorsque vous étendez un groupe de disponibilité de base de données sur plusieurs centres de données dans une configuration de résilience de site, il y a quelques considérations spécifiques en matière de certificats. Généralement, votre conception de certificat dépend des clients utilisés, ainsi que des conditions des autres applications utilisant des certificats. Certaines recommandations et meilleures pratiques doivent être observées en ce qui concerne le type et le nombre de certificats.

Il est conseillé de minimiser le nombre de certificats utilisés pour vos serveurs d’accès au client, vos serveurs proxy inverses et vos serveurs de transport (Edge et Hub). Il est recommandé d’utiliser un certificat unique pour tous ces points finaux de service dans chaque centre de données. Cette approche minimise le nombre de certificats nécessaires, ce qui réduit à la fois le coût et la complexité de la solution.

Pour les clients Outlook Anywhere, nous recommandons l’utilisation d’un seul certificat Autre Nom d’Objet (SAN) par centre de données, en incluant plusieurs noms d’hôtes dans le certificat. Pour assurer la connectivité d’Outlook Anywhere après une base de données, un serveur ou un basculement de centre de données, vous devez utiliser le même nom principal du certificat pour chaque certificat, et configurer l’objet configuration de fournisseur OutlookActive Directory avec le même nom de principal dans le formulaire Microsoft-Standard (msstd). Par exemple, si vous utilisez un nom de principal de certificat de mail.contoso.com, vous configurez les attributs de la manière suivante :

Set-OutlookProvider EXPR -CertPrincipalName "msstd:mail.contoso.com"

Quelques applications qui s’intègrent avec Exchange présentent des conditions spéciales de certificat qui peuvent nécessiter l’utilisation de certificats supplémentaires. Exchange 2010 peut coexister avec Office Communications Server (OCS). OCS requiert des certificats 1024 bits ou des certificats plus importants qui utilisent le nom de serveur OCS comme nom principal du certificat. Utiliser le nom de serveur OCS comme nom principal de certificat empêcherait Outlook Anywhere de fonctionner correctement. Il vous faut donc utiliser un certificat supplémentaire séparé pour l’environnement OCS.

Pour plus d’informations sur l’utilisation de certificats SAN pour l’accès au client Exchange 2010, consultez la rubrique Configurer les certificats SSL pour utiliser plusieurs noms d'hôtes de serveur d'accès au client.

Planification de réseau

En plus des conditions spécifiques de mise en réseau nécessaires pour chaque groupe de disponibilité de base de données ainsi que pour chaque serveur membre d’un groupe de disponibilité de base de données, il existe d’autres conditions et recommandations spécifiques aux configurations de résilience de site. Comme avec tous les groupes de disponibilité de base de données, que les membres du DAG soient déployés dans un seul site ou dans plusieurs sites, la latence du parcours circulaire du réseau entre les membres du groupe de disponibilité de base de données ne doit pas dépasser 500 millisecondes (ms). En outre, certains paramètres spécifiques de configuration sont recommandés pour les groupes de disponibilité de base de données étendus sur plusieurs sites :

• Les réseaux MAPI doivent être isolés des réseaux de réplication Les stratégies de réseau Windows, les stratégies de pare-feu Windows ou les listes de contrôle d’accès routeur (ACL) doivent être utilisées pour bloquer le trafic entre le réseau MAPI et le(s) réseau(x) de réplication. Cette configuration est nécessaire pour empêcher la pulsation de réseau inter-conversation.

• Les enregistrements DNS côté client doivent avoir une valeur de durée de vie (TTL, Time to Live) de 5 minutes Le temps d’indisponibilité vécu par les clients dépend non seulement de la rapidité du basculement, mais aussi de la vitesse à laquelle la réplication de DNS se produit et à laquelle les clients demandent les informations DNS mises à jour. Les enregistrements de DNS pour tous les services clients Exchange, y compris Outlook Web App, Exchange ActiveSync, Exchange Web services, Outlook Anywhere, les protocoles SMTP, POP3, IMAP4 et l’accès au client RPC dans les serveurs DNS internes et externes doivent être paramétrés avec un TTL de 5 minutes.

• Utilisation d’un routage statique pour configurer la connectivité sur les réseaux de réplication Utilisez un routage permanent statique pour fournir la connectivité de réseau entre les cartes du réseau de réplication. Ce processus consiste en une configuration rapide et unique, effectuée sur chaque membre du groupe de disponibilité de base de données lors de l’utilisation d’adresses IP statiques. Si vous utilisez un protocole DHCP pour obtenir des adresses IP pour vos réseaux de réplication, vous pouvez aussi l’utiliser pour affecter des routages statiques à la réplication et ainsi simplifier le processus de configuration.

Planification générale de résilience de site

En plus des conditions répertoriées ci-dessus pour la haute disponibilité, il existe d’autres recommandations pour le déploiement de Exchange 2010 dans une configuration de résilience de site (par exemple, l’extension d’un groupe de disponibilité de base de données sur plusieurs centres de données). Ce que vous faites pendant la phase de planification conditionnera directement la réussite de votre solution de résilience de site. Par exemple, une conception d’espace de noms médiocre peut entraîner des complications avec les certificats et une configuration de certificat incorrecte peut empêcher les utilisateurs d’accéder aux services.

Afin de minimiser le temps que prend l’activation d’un deuxième centre de données et de permettre à celui-ci d’héberger des points finaux de service d’un centre de données défaillant, il faut effectuer la planification appropriée. Par exemple :

• Vos objectifs SLA pour la solution de résilience de site doivent être bien compris et bien documentés.

• Les serveurs du deuxième centre de données doivent disposer d’une capacité suffisante pour héberger la population d’utilisateurs des deux centres de données.

• Tous les services du deuxième centre de données fournis dans le centre de données principal doivent être activés (à moins que le service ne soit pas inclus dans le cadre de l’accord SLA de résilience de site). Les services sont les suivants : Active Directory, infrastructure de réseau (DNS, TCP/IP etc), services de téléphonie (si la messagerie unifiée est utilisée) et infrastructure de site (courant, refroidissement, etc).

• Pour que certains services puissent fonctionner à partir du centre de données défaillant, les certificats de serveur qui conviennent doivent être configurés. Certains services ne permettent pas l’instanciation (par exemple, POP3 et IMAP4) et ne permettent que l’utilisation d’un seul certificat. Dans ces cas-là, soit le certificat doit être un certificat Autre nom d’objet (SAN) incluant plusieurs noms, soit les différents noms doivent être suffisamment similaires pour qu’un certificat générique puisse être utilisé (à condition que les stratégies de sécurité de l’organisation permettent l’utilisation de certificats génériques).

• Les services nécessaires doivent être définis dans le deuxième centre de données. Par exemple, si le premier centre de données a trois URL SMTP différentes sur différents serveurs de transport, la configuration appropriée doit être définie dans le deuxième centre de données afin d’activer au moins un (si ce n’est les trois) serveur(s) de transport pour héberger la charge de travail.

• La configuration de réseau nécessaire doit être en place pour prendre en charge le basculement de centre de données. Cela peut impliquer de veiller à ce que les configurations d’équilibrage de charge soient en place, que le serveur DNS général soit configuré et que la connexion Internet soit activée avec la configuration de routage appropriée.

• La stratégie d’activation des changements du DNS nécessaires au basculement de centre de données doit être comprise. Les changements DNS spécifiques, dont leurs paramètres TTL, doivent être définis et documentés pour prendre en charge le(s) SLA en vigueur.

• Une stratégie de test de la solution doit aussi être établie et prise en compte dans l’accord SLA. La validation périodique du déploiement représente la seule manière de garantir que la qualité et la viabilité du déploiement ne se dégradent pas avec le temps. Après la validation du déploiement, nous vous recommandons de documenter explicitement la partie de la configuration affectant directement la réussite de la solution. En outre, nous vous recommandons aussi d’améliorer vos processus de gestion des changements liés à ces segments du déploiement.

Conditions requises générales

Planification des basculements de centres de données

La bonne planification et préparation implique non seulement le déploiement des ressources du deuxième centre de données telles que les serveurs d’accès au client et de transport Hub en direct, mais aussi la pré-configuration de ces ressources afin de minimiser les changements nécessaires lors de l’opération de basculement de centre de données.

Remarque :
Les services d’accès au client et de transport Hub sont requis dans le deuxième centre de données, même quand l’activation automatique des bases de données de boîtes aux lettres du deuxième centre de données est bloquée. Ces services sont nécessaires aux opérations de basculement de bases de données, ainsi qu’au test et à la validation des services et données dans le deuxième centre de données.

Si l’on veut mieux comprendre comment fonctionne le processus de basculement de centre de données, il faut d’abord comprendre les opérations de base d’un basculement de centre de données Exchange 2010.

Comme illustré ci-après, un déploiement de résilience de site consiste en un groupe de disponibilité de base de données qui a des membres dans les deux centres de données.

Groupe de disponibilité de base de données avec des membres dans les deux centres de données

Quand un groupe de disponibilité de base de données est étendu sur plusieurs centres de données, il doit être conçu pour que la majorité des membres du groupe de disponibilité de base de données soient situés dans le centre de données principal, ou bien quand chaque centre de données a le même nombre de membres, pour que le centre de données principal héberge le serveur témoin. Cette conception garantit que le service sera fourni dans le centre de données principal même si la connectivité réseau entre les deux centres de données est défaillante. Cependant, cela implique aussi une perte de quorum pour les membres du deuxième centre de données en cas de défaillance du centre de données principal.

Il est possible que des échecs partiels de centre de données se produisent. On présume que si la fonctionnalité est suffisamment perdue dans le centre de données principal pour empêcher une gestion et un service efficace, alors un basculement de centre de données doit être effectué pour activer le deuxième centre de données. Le processus d’activation implique que l’administrateur configure l’arrêt de service des serveurs valides en état opérationnel partiel L’activation peut ensuite être effectuée dans le deuxième centre de données. Ces mesures sont prises pour empêcher que les deux ensembles de services tentent de fonctionner en même temps.

La conséquence de la perte de quorum est que les membres du groupe de disponibilité de base de données du deuxième centre de données ne peuvent pas se connecter automatiquement. De ce fait, l’activation des serveurs de boîte aux lettres dans le deuxième centre de données nécessite aussi une étape au cours de laquelle les serveurs membres du groupe de disponibilité de base de données sont forcés à créer un quorum, et à ce moment-là, les serveurs du centre de données défaillant sont supprimés du groupe de disponibilité de base de données en interne (mais seulement temporairement). Cela apporte une solution de service partiel qui est stable et capable de résister à un certain niveau de défaillances supplémentaires et de continuer à fonctionner.

Remarque :
Une des conditions pour résister aux pannes supplémentaires est que le groupe de disponibilité de base de données ait au moins quatre membres et que ceux-ci soient répartis entre deux sites Active Directory (par ex., au moins deux membres dans chaque centre de données).

C’est le processus basique utilisé pour rétablir la fonctionnalité de rôle de boîte aux lettres dans le deuxième centre de données. L’activation des autres rôles dans le deuxième centre de données n’implique pas d’actions explicites sur les serveurs touchés dans le deuxième centre de données. À la place, les serveurs du deuxième centre de données deviennent des points finaux de service pour les services qui sont normalement hébergés par le centre de données principal. Par exemple, un utilisateur normalement hébergé sur le centre de données principal peut se connecter à Outlook Web App à l’aide de https://mail.contoso.com/owa. Après une défaillance du centre de données, ces points finaux de service sont déplacés vers les points finaux du deuxième centre de données comme partie de l’opération de basculement. Pendant l’opération de basculement, les points finaux de service du centre de données principal sont re-ciblés vers d’autres adresses IP pour les mêmes services dans le deuxième centre de données. Cela minimise le nombre de changements qui doivent être apportés aux informations de configuration stockées dans Active Directory pendant le processus de basculement. En règle générale, il y a deux façons d’effectuer cette étape :

• Mettre à jour les enregistrements DNS ou

• Reconfigurer les DNS et les équilibrages de charge pour activer et désactiver les autres adresses IP en déplaçant les services entre les centres de données.

Une stratégie de test de la solution doit être établie. Elle doit être prise en compte dans le contrat de niveau de service. La validation périodique du déploiement représente la seule manière de garantir que le déploiement ne se dégrade pas avec le temps.

La manière dont vous effectuerez ces étapes de planification aura un impact direct sur la réussite du basculement de centre de données. Par exemple, une conception d’espace de noms médiocre peut entraîner des complications avec les certificats et une configuration de certificat incorrecte peut empêcher les utilisateurs d’accéder aux services.

Après la validation du déploiement, nous vous recommandons de documenter explicitement toutes les parties de la configuration affectant directement la réussite du basculement de centre de données. En outre, il peut être plus prudent d’améliorer vos processus de gestion des changements liés à ces segments du déploiement.

Pour plus d’informations sur les basculements de centre de données, et sur l’activation d’un centre de données secondaire ainsi que la réactivation d’un centre de données (principal) défaillant, consultez les rubriques Switchovers de centre de données.

Conditions requises générales

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