The document summarizes new storage and high availability features in Exchange Server 2013, including: - Multiple databases per storage volume to improve storage efficiency and reseed performance. - Automatic reseed functionality that uses spare volumes to automatically restore redundancy after disk failures without manual intervention. - Enhanced recovery capabilities to automatically recover from various storage-related failures. - Improved lagged copy functionality including automatic log playback in certain situations. - Managed availability framework to more proactively monitor protocol and database health and trigger automated recovery actions or failovers when needed. - Enhancements to the best copy selection algorithm to consider overall protocol health on servers in addition to replication health.

1. Exchange Server 2013
High Availability | Site Resilience
Scott Schnoll
Principal Technical Writer
Microsoft Corporation

2. Agenda
Storage
High Availability
Site Resilience

4. Storage Challenges
Capacity is increasing, but IOPS are not
Database sizes must be manageable
Reseeds must be fast and reliable
Passive copy IOPS are inefficient
Lagged copies have asymmetric storage requirements
Low agility from low disk space recovery

5. Storage Innovations
Multiple Databases Per Volume
Automatic Reseed
Automatic Recovery from Storage Failures
Lagged Copy Enhancements

7. Multiple Databases Per Volume
4-member DAG
4 databases
4 copies of each database
4 databases per volume
Symmetrical design with balanced
activation preference
Number of copies per database =
number of databases per volume
DB2 DB3 DB4
Active Passive Lagged

8. Multiple Databases Per Volume
Single database copy/disk:
Reseed 2TB Database = ~23 hrs
Reseed 8TB Database = ~93 hrs
DB1 DB1 20 MB/s DB1 DB1
Active Passive

9. Multiple Databases Per Volume
Single database copy/disk:
Reseed 2TB Database = ~23 hrs
Reseed 8TB Database = ~93 hrs
4 database copies/disk:
Reseed 2TB Disk = ~9.7 hrs
Reseed 8TB Disk = ~39 hrs
20 MB/s DB2 12 MB/s DB3 20 MB/s DB4
12 MB/s Active Passive Lagged

10. Multiple Databases Per Volume
Requirements Best Practices
Single logical disk/partition per Same neighbors on all servers
physical disk
Balance activation preferences
Database copies per volume =
copies per database

12. Seeding Challenges
Disk failure on active copy = database failover
Failed disk and database corruption issues need to be addressed quickly
Fast recovery to restore redundancy is needed

13. Seeding Innovations
Automatic Reseed (Autoreseed) - use spares to automatically restore
database redundancy after a disk failure

14. Autoreseed
X

15. Autoreseed Workflow
Periodically Check Verify that
scan for failed prerequisites: Allocate Admin
Start the the new
and single and remap replaces
suspended copy, spare seed copy is
a spare failed disk
copies availability healthy

16. Autoreseed Workflow
1. Detect a copy in an F&S state for 15 min in a row
2. Try to resume copy 3 times (with 5 min sleeps in between)
3. Try assigning a spare volume 5 times (with 1 hour sleeps in between)
4. Try InPlaceSeed with SafeDeleteExistingFiles 5 times (with 1 hour
sleeps in between)
5. Once all retries are exhausted, workflow stops
6. If 3 days have elapsed and copy is still F&S, workflow state is reset
and starts from Step 1

17. Autoreseed Workflow
Prerequisites
Copy is not ReseedBlocked or ResumeBlocked
Logs and EDB files are on same volume
Database and Log folder structure matches required naming convention
No active copies on failed volume
All copies are F&S on the failed volume
No more than 8 F&S copies on the server (if so, we might be in a controller failure situation)
For InPlaceReseed
If EDB files exists, wait for 2 days before in-place reseeding (based on LastWriteTime of edb file)
Only up to 10 concurrent seeds are allowed

18. Autoreseed AutoDagDatabasesRootFolderPath
AutoDagVolumesRootFolderPath
Configure storage Create DAG, add servers
subsystem with spare disks with configured storage
Create directory and Configure 3 AutoDAG
mount points properties
MDB1 MDB2
Create mailbox databases
and database copies
MDB1 MDB2
AutoDagDatabaseCopiesPerVolume = 1 MDB1.DB MDB1.log
MDB1.DB MDB1.log

19. Autoreseed
Requirements
Single logical disk/partition per physical disk
Specific database and log folder structure must be used
Recommendations
Same neighbors on all servers
Databases per volume should equal the number of copies per database
Balance activation preferences
Configuration instructions at http://aka.ms/autoreseed

20. Autoreseed
Numerous fixes in CU1
Autoreseed not detecting spare disks correctly or using detected disks
GetCopyStatus has a new field 'ExchangeVolumeMountPoint' which
shows the mount point of the database volume under
C:ExchangeVolumes
Better tracking around mount path and ExchangeVolume path
Increased autoreseed copy limits (previously 4, now 8)

22. Storage Challenges
Storage controllers are essentially mini-PCs and they can
crash/hang
Other operator-recoverable conditions can occur
Loss of vital system elements
Hung or highly latent IO

23. Storage Innovations
Exchange Server 2013 includes functionality to automatically recovery
from a variety of new storage-related failures
Innovations added in Exchange 2010 also carried forward
Even more behaviors added in CU1

24. Automatic Recovery from Storage Failures
Exchange Server 2010 Exchange Server 2013
ESE Database Hung IO (240s) System Bad State (302s)
Failure Item Channel Heartbeat (30s) Long I/O times (41s)
SystemDisk Heartbeat (120s) MSExchangeRepl.exe memory threshold
(4GB)
System Bus Reset (Event 129)
Replication service endpoints not
responding

26. Lagged Copy Challenges
Activation is difficult
Require manual care
Cannot be page patched

