Storeonce catalyst copy replication over 10G Fiber

[Hirosh]

Hi guys ,

Im planning to configure Replication between multiple Storeonce of 10G Connections , in 3 different Sites in a ring topology. as a Security regulation we need to isolate the backup traffic . we are trying to use an isolated VLAN and put all three Storeonce in that VLAN. I could not find any information in regards to replication/connection configuration(Catalyst Copy) in StoreOnce nor if we should configure Inter-vlan routes or single Isolated VLAN for this?


regards,
L.B

[Andreas Neufert]

We just trigger/orchestrate the replication and do not control the direct data flow. This is a HPE internal transport. Please reach out to your HPE technical representative.

[Hirosh]

Hi Andreas,
im curious to know if any settings needs to be done in storeonce appliances to find eachother, or simply just create a backup copy job in Veeam?i can go for my technical representative but then again someone might have the same question, and i wanted to know from Veeam perspective.

[Andreas Neufert]

You need to configure and prepare the StoreOnce for Catalyst copy and setup the relationship between the 2 systems. What Veeam does is just trigger the replication (update).

[Hirosh]

i have checked the documents , i could not find any information about the details of configuration, is there any document out there about catalyst copy configuration?

[Andreas Neufert]

I will ask our HPE specialist to answer with some details here.

[Hirosh]

Thank you.

[foggy]

Hi Hirosh, you need to add the arrays into Veeam B&R console using the following instructions and make sure they are configured for Catalyst Copy (HPE side of things - nothing special is required but you might want to review this detailed document for some tips and tricks). After that, you just create a backup copy job for HPE StoreOnce repositories between the corresponding source and target and that's it. Thanks!

[Hirosh]

hi foggy,

few month ago after creating catalyst stores inside Storeonce ,i created the repositories through Veeam Powershell in those catalyst storesusing the same document you just shared. my question is that before creating the backup copy job, do we need to configure anything inside storeonce appliances, so they can find eachother, or be connected? normally when we create a replication relationship we add the appliance in each other. i can not find any information about this in any document. the rest i already know and configured, i just want to know about the replication setup between storonce appliances, the settings that needs to be done for catalyst copy!?

[CLDonohoe]

There is no special configuration in the StoreOnce to support Catalyst Copy. Foggy has provided all the relevant details. I personally would configure a test job to see if traffic is routing properly. Veeam does not control the traffic routing between StoreOnce arrays, but this could obviously be further configured in the StoreOnce arrays themselves and in your own network infrastructure.

Run a test job first, though, and see how the traffic routes. Is there maybe a small repository you can use to test?

[FedericoV]

The two SO units do not know each other. It is Veeam telling the first unit to talk to the remote one providing it the IP or (FQ)DN.
That name is only located in the VBR Backup-Repository wizard. It is the same IP for all. All the Veeam proxies-gateway as well as the Source StoreOnce will use the same IP.
Now, going to your original request, I understand you want your Proxy-gateway to see the destination SO under one IP, but you want the Source SO to see the destination SO under a different IP. Honestly I'll think twice at the advantages of doing that, the reason is that you already have a Proxy accessing the remote SO unit, and that proxy needs anyway to communicate with the Veeam server which is in your source site. This means that even if you isolate the replication connection to a specific VLAN, you still have another link on the backup VLAN, so closing a door is important if that is the only door, but in this case the other door has to remain open. Normally a dedicated replication IP is used for Storage Array replication, where the communication is between the 2 units, and nobody else is involved.
Here we want to have VBR able to see the content of the Destination SO, because this way you can browse it from the GUI and start any restore operation from the destination the same way you do from source, without having to make any re-configuration. I'm sure we all understand the advantages of that. For instance, browsing the destination from the GUI, and testing a restore from the destination is something that takes just few clicks.

That said, if it is still mandatory for you to use a different IP for replication, I guess there might be a solution. I want to make it clear that it is not documented and I have never tested it, so it is up to you to try, or to ask your consultants to work on it.
Draft idea to be verified: If you define the destination StoreOnce within the Backup-Repository using a DN (not a FQDN, and not a IP), and the Source StoreOnce points to a different default DNS then the one of your proxy, than the IP translation it gets for that DN can be different. Same result if we can have that DN in the SO hosts file, which as priority in any name resolution. Again: THIS IS AN UNTESTED CONFIGURATION that you have to test and maintain on your own.

[Hirosh]

Hi Federico,
Thank you, its always great to have your comments on topics. I think I need to emphasize on some fact:
1. we want to use a single VLAN, which has spanned over the 3 Datacenters(each 40KM away), which would be an Isolated VLAN.
2. The interfaces and IPs would be unique for that backup VLAN only, which will include not just replication links , but also Veeam Servers to SO(Proxy & GW are installed on Veeam Server).
3. we are aware the alternative is to use a vlan in each Site and create a inter-vlan routes betwen those sites(vlans), but that's not our preference.

just be clear , so no specific configuration needs to bed done on SO units for replication? just simply create a backup copy job with source/destination being SO units? Honestly I thought this is handled(maybe some configuration needs to be done) and done by SO through SO GUI

regards,
Hirosh.

[FedericoV]

Hi Hirosh,

It's a pleasure to be able to contribute when it's a topic I know.
It is for NAS and VTL replication that we need to setup the replication process inside StoreOnce, specifying destination and frequency. With Catalyst Copy everything is simpler.

Catalyst-Copy is easy to setup. It just requires 2 Backup-Repositories. It works in parallel (a single source to multiple destinations) and cascade (Source to dest1, which is source to dest2, ...). If you have multiple ROBO to be replicated to a central site, you can send all to the same destination repository, but I prefer to create multiple dedicated repositories also on the central site and have a 1 to 1 replication. If you create them on independent Catalyst Stores you lose the cross deduplication between the different repositories. In this situation I prefer to create multiple Veeam Backup Repositories inside the same Catalyst Store in the Central site. This can be done only via VBR CLI, but it is very easy (copy and paste, and replacing the important names).

Catalyst Copy can be fast, and by default it tries to run at maximum speed. If you have a shared WAN, you might want to reduce the bandwidth utilization. If necessary, this can be done setting restrictions on the destination repository. I like to let it run at max speed. Also, remember that VBR is not aware of the deduplication effect on the line, so if you set a restriction it is on the logical throughput. The physical speed can be 1/10 of the logical, so pay attention to not reduce it too much. For example, if you want to use 100MB/s on your WAN, probably you could set a limitation at 1000MB/s on the repository. Regarding the number of parallel streams, I like to leave it unlimited, and eventually reduce it only if you see issues.
The simplest configuration is to not set any restriction (bandwidth and streams) on both source and destination repositories.

Regards
Federico

[Hirosh]

Hi Federico,

Thanks for the clarification & details you shared with us, appreciate it.

regards,
Hirosh.