Présentation des groupes de disponibilité de base de données

 

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

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

Un groupe de disponibilité de base de données (DAG) est le composant de base de la structure de résilience de site et de haute disponibilité intégrée à Microsoft Exchange Server 2010. Un DAG est composé d'un maximum de 16 serveurs de boîtes aux lettres qui hébergent un ensemble de bases de données. Ces serveurs peuvent ainsi récupérer automatiquement des bases de données à la suite d'une panne d'un serveur ou lorsqu'une base de données n'est plus accessible.

Un DAG tient lieu de cadre pour la réplication de bases de données de boîtes aux lettres, le basculement et la permutation de bases de données et de serveurs et un composant Exchange 2010 interne appelé Active Manager. Active Manager, qui s'exécute sur chaque serveur dans un DAG, gère les basculements et les permutations. Pour plus d'informations sur Active Manager, consultez la rubrique Présentation du gestionnaire Active Manager.

N'importe quel serveur d'un DAG peut héberger une copie d'une base de données de boîtes aux lettres se trouvant sur un autre serveur du DAG. Lorsqu'un serveur est ajouté à un DAG, il fonctionne avec les autres serveurs de ce dernier pour assurer la récupération automatique des bases de données de boîtes aux lettres à la suite d'une panne d'un disque ou d'un serveur.

Contenu de cette rubrique

Cycle de vie du groupe de disponibilité de base de données

Utilisation d’un groupe de disponibilité de base de données pour la haute disponibilité

Utilisation d’un groupe de disponibilité de base de données pour la résilience de site

Expérience du client lors de l’utilisation de groupes de disponibilité de base de données

Cycle de vie du groupe de disponibilité de base de données

Les DAG s’appuient sur une fonctionnalité d’Exchange 2010 appelée déploiement incrémentiel, qui garantit la disponibilité des services et des données pour tous les serveurs et bases de données de boîtes aux lettres après l’installation d’Exchange. Après avoir déployé Exchange 2010, vous pouvez créer un DAG, y ajouter des serveurs de boîtes aux lettres et répliquer des bases de données de boîtes aux lettres entre les membres de ce DAG.

RemarqueRemarque :
Il est possible de créer un DAG comprenant une combinaison de serveurs de boîtes aux lettres physiques et virtuels, si les serveurs et les solutions répondent aux Configuration requise pour Exchange 2010. Comme pour toutes les configurations de haute disponibilité Exchange, vous devez vérifier que tous les serveurs de boîtes aux lettres du DAG sont correctement dimensionnés de façon à traiter la charge de travail complète lors des interruptions programmées et non programmées.

La création d'un DAG s'effectue à l'aide de la cmdlet New-DatabaseAvailabilityGroup. À sa création, le DAG est un objet vide dans Active Directory. Cet objet annuaire permet de stocker les informations nécessaires ayant trait au DAG, telles que les informations d’appartenance au DAG des serveurs. Lorsque vous ajoutez le premier serveur au DAG, un cluster de basculement est automatiquement créé pour le DAG. Ce cluster de basculement est utilisé exclusivement par le DAG et doit lui être dédié. L'utilisation du cluster à d'autres fins n'est pas prise en charge.

Outre la création d'un cluster de basculement, l'infrastructure qui surveille les serveurs pour détecter les pannes du réseau ou de serveurs est exécutée. Le mécanisme de pulsation du cluster de basculement et la base de données du cluster sont alors utilisés pour effectuer le suivi des informations liées au DAG et les gérer. Ces informations, qui peuvent changer rapidement, sont notamment l'état de montage de la base de données, l'état de réplication et le dernier emplacement monté.

Lors de sa création, le DAG reçoit un nom unique, et soit une ou plusieurs adresses IP statiques lui sont affectées, soit il est configuré pour utiliser le protocole DHCP. Vous pouvez spécifier une seule adresse IP ou une liste d’adresses IP séparées par une virgule à l’aide du paramètre DatabaseAvailabilityGroupIPAddresses.

