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

E00.log E0000000012.log E0000000011.log

Log

Database

1. Copy logs

3. Replay logs

Local

Cluster
File Share

Standby

Log shipping to a local disk

Log shipping within a cluster

Log shipping to a standby server or cluster

Outlook (MAPI) client AD site: San Jose

OWA, ActiveSync, or Outlook Anywhere

Manual activation of remote mailbox server

AD site: Dallas
Client Access Server

DB4 DB5

Client Access Server

Mailbox server cant co-exist with other roles

Standby Server

DB6

SCR

CCR #1 Node A

CCR #1 Node B

CCR #2 Node A

CCR #2 Node B

SCR managed separately; no GUI Clustering knowledge required Database failure requires server failover

Windows cluster

Windows cluster

DB1 DB2 DB3

DB1 DB2 DB3

DB4 DB5 DB6

DB4 DB5 DB6

Windows Failover Cluster

Default Cluster Group
Cluster IP Address Cluster Name Cluster Quorum

Clustered Mailbox Server (CMS)

CMS IP Address CMS Name CMS resources (exres.dll) CMS disk resources

Cluster Database

Cluster Networks

Database Availability Group

Active Manager
PAM SAM

DAG Networks

Windows Failover Cluster

Default Cluster Group
Cluster IP Address Cluster Name Cluster Quorum

Cluster Database

Database Availability Group

Mailbox Server
GetMailboxDatabaseCopyStatus

Mailbox Server
GetMailboxDatabaseCopyStatus

Mailbox Server
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
Further Input/Output (I/O) reductions RAID*-less/JBOD** support

Key Benefits Easier and cheaper to deploy Easier and cheaper to manage Better Service Level Agreements (SLAs)

Reduced storage costs Larger mailboxes

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

DB1 DB3

AD site: San Jose

Mailbox Server 6

DB5

Client Access Server (CAS)

Easy to stretch across sites

Mailbox Server 1

Mailbox Server 2

Mailbox Server 3

Mailbox Server 4

Mailbox Server 5

Failover managed within Exchange

DB1 DB2 DB3

DB4 DB5 DB1

DB2 DB3

DB5 DB1

DB3 DB4 DB5

DB4

DB2

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 DAGs 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 DB2 DB3

DB4 DB1 DB2

DB3 DB4

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 DB2 DB3

DB4 DB1 DB2

DB3 DB4 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

Mailbox Server 2

DB1 DB2 DB3

DB1 DB2 DB1 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 targets Inspector directory

Active Manager selects the best copy to become active when existing active fails

10 8 6 9 5 7

Catalog Copy status or

Crawling Healthy Healthy, DisconnectedAndHealthy, DisconnectedAndResynchronizing,

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 DB2 DB3

DB1 DB2 DB3

DB2
DB3

VSS requestor

Site/server/disk failure Archiving/compliance Recover deleted items

Exchange 2010 HA E-mail archive Extended/protected dumpster retention

Database Availability Group

Mailbox Server 1

Mailbox Server 2

Mailbox Server 3 7-14 day lag copy

DB1 DB2 DB3

DB1 DB2 DB3

DB1 DB2 DB3

Legacy Deployment Steps (CCR/SCC) 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

Exchange 2010 Incremental Deployment 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
Database Availability Group

Datacenter 2

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

View locations and status of replicated copies

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

Member servers of DAG can host other server roles

DB2

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.