Delta Backup transferred thru slow management network...

icecoke

Hi there,

we have the following, physical setup:

public net 1.2.3.xxx
management net 192.168.0.xxx
storage net 10.0.0.xxx

all storages are connected to 10.0.0.xxx only (so the remote target, too)
all xenserver are connected with one NIC to the public net
all xenserver are connected with one NIC to the storage net
SOME xenserver have their management network on the NIC with the management net
SOME xenserver have their management network on the NIC with the storage net (so no dedicated storage/management NIC)

It is planned to separate the storage net completely from the management net, but atm some have the old (management on storage network/NIC) and some have the new (management network on dedicated NIC, storage on dedicated NIC) setup.

The xoa VM has connection to bot networks.

In the most situations it was helpful, to separate the storage and the management, even if the management has just 1Gbit/s and not 10Gbit/s as the storage network. According to the citrix xen forum discussions the management suffers from the traffic kind of the storages, so we separated it. We got faster responses in controlling VMs etc. after that. So far, so good.

The big problem is now:

xoa is transferring the complete backup data of VMs on hosts with the dedicated management NICs thru these NICs even if the target storage is only connected to the storage network. VMs on hosts with shared management/storage NIC on the storage network are transferred on this network, with nearly 10 times faster speed (as this is a 10Gbit/s network).

This is terrible slow for the setup with the dedicated management NIC and - as the target is on the storage network (which makes sense in all environments) - I wonder why this can't be controlled by the user, if xoa is not trying to use always the target network if possible on it's own?

When I migrate VMs across pools, xen is offering the selection of the network and - as all VMs/Hosts are connected to the fast storage network - it makes only sense to transfer the data on the storage network as this data is no control information, but only a stream of storage data...

Is there a way to control/change this for backups? Do I need to remove the management NIC from the xoa VM, so xoa MUST connect to all hosts by the storage network? That in return would slow down api commands to control hosts and VMs again as that was the reason for a dedicated management network.

Any solutions/workarounds on this?

Kind regards,
jimmy

Darkbeldin

Hi,

What you need to understand is that all backup traffic is going through XOA VM. To summarize quickly when XOA launch a backup job:

The host make a snapshot.
This snapshot is exposed to XOA who download it.
Xoa push the backup to the remote.

So your XOA being able to communicate through your 10Gb network between your host and your SR is mandatory.

icecoke

@darkbeldin Hi!,

the xoa VM is already able to communicate thru the 10GB network, but it does'nt as it obviously prefers the management network for this purpose instead of the dedicated storage network of the dom0 hosting the given VM to backup.

So the 'problem' seems to be that the download from the host is taken thru the management network if that exists - despite the existance of a dedicated storage network on the same dom0. That is the point where one should be able to select the network where the snapshot is transfered thru. At least if there are more than one network existing in the given pool/dom0.

Can this be achieved?

olivierlambert

Try to change the default network of the pool in Pool/advanced tab/Default migration network.

Darkbeldin

Here is the news about that https://xen-orchestra.com/blog/xen-orchestra-5-62/#usedefaultmigrationnetworkinbackups

icecoke

@darkbeldin

That sounds really promissing! I will change and test this.
Many thanks!!!

icecoke

@olivierlambert I'm sorry to say that, but it seems that this change (defining the default migration network for all pools) made no difference.
Is it for sure, that this also defines the network used on Delta Backup jobs?
Is it needed to define the Delta Backup job completely new (maybe it saved some information about the migration networks of the first Delta Backup job run?) ?
Any input is welcome!

icecoke

@darkbeldin Any additional idea, why this still happens after the suggested change?

Many thanks!