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
6.7 KiB
Home 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:
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
eth0in each container, but the container network interface is configurable inopenstack_user_config.ymlin theprovider_networksdictionary.
- 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
bond0VLAN subinterface. Also attaches toeth1in each container. As mentioned earlier, the container network interface is configurable inopenstack_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
bond0VLAN subinterface. Also attaches toeth2in each associated container. As mentioned earlier, the container network interface is configurable inopenstack_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
bond1VLAN subinterface. Also attaches toeth10in each associated container. As mentioned earlier, the container network interface is configurable inopenstack_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 toeth11for 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 inopenstack_user_config.yml. - This interface can support flat networks as well, though additional
bridge configuration will be needed. More details are available here:
network_configuration.
Network diagrams
The following image shows how all of the interfaces and bridges interconnect to provide network connectivity to the OpenStack deployment:
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:
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:
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:




