Distributed setup Proxies to Repositories via fibre channel

[cookiejc]

Hi,

Has anyone any experience of using separate servers for the Proxy and Repository role and the data transfer method between the two? Veeam support have advised me that it's possible for the transfer to be via Fibre channel. Any tips on configuring this would be useful, have you simply zoned the Proxy to the repository and the veeam agent handles the rest? I currently have data coming into the proxy from the SAN via fibre channel and am looking to move my repository onto separate server(s) but don't want this stage of the data transfer to have to go over LAN. Thanks in advance

[veremin]

From my perspective, you should use IPFC (IP over FC) in order to make this scenario possible. IP over FC is specified by RFC 2625. Some HBAs support IP over F/C, and many switches also support it. So, you have to check whether or not currently used HBAs/switches support IPFC.

Also, what is the reason to separate proxy and repository roles?

Thanks.

[cookiejc]

Well we are following the Veeam advanced deployment scenario and this is what was recommended. From my point of view having proxies and repositories on the same server means jobs have to use the same proxy every time they backup. Unless i've missed something? We want to be in a situation where a number of proxies can be used as a pool of resource connecting to several common repositories. Having a repository directly on Proxy A for example, what happens when automatic selection processes a job on Proxy B?

[veremin]

Well we are following the Veeam advanced deployment scenario and this is what was recommended.

Based on my understanding, the only way to isolate backup traffic to FC and, meanwhile, have multiple proxyies/repositories is to provide proxies with multiple FC (IPFC) connections to existing repository servers.

Having a repository directly on Proxy A for example, what happens when automatic selection processes a job on Proxy B?

In this case, the traffic will flow via network.

Thanks.

[cookiejc]

Ok thanks, this is conflicting with information receieved from an Open case i have with veeam support where they've advised that the veeam agents will establish a connection over fibre channel for the repository using target - source. I wasn't sure and and can't find much on the subject. I'll try to get some clarification on the open call but this must be a common requirement for large deployments? Unless it is assumed the LAN overhead will be lower due to compression already having taken place on the proxy.

[veremin]

Ok thanks, this is conflicting with information receieved from an Open case i have with veeam support where they've advised that the veeam agents will establish a connection over fibre channel for the repository using target - source.

As to me, it seems like a slight misunderstanding between both parties.

If proxy server has corresponding LUN connected to, then, indeed there will be no need to use IPFC, as the whole process will be managed by VB&R without any issues. However, if you want to deploy proxy and repository role on different machines connect via FC, then, the only option I can come up with will be to use IPFC in order to isolate traffic to FC.

You might want to provide your ticket number here, so that, we can follow the case and see what has been originally meant.

Also, you might ask the same questions within existing support case. Probably, support team will be able to shed a little more light on how this scenario should be implemented.

Thanks.

[Vitaliy S.]

I'll try to get some clarification on the open call but this must be a common requirement for large deployments?

To run backup jobs in true "LAN-free" mode, our existing customers are installing proxy and repository servers on the same machine. And it is not something specific to small or large deployments, this recommendation is the same for all shops.

[cookiejc]

Vitaliy, if this is the case I am unsure how your other customer are making use of multiple proxies and automatic selection for load balancing. If the repository is tied to a proxy then the job cannot move between proxies?

My case number is: 00470027

I have just updated it as you say there may be a mis understanding. Thanks again

[Vitaliy S.]

Yes, it's all about the trade offs. If you want HA for the backup proxy servers and still send VM backup traffic over FC connection, then you should have one single repository server/FC switch and FC adapter on each proxy server. In deployments when this setup is not possible, backup admins are configuring a dedicated network for the VM backup traffic.

[cookiejc]

That is possible in our environment but it leaves us pretty much where we are now. Multiple individual servers as the jobs couldn't span proxies. It's more loadbalancing over HA we want.

We had considered a separate LAN network for the repository traffic. It just seems that there's a step missing in the whole solution. If the Proxy had the ability to talk to the repository over FC we would have a scalable loadbalanced solution using purely FC.I haven't done anything on IP over FC but will take a look at that as a potential work around

[dellock6]

I think honestly there is a basic misunderstanding around the term "LAN-Free" itself. Even if proxies and repositories, when running on separated machines, transmit data via TCP/IP, is completely still possible to have lan-free backup: lan backups refer to the idea of having backup traffic using the same network as production data, as it was "in the past" when using backup agents directly installed inside each VM.
But users can also design a completely separated network via separated cables (VLANs only separate broadcast domains but an high I/O on a vlan can degrade other VLANs...). In this way the fraffic from proxies to repositories is "LAN free", or we can better call it "production LAN free".

Even more, by adding a dedicated management interface, even the network mode backup can be LAN free.

I'm totally in for the two layer design with several proxies and common repositories, it gives no single poinf of failure if both a proxy or a repository crashes. A complete "pod" is for sure easy to design and deploy, and makes sense in medium environments. But to me is a remnant of Veeam v5, since the split of roles a completely distributed architecture is a goal any medium-large environment should have as a goal.

By the way, this is the exact design I made internally, and created to some of our largest customers.

Luca.

[cookiejc]

Thanks Luca, I understood the LAN requirement but was thrown by the possibility of Veeam agents being able to use the Fibre channel fabric as an alternative. The reason we'd want to do this is simply because of the extra capacity available on the FC. I think we will go for multiple proxies with two of them also housing the repositories and just accept that when jobs run on a proxy that doesn't have the repository, there will be some lan transfer.

[dellock6]

Been there, done that. It's not that bad, you need obvously to size the proxy-repo to accept more incoming jobs than it would eventually be able to execute by itself. And only part of the backup traffic goes onto LAN, at least the backups executed by the same machine are lan-free.

It's a good design indeed, don't get me wrong. But it only solve one part of the problem: proxy redundancy.
Repository redundancy is another problem, and requires a way to publish the same backend storage via several "gateways". We solved it using a scale-out Ceph storage, I have this stuff in my blogging queue since months, eventually one day I will find time to write about it.
Also, if you are more used to Windows, the new "SMB scale-out" feature in Windows 2012 R2 sounds really promising!

Luca.