Host-based backup of VMware vSphere VMs.
Post Reply
ditguy2012
Novice
Posts: 8
Liked: never
Joined: Dec 03, 2014 7:26 pm
Full Name: Blake
Contact:

Designing for performance

Post by ditguy2012 »

Hello All,

Wanted to get some real-world performance advice. We're about the deploy Veeam at a single site to start. I've tried reading up on what things affect performance so I was hoping you could help me wade through the issues.

* Master server - any special requirements? Virtual OK or is physical better?
* Proxy server - any special requirements? Virtual OK or is physical better?
* I read that a proxy server on each host in your clusters improves performance somehow. Not sure how or why. We have 10 on site plus 4 standalone esxi essentials hosts. That would be a lot.
* We want to use deduplication. Does that database run on master server, proxy server, or our SQL server? Should we use SSD if possible?
* Is the more cores in the proxy the better? Should we get dual 10-core CPUs?
* Is RAM a bottleneck? how much should we get?
* destination for backup is protentially going to be a Dell PowerVault system. Should we get smaller 10K drives with higher quantity or larger 7.2K drives? RAID 6 is slower than 5 for writes but faster for reads. RAID 10 is best but double the destination. Use that with 7.2K drives instead of RAID5 with 10K drives?
* Our tape libraries are connected via Fiber Channel. Anything to consider there?

I read there are various modes for doing backups. We have NetApp SAN for our VMs on ESXi 5.1. Something about hot-adds not working sometimes was worth considering.

Reducing our backup window is the biggest requirement for us. Get all the backups done as fast as possible. We need to do daily's for 30 days with weekly fulls (synthetic is OK but the Fulls need to go to tape) and then quarterlies that we'd keep for at least seven years.

We are hoping to only buy one physical server instead of separating the roles out to different servers. Is this OK?

Thank you to all who spend the time helping. Unfortunately our Veeam engineer rep is unavailable until next week but our VP is gone then so we're scrambling to design the environment.
Shestakov
Veteran
Posts: 7328
Liked: 781 times
Joined: May 21, 2014 11:03 am
Full Name: Nikita Shestakov
Location: Prague
Contact:

Re: Designing for performance

Post by Shestakov »

Hello Blake,
ditguy2012 wrote:Master server - any special requirements? Virtual OK or is physical better?
Both virtual and physical are ok.
ditguy2012 wrote:Proxy server - any special requirements? Virtual OK or is physical better?
A machine used as a backup proxy should have direct access to the storage on which VMs reside or the storage where VM data is written. This way, the backup proxy will retrieve data directly from the datastore, bypassing LAN.
The backup proxy can be a VM with HotAdd access to VM disks on the datastore. This type of proxy also enables LAN-free data transfer.
Please check transport modes.
ditguy2012 wrote:We want to use deduplication. Does that database run on master server, proxy server, or our SQL server? Should we use SSD if possible?
It`s perfectly explained here. Please read.
ditguy2012 wrote:Is the more cores in the proxy the better? Should we get dual 10-core CPUs?
Correct.
ditguy2012 wrote:Is RAM a bottleneck? how much should we get?
Depends on the infrastructure, job type etc. However, RAM is usually not a bottleneck. Please read the corresponding FAQ section.
ditguy2012 wrote:Reducing our backup window is the biggest requirement for us. Get all the backups done as fast as possible. We need to do daily's for 30 days with weekly fulls (synthetic is OK but the Fulls need to go to tape) and then quarterlies that we'd keep for at least seven years.
You can use forward incremental job to get the fastest backup during week-days and full backup during the weekend(if workload is less and backup window size is less critical at the weekend). For archival purposes GFS retention policy can be used.
Thanks.
ditguy2012
Novice
Posts: 8
Liked: never
Joined: Dec 03, 2014 7:26 pm
Full Name: Blake
Contact:

Re: Designing for performance

Post by ditguy2012 »

Thank you so much. I've got some reading to do and I'll reply back later. One thing I need to do is understand the pros and cons of using forward incremental vs others. For the fulls I was hoping a synthetic full would be acceptable (not sure if that's what Veeam calls them - we were comparing Veeam to Commvault thus the terminology) and then let Veeam reconstruct a true full when it goes to tape.
ditguy2012
Novice
Posts: 8
Liked: never
Joined: Dec 03, 2014 7:26 pm
Full Name: Blake
Contact:

Re: Designing for performance

Post by ditguy2012 »

Shestakov wrote: It`s perfectly explained here. Please read.
One question about this. I read the post and I'm still a bit confused. I don't know what it means when it says it performs the deduplication against the source datastore. To help me understand compare it to commvault - it stores hashes of data backed up and pointers in a database on the proxy/media-agent server. it doesn't touch the destination or source datastore in addition to getting data to back up or sending data to disk.

does veeam take a hash of the data it wants to back up and run hash checks against all other data in the source everytime? seems very inefficient and a potential bottleneck. I guess I don't understand how this is done without a database without hammering the source and/or destination disk. The other benefit of commvault from what I can tell is that less data is transfered over the wire.
Shestakov
Veteran
Posts: 7328
Liked: 781 times
Joined: May 21, 2014 11:03 am
Full Name: Nikita Shestakov
Location: Prague
Contact:

Re: Designing for performance

Post by Shestakov »

ditguy2012 wrote:I've got some reading to do and I'll reply back later. One thing I need to do is understand the pros and cons of using forward incremental vs others. For the fulls I was hoping a synthetic full would be acceptable (not sure if that's what Veeam calls them - we were comparing Veeam to Commvault thus the terminology) and then let Veeam reconstruct a true full when it goes to tape.
If your backups need to be moved to tapes, forward incremental is what you need. We also offer Forward Incremental-Forever Backup by default. This topic has related discussion. Please get familiar.
ditguy2012 wrote:I read the post and I'm still a bit confused. I don't know what it means when it says it performs the deduplication against the source datastore. ... does veeam take a hash of the data it wants to back up and run hash checks against all other data in the source everytime?
FAQ section also helps to understand deduplication processes.

Note, that there are different types of deduplication.
When you backup several VMs which contain similar data blocks or blocks of free space, Veeam Backup & Replication eliminates them, which decreases the size of the created backup file. It`s performed by backup proxy.
Also if you use WAN acceleration Global Data Deduplication before sending data over WAN(backup copy and replication jobs). Veeam Backup & Replication uses three sources for data deduplication in this case: VM disks, Previous restore points for the processed VM on the target repository and WAN Global cache.

Thanks.
ditguy2012
Novice
Posts: 8
Liked: never
Joined: Dec 03, 2014 7:26 pm
Full Name: Blake
Contact:

Re: Designing for performance

Post by ditguy2012 »

Shestakov wrote: FAQ section also helps to understand deduplication processes.

Note, that there are different types of deduplication.
When you backup several VMs which contain similar data blocks or blocks of free space, Veeam Backup & Replication eliminates them, which decreases the size of the created backup file. It`s performed by backup proxy.
Also if you use WAN acceleration Global Data Deduplication before sending data over WAN(backup copy and replication jobs). Veeam Backup & Replication uses three sources for data deduplication in this case: VM disks, Previous restore points for the processed VM on the target repository and WAN Global cache.

Thanks.

I'm only talking about local backup for now. not wan replication. So it sounds like it will dedupe across the source VMs before sending the data. does it then keep it deduped at the destination (including if we go to tape)?
Vitaliy S.
VP, Product Management
Posts: 27055
Liked: 2710 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: Designing for performance

Post by Vitaliy S. »

Yes, the dedupe also happens within the backup files (per each file). If you send backup files to tape, then there is no issue with that.
ditguy2012
Novice
Posts: 8
Liked: never
Joined: Dec 03, 2014 7:26 pm
Full Name: Blake
Contact:

Re: Designing for performance

Post by ditguy2012 »

Been doing some reading. From what I've read the more memory you put in the proxy server the more it will use but it is windows caching that's using it not veeam. Is this true? If so does it help significantly to add more memory? Memory is pretty cheap these days when buying it with your server initially. First we thought 32GB would be enough. Then we decided on 64GB. But if there's some level of linear relationship then even doubling that might make sense. Buying new CPUs is not cheap so we're starting with 2x 10-core cpus.

The bigger concern we have found is the disk destination storage size. Even with forward incremental and synthetic fulls we're being told we'll need up to 3x our actual data size to have enough space for our retention needs. this is crazy compared to synthetic fulls with other vendors (BackupExec and Commvault). It appears that every full, even when synthetic uses up the actual full backup size each time. Now most of it comes from already backed up data but it actually creates duplicates of the same data. So if you back up 100GB today and add 1GB a day, next week the synthetic full will go faster from the source VM perspective but the space used at the target will be 212GB to keep the first full, changes and second full. This does seem to offer some 'protection' in case the original full got corrupted all subsequent fulls wouldn't be but it's skyrocketing our disk target costs. Am I missing something here? Our goals are to dramatically reduce our backup windows and the amount of disk we're buying to store it.
Vitaliy S.
VP, Product Management
Posts: 27055
Liked: 2710 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: Designing for performance

Post by Vitaliy S. »

1. Actually, proxy servers are heavy CPU users rather than memory. CPU resources are utilized during VM backup compression process.
2. With new backup mode forever incremental, synthetic fulls are note required, so you will not need that much space > http://helpcenter.veeam.com/backup/80/v ... up_vm.html
ditguy2012
Novice
Posts: 8
Liked: never
Joined: Dec 03, 2014 7:26 pm
Full Name: Blake
Contact:

Re: Designing for performance

Post by ditguy2012 »

Vitaliy S. wrote:1. Actually, proxy servers are heavy CPU users rather than memory. CPU resources are utilized during VM backup compression process.
2. With new backup mode forever incremental, synthetic fulls are note required, so you will not need that much space > http://helpcenter.veeam.com/backup/80/v ... up_vm.html
Thank you Vitaliy,

However I'm curious though you still need memory for the proxy server. How do you determine how much to need?

Also is memory more of a concern in the master server? We also plan on running the Veeam One server. But SQL is on another SQL server not any of these.

As for "forever incremental" is this anything special other than old school full backup plus incrementals but never doing another full? Or is there something different and beneficial about Veeam's version of doing incrementals forever. I don't see what's so great about never doing a full again.

Thanks for taking the time.
Shestakov
Veteran
Posts: 7328
Liked: 781 times
Joined: May 21, 2014 11:03 am
Full Name: Nikita Shestakov
Location: Prague
Contact:

Re: Designing for performance

Post by Shestakov »

It`s required to have 4 GB RAM plus 500 MB RAM for each concurrent job.
ditguy2012 wrote:As for "forever incremental" is this anything special other than old school full backup plus incrementals but never doing another full? Or is there something different and beneficial about Veeam's version of doing incrementals forever. I don't see what's so great about never doing a full again.
Yes, it`s different: During first run of a backup job, VBR creates a full backup file (VBK), during subsequent backup job sessions VBR copies only changed VM data blocks, saves them as an incremental backup file (VIB) in the chain and merges first incremental of the chain with the full backup file, so you always have length of chain = preset number of restore points in accordance with retention policy.
This topic can answer additional questions. Thanks.
Vitaliy S.
VP, Product Management
Posts: 27055
Liked: 2710 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: Designing for performance

Post by Vitaliy S. »

ditguy2012 wrote:However I'm curious though you still need memory for the proxy server. How do you determine how much to need?
If you're talking about dedicated proxy server, then system requirements should be these - 2 GB RAM plus 200MB for each concurrent task (Using faster memory (DDR3) improves data processing performance).

If you're going to combine proxy and backup server, then follow Nikita's advice. As regards Veeam ONE installation on this server, then make sure you provision enough resources for this servers as well (please check our release notes for Veeam ONE)
Post Reply

Who is online

Users browsing this forum: Google [Bot] and 75 guests