[ English | English (United Kingdom) | español | Deutsch | Indonesia | русский | 한국어 (대한민국) | français ]

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

Configuring network interfaces

OpenStack-Ansible does not mandate any specific method of configuring network interfaces on the host. You may choose any tool, such as ifupdown, netplan, systemd-networkd, networkmanager or another operating-system specific tool. The only requirement is that a set of functioning network bridges and interfaces are created which match those expected by OpenStack-Ansible, plus any that you choose to specify for neutron physical interfaces.

A selection of network configuration example files are given in the etc/network and etc/netplan for ubuntu systems, and it is expected that these will need adjustment for the specific requirements of each deployment.

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

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

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

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

На каждом хосте потребуется настроить корректные сетевые мосты. Ниже представлено содержимое файла /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 и инстансов.

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

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

На каждом хосте потребуется настроить корректные сетевые мосты. Ниже представлено содержимое файла /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 для различных сценариев развертывания вы можете найти по ссылкам:

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

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

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

Для сетевого агента и сетевой топологии контейнеров, пожалуйста обратитесь к следующим статьям:

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