块存储备份指南

Red Hat OpenStack Platform 16.1

了解、使用和管理 OpenStack 中的块存储备份服务

OpenStack Documentation Team

摘要

本文档论述了如何部署 OpenStack 块存储备份服务。Red Hat OpenStack Platform director 可以将 Red Hat Ceph Storage、NFS 和 Object Storage (swift)配置为后端。您还可以将 Google Cloud Storage 配置为备份后端。

使开源包含更多

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始:master、slave、黑名单和白名单。由于此项工作十分艰巨,这些更改将在即将推出的几个发行版本中逐步实施。详情请查看 CTO Chris Wright 的信息

对红帽文档提供反馈

我们感谢您对文档提供反馈信息。与我们分享您的成功秘诀。

使用直接文档反馈(DDF)功能

使用 添加反馈 DDF 功能,用于特定句子、段落或代码块上的直接注释。

  1. Multi-page HTML 格式查看文档。
  2. 请确定您看到文档右上角的 反馈 按钮。
  3. 用鼠标指针高亮显示您想评论的文本部分。
  4. 添加反馈
  5. 添加反馈项中输入您的意见。
  6. 可选:添加您的电子邮件地址,以便文档团队可以联系您以讨论您的问题。
  7. Submit

第 1 章 Red Hat OpenStack Platform 块存储备份服务概述

Red Hat OpenStack Platform (RHOSP)提供了在 Red Hat Enterprise Linux 之上构建私有或公共基础设施即服务(IaaS)云的基础。它是用于开发启用云工作负载的可扩展、容错平台。

您可以使用 RHOSP 仪表板或命令行客户端方法管理备份服务的大部分功能,但您必须使用命令行来执行一些更高级的流程。

注意

有关 Red Hat OpenStack Platform 文档的完整套件,请参阅 Red Hat OpenStack Platform 文档

块存储服务 (cinder) 包含了一个横向扩展备份服务,可用于将 Cinder 卷备份到不同的存储后端。您可以使用 Block Storage 备份服务来创建和恢复完整或增量备份。该服务独立于卷。

Red Hat OpenStack Platform (RHOSP) director 是一个工具集,用于安装和管理完整的 RHOSP 环境,称为 overcloud。有关 director 的更多信息,请参阅 Director 安装和使用指南。overcloud 包含为最终用户提供服务的组件,包括块存储。块存储备份服务是在 Controller 节点上部署的可选服务。

1.1. 备份和快照

卷备份是卷内容的持久副本。卷备份通常作为对象存储创建,默认通过 OpenStack Object Storage 服务(swift)管理。您可以使用 Red Hat Ceph 和 NFS 作为备份的替代后端。

当您创建卷备份时,所有备份元数据都存储在块存储服务数据库中。当从备份中恢复卷时,cinder-backup 服务使用此元数据。这意味着,当您从灾难性数据库丢失中执行恢复时,您必须先恢复块存储服务数据库,然后才能从备份中恢复任何卷,只要块存储服务数据库的原始卷备份元数据是完的。如果您只想配置卷备份的子集,以便在灾难性数据库丢失后存活,您也可以导出备份元数据。然后,您可以使用 REST API 或 cinder 客户端将元数据重新导入到块存储数据库,然后正常恢复卷备份。

卷备份与快照不同。备份保留卷中包含的数据,快照会在特定时间点保留卷的状态。如果卷有现有的快照,则无法删除卷。卷备份可防止数据丢失,而快照则有助于克隆。因此,快照后端通常与卷后端在一起,以便在克隆期间最小化延迟。相反,备份存储库通常独立于不同的后端,无论是在不同节点或不同的物理存储上。这可以防止备份存储库不受卷后端可能出现的任何损坏的影响。

有关卷快照的更多信息,请参阅存储指南中的创建、使用或删除卷快照

1.2. 备份和恢复工作方式

以下小节演示了备份和恢复的工作流。

1.2.1. 卷备份工作流

当块存储备份服务执行备份时,它会从 cinder API 接收请求来备份目标卷。备份服务完成请求,并将内容存储在后端。

下图演示了请求如何与 Block Storage (cinder)服务交互来执行备份。

OpenStack BlockStorage 备份
  1. 客户端通过调用 cinder API 来发出一个请求来备份块存储卷。
  2. Cinder API 服务从 HAProxy 接收请求并验证请求、用户凭据和其他信息。
  3. 在 SQL 数据库中创建备份记录。
  4. 通过 AMQP 对 cinder-backup 服务进行异步 RPC 调用,以备份卷。
  5. 将当前备份记录(带有 ID)返回到 API 调用器。
  6. RPC 创建消息到达其中一个备份服务。
  7. cinder-backup 服务对 get_backup_device 执行同步 RPC 调用。
  8. cinder-volume 服务确保正确的设备返回到调用者。通常,它是同一个卷,但如果卷正在使用,则服务会返回临时克隆的卷或临时快照,具体取决于配置。
  9. cinder-backup 服务向 cinder-volume 发出另一个同步 RPC 以公开源设备。
  10. cinder-volume 服务导出并映射源设备(卷或快照),并返回适当的连接信息。
  11. cinder-backup 服务使用连接信息附加源卷。
  12. cinder-backup 服务调用备份驱动程序,设备已经附加,后者开始向备份目的地传输数据传输。
  13. 卷从 Backup 主机分离。
  14. cinder-backup 服务向 cinder-volume 发出同步 RPC,以断开源设备的连接。
  15. cinder-volume 服务取消映射并删除设备的导出。
  16. 如果创建了临时卷或临时快照,cinder-backup 会调用 cinder-volume 来删除它。
  17. cinder-volume 服务移除临时卷。
  18. 备份完成后,备份记录会在数据库中更新。

