自助式红帽 OpenShift 订阅指南

简介

本文将帮助您了解自助式 红帽® OpenShift® 产品的订阅模式,并提供有关如何估算红帽 OpenShift 环境所需授权数量的分布说明。我们也可根据要求提供更准确的规模信息。

定义

首先,我们将定义一些您需要了解的术语:

  • 核心对: 这是自助式 OpenShift 订阅的基础之一。它定义为两个物理核心或四个 vCPU。在裸机上,它始终指物理核心,无论是否使用了任何超线程或对称多线程技术。如果启用了超线程,则两个物理核心(显示为四个 vCPU)仍计为一个核心对。对于超大规模云服务商部署(如 AWS、Azure 和 GCP),四个 vCPU 始终被视为一个核心对。核心对订阅在集群级别进行计数,因此可以跨多个云实例、虚拟机(VM)和物理服务器。
  • 裸机插槽对: 这是自助式 OpenShift 订阅的另一个基础。每台服务器至少需要一个裸机插槽对订阅,最多可覆盖 128 个核心。单个裸机插槽对订阅不能跨越多台服务器,订阅中的核心也不能跨越多台服务器。裸机插槽对订阅可以堆叠,以覆盖更多核心和更多插槽。
  • AI 加速器:所需的红帽 AI 加速器订阅数量基于物理硬件附加设备的数量,这些设备可加速中央处理单元(CPU)之外的某些计算功能。这些设备包括但不限于:独立图形处理单元(GPU)、张量处理单元(TPU)、数据处理单元(DPU)、现场可编程门阵列(FPGA)、专用集成电路(ASIC)以及作为附加组件安装的网络处理单元(NPU)。但是,与主 CPU 紧密集成的加速器(如集成 GPU、NPU 和其他类型的加速器)不包含在内。尽管这些加速器通常可以虚拟化并分配给多个虚拟机或实例,并且可能具有与 CPU 核心类似的一个或多个“核心”,但订阅数量基于物理设备的数量。
  • SLA: 红帽订阅需要选择支持服务级别协议(SLA)。具体有两种选择:标准 8x5 支持 SLA 或全天候高级支持 SLA。
  • 计算节点:运行最终用户应用 pod 的红帽企业 Linux® 或红帽企业 Linux CoreOS 的实例(虚拟机或裸机主机)。OpenShift 环境可以拥有多个计算节点。这些节点需要 OpenShift 订阅。支持计算节点的控制平面节点和基础架构节点不需要订阅,但可能会产生基础架构费用。
  • 控制平面节点:红帽企业 Linux CoreOS 的实例(虚拟机或裸机主机),充当红帽 OpenShift 的 Kubernetes 编排或管理层。自助式 OpenShift 订阅中包含控制平面节点授权,因此无需计算即可确定需要购买的订阅数量。有关更多详细信息,请参阅“红帽 OpenShift 控制平面和基础架构节点”部分。
  • 基础架构节点:运行支持 OpenShift 集群基础架构的 pod 而非应用实例的节点。(比如,运行基于 HAProxy 的负载平衡器以处理入口流量的节点)。自助式 OpenShift 订阅中包含基础架构节点授权,只要这些节点上未运行用户应用实例,则无需计算即可确定要购买的订阅数量。
  • 集群:由控制平面、可选基础架构节点和一个或多个计算节点组成的 OpenShift Kubernetes 集群。

应用实例:“应用”可以是单 pod 实例,也可以部署在构成应用服务的多 pod 实例中。例如,高度可用的应用服务可能由两个或多个 pod 组成。应用实例必须始终在具有红帽 OpenShift 订阅的计算节点上运行。

红帽 OpenShift 订阅版本

红帽 OpenShift 在开放混合云环境中提供一致的应用开发和管理平台,并支持本地、虚拟和物理基础架构,以及私有云、公共云和边缘部署。红帽 OpenShift 的运维和使用方式有两种:自助式 OpenShift 和全托管式 OpenShift 云服务。本指南重点介绍自助式 OpenShift。

自助式 OpenShift 使您能够以最大的控制程度、灵活性和个性化来安装、运维和管理红帽 OpenShift 环境,从而能够从基础架构开始运维自己的环境。自助式 OpenShift 支持在本地(物理服务器、虚拟化平台,以及在私有云环境中)以及支持的公共云环境中运行。您可以自行控制升级、管理位于底层的基础架构,以及维护服务级别协议(SLA)。

托管式 OpenShift 云服务由红帽及其公共云合作伙伴在主要公共云中全面管理和运维。专业的站点可靠性工程(SRE)团队负责管理和维护红帽 OpenShift 核心服务和基础架构,使得 DevSecOps 团队能够专注于开发和部署新应用以及实现现有应用的现代化。

OpenShift 云服务产品以及更多信息来源:

所有版本的红帽 OpenShift 都能为开发人员和运维团队提供一致的用户体验,使您能够将自己的技能和应用转移到应用运行效果最佳的云环境中。

计入自助式 OpenShift 订阅的情况

自助式 OpenShift(红帽 OpenShift 平台 Plus、红帽 OpenShift 容器平台、红帽 OpenShift Kubernetes 引擎和红帽 OpenShift 虚拟化引擎)可在 64 位红帽企业 Linux 已获认证且受支持的任何地方运行。请参阅 相关文档,以了解关于  OpenShift 部署方法和支持的基础架构类型的更多信息。

自助式 OpenShift 软件版本:

  • 红帽 OpenShift Kubernetes 引擎:一种面向混合云的企业级 Kubernetes 运行时引擎,提供核心 OpenShift 功能,用于部署和运行应用,您可以在数据中心、公共云和边缘环境中安装和管理该平台。
  • 红帽 OpenShift 容器平台: 一种功能齐全的面向混合云的企业级 Kubernetes 应用平台,可用来构建、部署和运行应用,您可以在数据中心、公共云和边缘环境中安装和管理该平台。
  • 红帽 OpenShift 平台 Plus: 一种使企业能够在多个集群和云环境中大规模构建、部署、运行和管理智能应用的混合云平台。该平台提供多层安全防护、可管理性和自动化,可在整个软件供应链中提供一致的体验。OpenShift 平台 Plus 订阅仅适用于基于 x86 的集群。
  • 红帽 OpenShift 虚拟化引擎:基于红帽 OpenShift 和开源的基于内核的虚拟机(KVM)监控程序的纯裸机虚拟化基础架构产品,旨在为企业提供可靠的企业级解决方案,用于部署、管理和扩展虚拟机。作为 OpenShift 功能的一部分,此版本的 OpenShift 适用于仅虚拟机工作负载,且仅支持容器中的基础架构服务(即不支持最终用户应用容器)。

订阅类型

自助式 OpenShift 有两种类型的订阅(核心对和裸机插槽对),每种订阅具有两种支持级别。

环境中的计算节点需要计算节点订阅。这些订阅可以通过核心对或裸机插槽对进行授权:

  1. 核心对(两个核心或四个 vCPU)
    • 此订阅选项适用于 OpenShift Kubernetes 引擎、OpenShift 容器平台和 OpenShift 平台 Plus。核心订阅 适用于 OpenShift 虚拟化引擎。
    • 在向 CPU 核心授权时,计算在您想要使用核心对订阅授权的所有 OpenShift 集群中运行的所有 OpenShift 计算节点的物理核心或 vCPU 总数。
    • 提供每周五天、每天八小时的标准支持 SLA 选项,或全天候高级支持 SLA 选项。
  2. 裸机插槽对(一至两个插槽,最多 128 个核心)
    • 此订阅选项适用于所有自助式 OpenShift 版本,也是 OpenShift 虚拟化引擎的唯一选项。
    • 此订阅选项仅适用于 x86 和 ARM 裸机物理节点,其中 OpenShift 直接安装在硬件上。不允许使用第三方虚拟机监控程序。
    • 这显然 是 “虚拟数据中心 ”订阅(比如用于虚拟数据中心的红帽企业 Linux,只需单个订阅,即可让您在任何虚拟机监控程序主机上无限次安装虚拟机客户操作系统)。
    • 提供每周五天、每天八小时的标准支持 SLA 选项,或全天候高级支持 SLA 选项。
    • 对于具有超过两个插槽或超过 128 个核心的裸机服务器,可以叠加使用订阅,但单个订阅不能跨越多台裸机服务器

此外,您还需要为环境中的加速器购买红帽 AI 加速器订阅:

  1. AI 加速器(一个加速器)
    • 此订阅选项适用于为 AI 工作负载提供计算加速功能的加速卡(GPU、TPU、NPU、FPGA、DPU 等),这些加速卡是独立的附加组件,而不是 CPU 软件包中的一部分。
    • 无论红帽 OpenShift 版本如何,每个物理 AI 加速器都使用相同的订阅。
    • 如果集群上安装了红帽 OpenShift 和 OpenShift AI,那么购买一项 AI 加速器订阅产品就足够了。
    • 只要加速器功能未用于计算加速,则 无需此订阅(比如 DPU 仅用作 SmartNIC 进行网络加速,即使其具有未使用的可寻址 ARM 核心;或 GPU 用于图形渲染而非 AI 加速)。
    • 提供每周五天、每天八小时的标准支持 SLA 选项,或全天候高级支持 SLA 选项。SLA 必须与支持核心对或裸机插槽对订阅的 SLA 匹配。

何时选择核心对订阅

当您在基础架构即服务(IaaS)私有云中将自助式 OpenShift 部署到公共云超大规模云服务商时,或者在 VMware vSphere、红帽 OpenStack® 平台或 Nutanix 等虚拟机监控程序上部署时,您通常会选择核心对订阅。

选择核心对订阅后,您无需将订阅附加到物理服务器,并且还可以拥有很大的灵活性,能够根据需要随时随地在混合云中部署 pod。

您也可以在裸机服务器或设备(即没有虚拟机监控程序)上使用核心对订阅。注意,通常在一定的计算 pod 密度下,裸机插槽对订阅可能更具成本效益。

在将 OpenShift 虚拟化引擎用作专用虚拟化平台时,您可以选择在虚拟机监控程序本身的裸机插槽对订阅之上,使用核心对订阅来为虚拟机上的 OpenShift 容器授权。您可以单独购买 OpenShift 自助式核心对订阅,并将其分配给该环境中的虚拟机,就像您可以购买并作为虚拟机运行的任何其他应用一样。在这种情况下,存在一个核心密度,达到该密度后,切换到自助式 OpenShift 的裸机插槽对订阅模式可能更具成本效益。自助式 OpenShift 的裸机插槽对订阅模式不仅包含在裸机服务器上使用无限量的 OpenShift 容器的权限,还支持在 OpenShift 虚拟机中运行这些容器。

核心对订阅可以进行分发,从而覆盖所有 OpenShift 集群中的所有 OpenShift 计算节点。例如,100 个核心对红帽 OpenShift 平台 Plus 订阅将提供 200 个核心(400 个 vCPU),可用于混合云环境中所有运行的 OpenShift 集群中任意数量的计算节点。

何时选择裸机插槽对订阅

裸机插槽对订阅仅适用于部署到专用物理服务器上的 OpenShift 计算节点,这些物理服务器可以位于数据中心内、受支持的裸机产品上的托管私有云中,也可以在受支持的裸机产品上由超大规模云服务商提供。裸机插槽对订阅是 OpenShift 虚拟化引擎的唯一选择,并且是其他自助式 OpenShift 版本中支持 OpenShift 虚拟化功能所必需的。

每项裸机插槽对订阅最多可为插槽对中的 128 个物理核心授权。裸机订阅可堆叠,既可以用于覆盖总核心数超过 128 个的插槽对,也可以用于覆盖具有多个插槽对的物理服务器。

若要授权物理服务器,可堆叠一个或多个订阅,以覆盖服务器中的插槽总数或物理核心总数(以两者中较多者为准)。例如,一台服务器有两个插槽,且每个 CPU 中有 48 个核心,那么总核心数为 96。由于服务器具有一至两个插槽,核心总数少于 128 个,因此需要一个订阅。第二台服务器具有两个插槽,核心总数为 192 个,因此需要两个订阅。需要两个订阅才能覆盖 192 个核心,因为单个订阅最多只能覆盖 128 个核心。单个裸机插槽对订阅不能进行拆分以用于多台物理主机(不能用于覆盖两台服务器,其中每台具有一个插槽;也不能用于覆盖多台独立服务器上的核心)。

由于 Kubernetes 的固有架构,使用基于插槽授权的每台物理裸机服务器只能用作一个 OpenShift 节点。由于 Kubernetes 中的每个节点只能属于一个集群,这意味着裸机服务器上的所有容器都将位于同一个集群中。这种模式非常适合资源密集型工作负载,如 OpenShift 虚拟化(其中每个工作负载运行一个完整的虚拟机),但可能不适合其他场景。尽管 OpenShift 支持在单个节点上运行多达 2500 个容器,但在某些情况下(无论是出于性能还是架构原因),您可能希望在不同的节点或不同的集群之间分配容器。如果不使用虚拟化技术在裸机服务器上创建单独的计算节点,这将无法实现。

容器的一种常见部署模式是构建大量集群,其中每个集群包含较少数量的容器。这种模式在超大规模云服务商环境中非常普遍,并且可以通过在数据中心内使用虚拟机监控程序创建虚拟机来实现,其中这些虚拟机将成为部署容器的计算节点。在使用 VMware vSphere、红帽 OpenStack 平台和 Nutanix 等虚拟机监控程序时,您必须为部署在虚拟机中的 OpenShift 使用核心对订阅。

部署到裸机和授权插槽对订阅的 OpenShift Kubernetes 引擎、OpenShift 容器平台和 OpenShift 平台 Plus 集群,包含 OpenShift 虚拟化和部署到这些集群中的相同产品类型的任何虚拟 OpenShift 集群的订阅。举例来说,这意味着部署到裸机 OpenShift 容器平台群集的虚拟 OpenShift 群集,将会继承托管裸机群集的 OpenShift 容器平台订阅。

需要注意的是,OpenShift 虚拟化引擎订阅 包括对容器化应用实例的支持,但下文 OpenShift 虚拟化引擎部分定义的基础架构工作负载除外。如果您希望使用 OpenShift 虚拟化引擎运行自己的容器化应用工作负载,您需要使用自助式 OpenShift 的核心对订阅来授权虚拟机。或者,在密度较高的情况下,您可以选择购买自助式 OpenShift Kubernetes 引擎、OpenShift 容器平台或 OpenShift 平台 Plus 的裸机插槽对订阅,这将使您能够在裸机集群或继承订阅的虚拟集群(如上一段中所述)上原生运行基于容器的应用。

在同一集群中无法混合使用不同类型的 OpenShift 产品,所有节点必须使用相同的 OpenShift 虚拟化引擎、OpenShift Kubernetes 引擎、OpenShift 容器平台或 OpenShift 平台 Plus 产品类型进行订阅,然而,在单个集群中可以使用核心对和插槽对订阅。例如,您不能在单个裸机集群中使用一些 OpenShift 虚拟化引擎节点来托管虚拟机,而使用 OpenShift 平台 Plus 订阅的其他节点用于托管容器化应用和虚拟 OpenShift 实例。

如何计算 AI 加速器订阅数量

近年来,市场上出现了一些特定的硬件技术,这些技术能够使某些计算工作负载以更快的速度运行。这些类型的硬件设备在红帽的部分内容中被统称为“加速器”或“AI 加速器”。有几种适用于现代服务器的硬件设备可归类为加速器,包括但不限于 GPU、TPU、ASIC、NPU 和 FPGA。

这些加速器通常是一个卡、面板或其他物理设备,占用服务器中的一个外设组件互连(PCI)插槽。加速器的数量通常与您从加速器供应商处购买的单位数量相同。例如,如果某台服务器的供应商称这台服务器“配备了八个 GPU”,这通常是指八个物理加速器单元。

每个 AI 加速器订阅都涵盖一台物理加速器设备。我们以 AI 加速器订阅为例:

  • 具有四个物理 GPU 设备的物理计算节点,除了需要覆盖计算节点的 CPU 核心对或插槽对订阅外,还需要四个 AI 加速器订阅。
  • 如果单个虚拟计算节点具有一个物理 GPU 设备,并且以多个 vGPU 的形式呈现给虚拟机,则需要一个 AI 加速器订阅,因为订阅计数是基于物理加速器,而不是虚拟加速器。

加速器只有在用于执行计算工作负载时才会被计算在内。当工作负载的主要目的不是近乎实时地在用户屏幕上绘制像素或在网络上传输数据时,该工作负载才会被视为计算工作负载。

这种区分非常重要,因为 VFX(视觉特效)和流媒体应用可能会使用 GPU 和其他加速器硬件,但这些场景的主要目的是在屏幕上绘制像素。在某些情况下,加速器主要功能是在网络上传输数据(例如专用于网络功能的数据处理单元),这也不应视为计算工作负载。

计算工作负载的示例包括:

  • 传统软件应用,如 Java、Python 和 Perl。
  • LLM 或其他计算密集型软件。
  • 数据科学模型训练和调优。
  • 科学建模和物理模拟,比如蛋白质折叠和流体动力学。

不计入订阅的情况

红帽 OpenShift 控制平面和基础架构节点

每个自助式 OpenShift 订阅都包含红帽 OpenShift 和其他 OpenShift 相关组件的授权。OpenShift Kubernetes 引擎、OpenShift 容器平台和 OpenShift 平台 Plus 包含用于计算和基础架构节点的红帽企业 Linux 授权。红帽 OpenShift 虚拟化引擎不支持标准的红帽企业 Linux 工作节点或基础架构节点,仅支持作为 OpenShift 授权一部分的红帽企业 Linux CoreOS 操作系统。

订阅中包含的这些授权用于运行所需的 OpenShift 控制平面和基础架构,但在确定所需的红帽订阅数量时无需计入。

红帽 OpenShift 平台 Plus 订阅还包含对所有节点的管理,具体由红帽 Kubernetes 高级集群安全防护和红帽 Kubernetes 高级集群管理提供。

默认安装会部署一个由三个控制平面节点组成的高可用 OpenShift 控制平面,以及至少两个用于运行最终用户应用的 OpenShift 计算节点。默认情况下,Kubernetes 控制平面组件(比如应用编程接口(API)、服务器、etcd、调度程序)和支持集群服务(比如监控、注册表)将部署在 OpenShift 控制平面节点上。但是,您可以决定将其中一些支持集群服务移动到专用的“基础架构节点”。

要获得作为基础架构节点的资格并使用包含的授权,只有用于支持集群并且不属于最终用户应用的组件才能在这些实例上运行。示例包括:

  • OpenShift 注册表。
  • OpenShift 入口路由器(本地和全局/多集群入口)。
  • OpenShift Observability
  • 用于集群入口的基于 HAProxy 的实例。
  • 红帽 Quay。
  • 红帽 OpenShift 数据基础。
  • 红帽 Kubernetes 高级集群管理。
  • 红帽 Kubernetes 高级集群安全防护。
  • 红帽 OpenShif GitOps。
  • 红帽 OpenShift Pipelines。
  • 红帽 OpenShift 托管控制平面。

您可以向基础架构节点部署和运行自定义及第三方代理和工具,用于监控、日志数据收集和转发、硬件驱动程序、基础架构集成(如虚拟化代理)等,而不会使节点失去基础架构许可的资格。但是,这仅限于代理和相关组件,包括用于 Operator 的控制器 pod,但不包括自定义或第三方软件套件。符合基础架构工作负载资格要求的非红帽软件示例包括:

  • 自定义和第三方监控代理。
  • 容器网络接口(CNI)和容器存储接口(CSI)驱动程序和控制器(插件)。
  • 硬件或虚拟化支持加速器。
  • 用于 Kubernetes 自定义资源定义(CRD)或 operator(自定义或第三方软件)的控制器 pod。

使用包含的授权时,不得在基础架构节点上运行其他最终用户应用实例或类型。若要在红帽 OpenShift 上以应用实例的形式运行其他基础架构工作负载,您必须在具有有效红帽 OpenShift 订阅的常规应用节点上运行这些实例。您可以联系红帽来验证某一应用或服务是否符合基础架构工作负载的资格要求。 

红帽企业 Linux 授权

OpenShift Kubernetes 引擎、OpenShift 容器平台和 OpenShift 平台 Plus 包含用于 OpenShift 计算节点和基础架构节点的红帽企业 Linux 授权。这还包括用于面向应用的授权 pod 和面向虚拟机的客户操作系统授权。然而,红帽 OpenShift 订阅不包含用于红帽企业 Linux 节点的其他授权,以下情况除外:

  • 专门用于裸机安装程序置备的基础架构(IPI)置备的红帽企业 Linux 节点。

OpenShift 虚拟化引擎既 包括用于计算和基础架构节点的红帽企业 Linux,也不包括用于虚拟机客户机操作系统授权的红帽企业 Linux。在 OpenShift 虚拟化引擎上运行红帽企业 Linux 客户机,需要用于虚拟数据中心的红帽企业 Linux 订阅或按虚拟机订阅。

对于 OpenShift 所依赖的外部节点托管服务,比如互联网代理、负载平衡器或镜像注册表,不包含相应的红帽企业 Linux 授权。红帽卫星不包含在授权范围内。

用于对 OpenShift 容器镜像进行镜像的引导容器镜像仓库

OpenShift 的镜像注册表是一项 Quay 授权,专门用于简化为断开连接的 OpenShift 集群提供引导服务所需内容的镜像过程,并作为红帽 OpenShift 订阅的一部分提供。这是一项提供有限支持的授权,适用于由特定安装工具创建的最小 Quay 部署,允许您在预置备且由客户管理的红帽企业 Linux 主机上运行 Quay 注册表。

注意:您可以将 Quay 用作注册表镜像,但仅限于镜像 OpenShift 发行版有效负载、OperatorHub 内容、示例 Operator 镜像、Cincinnati 图表镜像以及与红帽 OpenStack 平台产品(包括 OpenShift 上的红帽 OpenStack 服务和红帽 OpenShift 数据基础)相关的镜像。

OpenShift 镜像注册表 并非能以任意规模运作的普通用途注册表。不过,允许在此存储有限的自定义镜像集,其中包含所需的辅助软件,比如适用于符合条件的基础架构工作负载的代理和容器镜像。示例包括:

  • 监控代理。
  • CNI 和 CSI 提供程序。
  • 硬件或虚拟化支持代理。
  • 支持独立软件供应商(ISV)服务的 Operator。
  • 作为部署控制器的自定义 Operator。

托管控制平面

经典的 OpenShift 基础架构要求每个 OpenShift 集群至少具有 3 个控制平面节点。另一种选择是使用托管控制平面,其中控制平面在中央控制平面集群上运行,并为 OpenShift 集群提供逻辑控制平面。与以往一样,控制平面节点和基础架构节点不计入订阅,但在架构中需要加以考虑。

托管控制平面可以在任何裸机 OpenShift 集群上运行,但这些集群的计算节点需要与运行它的基础架构一致的授权。例如,托管在 OpenShift 虚拟化引擎上的虚拟集群需要计算节点的核心对订阅,而控制平面由 OpenShift 虚拟化引擎集群托管且使用裸机计算节点的集群则需要裸机插槽对订阅。

例外情况 1:如果您选择在控制平面或基础架构节点上运行应用实例

OpenShift 控制平面节点默认不用作计算节点,因此不会运行应用实例。控制平面节点是否需要完整的红帽 OpenShift 订阅,取决于它是仅运行支持性的 OpenShift 集群组件还是运行最终用户应用。如果您选择将控制平面节点用作托管任何最终用户应用的节点,则需要为所有核心订阅。查看“基础架构节点”部分,了解如何识别不需要订阅的合格工作负载。

例外情况 2:精简集群部署

在像三节点 OpenShift 这样的精简集群部署中,最终用户应用工作负载会在控制平面节点上运行。无论这些节点有何作用,您都需要为这三个节点上的核心计算红帽 OpenShift 订阅数量。

单节点 OpenShift 实例将所有 OpenShift 服务和最终用户应用部署到单个物理或虚拟节点上,并通过优化减少占用空间并实现应用可用资源最大化。与上文中的三节点精简集群一样,这种部署模式没有特殊考量,节点上的所有核心都需要获得授权。

特殊用例

灾难恢复

红帽定义了三种类型的灾难恢复(DR)环境:热备份、温备份和冷备份。仅热备份 DR 需要付费红帽 OpenShift 订阅。

  • 热备份 DR 系统是指功能齐全且与生产系统同时运行的系统。它们随时准备好在主要环境发生灾难时立即接收流量并接管工作。当数据卷在集群之间以同步或异步方式主动进行复制时,这些系统被视为“热备份”DR 系统。
  • 温备份 DR 系统是指已准备好部署和托管容器化工作负载的系统,这些系统是主站点中系统的合理复制版,但不包含源集群上的客户工作负载。温备份 DR 系统不应参与集群之间同步或异步的活动数据卷复制。温备份 DR 需要将客户的数据从集群外部恢复到现有的集群硬件上。
  • 冷备份 DR 系统是指具有适当的基础架构,但没有还原服务所需的全部技术(硬件、软件、数据)的系统。

