2.3.3 Инфраструктурная сеть

Инфраструктурная сеть подается на все узлы облака в виде терминированной сети VLAN в trunk, состоящий из двух физических интерфейсов, объединенных в агрегацию (bond0 и bond1 на Рис. 2.5).

../_images/LACP_comm1.png

Рис. 2.5 Принцип логической коммутации инфраструктурной сети

Использование LACP, с одной стороны, обеспечит высокую доступность агрегированного канала, так как выход из строя любого из линков между сервером и коммутатором не приведёт к потере доступности сетевых сервисов. С другой стороны, применение LACP обеспечит равномерную балансировку нагрузки между физическими сетевыми интерфейсами сервера.

Минимальная пропускная способность сетевых интерфейсов – 1Гбит/с.

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

Для обеспечения взаимодействия служебных компонентов облака необходима сетевая связанность, которая может быть выполнена в L2 и L3 варианте.

Примечание.

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

Кроме LACP, возможно использовать другие конфигурации – обычный bond или без агрегации, но это является нерекомендуемой конфигурацией.

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

  • один инфраструктурный VLAN;
  • три инфраструктурных VLAN для разделения потоков трафика запросов: public, internal и admin.

Пример архитектуры, использующей FC СХД для хранения дисков ВМ и файловое хранилище для образов и перемещаемых профилей, приведен ниже (Рис. 2.6).

../_images/VLAN_segmentation.png

Рис. 2.6 Сегментация продуктивной сети (несколько VLAN)

2.3.3.1 Назначения сетей

Название подсети Маска VLAN Назначение Сеть/Маска GW
tionuix_kvm_public 24 915 Сеть для внешнего доступа к API платформы, рабочему столу Tionix, сетям виртуальных машин 10.160.209.0/24 10.160.209.1
tionix_kvm_internal 24 916 Сеть для внутреннего взаимодействия по API между управляющими и вычислительными узлами 10.160.210.0/24 10.160.210.1
tionix_kvm_mgmt 24 917 Сеть для настройки и управления Tionix VDI 10.160.211.0/24 10.160.211.1
Tenant 22 918 Сеть виртуальных машин VDI 10.160.236.0/22 10.160.236.1
IPMI 24 920 Управление оборудованием через интерфейсы удаленного управления 10.160.213.0/24 10.160.213.1

2.3.3.2 Сети хранения данных

Специализированная сеть передачи данных – FibreChannel (сокр. FC) – является рекомендуемой, в связи с низкой латентностью (отсутствием Ethernet задержек) и специализированности такой реализации (назначение – передача данных).

Тем не менее, вполне допустимо использование сетей Ethernet для взаимодействия с хранилищами, при обеспечении достаточной отказоустойчивости и производительности.

../_images/Data-Transfer_Network.png

Рис. 2.7 Схема сети передачи данных (подключение узлов платформы)

2.3.3.2.1 Сеть FibreChannel

Сеть FibreChannel (сокр. FC) подключается к вычислительным узлам, в случае минимальной интеграции подключения дисков. В такой конфигурации диски (volumes) хранятся и подключаются на СХД, а образы ВМ (Glance images) хранятся локально (в управляющем контуре), либо используя альтернативные хранилища (в том же контуре).

Недостаток данной конфигурации – необходимость копирования образа при создании виртуальной машины.

При использовании совмещенной схемы – хранении дисков (volumes) и образов (images) – необходимо подключение FC к управляющему контуру, помимо вычислительных узлов. Пропускная способность сети определяется архитектором, в зависимости от требуемых показателей IOPS.

Внимание.

Рекомендуемая конфигурация: SAN связанность для всех узлов; интеграция Glance для хранения образов на СХД.

Коммутацию необходимо выполнять с избыточностью, используя Multipath. Данный режим должен быть включен в службе Nova (на вычислительных узлах), путем внесения соответствующего изменения в файл конфигурации:

[libvirt]
volume_use_multipath = True

Также, при необходимости, должна быть настроена служба multipathd – модифицируйте файл multipathd.conf на вычислительных узлах.

Примечание.

Использование сети хранения без избыточности каналов допускается при настройке тестовых стендов.

2.3.3.2.2 Сеть СХД Ethernet

В случае использования хранилищ, не поддерживающих протокол FC (SDS либо NFS и т.п.), необходимо дооснастить облако сетью с пропускной способностью не ниже 10Gbits, то есть направить Storage-трафик через отдельную СХД сеть (SAN).

Для данной сети Ethernet рекомендуется включение JumboFrame. Изменить MTU можно в конфигурационном файле интерфейса systemd-networkd:

[Match]
Name=enp5s0

[Link]
MTUBytes=9000

Коммутацию необходимо выполнять с избыточностью, используя агрегацию каналов Ethernet. Рекомендуется использование LACP (802.3ad). Также, допускается использование отказоустойчивого решения на основе L3 (BGP Fabric [1]).

Включите multipath для iSCSI на вычислительных узлах – измените опцию „volume_use_multipath“ (/etc/nova/nova.conf`) на значение True:

[libvirt]
volume_use_multipath = True

2.3.3.2.3 Клиентские сети

Клиентские сети – внутренние сети, в которых виртуальный L2 работает поверх инфраструктурной сети (Рис. 2.5).

Внешние сети, подаваемые с помощью VLAN или Flat (access-сети) могут быть заведены на различные интерфейсы, посредством сопоставления Neutron-алиасов логических сетей физическим. Физическая сеть в данном случае может быть как отдельно взятым сетевым интерфейсом, так и агрегацией (bond).

Внешние клиентские сети могут подаваться для работы в облаке в различном виде (тегированный flat, отдельный интерфейс с access сетью). Связанность выполняется только на вычислительных узлах (совмещенная роль network ноды), поскольку на них располагается непосредственно контроллер OVN.

Клиентские сети могут подаваться через маршрутизацию из других сетей, например – при использовании IP Fabric.

Примечание.

Допустимо построение сетевого ядра облака на базе IP Fabric, а ввод тенантных сетей – с помощью маршрутизации.

2.3.3.3 Пример архитектуры сети с хранилищем Ceph

../_images/Ceph_storage-net.png

Рис. 2.8 Схема организации сети с использованием хранилища Ceph

В приведенном на Рис. 2.8 примере сеть физически подана через агрегацию LACP. В ней присутствуют три инфраструктурных VLAN: Public, Internal и Manage (зеленая, синяя и коричневая шины передачи данных).

Также на схеме обозначен VXLAN, обеспечивающий связанность внутренней сети – он работает поверх инфраструктурной сети (голубая шина).

Сеть тенанта (Tenant, желтая шина) используется как продуктивная внешняя сеть облака, используемая виртуальными машинами.

Сеть 10G (в данном примере) используется для обеспечения связанности с системой хранения данных Ceph.

2.3.3.4 Балансировщик нагрузки

Балансировка нагрузки – распространенное решение для горизонтального масштабирования веб-приложений по нескольким хостам, с предоставлением единой точки доступа пользователей к определенному сервису.

HAproxy – популярное ПО, используемое для балансировки нагрузки. HAproxy обеспечивает высокую доступность и функциональность проксирования, оптимизирует использование ресурсов, максимизирует пропускную способность, минимизирует время отклика и позволяет избежать перегрузки каждого отдельно взятого ресурса.

Необходимость в VirtualIP отсутствует, поскольку балансировщик отслеживает состояние узлов и, в случае «падения узла», автоматически перенаправляет запросы на активные узлы.

Сноски

[1]https://www.ipspace.net/Data_Center_BGP/BGP_Fabric_Routing_Protocol