1.2.2. 卷恢复工作流

下图演示了用户请求恢复块存储服务(cinder)备份时所执行的步骤。

OpenStack BlockStorage 恢复
  1. 客户端通过调用 CinderREST API 来发出恢复块存储备份的请求。
  2. Cinder API 从 HAProxy 接收请求并验证请求、用户凭据和其他信息。
  3. 如果请求不包含现有卷作为目的地,API 会发出异步 RPC 调用来创建新卷并轮询卷的状态,直到卷可用为止。
  4. cinder-scheduler 选择一个卷服务,并发出 RPC 调用来创建卷。
  5. 所选的 cinder-volume 服务创建卷。
  6. cinder-api 检测到卷可用时,会在数据库中创建备份记录。
  7. 通过 AMQP 对备份服务进行异步 RPC 调用,以恢复备份。
  8. 将当前卷 ID、备份 ID 和卷名称返回到 API 调用器。
  9. RPC 创建消息到达其中一个备份服务。
  10. cinder-backup 服务执行对 cinder-volume 的同步 RPC 调用,以公开目标卷。
  11. cinder-volume 服务导出并映射目标卷返回适当的连接信息。
  12. cinder-backup 服务使用连接信息附加源卷。
  13. cinder-backup 服务调用已附加设备的驱动程序,后者开始恢复卷目的地的数据。
  14. 卷从备份主机分离。
  15. cinder-backup 服务向 cinder-volume 发出同步 RPC,以断开源设备的连接。
  16. cinder-volume 服务取消映射并删除设备的导出。
  17. 备份完成后,会在数据库中更新备份记录。

1.3. 云存储与本地存储

Google Cloud Storage 驱动程序是块存储备份服务唯一支持的云驱动程序。默认情况下,Google Cloud Storage 驱动程序对这种类型的备份使用最昂贵的存储解决方案 Nearline。

配置备份服务以优化性能。例如,如果您从欧洲创建备份,请将备份区域改为 Europe。如果您没有从默认的美国更改备份区域,则由于两个区域之间的地理距离,性能可能会较慢。

注意

Google Cloud Storage 需要特殊配置,如 附录 A, Google Cloud Storage 配置 部分所述。

下表根据情况列出了云存储和本地存储的优点和限制。

情况云存储本地存储

offsite 备份

云存储是另一个公司的数据中心,因此会自动关闭。您可以从多个位置访问数据。远程副本可用于灾难恢复。

需要额外的规划和费用。

硬件控制

依赖于其他服务的可用性和专业知识。

您可以完全控制存储硬件。需要管理和专业知识。

成本注意事项

不同的定价策略或层取决于您从供应商使用的服务。

根据需要添加额外的硬件是已知的成本。

网络速度和数据访问

整体数据访问速度较慢,需要访问互联网。速度和延迟取决于多个因素。

对数据的访问快速并立即获得。不需要访问互联网。

第 2 章 块存储备份服务部署

Block Storage 备份服务是可选的。默认情况下不安装它,因此您必须将其添加到 overcloud 部署中

先决条件

  • 现有的 Red Hat OpenStack Platform (RHOSP)安装。
  • 具有兼容备份驱动程序的可用存储源: Object Storage (swift; default)、Ceph、NFS 或 Google Cloud 存储。
注意

Google Cloud Storage 需要额外的配置。更多信息请参阅 附录 A, Google Cloud Storage 配置

2.1. 为备份服务配置后端存储选项

要启用备份服务,请完成以下步骤。

流程

  1. 创建 cinder-backup.yaml 文件的副本,该文件位于 /usr/share/openstack-tripleo-heat-templates/environments/ 目录中,并将它存储在与其他自定义模板相同的位置。

    cp /usr/share/openstack-tripleo-heat-templates/environments/cinder-backup.yaml /home/stack/templates/cinder-backup-settings.yaml
  2. cinder-backup.yaml 文件的副本包含默认设置,它们使用 Pacemaker 为块存储备份服务配置 OpenStack Object Storage (swift)后端。如果这是您用于备份的后端,则不需要更改此文件。如果您使用替代后端,请根据备份后端配置 parameter_defaults

    • 如果使用 Red Hat Ceph Storage,请使用以下方法配置 parameter_defaults

      • CinderBackupBackend: (Required) ceph
      • CinderBackupRbdPoolName :(可选)设置为自定义 RBD 池名称。默认: backups
    • 如果使用 NFS,请使用以下方法配置 parameter_defaults

      • CinderBackupBackend: (Required) nfs
      • CinderBackupNfsShare: (必需)设置为您要挂载的 NFS 共享。默认值为空。
      • CinderBackupNfsMountOptions :(可选)设置为您所需的挂载选项。
  3. 保存对文件的更改。
  4. 要启用备份服务并应用此配置,请将备份设置环境文件与其他环境文件一起添加到堆栈中,并部署 overcloud:

    (undercloud) [stack@undercloud ~]$ openstack overcloud deploy --templates \
      -e [your environment files]
      -e /home/stack/templates/cinder-backup-settings.yaml

