注意

本文档适用于 Ceph 开发版本。

升级 Ceph

Cephadm 可以安全地将 Ceph 从一个点版本升级到下一个点版本。例如，您可以从 v15.2.0（第一个 Octopus 发布版本）升级到下一个点版本，v15.2.1。

自动升级过程遵循 Ceph 最佳实践。例如：

  • 升级顺序从管理员、监视器开始，然后是其他守护进程。

  • 每个守护进程只有在 Ceph 指示集群将保持可用时才会重新启动。

Note

Ceph 集群健康状态在升级期间可能会切换到HEALTH_WARNING状态。

Note

如果集群主机不可用或变得不可用，升级将暂停，直到其恢复。

Note

当任何池的 PG 自动缩放模式设置为on时，我们建议在升级期间禁用自动缩放。这是为了防止在升级过程中中间的 PG 分割或合并不当地延迟升级进度。在非常大的集群中，这可能会使完成时间增加一天或更长时间，特别是如果升级恰好更改了 PG 自动缩放行为，例如更改了mon_target_pg_per_osd.

ceph osd pool set noautoscale
# Perform the upgrade
ceph osd pool unset noautoscale

的默认值off, on或warn，则预期每个池的模式

开始升级

Note

Note

分阶段升级使用以下 CephFS 升级功能可能需要 Monitors 和 Managers 的

Cephadm 默认减少max_mdsto1。这对于大规模 CephFS 部署可能具有破坏性，因为集群无法快速将活动 MDS(s) 减少到1，并且单个活动 MDS 无法轻松处理所有客户端的负载，即使只是短时间内。因此，为了在不减少max_mds的情况下升级 MDS(s)，fail_fs选项可以设置为true（默认值是false）在启动升级之前：

ceph config set mgr mgr/orchestrator/fail_fs true
这将：

  1. 使 CephFS 文件系统失败，将活动 MDS 守护进程(s)置于up:standby状态。

  2. 安全地升级 MDS 守护进程。

  3. 将 CephFS 文件系统重新启动，将活动 MDS 守护进程(s)的状态从up:standbytoup:active` 恢复。.

在您使用 cephadm 升级 Ceph 之前，请通过运行以下命令验证所有主机当前在线并且您的集群是健康的：

ceph -s

要升级到特定版本，请运行以下形式的命令：

ceph orch upgrade start --ceph-version <version>

例如，要升级到 v16.2.6，请运行以下形式的命令：

ceph orch upgrade start --ceph-version 16.2.6

Note

从版本 v16.2.6 开始，不再使用 Docker Hub 注册表，因此如果您使用 Docker，必须将其指向 quay.io 注册表中的镜像：

ceph orch upgrade start --image quay.io/ceph/ceph:v16.2.6

监控升级

通过运行以下命令确定 (1) 是否正在进行升级以及 (2) 集群正在升级到哪个版本：

ceph orch upgrade status

在 Ceph 升级期间观察进度条

在升级期间，在 ceph 状态输出中可以看到进度条。它看起来像这样：

# ceph -s

[...]
  progress:
    Upgrade to docker.io/ceph/ceph:v15.2.1 (00h 20m 12s)
      [=======.....................] (time remaining: 01h 43m 31s)

在升级期间观察 cephadm 日志

通过运行以下命令观察 cephadm 日志：

ceph -W cephadm

取消升级

您可以通过运行以下命令随时停止升级过程：

ceph orch upgrade stop

升级后的操作

如果新版本基于cephadm，一旦升级完成，用户必须将cephadm软件包（如果用户不使用cephadm shell，则为 ceph-common 软件包）更新到与新版本兼容的版本。

潜在问题

错误：ENOENT：模块未找到

如果协调器崩溃，命令Error ENOENT: Module not found的响应中会显示此消息：ceph orch upgrade status如果协调器崩溃：

ceph orch upgrade status

Error ENOENT: Module not found

这可能是由于 mgr 配置键中的无效 JSON 引起的。请参阅Redmine 追踪器问题 #67329和在 ceph-users 邮件列表上关于此的讨论.

UPGRADE_NO_STANDBY_MGR

此警报 (UPGRADE_NO_STANDBY_MGR) 表示 Ceph 检测不到活动的备用管理器守护进程。为了继续进行升级，Ceph 需要一个活动的备用管理器守护进程（在这种情况下，您可以将其视为“第二个管理员”）。

您可以通过运行以下命令确保 Cephadm 配置为运行两个（或更多）个管理器：

ceph orch apply mgr 2  # or more

您可以通过运行以下命令检查现有管理器守护进程的状态：

ceph orch ps --daemon-type mgr

如果现有的管理器守护进程已停止，您可以通过运行以下命令尝试重新启动它：

ceph orch daemon restart <name>

UPGRADE_FAILED_PULL

此警报 (UPGRADE_FAILED_PULL) 表示 Ceph 无法拉取目标版本的容器镜像。如果指定了不存在的版本或容器镜像（例如，“1.2.3”），或者集群中的一个或多个主机无法访问容器注册表，则可能会发生这种情况。

要取消现有的升级并指定不同的目标版本，请运行以下命令：

ceph orch upgrade stop
ceph orch upgrade start --ceph-version <version>

使用自定义容器镜像

对于大多数用户来说，升级只需要指定要升级的 Ceph 版本。在这种情况下，cephadm 通过将container_image_base配置选项（默认：docker.io/ceph/ceph）与vX.Y.Z.

标签结合起来定位要使用的特定 Ceph 容器镜像。但是，如果需要，可以升级到任意的容器镜像。例如，以下命令升级到开发版本：

ceph orch upgrade start --image quay.ceph.io/ceph-ci/ceph:recent-git-branch-name

有关可用容器镜像的更多信息，请参阅Ceph 容器镜像.

分阶段升级

一些用户可能更喜欢分阶段升级组件，而不是一次性全部升级。从 16.2.11 和 17.2.1 开始，升级命令允许参数限制单个升级命令升级哪些守护进程。选项包括daemon_types, services, hosts和limit. daemon_types接受逗号分隔的守护进程类型列表，并且只升级这些类型的守护进程。services与daemon_types互斥，一次只接受一种类型的服务（例如，不能同时提供 OSD 和 RGW 服务），并且只升级属于这些服务的守护进程。hosts可以与daemon_types或services或单独提供。参数hosts的格式与守护进程放置. limit的命令行选项相同。limit可以与其他任何参数组合。例如，如果您指定要在 Host1 上升级 osd 类型的守护进程，并将limit设置为 3，cephadm 将在 Host1 上升级（最多）3 个 osd 守护进程。

示例：指定守护进程类型和主机：

ceph orch upgrade start --image <image-name> --daemon-types mgr,mon --hosts host1,host2

示例：指定服务并使用限制：

ceph orch upgrade start --image <image-name> --services rgw.example1,rgw.example2 --limit 2

Note

Cephadm 严格执行守护进程升级的顺序，这在交错升级场景中仍然存在。当前的升级顺序是mgr -> mon -> crash -> osd -> mds -> rgw -> rbd-mirror -> cephfs-mirror -> iscsi -> nfs。如果您指定了将守护进程升级顺序错乱的参数，升级命令将阻止并指出如果您继续进行，将错过哪些守护进程。

Note

具有限制参数的升级命令将在开始升级之前验证选项，这可能需要拉取新的容器镜像。当提供限制参数时，不要惊讶于升级启动命令花费很长时间才返回。

Note

在交错升级场景中（当提供限制参数时），监控堆栈守护进程，包括 Prometheus 和 node-exporter，在管理器守护进程升级后刷新。因此，管理器升级可能比预期花费更长的时间。请注意，监控堆栈守护进程的版本可能在 Ceph 发布之间不会更改，在这种情况下，它们只是重新部署。

升级到支持交错升级的版本，从不支持该功能的版本升级

在从已经支持交错升级的版本升级时，该过程只需要提供必要的参数。但是，如果您希望从不支持交错升级的版本升级到支持该功能的版本，则存在一个变通方法。它需要首先手动升级管理器守护进程，然后像平常一样传递限制参数。

警告

在尝试此过程之前，确保您有多个运行中的 mgr 守护进程。

首先，确定您的活动管理器是哪个，哪些是备用。这可以通过多种方式完成，例如查看ceph -s输出。然后，使用以下命令手动升级每个备用 mgr 守护进程：

ceph orch daemon redeploy mgr.example1.abcdef --image <new-image-name>

Note

如果您使用的是非常早期的 cephadm 版本（早期的 Octopus），则orch daemon redeploy命令可能没有--image标志。在这种情况下，您必须手动设置管理器容器镜像ceph config set mgr container_image <new-image-name>然后重新部署管理器ceph orch daemon redeploy mgr.example1.abcdef

在此点，管理器故障转移应该允许我们将活动管理器设置为运行新版本的守护进程。

ceph mgr fail

验证当前的活动管理器现在正在运行新版本。要完成管理器升级：

ceph orch upgrade start --image <new-image-name> --daemon-types mgr

您现在应该所有管理器守护进程都在新版本上，并且能够为其余的升级指定限制参数。

使用自定义镜像更新非 Ceph 图像服务

要更新非 Ceph 图像服务，请运行以下形式的命令：

ceph orch update service <service_type> <image>

例如：

ceph orch update service prometheus quay.io/prometheus/prometheus:v2.55.1

由 Ceph 基金会带给您

Ceph 文档是一个社区资源，由非盈利的 Ceph 基金会资助和托管Ceph Foundation. 如果您想支持这一点和我们的其他工作，请考虑加入现在加入.