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

1 Guillaume Bordier Philippe Maurent Microsoft Services France

Présentations similaires


Présentation au sujet: "1 Guillaume Bordier Philippe Maurent Microsoft Services France"— Transcription de la présentation:

1 1 Guillaume Bordier Philippe Maurent Microsoft Services France

2 2 Nouvelle approche du stockage Une toute nouvelle approche de la haute disponibilité : plus de SPOF ni SAN, ni RAID, ni Backup ?

3 3

4 4 Premier facteur de coût de linfrastructure Le besoin en performances (IOPS) croit avec la taille de la boite aux lettres Impact de la mise en tolérance à la panne du stockage Les solutions darchivage sont souvent vues comme le moyen de limiter la taille de la boîte.

5 5 Sadapte aux configurations jusquà plusieurs millions de boites. Une boite de 10 GB avec Exchange 2010 consomme autant quune boite de 200MB Moins dIO (random) Grosses boites aux lettres peu couteuses Optimisation pour les disques peu couteux (SATA) Flexibilité du stockage Haute dispo logicielle

6 6 Contigüité logique, physique et temporelle (Schéma) Adaptation du moteur ESE Taille des IOs -> 32 KB OLD2, Checkpoint depth = 100MB Algorithmique du cache lecture en avance Groupement des écritures.. Version Courte Version Courte Version Courte Version Courte Version Longue Version Longue Version Longue Version Longue

7 7 Passer dIos random à séquentielles ElémentExchange Server 2007 Exchange Server 2010 (Beta) Physical Contiguity (ESE) Pas de gestion de la contigüité physique des pages : 1 IO = 1 page Bonne contigüité : 1 I/O = environ 100 pages. Logical Contiguity (Store) Les en-têtes des messages sont stockées dans une table par dossier : beaucoup de petites I/O réparties sur beaucoup de tables Les en-têtes de toutes les boites sont dans la même table : de plus grosses IO. Temporal Contiguity (View) Toutes les vues et index sont mis à jour à chaque fois quun message est délivré : beaucoup dIO random en permanence Les vues et index ne sont mis à jour que quand lutilisateur y accède: de grosses I/O sur les mêmes zones du disque moins souvent Schéma

8 8 8 Exchange Server 2007 Message/Folder Table (MFT) Joe:Inbox:H1 Joe:Inbox:H2 Joe:Inbox:H3 Per Database Per Folder Mailbox Table Jeffs Mbx Anns Mbx Joes Mbx Attachments Table Jeff:Excel.xls Ann:Pic.bmp Joe:Help.doc Message Table (Msg) Joe:Msg10 Jeff:Msg32 Ann:Msg180 Folders Table Jeff:Inbox Ann:Drafts Joe:Unread Exchange Server 2010 (Beta) View Tables (e.g. From) Joe:H920 Joe:H302 Joe:H10 Secondary Indexes used for Views Per Mailbox Mailbox Table Jeffs Mbx Anns Mbx Joes Mbx Message Header Table Joe:H10 Joe:H302 Joe:H920 Folders Table Joe:Inbox Joe:Drafts Joe:Unread Per Database Nouveau Schéma : plus de Single Instance du tout Per View Body Table Joe:Msg10 Joe:Help.doc Joe:Msg302 Schéma

9 9 Adaptation au nouveau schéma Compression de page Défragmentation permanente Alloue lespace en fonction de la contigüité Cache plus intelligent 100MB checkpoint depth (40% moins de writes) Compression du cache Espacer les écritures pour en faire moins Taille de page : 32K ESE

10 10 Optimisation de lallocation despace Allocation en fonction de la contigüité ou de la fragmentation (en fonction de relevé dusage) Page 1 Used Page Page 3 Used Page Disk DB Cache Page X Msg Header Page Y Msg Header Page Z Event History Contiguity Space Contiguity Space Compactness Page 4 Msg Header Page 5 Msg Header Page 2 Event History Sequential/Bloat Random/Compact ESE

11 11 New Database Maintenance Architecture: ESE FunctionExchange Server 2007 Service Pack 1 (SP1) Exchange Server 2010 (Beta) Cleanup (deleted items/mailboxes) Cleanup performed during Online Defrag (OLD) which occurs during Online Maintenance (OLM) time window Cleanup performed at run time (when hard delete occurs)happens during Store dumpster cleanup (OLM), pages are zeroed by default Space Compaction (deleted items/mailboxes) Database is compacted and space reclaimed during Online Defrag (OLD) Database is compacted and space reclaimed at run-timeauto-throttled Maintain Contiguity (defragmentation) N/A: Contiguity is compromised by space compaction Database is analyzed for contiguity and space at run time and is defragmented in the background (B+Tree Defrag/OLD2)auto- throttled Database ChecksumWhen configured, ½ of OLD maintenance window reserved for sequential scan (Checksum), manual throttleactive DB copy only Two options (both Active and Passive copies): 1.Run DB Checksum in the background 24x7 (default). Sequential IO 2.Run DB Checksum during OLM window. Sequential IO ESE

12 12 Problème : Grossissement de la base de 20% (Nouveau Schéma, la defragmentation et les pages de 32 KB) Solution : Compression de page (header et body) CountsE2K7 SP1E2010 Mailbox Count750 Tables Secondary Indexes Pages Used Pages (%)85.7%86.7% Available Pages (%)14.3%13.3% Msg Table (% space)84.9%80.0% 1 Database, 750 x 250MB mailboxes RTF = RTF Compressed, Mix = 77% HTML, 15% RTF, 8% Text Avg. Message size = ~50KB Msg Views 32KB Pages DB Space AnalysisDB File Size Comparison ESE

13 13 Page 1 Msg Header Page 2 X Page 3 Msg Body Disk Page 4 X Page 5 Msg Body DB Cache Page 1 Msg Header Page 3 Msg Body Page 5 Msg Body 3 Read IOs Page 1 (32KB) Msg Header, Msg Body Disk DB Cache 1 Read IO Exchange Server 2007 DB Read 20 KB Message Exchange Server 2010 (Beta) DB Read 20 KB Message 8 KB Pages 32 KB Pages Page 2 (32KB) X Page 1 (32KB) Msg Header, Msg Body Cache 13

14 14 Page 1 Msg Header Page 2 X Page 3 Msg Body Disk Page 4 X Page 5 Msg Body Exchange Server 2007 DB Exchange Server 2010 (Beta) DB DB Cache Page 1 Msg Header Page 3 Msg Body Page 5 Msg Body 3 Read IOs Page 1 Msg Header Page 2 X Page 3 Msg Body Disk Page 4 X Page 5 Msg Body DB Cache Page 1 Msg Header Page 3 Msg Body Page 5 Msg Body Page 2 Temp Buffer Page 4 Temp Buffer 1 Read IO Cache

15 15 Page 1 Dirty Page 2 Clean Page 3 Dirty Disk Page 4 Clean Page 5 Dirty Exchange Server 2007 DB Write Behavior 3 Write IOs Page 1 Dirty Page 2 Clean Page 3 Dirty Disk Page 4 Clean Page 5 Dirty Exchange Server 2010 (Beta) DB Write Behavior 1 Write IO DB Cache Espacement des écritures dans le temps Cache 15

16 16 Les pics décriture sur la base affectent les lectures de base et augmentent la latence décriture sur les logs Plus il y a décriture, plus il y a de contention Single 7.2k SATA disk, logs/db on same spindle, Loadgen load generating 250 RPC Operations/second, ~50 IOPS E2K7=96 Maximum write Queue depth (global) Log Write IO ESE

17 17 Throttle DB writes based on checkpoint target (QoS) When checkpoint depth equals 1x ->1.24x of checkpoint target, Limit Max Outstanding DB writes/LUN to 1 When checkpoint depth meets or exceeds 1.25x of checkpoint target, ratchet up max outstanding DB writes/LUN The further behind on checkpoint, the more aggressively we raise the max outstanding DB writes/LUN (maximum = 512/LUN) Works for both JBOD SATA and RAID10 SAN! 20 MB Max Checkpoint Example ESE

18 18 24,000 profils très lourd, Mode cache, 2Go par boite, Rack/Cablage non inclus

19 19 Boite darchive en ligne dans Exchange 2010 Optimisé pour le DAS, mais le Stockage SAN est supporté Réduction des I/Os et contrôle des burst permet dutiliser des disques SATA Une architecture de tolérance à la panne moins complexe et donc moins chère Nous supportons le stockage JBOD* ou RAID storage Exchange Server 2010 (Beta) optimisé pour les disques grand public SSD/Flash supportés mais non recommandés - raisons de coût 100 Bases par serveur, plus de storage group Taille de base maximum recommandée 2 TB* Nombre déléments par dossier maximum recommandé (Outlook Online ou OWA) : *3 copy High Availability only

20 20

21 SCC LCR CCR File Share SCR Site 1 Site 2

22 DAG Database Availability Group

23 23 Accès client : Client Access Array Le client se connecte au nom du Client Access Array (nom LB) Le CAS est la terminaison RPC du client et se connecte à son tour au DAG Transport Redundancy Shadow Queue/Transport Dumpster, les messages sont conservés sur un HUB tant que le next hop na pas confirmé la délivrance (commande SMTP XSHADOW) Base de données : Data Availability Group Jusquà 16 instances répliquées dune même base dans un DAG Active Manager : Bascule automatique dune copie vers lautre

24 24 Technologie «Single Copy Cluster » abandonnée: => un serveur est toujours le seul à accéder à une base Technologies xCR remplacée par le DAG Fiabilisation Sockets TCP à la place de SMB La source « pousse » les fichiers logs sur les cibles LLR est de nouveau à 1 Un DAG est un ensemble de serveurs (jusquà 16) Windows Failover Clustering utilisé de manière transparente Une base peut être répliquée sur chacun des serveurs DAG

25 25 Ajouter un nœud dans un DAG DAG

26 26 Ajouter un membre dans le DAG est facile, ne nécessite pas de réinstallation, tout est automatique Passage dun modèle de Quorum à un autre Démo PPT Démo PPT Démo PPT Démo PPT Suite du PPT Suite du PPT Suite du PPT Suite du PPT DAG

27 27

28 28 DAG

29 29 Autres avantages Passer dun MBX normal à un membre de DAG sans réinstallation Configuration de réplication base par base à la demande Pas de contraintes darchitecture réseau Single-copy cluster (cluster classique) Cluster Continuous Replication Exchange Server 2010 High Availability Granularity de basculementServeur Base de donnée Nombre de copie de bases122 à 16 Temps de bascule~2 min ~30 sec (POR) Contrôle de basculeWindows Cluster Exchange Server Data replicationTechnologie non MS (SRDF, VVM..) Continuous replication Outil dadministrationSéparé intégré Compatible avec dautres rôles ?Non Oui DAG

30 30 Exchange 2007 Outlook Clients MBX Exchange Server 2010 (Beta) Exchange CAS NLB Outlook Clients Failover: Client disconnected for 0-TTL minutes MBX1MBX2 Failover: Connected client disconnected for 30 seconds (POR) CAS Failure: Client just reconnects DAG

31 31 Mailbox Server Node 1 Mailbox Server Node 2 Database Availability Group (DAG) Page1 Page2 Page3 Mailbox Server Node 3 1.Page corruption detected on Active Copy (e.g ) 2.Active DB places marker in log stream to notify passive copies to ship up to date page 3.Passive receives log and replays up to marker, retrieves good page, invokes Replay Service callback and ships page 4.Active receives good page, writes page to log, DB page is patched DB1-Active Database Log Page1 Page2 Page3 DB1-CopyA Database Log Page1 Page2 Page3 DB1-CopyB Database Log 5.Subsequent page repair from additional copies ignored DAG

32 32 Mailbox Server Node 1 Mailbox Server Node 2 Database Availability Group (DAG) Page1 Page2 Page3 Mailbox Server Node 3 1.Page corruption detected on DB Passive Copy (e.g ) 2.Passive copy pauses log replay (log copying continues) 3.Passive retrieves the corrupted page # from the active using DB seeding infrastructure 4.Passive copy waits till log file which meets max required generation requirement is copied/inspected, then patches page DB1-Active Database Log Page1 Page2 Page33 DB1-CopyA Database Log Page1 Page2 Page3 DB1-CopyB Database Log 5.Passive resumes log replay DAG

