Question on NFS Write Through in v10

[jimnoco]

As a service provider, we utilize Netapp’s primarily for Veeam backup repository storage. We get really good pricing on Netapp and with the speeds they provide we’ve had good success utilizing NFS shares as backup repositories. I would have preferred iSCSI but there is a limitation on volume size whereas we can get up to 100TB volumes with NFS. This allows us to deploy new repositories whenever we need them whether for our public or private cloud offerings.

Up until v10, we had to present NFS shares with CentOS virtual machines as repository servers. Our deployment would consist of a Netapp volume as an NFS share per repository server. We worked with a Veeam engineer who stated this should be a 1 to 1 relationship and needs a ton of resources for concurrent jobs, so often there would be multiple repository servers that would aggregate into a SOBR, in the case of our larger environments. We have had to commit quite a bit of resources to these repository servers to accommodate the large number of backup jobs that run nightly. Now that NFS write through is available in v10 I have some questions that do not seem answered in the documentation.

As stated, we had to dedicate a LOT of CPU/RAM to the repository servers. Now that the need for the repository server is removed, I see that it is necessary to deploy a gateway server instead. My question is do we need to dedicate resources to the gateway servers similarly as we did to the repository servers? Where are the resources needed to handle multiple concurrent tasks as they would on the repository servers? Does this translate to the gateway servers now with NFS write through? If so then what really is the difference if I deploy a gateway server vs. a repository server?

Thanks,
Jimmy

[HannesK]

Hello,

we utilize Netapp’s primarily for Veeam backup repository storage

so you chose the expensive and slow way (no matter what your discount was and what you believe is "fast")

Honest recommendation: get block storage (Netapp E-Series is fine) and use the FAS for something else.

I see that it is necessary to deploy a gateway server instead.

correct. and use "active full". Otherwise it will always be slow on NFS.

do we need to dedicate resources to the gateway servers similarly as we did to the repository servers

yes. but keep on reading, that is only have of the answer.

Yes, the gateway server does all that.

If so then what really is the difference if I deploy a gateway server vs. a repository server?

most people use "automatic selection". So the gateway gets dynamically assigned to multiple proxies and you can just skip the dedicated gateway. If you like to have a dedicated gateway, then there is only little difference, yes. https://helpcenter.veeam.com/docs/backu ... ml?ver=100

Best regards,
Hannes

[jimnoco]

Thanks Hannes. I figured this was the case with the gateway server but wanted to make sure. We originally went with Linux repo servers to get around Windows licensing so we'll probably just keep going the way we have instead of having to deploy more Windows. My storage admin found the Netapp's made sense price wise in comparison to UCS or something bulk so that we could deploy new environments on the fly with shared storage. I'll have him take a look at the E-series if we need to onboard another one.

Could you elaborate on what I believe is "fast" and NFS will always be slow? I'm assuming you refer to merge and synthetic operations in which we have thus far been meeting our backup windows with what we have. I understand ReFS, XFS much better for this, but at this point it would be very hard to move to, with everything we have in place (around 30 VBR environments for private and shared customers across 5 geos).

[HannesK]

Hello,
yes, it's about the merges. Sure, if you throw enough hardware on it (I have seen all-flash FAS systems for backup...), then it can work, yes. Or the amount of data is just small enough.

A block storage with REFS / XFS is a different level of performance. It cannot be compared with NAS systems.

The only advantage I see not using REFS / XFS is, that there more spindles for restore

Best regards,
Hannes

[orb]

I agree with both here

Usually, my first choices always go to

• E-Series > ONTAP for $$$

• Block over NAS because performance (write speed) vs time (backup window) vs physical space (block cloning)

jimnoco is right to point about LUN size limitation with ONTAP but It is hard to compare how much saving you can do vs a traditional volume approach.

For the sake of it, I did a single volume with qtrees with a SOBR and in-line compression, with post dedupe, post-compression and compaction on NL-SAS. To my own surprise, it works great! CPU on the controller is still low and my sources are still my bottleneck. We know we can rely only on full active, it uses a ton of bandwidth but the customer is super happy and he feels the ONTAP was his best investment (he didn't ask us at the first place). The extra tidbit is we save also space on with increments which by design is not possible with a block approach. Few of their services do huge increment randomly (old software, no one wants to touch, no support, yadda yadda yadda) . When we compare numbers with old block storage we get an extra saving (25%) when the physical print is compared over the same retention period on both systems.

Veeam is an amazing tool with agility. Would I recommend this design again? Not sure because it has his own complexity, price point and every customer are different at the end. Sometimes they are able to pull off some incredible deal with storage manufacturers. I say no more than cloud repositories on all-flash storages.

About that "automatic gateway" thing, this part needs to be re-engineered especially when you proxy/gateway does DirectNFS and Veeam is covering multi-sites and storages. It will tell you its unable to detect anything even if you declare a repository/proxy preferred relation. It makes even make more needed because it is written in the docs usually the proxy doing the DirectNFS is going to be the gateway anyway. It is annoying. I would be happy to see a "pool" approach as it exists for VCC gateways here.

Regards,
Oli

[HannesK]

I would be happy to see a "pool" approach as it exists for VCC gateways here.

that's a valid feature request and we count your request as +1.