4.4 vSphere Networking

Outside of the virtualized platform, there’s a complete range of additional resources that a service provider has to setup in order to guarantee Veeam Cloud Connect operates properly.

In particular, the network design is of extreme importance for Veeam Cloud Connect.

NOTE: VLANs and NEA appliances are used in vSphere environments, while on vCloud Director environments Cloud Connect takes care of replication and registration of VMs while relying on VMware NSX technology for the networking part. For this reason, there is no networking design related to vCloud Director in this book.

VLANs

Veeam Cloud Connect guarantees multi-tenancy at the network level using VLANs.

Each port group created for any service provider is tagged with a unique VLAN ID so communications between port groups, VLANs and networks are only possible by traversing a network extension appliance and thus are regulated. Veeam Backup & Replication, upon creating a new network for a tenant, automatically creates a new port group on the selected virtual switch and sets a VLAN tag. The available VLAN IDs need to be configured in advance both in Veeam Cloud Connect:

4.11: Configure VLAN pool settings

In the example, the service provider has a vSphere cluster named VCCR Cluster. There is a distributed virtual switch named vcc-dvs, and VLANs 112 to 149 have been already configured in the hardware switches on the uplinks registered in the distributed switch. No routing has been configured between the VLANs so this property will be exclusively managed by Veeam network extension appliances.

Two settings control the way NAT is applied to VMs belonging to a given VLAN:

• “No Internet”/”With Internet” toggles Source NAT. VMs belonging to a VLAN “With Internet” can reach internet.
• “Public IP” setting enables Destination NAT. Both VMs belonging to “No Internet” and “With Internet” VLANs can be reached from internet if a Public IP publishing rule is created.

This two settings are independent from each other, so that service providers can satisfy different customers needs.

Public IPs

During a full failover, replicated VMs are powered on and need to be reached from the outside so that a tenant can consume their services. All communications happening in a failover are managed by Veeam network extension appliances; in order to be reached from internet and to allow failed over VMs to reach the internet, an NEA acts like a firewall or gateway. To do so it needs to have a public IP loaded on its external interface. Just like VLAN pools, public IPs are not manually assigned to each tenant; instead, whenever an additional public IP is needed, Veeam Cloud Connect uses one of the available IPs that have been pre-loaded into the configuration:

4.12: Public IP pre-loaded in Veeam Cloud Connect

Service providers can consume public IPs coming from different pools, as long as the external interface of an NEA is connected to the right VLAN where this public IP can be used.

Public IP’s or NAT-ed IP’s

When Veeam Cloud Connect v8 was first released, only backup services were available. For this solution to work, cloud gateways could have been published either loading public IPs directly in their network interfaces or using NAT (network address translation) technologies, cloud gateways were using non-public IP addresses, and an external component like a firewall would have published the TCP ports needed to expose cloud gateways to the public internet.

This is still the case for backup services in Veeam Cloud Connect v9, but in order to correctly publish replica resources, it is highly recommended to load public IPs on both cloud gateways and NEAs.

There are two main reasons to do so:

• Cloud gateways and NEAs need to be able to communicate during a partial failover. If one of the two is behind a NAT system, the NAT device itself hides the real IP of the device. However, because DNS resolution is also in place, a service provider needs to build a complicated solution to hack DNS in order to correctly resolve Veeam Cloud Connect resources via their NAT-ed IPs, instead of the real ones. Simply using public IPs with no NAT makes this configuration much easier.
• Tenants can execute a full failover by themselves by accessing the Veeam Cloud Connect Portal. When at least one public IP address mapping rule is created, a service running in a VM is published on the outside using one of the public IPs assigned on the external interface of the NEA. Actually, any IP would be usable in this situation, like in this example:

4.13: A public IP address mapping rule using a non-public IP address

The public IP address 198.51.100.3 is a special subnet dedicated to create documentation and examples, but it can be compared with an internal IP used in a DMZ network, like 192.168.0.3. None of these IPs are reachable over internet. If a tenant attempts a failover using this configuration at the service provider, the service provider itself will need an additional NAT rule to publish the internal IP used in the NEA by using an additional IP that is publicly routable, like 185.62.37.102.

The problem is that the customer can be confused because the Veeam Cloud Connect Portal suggests the user to reach his virtual machine over the IP address loaded in the NEA:

4.14: Failover plan using a non-public IP

This IP address (192.168.100.51) loaded in the NEA is not a public IP, and so the customer cannot reach his VM unless the service provider advises the tenant to use the public IP that for example a firewall is using to publish the NEA on the internet.

This scenario is a major complication in both the network design and the level of automation that can be possibly reached. The NEA is a hardened Linux system, exposing to the outside just the ports that the customer or tenant has configured in his failover plan. No additional protection or routing is needed on the external interface of the NEA. If a service provider desires to have additional control, he can deploy an external firewall working at L2 (Layer2) and thus be totally transparent to the network configuration of a NEA or use the firewall to also be the router of the NEA’s public IP.