Cet exemple montre un DAG qui aura trois serveurs. Deux serveurs (EX1 et EX2) sont sur le même sous-réseau (10.0.0.0) et le troisième (EX3) se trouve sur un autre sous-réseau (192.168.0.0).

New-DatabaseAvailabilityGroup -Name DAG1 -DatabaseAvailabilityGroupIPAddresses 10.0.0.5,192.168.0.5
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX3
RemarqueRemarque :
Si vous configurez le paramètre DatabaseAvailabilityGroupIPAddresses avec la valeur 0.0.0.0, le DAG (cluster) utilisera le protocole DHCP pour ses adresses IP ou ses ressources d’adresses IP.

Le cluster pour DAG1 est créé lorsqu'EX1 est ajouté au groupe de disponibilité de base de données. Au cours de la création du cluster, la cmdlet Add-DatabaseAvailabilityGroupServer récupère les adresses IP configurées pour le DAG et ignore celles qui ne correspondent à aucun des sous-réseaux trouvés sur EX1. Dans cet exemple, le cluster pour DAG1 est créé avec l’adresse IP 10.0.0.5 et l’adresse 192.168.0.5 est ignorée.

EX2 est ensuite ajouté et la cmdlet Add-DatabaseAvailabilityGroupServer récupère de nouveau les adresses IP configurées pour le DAG. Les adresses IP du cluster ne changent pas, car EX2 se trouve sur le même sous-réseau qu’EX1.

EX3 est ensuite ajouté et la cmdlet Add-DatabaseAvailabilityGroupServer récupère de nouveau les adresses IP configurées pour le DAG. Étant donné qu'un sous-réseau correspondant à l'adresse 192.168.0.5 est présent sur EX3, l'adresse 192.168.0.5 est ajoutée en tant que ressource d'adresse IP dans le groupe de clusters. En outre, une dépendance OR pour la ressource Nom du réseau de chaque ressource d'adresse IP est automatiquement configurée. L’adresse 192.168.0.5 sera utilisée par le cluster lorsque le groupe de clusters bascule vers EX3.

La fonctionnalité de clustering de basculement de Windows enregistre les adresses IP du cluster dans le DNS (Domain Name System) lorsque la ressource Nom du réseau est disponible en ligne. De plus, un objet nom de cluster est créé dans Active Directory. Le nom, l’adresse IP et l’objet nom du cluster sont utilisés en interne par le système uniquement pour sécuriser le DAG et à des fins de communication interne. Les administrateurs et les utilisateurs finaux n’ont pas besoin de communiquer, pour une raison ou une autre, avec le nom du DAG ni avec l’adresse IP ou de s’y connecter.

En plus de disposer d’un nom et d’adresses IP, le DAG est également configuré pour utiliser un serveur témoin et un répertoire témoin. Le serveur témoin et le répertoire témoin sont automatiquement spécifiés par le système, mais l’administrateur peut les indiquer manuellement.

Par défaut, un DAG est conçu pour utiliser la fonctionnalité de réplication continue intégrée pour répliquer des bases de données de boîtes aux lettres entre les serveurs qui en sont membres. Si vous utilisez la réplication de données tierce prenant en charge l’API de réplication tierce dans Exchange 2010, vous devez créer le DAG en mode réplication tierce à l’aide de la cmdlet New-DatabaseAvailabilityGroup avec le paramètre ThirdPartyReplication. Une fois que ce mode est activé, il ne peut pas être désactivé.

Une fois le DAG créé, des serveurs de boîtes aux lettres peuvent y être ajoutés. Lorsque le premier serveur est ajouté au DAG, un cluster qui sera utilisé par ce dernier est créé. Les DAG font un usage limité de la technologie de clustering de basculement de Windows ; il peut s’agir notamment de la pulsation de clusters, de réseaux de clusters et d’une base de données de clusters (pour stocker les données qui changent, par exemple lorsque l’état d’une base de données passe d’actif à passif et inversement, ou de montée à démontée et inversement). Lorsqu’un serveur est ajouté au DAG, il est ajouté au cluster sous-jacent. Le modèle de quorum du cluster est automatiquement ajusté par le système et le serveur est ajouté à l’objet du DAG dans Active Directory.

