分布式存储的一些问题

kartwall

我的一些客户有一些高性能计算的集群，在64个节点左右规模。现在比较麻烦的是，用户没有更多的资金来购置存储设备（应该说钱已经全部投在这些计算集群上了），所以就开始整天打计算集群节点上那些硬盘的主义。为了满足他们的这种需求，我们已经先后给其安装过pvfs和lustre，两者的表现都不好。主要问题体现在，两者读写小文件的性能极不好，读写大文件时也不太稳定，而且由pvfs或lustre所构建出来的一个大逻辑硬盘（整合了所有计算节点上的空余硬盘分区），必须要所有节点全部开机后，这个硬盘才能正常工作，但是我们这些可爱的客户又比较喜欢关机，经常没事就会把集群关掉个一半或N台，美其名曰省电，等到下次再启动起来时，发现pvfs和lustre就总会出一些异常的问题，最终结果是我们很累。

现在我不知道除了pvfs或lustre之外，还有没有一些其他的分布式存储的方案，对性能已经没有要求了，换句话说，不一定要是并行化的读写数据，只需要能将分布的存储资源利用起来，整合成一个逻辑上的大存储设备，然后稳定一些就可以了。请教各位了。

[ 本帖最后由 kartwall 于 2006-6-26 23:18 编辑 ]

nntp

Hi,

1. 小文件性能有问题很正常的, 是此类型方案的技术局限 http://bbs.chinaunix.net/viewthr ... &extra=page%3D1我已经详细介绍过这个问题了
2. 大文件性能不好就不是pvfs2/lustre的问题，而是你的硬件不行.包括disk IO+ inter-connect
3. 购买hpc的用户因为运营资金的限制希望不要24h开机运行也是很正常，很合理的理由. 特别是像学校或者研究机构，他们的hpc采购都是国家学校的钱,但是日常运营费用就要自己来想办法了.
   关于关机这个问题,我觉得是你们和客户的沟通上的问题, 完全可以通过技术手段把这个问题解决掉的. 之前在 http://bbs.chinaunix.net/viewthr ... &extra=page%3D1的贴里面我说到过关于hpc cluster和分布存储的cluster最好分开,当时我忘记哪位对此表示不理解了, 你现在的这个例子,就是实际运营中为什么要分开的证明之一.
4. 你们这个项目初期的需求分析没有做到位, 这样的用户,应该优先考虑去验证 diskless hpc cluster 方案, 如果调研结果确定采用diskless hpc cluster方案,很多问题都可以克服了.

所有的compute node全部diskless, boot from network,  把所有的compute node的硬盘全部集中到4-6台硬盘槽位多的服务器上,然后这4-6台服务器作分布存储. 这样并没有增加什么技术难度,也没有增加硬件开支,既可以解决IO的性能问题,用户要求关机节电的要求也可以满足了. 而且可以把作分布存储的node的处理器和内存数量降低,配到compute node上去,提高compute node的性能. 唯一我看到可能要增加硬件投入的就是多加几个网络交换机.

kartwall

嗯。。。看明白了，意见很中肯，在今后的项目中我会考虑给用户提这样的方案，谢谢！！

kartwall

不过我对diskless的方案仍然有一些疑问，对于cluster这种结构来说，每个节点上都运行着单独的操作系统，如果一个本地硬盘都没有的话，内存做SWAP怎么办？程序在运行过程中要写大量的临时文件怎么办？各台机器要做不同的配置怎么办？所有的这些都要通过网络存储在server结点上么？那岂不是对inter-connect网络又提出了更高的要求？

nntp

原帖由 kartwall 于 2006-6-27 22:21 发表
不过我对diskless的方案仍然有一些疑问，对于cluster这种结构来说，每个节点上都运行着单独的操作系统，如果一个本地硬盘都没有的话，内存做SWAP怎么办？程序在运行过程中要写大量的临时文件怎么办？各台机器要做 ...

回答这个问题似乎和鸡和蛋的关系扯上一点关系，呵呵。

hpc 的应用，最忌讳的就是swap, 如果硬件没有sizing好，一发生swap, cpu利用率马上往下掉，所以你可以去看linpack测试的时候，compute node上基本上不发生swap.
怎么回答呢，呵呵，说白了在计算主导的hpc应用中，就不应该发生swap,如果compute node上有硬盘的情况下不停的在swap,就得先把diskless的问题放一遍，因为你得先解决compute node的上面app和OS的swap的问题, 这个问题不解决，这个cluster的性能不会好的。我不知道这么说逻辑是否清晰。总而言之在一个建议使用diskless方案的hpc cluster系统中，首先我肯定的时候每个compute node的app和OS都sizing在最正确的状态，也就是不swap状态。当然这个是和你的应用直接相关的，如果cluster上面跑的是不停产生大量中间结果的应用，比如我以前做过一个项目，客户的物理计算软件在4个多小时内,compute node 会产生多个1G左右的中间文件，并且产生中间文件的过程是在不断的读写文件(增长),像这种应用就不能考虑diskless的应用了.

你提出的情况正好是diskless 反例的一种情况,嘿嘿，如果你的客户是属于这样的应用类型的，就只能考虑增加投资采取集中存储的方案了。

hpc不像商业系统有广谱方案，对症下药才能做到精确。

kartwall

嗯。。。没错，和我预想的一样。在我所接触的客户中，大部分应用都需要写临时文件，而且我们不能保证用户在集群上提交的每个任务都不用到SWAP，因为用户对计算机的了解是不多的，他们对自身的专业知识可能很精通。

OK，这个问题有答案了，谢谢NNTP的无私建议。

archangle

我以前测试过openafs,IBM的，不知道能不能适合你的情况。

kartwall

哦？不知道性能如何？读写小文件的性能如何？此外，如果某个节点的硬盘down了，openAFS的应对策略是？

archangle

哦？不知道性能如何？读写小文件的性能如何？此外，如果某个节点的硬盘down了，openAFS的应对策略是？

性能你估计要测测才知道，多个节点直接可以有复制，很久没用了，你可以看看文档。

myprotein

lustre和pvfs没有冗余措施么？
一个io节点down了，所有数据就不能访问了么？
是不是因为每个文件都被strip到所有io节点上？