diff --git a/doc/source/install-guide/configure-networking.rst b/doc/source/install-guide/configure-networking.rst index c1b2f8f632..3fec7b5782 100644 --- a/doc/source/install-guide/configure-networking.rst +++ b/doc/source/install-guide/configure-networking.rst @@ -1,5 +1,7 @@ `Home `_ OpenStack-Ansible Installation Guide +.. _network_configuration: + Configuring target host networking ---------------------------------- diff --git a/doc/source/install-guide/overview-hostnetworking.rst b/doc/source/install-guide/overview-hostnetworking.rst deleted file mode 100644 index d9252240fb..0000000000 --- a/doc/source/install-guide/overview-hostnetworking.rst +++ /dev/null @@ -1,123 +0,0 @@ -`Home `_ OpenStack-Ansible Installation Guide - -Host networking ---------------- - -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. - -OSA 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 relationship between physical interfaces, logical interfaces, -bridges, and virtual interfaces within containers is shown in -`Figure 1.2, "Network -components" `_. - -  - -**Figure 1.2. Network components** - -.. image:: figures/networkcomponents.png - -Target hosts can contain the following network bridges: - -- LXC internal ``lxcbr0``: - - - Mandatory (automatic). - - - Provides external (typically internet) connectivity to containers. - - - Automatically created and managed by LXC. Does not directly attach - to any physical or logical interfaces on the host because iptables - handle connectivity. Attaches to ``eth0`` in each container. - -- Container management ``br-mgmt``: - - - Mandatory. - - - 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. - -- Storage ``br-storage``: - - - Optional. - - - 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. - -- OpenStack Networking tunnel/overlay ``br-vxlan``: - - - Mandatory. - - - 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. - -- OpenStack Networking provider ``br-vlan``: - - - Mandatory. - - - 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. This interface can support flat - networks as well, though additional bridge configuration will be needed. - See more on `network configuration here `_ - - -`Figure 1.3, "Container network -architecture" `_ -provides a visual representation of network components for services in -containers. - - -**Figure 1.3. Container network architecture** - -.. image:: figures/networkarch-container-external.png - -By default, OSA installs the Compute service in a bare metal -environment rather than within a container. `Figure 1.4, "Bare/Metal -network -architecture" `_ -provides a visual representation of the unique layout of network -components on a Compute host. - -  - -**Figure 1.4. Bare/Metal network architecture** - -.. image:: figures/networkarch-bare-external.png - --------------- - -.. include:: navigation.txt diff --git a/doc/source/install-guide/overview-neutron.rst b/doc/source/install-guide/overview-neutron.rst deleted file mode 100644 index 1ec1e289f7..0000000000 --- a/doc/source/install-guide/overview-neutron.rst +++ /dev/null @@ -1,32 +0,0 @@ -`Home `_ OpenStack-Ansible Installation Guide - -OpenStack Networking --------------------- - -OpenStack Networking (neutron) is configured to use a DHCP agent, L3 -Agent and Linux Bridge agent within a networking agents container. -`Figure 1.5, "Networking agents -containers" `_ -shows the interaction of these agents, network components, and -connection to a physical network. - -  - -**Figure 1.5. Networking agents containers** - -.. image:: figures/networking-neutronagents.png - -The Compute service uses the KVM hypervisor. `Figure 1.6, "Compute -hosts" `_ shows -the interaction of instances, Linux Bridge agent, network components, -and connection to a physical network. - -  - -**Figure 1.6. Compute hosts** - -.. image:: figures/networking-compute.png - --------------- - -.. include:: navigation.txt diff --git a/doc/source/install-guide/overview.rst b/doc/source/install-guide/overview.rst index aac0b5d874..689d404d0a 100644 --- a/doc/source/install-guide/overview.rst +++ b/doc/source/install-guide/overview.rst @@ -9,8 +9,6 @@ Chapter 1. Overview overview-ansible.rst overview-lxc.rst overview-hostlayout.rst - overview-hostnetworking.rst - overview-neutron.rst overview-requirements.rst overview-workflow.rst overview-security.rst diff --git a/doc/source/install-guide/targethosts-network.rst b/doc/source/install-guide/targethosts-network.rst index 74ad842071..195f3119e9 100644 --- a/doc/source/install-guide/targethosts-network.rst +++ b/doc/source/install-guide/targethosts-network.rst @@ -3,6 +3,12 @@ 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 @@ -10,39 +16,154 @@ instructions use a reference architecture with example network interface names, networks, and IP addresses. Modify these values as needed for the particular environment. -The reference architecture for target hosts contains the following -mandatory components: +Bonded network interfaces +~~~~~~~~~~~~~~~~~~~~~~~~~ -- A ``bond0`` interface using two physical interfaces. For redundancy - purposes, avoid using more than one port on network interface cards - containing multiple ports. The example configuration uses ``eth0`` - and ``eth2``. Actual interface names can vary depending on hardware - and drivers. Configure the ``bond0`` interface with a static IP - address on the host management network. +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. -- A ``bond1`` interface using two physical interfaces. For redundancy - purposes, avoid using more than one port on network interface cards - containing multiple ports. The example configuration uses ``eth1`` - and ``eth3``. Actual interface names can vary depending on hardware - and drivers. Configure the ``bond1`` interface without an IP address. +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. -- Container management network subinterface on the ``bond0`` interface - and ``br-mgmt`` bridge with a static IP address. +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. -- The OpenStack Networking VXLAN subinterface on the ``bond1`` - interface and ``br-vxlan`` bridge with a static IP address. +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. -- The OpenStack Networking VLAN ``br-vlan`` bridge on the ``bond1`` - interface without an IP address. +Adding bridges +~~~~~~~~~~~~~~ -The reference architecture for target hosts can also contain the -following optional components: +The combination of containers and flexible deployment options requires +implementation of advanced Linux networking features such as bridges and +namespaces. -- Storage network subinterface on the ``bond0`` interface and - ``br-storage`` bridge with a static IP address. +*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 -For more information, see `OpenStack-Ansible -Networking `_. --------------