Cet article a fait l’objet d’une traduction automatique. Pour afficher l’article en anglais, activez la case d’option Anglais. Vous pouvez également afficher le texte anglais dans une fenêtre contextuelle en faisant glisser le pointeur de la souris sur le texte traduit.
Traduction
Anglais

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

[Cette rubrique est une documentation préliminaire et peut être modifiée dans les versions ultérieures. Des rubriques vides sont incluses comme espaces réservés. N’hésitez pas à nous transmettre vos commentaires. Envoyez-nous un e-mail à l’adresse ExchangeHelpFeedback@microsoft.com.]  

S’applique à :Exchange Server 2016

Résumé: Apprenez à créer, configurer et gérer un groupe de disponibilité de base de données (DAG) dans Exchange 2016.

Un groupe de disponibilité de base de données (DAG) est un ensemble de serveurs de boîtes aux lettres jusqu'à 16 Exchange 2016 qui permet une récupération automatique, au niveau de la base de données à partir d’une base de données, serveur ou du réseau. DAGs utilisez la réplication continue et un sous-ensemble de Windows technologies de clustering de basculement pour une haute disponibilité et résilience de site. Les serveurs de boîtes aux lettres dans un DAG surveillent mutuellement pour les échecs. Lorsqu’un serveur de boîtes aux lettres est ajouté à un DAG, celui-ci fonctionne avec les autres serveurs de la DAG pour fournir une récupération automatique, au niveau de la base de données contre les défaillances de la base de données.

Lorsque vous créez un DAG, il est 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 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é.

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 la cmdlet New-DatabaseAvailabilityGroup dans l' Environnement de ligne de commande Exchange Management Shell. Lorsque vous créez un DAG, vous fournissez un nom pour le DAG et serveur témoin facultatif et aux paramètres des répertoires de témoin. En outre, vous pouvez affecter une ou plusieurs adresses IP pour le DAG, soit à l’aide des adresses IP statiques, soit en autorisant le DAG à affecter automatiquement les adresses IP nécessaires à l’aide de DHCP Dynamic Host Configuration Protocol (). Vous pouvez affecter manuellement des adresses IP pour le DAG en utilisant le paramètre DatabaseAvailabilityGroupIpAddresses . Si vous omettez ce paramètre, le DAG tente d’obtenir une adresse IP à l’aide d’un serveur DHCP sur votre réseau.

Si vous créez un DAG destiné à contenir des serveurs de boîtes aux lettres exécutant 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 groupe n’aura pas d’objet de nom de cluster (CNO) dans Active Directory et le groupe de ressources de base du cluster ne contiendra pas de ressource de nom de réseau ni de ressource 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 portant le nom que vous avez indiqué et une classe d’objet dumsExchMDBAvailabilityGroup sont créés dans Active Directory.

DAGs utiliser un sous-ensemble des technologies, telles que la pulsation de cluster, les réseaux de cluster et base de données du cluster (pour le stockage des données change ou susceptible de changer rapidement, comme les modifications de l’état de base de données actif au passif ou à l’inverse, de clustering Windows ou à partir de démontée ou l’inverse). Comme DAGs reposent sur les clusters de basculement Windows, ils ne peuvent être créés sur les Exchange 2013 des serveurs de boîtes aux lettres exécute le Windows Server 2008 R2, Enterprise ou Datacenter, Windows Server 2012 Standard ou système d’exploitation Datacenter ou Windows Server 2012 R2 Système d’exploitation standard ou de centre de données.

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

Lorsque vous créez un DAG, vous devez spécifier un nom pour le DAG n’a plus de 15 caractères qui est unique dans la forêt Active Directory. En outre, chaque DAG est configuré avec un serveur témoin et d’un répertoire de témoin. Le serveur témoin et son répertoire sont utilisés uniquement lorsqu’il existe un nombre pair de membres dans la DAG puis uniquement à des fins de quorum. Vous n’avez pas besoin de créer le répertoire de rappel à l’avance. Exchange crée automatiquement et sécurise l’annuaire pour vous sur le serveur témoin. Le répertoire de rappel ne doit pas être utilisé à des fins autres que pour le serveur témoin DAG.

