使用 Red Hat OpenStack Platform 部署和管理 OpenShift Data Foundation
在 Red Hat OpenStack Platform 上部署和管理 OpenShift Data Foundation 的说明
摘要
使开源包含更多
红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始：master、slave、黑名单和白名单。由于此项工作十分艰巨，这些更改将在即将推出的几个发行版本中逐步实施。详情请查看 CTO Chris Wright 的信息。
对红帽文档提供反馈
我们感谢您对文档提供反馈信息。请告诉我们如何让它更好。
要提供反馈，请创建一个 Bugzilla ticket：
- 进入 Bugzilla 网站。
- 在 Component 部分中，选择 文档。
- 在 Description 中输入您要提供的信息。包括文档相关部分的链接。
- 点 Submit Bug。
前言
Red Hat OpenShift Data Foundation 4.8 支持使用 Red Hat OpenStack Platform 集群在现有 Red Hat OpenShift Container Platform (RHOCP) 上部署。
Red Hat OpenStack Platform 支持内部和外部 OpenShift Data Foundation 集群。如需有关部署要求的更多信息，请参阅规划部署。
要部署 OpenShift Data Foundation，请从准备部署 OpenShift Data Foundation 章节的要求开始，并根据您的要求遵循适当的部署流程：
第 1 章 准备部署 OpenShift 数据基础
使用动态存储设备在 OpenShift Container Platform 上部署 OpenShift Data Foundation 为您提供创建内部集群资源的选项。这将会在内部置备基础服务，这有助于为应用提供额外的存储类。
在开始部署 Red Hat OpenShift Data Foundation 前，请按照以下步骤执行：
可选：如果要使用外部密钥管理系统 (KMS) HashiCorp Vault 启用集群范围加密，请按照以下步骤执行：
- 确定您有有效的 Red Hat OpenShift Data Foundation Advanced 订阅。要了解 OpenShift Data Foundation 订阅如何工作，请参阅与 OpenShift Data Foundation 订阅相关的知识库文章。
- 当为加密选择 Token 验证方法时，请参考使用 KMS 通过 Token 身份验证启用集群范围的加密。
- 当为加密选择了 Kubernetes 验证方法时，请参考使用 KMS 使用 Kubernetes 身份验证启用集群范围的加密。
- 确保您在 Vault 服务器上使用签名的证书。
可选： 如果要使用外部密钥管理系统 (KMS) Thales CipherTrust Manager 启用集群范围的加密，您必须首先启用密钥管理互操作性协议 (KMIP)，并在服务器上使用签名证书。按照以下步骤操作：
如果 KMIP 客户端不存在，请创建一个。在用户界面中，选择 KMIP → Client Profile → Add Profile。
-
在创建配置集的过程中，将
CipherTrust用户名添加到 Common Name 字段中。
-
在创建配置集的过程中，将
- 通过进入到 KMIP → Registration Token → New Registration Token 来创建令牌。为下一步复制令牌。
- 要注册客户端，请进入到 KMIP → Registered Clients → Add Client。指定名称。粘贴上一步中的注册令牌，然后点保存。
- 点 Save Private Key 和 Save Certificate 下载私钥和客户端证书。
要创建新的 KMIP 接口，请进入到 Admin Settings → Interfaces → Add Interface。
- 选择 KMIP Key Management Interoperability Protocol 并点 Next。
- 选择一个空闲端口。
- 为 Network Interface 选择 all。
- 为 Interface Mode 选择 TLS, verify client cert, user name taken from client cert, auth request is optional。
- （可选）您可以在密钥被删除时启用硬删除以删除元数据和材料。它默认是禁用的。
- 选择要使用的 CA，然后点 Save。
- 要获取服务器 CA 证书，请点新创建的界面右侧的 Action 菜单(⋮)，然后点 Download Certificate。
可选： 如果要在部署过程中启用 StorageClass 加密，请创建一个密钥来充当密钥加密密钥 (KEK)：
- 进入到 Keys → Add Key。
- 输入 Key Name。
- 分别将 Algorithm 和 Size 设置为 AES 和 256。
- 启用 Create a key in Pre-Active state，并设置激活的日期和时间。
- 确保在 Key Usage 下启用了 Encrypt 和 Decrypt。
- 复制新创建的密钥的 ID，以在部署过程中用作唯一标识符。
启动节点最低要求
当不符合标准部署资源要求时，将使用最低配置部署 OpenShift Data Foundation 集群。请参阅规划指南中的资源要求部分。
实现灾难恢复的要求 [技术预览]
Red Hat OpenShift Data Foundation 支持的灾难恢复功能需要满足以下所有先决条件，才能成功实施灾难恢复解决方案：
- 有效的 Red Hat OpenShift Data Foundation 高级订阅
有效的 Red Hat Advanced Cluster Management for Kubernetes 订阅
要了解 OpenShift Data Foundation 订阅如何工作，请参阅与 OpenShift Data Foundation 订阅相关的知识库文章。
如需更多信息，请参阅 Configuring OpenShift Data Foundation Disaster Recovery for OpenShift Workloads 指南，以及 Red Hat Advanced Cluster Management for Kubernetes 文档中的安装指南中的 Requirements and recommendations 部分。
第 2 章 以内部模式在 Red Hat OpenStack Platform 上部署 OpenShift Data Foundation
使用 Red Hat OpenStack Platform 安装程序置备的基础架构 (IPI) 提供的动态存储设备在 OpenShift Container Platform 上部署 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 节点。每个节点都应该包含一个磁盘，需要 3 个磁盘(PV)。但是，一个 PV 最终会默认未使用。这是预期的行为。
- 有关其他资源要求，请参阅规划您的部署指南。
当您需要覆盖 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 部分。
流程
- 登录 OpenShift Web 控制台。
- 点 Operators → OperatorHub。
-
在 Filter by keyword 框中滚动或键入
OpenShift Data Foundation，以查找 OpenShift Data Foundation Operator。 - 点 Install。
在 Install Operator 页面中设置以下选项：
- 更新频道为 stable-4.12。
- 安装模式是 A specific namespace on the cluster。
-
Installed Namespace 为 Operator recommended namespace openshift-storage。如果命名空间
openshift-storage不存在，它会在 Operator 安装过程中创建。 将 Approval Strategy 选为 Automatic 或 Manual。
如果选择 Automatic 更新，Operator Lifecycle Manager(OLM)将自动升级 Operator 的运行实例，而无需任何干预。
如果选择 手动 更新，则 OLM 会创建一个更新请求。作为集群管理员，您必须手动批准该更新请求，才能将 Operator 更新至更新的版本。
- 确保为 Console 插件 选择了 Enable 选项。
- 点 Install。
验证步骤
-
成功安装 Operator 后，用户界面中会显示一个带有
Web console update is available信息的弹出窗口。点这个弹出窗口中的 Refresh web console 来反映控制台的更改。 在 Web 控制台中：
- 进入到 Installed Operators，再验证 OpenShift Data Foundation Operator 是否显示绿色勾号，指示安装成功。
- 进入到 Storage，再验证 Data Foundation 仪表板是否可用。
2.2. 使用 Token 验证方法通过 KMS 启用集群范围的加密
您可以在密码库中启用用于令牌身份验证的键值后端路径和策略。
先决条件
- 管理员对 vault 的访问权限。
- 有效的 Red Hat OpenShift Data Foundation 高级订阅。如需更多信息，请参阅 OpenShift Data Foundation 订阅中的知识库文章。
-
仔细选择唯一路径名称作为遵循命名惯例的后端
路径，因为它无法在以后更改。
流程
在密码库中启用 Key/Value(KV)后端路径。
对于 vault KV 机密引擎 API，版本 1：
$ vault secrets enable -path=odf kv
对于 vault KV 机密引擎 API，版本 2：
$ vault secrets enable -path=odf kv-v2
创建策略来限制用户在 secret 上执行写入或删除操作：
echo ' path "odf/*" { capabilities = ["create", "read", "update", "delete", "list"] } path "sys/mounts" { capabilities = ["read"] }'| vault policy write odf -创建与上述策略匹配的令牌：
$ 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 安装。
-
仔细选择唯一路径名称作为后端
路径，请仔细选择命名规则。您不能在以后更改此路径名称。
流程
创建服务帐户：
$ oc -n openshift-storage create serviceaccount <serviceaccount_name>
其中,
<serviceaccount_name>指定服务帐户的名称。例如：
$ oc -n openshift-storage create serviceaccount odf-vault-auth
创建
clusterrolebindings和clusterroles:$ 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
为
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>是上一步中创建的服务帐户。从 secret 获取令牌和 CA 证书。
$ SA_JWT_TOKEN=$(oc -n openshift-storage get secret odf-vault-auth-token -o jsonpath="{.data['token']}" | base64 --decode; echo) $ SA_CA_CRT=$(oc -n openshift-storage get secret odf-vault-auth-token -o jsonpath="{.data['ca\.crt']}" | base64 --decode; echo)检索 OCP 集群端点。
$ OCP_HOST=$(oc config view --minify --flatten -o jsonpath="{.clusters[0].cluster.server}")获取服务帐户签发者：
$ oc proxy & $ proxy_pid=$! $ issuer="$( curl --silent http://127.0.0.1:8001/.well-known/openid-configuration | jq -r .issuer)" $ kill $proxy_pid
使用上一步中收集的信息在 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"在 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
创建策略来限制用户在 secret 上执行
写入或删除操作：echo ' path "odf/*" { capabilities = ["create", "read", "update", "delete", "list"] } path "sys/mounts" { capabilities = ["read"] }'| vault policy write odf -生成角色：
$ 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 安装。如需更多信息，请参阅使用 Operator Hub 安装 OpenShift Data Foundation Operator。
流程
在 OpenShift Web 控制台中，点 Operators → Installed Operators 查看所有已安装的 Operator。
确保所选 项目 为
openshift-storage。- 点 OpenShift Data Foundation 操作器，然后单击 Create StorageSystem。
在 Backing storage 页面中，选择以下内容：
- 为 Deployment 类型选项选择 Full Deployment。
- 选择 Use a existing StorageClass 选项。
选择 Storage Class。
默认情况下，设置为
standard。- 点 Next。
在 Capacity and nodes 页面中，提供必要的信息：
从下拉列表中选择 Requested Capacity 的值。默认设置为
2 TiB。注意选择初始存储容量后，集群扩展将使用所选的可用容量（原始存储的三倍）执行。
- 在 Select Nodes 部分中，选择至少三个可用节点。
可选：选中 Taint nodes 复选框，以将所选节点专用于 OpenShift Data Foundation。
对于具有多个可用区的云平台，请确保节点分布在不同的位置/可用性区域。
如果选择的节点与聚合的 30 个 CPU 和 72 GiB RAM 的 OpenShift Data Foundation 集群要求不匹配，则会部署最小的集群。如需最低起始节点要求，请参阅 规划指南中的资源要求部分。
- 点 Next。
可选：在 Security and network 页面中，根据您的要求进行配置：
- 若要启用加密，可选择为块存储和文件存储启用数据加密。
选择其中一个加密级别或两个都选：
集群范围的加密
加密整个集群（块和文件）。
StorageClass 加密
使用启用加密的存储类创建加密的持久性卷（仅块）。
可选：选择 Connect to an external key management service 复选框。这是集群范围加密的可选选项。
- 从 Key Management Service Provider 下拉列表中，选择 Vault 或 Thales CipherTrust Manager (using KMIP)。如果选择了 Vault，请进入下一步。如果您选择了 Thales CipherTrust Manager （using KMIP），请转到步骤 iii。
选择身份验证方法。
- 使用令牌验证方法
- 输入唯一的连接名称 , Vault 服务器的主机地址（'https://<hostname 或 ip>'），端口号和令牌。
展开 Advanced Settings，以根据您的
Vault配置输入其他设置和证书详情：- 在 后端路径中输入为 OpenShift Data Foundation 专用且唯一的 Key Value secret 路径。
- （可选）输入 TLS 服务器名称和 Vault Enterprise 命名空间。
- 上传对应的 PEM 编码证书文件，以提供 CA 证书、客户端证书和客户端私钥。
- 点 Save 并跳过步骤 iv。
- 使用 Kubernetes 验证方法
- 输入唯一的 Vault Connection Name, Vault 服务器的主机地址（'https://<hostname 或 ip>'）、端口号和角色名称。
展开 Advanced Settings，以根据您的
Vault配置输入其他设置和证书详情：- 在 后端路径中输入为 OpenShift Data Foundation 专用且唯一的 Key Value secret 路径。
- 可选：输入 TLS Server Name 和 Authentication Path （如果适用）。
- 上传对应的 PEM 编码证书文件，以提供 CA 证书、客户端证书和客户端私钥。
- 点 Save 并跳过步骤 iv。
要使用 Thales CipherTrust Manager (using KMIP) 作为 KMS 供应商，请按照以下步骤执行：
- 在项目中输入密钥管理服务的唯一连接名称。
在 Address 和 Port 部分中，输入 Thales CipherTrust Manager 的 IP 以及在其中启用了 KMIP 接口的端口。例如：
- 地址: 123.34.3.2
- 端口 ：5696
- 上传 客户端证书、CA 证书和 客户端私钥。
- 如果启用了 StorageClass 加密，请输入用于加密和解密的唯一标识符。
-
TLS Server 字段是可选的，并在没有 KMIP 端点的 DNS 条目时使用。例如，
kmip_all_<port>.ciphertrustmanager.local。
- 选择 网络。
- 点 Next。
在 Review and create 页面中，检查配置详情。
若要修改任何配置设置，请单击 Back。
- 单击 Create StorageSystem。
验证步骤
验证已安装存储集群的最终状态：
- 在 OpenShift Web 控制台中，导航到 Installed Operators → OpenShift Data Foundation → Storage System → ocs-storagecluster-storagesystem → Resources。
-
验证
StorageCluster的Status是否为Ready，并且旁边有一个绿色勾号标记。
- 要验证 OpenShift Data Foundation 是否已成功安装，请参阅验证您的 OpenShift Data Foundation 部署。
其他资源
要启用 Overprovision Control 警报，请参阅 Monitoring 中的 Alerts 指南。
2.5. 验证 OpenShift Data Foundation
使用本节验证 OpenShift Data Foundation 是否已正确部署。
2.5.1. 验证 pod 的状态
流程
- 从 OpenShift Web 控制台点 Workloads → Pods。
从 Project 下拉列表中选择
openshift-storage。注意如果禁用 Show default projects 选项，请使用切换按钮列出所有默认项目。
有关每个组件预期的 pod 数量及其变化取决于节点数量的更多信息，请参阅 表 2.1 “对应 OpenShift Data Foundation 集群的 Pod”。
为 Running 和 Completed pod 设置过滤器，以验证以下 pod 是否处于
Running和Completed状态：表 2.1. 对应 OpenShift Data Foundation 集群的 Pod
组件 对应的 pod OpenShift Data Foundation Operator
-
ocs-operator114（任何存储节点上 1 个 pod） -
ocs-metrics-exporter（任何存储节点上 1 个 pod） -
odf-operator-controller-manager-*（任何存储节点上 1 个 pod） -
odf-console-*任何存储节点上 1 个 pod） -
csi-addons-controller-manager-*（任何存储节点上 1 个 pod）
Rook-ceph Operator
rook-ceph-operator-*（任何存储节点上的 1 个 pod）
多云对象网关
-
noobaa-operator-*（任何存储节点上 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-*（每个存储节点上 1 个 pod） -
csi-cephfsplugin-provisioner-*（2 个 pod 在存储节点间分布）
-
rbd-
csi-rbdplugin-*（每个存储节点上 1 个 pod） -
csi-rbdplugin-provisioner-*（2 个 pod 在存储节点间分布）
-
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 集群是否健康
流程
- 在 OpenShift Web 控制台中，点 Storage → Data Foundation。
- 在 Overview 选项卡的 Status 卡中，点 Storage System，然后点弹出框中的存储系统链接。
- 在 Block and File 选项卡的 Status 卡中，验证 Storage Cluster 是否具有绿色勾号。
- 在 Details 卡中，验证是否显示集群信息。
如需有关使用 Block and File 仪表板的 OpenShift Data Foundation 集群健康的更多信息，请参阅 监控 OpenShift Data Foundation。
2.5.3. 验证 Multicloud 对象网关是否健康
流程
- 在 OpenShift Web 控制台中，点 Storage → Data Foundation。
在 Overview 选项卡的 Status 卡中，点 Storage System，然后点弹出框中的存储系统链接。
- 在 Object 选项卡的 Status 卡 中，验证 Object Service 和数据弹性 都具有绿色勾号。
- 在 Details 卡中，验证是否显示了 MCG 信息。
如需有关使用对象服务仪表板的 OpenShift Data Foundation 集群健康的更多信息，请参阅监控 OpenShift Data Foundation。
2.5.4. 验证特定的存储类是否存在
流程
- 从 OpenShift Web 控制台左侧窗格中，点击 Storage → Storage Classes。
验证是否在创建 OpenShift Data Foundation 集群时创建了以下存储类：
-
ocs-storagecluster-ceph-rbd -
ocs-storagecluster-cephfs -
openshift-storage.noobaa.io
-
2.6. 卸载 OpenShift Data Foundation
2.6.1. 以内部模式卸载 OpenShift Data Foundation
要以内部模式卸载 OpenShift Data Foundation，请参阅 有关卸载 OpenShift Data Foundation 的知识库文章。
第 3 章 以外部模式在 Red Hat OpenStack Platform 上部署 OpenShift Data Foundation
Red Hat OpenShift Data Foundation 可以使用外部托管的 Red Hat Ceph Storage (RHCS) 集群作为 Red Hat OpenStack Platform 上的存储供应商。如需更多信息，请参阅规划部署。
有关如何安装 RHCS 集群的说明，请参阅安装指南。
按照以下步骤，以外部模式部署 OpenShift Data Foundation：
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 节点。每个节点都应该包含一个磁盘，需要 3 个磁盘(PV)。但是，一个 PV 最终会默认未使用。这是预期的行为。
- 有关其他资源要求，请参阅规划您的部署指南。
当您需要覆盖 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 部分。
流程
- 登录 OpenShift Web 控制台。
- 点 Operators → OperatorHub。
-
在 Filter by keyword 框中滚动或键入
OpenShift Data Foundation，以查找 OpenShift Data Foundation Operator。 - 点 Install。
在 Install Operator 页面中设置以下选项：
- 更新频道为 stable-4.12。
- 安装模式是 A specific namespace on the cluster。
-
Installed Namespace 为 Operator recommended namespace openshift-storage。如果命名空间
openshift-storage不存在，它会在 Operator 安装过程中创建。 将 Approval Strategy 选为 Automatic 或 Manual。
如果选择 Automatic 更新，Operator Lifecycle Manager(OLM)将自动升级 Operator 的运行实例，而无需任何干预。
如果选择 手动 更新，则 OLM 会创建一个更新请求。作为集群管理员，您必须手动批准该更新请求，才能将 Operator 更新至更新的版本。
- 确保为 Console 插件 选择了 Enable 选项。
- 点 Install。
验证步骤
-
成功安装 Operator 后，用户界面中会显示一个带有
Web console update is available信息的弹出窗口。点这个弹出窗口中的 Refresh web console 来反映控制台的更改。 在 Web 控制台中：
- 进入到 Installed Operators，再验证 OpenShift Data Foundation Operator 是否显示绿色勾号，指示安装成功。
- 进入到 Storage，再验证 Data Foundation 仪表板是否可用。
3.2. 为外部模式创建 OpenShift Data Foundation 集群
在 Red Hat OpenStack 平台上部署的 OpenShift Container Platform 上安装 OpenShift Data Foundation operator 后，需要创建新的 OpenShift Data Foundation 集群。
先决条件
- 在部署 OpenShift Data Foundation 4.12 之前，请确保 OpenShift Container Platform 版本为 4.12 或更高版本。
- 必须安装 OpenShift Data Foundation 操作器。如需更多信息，请参阅使用 Operator Hub 安装 OpenShift Data Foundation Operator。
要以外部模式检查 Red Hat Ceph Storage (RHCS) 与 Red Hat OpenShift Data Foundation 的支持性和互操作性，请转至 lab Red Hat OpenShift Data Foundation 支持性和互操作性检查器。
-
选择 Service Type 为
ODF as Self-Managed Service。 - 从下拉菜单中选择适当的 Version。
- 在 Versions 选项卡中，点 支持的 RHCS 兼容性选项卡。
-
选择 Service Type 为
如果您已将红帽 Ceph 存储集群从低于 4.1.1 的版本更新为最新版本，且不是全新部署的集群，您必须在红帽 Ceph 存储集群中手动设置 CephFS 池的应用类型，以外部模式启用 CephFS PVC 创建。
如需了解更多详细信息，请参阅在外部模式中对 CephFS PVC 创建进行故障排除。
- Red Hat Ceph Storage 必须安装并配置 Ceph 控制面板。如需更多信息，请参阅 Ceph 控制面板安装和访问。
- 红帽建议外部 Red Hat Ceph Storage 集群启用 PG Autoscaler。如需更多信息，请参阅 Red Hat Ceph Storage 文档中的放置组自动扩展部分。
- 外部 Ceph 集群应当预配置有一个现有的 RBD 池，供使用。如果不存在，请在进行 OpenShift Data Foundation 部署前，联系您的 Red Hat Ceph Storage 管理员创建一个。红帽建议为每个 OpenShift Data Foundation 集群使用单独的池。
流程
点 Operators → Installed Operators 查看所有已安装的 Operator。
确保所选 项目 为
openshift-storage。- 点 OpenShift Data Foundation → Create Instance of Storage Cluster 链接。
将 Mode 选择为 External。默认情况下，Internal 被选为部署模式。
图 3.1. 连接到创建存储集群表单上的外部集群部分
- 在 Connect to external cluster 部分中，单击 Download Script 链接，以下载用于提取 Ceph 集群详细信息的 python 脚本。
要提取 Red Hat Ceph Storage (RHCS) 集群详情，请联系 RHCS 管理员，以在带有
admin 密钥的 Red Hat Ceph Storage 节点上运行下载的 python 脚本。在 RHCS 节点上运行以下命令，以查看可用参数的列表：
# python3 ceph-external-cluster-details-exporter.py --help
重要如果在 Red Hat Enterprise Linux 7.x (RHEL 7.x) 集群中部署了 Red Hat Ceph Storage 4.x 集群，则使用
python而不是python3。注意您也可以从 MON 容器（容器化部署）或 MON 节点（rpm 部署）运行 脚本。
要从 RHCS 集群检索外部集群详情，请运行以下命令
# python3 ceph-external-cluster-details-exporter.py \ --rbd-data-pool-name <rbd block pool name> [optional arguments]
例如：
# python3 ceph-external-cluster-details-exporter.py --rbd-data-pool-name ceph-rbd --monitoring-endpoint xxx.xxx.xxx.xxx --monitoring-endpoint-port xxxx --rgw-endpoint xxx.xxx.xxx.xxx:xxxx --run-as-user client.ocs
在上面的示例中，
-
--RBD-data-pool-name是用于在 OpenShift Data Foundation 中提供块存储的强制参数。 -
--rgw-endpoint是可选的。如果要通过 Ceph Rados 网关为 OpenShift Data Foundation 置备对象存储，请提供此参数。使用以下格式提供端点：<ip_address>:<port> -
--monitoring-endpoint是可选的。它是可从 OpenShift 容器平台集群访问的活动ceph-mgr的 IP 地址。如果没有提供，则会自动填充该值。 -
--monitoring-endpoint-port是可选的。它是与--monitoring-endpoint指定的ceph-mgrPrometheus exporter 关联的端口。如果没有提供，则会自动填充该值。 -- run-as-user是一个可选参数，用于为 Ceph 用户提供由 脚本创建的名称。如果没有指定此参数，则会创建一个默认的用户名client.healthchecker。新用户的权限被设置为：- caps: [mgr] allow command config
- caps: [mon] allow r, allow command quorum_status, allow command version
caps: [osd] allow rwx pool=
RGW_POOL_PREFIX.rgw.meta, allow r pool=.rgw.root, allow rw pool=RGW_POOL_PREFIX.rgw.control, allow rx pool=RGW_POOL_PREFIX.rgw.log, allow x pool=RGW_POOL_PREFIX.rgw.buckets.index使用 python 脚本生成的 JSON 输出示例：
[{"name": "rook-ceph-mon-endpoints", "kind": "ConfigMap", "data": {"data": "xxx.xxx.xxx.xxx:xxxx", "maxMonId": "0", "mapping": "{}"}}, {"name": "rook-ceph-mon", "kind": "Secret", "data": {"admin-secret": "admin-secret", "fsid": "<fs-id>", "mon-secret": "mon-secret"}}, {"name": "rook-ceph-operator-creds", "kind": "Secret", "data": {"userID": "client.healthchecker", "userKey": "<user-key>"}}, {"name": "rook-csi-rbd-node", "kind": "Secret", "data": {"userID": "csi-rbd-node", "userKey": "<user-key>"}}, {"name": "ceph-rbd", "kind": "StorageClass", "data": {"pool": "ceph-rbd"}}, {"name": "monitoring-endpoint", "kind": "CephCluster", "data": {"MonitoringEndpoint": "xxx.xxx.xxx.xxx", "MonitoringPort": "xxxx"}}, {"name": "rook-csi-rbd-provisioner", "kind": "Secret", "data": {"userID": "csi-rbd-provisioner", "userKey": "<user-key>"}}, {"name": "rook-csi-cephfs-provisioner", "kind": "Secret", "data": {"adminID": "csi-cephfs-provisioner", "adminKey": "<admin-key>"}}, {"name": "rook-csi-cephfs-node", "kind": "Secret", "data": {"adminID": "csi-cephfs-node", "adminKey": "<admin-key>"}}, {"name": "cephfs", "kind": "StorageClass", "data": {"fsName": "cephfs", "pool": "cephfs_data"}}, {"name": "ceph-rgw", "kind": "StorageClass", "data": {"endpoint": "xxx.xxx.xxx.xxx:xxxx", "poolPrefix": "default"}}]
-
将 JSON 输出保存到带有
.json扩展名的文件注意要使 OpenShift Data Foundation 无缝工作，请确保使用 JSON 文件上传的参数（RGW 端点、CephFS 详细信息和 RBD 池等）在创建存储集群后在 RHCS 外部集群上保持不变。
点 External cluster metadata → Browse 来选择并上传 JSON 文件。
JSON 文件的内容填充并在文本框中显示。
图 3.2. JSON 文件内容
点 Create。
Create 按钮只有在上传
.json文件后才会启用。
验证步骤
验证已安装存储集群的最后一个 Status 显示为
Phase: Ready，并带有绿色勾号标记。- 点 Operators → Installed Operators → Storage Cluster 链接来查看存储集群安装状态。
- 另外，当使用 Operator Details 选项卡时，您可以点击 Storage Cluster 选项卡查看状态。
- 要验证 OpenShift Data Foundation、Pod 和 StorageClass 是否已成功安装，请参阅验证外部模式 OpenShift Data Foundation 安装。
3.3. 验证您的 OpenShift Data Foundation 安装的外部模式
使用本节验证 OpenShift Data Foundation 是否已正确部署。
3.3.1. 验证 pod 的状态
- 从 OpenShift Web 控制台左侧窗格中，点击 Workloads → Pods。
从 Project 下拉列表中选择
openshift-storage。注意如果禁用 Show default projects 选项，请使用切换按钮列出所有默认项目。
有关每个组件预期的 pod 数量及其变化取决于节点数量的更多信息，请参阅 表 3.1 “对应 OpenShift Data Foundation 组件的 Pod”
验证以下 pod 是否处于运行状态：
表 3.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-*（任何 worker 节点上有 1 个 pod） -
noobaa-db-pg-*（任何 worker 节点上有 1 个 pod） -
noobaa-endpoint-*（任何 worker 节点上有 1 个 pod）
CSI
cephfs-
csi-cephfsplugin-*(每个 worker 节点上 1 个 pod) -
csi-cephfsplugin-provisioner-*（2 个 pod 在不同的 worker 节点上分布）
-
注意如果没有在外部集群中部署 MDS，则不会创建 csi-cephfs 插件 pod。
rbd-
csi-rbdplugin-*(每个 worker 节点上 1 个 pod) -
csi-rbdplugin-provisioner-*（2 个 pod 在不同的 worker 节点上分步）
-
-
3.3.2. 验证 OpenShift Data Foundation 集群是否健康
- 在 OpenShift Web 控制台中，点 Storage → Data Foundation。
- 在 Overview 选项卡的 Status 卡中，点 Storage System，然后点弹出框中的存储系统链接。
- 在 Block and File 选项卡的 Status 卡中，验证 Storage Cluster 和 Data Resiliency 是否都具有绿色勾号。
在 Details 卡中，验证集群信息是否显示如下。
+ Service Name:: OpenShift Data Foundation Cluster Name:: ocs-external-storagecluster Provider:: OpenStack Mode:: External Version:: ocs-operator-4.12.0
有关使用 Block and File 仪表板的 OpenShift Data Foundation 健康状况的更多信息，请参阅监控 OpenShift Data Foundation。
3.3.3. 验证 Multicloud 对象网关是否健康
- 在 OpenShift Web 控制台中，点 Storage → Data Foundation。
在 Overview 选项卡的 Status 卡中，点 Storage System，然后点弹出框中的存储系统链接。
- 在 Object 选项卡的 Status 卡中，验证 Object Service 和数据弹性都具有绿色勾号。
- 在 Details 卡中，验证 Multicloud Object Gateway(MCG)信息是否已显示。
RADOS 对象网关仅列出在以外部模式部署 OpenShift Data Foundation 时包含 RADOS 对象网关端点详细信息的情况。
有关使用对象仪表板的 OpenShift Data Foundation 健康状况的更多信息，请参阅监控 OpenShift Data Foundation。
3.3.4. 验证存储类是否已创建并列出
- 从 OpenShift Web 控制台左侧窗格中，点击 Storage → Storage Classes。
验证是否在创建 OpenShift Data Foundation 集群时创建了以下存储类：
-
ocs-external-storagecluster-ceph-rbd -
ocs-external-storagecluster-ceph-rgw -
ocs-external-storagecluster-cephfs -
openshift-storage.noobaa.io
-
-
如果没有在外部集群中部署 MDS，则不会创建
ocs-external-storagecluster-cephfs存储类。 -
如果没有在外部集群中部署 RGW，则不会创建
ocs-external-storagecluster-ceph-rgw存储类。
如需有关 MDS 和 RGW 的更多信息，请参阅 Red Hat Ceph Storage 文档
3.3.5. 验证 Ceph 集群是否已连接
运行以下命令，以验证 OpenShift Data Foundation 集群是否已连接到外部 Red Hat Ceph Storage 集群。
$ oc get cephcluster -n openshift-storage
NAME DATADIRHOSTPATH MONCOUNT AGE PHASE MESSAGE HEALTH ocs-external-storagecluster-cephcluster 31m15s Connected Cluster connected successfully HEALTH_OK
3.3.6. 验证存储集群是否已就绪
运行以下命令，以验证存储集群是否已就绪，并且 External 选项设为 true。
$ oc get storagecluster -n openshift-storage
NAME AGE PHASE EXTERNAL CREATED AT VERSION ocs-external-storagecluster 31m15s Ready true 2021-02-29T20:43:04Z 4.8.0
3.4. 卸载 OpenShift Data Foundation
3.4.1. 从外部存储系统卸载 OpenShift Data Foundation
使用本节中的步骤卸载 OpenShift Data Foundation。卸载 OpenShift Data Foundation 不会从外部集群中删除 RBD 池，或卸载外部 Red Hat Ceph Storage 集群。
卸载注解
Storage Cluster 上的注解用于更改卸载过程的行为。要定义卸载行为，在存储集群中引入了以下两个注解：
-
uninstall.ocs.openshift.io/cleanup-policy: delete -
uninstall.ocs.openshift.io/mode: graceful
uninstall.ocs.openshift.io/cleanup-policy 不适用于外部模式。
下表提供了有关可用于这些注解的不同值的信息：
表 3.2. uninstall.ocs.openshift.io 卸载注解描述
| 注解 | 值 | 默认值 | 行为 |
|---|---|---|---|
| cleanup-policy | delete | 是 |
Rook 清理物理驱动器和 |
| cleanup-policy | retain | 否 |
Rook 不会清理物理驱动器和 |
| 模式 | graceful | 是 | Rook 和 NooBaa 暂停卸载过程，直到管理员/用户移除 PVC 和 OBC |
| 模式 | forced | 否 | rook 和 NooBaa 会在卸载过程中继续进行，即使 PVC/OBCs 使用 Rook 和 NooBaa 置备 |
您可以通过使用以下命令编辑注解值来更改卸载模式：
$ oc annotate storagecluster ocs-external-storagecluster -n openshift-storage uninstall.ocs.openshift.io/mode="forced" --overwrite storagecluster.ocs.openshift.io/ocs-external-storagecluster annotated
先决条件
- 确保 OpenShift Data Foundation 集群处于健康状态。当因为资源或节点不足而导致部分 pod 无法成功终止时，卸载过程可能会失败。如果集群处于不健康状态，请在卸载 OpenShift Data Foundation 前联系红帽客户支持。
- 使用 OpenShift Data Foundation 提供的存储类，确保应用程序不使用持久性卷声明 (PVC) 或对象存储桶声明 (OBC)。
流程
删除使用 OpenShift Data Foundation 的卷快照。
列出所有命名空间中的卷快照
$ oc get volumesnapshot --all-namespaces
从上一命令的输出中，识别和删除使用 OpenShift Data Foundation 的卷快照。
$ oc delete volumesnapshot <VOLUME-SNAPSHOT-NAME> -n <NAMESPACE>
删除使用 OpenShift Data Foundation 的 PVC 和 OBC。
在默认的卸载模式 (graceful) 中，卸载程序会等待所有使用 OpenShift Data Foundation 的 PVC 和 OBC 被删除。
如果要事先删除 PVC 来删除存储集群，您可以将卸载模式注解设置为"强制"并跳过此步骤。这样做会导致系统中出现孤立 PVC 和 OBC。
使用 OpenShift Data Foundation 删除 OpenShift Container Platform 监控堆栈 PVC。
使用 OpenShift Data Foundation 删除 OpenShift Container Platform Registry PVC。
从 OpenShift Data Foundation 中删除 OpenShift Container Platform registry
使用 OpenShift Data Foundation 删除 OpenShift Container Platform 日志 PVC。
删除使用 OpenShift Data Foundation 置备的其他 PVC 和 OBC。
下面是一个示例脚本，用于标识使用 OpenShift Data Foundation 置备的 PVC 和 OBC。该脚本将忽略 OpenShift Data Foundation 内部使用的 PVC 和 OBC。
#!/bin/bash RBD_PROVISIONER="openshift-storage.rbd.csi.ceph.com" CEPHFS_PROVISIONER="openshift-storage.cephfs.csi.ceph.com" NOOBAA_PROVISIONER="openshift-storage.noobaa.io/obc" RGW_PROVISIONER="openshift-storage.ceph.rook.io/bucket" NOOBAA_DB_PVC="noobaa-db" NOOBAA_BACKINGSTORE_PVC="noobaa-default-backing-store-noobaa-pvc" # Find all the OCS StorageClasses OCS_STORAGECLASSES=$(oc get storageclasses | grep -e "$RBD_PROVISIONER" -e "$CEPHFS_PROVISIONER" -e "$NOOBAA_PROVISIONER" -e "$RGW_PROVISIONER" | awk '{print $1}') # List PVCs in each of the StorageClasses for SC in $OCS_STORAGECLASSES do echo "======================================================================" echo "$SC StorageClass PVCs and OBCs" echo "======================================================================" oc get pvc --all-namespaces --no-headers 2>/dev/null | grep $SC | grep -v -e "$NOOBAA_DB_PVC" -e "$NOOBAA_BACKINGSTORE_PVC" oc get obc --all-namespaces --no-headers 2>/dev/null | grep $SC echo done删除 OBC。
$ oc delete obc <obc name> -n <project name>
删除 PVC。
$ oc delete pvc <pvc name> -n <project-name>
确保您已删除了集群中创建的自定义后备存储、存储桶类等。
删除 Storage Cluster 对象并等待相关资源被删除。
$ oc delete -n openshift-storage storagesystem --all --wait=true
删除命名空间并等待删除完成。如果
openshift-storage是活跃的项目，则需要切换到另一个项目。例如：
$ oc project default $ oc delete project openshift-storage --wait=true --timeout=5m
如果以下命令返回
NotFound错误，则项目被删除。$ oc get project openshift-storage
注意卸载 OpenShift Data Foundation 时，如果没有完全删除命名空间并处于
Terminating状态，请执行 故障排除和删除 Uninstall 过程中剩余的资源 的步骤，以识别阻塞命名空间的对象。确认已删除使用 OpenShift Data Foundation 置备的所有 PV。如果有任何 PV 处于
Released状态，请将其删除。$ oc get pv $ oc delete pv <pv name>
删除
CustomResourceDefinitions。$ oc delete crd backingstores.noobaa.io bucketclasses.noobaa.io cephblockpools.ceph.rook.io cephclusters.ceph.rook.io cephfilesystems.ceph.rook.io cephnfses.ceph.rook.io cephobjectstores.ceph.rook.io cephobjectstoreusers.ceph.rook.io noobaas.noobaa.io ocsinitializations.ocs.openshift.io storageclusters.ocs.openshift.io cephclients.ceph.rook.io cephobjectrealms.ceph.rook.io cephobjectzonegroups.ceph.rook.io cephobjectzones.ceph.rook.io cephrbdmirrors.ceph.rook.io storagesystems.odf.openshift.io --wait=true --timeout=5m
确保完全卸载 OpenShift Data Foundation：
- 在 OpenShift Container Platform Web 控制台中点 Storage。
- 验证 OpenShift Data Foundation 是否不再出现在 Storage 下。
3.4.2. 从 OpenShift Data Foundation 中删除监控堆栈
使用本节清理 OpenShift Data Foundation 的监控堆栈。
在配置监控堆栈时创建的 PVC 位于 openshift-monitoring 命名空间中。
先决条件
PVC 被配置为使用 OpenShift Container Platform 监控堆栈。
如需更多信息，请参阅配置监控堆栈。
流程
列出当前在
openshift-monitoring命名空间中运行的 pod 和 PVC。$ oc get pod,pvc -n openshift-monitoring NAME READY STATUS RESTARTS AGE pod/alertmanager-main-0 3/3 Running 0 8d pod/alertmanager-main-1 3/3 Running 0 8d pod/alertmanager-main-2 3/3 Running 0 8d pod/cluster-monitoring- operator-84457656d-pkrxm 1/1 Running 0 8d pod/grafana-79ccf6689f-2ll28 2/2 Running 0 8d pod/kube-state-metrics- 7d86fb966-rvd9w 3/3 Running 0 8d pod/node-exporter-25894 2/2 Running 0 8d pod/node-exporter-4dsd7 2/2 Running 0 8d pod/node-exporter-6p4zc 2/2 Running 0 8d pod/node-exporter-jbjvg 2/2 Running 0 8d pod/node-exporter-jj4t5 2/2 Running 0 6d18h pod/node-exporter-k856s 2/2 Running 0 6d18h pod/node-exporter-rf8gn 2/2 Running 0 8d pod/node-exporter-rmb5m 2/2 Running 0 6d18h pod/node-exporter-zj7kx 2/2 Running 0 8d pod/openshift-state-metrics- 59dbd4f654-4clng 3/3 Running 0 8d pod/prometheus-adapter- 5df5865596-k8dzn 1/1 Running 0 7d23h pod/prometheus-adapter- 5df5865596-n2gj9 1/1 Running 0 7d23h pod/prometheus-k8s-0 6/6 Running 1 8d pod/prometheus-k8s-1 6/6 Running 1 8d pod/prometheus-operator- 55cfb858c9-c4zd9 1/1 Running 0 6d21h pod/telemeter-client- 78fc8fc97d-2rgfp 3/3 Running 0 8d NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE persistentvolumeclaim/my-alertmanager-claim-alertmanager-main-0 Bound pvc-0d519c4f-15a5-11ea-baa0-026d231574aa 40Gi RWO ocs-external-storagecluster-ceph-rbd 8d persistentvolumeclaim/my-alertmanager-claim-alertmanager-main-1 Bound pvc-0d5a9825-15a5-11ea-baa0-026d231574aa 40Gi RWO ocs-external-storagecluster-ceph-rbd 8d persistentvolumeclaim/my-alertmanager-claim-alertmanager-main-2 Bound pvc-0d6413dc-15a5-11ea-baa0-026d231574aa 40Gi RWO ocs-external-storagecluster-ceph-rbd 8d persistentvolumeclaim/my-prometheus-claim-prometheus-k8s-0 Bound pvc-0b7c19b0-15a5-11ea-baa0-026d231574aa 40Gi RWO ocs-external-storagecluster-ceph-rbd 8d persistentvolumeclaim/my-prometheus-claim-prometheus-k8s-1 Bound pvc-0b8aed3f-15a5-11ea-baa0-026d231574aa 40Gi RWO ocs-external-storagecluster-ceph-rbd 8d
编辑监控
configmap。$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
删除引用 OpenShift Data Foundation 存储类的所有
config部分，如下例所示并保存。Before editing
. . . apiVersion: v1 data: config.yaml: | alertmanagerMain: volumeClaimTemplate: metadata: name: my-alertmanager-claim spec: resources: requests: storage: 40Gi storageClassName: ocs-external-storagecluster-ceph-rbd prometheusK8s: volumeClaimTemplate: metadata: name: my-prometheus-claim spec: resources: requests: storage: 40Gi storageClassName: ocs-external-storagecluster-ceph-rbd kind: ConfigMap metadata: creationTimestamp: "2019-12-02T07:47:29Z" name: cluster-monitoring-config namespace: openshift-monitoring resourceVersion: "22110" selfLink: /api/v1/namespaces/openshift-monitoring/configmaps/cluster-monitoring-config uid: fd6d988b-14d7-11ea-84ff-066035b9efa8 . . .After editing
. . . apiVersion: v1 data: config.yaml: | kind: ConfigMap metadata: creationTimestamp: "2019-11-21T13:07:05Z" name: cluster-monitoring-config namespace: openshift-monitoring resourceVersion: "404352" selfLink: /api/v1/namespaces/openshift-monitoring/configmaps/cluster-monitoring-config uid: d12c796a-0c5f-11ea-9832-063cd735b81c . . .
在本例中，
alertmanagerMain和prometheusK8s监控组件使用 OpenShift Data Foundation PVC。列出使用 PVC 的 pod。
在本例中，消耗 PVC 的
alertmanagerMain和prometheusK8spod 处于Terminating状态。这些 pod 不再使用 OpenShift Data Foundation PVC后，您可以删除 PVC。$ oc get pod,pvc -n openshift-monitoring NAME READY STATUS RESTARTS AGE pod/alertmanager-main-0 3/3 Terminating 0 10h pod/alertmanager-main-1 3/3 Terminating 0 10h pod/alertmanager-main-2 3/3 Terminating 0 10h pod/cluster-monitoring-operator-84cd9df668-zhjfn 1/1 Running 0 18h pod/grafana-5db6fd97f8-pmtbf 2/2 Running 0 10h pod/kube-state-metrics-895899678-z2r9q 3/3 Running 0 10h pod/node-exporter-4njxv 2/2 Running 0 18h pod/node-exporter-b8ckz 2/2 Running 0 11h pod/node-exporter-c2vp5 2/2 Running 0 18h pod/node-exporter-cq65n 2/2 Running 0 18h pod/node-exporter-f5sm7 2/2 Running 0 11h pod/node-exporter-f852c 2/2 Running 0 18h pod/node-exporter-l9zn7 2/2 Running 0 11h pod/node-exporter-ngbs8 2/2 Running 0 18h pod/node-exporter-rv4v9 2/2 Running 0 18h pod/openshift-state-metrics-77d5f699d8-69q5x 3/3 Running 0 10h pod/prometheus-adapter-765465b56-4tbxx 1/1 Running 0 10h pod/prometheus-adapter-765465b56-s2qg2 1/1 Running 0 10h pod/prometheus-k8s-0 6/6 Terminating 1 9m47s pod/prometheus-k8s-1 6/6 Terminating 1 9m47s pod/prometheus-operator-cbfd89f9-ldnwc 1/1 Running 0 43m pod/telemeter-client-7b5ddb4489-2xfpz 3/3 Running 0 10h NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE persistentvolumeclaim/ocs-alertmanager-claim-alertmanager-main-0 Bound pvc-2eb79797-1fed-11ea-93e1-0a88476a6a64 40Gi RWO ocs-external-storagecluster-ceph-rbd 19h persistentvolumeclaim/ocs-alertmanager-claim-alertmanager-main-1 Bound pvc-2ebeee54-1fed-11ea-93e1-0a88476a6a64 40Gi RWO ocs-external-storagecluster-ceph-rbd 19h persistentvolumeclaim/ocs-alertmanager-claim-alertmanager-main-2 Bound pvc-2ec6a9cf-1fed-11ea-93e1-0a88476a6a64 40Gi RWO ocs-external-storagecluster-ceph-rbd 19h persistentvolumeclaim/ocs-prometheus-claim-prometheus-k8s-0 Bound pvc-3162a80c-1fed-11ea-93e1-0a88476a6a64 40Gi RWO ocs-external-storagecluster-ceph-rbd 19h persistentvolumeclaim/ocs-prometheus-claim-prometheus-k8s-1 Bound pvc-316e99e2-1fed-11ea-93e1-0a88476a6a64 40Gi RWO ocs-external-storagecluster-ceph-rbd 19h
删除相关的 PVC。请确定删除所有消耗存储类的 PVC。
$ oc delete -n openshift-monitoring pvc <pvc-name> --wait=true --timeout=5m
3.4.3. 从 OpenShift Data Foundation 中删除 OpenShift Container Platform registry
使用这个部分从 OpenShift Data Foundation 清理 OpenShift Container Platform registry。如果要配置其他存储，请参阅 镜像 registry
作为配置 OpenShift Container Platform registry 的一部分创建的 PVC 位于 openshift-image-registry 命名空间中。
先决条件
- 镜像 registry 应配置为使用 OpenShift Data Foundation PVC。
流程
编辑
configs.imageregistry.operator.openshift.io对象，并删除 storage 部分中的内容。$ oc edit configs.imageregistry.operator.openshift.io
编辑前
. . . storage: pvc: claim: registry-cephfs-rwx-pvc . . .编辑后
. . . storage: emptyDir: {} . . .在本例中，PVC 称为
registry-cephfs-rwx-pvc，现在可以安全地删除。删除 PVC。
$ oc delete pvc <pvc-name> -n openshift-image-registry --wait=true --timeout=5m
3.4.4. 从 OpenShift Data Foundation 中删除集群日志记录操作器
使用本节从 OpenShift Data Foundation 清理集群日志记录 Operator。
在配置集群日志记录 Operator 时创建的 PVC 位于 openshift-logging 命名空间中。
先决条件
- 集群日志记录实例应该已配置为使用 OpenShift Data Foundation PVC。
流程
删除命名空间中的
ClusterLogging实例。$ oc delete clusterlogging instance -n openshift-logging --wait=true --timeout=5m
openshift-logging命名空间中的 PVC 现在可以安全地删除。删除 PVC。
$ oc delete pvc <pvc-name> -n openshift-logging --wait=true --timeout=5m<pvc-name>- 是 PVC 的名称
第 4 章 以内部模式部署独立多云对象网关
仅通过 OpenShift Data Foundation 部署多云对象网关组件可为部署提供灵活性，并有助于减少资源消耗。使用这个部分只以内部模式部署独立 Multicloud 对象网关组件，这涉及以下步骤：
- 安装 Red Hat OpenShift Data Foundation Operator
- 创建独立多云对象网关
在外部模式部署中不支持部署独立多云对象网关组件。
4.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 节点。每个节点都应该包含一个磁盘，需要 3 个磁盘(PV)。但是，一个 PV 最终会默认未使用。这是预期的行为。
- 有关其他资源要求，请参阅规划您的部署指南。
当您需要覆盖 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 部分。
流程
- 登录 OpenShift Web 控制台。
- 点 Operators → OperatorHub。
-
在 Filter by keyword 框中滚动或键入
OpenShift Data Foundation，以查找 OpenShift Data Foundation Operator。 - 点 Install。
在 Install Operator 页面中设置以下选项：
- 更新频道为 stable-4.12。
- 安装模式是 A specific namespace on the cluster。
-
Installed Namespace 为 Operator recommended namespace openshift-storage。如果命名空间
openshift-storage不存在，它会在 Operator 安装过程中创建。 将 Approval Strategy 选为 Automatic 或 Manual。
如果选择 Automatic 更新，Operator Lifecycle Manager(OLM)将自动升级 Operator 的运行实例，而无需任何干预。
如果选择 手动 更新，则 OLM 会创建一个更新请求。作为集群管理员，您必须手动批准该更新请求，才能将 Operator 更新至更新的版本。
- 确保为 Console 插件 选择了 Enable 选项。
- 点 Install。
验证步骤
-
成功安装 Operator 后，用户界面中会显示一个带有
Web console update is available信息的弹出窗口。点这个弹出窗口中的 Refresh web console 来反映控制台的更改。 在 Web 控制台中：
- 进入到 Installed Operators，再验证 OpenShift Data Foundation Operator 是否显示绿色勾号，指示安装成功。
- 进入到 Storage，再验证 Data Foundation 仪表板是否可用。
4.2. 创建独立多云对象网关
在部署 OpenShift Data Foundation 时，您只能创建独立多云对象网关组件。
先决条件
- 确保已安装 OpenShift Data Foundation Operator。
流程
在 OpenShift Web 控制台中，点 Operators → Installed Operators 查看所有已安装的 Operator。
确保所选 项目 为
openshift-storage。- 单击 OpenShift Data Foundation operator，然后单击 Create StorageSystem。
在 Backing storage 页面中，选择以下内容：
- 为 Deployment 类型选择 Multicloud Object Gateway。
- 选择 Use a existing StorageClass 选项。
- 点 Next。
可选：选择 Connect to an external key management service 复选框。这是集群范围加密的可选选项。
- 从 Key Management Service Provider 下拉列表中，选择 Vault 或 Thales CipherTrust Manager (using KMIP)。如果选择了 Vault，请进入下一步。如果您选择了 Thales CipherTrust Manager （using KMIP），请转到步骤 iii。
选择身份验证方法。
- 使用令牌验证方法
- 输入唯一的连接名称 , Vault 服务器的主机地址（'https://<hostname 或 ip>'），端口号和令牌。
展开 Advanced Settings，以根据您的
Vault配置输入其他设置和证书详情：- 在 后端路径中输入为 OpenShift Data Foundation 专用且唯一的 Key Value secret 路径。
- （可选）输入 TLS 服务器名称和 Vault Enterprise 命名空间。
- 上传对应的 PEM 编码证书文件，以提供 CA 证书、客户端证书和客户端私钥。
- 点 Save 并跳过步骤 iv。
- 使用 Kubernetes 验证方法
- 输入唯一的 Vault Connection Name, Vault 服务器的主机地址（'https://<hostname 或 ip>'）、端口号和角色名称。
展开 Advanced Settings，以根据您的
Vault配置输入其他设置和证书详情：- 在 后端路径中输入为 OpenShift Data Foundation 专用且唯一的 Key Value secret 路径。
- 可选：输入 TLS Server Name 和 Authentication Path （如果适用）。
- 上传对应的 PEM 编码证书文件，以提供 CA 证书、客户端证书和客户端私钥。
- 点 Save 并跳过步骤 iv。
要使用 Thales CipherTrust Manager (using KMIP) 作为 KMS 供应商，请按照以下步骤执行：
- 在项目中输入密钥管理服务的唯一连接名称。
在 Address 和 Port 部分中，输入 Thales CipherTrust Manager 的 IP 以及在其中启用了 KMIP 接口的端口。例如：
- 地址: 123.34.3.2
- 端口 ：5696
- 上传 客户端证书、CA 证书和 客户端私钥。
- 如果启用了 StorageClass 加密，请输入用于加密和解密的唯一标识符。
-
TLS Server 字段是可选的，并在没有 KMIP 端点的 DNS 条目时使用。例如，
kmip_all_<port>.ciphertrustmanager.local。
- 选择 网络。
- 点 Next。
在 Review and create 页面中，查看配置详情：
若要修改任何配置设置，请单击 Back。
- 单击 Create StorageSystem。
验证步骤
- 验证 OpenShift Data Foundation 集群是否健康
- 在 OpenShift Web 控制台中，点 Storage → Data Foundation。
在 Overview 选项卡的 Status 卡中，点 Storage System，然后点弹出框中的存储系统链接。
- 在 Object 选项卡的 Status 卡 中，验证 Object Service 和数据弹性 都具有绿色勾号。
- 在 Details 卡中，验证是否显示了 MCG 信息。
- 验证 pod 的状态
- 从 OpenShift Web 控制台点 Workloads → Pods。
从 Project 下拉列表中选择
openshift-storage，再验证以下 pod 处于Running状态。注意如果禁用 Show default projects 选项，请使用切换按钮列出所有默认项目。
组件 对应的 pod OpenShift Data Foundation Operator
-
ocs-operator114（任何存储节点上 1 个 pod） -
ocs-metrics-exporter（任何存储节点上 1 个 pod） -
odf-operator-controller-manager-*（任何存储节点上 1 个 pod） -
odf-console-*任何存储节点上 1 个 pod） -
csi-addons-controller-manager-*（任何存储节点上 1 个 pod）
Rook-ceph Operator
rook-ceph-operator-*（任何存储节点上的 1 个 pod）
多云对象网关
-
noobaa-operator-*（任何存储节点上 1 个 pod） -
noobaa-core-*(任何存储节点上 1 个 pod) -
noobaa-db-pg-*(任何存储节点上 1 个 pod) -
noobaa-endpoint-*(任何存储节点上 1 个 pod)
-
第 5 章 存储类和存储池
OpenShift Data Foundation Operator 根据使用的平台安装默认存储类。这个默认存储类由 Operator 所有和控制，且无法删除或修改。但是，如果您希望存储类具有不同的行为，可以创建自定义存储类。
您可以创建多个存储池，映射到提供以下功能的存储类：
- 使具有自身高可用性的应用能够使用具有两个副本的持久卷，从而可能提高应用性能。
- 使用启用了压缩的存储类为持久性卷声明节省空间。
外部模式 OpenShift Data Foundation 集群不支持多个存储类和多个池。
使用单个设备集的最小集群，只能创建两个新的存储类。每个存储集群扩展都允许两个新的附加存储类。
5.1. 创建存储类和池
您可以使用现有池创建存储类，也可以在创建存储类时为存储类创建新池。
先决条件
-
确保您已登录到 OpenShift Container Platform Web 控制台，并且 OpenShift Data Foundation 集群处于
Ready状态。
流程
- 点 Storage → StorageClasses。
- 点 Create Storage Class。
- 输入存储类 Name 和 Description。
Reclaim Policy 设置为
Delete作为默认选项。使用这个设置。如果您在存储类中将重新声明策略改为
Retain，则持久性卷(PV)会处于Released状态，即使在删除持久性卷声明(PVC)后也是如此。卷绑定模式设置为
WaitForConsumer作为默认选项。如果您选择
Immediate选项，则创建 PVC 时会立即创建 PV。- 选择 RBD Provisioner，这是用于置备持久性卷的插件。
从列表中选择现有存储池，或创建新池。
注意默认的池不支持使用双向复制数据保护策略。但是，如果您创建了额外的池，则可以使用双向复制。
- 创建新池
- 单击 Create New Pool。
- 输入 池名称。
- 选择 2-way-Replication 或 3-way-Replication作为数据保护策略。
如果需要压缩数据，选择启用压缩。
启用压缩可能会影响应用程序的性能，在已压缩或加密的数据时可能会证明无效。在启用压缩之前写入的数据不会压缩。
- 单击 Create 以创建新存储池。
- 创建池后，单击 Finish。
- 可选：选择启用加密复选框。
- 点 Create 创建存储类。
5.2. 为持久性卷加密创建存储类
先决条件
根据您的用例，您必须确保为以下之一配置对 KMS 的访问：
-
使用
vaulttokens：确保配置了访问权限，如使用 vaulttoken 配置对 KMS 的访问所述 -
使用
vaulttenantsa（技术预览）：确保配置访问权限，如使用vaulttenantsa配置对 KMS 的访问所述 - 使用 Thales CipherTrust Manager （使用 KMIP）：确保配置访问权限，如使用 Thales CipherTrust Manager 配置对 KMS 的访问所述
流程
- 在 OpenShift Web 控制台中，进入 Storage → StorageClasses。
- 点 Create Storage Class。
- 输入存储类 Name 和 Description。
- 为 Reclaim Policy 选择 Delete 或 Retain。默认情况下，选择 Delete。
- 选择 Immediate 或 WaitForFirstConsumer 作为卷绑定模式。WaitForConsumer 设置为默认选项。
-
选择 RBD Provisioner
openshift-storage.rbd.csi.ceph.com，这是用于调配持久卷的插件。 - 选择 存储池，其中卷数据将存储到列表中或创建新池。
选中 Enable encryption 复选框。有两个选项可用来设置 KMS 连接详情：
Select existing KMS connection: 从下拉列表中选择现有 KMS 连接。该列表填充自
csi-kms-connection-detailsConfigMap 中的连接详情。- 从下拉菜单中选择 Provider。
- 从列表中选择给定供应商的 Key service。
创建新的 KMS 连接 ：这仅适用于
vaulttoken和Thales CipherTrust Manager (using KMIP)。- 选择 Key Management Service Provider。
如果将
Vault选为 Key Management Service Provider，请按照以下步骤执行：- 输入唯一的连接名称 , Vault 服务器的主机地址（'https://<hostname 或 ip>'），端口号和令牌。
展开 Advanced Settings，以根据您的
Vault配置输入其他设置和证书详情：- 在 后端路径中输入为 OpenShift Data Foundation 专用且唯一的 Key Value secret 路径。
- （可选）输入 TLS 服务器名称和 Vault Enterprise 命名空间。
- 上传对应的 PEM 编码证书文件，以提供 CA 证书、客户端证书和客户端私钥。
- 点 Save。
如果选择了
Thales CipherTrust Manager （using KMIP）作为 Key Management Service Provider，请按照以下步骤执行：- 输入唯一 连接名称。
- 在 Address 和 Port 部分中，输入 Thales CipherTrust Manager 的 IP 以及在其中启用了 KMIP 接口的端口。例如，Address: 123.34.3.2, Port: 5696.
- 上传 客户端证书、CA 证书和 客户端私钥。
- 输入在上面生成的用于加密和解密的密钥的唯一标识符。
-
TLS Server 字段是可选的，并在没有 KMIP 端点的 DNS 条目时使用。例如，
kmip_all_<port>.ciphertrustmanager.local。
- 点 Save。
- 点 Create。
如果 HashiCorp Vault 设置不允许自动检测后端路径使用的 Key/Value(KV)secret 引擎 API 版本，编辑 ConfigMap 以添加
vaultBackend参数。注意vaultBackend是一个可选参数，添加到 configmap 中，以指定与后端路径关联的 KV secret 引擎 API 版本。确保值与为后端路径设置的 KV secret 引擎 API 版本匹配，否则可能会导致持久性卷声明(PVC)创建过程中失败。识别新创建的存储类使用的 encryptionKMSID。
- 在 OpenShift Web 控制台中，导航到 Storage → Storage Classes。
- 点 Storage class name → YAML 标签页。
捕获存储类使用的 encryptionKMSID。
Example:
encryptionKMSID: 1-vault
- 在 OpenShift Web 控制台中，导航到 Workloads → ConfigMaps。
- 要查看 KMS 连接详情，请单击点击 csi-kms-connection-details。
编辑 ConfigMap。
- 点击 Action 菜单 (⋮) → Edit ConfigMap。
根据之前标识的
encryptionKMSID配置的后端，添加vaultBackend参数。您可以为 KV secret engine API 版本 1 分配
kv，为 KV secret engine API 版本 2 分配kv-v2。Example:
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" }- 点 Save
第 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 通常用作集群中构建的镜像的发布目标，以及在集群中运行的工作负载的镜像源。
此过程不会将数据从现有镜像 registry 迁移到新镜像 registry。如果您在现有 registry 中已有容器镜像，请在完成此过程前备份 registry，并在这个过程完成后重新注册您的镜像。
先决条件
- 具有 OpenShift Web 控制台的管理访问权限。
-
OpenShift Data Foundation Operator 在
openshift-storage命名空间上安装并运行。在 OpenShift Web 控制台中，点 Operators → Installed Operators 查看已安装的 Operator。 -
Image Registry Operator 在
openshift-image-registry命名空间中安装并运行。在 OpenShift Web 控制台中，点 Administration → Cluster Settings → Cluster Operators 查看集群操作器。 -
带有 provisioner
openshift-storage.cephfs.csi.ceph.com的存储类可用。在 OpenShift Web 控制台中，点 Storage → StorageClasses 查看可用的存储类。
流程
为镜像 Registry 创建一个持久性卷声明。
- 在 OpenShift Web 控制台中，点击 Storage → Persistent Volume Claims。
-
将 Project 设置为
openshift-image-registry。 单击 Create Persistent Volume Claim。
-
在上方检索的可用存储类列表中，使用置备程序
openshift-storage.cephfs.csi.ceph.com指定存储类。 -
指定持久性卷声明 名称，如
ocs4registry。 -
指定
Shared Access (RWX)访问模式。 - 将 Size 指定为最少 100 GB。
点 Create。
等待新持久卷声明的状态变为
Bound。
-
在上方检索的可用存储类列表中，使用置备程序
将集群的 Image Registry 配置为使用新的持久卷声明。
- 点 Administration → Custom Resource Definitions。
-
点与
imageregistry.operator.openshift.io组关联的Config自定义资源定义。 - 点 实例 选项卡。
- 在集群实例外，点 Action Menu(⋮) → Edit Config。
添加新的持久性卷声明作为镜像 Registry 的持久性存储。
在
spec:下添加以下内容，并替换现有的storage:部分（如有必要）。storage: pvc: claim: <new-pvc-name>例如：
storage: pvc: claim: ocs4registry- 点 Save。
验证新配置是否正在使用。
- 点击 Workloads → Pods。
-
将 Project 设置为
openshift-image-registry。 -
验证新的
image-registry-*pod 的状态是否为Running，并且以前的image-registry-*pod 已终止。 -
点击新
image-registry-*Pod 查看 pod 详情。 -
向下滚动到 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 控制台中，点 Operators → Installed Operators 查看已安装的 Operator。 -
监控 Operator 在
openshift-monitoring命名空间内安装并运行。在 OpenShift Web 控制台中，点 Administration → Cluster Settings → Cluster Operators 查看集群操作器。 -
带有 provisioner
openshift-storage.rbd.csi.ceph.com的存储类可用。在 OpenShift Web 控制台中，点 Storage → StorageClasses 查看可用的存储类。
流程
- 在 OpenShift Web 控制台中，前往 Workloads → Config Maps。
-
将 Project 下拉菜单设置为
openshift-monitoring。 - 单击 Create Config Map。
使用以下命令定义一个新的
cluster-monitoring-configConfig Map。将尖括号 (
<,>) 中的内容替换为您自己的值，如retention: 24h或storage: 40Gi。将 storageClassName 替换为使用 provisioner
openshift-storage.rbd.csi.ceph.com的storageclass。在下例中，storageclass 的名称为ocs-storagecluster-ceph-rbd。cluster-monitoring-configConfig 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>- 单击 Create 以保存并创建 Config Map。
验证步骤
验证持久卷声明是否已绑定到 pod。
- 进入 Storage → Persistent Volume Claims。
-
将 Project 下拉菜单设置为
openshift-monitoring。 验证 5 持久性卷声明是否可见，状态为
Bound，附加到三个alertmanager-main-*pod，以及两个prometheus-k8s-*pod。图 6.1. 监控创建和绑定的存储
验证新
alertmanager-main-*pod 的状态是否显示为Running。- 进入 Workloads → Pods。
-
点击新
alertmanager-main-*pod 查看 pod 详情。 向下滚动到 Volumes，再验证卷是否具有 Type (
ocs-alertmanager-claim)，它与您的新持久性卷声明匹配，如ocs-alertmanager-claim-alertmanager-main-0。图 6.2. 附加到
alertmanager-main-*pod 的持久性卷声明
验证新的
prometheus-k8s-*pod 的状态是否为Running。-
点新的
prometheus-k8s-*Pod 查看 pod 详情。 向下滚动到 Volumes，再验证卷是否具有 Type (
ocs-prometheus-claim)，它与您的新持久性卷声明匹配，如ocs-prometheus-claim-prometheus-k8s-0。图 6.3. 附加到
prometheus-k8s-*pod 的持久性卷声明
-
点新的
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"
本例指定，集群中的每个数据节点将绑定到请求 200GiB 的 ocs-storagecluster-ceph-rbd 存储的持久性卷声明。每个主分片将由单个副本支持。分片的副本会在所有节点之间复制，并且始终可用；如果因为单一冗余策略至少存在两个节点，则可以恢复副本。有关 Elasticsearch 复制策略的详情，请参考为日志存储配置复制策略。
缺少存储块将导致默认存储支持部署。例如：
spec:
logStore:
type: "elasticsearch"
elasticsearch:
nodeCount: 3
storage: {}如需更多信息，请参阅为日志存储配置持久性存储以及为 emptyDir 存储配置日志存储。
6.3.2. 配置集群日志记录以使用 OpenShift Data Foundation
按照本节中的说明，将 OpenShift Data Foundation 配置为 OpenShift 集群日志记录的存储。
当您首次在 OpenShift 数据基础中配置日志记录时，您可以获取所有日志。但是，在卸载和重新安装日志记录后，会删除旧日志并只处理新日志。
先决条件
- 具有 OpenShift Web 控制台的管理访问权限。
-
OpenShift Data Foundation Operator 在
openshift-storage命名空间上安装并运行。 -
Cluster logging Operator 已安装并在
openshift-logging命名空间中运行。
流程
- 从 OpenShift Web 控制台左侧窗格中，点击 Administration → Custom Resource Definitions。
- 在 Custom Resource Definitions 页面中点 ClusterLogging。
- 在 Custom Resource Definition Overview 页面上，从 Actions 菜单中选择 View Instances，或者点击 Instances 选项卡。
在 Cluster Logging 页面上，点击 Create Cluster Logging。
您可能需要刷新页面来加载数据。
在 YAML 中，将 storageClassName 替换为使用 provisioner
openshift-storage.rbd.csi.ceph.com的storageclass。在下例中，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- 点 Save。
验证步骤
验证持久卷声明是否已绑定到
elasticsearchPod。- 进入 Storage → Persistent Volume Claims。
-
将 Project 下拉菜单设置为
openshift-logging。 验证持久卷声明是否可见，状态为
Bound，附加到elasticsearch-* pod。图 6.4. 创建并绑定集群日志记录
验证是否在使用新集群日志记录。
- 点 Workload → Pods。
-
将项目设置为
openshift-logging。 -
验证新的
elasticsearch-* Pod 的状态是否为Running。 -
点新的
elasticsearch-* Pod 查看 pod 详情。 -
向下滚动到 Volumes，再验证 elasticsearch 卷是否具有与新持久性卷声明匹配的 Type，如
elasticsearch-elasticsearch-cdm-9r624biv-3。 - 点 Persistent Volume Claim 名称，然后在 PersistentVolumeClaim Overview 页面中验证存储类名称。
确保使用较短的 Curator 时间，以避免在附加到 Elasticsearch Pod 的 PV 上 PV 完整场景。
您可以配置 Curator，以根据保留设置删除 Elasticsearch 数据。建议您将以下默认索引数据保留 5 天设为默认值。
config.yaml: |
openshift-storage:
delete:
days: 5如需了解更多详细信息，请参阅配置日志保留时间。
要卸载由持久性卷声明支持的集群日志记录，请使用相应部署指南的卸载章节中从 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命名空间上安装并运行。
流程
在 OpenShift Web 控制台中执行以下任一操作：
点 Workloads → Deployments。
在 Deployments 页面中，您可以执行以下操作之一：
- 从 Action 菜单中选择任何现有部署并点击 Add Storage 选项。
创建新部署，然后添加存储。
- 单击 Create Deployment 以创建新部署。
-
根据您的要求编辑
YAML以创建部署。 - 点 Create。
- 从页面右上角的 Actions 下拉菜单中选择 Add Storage。
点 Workloads → Deployment Configs。
在 Deployment Configs 页面中，您可以执行以下操作之一：
- 从 Action 菜单中选择任何现有部署并点击 Add Storage 选项。
创建新部署，然后添加存储。
- 单击 Create Deployment Config 以创建新部署。
-
根据您的要求编辑
YAML以创建部署。 - 点 Create。
- 从页面右上角的 Actions 下拉菜单中选择 Add Storage。
在 Add Storage 页面中，您可以选择以下选项之一：
- 点击 Use existing claim 选项，然后从下拉菜单中选择适合的 PVC。
单击 Create new claim 选项。
-
从 Storage Class 下拉列表中，选择适当的
CephFS或RBD存储类。 - 为持久性卷声明提供名称。
选择 ReadWriteOnce (RWO) 或 ReadWriteMany (RWX) 访问模式。
注意ReadOnlyMany (ROX) 已被取消激活，因为它不受支持。
选择所需存储容量的大小。
注意您可以扩展块 PV，但无法在创建持久性卷声明后减少存储容量。
-
从 Storage Class 下拉列表中，选择适当的
- 指定容器内挂载路径卷的挂载路径和子路径（如果需要）。
- 点 Save。
验证步骤
根据您的配置，执行以下任一操作：
- 点 Workloads → Deployments。
- 点 Workloads → Deployment Configs。
- 根据需要设置项目。
- 单击您添加存储的部署，以显示部署详情。
- 向下滚动到 Volumes，再验证您的部署带有一个与您分配的持久性卷声明相匹配的类型。
- 点 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 资源调度到污点节点上。
在节点上添加存储污点可能需要对其他 daemonset pod（如 openshift-dns daemonset ）进行容限处理。有关如何管理容限的详情，请参考知识库文章 https://access.redhat.com/solutions/6592171。
用于运行 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-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 部署后污点节点的步骤。
流程
- 在 OpenShift Web 控制台中，点击 Compute → Nodes，然后选择必须污点的节点。
- 在 Details 页面中，点 Edit taint。
- 在 Key <node.ocs.openshift.io/storage>, Value <true> 和 Effect<Noschedule> 字段中输入值。
- 点 Save。
验证步骤
按照以下步骤验证节点是否已成功污点：
- 进入 Compute → Nodes。
- 选择节点以验证其状态，然后单击 YAML 选项卡。
在 specs 部分中检查以下参数值：
Taints: Key: node.ocs.openshift.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. 通过在 Red Hat OpenStack Platform 基础架构上为 OpenShift Data Foundation 节点添加容量来扩展存储
要在用户置备的基础架构上增加动态创建的存储集群中的存储容量，您可以为配置的 Red Hat OpenShift Data Foundation worker 节点添加存储容量和性能。
先决条件
- 具有 OpenShift Container Platform 控制台的管理权限。
- 您有一个正在运行的 OpenShift Data Foundation Storage Cluster。
- 该磁盘的大小应该与初始部署过程中使用的大小相同。
流程
- 登录 OpenShift Web 控制台。
- 点 Operators → Installed Operators。
- 点 OpenShift Data Foundation Operator。
单击 Storage Systems 选项卡。
- 点击存储系统名称最右侧的 Action Menu(⋮) 来扩展选项菜单。
- 从选项菜单中选择 Add Capacity。
- 选择 Storage Class。选择您要用来置备新存储设备的存储类。
如果您使用部署期间生成的默认存储类，存储类应设置为 standard。如果您已创建了其他存储类，请选择适当的选项。
+ Raw Capacity 字段显示在存储类创建过程中设置的大小。所消耗的存储总量是这个大小的三倍，因为 OpenShift Data Foundation 使用的副本数为 3。
点 Add。
-
要检查状态，请进入 Storage → Data Foundation，并验证 Status 卡中的
Storage System有一个绿色勾号。
-
要检查状态，请进入 Storage → Data Foundation，并验证 Status 卡中的
验证步骤
验证 Raw Capacity 卡。
- 在 OpenShift Web 控制台中，点 Storage → Data Foundation。
- 在 Overview 选项卡的 Status 卡中，点 Storage System，然后点弹出框中的存储系统链接。
在 Block and File 选项卡中，检查 Raw Capacity 卡。
请注意，容量会根据您的选择而增加。
注意原始容量不考虑复制并显示完整容量。
验证新 OSD 及其对应的新持久卷声明(PVC)已创建。
查看新创建的 OSD 的状态：
- 从 OpenShift Web 控制台点 Workloads → Pods。
从 Project 下拉列表中选择
openshift-storage。注意如果禁用 Show default projects 选项，请使用切换按钮列出所有默认项目。
查看 PVC 的状态：
- 从 OpenShift Web 控制台点 Storage → Persistent Volume Claims。
从 Project 下拉列表中选择
openshift-storage。注意如果禁用 Show default projects 选项，请使用切换按钮列出所有默认项目。
可选：如果在集群中启用了集群范围的加密，请验证新 OSD 设备是否已加密。
识别运行新 OSD pod 的节点。
$ oc get -n openshift-storage -o=custom-columns=NODE:.spec.nodeName pod/<OSD-pod-name><OSD-pod-name>是 OSD pod 的名称。
例如：
$ oc get -n openshift-storage -o=custom-columns=NODE:.spec.nodeName pod/rook-ceph-osd-0-544db49d7f-qrgqm
输出示例：
NODE compute-1
对于上一步中确定的每个节点，请执行以下操作：
创建调试 pod，并为所选主机打开 chroot 环境。
$ oc debug node/<node-name><node-name>是节点的名称。
$ chroot /host
检查
ocs-deviceset名称旁边的crypt关键字。$ lsblk
只有在红帽支持团队帮助下，才支持集群缩减。
9.3. 通过添加新节点来横向扩展存储容量
要扩展存储容量，您需要执行以下操作：
- 添加新节点，以在现有工作程序节点已以其最大支持 OSD 运行时增加存储容量，即初始配置期间所选容量的 3 个 OSD 递增。
- 验证新节点是否已成功添加
- 添加节点后扩展存储容量
9.3.1. 在安装程序置备的基础架构中添加节点
先决条件
- 具有 OpenShift Container Platform 控制台的管理权限。
- 您有一个正在运行的 OpenShift Data Foundation Storage Cluster。
流程
- 导航到 Compute → Machine Sets。
在您要添加节点的机器集中，选择 Edit Machine Count。
- 添加节点数量，然后点 Save。
- 点 Compute → Nodes 并确认新节点是否处于 Ready 状态。
将 OpenShift 数据基础标签应用到新节点。
- 对于新节点，点击 Action 菜单(⋮) → Edit Labels。
- 添加 cluster.ocs.openshift.io/openshift-storage，然后点 Save。
建议您添加 3 个节点，每个节点都位于不同的区中。您必须添加 3 个节点，并对所有节点执行此步骤。
验证步骤
执行以下命令终端，并验证输出中是否存在新节点：
$ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1
在 OpenShift Web 控制台中，点 Workloads → Pods，确认在新节点上至少有以下 pod 处于 Running 状态：
-
csi-cephfsplugin-* -
csi-rbdplugin-*
-
9.3.2. 扩展存储容量
将新节点添加到 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 访问密钥：
例如：
- 使用虚拟主机风格访问 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
oc describe nooba 命令的输出列出了可用的内部和外部 DNS 名称。使用内部 DNS 时，流量是空闲的。外部 DNS 使用 Load Balancing 来处理流量，因此会有一个每小时的成本。
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.
现在，您有相关的端点、访问密钥和 secret 访问密钥来连接到您的应用。
例如：
如果 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. 为混合或多云添加存储资源
10.3.1. 创建新的后备存储
在 OpenShift Data Foundation 中使用此流程创建新的后备存储。
先决条件
- OpenShift Data Foundation 的管理员访问权限。
流程
- 在 OpenShift Web 控制台中，点 Storage → Data Foundation。
- 单击 Backing Store 选项卡。
- 单击 Create Backing Store。
在 Create New Backing Store 页面中执行以下操作：
- 输入后端存储名称。
- 选择 Provider。
- 选择 Region。
- 输入 端点.这是可选的。
从下拉列表中选择一个 Secret，或者创建自己的 secret。另外，您也可以切换到 Credentials 视图来填写所需的 secret。
有关创建 OCP secret 的更多信息，请参阅 Openshift Container Platform 文档中的 创建 secret 部分。
每个后备存储都需要不同的机密。有关为特定后备存储创建 secret 的更多信息，请参阅 第 10.3.2 节 “使用 MCG 命令行界面为混合或多云添加存储资源” 并按照使用 YAML 添加存储资源的步骤进行操作。
注意此菜单与 Google Cloud 和本地 PVC 以外的所有供应商相关。
- 输入 Target bucket。目标 bucket 是托管在远程云服务的容器存储。它允许您创建一个连接，告诉 MCG 它可以将此存储桶用于系统。
- 单击 Create Backing Store。
验证步骤
- 在 OpenShift Web 控制台中，点 Storage → Data Foundation。
- 单击 Backing Store 选项卡，以查看所有后备存储。
10.3.2. 使用 MCG 命令行界面为混合或多云添加存储资源
多云对象网关 (MCG) 简化了跨云供应商和集群的数据生成过程。
您必须添加 MCG 可以使用的后备存储。
根据部署类型，您可以选择以下步骤之一来创建后备存储：
- 有关创建 AWS 支持的后备存储，请参阅 第 10.3.2.1 节 “创建 AWS 支持的后备存储”
- 有关创建 IBM COS 支持的后备存储，请参阅 第 10.3.2.2 节 “创建 IBM COS 支持的后备存储”
- 有关创建 Azure 支持的后备存储，请参阅 第 10.3.2.3 节 “创建 Azure 支持的后备存储”
- 有关创建由 GCP 支持的后备存储，请参阅 第 10.3.2.4 节 “创建由 GCP 支持的后备存储”
- 有关创建本地持久性卷支持的后备存储，请参阅 第 10.3.2.5 节 “创建由本地持久性卷支持的后备存储”
对于 VMware 部署，请跳至 第 10.3.3 节 “创建兼容 s3 的多云对象网关后备存储” 以获得进一步说明。
10.3.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
或者，您也可以从 下载红帽 OpenShift Data Foundation 页面上的 OpenShift Data Foundation RPM 安装 MCG 软件包。
注意根据您的架构选择正确的产品变体。
流程
使用 MCG 命令行界面
在 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
<backingstore_name>- 后备储存的名称。
<AWS ACCESS KEY>和<AWS SECRET ACCESS KEY>- 您创建的 AWS 访问密钥 ID 和 secret 访问密钥。
<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 添加存储资源
使用凭证创建 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>
<AWS ACCESS KEY>和<AWS SECRET ACCESS KEY>-
使用 Base64 提供并编码您自己的 AWS 访问密钥 ID 和 secret 访问密钥，并使用结果代替
<AWS ACCESS KEY ID ENCODED IN BASE64>和<AWS SECRET ACCESS KEY ENCODED IN BASE64>。 <backingstore-secret-name>- 上一步中创建的后备存储 secret 的名称。
为特定的后备存储应用以下 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<bucket-name>- 现有 AWS 存储桶名称。
<backingstore-secret-name>- 上一步中创建的后备存储 secret 的名称。
10.3.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
或者，您也可以从 下载红帽 OpenShift Data Foundation 页面上的 OpenShift Data Foundation RPM 安装 MCG 软件包。
注意根据您的架构选择正确的产品变体。
流程
使用命令行界面
在 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
<backingstore_name>- 后备储存的名称。
<IBM ACCESS KEY>,<IBM SECRET ACCESS KEY>, 和<IBM COS ENDPOINT>IBM 访问密钥 ID、secret 访问密钥和适当的区域端点，对应于现有 IBM 存储桶的位置。
要在 IBM 云中生成上述密钥，您必须在为您的目标存储桶创建服务凭证时包含 HMAC 凭证。
<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 添加存储资源
使用凭证创建 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>
<IBM COS ACCESS KEY ID ENCODED IN BASE64>和<IBM COS SECRET ACCESS KEY ENCODED IN BASE64>- 使用 Base64 提供并编码您自己的 IBM COS 访问密钥 ID 和 secret 访问密钥，并使用这些属性的结果来代替这些属性。
<backingstore-secret-name>- 后备存储 secret 的名称。
为特定的后备存储应用以下 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<bucket-name>- 现有的 IBM COS 存储桶名称。此参数告知 MCG 将哪一个存储桶用作其后备存储的目标存储桶，以及随后数据存储和管理。
<endpoint>- 与现有 IBM 存储桶名称的位置对应的区域端点。此参数指示 MCG 关于用于其后备存储的端点，然后是数据存储和管理。
<backingstore-secret-name>- 上一步中创建的 secret 的名称。
10.3.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
或者，您也可以从 下载红帽 OpenShift Data Foundation 页面上的 OpenShift Data Foundation RPM 安装 MCG 软件包。
注意根据您的架构选择正确的产品变体。
流程
使用 MCG 命令行界面
在 MCG 命令行界面中运行以下命令：
noobaa backingstore create azure-blob <backingstore_name> --account-key=<AZURE ACCOUNT KEY> --account-name=<AZURE ACCOUNT NAME> --target-blob-container <blob container name> -n openshift-storage
<backingstore_name>- 后备储存的名称。
<AZURE ACCOUNT KEY>和<AZURE ACCOUNT NAME>- 您为此创建的 AZURE 帐户密钥和帐户名称。
<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 添加存储资源
使用凭证创建 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>
<AZURE ACCOUNT NAME ENCODED IN BASE64>和<AZURE ACCOUNT KEY ENCODED IN BASE64>- 使用 Base64 提供并编码您自己的 Azure 帐户名称和帐户密钥，并分别使用这些属性代替这些属性。
<backingstore-secret-name>- 唯一的后备存储 secret 名称。
为特定的后备存储应用以下 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<blob-container-name>- 现有的 Azure blob 容器名称。此参数告知 MCG 将哪一个存储桶用作其后备存储的目标存储桶，以及随后数据存储和管理。
<backingstore-secret-name>- 使用上一步中创建的 secret 的名称。
10.3.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
或者，您也可以从 下载红帽 OpenShift Data Foundation 页面上的 OpenShift Data Foundation RPM 安装 MCG 软件包。
注意根据您的架构选择正确的产品变体。
流程
使用 MCG 命令行界面
在 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> -n openshift-storage
<backingstore_name>- 后备储存的名称。
<PATH TO GCP PRIVATE KEY JSON FILE>- 为此目的创建的 GCP 私钥的路径。
<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 添加存储资源
使用凭证创建 secret：
apiVersion: v1 kind: Secret metadata: name: <backingstore-secret-name> type: Opaque data: GoogleServiceAccountPrivateKeyJson: <GCP PRIVATE KEY ENCODED IN BASE64>
<GCP PRIVATE KEY ENCODED IN BASE64>- 使用 Base64 提供并编码您自己的 GCP 服务帐户私钥，并将结果用于此属性。
<backingstore-secret-name>- 后备存储 secret 的唯一名称。
为特定的后备存储应用以下 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<target bucket>- 现有的 Google 存储桶。此参数告知 MCG 将哪一个存储桶用作其后备存储的目标存储桶，以及随后数据存储和管理。
<backingstore-secret-name>- 上一步中创建的 secret 的名称。
10.3.2.5. 创建由本地持久性卷支持的后备存储
先决条件
下载多云对象网关(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 软件包。
注意根据您的架构选择正确的产品变体。
流程
使用 MCG 命令行界面添加存储资源
在 MCG 命令行界面中运行以下命令：
注意此命令必须从
openshift-storage命名空间内运行。$ noobaa -n openshift-storage backingstore create pv-pool <backingstore_name> --num-volumes <NUMBER OF VOLUMES> --pv-size-gb <VOLUME SIZE> --request-cpu <CPU REQUEST> --request-memory <MEMORY REQUEST> --limit-cpu <CPU LIMIT> --limit-memory <MEMORY LIMIT> --storage-class <LOCAL STORAGE CLASS>
使用 YAML 添加存储资源
为特定的后备存储应用以下 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> cpu: <CPU REQUEST> memory: <MEMORY REQUEST> limits: cpu: <CPU LIMIT> memory: <MEMORY LIMIT> storageClass: <LOCAL STORAGE CLASS> type: pv-pool<backingstore_name>- 后备储存的名称。
<NUMBER OF VOLUMES>- 要创建的卷数量。请注意，增加卷数量可向上扩展存储。
<VOLUME SIZE>- 每个卷所需的大小（以 GB 为单位）。
<CPU REQUEST>-
保证的 CPU 请求，以 CPU 单元
m为单位。 <MEMORY REQUEST>- 保证请求的内存量。
<CPU LIMIT>-
可消耗的最大 CPU 量，以 CPU 单元
m为单位。 <MEMORY LIMIT>- 可消耗的最大内存量。
<LOCAL STORAGE CLASS>本地存储类名称，建议使用
ocs-storagecluster-ceph-rbd。输出结果类似如下：
INFO[0001] ✅ Exists: NooBaa "noobaa" INFO[0002] ✅ Exists: BackingStore "local-mcg-storage"
10.3.3. 创建兼容 s3 的多云对象网关后备存储
多云对象网关(MCG)可以使用任何 S3 兼容对象存储作为后备存储，例如，Red Hat Ceph Storage 的 RADOS 对象网关(RGW)。以下步骤演示了如何为 Red Hat Ceph Storage 的 RGW 创建 S3 兼容 MCG 后备存储。请注意，部署 RGW 时，OpenShift Data Foundation operator 会自动为 MCG 创建 S3 兼容后备存储。
流程
在 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> -n openshift-storage
要获取
<RGW ACCESS KEY>和<RGW SECRET KEY>，请使用您的 RGW 用户 secret 名称运行以下命令：oc get secret <RGW USER SECRET NAME> -o yaml -n openshift-storage
- 解码 Base64 中的访问密钥 ID 和访问密钥，并保留它们。
-
将
<RGW USER ACCESS KEY>和<RGW USER SECRET ACCESS KEY>替换为上一步中的相应已解码数据。 -
将
<bucket-name>替换为现有的 RGW 存储桶名称。此参数告知 MCG 将哪一个存储桶用作其后备存储的目标存储桶，以及随后数据存储和管理。 要获取
<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 创建后备存储：
创建
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>"
-
将
<RGW-Username>和<Display-name>替换为唯一的用户名和显示名称。
-
将
为 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-
将
<backingstore-secret-name>替换为上一步中使用CephObjectStore创建的 secret 的名称。 -
将
<bucket-name>替换为现有的 RGW 存储桶名称。此参数告知 MCG 将哪一个存储桶用作其后备存储的目标存储桶，以及随后数据存储和管理。 -
要获取
<RGW endpoint>，请参阅访问 RADOS 对象网关 S3 端点。
-
将
10.3.4. 使用用户界面为混合和多云添加存储资源
流程
- 在 OpenShift Web 控制台中，点 Storage → Data Foundation。
- 在 Storage Systems 选项卡中，选择 storage 系统，然后点 Overview → Object 选项卡。
- 选择 Multicloud Object Gateway 链接。
选择左侧的资源选项卡，突出显示下方。从填充的列表中，选择 Add Cloud Resource。
选择 Add new connection。
选择相关的原生云供应商或 S3 兼容选项并填写详情。
选择新创建的连接并将其映射到现有存储桶。
- 重复这些步骤，根据需要创建任意数量的后备存储。
在 NooBaa UI 中创建的资源不能由 OpenShift UI 或 MCG CLI 使用。
10.3.5. 创建新存储桶类
bucket 类是一个 CRD，代表一种存储桶类别，用于定义对象 Bucket 类 (OBC) 的分层策略和数据放置。
在 OpenShift Data Foundation 中创建存储桶类。
流程
- 在 OpenShift Web 控制台中，点 Storage → Data Foundation。
- 单击 Bucket Class 选项卡。
- 点 Create Bucket Class。
在 Create new Bucket Class 页面中，执行以下操作：
选择 bucket 类类型，再输入 bucket 类名称。
选择 BucketClass 类型。选择以下选项之一：
- Standard ：数据将由多云对象网关(MCG)使用，已取消、压缩和加密。
Namespace ：数据存储在 Namespace 存储中，而无需执行重复数据删除、压缩或加密。
默认选择 Standard。
- 输入 Bucket Class Name。
- 点 Next。
在 放置策略 中，选择 Tier 1 - Policy Type 并单击 Next。您可以根据要求选择任一选项。
- Spread 允许在选定资源之间分散数据。
- Mirror 允许在选定资源中完全重复数据。
- 单击 Add Tier 以添加另一个策略层。
如果您为 Spread 选择了 Tier 1 - Policy Type，从可用列表中选择至少一个 Backing Store 资源并点 Next。或者，您也可以创建新的后备存储。
注意当在上一步中选择 Policy Type 作为 Mirror 时，至少需要选择 2 个后备存储。
- 检查并确认 Bucket 类设置。
- 点 Create Bucket Class。
验证步骤
- 在 OpenShift Web 控制台中，点 Storage → Data Foundation。
- 单击 Bucket Class 选项卡，再搜索新的 Bucket 类。
10.3.6. 编辑存储桶类
使用以下步骤，通过 YAML 文件编辑存储桶类组件，方法是点击 Openshift Web 控制台上的 edit 按钮。
先决条件
- 管理员对 OpenShift Web 控制台的访问权限。
流程
- 在 OpenShift Web 控制台中，点 Storage → Data Foundation。
- 单击 Bucket Class 选项卡。
- 点击您要编辑的 Bucket 类旁边的 Action Menu (⋮)。
- 点 Edit Bucket Class。
- 您将被重定向到 YAML 文件，在此文件中进行必要的更改并点 Save。
10.3.7. 为存储桶类编辑后备存储
使用以下步骤编辑现有的多云对象网关(MCG)存储桶类，以更改存储桶类中使用的底层后备存储。
先决条件
- 管理员对 OpenShift Web 控制台的访问权限。
- 存储桶类。
- 后备存储。
流程
- 在 OpenShift Web 控制台中，点 Storage → Data Foundation。
- 单击 Bucket Class 选项卡。
点击您要编辑的 Bucket 类旁边的 Action Menu (⋮)。
- 点 Edit Bucket Class Resources。
在 Edit Bucket Class Resources 页面中，通过添加后备存储到存储桶类或从存储桶类中删除后备存储来编辑存储桶类资源。您还可以编辑使用一或两个分层和不同的放置策略创建的 bucket 类资源。
- 要将后备存储添加到 bucket 类，请选择后备存储的名称。
要从存储桶类中删除后备存储，请清除后备存储的名称。
- 点 Save。
10.4. 管理命名空间存储桶
命名空间存储桶可让您将不同提供程序上的数据存储库连接在一起，以便您可以通过统一视图与所有数据交互。将与各个提供程序关联的对象存储桶添加到命名空间存储桶，并通过命名空间存储桶访问您的数据，以一次性查看所有对象存储桶。这可让您在读取多个其他存储提供商的同时写入您首选的存储供应商，从而显著降低迁移至新存储提供商的成本。
您可以使用 S3 API 与命名空间存储桶中的对象交互。如需更多信息，请参阅命名空间存储桶中对象的 S3 API 端点。
只有其写入目标可用且可正常运行时，才能使用命名空间存储桶。
10.4.1. 命名空间存储桶中对象的 Amazon S3 API 端点
您可以使用 Amazon Simple Storage Service(S3) API 与命名空间存储桶中的对象交互。
Red Hat OpenShift Data Foundation 4.6 之后支持以下命名空间存储桶操作：
有关这些操作及其使用方法的最新信息，请参阅 Amazon S3 API 参考文档。
10.4.2. 使用 Multicloud 对象网关 CLI 和 YAML 添加命名空间存储桶
如需有关命名空间存储桶的更多信息，请参阅管理命名空间存储桶。
根据部署的类型以及是否使用 YAML 或 Multicloud 对象网关 CLI，选择以下流程之一来添加命名空间存储桶：
10.4.2.1. 使用 YAML 添加 AWS S3 命名空间存储桶
先决条件
- 安装了带有 OpenShift Data Foundation operator 的 OpenShift Container Platform。
访问多云对象网关(MCG)。
如需更多信息，请参阅第 2 章，使用应用程序访问多云对象网关。
流程
使用凭证创建 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>
其中
<namespacestore-secret-name>是一个唯一的 NamespaceStore 名称。您必须使用
Base64提供并编码您自己的 AWS 访问密钥 ID 和 secret 访问密钥，并使用其结果替换<AWS ACCESS KEY ID ENCODED IN BASE64>和<AWS SECRET ACCESS KEY ENCODED IN BASE64>。使用 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<resource-name>- 您要提供给资源的名称。
<namespacestore-secret-name>- 上一步中创建的 secret。
<namespace-secret>- 包括 secret 的命名空间。
<target-bucket>- 为 NamespaceStore 创建的目标存储桶。
创建一个命名空间存储桶类，为命名空间存储桶定义命名空间策略。命名空间策略的类型需要是
single或multi。一个类型为
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>- 定义命名空间存储桶的读写目标的单个 NamespaceStore 的名称。
一个类型为
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>-
定义命名空间存储桶
写入目标的单个 NamespaceStore。 <read-resources>-
定义命名空间存储桶的
读取目标的 NamespaceStore 的名称列表。
使用以下 YAML 使用上一步中定义的存储桶类(OBC)资源，创建存储桶：
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><resource-name>- 您要提供给资源的名称。
<my-bucket>- 您要提供给存储桶的名称。
<my-bucket-class>- 上一步中创建的 bucket 类。
在 Operator 置备 OBC 后，会在 MCG 中创建存储桶，Operator 会创建一个具有相同名称的 Secret 和 ConfigMap，并在与 OBC 相同的命名空间中创建 Secret 和 ConfigMap。
10.4.2.2. 使用 YAML 添加 IBM COS 命名空间存储桶
先决条件
- 安装了带有 OpenShift Data Foundation operator 的 OpenShift Container Platform。
- 访问多云对象网关（MCG），请参阅第 2 章，使用应用程序访问多云对象网关
流程
使用凭证创建 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>
<namespacestore-secret-name>唯一的 NamespaceStore 名称。
您必须使用
Base64提供和编码您自己的 IBM COS 访问密钥 ID 和 secret 访问密钥，并使用其结果替代<IBM COS ACCESS KEY ID ENCODED IN BASE64>和<IBM COS SECRET ACCESS KEY ENCODED IN BASE64>。
使用 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<IBM COS ENDPOINT>- 适当的 IBM COS 端点。
<namespacestore-secret-name>- 上一步中创建的 secret。
<namespace-secret>- 包括 secret 的命名空间。
<target-bucket>- 为 NamespaceStore 创建的目标存储桶。
创建一个命名空间存储桶类，为命名空间存储桶定义命名空间策略。命名空间策略的类型需要是
single或multi。一个类型为
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>-
定义命名空间存储桶的
读和写目标的单个 NamespaceStore 的名称。
类型为
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>- 定义命名空间存储桶写入目标的单个 NamespaceStore。
<read-resources>-
NamespaceStores 名称列表，用于定义命名空间存储桶的
读取目标。
要使用上一步中定义的 bucket 类的 Object Bucket Class (OBC) 资源创建存储桶，请应用以下 YAML：
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><resource-name>- 您要提供给资源的名称。
<my-bucket>- 您要提供给存储桶的名称。
<my-bucket-class>上一步中创建的 bucket 类。
在 Operator 置备 OBC 后，会在 MCG 中创建存储桶，Operator 会创建一个具有相同名称的
Secret和ConfigMap，并在与 OBC 相同的命名空间中创建 Secret 和 ConfigMap。
10.4.2.3. 使用 Multicloud 对象网关 CLI 添加 AWS S3 命名空间存储桶
先决条件
- 安装了带有 OpenShift Data Foundation operator 的 OpenShift Container Platform。
- 访问多云对象网关（MCG），请参阅第 2 章，使用应用程序访问多云对象网关
- 下载 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 软件包。
根据您的架构选择正确的产品变体。
流程
在 MCG 命令行界面中，创建一个 NamespaceStore 资源。
NamespaceStore 代表底层存储，用作 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
<namespacestore>- NamespaceStore 的名称。
<AWS ACCESS KEY>和<AWS SECRET ACCESS KEY>- 您创建的 AWS 访问密钥 ID 和 secret 访问密钥。
<bucket-name>- 现有 AWS 存储桶名称。此参数告知 MCG 将哪一个存储桶用作其后备存储的目标存储桶，以及随后数据存储和管理。
创建一个命名空间存储桶类，为命名空间存储桶定义命名空间策略。命名空间策略可以是
single或multi。创建一个命名空间存储桶类，其命名空间策略类型为
single：$ noobaa bucketclass create namespace-bucketclass single <my-bucket-class> --resource <resource> -n openshift-storage
<resource-name>- 要为资源指定名称。
<my-bucket-class>- 唯一的存储桶类名称。
<resource>-
定义命名空间存储桶的
读和写目标的单个 NamespaceStore 的名称。
创建一个命名空间存储桶类，其命名空间策略类型为
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>s-
命名空间存储列表，用逗号隔开，用于定义命名空间存储桶的
读取目标。
使用上一步中定义的 bucket 类的对象 Bucket Class(OBC)资源创建存储桶。
$ noobaa obc create my-bucket-claim -n openshift-storage --app-namespace my-app --bucketclass <custom-bucket-class>
<bucket-name>- 您选择的存储桶名称。
<custom-bucket-class>- 上一步中创建的 bucket 类的名称。
在 Operator 置备 OBC 后，会在 MCG 中创建存储桶，Operator 会创建一个具有相同名称的
Secret和ConfigMap，并在与 OBC 相同的命名空间中创建 Secret 和 ConfigMap。
10.4.2.4. 使用 Multicloud 对象网关 CLI 添加 IBM COS 命名空间存储桶
先决条件
- 安装了带有 OpenShift Data Foundation operator 的 OpenShift Container Platform。
- 访问多云对象网关（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 软件包。
注意根据您的架构选择正确的产品变体。
流程
在 MCG 命令行界面中，创建一个 NamespaceStore 资源。
NamespaceStore 代表底层存储，用作 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
<namespacestore>- NamespaceStore 的名称。
<IBM ACCESS KEY>,<IBM SECRET ACCESS KEY>,<IBM COS ENDPOINT>- IBM 访问密钥 ID、secret 访问密钥和适当的区域端点，对应于现有 IBM 存储桶的位置。
<bucket-name>- 现有 IBM 存储桶名称。此参数告知 MCG 将哪一个存储桶用作其后备存储的目标存储桶，以及随后数据存储和管理。
创建一个命名空间存储桶类，为命名空间存储桶定义命名空间策略。命名空间策略的类型需要是
single或multi。创建一个命名空间存储桶类，其命名空间策略类型为
single：$ noobaa bucketclass create namespace-bucketclass single <my-bucket-class> --resource <resource> -n openshift-storage
<resource-name>- 要为资源指定名称。
<my-bucket-class>- 唯一的存储桶类名称。
<resource>-
定义命名空间存储桶的
读和写目标的单个 NamespaceStore 的名称。
创建一个命名空间存储桶类，其命名空间策略类型为
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>-
以逗号分隔的 NamespaceStore 列表，用于定义命名空间存储桶的
读取目标。
使用以前步骤中定义的 bucket 类的对象 Bucket Class(OBC)资源创建存储桶。
$ noobaa obc create my-bucket-claim -n openshift-storage --app-namespace my-app --bucketclass <custom-bucket-class>
<bucket-name>- 您选择的存储桶名称。
<custom-bucket-class>- 上一步中创建的 bucket 类的名称。
在 Operator 置备 OBC 后，会在 MCG 中创建存储桶，Operator 会创建一个具有相同名称的 Secret 和 ConfigMap，并在与 OBC 相同的命名空间中创建 Secret 和 ConfigMap。
10.4.3. 使用 OpenShift Container Platform 用户界面添加命名空间存储桶
您可以使用 OpenShift Container Platform 用户界面添加命名空间存储桶如需有关命名空间存储桶的更多信息，请参阅管理命名空间存储桶。
先决条件
- 安装了带有 OpenShift Data Foundation operator 的 OpenShift Container Platform。
- 访问多云对象网关(MCG)。
流程
- 登录 OpenShift Web 控制台。
- 点 Storage → Data Foundation。
点 Namespace Store 选项卡创建要在命名空间存储桶中使用的
namespacestore资源。- 单击 Create namespace store。
- 输入命名空间存储名称。
- 选择一个供应商。
- 选择一个地区。
- 选择现有的 secret，或者点击 Swith to credentials 通过输入 secret key 和 secret access key 来创建 secret。
- 选择目标存储桶。
- 点 Create。
- 验证 namespacestore 是否处于 Ready 状态。
- 重复这些步骤，直到您拥有所需的资源量。
点击 Bucket Class 选项卡 → Create a new Bucket Class。
- 选择 Namespace 单选按钮。
- 输入 Bucket 类名称。
- （可选）添加描述。
- 点 Next。
- 为您的命名空间存储桶选择一个命名空间策略类型，然后单击 Next。
选择目标资源。
- 如果您的命名空间策略类型是 Single，则需要选择一个读取资源。
- 如果您的命名空间策略类型是 Multi，则需要选择读取资源和写入资源。
- 如果命名空间策略类型是 Cache，则需要选择一个定义命名空间存储桶读取和写入目标的 Hub 命名空间存储。
- 点 Next。
- 检查您的新 bucket 类，然后点击 Create Bucketclass。
- 在 BucketClass 页面中，验证新创建的资源是否处于 Created 阶段。
- 在 OpenShift Web 控制台中，点 Storage → Data Foundation。
- 在 Status 卡中，单击 Storage System，再单击弹出窗口中的 storage 系统链接。
- 在 Object 选项卡中，点 Multicloud Object Gateway → Buckets → Namespace Buckets 选项卡。
点 Create Namespace Bucket。
- 在 Choose Name 选项卡中，为命名空间存储桶指定一个名称，然后点 Next。
在 Set Placement 标签页中：
- 在 Read Policy 下，选择在上一步中创建的每个命名空间资源的复选框，命名空间存储桶应该从中读取数据。
- 如果您使用的命名空间策略类型是 Multi，在 Write Policy 下指定要将数据写入的命名空间资源。
- 点 Next。
- 点 Create。
验证步骤
- 验证命名空间存储桶是否在 State 列中带有绿色勾号、预期的读取资源和预期的写入资源名称。
10.5. 混合和多云存储桶的镜像数据
您可以使用 Multicloud Object Gateway(MCG)简化流程跨云供应商和集群跨数据。在创建反映数据管理策略和镜像的存储桶类前，您必须添加可以被 MCG 使用的后备存储。如需更多信息，请参阅第 4 章 第 10.3 节 “为混合或多云添加存储资源”。
您可以使用 OpenShift UI、YAML 或 MCG 命令行界面设置镜像数据。
请参见以下部分：
- 第 6.2 节，第 10.5.1 节 “使用 MCG 命令行创建存储桶类来镜像数据”
- 第 6.3 节，第 10.5.2 节 “使用 YAML 创建存储桶类来镜像数据”
10.5.1. 使用 MCG 命令行创建存储桶类来镜像数据
先决条件
- 确保下载 Multicloud 对象网关(MCG)命令行界面。
流程
在 Multicloud Object Gateway(MCG)命令行界面中，运行以下命令来创建带有镜像策略的存储桶类：
$ noobaa bucketclass create placement-bucketclass mirror-to-aws --backingstores=azure-resource,aws-resource --placement Mirror
将新创建的存储桶类设置为一个新的存储桶声明，生成一个新的存储桶，该存储桶将在两个位置之间进行镜像：
$ noobaa obc create mirrored-bucket --bucketclass=mirror-to-aws
10.5.2. 使用 YAML 创建存储桶类来镜像数据
应用以下 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将以下行添加到标准 Object Bucket Claim (OBC) 中：
additionalConfig: bucketclass: mirror-to-aws
有关 OBCs 的更多信息，请参阅 第 10.7 节 “对象 Bucket 声明”。
10.6. Multicloud 对象网关中的存储桶策略
OpenShift Data Foundation 支持 AWS S3 存储桶策略。bucket 策略允许您为用户授予存储桶及其对象的访问权限。
10.6.1. bucket 策略简介
bucket 策略是一个访问策略选项，可供您向 AWS S3 存储桶和对象授予权限。bucket 策略使用基于 JSON 的访问策略语言。有关访问策略语言的更多信息，请参阅AWS 访问策略语言概述。
10.6.2. 在 Multicloud 对象网关中使用存储桶策略
先决条件
- 正在运行的 OpenShift Data Foundation 平台。
- 访问 Multicloud 对象网关(MCG)，请参阅 第 10.2 节 “使用应用程序访问多云对象网关”
流程
在 MCG 中使用存储桶策略：
以 JSON 格式创建 bucket 策略。
例如：
{ "Version": "NewVersion", "Statement": [ { "Sid": "Example", "Effect": "Allow", "Principal": [ "john.doe@example.com" ], "Action": [ "s3:GetObject" ], "Resource": [ "arn:aws:s3:::john_bucket" ] } ] }使用 AWS S3 客户端，使用
put-bucket-policy命令将存储桶策略应用到 S3 存储桶：# aws --endpoint ENDPOINT --no-verify-ssl s3api put-bucket-policy --bucket MyBucket --policy BucketPolicy
-
将
ENDPOINT替换为 S3 端点。 -
将
MyBucket替换为 bucket，以设置策略。 -
将
BucketPolicy替换为 bucket 策略 JSON 文件。 如果您使用默认的自签名证书，请添加
--no-verify-ssl。例如：
# aws --endpoint https://s3-openshift-storage.apps.gogo44.noobaa.org --no-verify-ssl s3api put-bucket-policy -bucket MyBucket --policy file://BucketPolicy
如需有关
put-bucket-policy命令的更多信息，请参阅有关 put-bucket-policy 的 AWS CLI 命令参考。注意principal 元素指定允许或拒绝访问某一资源的用户，如存储桶。目前，只有 NooBaa 帐户才能用作主体。对于对象存储桶声明，NooBaa 会自动创建一个帐户
obc-account.<generated bucket name>@noobaa.io。注意不支持 bucket 策略条件。
-
将
其他资源
- bucket 策略有许多可用元素，与访问权限有关。
- 有关这些元素的详细信息，以及如何使用它们控制访问权限的示例，请参阅 AWS 访问策略语言概述。
- 如需存储桶策略的更多示例，请参阅 AWS Bucket 策略示例。
10.6.3. 在 Multicloud 对象网关中创建用户
先决条件
- 正在运行的 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 软件包。
注意根据您的架构选择正确的产品变体。
流程
执行以下命令创建一个 MCG 用户帐户：
noobaa account create <noobaa-account-name> [--allow_bucket_create=true] [--allowed_buckets=[]] [--default_resource=''] [--full_permission=false]
<noobaa-account-name>- 指定新 MCG 用户帐户的名称。
--allow_bucket_create- 允许用户创建新存储桶。
--allowed_buckets- 设置用户的允许存储桶列表（使用逗号或多个标记）。
--default_resource- 设置默认资源。新存储桶在此默认资源（包括将来的资源）上创建新的 bucket。
--full_permission- 允许此帐户访问所有现有和将来的存储桶。
您需要提供访问最少一个存储桶的访问权限，或完整权限来来访问所有存储桶。
10.7. 对象 Bucket 声明
Object Bucket Claim 可以用来为您的工作负载请求 S3 兼容存储桶后端。
您可以通过三种方式创建对象 Bucket 声明：
对象 bucket 声明在 NooBaa 中创建一个新 bucket 和应用帐户，其具有存储桶的权限，包括新的 access key 和 secret access key。应用程序帐户仅允许访问单个存储桶，默认情况下无法创建新的存储桶。
10.7.1. 动态对象 Bucket 声明
与持久卷类似，您可以将 Object Bucket 声明（OBC）的详细信息添加到应用的 YAML 中，并获取配置映射和机密中可用的对象服务端点、访问密钥和 secret 访问密钥。可在应用程序的环境变量中动态阅读此信息。
只有在 OpenShift 使用自签名证书时，多云对象网关端点才会使用自签名证书。在 OpenShift 中使用签名证书自动将 Multicloud Object Gateway 端点证书替换为签名证书。通过浏览器访问端点，获取多云对象网关当前使用的证书。如需更多信息，请参阅使用应用程序访问多云对象网关。
流程
在应用程序 YAML 中添加以下行：
apiVersion: objectbucket.io/v1alpha1 kind: ObjectBucketClaim metadata: name: <obc-name> spec: generateBucketName: <obc-bucket-name> storageClassName: openshift-storage.noobaa.io
这些线是 OBC 本身。
-
将
<obc-name>替换为唯一的 OBC 名称。 -
将
<obc-bucket-name>替换为 OBC 的唯一存储桶名称。
-
将
若要自动使用 OBC 将更多行添加到 YAML 文件。
例如：
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以下示例是存储桶声明结果之间的映射，这是一个带有凭证数据和 secret 的配置映射。此特定作业从 NooBaa 声明 Object Bucket，它将创建一个存储桶和帐户。
-
将
<obc-name>的所有实例替换为您的 OBC 名称。 -
将
<your application image>替换为您的应用程序镜像。
-
将
应用更新的 YAML 文件：
# oc apply -f <yaml.file>
将
<yaml.file>替换为 YAML 文件的名称。要查看新配置映射，请运行以下命令：
# oc get cm <obc-name> -o yaml
将
obc-name替换为您的 OBC 的名称。您可以在输出中预期以下环境变量：
-
BUCKET_HOST- 应用程序中使用的端点。 BUCKET_PORT- 可供应用使用的端口。-
端口与
BUCKET_HOST相关。例如，如果BUCKET_HOST是 https://my.example.com，BUCKET_PORT为 443，则对象服务的端点将是 https://my.example.com:443。
-
端口与
-
BUCKET_NAME- 请求或生成的存储桶名称。 -
AWS_ACCESS_KEY_ID- 作为凭据一部分的访问密钥。 -
AWS_SECRET_ACCESS_KEY- 属于凭据的 Secret 访问密钥。
-
获取 AWS_ACCESS_KEY_ID 和 AWS_SECRET_ACCESS_KEY。使用名称以便与 AWS S3 API 兼容。您需要在执行 S3 操作时指定密钥，特别是从多云对象网关(MCG)存储桶中读取、写入或列表时。密钥以 Base64 编码。解码密钥，然后才能使用它们。
# oc get secret <obc_name> -o yaml<obc_name>- 指定对象存储桶声明的名称。
10.7.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
流程
使用命令行界面生成新 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。
运行以下命令来查看 OBC:
# oc get obc -n openshift-storage
例如：
NAME STORAGE-CLASS PHASE AGE test21obc openshift-storage.noobaa.io Bound 38s
运行以下命令查看新 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在
openshift-storage命名空间内，您可以找到配置映射和 secret 来使用此 OBC。CM 和 secret 的名称与 OBC 相同。运行以下命令来查看 secret：
# oc get -n openshift-storage secret test21obc -o yaml
例如：
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 访问凭据。
运行以下命令来查看配置映射：
# 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.7.3. 使用 OpenShift Web 控制台创建对象 Bucket 声明
您可以使用 OpenShift Web 控制台创建对象 BucketClaim (OBC)。
先决条件
- 对 OpenShift Web 控制台的管理访问权限.
- 为了让您的应用程序与 OBC 通信，您需要使用 configmap 和 secret。有关此信息的详情请参考 第 10.7.1 节 “动态对象 Bucket 声明”。
流程
- 登录 OpenShift Web 控制台。
在左侧导航栏中，点击 Storage → Object Bucket Claims → Create Object Bucket Claim。
输入对象存储桶声明的名称，并根据您的部署（内部或外部）从下拉菜单中选择适当的存储类：
- 内部模式
以下存储类是在部署后创建的，可供使用：
-
OCS-storagecluster-ceph-rgw使用 Ceph 对象网关 (RGW) -
openshift-storage.noobaa.io使用 Multicloud 对象网关(MCG)
-
- 外部模式
以下存储类是在部署后创建的，可供使用：
-
ocs-external-storagecluster-ceph-rgw使用 RGW openshift-storage.noobaa.io使用 MCG注意RGW OBC 存储类仅可用于全新安装的 OpenShift Data Foundation 版本 4.5。它不适用于从以前的 OpenShift 数据基础版本升级的集群。
-
点 Create。
创建 OBC 后，您会被重定向到其详情页面。
10.7.4. 将对象 Bucket 声明附加到部署
创建后，对象 Bucket 声明 (OBC) 可以附加到特定的部署。
先决条件
- 对 OpenShift Web 控制台的管理访问权限.
流程
- 在左侧导航栏中，点击 Storage → Object Bucket Claims。
单击您创建的 OBC 旁边的操作菜单 (⋮)。
- 从下拉菜单中选择 Attach to Deployment。
- 从 Deployment Name 列表中选择所需的部署，然后单击 Attach。
10.7.5. 使用 OpenShift Web 控制台查看对象存储桶
您可以使用 OpenShift Web 控制台查看为对象 Bucket 声明 (OBC) 创建的对象存储桶详情。
先决条件
- 对 OpenShift Web 控制台的管理访问权限.
流程
- 登录 OpenShift Web 控制台。
在左侧导航栏中，点击 Storage → Object Buckets。
可选：您还可以进入到特定 OBC 的详细信息页面，再点 Resource 链接来查看该 OBC 的对象存储桶。
- 选择您要查看详情的对象存储桶。选择后，您将进入 Object Bucket Details 页面。
10.7.6. 删除对象 Bucket 声明
先决条件
- 对 OpenShift Web 控制台的管理访问权限.
流程
- 在左侧导航栏中，点击 Storage → Object Bucket Claims。
点击您要删除的 Object Bucket Claim(OBC ) 旁边的 Action 菜单 (⋮)。
- 选择 Delete Object Bucket Claim。
- 点 Delete。
10.8. 对象存储桶的缓存策略
缓存存储桶是带有 hub 目标和缓存目标的命名空间存储桶。hub 目标是一个 S3 兼容的大型对象存储桶。缓存存储桶是本地 Multicloud 对象网关存储桶。您可以创建一个缓存存储桶来缓存 AWS 存储桶或 IBM COS 存储桶。
缓存存储桶是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。
如需更多信息，请参阅技术预览功能支持范围。
10.8.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
或者，您也可以从 下载红帽 OpenShift Data Foundation 页面上的 OpenShift Data Foundation RPM 安装 MCG 软件包。
注意根据您的架构选择正确的产品变体。
流程
创建 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>
-
将
<namespacestore>替换为命名空间存储的名称。 -
将
<AWS ACCESS KEY>和<AWS SECRET ACCESS KEY>替换为您为此创建的 AWS 访问密钥 ID 和 secret 访问密钥。 将
<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-
将
<namespacestore>替换为唯一的名称。 -
将
<namespacestore-secret-name>替换为上一步中创建的 secret。 -
将
<namespace-secret>替换为用于在上一步中创建 secret 的命名空间。 -
将
<target-bucket>替换为您为命名空间存储创建的 AWS S3 存储桶。
-
将
运行以下命令来创建存储桶类：
noobaa bucketclass create namespace-bucketclass cache <my-cache-bucket-class> --backingstores <backing-store> --hub-resource <namespacestore>
-
将
<my-cache-bucket-class>替换为唯一的存储桶类名称。 -
将
<backing-store>替换为相关的后备存储。您可以在此字段中列出一个或多个以逗号分开的后备存储。 -
将
<namespacestore>替换为上一步中创建的命名空间存储。
-
将
运行以下命令，以使用 Object Bucket Claim (OBC) 资源创建 bucket，该资源使用第 2 步中定义的 bucket 类。
noobaa obc create <my-bucket-claim> my-app --bucketclass <custom-bucket-class>
-
将
<my-bucket-claim>替换为唯一名称。 -
将
<custom-bucket-class>替换为在第 2 步中创建的 bucket 类的名称。
-
将
10.8.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
或者，您也可以从 下载红帽 OpenShift Data Foundation 页面上的 OpenShift Data Foundation RPM 安装 MCG 软件包。
注意根据您的架构选择正确的产品变体。
流程
创建 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>
-
将
<namespacestore>替换为 NamespaceStore 的名称。 -
将
<IBM ACCESS KEY>、、<IBM SECRET ACCESS KEY>、<IBM COS ENDPOINT>替换为 IBM 访问密钥 ID、机密访问密钥和对应于现有 IBM 存储桶位置的适当区域端点。 将
<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-
将
<namespacestore>替换为唯一的名称。 -
将
<IBM COS ENDPOINT>替换为适当的 IBM COS 端点。 -
将
<backingstore-secret-name>替换为上一步中创建的 secret。 -
将
<namespace-secret>替换为用于在上一步中创建 secret 的命名空间。 -
将
<target-bucket>替换为您为命名空间存储创建的 AWS S3 存储桶。
-
将
运行以下命令来创建存储桶类：
noobaa bucketclass create namespace-bucketclass cache <my-bucket-class> --backingstores <backing-store> --hubResource <namespacestore>
-
将
<my-bucket-class>替换为唯一的存储桶类名称。 -
将
<backing-store>替换为相关的后备存储。您可以在此字段中列出一个或多个以逗号分开的后备存储。 -
将
<namespacestore>替换为上一步中创建的命名空间存储。
-
将
运行以下命令，以使用 Object Bucket Claim 资源创建 bucket，该资源使用第 2 步中定义的 bucket 类。
noobaa obc create <my-bucket-claim> my-app --bucketclass <custom-bucket-class>
-
将
<my-bucket-claim>替换为唯一名称。 -
将
<custom-bucket-class>替换为在第 2 步中创建的 bucket 类的名称。
-
将
10.9. 通过添加端点扩展多云对象网关性能
多云对象网关的性能可能因环境而异。在某些情况下，特定的应用需要更快的性能，这可以通过扩展 S3 端点来轻松解决。
Multicloud Object Gateway 资源池是一组 NooBaa 守护进程容器，默认启用两种类型的服务：
- 存储服务
- S3 端点服务
10.9.1. 使用存储节点扩展 Multicloud 对象网关
先决条件
- 在 OpenShift Container Platform 上运行 OpenShift 数据基础集群，可访问多云对象网关(MCG)。
MCG 中的存储节点是一个 NooBaa 守护进程容器，附加到一个或多个持久性卷(PV)，用于本地对象存储。NooBaa 守护进程可以在 Kubernetes 节点上部署。这可以通过创建一个由 StatefulSet pod 组成的 Kubernetes 池来完成。
流程
- 登录 OpenShift Web 控制台。
- 在 MCG 用户界面中，点击 Overview → Add Storage Resources。
- 在窗口中，单击 Deploy Kubernetes Pool。
- 在 Create Pool 步骤中，为将来安装的节点创建目标池。
- 在 Configure 步骤中，配置请求的 pod 数以及每个 PV 的大小。对于每个新 pod，将创建一个 PV。
- 在 Review 步骤中，您可以找到新池的详细信息，再选择要使用的部署方法：本地或外部部署。如果选择了本地部署，Kubernetes 节点将在集群内部署。如果选择了外部部署，您将获得 YAML 文件，供外部运行。
- 所有节点都会分配给您在第一步中选择的池，并可在 Resources → Storage resources → Resource name 下找到。
10.10. 自动扩展 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 控制台中，点 Operators → Installed Operators 查看已安装的 Operator。 - OpenShift Data Foundation 提供的默认存储类可用。在 OpenShift Web 控制台中，点 Storage → Storage Classes 查看默认存储类。
流程
为要使用的应用创建持久性卷声明 (PVC)。
- 在 OpenShift Web 控制台中，点击 Storage → Persistent Volume Claims。
- 为应用程序 pod 设置 Project。
单击 Create Persistent Volume Claim。
- 指定由 OpenShift Data Foundation 提供的存储类。
-
指定 PVC Name，如
myclaim。 选择所需的 Access Mode。
注意IBM FlashSystem 不支持 Access Mode,
Shared access (RWX)。-
对于 Rados 块设备(RBD)，如果 Access 模式 为 ReadWriteOnce(
RWO)，请选择所需的卷模式。默认卷模式是Filesystem。 - 根据应用程序要求指定一个 大小。
-
点 Create 并等待 PVC 处于
Bound状态。
配置新的或现有应用容器集以使用新 PVC。
对于新应用程序 pod，执行以下步骤：
- 点 Workloads →Pods。
- 创建新的应用 pod。
在
spec:部分下，添加volume:部分，将新 PVC 添加为应用 Pod 的卷。volumes: - name: <volume_name> persistentVolumeClaim: claimName: <pvc_name>例如：
volumes: - name: mypd persistentVolumeClaim: claimName: myclaim
对于现有应用程序 pod，执行以下步骤：
- 点 Workloads →Deployment Configs。
- 搜索与应用程序 pod 关联的所需部署配置。
- 点击其 Action 菜单(⋮) → Edit Deployment Config。
在
spec:部分下，添加volume:部分，将新 PVC 添加为应用程序 Pod 的卷，然后点 Save。volumes: - name: <volume_name> persistentVolumeClaim: claimName: <pvc_name>例如：
volumes: - name: mypd persistentVolumeClaim: claimName: myclaim
验证新配置是否正在使用。
- 点击 Workloads → Pods。
- 为应用程序 pod 设置 Project。
-
验证应用容器集的状态是否为
Running。 - 单击应用容器集名称，以查看容器集详细信息。
-
向下滚动到 Volumes 部分，再验证卷的 Type 与您的新持久卷声明匹配，如
myclaim。
11.2. 查看持久性卷声明请求状态
使用这个流程查看 PVC 请求的状态。
先决条件
- OpenShift Data Foundation 的管理员访问权限。
流程
- 登录 OpenShift Web 控制台。
- 点 Storage → Persistent Volume Claims
- 使用 Filter 文本框搜索所需的 PVC 名称。您还可以按 Name 或 Label 过滤 PVC 列表来缩小列表范围
- 检查与所需 PVC 对应的 Status 列。
- 点所需的 Name 查看 PVC 详情。
11.3. 查看持久性卷声明请求事件
使用这个流程来查看和解决持久性卷声明 (PVC) 请求事件。
先决条件
- 管理员对 OpenShift Web 控制台的访问权限。
流程
- 在 OpenShift Web 控制台中，点 Storage → Data Foundation。
- 在 Storage systems 选项卡中，选择存储系统，然后点 Overview → Block and File。
- 找到 Inventory 卡，查看 PVC 数量并显示错误。
- 点 Storage → Persistent Volume Claims
- 使用 Filter 文本框搜索所需的 PVC。
- 点 PVC 名称并导航到 Events
- 根据需要或按指示处理事件。
11.4. 动态置备
11.4.1. 关于动态置备
StorageClass 资源对象描述并分类了可请求的存储，并提供了根据需要为动态置备存储传递参数的方法。StorageClass 也可以作为控制不同级别的存储和访问存储的管理机制。集群管理员（cluster-admin）或者存储管理员（storage-admin）可以在无需了解底层存储卷资源的情况下，定义并创建用户可以请求的 StorageClass 对象。
OpenShift Container Platform 的持久性卷框架启用了这个功能，并允许管理员为集群提供持久性存储。该框架还可让用户在不了解底层存储架构的情况下请求这些资源。
很多存储类型都可用于 OpenShift Container Platform 中的持久性卷。存储插件可能支持静态置备、动态置备或两种置备类型。
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 |
| |
| AWS Elastic Block Store (EBS) |
|
当在不同的区中使用多个集群进行动态置备时，使用 |
| AWS Elastic File System (EFS) | 动态置备通过 EFS provisioner pod 实现，而不是通过置备程序插件实现。 | |
| Azure Disk |
| |
| Azure File |
|
|
| GCE 持久性磁盘 (gcePD) |
| 在多区（multi-zone）配置中，建议在每个 GCE 项目中运行一个 OpenShift Container Platform 集群，以避免在当前集群没有节点的区域中创建 PV。 |
|
| ||
| Red Hat Virtualization |
|
任何选择的置备程序插件还需要根据相关文档为相关的云、主机或者第三方供应商配置。
第 12 章 卷快照
卷快照是集群中特定时间点的存储卷的状态。这些快照有助于更有效地使用存储，不必每次都制作完整的副本，也可用作应用程序开发的构建块。
您可以创建同一持久性卷声明 (PVC) 的多个快照。对于 CephFS，您可以为每个 PVC 创建最多 100 个快照。对于 RADOS 块设备 (RBD)，您可以为每个 PVC 创建最多 512 个快照。
您无法计划定期创建快照。
12.1. 创建卷快照
您可以从持久性卷声明 (PVC) 页面或 Volume Snapshots 页面创建卷快照。
先决条件
-
对于一致的快照，PVC 应该处于
Bound状态，且不使用。确保先停止所有 IO，然后再执行快照。
只有 pod 使用时，OpenShift Data Foundation 才会为 PVC 的卷快照提供崩溃一致性。若要确保应用一致性，请务必先停止正在运行的容器集，以确保快照的一致性，或使用应用提供的任何静默机制来确保快照的一致性。
流程
- 在持久性卷声明页中显示
- 从 OpenShift Web 控制台点 Storage → Persistent Volume Claims。
要创建卷快照，请执行以下操作之一：
- 在所需 PVC 旁边，点 Action 菜单 (⋮) → Create Snapshot。
- 点击您要创建快照的 PVC，然后点击 Actions → Create Snapshot。
- 输入卷快照的名称。
- 从下拉列表中选择 Snapshot Class。
- 点 Create。您将被重定向到所创建的卷快照的 Details 页面。
- 从 Volume Snapshots 页面中
- 从 OpenShift Web 控制台点 Storage → Volume Snapshots。
- 在 Volume Snapshots 页面中，单击 Create Volume Snapshot。
- 从下拉列表中选择所需的 项目。
- 从下拉列表中选择持久性卷声明。
- 输入快照的名称。
- 从下拉列表中选择 Snapshot Class。
- 点 Create。您将被重定向到所创建的卷快照的 Details 页面。
验证步骤
- 进入 PVC 的 Details 页面，然后点击 Volume Snapshots 选项卡查看卷快照列表。验证是否列出了新卷快照。
- 从 OpenShift Web 控制台点 Storage → Volume Snapshots。验证是否列出了新卷快照。
-
等待卷快照处于
Ready状态。
12.2. 恢复卷快照
恢复卷快照时，会创建一个新的持久性卷声明 (PVC)。恢复的 PVC 独立于卷快照和父 PVC。
您可以从 PVC 页面或 Volume Snapshots 页面恢复卷快照。
流程
- 在持久性卷声明页中显示
只有在存在父 PVC 时，才可以从持久性卷声明页面恢复卷快照。
- 从 OpenShift Web 控制台点 Storage → Persistent Volume Claims。
- 点击 PVC 名称及卷快照将卷快照恢复为新 PVC。
- 在 Volume Snapshots 选项卡中，点您要恢复的卷快照旁的 Action 菜单(⋮)。
- 点 Restore 作为新 PVC。
- 输入新 PVC 的名称。
选择 Storage Class 名。
注意对于 Rados 块设备(RBD)，您必须选择一个与父 PVC 池相同的存储类。使用未启用加密的存储类恢复加密 PVC 的快照，反之亦然。
选择您选择的 Access Mode。
重要ReadOnlyMany(ROX)访问模式是一个开发者预览功能，它受到开发人员预览支持的限制。开发人员预览版本不应在生产环境中运行，且不受红帽客户门户网站问题单管理系统的支持。如果您需要 ReadOnlyMany 功能的帮助，请联络 ocs-devpreview@redhat.com 邮件列表和红帽开发团队成员将根据可用性和工作计划尽快为您提供协助。请参阅 使用新的只读访问模式创建克隆或恢复快照以使用 ROX 访问模式。
- 可选：对于 RBD，选择 卷模式。
- 单击 Restore。您将被重定向到新的 PVC 详情页面。
- 从 Volume Snapshots 页面中
- 从 OpenShift Web 控制台点 Storage → Volume Snapshots。
- 在 Volume Snapshots 选项卡中，点您要恢复的卷快照旁的 Action 菜单(⋮)。
- 点 Restore 作为新 PVC。
- 输入新 PVC 的名称。
选择 Storage Class 名。
注意对于 Rados 块设备(RBD)，您必须选择一个与父 PVC 池相同的存储类。使用未启用加密的存储类恢复加密 PVC 的快照，反之亦然。
选择您选择的 Access Mode。
重要ReadOnlyMany(ROX)访问模式是一个开发者预览功能，它受到开发人员预览支持的限制。开发人员预览版本不应在生产环境中运行，且不受红帽客户门户网站问题单管理系统的支持。如果您需要 ReadOnlyMany 功能的帮助，请联络 ocs-devpreview@redhat.com 邮件列表和红帽开发团队成员将根据可用性和工作计划尽快为您提供协助。请参阅 使用新的只读访问模式创建克隆或恢复快照以使用 ROX 访问模式。
- 可选：对于 RBD，选择 卷模式。
- 单击 Restore。您将被重定向到新的 PVC 详情页面。
验证步骤
- 从 OpenShift Web 控制台点 Storage → Persistent Volume Claims，并确认新 PVC 在 Persistent Volume Claims 页面中列出。
-
等待新 PVC 进入
Bound状态。
12.3. 删除卷快照
先决条件
- 要删除卷快照，应存在该特定卷快照中使用的卷快照类。
流程
- 从持久性卷声明页面
- 从 OpenShift Web 控制台点 Storage → Persistent Volume Claims。
- 点击具有需要删除卷快照的 PVC 名称。
- 在 Volume Snapshots 选项卡中，点击所需卷快照旁的 Action 菜单 (⋮) → Delete Volume Snapshot。
- 从卷快照页面
- 从 OpenShift Web 控制台点 Storage → Volume Snapshots。
- 在 Volume Snapshots 页面中，点击所需卷快照菜单 (⋮) → Delete Volume Snapshot 旁。
验证步骤
- 确保 PVC 详情页面的 Volume Snapshots 选项卡中没有删除的卷快照。
- 点 Storage → Volume Snapshots 并确保不会列出删除的卷快照。
第 13 章 卷克隆
克隆是现有存储卷的副本，用作任何标准卷。您可以创建一个卷克隆，以达到数据的时间副本。持久性卷声明 (PVC) 不能使用不同的大小克隆。您可以为每个 PVC 为 CephFS 和 RADOS 块设备 (RBD) 创建最多 512 个克隆。
13.1. 创建克隆
先决条件
-
源 PVC 必须处于
Bound状态，且不得处于使用状态。
如果 Pod 正在使用 PVC，则不要创建 PVC 克隆。这样做可能会导致数据崩溃，因为 PVC 没有被静默（暂停）。
流程
- 从 OpenShift Web 控制台点 Storage → Persistent Volume Claims。
要创建克隆，请执行以下操作之一：
- 在所需的 PVC 旁边，点 Action 菜单 (⋮) → Clone PVC。
- 点击您要克隆的 PVC，然后点击 Actions → Clone PVC。
- 输入克隆的名称。
选择您选择的访问模式。
重要ReadOnlyMany(ROX)访问模式是一个开发者预览功能，它受到开发人员预览支持的限制。开发人员预览版本不应在生产环境中运行，且不受红帽客户门户网站问题单管理系统的支持。如果您需要 ReadOnlyMany 功能的帮助，请联络 ocs-devpreview@redhat.com 邮件列表和红帽开发团队成员将根据可用性和工作计划尽快为您提供协助。请参阅 使用新的只读访问模式创建克隆或恢复快照以使用 ROX 访问模式。
- 单击 Clone。您将被重定向到新的 PVC 详情页面。
等待克隆的 PVC 状态变为
Bound。克隆的 PVC 现在可以被 pod 使用。这个克隆的 PVC 独立于其 dataSource PVC。
第 14 章 替换存储节点
您可以选择以下步骤之一来替换存储节点：
14.1. 在 Red Hat OpenStack Platform 安装程序置备的基础架构中替换操作节点
流程
- 登录 OpenShift Web 控制台，再点击 Compute → Nodes。
- 确定需要替换的节点。记录其 Machine Name。
将节点标记为不可调度：
$ oc adm cordon <node_name><node_name>- 指定替换的节点的名称。
排空节点：
$ oc adm drain <node_name> --force --delete-emptydir-data=true --ignore-daemonsets重要此活动可能至少需要 5 到 10 分钟或更多。Ceph 周期内生成的 Ceph 错误是临时的，当您标记新节点并且可以正常工作时，会自动解决。
- 点 Compute → Machines。搜索所需的机器。
- 除了所需机器外，点击 Action 菜单(⋮) → Delete Machine。
- 点 Delete 以确认机器已被删除。会自动创建新机器。
等待新计算机启动并过渡到 Running 状态。
重要此活动可能至少需要 5 到 10 分钟或更多。
- 点 Compute → Nodes。确认新节点处于 Ready 状态。
将 OpenShift Data Foundation 标签应用到新节点：
- 从用户界面
- 对于新节点，点击 Action Menu(⋮) → Edit Labels。
-
添加
cluster.ocs.openshift.io/openshift-storage，然后点 Save。
- 使用命令行界面
- 将 OpenShift Data Foundation 标签应用到新节点：
$ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""<new_node_name>- 指定新节点的名称。
验证步骤
验证输出中是否存在新节点：
$ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1
点击 Workloads → Pods。确认新节点上至少以下 pod 处于 Running 状态：
-
csi-cephfsplugin-* -
csi-rbdplugin-*
-
- 验证所有其他所需的 OpenShift Data Foundation pod 是否处于 Running 状态。
验证新的对象存储设备(OSD)pod 是否在替换节点上运行：
$ oc get pods -o wide -n openshift-storage| egrep -i <new_node_name> | egrep osd可选：如果在集群中启用了集群范围的加密，请验证新 OSD 设备是否已加密。
对于上一步中标识的每个新节点，请执行以下操作：
创建 debug pod 并为一个或多个所选主机打开 chroot 环境：
$ oc debug node/<node_name>$ chroot /host
显示可用块设备列表：
$ lsblk
检查一个或多个
ocs-deviceset名称旁的crypt关键字。
- 如果验证步骤失败，请联系红帽支持团队。
14.2. 在 Red Hat OpenStack Platform 安装程序置备的基础架构中替换失败的节点
流程
- 登录 OpenShift Web 控制台，再点击 Compute → Nodes。
- 确定有故障的节点，再单击其 Machine Name。
- 点击 Actions → Edit Annotations，然后点 Add More。
-
添加
machine.openshift.io/exclude-node-draining并点 Save。 - 点 Actions → Delete Machine，然后点 Delete。
新机器会自动创建，等待新机器启动。
重要此活动可能至少需要 5 到 10 分钟或更多。Ceph 周期内生成的 Ceph 错误是临时的，当您标记新节点并且可以正常工作时，会自动解决。
- 点 Compute → Nodes。确认新节点处于 Ready 状态。
使用以下任一方法之一将 OpenShift Data Foundation 标签应用到新节点：
- 从用户界面
- 对于新节点，点击 Action Menu(⋮) → Edit Labels。
-
添加
cluster.ocs.openshift.io/openshift-storage，然后点 Save。
- 使用命令行界面
- 将 OpenShift Data Foundation 标签应用到新节点：
$ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""<new_node_name>- 指定新节点的名称。
- 可选：如果失败的 Red Hat OpenStack Platform 实例没有自动删除，请从 Red Hat OpenStack Platform 控制台终止实例。
验证步骤
验证输出中是否存在新节点：
$ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1
点击 Workloads → Pods。确认新节点上至少以下 pod 处于 Running 状态：
-
csi-cephfsplugin-* -
csi-rbdplugin-*
-
- 验证所有其他所需的 OpenShift Data Foundation pod 是否处于 Running 状态。
验证新的对象存储设备(OSD)pod 是否在替换节点上运行：
$ oc get pods -o wide -n openshift-storage| egrep -i <new_node_name> | egrep osd可选：如果在集群中启用了集群范围的加密，请验证新 OSD 设备是否已加密。
对于上一步中标识的每个新节点，请执行以下操作：
创建 debug pod 并为一个或多个所选主机打开 chroot 环境：
$ oc debug node/<node_name>$ chroot /host
显示可用块设备列表：
$ lsblk
检查一个或多个
ocs-deviceset名称旁的crypt关键字。
- 如果验证步骤失败，请联系红帽支持团队。
第 15 章 替换存储设备
15.1. 在 Red Hat OpenStack Platform 安装程序置备的基础架构中替换操作或失败的存储设备
使用这个流程替换 OpenShift Data Foundation 中部署在 Red Hat OpenStack Platform 上的存储设备。这个过程有助于在新卷上创建新持久性卷声明 (PVC) 并删除旧的对象存储设备 (OSD)。
流程
确定需要替换的 OSD，以及在其上调度 OSD 的 OpenShift Container Platform 节点。
$ oc get -n openshift-storage pods -l app=rook-ceph-osd -o wide
输出示例：
rook-ceph-osd-0-6d77d6c7c6-m8xj6 0/1 CrashLoopBackOff 0 24h 10.129.0.16 compute-2 <none> <none> rook-ceph-osd-1-85d99fb95f-2svc7 1/1 Running 0 24h 10.128.2.24 compute-0 <none> <none> rook-ceph-osd-2-6c66cdb977-jp542 1/1 Running 0 24h 10.130.0.18 compute-1 <none> <none>
在本例中，
rook-ceph-osd-0-6d77d6c7c6-m8xj6需要替换，compute-2是调度 OSD 的 OpenShift Container Platform 节点。注意如果要更换的 OSD 处于健康状态，则 Pod 的状态将为
Running。缩减 OSD 部署，以替换 OSD。
$ osd_id_to_remove=0 $ oc scale -n openshift-storage deployment rook-ceph-osd-${osd_id_to_remove} --replicas=0其中，
osd_id_to_remove是 pod 名称中紧接在rook-ceph-osd前缀后面的整数。在本例中，部署名称为rook-ceph-osd-0。输出示例：
deployment.extensions/rook-ceph-osd-0 scaled
验证
rook-ceph-osdpod 是否已终止。$ oc get -n openshift-storage pods -l ceph-osd-id=${osd_id_to_remove}输出示例：
No resources found.
注意如果
rook-ceph-osdpod 处于terminating状态，请使用force选项删除 pod。$ oc delete pod rook-ceph-osd-0-6d77d6c7c6-m8xj6 --force --grace-period=0
输出示例：
warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely. pod "rook-ceph-osd-0-6d77d6c7c6-m8xj6" force deleted
在情形中，与故障 OSD 关联的持久性卷失败，获取失败的持久性卷详情，并使用以下命令删除它们：
$ oc get pv $ oc delete pv <failed-pv-name>
从集群中移除旧 OSD，以便能够添加新 OSD。
删除所有旧的
ocs-osd-removal任务。$ oc delete -n openshift-storage job ocs-osd-removal-${osd_id_to_remove}输出示例：
job.batch "ocs-osd-removal-0" deleted
更改到
openshift-storage项目。$ oc project openshift-storage
从集群中移除旧 OSD。
$ oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_IDS=${osd_id_to_remove} -p FORCE_OSD_REMOVAL=false |oc create -n openshift-storage -f -您可以通过在命令中添加逗号分隔的 OSD ID，以移除多个 OSD。（例如，FAILED_OSD_IDS=0,1,2）。
FORCE_OSD_REMOVAL 值必须在有三个 OSD 的集群中更改为"true"，或者有足够空间的集群在移除 OSD 后恢复所有这三个数据副本。
警告这一步会导致 OSD 完全从集群中移除。确保提供了
osd_id_to_remove的正确值。
通过检查
ocs-osd-removal-jobpod 的状态，验证 OSD 是否已成功移除。状态为
Completed，确认 OSD 移除作业已成功。# oc get pod -l job-name=ocs-osd-removal-job -n openshift-storage
确保 OSD 移除已完成。
$ oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1 | egrep -i 'completed removal'
输出示例：
2022-05-10 06:50:04.501511 I | cephosd: completed removal of OSD 0
重要如果
ocs-osd-removal-job失败并且 pod 不在预期的Completed状态，请检查 pod 日志来进一步调试。例如：
# oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1
如果在安装时启用了加密，在从相应 OpenShift Data Foundation 节点中删除的 OSD 设备中删除
dm-crypt关联的device-mapper映射。从
ocs-osd-removal-jobpod 日志中获取所替换 OSD 的 PVC 名称：$ oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1 |egrep -i ‘pvc|deviceset’
例如：
2021-05-12 14:31:34.666000 I | cephosd: removing the OSD PVC "ocs-deviceset-xxxx-xxx-xxx-xxx"
对于第 #1 步中指定的每个节点，请执行以下操作：
创建
debugpod 和chroot到存储节点上的主机。$ oc debug node/<node name> $ chroot /host
根据上一步中标识的 PVC 名称查找相关的设备名称
sh-4.4# dmsetup ls| grep <pvc name> ocs-deviceset-xxx-xxx-xxx-xxx-block-dmcrypt (253:0)
删除映射的设备。
$ cryptsetup luksClose --debug --verbose ocs-deviceset-xxx-xxx-xxx-xxx-block-dmcrypt
注意如果上述命令因为权限不足而卡住，请运行以下命令：
-
按
CTRL+Z退出上述命令。 查找阻塞的进程的 PID。
$ ps -ef | grep crypt
使用
kill命令终止进程。$ kill -9 <PID>
验证设备名称是否已移除。
$ dmsetup ls
-
按
删除
ocs-osd-removal任务。$ oc delete -n openshift-storage job ocs-osd-removal-${osd_id_to_remove}输出示例：
job.batch "ocs-osd-removal-0" deleted
验证步骤
验证是否有新的 OSD 正在运行。
$ oc get -n openshift-storage pods -l app=rook-ceph-osd
输出示例：
rook-ceph-osd-0-5f7f4747d4-snshw 1/1 Running 0 4m47s rook-ceph-osd-1-85d99fb95f-2svc7 1/1 Running 0 1d20h rook-ceph-osd-2-6c66cdb977-jp542 1/1 Running 0 1d20h
验证是否创建了处于
Bound状态的新 PVC。$ oc get -n openshift-storage pvc
输出示例：
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE db-noobaa-db-0 Bound pvc-b44ebb5e-3c67-4000-998e-304752deb5a7 50Gi RWO ocs-storagecluster-ceph-rbd 6d ocs-deviceset-0-data-0-gwb5l Bound pvc-bea680cd-7278-463d-a4f6-3eb5d3d0defe 512Gi RWO standard 94s ocs-deviceset-1-data-0-w9pjm Bound pvc-01aded83-6ef1-42d1-a32e-6ca0964b96d4 512Gi RWO standard 6d ocs-deviceset-2-data-0-7bxcq Bound pvc-5d07cd6c-23cb-468c-89c1-72d07040e308 512Gi RWO standard 6d
可选：如果在集群中启用了集群范围的加密，请验证新 OSD 设备是否已加密。
识别运行新 OSD pod 的节点。
$ oc get -n openshift-storage -o=custom-columns=NODE:.spec.nodeName pod/_<OSD-pod-name>_
<OSD-pod-name>是 OSD pod 的名称。
例如：
$ oc get -n openshift-storage -o=custom-columns=NODE:.spec.nodeName pod/rook-ceph-osd-0-544db49d7f-qrgqm
输出示例：
NODE compute-1
对于上一步中确定的每个节点，请执行以下操作：
创建调试 pod，并为所选主机打开 chroot 环境。
$ oc debug node/<node name> $ chroot /host
运行 "lsblk" 并检查
ocs-deviceset名旁边的 "crypt" 关键字。$ lsblk
登录 OpenShift Web 控制台并查看存储仪表板。
图 15.1. 在设备替换后，OpenShift Container Platform 存储仪表板中的 OSD 状态
第 16 章 升级到 OpenShift Data Foundation
16.1. OpenShift Data Foundation 更新过程概述
本章可帮助您在所有 Red Hat OpenShift Data Foundation 部署（Internal、Internal-Attached 和 External）在次版本和 z-stream 之间升级。所有部署的升级过程都保持不变。
您可以通过启用自动更新（如果没有在 operator 安装过程中进行）或执行手工更新，在次版本间（如 4.11 和 4.12 间）或在 z-stream 更新之间（如 4.12.0 和 4.12.1 间）升级 OpenShift Data Foundation 及其组件。当新的 z-stream 版本可用时，如果更新策略被设置为 Automatic，升级过程会自动触发。
您还需要为内部和外部模式部署按照以下顺序升级 Red Hat OpenShift Data Foundation 的不同部分：
- 根据 OpenShift Container Platform 更新集群文档更新 OpenShift Container Platform。
更新 Red Hat OpenShift Data Foundation.
- 要准备断开连接的环境以获取更新，请参阅 Operator 指南，在受限网络中使用 Operator Lifecycle Manager，以便在使用时能够更新 OpenShift Data Foundation 和 Local Storage Operator。
- 有关在次版本间更新的信息，请参阅将 Red Hat OpenShift Data Foundation 4.11 更新至 4.12。
- 有关 z-stream 版本之间的更新，请参阅将 Red Hat OpenShift Data Foundation 4.12.x 更新至 4.12.y。
- 若要更新外部模式部署，还必须执行 更新 Red Hat OpenShift Data Foundation 外部机密 一节中的步骤。
- 如果使用本地存储，请更新 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。
- 要了解集群是否在内部还是外部模式中部署，请参阅知识库文章了解如何确定 ODF 集群是否在内部或外部模式中存储。
- 只有在 Local Storage Operator 版本与 Red Hat OpenShift Container Platform 版本匹配时，才会完全支持 Local Storage Operator。
- 灵活的扩展功能仅适用于 OpenShift Data Foundation 的新部署。如需更多信息，请参阅扩展存储指南。
16.2. 将 Red Hat OpenShift Data Foundation 4.11 更新至 4.12
本章可帮助您在所有 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.11 之前的版本升级到 4.12。
先决条件
- 确保 OpenShift Container Platform 集群已更新至版本 4.12.X 的最新稳定版本，请参阅 更新集群。
确保 OpenShift Data Foundation 集群正常运行，数据具有弹性。
- 进入到 Storage → Data Foundation → Storage Systems 选项卡，然后点存储系统名称。
- 检查 Overview - Block and File 和 Object 选项卡的状态卡上绿色勾号。绿色勾号表示 存储集群、对象服务和数据弹性都是健康的。
确保所有 OpenShift Data Foundation Pod（包括操作器 Pod）在
openshift-storage命名空间中处于 Running 状态。要查看 pod 的状态，在 OpenShift Web 控制台中点 Workloads → Pods。从 Project 下拉列表中选择
openshift-storage。注意如果禁用 Show default projects 选项，请使用切换按钮列出所有默认项目。
- 确保您有足够的时间完成 OpenShift 数据基础更新过程，因为更新时间因集群中运行的 OSD 数量而异。
流程
- 在 OpenShift Web 控制台中，导航到 Operators → Installed Operators。
-
选择
openshift-storage项目。 - 点 OpenShift Data Foundation operator 名称。
- 点 Subscription 标签页，点 Update Channel 下的链接。
- 选择 Stable-4.12 更新频道并保存。
如果 Upgrade status 显示
requires approval，请单击 requires approval。- 在 Install Plan Details 页面中，单击 Preview Install Plan。
检查安装计划并点 Approve。
等待 Status 从
Unknown改为Created。
- 导航到 Operators → Installed Operators。
选择
openshift-storage项目。等待 OpenShift Data Foundation Operator Status 更改为 Up to date。
验证步骤
检查 OpenShift Data Foundation 名称下面的 Version，并检查 Operator 状态。
-
导航到 Operators → Installed Operators，再选择
openshift-storage项目。 - 升级完成后，新版本会更新到 OpenShift 数据基础的新版本号，并通过绿色勾号更改 Succeeded 状态。
-
导航到 Operators → Installed Operators，再选择
验证 OpenShift Data Foundation 集群是否正常运行并且数据具有弹性。
- 进入到 Storage → Data Foundation → Storage Systems 选项卡，然后点存储系统名称。
- 检查 Overview - Block 和 File 和 Object 选项卡的状态卡上绿色勾号。绿色勾号表示存储集群、对象服务和数据弹性是健康的。
- 如果验证步骤失败，请联系红帽支持。
在更新外部模式部署后，还必须更新外部 secret。具体步骤，请参阅 更新 OpenShift 数据基础外部 secret。
其它资源
如果您在更新 OpenShift Data Foundation 时遇到任何问题，请参阅故障排除指南中的常见的进行故障排除所需的日志部分。
16.3. 将 Red Hat OpenShift Data Foundation 4.12.x 更新至 4.12.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.12.X 的最新稳定版本，请参阅 更新集群。
确保 OpenShift Data Foundation 集群正常运行，数据具有弹性。
- 进入到 Storage → Data Foundation → Storage Systems 选项卡，然后点存储系统名称。
- 检查 Overview - Block 和 File 和 Object 选项卡的状态卡上绿色勾号。绿色勾号表示存储集群、对象服务和数据弹性是健康的。
确保所有 OpenShift Data Foundation Pod（包括操作器 Pod）在
openshift-storage命名空间中处于 Running 状态。要查看 pod 的状态，在 OpenShift Web 控制台中点 Workloads → Pods。从 Project 下拉列表中选择
openshift-storage。注意如果禁用 Show default projects 选项，请使用切换按钮列出所有默认项目。
- 确保您有足够的时间完成 OpenShift 数据基础更新过程，因为更新时间因集群中运行的 OSD 数量而异。
流程
- 在 OpenShift Web 控制台中，导航到 Operators → Installed Operators。
选择
openshift-storage项目。注意如果禁用 Show default projects 选项，请使用切换按钮列出所有默认项目。
- 单击 OpenShift Data Foundation 操作器名称。
- 点 Subscription 标签页。
-
如果 Upgrade Status 显示
需要批准，请单击 require approval 链接。 - 在 InstallPlan Details 页面中点 Preview Install Plan。
- 检查安装计划并点 Approve。
-
等待 Status 从
Unknown变为Created。
验证步骤
检查 OpenShift Data Foundation 名称下面的 Version，并检查 Operator 状态。
-
导航到 Operators → Installed Operators，再选择
openshift-storage项目。 - 升级完成后，新版本会更新到 OpenShift 数据基础的新版本号，并通过绿色勾号更改 Succeeded 状态。
-
导航到 Operators → Installed Operators，再选择
验证 OpenShift 数据基础集群是否正常运行并且数据具有弹性。
- 进入到 Storage → Data Foundation → Storage Systems 选项卡，然后点存储系统名称。
- 检查 Overview - Block 和 File 和 Object 选项卡的状态卡上绿色勾号。绿色勾号表示存储集群、对象服务和数据弹性是健康的
- 如果验证步骤失败，请联系红帽支持。
16.4. 更改更新批准策略
为确保在同一频道中有新更新时自动更新存储系统，我们建议把更新批准策略设置为 Automatic。将更新批准策略更改为 Manual 需要在每次升级时手动批准。
流程
- 导航到 Operators → Installed Operators。
从 Project 下拉列表中选择
openshift-storage。注意如果禁用 Show default projects 选项，请使用切换按钮列出所有默认项目。
- 单击 OpenShift Data Foundation operator 名称
- 转至 订阅 选项卡。
- 单击 铅笔 图标以更改 更新批准。
- 选择更新批准策略并点 Save。
验证步骤
- 验证 Update 批准显示了它下面新选择的批准策略。