Après l'ajout de serveurs de boîtes aux lettres à un DAG, vous pouvez configurer plusieurs propriétés, comme l'utilisation du chiffrement ou de la compression réseau pour la réplication des bases de données au sein du DAG. Vous pouvez également configurer des réseaux de DAG et en créer.

Une fois que vous avez ajouté des membres à un DAG et configuré celui-ci, vous pouvez répliquer les bases de données de boîtes aux lettres actives se trouvant sur chaque serveur sur les autres membres du DAG. Vous pouvez ensuite surveiller l'intégrité et l'état des copies de ces bases de données à l'aide de différents outils de surveillance intégrés. Vous pouvez également effectuer des permutations de serveurs et de bases de données.

Pour plus d'informations sur la création d'un DAG, la gestion des serveurs membres d'un DAG, la configuration des propriétés d'un DAG, la création de copies de bases de données de boîtes aux lettres et leur surveillance et sur les permutations de serveurs et de bases de données, consultez la rubrique Gestion de la haute disponibilité et de la résilience de site.

Modèles de quorum des groupes de disponibilité de base de données

Un cluster de basculement de Windows se trouve sous chaque DAG. Les clusters de basculement utilisent le concept de quorum, qui utilise lui-même un consensus de votants pour assurer que seul un sous-ensemble des membres du cluster (ce qui pourrait signifier tous les membres ou une majorité des membres) fonctionne à la fois. Le quorum n’est pas un nouveau concept pour Exchange 2010. Les serveurs de boîtes aux lettres à haut niveau de disponibilité dans les versions précédentes d'Exchange utilisent aussi les clusters de basculement et le concept du quorum. Le quorum représente une vue partagée des membres et des ressources, et le terme quorum est également utilisé pour décrire les données physiques représentant la configuration au sein du cluster partagé entre tous les membres du cluster. Les clusters de basculement de tous les groupes de disponibilité de base de données doivent donc avoir un quorum. Si le cluster perd son quorum, toutes les opérations du DAG sont terminées et toutes les bases de données montées hébergées dans le DAG sont démontées. Dans ce cas, une intervention de l’administrateur est requise pour corriger le problème du quorum et restaurer les opérations du DAG.

Le quorum est important pour assurer la cohérence, départager pour éviter le partitionnement, et réduire le temps de réponse des clusters :

  • Assurer la cohérence   Une exigence cruciale pour un cluster de basculement de Windows est que chacun des membres garde toujours une vue du cluster qui est cohérente avec celle des autres membres. La ruche de cluster agit comme le référentiel définitif pour toutes les informations de configuration relatives au cluster. Si la ruche de cluster ne peut pas être chargée localement sur un membre DAG, le service de cluster ne démarre pas car il n'est pas en mesure de garantir que le membre satisfait à l'exigence d'avoir une vue du cluster qui est cohérente avec celle des autres membres.

  • Départager   Une ressource de témoin de quorum est utilisée dans les DAG avec un nombre pair de membres afin d'éviter les scénarios de Split-Brain Syndrome et pour s'assurer qu'un seul ensemble de membres de la DAG est considéré comme étant officiel. Quand le serveur témoin devient nécessaire pour le quorum, tout membre du DAG qui peut communiquer avec le serveur témoin peut placer un SMB (Server Message Block) dans le fichier witness.log du serveur témoin. Le membre du DAG qui verrouille le serveur témoin (appelé le nœud de verrouillage) conserve un vote supplémentaire pour le quorum. Les membres du DAG en contact avec le nœud de verrouillage sont majoritaires et conservent le quorum. Les membres du DAG qui ne peuvent pas communiquer avec le nœud de verrouillage sont minoritaires et perdent ainsi le quorum.

  • Réduire le temps de réponse   Pour assurer la réactivité, le modèle de quorum vérifie que, chaque fois que le cluster s'exécute, un nombre suffisant de membres du système distribué sont opérationnels et aptes à communiquer, et qu'au moins une réplique de l'état actuel du cluster peut être garantie. Aucun délai supplémentaire n'est nécessaire pour que les membres entrent en communication ou pour déterminer si une réplique spécifique est garantie.

