4.3. 计算使用架构
此单元版本 作为技术预览提供,因此不受红帽完全支持。它们只应用于测试,不应在生产环境中部署。有关技术预览功能的更多信息,请参阅覆盖范围详细信息。
计算为中心的云支持 CPU 密集型工作负载,如数据计算或加密和解密、RAM 密集型工作负载,如内存缓存或数据库服务器等。这种架构类型通常不是存储密集型或网络密集型,它会为客户提供需要计算资源的强大功能。
以计算为计算的工作负载包括以下用例:
- 高性能计算(HPC)
- 使用 Hadoop 或其他分布式数据存储进行大数据分析
- 持续集成或持续部署(CI/CD)
- 平台即服务(PaaS)
- 网络功能虚拟化(NFV)的信号处理.
以计算为中心的 OpenStack 云通常不使用原始块存储服务,因为云通常不托管需要持久块存储的应用。基础架构组件不共享,因此工作负载可以根据需要消耗尽可能多的可用资源。基础架构组件还需要具有高可用性。此设计使用负载均衡器。您还可以使用 HAProxy。
有关安装和部署文档,请参阅 第 5 章 部署信息。
4.3.1. 用例示例
组织为研究项目提供 HPC,需要将第三个计算中心添加到欧洲的两个现有计算中心。
下表列出了要添加的每个计算中心的要求:
数据中心 | 大约容量 |
---|---|
Geneva, Switzerland |
|
Budapest, Hungary |
|
4.3.2. 关于设计
此架构使用单元格来隔离计算资源,并在不同数据中心之间透明扩展。这个决定会影响对安全组和实时迁移的支持。此外,它需要跨单元手动复制一些配置元素,如类别。但是,单元在向用户公开一个公共 API 端点时提供所需的扩展。
云对两个原始数据中心使用一个计算单元,每当您添加新数据中心时,都将创建新的计算单元。每个单元都包含三个可用区,用于进一步隔离计算资源,以及至少三个为具有镜像队列以实现高可用性的集群配置的 RabbitMQ 消息代理。
位于 HAProxy 负载均衡器后面的 API 单元位于 Switzerland 的数据中心。API 单元使用单元调度程序的自定义变体将 API 调用定向到计算单元。自定义允许某些工作负载路由到特定数据中心,或基于单元 RAM 可用性的所有数据中心。
您还可以使用过滤器来自定义处理单元格中放置的计算调度程序。例如,ImagePropertiesFilter 根据客户机运行的操作系统(如 Linux 或 Windows)提供特殊处理。
中央数据库团队使用 NetApp 存储后端在主动/被动配置中管理每个单元格的 SQL 数据库服务器。备份每 6 小时运行一次。
4.3.3. 架构组件
组件 | 描述 |
---|---|
Compute | 在控制器上运行计算管理和调度服务。计算服务也会在每个计算节点上运行。 |
仪表板服务 | 用于 OpenStack 管理的 GUI. |
Identity Service | 基本身份验证和授权功能。 |
镜像服务 | 在 API 单元中运行,并维护一组小型 Linux 镜像,以便编配工具可以放置应用程序。 |
网络 | 网络服务。有关 OpenStack 网络的更多信息,请参阅 第 2 章 Network In-Depth。 |
监控 | 遥测服务执行 metering,以使用分片复制的 MongoDB 后端调整项目配额。要分散 API 负载,您必须在 Telemetry 可以查询的子单元中部署 openstack-nova-api 服务的实例。此部署还需要在子单元中配置支持服务,如身份和镜像。要捕获的特定关键指标包括镜像磁盘利用率和计算 API 响应时间。 |
编配服务 | 自动部署和测试新实例。 |
Telemetry 服务 | 支持编排自动扩展功能。 |
对象存储 | 存储具有 3 PB Ceph 集群的对象。 |
4.3.4. 设计注意事项
除了 第 3 章 设计 和计算节点设计注意事项 中描述的基本设计注意事项外,还需要考虑以下项目用于计算密集型架构。
- 工作负载
短期的工作负载可以包含持续集成和持续部署(CI-CD)作业,该作业同时创建大量计算实例来执行一组计算密集型任务。然后,环境会在终止实例前将结果或工件从每个实例复制到长期存储。
长期工作负载,如 Hadoop 集群或 HPC 集群,通常会接收大型数据集,在这些数据集上执行计算工作,然后将结果推送到长期存储。计算工作结束时,实例将闲置,直到它们收到另一个作业。对于长期工作负载的环境通常更大且更为复杂,但您可以通过保持在作业间活跃而降低构建这些环境的成本。
以计算为计算的 OpenStack 云中的工作负载通常需要持久块存储,除了使用HDFS 的 Hadoop 之外。共享文件系统或对象存储维护初始数据集,并充当保存计算结果的目的地。通过避免 input-output (IO)开销,您可以显著提高工作负载性能。根据数据集的大小,您可能需要扩展对象存储或共享文件系统。
- 扩展规划
云用户期望在需要时即时访问新的资源。因此,您必须计划典型使用,并需要满足资源需求突然的激增。如果您计划太保守,您可能会遇到对云的意外订阅的情况。如果您非常积极地计划,您可能会遇到云不必要的操作和维护成本的意外利用。
扩展规划的主要因素是分析云使用情况的趋势。衡量您提供服务的一致性,而不是云的平均速度或容量。这些信息可帮助您对容量性能建模,并确定云的当前和未来容量。
有关监控软件的详情,请参考 第 3.9 节 “其他软件”。
- CPU 和 RAM
现在,典型的服务器产品包括最多 12 个内核的 CPU。另外,一些 Intel CPU 支持 Hyper-Threading Technology (HTT),这会加倍内核容量。因此,一个支持多个 CPU 的服务器带有 HTT 乘以可用内核数。HTT 是一个 Intel 专有同时多线程实施,用于改进 Intel CPU 上的并行化。考虑启用 HTT 来提高多线程应用程序的性能。
在 CPU 上启用 HTT 的决定取决于用例。例如,禁用 HTT 可以帮助编写计算环境。使用或不使用 HTT 运行本地工作负载的性能测试可帮助确定哪个选项更适合特定情况。
- 容量规划
您可以使用以下策略为计算环境添加容量:
通过向云添加额外的容量来水平扩展。您应该在额外节点中使用相同的或类似的 CPU,以减少破坏所有实时迁移功能的机会。横向扩展虚拟机监控程序主机也会影响网络和其他数据中心资源。当您访问机架容量或需要额外网络交换机时,请考虑此增加。
注意请注意,将节点放在适当的可用区和主机聚合中所需的额外工作。
- 通过增加内部计算主机组件的容量来扩展,以支持使用量增加。例如,您可以将 CPU 替换为更多内核,或者增加服务器的 RAM。
通过调整 over-commit 比率,评估您的平均工作负载,并尽可能增加计算环境中运行的实例数量。
重要不要在以计算的 OpenStack 设计架构中增加 CPU 超提交率。更改 CPU over-commit 比率可能会导致与其他需要 CPU 资源的其他节点冲突。
- Compute Hardware
以计算为中心的 OpenStack 云对处理器和内存资源非常要求。因此,您应该对可提供更多 CPU 插槽、更多 CPU 内核和更多 RAM 的服务器硬件优先排序。
网络连接和存储容量对这个架构而言并不重要。硬件必须提供足够的网络连接和存储容量来满足最低用户要求,但存储和网络组件主要将数据集加载到计算集群,且不需要一致的性能。
- 存储硬件
您可以使用具有开源软件的商业硬件构建存储阵列,但可能需要专门的专业知识来部署它。您还可以使用带有服务器中直接附加的存储的横向扩展存储解决方案,但您必须确保服务器硬件支持存储解决方案。
在设计存储硬件时请考虑以下因素:
- 可用性。如果实例必须在主机之间高度可用或能够迁移,请将共享存储文件系统用于临时实例数据,以确保计算服务在节点出现故障时可以运行不间断。
- 延迟使用固态驱动器(SSD)磁盘来最大程度减少实例存储延迟,减少 CPU 延迟并提高性能。考虑在计算主机中使用 RAID 控制器卡来提高底层磁盘子系统的性能。
- 性能。虽然以计算为计算的云通常需要主数据 I/O 和存储,但存储性能仍是要考虑的重要因素。您可以通过观察存储 I/O 请求的延迟来测量存储硬件性能。在某些计算密集型工作负载中,尽量减少从存储获取数据时 CPU 体验的延迟可能会显著提高应用程序的整体性能。
- 可扩展性.决定存储解决方案的最大容量。例如,扩展至 50 PB 的解决方案比只扩展至 10PB 的解决方案更可扩展。此指标与以下指标相关,但与可扩展性不同,这是随着不断扩展的解决方案性能的测量。
- 连接性.连接必须满足存储解决方案要求。如果您选择了集中存储阵列,请确定如何将虚拟机监控程序连接到存储阵列。连接可能会影响延迟和性能。因此,请确保网络特征最小化延迟,以提高环境的整体性能。
- 网络硬件
除了 第 2 章 Network In-Depth 中描述的基本网络注意事项外,请考虑以下因素:
- 所需的端口计数会影响网络设计需要的物理空间。例如,为 1U 服务器中的每个端口提供 48 个端口有 10 GbE 容量的交换机,其端口密度高于交换机,为 2U 服务器中的每个端口提供有 10 GbE 容量的 24 个端口。更高的端口密度可为计算或存储组件提供更多机架空间。您还必须考虑故障域和电源密度。虽然更为昂贵,但您也可以考虑更高的密度交换机,因为您不应设计网络超出功能要求。
- 您应该使用可扩展的网络模型设计网络架构,这有助于添加容量和带宽,如 leaf-spline 模型。在这种网络设计中,您可以添加额外的带宽并扩展到额外的 gear 机架。
- 选择支持所需端口数、端口速度和端口密度的网络硬件非常重要,而且在工作负载需求增加时也允许未来增长。还需要评估网络架构中提供冗余的重要位置。提高网络可用性和冗余成本可能会昂贵,因此您应该将额外成本与冗余网络交换机和绑定接口的好处进行比较。