DD Boost - Gateway server - Which Veeam edition

[cristiano.cumer]

Hello Forum,

I have some questions regarding the DD Bost integration. First the easy one : which Veeam edition is required to be able to use DD Bost? Will the Standard be enough?

The second question is about DD gateway server role. Will each proxy act as GW server if I chose not to specify a GW server?

And the final question is about the DD gateway placement. I read in the manual on page 330

If you perform backup over WAN or slow connections, choose The following server. From the list below, select a Microsoft Windows server on the target site to be used as a gateway server. The selected gateway server must have a direct access to the EMC Data Domain storage appliance and must be located as close to the storage appliance as possible.

This is a bit confusing. I can't understand why the GW server should be located close to the storage appliance. If I have understood how DD Bost works, the GW server should send already deduplicated and compressed data to the DD Appliance. On the other side, data from the proxy to the GW Appliance is not already deduplicated, so the bandwidth requirement for this kind of traffic should be higher than the DD Boost traffic. So why push this data over the WAN link instead of the DD Boost traffic? I'm missing something?

Thank you!

[mlott@gie.com]

Standard appears to work for me, by the way. I am also curious about the gateway server concept. We are currently testing the DD Boost over Ethernet connection. But, I would like to have a more direct connection via FC. However, the LAN connected to the Veeam server, a VM, will no doubt still be in use when connecting to the gateway. This currently connects via the same network that is used for production VMs. Must be a better way.

[nefes]

You need Enterprise or Enterprise Plus license to add deduplicating storage as repository and to run jobs against it. Please see this document for full editions comparison: http://www.veeam.com/veeam_vas_8_editio ... _en_ds.pdf
As to WAN connections, that is EMC limitation: ddboost is not considered to work over WAN links.

[mlott@gie.com]

My mistake - we do have Enterprise.

[tsightler]

This is a bit confusing. I can't understand why the GW server should be located close to the storage appliance. If I have understood how DD Bost works, the GW server should send already deduplicated and compressed data to the DD Appliance. On the other side, data from the proxy to the GW Appliance is not already deduplicated, so the bandwidth requirement for this kind of traffic should be higher than the DD Boost traffic. So why push this data over the WAN link instead of the DD Boost traffic? I'm missing something?

I believe the answer to this is that EMC doesn't officially support DDboost connections over the WAN in the current versions of the DDboost API (I believe they state something like 1GbE and 0 percent packet loss). So instead Veeam compression/dedupe is used between the proxy and the gateway server, and DDboost is used across the local connection only.

Every actively running job will have exactly one gateway server. This server handles all I/O to the DD for that job, thus if multiple proxies are used for a job (for parallel processing) those proxies must send their data stream to the server acting as the gateway, which will use DDboost to write it to the DD.

BTW, this behavior is exactly the same as it has been for customers using CIFS/SMB since v6 was released. One server for each job controls the I/O stream. You can either statically configure a server to always handle the I/O stream (which can make the dataflow more predictable), or you can choose auto and Veeam will randomly select a proxy for each job to act as the gateway.

[Gostev]

That is correct.

[cristiano.cumer]

Hi!

Thank you for all the answers!

Kind regards

Cristiano

[cristiano.cumer]

Just a follow up:

From the release notes of DDOS 5.5:

WAN support—backup to Data Domain over WAN, enabling Avamar DT/LT (DeskTop/ LapTop) and ROBO (Remote Office Back Office) use cases to Data Domain and DDBoost.

Now dd boost can be used over the wan!

Kind regards

Cristiano

[Gostev]

This also requires the new version of API (DDBoost 3.0) as well, whereas B&R v8 uses DDBoost 2.6.3.1 (which was the latest stable release at the time).

[haslund]

Gostev: With the release of v8 Update 2, is Veeam still using DD Boost 2.6.3.1 or has it been updated to use 3.0?

[dellock6]

I'll let Anton the final word, but by looking at C:\Program Files (x86)\Veeam\Backup Transport\x64\ddboost\libDDBoost.dll in a system using v8 Update 2, version of the library is still 2.6.3.1.

[rasmusan]

I know this post a bit old, but still relevant I think.

As I understand, when doing backup copy job to a DataDomain appliance with DD Boost integration, the backup merge operation still happens the same way as with fx. a CIFS share with traffic going back and forth to the proxy during merge? as opposed to the creation of a Synthetic Full backup creation, which happens locally on the Data Domain? Is that correctly understood?

And will behavior change with the release of Veeam B&R v9 in relation to DataDomain/DD Boost ?

[Gostev]

No, you understanding is not correct here, Rasmus. ALL full backup transformation operations happen locally on the Data Domain when DD Boost integration is leveraged, not just synthetic full. Thanks!

[rasmusan]

hmn if this is true, I can't understand why I see a quite big network load on my Veeam proxy, when the copy job has finished copying and are running the "starting full backup file merge (GFS)" operation?

also the time to run this is highly dependent on the bandwidth available between my proxy and Data Domain...

I have separate installations where I see this behavior - so that's the reason for my question. I would love to see the merge also just running locally on the Data Domain and not being dependent on the network bandwidth...

[foggy]

Rasmus, what kind of network load are you talking about? All synthetic activity stays local within the storage, however Veeam data mover agent installed on the gateway server (proxy, by default) communicates with the storage to send actual commands for blocks relocation.

[rasmusan]

Well looking at the task manager on the gateway server, show bandwidth usage between 50 to several hundred megabit/s when doing consolidation/merge... and the time used for merge seems to be largely dependant on the bandwidth avalable between gateway server/proxy and DataDomain (100 vs. 1000 mbit/s)

[rasmusan]

Veeam guys, could you please comment on my latest reply ?

[Gostev]

As per earlier responses from Veeam guys, this is unexpected so please open a support case for further troubleshooting.

[rasmusan]

thanks - I will do so

[rasmusan]

I have now had a support case created, and it turns out that my observations were indeed the intended and by design - at least for now. Hope this can change in future release.

reply from support was:

"This behavior is behavior by design. Essentially, when creating a synthetic full, we are taking advantage of the Datadomain's internal ability to create synthetic full backups on it's own but when merge is running, it is mandatory that some blocks get combined, some blocks deleted and eventually the chain has to have one less restore point(as per retention policy). It is advisable to have a gateway server running as close to the DD as possible to avoid merge traffic going through management networks for this reason"


Hope this information can help others wondering about this...

[Gostev]

This response for support is completely incorrect (I double checked with the lead developer behind this feature). What was the support case ID?

[rasmusan]

Ehm ok....

case number is: 01089379

[foggy]

I'd recommend to re-open the case and ask for its escalation, so that our engineers could look at what is actually happening during the merge in your case.