Les DAG comportant un nombre pair de membres utilisent le mode de quorum de nœuds et de partage de fichiers majoritaire du cluster de basculement. Ce mode fait appel à un serveur témoin externe pour départager. Dans ce mode de quorum, chaque membre du DAG obtient un vote. En outre, le serveur témoin est utilisé pour donner à un membre du DAG un vote pondéré (il obtient par exemple deux votes au lieu d’un seul). Les données du quorum du cluster sont stockées par défaut sur le disque système de chaque membre du DAG et leur cohérence est maintenue sur l'ensemble de ces disques. Toutefois, aucune copie des données du quorum n'est stockée sur le serveur témoin. Un fichier sur le serveur témoin est utilisé pour surveiller quel membre a la copie la plus récente des données, mais le serveur témoin ne possède pas de copie des données du quorum du cluster. Dans ce mode, une majorité des votants (les membres du DAG plus le serveur témoin) doivent être opérationnels et aptes à communiquer les uns avec les autres pour conserver le quorum. Si une majorité des votants ne peuvent pas communiquer entre eux, le cluster sous-jacent du DAG perd le quorum et le DAG nécessitera une intervention de l'administrateur pour redevenir opérationnel.

Les DAG comportant un nombre impair de membres utilisent le mode de quorum Nœud majoritaire du cluster de basculement. Dans ce mode, chaque membre obtient un vote et le disque système local de chaque membre est utilisé pour stocker les données du quorum du cluster. Si la configuration du DAG change, cette modification est apportée sur les différents disques. La modification est considérée comme validée ou rendue permanente uniquement si elle est apportée sur les disques de la moitié des membres (arrondis à la valeur inférieure) plus un. Par exemple, dans un DAG composé de cinq membres, la modification doit être effectuée sur deux membres plus un, ou un total de trois membres.

Le quorum requiert qu'une majorité des votants soient aptes à communiquer les uns avec les autres. Prenons un DAG constitué de quatre membres. Du fait que ce DAG possède un nombre pair de membres, un serveur témoin externe est utilisé pour accorder à l'un des membres du cluster un cinquième vote de départage. Pour conserver une majorité des votants (et donc le quorum), trois votants minimum doivent être aptes à communiquer les uns avec les autres. À tout moment, jusqu'à deux votants peuvent être déconnectés sans perturber les services et l'accès aux données. Si trois votants ou plus sont déconnectés, le DAG perd le quorum, et le service et l'accès aux données sont interrompus tant que vous n'aurez pas résolu le problème.

Retour au début

Utilisation d’un groupe de disponibilité de base de données pour la haute disponibilité

Pour montrer de quelle manière un DAG permet d'assurer un haut niveau de disponibilité des bases de données de boîtes aux lettres, prenons l'exemple suivant, dans lequel un DAG comporte cinq membres. L'illustration suivante représente ce DAG.

DAG comportant cinq membres

Groupe de disponibilité de la base de données

Dans l'illustration précédente, les bases de données vertes sont des copies de bases de données de boîtes aux lettres actives et les bases de données bleues sont des copies de bases de données de boîtes aux lettres passives. Dans cet exemple, les copies de bases de données ne sont pas répliquées de manière identique sur chaque serveur, elles sont réparties sur plusieurs serveurs. Ainsi, deux serveurs ne comportent pas le même ensemble de copies de bases de données, ce qui rend le DAG plus résilient aux pannes, notamment les pannes qui se produisent lorsque d'autres composants sont indisponibles pour des raisons de maintenance.

Examinons le scénario suivant, basé sur l'exemple précédent, qui illustre la résilience à plusieurs pannes de base de données et de serveur.

Au départ, tous les serveurs et bases de données sont en bon état de fonctionnement. Vous devez installer certaines mises à jour du système d’exploitation sur EX2. Vous effectuez une permutation de serveur, qui active la copie de DB4 sur un autre serveur de boîtes aux lettres. Une permutation de serveur fait passer toutes les copies des bases de données de boîtes aux lettres d'un serveur vers d'autres serveurs de boîtes aux lettres du DAG en vue d'une mise hors service programmée de ce serveur. Vous pouvez effectuer un basculement rapide de serveur en exécutant la commande suivante dans l’environnement de ligne de commande Exchange Management Shell.

Move-ActiveMailboxDatabase -Server EX2

Dans cet exemple, une seule base de données de boîtes aux lettres est active sur EX2 (DB4), par conséquent, une seule copie de base de données active est déplacée. En omettant le paramètre ActivateOnServer dans la commande précédente, vous décidez de confier au système la sélection de la meilleure nouvelle copie de base de données. Le système choisit la copie sur le serveur EX5, comme le montre l’illustration suivante.

DAG avec un serveur déconnecté pour des raisons de maintenance

Groupe de disponibilité de la base de données avec un serveur hors ligne

Lorsque vous procédez à la maintenance du serveur EX2, EX3 subit une panne matérielle catastrophique et est déconnecté. Avant d'être déconnecté, le serveur EX3 hébergeait la copie active de DB2. Pour récupérer la base de données DB2 à la suite de la panne, le système active automatiquement la copie de DB2 qui est hébergée sur EX1 dans un délai de 30 secondes. Cela est montré dans l'illustration suivante.

DAG avec un serveur hors ligne pour des raisons de maintenance et un serveur défaillant

Groupe de disponibilité de la base de données avec un serveur hors ligne et un serveur défaillant

Une fois que la maintenance planifiée d’EX2 est terminée, vous le reconnectez. Dès qu'EX2 est disponible, les autres membres du DAG en sont notifiés et les copies de DB1, DB4 et DB5 qui sont hébergées sur EX2 sont automatiquement synchronisées avec la copie active de chaque base de données. Cela est montré dans l'illustration suivante.

DAG avec un serveur restauré synchronisant ses copies de bases de données

Groupe de disponibilité de la base de données avec bases de données de resynchronisation de serveurs restaurées

Une fois que le composant matériel tombé en panne dans EX3 a été remplacé par un nouveau composant, EX3 est mis en ligne. Dès qu'EX3 est disponible, les autres membres du DAG en sont notifiés et les copies de DB2, DB3 et DB4 qui sont hébergées sur EX3 sont automatiquement synchronisées avec la copie active de chaque base de données. Cela est montré dans l'illustration suivante.

DAG avec un serveur réparé synchronisant ses copies de bases de données

Groupe de disponibilité de la base de données avec copies de bases de données de resynchronisation membres

Retour au début

Utilisation d’un groupe de disponibilité de base de données pour la résilience de site

En plus d'assurer un haut niveau de disponibilité dans un centre de données, un DAG peut également être étendu à d'autres centres de données dans une configuration qui en garantit la résilience de site. Dans les illustrations des exemples précédents, le DAG est situé dans un seul centre de données et un seul site Active Directory. Le déploiement incrémentiel peut être utilisé pour étendre ce DAG à un second centre de données (et un second site Active Directory) en déployant un serveur de boîtes aux lettres et les ressources nécessaires (un ou plusieurs serveurs Active Directory, et un ou plusieurs serveurs de transport Hub et d’accès au client). Le serveur de boîte aux lettres est ensuite ajouté au DAG, comme illustré dans la figure suivante.

Groupe de disponibilité de la base de données étendu à deux sites Active Directory

Groupe de disponibilité de la base de données étendu à deux sites Active Directory

