There has been a lot of buzz created about Exchange Server 2010’s new database capabilities.  The terms “RAID-less” and “backup-less” get mentioned in conversations but are often taken out of context, or used with incorrect assumptions.

But why are people so excited about Exchange Server 2010 and talking about throwing out RAID and backups?  There are three main reasons for this.

Three Big Exchange Server 2010 Improvements

Improved Database Performance – the Exchange database schema has been overhauled to deliver much greater efficiency and therefore much better performance in terms of disk I/O.  This overhaul stirred some controversy because it put an end to single instance storage, however the small loss of SIS delivers much greater benefits in performance.

Improved High Availability – Exchange Server 2007 had four different HA/DR options, each one with its own complexities and limitations, and each one administered in a different way.  Exchange Server 2010 simplifies this to one single, vastly more effective high availability model called Database Availability Groups.  This basically involves replicating a database between as many as 16 servers (DAG members) that can seamlessly fail over if any individual server experiences a fault.

Improved Data Retention – In Exchange Server 2010 mailboxes and databases can be much bigger than previous versions, archiving has been built in, and longer retention is feasible making recovery of single items and mailboxes possible over longer periods without having to access backups.

These improvements have led to the idea that an organization can deploy multiple Exchange servers in a DAG using cheaper, slower storage sub-systems, without RAID to replicate the data, and without backing up because emails can be recovered almost indefinitely.

Which is true, but only if Exchange Server 2010 is deployed correctly with enough resources to make this possible. Continue reading Data Protection for Exchange Server 2010

The worst possible time to define your uptime and availability requirements for an Exchange environment is when that environment is unavailable.  No email administrator wants to hear “We need this working within 2 hours” when they are looking at a dead server that is going to take all night to recover.

Uptime and availability should be defined within an SLA, or Service Level Agreement.  An Exchange Server SLA should exist in all organizations, even those that provide their own internal IT services.  The SLA is between the IT supplier or IT department and the rest of the business, and clearly defines what is an acceptable downtime or outage of the Exchange environment.

Why Are SLAs So Important?

The existence of an SLA supports many facets of the design and operation of the Exchange Server environment.

Budget – When a business defines their service level requirements they are making a commitment to providing the funds necessary to deliver those service levels.  An SLA is one of the best pieces of leverage the IT department has to secure those funds and implement an appropriate Exchange system.  Without the backing of an SLA the IT department may struggle to get approval for Enterprise server licensing, multiple servers for clustering, and other high availability components.

Server and Network Design – Exchange Server environments are designed to meet defined SLAs.  Certain uptime expectations can only be met with the right server design.  A business that is willing to go a day without email would not need the same infrastructure deployed as a bank that can’t go more than 15 minutes without email.  Clustering, redundancy, site-to-site failover, are all design points that would be included or excluded based on the SLA. Continue reading Exchange Server SLAs, and Why You Need One

In my recent post I examined the question of whether Exchange Server 2010’s new replication and retention features could mean an organization no longer needed to back up their Exchange servers.

One reader emailed me to suggest that avoiding backups would be unwise, citing the example of potential corruption within the database that might replicate to all copies within the Database Availability Group and cause loss of data.

The scenario is one that definitely needs to be considered.  Although Exchange Server 2010 includes application intelligence to detect and handle some database corruption scenarios, there still exists the possibility of logical corruption leading to data loss.

Fortunately the solution to this problem is already included in the DAG feature of Exchange Server 2010.

If you are already familiar with Exchange Server 2007 Standby Continuous Replication then you already understand the concept of replay lag time.  Replay lag time is a configurable setting on each database copy within a DAG that delays the replay of a transaction log into that database replica.  A database copy with a replay lag time of more than zero is referred to as a lagged copy.

For example, within a DAG there may be 3 servers hosting replicas of Database 1.  Two of the servers are located in a primary data center, and the third server is located at a secondary data center.

The servers at the primary data center are configured with a replay lag time of zero, meaning the passive copy of the database is kept up to date with the latest transaction log information in near real-time.  A failure of one server permits seamless failover to the second server and continued email operation for the business. Continue reading What if You Never Backed Up Your Exchange Server Again? (Part 2)

Imagine for a moment that you never had to back up your Exchange servers again.  Sounds crazy right?  Well with Exchange Server 2010, it may not be as crazy as you think.

In a recent post I described the killer new High Availability feature of Exchange Server 2010 – the Database Availability Group (or DAG for short).

A DAG is an Organization-level object that allows a database to have several passive replicas on other servers (DAG members).  When a DAG is configured it permits individual mailbox databases to failover to passive instances should any problem with the active database arise.

The nature of DAGs means that they can be deployed to protect from failures at almost any layer of the Exchange infrastructure.  DAGs can protect from anything from a single failed server hard disk to an entire data center failure as long as the DAG is architected accordingly.

How this relates to backups is simply this – if a database is protected from all failure scenarios by the DAG, why would you need to back it up at all?  Let’s take a closer look at this question. Continue reading What if You Never Backed Up Your Exchange Server Again?

I recently wrote a five part series about Exchange Server 2007 high availability, describing each of the HA features (LCR, SCC, CCR, and SCR) in detail and demonstrating their uses, strengths and weaknesses.

With the release of Exchange Server 2010 these high availability features are no longer available.  The features have now been replaced by a single high availability option known as Database Availability Groups (or DAGs for short, admittedly a horrible acronym for what is truly the product’s finest feature).

A little background is required to fully understand the evolution of Exchange storage architecture to its current incarnation in DAGs.  Going back to Exchange Server 2003 the product was limited to a maximum of 4 Storage Groups, each containing a maximum of 5 databases.  This meant a maximum of 20 databases (of either Mailbox or Public Folder type) per Exchange server.

Exchange Server 2007 improved on this in two ways.  Firstly, the product was limited to 5 Storage Groups and 5 databases for the Standard Edition, and up to 50 Storage Groups and databases for the Enterprise Edition.  The best practice with Exchange Server 2007 was to use one Storage Group per database, unlike Exchange Server 2003.

Naturally this lead to the question of why have Storage Groups at all?  Exchange Server 2010 answers this question by doing away with the concept of Storage Groups entirely.  Databases are now Organization-level objects that contain both the transaction logs and the database itself.

Exchange Server 2010 then introduces the Database Availability Group to provide high availability.  A DAG is a group of Mailbox Servers (up to 16 per DAG) that replicate databases and perform automatic failover and recovery for either individual database or entire server failures.

So how does this compare to Exchange Server 2007 high availability?  An immediate advantage is that DAGs unify Exchange high availability into a single feature and management toolset, unlike Exchange Server 2007 which had 4 different features each managed with different tools.

Let’s take a more detailed look at each of the features to see how they compare to DAGs. Continue reading Exchange Server 2010 Delivers Improved Availability

In my last posts I discussed Exchange Server 2007 Single Copy Clusters, which is one of two clustering features available in Exchange.  In this post I will discuss the other type of Exchange Server 2007 clustering, Cluster Continuous Replication

What is Cluster Continuous Replication?

Cluster Continuous Replication (CCR) for Exchange Server 2007 would not be familiar to anyone who only has clustering experience with previous versions of Exchange.  In a CCR cluster two cluster server nodes connect to non-shared resources in an active/passive configuration.  Exchange storage group and mailbox database information is replicated between the active and passive node using asynchronous log shipping.  I explained asynchronous log shipping in the first part of this series on the basic concepts of Exchange Server 2007 high availability.  The same log shipping occurs in Local Continuous Replication.

The two CCR cluster nodes appear to other computers to be a single system, and when one server node fails the clustered resources are able to fail over to the other node and continue operation.

