高性能计算场景IO优化一例

 

冬瓜哥最近闭关中，所以没经常出来分享。这次冬瓜哥想聊一聊高性能计算场景下的一例 IO 优化，这个例子非常偏向于应用层，而不是在底层架构上优化 IO 。
高性能计算是一个大场景，其由软件和硬件组成。
 
高性能计算领域的软硬件
硬件上，其就是一堆计算核心的组合，当然，这只是其本质，而表象上就有多种形式了，比如：多路 CPU 的服务器（ HPC 领域内俗称胖节点）、一台服务器带着若干块 GPU 卡、一台服务器内多片众核心 CPU 、成千上万块独立的主板通过比如以太 /IB 网络互联起来。这些形态上本质都是一堆计算核心和一堆内存。



其中，胖节点的计算效率最高，编程简单，因为核心之间可以通过高速总线透明的共享内存，但是价格也最贵。

其次是众核心 CPU ，有些可共享内存，有些也不行，有些采用片上高速 DDR 可做缓存也可以直接寻址或者二者混合，这类形态需要有一定的编程模型和库来支撑了，并不是完全透明的，至少在想要达到更高性能的前提下。
再就是利用 GPU 内部的数千个计算核心，此时编程模型更加复杂了， GPU 和 CPU 无法共享内存（最新的一些 SDK 里也提供了可共享内存的框架），所以牵扯到数据和代码的传递，不过还好，数据和代码的传递还都是走内存和 PCIE 的，还是可以用单机控制的。
最麻烦的则是成千上万块主板，也就是单独的机器通过外部网络连接起来，此时，代码只需要在初始时候从管理器分发一次，运行起来之后，机器之间只传递数据，而且这个数据传递并不走内存，机器之间无法透明的共享内存，必须通过网络来传递，进程间的数据传递、协调和同步利用 MPI 库来进行，其编程模型基本上与 GPU 编程模型处在同一个复杂度级别上。
软件上，可分为底层软件和上层软件。底层软件包含基本的操作系统、编程库，比如 OpenMP 、 OpenCL 、 MPI 、 CUDA 等等，上层软件就是应用软件，也就是实现最终计算逻辑的应用程序，比如 海洋气象地质类、基因分析类、分子动力学类、核物理类、化学化工类 等等，种类繁多。
 

用户环境

该用户主要应用是进行气象海洋预报业务。海洋预报的计算模型软件有多种，本用户使用了如下软件： WRF 、 FVCOM 、 WaveWatch3 和 SWAN ，其中 FVCOM 是最广泛应用之一。
FVCOM 是一个有限元分析软件， 包含了多种物理、水质、生态计算模块，该模型基于 Fortran 90/95 标准，且在 MPI (Message Passing Interface) 的框架下实现计算并行化，可以在共享内存及分布式内存多计算节点的高性能计算机上实现并行快速模拟。具体算法已经超出了冬瓜哥的认知范围。
大量的海洋数据，需要分析、处理和存储，对存储的需求如下：
（1）    气象数据的接收，需要高性能、低延迟的存储设备

（2）    要求支持大容量、高带宽、多客户端的并发访问

该用户原先使用了某开源分布式存储系统，但是由于其性能已经无法满足业务要求，后升级到了浪潮 AS13000-Rack 大规模机架式分布式存储系统。 AS13000 非常有利于满足高性能计算场景的高并发需求。






 

性能对比

采用了浪潮 AS13000-Rack 系统之后，系统的整体性能得到了大幅提升，但是美中不足的是，在 FVCOM 这一步计算中， AS13000 的性能却落后了原有存储系统将近一半，而在其他各项计算中，均大幅领先。按理说，如果单看最后的总成绩， AS13000 的表现已经是让人足够满意了，但是这项标红的落后项，对于拥有追求完美情怀的工程师而言，那就是失败，是不可容忍的。



在超算领域，浪潮是国内最顶尖的提供商，拥有足够的人才储备，包括 GPU 、 MIC 、 MPI 、 OpenMP 等领域的算法优化工程师、开发工程师、架构师；拥有精通各种工程领域建模、计算的架构师。而在底层基础架构领域，浪潮的 K1 小型机在国内高端服务器领域首屈一指， 8 路服务器和各种中低端服务器产品线全覆盖；浪潮的 AS18000 高端存储、 HF5000 固态存储，以及 AS13000 大规模分布式存储系统各个档次、场景一应俱全。这给了浪潮得天独厚的优势，可以进行自顶向下的优化，而不是仅仅孤立在某个层面来看问题。
 

原因分析过程

 

浪潮派出了高性能计算应用架构师、存储系统架构师、 AS13000 核心 IO 路径开发工程师三元大将出场来分析解决该性能问题。
首先由应用架构师上场，经过对 FVCOM 系统运行时的状态和数据做了一番分析之后，他给出了如下的结论：
     计算时间长的主因是因为 FVCOM 在使用时，主节点创建该过程日志文件，其他节点 open ；然后主节点高频率的往该过程日志文件追加写，每次只写入很少的数据量。但是其他节点读该文件，但是读取频率较低；直到算例执行结束，其他节点才 close 该文件。因此整个过程中，为了保证数据一致性，主节点的写都是直写而不是写缓存，目测这应该是一个严重的瓶颈。

       有了应用架构师的头阵支撑，存储系统架构师登场。在使用了各种 Trace 工具，盯着结果仔细分析了一番之后，他给出了如下的结论：在某个典型计算任务采样过程中，主节点的确在高频的追加写入日志文件，每次 80 字节左右的 Write Through ，共发生了大约 155 万次的写，读节点执行了大约 6700 次。过程日志文件写入 80 字节数据是追加写，采用 Write Through 方式写盘，从而导致系统响应变慢。

     该 AS13000 研发工程师出场了。其给出设计思路如下：在保证多点并发访问数据一致性的前提下开启写缓存模式。经过分析之后，确定其他节点 OPEN ， WRITE ， READ 某个文件时，该文件的写缓存不得不改变为 Write Through 模式以保证数据一致性。但实际上， OPEN 本身不会对写有影响； READ 对追加写没有影响，但会导致修改写变为 Write Through 。具体如下表：



    
读对于追加写没有影响的原理是，在多节点一写多读时，追加写只有在更新元数据后，其他节点的读才能访问到新的数据。而当前的元数据更新机制，与是否 WriteThrough 是没有关系的，所以可以做到读不影响追加写的写缓存。

最终，三员 大将给出了一套优化方案 ： 增加可保证多点并发访问时一致性的写缓存，从而在多节点同时操作同一个文件时，让只 OPEN （即使是以写方式 OPEN ）和 READ 但不实际写入的节点不对写节点的写缓存操作造成干扰。
通过实际测试和验证， FVCOM 运行时间由 89 分钟缩减到 40 分钟，大大提高了系统性能。

 

提示：浪潮存储从去年开始全面启动针对应用场景的定制化和优化。气象海洋 HPC 这个 项目是 AS13000 场景高性能重点应用之一。该项目的优化开发调试过程中，浪潮工程师克服了巨大阻力和挑战，中间也曾经出现过分歧，但是整个验收阶段非常顺利，整套系统按时上线，一直稳定运行到现在。  



Reward

people gave a reward