未明确配置和设计用于温备份或冷备份 DR 的休眠集群需要订阅,比如在云服务上运行且因需求较低而暂时休眠的集群。当温备份或冷备份 DR 集群退出休眠状态以运行工作负载时,需要订阅。如果使集群暂时退出休眠状态以进行日常维护或测试,则不需要额外订阅 OpenShift 软件产品中的任何组件。

对于温备份和冷备份 DR,当灾难发生时,红帽 OpenShift 订阅可以从主环境转移到 DR 环境,从而快速恢复服务并保持遵守红帽的订阅条款。

迁移和 swing 升级

红帽 OpenShift 4 提供了次要版本就地升级功能。然而,如果您要从红帽 OpenShift 3 升级,或由于维护时段或其他考虑因素而需要在 OpenShift 4 次要版本之间执行 swing 升级,您的红帽 OpenShift 订阅将涵盖单向迁移的原始和目标基础架构,直到迁移完成。在迁移过程中,根据您购买的红帽 OpenShift 订阅数量,红帽的订阅管理工具可能会显示您的环境不合规。红帽允许在主要版本升级过程中出现这种情况,并且不会要求购买额外的订阅以在迁移期间恢复合规状态。最后,红帽 OpenShift 提供工具来协助完成这些迁移,如果需要的话,还提供红帽咨询服务。具体信息请参阅关于 容器迁移工具包的文档。

针对启用超线程技术的核心的授权

要确定某个特定 OpenShift 节点是否使用一个或多个物理核心,主要取决于该系统是否启用了每个核心的多个线程。 了解如何确定特定系统是否支持超线程。

使用逻辑 CPU 线程的虚拟化 OpenShift 节点(对于 AMD EPYC CPU,也称为“同步多线程(SMT)”;对于英特尔 CPU,也称为“超线程”),基于分配给节点的核心/CPU 数量,计算其红帽 OpenShift 订阅的核心利用率。然而,当使用逻辑 CPU 线程时,每个订阅涵盖四个 vCPU/核心。红帽的订阅管理工具假定所有系统上都默认启用了逻辑 CPU 线程。

裸机订阅只计算物理核心,计算裸机所需的订阅数量时不计算逻辑 CPU 线程。

替代架构(ARM、IBM Z、IBM LinuxONE、IBM Power)

注意:虽然本文档从此处开始仅提及 IBM Z,但所有提及 IBM Z 的信息也适用于 IBM LinuxONE。

对于使用这些平台作为构建和部署云原生应用和微服务标准的客户来说,红帽 OpenShift 容器平台还可以在 ARM、IBM Z 和 IBM Power 上运行。对于 IBM Z 和 IBM Power 平台,仅支持基于核心的订阅模式。

ARM 集群按照与 x86 相同的规则来授权。

对于 IBM Z 客户,红帽 OpenShift 不要求整个物理节点获得授权,只需要 OpenShift 使用的核心获得授权。IBM Z 客户将此称为“子容量”授权。如果客户仅在其 IBM Z 环境中使用 OpenShift 容器平台的一部分可用核心(计算容量),则只需要为用于计算节点的这一部分核心获取订阅即可。无论通过何种方式实现 CPU 分区(通过 CPU 池化、上限、单独的逻辑分区(LPAR)或其他方法),这种授权方式均适用。

对于 IBM Z,一个 Linux 集成设施(IFL)需要一个 OpenShift 核心对订阅。当未使用分区时,每个 OpenShift 集群最多可以为主机上运行的控制平面或基础架构服务识别三个 IFL。这些 IFL 必须实际用于控制平面和/或基础架构服务才能符合条件,并且不需要 OpenShift 订阅授权。三节点精简集群部署要求所有 IFL 都获得授权。

目前,IBM Z 和 IBM Power 不支持 OpenShift 容器平台以外的红帽 OpenShift 平台 Plus 组件,但以下情况除外:

  • 在 x86 架构上运行的独立红帽 Quay 订阅可以为包括 IBM Z 和 IBM Power 集群在内的多种架构提供全局镜像仓库。红帽 Quay 本身不会在 IBM Z 或 IBM Power 上运行。
  • 红帽 Kubernetes 高级集群管理可以安装到 IBM Z 或 IBM Power 环境中,用于管理 IBM Z 或 IBM Power 环境中运行的红帽 OpenShift 节点。
  • 借助红帽 Kubernetes 高级集群安全防护,您可以通过红帽高级集群安全防护 Operator 保护在 IBM Z 或 IBM Power 上运行的红帽 OpenShift 集群。
  • 红帽 OpenShift 数据基础完全支持在 IBM Z 或 IBM Power 上进行安装。

红帽 OpenShift 平台 Plus 订阅组件对替代(非 x86)架构具有不同程度的支持。具体请参阅 红帽 OpenShift 容器平台 4.16 多架构组件可用性矩阵一文。如需详细了解 OpenShift 平台 Plus 组件与非 x86 架构之间的互操作性,请参阅 红帽 OpenShift 容器平台、 红帽高级集群管理、 红帽高级集群安全防护、 红帽 Quay 和 红帽 OpenShift 数据基础的兼容性矩阵。

IBM Z 和 IBM Power 不支持红帽 OpenShift Kubernetes 引擎和红帽 OpenShift 虚拟化引擎。

Microsoft Windows Server 容器支持

自助式红帽 OpenShift 支持利用 Microsoft Windows Server 容器运行部分 OpenShift 功能和通过部分方式安装基础架构。Windows Server 容器仅在基于 Microsoft Windows Server 的计算节点上受支持。OpenShift 环境的控制平面和基础架构平面必须在使用红帽企业 Linux 或红帽企业 Linux CoreOS 的 x86 基础架构上运行。因此,Windows Server 容器支持作为独立订阅出售,并按核心定价。

红帽 OpenShift 平台 Plus 和红帽 OpenShift 容器平台基础架构可用于部署和管理 Windows Server 计算节点。适用于红帽 OpenShift 订阅的 Microsoft Windows Server 容器支持服务,必须作为单独的附加组件购买。

红帽高级集群管理和红帽高级集群安全防护不支持管理 Microsoft Windows 节点,但在 x86 架构上运行的红帽 Quay 可以管理基于 Microsoft Windows Server 工作负载的容器镜像。

每种情况各不相同,这些仅作为指导,而非保证

红帽 OpenShift 支持许多功能,它们可能会影响可扩展性、pod 调度、闲置和资源配额/限制功能。前面的计算方法仅作为指导,您可以调整实际环境,以更好地利用资源或缩小总体环境规模。OpenShift 平台 Plus 客户应考虑其他软件应用(红帽高级集群管理、红帽高级集群安全防护和 Quay)的需求,包括存储和计算资源,即使它们可能不需要额外的计算订阅。

如果与第三方经销商合作,请参阅第三方经销商针对红帽产品和服务的具体条款和协议。 

红帽 OpenShift 平台 Plus 组件支持

红帽 OpenShift 平台 Plus 包括 OpenShift 容器平台之外的其他软件,可帮助您跨多个集群和多个云大规模管理和保护 OpenShift 环境。红帽 OpenShift 平台 Plus 提供核心对订阅模式和裸机插槽对订阅模式,但存在前文所述的限制。

红帽 OpenShift 平台 Plus 附带的额外软件通常仅限于管理通过 OpenShift 平台 Plus 订阅授权的节点。例如,OpenShift 平台 Plus 附带的红帽高级集群管理订阅仅可用于管理 OpenShift 平台 Plus 授权节点和集群。如果客户还希望管理非 OpenShift 平台 Plus 授权节点和集群,例如 AWS 集群上的红帽 OpenShift 服务,则需要购买额外的红帽高级集群管理附加订阅来覆盖这些集群。

额外的软件订阅也必须与 OpenShift 平台 Plus 订阅一同使用。例如,您不能购买 100 个 OpenShift 平台 Plus 订阅,安装 200 个核心的红帽 OpenShift 容器平台订阅,再单独使用红帽高级集群管理对使用相同订阅的 200 个 Azure 红帽 OpenShift 核心进行管理。 附加软件只能用于管理安装核心 OpenShift 平台 Plus 软件的相同的 200 个核心。

每种分层产品的特定规则:

  • 红帽 Kubernetes 高级集群管理: OpenShift 平台 Plus 订阅允许您根据需要安装任意数量的红帽高级集群管理中心实例来管理自己的环境,并覆盖通过 OpenShift 平台 Plus 授权的所有节点和集群的管理,包括控制平面和基础架构节点。如果您想要在没有 OpenShift 平台 Plus 授权的情况下管理节点和集群(例如,您还拥有自助式 OpenShift 容器平台或红帽 OpenShift Kubernetes 引擎授权集群、在完全托管的 OpenShift 云中运行的集群,或红帽高级集群管理支持的第三方 Kubernetes 环境),那么您需要购买红帽高级集群管理附加组件订阅来覆盖这些环境。您可以根据需要选择从安装在 OpenShift 平台 Plus 上的红帽高级集群管理控制台集中管理,或者从单独的中央应用集中管理。 进一步了解红帽高级集群管理订阅、红帽高级集群管理支持的环境,以及红帽高级集群管理最佳实践。
  • 红帽 Kubernetes 高级集群安全防护: OpenShift 平台 Plus 订阅允许您根据需要安装任意数量的红帽高级集群安全防护中央应用来管理自己的环境,并覆盖通过 OpenShift 平台 Plus 授权的所有节点和集群的管理,包括控制平面和基础架构节点。如果您想要在没有 OpenShift 平台 Plus 授权的情况下管理节点和集群(例如,您还拥有自助式 OpenShift 容器平台或 OpenShift Kubernetes 引擎授权集群、在完全托管的红帽 OpenShift 云中运行的集群,或红帽高级集群安全防护支持的第三方 Kubernetes 环境),那么您需要购买红帽高级集群安全防护附加组件订阅来覆盖这些环境。红帽建议的做法是,使用单独的红帽高级集群安全防护中央应用来管理每个环境。 进一步了解红帽高级集群安全防护支持的环境。
  • 红帽 Quay:OpenShift 平台 Plus 订阅允许您在具有 OpenShift 平台 Plus 授权的任何集群上安装红帽 Quay。安装到 OpenShift 平台 Plus 集群的 Quay 部署数量没有限制。因此,Quay 可以提供您希望的任何受支持的 Kubernetes 环境,包括 OpenShift 平台 Plus 环境、其他自助式 OpenShift 集群、托管式 OpenShift 服务以及支持的第三方 Kubernetes。如果您希望在非 OpenShift 平台 Plus 环境中安装 Quay,需要购买单独的红帽 Quay 订阅。红帽 Quay 还可作为全托管式 软件即服务(SaaS)产品提供。
  • 红帽 OpenShift 数据基础。OpenShift 平台 Plus 订阅允许您在具有 OpenShift 平台 Plus 授权的任何集群上安装红帽 OpenShift Data Foundation Essentials。红帽数据基础授权仅限于 Essentials 中可用的功能,每个 OpenShift 集群的数据存储上限为 256TB。您可以通过附加订阅来扩展功能和容量。请参阅《OpenShift 数据基础订阅指南》(需要登录客户门户),或咨询红帽销售代表来获取进一步指导。

红帽 OpenShift 虚拟化引擎和相关产品

OpenShift 虚拟化长期以来一直是所有自助式 OpenShift 版本中包含的功能,使客户能够将虚拟机工作负载纳入云原生应用,并将虚拟机现代化为微服务和容器。

虚拟化市场的最新变化使人们对替代虚拟化平台的需求增加,尤其是那些提供现代化路径的平台。许多客户在最初迁移虚拟机时并不需要 OpenShift 的所有功能,他们更愿意针对这些用例使用简化且成本更低的自助式 OpenShift 替代版本。

红帽 OpenShift 虚拟化引擎是自助式 OpenShift 的一个版本,专门针对那些希望使用替代虚拟化平台来运行虚拟机的客户。OpenShift 虚拟化引擎通过受支持的物理服务器和受支持的超大规模云服务商裸机实例上的裸机插槽对订阅进行授权。

OpenShift 虚拟化引擎仅包含部署、管理和运行虚拟机所需的功能,例如:

  • 在已订阅的主机上运行无限量的虚拟机。
  • 不能用于在容器中运行应用实例(如商业软件或客户应用),仅支持虚拟机。
  • 不包括在虚拟机内运行任何红帽 OpenShift 版本的订阅(需要单独购买核心对订阅)。
  • 不包含虚拟机的红帽企业 Linux 客户机授权(需要单独购买用于虚拟数据中心的红帽企业 Linux 订阅或按虚拟机订阅)。

红帽现在有两个适用于 OpenShift 虚拟化引擎的附加产品。

  • 红帽虚拟化高级集群管理支持虚拟化和虚拟机监控程序生命周期管理及运维,与完整版本的高级集群管理相比,成本更低(每个 OpenShift 虚拟化引擎订阅需要一个订阅)。
  • 面向虚拟化的红帽 Ansible® 应用平台为运行 OpenShift 虚拟化引擎的虚拟机监控程序节点提供支持,用于迁移和 Day 1 运维(每个 OpenShift 虚拟化引擎订阅需要一个订阅)。

对于现有的高级集群管理和 Ansible 应用平台客户,您可以使用这些中央应用的现有安装来支持环境的其余部分,并通过购买上文提及的附加组件订阅来管理 OpenShift 虚拟化引擎主机。

对于尚未安装高级集群管理或 Ansible 应用平台中央应用的客户,您购买的上述附加组件订阅还支持将中央应用作为基础架构容器安装到 OpenShift 虚拟化引擎主机上。若要了解如何安装这些中央应用以及架构的最佳实践,请参阅高级集群管理或 Ansible 应用平台相关文档。

对于需要为其虚拟机进行 Day 2 自动化的客户,建议使用 Ansible 自动化平台。除了上面列出的虚拟机监控程序节点订阅外,客户还需要为每个虚拟机实例购买节点订阅。若要了解更多相关信息,请参阅 Ansible 自动化平台文档。

虽然 OpenShift 虚拟化引擎的授权将客户应用实例限制为仅虚拟机,但许多基础架构需求(如存储驱动程序、备份应用、转发代理、高级集群管理和 Ansible 自动化平台)在红帽 OpenShift 中作为基础架构容器运行。因此,您的授权确实能够让您在容器中运行这些基础架构功能。此外,为虚拟机提供存储空间但自身在容器中运行的软件定义存储解决方案也包含在授权中。关于哪些内容符合这些基础架构容器的指导原则,与红帽 OpenShift 其他版本的基础架构节点上允许的工作负载相同。有关基础架构节点的相关信息,请参阅“不计入订阅的情况”部分。您可以联系红帽来验证某个应用或服务是否符合 OpenShift 虚拟化引擎的基础架构工作负载的资格要求。

如何确定自助式 OpenShift 环境的规模

要确定您需要多少自助式 OpenShift(红帽 OpenShift 平台 Plus、红帽 OpenShift 容器平台或红帽 OpenShift Kubernetes 引擎)或附加组件订阅,请参考以下问题和示例。

总结:

  • 应用打包在容器镜像或虚拟机中。
  • 容器和虚拟机部署为 pod。
  • pod 运行在由 OpenShift 控制平面节点管理的 OpenShift 计算节点上。

如何估算您的授权要求

红帽 OpenShift 订阅不限制应用实例。只要底层硬件和基础架构支持,您可以在红帽 OpenShift 环境中运行任意数量的应用实例。容量较大的硬件可以在少量主机上运行多个应用实例,而容量较小的硬件则需要许多主机来运行多个应用实例。决定红帽 OpenShift 环境规模的主要因素是在任何特定时间将运行多少个 pod 或应用实例。

第 1 步:确定所需应用实例的数量和类型

从应用开始。确定计划部署的应用实例或 pod 的数量。估算环境规模时,部署在红帽 OpenShift 上的任何应用组件(如数据库、前端静态服务器或虚拟机实例)都将被视为应用实例。

这个数字可以是一个近似值,用于帮助您粗略估算红帽 OpenShift 环境的规模。CPU、内存超额订阅、配额和限制以及其他功能可用于进一步优化此估计值。

表 1:应用和实例规模问题

 

相关问题

示例答案

  • 您预计在每个红帽 OpenShift 环境中部署多少个应用实例?
  • 它们是什么类型的应用(例如语言、框架、数据库)?
  • 对于虚拟机工作负载,虚拟机的标准配置是什么?虚拟机是全部自定义的,还是按应用标准化的?虚拟机的要求是什么?
  • 我们的开发环境中有大约 1,250 个应用实例,生产环境中则有大约 250 个应用实例。
  • 我们主要部署的是 Java,但也有一些 Microsoft.NET Core 和 Ruby 应用。我们还使用了 MySQL。
  • 我们的虚拟机平均需要四个 vCPU 和 8 GB 内存
  • 我们的容器平均需要两个 vCPU 和 2 GB 内存

 

第 2 步:确定所需的总内存和总核心数

一旦确定了一个应用实例的需求和应用实例的数量,就可以轻松确定计算和内存所需的资源总量。

