Назад | Перейти на главную страницу

Базовая настройка многоузловой сети Openstack / PackStack

Задний план

После установки OpenStack с PackStack у нас осталась проблема с сетью. Нам нужна была суперпростая сеть с одной подсетью, в которой должны находиться все виртуальные машины, так как это выглядело как простейшее решение. Мы должны начать с трех узлов, на которых работает nova.

Мы использовали следующий файл ответов: файл ответов (pastebin)

Наша установка

Три узла с CentOS 6.5, где узлы подключены к двум коммутаторам.

Правила группы безопасности

Ingress IPv4    TCP 1 - 65535   0.0.0.0/0 (CIDR)
Ingress IPv4    TCP 22 (SSH)    0.0.0.0/0 (CIDR)
Ingress IPv6    Any -       default
Ingress IPv4    TCP 22 (SSH)    10.0.20.0/24 (CIDR)
Ingress IPv4    TCP 53 (DNS)    0.0.0.0/0 (CIDR)
Egress  IPv4    Any -       0.0.0.0/0 (CIDR)
Ingress IPv4    ICMP    -       0.0.0.0/0 (CIDR)
Egress  IPv6    Any -       ::/0 (CIDR)
Ingress IPv4    Any -       default

Нейтрон

(neutron) agent-list
+--------------------------------------+--------------------+------------------------
| id                                   | agent_type         | host  | alive | admin_state_up
+--------------------------------------+--------------------+------------------------
| 09add8dd-0328-4c63-8a79-5c61322a8314 | L3 agent           | host3 | :-)   | True
| 0d0748a9-4289-4a5d-b1d9-d06a764a8d25 | Open vSwitch agent | host2 | :-)   | True
| 258c92fe-8e3a-4760-864e-281a47523e85 | Open vSwitch agent | host1 | :-)   | True
| 2e886dc1-af93-4f4f-b66c-61177a6c9dba | L3 agent           | host1 | :-)   | True
| 50f37a33-2bfc-43f2-9d2f-4f42564d234d | Open vSwitch agent | host3 | :-)   | True
| 535bf0a3-06aa-4072-ae5a-1b1ba1d377ab | L3 agent           | host2 | :-)   | True
| 9b17ef73-a602-4b5d-a4e9-e97445e594b4 | DHCP agent         | host1 | :-)   | True

ovs-vsctl

Host1

ovs-vsctl показать

43da814e-223c-4f66-ba2d-c3c9de91e1f8
    Bridge br-ex
        Port br-ex
            Interface br-ex
                type: internal
    Bridge br-int
        Port br-int
            Interface br-int
                type: internal
        Port "tap3e0d3121-32"
            tag: 4
            Interface "tap3e0d3121-32"
                type: internal
        Port "tap4a397755-29"
            tag: 4
            Interface "tap4a397755-29"
    ovs_version: "1.11.0"
Host2
afa75816-6a40-4f0c-842f-236a3a94cd63
    Bridge br-int
        Port br-int
            Interface br-int
                type: internal
        Port "tap46f55af8-73"
            tag: 1
            Interface "tap46f55af8-73"
    Bridge br-ex
        Port br-ex
            Interface br-ex
                type: internal
    ovs_version: "1.11.0"

Проблема

Экземпляры не могут общаться друг с другом и не могут подключиться к Интернету. Честно говоря, мы не уверены, каковы требования к этому при использовании многоузловой установки nova, когда «внутренняя» сеть между узлами использует только одно соединение. Я думаю, что проблема связана с маршрутизацией, поскольку мы не можем подключаться между экземплярами на разных узлах, но, прочитав МНОГО документации, я не совсем уверен, как это делать. Если я tcpdump интерфейс br-int, я могу получать запросы ARP, но не более того. То есть, если я попытаюсь выполнить эхо-запрос с экземпляра на соответствующем хосте.

Вопрос

Итак, возникает вопрос: как мы можем найти решение этой проблемы многоузловой сети и о чем нам нужно подумать? Может быть, это маршрутизация, неправильная конфигурация ОС хоста или openstack? (Запуск CentOS).

Любая обратная связь приветствуется, так как мы застряли на этом этапе на пару недель. Извините за длинный пост, но я надеюсь, что здесь есть необходимая информация. Если не; не стесняйся :)

Обновить

Мне удалось исправить внутреннюю сеть между узлами, чтобы экземпляры могли обмениваться данными между физическими узлами.

- Changed the /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini:
[database]
connection = mysql://neutron:password@127.0.0.1:3306/ovs_neutron

[OVS]
tennant_network_type = gre
tunnel_id_ranges = 1:1000
integration_brige = br-int
tunnel_bridge = br-tun
local_ip = 10.0.20.1
enable_tunneling = True

- Restarted the service on controller
cd /etc/init.d/; for i in $( ls neutron-* ); do sudo service $i restart; done )
service openvswitch restart

Это было сделано на всех узлах и созданы туннели GRE. Хотя поток не работал, мне нужно было использовать ovs-ofctl add-flow br-tun action=normal.

Текущая проблема, с которой я сейчас сталкиваюсь, - это возможность направить внутреннюю подсеть в Интернет, чтобы все экземпляры получили доступ в Интернет. Нужны ли мне плавающие IP-адреса для подключения к Интернету? Нет патча между br-int и br-ex или маршрутизаторами, так нужно ли это, чтобы иметь возможность направлять трафик в Интернет?

Могу ли я добавить маршрут по умолчанию с помощью ip netns exec ... ip add default gw via (ip of br-ex) или мне нужно добавить несколько новых интерфейсов?

Как было обновлено ранее, мне удалось запустить сеть, используя туннелирование GRE вместо сети nova. Сетевые швы Nova могут быть хорошим решением, если у вас есть запасной физический сетевой интерфейс, но когда у вас его нет, он не работает так хорошо.

Для настройки GRE использовалось следующее: - Изменен файл /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini:

[database]
connection = mysql://neutron:password@127.0.0.1:3306/ovs_neutron

[OVS]
tennant_network_type = gre
tunnel_id_ranges = 1:1000
integration_brige = br-int
tunnel_bridge = br-tun
local_ip = "internal ip"
enable_tunneling = True

- Restarted the service on controller
cd /etc/init.d/; for i in $( ls neutron-* ); do sudo service $i restart; done )
service openvswitch restart

Это было скопировано на каждый вычислительный узел. Однако важной частью использования туннелей GRE является то, что при создании новой сети вам необходимо указать идентификатор сегментации. Если вы попытаетесь создать сеть через горизонт, это не сработает.

keystone tenant-list
admin=$(keystone tenant-list | grep admin | awk -F' |' '{ print $2 }')
neutron net-create --tenant-id $admin network --provider:network_type gre --provider:segmentation_id 3
neutron subnet-create --tenant-id $admin network 192.168.0.0/24 --getaway 192.168.0.1

Вы также можете добавить внешнюю сеть с помощью следующих команд:

neutron net-create ext
neutron net-list
neutron subnet-create extnet --allocation-pool start=10.0.0.10,end=10.0.0.100 --gateway=10.0.0.1 --enable_dhcp=False 10.0.0.0/24

Затем мы можем создать новый маршрутизатор и подключить сеть к этому внешнему маршрутизатору. Это, конечно, лишь одно из многих решений.

intsubnet=$(neutron subnet-list | grep 192.168.0.0/24| awk -F' |' '{ print $2 }')
extnet=$(neutron net-list | grep ext | awk -F' |' '{ print $2 }')

neutron router-create ext-to-int --tenant-id $admin
router=$(neutron router-list | grep ext-to-int | awk -F' |' '{ print $2 }')

neutron router-interface-add $router $intsubnet
neutron router-gateway-set $router $extnet

Поначалу у меня была очень низкая пропускная способность инстансов. Это было решено, когда я распределил новый MTU (1454) с DCHP (создайте файл конфигурации dhcp в / etc / нейтрон / и добавьте dhcp-option-force=26,1454 в файл. Обновить dnsmasq_config_file в /etc/neutron/dhcp_agent.ini

Это сработало для меня и было всем, что было нужно.

Сядь и смотри этот.

Он проходит через настройку простого многоузлового кластера, и я нашел это очень понятным. Последний бит о настройке NAT не будет применяться, потому что он запускает свой кластер на Virtualbox.

В описании видео есть связанное слайд-шоу.