Now that Exchange Server 2010 has had its first birthday, it’s a good time to remind folks about the built-in features for high availability, site resilience and disaster recovery in Exchange 2010. If you’re already running Exchange 2010, then you probably already know about database availability groups, mailbox database copies, and Active Manager. But if you’re running Exchange Server 2007 or Exchange Server 2003, there will be new concepts and technology with new benefits for your organization as you upgrade to Exchange 2010, such as incremental deployment, datacenter switchovers, and recovery databases.
Building on the native replication capabilities introduced in Exchange Server 2007, Exchange 2010 integrates high availability into the core architecture of Exchange, enabling customers of all sizes and in all segments to economically deploy a messaging continuity service in their organization. Exchange 2010 reduces the cost and complexity of deploying a highly available and site resilient messaging solution while providing higher levels of end-to-end availability, simplifying administration, and supporting large mailboxes.
In previous versions of Exchange, service availability for the Mailbox server role was achieved by deploying Exchange in a Windows failover cluster. To deploy Exchange in a cluster, you had to first build a failover cluster, and then install the Exchange program files. This process created a special Mailbox server called a clustered Mailbox server (or Exchange Virtual Server prior to Exchange 2007). If you had already installed the Exchange program files on a non-clustered server and you decided you wanted high availability, you had to build a cluster using new hardware, or rebuild the existing server by removing Exchange, installing failover clustering, and reinstalling Exchange.
Exchange 2010 introduces the concept of incremental deployment, which enables you to deploy service and data availability for all Mailbox servers and databases after Exchange is installed. Service and data redundancy is achieved by using new features in Exchange 2010 such as database availability groups and mailbox database copies. In Exchange 2010, the days of building clusters and clustered mailbox servers, and the complexity that goes with those tasks, are gone. Mailbox servers can be added to a database availability group and mailbox databases hosted on those servers can be replicated across the servers to provide automatic recovery at the mailbox database level instead of at the server level. Fast database-level failover times (<30 seconds) that are transparent to end-users, and the capability to switch between database copies, can dramatically improve an organization’s uptime. Organizations can now deploy a fully redundant Exchange organization with as few as just two Exchange servers, and benefit from database-level failovers. Customers benefit from automatic, database-level failover capabilities without having to become experts in Windows failover clustering.
Moreover, you can add site resilience to your existing high availability deployments with less complexity by simply extending database availability group across multiple physical locations (for example, primary and standby datacenters). By combining the native site resilience capabilities in Exchange 2010 with proper planning, a standby datacenter can be rapidly activated to serve a failed datacenter’s clients. In the event of a disaster affecting your primary datacenter, you can use the built-in Exchange PowerShell cmdlets for site resilience to quickly perform a datacenter switchover to move the Exchange service namespaces and data endpoints from the primary datacenter to the standby datacenter. This transition is seamless for end-users; they don’t need to use separate accounts, maintain multiple passwords or learn a new URL. They use the same URLs and namespaces as in the primary datacenter; they use the same account as in the primary datacenter, and they are accessing the same data as in the primary datacenter.
There’s a lot of information out there that will help you plan, design and manage your high availability or site resilience solution. For example, you might want to start with this four-part video blogcast on high availability in Exchange 2010:
- High Availability in Exchange Server 2010 – Part 1
- High Availability in Exchange Server 2010 – Part 2
- High Availability in Exchange Server 2010 – Part 3
- High Availability in Exchange Server 2010 – Part 4
Next, visit the Exchange 2010 library in TechNet, where you can read topics that will help you understand high availability and site resilience in Exchange 2010. When you’re ready, check out these TechEd presentations for deeper technical content:
- Microsoft Exchange Server 2010: High Availability Deep Dive
- Microsoft Exchange Server 2010 High Availability Design Considerations
Of course, as with previous versions of Exchange, Exchange Server 2010 also includes a rich backup, restore and disaster recovery feature set. For example, like Exchange 2007, Exchange 2010 supports VSS backups of mailbox databases, including both active and passive mailbox database copies. Exchange 2010 also includes support for a “recovery database” (previously called a recovery storage group in Exchange 2007).
But unlike any previous version of Exchange, Exchange 2010 also introduces several new features and core changes that, when deployed and configured correctly, can provide native data protection that eliminates the need to make traditional backups of your data. Using database availability groups to minimize downtime and data loss in the event of a disaster can also reduce the total cost of ownership of the messaging system. And by combining DAGs with other built-in features, such as Single Item recovery, organizations can reduce or eliminate their dependency on traditional point-in-time backups and reduce the associated costs. For more information on these features, see these resources:
To read all available library content for Exchange 2010 high availability and site resilience, see High Availability and Site Resilience in Exchange 2010.
Finally, to read more about continuity services, check out today’s post on the UC Blog.