27. Lagged Copy Innovations
Automatic play down of log files in critical situations
Integration with Safety Net

28. Lagged Copy Innovations
Automatic log play down
Low disk space (enable in registry)
Page patching (enabled by default)
Less than 3 other healthy copies (enable in AD; configure in registry)
Simpler activation with Safety Net
No need for log surgery or hunting for the point of corruption

30. High Availability Challenges
High availability focuses on database health
Best copy selection insufficient for new architecture
Management challenges around maintenance and DAG network
configuration

31. High Availability Innovations
Managed Availability
Best Copy and Server Selection
DAG Network Autoconfig

33. Managed Availability
Key tenet for Exchange 2013
All access to a mailbox is provided by the protocol stack on the Mailbox server that hosts the active
copy of the user’s mailbox
If a protocol is down on a Mailbox server, all active databases lose access via that protocol
Managed Availability was introduced to detect these kinds of
failures and automatically correct them
For most protocols, quick recovery is achieved via a restart action
If the restart action fails, a failover can be triggered

34. Managed Availability
An internal framework used by component teams
Sequencing mechanism to control when recovery actions are taken
versus alerting and escalation
Includes a mechanism for taking servers in/out of service (maintenance
mode)
Enhancement to best copy selection algorithm

35. Managed Availability
MA failovers come in two forms
Server: Protocol failure can trigger server failover
Database: Store-detected database failure can trigger database failover
MA includes Single Copy Alert
Alert is per-server to reduce flow
Still triggered across all machines with copies
Monitoring triggered through a notification
Logs 4138 (red) and 4139 (green) events based on 4113 (red) and 4114 (green) events

37. Best Copy Selection Challenges
Process for finding the “best” copy of a specific database to
activate
Exchange 2010 uses several criteria
Copy queue length
Replay queue length
Database copy status – including activation blocked
Content index status
Not good enough for Exchange Server 2013, because protocol
health is not considered

38. Best Copy and Server Selection
Still an Active Manager algorithm performed at *over time based on
extracted health of the system
Replication health still determined by same criteria and phases
Criteria now includes health of the entire protocol stack
Considers a prioritized protocol health set in the selection
Four priorities – critical, high, medium, low (all health sets have a priority)
Failover responders trigger added checks to select a “protocol not worse”
target

39. Best Copy and Server Selection
All Healthy
Checks for a server hosting a copy that has all health sets in a healthy state
Up to Normal Healthy
Checks for a server hosting a copy that has all health sets Medium and above in a healthy state
All Better than Source
Checks for a server hosting a copy that has health sets in a state that is better than the current server hosting the
affected copy
Same as Source
Checks for a server hosting a copy of the affected database that has health sets in a state that is the same as the current server hosting the
affected copy

41. DAG Network Autoconfig
Automatic or manual DAG network config
Default is Automatic
Requires specific configuration settings on MAPI and Replication network interfaces
Manual edits and EAC controls blocked when automatic networking
is enabled
Set DAG to manual network setup to edit or change DAG networks
DAG networks automatically collapsed in multi-subnet environment

44. Site Resilience Challenges
Operationally complex
Mailbox and Client Access recovery connected
Namespace is a SPOF

45. Site Resilience Innovations
Operationally simplified
Mailbox and Client Access recovery independent
Namespace provides redundancy

46. Site Resilience
Key Characteristics
DNS resolves to multiple IP addresses
Almost all protocol access in Exchange 2013 is HTTP
HTTP clients have built-in IP failover capabilities
Clients skip past IPs that produce hard TCP failures
Admins can switchover by removing VIP from DNS
Namespace no longer a SPOF
No dealing with DNS latency

47. Site Resilience
Previously loss of CAS, CAS array, VIP, LB, some portion of the DAG
required admin to perform a datacenter switchover
In Exchange Server 2013, recovery happens automatically
The admin focuses on fixing the issue, instead of restoring service

48. Site Resilience
Previously, CAS and Mailbox server recovery were tied together in site
recoveries
In Exchange Server 2013, recovery is independent, and may come
automatically in the form of failover
This is dependent on the customer’s business requirements and
configuration

49. Site Resilience
With the namespace simplification, consolidation of server
roles, separation of CAS array and DAG recovery, de-coupling of CAS
and Mailbox by AD site, and load balancing changes…
if available, three locations can simplify mailbox recovery in
response to datacenter-level events

50. Site Resilience
You must have at least three locations
Two locations with Exchange; one with witness server
Exchange sites must be well-connected
Witness server site must be isolated from network failures affecting
Exchange sites

51. Site Resilience
cas1 cas2 cas3 cas4
Redmond Portland

52. Site Resilience
cas1 cas2 cas3 cas4
Redmond Portland

53. Site Resilience
Assuming MBX3 and MBX4 are operating and one of them can lock the witness.log file, automatic failover should
occur
mbx1 mbx2 dag1 mbx3 mbx4
Redmond witness Portland

54. Site Resilience
mbx1 mbx2 dag1 mbx3 mbx4
Redmond Portland

55. Site Resilience
1. Mark the failed servers/site as down: Stop-DatabaseAvailabilityGroup DAG1 –ActiveDirectorySite:Redmond
2. Stop the Cluster Service on Remaining DAG members: Stop-Clussvc
3. Activate DAG members in 2nd datacenter: Restore-DatabaseAvailabilityGroup DAG1 –ActiveDirectorySite:Portland
mbx1 mbx2 dag1 mbx3 mbx4
Redmond Portland

56. Questions?
Scott Schnoll
Principal Technical Writer
scott.schnoll@microsoft.com
http://aka.ms/schnoll
schnoll