Обновление региона KeyStack до версии 2025.1.1 вместе с ОС узлов

В этом разделе описаны шаги по обновлению операционных систем узлов с последующим развёртыванием на них целевой версии KeyStack. Обновление операционных систем происходит путём полного удаления старой версии ОС и установки новой версии ОС.

Проверка работоспособности региона

Перед тем как приступать к обновлению, необходимо проверить состояние облачной инфраструктуры. Эта проверка необходима для минимизации рисков и поддержания стабильности системы. Проверка работоспособности региона позволяет убедиться, что виртуальные машины создаются и доступны по сети, что подтверждает работоспособность цепочки сервисов (MariaDB, HAProxy, Cinder, Nova, Neutron, Glance).

  1. Подключитесь к интерфейсу OpenStack CLI.

  2. Проверьте сетевую доступность всех узлов облака с помощью команды ping.

  3. Выполните команду openstack compute service list для проверки состояния вычислительных сервисов. Убедитесь, что все сервисы находятся в состоянии up.

  4. Выполните команду openstack volume service list для проверки состояния службы томов. Убедитесь, что все сервисы находятся в состоянии up.

  5. Выполните команду openstack server list для проверки состояния виртуальных машин.

  6. Используя OpenStack CLI, портал самообслуживания Horizon или Портал администратора, создайте несколько ВМ с различными флейворами и выполните их live-миграцию.

Примечание

Убедитесь в наличии настройки LACP Fallback на загрузочном порте каждого обновляемого сервера перед запуском пайплайна развёртывания ОС.

Отключение сервисов DRS и HA

Перед началом обновления необходимо отключить сервисы DRS и HA.

Для деактивации DRS:

  1. Войдите в Портал администратора.

  2. Перейдите в раздел DRS > Jobs.

  3. Деактивируйте все задания сервиса DRS.

Для деактивации HA:

  1. Зайдите на каждый Control-узел по SSH и выполните команду:

    # systemctl stop kolla-consul-container.service

Обновление RabbitMQ

Перед обновлением региона необходимо выполнить обновление RabbitMQ. Для обновления RabbitMQ до версии 3.12 выполните следующие действия:

  1. Зайдите в веб-интерфейс GitLab по адресу https://ks-lcm.cloud.itkey.com.

  2. Перейдите в репозиторий вашего региона project_k / deployments / <имя региона>.

  3. Создайте новый пайплайн: Build > Pipelines > Run Pipeline.

  4. В переменной KOLLA_ANSIBLE_DEPLOY_ACTION укажите значение rabbitmq-upgrade 3.12.

  5. Запустите пайплайн, нажав кнопку Run pipeline.

  6. Дождитесь завершения задач на этапе setup.

  7. Запустите задачу deploy на этапе deploy и дождитесь её завершения.

Выполните проверку RabbitMQ:

  1. Зайдите на Control-узел по SSH.

  2. Выполните команды проверки:

    # docker ps -af name=rabbitmq
# docker exec rabbitmq bash -c 'rabbitmqctl cluster_status | grep 'Node''

Контейнер должен находиться в состоянии healthy. В выводе должны присутствовать все Control-узлы.

Настройка GitLab

Проверьте значения переменных CI/CD:

  1. Зайдите в веб-интерфейс GitLab.

  2. Перейдите в репозиторий вашего региона project_k / deployments / <имя региона>.

  3. Перейдите в раздел Settings > CI/CD > Variables.

  4. Убедитесь в наличии переменной BASE со значением sberlinux.

  5. Если переменная отсутствует:

    1. Нажмите Add variable.

    2. Введите в поле Key значение BASE.

    3. Введите в поле Value значение sberlinux.

    4. Уберите флаг Protect variable и сохраните изменения.

Измените конфигурацию пайплайна:

  1. Зайдите в веб-интерфейс GitLab по адресу https://ks-lcm.cloud.itkey.com.

  2. Перейдите в репозиторий вашего региона project_k / deployments / <имя региона>.

  3. Откройте файл .gitlab-ci.yml в репозитории региона.

  4. В переменной KEYSTACK_RELEASE укажите версию релиза, на которую производится обновление — ks2025.1.1:

    KEYSTACK_RELEASE:
  value: &KEYSTACK_RELEASE ks2025.1.1

Настройте таймаут для пайплайнов:

  1. Перейдите в раздел Settings > CI/CD > General pipelines.

  2. Установите значение Timeout — 5h.

Установка Bifrost

Если на узле LCM используется firewall, необходимо добавить следующие исключения для Bifrost:

  • 67/UDP — для обслуживания DHCP-запросов,

  • 8080/TCP — для загрузки файлов по HTTP (iPXE, Ironic-Python-Agent),

  • 69/UDP для передачи файлов через TFTP (начальный бинарный файл iPXE),

  • 5050/TCP для introspection API,

  • 6385/TCP для Ironic API.

Выполните настройку firewall на узле LCM:

  1. Зайдите на узел LCM по SSH.

  2. Откройте TCP-порты 8080, 5050, 6385 и UDP-порты 67, 69:

Выполните команды настройки firewalld:

# firewall-cmd --add-port=8080/tcp --permanent
# firewall-cmd --add-port=5050/tcp --permanent
# firewall-cmd --add-port=6385/tcp --permanent
# firewall-cmd --add-service=dhcp --permanent
# firewall-cmd --add-service=tftp --permanent
# firewall-cmd --reload

Проверьте CI/CD переменные в GitLab:

  1. Перейдите в веб-интерфейс GitLab по адресу https://ks-lcm.cloud.itkey.com.

  2. Перейдите в репозиторий project_k / services / baremetal.

  3. Перейдите в раздел Settings > CI/CD > Variables.

  4. Проверьте наличие переменных NEXUS_FQDN и NEXUS_USER в списке.

  5. При отсутствии, добавьте их:

    • Нажмите Add variable.

    • Снимите флаг Protect variable. Переменные не должны быть protected.

    • Укажите Key и Value:

      • NEXUS_FQDN со значением полного доменного имени сервиса Nexus;

      • NEXUS_USER со значением admin.

Установка Bifrost выполняется через запуск пайплайна GitLab:

  1. Перейдите в веб-интерфейс GitLab.

  2. Перейдите в репозиторий project_k / deployments / bifrost.

  3. Откройте файл inventory и замените в нем значение LCM_IP на IP-адрес LCM-узла.

  4. Откройте файл globals.d/REGION.yml и замените значение параметра network_interface на имя интерфейса LCM-узла, на котором будет работать PXE, например, bond0. Убедитесь, что выбран именно тот интерфейс, который соответствует PXE-сети.

  5. Откройте файл config/bifrost/bifrost.yml и внесите в него изменения:

    1. Измените следующие строки, заменив LCM_IP на IP-адрес LCM-узла:

      ipa_kernel_url: "http://LCM_IP:8080/ipa-centos9-debug-anthelope.kernel"
ipa_ramdisk_url: "http://LCM_IP:8080/ipa-centos9-debug-anthelope.initramfs"

    2. Добавьте свой NTP-сервер, раскомментировав следующую строку и замените в ней 10.224.128.1 на IP-адрес своего NTP-сервера:

      #inspector_extra_kernel_options: "ipa-inspection-collectors=default,logs ipa-ntp-server=10.224.128.1"

  6. Создайте новый пайплайн: Build > Pipelines > Run Pipeline.

  7. Запустите пайплайн, нажав кнопку Run pipeline.

  8. Дождитесь завершения задач на этапе setup.

  9. Запустите шаг deploy-bifrost.

  10. Дождитесь завершения выполнения пайплайна.

Скопируйте необходимые образы для работы Bifrost:

  1. Зайдите на LCM-узел по SSH и выполните команду:

    # docker exec -ti bifrost_deploy bash
