Exchange HA: Keeping on Message
High availability has become more than a buzzword for IT departments serving enterprise environments.
Although HA typically has come with a hefty price tag attached, modern implementations built into Microsoft Exchange Server make it a manageable expense and an administrative must-have for many organizations.
Since its 2003 release of Exchange, Microsoft has included HA features in the messaging software. But the options available are somewhat unique to each of three key versions of Exchange: 2003, 2007 and 2010. Here's a rundown of the availability capabilities of each one.
With Exchange 2003, if you wanted to implement HA you would go with a clustered set of servers (requiring the Enterprise Edition) that allowed some form of shared storage.
Although this solution works, it doesn't provide a great deal of flexibility, nor does it adequately protect against storage failure. The systems can failover to one another, but the shared storage is a weak point. Microsoft had a good reason for this. Many of the shared storage area network and network-attached storage solutions available when Microsoft released Exchange 2003 included their own redundant features (RAID, multiple power supplies and so forth) to ensure the storage was bullet-proof.
Exchange 2007 kept the clustered solution with a shared storage option on the table in the form of Single Copy Clusters that mimicked the 2003 method. But Microsoft also introduced two new flavors of HA, and the 2007 Service Pack 1 release added a third. The additional availability tools all rely on a Continuous Replication (CR) feature.
For the CR approach to make sense, you have to have a basic grasp of Exchange storage architecture. In short, as mail comes into a server, it gets written to transaction logs (which were 5 megabytes in size in Exchange 2003, but dropped to 1MB in Exchange 2007 and 2010 for easier transport and less data loss in the event of a crash).
These logs play into the database and are backed up for full coverage if a disaster strikes. CR makes a copy of the database and then replicates transaction logs only and replays them into the copied (passive) database. This is called log shipping and replay. If the primary or active copy dies, the secondary or passive copy can be used.
The three versions of HA with CR in 2007 provide for recovery in the event that disaster hits your disk, your server or your site. Here's how:
For the latest version of Exchange, Microsoft took the best of all of its earlier HA features and introduced a solution based on a new storage architecture. Availability now no longer relies on storage groups but focuses on the database instead.
Microsoft Online Exchange HA Help:
In this approach, CR is used between members of a database availability group (DAG). You create a DAG under the Organization node within the Exchange Management Console. Once you have a group, you need to add members, but this still doesn't ensure HA. Once members are added to the group, you must decide which databases will be replicated to which members (you can have up to 16). You can pick and choose the number of replicas and where they go.
2010 uses failover clustering, but one chief benefit is that you don't have to configure it. It is installed and configured behind the scenes. Failover is automatic as a result, and the flexibility is impressive.
HA has steadily evolved in Exchange, and you may find that the options Microsoft provides are just what you need -- and maybe all that you need. But if you require more protection, you can also consider other third-party replication options that Microsoft recommends for up-to-the-minute/second/nanosecond protection of your data.