Translate

dimanche 1 mai 2016

Convertir un DAG classique en DAG sans point d'administration (et vice-versa)

Bonjour,


"It's been a while" (encore :)), comme le disent nos amis anglosaxons...
Aujourd'hui je voulais partager une technique permettant de convertir des groupes de disponibilité de base de données (autrement dit des Database Availability Groups, ou DAG) Exchange d'un mode "classique" (avec point d'administration, adresse IP + enregistrement DNS + objet ordinateur dans l'AD) à un mode "sans point d'administration".
Comme vous le savez, ce mode est supporté et recommandé depuis Exchange Server 2013 SP1/CU4 dès lors que le système d'exploitation utilisé est à la version Windows Server 2012 R2 ou ultérieure (rappel: il n'y a pas de version "ultérieure" supportée pour l'instant puisque Windows Server 2016 est toujours en Preview).
Les DAG sans point d'administration sont 200% recommandés pour des raisons très simples:
  1. Ils permettent d'éviter l'utilisation d'une ou plusieurs adresses IP (groupe du Cluster),
  2. Ils permettent d'éviter l'utilisation d'un objet dans l'AD (Cluster Network Object),
  3. Ils permettent d'éviter l'utilisation d'un enregistrement DNS pour le nom du DAG.
Bref, il permettent d'éviter tous les problèmes potentiels liés à un Cluster Windows classique... :)

La problématique de la conversion est qu'il n'est pas possible de changer de mode lorsque le Cluster Windows est déjà créé. Il s'agit d'une limitation des Clusters Windows et non d'Exchange.

Le principe est donc de partir d'un DAG existant (avec X membres et Y copies) et de supprimer le Cluster Windows sous-jacent, de reconfigurer le DAG puis de recréer le Cluster Windows sous-jacent. Afin d'en arriver là il faut passer par une phase où le DAG existe toujours mais où toute la haute disponibilité des bases de données n'existe plus:
  1. Supprimer toutes les copies de bases de données,
  2. Supprimer tous les membres du DAG.
Et, une fois le DAG reconfiguré, de:
  1. Rejoindre les serveurs au DAG,
  2. Recréer les copies.
L'avantage de cette technique est qu'elle peut s'exécuter à chaud, sans démontage des bases de données. Cependant il existe forcément un état à un instant T pendant lequel il n'existe plus qu'une copie de chaque base de données. Même si ce temps est relativement court (quelques minutes, max 5 tout au plus - le temps de rejoindre les membres et de recréer les copies), cela peut ne pas être jugé acceptable. Si tel est le cas, la seule option est de migrer vers un nouveau DAG. Hélas, cette option n'est pas toujours possible car cela demande de réinvestir.

Pour les personnes ayant donc installé un DAG sur Windows Server 2012 R2 avant Exchange 2013 SP1/CU4, et/ou n'ayant pas initialement voulu "tenter" le mode "DAG sans point d'administration", un peu d'automatisation peu permettre de faire la conversion en un minimum de temps et sans erreur.

Voici donc un petit script permettant d'effectuer la conversion d'un DAG classique vers un DAG sans point d'administration - ce script est aussi capable de faire l'inverse (même si je trouve l’intérêt de faire le chemin inverse limité...).

Le script prend soin de récupérer les paramètres existants du DAG et des copies:

  • mode DAC (DatacenterActivation DagOnly)
  • réseaux du DAG (Database Availabiltiy Group Networks)
  • désactivation puis restauration du Circular Logging (ex: pour les DAGs sans sauvegarde)
  • copies décalées (ReplayLagTime et/ou TruncationLagTime)
  • ordre de préférence d'activation (ActivationPreference)
  • et pour les DAGs Exchange 2016 CU1 ou +, le gestion du ReplayLagMaxDelay
Utilisation:

.\Convert-DatabaseAvailabilityGroup.ps1 -Identity -Verbose -- conversion vers un DAG sans point d'administration

ou 

.\Convert-DatabaseAvailabilityGroup.ps1 -Identity -DatabaseAvailabilityGroupIpAddresses 255.255.255.255 -Verbose -- conversion vers un DAG sans point d'administration

A l'inverse:

.\Convert-DatabaseAvailabilityGroup.ps1 -Identity -DatabaseAvailabilityGroupIpAddresses 0.0.0.0 -Verbose -- conversion vers un DAG avec point d'administration mais utilisant DHCP

.\Convert-DatabaseAvailabilityGroup.ps1 -Identity -DatabaseAvailabilityGroupIpAddresses [, IP2, IP3...] -Verbose -- conversion vers un DAG avec point d'administration et une ou plusieurs adresses IP statiques

Le script est disponible ici.

2 commentaires:

  1. You must read this before running any script. It is neither supported or recommended.

    Converting an Existing DAG
    In WFC, you can configure administrative access point settings only when you create a cluster. Thus, a DAG with one or more members cannot have its configuration changed from having an AAP to not having an AAP, or vice versa. There is no supported way to do this because WFC does not support it. So don’t even try it. But, I know some of you will anyway, so…

    If you have a DAG with members without an AAP, and you use Set-DatabaseAvailabilityGroup to try to assign it an IP address or configure it to use DHCP, you will get a warning and an error message similar to the following:

    WARNING: An unexpected error has occurred and a Watson dump is being generated: Some or all identity references could not be translated.
    Some or all identity references could not be translated.
    + CategoryInfo : NotSpecified: (:) [Set-DatabaseAvailabilityGroup], IdentityNotMappedException
    + FullyQualifiedErrorId : System.Security.Principal.IdentityNotMappedException,Microsoft.Exchange.Management.SystemConfigurationTasks.
    SetDatabaseAvailabilityGroup
    + PSComputerName : ex4.e15demos.com

    https://blogs.technet.microsoft.com/scottschnoll/2014/02/25/windows-server-2012-r2-and-database-availability-groups/

    RépondreSupprimer
  2. Dear Prabhat,

    I am perfectly aware of the supportability statement. Actually, you should read my blog post twice because you'd realize I am doing it the supported way. As Scott said, a DAG can't be converted while the underlying cluster still exists. This is the limitation because the cluster's mode can't be changed.

    That said, my technique consists in temporarily "destruct" the DAG, including removing all DAG members (which clears the cluster), change mode and then re-add DAG members, DB copies (without even a full reseed) and indeed restores DB copies as they should.

    In addition, I am taking care of the FSW (which is not removed when the cluster is destructed) because since the CNO no longer exist the FSW permissions must be changed to allow each individual nodes, and no longer the CNO... FSW (and Alternate, if it existed) are then recreated when the DAG is reformed.

    For the records, this script has been submitted to a PMC/PFE Microsoft team with positive feedback. Yet, Microsoft will never support a third-party's script they told us the approach was the right one. We thereafter converted all DAGs (4) from geo-streched DAGs (2 IPs) to DAGwAAP in a few minutes. No impact for the end-users, only a few copies had some difficulties to reconcile their Context Index State, we had to enforce catalog update but that's nothing more than a basic operation task.

    So once again, please read everything before taking too fast routes and wrong conclusions...

    Best regards,
    Benoit.

    RépondreSupprimer