noteRemarque :
Dans la base de données mise en miroir de la topologie, vous pouvez avoir un troisième serveur appelé témoin. Le serveur témoin permet un basculement automatique du principal au serveur miroir et inversement. À la différence des serveurs principal et miroir, le serveur témoin ne sert pas de la base de données. Le rôle du témoin est de vérifier si un serveur partenaire donné est et le fonctionnement. Prise en charge du basculement automatique est la seule fonction de serveur témoin, et identifie le serveur qui conserve la copie principale et le serveur qui conserve 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 2012, 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. Cependant, chaque groupe de disponibilité nécessite son propre répertoire témoin.

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

importantImportant :
Si le serveur de rappel que vous spécifiez n’est pas un serveur Exchange 2016 ou Exchange 2010, vous devez ajouter le groupe de sécurité universel de sous-système sécurisé Exchange (USG) pour le groupe Administrateurs local sur le serveur témoin avant de créer le DAG. Ces autorisations de sécurité sont nécessaires pour assurer que Exchange peut créer un répertoire et le partage sur le serveur témoin en fonction des besoins.

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

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

Le placement du serveur témoin d’un DAG dépend des besoins de votre entreprise et des options disponibles pour votre organisation. Exchange 2013 inclut la prise en charge de nouvelles options de configuration de DAG qui ne sont pas recommandées ou qui n’existent pas dans les versions précédentes d’Exchange. 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éploiementRecommandations

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 groupe de disponibilité de base (DAG) a été déployé dans deux centres de données, une nouvelle option de configuration dans Exchange 2013 permet d’utiliser un troisième emplacement pour héberger le serveur témoin. Si votre organisation dispose d’un troisième emplacement avec une infrastructure réseau protégée contre les pannes de réseau qui affectent les deux centres de données dans lesquels votre groupe de disponibilité de base (DAG) est déployé, vous pouvez déployer le serveur témoin du DAG dans ce troisième emplacement. Cela permet de configurer votre DAG afin qu’il bascule automatiquement les bases de données vers l’autre centre de données en cas de défaillance de niveau centre de données. Si votre organisation 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.

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.

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 recherche sur le site Active Directory local un serveur d’accès au client où 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, puis utilise ce serveur d’accès au client comme serveur témoin. Par exemple, prenons le serveur témoin CAS3 sur lequel nous avons installé le système d’exploitation sur le lecteur C. Un groupe de disponibilité de base (DAG) nommé DAG1 dans le domaine contoso.com doit utiliser un répertoire témoin par défaut de C:\DAGFileShareWitnesses\DAG1.contoso.com, qui doit être 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.

noteRemarque :
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 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 ’ServerName’. 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 ’ServerName’. 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 ’ServerName’ : 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

Après avoir créé un DAG, vous pouvez ajouter des serveurs ou supprimer des serveurs à partir de la DAG à l’aide de l’Assistant groupe de disponibilité de base de données de gestion dans le Centre d’administration Exchange (EAC), ou à l’aide des applets de commande Add-DatabaseAvailabilityGroupServer ou Remove-DatabaseAvailabilityGroupServer dans la Environnement de ligne de commande Exchange Management Shell. Pour obtenir la procédure détaillée sur la façon de gérer les membres DAG, voir Gérer l’appartenance au groupe de disponibilité de la base de données.

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

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

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.

warningAvertissement :
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 du DAG exécutent Windows Server 2012 R2 et que vous créez un DAG sans point d’accès administratif de cluster, aucun CNO n’est créé et il n’est pas nécessaire de créer de 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 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éinstallation de l’objet nom de cluster pour un groupe de disponibilité de base de données.

Les serveurs de boîtes aux lettres peuvent être supprimés d’un groupe de disponibilité de base de données (DAG) à l’aide de l’Assistant Gestion des groupes de disponibilité de base de données du Centre d’administration Exchange (EAC) 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 du groupe de 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 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.

Retour au début

