TechNet Webcast: Exchange 2010 High Availability

High Availability in
Scott Schnoll
scott.schnoll@microsoft.com
Principal Technical Writer
Microsoft Corporation

Agenda
Exchange 2010 High Availability Vision/Goals
Exchange 2010 High Availability Features
Exchange 2010 High Availability Deep Dive
Deploying Exchange 2010 High Availability Features
Transitioning to Exchange 2010 High Availability
End-to-End Availability Improvements
High Availability Design Examples

High Availability Vision and Goals

Exchange 2010 High Availability Vision and Goals
Vision: Deliver a fast, easy-to-deploy and operate, economical solution that can provide messaging service continuity for all customers
Goals
Deliver a solution for high availability and site resilience that is native to Exchange
Enable less expensive and less complex storage
Simplify administration and reduce support costs
Increase end-to-end availability
Support Exchange Server 2010 Online

Exchange 2010 High Availability Solution
Unified technology for high availability and site resilience
New framework for creating highly available Mailboxes
Evolution of continuous replication technology
Can be deployed on a range of storage options
Native to Exchange; not bolted onto the side

Dallas
Complex site resilience and recovery
DB1
Outlook
OWA, ActiveSync, or Outlook Anywhere
DB2
Standby Cluster
DB3
Clustered Mailbox Server had to be created manually
San Jose
Front End Server
Third-party data replication needed for site resilience
NodeB(passive)
NodeA(active)
Clustering knowledge required
Failover at Mailbox server level
DB1
DB4
DB2
DB5
DB3
DB6
Exchange Server 2003

Dallas
Complex activation for remote server / datacenter
DB1
SCR
Outlook
OWA, ActiveSync, or Outlook Anywhere
DB2
Standby Cluster
DB3
Clustered Mailbox Server can’t co-exist with other roles
San Jose
Client Access Server
No GUI to manage SCR
NodeB(passive)
NodeA(active)
CCR
Clustering knowledge required
DB1
DB4
DB1
DB4
DB2
DB2
DB5
DB5
Failover at Mailbox server level
DB3
DB3
DB6
DB6

Dallas
All clients connect via CAS servers
DB1
DB3
Client
DB5
Mailbox Server 6
San Jose
Easy to extend across sites
Failover managed by/with Exchange
Mailbox Server 1
Mailbox Server 2
Mailbox Server 3
Mailbox Server 4
Mailbox Server 5
DB1
DB4
DB1
DB5
DB3
DB2
Database level failover
DB5
DB2
DB1
DB4
DB3
DB3
DB1
DB2
DB4
DB5

Exchange Server 2010High Availability Features

Exchange 2010 High Availability Feature Names
Mailbox Resiliency – Name of Unified High Availability and Site Resilience Solution
Database Availability Group – A group of up to 16 Mailbox servers that host a set of replicated databases
Mailbox Database Copy – A mailbox database (.edb file and logs) that is either active or passive
Database Mobility – The ability of a single mailbox database to be replicated to and mounted on other mailbox servers

Exchange 2010 High Availability Feature Names
RPC Client Access service – A Client Access server feature that provides a MAPI endpoint for Outlook clients
Shadow Redundancy – A transport feature that provides redundancy for messages for the entire time they are in transit
Incremental Deployment – The ability to deploy high availability /site resilience after Exchange is installed
Exchange Third Party Replication API – An Exchange-provided API that enables use of third-party replication for a DAG in lieu of continuous replication

Exchange 2010 High Availability Terminology
High Availability – Solution must provide data availability, service availability, and automatic recovery from failures
Disaster Recovery – Process used to manually recover from a failure
Site Resilience – Disaster recovery solution used for recovery from site failure
*over – Short for switchover/failover; a switchover is a manual activation of one or more databases; a failover is an automatic activation of one or more databases after a failure

Exchange 2010 *overs
Within a datacenter
Database or server *overs
Datacenter level: switchover
Between datacenters
Database or server *overs
Assumptions:
Each datacenter is a separate Active Directory site
Each datacenter has live, active messaging services
Standby datacenter must be active to support single database *over

Exchange 2007 Concepts Brought Forward
Extensible Storage Engine (ESE)
Databases and log files
Continuous Replication
Log shipping and replay
Database seeding
Store service/Replication service
Database health and status monitoring
Divergence
Automatic database mount behavior
Concepts of quorum and witness
Concepts of *overs

Exchange 2010 Deprecated Concepts
Storage Groups
Databases identified by the server on which they live
Server names as part of database names
Clustered Mailbox Servers
Pre-installing a Windows Failover Cluster
Running Setup in Clustered Mode
Moving a CMS network identity between servers
Shared Storage
Two HA Copy Limits
Private and Public Networks

Exchange 2010 High Availability Deep Dive

Exchange 2010 HA Fundamentals
RPC CAS
Database Availability Group
Server
Database
Database Copy
Active Manager
RPC Client Access
SVR
DB
DB
copy
copy
copy
copy
AM
AM
SVR
DAG
RPC CAS

Database Availability Group (DAG)
Base component of high availability and site resilience
A group of up to 16 servers that host a set of replicated databases
“Wraps” a Windows Failover Cluster
Manages membership (DAG member = node)
Provides heartbeat of DAG member servers
Active Manager stores data in cluster database
Defines a boundary for:
Mailbox database replication
Database and server *overs
Active Manager

Mailbox Database Replication
Continuous Replication
Uses TCP instead of SMB
Supports encryption and compression
Supports multiple replication networks
Third Party Replication API
Intended for 3rd party synchronous replication

Active Manager
Exchange component that manages *overs
Runs on every server in the DAG
Selects best available copy on failovers
Is the definitive source of information on where a database is active
Stores this information in cluster database
Provides this information to other Exchange components (e.g., RPC Client Access and Hub Transport)
Two Active Manager roles: PAM and SAM

Active Manager
Primary Active Manager (PAM)
Runs on the node that owns the cluster group
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 about which server hosts the active copy of the mailbox database
Both roles are necessary for automatic recovery
If Replication service is stopped, automatic recovery will not happen

Active ManagerSelection of Active Database Copy
Active Manager selects the “best” copy to become active when existing active fails
Ignores servers that are unreachable or activation is temporarily or regularly blocked
Sorts copies by currency to minimize data loss
Breaks ties during sort based on Activation Preference
Selects from sorted listed based on copy status of each copy

Active ManagerSelection of Active Database Copy
Active Manager selects the “best” copy to become active when existing active fails
8
6
9
5
7
10
Catalog Crawling
Copy status Healthy, DisconnectedAndHealthy,DisconnectedAndResynchronizing, orSeedingSource
CopyQueueLength < 10
Catalog Healthy
Catalog Crawling
Catalog Healthy
ReplayQueueLength < 50
Catalog Crawling
Catalog Healthy
Catalog Crawling
Catalog Healthy

Example: Database Failover
Database failure occurs
Failure item is raised
Active Manager moves active database
Database copy is restored
Similar flow within and across datacenters
DAG
Mailbox Server 1
Mailbox Server 2
Mailbox Server 3
Mailbox Server 4
Mailbox Server 5
DB3
DB2
DB4
DB3
DB4
DB1
DB5
DB4
DB5
DB5
DB2
DB1
DB3
DB1
DB2

Example: Server Failover
Server failure occurs
Cluster notification of node down
Active Manager moves active databases
Server is restored
Cluster notification of node up
Database copies resynchronize with active databases
Similar flow within and across datacenters
DAG
Mailbox Server 1
Mailbox Server 2
Mailbox Server 3
Mailbox Server 4
Mailbox Server 5
DB3
DB2
DB4
DB3
DB4
DB1
DB5
DB4
DB5
DB5
DB2
DB1
DB3
DB1
DB2

DAG Lifecycle
DAG is created initially as empty object in Active Directory
Continuous replication or 3rd party replication using Third Party Replication mode
When first Mailbox server is added to a DAG
A Windows failover cluster is formed with a Node Majority quorum using the name of the DAG
The server is added to the DAG object in Active Directory
A cluster network object (CNO) for the DAG is created in the built-in Computers container
One or more IP addresses is assigned to the DAG
The Name and IP address(s) of the DAG is registered in DNS
The cluster database for the DAG is updated with info on configured databases, including if they are locally active (which they should be)

DAG Lifecycle
When second and subsequent Mailbox server is added to a DAG
The server is joined to cluster for the DAG
The quorum model is automatically adjusted
Node Majority - DAGs with odd number of members
Node and File Share Majority - DAGs with even number of members
File share witness cluster resource, directory, and share are automatically created by Exchange when needed
Additional specified IP addresses are added to the DAG and registered in DNS
The server is added to the DAG object in Active Directory
The cluster database for the DAG is updated with info on configured databases, including if they are locally active (which they should be)

DAG Lifecycle
After servers have been added to a DAG
Configure the DAG
Network Encryption
Network Compression
Configure DAG networks
Network subnets
Enable/disable MAPI traffic/replication
Create mailbox database copies
Seeding is performed automatically
Monitor health and status of database copies
Perform switchovers as needed

DAG Lifecycle
Before you can remove a server from a DAG, you must first remove all replicated databases from the server
When a server is removed from a DAG:
The server is evicted from the cluster
The cluster quorum is adjusted as needed
The server is removed from the DAG object in Active Directory
Before you can remove a DAG, you must first remove all servers from the DAG

Deploying Exchange 2010 High Availability Features

Deploying Exchange 2010 HA Features

Exchange 2010 Incremental Deployment (Beta)
Create a DAGNew-DatabaseAvailabilityGroup -Name DAG1 -FileShareWitnessShare \EXHUB1DAG1FSW -FileShareWitnessDirectory C:DAG1FSW
Add first Mailbox Server to DAGAdd-DatabaseAvailbilityGroupServer -Identity DAG1 -MailboxServer EXMBX1 -DatabaseAvailablityGroupIpAddresses 10.0.0.8
Add second and subsequent Mailbox ServerAdd-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EXMBX2Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EXMBX2 -DatabaseAvailablityGroupIpAddresses 10.0.0.8,10.0.1.8
Add Mailbox Database CopyAdd-MailboxDatabaseCopy -Identity MBXDB1 -MailboxServer EXMBX3
Extend as needed

