Installing a Continuous Copy Replication or CCR Cluster Part 3…

 

In the last article, we finished setting up the cluster, and the file share for the Majority Node Set cluster.  Before we get to installing the actual Exchange CMS, lets talk a little bit about, and configure, the Transport Dumpster.

First, what is the Transport Dumpster?  It is a feature of Exchange 2007 that only comes into play when a mailbox is located on a CCR cluster.  Remember we talked about how the active node of the cluster, ships the logs to the passive node, and then plays them into its own copy of the database?  Imagine now if you had a situation where the active node went down, hard.  Let’s say the server was pretty busy, and it blue screened, the passive node could be missing a decent amount of transaction logs that should have been shipped over.  Well, we would now have missing data in our mailboxes wouldn’t we?  This is something we like to avoid!

This is where the Transport Dumpster comes in.  When configured, and a mailbox is located on a CCR cluster, and a lossy failover occurs, the Transport Dumpster will attempt to recover lost emails.  The Transport Dumpster is an organizational wide setting, and involves the Hub Transport servers.  What the dumpster actual does is store copies of ALREADY successfully delivered emails in it’s queues.  When the lossy failover occurs, the newly appointed active node of the cluster requests past emails from the Hub Transport servers for an amount of time that would account for most of the data lost.  Now, this wont hold data such as contacts or calendar appointments, but when you get down to it, the emails are the meat and potatoes.  The Transport Dumpster should help you account for almost all of the difference in data.  Now, keep in mind, this means emails that have already been delivered.  For instance, say you have a lossy failover on Tuesday at 10:00 AM.  The newly appointed active node could request all copies of emails that were delivered from Tuesday at 9:30 AM till Tuesday at 10:00 AM to account for any logs it did not receive before the failure.

There are two values that you want to be concerned with.  The first is the total size of the dumpster, and the number of days that the dumpster retains emails.  Run the Get-TransportConfig command to list the current settings:

ScreenHunter_01 Feb. 14 19.06

The total days emails are allowed to stay in the dumpster is marked by the MaxDumpsterTime value, which by default is seven days.  The total size of the dumpster depends on the value MaxDumpsterSizePerStorageGroup which by default is 18 MB.  This means if you have five storage groups, the total size of the Transport Dumpster could get no larger than 5*18MB = 90 MB.  If you added a sixth storage group it would now be 108 MB. 

Microsoft’s recommendation for configuring the Transport Dumpster is to make the maximum size per storage group value to be 1.5 times the size of the maximum message in your environment.  So if you allow messages of 50 MB in your environment, your MaxDumpsterSizePerStorageGroup should be 1.5 * 50MB = 75MB.

So first, lets get the configuration for our enviornment.  Run the Get-TransportConfig command:

ScreenHunter_02 Feb. 14 19.16

We have a 35 MB limit on sending and receiving.  So, we should set the MaxDumpsterSizePerStorageGroup value to be 1.5*35MB or 52.5.  Lets just round up to 53 MB.  We also want to set the maximum number of days that a message can last in the dumpster to be 10 days instead of the default 7. 

Run the command Set-TransportConfig –MaxDumpsterSizePerStorageGroup 53MB –MaxDumpsterTime 10.00:00:00

ScreenHunter_03 Feb. 14 19.18

Run the Get-TransportConfig again to confirm the settings:

ScreenHunter_04 Feb. 14 19.19

Okay, so that takes care of the Transport Dumpster, now on to installing Exchange CMS!!

On the active node, in our case NYCCRNODE1.ponzeka.test, install the Exchange 2007 binaries, ensure you have all of the pre-requisites in place.

For installation, select “Custom”, remember you CANNOT install any roles besides the Mailbox Role in a cluster.

ScreenHunter_01 Feb. 14 19.26

Select Active Clustered Mailbox

ScreenHunter_02 Feb. 14 19.29

Make sure to select Continuous Cluster Replication.  For the Clustered Mailbox Server Name, ensure you put in the name you want clients to be presented with.  In our case its NYMB01.

ScreenHunter_03 Feb. 14 19.30

For the next screen, you will need to enter the IP address that will be presented to the clients, in our case its 10.2.1.110

ScreenHunter_04 Feb. 14 19.31

Now the system will perform readiness checks to ensure that the CMS role can be installed on this server.  If everything checks out, hit Install.

After the install has been completed, you need to log into the passive node, NYCCRNODE2.ponzeka.test and repeat these steps.  Except this time you need to select the Passive Mailbox Server Role.

All set!  We should now have a fully functional CCR cluster!  In the next article we’ll go over how to seed a DB, update the cluster and test failovers.

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s