vMotion for database applications

[RanjnaAggarwal]

Is there anyone who can tell me that vMotion is recommended for database applications or not? and why or why not?

[Virtualinfra]

Rickard Nobel wrote:

Dharshan wrote:

4 vCPU / 16 GB RAM those are called as small VM,

Large VMs are 8 vCPU and 128 GB RAM or plus,

Could you please provide a link where it is defined what is a "small" or "large" VM? Since I am very un-aware of any such clear definitions.

Very correct, me to unaware of such definition, but still the documents mention as large VM, but there is no definition that i can find for configuration saying this is large VM, but according to VMware config Max, VM are max supported with 32vCPU and 1TB RAM, based on this IMO i will say anything higher than 8vCPU and 64GB ram can be considered as large VM.

[rickardnobel]

Dharshan wrote:

based on this IMO i will say anything higher than 8vCPU and 64GB ram can be considered as large VM.

I guess many might not agree with this specific definition of "large VM", but of course that is nothing wrong either. I think it just is important to make a distinction between what is officially recommended and what is someones private opinion.

Dharshan wrote:

but still the documents mention as large VM, but there is no definition that i can find for configuration saying this is large VM,

The document about DRS does in my interpretation just mention that the DRS algorithm will prefer smaller VMs than larger VMs when doing reorganizations of the VMs inside the cluster. I think there is nothing strange with this, it will mean the least amount of network traffic and the fastest transfers and it will be good for everyone. It is however not really the same as the question of a Database VM could/should be vMotion moved at all.

[Virtualinfra]

Rickard Nobel wrote:

I guess many might not agree with this specific definition of "large VM", but of course that is nothing wrong either. I think it just is important to make a distinction between what is officially recommended and what is someones private opinion.

The document about DRS does in my interpretation just mention that the DRS algorithm will prefer smaller VMs than larger VMs when doing reorganizations of the VMs inside the cluster. I think there is nothing strange with this, it will mean the least amount of network traffic and the fastest transfers and it will be good for everyone. It is however not really the same as the question of a Database VM could/should be vMotion moved at all.

In that case if that refers only DRS, why do they mention in the documents as large VM and as you told DRS has a algorithm which to pefer smaller on that larger one(again what is larger one here).mover over the  document or discussion is not about vmotion of smaller ones or large ones, its about SQL server as virtual machine vMotion.

Also its clearly mentioned as VMware vMotion and VMware DRS and again mentioned that Smaller VMs are better candidate that larger once(unware).

as mentioned to your interpretation, if its just with DRS, in the document it could have been clearly mentioned that DRS will prefer moving smaller VMs than larger one as per algorithm( again there are differents between VMware documentation and our own interpretation). that document is particularly for SQL servers and also it clearly mentions as Vmware vMotion and VMware DRS. in both the case VMware vMotion or VMware DRS its is prefer to be a better candidate for smaller ones than larger VM( again as unware what are large VM, as mentioned there are distinction between VMware officially recommendation and private opinion).

[rickardnobel]

Actually I am a bit unsure what your exact point is, but as I have said already: there is nothing strange to me that DRS will prefer to vMotion a smaller VM compared to a larger one.

The SQL document you have quoted just says for vMotion / DRS:

"Virtual machines with smaller memory sizes are better candidates for migration than larger ones."

For me this is just that a VM with 8 GB vRAM is larger than VM with 4 GB vRAM and if everything else is equal then it is most suitable to migrate the smaller one.

[Virtualinfra]

For example if we are speaking about the VM in cluster in common , then the comparison works like 8GB vRAM is larger than 4GB vRAM.

But this document is specfic for SQL servers, here as you mentioned we are unware what configuration of VM said as larger one in the environment ?(private opinion are not valid, even though it seems)

So my point is in general there is no problem with vmotion larger or smaller, but when it comes to DB servers larger VMs running databases are not a better candidate for vmotion, its not that my point is should not do vmotion, but as referred its not a better options during the VM is fully load (peak time).

By default as you already mentioned DRS functionality is to do vMotion of smaller VM in that cluster as per the algorithm theoretically,practically it might differ I am not sure lets not get into DRS core..

[rickardnobel]

Dharshan wrote:

But this document is specfic for SQL servers, here as you mentioned we are unware what configuration of VM said as larger one in the environment ? (private opinion are not valid, even though it seems)

So my point is in general there is no problem with vmotion larger or smaller, but when it comes to DB servers larger VMs running databases are not a better candidate for vmotion, its not that my point is should not do vmotion, but as referred its not a better options during the VM is fully load (peak time).

There seems to be nothing in the either the vMotion Best Practice document or the specific virtualized SQL server document that says you should not do a vMotion of a DB VM during peak times.

Since the line about smaller VMs being "better candidates" are for DRS, I really think you are reading a little bit too much into this. DRS has no knowledge what is running inside the VMs and it could only look at CPU and RAM usage. From that perspective a smaller VM is just a better candidate to move first to achieve the goal of better balancing of load.

[RobertAnders]

Hi,

I have a question in the same direction. We plan to implement virtual machines with database and erp application with 64-128GB RAM in next year. Our cluster is still on a dedicated 1GbE vMotion network. I'm afraid, that vMotion won't work because it take too long and run in a timeout or I have so much changes in the running VM that vMotion will not come to an end. Is that right? Is there a timeout?

I want to upgrade to 10GbE but need to justify that. But I can't find minimum requirements for vMotion of such large VMs. I found a recommendation in Best Practise Guide (http://www.vmware.com/files/pdf/vmotion-perf-vsphere5.pdf - page 22). But I'm afraid it's not enough.

What do you think?

Regards

Robert

[mcowger]

To my knowledge, theres no direct timeout for the task. However, if the task fails to make sufficient forward progress (due to high memory change rates), it could get killed.

I think it would work, but if you memory change rate exceeds what the vMotion link is capable of (~110MB/s), then it wont. Even if it does, you are still looking at 20+ minute vMotions as a best case scenario.

[RobertAnders]

Hi mcowger,

yes, I think you're right. I could talk yesterday to another VMware specialist, he told me the same. The vMotion process will run as long as needed, no time out. With vSphere v5.1 there is a new feature "SDPS". In case the change rate is to high, vMotion will with that feature slow down the virtual machine.

In summary it's possible to move large machines with 1GbE, but it's not recommend by VMware (see Best Practise Guide http://www.vmware.com/files/pdf/vmotion-perf-vsphere5.pdf - page 22) and it will take a long time (20+ minutes).

Thanks for help!

Regards

Robert