1

Haute disponibilité et stockage pour Exchange Server 2010

Guillaume BordierPhilippe MaurentMicrosoft Services Francehttp://blogs.technet.com/frmcsuc

2

Introduction

Nouvelle approche du stockageUne toute nouvelle approche de la haute disponibilité : plus de SPOF

ni SAN, ni RAID, ni Backup ?

3

Stockage Exchange 2010

4

Le stockage avant Exchange 2010

Premier facteur de coût de l’infrastructure

Le besoin en performances (IOPS) croit avec la taille de la boite aux lettresImpact de la mise en tolérance à la panne du stockageLes solutions d’archivage sont souvent vues comme le moyen de limiter la taille de la boîte.

5

Exchange Server 2010 (Beta) Storage Vision

S’adapte aux configurations jusqu’à plusieurs millions de boites.Une boite de 10 GB avec Exchange 2010 consomme autant qu’une boite de 200MB

Moins d’IO(random)

Grosses boites aux lettres peu

couteuses

Optimisation pour les

disques peu couteux (SATA)

Flexibilité du stockage

Haute dispo logicielle

6

Nouveautés pour le stockage

Contigüité logique, physique et temporelle (Schéma)Adaptation du moteur ESE

Taille des IOs -> 32 KBOLD2, Checkpoint depth = 100MB

Algorithmique du cache lecture en avanceGroupement des écritures..

Version Courte Version Longue

7

Réduction d’IO : Schéma

Passer d’Ios random à séquentielles

Elément Exchange 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 qu’un message est délivré : beaucoup d’IO random en permanence

Les vues et index ne sont mis à jour que quand l’utilisateur y accède: de grosses I/O sur les mêmes zones du disque moins souvent

Schéma

8

IO Reduction: Store Table Architecture

8

Exchange Server 2007

Message/Folder Table (MFT)

Joe:Inbox:H1

Joe:Inbox:H2

Joe:Inbox:H3

Per Database Per Folder

Mailbox Table

Jeff’s Mbx

Ann’s Mbx

Joe’s 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

Per Mailbox

Mailbox Table

Jeff’s Mbx

Ann’s Mbx

Joe’s 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

Modifications ESE (moteur)

Adaptation au nouveau schémaCompression de pageDéfragmentation permanenteAlloue l’espace en fonction de la contigüité

Cache plus intelligent100MB checkpoint depth (40% moins de writes)Compression du cacheEspacer les écritures pour en faire moinsTaille de page : 32K

ESE

10

Allouer l’espace en fonction de la contigüité

Optimisation de l’allocation d’espaceAllocation en fonction de la contigüité ou de la fragmentation (en fonction de relevé d’usage)

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/BloatRandom/CompactESE

11

Maintenance en ligneNew Database Maintenance Architecture:

ESE Function Exchange 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-time—auto-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 Checksum When configured, ½ of OLD maintenance window reserved for sequential scan (Checksum), manual throttle—active DB copy only

Two options (both Active and Passive copies):1. Run DB Checksum in the background

24x7 (default). Sequential IO2. Run DB Checksum during OLM

window. Sequential IO

ESE

12

Contrebalancer le grossissementProblè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)

E2K7/RTF E14/RTF E14/Mix E14/HTML0.000.200.400.600.801.001.201.40

1.001.20

1.000.88

Counts E2K7 SP1 E2010

Mailbox Count 750 750

Tables 14.754 92.435

Secondary Indexes 85.784 4.557

Pages 28.486.144 5.814.032

Used Pages (%) 85.7% 86.7%

Available Pages (%) 14.3% 13.3%

Msg Table (% space) 84.9% 80.0%

1 Database, 750 x 250MB mailboxesRTF = 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

Réduction des LecturesAugmentation de la taille de page à 32 KB

Page 1

Msg Header

Page 2

X

Page 3

Msg Body

Disk

Page 4

X

Page 5

MsgBody

DBCache

Page 1

Msg Header

Page 3

Msg Body

Page 5

MsgBody

3 Read IO’s

Page 1 (32KB)

Msg Header, Msg Body

Disk

DBCache

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

Cache13

14

Réduction des lecturesLecture en avance

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

