你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
Azure HPC 工作负载的存储
存储访问是规划高性能计算(HPC)工作负荷性能时要考虑的一个关键因素。 某些环境中的大规模 HPC 工作负荷可能会对数据存储和访问的需求超过传统云文件系统的功能。 本文提供建议,帮助你为 Azure HPC 工作负荷选择正确的存储。 它还提供有关能源、金融和制造业中 HPC 工作负荷存储的建议。
请考虑以下与应用程序要求相关的因素,以帮助确定要使用的存储解决方案:
- 延迟
- 每秒输入/输出操作数(IOPS)
- 吞吐量
- 文件大小和文件数量
- 作业运行时
- 成本
- 存储位置 - 本地与 Azure
有关详细信息,请参阅 了解影响 Azure中 HPC 存储选择的因素。
下图显示了用于特定 HPC 存储系统选择的决策树。
HPC 注意事项
石油和天然气公司必须能够有效地管理和存储数十亿字节的地震数据、井数据、地图和租赁。 为了使用此数据,他们需要一个高性能基础结构,它可以处理和交付实时分析,以帮助优化生产、降低环境风险并提高运营安全性。
数据存储 和访问需求因工作负荷规模而异。 Azure 支持多种方法来管理 HPC 应用程序的速度和容量。
能源行业的大规模批处理和 HPC 工作负载对数据存储和访问的需求超过了传统云文件系统的功能。 高性能输入/输出(I/O)要求和 HPC 的大规模可伸缩性需求为数据存储和访问带来了独特的挑战。
高性能计算 (HPC) 能够解决诸如地震和油藏模拟及建模等传统计算技术无法实用或经济高效处理的复杂问题。 HPC 通过并行处理和大规模可伸缩性的组合来解决这些问题,以便快速、高效、可靠地执行大型和复杂的计算任务。
在 Azure HPC 群集中,计算节点是可以快速创建的虚拟机(VM),以执行分配给群集的作业。 这些节点跨群集分配计算任务。 此分发有助于实现解决复杂 HPC 问题所需的高性能并行处理。 计算节点在运行作业时需要对共享工作存储执行读取和写入操作。 节点在以下两种极端情况下访问此存储:
一组数据对许多计算节点。 在此方案中,网络上有一个数据源,所有计算节点都可以访问工作数据。 尽管它们在结构上很简单,但存储位置的 I/O 容量会限制 I/O 操作。
许多数据集对许多计算节点。 在此方案中,网络上有许多数据源可供所有计算节点访问工作数据。 尽管它们在结构上很简单,但存储位置的 I/O 容量会限制 I/O 操作。
HPC 设计建议
选择最适合你唯一 I/O 和容量要求的解决方案。
网络文件系统
网络文件系统(NFS)通常用于提供对共享存储位置的访问权限。 使用 NFS 的服务器 VM 共享其本地文件系统。 在 Azure 中,此文件系统存储在 Azure 存储中托管的一个或多个虚拟硬盘(VHD) 上。 然后,客户端可以装载服务器的共享文件并直接访问共享位置。
NFS 通常用于需要跨所有节点进行访问的主目录和项目空间。 它可以为共享数据的研究组提供空间。 一般情况下,吞吐量工作负荷可以横向扩展,单个任务之间几乎没有依赖关系。 作业计划程序将工作划分为多个节点并协调活动。 NFS 是通过 TCP/IP 网络访问的典型跨节点共享存储。
NFS 的优点是易于设置和维护,在 Linux 和 Windows 操作系统上都受支持。 多个 NFS 服务器可用于跨网络分散存储,但单个文件只能通过单个服务器访问。
对于小型工作负载,请考虑使用具有大型临时磁盘的存储优化型 VM 或具有 Azure 高级存储的 D 系列 VM(具体取决于你的要求),从而在头节点上运行 NFS。 此解决方案适用于具有 500 个核心或更少内核的工作负荷。
在 HPC 方案中,文件服务器通常充当限制整体性能的瓶颈。 尝试以高于文档中每个虚拟机最大 IOPS 和吞吐量的速率访问来自单个 NFS 服务器的未缓存数据,会导致限流。
在数十个客户端尝试处理存储在单个 NFS 服务器上的数据的情况下,可以轻松达到这些限制。 这些限制可能会导致整个应用程序的性能受到影响。 你的 HPC 应用程序使用的场景越接近纯粹的一对多场景,你就越早遇到这些限制。
Azure 上的并行文件系统
并行文件系统跨多个网络存储节点分配块级存储。 文件数据分布在这些节点之间,这意味着文件数据分布在多个存储设备之间。 此分发将跨多个存储节点的任何单个存储 I/O 请求汇集到一起,这些存储节点可通过一个通用命名空间进行访问。
多个存储设备和数据路径用于提供高度并行度。 此方法减少了一次仅访问单个节点所施加的瓶颈数量。 但是,如果直接在 API 或 POSIX I/O 接口级别工作,则并行 I/O 可能难以协调和优化。 通过引入中间数据访问和协调层,并行文件系统为应用程序开发人员提供应用程序层与 I/O 层之间的高级接口。
能源消息传递接口(MPI)工作负载具有独特的要求,需要节点之间的低延迟通信。 这些节点通过高速互连进行连接,并且不易适应与其他工作负载共享。 MPI 应用程序在虚拟化环境中通过直通模式使用整个高性能互连。 MPI 节点的存储通常是一个并行文件系统,如 Lustre,也可通过高速互连进行访问。 Lustre 和 BeeGFS 通常用于处理地震处理的巨大吞吐量要求。 在较小程度上,它们还用于水库模拟。
Lustre 等并行文件系统用于 HPC 能源工作负载,这些工作负载需要访问大型文件、同时从多个计算节点进行访问以及大量数据。 并行文件系统的实现使得在能力和性能方面容易扩展。 这些文件系统利用具有较大带宽的远程直接内存访问传输,并减少 CPU 使用率。 并行文件系统通常用作暂存空间,适用于需要优化的 I/O 的工作。 示例包括工作负荷设置、预处理、运行和后处理。
协调的并行文件服务(如 Azure 托管 Lustre)适用于 50,000 个或多个核心,读取/写入速率高达 500 GBps 和 2.5-PB 存储。 有关详细信息,请参阅 Microsoft Azure上的
HPC 组件
Azure NetApp 文件和本地磁盘通常用于处理延迟和 IOPS 敏感型工作负荷,例如地震解释、模型准备和可视化。 请考虑将 Azure NetApp 文件用于最多 4,000 个核心、吞吐量高达 6.5 GiBps 的工作负载,以及受益于或需要对同一数据集进行多协议 NFS 和服务器消息块 (SMB) 访问的工作负载。
托管 Lustre 为 HPC 工作负载提供更快、更高的容量存储。 此解决方案适用于中型到大型工作负荷,可支持 50,000 个或更多核心,吞吐量高达 500 GBps,存储容量高达 2.5 PiB。
标准或高级 Azure Blob 存储经济高效,因为它是成本最低的云产品/服务。 此服务可在需要时提供 EB 规模、高吞吐量、低延迟的访问,并提供熟悉的文件系统接口和多协议访问(REST、HDFS、NFS)。 可以在 Blob 服务终结点上使用 NFS v3.0 来实现高吞吐量和读密集型工作负载。 可以通过移动到较冷的存储层来优化成本。 此方法允许基于上次更新或访问时间的生命周期管理,以及使用可自定义策略的智能分层。
石油和天然气能源工作负载可能需要你在本地系统和云之间传输大量数据。 脱机迁移使用基于设备的服务,例如 Azure Data Box。 联机迁移使用基于网络的服务,例如 Azure ExpressRoute。
下表对 Blob 存储、Azure 文件存储、托管 Lustre 和 Azure NetApp 文件进行了比较。
类别 | Blob 存储 | Azure 文件存储 | 托管 Lustre | Azure NetApp 文件 |
---|---|---|---|---|
用例 | 最适合用于大规模、读取频繁的顺序访问工作负荷,其中数据只需引入一次且修改极少。 低总拥有成本(如果存在轻型维护)。 一些示例方案包括大规模分析数据、吞吐量敏感的高性能计算、备份和存档、自动驾驶、媒体渲染和基因组排序。 |
最适合随机访问工作负载的高可用性服务。 对于 NFS 共享,Azure 文件提供完整的 POSIX 文件系统支持。 借助内置的 CSI 驱动程序,可以从基于 VM 的平台和容器平台(例如 Azure 容器实例和 Azure Kubernetes 服务(AKS)轻松使用它。 一些示例方案包括共享文件、数据库、主目录、传统应用程序、ERP、CMS、不需要高级管理的 NAS 迁移,以及需要横向扩展文件存储的自定义应用程序。 |
托管 Lustre 是一个完全托管的并行文件系统,最适合中大型 HPC 工作负载。 通过提供熟悉的 Lustre 并行文件系统功能、行为和性能,在云中启用 HPC 应用程序,而不会破坏应用程序兼容性。 此服务有助于保护长期应用程序投资。 |
由 NetApp 提供支持的云中完全托管的文件服务,具有高级管理功能。 Azure NetApp 文件适用于需要随机访问的工作负荷。 它提供广泛的协议支持和改进的数据保护。 一些示例方案包括需要丰富的管理功能的本地企业 NAS 迁移、SAP HANA、延迟敏感或 IOPS 密集型高性能计算或需要同时进行多协议访问的工作负荷。 |
可用的协议 | NFS 3.0 REST Azure Data Lake Storage |
中小型企业 NFS 4.1 (任一协议之间没有互操作性) |
Lustre | NFS 3.0 和 4.1 中小型企业 |
主要功能 | 与 Azure HPC 缓存集成,用于低延迟工作负荷。 集成式管理,包括生命周期管理、不可变 Blob、数据故障转移和元数据索引。 |
区域冗余以确保高可用性。 一致的个位数毫秒延迟。 性能和成本具有可预测性,并可随容量扩展。 |
高达 2.5 PB 的高存储容量。 低延迟,约 2 毫秒。 在几分钟内创建新群集。 使用 AKS 支持容器化工作负载。 |
极低延迟,低至亚毫秒。 丰富的 NetApp ONTAP 管理功能,例如 SnapMirror Cloud。 一致的混合云体验。 |
性能(每单位体积) | 高达 20,000 IOPS。 高达 100 GiBps 吞吐量。 | 高达 100,000 IOPS。 高达 80 GiBps 吞吐量。 | 高达 100,000 IOPS。 高达 500 GiBps 吞吐量。 | 高达 460,000 IOPS。 高达 36 GiBps 吞吐量。 |
规模 | 单个卷最大可达 2 PiB。 单个文件的大小可以达到大约 4.75 TiB。 没有最低容量要求。 |
单个卷的容量可达 100 TiB。 单个文件可以达到 4 TiB。 最小容量为100 GiB。 |
单个卷最大可达 2.5 PiB。 单个文件最大可达 32 PB。 4 TiB 最小容量。 |
单个卷容量可达 100 TiB。 单个文件最大可达 16 TiB。 一致的混合云体验。 |
定价 | Blob 存储定价 | Azure 文件存储定价 | 托管 Lustre 定价 | Azure NetApp 文件定价 |
财务设计建议
使用 标准或高级 Blob 存储 实现高吞吐量、低延迟存储。 它提供了以下优势:
它提供 EB 规模、高吞吐量、低延迟的访问,并提供熟悉的文件系统和多协议访问,包括 REST、HDFS、NFS。
这是经济高效的。
可以使用 BlobFuse 将 Blob 存储装载为文件系统。 这样做可以轻松允许多个节点为只读方案装载同一容器。
它在 BLOB 服务终结点支持 NFS 3.0,可用于高吞吐量、读取繁重的工作负载。
可以通过将数据移到较冷的存储层来优化成本。 通过基于上次更新或访问时间的生命周期管理和具有可自定义策略的智能分层,可以实现此优化。
将 Azure NetApp 文件用于 ReadWriteMany(唯一)或写一次读一次的应用程序。 它提供了以下优势:
各种文件协议,例如 NFSv3、NFSv4.1 和 SMB3
与本地性能相当的性能,具有多个层级(超高、高级和标准)
几分钟内完成部署,提供广泛的等级和灵活性。
灵活的容量池类型和性能,根据池的层级和卷配额自动分配每个卷的 QoS
制造注意事项
请务必确保所需数据在正确的时间到达 HPC 群集计算机。 你还希望确保这些单独的计算机的结果快速保存,并可用于进一步分析。
工作负荷流量的分布
请考虑 HPC 环境生成和处理流量的类型。 如果计划运行多种类型的工作负荷并计划将存储用于其他目的,此步骤尤其重要。 请考虑并记录以下流量类型:
- 单个流与多个流
- 读取流量与写入流量的比率
- 平均文件大小和文件数量
- 随机访问模式与顺序访问模式
数据本地性
此类别说明数据的位置。 区域意识有助于确定是否可以使用复制、缓存或同步作为数据移动策略。 预先检查以下区域项:
- 如果源数据位于本地、Azure 或两者中
- 如果结果数据位于本地、Azure 中或两者中
- Azure 中的 HPC 工作负载是否需要与源数据修改时间线相协调
- 是否包含敏感数据或 Health Insurance Portability and Accountability Act 数据
性能要求
存储解决方案的性能要求通常如下汇总:
- 单流吞吐量
- 多流吞吐量
- 预期最大 IOPS
- 平均延迟
每个因素都会影响性能,因此这些数字充当特定解决方案预期结果的指南。 例如,HPC 工作负荷可能包括在工作流中创建和删除大量文件。 这些操作可能会影响总体吞吐量。
访问方法
确认所需的客户端访问协议,并明确说明该协议所需的功能。 有不同版本的 NFS 和 SMB。
请考虑以下要求:
- 是否需要 NFS/SMB 版本
- 预期的协议功能,如访问控制列表或加密
- 并行文件系统解决方案
总容量要求
Azure 中的存储容量是下一个考虑因素。 它有助于了解解决方案的总体成本。 如果计划长时间存储大量数据,可能需要考虑将分层作为存储解决方案的一部分。 分层在一个热层中将较低成本的存储选项与较高成本、较高性能的存储相结合。 请考虑以下容量要求:
- 所需的总容量
- 所需的热层总容量
- 所需的暖层容量总数
- 所需的冷层容量总数
身份验证和授权方法
对于身份验证和授权要求(例如使用 LDAP 服务器或 Windows Server Active Directory),请确保在体系结构中包含必要的支持系统。 如果需要支持 UID 或 GID 映射到 Windows Server Active Directory 用户等功能,请确认存储解决方案支持该功能。
请考虑以下网络要求:
- 本地(仅限文件服务器上的 UID 或 GID)
- 目录(LDAP 或 Windows Server Active Directory)
- UID 或 GID 是否映射到 Windows Server Active Directory 用户
自主开发并行文件系统
与 NFS 类似,可以创建多节点 BeeGFS 或 Lustre 文件系统。 这些系统的性能主要取决于所选 VM 的类型。 可以使用在 Azure 市场中针对 BeeGFS 找到的映像,或名为 Whamcloud 的 DDN 提供的 Lustre 实现。 如果使用来自 BeeGFS 或 DDN 等供应商的非 Microsoft 映像,则可以购买他们的支持服务。 除了计算机和磁盘的成本外,可以在其 GPL 许可证下使用 BeeGFS 和 Lustre,无需额外付费。 可以使用 Azure HPC 脚本以及临时本地磁盘(用于暂存)或 Azure 高级 SSD 或 Azure 超级磁盘存储(用于持久存储),从而轻松推出这些工具。
Cray ClusterStor
对于较大的工作负载来说,在大型 Lustre 环境中复制大型计算群集的裸机性能是一项挑战。 其他挑战包括实现以 TBps 为单位的高吞吐量,并可能需要处理 PB 级别的存储。 现在,可以使用 Azure 解决方案中的 Cray ClusterStor 运行这些工作负载。 这种方法是置于相关 Azure 数据中心的纯裸机 Lustre 部署。 BeeGFS 和 Lustre 等并行文件系统因其体系结构而提供了最高的性能。 但是,这种体系结构和这些技术的使用具有很高的管理价格。
后续步骤
以下文章提供了指导,在你的云采用历程中的不同阶段为你提供帮助。