了解 OpenShift 数据基金会
虚拟私有云 经典基础架构 Satellite
OpenShift Data Foundation 是一种高可用性存储解决方案，可用于管理容器化应用程序的持久存储器。
- 什么是 OpenShift Data Foundation?
- OpenShift Data Foundation 是一种高可用性存储解决方案，由多种开源运算符和技术组成，例如 头孢，努巴，和 Rook。 这些运算符允许您为容器化工作负载配置和管理文件、块和对象存储Red Hat® OpenShift® on IBM Cloud®簇。 与其他存储解决方案不同，您可能需要为每种类型的存储配置单独的驱动程序和操作程序，ODF 是一个统一的解决方案，能够根据您的存储需求进行调整或扩展。 您还可以在任何 OCP 集群上部署 ODF。
- OpenShift Data Foundation 如何工作?
- ODF 使用这些设备来创建虚拟化的存储层，在该存储层中复制应用程序数据以实现高可用性。 由于 ODF 将底层存储器抽象化，因此您可以使用 ODF 从同一底层原始块存储器创建文件，块或对象存储器声明。
- ODF 使用 3 倍数的存储卷，并在这些卷中复制应用程序数据。 用于 ODF 的底层存储卷取决于集群类型。
- 对于使用虚拟机的 VPC 群集，存储卷是 Block Storage for VPC 存储卷。
- 对于使用裸机工作者的经典或 VPC 群集，存储卷是裸机工作者节点上的本地磁盘。
- 对于 Satellite集群，存储卷可以是工作节点上的本地磁盘，也可以使用兼容的块存储驱动程序动态配置磁盘。
- 我可以在仅限私人的VPC集群上安装 OpenShift Data Foundation吗？
- 是的，您可以将ODF安装在仅限私有的VPC集群上，集群版本为
4.16.23_1546_openshift，适用于 CoreOS 工作者，4.16.21_1544_openshift适用于RHEL工作者。 - 能否在 Satellite 集群中安装 OpenShift Data Foundation 附加组件?
- 编号 集群附加组件仅可用于经典和 VPC 集群。
- 如何在 Satellite上安装 OpenShift Data Foundation?
- 您可以使用其中一个 Satellite 存储模板在 Satellite 上安装 ODF。 有关更多信息，请参阅 Satellite 存储文档。
odf-local: 当您具有可供工作程序节点使用的本地存储器时，请选择此模板。 如果存储卷在运行lsblk时可视，那么可以在部署 ODF 时使用这些磁盘 (如果它们是原始磁盘且未格式化)。odf-remote: 如果在集群中安装了 CSI 驱动程序，请选择此模板。 例如，azuredisk-csi-driver驱动程序。 部署 ODF 时，可以使用 CSI 驱动程序动态供应存储卷。
有关功能和优势的完整概述，请参阅 OpenShift Data Foundation。
体系结构概述
查看下图和表以了解有关 OpenShift Data Foundation 的更多信息。
{: caption="ODF" caption-side="bottom"}
| 编号 | ODF 组件 | 描述 |
|---|---|---|
| 1 | OpenShift Data Foundation 存储类 | 部署 ODF 时，ODF 操作程序会在集群中创建“文件”，“块”和“对象”存储类。 在 PVC 中引用这些存储类，并为应用程序声明存储器。 |
| 2 | OSD Block Storage | 这些设备在集群中提供应用程序存储器。 每个 OSD 都是原始块存储设备，可以是工作程序节点上的本地磁盘，也可以在部署 ODF 时动态供应。 在 VPC 集群中，通过使用 Block Storage for VPC 驱动程序动态供应 OSD 块存储设备。 在 Satellite 集群中，您可以使用工作程序节点上的本地卷，也可以使用支持动态供应的块存储驱动程序来动态供应块存储设备。 在经典集群中，OSD 块设备是工作程序节点上的本地磁盘。 部署 ODF 时，每个设备都由
OSD pod 安装。 可供应用程序使用的总存储量等于 osdSize 乘以 numOfOsd。 |
| 3 | Object Storage 守护程序 (OSD) pod | OSD pod 管理存储设备之间的数据放置和复制。 |
| 4 | 监视器 (Mon) Pod | Monitor pod 保留 OpenShift Data Foundation 存储集群的映射，并监视存储集群运行状况。 |
| 5 | 监视器 (Mon) 块存储设备 | 监视器存储设备是监视器 pod 的底层存储设备。 每个监视设备都是原始块存储设备，可以是工作程序节点上的本地磁盘，也可以在部署 ODF 时动态供应。 每个设备都向监视器 pod 提供存储器。 |
Multicloud Object Gateway 概述
Multicloud Object Gateway 由开放式源代码工具 NooBaa 组成，并且是 OpenShift Data Foundation 的组件。 通过 Multicloud Object Gateway，您可以跨云提供者管理对象和存储区。
| 编号 | Multicloud Object Gateway 组件 | 描述 |
|---|---|---|
| 1 | 后备存储器 | 支持存储是兼容 s3 的对象存储区。 在 Multicloud Object Gateway 中，支持商店可以位于任何云环境中，而不考虑提供者。 您可以将多个支持商店连接到 Multicloud Object Gateway。 部署 ODF 时，缺省支持存储将使用为 ODF 存储集群指定的原始块存储设备。 但是，您可以选择将 IBM Cloud Object Storage 设置为缺省支持存储。 |
| 2 | 存储区类 | 存储区类由一个或多个支持存储 (存储区) 和布置策略组成。 您可以配置支持商店和放置策略，以跨位置和云来管理对象。 |
| 3 | 存储类 | Multicloud Object Gateway 中的存储类与定义存储资源参数的任何其他 Kubernetes 存储类类似。 但是，在 Multicloud Object Gateway 中，创建存储类时，指定要使用的存储区类。 通过从存储区类创建存储类，可以使 Multicloud Object Gateway 资源在名称空间中可用。 |
| 4 | 对象存储区声明 (OBC) | 对象存储区声明 (OBC) 类似于 Kubernetes 持久卷声明 (PVC)，开发者或存储管理员可以创建 OBC 来声明存储资源。 创建 OBC 时，指定要使用的存储类，并 (可选) 为动态创建的对象存储区提供名称。 |
| 5 | 私钥 | 创建对象存储区声明时，还会在集群中创建 Kubernetes 私钥。 |
| 6 | ConfigMap | 创建对象存储区声明时，还会在集群中创建 ConfigMap。 |
| 7 | 对象存储区 | 对象存储区是在您创建对象存储区声明时动态供应的对象存储区。 对象存储区将一个或多个支持存储库抽象为单个资源。 |
| 8 | s3 应用程序 | 使用对象存储器的应用程序。 |
| 9 | 私钥引用 | 私钥引用是对集群中 Kubernetes 私钥的引用。 创建对象存储区声明时，NooBaa 将创建相应的私钥和配置映射。 然后，您可以在应用程序中引用私钥和配置映射，而无需在应用程序中直接包含凭证。 |
| 10 | ConfigMap 引用 | 配置映射引用是对集群中 Kubernetes 配置映射的引用。 创建对象存储区声明时，NooBaa 会动态创建相应的私钥和配置映射。 您可以在应用程序中引用私钥和配置映射，而无需在应用程序中包含这些凭证。 |
| 11 | 名称空间资源 | 名称空间资源是兼容 s3 的存储区。 将名称空间资源 (存储区) 添加到 Multicloud Object Gateway 后，可以通过创建可用于从一个或多个名称空间资源进行读写的名称空间存储区来引用这些存储区。 |
| 12 个月 | 名称空间存储区 | 名称空间存储区将抽取 NooBaa 名称空间中的一个或多个名称空间资源。 创建名称空间存储区时，可以指定对 Multicloud Object Gateway 中配置的名称空间资源的读或写策略。 例如，您可以从不同云提供者中的两个存储区中读取数据，并在另一个单独的云环境中写入第三个存储区。 |
| 13 | 名称空间存储区访问密钥 | 访问密钥用于访问名称空间存储区。 名称空间存储区可以包含来自不同云提供者或内部部署存储区的多个名称空间资源。 在 s3 应用程序中使用名称空间存储区访问密钥和密钥来配置对名称空间存储区的访问权，然后定义对您配置的名称空间资源的读写策略。 |
| 14 | 名称空间存储区密钥 | 密钥用于访问名称空间存储区。 名称空间存储区可以包含来自不同云提供者或内部部署存储区的多个名称空间资源。 在 s3 应用程序中使用名称空间存储区访问密钥和密钥来配置对名称空间存储区的访问权，然后定义对您配置的名称空间资源的读写策略。 |
| 15 | 放置策略 | 创建存储区类时，必须指定布置策略。 布置策略定义如何将数据写入支持商店。 镜像 布置策略将对存储区类中的支持存储区中的对象进行镜像，而 分布 布置策略将对存储区类中的支持存储区中的对象进行分布。 |
功能部件支持 (按计费类型)
| 功能支持 | Essentials | 高级 |
|---|---|---|
| 块存储器 | 是 | 是 |
| 文件存储器 | 是 | 是 |
| 对象存储器 | 是 | 是 |
| Node 和磁盘弹性 | 是 | 是 |
| 基于操作程序的自动化 | 是 | 是 |
| 压缩 | 是 | 是 |
| 本地快照和克隆 | 是 | 是 |
| 基本集群范围的加密 | 是 | 是 |
| 使用 KMS 进行高级加密 | 否 | 是 |
| 具有复制功能的区域灾难恢复 | 否 | 是 |
| 延伸集群-高速高可用性和灾难恢复 | 否 | 是 |
| 多集群-高速高可用性和灾难恢复 | 否 | 是 |
最佳实践
在安装和管理 ODF 时，请查看以下部分以了解最佳实践。
计划
- 规划工作程序节点分发
- 要确保高可用性，请跨故障域分布 ODF 集群。 此分布有助于最大程度地降低节点故障的影响，并保持集群的整体稳定性。
- 满足最低工作程序节点规范
- 使用 ODF 的工作程序节点应该具有 16 个 vCPUs 和 64GB RAM 或更高版本。 对于 IBM 经典集群，建议的类型模板为
mb4c.32x384.3.8tb.ssd或更高版本。 - 保留备用主机以实现高可用性
- 为确保高可用性并尽量减少主机故障时的停机时间，建议始终保持一台备用主机。
- 满足每个节点建议的存储设备计数
- 计划每个节点少于 9 个存储设备。 这有助于防止潜在的瓶颈，提高数据访问和检索的效率。
- 使用建议的存储设备大小和计数
- 部署本地存储器时，请使用 4 TiB 或更小的磁盘大小。 确保集群中所有存储节点上的所有磁盘都具有相同的大小和类型，以便最佳地使用存储器，这一点很重要。 使用至少512Gi 的 OSD。
- 使用缺省复制因子和存储节点配置向上扩展
- 在 OpenShift Data Foundation (ODF) 中，缺省情况下，复制因子设置为 3。 添加容量时，计划以 3 的倍数添加存储节点。
- 根据您的需求选择正确的设置: 远程存储与本地存储
- 如果您的存储器需求较低或正在使用虚拟服务器实例，那么远程存储器可能是一个方便且经济有效的选项。 不过，如果您有大量存储需求，使用本地存储的裸机集群或低网络延迟的高性能存储会更合适。
- 使用自动发现功能简化部署
- 在经典群集或具有本地存储的环境中，利用自动发现功能可自动识别和配置群集中用于 ODF 的可用存储磁盘。 此选项不需要手动选择磁盘。 除非 ODF 供应有特定的磁盘需求，否则使用自动发现功能可简化部署过程并减少发生配置错误的可能性。
- 将 metro 存储类用于远程存储器上的 ODF 安装
- 执行使用远程存储器的 ODF 安装时，请确保使用
VolumeBindingMode为WaitForFirstConsumer的存储类，该存储类会延迟 Block Storage 的创建，直到使用此存储器的第一个 pod 准备就绪可调度为止。 - 调整部署大小
- 要获取存储需求的详细分析，请使用 Sizing Tool 来确定所需的存储容量。 您还可以使用官方 Red Hat 缩放大小工具
- 设置定期备份
- 定期备份 ODF 集群对于确保数据保护和在灾难发生时促进数据恢复至关重要。 如果没有定期备份，从灾难性事件中恢复数据将变得更具挑战性，并可能导致永久数据丢失。
部署
- 计划使用专用存储节点
- 在工作负载繁重的场景中，请使用 ODF 的专用存储节点。 通过分离存储节点的操作，您可以为存储基础结构实现更好的性能和可伸缩性。
- 设置 Red Hat 控制台的常规监视
- Red Hat 控制台可提供有关 ODF 环境健康状况和性能的宝贵信息。 建议定期监视控制台以随时了解任何潜在问题。 只要检测到 ODF 存在问题，控制台就会触发警报，从而使您能够采取主动措施。
- 及时处理容量警告
- 发出容量警告时，必须及时解决这些问题。 忽略或延迟对这些警告执行的操作可能会导致存储容量约束和工作负载的潜在中断。 将容量警告视为评估存储需求的机会，并采取适当措施来缓解任何潜在问题。
容量扩展
- 了解容量扩展选项
- 有两个选项可用于 ODF 中的容量扩展。 第一个选项涉及通过在集群中的现有节点上添加更多 OSD (Object Storage Daemons) 来增加容量。 这允许利用可用资源来扩展存储容量。 第二个选项是通过向集群添加新节点来扩展容量。 一旦 OSD 数量增加，将在新添加的节点上自动供应 OSD。
更新
- 执行运行状况检查以替换节点
- 如果 ODF 未处于正常状态，请避免更换存储节点。 在继续进行节点更换之前，请始终验证 ODF 的运行状态。 请先尝试解决任何问题，然后再更换运行不正常的节点。
- 使您的环境保持最新
- 将集群版本更新为缺省版本或最新版本可用。 与集群版本保持同步可确保您可以利用最新功能并保持与环境中其他组件的兼容性。
- 在集群升级后执行 ODF 更新
- 始终先升级集群主节点和工作程序节点，然后再进行 ODF 升级。 完成集群升级后，还必须更新 ODF。 虽然 ODF 同时支持当前集群版本 (n) 和下一个集群版本 (n+1)，但请保持 ODF 版本与集群版本相同。 此对齐可确保最佳兼容性。
- 按顺序升级存储节点
- 升级存储节点时，最佳实践是逐个执行升级。 此顺序方法允许您在每个节点升级后验证 ODF 的状态，并确保存储基础结构在整个过程中保持正常运行。 通过单独升级节点，您可以密切监视每次升级对 ODF 的影响，并快速识别和解决可能出现的任何问题。
恢复
- 替换运行状况不佳的主机
- 如果发生本地灾难，建议用健康的集群主机替换不健康的集群主机。
- 遵循文档以恢复 OSD
- 当 OSD (Object Storage 守护程序) 在 OpenShift Data Foundation (ODF) 中关闭时，请务必遵循建议的恢复步骤。 IBM Cloud Platform 中提供的文档提供了有关如何在此类情况下恢复 OSD 的详细指示信息。
卸载和除去
- 删除 pod 和持久卷 (PV)
- 删除使用 ODF 存储类的资源时，必须遵循建议的程序。 在继续删除其他资源之前，请始终删除使用 OF 存储类创建的关联 pod 和 PV。
- 遵循正确的清除顺序
- 在集群中停用或除去 ODF 时，请确保在清除资源时遵循文档。 首先删除负责管理 ODF 的
ocscluster资源。 除去ocscluster资源后，继续从 IBM 控制台中除去 ODF 附加组件。 遵循此顺序可确保从集群中顺利地正确除去 ODF，从而防止任何潜在问题或冲突。
故障诊断
- 查看容量警报和阈值
- 当集群存储容量达到特定阈值时，ODF 会生成容量警报。 这些阈值设置为总容量的 75% (近满) 和 85% (满)。 这些警报指示存储容量正在接近其限制，需要注意。
- 查看常见问题
- 使用 OpenShift Data Foundation (ODF) 迂到问题时，请参阅提供有关常见问题故障诊断指导的可用运行手册，这很有用。 这些运行手册包含 ODF 的已知问题及其相应解决方案的综合列表。
部署 OpenShift Data Foundation
查看基础架构提供者的部署选项。
- 虚拟专用云 (VPC) 集群
- 您可以使用 Block Storage for VPC 进行动态配置，或在裸机工作者上使用本地磁盘来部署 ODF。 有关更多信息，请参阅 在 VPC 集群上部署 OpenShift Data Foundation。
- Satellite 集群
- 如果要将 ODF 部署到 Satellite 集群，那么可以使用 Satellite 存储模板。 有关更多信息，请参阅以下链接。
- 为远程动态供应的磁盘部署 OpenShift Data Foundation 模板。
- 为本地磁盘部署 OpenShift Data Foundation 模板。
- 经典集群
- 您可以使用裸机工作程序节点上的本地磁盘来部署 ODF。 有关更多信息，请参阅 在经典集群上部署 OpenShift Data Foundation。