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

S'applique à : Exchange Server 2010

Dernière rubrique modifiée : 2010-01-25

Un groupe de disponibilité de base de données 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 utilisent la réplication continue et un sous-ensemble de technologies de clustering avec basculement Windows pour assurer une disponibilité continue des boîtes aux lettres. 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 le 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 aux groupes de disponibilité de base de données

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

Réseaux du groupe de disponibilité de base de données

Arrêt des membres du groupe de disponibilité de base de données

Installation des correctifs cumulatifs aux membres du groupe de disponibilité de base de données

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 DatabaseAvailablityGroupIpAddresses. Si vous omettez ce paramètre, le DAG tentera d’utiliser un serveur DHCP (Dynamic Host Configuration Protocol) de votre réseau pour obtenir une adresse IP.

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 cluster de basculement Windows, telles que la pulsation de cluster, les réseaux de cluster et les bases de données de cluster (pour le stockage des données qui changent ou peuvent changer rapidement, telles que les changements d’état de la base de données d’actif à passif ou inversement, ou de monté à démonté ou inversement). Comme les DAG dépendent du cluster de basculement Windows, ils ne peuvent être créés que sur les serveurs de boîtes aux lettres Exchange 2010 qui exécutent le système d’exploitation Windows Server 2008 Enterprise ou Windows Server 2008 R2 Enterprise.

Serveur et répertoire témoins du Groupe de disponibilité de base de données

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 DAG. Il n’est pas nécessaire de créer le répertoire témoin à l’avance. Exchange créera et sécurisera 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 du 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 le système Windows Server 2008 R2, Windows Server 2008, Windows Server 2003 R2 ou Windows Server 2003.
• Un serveur unique peut servir de témoin pour plusieurs groupes de disponibilité de base de données. Toutefois, chaque DAG requiert 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.

Important :
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 DAG. Ces autorisations de sécurité sont nécessaires pour garantir qu’Exchange peut créer un répertoire et un partage sur le serveur témoin si nécessaire.

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épertorie témoin (si vous avez un quorum).

Remarque :
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 primaire.

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 ne sera 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. Si vous spécifiez un serveur témoin, il est recommandé 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îtes 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.

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 la classe 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 la classe 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 l’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 l’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 la classe WMI, la cmdlet Add-DatabaseAvailabilityGroupServer va afficher l’avertissement suivant :

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éer au préalable le répertoire de rappel et le partager sur le serveur témoin
• Activer l’exception de WMI dans le pare-feu Windows
• Désactiver le pare-feu Windows

Retour au début

Appartenance aux groupes de disponibilité de base de données

Une fois le DAG créé, vous pouvez ajouter des serveurs au DAG 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-DatabaseAvailbilityGroupServer ou Remove-DatabaseAvailbilityGroupServer 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.

Remarque :
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.
• Un objet réseau de cluster 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.
• 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 membre du 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.

Remarque :
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 réseau de cluster pour un groupe de disponibilité de base de données

L’objet réseau de cluster 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 le compte d’utilisateur pour obtenir les 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îte 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.

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 de la première 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 de la première 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 ce groupe 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, voir Préparer l'objet de réseau de cluster pour un groupe de disponibilité de base de données.

Suppression de 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-DatabaseAvailbilityGroupServer 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 la 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.

Les commandes Exchange Management Shell permettent 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 de groupe de disponibilité de la base de données, voir Configurer les propriétés du groupe de disponibilité de la base de données.

Chiffrement du réseau de groupe de disponibilité de base de données

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 une authentification Kerberos entre les serveurs Exchange. Les API EncryptMessage/DecryptMessage du fournisseur de prise en charge de la sécurité (SSP) 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 chiffrements » 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.

Remarque :
Les informations relatives à des sites Web tiers dans cette rubrique sont indiquées pour vous fournir les informations techniques dont vous avez besoin. Les URL peuvent faire l'objet de modifications sans préavis.

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.
SeedOnly	Le chiffrement de réseau est utilisé sur tous les réseaux DAG pour l’amorçage uniquement.

Compression de réseau de groupe de disponibilité de base de données

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, voir LZ77 algorithm et la section 3.1.7.2, « Algorithme de compression » dans la rubrique 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.

Remarque :
Les informations relatives à des sites Web tiers dans cette rubrique sont indiquées pour vous fournir les informations techniques dont vous avez besoin. Les URL peuvent faire l'objet de modifications sans préavis.

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.
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 du groupe de disponibilité de base de données

Bien qu’un seul adaptateur et chemin réseau soit pris en charge, nous recommandons un minimum de deux réseaux DAG par 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. 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 créer des réseaux supplémentaires dans un groupe de disponibilité de base de données et les configurer comme réseaux de réplication pour la redondance.

Remarque :
Lorsque plusieurs réseaux de réplication sont utilisés, il n’est pas possible de spécifier un ordre de priorité pour l’utilisation de ceux-ci. Exchange choisira au hasard un réseau de réplication dans le groupe de réseaux de réplication à utiliser pour l’envoi de journaux.

Vous pouvez utiliser l’Assistant Nouveau 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 ; 2001:DB8:0:C000::/64 pour les sous-réseaux IPv6).
• 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.

Remarque :

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 un réseau MAPI qui n’est pas activé pour la réplication, alors le système utilisera ce réseau pour la réplication jusqu’à ce qu’un réseau activé pour la réplication se connecte et devienne disponible.

Réseaux de DAG et réseaux iSCSI

Par défaut, les DAG effectueront une récupération de tous les réseaux détectés et configurés pour l’utilisation par leur 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 interface 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. Il y a deux opérations à effectuer pour désactiver la détection et l’utilisation des réseaux iSCSI comme réseaux de DAG :

1. Configurez le DAG pour qu’il ignore tout réseau iSCSI détecté actuellement, ceci à l’aide de la cmdlet Set-DatabaseAvailabilityGroupNetwork, comme indiqué dans l’exemple.

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

2. Désactivez l’utilisation du réseau par le cluster en exécutant la commande suivante à partir d’une invite de commande élevée ou de la fenêtre PowerShell. (Exécutez Cluster network pour afficher les noms des réseaux de cluster).

   Cluster network ClusterNetworkName /prop Role=0
   

Après avoir désactivé l’utilisation de tous les réseaux iSCSI par le DAG et son cluster, vous avez la possibilité de forcer la découverte de réseau en exécutant la cmdlet Set-DatabaseAvailabilityGroup avec le paramètre DiscoverNetworks. Si des réseaux iSCSI restent affichés en tant que réseaux de DAG, supprimez tous les sous-réseaux du réseau puis supprimez le réseau de DAG.

Retour au début

Arrêt des membres du groupe de disponibilité de base de données

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 une activation sans perte de toutes les bases de données arrêtées sur le serveur. 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 obtenir la procédure détaillée d’exécution d’un basculement de serveur, voir Effectuer un basculement de serveur.

Retour au début

Installation de correctifs cumulatifs sur les membres du groupe de disponibilité de base de données

L’installation de correctifs cumulatifs 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 Windows. La procédure générale d’application de correctifs cumulatifs à un membre de DAG est la suivante :

• Effectuez un basculement de serveur de manière à ce que toutes les bases de données sur le serveur soient des copies passives.
• Suspendez l’activation des bases de données sur le serveur en cours de mise à jour.
• Installez le correctif cumulatif.
• Reprenez l’activation des bases de données sur le serveur mis à jour.
• Effectuez les basculements de base de données si nécessaire.

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 cumulatif correctif sur un membre du DAG, voir Installation de correctifs cumulatifs sur les membres du groupe de disponibilité de base de données.

Retour au début