=====================
Network connectivity
=====================

The selected server hardware must have the appropriate number of
network connections, as well as the right type of network
connections, in order to support the proposed architecture. Ensure
that, at a minimum, there are at least two diverse network
connections coming into each rack.

The selection of form factors or architectures affects the selection of
server hardware. Ensure that the selected server hardware is configured
to support enough storage capacity (or storage expandability) to match
the requirements of selected scale-out storage solution. Similarly, the
network architecture impacts the server hardware selection and vice
versa.

=====================
Network connectivity
=====================

The selected server hardware must have the appropriate number of network
connections, as well as the right type of network connections, in order to
support the proposed architecture. Ensure that, at a minimum, there are at
least two diverse network connections coming into each rack.

The selection of form factors or architectures affects the selection of server
hardware. Ensure that the selected server hardware is configured to support
enough storage capacity (or storage expandability) to match the requirements of
selected scale-out storage solution. Similarly, the network architecture
impacts the server hardware selection and vice versa.

While each enterprise install is different, the following networks with their
proposed bandwidth is highly recommended for a basic production OpenStack
install.

**Install or OOB network** - Typically used by most distributions and
provisioning tools as the network for deploying base software to the
OpenStack compute nodes. This network should be connected at a minimum of 1Gb
and no routing is usually needed.

**Internal or Management network** - Used as the internal communication network
between OpenStack compute and control nodes. Can also be used as a network
for iSCSI communication between the compute and iSCSI storage nodes. Again,
this should be a minimum of a 1Gb NIC and should be a non-routed network. This
interface should be redundant for high availability (HA).

**Tenant network** - A private network that enables communication between each
tenant's instances. If using flat networking and provider networks, this
network is optional. This network should also be isolated from all other
networks for security compliance. A 1Gb interface should be sufficient and
redundant for HA.

**Storage network** - A private network which could be connected to the Ceph
frontend or other shared storage. For HA purposes this should be a redundant
configuration with suggested 10Gb NICs. This network isolates the storage for
the instances away from other networks. Under load, this storage traffic
could overwhelm other networks and cause outages on other OpenStack services.

**(Optional) External or Public network** - This network is used to communicate
externally from the VMs to the public network space. These addresses are
typically handled by the neutron agent on the controller nodes and can also
be handled by a SDN other than neutron. However, when using neutron DVR with
OVS, this network must be present on the compute node since north and south
traffic will not be handled by the controller nodes, but by the compute node
itself. For more information on DVR with OVS and compute nodes, see `Scenario:
High Availability using Distributed Virtual Routing (DVR) <http://docs.openstack.org/mitaka/networking-guide/scenario-dvr-ovs.html>`_

Update Network Section of Compute
[arch-guide] Update Network Section of Compute

New network recommendations
New interface recommendations

Change-Id: I2054d3c59cfb8edb50ce3ebe903c3a7aaa62ddbf
Implements: blueprint arch-guide-restructure
