规划部署
部署 RHOCS 4.6 时的重要注意事项
摘要
第 1 章 Red Hat 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 等机器学习框架。
IBM Power Systems 上的 OpenShift Container Storage 4.6 仅支持块和文件存储，而不是对象存储。
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 组件互操作性的信息，请参阅互操作性列表。
对于 IBM Power 系统，请参阅 OpenShift Container Platform - 安装过程。
如需有关 OpenShift Container Platform 架构和生命周期的信息，请参阅 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、存储等）需要管理提供存储服务的外部集群。可能已存在。
外部方法不适用于 IBM Power Systems、IBM Z 和 LinuxONE 架构。
2.3. 节点类型
节点运行容器运行时和服务，以确保容器正在运行，并且维护容器集之间的网络通信和隔离。在 OpenShift Container Storage 中，有三种类型的节点：
表 2.1. 节点类型
| 节点类型 | 描述 |
|---|---|
| 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。IBM Power 系统的 OpenShift Container Storage 4.6 不支持 FIPS。
如需更多信息，请参阅在 FIPS 模式中安装集群和FIPS 加密的支持。
5.2. 代理环境
代理环境是一个生产环境，它拒绝直接访问互联网并提供可用的 HTTP 或 HTTPS 代理。Red Hat Openshift Container Platform 被配置为使用代理，方法是修改现有集群的代理对象，或在新集群的 install-config.yaml 文件中配置代理设置。
当根据配置集群范围代理中的内容配置 OpenShift Container Platform 后，红帽支持在代理环境中部署 Openshift Container Storage 版本 4.5 或更高版本。
IBM Power Systems 上的 OpenShift Container Storage 4.6 不支持代理环境。
5.3. 数据加密选项
加密可让您对数据进行编码和模糊处理，从而在数据被盗时受到保护。Red Hat OpenShift Container Storage 4.6 支持对存储集群中所有磁盘进行静态加密，这意味着您的数据在写入磁盘时会加密，并在从磁盘读取时解密。
OpenShift Container Storage 4.6 使用基于 Linux Unified Key System (LUKS) 版本 2 的加密，其密钥大小为 512 位和 aes-xts-plain64 密码。每个设备都有不同的加密密钥，存储为 Kubernetes secret。
您可以在集群部署过程中为整个集群启用或禁用加密。它默认是禁用的。使用加密的数据对性能只会有非常小的损失。
使用 OpenShift Container Storage 4.6 部署的新集群只支持数据加密。升级到 4.6 的现有集群不支持它。
第 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。
对于配置 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 个订阅内核。当订阅以 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 都可以用作主机操作系统。当 worker 节点用于 OpenShift Container Storage 组件时，这些节点需要订阅 OpenShift Container Platform 和 OpenShift Container Storage。使用基础架构节点时，这些节点只需要具有 OpenShift Container Storage 订阅。标签用于指示节点是否应该被视为 worker 节点或基础架构节点，请参阅管理和分配存储资源指南中的如何为 Red Hat OpenShift Container Storage 使用专用 worker 节点。
第 7 章 基础架构要求
7.1. 平台要求
Red Hat OpenShift Container Storage 可以有一个或多个 OpenShift Container Platform，它可以比 OpenShift Container Storage 版本早一个次版本或新一个次版本。
OpenShift Container Storage 4.6 可以运行于：
- OpenShift Container Platform 4.5（老一个版本）
- OpenShift Container Platform 4.6（相同版本）
- OpenShift Container Platform 4.7（新一个版本）
对于 IBM Power Systems、IBM Z 和 LinuxONE 基础架构上的 OpenShift Container Storage 4.6，只支持 OpenShift Container Platform 4.6 或更高版本。
有关外部集群订阅要求，请参阅红帽知识库文章。
有关支持的平台版本的完整列表，请参阅 Red Hat OpenShift Container Storage 和 Red Hat OpenShift Container Platform 互操作性列表。
7.1.1. Amazon EC2
仅支持内部 Red Hat Openshift Container Storage 集群。
内部集群必须满足 存储设备要求，并且具有提供存储设备的存储类。
- 通过 aws-ebs 置备程序进行 EBS 存储
- 通过 Local Storage Operator 进行实例存储
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 集群的说明，请参阅安装指南。
外部模式不适用于 IBM Power 系统架构。
7.3. 资源要求
OpenShift Container Storage 服务由一组初始的基础镜像组成，并可使用额外的设备集进行扩展。所有这些 OpenShift Container Storage 服务 pod 都由 OpenShift Container Platform 节点上的 kubernetes 根据资源要求调度。以三个节点（每个故障域中一个节点）来扩展集群是满足 pod 放置规则的一种简单方法。
表 7.1. 汇总可用资源要求
| 部署模式 | 基础服务 | 附加设备集 |
|---|---|---|
| 内部 |
|
|
| 外部 |
| 不适用 |
示例：对于内部模式中带有单个设备集的 3 个节点集群，至少需要 3 x 10 = 30 个 CPU 单元。
CPU 单元
在本节中，1 个 CPU 单元映射到 Kubernetes 的 1 个 CPU 单元的概念。
- 1 个 CPU 单元相当于 1 个非超线程 CPU 内核。
- 2 个 CPU 单元相当于 1 个超线程 CPU 内核。
- OpenShift Container Storage 基于内核的订阅总是成对提供（2 内核）。
有关设计 OpenShift Container Storage 集群的其他指导，请参阅 OCS 大小工具。
7.3.1. 最低部署资源要求 [技术预览]
当不符合标准部署资源要求时，OpenShift Container Storage 集群将以最小配置进行部署。
表 7.2. 聚合资源要求
| 部署模式 | 基础服务 |
|---|---|
| 内部 |
|
如果要添加额外的设备集，我们建议将最小部署转换为标准部署。
部署具有最低配置的 OpenShift Container Storage 是一项技术预览功能。技术预览功能不被红帽产品服务等级协议 (SLA) 支持，且可能在功能方面有缺陷。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。
如需更多信息，请参阅技术预览功能支持范围。
7.3.2. 紧凑部署资源要求 [技术预览]
OpenShift Container Storage 现在可以安装到三节点 OpenShift 紧凑裸机集群中，所有工作负载都在三个强大的 master 节点上运行。没有 worker 或存储节点。
表 7.3. 只聚合 OpenShift Container Storage 的资源要求
| 部署模式 | 基础服务 | 附加设备集 |
|---|---|---|
| 内部 |
|
|
要在紧凑的裸机集群中配置 OpenShift Container Platform，请参阅部署配置三节点集群和为 Edge 部署提供三节点架构。
在三节点紧凑集群上部署 OpenShift Container Storage 是一项技术预览功能。技术预览功能不被红帽产品服务等级协议 (SLA) 支持，且可能在功能方面有缺陷。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。
如需更多信息，请参阅技术预览功能支持范围。
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 容量作为动态存储设备大小的请求大小。可以每个节点运行的动态存储设备数量取决于节点大小、底层置备程序限制和资源要求。
IBM Power Systems 上的 OpenShift Container Storage 4.6 不支持动态存储设备。
7.5.2. 本地存储设备
对于本地存储部署，可以使用 4 TiB 或更少的磁盘大小，并且所有磁盘的大小和类型都应相同。可以每个节点运行的本地存储设备数量取决于节点大小和资源要求。以三个节点（每个故障域中一个节点）来扩展集群是满足 pod 放置规则的一种简单方法。
7.5.3. 容量规划
始终确保可用的存储容量保持领先于消费。如果可用存储容量已完全用尽，则需要更多的干预，而不是仅仅添加容量、删除或迁移内容。
当集群存储容量达到总容量的 75%（接近满）和 85%（满）时，会发出容量警报。始终及时处理容量警告的信息，并定期检查您的存储以确保您不会耗尽存储空间。如果您完全耗尽存储空间，请联系 红帽客户支持。
下表显示了带有动态存储设备的 Red Hat OpenShift Container Storage 节点配置示例。
表 7.4. 带有 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.5. 带有 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 |
第 8 章 断开连接的环境
断开连接的环境是一个网络受限网络，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 指南。
IBM Power Systems 上的 OpenShift Container Storage 4.6 不支持断开连接的环境。
第 9 章 后续步骤
要开始部署 OpenShift Container Storage，您可以使用 OpenShift Container Platform 中的内部模式，或使用外部模式从 OpenShift Container Platform 外运行的集群提供可用服务。
根据您的要求，请转至相应的部署指南。
内部模式
- 使用 Amazon Web 服务部署 OpenShift Container Storage
- 使用裸机部署 OpenShift Container Storage
- 使用 VMWare vSphere 部署 OpenShift Container Storage
- 使用 Microsoft Azure 和 Azure Red Hat OpenShift 部署 OpenShift Container Storage
- 使用 Google Cloud [技术预览] 部署 OpenShift Container Storage
- 使用 Red Hat OpenStack Platform 部署 OpenShift Container Storage [技术预览]
- 使用 Red Hat Virtualization 平台部署 OpenShift Container Storage [技术预览]
- 在 IBM Power 系统中部署 OpenShift Container Storage
- 在 IBM Z 上部署 OpenShift Container Storage
