Le mode de coordination de l’activation du centre de données (DAC) est une propriété du groupe de disponibilité des bases de données (DAG). Ce mode est utilisé pour contrôler le montage de la base de données sur le comportement de démarrage du groupe de disponibilité de la base de données (DAG). Cette fonctionnalité est conçue pour éviter que le “split brain” ne se produise au niveau de la base de données lors d’un switchback.
Qu’est-ce qu’un cerveau divisé ? Un cerveau divisé, également connu sous le nom de syndrome du cerveau divisé, est une situation dans laquelle une base de données de boîtes aux lettres est définie comme la copie active de deux membres du groupe de disponibilité des bases de données. Il en résulte des problèmes de communication entre les deux serveurs et les deux bases de données.
Pour éviter ce problème, vous pouvez activer le mode de coordination de l’activation du centre de données (DAC), qui requiert l’autorisation de monter la base de données auprès des membres du groupe de disponibilité de la base de données (DAG) avant de procéder à l’activation. Il s’agit d’une option de sécurité.
Lorsque le mode de coordination de l’activation du centre de données (DAC) est activé, il permet non seulement d’éviter que votre cluster ne se retrouve dans une situation de ” split brain “, mais aussi d’activer de nouvelles cmdlets, notamment Stop-DatabaseAvailabilityGroup, Start-DatabaseAvailabilityGroup et Restore-DatabaseAvailabilityGroup. Ces commandes sont très utiles lors du basculement d’un centre de données.
Pour confirmer si le mode DAC est actif ou non, vous pouvez utiliser la commande Get-DatabaseAvailabilityGroup avec les paramètres suivants pour obtenir les informations.
Get-DatabaseAvailabilityGroup | Select Name,Servers,DatacenterActivationMode
Si elle n’a pas été activée, la sortie sera affichée comme “off”.
Pour activer le mode DAC, vous devez utiliser la cmdlet Set-DatabaseAvailabilitGroup comme indiqué ci-dessous.
Set-DatabaseAvailabilityGroup servername -DatacenterActivationMode DagOnly /servername
Une fois cette opération terminée, le DataCenterActivationMode passera à DagOnly.
Éléments à prendre en compte avant d’activer le mode DAC
Le mode DAC est désactivé par défaut lorsqu’un serveur Exchange à haute disponibilité est configuré. Il doit être activé pour tous les groupes de disponibilité de base de données ayant deux membres ou plus qui sont configurés pour utiliser la réplication continue.
Si un logiciel ou un matériel de réplication tiers est installé, il est conseillé de ne pas activer cette fonction. Il en va de même pour le mode de réplication tiers. Il n’est pas non plus supporté si votre DAG n’a qu’un seul membre dans le cluster.
Il faut également tenir compte du fait que le mode DAC peut être activé sur n’importe quel groupe de disponibilité de base de données existant dans un seul centre de données, bien qu’il soit peu probable qu’un dédoublement de cerveau se produise. Il est recommandé de l’activer car il y a toujours une possibilité que cela se produise. Le dédoublement de cerveau peut facilement se produire dans le cas d’une configuration multi-site où un serveur Exchange se trouve sur le site principal et les autres sur un autre site géographique pour la reprise après sinistre et la continuité de l’activité. Cela peut être dû à la latence, aux déconnexions ou même à une mauvaise configuration entre les sites.
Il est important de connaître ces éléments car il peut y avoir des problèmes si la configuration n’est pas correcte ou si elle n’est pas prise en charge. Vous n’aimeriez pas être confronté à une installation avec des journaux de transactions Exchange corrompus ou une inadéquation de la base de données entre le site et la perte de données. Si deux bases de données sont actives, vous aurez des problèmes de réplication et même d’intégrité des données.
Que faire en cas de cerveau divisé ?
Si le processus de dédoublement du cerveau se produit, les deux serveurs penseront qu’ils sont des serveurs actifs. Cela entraînera un bouleversement des données sur le site et une corruption de la base de données Exchange, voire un endommagement des bases de données ou des journaux.
Dans de tels cas, vous finirez par restaurer les serveurs à partir d’une sauvegarde, car la résolution du problème peut prendre un grand nombre d’heures. La restauration à partir d’une sauvegarde peut entraîner une perte de données, selon le moment de la journée où cela se produit. Il n’est pas agréable d’avoir des bases de données ou des journaux de transactions corrompus, car les bases de données ne se montent pas.
Vous pouvez utiliser ESEUtil pour effectuer une récupération rapide ou une récupération dure afin de résoudre le problème. Toutefois, la récupération en dur n’est pas recommandée car elle supprimera toutes les données considérées comme corrompues. Après toutes ces épreuves, il n’y a aucune garantie que la base de données soit remontée.
Une solution alternative
Des applications tierces de récupération Exchange, telles que Stellar Repair for Exchange, peuvent s’avérer pratiques dans de telles situations. Stellar Repair for Exchange peut ouvrir plusieurs bases de données Exchange Server de n’importe quelle version et dans n’importe quel état. Vous pouvez naviguer dans la base de données et exporter vers PST et d’autres formats de fichiers. Si la base de données Exchange n’est pas en cours de montage, vous pouvez facilement créer une nouvelle base de données et exporter directement de la base de données corrompue vers la nouvelle. Vous pouvez également exporter directement vers un locataire Office 365. L’application propose un mappage automatique ou manuel des boîtes aux lettres, une récupération parallèle des boîtes aux lettres, des exportations prioritaires VIP et la poursuite du processus en cas d’interruption. Le coût et la durée de la récupération sont ainsi réduits au minimum.
Was this article helpful?
