I have was wondering if any Veeam engineers could weigh in on the design below, i need to forecast for 2015 and what hardware we need to support an additional 1000vms
Current setup is all vmware 5.5
1 main Backup server 32GB 16core Virtual
16 Proxies 8 gig ram 16 Cores Virtual each
DD860 10 Gig Uplinks, Using CIFS,
Jobs:40
VMs:1102
Templates:0
Data Processing speed: 26 MB/s
Source VMs size: 266.4 TB
Full backups:269.9 TB
Restore points:99.8 TB
With the release of version 8 i can leverage the use of DDBOOST helping backup windows come down, but we are still getting to the point where backups are running for nearly 18 hours a day, the speeds are not bad at all, I assume this 26MB/s is an average and we see more than that at certain times and less at other, i just wondering in the next year when we may hit 2000vm servers what hardware modifications we should make? I believe the main option would be to use the DD860 as long term storage and try and get a cheaper SAN in front of it so we can get faster file restores, as re hydrating a data domain with 16x dedupe is horrible.
All Ears Tom, Gostev
-
- Enthusiast
- Posts: 43
- Liked: 3 times
- Joined: Aug 21, 2013 1:15 pm
- Contact:
-
- Veeam Software
- Posts: 21139
- Liked: 2141 times
- Joined: Jul 11, 2011 10:22 am
- Full Name: Alexander Fogelson
- Contact:
Re: Infrastructure Advice
Honestly, 26MB/s is not too fast, although you say it is average across all the jobs. What bottleneck stats do you have for your jobs, what transport modes are used to retrieve VM data from the source datastore, what are your storage optimization settings, and what backup mode (forward or reverse incremental) do you use?
-
- Enthusiast
- Posts: 43
- Liked: 3 times
- Joined: Aug 21, 2013 1:15 pm
- Contact:
Re: Infrastructure Advice
Job settings are as with every job
Incremental. Active fulls weekly
Compression NONE
Optimize Local target
CBT ON
As Recommended by EMC with DD860
Repository Don't Align Data Block
No Decompress Backup Data
CIF Share
28MB is a very low average, we normally get around 75MB in the job, sometimes they burst to 1GB/s no idea why the massive variance, lots of moving parts are in the design
Incremental. Active fulls weekly
Compression NONE
Optimize Local target
CBT ON
As Recommended by EMC with DD860
Repository Don't Align Data Block
No Decompress Backup Data
CIF Share
28MB is a very low average, we normally get around 75MB in the job, sometimes they burst to 1GB/s no idea why the massive variance, lots of moving parts are in the design
-
- Veeam Software
- Posts: 21139
- Liked: 2141 times
- Joined: Jul 11, 2011 10:22 am
- Full Name: Alexander Fogelson
- Contact:
Re: Infrastructure Advice
And what about bottleneck stats and transport modes? You can check those in the job statistics window available by right-clicking the job and selecting Statistics.
-
- VeeaMVP
- Posts: 6166
- Liked: 1971 times
- Joined: Jul 26, 2009 3:39 pm
- Full Name: Luca Dell'Oca
- Location: Varese, Italy
- Contact:
Re: Infrastructure Advice
Uhm, only counting the proxies and supposing the VBR server is not actively partecipating in the jobs, 16 * 16 means a total of 256 slots for parallel processing.
This would mean, with any limit configured, 1/4 of all VMs are processed together. Ok, there are limits too to the snapshots per datastore we open, but the point is, how many backups are started at the same time? Maybe there are too many proxies hitting the production storages (I supposed there are more than one... by the way what is it?) thus causing problems to it?
If we have bottleneck stats we can stop guessing and start to look better at the environment, but a really wild guess is maybe there are too proxies, and since the DD is used in CIFS mode, of of this proxy can probably be the bottleneck since he's acting as the "proxying server", thus receiving all the data from all other jobs. Again, just a first wild guess.
Luca.
This would mean, with any limit configured, 1/4 of all VMs are processed together. Ok, there are limits too to the snapshots per datastore we open, but the point is, how many backups are started at the same time? Maybe there are too many proxies hitting the production storages (I supposed there are more than one... by the way what is it?) thus causing problems to it?
If we have bottleneck stats we can stop guessing and start to look better at the environment, but a really wild guess is maybe there are too proxies, and since the DD is used in CIFS mode, of of this proxy can probably be the bottleneck since he's acting as the "proxying server", thus receiving all the data from all other jobs. Again, just a first wild guess.
Luca.
Luca Dell'Oca
Principal EMEA Cloud Architect @ Veeam Software
@dellock6
https://www.virtualtothecore.com/
vExpert 2011 -> 2022
Veeam VMCE #1
Principal EMEA Cloud Architect @ Veeam Software
@dellock6
https://www.virtualtothecore.com/
vExpert 2011 -> 2022
Veeam VMCE #1
Who is online
Users browsing this forum: Bing [Bot] and 98 guests