Files

Matthew Kassawara 374a38f49a [install] Initial networking architecture changes

Implement initial networking architecture changes for Liberty
as follows:

1) Remove nova-network.
2) Develop architecture for provider networks with Linux
   bridge agent.
3) Develop architecture for self-service networks with
   Linux bridge agent.
4) Munge the neutron controller and network node configuration
   together.
5) Rejigger neutron to use the Linux bridge agent.
6) Restructure launch an instance content to account for
   two networking options.
7) Other restructuring as necessary to meet the primary
   goal.

For simplicity, both architectures require only two nodes,
each with two network interfaces, to deploy core OpenStack
services. Also, to address recurring issues about the lack
of support for connecting instances directly to the
public/external network, the self-service architecture
augments the provider networks architecture which allows
connection to both private and public networks.

Change-Id: Ie3ab9a15ebfe82c0ce54f709c87a66d7cc46db3f
Implements: blueprint installguide-liberty

2015-09-22 10:59:55 -05:00

11 KiB

Raw Blame History

Host Networking

ubuntu

After installing the operating system on each node for the architecture that you choose to deploy, you must configure the network interfaces. We recommend that you disable any automated network management tools and manually edit the appropriate configuration files for your distribution. For more information on how to configure networking on your distribution, see the documentation .

debian

rdo

obs

All nodes require Internet access for administrative purposes such as package installation, security updates, DNS, and NTP. In most cases, nodes should obtain internet access through the management network interface. To highlight the importance of network separation, the example architectures use private address space for the management network and assume that the physical network infrastructure provides Internet access via NAT or other method. The example architectures use routable IP address space for the public network and assume that the physical network infrastructure provides direct Internet access. In the provider networks architecture, all instances attach directly to the public network. In the self-service networks architecture, instances can attach to a private or public network. Private networks can reside entirely within OpenStack or provide some level of public network access using NAT.

The example architectures assume use of the following networks:

Management on 10.0.0.0/24 with gateway 10.0.0.1

Note

This network requires a gateway to provide Internet access to all nodes for administrative purposes such as package installation, security updates, DNS, and NTP.
Public on 203.0.113.0/24 with gateway 203.0.113.1

Note

This network requires a gateway to provide Internet access to instances in your OpenStack environment.

You can modify these ranges and gateways to work with your particular network infrastructure.

Note

Network interface names vary by distribution. Traditionally, interfaces use "eth" followed by a sequential number. To cover all variations, this guide simply refers to the first interface as the interface with the lowest number and the second interface as the interface with the highest number.

Unless you intend to use the exact configuration provided in this example architecture, you must modify the networks in this procedure to match your environment. Also, each node must resolve the other nodes by name in addition to IP address. For example, the controller name must resolve to 10.0.0.11, the IP address of the management interface on the controller node.

Warning

Reconfiguring network interfaces will interrupt network connectivity. We recommend using a local terminal session for these procedures.

Controller node

Configure networking

Configure the first interface as the management interface:

IP address: 10.0.0.11

Network mask: 255.255.255.0 (or /24)

Default gateway: 10.0.0.1
Reboot the system to activate the changes.

Configure name resolution

Set the hostname of the node to controller.
Edit the /etc/hosts file to contain the following:
```
# controller
10.0.0.11       controller

# compute1
10.0.0.31       compute1
```
Warning

Some distributions add an extraneous entry in the /etc/hosts file that resolves the actual hostname to another loopback IP address such as 127.0.1.1. You must commend out or remove this entry to prevent name resolution problems. Do not remove the ``127.0.0.1`` entry.

Compute node

Configure networking

Configure the first interface as the management interface:

IP address: 10.0.0.31

Network mask: 255.255.255.0 (or /24)

Default gateway: 10.0.0.1

Note

Additional compute nodes should use 10.0.0.32, 10.0.0.33, and so on.
The public interface uses a special configuration without an IP address assigned to it. Configure the second interface as the public interface:

Replace INTERFACE_NAME with the actual interface name. For example, eth1 or ens224.
ubuntu or debian
1. Edit the /etc/network/interfaces file to contain the following:
```
# The public network interface
auto INTERFACE_NAME
iface  INTERFACE_NAME inet manual
up ip link set dev $IFACE up
down ip link set dev $IFACE down
```
rdo
1. Edit the /etc/sysconfig/network-scripts/ifcfg-INTERFACE_NAME file to contain the following:
  
  Do not change the HWADDR and UUID keys.