如需更多信息和其他配置选项,请参阅 附录 A, Google Cloud Storage 配置

2.2. 使用 Google Cloud 配置部署 overcloud

'/home/stack/templates/ 中创建环境文件后,部署 overcloud,然后重新启动 cinder-backup 服务。

流程

  1. stack 用户身份登录。
  2. 部署配置:

    $ openstack overcloud deploy --templates \
    -e /home/stack/templates/cinder-backup-settings.yaml
    重要

    如果您在创建 overcloud 时传递任何额外的环境文件,请使用 -e 选项再次传递它们,以避免对 overcloud 进行不必要的更改。

  3. 部署完成后重启 cinder-backup 服务。

如需更多信息,请参阅 Director 安装和使用指南中的在一个 overcloud 部署中包括的环境文件,以及 高级 Overcloud 自定义指南中的环境文件

第 3 章 使用块存储备份服务

您可以使用块存储备份服务执行完整或增量备份,并将备份恢复到卷。

3.1. 完整备份

3.1.1. 创建完整卷备份

要备份卷,请使用 cinder backup-create 命令。默认情况下,这个命令会创建卷的完整备份。如果卷有现有的备份,您可以选择创建增量备份。更多信息请参阅 第 3.2.2 节 “执行增量备份”

注意

在 Red Hat OpenStack Platform (RHOSP)版本 16 之前,cinder backup-create 命令在第一个完整 Ceph 卷备份到 Ceph 存储后端后创建增量备份。在 RHOSP 版本 16 及更高版本中,您必须使用 --incremental 选项来创建增量卷备份。如果您没有在 cinder backup-create 命令中使用 --incremental 选项,则默认设置会创建完整的备份。更多信息请参阅 第 3.2.2 节 “执行增量备份”

您可以创建您可以访问的卷备份。这意味着,具有管理特权的用户都可以备份任何卷,而不考虑所有者。更多信息请参阅 第 3.1.2 节 “以管理员身份创建卷备份”

流程

  1. 查看您要备份的卷的 ID 或显示名称:

    # cinder list
  2. 备份卷:

    # cinder backup-create _VOLUME_

    使用您要备份的卷的 ID显示 名称替换 VOLUME。例如:

      +-----------+--------------------------------------+
      |  Property |                Value                 |
      +-----------+--------------------------------------+
      |     id    | e9d15fc7-eeae-4ca4-aa72-d52536dc551d |
      |    name   |                 None                 |
      | volume_id | 5f75430a-abff-4cc7-b74e-f808234fa6c5 |
      +-----------+--------------------------------------+

    生成的备份的 volume_id 与源卷的 ID 相同。

  3. 验证卷备份创建是否已完成:

    # cinder backup-list
  4. 当备份条目的 Status 可用时,卷备份创建已完成。

3.1.2. 以管理员身份创建卷备份

具有管理特权的用户可以备份由 Red Hat OpenStack Platform 管理的任何卷。当 admin 用户备份由非管理员用户拥有的卷时,默认从卷所有者中隐藏备份。

流程

  • 作为 admin 用户,您可以使用以下命令备份卷,并使备份可供特定租户使用:

    # cinder --os-auth-url <KEYSTONEURL> --os-tenant-name <TENANTNAME> --os-username <USERNAME> --os-password <PASSWD> backup-create <VOLUME>

    根据您的环境要求替换以下变量:

  • <TENANTNAME> 是您要备份的租户的名称。
  • <USERNAME> 和 <PASSWD> 是 <TENANTNAME> 中用户的用户名和密码凭证。
  • <VOLUME> 是您要备份的卷的名称或 ID。
  • <KEYSTONEURL> 是身份服务的 URL 端点,通常为 http://IP:5000/v2,其中 IP 是身份服务主机的 IP 地址。执行此操作时,生成的备份大小针对 TENANTNAME 的配额而不是租户 admin 的配额进行计数。

3.1.3. 导出卷备份的元数据

您可以导出并存储卷备份的元数据,以便您可以恢复卷备份,即使块存储数据库遭受灾难性丢失。

流程

  • 运行以下命令:

    # cinder backup-export _BACKUPID_

    将 <BACKUPID> 替换为卷备份的 ID 或名称:

    +----------------+------------------------------------------+
    |    Property    |                Value                     |
    +----------------+------------------------------------------+
    | backup_service |     cinder.backup.drivers.swift          |
    |   backup_url   | eyJzdGF0dXMiOiAiYXZhaWxhYmxlIiwgIm9iam...|
    |                | ...4NS02ZmY4MzBhZWYwNWUiLCAic2l6ZSI6IDF9 |
    +----------------+------------------------------------------+

卷备份元数据由 backup_servicebackup_url 值组成。

3.1.4. 备份使用中的卷

当支持块存储后端快照时,您可以使用 --force 选项创建 in-use 卷备份。

注意

要使用 --force 选项,必须支持 Block Storage 后端快照。您可以通过检查您使用的后端的文档来验证快照支持。

通过使用 --force 选项,您可以确认在执行备份前您不会静止驱动器。使用此方法会造成崩溃一致性,但不是应用程序一致性的备份。这意味着备份不知道执行备份时运行哪些应用程序。但是,数据保持不变。

流程

  • 要创建 in-use 卷的备份,请运行:

    # cinder backup-create _VOLUME_ --incremental --force

3.1.5. 备份快照

您可以使用与快照关联的卷 ID 从快照创建完整备份。

流程

  1. 使用 cinder snapshot list 找到要备份的快照的快照 ID。

    # cinder snapshot-list --volume-id _VOLUME_ID_
  2. 如果快照被命名,您可以使用以下示例查找 ID

    # cinder snapshot-show _SNAPSHOT_NAME_
  3. 创建快照的备份:

    # cinder backup-create _VOLUME_ --snapshot-id=_SNAPSHOT_ID_
    注意

    当您使用 --snapshot-id 选项时,基于快照的 NFS 卷备份会失败。这是个已知问题。

3.1.6. 在边缘站点间备份和恢复

您可以在边缘站点和可用区中的分布式计算节点(DCN)架构间备份和恢复块存储服务(cinder)卷。cinder-backup 服务在中央可用区(AZ)中运行,备份存储在中央 AZ 中。块存储服务不在 DCN 站点存储备份。

先决条件

  • 中央站点使用位于 /usr/share/openstack-tripleo-heat-templates/environmentscinder-backup.yaml 环境文件进行部署。如需更多信息,请参阅块存储备份服务部署
  • Block Storage 服务(cinder) CLI 可用。
  • 所有站点都必须使用通用的 openstack cephx 客户端名称。有关更多信息,请参阅为外部访问创建 Ceph 密钥

流程

  1. 在第一个 DCN 站点中创建卷的备份:

    $ cinder --os-volume-api-version 3.51 backup-create --name <volume_backup> --availability-zone <az_central> <edge_volume>
    • <volume_backup > 替换为卷备份的名称。
    • <az_central > 替换为托管 cinder-backup 服务的中央可用区的名称。
    • 将 < edge_volume > 替换为您要备份的卷的名称。

      注意

      如果 Ceph 密钥环出现问题,您可能需要重启 cinder-backup 容器,以便从主机中的密钥环复制到容器。

  2. 将备份恢复到第二个 DCN 站点中的新卷:

    $ cinder --os-volume-api-version 3.51 create --availability-zone <az_2> --name <new_volume> --backup-id <volume_backup> <volume_size>
    • 将 &lt ;az_ 2> 替换为您要恢复备份的可用区的名称。
    • <new_volume > 替换为新卷的名称。
    • 将 &lt ;volume_backup > 替换为您在上一步中创建的卷备份的名称。
    • 将 < volume_size > 替换为等于或大于原始卷大小的 GB 值。

3.2. 增量备份

使用块存储备份服务,您可以执行增量备份。

3.2.1. 性能考虑

有些备份功能(如增量和数据压缩)可能会影响性能。增量备份会影响性能,因为卷中的所有数据都必须读取和校验和,以进行完整备份和每个增量备份。

您可以将数据压缩用于非 Ceph 后端。启用数据压缩需要额外的 CPU 电源,但使用较少的网络带宽和存储空间。

多路径配置也会影响性能。如果您在没有启用多路径的情况下附加多个卷,则可能无法连接或具有完整的网络功能,这会影响性能。

您可以使用高级配置选项启用或禁用压缩,定义进程数量,以及添加额外的 CPU 资源。更多信息请参阅 附录 B, 高级块存储备份配置选项

3.2.1.1. 从快照备份的影响

有些后端支持从快照创建备份。支持此功能的驱动程序可以直接附加快照,这比将快照克隆到卷中要快,才能附加到其中。通常,这个功能可能会影响性能,因为从快照创建卷的额外步骤。

3.2.2. 执行增量备份

默认情况下,cinder backup-create 命令会创建卷的完整备份。但是,如果卷有现有的备份,您可以创建增量备份。

NFS、Object Storage (swift) 和 Red Hat Ceph Storage 备份软件仓库完全支持增量备份。

增量备份会捕获自上次完整或增量备份后对卷的任何更改。执行大量、常规、完全备份卷可能会成为资源密集型,因为卷的大小会随时间增加。通过增量备份,您可以捕获卷的定期更改,并最小化资源使用量。

流程

  • 要创建增量卷备份,请使用以下命令使用 --incremental 选项:

    # cinder backup-create _VOLUME_ --incremental

    使用您要备份的卷的 ID显示 名称替换 VOLUME

注意

如果已经有增量备份,则无法删除全备份。如果完整备份有多个增量备份,则只能删除最新的备份。

3.3. 取消备份

要取消备份,管理员必须在备份上请求强制删除。

重要

如果您使用 Ceph 或 RBD 后端,则不支持此操作。

流程

  • 运行以下命令:

    # openstack volume backup delete --force <backup>

完成取消且备份不再出现在备份列表中后,备份可能会稍微延迟才能成功取消备份。要验证备份是否已成功取消,源资源中的备份状态将停止。

注意

在 Red Hat OpenStack 版本 12 之前,备份 状态存储在卷中,即使备份快照也是如此。因此,当备份快照时,对快照进行取消的任何删除操作都可能会导致在快照仍映射时出现错误。在 Red Hat OpenStack Platform 版本 13 及更高版本中,可以在任何受支持的备份驱动程序中取消持续恢复操作。

3.4. 查看和修改租户备份配额

通常,您可以使用控制面板修改租户存储配额,如租户可以具有的卷、卷存储、快照或其他操作限制。但是,使用仪表板修改备份配额的功能还不可用。

您必须使用命令行界面修改备份配额。

流程

  1. 要查看特定租户(TENANT_ID)的存储配额,请运行以下命令:

    # cinder quota-show TENANT_ID
  2. 要更新在特定租户中创建的最大备份数(MAXNUM),请运行以下命令:

    # cinder quota-update --backups MAXNUM TENANT_ID
  3. 要更新特定租户内所有备份的最大大小(MAXGB),请运行以下命令:

    # cinder quota-update --backup-gigabytes MAXGB TENANT_ID
  4. 要查看特定租户的存储配额使用情况,请运行以下命令:

    # cinder quota-usage TENANT_ID

3.5. 从备份中恢复

在数据库故障或导致数据丢失的另一种事件类型后,使用您创建的备份来恢复数据。

重要

如果将 cinder-backup 服务配置为使用 Ceph RBD 驱动程序,则只能将备份卷恢复到基于 RBD 的块存储(cinder)后端。

3.5.1. 从备份中恢复卷

要从备份创建新卷,请完成以下步骤。

流程

  1. 查找您要使用的卷备份的 ID:

    # cinder backup-list

    确保卷 ID 与您要恢复的卷 ID 匹配。

  2. 恢复卷备份:

    # cinder backup-restore _BACKUP_ID_

    BACKUP_ID 替换为您要使用的卷备份的 ID。

  3. 如果您不再需要备份,请删除它:

    # cinder backup-delete _BACKUP_ID_
  4. 如果您需要将备份卷恢复到特定类型的卷,请使用 --volume 选项将备份恢复到特定卷:

    # cinder backup-restore _BACKUP_ID --volume VOLUME_ID_
    注意

    如果您从加密备份中恢复卷,则必须加密目标卷类型。

3.5.2. 在块存储数据库丢失后恢复卷

当块存储数据库丢失时,您无法恢复卷备份,因为数据库包含卷备份服务所需的元数据。但是,在创建卷备份后,您可以导出和存储由 backup_servicebackup_url 值组成的元数据,以便在数据库丢失时,您可以恢复卷备份。如需更多信息,请参阅 第 3.1.1 节 “创建完整卷备份”

如果您导出并存储此元数据,您可以将其导入到新的块存储数据库,该数据库允许您恢复卷备份。

注意

对于增量备份,您必须先导入所有导出数据,然后才能恢复其中一个增量备份。

流程

  1. 以具有管理特权的用户身份,运行以下命令:

    # cinder backup-import _backup_service_ _backup_url_

    backup_servicebackup_url 替换为您导出的元数据。例如,使用从 第 3.1.1 节 “创建完整卷备份” 导出的元数据:

    # cinder backup-import cinder.backup.drivers.swift eyJzdGF0dXMi...c2l6ZSI6IDF9
    +----------+--------------------------------------+
    | Property |                Value                 |
    +----------+--------------------------------------+
    |    id    | 77951e2f-4aff-4365-8c64-f833802eaa43 |
    |   name   |                 None                 |
    +----------+--------------------------------------+
  2. 将元数据导入到块存储服务数据库后,您可以正常恢复卷,请参阅 第 3.5.1 节 “从备份中恢复卷”

3.5.3. 取消备份恢复

要取消备份恢复操作,请将备份的状态改为 恢复 以外的任何状态。您可以使用 错误状态 来最小化与恢复成功相关的混淆。或者,您可以将值更改为 available

$ openstack volume backup set --state error BACKUP_ID
注意

备份取消是一种异步操作,因为备份驱动程序必须在取消备份前检测状态更改。当目标卷中状态变为 available 时,取消完成。

注意

此功能目前在 RBD 备份上不可用。

警告

如果在启动后取消恢复操作,则目标卷是无用的,因为无法知道实际恢复的数据量(如果有的话)。

3.6. 故障排除

有两种常见情况会导致备份服务发生的许多问题:

  • cinder-backup 服务启动时,它会连接到其配置的后端,并将其用作备份的目标。此连接的问题可能会导致服务失败。
  • 请求备份时,备份服务会连接到卷服务并附加所请求的卷。这个连接的问题仅在备份期间被识别。

