Exchange Server 2010 Architettura, High
Availability & Storage: le novità
Alessandro Appiani
Microsoft TechNet Speaker & Certified Trainer
email: [email protected]
Pulsar IT Founder & CEO
sip/im/email: [email protected]
L’eccellenza sulle tecnologie Microsoft
Pulsar IT è stata tra le prime società in Italia a certificarsi
sulle infrastrutture di rete Microsoft (1995) e sulle
soluzioni in area Server
Pulsar IT è specializzata sulle soluzioni per la
comunicazione, la collaborazione e la sicurezza
Le persone di Pulsar IT sono Speaker tecnici in
conferenze ed eventi Microsoft da oltre 15 anni
Pulsar IT è Microsoft Voice-Ready Partner specializzato
nell’integrazione delle tecnologie Microsoft Unified
Communications con i sistemi VoIP e legacy PBX
Agenda
Architettura di Exchange Server 2010
Ruoli e topologia
Client Access, Transport, Mailbox, ... le novità
Linee guida per il dimensionamento
Exchange Storage
Exchange 2010 Storage Design Goals
Exchange 2010 Storage Vision
Exchange DB novità architettura e prestazioni
Alta affidabilità (HA), Fault Tolerance (FT) e clustering
Scenari di HA/FT con Exchange 2003/2007/2010
Exchange 2010 Clustering: i concetti di base
Database Availability Group (DAG)
ARCHITETTURA DI EXCHANGE
SERVER 2010
Exchange 2010 Enterprise Topology
Enterprise Network
Edge Transport
Routing & AV/AS
Phone system
(PBX or VOIP)
Hub Transport
Routing & Policy
External
SMTP
servers
Mailbox
Storage of
mailbox items
Mobile
phone
Client Access
Client connectivity
Web services
Web
browser
Outlook
(remote user)
Unified Messaging
Voice mail &
voice access
Reverse Proxy
(es: Forefront
TMG/UAG)
Line of business
application
Outlook (local user)
Colocation dei ruoli e novità
L’architettura di clustering del ruolo Mailbox di Exchange
2010 non è più basata su Windows Cluster, anche se ne
richiede le tecnologie di base
può essere anche colocato con gli altri ruoli
E’ possibile implementare una soluzione in High
Availability/Fault Tolerance (“consolidata”)
soluzione in HA/FT completa con 2 soli server (oltre ad Edge)
se tutti i ruoli colocati è richiesto load balancer esterno
Unified Messaging supportato ma non consigliato
Edge è l’unico ruolo Exchange posizionato in DMZ
no colocation (come per Exchange 2007)
E’ richiesto un reverse proxy (tipicamente in DMZ) per
pubblicare su Internet il ruolo CAS
come per Exchange 2007
Forefront TMG e UAG hanno funzioni specifiche
La nuova architettura interna per
l’accesso allo store
Entourage
Exchange Components
Exchange Components
Outlook /
MAPI clients
Outlook /
MAPI clients
Exchange
Biz Logic
Entourage
Mailbox
Middle
Tier
Sync
UM
MAPI RPC
Store
Mailbox
Agents
DAV
Mailbox
OWA
Mailbox
Agents
Middle
Tier
WS
WS
Transport
Agents
OWA
Sync
MAPI,
Exchange
RFR &
Biz Logic
NSPI RPC
Exchange Core Biz Logic
MAPI RPC
Store
Transport
Agents
UM
RPC Client Access Service
Un nuovo servizio che risiede
nel ruolo CAS di Exchange
Server 2010
miglior switch in caso di mailbox
failover
architettura più pulita e minor codice
“client” nello store
Exchange Business logic uniforme tra
tutti i client
Outlook Clients
Exchange CAS Array
content/body format conversion, AD
Access (LDAP), ...
fornisce Address Book Services ai
client Outlook Anywhere gestendo
AD Query (LDAP)
supporto per un maggior numero di
connessioni per mailbox/server
MBX
GC
Client Access
Connessioni client RPC
Exchange Server 2007
Exchange Server 2010
Outlook / MAPI
clients
RpcProxy
MAPI RPC
DSProxy
NSPI
RPC Data Flow
Mailbox
AD
HTTP Data Flow
RPCProxy
NSPI,
RFR
RPC
Exchange Biz Logic
MAPI RPC
Store
Store
ESE
MAPI
RPC
ESE
Mailbox
CAS Array
CAS
Outlook / MAPI
clients
LDAP
Common Data Flow
AD
Client Access
Connessioni verso le mailbox
60K outbound
connections / CAS IP
(W2K8)
Outlook Anywhere
Clients
CAS
60K outbound
connections /
MBX server
MBX
GC
Exchange Server 2007
60K connections / MBX
server
MBX
Outlook Clients
Exchange Server 2007
Outlook Clients
# of CAS servers
x 100 connections / CAS RPCCA
service/process
MBX
Exchange CAS NLB
Exchange Server 2010
GC
LDAP
Transport Roles
Migliore affidabilità di trasporto
Shadow redundancy è una nuova caratteristica del ruolo
Transport
fornisce ridondanza dei messaggi durante le fasi di transito
rende stateless il transport
elimina l’esigenza di RAID (50% di write in meno) per mail.que
Transport Dumpster
ora sfrutta l’architettura di replica dei DB per ridurre
l’occupazione
se un messaggio è replicato in tutte le copie dei DB viene
automaticamente rimosso dal dumpster
la dimensione del dumpster è funzione della latenza di replica
dei log e della frequenza delle notifiche di replica (feedback)
Transport Roles
Come funziona Shadow redundancy
1. Hub (shadow) consegna il messaggio a
Edge1 (primary)
Verifica che Edge1 supporta Transport
redundancy tramite il verbo SMTP XSHADOW
Hub muove il messaggio nella coda shadow e
marca Edge1 come primary owner corrente
Hub
1
Edge1
Edge2
2
Foreig
n MTA
2. Edge1 (primary) riceve il messaggio
(e diventa “primary owner”)
Edge1 consegna il messaggio al next hop
Edge1 aggiorna lo stato del messaggio
evidenziando il completamento della consegna ad
un MTA esterno
Transport Roles
Come funziona Shadow redundancy
Hub
1
4
3
3. Success: Hub (shadow) interroga Edge1
(primary) per verificare lo stato di scadenza
Hub esegue il comando XQDISCARD (next SMTP
Session); Edge1 verifica lo status locale e
risponde con la lista di messaggi considerati
consegnati
 Hub cancella i messaggi dalla sua coda
