如果和尚说得对, 万般皆有因, 那么受苦将赐我们更接近神。 教导我们, 软弱时要坚强; 恐惧时要勇敢; 迷惑时要明智,抓不住的就要放手, 永久的胜利是在心中赢得,而非在一片土地上。

Lustre集群文件系统讨论

上一篇 / 下一篇  2007-05-22 13:53:08

就分布式文件系统而言, 分为三部分, client, metadata_server 和 data_server. 现在主流方向都是把metadata_server 和 data_server 分离. 象pNFS, GFS, panasys, Lustre, .... 只是他们分离的方式层次不同. GFS 实际上 client 和 metadata_server 实际上没有分离, 它只是在I/O 层次上对 data_server 进行了分布. pNFS 对 client, metadata_server 和 data_server 进行了彻底的分离, 但是它只是对NFS 进行了 简单的改进, 至少目前是这样, 很多其他相关的东西都没有考虑, 现在还只是实验室阶段. panasys 和 Lustre 结构上基本相似. 都是把三部分完全分离. "多client-单serve"
所以我太清楚你说的 单server 是指那部分, 如果是Metadata_server, 但是lustre 实际上已经实现了多个metadata-server. 但是对于用户来说, 好象没有报怨过metaserver 是瓶颈的说法, 其中包括 1000个节点(client)以上的lustre. L 说 GFS 是 peer to peer, 可能是因为 它的metadata_server 和 client 没有分离. redhat 从 sistina 买了 GFS 好象一直在推它, 不知道稳定性怎么样. 对于lustre 来说 client 和metadata_server 可以在一个节点.
对于GFS 而言, 在进行数据i/O 之前的所有操作都在本地, 只是在最后写 I/O 的时候要进行元数据的
同步以及真正的 I/O, 就我的理解, 它的元数据的同步在节点数目多的时候, 是相当费时的, 因此扩展性不强.根本原因还是分布的层次底, 导致扩展性不强. 以前听说GFS 最大是64个节点. 对于小的cluster 来说, GFS 确实是不错的选择. 对 lustre I/O, client 开始要和Metadataser 联系要获得 数据的分布信息, (不是同步, 因为这个分布信息 一经产生就不再变化) 然后直接和 dataserver 联系. 另外, client 端的cache 也使得很多时候, client 不必与metadataserver 联系.
其实对分布式文件系统来说, 分布式锁的基本原理都差不多, 都是revoke 和 cache 的refresh. 只是在grant和 revoke 时优化的机理不同. 但是这些优化对文件系统性能的影响相当大, 所以也是最难的一部分. 没有研究过GFS 的锁机制, 不过Lustre 的分布锁机制做了很多优化, 也很复杂. 另外Lustre 的网络使用的是portal, 它是专门为分布式系统设计的. 开始是美国sandia设计的, 不过CFS 对它做了很多改进. 目前可以支持 Quadrics ELAN, TCP . Infiniband . Myrinet等很多流行高速网,

TAG:

 

评分:0

我来说两句

日历

« 2024-04-24  
 123456
78910111213
14151617181920
21222324252627
282930    

数据统计

  • 访问量: 11801
  • 日志数: 18
  • 建立时间: 2007-05-18
  • 更新时间: 2007-10-26

RSS订阅

Open Toolbar