Une fois les serveurs ajoutés au DAG, vous pouvez utiliser le Centre d’administration Exchange (EAC) ou l’Environnement de ligne de commande Exchange Management Shell pour configurer les propriétés d’un DAG, y compris le serveur et le répertoire témoins utilisés par le DAG, ainsi que 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 d’accès au client en tant que serveur témoin. Cela permet au système de configurer, de sécuriser et d’utiliser automatiquement le partage si nécessaire, mais permet également à l’administrateur de messagerie de connaître la disponibilité du serveur témoin.

  • 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 doivent être affectées au DAG, sauf si les membres du DAG 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 des propriétés du groupe de disponibilité de base de données (DAG) qui ne sont pas accessibles dans le Centre d’administration Exchange (EAC) comme les adresses IP du DAG, les paramètres de chiffrement et de compression réseau, la découverte du réseau, le port TCP utilisé pour la réplication et d’autres paramètres de serveur témoin et de répertoire témoin, et aussi 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 Configuration des propriétés du 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 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, « Encryption Types » (Types de chiffrement) du fichier sur les extensions du 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ètreDescription

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.

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 Explication de l’algorithme de décompression et la section 3.1.4.11.1.2.1, « LZ77 Compression Algorithm » (Algorithme de compression LZ77) de Spécification du protocole au format câble. 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ètreDescription

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

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.

noteRemarque :
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. Dans Exchange 2013, par défaut, 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é une configuration réseau DAG manuelle, vous pouvez utiliser l’applet de commande New-DatabaseAvailabilityGroupNetwork dans les Environnement de ligne de commande Exchange Management Shell pour créer un réseau DAG. Pour obtenir la procédure détaillée sur la façon de créer 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 le Environnement de ligne de commande Exchange Management Shell pour configurer les propriétés de réseau DAG. Pour obtenir la procédure détaillée sur la façon de configurer les propriétés de réseau DAG, consultez Configuration des propriétés du réseau de groupe de disponibilité de la base de données. Chaque réseau DAG est obligatoire et des paramètres facultatifs pour 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 le Centre d’administration Exchange (EAC), cochez la case pour dédier le réseau DAG au trafic de réplication et bloquer le trafic MAPI. Désélectionnez la case à cocher pour empêcher la réplication d’utiliser le réseau DAG 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.

noteRemarque :
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 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-serveurAdresse IP/masque de sous-réseauPasserelle 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

NomSous-réseauxInterfacesAccè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 achever 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. Cette opération est effectuée intentionnellement par le système pour maintenir une disponibilité élevée.

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, 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-serveurAdresse IP/masque de sous-réseauPasserelle 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

NomSous-réseauxInterfacesAccè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

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 sont pas utilisés pour le trafic MAPI ou de réplication une fois la commande ci-dessus exécutée.

Retour au début

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 :

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

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

Set-MailboxServer -Identity EX1 -AutoDatabaseMountDial GoodAvailability

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.

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

Set-MailboxServer -Identity EX1 -DatabaseCopyAutoActivationPolicy Blocked

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.

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

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 2016 pour vous aider avec les procédures de maintenance DAG.

  • StartDagServerMaintenanceScripts.ps1 Script vous aidant à déplacer toutes les bases de données actives désactivée sur le 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.

  • StopDagServerMaintenanceScripts.ps1 Script vous aidant à faire sortir le membre DAG du mode maintenance et à le transformer en cible active pour toutes les bases de données et toutes les fonctionnalités de prise en charge du DAG critiques.

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 le paramètre -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).

