La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Christophe Leroux IT Architect Microsoft France

Présentations similaires


Présentation au sujet: "Christophe Leroux IT Architect Microsoft France"— Transcription de la présentation:

1

2 Christophe Leroux IT Architect Microsoft France
High Availability Christophe Leroux IT Architect Microsoft France

3 Agenda Exchange 2010 High Availability Vision/Goals
Exchange 2010 High Availability Features Exchange 2010 High Availability Deep Dive Deploying Exchange 2010 High Availability Features Transitioning to Exchange 2010 High Availability High Availability Design Examples

4 Vision de la Haute disponibilité Exchange 2010

5 Vision et buts Vision: délivrer une solution rapide, facile à déployer et à opérer, à cout faible, pouvant s’adapter à l’ensemble des clients. Buts Délivrer une solution native à Exchange pour adresser la haute disponibilité et la tolérance de site Utiliser des stockages moins couteux et plus simples Simplifier l’administration et diminuer les couts de support Augmenter la disponibilité globale Supporter Exchange Server 2010 Online Supporter de larges boites aux lettres à faible cout

6 Exchange Server 2003 Complexité de mise en œuvre d’un site de secours et de process de bascule Dallas DB1 Outlook OWA, ActiveSync, ou Outlook Anywhere DB2 Standby Cluster DB3 La création du cluster est une opération manuelle San Jose Front End Server Besoinnd’un outil tier pour monter un site de secours NodeA (actif) NodeB (passif) Nécessité de connaitre le cluster Failover au niveau du serveur DB1 DB4 DB2 DB5 DB3 DB6

7 Exchange Server 2007 SCR CCR
Complexité de mise en œuvre d’un site de secours et de process de bascule Dallas DB1 SCR Outlook OWA, ActiveSync, ou Outlook Anywhere DB2 Standby Cluster DB3 Clustered Mailbox Server can’t co-exist with other roles San Jose Client Access Server Pas d’interface pour gérer le SCR NodeA (active) NodeB (passive) CCR Nécessité de connaitre le cluster DB1 DB4 DB1 DB4 DB2 DB5 DB2 DB5 Failover au niveau du serveur DB3 DB6 DB3 DB6

8 Exchange Server 2010 Dallas Tous les clients se connectent au travers des serveurs CAS DB1 Client DB3 DB5 Mailbox Server 6 San Jose Facilité d’extention sur d’autres sites Client Access Server Failover géré par Exchange Mailbox Server 1 Mailbox Server 2 Mailbox Server 3 Mailbox Server 4 Mailbox Server 5 DB2 DB3 DB4 DB3 DB4 DB5 DB1 DB1 DB4 DB5 Failover au niveau des bases DB2 DB5 DB1 DB3 DB1 DB2

9 Fonctionnalités de haute disponibilité d’Exchange 2010

10 Haute disponibilité Exchange 2010 Terminologie
Haute disponibilité – Solution qui doit apporter une disponibilité des services et données ainsi qu’une reprise automatique en cas de problème Disaster Recovery – Process utilisé pour une reprise manuelle en cas de problème Resilience de site – Solution de récupération de désastre utilisé en cas d’indisponibilité d’un site physique *over (switchover/failover) – un “switchover” est une activation manuelle d’une ou plusieurs bases de données; un failover est une activation automatique d’une ou plusieurs bases de données en cas de problème

11 Haute disponibilité Exchange 2010 Fonctionnalités
Mailbox Resiliency – Nom d’une solution complète de haute disponibilité ou de résilience de site Database Mobility – Possibilité de répliquer et remonter une base de données sur un autre serveur de boites aux lettres Incremental Deployment – Possibilité de déployer des fonctionnalité de haute disponibilité ou de résilience de site après l’installation d’Exchange Exchange Third Party Replication API – API Exchange permettant à des partenaires de développer une réplication compatible DAG en lieu et place de la solution native d’Exchange

12 Haute disponibilité Exchange 2010 Fonctionnalités
Database Availability Group – un groupe de serveurs (16 maximum) hébergeant des répliques de bases de données Mailbox Database Copy – une base de données (EDB + Logs) qui peut être soit active ou passive RPC Client Access service – Fonctionnalité du rôle CAS permettant à un client MAPI de se connecter Shadow Redundancy – Fonctionnalité de transport offrant une redondance des messages pour assurer une redondance du transfert

13 Concepts basés sur Exchange 2007
Extensible Storage Engine (ESE) Bases de données et fichiers de logs Continuous Replication Log shipping Database seeding Store service/Replication service Database health et status monitoring Divergence Montage automatique de base Concepts de quorum de witness Concepts des failover et switchover

14 Concepts supprimés dans Exchange 2010
Storage Groups Identifications des bases de données en fonction des serveurs auxquelles est sont attachées Nom du serveur faisant parti du nom des bases de données Clustered Mailbox Servers Pre-installation du Windows Failover Cluster Lancement des étapes d’installation dans le mode cluster Déplacement d’un réseau CMS entre les serveurs Stockage partagé Limite de deux copies pour la HA Besoin de deux réseaux Concepts de public, privé et réseau mixte

15 Changement de stratégie HA/Backup
Fonctionnalité Exchange 2010 Avantage Panne HW/SW Mailbox Resiliency Récupération rapide Redondance de données Récupération rapide Panne d’un Data Center Single Item Recovery Suppression accidentelle de données Garantie de récupération de données Erreur d’un administrateur Lagged Copy Rétention d’informations Redémarrage avec étant antérieur Corruption d’une boite Personal Archive + Retention Policies Rétention de longue durée Autre boite pour données anciennes

16 Concepts avancés de la haute disponibilité Exchange 2010

17 Principes de la HA Exchange 2010
RPC CAS Database Availability Group Serveur Bases de données Copy de bases Active Manager RPC Client Access AM SVR copy copy DB DB copy copy SVR AM DAG RPC CAS

18 Database Availability Group (DAG)
Principe élémentaire de haute disponibilité et de résilience de site Un groupe de 16 serveurs maxi pouvant partager des répliques de bases de données Basé sur Windows Failover Cluster Gère les membres ( membre d’un DAG = nœud) Utilise le heartbeat entre les membres du DAG L’ Active Manager stocke les informations dans la base de donnée du cluster Définit la frontière pour: La réplication des bases de données Base de donnée et serveur *overs Active Manager

19 Besoins du DAG Windows Server 2008 SP2 Enterprise Edition ou Windows Server 2008 R2 Enterprise Edition Exchange Server 2010 Standard Edition ou Exchange Server 2010 Enterprise Edition Standard supporte jusqu’à 5 bases par serveur Enterprise supporte jusqu’à 100 bases par serveur Au moins une carte réseau par membre du DAG

20 Active Manager Composant Exchange qui gère les *overs
Est actif sur tous les serveurs du DAG Sélectionne la meilleure copie lors d’un failover Est la source de référence pour savoir où une base de données est active Stocke les informations dans la base cluster Fourni les informations aux autres composants Exchange (RPC Client Access et Hub Transport) Deux rôles Active Manager : PAM et SAM Les clients Active Managers tournent sur les CAS et Hub

21 Active Manager Primary Active Manager (PAM)
Tourne sur le nœud qui détient le group cluster Récupère les changements de topologie Prend les décisions lors des pannes de serveurs Sélectionne la meilleur base de donnée lors des bascules Standby Active Manager (SAM) Tourne sur l’ensemble des nœuds du DAG Répond au demandes pour savoir qui a la copie active d’une base de données Les deux rôles sont nécessaires pour disposer d’une redémarrage automatique sur erreur Si le service de réplication est arrêté, le redémarrage automatique ne fonctionne pas

22 Active Manager Sélection de la copie active d’une base de données
Active Manager sélectionne la “meilleure’ copie pouvant devenir active quand une erreur survient sur une base Ignore les serveurs qui ne sont pas joignable ou dont l’activité est temporairement bloquée Trie les copies classé dans l’ordre d’une perte minimal d’informations Supprime les entrées concernant les bases qui ne sont pas éligible à la bascule Sélectionne la base devant devenir active en fonction du tri réalisé

23 Active Manager Sélection de la copie active d’une base de données
Active Manager selectionne la “meilleurs” copie pouvant devenir active 6 5 8 10 9 7 Catalog Crawling Copy status Healthy, DisconnectedAndHealthy, DisconnectedAndResynchronizing, or SeedingSource ReplayQueueLength < 50 Catalog Crawling Copy status Healthy, DisconnectedAndHealthy, DisconnectedAndResynchronizing, or SeedingSource Catalog Healthy Copy status Healthy, DisconnectedAndHealthy, DisconnectedAndResynchronizing, or SeedingSource Catalog Crawling Copy status Healthy, DisconnectedAndHealthy, DisconnectedAndResynchronizing, or SeedingSource CopyQueueLength < 10 Catalog Healthy Copy status Healthy, DisconnectedAndHealthy, DisconnectedAndResynchronizing, or SeedingSource CopyQueueLength < 10 ReplayQueueLength < 50 Catalog Crawling Copy status Healthy, DisconnectedAndHealthy, DisconnectedAndResynchronizing, or SeedingSource CopyQueueLength < 10 ReplayQueueLength < 50 Catalog Healthy Copy status Healthy, DisconnectedAndHealthy, DisconnectedAndResynchronizing, or SeedingSource CopyQueueLength < 10 Catalog Healthy Copy status Healthy, DisconnectedAndHealthy, DisconnectedAndResynchronizing, or SeedingSource ReplayQueueLength < 50 Copy status Healthy, DisconnectedAndHealthy, DisconnectedAndResynchronizing, or SeedingSource Copy status Healthy, DisconnectedAndHealthy, DisconnectedAndResynchronizing, or SeedingSource ReplayQueueLength < 50

24 Principe de redémarrage automatique
Quand une panne survient au niveau d’une base de données: Active Manager détermines la meilleure copie à activer Le service de réplication du serveur cible essaye de copier les fichiers de log manquant Si la copie a réussi, la base de données va démarrer sans aucune perte de données Si la copie ne fonctionne pas, la base va démarrer en se basant sur le paramétrage AutoDatabaseMountDial La base montée va générer de nouveau fichiers de logs (utilisant la même séquence de log) Le service de requête du Transport Dumpster initie une demande de récupération des messages perdus Quand le serveur ou la base initiale est remontée, il détecte une divergence et détermine s’il doit effectuer une resynchronisation incrémentale ou complète

25 Cycle de vie d’un DAG Le DAG est créé initialement comme un objet vide dans l’Active Directory Un nom est donné au DAG ainsi qu’une ou plusieurs adresses IP (ou configuré pour utiliser DHCP) Quand le premier serveur MBX est ajouté au DAG: Un cluster Windows est créé avec un quorum “Node Majority” et portant le nom du DAG Le serveur est ajouté à l’objet DAG stocké dans Active Directory Active Directory Le nom et l’adresse IP du DAG sont enregistrés dans le DNS La base de données du DAG est mise à jour avec les informations sur les bases de données et l’état des bases.

26 Cycle de vie d’un DAG Quand d’autres roles MBX sont ajoutés au DAG
Le serveur rejoint le cluster portant le nom du DAG Le type de modèle de quorum est automatiquement mis à jour Node Majority - DAGs avec un nombre impair de membres Node et File Share Majority - DAGs avec un nombre pair de membres La ressource “File share witness”, le répertoire et le partage sont automatiquement créé quand nécessaire Le serveur est ajouté à l’objet DAG dans Active Directory La base do données du cluster DAG est mise à jour avec les bases de données configurées et leurs états

27 Cycle de vie d’un DAG Après ajout des serveurs dans le DAG, il faut:
Configurer le DAG Encryption réseau Compression réseau Configurer les réseaux du DAG Sous-réseaux Activation/désactivation du trafic MAPI / réplications Créer les copies des bases de données Le “Seeding” est réalisé automatiquement Surveiller l’état des bases de données

28 Cycle de vie d’un DAG Avant de supprimer un serveur d’un DAG, il faut supprimer l’ensemble des copies de bases de données Quand un serveur est supprimé d’un DAG: Le serveur est supprimé du cluster Le quorum est ajouté en fonction du nombre de noeuds restant Le serveur est supprimé de l’objet DAG d’Active Directory Avant de pouvoir supprimer un DAG, il faut supprimer l’ensemble des serveurs qui le compose

29 Déploiement des fonctionnalités Exchange 2010 HA

30 Déploiement des fonctionnalités Exchange 2010 HA
Déploiement Exchange 2007 et précédents (CCR/SCC) Déploiement incrémental d’Exchange 2010 Préparation du matériel, installation de l’OS et mise à jour Pour le SCC: configuration du stockage Construction du Cluster windows Configuration du quorum, du file share witness, et des réseaux public etprivate Lancement du Setup est installation du role mailbox sur le cluster Configuration du rôle mailbox Pour le SCC: configuration des dépendances des ressources disques Test des bascules Lancement du Setup pour installation du rôle Mailbox Création du DAG est réplication des bases Déploiement Exchange 2007 et précédents (CCR/SCC) Préparation du matériel, installation de l’OS et mise à jour Pour le SCC: configuration du stockage Construction du Cluster windows Configuration du quorum, du file share witness, et des réseaux public etprivate Lancement du Setup est installation du role mailbox sur le cluster Configuration du rôle mailbox Pour le SCC: configuration des dépendances des ressources disques Test des bascules

31 Déploiement incrémental d’Exchange 2010
Création du DAG New-DatabaseAvailabilityGroup -Name DAG1 –WitnessServer EXHUB1 -WitnessDirectory C:\DAG1FSW -DatabaseAvailablityGroupIpAddresses New-DatabaseAvailabilityGroup -Name DAG2 -DatabaseAvailablityGroupIpAddresses , Ajout du premier serveur dans le DAG Add-DatabaseAvailbilityGroupServer -Identity DAG1 -MailboxServer EXMBX1 Ajout du second serveur dans le DAG Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EXMBX2 Ajout d’une copie de base de données Add-MailboxDatabaseCopy -Identity MBXDB1 -MailboxServer EXMBX3

32 Migration vers une solution HA Exchange 2010

33 Transition Steps Vérification des prérequis Exchange 2010
Déploiement des serveurs Exchange 2010 Utilisation des fonctionnalités de déplacement de boites aux lettres d’Exchange 2010 Migrations non supportées Mise à jour sur place depuis les versions précédentes Impossibilité d’utiliser le portage de bases de données entre des serveurs Exchange 2010 et non Exchange 2010 Backup et restore depuis les versions précédentes d’Exchange 2010 Utilisation de la réplication entre Exchange 2010 et Exchange 2007

34 Exemples d’architecture HA sous Exchange Server 2010

35 Client Access Hub Transport Mailbox
Exemple d’architecture HA Scenario Branch Office / Petite structure Répartiteur de charge matériel 8 cœurs processeurs recommandés avec un maximum de 64Go RAM Client Access Hub Transport Mailbox Client Access Hub Transport Mailbox Les membres des DAG peuvent héberger d’autres rôles Role UM co-localisé non recommandé DB1 DB1 Un DAG deux nœuds doit utiliser un stockage en RAID DB2 DB2 DB2 DB3 DB3

36 Database Availability Group
Exemple de HA Double secours– Maintenance + panne de base AD: Dublin 2 serveurs HS-> activation manuelle du 3ème serveur Dans une configuration à 3 serveurs, le Quorum est perdu Les DAGs avec plus de noeuds supportent plus de pannes Un seul site 3 Noeuds 3 Copies CAS NLB Farm X JBOD Mailbox Server 1 Mailbox Server 2 Mailbox Server 3 X DB1 DB2 DB3 DB1 DB2 DB3 DB1 DB2 DB3 DB4 DB5 DB6 DB4 DB5 DB6 DB4 DB5 DB6 Database Availability Group

37 Database Availability Group (DAG)
Exemple de HA Triple secours– Maintenance + panne de serveur +panne de base AD: Dublin Mise à jour du serveur 1 Panne du serveur 2 Mise à jour du serveur 1 terminée 2 copies HS Un seul site 4 Noeuds 3 copies JBOD CAS NLB Farm X Mailbox Server 1 Mailbox Server 2 Mailbox Server 3 Mailbox Server 4 X DB3 DB5 DB6 DB3 DB4 DB1 DB2 DB7 DB8 DB1 DB7 DB5 DB4 DB5 DB3 DB4 DB6 DB7 DB8 DB6 DB2 DB8 DB1 DB2 Database Availability Group (DAG)

38 Database Availability Group (DAG)
Exemple de HA 6 Serveurs 24,000 Mailboxes Heavy Profile: 100 Messages/day MAPI network .1 IOPS/Mailbox 2GB Mailbox Size 8 Cores 48 GB RAM 8 Cores 48 GB RAM Replication network 4,000 Active Mbxs/Svr Mbx Server 1 Mbx Server 2 6 Servers, 3 Copies = double server failure resiliency DB1 DB2 DB3 DB4 DB5 DB6 DB31 DB32 DB33 DB46 DB47 DB48 DB49 DB50 DB51 DB52 DB53 DB54 DB7 DB8 DB9 DB10 DB11 DB12 DB34 DB35 DB36 DB1 DB55 DB56 DB57 DB58 DB59 DB60 DB61 DB62 DB63 4,000 Active Mbxs/Svr 1st failure: ~5,000 active DB13 DB14 DB15 DB16 DB17 DB18 DB37 DB38 DB39 DB64 DB65 DB66 DB67 DB68 DB69 DB70 DB71 DB72 2nd failure: 6,000 active DB1 Soft active limit: 24 DB19 DB20 DB21 DB22 DB23 DB24 DB40 DB41 DB42 DB73 DB74 DB75 DB76 DB77 DB78 DB79 DB80 DB81 DB25 DB26 DB27 DB28 DB29 DB30 DB43 DB44 DB45 DB82 DB83 DB84 DB85 DB86 DB87 DB88 DB89 DB90 1TB 7.2k SATA disks JBOD: 48 Disks/node Online Spares (3) Database Availability Group (DAG) 288 disks total 30 TB of db space Battery Backed Caching Array Controller Active copy Passive copy Spare Disk Legend

39 Conclusion Meilleur solution de HA de bout en bout
Solution identique pour la HA et le site de secours Plus facile et plus simple à déployer Réduction du TCO grâce aux changement d’architecture de stockage Support de larges boites aux lettres pour un coût inférieur

40 Questions / Réponses

41 Required Slide © 2009 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.


Télécharger ppt "Christophe Leroux IT Architect Microsoft France"

Présentations similaires


Annonces Google