Appliance Network/VS Networking
The appliance Network in OnApp is used for VS networking only: it provides network connectivity for virtual servers.
OnApp will bridge the public NIC and assign virtual interfaces to it, when VSs are provisioned, and/or when additional network interfaces are added to VSs from the Web UI, or via the OnApp API. As the public interface is managed fully by OnApp, the public NIC requires a blank config - for example:
You should configure your network interface file accordingly. You will not need to add any configuration to this NIC, so no subnet, gateway or IP address details should be added.
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) so you should allow for this when you are designing your compute resource, as you must make sure you have a physical NIC available.
This network should be a minimum of 1Gbit. You should also consider bonding on the appliance network to introduce redundancy at the network level.
Configuring a switch trunk port is the preferred method, because it gives you additional flexibility and security. Alternatively, you can configure a switch access port. If this is the case, you will not need to specify a VLAN when adding the range to OnApp.
You'll need to connect your appliance Network to a switch trunk port, if you want to use VLANs. VLANs allow a network administrator to segregate traffic for bandwidth or security purposes.
If you choose to VLAN your VS networking, you'll need to associate your VLAN with the subnet when you add the VS networking range to OnApp.
Some hosting companies have limitations and the transfer of IP addresses between servers can sometimes require manual interventions - a change on their user portal, for example - so if you are leasing hosting server solutions, it is worth double-checking with your host that this will be possible.
OnApp standard deployment (XEN/KVM) requirements
This network is responsible for a couple of different tasks. It provides incoming and outgoing connectivity to the servers, which means the management network should always be the default gateway.
If you are going to use Cloud Boot, this should be a local network behind a gateway device, that is capable of bridging traffic to the Internet to allow the servers to perform tasks such as dns resolution, ntp updates and operating system updates. Also, you have to open the 5555 port for outgoing connections to the licensing server.
The control panel will need to have incoming traffic allowed to ports 80/443 & 30000->40000. This should again be configured at the gateway with incoming NAT. If your gateway device is not capable of supporting this , this network can also be an external network, but should always be firewalled at the gateway to block all incoming traffic, with the exception of the ports listed above.
The management network also serves as a route for communication between the control panel server and the compute resources for critical OnApp internal traffic. That means, the stability of this network is critical: you should always consider bonding to introduce network level redundancy, and the network should run at least 1Gbit.
If your management network is behind a firewall, please make sure that ports 22/80/5555/30000-40000 are open to the world for 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 it proxies over port 80 or 443.
OnApp and vCloud Director integration requirements
OnApp and vCloud connection is supported with RabbitMQ. OnApp CP connects to vCloud Director using REST API and requires outgoing connection to vCloud API interface via ports 80,443.
If RabbitMQ server, installed by OnApp by default, is used, incoming connection to port 5672 is required in management network. Also port 15672 is optional for RabbitMQ server management.
If external AMQP server is used, outgoing connection to RabbitMQ default port 5672 is required.
The provisioning network is used to transfer backup and template data between the provisioning server and the primary storage volumes.
The network will be used to transfer large amount of data, so we recommend that it runs at least 1Gbit. Ideally, you should consider 10Gbit, FibreChannel, InfiniBand or aggregated 1Gbit links for maximum throughput.
Provisioning network is not required for clouds using Integrated Storage with dedicated backup servers.
The storage network provides the connection between storage devices (e.g. SANs) and the compute resources.
The type of network will depend on what kind of connectivity your primary storage requires. For example, if you are using iSCSI or ATAoE, you will need to set up an ethernet network. If your SAN has fibre connectivity, then the storage network will be a fiber network.
The stability of the storage network is absolutely critical. You should always make redundancy your primary concern when designing this network. The Centralized Storage (SAN) section of this document discusses this in more detail.
- The storage network must be a local network.
- We recommend this network runs at 10 Gbit, at least; FibreChannel or InfiniBand to achieve maximum 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 1Gbit 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 the switch connecting the compute resources to the SAN supports jumbo frames: the storage network on the compute resources and the SAN(s) must have MTU set to 9000 to optimize performance.
Emulex hardware currently does not have support for 3.x Linux kernels, so is only compatible with CentOS 5.x
Now proceed to configuring storage.