Exchange your Mind

"La connaissance ne vaut que si elle est partagée" / "An effective Knowledge is a shared one"

Archive for the ‘Cluster-2010’ Category

Exchange : Correctif KB2550886 pour Windows 2008 R2 / R2SP1

Posted by Teruin laurent le novembre 23, 2011


KB2550886 – A transient communication failure causes a Windows Server 2008 R2 failover cluster to stop working

Le correctif proposé corrige des problèmes de de verrouillage de cluster en cas de problématique réseau. Il est vivement conseillé sur des infrastructures étendues sur deux sites distants. Dans le cas contraire le patch est malgré tout recommandé mais moins vital que pour les infrastructures réparties sur deux centres de données.

Dans le cas ou des perturbations réseaux sont rencontrées par Windows Failover cluster, la logique de reconnexion des nœuds du cluster engendrerai un blocage de la base de données du cluster ayant pour conséquence une perte des services de basculement.

Les équipes de Microsoft confirment avoir rencontré ces scénarios de blocage lors de perte de connexion réseau avoisinant les 60 Secondes. La résultante étant un blocage complet (deadLock) de l’intégralité du cluster avec pour conséquence un arrêt de toutes les bases de données.

Comme il n’est pas évident de déterminer quels nœuds du cluster sont effectivement bloqués (deadlockés) la seule solution est de redémarrer l’ensemble des membres du DAG afin de résoudre ce "verrou mortel".

Le patch ainsi délivré permet de résoudre ce problème et comprend les correctifs suivants:

http://support.microsoft.com/kb/2549472 – Cluster node cannot rejoin the cluster after the node is restarted or removed from the cluster in Windows Server 2008 R2
http://support.microsoft.com/kb/2549448 – Cluster service still uses the default time-out value after you configure the regroup time-out setting in Windows Server 2008 R2
http://support.microsoft.com/kb/2552040 – A Windows Server 2008 R2 failover cluster loses quorum when an asymmetric communication fail

Il est à noter que ce correctif concerne également les clusters répartis en environnement Exchange 2007 reposant sur les technologies SCC et CCR. Par contre ne sont concerné que ceux fonctionnant dans l’environnement Windows 2008 R2 ou Windows 2008 R2 SP1.

A l’installation nous avons rencontré le problème suivant : Installer Encountered an error : 0X80070422


Ceci est dû au fait que les services BIT et Windows Update étaient arrêtés

Cordialement
Laurent Teruin

 

Posted in 1-EXCHANGE 2010, Cluster-2007, Cluster-2010, Exchange 2010 Service Pack 1, Windows Server 2008 R2 | Leave a Comment »

Un patch pour les DAG

Posted by Anthony Costeseque le novembre 22, 2011


Bonjour,

Voici un patch qu’il est fortement recommandé d’installer sur vos serveurs MBX en cluster (DAG).

Sur tout destiné aux configurations multisites, il ne fera cependant pas de mal à toutes les configurations (DAG).

Le patch est à télécharger ici : KB2550886 – A transient communication failure causes a Windows Server 2008 R2 failover cluster to stop working

Plus de détails ici : http://blogs.technet.com/b/exchange/archive/2011/11/20/recommended-windows-hotfix-for-database-availability-groups-running-windows-server-2008-r2.aspx

Cordialement,

Anthony COSTESEQUE

Posted in Cluster-2010, Exchange 2010 Service Pack 1, Exchange Server 2010 | Leave a Comment »

Exchange 2010 : Error getting mailbox database copy status from server .. use -SkipActiveCopyChecks

Posted by Teruin laurent le octobre 11, 2011


Introduction

Dans un environnement Exchange 2010 vous avez pu constater un cas de figure ou votre Dag à trois nœuds par exemple ne basculait pas en cas de panne des deux autres. Ceci ce produit si le serveur Exchange qui reprend les bases de données ne possède pas la majorité au sein du cluster.

Dans notre cas, nous avons positionné un cluster à trois nœuds avec un File Share Witness. Dans le cas d’un arrêt des deux serveurs sur le site principal voici la situation que nous avons constatée.


Le troisième serveur Exchange trouve le FileShareWitness mais ne montera pas les bases de données. Le dag comprenant trois nœuds plus un FSW ; lorsque les deux nœuds MRSEXC01, et MRSEXC02 sont arrêtés le serveur MRSEXC03 et le FSW ne forme que 50% du cluster. La remontée des bases de données doit donc être manuelle.

Pour Information notre configuration ne prenait pas en compte l’activation du mode Dag. Pour connaitre si votre DAG utilise le Mode d’activation Datacenter utiliser la commande suivante :

Get-DatabaseAvailabilityGroup | fl

RunspaceId : 04cb9450-f690-4cb4-a2c6-19f55c2e51ca

Name : MRSDAG01

Servers : {MRSEXC03, MRSEXC02, MRSEXC01}

WitnessServer : mrsscom01.unifiedit.priv

WitnessDirectory : F:\FSW-EX2K10-MRSDAG01

AlternateWitnessServer :

AlternateWitnessDirectory :

NetworkCompression : InterSubnetOnly

NetworkEncryption : InterSubnetOnly

DatacenterActivationMode : Off

StoppedMailboxServers : {}

StartedMailboxServers : {}

DatabaseAvailabilityGroupIpv4Addresses : {172.16.18.20}

DatabaseAvailabilityGroupIpAddresses : {172.16.18.20}

AllowCrossSiteRpcClientAccess : False

OperationalServers :

PrimaryActiveManager :

ServersInMaintenance :

ThirdPartyReplication : Disabled

ReplicationPort : 0

NetworkNames : {}

WitnessShareInUse :

AdminDisplayName :

ExchangeVersion : 0.10 (14.0.100.0)

DistinguishedName : CN=MRSDAG01,CN=Database Availability Groups,CN=Exchange Administrative Group

Exchange,CN=Services,CN=Configuration,DC=unifiedit,DC=priv

Identity : MRSDAG01

Guid : f1d389be-c78a-4e2a-8b39-14f3d9c1724e

ObjectCategory : unifiedit.priv/Configuration/Schema/ms-Exch-MDB-Availability-Group

ObjectClass : {top, msExchMDBAvailabilityGroup}

WhenChanged : 9/21/2011 4:28:42 PM

WhenCreated : 9/21/2011 4:28:42 PM

WhenChangedUTC : 9/21/2011 2:28:42 PM

WhenCreatedUTC : 9/21/2011 2:28:42 PM

OrganizationId :

OriginatingServer : MRSINF2K01.unifiedit.priv

IsValid : True

 

Si vous tentez de monter une base de données vous allez rencontrer l’erreur suivante :

[PS] C:\Windows\system32>Move-ActiveMailboxDatabase MRSDB01 -ActivateOnServer MRSEXC03 -MountDialOverride:GoodAvailability -confirm:$confirm

Error getting mailbox database copy status from server "mrsexc01". You can use -SkipActiveCopyChecks
to skip this validation check. Error: A server-side administrative operation has fa

iled. The Microsoft Exchange Replication service may not be running on server MRSEXC01.unifiedit.priv. Specific RPC error message: Error 0x71a (The remote procedure call was cancelled) f

rom cli_GetCopyStatusEx2

+ CategoryInfo : InvalidOperation: (MRSEXC01.unifiedit.priv:String) [Move-ActiveMailboxDatabase], ErrorMoveUnableToGetCopyStatusException

+ FullyQualifiedErrorId : 62FFCB32,Microsoft.Exchange.Management.SystemConfigurationTasks.MoveActiveMailboxDatabase

 

Remonter Les bases de données sur le serveur restant

 

Pour correctement monter la base de donnée sur le serveur du Dag restant vous devez utiliser les commandes suivantes sur le serveur restant

 

net stop clussvc
net start clussvc /forcequorum
Move-ActiveMailboxDatabase -SkipActiveCopyChecks -SkipLagChecks -MountDialOverride:besteffort -SkipClientExperienceChecks -ActivateOnServer MRSEXC03 -identity MRSDB03 -confirm:$confirm

 

On notera que dans cette commande, nous activons la base de données quelques soit le nombre de journaux perdus grâce au paramètre « MountDialOverride:besteffort »

Retour à la normal

Dans le cas précis nous allons remonter le serveur MRSEXC01 et vérifier le comportement de notre Dag


Comme vous pouvez le voir le serveur MRSEXC01 est de nouveau en ligne et la réplication est active. La Base est marqué comme Saine (Healthy) et pourra de nouveau être activée.

Je vous conseille d’utiliser un script Powershell pour repositionner les bases de données sur les serveurs qui ont remonté.

Move-ActiveMailboxDatabase MRSDB01 -ActivateOnServer MRSEXC01 -MountDialOverride:GoodAvailability -confirm:$confirm
Move-ActiveMailboxDatabase MRSDB03 -ActivateOnServer MRSEXC01 -MountDialOverride:GoodAvailability -confirm:$confirm
Move-ActiveMailboxDatabase MRSDB05 -ActivateOnServer MRSEXC01 -MountDialOverride:GoodAvailability -confirm:$confirm
Move-ActiveMailboxDatabase MRSDB07 -ActivateOnServer MRSEXC01 -MountDialOverride:GoodAvailability -confirm:$confirm
Move-ActiveMailboxDatabase MRSDB02 -ActivateOnServer MRSEXC02 -MountDialOverride:GoodAvailability -confirm:$confirm
Move-ActiveMailboxDatabase MRSDB04 -ActivateOnServer MRSEXC02 -MountDialOverride:GoodAvailability -confirm:$confirm
Move-ActiveMailboxDatabase MRSDB06 -ActivateOnServer MRSEXC02 -MountDialOverride:GoodAvailability -confirm:$confirm

 

Cordialement
Laurent Teruin

Posted in 1-EXCHANGE 2010, Cluster-2010 | Leave a Comment »

Validation de la configuration du Cluster Exchange 2010

Posted by Teruin laurent le octobre 4, 2011


 

  1. Introduction

La mise en place d’un environnement Exchange doit être suivie d’une phase de validation qui comprend plusieurs étapes. Au cours de cette série nous allons passer en revue ces différents phase qui vous permettrons d’être sûr que votre environnement est convenablement paramétré. Pour commencer nous allons vérifier si notre environnement de Haute disponibilité (cluster) est correctement paramétré. Cette opération s’effectue grâce à l’assistant de validation de cluster présent dans l’environnement Windows 2008.Rappelons que :

Cette phase de validation est impérative si vous voulez que votre infrastructure Exchange clusterisée soit supportée par les équipes Microsoft.

Grace à cet outil, la configuration sera passée en revue et garantira que votre cluster respecte les bonnes pratiques. En cas de souci les équipes Microsoft peuvent vous demandez d’effectuer ces test soit dans le but d’inventaire, soit dans le but de valider votre configuration. Microsoft support une solution de clustering si tous les composant matériel sont marqués comme étant Certifié pour Windows 2008 R2 . Pour connaitre ou vérifier que votre matériel est présent dans la liste de compatibilité vous devrez vous reportez à l’adresse suivante:

http://www.windowsservercatalog.com/

L’outil de validation comprend 5 tests de base qui sont les suivants :

  • Test de configuration du cluster
  • test d’inventaires
  • Tests du stockage
  • Test de configuration des systèmes

 


Les tests de configuration du cluster vont inclure un certain nombre de tests d’inventaire sous-jacents qui sont les suivants :

  • Inventaire des Groupes de ressources de base utilisée par le cluster
  • Inventaire des informations de configuration réseau
  • Inventaire des ressources présentes au sein du cluster
  • Inventaire des volumes présent dans l’environnement stockage du cluster

Puis un certain nombre de tests seront effectués

  • Validation de la configuration du Quorum
  • Validation du statut des ressources
  • Validation de nom principal de service
  • Validation de la consistance de volume.


Figure 1 : Test de configuration du cluster

Les tests d’inventaires vont quant à eux vérifier les points suivants :

  • Information du BIOS
  • Variable d’environnement
  • Les adaptateurs Fibre
  • Les adaptateurs ISCSI
  • Les informations de mémoire
  • Les informations liées aux systèmes d’exploitation
  • les périphériques plug and play
  • les processus en cours d’exécution
  • les adaptateurs SAS
  • les informations sur les services
  • les mises à jour logicielles présentes
  • les pilotes logiciels
  • les informations du système comme le nom du serveur, le modèle type, le compte utilisé pour le test, le nom du domaine de la machine ainsi que la plage horaire du serveur


Figure 2 : Inventaires des données du cluster

 

Les tests du stockage vont quant à eux vérifier un certain nombre de point technique listés ci-dessous :


Les tests de la configuration du système vont quant à eux tester les points suivants :


  1. Exécution de l’outil de validation

Dans notre exemple nous avons mis en place un cluster à trois nœuds comportant trois serveurs de boites aux lettres. Les deux premiers sont présents sur un site physique le troisième sur un site distant. Site distant dont l’adressage IP est le même que sur le site dit principal. Pour des raisons évidentes nous vous recommandons de procéder à une sauvegarde des configurations avant de procéder aux tests.




  1. Résultat du test

Et les résultats tombent ;-))



  1. Correction des erreurs

Visiblement quelques avertissements sont présents. Je vous propose donc d’aller voir ce qu’il en est :

  1. HostRecordTTL property Warning

L’avertissement remonté par l’outil de validation est le suivant : The HostRecordTTL property for network name ‘Name: MRSDAG01′ is set to 300 ( 5 minutes). For local clusters the suggested value is 1200 (20 minutes).

Pour le corriger ouvrez le module powershell suivant : Windows PowerShell Modules


Pour le visualiser le paramètre en question utilisez la commande suivante :

PS C:\Users\lteruin> get-clusterResource "cluster Name" | Get-ClusterParameter

Object Name Value Type

—— —- —– —-

Cluster Name Name MRSDAG01 String

Cluster Name DnsName MRSDAG01 String

Cluster Name RemapPipeNames 0 UInt32

Cluster Name HostRecordTTL 300 UInt32

Cluster Name RegisterAllProvidersIP 0 UInt32

Cluster Name PublishPTRRecords 0 UInt32

Cluster Name TimerCallbackAdditionalThr… 5 UInt32

Cluster Name ResourceData {1, 0, 0, 0…} ByteArray

Cluster Name StatusNetBIOS 0 UInt32

Cluster Name StatusDNS 0 UInt32

Cluster Name StatusKerberos 0 UInt32

Cluster Name CreatingDC \\MRSINF2K01. String

Cluster Name LastDNSUpdateTime 10/3/2011 2:31:49 PM DateTime

Cluster Name ObjectGUID 855f5d489058f24188b12dd38c… String

 

Pour modifier la valeur en question utilisez la commande suivante :

 

Get-ClusterResource "cluster Name"| Set-ClusterParameter HostRecordTTL 1200

  1. Avertissements concernant le stockage

 

Concernant le stockage certains avertissements peuvent survenir selon votre configuration. Dans notre environnement, nous utilisons des disques locaux en Jbod. De plus, dans l’environnement Exchange Dag aucune ressource disque n’est partagée au sein du cluster. Certains avertissements sont donc tout à fait normaux. Si vous avez pris en compte les tests par défaut alors certains avertissement peuvent apparaitre (voir ci-dessous) :

 

  • List Potential Cluster Disks Warning / Normal & Peut être ignoré
  • Validate Disk Access Latency Warning / Normal & Peut être ignoré
  • Validate Disk Arbitration Warning / Normal & Peut être ignoré
  • Validate Disk Failover Warning / Normal & Peut être ignoré
  • Validate File System Warning / Normal & Peut être ignoré
  • Validate Microsoft MPIO-based disks Warning / Normal & Peut être ignoré
  • Validate Multiple Arbitration Warning / Normal & Peut être ignoré
  • Validate SCSI device Vital Product Data (VPD) Warning / Normal & Peut être ignoré
  • Validate SCSI-3 Persistent Reservation Warning / Normal & Peut être ignore
  • Validate Simultaneous Failover Warning/ Normal & Peut être ignoré

 

La plupart du temps si vous regardez dans le rapport du cluster, vous allez trouver qu’aucun disque n’a été trouvé.

"No disks were found on which to perform cluster validation tests."

Si vous ne voulez pas que ces derniers réapparaissent sélectionnez lors du lancement de l’outil de validation l’option Run Only Tests I Select


Et sélectionner uniquement List All Disk dans la section stockage comme le montre la figure suivante :


  1. System Configuration

Après vérification il manquait un certain nombre de mise à jour de sécurité sur l’un des nœuds du cluster


Un petit Windows Update et le tour sera joué.

  1. CONCLUSION

Lorsque vous installez ou faites installer un environnement Exchange 2010 ou bien que vous procédez ou faite procéder à la mise à jour d’un environnement Exchange en production vous devriez rejouer ces tests afin de vérifier si vous êtes toujours dans une configuration supportée par Microsoft. Le rapport de cet outil fait partie intégrante des documents de recette que vous devez exiger des équipes techniques lors de l’installation mais également régulièrement.

Laurent TERUIN

Posted in 1-EXCHANGE 2010, Cluster-2010 | Leave a Comment »

Exchange 2010 HA : Des nouvelles de Sam et PAM ?

Posted by Teruin laurent le novembre 7, 2010


Qui sont Pam et SAM ?

Pam est un acronyme désignant Primary Active Manager,Sam désigne Standby Active Manager . Le processus Active Manager est un processus qui s’exécute sur tout serveur Exchange 2010 normalement constitué. Vous trouverez PAM sur le membre d’un groupe de distribution de base de données possédant les ressources du cluster, SAM sur les autres membres du DAG. Comme vous le savez peut être déjà, Active Manager remplace les fonctionnalités de basculement des ressources Exchange assurée dans l’environnement Exchange 2007 par les services de cluster. Si vous cherchez un service portant ces deux acronymes vous ne le trouverez pas, car ils s’exécutent tous les deux au sein du service de réplication des services Exchange (MSExchangeRepl.exe). On notera au passage que si vous arrêtez ce service aucun basculement de facto ne sera possible.

Le rôle de PAM est simple : Il est responsable du contrôle des copies de bases de données qui vont être actives et celles qui seront passives. Il décide également du changement d’état de ces dernières lorsque des pannes de serveurs ou de bases de données se produisent. Lorsque vous décidez de changer le propriétaire du groupe de ressources du cluster, le PAM va également migrer automatiquement.

Voici quelques commandes Powershell qui vous seront utiles :

Qui détient les ressources du cluster ?

Pour vérifier en Powershell qui détient le cluster rien de plus simple voici les deux commandes que vous devez exécuter dans l’environnement Powershell

  • Import-Module FailoverClusters
  • Get-clustergroup | ft –auto

Déplacer les ressources du groupe de cluster vers un autre membre

  • Move-clustergroup « Nomduclustergroupe » – Node nomdunoeudcible.

Pour vérifier ou est Pam

  • Get-DatabaseAvaliabilityGroupe « Nomdevotredag » – Status | FL Name, PrimaryActiveManager

Le rôle de SAM ? Eh bien malgré le fait que ce petit dernier serait de type « Standby » figurez-vous qu’il travaille. SAM fourni des informations concernant les serveurs qui hébergent une copie active de base de données. Il est également en charge de détecter tout évènement de type « panne » sur les bases locales et les éventuels problèmes liés à la banque d’information. Si tel est le cas, il va demander à PAM de procéder à un basculement des bases de données. Les processus SAM accèdent tous à l’environnement Active Directory pour répondre aux requêtes de localisation de bases active provenant des services comme le transport ou les services d’accès client. On parle dans ce cas précis de Client Active Manager.

Dans le cas d’un serveur ne s’exécutant pas dans le cadre d’un groupe de bases de données, l’Active Manager présent dans le service MSExchangeRepl.exe va initier un StandAlone Manager (ne pas confondre avec StandBy : SAM). Toutes les 30 secondes, Active Manager va vérifier les données d’Active Directory et modifier la configuration du serveur en question si ce dernier a été ajouté à un groupe de disponibilité. Si cela est le cas, l’évènement 111 sera inscrit dans les journaux de haute disponibilité.

Nouveauté SP1

Dans le cadre d’un serveur Exchange 2010 fonctionnant en version SP1 et que vous souhaitez mettre sous maintenance, vous pouvez exécuter le script suivant : StartDagServerMaintenance.ps1
qui déplacer du serveur en question toutes les rôles de bases actives vers d’autres copies et marquer ces dernières non activables sur le serveur en question. Une fois que vous en avez terminé lancer le script StopDagServerMaintenance.ps1
pour rétablir la situation. De mémoire vous devrez réactiver manuellement les bases de données se situant sur le serveur ou vous avez effectué une opération de maintenance.

