Partager via

Gérer les groupes de disponibilité de base de données dans Exchange Server

  • Article

Un groupe de disponibilité de base de données (DAG) est un ensemble de 16 serveurs de boîtes aux lettres Exchange maximum qui fournissent une récupération automatique au niveau de la base de données suite à une défaillance de base de données/serveur/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 DAG, ce serveur fonctionne avec les autres serveurs du DAG pour fournir une récupération automatique au niveau de la base de données en cas de défaillance de base de données.

Lorsque vous créez un DAG, il est initialement vide. 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 les défaillances du réseau ou du serveur est lancée. Le mécanisme de pulsation du cluster de basculement et la base de données de cluster sont ensuite utilisés pour suivre et gérer les informations sur le DAG qui peuvent changer rapidement, telles que les status de montage de base de données, les status de réplication et l’emplacement du dernier montage.

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 le Centre d’administration Exchange (EAC) ou en exécutant l’applet de commande New-DatabaseAvailabilityGroup dans Exchange Management Shell. Lorsque vous créez un DAG, vous fournissez un nom pour le DAG, ainsi que les paramètres facultatifs du serveur témoin et du répertoire de témoins. En outre, vous pouvez affecter une ou plusieurs adresses IP 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 attribuer manuellement des adresses IP au DAG à l’aide du 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.

Si vous créez un DAG qui contiendra des serveurs de boîtes aux lettres qui exécutent Windows Server 2012 R2, vous avez également la possibilité de créer un DAG sans point d’accès administratif de cluster. Dans ce cas, le cluster n’aura pas d’objet de nom de cluster (CNO) dans Active Directory, et le groupe de ressources principal du cluster ne contiendra pas de ressource de nom réseau ou d’adresse IP.

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

Lorsque vous créez un DAG, un objet vide représentant le DAG avec le nom que vous avez spécifié et une classe d’objet msExchMDBAvailabilityGroup sont créés dans Active Directory.

Les DAG utilisent un sous-ensemble des technologies de basculement Windows clustering dans Windows Server 2008 R2 ou version ultérieure, telles que la pulsation du cluster, les réseaux de cluster et la base de données de cluster (pour stocker les données qui changent ou peuvent changer rapidement, telles que les changements d’état de la base de données d’actif à passif ou inversé, ou de montées à démontées ou inversées). Par conséquent, vous pouvez créer des DAG uniquement sur des serveurs de boîtes aux lettres Exchange installés sur les versions prises en charge de Windows qui incluent des clustering de basculement Windows.

Remarque

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 et répertoire témoin de groupe de disponibilité de base (DAG)

Lorsque vous créez un DAG, vous devez spécifier un nom pour le DAG ne dépassant pas 15 caractères qui est 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 sont utilisés uniquement lorsqu’il y a un nombre pair de membres dans le DAG, et uniquement à des fins de quorum. 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 témoin ne doit pas être utilisé à d’autres fins que pour le serveur témoin DAG.

Remarque

Dans la topologie de mise en miroir de bases de données, vous pouvez avoir un troisième serveur appelé « témoin ». Le serveur témoin active le basculement automatique du principal vers miroir serveur ou inversement. Contrairement aux serveurs principal et miroir, le serveur témoin ne sert pas la base de données. Le rôle du témoin est de vérifier si un serveur partenaire donné est opérationnel. La prise en charge du basculement automatique est la seule fonction pour le serveur témoin. Elle identifie le serveur qui détient la copie principale et le serveur qui détient la copie miroir de la base de données.

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 2008 ou 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.

Quel que soit le serveur utilisé comme serveur témoin, si le Pare-feu Windows est activé sur le serveur témoin prévu, vous devez activer l’exception pare-feu Windows pour le partage de fichiers et d’imprimantes. Le serveur témoin utilise le port SMB 445.

Importante

Si le serveur témoin que vous spécifiez n’est pas un serveur Exchange 2010 ou version ultérieure, vous devez ajouter le groupe de sécurité universel (USG) 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 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).

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.

Considérations relatives au placement du serveur témoin

Le placement du serveur témoin d'un DAG dépend des besoins de votre entreprise et des options disponibles pour votre organisation. Exchange inclut désormais la prise en charge des nouvelles options de configuration DAG qui ne sont pas recommandées ou ne sont pas possibles dans Exchange 2010. Ces options incluent l'utilisation d'un troisième emplacement, comme un troisième centre de données, une filiale ou un réseau virtuel Microsoft Azure.