noteRemarque :
RedistributeActiveDatabases.ps1 est un autre script disponible qui permet de monter les 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, une nouvelle propriété DAG appelée PreferenceMoveFrequency est présente dans Exchange 2016 CU2 ou version ultérieure. Cette propriété équilibre automatiquement des copies de base de données sur un DAG, afin que seul le script RedistributeActiveDatabases.ps1 soit nécessaire si vous avez désactivé cette nouvelle fonctionnalité ou si vous voulez équilibrer manuellement les copies de base de données. Pour plus d’informations, consultez la section « Propriété DAG PreferenceMoveFrequency » dans la rubrique Gestion des copies de base de données de boîtes aux lettres.

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

  • Définit la valeur du paramètre DatabaseCopyAutoActivationPolicy sur le membre DAG sur Blocked, 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écuter

    Set-ServerComponentState <ServerName> -Component HubTransport -State Draining -Requester Maintenance
    
  2. Pour lancer le drainage des files d’attente de transport, exécutez Restart-Service MSExchangeTransport

  3. Pour lancer le processus de drainage de tous les appels de messagerie unifiée, exécutez

    Set-ServerComponentState <ServerName> -Component UMCallRouter -State Draining -Requester Maintenance
    
  4. Pour accéder aux scripts de maintenance DAG, exécutez CD $ExScripts.

  5. Pour exécuter le script StartDagMaintenance.ps1, exécutez

    .\StartDagMaintenance.ps1 -serverName <ServerName> -MoveComment Maintenance
    

    Après le paramètre -MoveComment, vous pouvez effectuer des notations. L’exemple ci-dessus utilise « Maintenance ».

    noteRemarque :
    L’exécution du script peut être longue. Pendant ce temps, il se peut qu’aucune activité n’apparaisse sur votre écran.
  6. Pour rediriger les messages en attente de remise dans les files d’attente locales vers le serveur Exchange 2016 spécifié par le paramètre Target, exécutez

    Redirect-Message -Server <ServerName> -Target <Server FQDN>
    
  7. Pour mettre le serveur en mode maintenance, exécutez

    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, confirmez que seuls Monitoring et RecoveryActionsEnabled sont dans un état actif lorsque vous exécutez la commande suivante :

    Get-ServerComponentState <ServerName> | FT Component,State -Autosize
    
  2. Pour vérifier que le serveur n’héberge aucune copie de base de données active, exécutez

    Get-MailboxServer <ServerName> | FL DatabaseCopyAutoActivationPolicy
    
  3. Pour vérifier que le nœud de cluster est interrompu, exécutez

    Get-ClusterNode <ServerName> | FL
    
  4. Pour vérifier que toutes les files d’attente de transport ont été vidées, exécutez Get-Queue.

Une fois la maintenance terminée et le membre DAG prêt à fonctionner de nouveau, le script StopDagServerMaintenance.ps1 enlève le membre DAG du mode maintenance et le remet en production. Le script StopDagServerMaintenance.ps1 réalise 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 avec le statut de production complète, y compris la reprise les files d’attente de transport et la connectivité cliente, effectuez les tâches suivantes :

  1. Pour configurer le serveur comme hors mode maintenance et prêt à accepter les connexions client, exécutez

    Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active -Requester Maintenance
    
  2. Pour autoriser le serveur à accepter des appels de messagerie unifiée, exécutez

    Set-ServerComponentState <ServerName> -Component UMCallRouter -State Active -Requester Maintenance
    
  3. Pour exécuter le script StopDagMaintenance.ps1, exécutez

    .\StopDagMaintenance.ps1 -serverName <ServerName> -MoveComment Maintenance
    
  4. Pour activer les files d’attente de transport afin de reprendre l’acceptation et le traitement des messages, exécutez

    Set-ServerComponentState <ServerName> -Component HubTransport -State Active -Requester Maintenance
    
  5. Pour reprendre l’activité de transport, exécutez

    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

    Get-ServerComponentState <ServerName> | ft Component,State -Autosize
    

Si vous installez une mise à jour Exchange et que l’opération échoue, certains composants de serveur peuvent rester dans un état inactif, ce qui sera affiché dans les résultats de la cmdlet Get-ServerComponentState ci-dessus. 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

Retour au début

La solution de haute disponibilité Exchange 2013 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.

Retour au début

L’installation de mises à jour Microsoft Exchange Server 2013 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 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. Vous pouvez également utiliser le script RedistributeActiveDatabases.ps1 pour rééquilibrer les copies de base de données actives dans le DAG.

Vous pouvez télécharger la dernière mise à jour pour Exchange 2013 à partir du Centre de téléchargement Microsoft.

Retour au début

 
Afficher: