使用 Red Hat OpenStack Platform 部署和管理 OpenShift Container Storage

Red Hat OpenShift Container Storage 4.7

如何安装和管理

摘要

有关在 Red Hat OpenStack Platform (RHOSP) 上安装和管理 Red Hat OpenShift Container Storage 的说明,请参阅本文档。
重要
Deploying and managing OpenShift Container Storage on Red Hat OpenStack Platform is a Technology Preview feature. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

让开源更具包容性

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

对红帽文档提供反馈

我们感谢您对文档提供反馈信息。请告诉我们如何让它更好。提供反馈:

  • 关于特定内容的简单评论:

    1. 请确定您使用 Multi-page HTML 格式查看文档。另外,确定 Feedback 按钮出现在文档页的右上方。
    2. 用鼠标指针高亮显示您想评论的文本部分。
    3. 点在高亮文本上弹出的 Add Feedback
    4. 按照显示的步骤操作。
  • 要提交更复杂的反馈,请创建一个 Bugzilla ticket:

    1. 进入 Bugzilla 网站。
    2. 在 Component 中选择 Documentation
    3. Description 中输入您要提供的信息。包括文档相关部分的链接。
    4. Submit Bug

前言

Red Hat OpenShift Container Storage 4.7 支持使用 Red Hat OpenStack Platform 集群在现有 Red Hat OpenShift Container Platform(RHOCP)上部署。

注意

Red Hat OpenStack Platform 支持内部和外部 Openshift Container Storage 集群。如需有关部署要求的更多信息,请参阅规划部署

要部署 OpenShift Container Storage,请从 准备部署 OpenShift Container Storage 章节的要求开始,然后按照环境的部署过程操作:

  • 内部模式

以内部模式在 Red Hat OpenStack Platform 上部署 OpenShift Container Storage

  • 外部模式

以外部模式在 Red Hat OpenStack Platform 上部署 OpenShift Container Storage

第 1 章 准备部署 OpenShift Container Storage

使用动态存储设备在 OpenShift Container Platform 上部署 OpenShift Container Storage 可让您选择创建内部集群资源。这将会在内部置备基础服务,这有助于为应用提供额外的存储类。

在开始部署 Red Hat OpenShift Container Storage 前,请按照以下步骤执行:

  1. 可选: 如果要使用外部密钥管理系统(KMS)启用集群范围加密:

  2. 最低的启动节点要求 [技术预览]

    当不符合标准部署资源要求时,OpenShift Container Storage 集群将以最小配置进行部署。请参阅规划指南中的资源要求部分。

1.1. 在 Vault 中启用键值后端路径和策略

先决条件

  • 管理员对 Vault 的访问权限。
  • 仔细选择唯一路径名称作为遵循命名惯例的后端路径,因为它无法在以后更改。

步骤

  1. 在 Vault 中启用 Key/Value(KV)后端路径。

    对于 Vault KV secret 引擎 API,版本 1:

    $ vault secrets enable -path=ocs kv

    对于 Vault KV secret 引擎 API,版本 2:

    $ vault secrets enable -path=ocs kv-v2
  2. 使用以下命令,创建一个策略来限制用户对 secret 执行写入或删除操作:

    echo '
    path "ocs/*" {
      capabilities = ["create", "read", "update", "delete", "list"]
    }
    path "sys/mounts" {
    capabilities = ["read"]
    }'| vault policy write ocs -
  3. 创建与上述策略匹配的令牌:

    $ vault token create -policy=ocs -format json

第 2 章 以内部模式在 Red Hat OpenStack Platform 上部署 OpenShift Container Storage

使用 Red Hat OpenStack Platform 安装程序置备的基础架构 (IPI) 提供的动态存储设备在 OpenShift Container Platform 上部署 OpenShift Container Storage 可让您创建内部集群资源。这会导致在内部置备基础服务,这有助于为应用提供额外的存储类。

确保已满足 准备部署 OpenShift Container Storage 章节的要求,然后按照以下步骤使用动态存储设备进行部署:

2.1. 安装 Red Hat OpenShift Container Storage Operator

您可以使用 Red Hat OpenShift Container Platform Operator Hub 安装 Red Hat OpenShift Container Storage Operator。

先决条件

  • 使用具有 cluster-admin 和 Operator 安装权限的账户访问 OpenShift Container Platform 集群。
  • RHOCP 集群中至少有三个 worker 节点。
  • 如需额外的资源要求,请参阅规划部署
注意
  • 当您需要覆盖 OpenShift Container Storage 的集群范围默认节点选择器时,您可以在命令行界面中使用以下命令为 openshift-storage 命名空间指定空白节点选择器(在这种情况下创建 openshift-storage 命名空间):

    $ oc annotate namespace openshift-storage openshift.io/node-selector=
  • 将节点作为 infra 污点,以确保只在该节点上调度 Red Hat OpenShift Container Storage 资源。这有助于您节省订阅成本。如需更多信息,请参阅管理和分配存储资源指南中的如何将专用 worker 节点用于 Red Hat OpenShift Container Storage 一章。

步骤

  1. 在 Web 控制台中,点 Operators → OperatorHub
  2. 在 Filter by keyword 框中滚动或输入关键字以搜索 OpenShift Container Storage Operator。
  3. 在 OpenShift Container Storage operator 页中点 Install
  4. Install Operator 页面中,默认选择以下所需选项:

    1. 更新频道作为 stable-4.7
    2. 安装模式是 A specific namespace on the cluster
    3. Installed Namespace 为 Operator recommended namespace openshift-storage。如果 Namespace openshift-storage 不存在,它会在 Operator 安装过程中创建。
    4. Approval Strategy 选为 AutomaticManual
    5. Install

      如果选择 Automatic 更新,Operator Lifecycle Manager(OLM)将自动升级 Operator 的运行实例,而无需任何干预。

      如果选择了 手动 更新,则 OLM 会创建一个更新请求。作为集群管理员,您必须手动批准该更新请求,才可将 Operator 更新至新版本。

验证步骤

验证 OpenShift Container Storage Operator 是否显示绿色勾号,指示安装成功。

后续步骤

  • 创建 OpenShift Container Storage 集群。

如需更多信息,请参阅以内部模式创建 OpenShift Container Storage Cluster Service

2.2. 以内部模式创建 OpenShift Container Storage Cluster Service

安装 OpenShift Container Storage operator 后,请使用此流程创建 OpenShift Container Storage Cluster Service。

先决条件

步骤

  1. 登录 OpenShift Web 控制台。
  2. Operators → Installed Operators 查看所有已安装的 Operator。

    确保所选 项目openshift-storage

  3. OpenShift Container Storage > Create Instance Cluster 链接。
  4. 选择 Mode 被默认设置为 Internal
  5. Select capacity and nodes 中,

    1. 选择 Storage Class。默认情况下,设置为 standard
    2. 从下拉列表中选择 Requested Capacity。默认设置为 2 TiB。您可以使用下拉菜单修改容量值。

      注意

      选择初始存储容量后,集群扩展将使用所选的可用容量(原始存储的 3 倍)执行。

    3. Select Nodes 部分中,选择至少三个可用节点。

      对于具有多个可用区的云平台,请确保节点分布在不同的位置/可用性区域。

      如果选择的节点与一个聚合的 30 个 CPU 和 72 GiB RAM 的要求不匹配,则会部署一个最小的集群。如需最低起始节点要求,请参阅规划指南中的资源要求部分。

    4. 点击 Next
  6. (可选)安全配置

    1. 选中 启用加密 复选框,以加密块和文件存储。
    2. 选择任意一个或两个 加密级别

      • Cluster-wide encryption 来加密整个集群(块存储和文件存储)。
      • Storage class encryption 以使用加密启用的存储类创建加密的持久性卷(仅限块)。

        重要

        存储类加密是仅可供 RBD PV 使用的技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

        如需更多信息,请参阅技术预览功能支持范围

    3. 选择 Connect to an external key management service 复选框。这是集群范围加密的可选选项。

      1. 默认情况下,Key Management Service Provider 设置为 Vault
      2. 输入 Vault Service Name、Vault 服务器的主机地址 ('https://<hostname 或 ip>')、端口号Token
      3. 展开 Advanced Settings 以根据您的 Vault 配置输入额外的设置和证书详情:

        1. 后端路径中输入为 OpenShift Container Storage 专用且唯一的 Key Value secret 路径。
        2. 输入 TLS Server NameVault Enterprise Namespace
        3. 通过上传相应的 PEM 编码证书文件提供 CA 证书客户端证书客户端私钥
        4. 点击 Save
    4. 点击 Next
  7. 检查配置详情。若要修改任何配置设置,请单击 Back 以返回到上一配置页面。
  8. Create
  9. 如果 Vault Key/Value(KV)secret 引擎 API,则编辑 configmap,版本 2 则用于使用密钥管理系统(KMS)进行集群范围的加密。

    1. 在 OpenShift Web 控制台中,导航到 Workloads → ConfigMaps
    2. 要查看 KMS 连接详情,点 ocs-kms-connection-details
    3. 编辑 configmap。

      1. Action menu (⋮) → Edit ConfigMap
      2. VAULT_BACKEND 参数设置为 v2

        kind: ConfigMap
        apiVersion: v1
        metadata:
          name: ocs-kms-connection-details
        [...]
        data:
          KMS_PROVIDER: vault
          KMS_SERVICE_NAME: vault
        [...]
          VAULT_BACKEND: v2
        [...]
      3. 点击 Save

验证步骤

  1. 在存储集群详情页面中,存储集群名称旁边显示一个绿色勾号,表示集群创建成功。
  2. 验证已安装存储集群的最后一个 Status 显示为 Phase: Ready,并带有绿色勾号标记。

    • Operators → Installed Operators → Storage Cluster 链接来查看存储集群安装状态。
    • 另外,当使用 Operator Details 选项卡时,您可以点击 Storage Cluster 选项卡查看状态。
    • 要验证 OpenShift Container Storage 是否已成功安装,请参阅验证 OpenShift Container Storage 安装

2.3. 验证 OpenShift Container Storage 部署

使用本节验证 OpenShift Container Storage 是否已正确部署。

2.3.1. 验证 pod 的状态

要确定 OpenShift Container 存储是否已成功部署,您可以验证 pod 是否处于 Running 状态。

步骤

  1. 从 OpenShift Web 控制台左侧窗格中,点击 Workloads → Pods
  2. Project 下拉列表中,选择 openshift-storage

    有关每个组件预期的 pod 数量及其变化取决于节点数量的更多信息,请参阅 表 2.1 “对应 OpenShift Container 存储集群的 Pod”

  3. RunningCompleted 标签页验证以下 pod 是否处于运行状态并完成状态:

    表 2.1. 对应 OpenShift Container 存储集群的 Pod

    组件对应的 pod

    OpenShift Container Storage Operator

    • OCS-operator-*(在任何 worker 节点上有 1 个 pod)
    • ocs-metrics-exporter-*

    Rook-ceph Operator

    rook-ceph-operator-*

    (任何 worker 节点上有 1 个 pod)

    多云对象网关

    • noobaa-operator-* (任何 worker 节点上 1 个 pod)
    • noobaa-core-* (任何存储节点上 1 个 pod)
    • noobaa-db-pg-* (任何存储节点上 1 个 pod)
    • noobaa-endpoint-* (任何存储节点上 1 个 pod)

    MON

    rook-ceph-mon-*

    (在存储节点间分布 3 个 pod)

    MGR

    rook-ceph-mgr-*

    (任何存储节点上的 1 个 pod)

    MDS

    rook-ceph-mds-ocs-storagecluster-cephfilesystem-*

    (2 个 pod 在存储节点间分布)

    CSI

    • cephfs

      • csi-cephfsplugin-* (每个 worker 节点上 1 个 pod)
      • csi-cephfsplugin-provisioner-* (2 个 pod 在不同的 worker 节点上分布)
    • rbd

      • csi-rbdplugin-* (每个 worker 节点上 1 个 pod)
      • csi-rbdplugin-provisioner-* (2 个 pod 在不同的 worker 节点上分步)

    rook-ceph-crashcollector

    rook-ceph-crashcollector-*

    (每个存储节点上 1 个 pod)

    OSD

    • rook-ceph-osd-* (每个设备 1 个 pod)
    • rook-ceph-osd-prepare-ocs-deviceset-* (每个设备 1 个 pod)

2.3.2. 验证 OpenShift Container Storage 集群是否正常运行

  • 点击 OpenShift Web 控制台左侧窗格中的 Home → Overview,然后点击 Persistent Storage 选项卡。
  • Status 卡 中,验证 OCS ClusterData Resiliency 带有绿色勾号标记,如下图所示:

    图 2.1. Persistent Storage Overview Dashboard 中的健康状态卡

    持久性存储仪表板中 Health 卡截图
  • 详情卡中,验证集群信息是否显示如下:

    服务名称
    OpenShift Container Storage
    集群名称
    ocs-storagecluster
    提供者
    OpenStack
    模式
    内部
    版本
    ocs-operator-4.7.0

如需有关使用持久性存储仪表板的 OpenShift Container Storage 集群健康状况的更多信息,请参阅监控 OpenShift Container Storage

2.3.3. 验证 Multicloud 对象网关是否健康

  • 点击 OpenShift Web 控制台左侧窗格中的 Home → Overview,然后点击 Object Service 选项卡。
  • Status 卡 中,验证 Object ServiceData Resiliency 都处于 Ready 状态(绿色钩号)。

    图 2.2. Object Service Overview Dashboard 中的健康状态卡

    对象服务仪表板中健康检查的截图
  • Details 卡 中,验证 MCG 信息是否显示如下:

    服务名称
    OpenShift Container Storage
    系统名称
    多云对象网关
    提供者
    OpenStack
    版本
    ocs-operator-4.7.0

如需有关使用对象服务仪表板的 OpenShift Container Storage 集群健康状况的更多信息,请参阅监控 OpenShift Container Storage

2.3.4. 验证 OpenShift Container Storage 特定的存储类是否存在

验证集群中是否存在存储类:

  • 从 OpenShift Web 控制台左侧窗格中,点击 Storage → Storage Classes
  • 验证是否在创建 OpenShift Container Storage 集群时创建了以下存储类:

    • ocs-storagecluster-ceph-rbd
    • ocs-storagecluster-cephfs
    • openshift-storage.noobaa.io

2.4. 以内部模式卸载 OpenShift Container Storage

2.4.1. 在内部模式中卸载 OpenShift Container Storage

使用本节中的步骤卸载 OpenShift Container Storage。

卸载注解

Storage Cluster 上的注解用于更改卸载过程的行为。要定义卸载行为,在存储集群中引入了以下两个注解:

  • uninstall.ocs.openshift.io/cleanup-policy: delete
  • uninstall.ocs.openshift.io/mode: graceful

下表提供了有关可用于这些注解的不同值的信息:

表 2.2. uninstall.ocs.openshift.io 卸载注解描述

注解订阅价值Default(默认)行为

cleanup-policy

删除

Rook 清理物理驱动器和 DataDirHostPath

cleanup-policy

retain

Rook 不会清理物理驱动器和 DataDirHostPath

模式

graceful

Rook 和 NooBaa 暂停卸载过程,直到管理员/用户移除 PVC 和 OBC

模式

forced

Rook 和 NooBaa 即使使用 Rook 和 NooBaa 置备的 PVC/OBC 分别存在,也会继续卸载。

您可以通过使用以下命令编辑注解值来更改清理策略或卸载模式:

$ oc annotate storagecluster -n openshift-storage ocs-storagecluster uninstall.ocs.openshift.io/cleanup-policy="retain" --overwrite
storagecluster.ocs.openshift.io/ocs-storagecluster annotated
$ oc annotate storagecluster -n openshift-storage ocs-storagecluster uninstall.ocs.openshift.io/mode="forced" --overwrite
storagecluster.ocs.openshift.io/ocs-storagecluster annotated

先决条件

  • 确保 OpenShift Container Storage 集群处于健康状态。当因为资源或节点不足而导致部分 pod 无法成功终止时,卸载过程可能会失败。如果集群处于不健康状态,请在卸载 OpenShift Container Storage 前联络红帽客户支持。
  • 使用 OpenShift Container Storage 提供的存储类,确保应用程序不使用持久性卷声明 (PVC) 或对象存储桶声明 (OBC)。
  • 如果管理员创建了任何自定义资源(如自定义存储类、cephblockpools),则管理员必须在移除消耗这些资源后将它们删除。

步骤

  1. 删除使用 OpenShift Container Storage 的卷快照。

    1. 列出来自所有命名空间的卷快照。

      $ oc get volumesnapshot --all-namespaces
    2. 在上一命令的输出中,识别和删除使用 OpenShift Container Storage 的卷快照。

      $ oc delete volumesnapshot <VOLUME-SNAPSHOT-NAME> -n <NAMESPACE>
  2. 删除使用 OpenShift Container Storage 的 PVC 和 OBC。

    在默认的卸载模式 (graceful) 中,卸载程序会等待所有使用 OpenShift Container Storage 的 PVC 和 OBC 被删除。

    如果要事先删除 PVC 来删除存储集群,您可以将卸载模式注解设置为"强制"并跳过此步骤。这样做会导致系统中出现孤立 PVC 和 OBC。

    1. 使用 OpenShift Container Storage 删除 OpenShift Container Platform 监控堆栈 PVC。

      请查看 第 2.4.1.1 节 “从 OpenShift Container Storage 中删除监控堆栈”

    2. 使用 OpenShift Container Storage 删除 OpenShift Container Platform Registry PVC。

      请查看 第 2.4.1.2 节 “从 OpenShift Container Storage 中删除 OpenShift Container Platform registry”

    3. 使用 OpenShift Container Storage 删除 OpenShift Container Platform 日志 PVC。

      请查看 第 2.4.1.3 节 “从 OpenShift Container Storage 中删除集群日志记录 Operator”

    4. 删除使用 OpenShift Container Storage 置备的其他 PVC 和 OBC。

      • 下面是一个示例脚本,用于标识使用 OpenShift Container Storage 置备的 PVC 和 OBC。该脚本忽略 Openshift Container Storage 内部使用的 PVC。

        #!/bin/bash
        
        RBD_PROVISIONER="openshift-storage.rbd.csi.ceph.com"
        CEPHFS_PROVISIONER="openshift-storage.cephfs.csi.ceph.com"
        NOOBAA_PROVISIONER="openshift-storage.noobaa.io/obc"
        RGW_PROVISIONER="openshift-storage.ceph.rook.io/bucket"
        
        NOOBAA_DB_PVC="noobaa-db"
        NOOBAA_BACKINGSTORE_PVC="noobaa-default-backing-store-noobaa-pvc"
        
        # Find all the OCS StorageClasses
        OCS_STORAGECLASSES=$(oc get storageclasses | grep -e "$RBD_PROVISIONER" -e "$CEPHFS_PROVISIONER" -e "$NOOBAA_PROVISIONER" -e "$RGW_PROVISIONER" | awk '{print $1}')
        
        # List PVCs in each of the StorageClasses
        for SC in $OCS_STORAGECLASSES
        do
                echo "======================================================================"
                echo "$SC StorageClass PVCs and OBCs"
                echo "======================================================================"
                oc get pvc  --all-namespaces --no-headers 2>/dev/null | grep $SC | grep -v -e "$NOOBAA_DB_PVC" -e "$NOOBAA_BACKINGSTORE_PVC"
                oc get obc  --all-namespaces --no-headers 2>/dev/null | grep $SC
                echo
        done
        注意

        云平台省略 RGW_PROVISIONER

      • 删除 OBC。

        $ oc delete obc <obc name> -n <project name>
      • 删除 PVC。

        $ oc delete pvc <pvc name> -n <project-name>
        注意

        确保您已删除了集群中创建的任何自定义后备存储、存储桶类等。

  3. 删除 Storage Cluster 对象并等待相关资源被删除。

    $ oc delete -n openshift-storage storagecluster --all --wait=true
  4. 检查 uninstall.ocs.openshift.io/cleanup-policy 是否已设置为 delete(默认),并确保其状态为 Completed

    $ oc get pods -n openshift-storage | grep -i cleanup
    NAME                                READY   STATUS      RESTARTS   AGE
    cluster-cleanup-job-<xx>        	0/1     Completed   0          8m35s
    cluster-cleanup-job-<yy>     		0/1     Completed   0          8m35s
    cluster-cleanup-job-<zz>     		0/1     Completed   0          8m35s
  5. 确认目录 /var/lib/rook 现在为空。只有 uninstall.ocs.openshift.io/cleanup-policy 注解设置为 delete(默认)时,此目录才为空。

    $ for i in $(oc get node -l cluster.ocs.openshift.io/openshift-storage= -o jsonpath='{ .items[*].metadata.name }'); do oc debug node/${i} -- chroot /host  ls -l /var/lib/rook; done
  6. 如果在安装时启用了加密,在所有 OpenShift Container Storage 节点上的 OSD 设备中删除 dm-crypt 管理的 device-mapper 映射。

    1. 创建 debug pod 和 chroot 到存储节点上的主机。

      $ oc debug node/<node name>
      $ chroot /host
    2. 获取设备名称并记录 OpenShift Container Storage 设备。

      $ dmsetup ls
      ocs-deviceset-0-data-0-57snx-block-dmcrypt (253:1)
    3. 删除映射的设备。

      $ cryptsetup luksClose --debug --verbose ocs-deviceset-0-data-0-57snx-block-dmcrypt
      注意

      如果上述命令因为权限不足而卡住,请运行以下命令:

      • CTRL+Z 退出上述命令。
      • 查找阻塞的进程的 PID。

        $ ps -ef | grep crypt
      • 使用 kill 命令终止进程。

        $ kill -9 <PID>
      • 验证设备名称是否已移除。

        $ dmsetup ls
  7. 删除命名空间并等待删除完成。如果 openshift-storage 是活跃的项目,则需要切换到另一个项目。

    例如:

    $ oc project default
    $ oc delete project openshift-storage --wait=true --timeout=5m

    如果以下命令返回 NotFound 错误,则项目被删除。

    $ oc get project openshift-storage
    注意

    卸载 OpenShift Container Storage 时,如果没有完全删除 命名空间 并处于 Terminating 状态,请执行 故障排除和删除 Uninstall 过程中剩余的资源 的步骤,以识别阻塞命名空间的对象。

  8. 取消标记存储节点。

    $ oc label nodes  --all cluster.ocs.openshift.io/openshift-storage-
    $ oc label nodes  --all topology.rook.io/rack-
  9. 如果节点有污点,则删除 OpenShift Container Storage 污点。

    $ oc adm taint nodes --all node.ocs.openshift.io/storage-
  10. 确认已删除使用 OpenShift Container Storage 置备的所有 PV。如果有任何 PV 处于 Released 状态,请将其删除。

    $ oc get pv
    $ oc delete pv <pv name>
  11. 删除 Multicloud 对象网关存储类。

    $ oc delete storageclass openshift-storage.noobaa.io --wait=true --timeout=5m
  12. 删除 CustomResourceDefinitions

    $ oc delete crd backingstores.noobaa.io bucketclasses.noobaa.io cephblockpools.ceph.rook.io cephclusters.ceph.rook.io cephfilesystems.ceph.rook.io cephnfses.ceph.rook.io cephobjectstores.ceph.rook.io cephobjectstoreusers.ceph.rook.io noobaas.noobaa.io ocsinitializations.ocs.openshift.io storageclusters.ocs.openshift.io cephclients.ceph.rook.io cephobjectrealms.ceph.rook.io cephobjectzonegroups.ceph.rook.io cephobjectzones.ceph.rook.io cephrbdmirrors.ceph.rook.io --wait=true --timeout=5m
  13. 可选:要确保永久删除 vault 密钥,您需要手动删除与 vault 密钥关联的元数据。

    注意

    只有在 Vault Key/Value(KV)机密引擎 API 时才执行此步骤,使用密钥管理系统(KMS)版本 2 进行集群范围加密,因为 vault 密钥被标记为删除并在 OpenShift Container Storage 卸载过程中永久删除。如果需要,您可以在以后恢复它。

    1. 列出密码库中的密钥。

      $ vault kv list <backend_path>
      <backend_path>

      是存储加密密钥的密码库中的路径。

      例如:

      $ vault kv list kv-v2

      输出示例:

      Keys
      -----
      NOOBAA_ROOT_SECRET_PATH/
      rook-ceph-osd-encryption-key-ocs-deviceset-thin-0-data-0m27q8
      rook-ceph-osd-encryption-key-ocs-deviceset-thin-1-data-0sq227
      rook-ceph-osd-encryption-key-ocs-deviceset-thin-2-data-0xzszb
    2. 列出与 vault 密钥关联的元数据。

      $ vault kv get kv-v2/<key>

      对于 Multicloud Object Gateway(MCG)密钥:

      $ vault kv get kv-v2/NOOBAA_ROOT_SECRET_PATH/<key>
      <key>

      是加密密钥。

      例如:

      $ vault kv get kv-v2/rook-ceph-osd-encryption-key-ocs-deviceset-thin-0-data-0m27q8

      输出示例:

      ====== Metadata ======
      Key              Value
      ---              -----
      created_time     2021-06-23T10:06:30.650103555Z
      deletion_time    2021-06-23T11:46:35.045328495Z
      destroyed        false
      version          1
    3. 删除元数据。

      $ vault kv metadata delete kv-v2/<key>

      对于 MCG 密钥:

      $ vault kv metadata delete kv-v2/NOOBAA_ROOT_SECRET_PATH/<key>
      <key>

      是加密密钥。

      例如:

      $ vault kv metadata delete kv-v2/rook-ceph-osd-encryption-key-ocs-deviceset-thin-0-data-0m27q8

      输出示例:

      Success! Data deleted (if it existed) at: kv-v2/metadata/rook-ceph-osd-encryption-key-ocs-deviceset-thin-0-data-0m27q8
    4. 重复这些步骤,以删除与所有 vault 密钥关联的元数据。
  14. 在 OpenShift Container Platform Web 控制台中,确保完全卸载 OpenShift Container Storage,

    1. Home → Overview 访问仪表板。
    2. 验证 Cluster 选项卡旁边是否不再显示持久性存储和对象存储选项卡。

2.4.1.1. 从 OpenShift Container Storage 中删除监控堆栈

使用本节清理 OpenShift Container Storage 中的监控堆栈。

在配置监控堆栈时创建的 PVC 位于 openshift-monitoring 命名空间中。

先决条件

  • PVC 被配置为使用 OpenShift Container Platform 监控堆栈。

    如需更多信息,请参阅 配置监控堆栈

