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

Модернизация системы распределения

В этом руководстве содержится информация о переходе с одного выпуска дистрибутива на другой.

Примечание

Это руководство в последний раз обновлялось при переходе с Ubuntu Focal на Jammy во время выпуска Antelope (2023.1). Для более ранних релизов смотрите другие версии руководства.

Введение

OpenStack-Ansible supports operating system distribution upgrades during specific release cycles. These can be observed by consulting the operating system compatibility matrix, and identifying where two versions of the same operating system are supported.

Upgrades should be performed in the order specified in this guide to minimise the risk of service interruptions. Upgrades must also be carried out by performing a fresh installation of the target system’s operating system, before running OpenStack-Ansible to install services on this host.

Порядок

This guide includes a suggested order for carrying out upgrades. This may need to be adapted dependent on the extent to which you have customised your OpenStack-Ansible deployment.

Critically, it is important to consider when you upgrade „repo“ hosts/containers. At least one „repo“ host should be upgraded before you upgrade any API hosts/containers. The last „repo“ host to be upgraded should be the „primary“, and should not be carried out until after the final service which does not support „–limit“ is upgraded.

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

If this order is adapted, it will be necessary to restore some files to the „repo“ host from a backup part-way through the process. This will be necessary if no „repo“ hosts remain which run the older operating system version, which prevents older packages from being built.

Beyond these requirements, a suggested order for upgrades is a follows:

  1. Инфраструктурные сервисы (Galera, RabbitMQ, API, HAProxy)

    В любом случае сначала следует обновить вторичные или резервные инстансы

  2. Вычислительные узлы

  3. Сетевые узлы

Предварительные условия

  • Убедитесь, что все узлы в вашем целевом развертывании были установлены и настроены с помощью соответствующей версии OpenStack-Ansible. В идеале сначала выполните незначительное обновление до последней версии цикла выпуска OpenStack, который вы используете в данный момент, чтобы снизить риск столкновения с ошибками.

  • Проверьте все переменные OpenStack-Ansible, которые вы настраиваете, чтобы убедиться, что они учитывают новую и старую версию операционной системы (например, пользовательские репозитории пакетов и привязка версий).

  • Выполните резервное копирование критически важных данных, в частности базы данных Galera, на случай сбоев. Также рекомендуется создать резервную копию каталога „/var/www/repo“ на основном хосте „репозитория“ на случай, если его придется восстанавливать в процессе обновления.

  • Определите „основной“ хост инфраструктуры HAProxy/Galera/RabbitMQ/repo

    При простой настройке с 3 хостами инфраструктуры эти службы/контейнеры обычно располагаются на одном хосте.

    The „primary“ will be the LAST box you’ll want to reinstall.

    • HAProxy/Keepalived

      Найти свой основной HAProxy/Keepalived так же просто, как

      ssh {{ external_lb_vip_address }}
      

      Or preferably if you’ve installed HAProxy with stats, like so:

      haproxy_stats_enabled: true
      haproxy_stats_bind_address: "{{ external_lb_vip_address }}"
      

      and can visit https://admin:password@external_lb_vip_address:1936/ and read „Statistics Report for pid # on infrastructure_host“

  • Убедитесь, что RabbitMQ запущен со всеми включенными флагами возможностей, чтобы избежать конфликтов при переустановке узлов. Если какие-либо из них указаны как отключенные, включите их через консоль на одном из узлов:

    rabbitmqctl list_feature_flags
    rabbitmqctl enable_feature_flag all
    

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

  • During the upgrade process, some OpenStack services cannot be deployed by using Ansible’s „–limit“. As such, it will be necessary to deploy some services to mixed operating system versions at the same time.

    Известно, что следующие службы не поддерживают „–limit“:

    • RabbitMQ

    • Сервер репозитория

    • Keystone

  • Так же, как и при крупных (и некоторых мелких) обновлениях OpenStack-Ansible, во время обновления будут наблюдаться кратковременные перерывы в работе всех кластеров Galera и RabbitMQ, что приведет к кратковременным перебоям в обслуживании.

  • Когда инстансы „memcached“ будут выключены для обновления, вы можете столкнуться с проблемами производительности API.

Развертывание узлов инфраструктуры

  1. Отключите бекэнды HAProxy (необязательно)

    Если вы хотите минимизировать количество ошибок в HAProxy, службы на хостах, которые переустанавливаются, могут быть переведены в режим обслуживания (MAINT).

    Войдите в свой основной HAProxy/Keepalived и запустите что-то похожее на

    echo "disable server repo_all-back/<infrahost>_repo_container-<hash>" | socat /var/run/haproxy.stat stdio
    

    для каждого API или инстанса службы, которые вы хотите отключить.

    Вы также можете использовать плейбук из OPS-репозитория, например, так:

    openstack-ansible set-haproxy-backends-state.yml -e hostname=reinstalled_host -e backend_state=disabled
    

    Or if you’ve enabled haproxy_stats as described above, you can visit https://admin:password@external_lb_vip_address:1936/ and select them and „Set state to MAINT“

  2. Переустановка операционной системы узла инфраструктуры

    Как отмечалось выше, сначала это следует сделать для не основных хостов, в идеале начав с хоста „репозитория“.

  3. Очистка от устаревшей информации

    1. Удаление устаревших фактов из ansible-facts

      rm /etc/openstack_deploy/ansible-facts/reinstalled_host*
      

      (* because we’re deleting all container facts for the host as well.)

    2. Если RabbitMQ запущен на этом хосте

      Мы забудем об этом, выполнив эти команды на другом хосте RabbitMQ.

      rabbitmqctl cluster_status
      rabbitmqctl forget_cluster_node rabbit@removed_host_rabbitmq_container
      
    3. Если GlusterFS была запущена на этом узле (узлы репозитория)

      Мы забываем об этом, выполняя эти команды на другом хосте репозитория. Обратите внимание, что нам нужно сообщить Gluster, что мы намеренно уменьшаем количество реплик. „N“ должно быть равно количеству репо-серверов минус 1. Имена существующих пиров Gluster можно узнать с помощью команды „gluster peer status“.

      gluster volume remove-brick gfs-repo replica N removed_host_gluster_peer:/gluster/bricks/1 force
      gluster peer detach removed_host_gluster_peer
      
  4. Выполните общую подготовку переустановленного хоста

    openstack-ansible openstack.osa.setup_hosts --limit localhost,reinstalled_host*
    
  5. Этот шаг должен быть выполнен, когда вы переконфигурируете один из хостов HAProxy

    Поскольку настройка бекэндов HAProxy происходит во время предоставления отдельных служб, нам нужно убедиться, что все бекэнды настроены, прежде чем разрешить Keepalived выбирать этот хост.

    Команды ниже настроят все необходимые бекенды на узлах HAProxy:

    openstack-ansible openstack.osa.haproxy --limit localhost,reinstalled_host --skip-tags keepalived
    openstack-ansible openstack.osa.repo --tags haproxy-service-config
    openstack-ansible openstack.osa.galera_server --tags haproxy-service-config
    openstack-ansible openstack.osa.rabbitmq_server --tags haproxy-service-config
    openstack-ansible openstack.osa.setup_openstack --tags haproxy-service-config
    

    Как только это будет сделано, вы сможете снова развернуть Keepalived:

    openstack-ansible openstack.osa.haproxy --tags keepalived --limit localhost,reinstalled_host
    

    После этого вы, возможно, захотите убедиться, что «локальные» бэкенды остаются отключенными. Для этого также можно использовать плейбук из OPS repository:

    openstack-ansible set-haproxy-backends-state.yml -e hostname=reinstalled_host -e backend_state=disabled --limit reinstalled_host
    
  6. Если он НЕ является „основным“, установите все на новый хост.

    openstack-ansible openstack.osa.setup_infrastructure --limit localhost,repo_all,rabbitmq_all,reinstalled_host*
    openstack-ansible openstack.osa.setup_openstack --limit localhost,keystone_all,reinstalled_host*
    

    (* because we need to include containers in the limit)

  7. Если он является „основным“, выполните следующие действия

    1. Временно установите свою основную Galera в MAINT в HAProxy.

      Для того чтобы роль не сделала вашу основную Galera как UP в HAProxy, создайте пустой файл /var/tmp/clustercheck.disabled . Вы можете сделать это с помощью ad-hoc:

      cd /opt/openstack-ansible
      ansible -m file -a "path=/var/tmp/clustercheck.disabled state=touch" 'reinstalled-host*:&galera_all'
      

      Когда все готово, вы можете запустить плейбук для установки MariaDB в место назначения

      openstack-ansible openstack.osa.galera_server --limit localhost,reinstalled_host* -e galera_server_bootstrap_node="{{ groups['galera_all'][-1] }}"
      

      Теперь у вас будет запущен mariadb, и он должен быть синхронизирован с неосновными серверами.

      Чтобы проверить состояние кластера MariaDB, выполните с хоста, на котором запущена основная MariaDB, следующую команду:

      mariadb -e 'SHOW STATUS LIKE "wsrep_cluster_%";'
      

      Если узел не синхронизируется, возможно, вам нужно перезапустить службу mariadb.service и проверить, все ли в порядке.

      systemctl restart mariadb.service
      mariadb
      MariaDB> SHOW STATUS LIKE "wsrep_cluster_%";
      MariaDB> SHOW DATABASES;
      

      Когда кластер MariaDB будет здоров, вы можете удалить файл, который запрещает бекенду использовать HAProxy.

      ansible -m file -a "path=/var/tmp/clustercheck.disabled state=absent" 'reinstalled-host_containers:&galera_all'
      
    2. Мы можем перейти к первичной обработке RabbitMQ

      openstack-ansible openstack.osa.rabbitmq_server -e rabbitmq_primary_cluster_node="{{ hostvars[groups['rabbitmq_all'][-1]]['ansible_facts']['hostname'] }}"
      
    3. Теперь основной хост репозитория

      openstack-ansible openstack.osa.repo -e glusterfs_bootstrap_node="{{ groups['repo_all'][-1] }}"
      
    4. Теперь все должно быть в рабочем состоянии, и мы можем завершить его с помощью

      openstack-ansible openstack.osa.setup_infrastructure --limit localhost,repo_all,rabbitmq_all,reinstalled_host*
      openstack-ansible openstack.osa.setup_openstack --limit localhost,keystone_all,reinstalled_host*
      
  8. Настройте статус HAProxy

    Если HAProxy был установлен в режим MAINT, теперь его можно удалить для восстановленных сервисов.

    For the „repo“ host, it is important that the freshly installed hosts are set to READY in HAProxy, and any which remain on the old operating system are set to „MAINT“.

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

    openstack-ansible set-haproxy-backends-state.yml -e hostname=reinstalled_host -e backend_state=enabled
    

Развертывание вычислительных и сетевых узлов

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

  2. Переустановите операционную систему хоста

  3. Удалите устаревшие факты из ansible-facts

    rm /etc/openstack_deploy/ansible-facts/reinstalled_host*
    

    (* because we’re deleting all container facts for the host as well.)

  4. Выполните следующие действия:

    openstack-ansible openstack.osa.setup_hosts --limit localhost,reinstalled_host*
    openstack-ansible openstack.osa.setup_infrastructure --limit localhost,reinstalled_host*
    openstack-ansible openstack.osa.setup_openstack --limit localhost,reinstalled_host*
    

    (* because we need to include containers in the limit)

  5. Заново установите UUID гипервизора вычислительного узла

    Compute nodes should have their UUID stored in the file „/var/lib/nova/compute_id“ and the „nova-compute“ service restarted. UUIDs can be found from the command line’openstack hypervisor list“.

    Кроме того, для автоматизации этих действий можно использовать следующий Ansible:

    openstack-ansible ../scripts/upgrade-utilities/nova-restore-compute-id.yml --limit reinstalled_host