Networking

An OnApp Cloud installation requires four separate networks that are Management, Appliance, Storage, and Provisioning network. If you plan to use OnApp Integrated Storage, you don't need to set up the Provisioning network.

The networks should be separated either physically, using different switches, or with VLANs. If you experience MAC address flapping across ports because a switch does not support the balance-rr mode, you can set up separated VLANs per each bond pair for the switch. 

The following scheme illustrates how networks handle your cloud environment. For more details on the role and configuration of each network, see the sections below. 

On this page:

Management Network

Appliance Network

Storage Network

Provisioning Network

External Network Connectivity

See also:

Required Ports

Storage

Servers

ISOs

OVAs

Management Network

The Management network serves as a route for communication between the Control Panel server, compute resources and backup servers. The management network should always be a default gateway. If you deploy CloudBoot compute resources, the Control Panel server automatically assigns management network IP addresses via the internal DHCP server to compute resources and backup servers. 

The Management network should be a local network behind a gateway device that is capable of bridging traffic to the Internet to allow servers to perform tasks such as DNS resolution, NTP and operating system updates. If the gateway has a DHCP service for allocating private IP addresses, this service must be disabled.

You have to open the 443 port for outgoing connections to the OnApp Licensing Server. The Control Panel server needs to have incoming traffic allowed to ports 80/443 & 30000->40000. This should be configured at the gateway with incoming NAT. If your gateway device doesn't support it, a network can also be an external network. However, you should always use firewall at the gateway to block all incoming traffic except for the ports listed above.

Since the Management network serves as a route for communication between the Control Panel server, compute resources and backup servers, the stability of this network is critical. You should always consider bonding to introduce the network level redundancy and the network bandwidth should be at least 1 Gbit.

If your management network is behind a firewall, please make sure that ports 22/80/443/30000-40000 are open to the Control Panel server and port 22 for all other servers. The 30000-40000 ports are not required if you are going to use HTML5 console as the console proxies over port 80 or 443.

OnApp and vCloud Director Integration Requirements

OnApp and vCloud connection is supported by RabbitMQ. OnApp Control Panel connects to vCloud Director using REST API and requires an outgoing connection to vCloud API interface via ports 80 and 443. By default, the RabbitMQ server is installed by OnApp and the Management network requires an incoming connection to port 5672. The port 15672 is optional for the RabbitMQ server management. If external AMQP server is used, an outgoing connection to the RabbitMQ default port 5672 is required.

Appliance Network

The Appliance network is used for all virtual servers network traffic. OnApp bridges the appliance NIC and assigns virtual interfaces to it when virtual servers are provisioned, or when additional network interfaces are added to virtual servers via OnApp UI or API. Since the public interface is managed by OnApp, the public NIC requires a blank config. 

/etc/sysconfig/network-scripts/ifcfg-ethX
ONBOOT=no
BOOTPROTO=none

You should configure your network interface file accordingly. You don't need to add any configurations to this NIC, such as subnet, gateway or IP address details. The NIC could either be a standard physical interface (e.g. eth1) or a bonded interface (e.g. bond1). It cannot be a sub-interface (e.g. eth1:1) or a VLAN sub-interface (e.g. eth1.101). Take it into consideration when you design your compute resources to make sure you have a physical NIC available. The Appliance network bandwidth should be at least 1 Gbit. You should also consider bonding on the Appliance network to introduce redundancy at the network level. 

Configuring a switch trunk port is a preferred method because it gives you additional flexibility and security. Alternatively, you can configure a switch access port. In the latter case, you don't need to specify a VLAN when adding a range to OnApp. To be able to use multiple appliance VLANs, connect your Appliance network to switch ports that are configured in a VLAN trunk mode. This provides your cloud with flexibility to offer private VLANs to users in future. If you choose multiple appliance VLANs, you need to associate your VLAN with a subnet when you add a range to OnApp.

SDN Network

Software-defined networking (SDN) provides the ability to manage networks using VXLAN technology across OnApp cloud compute resources. Thus, you receive a tool to build a level-two network infrastructure with OnApp on top of the existing IP (level three) network. SDN networks belong to appliance networks. 

You may consider the following points before the creation of SDN networks:

• OnApp requires Carbon 0.6.2 ODL controller version.
• ODL controller should be accessible from Control Panel with SDN manager host:port and from compute resources with selected connection options (tcp:ip_address:port)
• The SDN network creation is currently supported only on KVM compute resources.
• You will need to ensure the connection via IPs between the compute resources: configure an IP address to use for tunneling traffic over VXLAN to the other nodes.
• Ensure there is a connection option to connect a compute resource to OpenDayLight Controller. You may refer to the Install OpenDayLight Controller guide to check the existing hardware requirements to install OpenDayLight server. 
• Control Panel should be able to connect to the ODL controller using host, port, login, and password (it is possible with OnApp Cloud).
• Since VXLAN adds 50 to 54 bytes of additional header information to the original Ethernet frame, you might want to increase the maximum transmission unit (MTU) of the underlying NIC on the corresponding compute resource.

Storage Network

The Storage network enables a connection between storage devices (e.g. SANs) and compute resources. The type of a network depends on which kind of connectivity your primary storage requires. For example, if you use iSCSI or ATAoE, you need to set up an Ethernet network. If your SAN has fibre connectivity, then the storage network is a fiber network. 

The stability of the Storage network is absolutely critical. You should always make redundancy your primary concern when designing this network. See the Centralized Storage (SAN) section for more details. 

There are the following requirements to the Storage network that you need to follow: 

• The Storage network must be a local network.
• The Storage network should run at least 10 Gbit FibreChannel or InfiniBand to achieve the best performance.
• We strongly recommend that you avoid NICs using Broadcom chipsets on the Storage network due to known issues surrounding iSCSI and TCP offload in the Linux kernel modules. 
• To achieve better performance and redundancy over 1 Gbit, you should consider NIC teaming/bonding and LACP or MPIO over multiple subnets.
• If your primary Storage network is running over Ethernet, then it is important that a switch connecting compute resources to SAN supports jumbo frames: the Storage network on compute resources and SAN(s) must have MTU set to 9000 to optimize performance.

Provisioning Network

The Provisioning network is used to transfer backup and template data between the provisioning server and the primary storage volumes. The network is used to transfer large sets of data, so we recommend that it runs at least 1 Gbit. It is more preferable for you to consider 10Gbit, FibreChannel, InfiniBand or aggregated 1 Gbit links for maximum throughput. The Provisioning network is not required for clouds that run OnApp Integrated Storage with dedicated backup servers. However, without a provisioning network, all migration traffic will use the management network.

External Network Connectivity

The following table provides an overview of communications between the OnApp Control Panel server and external networks.