Le tableau suivant répertorie les recommandations générales en matière de placement du serveur témoin pour différents scénarios de déploiement.

Scénario de déploiement Recommandations
DAG unique déployé dans un seul centre de données Placer le serveur témoin dans le même centre de données que les membres du DAG
DAG unique déployé dans deux centres de données ; aucun emplacement supplémentaire disponible Placer le serveur témoin dans un réseau virtuel Microsoft Azure pour permettre le basculement automatique du centre de données, ou

Placer le serveur témoin dans le centre de données principal
Plusieurs DAG déployés dans un seul centre de données Placer le serveur témoin dans le même centre de données que les membres du DAG. Les options supplémentaires suivantes sont disponibles :
  • Utilisation du même serveur témoin pour plusieurs DAG
  • Utilisation d'un membre du DAG qui servira de serveur témoin pour un autre DAG
Plusieurs DAG déployés dans deux centres de données Placer le serveur témoin dans un réseau virtuel Microsoft Azure pour permettre le basculement automatique du centre de données, ou

Placer le serveur témoin dans le centre de données considéré comme le centre principal pour chaque DAG. Les options supplémentaires suivantes sont disponibles :

  • Utilisation du même serveur témoin pour plusieurs DAG
  • Utilisation d'un membre du DAG qui servira de serveur témoin pour un autre DAG
Un ou plusieurs DAG déployés dans plus de deux centres de données Dans cette configuration, le serveur témoin doit être situé dans le centre de données dans lequel vous souhaitez que la plupart des votes de quorum figurent.

Lorsqu’un DAG a été déployé dans deux centres de données, vous pouvez désormais utiliser un troisième emplacement pour héberger le serveur témoin. Si votre organization dispose d’un troisième emplacement avec une infrastructure réseau isolée des défaillances réseau qui affectent les deux centres de données dans lesquels votre DAG est déployé, vous pouvez déployer le serveur témoin du DAG dans ce troisième emplacement, ce qui vous permet de configurer votre DAG avec la possibilité de basculer automatiquement les bases de données vers l’autre centre de données en réponse à un événement de défaillance au niveau du centre de données. Si votre organization n’a que deux emplacements physiques, vous pouvez utiliser un réseau virtuel Microsoft Azure comme troisième emplacement pour placer votre serveur témoin.

Spécification d’un serveur témoin et d’un répertoire témoin lors de la création d’un groupe de disponibilité de base (DAG)

Lorsque vous créez un DAG, vous devez fournir un nom pour le DAG. Vous pouvez aussi éventuellement spécifier un serveur témoin et un répertoire témoin.

Lorsque vous créez un DAG, les combinaisons suivantes d’options et de comportements 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 recherche sur le site Active Directory local un serveur d’accès au client sur lequel le serveur de boîtes aux lettres n’est pas installé et crée automatiquement le répertoire par défaut (%SystemDrive%:\DAGFileShareWitnesses\<DAGFQDN>) et le partage par défaut (<DAGFQDN>) sur ce serveur et utilise ce serveur d’accès au client comme serveur témoin. Par exemple, considérez le serveur témoin CAS3 sur lequel le système d’exploitation a été installé sur le lecteur C. Un DAG nommé DAG1 dans le domaine contoso.com utiliserait un répertoire témoin par défaut C:\DAGFileShareWitnesses\DAG1.contoso.com, qui serait partagé en tant que \CAS3\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 recherche un serveur d'accès au client où le serveur de boîtes aux lettres n'est pas installé et crée automatiquement le groupe de disponibilité de base (DAG) spécifié sur ce serveur, partage le répertoire, puis utilise ce serveur d'accès au client 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. Lorsque ce changement se produit, le cluster du groupe de disponibilité de base (DAG) commence à utiliser le serveur témoin pour conserver le quorum. Si le répertoire témoin n'existe pas, Exchange le crée automatiquement, le partage et lui fournit les autorisations de contrôle total sur le compte d'ordinateur de l'objet nom de cluster du DAG.

Remarque

L'utilisation d'un partage de fichiers intégré à l'espace de noms du système de fichiers distribués (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 un répertoire témoin, le message d’erreur suivant s’affiche :

