规划部署
部署 RHOCS 4.8 时的重要注意事项
摘要
使开源包含更多
红帽承诺替换我们的代码、文档和网页属性中存在问题的语言。我们从这四个术语开始： master、slave、blacklist 和 whitelist。这些更改将在即将发行的几个发行本中逐渐实施。如需了解更多详细信息，请参阅 CTO Chris Wright 信息。
对红帽文档提供反馈
我们感谢您对文档提供反馈信息。请告诉我们如何让它更好。提供反馈：
关于特定内容的简单评论：
- 请确定您使用 Multi-page HTML 格式查看文档。另外，确定 Feedback 按钮出现在文档页的右上方。
- 用鼠标指针高亮显示您想评论的文本部分。
- 点在高亮文本上弹出的 Add Feedback。
- 按照显示的步骤操作。
要提交更复杂的反馈，请创建一个 Bugzilla ticket：
- 进入 Bugzilla 网站。
- 在 Component 部分中，选择 文档。
- 在 Description 中输入您要提供的信息。包括文档相关部分的链接。
- 点 Submit Bug。
第 1 章 OpenShift Container Storage 简介
Red Hat OpenShift Container Storage 是 Red Hat OpenShift Container Platform 的云存储和数据服务的高度集成集合。它作为 Red Hat OpenShift Container Platform Service Catalog 的一部分提供，它作为一个 operator 提供，以便于简单部署和管理。
Red Hat OpenShift Container Storage 服务主要通过代表以下组件的存储类提供给应用程序：
- 块存储设备，主要服务于数据库工作负载。示例包括 Red Hat OpenShift Container Platform 日志记录和监控，以及 PostgreSQL。
- 共享和分布式文件系统，主要服务于软件开发、消息传递和数据聚合工作负载。示例包括 Jenkins 构建源和工件、Wordpress 上传的内容、Red Hat OpenShift Container Platform registry，以及使用 JBoss AMQ 的消息传递。
- 多云对象存储，具有一个轻量级 S3 API 端点，可以从多个云对象存储中提取存储和检索数据。
- 在内部对象存储中，具有一个稳定的 S3 API 端点，可扩展到数十拍字节（PB）和数十亿个对象的环境，主要面向数据密集型应用。例如，使用 Spark、Pacesto、Red Hat AMQ Streams (Kafka) 等应用程序，以及 TensorFlow 和 Pytorch 等机器学习框架。
Red Hat OpenShift Container Storage 版本 4.x 集成了软件项目的集合，包括：
- Ceph，提供块存储、共享分布式文件系统以及内部对象存储
- Ceph CSI，用于管理持久性卷和声明的调配和生命周期
- NooBaa 提供多云对象网关
- OpenShift Container Storage、Rook-Ceph 和 NooBaa operator 用于初始化和管理 OpenShift Container Storage 服务。
第 2 章 OpenShift Container Storage 架构
Red Hat OpenShift Container Storage 提供服务，可以从 Red Hat OpenShift Container Platform 内部运行。
Red Hat OpenShift Container Storage 架构
Red Hat OpenShift Container Storage 支持部署到在 Installer Provisioned Infrastructure 或 User Provisioned Infrastructure 上部署的 Red Hat OpenShift Container Platform 集群。有关这两种方法的详情，请参阅 OpenShift Container Platform - 安装过程。要了解更多有关 Red Hat OpenShift Container Storage 和 Red Hat OpenShift Container Platform 组件互操作性的信息，请参阅互操作性列表。
如需有关 OpenShift Container Platform 架构和生命周期的信息，请参阅 OpenShift Container Platform 架构。
对于 IBM Power 系统，请参阅 OpenShift Container Platform - 安装过程。
2.1. 关于 Operator
Red Hat OpenShift Container Storage 包括三个主要的 operator，它们可以实现管理任务和自定义资源，从而可以轻松地自动执行任务和资源特征。管理员定义集群的所需最终状态，OpenShift Container Storage operator 通过最少的管理员干预来确保集群处于该状态，或接近该状态。
OpenShift Container Storage operator
一个元 operator，通过特定、经过测试的方式利用其他 Operator 来整理并强制实施受支持的 Red Hat OpenShift Container Storage 部署的建议和要求。此 operator 提供存储集群资源，以打包 Rook-Ceph 和 NooBaa operator 提供的资源。
Rook-Ceph operator
此 operator 自动打包、部署、管理、升级和扩展持久存储和文件、块和对象服务。它为所有环境创建块和文件存储类，并在内部环境中创建针对它的对象存储类和服务对象存储桶声明。
此外，对于内部模式集群，它提供 Ceph 集群资源，它管理部署和服务，如下所示：
- 对象存储守护进程 (OSD)
- 监视器 (MON)
- 经理 (MGR)
- 元数据服务器 (MDS)
- 仅限内部的对象网关 (RGW)
NooBaa operator
此 operator 自动打包、部署、管理、升级和扩展多云对象网关对象服务。它创建一个对象存储类和服务对象存储桶（bucket）声明。
另外，它还提供 NooBaa 集群资源，用于管理 NooBaa core、数据库和端点的部署和服务。
2.2. 存储集群部署方法
灵活性是 Red Hat OpenShift Container Storage 的核心原则，其运行状况列表就证明了这一点。本节将为您提供信息，帮助您为您的环境选择最合适的方法。OpenShift Container Storage 可以完全在 OpenShift Container Platform 中部署（内部方法），或者从 OpenShift Container Platform 外部运行的集群（外部方法）提供服务。
2.2.1. 内部方法
在 Red Hat OpenShift Container Platform 中完全部署 Red Hat OpenShift Container Storage 具有基于 Operator 的部署和管理优势。图形用户界面中的内部附加设备方法可用于使用本地存储 operator 和本地存储设备以内部模式部署 Red Hat OpenShift Container Storage。
当 Red Hat OpenShift Container Storage 完全在 Red Hat OpenShift Container Platform 中运行时，可以使用两种不同的部署模式：
- Simple（简单）
- Optimized（优化）
简单部署
Red Hat OpenShift Container Storage 服务与应用程序共同运行，这些应用程序由 Red Hat OpenShift Container Platform 中的 Operator 管理。
简单的部署最适用于以下情况：
- 存储要求不明确
- OpenShift Container Storage 服务将与应用程序共同运行
- 创建特定大小的节点实例比较困难（裸机）
为了让 Red Hat OpenShift Container Storage 与应用程序共同运行，它们必须具有动态附加本地存储设备或可移植存储设备（如 EC2 上的 EBS 卷或 VMware 上的 vSphere 虚拟磁盘）或由 PowerVC 动态置备的 SAN 卷。
优化的部署
OpenShift Container Storage 服务在由 Red Hat OpenShift Container Platform 管理的专用基础架构节点上运行。
优化的方法最适合以下情况：
- 存储要求是明确的
- OpenShift Container Storage 服务在专用的基础架构节点上运行
- 可轻松创建特定大小的节点实例（云、虚拟化环境等）
2.2.2. 外部方法
Red Hat OpenShift Container Storage 将 OpenShift Container Platform 集群外运行的 Red Hat Ceph Storage 服务作为存储类公开。
在以下情况下最适合使用外部方法：
- 存储要求非常显著（超过 600 个存储设备）
- 多个 OpenShift Container Platform 集群需要消耗来自通用外部集群的存储服务。
- 另一个团队（SRE、存储等）需要管理提供存储服务的外部集群。可能已存在。
2.3. 节点类型
节点运行容器运行时和服务，以确保容器正在运行，并且维护容器集之间的网络通信和隔离。在 OpenShift Container Storage 中，有三种类型的节点：
表 2.1. 节点类型
| 节点类型 | Description |
|---|---|
| Master | 这些节点运行公开 Kubernetes API、观察和调度新创建的 pod、维护节点健康和数量，以及控制与底层云供应商的交互的进程。 |
| Infrastructure (Infra) | Infra 节点运行集群级别的基础架构服务，如日志记录、指标、registry 和路由。这些在 OpenShift Container Platform 集群中是可选的。建议您在虚拟化环境和云环境中使用 infra 节点作为 OpenShift Container Storage。
要创建 Infra 节点，您可以置备标记为 |
| Worker | Worker 节点也称为应用节点，因为它们运行应用。 当 OpenShift Container Storage 以内部模式部署时，需要最少的 3 个 worker 节点集群，其中节点需要分散到三个不同的机架或可用区，以确保可用性。为了使 OpenShift Container Storage 能够在 worker 节点上运行，它们必须具有本地存储设备，或者动态附加有可移植存储设备。 当以外部模式部署时，它在多个节点上运行，以便在出现故障时允许 K8S 重新调度可用节点上的。 可移植存储设备的示例包括 EC2 上的 EBS 卷或 VMware 上的 vSphere 虚拟磁盘，或者 PowerVC 动态置备的 SAN 卷。 |
仅运行存储工作负载的节点需要 Red Hat OpenShift Container Storage 订阅。除了存储工作负载外，运行其他工作负载的节点还需要 Red Hat OpenShift Container Storage 和 Red Hat OpenShift Container Platform 订阅。如需更多信息，请参阅 第 6 章 订阅。
第 3 章 内部存储服务
Red Hat OpenShift Container Storage 服务可在内部被在以下基础架构上运行的 Red Hat OpenShift Container Platform 使用：
- Amazon Web Services
- 裸机
- VMware vSphere
- Microsoft Azure
- Google Cloud [技术预览]
- Red Hat Virtualization 4.4.x 或更高版本 (IPI)
- Red Hat OpenStack 13 或更高版本 (IPI) [技术预览]
- IBM Power 系统
- IBM Z 和 LinuxONE
易于部署和管理是在 OpenShift Container Platform 内部运行 OpenShift Container Storage 服务的关键。创建内部集群资源将导致内部置备 OpenShift Container Storage 基础服务，并为应用程序提供额外的存储类。
第 4 章 外部存储服务
Red Hat OpenShift Container Storage 可以从外部 Red Hat Ceph Storage 集群提供服务，以便通过在以下平台上运行的 OpenShift Container Platform 集群使用：
- VMware vSphere
- 裸机
- Red Hat OpenStack platform（技术预览）
OpenShift Container Storage operator 会创建和管理服务，以满足针对外部服务的持久性卷和对象存储桶声明。外部集群可以为 OpenShift Container Platform 上运行的应用程序提供 Block、file 和 Object 存储类。外部集群不会由 Operator 部署和管理。
第 5 章 安全考虑
5.1. FIPS-140-2
Federal Information Processing Standard Publication 140-2 (FIPS-140-2) 是定义使用加密模块的一系列安全要求的标准。这个标准受到美国政府机构和承包商的强制要求，在其他国际和行业特定的标准中也会引用该标准。
Red Hat OpenShift Container Storage 现在使用由 Red Hat Enterprise Linux OS/CoreOS (RHCOS) 提供的 FIPS 验证加密模块。
加密模块目前由加密模块验证计划 (CMVP) 处理，其状态可在流程列表中的模块列表中看到。有关更新的信息，请参阅知识库文章。
在安装 OpenShift Container Storage 之前，必须在 OpenShift Container Platform 上启用 FIPS 模式。OpenShift Container Platform 必须在 RHCOS 节点上运行，因为此功能不支持在 RHEL 7 上部署 OpenShift Container Storage。
如需更多信息，请参阅在 FIPS 模式中安装集群和FIPS 加密的支持。
5.2. 代理环境
代理环境是一个生产环境，它拒绝直接访问互联网并提供可用的 HTTP 或 HTTPS 代理。Red Hat Openshift Container Platform 被配置为使用代理，方法是修改现有集群的代理对象，或在新集群的 install-config.yaml 文件中配置代理设置。
当根据配置集群范围代理中的内容配置 OpenShift Container Platform 后，红帽支持在代理环境中部署 Openshift Container Storage 版本 4.5 或更高版本。
5.3. 数据加密选项
加密可让您对数据进行编码，使其在没有所需的加密密钥的情况下无法读取。通过这种机制，当物理性安全被破坏的情况下，您的数据所在的物理介质丢失时，可以保护您的数据的安全性。当数据写入到磁盘时，数据会被加密，并在从磁盘读取数据时对其进行解密。使用加密的数据可能会对性能产生较小的影响。
仅使用 OpenShift Container Storage 4.6 或更高版本部署的新集群才支持加密。没有使用外部密钥管理系统 (KMS) 的现有加密集群无法迁移为使用外部 KMS。
目前，HashiCorp Vault 是唯一支持集群范围的 KMS 和持久性卷加密的 KMS。在 OpenShift Container Storage 4.7.0 和 4.7.1 中，只支持 HashiCorp Vault Key/Value (KV) secret engine API，支持版本 1。从 OpenShift Container Storage 4.7.2 开始，支持 HashiCorp Vault KV secret 引擎 API、版本 1 和 2。
- KMS 是持久性卷(PV)加密所必需的，对于集群范围加密是可选的。
- 红帽与技术合作伙伴合作，将本文档作为为客户提供服务。但是，红帽不为 Hashicorp 产品提供支持。有关此产品的技术协助，请联系 Hashicorp。
5.3.1. 集群范围的加密
Red Hat OpenShift Container Storage 支持存储集群中所有磁盘和多云对象网关操作的集群范围加密 (encryption-at-rest)。OpenShift Container Storage 使用基于 Linux 统一密钥系统 (LUKS) 版本 2 的加密，其密钥大小为 512 位，以及 aes-xts-plain64 密码，其中每个设备都有不同的加密密钥。密钥使用 Kubernetes secret 或外部 KMS 存储。两种方法都是互斥的，您不能在方法之间迁移。
加密默认是禁用的。您可以在部署时为集群启用加密。如需更多信息，请参阅部署指南。
在没有密钥管理系统 (KMS) 的 OpenShift Container Storage 4.6 中支持集群范围的加密，而 OpenShift Container Storage 4.7 也支持它，且没有 KMS。
目前，HashiCorp Vault 是唯一受支持的 KMS。在 OpenShift Container Storage 4.7.0 和 4.7.1 中，只支持 HashiCorp Vault KV secret 引擎，支持 API 版本 1。从 OpenShift Container Storage 4.7.2 开始，支持 HashiCorp Vault KV secret 引擎 API、版本 1 和 2。
红帽与技术合作伙伴合作，将本文档作为为客户提供服务。但是，红帽不为 Hashicorp 产品提供支持。有关此产品的技术协助，请联系 Hashicorp。
5.3.2. 存储类加密
您可以使用外部密钥管理系统 (KMS) 使用存储类加密来加密持久性卷（仅限块）来存储设备加密密钥。永久卷加密仅可用于 RADOS 块设备 (RBD) 持久卷。请参阅如何使用持久性卷加密创建存储类。
OpenShift Container Storage 4.7 或更高版本支持存储类加密。
第 6 章 订阅
6.1. 订阅服务
Red Hat OpenShift Container Storage 订阅基于"内核对"，与 Red Hat OpenShift Container Platform 类似的。Red Hat OpenShift Container Storage 2 核订阅基于 OpenShift Container Platform 运行的系统中 CPU 的逻辑内核数量。
与 OpenShift Container Platform 一样：
- OpenShift Container Storage 订阅可以以堆栈的形式来满足大型的主机。
- 内核可以根据需要在多个虚拟机 (VM) 间进行分配。例如，十个 2 核订阅将提供 20 个内核。对于 IBM Power 系统，2 核 订阅（SMT 级别 8）会提供 2 个内核或 16 个 vCPU，可在任意数量的虚拟机中使用。
- OpenShift Container Storage 订阅提供 Premium 或 Standard 支持。
6.2. 灾难恢复订阅
Red Hat OpenShift Container Storage 不提供灾难恢复(DR)、冷备份或其他订阅类型。任何安装了 OpenShift Container Storage、开机或关机、运行工作负载的系统都需要有效的订阅。
6.3. 内核与 vCPU 和超线程
判断特定系统是否消耗一个或多个内核目前取决于该系统是否可用超线程。超线程只是 Intel CPU 的一项功能。访问红帽客户门户，以确定特定系统是否支持超线程。
对于启用了超线程的系统，一个超线程等于一个可见的系统内核，内核的计算是 2 个内核到 4 个 vCPU 的比率。因此，2 核订阅涵盖超线程系统中的 4 个 vCPU。一个大型虚拟机 (VM) 可能具有 8 个 vCPU，相当于 4 个订阅内核。当订阅以 2 核作为单位时，您将需要两个 2 核订阅来满足 4 个内核或 8 个 vCPU。
如果没有启用超线程，并且每个可见的系统内核直接与底层物理内核关联，内核的计算为 2 个内核到 2 个 vCPU 的比率。
6.3.1. 用于 IBM Power 系统的内核与 vCPU 以及并发多线程(SMT)
确定特定系统是否消耗一个或多个内核目前取决于配置的并发多线程级别 (SMT)。IBM Power 系统为每个内核提供 1、2、4 或 8 的并发多线程级别，对应于下表中的 vCPU 数量。
表 6.1. 不同的 SMT 级别及其对应的 vCPU
| SMT 级别 | SMT=1 | SMT=2 | SMT=4 | SMT=8 |
|---|---|---|---|---|
| 1 个内核 | # vCPUs=1 | # vCPUs=2 | # vCPUs=4 | # vCPUs=8 |
| 2 个内核 | # vCPUs=2 | # vCPUs=4 | # vCPUs=8 | # vCPUs=16 |
| 4 个内核 | # vCPUs=4 | # vCPUs=8 | # vCPUs=16 | # vCPUs=32 |
对于配置 SMT 的系统，用于订阅所需的内核数取决于 SMT 级别。因此，2 核订阅对于 SMT 级别 1 是 2 个 vCPU、对于 SMT 级别 2 是 4 个 vCPU，对于 SMT 级别 4 是 8 个 vCPU，对于 SMT 级别 8 是 16 个 vCPU，如上表所示。一个大型虚拟机 (VM) 可能有 16 个 vCPU，在 SMT 级别 8 中，需要一个 2 核订阅。计算方法是 vCPU 的数量除以 SMT 级别（对于 SMT-8，16 个 vCPU / 8 = 2）。当订阅以 2 核为单位时，您将需要一个 2 核订阅来满足这 2 个内核或 16 个 vCPU。
6.4. 分割内核
需要奇数内核的系统需要消耗整个 2 核订阅。例如，对于只需要 1 个内核的系统，在注册和订阅了 2 核订阅后，会使用整个 2 核订阅。
当具有 2 个 vCPU 的单个虚拟机 (VM) 使用超线程计算的 vCPU 时，则需要一个完整的 2 核订阅；不能在具有 2 个使用超线程的 2 个 vCPU 之间分割单个 2 核订阅。如需更多信息，请参阅内核、 vCPU 以及超线程的比较部分。
建议对虚拟实例进行大小调整，以便它们需要偶数数量的内核。
6.5. 订阅要求
OpenShift Container Storage 组件可以在 OpenShift Container Platform worker 或基础架构节点上运行，您可以将 Red Hat CoreOS (RHCOS) 或 Red Hat Enterprise Linux (RHEL)7 用作主机操作系统。每个 OpenShift Container Platform 订阅的内核都需要 OpenShift Container Storage 订阅，比率为 1:1。
使用基础架构节点时，会应用为 OpenShift Container Storage 订阅所有 OpenShift worker 节点内核的规则，即使它们不需要 OpenShift Container Platform 或任何 OpenShift Container Storage 订阅。您可以使用标签来说明节点是 worker 还是基础架构节点。
如需更多信息，请参阅管理和分配存储资源指南中的如何将专用 worker 节点用于 Red Hat OpenShift Container Storage 一章。
第 7 章 基础架构要求
7.1. 平台要求
Red Hat OpenShift Container Storage 4.8 只在 OpenShift Container Platform 版本 4.8 及其下一个次版本中被支持。
以前版本的 OpenShift Container Storage 的程序错误修正将会作为程序错误修复版本发布。详情请参阅 Red Hat OpenShift Container Platform 生命周期政策。
有关外部集群订阅要求，请参阅红帽知识库文章。
有关支持的平台版本的完整列表，请参阅 Red Hat OpenShift Container Storage 和 Red Hat OpenShift Container Platform 互操作性列表。
7.1.1. Amazon EC2
仅支持内部 Red Hat Openshift Container Storage 集群。
内部集群必须满足存储设备要求，并有一个提供的存储类
- 通过 aws-ebs 置备程序进行 EBS 存储
7.1.2. 裸机
支持内部集群和使用外部集群。
内部集群必须满足存储设备要求，并且具有通过 Local Storage Operator 提供本地 SSD（NVMe/SATA/SAS、SAN）的存储类。
7.1.3. VMware vSphere
支持内部集群和使用外部集群。
推荐的版本： vSphere 6.7, Update 2
详情请参阅 VMware vSphere 基础架构要求。
另外，内部集群必须满足存储设备要求，并具有提供存储类的存储类
- VSAN 或 VMFS 数据存储通过 vsphere-volume 置备程序
- VMDK、RDM 或 DirectPath 存储设备通过 Local Storage Operator。
7.1.4. Microsoft Azure
仅支持内部 Red Hat Openshift Container Storage 集群。
内部集群必须满足存储设备要求，并有一个提供的存储类
- 通过 azure-disk 置备程序 Azure 磁盘
7.1.5. Google Cloud [技术预览]
仅支持内部 Red Hat Openshift Container Storage 集群。
内部集群必须满足存储设备要求，并有一个提供的存储类
- 通过 gce-pd 置备程序 GCE Persistent Disk
7.1.6. Red Hat Virtualization Platform
仅支持内部 Red Hat Openshift Container Storage 集群。
内部集群必须满足存储设备要求，并且具有通过 Local Storage Operator 提供本地 SSD（NVMe/SATA/SAS、SAN）的存储类。
7.1.7. Red Hat OpenStack Platform [技术预览]
支持内部 Red Hat Openshift Container Storage 集群和使用外部集群。
内部集群必须满足存储设备要求，并有一个提供的存储类
- 通过 Cinder 置备程序的标准磁盘
7.1.8. IBM Power 系统
仅支持内部 Red Hat Openshift Container Storage 集群。
内部集群必须满足存储设备要求，并且具有通过 Local Storage Operator 提供本地 SSD（NVMe/SATA/SAS、SAN）的存储类。
7.1.9. IBM Z 和 LinuxONE
仅支持内部 Red Hat Openshift Container Storage 集群。
内部集群必须满足存储设备要求，并且具有通过 Local Storage Operator 提供本地 SSD（NVMe/SATA/SAS、SAN）的存储类。
7.2. 外部模式要求
7.2.1. Red Hat Ceph Storage
需要 Red Hat Ceph Storage (RHCS) 版本 4.2z1 或更高版本。如需有关支持版本的更多信息，请参阅有关 Red Hat Ceph Storage 版本和相应 Ceph 软件包版本的知识库文章。
有关如何安装 RHCS 4 集群的说明，请参阅安装指南。
7.3. 资源要求
OpenShift Container Storage 服务由一组初始的基础镜像组成，并可使用额外的设备集进行扩展。所有这些 OpenShift Container Storage 服务 pod 都由 OpenShift Container Platform 节点上的 kubernetes 根据资源要求调度。以三个节点（每个故障域中一个节点）来扩展集群是满足 pod 放置规则的一种简单方法。
这些要求仅与 OpenShift Container Storage 服务相关，而不与这些节点上运行的其他服务、操作员或工作负载无关。
表 7.1. 仅限 OpenShift Container Storage 的可用资源要求
| 部署模式 | 基础服务 | 附加设备集 |
|---|---|---|
| 内部 |
|
|
| 外部 |
重要 外部红帽 Ceph 存储集群使用普通 Ceph 大小规则，以了解 硬件指南 的详细信息。
| Not applicable |
示例：对于内部模式中带有单个设备集的 3 个节点集群，至少需要 3 x 10 = 30 个 CPU 单元。
有关设计 OpenShift Container Storage 集群的其他指导，请参阅 OCS 大小工具。
CPU 单元
在本节中，1 个 CPU 单元映射到 Kubernetes 的 1 个 CPU 单元的概念。
- 1 个 CPU 单元相当于 1 个非超线程 CPU 内核。
- 2 个 CPU 单元相当于 1 个超线程 CPU 内核。
- OpenShift Container Storage 基于内核的订阅总是成对提供（2 内核）。
表 7.2. IBM Power 系统的合计的最低资源要求
| 部署模式 | 基础服务 |
|---|---|
| 内部 |
|
| 外部 |
|
示例：对于内部附加设备模式中的 3 个节点集群，至少需要 48（3 x 16）个 CPU 单元，3 x 64 = 192 GB 内存。
7.3.1. IBM Z 和 LinuxONE 基础架构的资源要求
OpenShift Container Storage 服务由一组初始的基础镜像组成，并可使用额外的设备集进行扩展。
所有这些 OpenShift Container Storage 服务 pod 都由 kubernetes 根据 资源要求 调度到 OpenShift Container Platform 节点上。
以三个节点（每个故障域中一个节点）来扩展集群是满足 pod 放置规则的一种简单方法。
表 7.3. 仅聚合 OpenShift Container Storage 的可用资源要求（IBM Z 和 LinuxONE）
| 部署模式 | 基础服务 | 附加设备集 | IBM Z 和 LinuxONE 最低硬件要求 |
|---|---|---|---|
| 内部 |
|
| 1 个 IFL |
| 外部 |
| Not applicable | Not applicable |
- CPU
- 是系统管理程序、IBM z/VM、内核虚拟机(KVM)或两者中定义的虚拟内核数。
- IFL（Linux 集成设施）
- 是 IBM Z 和 LinuxONE 的物理核心。
最低系统环境
- 要运行带有 1 逻辑分区(LPAR)的最小群集，需要在 6 IFL 之上再添加一个 IFL。OpenShift 容器平台使用这些 IFL。
7.3.2. 最低部署资源要求 [技术预览]
当不符合标准部署资源要求时，OpenShift Container Storage 集群将以最小配置进行部署。
这些要求仅与 OpenShift Container Storage 服务相关，而不与这些节点上运行的其他服务、操作员或工作负载无关。
表 7.4. 只聚合 OpenShift Container Storage 的资源要求
| 部署模式 | 基础服务 |
|---|---|
| 内部 |
|
如果要添加额外的设备集，我们建议将最小部署转换为标准部署。
部署具有最低配置的 OpenShift Container Storage 是一项技术预览功能。技术预览功能不被红帽产品服务等级协议 (SLA) 支持，且可能在功能方面有缺陷。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。
如需更多信息，请参阅技术预览功能支持范围。
7.3.3. 紧凑部署资源要求
OpenShift Container Storage 可以安装到三节点 OpenShift 紧凑裸机集群中，所有工作负载都在三个强大的 master 节点上运行。没有 worker 或存储节点。
这些要求仅与 OpenShift Container Storage 服务相关，而不与这些节点上运行的其他服务、操作员或工作负载无关。
表 7.5. 只聚合 OpenShift Container Storage 的资源要求
| 部署模式 | 基础服务 | 附加设备集 |
|---|---|---|
| 内部 |
|
|
要在紧凑的裸机集群中配置 OpenShift Container Platform，请参阅部署配置三节点集群和为 Edge 部署提供三节点架构。
7.4. Pod 放置规则
Kubernetes 根据声明性放置规则负责 pod 放置。内部集群的 OpenShift Container Storage 基础服务放置规则总结如下：
-
节点使用
cluster.ocs.openshift.io/openshift-storage密钥标记 - 如果不存在，节点将被排序为伪故障域
- 需要高可用性的组件分散在故障域中
- 每个故障域中必须可以访问存储设备
这会产生以下要求：至少有三个节点，并且节点于三个不同的机架或区域故障域中（如果预先存在的拓扑标签 ）。
对于额外的设备集，在三个故障域中必须有一个存储设备和消耗它的 pod 的充足资源。可以使用手动放置规则覆盖默认放置规则，但这种方法通常仅适用于裸机部署。
7.5. 存储设备要求
使用本节了解在规划内部模式部署和升级时可以考虑的不同存储容量要求。我们通常建议每个节点 9 个设备或更少。本建议可确保节点保持低于云供应商动态存储设备附加限制，以及限制使用本地存储设备的节点故障后恢复时间。以三个节点（每个故障域中一个节点）来扩展集群是满足 pod 放置规则的一种简单方法。
您只能根据安装时所选的容量递增来扩展存储容量。
7.5.1. 动态存储设备
Red Hat OpenShift Container Storage 允许选择 0.5 TiB、2 TiB 或 4 TiB 容量作为动态存储设备大小的请求大小。可以每个节点运行的动态存储设备数量取决于节点大小、底层置备程序限制和资源要求。
7.5.2. 本地存储设备
对于本地存储部署，可以使用 4 TiB 或更少的磁盘大小，并且所有磁盘的大小和类型都应相同。可以每个节点运行的本地存储设备数量取决于节点大小和资源要求。以三个节点（每个故障域中一个节点）来扩展集群是满足 pod 放置规则的一种简单方法。
不支持磁盘分区。
7.5.3. 容量规划
始终确保可用的存储容量保持领先于消费。如果可用存储容量已完全用尽，则需要更多的干预，而不是仅仅添加容量、删除或迁移内容。
当集群存储容量达到总容量的 75%（接近满）和 85%（满）时，会发出容量警报。始终及时处理容量警告的信息，并定期检查您的存储以确保您不会耗尽存储空间。达到 75% (接近满) 时，释放一些空间或扩展集群。当出现 85%（满）警报时，这表示您已完全耗尽存储空间，并且无法使用标准命令释放空间。如果出现这种情况，请联系红帽客户支持。
下表显示了带有动态存储设备的 Red Hat OpenShift Container Storage 节点配置示例。
表 7.6. 带有 3 个节点的初始配置示例
| 存储设备大小 | 每个节点的存储设备 | 总容量 | 可用的存储容量 |
|---|---|---|---|
| 0.5 TiB | 1 | 1.5 TiB | 0.5 TiB |
| 2 TiB | 1 | 6 TiB | 2 TiB |
| 4 TiB | 1 | 12 TiB | 4 TiB |
表 7.7. 带有 30 个节点 (N) 的扩展配置示例
| 存储设备大小 (D) | 每个节点的存储设备 (M) | 总容量 (D * M * N) | 可用的存储容量 (D*M*N/3) |
|---|---|---|---|
| 0.5 TiB | 3 | 45 TiB | 15 TiB |
| 2 TiB | 6 | 360 TiB | 120 TiB |
| 4 TiB | 9 | 1080 TiB | 360 TiB |
7.6. 支持多网络插件 (Multus)
默认情况下，Red Hat OpenShift Container Storage 被配置为使用 Red Hat OpenShift Software Defined Network (SDN)。在这个默认配置中，SDN 会传输以下类型的流量：
- Pod 到 pod 流量
- Pod 到 OpenShift Container Storage 流量，称为 OpenShift Container Storage 公共网络流量
- OpenShift Container Storage 复制和重新平衡，称为 OpenShift Container Storage 集群网络流量
但是，OpenShift Container Storage 4.8 及更新的版本支持作为技术预览使用 Multus 通过隔离不同类型的网络流量来提高安全性和性能。
Multus 支持是一个技术预览功能，它只受支持并在裸机和 VMWare 部署中测试。技术预览功能不被红帽产品服务等级协议 (SLA) 支持，且可能在功能方面有缺陷。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。
如需更多信息，请参阅技术预览功能支持范围。
7.6.1. 了解多网络
在 Kubernetes 中，容器联网由实现了 Container Network Interface (CNI) 的网络插件负责。
OpenShift Container Platform 使用 Multus CNI 插件来实现对 CNI 插件的链接。在集群安装过程中，您要配置 default pod 网络。默认网络处理集群中的所有一般网络流量。您可以基于可用的 CNI 插件定义额外网络，并将一个或多个这种网络附加到 pod。您可以根据需要为集群定义多个额外网络。这可让您灵活地配置提供交换或路由等网络功能的 pod。
7.6.1.1. 额外网络使用场景
您可以在需要网络隔离的情况下使用额外网络，包括分离数据平面与控制平面。隔离网络流量对以下性能和安全性原因很有用：
- 性能
- 您可以在两个不同的平面上发送流量，以管理每个平面上流量的多少。
- 安全性
- 您可以将敏感的流量发送到专为安全考虑而管理的网络平面，也可隔离不能在租户或客户间共享的私密数据。
集群中的所有 pod 仍然使用集群范围的默认网络，以维持整个集群中的连通性。每个 pod 都有一个 eth0 接口，附加到集群范围的 pod 网络。您可以使用 oc exec -it <pod_name> -- ip a 命令来查看 pod 的接口。如果您添加使用 Multus CNI 的额外网络接口，则名称为 net1、net2、…、netN。
要将额外网络接口附加到 pod，您必须创建配置来定义接口的附加方式。您可以使用 NetworkAttachmentDefinition 自定义资源（CR）来指定各个接口。各个 CR 中的 CNI 配置定义如何创建该接口。
7.6.2. 使用 Multus 隔离存储流量
要使用 Multus，在部署前您必须创建稍后附加到集群的网络附加定义 (NAD)。如需更多信息，请参阅：
使用 Multus 时，根据您的硬件设置或 VMWare 实例网络设置，可以进行以下配置：
具有双网络接口的节点建议配置
隔离的存储流量
- 为 OpenShift SDN 配置一个接口（pod 到 pod 流量）
- 为所有 OpenShift Container Storage 流量配置一个接口
具有三倍网络接口的节点建议配置
完整流量隔离
- 为 OpenShift SDN 配置一个接口（pod 到 pod 流量）
- 为所有 pod 配置一个接口到 OpenShift Container Storage 流量（OpenShift Container Storage 公共流量）
- 为所有 OpenShift Container Storage 复制和重新平衡流量（OpenShift Container Storage 集群流量）配置一个接口。
7.6.3. Multus 配置的建议网络配置和要求
如果您决定利用 Multus 配置，必须满足以下先决条件：
- 用于部署 OpenShift Container Storage 的所有节点必须具有相同的网络接口配置，才能保证完全正常工作的 Multus 配置。所有节点上的网络接口名称必须相同，并连接到 Multus 公共网络和 Multus 集群网络的相同底层交换机制。
- 用于部署使用 OpenShift Container Storage 进行持久性存储的应用程序的所有节点必须具有相同的网络接口配置，以确保完全正常工作的 Multus 配置。两个接口之一必须与在存储节点上配置 Multus 公共网络的接口名称相同。所有工作程序网络接口必须连接到与存储节点的 Multus 公共网络相同的底层交换机制。
网络软件，无论是在交换机还是 SDN，有时会被过滤或丢弃，来自未知 MAC 地址的以太网帧。这个功能的 Cisco parlance 是"Port Security"，在裸机环境网络管理员需要确保它或等同的功能被禁用，这与 Multus 管理的物理网络接口的端口被禁用。对于软件定义的网络而言也是如此。对于 VMware，不得配置端口组的安全策略以防止 MAC 地址更改。
只有运行 OpenShift Container Storage OSD 的 Storage 节点需要访问通过 Multus 配置的 OpenShift Container Storage 集群网络。
如需了解在裸机上配置基于 Multus 的配置的步骤，请参阅创建 Multus 网络。
如需了解在 VMware 上配置基于 Multus 配置的步骤，请参阅创建 Multus 网络。
第 8 章 Disaster Recovery
灾难恢复 (DR) 有助于机构在出现中断或紧急情况时恢复业务关键功能或正常操作。
Red Hat OpenShift Container Storage 提供两种类型：
Regional-DR ：这是两个 OpenShift Container Storage 集群间存储卷的多集群异步复制，为两个 Openshift Container Platform 集群提供服务。任何有状态应用，包括其无状态的对等应用，都需要在对等群集上部署相同之前进行一些准备。
重要这是一个开发人员预览功能，受开发人员预览支持限制。开发人员预览版本不应在生产环境中运行，且不受红帽客户门户网站问题单管理系统的支持。如果您需要开发人员预览功能的帮助，请联络 ocs-devpreview@redhat.com 邮件列表和红帽开发团队成员将根据其可用性和工作计划尽快为您提供协助。
Metro-DR(Stretched Cluster - Arbiter) ：在这种情况下，单个集群将扩展到两个区域，并有第三个区域作为仲裁者的位置。这是一个技术预览功能，目前用于在 OpenShift Container Platform 内部部署。
注意此解决方案设计为在延迟不超过 4 毫秒的往返时间 (RTT) 时进行部署。如果您计划以更高的延迟进行部署，请联系红帽客户支持。
要使用 Arbiter 扩展集群，
在三个区中必须至少有五个节点：
- 每个区有两个节点用于每个数据中心区和
- 一个带有一个节点的区用于仲裁区（仲裁程序可以在主节点上）。
在创建集群之前，必须使用 zone 标签手动标记所有节点。
例如，这些区可以被标记为：
-
topology.kubernetes.io/zone=arbiter（master 节点或 worker 节点） -
topology.kubernetes.io/zone=datacenter1(最少两个 worker 节点) -
topology.kubernetes.io/zone=datacenter2(最少两个 worker 节点)
-
如需更多信息，请参阅
这是一个技术预览功能，仅适用于使用本地存储设备进行部署。技术预览功能不被红帽产品服务等级协议 (SLA) 支持，且可能在功能方面有缺陷。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。
如需更多信息，请参阅技术预览功能支持范围。
第 9 章 断开连接的环境
断开连接的环境是一个网络受限网络，Operator Lifecycle Manager (OLM) 无法访问需要互联网连接的默认 Operator Hub 和镜像 registry。
红帽支持在受限网络中安装 OpenShift Container Platform 的断开连接的环境中部署 OpenShift Container Storage。
在受限网络环境中安装 OpenShift Container Storage 时，请将自定义网络时间协议 (NTP) 配置应用到节点，因为默认情况下，OpenShift Container Platform 中会假设互联网连接，chronyd 被配置为使用 *.rhel.pool.ntp.org 服务器。如需了解更多详细信息，请参阅红帽知识库文章和配置 chrony 时间服务。
如需更多信息，请参阅在受限网络中使用 Operator Lifecycle Manager 的 Operator 指南。
第 10 章 IBM Power 系统和 IBM Z 基础架构不支持的功能
- IBM Power Systems 和 IBM Z 基础架构上的 OpenShift Container Storage 4.8 不支持 FIPS，因为 RHEL 不支持 FIPS 本身。
- 外部模式不适用于 IBM Power Systems 和 IBM Z 基础架构。
- IBM Z 基础架构不支持集群范围的加密。
- IBM Z 基础架构不支持在部署过程中进行存储数据加密。
- IBM Power Systems 上的 OpenShift Container Storage 4.8 不支持动态存储设备。
- IBM Power Systems 和 IBM Z 基础架构上的 OpenShift Container Storage 4.8 不支持 Disaster Recovery。
- 紧凑部署不适用于 IBM Power 系统和 IBM Z 基础架构。
- IBM Power Systems 和 IBM Z 基础架构上的 OpenShift Container Storage 4.8 不支持 Multus。
第 11 章 后续步骤
要开始部署 OpenShift Container Storage，您可以使用 OpenShift Container Platform 中的内部模式，或使用外部模式从 OpenShift Container Platform 外运行的集群提供可用服务。
根据您的要求，请转至相应的部署指南。
内部模式
- 使用 Amazon Web 服务部署 OpenShift Container Storage
- 使用裸机部署 OpenShift Container Storage
- 使用 VMWare vSphere 部署 OpenShift Container Storage
- 使用 Microsoft Azure 部署 OpenShift Container Storage
- 使用 Google Cloud [技术预览] 部署 OpenShift Container Storage
- 使用 Red Hat OpenStack Platform 部署 OpenShift Container Storage [技术预览]
- 使用 Red Hat Virtualization Platform 部署 OpenShift Container Storage
- 在 IBM Power 系统中部署 OpenShift Container Storage
- 在 IBM Z Infrastructure 上部署 OpenShift Container Storage
