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

Развертывания с различными архитектурами

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

Смешанные архитектуры процессора для вычислительных узлов

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

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

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

Пример - добавление aarch64 серверов в x86_64 окружение

  1. Установите операционную систему на все новые вычислительные серверы.

  2. Добавьте новые вычислительные ноды в openstack_user_config.yml.

  3. Убедитесь, что как минимум один хост каждой архитектуры присутвует в группе repo-infra_hosts в openstack_user_config.yml.

    Этот хост будет использован для сборки python wheels для собственной архитектуры, которые в дальнейшем ускорят развертывание остальных хостов. Если вы не создаете контейнер с репозиторием для каждой архитектуры, убедитесь что предприняты меры против перегрузки git серверов opendev.org, например путем создания локальных зеркал для репозиториев OpenStack.

  4. Запустите плейбуки OpenStack-Ansible для развертывание требуемых сервисов.

  5. Добавьте признак HW_ARCH_XXXX к каждому вычислительному узлу в OpenStack.

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

    HW_ARCH_X86_64 для процессоров архитектуры x86_64 Intel и AMD, HW_ARCH_AARCH64 для процессоров архитектуры aarch64

    (см.: https://docs.openstack.org/os-traits/latest/reference/traits.html)

    openstack resource provider list
openstack resource provider trait list <uuid-of-compute-host>
openstack resource provider trait set --trait <existing-trait-1> --trait <existing-trait-2> ... --trait HW_ARCH_xxxxx <uuid-of-compute-host>

    Примечание

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

  6. Настройте Nova Scheduler для проверки архитектуры.

    Две дополнительные настройки в /etc/nova/nova.conf для всех Nova API сервисов:

    [scheduler]
image_metadata_prefilter = True

[filter_scheduler]
image_properties_default_architecture = x86_64

    Настройка image_metadata_prefilter заставляет планировщик Nova сопоставлять hw_architecture параметр в образах Glance с соответствующей HW_ARCH_XXX спецификацией для вычислительного хоста в списке провайдеров ресурсов. Это удостоверяет, что образы которые были маркированы целевой архитектурой будут созданы на серверах с совпадающей архитектурой.

    Настройка image_properties_default_architecture применит существующую x86_64 архитектуру ко всем образам Glance, где архитектура ранее не была задана. Это предотвратит необходимость ретроспективно применять параметры ко всем существующим образам, что может быть трудозатратно для пользователей которые имеют различные инструменты автоматизации без применения данного параметра.

    Предупреждение

    Предупреждение о недокументированом поведении!

    Обратите внимание, что image_metadata_prefilter и ImagePropertiesFilter — это разные и не связанные между собой шаги в процессе, который планировщик Nova использует для определения потенциальных вычислительных хостов. В этом разделе объясняется, как использовать их вместе.

    image_metadata_prefilter просматривает только признаки HW_ARCH_XXX на вычислительных хостах и ​​находит оборудование, которое соответствует требуемой архитектуре. Это происходит только тогда, когда свойство hw_architecture присутствует на изображении, и только если требуемые признаки вручную добавлены на вычислительные хосты.

    image_properties_default_architecture используется ImagePropertiesFilter, который проверяет все архитектуры, поддерживаемые QEMU на каждом вычислительном хосте; это включает программные эмуляции неродных архитектур.

    Если полный набор QEMU установлен на вычислительном хосте, этот хост предложит запустить все архитектуры, поддерживаемые доступными бинарными файлами qemu-system-*. В этой ситуации образы без свойства hw_architecture могут быть распределены на хост неродной архитектуры и эмулированы.

  7. Отключите эмуляцию QEMU.

    Примечание

    Этот шаг особенно актуален для существующих сред x86_64, когда добавляются новые вычислительные узлы aarch64, и нельзя предполагать, что свойство hw_architecure применяется ко всем образам Glance, поскольку оператор может не контролировать все загрузки образов.

    Чтобы избежать нежелательной эмуляции QEMU неродных архитектур, необходимо убедиться, что на всех вычислительных узлах присутствует только родной бинарный файл qemu-system-*. Самый простой способ сделать это для существующих развертываний — использовать системный менеджер пакетов, чтобы убедиться, что нежелательные бинарные файлы удалены.

    Выпуски OpenStack-Ansible, включая 2023.1 и более поздние, устанавливают только бинарный файл собственной архитектуры qemu-system-*`, поэтому этот шаг не требуется в более новых выпусках.

  8. Загрузите образы в Glance.

    • В идеале свойство hw_architecture задается для всех загруженных образов. Это свойство обязательно должно быть установлено для всех архитектур, которые не соответствуют image_properties_default_architecture

    • Рекомендуется задать свойство hw_firmware_type='uefi' для любых образов, требующих загрузки UEFI, даже если это подразумевается архитектурой aarch64. Это необходимо для избежания проблем с файлами NVRAM в libvirt при удалении инстанса.

Эмуляция архитектуры при помощи Nova

Nova позволяет эмулировать одну процессорную архитектуру на хосте с другой собственной процессорной архитектурой. Более подробную информацию см. https://docs.openstack.org/nova/latest/admin/hw-emulation-architecture.html

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