Dave, I've done a bunch of these and they are actually better than the Autostart clusters. The basic gist is to setup the target cluster "as close to exactly the same as the source as possible."
Assuming you already have a source cluster:
1. Create the target cluster. (This is usually a single node cluster) This will be a completely separate cluster from the source. 2. Install Exchange. 3. Create Exchange Cluster group with only the disks. (Needs to be same drive letters as production) 4. Bring disks online and replicate the data from source to Target. 5. Take cluster group on production server offline (including the specs) 6. Create the network name and IP resources in the cluster group on the target. (The name MUST be exactly the same as on the source. IP will be different.) 7. Add the System Attendant cluster resource. (This will complete the Exchange install. When Exchange is clustered, it will go to Active Directory first to see if the exchange server exists. If it does, it will perform a disaster recovery install which just puts the binaries in place. 8. When that is completed, you should have a cluster group that is identical to the production cluster group with the exception of the Virtual IP address. Also, if you configure the network name to update DNS then that will be taken care of for you as well.
The only issue here is that there is an IP address in the Default SMTP Virtual server that you can access from either IIS or ESM. This info is actually stored in AD but can be change via script. Personally, I've always just instructed the client to change it manually.
So, to start exchange on the target server now, all you have to do is bring the cluster group online just like you would on the source server. DNS cache on the client PC's will take 5 minutes or so to timeout or you can do an ipconfig /flushdns or just tell them to reboot. After the client has the proper DNS cached info, all should work. This goes for any front end servers as well. They will all need to have their cache flushed. Personally I script this using psexec from sysinternals.
That should atleast give you enough information to go on, if you haven't figured it out already.
Personally, I don't create cluster resources for Replistor on the target. I don't like anything to replicate back to production automatically. I keep it all manual. Besides, if you failover it should be because your source system isn't available yet. Why would you want to replicate back to it right away?
There are some really old docs on PowerLink for this solution.
It is very possible and I have seen a lot of solutions working for this configuration.
Thereis not much different than replicating data from the Source MSCS to the Target MSCS. - The Spec's will be defined to replciate data from the Source shared disk to a Target shared disk. - RepliStor resources can be inculdede in the MSCS to accommodate for failover. This can be done on the Source and Targets.
Ryan9
45 Posts
0
July 30th, 2007 13:00
Assuming you already have a source cluster:
1. Create the target cluster. (This is usually a single node cluster) This will be a completely separate cluster from the source.
2. Install Exchange.
3. Create Exchange Cluster group with only the disks. (Needs to be same drive letters as production)
4. Bring disks online and replicate the data from source to Target.
5. Take cluster group on production server offline (including the specs)
6. Create the network name and IP resources in the cluster group on the target. (The name MUST be exactly the same as on the source. IP will be different.)
7. Add the System Attendant cluster resource. (This will complete the Exchange install. When Exchange is clustered, it will go to Active Directory first to see if the exchange server exists. If it does, it will perform a disaster recovery install which just puts the binaries in place.
8. When that is completed, you should have a cluster group that is identical to the production cluster group with the exception of the Virtual IP address. Also, if you configure the network name to update DNS then that will be taken care of for you as well.
The only issue here is that there is an IP address in the Default SMTP Virtual server that you can access from either IIS or ESM. This info is actually stored in AD but can be change via script. Personally, I've always just instructed the client to change it manually.
So, to start exchange on the target server now, all you have to do is bring the cluster group online just like you would on the source server. DNS cache on the client PC's will take 5 minutes or so to timeout or you can do an ipconfig /flushdns or just tell them to reboot. After the client has the proper DNS cached info, all should work. This goes for any front end servers as well. They will all need to have their cache flushed. Personally I script this using psexec from sysinternals.
That should atleast give you enough information to go on, if you haven't figured it out already.
Personally, I don't create cluster resources for Replistor on the target. I don't like anything to replicate back to production automatically. I keep it all manual. Besides, if you failover it should be because your source system isn't available yet. Why would you want to replicate back to it right away?
Hope that helps.
dramjass
151 Posts
0
July 30th, 2007 13:00
It is very possible and I have seen a lot of solutions working for this configuration.
Thereis not much different than replicating data from the Source MSCS to the Target MSCS.
- The Spec's will be defined to replciate data from the Source shared disk to a Target shared disk.
- RepliStor resources can be inculdede in the MSCS to accommodate for failover. This can be done on the Source and Targets.