Exchange 2007 SCC Clustering in VMWARE using iSCSI for the Masses (the Final Part) – part 6
Yet again it has been a long time since I last posted on this subject – I have my usual repertoire of excuses being busy etc, etc but its bumf really – I should have finished this series of sooner.
Of course since my last posts (more info on them below) there has been much change in the Exchange world with the first public beta of Exchange 2010 and a revelation within the feature specifications is SCC clusters have been depreciated (come to think of it CCR only exists now as a technology rather than a convention having – being replaced by the rather excellent concept of Database Availability Groups [DAGS]) so what is the point in this article?
Well – I suspect that some Organisation will not make an immediate jump to 2010 when it is finally released perhaps preferring it to bed down a little, also there are many organisations whom are just getting over their migrations to Exchange 2007 (or perhaps just beginning) so the prospect of making another move might not be palatable. Combine this with the fact that there are a large amount of companies whom choose not to use CCR clustering and combine it with SCR essentially gives this article some purpose (although I started it such a long time ago I am trying to remember what it was…… oh yes iSCSI).
So for those of you whom are just joining us the scope of this set of articles was originally getting SCC clustering working on Windows 2008 via iSCSI using a Open Source SAN Solution – after a rather embarrassing technical discovery about Windows 2008 – I changed the scope to iSCSI on Windows 2003 – all of the drama can be found in the following parts:
In this the sixth and final part I would like to take you (very briefly) how you can install Exchange 2007 on your SCC cluster which is making use of iSCSI targets. I have said briefly, the actual installation is very straight forward and only slightly deviates from a normal Exchange 2007 install – however the following assumptions have been made:
You have already prepared your domain and Active Directory using the /PrepareAD command (e.g. I am assuming that you have updated the schema and domain before you being the install)
Finalising the cluster configuration:
Before we begin installing Exchange there are a couple of things that we should do out of good practice (even though we are working within a Lab Environment):
- Configure the network priority
- Configure the role of each cluster network
- Test Cluster Group Failover
Configuring the network priority:
In all Windows based clustering configurations the Public Network Interfaces should have the higher Connection binding order on the network, in order to configure bring up the properties of “My Network Places” and then from the “Advanced” Menu choose “Advanced Settings” – see below:
Which will present you with the following dialog box:
From the Connections area – ensure that all interfaces which deal with Public Network Traffic are placed above interfaces which deal with internal cluster communications.
Configure the role of each cluster network
Open the Cluster Administrator and expand [ Your Cluster Name –> Cluster Configuration –> Networks ]
Right click on your network entries and confirm the roles that they will play within the cluster – the following is an example of the correct setting for Internal Cluster Communications only:
Test Cluster Group Failover
On your active node – open a command window (CMD) and type in the following command:
Cluster.exe group “Cluster Group” /move
You should get the following results:
Remember to move the group back when you are done!
Installing Exchange 2007 Service Pack 1 on your Active SCC Node:
Compared to previous versions of Exchange server installing an SCC cluster is very straight forward – one prerequisite that you must have before starting setup is from within the “Cluster Administrator” you must have configure a single Cluster Group with one Disk Resource within it Disks can now be completely independent of the Exchange server group which is created during setup –see below:
This ensures that there is a clustered location available to the First Storage Group for the SCC cluster.
For the purposes of this article I will take you through the GUI setup for Exchange in order to create an SCC cluster – therefore from your Exchange installation media double click on the “Setup.exe” file:
You will be presented with the welcome screen as per above – click on the “Install Microsoft Exchange Server 2007 SP1”
You will be presented with the Introduction screen above – click “Next”:
Agree to the licensing agreement and click on the “Next” button:
Choose a custom Exchange Server Installation and click “Next”:
Choose the “Active Clustered Mailbox Server Role” and then click on the "Next” button:
Choose the “Single Copy Cluster option” and then provide a unique NetBIOS name that the Cluster Mailbox Server will be known as – you will also need to provide the location of the clustered disk that you created in the very first step which will house the first storage group and Database – when you are done click next:
You will then be asked to provide the IP address that will be linked to the Clustered Mailbox Server name that you created in the previous step – you will not be able to create a second subnet as this is an SCC cluster – when you are done click “Next”:
Setup will not verify if the configuration that you have chosen is ok – when it is done click “Next”:
Setup will then install the SCC cluster – when setup is completed you are ready to to verify the configuration and then install the second node.
Installing Exchange 2007 Service Pack 1 on your Passive SCC Node:
The install process is almost exactly the same to that on the Active node – only you do not get asked for an IP address and NetBIOS name for the cluster – additionally on the Custom Installation options you need to ensure that you choose “Passive Clustered Mailbox Role” – see below:
So you now (should) have a fully functioning SCC cluster node with all of its Clustered Disks Presented via iSCSI. Now some of you might be thinking – where can I take this from here?
Well there are many scenarios and recommendations for iSCSI – but the key thing that strikes me is that with some clever co-operation work with your Network Guys you can in theory have iSCSI targets which as long as they are routable and comply with the correct I/O specifications for iSCSI with Exchange can be location independent – for example you could have a set of Database targets located in a separate Data Centre to the one which houses your TS logs – or indeed separate out your DB and Logs to many remote locations. Obviously that would require a lot of planning and investment – and I would argue that in that situation you should use CCR – but it is one idea.