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 [1] 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.
Exchange 2003: Shared Storage
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: Continuous Replication
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:
- Local CR: LCR allows you to keep a secondary copy on another disk in the same machine. This doesn’t use clustering services so you have to manually failover the server from the active to the passive copy. Also known as the “poor man’s cluster,” LCR works great for a disk failure or corruption.
- Cluster CR: CCR uses clustering services (so there is a greater expense because you need multiple servers, with two running the mailbox role of the Enterprise Edition). This provides for an automatic server failover and uses a hub transport server for the passive log to recover as much data as possible in a crash, through a feature called the Transport Dumpster.
- Standby CR: SCR uses technology similar to LCR in that there are no clustering features installed and the failover is manual. It provides site redundancy because it can copy the database to a remote host for disaster recovery protection.
Exchange 2010: Database Focus
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 can create a DAG under the Organization node within the Exchange Management Console. Once you have a group, you need to add members. This still doesn’t ensure HA. Once members are added to the group, you must then 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.
As you can see, HA has steadily evolved in Exchange. You may find that the HA 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.
J. Peter Bruzzese is triple-MCSE, MCT and MCITP: Messaging certified. He’s also an Exchange 2010 instructor for technology training firm Train Signal and the mind behind ExclusivelyExchange [5].