[ English | English (United Kingdom) | русский | Deutsch ]

Сетевые архитектуры

OpenStack-Ansible поддерживает несколько различных сетевых архитектур и может произвести развертывание используя один сетевой интерфейс для тестовых окружений, или использовать несколько сетевых интерфейсов, или агрегированные интерфейсы для рабочих окружений.

Эталонная архитектура OpenStack-Ansible разделяет трафик используя VLAN-ы на нескольких сетевых интерфейсах или агрегациях. Стандартные сети, используемые при развертывании OpenStack-Ansible описаны в следующей таблице:

Сеть	CIDR	VLAN
Управляющая сеть	172.29.236.0/22	10
Overlay сеть	172.29.240.0/22	30
Сеть хранилища данных	172.29.244.0/22	20

Сеть управления, также упоминающаяся как сеть контейнеров служит для управления и общения между инфраструктурой и сервисами OpenStack, которые запущены как в контейнерах так и без них. Сеть управления использует выделенный VLAN, обычно подключенный к мосту br-mgmt и может быть использован как основной интерфейс для взаимодействия с сервером по SSH.

Overlay сеть, также называемая туннелированная сеть, обеспечивает связь между хостами с целью туннелирования инкапсулированного трафика с использованием VXLAN, Geneve или других протоколов. Overlay сеть использует выделенную VLAN, обычно подключенную к мосту br-vxlan.

Сеть хранилища данных предоставляет разделенный доступ к Блочному Хранилищу с таких сервисов OpenStack, как Cinder и Glance. Сеть хранилища данных использует выделенный VLAN, обычно подключенный к мосту br-storage.

Примечание

Указанные для каждой сети CIDR и VLAN приведены в качестве примера и могут отличаться в вашем окружении.

Дополнительные VLAN-ы могут потребоваться для следующих целей:

• Внешние сети провайдера для назначаемых IP и инстансов

• Собственные сети проектов/тенантов для инстансов

• Другие сервисы OpenStack

Сетевые интерфейсы

Настройка сетевых интерфейсов

OpenStack-Ansible не предписывает какой-либо конкретный метод настройки сетевых интерфейсов на хосте. Вы можете выбрать любой инструмент, например ifupdown, netplan, systemd-networkd, networkmanager или другой инструмент, специфичный для операционной системы. Единственное требование — создание набора функционирующих сетевых мостов и интерфейсов, соответствующих ожидаемым OpenStack-Ansible, а также любых, которые вы укажете для физических интерфейсов neutron.

Выборка файлов примеров конфигурации сети приведена в etc/network и etc/netplan для систем Ubuntu, и ожидается, что их потребуется настроить в соответствии с конкретными требованиями каждого развертывания.

Если вы хотите делегировать управление сетевыми мостами и интерфейсами OpenStack-Ansible, вы можете определить переменные openstack_hosts_systemd_networkd_devices и openstack_hosts_systemd_networkd_networks в group_vars/lxc_hosts, например:

openstack_hosts_systemd_networkd_devices:
  - NetDev:
      Name: vlan-mgmt
      Kind: vlan
    VLAN:
      Id: 10
  - NetDev:
      Name: "{{ management_bridge }}"
      Kind: bridge
    Bridge:
      ForwardDelaySec: 0
      HelloTimeSec: 2
      MaxAgeSec: 12
      STP: off

openstack_hosts_systemd_networkd_networks:
  - interface: "vlan-mgmt"
    bridge: "{{ management_bridge }}"
  - interface: "{{ management_bridge }}"
    address: "{{ management_address }}"
    netmask: "255.255.252.0"
    gateway: "172.29.236.1"
  - interface: "eth0"
    vlan:
      - "vlan-mgmt"
    # NOTE: `05` is prefixed to filename to have precedence over netplan
    filename: 05-lxc-net-eth0
    address: "{{ ansible_facts['eth0']['ipv4']['address'] }}"
    netmask: "{{ ansible_facts['eth0']['ipv4']['netmask'] }}"

Если вам нужно запустить некоторые pre/post хуки для интерфейсов, вам нужно будет настроить для этого службу systemd. Это можно сделать с помощью переменной openstack_hosts_systemd_services, например:

openstack_hosts_systemd_services:
  - service_name: "{{ management_bridge }}-hook"
    state: started
    enabled: yes
    service_type: oneshot
    execstarts:
      - /bin/bash -c "/bin/echo 'management bridge is available'"
    config_overrides:
      Unit:
        Wants: network-online.target
        After: "{{ sys-subsystem-net-devices-{{ management_bridge }}.device }}"
        BindsTo: "{{ sys-subsystem-net-devices-{{ management_bridge }}.device }}"

Одиночный интерфейс или агрегация

OpenStack-Ansible поддерживает использование как и одиночных интерфейсов так и набора агрегированных интерфейсов для обслуживания трафика сервисов OpenStack также как и инстансов.

Open Virtual Network (OVN)

Данная диаграмма демонстрирует использование хостами одиночного интерфейса с OVN:

В приведенном ниже сценарии к внешней сети подключен только сетевой узел, а вычислительные устройства не имеют внешнего подключения, поэтому для внешнего подключения необходимы маршрутизаторы:

На следующей схеме показан вычислительный узел, выполняющий функции шлюза OVN. Он подключен к публичной сети, что позволяет подключать виртуальные машины к публичным сетям не только через маршрутизаторы, но и напрямую:

Open vSwitch и Linux Bridge

Данная диаграмма демонстрирует использование хостами одиночного интерфейса для сценариев OVS и Linux Bridge:

Данная диаграмма демонстрирует использование хостами одного агрегированного интерфейса:

На каждом хосте потребуется настроить корректные сетевые мосты. Ниже представлено содержимое файла /etc/network/interfaces для infra1 с использованием одного агрегированного интерфейса.

Примечание

Если в вашем окружении нет интерфейса eth0, но вместо него используется p1p1, либо же какое-нибудь другое имя интерфейса, убедитесь, что все отсылки к eth0 в конфигурационных файлах заменены на подходящее имя. Это же применимо ко всем дополнительным сетевым интерфейсам.

# This is a multi-NIC bonded configuration to implement the required bridges
# for OpenStack-Ansible. This illustrates the configuration of the first
# Infrastructure host and the IP addresses assigned should be adapted
# for implementation on the other hosts.
#
# After implementing this configuration, the host will need to be
# rebooted.

# Assuming that eth0/1 and eth2/3 are dual port NIC's we pair
# eth0 with eth2 for increased resiliency in the case of one interface card
# failing.
auto eth0
iface eth0 inet manual
    bond-master bond0
    bond-primary eth0

auto eth1
iface eth1 inet manual

auto eth2
iface eth2 inet manual
    bond-master bond0

auto eth3
iface eth3 inet manual

# Create a bonded interface. Note that the "bond-slaves" is set to none. This
# is because the bond-master has already been set in the raw interfaces for
# the new bond0.
auto bond0
iface bond0 inet manual
    bond-slaves none
    bond-mode active-backup
    bond-miimon 100
    bond-downdelay 200
    bond-updelay 200

# Container/Host management VLAN interface
auto bond0.10
iface bond0.10 inet manual
    vlan-raw-device bond0

# OpenStack Networking VXLAN (tunnel/overlay) VLAN interface
auto bond0.30
iface bond0.30 inet manual
    vlan-raw-device bond0

# Storage network VLAN interface (optional)
auto bond0.20
iface bond0.20 inet manual
    vlan-raw-device bond0

# Container/Host management bridge
auto br-mgmt
iface br-mgmt inet static
    bridge_stp off
    bridge_waitport 0
    bridge_fd 0
    bridge_ports bond0.10
    address 172.29.236.11
    netmask 255.255.252.0
    gateway 172.29.236.1
    dns-nameservers 8.8.8.8 8.8.4.4

# OpenStack Networking VXLAN (tunnel/overlay) bridge
#
# Nodes hosting Neutron agents must have an IP address on this interface,
# including COMPUTE, NETWORK, and collapsed INFRA/NETWORK nodes.
#

auto br-vxlan
iface br-vxlan inet static
    bridge_stp off
    bridge_waitport 0
    bridge_fd 0
    bridge_ports bond0.30
    address 172.29.240.16
    netmask 255.255.252.0

# OpenStack Networking VLAN bridge
#
# The "br-vlan" bridge is no longer necessary for deployments unless Neutron
# agents are deployed in a container. Instead, a direct interface such as
# bond0 can be specified via the "host_bind_override" override when defining
# provider networks.
#
#auto br-vlan
#iface br-vlan inet manual
#    bridge_stp off
#    bridge_waitport 0
#    bridge_fd 0
#    bridge_ports bond0

# compute1 Network VLAN bridge
#auto br-vlan
#iface br-vlan inet manual
#    bridge_stp off
#    bridge_waitport 0
#    bridge_fd 0
#

# Storage bridge (optional)
#
# Only the COMPUTE and STORAGE nodes must have an IP address
# on this bridge. When used by infrastructure nodes, the
# IP addresses are assigned to containers which use this
# bridge.
#
auto br-storage
iface br-storage inet manual
    bridge_stp off
    bridge_waitport 0
    bridge_fd 0
    bridge_ports bond0.20

# compute1 Storage bridge
#auto br-storage
#iface br-storage inet static
#    bridge_stp off
#    bridge_waitport 0
#    bridge_fd 0
#    bridge_ports bond0.20
#    address 172.29.244.16
#    netmask 255.255.252.0

Несколько интерфейсов или агрегаций

OpenStack-Ansible поддерживает использование как нескольких интерфейсов так и набора агрегированных интерфейсов для обслуживания трафика сервисов OpenStack и инстансов.

Open Virtual Network (OVN)

Данная диаграмма демонстрирует использование хостами нескольких агрегированных интерфейсов с OVN:

В приведенном ниже сценарии к внешней сети подключен только сетевой узел, а вычислительные устройства не имеют внешнего подключения, поэтому для внешнего подключения необходимы маршрутизаторы:

На следующей схеме показан вычислительный узел, выполняющий функции шлюза OVN. Он подключен к публичной сети, что позволяет подключать виртуальные машины к публичным сетям не только через маршрутизаторы, но и напрямую:

Open vSwitch и Linux Bridge

Данная диаграмма демонстрирует использование хостами нескольких интерфейсов для сценариев OVS и Linux Bridge:

Данная диаграмма демонстрирует использование хостами нескольких агрегаций:

На каждом хосте потребуется настроить корректные сетевые мосты. Ниже представлено содержимое файла /etc/network/interfaces для infra1 с использованием нескольких агрегированных интерфейсов.

Примечание

Если в вашем окружении нет интерфейса eth0, но вместо него используется p1p1, либо же какое-нибудь другое имя интерфейса, убедитесь, что все отсылки к eth0 в конфигурационных файлах заменены на подходящее имя. Это же применимо ко всем дополнительным сетевым интерфейсам.

# This is a multi-NIC bonded configuration to implement the required bridges
# for OpenStack-Ansible. This illustrates the configuration of the first
# Infrastructure host and the IP addresses assigned should be adapted
# for implementation on the other hosts.
#
# After implementing this configuration, the host will need to be
# rebooted.

# Assuming that eth0/1 and eth2/3 are dual port NIC's we pair
# eth0 with eth2 and eth1 with eth3 for increased resiliency
# in the case of one interface card failing.
auto eth0
iface eth0 inet manual
    bond-master bond0
    bond-primary eth0

auto eth1
iface eth1 inet manual
    bond-master bond1
    bond-primary eth1

auto eth2
iface eth2 inet manual
    bond-master bond0

auto eth3
iface eth3 inet manual
    bond-master bond1

# Create a bonded interface. Note that the "bond-slaves" is set to none. This
# is because the bond-master has already been set in the raw interfaces for
# the new bond0.
auto bond0
iface bond0 inet manual
    bond-slaves none
    bond-mode active-backup
    bond-miimon 100
    bond-downdelay 200
    bond-updelay 200

# This bond will carry VLAN and VXLAN traffic to ensure isolation from
# control plane traffic on bond0.
auto bond1
iface bond1 inet manual
    bond-slaves none
    bond-mode active-backup
    bond-miimon 100
    bond-downdelay 250
    bond-updelay 250

# Container/Host management VLAN interface
auto bond0.10
iface bond0.10 inet manual
    vlan-raw-device bond0

# OpenStack Networking VXLAN (tunnel/overlay) VLAN interface
auto bond1.30
iface bond1.30 inet manual
    vlan-raw-device bond1

# Storage network VLAN interface (optional)
auto bond0.20
iface bond0.20 inet manual
    vlan-raw-device bond0

# Container/Host management bridge
auto br-mgmt
iface br-mgmt inet static
    bridge_stp off
    bridge_waitport 0
    bridge_fd 0
    bridge_ports bond0.10
    address 172.29.236.11
    netmask 255.255.252.0
    gateway 172.29.236.1
    dns-nameservers 8.8.8.8 8.8.4.4

# OpenStack Networking VXLAN (tunnel/overlay) bridge
#
# Nodes hosting Neutron agents must have an IP address on this interface,
# including COMPUTE, NETWORK, and collapsed INFRA/NETWORK nodes.
#

auto br-vxlan
iface br-vxlan inet static
    bridge_stp off
    bridge_waitport 0
    bridge_fd 0
    bridge_ports bond1.30
    address 172.29.240.16
    netmask 255.255.252.0

# OpenStack Networking VLAN bridge
#
# The "br-vlan" bridge is no longer necessary for deployments unless Neutron
# agents are deployed in a container. Instead, a direct interface such as
# bond1 can be specified via the "host_bind_override" override when defining
# provider networks.
#
#auto br-vlan
#iface br-vlan inet manual
#    bridge_stp off
#    bridge_waitport 0
#    bridge_fd 0
#    bridge_ports bond1

# compute1 Network VLAN bridge
#auto br-vlan
#iface br-vlan inet manual
#    bridge_stp off
#    bridge_waitport 0
#    bridge_fd 0
#

# Storage bridge (optional)
#
# Only the COMPUTE and STORAGE nodes must have an IP address
# on this bridge. When used by infrastructure nodes, the
# IP addresses are assigned to containers which use this
# bridge.
#
auto br-storage
iface br-storage inet manual
    bridge_stp off
    bridge_waitport 0
    bridge_fd 0
    bridge_ports bond0.20

# compute1 Storage bridge
#auto br-storage
#iface br-storage inet static
#    bridge_stp off
#    bridge_waitport 0
#    bridge_fd 0
#    bridge_ports bond0.20
#    address 172.29.244.16
#    netmask 255.255.252.0

Дополнительные ресурсы

Больше информации как правильно настроить сетевые интерфейсы и файлы конфигурации OpenStack-Ansible для различных сценариев развертывания вы можете найти по ссылкам:

• Настройка тестового окружения

• Настройка однородного рабочего окружения

• Использование сетей провайдера для разнородного окружения

Для сетевого агента и сетевой топологии контейнеров, пожалуйста, см.:

• Сетевая архитектура контейнеров