vsa architecture question

Last post 03-08-2011, 5:08 PM by PhilippeMorin. 6 replies.
Sort Posts: Previous Next
  • vsa architecture question
    Posted: 02-25-2011, 5:56 PM

    I'm looking into setting up VSA with VMWare and I'm a little confused on how the data flows from the datastore to the backup media.

    Where should a VSA proxy sit? One per cluster, backing up all vms in that cluster?

    I'm thinking that in an ideal situation the proxy host would have direct access to the backup media AND the datastores, pulling data from, say, fiber storage right to fiber tape.

    From this diagram it looks like everything goes across the network from the vsa proxy to the media agent. I guess that's no worse than backing up vms as individual servers over the network.


    How have you guys set this up? "VM as on host proxy" on each cluster? Standalone proxy servers?

  • Re: vsa architecture question
    Posted: 02-28-2011, 3:18 AM

    Hi There.


    You can configure the Virtual Server Agent to backup up using different methods, the main two being LAN and SAN.


    LAN being obvious and using the network.

    SAN is the quickest, and will backup direct from the VM Datastore, for this to work the LUNS need to be present to the Proxy Machine.

    Generally you will need 1 VSA per 50 Virtual Machines.

    I would normally setup a stand alone proxy machine, LUNS presented to it, Backed up using SAN.




    Ben Walker
    PAV i.t. Services
    Commvault Platinum Partner Commvault Authorised Support Partner
  • Re: vsa architecture question
    Posted: 02-28-2011, 10:53 AM

    Thanks Ben, do you know of any good documentation online for setting up vsa over the san?

    Would it make sense for the vsa proxy machines to also be media agents so they have direct access to the backup media?

  • Re: vsa architecture question
    Posted: 02-28-2011, 11:54 AM

    If you can locate an old 3.5 backup guide, it should have details on what needs to occur for san transport mode (again all you need is to present the luns to the VS proxy)

    Making the VSA proxy also a media agent will prevent an additional hop of the network, so this is a typical setup.

  • Re: vsa architecture question
    Posted: 02-28-2011, 5:37 PM

    When you say 1 vsa per 50 virtual machines, would I really need 15 vsa proxies for 750 vms if I stagger the backups across the window?

  • Re: vsa architecture question
    Posted: 03-07-2011, 10:46 AM

    We have a lot more than the 1:50 recommended ratio.  We spread jobs out over our backup window so we have approximately 30 jobs running at one time per our 4 VSA proxy servers. 


















  • Re: vsa architecture question
    Posted: 03-08-2011, 5:08 PM

    Our VSA is also a media agent. We presented the luns to it so that VMs are backed up directly from the SAN to our backup storage. This works very well and fast. You could also consider using the snap protect which is pretty efficient too.

    For the number of VMs to backup, instead of manually spreading the backups over your backup window using schedules, you could just set a limit to the number of VMs backed up simultaneously either through the subclient if you use only one or through the storage policy (have a dedicated storage policy for your VMs with optionally global dedup enabled on your site for better dedup ratio with your other backups). That way, you don't have to try and time your backups so that new ones start once the first ones are done.


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.
Copyright © 2020 Commvault | All Rights Reserved. | Legal | Privacy Policy