Transcript Exchange Server 2010 - BangaloreITPro User Group

Kaliyan Selvaraj
Technical Consultant
Dell India Pvt. Ltd.,
Review of Exchange Server 2007 Availability Solutions
Overview of Exchange 2010 High Availability
Exchange 2010 High Availability Fundamentals
Exchange 2010 Incremental Deployment
DAG Demo (Creation, Adding Database Copy, *Over)
Exchange 2010 High Availability Design Examples
Exchange Server 2007
Availability Solutions
Single Copy Cluster (SCC) out-of-box provides little high
availability value
On Store failure, SCC restarts store on the same machine;
no clustered mailbox server (CMS) failover
SCC does not automatically recover from storage failures
SCC does not protect your data, your most valuable asset
SCC does not protect against site failures
SCC redundant network is not leveraged by CMS
Conclusion
SCC only provides protection from server hardware failures
and bluescreens, the relatively easy components to recover
Supports rolling upgrades without losing redundancy
2. Inspect logs
Database
Log
Log
E00.log
E0000000012.log
E0000000011.log
1. Copy logs
Local
Cluster
Database
3. Replay logs
Standby
File
Share
Log shipping to a local
disk
Log shipping within a cluster
Log shipping to a standby
server or cluster
Outlook (MAPI)
client
OWA, ActiveSync, or
Outlook Anywhere
AD site: San Jose
Client Access
Server
CCR #1
Node A
CCR #1
Node B
Windows cluster
Manual
“activation” of
remote mailbox
server
AD site: Dallas
Client Access
Server
DB4
DB5
Standby
Server
Mailbox server
can’t co-exist
with other roles
CCR #2
Node A
DB6
SCR
CCR #2
Node B
Windows cluster
DB1
DB1
DB4
DB4
DB2
DB2
DB5
DB5
DB3
DB3
DB6
DB6
SCR managed
separately; no
GUI
Clustering
knowledge
required
Database failure
requires server
failover
Windows Failover Cluster
Default Cluster
Group
Cluster IP Address
Cluster Name
Cluster Quorum
Cluster
Database
Clustered Mailbox
Server (CMS)
CMS IP Address
CMS Name
CMS resources
(exres.dll)
CMS disk resources
Cluster
Networks
Database Availability Group
Active Manager
DAG Networks
PAM
SAM
Windows Failover Cluster
Default Cluster Group
Cluster IP Address
Cluster Name
Cluster Quorum
Cluster
Database
Database Availability Group
Mailbox Server
Mailbox Server
Mailbox Server
GetMailboxDatabaseCopyStatus
GetMailboxDatabaseCopyStatus
GetMailboxDatabaseCopyStatus
MoveActiveMailboxDatabase
MoveActiveMailboxDatabase
MoveActiveMailboxDatabase
Primary Active Manager
Standby Active Manager
Standby Active Manager
Storage
Storage
Storage
Overview of Exchange 2010 High
Availability
Reduce complexity
Reduce cost
Native solution - no single point of failure
Improve recovery times
Support larger mailboxes
Support large scale deployments
Make High Availability Exchange
deployments mainstream!
Improved mailbox uptime
• Improved failover granularity
• Simplified administration
• Incremental deployment
• Unification of CCR + SCR
• Easy stretching across sites
• Up to 16 replicated copies
More storage flexibility
•
•
Key Benefits
 Easier and cheaper to deploy
 Easier and cheaper to manage
 Better Service Level
Agreements (SLAs)
 Reduced storage costs
 Larger mailboxes
Further Input/Output (I/O)
reductions
RAID*-less/JBOD** support
Better end-to-end availability
• Online mailbox moves
• Improved transport resiliency
*Redundant Array of Independent Disks (RAID)
 Easier and cheaper to manage
 Better SLAs
**Just a Bunch of Disks (JBOD)
AD site: Dallas
Client
All clients connect
via CAS servers
Client Access
Server
DB3
Mailbox
Server 6
AD site: San Jose
DB1
DB5
Easy to
stretch across
sites
Client Access
Server (CAS)
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
Failover
managed within
Exchange
Database
(DB) centric
failover
Exchange 2010
High Availability Fundamentals
Database Availability
Group
Server
Database
Database Copy
Active Manager (AM)
Remote Procedure Call
(RPC) Client Access
service
DAG
A group of up to 16 servers hosting a set of replicated
databases
Wraps a Windows Failover Cluster
Manages servers’ membership in the group
Heartbeats servers, quorum, cluster database
Defines the boundary of database replication
Defines the boundary of failover/switchover (*over)
Defines boundary for DAG’s Active Manager
Mailbox
Server 1
Mailbox
Server 2
Mailbox
Server 3
Mailbox
Server 4
Mailbox
Server 16
Unit of membership for a DAG
Hosts the active and passive copies of multiple mailbox databases
Executes Information Store, CI, Assistants, etc., services on active
mailbox database copies
Executes replication services on passive mailbox database copies
Mailbox
Server 1
Mailbox
Server 2
Mailbox
Server 3
DB1
DB4
DB3
DB2
DB1
DB4
DB3
DB2
Unit of *over
A database has 1 active copy – active copy can be
mounted or dismounted
Maximum # of passive copies == # servers in DAG – 1
Mailbox
Server 1
Mailbox
Server 2
Mailbox
Server 3
DB1
DB4
DB3
DB2
DB1
DB4
DB3
DB2
DB1
Scope of replication
A copy is either source or target of replication at any given time
A copy is either active or passive at any given time
Only 1 copy of each database in a DAG is active at a time
A server may not host >1 copy of a any database
Mailbox
Server 1
DB1
Mailbox
Server 2
X
DB1
DB2
DB2
DB1
DB3
DB3
Primary Active Manager (PAM)
Runs on the node that owns the default cluster group
(quorum resource)
Gets topology change notifications
Reacts to server failures
Selects the best database copy on *overs
Standby Active Manager (SAM)
Runs on every other node in the DAG
Responds to queries from other Exchange components for
which server hosts the active copy of the mailbox database
Continuous replication has the following basic steps:
Database copy seeding of target
Log copying from source to target
Log inspection at target
Log replay into database copy
There are three ways to seed the target instance:
Automatic Seeding
Requires 1st log file containing CreateDB record
Update-MailboxDatabaseCopy cmdlet
Can be performed from active or passive copies
Manually copy the database
Log shipping in Exchange 2010 leverages Transmission
Control Protocol (TCP) sockets
Supports encryption and compression
Administrator can set TCP port to be used
Replication service on target notifies the active instance
the next log file it expects
Based on last log file which it inspected
Replication service on source responds by sending the
required log file(s)
Copied log files are placed in the target’s Inspector
directory
Active Manager selects the “best” copy to become
active when existing active fails
10
8
6
9
5
7
Catalog
Copy status
Crawling
Healthy
Healthy, DisconnectedAndHealthy,
DisconnectedAndResynchronizing,
or
SeedingSource
CopyQueueLength
ReplayQueueLength< 10 < 50
ReplayQueueLength
< 50
Streaming backup APIs for public use have been cut, must use Volume
Shadow Copy Service (VSS) for backups
Backup from any copy of the database/logs
Always choose Passive (or Active) copy
Backup an entire server
Designate a dedicated backup server for a given database
Restore from any of these backups scenarios
Database Availability Group
Mailbox
Server 1
Mailbox
Server 2
Mailbox
Server 3
DB1
DB1
DB1
DB2
DB2
DB2
DB3
DB3
DB3
VSS requestor
Exchange 2010 HA
E-mail archive
Extended/protected dumpster
retention
Site/server/disk failure
Archiving/compliance
Recover deleted items
Database Availability Group
Mailbox
Server 1
Mailbox
Server 2
Mailbox
Server 3
7-14 day lag copy
DB1
DB1
DB1
DB2
DB2
DB2
DB3
DB3
DB3
X
Legacy Deployment Steps (CCR/SCC)
Exchange 2010 Incremental Deployment
1. Prepare hardware, install proper OS,
and update
Extra for SCC: configure storage
2. Build Windows Failover Cluster
Extra for SCC: configure storage
3. Configure cluster quorum, file share
witness, and public and private
networks
4. Run Setup in Custom mode and install
clustered mailbox server
5. Configure clustered mailbox server
Extra for SCC: configure disk
resource dependencies
6. Test *overs
1. Prepare hardware, install proper OS,
and update
2. Run Setup and install Mailbox role
3. Create a DAG and replicate databases
4. Test *overs
Easy to add high availability to existing deployment
High availability configuration is post-setup
HA Mailbox servers can host other Server Roles
Reduces cost and complexity of HA deployments
Datacenter 1
Datacenter 2
Database Availability Group
Mailbox
Server 1
Mailbox
Server 2
Mailbox
Server 3
Exchange Management Console
Exchange Management Console
Exchange Management Console
Exchange Management Shell
Create a DAG
New-DatabaseAvailabilityGroup -Name DAG1 -FileShareWitnessShare
\\CTD-CH02\DAGWitness -FileShareWitnessDirectory C:\DAGWitness
Add first Mailbox Server to DAG
Add-DatabaseAvailbilityGroupServer -Identity DAG1 -MailboxServer CTDMBX1 -DatabaseAvailablityGroupIpAddresses 192.168.1.100
Add second and subsequent Mailbox Server
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer CTDMBX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer
EXMBX3 -DatabaseAvailablityGroupIpAddresses 192.168.1.100,
192.168.2.10
Add Mailbox Database Copy
Add-MailboxDatabaseCopy -Identity MBXDB1 -MailboxServer CTD-MBX2
Extend as needed
HA Administration within Exchange
Recovery uses the same simple
operation for a wide range of failures
Simplified activation of Exchange
services in a standby datacenter
Reduces cost and
complexity of management
Managing Availability in the Exchange Management Console
1
Select a database
2
View locations and status of
replicated copies
3
Take action (add copies,
change master, etc.)
DAG Demo LAB Setup Diagram
Exchange 2010
High Availability Design Examples
File
Share
File
Share
File
Share
File
Share
File
Share
2 servers out -> manual
Single
Site 3
activation
of server
3
Nodes
In 3 server DAG, quorum is lost
3 HA Copies
DAGs with more servers sustain
JBOD
-> 3–physical
Copies
more
failures
greater resiliency
Mailbox
Server 1
Mailbox
Server 2
Mailbox
Server 3
X
Database Availability Group (DAG)
CAS/HUB/
MAILBOX 1
CAS/HUB/
MAILBOX 2
DB2
Member servers of DAG
can host other server roles
2 server DAGs, with server
roles combined or not, should
use RAID
With each release, our goals are to make Exchange
high availability:
Easier and cheaper to deploy
Easier and cheaper to manage
Support better SLAs with faster and more granular
recoveries
Improve site resiliency support
Our other goal is for highly available deployments to be
mainstream!
© 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.