Menu Close
Settings Close

Language and Page Formatting Options

规划部署

Red Hat OpenShift Container Storage 4.7

部署 RHOCS 4.7 时的重要注意事项

摘要

有关规划 Red Hat OpenShift Container Storage 部署时的重要注意事项,请参阅本文档。

使开源包含更多

红帽承诺替换我们的代码、文档和网页属性中存在问题的语言。我们从这四个术语开始: master、slave、blacklist 和 whitelist。这些更改将在即将发行的几个发行本中逐渐实施。如需了解更多详细信息,请参阅 CTO Chris Wright 信息

对红帽文档提供反馈

我们感谢您对文档提供反馈信息。请告诉我们如何让它更好。提供反馈:

  • 关于特定内容的简单评论:

    1. 请确定您使用 Multi-page HTML 格式查看文档。另外,确定 Feedback 按钮出现在文档页的右上方。
    2. 用鼠标指针高亮显示您想评论的文本部分。
    3. 点在高亮文本上弹出的 Add Feedback
    4. 按照显示的步骤操作。
  • 要提交更复杂的反馈,请创建一个 Bugzilla ticket:

    1. 进入 Bugzilla 网站。
    2. 在 Component 中选择 Documentation
    3. Description 中输入您要提供的信息。包括文档相关部分的链接。
    4. Submit Bug

第 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 等机器学习框架。

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 architecture

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 节点,您可以置备标记为 infra 的新节点。请参阅如何为 Red Hat OpenShift Container Storage 使用专用 worker 节点?

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
  • Red Hat Virtualization 4.4.x 或更高版本 (IPI)
  • Microsoft Azure
  • Google Cloud [技术预览]
  • 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。

重要

红帽与技术合作伙伴合作,将本文档作为为客户提供服务。但是,红帽不为 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=1SMT=2SMT=4SMT=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.4.1. IBM Power 系统的共享处理器池

IBM Power 系统具有共享处理器池的概念。共享处理器池中的处理器可以在集群的节点之间共享。OpenShift Container Storage 所需的聚合计算容量应当是多个内核对。

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. 平台要求

从 OpenShift Container Storage 4.7 开始,只支持以下版本:

  • OpenShift Container Platform 4.7(相同版本)
  • 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 存储
  • 通过 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. Red Hat Virtualization Platform

仅支持内部 Red Hat Openshift Container Storage 集群。

内部集群必须满足存储设备要求,并且具有通过 Local Storage Operator 提供本地 SSD(NVMe/SATA/SAS、SAN)的存储类。

7.1.5. Microsoft Azure

仅支持内部 Red Hat Openshift Container Storage 集群。

内部集群必须满足存储设备要求,并有一个提供的存储类

  • 通过 azure-disk 置备程序 Azure 磁盘

7.1.6. Google Cloud [技术预览]

仅支持内部 Red Hat Openshift Container Storage 集群。

内部集群必须满足存储设备要求,并有一个提供的存储类

  • 通过 gce-pd 置备程序 GCE Persistent Disk

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 放置规则的一种简单方法。

表 7.1. 只聚合 OpenShift Container Storage 的资源要求

部署模式基础服务附加设备集

内部

  • 30 个 CPU(逻辑)
  • 72 GiB 内存
  • 3 个存储设备
  • 6 个 CPU(逻辑)
  • 15 GiB 内存
  • 3 个存储设备

外部

  • 4 个 CPU(逻辑)
  • 16 GiB 内存

Not applicable

示例:对于内部模式中带有单个设备集的 3 个节点集群,至少需要 3 x 10 = 30 个 CPU 单元。

如需更多信息,请参阅 第 6 章 订阅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 系统的合计的最低资源要求

部署模式基础服务

内部

  • 48 个 CPU(逻辑)
  • 192 GB 内存
  • 3 个存储设备,每个设备需要额外 500GB 磁盘

外部

  • Not applicable

