February 22, 2017 at 7:35 am
Dear Friends,
I am working with a SQL Server 2008 Enterprise Edition in a cluster environment. We are moving our infrastructure from physical machines, to virtual machines.
Our virtual machines will not be using microsoft cluster architecture. I know that the first step, is to know the environment, I want to move my instance as is, to this new machine, when I said as is, I refer to the instance that resulted from the cluster service.
What would be the best tool to simulate this move, if it exist ?
I'm interested in your opinion and ideas
Thanks for your ideas
February 22, 2017 at 7:40 am
P2V should do the trick with vCenter Converter.
Your issue might be that you are taking an image of a cluster, and deploying it as standalone.
You could run it as a one node cluster, but personally I'd perform a clean install on a new VM guest and migrate.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This thing is addressing problems that dont exist. Its solution-ism at its worst. We are dumbing down machines that are inherently superior. - Gilfoyle
February 22, 2017 at 8:16 am
I suggest to build a new SQL instance in a VM. Next set the instance specific settings (like sys.configurations kind of stuff, but also LOGINs and server-level permissions) to the same as the current iron-environment. Finally copy the database from iron to VM with a back-up & restore method.
If you search the internet you'll find several T-SQL and PoSh scripts to automate the process of copying SQL instances.
February 22, 2017 at 8:20 am
removed this post
it was a remark that was already clearly mentioned in the original post :Whistling:
February 22, 2017 at 10:06 am
luismarinaray - Wednesday, February 22, 2017 7:35 AMDear Friends,I am working with a SQL Server 2008 Enterprise Edition in a cluster environment. We are moving our infrastructure from physical machines, to virtual machines.
Our virtual machines will not be using microsoft cluster architecture. I know that the first step, is to know the environment, I want to move my instance as is, to this new machine, when I said as is, I refer to the instance that resulted from the cluster service.
What would be the best tool to simulate this move, if it exist ?
I'm interested in your opinion and ideas
Thanks for your ideas
You cannot convert a clustered instance to a standalone instance, period!
And don't be tempted to restore the system databases from the clustered instance to a standalone server, either!
Build a new standalone server and migrate objects from the old instance to the new instance. At cutover you'll be able to use the same computername the clustered instance was assigned, but make sure you understand eactly how to achieve this!
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
February 22, 2017 at 1:13 pm
Thanks to all,
Could be a good idea to virtualize in the same vm, production, quality and development ? but in different instances, where could I find known good practices to manage this environments.
Again thanks
February 23, 2017 at 3:48 am
luismarinaray - Wednesday, February 22, 2017 1:13 PMCould be a good idea to virtualize in the same vm, production, quality and development ?
Not sure what you mean by this, could you explain
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
February 23, 2017 at 6:13 am
Dev, Test and Production SQL Server environments in the same VM but in different instances, if possible.
I could take the following strategies, going to virtual in my mind:
1.) If an physical SQL Server instance go to virtual, standalone instance, then do a P2V migration.
2.) If a "normal" SQL Server cluster instance go to virtual, then build a new VM with a new SQL Server instance and migrate to virtual one-by-one database.
3.) If an SQL Server cluster Mission Critical Application go to virtual, then migrate to a new VM step-by-step database, cutoff the instance name and rename the new instance name as the old Mission critical application SQL Server instance name.
I know that every option has its working details, just validating if it sounds logical to you.
Thanks Again, for your patience.
February 23, 2017 at 6:42 am
luismarinaray - Thursday, February 23, 2017 6:13 AMDev, Test and Production SQL Server environments in the same VM but in different instances, if possible.
I could take the following strategies, going to virtual in my mind:
1.) If an physical SQL Server instance go to virtual, standalone instance, then do a P2V migration.
2.) If a "normal" SQL Server cluster instance go to virtual, then build a new VM with a new SQL Server instance and migrate to virtual one-by-one database.
3.) If an SQL Server cluster Mission Critical Application go to virtual, then migrate to a new VM step-by-step database, cutoff the instance name and rename the new instance name as the old Mission critical application SQL Server instance name.
I know that every option has its working details, just validating if it sounds logical to you.
Thanks Again, for your patience.
Based on you feedback, P2V is the last thing you want to do.
Split out your environments immediately. Prod, Dev, Test should never be on the same VM. Can't even imagine the issues you had throughout it existing like this.
You need to develop a complete design of what sort of redundancy you need, VM, Instance, DB level.
What SQL version can you upgrade to? Which version of SQL provides the layer of HA you need?
Does your app support this version of SQL? If no, back to design.
This should drive/guide your high level decisions. of what kind of environment you are going to deploy for each.
Example:
Prod = you want HA on every possible layer
Dev & Test = not so much, standalone instances should suffice (in general)
Coordinate your design with your applications team, as they will definitely be involved in this change as you switch over/test your new environment.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This thing is addressing problems that dont exist. Its solution-ism at its worst. We are dumbing down machines that are inherently superior. - Gilfoyle
February 23, 2017 at 10:42 am
Good Points to have in mind,
Additionally, If i were using SSIS, Analysis Services and Reporting Services, but I'am consolidating servers, could be good candidates to place in the same VM of production, all this environments in one VM, tagged as Production, that also have production tasks, or should I apply to put in differents VM.
Thanks.
February 23, 2017 at 11:28 am
No, personally I would not put anything other than the DB Engine on my production DB Server.
Give SSAS, SSIS, SSRS their own servers.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This thing is addressing problems that dont exist. Its solution-ism at its worst. We are dumbing down machines that are inherently superior. - Gilfoyle
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply