Многоузловая конфигурация сети OpenStack в Ubuntu - PullRequest
Новая
       61

Многоузловая конфигурация сети OpenStack в Ubuntu

0 голосов
/ 25 сентября 2018

Я пытаюсь настроить простое развертывание с двумя узлами через devstack.Я следовал как многоузловой лаборатории, так и руководству " Using devstack с Neutron ".я добился наибольшего прогресса с последним.тем не менее, я все еще не могу связаться с экземплярами, работающими на моем узле только для вычислений.экземпляры, которые работают на контроллере / вычислительном узле, выглядят нормально.я могу пропинговать их через ssh с любой машины в моем офисе.

моя среда: 2 сервера Ubuntu 18.04 с открытым железом, частная сеть с маршрутизатором, раздающим адреса DHCP (у меня выделен небольшой диапазон адресов),Я отключил Ubuntu NetworkManager и настроил его через ifupdown в / etc / network / interfaces: 

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

Контроллер / вычислительный узел 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-сервер.если я использую Google, то это нормально.

на узле только для вычислений, у меня есть 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"

любые идеи о том, что может быть не так в моей установке?какие-нибудь предложения для того, что я мог бы попробовать?

1 Ответ

0 голосов
/ 27 сентября 2018

Оказалось, что Ubuntu Network Manager восстанавливал себя после того, как я остановил службы.я предпринял более радикальный шаг, отключив и очистив его от своих серверов: systemctl disable NetworkManager.service, а затем apt-get purge network-manager

, когда все прошло навсегда, все стало работать как рекламируется.я начал с local.conf выше и мог раскручивать экземпляры на обоих серверах, подключаться к ним, и у них не было проблем с подключением друг к другу и т. д. Затем я добавил дополнительные элементы в мой стек (heat, magnum, barbican, lbaasv2).) и все остается надежным.

Мораль этой истории такова: Ubuntu Network Manager и devstack ovs config не очень хорошо играют вместе.чтобы заставить последний работать, вы должны удалить первый (насколько я могу судить).

Кроме того, перед всеми этими проблемами с ovs мне пришлось применить предложенное исправление к сценарию devstack lib / etcd3 на моем узле только для вычислений.это небольшое, но обязательное изменение в ветке stable / queens с 27 сентября 2018 года.см. https://github.com/openstack-dev/devstack/commit/19279b0f8. без этого стека. Ошибка на вычислительном узле при попытке связать его с адресом на узле контроллера.

...