Haute Disponibilité : DAG 08/02/2011 Matthieu PARFUS Consultant Senior II Microsoft Consulting Services

Microsoft Services: Un accompagnement global de nos clients Architecture & Planning Planification Conseil et Projets Déploiement et adoption Support Optimisation et Opération Evaluation Développement Déploiement Stabilisation Opérations Support Premier Enterprise Strategy Consulting Services Division Services France 2010 180 Consultants 125 Technical Account Managers 190 Ingénieurs Support 17 Responsables de Mission 41 Partenaires référencés Division Services Monde 2010 82 pays couverts 18 000 employés 35 000 partenaires 44 langues parlées par nos ingénieurs www.microsoft.fr/services

Nos clients et partenaires sont particulièrement satisfaits par… Notre positionnement est d’intervenir sur les projets critiques et les technologies récentes Criticité du projet Maturité de la technologie Partenaires Notre engagement auprès de nos partenaires est : De leur assurer un transfert d’expertise, De leur apporter notre support sur les dernières technologies, De leur donner accès aux meilleures pratiques de mise en œuvre et de support. Nos clients et partenaires sont particulièrement satisfaits par… Le niveau d’engagement des consultants : 94% La gestion de l’équipe de projet : 92% Les compétences techniques des consultants : 91% La relation avec les équipes du client : 90%

Agenda Principes Pré-requis et limites Dimensionnement Paramètres MBX membre d’un DAG Fonctionnement réplication Quorum et FileShareWitness Active Manager Sélection de la meilleure copie Datacenter Activation Coordination (DAC) Résilience de site Nouveautés du SP1

Principes du DAG DAG : groupe de serveurs ayant le rôle Mailbox (MBX) Les bases de données peuvent disposer d’une ou plusieurs copies entre les MBX du DAG (une active, les autres passives) Transmission de log de transaction au travers du réseau (logshipping), et commit sur les DB Passives Haute Dispo DAG associée au CAS Array (Ferme de CAS) Primary Active Manager (PAM) : Mécanisme d’activation automatique de la meilleure copie Complexité apportée par : DAG étendu sur plusieurs sites géographique => Split-Brain / mécanisme de redémarrage Commit retardé (lagged copy)

Pré-requis et limites (1) Intégration AD : MBX présents sur un ou plusieurs sites AD / VLAN Plusieurs DAG peuvent être présents dans un site AD Tous les nœuds doivent appartenir au même domaine 1 CAS Array par site AD (8 CAS max si NLB) Nom du DAG < 16 caractères MBX ne doit pas être avoir de rôle DC/GC

Pré-requis et limites (2) Service « Failover Cluster » : Valide la présence ou l’absence des nœuds (heartbeat) 16 nœuds maximum par DAG Information d’étât stockée dans ruche cluster (utilisé par le PAM) Implique « Windows Server 2008 Entreprise ou 2008 R2 Entreprise) Activation du DAG ne nécessite pas de ré-installer Exchange (installation incrémentale) Utilisation réduite du failover cluster Plus de modèle de ressources / groupe pour Exchange / partage de stockage Plus de dll exres.dll Uniquement : Nom, IP, Quorum (si nb de nœuds pair) Les nœuds et les réseaux doivent être gérés au travers de l’EMC et non des outils cluster

Pré-requis et limites (3) DB Maximum (Active, Passive ou Dossiers Publics confondus) : Exchange Server Standard = 5 DB maximum Exchange Server Entreprise = 100 DB maximum Nom unique de la DB dans l’organisation (globalisation) Taille DB : Supportée = 16 To Maximum recommandé sans Haute Dispo = 100 Go Maximum recommandé avec plusieurs copies dans un DAG = 2 To Log CheckpointDepth Target : Stand Alone = 20 Mo DB active qui a plusieurs copies = 100 Mo DB Passive = 5 Mo

Pré-requis et limites (4) Mutualisation des rôles CAS et HT peuvent être installés sur un MBX membre d’un DAG Failover Cluster : NLB n’est pas supporté CAS membre d’un DAG => Hardware Load Balancer HT : le rôle n’est pas utilisé pour les communications émise par nœud (sauf si dernier HT disponible dans le site) Datacenter Activation Coordination Mode (DAC) : 3 MBX minimum et 2 sites AD distincts (RTM) Virtualisation : Solutions de Haute Dispo Virtu (LiveMigration et VMWare HA) non supportées avec les membres d’un DAG et host qui héberge le FSW NIC : 1 supportée 2 minimum recommandées, NIC dédiée : Réplication MAPI, dialogue HT/CAS/GC  MBX MultiVLAN : /!\ associer les Subnets ; Réseau MAPI et Réplication ne doivent pas se voir ; « netsh » au lieu de « route add »

Dimensionnement ”Exchange 2010 Mailbox Server Role Requirements Calculator” + “Exchange Processor Query Tool” Nombre de nœuds Nombre de cores CAS / HT / GC Dimensionnement des LUN DAG multi-sites Trafic réseau Compression activable sur le même VLAN voir entre VLAN différent uniquement Nombre/Type de disques et redondance associée

Paramètre MBX d’un DAG Set-MailboxServer autoDatabaseMountDial : BestAvailability = 12 (default) GoodAvailability = 6 Lossless = 0 DatabaseCopyAutoActivationPolicy Blocked : activation impossible sur le serveur IntraSiteOnly : activation possible seulement si le MBX est dans le même site que le MBX d’origine Unrestricted : pas de restriction MaximumActiveDatabases : DB maximum qui peuvent être activées sur un MBX

Fonctionnement réplication Replication Continue mode Fichier Changement depuis Exchange 2007 : TCP Socket au lieu du SMB Plus de « pull » : la copie passive notifie la copie active des fichiers à récupérer (TCP notification), la copie active pousse alors les fichiers (TCP socket) Une copie passive peut être source lors d’un reseed DB « Dossier publics » peut être présente sur un MBX membre d’un DAG, mais la réplication doit toujours s’appuyer sur les replicas de dossiers Réplication gérée par l’Information Store (plus par le service Replication) => informations déjà dans le cache, accélère l’activation de la DB

Fonctionnement réplication Fichier de log = 1 Mo Réplication peut être compressée / encryptée : Entre toutes les machines Entre VLAN Pour du seeding CopyQueueLength = Nb Log en attente d’être copiées et inspectées ReplayQueueLength = Nb Log en attente de commit Set-mailboxdatabasecopy: -ReplayLagTime = délai avant commit (14 j max) - TruncationLagTime = délai du purge des logs après commit (14 j max) -ActivationPreference = Utiliser lors du calcul de la meilleure copie à activer, et dans la redistribution des DB

Quorum et FileShareWitness Intégrité : Tous les nœuds doivent disposer des mêmes informations de configuration Service Cluster ne démarre pas si le nœud ne dispose pas des dernières informations Calcul de majorité dans le DAG Nombre de nœuds pairs : quorum => « File Share Majority » Ressource Quorum FileShareWitness : évite les phénomènes de split-brain. Verrou est positionné sur le fichier « witness.log » par un nœud (SMB), il possède alors une double voix lors des élections. Les autres nœuds qui peuvent le contacter sont additionnés dans le calcul /!\ FileShareWitness ne possède pas de copie du Quorum Nombre de nœuds impairs : Quorum => « Majorité de nœuds » Nombre de nœuds insuffisants pour obtenir la majorité => le service s’arrête Recommandation Créer un DAG avec un FileShareWitness même si nombre de nœuds impair (permet d’anticiper la modification du nombre de nœuds dans l’avenir) Positionner le Share sur un serveur Exchange (HT) afin que les MBX disposent par défaut des droits nécessaires sur le partage

Active Manager Primary Active Manager (PAM) Un des nœuds du DAG Il décide quelle copie doit être active et passive dans le DAG Il reçoit les modifications de topologie, d’état des nœuds et il réagit à une panne Il est toujours le nœud qui possède la ressource Quorum du cluster Group Il faut déplacer le rôle PAM avant d’effectuer une maintenance sur le serveur En cas de panne, un autre nœud capture le rôle PAM Standby Active Manager Il détecte les pannes sur les bases locales ou l’Information Store Il demande au PAM en cas de panne d’effectuer une bascule de DB Il transmet l’information du nœud qui possède la base active aux autre rôles notés comme « Active Manager Client » Il reçoit les informations de supervision du service de réplication ou du moteur ESE (problème d’I/O) Le SAM est présent sur tous les nœuds (y compris sur celui héberge le PAM) Standalone Active Manager Rôle MBX non membre d’un DAG

Sélection de la meilleure copie Best Copy Selection (BCS) Détection du meilleur nœud pour activer la copie (jusqu’à 10 critères sont utilisés) Attempt to Copy Last Log (ACLL) : Tentative de copie de toutes les dernières log manquante depuis la DB Active PAM demande au nœud qui héberge la meilleure copie de la monter Pas de perte de logs / « lossless failover » => pas de perte d’information Perte de logs => le MBX contacte les HT pour obtenir des messages conservés en tampon (Transport Dumpster) Raison pour que la meilleure copie ne monte pas : Nombre de logs perdues > « autodabasemountdial » Nombre de DB active >= MaximumActiveDatabases Copie suspendue d’activation (DatabaseCopyAutoActivationPolicy) => PAM demande alors à la meilleure copie suivante de monter, etc.

Sélection de la meilleure copie Algorithme (RTM) 1ère étape : DB éligible Statut = healthy, disconnectedAndHealthy, disconnectedandresynchronizing, seedingsource 2ième étape : Tri 1er niveau : « Copy Queue Length / LastLogInspected» => la plus grande log inspectée est mise en premier. 2ième niveau : ActivationPreference => le plus faible est mis en premier

Sélection de la meilleure copie Algorithme (RTM) 3ième étape : Validation de l’état de la copie

Sélection de la meilleure copie Database Copy Activation Preference Copy Queue Length Replay Queue Length Content Index State Database State Activation Blocked Srv2\DB1 2 4 Healthy No Srv3\DB1 3 DisconnectedAndHealthy Srv4\DB1 10 Crawling 1ère étape : Toutes les copies sont healthy ou disconnectedandhealthy 2ième étape – tri : Srv3, Srv2, Srv4 3ième étape : ACCL : si log manquantes < autodabasemountdial => mounted + Transport Dumpster sinon, essai avec la copie du Srv2, etc. Srv3 Srv2 Srv4 Phase CopyQueue ReplayQueue ContentIndex X   Phase1 < 10 logs < 50 logs Healthy Phase2 Crawling Phase3 ========== X  Phase4 Phase5 Phase6 Phase7 Phase8 Phase9 Phase10 Any database not activation suspended

Sélection de la meilleure copie Database Copy Activation Preference Copy Queue Length Replay Queue Length Content Index State Database State Activation Blocked Srv2\DB2 2 Healthy No Srv3\DB2 3 DisconnectedAndHealthy Srv4\DB2 4 10 Crawling 1ère étape : Toutes les copies sont healthy ou disconnectedandhealthy 2ième étape – tri : Srv2, Srv3, Srv4 (copyqueuelength = ; activation preference <>) 3ième étape : ACCL : si log manquantes < autodabasemountdial => mounted + Transport Dumpster sinon, essai avec la copie du Srv3, etc. Srv2 Srv3 Srv4 Phase CopyQueue ReplayQueue ContentIndex X   Phase1 < 10 logs < 50 logs Healthy Phase2 Crawling Phase3 ========== Phase4 Phase5 Phase6 Phase7 Phase8 Phase9 Phase10 Any database not activation suspended

Datacenter Activation Coordination Evite certains cas de split-brain : Datacenter 1 : MBX1, MBX2 Datacenter 2 : MBX3 Panne de courant sur Datacenter 1 => Activation Datacenter 2 => DB montées sur MBX3 Retour du courant sur Datacenter 1, mais pas de réseau Sans DAC, MBX1 et MBX2 pensent avoir la majorité et montent les DB alors qu’elles sont actives sur MBX3 Avec DAC, majorité retrouvée => DB ne remontent pas automatiquement

Datacenter Activation Coordination Un bit positionné en mémoire En mode DAC : Active Manager démarre => bit = 0 (ne pas monter les DB automatiquement) Il tente de contacter les autres MBX Si un MBX a un bit = 1 ou si tous les MBX sont joignables => le bit passe à 1 RTM : 3 nœuds et 2 sites AD minimum

Résilience de site DAG étendu sur un site AD ?

Résilience de site DAG étendu sur un site AD ? Bascule automatique : Implique HLB cross-Datacenter Ajoute une complexité réseau Redondance de point d’entrée réseau si VLAN étendu Dialogue CAS / HUB  GC / MBX cross Datacenter Pas supporté de positionner un Firewall entre CAS et MBX Bascule complète d’un site en cas de perte de connectivité réseau => Modèle à éviter si utilisateurs présents dans chacun des sites Gestion des URL souvent plus simple

Résilience de site DAG étendu sur deux sites AD ?

Résilience de site DAG étendu sur deux sites AD ? Bascule automatique : Complexe en cas de perte complète de Datacenter (HLB cross Datacenter, redirection MAPI/HTTP) Toujours du trafic entre Datacenter HUB  HUB CAS  MBX (dépend du CAS Array configuré sur la DB, et de la valeur du profil Outlook) Gestion des URL souvent plus compliqué OWA/ECP : internalURL => FQDN du CAS pour Kerberos Deux DAG croisés en mode A/P évitent de couper les utilisateurs lorsqu’ils sont présents sur les 2 sites Utilisation d’un « AlternateFileShareWitness » sur l’autre site Recommandation : changement d’adresses IP des CAS Array / URL => améliore l’expérience utilisateurs (TTL à prendre en compte)

SP1: DAC Maintenant sont supportés : DAG 2 noeuds (utilisation d’un FileShareWitness) DAG étendu sur plusieurs sites géographiques mais dans le même site AD

SP1: Réplication continue mode bloc Mise à jour écrite dans le buffer de log : de la DB active de chacune des copies passives Buffer de log plein => chaque copie construit, vérifie, et génère un nouveau fichier de log Panne de la copie active =>copies passives disposent des dernières informations Pas de verrou sur la copie active => pas d’impact pour l’expérience utilisateur Réduit le temps de propagation des changements Au démarrage, la réplication est en mode fichier Replication à jour en mode fichier (copy queue length = 0) => Activation du mode bloc Passage automatique d’un mode à un autre (process « log copier »)

SP1: Réplication continue mode bloc Savoir que le mode bloc est activé pour la copie : Compteur de performance : « MSExchange Replication \ Continuous replication – block mode Active = 1 » Get-Counter -ComputerName <DAGMemberName> -Counter "\MSExchange Replication(*)\Continuous replication - block mode Active" Get-WMIObject -ComputerName <DAGMemberName> Win32_PerfRawData_MSExchangeReplication_MSExchangeReplication | Where-Object {$_.ContinuousReplicationBlockModeActive -eq "1"} | Where-Object {$_.name -ne "_total"} | format-table Name,ContinuousReplicationBlockModeActive

SP1: Outils de supervision Checkdatabaseredundancy.ps1 : Valide que toutes les DB sont redondées et qu’au moins 2 copies sont saines Intégration avec System Center Operation Manager 2007 Très utile en cas d’utilisation de JBOD StartDagServerMaintenance.ps1 : Positionne un membre du DAG en maintenance Déplace les DB actives vers d’autres membres et empêche l’activation de DB Déplace vers un autre membre le rôle PAM et l’empêche de revenir StopDagServerMaintenance.ps1 pour terminer la mise en maintenance CollectOverMetrics.ps1 : Permet d’obtenir des informations sur les bascules planifiées ou non Fournit des informations sur le mode de réplication (mode bloc) CollectReplicationMetrics.ps1 : Information en temps réel sur la réplication (paramétrage possible)Form active

URL ”Exchange 2010 Mailbox Server Role Requirements Calculator” : Description : http://msexchangeteam.com/archive/2009/11/09/453117.aspx Mise à jour : http://msexchangeteam.com/archive/2010/01/22/453859.aspx Téléchargement : http://msexchangeteam.com/files/12/attachments/entry453145.aspx  “Exchange Processor Query Tool” : Description : http://msexchangeteam.com/archive/2010/10/27/456738.aspx Téléchargement : http://msexchangeteam.com/files/12/attachments/entry456737.aspx Understanding Active Manager / Best copy selection process http://technet.microsoft.com/en-us/library/dd776123.aspx Datacenter Switch/Failover http://technet.microsoft.com/en-us/library/dd298067.aspx Hardware Virtualization : http://technet.microsoft.com/en-us/library/aa996719.aspx http://technet.microsoft.com/en-us/library/dd298121.aspx http://technet.microsoft.com/en-us/library/ee832795.aspx

Supervision Get-MailboxDatabaseCopyStatus

MSDN et TechNet : l’essentiel des ressources techniques à portée de clic Portail administration et infrastructure pour informaticiens Portail de ressources technique pour développeurs http://technet.com http://msdn.com