Gestion de groupes de disponibilité de base de données

  • Article

 

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

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

Un groupe de disponibilité de base de données (DAG) est composé d’un maximum de 16 serveurs de boîtes aux lettres Microsoft Exchange Server 2010 qui permettent une récupération automatique au niveau de la base de données en cas de défaillance d’une base de données, d’un serveur ou du réseau. Les groupes de disponibilité de base de données (DAG) utilisent la réplication continue et un sous-ensemble de technologies de clustering avec basculement Windows pour fournir la haute disponibilité et la résilience de site. Les serveurs de boîtes aux lettres d’un groupe de disponibilité de base de données (DAG) se surveillent mutuellement pour détecter les défaillances. Lorsqu’un serveur de boîtes aux lettres est ajouté à un groupe de disponibilité de base de données, il fonctionne avec les autres serveurs du groupe de disponibilité de base de données pour assurer la récupération automatique des défaillances de la base de données.

Lorsque vous créez un DAG, celui-ci est vide au départ, et un objet répertoire est créé dans l’instance Active Directory qui représente le DAG. L’objet répertoire est utilisé pour stocker les informations nécessaires ayant trait au DAG, telles que les informations d’appartenance du serveur. Lorsque vous ajoutez le premier serveur au DAG, un cluster de basculement est automatiquement créé pour le DAG. En outre, l’infrastructure qui surveille les serveurs pour détecter les défaillances de réseau ou de serveur est lancé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é.

Contenu de cette rubrique

Création de groupes de disponibilité de base de données

Appartenance au groupe de disponibilité de base de données

Configuration des propriétés du groupe de disponibilité de base de données

Réseaux DAG

Configuration des membres du groupe de disponibilité de base de données

Exécution de la maintenance sur les membres du groupe de disponibilité de base de données

Arrêt des membres DAG

Installation des correctifs cumulatifs sur les membres DAG

Création de groupes de disponibilité de base de données

Un DAG peut être créé à l’aide de l’Assistant Nouveau groupe de disponibilité de base de données dans la console de gestion Exchange ou en exécutant la cmdlet New-DatabaseAvailabilityGroup dans l’environnement de ligne de commande Exchange Management Shell. Lorsque vous créez un DAG, vous lui donnez un nom, et accessoirement un serveur témoin ainsi que des paramètres de répertoire témoin. En outre, une ou plusieurs adresses IP sont affectées au DAG soit par le biais d’adresses IP statiques soit en permettant au DAG d’affecter automatiquement les adresses IP nécessaires à l’aide du protocole DHCP (Dynamic Host Configuration Protocol). Vous pouvez affecter manuellement des adresses IP au groupe de disponibilité de base de données en utilisant le paramètre DatabaseAvailabilityGroupIpAddresses. Si vous omettez ce paramètre, le DAG tentera d’obtenir une adresse IP en utilisant un serveur DHCP sur votre réseau.

Pour obtenir la procédure détaillée de création d’un DAG, voir Créer un groupe de disponibilité de la base de données.

Lorsque vous créez un DAG, un objet vide représentant le DAG portant le nom que vous avez indiqué et une classe d’objet dumsExchMDBAvailabilityGroup sont créés dans Active Directory.

Les DAG utilisent un sous-ensemble de technologies de clustering avec basculement 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 ou qui peuvent changer rapidement, 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). Puisque les DAG reposent sur le clustering de basculement Windows, ils peuvent uniquement être créés sur des serveurs de boîtes aux lettres Exchange 2010 exécutant le système d’exploitation Windows Server 2008 Enterprise ou Windows Server 2008 R2 Enterprise.

RemarqueRemarque :
Le cluster de basculement créé et utilisé par le groupe de disponibilité de base de données (DAG) doit être dédié au DAG. Le cluster ne peut pas être utilisé pour toute autre solution de disponibilité élevée ou pour tout autre rôle. Par exemple, le cluster de basculement ne peut pas être utilisé pour mettre en cluster d’autres applications ou services. L’utilisation d’un cluster de basculement du groupe de disponibilité de base de données pour des rôles autres que le DAG n’est pas prise en charge.

Serveur témoin pour le DAG et répertoire témoin

Lorsque vous créez un DAG, vous devez lui donner un nom contenant 15 caractères au maximum et unique dans la forêt Active Directory. En outre, chaque DAG est configuré avec un serveur et un répertoire témoins. Le serveur témoin et son répertoire ne sont utilisés qu’à des fins de quorum avec un nombre pair de membres dans le groupe de disponibilité de base de données. Il n’est pas nécessaire de créer le répertoire témoin à l’avance. Exchange crée et sécurise automatiquement le répertoire pour vous sur le serveur témoin. Le répertoire ne doit pas être utilisé pour autre chose que le serveur DAG témoin.

La configuration requise pour le serveur témoin est la suivante :

  • Le serveur témoin ne peut pas être membre DAG.

  • Le serveur témoin doit se trouver dans la même forêt Active Directory que le groupe de disponibilité de base de données.

  • Le serveur témoin doit exécuter Windows Server 2003 ou une version ultérieure.

  • Un serveur unique peut servir de témoin pour plusieurs groupes de disponibilité de base de données. Cependant, chaque groupe de disponibilité nécessite son propre répertoire témoin.

Nous vous recommandons d’utiliser un serveur de transport Hub Exchange 2010 dans le site Active Directory contenant le groupe de disponibilité de base de données. Ainsi, le serveur témoin et le répertoire restent sous le contrôle d’un administrateur Exchange. Quel que soit le serveur utilisé comme serveur témoin, si le pare-feu Windows est activé sur le serveur témoin désigné, vous devez activer l’exception du pare-feu Windows pour le partage de fichiers et d’imprimantes.

ImportantImportant :
Si le serveur témoin que vous spécifiez n’est pas un serveur Exchange 2010, vous devez ajouter le groupe de sécurité universel du sous-système approuvéExchange au groupe Administrateurs local sur le serveur témoin avant de créer le groupe de disponibilité de base de données. Ces autorisations de sécurité sont nécessaires pour garantir que Exchange peut créer un répertoire et un partage sur le serveur témoin au besoin.

Il n’est pas nécessaire que le serveur témoin et le répertoire témoin aient une tolérance de panne ni une autre forme de redondance ou de haute disponibilité. Il n’est pas nécessaire d’utiliser un serveur de fichiers en cluster pour le serveur témoin ni d’employer une autre forme de résilience pour le serveur témoin. et ce pour plusieurs raisons. Dans les grands DAG (par exemple, avec six membres ou plus), il faut plusieurs pannes avant d’avoir besoin d’un serveur témoin. Comme un DAG à six membres peut tolérer un maximum de deux pannes de serveur sans perdre de quorum, il faudrait que trois membres tombent en panne avant que le serveur témoin soit nécessaire pour maintenir le quorum. De même, si une panne touche votre serveur témoin actuel (par exemple, si vous perdez le serveur témoin à cause d’une défaillance matérielle), vous pouvez employer la cmdlet Set-DatabaseAvailabilityGroup pour configurer un nouveau serveur témoin et un répertoire témoin (si vous avez un quorum).

RemarqueRemarque :
Vous pouvez aussi utiliser la cmdlet Set-DatabaseAvailabilityGroup pour configurer le serveur témoin et le répertoire témoin à l’emplacement d’origine si le serveur témoin a perdu son stockage ou si quelqu’un a modifié les autorisations de partage ou du répertoire témoin.

Dans un environnement où un DAG est étendu entre plusieurs centres de données (et sites Active Directory) et configuré pour la résilience de site, nous vous recommandons d’utiliser un serveur témoin dans votre centre de données principal (le centre de données contenant la majorité de vos utilisateurs). Si chaque centre de données a un nombre d’utilisateurs similaire, le centre de données que vous choisissez pour héberger le serveur témoin sera considéré comme le centre de données principal du point de vue de la solution. Si le serveur témoin se trouve dans le centre de données comportant la majorité de la population des clients, ces derniers conserveront en majorité l’accès après une panne.

Si le centre de données est à distance des grandes populations d’utilisateurs, cela peut influencer votre décision. Il vous faudrait alors déterminer s’il est nécessaire que le centre de données principal demeure sain et actif en cas de perte de connectivité WAN avec les deux autres centres de données. Dans ce cas, le serveur témoin devrait aussi se trouver dans le centre de données principal.

Bien qu’il soit possible d’utiliser un serveur témoin dans un troisième centre de données, nous ne le recommandons pas. D’un point de vue Exchange, cette configuration ne vous procure pas une plus grande disponibilité. Il est important que vous examiniez les facteurs de chemin critiques si vous utilisez un serveur témoin dans un troisième centre de données. Par exemple, si la connexion WAN entre le centre de données principal, le second et le troisième est défaillante, la solution n’est plus disponible dans le centre principal.

Spécification d’un serveur témoin et d’un répertoire témoin lors de la création d’un DAG

Lorsque vous créez un groupe de disponibilité de base de données, vous devez lui donner un nom. Vous pouvez aussi éventuellement spécifier un serveur témoin et un répertoire témoin. Si vous spécifiez un serveur témoin, nous vous recommandons d’utiliser un serveur de transport Hub, car cela permet à un administrateur Exchange de connaître la disponibilité du serveur témoin.

Lors de la création d’un DAG, les combinaisons de comportements et d’options suivantes sont disponibles :

  • Vous pouvez n’indiquer que le nom du DAG et laisser les champs Serveur témoin et Répertoire témoin vides. Dans ce scénario, l’Assistant va rechercher un serveur de transport Hub qui ne possède pas de rôle serveur de boîte aux lettres et va automatiquement créer le répertoire par défaut (%SystemDrive%:\DAGFileShareWitnesses\<DAGFQDN>) et le partage par défaut (<DAGFQDN>) sur ce serveur, puis utiliser ce serveur de transport Hub comme serveur témoin. Par exemple, imaginez un serveur témoin appelé EXMBX3 sur lequel le système d’exploitation a été installé sur le lecteur C. Un DAG appelé DAG1 dans un domaine appelé contoso.com aurait recours à un répertoire témoin par défaut de C:\DAGFileShareWitnesses\DAG1.contoso.com, qui serait partagé en tant que \\EXMBX3\DAG1.contoso.com.

  • Vous pouvez donner un nom au groupe de disponibilité de base de données, au serveur témoin que vous souhaitez utiliser et au répertoire qui sera créé et partagé sur le serveur témoin.

  • Vous pouvez donner un nom au DAG et au serveur témoin que vous voulez utiliser et laisser le champ Répertoire témoin vide. Dans ce scénario, l’Assistant va créer le répertoire par défaut sur le serveur témoin spécifié.

  • Vous pouvez donner un nom au DAG, laisser le champ Serveur témoin vide et spécifier le répertoire que vous voulez créer et partager sur le serveur témoin. Dans ce scénario, l’Assistant va rechercher un serveur de transport Hub qui ne possède pas de rôle serveur de boîte aux lettres et va automatiquement créer le DAG spécifié sur ce serveur, partager le répertoire, puis utiliser ce serveur de transport Hub comme serveur témoin.

Une fois le DAG formé, il utilisera d’abord le modèle de quorum Nœud Majoritaire. Une fois la deuxième boîte aux lettres ajoutée au DAG, le quorum est automatiquement changé en un modèle de quorum de nœuds et partage de fichiers majoritaire. Lors de ce changement, le DAG commence à utiliser le serveur témoin pour conserver un quorum. Si le répertoire témoin n’existe pas, Exchange le créera automatiquement, le partagera et lui fournira les autorisations de contrôle total pour le compte d’ordinateur d’objet réseau de cluster pour le DAG.

RemarqueRemarque :
L’utilisation d’un partage de fichiers qui est intégré à l’espace de noms Distributed File System (DFS) n’est pas prise en charge.

Si le pare-feu Windows est activé sur le serveur témoin avant la création du DAG, celle-ci risque d’être bloquée. Exchange utilise Windows WMI (Windows Management Instrumentation) pour créer le répertoire et le partage de fichiers sur le serveur témoin. Si le pare-feu Windows est activé sur le serveur témoin et qu’aucune exception de pare-feu n’est configurée pour WMI, la cmdlet New-DatabaseAvailabilityGroup va échouer en indiquant une erreur. Si vous spécifiez un serveur témoin mais pas de répertoire témoin, vous obtiendrez le message d’erreur suivante.

La tâche n’a pas réussi à créer le répertoire témoin par défaut sur le serveur <Nom de serveur>. Indiquez manuellement un répertoire témoin.

Si vous spécifiez un serveur témoin mais pas de répertoire témoin, vous obtiendrez le message d’avertissement suivant.

