Mailbox Server Role
The Mailbox role holds the Exchange databases within which the user mailboxes are contained. It is also home to the Public Folder databases if you enabled Public Folders.Exchange Server 2007 Standard edition supports a total of 5 Storage Groups and 5 databases. Enterprise edition supports up to 50 Storage groups and a maximum of 50 databases per server.
Exchange Server 2007 Backup and Recovery – Mailbox Servers
Backing up the Databases
In Exchange Server 2007, it is important to have a backup of mailbox server role. Mailbox storage groups can be backup using ntbackup features of Windows Server 2003.
Restoring the Database
Before beginning the database restore operation we must first prepare the database for recovery. To do this open the properties of the Mailbox Database and tick the “This database can be overwritten by a restore” check box.
Using the NTBackup program we can now commence the restore of the Storage Group containing the Mailbox Database.
Mailbox Database restores will not automatically initiate a transaction log replay and then mount the database unless we specifically choose to. This is for situations where the restore will involve a “full” backup set followed by a “differential” backup set, or followed by one or more “incremental” backup sets. In this case we are only restoring a full backup set, so we can enable the “Last Restore Set” and “Mount Database after Restore” settings. We must also specify a temporary path for log and patch files.
Once the restore operation is complete we can see that the Mailbox Database is now mounted and online again.
What Just Happened?
When the last restore set has been restored to the server it begins rebuilding the database using the recovered database and transaction log files from the backup set. These transaction logs are replayed from the temporary location specified during the restore operation. This achieves the outcome of restoring the database as at the time the backup was taken. In the real world this would typically mean the previous night. So what about all of the email that has been sent and received since then?
Again, in the real world Exchange Mailbox Server storage uses SAN volumes, or at the very least a disk layout that uses separate storage for the database and transaction logs. This improves recoverability by ensuring that a failure of a single disk volume only causes the loss of the database or the transaction log, and not both at the same time.
In this demonstration that means that the transaction logs that have been generated by all of the current day’s email activity are still intact. When the restore operation finishes with the data that came off the backup set it then begins to reply the transaction logs that still reside on the Exchange Mailbox Server.
This operation brings the database completely backed up to the current point in time, fully recovering all email items that were contained in it prior to the database failure. Once this log replay operation is complete the database is mounted and made available to email users again.
High Availibility Mailbox Server Role
First, let's take a closer look at the high availability options for the Mailbox server role. This is where the users' actual mailbox data is stored so it's one of the key roles to make highly available.
When you think of high availability for mailboxes in Exchange, you will most likely think of clustering since many previous versions of Exchange have included this technology. So it will come as no surprise that clustering is also at the heart of high Availability in Exchange 2007, although there are some significant changes that may cause you to re-evaluate clustering if you have previously dismissed it.
Single Copy Clusters
The first technology we'll look at is Single Copy Clusters (SCC). This technology will be familiar to those Exchange administrators who have implemented clustering in previous versions of Exchange since it's essentially the new name for 'traditional' Exchange clustering.
SCC in Exchange 2007 is essentially the same as previous versions of Exchange clustering. This means that it still uses the shared storage model, where the actual mailbox and public folder databases only exist once within the storage infrastructure (hence the term single copy). The individual cluster nodes of the SCC environment can all access the same shared data, but only one node at a time can actually use it. Figure 1 shows a simplified diagram of how this might look with a three-node SCC environment.
Figure 1: Single Copy Clusters
In Figure 1, you can see three nodes within the SCC environment, two of these are curretly active nodes (i.e. they are actively servicing users), while the third is passive. Exchange 2007 clusters only support the active/passive model: it's possible to have up to eight nodes configured as long as one is passive
The passive node is available to take ownership of the data currently belonging to one of the active nodes, if and when an issue arises with one of those active nodes. With up to eight nodes available, some interesting combinations can be designed. For example, you might consider a six-active and two-passive node system, or perhaps a four-active and four-passive node system. The latter option actually falls within the Microsoft best practice recommendations, since Microsoft recommends that you have at least one passive node for every active node that you implement.
You might consider a configuration such as a two active and two passive node SCC environments to be wasteful in terms of hardware resources, since two nodes aren't actually offering a service to the users. However, you have to consider the reason that you may have implemented such a design: high availability, and therefore the preservation of your messaging service in the event of a node failure. For example, consider the case in Figure 1, where you have two active nodes and a single passive node. If Node A fails, the service will failover to use Node C and users are largely unaffected. However, you are now in the situation where you no longer have a passive node available until you resolve the problem with Node A. Therefore, if Node B were to fail before Node A is brought back into service, there is nowhere for the services on Node B to failover to and thus users will be affected. Therefore, having at least one passive node per active node is good practice.
You can clearly see that an SCC environment is excellent at providing high availability in cases where there is a server failure. Although SCC environments can and do provide good levels of uptime, the main drawback with SCC is the fact that there is only a single copy of the storage present. Some organizations implement their Exchange databases on replicated Storage Area Networks (SANs) to overcome this. Here, synchronous data replication can be used to ensure that the Exchange databases are copied to a different SAN, typically located in a different data centre.
One key area to consider regarding clustering is that if you deploy the Mailbox server role on a clustered solution, either using SCC or Clustered Continuous Replication (CCR), which will be described later, no additional Exchange 2007 server roles can be combined with the Mailbox server role. Consequently, the minute you decide to deploy a SCC environment for your Mailbox servers, you will need additional servers to run other roles such as the Hub Transport and Client Access Server roles.
Local Continuous Replication
This is the first of the new continuous replication technologies available within Exchange 2007. The first and most obvious point to make about Local Continuous Replication (LCR) is the fact that it is a single-server solution and not a clustered solution. Therefore, LCR will not protect you against the failure of an entire server. Having said this, LCR does implement the new log shipping and replay functionality that Exchange 2007 provides. It does this by shipping the transaction logs generated by a storage group, known as the active copy, to another separate set of disks that are connected to the same server, referred to as the passive copy. Once the logs have been transferred to the alternate disks, they are replayed into a copy of the Exchange database that also resides on these disks. Thus, a separate copy of the database is maintained in near-real time fashion on the same server, and you therefore have data redundancy. Should there be a problem with the production database the administrator can switch over to using the backup copy of the database fairly quickly. An overview diagram of LCR is shown in Figure
2.
2.
Figure 2: Local Continuous Replication
It makes the most sense to deploy the second set of disks via a separate disk array controller to cover for the failure of the primary disk array controller. As I've already mentioned, LCR is not a clustered solution and therefore does not protect you should the entire server fail. However, it is a good solution to protect against mailbox data corruption and additionally offers the ability to offload Volume Shadow Copy Service (VSS) backups from the active copy of the databases. In this scenario, you configure the VSS backup to be performed against the passive storage group. This is better for disk performance on the active storage group as well as allowing online maintenance to be unaffected by the backup process.
Clustered Continuous Replication
Whilst SCC offers you protection against server failure and LCR offers you protection against data failure, Clustered Continuous Replication (CCR) offers you both server and data protection. As you can guess from the name, CCR is the second of the new continuous replication technologies available with Exchange 2007. A CCR environment is a two-node cluster only, consisting of an active and a passive node. The key difference between a CCR environment and a SCC environment is that the CCR environment does not use shared storage. Rather, both nodes of the CCR environment have their own copies of the Exchange databases and transaction logs. The transaction logs from the active node are asynchronously copied to the passive node and replayed into the database. Should a problem occur with either the active node itself or the active node's databases, the Exchange server can be failed over to run from the previously passive node and its own copy of the databases. A sample CCR environment configuration is shown in Figure 3.
Figure 3: Clustered Continuous Replication
As I stated earlier, a CCR environment consists of two nodes; it cannot be scaled out to eight nodes as with the SCC environment. However, the fact that CCR implements two separate copies of the databases and transaction logs is usually attractive to many organizations. Also, CCR can be implemented using Direct Attached Storage (DAS) rather than SAN storage. This, too, can appear attractive to many organizations although it is important to note that this may not necessarily be a straight decision to make as there are other factors to consider. Also, VSS backups can be taken from the passive node, which is obviously good for the performance of the active node, plus it has the added benefit of allowing online database maintenance to run outside of the backup window.
Some organizations may choose to implement the active CCR node in one data center with the passive CCR node in a different data centre. This is technically fine, although it should be noted that if you are deploying CCR on the Windows 2003 operating system, both CCR nodes must be in the same subnet. You will therefore need to check with the network team in your organization as to how the network is configured across the two data centers. This restriction does not apply to Windows 2008 since clusters can be implemented with nodes from different subnets, although the nodes must be in the same Windows Active Directory site. With nodes in different data centers, the CCR environment can be considered a stretched cluster. You will also need to factor in considerations such as the available network bandwidth between the two data centers as well as the latency of the network connection. Such factors can affect the performance of the system, especially when you consider the fact that the various server roles will communicate via Remote Procedure Calls (RPCs) and thus require sufficient bandwidth.
Consequently, many organizations choose to implement a CCR environment within their production data center and Standby Continuous Replication (SCR) to a disaster recovery data center. CCR then protects from server and data failure within the same data center, which is more likely than the complete loss or failure of a single data center. Having said that, you may still need to plan for that eventuality which is where SCR comes in. SCR is a site resilience solution available in Exchange 2007 Service Pack 1 that currently falls outside of the topics that I want to cover in this article.
No comments:
Post a Comment