使用 Google Cloud 部署和管理 OpenShift Data Foundation


Red Hat OpenShift Data Foundation 4.10

在现有 Red Hat OpenShift Container Platform Google Cloud 集群上部署和管理 OpenShift Data Foundation 的说明

Red Hat Storage Documentation Team

摘要

请阅读本文档,了解如何使用 Google Cloud 上的 Red Hat OpenShift Container Platform 安装和管理 Red Hat OpenShift Data Foundation。
重要
Deploying and managing OpenShift Data Foundation on Google Cloud is a Technology Preview feature. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

使开源包含更多

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

对红帽文档提供反馈

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

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

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

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

前言

Red Hat OpenShift Data Foundation 支持在现有 Red Hat OpenShift Container Platform(RHOCP)Google Cloud 集群上部署。

注意

Google Cloud 上仅支持内部 OpenShift 数据基础集群。如需有关部署要求的更多信息,请参阅规划部署

要以内部模式部署 OpenShift 数据基础,请从 准备部署 OpenShift 数据基础 章节的要求开始,并根据您的要求遵循适当的部署流程:

第 1 章 准备部署 OpenShift 数据基础

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

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

  1. 可选:如果要使用外部密钥管理系统(KMS)启用集群范围加密,请按照以下步骤执行:

  2. 启动节点最低要求

    当不符合标准部署资源要求时,将使用最低配置部署 OpenShift Data Foundation 集群。请参阅规划指南中的资源要求部分。

  3. region-DR 要求 [Developer preview]

    Red Hat OpenShift Data Foundation 支持的灾难恢复功能需要满足以下所有先决条件,才能成功实施灾难恢复解决方案:

    有关详细要求,请参阅 Regional-DR 要求RHACM 要求

第 2 章 在 Google Cloud 上部署 OpenShift Data Foundation

您可以使用 Google Cloud 安装程序置备的基础架构提供的动态存储设备在 OpenShift Container Platform 上部署 OpenShift Data Foundation。这可让您创建内部集群资源,并导致在内部置备基础服务,这有助于为应用程序提供额外的存储类。

另外,可以使用 OpenShift Data Foundation 仅部署多云对象网关(MCG)组件。如需更多信息,请参阅 部署独立多云对象网关

注意

Google Cloud 上仅支持内部 OpenShift Data Foundation 集群。如需有关部署要求的更多信息,请参阅规划部署

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

2.1. 安装 Red Hat OpenShift Data Foundation Operator

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

先决条件

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

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

流程

  1. 登录 OpenShift Web 控制台。
  2. Operators → OperatorHub
  3. Filter by keyword 框中滚动或键入 OpenShift Data Foundation,以查找 OpenShift Data Foundation Operator。
  4. Install
  5. Install Operator 页面中设置以下选项:

    1. 将 Channel 更新为 stable-4.10
    2. 安装模式是 A specific namespace on the cluster
    3. Installed Namespace 为 Operator recommended namespace openshift-storage。如果命名空间 openshift-storage 不存在,它会在 Operator 安装过程中创建。
    4. 将 Approval Strategy 选为 AutomaticManual

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

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

    5. 确保为 Console 插件 选择了 Enable 选项。
    6. Install

验证步骤

  • 验证 OpenShift Data Foundation Operator 是否显示绿色勾号(代表安装成功)。
  • 成功安装 Operator 后,用户界面中会显示一个带有 Web console update is available 信息的弹出窗口。点这个弹出窗口中的 Refresh web console 来反映控制台的更改。

    • 在 Web 控制台中,导航到 Operators,并验证 OpenShift Data Foundation 是否可用。

2.2. 使用 Token 验证方法通过 KMS 启用集群范围的加密

要在 Vault 中为 Token 身份验证启用键值后端路径和策略,请按照以下步骤执行:

先决条件

流程

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

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

    $ vault secrets enable -path=odf kv

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

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

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

    $ vault token create -policy=odf -format json

2.3. 使用 Kubernetes 身份验证方法通过 KMS 启用集群范围的加密

您可以使用密钥管理系统(KMS)为集群范围的加密启用 Kubernetes 验证方法。

先决条件

  • 管理员对 Vault 的访问权限。
  • 有效的 Red Hat OpenShift Data Foundation 高级订阅。如需更多信息,请参阅 OpenShift Data Foundation 订阅中的知识库文章
  • OpenShift Data Foundation 操作器必须从 Operator Hub 安装。
  • 选择唯一路径名称作为后端 路径,该路径 遵循命名约定,因为以后无法更改它。

    注意

    OpenShift Data Foundation 4.10 中的 Kubernetes 验证方法不支持 Vault 命名空间

流程

  1. 创建服务帐户:

    $ oc -n openshift-storage create serviceaccount <serviceaccount_name>

    其中, <serviceaccount_name> 指定服务帐户的名称。

    例如:

    $ oc -n openshift-storage create serviceaccount odf-vault-auth
  2. 创建 clusterrolebindingsclusterroles:

    $ oc -n openshift-storage create clusterrolebinding vault-tokenreview-binding --clusterrole=system:auth-delegator --serviceaccount=openshift-storage:_<serviceaccount_name>_

    例如:

    $ oc -n openshift-storage create clusterrolebinding vault-tokenreview-binding --clusterrole=system:auth-delegator --serviceaccount=openshift-storage:odf-vault-auth
  3. 根据 OpenShift Container Platform 版本,执行以下任一操作:

    • 对于 OpenShift Container Platform 4.10:

      • 识别与上面创建的 serviceaccount(SA)关联的 secret 名称。

        $ VAULT_SA_SECRET_NAME=$(oc -n openshift-storage get sa <SA_NAME> -o jsonpath="{.secrets[*]['name']}") | grep -o "[^[:space:]]*-token-[^[:space:]]*"

        例如:

        $ VAULT_SA_SECRET_NAME=$(oc -n openshift-storage get sa odf-vault-auth -o jsonpath="{.secrets[*]['name']}" | grep -o "[^[:space:]]*-token-[^[:space:]]*")
    • 对于 OpenShift Container Platform 4.11:

      • serviceaccount 令牌和 CA 证书创建 secret。

        $ cat <<EOF | oc create -f -
        apiVersion: v1
        kind: Secret
        metadata:
          name: odf-vault-auth-token
          namespace: openshift-storage
          annotations:
            kubernetes.io/service-account.name: <serviceaccount_name>
        type: kubernetes.io/service-account-token
        data: {}
        EOF

        其中,<serviceaccount_name> 是上一步中创建的服务帐户。

        $ VAULT_SA_SECRET_NAME=odf-vault-auth-token
  4. 从 secret 获取令牌和 CA 证书。

    $ SA_JWT_TOKEN=$(oc -n openshift-storage get secret "$VAULT_SA_SECRET_NAME" -o jsonpath="{.data.token}" | base64 --decode; echo)
    $ SA_CA_CRT=$(oc -n openshift-storage get secret "$VAULT_SA_SECRET_NAME" -o jsonpath="{.data['ca\.crt']}" | base64 --decode; echo)
  5. 检索 OCP 集群端点。

    $ OCP_HOST=$(oc config view --minify --flatten -o jsonpath="{.clusters[0].cluster.server}")
  6. 获取服务帐户签发者。

    $ oc proxy &
    $ proxy_pid=$!
    $ issuer="$( curl --silent http://127.0.0.1:8001/.well-known/openid-configuration | jq -r .issuer)"
    $ kill $proxy_pid
  7. 使用以上步骤中收集的信息,在 Vault 中设置 Kubernetes 验证方法,如下所示。

    $ vault auth enable kubernetes
    $ vault write auth/kubernetes/config \
              token_reviewer_jwt="$SA_JWT_TOKEN" \
              kubernetes_host="$OCP_HOST" \
              kubernetes_ca_cert="$SA_CA_CRT" \
              issuer="$issuer"
    重要

    当签发者为空时,在 Vault 中配置 Kubernetes 身份验证方法。

    $ vault write auth/kubernetes/config \
              token_reviewer_jwt="$SA_JWT_TOKEN" \
              kubernetes_host="$OCP_HOST" \
              kubernetes_ca_cert="$SA_CA_CRT"
  8. 在 Vault 中启用 Key/Value(KV)后端路径。

    对于 Vault KV secret engine API,版本 1。

    $ vault secrets enable -path=odf kv

    对于 Vault KV secret engine API,版本 2。

    $ vault secrets enable -path=odf kv-v2
  9. 创建策略来限制用户在 secret 上执行写入或删除操作:

    echo '
    path "odf/*" {
      capabilities = ["create", "read", "update", "delete", "list"]
    }
    path "sys/mounts" {
    capabilities = ["read"]
    }'| vault policy write odf -
  10. 生成角色:

    $ vault write auth/kubernetes/role/odf-rook-ceph-op \
            bound_service_account_names=rook-ceph-system,rook-ceph-osd,noobaa \
            bound_service_account_namespaces=openshift-storage \
            policies=odf \
            ttl=1440h

    在创建存储系统期间配置 KMS 连接详情时,会稍后使用角色 odf-rook-ceph-op

    $ vault write auth/kubernetes/role/odf-rook-ceph-osd \
            bound_service_account_names=rook-ceph-osd \
            bound_service_account_namespaces=openshift-storage \
            policies=odf \
            ttl=1440h

2.4. 创建 OpenShift Data Foundation 集群

安装 OpenShift Data Foundation 操作器(operator)后,创建 OpenShift Data Foundation。

先决条件

  • OpenShift Data Foundation 操作器必须从 Operator Hub 安装。如需更多信息,请参阅 安装 OpenShift Data Foundation Operator
  • 请注意,Google Cloud 平台的默认存储类使用硬盘(HDD)。要使用基于固态驱动器 (SSD) 的磁盘来提高性能,您需要使用 pd-ssd 创建存储类,如以下 ssd-storeageclass.yaml 示例所示:

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
     name: faster
    provisioner: kubernetes.io/gce-pd
    parameters:
     type: pd-ssd
    volumeBindingMode: WaitForFirstConsumer
    reclaimPolicy: Delete