Impossible d’accéder aux partages de fichiers sur le serveur témoin ’NomServeur’. Le groupe de disponibilité de base de données risque d’être plus vulnérable aux échecs tant que ce problème n’aura pas été résolu. Vous pouvez utiliser la cmdlet Set-DatabaseAvailabilityGroup pour retenter l’opération. Erreur : Le chemin réseau n’a pas été trouvé.

Si le pare-feu Windows est activé sur le serveur témoin après création du DAG mais avant l’ajout des serveurs, l’ajout ou le retrait des membres du DAG risque d’être bloqué. Si le pare-feu Windows est activé sur le serveur témoin et qu’aucune exception de pare-feu n’est configurée pour WMI, la cmdlet Add-DatabaseAvailabilityGroupServer va échouer en indiquant une erreur.

Impossible de créer le répertoire témoin de partage de fichiers ’C:\DAGFileShareWitnesses\DAG_FQDN’ sur le serveur témoin ’NomServeur’. Le groupe de disponibilité de base de données risque d’être plus vulnérable aux échecs tant que ce problème n’aura pas été résolu. Vous pouvez utiliser la cmdlet Set-DatabaseAvailabilityGroup pour retenter l’opération. Erreur : Une exception WMI s’est produite sur le serveur ’NomServeur’ : Le serveur RPC n’est pas disponible. (Exception de HRESULT : 0x800706BA)

Pour corriger cette erreur et les avertissements, effectuez une des opérations suivantes :

  • Créez manuellement le répertoire témoin et effectuez le partage sur le serveur témoin. Puis attribuez l’objet réseau de cluster (CNO) pour le contrôle total du groupe de disponibilité de base de données pour le répertoire et le partage.

  • Activez l’exception WMI dans le pare-feu Windows.

  • Désactivez le pare-feu Windows.

Retour au début

Appartenance au groupe de disponibilité de base de données

Une fois le DAG créé, vous pouvez ajouter des serveurs à celui-ci ou en supprimer à l’aide de l’Assistant Gestion de groupe de disponibilité de base de données dans la console de gestion Exchange ou à l’aide des cmdlets Add-DatabaseAvailabilityGroupServer ou Remove-DatabaseAvailabilityGroupServer dans l’environnement de ligne de commande Exchange Management Shell. Pour obtenir la procédure détaillée de gestion de l’appartenance aux DAG, voir Gérer l’appartenance au groupe de disponibilité de la base de données.

RemarqueRemarque :
Chaque serveur de boîtes aux lettres membre d’un groupe de disponibilité de la base de données constitue également un nœud dans le cluster sous-jacent, utilisé par le groupe de disponibilité de la base de données. Par conséquent, un serveur de boîtes aux lettres peut être membre d’un seul groupe de disponibilité de la base de données.

Si le serveur de boîte aux lettres ajouté au DAG n’a pas le composant de clustering avec basculement, la méthode utilisée pour ajouter le serveur (par exemple, la cmdlet Add-DatabaseAvailabilityGroupServer ou l’Assistant de gestion du groupe de disponibilité de base de données) installera la fonction de clustering avec basculement.

Voici ce qui se passe quand le premier serveur de boîte aux lettres est ajouté à un DAG :

  • Le composant de clustering avec basculement Windows est installé, s’il ne l’est pas déjà.

  • Un cluster de basculement est créé avec le nom du DAG. Ce cluster de basculement est utilisé uniquement par le groupe de disponibilité de base de données (DAG) et ce cluster doit être dédié au DAG. L’utilisation du cluster à d’autres fins n’est pas prise en charge.

  • Un objet réseau de cluster (CNO) est créé dans le conteneur des ordinateurs par défaut.

  • Le nom et l’adresse IP du DAG figurent comme enregistrement d’hôte (A) dans DNS (Domain Name System).

  • Le serveur est ajouté à l’objet DAG dans Active Directory.

  • La base de données du cluster est mise à jour avec les informations sur les bases de données montées sur le serveur ajouté.

Dans les grands environnements ou à sites multiples, ceux dans lesquels le DAG est étendu à plusieurs sites Active Directory, vous devez attendre la réplication Active Directory de l’objet DAG contenant le premier membre DAG à traiter. Si cet objet Active Directory n’est pas répliqué dans tout l’environnement, l’ajout du second serveur risque de provoquer la création d’un nouveau cluster (ainsi qu’un nouvel objet réseau de cluster) pour le DAG. Cela est dû au fait que l’objet DAG apparaît vide dans la perspective du second membre ajouté, ce qui provoquera par conséquent la création d’un cluster et d’un objet réseau de cluster pour le DAG par le biais de la cmdlet Add-DatabaseAvailabilityGroupServer, même si ces objets existent déjà. Pour vérifier que l’objet DAG contenant le premier serveur DAG a été répliqué, utilisez la cmdlet Get-DatabaseAvailabilityGroup sur le second serveur en cours d’ajout et vérifiez que le premier serveur ajouté est répertorié en tant que membre DAG.

Voici ce qui se passe quand les serveurs suivants sont ajoutés au DAG :

  • Le serveur est joint au cluster de basculement Windows pour le DAG.

  • Le modèle de quorum est automatiquement réglé :

    • Un modèle de quorum Nœud majoritaire est utilisé pour les DAGs ayant un nombre impair de membres.

    • Un modèle de quorum Nœud et partage de fichiers majoritaire est utilisé pour les DAGs ayant un nombre de membres pair.

  • Le répertoire témoin et le partage témoin sont automatiquement créés par Exchange si nécessaire.

  • Le serveur est ajouté à l’objet DAG dans Active Directory.

  • La base de données du cluster est mise à jour avec les informations sur les bases de données montées.

RemarqueRemarque :
Le changement de modèle de quorum doit se produire automatiquement. Toutefois, si le modèle de quorum n’est pas changé automatiquement vers le modèle approprié, vous pouvez exécuter la cmdlet Set-DatabaseAvailabilityGroup avec seulement le paramètre Identity pour modifier les réglages de quorum du DAG.

Préconfiguration de l’objet nom de cluster pour un groupe de disponibilité de base de données

L’objet réseau de cluster (CNO) est un compte d’ordinateur qui est créé dans Active Directory et associé à la ressource Nom du cluster. La ressource Nom du cluster est liée à l’objet réseau de cluster représentant un objet Kerberos qui agit comme identité du cluster et fournit le contexte de sécurité du cluster. Dans Exchange 2007, ce compte d’ordinateur Kerberos a été créé dans le domaine en utilisant le contexte de sécurité de l’utilisateur effectuant les tâches. Cette opération nécessitait que le compte d’utilisateur dispose d’autorisations permettant de créer et d’activer les comptes d’ordinateur dans le domaine ou que le compte d’ordinateur soit correctement préconfiguré et approvisionné.

