Обновления дистрибутива¶

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

Примечание

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

Введение¶

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

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

Порядок¶

В этом руководстве приведен предлагаемый порядок выполнения обновлений. Он может быть изменен в зависимости от степени настройки вашего развертывания OpenStack-Ansible.

Очень важно учитывать, когда вы обновляете хосты/контейнеры «репозиториев“» Перед обновлением хостов/контейнеров API следует обновить хотя бы один хост «репозитория». Последний обновляемый хост «репозитория» должен быть «основным», и его обновление должно выполняться только после обновления последней службы, который не поддерживает «–limit».

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

Если приспособить этот порядок, то на середине процесса потребуется восстановить некоторые файлы на хосте «репозитория» из резервной копии. Это будет необходимо, если не останется хостов «репозитория», на которых работает старая версия операционной системы, что не позволяет собирать старые пакеты.

Помимо этих требований, предлагается следующий порядок обновления:

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

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

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

Убедитесь, что все узлы в вашем целевом развертывании были установлены и настроены с помощью соответствующей версии OpenStack-Ansible. В идеале сначала выполните незначительное обновление до последней версии цикла релиза OpenStack, который вы используете в данный момент, чтобы снизить риск столкновения с ошибками.
Проверьте все переменные OpenStack-Ansible, которые вы настраиваете, чтобы убедиться, что они учитывают новую и старую версию операционной системы (например, пользовательские репозитории пакетов и привязка версий).
Выполните резервное копирование критически важных данных, в частности базы данных Galera, на случай сбоев. Также рекомендуется создать резервную копию каталога /var/www/repo на основном хосте «репозитория» на случай, если его придется восстанавливать в процессе обновления.
Определите «основной» хост инфраструктуры HAProxy/Galera/RabbitMQ/repo

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

«Основной» будет ПОСЛЕДНИМ блоком, который вы захотите переустановить.
- HAProxy/Keepalived
  
  Найти свой основной HAProxy/Keepalived так же просто, как
```
ssh {{ external_lb_vip_address }}
```
  А лучше всего, если вы установили HAProxy со статистикой, например, так:
```
haproxy_stats_enabled: true
haproxy_stats_bind_address: "{{ external_lb_vip_address }}"
```
  и можете зайти на https://admin:password@external_lb_vip_address:1936/ и прочитать „Отчет по статистике для pid # на инфраструктурном узле“.
Убедитесь, что RabbitMQ запущен со всеми включенными флагами возможностей, чтобы избежать конфликтов при переустановке узлов. Если какие-либо из них указаны как отключенные, включите их через консоль на одном из узлов:
```
rabbitmqctl list_feature_flags
rabbitmqctl enable_feature_flag all
```

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

В процессе обновления некоторые службы OpenStack не могут быть развернуты с помощью команды Ansible „–limit“. Поэтому некоторые службы придется развертывать одновременно на смешанных версиях операционных систем.

Известно, что следующие службы не поддерживают --limit:
- RabbitMQ
- Сервер репозитория
- Keystone
Так же, как и при крупных (и некоторых мелких) обновлениях OpenStack-Ansible, во время обновления будут наблюдаться кратковременные перерывы в работе всех кластеров Galera и RabbitMQ, что приведет к кратковременным перебоям в обслуживании.
Когда инстансы «memcached» будут выключены для обновления, вы можете столкнуться с проблемами производительности API.

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

Отключите бекэнды 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
```
Или, если вы включили haproxy_stats, как описано выше, вы можете перейти по адресу https://admin:password@external_lb_vip_address:1936/, выбрать их и установить состояние «MAINT».
Переустановка операционной системы узла инфраструктуры

Как отмечалось выше, сначала это следует сделать для не основных хостов, в идеале начав с хоста „репозитория“.
Очистка от устаревшей информации
1. Удаление устаревших фактов из ansible-facts
```
rm /etc/openstack_deploy/ansible-facts/reinstalled_host*
```
  (* потому что мы удаляем все факты о контейнерах и для хоста.)
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
```
Выполните общую подготовку переустановленного хоста
```
openstack-ansible openstack.osa.setup_hosts --limit localhost,reinstalled_host*
```
Этот шаг должен быть выполнен, когда вы переконфигурируете один из хостов 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
```
Если он НЕ является «основным», установите все на новый хост.
```
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*
```
(* потому что нам нужно включить контейнеры в ограничение)
Если он является «основным», выполните следующие действия
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*
```
Настройте статус HAProxy

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

Для хоста «репозитория» важно, чтобы вновь установленные хосты были установлены в состояние «READY» в HAProxy, а все хосты, которые остались на старой операционной системе, были установлены в состояние «MAINT».

Вы также можете использовать плейбук из OPS repository для повторного включения всех бекэндов с хоста:
```
openstack-ansible set-haproxy-backends-state.yml -e hostname=reinstalled_host -e backend_state=enabled
```

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

Отключите службу гипервизора на вычислительных узлах и переведите все инстансы на другой доступный гипервизор.
Переустановите операционную систему хоста
Удалите устаревшие факты из ansible-facts
```
rm /etc/openstack_deploy/ansible-facts/reinstalled_host*
```
(* потому что мы также удаляем все факты о контейнерах для хоста)

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

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*

(* потому что нам нужно включить контейнеры в ограничение)

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

Вычислительные узлы должны иметь свой UUID в файле /var/lib/nova/compute_id, а служба «nova-compute» должна быть перезапущена. UUID можно найти, выполнив в командной строке openstack hypervisor list.

Кроме того, для автоматизации этих действий можно использовать следующий Ansible:
```
openstack-ansible ../scripts/upgrade-utilities/nova-restore-compute-id.yml --limit reinstalled_host
```

Обновления дистрибутива