此时,您应该确定计算节点要达到的最大利用率。这应该为 OpenShift 的管理开销留出空间(有关更多信息,请参阅相关文档,但通常每个计算节点需要一个核心或一个 vCPU 以及 <1 GB 的读取访问内存(RAM)),并在需要自动扩展之前允许应用的正常变化。如果您假设采用较高的利用率(超过 80%),则可能需要在计算内存和核心资源时考虑 OpenShift 开销方面的需求。

对于虚拟化用例,您需要考虑 CPU 和内存过量使用、冗余和高可用性问题以及环境的整体架构。我们将在与规模相关的示例 3 中进行说明。

表 2:偏好的最大 OpenShift 节点利用率问题

 

相关问题

示例答案

我需要预留多少空间以备需求增加?

我们希望以总容量的 80% 为平均上限(保留 20%)来运行节点。

 

最大利用率 = 架构师所选的百分比

所需总核心数(或 vCPU)= “1 个应用所需核心数” × “应用实例数量” × 1 /“利用率百分比”

所需总核心数 =“1 个应用所需核心数” × “应用实例数量” × 1 /“利用率百分比”

第 3 步:选择标准计算节点(虚拟机、云实例或裸机服务器)

现在,您已经得出了需要容纳的总核心数和内存量。现在,您必须选择一个标准计算节点来部署应用的工作节点。

在虚拟化基础架构中,您的环境可能允许您选择将要用作计算节点的虚拟机的配置,或者您可能需要从几种标准的“T恤尺寸”虚拟机类型中选择一种。

在超大规模云服务商的云环境中,您通常需要选择一种具有不同计算能力、内存大小且可访问可选设备(如 AI 加速器)的云实例类型。

如果您在裸机上部署(无论是在本地还是在超大规模云服务商的裸机实例中),您可能会有一个标准的服务器配置,有时还可以指定配置。

您应尽可能选择最符合您的核心需求和内存需求比率的计算节点。例如,如果我对容器的总需求是 400 个 vCPU 和 1600 GB 内存,那么我可以选择 vCPU 与内存比率约为 1:4 的计算节点,从而获得最佳的平均整合率。 

表 3:虚拟机和硬件规模问题

 

相关问题

示例答案

  • 将用于节点的虚拟机的内存容量是多少?
  • 将用于节点的虚拟机的 vCPU 数量是多少?

     
  • 是否使用超线程?
  • 正在使用的 AI 加速器数量有多少?
  • 我们的虚拟机有 64 GB 内存和四个 vCPU,并且使用超线程。
  • 在我们的数据中心内,我们可以为容器工作负载自定义虚拟机。
  • 我们使用 Amazon EC2,并且可以使用 M6i 和 M7i 实例类型。
  • 我们的裸机系统具有 128 GB 内存、两个 CPU 插槽(64 核),使用了超线程技术,并配备了一个 GPU。

 

第 4 步:计算所需的总订阅数

最后,根据步骤 1-3 中收集的数据确定所需的红帽 OpenShift 订阅数。对于虚拟机或超大规模云服务商云实例的订阅,必须使用核心对订阅模式。对于裸机服务器,您应使用两种模式计算订阅数量,比较每种模式在成本和灵活性方面的差异,并选择最符合您需求的模式。

对于核心对订阅模式

  • 自助式 OpenShift 核心对订阅数量
    = 总核心数 / 2,四舍五入 
    = 总 vCPU 数 / 4,四舍五入

对于裸机插槽对订阅模式

  • 首先,计算应用所需的核心对订阅数量,因为您可以在裸机安装中使用核心对模式。
  • 其次,计算裸机核心对订阅数量,方法如下:
    • 裸机服务器数量 = 
      以下两项中的最大值:
      • 所需总核心数 / 每个裸机服务器模型的核心数,四舍五入至下一个整数
      • 所需总内存 / 每个裸机服务器模型的内存量,四舍五入至下一个整数。
    • 每个裸机服务器所需的裸机核心对订阅数量 =
      如果您的裸机服务器有 1-2 个插槽:
    • 每个裸机服务器模型的核心数 / 128 个核心或 256 个 vCPU,四舍五入至下一个整数。
      如果您的裸机服务器有>两个插槽:
      • 每个裸机服务器模型的核心数/(128 X 插槽对数),四舍五入至下一个整数。
    • 每个插槽对至少需要一个订阅,您可以堆叠订阅以满足总插槽数和总核心数。
    • 订阅可以跨插槽,但不能跨服务器。
  • 第三,比较两种模式在成本和灵活性方面的差异。
    • 财务方面:
      • 对于您调整过规模的环境,一种订阅模式可能会比另一种更便宜。
      • 在规划未来时,可能会有一个盈亏平衡容量点,超过该阈值后,另一种模式在财务方面更具优势。
    • 架构方面:
      • 核心对订阅可以在您环境中的任意位置使用(虚拟机、云实例、裸机服务器),而裸机插槽对订阅只能用于裸机服务器。
      • 裸机服务器上的核心对订阅必须在裸机上运行容器,并且必须在同一个集群中。
      • 您可以选择在裸机服务器上安装 OpenShift 虚拟化引擎,然后在上面运行核心对 OpenShift 订阅以支持容器(在 OpenShift 中运行 OpenShift)。对于每台服务器上 OpenShift 数量相对较少的混合虚拟机环境,这种方案是最佳之选。
      • 如果您需要在裸机服务器上运行高密度的 OpenShift 工作负载,选择裸机插槽对订阅可以让您直接在裸机上或通过 OpenShift 虚拟化功能在服务器上运行的虚拟机内运行无限量的 OpenShift 容器。

第 5 步:计算 AI 加速器订阅总数(如适用)

将上述所有 AI 加速器订阅相加。您需要为本地或裸机服务器上的每个物理加速器购买一个 AI 加速器订阅。在超大规模云服务商的云环境中,加速计算实例类型会列出该实例类型中包含的物理 GPU 或加速器数量。请确保 AI 加速器订阅的服务级别协议(SLA)与相应的红帽 OpenShift 订阅匹配。

注意:红帽 OpenShift 支持许多功能,它们可能会影响可扩展性、pod 调度、闲置和资源配额/限制功能。前面的计算方法仅作为指导,您可以调整实际环境,以更好地利用资源或缩小总体环境规模。OpenShift 平台 Plus 客户应考虑其他软件应用(红帽高级集群管理、红帽高级集群安全防护和 Quay)的需求,包括存储和计算资源,即使它们可能不需要额外的计算订阅。

如果与第三方经销商合作,请参阅第三方经销商针对红帽产品和服务的具体条款和协议。 

示例 1:在超大规模云服务商云中运行的容器化应用

我们有一个由 200 个容器实例组成的应用,每个实例平均消耗一个 vCPU 和 4 GB 内存。我们偏好的最大利用率为 80%。我们在 AWS 上运行应用,并且可以使用 EC2 M6i 实例类型。我们的应用不需要任何特定的硬件或 AI 加速器。我们已选择红帽 OpenShift 平台 Plus 作为自助式版本,目前我们只需要估算所需的订阅数量。

第 1 步:确定所需应用实例的数量和类型

根据示例中的信息:

  • 应用实例数 = 200
  • 偏好的最大节点利用率 = 80%
  • 平均应用 vCPU 需求 = 1 个 vCPU
  • 平均应用内存占用量 = 4 GB

第 2 步:确定所需的总内存和总核心数

在计算中使用步骤 1 中的数字:

  • 最大利用率 = 80%
  • 所需的总 vCPU 数 = 1 个 vCPU X 200 X 1/80% = 250 个 vCPU
  • 所需的总内存 = 4 GB X 200 X 1/80% = 1,000 GB

第 3 步:选择标准计算节点

根据所提供的信息,我们不需要带有 GPU 或专用硬件的实例类型。我们的 vCPU 与内存的比率为 250 个 vCPU:1,000 GB,即 1:4。在分析了我们的应用所需的其他因素后,我们确定 m6i.4xlarge 实例类型最符合我们的需求。每个实例都有 16 个 vCPU 和 64 GB内存。

第 4 步:计算所需的总订阅数

在本例中,我们知道我们需要核心对订阅,因为我们在超大规模云服务商的云环境中运行,并且我们超大规模云服务商的云环境中使用的是 vCPU,因此我们使用步骤 2 中的核心对订阅公式。

核心对订阅总数 = 所需的 vCPU 总数 / 4,四舍五入

250 个 vCPU / 4 = 62.5,四舍五入为 63

第 5 步:计算 AI 加速器订阅总数(如适用)

在此规模估算示例中,我们未使用 AI 加速器,因此该步骤不适用。

结果

对于此示例 1,需要63 个 OpenShift 平台 Plus 核心对订阅

示例 2:在本地裸机上运行的容器化应用

我们现在希望在本地裸机上运行相同的应用,并使用红帽 OpenShift 内置的 OpenShift 虚拟化功能将该应用置备到虚拟机计算节点中。该应用由 200 个容器实例组成,每个实例消耗一个 vCPU 和 4 GB 内存。我们偏好的最大利用率为 80%。我们的应用不需要任何特定的硬件或 AI 加速器。我们已选择红帽 OpenShift 平台 Plus 作为自助式版本,目前我们只需要估算所需的订阅数量。我们在裸机配置方面具有一定的选择灵活性,但我们使用的是标准的现成服务器配置。

第 1 步:确定所需应用实例的数量和类型

根据示例中的信息:

  • 应用实例数 = 200
  • 偏好的最大节点利用率 = 80%
  • 平均应用 vCPU 需求 = 1 个 vCPU
  • 平均应用内存占用量 = 4 GB

第 2 步:确定所需的总内存和总核心数

在计算中使用步骤 1 中的数字:

  • 最大利用率 = 80%
  • 所需的总 vCPU 数 = 1 个 vCPU X 200 X 1/80% = 250 个 vCPU
  • 所需的总内存 = 4 GB X 200 X 1/80% = 1,000 GB

第 3 步:选择标准计算节点

我们当前的裸机服务器标准是:一个双插槽服务器,每个插槽有 32 个核心/64 个 vCPU。我们可以选择内存容量。由于 vCPU 与内存的比率为 1:4,因此我们将为服务器配备 256 GB 内存。因此,我们选择的裸机服务器是双插槽服务器,每个插槽有 32 个核心/64 个 vCPU(每台服务器 64 个核心/128 个 vCPU)和 256 GB 内存。

第 4 步:计算所需的总订阅数

在裸机服务器上,我们可以选择核心对订阅或裸机插槽对订阅。我们分别计算上述两种订阅模式:

核心对订阅总数 = 所需的 vCPU 总数 / 4,四舍五入

250 个 vCPU / 4 = 62.5,四舍五入为 63

插槽对订阅总数 =

  • 所需服务器总数 = 250 个 vCPU / 每台服务器 128 个 vCPU,四舍五入 = 2 台服务器
  • 每台服务器所需的订阅总数 = 每个插槽对的核心数 / 128,四舍五入 = 64/128 = 0.5 四舍五入为 1 个订阅
  • 2 台服务器 x 1 个订阅/服务器 = 2 个裸机插槽对订阅

在此例中,我们能够选择一台服务器来提供合适的 vCPU 与内存比率,因此无需计算满足内存需求所需的服务器数量,而是取两者中的较大值。如果我们选择的服务器内存容量不同,则需要考虑这一差异。

第 5 步:计算 AI 加速器订阅总数(如适用)

在此规模估算示例中,我们未使用 AI 加速器,因此该步骤不适用。

结果

对于此示例,需要 63 个 OpenShift 平台 Plus 核心对订阅或 2 个裸机插槽对订阅 。您应考虑财务和架构因素,选择最符合您需求的方案。 

示例 3:仅虚拟机环境

我们正在将虚拟机从其他虚拟机监控程序转移到红帽。这是一个混合环境,但我们已确定以下不同规模的虚拟机数量:

  • 1,000 个小型虚拟机 = 1,000 个 vCPU,4,000 GiB 内存。外加 228 GiB 内存开销
  • 300 个中型虚拟机 = 600 个 vCPU,2,400 GiB 内存。外加 73 GiB 内存开销
  • 200 个大型虚拟机 = 800 个 vCPU,4,800 GiB 内存。外加 58 GiB 内存开销
  • 200 个超大型虚拟机 = 1,600 个 vCPU,9,600 GiB 内存。外加 64 GiB 内存开销

第 1 步:确定所需应用实例的数量和类型

根据示例中的信息:

  • 应用实例数 = 1,700
  • 总 vCPU 数 = 4,000 个 vCPU
  • 总内存 = 20,800 GB + 423 GB 开销 = 21,223 GB
  • 平均应用 vCPU 需求 = 2.4 个 vCPU
  • 平均应用内存占用量 = 12.5 GB

第 2 步:确定所需的总内存和总核心数

在计算中使用步骤 1 中的数字:

  • 所需的总内存 = 20,800 GB + 423 GB 开销 = 21,223 GB
  • 所需的总 vCPU 数 = 4,000 个 vCPU

对于虚拟机,最大利用率指标的计算方式与容器略有不同,但虚拟化管理员应该对此不陌生。

通常,我们不建议对虚拟机进行内存超额分配,因此总内存需求通常是计算节点数量的主要决定因素。

对于计算资源,我们预计会出现 CPU 超额分配,因为平均而言,大多数虚拟机不会使用其所有计算资源。OpenShift 虚拟化的最大 CPU 超额分配比率设置为 10:1,因此选择 4:1 之类的比率是相对保守的。在这里,我们还可以选择是将核心还是线程(在超线程支持下,每个核心可以是两个线程)视为一个 vCPU。我们可以保守地选择一个 vCPU = 1 个核心,并且不使用超线程。现在,我们的需求如下:

  • 所需的总内存 = 20,800 GB + 423 GB 开销 = 21,223 GB
  • 所需的总核心数 = 4,000 个 vCPU x 1/4 x 1 个核心/vCPU = 1,000 个核心

第 3 步:选择标准计算节点

选择用于虚拟化的裸机计算节点取决于许多因素,包括冗余和故障域、集群大小等。在本地,我们有一些选择,包括增加每台服务器的内存。由于内存通常是服务器需求的主要决定因素,我们可以从此处着手。

我们有 1,700 个虚拟机,并选择了一台双插槽服务器,每个插槽有 32 个核心。如果我们使用核心数来确定服务器数量,则需要:

  • 1,000 个核心 / 64 个核心/服务器,四舍五入 = 16 台服务器

对于 16 台服务器,我们需要 21,223 GB / 16 台服务器 = 每台服务器 1,326 GB 内存。我们的服务器可以选择 1,536 GB 内存。现在,我们的裸机配置为:

  • 双插槽服务器,每个插槽 32 个核心(总共 64 个核心),1,536 GB 内存

最终,针对 16 台采用此配置的服务器计算得出的结果如下:

  • 16 × 64 个核心 = 1,024 个核心
  • 16 × 1,536 GB = 24,576 GB 内存

这足以运行虚拟机负载,但我们需要额外的服务器以确保具备冗余能力。目前,我们无法承受任何一台服务器停机或性能严重下降造成的影响。我们的虚拟化管理员建议我们保留 25% 的备用容量,以确保具备故障转移和冗余的能力。因此,我们需要:

  • 16 台服务器 +(16 台服务器 * 25%)= 总共 20 台服务器

我们将虚拟机分布在所有 20 台服务器上,这样即使我们丢失 1-4 台服务器,仍能够满足虚拟机的需求(您的弹性需求可能有所不同)。

第 4 步:计算所需的总订阅数

对于仅虚拟化的用例,我们使用 OpenShift 虚拟化引擎,它仅适用于裸机插槽对订阅。

插槽对订阅总数 =

  • 所需服务器总数 = 20
  • 每台服务器所需订阅总数 = 1 个(因为我们的服务器最多包含 64 个核心/插槽对)
  • 20 台服务器 x 1 个订阅/服务器 = 20 个裸机插槽对订阅

第 5 步:计算 AI 加速器订阅总数(如适用)

在此规模估算示例中,我们未使用 AI 加速器,因此该步骤不适用。

结果

针对此示例,需要 20 个 OpenShift 虚拟化引擎裸机插槽对订阅。 

附录 1:自助式 OpenShift 版本及其所含功能

表 1:红帽 OpenShift 各版本的整体功能差异

功能

红帽 OpenShift Kubernetes 引擎

红帽 OpenShift 容器平台

红帽 OpenShift 平台 Plus

红帽 OpenShift 虚拟化引擎

管理员 Web 控制台

认证集成、基于角色的访问权限控制(RBAC)、安全环境限制(SCC)、多租户许可控制器

自动扩展(群集和 pod)

集群监控

成本管理 SaaS 服务

面向开源容器运动(OCI)兼容运行时的 Kubernetes 容器运行时接口(CRI)(或简称“CRI-O 运行时”)

企业级安全 Kubernetes

全自动安装程序

kubectl 和 oc 自动化命令行

OpenShift 虚拟化

Operator 生命周期管理(OLM)

无线智能升级

机密管理

存储驱动程序

用户提供的虚拟机工作负载

红帽 OpenShift GitOps

仅适用于虚拟机用例

仅适用于虚拟机用例

平台日志记录

仅适用于虚拟机用例

仅适用于虚拟机用例

用户工作负载监控

仅适用于虚拟机用例

仅适用于虚拟机用例

红帽企业 Linux 对工作节点和基础架构节点的支持与授权

 

红帽企业 Linux 虚拟机客户机操作系统和容器构建的授权

 

用户提供的容器工作负载

 

红帽 OpenShift 构建

 

 

开发人员应用目录

 

 

开发人员 Web 控制台

 

 

IBM Cloud Pak 和红帽应用服务捆绑包的嵌入式组件

 

 

集成开发环境(IDE)

 

 

分布式跟踪

 

 

odo

 

 

红帽 OpenShift Pipelines

 

 

红帽 OpenShift 沙盒容器

 

 

红帽 OpenShift Serverless

 

 

红帽 OpenShift 服务网格

 

 

红帽 Kubernetes 高级集群管理

  

 

红帽 Kubernetes 高级集群安全防护

  

 

红帽 OpenShift Data Foundation Essentials

  

 

红帽 Quay

  

 

表 2:红帽 OpenShift 各版本之间的详细差异,包括提供这些功能的 operator

功能

红帽 OpenShift Kubernetes 引擎

红帽 OpenShift 容器平台

红帽 OpenShift 平台 Plus

红帽 OpenShift 虚拟化引擎

Operator 名称

AWS EFS CSI 驱动程序 Operator

aws-efs-csi-driver-operator

AWS Load Balancer Operator

aws-load-balancer-operator

红帽 OpenShift 的证书管理器 operator

openshift-cert-manager-operator

集群监控

集群监控

集群可观测性 operator

cluster-observability-operator

ClusterResourceOverride Operator

clusterresourceoverride

CNI 插件 ISV 兼容性

不适用

合规性 operator

合规性 operator

机密计算认证

trustee-operator

CSI 插件 ISV 兼容性

不适用

自定义指标的自动缩放器

openshift-custom-metrics-autoscaler-operator

设备管理器(比如 GPU)

不适用

DPU 网络操作器

dpu-network-operator

出口 Pod 和命名空间粒度控制

不适用

嵌入式市场

不适用

嵌入式 OperatorHub

不适用

嵌入式镜像仓库

不适用

外部 DNS operator

external-dns-operator

隔离代理修复

fence-agents-remediation

文件完整性 operator

文件完整性 Operator

GCP FileStore CSI 驱动程序 Operator

gcp-filestore-csi-driver-operator

HAProxy 入口控制器

不适用

Helm

不适用

入口集群范围防火墙

不适用

入口非标准端口

不适用

IPv6 单栈和双栈

不适用

红帽提供的 Kube 调度程序 operator

Kube 调度程序 Operator

Kubernetes NMState Operator

kubernetes-nmstate-operator

本地存储 Operator

本地存储 Operator

日志转发

红帽 OpenShift Logging Operator

Loki Operator

loki-operator

逻辑卷管理存储

lvms-operator

机器删除修复

machine-deletion-remediation

MetalLB Operator

metallb-operator

虚拟化迁移工具包

mtv-operator

多架构调优

multiarch-tuning-operator

Multus 及可用 Multus 插件

不适用

网络绑定磁盘加密(NBDE)Tang 服务器

nbde-tang-server

网络策略

不适用

由红帽提供的 Node Feature Discovery

nfd

节点健康检查

node-healthcheck-operator

节点维护

node-maintenance-operator

NUMA 资源 Operator

numaresources-operator

OpenShift API for Data Protection(OADP)

OADP Operator

OpenShift 云管理器 SaaS 服务

不适用

OpenShift 更新服务

cincinnati-operator

OpenShift 虚拟化

OpenShift 虚拟化 Operator

OVS 和 OVN SDN

不适用

红帽 OpenShift 的电源监控

power-monitoring-operator

红帽提供的 PTP Operator

PTP Operator

红帽 Quay 兼容性

不适用

红帽企业 Linux 软件集合和 RHT SSO 通用服务

不适用

单次运行时长覆盖 Operator

run-once-duration-override-operator

红帽 OpenShift 的次要调度程序 Operator

openshift-secondary-scheduler-operator

密钥存储 CSI

密钥存储 CSI Operator

安全配置文件

安全配置文件 Operator

服务绑定 Operator

rh-service-binding-operator

SR-IOV 网络 Operator

SR-IOV 网络 Operator

遥测技术与智能分析互联体验

不适用

垂直 Pod 自动缩放器

垂直 Pod 自动缩放器

Web 终端

web-terminal

成本管理

 

costmanagement-metrics-operator

平台日志记录

仅适用于虚拟机用例

仅适用于虚拟机用例

红帽 OpenShift Logging Operator

用户工作负载监控

仅适用于虚拟机用例

仅适用于虚拟机用例

cluster-monitoring-operator

红帽 OpenShift 构建

 

 

openshift-builds-operator

开发人员应用目录

 

 

不适用

开发人员 Web 控制台

 

 

不适用

Kourier 入口控制器

 

 

OpenShift Serverless

应用迁移工具包

 

 

mta-operator

容器迁移工具包

 

 

mtc-operator

运行时迁移工具包

 

 

mtr-operator

网络可观测性 Operator

 

 

netobserv-operator

ODF 多集群编排器

  

 

odf-multicluster-orchestrator

红帽 OpenShift Dev Spaces

 

 

devspaces

红帽版 OpenTelemetry

 

 

klusterlet-product

分布式跟踪

 

 

tempo-operator

OpenShift DR 集群 Operator

  

 

odr-cluster-operator

OpenShift DR 中心 Operator

  

 

odr-hub-operator

OpenShift Elasticsearch Operator(注 1)

 

 

elasticsearch-operator

红帽 OpenShift GitOps

仅适用于虚拟机用例

仅适用于虚拟机用例

openshift-gitops-operator

Kiali

 

 

Kiali Operator

红帽 OpenShift 本地版

 

 

不适用

红帽 OpenShift 日志记录

 

 

cluster-logging

红帽 OpenShift Pipelines

 

 

openshift-pipelines-operator-rh

红帽 OpenShift 沙盒容器

 

 

sandboxed-containers-operator

红帽 OpenShift Serverless

 

 

serverless-operator

红帽 OpenShift 服务网格

 

 

servicemeshoperator

红帽提供的 Quay 桥接 Operator

 

 

Quay 桥接 Operator

红帽提供的 Quay 容器安全防护

 

 

容器安全防护 Operator

红帽版 Keycloak

 

 

keycloak-operator

红帽版 Quarkus

 

 

不适用

单点登录

 

 

rhsso-operator

源代码到镜像和构建自动化

 

 

OpenShift Pipelines

拓扑感知生命周期管理器

 

 

topology-aware-lifecycle-manager

VolSync

 

 

volsync-product

红帽提供的 Web 终端

 

 

Web 终端

Windows 机器配置 Operator

 

 

Windows 机器配置 Operator

注释 1:红帽 OpenShift 中包含的 OpenShift Elasticsearch Operator 仅被许可用于支持 OpenShift 集群的内部基础架构搜索需求,不能单独用于客户应用。

未包含在任何红帽 OpenShift 版本中的常见红帽软件

除非另有说明,否则以下通常与 OpenShift 结合使用的红帽软件产品需要单独授权。红帽 OpenShift 平台 Plus 包括红帽高级集群管理、红帽高级集群安全防护、红帽 Quay 和红帽 OpenShift Data Foundation Essentials。其他自助式 OpenShift 订阅不包含这些额外的产品,但它们可以单独购买。其他与红帽 OpenShift 搭配使用,但未包含在本订阅指南中的红帽软件包括:

  • 红帽 Ansible 自动化平台
  • 红帽应用基础
  • 红帽企业 Linux AI
  • 红帽集成产品组合,包括 3scale、AMQ、Camel K、Fuse 等
  • 红帽 JBoss EAP
  • 红帽中间件捆绑包
  • 红帽 OpenShift 开发人员中心(红帽版 Backstage 项目)
  • 红帽 OpenShift AI
  • 红帽卫星(用于管理红帽企业 Linux)
  • IBM CloudPaks

如需了解有关上述产品的更多信息,请咨询您的红帽销售人员或合作伙伴。

标签:云服务