使用 Google Cloud 部署和管理 OpenShift Data Foundation
在现有 Red Hat OpenShift Container Platform Google Cloud 集群上部署和管理 OpenShift Data Foundation 的说明
摘要
使开源包含更多
红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始:master、slave、黑名单和白名单。由于此项工作十分艰巨,这些更改将在即将推出的几个发行版本中逐步实施。详情请查看 CTO Chris Wright 的信息。
对红帽文档提供反馈
我们感谢您对文档提供反馈信息。请告诉我们如何让它更好。提供反馈:
关于特定内容的简单评论:
- 请确定您使用 Multi-page HTML 格式查看文档。另外,确定 Feedback 按钮出现在文档页的右上方。
- 用鼠标指针高亮显示您想评论的文本部分。
- 点在高亮文本上弹出的 Add Feedback。
- 按照显示的步骤操作。
要提交更复杂的反馈,请创建一个 Bugzilla ticket:
- 进入 Bugzilla 网站。
- 在 Component 部分中,选择 文档。
- 在 Description 中输入您要提供的信息。包括文档相关部分的链接。
- 点 Submit Bug。
前言
Red Hat OpenShift Data Foundation 4.9 支持在现有 Red Hat OpenShift Container Platform(RHOCP)Google Cloud 集群上部署。
Google Cloud 上仅支持内部 OpenShift Data Foundation 集群。如需有关部署要求的更多信息,请参阅规划部署。
要以内部模式部署 OpenShift 数据基础,请从 准备部署 OpenShift 数据基础 章节的要求开始,并根据您的要求遵循适当的部署流程:
第 1 章 准备部署 OpenShift 数据基础
使用动态存储设备在 OpenShift Container Platform 上部署 OpenShift Data Foundation 为您提供创建内部集群资源的选项。这将会在内部置备基础服务,这有助于为应用提供额外的存储类。
在开始部署 Red Hat OpenShift Data Foundation 前,请按照以下步骤执行:
可选:如果要使用外部密钥管理系统(KMS)启用集群范围加密:
- 确保存在具有令牌的策略,并且启用了 Vault 中的键值后端路径。请参阅 Vault 中启用的键值后端路径和策略。
- 确保您在 Vault 服务器上使用签名的证书。
最低的启动节点要求 [技术预览]
当不符合标准部署资源要求时,将使用最低配置部署 OpenShift Data Foundation 集群。请参阅规划指南中的资源要求部分。
Regional-DR 要求 [开发人员预览]
Red Hat OpenShift Data Foundation 支持的灾难恢复功能需要满足以下所有先决条件,才能成功实施灾难恢复解决方案:
- 有效的 Red Hat OpenShift Data Foundation 高级授权
有效的 Red Hat Advanced Cluster Management for Kubernetes 订阅
要了解 OpenShift Data Foundation 订阅如何工作,请参阅与 OpenShift Data Foundation 订阅相关的知识库文章。
有关详细要求,请参阅 Regional-DR 要求 和 RHACM 要求。
1.1. 在 Vault 中启用键值后端路径和策略
先决条件
- 管理员对 Vault 的访问权限。
-
仔细选择唯一路径名称作为遵循命名惯例的后端
路径
,因为它无法在以后更改。
流程
在 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
使用以下命令,创建一个策略来限制用户对机密执行写入或删除操作。
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 章 在 Google Cloud 上部署 OpenShift Data Foundation
您可以使用 Google Cloud 安装程序置备的基础架构提供的动态存储设备在 OpenShift Container Platform 上部署 OpenShift Data Foundation。这可让您创建内部集群资源,并导致在内部置备基础服务,这有助于为应用程序提供额外的存储类。
另外,可以使用 OpenShift Data Foundation 仅部署多云对象网关(MCG)组件。如需更多信息,请参阅 部署独立多云对象网关。
Google Cloud 上仅支持内部 OpenShift Data Foundation 集群。如需有关部署要求的更多信息,请参阅规划部署。
确保已满足 准备部署 OpenShift Data Foundation 章节的要求,然后按照以下步骤使用动态存储设备进行部署:
2.1. 安装 Red Hat OpenShift Data Foundation Operator
您可以使用 Red Hat OpenShift Container Platform Operator Hub 安装 Red Hat OpenShift Data Foundation Operator。
先决条件
-
使用具有
cluster-admin
和 Operator 安装权限的账户访问 OpenShift Container Platform 集群。 - 您必须在 Red Hat OpenShift Container Platform 集群中至少有三个 worker 节点。
- 有关其他资源要求,请参阅规划您的部署指南。
当您需要覆盖 OpenShift Data Foundation 的集群范围默认节点选择器时,您可以在命令行界面中使用以下命令为
openshift-storage
命名空间指定空白节点选择器(在这种情况下创建 openshift-storage 命名空间):$ oc annotate namespace openshift-storage openshift.io/node-selector=
-
将节点作为
infra
污点,以确保只在该节点上调度 Red Hat OpenShift Data Foundation 资源。这有助于您节省订阅成本。如需更多信息,请参阅管理和分配存储资源指南中的如何将专用 worker 节点用于 Red Hat OpenShift Data Foundation 章节。
流程
- 登录 OpenShift Web 控制台。
- 点 Operators → OperatorHub。
-
在 Filter by keyword 框中滚动或键入
OpenShift Data Foundation
,以查找 OpenShift Data Foundation Operator。 - 点 Install。
在 Install Operator 页面中设置以下选项:
- 更新频道是 stable-4.9。
- 安装模式是 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。
我们建议使用所有默认设置。更改可能会导致意外行为。仅在您意识到其结果时进行修改。
验证步骤
- 验证 OpenShift Data Foundation Operator 是否显示绿色勾号(代表安装成功)。
成功安装 Operator 后,用户界面中会显示一个带有
Web console update is available
信息的弹出窗口。点这个弹出窗口中的 Refresh web console 来反映控制台的更改。- 在 Web 控制台中,导航到 Operators,并验证 OpenShift Data Foundation 是否可用。
如果在安装 OpenShift Data Foundation Operator 后,不能自动启用 console plugin 选项,则需要启用它。
有关如何启用 console 插件的更多信息,请参阅启用 Red Hat OpenShift Data Foundation 控制台插件。
2.2. 创建 OpenShift Data Foundation 集群
安装 OpenShift Data Foundation 操作器(operator)后,创建 OpenShift Data Foundation。
先决条件
- OpenShift Data Foundation 操作器必须从 Operator Hub 安装。如需更多信息,请参阅 安装 OpenShift Data Foundation Operator。
请注意,Google Cloud 平台的默认存储类使用硬盘(HDD)。要使用基于固态驱动器 (SSD) 的磁盘来提高性能,您需要使用
pd-ssd
创建存储类,如以下ssd-storeageclass.yaml
示例所示:apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: faster provisioner: kubernetes.io/gce-pd parameters: type: pd-ssd volumeBindingMode: WaitForFirstConsumer reclaimPolicy: Delete
流程
在 OpenShift Web 控制台中,点 Operators → Installed Operators 查看所有已安装的 Operator。
确保所选 项目 为
openshift-storage
。- 点 OpenShift Data Foundation 操作器,然后单击 Create StorageSystem。
在 Backing storage 页面中,选择以下内容:
- 选择 Use a existing StorageClass 选项。
选择 Storage Class。
默认情况下,设置为
standard
。但是,如果您创建了存储类以使用 SSD 的磁盘来提高性能,则需要选择该存储类。-
展开 Advanced,为 Deployment type 选项选择
Full Deployment
。 - 点 Next。
在 Capacity and nodes 页面中,提供必要的信息:
从下拉列表中选择 Requested Capacity 的值。默认设置为
2 TiB
。注意选择初始存储容量后,集群扩展将使用所选的可用容量(原始存储的三倍)执行。
在 Select Nodes 部分中,选择至少三个可用节点。
对于具有多个可用区的云平台,请确保节点分布在不同的位置/可用性区域。
如果选择的节点与 OpenShift Data Foundation 的一个聚合的 30 个 CPU 和 72 GiB RAM 的要求不匹配,则会部署一个最小的集群。如需最低起始节点要求,请参阅 规划指南中的资源要求部分。
- 点 Next。
可选:在 Security and network 页面中,根据您的要求进行配置:
- 若要启用加密,可选择为块存储和文件存储启用数据加密。
选择一个或多个加密级别:
集群范围的加密
加密整个集群(块和文件)。
StorageClass 加密
使用启用加密的存储类创建加密的持久性卷(仅块)。
选择 Connect to an external key management service 复选框。这是集群范围加密的可选选项。
-
默认情况下,Key Management Service Provider 设置为
Vault
。 - 输入 Vault Service Name、Vault 服务器的主机地址 ('https://<hostname 或 ip>')、端口号和 Token。
展开 Advanced Settings,以根据您的
Vault
配置输入其他设置和证书详情。- 在 后端路径中输入为 OpenShift Data Foundation 专用且唯一的 Key Value secret 路径。
- 可选:输入 TLS Server Name 和 Vault Enterprise Namespace。
- 上传对应的 PEM 编码证书文件,以提供 CA 证书、客户端证书和客户端私钥。
- 点击 Save。
-
默认情况下,Key Management Service Provider 设置为
- 点 Next。
在 Review and create 页面中,检查配置详情。
若要修改任何配置设置,请单击 Back。
- 单击 Create StorageSystem。
验证步骤
验证已安装存储集群的最终状态:
- 在 OpenShift Web 控制台中,导航到 Installed Operators → OpenShift Data Foundation → Storage System → ocs-storagecluster-storagesystem → Resources。
验证
StorageCluster
的Status
是否为Ready
,并且旁边有一个绿色勾号标记。- 要验证 OpenShift 数据基础的所有组件是否已成功安装,请参阅验证您的 OpenShift Data Foundation 部署。
其它资源
要启用 Overprovision Control 警报,请参阅 Monitoring 中的 Alerts 指南。
2.3. 验证 OpenShift Data Foundation
使用本节验证 OpenShift Data Foundation 是否已正确部署。
2.3.1. 验证 pod 的状态
流程
- 从 OpenShift Web 控制台点 Workloads → Pods。
从 Project 下拉列表中选择
openshift-storage
。注意如果禁用 Show default projects 选项,请使用切换按钮列出所有默认项目。
有关每个组件预期的 pod 数量及其变化取决于节点数量的更多信息,请参阅 表 2.1 “对应 OpenShift Data Foundation 集群的 Pod”。
点 Running 和 Completed 标签页验证以下 pod 是否处于
Running
和Completed
状态:表 2.1. 对应 OpenShift Data Foundation 集群的 Pod 组件 对应的 pod OpenShift Data Foundation Operator
-
OCS-operator-*
(在任何 worker 节点上有 1 个 pod) -
ocS-metrics-exporter-*
(任何 worker 节点上 1 个 pod) -
odF-operator-controller-manager-*
(任何 worker 节点上 1 个 pod) -
odf-console-*
(任何 worker 节点上 1 个 pod)
Rook-ceph Operator
rook-ceph-operator-*
(任何 worker 节点上有 1 个 pod)
多云对象网关
-
noobaa-operator-*
(任何 worker 节点上 1 个 pod) -
noobaa-core-*
(任何存储节点上 1 个 pod) -
noobaa-db-pg-*
(任何存储节点上 1 个 pod) -
noobaa-endpoint-*
(任何存储节点上 1 个 pod)
MON
rook-ceph-mon-*
(在存储节点间分布 3 个 pod)
MGR
rook-ceph-mgr-*
(任何存储节点上的 1 个 pod)
MDS
rook-ceph-mds-ocs-storagecluster-cephfilesystem-*
(2 个 pod 在存储节点间分布)
CSI
cephfs
-
csi-cephfsplugin-*
(每个 worker 节点上 1 个 pod) -
csi-cephfsplugin-provisioner-*
(2 个 pod 在不同的 worker 节点上分布)
-
rbd
-
csi-rbdplugin-*
(每个 worker 节点上 1 个 pod) -
csi-rbdplugin-provisioner-*
(2 个 pod 在不同的 worker 节点上分步)
-
rook-ceph-crashcollector
rook-ceph-crashcollector-*
(每个存储节点上 1 个 pod)
OSD
-
rook-ceph-osd-*
(每个设备 1 个 pod) -
rook-ceph-osd-prepare-ocs-deviceset-*
(每个设备 1 个 pod)
-
2.3.2. 验证 OpenShift Data Foundation 集群是否健康
流程
- 在 OpenShift Web 控制台中,点 Storage → OpenShift Data Foundation。
- 在 Overview 选项卡的 Status 卡中,点 Storage System,然后点弹出框中的存储系统链接。
- 在 Block and File 选项卡的 Status 卡中,验证 Storage Cluster 是否具有绿色勾号。
- 在 Details 卡中,验证是否显示集群信息。
如需有关使用 Block and File 仪表板的 OpenShift Data Foundation 集群健康的更多信息,请参阅 监控 OpenShift Data Foundation。
2.3.3. 验证 Multicloud 对象网关是否健康
流程
- 在 OpenShift Web 控制台中,点 Storage → OpenShift Data Foundation。
在 Overview 选项卡的 Status 卡中,点 Storage System,然后点弹出框中的存储系统链接。
- 在 Object 选项卡的 Status 卡 中,验证 Object Service 和数据弹性 都具有绿色勾号。
- 在 Details 卡中,验证是否显示了 MCG 信息。
如需有关使用对象服务仪表板的 OpenShift Data Foundation 集群健康的更多信息,请参阅监控 OpenShift Data Foundation。
2.3.4. 验证 OpenShift Data Foundation 特定的存储类是否存在
流程
- 从 OpenShift Web 控制台左侧窗格中,点击 Storage → Storage Classes。
验证是否在创建 OpenShift Data Foundation 集群时创建了以下存储类:
-
ocs-storagecluster-ceph-rbd
-
ocs-storagecluster-cephfs
-
openshift-storage.noobaa.io
-
第 3 章 部署独立多云对象网关
仅通过 OpenShift Data Foundation 部署多云对象网关组件可为部署提供灵活性,并有助于减少资源消耗。使用这个部分来只部署独立 Multicloud 对象网关组件,它涉及以下步骤:
- 安装 Red Hat OpenShift Data Foundation Operator
- 创建独立多云对象网关
3.1. 安装 Red Hat OpenShift Data Foundation Operator
您可以使用 Red Hat OpenShift Container Platform Operator Hub 安装 Red Hat OpenShift Data Foundation Operator。
先决条件
-
使用具有
cluster-admin
和 Operator 安装权限的账户访问 OpenShift Container Platform 集群。 - 您必须在 Red Hat OpenShift Container Platform 集群中至少有三个 worker 节点。
- 有关其他资源要求,请参阅规划您的部署指南。
当您需要覆盖 OpenShift Data Foundation 的集群范围默认节点选择器时,您可以在命令行界面中使用以下命令为
openshift-storage
命名空间指定空白节点选择器(在这种情况下创建 openshift-storage 命名空间):$ oc annotate namespace openshift-storage openshift.io/node-selector=
-
将节点作为
infra
污点,以确保只在该节点上调度 Red Hat OpenShift Data Foundation 资源。这有助于您节省订阅成本。如需更多信息,请参阅管理和分配存储资源指南中的如何将专用 worker 节点用于 Red Hat OpenShift Data Foundation 章节。
流程
- 登录 OpenShift Web 控制台。
- 点 Operators → OperatorHub。
-
在 Filter by keyword 框中滚动或键入
OpenShift Data Foundation
,以查找 OpenShift Data Foundation Operator。 - 点 Install。
在 Install Operator 页面中设置以下选项:
- 更新频道是 stable-4.9。
- 安装模式是 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。
我们建议使用所有默认设置。更改可能会导致意外行为。仅在您意识到其结果时进行修改。
验证步骤
- 验证 OpenShift Data Foundation Operator 是否显示绿色勾号(代表安装成功)。
成功安装 Operator 后,用户界面中会显示一个带有
Web console update is available
信息的弹出窗口。点这个弹出窗口中的 Refresh web console 来反映控制台的更改。- 在 Web 控制台中,导航到 Operators,并验证 OpenShift Data Foundation 是否可用。
如果在安装 OpenShift Data Foundation Operator 后,不能自动启用 console plugin 选项,则需要启用它。
有关如何启用 console 插件的更多信息,请参阅启用 Red Hat OpenShift Data Foundation 控制台插件。
3.2. 创建独立多云对象网关
使用本节来仅创建带有 OpenShift Data Foundation 的 Multicloud 对象网关组件。
先决条件
- 确保已安装 OpenShift Data Foundation Operator。
- (用于仅使用本地存储设备进行部署)确保安装了 Local Storage Operator。
- 确保您有一个存储类,并被设置为默认值。
流程
在 OpenShift Web 控制台中,点 Operators → Installed Operators 查看所有已安装的 Operator。
确保所选项目为
openshift-storage
。- 单击 OpenShift Data Foundation operator,然后单击 Create StorageSystem。
- 在 Backing storage 页面中,展开 Advanced。
- 为 Deployment 类型选择 Multicloud Object Gateway。
- 点 Next。
可选:在 Security 页面中,选择连接到外部密钥管理服务。
-
默认情况下,Key Management Service Provider 设置为
Vault
。 - 输入 Vault Service Name、Vault 服务器的主机地址 ('https://<hostname 或 ip>')、端口号和 Token。
展开 Advanced Settings,以根据您的
Vault
配置输入其他设置和证书详情。- 在 后端路径中输入为 OpenShift Data Foundation 专用且唯一的 Key Value secret 路径。
- 可选:输入 TLS Server Name 和 Vault Enterprise Namespace。
- 上传对应的 PEM 编码证书文件,以提供 CA 证书、客户端证书和客户端私钥。
- 点击 Save。
- 点 Next。
-
默认情况下,Key Management Service Provider 设置为
在 Review and create 页面中,查看配置详情:
若要修改任何配置设置,请单击 Back。
- 单击 Create StorageSystem。
验证步骤
- 验证 OpenShift Data Foundation 集群是否健康
- 在 OpenShift Web 控制台中,点 Storage → OpenShift 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-operator-*
(在任何 worker 节点上有 1 个 pod) -
ocS-metrics-exporter-*
(任何 worker 节点上 1 个 pod) -
odF-operator-controller-manager-*
(任何 worker 节点上 1 个 pod) -
odf-console-*
(任何 worker 节点上 1 个 pod)
Rook-ceph Operator
rook-ceph-operator-*
(任何 worker 节点上有 1 个 pod)
多云对象网关
-
noobaa-operator-*
(任何 worker 节点上 1 个 pod) -
noobaa-core-*
(任何 worker 节点上有 1 个 pod) -
noobaa-db-pg-*
(任何 worker 节点上有 1 个 pod) -
noobaa-endpoint-*(
任何 worker 节点上有 1 个 pod)
-
第 4 章 卸载 OpenShift Data Foundation
4.1. 以内部模式卸载 OpenShift Data Foundation
要以内部模式卸载 OpenShift Data Foundation,请参阅 有关卸载 OpenShift Data Foundation 的知识库文章。
第 5 章 存储类和存储池
OpenShift Data Foundation Operator 根据使用的平台安装默认存储类。这个默认存储类由 Operator 所有和控制,且无法删除或修改。但是,如果您希望存储类具有不同的行为,可以创建自定义存储类。
您可以创建多个存储池,映射到提供以下功能的存储类:
- 使具有自身高可用性的应用能够使用具有两个副本的持久卷,从而可能提高应用性能。
- 使用启用了压缩的存储类为持久性卷声明节省空间。
外部模式 OpenShift Data Foundation 集群不支持多个存储类和多个池。
使用单个设备集的最小集群,只能创建两个新的存储类。每个存储集群扩展都允许两个新的附加存储类。
5.1. 创建存储类和池
您可以使用现有池创建存储类,也可以在创建存储类时为存储类创建新池。
先决条件
-
确保您已登录到 OpenShift Container Platform Web 控制台,并且 OpenShift Data Foundation 集群处于
Ready
状态。
流程
- 点 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. 为持久性卷加密创建存储类
持久性卷(PV)加密可确保租户(应用程序)之间的隔离和保密性。在使用 PV 加密前,您必须为 PV 加密创建一个存储类。
OpenShift Data Foundation 支持在 HashiCorp Vault 中存储加密密码短语。使用以下步骤创建加密的存储类,使用外部密钥管理系统(KMS)进行持久性卷加密。持久卷加密仅可用于 RBD PV。您可以通过两种不同的方式配置对 KMS 的访问:
-
使用
vaulttoken
允许用户使用令牌进行身份验证 -
使用
vaulttenantsa
(技术预览):允许用户使用 serviceaccounts 通过 Vault 进行身份验证
使用 vaulttenantsa
访问 KMS 是一项技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
如需更多信息,请参阅技术预览功能支持范围。
在按照创建存储类的步骤之前,请参阅您的用例的相关先决条件部分:
5.2.1. 使用 vaulttoken
的先决条件
-
OpenShift 数据基础集群处于
Ready
状态。 在外部密钥管理系统 (KMS) 上,
- 确保存在具有令牌的策略,并且启用了 Vault 中的键值后端路径。如需更多信息,请参阅在 Vault 中启用键值和策略。
- 确保您在 Vault 服务器上使用签名的证书。
在租户命名空间中创建一个 secret,如下所示:
- 在 OpenShift Container Platform web 控制台中进入 Workloads → Secrets。
- 点 Create → Key/value secret。
-
输入 Secret Name 作为
ceph-csi-kms-token
。 -
输入 Key 作为
token
。 - 输入 Value。它是来自 Vault 的令牌。您可以单击 Browse 来选择并上传含有令牌的文件,或者直接在文本框中输入令牌。
- 点击 Create。
只有在所有使用 ceph-csi-kms-token
的加密 PVC 已被删除后,才能删除令牌。
接下来,按照 第 5.2.3 节 “为 PV 加密创建存储类的步骤” 中的步骤操作。
5.2.2. 使用 vaulttenantsa
的先决条件
-
OpenShift 数据基础集群处于
Ready
状态。 在外部密钥管理系统 (KMS) 上,
- 确保策略存在,并且已启用 Vault 中的键值后端路径。如需更多信息,请参阅在 Vault 中启用键值和策略。
- 确保您在 Vault 服务器上使用签名的证书。
在租户命名空间中创建以下 serviceaccount,如下所示:
$ cat <<EOF | oc create -f - apiVersion: v1 kind: ServiceAccount metadata: name: ceph-csi-vault-sa EOF
必须配置 Kubernetes 身份验证方法,然后才能使用 OpenShift 数据基础进行身份验证并开始使用 Vault。以下说明创建并配置所需的
serviceAccount
、ClusterRole
和ClusterRoleBinding
,以允许 OpenShift Data Foundation 使用 Vault 进行身份验证。将以下 YAML 应用到您的 Openshift 集群:
apiVersion: v1 kind: ServiceAccount metadata: name: rbd-csi-vault-token-review --- kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: rbd-csi-vault-token-review rules: - apiGroups: ["authentication.k8s.io"] resources: ["tokenreviews"] verbs: ["create", "get", "list"] --- kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: rbd-csi-vault-token-review subjects: - kind: ServiceAccount name: rbd-csi-vault-token-review namespace: openshift-storage roleRef: kind: ClusterRole name: rbd-csi-vault-token-review apiGroup: rbac.authorization.k8s.io
识别与上述创建的 serviceaccount(SA)关联的 secret 名称:
$ oc -n openshift-storage get sa rbd-csi-vault-token-review -o jsonpath="{.secrets[*]['name']}"
从 secret 获取令牌和 CA 证书:
$ oc get secret <secret associated with SA> -o jsonpath="{.data['token']}" | base64 --decode; echo $ oc get secret <secret associated with SA> -o jsonpath="{.data['ca\.crt']}" | base64 --decode; echo
检索 OCP 集群端点:
$ oc config view --minify --flatten -o jsonpath="{.clusters[0].cluster.server}"
使用上面步骤中收集的信息在 Vault 中设置 kubernetes 验证方法,如下所示:
$ vault auth enable kubernetes $ vault write auth/kubernetes/config token_reviewer_jwt=<SA token> kubernetes_host=<OCP cluster endpoint> kubernetes_ca_cert=<SA CA certificate>
在 Vault 中为租户命名空间创建一个角色:
$ vault write "auth/kubernetes/role/csi-kubernetes" bound_service_account_names="ceph-csi-vault-sa" bound_service_account_namespaces=<tenant_namespace> policies=<policy_name_in_vault>
csi-kubernetes
是 OpenShift Data Foundation 在 Vault 中寻找的默认角色名称。Openshift Data Foundation 集群中租户命名空间中的默认服务帐户名称为ceph-csi-vault-sa
。这些默认值可以通过在租户命名空间中创建 ConfigMap 来覆盖。有关覆盖默认名称的更多信息,请参阅使用租户 ConfigMap 覆盖 Vault 连接详情。
要创建一个使用
vaulttenantsa
方法进行 PV 保护的存储类,您必须编辑现有的 ConfigMap 或创建名为csi-kms-connection-details
的配置映射,它将保存建立与 Vault 连接所需的所有信息。以下提供的 yaml 示例可用于更新或创建
csi-kms-connection-detail
ConfigMap:apiVersion: v1 data: vault-tenant-sa: |- { "encryptionKMSType": "vaulttenantsa", "vaultAddress": "<https://hostname_or_ip_of_vault_server:port>", "vaultTLSServerName": "<vault TLS server name>", "vaultAuthPath": "/v1/auth/kubernetes/login", "vaultAuthNamespace": "<vault auth namespace name>" "vaultNamespace": "<vault namespace name>", "vaultBackendPath": "<vault backend path name>", "vaultCAFromSecret": "<secret containing CA cert>", "vaultClientCertFromSecret": "<secret containing client cert>", "vaultClientCertKeyFromSecret": "<secret containing client private key>", "tenantSAName": "<service account name in the tenant namespace>" } metadata: name: csi-kms-connection-details
-
encryptionKMSType
:应设置为vaulttenantsa
,以使用服务帐户通过 vault 进行身份验证。 -
vaultAddress
:使用端口号的 vault 服务器的主机名或 IP 地址。 -
vaultTLSServerName
:(可选) vault TLS 服务器名称 -
vaultAuthPath
:(可选)在 Vault 中启用 kubernetes auth 方法的路径。默认路径为kubernetes
。如果在kubernetes
之外的其他路径中启用了 auth 方法,则需要将此变量设置为"/v1/auth/<path>/login"。
-
vaultAuthNamespace
:(可选)启用 kubernetes auth 方法的 Vault 命名空间。 -
VaultNamespace
:(可选)用于存储密钥的后端路径存在的 Vault 命名空间 -
vaultBackendPath:
保存加密密钥的 Vault 中的后端路径 -
vaultCAFromSecret
:包含来自 Vault 的 CA 证书的 OpenShift Data Foundation 集群中的 secret -
vaultClientCertFromSecret
:包含来自 Vault 的客户端证书的 OpenShift Data Foundation 集群中的 secret -
vaultClientCertKeyFromSecret
:包含来自 Vault 的客户端私钥的 OpenShift Data Foundation 集群中的 secret -
tenantSAName
:(可选)租户命名空间中的服务帐户名称。默认值为ceph-csi-vault-sa
。如果要使用其他名称,则必须相应地设置此变量。
-
接下来,按照 第 5.2.3 节 “为 PV 加密创建存储类的步骤” 中的步骤操作。
5.2.3. 为 PV 加密创建存储类的步骤
在为 vaulttoken
或 vaulttenantsa
执行必要的先决条件后,请执行以下步骤来创建启用了加密的存储类。
- 进入 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 连接详情:
-
选择现有 KMS 连接 :从下拉列表中选择现有 KMS 连接。该列表填充自
csi-kms-connection-details
ConfigMap 中的连接详情。 创建新的 KMS 连接 :这仅适用于
vaulttoken
。- 默认情况下,Key Management Service Provider 设置为 Vault。
-
输入唯一的 Vault Service Name、Vault 服务器的主机地址 (
https://<hostname 或 ip>
)和端口号 。 展开 Advanced Settings ,以根据您的 Vault 配置输入其他设置和证书详情。
- 在 后端路径中输入为 OpenShift Data Foundation 专用且唯一的 Key Value secret 路径。
- 可选 :输入 TLS Server Name 和 Vault Enterprise 命名空间。
- 通过上传相应的 PEM 编码证书文件提供 CA 证书、客户端证书和客户端私钥。
- 单击 Save。
- 点击 Save。
-
选择现有 KMS 连接 :从下拉列表中选择现有 KMS 连接。该列表填充自
- 点击 Create。
如果 HashiCorp Vault 设置不允许自动检测后端路径使用的 Key/Value(KV)secret 引擎 API 版本,请编辑 ConfigMap 以添加
VAULT_BACKEND
或vaultBackend
参数。注意VAULT_BACKEND
或vaultBackend
是已添加到 configmap 中的可选参数,以指定与后端路径关联的 KV secret 引擎 API 的版本。确保值与为后端路径设置的 KV secret 引擎 API 版本匹配,否则可能会导致持久性卷声明(PVC)创建过程中失败。识别新创建的存储类使用的 encryptionKMSID。
- 在 OpenShift Web 控制台中,导航到 Storage → Storage Classes。
- 点 Storage class name → YAML 标签页。
捕获存储类使用的 encryptionKMSID。
例如:
encryptionKMSID: 1-vault
- 在 OpenShift Web 控制台中,导航到 Workloads → ConfigMaps。
- 要查看 KMS 连接详情,请单击点击 csi-kms-connection-details。
编辑 ConfigMap。
- 点击 Action 菜单 (⋮) → Edit ConfigMap。
根据为之前标识的 encryptionKMSID 配置的后端,添加
VAULT_BACKEND
或vaultBackend
参数。您可以为 KV secret engine API、版本 1 和
kv-v2
分配 kv 用于 KV secret engine API(版本 2)。例如:
kind: ConfigMap apiVersion: v1 metadata: name: csi-kms-connection-details [...] data: 1-vault: |- { "KMS_PROVIDER": "vaulttokens", "KMS_SERVICE_NAME": "1-vault", [...] "VAULT_BACKEND": "kv-v2" } 2-vault: |- { "encryptionKMSType": "vaulttenantsa", [...] "vaultBackend": "kv-v2" }
- 点 Save
后续步骤
5.2.3.1. 使用租户 ConfigMap 覆盖 Vault 连接详情
可以通过在 Openshift 命名空间中创建 ConfigMap 来为每个租户重新配置 Vault 连接详情,其配置选项与 openshift-storage
命名空间中的 csi-kms-connection-details
ConfigMap 中设置的值不同。ConfigMap 需要位于租户命名空间中。租户命名空间中的 ConfigMap 中的值将覆盖在该命名空间中创建的加密持久性卷的 csi-kms-connection-details
ConfigMap 中设置的值。
流程
- 确保您位于租户命名空间中。
- 点 Workloads → ConfigMaps。
- 点 Create ConfigMap。
以下是 yaml 示例。给定租户命名空间要覆盖的值可以在
data
部分下指定,如下所示:--- apiVersion: v1 kind: ConfigMap metadata: name: ceph-csi-kms-config data: vaultAddress: "<vault_address:port>" vaultBackendPath: "<backend_path>" vaultTLSServerName: "<vault_tls_server_name>" vaultNamespace: "<vault_namespace>"
- 编辑完 yaml 后,点 Create。
第 6 章 为 OpenShift Container Platform 服务配置存储
您可以使用 OpenShift Data Foundation 为 OpenShift Container Platform 服务(如镜像 registry、监控和日志记录)提供存储。
为这些服务配置存储的过程取决于 OpenShift Data Foundation 部署中使用的基础架构。
始终确保您具有适用于这些服务的大量存储容量。如果这些关键服务的存储空间不足,集群就会变得不可用,且很难恢复。
红帽建议为这些服务配置较短的策展和保留间隔。详情请参阅 OpenShift Container Platform 文档中的配置持久性存储的配置 Curator 调度和修改 Prometheus 指标数据的保留时间部分。
如果您确实耗尽这些服务的存储空间,请联系红帽客户支持。
6.1. 将镜像 registry 配置为使用 OpenShift Data Foundation
OpenShift Container Platform 提供了一个内建的容器镜像 Registry,它作为一个标准的工作负载在集群中运行。registry 通常用作集群中构建的镜像的发布目标,以及在集群中运行的工作负载的镜像源。
按照本节中的说明,将 OpenShift Data Foundation 配置为 Container Image Registry 的存储。在 Google Cloud 上,不需要更改 registry 的存储。
此过程不会将数据从现有镜像 registry 迁移到新镜像 registry。如果您在现有 registry 中已有容器镜像,请在完成此过程前备份 registry,并在这个过程完成后重新注册您的镜像。
先决条件
- 具有 OpenShift Web 控制台的管理访问权限。
-
OpenShift Data Foundation Operator 在
openshift-storage
命名空间上安装并运行。在 OpenShift Web 控制台中,点 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-config
Config Map:将尖括号 (
<
,>
) 中的内容替换为您自己的值,如retention:24h
或storage:40Gi
。将 storageClassName 替换为使用 provisioner
openshift-storage.rbd.csi.ceph.com
的storageclass
。在下例中,storageclass 的名称为ocs-storagecluster-ceph-rbd
。cluster-monitoring-config
Config Map 示例apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | prometheusK8s: retention: <time to retain monitoring files, e.g. 24h> volumeClaimTemplate: metadata: name: ocs-prometheus-claim spec: storageClassName: ocs-storagecluster-ceph-rbd resources: requests: storage: <size of claim, e.g. 40Gi> alertmanagerMain: volumeClaimTemplate: metadata: name: ocs-alertmanager-claim spec: storageClassName: ocs-storagecluster-ceph-rbd resources: requests: storage: <size of claim, e.g. 40Gi>
- 单击 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 复制策略的详情,请参考关于部署和配置集群日志记录中的 Elasticsearch 复制策略。
缺少存储块将导致默认存储支持部署。例如:
spec: logStore: type: "elasticsearch" elasticsearch: nodeCount: 3 storage: {}
如需更多信息,请参阅配置集群日志记录。
6.3.2. 配置集群日志记录以使用 OpenShift Data Foundation
按照本节中的说明,将 OpenShift Data Foundation 配置为 OpenShift 集群日志记录的存储。
当您首次在 OpenShift 数据基础中配置日志记录时,您可以获取所有日志。但是,在卸载和重新安装日志记录后,会删除旧日志并只处理新日志。
先决条件
- 具有 OpenShift Web 控制台的管理访问权限。
-
OpenShift Data Foundation Operator 在
openshift-storage
命名空间上安装并运行。 -
Cluster logging Operator 已安装并在
openshift-logging
命名空间中运行。
流程
- 从 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。
验证步骤
验证持久卷声明是否已绑定到
elasticsearch
Pod。- 进入 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
如需了解更多详细信息,请参阅 Elasticsearch 数据。
要卸载由持久性卷声明支持的集群日志记录,请使用相应部署指南的卸载章节中从 OpenShift Data Foundation 中删除集群日志记录 Operator 的步骤。
第 7 章 使用 OpenShift Data Foundation 支持 OpenShift Container Platform 应用程序
您无法在 OpenShift Container Platform 安装过程中直接安装 OpenShift Data Foundation。但是,您可以使用 Operator Hub 在现有 OpenShift Container Platform 上安装 OpenShift Data Foundation,然后将 OpenShift Container Platform 应用程序配置为由 OpenShift Data Foundation 支持。
先决条件
- 已安装 OpenShift Container Platform,您还可管理 OpenShift Web 控制台。
-
OpenShift Data Foundation 在
openshift-storage
命名空间上安装并运行。
流程
在 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-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 污点足以满足权利的要求。
第 9 章 扩展存储节点
要扩展 OpenShift 数据基础的存储容量,您可以执行以下操作之一:
- 扩展存储节点 - 为现有 OpenShift Data Foundation 节点添加存储容量
- 扩展存储节点 - 添加包含存储容量的新 worker 节点
9.1. 扩展存储节点的要求
在继续扩展存储节点前,请参考以下部分以了解特定 Red Hat OpenShift Data Foundation 实例的节点要求:
始终确保您有大量的存储容量。
如果存储完全填满,则无法添加容量、删除内容或从存储中迁移内容来释放空间。当存储被完全占用时将很难恢复。
当集群存储容量达到总容量的 75%(接近满)和 85%(满)时,会发出容量警报。始终及时处理容量警告的信息,并定期检查您的存储以确保您不会耗尽存储空间。
如果您完全耗尽存储空间,请联系红帽客户支持。
9.2. 通过在 Google Cloud 基础架构上的 OpenShift Data Foundation 节点添加容量来扩展存储
您可以为配置的 Red Hat OpenShift Data Foundation worker 节点添加存储容量和性能。
先决条件
- 正在运行的 OpenShift Data Foundation 平台。
- OpenShift Web 控制台的管理特权。
- 要使用部署期间置备的存储类之外的存储类进行扩展,首先定义一个额外的存储类。详情请参阅创建存储类。
流程
- 登录 OpenShift Web 控制台。
- 点 Operators → Installed Operators。
- 点 OpenShift Data Foundation Operator。
单击 Storage Systems 选项卡。
- 点击存储系统名称最右侧的 Action Menu(⋮) 来扩展选项菜单。
- 从选项菜单中选择 Add Capacity。
- 选择 Storage Class。
如果您使用默认的存储类(它使用 HDD),则将存储类设置为 standard
。但是,如果您创建了存储类以使用 SSD 的磁盘来提高性能,则需要选择该存储类。
+ Raw Capacity 字段显示在存储类创建过程中设置的大小。所消耗的存储总量是这个大小的三倍,因为 OpenShift Data Foundation 使用的副本数为 3。
点击 Add。
-
要检查状态,请导航到 Storage → OpenShift Data Foundation,再验证 Status 卡中的
Storage 系统
是否具有绿色勾号。
-
要检查状态,请导航到 Storage → OpenShift Data Foundation,再验证 Status 卡中的
验证步骤
验证 Raw Capacity 卡。
- 在 OpenShift Web 控制台中,点 Storage → OpenShift 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 -o=custom-columns=NODE:.spec.nodeName pod/<OSD-pod-name>
<OSD-pod-name>
是 OSD pod 的名称。
例如:
oc get -o=custom-columns=NODE:.spec.nodeName pod/rook-ceph-osd-0-544db49d7f-qrgqm
对于上一步中确定的每个节点,请执行以下操作:
创建调试 pod,并为所选主机打开 chroot 环境。
$ oc debug node/<node-name>
<node-name>
是节点的名称。
$ chroot /host
检查
ocs-deviceset
名称旁边的crypt
关键字。$ lsblk
只有红帽支持团队的协助才支持 集群。
9.3. 通过添加新节点来横向扩展存储容量
要扩展存储容量,您需要执行以下操作:
- 添加新节点,以在现有工作程序节点已以其最大支持 OSD 运行时增加存储容量,即初始配置期间所选容量的 3 个 OSD 递增。
- 验证新节点是否已成功添加
- 添加节点后扩展存储容量
9.3.1. 在 Google Cloud installer 置备的基础架构上添加节点
先决条件
- 您必须登录到 OpenShift Container Platform 集群。
流程
- 导航到 Compute → Machine Sets。
在您要添加节点的机器集中,选择 Edit Machine Count。
- 添加节点数量,然后点 Save。
- 点 Compute → Nodes 并确认新节点是否处于 Ready 状态。
将 OpenShift 数据基础标签应用到新节点。
- 对于新节点,点击 Action 菜单(⋮) → Edit Labels。
- 添加 cluster.ocs.openshift.io/openshift-storage,然后点 Save。
建议您添加 3 个节点,每个节点都位于不同的区中。您必须添加 3 个节点,并对所有节点执行此步骤。
验证步骤
- 要验证是否已添加新节点,请参阅验证添加新节点。
9.3.2. 验证新节点的添加
执行以下命令并验证输出中是否存在新节点:
$ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1
点 Workloads → Pods,确认新节点上的以下 pod 处于 Running 状态 :
-
csi-cephfsplugin-*
-
csi-rbdplugin-*
-
9.3.3. 扩展存储容量
将新节点添加到 OpenShift Data Foundation 后,您必须扩展存储容量,如通过添加容量扩展存储中所述。
第 10 章 多云对象网关
10.1. 关于 Multicloud 对象网关
Multicloud 对象网关 (MCG) 是 OpenShift 的轻量级对象存储服务,允许用户启动小规模,然后根据需要在多个集群中、多个集群中和云原生存储中进行扩展。
10.2. 使用应用程序访问多云对象网关
您可以使用任何以 AWS S3 或使用 AWS S3 软件开发套件 (SDK) 的代码为目标的应用程序访问对象服务。应用程序需要指定多云对象网关(MCG)端点、访问密钥和 secret 访问密钥。您可以使用您的终端或 MCG CLI 来检索此信息。
先决条件
- 正在运行的 OpenShift Data Foundation 平台。
下载 MCG 命令行界面以简化管理。
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms # yum install mcg
注意指定使用订阅管理器启用存储库的适当架构。
- 对于 IBM Power,使用以下命令:
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-ppc64le-rpms
- 对于 IBM Z 基础架构,使用以下命令:
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
或者,您也可以从 下载红帽 OpenShift Data Foundation 页面上的 OpenShift Data Foundation RPM 安装 MCG 软件包。
注意根据您的架构选择正确的产品变体。
您可以通过两种方式访问相关的端点、访问密钥和 secret 访问密钥:
例 10.1. 示例
- 使用虚拟主机风格访问 MCG 存储桶
- 如果客户端应用程序尝试访问 https://<bucket-name>.s3-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com
<bucket-name>
是 MCG 存储桶的名称
例如:https://mcg-test-bucket.s3-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com
DNS 条目需要
mcg-test-bucket.s3-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com
来指向 S3 服务。
确保您有一个 DNS 条目,以便使用虚拟主机样式将客户端应用程序指向 MCG 存储桶。
10.2.1. 从终端访问 Multicloud 对象网关
流程
运行 describe
命令,以查看有关多云对象网关(MCG)端点的信息,包括其访问密钥(AWS_ACCESS_KEY_ID
值)和 secret 访问密钥(AWS_SECRET_ACCESS_KEY
值)。
# oc describe noobaa -n openshift-storage
输出结果类似如下:
Name: noobaa Namespace: openshift-storage Labels: <none> Annotations: <none> API Version: noobaa.io/v1alpha1 Kind: NooBaa Metadata: Creation Timestamp: 2019-07-29T16:22:06Z Generation: 1 Resource Version: 6718822 Self Link: /apis/noobaa.io/v1alpha1/namespaces/openshift-storage/noobaas/noobaa UID: 019cfb4a-b21d-11e9-9a02-06c8de012f9e Spec: Status: Accounts: Admin: Secret Ref: Name: noobaa-admin Namespace: openshift-storage Actual Image: noobaa/noobaa-core:4.0 Observed Generation: 1 Phase: Ready Readme: Welcome to NooBaa! ----------------- Welcome to NooBaa! ----------------- NooBaa Core Version: NooBaa Operator Version: Lets get started: 1. Connect to Management console: Read your mgmt console login information (email & password) from secret: "noobaa-admin". kubectl get secret noobaa-admin -n openshift-storage -o json | jq '.data|map_values(@base64d)' Open the management console service - take External IP/DNS or Node Port or use port forwarding: kubectl port-forward -n openshift-storage service/noobaa-mgmt 11443:443 & open https://localhost:11443 2. Test S3 client: kubectl port-forward -n openshift-storage service/s3 10443:443 & 1 NOOBAA_ACCESS_KEY=$(kubectl get secret noobaa-admin -n openshift-storage -o json | jq -r '.data.AWS_ACCESS_KEY_ID|@base64d') 2 NOOBAA_SECRET_KEY=$(kubectl get secret noobaa-admin -n openshift-storage -o json | jq -r '.data.AWS_SECRET_ACCESS_KEY|@base64d') alias s3='AWS_ACCESS_KEY_ID=$NOOBAA_ACCESS_KEY AWS_SECRET_ACCESS_KEY=$NOOBAA_SECRET_KEY aws --endpoint https://localhost:10443 --no-verify-ssl s3' s3 ls Services: Service Mgmt: External DNS: https://noobaa-mgmt-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com https://a3406079515be11eaa3b70683061451e-1194613580.us-east-2.elb.amazonaws.com:443 Internal DNS: https://noobaa-mgmt.openshift-storage.svc:443 Internal IP: https://172.30.235.12:443 Node Ports: https://10.0.142.103:31385 Pod Ports: https://10.131.0.19:8443 serviceS3: External DNS: 3 https://s3-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com https://a340f4e1315be11eaa3b70683061451e-943168195.us-east-2.elb.amazonaws.com:443 Internal DNS: https://s3.openshift-storage.svc:443 Internal IP: https://172.30.86.41:443 Node Ports: https://10.0.142.103:31011 Pod Ports: https://10.131.0.19:6443
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 访问密钥来连接到您的应用。
例 10.2. 示例
如果 AWS S3 CLI 是应用程序,以下命令将列出 OpenShift Data Foundation 中的存储桶:
AWS_ACCESS_KEY_ID=<AWS_ACCESS_KEY_ID> AWS_SECRET_ACCESS_KEY=<AWS_SECRET_ACCESS_KEY> aws --endpoint <ENDPOINT> --no-verify-ssl s3 ls
10.3. 允许用户访问多云对象网关控制台
要允许用户访问 Multicloud 对象网关(MCG)控制台,请确保用户满足以下条件:
- 用户位于 cluster-admins 组中。
- 用户位于 system:cluster-admins 虚拟组中.
先决条件
- 正在运行的 OpenShift Data Foundation 平台。
流程
启用对 MCG 控制台的访问。
在集群中执行以下步骤:
创建
cluster-admins
组。# oc adm groups new cluster-admins
将组绑定到
cluster-admin
角色。# oc adm policy add-cluster-role-to-group cluster-admin cluster-admins
从
cluster-admins
组中添加或删除用户,以控制对 MCG 控制台的访问。将一组用户添加到
cluster-admins
组:# oc adm groups add-users cluster-admins <user-name> <user-name> <user-name>...
其中
<user-name>
是要添加的用户的名称。注意如果您要向
cluster-admins
组添加一组用户,您不需要将新添加的用户绑定到 cluster-admin 角色,以允许访问 OpenShift Data Foundation 仪表板。从
cluster-admins
组中删除一组用户:# oc adm groups remove-users cluster-admins <user-name> <user-name> <user-name>...
其中
<user-name>
是要删除的用户的名称。
验证步骤
- 在 OpenShift Web 控制台中,以有权访问多云对象网关控制台的用户身份登录。
- 导航到 Storage → OpenShift Data Foundation。
- 在 Storage Systems 选项卡中,选择 storage 系统,然后点 Overview → Object 选项卡。
- 选择 Multicloud Object Gateway 链接。
- 点击 Allow selected permissions。
10.4. 为混合或多云添加存储资源
10.4.1. 创建新的后备存储
在 OpenShift Data Foundation 中使用此流程创建新的后备存储。
先决条件
- OpenShift Data Foundation 的管理员访问权限。
流程
- 在 OpenShift Web 控制台中,点 Storage → OpenShift 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.4.2 节 “使用 MCG 命令行界面为混合或多云添加存储资源” 并按照使用 YAML 添加存储资源的步骤进行操作。
注意此菜单与 Google Cloud 和本地 PVC 以外的所有供应商相关。
- 输入 Target bucket。目标 bucket 是托管在远程云服务的容器存储。它允许您创建一个连接,告诉 MCG 它可以将此存储桶用于系统。
- 单击 Create Backing Store。
验证步骤
- 在 OpenShift Web 控制台中,点 Storage → OpenShift Data Foundation。
- 单击 Backing Store 选项卡,以查看所有后备存储。
10.4.2. 使用 MCG 命令行界面为混合或多云添加存储资源
多云对象网关 (MCG) 简化了跨云供应商和集群的数据生成过程。
您必须添加 MCG 可以使用的后备存储。
根据部署类型,您可以选择以下步骤之一来创建后备存储:
- 有关创建 AWS 支持的后备存储,请参阅 第 10.4.2.1 节 “创建 AWS 支持的后备存储”
- 有关创建 IBM COS 支持的后备存储,请参考 第 10.4.2.2 节 “创建 IBM COS 支持的后备存储”
- 有关创建 Azure 支持的后备存储,请参阅 第 10.4.2.3 节 “创建 Azure 支持的后备存储”
- 有关创建 GCP 支持的后备存储,请参阅 第 10.4.2.4 节 “创建由 GCP 支持的后备存储”
- 有关创建本地持久性卷支持的后备存储,请参阅 第 10.4.2.5 节 “创建由本地持久性卷支持的后备存储”
对于 VMware 部署,请跳至 第 10.4.3 节 “创建兼容 s3 的多云对象网关后备存储” 以了解更多详细信息。
10.4.2.1. 创建 AWS 支持的后备存储
先决条件
下载多云对象网关(MCG)命令行界面。
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms # yum install mcg
注意指定使用订阅管理器启用存储库的适当架构。例如,如果是 IBM Z 基础架构,请使用以下命令:
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
另外,您还可以从位于 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/packages的 OpenShift Data Foundation RPM 安装 MCG 软件包。
注意根据您的架构选择正确的产品变体。
流程
在 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>
-
您必须使用 Base64 提供并编码您自己的 AWS 访问密钥 ID 和 secret 访问密钥,并使用结果代替
<AWS ACCESS KEY ID ENCODED IN BASE64>
和<AWS SECRET ACCESS KEY ENCODED IN BASE64>
。 -
将
<backingstore-secret-name>
替换为唯一名称。
-
您必须使用 Base64 提供并编码您自己的 AWS 访问密钥 ID 和 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 存储桶名称。此参数告知 MCG 将哪一个存储桶用作其后备存储的目标存储桶,以及随后数据存储和管理。 -
将
<backingstore-secret-name>
替换为上一步中创建的 secret 的名称。
-
将
10.4.2.2. 创建 IBM COS 支持的后备存储
先决条件
下载多云对象网关(MCG)命令行界面。
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms # yum install mcg
注意指定使用订阅管理器启用存储库的适当架构。例如,
- 对于 IBM Power,使用以下命令:
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-ppc64le-rpms
- 对于 IBM Z 基础架构,使用以下命令:
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
另外,您还可以从位于 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/packages的 OpenShift Data Foundation RPM 安装 MCG 软件包。
注意根据您的架构选择正确的产品变体。
流程
在 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、机密访问密钥和对应于现有 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>
-
您必须使用 Base64 提供和编码您自己的 IBM COS 访问密钥 ID 和 secret 访问密钥,并使用结果代替
<IBM COS ACCESS KEY ID ENCODED IN BASE64>
和<IBM COS SECRET ACCESS KEY ENCODED IN BASE64>
。 -
将
<backingstore-secret-name>
替换为唯一名称。
-
您必须使用 Base64 提供和编码您自己的 IBM COS 访问密钥 ID 和 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 存储桶名称位置对应的区域端点。这个参数告诉 Multicloud Object Gateway 使用哪个端点进行后备存储,然后再将哪一端点用于数据存储和管理。 -
将
<backingstore-secret-name>
替换为上一步中创建的 secret 的名称。
-
将
10.4.2.3. 创建 Azure 支持的后备存储
先决条件
下载多云对象网关(MCG)命令行界面。
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms # yum install mcg
注意指定使用订阅管理器启用存储库的适当架构。例如,如果是 IBM Z 基础架构,请使用以下命令:
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
另外,您还可以从位于 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/packages的 OpenShift Data Foundation RPM 安装 MCG 软件包。
注意根据您的架构选择正确的产品变体。
流程
在 MCG 命令行界面中运行以下命令:
noobaa backingstore create azure-blob <backingstore_name> --account-key=<AZURE ACCOUNT KEY> --account-name=<AZURE ACCOUNT NAME> --target-blob-container <blob container name>
-
将
<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>
-
您必须使用 Base64 提供和编码您自己的 Azure 帐户名称和帐户密钥,并使用结果代替
<AZURE ACCOUNT NAME ENCODED IN BASE64>
和<AZURE ACCOUNT KEY ENCODED IN BASE64>
。 -
将
<backingstore-secret-name>
替换为唯一名称。
-
您必须使用 Base64 提供和编码您自己的 Azure 帐户名称和帐户密钥,并使用结果代替
为特定的后备存储应用以下 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.4.2.4. 创建由 GCP 支持的后备存储
先决条件
下载多云对象网关(MCG)命令行界面。
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms # yum install mcg
注意指定使用订阅管理器启用存储库的适当架构。例如,如果是 IBM Z 基础架构,请使用以下命令:
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
另外,您还可以从位于 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/packages的 OpenShift Data Foundation RPM 安装 MCG 软件包。
注意根据您的架构选择正确的产品变体。
流程
在 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>
-
将
<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>
-
您必须使用 Base64 提供并编码您自己的 GCP 服务帐户私钥,并使用结果代替
<GCP PRIVATE KEY ENCODED IN BASE64>
。 -
将
<backingstore-secret-name>
替换为唯一名称。
-
您必须使用 Base64 提供并编码您自己的 GCP 服务帐户私钥,并使用结果代替
为特定的后备存储应用以下 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.4.2.5. 创建由本地持久性卷支持的后备存储
先决条件
下载多云对象网关(MCG)命令行界面。
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms # yum install mcg
注意指定使用订阅管理器启用存储库的适当架构。例如,如果是 IBM Z 基础架构,请使用以下命令:
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
另外,您还可以从位于 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/packages的 OpenShift Data Foundation RPM 安装 MCG 软件包。
注意根据您的架构选择正确的产品变体。
流程
在 MCG 命令行界面中运行以下命令:
noobaa backingstore create pv-pool <backingstore_name> --num-volumes=<NUMBER OF VOLUMES> --pv-size-gb=<VOLUME SIZE> --storage-class=<LOCAL STORAGE CLASS>
-
将
<backingstore_name>
替换为后备存储的名称。 -
将
<NUMBER OF VOLUMES>
替换为您要创建的卷数。请注意,增加卷数量可向上扩展存储。 -
将
<VOLUME SIZE>
替换为每个卷所需的大小(以 GB 为单位)。 将
<LOCAL STORAGE CLASS>
替换为本地存储类,建议使用ocs-storagecluster-ceph-rbd
。输出结果类似如下:
INFO[0001] ✅ Exists: NooBaa "noobaa" INFO[0002] ✅ Exists: BackingStore "local-mcg-storage"
-
将
您还可以使用 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> storageClass: <LOCAL STORAGE CLASS> type: pv-pool
-
将
<backingstore_name>
替换为后备存储的名称。 -
将
<NUMBER OF VOLUMES>
替换为您要创建的卷数。请注意,增加卷数量可向上扩展存储。 -
将
<VOLUME SIZE>
替换为每个卷所需的大小(以 GB 为单位)。请注意,字母 G 应保留。 -
将
<LOCAL STORAGE CLASS>
替换为本地存储类,建议使用ocs-storagecluster-ceph-rbd
。
-
将
10.4.3. 创建兼容 s3 的多云对象网关后备存储
多云对象网关(MCG)可以使用任何 S3 兼容对象存储作为后备存储,例如,Red Hat Ceph Storage 的 RADOS 对象网关(RGW)。以下步骤演示了如何为 Red Hat Ceph Storage 的 RGW 创建 S3 兼容 MCG 后备存储。请注意,部署 RGW 时,OpenShift Data Foundation operator 会自动为 MCG 创建 S3 兼容后备存储。
流程
在 MCG 命令行界面中运行以下命令:
noobaa backingstore create s3-compatible rgw-resource --access-key=<RGW ACCESS KEY> --secret-key=<RGW SECRET KEY> --target-bucket=<bucket-name> --endpoint=<RGW endpoint>
要获取
<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.4.4. 使用用户界面为混合和多云添加存储资源
流程
- 在 OpenShift Web 控制台中,点 Storage → OpenShift Data Foundation。
- 在 Storage Systems 选项卡中,选择 storage 系统,然后点 Overview → Object 选项卡。
- 选择 Multicloud Object Gateway 链接。
选择左侧的资源选项卡,突出显示下方。从填充的列表中,选择 Add Cloud Resource。
选择 Add new connection。
选择相关的原生云供应商或 S3 兼容选项并填写详情。
选择新创建的连接并将其映射到现有存储桶。
- 重复这些步骤,根据需要创建任意数量的后备存储。
在 NooBaa UI 中创建的资源不能由 OpenShift UI 或 MCG CLI 使用。
10.4.5. 创建新存储桶类
bucket 类是一个 CRD,代表一种存储桶类别,用于定义对象 Bucket 类 (OBC) 的分层策略和数据放置。
在 OpenShift Data Foundation 中创建存储桶类。
流程
- 在 OpenShift Web 控制台中,点 Storage → OpenShift 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 → OpenShift Data Foundation。
- 单击 Bucket Class 选项卡,再搜索新的 Bucket 类。
10.4.6. 编辑存储桶类
使用以下步骤,通过 YAML 文件编辑存储桶类组件,方法是点击 Openshift Web 控制台上的 edit
按钮。
先决条件
- 管理员对 OpenShift Web 控制台的访问权限。
流程
- 在 OpenShift Web 控制台中,点 Storage → OpenShift Data Foundation。
- 单击 Bucket Class 选项卡。
- 点击您要编辑的 Bucket 类旁边的 Action Menu (⋮)。
- 点 Edit Bucket Class。
- 您将被重定向到 YAML 文件,在此文件中进行必要的更改并点 Save。
10.4.7. 为存储桶类编辑后备存储
使用以下步骤编辑现有的多云对象网关(MCG)存储桶类,以更改存储桶类中使用的底层后备存储。
先决条件
- 管理员对 OpenShift Web 控制台的访问权限。
- 存储桶类。
- 后备存储。
流程
- 在 OpenShift Web 控制台中,点 Storage → OpenShift Data Foundation。
- 单击 Bucket Class 选项卡。
点击您要编辑的 Bucket 类旁边的 Action Menu (⋮)。
- 点 Edit Bucket Class Resources。
在 Edit Bucket Class Resources 页面中,通过添加后备存储到存储桶类或从存储桶类中删除后备存储来编辑存储桶类资源。您还可以编辑使用一或两个分层和不同的放置策略创建的 bucket 类资源。
- 要将后备存储添加到 bucket 类,请选择后备存储的名称。
要从存储桶类中删除后备存储,请清除后备存储的名称。
- 点击 Save。
10.5. 管理命名空间存储桶
命名空间存储桶可让您将不同提供程序上的数据存储库连接在一起,以便您可以通过统一视图与所有数据交互。将与各个提供程序关联的对象存储桶添加到命名空间存储桶,并通过命名空间存储桶访问您的数据,以一次性查看所有对象存储桶。这可让您在读取多个其他存储提供商的同时写入您首选的存储供应商,从而显著降低迁移至新存储提供商的成本。
您可以使用 S3 API 与命名空间存储桶中的对象交互。如需更多信息,请参阅命名空间存储桶中对象的 S3 API 端点。
只有其写入目标可用且可正常运行时,才能使用命名空间存储桶。
10.5.1. 命名空间存储桶中对象的 Amazon S3 API 端点
您可以使用 Amazon Simple Storage Service(S3) API 与命名空间存储桶中的对象交互。
Red Hat OpenShift Data Foundation 4.6 之后支持以下命名空间存储桶操作:
有关这些操作及其使用方法的最新信息,请参阅 Amazon S3 API 参考文档。
10.5.2. 使用 Multicloud 对象网关 CLI 和 YAML 添加命名空间存储桶
如需有关命名空间存储桶的更多信息,请参阅管理命名空间存储桶。
根据部署的类型以及是否使用 YAML 或 Multicloud 对象网关 CLI,选择以下流程之一来添加命名空间存储桶:
10.5.2.1. 使用 YAML 添加 AWS S3 命名空间存储桶
先决条件
- 正在运行的 OpenShift Data Foundation
- 访问多云对象网关(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>
-
您必须使用 Base64 提供并编码您自己的 AWS 访问密钥 ID 和 secret 访问密钥,并使用结果代替
<AWS ACCESS KEY ID ENCODED IN BASE64>
和<AWS SECRET ACCESS KEY ENCODED IN BASE64>
。 -
使用一个唯一的名称替换
<namespacestore-secret-name>
。
-
您必须使用 Base64 提供并编码您自己的 AWS 访问密钥 ID 和 secret 访问密钥,并使用结果代替
使用 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>
替换为在第 1 步中创建的 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>
替换为单个 namespace-store 的名称,该存储将定义命名空间存储桶的读取和写入目标。
-
将
一个类型为
multi
的命名空间策略需要以下配置:apiVersion: noobaa.io/v1alpha1 kind: BucketClass metadata: labels: app: noobaa name: <my-bucket-class> namespace: openshift-storage spec: namespacePolicy: type: Multi multi: writeResource: <write-resource> readResources: - <read-resources> - <read-resources>
-
将
<my-bucket-class>
替换为唯一的存储桶类名称。 -
将
<write-resource>
替换为定义命名空间存储桶写入目标的单一命名空间存储名称。 -
将
<read-resources>
替换为定义命名空间存储桶读取目标的 namespace-store 的名称列表。
-
将
应用以下 YAML,以使用对象 Bucket Class (OBC) 资源创建 bucket,该资源使用第 2 步中定义的 bucket 类。
apiVersion: objectbucket.io/v1alpha1 kind: ObjectBucketClaim metadata: name: <resource-name> namespace: openshift-storage spec: generateBucketName: <my-bucket> storageClassName: openshift-storage.noobaa.io additionalConfig: bucketclass: <my-bucket-class>
-
将
<resource-name>
替换为您要提供给资源的名称。 -
将
<my-bucket>
替换为您要提供给存储桶的名称。 -
将
<my-bucket-class>
替换为上一步中创建的存储桶类。
-
将
当 Operator 置备 OBC 后,会在 MCG 中创建存储桶,Operator 会创建一个名称相同且位于 OBC 同一命名空间上的 Secret 和 ConfigMap。
10.5.2.2. 使用 YAML 添加 IBM COS 命名空间存储桶
先决条件
- 正在运行的 OpenShift Data Foundation 平台。
- 访问多云对象网关(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>
-
您必须使用 Base64 提供和编码您自己的 IBM COS 访问密钥 ID 和 secret 访问密钥,并使用结果代替
<IBM COS ACCESS KEY ID ENCODED IN BASE64>
和<IBM COS SECRET ACCESS KEY ENCODED IN BASE64>
。 -
使用一个唯一的名称替换
<namespacestore-secret-name>
。
-
您必须使用 Base64 提供和编码您自己的 IBM COS 访问密钥 ID 和 secret 访问密钥,并使用结果代替
使用 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>
替换为在第 1 步中创建的 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>
替换为单个 namespace-store 的名称,该存储将定义命名空间存储桶的读取和写入目标。
-
将
一个类型为
multi
的命名空间策略需要以下配置:apiVersion: noobaa.io/v1alpha1 kind: BucketClass metadata: labels: app: noobaa name: <my-bucket-class> namespace: openshift-storage spec: namespacePolicy: type: Multi multi: writeResource: <write-resource> readResources: - <read-resources> - <read-resources>
-
将
<my-bucket-class>
替换为唯一的存储桶类名称。 -
将
<write-resource>
替换为定义命名空间存储桶写入目标的单一命名空间存储名称。 -
将
<read-resources>
替换为定义命名空间存储桶读取目标的 namespace-store 的名称列表。
-
将
应用以下 YAML,以使用对象 Bucket Class (OBC) 资源创建 bucket,该资源使用第 2 步中定义的 bucket 类。
apiVersion: objectbucket.io/v1alpha1 kind: ObjectBucketClaim metadata: name: <resource-name> namespace: openshift-storage spec: generateBucketName: <my-bucket> storageClassName: openshift-storage.noobaa.io additionalConfig: bucketclass: <my-bucket-class>
-
将
<resource-name>
替换为您要提供给资源的名称。 -
将
<my-bucket>
替换为您要提供给存储桶的名称。 -
将
<my-bucket-class>
替换为上一步中创建的存储桶类。
-
将
当 Operator 置备 OBC 后,会在 MCG 中创建存储桶,Operator 会创建一个名称相同且位于 OBC 同一命名空间上的 Secret 和 ConfigMap。
10.5.2.3. 使用 Multicloud 对象网关 CLI 添加 AWS S3 命名空间存储桶
先决条件
- 正在运行的 OpenShift Data Foundation 平台。
- 访问多云对象网关(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 软件包。
根据您的架构选择正确的产品变体。
流程
创建 NamespaceStore 资源。NamespaceStore 代表底层存储,用作 MCG 命名空间存储桶中数据的读取或写入目标。在 MCG 命令行界面中运行以下命令:
noobaa namespacestore create aws-s3 <namespacestore> --access-key <AWS ACCESS KEY> --secret-key <AWS SECRET ACCESS KEY> --target-bucket <bucket-name> -n openshift-storage
-
将
<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>
替换为定义命名空间存储桶读写目标的单个 namespace-store。
-
将
运行以下命令,创建一个命名空间存储桶类,其命名空间策略为
multi
:noobaa bucketclass create namespace-bucketclass multi <my-bucket-class> --write-resource <write-resource> --read-resources <read-resources> -n openshift-storage
-
将
<resource-name>
替换为您要为其提供资源的名称。 -
将
<my-bucket-class>
替换为唯一的存储桶类名称。 -
将
<write-resource>
替换为定义命名空间存储桶写入目标的单个 namespace-store。 -
将
<read-resources>
替换为一个以逗号分开的命名空间存储列表,该存储将定义命名空间存储桶的读取目标。
-
将
运行以下命令,以使用对象 Bucket Class (OBC) 资源创建 bucket,该资源使用第 2 步中定义的 bucket 类。
noobaa obc create my-bucket-claim -n openshift-storage --app-namespace my-app --bucketclass <custom-bucket-class>
-
将
<bucket-name>
替换为您选择的存储桶名称。 -
将
<custom-bucket-class>
替换为在第 2 步中创建的 bucket 类的名称。
-
将
当 Operator 置备 OBC 后,会在 MCG 中创建存储桶,Operator 会创建一个名称相同且位于 OBC 同一命名空间上的 Secret 和 ConfigMap。
10.5.2.4. 使用 Multicloud 对象网关 CLI 添加 IBM COS 命名空间存储桶
先决条件
- 正在运行的 OpenShift Data Foundation 平台。
- 访问多云对象网关(MCG),请参阅第 2 章,使用应用程序访问多云对象网关
下载 MCG 命令行界面:
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms # yum install mcg
注意指定适当的架构,以使用订阅管理器启用存储库。
- 对于 IBM Power,使用以下命令:
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-ppc64le-rpms
- 对于 IBM Z 基础架构,使用以下命令:
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
另外,您还可以从位于 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/package的 OpenShift Data Foundation RPM 安装 MCG 软件包。
注意根据您的架构选择正确的产品变体。
流程
创建 NamespaceStore 资源。NamespaceStore 代表底层存储,用作 MCG 命名空间存储桶中数据的读取或写入目标。在 MCG 命令行界面中运行以下命令:
noobaa namespacestore create ibm-cos <namespacestore> --endpoint <IBM COS ENDPOINT> --access-key <IBM ACCESS KEY> --secret-key <IBM SECRET ACCESS KEY> --target-bucket <bucket-name> -n openshift-storage
-
将
<namespacestore>
替换为 NamespaceStore 的名称。 -
将
<IBM ACCESS KEY>
、、<IBM SECRET ACCESS KEY>
、<IBM COS ENDPOINT>
替换为 IBM 访问密钥 ID、机密访问密钥和对应于现有 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>
替换为定义命名空间存储桶读写目标的单个 namespace-store。
-
将
运行以下命令,创建一个命名空间存储桶类,其命名空间策略为
multi
:noobaa bucketclass create namespace-bucketclass multi <my-bucket-class> --write-resource <write-resource> --read-resources <read-resources> -n openshift-storage
-
将
<resource-name>
替换为您要为其提供资源的名称。 -
将
<my-bucket-class>
替换为唯一的存储桶类名称。 -
将
<write-resource>
替换为定义命名空间存储桶写入目标的单个 namespace-store。 -
将
<read-resources>
替换为一个以逗号分开的命名空间存储列表,该存储将定义命名空间存储桶的读取目标。
-
将
运行以下命令,以使用对象 Bucket Class (OBC) 资源创建 bucket,该资源使用第 2 步中定义的 bucket 类。
noobaa obc create my-bucket-claim -n openshift-storage --app-namespace my-app --bucketclass <custom-bucket-class>
-
将
<bucket-name>
替换为您选择的存储桶名称。 -
将
<custom-bucket-class>
替换为在第 2 步中创建的 bucket 类的名称。
-
将
当 Operator 置备 OBC 后,会在 MCG 中创建存储桶,Operator 会创建一个名称相同且位于 OBC 同一命名空间上的 Secret 和 ConfigMap。
10.5.3. 使用 OpenShift Container Platform 用户界面添加命名空间存储桶
随着 OpenShift Data Foundation 4.8 的发布,可以使用 OpenShift Container Platform 用户界面添加命名空间存储桶。如需有关命名空间存储桶的更多信息,请参阅管理命名空间存储桶。
先决条件
- 安装了带有 OpenShift Data Foundation operator 的 OpenShift Container Platform。
- 访问多云对象网关(MCG)。
流程
- 登录 OpenShift Web 控制台。
- 点 Storage → OpenShift Data Foundation。
点 Namespace Store 选项卡创建要在命名空间存储桶中使用的
namespacestore
资源。- 单击 Create namespace store。
- 输入命名空间存储名称。
- 选择一个供应商。
- 选择一个地区。
- 选择现有的 secret,或者点击 Swith to credentials 通过输入 secret key 和 secret access key 来创建 secret。
- 选择目标存储桶。
- 点击 Create。
- 验证命名空间存储是否处于 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 → OpenShift Data Foundation。
- 在 Status 卡中,单击 Storage System,再单击弹出窗口中的 storage 系统链接。
- 在 Object 选项卡中,点 Multicloud Object Gateway → Buckets → Namespace Buckets 选项卡。
点 Create Namespace Bucket。
- 在 Choose Name 选项卡中,指定命名空间存储桶的名称,再单击 Next。
在 Set Placement 标签页中:
- 在 Read Policy 下,选中在第 5 步中创建的每个命名空间资源应从中读取数据的复选框。
- 如果您使用的命名空间策略类型是 Multi,在 Write Policy 下指定要将数据写入的命名空间资源。
- 点 Next。
- 点击 Create。
验证
- 验证命名空间存储桶是否在 State 列中带有绿色勾号、预期的读取资源和预期的写入资源名称。
10.6. 混合和多云存储桶的镜像数据
多云对象网关 (MCG) 简化了跨云供应商和集群的数据生成过程。
先决条件
- 您必须首先添加 MCG 使用的后备存储,请参阅 第 10.4 节 “为混合或多云添加存储资源”。
然后,您创建一个 bucket 类来反映数据管理策略镜像。
流程
您可以通过三种方式设置镜像数据:
10.6.1. 使用 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.6.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.8 节 “对象 Bucket 声明”。
10.6.3. 使用用户界面将存储桶配置为镜像数据
- 在 OpenShift Web 控制台中,点 Storage → OpenShift Data Foundation。
- 在 Status 卡中,单击 Storage System,再单击弹出窗口中的 storage 系统链接。
- 在 Object 选项卡中,点 Multicloud Object Gateway 链接。
在 NooBaa 页面中,单击左侧的存储 桶 图标。您可以看到存储桶列表:
- 点击您要更新的存储桶。
点击 Edit Tier 1 Resources:
选择 Mirror 并检查您要用于这个存储桶的相关资源。在以下示例中,在 RGW 和
AWS-backingstore
中被镜像的noobaa-default-backing-store
间的数据会被镜像:- 点击 Save。
在 NooBaa UI 中创建的资源不能被 OpenShift UI 或多云对象网关(MCG)CLI 使用。
10.7. Multicloud 对象网关中的存储桶策略
OpenShift Data Foundation 支持 AWS S3 存储桶策略。bucket 策略允许您为用户授予存储桶及其对象的访问权限。
10.7.1. 关于存储桶策略
bucket 策略是一个访问策略选项,可供您向 AWS S3 存储桶和对象授予权限。bucket 策略使用基于 JSON 的访问策略语言。有关访问策略语言的更多信息,请参阅AWS 访问策略语言概述。
10.7.2. 使用存储桶策略
先决条件
- 正在运行的 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" ] } ] }
bucket 策略有许多可用元素,与访问权限有关。
有关这些元素的详细信息,以及如何使用它们控制访问权限的示例,请参阅 AWS 访问策略语言概述。
如需存储桶策略的更多示例,请参阅 AWS Bucket 策略示例。
有关创建 S3 用户的说明,请参阅 第 10.7.3 节 “在 Multicloud 对象网关中创建 AWS S3 用户”。
使用 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 策略条件。
-
将
10.7.3. 在 Multicloud 对象网关中创建 AWS S3 用户
先决条件
- 正在运行的 OpenShift Data Foundation 平台。
- 访问 Multicloud 对象网关(MCG),请参阅 第 10.2 节 “使用应用程序访问多云对象网关”
流程
- 在 OpenShift Web 控制台中,点 Storage → OpenShift Data Foundation。
- 在 Status 卡中,单击 Storage System,再单击弹出窗口中的 storage 系统链接。
- 在 Object 选项卡中,点 Multicloud Object Gateway 链接。
在 Accounts 选项卡下,单击 Create Account。
选择 S3 Access Only,提供 帐户名称,例如 john.doe@example.com。点 Next。
选择 S3 默认放置,例如 noobaa-default-backing-store。选择 Buckets Permissions。可以选择特定的存储桶或所有存储桶。点击 Create。
10.8. 对象 Bucket 声明
Object Bucket Claim 可以用来为您的工作负载请求 S3 兼容存储桶后端。
您可以通过三种方式创建对象 Bucket 声明:
对象 bucket 声明在 NooBaa 中创建一个新 bucket 和应用帐户,其具有存储桶的权限,包括新的 access key 和 secret access key。应用程序帐户仅允许访问单个存储桶,默认情况下无法创建新的存储桶。
10.8.1. 动态对象 Bucket 声明
与持久卷类似,您可以将 Object Bucket 声明(OBC)的详细信息添加到应用的 YAML 中,并获取配置映射和机密中可用的对象服务端点、访问密钥和 secret 访问密钥。可在应用程序的环境变量中动态阅读此信息。
流程
在应用程序 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 的唯一存储桶名称。
-
将
您可以在 YAML 文件中添加更多行来自动使用 OBC。以下示例是存储桶声明结果之间的映射,这是一个带有凭证数据和 secret 的配置映射。此特定作业从 NooBaa 声明 Object Bucket,它将创建一个存储桶和帐户。
apiVersion: batch/v1 kind: Job metadata: name: testjob spec: template: spec: restartPolicy: OnFailure containers: - image: <your application image> name: test env: - name: BUCKET_NAME valueFrom: configMapKeyRef: name: <obc-name> key: BUCKET_NAME - name: BUCKET_HOST valueFrom: configMapKeyRef: name: <obc-name> key: BUCKET_HOST - name: BUCKET_PORT valueFrom: configMapKeyRef: name: <obc-name> key: BUCKET_PORT - name: AWS_ACCESS_KEY_ID valueFrom: secretKeyRef: name: <obc-name> key: AWS_ACCESS_KEY_ID - name: AWS_SECRET_ACCESS_KEY valueFrom: secretKeyRef: name: <obc-name> key: AWS_SECRET_ACCESS_KEY
-
将
<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.8.2. 使用命令行界面创建对象 Bucket 声明
在使用命令行界面创建对象 Bucket 声明(OBC)时,您会获得一个配置映射和一个 Secret,其中包含应用使用对象存储服务所需的所有信息。
先决条件
下载多云对象网关(MCG)命令行界面。
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms # yum install mcg
注意指定使用订阅管理器启用存储库的适当架构。
- 对于 IBM Power,使用以下命令:
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-ppc64le-rpms
- 对于 IBM Z 基础架构,使用以下命令:
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
流程
使用命令行界面生成新 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
输出示例:
Example output: apiVersion: v1 data: AWS_ACCESS_KEY_ID: c0M0R2xVanF3ODR3bHBkVW94cmY= AWS_SECRET_ACCESS_KEY: Wi9kcFluSWxHRzlWaFlzNk1hc0xma2JXcjM1MVhqa051SlBleXpmOQ== kind: Secret metadata: creationTimestamp: "2019-10-24T13:30:07Z" finalizers: - objectbucket.io/finalizer labels: app: noobaa bucket-provisioner: openshift-storage.noobaa.io-obc noobaa-domain: openshift-storage.noobaa.io name: test21obc namespace: openshift-storage ownerReferences: - apiVersion: objectbucket.io/v1alpha1 blockOwnerDeletion: true controller: true kind: ObjectBucketClaim name: test21obc uid: 64f04cba-f662-11e9-bc3c-0295250841af resourceVersion: "40751" selfLink: /api/v1/namespaces/openshift-storage/secrets/test21obc uid: 65117c1c-f662-11e9-9094-0a5305de57bb type: Opaque
该机密为您提供了 S3 访问凭据。
运行以下命令来查看配置映射:
# oc get -n openshift-storage cm test21obc -o yaml
输出示例:
apiVersion: v1 data: BUCKET_HOST: 10.0.171.35 BUCKET_NAME: test21obc-933348a6-e267-4f82-82f1-e59bf4fe3bb4 BUCKET_PORT: "31242" BUCKET_REGION: "" BUCKET_SUBREGION: "" kind: ConfigMap metadata: creationTimestamp: "2019-10-24T13:30:07Z" finalizers: - objectbucket.io/finalizer labels: app: noobaa bucket-provisioner: openshift-storage.noobaa.io-obc noobaa-domain: openshift-storage.noobaa.io name: test21obc namespace: openshift-storage ownerReferences: - apiVersion: objectbucket.io/v1alpha1 blockOwnerDeletion: true controller: true kind: ObjectBucketClaim name: test21obc uid: 64f04cba-f662-11e9-bc3c-0295250841af resourceVersion: "40752" selfLink: /api/v1/namespaces/openshift-storage/configmaps/test21obc uid: 651c6501-f662-11e9-9094-0a5305de57bb
配置映射包含应用的 S3 端点信息。
10.8.3. 使用 OpenShift Web 控制台创建对象 Bucket 声明
您可以使用 OpenShift Web 控制台创建对象 BucketClaim (OBC)。
先决条件
- 对 OpenShift Web 控制台的管理访问权限.
- 为了让您的应用程序与 OBC 通信,您需要使用 configmap 和 secret。有关此信息的详情请参考 第 10.8.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.8.4. 将对象 Bucket 声明附加到部署
创建后,对象 Bucket 声明 (OBC) 可以附加到特定的部署。
先决条件
- 对 OpenShift Web 控制台的管理访问权限.
流程
- 在左侧导航栏中,点击 Storage → Object Bucket Claims。
单击您创建的 OBC 旁边的操作菜单 (⋮)。
从下拉菜单中选择 Attach to Deployment。
从 Deployment Name 列表中选择所需的部署,然后单击 Attach。
10.8.5. 使用 OpenShift Web 控制台查看对象存储桶
您可以使用 OpenShift Web 控制台查看为对象 Bucket 声明 (OBC) 创建的对象存储桶详情。
先决条件
- 对 OpenShift Web 控制台的管理访问权限.
流程
- 登录 OpenShift Web 控制台。
在左侧导航栏中,点击 Storage → Object Buckets。
或者,您还可以导航到特定 OBC 的详细信息页面,再单击 Resource 链接来查看该 OBC 的对象存储桶。
- 选择您要查看详细信息的对象 bucket。您可以导航到 Object Bucket Details 页面。
10.8.6. 删除对象 Bucket 声明
先决条件
- 对 OpenShift Web 控制台的管理访问权限.
流程
- 在左侧导航栏中,点击 Storage → Object Bucket Claims。
点击您要删除的 Object Bucket Claim(OBC ) 旁边的 Action 菜单 (⋮)。
- 选择 Delete Object Bucket Claim。
- 点击 Delete。
10.9. 对象存储桶的缓存策略
缓存存储桶是带有 hub 目标和缓存目标的命名空间存储桶。hub 目标是一个 S3 兼容的大型对象存储桶。缓存存储桶是本地 Multicloud 对象网关存储桶。您可以创建一个缓存存储桶来缓存 AWS 存储桶或 IBM COS 存储桶。
缓存存储桶是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
如需更多信息,请参阅技术预览功能支持范围。
10.9.1. 创建 AWS 缓存存储桶
先决条件
下载多云对象网关(MCG)命令行界面。
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms # yum install mcg
注意指定使用订阅管理器启用存储库的适当架构。如果是 IBM Z 基础架构,请使用以下命令:
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
另外,您还可以从位于 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/package的 OpenShift Data Foundation RPM 安装 MCG 软件包。
注意根据您的架构选择正确的产品变体。
流程
创建 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.9.2. 创建 IBM COS 缓存存储桶
先决条件
下载多云对象网关(MCG)命令行界面。
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms # yum install mcg
注意指定使用订阅管理器启用存储库的适当架构。
- 对于 IBM Power,使用以下命令:
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-ppc64le-rpms
- 对于 IBM Z 基础架构,使用以下命令:
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
另外,您还可以从位于 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/package的 OpenShift Data Foundation RPM 安装 MCG 软件包。
注意根据您的架构选择正确的产品变体。
流程
创建 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.10. 通过添加端点扩展多云对象网关性能
多云对象网关的性能可能因环境而异。在某些情况下,特定的应用需要更快的性能,这可以通过扩展 S3 端点来轻松解决。
Multicloud Object Gateway 资源池是一组 NooBaa 守护进程容器,默认启用两种类型的服务:
- 存储服务
- S3 端点服务
10.10.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.11. 自动扩展 MultiCloud Object Gateway 端点
当 MCG S3 服务的负载增加或减少时,MultiCloud Object Gateway(MCG)端点的数量会自动缩放。OpenShift 数据基础集群使用一个活跃的 MCG 端点进行部署。每个 MCG 端点 pod 都默认配置有 1 个 CPU 和 2Gi 内存请求,其限值与请求匹配。当端点上的 CPU 负载在固定时间段内超过 80% 用量阈值时,部署第二个端点会降低第一个端点的负载。当两个端点的平均 CPU 负载在固定时间段内低于 80% 阈值时,会删除其中一个端点。此功能提高了 MCG 的性能和可服务性。
第 11 章 管理持久性卷声明
OpenShift Data Foundation 支持的 PVC 不支持扩展 PVC。
11.1. 配置应用程序 pod 以使用 OpenShift Data Foundation
按照本节中的说明,将 OpenShift Data Foundation 配置为应用 pod 的存储。
先决条件
- 具有 OpenShift Web 控制台的管理访问权限。
-
OpenShift Data Foundation Operator 在
openshift-storage
命名空间上安装并运行。在 OpenShift Web 控制台中,点 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:
部分下,添加volumes:
部分,将新 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:
部分下,添加volumes:
部分,将新 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 → OpenShift 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 中的持久性卷。虽然它们都可以由管理员静态置备,但有些类型的存储是使用内置供应商和插件 API 动态创建的。
11.4.2. OpenShift Data Foundation 中的动态置备
Red Hat OpenShift Data Foundation 是软件定义的存储,针对容器环境优化。它在 OpenShift Container Platform 上作为操作器运行,为容器提供高度集成和简化的持久性存储管理。
OpenShift Data Foundation 支持各种存储类型,包括:
- 数据库的块存储
- 共享文件存储,用于持续集成、消息传递和数据聚合
- 归档、备份和介质存储的对象存储
第 4 版使用 Red Hat Ceph Storage 来提供支持持久卷的文件、块和对象存储,以及 Rook.io 来管理和编排持久卷和声明的调配。NooBaa 提供对象存储,其多云网关允许在多个云环境中联合对象(作为技术预览使用)。
在 OpenShift Data Foundation 4 中,RADOS 块设备 (RBD) 和 Ceph 文件系统 (CephFS) 的 Red Hat Ceph Storage Container Storage Interface (CSI) 驱动程序处理动态置备请求。当 PVC 请求动态进入时,CSI 驱动程序有以下选项:
-
创建一个具有 ReadWriteOnce (RWO) 和 ReadWriteMany (RWX) 访问权限的 PVC,它基于卷模式
块
的 Ceph RBD -
创建一个具有 ReadWriteOnce (RWO) 访问权限的 PVC,它基于卷模式
Filesystem
的 Ceph RBD -
为卷模式
Filesystem
创建基于 CephFS 的 ReadWriteOnce (RWO) 和 ReadWriteMany (RWX) 访问的 PVC
判断要使用的驱动程序(RBD 或 CephFS)取决于 storageclass.yaml
文件中的条目。
11.4.3. 可用的动态部署插件
OpenShift Container Platform 提供了以下置备程序插件,用于使用集群配置的供应商 API 创建新存储资源的动态部署:
存储类型 | provisioner 插件名称 | 备注 |
---|---|---|
OpenStack Cinder |
| |
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. 替换 Google Cloud installer 置备的基础架构上的操作节点
使用这个流程替换 Google Cloud 安装程序置备的基础架构 (IPI) 上的操作节点。
流程
- 登录 OpenShift Web 控制台并点击 Compute → Nodes。
- 确定需要替换的节点。记录其 Machine Name。
使用以下命令将节点标记为不可调度:
$ oc adm cordon <node_name>
使用以下命令排空节点:
$ oc adm drain <node_name> --force --delete-emptydir-data=true --ignore-daemonsets
重要此活动可能需要至少 5 到 10 分钟或更长时间。这一期间内生成的 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=""
验证步骤
执行以下命令并验证输出中是否存在新节点:
$ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1
点 Workloads → Pods,确认新节点上的以下 pod 处于 Running 状态 :
-
csi-cephfsplugin-*
-
csi-rbdplugin-*
-
- 验证所有其他必需的 OpenShift 数据基础容器集是否都处于 Running 状态。
验证新 OSD pod 是否在替换节点上运行。
$ oc get pods -o wide -n openshift-storage| egrep -i new-node-name | egrep osd
可选:如果在集群中启用了集群范围的加密,请验证新 OSD 设备是否已加密。
对于上一步中标识的每个新节点,请执行以下操作:
创建调试 pod,并为所选主机打开 chroot 环境。
$ oc debug node/<node name> $ chroot /host
运行 "lsblk" 并检查
ocs-deviceset
名旁边的 "crypt" 关键字。$ lsblk
- 如果验证步骤失败,请联系红帽支持。
14.2. 在 Google Cloud installer 置备的基础架构中替换失败的节点
执行此流程替换在 OpenShift Data Foundation 的 Google Cloud 安装程序置备的基础架构 (IPI) 上无法正常工作的故障节点。
流程
- 登录 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 错误是临时的,在新节点标上并正常运行时自动解决。
- 点 Compute → Nodes,确认新节点是否处于 Ready 状态。
使用以下任一方法之一将 OpenShift Data Foundation 标签应用到新节点:
- 使用 Web 用户界面
- 对于新节点,点击 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=""
- [可选]:如果没有自动删除失败的 Google Cloud 实例,请从 Google Cloud 控制台终止实例。
验证步骤
执行以下命令并验证输出中是否存在新节点:
$ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1
点 Workloads → Pods,确认新节点上的以下 pod 处于 Running 状态 :
-
csi-cephfsplugin-*
-
csi-rbdplugin-*
-
- 验证所有其他必需的 OpenShift 数据基础容器集是否都处于 Running 状态。
验证新 OSD pod 是否在替换节点上运行。
$ oc get pods -o wide -n openshift-storage| egrep -i new-node-name | egrep osd
可选:如果在集群中启用了集群范围的加密,请验证新 OSD 设备是否已加密。
对于上一步中标识的每个新节点,请执行以下操作:
创建调试 pod,并为所选主机打开 chroot 环境。
$ oc debug node/<node name> $ chroot /host
运行 "lsblk" 并检查
ocs-deviceset
名旁边的 "crypt" 关键字。$ lsblk
- 如果验证步骤失败,请联系红帽支持。
第 15 章 替换存储设备
15.1. 在 Google Cloud installer 置备的基础架构中替换操作或失败的存储设备
当您需要替换 Google Cloud 安装程序置备的基础架构上动态创建的存储集群中的设备时,必须替换存储节点。有关如何替换节点的详情,请参考:
第 16 章 升级到 OpenShift Data Foundation
16.1. OpenShift Data Foundation 更新过程概述
OpenShift Container Storage 基于开源 Ceph 技术,自引入以来,在容器化、混合云环境中扩展了其范围和基本角色。它补充了除其他数据相关的硬件和软件外,还使其可在混合云环境中快速连接、可访问和扩展的现有存储。为了更好地反映这些基础和基础架构的独特之处,OpenShift Container Storage 现在是 OpenShift Data Foundation。
您只能通过从 OpenShift Container Platform OperatorHub 安装 OpenShift Data Foundation operator,从 OpenShift Container Storage 4.8 执行 OpenShift Data Foundation 版本 4.9 的升级流程。
在以后的版本中,您可以通过启用自动更新(如果在 Operator 安装过程中未这样做)或执行手动更新,在次版本间(如 4.9 和 4.x 之间)或在更新间(如 4.9.0 和 4.9.1 之间)升级 Red Hat OpenShift Data Foundation。
您还需要为内部和外部模式部署按照以下顺序升级 Red Hat OpenShift Data Foundation 的不同部分:
- 根据 OpenShift Container Platform 更新集群文档更新 OpenShift Container Platform。
更新 Red Hat OpenShift Data Foundation.
- 要准备断开连接的环境以获取更新,请参阅 Operator 指南,在受限网络中使用 Operator Lifecycle Manager,以便在使用时能够更新 Red Hat OpenShift Data Foundation 和 Local Storage Operator。
- 通过在 OpenShift Container Platform Web 控制台中从 OperatorHub 安装 Red Hat OpenShift Data Foundation operator,将 Red Hat OpenShift Container Storage operator 版本 4.8 更新至版本 4.9。请参阅 Red Hat OpenShift Container Storage 4.8 更新至 Red Hat OpenShift Data Foundation 4.9。
- 将 Red Hat OpenShift Data Foundation 从 4.9.x 更新到 4.9.y。请参阅 更新 Red Hat OpenShift Data Foundation 4.9.x 到 4.9.y。
- 若要更新外部模式部署,还必须执行 更新 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。
- 只有在 Local Storage Operator 版本与 Red Hat OpenShift Container Platform 版本匹配时,才会完全支持 Local Storage Operator。
- 灵活的扩展功能仅在 Red Hat OpenShift Data Foundation 版本 4.7 及更新的版本中提供。存储集群从以前的版本升级到版本 4.7 或更高版本不支持灵活的扩展。如需更多信息,请参阅 4.7 发行注记的新功能部分中的 OpenShift Container Storage 集群灵活性扩展。
16.2. 将 Red Hat OpenShift Container Storage 4.8 更新至 Red Hat OpenShift Data Foundation 4.9
本章可帮助您在所有 Red Hat OpenShift Data Foundation 部署(Internal、Internal-Attached 和 External)中升级 z-stream 版本。所有部署的升级过程都保持不变。唯一的区别在在升级后的结果。
- 对于内部和内部附加的部署,升级 OpenShift Container Storage 升级所有 OpenShift Container Storage 服务,包括后端 Ceph 存储集群。
对于外部模式部署,升级 OpenShift Container Storage 只会升级 OpenShift Container Storage 服务,而后端 Ceph 存储集群没有变化,需要单独升级。
我们建议升级 RHCS 和 OpenShift Container Storage,以获取新的功能支持、安全修复和其他程序错误修复。由于我们对 RHCS 升级没有强烈依赖,因此您可以先升级 OpenShift Data Foundation operator,然后再升级 RHCS 升级,或反之亦然。请参阅 解决方案 以了解更多关于 Red Hat Ceph Storage 版本的信息。
不支持直接从 4.8 以上版本升级到 4.9。
先决条件
- 确保 OpenShift Container Platform 集群已更新至版本 4.9.X 的最新稳定版本,请参阅 更新集群。
确保 OpenShift Container Storage 集群处于健康状态,数据具有弹性。
- 进入 Storage → Overview 并选中 Block and File 和 Object 选项卡以检查状态卡上的绿色勾号。绿色勾号表示 存储集群、对象服务和数据弹性都是健康的。
确保所有 OpenShift Container Storage Pod(包括 Operator Pod)在
openshift-storage
命名空间中处于 Running 状态。要查看 pod 的状态,在 OpenShift Web 控制台中点 Workloads → Pods。从 Project 下拉列表中选择
openshift-storage
。注意如果禁用 Show default projects 选项,请使用切换按钮列出所有默认项目。
- 确保您有足够的时间完成 OpenShift 数据基础更新过程,因为更新时间因集群中运行的 OSD 数量而异。
流程
- 在 OpenShift Web 控制台中,导航到 OperatorHub。
-
使用 Filter by keyword 框搜索
OpenShift Data Foundation
,然后单击 OpenShift Data Foundation 标题。 - 点 Install。
在 install Operator 页面中,点 Install。等待 Operator 安装完成。
注意我们建议使用所有默认设置。更改可能会导致意外行为。仅在您意识到其结果时进行修改。
验证步骤
验证页面显示 Succeeded 消息以及 Create StorageSystem 选项。
注意对于升级的集群,因为存储系统是自动创建的,所以不会再次创建它。
- 在通知弹出窗口中,单击 Refresh Web 控制台 链接,以反映 OpenShift 控制台中的 OpenShift Data Foundation 更改。
验证 OpenShift Web 控制台中容器集的状态。
- 点 Workloads → Pods。
从 Project 下拉列表中选择
openshift-storage
。注意如果禁用 Show default projects 选项,请使用切换按钮列出所有默认项目。
等待
openshift-storage
命名空间中的所有容器集重启并达到Running
状态。
验证 OpenShift Data Foundation 集群是否正常运行并且数据具有弹性。
- 导航到 Storage → OpenShift Data foundation → Storage Systems 选项卡,然后点击存储系统名称。
- 检查 Block and File 和 Object 选项卡,以查找状态卡上的绿色勾号。绿色勾号表示存储集群、对象服务和数据弹性都是健康的。
如果在安装 OpenShift Data Foundation Operator 后,不能自动启用 console plugin 选项,则需要启用它。
有关如何启用 console 插件的更多信息,请参阅启用 Red Hat OpenShift Data Foundation 控制台插件。
- 在更新外部模式部署后,还必须更新外部 secret。具体步骤,请参阅 更新 OpenShift 数据基础外部 secret。
其它资源
如果您在更新 OpenShift Data Foundation 时遇到任何问题,请参阅故障排除指南中的常见的进行故障排除所需的日志部分。
16.3. 把 Red Hat OpenShift Data Foundation 从 4.9.x 更新到 4.9.y。
本章可帮助您在所有 Red Hat OpenShift Data Foundation 部署(Internal、Internal-Attached 和 External)中升级 z-stream 版本。所有部署的升级过程都保持不变。唯一的区别在在升级后的结果。
- 对于内部和内部附加的部署,升级 OpenShift Container Storage 升级所有 OpenShift Container Storage 服务,包括后端 Ceph 存储集群。
对于外部模式部署,升级 OpenShift Container Storage 只会升级 OpenShift Container Storage 服务,而后端 Ceph 存储集群没有变化,需要单独升级。
我们建议升级 RHCS 和 OpenShift Container Storage,以获取新的功能支持、安全修复和其他程序错误修复。由于我们对 RHCS 升级没有强烈依赖,因此您可以先升级 OpenShift Data Foundation operator,然后再升级 RHCS 升级,或反之亦然。请参阅 解决方案 以了解更多关于 Red Hat Ceph Storage 版本的信息。
当新的 z-stream 发行版本可用时,升级过程会在更新策略被设置为 Automatic
时自动触发。如果更新策略被设置为 Manual
,则使用以下步骤。
先决条件
- 确保 OpenShift Container Platform 集群已更新至版本 4.9.X 的最新稳定版本,请参阅 更新集群。
确保 OpenShift Data Foundation 集群正常运行,数据具有弹性。
- 导航到 Storage → OpenShift 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 → OpenShift Data Foundation → Storage Systems 选项卡,然后点击存储系统名称。
- 检查 Overview - Block 和 File 和 Object 选项卡的状态卡上绿色勾号。绿色勾号表示存储集群、对象服务和数据弹性是健康的
如果在安装 OpenShift Data Foundation Operator 后,不能自动启用 console plugin 选项,则需要启用它。
有关如何启用 console 插件的更多信息,请参阅启用 Red Hat OpenShift Data Foundation 控制台插件。
- 如果验证步骤失败,请联系红帽支持。
16.4. 更改更新批准策略
为确保在同一频道中有新更新时自动更新存储系统,我们建议把更新批准策略设置为 Automatic
。将更新批准策略更改为 Manual
需要在每次升级时手动批准。
流程
- 导航到 Operators → Installed Operators。
从 Project 下拉列表中选择
openshift-storage
。注意如果禁用 Show default projects 选项,请使用切换按钮列出所有默认项目。
- 单击 OpenShift Data Foundation operator 名称
- 转至 订阅 选项卡。
- 单击 铅笔 图标以更改 更新批准。
- 选择更新批准策略并点 Save。
验证步骤
- 验证 Update 批准显示了它下面新选择的批准策略。