Transitioning to Exchange 2010 High Availability

Transition Steps
Verify that you meet requirements for Exchange 2010
Deploy Exchange 2010
Use Exchange 2010 mailbox move features to migrate
Unsupported Transitions
In-place upgrade to Exchange 2010 from any previous version of Exchange
Using database portability between Exchange 2010 and non-Exchange 2010 databases
Backup and restore of earlier versions of Exchange databases on Exchange 2010
Using continuous replication between Exchange 2010 and Exchange 2007

Exchange 2010 End-to-End Availability Improvements

Online Move Mailbox
Supported between Exchange 2010 databases, and between Exchange 2007 SP2 and Exchange 2010 databases
User can access their mailbox while move is in progress
Move is performed asynchronouslyby a new service called the Microsoft Exchange Mailbox Replication Service (MRS), which runs on Client Access servers
E-Mail Client
Mailbox Server 1
Mailbox Server 2

RPC Client Access service
A new service that establishes a RPC endpoint for client access on the CAS role to replace the existing RPC endpoint on the Mailbox role
New RPC endpoint entirely re-written in managed code
Re-factored common business logic from Exchange 2007 that overlaps with what is needed by the RPC endpoint
Cmdlets, performance counters, etc. to manage and monitor
Does not replace RPC endpoint for public folder databases; Outlook clients logon directly with public folder store to access public folder databases

Shadow Redundancy

Mailbox
Server
X
EdgeTransport
Servers keep “shadow copies” of items until they are delivered to the next hop
Also helps simplify Hub and Edge Transport Server upgrades and maintenance
HubTransport
Edge Transport

Transport Dumpster Improvements
Gets feedback from replication pipeline to let it know when to delete items
Once something has been delivered, and the logs for the message are replicated, transport dumpster can delete the message
Replay is not required for deleting items from dumpster; only data in dumpster is data that has not yet been replicated
Responds to requests for redelivery after lossy failover both within its Active Directory site and across Active Directory sites (old site and new site)

Using 3 or more database copies enables you to use replication for your backups
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 3
Mailbox Server 2
DB1
DB1
DB1
DB2
DB2
DB2
X
DB3
DB3
DB3

Exchange Server 2010 High Availability Design Examples

High Availability Design ExampleBranch/Small Office Design
Hardware Load Balancer
8 processor cores recommended with a maximum of 64GB RAM
Member servers of DAG can host other server roles
Client Access
Hub Transport
Mailbox
Client AccessHub TransportMailbox
DB1
DB1
UM role not recommended for co-location
2-server DAGs should use RAID
DB2
DB2
DB2
DB3
DB3

High Availability Design ExampleDouble Node/Disk Failure Resilience
AD: Dublin

Single Site
4 Nodes
3 HA Copies
JBOD -> 3+ Copies
Upgrade Server 1
Server 2 fails
Server 1 upgrade done
2 active copies die

CAS NLB Farm
X
Mailbox
Server 1
Mailbox
Server 2
Mailbox
Server 3
Mailbox
Server 4
X
DB6
DB4
DB5
DB3
DB7
DB5
DB2
DB1
DB3
DB8
DB7
DB1
DB8
DB1
DB2
DB6
DB7
DB8
DB5
DB4
DB6
DB2
DB3
DB4
Database Availability Group (DAG)

High Availability for Other Server Roles

Key Takeaways
Greater end-to-end availability with Mailbox Resiliency
Unified framework for high availability and site resilience
Faster and easier to deploy with Incremental Deployment
Reduced TCO with core ESE architecture changes and more storage options
Supports large mailboxes for less money

Questions and Answers
Submit text questions using the “Ask” button.
Don’t forget to fill out the survey.
For upcoming and previously live webcasts: www.microsoft.com/webcast
Got webcast content ideas? Contact us at: http://go.microsoft.com/fwlink/?LinkId=41781

Additional Resources
Exchange Server 2010 Webcasts
Exchange 2010 Overview (June 3rd, 9am PST)
Exchange 2010 Management Tools (June 8th, 1pm PST)
Exchange 2010 Archiving and Retention (June 10, 9am PST)
http://msexchangeteam.com/archive/2009/05/26/451465.aspx
Download the Exchange Server 2010 Betahttp://technet.microsoft.com/evalcenter/dd185495.aspx
Read the Exchange Server 2010 Documentationhttp://technet.microsoft.com/library/bb124558(EXCHG.140).aspx
Read Exchange Team Blog Postshttp://msexchangeteam.com/archive/category/11164.aspx
Participate in Exchange Server 2010 Forumshttp://social.technet.microsoft.com/Forums/en-US/exchange2010/threads