May 13, 2015 at 3:23 pm
I need guidance, link, or high level guidance from the community.
So, today we have the following:
Dallas: A 2 node Windows 2008 Cluster running SQL 2012 ENT cluster
Wash: A 2 node Windows 2008 Cluster running SQL 2012 ENT cluster
and I'm mirroring (synchronous, no witness) a database from Dallas to Wash.
Crappy set up. I know.
Now customer wants to have the database mirror to another server in Dallas.
What are the high level steps to transform my two clusters to use Availability Groups and Always On?
Do I need to basically start over and build a new environment?
or can I transform my two disconnected cluster?
Thank you for your help.
Miguel
May 13, 2015 at 9:55 pm
A couple of things to remember on availability groups. These groups are cluster resources themselves, and thus each server must belong to the same cluster (remote servers are allowed).
Since you already have this listed as two clusters of 2 servers (each cluster in its own location), I am assuming that they are not part of the same cluster group, which means you would indeed need to start over to get onto AlwaysOn avability groups.
There are a couple of things I learned that do need to be considered is the way you are going to need to configure things. When I created the AG (Availability Group), I created it this way, 2 servers in one location connected to one server in the remote location. My reasoning was the one in the remote location was to work as the DR server in case of failure of the primary servers hosting location. Then, I made the secondary site server part of the availability group, but did not make it auto-failover eligible. The concept of this design had more to do with the applications that connect to DR purposefully than the limitations of the failover group itself. What I discovered later is that due to latency between the data centers, it was possible that the remote server ran a few seconds behind, and in the case of a failure of both servers, still was not eligible to be failed over to manually as it knew there was a possible loss of data. Since I was just doing a DR test, I accepted the loss of data and wrote it down to the cost of having to fail to DR.
That all being said, setting up an availability group is not too difficult - and comes with just a few steps. First you need all of the servers in the AG to be listed as part of the cluster. Now comes the less intuitive part, when installing, you are installing separate installs of SQL Server, not using the cluster installation. This also means a few carry on effects, such as the disks are not cluster managed resources, but instead have to be configured at the OS level on each server. There is no requirement for like servers (in any way but the version of SQL), and you can go back to using local disks if desired. That of course means that in a 3 server availability group, if the db that you are configuring as part of the group are 2GB, it will take up 2GB on each server, so be prepared for much more disk space usage. Once you have installed SQL on each of the servers, you then create/restore the DB onto one server. Then you can either run through the AG wizard, and add the database(s) you wish to have part of this group, or run the TSQL commands manually. You will be presented options on whether you want the copy to be read only (for reporting) or failover eligible. That design is pretty much up to you. Once you run through the wizard or run the TSQL commands to create the AG and add databases to it, and run the required pieces on the other servers, you can go back into cluster administration, and you will see the Availability group there. That is where the magic piece really happens.
The last part is the most important, name your availability group something meaningful, as you will be using this as the server name portion when you attempt to connect to the AG from the applications that need to fail over. Keep in mind that you can always login to SQL on any node of an AG, but that depending on how you set it up you may or may not be able to query the inactive node.
Not sure how much all of this helps, but I figured I would at least give you the steps from the SQL Side. I think you may need to get your networking group to assist with the clustering configuration, as there are some special things that they need to do to enable multiple location clustering. I could help with those too, but since this is a SQL board, I am limiting my input to just SQL Server.
Tim Blum
Senior Manager, Outsourced Data Services
Learn2Live at Ureach.com
May 14, 2015 at 4:27 am
MiguelSQL (5/13/2015)
I need guidance, link, or high level guidance from the community.So, today we have the following:
Dallas: A 2 node Windows 2008 Cluster running SQL 2012 ENT cluster
Wash: A 2 node Windows 2008 Cluster running SQL 2012 ENT cluster
and I'm mirroring (synchronous, no witness) a database from Dallas to Wash.
Crappy set up. I know.
Now customer wants to have the database mirror to another server in Dallas.
What are the high level steps to transform my two clusters to use Availability Groups and Always On?
Do I need to basically start over and build a new environment?
or can I transform my two disconnected cluster?
Thank you for your help.
Miguel
See this link for more info
https://msdn.microsoft.com/en-us/library/hh923056.aspx
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
May 14, 2015 at 7:30 am
Thank you so much Learn2Live. Your high level steps are great
And Perry Whittle... oh oh oh.... that's paper.. great find.
That's exactly what I needed
My biggest question as... can we somehow join the two clusters?
3. You will need to completely remove the existing FCI2 because the underlying WSFC cluster must be destroyed in order for the nodes to be joined to the WSFC cluster for FCI1. It may be more efficient to completely reinstall Windows.
mmm no.
Miguel
May 14, 2015 at 8:58 am
MiguelSQL (5/14/2015)
Thank you so much Learn2Live. Your high level steps are greatAnd Perry Whittle... oh oh oh.... that's paper.. great find.
That's exactly what I needed
My biggest question as... can we somehow join the two clusters?
3. You will need to completely remove the existing FCI2 because the underlying WSFC cluster must be destroyed in order for the nodes to be joined to the WSFC cluster for FCI1. It may be more efficient to completely reinstall Windows.
mmm no.
Miguel
You'll have to sacrifice one cluster, I.e. destroy it and merge the nodes into the remaining cluster.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply