P2V issue for HUGE CRM server

[Dave-Departed]

Hi All,

I've posted this on Spiceworks too, just in case... However I do feel it relevant, considering my imagined use of Veeam as part of the solution!!

I've got a requirement to P2V our Sage CRM system, which comprises of 2 boxes (web and database servers). I know they work after P2V, as I've done this successfully several times as a test. However, I am now having to start thinking very creatively, due to the way in which we want to host these CRM VMs in production.

Here's where I'll try my best to explain the setup...

Our web server is around 160GB in total size. No problem there.

Our database server has 1TB of local storage on it, with the majority being taken up by an 800GB partition called DATA, where the actual SQL databases themselves reside. Now, here's the gotcha... When these servers were setup (before my time), it seems that the company didn't buy the SQL module for BackupExec, so the transaction logs can't be flushed automatically by the daily tape backup. To this end, there is a SQL maintenance plan that runs daily for all databases, and this maintenance plan goes to... Yep, you guessed it... The DATA partition! Now, the actual databases are only about 36GB in total, but the backups produced by the maintenance plan, if left unchecked, will fill up the rest of that 800GB (right now I can see they're taking up 500GB). This means that, when it comes to a P2V, I have to take all that extra data with me (once they are VMs, they will be backed up by Veeam and therefore won't need the SQL maintenance plan).

When originally testing the P2V, we had a nice, beefy Dell box with 1.6TB worth of RAID10 15k local storage. This was configured as an ESXi host, and when running the P2V onto the local datastore of this host, even taking the extra useless SQL backup data, the process only took about 5hrs total. Very nice for testing. I also successfully got rid of the crap by creating a new vDisk on the VM, of about 50GB, then stopping all CRM-related services, and moving the database files onto this new disk, then removing the old 800GB disk and giving the new 50GB disk the same drive letter as its predecessor, then deleting the maintenance plan from SQL. CRM works fine and is none the wiser.

Now, what we want to do with the production version of this is...

We have a vCenter deployment that contains 3 hosts in a HA/FT cluster. They use shared storage, and most of our VMs run just fine on this storage. However, we need the performance of the CRM system to remain the same even after P2V, and our main storage array won't provide that performance.

So, what I've done is take the beefy Dell box with its 1.6TB of RAID10 15k storage and turn it into an iSCSI target, and provisioned it as a datastore available within our vCenter infrastructure. Our network is 1GB all-round, for the record.

Now, when I perform a P2V on the CRM database server, putting it onto one of our hosts within our vCenter (our vCenter hosts are blades, so have no DAS storage), and select the datastore as the newly-created iSCSI target, the total time for a P2V is... 5 DAYS. Obviously this is because there is a massive speed decrease between going from transferring to DAS storage (as was the case during initial testing) to transferring to iSCSI storage.

My problem is that I need to schedule downtime for the crossover from physical to virtual CRM to happen, but with a total time of somewhere around 5 days, it's hard for that to happen.

Trying to think creatively, I've come up with the following:

Deploy another box as a standalone ESXi host and P2V the DB server straight to the DAS of the standalone host (should only take 5hrs or so, which means I can specify the downtime for switchover easily). Get rid of unnecessary SQL backup files and then use Veeam to take a backup of the VM. Then restore from Veeam backup into our vCenter infrastructure. This would probably mean an entire day of downtime, I'd guess.

Can anyone offer any advice (or alternatively, tell me I've WAY over-complicated things, and there's an easier way to do this!) please? Many thanks in advance!

[veremin]

Your plan looks good to me. Bear in mind, though, that VB&R doesn't replace native SQL tools completely, and if you're after SQL point in time recovery you will still need to use those.

As to the downtime during VM restore, you can minimize it using Instant VM Recovery. Restore VM almost immediately in the production and, then, start migration process. This way, the downtime will be several minutes,rather than hours.

Thanks.

[Dave-Departed]

Thanks Vladimir, much appreciated. Never even thought of using Instant VM Recovery! Although I think the performance may take a hit in doing it that way, as our backup storage is only 7.2krpm. But still, another option!

As for point-in-time recovery, our current SQL Maintenance Plan only runs once a day anyway, so Veeam can comfortably replace that, I think.

Many thanks

Dave

[veremin]

In this case, the backup job with AAIP and log truncation options enabled would answer your requirements, indeed. Thanks.