33 Defines properties applicable to an individual database copy Copy status: Healthy, Initializing, Failed, Mounted, Dismounted, Disconnected, Suspended, FailedandSuspended, Resynchronizing, Seeding CopyQueueLength ReplayQueueLength ActiveCopy ActivationSuspended 33 DAG

34 34 Primary Active Manager (PAM) Sexécute sur le noeud du cluster qui possède le Default cluster Group Détecte les changements de topologie Réagit aux défaillance de serveurs Sélectionne la meilleure base à activer Standby Active Manager (SAM) Sexécute sur tous les membres du DAG Réponds aux requêtes des autres composants Exchange sur létat de la réplication et de lactivation des bases DAG

35 35 Plus de streaming backup Plus de SCC (Single Copy Cluster) Préconisations : Stockage DAS pour des raisons de coût DAG pour la haute disponibilité Noms unique pour les bases dans toute lorganisation (obligatoire) Combiner base et logs sur les même disques nest plus un problème A partir de 3 copies de base Le RAID devient optionnel On peut combiner Support de très grosses boîtes 1 à 2 ans de données dans la boîte active Le reste dans la boîte darchive Office 2007 Service Pack 2 (SP2) minimum (Taille.OST !) DAG

36 36 DB1 DB1 DB1 DB1 DB1DB2DB3DB4DB5DB6 DB7DB8DB9DB10DB11DB12 DB13DB14DB15DB16DB17DB18 DB19DB20DB21DB22DB23DB24 DB25DB26DB27DB28DB29DB30 Legend Active copyPassive copySpare Disk DB1 DB1 DB1 DB1 DB1DB2DB3DB4DB5DB6 DB7DB8DB9DB10DB11DB12 DB13DB14DB15DB16DB17DB18 DB19DB20DB21DB22DB23DB24 DB25DB26DB27DB28DB29DB30 DB1 DB1 DB1 DB1 DB1DB2DB3DB4DB5DB6 DB7DB8DB9DB10DB11DB12 DB13DB14DB15DB16DB17DB18 DB19DB20DB21DB22DB23DB24 DB25DB26DB27DB28DB29DB30 Mbx Server 1 10,000 mailboxes 3,333 active mailboxes/server 3 nodes, 3 copies = secondary failure resiliency 8 Cores 32 GB RAM 8 Cores 32 GB RAM 8 Cores 32 GB RAM 2 GB mailbox size.11 IOPS/mailbox 1TB 7.2k disks (SAS/SATA) online spares battery backed caching array controller heavy Profile: 120 messages/day JBOD: 30 disks/node Database Availability Group (DAG) Mbx Server 2Mbx Server 3 DAG

37 37 « Une vraie architecture multi-tiers » CAS

38 38 Middle Tier XSO MAPI.Net Mailbox MAPI RPC Store Exchange Components OWA Sync UM Transport Agents Mailbox Agents WS Entourage Outlook / MAPI clients DAV Middle Tier MAPI RPC MAPI.Net Core Objects XSO Mailbox MAPI RPC Store Exchange Components OWA Sync UM Transport Agents Mailbox Agents WS Outlook / MAPI clients Entourage DSPROXY NSPI CAS

39 39 Nouveau ratio CAS:MBX 3:4 !!! Le CAS devient le point de connexion des clients pour tous les protocoles: MAPI (MoMT et DoMT) Outlook Anywhere OWA/ActiveSync/IMAP/POP/EWS/Entourage MoMT détecte le serveur disposant de la copie de base valide et effectue la connexion et gère un pool de 100 connexions avec chaque MBX Exchange Server 2010 (Beta) CAS dans chaque site où un MBX 2010 est présent Haute Disponibilité Hardware Load-Balancer obligatoire sur les serveurs CAS+MBX Car NLB nest pas compatible avec WFC HLB conseillé au delà de 8 CAS dans la ferme OCS 2007 R2 obligatoire pour lintégration OWA/OCS (Présence & IM/Chat) OWA 2010 ne permet daccéder quaux Dossiers Publics E2010 CAS

40 40 « Garantir la livraison du message »

41 41 Participation étendue des serveurs Hub Transport à la fourniture de la haute disponibilité: Transport Redundancy (Nouveau) Shadow Queues Mailbox Server resubmission Transport Dumpster (améliorations) Basé sur la santé des bases Transport

42 42 Le Transport Shadow Queue fournit une solution supplémentaire au Transport Dumpster Les messages sont conservés sur le serveur précédent jusqu'à ce qu'il soit délivé plus loin Lorsqu'une erreur est détectée (timeout), le serveur précédent redélivre (à un autre HUB par exemple) Des extensions SMTP sont utilisées (XSHADOW, XDISCARD) Génère un léger overhead dans le dialogue Nécessite une chaine de serveurs SMTP Exchange 2010 (Hub Transport, Edge Transport) Le Submission service sur le MBX resoumets les messages si le HUB na pas émis davis de réception Transport

43 43 Diminution des IOPS supplémentaire dues au Dumpster Purge du Dumpster en fonction de létat de la réplication de base Vérification à intervalle régulier par l'Active Manager du LastLogInspected pour chaque copie de DB Considère la "plus vieille" copie dans le DAG et utilise cette information comme "référentiel" (dumpster watermark) pour chacune des DBs (plus petit dénominateur commun pour une DB donnée) Les éléments plus anciens que le "référentiel" de la DB sont supprimés du dumpster (processus de feeback régulier) La taille du Transport Dumpster est donc adaptée à partir des éléments de latence de réplication et de la fréquence de feedback Les requêtes de resoumissions ne renvoient que les items plus récents que le "référentiel" (dumptser watermark) Transport

44 44 Les serveurs MBX 2010 ne peuvent communiquer quavec des HUB 2010 Communication possible entre HUB 2010 et HUB 2007 Un HUB 2010 dans chaque site ou un MBX 2010 est présent Pas besoin de RAID sur les files dattente car le HUB grâce au Shadow Queue Transport

45 45

46 46 Site S1Site S2 Jean- Paul Clint Roberto XSHADOWXDISCARD Jean-Paul envoie un mail à Roberto Jean-Paul envoie un mail à Clint Démo PPT Démo PPT Démo PPT Démo PPT Suite de la présentation Suite de la présentation Suite de la présentation Suite de la présentation

47 47

48 48

49 49 Architecture totalement « stateless », on peut perdre définitivement nimporte quelle machine sans jamais perdre un message MBX => DAG + Dumpster HUB => Shadow CAS => stateless par nature 100 users x 10 GB = 3 disques SATA à 100/disque !

50 50 Single Site 4 Nodes 3 HA Copies JBOD -> 3 physical Copies Database Availability Group (DAG) Mailbox Server 1 Mailbox Server 2 Mailbox Server 3 X Mailbox Server 4 X Upgrade server 1 Server 2 fails Server 1 upgrade is done 2 active copies die DAG

51 51 SAN Le SAN était obligatoire pour le SCC Exchange 2010 na plus besoin du même niveau de performances Il est désormais possible daugmenter le service à lutilisateur (taille de sa boîte) en maîtrisant le coût du stockage « Si ça marche sur un SATA 7200 en DAS, ça marchera aussi sur un SAN » Mécanismes de snaps ? RAID : à partir de 3 copies de bases, Microsoft supporte le RAID-less Réparation de page dynamique, détection derreurs Être en mesure de supporter un reseed complet dans certains cas Backup Combien de fois effectuez-vous des restauration de boites aux lettres de plus de 30 jours? Possibilité davoir une base en « retard » de 14 jours

52 52

53 53 © 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.

54 54 Storage GuidanceStand AloneExchange Server (Beta) 2010 HA (2 copies) Exchange Server 2010 (Beta) HA (3+ copies) Storage TypeDAS, SAN (Fibre Channel, iSCSI) Disk TypeSAS, Fibre Channel, SATA (with battery backed cache), SSD RAIDRAID recommendedRAID optional RAID TypeRAID-1/0, RAID-5, RAID-6JBOD DB/Log IsolationBest PracticeNot required Windows Disk TypeBasic (recommended), Dynamic Partition TypeGPT (recommended), MBR Partition AlignmentWindows 2008 Default (1MB) File SystemNTFS NTFS Allocation Unit Size 64 KB for both database and log volumes Encryption SupportOutlook Protection Rules, Bitlocker


Télécharger ppt "1 Guillaume Bordier Philippe Maurent Microsoft Services France"

Présentations similaires


Annonces Google