在这两种情况下,日志都包含描述错误的消息。

有关日志文件和服务的更多信息,请参阅 日志记录、监控和故障排除指南中的 OpenStack 服务的日志文件

有关日志位置和建议的一般信息,请参阅日志记录、监控和故障排除指南中的 块存储(cinder)日志文件

3.6.1. 验证服务

您可以通过验证服务是否可用,并通过检查错误消息来诊断许多问题。有关密钥服务及其交互的详情,请参考 第 1.2 节 “备份和恢复工作方式”

验证服务状态后,检查 cinder-backup.log 文件。Block Storage Backup 服务日志位于 /var/log/containers/cinder]/cinder-backup.log 中。

流程

  1. 在卷上运行 cinder show 命令,以查看它是否被主机存储:

    # cinder show
  2. 运行 cinder service-list 命令来查看正在运行的服务:

    # cinder service-list
    +------------------+--------------------+------+---------+-------+----------------------------+-----------------+
    | Binary           | Host               | Zone | Status  | State | Updated_at                 | Disabled Reason |
    +------------------+--------------------+------+---------+-------+----------------------------+-----------------+
    | cinder-backup    | hostgroup          | nova | enabled | up    | 2017-05-15T02:42:25.000000 | -               |
    | cinder-scheduler | hostgroup          | nova | enabled | up    | 2017-05-15T02:42:25.000000 | -               |
    | cinder-volume    | hostgroup@sas-pool | nova | enabled | down  | 2017-05-14T03:04:01.000000 | -               |
    | cinder-volume    | hostgroup@ssd-pool | nova | enabled | down  | 2017-05-14T03:04:01.000000 | -               |
    +------------------+--------------------+------+---------+-------+----------------------------+-----------------+
  3. 验证预期的服务是否可用。

3.6.2. 故障排除窍门

备份是异步的。块存储备份服务在收到 API 请求时会执行少量的静态检查,如检查无效卷引用(missing)或卷处于 in-use,或附加到一个实例。in-use 用例要求您使用 --force 选项。

注意

使用 --force 选项意味着不会静止 I/O,生成的卷镜像可能会损坏。

如果 API 接受请求,则备份会在后台进行。通常,即使备份失败或正在处理失败,CLI 也会立即返回。您可以使用 cinder 备份 API 查询备份状态。如果发生错误,请检查日志以发现原因。

3.6.3. pacemaker

默认情况下,Pacemaker 部署块存储备份服务。Pacemaker 将虚拟 IP 地址、容器、服务和其他功能配置为集群中的资源,以确保定义的 OpenStack 集群资源正在运行并可用。当集群中的服务或整个节点失败时,Pacemaker 可以重启该资源,使节点退出集群,或重新引导节点。对大多数服务的请求通过 HAProxy

有关如何使用 Pacemaker 进行故障排除的详情,请参考 高可用性部署和使用指南中的使用 Pacemaker 管理高可用性服务

附录 A. Google Cloud Storage 配置

要将块存储服务(cinder)配置为使用 Google Cloud Storage 作为备份后端,请完成以下步骤:

  1. 创建并下载 Google 帐户的服务帐户凭证:

  2. 创建一个环境文件来映射您需要的块存储设置:

  3. 使用您创建的环境文件重新部署 overcloud:

先决条件

  • 您有具有升级权限的帐户的用户名和密码。您可以使用为部署 overcloud 而创建的 stack 用户帐户。如需更多信息,请参阅 Director 安装和使用指南
  • 您有一个 Google 帐户,可访问 Google Cloud Platform。块存储服务使用此帐户访问和使用 Google Cloud 存储备份。

A.1. 创建 GCS 凭证文件

Block Storage 服务(cinder)需要 Google 凭证访问和使用 Google Cloud 进行备份。您可以通过创建服务帐户密钥,为块存储服务提供这些凭证。

