Un cluster DAG (Database Availability Group) dans l’environnement Exchange Server est un élément clé de la résilience des données et de la haute disponibilité des services Exchange Server. Si quelque chose arrive au serveur principal, les services et les données ne sont pas affectés et les utilisateurs ne subissent pas de temps d’arrêt. Pour ce faire, il existe un processus appelé basculement, au cours duquel la copie active de la base de données est déplacée vers un autre serveur du DAG. Dans cet article, nous allons procéder étape par étape pour garantir la certitude et la réussite du basculement du serveur du groupe de disponibilité des bases de données (DAG).
Pourquoi devez-vous effectuer la migration ?
Il y a plusieurs raisons pour lesquelles vous pouvez avoir besoin d’effectuer une migration. Examinons les raisons les plus courantes.
La maintenance planifiée est le facteur le plus courant lorsque les administrateurs doivent remplacer/mettre à niveau ou réparer le matériel ou la mémoire du serveur. Cela se produit également lors de la maintenance de logiciels nécessitant un redémarrage.
Les tests de basculement sont généralement effectués pour répondre aux listes de contrôle des entreprises et de la conformité et pour s’assurer que le document de continuité des activités et le document de récupération des données sont à jour en cas d’incident. Il permet également de s’assurer que le basculement fonctionne comme prévu.
L’équilibrage de la charge est effectué lorsque le serveur principal doit être remplacé parce qu’il ne peut pas gérer la charge et que les services/accès aux données doivent être déplacés vers un autre nœud/matériel plus puissant.
Une récupération des données est effectuée en cas de problèmes avec le serveur actuel et les administrateurs doivent passer à un autre serveur jusqu’à ce que le problème soit résolu.
Conditions préalables au basculement du serveur DAG
Normalement, il n’y a pas de conditions préalables à remplir, car tout devrait fonctionner normalement. Mais si une maintenance ou un temps d’arrêt est réservé, vous devez toujours effectuer les tests suivants pour vous assurer que tout fonctionne comme il se doit avant de procéder au basculement.
Étape 1 – Vérifier l’état de santé des serveurs membres
Pour ce faire, vous devez vous assurer que tous les serveurs Exchange de la grappe sont en bon état et qu’il n’y a aucun problème. Pour vérifier l’état du groupe de disponibilité de la base de données (DAG), vous pouvez utiliser la commande suivante :
Get-MailboxServer| Test-ServiceHealthCopy Code
Étape 2 – Vérifiez la réplication des bases de données
Si la réplication des bases de données est défectueuse, les données ne sont pas à jour. Pour confirmer que le transfert de données fonctionne correctement et que les bases de données sont synchronisées, vous pouvez utiliser la commande suivante :
Get-MailboxDatabaseCopyStatusCopy Code
Étape 3 – Vérification de la connexion et de la portée du réseau
La communication entre les serveurs Exchange via le réseau cluster et le réseau client doit être claire et rapide. Pour le confirmer, vous pouvez vérifier auprès de l’équipe réseau si les serveurs se trouvent dans des bureaux différents. En cas de problème, la migration ne sera pas couronnée de succès.
Étape 4 – Vérifier les journaux de transactions
Vous devez vous assurer que les journaux de transactions sont correctement répliqués et tronqués. La synchronisation des données repose sur l’envoi des journaux. Vous pouvez exécuter les commandes suivantes pour vérifier que tout est en ordre.
Test-ReplicationHealth -Server <MailboxServer> Copier le code
Get-MailboxDatabaseCopyStatus -Identity <nom de la base de données> Code de copie
Pour réussir la migration, vous devez bien planifier et vous assurer que tout est en ordre. Si les tests ci-dessus sont concluants, vous pouvez passer aux étapes suivantes.
Étape n°1 – Confirmer les bases de données des boîtes aux lettres actives
Vous devez afficher la base de données de boîtes aux lettres active sur le serveur et voir également quelles bases de données peuvent être déplacées vers un autre serveur, car le serveur peut héberger des copies de bases de données d’un autre serveur. Pour ce faire, vous pouvez utiliser la commande suivante :
Get-MailboxDatabase | Format-Table Name, ServerCopy Code
Étape 2 – Déplacer les bases de données actives vers le serveur cible
Vous pouvez utiliser la commande suivante pour déplacer les bases de données actives spécifiées sur le serveur cible. Cela transformera les bases de données actives en copies et la base de données copiée sera marquée comme active après le contrôle de synchronisation.
Move-ActiveMailboxDatabase -Identity <DatabaseName> -ActivateOnServer < TargetServer> -Confirm:$falseCopy Code
En fonction de l’utilisation, des performances et de la taille de la base de données de boîtes aux lettres, cette opération peut prendre un certain temps.
Pour surveiller le basculement, vous pouvez utiliser la commande suivante :
Get-MailboxDatabaseCopyStatus -Identity <nom de la base de données> Copy Code
Étape 3 – Test de l’accès client
Après le transfert, il est important que vous effectuiez quelques tests pour vous assurer que tout fonctionne correctement. Cela comprend les points suivants :
Testez l’accès à la boîte aux lettres via Outlook Web Access (OWA).
Testez l’accès à la boîte aux lettres via Microsoft Outlook/appareil mobile.
Vérifiez le trafic des courriels en contrôlant les files d’attente.
Assurez-vous que les services Exchange Server fonctionnent.
Si tout s’est bien passé, vous pouvez mettre le serveur concerné en mode maintenance. Vous vous assurez ainsi que les travaux effectués sur le serveur n’affectent pas les utilisateurs et les autres opérations. Cela permet aux administrateurs de résoudre les problèmes ou d’effectuer les travaux de maintenance.
Que se passe-t-il en cas de problème ?
De nombreux problèmes peuvent survenir au cours de ce processus si les conditions préalables ne sont pas remplies et s’il y a des problèmes de réplication entre les serveurs. Vous devez également tenir compte du fait qu’un basculement peut se produire automatiquement si un problème survient, comme par exemple
une panne matérielle
Installation d’un logiciel tiers incompatible
une panne d’électricité soudaine
attaques malveillantes
manque d’espace de stockage libre.
Tous ces problèmes peuvent affecter l’intégrité des données et la disponibilité des bases de données. Si le serveur est inaccessible ou endommagé, il est facile de le remettre en état. Si, après un sinistre ou une mauvaise configuration, les journaux de transactions ou la base de données d’Exchange Server sont corrompus ou ne sont pas synchronisés, vous pouvez utiliser ESEUtil. Toutefois, cette opération peut prendre du temps et s’avère souvent infructueuse.
Alternativement, vous pouvez compter sur des outils de récupération de données Exchange spécialisés qui peuvent atténuer les défis ci-dessus. Stellar Repair for Exchange est l’un de ces outils qui peut ouvrir des bases de données dans n’importe quel état, taille et version d’Exchange Server indépendamment, même si le serveur Exchange n’est pas en cours d’exécution. Après avoir ouvert la base de données, vous pouvez exporter de manière granulaire les boîtes aux lettres des utilisateurs, les boîtes aux lettres partagées, les archives des utilisateurs, les boîtes aux lettres désactivées et les dossiers publics vers un fichier PST ou d’autres formats. Après avoir reconstruit le serveur, vous pouvez facilement exporter les données EDB vers une base de données Exchange Server active ou un locataire Microsoft 365 avec synchronisation automatique des boîtes aux lettres.
Conclusion
Il est très important que tout soit en ordre si vous devez procéder à un changement en cas de catastrophe ou d’autres problèmes. Il est important de surveiller et d’entretenir le cluster Exchange Server et de veiller à ce que les problèmes (le cas échéant) soient résolus immédiatement. De même, en cas de sinistre, vous devez vous assurer que vous disposez des bons outils pour remettre en état les services et les données dans les plus brefs délais et avec un impact minimal sur le Business.