shadow
Edge2 4.
Edge1
2
Foreig
n MTA
Failure: Hub (shadow) interroga Edge1
(primary) per verificare lo stato di scadenza e
reinviare
Hub apre una sessione SMTP, esegue
XQDISCARD (heartbeat) — se Hub non riesce a
contattare Edge1 e va in timeout, reinvia i
messaggi nella coda shadow — reinvia i
messaggi a Edge2 (go to #1)
Transport Roles
Shadow redundancy: altri scenari
Con sistemi che non supportano shadow redundancy,
Exchange 2010 usa un processo di acknowledgement
ritardato
SMTP submission da Exchange 2003/2007, altri Message Transfer
Agent (MTA) e Mail User Agent (MUA - UM, POP and IMAP
clients)
250 response ritardato fino a 30 secondi (default)
se il transport server fallisce prima di ack, il client reinvia
Mailbox Submission redundancy si appoggia sulla copia
dei messaggi presente nella “Sent Items” del sender
Mail Submission Service reinvia la copia quando l’hub non
conferma con acknowledge la consegna del messaggio
I messaggi di sistema (Journal Report, NDR) sono
considerati “side effects” dell’invio originale e registrati
nello status del messaggio originale
Transport Roles
Altri miglioramenti in Exchange 2010
SMTP DataBase & I/O
ESE page size 32KB
ESE database page compression
DB cache size increased to 1GB
Checkpoint depth increased to 512MB
 riduzione di circa il 50% dell’I/O
 supporto per messaggi più grossi
Edge
Migliori prestazioni per EdgeSync grazie a Deltasync Mode
Mailbox
Considerazioni architetturali
Il supporto a Large mailbox (10 GB+) abilita differenti
scenari, incluso l’utilizzo del personal archive
usare Office/Outlook 2007 Service Pack 2 (SP2) o successivi
implementare le funzionalità di record management
Utilizzare soluzioni direct-attached storage (DAS) per
ridurre i costi in caso di large mailbox e continuous
replication
Exchange 2010 Mailbox Server Role Requirements Calculator
Alta affidabilità basata su Database Availability Group
(DAG) e replica
con 3 o più copie si possono considerare soluzioni RAID-less
con log e database sullo stesso volume
Streaming backup non è più supportato
{
}
EXCHANGE STORAGE
E-mail storage & design goals
Molte e-mail
circa 200 al gg
in/out
Large mailbox
(1-10GB+) è ormai
un’esigenza
300
Messages Sent/Received Per User/Day
(Radicati group 2008)
200
100
0
2008
2010
2012
produttività, search, storia pluriennale, ...
Disk storage trends
la capacità degli HD cresce costantemente (soprattutto SATA)
il costo per GB decresce continuamente (soprattutto SATA)
la massima velocità si ottiene in caso di Sequential I/O
Storage consolidation
eliminare/ridurre PST
eliminare/ridurre l’esigenza di soluzioni di archiving terze
Exchange 2010 Storage Vision
SATA/Tier 2
Disk
Optimization
IO Reduction
Sequential IO
Large, Fast, Lowcost Mailboxes
Storage Design
Flexibility
RAID’less
Storage (JBOD)
Riduzione dell’IOPS
Store Table Architecture
Per Database
E2007
Per Folder
Mailbox Table
Folders Table
Message Table
(Msg)
Attachments
Table
Message/Folder
Table (MFT)
Jeff’s Mbx
Jeff:Inbox
Joe:Msg10
Jeff:Excel.xls
Joe:Inbox:H3
Ann’s Mbx
Ann:Drafts
Jeff:Msg32
Ann:Pic.bmp
Joe:Inbox:H2
Joe’s Mbx
Joe:Unread
Ann:Msg180
Joe:Help.doc
Joe:Inbox:H1
Secondary Indexes used for Views
Per Mailbox
Per Database
E2010
Per View
Mailbox Table
Folders Table
Message
Header Table
Body
View Tables (e.g.
From)
Jeff’s Mbx
Joe:Inbox
Joe:H10
Joe:Msg10
Joe:H920
Ann’s Mbx
Joe:Drafts
Joe:H302
Joe:Help.doc
Joe:H302
Joe’s Mbx
Joe:Unread
Joe:H920
Joe:Msg302
Joe:H10
 non c’è più single instance storage 
Store Schema Changes
Lazy View Updates
All Unread or Flagged items (view)
E2007
M1
M2
M1
M3
M2
Nickel &
Dime
Approach
DB I/O
Many, random, IOs (1 per update)
M1 arrives
M2 arrives
M1 flagged
M3 arrives
M2 deleted
Time
User uses OWA/Outlook Online
and
switches to this view
E2010
Pay to Play
Approach
All Unread or Flagged items (view)
M1
M2
M1
M3
M2
Fewer, sequential, IOs (1 per view)
Riduzione dell’I/O ottenuta ritardando
l’aggiornamento delle viste e favorendo le scritture sequenziali
DB Page Size elevato a 32KB*
E2007 DB Read
20KB Message
DB
Cache
Page 1
Page 3
Page 5
Msg
Header
Msg
Body
Msg
Body
Disk
3 Read IO’s
8 KB
Pages
E2010 DB Read
20KB Message
* 8k in E2007
4k in E2003
DB
Cache
Page 1
Page 2
Page 3
Page 4
Page 5
Msg
Header
X
Msg
Body
X
Msg
Body
Page 1 (32KB)
Msg Header, Msg Body
1 Read IO
Disk
32 KB
Pages
Page 1 (32KB)
Page 2 (32KB)
Msg Header, Msg Body
X
~20KB Message
Exchange 2010 Storage
Mailbox I/O
Mailbox IO Characteristics: E2007 vs... E2010
DB IO
E2007
E2010
Log IO
E2007
E2010
IO Type
Random
“Sequentialish”
IO Type
Sequential
Sequential
Read:Write
1:1
3:2
Read:Write
0:1
0:1
Avg Read IO
Size (KB)
12
52
n/a
n/a
Avg Write IO
Size (KB)
8
Avg Read IO
Size (KB)
Avg Write IO
Size (KB)
10
10
60
consolidamento delle
scritture su DB: IO size
circa 5x rispetto a E007
Write size dei log
sostanzialmente inalterato...
3000 Mailboxes, 12 DB’s 4MB DBCache/Mailbox, Loagen Outlook 2007 Online Very Heavy Profile, 250MB Mailbox Size
E2010 rispetto a E2007
riduzione complessiva IOPS
500
oltre il 70% di
IO in meno
450
400
350
DB Read IO/Sec
DB Write IO/Sec
DB IO/Sec
300
250
200
150
100
50
0
E2007
E2010
3000 Mailboxes, 3MB DB Cache/user, Loadgen Outlook 2007 Online Very Heavy Profile, 250MB Mailbox Size, E2010 Beta
E2010 rispetto a E2003
riduzione complessiva IOPS
DB IOPS/Mailbox
90% !
1
0.8
Exchange 2003
Exchange 2007
Exchange 2010
0.6
0.4
0.2
0
Exchange
2003
Exchange
2007
Exchange
2010
Exhange 2010 HA Storage Design
SAN
• HA = Shared Storage
Clustering
• +1.0 IOPS/Mailbox
• 3.5” 15K 146GB FC Disks
• RAID10 for DB & Logs
• Dedicated Spindles
• Multi-path (HBA’s, FC
Switches, SAN array
controllers)
• Backup = Streaming off
active
• Fast Recovery = Hardware
VSS (Snapshots/Clones)
•
•
•
•
•
•
•
•
DAS (SAS)
DAS (SATA/Tier2)
HA = CCR
.33 IOPS/Mailbox
2.5” 146GB 10K SAS Disks
RAID5 for DB
RAID10 for Logs
SAS Array Controller (/w BBU)
Backup = VSS Snapshot
Fast Recovery = CCR
• HA = DAG (2+ DB copies)
• .11 IOPS/Mailbox
• 3.5” 1TB 7.2K SATA/Tier2
Disks
• RAID10 for DB & Logs
• SAS Array Controller (/w
BBU)
• Backup = VSS
Snapshot/Optional
• Fast Recovery = Database
Failover
più flessibilità per ridurre i costi
JBOD (SATA/Tier2)
• HA = DAG (3+ DB copies)
• .11 IOPS/Mailbox
• 3.5” 1TB 7.2K SATA/Tier2
Disks
• 1 DB = 1 Disk
• SAS Array Controller (/w
BBU)
• Backup = VSS
Snapshot/Optional
• Fast Recovery = Database
Failover
E2010 Storage Requirements
Storage Guidance
Stand Alone
E2010 HA(2 copies)
E2010 HA(3+ copies)
Storage Type
DAS, SAN (Fibre Channel, iSCSI)
Disk Type
SAS, Fibre Channel, SATA/Tier2 , SSD
RAID
RAID recommended
RAID optional
RAID Type
RAID-1/0, RAID-5, RAID-6
JBOD
DB/Log Isolation
Best Practice
Windows Disk Type
Basic (recommended), Dynamic (supported)
Partition Type
GPT (recommended), MBR (supported)
Partition Alignment
Windows 2008/R2 Default (1MB)
File System
NTFS
NTFS Allocation Unit Size
64KB for both database and log volumes
Encryption Support
Outlook Protection Rules, Bitlocker
Not required
{
}
ALTA AFFIDABILITÀ (HA), FAULT
TOLERANCE (FT) E CLUSTERING
Exchange Server 2003
Outlook
OWA, ActiveSync, or
Outlook Anywhere
San Jose
Front End
Server
NodeA
(active)
Complex site
resilience and
recovery
Clustered Mailbox
Server had to be
created manually
NodeB
(passive)
DB1
DB4
DB2
DB5
DB3
DB6
Failover at
Mailbox server
level
Dallas
DB1
DB2
Standby
Cluster
DB3
Third-party data
replication
needed for site
resilience
Clustering
knowledge
required
Exchange Server 2007
Outlook
OWA, ActiveSync, or
Outlook Anywhere
Client Access
Server
DB2
Standby
Cluster
DB3
No GUI to
manage
SCR
NodeB
(passive)
CCR
DB1
SCR
Clustered Mailbox
Server can’t coexist with other
roles
San Jose
NodeA
(active)
Dallas
Complex activation
for remote server /
datacenter
DB1
DB4
DB1
DB4
DB2
DB5
DB2
DB5
DB3
DB6
DB3
DB6
Clustering
knowledge
required
Failover at
Mailbox server
level
Exchange Server 2010
Dallas
All clients connect
via CAS servers
DB1
DB3
Mailbox
Server 6
San Jose
DB5
Easy to
extend across
sites
Client Access
Server
Failover managed
by/with Exchange
Mailbox
Server 1
Mailbox
Server 2
Mailbox
Server 3
Mailbox
Server 4
Mailbox
Server 5
DB1
DB4
DB2
DB5
DB3
DB2
DB5
DB3
DB1
DB4
DB3
DB1
DB4
DB2
DB5
Database
level
failover
Exchange 2010 High Availability
Concetti di base
E’ ottenuta attraverso il concetto di Mailbox Resiliency
che uniforma l’approccio al fault tolerance per dati e
servizi sia a livello locale che a livello geografico (site)
E’ granulare a livello di mailbox database, non più a
livello di server o Storage Group
In ogni istante possono esistere N copie di un Database
una sola delle quali è attiva
La copia attiva può essere cambiata sia manualmente
(switchover) che automaticamente in caso di failure
(failover)*
* il processo di cambiamento di Active mailbox database copy si abbrevia generalmente
*over così da comprendere le due modalità (switch/fail)
Exchange 2010 High Availability
Cosa cambia e cosa no
Non più basata su un Windows Cluster
usa comunque le tecnologie clustering di Windows Server
2008/2008 R2 Enterprise
nativa in Exchange (DAG), anche per setup e management
nessun limite geografico o di network
rimane il concetto di quorum, witness, heartbeat/monitoring
Storage Group: non ci sono più
fino a 100 Mailbox DB per ogni server
Il modello SCC non è più consentito
basata su replica, DB Seed, log shipping & reply
fino a 16 copie di ogni DB (erano 2 in E2007)
Deployment incrementale
dopo il setup, in ogni momento
Exchange 2010 HA
Schema logico dei componenti
Database Availability Group
Server
Database
Database Copy
Active Manager
RPC Client Access
DAG
Database Availability Group (DAG)
E’ un raggruppamento di server (fino a 16) in
grado di ospitare repliche di DB
Componente alla base dell’alta affidabilità sia
locale che geografica (site)
Racchiude di fatto un Windows Failover Cluster
gestisce il gruppo: DAG member = cluster node
rileva heartbeat dei server membri
Active Manager stores data in cluster database
La replica e l’HA può avvenire solo all’interno di
un DAG
Active Manager
E’ un processo in esecuzione su ogni server di un DAG
che ha il compito principale di determinare la copia
attiva di un DB nel DAG
Gestisce i dati e le informazioni proprie del DAG
Comunica e fornisce informazioni agli altri componenti
di Exchange (RPC Client Access, Hub Transport, ...)
Due differenti ruoli
Primary Active Manager (PAM)
è quello in esecuzione sul nodo attivo (owner) del cluster group
seleziona la copia di riferimento di un DB in caso di *over
Standby Active Manager (SAM)
è quello in esecuzione sugli altri nodi del cluster group
Esempio di Database Failover
Database failure
Failure viene segnalato
Active Manager riseleziona active database
Viene ripristinata una Database copy
Il processo è sostanzialmente uguale anche in caso di failure su nodi
remoti/tra datacenter
DAG
Mailbox
Server 1
Mailbox
Server 2
Mailbox
Server 3
Mailbox
Server 4
Mailbox
Server 5
DB1
DB4
DB2
DB5
DB3
DB2
DB5
DB3
DB1
DB4
DB3
DB1
DB4
DB2
DB5
Esempio di Server Failover
Database failure
Failure viene segnalato (cluster node down)
Active Manager riseleziona gli active database
Viene ripristinato il server
Segnalazione di cluster node up
Le copie dei database vengono risincronizzate con quelle attive
Il processo è lo stesso anche tra datacenter
DAG
Mailbox
Server 1
Mailbox
Server 2
Mailbox
Server 3
Mailbox
Server 4
Mailbox
Server 5
DB1
DB4
DB2
DB5
DB3
DB2
DB5
DB3
DB1
DB4
DB3
DB1
DB4
DB2
DB5
Un modello diverso di affidabilità
Con 3 o più copie dei database e l’applicazione delle nuove funzionalità è
possibile utilizzare la replica come alternativa ai backup tradizionali
Site/Server/Disk failure
Archiving/Compliance
Recover deleted items
Exchange 2010 HA
E-mail Archive
Hold Policy
Database Availability Group
Mailbox
Server 1
Mailbox
Server 2
Mailbox
Server 3
DB1
DB1
DB1
DB2
DB2
DB2
DB3
DB3
DB3
X
JBOD/RAID'less Storage
Single Page Restore (Active)
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.
5.
Active receives good
page, writes page to DB.
Page is restored.
Subsequent page repair
from additional copies
ignored
Database Availability Group (DAG)
Mailbox
Server Node 1
DB1-Active
Mailbox
Server Node 2
Mailbox
Server Node 3
DB1-CopyA
DB1-CopyB
Log
Log
Log
Page1
Page1
Page1
Page2
Page2
Page2
Page3
Page3
Page3
Database
Database
Database
{
}
IN SINTESI
Riepilogo
Exchange 2010: una versione importante
Architettura
Client connections tutte sul Client Access Server role
(attenzione al sizing)
Shadow redundancy irrobustisce il trasporto
Ottimizzato per large mailboxes (+10GB)
Storage
Riduzione dell’I/O del 70% rispetto a Exchange 2007 (del 90%
rispetto a Exchange 2003)
Consente l’uso di dischi SATA/Tier2 (large/slow/low-cost)
Favorisce retention e archiving
High Availability
nuovo modello nativo in architettura Exchange (DAG)
uniforma Data, Service, Site, Disaster Recovery
consente soluzioni JBOD/Raidless
Risorse (1)
Exchange 2010 Mailbox Server Role Requirements Calculator
http://msexchangeteam.com/archive/2009/11/09/453117.aspx
Mailbox Server Storage Design
http://technet.microsoft.com/en-us/library/dd346703.aspx
Understanding Storage Configuration
http://technet.microsoft.com/en-us/library/ee832792.aspx
Mailbox Server Processor Capacity Planning
http://technet.microsoft.com/en-us/library/ee712771.aspx
Planning for High Availability and Site Resilience
http://technet.microsoft.com/en-us/library/dd638104.aspx
Understanding Exchange Performance
http://technet.microsoft.com/en-us/library/dd351192.aspx
Capacity Planning Tools
Profiling (Exchange Profile Analyzer, Performance Monitor)
Sizing (Exchange 2010 Mailbox Server Role Requirements Calculator)
Validation (Jetstress 2010, Exchange Load Generator)
Risorse (2)
Microsoft Exchange Server TechCenter
http://technet.microsoft.com/en-us/exchange
Microsoft Exchange Team Blog
http://msexchangeteam.com
Microsoft Unified Communications Group Team Blog
http://blogs.technet.com/uc
Microsoft Unified Communications | TechNet Edge
http://edge.technet.com/unifiedcommunications
Microsoft Exchange Server Home
http://www.microsoft.com/exchange
Microsoft Unified Communications (UC) Home
http://www.microsoft.com/uc
Microsoft Exchange Server Italy Home
http://www.microsoft.com/italy/server/exchange
© 2009 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only.
MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.