Dans cet exemple, une copie passive de chaque base de données active du centre de données de Redmond est configurée sur EX6 dans le centre de données de Dublin. Toutefois, de nombreux autres exemples de configurations DAG fournissent une résilience de site. Par exemple :

  • Au lieu d'héberger seulement des copies de base de données passives, EX6 pourrait héberger toutes les copies actives, ou il pourrait héberger un mélange de copies actives et passives.

  • En plus d'EX6, plusieurs membres de DAG pourraient être déployés dans le centre de données de Dublin pour assurer la protection contre les défaillances supplémentaires. Cette configuration fournit également une capacité supplémentaire, de sorte que si le centre de données de Redmond tombe en panne, celui de Dublin peut prendre en charge une population d'utilisateurs beaucoup plus importante.

Utilisation de plusieurs groupes de disponibilité de base de données pour la résilience de site

Dans l'exemple précédent, un seul DAG s'étend sur plusieurs centres de données, offrant la résilience de site pour l'un des centres de données ou les deux à la fois. Quand on utilise un seul DAG afin de fournir la résilience de site dans un environnement où chaque centre de données auquel vous étendez le DAG a une population d'utilisateurs actifs, il y a un point unique de défaillance dans la connexion de réseau étendu (WAN). Ceci est dû au fait que le quorum requiert qu'une majorité des votants soient aptes à communiquer les uns avec les autres.

Dans l'exemple précédent, la majorité des votants sont situés dans le centre de données de Redmond. Si le centre de données de Dublin héberge des bases de données de boîtes aux lettres actives et s'il a une population d'utilisateurs locaux, une panne du réseau étendu entraînerait l'interruption du service de messagerie pour les utilisateurs de Dublin. Lorsque la connectivité du réseau étendu est rompue, seuls les membres du DAG dans le centre de données de Redmond conservent le quorum et continuent d'offrir le service de messagerie.

Pour résoudre le problème du réseau étendu comme seul point de défaillance lorsque vous devez fournir la résilience de site pour plusieurs centres de données ayant chacun une population d'utilisateurs actifs, vous devez déployer plusieurs DAG dont chacune possède une majorité de votants dans un centre de données distinct. Lorsqu'une panne du réseau étendu survient, la réplication est bloquée jusqu'à ce que la connectivité soit restaurée. Les utilisateurs disposent du service de messagerie car chaque DAG continue de servir sa population d'utilisateurs locaux.

Retour au début

Expérience du client lors de l’utilisation de groupes de disponibilité de base de données

Les DAG peuvent servir à offrir à la fois haute disponibilité et résilience de site. L’expérience du client lors de l’utilisation d’un DAG varie selon le type et la version du client et le protocole utilisé par le client pour accéder aux données de boîte aux lettres. Par exemple, si un basculement de base de données intersite se produit, la logique de comportement et de reconnexion utilisée par un client POP3 ou IMAP4 est différente de celle d’un client Microsoft Outlook 2010.

Les sections suivantes décrivent la logique et le comportement du client dans divers scénarios. Le comportement décrit suppose que :

  • L’environnement contient un seul groupe de serveurs d’accès au client dans chaque site Active Directory et chaque site contient au moins deux serveurs d’accès au client.

  • Un équilibreur de charge matériel ou logiciel approprié est installé et configuré face au groupe de serveurs d’accès au client.

  • Une planification et une configuration appropriées des espaces de noms et des certificats ont été effectuées, avec les enregistrements DNS nécessaires.

Comportement et logique de Microsoft Outlook

