April 29, 2015 at 9:43 am
Hi all,
I am in the inital stages of planning my upgrade to 2014.
I have a 2 node windows 2008R2 cluster with 3 instances of SQL2008R2 standard (1 named instance production and 1 default production, 1 named test)
I want to plan the upgrade to sql2014 with a windows 2012 R2 cluster.
I have started reading some upgrade documents to plan the upgrade, and am starting to form a plan:
- setup new windows 2012 cluster
- install an initial sql 2014 test clustered instance
- test a migration by scripting logins, jobs, security, ssis etc. then backup-restore or detach-copy-attach or user dbs.
- setup future production instances (default, and 1 named)
- test migration of production instances without golive.
I want to keep the same network names and instance names so I can have a seemless transition and not have to go the DNS redirect or change all connection strings route.
What I am not certain about yet is how to accomplish this.
Can I use the same instance name and a default instance in the new cluster, and then on golive day, remove the network name from the old failover groups and then rename/ add the network name to the new failover groups?
The reason I am asking is that I read in one of the MS documents that named instances have to be unique in the domain, which I was surprised to see. I know you can have the same instance name on different servers, and I do not understand why this would not be the case in a failover cluster.
From sqlserver 2014 upgrade technical guide
With clusters, even the instance name must be unique in the domain since it is not the same as the name for the underlying WSFC cluster or any of the nodes. If the old clustered instance was a default instance named MYSQLINS, you could not reuse that name when configuring the new cluster. You can rename a clustered instance only after the old server has been decommissioned; however, you can only rename the portion of a clustered instance that exists in Active Directory. So a named instance cannot be fully renamed because the part after the slash cannot be renamed. For example, assume you have a named instance of MYINS\INSNAME. MYINS can be renamed but INSNAME cannot.
Can someone tell me if the above is true or not? and if the following is doable (as mentionned above)
On the new cluster :
- Create 1 default instance
- create 1 named instance with the same instance name as on the production cluster
- do the side by side migration of each instance ( script logins and all the rest, backup-restore)
- once the new instances are tested and verified properly, remove or rename network name on production system
- add network name removed above (rename) to the 2 new production instances.
Thanks and best wishes.
April 29, 2015 at 10:25 am
Andre Carrier (4/29/2015)
- setup new windows 2012 cluster- install an initial sql 2014 test clustered instance
- test a migration by scripting logins, jobs, security, ssis etc. then backup-restore or detach-copy-attach or user dbs.
- setup future production instances (default, and 1 named)
- test migration of production instances without golive.
Sounds good so far.
Andre Carrier (4/29/2015)
I want to keep the same network names and instance names so I can have a seemless transition and not have to go the DNS redirect or change all connection strings route.What I am not certain about yet is how to accomplish this.
This is possible
Andre Carrier (4/29/2015)
Can I use the same instance name and a default instance in the new cluster, and then on golive day, remove the network name from the old failover groups and then rename/ add the network name to the new failover groups?
No, the name may only be used once at anytime.
When you deploy the new clustered instances you'll use the same instance names you have already, for the Virtual network names you'll need to use unique names. They could easily be
NEWINST1
NEWINST2
NEWINST3
So, your new clustered instances will be
NEWINST1\prodinstname
NEWINST2
NEWINST3\testinstname
This will allow you to bring the instances online and move objects across. On the go live day the current system would be shut down and in each of the new clustered roles you would select the networkname and change it to the appropriate old name, does this make sense?
This details how to rename a virtual server for sql server
https://msdn.microsoft.com/en-us/library/ms178083.aspx
Andre Carrier (4/29/2015)
The reason I am asking is that I read in one of the MS documents that named instances have to be unique in the domain, which I was surprised to see.
No, computernames have to be unique in the domain, since a virtual network name is a computer name they too must be unique.
Andre Carrier (4/29/2015)
I know you can have the same instance name on different servers, and I do not understand why this would not be the case in a failover cluster.
The actual instance name is unique within the cluster not the domain. So, 3 instances named
TEST
PROD
PRE
are unique. You'd have 3 clustered instances in your windows server failover cluster called
NEWINST1\TEST
NEWINST2\PROD
NEWINST3\PRE
You couldn't have this in the same cluster
NEWINST1\TEST
NEWINST2\PROD
NEWINST3\TEST
You couldn't have this in the same domain
NEWINST1\TEST
NEWINST1\PROD
NEWINST3\PRE
Andre Carrier (4/29/2015)
From sqlserver 2014 upgrade technical guideWith clusters, even the instance name must be unique in the domain since it is not the same as the name for the underlying WSFC cluster or any of the nodes. If the old clustered instance was a default instance named MYSQLINS, you could not reuse that name when configuring the new cluster. You can rename a clustered instance only after the old server has been decommissioned; however, you can only rename the portion of a clustered instance that exists in Active Directory. So a named instance cannot be fully renamed because the part after the slash cannot be renamed. For example, assume you have a named instance of MYINS\INSNAME. MYINS can be renamed but INSNAME cannot.
Can someone tell me if the above is true or not? and if the following is doable (as mentionned above)
Slightly confusing, they maybe mean Servername, in SQL server this would be the Servername
NEWINST1\TEST
This is made up of the networkname NEWINST1 and the instancename TEST
Andre Carrier (4/29/2015)
On the new cluster :- Create 1 default instance
- create 1 named instance with the same instance name as on the production cluster
- do the side by side migration of each instance ( script logins and all the rest, backup-restore)
- once the new instances are tested and verified properly, remove or rename network name on production system
- add network name removed above (rename) to the 2 new production instances.
Thanks and best wishes.
Yes, the new instances will initially need different networknames but you can change them later 😉
Please please check my stairway series on this site starting at this link[/url]
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
April 29, 2015 at 11:29 am
If your end goal is, only, to have a seamless roll-over for applications or processes trying to use the old connection string, then you can make this easier with DNS. Stand up your 2014 cluster with new names and, after shutting down the old cluster, create DNS aliases pointing to the new cluster. Your processes will be happy and you won't need to mess with network name uniqueness or renaming.
After that, if you ever decide to discontinue the old name, you can modify your connection strings and simply disable / enable the DNS to test that you found everything. I might also recommend always connecting to a DNS aliases, when possible, so that you can do migrations and upgrades without ever worrying about the server / cluster names.
Derik Hammer
@SQLHammer
www.sqlhammer.com
April 29, 2015 at 11:33 am
Hi,
I think that clears it up, excellent detailed answer thank you.
I knew of course network names are unique in a domain and networkname\instance name combination must also be unique.
The way they phrased the paragraph got me confused a bit.
The reply confirmed that the best route in my case is to use a new network name for each new failover instance using the same instance names as in the production cluster. Then on golive, remove the network names from the old cluster and rename the new instance network names to what the old instances were using.
If you don't mind, the migration part about scripting the system stuff: is it the best way to proceed ? I have not yet hammered out the details but this is what I am thinking of doing.
- script out the logins to keep same sids
- script out jobs, linked servers
- setup security for ssis, credential and others
- export import ssis packages.
- many other things I have not thought about yet 🙂
I believe this is a cleaner way as you start with a clean slate, but not sure.
Is this the best way or is there a smarter or more efficient method for doing the system part of the migration?
I will read your articles as suggested, thanks!
April 29, 2015 at 11:38 am
Very good point SQLHammer!
So in the long run, there would never be an issue using DNS aliases permanently?
Basically using them forever is a good way to go? You would indeed never worry about the actual network names of the failover groups.
April 29, 2015 at 12:47 pm
I worked in a custom development shop for a few years and we, almost, never used a server name for anything. It was amazing to be able to create, let us say, a DataWarehouse DNS and then move it wherever we felt. In the DW example, I personally migrated it to 4 different clusters in my time there and I never had to worry about connections breaking.
I do believe that using DNS aliases permanently is a good practice. I find that the challenge with DNS aliases only comes if you allow them to grow too numerous. In the case of this migration, if you were to move the cluster 4 times, you'd end up with 4 DNS aliases all pointing to one server in order to maintain all of the possible connections to the previous server name. That is why I advocate creating a purpose related DNS name with a standardized naming convention. This way, if your server houses databases for 6 different applications, it will have 6 DNS aliases but that will never grow. As you migrate things around the server names simply die with the hardware.
In your case, I would do the move with the old server name as a DNS alias and then make sure to set time aside for discontinuing that name and updating connection strings to a name that is abstracted away from the hardware.
Derik Hammer
@SQLHammer
www.sqlhammer.com
April 29, 2015 at 12:56 pm
I think you are 100% correct to use DNS aliases.
The names I use in the current cluster are already named independently of servers. The 3 sql cluster failover group network names I use are
PROCESSSQL, BUSINESSSQL, TESTSQL. So in my migration if I turn these into DNS aliases, I will be fine long term I think.
I will definitely go that route for the upgrade.
Thanks!
April 30, 2015 at 6:56 am
Andre Carrier (4/29/2015)
If you don't mind, the migration part about scripting the system stuff: is it the best way to proceed ? I have not yet hammered out the details but this is what I am thinking of doing.- script out the logins to keep same sids
- script out jobs, linked servers
- setup security for ssis, credential and others
- export import ssis packages.
- many other things I have not thought about yet 🙂
Looks good
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply