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

发行版升级

本指南提供了有关从一个发行版版本升级到下一个版本的信息。

注意

本指南最后更新于 Antelope (2023.1) 版本期间，从 Ubuntu 20.04 (Focal Fossa) 升级到 Ubuntu 22.04 (Jammy Jellyfish)。对于早期版本，请参阅本指南的其他版本。

介绍

OpenStack-Ansible 在特定的发布周期内支持操作系统发行版升级。可以通过查阅操作系统兼容性矩阵，并确定相同操作系统的两个版本是否都受支持来观察到这一点。

应按照本指南中指定的顺序执行升级，以最大程度地降低服务中断的风险。升级还必须通过先全新安装目标系统操作系统，然后运行 OpenStack-Ansible 在此主机上安装服务来执行。

顺序

本指南包含执行升级的建议顺序。这可能需要根据您自定义 OpenStack-Ansible 部署的程度进行调整。

至关重要的是，要考虑何时升级“repo”主机/容器。在升级任何 API 主机/容器之前，至少应升级一个“repo”主机。要升级的最后一个“repo”主机应该是“primary”，并且不应在升级最后一个不支持“–limit”的服务之后才执行。

如果您有跨架构部署，则在升级使用该架构的任何其他主机之前，需要升级每个架构的至少一个“repo”主机。

如果调整了此顺序，则需要在过程中从备份中将一些文件恢复到“repo”主机。如果不再有运行旧操作系统版本的“repo”主机，这将是必要的，这会阻止构建较旧的软件包。

除了这些要求之外，升级的建议顺序如下

1. 基础设施服务 (Galera, RabbitMQ, APIs, HAProxy)

   在所有情况下，应先升级辅助或备份实例

2. 计算节点

3. 网络节点

先决条件

• 确保目标部署中的所有主机都已使用匹配版本的 OpenStack-Ansible 安装和配置。理想情况下，首先将 OpenStack release cycle 升级到您当前运行的最新版本，以降低遇到错误的风险。

• 检查您自定义的任何 OpenStack-Ansible 变量，以确保它们考虑到新的和旧的操作系统版本（例如自定义软件包仓库和版本固定）。

• 备份关键数据，特别是 Galera 数据库，以防发生任何故障。 建议备份 primary “repo”主机上的‘/var/www/repo’目录，以防在升级过程中需要恢复它。

• 识别您的 ‘primary’ HAProxy/Galera/RabbitMQ/repo 基础设施主机

  在简单的 3 个基础设施主机设置中，这些服务/容器通常最终都在同一主机上。

  ‘primary’ 将是您希望重新安装的最后一个盒子。

  • HAProxy/Keepalived

    查找您的 HAProxy/Keepalived primary 就像

    ssh {{ external_lb_vip_address }}
    

    或者最好的是，如果您使用 stats 安装了 HAProxy，如下所示

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

    并访问 https://admin:password@external_lb_vip_address:1936/ 并阅读 ‘Statistics Report for pid # on infrastructure_host’

• 确保 RabbitMQ 正在运行，并且所有 feature flags 都已启用，以避免重新安装节点时发生冲突。 如果有任何被列为禁用的，请通过控制台在其中一个节点上启用它们

  rabbitmqctl list_feature_flags
  rabbitmqctl enable_feature_flag all
  

警告

• 在升级过程中，某些 OpenStack 服务无法通过 Ansible 的 ‘–limit’ 部署。 因此，将需要在同一时间将一些服务部署到混合操作系统版本。

  已知以下服务缺乏对 ‘–limit’ 的支持

  • RabbitMQ

  • Repo Server

  • Keystone

• 与 OpenStack-Ansible 主要（和一些次要）升级一样，在升级过程中 Galera 和 RabbitMQ 集群将会有短暂的中断，这将导致短暂的服务中断。

• 在为升级关闭 ‘memcached’ 实例时，您可能会遇到 API 的性能问题。

部署基础设施主机

1. 将重新部署的主机定义为环境变量

   这将作为未来操作的快捷方式，并使遵循说明更容易出错。 例如

   export REINSTALLED_HOST="infra3"
   

2. 禁用 HAProxy 后端（可选）

   如果您希望最大程度地减少 HAProxy 中的错误状态，则可以设置正在重新安装的主机上的服务处于维护模式 (MAINT)。

   登录到您的 primary HAProxy/Keepalived 并运行类似如下命令

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

   对于您要禁用的每个 API 或服务实例。

   您也可以使用 playbook 来执行此操作

   openstack-ansible openstack.osa.tools.set_haproxy_backends_state -e hostname=${REINSTALLED_HOST} -e backend_state=disabled
   

   或者，如果您启用了 haproxy_stats，如上所述，您可以访问 https://admin:password@external_lb_vip_address:1936/ 并选择它们并将状态设置为 MAINT。

3. 重新安装基础设施主机的操作系统

   如上所述，应先对非 primary 主机执行此操作，理想情况下从一个 ‘repo’ 主机开始。

4. 清除过时信息

   1. 删除过时的 ansible-facts

      rm /etc/openstack_deploy/ansible-facts/${REINSTALLED_HOST}*
      

      (* 因为我们正在删除主机的所有容器 facts)

   2. 如果 RabbitMQ 正在此主机上运行

      我们通过在另一个 RabbitMQ 主机上运行这些命令来忘记它。

      rabbitmqctl cluster_status
      rabbitmqctl forget_cluster_node rabbit@removed_host_rabbitmq_container
      

   3. 如果 GlusterFS 正在此主机上运行 (repo 节点)

      我们通过在另一个 repo 主机上运行这些命令来忘记它。 请注意，我们必须告诉 Gluster 我们正在故意减少副本的数量。 ‘N’ 应设置为 repo 服务器的数量减 1。可以使用 ‘gluster peer status’ 命令找到现有的 gluster peer 名称。

      gluster volume remove-brick gfs-repo replica N removed_host_gluster_peer:/gluster/bricks/1 force
      gluster peer detach removed_host_gluster_peer
      

5. 执行重新安装主机的通用准备

   openstack-ansible openstack.osa.setup_hosts --limit localhost,${REINSTALLED_HOST}*
   

6. 当您重新配置 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}
   

   之后，您可能希望确保 “local” 后端保持禁用状态。 您也可以使用 playbook 来执行此操作

   openstack-ansible openstack.osa.tools.set_haproxy_backends_state -e hostname=${REINSTALLED_HOST} -e backend_state=disabled --limit ${REINSTALLED_HOST}
   

7. 如果它不是 ‘primary’，请在新主机上安装所有内容

   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}*
   

   (* 因为我们需要在 limit 中包含容器)

8. 如果是 ‘primary’，请执行以下步骤

   1. 暂时将您的 primary Galera 设置为 HAProxy 中的 ‘MAINT’。

      为了防止角色将您的 primary Galera 作为 HAProxy 中的 UP，创建一个空文件 /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"
      

      完成此操作后，您可以运行 playbook 将 MariaDB 安装到目标

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

      现在您将拥有正在运行的 MariaDB，并且它应该与非 primary 同步。

      要检查是否同步，请从运行 primary 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}*:&galera_all"
      

   2. 我们可以继续进行 repo 主机 primary

      openstack-ansible openstack.osa.rabbitmq_server -e rabbitmq_primary_cluster_node="{{ hostvars[groups['rabbitmq_all'][-1]]['ansible_facts']['hostname'] }}"
      

   3. 现在 repo 主机 primary

      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}*
      

9. 调整 HAProxy 状态

   如果 HAProxy 设置为 ‘MAINT’ 模式，现在可以为已恢复的服务删除它。

   对于 ‘repo’ 主机，重要的是将新安装的主机设置为 HAProxy 中的 ‘READY’，并将任何仍然在旧操作系统上的主机设置为 ‘MAINT’。

   您可以使用 playbook 重新启用主机上的所有后端

   openstack-ansible openstack.osa.tools.set_haproxy_backends_state -e hostname=${REINSTALLED_HOST} -e backend_state=enabled
   

部署计算和网络主机

1. 禁用计算主机上的 hypervisor 服务，并将任何实例迁移到另一个可用的 hypervisor。

2. 重新安装主机的操作系统

3. 清除过时的 ansible-facts

   rm /etc/openstack_deploy/ansible-facts/${REINSTALLED_HOST}*
   

   (* 因为我们正在删除主机的所有容器 facts)

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}*
   

   (* 因为我们需要在 limit 中包含容器)

5. 恢复计算节点 hypervisor UUID

   计算节点应将其 UUID 存储在文件 ‘/var/lib/nova/compute_id’ 中，并重新启动 ‘nova-compute’ 服务。 可以使用命令行 ‘openstack hypervisor list’ 找到 UUID。

   或者，可以使用以下 Ansible 自动执行这些操作

   openstack-ansible openstack.osa.tools.nova_restore_compute_id --limit ${REINSTALLED_HOST}