Les serveurs Exchange 2010 pourraient-il devenir schizophrènes. En quelque sorte…. La réponse est Oui. Mais rassurez-vous le DACP veille ;-)
J’ai donc traduit pour une meilleure compréhension l’article du TechNet suivant (http://technet.microsoft.com/en-us/library/dd979790.aspx). Ce dernier me parait très important spécialement si vous envisager de mettre en place une même architecture Exchange répartie dans deux centres de données.
Bonne lecture !
Le mode de coordination d’activation de centre de données (Datacenter Activation Coordination Mode) est une propriété mise en place sur un Groupe de Disponibilité de Bases de données (DAG). Le mode Dac est désactivé par défaut et doit être activé pour tous les Groupes de Disponibilité de Bases de données (DAG) qui utilisent la réplication continue. Le mode DAC ne doit pas être activé pour les Groupes de bases de données qui utilisent la réplication tierce partie sauf sur recommandations par l’éditeur en question.
Si un panne importante provient et qui affecte le Groupe de bases de données (Par exemple une panne générale d’un des centres de bases de données), le mode DAC est utilisé pour contrôler le comportement de l’activation au sein du DAG. Lorsque le mode DAC n’est pas activé et qu’une panne survient affectant plusieurs serveurs dans le groupe de base de données, ce comportement peut engendrer un split Brain Syndrome, une condition qui provient lorsque tous les réseaux ne sont plus disponibles, et que les membres du DAG ne peuvent pas recevoir des signaux de vie (HeartBeat) des autres membres. Le Split Brain Syndrome, peut également se produire lorsque la connectivité réseau n’est plus disponible entres les centres de données.
Le phénomène de Split Brain Syndrome peut toujours être évité en requérant la disponibilité de la majorité des membres du groupe de disponibilité (Et dans le cas de Dag qui ont un nombre pair de membre, avec l’utilisation de témoin de partage de fichier) et en interagissant, afin que le groupe de base de données soit opérationnel. Lorsque la majorité des membres communiquent, on dit alors que le groupe de disponibilité possède le quorum.
Par exemple, considérons un scénario ou le premier centre de données contenant deux membres d’un groupe de disponibilité de bases de données et un témoin de partage de fichier , et un second centre de données contenant deux autres serveurs membres du groupes de disponibilités de base de données. Si le premier centre de données est remis en route sans connectivité réseaux vers le second centre de donnés, le groupe de disponibilité peut entrer en mode splitbrain syndrome.
Comment fonctionne le mode DAC (coordination d’activation de centre de données)
Le mode DAC a été conçu pour éviter qu’un syndrome SplitBrain ne puisse survenir, en incluant le protocole DACP (Datacenter Activation Coordination Protocol). Après une panne majeure lorsque le groupe de disponibilité de base de donnés remonte, il ne va pas remonter automatiquement les bases de données sauf dans le cas où le Dag possède le quorum. Dans le cas contraire, le protocole DACP est utilisé pour déterminer l’état en cours du groupe de disponibilité de bases de données et si le processus Active Manager doit tenter de monter les bases de données.
On pourrait penser que le mode DAC se rapproche d’un niveau applicatif lié au quorum dans le but de monter les bases de données. . Afin de bien comprendre le but du DACP et comment ce dernier fonctionne, il est important de prendre en compte le premier scenario décrit ci-dessus.
Considérant deux centre de données, en supposant qu’un panne complète de courant se produise dans le premier centre de données, dans ce cas de figure tous les serveurs et l’interconnexion réseau seront arrêtés. L’organisation va donc décider d’activer le second centre de données considéré comme "de secours". Dans la plupart des cas, lors des opérations de remise en route, lorsque l’électricité va revenir dans le premier centre de données, les liens d’interconnexion réseau risquent de ne pas être opérationnels. Cela implique donc que les membres du groupe de disponibilités dans le centre de données primaire vont démarrer mais ne seront pas capable de communiquer avec les autres membres du Groupe de Disponibilité de base de données s’exécutant dans le centre de secours. Or les membres du Groupe de disponibilité de bases de données du premier centre posséderont la majorité et par conséquent le quorum. Ceci pose donc un problème car ces serveurs vont tenter de monter les bases de données, ce qui va provoquer une divergence vis à vis des bases de données déjà actives sur le site de secours.
Le protocole DACP a donc été créé dans ce but. Active Manager va stocker un Bit en mémoire (0 ou 1) qui va informer le DAG, lui permettant de savoir s’il est dans la position de monter ou pas les bases de données locales assignées comme « active » sur ce server. Lorsque le groupe de disponibilité de base de données s’exécute en mode DAC (Ce qui peut être n’importe quel groupe de disponibilité de base de données comprenant 3 membres ou plus), alors, chaque fois que le processus Active Manager démarre, il positionne le bit à zéro, précisant qu’il n’est pas autorisé à monter les bases de données. Parce ce que l’on est en mode Dac, le serveur doit essayer de communiquer avec les autres membres du groupe de disponibilité de base de données qu’il connait de façon à obtenir une réponse lui permettant de savoir si il peut ou non monter les bases de données qui lui sont assignée comme actives.
La réponse viendra par conséquent de la valeur assignée au bit en question par les processus Active manager des autres serveurs du DAG. Si les autres serveurs répondent que la valeur du Bit est à 1, cela précise qu’il est possible de monter les bases de données, le serveur démarrant, va positionner le bit à 1 et monter ces bases de données.
Lorsque l’on remet en route un centre de données après un dommage électrique et lorsque les serveurs remontent sans interconnexion possible sur le réseau étendu, tous les membres du groupe de disponibilité de base de données du centre de données primaire vont avoir comme Bit liés au protocole DACP la valeur 0. Ainsi, aucun des serveurs du centre de données primaire ne va tenter de monter les bases de données en question, car aucun d’entre eux n’est capable de communiquer avec des membres du groupe de disponibilité de base de données ayant une valeur égale à 1.
Le Mode Dac avec un groupe de disponibilité de base de données comprenant uniquement deux membres.
Les groupes de disponibilité comprenant uniquement deux membres ont des limitations intrinsèques qui permettent au protocole DACP d’être totalement protégé vis à vis du syndrome de type splitbrain. Pour les Groupes de disponibilité de base de données ne comprenant que deux membres, le mode Dac utilise également les informations de temps liés au démarrage du serveur témoin de partage de fichier afin de déterminer s’il est dans la mesure de monter ou non les bases de données. L’heure de démarrage du serveur de témoin du partage de fichier est alors comparée à l’heure ou le bit de DACP a été positionné à 1.
- Si le moment ou le bit DACP précède le moment de démarrage du serveur témoin, le système va estimer que le serveur du dag en question et que le serveur témoin de partage de fichier ont été redémarré au même moment (Vraisemblablement dans le cas d’un problème d’alimentation électrique du premier centre de données), et dans ce cas les serveurs membre du dag ne seront pas autorisés à monter les bases de données.
- Dans le cas contraire, ou le moment ou le bit du DACP succède le moment de démarrage du serveur témoin, le système va estimer que le membre du groupe de disponibilité de bases de données a été redémarrer pour d’autre raisons (Eventuellement un arrêt programmé dans le cas d’un maintenance, un crash server ou une panne de courant local a ce dernier) et le membre du groupe sera donc autorisé a monté les bases de données
IMPORTANT
En raison du fait que l’heure de démarrage du serveur témoin de partage de fichier est prise en compte pour déterminer si un membre du DAG est en mesure de monter ses bases Actives on démarrage, vous ne devez jamais redémarrer le serveur témoin de partage de fichier et le membre du DAG au même moment. Si cela se produisait, le membre du Dag serait dans un état ou il ne pourrait pas monter les bases. Dans ce cas précis vous devez utiliser la commande PowerShell Restore-DatabaseAvailabilityGroup
sur le DAG en question. Cette commande aura pour effet de paramétrer le Bit du DACP et permettre au membre du DAG de monter ses bases de données.
La prochaine fois on essayera d’illustrer cela dans le cadre d’un exemple concret
Cordialement
Laurent Teruin
Anthony Costeseque
Arnaud DUTEIL
Frédéric Laubel
Teruin laurent
David ANDRE
David PEKMEZ
Yohan Boullier