CCR provides high availability for the Mailbox Server by protecting it from the failure of either cluster server node, as well as protecting it from storage failure.  Because each cluster node is connected to its own non-shared storage, the failure of one does not impact the other.  This also means that CCR disk storage can consist of much cheaper hardware alternatives than an enterprise-grade SAN would cost, making Exchange high availability a reality for businesses with smaller budgets. Continue reading Exchange Server 2007 High Availability Part 4 – Cluster Continuous Replication

In my recent posts I discussed the fundamentals of Exchange Server 2007 high availability and how to use Local Continuous Replication.  In this post I will demonstrate one of the two Exchange Server 2007 clustering methods, Single Copy Clusters.

What are Single Copy Clusters?

Single Copy Clusters (SCC) for Exchange Server 2007 is basically the same as clustering in previous versions of Exchange Server.  Two cluster server nodes connect to shared resources in an active/passive configuration.  The two servers appear to other computers to be a single system, and when one server node fails the clustered resources are able to fail over to the other node and continue operation.

SCC provides high availability for the Mailbox Server by protecting it from the failure of either cluster server node.  Typically the cluster will also consist of redundant networking (e.g. teamed network interfaces, multiple switches) and storage components (e.g. a SAN that is in itself a highly available system through redundant components).  The servers are also usually located in high quality data centers with redundant power and cooling.

SCC is available in the Enterprise edition of Exchange Server 2007.  Because it uses an underlying Windows Server failover cluster, the servers that form part of the cluster must also run the Enterprise edition of Windows Server (either 2003 or 2008).

Unlike LCR an SCC cluster offers high availability benefits but no performance benefits.  Because there is a single copy of each mailbox database within the cluster there is no opportunity to use a passive copy for backup operations.

How to Install a Single Copy Cluster

In this example two Windows Server 2003 Enterprise edition servers have been configured with the basic requirements of a failover cluster:

• A public network interface for normal network operations
• A private network interface for the cluster “heartbeat”
• Shared disk storage for the database, log files, and cluster quorum disk

Once the failover cluster has been configured we can install Exchange Server 2007 on the first node.  Run setup as normal, and when selecting the roles to install choose “Active Clustered Mailbox Role” as the server role.  You will notice that a clustered mailbox server cannot co-exist with any other server role. Continue reading Exchange Server 2007 High Availability Part 3 – Single Copy Clusters

In my last post I explained the basic concepts of Exchange Server 2007 high availability.  In this post I will demonstrate one of the Exchange Server 2007 HA features that is called Local Continuous Replication.

What is Local Continuous Replication?

Local Continuous Replication (LCR) uses asynchronous log shipping technology to maintain a copy of a mailbox database on another locally connected disk volume.

For example, the mailbox database and transaction logs may reside on fast, expensive SAN disks, but the LCR copy is kept on slower, cheaper SATA disks.

LCR provides high availability for the Mailbox Server by protecting it from a storage failure.  If the SAN disks failed or became disconnected for some reason the server could continue serving end users via the replica database, possibly at a degraded performance level if the slower disks were not able to handle the required I/O load.

Because LCR is available in both Standard and Enterprise editions of Exchange Server 2007 it is a fairly easy way to achieve some high availability for the server. Continue reading Exchange Server 2007 High Availability Part 2 – Local Continuous Replication

Microsoft Exchange Server 2007 has several different Mailbox Server high availability features included with the product.  Each of the features is similar to the others in some ways but also very different.

In this post I will explain each of the high availability features and which types of scenarios they are suitable for.

What is High Availability?

High availability is a term used to describe the avoidance of unplanned downtime for a computer system through the implementation of hardware and/or software solutions.  Generally speaking a high availability solution will involve the elimination of and single points of failure in the system, often by duplicating or replicating components of the system so that if one fails the other is able to continue performing the role.

An example of downtime would be an email server that has suffered a hard disk crash and is unavailable to users who are then unable to send or receive email.  An example of a high availability solution in this case would be the use of a RAID volume to protect from single disk failures. Continue reading Exchange Server 2007 High Availability Part 1 – HA Fundamentals