Post on 16-Apr-2017
Exchange 2010 High Availability
Kaliyan SelvarajTechnical ConsultantDell India Pvt. Ltd.,
AgendaReview of Exchange Server 2007 Availability SolutionsOverview of Exchange 2010 High AvailabilityExchange 2010 High Availability FundamentalsExchange 2010 Incremental DeploymentDAG Demo (Creation, Adding Database Copy, *Over)Exchange 2010 High Availability Design Examples
Exchange Server 2007 Availability Solutions
Exchange Server 2007Single Copy Clusters
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) failoverSCC does not automatically recover from storage failuresSCC does not protect your data, your most valuable assetSCC does not protect against site failuresSCC redundant network is not leveraged by CMS
ConclusionSCC only provides protection from server hardware failures and bluescreens, the relatively easy components to recoverSupports rolling upgrades without losing redundancy
1. Copy logs
E00.logE0000000012.logE0000000011.log
2. Inspect logs
3. Replay logs
Log Log
Log shipping to a local disk
LocalFileShare
Log shipping within a cluster
Cluster
Log shipping to a standby server or
cluster
Standby
Database Database
Exchange Server 2007Continuous Replication
DB1
Client Access Server
CCR #1
Node A
CCR #1
Node B
CCR #2 Node B
CCR #2
Node A
SCR
Outlook (MAPI) client
Windows cluster Windows cluster
OWA, ActiveSync, or
Outlook AnywhereAD site: San Jose
AD site: Dallas Client Access Server
Standby Server
SCR managed
separately; no GUI
Manual “activation” of
remote mailbox server
Clustering knowledge required
DB2DB3
DB1DB2DB3
DB4DB5DB6
DB4DB5DB6
Database failure requires server failover
DB4DB5DB6Mailbox server
can’t co-exist with other
roles
Exchange Server 2007 CCR + SCR
Core Architectural ShiftWindows 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
Core Architectural Shift
Windows Failover Cluster
Default Cluster Group
Cluster IP Address Cluster Name
Cluster Quorum
Cluster Database
Active Manager
PAMSAM
DAG Networks
Database Availability Group
Core Architectural Shift
Mailbox Server
Get-MailboxDatabaseCopyStatus
Primary Active Manager
Move-ActiveMailboxDatabase
Storage
Mailbox Server
Get-MailboxDatabaseCopyStatus
Standby Active Manager
Move-ActiveMailboxDatabase
Storage
Mailbox Server
Get-MailboxDatabaseCopyStatus
Standby Active Manager
Move-ActiveMailboxDatabase
Storage
Overview of Exchange 2010 High Availability
Exchange 2010 High Availability Goals
Reduce complexity Reduce cost Native solution - no single point of failureImprove recovery timesSupport larger mailboxesSupport large scale deployments
Make High Availability Exchange deployments mainstream!
•Improved failover granularity•Simplified administration•Incremental deployment•Unification of CCR + SCR•Easy stretching across sites•Up to 16 replicated copies
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
Exchange Server Improvements Key Benefits
• Online mailbox moves• Improved transport resiliency
Easier and cheaper to manage
Better SLAs
Improved mailbox uptime
More storage flexibility
Better end-to-end availability
*Redundant Array of Independent Disks (RAID) **Just a Bunch of Disks (JBOD)
Client
DB2DB3
DB2DB3DB4
DB4DB5
Client Access Server (CAS)
Mailbox
Server 1
Mailbox
Server 2
Mailbox
Server 3
Mailbox Server 6
Mailbox
Server 4
AD site: Dallas
AD site: San Jose
Mailbox
Server 5
DB5
DB2
DB3DB4DB5DB1
DB1DB1 DB1
Exchange 2010 High Availability Architecture
Failover managed
within Exchange
Database (DB)
centric failover
Easy to stretch
across sites
Client Access Server
All clients connect via CAS
servers DB3DB5
DB1
Exchange 2010High Availability Fundamentals
Exchange 2010 High Availability Fundamentals
Database Availability Group ServerDatabaseDatabase CopyActive Manager (AM)Remote Procedure Call (RPC) Client Access service
DAG
copy
copy
AMSVR
copy
copy
AM
SVR
DB DB
RPC CAS
RPC CAS
Exchange 2010 High Availability FundamentalsDatabase Availability Group
A group of up to 16 servers hosting a set of replicated databasesWraps a Windows Failover Cluster
Manages servers’ membership in the groupHeartbeats servers, quorum, cluster database
Defines the boundary of database replicationDefines 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
Exchange 2010 High Availability FundamentalsServer
Unit of membership for a DAGHosts the active and passive copies of multiple mailbox databasesExecutes Information Store, CI, Assistants, etc., services on active mailbox database copiesExecutes replication services on passive mailbox database copies
DB2DB3
DB4
Mailbox Server
1
Mailbox Server
2
Mailbox Server
3
DB1DB1 DB3
DB4DB2
Exchange 2010 High Availability FundamentalsMailbox Database
Unit of *overA database has 1 active copy – active copy can be mounted or dismountedMaximum # of passive copies == # servers in DAG – 1
DB2DB3
DB4
Mailbox Server
1
Mailbox Server
2
Mailbox Server
3
DB1DB1 DB3
DB4DB2 DB1
Exchange 2010 High Availability FundamentalsMailbox Database Copy
Scope of replicationA copy is either source or target of replication at any given timeA copy is either active or passive at any given timeOnly 1 copy of each database in a DAG is active at a timeA server may not host >1 copy of a any database
Mailbox Server 1
Mailbox Server 2
DB1
DB3DB2
DB1
DB3
XDB2DB1
Active ManagerPrimary Active Manager (PAM)
Runs on the node that owns the default cluster group (quorum resource)Gets topology change notificationsReacts to server failuresSelects the best database copy on *overs
Standby Active Manager (SAM)Runs on every other node in the DAGResponds to queries from other Exchange components for which server hosts the active copy of the mailbox database
Exchange 2010 High Availability FundamentalsContinuous Replication
Continuous replication has the following basic steps:
Database copy seeding of targetLog copying from source to targetLog inspection at targetLog replay into database copy
Exchange 2010 High Availability FundamentalsDatabase Seeding
There are three ways to seed the target instance:Automatic Seeding
Requires 1st log file containing CreateDB recordUpdate-MailboxDatabaseCopy cmdlet
Can be performed from active or passive copiesManually copy the database
Exchange 2010 High Availability FundamentalsLog Shipping
Log shipping in Exchange 2010 leverages Transmission Control Protocol (TCP) sockets
Supports encryption and compressionAdministrator 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 inspectedReplication service on source responds by sending the required log file(s) Copied log files are placed in the target’s Inspector directory
Exchange 2010 High Availability FundamentalsActive Manager Selection of Active Database CopyActive Manager selects the “best” copy to
become active when existing active fails
Catalog HealthyCopy status Healthy, DisconnectedAndHealthy,
DisconnectedAndResynchronizing, orSeedingSource
CopyQueueLength < 10ReplayQueueLength < 50
Catalog CrawlingCopy status Healthy, DisconnectedAndHealthy,
DisconnectedAndResynchronizing, orSeedingSource
CopyQueueLength < 10ReplayQueueLength < 50
Catalog HealthyCopy status Healthy, DisconnectedAndHealthy,
DisconnectedAndResynchronizing, orSeedingSource
ReplayQueueLength < 50
Catalog CrawlingCopy status Healthy, DisconnectedAndHealthy,
DisconnectedAndResynchronizing, orSeedingSource
ReplayQueueLength < 50
5Copy status Healthy, DisconnectedAndHealthy,
DisconnectedAndResynchronizing, orSeedingSource
ReplayQueueLength < 50
6Catalog HealthyCopy status Healthy, DisconnectedAndHealthy,
DisconnectedAndResynchronizing, orSeedingSource
CopyQueueLength < 10
7Catalog CrawlingCopy status Healthy, DisconnectedAndHealthy,
DisconnectedAndResynchronizing, orSeedingSource
CopyQueueLength < 10
8Catalog HealthyCopy status Healthy, DisconnectedAndHealthy,
DisconnectedAndResynchronizing, orSeedingSource
9Catalog CrawlingCopy status Healthy, DisconnectedAndHealthy,
DisconnectedAndResynchronizing, orSeedingSource
10Copy status Healthy, DisconnectedAndHealthy,
DisconnectedAndResynchronizing, orSeedingSource
Exchange 2010 High Availability FundamentalsBackups
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/logsAlways choose Passive (or Active) copyBackup an entire server Designate a dedicated backup server for a given database
Restore from any of these backups scenarios
DB2DB3
DB2DB3
DB1
DB3
DB1 DB1
VSS requestor
DB2
Database Availability Group
Mailbox Server 1
Mailbox Server 2
Mailbox Server 3
Multiple Database Copies Enable Backupless Configurations Exchange 2010 HA
E-mail archiveExtended/protected dumpster retention
7-14 day lag copy
X
Database Availability Group
Mailbox Server 1
Mailbox Server 2
Mailbox Server 3
DB1DB2DB3
DB1DB2DB3
DB1DB2DB3
Site/server/disk failureArchiving/complianceRecover deleted items
Deploying Exchange2010 HA Features
Legacy Deployment Steps (CCR/SCC)
Exchange 2010 Incremental Deployment
1. Prepare hardware, install proper OS, and update
Extra for SCC: configure storage2. Build Windows Failover Cluster
Extra for SCC: configure storage3. 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 serverExtra for SCC: configure disk
resource dependencies6. Test *overs
1. Prepare hardware, install proper OS, and update
2. Run Setup and install Mailbox role3. Create a DAG and replicate
databases4. Test *overs
Incremental DeploymentEasy to add high availability to existing deploymentHigh availability configuration is post-setupHA Mailbox servers can host other Server Roles
Mailbox Server 1
Mailbox Server 2
Database Availability Group
Mailbox Server 3
Datacenter 1 Datacenter 2
DB2
DB3
DB1
DB2
DB3
DB1
DB2
DB3
DB1
Reduces cost and complexity of HA deployments
Creating a Database Availability GroupExchange Management Console
Creating a Database Availability GroupExchange Management Console
Creating a Database Availability GroupExchange Management Console
Creating a Database Availability GroupExchange Management ShellCreate a DAGNew-DatabaseAvailabilityGroup -Name DAG1 -FileShareWitnessShare \\CTD-CH02\DAGWitness -FileShareWitnessDirectory C:\DAGWitnessAdd first Mailbox Server to DAGAdd-DatabaseAvailbilityGroupServer -Identity DAG1 -MailboxServer CTD-MBX1 -DatabaseAvailablityGroupIpAddresses 192.168.1.100Add second and subsequent Mailbox ServerAdd-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer CTD-MBX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EXMBX3 -DatabaseAvailablityGroupIpAddresses 192.168.1.100, 192.168.2.10Add Mailbox Database CopyAdd-MailboxDatabaseCopy -Identity MBXDB1 -MailboxServer CTD-MBX2Extend as needed
Simplified ManagementHA Administration within ExchangeRecovery uses the same simple operation for a wide range of failuresSimplified activation of Exchange services in a standby datacenterReduces cost and complexity of management
1
2
Managing Availability in the Exchange Management Console
3View locations and status of replicated copies
Take action (add copies, change master, etc.)
Select a database
Demo
DAG Demo LAB Setup Diagram
Exchange 2010 High Availability Design Examples
AD: Dublin
CCR CCR
CCR CCR
DAG
DAG
DAG
FileShare
FileShare
FileShare
FileShare
DAG DA
G
FileShare
Not an upgrade path – A design path
High Availability Design ExampleCCR Design -> DAG Design
Single Site
3 HA Copies
Database Availability Group (DAG)
DB1 DB2 DB3
DB5 DB6
DB1 DB2 DB3
DB4 DB5 DB6
DB1 DB2 DB3
DB4 DB5 DB6DB4
MailboxServer 1
MailboxServer 2
MailboxServer 3
3 Nodes
X
CAS NLB Farm
AD: Dublin
XJBOD -> 3 physical Copies
2 servers out -> manual activation of server 3
In 3 server DAG, quorum is lostDAGs with more servers sustain more failures – greater resiliency
High Availability Design ExampleDouble Resilience – Maintenance + DB Failure
CAS/HUB/
MAILBOX 1
CAS/HUB/
MAILBOX 2
Member servers of DAG can host other server roles
Hardware Load Balancer
DB1
DB2
DB3
DB2
DB1
DB2
DB3
2 server DAGs, with server roles combined or not, should use RAID
High Availability Design ExampleBranch Office or Smaller Deployment
TakeawaysWith each release, our goals are to make Exchange high availability:
Easier and cheaper to deployEasier and cheaper to manageSupport better SLAs with faster and more granular recoveriesImprove site resiliency support
Our other goal is for highly available deployments to be mainstream!
Q & A
© 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.