http://hi.baidu.com/agg230/blog/item/8ace1f0e875f97ce7acbe1f9.html
2008年01月15日 星期二 下午 04:53
|
自:http://www.redhat.com/magazine/006apr05/features/gfs/
Some services have static data that can easily be split between servers. Using duplication, each server in the cluster hosts a copy of all the data. However, other services utilize dynamic data that is rapidly changing, and it is much more difficult to duplicate data. What these applications really need is access to a single data store that can be read from and written to by all servers simultaneously. The use of a file server (network attached storage server) supporting the NFS and CIFS protocols is the traditional approach for this kind of shared data. Linux, of course, offers these popular data sharing protocols, and this solution is suitable for some applications, but a single file server often becomes a performance bottleneck and single point of failure (SPoF) in the complete system. To solve the difficulty of using traditional approaches for scalable and simplified data sharing, every server in the cluster should have direct access to the storage device, and each server should be able to read and write to the data store simultaneously. The Red Hat Global File System (GFS) represents the heart of such a solution. It(gfs) combines Linux servers and a storage network (SAN) to create a data sharing cluster through a single shared file system base. Figure 2 shows the structure of a typical GFS storage cluster. The GFS file system is mapped onto a pool volume, which is constructed from one or more independent storage units. The servers(cluster) are connected with a storage network (SAN) over one or more data paths to the pool volume. The individual cluster servers are also connected via one or more data paths to the network. Thus every server can directly access the storage arrays onto which the pool volume is mapped, greatly increasing I/O system performance and providing scalability far beyond what can be achieved with a single NAS server.  The lock server coordinates the multiple servers which access the same physical file system blocks in a GFS storage cluster. It assures the file system's data consistency. From the beginning, GFS has been provided with a modular locking layer. In early GFS versions lock information was exchanged over the SCSI protocol (DLOCK, DMEP). Since GFS version 5, a redundant, IP-based user space locking service (RLM), which runs on all nodes ,has been used. Red Hat is working to integrate its distributed lock manager (DLM) into GFS 6.1, which will be released in the summer of 2005 Each server in the GFS cluster must heartbeat the lock server on a regular basis. If the server is unable to heartbeat, it will be selected by the lock manager to be removed from the cluster 1>由以上可见 集群文件系统和分布式文件系统有很大区别, 一个是有一个中心存储,多个client通过gfs连接到存储实体,各个client对数据的读写通过运行于各个client上的gfs来协调. 一个是分布在多个server上组成大的存储,然后对外提供统一接口/example,各个client只管读写数据,数据统一由server上的parallel file system manager管理. 1. cluster aware/wide FS ( TruCluster cluster wide FS, ocfs, ocfs2, polyserv, GFS ....) FS are locate on classic storage system such as DAS, NAS(netapp filer), SAN. 2. Parallel FS (lustre, SFS, GPFS, PVFS.....) FS are seperated on different computing system that Act as "storage Nodes" and "Storage Meta Nodes". Normally we use cheap IA server present those "nodes". 2>NFS原理是一台storage server, 然后多台"client" 挂载(mount) "storage server" 到本机, 看起来就如同本机一个目录,从而实现多client的共享, 没有锁的机制 3>lustre coda 则是分布式文件系统 一台manage server 数台metadata server 通过manage server虚拟出一个路径如同 /*/*/share-folder 然后多台client端通过安装 lustre/coda 客户端, 从而找到/*/*/share-folder 从而实现多台client共享. coda没有锁机制,通过client 的disconnect/connect不同状态,表示是否出现同时写一个文件出现冲突.若出现,需要手工解决. lustre还没看文档,但貌似支持锁机制 http://bbs.chinaunix.net/thread-746324-3-4.html GFS已经ok,我另外一台重起之后就好了 有个问题就是 只要其中一台写文件之后,另外一台访问这个目录ls 的时候要等个几秒钟才能显示,这样是什么问题呢? 还有个问题, GFS lock_dlm应该没有主服务器来控制lock把, 那为什么我把第一台重起的时候就会挂死, 第二台基本一访问gfs那个挂载点也是吊死了, 然后我把第一台Reset之后,启动正常之后 ,第二台才能访问那个GFS服务器 , 如果我重起第二台就不会有这个问题.郁闷中...不过我发现GFS很头痛的问题, 机器重起都成问题, 估计被cman fenced 这些进程吊在那边,比如我有2台机器,我在node1重起, node2再同时重起, 2台机器都一起掉死, 关不掉.没办法,只能按power 强制关机,然后node1启动到一半运行好ccsd cman fenced等服务时就等在那边, 非要等到node2也起来之后 才能继续启动下去,不知道是什么原因--这个是正确的，这个是为了GFS防止“裂脑”的手段。必须要达到一个 所谓法定人数才可以启动，最小是2个。运行过程中少于这个人数系统也要被挂起，直到满足 quorum 值。 这种基于san的并行文件系统解决方案，问题在于单点实效后如何重新让这个单点重新加入文件系统，ocfs2, gfs, polyserve这方面都不理想，polyserve由于是封闭的系统，折腾起来更困难，而且文件系统很脆弱，稍不如意就需要重新恢复。NAS这方面还是有优势的，至少前端服务器出现故障后，不会影响后端的数据。 lustre+SAN 这样效率不高，我已经做过了，而且成本让用户深恶痛绝.lustre最大的问题还是处理海量小文件，stripe不起太大作用. 偶有一个项目就败在这个上面。原来我们公司有一个lustre cluster, 前面是IA64的 hpc , 放在internet 上，谁都可以访问.http://www.testdrive.hp.com http://bbs.chinaunix.net/thread-672835-2-14.html 1。NFS是使用得最普遍的也是最稳定的网络文件系统。在很多HPC中都经常使用，因为做并行计算mpi时，往往需要共享中间过程产生的大量数据，或者是输入的采集数据非常大（几十GB甚至上TB）（在top500中，一些中低端的配置也用得不少吧）。但由于NFS是那种单server的模式，所以由此产生了NFS server的入口I／O带宽的瓶颈。解决这个问题的途径是，首先了解数据流的各个阶段，有将千兆网卡做bonding的，有将业务数据分组的，有使用 FC的高性能raid的。。。 2。从文件系统的角度解决NFS的并行性能的是使用并行文件系统，如PVFS，Lustre，我不知道将Lustre归于并行文件系统一类是否妥当。（Lustre号称在top500中被广泛使用）不过Lustre的牛人之一peter，我倒是见过，并且一眼看上去就是个搞研究的牛人。PVFS我看过早期的源码，实现原理简介明快，对于大文件I／O的聚集带宽性能应该是比NFS强，但metadata的HA，以及I/O server的HA，好像并没有冗余的设计，PVFS采用数据的网络分片方式并发处理I／O流，所以类似与网络的RAID0，但是一旦有一个 I／Oserver宕机或者干脆metadata宕机会很麻烦，不知道这些在PVFS2中得到改进没有（我有好久没有看PVFS了，不过我想PVFS2最好支持一下网络RAID5的数据分片，以提高数据的高可靠性。当然，这些都只是性能和可靠性之间的折衷了）。似乎lustre比PVFS在HA方面做得好一些。PVFS和Lustre，个人认为对小文件的支持肯定没有大文件好，这是由他们的原理来决定的。另外，向coda，似乎也是metadata和 I／O server的架构，具体没有去研究。 3。还有一个牛文件系统不得不提，这就是GFS。在sourceforge上有opengfs，后来sistina被RH拿了之后，sistina的看家技术GFS顺利成章的成为RH的solution了。GFS不同于PVFS等CFS，GFS应该来说是严格的分布式日志文件系统，不同于PVFS系统的关键在于，GFS的metadat和I／O real data都分布在一个逻辑的存储池上（这个存储池，可以是共享的SCSI盘阵或者光线盘阵，还可以上是iSCSI或者gnbd和lvm组合形成的虚拟可扩展存储块），和传统的本地文件系统类似，不同的是GFS的makefs工具和内核模块都是分布式的。当然GFS的性能，通过实际的使用，我觉得并不是很乐观，它使用dlm锁／gulm锁，似乎带来了性能的不少损失。不过，GFS似乎更通用一些，不向PVFS／Lustre对hpc支持得更好。GFS常常用于LB和HA的并行数据库应用当中。商业的这类FS，象Veritas的CFS好像也不错，和Oracle的rac配合的很好。 4。DAFS，搞存储的人都知道有个netapp，dafs号称可以改善数据通过网络的性能消耗，在对ＮＡＳ这类设备的改进有帮助。有netapp有用ＮＡＳ来支持oracle的系统的测试报告，性能好像不错，这个dafs应该发挥了作用。 1. lustre 的HA特性的确如你所说比PVFS好，而且是好得多。所以lustre 现在的license mode让独立研究人员深恶痛绝。(kick kick)，不过也从另外一个角度表达了这样一种意思，就是lustre可以更好的复合企业环境的应用，而不仅仅是hpc 的后端. 2. lustre/pvfs之类的分布式文件系统(包括GFS) 对于小文件的表现，仍旧如同传统文件系统那样，没有给我在具体项目中带来任何的希望. (实际上一度把我逼死). 我在这个论坛的另外一个帖子中详细写过关于小文件的在分布式fs上的性能问题. 就不重复了.在评估过GFS之后，我还是觉得lustre更加有希望领先于其他分布式fs进入商业应用的主流市场. 所以空闲下来后，我会花比较多的精力来琢磨. RHCS需要gfs支持以解决共享存储数据一致性保护和并发访问的问题. http://bbs.chinaunix.net/viewthread.php?tid=779132&extra=page%3D1 目前分布式文件系统比如 PVFS, lustre, 对于大量小文件的操作性能都一塌糊涂,原因很清楚, 在分布式文件系统中,通过多个服务器组成的IO cluster 建立一个跨越物理节点的虚拟的文件系统,当用户请求IO的时候,如果请求操作的文件块,被条带化在多个物理节点上, 多个物理IO节点和metadata node协同工作,可以并发的操作你的数据, 比如一个500MB的文件被条带化在10个节点上,如果存储策略是等分的,每个IO node并发的存取1/10的这个文件, node数越多, 存取速度越快.再来考虑小文件,比如16KB以下的文件, 当IO request过来的时候,metadata server发现这个data实际上并没有跨越在多个IO node上,而是位于一个server上,所以整个处理过程等同于IO client -> metadata server -> IO node, 当如果你有大量的小文件(<16KB)分布在若干个IO node上的时候, 存取的性能除了需要考虑单台IO node的IO延迟之外,还要加上整个分布式文件系统在同一读写的时候的元数据操作开销. 所以当你的数据文件尺寸越小, 整个文件系统的性能就越差. 我的一个朋友，在自己的一个HPC集群上，在每个节点上都划分出了一个分区，然后安装了lustre，每个节点既做为lustre的server和 client，同时也要做计算节点。发现一个有趣的现象，就是lustre装好了以后，在节点上跑计算程序，CPU的负载最高也就是50％，将 lustre卸掉之后就OK了，好像lustre预留了50％的CPU资源一样。按理说lustre是不提倡用户一个节点又做client又做 server的，所以我想也有可能是这方面的问题。 http://bbs.chinaunix.net/viewthread.php?tid=780672&extra=page%3D1 我的一些客户有一些高性能计算的集群，在64个节点左右规模。现在比较麻烦的是，用户没有更多的资金来购置存储设备（应该说钱已经全部投在这些计算集群上了），所以就开始整天打计算集群节点上那些硬盘的主义。为了满足他们的这种需求，我们已经先后给其安装过pvfs和lustre，两者的表现都不好。主要问题体现在，两者读写小文件的性能极不好，读写大文件时也不太稳定，而且由pvfs或lustre所构建出来的一个大逻辑硬盘（整合了所有计算节点上的空余硬盘分区），必须要所有节点全部开机后，这个硬盘才能正常工作，但是我们这些可爱的客户又比较喜欢关机，经常没事就会把集群关掉个一半或N台，美其名曰省电，等到下次再启动起来时，发现pvfs和lustre就总会出一些异常的问题，最终结果是我们很累。 现在我不知道除了pvfs或lustre之外，还有没有一些其他的分布式存储的方案，对性能已经没有要求了，换句话说，不一定要是并行化的读写数据，只需要能将分布的存储资源利用起来，整合成一个逻辑上的大存储设备，然后稳定一些就可以了。请教各位了。 1. 小文件性能有问题很正常的, 是此类型方案的技术局限 2. 大文件性能不好就不是pvfs2/lustre的问题，而是你的硬件不行.包括disk IO+ inter-connect 3. 购买hpc的用户因为运营资金的限制希望不要24h开机运行也是很正常，很合理的理由. 特别是像学校或者研究机构，他们的hpc采购都是国家学校的钱,但是日常运营费用就要自己来想办法了. 关于关机这个问题,我觉得是你们和客户的沟通上的问题, 完全可以通过技术手段把这个问题解决掉的. 所有的compute node全部diskless, boot from network, 把所有的compute node的硬盘全部集中到4-6台硬盘槽位多的服务器上,然后这4-6台服务器作分布存储. 这样并没有增加什么技术难度,也没有增加硬件开支,既可以解决IO的性能问题,用户要求关机节电的要求也可以满足了. 而且可以把作分布存储的node的处理器和内存数量降低,配到compute node上去,提高compute node的性能. 唯一我看到可能要增加硬件投入的就是多加几个网络交换机. |
