【IT168 资讯】 FVCOM(有限体积海岸海洋模型)大众接触比较少，但说起海洋气象预报大家就比较熟悉了。FVCOM是海洋气象预报里边的一个重要应用，是用来计算海洋内部大陆架和河口的复杂礁岛、水湾、广阔的高潮线与低潮线之间的盐碱湾等特征。浪潮整机柜软件定义存储AS13000-Rack为这个应用做了定制化IO优化，将其性能提升一倍多。

　　浪潮在今年9月的整机柜SDS新品AS13000-Rack发布会上表示，依托“计算+”硬件重构和软件定义理念，浪潮SDS可以“为应用的深度定制”，匹配不同应用场景的数据特点优化。

　　这次我们就来聊一聊高性能计算场景下的一例IO优化，这个例子非常偏向于应用层，而不是在底层架构上优化IO。

　　高性能计算是一个大场景，其由软件和硬件组成。

　　高性能计算领域的软硬件

　　硬件上，其就是一堆计算核心的组合，当然，这只是其本质，而表象上就有多种形式了，比如：多路CPU的服务器(HPC领域内俗称胖节点)、一台服务器带着若干块GPU卡、一台服务器内多片众核心CPU、成千上万块独立的主板通过比如以太/IB网络互联起来。这些形态上本质都是一堆计算核心和一堆内存。

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

　　其次是众核心CPU，有些可共享内存，有些也不行，有些采用片上高速DDR可做缓存也可以直接寻址或者二者混合，这类形态需要有一定的编程模型和库来支撑了，并不是完全透明的，至少在想要达到更高性能的前提下。

　　再就是利用GPU内部的数千个计算核心，此时编程模型更加复杂了，GPU和CPU无法共享内存(最新的一些SDK里也提供了可共享内存的框架)，所以牵扯到数据和代码的传递，不过还好，数据和代码的传递还都是走内存和PCIE的，还是可以用单机控制的。

　　最麻烦的则是成千上万块主板，也就是单独的机器通过外部网络连接起来，此时，代码只需要在初始时候从管理器分发一次，运行起来之后，机器之间只传递数据，而且这个数据传递并不走内存，机器之间无法透明的共享内存，必须通过网络来传递，进程间的数据传递、协调和同步利用MPI库来进行，其编程模型基本上与GPU编程模型处在同一个复杂度级别上。

　　软件上，可分为底层软件和上层软件。底层软件包含基本的操作系统、编程库，比如OpenMP、OpenCL、MPI、CUDA等等，上层软件就是应用软件，也就是实现最终计算逻辑的应用程序，比如海洋气象地质类、基因分析类、分子动力学类、核物理类、化学化工类等等，种类繁多。

　　海洋预报如何优化IO?

　　该用户主要应用是进行气象海洋预报业务。海洋预报的计算模型软件有多种，本用户使用了如下软件：WRF、FVCOM、WaveWatch3和SWAN，其中FVCOM是最广泛应用之一。

　　FVCOM(The Finite-Volume Coastal Ocean Model，有限体积海岸海洋模型)是一个有限元分析软件，包含了多种物理、水质、生态计算模块，该模型基于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。具体如下表：

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

　　FVCOM应用性能提升1.23倍

　　最终，三员大将给出了一套优化方案：增加可保证多点并发访问时一致性的写缓存，从而在多节点同时操作同一个文件时，让只OPEN(即使是以写方式OPEN)和READ但不实际写入的节点不对写节点的写缓存操作造成干扰。

　　通过实际测试和验证，FVCOM运行时间由89分钟缩减到40分钟，大大提高了系统性能。

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