guillaume bordier philippe maurentdownload.microsoft.com/documents/france/technet/2009/...4 premier...

1

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

http://blogs.technet.com/frmcsuc

2

Nouvelle approche du stockage

Une toute nouvelle approche de la haute disponibilité : plus de SPOF

ni SAN, ni RAID, ni Backup ?

4

Premier facteur de coût de l‟infrastructure

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 d‟archivage sont souvent vues comme le moyen de limiter la taille de la boîte.

5

S‟adapte aux configurations jusqu‟à plusieurs millions de boites.

Une boite de 10 GB avec Exchange 2010 consomme autant qu‟une boite de 200MB

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

..

7

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

88

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

Secondary Indexes used for Views

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

Adaptation au nouveau schéma

Compression de page

Défragmentation permanente

Alloue l‟espace 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

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

CompactnessPage 4

Msg

Header

Page 5

Msg

Header

Page 2

Event

History

Sequential/BloatRandom/Compact

ESE

11

New 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 IO

2. Run DB Checksum during OLM window.

Sequential IO

ESE

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)

1,00

1,20

1,000,88

0,00

0,20

0,40

0,60

0,80

1,00

1,20

1,40

E2K7/RTF E14/RTF E14/Mix E14/HTML

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

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

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

Cache13

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

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

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

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

18 20

31 3540 42

6369

8085

91

114

0

20

40

60

80

100

120

2 4 8 16 32 64

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

Maximum DB Write IO's Issued

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

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

0

5

10

15

20

25

30

35

40

26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

Max Outstanding DB Writes vs. Checkpoint Depth

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

Max O

uts

tan

din

g D

B W

rite

s

ESE

19

Boite d‟archive “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 d‟utiliser 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) : 100.000

*3 copy High Availability only

SCC LCR

CCR

FileShare

SCRSite 1 Site 2

DAGDatabase Availability Group

23

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 RedundancyShadow 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 DAG

Active Manager : Bascule automatique d‟une copie vers l‟autre

24

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

Technologies xCR remplacée par le DAGFiabilisation

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

Ajouter un nœud dans un DAG

DAG

26

Ajouter un membre dans le DAG est facile, ne nécessite pas de réinstallation, tout est automatique

Passage d‟un modèle de Quorum à un autre

DAG

29

Autres avantagesPasser d‟un MBX “normal” à un membre de DAG sans réinstallation

Configuration de réplication base par base à la demande

Pas 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

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

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

DAG

Defines properties applicable to an individual database copy

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

CopyQueueLength

ReplayQueueLength

ActiveCopy

ActivationSuspended

33DAG

34

Primary Active Manager (PAM)

S‟exé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)

S‟exé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 l‟activation des bases

DAG

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 l‟organisation (obligatoire)

Combiner base et logs sur les même disques n‟est plus un problème

A partir de 3 copies de baseLe RAID devient optionnel

On 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‟archive

Office 2007 Service Pack 2 (SP2) minimum (Taille .OST !)

DAG

36

D

B

1

D

B

1

DB1 DB2 DB3 DB4 DB5 DB6





Legend

Active copy Passive copy Spare Disk

D

B

1

D

B

1






D

B

1

D

B

1






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/nodeDatabase Availability Group (DAG)

Mbx Server 2 Mbx Server 3

DAG

37

« Une vraie architecture multi-tiers »

CAS

38

Mid

dle

Tier

XSO

MAPI.Net

Mai

lbo

x MAPI RPC

Store

Exchange Components

OWA

SyncUM

Transport Agents

Mailbox Agents

WS

Entourage

Outlook / MAPI clients

DAV

Mid

dle

Tier

MAPI RPC

MAPI.Net

Core Objects

XSO

Mai

lbo

x

MAPI RPC

Store

Exchange Components

OWA

SyncUM

Transport Agents

Mailbox Agents

WS

Outlook / MAPI clients

Entourage

DSP

RO

XY

NSP

I

CAS

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+MBXCar NLB n‟est pas compatible avec WFC

HLB 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

« Garantir la livraison du message »

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

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 n„a pas émis d„avis de réception

Transport

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 LastLogInspectedpour 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

Les serveurs MBX 2010 ne peuvent communiquer qu‟avec 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 d‟attente car le HUB grâce au Shadow Queue

Transport

46

Hub

Transport

CASHUB1-

S1

Hub

Transport

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

49

Architecture totalement « stateless », on peut perdre définitivement n‟importe 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 !

51

SANLe SAN était obligatoire pour le SCC

Exchange 2010 n‟a plus besoin du même niveau de performances

Il 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

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.

guillaume bordier philippe maurentdownload.microsoft.com/documents/france/technet/2009/...4 premier...

Documents