Issues migrating to Dedicated Backup Network

Hyper-V specific discussions

Issues migrating to Dedicated Backup Network

Veeam Logoby Norsak » Wed Aug 10, 2016 1:57 pm

I wish to offload my Hyper-V backups to a dedicated network/switch.

Here is a simplified diagram of my network:

Image

- Backups where originally talking to HV1 using the LAN IP 192.168.10.9
- Then I added the dedicated backup network
- I added (in veeam) a new Hyper-V Server with IP 10.66.66.10
- I created A replacement backup job targeting VMs on IP 10.66.66.10

Every thing seemed fine, except that I still saw heavy load on the 192.168.10.x network when backups where targeting the Hyper-V host on 10.66.66.10

For trouble-shooting purposes I disconnected the 192.168.10.35 interface on the Veeam server.
This creates the following error when re-scanning the 10.66.66.10 host:
Image
So veeam isn't willing to talk to HV1 using only the 10.66.66.10 interface.
Maybe this is because whatever veeam service/agent got installed on HV1, was installed using 192.168.10.9

How do I fix this? How do I migrate all backup traffic to the 10.66.66.10 interface?
Norsak
Novice
 
Posts: 3
Liked: never
Joined: Tue Jul 26, 2016 1:57 pm
Full Name: Norsak

Re: Issues migrating to Dedicated Backup Network

Veeam Logoby foggy » Wed Aug 10, 2016 4:27 pm

You seem to do everything correct. Might be a routing issue, I recommend contacting support for verification.
foggy
Veeam Software
 
Posts: 14742
Liked: 1079 times
Joined: Mon Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson

Re: Issues migrating to Dedicated Backup Network

Veeam Logoby nefes » Thu Aug 11, 2016 10:13 am

Could you please check in name resolution of HV1 on backup server? It should be resolved into 10.66.66.10, not 192.168.10.9.
nefes
Veeam Software
 
Posts: 534
Liked: 125 times
Joined: Mon Dec 10, 2012 8:44 am
Full Name: Nikita Efes

Re: Issues migrating to Dedicated Backup Network

Veeam Logoby Norsak » Fri Aug 12, 2016 11:38 am

Could you please check in name resolution of HV1 on backup server? It should be resolved into 10.66.66.10, not 192.168.10.9


That's actually good advice.
I updated the hosts files on both BACKUP and HV1 so that they resolve each other's hostname and FQDN on a 10.66.66.x IP address.

After restarting the BACKUP server this allowed for jobs to succeed.
----------------------------------------------------------------------------------

But there are still issues.
If I disable the 192.168.10.35 interface on the BACKUP server, then I can successfully run most jobs. Since the ONLY way it can talk to HV! is over the 10.66.66.x network, I do not get any traffic issues on the 192.168.10.x network.
But if I leave the 192.168.10.35 interface enabled on the BACKUP server, then I can see traffic issues on the 192.168.10.x network when i run backup jobs.

Because of these issues, my current strategy is to remove the 192.168.10.35 interface, to enforce complete physical isolation. Then give the 10.66.66.x network internet access.
It's not perfect (BACKUP would not have access to a domain controller), but it's where I think this is headed.
Norsak
Novice
 
Posts: 3
Liked: never
Joined: Tue Jul 26, 2016 1:57 pm
Full Name: Norsak

Re: Issues migrating to Dedicated Backup Network

Veeam Logoby nefes » Fri Aug 12, 2016 12:17 pm

Norsak wrote:But if I leave the 192.168.10.35 interface enabled on the BACKUP server, then I can see traffic issues on the 192.168.10.x network when i run backup jobs.

Because of these issues, my current strategy is to remove the 192.168.10.35 interface, to enforce complete physical isolation. Then give the 10.66.66.x network internet access.
It's not perfect (BACKUP would not have access to a domain controller), but it's where I think this is headed.

The question is, what traffic is it.
Could you please describe your configuration a little bit deeper:
1. What repository and where do you use? Traffic between host and repository can go through both networks, so you may want to utilize Preferred Networks feature to make it go through backup network (if all components have access to it).
2. Do you use guest processing? If so, and guests are connected to production network only, guest interaction traffic will go through production network anyway. However this traffic should not be intensive, so it is better to stay with it because of benefits from VSS and other guest processing bonuses.
You may also want to utilize Guest Interaction proxy and put it on some internal network of HV1. It will require additional configuration, but that way interaction will go through non-production networks.
nefes
Veeam Software
 
Posts: 534
Liked: 125 times
Joined: Mon Dec 10, 2012 8:44 am
Full Name: Nikita Efes


Return to Microsoft Hyper-V



Who is online

Users browsing this forum: No registered users and 5 guests