使用 Red Hat Virtualization 平台部署和管理 OpenShift Container Storage

Red Hat OpenShift Container Storage 4.6

如何安装和管理

摘要

有关使用 Red Hat Virtualization 平台安装和管理 Red Hat OpenShift Container Storage 的说明,请参阅本文档。
重要
Deploying and managing OpenShift Container Storage on Red Hat Virtualization 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.

前言

Red Hat OpenShift Container Storage 4.6 支持在现有 Red Hat OpenShift Container Platform (RHOCP) Red Hat Virtualization Platform 集群上部署。

要以内部模式部署 OpenShift Container Storage,请遵循在 Red Hat Virtualization 上部署 OpenShift Container Storage 的部署过程。

第 1 章 在 Red Hat Virtualization 平台上部署 OpenShift Container Storage

使用 Red Hat Virtualization 安装程序置备的基础架构 (IPI) 提供的共享存储设备在 OpenShift Container Platform 上部署 OpenShift Container Storage 可让您创建内部集群资源。

注意

只有 Red Hat Virtualization 平台支持内部 Openshift Container Storage 集群。如需有关部署要求的更多信息,请参阅规划部署

使用本节在已安装 OpenShift Container Platform 的 Red Hat Virtualization 基础架构上部署 OpenShift Container Storage。

要使用本地存储部署 Red Hat OpenShift Container Storage,请按照以下步骤执行:

1.1. 使用本地存储设备安装 OpenShift Container Storage 的要求

  • 在部署 OpenShift Container Storage 4.6 之前,您必须升级到 OpenShift Container Platform 4.6 的最新版本。如需更多信息,请参阅更新 OpenShift Container Platform 集群指南。
  • Local Storage Operator 版本必须与 Red Hat OpenShift Container Platform 版本匹配,以便 Red Hat OpenShift Container Storage 完全支持 Local Storage Operator。当 Red Hat OpenShift Container Platform 升级时,Local Storage Operator 不会被升级。
  • 集群中必须至少有三个 OpenShift Container Platform worker 节点,每个节点都有本地附加的存储设备。

    • 三个所选节点的每个节点必须至少有一个原始块设备可供 OpenShift Container Storage 使用。
    • 您使用的设备必须为空;磁盘不得包含物理卷 (PV),卷组 (VG) 或逻辑卷 (LV) 不能保留在磁盘上。

1.2. 安装 Red Hat OpenShift Container Storage Operator

您可以使用 Red Hat OpenShift Container Platform Operator Hub 安装 Red Hat OpenShift Container Storage Operator。有关硬件和软件要求的详情,请参阅规划您的部署

先决条件

  • 您必须登录 OpenShift Container Platform (RHOCP) 集群。
  • RHOCP 集群中必须至少有三个工作程序节点。
注意
  • 当您需要覆盖 OpenShift Container 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. 在 OpenShift Web 控制台左侧窗格中,点 Operators → OperatorHub
  2. 使用 Filter by keyword 文本框或过滤器列表从 operator 列表中搜索 OpenShift Container Storage。
  3. OpenShift Container Storage
  4. OpenShift Container Storage operator 页面中,点 Install。
  5. Install Operator 页面中,确保默认选择以下选项:

    1. 将频道更新为 stable-4.6
    2. 安装模式为 A specific namespace on the cluster
    3. Installed Namespace 为 Operator recommended namespace openshift-storage。如果 Namespace openshift-storage 不存在,它会在 Operator 安装过程中创建。
    4. 选择 Enable operator recommended cluster monitoring on this namespace 复选框,因为集群监控需要它。
    5. Approval Strategy 选为 AutomaticManual。默认情况下,批准策略设置为 Automatic

      • Approval StrategyAutomatic.

        注意

        当您将 Approval Strategy 选为 Automatic 时,在全新安装过程或升级到最新版本的 OpenShift Container Storage 时不需要批准。

        1. Install
        2. 等待安装启动。这可能需要长达 20 分钟。
        3. Operators → Installed Operators
        4. 确保 Projectopenshift-storage。默认情况下,Projectopenshift-storage
        5. 等待 OpenShift Container StorageStatus 变为 Succeeded
      • Approval StrategyManual.

        注意

        当您将 Approval Strategy 选为 Manual 时,在全新安装或升级到最新版本的 OpenShift Container Storage 过程中需要批准。

        1. Install
        2. Manual approval required 页面中,您可以点 ApproveView Installed Operators in namespace openshift-storage 来安装 Operator。

          重要

          在单击任一选项前,请在 Manual approval required 页面中等待几分钟,直到安装计划加载到窗口中。

          重要

          如果您选择单击 Approve,您必须先检查安装计划,然后再继续。

          • 如果您单击 Approve

            • 等待几分钟,以便安装 OpenShift Container Storage Operator。
            • Installed operator - ready for use 页面上,点 View Operator
            • 确保 Projectopenshift-storage。默认情况下,Projectopenshift-storage
            • Operators → Installed Operators
            • 等待 OpenShift Container StorageStatus 变为 Succeeded
          • 如果您点 View Installed Operators in namespace openshift-storage

            • Installed Operators 页面中,点 ocs-operator
            • Subscription Details 页面中,点 Install Plan 链接。
            • InstallPlan Details 页面中点 Preview Install Plan
            • 检查安装计划并点 Approve
            • 等待 ComponentsStatusUnknown 变为 CreatedPresent
            • Operators → Installed Operators
            • 确保 Projectopenshift-storage。默认情况下,Projectopenshift-storage
            • 等待 OpenShift Container StorageStatus 变为 Succeeded

验证步骤

  • 验证 OpenShift Container Storage Operator 是否显示绿色勾号,指示安装成功。
  • View Installed Operators in namespace openshift-storage 链接,验证 OpenShift Container Storage Operator 是否在 Installed Operators 仪表板上显示的 StatusSucceeded

1.3. 安装 Local Storage Operator

在本地存储设备上创建 OpenShift Container Storage 集群前,使用此流程从 Operator Hub 安装 Local Storage Operator。

流程

  1. 登录 OpenShift Web 控制台。
  2. Operators → OperatorHub
  3. 从 operator 列表中搜索 Local Storage Operator,再单击它。
  4. 点击 Install

    图 1.1. 安装 Operator 页面

    Install Operator 页面的截图。
  5. Install Operator 页面中设置以下选项:

    1. 把频道更新为 4.6
    2. 安装模式为 A specific namespace on the cluster
    3. Installed Namespace 为 Operator recommended namespace openshift-local-storage
    4. 批准策略作为 Automatic
  6. 点击 Install
  7. 验证 Local Storage Operator 是否显示 Status 为 Succeeded

1.4. 在 Red Hat Virtualization 平台上创建 OpenShift Container Storage 集群

当存储类不存在时,使用这个流程在 Red Hat Virtualization 平台上创建存储集群。

如果您已经创建了存储类,可以直接创建存储集群,如 当存储类存在时在 Red Hat Virtualization 平台上创建存储集群所述。

先决条件

流程

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

    确保所选的 Projectopenshift-storage

    图 1.2. OpenShift Container Storage Operator 页

    OpenShift Container Storage operator 仪表板的截图。
  3. OpenShift Container Storage

    图 1.3. OpenShift Container Storage 的详情标签页

    选定操作器详细信息选项卡的屏幕截图。
  4. 单击 Storage Cluster 的 Create Instance 链接。

    图 1.4. 创建存储集群页面

    Create Storage Cluster 页面的截图
  5. Select Mode 选择 Internal-Attached 设备。默认选择 Internal。
  6. 使用向导创建存储集群,其中包括磁盘发现、存储类创建和存储集群创建。

    系统会提示您安装 Local Storage Operator。点 Install 并安装 Operator,如安装 Local Storage Operator 所述。

    发现磁盘

    您可以在所选节点上发现一个潜在的可用磁盘列表。发现不使用且可用于置备持久性卷 (PV) 的磁盘和分区。

    图 1.5. Discovery Disks 向导页面

    在所选节点中发现磁盘的截图.
    1. 选择以下任意一项:

      • 可发现所有节点中磁盘的所有节点
      • 从列出的节点选择节点的子集。

        要查找集群中的特定 worker 节点,您可以根据 Name 或 Label 过滤节点。Name 允许您按节点名称搜索,而 Label 则允许您选择预定义的标签进行搜索。

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

        注意

        如果要选择的节点有污点且没有在向导中发现,请按照红帽知识库解决方案中提供的步骤作为临时解决方案。

    2. Next
    创建存储类

    您可以通过过滤一组存储卷来创建专用的存储类来消耗存储。

    图 1.6. 创建 Storage Class 向导页面

    输入存储类详情的截图。
    1. 输入 Volume Set Name
    2. 输入 Storage Class Name。默认情况下,存储类名称会出现卷集名称。
    3. 在上一步中为磁盘发现选择的节点会在 Filter Disks 部分显示。选择以下任意一项:

      • 选择 All nodes 可以选择您发现设备的所有节点。
      • 选择 Select nodes 可以选择一组节点来发现设备。

        要查找集群中的特定 worker 节点,您可以根据 Name 或 Label 过滤节点。Name 允许您按节点名称搜索,而 Label 则允许您选择预定义的标签进行搜索。

        建议 worker 节点分散到三个不同的物理节点、机架或故障域中以实现高可用性。

        注意

        确保 OpenShift Container Storage 机架标签与数据中心中的物理机架一致,以防止在故障域级别出现双节点故障。

    4. 选择所需的 Disk Type。可用的选项如下:

      All

      选择节点上存在的所有磁盘类型。默认情况下会选择这个选项。

      SSD/NVME

      仅选择 SSD 或 NVME 类型磁盘。

      HDD

      仅选择 HDD 类型磁盘。

      注意

      如果因为底层存储抽象而检测到 SSD/NVME 磁盘为 HDD,请选择磁盘类型 AllHDD

    5. Advanced 部分,您可以设置以下内容:

      磁盘模式

      默认会选择块。

      磁盘大小

      需要被包含的设备的最小和最大可用大小。

      注意

      您必须为该设备设置最小 100GB。

      最大磁盘限制

      这表示节点上可以创建的 PV 数量上限。如果此字段留空,则为匹配节点上的所有可用磁盘创建 PV。

    6. (可选)您可以使用 Select Capacity Chart 查看所选节点上的磁盘所选容量。

      此图表可能需要几分钟时间来反映上一步中发现的磁盘。

      您可以单击图表中的 NodesDisks 链接,以调出节点和磁盘列表以查看更多详细信息。

      图 1.7. 选定节点列表

      从所选容量图显示的节点列表截图。

      图 1.8. 所选磁盘列表

      从所选容量图中显示的磁盘列表截图。
    7. Next
    8. 在消息警报中单击 Yes 以确认创建存储类。

      本地卷集和存储类被创建后,无法返回该步骤。

    创建存储集群

    图 1.9. 创建 Storage Cluster 向导页面

    存储集群创建屏幕截图.
    1. 选择所需的存储类。

      您可能需要等待一两分钟,以便与所选存储类对应的存储节点被填充。

    2. (可选)在 Encryption 部分中,将切换设置为 Enabled 以在集群中启用数据加密。
    3. 与存储类对应的节点会根据从下拉列表中选择的存储类显示。
    4. 点击 Create

      只有在最少选择了三个节点时,才会启用 Create 按钮。将创建一个包含三个卷的新存储集群,每个 worker 节点都有一个卷。默认配置使用 3 的复制因子。

若要扩展初始集群的容量,请参阅扩展存储节点

1.5. 当存储类存在时,在 Red Hat Virtualization 平台中创建存储集群

您可以使用通过 Local Storage Operator 页面创建的现有存储类来创建 Openshift Container Storage Cluster。

先决条件

流程

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

    确保所选的 Projectopenshift-storage

    图 1.10. OpenShift Container Storage Operator 页

    OpenShift Container Storage operator 仪表板的截图。
  3. OpenShift Container Storage

    图 1.11. OpenShift Container Storage 的详情标签页

    选定操作器详细信息选项卡的屏幕截图。
  4. 单击 Storage Cluster 的 Create Instance 链接。

    图 1.12. 创建存储集群页面

    Create Cluster Service 页面的截图
  5. Select Mode 选择 Internal-Attached 设备。默认选择 Internal。

    图 1.13. 创建存储集群页面

    存储集群创建页面截图。
  6. (可选)在 Encryption 部分中,将切换设置为 Enabled 以在集群中启用数据加密。
  7. 此时会显示与所选存储类对应的节点。

    如果还没有标记,所选节点标记为 cluster.ocs.openshift.io/openshift-storage=''。选定的三个节点用于初始部署,其余节点用作 OpenShift Container Storage 扩展的调度目标。

  8. 点击 Create

    只有在最少选择了三个节点时,才会启用 Create 按钮。

    将创建一个包含三个卷的新存储集群,每个 worker 节点都有一个卷。默认配置使用 3 的复制因子。

若要扩展初始集群的容量,请参阅扩展存储节点

第 2 章 验证 OpenShift Container Storage 部署

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

2.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-* (任意存储节点上的 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 在存储节点间分布)

    RGW

    rook-ceph-rgw-ocs-storagecluster-cephobjectstore-* (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.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-cephcluster
    提供者
    oVirt
    模式
    内部
    Version
    ocs-operator-4.6.0

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

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

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

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

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

    服务名称
    OpenShift Container Storage
    系统名称

    多云对象网关

    RADOS 对象网关

    提供者
    oVirt
    Version
    ocs-operator-4.6.0

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

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

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

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

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

第 3 章 卸载 OpenShift Container Storage

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

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

卸载注解

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

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

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

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

注解默认行为

cleanup-policy

delete

Rook 清理物理驱动器和 DataDirHostPath

cleanup-policy

retain

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

mode

graceful

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

mode

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。

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

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

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

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

      请查看 第 3.4 节 “从 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 退出上述命令。
      • 查找 cryptsetup 进程的 PID,该进程一直卡住。

        $ ps

        输出示例:

        PID     TTY    TIME     CMD
        778825   ?     00:00:00 cryptsetup

        记录要终止的 PID 编号。在本例中,PID778825

      • 使用 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. 如果您使用本地存储设备部署了 OpenShift Container Storage,请删除本地存储 Operator 配置。请参阅删除本地存储 Operator 配置
  9. 取消标记存储节点。

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

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

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

    $ oc delete storageclass openshift-storage.noobaa.io --wait=true --timeout=5m
  13. 删除 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
  14. 在 OpenShift Container Platform Web 控制台中,确保完全卸载 OpenShift Container Storage,

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

3.1.1. 删除本地存储 Operator 配置

只有在使用本地存储设备部署了 OpenShift Container Storage 时,才使用本节中的说明。

注意

对于仅使用 localvolume 资源的 OpenShift Container Storage 部署,请直接转至第 8 步。

流程

  1. 标识 LocalVolumeSet 以及 OpenShift Container Storage 使用的对应 StorageClassName
  2. 将变量 SC 设置为提供 LocalVolumeSetStorageClass

    $ export SC="<StorageClassName>"
  3. 删除 LocalVolumeSet

    $ oc delete localvolumesets.local.storage.openshift.io <name-of-volumeset> -n openshift-local-storage
  4. 删除给定 StorageClassName 的本地存储 PV。

    $ oc get pv | grep $SC | awk '{print $1}'| xargs oc delete pv
  5. 删除 StorageClassName

    $ oc delete sc $SC
  6. 删除 LocalVolumeSet 创建的符号链接。

    [[ ! -z $SC ]] && 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 rm -rfv /mnt/local-storage/${SC}/; done
  7. 删除 LocalVolumeDiscovery

    $ oc delete localvolumediscovery.local.storage.openshift.io/auto-discover-devices -n openshift-local-storage
  8. 删除 LocalVolume 资源(如果有)。

    使用以下步骤删除在当前或以前的 OpenShift Container Storage 版本中置备 PV 的 LocalVolume 资源。此外,确保这些资源不提供给集群上的其他租户使用。

    对于每个本地卷,请执行以下操作:

    1. 标识 LocalVolume 以及 OpenShift Container Storage 使用的对应 StorageClassName
    2. 将变量 LV 设置为 LocalVolume 的名称,变量 SC 设置为 StorageClass 的名称

      例如:

      $ LV=local-block
      $ SC=localblock
    3. 删除本地卷资源。

      $ oc delete localvolume -n local-storage --wait=true $LV
    4. 删除剩余的 PV 和 StorageClasses(如果存在)。

      $ oc delete pv -l storage.openshift.com/local-volume-owner-name=${LV} --wait --timeout=5m
      $ oc delete storageclass $SC --wait --timeout=5m
    5. 从该资源的存储节点中清理工件。

      $ [[ ! -z $SC ]] && 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 rm -rfv /mnt/local-storage/${SC}/; done

      输出示例:

      Starting pod/node-xxx-debug ...
      To use host binaries, run `chroot /host`
      removed '/mnt/local-storage/localblock/nvme2n1'
      removed directory '/mnt/local-storage/localblock'
      
      Removing debug pod ...
      Starting pod/node-yyy-debug ...
      To use host binaries, run `chroot /host`
      removed '/mnt/local-storage/localblock/nvme2n1'
      removed directory '/mnt/local-storage/localblock'
      
      Removing debug pod ...
      Starting pod/node-zzz-debug ...
      To use host binaries, run `chroot /host`
      removed '/mnt/local-storage/localblock/nvme2n1'
      removed directory '/mnt/local-storage/localblock'
      
      Removing debug pod ...

3.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-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

3.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. 从 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 使用所选池创建存储类。

第 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 和 AlertManager 组成。

按照本节中的说明,将 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. 进入 Workloads → Pods
    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 名称,然后在 PersistenVolumeClaim 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. 使用本地存储设备为 OpenShift Container Storage 节点添加容量来扩展存储

使用这个流程将存储容量(额外存储设备)添加到 Red Hat Virtualization 基础架构上基于 OpenShift Container Storage worker 节点配置的本地存储中。

先决条件

  • 您必须登录到 OpenShift Container Platform 集群。
  • 您必须已安装 Local Storage Operator。请参阅安装 Local Storage Operator
  • 如果您已经从以前的 OpenShift Container Storage 版本升级,请创建一个 LocalVolumeSet 对象来启用自动置备设备,如 Post-update 配置更改 中所述。
  • 如果您从以前的版本升级到 OpenShift Container Storage 4.6,请确定您遵循了升级后的步骤来创建 LocalVolumeDiscovery 对象。详情请参阅更新后的配置更改
  • 您必须有三个存储类型和大小相同的 OpenShift Container Platform worker 节点(例如,2TB NVMe 驱动器),与原始 OpenShift Container Storage StorageCluster 创建时相同。

流程

要添加容量,您可以使用部署期间置备的存储类或与过滤器匹配的其它存储类。

  1. 在 OpenShift Web 控制台中,点 OperatorsInstalled Operators

    ocs 安装的 operators
  2. OpenShift Container Storage Operator。
  3. 单击 Storage Cluster 选项卡。

    OCS 存储集群概述
  4. 可见列表中应当只有一个项目。点击最右侧的(⋮)来扩展选项菜单。
  5. 从选项菜单中选择 Add Capacity

    OCS 添加容量对话框菜单 lso
  6. 根据您的要求,选择您添加磁盘或新存储类的存储类。显示的可用容量基于存储类中可用的本地磁盘。
  7. Add

    您可能需要等待几分钟,以便存储集群达到 Ready 状态。

验证步骤

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

    OCS 添加容量扩展验证容量卡 bm

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

  • 验证新 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
重要

OpenShift Container Storage 不支持通过减少 OSD 或减少节点来减少集群。

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

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

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

8.3.1. 使用本地存储设备添加节点

使用这个流程在 Red Hat Virtualization 基础架构上添加节点。

先决条件

  • 您必须登录 OpenShift Container Platform (RHOCP) 集群。
  • 如果您从以前的版本升级到 OpenShift Container Storage 4.6,请确定您遵循了升级后的步骤来创建 LocalVolumeDiscovery 对象。详情请参阅更新后的配置更改
  • 您必须有三个存储类型和大小相同的 OpenShift Container Platform worker 节点(例如,2TB SSD 或 2TB NVMe 驱动器),与原始 OpenShift Container Storage StorageCluster 创建时相同。
  • 如果您已经从以前的 OpenShift Container Storage 版本升级,请创建一个 LocalVolumeSet 对象来启用自动置备设备,如更新后配置更改中所述。

流程

  1. 使用所需基础架构在 Red Hat Virtualization 上创建新虚拟机。查看平台要求
  2. 使用新虚拟机创建新的 OpenShift Container Platform worker 节点。
  3. 检查与处于 Pending 状态的 OpenShift Container Storage 相关的证书签名请求 (CSR):

    $ oc get csr
  4. 为新节点批准所有所需的 OpenShift Container Storage CSR:

    $ oc adm certificate approve <Certificate_Name>
  5. ComputeNodes,确认新节点是否处于 Ready 状态
  6. 使用以下任一方法之一将 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=""
  7. 从 OpenShift Web 控制台中点 OperatorsInstalled Operators

    Project 下拉菜单中选择安装 Local Storage Operator 的项目。

  8. Local Storage
  9. Local Volume Discovery 选项卡
  10. LocalVolumeDiscovery 旁边,点 Action 菜单 (⋮) → Edit Local Volume Discovery
  11. 在 YAML 中,将新节点的主机名添加到 节点选择器下的 values 字段中。
  12. Save
  13. Local Volume Sets 选项卡。
  14. LocalVolumeSet 旁边,点 Action 菜单 (⋮)Edit Local Volume Set
  15. 在 YAML 中,将新节点的主机名添加到节点选择器下的 values 字段中。

    图 8.1. 显示添加新主机名的 YAML

    YAML 屏幕截图,显示新主机名的添加。
  16. Save
注意

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

验证步骤

8.3.2. 验证新节点的添加

  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.3. 扩展存储容量

将新节点添加到 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. 为混合或多云添加存储资源

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

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

为此,请添加 MCG 可以使用的后备存储。

先决条件

  • 下载 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 软件包。

流程

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

    noobaa backingstore create <backing-store-type> <backingstore_name> --access-key=<AWS ACCESS KEY> --secret-key=<AWS SECRET ACCESS KEY> --target-bucket <bucket-name>
    1. <backing-store-type> 替换为您的相关后备存储类型: aws-s3google-cloud-storeazure-blobs3-compatibleibm-cos
    2. <backingstore_name> 替换为后备存储的名称。
    3. <AWS ACCESS KEY><AWS SECRET ACCESS KEY> 替换为您为此创建的 AWS 访问密钥 ID 和 secret 访问密钥。
    4. <bucket-name> 替换为现有的 AWS 存储桶名称。此参数告知 NooBaa 将哪一个存储桶用作其后备存储的目标存储桶,以及数据存储和管理。

      输出结果类似如下:

      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>
    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: noobaa
    spec:
      awsS3:
        secret:
          name: <backingstore-secret-name>
          namespace: noobaa
        targetBucket: <bucket-name>
      type: <backing-store-type>
    1. <bucket-name> 替换为现有的 AWS 存储桶名称。此参数告知 NooBaa 将哪一个存储桶用作其后备存储的目标存储桶,以及数据存储和管理。
    2. <backingstore-secret-name> 替换为上一步中创建的 secret 的名称。
    3. 将 <backing-store-type> 替换为您的相关后备存储类型:aws-s3google-cloud-storeazure-blobs3-compatibleibm-cos

9.3.2. 创建兼容 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
    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.3.3. 使用用户界面为混合和多云添加存储资源

流程

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

    MCG 对象服务 noobaa 链接
  2. 选择左侧的资源选项卡,突出显示下方。从填充的列表中,选择 Add Cloud Resource

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

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

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

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

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

9.3.4. 创建新存储桶类

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 选项卡。

    图 9.1. 带有 Bucket Class 选项卡的 OpenShift Container Storage Operator 页

    包含 Bucket Class 选项卡的 OpenShift Container Storage operator 页面截图。
  4. Create Bucket Class
  5. 在 Create new Bucket Class 页面中,执行以下操作:

    1. 输入 Bucket Class Name 并点 Next

      图 9.2. Create Bucket Class 页

      创建新 bucket 类页面的屏幕截图.
    2. 在放置策略中,选择 Tier 1 - Policy Type 并单击 Next。您可以根据要求选择任一选项。

      • Spread 允许在选定资源之间分散数据。
      • Mirror 允许在选定资源中完全重复数据。
      • 单击 Add Tier 以添加另一个策略层。

        图 9.3. 第 1 层 - 策略类型选择页面

        Tier 1 的截图 - 策略类型选择选项卡。
    3. 如果您选择了 Tier 1 - Policy Type as Spread,请从可用列表中选择 Backing Store 资源,然后单击 Next。或者,您也可以创建新的后备存储

      图 9.4. 第 1 层 - 后端存储选择页面

      层 1 的截图 - 后端存储选择选项卡。
注意

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

  1. 检查并确认 Bucket 类设置。

    图 9.5. bucket 类设置查看页面

    bucket 类设置屏幕截图查看选项卡。
  2. Create Bucket Class

验证步骤

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

9.3.5. 创建新的后备存储

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

先决条件

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

流程

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

    图 9.6. 带有后备存储标签的 OpenShift Container Storage Operator 页

    使用后备存储标签页的 OpenShift Container Storage operator 页截图。
  4. 单击 Create Backing Store

    图 9.7. 创建后端存储页面

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

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

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

      每个后备存储都需要不同的机密。有关为特定后备存储创建 secret 的更多信息,请参阅 第 9.3.1 节 “使用 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. 混合和多云存储桶的镜像数据

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

先决条件

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

流程

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

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

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

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

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

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

  1. 应用以下 YAML。此 YAML 是一个混合示例,在本地 Ceph 存储和 AWS 之间镜像数据:

    apiVersion: noobaa.io/v1alpha1
    kind: BucketClass
    metadata:
      name: hybrid-class
      labels:
        app: noobaa
    spec:
      placementPolicy:
        tiers:
          - tier:
              mirrors:
                - mirror:
                    spread:
                      - cos-east-us
                - mirror:
                    spread:
                      - noobaa-test-bucket-for-ocp201907291921-11247_resource
  2. 将以下行添加到标准 Object Bucket Claim (OBC) 中:

    additionalConfig:
      bucketclass: mirror-to-aws

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

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

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

    MCG 对象服务 noobaa 链接
  2. 点击左侧的存储 图标。您将看到存储桶列表:

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

    MCG 编辑第 1 层资源
  5. 选择 Mirror 并检查您要用于这个存储桶的相关资源。在以下示例中,我们将 prem Ceph RGW 上的数据镜像到 AWS:

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

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

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

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

9.5.1. 关于存储桶策略

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

9.5.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.5.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.5.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.6. 对象 Bucket 声明

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

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

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

9.6.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 访问密钥

9.6.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.6.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.7. 通过添加端点扩展多云对象网关性能

多云对象网关的性能可能因环境而异。在某些情况下,特定的应用需要更快的性能,这可以通过扩展 S3 端点来轻松解决。

Multicloud Object Gateway 资源池是一组 NooBaa 守护进程容器,默认启用两种类型的服务:

  • 存储服务
  • S3 端点服务

9.7.1. Multicloud 对象网关中的 S3 端点

S3 端点是每个多云对象网关默认提供服务,用于处理 Multicloud 对象网关中的繁重数据摘要。端点服务处理内联数据块、重复数据删除、压缩和加密,它接受来自多云对象网关的数据放置指令。

9.7.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 存储资源概述

第 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 Platform 的持久性卷框架启用了这个功能,并允许管理员为集群提供持久性存储。该框架还可让用户在不了解底层存储架构的情况下请求这些资源。

很多存储类型都可用于 OpenShift Container Platform 中的持久性卷。虽然它们都可以由管理员静态置备,但有些类型的存储是使用内置供应商和插件 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 Platform 提供了以下置备程序插件,用于使用集群配置的供应商 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

在多区(multi-zone)配置中,建议在每个 GCE 项目中运行一个 OpenShift Container Platform 集群,以避免在当前集群没有节点的区域中创建 PV。

VMware vSphere

kubernetes.io/vsphere-volume

 
重要

任何选择的置备程序插件还需要根据相关文档为相关的云、主机或者第三方供应商配置。

第 11 章 卷快照

卷快照是集群中特定时间点的存储卷的状态。这些快照有助于更有效地使用存储,不必每次都制作完整的副本,也可用作应用程序开发的构建块。

您可以创建同一持久性卷声明 (PVC) 的多个快照。对于 CephFS,您可以为每个 PVC 创建最多 100 个快照。对于 RADOS 块设备 (RBD),您可以为每个 PVC 创建最多 512 个快照。

注意

您无法计划定期创建快照。

11.1. 创建卷快照

您可以从持久性卷声明 (PVC) 页面或 Volume Snapshots 页面创建卷快照。

先决条件

  • PVC 必须处于 Bound 状态,且不得在使用中。
注意

只有 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 菜单(⋮)→ Restore as new PVC
  4. 输入新 PVC 的名称。
  5. 选择 Storage Class 名。

    注意

    (对于 Rados 块设备 (RBD),您必须选择一个与父 PVC 池相同的存储类。

  6. 单击 Restore。您将被重定向到新的 PVC 详情页面。
从 Volume Snapshots 页面中
  1. 从 OpenShift Web 控制台点 StorageVolume Snapshots
  2. 在所需卷快照旁边,点 Action Menu(⋮)→ Restore as new PVC
  3. 输入新 PVC 的名称。
  4. 选择 Storage Class 名。

    注意

    (对于 Rados 块设备 (RBD),您必须选择一个与父 PVC 池相同的存储类。

  5. 单击 Restore。您将被重定向到新的 PVC 详情页面。
注意

当您恢复卷快照时,只有在父 PVC 存在时,才会使用父 PVC 的访问模式创建 PVC。否则,PVC 只使用 ReadWriteOnce (RWO) 访问模式创建。目前,您无法使用 OpenShift Web 控制台指定访问模式。但是,您可以使用 YAML 从 CLI 指定访问模式。如需更多信息,请参阅恢复卷快照

验证步骤

  • 从 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. 单击 Clone。您将被重定向到新的 PVC 详情页面。

    注意

    克隆使用父 PVC 的访问模式创建。目前,您无法使用 OpenShift Web 控制台 UI 指定访问模式。但是,您可以使用 YAML 从 CLI 指定访问模式。如需更多信息,请参阅置备 CSI 卷克隆

  5. 等待克隆的 PVC 状态变为 Bound

    克隆的 PVC 现在可以被 pod 使用。这个克隆的 PVC 独立于其 dataSource PVC。

第 13 章 替换存储节点

13.1. 在 Red Hat Virtualization 安装程序置备的基础架构中替换操作节点

使用这个流程替换 Red Hat Virtualization 安装程序置备的基础架构 (IPI) 上的操作节点。

先决条件

  • 红帽建议为替换节点配置类似的基础架构和资源,以用于被替换的节点。
  • 您必须登录 OpenShift Container Platform (RHOCP) 集群。

流程

  1. 登录 OpenShift Web 控制台并点击 Compute → Nodes
  2. 确定需要替换的节点。记录它的机器名称。
  3. 在要替换的节点上获取标签。

    $ oc get nodes --show-labels | grep <node_name>
  4. 识别要替换的节点中运行的 mon(若有)和 OSD。

    $ oc get pods -n openshift-storage -o wide | grep -i <node_name>
  5. 缩减上一步中确定的容器集部署。

    例如:

    $ oc scale deployment rook-ceph-mon-c --replicas=0 -n openshift-storage
    $ oc scale deployment rook-ceph-osd-0 --replicas=0 -n openshift-storage
    $ oc scale deployment --selector=app=rook-ceph-crashcollector,node_name=<node_name>  --replicas=0 -n openshift-storage
  6. 将节点标记为不可调度。

    $ oc adm cordon <node_name>
  7. 排空节点。

    $ oc adm drain <node_name> --force --delete-local-data --ignore-daemonsets
  8. Compute → Machines。搜索所需的机器。
  9. 除了所需的机器外,点击 Action 菜单(⋮)→ Delete Machine
  10. 单击 Delete 以确认删除机器。会自动创建新机器。
  11. 等待新计算机启动并过渡到 Running 状态。

    重要

    此活动可能需要至少 5 到 10 分钟或更长时间。

  12. 在 OpenShift Web 控制台中点 Compute → Nodes。确认新节点是否处于 Ready 状态。
  13. 使用以下任一方法之一将 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=""
  14. 将 worker 节点上可用的本地存储设备添加到 OpenShift Container Storage StorageCluster。

    1. 决定要编辑的 localVolumeSet

      在以下命令中,将 local-storage-project 替换为您的本地存储项目的名称。在 OpenShift Container Storage 4.6 及更高版本中,默认项目名称为 openshift-local-storage。之前的版本默认使用 local-storage

      # oc get -n local-storage-project localvolumeset
      NAME          AGE
      localblock   25h
    2. 将新节点添加到 localVolumeSet 定义中。

      # oc edit -n local-storage-project localvolumeset localblock
      [...]
         nodeSelector:
          nodeSelectorTerms:
            - matchExpressions:
                - key: kubernetes.io/hostname
                  operator: In
                  values:
                  - server1.example.com
                  - server2.example.com
               #  - server3.example.com
                  - newnode.example.com
      [...]

      记住在退出编辑器之前进行保存。

  15. 验证新的 localblock PV 是否可用。

    $ oc get pv | grep localblock
              CAPA- ACCESS RECLAIM                                STORAGE
    NAME      CITY  MODES  POLICY  STATUS     CLAIM               CLASS       AGE
    local-pv- 931Gi  RWO   Delete  Bound      openshift-storage/  localblock  25h
    3e8964d3                                  ocs-deviceset-2-0
                                              -79j94
    local-pv- 931Gi  RWO   Delete  Bound      openshift-storage/  localblock  25h
    414755e0                                  ocs-deviceset-1-0
                                              -959rp
    local-pv- 931Gi RWO Delete Available localblock 3m24s b481410
    local-pv- 931Gi  RWO   Delete  Bound      openshift-storage/  localblock  25h
    d9c5cbd6                                  ocs-deviceset-0-0
                                              -nvs68
  16. 更改到 openshift-storage 项目。

    $ oc project openshift-storage
  17. 从集群移除出现故障的 OSD。

    $ oc process -n openshift-storage ocs-osd-removal \
    -p FAILED_OSD_IDS=failed-osd-id1,failed-osd-id2 | oc create -f -
  18. 通过检查 ocs-osd-removal pod 的状态,验证 OSD 是否已成功移除。

    状态为 Completed,确认 OSD 移除作业已成功。

    # oc get pod -l job-name=ocs-osd-removal-failed-osd-id -n openshift-storage
    注意

    如果 ocs-osd-removal 失败且 pod 不处于预期的 Completed 状态,请检查 pod 日志以进一步调试。例如:

    # oc logs -l job-name=ocs-osd-removal-failed-osd_id -n openshift-storage --tail=-1
  19. 删除与故障节点关联的 PV。

    1. 标识与 PVC 关联的 PV。

      # oc get -n openshift-storage pvc claim-name

      例如:

      # oc get -n openshift-storage pvc ocs-deviceset-0-0-nvs68
                                                  ACCESS STORAGE
      NAME           STATUS    VOLUME    CAPACITY MODES  CLASS      AGE
      ocs-deviceset- Released  local-pv- 931Gi    RWO    localblock 24h
      0-0-nvs68                d9c5cbd6
    2. 删除 PV:

      # oc delete pv <persistent-volume>

      例如:

      # oc delete pv local-pv-d9c5cbd6
      persistentvolume "local-pv-d9c5cbd6" deleted
  20. 删除 crashcollector pod 部署。

    $ oc delete deployment --selector=app=rook-ceph-crashcollector,node_name=failed-node-name -n openshift-storage
  21. 通过重启 rook-ceph-operator 来强制 Operator 协调,从而部署新的 OSD。

    # oc get -n openshift-storage pod -l app=rook-ceph-operator

    输出示例:

    NAME                                  READY   STATUS    RESTARTS   AGE
    rook-ceph-operator-6f74fb5bff-2d982   1/1     Running   0          1d20h
    1. 删除 rook-ceph-operator

      # oc delete -n openshift-storage pod rook-ceph-operator-6f74fb5bff-2d982

      输出示例:

      pod "rook-ceph-operator-6f74fb5bff-2d982" deleted
    2. 验证 rook-ceph-operator pod 是否已重启。

      # oc get -n openshift-storage pod -l app=rook-ceph-operator

      输出示例:

      NAME                                  READY   STATUS    RESTARTS   AGE
      rook-ceph-operator-6f74fb5bff-7mvrq   1/1     Running   0          66s

      创建新 OSD 和 mon 可能需要几分钟时间,然后再重新启动 operator。

  22. 删除 ocs-osd-removal 任务。

    # oc delete job ocs-osd-removal-${osd_id_to_remove}

    输出示例:

    job.batch "ocs-osd-removal-0" deleted

验证步骤

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

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

    • csi-cephfsplugin-*
    • csi-rbdplugin-*
  3. 验证所有其他所需的 OpenShift Container Storage Pod 是否都处于 Running 状态。

    确保创建了新的增量 mon,并处于 Running 状态。

    $ oc get pod -n openshift-storage | grep mon

    输出示例:

    rook-ceph-mon-c-64556f7659-c2ngc                                  1/1     Running     0          6h14m
    rook-ceph-mon-d-7c8b74dc4d-tt6hd                                  1/1     Running     0          4h24m
    rook-ceph-mon-e-57fb8c657-wg5f2                                   1/1     Running     0          162m

    OSD 和 Mon 可能需要几分钟才能进入 Running 状态。

  4. 验证新 OSD pod 是否在替换节点上运行。

    $ oc get pods -o wide -n openshift-storage| egrep -i new-node-name | egrep osd
  5. (可选)如果在集群中启用了数据加密,请验证新 OSD 设备是否已加密。

    对于上一步中标识的每个新节点,请执行以下操作:

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

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

      $ lsblk
  6. 如果验证步骤失败,请联系红帽支持

13.2. 在 Red Hat Virtualization 安装程序置备的基础架构中替换失败的节点

当实例关闭时,Red Hat Virtualization 用于 OpenShift Container Storage 的临时存储可能会导致数据丢失。使用这个流程从 Red Hat Virtualization 平台上关闭的实例电源中恢复。

先决条件

  • 红帽建议为替换节点配置类似的基础架构和资源,以用于被替换的节点。
  • 您必须登录 OpenShift Container Platform (RHOCP) 集群。

流程

  1. 登录 OpenShift Web 控制台并点击 Compute → Nodes
  2. 确定需要替换的节点。记录它的机器名称。
  3. 获取要替换节点上的标签。

    $ oc get nodes --show-labels | grep <node_name>
  4. 识别要替换的节点中运行的 mon(若有)和 OSD。

    $ oc get pods -n openshift-storage -o wide | grep -i <node_name>
  5. 缩减上一步中确定的容器集部署。

    例如:

    $ oc scale deployment rook-ceph-mon-c --replicas=0 -n openshift-storage
    $ oc scale deployment rook-ceph-osd-0 --replicas=0 -n openshift-storage
    $ oc scale deployment --selector=app=rook-ceph-crashcollector,node_name=<node_name>  --replicas=0 -n openshift-storage
  6. 将节点标记为不可调度。

    $ oc adm cordon <node_name>
  7. 删除处于 Terminating 状态的 pod。

    $ oc get pods -A -o wide | grep -i <node_name> |  awk '{if ($4 == "Terminating") system ("oc -n " $1 " delete pods " $2  " --grace-period=0 " " --force ")}'
  8. 排空节点。

    $ oc adm drain <node_name> --force --delete-local-data --ignore-daemonsets
  9. Compute → Machines。搜索所需的机器。
  10. 除了所需的机器外,点击 Action 菜单(⋮)→ Delete Machine
  11. 单击 Delete 以确认删除机器。会自动创建新机器。
  12. 等待新计算机启动并过渡到 Running 状态。

    重要

    此活动可能需要至少 5 到 10 分钟或更长时间。

  13. 在 OpenShift Web 控制台中点 Compute → Nodes。确认新节点是否处于 Ready 状态。
  14. 使用以下任一方法之一将 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=""
  15. 将新 worker 节点上可用的本地存储设备添加到 OpenShift Container Storage StorageCluster。
  16. 将 worker 节点上可用的本地存储设备添加到 OpenShift Container Storage StorageCluster。

    1. 决定要编辑的 localVolumeSet

      在以下命令中,将 local-storage-project 替换为您的本地存储项目的名称。在 OpenShift Container Storage 4.6 及更高版本中,默认项目名称为 openshift-local-storage。之前的版本默认使用 local-storage

      # oc get -n local-storage-project localvolumeset
      NAME          AGE
      localblock   25h
    2. 将新节点添加到 localVolumeSet 定义中。

      # oc edit -n local-storage-project localvolumeset localblock
      [...]
         nodeSelector:
          nodeSelectorTerms:
            - matchExpressions:
                - key: kubernetes.io/hostname
                  operator: In
                  values:
                  - server1.example.com
                  - server2.example.com
               #  - server3.example.com
                  - newnode.example.com
      [...]

      记住在退出编辑器之前进行保存。

  17. 验证新的 localblock PV 是否可用。

    $ oc get pv | grep localblock
              CAPA- ACCESS RECLAIM                                STORAGE
    NAME      CITY  MODES  POLICY  STATUS     CLAIM               CLASS       AGE
    local-pv- 931Gi  RWO   Delete  Bound      openshift-storage/  localblock  25h
    3e8964d3                                  ocs-deviceset-2-0
                                              -79j94
    local-pv- 931Gi  RWO   Delete  Bound      openshift-storage/  localblock  25h
    414755e0                                  ocs-deviceset-1-0
                                              -959rp
    local-pv- 931Gi RWO Delete Available localblock 3m24s b481410
    local-pv- 931Gi  RWO   Delete  Bound      openshift-storage/  localblock  25h
    d9c5cbd6                                  ocs-deviceset-0-0
                                              -nvs68
  18. 更改到 openshift-storage 项目。

    $ oc project openshift-storage
  19. 从集群移除出现故障的 OSD。

    $ oc process -n openshift-storage ocs-osd-removal \
    -p FAILED_OSD_IDS=failed-osd-id1,failed-osd-id2 | oc create -f -
  20. 通过检查 ocs-osd-removal pod 的状态,验证 OSD 是否已成功移除。

    状态为 Completed,确认 OSD 移除作业已成功。

    # oc get pod -l job-name=ocs-osd-removal-failed-osd-id -n openshift-storage
    注意

    如果 ocs-osd-removal 失败且 pod 不处于预期的 Completed 状态,请检查 pod 日志以进一步调试。例如:

    # oc logs -l job-name=ocs-osd-removal-failed-osd_id -n openshift-storage --tail=-1
  21. 删除与故障节点关联的 PV。

    1. 标识与 PVC 关联的 PV。

      # oc get -n openshift-storage pvc claim-name

      例如:

      # oc get -n openshift-storage pvc ocs-deviceset-0-0-nvs68
                                                  ACCESS STORAGE
      NAME           STATUS    VOLUME    CAPACITY MODES  CLASS      AGE
      ocs-deviceset- Released  local-pv- 931Gi    RWO    localblock 24h
      0-0-nvs68                d9c5cbd6
    2. 删除 PV:

      # oc delete pv <persistent-volume>

      例如:

      # oc delete pv local-pv-d9c5cbd6
      persistentvolume "local-pv-d9c5cbd6" deleted
  22. 删除 crashcollector pod 部署。

    $ oc delete deployment --selector=app=rook-ceph-crashcollector,node_name=failed-node-name -n openshift-storage
  23. 通过重启 rook-ceph-operator 来强制 Operator 协调,从而部署新的 OSD。

    # oc get -n openshift-storage pod -l app=rook-ceph-operator

    输出示例:

    NAME                                  READY   STATUS    RESTARTS   AGE
    rook-ceph-operator-6f74fb5bff-2d982   1/1     Running   0          1d20h
    1. 删除 rook-ceph-operator

      # oc delete -n openshift-storage pod rook-ceph-operator-6f74fb5bff-2d982

      输出示例:

      pod "rook-ceph-operator-6f74fb5bff-2d982" deleted
    2. 验证 rook-ceph-operator pod 是否已重启。

      # oc get -n openshift-storage pod -l app=rook-ceph-operator

      输出示例:

      NAME                                  READY   STATUS    RESTARTS   AGE
      rook-ceph-operator-6f74fb5bff-7mvrq   1/1     Running   0          66s

      创建新 OSD 和 mon 可能需要几分钟时间,然后再重新启动 operator。

  24. 删除 'ocs-osd-removal' 任务。

    # oc delete job ocs-osd-removal-${osd_id_to_remove}

    输出示例:

    job.batch "ocs-osd-removal-0" deleted

验证步骤

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

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

    • csi-cephfsplugin-*
    • csi-rbdplugin-*
  3. 验证所有其他所需的 OpenShift Container Storage Pod 是否都处于 Running 状态。

    确保创建了新的增量 mon,并处于 Running 状态。

    $ oc get pod -n openshift-storage | grep mon

    输出示例:

    rook-ceph-mon-c-64556f7659-c2ngc                                  1/1     Running     0          6h14m
    rook-ceph-mon-d-7c8b74dc4d-tt6hd                                  1/1     Running     0          4h24m
    rook-ceph-mon-e-57fb8c657-wg5f2                                   1/1     Running     0          162m

    OSD 和 Mon 可能需要几分钟才能进入 Running 状态。

  4. 验证新 OSD pod 是否在替换节点上运行。

    $ oc get pods -o wide -n openshift-storage| egrep -i new-node-name | egrep osd
  5. (可选)如果在集群中启用了数据加密,请验证新 OSD 设备是否已加密。

    对于上一步中标识的每个新节点,请执行以下操作:

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

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

      $ lsblk
  6. 如果验证步骤失败,请联系红帽支持

第 14 章 在 Red Hat Virtualization 平台上替换失败的存储设备

当您需要替换 Red Hat Virtualization 平台上的存储设备时,您必须替换该存储节点。有关如何替换节点的详情,请参考在 Red Hat Virtualization 平台上替换失败的存储节点

第 15 章 更新 OpenShift Container Storage

15.1. OpenShift Container Storage 更新过程概述

您可以在次版本(如 4.5 和 4.6)间升级 Red Hat OpenShift Container Storage 及其组件,也可以在 4.6.0 和 4.6.1 等批处理更新之间升级。

您需要以特定的顺序升级 OpenShift Container Storage 的不同部分。

  1. 根据 OpenShift Container Platform 更新集群文档更新 OpenShift Container Platform。
  2. 更新 OpenShift 容器平台存储.

    1. 使用适合您的设置的流程更新 OpenShift Container Storage operator

    2. 如果使用本地存储:

      1. 更新 Local Storage operator

        如果您不确定,请参阅检查 Local Storage Operator 部署

      2. 为由本地存储支持的集群执行更新后配置更改

        详情请参阅由本地存储支持的集群的 Post-update 配置

更新注意事项

开始之前,请先查阅以下重要注意事项:

  • 红帽建议在 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.6 \
      --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.5.X 或 4.6.Y 的最新稳定版本,请参阅 更新集群
  • 将 Red Hat OpenShift Container Storage 频道从 stable-4.5 切换到 stable-4.6。有关频道的详情,请参阅 OpenShift Container Storage 升级频道和发行版本

    注意

    只有在您更新次版本(例如从 4.5 更新至 4.6)且不需要在 4.6 的批处理更新之间更新时(例如从 4.6.0 更新至 4.6.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

验证步骤

  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.5 更新至 4.6 后,此处的 Version 字段仍将显示 4.5。这是因为 ocs-operator 不会更新此字段中代表的字符串。

  4. 确保所有 OpenShift Container Storage Pod(包括 Operator Pod)在 openshift-storage 命名空间中 处于 Running 状态。

    要查看 pod 的状态,请点击 WorkloadsPods。从 Project 下拉列表中,选择 openshift-storage

  5. 如果验证步骤失败,请联系红帽支持

其它资源

如果您在更新 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.5.X 或 4.6.Y 的最新稳定版本,请参阅 更新集群
  • 将 Red Hat OpenShift Container Storage 频道从 stable-4.5 切换到 stable-4.6。有关频道的详情,请参阅 OpenShift Container Storage 升级频道和发行版本

    注意

    只有在您更新次版本(例如从 4.5 更新至 4.6)且不需要在 4.6 的批处理更新之间更新时(例如从 4.6.0 更新至 4.6.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

验证步骤

  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.5 更新至 4.6 后,此处的 Version 字段仍将显示 4.5。这是因为 ocs-operator 不会更新此字段中代表的字符串。

  4. 确保所有 OpenShift Container Storage Pod(包括 Operator Pod)在 openshift-storage 命名空间中 处于 Running 状态。

    要查看 pod 的状态,请点击 OpenShift Web 控制台左侧窗格中的 WorkloadsPods。从 Project 下拉列表中,选择 openshift-storage

  5. 如果验证步骤失败,请联系红帽支持

其它资源

如果您在更新 OpenShift Container Storage 时遇到任何问题,请参阅故障排除指南中的常见的进行故障排除所需的日志部分。

15.4. 更新后配置更改

在某些情况下,更新后还需要额外的配置步骤,以确保所有功能都能按预期工作。

15.4.1. 由本地存储支持的集群更新后配置

在 Red Hat OpenShift Container Platform 4.6 及之后,Local Storage operator 提供了新的自定义资源类型来管理本地存储:

  • LocalVolumeDiscovery
  • LocalVolumeSet

这些资源类型不会作为之前版本更新的一部分自动处理,必须手动创建。

15.4.1.1. 使用命令行创建 LocalVolumeDiscovery 自定义资源

创建 LocalVolumeDiscovery 自定义资源,以确保设备管理用户界面可以发现本地设备的状态,并提供有关集群节点中可用设备的信息。

先决条件

  • 对 OpenShift Container Platform 集群的管理访问权限。

流程

  1. 更改到安装有 Local Storage operator 的项目。

    $ oc project local-storage-project

    local-storage-project 替换为 Local Storage 项目的名称。

    在版本 4.5 及更早版本中,默认本地存储项目的名称为 local-storage。在版本 4.6 及更新的版本中,默认本地存储项目的名称为 openshift-local-storage

  2. 定义 LocalVolumeDiscovery 自定义资源。

    例如,在 local-volume-discovery.yaml 文件中定义以下内容:

    apiVersion: local.storage.openshift.io/v1alpha1
    kind: LocalVolumeDiscovery
    metadata:
      name: auto-discover-devices
    spec:
      nodeSelector:
        nodeSelectorTerms:
          - matchExpressions:
              - key: kubernetes.io/hostname
                operator: In
                values:
                  - worker1.example.com
                  - worker2.example.com
                  - worker3.example.com
  3. 创建 LocalVolumeDiscovery 自定义资源。

    $ oc create -f local-volume-discovery.yaml

验证步骤

  1. 登录 OpenShift Web 控制台。
  2. ComputeNode,然后点击节点的名称。
  3. 点击 Disks 选项卡,检查您是否可以看到该节点上可用的设备。

15.4.1.2. 使用命令行创建 LocalVolumeSet 自定义资源

创建 LocalVolumeSet 自定义资源,根据您指定的条件自动将某些存储设备置备为持久性卷。对于任何符合 nodeSelector 条件的节点中的 deviceInclusionSpec 条件的设备都会创建持久性卷。

先决条件

  • 对 OpenShift Container Platform 集群的管理访问权限。

流程

  1. local-volume-set.yaml 文件中定义 LocalVolumeSet 自定义资源。

    apiVersion: local.storage.openshift.io/v1alpha1
    kind: LocalVolumeSet
    metadata:
      name: localblock
    spec:
      nodeSelector:
        nodeSelectorTerms:
          - matchExpressions:
              - key: kubernetes.io/hostname
                operator: In
                values:
                  - worker1.example.com
                  - worker2.example.com
                  - worker3.example.com
      storageClassName: localblock
      volumeMode: Block
      maxDeviceCount: 10 # optional, limit devices provisioned per node
      deviceInclusionSpec:
        deviceTypes: # list of types to allow
          - disk
          - part # omit this to use only whole devices
        deviceMechanicalProperty:
          - NonRotational
        minSize: 100Gi # optional, minimum size of device to allow
        maxSize: 100Ti # optional, maximum size of device to allow
        models: # (optional) list of models to allow
          - SAMSUNG
          - Crucial_CT525MX3
        vendors: # (optional) list of device vendors to allow
          - ATA
          - ST2000LM

    以上的定义会选择特定模式的非轮换设备上的整个磁盘或分区,它们的大小在 100 GB 和 100 TB 之间,由特定厂商提供,来自 worker1worker2worker3 节点。创建 localblock 存储类,并从发现的设备置备持久性卷。

    重要

    minSize 选择一个适当的值,以确保未选择系统分区。

  2. 创建 LocalVolumeSet

    $ oc create -f local-volume-set.yaml

验证步骤

  1. 使用以下命令,跟踪与 deviceInclusionSpec 匹配的设备的持久性卷置备。调配持久卷可能需要几分钟时间。

    $ oc describe localvolumeset localblock
    [...]
    Status:
      Conditions:
        Last Transition Time:          2020-11-17T05:03:32Z
        Message:                       DiskMaker: Available, LocalProvisioner: Available
        Status:                        True
        Type:                          DaemonSetsAvailable
        Last Transition Time:          2020-11-17T05:03:34Z
        Message:                       Operator reconciled successfully.
        Status:                        True
        Type:                          Available
      Observed Generation:             1
      Total Provisioned Device Count: 4
    Events:
    Type    Reason      Age          From                Message
    ----    ------      ----         ----                -------
    Normal  Discovered  2m30s (x4    localvolumeset-     ip-10-0-147-124.us-east-
            NewDevice   over 2m30s)  symlink-controller  2.compute.internal -
                                                         found possible matching
                                                         disk, waiting 1m to claim
    Normal  FoundMatch  89s (x4      localvolumeset-     ip-10-0-147-124.us-east-
            ingDisk     over 89s)    symlink-controller  2.compute.internal -
                                                         symlinking matching disk
  2. 验证调配的持久卷的状态。

    $ oc get pv
                         ACCESS   RECLAIM             STORAGE
    NAME       CAPACITY  MODES    POLICY   STATUS     CLASS       AGE
    local-pv-  500Gi     RWO      Delete   Available  localblock  7m48s
    3584969f
    local-pv-  500Gi     RWO      Delete   Available  localblock  7m48s
    3aee84fa
    local-pv-  500Gi     RWO      Delete   Available  localblock  7m48s
    644d09ac
    local-pv-  500Gi     RWO      Delete   Available  localblock  7m48s
    c73cee1

15.4.1.3. 添加注解

从以前的版本升级到 OpenShift Container Storage 4.6 时,使用此流程为存储集群添加注解,以通过用户界面启用替换失败存储设备。

流程

  1. 登录 OpenShift Container Platform Web 控制台。
  2. HomeSearch
  3. Resources 中搜索 StorageCluster 并点击它。
  4. ocs-storagecluster 旁边,点 Action 菜单 (⋮)Edit annotations
  5. KEYVALUE 添加 cluster.ocs.openshift.io/local-devicestrue
  6. Save