1
Guillaume BordierPhilippe MaurentMicrosoft Services Francehttp://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 ?
3
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
20
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
27
28DAG
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
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
D
B
1
D
B
1
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
D
B
1
D
B
1
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/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
45
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
47
48
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
52
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.