【问题标题】:OpenStack multi-node network configuration on UbuntuUbuntu 上的 OpenStack 多节点网络配置
【发布时间】:2018-09-25 20:43:18
【问题描述】:

我正在尝试通过 devstack 设置一个简单的 2 节点部署。我遵循了多节点实验室和“Using devstack with Neutron”指南。我在后者方面取得了最大的进步。但是,我似乎仍然无法与在我的仅计算节点上运行的实例进行通信。在控制器/计算节点上运行的实例看起来不错。我可以从我办公室的任何机器上 ping/ssh 到他们。

我的环境:2 台 ubuntu 18.04 裸机服务器,带有分配 DHCP 地址的路由器的专用网络(我留出了一小部分地址)。我禁用了 Ubuntu NetworkManager 并通过 /etc/network/interfaces 中的 ifupdown 进行配置:

auto enp0s31f6
iface enp0s31f6 inet static
    address 192.168.7.170
    netmask 255.255.255.0
    gateway 192.168.7.254
    multicast 192.168.7.255
    dns-nameservers 8.8.8.8 8.8.4.4

controller/compute node local.conf按照指南配置:

[[local|localrc]]

HOST_IP=192.168.7.170
SERVICE_HOST=192.168.7.170
MYSQL_HOST=192.168.7.170
RABBIT_HOST=192.168.7.170
GLANCE_HOSTPORT=192.168.7.170:9292
DATABASE_PASSWORD=Passw0rd
RABBIT_PASSWORD=Passw0rd
SERVICE_PASSWORD=Passw0rd
ADMIN_PASSWORD=Passw0rd

LOGFILE=/opt/stack/logs/stack.sh.log

## Neutron options
Q_USE_SECGROUP=True
FLOATING_RANGE="192.168.7.0/24"
IPV4_ADDRS_SAFE_TO_USE="10.0.0.0/22"
Q_FLOATING_ALLOCATION_POOL=start=192.168.7.249,end=192.168.7.253
PUBLIC_NETWORK_GATEWAY="192.168.7.254"
PUBLIC_INTERFACE=enp0s31f6

# Open vSwitch provider networking configuration
Q_USE_PROVIDERNET_FOR_PUBLIC=True
Q_ASSIGN_GATEWAY_TO_PUBLIC_BRIDGE=False
OVS_PHYSICAL_BRIDGE=br-ex
PUBLIC_BRIDGE=br-ex
OVS_BRIDGE_MAPPINGS=public:br-ex

唯一的区别在于 Q_ASSIGN_GATEWAY_TO_PUBLIC_BRIDGE。我发现如果我没有设置这个,我会在服务器上看到很多数据包丢失。我不明白为什么网关会作为辅助地址添加到 vSwitch。

我注意到的另一个奇怪之处是,一旦设置了 OVS 新娘并将我的公共接口添加为端口,网络网关就不再用作 DNS 服务器。如果我用谷歌就可以了。

在我有 local.conf 的仅计算节点上:

[[local|localrc]]

HOST_IP=192.168.7.172
LOGFILE=/opt/stack/logs/stack.sh.log

SERVICE_HOST=192.168.7.170
MYSQL_HOST=$SERVICE_HOST
RABBIT_HOST=$SERVICE_HOST
GLANCE_HOSTPORT=$SERVICE_HOST:9292

ADMIN_PASSWORD=Passw0rd
DATABASE_PASSWORD=Passw0rd
RABBIT_PASSWORD=Passw0rd
SERVICE_PASSWORD=Passw0rd

PUBLIC_INTERFACE=enp0s31f6
ENABLED_SERVICES=n-cpu,rabbit,q-agt,placement-client

我在控制器/计算节点上运行 stack.sh,然后是仅计算节点。安装看起来不错。我可以设置安全组、ssh 密钥对等并启动实例。我为每个和关联分配浮动 IP。地址按预期来自池。我可以看到使用 OVS 在每个节点上设置的隧道:

controller$ sudo ovs-vsctl show
1cc8a95d-660d-453f-9772-02393adc2031
    Manager "ptcp:6640:127.0.0.1"
        is_connected: true
    Bridge br-tun
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        Port br-tun
            Interface br-tun
                type: internal
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}
        Port "vxlan-c0a807ac"
            Interface "vxlan-c0a807ac"
                type: vxlan
                options: {df_default="true", in_key=flow, local_ip="192.168.7.170", out_key=flow, remote_ip="192.168.7.172"}
    Bridge br-ex
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        Port br-ex
            Interface br-ex
                type: internal
        Port phy-br-ex
            Interface phy-br-ex
                type: patch
                options: {peer=int-br-ex}
        Port "enp0s31f6"
            Interface "enp0s31f6"
    Bridge br-int
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        Port "qg-7db4efa8-8f"
            tag: 2
            Interface "qg-7db4efa8-8f"
                type: internal
        Port "tap88eb8a36-86"
            tag: 1
            Interface "tap88eb8a36-86"
                type: internal
        Port patch-tun
            Interface patch-tun
                type: patch
                options: {peer=patch-int}
        Port int-br-ex
            Interface int-br-ex
                type: patch
                options: {peer=phy-br-ex}
        Port br-int
            Interface br-int
                type: internal
        Port "qr-e0e43871-2d"
            tag: 1
            Interface "qr-e0e43871-2d"
                type: internal
        Port "qvo5a54876d-0c"
            tag: 1
            Interface "qvo5a54876d-0c"
        Port "qr-9452dacf-82"
            tag: 1
            Interface "qr-9452dacf-82"
                type: internal
    ovs_version: "2.8.1"

在仅计算节点上:

compute$ sudo ovs-vsctl show
c817878d-7127-4d17-9a69-4ff296adc157
    Manager "ptcp:6640:127.0.0.1"
        is_connected: true
    Bridge br-int
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        Port "qvo1b56a018-10"
            tag: 1
            Interface "qvo1b56a018-10"
        Port patch-tun
            Interface patch-tun
                type: patch
                options: {peer=patch-int}
        Port br-int
            Interface br-int
                type: internal
        Port int-br-ex
            Interface int-br-ex
                type: patch
                options: {peer=phy-br-ex}
    Bridge br-ex
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        Port phy-br-ex
            Interface phy-br-ex
                type: patch
                options: {peer=int-br-ex}
        Port br-ex
            Interface br-ex
                type: internal
    Bridge br-tun
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        Port "vxlan-c0a807aa"
            Interface "vxlan-c0a807aa"
                type: vxlan
                options: {df_default="true", in_key=flow, local_ip="192.168.7.172", out_key=flow, remote_ip="192.168.7.170"}
        Port br-tun
            Interface br-tun
                type: internal
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}
    ovs_version: "2.8.1"

关于我的设置可能有什么问题有什么想法吗?有什么我可以尝试的建议吗?

【问题讨论】:

    标签: openstack devstack openvswitch openstack-neutron


    【解决方案1】:

    事实证明,在我停止服务后,Ubuntu 网络管理器正在重新声明自己。我采取了更激烈的步骤,从我的服务器中禁用并清除它:systemctl disable NetworkManager.service 然后apt-get purge network-manager

    一旦它永远消失了,事情就开始像宣传的那样工作了。我从上面的 local.conf 开始,能够在两台服务器上启动实例,并连接到它们,它们相互连接没有问题等。然后我在我的堆栈中添加了更多的部分(热、马格南、巴比肯、lbaasv2 ) 并且事情仍然是可靠的。

    这个故事的寓意是:Ubuntu 网络管理器和 devstack ovs 配置不能很好地配合使用。要使后者工作,您必须删除前者(据我所知)。

    另外,在 ovs 遇到所有这些麻烦之前,我必须在我的仅计算节点上对 devstack 的 lib/etcd3 脚本应用建议的修复程序。截至 2018 年 9 月 27 日,这是 stable/queens 分支中的一个小但必要的更改。见https://github.com/openstack-dev/devstack/commit/19279b0f8。没有这个 stack.sh 在计算节点上尝试绑定到控制器节点上的地址失败。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多