10c600ae44
This centralizes the network documentation and explanations into one place that the deployer is more likely to see as they start a deployment. Change-Id: Ie9765ccb47e65e7eedb73da567bc6d0147b25f38
171 lines
6.7 KiB
ReStructuredText
171 lines
6.7 KiB
ReStructuredText
`Home <index.html>`_ OpenStack-Ansible Installation Guide
|
|
|
|
Configuring the network
|
|
-----------------------
|
|
|
|
This documentation section describes a recommended reference architecture.
|
|
Some components are mandatory, such as the bridges described below. Other
|
|
components aren't required but are strongly recommended, such as the bonded
|
|
network interfaces. Deployers are strongly urged to follow the reference
|
|
design as closely as possible for production deployments.
|
|
|
|
Although Ansible automates most deployment operations, networking on
|
|
target hosts requires manual configuration because it can vary
|
|
dramatically per environment. For demonstration purposes, these
|
|
instructions use a reference architecture with example network interface
|
|
names, networks, and IP addresses. Modify these values as needed for the
|
|
particular environment.
|
|
|
|
Bonded network interfaces
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The reference architecture includes bonded network interfaces, which
|
|
use multiple physical network interfaces for better redundancy and throughput.
|
|
Avoid using two ports on the same multi-port network card for the same bonded
|
|
interface since a network card failure would affect both physical network
|
|
interfaces used by the bond.
|
|
|
|
The ``bond0`` interface will carry the traffic from the containers that
|
|
run the OpenStack infrastructure. Configure a static IP address on the
|
|
``bond0`` interface from your management network.
|
|
|
|
The ``bond1`` interface will carry the traffic from your virtual machines.
|
|
Don't configure a static IP on this interface since this bond will be used by
|
|
neutron to handle VLAN and VXLAN networks for virtual machines.
|
|
|
|
Additional bridge networks are required for OpenStack-Ansible and those bridges
|
|
will be connected to these two bonded network interfaces. See the following
|
|
section for the bridge configuration.
|
|
|
|
Adding bridges
|
|
~~~~~~~~~~~~~~
|
|
|
|
The combination of containers and flexible deployment options requires
|
|
implementation of advanced Linux networking features such as bridges and
|
|
namespaces.
|
|
|
|
*Bridges* provide layer 2 connectivity (similar to switches) among
|
|
physical, logical, and virtual network interfaces within a host. After
|
|
creating a bridge, the network interfaces are virtually "plugged in" to
|
|
it.
|
|
|
|
OpenStack-Ansible uses bridges to connect physical and logical network
|
|
interfaces on the host to virtual network interfaces within containers.
|
|
|
|
*Namespaces* provide logically separate layer 3 environments (similar to
|
|
routers) within a host. Namespaces use virtual interfaces to connect
|
|
with other namespaces, including the host namespace. These interfaces,
|
|
often called ``veth`` pairs, are virtually "plugged in" between
|
|
namespaces similar to patch cables connecting physical devices such as
|
|
switches and routers.
|
|
|
|
Each container has a namespace that connects to the host namespace with
|
|
one or more ``veth`` pairs. Unless specified, the system generates
|
|
random names for ``veth`` pairs.
|
|
|
|
The following image demonstrates how the container network interfaces are
|
|
connected to the host's bridges and to the host's physical network interfaces:
|
|
|
|
.. image:: figures/networkcomponents.png
|
|
|
|
Target hosts can contain the following network bridges:
|
|
|
|
- LXC internal ``lxcbr0``:
|
|
|
|
- This bridge is **required**, but LXC will configure it automatically.
|
|
|
|
- Provides external (typically internet) connectivity to containers.
|
|
|
|
- This bridge does not directly attach to any physical or logical
|
|
interfaces on the host because iptables handles connectivity. It
|
|
attaches to ``eth0`` in each container, but the container network
|
|
interface is configurable in ``openstack_user_config.yml`` in the
|
|
``provider_networks`` dictionary.
|
|
|
|
- Container management ``br-mgmt``:
|
|
|
|
- This bridge is **required**.
|
|
|
|
- Provides management of and communication among infrastructure and
|
|
OpenStack services.
|
|
|
|
- Manually created and attaches to a physical or logical interface,
|
|
typically a ``bond0`` VLAN subinterface. Also attaches to ``eth1``
|
|
in each container. As mentioned earlier, the container network interface
|
|
is configurable in ``openstack_user_config.yml``.
|
|
|
|
- Storage ``br-storage``:
|
|
|
|
- This bridge is *optional*, but recommended.
|
|
|
|
- Provides segregated access to block storage devices between
|
|
Compute and Block Storage hosts.
|
|
|
|
- Manually created and attaches to a physical or logical interface,
|
|
typically a ``bond0`` VLAN subinterface. Also attaches to ``eth2``
|
|
in each associated container. As mentioned earlier, the container network
|
|
interface is configurable in ``openstack_user_config.yml``.
|
|
|
|
- OpenStack Networking tunnel/overlay ``br-vxlan``:
|
|
|
|
- This bridge is **required**.
|
|
|
|
- Provides infrastructure for VXLAN tunnel/overlay networks.
|
|
|
|
- Manually created and attaches to a physical or logical interface,
|
|
typically a ``bond1`` VLAN subinterface. Also attaches to
|
|
``eth10`` in each associated container. As mentioned earlier, the
|
|
container network interface is configurable in
|
|
``openstack_user_config.yml``.
|
|
|
|
- OpenStack Networking provider ``br-vlan``:
|
|
|
|
- This bridge is **required**.
|
|
|
|
- Provides infrastructure for VLAN networks.
|
|
|
|
- Manually created and attaches to a physical or logical interface,
|
|
typically ``bond1``. Attaches to ``eth11`` for vlan type networks
|
|
in each associated container. It does not contain an IP address because
|
|
it only handles layer 2 connectivity. As mentioned earlier, the
|
|
container network interface is configurable in
|
|
``openstack_user_config.yml``.
|
|
|
|
- This interface can support flat networks as well, though additional
|
|
bridge configuration will be needed. More details are available here:
|
|
:ref:`network_configuration`.
|
|
|
|
|
|
Network diagrams
|
|
~~~~~~~~~~~~~~~~
|
|
|
|
The following image shows how all of the interfaces and bridges interconnect
|
|
to provide network connectivity to the OpenStack deployment:
|
|
|
|
.. image:: figures/networkarch-container-external.png
|
|
|
|
OpenStack-Ansible deploys the compute service on the physical host rather than
|
|
in a container. The following image shows how the bridges are used for
|
|
network connectivity:
|
|
|
|
.. image:: figures/networkarch-bare-external.png
|
|
|
|
The following image shows how the neutron agents work with the bridges
|
|
``br-vlan`` and ``br-vxlan``. As a reminder, OpenStack Networking (neutron) is
|
|
configured to use a DHCP agent, L3 agent and Linux Bridge agent within a
|
|
``networking-agents`` container. You can see how the DHCP agents can provide
|
|
information (IP addresses and DNS servers) to the instances, but also how
|
|
routing works on the image:
|
|
|
|
.. image:: figures/networking-neutronagents.png
|
|
|
|
The following image shows how virtual machines connect to the ``br-vlan`` and
|
|
``br-vxlan`` bridges and send traffic to the network outside the host:
|
|
|
|
.. image:: figures/networking-compute.png
|
|
|
|
|
|
--------------
|
|
|
|
.. include:: navigation.txt
|