DBCache

Page 1

Msg Header

Page 3

Msg Body

Page 5

Msg Body

3 Read IO’s

Page 1

Msg Header

Page 2

X

Page 3

Msg Body

Disk

Page 4

X

Page 5

Msg Body

DBCache

Page 1

Msg Header

Page 3

Msg Body

Page 5

Msg Body

Page 2

Temp Buffer

Page 4

TempBuffer

1 Read IO

Cache

15

Réduction des écritures (dans la base)espacer les écritures et les grouper

Page 1

Dirty

Page 2

Clean

Page 3

Dirty

Disk

Page 4

Clean

Page 5

Dirty

Exchange Server 2007 DB Write Behavior

3 Write IO’s

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

DB Cache

Espacement des écritures dans le temps

Cache15

16

Optimisé pour le SATA: Smooth Database Write IO

Les pics d’écriture sur la base affectent les lectures de base et augmentent la latence d’écriture sur les logsPlus il y a d’écriture, plus il y a de contention

2 4 8 16 32 640

20

40

60

80

100

120

18 2031 35 40 42

6369

80 8591

114

IO Latency Based on Max DB Write IO’s (ms)

Maximum DB Write IO's Is-sued

Latency (ms)

DB Read IO

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

Optimize for SATASmooth DB Write IO

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 1When checkpoint depth meets or exceeds 1.25x of checkpoint target, ratchet up max outstanding DB writes/LUNThe 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

25.5

26.5

27.5

28.5

29.5

30.5

31.5

32.5

33.5

34.5

35.5

36.5

37.5

38.5

39.5

40.5

41.5

42.5

43.5

0

5

10

15

20

25

30

35

40 Max Outstanding DB Writes vs. Checkpoint Depth

Log Checkpoint Depth (MB)Log Checkpoint Depth (MB)

Max O

uts

tan

din

g D

B

Wri

tes

ESE

19

Exchange Server 2010 (Beta) : Flexibilité

Boite d’archive “en ligne” dans Exchange 2010Optimisé pour le DAS, mais le Stockage SAN est supporté

Réduction des I/Os et contrôle des burst permet d’utiliser des disques SATAUne architecture de tolérance à la panne moins complexe et donc moins chère

Nous supportons le stockage JBOD* ou RAID storageExchange Server 2010 (Beta) optimisé pour les disques grand publicSSD/Flash supportés mais non recommandés - raisons de coût100 Bases par serveur, plus de storage groupTaille de base maximum recommandée 2 TB*Nombre d’éléments par dossier maximum recommandé(Outlook Online ou OWA) : 100.000

*3 copy High Availability only

20

Haute Disponibilité : une nouvelle approche

Haute disponibilité Exchange 2007

SCC LCR

CCR

FileShare

SCRSite 1

Site 2

Haute disponibilité Exchange 2010

DAGDatabase Availability Group

23

Eléments de la Haute Dispo

Accès client : Client Access ArrayLe 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 n’a pas confirmé la délivrance (commande SMTP XSHADOW)

Base de données : Data Availability GroupJusqu’à 16 instances répliquées d’une même base dans un DAGActive Manager : Bascule automatique d’une copie vers l’autre

24

DAG : Adieu xCR, Adieu SCC

Technologie «Single Copy Cluster » abandonnée:=> un serveur est toujours le seul à accéder à une base

Technologies xCR remplacée par le DAGFiabilisationSockets TCP à la place de SMBLa source « pousse » les fichiers logs sur les ciblesLLR 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

Ajouter un nœud dans un DAG

Demo

DAG

26

Ajouter un membre dans le DAG

Ajouter un membre dans le DAG est facile, ne nécessite pas de réinstallation, tout est automatiquePassage d’un modèle de Quorum à un autre

Démo PPT Suite du PPTDAG

27

Ajouter un membre au DAG

28

Exchange Server 2010 (Beta)Les databases sont des objets déclarés au niveau Org.

DAG

29

MailboxChangements pour la haute disponibilité

Autres avantagesPasser d’un MBX “normal” à un membre de DAG sans réinstallation Configuration de réplication base par base à la demandePas de contraintes d’architecture réseau

Single-copy cluster(cluster

“classique”)

Cluster Continuous Replication

Exchange Server 2010 High Availability

Granularity de basculement Serveur Serveur Base de donnée

Nombre de copie de bases 1 2 2 à 16

Temps de bascule ~2 min ~2 min ~30 sec (POR)

Contrôle de bascule Windows Cluster Windows Cluster Exchange Server

Data replication Technologie non MS (SRDF, VVM ..)

Continuous replication

Continuous replication

Outil d’administration Séparé Séparé intégré

Compatible avec d’autres rôles ?

Non Non Oui

DAG

30

Exchange 2007

Outlook Clients

MailboxBetter Client Experience

MBX MBX

Exchange Server 2010 (Beta)

Exchange CAS NLB

Outlook Clients

Failover:Client

disconnected for 0-TTL minutes

MBX1 MBX2

Failover:Connected

client disconnected

for 30 seconds (POR)

CAS Failure:

Client just reconnects

DAG

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. -1018)

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

JBOD/RAID-less Storage: Single Page Restore (Active)

DAG

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. -1018)

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

JBOD/RAID-less Storage: Single Page Restore (Passive)

DAG

33

Exchange Server 2010 (Beta) HA FundamentalsMailbox Database CopyDefines properties applicable to an individual database copy

Copy status: Healthy, Initializing, Failed, Mounted, Dismounted, Disconnected, Suspended, FailedandSuspended, Resynchronizing, SeedingCopyQueueLengthReplayQueueLength

ActiveCopyActivationSuspended

DAG

34

Active Manager

Primary Active Manager (PAM)S’exécute sur le noeud du cluster qui possède le “Default cluster Group”Détecte les changements de topologieRéagit aux défaillance de serveursSélectionne la meilleure base à activer

Standby Active Manager (SAM)S’exécute sur tous les membres du DAGRéponds aux requêtes des autres composants Exchange sur l’état de la réplication et de l’activation des bases

DAG

35

MailboxPoints d’architecture

Plus de streaming backup Plus de SCC (Single Copy Cluster)Préconisations :

Stockage DAS pour des raisons de coûtDAG pour la haute disponibilitéNoms unique pour les bases dans toute l’organisation (obligatoire)Combiner base et logs sur les même disques n’est plus un problèmeA partir de 3 copies de base

Le RAID devient optionnelOn peut combiner

Support de très grosses boîtes1 à 2 ans de données dans la boîte active Le reste dans la boîte d’archiveOffice 2007 Service Pack 2 (SP2) minimum (Taille .OST !)

DAG

36

Exchange Server 2010 (Beta) HA/JBOD Storage Example: Single Site (or more), 3 Nodes, 3 Copy DAG

DB1 DB1

DB1 DB2 DB3 DB4 DB5 DB6

DB7 DB8 DB9 DB10

DB11

DB12

DB13

DB14

DB15

DB16

DB17

DB18

DB19

DB20

DB21

DB22

DB23

DB24

DB25

DB26

DB27

DB28

DB29

DB30

Legend

Active copy Passive copy Spare Disk

DB1 DB1

DB1 DB2 DB3 DB4 DB5 DB6

DB7 DB8 DB9 DB10

DB11

DB12

DB13

DB14

DB15

DB16

DB17

DB18

DB19

DB20

DB21

DB22

DB23

DB24

DB25

DB26

DB27

DB28

DB29

DB30

DB1 DB1

DB1 DB2 DB3 DB4 DB5 DB6

DB7 DB8 DB9 DB10

DB11

DB12

DB13

DB14

DB15

DB16

DB17

DB18

DB19

DB20

DB21

DB22

DB23

DB24

DB25

DB26

DB27

DB28

DB29

DB30

Mbx Server 1

10,000 mailboxes

3,333 active mailboxes/server3 nodes, 3 copies = secondary failure resiliency

8 Cores32 GB RAM

8 Cores32 GB RAM

8 Cores32 GB RAM 2 GB mailbox

size

.11 IOPS/mailbox

1TB 7.2k disks (SAS/SATA)

online sparesbattery backedcaching array controller

heavy Profile: 120 messages/day

JBOD: 30 disks/nodeDatabase Availability Group (DAG)

Mbx Server 2

Mbx Server 3

DAG

37

Client Access Server

« Une vraie architecture multi-tiers »

CAS

38

Client AccessConsolidation of Store Access Paths

Mid

dle

Tier

XSOMAPI.Net

Mai

lbo

x

MAPI RPC

Store

Exchange Components

OWA

SyncUM

Transport Agents

Mailbox Agents

WS

Entourage

Outlook / MAPI clients

DAVM

iddl

eTi

er

MAPI RPC

MAPI.Net

Core Objects

XSO

Mai

lbox MAPI RPC

Store

Exchange Components

OWA

SyncUM

Transport Agents

Mailbox Agents

WS

Outlook / MAPI clients

Entourage

Exchange Server 2007

Exchange Server 2010 (Beta)

DSP

ROXY

NSP

I

CAS

39

Client AccessPoints d’architecture

Nouveau ratio CAS:MBX 3:4 !!!Le CAS devient le point de connexion des clients pour tous les protocoles:

MAPI (MoMT et DoMT)Outlook AnywhereOWA/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 MBXExchange Server 2010 (Beta) CAS dans chaque site où un MBX 2010 est présentHaute Disponibilité

Hardware Load-Balancer obligatoire sur les serveurs CAS+MBXCar NLB n’est pas compatible avec WFCHLB conseillé au delà de 8 CAS dans la ferme

OCS 2007 R2 obligatoire pour l’intégration OWA/OCS (Présence & IM/Chat)OWA 2010 ne permet d’accéder qu’aux Dossiers Publics E2010

CAS

40

Hub Transport

« Garantir la livraison du message »

41

Hub Transport

Participation étendue des serveurs Hub Transport à la fourniture de la haute disponibilité:

Transport Redundancy (Nouveau)Shadow QueuesMailbox Server resubmission

Transport Dumpster (améliorations)Basé sur la santé des bases

Transport

42

Transport Shadow Queue

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 loinLorsqu'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 dialogueNécessite une chaine de serveurs SMTP Exchange 2010 (Hub Transport, Edge Transport)

Le Submission service sur le MBX resoumets les messages si le HUB n‘a pas émis d‘avis de réception

Transport

43

Transport DumpsterAméliorations

Diminution des IOPS supplémentaire dues au DumpsterPurge 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 feedbackLes requêtes de resoumissions ne renvoient que les items plus récents que le "référentiel" (dumptser watermark)

Transport

44

Transport Points d’architecture

Les serveurs MBX 2010 ne peuvent communiquer qu’avec des HUB 2010

Communication possible entre HUB 2010 et HUB 2007Un HUB 2010 dans chaque site ou un MBX 2010 est présent

Pas besoin de RAID sur les files d’attente car le HUB grâce au Shadow Queue

Transport

45

Shadow Queue

Demo

46

HubTransport CASHUB1-

S1

HubTransport CASHUB1-

S2

Site S1 Site S2

Jean-Paul

Clint

Roberto Relai SMTP

tier

XSHADOWXDISCARD

Jean-Paul envoie un mail à RobertoJean-Paul envoie un mail à Clint

Shadow Queue

Démo PPTSuite de la

présentation

47

Tranport Shadow Demo

48

Synthèse

49

Chaque brique à sa place

Architecture totalement « stateless », on peut perdre définitivement n’importe quelle machine sans jamais perdre un message

MBX => DAG + Dumpster HUB => ShadowCAS => stateless par nature

100 users x 10 GB = 3 disques SATA à 100€/disque !

51

Pas de SAN?, pas de RAID , pas de Backup ?

SANLe SAN était obligatoire pour le SCCExchange 2010 n’a plus besoin du même niveau de performancesIl est désormais possible d’augmenter le service à l’utilisateur (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-lessRéparation de page dynamique, détection d’erreursÊtre en mesure de supporter un reseed complet dans certains cas

BackupCombien de fois effectuez-vous des restauration de boites aux lettres de plus de 30 jours?Possibilité d’avoir une base en « retard » de 14 jours

52

Q & A

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.