The task was unable to create the default witness directory on server <Server Name>. Please manually specify a witness directory.

Si vous spécifiez un serveur témoin et un répertoire témoin, le message d’avertissement suivant s’affiche :

Unable to access file shares on witness server '<ServerName>'. Until this problem is corrected, the database availability group may be more vulnerable to failures. You can use the Set-DatabaseAvailabilityGroup cmdlet to try the operation again. Error: The network path was not found.

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, l’applet de commande Add-DatabaseAvailabilityGroupServer affiche le message d’avertissement suivant :

Failed to create file share witness directory 'C:\DAGFileShareWitnesses\DAG_FQDN' on witness server '<ServerName>'. Until this problem is corrected, the database availability group may be more vulnerable to failures. You can use the Set-DatabaseAvailabilityGroup cmdlet to try the operation again. Error: WMI exception occurred on server '<ServerName>': The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)

Pour résoudre les erreurs et avertissements précédents, effectuez l’une des étapes 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.

Appartenance au groupe de disponibilité de base (DAG)

Une fois qu’un DAG a été créé, vous pouvez ajouter ou supprimer des serveurs du DAG à l’aide de l’Assistant Gérer le groupe de disponibilité de base de données dans le CENTRE d’administration Exchange ou des applets de commande Add-DatabaseAvailabilityGroupServer ou Remove-DatabaseAvailabilityGroupServer dans 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, à tout moment, un serveur de boîtes aux lettres peut être membre d’un seul DAG.

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.

Lorsque le premier serveur de boîtes aux lettres est ajouté à un DAG, les événements suivants se produisent :

  • 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 votre environnement, l’ajout du deuxième serveur peut entraîner la création d’un nouveau cluster (et d’une nouvelle CNO) pour le DAG. Cette création est due au fait que l’objet DAG semble vide du point de vue du deuxième membre ajouté, ce qui amène l’applet de commande Add-DatabaseAvailabilityGroupServer à créer un cluster et un CNO pour le DAG, 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.

Lorsque le deuxième serveur et les serveurs suivants sont ajoutés au DAG, les événements suivants se produisent :

  • 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 ne passe pas automatiquement au modèle approprié, vous pouvez exécuter l’applet de commande Set-DatabaseAvailabilityGroup avec uniquement le paramètre Identity à corriger dans les paramètres de quorum du DAG.

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

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. 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, l'instance PowerShell distante contacte le service de réplication d'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.

Attention

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). Si les membres de votre DAG exécutent Windows Server 2012 R2 et que vous créez un DAG sans point d’accès administratif de cluster, un CNO n’est pas créé et vous n’avez pas besoin de créer un CNO pour le 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 créez et désactivez un compte d’ordinateur pour le CNO, puis effectuez l’une des étapes suivantes :

  • 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éinstallation de 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 (DAG)

Les serveurs de boîtes aux lettres peuvent être supprimés d’un DAG à l’aide de l’Assistant Gérer le groupe de disponibilité de base de données dans le Centre d’administration Exchange ou de l’applet de commande Remove-DatabaseAvailabilityGroupServer dans 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 :

  • Exécution d’une opération de récupération de serveur : si un serveur de boîtes aux lettres membre d’un DAG est perdu ou échoue et est irrécupérable et doit ê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 l’opération de récupération, vous devez d’abord supprimer le serveur du DAG à l’aide de l’applet de commande Remove-DatabaseAvailabilityGroupServer avec le paramètre ConfigurationOnly .

  • Suppression du groupe de disponibilité de base de données : il peut arriver que vous deviez supprimer un DAG (par exemple, lors de la désactivation du mode de réplication tiers). 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 contient des membres, la tâche échouera.

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

Une fois que les serveurs ont été ajoutés au DAG, vous pouvez utiliser le CAE ou l’environnement de ligne de commande Exchange Management Shell pour configurer les propriétés d’un DAG, y compris le serveur témoin et le répertoire témoin utilisés par le DAG, ainsi que les adresses IP affectées au DAG.

Les propriétés configurables sont les suivantes :

  • Serveur témoin : nom du serveur sur lequel vous souhaitez héberger le partage de fichiers pour le témoin de partage de fichiers. Nous vous recommandons de spécifier un serveur d'accès au client en tant que serveur témoin. Ce nom permet au système de configurer, de sécuriser et d’utiliser automatiquement le partage, selon les besoins, et permet à l’administrateur de messagerie de connaître la disponibilité du serveur témoin.

  • Répertoire témoin : nom d’un répertoire qui sera utilisé pour stocker les données de 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 doivent être affectées au DAG, sauf si les membres du groupe de disponibilité de base de données exécutent Windows Server 2012 R2 et que vous créez un DAG sans adresse IP. Dans le cas contraire, les adresses IP du DAG 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 vous permet de configurer les propriétés DAG qui ne sont pas disponibles dans le CENTRE d’administration Exchange, telles que les adresses IP du groupe de disponibilité de groupe de disponibilité ; paramètres de chiffrement et de compression réseau ; découverte de réseau ; port TCP utilisé pour la réplication ; et autres paramètres de serveur témoin et d’annuaire de témoins ; et pour activer le mode 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 Configuration des propriétés du groupe de disponibilité de 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.) L’établissement d’une liaison d’authentification Kerberos sélectionne le protocole de chiffrement le plus puissant pris en charge dans la liste : généralement Advanced Encryption Standard (AES) 256 bits, potentiellement avec un code d’authentification de message basé sur le hachage SHA (HMAC) pour maintenir l’intégrité des données. Pour plus d’informations, consultez HMAC.

Le chiffrement réseau est une propriété du DAG et non du réseau DAG. Vous pouvez configurer le chiffrement réseau DAG à l’aide de l’applet de commande Set-DatabaseAvailabilityGroup dans Exchange Management Shell. Les paramètres de chiffrement possibles pour les communications réseau DAG sont indiqués dans le tableau suivant :

Setting 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. Ce paramètre est le 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. Cette compression est le même type de compression que celui utilisé dans de nombreux protocoles Microsoft, en particulier la compression RPC MAPI entre Microsoft Outlook et Exchange.

Comme avec le chiffrement réseau, la compression réseau est également une propriété du DAG et non du réseau DAG. Vous configurez la compression du réseau DAG à l’aide de l’applet de commande Set-DatabaseAvailabilityGroup dans Exchange Management Shell. Les paramètres de compression possibles pour les communications réseau DAG sont indiqués dans le tableau suivant :

Setting 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. Ce paramètre est le paramètre par défaut.
SeedOnly La compression réseau est utilisée sur tous les réseaux DAG pour l'amorçage uniquement.

Réseaux DAG

Un réseau DAG est constitué d’un ou de plusieurs sous-réseaux utilisés pour le trafic de réplication ou le trafic MAPI. Chaque DAG contient au maximum un réseau MAPI et aucun, un ou plusieurs réseaux de réplication. Dans une configuration de carte réseau unique, le réseau est utilisé pour le trafic MAPI et le trafic de réplication. Bien qu’une seule carte réseau et un seul chemin d’accès soient pris en charge, nous recommandons que chaque DAG dispose d’un minimum de deux réseaux DAG. Dans une configuration à deux réseaux, un réseau est généralement dédié au trafic de réplication, et l’autre réseau est principalement utilisé 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.

Remarque

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. 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.

Dans Exchange 2010, la configuration manuelle des réseaux DAG était nécessaire dans plusieurs scénarios. Par défaut, dans les versions ultérieures d’Exchange, les réseaux DAG sont automatiquement configurés par le système. Pour pouvoir créer ou modifier des réseaux DAG, vous devez d'abord activer le contrôle de réseau DAG manuel en exécutant la commande suivante :

Set-DatabaseAvailabilityGroup <DAGName> -ManualDagNetworkConfiguration $true

Une fois que vous avez activé la configuration réseau manuelle du DAG, vous pouvez utiliser l’applet de commande New-DatabaseAvailabilityGroupNetwork dans 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éation d'un réseau de groupe de disponibilité de la base de données.

Vous pouvez utiliser l’applet de commande Set-DatabaseAvailabilityGroupNetwork dans l’environnement de ligne de commande Exchange Management Shell pour configurer les propriétés réseau du DAG. Pour obtenir la procédure détaillée sur la configuration des propriétés de réseau DAG, voir Configuration des 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 : nom unique pour le réseau DAG de 128 caractères maximum.

  • Description du réseau : description facultative du réseau DAG de 256 caractères maximum.

  • Sous-réseaux réseau : un ou plusieurs sous-réseaux entrés au 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 le CENTRE d’administration 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 d’utiliser le réseau DAG et activer le trafic MAPI. Dans Exchange Management Shell, utilisez le paramètre ReplicationEnabled dans l’applet de commande Set-DatabaseAvailabilityGroupNetwork pour activer et 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 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, MapiDagNetwork et ReplicationDagNetwork01) créés par le système sont basés 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 exemples de paramètres de configuration d’adresse IP sont indiqué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