示例:对于内部附加设备模式中的 3 个节点集群,至少需要 48(3 x 16)个 CPU 单元,3 x 64 = 192 GB 内存。

7.3.1. 最低部署资源要求 [技术预览]

当不符合标准部署资源要求时,OpenShift Container Storage 集群将以最小配置进行部署。

表 7.3. 只聚合 OpenShift Container Storage 的资源要求

部署模式基础服务

内部

  • 24 个 CPU(逻辑)
  • 72 GiB 内存
  • 3 个存储设备

如果要添加额外的设备集,我们建议将最小部署转换为标准部署。

重要

部署具有最低配置的 OpenShift Container Storage 是一项技术预览功能。技术预览功能不被红帽产品服务等级协议 (SLA) 支持,且可能在功能方面有缺陷。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

如需更多信息,请参阅技术预览功能支持范围

7.3.2. 紧凑部署资源要求 [技术预览]

OpenShift Container Storage 可以安装到三节点 OpenShift 紧凑裸机集群中,所有工作负载都在三个强大的 master 节点上运行。没有 worker 或存储节点。

表 7.4. 只聚合 OpenShift Container Storage 的资源要求

部署模式基础服务附加设备集

内部

  • 24 个 CPU(逻辑)
  • 72 GiB 内存
  • 3 个存储设备
  • 6 个 CPU(逻辑)
  • 15 GiB 内存
  • 3 个存储设备

要在紧凑的裸机集群中配置 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 容量作为动态存储设备大小的请求大小。可以每个节点运行的动态存储设备数量取决于节点大小、底层置备程序限制和资源要求

7.5.2. 本地存储设备

对于本地存储部署,可以使用 4 TiB 或更少的磁盘大小,并且所有磁盘的大小和类型都应相同。可以每个节点运行的本地存储设备数量取决于节点大小和资源要求。以三个节点(每个故障域中一个节点)来扩展集群是满足 pod 放置规则的一种简单方法。

注意

不支持磁盘分区。

7.5.3. 容量规划

始终确保可用的存储容量保持领先于消费。如果可用存储容量已完全用尽,则需要更多的干预,而不是仅仅添加容量、删除或迁移内容。

当集群存储容量达到总容量的 75%(接近满)和 85%(满)时,会发出容量警报。始终及时处理容量警告的信息,并定期检查您的存储以确保您不会耗尽存储空间。达到 75% (接近满) 时,释放一些空间或扩展集群。当出现 85%(满)警报时,这表示您已完全耗尽存储空间,并且无法使用标准命令释放空间。如果出现这种情况,请联系红帽客户支持

下表显示了带有动态存储设备的 Red Hat OpenShift Container Storage 节点配置示例。

表 7.5. 带有 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.6. 带有 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 章 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.7 仅支持块和文件存储,而不支持对象存储。
  • IBM Power Systems 和 IBM Z 基础架构上的 OpenShift Container Storage 4.7 不支持 FIPS,因为 RHEL 不支持 FIPS 本身。
  • 外部模式不适用于 IBM Power Systems 和 IBM Z 基础架构。
  • IBM Power Systems 和 IBM Z 上的 OpenShift Container Storage 4.7 不支持 Disconnected 环境。
  • IBM Power Systems 和 IBM Z infrstructure 上的 OpenShift Container Storage 4.7 不支持动态存储设备。
  • IBM Power 系统和 IBM Z 基础架构不支持 OpenShift Container Storage 4.7 中引入的以下新功能:

    1. 使用外部密钥管理系统 (KMS) 进行存储类加密。
    2. 集群范围加密。
    3. 灾难恢复。
    4. OpenShift Container Storage 集群的灵活扩展。

第 11 章 后续步骤

要开始部署 OpenShift Container Storage,您可以使用 OpenShift Container Platform 中的内部模式,或使用外部模式从 OpenShift Container Platform 外运行的集群提供可用服务。

根据您的要求,请转至相应的部署指南。