[ English | русский ]

Подготовка целевых хостов

_images/installation-workflow-targethosts.png

[ English | русский ]

Настройка операционной системы

This section describes the installation and configuration of operating systems for the target hosts, as well as deploying SSH keys and configuring storage.

Установка операционной системы

Установите одну из следующих поддерживаемых операционных систем на целевом хосте:

  • Ubuntu Server 24.04 (Noble Numbat) 64-bit
  • Ubuntu Server 26.04 (Resolute Raccoon) 64-bit
  • Debian 13 (Trixie) 64-bit
  • CentOS 10 Stream 64-bit
  • Rocky Linux 10 64-bit
  • AlmaLinux 10 64-bit (may work, not officially tested)

Настройте как минимум один сетевой интерфейс для доступа в Интернет или к локальным репозиториям пакетов.

Некоторые дистрибутивы добавляют в файл /etc/hosts лишнюю запись, разрешающую фактическое имя хоста на другой петлевой IP-адрес, например 127.0.1.1. Эту запись необходимо закомментировать или удалить во избежание проблем с разрешением имен. Не удаляйте запись 127.0.0.1. Данный шаг особенно важен при развертываниях типа bare metal.

Используйте короткие имена хостов вместо полных доменных имен (FQDN), чтобы избежать проблем с ограничением длины в LXC и SSH. Например, подходящим коротким именем для вычислительного хоста может быть: 12345-Compute001.

Рекомендуется установить пакеты SSH-сервера на целевые хосты, не имеющие локального (через консоль) доступа.

Примечание

We also recommend setting your locale to en_US.UTF-8. Other locales might work, but they are not tested or supported. Также рекомендуется установить локаль en_US.UTF-8. Другие локали могут работать, однако они не тестируются и не поддерживаются.

Настройка Debian

  1. Обновите списки источников пакетов

    # apt update

  2. Обновите системные пакеты и ядро:

    # apt dist-upgrade

  3. Установите дополнительные программные пакеты:

    # apt install bridge-utils debootstrap ifenslave ifenslave-2.6 \
  lsof lvm2 openssh-server sudo tcpdump vlan python3

  4. Перезагрузите хост для применения изменений и загрузки нового ядра.

Настройка Ubuntu

  1. Обновите списки источников пакетов

    # apt update

  2. Обновите системные пакеты и ядро:

    # apt dist-upgrade

  3. Установите дополнительные программные пакеты:

    # apt install bridge-utils debootstrap openssh-server \
  tcpdump vlan python3

  4. Установите дополнительный пакет ядра (kernel extra), если он доступен для вашей версии ядра

    # apt install linux-modules-extra-$(uname -r)

  5. Перезагрузите хост для применения изменений и загрузки нового ядра.

Настройка CentOS Stream / Rocky Linux / AlmaLinux

  1. Обновите системные пакеты и ядро:

    # dnf upgrade

  2. Отключите SELinux. Отредактируйте файл /etc/sysconfig/selinux и замените SELINUX=enforcing на SELINUX=disabled.

    Для дистрибутивов RHEL начиная с версии 9 рекомендуемый способ отключения SELinux — через загрузчик с помощью утилиты grubby:

    # grubby --update-kernel ALL --args selinux=0

    Примечание

    В настоящее время SELinux не поддерживается в OpenStack-Ansible для CentOS/RHEL в связи с отсутствием мейнтейнеров данной функциональности.

  3. Отключите firewalld для обеспечения корректного взаимодействия компонентов:

    # systemctl stop firewalld
# systemctl mask firewalld

  4. Установите дополнительные программные пакеты:

    # dnf install iputils lsof openssh-server\
  sudo tcpdump python3

  5. (Необязательно) Снизьте уровень журналирования ядра, изменив значение printk в sysctl:

    # echo "kernel.printk='4 1 7 4'" >> /etc/sysctl.conf

  6. Перезагрузите хост для применения изменений и загрузки нового ядра.

Настройка SSH-ключей

Ansible использует SSH для подключения узла развертывания к целевым хостам. Можно использовать пользователя root или любого другого пользователя, которому разрешено повышение привилегий через механизм Ansible become (например, путем добавления пользователя в sudoers). Подробнее см. в разделе Запуск без прав root (Running as non-root).

  1. Скопируйте содержимое файла открытого ключа с узла развертывания в файл ``~/.ssh/authorized_keys``на каждом целевом хосте.

  2. Проверьте аутентификацию по открытому ключу с узла развертывания на каждый целевой хост, подключившись по SSH с узла развертывания к целевому хосту. Если подключение устанавливается и предоставляется командная оболочка без запроса пароля — аутентификация настроена корректно.

Дополнительные сведения о генерации пары SSH-ключей и рекомендуемых практиках см. в документации GitHub по генерации SSH-ключей.

Настройка хранилища

Менеджер логических томов (LVM) позволяет разбить одно устройство на несколько логических томов, которые операционная система воспринимает как физические устройства хранения. Служба блочного хранилища (Cinder) и LXC-контейнеры, в которых при необходимости работает инфраструктура OpenStack, могут использовать LVM для хранения своих данных.

Примечание

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

  1. Для использования опциональной службы блочного хранилища (Cinder) создайте группу томов LVM с именем cinder-volumes на хосте хранилища. При создании физического тома укажите размер метаданных 2048. Например:

    # pvcreate --metadatasize 2048 physical_volume_device_path
# vgcreate cinder-volumes physical_volume_device_path

  2. Дополнительно можно создать группу томов LVM с именем lxc для файловых систем контейнеров и установить lxc_container_backing_store: lvm в файле user_variables.yml, если требуется использовать LXC совместно с LVM. Если группа томов lxc ``отсутствует, контейнеры по умолчанию автоматически устанавливаются в файловую систему в каталоге ``/var/lib/lxc.

[ English | русский ]

Настройка сети

OpenStack-Ansible использует мостовые (bridge) интерфейсы для соединения физических и логических сетевых интерфейсов хоста с виртуальными сетевыми интерфейсами внутри контейнеров. На целевых хостах необходимо настроить следующие сетевые мосты:

Имя моста

Рекомендуемое размещение

Со статическим IP-адресом

br-mgmt

На каждом узле

Всегда

br-storage

На каждом узле хранилища

При развертывании компонента непосредственно на «железе» (bare metal)

На каждом вычислительном узле

Всегда

br-vxlan

На каждом сетевом узле

При развертывании компонента непосредственно на «железе» (bare metal)

На каждом вычислительном узле

Всегда

br-vlan

На каждом сетевом узле

Никогда

На каждом вычислительном узле

Никогда

Подробное описание реализации сети хостов и контейнеров см Сетевое взаимодействие контейнеров в разделе архитектуры справочника OpenStack-Ansible<reference/architecture/index.html>.

Примеры конкретных сценариев использования приведены в Руководстве пользователя.

Информация о сетевых мостах хоста

  • LXC internal: lxcbr0

    Мост lxcbr0 обязателен для LXC, однако OpenStack-Ansible настраивает его автоматически. Он обеспечивает внешнее (как правило, Интернет) подключение для контейнеров посредством dnsmasq (DHCP/DNS) и NAT.

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

    Сеть контейнеров, к которой подключается мост, настраивается в файле openstack_user_config.yml в provider_networks.

  • Управление контейнерами: br-mgmt

    Мост br-mgmt обеспечивает управление и взаимодействие между инфраструктурными компонентами и службами OpenStack.

    Мост подключается к физическому или логическому интерфейсу, как правило к VLAN-субинтерфейсу bond0. Внутри каждого контейнера он подключается к интерфейсу ``eth1`.

    Сетевой интерфейс контейнера, к которому подключается мост, настраивается в файле openstack_user_config.yml.

  • Хранилище: br-storage

    Мост ``br-storage ``обеспечивает изолированный доступ к устройствам блочного хранилища между службами OpenStack и устройствами хранилища.

    Мост подключается к физическому или логическому интерфейсу, как правило к VLAN-субнтерфейсу bond0. Внутри каждого связанного контейнера он подключается к интерфейсу eth2.

    Сетевой интерфейс контейнера, к которому подключается мост, настраивается в файле openstack_user_config.yml.

  • Туннель OpenStack Networking: br-vxlan

    Интерфейс br-vxlan необходим, если среда настроена таким образом, чтобы проекты могли создавать виртуальные сети с использованием VXLAN. Он обеспечивает передачу инкапсулированного трафика виртуальных (VXLAN) туннельных сетей.

    Следует отметить, что br-vxlan вовсе не обязательно должен быть мостовым интерфейсом: можно напрямую использовать физический интерфейс или VLAN-субинтерфейс агрегированного канала (bond), что будет более эффективно. Имя br-vxlan сохранено здесь для единообразия в документации и примерах конфигурации.

    Сетевой интерфейс контейнера, к которому подключается данный интерфейс, настраивается в файле openstack_user_config.yml.

  • Сеть провайдера OpenStack Networking: br-vlan

    Примечание

    Мост br-vlan больше не является строго обязательным — при правильной конфигурации можно использовать физический интерфейс напрямую (например, при использовании OVN). В ряде конфигураций он сохраняется преимущественно для единообразия и соответствия соглашениям об именовании в документации, однако его использование является необязательным.

    Мост br-vlan обеспечивает инфраструктуру для сетей с тегами VLAN или плоских сетей (без тегов VLAN).

    Мост подключается к физическому или логическому интерфейсу, как правило bond1. IP-адрес ему не назначается, поскольку он обеспечивает связность исключительно на уровне L2.

    Сетевой интерфейс контейнера, к которому подключается мост, настраивается в файле openstack_user_config.yml.