步骤

  1. 列出当前在 openshift-monitoring 命名空间中运行的 pod 和 PVC。

    $ oc get pod,pvc -n openshift-monitoring
    NAME                           READY   STATUS    RESTARTS   AGE
    pod/alertmanager-main-0         3/3     Running   0          8d
    pod/alertmanager-main-1         3/3     Running   0          8d
    pod/alertmanager-main-2         3/3     Running   0          8d
    pod/cluster-monitoring-
    operator-84457656d-pkrxm        1/1     Running   0          8d
    pod/grafana-79ccf6689f-2ll28    2/2     Running   0          8d
    pod/kube-state-metrics-
    7d86fb966-rvd9w                 3/3     Running   0          8d
    pod/node-exporter-25894         2/2     Running   0          8d
    pod/node-exporter-4dsd7         2/2     Running   0          8d
    pod/node-exporter-6p4zc         2/2     Running   0          8d
    pod/node-exporter-jbjvg         2/2     Running   0          8d
    pod/node-exporter-jj4t5         2/2     Running   0          6d18h
    pod/node-exporter-k856s         2/2     Running   0          6d18h
    pod/node-exporter-rf8gn         2/2     Running   0          8d
    pod/node-exporter-rmb5m         2/2     Running   0          6d18h
    pod/node-exporter-zj7kx         2/2     Running   0          8d
    pod/openshift-state-metrics-
    59dbd4f654-4clng                3/3     Running   0          8d
    pod/prometheus-adapter-
    5df5865596-k8dzn                1/1     Running   0          7d23h
    pod/prometheus-adapter-
    5df5865596-n2gj9                1/1     Running   0          7d23h
    pod/prometheus-k8s-0            6/6     Running   1          8d
    pod/prometheus-k8s-1            6/6     Running   1          8d
    pod/prometheus-operator-
    55cfb858c9-c4zd9                1/1     Running   0          6d21h
    pod/telemeter-client-
    78fc8fc97d-2rgfp                3/3     Running   0          8d
    
    NAME                                                              STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
    persistentvolumeclaim/my-alertmanager-claim-alertmanager-main-0   Bound    pvc-0d519c4f-15a5-11ea-baa0-026d231574aa   40Gi       RWO            ocs-storagecluster-ceph-rbd   8d
    persistentvolumeclaim/my-alertmanager-claim-alertmanager-main-1   Bound    pvc-0d5a9825-15a5-11ea-baa0-026d231574aa   40Gi       RWO            ocs-storagecluster-ceph-rbd   8d
    persistentvolumeclaim/my-alertmanager-claim-alertmanager-main-2   Bound    pvc-0d6413dc-15a5-11ea-baa0-026d231574aa   40Gi       RWO            ocs-storagecluster-ceph-rbd   8d
    persistentvolumeclaim/my-prometheus-claim-prometheus-k8s-0        Bound    pvc-0b7c19b0-15a5-11ea-baa0-026d231574aa   40Gi       RWO            ocs-storagecluster-ceph-rbd   8d
    persistentvolumeclaim/my-prometheus-claim-prometheus-k8s-1        Bound    pvc-0b8aed3f-15a5-11ea-baa0-026d231574aa   40Gi       RWO            ocs-storagecluster-ceph-rbd   8d
  2. 编辑监控 configmap

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  3. 删除引用 OpenShift Container Storage 存储类的所有 config 部分,如下例所示并保存。

    编辑前

    .
    .
    .
    apiVersion: v1
    data:
      config.yaml: |
        alertmanagerMain:
          volumeClaimTemplate:
            metadata:
              name: my-alertmanager-claim
            spec:
              resources:
                requests:
                  storage: 40Gi
              storageClassName: ocs-storagecluster-ceph-rbd
        prometheusK8s:
          volumeClaimTemplate:
            metadata:
              name: my-prometheus-claim
            spec:
              resources:
                requests:
                  storage: 40Gi
              storageClassName: ocs-storagecluster-ceph-rbd
    kind: ConfigMap
    metadata:
      creationTimestamp: "2019-12-02T07:47:29Z"
      name: cluster-monitoring-config
      namespace: openshift-monitoring
      resourceVersion: "22110"
      selfLink: /api/v1/namespaces/openshift-monitoring/configmaps/cluster-monitoring-config
      uid: fd6d988b-14d7-11ea-84ff-066035b9efa8
    .
    .
    .

    编辑后

    .
    .
    .
    apiVersion: v1
    data:
      config.yaml: |
    kind: ConfigMap
    metadata:
      creationTimestamp: "2019-11-21T13:07:05Z"
      name: cluster-monitoring-config
      namespace: openshift-monitoring
      resourceVersion: "404352"
      selfLink: /api/v1/namespaces/openshift-monitoring/configmaps/cluster-monitoring-config
      uid: d12c796a-0c5f-11ea-9832-063cd735b81c
    .
    .
    .

    在本例中,alertmanagerMainprometheusK8s 监控组件使用 OpenShift Container Storage PVC。

  4. 删除相关的 PVC。请确定删除所有消耗存储类的 PVC。

    $ oc delete -n openshift-monitoring pvc <pvc-name> --wait=true --timeout=5m

2.4.1.2. 从 OpenShift Container Storage 中删除 OpenShift Container Platform registry

使用这个部分从 OpenShift Container Storage 清理 OpenShift Container Platform registry。如果要配置其他存储,请参阅 镜像 registry

作为配置 OpenShift Container Platform registry 的一部分创建的 PVC 位于 openshift-image-registry 命名空间中。

先决条件

  • 镜像 registry 应配置为使用 OpenShift Container Storage PVC。

步骤

  1. 编辑 configs.imageregistry.operator.openshift.io 对象,并删除 storage 部分中的内容。

    $ oc edit configs.imageregistry.operator.openshift.io

    编辑前

    .
    .
    .
    storage:
        pvc:
            claim: registry-cephfs-rwx-pvc
    .
    .
    .

    编辑后

    .
    .
    .
    storage:
    .
    .
    .

    在本例中,PVC 称为 registry-cephfs-rwx-pvc,现在可以安全地删除。

  2. 删除 PVC。

    $ oc delete pvc <pvc-name> -n openshift-image-registry --wait=true --timeout=5m

2.4.1.3. 从 OpenShift Container Storage 中删除集群日志记录 Operator

使用本节从 OpenShift Container Storage 清理集群日志记录 Operator。

作为配置集群日志记录 Operator 的一部分创建的 PVC 位于 openshift-logging 命名空间中。

先决条件

  • 集群日志记录实例应该已配置为使用 OpenShift Container Storage PVC。

步骤

  1. 删除命名空间中的 ClusterLogging 实例。

    $ oc delete clusterlogging instance -n openshift-logging --wait=true --timeout=5m

    openshift-logging 命名空间中的 PVC 现在可以安全地删除。

  2. 删除 PVC。

    $ oc delete pvc <pvc-name> -n openshift-logging --wait=true --timeout=5m

第 3 章 以外部模式在 Red Hat OpenStack Platform 上部署 OpenShift Container Storage

Red Hat OpenShift Container Storage 可以使用外部托管的 Red Hat Ceph Storage (RHCS) 集群作为 Red Hat OpenStack Platform 上的存储供应商。如需更多信息,请参阅规划部署

有关如何安装 RHCS 4 集群的说明,请参阅安装指南

按照以下步骤,以外部模式部署 OpenShift Container Storage:

3.1. 安装 Red Hat OpenShift Container Storage Operator

您可以使用 Red Hat OpenShift Container Platform Operator Hub 安装 Red Hat OpenShift Container Storage Operator。

先决条件

  • 使用具有 cluster-admin 和 Operator 安装权限的账户访问 OpenShift Container Platform 集群。
  • RHOCP 集群中至少有三个 worker 节点。
  • 如需额外的资源要求,请参阅规划部署
注意
  • 当您需要覆盖 OpenShift Container Storage 的集群范围默认节点选择器时,您可以在命令行界面中使用以下命令为 openshift-storage 命名空间指定空白节点选择器(在这种情况下创建 openshift-storage 命名空间):

    $ oc annotate namespace openshift-storage openshift.io/node-selector=
  • 将节点作为 infra 污点,以确保只在该节点上调度 Red Hat OpenShift Container Storage 资源。这有助于您节省订阅成本。如需更多信息,请参阅管理和分配存储资源指南中的如何将专用 worker 节点用于 Red Hat OpenShift Container Storage 一章。

步骤

  1. 在 Web 控制台中,点 Operators → OperatorHub
  2. 在 Filter by keyword 框中滚动或输入关键字以搜索 OpenShift Container Storage Operator。
  3. 在 OpenShift Container Storage operator 页中点 Install
  4. Install Operator 页面中,默认选择以下所需选项:

    1. 更新频道作为 stable-4.7
    2. 安装模式是 A specific namespace on the cluster
    3. Installed Namespace 为 Operator recommended namespace openshift-storage。如果 Namespace openshift-storage 不存在,它会在 Operator 安装过程中创建。
    4. Approval Strategy 选为 AutomaticManual
    5. Install

      如果选择 Automatic 更新,Operator Lifecycle Manager(OLM)将自动升级 Operator 的运行实例,而无需任何干预。

      如果选择了 手动 更新,则 OLM 会创建一个更新请求。作为集群管理员,您必须手动批准该更新请求,才可将 Operator 更新至新版本。

验证步骤

验证 OpenShift Container Storage Operator 是否显示绿色勾号,指示安装成功。

后续步骤

  • 创建 OpenShift Container Storage 集群。

如需更多信息,请参阅为外部模式创建 OpenShift Container Storage Cluster 服务

3.2. 为外部模式创建 OpenShift Container Storage 集群服务

在 Red Hat OpenStack 平台上部署的 OpenShift Container Storage Operator 上安装 OpenShift Container Storage operator 后,需要创建新的 OpenShift Container Storage 集群服务。

先决条件

  • 从 OpenShift Container Storage 4.7 开始,OpenShift Container Platform 版本必须是 4.7 或更高版本。
  • 必须安装 OpenShift Container Storage Operator。如需更多信息,请参阅使用 Operator Hub] 链接:https://access.redhat.com/documentation/en-us/red_hat_openshift_container_storage/4.7/html-single/deploying_and_managing_openshift_container_storage_using_red_hat_openstack_platform/index#installing-openshift-container-storage-operator-using-the-operator-hub_external-ospInstalling OpenShift Container Storage Operator。
  • 外部集群需要 Red Hat Ceph Storage 版本 4.2z1 或更高版本。如需更多信息,请参阅有关红帽 Ceph 存储发行版和相应 Ceph 软件包版本的知识库文章

    如果您已将红帽 Ceph 存储集群从低于 4.1.1 的版本更新为最新版本,且不是全新部署的集群,您必须在红帽 Ceph 存储集群中手动设置 CephFS 池的应用类型,以外部模式启用 CephFS PVC 创建。

    如需了解更多详细信息,请参阅在外部模式中对 CephFS PVC 创建进行故障排除

  • Red Hat Ceph Storage 必须安装并配置 Ceph 控制面板。如需更多信息,请参阅 Ceph 控制面板安装和访问
  • 红帽建议外部 Red Hat Ceph Storage 集群启用 PG Autoscaler。如需更多信息,请参阅 Red Hat Ceph Storage 文档中的放置组自动扩展部分。
  • 外部 Ceph 集群应当预配置有一个现有的 RBD 池,供使用。如果不存在,请在进行 OpenShift Container Storage 部署前,联系您的 Red Hat Ceph Storage 管理员创建一个。红帽建议为每个 OpenShift Container Storage 集群使用单独的池。

步骤

  1. Operators → Installed Operators 查看所有已安装的 Operator。

    确保所选 项目openshift-storage

  2. 点 Storage Cluster 的 OpenShift Container StorageCreate Instance 链接。
  3. 将 Mode 选择为 External。默认情况下,Internal 被选为部署模式。

    图 3.1. 连接到创建存储集群表单上的外部集群部分

    选择模式为外部后,屏幕截图会显示连接到外部集群部分,您可以在其中下载 python 脚本,然后上传 RHCS json 文件。
  4. 在 Connect to external cluster 部分中,单击 Download Script 链接,以下载用于提取 Ceph 集群详细信息的 python 脚本。
  5. 要提取 Red Hat Ceph Storage (RHCS) 集群详情,请联系 RHCS 管理员,以在带有 admin 密钥 的 Red Hat Ceph Storage 节点上运行下载的 python 脚本。

    1. 在 RHCS 节点上运行以下命令,以查看可用参数的列表:

      # python3 ceph-external-cluster-details-exporter.py --help
      重要

      如果在 Red Hat Enterprise Linux 7.x (RHEL 7.x) 集群中部署了 Red Hat Ceph Storage 4.x 集群,则使用 python 而不是 python3

      注意

      您也可以从 MON 容器(容器化部署)或 MON 节点(rpm 部署)运行 脚本。

    2. 要从 RHCS 集群检索外部集群详情,请运行以下命令

      # python3 ceph-external-cluster-details-exporter.py \
      --rbd-data-pool-name <rbd block pool name>  [optional arguments]

      例如:

      # python3 ceph-external-cluster-details-exporter.py --rbd-data-pool-name ceph-rbd --monitoring-endpoint xxx.xxx.xxx.xxx --monitoring-endpoint-port xxxx --rgw-endpoint xxx.xxx.xxx.xxx:xxxx --run-as-user client.ocs

      在上面的示例中,

      • --rbd-data-pool-name 是用于在 OpenShift Container Storage 中提供块存储的强制参数。
      • --rgw-endpoint 是可选的。如果要通过 Ceph Rados 网关为 OpenShift Container Storage 置备对象存储,请提供此参数。使用以下格式提供端点:<ip_address>:<port>
      • --monitoring-endpoint 是可选的。它是可从 OpenShift 容器平台集群访问的活动 ceph-mgr 的 IP 地址。如果没有提供,则会自动填充该值。
      • --monitoring-endpoint-port 是可选的。它是与 --monitoring-endpoint 指定的 ceph-mgr Prometheus exporter 关联的端口。如果没有提供,则会自动填充该值。
      • -- run-as-user 是一个可选参数,用于为 Ceph 用户提供由 脚本创建的名称。如果没有指定此参数,则会创建一个默认的用户名 client.healthchecker。新用户的权限被设置为:

        • caps: [mgr] allow command config
        • caps: [mon] allow r, allow command quorum_status, allow command version
        • caps: [osd] allow rwx pool=RGW_POOL_PREFIX.rgw.meta, allow r pool=.rgw.root, allow rw pool=RGW_POOL_PREFIX.rgw.control, allow rx pool=RGW_POOL_PREFIX.rgw.log, allow x pool=RGW_POOL_PREFIX.rgw.buckets.index

          使用 python 脚本生成的 JSON 输出示例:

          [{"name": "rook-ceph-mon-endpoints", "kind": "ConfigMap", "data": {"data": "xxx.xxx.xxx.xxx:xxxx", "maxMonId": "0", "mapping": "{}"}}, {"name": "rook-ceph-mon", "kind": "Secret", "data": {"admin-secret": "admin-secret", "fsid": "<fs-id>", "mon-secret": "mon-secret"}}, {"name": "rook-ceph-operator-creds", "kind": "Secret", "data": {"userID": "client.healthchecker", "userKey": "<user-key>"}}, {"name": "rook-csi-rbd-node", "kind": "Secret", "data": {"userID": "csi-rbd-node", "userKey": "<user-key>"}}, {"name": "ceph-rbd", "kind": "StorageClass", "data": {"pool": "ceph-rbd"}}, {"name": "monitoring-endpoint", "kind": "CephCluster", "data": {"MonitoringEndpoint": "xxx.xxx.xxx.xxx", "MonitoringPort": "xxxx"}}, {"name": "rook-csi-rbd-provisioner", "kind": "Secret", "data": {"userID": "csi-rbd-provisioner", "userKey": "<user-key>"}}, {"name": "rook-csi-cephfs-provisioner", "kind": "Secret", "data": {"adminID": "csi-cephfs-provisioner", "adminKey": "<admin-key>"}}, {"name": "rook-csi-cephfs-node", "kind": "Secret", "data": {"adminID": "csi-cephfs-node", "adminKey": "<admin-key>"}}, {"name": "cephfs", "kind": "StorageClass", "data": {"fsName": "cephfs", "pool": "cephfs_data"}}, {"name": "ceph-rgw", "kind": "StorageClass", "data": {"endpoint": "xxx.xxx.xxx.xxx:xxxx", "poolPrefix": "default"}}]

    3. 将 JSON 输出保存到带有 .json 扩展名的文件

      注意

      要使 OpenShift Container Storage 无缝工作,请确保使用 JSON 文件上传的参数(RGW 端点、CephFS 详细信息和 RBD 池等)在创建存储集群后在 RHCS 外部集群上保持不变。

  6. External cluster metadata → Browse 来选择并上传 JSON 文件。

    JSON 文件的内容填充并在文本框中显示。

    图 3.2. JSON 文件内容

    屏幕截图显示凭据文件在上传后的内容
  7. Create

    Create 按钮只有在上传 .json 文件后才会启用。

验证步骤

  1. 验证已安装存储集群的最后一个 Status 显示为 Phase: Ready,并带有绿色勾号标记。

    • Operators → Installed Operators → Storage Cluster 链接来查看存储集群安装状态。
    • 另外,当使用 Operator Details 选项卡时,您可以点击 Storage Cluster 选项卡查看状态。
  2. 要验证 OpenShift Container Storage、Pod 和 StorageClass 是否已成功安装,请参阅验证外部 OpenShift Container Storage 安装模式

3.3. 为外部模式验证 OpenShift Container Storage 安装

使用本节验证 OpenShift Container Storage 是否已正确部署。

3.3.1. 验证 pod 的状态

  1. 从 OpenShift Web 控制台左侧窗格中,点击 Workloads → Pods
  2. Project 下拉列表中,选择 openshift-storage

    有关每个组件预期的 pod 数量及其变化取决于节点数量的更多信息,请参阅 表 3.1 “对应 OpenShift Container Storage 组件的 Pod”

  3. 验证以下 pod 是否处于运行状态:

    表 3.1. 对应 OpenShift Container Storage 组件的 Pod

    组件对应的 pod

    OpenShift Container Storage Operator

    • OCS-operator-*(在任何 worker 节点上有 1 个 pod)
    • ocs-metrics-exporter-*

    Rook-ceph Operator

    rook-ceph-operator-*

    (任何 worker 节点上有 1 个 pod)

    多云对象网关

    • noobaa-operator-* (任何 worker 节点上 1 个 pod)
    • noobaa-core-*(任何 worker 节点上有 1 个 pod)
    • noobaa-db-pg-*(任何 worker 节点上有 1 个 pod)
    • noobaa-endpoint-*( 任何 worker 节点上有 1 个 pod)

    CSI

    • cephfs

      • csi-cephfsplugin-* (每个 worker 节点上 1 个 pod)
      • csi-cephfsplugin-provisioner-* (2 个 pod 在不同的 worker 节点上分布)
    注意

    如果没有在外部集群中部署 MDS,则不会创建 csi-cephfs 插件 pod。

    • rbd

      • csi-rbdplugin-* (每个 worker 节点上 1 个 pod)
      • csi-rbdplugin-provisioner-* (2 个 pod 在不同的 worker 节点上分步)

3.3.2. 验证 OpenShift Container Storage 集群是否正常运行

  • 点击 OpenShift Web 控制台左侧窗格中的 Home → Overview,然后点击 Persistent Storage 选项卡。
  • Status 卡 中,验证 OCS 集群有一个绿色勾号标记,如下图所示:

    图 3.3. Persistent Storage Overview Dashboard 中的健康状态卡

    在持久性存储仪表板中显示外部集群健康状况的状态卡截图
  • 详情卡中,验证集群信息是否显示如下:

    服务名称
    OpenShift Container Storage
    集群名称
    ocs-external-storagecluster
    提供者
    OpenStack
    模式
    外部
    版本
    ocs-operator-4.7.0

如需有关使用持久性存储仪表板的 OpenShift Container Storage 集群健康状况的更多信息,请参阅监控 OpenShift Container Storage

3.3.3. 验证 Multicloud 对象网关是否健康

  • 点击 OpenShift Web 控制台左侧窗格中的 Home → Overview,然后点击 Object Service 选项卡。
  • Status 卡 中,验证 Object ServiceData Resiliency 都处于 Ready 状态(绿色钩号)。

    图 3.4. Object Service Overview Dashboard 中的健康状态卡

    对象服务仪表板中健康检查的截图
  • Details 卡 中,验证 MCG 信息是否正确显示,如下:

    服务名称
    OpenShift Container Storage
    系统名称

    多云对象网关

    RADOS 对象网关

    提供者
    OpenStack
    版本
    ocs-operator-4.7.0
注意

RADOS 对象网关仅列出在以外部模式部署 OpenShift Container Storage 时包含 RADOS 对象网关端点详细信息的情况。

如需有关使用对象服务仪表板的 OpenShift Container Storage 集群健康状况的更多信息,请参阅 监控 OpenShift Container Storage

3.3.4. 验证存储类是否已创建并列出

  • 从 OpenShift Web 控制台左侧窗格中,点击 Storage → Storage Classes
  • 验证是否在创建 OpenShift Container Storage 集群时创建了以下存储类:

    • ocs-external-storagecluster-ceph-rbd
    • ocs-external-storagecluster-ceph-rgw
    • ocs-external-storagecluster-cephfs
    • openshift-storage.noobaa.io
注意
  • 如果没有在外部集群中部署 MDS,则不会创建 ocs-external-storagecluster-cephfs 存储类。
  • 如果没有在外部集群中部署 RGW,则不会创建 ocs-external-storagecluster-ceph-rgw 存储类。

如需有关 MDS 和 RGW 的更多信息,请参阅 Red Hat Ceph Storage 文档

3.3.5. 验证 Ceph 集群是否已连接

运行以下命令,以验证 OpenShift Container Storage 集群是否已连接到外部 Red Hat Ceph Storage 集群。

$ oc get cephcluster -n openshift-storage
NAME                                      DATADIRHOSTPATH     MONCOUNT    AGE      PHASE       MESSAGE                         HEALTH
ocs-external-storagecluster-cephcluster                                   31m15s   Connected   Cluster connected successfully  HEALTH_OK

3.3.6. 验证存储集群是否已就绪

运行以下命令,以验证存储集群是否已就绪,并且 External 选项设为 true。

$ oc get storagecluster -n openshift-storage
NAME                        AGE      PHASE EXTERNAL  CREATED AT              VERSION
ocs-external-storagecluster 31m15s   Ready true      2021-02-29T20:43:04Z    4.7.0

3.4. 以外部模式卸载 OpenShift Container Storage

3.4.1. 以外部模式卸载 OpenShift Container Storage

使用本节中的步骤卸载 OpenShift Container Storage。卸载 OpenShift Container Storage 不会从外部集群中删除 RBD 池,或卸载外部 Red Hat Ceph Storage 集群。

卸载注解

Storage Cluster 上的注解用于更改卸载过程的行为。要定义卸载行为,在存储集群中引入了以下两个注解:

  • uninstall.ocs.openshift.io/cleanup-policy: delete
  • uninstall.ocs.openshift.io/mode: graceful
注意

uninstall.ocs.openshift.io/cleanup-policy 不适用于外部模式。

下表提供了有关可用于这些注解的不同值的信息:

表 3.2. uninstall.ocs.openshift.io 卸载注解描述

注解订阅价值Default(默认)行为

cleanup-policy

删除

Rook 清理物理驱动器和 DataDirHostPath

cleanup-policy

retain

Rook 不会清理物理驱动器和 DataDirHostPath

模式

graceful

Rook 和 NooBaa 暂停卸载过程,直到管理员/用户移除 PVC 和 OBC

模式

forced

rook 和 NooBaa 会在卸载过程中继续进行,即使 PVC/OBCs 使用 Rook 和 NooBaa 置备

您可以通过使用以下命令编辑注解值来更改卸载模式:

$ oc annotate storagecluster ocs-external-storagecluster uninstall.ocs.openshift.io/mode="forced" --overwrite
storagecluster.ocs.openshift.io/ocs-external-storagecluster annotated

先决条件

  • 确保 OpenShift Container Storage 集群处于健康状态。当因为资源或节点不足而导致部分 pod 无法成功终止时,卸载过程可能会失败。如果集群处于不健康状态,请在卸载 OpenShift Container Storage 前联络红帽客户支持。
  • 使用 OpenShift Container Storage 提供的存储类,确保应用程序不使用持久性卷声明 (PVC) 或对象存储桶声明 (OBC)。

步骤

  1. 删除使用 OpenShift Container Storage 的卷快照。

    1. 列出所有命名空间中的卷快照

      $ oc get volumesnapshot --all-namespaces
    2. 在上一命令的输出中,识别和删除使用 OpenShift Container Storage 的卷快照。

      $ oc delete volumesnapshot <VOLUME-SNAPSHOT-NAME> -n <NAMESPACE>
  2. 删除使用 OpenShift Container Storage 的 PVC 和 OBC。

    在默认的卸载模式 (graceful) 中,卸载程序会等待所有使用 OpenShift Container Storage 的 PVC 和 OBC 被删除。

    如果要事先删除 PVC 来删除存储集群,您可以将卸载模式注解设置为"强制"并跳过此步骤。这样做会导致系统中出现孤立 PVC 和 OBC。

    1. 使用 OpenShift Container Storage 删除 OpenShift Container Platform 监控堆栈 PVC。

      请查看 第 2.4.1.1 节 “从 OpenShift Container Storage 中删除监控堆栈”

    2. 使用 OpenShift Container Storage 删除 OpenShift Container Platform Registry PVC。

      请查看 第 2.4.1.2 节 “从 OpenShift Container Storage 中删除 OpenShift Container Platform registry”

    3. 使用 OpenShift Container Storage 删除 OpenShift Container Platform 日志 PVC。

      请查看 第 2.4.1.3 节 “从 OpenShift Container Storage 中删除集群日志记录 Operator”

    4. 删除使用 OpenShift Container Storage 置备的其他 PVC 和 OBC。

      • 下面是一个示例脚本,用于标识使用 OpenShift Container Storage 置备的 PVC 和 OBC。该脚本忽略 Openshift Container Storage 内部使用的 PVC 和 OBC。

        #!/bin/bash
        
        RBD_PROVISIONER="openshift-storage.rbd.csi.ceph.com"
        CEPHFS_PROVISIONER="openshift-storage.cephfs.csi.ceph.com"
        NOOBAA_PROVISIONER="openshift-storage.noobaa.io/obc"
        RGW_PROVISIONER="openshift-storage.ceph.rook.io/bucket"
        
        NOOBAA_DB_PVC="noobaa-db"
        NOOBAA_BACKINGSTORE_PVC="noobaa-default-backing-store-noobaa-pvc"
        
        # Find all the OCS StorageClasses
        OCS_STORAGECLASSES=$(oc get storageclasses | grep -e "$RBD_PROVISIONER" -e "$CEPHFS_PROVISIONER" -e "$NOOBAA_PROVISIONER" -e "$RGW_PROVISIONER" | awk '{print $1}')
        
        # List PVCs in each of the StorageClasses
        for SC in $OCS_STORAGECLASSES
        do
                echo "======================================================================"
                echo "$SC StorageClass PVCs and OBCs"
                echo "======================================================================"
                oc get pvc  --all-namespaces --no-headers 2>/dev/null | grep $SC | grep -v -e "$NOOBAA_DB_PVC" -e "$NOOBAA_BACKINGSTORE_PVC"
                oc get obc  --all-namespaces --no-headers 2>/dev/null | grep $SC
                echo
        done
      • 删除 OBC。

        $ oc delete obc <obc name> -n <project name>
      • 删除 PVC。

        $ oc delete pvc <pvc name> -n <project-name>

        确保您已删除了集群中创建的任何自定义后备存储、存储桶类等。

  3. 删除 Storage Cluster 对象并等待相关资源被删除。

    $ oc delete -n openshift-storage storagecluster --all --wait=true
  4. 删除命名空间并等待删除完成。如果 openshift-storage 是活跃的项目,则需要切换到另一个项目。

    例如:

    $ oc project default
    $ oc delete project openshift-storage --wait=true --timeout=5m

    如果以下命令返回 NotFound 错误,则项目被删除。

    $ oc get project openshift-storage
    注意

    卸载 OpenShift Container Storage 时,如果没有完全删除命名空间并处于 Terminating 状态,请执行 故障排除和删除 Uninstall 过程中剩余的资源 的步骤,以识别阻塞命名空间的对象。

  5. 确认已删除使用 OpenShift Container Storage 置备的所有 PV。如果有任何 PV 处于 Released 状态,请将其删除。

    $ oc get pv
    $ oc delete pv <pv name>
  6. 删除 Multicloud 对象网关存储类。

    $ oc delete storageclass openshift-storage.noobaa.io --wait=true --timeout=5m
  7. 删除 CustomResourceDefinitions

    $ oc delete crd backingstores.noobaa.io bucketclasses.noobaa.io cephblockpools.ceph.rook.io cephclusters.ceph.rook.io cephfilesystems.ceph.rook.io cephnfses.ceph.rook.io cephobjectstores.ceph.rook.io cephobjectstoreusers.ceph.rook.io noobaas.noobaa.io ocsinitializations.ocs.openshift.io storageclusters.ocs.openshift.io cephclients.ceph.rook.io cephobjectrealms.ceph.rook.io cephobjectzonegroups.ceph.rook.io cephobjectzones.ceph.rook.io cephrbdmirrors.ceph.rook.io --wait=true --timeout=5m
  8. 在 OpenShift Container Platform Web 控制台中,确保完全卸载 OpenShift Container Storage,

    1. HomeOverview 访问仪表板。
    2. 验证 Persistent StorageObject Service 标签页没有在 Cluster 标签页旁显示。

3.4.2. 从 OpenShift Container Storage 中删除监控堆栈

使用本节清理 OpenShift Container Storage 中的监控堆栈。

在配置监控堆栈时创建的 PVC 位于 openshift-monitoring 命名空间中。

先决条件

  • PVC 被配置为使用 OpenShift Container Platform 监控堆栈。

    如需更多信息,请参阅 配置监控堆栈

步骤

  1. 列出当前在 openshift-monitoring 命名空间中运行的 pod 和 PVC。

    $ oc get pod,pvc -n openshift-monitoring
    NAME                           READY   STATUS    RESTARTS   AGE
    pod/alertmanager-main-0         3/3     Running   0          8d
    pod/alertmanager-main-1         3/3     Running   0          8d
    pod/alertmanager-main-2         3/3     Running   0          8d
    pod/cluster-monitoring-
    operator-84457656d-pkrxm        1/1     Running   0          8d
    pod/grafana-79ccf6689f-2ll28    2/2     Running   0          8d
    pod/kube-state-metrics-
    7d86fb966-rvd9w                 3/3     Running   0          8d
    pod/node-exporter-25894         2/2     Running   0          8d
    pod/node-exporter-4dsd7         2/2     Running   0          8d
    pod/node-exporter-6p4zc         2/2     Running   0          8d
    pod/node-exporter-jbjvg         2/2     Running   0          8d
    pod/node-exporter-jj4t5         2/2     Running   0          6d18h
    pod/node-exporter-k856s         2/2     Running   0          6d18h
    pod/node-exporter-rf8gn         2/2     Running   0          8d
    pod/node-exporter-rmb5m         2/2     Running   0          6d18h
    pod/node-exporter-zj7kx         2/2     Running   0          8d
    pod/openshift-state-metrics-
    59dbd4f654-4clng                3/3     Running   0          8d
    pod/prometheus-adapter-
    5df5865596-k8dzn                1/1     Running   0          7d23h
    pod/prometheus-adapter-
    5df5865596-n2gj9                1/1     Running   0          7d23h
    pod/prometheus-k8s-0            6/6     Running   1          8d
    pod/prometheus-k8s-1            6/6     Running   1          8d
    pod/prometheus-operator-
    55cfb858c9-c4zd9                1/1     Running   0          6d21h
    pod/telemeter-client-
    78fc8fc97d-2rgfp                3/3     Running   0          8d
    
    NAME                                                              STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
    persistentvolumeclaim/my-alertmanager-claim-alertmanager-main-0   Bound    pvc-0d519c4f-15a5-11ea-baa0-026d231574aa   40Gi       RWO            ocs-external-storagecluster-ceph-rbd   8d
    persistentvolumeclaim/my-alertmanager-claim-alertmanager-main-1   Bound    pvc-0d5a9825-15a5-11ea-baa0-026d231574aa   40Gi       RWO            ocs-external-storagecluster-ceph-rbd   8d
    persistentvolumeclaim/my-alertmanager-claim-alertmanager-main-2   Bound    pvc-0d6413dc-15a5-11ea-baa0-026d231574aa   40Gi       RWO            ocs-external-storagecluster-ceph-rbd   8d
    persistentvolumeclaim/my-prometheus-claim-prometheus-k8s-0        Bound    pvc-0b7c19b0-15a5-11ea-baa0-026d231574aa   40Gi       RWO            ocs-external-storagecluster-ceph-rbd   8d
    persistentvolumeclaim/my-prometheus-claim-prometheus-k8s-1        Bound    pvc-0b8aed3f-15a5-11ea-baa0-026d231574aa   40Gi       RWO            ocs-external-storagecluster-ceph-rbd   8d
  2. 编辑监控 configmap

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  3. 删除引用 OpenShift Container Storage 存储类的所有 config 部分,如下例所示并保存。

    编辑前

    .
    .
    .
    apiVersion: v1
    data:
      config.yaml: |
        alertmanagerMain:
          volumeClaimTemplate:
            metadata:
              name: my-alertmanager-claim
            spec:
              resources:
                requests:
                  storage: 40Gi
              storageClassName: ocs-external-storagecluster-ceph-rbd
        prometheusK8s:
          volumeClaimTemplate:
            metadata:
              name: my-prometheus-claim
            spec:
              resources:
                requests:
                  storage: 40Gi
              storageClassName: ocs-external-storagecluster-ceph-rbd
    kind: ConfigMap
    metadata:
      creationTimestamp: "2019-12-02T07:47:29Z"
      name: cluster-monitoring-config
      namespace: openshift-monitoring
      resourceVersion: "22110"
      selfLink: /api/v1/namespaces/openshift-monitoring/configmaps/cluster-monitoring-config
      uid: fd6d988b-14d7-11ea-84ff-066035b9efa8
    
    
    .
    .
    .

    编辑后

    .
    .
    .
    apiVersion: v1
    data:
      config.yaml: |
    kind: ConfigMap
    metadata:
      creationTimestamp: "2019-11-21T13:07:05Z"
      name: cluster-monitoring-config
      namespace: openshift-monitoring
      resourceVersion: "404352"
      selfLink: /api/v1/namespaces/openshift-monitoring/configmaps/cluster-monitoring-config
      uid: d12c796a-0c5f-11ea-9832-063cd735b81c
    .
    .
    .

    在本例中,alertmanagerMainprometheusK8s 监控组件使用 OpenShift Container Storage PVC。

  4. 列出使用 PVC 的 pod。

    在本例中,消耗 PVC 的 alertmanagerMainprometheusK8s pod 处于 Terminating 状态。这些 pod 不再使用 OpenShift Container Storage PVC 后,您可以删除 PVC。

    $ oc get pod,pvc -n openshift-monitoring
    NAME                                               READY   STATUS      RESTARTS AGE
    pod/alertmanager-main-0                            3/3     Terminating   0      10h
    pod/alertmanager-main-1                            3/3     Terminating   0      10h
    pod/alertmanager-main-2                            3/3     Terminating   0      10h
    pod/cluster-monitoring-operator-84cd9df668-zhjfn   1/1     Running       0      18h
    pod/grafana-5db6fd97f8-pmtbf                       2/2     Running       0      10h
    pod/kube-state-metrics-895899678-z2r9q             3/3     Running       0      10h
    pod/node-exporter-4njxv                            2/2     Running       0      18h
    pod/node-exporter-b8ckz                            2/2     Running       0      11h
    pod/node-exporter-c2vp5                            2/2     Running       0      18h
    pod/node-exporter-cq65n                            2/2     Running       0      18h
    pod/node-exporter-f5sm7                            2/2     Running       0      11h
    pod/node-exporter-f852c                            2/2     Running       0      18h
    pod/node-exporter-l9zn7                            2/2     Running       0      11h
    pod/node-exporter-ngbs8                            2/2     Running       0      18h
    pod/node-exporter-rv4v9                            2/2     Running       0      18h
    pod/openshift-state-metrics-77d5f699d8-69q5x       3/3     Running       0      10h
    pod/prometheus-adapter-765465b56-4tbxx             1/1     Running       0      10h
    pod/prometheus-adapter-765465b56-s2qg2             1/1     Running       0      10h
    pod/prometheus-k8s-0                               6/6     Terminating   1      9m47s
    pod/prometheus-k8s-1                               6/6     Terminating   1      9m47s
    pod/prometheus-operator-cbfd89f9-ldnwc             1/1     Running       0      43m
    pod/telemeter-client-7b5ddb4489-2xfpz              3/3     Running       0      10h
    
    NAME                                                      STATUS  VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
    persistentvolumeclaim/ocs-alertmanager-claim-alertmanager-main-0   Bound    pvc-2eb79797-1fed-11ea-93e1-0a88476a6a64   40Gi       RWO            ocs-external-storagecluster-ceph-rbd   19h
    persistentvolumeclaim/ocs-alertmanager-claim-alertmanager-main-1   Bound    pvc-2ebeee54-1fed-11ea-93e1-0a88476a6a64   40Gi       RWO            ocs-external-storagecluster-ceph-rbd   19h
    persistentvolumeclaim/ocs-alertmanager-claim-alertmanager-main-2   Bound    pvc-2ec6a9cf-1fed-11ea-93e1-0a88476a6a64   40Gi       RWO            ocs-external-storagecluster-ceph-rbd   19h
    persistentvolumeclaim/ocs-prometheus-claim-prometheus-k8s-0        Bound    pvc-3162a80c-1fed-11ea-93e1-0a88476a6a64   40Gi       RWO            ocs-external-storagecluster-ceph-rbd   19h
    persistentvolumeclaim/ocs-prometheus-claim-prometheus-k8s-1        Bound    pvc-316e99e2-1fed-11ea-93e1-0a88476a6a64   40Gi       RWO            ocs-external-storagecluster-ceph-rbd   19h
  5. 删除相关的 PVC。请确定删除所有消耗存储类的 PVC。

    $ oc delete -n openshift-monitoring pvc <pvc-name> --wait=true --timeout=5m

3.4.3. 从 OpenShift Container Storage 中删除 OpenShift Container Platform registry

使用这个部分从 OpenShift Container Storage 清理 OpenShift Container Platform registry。如果要配置其他存储,请参阅 镜像 registry

作为配置 OpenShift Container Platform registry 的一部分创建的 PVC 位于 openshift-image-registry 命名空间中。

先决条件

  • 镜像 registry 应配置为使用 OpenShift Container Storage PVC。

步骤

  1. 编辑 configs.imageregistry.operator.openshift.io 对象,并删除 storage 部分中的内容。

    $ oc edit configs.imageregistry.operator.openshift.io

    编辑前

    .
    .
    .
    storage:
      pvc:
        claim: registry-cephfs-rwx-pvc
    .
    .
    .

    编辑后

    .
    .
    .
    storage:
      emptyDir: {}
    .
    .
    .

    + 在本例中,PVC 名为 registry-cephfs-rwx-pvc,现在可以安全地删除。

  2. 删除 PVC。

    $ oc delete pvc <pvc-name> -n openshift-image-registry --wait=true --timeout=5m

3.4.4. 从 OpenShift Container Storage 中删除集群日志记录 Operator

使用本节从 OpenShift Container Storage 清理集群日志记录 Operator。

作为配置集群日志记录 Operator 的一部分创建的 PVC 位于 openshift-logging 命名空间中。

先决条件

  • 集群日志记录实例应该已配置为使用 OpenShift Container Storage PVC。

步骤

  1. 删除命名空间中的 ClusterLogging 实例。

    $ oc delete clusterlogging instance -n openshift-logging --wait=true --timeout=5m

    openshift-logging 命名空间中的 PVC 现在可以安全地删除。

  2. 删除 PVC。

    $ oc delete pvc <pvc-name> -n openshift-logging --wait=true --timeout=5m

第 4 章 存储类和存储池

OpenShift Container Storage Operator 根据使用的平台安装默认存储类。这个默认存储类由 Operator 所有和控制,且无法删除或修改。但是,如果您希望存储类具有不同的行为,可以创建自定义存储类。

您可以创建多个存储池,映射到提供以下功能的存储类:

  • 使具有自身高可用性的应用能够使用具有两个副本的持久卷,从而可能提高应用性能。
  • 使用启用了压缩的存储类为持久性卷声明节省空间。
注意

外部模式 OpenShift Container Storage 集群不支持多个存储类和多个池。

注意

使用单个设备集的最小集群,只能创建两个新的存储类。每个存储集群扩展都允许两个新的附加存储类。

4.1. 创建存储类和池

您可以使用现有池创建存储类,也可以在创建存储类时为存储类创建新池。

先决条件

确保 OpenShift Container Storage 集群处于 Ready 状态。

步骤

  1. 登录 OpenShift Web 控制台。
  2. StorageStorage Classes
  3. Create Storage Class
  4. 输入存储类 NameDescription
  5. 为 Reclaim Policy 选择 DeleteRetain。默认情况下,选择 Delete
  6. 选择 RBD Provisioner,这是用于调配持久卷的插件。
  7. 您可以创建新池或使用现有的池。

    创建新池
    1. 输入池的名称。
    2. 选择 双向复制三向复制作为数据保护策略。
    3. 如果需要压缩数据,选择启用压缩

      启用压缩可能会影响应用程序的性能,在已压缩或加密的数据时可能会证明无效。在启用压缩之前写入的数据不会压缩。

    4. 单击 Create 以创建存储池。
    5. 创建池后,单击 Finish
    6. Create 创建存储类。
    使用现有的池
    1. 从列表中选择池。
    2. Create 使用所选池创建存储类。

4.2. 为持久性卷加密创建存储类

使用外部密钥管理系统(KMS)通过存储类加密置备的持久性卷是一个技术预览功能。持久卷加密仅可用于 RBD PV。

重要

存储类加密是仅可供 RBD PV 使用的技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

如需更多信息,请参阅技术预览功能支持范围

先决条件

  • OpenShift Container Storage 集群处于 Ready 状态。
  • 在外部密钥管理系统 (KMS) 上,

    • 确保存在具有令牌的策略,并且启用了 Vault 中的键值后端路径。请参阅在 Vault 中启用键值和策略
    • 确保您在 Vault 服务器上使用签名的证书。
  • 在租户命名空间中创建一个 secret,如下所示:

    • 在 OpenShift Container Platform web 控制台中进入 Workloads → Secrets
    • Create → Key/value secret
    • 输入 Secret Name 作为 ceph-csi-kms-token
    • 输入 Key 作为 token
    • 输入 Value。它是来自 Vault 的令牌。您可以单击 Browse 来选择并上传含有令牌的文件,或者直接在文本框中输入令牌。
    • Create
注意

只有在所有使用 ceph-csi-kms-token 的加密 PVC 已被删除后,才能删除令牌。

步骤

  1. 导航到 StorageStorage Classes
  2. Create Storage Class
  3. 输入存储类 NameDescription
  4. Reclaim Policy 选择 Delete 或 Retain。默认情况下,选择 Delete。
  5. 选择 RBD Provisioner openshift-storage.rbd.csi.ceph.com,这是用于调配持久卷的插件。
  6. 选择要 存储卷数据的存储池。
  7. 选中启用加密复选框。

    1. 默认情况下,Key Management Service Provider 设置为 Vault。
    2. 输入 Vault Service Name、Vault 服务器的主机地址 ('https://<hostname or ip>')、端口号
    3. 展开 Advanced Settings 以进入证书详情。

      1. 后端路径中输入为 OpenShift Container Storage 专用且唯一的 Key Value secret 路径。
      2. (可选)输入 TLS 服务器名称Vault Enterprise 命名空间
      3. 通过上传相应的 PEM 编码证书文件提供 CA 证书客户端证书客户端私钥
      4. 点击 Save
    4. 连接
  8. 检查外部密钥管理服务连接详细信息。要修改信息,请点击 Change connection details 并编辑字段。
  9. Create
  10. 如果 Hashicorp Vault 设置不允许自动检测后端路径使用的 Key/Value(KV)机密引擎 API 版本,则编辑 configmap 以添加 VAULT_BACKEND 参数。

    注意

    VAULT_BACKEND 是一个可选参数,添加到 configmap 中,用于指定与后端路径关联的 KV secret 引擎 API 版本。确保值与为后端路径设置的 KV secret 引擎 API 版本匹配,否则可能会导致持久性卷声明(PVC)创建过程中失败。

    1. 识别新创建的存储类使用的 encryptionKMSID

      1. 在 OpenShift Web 控制台中,导航到 Storage → Storage Classes
      2. Storage class name → YAML 标签页。
      3. 捕获存储类使用的 encryptionKMSID

        例如:

        encryptionKMSID: 1-vault
    2. 在 OpenShift Web 控制台中,导航到 Workloads → ConfigMaps
    3. 要查看 KMS 连接详情,请单击点击 csi-kms-connection-details
    4. 编辑 configmap。

      1. 点击 Action 菜单 (⋮)Edit ConfigMap
      2. 根据为之前确定的 encryptionKMSID 配置的后端,添加 VAULT_BACKEND 参数。

        您可以为 KV secret engine API 分配 kv,版本 1 和 kv-v2 for KV secret engine API,版本 2 作为 VAULT_BACKEND 参数。

        例如:

        kind: ConfigMap
        apiVersion: v1
        metadata:
          name: csi-kms-connection-details
        [...]
        data:
          1-vault: >-
        
            {
              "KMS_PROVIDER": "vaulttokens",
              "KMS_SERVICE_NAME": "vault",
              [...]
              "VAULT_BACKEND": "kv-v2"
            }
      3. 点击 Save
重要

红帽与技术合作伙伴合作,将本文档作为为客户提供服务。但是,红帽不为 Hashicorp 产品提供支持。有关此产品的技术协助,请联系 Hashicorp

第 5 章 为 OpenShift Container Platform 服务配置存储

您可以使用 OpenShift Container Storage 为 OpenShift Container Platform 服务(如镜像 registry、监控和日志记录)提供存储。

为这些服务配置存储的过程取决于 OpenShift Container Storage 部署中使用的基础架构。

警告

始终确保您具有适用于这些服务的大量存储容量。如果这些关键服务的存储空间不足,集群就会变得不可用,且很难恢复。

红帽建议为这些服务配置较短的策展和保留间隔。详情请参阅 OpenShift Container Platform 文档中的配置持久性存储配置 Curator 调度修改 Prometheus 指标数据的保留时间部分。

如果您确实耗尽这些服务的存储空间,请联系红帽客户支持。

5.1. 将 Image Registry 配置为使用 OpenShift Container Storage

OpenShift Container Platform 提供了一个内建的容器镜像 Registry,它作为一个标准的工作负载在集群中运行。registry 通常用作集群中构建的镜像的发布目标,以及在集群中运行的工作负载的镜像源。

警告

此过程不会将数据从现有镜像 registry 迁移到新镜像 registry。如果您在现有 registry 中已有容器镜像,请在完成此过程前备份 registry,并在这个过程完成后重新注册您的镜像。

先决条件

  • 具有 OpenShift Web 控制台的管理访问权限。
  • OpenShift Container Storage Operator 已安装并在 openshift-storage 命名空间中运行。在 OpenShift Web 控制台中,点 OperatorsInstalled Operators 查看已安装的 Operator。
  • Image Registry Operator 在 openshift-image-registry 命名空间中安装并运行。在 OpenShift Web 控制台中,点 AdministrationCluster SettingsCluster Operators 查看集群操作器。
  • 带有 provisioner openshift-storage.cephfs.csi.ceph.com 的存储类可用。在 OpenShift Web 控制台中,点 Storage → Storage Classes 查看可用的存储类。

步骤

  1. 为镜像 Registry 创建一个持久性卷声明

    1. 在 OpenShift Web 控制台中,点击 StoragePersistent Volume Claims
    2. Project 设置为 openshift-image-registry
    3. 单击 Create Persistent Volume Claim

      1. 在上方检索的可用存储类列表中,使用置备程序 openshift-storage.cephfs.csi.ceph.com 指定存储类
      2. 指定持久性卷声明 名称,如 ocs4registry
      3. 指定 Shared Access (RWX) 访问模式
      4. Size 指定为最少 100 GB。
      5. Create

        等待新持久卷声明的状态变为 Bound

  2. 将集群的 Image Registry 配置为使用新的持久卷声明

    1. AdministrationCustom Resource Definitions
    2. 点与 imageregistry.operator.openshift.io 组关联的 Config 自定义资源定义。
    3. 实例 选项卡。
    4. 在集群实例外,点 Action Menu(⋮)Edit Config
    5. 添加新的持久性卷声明作为镜像 Registry 的持久性存储。

      1. spec: 下添加以下内容,并替换现有的 storage: 部分(如有必要)。

          storage:
            pvc:
              claim: <new-pvc-name>

        例如:

          storage:
            pvc:
              claim: ocs4registry
      2. 点击 Save
  3. 验证新配置是否正在使用。

    1. 点击 WorkloadsPods
    2. Project 设置为 openshift-image-registry
    3. 验证新的 image-registry-* pod 的状态是否为 Running,并且以前的 image-registry-* pod 已终止。
    4. 点击新 image-registry-* Pod 查看 pod 详情。
    5. 向下滚动到 Volumes,再验证 registry-storage 卷是否具有与您的新持久性卷声明匹配的 Type,如 ocs4registry

5.2. 将监控配置为使用 OpenShift Container Storage

OpenShift Container Storage 提供了一个监控堆栈,其中包含 Prometheus 和 Alert Manager。

按照本节中的说明,将 OpenShift Container Storage 配置为监控堆栈的存储。

重要

如果存储空间不足,则监控将无法正常工作。始终确保您拥有大量用于监控的存储容量。

红帽建议为此服务配置简短的保留间隔。详情请参阅 OpenShift Container Platform 文档中的 Prometheus 指标指南的修改保留时间

先决条件

  • 具有 OpenShift Web 控制台的管理访问权限。
  • OpenShift Container Storage Operator 已安装并在 openshift-storage 命名空间中运行。在 OpenShift Web 控制台中,点 OperatorsInstalled Operators 查看已安装的 Operator。
  • 监控 Operator 在 openshift-monitoring 命名空间内安装并运行。在 OpenShift Web 控制台中,点 AdministrationCluster SettingsCluster Operators 查看集群操作器。
  • 带有 provisioner openshift-storage.rbd.csi.ceph.com 的存储类可用。在 OpenShift Web 控制台中,点 Storage → Storage Classes 查看可用的存储类。

步骤

  1. 在 OpenShift Web 控制台中,前往 WorkloadsConfig Maps
  2. Project 下拉菜单设置为 openshift-monitoring
  3. 单击 Create Config Map
  4. 使用以下命令定义一个新的 cluster-monitoring-config Config Map:

    将尖括号 (<, >) 中的内容替换为您自己的值,如 retention: 24hstorage: 40Gi

    storageClassName 替换为使用 provisioner openshift-storage.rbd.csi.ceph.comstorageclass。在下例中,storageclass 的名称为 ocs-storagecluster-ceph-rbd

    cluster-monitoring-config Config Map 示例

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
          prometheusK8s:
            retention: <time to retain monitoring files, e.g. 24h>
            volumeClaimTemplate:
              metadata:
                name: ocs-prometheus-claim
              spec:
                storageClassName: ocs-storagecluster-ceph-rbd
                resources:
                  requests:
                    storage: <size of claim, e.g. 40Gi>
          alertmanagerMain:
            volumeClaimTemplate:
              metadata:
                name: ocs-alertmanager-claim
              spec:
                storageClassName: ocs-storagecluster-ceph-rbd
                resources:
                  requests:
                    storage: <size of claim, e.g. 40Gi>

  5. 单击 Create 以保存并创建 Config Map。

验证步骤

  1. 验证持久卷声明是否已绑定到 pod。

    1. 进入 StoragePersistent Volume Claims
    2. Project 下拉菜单设置为 openshift-monitoring
    3. 验证 5 持久性卷声明是否可见,状态为 Bound,附加到三个 alertmanager-main-* pod,以及两个 prometheus-k8s-* pod。

      监控创建和绑定的存储

      Screenshot of OpenShift Web Console showing five pods with persistent volume claims bound in the openshift-monitoring project

  2. 验证新 alertmanager-main-* pod 的状态是否显示为 Running

    1. 进入 WorkloadsPods
    2. 点击新 alertmanager-main-* pod 查看 pod 详情。
    3. 向下滚动到 Volumes,再验证卷是否具有 Type (ocs-alertmanager-claim),它与您的新持久性卷声明匹配,如 ocs-alertmanager-claim-alertmanager-main-0

      附加到 alertmanager-main-* pod 的持久性卷声明

      Screenshot of OpenShift Web Console showing persistent volume claim attached to the altermanager pod

  3. 验证新的 prometheus-k8s-* pod 的状态是否为 Running

    1. 点新的 prometheus-k8s-* Pod 查看 pod 详情。
    2. 向下滚动到 Volumes,再验证卷是否具有 Type (ocs-prometheus-claim ),它与您的新持久性卷声明匹配,如 ocs-prometheus-claim-prometheus-k8s-0

      附加到 prometheus-k8s-* pod 的持久性卷声明

      Screenshot of OpenShift Web Console showing persistent volume claim attached to the prometheus pod

5.3. OpenShift Container Storage 的集群日志记录

您可以部署集群日志记录来聚合一系列 OpenShift Container Platform 服务的日志。有关如何部署集群日志记录的详情,请参考部署集群日志记录

在初始 OpenShift Container Platform 部署时,OpenShift Container Storage 不会被默认配置,OpenShift Container Platform 集群将依赖于节点提供的默认存储。您可以编辑 OpenShift 日志记录 (ElasticSearch) 的默认配置,使其由 OpenShift Container Storage 支持,使其具有 OpenShift Container Storage 支持的日志记录(Elasticsearch)。

重要

始终确保您具有适用于这些服务的大量存储容量。如果您对这些关键服务的存储空间不足,日志记录应用将变得不可用,很难恢复。

红帽建议为这些服务配置较短的策展和保留间隔。详情请参阅 OpenShift Container Platform 文档中的 集群日志记录 Curator

如果您缺少这些服务的存储空间,请联系红帽客户支持。

5.3.1. 配置持久性存储

您可以使用存储类名称和大小参数为 Elasticsearch 集群配置持久性存储类和大小。Cluster Logging Operator 根据这些参数为 Elasticsearch 集群中的每个数据节点创建一个持久性卷声明。例如:

spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
        nodeCount: 3
        storage:
          storageClassName: "ocs-storagecluster-ceph-rbd”
          size: "200G"

本例指定,集群中的每个数据节点将绑定到请求 200GiBocs-storagecluster-ceph-rbd 存储的持久性卷声明。每个主分片将由单个副本支持。分片的副本会在所有节点之间复制,并且始终可用;如果因为单一冗余策略至少存在两个节点,则可以恢复副本。如需有关 Elasticsearch 复制策略的信息,请参阅 关于部署和配置集群日志记录 中的 Elasticsearch 复制策略

注意

缺少存储块将导致默认存储支持部署。例如:

spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
        nodeCount: 3
        storage: {}

如需更多信息,请参阅配置集群日志记录

5.3.2. 配置集群日志记录以使用 OpenShift Container Storage

按照本节中的说明,将 OpenShift Container Storage 配置为 OpenShift 集群日志记录的存储。

注意

您可在 OpenShift Container Storage 首次配置日志记录时获取所有日志。但是,在卸载和重新安装日志记录后,会删除旧日志并只处理新日志。

先决条件

  • 具有 OpenShift Web 控制台的管理访问权限。
  • OpenShift Container Storage Operator 已安装并在 openshift-storage 命名空间中运行。
  • Cluster logging Operator 已安装并在 openshift-logging 命名空间中运行。

步骤

  1. 从 OpenShift Web 控制台左侧窗格中,点击 Administration → Custom Resource Definitions
  2. 在 Custom Resource Definitions 页面中点 ClusterLogging
  3. 在 Custom Resource Definition Overview 页面上,从 Actions 菜单中选择 View Instances,或者点击 Instances 选项卡。
  4. 在 Cluster Logging 页面上,点击 Create Cluster Logging

    您可能需要刷新页面来加载数据。

  5. 在 YAML 中,将 storageClassName 替换为使用 provisioner openshift-storage.rbd.csi.ceph.comstorageclass。在下例中,storageclass 的名称为 ocs-storagecluster-ceph-rbd

    apiVersion: "logging.openshift.io/v1"
    kind: "ClusterLogging"
    metadata:
      name: "instance"
      namespace: "openshift-logging"
    spec:
      managementState: "Managed"
      logStore:
        type: "elasticsearch"
        elasticsearch:
          nodeCount: 3
          storage:
            storageClassName: ocs-storagecluster-ceph-rbd
            size: 200G # Change as per your requirement
          redundancyPolicy: "SingleRedundancy"
      visualization:
        type: "kibana"
        kibana:
          replicas: 1
      curation:
        type: "curator"
        curator:
          schedule: "30 3 * * *"
      collection:
        logs:
          type: "fluentd"
          fluentd: {}

    如果 OpenShift Container Storage 节点带有污点,您必须添加容限,以启用为日志调度 daemonset pod。

    spec:
    [...]
      collection:
        logs:
          fluentd:
            tolerations:
            - effect: NoSchedule
              key: node.ocs.openshift.io/storage
              value: 'true'
          type: fluentd
  6. 点击 Save

验证步骤

  1. 验证持久卷声明是否已绑定到 elasticsearch Pod。

    1. 进入 StoragePersistent Volume Claims
    2. Project 下拉菜单设置为 openshift-logging
    3. 验证持久卷声明是否可见,状态为 Bound,附加到 elasticsearch-* pod。

      图 5.1. 创建并绑定集群日志记录

      附加到 elasticsearch pod 的持久性卷声明的截图
  2. 验证是否在使用新集群日志记录。

    1. Workload → Pods
    2. 将项目设置为 openshift-logging
    3. 验证新的 elasticsearch-* Pod 的状态是否为 Running
    4. 点新的 elasticsearch-* Pod 查看 pod 详情。
    5. 向下滚动到 Volumes,再验证 elasticsearch 卷是否具有与新持久性卷声明匹配的 Type,如 elasticsearch-elasticsearch-cdm-9r624biv-3
    6. 点 Persistent Volume Claim 名称,然后在 PersistentVolumeClaim Overview 页面中验证存储类名称。
注意

确保使用较短的 Curator 时间,以避免在附加到 Elasticsearch Pod 的 PV 上 PV 完整场景。

您可以配置 Curator,以根据保留设置删除 Elasticsearch 数据。建议您将以下默认索引数据保留 5 天设为默认值。

config.yaml: |
    openshift-storage:
      delete:
        days: 5

如需了解更多详细信息,请参阅创建 Elasticsearch 数据

注意

要卸载由持久性卷声明支持的集群日志记录,请使用相应部署指南的卸载章节中从 OpenShift Container Storage 中删除集群日志记录 Operator 的步骤。

第 6 章 使用 OpenShift Container Storage 支持 OpenShift Container Platform 应用程序

您无法在 OpenShift Container Platform 安装过程中直接安装 OpenShift Container Storage。但是,您可以使用 Operator Hub 在现有 OpenShift Container Platform 上安装 OpenShift Container Storage,然后将 OpenShift Container Platform 应用程序配置为由 OpenShift Container Storage 支持。

先决条件

  • 已安装 OpenShift Container Platform,您还可管理 OpenShift Web 控制台。
  • OpenShift Container Storage 在 openshift-storage 命名空间内安装并运行。

步骤

  1. 在 OpenShift Web 控制台中执行以下任一操作:

    • Workloads → Deployments

      在 Deployments 页面中,您可以执行以下操作之一:

      • Action 菜单中选择任何现有部署并点击 Add Storage 选项。
      • 创建新部署,然后添加存储。

        1. 单击 Create Deployment 以创建新部署。
        2. 根据您的要求编辑 YAML 以创建部署。
        3. Create
        4. 从页面右上角的 Actions 下拉菜单中选择 Add Storage
    • Workloads → Deployment Configs

      在 Deployment Configs 页面中,您可以执行以下操作之一:

      • Action 菜单中选择任何现有部署并点击 Add Storage 选项。
      • 创建新部署,然后添加存储。

        1. 单击 Create Deployment Config 以创建新部署。
        2. 根据您的要求编辑 YAML 以创建部署。
        3. Create
        4. 从页面右上角的 Actions 下拉菜单中选择 Add Storage
  2. 在 Add Storage 页面中,您可以选择以下选项之一:

    • 点击 Use existing claim 选项,然后从下拉列表中选择一个合适的 PVC。
    • 单击 Create new claim 选项。

      1. Storage Class 下拉列表中,选择适当的 CephFSRBD 存储类。
      2. 为持久性卷声明提供名称。
      3. 选择 ReadWriteOnce (RWO) 或 ReadWriteMany (RWX) 访问模式。

        注意

        ReadOnlyMany (ROX) 已被取消激活,因为它不受支持。

      4. 选择所需存储容量的大小。

        注意

        您可以扩展块 PV,但无法在创建持久性卷声明后减少存储容量。

  3. 指定容器内挂载路径卷的挂载路径和子路径(如果需要)。
  4. 点击 Save

验证步骤

  1. 根据您的配置,执行以下任一操作:

    • Workloads → Deployments
    • Workloads → Deployment Configs
  2. 根据需要设置项目。
  3. 单击您添加存储的部署,以显示部署详情。
  4. 向下滚动到 Volumes,再验证您的部署带有一个与您分配的持久性卷声明相匹配的类型
  5. 点 Persistent Volume Claim 名称,然后在 Persistent Volume Claim Overview 页面中验证存储类名称。

第 7 章 如何将专用 worker 节点用于 Red Hat OpenShift Container Storage

使用基础架构节点调度 Red Hat OpenShift Container Storage 资源可降低 Red Hat OpenShift Container Platform 订阅成本。具有 infra node-role 标签的 Red Hat OpenShift Container Platform (RHOCP) 节点都需要 OpenShift Container Storage 订阅,而不是 RHOCP 订阅。

务必要在不同环境中维持 Machine API 支持的一致性。因此,强烈建议在所有情形中都有特殊类别的节点标记为 worker 或 infra,或者同时具有这两个角色。如需更多信息,请参阅 第 7.3 节 “手动创建基础架构节点” 部分。

7.1. 基础架构节点分析

用于 OpenShift Container Storage 的基础架构节点有几个属性。需要 infra node-role 标签,以确保节点不使用 RHOCP 权利。infra node-role 标签负责确保运行 OpenShift Container Storage 的节点只需要 OpenShift Container Storage 权利。

  • 标记了 node-role.kubernetes.io/infra

还需要添加具有 NoSchedule effect 的 OpenShift Container Storage 污点,以便 infra 节点只调度 OpenShift Container Storage 资源。

  • 使用 node.ocs.openshift.io/storage="true" 污点

该标签将 RHOCP 节点识别为 infra 节点,以便不应用 RHOCP 订阅成本。该污点可防止将非 OpenShift Container Storage 资源调度到污点节点上。

用于运行 OpenShift Container Storage 服务的基础架构节点上的污点和标签示例:

    spec:
      taints:
      - effect: NoSchedule
        key: node.ocs.openshift.io/storage
        value: "true"
      metadata:
        creationTimestamp: null
        labels:
          node-role.kubernetes.io/worker: ""
          node-role.kubernetes.io/infra: ""
          cluster.ocs.openshift.io/openshift-storage: ""

7.2. 用于创建基础架构节点的机器集

如果环境中支持 Machine API,则应将标签添加到要调配基础架构节点的 Machine Sets 的模板中。避免将标签手动添加到机器 API 创建的节点的反模式。这样做类似于向部署创建的 pod 添加标签。在这两种情况下,pod/节点失败时,替代的 pod/节点都将没有适当的标签。

注意

在 EC2 环境中,您将需要三个计算机集,各自配置为在不同的可用区(如 us-east-2a、us-east-2b、us-east-2b、us-east-2c)中调配基础架构节点。目前,OpenShift Container Storage 不支持在超过三个可用区部署。

以下 Machine Set 模板示例创建具有基础架构节点所需的适当污点和标签的节点。这将用于运行 OpenShift Container Storage 服务。

  template:
    metadata:
      creationTimestamp: null
      labels:
        machine.openshift.io/cluster-api-cluster: kb-s25vf
        machine.openshift.io/cluster-api-machine-role: worker
        machine.openshift.io/cluster-api-machine-type: worker
        machine.openshift.io/cluster-api-machineset: kb-s25vf-infra-us-west-2a
    spec:
      taints:
      - effect: NoSchedule
        key: node.ocs.openshift.io/storage
        value: "true"
      metadata:
        creationTimestamp: null
        labels:
          node-role.kubernetes.io/infra: ""
          cluster.ocs.openshift.io/openshift-storage: ""

7.3. 手动创建基础架构节点

只有环境中不支持 Machine API 时,标签才应直接应用到节点。手动创建要求至少可使用 3 个 RHOCP worker 节点来调度 OpenShift Container Storage 服务,并且这些节点有足够的 CPU 和内存资源。要避免 RHOCP 订阅成本,需要以下内容:

oc label node <node> node-role.kubernetes.io/infra=""
oc label node <node> cluster.ocs.openshift.io/openshift-storage=""

还需要添加一个 NoSchedule OpenShift Container Storage 污点,以便 infra 节点只调度 OpenShift Container Storage 资源并代表任何其他非 OpenShift Container Storage 工作负载。

oc adm taint node <node> node.ocs.openshift.io/storage="true":NoSchedule
警告

不要删除 node-role node-role.kubernetes.io/worker=""

除非对 OpenShift 调度程序和 MachineConfig 资源进行了更改,否则删除 node-role.kubernetes.io/worker="" 可能会导致问题。

如果已删除,则应将其重新添加到每个 infra 节点。添加 node-role node-role.kubernetes.io/infra="" 和 OpenShift Container Storage 污点足以满足权利的要求。

第 8 章 扩展存储节点

要扩展 OpenShift Container Storage 的存储容量,您可以执行以下操作之一:

  • 扩展存储节点 - 为现有 OpenShift Container Storage worker 节点添加存储容量
  • 扩展存储节点 - 添加包含存储容量的新 worker 节点

8.1. 扩展存储节点的要求

在继续扩展存储节点前,请参考以下部分以了解特定 Red Hat OpenShift Container Storage 实例的节点要求:

警告

始终确保您有大量的存储容量。

如果存储完全填满,则无法添加容量、删除内容或从存储中迁移内容来释放空间。当存储被完全占用时将很难恢复。

当集群存储容量达到总容量的 75%(接近满)和 85%(满)时,会发出容量警报。始终及时处理容量警告的信息,并定期检查您的存储以确保您不会耗尽存储空间。

如果您完全耗尽存储空间,请联系红帽客户支持。

8.2. 通过在 Red Hat OpenStack Platform 基础架构上为 OpenShift Container Storage 节点添加容量来扩展存储

使用这个流程为配置的 Red Hat OpenShift Container Storage worker 节点添加存储容量和性能。

先决条件

  • 正在运行的 OpenShift 容器平台。
  • OpenShift Web 控制台的管理特权。
  • 要使用部署期间置备的存储类之外的存储类进行扩展,首先定义一个额外的存储类。详情请参阅创建存储类

步骤

  1. 登录 OpenShift Web 控制台。
  2. Operators → Installed Operators
  3. OpenShift Container Storage Operator。
  4. 单击 Storage Cluster 选项卡。
  5. 可见列表中应当只有一个项目。点击最右侧的(⋮)来扩展选项菜单。
  6. 从选项菜单中选择 Add Capacity
  7. 选择 Storage Class

    如果您使用部署期间生成的默认存储类,存储类应设置为 standard。如果您已创建了其他存储类,请选择适当的选项。

    Raw Capacity 字段显示在存储类创建过程中设置的大小。所消耗的存储总量是这个大小的三倍,因为 OpenShift Container Storage 使用的副本数为 3。

  8. Add 并等待集群状态变为 Ready

验证步骤

  • 导航到 OverviewPersistent Storage 选项卡,然后检查 Raw Capacity breakdown 卡。

    请注意,容量会根据您的选择而增加。

    注意

    原始容量不考虑复制并显示完整容量。

  • 验证新 OSD 及其对应的新 PVC 是否已创建。

    • 查看新创建的 OSD 的状态:

      1. 从 OpenShift Web 控制台点 WorkloadsPods
      2. Project 下拉列表中选择 openshift-storage
    • 查看 PVC 的状态:

      1. 从 OpenShift Web 控制台点 StoragePersistent Volume Claims
      2. Project 下拉列表中选择 openshift-storage
  • (可选)如果在集群中启用了集群范围的加密,请验证新 OSD 设备是否已加密。

    1. 识别运行新 OSD pod 的节点。

      $ oc get -o=custom-columns=NODE:.spec.nodeName pod/<OSD pod name>

      例如:

      oc get -o=custom-columns=NODE:.spec.nodeName pod/rook-ceph-osd-0-544db49d7f-qrgqm
    2. 对于上一步中确定的每个节点,请执行以下操作:

      1. 创建调试 pod,并为所选主机打开 chroot 环境。

        $ oc debug node/<node name>
        $ chroot /host
      2. 运行 "lsblk" 并检查 ocs-deviceset 名旁边的 "crypt" 关键字。

        $ lsblk
重要

目前不支持集群缩减,无论是否要通过移除节点或 OSD 来实现缩减。

8.3. 通过添加新节点来横向扩展存储容量

要扩展存储容量,您需要执行以下操作:

  • 添加新节点,以在现有工作程序节点已以其最大支持 OSD 运行时增加存储容量,即初始配置期间所选容量的 3 个 OSD 递增。
  • 验证新节点是否已成功添加
  • 添加节点后扩展存储容量

先决条件

  • 您必须登录 OpenShift Container Platform (RHOCP) 集群。

步骤

  1. 导航到 ComputeMachine Sets
  2. 在您要添加节点的机器集中,选择 Edit Machine Count
  3. 添加节点数量,然后点 Save
  4. ComputeNodes 并确认新节点是否处于 Ready 状态
  5. 将 OpenShift Container Storage 标签应用到新节点。

    1. 对于新节点,Action menu (⋮)Edit Labels
    2. 添加 cluster.ocs.openshift.io/openshift-storage 并点 Save
注意

建议您添加 3 个节点,每个节点都位于不同的区中。您必须添加 3 个节点,并对所有节点执行此步骤。

验证步骤

8.3.1. 验证新节点的添加

  1. 执行以下命令并验证输出中是否存在新节点:

    $ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1
  2. WorkloadsPods,确认新节点上的以下 pod 处于 Running 状态

    • csi-cephfsplugin-*
    • csi-rbdplugin-*

8.3.2. 扩展存储容量

将新节点添加到 OpenShift Container Storage 后,您必须扩展存储容量,如通过添加容量扩展存储中所述。

第 9 章 多云对象网关

9.1. 关于 Multicloud 对象网关

Multicloud 对象网关 (MCG) 是 OpenShift 的轻量级对象存储服务,允许用户启动小规模,然后根据需要在多个集群中、多个集群中和云原生存储中进行扩展。

9.2. 使用应用程序访问多云对象网关

您可以使用任何以 AWS S3 或使用 AWS S3 软件开发套件 (SDK) 的代码为目标的应用程序访问对象服务。应用需要指定 MCG 端点、访问密钥和 secret 访问密钥。您可以使用您的终端或 MCG CLI 来检索此信息。

先决条件

  • 正在运行的 OpenShift Container Storage Platform
  • 下载 MCG 命令行界面以简化管理:

    # subscription-manager repos --enable=rh-ocs-4-for-rhel-8-x86_64-rpms
    # yum install mcg
  • 另外,您可以使用 OpenShift Container Storage RPM(下载 RedHat OpenShift Container Storage)安装 mcg 软件包。

您可以通过两种方式访问相关的端点、访问密钥和 secret 访问密钥:

重要

确保您有一个 DNS 条目,以便使用虚拟主机样式将客户端应用程序指向 MCG 存储桶。

9.2.1. 从终端访问 Multicloud 对象网关

步骤

运行 describe 命令以查看有关 MCG 端点的信息,包括其访问密钥(AWS_ACCESS_KEY_ID 值)和 secret 访问密钥(AWS_SECRET_ACCESS_KEY 值):

# oc describe noobaa -n openshift-storage

输出结果类似如下:

Name:         noobaa
Namespace:    openshift-storage
Labels:       <none>
Annotations:  <none>
API Version:  noobaa.io/v1alpha1
Kind:         NooBaa
Metadata:
  Creation Timestamp:  2019-07-29T16:22:06Z
  Generation:          1
  Resource Version:    6718822
  Self Link:           /apis/noobaa.io/v1alpha1/namespaces/openshift-storage/noobaas/noobaa
  UID:                 019cfb4a-b21d-11e9-9a02-06c8de012f9e
Spec:
Status:
  Accounts:
    Admin:
      Secret Ref:
        Name:           noobaa-admin
        Namespace:      openshift-storage
  Actual Image:         noobaa/noobaa-core:4.0
  Observed Generation:  1
  Phase:                Ready
  Readme:

  Welcome to NooBaa!
  -----------------

  Welcome to NooBaa!
    -----------------
    NooBaa Core Version:
    NooBaa Operator Version:

    Lets get started:

    1. Connect to Management console:

      Read your mgmt console login information (email & password) from secret: "noobaa-admin".

        kubectl get secret noobaa-admin -n openshift-storage -o json | jq '.data|map_values(@base64d)'

      Open the management console service - take External IP/DNS or Node Port or use port forwarding:

        kubectl port-forward -n openshift-storage service/noobaa-mgmt 11443:443 &
        open https://localhost:11443

    2. Test S3 client:

      kubectl port-forward -n openshift-storage service/s3 10443:443 &
1
      NOOBAA_ACCESS_KEY=$(kubectl get secret noobaa-admin -n openshift-storage -o json | jq -r '.data.AWS_ACCESS_KEY_ID|@base64d')
2
      NOOBAA_SECRET_KEY=$(kubectl get secret noobaa-admin -n openshift-storage -o json | jq -r '.data.AWS_SECRET_ACCESS_KEY|@base64d')
      alias s3='AWS_ACCESS_KEY_ID=$NOOBAA_ACCESS_KEY AWS_SECRET_ACCESS_KEY=$NOOBAA_SECRET_KEY aws --endpoint https://localhost:10443 --no-verify-ssl s3'
      s3 ls


    Services:
      Service Mgmt:
        External DNS:
          https://noobaa-mgmt-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com
          https://a3406079515be11eaa3b70683061451e-1194613580.us-east-2.elb.amazonaws.com:443
        Internal DNS:
          https://noobaa-mgmt.openshift-storage.svc:443
        Internal IP:
          https://172.30.235.12:443
        Node Ports:
          https://10.0.142.103:31385
        Pod Ports:
          https://10.131.0.19:8443
      serviceS3:
        External DNS: 3
          https://s3-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com
          https://a340f4e1315be11eaa3b70683061451e-943168195.us-east-2.elb.amazonaws.com:443
        Internal DNS:
          https://s3.openshift-storage.svc:443
        Internal IP:
          https://172.30.86.41:443
        Node Ports:
          https://10.0.142.103:31011
        Pod Ports:
          https://10.131.0.19:6443
1
访问密钥(AWS_ACCESS_KEY_ID 值)
2
Secret access key(AWS_SECRET_ACCESS_KEY 值)
3
MCG 端点
注意

oc describe nooba 命令的输出列出了可用的内部和外部 DNS 名称。使用内部 DNS 时,流量是空闲的。外部 DNS 使用 Load Balancing 来处理流量,因此会有一个每小时的成本。

9.2.2. 使用 MCG 命令行界面访问 Multicloud 对象网关

先决条件

  • 下载 MCG 命令行界面:

    # subscription-manager repos --enable=rh-ocs-4-for-rhel-8-x86_64-rpms
    # yum install mcg

步骤

运行 status 命令访问端点、访问密钥和 secret 访问密钥:

noobaa status -n openshift-storage

输出结果类似如下:

INFO[0000] Namespace: openshift-storage
INFO[0000]
INFO[0000] CRD Status:
INFO[0003] ✅ Exists: CustomResourceDefinition "noobaas.noobaa.io"
INFO[0003] ✅ Exists: CustomResourceDefinition "backingstores.noobaa.io"
INFO[0003] ✅ Exists: CustomResourceDefinition "bucketclasses.noobaa.io"
INFO[0004] ✅ Exists: CustomResourceDefinition "objectbucketclaims.objectbucket.io"
INFO[0004] ✅ Exists: CustomResourceDefinition "objectbuckets.objectbucket.io"
INFO[0004]
INFO[0004] Operator Status:
INFO[0004] ✅ Exists: Namespace "openshift-storage"
INFO[0004] ✅ Exists: ServiceAccount "noobaa"
INFO[0005] ✅ Exists: Role "ocs-operator.v0.0.271-6g45f"
INFO[0005] ✅ Exists: RoleBinding "ocs-operator.v0.0.271-6g45f-noobaa-f9vpj"
INFO[0006] ✅ Exists: ClusterRole "ocs-operator.v0.0.271-fjhgh"
INFO[0006] ✅ Exists: ClusterRoleBinding "ocs-operator.v0.0.271-fjhgh-noobaa-pdxn5"
INFO[0006] ✅ Exists: Deployment "noobaa-operator"
INFO[0006]
INFO[0006] System Status:
INFO[0007] ✅ Exists: NooBaa "noobaa"
INFO[0007] ✅ Exists: StatefulSet "noobaa-core"
INFO[0007] ✅ Exists: Service "noobaa-mgmt"
INFO[0008] ✅ Exists: Service "s3"
INFO[0008] ✅ Exists: Secret "noobaa-server"
INFO[0008] ✅ Exists: Secret "noobaa-operator"
INFO[0008] ✅ Exists: Secret "noobaa-admin"
INFO[0009] ✅ Exists: StorageClass "openshift-storage.noobaa.io"
INFO[0009] ✅ Exists: BucketClass "noobaa-default-bucket-class"
INFO[0009] ✅ (Optional) Exists: BackingStore "noobaa-default-backing-store"
INFO[0010] ✅ (Optional) Exists: CredentialsRequest "noobaa-cloud-creds"
INFO[0010] ✅ (Optional) Exists: PrometheusRule "noobaa-prometheus-rules"
INFO[0010] ✅ (Optional) Exists: ServiceMonitor "noobaa-service-monitor"
INFO[0011] ✅ (Optional) Exists: Route "noobaa-mgmt"
INFO[0011] ✅ (Optional) Exists: Route "s3"
INFO[0011] ✅ Exists: PersistentVolumeClaim "db-noobaa-core-0"
INFO[0011] ✅ System Phase is "Ready"
INFO[0011] ✅ Exists:  "noobaa-admin"

#------------------#
#- Mgmt Addresses -#
#------------------#

ExternalDNS : [https://noobaa-mgmt-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com https://a3406079515be11eaa3b70683061451e-1194613580.us-east-2.elb.amazonaws.com:443]
ExternalIP  : []
NodePorts   : [https://10.0.142.103:31385]
InternalDNS : [https://noobaa-mgmt.openshift-storage.svc:443]
InternalIP  : [https://172.30.235.12:443]
PodPorts    : [https://10.131.0.19:8443]

#--------------------#
#- Mgmt Credentials -#
#--------------------#

email    : admin@noobaa.io
password : HKLbH1rSuVU0I/souIkSiA==

#----------------#
#- S3 Addresses -#
#----------------#

1
ExternalDNS : [https://s3-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com https://a340f4e1315be11eaa3b70683061451e-943168195.us-east-2.elb.amazonaws.com:443]
ExternalIP  : []
NodePorts   : [https://10.0.142.103:31011]
InternalDNS : [https://s3.openshift-storage.svc:443]
InternalIP  : [https://172.30.86.41:443]
PodPorts    : [https://10.131.0.19:6443]

#------------------#
#- S3 Credentials -#
#------------------#

2
AWS_ACCESS_KEY_ID     : jVmAsu9FsvRHYmfjTiHV
3
AWS_SECRET_ACCESS_KEY : E//420VNedJfATvVSmDz6FMtsSAzuBv6z180PT5c

#------------------#
#- Backing Stores -#
#------------------#

NAME                           TYPE     TARGET-BUCKET                                               PHASE   AGE
noobaa-default-backing-store   aws-s3   noobaa-backing-store-15dc896d-7fe0-4bed-9349-5942211b93c9   Ready   141h35m32s

#------------------#
#- Bucket Classes -#
#------------------#

NAME                          PLACEMENT                                                             PHASE   AGE
noobaa-default-bucket-class   {Tiers:[{Placement: BackingStores:[noobaa-default-backing-store]}]}   Ready   141h35m33s

#-----------------#
#- Bucket Claims -#
#-----------------#

No OBC's found.
1
endpoint
2
access key
3
secret access key

现在,您有相关的端点、访问密钥和 secret 访问密钥来连接到您的应用。

例 9.2. 示例

如果 AWS S3 CLI 是应用程序,以下命令会列出 OpenShift Container Storage 中的存储桶:

AWS_ACCESS_KEY_ID=<AWS_ACCESS_KEY_ID>
AWS_SECRET_ACCESS_KEY=<AWS_SECRET_ACCESS_KEY>
aws --endpoint <ENDPOINT> --no-verify-ssl s3 ls

9.3. 允许用户访问多云对象网关控制台

要允许用户访问 Multicloud 对象网关控制台,请确保用户满足以下条件:

  • 用户位于 cluster-admins 组中。
  • 用户位于 system:cluster-admins 虚拟组中.

先决条件

  • 正在运行的 OpenShift 容器平台。

步骤

  1. 启用访问 Multicloud 对象网关控制台。

    在集群中执行以下步骤:

    1. 创建 cluster-admins 组。

      # oc adm groups new cluster-admins
    2. 将组绑定到 cluster-admin 角色。

      # oc adm policy add-cluster-role-to-group cluster-admin cluster-admins
  2. cluster-admins 组添加或删除用户,以控制对多云对象网关控制台的访问。

    • 将一组用户添加到 cluster-admins 组:

      # oc adm groups add-users cluster-admins <user-name> <user-name> <user-name>...

      其中 <user-name> 是要添加的用户的名称。

      注意

      如果要将一组用户添加到 cluster-admins 组,则不需要将新添加的用户绑定到 cluster-admin 角色,以允许访问 OpenShift Container Storage 仪表板。

    • cluster-admins 组中删除一组用户:

      # oc adm groups remove-users cluster-admins <user-name> <user-name> <user-name>...

      其中 <user-name> 是要删除的用户的名称。

验证步骤

  1. 在 OpenShift Web 控制台中,以有权访问多云对象网关控制台的用户身份登录。
  2. 导航到 HomeOverviewObject Service 选项卡 → 选择 Multicloud Object Gateway 链接。
  3. 在 Multicloud 对象网关控制台中,以具有访问权限的同一用户身份登录。
  4. 点击 Allow selected permissions

9.4. 为混合或多云添加存储资源

9.4.1. 创建新的后备存储

使用这个流程在 OpenShift Container Storage 中创建新的后备存储。

先决条件

  • 管理员对 OpenShift 的访问权限.

步骤

  1. 点击 OpenShift Web 控制台左侧窗格中的 Operators Installed Operators 来查看安装的 Operator。
  2. OpenShift Container Storage Operator。
  3. 在 OpenShift Container Storage Operator 页面中,向右滚动并点击 Backing Store 选项卡。
  4. 单击 Create Backing Store

    图 9.1. 创建后端存储页面

    创建新后备存储页面的屏幕截图。
  5. 在 Create New Backing Store 页面中执行以下操作:

    1. 输入后端存储名称
    2. 选择 Provider
    3. 选择 Region
    4. 输入 端点.这是可选的。
    5. 从下拉列表中选择一个 Secret,或创建自己的 secret。另外,您也可以切换到 Credentials 视图来填写所需的 secret。

      有关创建 OCP secret 的更多信息,请参阅 Openshift Container Platform 文档中的创建 secret 部分。

      每个后备存储都需要不同的机密。有关为特定后备存储创建 secret 的更多信息,请参阅 第 9.4.2 节 “使用 MCG 命令行界面为混合或多云添加存储资源” 并按照使用 YAML 添加存储资源的步骤进行操作。

      注意

      此菜单与 Google Cloud 和本地 PVC 以外的所有供应商相关。

    6. 输入 Target bucket。目标 bucket 是托管在远程云服务的容器存储。它允许您创建一个连接,告诉 MCG 它可以将此存储桶用于系统。
  6. 单击 Create Backing Store

验证步骤

  1. OperatorsInstalled Operators
  2. OpenShift Container Storage Operator。
  3. 搜索新的后备存储,或者单击 Backing Store 选项卡来查看所有后备存储。

9.4.2. 使用 MCG 命令行界面为混合或多云添加存储资源

多云对象网关 (MCG) 简化了跨云供应商和集群的数据生成过程。

您必须添加 MCG 可以使用的后备存储。

根据部署类型,您可以选择以下步骤之一来创建后备存储:

对于 VMware 部署,请跳至 第 9.4.3 节 “创建兼容 s3 的多云对象网关后备存储” 以获得进一步说明。

9.4.2.1. 创建 AWS 支持的后备存储

先决条件

步骤

  1. 在 MCG 命令行界面中运行以下命令:

    noobaa backingstore create aws-s3 <backingstore_name> --access-key=<AWS ACCESS KEY> --secret-key=<AWS SECRET ACCESS KEY> --target-bucket <bucket-name> -n openshift-storage
  1. <backingstore_name> 替换为后备存储的名称。
  2. <AWS ACCESS KEY><AWS SECRET ACCESS KEY> 替换为您为此创建的 AWS 访问密钥 ID 和 secret 访问密钥。
  3. <bucket-name> 替换为现有的 AWS 存储桶名称。此参数告知多云对象网关将哪一个存储桶用作其后备存储的目标存储桶,以及数据存储和管理。

    输出结果类似如下:

    INFO[0001] ✅ Exists: NooBaa "noobaa"
    INFO[0002] ✅ Created: BackingStore "aws-resource"
    INFO[0002] ✅ Created: Secret "backing-store-secret-aws-resource"

您还可以使用 YAML 添加存储资源:

  1. 使用凭证创建 secret:

    apiVersion: v1
    kind: Secret
    metadata:
      name: <backingstore-secret-name>
      namespace: openshift-storage
    type: Opaque
    data:
      AWS_ACCESS_KEY_ID: <AWS ACCESS KEY ID ENCODED IN BASE64>
      AWS_SECRET_ACCESS_KEY: <AWS SECRET ACCESS KEY ENCODED IN BASE64>
    1. 您必须使用 Base64 提供并编码您自己的 AWS 访问密钥 ID 和 secret 访问密钥,并使用结果代替 <AWS ACCESS KEY ID ENCODED IN BASE64><AWS SECRET ACCESS KEY ENCODED IN BASE64>
    2. <backingstore-secret-name> 替换为唯一名称。
  2. 为特定的后备存储应用以下 YAML:

    apiVersion: noobaa.io/v1alpha1
    kind: BackingStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: bs
      namespace: openshift-storage
    spec:
      awsS3:
        secret:
          name: <backingstore-secret-name>
          namespace: openshift-storage
        targetBucket: <bucket-name>
      type: aws-s3
    1. <bucket-name> 替换为现有的 AWS 存储桶名称。此参数告知多云对象网关将哪一个存储桶用作其后备存储的目标存储桶,以及数据存储和管理。
    2. <backingstore-secret-name> 替换为上一步中创建的 secret 的名称。

9.4.2.2. 创建 IBM COS 支持的后备存储

先决条件

步骤

  1. 在 MCG 命令行界面中运行以下命令:

    noobaa backingstore create ibm-cos <backingstore_name> --access-key=<IBM ACCESS KEY> --secret-key=<IBM SECRET ACCESS KEY> --endpoint=<IBM COS ENDPOINT> --target-bucket <bucket-name> -n openshift-storage
    1. <backingstore_name> 替换为后备存储的名称。
    2. <IBM ACCESS KEY>、<IBM SECRET ACCESS KEY><IBM COS ENDPOINT> 替换为 IBM 访问密钥 ID、机密访问密钥和对应于现有 IBM 存储桶位置的适当区域端点。

      要在 IBM 云中生成上述密钥,您必须在为您的目标存储桶创建服务凭证时包含 HMAC 凭证。

    3. <bucket-name> 替换为现有的 IBM 存储桶名称。此参数告知多云对象网关将哪一个存储桶用作其后备存储的目标存储桶,以及数据存储和管理。

      输出结果类似如下:

      INFO[0001] ✅ Exists: NooBaa "noobaa"
      INFO[0002] ✅ Created: BackingStore "ibm-resource"
      INFO[0002] ✅ Created: Secret "backing-store-secret-ibm-resource"

您还可以使用 YAML 添加存储资源:

  1. 使用凭证创建 secret:

    apiVersion: v1
    kind: Secret
    metadata:
      name: <backingstore-secret-name>
    type: Opaque
    data:
      IBM_COS_ACCESS_KEY_ID: <IBM COS ACCESS KEY ID ENCODED IN BASE64>
      IBM_COS_SECRET_ACCESS_KEY: <IBM COS SECRET ACCESS KEY ENCODED IN BASE64>
    1. 您必须使用 Base64 提供和编码您自己的 IBM COS 访问密钥 ID 和 secret 访问密钥,并使用结果代替 <IBM COS ACCESS KEY ID ENCODED IN BASE64><IBM COS SECRET ACCESS KEY ENCODED IN BASE64>
    2. <backingstore-secret-name> 替换为唯一名称。
  2. 为特定的后备存储应用以下 YAML:

    apiVersion: noobaa.io/v1alpha1
    kind: BackingStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: bs
      namespace: openshift-storage
    spec:
      ibmCos:
        endpoint: <endpoint>
        secret:
          name: <backingstore-secret-name>
          namespace: openshift-storage
        targetBucket: <bucket-name>
      type: ibm-cos
    1. <bucket-name> 替换为现有的 IBM COS 存储桶名称。此参数告知多云对象网关将哪一个存储桶用作其后备存储的目标存储桶,以及数据存储和管理。
    2. <endpoint> 替换为与现有 IBM 存储桶名称位置对应的区域端点。这个参数告诉 Multicloud Object Gateway 使用哪个端点进行后备存储,然后再将哪一端点用于数据存储和管理。
    3. <backingstore-secret-name> 替换为上一步中创建的 secret 的名称。

9.4.2.3. 创建 Azure 支持的后备存储

先决条件

步骤

  1. 在 MCG 命令行界面中运行以下命令:

    noobaa backingstore create azure-blob <backingstore_name> --account-key=<AZURE ACCOUNT KEY> --account-name=<AZURE ACCOUNT NAME> --target-blob-container <blob container name>
    1. <backingstore_name> 替换为后备存储的名称。
    2. <AZURE ACCOUNT KEY><AZURE ACCOUNT NAME> 替换为您为此创建的 AZURE 帐户密钥和帐户名称。
    3. <blob container name> 替换为现有的 Azure blob 容器名称。此参数告知多云对象网关将哪一个存储桶用作其后备存储的目标存储桶,以及数据存储和管理。

      输出结果类似如下:

      INFO[0001] ✅ Exists: NooBaa "noobaa"
      INFO[0002] ✅ Created: BackingStore "azure-resource"
      INFO[0002] ✅ Created: Secret "backing-store-secret-azure-resource"

您还可以使用 YAML 添加存储资源:

  1. 使用凭证创建 secret:

    apiVersion: v1
    kind: Secret
    metadata:
      name: <backingstore-secret-name>
    type: Opaque
    data:
      AccountName: <AZURE ACCOUNT NAME ENCODED IN BASE64>
      AccountKey: <AZURE ACCOUNT KEY ENCODED IN BASE64>
    1. 您必须使用 Base64 提供和编码您自己的 Azure 帐户名称和帐户密钥,并使用结果代替 <AZURE ACCOUNT NAME ENCODED IN BASE64><AZURE ACCOUNT KEY ENCODED IN BASE64>
    2. <backingstore-secret-name> 替换为唯一名称。
  2. 为特定的后备存储应用以下 YAML:

    apiVersion: noobaa.io/v1alpha1
    kind: BackingStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: bs
      namespace: openshift-storage
    spec:
      azureBlob:
        secret:
          name: <backingstore-secret-name>
          namespace: openshift-storage
        targetBlobContainer: <blob-container-name>
      type: azure-blob
    1. <blob-container-name> 替换为现有的 Azure blob 容器名称。此参数告知多云对象网关将哪一个存储桶用作其后备存储的目标存储桶,以及数据存储和管理。
    2. <backingstore-secret-name> 替换为上一步中创建的 secret 的名称。

9.4.2.4. 创建由 GCP 支持的后备存储

先决条件

步骤

  1. 在 MCG 命令行界面中运行以下命令:

    noobaa backingstore create google-cloud-storage <backingstore_name> --private-key-json-file=<PATH TO GCP PRIVATE KEY JSON FILE> --target-bucket <GCP bucket name>
    1. <backingstore_name> 替换为后备存储的名称。
    2. <PATH TO GCP PRIVATE KEY JSON FILE> 替换为为此创建的 GCP 私钥的路径。
    3. <GCP bucket name> 替换为现有的 GCP 对象存储桶名称。此参数告知多云对象网关将哪一个存储桶用作其后备存储的目标存储桶,以及数据存储和管理。

      输出结果类似如下:

      INFO[0001] ✅ Exists: NooBaa "noobaa"
      INFO[0002] ✅ Created: BackingStore "google-gcp"
      INFO[0002] ✅ Created: Secret "backing-store-google-cloud-storage-gcp"

您还可以使用 YAML 添加存储资源:

  1. 使用凭证创建 secret:

    apiVersion: v1
    kind: Secret
    metadata:
      name: <backingstore-secret-name>
    type: Opaque
    data:
      GoogleServiceAccountPrivateKeyJson: <GCP PRIVATE KEY ENCODED IN BASE64>
    1. 您必须使用 Base64 提供并编码您自己的 GCP 服务帐户私钥,并使用结果代替 <GCP PRIVATE KEY ENCODED IN BASE64>
    2. 将 <backingstore-secret-name> 替换为唯一名称。
  2. 为特定的后备存储应用以下 YAML:

    apiVersion: noobaa.io/v1alpha1
    kind: BackingStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: bs
      namespace: openshift-storage
    spec:
      googleCloudStorage:
        secret:
          name: <backingstore-secret-name>
          namespace: openshift-storage
        targetBucket: <target bucket>
      type: google-cloud-storage
    1. <target bucket> 替换为现有的 Google 存储桶。此参数告知多云对象网关将哪一个存储桶用作其后备存储的目标存储桶,以及数据存储和管理。
    2. <backingstore-secret-name> 替换为上一步中创建的 secret 的名称。

9.4.2.5. 创建由本地持久性卷支持的后备存储

先决条件

步骤

  1. 在 MCG 命令行界面中运行以下命令:

    noobaa backingstore create  pv-pool <backingstore_name> --num-volumes=<NUMBER OF VOLUMES>  --pv-size-gb=<VOLUME SIZE> --storage-class=<LOCAL STORAGE CLASS>
    1. <backingstore_name> 替换为后备存储的名称。
    2. <NUMBER OF VOLUMES> 替换为您要创建的卷数。请注意,增加卷数量可向上扩展存储。
    3. <VOLUME SIZE> 替换为每个卷所需的大小(以 GB 为单位)
    4. <LOCAL STORAGE CLASS> 替换为本地存储类,建议使用 ocs-storagecluster-ceph-rbd

      输出结果类似如下:

      INFO[0001] ✅ Exists: NooBaa "noobaa"
      INFO[0002] ✅ Exists: BackingStore "local-mcg-storage"

您还可以使用 YAML 添加存储资源:

  1. 为特定的后备存储应用以下 YAML:

    apiVersion: noobaa.io/v1alpha1
    kind: BackingStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: <backingstore_name>
      namespace: openshift-storage
    spec:
       pvPool:
        numVolumes: <NUMBER OF VOLUMES>
        resources:
          requests:
            storage: <VOLUME SIZE>
        storageClass: <LOCAL STORAGE CLASS>
      type: pv-pool
    1. <backingstore_name> 替换为后备存储的名称。
    2. <NUMBER OF VOLUMES> 替换为您要创建的卷数。请注意,增加卷数量可向上扩展存储。
    3. <VOLUME SIZE> 替换为每个卷所需的大小(以 GB 为单位)。请注意,字母 G 应该保留。
    4. <LOCAL STORAGE CLASS> 替换为本地存储类,建议使用 ocs-storagecluster-ceph-rbd

9.4.3. 创建兼容 s3 的多云对象网关后备存储

多云对象网关可以使用任何 S3 兼容对象存储作为后备存储,例如,Red Hat Ceph Storage’s RADOS Gateway (RGW)。下列步骤演示了如何为 Red Hat Ceph Storage 的 RADOS Gateway 创建 S3 兼容多云对象网关后端存储。请注意,当部署 RGW 时,Openshift Container Storage operator 会自动为多云对象网关创建一个 S3 兼容后备存储。

步骤

  1. 在 Multicloud Object Gateway (MCG) 命令行界面中,运行以下命令:

    noobaa backingstore create s3-compatible rgw-resource --access-key=<RGW ACCESS KEY> --secret-key=<RGW SECRET KEY> --target-bucket=<bucket-name> --endpoint=<RGW endpoint>
    1. 要获取 <RGW ACCESS KEY><RGW SECRET KEY>,请使用您的 RGW 用户 secret 名称运行以下命令:

      oc get secret <RGW USER SECRET NAME> -o yaml -n openshift-storage
    2. 解码 Base64 中的访问密钥 ID 和访问密钥,并保留它们。
    3. <RGW USER ACCESS KEY><RGW USER SECRET ACCESS KEY> 替换为上一步中的相应已解码数据。
    4. <bucket-name> 替换为现有的 RGW 存储桶名称。此参数告知多云对象网关将哪一个存储桶用作其后备存储的目标存储桶,以及数据存储和管理。
    5. 要获取 <RGW endpoint>,请参阅访问 RADOS 对象网关 S3 端点

      输出结果类似如下:

      INFO[0001] ✅ Exists: NooBaa "noobaa"
      INFO[0002] ✅ Created: BackingStore "rgw-resource"
      INFO[0002] ✅ Created: Secret "backing-store-secret-rgw-resource"

您还可以使用 YAML 创建后备存储:

  1. 创建 CephObjectStore 用户。这还会创建一个包含 RGW 凭证的 secret:

    apiVersion: ceph.rook.io/v1
    kind: CephObjectStoreUser
    metadata:
      name: <RGW-Username>
      namespace: openshift-storage
    spec:
      store: ocs-storagecluster-cephobjectstore
      displayName: "<Display-name>"
    1. <RGW-Username><Display-name> 替换为唯一的用户名和显示名称。
  2. 为 S3-Compatible 后备存储应用以下 YAML:

    apiVersion: noobaa.io/v1alpha1
    kind: BackingStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: <backingstore-name>
      namespace: openshift-storage
    spec:
      s3Compatible:
        endpoint: <RGW endpoint>
        secret:
          name: <backingstore-secret-name>
          namespace: openshift-storage
        signatureVersion: v4
        targetBucket: <RGW-bucket-name>
      type: s3-compatible
    1. <backingstore-secret-name> 替换为上一步中使用 CephObjectStore 创建的 secret 的名称。
    2. <bucket-name> 替换为现有的 RGW 存储桶名称。此参数告知多云对象网关将哪一个存储桶用作其后备存储的目标存储桶,以及数据存储和管理。
    3. 要获取 <RGW endpoint>,请参阅访问 RADOS 对象网关 S3 端点

9.4.4. 使用用户界面为混合和多云添加存储资源

步骤

  1. 在 OpenShift Storage 控制台中,点击 OverviewObject ServiceMulticloud Object Gateway 链接。
  2. 选择左侧的资源选项卡,突出显示下方。从填充的列表中,选择 Add Cloud Resource

    MCG 添加云资源
  3. 选择 Add new connection

    MCG 添加新连接
  4. 选择相关的原生云供应商或 S3 兼容选项并填写详情。

    MCG 添加云连接
  5. 选择新创建的连接并将其映射到现有存储桶。

    MCG 映射到现有存储桶
  6. 重复这些步骤,根据需要创建任意数量的后备存储。
注意

在 NooBaa UI 中创建的资源不能由 OpenShift UI 或 MCG CLI 使用。

9.4.5. 创建新存储桶类

bucket 类是一个 CRD,代表一种存储桶类别,用于定义对象 Bucket 类 (OBC) 的分层策略和数据放置。

使用这个流程在 OpenShift Container Storage 中创建存储桶类。

步骤

  1. 点击 OpenShift Web 控制台左侧窗格中的 Operators Installed Operators 来查看安装的 Operator。
  2. OpenShift Container Storage Operator。
  3. 在 OpenShift Container Storage Operator 页面中,向右滚动并点击 Bucket Class 选项卡。
  4. Create Bucket Class
  5. 在 Create new Bucket Class 页面中,执行以下操作:

    1. 输入 Bucket Class Name 并点 Next
    2. 在放置策略中,选择 Tier 1 - Policy Type 并单击 Next。您可以根据要求选择任一选项。

      • Spread 允许在选定资源之间分散数据。
      • Mirror 允许在选定资源中完全重复数据。
      • 单击 Add Tier 以添加另一个策略层。
    3. 如果您选择了 Tier 1 - Policy Type 作为 Spread,则至少从可用列表中选择 Backing Store 资源,然后单击 Next。或者,您也可以创建新的后备存储

      注意

      当在上一步中将 Policy Type 选择为 Mirror 时,您需要选择 atleast 2 后备存储。

    4. 检查并确认 Bucket 类设置。
    5. Create Bucket Class

验证步骤

  1. OperatorsInstalled Operators
  2. OpenShift Container Storage Operator。
  3. 搜索新的 Bucket Class 或点击 Bucket Class 选项卡来查看所有 Bucket 类。

9.4.6. 编辑存储桶类

使用以下步骤,通过 YAML 文件编辑存储桶类组件,方法是点击 Openshift Web 控制台上的 edit 按钮。

先决条件

  • 管理员对 OpenShift 的访问权限.

步骤

  1. 登录 OpenShift Web 控制台
  2. OperatorsInstalled Operators
  3. OpenShift Container Storage Operator
  4. 在 OpenShift Container Storage Operator 页面中,向右滚动并点击 Bucket Class 选项卡。
  5. 点击您要编辑的 Bucket 类旁边的操作菜单(⋮)。
  6. Edit Bucket Class
  7. 您将被重定向到 YAML 文件,在此文件中进行必要的更改并点 Save

9.4.7. 为存储桶类编辑后备存储

使用以下步骤编辑现有的 Multicloud Object Gateway bucket 类,以更改存储桶类中使用的底层后备存储。

先决条件

  • 管理员对 OpenShift Web 控制台的访问权限。
  • 存储桶类。
  • 后备存储。

步骤

  1. Operators → Installed Operators 查看已安装的 Operator。
  2. OpenShift Container Storage Operator
  3. 单击 Bucket Class 选项卡。
  4. 点击您要编辑的 Bucket 类旁边的操作菜单(⋮)。

    编辑存储桶类资源
  5. Edit Bucket Class Resources
  6. Edit Bucket Class Resources 页面中,通过添加后备存储到存储桶类或从存储桶类中删除后备存储来编辑存储桶类资源。您还可以编辑使用一或两个分层和不同的放置策略创建的 bucket 类资源。

    • 要将后备存储添加到 bucket 类,请选择后备存储的名称。
    • 要从存储桶类中删除后备存储,请清除后备存储的名称。

      为存储桶类编辑后备存储
  7. 点击 Save

9.5. 管理命名空间存储桶

命名空间存储桶可让您将不同提供程序上的数据存储库连接在一起,以便您可以通过统一视图与所有数据交互。将与各个提供程序关联的对象存储桶添加到命名空间存储桶,并通过命名空间存储桶访问您的数据,以一次性查看所有对象存储桶。这可让您在读取多个其他存储提供商的同时写入您首选的存储供应商,从而显著降低迁移至新存储提供商的成本。

  1. 将供应商连接到 Multicloud 对象网关
  2. 为每个供应商创建一个命名空间资源,以便可以将它们添加到命名空间存储桶中。
  3. 将命名空间资源添加到命名空间存储桶,并将存储桶配置为读取和写入适当的命名空间资源。

您可以使用 S3 API 与命名空间存储桶中的对象交互。如需更多信息,请参阅命名空间存储桶中对象的 S3 API 端点

注意

只有其写入目标可用且可正常运行时,才能使用命名空间存储桶。

9.5.1. 在 Multicloud 对象网关中添加供应商连接

您需要为每个供应商添加连接,以便 Multicloud 对象网关可以访问该供应商。

先决条件

  • OpenShift 控制台的管理访问权限.

步骤

  1. 在 OpenShift 控制台中,点击 HomeOverview,然后点击 Object Service 选项卡。
  2. Multicloud Object Gateway 并在系统提示时登录。
  3. Accounts 并选择要添加连接的帐户。
  4. 单击 My Connections
  5. 单击 Add Connection

    1. 输入 连接名称
    2. 默认情况下,您的云提供程序会在 服务 下拉菜单中显示。更改选择以使用其他提供程序。
    3. 默认情况下,您的云供应商的默认端点会在 Endpoint 字段中显示。如果需要,输入替代端点。
    4. 输入您的云供应商访问密钥
    5. 输入此云供应商的 Secret 密钥
    6. 点击 Save

9.5.2. 使用 Multicloud 对象网关添加命名空间资源

将现有存储添加到多云存储网关作为命名空间资源,以便它们可以包含在命名空间存储桶中,以便获得现有存储目标的统一视图,如 Amazon Web Services S3 存储桶、Microsoft Azure blob 和 IBM Cloud Object Storage bucket。

先决条件

步骤

  1. 在 OpenShift 控制台中,点 HomeOverview 并点 Object Service 选项卡。
  2. 点击 Multicloud Storage Gateway,并在出现提示时登录。
  3. 点击 Resources,然后点击 Namespace Resources 选项卡。
  4. Create Namespace Resource

    1. Target Connection 中,选择要用于此命名空间的存储供应商的连接。

      如果需要添加新连接,请点击 Add New Connection 并输入您的供应商详情。如需更多信息,请参阅 第 9.5.1 节 “在 Multicloud 对象网关中添加供应商连接”

    2. Target Bucket 中,选择要用作目标的存储桶的名称。
    3. 输入命名空间资源的 Resource Name
    4. Create

验证

  • 验证新资源是否在 State 列中带有绿色勾号,在 Connected Namespace Buckets 列中为 0 存储桶。

9.5.3. 使用 Multicloud 对象网关将资源添加到命名空间存储桶

将命名空间资源添加到命名空间存储桶,以统一查看不同供应商的存储。您还可以配置读取和写入机制,以便只有一家提供商接受新数据,而所有供应商都允许读取现有数据。

先决条件

步骤

  1. 在 OpenShift 控制台中,点击 HomeOverview,然后点击 Object Service 选项卡。
  2. Multicloud Object Gateway 并在系统提示时登录。
  3. 点击 Buckets,然后点击 Namespace Buckets 选项卡。
  4. Create Namespace Bucket

    1. Choose Name 选项卡中,指定命名空间存储桶的名称,再单击 Next
    2. Set Placement 标签页中:

      1. Read Policy 下,选中命名空间存储桶应该从中读取数据的每个命名空间资源的复选框。
      2. Write Policy 下,指定命名空间存储桶应将数据写入的命名空间资源。
      3. 点击 Next
    3. 对于生产环境,不要对 Set Caching Policy 选项卡进行更改。此选项卡作为开发预览提供,对其支持有相关的限制。
    4. Create

验证

  • 验证命名空间存储桶是否在 State 列中带有绿色勾号、预期的读取资源和预期的写入资源名称。

9.5.4. 命名空间存储桶中对象的 Amazon S3 API 端点

您可以使用 Amazon Simple Storage Service (S3) API 与命名空间存储桶中的对象交互。

Red Hat OpenShift Container Storage 4.6 支持以下命名空间存储桶操作:

有关这些操作及其使用方法的最新信息,请参阅 Amazon S3 API 参考文档。

9.5.5. 使用 Multicloud 对象网关 CLI 和 YAML 添加命名空间存储桶

如需有关命名空间存储桶的更多信息,请参阅管理命名空间存储桶

根据部署的类型以及是否使用 YAML 或 Multicloud 对象网关 CLI,选择以下流程之一来添加命名空间存储桶:

9.5.5.1. 使用 YAML 添加 AWS S3 命名空间存储桶

先决条件

步骤

  1. 使用凭证创建 secret:

    apiVersion: v1
    kind: Secret
    metadata:
    name: <namespacestore-secret-name>
    type: Opaque
    data:
    AWS_ACCESS_KEY_ID: <AWS ACCESS KEY ID ENCODED IN BASE64>
    AWS_SECRET_ACCESS_KEY: <AWS SECRET ACCESS KEY ENCODED IN BASE64>
    1. 您必须使用 Base64 提供并编码您自己的 AWS 访问密钥 ID 和 secret 访问密钥,并使用结果代替 <AWS ACCESS KEY ID ENCODED IN BASE64><AWS SECRET ACCESS KEY ENCODED IN BASE64>。ii.使用一个唯一的名称替换 <namespacestore-secret-name>
  2. 使用 OpenShift 自定义资源定义 (CRD) 创建 NamespaceStore 资源。NamespaceStore 代表底层存储,用作 Multicloud Object Gateway 命名空间存储桶中数据的读取或写入目标。要创建 NamespaceStore 资源,请应用以下 YAML:

    apiVersion: noobaa.io/v1alpha1
    kind: NamespaceStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: mybucketnamespace
      namespace: k8snamespace
    spec:
      awsS3:
        secret:
          name: <namespacestore-secret-name>
          namespace: k8snamespace
        targetBucket: awsdatalake
      type: aws-s3
    1. <namespacestore-secret-name> 替换为在第 1 步中创建的 secret。
  3. 创建一个命名空间存储桶类,为命名空间存储桶定义命名空间策略。命名空间策略的类型需要是 singlemulti

    • 一个类型为 single 的命名空间策略需要以下配置:

      apiVersion: noobaa.io/v1alpha1
      kind: BucketClass
      metadata:
        labels:
          app: noobaa
        name: <my-bucket-class>
        namespace: openshift-storage
      spec:
        namespacePolicy:
          type:
          single:
            resource: <resource>

      <my-bucket-class> 替换为唯一的命名空间存储桶类名称。

      <resource> 替换为一个 namespace-store,它将定义命名空间存储桶的读写目标。

    • 一个类型为 multi 的命名空间策略需要以下配置:

      apiVersion: noobaa.io/v1alpha1
      kind: BucketClass
      metadata:
        labels:
          app: noobaa
        name: <my-bucket-class>
        namespace: openshift-storage
      spec:
        namespacePolicy:
          type: Multi
          multi:
            writeResource: <write-resource>
            readResources:
            - <read-resources>
            - <read-resources>

      <my-bucket-class> 替换为唯一的存储桶类名称。

      使用将定义命名空间存储桶写入目标的单一 namespace-store 替换 write-resource

      <read-resources 替换为定义命名空间存储桶读取目标的命名空间存储列表。

  4. 应用以下 YAML,以使用对象 Bucket Class (OBC) 资源创建 bucket,该资源使用第 2 步中定义的 bucket 类。

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: my-bucket-claim
      namespace: my-app
    spec:
      generateBucketName: my-bucket
      storageClassName: noobaa.noobaa.io
      additionalConfig:
        bucketclass: <my-bucket-class>
    1. <my-bucket-class> 替换为上一步中创建的存储桶类。

在 Operator 置备 OBC 后,会在 Multicloud 对象网关中创建存储桶,Operator 会在 OBC 的同一命名空间中创建一个名称与 OBC 相同的 Secret 和 ConfigMap。

9.5.5.2. 使用 YAML 添加 IBM COS 命名空间存储桶

先决条件

步骤

  1. 使用凭证创建 secret:

    apiVersion: v1
    kind: Secret
    metadata:
    name: <namespacestore-secret-name>
    type: Opaque
    data:
    IBM_COS_ACCESS_KEY_ID: <IBM COS ACCESS KEY ID ENCODED IN BASE64>
    IBM_COS_SECRET_ACCESS_KEY: <IBM COS SECRET ACCESS KEY ENCODED IN BASE64>
    1. 您必须使用 Base64 提供和编码您自己的 IBM COS 访问密钥 ID 和 secret 访问密钥,并使用结果代替 <IBM COS ACCESS KEY ID ENCODED IN BASE64> 和 `<IBM COS SECRET ACCESS KEY ENCODED IN BASE64>。
    2. 使用一个唯一的名称替换 <namespacestore-secret-name>
  2. 使用 OpenShift 自定义资源定义 (CRD) 创建 NamespaceStore 资源。NamespaceStore 代表底层存储,用作 Multicloud Object Gateway 命名空间存储桶中数据的读取或写入目标。要创建 NamespaceStore 资源,请应用以下 YAML:

    apiVersion: noobaa.io/v1alpha1
    kind: NamespaceStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: bs
      namespace: k8snamespace
    spec:
      s3Compatible:
        endpoint: <IBM COS ENDPOINT>
        secret:
          name: <namespacestore-secret-name>
          namespace: openshift-storage
        signatureVersion: v2
        targetBucket: BUCKET
      type: ibm-cos
    1. <IBM COS ENDPOINT> 替换为适当的 IBM COS 端点。
    2. <namespacestore-secret-name> 替换为在第 1 步中创建的 secret。
  3. 创建一个命名空间存储桶类,为命名空间存储桶定义命名空间策略。命名空间策略的类型需要是 singlemulti

    • 一个类型为 single 的命名空间策略需要以下配置:

      apiVersion: noobaa.io/v1alpha1
      kind: BucketClass
      metadata:
        labels:
          app: noobaa
        name: <my-bucket-class>
        namespace: openshift-storage
      spec:
        namespacePolicy:
          type:
          single:
            resource: <resource>

      <my-bucket-class> 替换为唯一的命名空间存储桶类名称。

      <resource> 替换为一个 namespace-store,它将定义命名空间存储桶的读写目标。

    • 一个类型为 multi 的命名空间策略需要以下配置:

      apiVersion: noobaa.io/v1alpha1
      kind: BucketClass
      metadata:
        labels:
          app: noobaa
        name: <my-bucket-class>
        namespace: openshift-storage
      spec:
        namespacePolicy:
          type: Multi
          multi:
            writeResource: <write-resource>
            readResources:
            - <read-resources>
            - <read-resources>

      <my-bucket-class> 替换为唯一的存储桶类名称。

      使用将定义命名空间存储桶写入目标的单一 namespace-store 替换 write-resource

      <read-resources 替换为定义命名空间存储桶读取目标的命名空间存储列表。

  4. 应用以下 YAML,以使用对象 Bucket Class (OBC) 资源创建 bucket,该资源使用第 2 步中定义的 bucket 类。

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: my-bucket-claim
      namespace: my-app
    spec:
      generateBucketName: my-bucket
      storageClassName: noobaa.noobaa.io
      additionalConfig:
        bucketclass: <my-bucket-class>
    1. <my-bucket-class> 替换为上一步中创建的存储桶类。

在 Operator 置备 OBC 后,会在 Multicloud 对象网关中创建存储桶,Operator 会在 OBC 的同一命名空间中创建一个名称与 OBC 相同的 Secret 和 ConfigMap。

9.5.5.3. 使用 Multicloud 对象网关 CLI 添加 AWS S3 命名空间存储桶

先决条件

步骤

  1. 创建 NamespaceStore 资源。NamespaceStore 代表一个底层存储,用作 Multicloud Object Gateway 命名空间存储桶中数据的读取或写入目标。在 MCG 命令行界面中运行以下命令:

    noobaa namespacestore create aws-s3 <namespacestore> --access-key <AWS ACCESS KEY> --secret-key <AWS SECRET ACCESS KEY> --target-bucket <bucket-name> -n openshift-storage
    1. <namespacestore> 替换为 NamespaceStore 的名称。
    2. <AWS ACCESS KEY><AWS SECRET ACCESS KEY> 替换为您为此创建的 AWS 访问密钥 ID 和 secret 访问密钥。
    3. <bucket-name> 替换为现有的 AWS 存储桶名称。此参数告知多云对象网关将哪一个存储桶用作其后备存储的目标存储桶,以及数据存储和管理。
  2. 创建一个命名空间存储桶类,为命名空间存储桶定义命名空间策略。命名空间策略的类型需要是 singlemulti

    • 运行以下命令,创建一个命名空间存储桶类,其命名空间策略类型为 single

      noobaa bucketclass create namespace-bucketclass single <my-bucket-class> --resource <resource> -n openshift-storage

      <my-bucket-class> 替换为唯一的存储桶类名称。

      <resource> 替换为一个 namespace-store,它将定义命名空间存储桶的读写目标。

    • 运行以下命令,创建一个命名空间存储桶类,其命名空间策略为 multi

      noobaa bucketclass create namespace-bucketclass multi <my-bucket-class> --write-resource <write-resource> --read-resources <read-resources> -n openshift-storage

      <my-bucket-class> 替换为唯一的存储桶类名称。

      使用将定义命名空间存储桶写入目标的单一 namespace-store 替换 write-resource

      <read-resources 替换为一个以逗号分隔的命名空间存储列表,这些存储将定义命名空间存储桶的读取目标。

  3. 运行以下命令,以使用对象 Bucket Class (OBC) 资源创建 bucket,该资源使用第 2 步中定义的 bucket 类。

    noobaa obc create my-bucket-claim -n openshift-storage --app-namespace my-app --bucketclass <custom-bucket-class>
    1. <custom-bucket-class> 替换为在第 2 步中创建的 bucket 类的名称。

在 Operator 置备 OBC 后,会在 Multicloud 对象网关中创建存储桶,Operator 会在 OBC 的同一命名空间中创建一个名称与 OBC 相同的 Secret 和 ConfigMap。

9.5.5.4. 使用 Multicloud 对象网关 CLI 添加 IBM COS 命名空间存储桶

先决条件

步骤

  1. 创建 NamespaceStore 资源。NamespaceStore 代表一个底层存储,用作 Multicloud Object Gateway 命名空间存储桶中数据的读取或写入目标。在 MCG 命令行界面中运行以下命令:

    noobaa namespacestore create ibm-cos <namespacestore> --endpoint <IBM COS ENDPOINT> --access-key <IBM ACCESS KEY> --secret-key <IBM SECRET ACCESS KEY> --target-bucket <bucket-name> -n openshift-storage
    1. <namespacestore> 替换为 NamespaceStore 的名称。
    2. <IBM ACCESS KEY>、<IBM SECRET ACCESS KEY><IBM COS ENDPOINT> 替换为 IBM 访问密钥 ID、机密访问密钥和对应于现有 IBM 存储桶位置的适当区域端点。
    3. <bucket-name> 替换为现有的 IBM 存储桶名称。此参数告知多云对象网关将哪一个存储桶用作其后备存储的目标存储桶,以及数据存储和管理。
  2. 创建一个命名空间存储桶类,为命名空间存储桶定义命名空间策略。命名空间策略的类型需要是 singlemulti

    • 运行以下命令,创建一个命名空间存储桶类,其命名空间策略类型为 single

      noobaa bucketclass create namespace-bucketclass single <my-bucket-class> --resource <resource> -n openshift-storage

      <my-bucket-class> 替换为唯一的存储桶类名称。

      <resource> 替换为一个 namespace-store,它将定义命名空间存储桶的读写目标。

    • 运行以下命令,创建一个命名空间存储桶类,其命名空间策略为 multi

      noobaa bucketclass create namespace-bucketclass multi <my-bucket-class> --write-resource <write-resource> --read-resources <read-resources> -n openshift-storage

      <my-bucket-class> 替换为唯一的存储桶类名称。

      使用将定义命名空间存储桶写入目标的单一 namespace-store 替换 write-resource

      <read-resources 替换为一个以逗号分隔的命名空间存储列表,这些存储将定义命名空间存储桶的读取目标。

  3. 运行以下命令,以使用对象 Bucket Class (OBC) 资源创建 bucket,该资源使用第 2 步中定义的 bucket 类。

    noobaa obc create my-bucket-claim -n openshift-storage --app-namespace my-app --bucketclass <custom-bucket-class>
    1. <custom-bucket-class> 替换为在第 2 步中创建的 bucket 类的名称。

在 Operator 置备 OBC 后,会在 Multicloud 对象网关中创建存储桶,Operator 会在 OBC 的同一命名空间中创建一个名称与 OBC 相同的 Secret 和 ConfigMap。

9.6. 混合和多云存储桶的镜像数据

多云对象网关 (MCG) 简化了跨云供应商和集群的数据生成过程。

先决条件

然后,您创建一个 bucket 类来反映数据管理策略镜像。

步骤

您可以通过三种方式设置镜像数据:

9.6.1. 使用 MCG 命令行创建存储桶类来镜像数据

  1. 在 MCG 命令行界面中,运行以下命令来创建带有镜像策略的存储桶类:

    $ noobaa bucketclass create placement-bucketclass mirror-to-aws --backingstores=azure-resource,aws-resource --placement Mirror
  2. 将新创建的存储桶类设置为一个新的存储桶声明,生成一个新的存储桶,该存储桶将在两个位置之间进行镜像:

    $ noobaa obc create  mirrored-bucket --bucketclass=mirror-to-aws

9.6.2. 使用 YAML 创建存储桶类来镜像数据

  1. 应用以下 YAML。

    apiVersion: noobaa.io/v1alpha1
    kind: BucketClass
    metadata:
      labels:
        app: noobaa
      name: <bucket-class-name>
      namespace: openshift-storage
    spec:
      placementPolicy:
        tiers:
        - backingStores:
          - <backing-store-1>
          - <backing-store-2>
          placement: Mirror
  2. 将以下行添加到标准 Object Bucket Claim (OBC) 中:

    additionalConfig:
      bucketclass: mirror-to-aws

    有关 OBCs 的更多信息,请参阅 第 9.8 节 “对象 Bucket 声明”

9.6.3. 使用用户界面将存储桶配置为镜像数据

  1. 在 OpenShift Storage 控制台中,点击 OverviewObject ServiceMulticloud Object Gateway 链接。
  2. 在 NooBaa 页面中,单击左侧的存储 buckets 图标。您将看到存储桶列表:

    MCG nooba bucket 图标
  3. 点击您要更新的存储桶。
  4. 点击 Edit Tier 1 Resources:

    MCG 编辑第 1 层资源
  5. 选择 Mirror 并检查您要用于这个存储桶的相关资源。在以下示例中,在 RGW 和 AWS-backingstore 中被镜像的 noobaa-default-backing-store 间的数据会被镜像:

    MCG 镜像相关资源
  6. 点击 Save
注意

在 NooBaa UI 中创建的资源不能由 OpenShift UI 或 MCG CLI 使用。

9.7. Multicloud 对象网关中的存储桶策略

OpenShift Container Storage 支持 AWS S3 存储桶策略。bucket 策略允许您为用户授予存储桶及其对象的访问权限。

9.7.1. 关于存储桶策略

bucket 策略是一个访问策略选项,可供您向 AWS S3 存储桶和对象授予权限。bucket 策略使用基于 JSON 的访问策略语言。有关访问策略语言的更多信息,请参阅AWS 访问策略语言概述

9.7.2. 使用存储桶策略

先决条件

步骤

在 Multicloud 对象网关中使用存储桶策略:

  1. 以 JSON 格式创建 bucket 策略。请参见以下示例:

    {
        "Version": "NewVersion",
        "Statement": [
            {
                "Sid": "Example",
                "Effect": "Allow",
                "Principal": [
                        "john.doe@example.com"
                ],
                "Action": [
                    "s3:GetObject"
                ],
                "Resource": [
                    "arn:aws:s3:::john_bucket"
                ]
            }
        ]
    }

    bucket 策略的可用元素与访问权限有关。

    如需了解如何使用这些元素控制访问权限的元素和示例,请参阅 AWS 访问策略语言概述

    如需存储桶策略的更多示例,请参阅 AWS Bucket 策略示例

    有关创建 S3 用户的说明,请参阅 第 9.7.3 节 “在 Multicloud 对象网关中创建 AWS S3 用户”

  2. 使用 AWS S3 客户端,使用 put-bucket-policy 命令将存储桶策略应用到 S3 存储桶:

    # aws --endpoint ENDPOINT --no-verify-ssl s3api put-bucket-policy --bucket MyBucket --policy BucketPolicy

    使用 S3 端点替换 ENDPOINT

    MyBucket 替换为存储桶来设置策略

    BucketPolicy 替换为存储桶策略 JSON 文件

    如果您使用默认自签名证书,请添加 --no-verify-ssl

    例如:

    # aws --endpoint https://s3-openshift-storage.apps.gogo44.noobaa.org --no-verify-ssl s3api put-bucket-policy -bucket MyBucket --policy file://BucketPolicy

    如需有关 put-bucket-policy 命令的更多信息,请参阅有关 put-bucket-policy 的 AWS CLI 命令参考

注意

principal 元素指定允许或拒绝访问某一资源的用户,如存储桶。目前,只有 NooBaa 帐户才能用作主体。对于对象存储桶声明,NooBaa 会自动创建一个帐户 obc-account.<generated bucket name>@noobaa.io

注意

不支持 bucket 策略条件。

9.7.3. 在 Multicloud 对象网关中创建 AWS S3 用户

先决条件

步骤

  1. 在 OpenShift Storage 控制台中,导航到 OverviewObject Service → 选择 Multicloud Object Gateway 链接:

    MCG 对象服务 noobaa 链接
  2. Accounts 选项卡下,点 Create Account:

    MCG 帐户创建帐户按钮
  3. 选择 S3 Access Only,提供 帐户名称,例如 john.doe@example.com。点 Next:

    MCG 创建帐户 s3 用户
  4. 选择 S3 默认放置,例如 noobaa-default-backing-store。选择 Buckets Permissions。可以选择特定的存储桶或所有存储桶。点 Create

    MCG 创建帐户 s3 user2

9.8. 对象 Bucket 声明

Object Bucket Claim 可以用来为您的工作负载请求 S3 兼容存储桶后端。

您可以通过三种方式创建对象 BucketClaim:

对象 bucket 声明在 NooBaa 中创建一个新 bucket 和应用帐户,其具有存储桶的权限,包括新的 access key 和 secret access key。应用程序帐户仅允许访问单个存储桶,默认情况下无法创建新的存储桶。

9.8.1. 动态对象 Bucket 声明

与持久卷类似,您可以将 Object Bucket 声明的详细信息添加到应用的 YAML 中,并获取配置映射和机密中可用的对象服务端点、访问密钥和 secret 访问密钥。可在应用程序的环境变量中动态阅读此信息。

步骤

  1. 在应用程序 YAML 中添加以下行:

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: <obc-name>
    spec:
      generateBucketName: <obc-bucket-name>
      storageClassName: openshift-storage.noobaa.io

    这些行是对象 Bucket 声明本身。

    1. <obc-name> 替换为唯一的对象 Bucket Claim 名称。
    2. <obc-bucket-name> 替换为 Object Bucket Claim 的唯一存储桶名称。
  2. 您可以在 YAML 文件中添加更多行来自动使用 Object Bucket Claim。以下示例是存储桶声明结果之间的映射,这是一个带有凭证数据和 secret 的配置映射。此特定作业将从 NooBaa 声明 Object Bucket,这将创建一个存储桶和帐户。

    apiVersion: batch/v1
    kind: Job
    metadata:
      name: testjob
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - image: <your application image>
              name: test
              env:
                - name: BUCKET_NAME
                  valueFrom:
                    configMapKeyRef:
                      name: <obc-name>
                      key: BUCKET_NAME
                - name: BUCKET_HOST
                  valueFrom:
                    configMapKeyRef:
                      name: <obc-name>
                      key: BUCKET_HOST
                - name: BUCKET_PORT
                  valueFrom:
                    configMapKeyRef:
                      name: <obc-name>
                      key: BUCKET_PORT
                - name: AWS_ACCESS_KEY_ID
                  valueFrom:
                    secretKeyRef:
                      name: <obc-name>
                      key: AWS_ACCESS_KEY_ID
                - name: AWS_SECRET_ACCESS_KEY
                  valueFrom:
                    secretKeyRef:
                      name: <obc-name>
                      key: AWS_SECRET_ACCESS_KEY
    1. 将 <obc-name> 的所有实例替换为您的对象 Bucket Claim 名称。
    2. 将 <your application image> 替换为您的应用程序镜像。
  3. 应用更新的 YAML 文件:

    # oc apply -f <yaml.file>
    1. <yaml.file> 替换为 YAML 文件的名称。
  4. 要查看新配置映射,请运行以下命令:

    # oc get cm <obc-name>
    1. obc-name 替换为对象 Bucket Claim 的名称。

      您可以在输出中预期以下环境变量:

      • BUCKET_HOST - 要在应用程序中使用的端点
      • BUCKET_PORT - 应用程序可用的端口

      • BUCKET_NAME - 请求或生成的存储桶名称
      • AWS_ACCESS_KEY_ID - 作为凭据一部分的访问密钥
      • aws_SECRET_ACCESS_KEY - 属于凭据的 Secret 访问密钥
重要

获取 AWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEY。使用名称以便与 AWS S3 API 兼容。您需要在执行 S3 操作时指定密钥,特别是从多云对象网关(MCG)存储桶中读取、写入或列表时。密钥以 Base64 编码。解码密钥,然后才能使用它们。

# oc get secret <obc_name> -o yaml
<obc_name>
指定对象存储桶声明的名称。

9.8.2. 使用命令行界面创建对象 Bucket 声明

在使用命令行界面创建对象 Bucket 声明时,您会获得一个配置映射和一个 Secret,其中包含应用使用对象存储服务所需的所有信息。

先决条件

  • 下载 MCG 命令行界面:

    # subscription-manager repos --enable=rh-ocs-4-for-rhel-8-x86_64-rpms
    # yum install mcg

步骤

  1. 使用命令行界面生成新 bucket 和凭据的详细信息。运行以下命令:

    # noobaa obc create <obc-name> -n openshift-storage

    <obc-name> 替换为一个唯一的对象 Bucket Claim 名称,例如 myappobc

    另外,您可以使用 --app-namespace 选项指定创建 Object Bucket Claim 配置映射和 secret 的命名空间,如 myapp-namespace

    输出示例:

    INFO[0001] ✅ Created: ObjectBucketClaim "test21obc"

    MCG 命令行界面已创建了必要的配置,并已向 OpenShift 告知新的 OBC。

  2. 运行以下命令来查看对象 Bucket 声明:

    # oc get obc -n openshift-storage

    输出示例:

    NAME        STORAGE-CLASS                 PHASE   AGE
    test21obc   openshift-storage.noobaa.io   Bound   38s
  3. 运行以下命令,以查看新对象 Bucket 声明的 YAML 文件:

    # oc get obc test21obc -o yaml -n openshift-storage

    输出示例:

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      creationTimestamp: "2019-10-24T13:30:07Z"
      finalizers:
      - objectbucket.io/finalizer
      generation: 2
      labels:
        app: noobaa
        bucket-provisioner: openshift-storage.noobaa.io-obc
        noobaa-domain: openshift-storage.noobaa.io
      name: test21obc
      namespace: openshift-storage
      resourceVersion: "40756"
      selfLink: /apis/objectbucket.io/v1alpha1/namespaces/openshift-storage/objectbucketclaims/test21obc
      uid: 64f04cba-f662-11e9-bc3c-0295250841af
    spec:
      ObjectBucketName: obc-openshift-storage-test21obc
      bucketName: test21obc-933348a6-e267-4f82-82f1-e59bf4fe3bb4
      generateBucketName: test21obc
      storageClassName: openshift-storage.noobaa.io
    status:
      phase: Bound
  4. openshift-storage 命名空间内,您可以找到配置映射和 secret 来使用此 Object Bucket Claim。CM 和 secret 的名称与 Object Bucket Claim 的名称相同。查看 secret:

    # oc get -n openshift-storage secret test21obc -o yaml

    输出示例:

    Example output:
    apiVersion: v1
    data:
      AWS_ACCESS_KEY_ID: c0M0R2xVanF3ODR3bHBkVW94cmY=
      AWS_SECRET_ACCESS_KEY: Wi9kcFluSWxHRzlWaFlzNk1hc0xma2JXcjM1MVhqa051SlBleXpmOQ==
    kind: Secret
    metadata:
      creationTimestamp: "2019-10-24T13:30:07Z"
      finalizers:
      - objectbucket.io/finalizer
      labels:
        app: noobaa
        bucket-provisioner: openshift-storage.noobaa.io-obc
        noobaa-domain: openshift-storage.noobaa.io
      name: test21obc
      namespace: openshift-storage
      ownerReferences:
      - apiVersion: objectbucket.io/v1alpha1
        blockOwnerDeletion: true
        controller: true
        kind: ObjectBucketClaim
        name: test21obc
        uid: 64f04cba-f662-11e9-bc3c-0295250841af
      resourceVersion: "40751"
      selfLink: /api/v1/namespaces/openshift-storage/secrets/test21obc
      uid: 65117c1c-f662-11e9-9094-0a5305de57bb
    type: Opaque

    该机密为您提供了 S3 访问凭据。

  5. 查看配置映射:

    # oc get -n openshift-storage cm test21obc -o yaml

    输出示例:

    apiVersion: v1
    data:
      BUCKET_HOST: 10.0.171.35
      BUCKET_NAME: test21obc-933348a6-e267-4f82-82f1-e59bf4fe3bb4
      BUCKET_PORT: "31242"
      BUCKET_REGION: ""
      BUCKET_SUBREGION: ""
    kind: ConfigMap
    metadata:
      creationTimestamp: "2019-10-24T13:30:07Z"
      finalizers:
      - objectbucket.io/finalizer
      labels:
        app: noobaa
        bucket-provisioner: openshift-storage.noobaa.io-obc
        noobaa-domain: openshift-storage.noobaa.io
      name: test21obc
      namespace: openshift-storage
      ownerReferences:
      - apiVersion: objectbucket.io/v1alpha1
        blockOwnerDeletion: true
        controller: true
        kind: ObjectBucketClaim
        name: test21obc
        uid: 64f04cba-f662-11e9-bc3c-0295250841af
      resourceVersion: "40752"
      selfLink: /api/v1/namespaces/openshift-storage/configmaps/test21obc
      uid: 651c6501-f662-11e9-9094-0a5305de57bb

    配置映射包含应用的 S3 端点信息。

9.8.3. 使用 OpenShift Web 控制台创建对象 Bucket 声明

您可以使用 OpenShift Web 控制台创建对象 BucketClaim (OBC)。

先决条件

步骤

  1. 登录 OpenShift Web 控制台。
  2. 在左侧导航栏中,点击 StorageObject Bucket Claims
  3. 点击 Create Object Bucket Claim:

    创建 Object Bucket Claims 页面
  4. 输入对象存储桶声明的名称,并根据您的部署(内部或外部)从下拉菜单中选择适当的存储类:

    内部模式

    创建 Object Bucket Claim 向导

    以下存储类是在部署后创建的,可供使用:

    • OCS-storagecluster-ceph-rgw 使用 Ceph 对象网关 (RGW)
    • openshift-storage.noobaa.io 使用 Multicloud 对象网关

    外部模式

    创建 Object Bucket Claim 向导

    以下存储类是在部署后创建的,可供使用:

    • OCS-external-storagecluster-ceph-rgw 使用 Ceph 对象网关 (RGW)
    • openshift-storage.noobaa.io 使用 Multicloud 对象网关

      注意

      RGW OBC 存储类仅可用于全新安装的 OpenShift Container Storage 版本 4.5。它不适用于从以前的 OpenShift Container Storage 发行版本升级的集群。

  5. Create

    创建 OBC 后,您会被重定向到其详情页面:

    Object Bucket Claim Details 页

9.9. 对象存储桶的缓存策略

缓存存储桶是带有 hub 目标和缓存目标的命名空间存储桶。hub 目标是一个 S3 兼容的大型对象存储桶。缓存存储桶是本地 Multicloud 对象网关存储桶。您可以创建一个缓存存储桶来缓存 AWS 存储桶或 IBM COS 存储桶。

重要

缓存存储桶是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

如需更多信息,请参阅技术预览功能支持范围

9.9.1. 创建 AWS 缓存存储桶

先决条件

步骤

  1. 创建 NamespaceStore 资源。NamespaceStore 代表一个底层存储,用作 Multicloud Object Gateway 命名空间存储桶中数据的读取或写入目标。在 MCG 命令行界面中运行以下命令:

    noobaa namespacestore create aws-s3 <namespacestore> --access-key <AWS ACCESS KEY> --secret-key <AWS SECRET ACCESS KEY> --target-bucket <bucket-name>
    1. <namespacestore> 替换为命名空间存储的名称。
    2. <AWS ACCESS KEY><AWS SECRET ACCESS KEY> 替换为您为此创建的 AWS 访问密钥 ID 和 secret 访问密钥。
    3. <bucket-name> 替换为现有的 AWS 存储桶名称。此参数告知多云对象网关将哪一个存储桶用作其后备存储的目标存储桶,以及数据存储和管理。

      您还可以通过应用 YAML 来添加存储资源。首先使用凭证创建 secret:

      apiVersion: v1
      kind: Secret
      metadata:
        name: <namespacestore-secret-name>
      type: Opaque
      data:
        AWS_ACCESS_KEY_ID: <AWS ACCESS KEY ID ENCODED IN BASE64>
        AWS_SECRET_ACCESS_KEY: <AWS SECRET ACCESS KEY ENCODED IN BASE64>

      您必须使用 Base64 提供并编码您自己的 AWS 访问密钥 ID 和 secret 访问密钥,并使用结果代替 <AWS ACCESS KEY ID ENCODED IN BASE64><AWS SECRET ACCESS KEY ENCODED IN BASE64>

      使用一个唯一的名称替换 <namespacestore-secret-name>

      然后应用以下 YAML:

      apiVersion: noobaa.io/v1alpha1
      kind: NamespaceStore
      metadata:
        finalizers:
        - noobaa.io/finalizer
        labels:
          app: noobaa
        name: <namespacestore>
        namespace: openshift-storage
      spec:
        awsS3:
          secret:
            name: <namespacestore-secret-name>
            namespace: <namespace-secret>
          targetBucket: <target-bucket>
        type: aws-s3
    4. <namespacestore> 替换为唯一的名称。
    5. <namespacestore-secret-name> 替换为上一步中创建的 secret。
    6. <namespace-secret> 替换为用于在上一步中创建 secret 的命名空间。
    7. <target-bucket> 替换为您为命名空间存储创建的 AWS S3 存储桶。
  2. 运行以下命令来创建存储桶类:

    noobaa bucketclass create namespace-bucketclass cache <my-cache-bucket-class> --backingstores <backing-store> --hub-resource <namespacestore>
    1. <my-cache-bucket-class> 替换为唯一的存储桶类名称。
    2. <backing-store> 替换为相关的后备存储。您可以在此字段中列出一个或多个以逗号分开的后备存储。
    3. <namespacestore> 替换为上一步中创建的命名空间存储。
  3. 运行以下命令,以使用 Object Bucket Claim 资源创建 bucket,该资源使用第 2 步中定义的 bucket 类。

    noobaa obc create <my-bucket-claim> my-app --bucketclass <custom-bucket-class>
    1. <my-bucket-claim> 替换为唯一名称。
    2. <custom-bucket-class> 替换为在第 2 步中创建的 bucket 类的名称。

9.9.2. 创建 IBM COS 缓存存储桶

先决条件

步骤

  1. 创建 NamespaceStore 资源。NamespaceStore 代表一个底层存储,用作 Multicloud Object Gateway 命名空间存储桶中数据的读取或写入目标。在 MCG 命令行界面中运行以下命令:

    noobaa namespacestore create ibm-cos <namespacestore> --endpoint <IBM COS ENDPOINT> --access-key <IBM ACCESS KEY> --secret-key <IBM SECRET ACCESS KEY> --target-bucket <bucket-name>
    1. <namespacestore> 替换为 NamespaceStore 的名称。
    2. <IBM ACCESS KEY>、<IBM SECRET ACCESS KEY><IBM COS ENDPOINT> 替换为 IBM 访问密钥 ID、机密访问密钥和对应于现有 IBM 存储桶位置的适当区域端点。
    3. <bucket-name> 替换为现有的 IBM 存储桶名称。此参数告知多云对象网关将哪一个存储桶用作其后备存储的目标存储桶,以及数据存储和管理。

      您还可以通过应用 YAML 来添加存储资源。首先,使用凭证创建一个 secret:

      apiVersion: v1
      kind: Secret
      metadata:
        name: <namespacestore-secret-name>
      type: Opaque
      data:
        IBM_COS_ACCESS_KEY_ID: <IBM COS ACCESS KEY ID ENCODED IN BASE64>
        IBM_COS_SECRET_ACCESS_KEY: <IBM COS SECRET ACCESS KEY ENCODED IN BASE64>

      您必须使用 Base64 提供和编码您自己的 IBM COS 访问密钥 ID 和 secret 访问密钥,并使用结果代替 <IBM COS ACCESS KEY ID ENCODED IN BASE64> 和 <IBM COS SECRET ACCESS KEY ENCODED IN BASE64>`。

      使用一个唯一的名称替换 <namespacestore-secret-name>

      然后应用以下 YAML:

      apiVersion: noobaa.io/v1alpha1
      kind: NamespaceStore
      metadata:
        finalizers:
        - noobaa.io/finalizer
        labels:
          app: noobaa
        name: <namespacestore>
        namespace: openshift-storage
      spec:
        s3Compatible:
          endpoint: <IBM COS ENDPOINT>
          secret:
            name: <backingstore-secret-name>
            namespace: <namespace-secret>
          signatureVersion: v2
          targetBucket: <target-bucket>
        type: ibm-cos
    4. <namespacestore> 替换为唯一的名称。
    5. <IBM COS ENDPOINT> 替换为适当的 IBM COS 端点。
    6. <backingstore-secret-name> 替换为上一步中创建的 secret。
    7. <namespace-secret> 替换为用于在上一步中创建 secret 的命名空间。
    8. <target-bucket> 替换为您为命名空间存储创建的 AWS S3 存储桶。
  2. 运行以下命令来创建存储桶类:

    noobaa bucketclass create namespace-bucketclass cache <my-bucket-class> --backingstores <backing-store> --hubResource <namespacestore>
    1. <my-bucket-class> 替换为唯一的存储桶类名称。
    2. <backing-store> 替换为相关的后备存储。您可以在此字段中列出一个或多个以逗号分开的后备存储。
    3. <namespacestore> 替换为上一步中创建的命名空间存储。
  3. 运行以下命令,以使用 Object Bucket Claim 资源创建 bucket,该资源使用第 2 步中定义的 bucket 类。

    noobaa obc create <my-bucket-claim> my-app --bucketclass <custom-bucket-class>
    1. <my-bucket-claim> 替换为唯一名称。
    2. <custom-bucket-class> 替换为在第 2 步中创建的 bucket 类的名称。

9.10. 通过添加端点扩展多云对象网关性能

多云对象网关的性能可能因环境而异。在某些情况下,特定的应用需要更快的性能,这可以通过扩展 S3 端点来轻松解决。

Multicloud Object Gateway 资源池是一组 NooBaa 守护进程容器,默认启用两种类型的服务:

  • 存储服务
  • S3 端点服务

9.10.1. Multicloud 对象网关中的 S3 端点

S3 端点是每个多云对象网关默认提供服务,用于处理 Multicloud 对象网关中的繁重数据摘要。端点服务处理内联数据块、重复数据删除、压缩和加密,它接受来自多云对象网关的数据放置指令。

9.10.2. 使用存储节点扩展

先决条件

  • 在 OpenShift Container Platform 上运行 OpenShift Container Storage 集群,可访问多云对象网关。

Multicloud Object Gateway 中的存储节点是一个 NooBaa 守护进程容器,附加到一个或多个持久性卷,用于本地对象存储。NooBaa 守护进程可以在 Kubernetes 节点上部署。这可以通过创建一个由 StatefulSet pod 组成的 Kubernetes 池来完成。

步骤

  1. 在 Multicloud Object Gateway 用户界面的 Overview 页面中,点 Add Storage Resources:

    MCG 添加存储资源按钮
  2. 在窗口中点击 Deploy Kubernetes Pool

    MCG 部署 kubernetes 池
  3. Create Pool 步骤中,为将来安装的节点创建目标池。

    MCG 部署 kubernetes 池创建池
  4. Configure 步骤中,配置请求的 pod 数以及每个 PV 的大小。对于每个新 pod,会创建一个 PV。

    MCG 部署 kubernetes 池配置
  5. Review 步骤中,您可以找到新池的详细信息,再选择要使用的部署方法:本地或外部部署。如果选择了本地部署,Kubernetes 节点将在集群内部署。如果选择了外部部署,您将获得 YAML 文件,供外部运行。
  6. 所有节点都会分配给您在第一步中选择的池,并可在 ResourcesStorage resourcesResource name 下找到:

    MCG 存储资源概述

9.11. 自动扩展 MultiCloud Object Gateway 端点

当 MCG S3 服务上的负载增加或减少时,MultiCloud Object Gateway(MCG)端点的数量会自动扩展。{product-name-short} 集群使用一个活跃的 MCG 端点。每个 MCG 端点 pod 都默认配置有 1 个 CPU 和 2Gi 内存请求,其限值与请求匹配。当端点上的 CPU 负载在固定时间段内超过 80% 用量阈值时,部署第二个端点会降低第一个端点的负载。当两个端点的平均 CPU 负载在固定时间段内低于 80% 阈值时,会删除其中一个端点。此功能提高了 MCG 的性能和可服务性。

第 10 章 管理持久性卷声明

10.1. 将应用程序 pod 配置为使用 OpenShift Container Storage

按照本节中的说明,将 OpenShift Container Storage 配置为应用程序 pod 的存储。

先决条件

  • 具有 OpenShift Web 控制台的管理访问权限。
  • OpenShift Container Storage Operator 已安装并在 openshift-storage 命名空间中运行。在 OpenShift Web 控制台中,点 OperatorsInstalled Operators 查看已安装的 Operator。
  • OpenShift Container Storage 提供的默认存储类可用。在 OpenShift Web 控制台中,点 StorageStorage Classes 查看默认存储类。

步骤

  1. 为要使用的应用创建持久性卷声明 (PVC)。

    1. 在 OpenShift Web 控制台中,点击 StoragePersistent Volume Claims
    2. 为应用程序 pod 设置 Project
    3. 单击 Create Persistent Volume Claim

      1. 指定由 OpenShift Container Storage 提供的存储类
      2. 指定 PVC Name,如 myclaim
      3. 选择所需的 Access Mode
      4. 根据应用程序要求指定一个 大小
      5. Create 并等待 PVC 处于 Bound 状态。
  2. 配置新的或现有应用容器集以使用新 PVC。

    • 对于新应用程序 pod,执行以下步骤:

      1. WorkloadsPods
      2. 创建新的应用 pod。
      3. spec: 部分下,添加 volume: 部分,将新 PVC 添加为应用 Pod 的卷。

        volumes:
          - name: <volume_name>
            persistentVolumeClaim:
              claimName: <pvc_name>

        例如:

        volumes:
          - name: mypd
            persistentVolumeClaim:
              claimName: myclaim
    • 对于现有应用程序 pod,执行以下步骤:

      1. WorkloadsDeployment Configs
      2. 搜索与应用程序 pod 关联的所需部署配置。
      3. 点击其 Action 菜单(⋮)Edit Deployment Config
      4. spec: 部分下,添加 volume: 部分,将新 PVC 添加为应用程序 Pod 的卷,然后点 Save

        volumes:
          - name: <volume_name>
            persistentVolumeClaim:
              claimName: <pvc_name>

        例如:

        volumes:
          - name: mypd
            persistentVolumeClaim:
              claimName: myclaim
  3. 验证新配置是否正在使用。

    1. 点击 WorkloadsPods
    2. 为应用程序 pod 设置 Project
    3. 验证应用容器集的状态是否为 Running
    4. 单击应用容器集名称,以查看容器集详细信息。
    5. 向下滚动到 Volumes 部分,再验证卷的 Type 与您的新持久卷声明匹配,如 myclaim

10.2. 查看持久性卷声明请求状态

使用这个流程查看 PVC 请求的状态。

先决条件

  • 管理员对 OpenShift Container Storage 的访问权限。

步骤

  1. 登录 OpenShift Web 控制台。
  2. StoragePersistent Volume Claims
  3. 使用 Filter 文本框搜索所需的 PVC 名称。您还可以按 Name 或 Label 过滤 PVC 列表来缩小列表范围
  4. 检查与所需 PVC 对应的 Status 列。
  5. 点所需的 Name 查看 PVC 详情。

10.3. 查看持久性卷声明请求事件

使用这个流程来查看和解决持久性卷声明 (PVC) 请求事件。

先决条件

  • 管理员对 OpenShift Web 控制台的访问权限。

步骤

  1. 登录 OpenShift Web 控制台。
  2. HomeOverviewPersistent Storage
  3. 找到 Inventory 卡,查看 PVC 数量并显示错误。
  4. StoragePersistent Volume Claims
  5. 使用 Filter 文本框搜索所需的 PVC。
  6. 点 PVC 名称并导航到 Events
  7. 根据需要或按指示处理事件。

10.4. 扩展持久性卷声明

OpenShift Container Storage 4.6 能够扩展持久性卷声明,在管理持久性存储资源方面提供更多灵活性。

以下持久性卷支持扩展:

  • 具有 ReadWriteOnce (RWO) 和 ReadWriteMany (RWX) 访问权限的 PVC,这些访问基于 Ceph 文件系统 (CephFS),用于卷模式 Filesystem
  • 具有 ReadWriteOnce (RWO) 访问的 PVC,它基于卷模式 Filesystem 的 Ceph RADOS 块设备 (RBD)。
  • 具有 ReadWriteOnce (RWO) 访问的 PVC,它基于卷模式 Block 的 Ceph RADOS 块设备 (RBD)。
警告

红帽不支持 OSD 和 MON PVC 扩展。

先决条件

  • 管理员对 OpenShift Web 控制台的访问权限。

步骤

  1. 在 OpenShift Web 控制台中,导航到 StoragePersistent Volume Claims
  2. 点击您要扩展的持久性卷声明旁边的 Action Menu(⋮)。
  3. Expand PVC

    持久性卷声明扩展 PVC 菜单项
  4. 选择持久性卷声明的新大小,然后点 Expand

    扩展持久性卷声明向导
  5. 要验证扩展,请导航到 PVC 的详情页面,并验证 Capacity 字段是否具有请求的正确大小。

    注意

    当基于 Ceph RADOS 块设备 (RBD) 扩展 PVC 时,如果 PVC 尚未附加到 pod,Condition type 在 PVC 详情页面中为 FileSystemResizePending。挂载卷后,文件系统大小调整成功,并在 Capacity 字段中反映新大小。

10.5. 动态置备

10.5.1. 关于动态置备

StorageClass 资源对象描述并分类了可请求的存储,并提供了根据需要为动态置备存储传递参数的方法。StorageClass 也可以作为控制不同级别的存储和访问存储的管理机制。集群管理员(cluster-admin)或者存储管理员(storage-admin)可以在无需了解底层存储卷资源的情况下,定义并创建用户可以请求的 StorageClass 对象。

OpenShift Container Storage 持久性卷框架启用了此功能,并允许管理员为集群置备持久性存储。该框架还可让用户在不了解底层存储架构的情况下请求这些资源。

在 OpenShift Container Storage 中,许多存储类型都可用作持久性卷。虽然它们都可以由管理员静态置备,但有些类型的存储是使用内置供应商和插件 API 动态创建的。

10.5.2. OpenShift Container Storage 中的动态置备

Red Hat OpenShift Container Storage 是软件定义的存储,针对容器环境优化。它在 OpenShift Container Platform 上作为操作器运行,为容器提供高度集成和简化的持久性存储管理。

OpenShift Container Storage 支持各种存储类型,包括:

  • 数据库的块存储
  • 共享文件存储,用于持续集成、消息传递和数据聚合
  • 归档、备份和介质存储的对象存储

第 4 版使用 Red Hat Ceph Storage 来提供支持持久卷的文件、块和对象存储,以及 Rook.io 来管理和编排持久卷和声明的调配。NooBaa 提供对象存储,其多云网关允许在多个云环境中联合对象(作为技术预览使用)。

在 OpenShift Container Storage 4 中,RADOS 块设备 (RBD) 和 Ceph 文件系统 (CephFS) 的 Red Hat Ceph Storage Container Storage Interface (CSI) 驱动程序处理动态置备请求。当 PVC 请求动态进入时,CSI 驱动程序有以下选项:

  • 创建一个具有 ReadWriteOnce (RWO) 和 ReadWriteMany (RWX) 访问权限的 PVC,它基于卷模式的 Ceph RBD
  • 创建一个具有 ReadWriteOnce (RWO) 访问权限的 PVC,它基于卷模式 Filesystem的 Ceph RBD
  • 为卷模式 Filesystem创建基于 CephFS 的 ReadWriteOnce (RWO) 和 ReadWriteMany (RWX) 访问的 PVC

判断要使用的驱动程序(RBD 或 CephFS)取决于 storageclass.yaml 文件中的条目。

10.5.3. 可用的动态部署插件

OpenShift Container Storage 提供以下置备程序插件,它们为使用集群配置的供应商 API 创建新存储资源的动态置备提供了通用的实现:

存储类型provisioner 插件名称备注

OpenStack Cinder

kubernetes.io/cinder

 

AWS Elastic Block Store (EBS)

kubernetes.io/aws-ebs

当在不同的区中使用多个集群进行动态置备时,使用 Key=kubernetes.io/cluster/<cluster_name>,Value=<cluster_id> (每个集群的<cluster_name><cluster_id> 是唯一的)来标记(tag)每个节点。

AWS Elastic File System (EFS)

 

动态置备通过 EFS provisioner pod 实现,而不是通过置备程序插件实现。

Azure Disk

kubernetes.io/azure-disk

 

Azure File

kubernetes.io/azure-file

persistent-volume-binder ServiceAccount 需要相应的权限,以创建并获取 Secret 来存储 Azure 存储帐户和密钥。

GCE 持久性磁盘 (gcePD)

kubernetes.io/gce-pd

在多区配置中,建议在每个 GCE 项目中运行一个 OpenShift Container Storage 集群,以避免在当前集群中没有节点的区中创建 PV。

VMware vSphere

kubernetes.io/vsphere-volume

 

Red Hat Virtualization

csi.ovirt.org

 
重要

任何选择的置备程序插件还需要根据相关文档为相关的云、主机或者第三方供应商配置。

第 11 章 卷快照

卷快照是集群中特定时间点的存储卷的状态。这些快照有助于更有效地使用存储,不必每次都制作完整的副本,也可用作应用程序开发的构建块。

您可以创建同一持久性卷声明 (PVC) 的多个快照。对于 CephFS,您可以为每个 PVC 创建最多 100 个快照。对于 RADOS 块设备 (RBD),您可以为每个 PVC 创建最多 512 个快照。

注意

您无法计划定期创建快照。

11.1. 创建卷快照

您可以从持久性卷声明 (PVC) 页面或 Volume Snapshots 页面创建卷快照。

先决条件

  • 对于一致的快照,PVC 应该处于 Bound 状态,且不处于使用状态。在拍摄快照前,请确保停止所有 IO
注意

只有 pod 使用时,OpenShift Container Storage 才会为 PVC 的卷快照提供崩溃一致性。若要确保应用一致性,请务必先停止正在运行的容器集,以确保快照的一致性,或使用应用提供的任何静默机制来确保快照的一致性。

步骤

在持久性卷声明页中显示
  1. 从 OpenShift Web 控制台点 StoragePersistent Volume Claims
  2. 要创建卷快照,请执行以下操作之一:

    • 在所需 PVC 旁边,点 Action 菜单 (⋮)Create Snapshot
    • 点击您要创建快照的 PVC,然后点击 ActionsCreate Snapshot
  3. 输入卷快照的名称
  4. 从下拉列表中选择 Snapshot Class
  5. Create。您将被重定向到所创建的卷快照的 Details 页面。
从 Volume Snapshots 页面中
  1. 从 OpenShift Web 控制台点 StorageVolume Snapshots
  2. Volume Snapshots 页面中,单击 Create Volume Snapshot
  3. 从下拉列表中选择所需的 项目
  4. 从下拉列表中选择持久性卷声明
  5. 输入快照的名称
  6. 从下拉列表中选择 Snapshot Class
  7. Create。您将被重定向到所创建的卷快照的 Details 页面。

验证步骤

  • 进入 PVC 的 Details 页面,然后点击 Volume Snapshots 选项卡查看卷快照列表。验证是否列出了新卷快照。
  • 从 OpenShift Web 控制台点 StorageVolume Snapshots。验证是否列出了新卷快照。
  • 等待卷快照处于 Ready 状态。

11.2. 恢复卷快照

恢复卷快照时,会创建一个新的持久性卷声明 (PVC)。恢复的 PVC 独立于卷快照和父 PVC。

您可以从 PVC 页面或 Volume Snapshots 页面恢复卷快照。

步骤

在持久性卷声明页中显示

只有在存在父 PVC 时,才可以从持久性卷声明页面恢复卷快照。

  1. 从 OpenShift Web 控制台点 StoragePersistent Volume Claims
  2. 点击 PVC 名称及卷快照将卷快照恢复为新 PVC。
  3. Volume Snapshots 选项卡中,点您要恢复的卷快照旁的 Action 菜单(⋮)。
  4. Restore 作为新 PVC
  5. 输入新 PVC 的名称。
  6. 选择您选择的 Access Mode

    重要

    ReadOnlyMany(ROX)访问模式是一个开发者预览功能,它受到开发人员预览支持的限制。开发人员预览版本不应在生产环境中运行,且不受红帽客户门户网站问题单管理系统的支持。如果您需要 ReadOnlyMany 功能的帮助,请联络 ocs-devpreview@redhat.com 邮件列表和红帽开发团队成员将根据可用性和工作计划尽快为您提供协助。请参阅 使用新的只读访问模式创建克隆或恢复快照以使用 ROX 访问模式。

  7. 选择 Storage Class 名。

    注意

    对于 Rados 块设备(RBD),您必须选择一个与父 PVC 池相同的存储类。

  8. 单击 Restore。您将被重定向到新的 PVC 详情页面。
从 Volume Snapshots 页面中
  1. 从 OpenShift Web 控制台点 StorageVolume Snapshots
  2. Volume Snapshots 选项卡中,点您要恢复的卷快照旁的 Action 菜单(⋮)。
  3. Restore 作为新 PVC
  4. 输入新 PVC 的名称。
  5. 选择您选择的 Access Mode

    重要

    ReadOnlyMany(ROX)访问模式是一个开发者预览功能,它受到开发人员预览支持的限制。开发人员预览版本不应在生产环境中运行,且不受红帽客户门户网站问题单管理系统的支持。如果您需要 ReadOnlyMany 功能的帮助,请联络 ocs-devpreview@redhat.com 邮件列表和红帽开发团队成员将根据可用性和工作计划尽快为您提供协助。请参阅 使用新的只读访问模式创建克隆或恢复快照以使用 ROX 访问模式。

  6. 选择 Storage Class 名。

    注意

    对于 Rados 块设备(RBD),您必须选择一个与父 PVC 池相同的存储类。

  7. 单击 Restore。您将被重定向到新的 PVC 详情页面。

验证步骤

  • 从 OpenShift Web 控制台点 StoragePersistent Volume Claims,并确认新 PVC 在 Persistent Volume Claims 页面中列出。
  • 等待新 PVC 进入 Bound 状态。

11.3. 删除卷快照

先决条件

  • 要删除卷快照,应存在该特定卷快照中使用的卷快照类。

步骤

从持久性卷声明页面
  1. 从 OpenShift Web 控制台点 StoragePersistent Volume Claims
  2. 点击具有需要删除卷快照的 PVC 名称。
  3. Volume Snapshots 选项卡中,点击所需卷快照旁的 Action 菜单 (⋮)Delete Volume Snapshot
从卷快照页面
  1. 从 OpenShift Web 控制台点 StorageVolume Snapshots
  2. Volume Snapshots 页面中,点击所需卷快照菜单 (⋮)Delete Volume Snapshot 旁。

验证步骤

  • 确保 PVC 详情页面的 Volume Snapshots 选项卡中没有删除的卷快照。
  • StorageVolume Snapshots 并确保不会列出删除的卷快照。

第 12 章 卷克隆

克隆是现有存储卷的副本,用作任何标准卷。您可以创建一个卷克隆,以达到数据的时间副本。持久性卷声明 (PVC) 不能使用不同的大小克隆。您可以为每个 PVC 为 CephFS 和 RADOS 块设备 (RBD) 创建最多 512 个克隆。

12.1. 创建克隆

先决条件

  • 源 PVC 必须处于 Bound 状态,且不得处于使用状态。
注意

如果 Pod 正在使用 PVC,则不要创建 PVC 克隆。这样做可能会导致数据崩溃,因为 PVC 没有被静默(暂停)。

步骤

  1. 从 OpenShift Web 控制台点 StoragePersistent Volume Claims
  2. 要创建克隆,请执行以下操作之一:

    • 在所需的 PVC 旁边,点 Action 菜单 (⋮)Clone PVC
    • 点击您要克隆的 PVC,然后点击 ActionsClone PVC
  3. 输入克隆的名称
  4. 选择您选择的访问模式。

    重要

    ReadOnlyMany(ROX)访问模式是一个开发者预览功能,它受到开发人员预览支持的限制。开发人员预览版本不应在生产环境中运行,且不受红帽客户门户网站问题单管理系统的支持。如果您需要 ReadOnlyMany 功能的帮助,请联络 ocs-devpreview@redhat.com 邮件列表和红帽开发团队成员将根据可用性和工作计划尽快为您提供协助。请参阅 使用新的只读访问模式创建克隆或恢复快照以使用 ROX 访问模式。

  5. 单击 Clone。您将被重定向到新的 PVC 详情页面。
  6. 等待克隆的 PVC 状态变为 Bound

    克隆的 PVC 现在可以被 pod 使用。这个克隆的 PVC 独立于其 dataSource PVC。

第 13 章 替换存储节点

您可以选择以下步骤之一来替换存储节点:

13.1. 在 Red Hat OpenStack Platform 安装程序置备的基础架构中替换操作节点

使用这个流程替换 Red Hat OpenStack Platform 安装程序置备的基础架构 (IPI) 上的操作节点。

步骤

  1. 登录 OpenShift Web 控制台并点击 ComputeNodes
  2. 确定需要替换的节点。记录其 Machine Name
  3. 使用以下命令将节点标记为不可调度:

    $ oc adm cordon <node_name>
  4. 使用以下命令排空节点:

    $ oc adm drain <node_name> --force --delete-local-data --ignore-daemonsets
    重要

    此活动可能需要至少 5 到 10 分钟或更长时间。这一期间内生成的 Ceph 错误是临时的,在新节点标上并正常运行时自动解决。

  5. ComputeMachines。搜索所需的机器。
  6. 除了所需的机器外,点击 Action 菜单(⋮)Delete Machine
  7. 单击 Delete 以确认删除机器。会自动创建新机器。
  8. 等待新计算机启动并过渡到 Running 状态。

    重要

    此活动可能需要至少 5 到 10 分钟或更长时间。

  9. ComputeNodes,确认新节点是否处于 Ready 状态
  10. 使用以下任一方法之一将 OpenShift Container Storage 标签应用到新节点:

    从用户界面
    1. 对于新节点,点击 Action Menu(⋮)Edit Labels
    2. 添加 cluster.ocs.openshift.io/openshift-storage 并点 Save
    使用命令行界面
    • 执行以下命令,将 OpenShift Container Storage 标签应用到新节点:

      $ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""

验证步骤

  1. 执行以下命令并验证输出中是否存在新节点:

    $ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1
  2. WorkloadsPods,确认新节点上的以下 pod 处于 Running 状态

    • csi-cephfsplugin-*
    • csi-rbdplugin-*
  3. 验证所有其他所需的 OpenShift Container Storage Pod 是否都处于 Running 状态。
  4. 验证新 OSD pod 是否在替换节点上运行。

    $ oc get pods -o wide -n openshift-storage| egrep -i new-node-name | egrep osd
  5. (可选)如果在集群中启用了集群范围的加密,请验证新 OSD 设备是否已加密。

    1. 对于上一步中标识的每个新节点,请执行以下操作:

      1. 创建调试 pod,并为所选主机打开 chroot 环境。

        $ oc debug node/<node name>
        $ chroot /host
      2. 运行 "lsblk" 并检查 ocs-deviceset 名旁边的 "crypt" 关键字。

        $ lsblk
  6. 如果验证步骤失败,请联系红帽支持

13.2. 在 Red Hat OpenStack Platform 安装程序置备的基础架构中替换失败的节点

执行此流程替换在 OpenShift Container Storage 的 Red Hat OpenStack Platform 安装程序置备的基础架构 (IPI) 上无法正常工作的故障节点。

步骤

  1. 登录 OpenShift Web 控制台并点击 ComputeNodes
  2. 确定有故障的节点,再单击其 Machine Name
  3. 点击 Actions → Edit Annotations,然后点 Add More
  4. 添加 machine.openshift.io/exclude-node-draining 并点 Save
  5. ActionsDelete Machine,然后点 Delete
  6. 新机器会自动创建,等待新机器启动。

    重要

    此活动可能需要至少 5 到 10 分钟或更长时间。这一期间内生成的 Ceph 错误是临时的,在新节点标上并正常运行时自动解决。

  7. ComputeNodes,确认新节点是否处于 Ready 状态
  8. 使用以下任一方法之一将 OpenShift Container Storage 标签应用到新节点:

    从用户界面
    1. 对于新节点,点击 Action Menu(⋮)Edit Labels
    2. 添加 cluster.ocs.openshift.io/openshift-storage 并点 Save
    使用命令行界面
    • 执行以下命令,将 OpenShift Container Storage 标签应用到新节点:

      $ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""
  9. [可选]:如果失败的 Red Hat OpenStack Platform 实例没有自动删除,请从 Red Hat OpenStack Platform 控制台终止实例。

验证步骤

  1. 执行以下命令并验证输出中是否存在新节点:

    $ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1
  2. WorkloadsPods,确认新节点上的以下 pod 处于 Running 状态

    • csi-cephfsplugin-*
    • csi-rbdplugin-*
  3. 验证所有其他所需的 OpenShift Container Storage Pod 是否都处于 Running 状态。
  4. 验证新 OSD pod 是否在替换节点上运行。

    $ oc get pods -o wide -n openshift-storage| egrep -i new-node-name | egrep osd
  5. (可选)如果在集群中启用了集群范围的加密,请验证新 OSD 设备是否已加密。

    1. 对于上一步中标识的每个新节点,请执行以下操作:

      1. 创建调试 pod,并为所选主机打开 chroot 环境。

        $ oc debug node/<node name>
        $ chroot /host
      2. 运行 "lsblk" 并检查 ocs-deviceset 名旁边的 "crypt" 关键字。

        $ lsblk
  6. 如果验证步骤失败,请联系红帽支持

第 14 章 替换存储设备

14.1. 在 Red Hat OpenStack Platform 安装程序置备的基础架构中替换操作或失败的存储设备

使用这个流程替换 OpenShift Container Storage 中部署在 Red Hat OpenStack Platform 上的存储设备。这个过程有助于在新卷上创建新持久性卷声明 (PVC) 并删除旧的对象存储设备 (OSD)。

步骤

  1. 确定需要替换的 OSD,以及在其上调度 OSD 的 OpenShift Container Platform 节点。

    $ oc get -n openshift-storage pods -l app=rook-ceph-osd -o wide

    输出示例:

    rook-ceph-osd-0-6d77d6c7c6-m8xj6    0/1    CrashLoopBackOff    0    24h   10.129.0.16   compute-2   <none>           <none>
    rook-ceph-osd-1-85d99fb95f-2svc7    1/1    Running             0    24h   10.128.2.24   compute-0   <none>           <none>
    rook-ceph-osd-2-6c66cdb977-jp542    1/1    Running             0    24h   10.130.0.18   compute-1   <none>           <none>

    在本例中,rook-ceph-osd-0-6d77d6c7c6-m8xj6 需要替换,compute-2 是调度 OSD 的 OpenShift Container Platform 节点。

    注意

    如果要更换的 OSD 处于健康状态,则 Pod 的状态将为 Running

  2. 缩减 OSD 部署,以替换 OSD。

    $ osd_id_to_remove=0
    $ oc scale -n openshift-storage deployment rook-ceph-osd-${osd_id_to_remove} --replicas=0

    其中,osd_id_to_remove 是 pod 名称中紧接在 rook-ceph-osd 前缀后面的整数。在本例中,部署名称为 rook-ceph-osd-0

    输出示例:

    deployment.extensions/rook-ceph-osd-0 scaled
  3. 验证 rook-ceph-osd pod 是否已终止。

    $ oc get -n openshift-storage pods -l ceph-osd-id=${osd_id_to_remove}

    输出示例:

    No resources found.
    注意

    如果 rook-ceph-osd pod 处于 terminating 状态,请使用 force 选项删除 pod。

    $ oc delete pod rook-ceph-osd-0-6d77d6c7c6-m8xj6 --force --grace-period=0

    输出示例:

    warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely.
      pod "rook-ceph-osd-0-6d77d6c7c6-m8xj6" force deleted
  4. 在情形中,与故障 OSD 关联的持久性卷失败,获取失败的持久性卷详情,并使用以下命令删除它们:

    $ oc get pv
    $ oc delete pv <failed-pv-name>
  5. 从集群中移除旧 OSD,以便能够添加新 OSD。

    1. 删除所有旧的 ocs-osd-removal 任务。

      $ oc delete -n openshift-storage job ocs-osd-removal-${osd_id_to_remove}

      输出示例:

      job.batch "ocs-osd-removal-0" deleted
    2. 更改到 openshift-storage 项目。

      $ oc project openshift-storage
    3. 从集群中移除旧 OSD。

      $ oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_IDS=${osd_id_to_remove} |oc create -n openshift-storage -f -

      您可以通过在 命令中添加逗号分隔的 OSD ID 来移除多个 OSD。(例如:FAILED_OSD_IDS=0,1,2)

      警告

      这一步会导致 OSD 完全从集群中移除。确保提供了 osd_id_to_remove 的正确值。

  6. 通过检查 ocs-osd-removal pod 的状态,验证 OSD 是否已成功移除。状态为 Completed,确认 OSD 移除作业已成功。

    $ oc get pod -l job-name=ocs-osd-removal-${osd_id_to_remove} -n openshift-storage
    注意

    如果 ocs-osd-removal 失败且 pod 不处于预期的 Completed 状态,请检查 pod 日志以进一步调试。例如:

    $ oc logs -l job-name=ocs-osd-removal-${osd_id_to_remove} -n openshift-storage --tail=-1
  7. 如果在安装时启用了加密,请从从对应 OpenShift Container Storage 节点中删除的 OSD 设备中删除 dm-crypt managed device-mapper 映射。

    1. ocs-osd-removal-job pod 日志中获取所替换 OSD 的 PVC 名称:

      $ oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1  |egrep -i ‘pvc|deviceset’

      例如:

      2021-05-12 14:31:34.666000 I | cephosd: removing the OSD PVC "ocs-deviceset-xxxx-xxx-xxx-xxx"
    2. 对于第 #1 步中指定的每个节点,请执行以下操作:

      1. 创建 debug pod 和 chroot 到存储节点上的主机。

        $ oc debug node/<node name>
        $ chroot /host
      2. 根据上一步中标识的 PVC 名称查找相关的设备名称

        sh-4.4# dmsetup ls| grep <pvc name>
        ocs-deviceset-xxx-xxx-xxx-xxx-block-dmcrypt (253:0)
      3. 删除映射的设备。

        $ cryptsetup luksClose --debug --verbose ocs-deviceset-xxx-xxx-xxx-xxx-block-dmcrypt
        注意

        如果上述命令因为权限不足而卡住,请运行以下命令:

        • CTRL+Z 退出上述命令。
        • 查找阻塞的进程的 PID。

          $ ps -ef | grep crypt
        • 使用 kill 命令终止进程。

          $ kill -9 <PID>
        • 验证设备名称是否已移除。

          $ dmsetup ls
  8. 删除 ocs-osd-removal 任务。

    $ oc delete -n openshift-storage job ocs-osd-removal-${osd_id_to_remove}

    输出示例:

    job.batch "ocs-osd-removal-0" deleted

验证步骤

  1. 验证是否有新的 OSD 正在运行。

    $ oc get -n openshift-storage pods -l app=rook-ceph-osd

    输出示例:

    rook-ceph-osd-0-5f7f4747d4-snshw                                  1/1     Running     0          4m47s
    rook-ceph-osd-1-85d99fb95f-2svc7                                  1/1     Running     0          1d20h
    rook-ceph-osd-2-6c66cdb977-jp542                                  1/1     Running     0          1d20h
  2. 验证是否创建了处于 Bound 状态的新 PVC。

    $ oc get -n openshift-storage pvc

    输出示例:

    NAME                           STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
    db-noobaa-db-0                 Bound    pvc-b44ebb5e-3c67-4000-998e-304752deb5a7   50Gi       RWO            ocs-storagecluster-ceph-rbd   6d
    ocs-deviceset-0-data-0-gwb5l   Bound    pvc-bea680cd-7278-463d-a4f6-3eb5d3d0defe   512Gi      RWO            standard                      94s
    ocs-deviceset-1-data-0-w9pjm   Bound    pvc-01aded83-6ef1-42d1-a32e-6ca0964b96d4   512Gi      RWO            standard                      6d
    ocs-deviceset-2-data-0-7bxcq   Bound    pvc-5d07cd6c-23cb-468c-89c1-72d07040e308   512Gi      RWO            standard                      6d
  3. (可选)如果在集群中启用了集群范围的加密,请验证新 OSD 设备是否已加密。

    1. 识别运行新 OSD pod 的节点。

      $ oc get -o=custom-columns=NODE:.spec.nodeName pod/<OSD pod name>

      例如:

      oc get -o=custom-columns=NODE:.spec.nodeName pod/rook-ceph-osd-0-544db49d7f-qrgqm
    2. 对于上一步中确定的每个节点,请执行以下操作:

      1. 创建调试 pod,并为所选主机打开 chroot 环境。

        $ oc debug node/<node name>
        $ chroot /host
      2. 运行 "lsblk" 并检查 ocs-deviceset 名旁边的 "crypt" 关键字。

        $ lsblk
  4. 登录 OpenShift Web 控制台并查看存储仪表板。

    图 14.1. 在设备替换后,OpenShift Container Platform 存储仪表板中的 OSD 状态

    显示正常运行的 RHOCP 存储控制面板。

第 15 章 更新 OpenShift Container Storage

15.1. OpenShift Container Storage 更新过程概述

您可以将 Red Hat OpenShift Container Storage 及其组件(如 4.6 和 4.7)或批处理更新(如 4.7.0 和 4.7.1)升级。

您需要以特定的顺序升级 OpenShift Container Storage 的不同部分。

  1. 根据 OpenShift Container Platform 更新集群文档更新 OpenShift Container Platform。
  2. 更新 OpenShift 容器平台存储.

    1. 要准备断开连接的环境以获取更新,请参阅 Operator 指南,在受限网络中使用 Operator Lifecycle Manager,以便在使用时能够更新 Openshift Container Storage 和 Local Storage Operator。
    2. 使用适合您的设置的流程更新 OpenShift Container Storage operator

更新注意事项

开始之前,请先查阅以下重要注意事项:

  • 红帽建议在 Red Hat OpenShift Container Storage 中使用同一版本的 Red Hat OpenShift Container Platform。

    如需有关 OpenShift Container Platform 和 OpenShift Container Storage 组合的更多信息,请参阅 Interoperability Matrix

  • 只有在 Local Storage Operator 版本与 Red Hat OpenShift Container Platform 版本匹配时,才会完全支持 Local Storage Operator。

15.2. 在断开连接的环境中准备更新

当您的 Red Hat OpenShift Container Storage 环境没有直接连接到互联网时,需要一些额外的配置来为 Operator Lifecycle Manager (OLM) 提供默认 Operator Hub 和镜像 registry 的替代选择。

如需了解更多信息,请参阅 OpenShift Container Platform 文档: 更新 Operator 目录镜像

配置集群以进行断开连接的更新:

完成这些步骤后,请照常 继续更新

15.2.1. 添加镜像 registry 身份验证详情

先决条件

  • 验证现有的断开连接的集群是否使用 OpenShift Container Platform 4.3 或更高版本。
  • 验证 oc 客户端 版本是否为 4.4 或更高版本。
  • 使用镜像 registry 准备镜像主机。详情请参阅准备镜像主机

步骤

  1. 使用 cluster-admin 角色登录 OpenShift Container Platform 集群。
  2. 查找 auth.json 文件。

    当您使用 podman 或 docker 登录 registry 时,会生成此文件。它位于以下位置之一:

    • ~/.docker/auth.json
    • /run/user/<UID>/containers/auth.json
    • /var/run/containers/<UID>/auth.json
  3. 获取您唯一的红帽 registry pull secret,并将其粘贴到 auth.json 文件中。它看起来类似于:

    {
        "auths": {
            "cloud.openshift.com": {
                "auth": "*****************",
                "email": "user@example.com"
            },
            "quay.io": {
                "auth": "*****************",
                "email": "user@example.com"
            },
            "registry.connect.redhat.com": {
                "auth": "*****************",
                "email": "user@example.com"
            },
            "registry.redhat.io": {
                "auth": "*****************",
                "email": "user@example.com"
            }
        }
      }
  4. 使用设置的适当详情导出环境变量。

    $ export AUTH_FILE="<location_of_auth.json>"
    $ export MIRROR_REGISTRY_DNS="<your_registry_url>:<port>"
  5. 使用 podman 登录镜像 registry,并将凭据存储在 ${AUTH_FILE} 中。

    $ podman login ${MIRROR_REGISTRY_DNS} --tls-verify=false --authfile ${AUTH_FILE}

    这会将镜像 registry 添加到 auth.json 文件中。

    {
        "auths": {
            "cloud.openshift.com": {
                "auth": "*****************",
                "email": "user@example.com"
            },
            "quay.io": {
                "auth": "*****************",
                "email": "user@example.com"
            },
            "registry.connect.redhat.com": {
                "auth": "*****************",
                "email": "user@example.com"
            },
            "registry.redhat.io": {
                "auth": "*****************",
                "email": "user@example.com"
            },
            "<mirror_registry>": {
                "auth": "*****************",
            }
        }
      }

15.2.2. 构建和镜像红帽 operator 目录

在可以访问红帽 registry 的主机上按照此过程创建这些 registry 的镜像。

先决条件

  • 以集群管理员身份运行这些命令。
  • 请注意,镜像 redhat-operator 目录需要几小时才能完成,并且需要镜像主机上大量可用磁盘空间。

步骤

  1. redhat-operators 构建目录。

    使用与目标 OpenShift Container Platform 集群主版本和次版本匹配的标签,将 --from 设置为 ose-operator-registry 基础镜像。

    $ oc adm catalog build --appregistry-org redhat-operators \
      --from=registry.redhat.io/openshift4/ose-operator-registry:v4.7 \
      --to=${MIRROR_REGISTRY_DNS}/olm/redhat-operators:v2 \
      --registry-config=${AUTH_FILE} \
      --filter-by-os="linux/amd64" --insecure
  2. redhat-operators 镜像目录。

    这是一个漫长的操作,可能需要 1 到 5 个小时。确保镜像主机上有 100 GB 的可用磁盘空间。

    $ oc adm catalog mirror ${MIRROR_REGISTRY_DNS}/olm/redhat-operators:v2 \
    ${MIRROR_REGISTRY_DNS} --registry-config=${AUTH_FILE} --insecure

15.2.3. 创建 Operator imageContentSourcePolicy

oc adm catalog mirror 命令完成后,imageContentSourcePolicy.yaml 文件会被创建。通常,此文件的输出目录为 ./[catalog image name]-manifests)。使用这个流程在 .yaml 文件中添加任何缺少的条目,并将其应用到集群。

步骤

  1. 检查此文件的内容是否有如下所示的镜像映射:

    spec:
      repositoryDigestMirrors:
        - mirrors:
          - <your_registry>/ocs4
          source: registry.redhat.io/ocs4
        - mirrors:
          - <your_registry>/rhceph
          source: registry.redhat.io/rhceph
        - mirrors:
          - <your_registry>/openshift4
          source: registry.redhat.io/openshift4
        - mirrors:
          - <your_registry>/rhscl
          source: registry.redhat.io/rhscl
  2. imageContentSourcePolicy.yaml 文件的末尾添加任何缺少的条目。
  3. 将 imageContentSourcePolicy.yaml 文件应用到集群。

    $ oc apply -f ./[output dir]/imageContentSourcePolicy.yaml

    更新镜像内容源策略后,需要更新并重新引导集群中的所有节点(master、infra 和 worker)。此过程通过 Machine Config Pool operator 自动处理,最多需要 30 分钟,尽管确切经过的时间可能因 OpenShift 集群中的节点数量而异。您可以使用 oc get mcp 命令或 oc get node 命令来监控更新过程。

15.2.4. 更新 redhat-operator CatalogSource

步骤

  1. 重新创建 CatalogSource 对象来引用红帽操作器的目录镜像。

    注意

    确保您已使用正确的版本(即 v2)镜像了正确的目录源。

    redhat-operator-catalogsource.yaml 文件中保存以下内容,记住将 <your_registry> 替换为您的镜像 registry URL:

    apiVersion: operators.coreos.com/v1alpha1
    kind: CatalogSource
    metadata:
      name: redhat-operators
      namespace: openshift-marketplace
    spec:
      sourceType: grpc
      icon:
        base64data: PHN2ZyBpZD0iTGF5ZXJfMSIgZGF0YS1uYW1lPSJMYXllciAxIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHZpZXdCb3g9IjAgMCAxOTIgMTQ1Ij48ZGVmcz48c3R5bGU+LmNscy0xe2ZpbGw6I2UwMDt9PC9zdHlsZT48L2RlZnM+PHRpdGxlPlJlZEhhdC1Mb2dvLUhhdC1Db2xvcjwvdGl0bGU+PHBhdGggZD0iTTE1Ny43Nyw2Mi42MWExNCwxNCwwLDAsMSwuMzEsMy40MmMwLDE0Ljg4LTE4LjEsMTcuNDYtMzAuNjEsMTcuNDZDNzguODMsODMuNDksNDIuNTMsNTMuMjYsNDIuNTMsNDRhNi40Myw2LjQzLDAsMCwxLC4yMi0xLjk0bC0zLjY2LDkuMDZhMTguNDUsMTguNDUsMCwwLDAtMS41MSw3LjMzYzAsMTguMTEsNDEsNDUuNDgsODcuNzQsNDUuNDgsMjAuNjksMCwzNi40My03Ljc2LDM2LjQzLTIxLjc3LDAtMS4wOCwwLTEuOTQtMS43My0xMC4xM1oiLz48cGF0aCBjbGFzcz0iY2xzLTEiIGQ9Ik0xMjcuNDcsODMuNDljMTIuNTEsMCwzMC42MS0yLjU4LDMwLjYxLTE3LjQ2YTE0LDE0LDAsMCwwLS4zMS0zLjQybC03LjQ1LTMyLjM2Yy0xLjcyLTcuMTItMy4yMy0xMC4zNS0xNS43My0xNi42QzEyNC44OSw4LjY5LDEwMy43Ni41LDk3LjUxLjUsOTEuNjkuNSw5MCw4LDgzLjA2LDhjLTYuNjgsMC0xMS42NC01LjYtMTcuODktNS42LTYsMC05LjkxLDQuMDktMTIuOTMsMTIuNSwwLDAtOC40MSwyMy43Mi05LjQ5LDI3LjE2QTYuNDMsNi40MywwLDAsMCw0Mi41Myw0NGMwLDkuMjIsMzYuMywzOS40NSw4NC45NCwzOS40NU0xNjAsNzIuMDdjMS43Myw4LjE5LDEuNzMsOS4wNSwxLjczLDEwLjEzLDAsMTQtMTUuNzQsMjEuNzctMzYuNDMsMjEuNzdDNzguNTQsMTA0LDM3LjU4LDc2LjYsMzcuNTgsNTguNDlhMTguNDUsMTguNDUsMCwwLDEsMS41MS03LjMzQzIyLjI3LDUyLC41LDU1LC41LDc0LjIyYzAsMzEuNDgsNzQuNTksNzAuMjgsMTMzLjY1LDcwLjI4LDQ1LjI4LDAsNTYuNy0yMC40OCw1Ni43LTM2LjY1LDAtMTIuNzItMTEtMjcuMTYtMzAuODMtMzUuNzgiLz48L3N2Zz4=
        mediatype: image/svg+xml
      image: <your_registry>/olm/redhat-operators:v2
      displayName: Redhat Operators Catalog
      publisher: Red Hat
  2. 使用 redhat-operator-catalogsource.yaml 文件创建一个目录源:

    $ oc apply -f redhat-operator-catalogsource.yaml
  3. 验证新的 redhat-operator pod 是否正在运行。

    $ oc get pod -n openshift-marketplace | grep redhat-operators

15.2.5. 继续更新

在配置了其他目录源后,您可以继续适当的更新过程:

15.3. 以内部模式更新 OpenShift Container Storage

使用以下步骤更新以内部模式部署的 OpenShift Container Storage 集群。

15.3.1. 以内部模式启用 OpenShift Container Storage Operator 的自动更新

使用这个流程在 OpenShift Container Platform 中启用自动更新批准来更新 OpenShift Container Storage Operator。

先决条件

  • Status 卡中的 Persistent Storage 下,确认 OCS ClusterData Resiliency 有一个绿色勾号。
  • Status 卡中的 Object Service 下,确认 Object ServiceData Resiliency 都是 Ready 状态(绿色勾号)。
  • 将 OpenShift Container Platform 集群更新至版本 4.7.Y 的最新稳定版本,请参阅 更新集群
  • 将 Red Hat OpenShift Container Storage 频道从 stable-4.6 切换到 stable-4.7。有关频道的详情,请参阅 OpenShift Container Storage 升级频道和发行版本

    注意

    只有在更新次版本(例如,从 4.6 升级到 4.7)且不能在批处理更新之间更新(例如,从 4.7.0 更新到 4.7.1)时,才需要切换频道。

  • 确保所有 OpenShift Container Storage Pod(包括 Operator Pod)在 openshift-storage 命名空间中 处于 Running 状态。

    要查看 pod 的状态,请点击 OpenShift Web 控制台左侧窗格中的 WorkloadsPods。从 Project 下拉列表中,选择 openshift-storage

  • 确保您有足够的时间完成 Openshift Container Storage 更新过程,因为更新时间因集群中运行的 OSD 数量而异。

步骤

  1. 登录 OpenShift Web 控制台。
  2. OperatorsInstalled Operators
  3. 选择 openshift-storage 项目。
  4. 点 OpenShift Container Storage operator 名称。
  5. 单击 Subscription 选项卡,再单击 Approval 下的链接。
  6. 选择 Automatic(default) 并点 Save
  7. 根据 Upgrade Status 执行以下操作之一:

    • 升级状态 显示 需要批准

      注意

      如果频道中已检测到新的 OpenShift Container Storage 版本,且更新时已将批准策略从 Manual 改为 Automatic,则 升级状态 会显示为需要批准

      1. 单击 Install Plan 链接。
      2. InstallPlan Details 页面中点 Preview Install Plan
      3. 检查安装计划并点 Approve
      4. 等待 StatusUnknown 更改为 Created
      5. OperatorsInstalled Operators
      6. 选择 openshift-storage 项目。
      7. 等待 Status 更改为 Up to date
    • 升级状态 不需要 批准

      1. 等待更新启动。这可能需要长达 20 分钟。
      2. OperatorsInstalled Operators
      3. 选择 openshift-storage 项目。
      4. 等待 Status 更改为 Up to date
注意

现在,由于将 NooBaa DB 从 MongoDB 迁移到 PostgreSQL,在升级过程中可以短时间内停机。

验证步骤

  1. Overview → Persistent Storage 标签页,在 Status 卡中确认 OCS ClusterData Resiliency 有一个绿色勾号标记(表示它正常运行)。
  2. Overview → Object Service 标签页,在 Status 卡中确认 Object ServiceData Resiliency 都是 Ready 状态(绿色勾号)。
  3. OperatorsInstalled OperatorsOpenShift Container Storage Operator。在 Storage Cluster 下,验证集群服务状态是否为 Ready

    注意

    从 OpenShift Container Storage 版本 4.6 更新至 4.7 后,这里的 Version 字段仍将显示 4.6。这是因为 ocs-operator 不会更新此字段中代表的字符串。

  4. 确保所有 OpenShift Container Storage Pod(包括 Operator Pod)在 openshift-storage 命名空间中 处于 Running 状态。

    要查看 pod 的状态,请点击 WorkloadsPods。从 Project 下拉列表中,选择 openshift-storage

  5. 如果验证步骤失败,请联系红帽支持
注意

灵活的扩展功能仅在 Red Hat OpenShift Container Storage 4.7 的新部署中可用。升级到 4.7 版本的存储集群不支持灵活的扩展。

其它资源

如果您在更新 OpenShift Container Storage 时遇到任何问题,请参阅故障排除指南中的常见的进行故障排除所需的日志部分。

15.3.2. 以内部模式手动更新 OpenShift Container Storage Operator

通过向安装计划提供手动批准来更新 OpenShift Container Storage Operator。

先决条件

  • Status 卡中的 Persistent Storage 下,确认 OCS ClusterData Resiliency 有一个绿色勾号。
  • Status 卡中的 Object Service 下,确认 Object ServiceData Resiliency 都是 Ready 状态(绿色勾号)。
  • 将 OpenShift Container Platform 集群更新至版本 4.7.Y 的最新稳定版本,请参阅 更新集群
  • 将 Red Hat OpenShift Container Storage 频道从 stable-4.6 切换到 stable-4.7。有关频道的详情,请参阅 OpenShift Container Storage 升级频道和发行版本

    注意

    只有在更新次版本(例如,从 4.6 升级到 4.7)且不能在批处理更新之间更新(例如,从 4.7.0 更新到 4.7.1)时,才需要切换频道。

  • 确保所有 OpenShift Container Storage Pod(包括 Operator Pod)在 openshift-storage 命名空间中 处于 Running 状态。

    要查看 pod 的状态,请点击 OpenShift Web 控制台左侧窗格中的 WorkloadsPods。从 Project 下拉列表中,选择 openshift-storage

  • 确保您有足够的时间完成 Openshift Container Storage 更新过程,因为更新时间因集群中运行的 OSD 数量而异。

步骤

  1. 登录 OpenShift Web 控制台。
  2. OperatorsInstalled Operators
  3. 选择 openshift-storage 项目。
  4. OpenShift Container Storage operator 名称。
  5. 单击 Subscription 选项卡,再单击 Approval 下的链接。
  6. 选择 Manual,然后单击 Save
  7. 等待 Upgrade Status 更改为 Upgrading
  8. 如果 Upgrade Status 显示 需要批准,请单击 require approval
  9. InstallPlan Details 页面中点 Preview Install Plan
  10. 检查安装计划并点 Approve
  11. 等待 StatusUnknown 更改为 Created
  12. OperatorsInstalled Operators
  13. 选择 openshift-storage 项目。
  14. 等待 Status 更改为 Up to date
注意

现在,由于将 NooBaa DB 从 MongoDB 迁移到 PostgreSQL,在升级过程中可以短时间内停机。

验证步骤

  1. Overview → Persistent Storage 标签页,在 Status 卡中确认 OCS ClusterData Resiliency 有一个绿色勾号标记(表示它正常运行)。
  2. Overview → Object Service 标签页,在 Status 卡中确认 Object ServiceData Resiliency 都是 Ready 状态(绿色勾号)。
  3. OperatorsInstalled OperatorsOpenShift Container Storage Operator。在 Storage Cluster 下,验证集群服务状态是否为 Ready

    注意

    从 OpenShift Container Storage 版本 4.6 更新至 4.7 后,这里的 Version 字段仍将显示 4.6。这是因为 ocs-operator 不会更新此字段中代表的字符串。

  4. 确保所有 OpenShift Container Storage Pod(包括 Operator Pod)在 openshift-storage 命名空间中 处于 Running 状态。

    要查看 pod 的状态,请点击 OpenShift Web 控制台左侧窗格中的 WorkloadsPods。从 Project 下拉列表中,选择 openshift-storage

  5. 如果验证步骤失败,请联系红帽支持

其它资源

如果您在更新 OpenShift Container Storage 时遇到任何问题,请参阅故障排除指南中的常见的进行故障排除所需的日志部分。