Comme indiqué précédemment, la formation du cluster sous-jacent DAG et de l’objet réseau de cluster pour ce cluster est effectuée lorsque le premier membre est ajouté au DAG. Lorsque le premier serveur est ajouté au DAG, Powershell contacte le service de réplication Microsoft Exchange sur le serveur de boîtes aux lettres ajouté. Le service de réplication Microsoft Exchange installe la fonctionnalité de cluster de basculement (si celle-ci n’est pas déjà installée) et commence le processus de création du cluster. Le service de réplication Microsoft Exchange s’exécute dans le contexte de sécurité du système local et c’est dans ce contexte que la création du cluster est effectuée.

AvertissementAvertissement :
Si les membres de votre groupe de disponibilité de base de données (DAG) exécutent Windows Server 2012, vous devez préconfigurer l’objet réseau de cluster (CNO) avant d’ajouter le premier serveur au groupe de disponibilité de base de données (DAG).

Dans des environnements où la création de compte d’ordinateur est restreinte ou lorsque des comptes d’ordinateur sont créés dans un conteneur autre que le conteneur d’ordinateurs par défaut, vous pouvez préconfigurer et approvisionner l’objet réseau de cluster. Vous pouvez créer et désactiver un compte d’ordinateur pour l’objet réseau de cluster, puis vous pouvez :

  • attribuer le contrôle total du compte d’ordinateur au compte d’ordinateur du premier serveur de boîte aux lettres ajoutée au groupe de disponibilité de base de données.

  • attribuer le contrôle total du compte d’ordinateur au groupe de sécurité universel du sous-système approuvé Exchange.

L’attribution du contrôle total du compte d’ordinateur au compte d’ordinateur du premier serveur de boîte aux lettres que vous ajoutez au DAG garantit que le contexte de sécurité du système local pourra gérer le compte d’ordinateur préconfiguré. L’attribution du contrôle total du compte d’ordinateur au groupe de sécurité universel du sous-système approuvé Exchange peut être utilisée à la place car le groupe de sécurité universel du sous-système approuvé Exchange contient les comptes d’ordinateur de tous les serveurs Exchange du domaine.

Pour obtenir la procédure détaillée pour préconfigurer et approvisionner l’objet réseau de cluster pour un DAG, consultez la rubrique Préconfigurer l'objet nom de cluster pour un groupe de disponibilité de base de données.

Suppression des serveurs d’un groupe de disponibilité de base de données

Les serveurs de boîtes aux lettres peuvent être supprimés d’un DAG à l’aide de l’Assistant Gestion des groupes de disponibilité de base de données dans la console de gestion Exchange ou à l’aide de la cmdlet Remove-DatabaseAvailabilityGroupServer dans l’environnement de ligne de commande Exchange Management Shell. Toutes les bases de données de boîtes aux lettres répliquées doivent être retirées du serveur avant de pouvoir supprimer un serveur de boîte aux lettres d’un DAG. Si vous essayez de supprimer un serveur de boîte aux lettres comprenant des bases de données de boîtes aux lettres répliquées, la tâche échouera.

Dans le cadre de certaines procédures, il faut supprimer un serveur de boîte aux lettres d’un DAG avant d’effectuer certaines opérations. Ces différents cas de figure sont présentés ci-dessous :

  • Opération de récupération d’un serveur   Si un serveur de boîtes aux lettres membre d’un groupe de disponibilité de base de données est perdu ou tombe en panne et s’avère irrécupérable et nécessite d’être remplacé, vous pouvez effectuer une opération de récupération de serveur à l’aide du commutateur Setup /m:RecoverServer. Toutefois, avant de pouvoir effectuer cette opération, il vous faut d’abord supprimer le serveur du DAG à l’aide de la cmdlet Remove-DatabaseAvailabilityGroupServer avec le paramètre ConfigurationOnly.

  • Suppression de la disponibilité de base de données   Dans certains cas, vous aurez peut-être besoin de supprimer un DAG (par exemple, si vous désactivez le mode de réplication tierce). Si vous avez besoin de supprimer un DAG, il vous faut d’abord en effacer tous les serveurs. Si vous essayez de supprimer un DAG qui comprend un ou plusieurs membres, la tâche échouera.

Retour au début

Configuration des propriétés du groupe de disponibilité de base de données

Une fois les serveurs ajoutés au DAG, vous pouvez utiliser la console de gestion Exchange ou l’environnement de ligne de commande Exchange Management Shell pour configurer les propriétés d’un groupe de disponibilité de base de données, y compris le serveur et le répertoire témoins utilisés par le DAG et les adresses IP affectées à celui-ci.

Les propriétés configurables sont les suivantes :

  • Serveur témoin   Nom du serveur que vous avez choisi pour héberger le partage de fichiers pour le témoin de partage de fichiers. Nous vous recommandons de spécifier un serveur de transport Hub hors du DAG en tant que serveur témoin. Cela permet au système de configurer, sécuriser et utiliser automatiquement le partage, selon les besoins.

  • Répertoire témoin   Nom du répertoire qui sera utilisé pour stocker les données du témoin de partage de fichiers. Ce répertoire sera automatiquement créé par le système sur le serveur témoin spécifié.

  • Adresses IP du groupe de disponibilité de base de données   Une ou plusieurs adresses IP peuvent être affectées au DAG. Ces adresses peuvent être configurées à l’aide d’adresses IP statiques affectées manuellement, ou être automatiquement affectées au DAG à l’aide d’un serveur DHCP de votre organisation.

L’environnement de ligne de commande Exchange Management Shell permet de gérer les propriétés du DAG qui ne sont pas accessibles depuis la console de gestion Exchange telles que les adresses IP du DAG, le chiffrement de réseau et les paramètres de compression, la découverte du réseau, le port TCP utilisé pour la réplication, les autres paramètres de serveur et répertoire témoins, et pour activer le mode de coordination de l’activation du centre de données.

Pour obtenir la procédure détaillée sur la configuration des propriétés DAG, voir Configurer les propriétés du groupe de disponibilité de la base de données.

Chiffrement du réseau DAG

Les DAG prennent en charge l’utilisation du chiffrement en tirant parti des capacités de chiffrement du système d’exploitation Windows Server. Les DAG utilisent l’authentification Kerberos entre les serveurs Exchange. Les API EncryptMessage et DecryptMessage du SSP (Security Support Provider) de Microsoft Kerberos gèrent le chiffrement du trafic réseau DAG. Le SSP de Microsoft Kerberos prend en charge plusieurs algorithmes de chiffrement. (Pour obtenir la liste complète, consultez la section 3.1.5.2, « Types de chiffrement » des extensions de protocole Kerberos). Le protocole de liaison d’authentification Kerberos choisit les meilleurs protocoles de chiffrement pris en charge dans la liste : généralement l’algorithme d’encodage AES (Advanced Encryption Standard) 256 bits, potentiellement avec HMAC (Hash-based Message Authentication Code) SHA pour conserver l’intégrité des données. Pour plus d’informations, voir HMAC.

Le chiffrement de réseau est une propriété du DAG, et non un réseau DAG. Vous pouvez configurer le chiffrement du réseau DAG à l’aide de la cmdlet Set-DatabaseAvailabilityGroup dans l’environnement de ligne de commande Exchange Management Shell. Les paramètres de chiffrement possibles pour les communications d’un réseau DAG figurent dans le tableau suivant.

Paramètres de chiffrement des communications d’un réseau DAG

Paramètre Description

Désactivé

Le chiffrement réseau n’est pas utilisé.

activé

Le chiffrement de réseau est utilisé sur tous les réseaux DAG pour la réplication et l’amorçage.

InterSubnetOnly

Le chiffrement de réseau est utilisé sur les réseaux DAG lors de la réplication entre différents sous-réseaux. Il s’agit du paramètre par défaut.

SeedOnly

Le chiffrement de réseau est utilisé sur tous les réseaux DAG pour l’amorçage uniquement.

Compression d’un réseau DAG

Les DAG prennent également en charge la compression intégrée. Lorsque la compression est activée, la communication de réseau DAG utilise XPRESS, l’implémentation Microsoft de l’algorithme LZ77. Pour plus d’informations, consultez la page de présentation de l’algorithme de décompression et la section 3.1.7.2 relative à l’algorithme de compression dans la rubrique concernant la spécification du protocole au format câblé. Ce type de compression est le même que celui qui est utilisé dans de nombreux protocoles Microsoft, en particulier le protocole MAPI RPC utilisé pour la compression entre Microsoft Outlook et Exchange.

Comme le chiffrement de réseau, la compression réseau est aussi une propriété du DAG, et non un réseau DAG. La configuration de la compression réseau DAG se fait à l’aide de la cmdlet Set-DatabaseAvailabilityGroup dans l’environnement de ligne de commande Exchange Management Shell. Les paramètres de compression possibles pour les communications d’un réseau DAG figurent dans le tableau suivant.

Paramètres de compression de communication de réseau DAG

Paramètre Description

Désactivé

La compression réseau n’est pas utilisée.

Activé

La compression réseau est utilisée sur tous les réseaux DAG pour la réplication et l’amorçage.

InterSubnetOnly

La compression réseau est utilisée sur les réseaux DAG lors de la réplication entre différents sous-réseaux. Il s’agit du paramètre par défaut.

SeedOnly

La compression réseau est utilisée sur tous les réseaux DAG pour l’amorçage uniquement.

Retour au début

Réseaux DAG

Un réseau DAG regroupe un ou plusieurs sous-réseaux utilisés soit pour le trafic de réplication soit pour le trafic MAPI. Chaque DAG contient au maximum un réseau MAPI et aucun ou plusieurs réseaux de réplication. Dans une configuration de carte réseau unique, le réseau est utilisé pour le trafic de réplication et MAPI. Bien qu’une seule carte et un seul chemin réseau soient pris en charge, nous recommandons un minimum de deux réseaux DAG par DAG. Dans une configuration à deux réseaux, l’un est généralement consacré au trafic de réplication et le second est utilisé avant tout pour le trafic MAPI. Vous pouvez également ajouter des cartes réseau à chaque membre DAG et configurer des réseaux DAG supplémentaires en tant que réseaux de réplication.

RemarqueRemarque :
En cas d’utilisation de plusieurs réseaux de réplication, il n’y a aucun moyen de spécifier un ordre de priorité pour l’utilisation des réseaux. Exchange sélectionne de manière aléatoire un réseau de réplication dans le groupe de réseaux de réplication à utiliser pour la copie des journaux de transaction.

Vous pouvez utiliser l’Assistant Nouveau réseau de groupe de disponibilité de base de données de la console de gestion Exchange ou la cmdlet New-DatabaseAvailabilityGroupNetwork dans l’environnement de ligne de commande Exchange Management Shell pour créer un réseau DAG. Pour obtenir la procédure détaillée de création d’un réseau DAG, voir Créer un réseau de groupe de disponibilité de la base de données.

Pour configurer les propriétés du réseau DAG, vous pouvez utiliser la boîte de dialogue Propriétés dans la console de gestion Exchange du réseau DAG ou la cmdlet Set-DatabaseAvailabilityGroupNetwork dans l’environnement de ligne de commande Exchange Management Shell. Pour obtenir la procédure détaillée sur la configuration des propriétés de réseau DAG, voir Configurer les propriétés du réseau de groupe de disponibilité de la base de données. Chaque réseau DAG a des paramètres obligatoires et facultatifs qu’il faut configurer :

  • Nom du réseau   Un nom unique pour le réseau DAG pouvant contenir jusqu’à 128 caractères.

  • Description du réseau   Description facultative du réseau DAG pouvant contenir jusqu’à 256 caractères.

  • Sous-réseaux de réseau   Un ou plusieurs réseaux entrés à l’aide du format IPAddress/Bitmask (par exemple, 192.168.1.0/24 pour les sous-réseaux IPv4 (Internet Protocol version 4) ; 2001:DB8:0:C000::/64 pour les sous-réseaux IPv6 (Internet Protocol version 6).

  • Activer la réplication   Dans la console de gestion Exchange, cochez la case pour dédier le réseau DAG au trafic de réplication et bloquer le trafic MAPI. Décochez la case pour empêcher la réplication via le réseau de groupe de disponibilité de base de données et pour activer le trafic MAPI. Dans l’environnement de ligne de commande Exchange Management Shell, utilisez le paramètre ReplicationEnabled de la cmdlet Set-DatabaseAvailabilityGroupNetwork pour activer ou désactiver la réplication.

RemarqueRemarque :
La désactivation de la réplication sur votre réseau MAPI ne garantit pas que le système n’utilise pas ce réseau pour la réplication. Si tous les réseaux de réplication configurés sont hors connexion, en panne ou indisponibles pour une autre raison, et que seul reste le réseau MAPI (qui n’est pas activé pour la réplication), alors le système utilise le réseau MAPI pour la réplication.

Les réseaux DAG initiaux (par exemple, DAGNetwork01 et DAGNetwork02) créés par le système reposent sur les sous-réseaux énumérés par le service de cluster. Chaque membre du groupe de disponibilité de base de données doit disposer du même nombre de cartes réseau et chaque carte réseau doit disposer d’une adresse IPv4 (et facultativement d’une adresse IPv6) sur un sous-réseau unique. Plusieurs membres du groupe de disponibilité de base de données peuvent disposer d’adresses IPv4 sur le même sous-réseau mais chaque carte réseau et chaque paire d’adresse IP d’un membre du groupe de disponibilité de base de données spécifique doivent se trouver sur un sous-réseau unique. En outre, uniquement la carte utilisée pour le réseau MAPI devrait être configurée avec une passerelle par défaut. Les réseaux de réplication ne devraient pas être configurés avec une passerelle par défaut.

Par exemple, imaginez DAG1, DAG à deux membres où chaque membre a deux cartes réseau (une dédiée pour le réseau MAPI et l’autre pour le réseau de réplication). Les paramètres de configuration de l’adresse IP sont affichés dans le tableau suivant.

Exemple de paramètres de carte réseau

Carte réseau-serveur Adresse IP/masque de sous-réseau Passerelle par défaut

EX1-MAPI

192.168.1.15/24

192.168.1.1

Réplication EX1

10.0.0.15/24

Non applicable

EX2-MAPI

192.168.1.16

192.168.1.1

Réplication EX2

10.0.0.16

Non applicable

Dans la configuration suivante, il existe deux sous-réseaux configurés dans le groupe de disponibilité de base de données : 192.168.1.0 et 10.0.0.0. Lorsque EX1 et EX2 sont ajoutés au groupe de disponibilité de base de données, deux sous-réseaux seront énumérés et deux réseaux DAG seront créés : DAGNetwork01 (192.168.1.0) et DAGNetwork02 (10.0.0.0). Ces réseaux seront configurés comme indiqué dans le tableau suivant.

Paramètres de réseau DAG énumérés pour un DAG de sous-réseau unique

Nom Sous-réseaux Interfaces Accès MAPI activé Réplication activée

DAGNetwork01

192.168.1.0/24

EX1 (192.168.1.15)

EX2 (192.168.1.16)

True

True

DAGNetwork02

10.0.0.0/24

EX1 (10.0.0.15)

EX2 (10.0.0.16)

False

True

Pour achever la configuration de DAGNetwork02 en tant que réseau de réplication dédié, désactivez la réplication pour DAGNetwork01 en exécutant la commande suivante.

Set-DatabaseAvailabilityGroupNetwork -Identity DAG1\DAGNetwork01 -ReplicationEnabled:$false

Après avoir désactivé la réplication pour DAGNetwork01, le service de réplication Microsoft Exchange utilise DAGNetwork02 pour une réplication continue. Si DAGNetwork02 rencontre une défaillance, le service de réplication Microsoft Exchange bascule vers DAGNetwork01 pour la réplication continue. Cette opération est effectuée intentionnellement par le système pour maintenir une disponibilité élevée.

Réseaux DAG et déploiements de sous-réseaux multiples

Dans l’exemple précédent, même si deux sous-réseaux différents sont en cours d’utilisation par le groupe de disponibilité de base de données (192.168.1.0 et 10.0.0.0), ce groupe est considéré comme DAG de sous-réseau unique car chaque membre utilise le même sous-réseau pour former le réseau MAPI. Lorsque les membres DAG utilisent différents sous-réseaux pour le réseau MAPI, ce DAG est appelé DAG de sous-réseaux multiples. Dans un DAG de sous-réseaux multiples, une configuration supplémentaire de réseaux DAG doit être effectuée pour associer les sous-réseaux appropriés à chaque réseau DAG.

Par exemple, imaginez DAG2, un DAG à deux membres où chaque membre dispose de deux cartes réseau (une dédiée pour le réseau MAPI et l’autre pour le réseau de réplication). En outre, chaque membre DAG se trouve dans un site Active Directory distinct avec son réseau MAPI sur un sous-réseau différent. Les paramètres de configuration de l’adresse IP sont affichés dans le tableau suivant.

Exemple de paramètres de carte réseau pour un DAG de sous-réseaux multiples

Carte réseau-serveur Adresse IP/masque de sous-réseau Passerelle par défaut

EX1-MAPI

192.168.0.15/24

192.168.0.1

EX1-Replication

10.0.0.15/24

Non applicable

EX2-MAPI

192.168.1.15

192.168.1.1

EX2-Replication

10.0.1.15

Non applicable

Dans la configuration suivante, il existe quatre sous-réseaux configurés dans le groupe de disponibilité de base de données : 192.168.0.0, 192.168.1.0, 10.0.0.0 et 10.0.1.0. En cas d’ajout de EX1 et EX2 au groupe de disponibilité de base de données, quatre sous-réseaux seront énumérés et deux réseaux DAG seront créés : DAGNetwork01 (192.168.0.0), DAGNetwork02 (10.0.0.0), DAGNetwork03 (192.168.1.0) et DAGNetwork04 (10.0.1.0). Ces réseaux seront configurés comme indiqué dans le tableau suivant.

Paramètres de réseau DAG énumérés pour un DAG de sous-réseaux multiples

Nom Sous-réseaux Interfaces Accès MAPI activé Réplication activée

DAGNetwork01

192.168.0.0/24

EX1 (192.168.0.15)

True

True

DAGNetwork02

10.0.0.0/24

EX1 (10.0.0.15)

False

True

DAGNetwork03

192.168.1.0/24

EX2 (192.168.1.15)

True

True

DAGNetwork04

10.0.1.0/24

EX2 (10.0.1.15)

False

True

Pour effectuer la configuration nécessaire, DAGNetwork03 et DAGNetwork04 doivent être intégrés respectivement à DAGNetwork01 et DAGNetwork02. Cela implique l’ajout à DAGNetwork01 du sous-réseau actuellement associé à DAGNetwork03 ainsi que l’ajout à DAGNetwork02 du sous-réseau actuellement associé à DAGNetwork04. Cela supprime les associations de sous-réseaux de DAGNetwork03 et DAGNetwork04, en les laissant comme réseaux DAG vides pouvant être ensuite supprimés. Pour intégrer les sous-réseaux dans deux réseaux DAG et désactiver la réplication sur le réseau MAPI, exécutez les commandes suivantes.

Set-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork01 -Subnets 192.168.0.0,192.168.1.0 -ReplicationEnabled:$false
Set-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork02 -Subnets 10.0.0.0,10.0.1.0
Remove-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork03
Remove-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork04

Réseaux DAG et réseaux iSCSI

Par défaut, les DAG effectuent une recherche de tous les réseaux détectés et configurés pour utilisation par le cluster sous-jacent. Cela inclut tout réseau iSCSI (Internet SCSI) en cours d’utilisation du fait de l’utilisation du stockage iSCSI pour un ou plusieurs membres du DAG. Il est recommandé que le stockage iSCSI utilise des réseaux dédiés et des cartes réseau. Ces réseaux ne devraient pas être gérés ni par le DAG ni par son cluster ni utilisés comme réseaux de DAG (MAPI ou réplication). Leur utilisation par le DAG devrait au contraire être désactivée manuellement, de manière à ce qu’ils soient dédiés au trafic du stockage iSCSI. Pour que les réseaux iSCSI ne soient plus détectés et utilisés comme réseaux DAG, configurez le DAG pour qu’il ignore tous les réseaux iSCSI détectés à l’aide de la cmdlet Set-DatabaseAvailabilityGroupNetwork, comme indiqué dans cet exemple :

Set-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork02 -ReplicationEnabled:$false -IgnoreNetwork:$true

Cette commande désactive également le réseau pour une utilisation par le cluster. Même si les réseaux iSCSI continuent à apparaître en tant que réseaux DAG, ils ne seront pas utilisés pour MAPI ou le trafic de réplication une fois la commande ci-dessus exécutée.

Retour au début

Configuration des membres du groupe de disponibilité de base de données

Les serveurs de boîtes aux lettres qui sont membres d’un DAG ont certaines propriétés spécifiques de haute disponibilité qui doivent être configurées comme indiqué dans les sections suivantes :

  • Numérotation de montage automatique de base de données

  • Stratégie d’activation automatique de copie de base de données

  • Nombre maximal de bases de données actives

Numérotation de montage automatique de base de données

Le paramètre AutoDatabaseMountDial spécifie le comportement du montage automatique de base de données après basculement d’une base de données. Vous pouvez utiliser la cmdlet Set-MailboxServer pour configurer le paramètre AutoDatabaseMountDial avec l’une des valeurs suivantes :

  • BestAvailability   Si vous spécifiez cette valeur, la base de données monte automatiquement immédiatement après un basculement si la longueur de file d’attente de copie est inférieure ou égale à 12. La longueur de la file d’attente de copie correspond au nombre de journaux reconnu par la copie passive devant être répliquée. Si la longueur de la file d’attente de copie est supérieure à 12, la base de données n’est pas montée automatiquement. Si la longueur de la file d’attente de copie est inférieure ou égale à 12, Exchange tente de répliquer les journaux restants sur la copie passive et monte la base de données.

  • GoodAvailability   Si vous spécifiez cette valeur, la base de données est montée immédiatement après un basculement si la longueur de la file d’attente de copie est inférieure ou égale à six. La longueur de la file d’attente de copie correspond au nombre de journaux à répliquer reconnus par la copie passive. Si la longueur de la file d’attente de copie est supérieure à six, la base de données n’est pas montée automatiquement. Si la longueur de la file d’attente de copie est inférieure ou égale à six, Exchange tente de répliquer les journaux restants sur la copie passive et monte la base de données.

  • Lossless   Si vous spécifiez cette valeur, la base de données n’est pas montée automatiquement tant que tous les journaux générés sur la copie active n’ont pas été copiés sur la copie passive. Ce paramètre permet également à l’algorithme de sélection de la meilleure copie par le Gestionnaire Active Manager de trier les candidats éventuels pour l’activation en fonction de la valeur de préférence d’activation de la copie de la base de données et non sur sa longueur de file d’attente.

La valeur par défaut est GoodAvailability. Si vous spécifiez BestAvailability ou GoodAvailability, et si les données sur la copie active ne peuvent pas toutes être répliquées sur la copie passive, vous risquez de perdre des données de boîte aux lettres. Toutefois, la fonctionnalité de benne de transport (activée par défaut) forme une protection contre la perte de la plupart des données en renvoyant les messages qui se trouvent dans la file d’attente de la benne de transport.

En plus des valeurs précédentes, vous pouvez également configurer le paramètre AutoDatabaseMountDial avec une valeur personnalisée en utilisant ADSI Edit ou Ldp.exe pour modifier l’attribut directement dans Active Directory. Le paramètre AutoDatabaseMountDial est représenté par l’attribut msExchDataLossForAutoDatabaseMount de l’objet serveur de boîtes aux lettres. La valeur numérique du nombre entier pour cet attribut représente le nombre maximal de fichiers des journaux de transactions que vous êtes prêt à perdre pour monter une base de données sans intervention humaine. Si vous configurez le paramètre AutoDatabaseMountDial avec une valeur personnalisée supérieure à 12, nous vous recommandons d’augmenter également la taille de la benne de transport pour activer la protection améliorée contre un nombre supérieur de journaux perdus.

Exemple : Configuration de la numérotation de montage automatique de base de données

L’exemple suivant configure un serveur de boîtes aux lettres avec un paramètre AutoDatabaseMountDial de GoodAvailability.

Set-MailboxServer -Identity EX1 -AutoDatabaseMountDial GoodAvailability

Stratégie d’activation automatique de copie de base de données

Le paramètre DatabaseCopyAutoActivationPolicy spécifie le type d’activation automatique disponible pour les copies de base de données de boîtes aux lettres sur les serveurs de boîtes aux lettres sélectionnés. Vous pouvez utiliser la cmdlet Set-MailboxServer pour configurer le paramètre avec l’une des valeurs suivantes DatabaseCopyAutoActivationPolicy :

  • Blocked   Si vous spécifiez cette valeur, les bases de données ne peuvent pas être automatiquement activées sur les serveurs de boîtes aux lettres sélectionnées.

  • IntrasiteOnly   Si vous spécifiez cette valeur, la copie de la base de données est autorisée sur les serveurs appartenant au même site Active Directory. Cela empêche le basculement intersite ou l’activation. Cette propriété s’applique aux copies des bases de données des boîtes de réception (par exemple, une copie passive devenant une copie active). Il est impossible d’activer des bases de données sur ce serveur de boîtes aux lettres pour des copies de bases de données qui sont actives dans un autre site Active Directory.

  • Unrestricted   Si vous spécifiez cette valeur, il n’existe aucune restriction spéciale pour l’activation de copies de bases de données de boîtes aux lettres sur les serveurs de boîtes aux lettres sélectionnés.

Exemple : Configuration de la stratégie d’activation automatique de copie de base de données

L’exemple suivant configure un serveur de boîtes aux lettres avec un paramètre DatabaseCopyAutoActivationPolicy de Blocked.

Set-MailboxServer -Identity EX1 -DatabaseCopyAutoActivationPolicy Blocked

Nombre maximal de bases de données actives

Le paramètre MaximumActiveDatabases (également utilisé avec la cmdlet Set-MailboxServer) spécifie le nombre de bases de données qui peuvent être montées sur un serveur de boîtes aux lettres. Vous pouvez configurer des serveurs de boîtes aux lettres pour qu’ils correspondent aux exigences de déploiement en vous assurant qu’un serveur de boîtes aux lettres individuel ne devient pas surchargé.

Le paramètre MaximumActiveDatabases est configuré avec une valeur numérique de nombre entier. Lorsque le nombre maximal est atteint, les copies de la base de données sur le serveur ne sont pas activées si un basculement se produit. Si les copies sont déjà actives sur un serveur, le montage des bases de données ne sera pas autorisé par le serveur.

Exemple : Configuration du nombre maximal de bases de données actives

L’exemple suivant configure un serveur de boîtes aux lettres pour prendre en charge un nombre maximal de 20 bases de données actives.

Set-MailboxServer -Identity EX1 -MaximumActiveDatabases 20

Retour au début

Exécution de la maintenance sur les membres du groupe de disponibilité de base de données

Avant d’effectuer tout type de maintenance logicielle ou matérielle pour un membre du groupe de disponibilité de base de données, vous devez d’abord supprimer celui-ci du service en utilisant le script StartDagServerMaintenance.ps1. Ce script déplace toutes les bases de données actives hors du serveur et empêche le transfert des bases de données actives vers ce dernier. Le script garantit également que la fonctionnalité de prise en charge du DAG qui peut se trouver sur le serveur (par exemple, le rôle PAM (Primary Active Manager)) est transférée sur un autre serveur et qu’elle est bloquée pour qu’elle ne puisse pas revenir sur le serveur précédent. Plus spécifiquement, le script StartDagServerMaintenance.ps1 effectue les tâches suivantes :

  • Il exécute Suspend-MailboxDatabaseCopy avec le paramètre ActivationOnly pour suspendre chaque copie de base de données qui est hébergée sur le membre DAG pour activation.

  • Il interrompt le nœud dans le cluster, ce qui l’empêche de devenir le gestionnaire PAM (Primary Active Manager).

  • Il définit la valeur du paramètre DatabaseCopyAutoActivationPolicy pour le membre DAG sur Blocked.

  • Il transfère toutes les bases de données actives actuellement hébergées sur le membre DAG vers d’autres membres DAG.

  • Si le membre DAG contient actuellement le groupe de cluster par défaut, le script transfère le groupe de cluster par défaut (et par conséquent le rôle PAM) vers un autre membre DAG.

Si l’une des tâches précédentes échoue, toutes les opérations, sauf les transferts de base de données réussis, sont annulées.

Une fois la maintenance terminée et le membre DAG prêt à fonctionner de nouveau, vous pouvez utiliser le script StopDagServerMaintenance.ps1 pour enlever le membre DAG du mode de maintenance et le remettre en production. Plus spécifiquement, le script StopDagServerMaintenance.ps1 effectue les tâches suivantes :

  • Il exécute la cmdlet Resume-MailboxDatabaseCopy pour chaque copie de base de données hébergée sur le membre DAG.

  • Il reprend le nœud dans le cluster, ce qui active toute la fonctionnalité du cluster pour le membre DAG.

  • Il définit la valeur du paramètre DatabaseCopyAutoActivationPolicy pour le membre DAG sur Unrestricted.

Les deux scripts acceptent le paramètre -ServerName (qui peut être le nom d’hôte ou le nom de domaine complet (FQDN) du membre DAG) et le paramètre -WhatIf. Les deux scripts peuvent être exécutés localement ou à distance. Le serveur sur lequel les scripts sont exécutés doit disposer des outils de gestion du cluster de basculement Windows installés (RSAT-Clustering).

Retour au début

Arrêt des membres DAG

La solution de haute disponibilité Exchange 2010 est intégrée au processus d’arrêt de Windows. Si un administrateur ou une application arrête un serveur Windows dans le DAG qui a une base de données montée répliquée sur un ou plusieurs membres du DAG, le système tentera d’activer une autre copie de la base de données montée avant de terminer le processus d’arrêt.

Toutefois, ce nouveau comportement ne garantit pas que toutes les bases de données sur le serveur en cours de fermeture vont bénéficier d’une activation lossless. C’est pourquoi il est préférable d’effectuer un basculement de serveur avant d’arrêter un serveur membre d’un DAG. Pour connaître la procédure détaillée d’exécution d’une permutation de serveur, consultez la rubrique Effectuer un basculement de serveur.

Retour au début

Installation des correctifs cumulatifs sur les membres DAG

L’installation de correctifs cumulatifs Microsoft Exchange Server 2010 sur un serveur membre d’un groupe de disponibilité de base de données (DAG) est un processus relativement simple. Plusieurs services sont arrêtés lorsque vous installez un correctif cumulatif sur un serveur membre d’un DAG, notamment tous les services Exchange et le service de cluster. La procédure générale d’application de correctifs cumulatifs à un membre DAG est la suivante :

  1. Utilisez le script StartDagServerMaintenance.ps1 pour mettre le membre DAG en mode maintenance.

  2. Installez le correctif cumulatif.

  3. Utilisez le script StopDagServerMaintenance.ps1 pour enlever le membre DAG du mode maintenance et le remettre en production.

  4. Utilisez le script RedistributeActiveDatabases.ps1 pour rééquilibrer les copies de base de données actives dans le DAG.

Vous pouvez télécharger le dernier cumulatif correctif pour Exchange 2010 à partir du Centre de téléchargement Microsoft. Pour obtenir la procédure détaillée d’installation d’un correctif cumulatif sur un membre DAG, consultez la rubrique Installation de correctifs cumulatifs sur les membres du groupe de disponibilité de base de données.

Retour au début

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