Virtualising a DB server

BoomAM · 20 May 2011 at 09:30

Hi all,
Has anyone got any tips for virtualising a database server.
Im planning on doing a P2V conversion of our dangerously slow physical Db server onto a much faster virtual host.

Any tips beyond disk IOPs that i should be aware of?

Thanks in advance all.

AlexD · 20 May 2011 at 11:03

Hi,

Done this with a few old 2003 DB servers. Depending on whether your going to do an online or offline migration i'd suggest stopping the SQL service so no new data is written during the migration.

Also make sure the VM system has at least 2 VCPUs (assuming vmware here) presented to it.

BoomAM · 20 May 2011 at 15:22

AlexD said:
Hi,

Done this with a few old 2003 DB servers. Depending on whether your going to do an online or offline migration i'd suggest stopping the SQL service so no new data is written during the migration.

I'll probably do it offline over a weekend.

the_chicco said:
If possible do not P2V it. Create a new DB server and migrate the DB onto it.

Why?

Without looking at trending information its hard to tell. Why is it slow. Because it is being hammered or the hardware is old?

Old hardware, almost no resources free, too expensive to upgrade the hardware, etc;

Skidilliplop · 20 May 2011 at 15:42

If you're using VMware I'd use vCentre migration tool. It'll do the hard work for you and it's free.

Tips: if it's SQL point the DB and log drives to be placed in different data stores on the hypervisor (which should be on different SAN LUNs) to maximise your I/O performance.

Stop the SQL service before kicking off the conversion just to be safe. There is a setting in the tool to sync files that change during the conversion but given the nature of DBs I wouldn't take the chance. Make sure everyone's off the DB, shut it down then when it's all migrated fire it back up and you should be laughing.

Edit: also if it's in AD it's sometimes worth removing it from the domain first then re-enrolling it (provided that's not a complete ballache to do for the apps concerned). Conversions can and will screw about with SIDs and though it's usually not an issue if the physical box is to be binned, it's another preventative precaution.

BoomAM · 23 May 2011 at 09:18

the_chicco said:
P2V should always be used as a last resort,

Its not really all that feasible to move DB's off a server and create a new one.
Having to redo all the permissions, repoint database locations in apps, etc; is both a massive ball ache and in some scenarios, not even possible.

Right, so basically, as long as i stop the relevant services, everything should be hunky dory!

Skidilliplop · 23 May 2011 at 09:51

BoomAM said:
Its not really all that feasible to move DB's off a server and create a new one.
Having to redo all the permissions, repoint database locations in apps, etc; is both a massive ball ache and in some scenarios, not even possible.

Right, so basically, as long as i stop the relevant services, everything should be hunky dory!

Yep. And if not.....you still have the physical box left untouched which makes the backout plan a sinch

And you are indeed correct, moving DBs is a ball ache, especially with SQL 2008 because the groups and permissions are super anal compared to 2000/2005.
We moved one of our key DBs to 2008 recently, took bloody ages fiddling with permissions to get it working properly.
Infact still trying to implement an system upgrade as we speak where the vendor still won't support installing it on SQL 2008 - Probably because they CBA teaching their engineers how to migrate to 2008.

BoomAM · 23 May 2011 at 13:57

the_chicco said:
For the love of god don't get rid of the old box. Not at least until it is fully tested and has been in production for a while. I have a bit better insight than most on how P2V's actually work, I used to be an engineer for Platespin. We had major issues with Microsoft, specifically with AD, different variations of HAL's, etc. In any case try the P2V, if it works, great. But ensure you do full testing afterwards and you keep the box on standby just in case. A lot of my techie calls where from clients where we would P2V DC's, DB servers etc and issues became apartment a long time after it had actually happened.

Anyway good luck mate, hopefully it will be smooth sailing!

Always do, i always make sure i have a 'back out option' where i can.

Jobs a good'en then! Will give this a go in the coming weeks.

Thanks for the input everyone.

BoomAM · 5 Jun 2011 at 21:03

As an update:
Job done!

Went suprisingly smoothly.
3 hours to do the entire thing, and works sweet as a nut thus far! :eek:

Can start monitoring performance come Monday afternoon when all the DB's get hammered, see what's limiting it if anything.

Thanks for the input everyone.

steinooo · 5 Jun 2011 at 21:18

the_chicco said:
P2V should always be used as a last resort, i.e if you have a stubborn app you cannot virtualise or if you have that many servers time constraints dictate that you need to get them up and running quickly. Something as critical as a DB server, or a DC as another example, should be done fresh if possible. Sometimes during a P2V the creation process will inject specific drivers that may cause performance issues vs if building it from scratch. I used to a lot of P2V's when I was a consultant, probably over 3000 to date, and we used to have a lot of issues with core boxes such as AD, Exchange and SQL. Sometimes we could not always pinpoint the issue but the common trait was that they were P2V'ed.

whoa, this post has made me think about P2Ving big time.

Trojan · 6 Jun 2011 at 00:11

As long as a P2V is carried out correctly and sufficient post virtualisation remediation occurs, then you're extremely unlikely to encounter any problems. Unless the application is inherently unsuited to virtual platforms of course.

Skidilliplop · 6 Jun 2011 at 11:17

Trojan said:
As long as a P2V is carried out correctly and sufficient post virtualisation remediation occurs, then you're extremely unlikely to encounter any problems. Unless the application is inherently unsuited to virtual platforms of course.

I have one of those. An app that's CPU usage tends towards 100% because of the way it polls. Still virtualised it anyway

Resource pools for the win!

BoomAM · 6 Jun 2011 at 18:42

the_chicco said:
Glad it went OK!

Suprised me how well it went.
Couldnt be bothered waiting a few days for it to do almost a tera's worth of drives, so i gave it a go with resizing down to what it should be instead, went really quick, end of day one of DB usage, not a single issue. :cool: