External compute node can´t communicate with controller node

asked 2018-11-29 08:02:40 -0600

jferhid gravatar image

We are trying to deploy a simple system with Devstack Queens on two servers (baremetal). Our infra people have connected the two servers as displayed in the attached network diagram. (https://ibb.co/3vBkvHM) One of the servers will host the openstack controller and one compute node. The second server will be used to host another compute node. Our goal is to give the controller the possibility to choose where to deploy instances.

So far, we managed to install the controller and compute node in the first machine and compute in the second.

On the controller machine, apparently everything seems to be working. We are able to create instances, we can ping outside and are able to assign floating ips to them. Also if we create instances in the same compute node, we can ping from one to another both ways.

But then, on the other side of the coin, when we look at the second compute node, we can instantiate vms on that compute, but we can´t get them to communicate with the controller. We have noticed that if we deploy vms inside that compute, they can ping each other, but if we try to ping the gateway in that network, they can’t.

Note that when deploying compute node and discovering hosts on controller node, a patch between br-tun on both servers is created (see ovs-vsctl info appended). Though, no packet is using told path since br-tun always drops any input packet. Therefore, br-ex is the logical output preference to communicate between computes but as seen in figure, there is no connection between br-ex and Interface enp12s0.

Since we are deploying a provider network scenario, which packet flow between computes should we expect? Through br-ex(Compute External) -> Switch -> br-ex(Compute on Controller) or br-tun (Compute External) -> br-tun (Compute on Controller)

We are probably missing something somewhere. We are not trying to do anything complicated. So any help would be really appreciated.

Attached here some of the conf files:

local.conf from the controller

 [[local|localrc]]
# PASSWORDS
ADMIN_PASSWORD=*******
DATABASE_PASSWORD=supersecret
RABBIT_PASSWORD=$DATABASE_PASSWORD
SERVICE_PASSWORD=$DATABASE_PASSWORD

# HOST_IP: API endpoint host, use own public IP so endpoint can be reached from outside.
HOST_IP=XX.YY.40.124
# SERVICE_HOST: Pointer to Controller @IP
SERVICE_HOST=$HOST_IP

MULTI_HOST=1
RECLONE=True

# Logging
LOGFILE=$DEST/logs/stack.sh.log
LOGDAYS=2
VERBOSE=True
LOG_COLOR=True
SCREEN_LOGDIR=$DEST/logs

## Neutron options
Q_USE_SECGROUP=True
PUBLIC_INTERFACE=enp132s0f1
NEUTRON_CREATE_INITIAL_NETWORKS=False
# Open vSwitch provider networking configuration
OVS_PHYSICAL_BRIDGE=br-ex

Q_ML2_TENANT_NETWORK_TYPE=vlan
Q_ML2_PLUGIN_TYPE_DRIVERS=flat,vlan,vxlan
PHYSICAL_NETWORK=default
ENABLE_TENANT_VLANS=True
TENANT_VLAN_RANGE=1200:1220

# Prevent long lockout
KEYSTONE_LOCKOUT_FAILURE_ATTEMPTS=10
KEYSTONE_LOCKOUT_DURATION=2

# Fix incompatibility: tunnel_types starting as gre by default
[[post-config|/$Q_PLUGIN_CONF_FILE]]
[agent]
tunnel_types=vxlan

Local.conf from the compute node

[[local|localrc]]
# PASSWORDS
ADMIN_PASSWORD=********
DATABASE_PASSWORD=supersecret
RABBIT_PASSWORD=$DATABASE_PASSWORD
SERVICE_PASSWORD=$DATABASE_PASSWORD

# HOST_IP: API endpoint host, use own public IP so endpoint can be reached from outside.
HOST_IP=XX.YY.40.75
# SERVICE_HOST: Pointer to Controller @IP
SERVICE_HOST=XX.YY.40.124

MULTI_HOST=1
RECLONE=True

# Logging
LOGFILE=$DEST/logs/stack.sh.log
LOGDAYS=2 ...
(more)
edit retag flag offensive close merge delete

Comments

Why Devstack? It’s designed to be set up automatically in a virtual machine for CI testing, then torn down. I would not use it for a serious installation.

Instructions for multinode Devstack setup (with a single interface per host): https://assafmuller.com/2015/04/06/mu....

Bernd Bausch gravatar imageBernd Bausch ( 2018-11-29 08:34:50 -0600 )edit

The same blog also has a great overview of the traffic flow, though a bit old: https://assafmuller.com/2015/04/15/di...

Bernd Bausch gravatar imageBernd Bausch ( 2018-11-29 08:36:10 -0600 )edit

Thanks for the answers and the links. We are using devstack because we are more on the research than on deploying a production environment. Our goal was to start with a provider network and later on move to the DVR which offers lots of advantages, but increases the difficulty a notch.

jferhid gravatar imagejferhid ( 2018-11-29 10:10:56 -0600 )edit

In any case, do you think our system will work without the DVR deployment? We think we are very close, but there is something that probably escapes from us and makes the packages to be dropped. Any idea where should we look?

jferhid gravatar imagejferhid ( 2018-11-29 10:11:19 -0600 )edit

I am not that good at reading complex local.conf files. I can't tell you what's wrong.

The openvswitch agent config files on controller and compute may provide a clue. It is there that Neutron provider networks are mapped to the physical network infrastructure. It's easy to get this wrong.

Bernd Bausch gravatar imageBernd Bausch ( 2018-11-29 22:03:45 -0600 )edit