Very soon, in the very near future, I shall be embarking upon the building of our latest database utility SQL 2008 Cluster. Hopefully, I will get the time to document bits as I go because it should be rather special if it is anything like previous SQL 2005 clusters that I have been involved in installing.
Let me explain. So you have just installed a SQL cluster and you are now wondering about how on earth you are going to provide disaster recovery. There are many options open to you, but you decide that you still want your DR solution to be clustered AND you don’t want the SQL instance names to change once fail-over has been initiated. Secondly, you wonder about how you are going to ship the databases across to the secondary cluster, thinking about mirroring, replication and shipping technologies. All of these technologies have problems and there are implications with each and in addition you want all hardware to be utilized and not sitting idle.
The solution that I have put in and will been soon to be repeating will involve two physically separate Windows SQL Clusters each using SAN-based disk mirroring, with the ability for either cluster to take ownership and run every SQL instance in existence between the two clusters.
The way this is achieved is by fooling each cluster to believe it has each and every SQL instance installed to it and this works very well because of the nature and workings of the virtual clustered instances. Effectively only the virtual clustered instance/s that have visible SAN disk resources will be able to be on-lined, and of course only the SAN disk resources that are source disks for the mirroring will be visible -so it all works seamlessly. When I come to do this again I will try to get this documented and explained in more detail.