[ English | русский | Indonesia ]

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

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. Confirm the HW_ARCH_XXXX trait on every compute host in OpenStack.

    The Nova libvirt driver reports a CPU architecture trait on the resource provider of each compute host automatically, derived from the host CPU architecture. The traits are:

    HW_ARCH_X86_64 для процессоров Intel и AMD x86_64

    HW_ARCH_AARCH64 для процессоров архитектуры aarch64

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

    This behaviour is available since the 2023.2 (Bobcat) release (see: https://bugs.launchpad.net/nova/+bug/2062425), so the trait does not normally need to be added by hand. Confirm that the expected trait is present:

    openstack resource provider list
openstack resource provider list --required HW_ARCH_X86_64
openstack resource provider list --required HW_ARCH_AARCH64
openstack resource provider trait list <uuid-of-compute-host>

    If the trait is missing, for example when using a virt driver that does not report it, add it manually:

    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 использует для определения потенциальных вычислительных хостов. В этом разделе объясняется, как использовать их вместе.

    The image_metadata_prefilter only looks at the HW_ARCH_XXX traits on compute hosts and finds hardware that matches the required architecture. This only happens when the hw_architecture property is present on an image, and only if the required traits are set to compute hosts (see step 5).

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