流程

  1. 在 OpenShift Web 控制台中,点 Operators → Installed Operators 查看所有已安装的 Operator。

    确保所选 项目openshift-storage

  2. OpenShift Data Foundation 操作器,然后单击 Create StorageSystem
  3. Backing storage 页面中,选择以下内容:

    1. Deployment 类型选项选择 Full Deployment
    2. 选择 Use a existing StorageClass 选项。
    3. 选择 Storage Class

      默认情况下,它被设置为标准。但是,如果您创建了存储类以使用 SSD 的磁盘来提高性能,则需要选择该存储类。

    4. Next
  4. Capacity and nodes 页面中,提供必要的信息:

    1. 从下拉列表中选择 Requested Capacity 的值。默认设置为 2 TiB

      注意

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

    2. Select Nodes 部分中,选择至少三个可用节点。
    3. 可选:选中 Taint nodes 复选框,以将所选节点专用于 OpenShift Data Foundation。

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

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

    4. Next
  5. 可选:在 Security and network 页面中,根据您的要求进行配置:

    1. 若要启用加密,可选择为块存储和文件存储启用数据加密。
    2. 选择其中一个加密级别或两个都选:

      • 集群范围的加密

        加密整个集群(块和文件)。

      • StorageClass 加密

        使用启用加密的存储类创建加密的持久性卷(仅块)。

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

      1. 默认情况下,Key Management Service Provider 设置为 Vault
      2. 选择身份验证方法

        使用令牌验证方法
        • 输入唯一的连接名称 , Vault 服务器的主机地址('https://<hostname 或 ip>'),端口号和令牌
        • 展开 Advanced Settings,以根据您的 Vault 配置输入其他设置和证书详情。

          • 后端路径中输入为 OpenShift Data Foundation 专用且唯一的 Key Value secret 路径。
          • 可选:输入 TLS Server NameVault Enterprise Namespace
          • 上传对应的 PEM 编码证书文件,以提供 CA 证书客户端证书客户端私钥
          • 点击 Save
        使用 Kubernetes 验证方法
        • 输入唯一的 Vault Connection Name, Vault 服务器的主机地址('https://<hostname 或 ip>')、端口号和角色名称。
        • 展开 Advanced Settings,以根据您的 Vault 配置输入其他设置和证书详情。

          • 后端路径中输入为 OpenShift Data Foundation 专用且唯一的 Key Value secret 路径。
          • 可选:输入 TLS Server NameAuthentication Path (如果适用)。
          • 上传对应的 PEM 编码证书文件,以提供 CA 证书客户端证书客户端私钥
          • 点击 Save
    4. Next
  6. Review and create 页面中,检查配置详情。

    若要修改任何配置设置,请单击 Back

  7. 单击 Create StorageSystem

验证步骤

  • 验证已安装存储集群的最终状态:

    1. 在 OpenShift Web 控制台中,导航到 Installed OperatorsOpenShift Data FoundationStorage Systemocs-storagecluster-storagesystemResources
    2. 验证 StorageClusterStatus 是否为 Ready,并且旁边有一个绿色勾号标记。
  • 要验证 OpenShift 数据基础的所有组件是否已成功安装,请参阅验证您的 OpenShift Data Foundation 部署

其它资源

要启用 Overprovision Control 警报,请参阅 Monitoring 中的 Alerts 指南。

2.5. 验证 OpenShift Data Foundation

使用本节验证 OpenShift Data Foundation 是否已正确部署。

2.5.1. 验证 pod 的状态

流程

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

    注意

    如果禁用 Show default projects 选项,请使用切换按钮列出所有默认项目。

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

  3. RunningCompleted 标签页验证以下 pod 是否处于 RunningCompleted 状态:

    表 2.1. 对应 OpenShift Data Foundation 集群的 Pod
    组件对应的 pod

    OpenShift Data Foundation Operator

    • OCS-operator-*(在任何 worker 节点上有 1 个 pod)
    • ocS-metrics-exporter-*(任何 worker 节点上 1 个 pod)
    • odF-operator-controller-manager-*(任何 worker 节点上 1 个 pod)
    • odf-console-* (任何 worker 节点上 1 个 pod)
    • csi-addons-controller-manager-* (任何 worker 节点上 1 个 pod)

    Rook-ceph Operator

    rook-ceph-operator-*

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

    多云对象网关

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

    MON

    rook-ceph-mon-*

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

    MGR

    rook-ceph-mgr-*

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

    MDS

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

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

    CSI

    • cephfs

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

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

    rook-ceph-crashcollector

    rook-ceph-crashcollector-*

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

    OSD

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

2.5.2. 验证 OpenShift Data Foundation 集群是否健康

流程

  1. 在 OpenShift Web 控制台中,点 StorageData Foundation
  2. Overview 选项卡的 Status 卡中,点 Storage System,然后点弹出框中的存储系统链接。
  3. Block and File 选项卡的 Status 卡中,验证 Storage Cluster 是否具有绿色勾号。
  4. Details 卡中,验证是否显示集群信息。

如需有关使用 Block and File 仪表板的 OpenShift Data Foundation 集群健康的更多信息,请参阅 监控 OpenShift Data Foundation

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

流程

  1. 在 OpenShift Web 控制台中,点 StorageData Foundation
  2. Overview 选项卡的 Status 卡中,点 Storage System,然后点弹出框中的存储系统链接。

    1. Object 选项卡的 Status 卡 中,验证 Object Service数据弹性 都具有绿色勾号。
    2. Details 卡中,验证是否显示了 MCG 信息。

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

2.5.4. 验证 OpenShift Data Foundation 特定的存储类是否存在

流程

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

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

第 3 章 部署独立多云对象网关

仅通过 OpenShift Data Foundation 部署多云对象网关组件可为部署提供灵活性,并有助于减少资源消耗。使用这个部分来只部署独立 Multicloud 对象网关组件,它涉及以下步骤:

  • 安装 Red Hat OpenShift Data Foundation Operator
  • 创建独立多云对象网关

3.1. 安装 Red Hat OpenShift Data Foundation Operator

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

先决条件

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

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

流程

  1. 登录 OpenShift Web 控制台。
  2. Operators → OperatorHub
  3. Filter by keyword 框中滚动或键入 OpenShift Data Foundation,以查找 OpenShift Data Foundation Operator。
  4. Install
  5. Install Operator 页面中设置以下选项:

    1. 将 Channel 更新为 stable-4.10
    2. 安装模式是 A specific namespace on the cluster
    3. Installed Namespace 为 Operator recommended namespace openshift-storage。如果命名空间 openshift-storage 不存在,它会在 Operator 安装过程中创建。
    4. 将 Approval Strategy 选为 AutomaticManual

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

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

    5. 确保为 Console 插件 选择了 Enable 选项。
    6. Install

验证步骤

  • 验证 OpenShift Data Foundation Operator 是否显示绿色勾号(代表安装成功)。
  • 成功安装 Operator 后,用户界面中会显示一个带有 Web console update is available 信息的弹出窗口。点这个弹出窗口中的 Refresh web console 来反映控制台的更改。

    • 在 Web 控制台中,导航到 Operators,并验证 OpenShift Data Foundation 是否可用。

3.2. 创建独立多云对象网关

在部署 OpenShift Data Foundation 时,您只能创建独立多云对象网关组件。

先决条件

  • 确保已安装 OpenShift Data Foundation Operator。

流程

  1. 在 OpenShift Web 控制台中,点 OperatorsInstalled Operators 查看所有已安装的 Operator。

    确保所选 项目openshift-storage

  2. 单击 OpenShift Data Foundation operator,然后单击 Create StorageSystem
  3. Backing storage 页面中,选择以下内容:

    1. Deployment 类型选择 Multicloud Object Gateway
    2. 选择 Use a existing StorageClass 选项。
    3. Next
  4. 可选:在 Security 页面中,选择连接到外部密钥管理服务

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

      1. 后端路径中输入为 OpenShift Data Foundation 专用且唯一的 Key Value secret 路径。
      2. 可选:输入 TLS Server NameVault Enterprise Namespace
      3. 上传对应的 PEM 编码证书文件,以提供 CA 证书客户端证书客户端私钥
      4. 点击 Save
    4. Next
  5. Review and create 页面中,查看配置详情:

    若要修改任何配置设置,请单击 Back

  6. 单击 Create StorageSystem

验证步骤

验证 OpenShift Data Foundation 集群是否健康
  1. 在 OpenShift Web 控制台中,点 StorageData Foundation
  2. Overview 选项卡的 Status 卡中,点 Storage System,然后点弹出框中的存储系统链接。

    1. Object 选项卡的 Status 卡 中,验证 Object Service数据弹性 都具有绿色勾号。
    2. Details 卡中,验证是否显示了 MCG 信息。
验证 pod 的状态
  1. 从 OpenShift Web 控制台点 WorkloadsPods
  2. Project 下拉列表中选择 openshift-storage,再验证以下 pod 处于 Running 状态。

    注意

    如果禁用 Show default projects 选项,请使用切换按钮列出所有默认项目。

    组件对应的 pod

    OpenShift Data Foundation Operator

    • OCS-operator-*(在任何 worker 节点上有 1 个 pod)
    • ocS-metrics-exporter-*(任何 worker 节点上 1 个 pod)
    • odF-operator-controller-manager-*(任何 worker 节点上 1 个 pod)
    • odf-console-* (任何 worker 节点上 1 个 pod)
    • csi-addons-controller-manager-* (任何 worker 节点上 1 个 pod)

    Rook-ceph Operator

    rook-ceph-operator-*

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

    多云对象网关

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

第 4 章 卸载 OpenShift Data Foundation

4.1. 以内部模式卸载 OpenShift Data Foundation

要以内部模式卸载 OpenShift Data Foundation,请参阅 有关卸载 OpenShift Data Foundation 的知识库文章

第 5 章 存储类和存储池

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

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

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

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

注意

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

5.1. 创建存储类和池

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

先决条件

  • 确保您已登录到 OpenShift Container Platform Web 控制台,并且 OpenShift Data Foundation 集群处于 Ready 状态。

流程

  1. StorageStorageClasses
  2. Create Storage Class
  3. 输入存储类 NameDescription
  4. Reclaim Policy 设置为 Delete 作为默认选项。使用这个设置。

    如果您在存储类中将重新声明策略改为 Retain,则持久性卷(PV)会处于 Released 状态,即使在删除持久性卷声明(PVC)后也是如此。

  5. 卷绑定模式设置为 WaitForConsumer 作为默认选项。

    如果您选择 Immediate 选项,则创建 PVC 时会立即创建 PV。

  6. 选择 RBD Provisioner,这是用于置备持久性卷的插件。
  7. 从列表中选择现有存储池,或创建新池。

    创建新池
    1. 单击 Create New Pool
    2. 输入 池名称
    3. 选择 2-way-Replication3-way-Replication作为数据保护策略。
    4. 如果需要压缩数据,选择启用压缩

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

    5. 单击 Create 以创建新存储池。
    6. 创建池后,单击 Finish
  8. 可选:选中启用加密复选框。
  9. Create 创建存储类。

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

先决条件

根据您的用例,您必须确保为以下之一配置对 KMS 的访问:

流程

  1. 在 OpenShift Web 控制台中,进入 StorageStorageClasses
  2. Create Storage Class
  3. 输入存储类 NameDescription
  4. Reclaim Policy 选择 DeleteRetain。默认情况下,选择 Delete
  5. 选择 ImmediateWaitForFirstConsumer 作为卷绑定模式WaitForConsumer 设置为默认选项。
  6. 选择 RBD Provisioner openshift-storage.rbd.csi.ceph.com,这是用于调配持久卷的插件。
  7. 选择 存储池,其中卷数据将存储到列表中或创建新池。
  8. 选中 Enable encryption 复选框。有两个选项可用来设置 KMS 连接详情:

    • 选择现有的 KMS 连接 :从下拉列表中选择现有 KMS 连接。该列表填充自 csi-kms-connection-details ConfigMap 中的连接详情。
    • 创建新的 KMS 连接 :这仅适用于 vaulttoken

      1. 默认情况下,Key Management Service Provider 设置为 Vault。
      2. 输入唯一的连接名称 , Vault 服务器的主机地址('https://<hostname 或 ip>'),端口号和令牌
      3. 展开 Advanced Settings,以根据您的 Vault 配置输入其他设置和证书详情。

        1. 后端路径中输入为 OpenShift Data Foundation 专用且唯一的 Key Value secret 路径。
        2. 可选:输入 TLS Server NameVault Enterprise Namespace
        3. 上传对应的 PEM 编码证书文件,以提供 CA 证书客户端证书客户端私钥
        4. 点击 Save
      4. 点击 Save
  9. 点击 Create
  10. 如果 HashiCorp Vault 设置不允许自动检测后端路径使用的 Key/Value(KV)secret 引擎 API 版本,编辑 ConfigMap 以添加 vaultBackend 参数。

    注意

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

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

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

        例如:

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

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

        您可以为 KV secret engine API 版本 1 分配 kv,为 KV secret engine API 版本 2 分配 kv-v2

        例如:

         kind: ConfigMap
         apiVersion: v1
         metadata:
           name: csi-kms-connection-details
         [...]
         data:
           1-vault: |-
             {
               "encryptionKMSType": "vaulttokens",
               "kmsServiceName": "1-vault",
               [...]
               "vaultBackend": "kv-v2"
             }
           2-vault: |-
             {
               "encryptionKMSType": "vaulttenantsa",
               [...]
               "vaultBackend": "kv"
             }
      3. 点 Save

后续步骤

  • 存储类可用于创建加密的持久性卷。如需更多信息,请参阅管理持久性卷声明

    重要

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

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

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

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

警告

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

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

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

6.1. 将镜像 registry 配置为使用 OpenShift Data Foundation

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

按照本节中的说明,将 OpenShift Data Foundation 配置为 Container Image Registry 的存储。在 Google Cloud 上,不需要更改 registry 的存储。

警告

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

先决条件

  • 具有 OpenShift Web 控制台的管理访问权限。
  • OpenShift Data Foundation 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 → StorageClasses 查看可用的存储类。

流程

  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

6.2. 配置监控以使用 OpenShift 数据基础

OpenShift 数据基础提供由 Prometheus 和 Alert Manager 组成的监控堆栈。

按照本节中的说明,将 OpenShift 数据基础配置为监控堆栈的存储。

重要

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

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

先决条件

  • 具有 OpenShift Web 控制台的管理访问权限。
  • OpenShift Data Foundation 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 → StorageClasses 查看可用的存储类。

流程

  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。

      图 6.1. 监控创建和绑定的存储

      OpenShift Web 控制台的截图显示在 openshift-monitoring 项目中绑定了五个持久卷声明的 pod
  2. 验证新 alertmanager-main-* pod 的状态是否显示为 Running

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

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

      OpenShift Web 控制台的截图显示附加到 changemanager pod 的持久卷声明
  3. 验证新的 prometheus-k8s-* pod 的状态是否为 Running

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

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

      显示附加到 prometheus pod 的持久性卷声明的 OpenShift Web 控制台截图

6.3. OpenShift 数据基础的集群日志记录

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

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

重要

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

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

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

6.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: {}

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

6.3.2. 配置集群日志记录以使用 OpenShift Data Foundation

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

注意

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

先决条件

  • 具有 OpenShift Web 控制台的管理访问权限。
  • OpenShift Data Foundation 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 Data Foundation 节点带有污点,您必须添加容限,以启用为日志调度 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。

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

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

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

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

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

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

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

注意

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

第 7 章 使用 OpenShift Data Foundation 支持 OpenShift Container Platform 应用程序

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

先决条件

  • 已安装 OpenShift Container Platform,您还可管理 OpenShift Web 控制台。
  • OpenShift Data Foundation 在 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 页面中验证存储类名称。

第 8 章 如何在 Red Hat OpenShift Data Foundation 中使用专用 worker 节点

任何 Red Hat OpenShift Container Platform 订阅都需要一个 OpenShift Data Foundation 订阅。但是,如果您使用基础架构节点调度 OpenShift 数据基础资源,您可以在 OpenShift Container Platform 订阅上保存。

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

8.1. 基础架构节点分析

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

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

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

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

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

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

    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: ""

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

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

注意

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

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

  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: ""
重要

如果向基础架构节点添加污点,您还需要为其他工作负载的污点添加容限,如 fluentd pod。如需更多信息,请参阅 OpenShift 4 中的红帽知识库解决方案 基础架构节点。

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

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

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

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

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 Data Foundation 污点足以满足权利的要求。

8.4. 从用户界面污点一个节点

本节解释了在 OpenShift Data Foundation 部署后污点节点的步骤。

流程

  1. 在 OpenShift Web 控制台中,点击 ComputeNodes,然后选择必须污点的节点。
  2. Details 页面中,点 Edit taint
  3. Key <nodes.openshift.ocs.io/storage>, Value <true> and in the Effect<Noschedule> 项中输入值。
  4. 点 Save。

验证步骤

  • 按照以下步骤验证节点是否已成功污点:

    • 进入 ComputeNodes
    • 选择节点以验证其状态,然后单击 YAML 选项卡。
    • specs 部分中检查以下参数值:

      Taints:
        Key: nodes.openshift.ocs.io/storage
        Value: true
        Effect: Noschedule

其它资源

如需更多信息,请参阅在 VMware vSphere 上创建 OpenShift Data Foundation 集群

第 9 章 扩展存储节点

要扩展 OpenShift 数据基础的存储容量,您可以执行以下操作之一:

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

9.1. 扩展存储节点的要求

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

警告

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

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

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

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

9.2. 通过在 Google Cloud 基础架构上的 OpenShift Data Foundation 节点添加容量来扩展存储

您可以为配置的 Red Hat OpenShift Data Foundation worker 节点添加存储容量和性能。

先决条件

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

流程

  1. 登录 OpenShift Web 控制台。
  2. Operators → Installed Operators
  3. OpenShift Data Foundation Operator。
  4. 单击 Storage Systems 选项卡。

    1. 点击存储系统名称最右侧的 Action Menu(⋮) 来扩展选项菜单。
    2. 从选项菜单中选择 Add Capacity
    3. 选择 Storage Class

如果您使用默认的存储类(它使用 HDD),则将存储类设置为 standard。但是,如果您创建了存储类以使用 SSD 的磁盘来提高性能,则需要选择该存储类。

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

  1. 点击 Add

    1. 要检查状态,请进入 StorageData Foundation,并验证 Status 卡中的 Storage System 有一个绿色勾号。

验证步骤

  • 验证 Raw Capacity 卡。

    1. 在 OpenShift Web 控制台中,点 StorageData Foundation
    2. Overview 选项卡的 Status 卡中,点 Storage System,然后点弹出框中的存储系统链接。
    3. Block and File 选项卡中,检查 Raw Capacity 卡。

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

      注意

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

  • 验证新 OSD 及其对应的新持久卷声明(PVC)已创建。

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

      1. 从 OpenShift Web 控制台点 WorkloadsPods
      2. Project 下拉列表中选择 openshift-storage

        注意

        如果禁用 Show default projects 选项,请使用切换按钮列出所有默认项目。

    • 查看 PVC 的状态:

      1. 从 OpenShift Web 控制台点 StoragePersistent Volume Claims
      2. Project 下拉列表中选择 openshift-storage

        注意

        如果禁用 Show default projects 选项,请使用切换按钮列出所有默认项目。

  • 可选:如果在集群中启用了集群范围的加密,请验证新 OSD 设备是否已加密。

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

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

      是 OSD pod 的名称。

      例如:

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

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

        $ oc debug node/<node-name>
        <node-name>

        是节点的名称。

        $ chroot /host
      2. 检查 ocs-deviceset 名称旁边的 crypt 关键字。

        $ lsblk
重要

只有红帽支持团队的协助才支持 集群

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

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

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

9.3.1. 在 Google Cloud installer 置备的基础架构上添加节点

先决条件

  • 您必须登录到 OpenShift Container Platform 集群。

流程

  1. 导航到 ComputeMachine Sets
  2. 在您要添加节点的机器集中,选择 Edit Machine Count

    1. 添加节点数量,然后点 Save
    2. ComputeNodes 并确认新节点是否处于 Ready 状态
  3. 将 OpenShift 数据基础标签应用到新节点。

    1. 对于新节点,点击 Action 菜单(⋮)Edit Labels
    2. 添加 cluster.ocs.openshift.io/openshift-storage,然后点 Save
注意

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

验证步骤

9.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-*

9.3.3. 扩展存储容量

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

第 10 章 多云对象网关

10.1. 关于 Multicloud 对象网关

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

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

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

先决条件

  • 正在运行的 OpenShift Data Foundation 平台。
  • 下载 MCG 命令行界面以简化管理。

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

    指定使用订阅管理器启用存储库的适当架构。

    • 对于 IBM Power,使用以下命令:
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-ppc64le-rpms
    • 对于 IBM Z 基础架构,使用以下命令:
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
  • 或者,您也可以从 下载红帽 OpenShift Data Foundation 页面上的 OpenShift Data Foundation RPM 安装 MCG 软件包。

    注意

    根据您的架构选择正确的产品变体。

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

例 10.1. 示例

使用虚拟主机风格访问 MCG 存储桶
如果客户端应用程序尝试访问 https://<bucket-name>.s3-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com
<bucket-name>

是 MCG 存储桶的名称

例如:https://mcg-test-bucket.s3-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com

DNS 条目需要 mcg-test-bucket.s3-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com 来指向 S3 服务。

重要

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

10.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 端点

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

先决条件

  • 下载 MCG 命令行界面。

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

    指定使用订阅管理器启用存储库的适当架构。

    • 对于 IBM Power,使用以下命令:
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-ppc64le-rpms
    • 对于 IBM Z 基础架构,使用以下命令:
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms

流程

运行 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 访问密钥来连接到您的应用。

例 10.2. 示例

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

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

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

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

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

先决条件

  • 正在运行的 OpenShift Data Foundation 平台。

流程

  1. 启用对 MCG 控制台的访问。

    在集群中执行以下步骤:

    1. 创建 cluster-admins 组。

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

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

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

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

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

      注意

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

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

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

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

验证步骤

  1. 在 OpenShift Web 控制台中,以有权访问多云对象网关控制台的用户身份登录。
  2. 进入 StorageData Foundation
  3. Storage Systems 选项卡中,选择 storage 系统,然后点 OverviewObject 选项卡。
  4. 选择 Multicloud Object Gateway 链接。
  5. 点击 Allow selected permissions

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

10.4.1. 创建新的后备存储

在 OpenShift Data Foundation 中使用此流程创建新的后备存储。

先决条件

  • OpenShift Data Foundation 的管理员访问权限。

流程

  1. 在 OpenShift Web 控制台中,点 StorageData Foundation
  2. 单击 Backing Store 选项卡。
  3. 单击 Create Backing Store
  4. Create New Backing Store 页面中执行以下操作:

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

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

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

      注意

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

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

验证步骤

  1. 在 OpenShift Web 控制台中,点 StorageData Foundation
  2. 单击 Backing Store 选项卡,以查看所有后备存储。

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

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

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

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

对于 VMware 部署,请跳至 第 10.4.3 节 “创建兼容 s3 的多云对象网关后备存储” 以了解更多详细信息。

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

先决条件

  • 下载多云对象网关(MCG)命令行界面。

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

    指定使用订阅管理器启用存储库的适当架构。例如,如果是 IBM Z 基础架构,请使用以下命令:

    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
  • 另外,您还可以从位于 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/packages的 OpenShift Data Foundation RPM 安装 MCG 软件包。

    注意

    根据您的架构选择正确的产品变体。

流程

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

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

    输出结果类似如下:

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

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

  1. 使用凭证创建 secret:

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

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

先决条件

  • 下载多云对象网关(MCG)命令行界面。

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

    指定使用订阅管理器启用存储库的适当架构。例如,

    • 对于 IBM Power,使用以下命令:
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-ppc64le-rpms
    • 对于 IBM Z 基础架构,使用以下命令:
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
  • 另外,您还可以从位于 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/packages的 OpenShift Data Foundation RPM 安装 MCG 软件包。

    注意

    根据您的架构选择正确的产品变体。

流程

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

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

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

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

      输出结果类似如下:

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

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

  1. 使用凭证创建 secret:

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

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

先决条件

  • 下载多云对象网关(MCG)命令行界面。

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

    指定使用订阅管理器启用存储库的适当架构。例如,如果是 IBM Z 基础架构,请使用以下命令:

    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
  • 另外,您还可以从位于 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/packages的 OpenShift Data Foundation RPM 安装 MCG 软件包。

    注意

    根据您的架构选择正确的产品变体。

流程

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

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

      输出结果类似如下:

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

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

  1. 使用凭证创建 secret:

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

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

先决条件

  • 下载多云对象网关(MCG)命令行界面。

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

    指定使用订阅管理器启用存储库的适当架构。例如,如果是 IBM Z 基础架构,请使用以下命令:

    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
  • 另外,您还可以从位于 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/packages的 OpenShift Data Foundation RPM 安装 MCG 软件包。

    注意

    根据您的架构选择正确的产品变体。

流程

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

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

      输出结果类似如下:

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

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

  1. 使用凭证创建 secret:

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

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

先决条件

  • 下载多云对象网关(MCG)命令行界面。

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

    指定使用订阅管理器启用存储库的适当架构。例如,如果是 IBM Z 基础架构,请使用以下命令:

    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
  • 另外,您还可以从位于 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/packages的 OpenShift Data Foundation RPM 安装 MCG 软件包。

    注意

    根据您的架构选择正确的产品变体。

流程

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

    注意

    此命令必须从 openshift-storage 命名空间内运行。

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

      输出结果类似如下:

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

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

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

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

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

多云对象网关(MCG)可以使用任何 S3 兼容对象存储作为后备存储,例如,Red Hat Ceph Storage 的 RADOS 对象网关(RGW)。以下步骤演示了如何为 Red Hat Ceph Storage 的 RGW 创建 S3 兼容 MCG 后备存储。请注意,部署 RGW 时,OpenShift Data Foundation operator 会自动为 MCG 创建 S3 兼容后备存储。

流程

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

    注意

    此命令必须从 openshift-storage 命名空间内运行。

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

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

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

流程

  1. 在 OpenShift Web 控制台中,点 StorageData Foundation
  2. Storage Systems 选项卡中,选择 storage 系统,然后点 OverviewObject 选项卡。
  3. 选择 Multicloud Object Gateway 链接。
  1. 选择左侧的资源选项卡,突出显示下方。从填充的列表中,选择 Add Cloud Resource

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

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

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

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

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

10.4.5. 创建新存储桶类

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

在 OpenShift Data Foundation 中创建存储桶类。

流程

  1. 在 OpenShift Web 控制台中,点 StorageData Foundation
  2. 单击 Bucket Class 选项卡。
  3. Create Bucket Class
  4. 在 Create new Bucket Class 页面中,执行以下操作:

    1. 选择 bucket 类类型,再输入 bucket 类名称。

      1. 选择 BucketClass 类型。选择以下选项之一:

        • Standard :数据将由多云对象网关(MCG)使用,已取消、压缩和加密。
        • Namespace :数据存储在 Namespace 存储中,而无需执行重复数据删除、压缩或加密。

          默认选择 Standard

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

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

      注意

      当在上一步中选择 Policy Type 作为 Mirror 时,至少需要选择 2 个后备存储。

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

验证步骤

  1. 在 OpenShift Web 控制台中,点 StorageData Foundation
  2. 单击 Bucket Class 选项卡,再搜索新的 Bucket 类。

10.4.6. 编辑存储桶类

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

先决条件

  • 管理员对 OpenShift Web 控制台的访问权限。

流程

  1. 在 OpenShift Web 控制台中,点 StorageData Foundation
  2. 单击 Bucket Class 选项卡。
  3. 点击您要编辑的 Bucket 类旁边的 Action Menu (⋮)
  4. Edit Bucket Class
  5. 您将被重定向到 YAML 文件,在此文件中进行必要的更改并点 Save

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

使用以下步骤编辑现有的多云对象网关(MCG)存储桶类,以更改存储桶类中使用的底层后备存储。

先决条件

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

流程

  1. 在 OpenShift Web 控制台中,点 StorageData Foundation
  2. 单击 Bucket Class 选项卡。
  3. 点击您要编辑的 Bucket 类旁边的 Action Menu (⋮)

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

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

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

10.5. 管理命名空间存储桶

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

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

注意

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

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

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

Red Hat OpenShift Data Foundation 4.6 之后支持以下命名空间存储桶操作:

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

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

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

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

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

先决条件

流程

  1. 使用凭证创建 secret:

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

    apiVersion: noobaa.io/v1alpha1
    kind: NamespaceStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: <resource-name>
      namespace: openshift-storage
    spec:
      awsS3:
        secret:
          name: <namespacestore-secret-name>
          namespace: <namespace-secret>
        targetBucket: <target-bucket>
      type: aws-s3
    1. <resource-name> 替换为您要提供给资源的名称。
    2. <namespacestore-secret-name> 替换为在第 1 步中创建的 secret。
    3. <namespace-secret> 替换为可找到 secret 的命名空间。
    4. <target-bucket> 替换为您为 NamespaceStore 创建的目标存储桶。
  3. 创建一个命名空间存储桶类,为命名空间存储桶定义命名空间策略。命名空间策略的类型需要是 singlemulti

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

      apiVersion: noobaa.io/v1alpha1
      kind: BucketClass
      metadata:
        labels:
          app: noobaa
        name: <my-bucket-class>
        namespace: openshift-storage
      spec:
        namespacePolicy:
          type:
          single:
            resource: <resource>
      • <my-bucket-class> 替换为唯一的命名空间存储桶类名称。
      • <resource> 替换为单个 namespace-store 的名称,该存储将定义命名空间存储桶的读取和写入目标。
    • 一个类型为 multi 的命名空间策略需要以下配置:

      apiVersion: noobaa.io/v1alpha1
      
      kind: BucketClass
      metadata:
        labels:
          app: noobaa
        name: <my-bucket-class>
        namespace: openshift-storage
      spec:
        namespacePolicy:
          type: Multi
          multi:
            writeResource: <write-resource>
            readResources:
            - <read-resources>
            - <read-resources>
      • <my-bucket-class> 替换为唯一的存储桶类名称。
      • <write-resource> 替换为定义命名空间存储桶写入目标的单一命名空间存储名称。
      • <read-resources> 替换为定义命名空间存储桶读取目标的 namespace-store 的名称列表。
  4. 应用以下 YAML,以使用对象 Bucket Class (OBC) 资源创建 bucket,该资源使用第 2 步中定义的 bucket 类。

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: <resource-name>
      namespace: openshift-storage
    spec:
      generateBucketName: <my-bucket>
      storageClassName: openshift-storage.noobaa.io
      additionalConfig:
        bucketclass: <my-bucket-class>
    1. <resource-name> 替换为您要提供给资源的名称。
    2. <my-bucket> 替换为您要提供给存储桶的名称。
    3. <my-bucket-class> 替换为上一步中创建的存储桶类。

当 Operator 置备 OBC 后,会在 MCG 中创建存储桶,Operator 会创建一个名称相同且位于 OBC 同一命名空间上的 Secret 和 ConfigMap。

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

先决条件

流程

  1. 使用凭证创建 secret:

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

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

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

      apiVersion: noobaa.io/v1alpha1
      kind: BucketClass
      metadata:
        labels:
          app: noobaa
        name: <my-bucket-class>
        namespace: openshift-storage
      spec:
        namespacePolicy:
          type:
          single:
            resource: <resource>
      • <my-bucket-class> 替换为唯一的命名空间存储桶类名称。
      • <resource> 替换为单个 namespace-store 的名称,该存储将定义命名空间存储桶的读取和写入目标。
    • 一个类型为 multi 的命名空间策略需要以下配置:

      apiVersion: noobaa.io/v1alpha1
      kind: BucketClass
      metadata:
        labels:
          app: noobaa
        name: <my-bucket-class>
        namespace: openshift-storage
      spec:
        namespacePolicy:
          type: Multi
          multi:
            writeResource: <write-resource>
            readResources:
            - <read-resources>
            - <read-resources>
      • <my-bucket-class> 替换为唯一的存储桶类名称。
      • <write-resource> 替换为定义命名空间存储桶写入目标的单一命名空间存储名称。
      • <read-resources> 替换为定义命名空间存储桶读取目标的 namespace-store 的名称列表。
  4. 应用以下 YAML,以使用对象 Bucket Class (OBC) 资源创建 bucket,该资源使用第 2 步中定义的 bucket 类。

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: <resource-name>
      namespace: openshift-storage
    spec:
      generateBucketName: <my-bucket>
      storageClassName: openshift-storage.noobaa.io
      additionalConfig:
        bucketclass: <my-bucket-class>
    1. <resource-name> 替换为您要提供给资源的名称。
    2. <my-bucket> 替换为您要提供给存储桶的名称。
    3. <my-bucket-class> 替换为上一步中创建的存储桶类。

当 Operator 置备 OBC 后,会在 MCG 中创建存储桶,Operator 会创建一个名称相同且位于 OBC 同一命名空间上的 Secret 和 ConfigMap。

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

先决条件

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

指定适当的架构,以使用订阅管理器启用存储库。例如,如果是 IBM Z 基础架构,请使用以下命令:

# subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms

另外,您还可以从位于 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/package的 OpenShift Data Foundation RPM 安装 MCG 软件包。

注意

根据您的架构选择正确的产品变体。

流程

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

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

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

      noobaa bucketclass create namespace-bucketclass single <my-bucket-class> --resource <resource> -n openshift-storage
      • <resource-name> 替换为您要为其提供资源的名称。
      • <my-bucket-class> 替换为唯一的存储桶类名称。
      • <resource> 替换为定义命名空间存储桶读写目标的单个 namespace-store。
    • 运行以下命令,创建一个命名空间存储桶类,其命名空间策略为 multi

      noobaa bucketclass create namespace-bucketclass multi <my-bucket-class> --write-resource <write-resource> --read-resources <read-resources> -n openshift-storage
      • <resource-name> 替换为您要为其提供资源的名称。
      • <my-bucket-class> 替换为唯一的存储桶类名称。
      • <write-resource> 替换为定义命名空间存储桶写入目标的单个 namespace-store。
      • <read-resources> 替换为一个以逗号分开的命名空间存储列表,该存储将定义命名空间存储桶的读取目标。
  3. 运行以下命令,以使用对象 Bucket Class (OBC) 资源创建 bucket,该资源使用第 2 步中定义的 bucket 类。

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

