 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
SQL Server Forum / Other Technologies / Clustering / May 2008Replace hardware with other architecture (IA64 -> X64)
I have a 2 node SQL2K5 SP2 (build 3042) cluster with 1 instance running on W2K3 SP2 ia64. We are going to replace the hardware and the new will be running W2K3 SP2 x64. Clustername, DTC name and the host names will be new. I will keep the virtual server name and IP address for the sql instance. I will also install SQL2K5 x64 with the same paths as I had on ia64. My question is if I will be able to reuse master and msdb databases? That's because I'll have to script a lot of logins and jobs otherwise, and that means longer downtime for the system. I've done this scenario when changing hardware with the same architecture, but here it's as said from intel itanium to intel x64. /Peter Hi again! I suppose since there is no response no one has done this from IA64 to X64. Anyone done it from X86 to X64 or vice versa? If so, any experience to share? I have decided to export my logins from master and jobs from msdb so I can import it in the new instance. Then I'll attach the user databases. /Peter >I have a 2 node SQL2K5 SP2 (build 3042) cluster with 1 instance >running on W2K3 SP2 ia64. [quoted text clipped - 16 lines] > >/Peter Sorry for the lapse. Moving master and msdb across architectures is NOT supported or recommended. You can pre-move the jobs before the final migration. Logins can be moved easily using this KB article: How to transfer logins and passwords between instances of SQL Server http://support.microsoft.com/kb/246133/en-us  SignatureGeoff N. Hiten Senior SQL Infrastructure Consultant Microsoft SQL Server MVP > Hi again! > [quoted text clipped - 28 lines] >> >>/Peter No problem. New queestions! I thougth it would be unsupported, that's the reason for the original post. Where is it documented that it's not suppoprted? I'll only found it in unoffiical documents. I intend to use sp_help_revlogin for logins. But I don't get what you mean by pre-move jobs. As the new instance will have the same virtual server name as the old one I can't have them running at the same time. That's why I'll script the jobs aswell. The name is importent, since it's more than 3000 winxp pointing to it. /Peter >Sorry for the lapse. Moving master and msdb across architectures is NOT >supported or recommended. [quoted text clipped - 4 lines] >How to transfer logins and passwords between instances of SQL Server >http://support.microsoft.com/kb/246133/en-us You can't use the same virtual server name. Active Directory won't let you. You can create a new virtual server name and use DNS to redirect the old name to the new location. Unless your clients are pointing to the old cluster via IP address, this works just fine. Go ahead and script the jobs and set them up on the new server. Set them to disabled. Write a script to enable them when you go live. The idea is ti have as minimal downtime as possible and to have everythign completely scripted so all you are doing is executing scripts, not clicking GUI screens. SignatureGeoff N. Hiten Senior SQL Infrastructure Consultant Microsoft SQL Server MVP > No problem. New queestions! > [quoted text clipped - 18 lines] >>How to transfer logins and passwords between instances of SQL Server >>http://support.microsoft.com/kb/246133/en-us I disagree, I've done this and reused the virtual server name with other cluster, latest in the same AD just a month ago. The differens is that the new server architecture hardware was identical with the old one. Now I'm changing hardware architecture. What do you mean the AD would deny? /Peter >You can't use the same virtual server name. Active Directory won't let you. >You can create a new virtual server name and use DNS to redirect the old [quoted text clipped - 6 lines] >scripted so all you are doing is executing scripts, not clicking GUI >screens. You should not be able to create a virtual server name that is the same as the existing virtual server name. AD gets confused as to who you mean and DNS really gets out of whack. SignatureGeoff N. Hiten Senior SQL Infrastructure Consultant Microsoft SQL Server MVP >I disagree, I've done this and reused the virtual server name with > other cluster, latest in the same AD just a month ago. The differens [quoted text clipped - 17 lines] >>scripted so all you are doing is executing scripts, not clicking GUI >>screens. Sorry, Geoff but I really don't get what you mean. As I sad, I've done this. There could be issues reffering to AD/DNS depending on if the netbiosname for the virtual server is an object i AD or not. Maybe I've been a little short on info for you. Here is the timeline: The origninal virtual server (call it VS1) is running on it's present hardware (called OS1 and OS2). There is two more groups in the mscs, the cluster itself (called C1) and dtc (called D1). Install 2 new servers with new name (NS1 and NS2). Create a new cluster (C2) Create a new msdtc (D2). Verify that the ckuster is working. Then comes the part where it's time to change who is hosting VS1. Create login output by running sp_help_revlogin and job output by scripting out the jobs you need to move. Take down the virtual server cluster (VS1) resources, exept disk. That will free the netbiosname and ipaddress. Install a virtual server on cluster C2 with the name VS1. This is no problem with the steps above done. When this install is done with servicepack and pathes we have a running virtual server in the cluster C2 with the name VS1. After verification that VS1 can run om both new clusternodes it's time for user data. Here I'll script in the logins created by sp_help_revlogin, and script in the jobs to msdb. Then I'll copy the userdatabases (or change the zoning in our SAN). Then attach, and we are up and running. time for user verfication. /Peter >You should not be able to create a virtual server name that is the same as >the existing virtual server name. AD gets confused as to who you mean and >DNS really gets out of whack. >I disagree, I've done this and reused the virtual server name with > other cluster, latest in the same AD just a month ago. The differens [quoted text clipped - 20 lines] >>scripted so all you are doing is executing scripts, not clicking GUI >>screens. OK. I see what you are doing. That process will work. Most folks try and run BOTH virtual servers at the same time to do the data synch. That won't work for reasons you have undoubtably discovered. Again, I usually simplify the process using DNS records to point the old name to the new server. This is especially easy if the name is already abstracted via DNS to begin with. This has the advantage of allowing me to have both servers up and running. I can keep my cutover downtime to 15-30 minutes this way with the right setup. SignatureGeoff N. Hiten Senior SQL Infrastructure Consultant Microsoft SQL Server MVP > Sorry, Geoff but I really don't get what you mean. As I sad, I've done > this. There could be issues reffering to AD/DNS depending on if the [quoted text clipped - 64 lines] >>>scripted so all you are doing is executing scripts, not clicking GUI >>>screens. First, thanks for your wellwritten replys. I agree, it would be perfect to have both the new and the old one up at the same time. In this case I talked to the application vendor and they have problems see this be done at all. They more or less said that "we don't support it if you change VS name". About my earlier question, can you point me to a Microsoft article/document that said it's not supported to move systemdatabases (between architecture)? I can't find it! I >OK. I see what you are doing. That process will work. > [quoted text clipped - 6 lines] >have both servers up and running. I can keep my cutover downtime to 15-30 >minutes this way with the right setup. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.