讨论帖：建立一个Linux集群（开始配置集群软件，2楼提供更新的目录）

yuba

原帖由 ubuntuhk 于 27-6-2009 19:48 发表

                               
登录/注册后可看大图

哪个办法？

"远程配置网卡bonding失败，导致一台机器暂时无法控制"的办法

ubuntuhk

哪里需要那么费劲，直接把网线拔了就好了

ubuntuhk

正如前面各位同学介绍的（coredump、yuba等），分布式存储系统，有很多选择，每种选择都有自己的特点，所以我们需要根据自己的需求来选择最适当的存储系统。

这里有一个完整的文件系统的介绍（包括本地文件系统和分布式文件系统）：
http://en.wikipedia.org/wiki/List_of_file_systems
(估计要吓你一跳，原来这世界除了fat32/ntfs/ext3/zfs/xfs...竟然还有这么种文件系统 )

分布式存储系统依赖于本地文件系统（当然有些文件系统兼有2种功能，比如RedHat GFS），我大体评估了一下，可用的文件系统如下：
1.本地文件系统
Ext3:http://en.wikipedia.org/wiki/Ext3 （Linux默认的分区，但是性能一般）
GFS2:http://en.wikipedia.org/wiki/Global_File_System2 （CentOS默认支持的Cluster存储方案，性能不俗，方便安装）
JFS: http://en.wikipedia.org/wiki/JFS_(file_system)
XFS: http://en.wikipedia.org/wiki/XFS （性能不错，但据网友反映，当不正常关机之后，可能对文件系统完整性有严重影响）
RealiefFS:http://en.wikipedia.org/wiki/ReiserFS

2.分布式文件系统
1.NFS: http://en.wikipedia.org/wiki/NFS （老牌的网络存储系统）
2.GFS: http://en.wikipedia.org/wiki/Global_File_System2 （CentOS自带的Cluster存储系统，扩充性和可靠性都不错）
3.Lustre:http://en.wikipedia.org/wiki/Lustre_(file_system) （带有一定冗余性的分布式存储系统）
4.AFS: http://en.wikipedia.org/wiki/Andrew_File_System （老牌的网络存储系统）

经过一通比较，我感觉RedHat GFS更适合我目前的应用：
1.CentOS系统自带（这意味着我不需要编译新的文件系统，省了很多麻烦）
2.即可作为本地文件系统，又可以作为分布式文件系统（经过进一步了解，GFS作文本地文件系统有致命的兼容性问题，比如不支持fork()信号量，所以还是得舍弃）
3.可以方便的扩展容量和节点，而且有冗余特性（这一点大部分分布式系统都有这个功能）

有关GFS的管理手册，很详细：
http://www.redhat.com/docs/manuals/csgfs/pdf/rh-gfs-en-5_2_1.pdf

这里有个Blog提供了GFS安装的一些有用的知识：
http://roala.blogspot.com/2007/12/centos-5-gfs.html
安装GFS一定要装ntpd，定时自动同步服务器的时钟。


这篇Blog里面推荐Coraid SR1521作为廉价的SAN存储设备，
http://www.coraid.com/PRODUCTS/SR1521

• SATA/RAID 3U - 15 disk, hot swap, storage appliance
• Supports 15 SATA I or SATA II disks (disks not included)
• Dual GigE interface to AoE storage
• Includes RAID Controller for RAID 0,1,5,10 or JBOD with hot spares
• Access speed > 200 MB/s
  

售价USD3,995（约RMB3w），不包括硬盘。我个人感觉价格一般般。

ubuntuhk

仔细了解了一下ZFS的特性，发现这是一个革命性的文件系统，这个blog详细介绍了ZFS的特性：
http://blog.ccw.com.cn/blog.php? ... blog-type-blog.html
Solaris 10 最新版：使用ZFS的十条理由 - ZFS特性介绍

上个月，Sun Microsystems公司正式发布ZFS（Zettabyte File System）文件系统。ZFS是第一个128位的文件系统，同时ZFS又被Sun Microsystems称作史上最后一个文件系统。因为这个文件系统含有多项创新技术，不仅成功地解决现有文件系统的问题和陋习，而且前瞻性地考量了未来对存储空间的需求，单个文件系统可以达到256 quadrillion（264） Zettabytes（221）。 ZFS不仅符合POSIX文件系统的标准，而且提供了许多高级功能比如：Quota(配额)，Reservation(预留)， Compression(压缩)， Snapshot(快照)，Clone（克隆）等。如果你还在坚持使用现有32位或者64位的文件系统，如果你还在“痛并不快乐着”地用着各式各样的 Volume Manager，那就很值得看看这里列出的使用ZFS的十条理由。

1. 再也不需要fsck， scandisk EKdL,k}  

不管你是在用Linux，UNIX还是Windows，相信大家都有过类似的体会：当系统意外断电或者非法关机，系统重起后发现文件系统有inconsistent的问题，这时 候就需要fsck或者scandisk 来修复，这段时间是非常耗时而且最后不一定能够修复成功。更糟糕的是，如果这是一台服务器需要做fsck的时候，只能offline（下线），而且现有应用往往都是大硬盘，相应fsck修 复时间也很长，这对许多使用该服务器的用户来说几乎不能忍受的。 LPb]+bp!kq  
而使用ZFS后大家可以彻底抛弃fsck这种工具，因为ZFS是一个基于COW（Copy on Write）机制的文件系统。COW是不会对硬盘上现有的文件进行重写，保证所有硬盘上的文件都是有效的。所以不会有这种inconsistent的概念，自然就不需要这种工具了。

2. 管理简单



ZFS作为一个全新的文件系统，全面抛弃传统File System + Volume Manager + Storage的架构，所有的存储设备是通过ZFS Pool进行管理，只要把各种存储设备加 入同一个ZFS Pool，大家就可以轻松的在这个ZFS Pool管理配置文件系统。大家再也不用牢记各种专业概念，各种命令newfs， metinit及各种Volume Manager的用法。在ZFS中我们只需要两个命令，zpool(针 对ZFS Pool管理)和zfs(针对ZFS文件系统的管理)，就可以轻松管理128位的文件系统。举个例子，我们经常会遇到系统数据增长过 快，现有存储容量不够，需要添加硬盘，如果依照传统的Volume Manager管理方式，那我 们需要预先要考虑很多现有因素，还要预先根据应用计算出需要配置的各种参数。在ZFS情况下，我们的系统管理员可以彻底解放，再也不需要这种人为的复杂 考虑和计算，我们可以把这些交给ZFS，因为ZFS Pool会自动调节，动态适应需求。我们只需一个简单的命令为 这个ZFS Pool加入新的硬盘就可以了：
zpool add zfs_pool mirror c4t0d0 c5t0d0

基于这个动态调节的ZFS Pool之上的所有的文件系统就可以立即使用到这个新的硬盘，并且会自动的选择最优化的参数。

3.      没有任何容量限制

ZFS（Zettabyte File System）文件系统就如其名字所预示，可以提供真正的海量存储，在现实中几乎不可能遇到容量问题。在现有的64位kernel（内 核）下，它可以容纳达到16 Exabytes(264)大小的单个文件，可以使用264个存储设备，可以创建264个文件系统。

4.      完全保证 数据 的正确和完整

由于ZFS所有的数据操作都是基 于Transaction（事务），一组相应的操作会被ZFS解 析为一个事务操作，事务的操作就代表着一组操作要么一起失败，要么一起成功。而且如前所说，ZFS对 所有的操作是基于COW（Copy on Write）， 从而保证设备上的数 据始终都是有效的，再也不会因为系统崩溃或者意外掉电导致数据文件的inconsistent。

还有一种潜在威胁 数据的可能是来自于硬件设备的问题，比如磁 盘，RAID卡的硬件问题或者驱动bug。现有文件系统通常遇到这个问题，往往只是简单的把错误数据直接交给上层应用，通常我们把这个问题称作Silent Data Corruption。而在ZFS中，对所有数据不管是用户数据还是文件系统自身的metadata数 据都进行256位的Checksum（校 验），当ZFS在提交数据时会进行校验，彻底杜绝这种Silent Data Corruption情况。

5.      提供优异 性能和扩展性

和传统File System + Volume Manager + Storage架构不同，ZFS则是直接基于存储设备提供所有的功能，因此有自己独有的创新特性，性能自然非比寻常。

Dynamic Striping vs. Static Striping

由于ZFS是基于COW和一个全局动态的ZFS Pool，任何一次写 操作，都是对一块新数据块（Block）的一次写操作。ZFS从ZFS Pool中动态挑选出一个最优的设备，并且以一个transaction（事 务）线性写入，充分有效地利用了现有设备的带宽，我们把这个特性称为Dynamic Striping。而相对应的Static Striping则是传统文件系统所使用的方式，Static Striping需要管理员预先对这组Stripe进行正确地计算人为 设置，而且如果加入新的设备则需要再次人为的计算和设置，更为严重的是如果人为计算错误，则会直接影响系统的性能。而在使用Dynamic Striping这种特性之后，我们根本不需要人为介入，ZFS会自动调整，智能的为你 提供最佳的设备，最快的操作方式。 R}c4pf  
S;'.y   

支持多种 大小的数据块（Multiple Block Size）

ZFS支持多种大小的数据块定义，从512字节到1M字节。和传统文件系统往往都是固定大小数据块不同，ZFS则是可以动态的根据不同 大小的文件进行计算，动态的选择最佳的数据块。

因为不同大小数据 块，直接影响到实际使用硬盘容量和读取速度。如果使用较小的数据块，存储文件所导致的碎片则较少，读写小文件更快一些，但是会导致需要创建更多的metadata，读写大文件则会更费时。如果使用较大的数据块，使用的metadata较少，更利于读写大文件，但是会导致更多的碎片。ZFS根据实际调查现有文件使 用的情况，分析出一个选择数据块大小的算法，动态的根据实际文件大小确定最佳的数据块。所以ZFS是 非常智能的，在不需要系统管理员介入，就可以得到一个自我调优的结果。当然ZFS也支持用户对单个文件或者整个文件系统 所使用的数据块大小的自定义设置。

智能预读取（Intelligent Prefetch）

多数的操作系统都 有这种将数据预先读取的功能，而ZFS则是建立在文件系统上直接提供的一种更加智能的数据预读取功能。它不仅可以智能地识别出多种读取模式， 进 行提前读取数据，而且可以对每个读取数据流进行这种预读取智能识别，这个对许多流媒体提供者来说是件非常好的事情。

在扩展性上，和现有文件系统多是基于一个受限的静态模型不同，ZFS是采用ZFS Pool这个动态概念，它的metadata也是动态，并且读写操作都是可并行的，并且具有优先级概念，所以即使在大数据量，多设备的情况下仍可以保证性能的线性增长。

6.      自我修复功能

ZFS Mirror 和 RAID-Z

传统的硬盘Mirror及RAID 4，RAID 5阵列方式都会遇到前面提到过的问题：Silent Data Corruption。如果发生了某块硬盘物理问题导致数据错误，现有的Mirror，包括RAID 4，RAID 5阵列会默默地把这个错误数据提交给上层应用。如果这个错误发生在Metadata中，则会直接导致系统的Panic。 而且还有一种更为严重的情况是：在RAID 4和RAID 5阵列中，如果系统正在计算Parity数值，并再次写入新数据和新Parity值的时候发生断电，那么整个阵列的所有存储的数据都毫无意义了。

在ZFS中则提出了相对应的ZFS Mirror和RAID-Z方式，它在负责读取数据的时候会自动和256位校验码进行校验，会主动发现这种Silent Data Corruption，然后通过相应的Mirror硬 盘或者通过RAID-Z阵列中其他硬盘得到正确的数据返回给上层应用，并且同时自动修复原硬盘的Data Corruption 。

Fault Manager 1j'TH.K~#  

在Solaris 10中，包含 一个ZFS诊断引擎和Solaris的 Fault Manager（这也是Solaris 10的 另一个新特性）交互，可以实时地诊断分析并且报告ZFS Pool和存储设备的错误，用户可以通过Fault Manager及时得到一个非常友善的消息。这个诊断引擎虽然不会采取主动的行为去修复或者解决 问题，但是会在消息中提示系统管理员可采取的动作。类似下面一个ZFS报错消息，其中REC-ACTION就是建议采取的动作：

SUNW-MSG-ID: ZFS-8000-D3， TYPE: Fault， VER: 1， SEVERITY: Major

EVENT-TIME: Fri Mar 10 11:09:06 MST 2006

PLATFORM: SUNW，Ultra-60， CSN: -， HOSTNAME: neo

SOURCE: zfs-diagnosis， REV: 1.0

EVENT-ID: b55ee13b-cd74-4dff-8aff-ad575c372ef8

DESC: A ZFS device failed. Refer to http://sun.com/msg/ZFS-8000-D3 for more information.

AUTO-RESPONSE: No automated response will occur.

IMPACT: Fault tolerance of the pool maybe compromised.

REC-ACTION: Run ’zpool status -x’ and replace the bad device.

7. 安全

在安全上，ZFS支持类似NT风格NFSv4版的ACL（读取控制列表）。而且前面所提到的256位验证码，用户可选择多种验证方式，包括SHA-256验证算法，从而在物理存储单元级别上保证数据的安全性。

8. 超强功能

ZFS作为“最后一个文件系统”，涵盖了基本的文件系统和Volume管理的功能，同时 一并提供许多企业级别的超强功能：Quota(配额)，Reservation(预留)， Compression(压 缩)， Snapshot(快照)，Clone（克隆）。并且速度非常快。有了这个文件系统，大家再也不需要任何Volume Manager了。

兼容性

ZFS是一个完全兼容POSIX规范的文件系统，所以处于上层的应用程序是完全不受影响。ZFS也提供一个Emulated Volume模块，可以把任何一个ZFS文件系统作为普通的块设备使用。同时ZFS也可以使用基于Volume Manager构建的Volume作为存储设备单 元。这样在不需要修改应用程序，不修改已有文件系统下，给了大家最大的自由度去获得ZFS提供的各 种特性。

10. 开源

ZFS是Sun Microsystems公 司作为OpenSolaris的一个开源项目运作并且完全免费使用，点击这里(http://www.opensolaris.org/os/community/zfs/source/) 可以直接浏览到ZFS的代码。 这就代表着我们不仅同时可以享受商业公司的高质量，也可以获得开源模式的优点。

虽然目前只有Solaris支持该文件系统，但是这种开源的模式必定会促进更多基于ZFS的应用。现在已经有国外开发者正在将ZFS移植到Linux和Mac OS上来。如果想要体验一下ZFS，由于目前它和Solaris 10绑定在一起，所以需要下载最新版的Solaris 10 6/06 (http://www.sun.com/software/solaris/get.jsp)。

确实非常吸引人啊，可惜ZFS使用Common Development and Distribution License (CDDL)协议，和GPL协议冲突了，所以无法加入到Linux内核支持里面。

难道我要搞一台机器装一下OpenSolaris体验一下？还是找找如何将ZFS加入到Linux的方案（据说有曲线方案可以在Linux上实现ZFS的支持）。

yuba

ZFS的这些特性，除了128bit以外，其他的很快都会原生地在Linux上出现

ubuntuhk

你是说Linux在重新实现一个山寨ZFS？

但是Sun是有意让ZFS的Licence和GPL不一样，而且还申请了56项专利作为护身符，不知道Oracle收购Sun之后，会不会加入GPL的支持。

我看了一下ZFS on FUSE/Linux这个项目，支持得并不完美，而且作者也没有投入很大的支持力度来继续优化这个项目的代码：
http://zfs-on-fuse.blogspot.com/

有网友的benchmark显示它的性能只有XFS的一半：
http://www.csamuel.org/2007/04/2 ... or-fuse-performance

本地文件系统我可能还是要考虑XFS或者JFS，得看看这两个文件系统有什么优缺点，大家有经验的请给我一些意见。

yuba

我的路线图

ext4 -> btrfs -> nilfs2

jessiekant

nilfs2除了比较适合ssd之外还有什么优势，能介绍介绍吗？

ubuntuhk

你现在在用ext4吗？感觉如何？我初步的印象是它是基于ext3上的文件系统，所以无法根本性克服ext3所存在的问题（管理大分区性能较差）。

至于Btrfs，现在还远未到成熟的地步，将来再看吧，kernel.org的wiki上有这么一段话：

Btrfs is under heavy development, and is not suitable for any uses other than benchmarking and review. The Btrfs disk format is not yet finalized, but it will only be changed if a critical bug is found and no workarounds are possible.

nilfs2我更是第一次听说，得多做点了解。

ubuntuhk

看了这篇文章，对ext4有更多的了解，基本上也是一个新的文件系统，不够成熟，未经过太多时间验证，所以也不考虑了：
http://www.ibm.com/developerworks/cn/linux/l-ext4/index.html

这里有一篇ext4的benchmark，跟帖评论者意见纷纷，没有看到很多坚定支持ext4的意见，我现在时间不多，只能选择相对稳定，经过时间考证过的文件系统了：
http://linuxtoy.org/archives/ext4-benchmarks.html
该文结论如下：

结论： 在 Bonnie++，IOzone, 和 Flexible IO Tester 三个纯理论性能测试软件中 EXT4 取得了八项测试中五项第一，XFS 取得了剩余三项的第一名。除非你的工作就是测试文件系统的理论性能，这个结果并不能说明太多。

在 Nexuiz，World of Padman，和 Unreal Tournament 2004 这三个游戏的测试中，四个文件系统的表现十分相近，这意味着迁移文件系统到 EXT4 或者 XFS 上并不能获得更高的游戏运行帧速。

文件压缩测试中，EXT4 和 XFS 一起分享了头把交椅，没有给其他文件系统一点空间。

而在多媒体编码测试中，四个文件系统各有胜负，这意味着高清爱好者们并不需要立刻切换到新的文件系统上，老的 EXT3 依然不错。这一点同样体现在加密测试中，EXT3 摘得 GnuPG 加密测试冠军，而 EXT4 则占据 Bork 加密测试的性能表现宝座。

尽管在实际效能测试中 EXT4 并没有带来如在纯理论测试中那么大的性能提升，但是迁移到 EXT4 文件系统并不是完全没有好处的。EXT４文件系统相比它的前任提升了分区容量上限，增加了可允许的子目录数，并且增加了热碎片整理和日志校验码的功能。最重要的是，这些新功能的引进并没有对稳定性带来影响，它一如既往的安全高效。作为一个在 Btrfs 获得广泛应用之前的过渡品，EXT4 值得你考虑。

也许我该继续使用EXT3。

由这个benchmark的网页，发现了一款测试IO性能的工具：Bonnie，
这里有一些详细的介绍： http://www.eygle.com/unix/Use.Bonnie.To.Test.IO.speed.htm
这是bonnie的官方页面： http://www.textuality.com/bonnie/

yuba

原帖由 ubuntuhk 于 28-6-2009 12:52 发表

                               
登录/注册后可看大图

你现在在用ext4吗？感觉如何？

正在用，分区不大，没有特别的感受

在元数据方面ext4的改进解决了ext3的性能问题

Fedora 11已经默认是ext4文件系统了，并且引入了btrfs

可以说ext4已经成熟了，没有特别原因的话，已经可以放弃ext3了

[ 本帖最后由 yuba 于 28-6-2009 17:15 编辑 ]

yuba

原帖由 jessiekant 于 28-6-2009 12:32 发表

                               
登录/注册后可看大图

nilfs2除了比较适合ssd之外还有什么优势，能介绍介绍吗？

btrfs和nilfs2都提供zfs引以自豪的快照功能

btrfs极有可能成为Fedora 12的默认系统

Linux 2.6.30将引入对nilfs的支持

ubuntuhk

看了网友的评论，Fedora确实很进取，btrfs这种官方都承认不成熟的文件系统都敢引入

ubuntuhk

chinaunix上有几篇帖子不错，和大家分享一下，可以时间都有点久了:
有关集群文件系统的比较讨论（不是很深入）： http://bbs3.chinaunix.net/viewth ... p;extra=&page=1
RedHat GFS介绍：http://linux.chinaunix.net/bbs/viewthread.php?tid=777867
ChinaUnix上有关集群文件系统的讨论帖索引： http://linux.chinaunix.net/bbs/viewthread.php?tid=781785
Lustre的测试工具集：http://linux.chinaunix.net/bbs/thread-914505-1-1.html

看到一个牛人自己分析的google内部架构，虽然比较粗略，但是也挺有启发性：
http://cbcg.net/talks/googleinternals/index.html

看到这个帖子：
讨论分布式存储和计算节点之间的复用矛盾：http://bbs2.chinaunix.net/viewthread.php?tid=780672

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

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

A：
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的性能. 唯一我看到可能要增加硬件投入的就是多加几个网络交换机.

ubuntuhk

继续引用CU上面nntp的帖子，对我启发非常大，让我更清楚地意识到目前的应用可能需要什么方案：

Q:
用PVFS2 搭建了一个 1 IO client，3 IO server的架构， IO server使用本地的 IDE硬盘。
使用 IOzone测试，在测试过程中，发现 读写的块越大，性能越好， 如下，第一列是文件大小，第一行为块大小,单位为kB：
            64        128        256        512        1024        2048        4096        8192
32768        22417        31767        47938        65769        75807        83918        88573        88973
65536        20900        32689        42910        66529        77538        84766        87415        88472
131072        19465        34990        45330        65079        76348        82455        87738        87950
262144        20148        31539        45970        39854        77824        83332        88841        87776
524288        21090        33517        48185        64404        77262        84647        88657        87929
1048576        20079        24960        38063        45894        75932        61022        53082        50351
2097152        18595        30156        47571        49094        57575        83622        88007        88119

但是在实际的应用中，比较说用户去读取一个文件，是不是都是有一个默认的块大小？这个块的大小实际使用中是如何修改？或者说我如何调优性能！
非常谢谢！有没有高手帮忙

A:
Hello,

目前分布式文件系统比如 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延迟之外,还要加上整个分布式文件系统在同一读写的时候的元数据操作开销. 所以当你的数据文件尺寸越小, 整个文件系统的性能就越差.

回头说你的例子, 你每个IO node都是IDE 硬盘,IDE硬盘速度再快,但是并发性很差, 特别是大量数据(小文件)读写的时候,IDE硬盘的性能一败涂地, 更加不要说你的IDE channel和system bus之间的延迟了.
还有就是你选择IDE 硬盘的服务器+PVFS2正好是错误的选择,因为PVFS2和PVFS1还有lustre不一样,他的代码都是重新写的,而且用了分布式的 metadata ,PVFS2里面再也没有独立的一个metadata server存在了,也就是说,所有的IO node之间在每次IO操作,文件定位等等,都要比single metadata 的方案开销更大,有更多的延迟累加, 分布式的metadata设计+本来并发和IO都不太好的IDE硬盘的服务器, 你说性能会好么?  PVFS2的重新设计,完全是定位在高端用户的,Argonne 国家实验室和Clemson大学的重新开发PVFS2的初衷就是使得这个分布式文件系统完全摆脱PVFS1的socket network的结构,这样新的高端集群互联设备比如Infiniband, Myrinet,Quadrics就可以派上用处了.

优化的方法不多,下面列几条你可以试试看:

1)如果你现在只是测试的话,你可以这样做, 你把配置文件当中<StorageHints>这个章节的"TroveSyncMeta"和"TroveSyncData" 从yes改为no, 这样性能应该会有看得到的提高,每次IO node之间同步metadata的时候,就直接从cache里面读,而不是去读metafile了,当然如果服务器挂掉,数据也就废了.

2)我建议你把节点的硬件配置提高, IDE硬盘的设备不适合作这种应用,尤其是和PVFS2这种连metadata都分布的系统一起工作. 节点之间的交换速度要尽可能得快,把交换机的自动协商关掉,mii-tool把linux的网卡的自动协商也关掉,速度定死在1000MB上.

3)如果你用的是RHEL4U2的话,它里面带的ext3和PVFS2一起工作会有问题,你得用U3或者mount你的IO node上的 ext3的时候,用noreservation的开关.否则会对PVFS2的性能造成影响.

4) 你如果一定要用PVFS2的话,就要明白PVFS2是读写文件块的时候,是不用cache机制的,只有metafile的属性控制彼此同步的时候会用 cache,所以不管你用bonnie++还是IOzone他们都是用来对本地文件系统作测试的,测试用的都是很小的文件区块,这种测试方法本身就是不正确的,不管最后测试出来的结果如何,都不能正确的告诉你,你面前的这套PVFS2集群到底性能有多大.
测试并行分布式文件系统的工具有很多, PVFS2建议你用IOR (http://www.llnl.gov/asci/purple/benchmarks/limited/ior/), 你可以去测试一下,不要太在意IOzone的测试结果,那个在并行文件系统上测得不准.

5)如果你没有Infiniband,Myrinet的高速互联和快速的scsi 服务器,并且你以后跑的应用不会用到PVFS2的MPI-IO, 我建议你可以考虑Lustre而不是PVFS2.

6). PVFS2的性能还和IO server上的local filesystem的类型有关系, jfs 性能最好,其次是ext2, 然后是xfs, 然后是ext3(用writeback日志策略),然后是reiserfs,然后是ext3(默认的日志策略是ordered).  所以从兼容性和管理等方面权衡,你可以用 ext3( mount -o data=writeback, writeback日志策略).

7) 检查你的IO server的 buffer 设置 /proc/sys/net/core/rmem_default 和 /proc/sys/net/core/wmem_default

性能诊断和优化是非常复杂的工作,特别是在分布式的文件系统上,你要对各种并行文件系统本身和linux系统还有你的应用环境有非常深刻地认识, 调优的过程通常就像一个跷跷板,做得不好的话,一头高了,一头就低下去了, 你需要在精通上面这些技术的基础上,设计出针对你最终应用的几种方案,以便于从offline的tuning转向online tuning的工作.

good luck,

ubuntuhk

NAS、DAS、SAN的区别到底如何？我有点混淆，特别是NAS和SAN，看了wiki上一些资料，总算有更多的认识了：
http://en.wikipedia.org/wiki/Network-attached_storage
http://en.wikipedia.org/wiki/Storage_area_network

DAS：直接附加到单一设备上的外部存储设备，比如DELL MD1000这样的外置磁盘柜，主机可以把这种外接存储设备当作内置的硬盘来用；
NAS：本身是一个网络存储设备，带有特定的文件系统，通过某种或多种分布式文件协议（如：SAMBA、NFS、AFS等），供多台客户端进行连接使用；
SAN：可以当作通过远程网络连接的DAS，使用iSCSI等协议，可以组成海量存储系统，一般通过高速网络（如光纤）进行连接，这种设备一般价格比较高昂，往往只有大企业才有能力投资。

为什么要用SAN,它的好处包括：
1.传统的iSCSI电缆只能支持几米远，而利用光纤技术，可以将SAN设备放置在两个不同的城市，对于911这种灾难，如果有两个SAN设备进行冗余配置，就能很快进行数据恢复
2.可以将机器设置成从SAN中启动，一旦某台机器出现故障，利用SAN启动技术，就能很快将工作切换到另外一台机器上，这种技术已经在一些data center中进行应用
当然，SAN最大的门槛还是价格高昂，很贵很贵。。。。

下面这个图片更直观一些：

                               
登录/注册后可看大图

实际可能是这样应用的：

                               
登录/注册后可看大图

SAN-NAS混合技术：

                               
登录/注册后可看大图

ubuntuhk

倾向下面这个存储方案：
NFS+JFS/EXT4/EXT3

本地文件系统选用JFS或EXT4或EXT3，还需要具体实验测试过才决定。

在ChinaUnix上考察了一圈，才发现，目前那些集群存储系统（GFS、Lustre等）对我的应用来说，太复杂了，不一定能发挥集群存储的优势，而且管理和维护的成本太高了。

ubuntuhk

CentOS5.3支持Ext4文件系统，但我安装的CentOS 5.2不支持EXT4分区，需要升级到5.3，使用内核2.6.18.128.el5或以上版本才支持ext4，方法如下：
1.yum -y update  (将CentOS的软件包升级到最新版本)
2.yum -y install e4fsprogs (CentOS 5.2不包含ext4相关的管理软件，所以需要额外安装，CentOS5.3就不需要执行这个操作了)
3.reboot （重新启动机器，以启用新的内核）
4.uname -a （查看运行的内核版本信息，确保已经升级到最新的内核了）

现在CentOS5.2也是以最新的支持EXT4的内核来运行了。

创建、加载EXT4分区的办法如下（假设我的EXT4分区设备为/dev/sda7，并且mounte到/disc2.ext4）
1. mke4fs /dev/sda7
2. mount  /dev/sda7 /disc2.ext4

done。

注：
截至这个内核版本：2.6.2.18-128.el5，CentOS还不支持EXT4的delay allocation的特性（主要对写入文件的性能有提高，延迟判断分配给文件的block size），这个特性号称能提升文件系统的性能，估计CentOS 5.4会支持EXT4这个特性。

ubuntuhk

摘自：http://www.eygle.com/archives/2008/11/larry_cloud_computing.html

原来不是只有我不懂云计算的概念

关于云计算，在2008 Oracle Open World大会上，Larry Ellison已经发表了一番精彩的言论。

Larry言及：
"有趣的是，云计算概念已经被我们扭曲了，现在的云计算概念几乎包括了我们要做的一切。你甚至找不到一家不宣称自己是云计算的。计算机行业是唯一一个比女性时装界还要追逐概念和潮流的行业。也许我是个笨蛋，但是我真的搞不懂他们在说些什么。到底什么是云计算呢？完全是胡扯。这很荒唐，这种愚蠢什么时候能够停下来呢？"

"好吧，（假如）我们也宣称我们是云计算，我们不跟云计算对着干。但是，我们真的不知道，我们每天做的有什么不同，云计算对我们顶多是个广告概念。这就是我对云计算的看法"，拉里·埃里森说。

chubbycat

原帖由 coredump 于 25-6-2009 21:20 发表

                               
登录/注册后可看大图

这篇分析文章不错：What is the Best Clustered File System？

Or Veritas's CFS/CVM

http://www.symantec.com/business ... cluster-file-system

coredump

终于把老猫吸引过来啦

coredump

Larry Ellison关于Cloud Computing的评论: What The Hell Is Cloud Computing?                                                                                                                                                                                                                                                                                                                        摘自：http://www.eygle.com/archives/2008/11/larry_cloud_computing.html

原来不是只有我不懂云计算的概念

千万别把Larry Ellison 和Steve Jobs两个人说得话当真

Tux

想起看到过hutuworm写的关于7种文件系统性能之比较，估计对U版有用，有一定的参考价值。

http://hutuworm.blogspot.com/2009/02/ext4-reiserfs-btrfs.html

ubuntuhk

原帖由 chubbycat 于 29-6-2009 05:33 发表

                               
登录/注册后可看大图

Or Veritas's CFS/CVM

http://www.symantec.com/business ... cluster-file-system

肥猫卖广告来了

打倒一切要钱的软件（对不起，不包括我们要卖的）

ubuntuhk

原帖由 coredump 于 29-6-2009 09:36 发表

                               
登录/注册后可看大图

千万别把Larry Ellison 和Steve Jobs两个人说得话当真

哈，后来我才回味过来，原来是Larry担心自己的Oracle被云端数据库拉下马，故意装糊涂

但是云是个纯概念不假，没有一种清晰的软硬件架构叫“云”，只要是提供分布式服务，都可以叫云。

ubuntuhk

原帖由 Tux 于 29-6-2009 11:02 发表

                               
登录/注册后可看大图

想起看到过hutuworm写的关于7种文件系统性能之比较，估计对U版有用，有一定的参考价值。

http://hutuworm.blogspot.com/2009/02/ext4-reiserfs-btrfs.html

非常不错的评测报告，我把数据表和结论摘抄过来（IOZone测试的）：
结论：

本次测试所使用的 Linux kernel 版本为 2.6.29-rc3，文件系统性能测试工具为 IOzone 3.318。

从测试结果可以看出，Ext4 的综合性能位居现有文件系统之首，JFS、ReiserFS 在读性能方面亦有不俗表现。Btrfs 的小块数据读写性能与平均水平相差甚远，是导致其本次测试总时间超出平均时间两倍的主要原因。较之其它成熟的文件系统，Btrfs 投入生产系统运作可能尚需时日。

测试数据见附图，原作者的网页因为排版问题，无法显示完整数据，我做了重新排版，请参见附件doc文件。

ubuntuhk

我还没看到上表中的红字部分的数据代表的意义，哪位明白的给俺指点一下

coredump

红字是对应指标的最高值

ubuntuhk

红字是好的，这个我猜到了，具体是什么意思呢？

刚刚又看了一下，原来原表格下面有个(kbytes/sec)，所以各项数值是越高越好。

Tux

新鲜出炉的ext4/btrfs/nilfs2评测！！！还是热乎的。

http://www.phoronix.com/scan.php ... fs_nilfs2&num=1