```
DEVICE=INTERFACE_NAME
TYPE=Ethernet
ONBOOT="yes"
BOOTPROTO="none"
```
obs
1. Edit the /etc/sysconfig/network/ifcfg-INTERFACE_NAME file to contain the following:
```
STARTMODE='auto'
BOOTPROTO='static'
```
Reboot the system to activate the changes.

Configure name resolution

Set the hostname of the node to compute1.
Edit the /etc/hosts file to contain the following:
```
# controller
10.0.0.11       controller

# compute1
10.0.0.31       compute1
```
Warning

Some distributions add an extraneous entry in the /etc/hosts file that resolves the actual hostname to another loopback IP address such as 127.0.1.1. You must commend out or remove this entry to prevent name resolution problems. Do not remove the ``127.0.0.1`` entry.

Verify connectivity

We recommend that you verify network connectivity to the Internet and among the nodes before proceeding further.

From the controller node, test access to the Internet:

# ping -c 4 openstack.org
PING openstack.org (174.143.194.225) 56(84) bytes of data.
64 bytes from 174.143.194.225: icmp_seq=1 ttl=54 time=18.3 ms
64 bytes from 174.143.194.225: icmp_seq=2 ttl=54 time=17.5 ms
64 bytes from 174.143.194.225: icmp_seq=3 ttl=54 time=17.5 ms
64 bytes from 174.143.194.225: icmp_seq=4 ttl=54 time=17.4 ms

--- openstack.org ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3022ms
rtt min/avg/max/mdev = 17.489/17.715/18.346/0.364 ms

From the controller node, test access to the management interface on the compute node:

# ping -c 4 compute1
PING compute1 (10.0.0.31) 56(84) bytes of data.
64 bytes from compute1 (10.0.0.31): icmp_seq=1 ttl=64 time=0.263 ms
64 bytes from compute1 (10.0.0.31): icmp_seq=2 ttl=64 time=0.202 ms
64 bytes from compute1 (10.0.0.31): icmp_seq=3 ttl=64 time=0.203 ms
64 bytes from compute1 (10.0.0.31): icmp_seq=4 ttl=64 time=0.202 ms

--- compute1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.202/0.217/0.263/0.030 ms

From the compute node, test access to the Internet:

# ping -c 4 openstack.org
PING openstack.org (174.143.194.225) 56(84) bytes of data.
64 bytes from 174.143.194.225: icmp_seq=1 ttl=54 time=18.3 ms
64 bytes from 174.143.194.225: icmp_seq=2 ttl=54 time=17.5 ms
64 bytes from 174.143.194.225: icmp_seq=3 ttl=54 time=17.5 ms
64 bytes from 174.143.194.225: icmp_seq=4 ttl=54 time=17.4 ms

--- openstack.org ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3022ms
rtt min/avg/max/mdev = 17.489/17.715/18.346/0.364 ms

From the compute node, test access to the management interface on the controller node:

# ping -c 4 controller
PING controller (10.0.0.11) 56(84) bytes of data.
64 bytes from controller (10.0.0.11): icmp_seq=1 ttl=64 time=0.263 ms
64 bytes from controller (10.0.0.11): icmp_seq=2 ttl=64 time=0.202 ms
64 bytes from controller (10.0.0.11): icmp_seq=3 ttl=64 time=0.203 ms
64 bytes from controller (10.0.0.11): icmp_seq=4 ttl=64 time=0.202 ms

--- controller ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.202/0.217/0.263/0.030 ms

Note

rdo or obs

Your distribution enables a restrictive firewall by default. During the installation process, certain steps will fail unless you alter or disable the firewall. For more information about securing your environment, refer to the OpenStack Security Guide.

ubuntu or debian

Your distribution does not enable a restrictive firewall by default. For more information about securing your environment, refer to the OpenStack Security Guide.

11 KiB Raw Blame History

Host Networking

Controller node

Configure networking

Configure name resolution

Compute node

Configure networking

Configure name resolution

Verify connectivity

11 KiB

Raw Blame History