En général, toutes les versions d’Outlook se comportent de la même façon pour les basculements de base de données qui surviennent dans un même centre de données et un même site Active Directory. Contrairement aux versions précédentes d’Exchange, dans Exchange 2010, Outlook ne se connecte plus directement à la banque Exchange sur le serveur de boîtes aux lettres. Au lieu de cela, Outlook (et tout autre client MAPI) se connecte aux services Accès au client RPC et Carnet d’adresses sur le rôle serveur d’accès au client, et le logiciel Outlook de l’utilisateur est configuré pour se connecter au groupe de serveurs d’accès au client, qui connecte ensuite le client à un serveur d’accès au client individuel. Cette abstraction de la connexion de Outlook loin du serveur de boîtes aux lettres présente les avantages suivants :

  • En cas de basculement de base de données, Outlook reste connecté au même serveur dans le groupe de serveurs d’accès au client. Lorsque cela se produit, le client Active Manager exécuté sur le serveur d’accès au client apprend quel membre du DAG héberge la copie de la base de données active par le client Active Manager du DAG. Ensuite, le serveur d’accès au client se connecte à ce serveur de boîtes aux lettres et Outlook signale qu’il est connecté au serveur Exchange.

  • Si un des serveurs du groupe de serveurs d’accès au client devient indisponible en raison d’un arrêt prévu ou d’une panne imprévue, les serveurs d’accès au client restants dans ce groupe gèrent la charge du client. Étant donné qu’Outlook est configuré pour se connecter au groupe de serveurs d’accès au client et pas à un serveur individuel, les membres du groupe peuvent connaître individuellement des pannes ou des déconnexions manuelles sans impact sur le profil Outlook de l’utilisateur. Cela peut se produire automatiquement (par exemple, lors d’une reconfiguration automatique du groupe suite à la surveillance effectuée par la solution d’équilibreur de charge face au groupe) ou vous pouvez réaliser l’opération manuellement.

Toutes les versions d’Outlook se comportent de la même façon pour les basculements de centre de données qui surviennent entre deux centres de données et deux sites Active Directory. Les basculements de centre de données impliquent la modification des adresses IP utilisées par les espaces de noms d’accès au client (par exemple, Microsoft OfficeOutlook Web App, SMTP, POP3, IMAP4, la découverte automatique, les services web Exchange ou le service d’accès au client RPC) à partir des adresses IP dans le centre de données principal jusqu’aux adresses IP dans le centre de données secondaire. Par conséquent, l’espace de noms utilisé dans le profil Outlook de l’utilisateur ne change pas et la découverte automatique continue d’orienter les clients vers le même espace de noms du groupe de serveurs d’accès au client.

Le comportement d’Outlook après un basculement de base de données intersite est différent de celui qui suit un basculement de base de données dans un site Active Directory unique ou celui d’un basculement de centre de données.

Exemple de comportement pour des versions d’Outlook

Les exemples suivants illustrent le comportement d’Outlook 2010, Office Outlook 2007 et Office Outlook 2003 suite à un basculement de base de données intersite. La topologie utilisée dans chaque exemple est un DAG constitué de quatre membres étendu sur deux sites Active Directory : Redmond et Portland. La boîte aux lettres de l’utilisateur est hébergée sur DB1, qui est répliquée sur chacun des serveurs. Dans chaque exemple, la copie active de DB1 bascule de MBX2 vers MBX3.

Exemple de topologie démontrant le comportement d’Outlook après un basculement de base de données intersite

Comportement d’Outlook avec les groupes de disponibilité de base de données

Chaque client est configuré avec CAS1 comme serveur associé, ce qui fait de Redmond le site de profil Outlook. Du fait que les clients sont situés sur Redmond, la propriété RPCClientAccessServer pour DB1 est configurée pour CAS1, ce qui fait de Redmond le site privilégié de la base de données. Puisque DB1 a échoué sur MBX2 et qu’elle est devenue active sur MBX3, Portland est le site de la base de données montée.

Exemple pour Outlook 2010 et Outlook 2007

Si un serveur d’accès au client est disponible sur le site Redmond, Outlook 2010 et Outlook 2007 continuent de se connecter au groupe d’accès au client RPC sur le site Redmond. Le serveur d’accès au client utilisé par le client continuera d’utiliser MAPI RPC pour communiquer avec le serveur de boîtes aux lettres de l’utilisateur sur le site Portland.

