Vmotion with vrrp-a heartbeats best practice

Community Forum Forums Thunder and AX Series General Vmotion with vrrp-a heartbeats best practice

This topic contains 5 replies, has 2 voices, and was last updated by avatar toddmason 2 months, 1 week ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #16012
    avatar
    toddmason
    Member

    I’m not seeing (or finding) any documents out there that speak to best practices with VMware ‘s vmotion of a vThunder ADC when vrrp-a is operational. Understanding that during a vmotion event the VM is stunned momentarily and likely little to no IO for a short period of time. It would seem to me then that any heartbeat traffic between the two devices would potentially be jeopardized and could cause fail over.

    Is vmotion recommended with vADCs or if so are there any specific practices when using it?

    We come from a shop with lots of history with physical ADCs and have been migrating to virtualized over time. We seem to have gotten away with it (vmotion) at times but other times not.

    Suggestions or thoughts?

    Thank you in advance.

    #16022
    avatar
    toddmason
    Member

    I should clarify. I’m speaking more to the stun process/event that occurs with both vmotion and any snapshot of the VM.

    #16032
    avatar
    diederik
    Member

    Regarding vMotion in general, I believe it is not advised to vMotion busy systems in general.

    The same would be true for a busy vThunder.

    Since you are using VRRP already, make sure all traffic passes the master before using vMotion on the secondary unit. So if the current master needs to be moved, first move all the traffic to the other system. In this case even if there is a hickup in the VRRP-A communication, there will not be a state change. After the vMotion has concluded you can move the traffic to the moved system or keep it on the master. Or rebalance it all depending on the VRRP-A setup you are using.

    #16042
    avatar
    toddmason
    Member

    Thanks, that’s what I was thinking as well. I’m getting push back from our VMWare owner/operators on this. Is there an official recommendation from A10? You’re probably from A10 I realize…

    As I indicated we come from heavy physical ADC shop so the topology of dual ADCs is an easy concept to go forward in a virtual environment. I’m wondering now if a single vADC that is monitored by VMWare wouldn’t be worth exploring. I don’t know if the VMTools are required or if they’re even supported or can be installed in the underlying OS. I’m getting off subject here. Just thinking out loud.

    Thank you.

    #16052
    avatar
    diederik
    Member

    I believe you are already in contact with your A10 representatives, they can probably provide you the official answer regarding vThunder and vmotion.

    I have no experience with customers using vMotion and vThunder.
    Regarding single vADC instances and monitoring with VMWare, it depends on the version you are running, but in general A10 does have VMTools available.
    You mean a single vADC, so no HA/redundancy? That would provide you with effectively… no redundancy, well at least not without service interruption. That does not seem like a good idea to me.
    vMotion is not meant to provide redundancy :)
    For workload/resource management I can totally understand how/why it is an excellent feature of VMWare.

    What is the problem you are trying to solve with vMotion?

    #16062
    avatar
    toddmason
    Member

    :) Not trying to solve anything with vMotion, just trying to live with it or get agreement or statement that it’s not recommended.

    My group owns the VMs running in the virtualized environment. We do NOT however own/operate the virtualized environment; ie VMWare vSphere. It is those owners/operators that maintain all VMs should be able to continue operation whenever they vMotion VMs (because of environment loading, provisioning activities or otherwise) or perform snapshots.

    I am with the position that that is not reasonable for vADCs and need to operate without VM stuns by the hypervisor.

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.

Comments are closed.