(bifrost-deploy)# cd httpboot
(bifrost-deploy)# curl -k https://NEXUS_FQDN/repository/images/ipa-centos9-debug-anthelope.kernel -o ipa-centos9-debug-anthelope.kernel
(bifrost-deploy)# curl -k https://NEXUS_FQDN/repository/images/ipa-centos9-debug-anthelope.initramfs -o ipa-centos9-debug-anthelope.initramfs

Настройка параметров IP в Bifrost

При провиженинге узлам будут назначены адреса и прочие параметры IP, указанные на этом шаге. Для этого используется сервис dnsmasq. Настройте эти параметры:

  1. Зайдите на LCM-узел по SSH и выполните команду:

    # docker exec -ti bifrost_deploy bash
(bifrost-deploy)# vi /etc/dnsmasq.conf

  2. В открывшемся файле поменяйте значения:

    • listen-address=LCM_IP: замените LCM_IP на IP-адрес LCM-узла;

    • dhcp-boot=tag:ipxe,http://LCM_IP:8080/boot.ipxe: замените LCM_IP на IP-адрес LCM-узла;

    • dhcp-range=10.0.0.10,10.0.0.100,255.255.255.0,24h: укажите диапазон IP-адресов для выдачи серверам через DHCP;

    • dhcp-option=3,10.0.0.254: укажите адрес шлюза по умолчанию для IP-адресов, выдаваемых по DHCP.

  3. Сохраните изменения и закройте файл.

  4. Перезапустите сервис dnsmasq, выполнив команды:

    (bifrost-deploy)# systemctl enable dnsmasq
(bifrost-deploy)# systemctl restart dnsmasq
(bifrost-deploy)# systemctl status dnsmasq

    Убедитесь, что статус сервиса отображается как active (running).

Получение и добавление токена NetBox в Vault

Добавьте токен доступа к NetBox в сервис Vault, для этого выполните действия:

  1. Зайдите в веб-интерфейс NetBox по адресу https://netbox.cloud.itkey.com.

  2. Перейдите в раздел Admin > API Tokens.

  3. Скопируйте значение ключа из столбца KEY.

  4. Перейдите в веб-интерфейс Vault по адресу https://vault.cloud.itkey.com.

  5. Перейдите в директорию secret_v2 / deployments / secrets / accounts.

  6. Нажмите Create new, чтобы создать новую версию секрета.

  7. Обновите ключ NETBOX_TOKEN скопированным значением. Если ключ не существует, добавьте его.

Обновление Control-узлов

Обновление узлов Control выполняется поочерёдно. Рекомендуется делать обновление серверов по порядку по одному, начиная с первого Control-узла. Для каждого узла вначале выполняется переустановка операционной системы, а затем обновление версии KeyStack.

Выполните шаги двух следующих разделов последовательно для каждого Control-узла.

Переустановка ОС на Control-узлах

Переведите сервер, на котором будет производиться обновление ОС, в статус ready:

  1. Зайдите в веб-интерфейс NetBox.

  2. Перейдите в раздел Devices > Devices.

  3. Отметьте необходимый узел.

  4. Нажмите Edit Selected.

  5. В открывшейся форме для параметра state в разделе Custom Fields установите значение ready.

  6. Дополнительно проверьте корректность значений полей ROLE и TAGS.

    Состояние сервера ready

    Состояние сервера ready

Запустите пайплайн для развёртывания системы на Control-узлах.

  1. Откройте веб-интерфейс GitLab.

  2. Перейдите в репозиторий project_k / services / baremetal.

  3. Создайте новый пайплайн: Build > Pipelines > Run Pipeline.

  4. В открывшемся окне укажите значения переменных:

    • TARGET_ROLE — controller;

    • TARGET_CLOUD — имя тега региона в NetBox;

    • TARGET_NODE — имя конкретного узла для развёртывания, если необходимо ограничить развёртывание одним узлом;

    • IRONIC_IMAGE_URL — путь до образа системы, который будет установлен на узел, в формате http://<IP-адрес LCM>:8080/sberlinux-9.4.3-x86_64.qcow2. Требования к образу:

      • только поддерживаемый тип операционной системы,

      • формат QCOW2,

      • hash-файл образа в формате <имя образа>.md5 располагается в одной папке с самим образом.

    • IRONIC_IMAGE_ROOTFS_UUID — UUID корневого раздела в образе, если используется программный RAID;

    • IPA_KERNEL_NAME — путь до образа агента Ironic Python Agent (IPA) kernel image;

    • IPA_RAMDISK_NAME — путь до образа агента Ironic Python Agent (IPA) initramfs image;

    • KOLLA_ANSIBLE_IMG_TAG — тег контейнера с kolla-ansible, используемый для пайплайна;

    • EXPERIMENTAL_NETBOX_INTROSPECTION: true — использовать автозаполнение интерфейсов устройств в NetBox.

    • KEYSTACK_RELEASE — тег релиза Keystack;

    • CI_DEBUG_TRACE:

      • true — выводить отладочную информацию в пайплайне,

      • false — не выводить отладочную информацию.

  5. Запустите пайплайн, нажав кнопку Run pipeline.

  6. Дождитесь завершения выполнения операции. По результату выполнения пайплайна на сервере будет установлена операционная система.

Далее выполните инструкции из следующего раздела для обновления версии KeyStack на этом узле.

Обновление KeyStack на Control-узлах

Остановите и удалите сервисы контейнеров kolla-mariadb_clustercheck-container.service и kolla-prometheus_haproxy_exporter-container.service:

  1. Зайдите на каждый Control-узел по SSH.

  2. Выполните команды:

    # systemctl stop kolla-mariadb_clustercheck-container.service
# systemctl stop kolla-prometheus_haproxy_exporter-container.service

# systemctl disable kolla-mariadb_clustercheck-container.service
# systemctl disable kolla-prometheus_haproxy_exporter-container.service

Выполните перечисленные действия:

  1. Зайдите в веб-интерфейс GitLab.

  2. Перейдите в репозиторий вашего региона project_k / deployments / <имя региона>.

  3. Откройте файл globals.d/REGION.yml.

  4. Проверьте, что в файле отсутствуют или закомментированы следующие параметры:

    • docker_yum_gpgkey

    • docker_yum_url

    • docker_yum_baseurl

  5. Создайте новый пайплайн: Build > Pipelines > Run Pipeline.

  6. Сначала необходимо выполнить пайплайн без развёртывания компонента Keystone. Установите значение переменной KOLLA_ARGS равное --skip-tags keystone --limit control[<номер Control-узла>] для обновления одного узла. Нумерация узлов начинается с нуля. Для первого Control-узла укажите 0, для второго 1 и так далее.

  7. Запустите пайплайн, нажав кнопку Run pipeline.

  8. Дождитесь завершения задач на этапе setup.

  9. Запустите задачу deploy на этапе deploy и дождитесь её завершения.

  10. Последовательно запустите задачи bootstrap-servers и deploy, дождавшись выполнения каждой.

  11. Повторно создайте новый пайплайн: Build > Pipelines > Run Pipeline.

  12. Установите значение переменной KOLLA_ARGS равное -t keystone для выполнения пайплайна только для компонента KeyStone.

  13. Запустите пайплайн, нажав кнопку Run pipeline.

  14. Дождитесь завершения задач на этапе setup.

После обновления Control-узла на нём запускается сервис Consul, обеспечивающий функцию HA. Наличие этого сервиса во включённом состоянии нежелательно, если в дальнейшем планируется обновление Compute-узлов. Выключите сервис Consul:

  1. Зайдите на Control-узел по SSH.

  2. Выполните команду:

    # systemctl stop kolla-consul-container.service

Повторите шаги по переустановке ОС и установке KeyStack для всех остальных Control-узлов региона поочерёдно, указав значения --limit control[1] для второго Control-узла, --limit control[2] для третьего Control-узла соответственно.

Подготовка к обновлению Compute-узлов

Проверка временно недоступных узлов

Если перед обновлением в регионе есть временно недоступные Compute-узлы, выполните дополнительную проверку:

  1. Зайдите на узел LCM по SSH.

  2. Выполните команду:

    $ openstack compute service list

  3. Убедитесь, что:

    • значения updated_at для всех узлов схожи;

    • ни один из узлов не выполняет обновления статусов чаще других;

    • отсутствует up/down флап (переменное переключение) статусов;

    • отсутствуют неожидаемые статусы down.

  4. Зафиксируйте недоступные узлы.

  5. Зайдите в веб-интерфейс GitLab.

  6. Перейдите в репозиторий вашего региона project_k / deployments / <имя региона>.

  7. Откройте файл inventory и закомментируйте в нём все недоступные узлы.

Совет

После возврата недоступных узлов в регион необходимо их раскомментировать и запустить шаг пайплайна deploy без тегов, но с указанием переменной KOLLA_ARGS равной --limit hostname1.

Проверка маппингов СХД

Убедитесь в отсутствии маппингов на системе хранения данных в сторону гипервизора:

  1. Зайдите на обновляемый Compute-узел по SSH.

  2. Выполните команду: docker exec -it multipathd multipath -ll.

  3. Проверьте, содержит ли вывод команды пути со статусом ACTIVE. При наличии таких путей обратитесь к специалистам по СХД для их удаления.

Обновление Compute-узлов

Переустановка ОС на Compute-узлах

Перед выполнением обновления Compute-узла, его необходимо освободить от виртуальных машин. Освободите один или несколько гипервизоров от виртуальных машин одним из перечисленных способов:

Переведите серверы, на которых будет производиться обновление ОС, в статус ready:

  1. Зайдите в веб-интерфейс NetBox.

  2. Перейдите в раздел Devices > Devices.

  3. Отметьте все необходимые узлы.

  4. Нажмите Edit Selected.

  5. В открывшейся форме для параметра state в разделе Custom Fields установите значение ready.

  6. Дополнительно проверьте корректность значений полей ROLE и TAGS.

    Состояние сервера ready

    Состояние сервера ready

Запустите пайплайн для развёртывания системы на Compute-узлах:

  1. Откройте веб-интерфейс GitLab.

  2. Перейдите в репозиторий project_k / services / baremetal.

  3. Создайте новый пайплайн: Build > Pipelines > Run Pipeline.

  4. В открывшемся окне укажите значения переменных:

    • TARGET_ROLE — compute;

    • TARGET_CLOUD — имя тега региона в NetBox;

    • TARGET_NODE — имя конкретного узла для развёртывания, если необходимо ограничить развёртывание одним узлом;

    • IRONIC_IMAGE_URL — путь до образа системы, который будет установлен на узел, в формате http://<IP-адрес LCM>:8080/sberlinux-9.4.3-x86_64.qcow2. Требования к образу:

      • только поддерживаемый тип операционной системы,

      • формат QCOW2,

      • hash-файл образа в формате <имя образа>.md5 располагается в одной папке с самим образом.

    • IRONIC_IMAGE_ROOTFS_UUID — UUID корневого раздела в образе, если используется программный RAID;

    • IPA_KERNEL_NAME — путь до образа агента Ironic Python Agent (IPA) kernel image;

    • IPA_RAMDISK_NAME — путь до образа агента Ironic Python Agent (IPA) initramfs image;

    • KOLLA_ANSIBLE_IMG_TAG — тег контейнера с kolla-ansible, используемый для пайплайна;

    • EXPERIMENTAL_NETBOX_INTROSPECTION: true — использовать автозаполнение интерфейсов устройств в NetBox.

    • KEYSTACK_RELEASE — тег релиза Keystack;

    • CI_DEBUG_TRACE:

      • true — выводить отладочную информацию в пайплайне,

      • false — не выводить отладочную информацию.

  5. Запустите пайплайн, нажав кнопку Run pipeline.

  6. Дождитесь завершения выполнения операции. По результату выполнения пайплайна на сервере будет установлена операционная система.