当 Operator 置备 OBC 后,会在 MCG 中创建存储桶,Operator 会创建一个名称相同且位于 OBC 同一命名空间上的 Secret 和 ConfigMap。

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

先决条件

  • 正在运行的 OpenShift Data Foundation 平台。
  • 访问多云对象网关(MCG),请参阅第 2 章,使用应用程序访问多云对象网关
  • 下载 MCG 命令行界面:

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

    指定适当的架构,以使用订阅管理器启用存储库。

    • 对于 IBM Power,使用以下命令:
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-ppc64le-rpms
    • 对于 IBM Z 基础架构,使用以下命令:
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms

    另外,您还可以从位于 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/package的 OpenShift Data Foundation RPM 安装 MCG 软件包。

    注意

    根据您的架构选择正确的产品变体。

流程

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

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

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

      noobaa bucketclass create namespace-bucketclass single <my-bucket-class> --resource <resource> -n openshift-storage
      • <resource-name> 替换为您要为其提供资源的名称。
      • <my-bucket-class> 替换为唯一的存储桶类名称。
      • <resource> 替换为定义命名空间存储桶读写目标的单个 namespace-store。
    • 运行以下命令,创建一个命名空间存储桶类,其命名空间策略为 multi

      noobaa bucketclass create namespace-bucketclass multi <my-bucket-class> --write-resource <write-resource> --read-resources <read-resources> -n openshift-storage
      • <resource-name> 替换为您要为其提供资源的名称。
      • <my-bucket-class> 替换为唯一的存储桶类名称。
      • <write-resource> 替换为定义命名空间存储桶写入目标的单个 namespace-store。
      • <read-resources> 替换为一个以逗号分开的命名空间存储列表,该存储将定义命名空间存储桶的读取目标。
  3. 运行以下命令,以使用对象 Bucket Class (OBC) 资源创建 bucket,该资源使用第 2 步中定义的 bucket 类。

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

当 Operator 置备 OBC 后,会在 MCG 中创建存储桶,Operator 会创建一个名称相同且位于 OBC 同一命名空间上的 Secret 和 ConfigMap。

10.5.3. 使用 OpenShift Container Platform 用户界面添加命名空间存储桶

从 OpenShift Data Foundation 4.8 开始,可以使用 OpenShift Container Platform 用户界面添加命名空间存储桶。如需有关命名空间存储桶的更多信息,请参阅管理命名空间存储桶

先决条件

  • 安装了带有 OpenShift Data Foundation operator 的 OpenShift Container Platform。
  • 访问多云对象网关(MCG)。

流程

  1. 登录 OpenShift Web 控制台。
  2. 点 Storage → Data Foundation。
  3. Namespace Store 选项卡创建要在命名空间存储桶中使用的 namespacestore 资源。

    1. 单击 Create namespace store
    2. 输入命名空间存储名称。
    3. 选择一个供应商。
    4. 选择一个地区。
    5. 选择现有的 secret,或者点击 Swith to credentials 通过输入 secret key 和 secret access key 来创建 secret。
    6. 选择目标存储桶。
    7. 点击 Create
    8. 验证命名空间存储是否处于 Ready 状态。
    9. 重复这些步骤,直到您拥有所需的资源量。
  4. 点击 Bucket Class 选项卡 → Create a new Bucket Class

    1. 选择 Namespace 单选按钮。
    2. 输入 Bucket 类名称。
    3. 添加描述(可选)。
    4. Next
  5. 为您的命名空间存储桶选择一个命名空间策略类型,然后单击 Next
  6. 选择目标资源。

    • 如果您的命名空间策略类型是 Single,则需要选择一个读取资源。
    • 如果您的命名空间策略类型是 Multi,则需要选择读取资源和写入资源。
    • 如果命名空间策略类型是 Cache,则需要选择一个定义命名空间存储桶读取和写入目标的 Hub 命名空间存储。
  7. Next
  8. 检查您的新 bucket 类,然后点击 Create Bucketclass
  9. BucketClass 页面中,验证新创建的资源是否处于 Created 阶段。
  10. 在 OpenShift Web 控制台中,点 StorageData Foundation
  11. Status 卡中,单击 Storage System,再单击弹出窗口中的 storage 系统链接。
  12. Object 选项卡中,点 Multicloud Object GatewayBucketsNamespace Buckets 选项卡。
  13. Create Namespace Bucket

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

      1. Read Policy 下,选中在第 5 步中创建的每个命名空间资源应从中读取数据的复选框。
      2. 如果您使用的命名空间策略类型是 Multi,在 Write Policy 下指定要将数据写入的命名空间资源。
      3. Next
    3. 点击 Create

验证

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

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

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

先决条件

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

流程

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

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

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

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

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

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

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

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

    additionalConfig:
      bucketclass: mirror-to-aws

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

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

  1. 在 OpenShift Web 控制台中,点 StorageData Foundation
  2. Status 卡中,单击 Storage System,再单击弹出窗口中的 storage 系统链接。
  3. Object 选项卡中,点 Multicloud Object Gateway 链接。
  4. NooBaa 页面中,单击左侧的存储 图标。您可以看到存储桶列表:

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

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

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

在 NooBaa UI 中创建的资源不能被 OpenShift UI 或多云对象网关(MCG)CLI 使用。

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

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

10.7.1. 关于存储桶策略

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

10.7.2. 使用存储桶策略

先决条件

流程

在 MCG 中使用存储桶策略:

  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 用户的说明,请参阅 第 10.7.3 节 “在 Multicloud 对象网关中创建 AWS S3 用户”

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

    # aws --endpoint ENDPOINT --no-verify-ssl s3api put-bucket-policy --bucket MyBucket --policy BucketPolicy
    1. ENDPOINT 替换为 S3 端点。
    2. MyBucket 替换为 bucket,以设置策略。
    3. BucketPolicy 替换为 bucket 策略 JSON 文件。
    4. 如果您使用默认的自签名证书,请添加 --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 策略条件。

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

先决条件

流程

  1. 在 OpenShift Web 控制台中,点 StorageData Foundation
  2. Status 卡中,单击 Storage System,再单击弹出窗口中的 storage 系统链接。
  3. Object 选项卡中,点 Multicloud Object Gateway 链接。
  4. Accounts 选项卡下,单击 Create Account

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

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

    MCG 创建帐户 s3 user2

10.8. 对象 Bucket 声明

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

您可以通过三种方式创建对象 Bucket 声明:

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

10.8.1. 动态对象 Bucket 声明

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

注意

只有在 OpenShift 使用自签名证书时,多云对象网关端点才会使用自签名证书。在 OpenShift 中使用签名证书自动将 Multicloud Object Gateway 端点证书替换为签名证书。通过浏览器访问端点,获取多云对象网关当前使用的证书。如需更多信息,请参阅使用应用程序访问多云对象网关

流程

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

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

    这些线是 OBC 本身。

    1. <obc-name> 替换为唯一的 OBC 名称。
    2. <obc-bucket-name> 替换为 OBC 的唯一存储桶名称。
  2. 您可以在 YAML 文件中添加更多行来自动使用 OBC。以下示例是存储桶声明结果之间的映射,这是一个带有凭证数据和 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> 的所有实例替换为您的 OBC 名称。
    2. <your application image> 替换为您的应用程序镜像。
  3. 应用更新的 YAML 文件:

    # oc apply -f <yaml.file>

    <yaml.file> 替换为 YAML 文件的名称。

  4. 要查看新配置映射,请运行以下命令:

    # oc get cm <obc-name> -o yaml

    obc-name 替换为您的 OBC 的名称。

    您可以在输出中预期以下环境变量:

    • BUCKET_HOST - 应用程序中使用的端点。
    • BUCKET_PORT - 可供应用使用的端口。

    • BUCKET_NAME - 请求或生成的存储桶名称。
    • AWS_ACCESS_KEY_ID - 作为凭据一部分的访问密钥。
    • AWS_SECRET_ACCESS_KEY - 属于凭据的 Secret 访问密钥。
重要

获取 AWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEY。使用名称以便与 AWS S3 API 兼容。您需要在执行 S3 操作时指定密钥,特别是从多云对象网关(MCG)存储桶中读取、写入或列表时。密钥以 Base64 编码。解码密钥,然后才能使用它们。

# oc get secret <obc_name> -o yaml
<obc_name>
指定对象存储桶声明的名称。

10.8.2. 使用命令行界面创建对象 Bucket 声明

在使用命令行界面创建对象 Bucket 声明(OBC)时,您会获得一个配置映射和一个 Secret,其中包含应用使用对象存储服务所需的所有信息。

先决条件

  • 下载多云对象网关(MCG)命令行界面。

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

    指定使用订阅管理器启用存储库的适当架构。

    • 对于 IBM Power,使用以下命令:
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-ppc64le-rpms
    • 对于 IBM Z 基础架构,使用以下命令:
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms

流程

  1. 使用命令行界面生成新 bucket 和凭据的详细信息。运行以下命令:

    # noobaa obc create <obc-name> -n openshift-storage

    <obc-name> 替换为唯一的 OBC 名称,如 myappobc

    另外,您可以使用 --app-namespace 选项指定创建 OBC 配置映射和 secret 的命名空间,如 myapp-namespace

    输出示例:

    INFO[0001] ✅ Created: ObjectBucketClaim "test21obc"

    MCG 命令行界面已创建了必要的配置,并已向 OpenShift 告知新的 OBC。

  2. 运行以下命令来查看 OBC:

    # oc get obc -n openshift-storage

    输出示例:

    NAME        STORAGE-CLASS                 PHASE   AGE
    test21obc   openshift-storage.noobaa.io   Bound   38s
  3. 运行以下命令查看新 OBC 的 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 来使用此 OBC。CM 和 secret 的名称与 OBC 相同。运行以下命令来查看 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 端点信息。

10.8.3. 使用 OpenShift Web 控制台创建对象 Bucket 声明

您可以使用 OpenShift Web 控制台创建对象 BucketClaim (OBC)。

先决条件

流程

  1. 登录 OpenShift Web 控制台。
  2. 在左侧导航栏中,点击 StorageObject Bucket ClaimsCreate Object Bucket Claim

    1. 输入对象存储桶声明的名称,并根据您的部署(内部或外部)从下拉菜单中选择适当的存储类:

      内部模式
      创建 Object Bucket Claim 向导

      以下存储类是在部署后创建的,可供使用:

      • OCS-storagecluster-ceph-rgw 使用 Ceph 对象网关 (RGW)
      • openshift-storage.noobaa.io 使用 Multicloud 对象网关(MCG)
      外部模式
      创建 Object Bucket Claim 向导

      以下存储类是在部署后创建的,可供使用:

      • ocs-external-storagecluster-ceph-rgw 使用 RGW
      • openshift-storage.noobaa.io 使用 MCG

        注意

        RGW OBC 存储类仅可用于全新安装的 OpenShift Data Foundation 版本 4.5。它不适用于从以前的 OpenShift 数据基础版本升级的集群。

    2. 点击 Create

      创建 OBC 后,您会被重定向到其详情页面:

      Object Bucket Claim Details 页

10.8.4. 将对象 Bucket 声明附加到部署

创建后,对象 Bucket 声明 (OBC) 可以附加到特定的部署。

先决条件

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

流程

  1. 在左侧导航栏中,点击 StorageObject Bucket Claims
  2. 单击您创建的 OBC 旁边的操作菜单 (⋮)

    1. 从下拉菜单中选择 Attach to Deployment

      附加对象 Bucket 声明以进行部署
    2. 从 Deployment Name 列表中选择所需的部署,然后单击 Attach

      Deployment Name list

10.8.5. 使用 OpenShift Web 控制台查看对象存储桶

您可以使用 OpenShift Web 控制台查看为对象 Bucket 声明 (OBC) 创建的对象存储桶详情。

先决条件

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

流程

  1. 登录 OpenShift Web 控制台。
  2. 在左侧导航栏中,点击 StorageObject Buckets

    对象 Buckets 页面

    或者,您还可以导航到特定 OBC 的详细信息页面,再单击 Resource 链接来查看该 OBC 的对象存储桶。

  3. 选择您要查看详细信息的对象 bucket。您可以导航到 Object Bucket Details 页面。

10.8.6. 删除对象 Bucket 声明

先决条件

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

流程

  1. 在左侧导航栏中,点击 StorageObject Bucket Claims
  2. 点击您要删除的 Object Bucket Claim(OBC ) 旁边的 Action 菜单 (⋮)

    附加到部署的 MCG OBC 操作菜单
    1. 选择 Delete Object Bucket Claim
    2. 点击 Delete

10.9. 对象存储桶的缓存策略

缓存存储桶是带有 hub 目标和缓存目标的命名空间存储桶。hub 目标是一个 S3 兼容的大型对象存储桶。缓存存储桶是本地 Multicloud 对象网关存储桶。您可以创建一个缓存存储桶来缓存 AWS 存储桶或 IBM COS 存储桶。

重要

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

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

10.9.1. 创建 AWS 缓存存储桶

先决条件

  • 下载多云对象网关(MCG)命令行界面。

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

    指定使用订阅管理器启用存储库的适当架构。如果是 IBM Z 基础架构,请使用以下命令:

    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms

    另外,您还可以从位于 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/package的 OpenShift Data Foundation RPM 安装 MCG 软件包。

    注意

    根据您的架构选择正确的产品变体。

流程

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

    noobaa namespacestore create aws-s3 <namespacestore> --access-key <AWS ACCESS KEY> --secret-key <AWS SECRET ACCESS KEY> --target-bucket <bucket-name>
    1. <namespacestore> 替换为命名空间存储的名称。
    2. <AWS ACCESS KEY><AWS SECRET ACCESS KEY> 替换为您为此创建的 AWS 访问密钥 ID 和 secret 访问密钥。
    3. <bucket-name> 替换为现有的 AWS 存储桶名称。此参数告知 MCG 将哪一个存储桶用作其后备存储的目标存储桶,以及随后数据存储和管理。

      您还可以通过应用 YAML 来添加存储资源。首先使用凭证创建 secret:

      apiVersion: v1
      kind: Secret
      metadata:
        name: <namespacestore-secret-name>
      type: Opaque
      data:
        AWS_ACCESS_KEY_ID: <AWS ACCESS KEY ID ENCODED IN BASE64>
        AWS_SECRET_ACCESS_KEY: <AWS SECRET ACCESS KEY ENCODED IN BASE64>

      您必须使用 Base64 提供并编码您自己的 AWS 访问密钥 ID 和 secret 访问密钥,并使用结果代替 <AWS ACCESS KEY ID ENCODED IN BASE64><AWS SECRET ACCESS KEY ENCODED IN BASE64>

      使用一个唯一的名称替换 <namespacestore-secret-name>

      然后应用以下 YAML:

      apiVersion: noobaa.io/v1alpha1
      kind: NamespaceStore
      metadata:
        finalizers:
        - noobaa.io/finalizer
        labels:
          app: noobaa
        name: <namespacestore>
        namespace: openshift-storage
      spec:
        awsS3:
          secret:
            name: <namespacestore-secret-name>
            namespace: <namespace-secret>
          targetBucket: <target-bucket>
        type: aws-s3
    4. <namespacestore> 替换为唯一的名称。
    5. <namespacestore-secret-name> 替换为上一步中创建的 secret。
    6. <namespace-secret> 替换为用于在上一步中创建 secret 的命名空间。
    7. <target-bucket> 替换为您为命名空间存储创建的 AWS S3 存储桶。
  2. 运行以下命令来创建存储桶类:

    noobaa bucketclass create namespace-bucketclass cache <my-cache-bucket-class> --backingstores <backing-store> --hub-resource <namespacestore>
    1. <my-cache-bucket-class> 替换为唯一的存储桶类名称。
    2. <backing-store> 替换为相关的后备存储。您可以在此字段中列出一个或多个以逗号分开的后备存储。
    3. <namespacestore> 替换为上一步中创建的命名空间存储。
  3. 运行以下命令,以使用 Object Bucket Claim (OBC) 资源创建 bucket,该资源使用第 2 步中定义的 bucket 类。

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

10.9.2. 创建 IBM COS 缓存存储桶

先决条件

  • 下载多云对象网关(MCG)命令行界面。

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

    指定使用订阅管理器启用存储库的适当架构。

    • 对于 IBM Power,使用以下命令:
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-ppc64le-rpms
    • 对于 IBM Z 基础架构,使用以下命令:
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms

    另外,您还可以从位于 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/package的 OpenShift Data Foundation RPM 安装 MCG 软件包。

    注意

    根据您的架构选择正确的产品变体。

流程

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

    noobaa namespacestore create ibm-cos <namespacestore> --endpoint <IBM COS ENDPOINT> --access-key <IBM ACCESS KEY> --secret-key <IBM SECRET ACCESS KEY> --target-bucket <bucket-name>
    1. <namespacestore> 替换为 NamespaceStore 的名称。
    2. <IBM ACCESS KEY>、<IBM SECRET ACCESS KEY><IBM COS ENDPOINT> 替换为 IBM 访问密钥 ID、机密访问密钥和对应于现有 IBM 存储桶位置的适当区域端点。
    3. <bucket-name> 替换为现有的 IBM 存储桶名称。此参数告知 MCG 将哪一个存储桶用作其后备存储的目标存储桶,以及随后数据存储和管理。

      您还可以通过应用 YAML 来添加存储资源。首先,使用凭证创建一个 secret:

      apiVersion: v1
      kind: Secret
      metadata:
        name: <namespacestore-secret-name>
      type: Opaque
      data:
        IBM_COS_ACCESS_KEY_ID: <IBM COS ACCESS KEY ID ENCODED IN BASE64>
        IBM_COS_SECRET_ACCESS_KEY: <IBM COS SECRET ACCESS KEY ENCODED IN BASE64>

      您必须使用 Base64 提供和编码您自己的 IBM COS 访问密钥 ID 和 secret 访问密钥,并使用结果代替 <IBM COS ACCESS KEY ID ENCODED IN BASE64><IBM COS SECRET ACCESS KEY ENCODED IN BASE64>

      使用一个唯一的名称替换 <namespacestore-secret-name>

      然后应用以下 YAML:

      apiVersion: noobaa.io/v1alpha1
      kind: NamespaceStore
      metadata:
        finalizers:
        - noobaa.io/finalizer
        labels:
          app: noobaa
        name: <namespacestore>
        namespace: openshift-storage
      spec:
        s3Compatible:
          endpoint: <IBM COS ENDPOINT>
          secret:
            name: <backingstore-secret-name>
            namespace: <namespace-secret>
          signatureVersion: v2
          targetBucket: <target-bucket>
        type: ibm-cos
    4. <namespacestore> 替换为唯一的名称。
    5. <IBM COS ENDPOINT> 替换为适当的 IBM COS 端点。
    6. <backingstore-secret-name> 替换为上一步中创建的 secret。
    7. <namespace-secret> 替换为用于在上一步中创建 secret 的命名空间。
    8. <target-bucket> 替换为您为命名空间存储创建的 AWS S3 存储桶。
  2. 运行以下命令来创建存储桶类:

    noobaa bucketclass create namespace-bucketclass cache <my-bucket-class> --backingstores <backing-store> --hubResource <namespacestore>
    1. <my-bucket-class> 替换为唯一的存储桶类名称。
    2. <backing-store> 替换为相关的后备存储。您可以在此字段中列出一个或多个以逗号分开的后备存储。
    3. <namespacestore> 替换为上一步中创建的命名空间存储。
  3. 运行以下命令,以使用 Object Bucket Claim 资源创建 bucket,该资源使用第 2 步中定义的 bucket 类。

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

10.10. 通过添加端点扩展多云对象网关性能

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

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

  • 存储服务
  • S3 端点服务

10.10.1. 使用存储节点扩展 Multicloud 对象网关

先决条件

  • 在 OpenShift Container Platform 上运行 OpenShift 数据基础集群,可访问多云对象网关(MCG)。

MCG 中的存储节点是一个 NooBaa 守护进程容器,附加到一个或多个持久性卷(PV),用于本地对象存储。NooBaa 守护进程可以在 Kubernetes 节点上部署。这可以通过创建一个由 StatefulSet pod 组成的 Kubernetes 池来完成。

流程

  1. 登录 OpenShift Web 控制台
  2. 在 MCG 用户界面中,点击 OverviewAdd Storage Resources
  3. 在窗口中,单击 Deploy Kubernetes Pool
  4. Create Pool 步骤中,为将来安装的节点创建目标池。
  5. Configure 步骤中,配置请求的 pod 数以及每个 PV 的大小。对于每个新 pod,将创建一个 PV。
  6. Review 步骤中,您可以找到新池的详细信息,再选择要使用的部署方法:本地或外部部署。如果选择了本地部署,Kubernetes 节点将在集群内部署。如果选择了外部部署,您将获得 YAML 文件,供外部运行。
  7. 所有节点都会分配给您在第一步中选择的池,并可在 ResourcesStorage resourcesResource name 下找到。

10.11. 自动扩展 MultiCloud Object Gateway 端点

当 MCG S3 服务的负载增加或减少时,MultiCloud Object Gateway(MCG)端点的数量会自动缩放。OpenShift 数据基础集群使用一个活跃的 MCG 端点进行部署。每个 MCG 端点 pod 都默认配置有 1 个 CPU 和 2Gi 内存请求,其限值与请求匹配。当端点上的 CPU 负载在固定时间段内超过 80% 用量阈值时,部署第二个端点会降低第一个端点的负载。当两个端点的平均 CPU 负载在固定时间段内低于 80% 阈值时,会删除其中一个端点。此功能提高了 MCG 的性能和可服务性。

第 11 章 管理持久性卷声明

重要

OpenShift Data Foundation 支持的 PVC 不支持扩展 PVC。

11.1. 配置应用程序 pod 以使用 OpenShift Data Foundation

按照本节中的说明,将 OpenShift Data Foundation 配置为应用 pod 的存储。

先决条件

  • 具有 OpenShift Web 控制台的管理访问权限。
  • OpenShift Data Foundation Operator 在 openshift-storage 命名空间上安装并运行。在 OpenShift Web 控制台中,点 OperatorsInstalled Operators 查看已安装的 Operator。
  • OpenShift Data Foundation 提供的默认存储类可用。在 OpenShift Web 控制台中,点 StorageStorage Classes 查看默认存储类。

流程

  1. 为要使用的应用创建持久性卷声明 (PVC)。

    1. 在 OpenShift Web 控制台中,点击 StoragePersistent Volume Claims
    2. 为应用程序 pod 设置 Project
    3. 单击 Create Persistent Volume Claim

      1. 指定由 OpenShift Data Foundation 提供的存储类
      2. 指定 PVC Name,如 myclaim
      3. 选择所需的 Access Mode

        注意

        IBM FlashSystem 不支持 Access Mode, Shared access (RWX)

      4. 对于 Rados 块设备(RBD),如果 Access 模式 为 ReadWriteOnce(RWO),请选择所需的卷模式。默认卷模式是 Filesystem
      5. 根据应用程序要求指定一个 大小
      6. 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

11.2. 查看持久性卷声明请求状态

使用这个流程查看 PVC 请求的状态。

先决条件

  • OpenShift Data Foundation 的管理员访问权限。

流程

  1. 登录 OpenShift Web 控制台。
  2. StoragePersistent Volume Claims
  3. 使用 Filter 文本框搜索所需的 PVC 名称。您还可以按 Name 或 Label 过滤 PVC 列表来缩小列表范围
  4. 检查与所需 PVC 对应的 Status 列。
  5. 点所需的 Name 查看 PVC 详情。

11.3. 查看持久性卷声明请求事件

使用这个流程来查看和解决持久性卷声明 (PVC) 请求事件。

先决条件

  • 管理员对 OpenShift Web 控制台的访问权限。

流程

  1. 在 OpenShift Web 控制台中,点 Storage → Data Foundation
  2. Storage systems 选项卡中,选择存储系统,然后点 OverviewBlock and File
  3. 找到 Inventory 卡,查看 PVC 数量并显示错误。
  4. StoragePersistent Volume Claims
  5. 使用 Filter 文本框搜索所需的 PVC。
  6. 点 PVC 名称并导航到 Events
  7. 根据需要或按指示处理事件。

11.4. 动态置备

11.4.1. 关于动态置备

StorageClass 资源对象描述并分类了可请求的存储,并提供了根据需要为动态置备存储传递参数的方法。StorageClass 也可以作为控制不同级别的存储和访问存储的管理机制。集群管理员(cluster-admin)或者存储管理员(storage-admin)可以在无需了解底层存储卷资源的情况下,定义并创建用户可以请求的 StorageClass 对象。

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

很多存储类型都可用于 OpenShift Container Platform 中的持久性卷。虽然它们都可以由管理员静态置备,但有些类型的存储是使用内置供应商和插件 API 动态创建的。

11.4.2. OpenShift Data Foundation 中的动态置备

Red Hat OpenShift Data Foundation 是软件定义的存储,针对容器环境优化。它在 OpenShift Container Platform 上作为操作器运行,为容器提供高度集成和简化的持久性存储管理。

OpenShift Data Foundation 支持各种存储类型,包括:

  • 数据库的块存储
  • 共享文件存储,用于持续集成、消息传递和数据聚合
  • 归档、备份和介质存储的对象存储

第 4 版使用 Red Hat Ceph Storage 来提供支持持久卷的文件、块和对象存储,以及 Rook.io 来管理和编排持久卷和声明的调配。NooBaa 提供对象存储,其多云网关允许在多个云环境中联合对象(作为技术预览使用)。

在 OpenShift Data Foundation 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 文件中的条目。

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

 

Red Hat Virtualization

csi.ovirt.org

 
重要

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

第 12 章 卷快照

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

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

注意

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

12.1. 创建卷快照

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

先决条件

  • 对于一致的快照,PVC 应该处于 Bound 状态,且不使用。确保先停止所有 IO,然后再执行快照。
注意

只有 pod 使用时,OpenShift Data Foundation 才会为 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 状态。

12.2. 恢复卷快照

恢复卷快照时,会创建一个新的持久性卷声明 (PVC)。恢复的 PVC 独立于卷快照和父 PVC。

您可以从 PVC 页面或 Volume Snapshots 页面恢复卷快照。

流程

在持久性卷声明页中显示

只有在存在父 PVC 时,才可以从持久性卷声明页面恢复卷快照。

  1. 从 OpenShift Web 控制台点 StoragePersistent Volume Claims
  2. 点击 PVC 名称及卷快照将卷快照恢复为新 PVC。
  3. Volume Snapshots 选项卡中,点您要恢复的卷快照旁的 Action 菜单(⋮)。
  4. Restore 作为新 PVC
  5. 输入新 PVC 的名称。
  6. 选择 Storage Class 名。

    注意

    对于 Rados 块设备(RBD),您必须选择一个与父 PVC 池相同的存储类。使用未启用加密的存储类恢复加密 PVC 的快照,反之亦然。

  7. 选择您选择的 Access Mode

    重要

    ReadOnlyMany(ROX)访问模式是一个开发者预览功能,它受到开发人员预览支持的限制。开发人员预览版本不应在生产环境中运行,且不受红帽客户门户网站问题单管理系统的支持。如果您需要 ReadOnlyMany 功能的帮助,请联络 ocs-devpreview@redhat.com 邮件列表和红帽开发团队成员将根据可用性和工作计划尽快为您提供协助。请参阅 使用新的只读访问模式创建克隆或恢复快照以使用 ROX 访问模式。

  8. 可选:对于 RBD,请选择 卷模式
  9. 单击 Restore。您将被重定向到新的 PVC 详情页面。
从 Volume Snapshots 页面中
  1. 从 OpenShift Web 控制台点 StorageVolume Snapshots
  2. Volume Snapshots 选项卡中,点您要恢复的卷快照旁的 Action 菜单(⋮)。
  3. Restore 作为新 PVC
  4. 输入新 PVC 的名称。
  5. 选择 Storage Class 名。

    注意

    对于 Rados 块设备(RBD),您必须选择一个与父 PVC 池相同的存储类。使用未启用加密的存储类恢复加密 PVC 的快照,反之亦然。

  6. 选择您选择的 Access Mode

    重要

    ReadOnlyMany(ROX)访问模式是一个开发者预览功能,它受到开发人员预览支持的限制。开发人员预览版本不应在生产环境中运行,且不受红帽客户门户网站问题单管理系统的支持。如果您需要 ReadOnlyMany 功能的帮助,请联络 ocs-devpreview@redhat.com 邮件列表和红帽开发团队成员将根据可用性和工作计划尽快为您提供协助。请参阅 使用新的只读访问模式创建克隆或恢复快照以使用 ROX 访问模式。

  7. 可选:对于 RBD,请选择 卷模式
  8. 单击 Restore。您将被重定向到新的 PVC 详情页面。

验证步骤

  • 从 OpenShift Web 控制台点 StoragePersistent Volume Claims,并确认新 PVC 在 Persistent Volume Claims 页面中列出。
  • 等待新 PVC 进入 Bound 状态。

12.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 并确保不会列出删除的卷快照。

第 13 章 卷克隆

克隆是现有存储卷的副本,用作任何标准卷。您可以创建一个卷克隆,以达到数据的时间副本。持久性卷声明 (PVC) 不能使用不同的大小克隆。您可以为每个 PVC 为 CephFS 和 RADOS 块设备 (RBD) 创建最多 512 个克隆。

13.1. 创建克隆

先决条件

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

如果 Pod 正在使用 PVC,则不要创建 PVC 克隆。这样做可能会导致数据崩溃,因为 PVC 没有被静默(暂停)。

流程

  1. 从 OpenShift Web 控制台点 StoragePersistent Volume Claims
  2. 要创建克隆,请执行以下操作之一:

    • 在所需的 PVC 旁边,点 Action 菜单 (⋮)Clone PVC
    • 点击您要克隆的 PVC,然后点击 ActionsClone PVC
  3. 输入克隆的名称
  4. 选择您选择的访问模式。

    重要

    ReadOnlyMany(ROX)访问模式是一个开发者预览功能,它受到开发人员预览支持的限制。开发人员预览版本不应在生产环境中运行,且不受红帽客户门户网站问题单管理系统的支持。如果您需要 ReadOnlyMany 功能的帮助,请联络 ocs-devpreview@redhat.com 邮件列表和红帽开发团队成员将根据可用性和工作计划尽快为您提供协助。请参阅 使用新的只读访问模式创建克隆或恢复快照以使用 ROX 访问模式。

  5. 单击 Clone。您将被重定向到新的 PVC 详情页面。
  6. 等待克隆的 PVC 状态变为 Bound

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

第 14 章 替换存储节点

您可以选择以下步骤之一来替换存储节点:

14.1. 替换 Google Cloud installer 置备的基础架构上的操作节点

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

流程

  1. 登录 OpenShift Web 控制台并点击 ComputeNodes
  2. 确定需要替换的节点。记录其 Machine Name
  3. 使用以下命令将节点标记为不可调度:

    $ oc adm cordon <node_name>
  4. 使用以下命令排空节点:

    $ oc adm drain <node_name> --force --delete-emptydir-data=true --ignore-daemonsets
    重要

    此活动可能需要至少 5 到 10 分钟或更长时间。这一期间内生成的 Ceph 错误是临时的,在新节点标上并正常运行时自动解决。

  5. ComputeMachines。搜索所需的机器。
  6. 除了所需的机器外,点击 Action 菜单(⋮)Delete Machine
  7. 单击 Delete 以确认删除机器。会自动创建新机器。
  8. 等待新机器启动并过渡到 Running 状态。

    重要

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

  9. ComputeNodes,确认新节点是否处于 Ready 状态
  10. 使用以下任一方法之一将 OpenShift Data Foundation 标签应用到新节点:

    从用户界面
    1. 对于新节点,点击 Action Menu(⋮)Edit Labels
    2. 添加 cluster.ocs.openshift.io/openshift-storage 并点 Save
    使用命令行界面
    • 执行以下命令,将 OpenShift Data Foundation 标签应用到新节点:

      $ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""

验证步骤

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

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

    • csi-cephfsplugin-*
    • csi-rbdplugin-*
  3. 验证所有其他必需的 OpenShift 数据基础容器集是否都处于 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.2. 在 Google Cloud installer 置备的基础架构中替换失败的节点

执行此流程替换在 OpenShift Data Foundation 的 Google Cloud 安装程序置备的基础架构 (IPI) 上无法正常工作的故障节点。

流程

  1. 登录 OpenShift Web 控制台并点击 ComputeNodes
  2. 确定有故障的节点,再单击其 Machine Name
  3. 点击 Actions → Edit Annotations,然后点 Add More
  4. 添加 machine.openshift.io/exclude-node-draining 并点 Save
  5. ActionsDelete Machine,然后点 Delete
  6. 新机器会自动创建,等待新机器启动。

    重要

    此活动可能需要至少 5 到 10 分钟或更长时间。这一期间内生成的 Ceph 错误是临时的,在新节点标上并正常运行时自动解决。

  7. ComputeNodes,确认新节点是否处于 Ready 状态
  8. 使用以下任一方法之一将 OpenShift Data Foundation 标签应用到新节点:

    使用 Web 用户界面
    1. 对于新节点,点击 Action Menu(⋮)Edit Labels
    2. 添加 cluster.ocs.openshift.io/openshift-storage 并点 Save
    使用命令行界面
    • 执行以下命令,将 OpenShift Data Foundation 标签应用到新节点:

      $ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""
  9. [可选]:如果没有自动删除失败的 Google Cloud 实例,请从 Google Cloud 控制台终止实例。

验证步骤

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

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

    • csi-cephfsplugin-*
    • csi-rbdplugin-*
  3. 验证所有其他必需的 OpenShift 数据基础容器集是否都处于 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. 如果验证步骤失败,请联系红帽支持

第 15 章 替换存储设备

15.1. 在 Google Cloud installer 置备的基础架构中替换操作或失败的存储设备

当您需要替换 Google Cloud 安装程序置备的基础架构上动态创建的存储集群中的设备时,必须替换存储节点。有关如何替换节点的详情,请参考:

第 16 章 升级到 OpenShift Data Foundation

16.1. OpenShift Data Foundation 更新过程概述

本章可帮助您在所有 Red Hat OpenShift Data Foundation 部署(Internal、Internal-Attached 和 External)在次版本和 z-stream 之间升级。所有部署的升级过程都保持不变。

您可以通过启用自动更新(如果没有在 operator 安装过程中进行)或执行手工更新,在次版本间(如 4.9 和 4.10 间)或在 z-stream 更新之间(如 4.10.0 和 4.10.1 间)升级 OpenShift Data Foundation 及其组件。当新的 z-stream 版本可用时,如果更新策略被设置为 Automatic,升级过程会自动触发。

您还需要为内部和外部模式部署按照以下顺序升级 Red Hat OpenShift Data Foundation 的不同部分:

  1. 根据 OpenShift Container Platform 更新集群文档更新 OpenShift Container Platform。
  2. 更新 Red Hat OpenShift Data Foundation.

    1. 要准备断开连接的环境以获取更新,请参阅 Operator 指南,在受限网络中使用 Operator Lifecycle Manager,以便在使用时能够更新 OpenShift Data Foundation 和 Local Storage Operator。
    2. 有关在次版本间更新的信息,请参阅将 Red Hat OpenShift Data Foundation 4.9 更新至 4.10
    3. 有关 z-stream 版本之间的更新,请参阅将 Red Hat OpenShift Data Foundation 4.10.x 更新至 4.10.y
    4. 若要更新外部模式部署,还必须执行 更新 Red Hat OpenShift Data Foundation 外部机密 一节中的步骤。
    5. 如果使用本地存储,请更新 Local Storage operator。如果您不确定,请参阅检查 Local Storage Operator 部署

更新注意事项

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

  • Red Hat OpenShift Container Platform 版本与 Red Hat OpenShift Data Foundation 相同。

    如需有关 OpenShift Container Platform 和 Red Hat OpenShift Data Foundation 支持的组合的更多信息,请参阅 Interoperability Matrix

  • 只有在 Local Storage Operator 版本与 Red Hat OpenShift Container Platform 版本匹配时,才会完全支持 Local Storage Operator。
  • 灵活的扩展功能仅适用于 OpenShift Data Foundation 的新部署。如需更多信息,请参阅扩展存储指南

16.2. 将 Red Hat OpenShift Data Foundation 4.9 更新至 4.10

本章可帮助您在所有 Red Hat OpenShift Data Foundation 部署(非附加和外部)在次版本间进行升级。所有部署的升级过程都保持不变。唯一的区别在在升级后的结果。

  • 对于 Internal 和 Internal- attached 部署,升级 OpenShift Data Foundation 会升级所有 OpenShift Data Foundation 服务,包括后端 Ceph Storage 集群。
  • 对于外部模式部署,升级 OpenShift Data Foundation 会仅升级 OpenShift Data Foundation 服务,同时后端 Ceph 存储集群保持不变,需要单独升级。

    我们建议升级 RHCS 和 OpenShift Data Foundation,以获取新的功能支持、安全修复和其他程序错误修复。由于我们对 RHCS 升级没有强烈依赖,因此您可以先升级 OpenShift Data Foundation operator,然后再升级 RHCS 升级,或反之亦然。请参阅 解决方案 以了解更多关于 Red Hat Ceph Storage 版本的信息。

重要

不支持直接从 4.9 之前的版本升级到 4.10。

先决条件

  • 确保 OpenShift Container Platform 集群已更新至版本 4.10.X 的最新稳定版本,请参阅 更新集群
  • 确保 OpenShift Data Foundation 集群正常运行,数据具有弹性。

    • 进入到 Storage → Data Foundation → Storage Systems 选项卡,然后点存储系统名称。
    • 检查 Overview - Block and FileObject 选项卡的状态卡上绿色勾号。绿色勾号表示 存储集群对象服务数据弹性都是健康的。
  • 确保所有 OpenShift Data Foundation Pod(包括操作器 Pod)在 openshift-storage 命名空间中处于 Running 状态。

    要查看 pod 的状态,在 OpenShift Web 控制台中点 Workloads → Pods。从 Project 下拉列表中选择 openshift-storage

    注意

    如果禁用 Show default projects 选项,请使用切换按钮列出所有默认项目。

  • 确保您有足够的时间完成 OpenShift 数据基础更新过程,因为更新时间因集群中运行的 OSD 数量而异。

流程

  1. 在 OpenShift Web 控制台中,导航到 Operators → Installed Operators
  2. 选择 openshift-storage 项目。
  3. 点 OpenShift Data Foundation operator 名称。
  4. Subscription 标签页,点 Update Channel 下的链接。
  5. 选择 Stable-4.10 更新频道并进行保存
  6. 如果 Upgrade status 显示 requires approval,请单击 requires approval

    1. 在 Install Plan Details 页面中,单击 Preview Install Plan
    2. 检查安装计划并点 Approve

      等待 StatusUnknown 改为 Created

  7. 导航到 Operators → Installed Operators
  8. 选择 openshift-storage 项目。

    等待 OpenShift Data Foundation Operator Status 更改为 Up to date

验证步骤

  • 检查 OpenShift Data Foundation 名称下面的 Version,并检查 Operator 状态。

    • 导航到 Operators → Installed Operators,再选择 openshift-storage 项目。
    • 升级完成后,新版本会更新到 OpenShift 数据基础的新版本号,并通过绿色勾号更改 Succeeded 状态。
  • 验证 OpenShift Data Foundation 集群是否正常运行并且数据具有弹性。

    • 进入到 StorageData FoundationStorage Systems 选项卡,然后点存储系统名称。
    • 检查 Overview - Block 和 FileObject 选项卡的状态卡上绿色勾号。绿色勾号表示存储集群、对象服务和数据弹性是健康的。
  • 如果验证步骤失败,请联系红帽支持
重要

在更新外部模式部署后,还必须更新外部 secret。具体步骤,请参阅 更新 OpenShift 数据基础外部 secret

其它资源

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

16.3. 将 Red Hat OpenShift Data Foundation 4.10.x 更新至 4.10.y

本章可帮助您在所有 Red Hat OpenShift Data Foundation 部署(Internal、Internal-Attached 和 External)中升级 z-stream 版本。所有部署的升级过程都保持不变。唯一的区别在在升级后的结果。

  • 对于 Internal 和 Internal- attached 部署,升级 OpenShift Data Foundation 会升级所有 OpenShift Data Foundation 服务,包括后端 Ceph Storage 集群。
  • 对于外部模式部署,升级 OpenShift Data Foundation 会仅升级 OpenShift Data Foundation 服务,同时后端 Ceph 存储集群保持不变,需要单独升级。

    我们建议升级 RHCS 和 OpenShift Data Foundation,以获取新的功能支持、安全修复和其他程序错误修复。由于我们对 RHCS 升级没有强烈依赖,因此您可以先升级 OpenShift Data Foundation operator,然后再升级 RHCS 升级,或反之亦然。请参阅 解决方案 以了解更多关于 Red Hat Ceph Storage 版本的信息。

当新的 z-stream 发行版本可用时,升级过程会在更新策略被设置为 Automatic 时自动触发。如果更新策略被设置为 Manual,则使用以下步骤。

先决条件

  • 确保 OpenShift Container Platform 集群已更新至版本 4.10.X 的最新稳定版本,请参阅 更新集群
  • 确保 OpenShift Data Foundation 集群正常运行,数据具有弹性。

    • 进入到 Storage → Data Foundation → Storage Systems 选项卡,然后点存储系统名称。
    • 检查 Overview - Block 和 FileObject 选项卡的状态卡上绿色勾号。绿色勾号表示存储集群、对象服务和数据弹性是健康的。
  • 确保所有 OpenShift Data Foundation Pod(包括操作器 Pod)在 openshift-storage 命名空间中处于 Running 状态。

    要查看 pod 的状态,在 OpenShift Web 控制台中点 Workloads → Pods。从 Project 下拉列表中选择 openshift-storage

    注意

    如果禁用 Show default projects 选项,请使用切换按钮列出所有默认项目。

  • 确保您有足够的时间完成 OpenShift 数据基础更新过程,因为更新时间因集群中运行的 OSD 数量而异。

流程

  1. 在 OpenShift Web 控制台中,导航到 Operators → Installed Operators
  2. 选择 openshift-storage 项目。

    注意

    如果禁用 Show default projects 选项,请使用切换按钮列出所有默认项目。

  3. 单击 OpenShift Data Foundation 操作器名称。
  4. Subscription 标签页。
  5. 如果 Upgrade Status 显示 需要批准,请单击 require approval 链接。
  6. InstallPlan Details 页面中点 Preview Install Plan
  7. 检查安装计划并点 Approve
  8. 等待 Status 从 Unknown 变为 Created

验证步骤

  • 检查 OpenShift Data Foundation 名称下面的 Version,并检查 Operator 状态。

    • 导航到 Operators → Installed Operators,再选择 openshift-storage 项目。
    • 升级完成后,新版本会更新到 OpenShift 数据基础的新版本号,并通过绿色勾号更改 Succeeded 状态。
  • 验证 OpenShift 数据基础集群是否正常运行并且数据具有弹性。

    • 进入到 Storage → Data Foundation → Storage Systems 选项卡,然后点存储系统名称。
    • 检查 Overview - Block 和 FileObject 选项卡的状态卡上绿色勾号。绿色勾号表示存储集群、对象服务和数据弹性是健康的
  • 如果验证步骤失败,请联系红帽支持

16.4. 更改更新批准策略

为确保在同一频道中有新更新时自动更新存储系统,我们建议把更新批准策略设置为 Automatic。将更新批准策略更改为 Manual 需要在每次升级时手动批准。

流程

  1. 导航到 Operators → Installed Operators
  2. Project 下拉列表中选择 openshift-storage

    注意

    如果禁用 Show default projects 选项,请使用切换按钮列出所有默认项目。

  3. 单击 OpenShift Data Foundation operator 名称
  4. 转至 订阅 选项卡。
  5. 单击 铅笔 图标以更改 更新批准
  6. 选择更新批准策略并点 Save

验证步骤

  • 验证 Update 批准显示了它下面新选择的批准策略。
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.