It's time to verify that our Exchange 2007 clustered mailbox server is working as expected. Let's first open the Cluster Administrator and check whether the respective Exchange resources have been created. If you take a look at Figure 8.71, it looks good; we have both nodes listed in the left pane and all Exchange resources have been created and are currently owned by EDFS07.
Try to open the EMS by clicking Start -> All Programs -> Microsoft Exchange Server 2007 -> Exchange Management Shell on one of the nodes, then type Get- ClusteredMailboxServerStatus -Identity MailboxServer. As you can see in Figure 8.72, the status of the clustered mailbox server is Online, and EDFS7 is currently the active node.
You're then asked to confirm this action. Type Yes, then press Enter. After a while the clustered mailbox resources will have been moved to the second node (EDFS08), as shown in Figure 8.73.
|Warning: Even though it's possible to move the cluster resource groups between nodes using the Cluster Administrator console, you should always do so using the Move-ClusteredMailboxServer CMDlet, because the Move Group task in the Cluster Administrator console isn't Exchange 2007 aware.|
Viewing the Clustered Mailbox Server From Within the EMC
Let's take a look at the clustered mailbox server in the EMC. To do so, click Start -> All Programs -> Microsoft Exchange Server 2007 -> Exchange Management Console, then drill down to Server Configuration -> Mailbox. Notice that the clustered mailbox server we named MailboxServer is listed in the Results pane and that it's recognized as a cluster server, as shown in Figure 8.74.
Simulating a Failover from One Node to the Other
Now let's try to simulate a failover from EDFS08 (currently the active node) to EDFS07 so that we can see what will happen from the Outlook client perspective. To switch from one node to the other, we'll issue the CMDlet we used earlier in the chapter: Move- ClusteredMailboxServer -Identity:Mailbox Server -TargetMachine:EDFS07 -MoveComment:"Simulating a failover from one node to the other, seen from the end-user perspective".
When a manual move or a failover occurs, the balloon shown in Figure 8.75 will appear because all services need to be stopped on EDFS07 before they can be moved and brought online on EDFS08.
Depending on the number as well as the size of the databases in your Cluster Continuous Replication setup, this will take somewhere between 10 seconds to a couple of minutes, which shouldn't cause panic for the end users in the organization.
When EDFS08 has taken over, the end users will be notified that the connection to the Exchange Server has been restored (see Figure 8.76).
As you have seen you throughout this chapter, you benefit from several advantages when you choose to install the Exchange 2007 Mailbox Server role in a Cluster Continuous Replication setup in your organization. The primary benefit is that you no longer have a single point of failure in regard to the Mailbox/Public Folder databases. Should the database on one node crash, an automatic failover to the other node containing the secondary database will be completed. This also means that you no longer need to use a shared storage system in the CCR setup, as is the case with Exchange 2007 Single Copy Clusters as well as cluster setups in previous versions of Exchange. In addition, the two nodes in the CCR setup can even be placed in two different locations, as long as they belong to the same subnet. Not only that, the installation of the Exchange 2007 cluster has also been further simplified over previous versions. Since the CCR setup uses log file shipping and replay to a secondary database, you also don't have to do full online backups as often as was the case in Exchange 200x and earlier versions. Last but certainly not least, the failover process has been improved in several areas now that the new file share witness model has been introduced.
Backup Choices in a CCR Setup
When you deployed a cluster with Exchange 2003, the only option available when the stores were going to be backed up was to take a backup of the stores running on the production servers. With CCR (and LCR), you have the option of taking a backup of the database copies on the passive node, thereby eliminating any heavy load on the active node, both in terms of I/O to the disk spindles as well as CPU usage.
Keep in mind, though, that you can only perform a backup on the passive node using VSS, which means that Windows Backup cannot be used for this purpose. Instead you need to use Microsoft Data Protection Manager version 2 (DPM v2) or a third-party backup application that supports VSS backups.
It's also worth mentioning that any backups performed via the passive node will be backups of the database copies, not the databases on the active node. So, you might wonder, what will happen to the transaction log files on the active node? When the backups have been performed on the passive node, all log files associated with the respective storage group on the active node will be truncated. In addition, the database header on the active node will be modified, and this will generate a log file that will be replicated to the passive node and then modify the database header on the passive node afterward.
To read more about how you back up the databases in Exchange 2007, see Chapter 10.
Managing an Exchange 2007 Cluster Continuous Replication (CCR) setup
Part 1: Exchange 2007 Cluster Continuous Replication requirements
Part 2: Setting up Cluster Continuous Replication in Exchange 2007
Part 3: Creating a Windows 2003 cluster for an Exchange 2007 CCR setup
Part 4: Using a file share witness with Exchange 2007 CCR
Part 5: Enable the Transport Dumpster on the Hub Transport server
Part 6: Installing Exchange 2007 on the active node and passive node
Part 7: Testing clustered mailbox server functionality in a CCR setup
Part 8: Exchange 2007 Cluster Continuous Replication (CCR) setup overview
|This chapter excerpt from How to Cheat at Configuring Exchange Server 2007: Including Outlook Web, Mobile, and Voice Access , by Henrik Walther, is printed with permission from Syngress, a division of Elsevier, Copyright 2007.
Click here for the chapter download.