EX1-Replication 10.0.0.15/24 Non applicable
EX2-MAPI 192.168.1.16 192.168.1.1
EX2-Replication 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 : MapiDagNetwork (192.168.1.0) et ReplicationDagNetwork01 (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
MapiDagNetwork 192.168.1.0/24 EX1 (192.168.1.15)
EX2 (192.168.1.16)		 True True
ReplicationDagNetwork01 10.0.0.0/24 EX1 (10.0.0.15)
EX2 (10.0.0.16)		 False True

Pour terminer la configuration de ReplicationDagNetwork01 en tant que réseau de réplication dédié, désactivez la réplication pour MapiDagNetwork en exécutant la commande suivante :

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

Une fois la réplication désactivée pour MapiDagNetwork, le service de réplication Microsoft Exchange utilise ReplicationDagNetwork01 pour la réplication continue. Si ReplicationDagNetwork01 échoue, le service de réplication Microsoft Exchange utilise de nouveau MapiDagNetwork pour la réplication continue. Le retour à MapiDagNetwork est effectué intentionnellement par le système pour maintenir la haute disponibilité.

Déploiement de réseaux DAG et de plusieurs sous-réseaux

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 à plusieurs sous-réseaux, les sous-réseaux sont automatiquement associés au réseau DAG correspondant.

Par exemple, prenons DAG2, un DAG à deux membres où chaque membre a deux cartes réseau (une dédiée pour le réseau MAPI et l’autre pour un réseau de réplication), et chaque membre DAG se trouve dans un site Active Directory distinct, avec son réseau MAPI sur un sous-réseau différent. Les exemples de paramètres de configuration d’adresse IP sont indiqué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. Lorsque EX1 et EX2 sont ajoutés au DAG, quatre sous-réseaux sont énumérés et seulement deux réseaux DAG sont créés : MapiDagNetwork (192.168.0.0, 192.168.1.0) et ReplicationDagNetwork01 (10.0.0.0, 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
MapiDagNetwork 192.168.0.0/24
192.168.1.0/24		 EX1 (192.168.0.15)
EX2 (192.168.1.15)		 True True
ReplicationDagNetwork01 10.0.0.0/24
10.0.1.0/24		 EX1 (10.0.0.15)
EX2 (10.0.1.15)		 False True

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. Cette découverte inclut celle de tous les réseaux iSCSI (Internet SCSI) en cours d’utilisation suite à 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 doivent pas être gérés par le DAG ou son cluster, ni être utilisés en tant que réseaux DAG (MAPI ou réplication). Au lieu de cela, ces réseaux doivent être manuellement désactivés de l’utilisation par le DAG afin qu’ils puissent être dédiés au trafic de 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 sont pas utilisés pour le trafic MAPI ou de réplication une fois la commande ci-dessus exécutée.

Configuration des membres du groupe de disponibilité de base de données (DAG)

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

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 l’applet de commande 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 est automatiquement montée immédiatement après un basculement si la longueur de la 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. Lorsque 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 automatiquement 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 ne se monte pas automatiquement tant que tous les journaux générés sur la copie active n’ont pas été copiés dans 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 que tous les journaux de la copie active ne peuvent pas être copiés vers la copie passive en cours d’activation, vous risquez de perdre certaines données de boîte aux lettres. Toutefois, la fonctionnalité Safety Net (activée par défaut) forme une protection contre la plupart des cas de perte de données en renvoyant les messages qui se trouvent dans la file d’attente de Safety Net.

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 l’applet de commande Set-MailboxServer pour configurer le paramètre DatabaseCopyAutoActivationPolicy avec l’une des valeurs suivantes :

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

  • IntrasiteOnly: si vous spécifiez cette valeur, la copie de base de données est autorisée à être activée sur les serveurs du même site Active Directory. Cette activation empêche le basculement ou l’activation intersites. 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 sur l’activation des copies de base 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 maximum de 20 bases de données actives :

Set-MailboxServer -Identity EX1 -MaximumActiveDatabases 20

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

Avant d’effectuer tout type de maintenance matérielle ou logicielle sur un membre du DAG, vous devez d’abord mettre le membre du DAG en mode maintenance. Les scripts suivants sont fournis avec Exchange Server pour faciliter les procédures de maintenance de DAG :

  • StartDagServerMaintenance.ps1: aide à déplacer toutes les bases de données actives hors du serveur. Il déplace également toutes les fonctionnalités de prise en charge du DAG critiques, telles que le rôle gestionnaire Active Manager principal (PAM) et les empêche de revenir sur le serveur avant la fin de la maintenance.

  • StopDagServerMaintenance.ps1: aide à sortir le membre DAG du mode maintenance et à en faire une cible active pour toutes les bases de données et toutes les fonctionnalités critiques de prise en charge du DAG.

Les deux scripts ci-dessus acceptent le paramètre ServerName (qui peut être le nom d’hôte ou le nom de domaine complet (FQDN) du membre DAG) et les paramètres WhatIf . Les deux scripts peuvent être exécutés localement ou à distance. Les outils de gestion de cluster de basculement doivent être installés sur le serveur sur lequel les scripts sont exécutés (clustering des outils d'administration de serveur distant).

Remarque

Le script RedistributeActiveDatabases.ps1 est également disponible, ce qui permet de monter des bases de données de boîte aux lettres sur des membres DAG spécifiques, comme indiqué par le numéro de préférence d’activation sur chaque base de données. Toutefois, dans Exchange 2016 CU2 ou version ultérieure, la nouvelle propriété DAG nommée PreferenceMoveFrequency équilibre automatiquement les copies de base de données sur un DAG. Par conséquent, vous devez utiliser RedistributeActiveDatabases.ps1 script uniquement si vous avez désactivé cette fonctionnalité ou si vous souhaitez équilibrer manuellement les copies de base de données.

Le script StartDagServerMaintenance.ps1 effectue les tâches suivantes :

  • Définit la valeur du paramètre DatabaseCopyAutoActivationPolicy sur le membre BlockedDAG sur , ce qui empêche toute copie de base de données d’être activée sur le serveur.

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

  • 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, sont annulées par le script, sauf les transferts de base de données réussis.

Pour commencer les procédures de maintenance sur un membre DAG, y compris le vidage des files d’attente de transport et la suspension de la connectivité cliente, effectuez les tâches suivantes :

  1. Pour vider les files d’attente de transport, exécutez la commande suivante :

    Set-ServerComponentState <ServerName> -Component HubTransport -State Draining -Requester Maintenance

  2. Pour lancer le drainage des files d’attente de transport, exécutez la commande suivante :

    Restart-Service MSExchangeTransport

  3. Pour commencer le processus de drainage de tous les appels de messagerie unifiée (dans Exchange 2016 uniquement), exécutez la commande suivante :

    Set-ServerComponentState <ServerName> -Component UMCallRouter -State Draining -Requester Maintenance

  4. Pour accéder aux scripts de maintenance DAG, exécutez la commande suivante :

    CD $ExScripts

  5. Pour exécuter le script StartDagServerMaintenance.ps1 , exécutez la commande suivante :

    .\StartDagServerMaintenance.ps1 -ServerName <ServerName> -MoveComment Maintenance -PauseClusterNode

    Pour la valeur du paramètre MoveComment , vous pouvez créer la notation souhaitée. L’exemple ci-dessus utilise « Maintenance ».

    Remarque

    L’exécution de ce script peut prendre un certain temps et, pendant ce temps, il se peut que vous ne voyiez aucune activité sur votre écran.

  6. Pour rediriger les messages en attente de remise dans les files d’attente locales vers le serveur Exchange spécifié par le paramètre Target, exécutez la commande suivante :

    Redirect-Message -Server <ServerName> -Target <Server FQDN>

  7. Pour placer le serveur en mode maintenance, exécutez la commande suivante :

    Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Inactive -Requester Maintenance

Pour vérifier que le serveur est prêt pour la maintenance, effectuez les tâches suivantes :

  1. Pour vérifier que le serveur a été placé en mode maintenance, vérifiez que et RecoveryActionsEnabled sont dans un état actif uniquement Monitoring lorsque vous exécutez la commande suivante :

    Get-ServerComponentState <ServerName> | Format-Table Component,State -Autosize

  2. Pour vérifier que le serveur n’héberge aucune copie de base de données active, exécutez la commande suivante :

    Get-MailboxServer <ServerName> | Format-List DatabaseCopyAutoActivationPolicy

  3. Pour vérifier que le nœud de cluster est suspendu, exécutez la commande suivante :

    Get-ClusterNode <ServerName> | Format-List

  4. Pour vérifier que toutes les files d’attente de transport ont été vidées, exécutez la commande suivante :

    Get-Queue

Une fois la maintenance terminée et le membre DAG prêt à remettre en service, le script StopDagServerMaintenance.ps1 permet de sortir le membre du DAG du mode maintenance et de le remettre en production. Le script StopDagServerMaintenance.ps1 effectue les tâches suivantes :

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

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

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

Lorsque vous êtes prêt à restaurer le membre DAG en status de production complète, y compris la reprise des files d’attente de transport et de la connectivité client, effectuez les tâches suivantes :

  1. Pour configurer le serveur pour qu’il soit en mode hors maintenance et prêt à accepter les connexions clientes, exécutez la commande suivante :

    Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active -Requester Maintenance

  2. Pour autoriser le serveur à accepter les appels de messagerie unifiée (dans Exchange 2016 uniquement), exécutez la commande suivante :

    Set-ServerComponentState <ServerName> -Component UMCallRouter -State Active -Requester Maintenance

  3. Pour accéder aux scripts de maintenance DAG, exécutez la commande suivante :

    CD $ExScripts

  4. Pour exécuter le script StopDagServerMaintenance.ps1 , exécutez la commande suivante :

    .\StopDagServerMaintenance.ps1 -serverName <ServerName>

  5. Pour permettre aux files d’attente de transport de reprendre l’acceptation et le traitement des messages, exécutez la commande suivante :

    Set-ServerComponentState <ServerName> -Component HubTransport -State Active -Requester Maintenance

  6. Pour reprendre l’activité de transport, exécutez la commande suivante :

    Restart-Service MSExchangeTransport

Pour vérifier qu'un serveur est prêt pour la production, effectuez les tâches suivantes :

  1. Pour vérifier que le serveur n’est pas en mode maintenance, exécutez la commande suivante :

    Get-ServerComponentState <ServerName> | Format-Table Component,State -Autosize

Si vous installez une mise à jour Exchange et que le processus de mise à jour échoue, certains composants du serveur peuvent rester inactifs, qui seront affichés dans la sortie de l’applet de commande ci-dessus Get-ServerComponentState . Pour résoudre ce problème, exécutez les commandes suivantes :

  1. Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active -Requester Functional

  2. Set-ServerComponentState <ServerName> -Component Monitoring -State Active -Requester Functional

  3. Set-ServerComponentState <ServerName> -Component RecoveryActionsEnabled -State Active -Requester Functional

Arrêt des membres du DAG

La solution de haute disponibilité Exchange 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 d’arrêt seront lossless activées. C'est pourquoi il est préférable d'effectuer un basculement de serveur avant d'arrêter un serveur membre d'un DAG.

Installation de mises à jour sur les membres du DAG

L’installation des mises à jour Exchange sur un serveur membre d’un DAG est un processus relativement simple. Plusieurs services sont arrêtés lorsque vous installez une mise à jour 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 mises à jour à un membre de DAG est la suivante :

  1. Suivez les étapes décrites ci-dessus pour mettre le membre du DAG en mode maintenance.

  2. Installez la mise à jour.

  3. Suivez les étapes décrites ci-dessus pour enlever le membre du DAG du mode maintenance et le remettre en production.

  4. Si vous le souhaitez, utilisez le script RedistributeActiveDatabases.ps1 pour rééquilibrer les copies de base de données actives sur le DAG.

Pour plus d’informations sur les dernières mises à jour Exchange, consultez Exchange Server numéros de build et dates de publication.

Remarque

Vous devez toujours exécuter tous les membres du DAG sur la même version du serveur Exchange (y compris les mises à jour cumulatives et de sécurité). Effectuez une « mise à jour propagée » de tous les membres du DAG et n’exécutez pas de DAG avec des membres sur une autre version d’Exchange pendant une période prolongée.