关于对异构计算（Big Data、HPC）整合的一些思路

随着互联网的高速发展，基于数据计算密集型应用的框架不断涌现，BigData:从支持离线处理的MapReduce，到支持在线处理的Storm，从迭代式计算框架Spark到流式处理框架S4等，HPC：从使用单机胖节点处理数据，到openMPI(MPI)联机并行处理，到HPC框架SGE、PBS、SLURM等,GPU计算:从GPU的CUDA编程，到深度学习框架Caffe、TensorFlow等，各种框架诞生于不同的公司或者实验室，它们各有所长，各自解决了某一类问题。在提供数据分析、计算类软件企业中，或者大部分互联网公司，或者某些特殊行业(如:金融、银行、科研等等)，一般常用的系统(框架、软件）有:Hadoop、Spark、Storm、SGE、PBS、SLURM等，随着业务场景不断变化，框架越来越多，大多数公司、企业、团体希望把日常用到框架部署到公共的集群中，让所有框架共享集群内的资源，这样，我们萌生了整理一套简单易用的统一管理、调度平台的想法。

以下针对资源统一管理与调度平台产生背景以及它们所应具有的特点进行阐述。

多种计算框架支持：

管理平台内部资源对外提供全局统一的资源管理器。所有接入平台的框架在全局资源管理器中进行资源申请。调度工作交于框架自身控制。也就是:资源统一管理、计算控制权下放。各框架在统一的平台内控制资源(内存、CPU、硬盘、网络等)会出现相互干扰，所以，需要资源隔离机制、和常规框架资源调度方案，来避免资源类似问题。

扩展性：

平台化概念就是避免各类单点、性能、设备扩展性等问题。

容错行：

与扩展类似，容错性也是平台设计的重要方向，数据传输、分析处理、计算等一定要求平台有良好的容错性。

Cluster of Clan (大集群）

如果在使用环境中每个计算框架单独搭建一套集群，往往利用率不是很高，混合设计会让集群利用率大幅度提升。但是，也要根据具体应用场景来分析，如果计算密集型、并且周期较长，用得尽计算框架内的资源，这样建议使用静态资源分配的方式。根据经验：一般小的集群使用者，他的集群尽可能多的安装各种软件，这样对他们来说是最好的，原因有几种，资源紧张，使用者混搭较严重，一般各个用户用到的应用、计算框架等能装的都会装在上面的。还有一类就是专业研究某一领域的用户，他们会搭建专业的集群来使用。如：HPC集群、GPU的集群、Spark的集群。

打通各个环节：

底层基础设施运维：（除去网络、布线、机柜等等）远程开关机、远程安装操作系统、各类监控服务、各类告警服务、底层语言及SDK、特定的软件包等

存储层：RDBMS、NoSQL、NewSQL、文件存储等统一安装、维护、api化、集群化

计算层：各类计算框架，如Hadoop、Spqrk、SGE、Pbs 等

应用层：场景化应用安装维护，如脑影像相关软件FreeSuffer、SPM、VTK、ITK等

统一用户：统一用户信息，实现异构系统用户打通

非正常关闭系统、人为误操作、软件冲突等都会造成运维上的负担及用户使用体验度下降。所以在处理集群上的事物要仔细谨慎。

在后续章节陆续会介绍一些空手夺白刃的招式 ：）

如何搭建一套企业级HPC平台，包括：统一用户、统一存储等核心功能。

邮件：code_son@163.com