January 20, 2017 at 5:15 am
Hi,
We are going to migrate our two node AO cluster to some new hardware in the coming weeks. And we are looking at a couple of options when doing this.
1. Create a new cluster and AO group and do a restore to the brand new cluster.
2. Adding the new hardware as new nodes in the existing cluster and make the new nodes Primary and remove the old nodes.
Option 1. is recommended from our software supplier but due to the database being 5TB we can expect a significant downtime, which the company might not approve.
Does anyone have any experience with option 2? This is the easiest solution and will not require any significant downtime. But our SW supplier is concered about dropping the old nodes will cause some problems for us down the line.
Any feedback would be appriciated! Thank you 🙂
January 22, 2017 at 3:11 am
Option 2 is perfectly feasible, I'm interested to know what implications your vendor feels you may have by removing the old nodes
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
January 22, 2017 at 2:19 pm
Unless the applications the AO cluster support are not pointing to an AG listener why would the vendor think that supporting option 2 would cause problems? Install SQL, add the nodes to the cluster, add the replicas to the AG, then do a failover when ready. Are the new servers going to be located particularly far away where transferring the data is problematic?
Option 2 is pretty tried and true by this point. And with updates to WSFC and AlwaysOn it is good for other migrations too, like OS or SQL upgrades.
Joie Andrew
"Since 1982"
January 23, 2017 at 1:33 am
Thanks for the reply guys.
I think the only reason they don't recommend it is due to the fact that they have never done it themselves and therefor cannot support it. Their DBA consultants fear that when we remove the nodes there might be some *ghost* configuration left behind causing trouble in the production.
The application using the cluster is Dynamics Navi and is connecting through the AG, so the compatibility is no issue.
If it has been done before without implications, I don't see a reason not to do option 2. When it clearly is the best option.
January 23, 2017 at 5:47 am
otm - Monday, January 23, 2017 1:33 AM😀
Thanks for the reply guys.
I think the only reason they don't recommend it is due to the fact that they have never done it themselves and therefor cannot support it. Their DBA consultants fear that when we remove the nodes there might be some *ghost* configuration left behind causing trouble in the production.
The application using the cluster is Dynamics Navi and is connecting through the AG, so the compatibility is no issue.If it has been done before without implications, I don't see a reason not to do option 2. When it clearly is the best option.
They're making an awful number of assumptions.
Ghost configuration? :w00t:
Adding and removing nodes from a Windows Server Failover Cluster has no implications on configuration going forward.
They may want to check out my Stairway to HA on this site, please feel free to forward them the link
The only time a new cluster will be required is if the cluster nodes are Windows 2012 R2 or lower OS version and the new nodes to join will run a higher level OS.
Up to Windows 2012 R2, all nodes must be the same OS version.
With Windows 2016 you can join these nodes to an existing lower level cluster but the cluster must be Windows 2012 R2.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
January 23, 2017 at 6:26 am
The only time a new cluster will be required is if the cluster nodes are Windows 2012 R2 or lower OS version and the new nodes to join will run a higher level OS.
Up to Windows 2012 R2, all nodes must be the same OS version.
With Windows 2016 you can join these nodes to an existing lower level cluster but the cluster must be Windows 2012 R2.
Is that true though? I thought with the release of Windows Server 2012 you could add nodes of a higher OS version (2012 R2 at the time the feature got implemented) to a pre-existing lower-level cluster (2012) to enable a rolling upgrade of the Windows cluster?
Cross-cluster Migration of AlwaysOn Availability Groups - Microsoft
http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=0ahUKEwihxs-ArtjRAhWHuhQKHTIDBdQQFggkMAE&url=http%3A%2F%2Fdownload.microsoft.com%2Fdownload%2FD%2F2%2F0%2FD20E1C5F-72EA-4505-9F26-FEF9550EFD44%2FAlwaysOn%2520AG%2520OS%2520Upgrade.docx&usg=AFQjCNHypbNj2AI2H2vraQnXHkuVIuejWw&sig2=4Cm7IdNBG9fkcZ7tszVKJg&bvm=bv.144686652,d.bGg
Please forgive the Google-link. Couldn't find and did not have time to find the reference directly from MS's download site.
Joie Andrew
"Since 1982"
January 23, 2017 at 7:41 am
Joie Andrew - Monday, January 23, 2017 6:26 AMThe only time a new cluster will be required is if the cluster nodes are Windows 2012 R2 or lower OS version and the new nodes to join will run a higher level OS.
Up to Windows 2012 R2, all nodes must be the same OS version.
With Windows 2016 you can join these nodes to an existing lower level cluster but the cluster must be Windows 2012 R2.Is that true though? I thought with the release of Windows Server 2012 you could add nodes of a higher OS version (2012 R2 at the time the feature got implemented) to a pre-existing lower-level cluster (2012) to enable a rolling upgrade of the Windows cluster?
Cross-cluster Migration of AlwaysOn Availability Groups - Microsoft
http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=0ahUKEwihxs-ArtjRAhWHuhQKHTIDBdQQFggkMAE&url=http%3A%2F%2Fdownload.microsoft.com%2Fdownload%2FD%2F2%2F0%2FD20E1C5F-72EA-4505-9F26-FEF9550EFD44%2FAlwaysOn%2520AG%2520OS%2520Upgrade.docx&usg=AFQjCNHypbNj2AI2H2vraQnXHkuVIuejWw&sig2=4Cm7IdNBG9fkcZ7tszVKJg&bvm=bv.144686652,d.bGgPlease forgive the Google-link. Couldn't find and did not have time to find the reference directly from MS's download site.
For option 2, yes it is?
Even the doc at the link you posted in it's header states "Windows Server Failover Clustering does not support OS rolling upgrades".
Windows 2016 is the first OS to do this and the source WSFC must be at 2012 R2.
The doc details a cross cluster migration which is one way of upgrading the OS on the nodes, but requires 2 operational clusters, fine if you have the hardware available.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
January 23, 2017 at 7:58 am
Ah, you are correct. I remember doing this last year, but could not remember the differences in the specifics of it. Makes sense. Still, a really good use case for AGs though, because it can make your migrations easier even if you cannot support rolling upgrades of the original cluster.
Thanks Perry!
Joie Andrew
"Since 1982"
January 23, 2017 at 8:32 am
works ok for AGs in general but remember WSFC'c emcompass so much more.
Rubbish if you have an FCI running for instance
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
January 24, 2017 at 12:47 am
Thank you again for the feedback on this.
Fortunately we are running 2012 R2 so we should be able to join them with the new 2016 servers.
Can't wait to put the new beasts into action, 40TB SSD Raid10 with 2TB Memory and 4x4 CPU 😀
January 24, 2017 at 3:37 am
otm - Tuesday, January 24, 2017 12:47 AMThank you again for the feedback on this.Fortunately we are running 2012 R2 so we should be able to join them with the new 2016 servers.
Can't wait to put the new beasts into action, 40TB SSD Raid10 with 2TB Memory and 4x4 CPU 😀
In this case the rolling cluster upgrade makes sense.
Once all nodes have been upgraded, be sure to upgrade the cluster functional level to 2016
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply