Contstant communication stream between VSA and vCenter during VADP backup

Last post 08-03-2015, 7:53 AM by TenTimes10X. 2 replies.
Sort Posts: Previous Next
  • Contstant communication stream between VSA and vCenter during VADP backup
    Posted: 07-30-2015, 7:58 AM

    Hi Everyone,

    I hope anyone can help me with this.

    A customer of ours has asked us why there is a constant communication stream between the VSA/MA server and the vCenter server of about 100 kb/s. This communication stream is establisched during a backup of a VM by the vsbkp process and will close during the time the backup moves from one VM to the next.

    For this customer this is an issue as the VSA/MA server and ESX hosts are on a remote site and the vCenter server is on the central site. The remote site only has a 2 Mbit connection and 100 kb/s is a lot of data for them on this connection.

    As VADP backup stransports the data directly from the ESX hosts to the VSA proxy, why is constant communication needed from the VSA server to the vCenter and what does it contain?

    This customer is using NBD as transport mode in case this makes a difference. Simpana environment is on v10 SP9.

    Kind regards,

    Paul

     

    P.S.

    I will test this in my test environment, but I just want to know if anyone knows. If I have any explanation, I will of course post it as well.

  • Re: Contstant communication stream between VSA and vCenter during VADP backup
    Posted: 07-31-2015, 5:00 PM

    Without knowing for sure my first thought is that this is cuased by either general management trafffic or by the VSA communicating to the vCenter for Change Block Tracking (CBT) information. I would disable CBT if it fixes it. 

    How is the VSA configured? Can you create a new virtualization instance that points directly to this host instead of the vcenter? This way the VSA knows nothing about the vCenter and in theroy shouldn't have any communication. 

     

    Good luck,

    Jon

  • Re: Contstant communication stream between VSA and vCenter during VADP backup
    Posted: 08-03-2015, 7:53 AM

    Hi Jon,

    I also thought this was caused by management traffic and CBT. The data is all being send by or to the vsbkp process. The data transferred between the VSA and the vCenter is about 3 GB of data for a subclient which has 3 VM's with a size of around 150 GB and 1 VM with a size of 1.8 TB. I don't know if this amount of data for CBT is normal.

    The VSA is configured as a pseudo client and every subclient has it's own specified VSA proxy. The proxy also the local MA that stores the backups locally and replicates it offsite. The VSA is not mentioned in the VSA object proxies, but is only specified in the subclient. There is nothing special about the configuration that could cause this.

    Unfortunatelly, we cannot create a host that communicates directly to the ESX host. The customer doesn't want this to happen as this is a very complex environment.

    I will ask the customer if they can disable CBT for a test, but it will increase the time needed for the backup. I will also analyse the network transfer data as well as they captured the traffice with wireshark.

    Met vriendelijke groet,

    Paul

The content of the forums, threads and posts reflects the thoughts and opinions of each author, and does not represent the thoughts, opinions, plans or strategies of Commvault Systems, Inc. ("Commvault") and Commvault undertakes no obligation to update, correct or modify any statements made in this forum. Any and all third party links, statements, comments, or feedback posted to, or otherwise provided by this forum, thread or post are not affiliated with, nor endorsed by, Commvault.
Commvault, Commvault and logo, the “CV” logo, Commvault Systems, Solving Forward, SIM, Singular Information Management, Simpana, Commvault Galaxy, Unified Data Management, QiNetix, Quick Recovery, QR, CommNet, GridStor, Vault Tracker, InnerVault, QuickSnap, QSnap, Recovery Director, CommServe, CommCell, SnapProtect, ROMS, and CommValue, are trademarks or registered trademarks of Commvault Systems, Inc. All other third party brands, products, service names, trademarks, or registered service marks are the property of and used to identify the products or services of their respective owners. All specifications are subject to change without notice.
Close
Copyright © 2019 Commvault | All Rights Reserved. | Legal | Privacy Policy