Si aucun serveur d’accès au client n’est disponible sur le site Redmond, un basculement de centre de données doit être effectué de Redmond à Portland pour rétablir l’accès au service et aux données. Pour obtenir la procédure détaillée d’exécution d’un basculement de centre de données, consultez la rubrique Effectuer un basculement de serveur.

Exemple pour Outlook 2003

Quand Outlook 2003 tente de se connecter à CAS1, il reçoit aussi un message ecWrongServer en réponse. Contrairement à Outlook 2010 et Outlook 2007, Outlook 2003 n’inclut pas la fonctionnalité de découverte automatique et doit utiliser d’autres moyens pour mettre à jour le profil de l’utilisateur. La redirection de profil MAPI est le mécanisme utilisé par Outlook 2003. La redirection de profil MAPI exige que le serveur source d’origine soit en ligne. Si CAS1 n’est pas disponible et si tous les autres serveurs d’accès au client dans le groupe sont également indisponibles (ou si le groupe contient seulement CAS1), Outlook 2003 ne peut pas effectuer la redirection MAPI ou se connecter à la base de données de boîtes aux lettres de l’utilisateur sans intervention manuelle.

Comportement et logique d’Outlook lorsque des dossiers publics sont utilisés

Bien que les bases de données de dossiers publics puissent être hébergées sur des serveurs de boîtes aux lettres membres d’un DAG, elles n’utilisent pas la réplication continue. Elles s’appuient sur la réplication des dossiers publics pour maintenir une haute disponibilité. Le comportement des clients Outlook qui se reconnectent à une base de données de dossiers publics suite à un basculement de base de données de boîtes aux lettres dépend non seulement de la nature de la panne, mais également de vos paramètres de configuration de la réplication de dossiers publics, ainsi que de la santé et de la tenue à jour de vos bases de données de dossiers publics. Étant donné que la réplication continue ne peut pas être utilisée pour les bases de données de dossiers publics, la haute disponibilité des bases de données de dossiers publics est proposée par le déploiement de plusieurs bases de données de dossiers publics et leur configuration de sorte qu’ils se répliquent les uns avec les autres. Il est recommandé de configurer plus d’une réplique de chaque dossier.

Comportement et logique d’un client non Outlook

En règle générale, le comportement des clients et des protocoles autres qu’Outlook et MAPI dépend de l’application utilisée et du scénario de la panne. En général, comme pour Outlook, les applications et clients Exchange courants (par exemple, Outlook Web App, Microsoft Exchange ActiveSync, POP3, IMAP4 et les services web Exchange) se comportent de la même façon pour les basculements de base de données qui surviennent dans un même centre de données et un même site Active Directory. De même, tous ces clients et protocoles (y compris SMTP et Windows PowerShell) se comportent de la même façon qu’Outlook après un basculement de centre de données.

Si un basculement de base de données intersite se produit, le comportement varie selon ces clients et protocoles. Le tableau suivant présente le comportement de ces clients.

Comportement de basculement de base de données intersite pour des clients Exchange courants

Client ou protocole Comportement

Outlook Web App

Redirection manuelle. Dans ce scénario, l’espace de noms du client passe de http://mailred.contoso.com à http://mailpdx.contoso.com. Lorsque l’utilisateur saisit des informations d’identification d’ouverture de session, il est redirigé vers CAS2 dans le site de Portland à travers une page de redirection manuelle expliquant que l’URL incorrecte a été utilisée et que l’URL correcte est https://mailpdx.contoso.com/owa.

Exchange ActiveSync

Proxy ou redirection. Dans ce scénario, le comportement du client est déterminé par l’implémentation et la version du protocole Exchange ActiveSync sur le périphérique client.

POP3 et IMAP4

Proxy. Ce scénario implique toujours d’établir des connexions proxy d’un serveur d’accès au client à un autre.

Services web Exchange

Utilise la découverte automatique afin de déterminer le nouveau point de terminaison de connexion.

Retour au début

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