Archive

Posts Tagged ‘DAG’

Exchange 2010 – Vérifier l’état du DAG

Un peu de théorie avant d’aborder la pratique :

Le DAG (Data Availability Group ou encore Groupe de Disponibilité de Base de Données)  est le composant de base de l’architecture de haute disponibilité et de résilience de site intégrée à Exchange 2010. Un DAG est un groupe pouvant être formé d’un maximum de 16 serveurs de boîtes aux lettres qui hébergent un ensemble de bases de données et assurent une récupération automatique au niveau de la base de données à la suite de défaillances affectant des bases de données individuelles. N’importe quel serveur d’un groupe de disponibilité de base de données peut héberger une copie de base de données de boîtes aux lettres provenant d’un serveur quelconque du groupe de disponibilité de base de données. Lorsqu’un serveur est ajouté à un groupe de disponibilité de base de données, il fonctionne avec les autres serveurs du groupe pour assurer la récupération automatique à la suite de défaillances affectant des bases de données de boîtes aux lettres, par exemple la défaillance d’un disque ou d’un serveur.

De manière générale, un DAG est un élément particulièrement stable de l’architecture Exchange et à moins d’une saturation du disque contenant les logs (un grand classique) une grosse panne réseau ou d’un méchant crash serveur, il est assez rare de voir un DAG  se prendre les pieds dans le tapis.

Une des taches importantes de tout administrateur Exchange est donc de veiller à ce que le DAG se maintienne en bonne santé. Quelques contrôles réguliers suffisent généralement à éviter les gros problèmes :

  1. Surveiller l’espace disque disponible (notamment sur les disques contenant les log et les bases)
  2. S’assurer que tous les services sous jacents sont opérationnels sur l’ensemble des serveurs du DAG
  3. S’assurer que toutes les copies de bases de données sont saines

Pour le premier point, vous avez l’embarras du choix :

  • un coup d’oeil régulier sur les serveurs
  • un script planifié
  • application type SCOM (Microsoft System Center Operation Manager) ou tout autre application de monitoring (y en a des tas de gratuites)

Pour le deuxième et le troisième point:

  • La méthode manuelle en Powershell :

Vérifier que tous les services du DAG sont opérationnels (attention, les parenthèses sont importantes)

(Get-DatabaseAvailabilityGroup -Identity DAG).servers | Test-ReplicationHealth

dag-test-replication

 

Si une erreur est signalée (c’est assez rare, je vous rassure), c’est qu’un service est probablement arrêté ou qu’il est temps d’appeler le plombier 🙂

Vérifier que toutes les copies de bases de données sont saines :

(Get-DatabaseAvailabilityGroup -Identity DAG).servers | foreach {Get-MailboxDatabaseCopyStatus -Server $_.Name} |  Select Name, Status, ContentIndexState

dag-get-mailboxdatabasecopystatus

Quand tout va bien, la colonne Status affiche Healthy (pour les copies passives) ou Mounted (pour la copie active). Il arrive assez souvent de voir un ContentIndexState afficher Failed. Rien de bien méchant : en général, la suspension puis la remise en route de la réplication suffit à faire disparaître l’erreur.

  • L’utilisation d’un script plus élaboré  :

Le plus répandu est probablement l’excellent Get-DAGHealth de Paul Cunningham que vous pourrez télécharger sur son site.

L’exécution du script produit un fichier HTML donnant un bilan très complet de l’état de santé de votre DAG.

get-daghealth-output

Quelque soit la méthode utilisée, l’important est de ne pas négliger la surveillance de votre environnement. L’adage « prévenir  vaut mieux que guérir » prend ici toute sa dimension :-).

Bonne chance à tous.

Publicités
Catégories :Exchange, Powershell, Scripts Étiquettes : ,

Exchange 2010 multi-roles et Haute Disponibilité (Part 1/2)

Question : on met à votre disposition 2 serveurs pour déployer une plate-forme Exchange 2010 hautement disponible. Quelle solution proposez vous ?

La première réponse qui vient à l’esprit est :

  1. installer Exchange 2010 en multi-roles (Mailbox, Hub et Cas) sur les deux serveurs
  2. configurer un DAG pour la haute disponibilité des bases de données
  3. créer un CAS Array
  4. mettre en place NLB pour la haute disponibilité des CAS et pointer le Cas Array sur l’adresse ip virtuelle NLB.

Pas mal, mais il y a un hic de taille : on ne peut malheureusement pas installer la fonctionnalité Windows Network Load Balancing (NLB) sur un serveur qui est deja membre d’un DAG. Il s’agit la d’une limitation Windows qui fait qu’il n’est tout simplement pas possible de mixer du Failover Clustering (utilisé par le DAG) avec du Clustering NLB sur un même serveur.

C’est d’ailleurs pour cela que les premières architectures HA Exchange 2010 s’appuyaient le plus souvent sur des modèles à 4 serveurs (2 serveurs CAS/HUB en NLB et 2 serveurs MBX en DAG).

Ce qu’on retient donc pour l’instant :

  • la mutualisation des rôles n’a pas d’intéret particulier (sauf dans un environnement mono serveur bien sur)
  • pour une haute disponibilité de tous les rôles, 4 serveurs au minimum sont requis.

Lors du TechEd 2010, Microsoft change quelque peu son fusil d’épaule et cesse de recommander Windows NLB comme mécanisme de haute dispo pour les CAS. Voir slide ci dessous. La présentation complète est disponible ici en téléchargement (PPTX, 7,5MB).

 

Load_balancing_recommendations

 Load_balancing_recommendations_2

La recommandation est claire et sans équivoque : Utilisez donc un Load balancer (répartiteur de charge). La liste des équipements validés par Microsoft peut être consultée sur le site de l’éditeur.

A partir de la, les architectures Exchange 2010 HA de référence changent et les modèles à base de serveurs multi-roles font leur apparition (NLB n’etant plus la pour jouer les troubles fêtes). Microsoft recommande même clairement d’opter pour un modèle à base de serveurs multi-roles avec pour arguments : une meilleur utilisation des ressources et une simplification du déploiement. Voir ref :

A l’époque cependant, Load Balancer est encore souvent synonyme de F5 Big-IP et autres Citrix Netscaler pour ne citer que ceux la, des produits réputés pour être budgetivores et donc réservés aux grands comptes. Fort heureusement, c’était sans compter sur l’arrivée de constructeurs comme KEMP Technologies ou encore Barracuda Networks (il y en a d’autres bien sur) qui ont mis sur le marché des équipements tout à fait convenables et à des prix abordables, mettant ainsi le load balancer à la portée de tous.

Malgré cela, nous continuons à recevoir encore et encore des demandes pour le déploiement de plate-forme Exchange 2010 haute dispo avec dans les cartons deux serveurs et basta. Force est de constater que malgré la baisse des prix, l’usage de load balancers n’est toujours pas entré dans les moeurs.

Beaucoup d’articles sur internet traitent du problème de haute dispo dans les environnements Exchange 2010 à base de serveurs multi-role. Cela va de la mise en oeuvre de DNS Round Robin à la mise en place de scripts Powershell permettant de changer à la volée l’adresse du CAS Array en cas d’indisponibilité d’un des serveurs.

Il existe cependant une manière originale et très simple de régler controurner le problème. Et c’est paradoxalement, la moins documentée.

Nous donnerons le détails de cette mise en oeuvre dans la seconde partie de cet article. Désolé, vous allez devoir patienter quelques jours encore 🙂 D’ici la, tous vos commentaires sont les bienvenus.

En attendant, je vous recommande quelques lectures intéressantes sur le sujet :

A la semaine prochaine.

Microsoft Exchange 2010 on VMWare–Availability and Recovery Options

exchange2010

Ce document signé VMWare présente l’intérêt de la fonction HA (de VMWare) en environnement DAG (Exchange 2010). Autant vous le dire tout de suite, ce document a été plutôt mal reçu par les équipes Microsoft en charge d’Exchange qui préviennent que ce type de configuration (cocktail HA + DAG) ne sera pas supporté par Microsoft.

Télécharger le document (.PDF, 1.5 MB)

Plus d’infos :

Catégories :ebooks, Exchange, Virtualisation Étiquettes : , ,