Выведите гипервизор из работы в облаке:

  1. Зайдите на узел LCM по SSH.

  2. Выполните команды для установки пакета OpenStack Placement osc-placement:

    $ pip3 install osc-placement

  3. Выполните команды, указав имя гипервизора в переменной HOST_FOR_REMOVAL:

    $ HOST_FOR_REMOVAL=compute01
$ openstack --os-compute-api-version 2.87 compute service list \
    --host $HOST_FOR_REMOVAL --service nova-compute -f value -c ID | \
    xargs openstack --os-compute-api-version 2.87 compute service delete

$ openstack network agent list --host $HOST_FOR_REMOVAL -f value -c ID | \
    while read agent_id; do \
    openstack network agent delete $agent_id; \
    done

$ openstack resource provider list --name $HOST_FOR_REMOVAL -f value -c uuid | \
    xargs openstack resource provider show --allocations -f json | \
    jq .allocations | jq 'keys[]' | \
    xargs -n1 openstack resource provider allocation delete

$ openstack resource provider list --name $HOST_FOR_REMOVAL -f value -c uuid  | \
    xargs openstack resource provider delete

Далее выполните инструкции из следующего раздела для обновления версии KeyStack на этих узлах.

Обновление KeyStack на Compute-узлах

Выполните перечисленные действия:

  1. Зайдите в веб-интерфейс GitLab.

  2. Перейдите в репозиторий вашего региона project_k / deployments / <имя региона>.

  3. Создайте новый пайплайн: Build > Pipelines > Run Pipeline.

  4. В переменной KOLLA_ARGS укажите значение --limit hostname1,hostname2, перечислив имена гипервизоров, указанные в файле inventory вашего региона.

    Подсказка

    Значение параметра --limit можно указывать различными способами. Например, если ваш файл inventory содержит такие имена узлов:

    [compute]
cdm-sl-pca35.domain.company.ru
cdm-bl-pca02.domain.company.ru
cdm-bl-pca03.domain.company.ru
cdm-bl-pca20.domain.company.ru

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

    • --limit cdm-sl-pca35.domain.company.ru,cdm-bl-pca02.domain.company.ru,cdm-bl-pca03.domain.company.ru

    • --limit cdm-sl-pca35*,cdm-bl-pca02*,cdm-bl-pca03*

    • --limit cdm-sl-pca35*,cdm-bl-pca0[2,3]*

  5. Запустите пайплайн, нажав кнопку Run pipeline.

  6. Дождитесь завершения задач на этапе setup.

  7. Запустите шаги bootstrap-servers и deploy по очереди, дождавшись выполнения каждого.

  8. Добавьте гипервизор в нужный хост-агрегат.

Проверьте состояние узлов после обновления и при необходимости выведите узлы из режима обслуживания (maintenance mode):

  1. Выполните команду:

    # openstack compute service list --long

  2. Если какие-то гипервизоры находятся в режиме обслуживания, выведите их из него. Например, это можно сделать следующей командой:

    # openstack compute service set --up --enable <имя узла> nova-compute

  3. Проведите живую миграцию виртуальных машин на обновлённый гипервизор.

Повторите шаги запуска пайплайна для всех Compute-узлов по одному или порциями до полного обновления региона.

Проверка работоспособности региона после обновления

Выполните все шаги проверки из раздела Проверка работоспособности региона.

Включение сервисов DRS и HA

Для включения DRS:

  1. Войдите в Портал администратора.

  2. Перейдите в раздел DRS > Jobs.

  3. Активируйте все задания сервиса DRS.

Для включения HA:

  1. Зайдите на каждый Control-узел по SSH и выполните команду:

    # systemctl start kolla-consul-container.service