Vous voilà renseigné sur PAM SAM et AM et leurs différents rôles dans les processus de basculement.

Bonne continuation
Laurent TERUIN

Posted in Cluster-2010, Exchange 2010 Service Pack 1 | Leave a Comment »

Exchange 2010 et les Array CAS (Client Access Servers) – Part 2

Posted by David PEKMEZ le janvier 25, 2010


Introduction

 

Une des nouveautés d’Exchange 2010 est de centraliser les connexions clients vers les serveurs CAS, ce qui était déjà le cas en Exchange Server 2007 pour des services tels que Active Sync, OWA ou encore RPC Over http, les clients lourds Outlook se connectaient eux encore sur les serveurs de boîtes aux lettres en direct.

La grande nouveauté concerne donc la connexion des clients Outlook aux serveurs CAS qui porte définitivement bien son nom dans cette nouvelle version puisqu’il accueille tous les clients Exchange, le rôle de boîte aux lettres est dédié au stockage et à la gestion des banques d’informations.

Voici un schéma représentant les connexions clients vers les serveurs CAS sous Exchange server 2010


Dans la première partie de cet article, nous avons configuré un cluster de type NLB ;

La seconde partie de cet article sera consacrée à la création et la configuration d’un Array de serveur CAS afin d’accueillir les clients Outlook.

Création et configuration de l’Array de servers CAS

 

La création de cet array passe par la commande Powershell suivante : New-ClientAccessArray

New-ClientAccessArray –Name « Enter a Name » -Fqdn « Array Fqdn Name » -Site « Array Site Name »


 

Attention

Su une base de donnée est crée avant l’array de serveurs CAS elle ne prendra pas en compte cette configuration,

Ci-dessous, je peux remarquer que le paramètre RpcClientAccressServer pointe sur un de mes serveurs CAS et pas sur mon Array


Je vais devoir modifier ce paramètre à l’aide de la commande Set-MailboxDatabase afin de modifier la valeur du paramètre RpcClientAccressServer

Si par contre je créé une nouvelle base de données, elle prendra automatiquement ce paramètre en compte



 

Conclusion

La grande nouveauté est la gestion par les serveurs CAS de tous les clients de messagerie, il paraît tout de même important de noter que les connexions aux publics folders sont font en direct sur les serveurs de boîtes aux lettres.

Ceci implique tout de même un travail bien plus important de ces serveurs en comparaison avec Exchange 2007 donc faite bien attention au dimensionnement des serveurs hébergeant ces rôles CAS.

Cette fonctionnalité permet d’améliorer grandement les périodes de non disponibilité durant une perte de connexion, qui est de 30 secondes d’après les équipes produit au lieu de plusieurs minutes avec les versions précédentes.

Posted in Cas-2010, Cluster-2010 | Leave a Comment »

Exchange 2010 Database Availability Group (DAG)

Posted by David PEKMEZ le juillet 28, 2009


Suite à l’annonce d’Exchange 2010, je vais vous présenter le principal mécanisme de haute disponibilité appelé « DAG Database Availability Group »

Ce système de haute disponibilité améliore et remplace les systèmes de haute disponibilité existant sous Exchange 2007, CCR et SCR.

Grande nouveauté à annoncer de suite : oubliez les groupes de stockage, ils n’existent plus dans Exchange 2010 ! Donc celles-ci sont dorénavant gérées au niveau de l’organisation Exchange,

La haute disponibilité est maintenant gérée au niveau de la base de données et non plus au niveau du groupe de stockage.

Le DAG permet de répliquer une base de données sur plusieurs serveurs, à condition qu’ils fassent parti du DAG en question.

Le DAG repose sur le cluster Windows ( Failover Clustering ) et nécessite donc une version Enterprise de Windows.

Autre nouveauté à souligner, contrairement à Exchange 2007, différents rôles (CAS, HUB) pourront être installés sur une machine faisant parti d’un cluster, ce qui permettra de limiter le nombre de serveurs lors du Design de l’infrastructure,

A noter toutefois, le NLB (Network Load Balancing ) ne sera pas supporté sur des machines faisant parti d’un cluster de type Failover Clustering, donc si vous voulez mettre en haute disponibilité les rôles CAS et HUB via du NLB, vous devrez installer ces rôles sur les machines séparées, à moins d’utiliser des systèmes de haute disponibilité matériels.

Passons à création et la configuration d’un DAG ;)

Dans cet exemple, j’utilise 4 machines Windows 2008 SP2, 1 DC et 3 dédiées à Exchange et qui feront parti d’un DAG Exchange 2010.

Les machines Exchange :

  • WIN2K8EX01
  • WIN2K8EX02
  • WIN2K8EX03

Le DAG Exchange 2010

  • EX2K10DAG

Création d’un DAG Exchange 2010

Nous pouvons utiliser l’interface graphique ou powershell pour créer un DAG Exchange 2010, dans mon exemple j’utilise powershell

Pour créer un DAG nous devons utiliser la commande powershell New-DatabaseAvailabilityGroup en spécifiant les paramètres suivant :

  • Le Nom du DAG
  • Le partage du FSW (File Share Witness)
  • Le chemin vers le FSW


Il nous faut ensuite intégrer notre premier serveur Exchange 2010 au DAG via la commande powershell Add-DatabaseAvalabilityGroupServer

L’utisation de powershell permet de spécifier l’adresse IP qui sera utilisée par le DAG via l’utilisation du paramètre DatabaseAvailabilityGroupIpAdresses


Création du cluster



Nous pouvons ensuite ajouter des serveurs au DAG via l’interface graphique ou en utilisant les commandes powershell

Via l’interface graphique en faisant un clic droit sue le DAG et en sélectionnant « Manage Database Avalability Group Membership »


Puis ajouter un serveur au DAG


En utilisant les commandes powershell


Une fois les serveurs ajoutés nous pouvons vérifier les propriétés du DAG en double cliquant dessus


Ajout d’une base de données au DAG

Nous pouvons maintenant ajouter une base de données au DAG afin de répliquer les données de cette base


Le wizard se lance et nous permet d’ajouter des serveurs et de paramétrer les options Replay Lag Time (Le paramètre ReplayLagTime spécifie le temps d’attente du service de réplication Microsoft Exchange avant de relire les fichiers journaux copiés vers l’ordinateur cible) et Truncation Lag Time (Le paramètre TruncationLagTime spécifie le temps d’attente du service de réplication Microsoft Exchange avant de tronquer les fichiers journaux copiés vers l’ordinateur cible et relus dans la copie de la base de données)



Une fois terminée, la copie apparaît en « Mounted » sur le serveur ou est montée la base de donnée et la copie apparaît en « Healthy » sur les serveurs possédant une copie de la base de données.


L’ajout peut tout aussi bien se faire en powershell via la cmdlet Add-MailboxDatabaseCopy




Les copies apparaissent bien en Healthy.

Ci-dessous une vue du cluster Microsoft créé automatiquement par Exchange lors de la création du DAG et l’ajout de nœud au sein du cluster,

L’administrateur Exchange n’a plus à gérer la création du cluster ou l’ajout de nœuds.

La gestion du quorum et les changements nécessaires de configuration selon le nombre de nœuds se fait aussi automatiquement


Il est possible de basculer une base d’un serveur à l’autre en utilisant l’interface graphique en faisant un clic droit sur la base de données et en sélectionnant l’option « Move Active Mailbox Database »


Le Wizard se lance et nous permet de choisir le serveur vers lequel nous souhaitons basculer ainsi que les options de bascule.




La base de données active est revenue sur le serveur WIN2K8EX01 et les copies de cette base sont dans un état sein.

Nous pouvons faire le test en éteignant le serveur possédant la copie active, cela va engendrer une bascule vers un autre nœud du cluster


Voici quelques évènements du journal application très parlants et qui vous permettront de surveiller l’état de santé de votre infrastructure Exchange via SCOM ou autres produits de supervison.









La base se synchronise avec la copie active puis repasse en état « Healthy »


Voilà un petit tour de ces nouvelles fonctionnalités qui apparaissent vraiment comme l’aboutissement de ce qui était en Exchange 2007 les CCR et SCR,

Vivement les premiers projets de migration vers Exchange 2010 !!

Posted in Cluster-2010 | Tagué: | 4 Comments »

 
Suivre

Recevez les nouvelles publications par mail.

Rejoignez 223 autres abonnés