流程

  1. 使用您的 Google 帐户登录到 Google 开发人员控制台(http://console.developers.google.com)。
  2. Credentials 选项卡,从 Create credentials 下拉菜单中选择 Service account key

    creds create

  3. Create service account key 屏幕中,从 Service account 下拉菜单中选择您希望块存储服务使用的服务帐户:

    creds json compengine

  4. 在同一屏幕中,从 Key type 部分中选择 JSON,再单击 Create。浏览器会将密钥下载到其默认下载位置:

    creds key

  5. 打开文件并记录 project_id 参数的值:

    {
      "type": "service_account",
      "project_id": "*cloud-backup-1370*",
    ...
  6. 将 GCS JSON 凭证的副本保存到 /home/stack/templates/Cloud-Backup.json

    重要的
    将文件命名为 Cloud-Backup.json,且不更改文件名。此 JSON 文件必须与作为 第 A.2 节 “创建 cinder-backup-gcs.yaml 中一部分创建的 cinder-backup-gcs.yaml 文件位于同一个目录位置。

A.2. 创建 cinder-backup-gcs.yaml

使用提供的示例文件,创建 cinder-backup-gcs.yaml 文件。

注意

本例中使用的空格和格式(以及您的文件中)非常重要。如果更改了空格,则该文件可能无法按预期工作。

流程

  1. 复制下面的文本,将其粘贴到新文件中。不要对文件内容进行任何修改。

    heat_template_version: rocky
    
    description: >
      Post-deployment for configuration cinder-backup to GCS
    
    parameters:
      servers:
        type: json
      DeployIdentifier:
        type: string
    
    resources:
      CinderBackupGcsExtraConfig:
        type: OS::Heat::SoftwareConfig
        properties:
          group: script
          config:
            str_replace:
              template: |
                #!/bin/bash
                GCS_FILE=/var/lib/config-data/puppet-generated/cinder/etc/cinder/Cloud-Backup.json
                HOSTNAME=$(hostname -s)
                for NODE in $(hiera -c /etc/puppet/hiera.yaml cinder_backup_short_node_names | tr -d '[]",'); do
                  if [ $NODE == $HOSTNAME ]; then
                    cat <<EOF > $GCS_FILE
                GCS_JSON_DATA
                EOF
                    chmod 0640 $GCS_FILE
                    chown root:42407 $GCS_FILE
                  fi
                done
              params:
                GCS_JSON_DATA: {get_file: Cloud-Backup.json}
    
      CinderBackupGcsDeployment:
        type: OS::Heat::SoftwareDeploymentGroup
        properties:
          servers:  {get_param: servers}
          config: {get_resource: CinderBackupGcsExtraConfig}
          actions: ['CREATE','UPDATE']
          input_values:
            deploy_identifier: {get_param: DeployIdentifier}
  2. 将文件保存为 /home/stack/templates/cinder-backup-gcs.yaml

A.3. 使用 Google Cloud 设置创建环境文件

创建环境文件,使其包含您要应用到块存储服务(cinder)的设置。在这种情况下,环境文件配置块存储服务,将卷备份存储到 Google Cloud。有关环境文件的更多信息,请参阅 Director 安装和使用指南

使用以下示例环境文件,并使用 Cloud-Backup.json 文件中列出的项目 ID 更新 backup_gcs_project_id。您还可以将 backup_gcs_bucket_location 位置从美国更改为更接近的位置。

有关 Google Cloud Backup Storage 备份后端的配置选项列表,请参阅 表 A.1 “Google Cloud Storage 备份后端配置选项”

流程

  1. 复制下环境文件示例。保留空格的使用。
  2. 将内容粘贴到新文件: /home/stack/templates/cinder-backup-settings.yaml
  3. backup_gcs_project_id 的值从 cloud-backup-1370 更改为 Cloud-Backup.json 文件中列出的项目 ID。
  4. 保存该文件。

环境文件示例

在环境文件中定义每个设置。使用 表 A.1 “Google Cloud Storage 备份后端配置选项” 选择可用的配置选项。

resource_registry:
  OS::TripleO::Services::CinderBackup: /usr/share/openstack-tripleo-heat-templates/deployment/cinder/cinder-backup-pacemaker-puppet.yaml
  # For non-pcmk managed implementation
  # OS::TripleO::Services::CinderBackup: /usr/share/openstack-tripleo-heat-templates/deployment/cinder/cinder-backup-container-puppet.yaml
  OS::TripleO::NodeExtraConfigPost: /home/stack/templates/cinder-backup-gcs.yaml

parameter_defaults:
  CinderBackupBackend: swift
  ExtraConfig:
    cinder::backup::swift::backup_driver: cinder.backup.drivers.gcs.GoogleBackupDriver
    cinder::config::cinder_config:
      DEFAULT/backup_gcs_credential_file:
        value: /etc/cinder/Cloud-Backup.json
      DEFAULT/backup_gcs_project_id:
        value: cloud-backup-1370
      DEFAULT/backup_gcs_bucket:
        value: cinder-backup-gcs
      DEFAULT/backup_gcs_bucket_location:
        value: us

表 A.1. Google Cloud Storage 备份后端配置选项

PARAM默认CONFIG 描述

backup_gcs_project_id

 

必需。您正在使用的服务帐户的项目 ID,并包含在来自 第 A.1 节 “创建 GCS 凭证文件” 的服务帐户密钥的 project_id 中。

backup_gcs_credential_file

 

您在 第 A.1 节 “创建 GCS 凭证文件” 中创建的服务帐户密钥文件的绝对路径。

backup_gcs_bucket

 

要使用的 GCS 存储桶或对象存储存储库,它们可能也可能不存在。如果您指定了不存在的存储桶,Google Cloud Storage 备份驱动程序会创建一个,并为它分配您指定的名称。如需更多信息,请参阅 BucketsBucket 名称要求

backup_gcs_bucket_location

us

GCS 存储桶的位置。只有在 backup_gcs_bucket 中指定了不存在的存储桶时,才会使用这个值;在这种情况下,Google Cloud Storage 备份驱动程序将其指定为 GCS 存储桶位置。

backup_gcs_object_size

52428800

GCS 备份对象的大小(以字节为单位)。

backup_gcs_block_size

32768

为增量备份跟踪更改的大小,以字节为单位。这个值必须是 backup_gcs_object_size 值的倍数。

backup_gcs_user_agent

gcscinder

GCS API 的 HTTP user-agent 字符串。

backup_gcs_reader_chunk_size

2097152

GCS 对象以这个大小的块下载,以字节为单位。

backup_gcs_writer_chunk_size

2097152

GCS 对象以这个大小的块上传,以字节为单位。要将文件作为单个块上传,请使用值 -1。

backup_gcs_num_retries

3

尝试的重试次数。

backup_gcs_storage_class

NEARLINE

GCS 存储桶的存储类。只有在 backup_gcs_bucket 中指定了不存在的存储桶时,才会使用这个值;在这种情况下,Google Cloud Storage 备份驱动程序将其指定为 GCS bucket 存储类。如需更多信息,请参阅 存储类

backup_gcs_retry_error_codes

429

GCS 错误代码列表。

backup_gcs_enable_progress_timer

true

布尔值,用于启用或禁用在卷备份期间向 Telemetry 服务(ceilometer)发送定期进度通知的计时器。默认启用(True)。

警告

当您创建新存储桶时,Google Cloud Storage 根据您选择的存储类(backup_gcs_storage_class)收费。默认的 NEARLINE 类适合备份服务。

警告

您不能在创建存储桶后编辑存储桶的位置或类。如需更多信息 ,请参阅管理存储桶的存储类或位置

A.4. 部署 overcloud

/home/stack/templates/ 中创建环境文件后,部署 overcloud,然后重启 cinder-backup 服务:

流程

  1. stack 用户身份登录。
  2. 部署配置:

    $ openstack overcloud deploy --templates \
    -e /home/stack/templates/cinder-backup-settings.yaml
    重要

    如果您在创建 overcloud 时传递任何额外的环境文件,请使用 -e 选项再次传递它们,以避免对 overcloud 进行不必要的更改。

  3. 部署完成后重启 cinder-backup 服务。

如需更多信息,请参阅 Director 安装和使用指南中的Overcloud 创建中包括的环境文件,以及高级 Overcloud 自定义指南中的环境文件部分。

附录 B. 高级块存储备份配置选项

在 director 部署安装前,cinder.conf 文件配置块存储服务和备份服务。当 cinder.conf 的值没有等效的编配(heat)模板时,您可以使用自定义环境文件将值传递给 director。将值添加到自定义环境文件的 parameter_defaults 部分中的 ExtraConfig 部分,如 cinder-backup-settings.yaml 文件。

使用 ExtraConfig,您可以添加额外的 hiera 配置来注入到所有节点上的集群。这些设置包含在专用备份节点上。但是,如果您使用 ControllerExtraConfig 而不是 ExtraConfig,则您的设置会在 Controller 节点上安装,而不是在专用备份节点上安装。

您可以为来自 cinder.conf 文件的 DEFAULT 部分的设置替换 DEFAULT/[cinder.conf setting]` 。以下示例演示了如何在 YAML 文件中显示 ExtraConfig 条目:

parameter_defaults:
 ExtraConfig:
   cinder::config::cinder_config:
     DEFAULT/backup_compression_algorithm:
       value: None

表 B.1 列出与备份相关的示例选项。

表 B.1. 块存储备份服务配置选项

选项类型默认值描述

backup_service_inithost_offload

选填

true

在备份服务启动过程中卸载待处理的备份删除。如果为 false,则备份服务将保持关闭,直到所有待处理的备份都被删除。

use_multipath_for_image_xfer

选填

False

在备份和恢复过程中,使用多路径附加卷。这会影响所有 cinder 附加操作,如从镜像、通用冷迁移和其他操作创建卷。

num_volume_device_scan_tries

选填

3

重新扫描目标在附加期间查找卷的次数上限。

backup_workers

选填

1

要运行的备份进程数量。使用压缩运行多个并发备份或恢复会导致性能显著提高。

backup_native_threads_pool_size

选填

60

备份的原生线程池的大小。大多数备份驱动程序都依赖这么大。您可以减少不依赖于这个选项的特定驱动程序的值。

backup_share

必填

 

设置为 HOST:_EXPORT_PATH_。

backup_container

选填

(字符串)用于备份的自定义目录。

backup_enable_progress_timer

选填

true

在将卷备份到后端存储时,启用(true)或禁用(false)计时器,将定期进度通知发送到 Telemetry 服务(ceilometer)。

backup_mount_options

选填

 

在挂载 backup_share 中指定的 NFS 导出时,可以指定以逗号分隔的选项列表。

backup_mount_point_base

选填

$state_path/backup_mount

(字符串)包含 NFS 共享挂载点的基本目录。

backup_compression_algorithm

选填

zlib

在将备份数据发送到存储库时使用的压缩算法。有效值为 zlibbz2None

backup_file_size

选填

1999994880

大于这个值的 cinder 卷中的数据作为备份存储库中的多个文件存储。这个选项必须是 backup_sha_block_size_bytes 的倍数。

backup_sha_block_size_bytes

选填

32768

数字签名计算的 cinder 卷块的大小

法律通告

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.