有奖讨论：寻找节省数据存储成本的有效措施！存储虚拟化、分布式文件系统、集群NAS

一刀砍死

freeNAS/iSCSI

dynasty

存储虚拟化，支持！

草上飞2008

原帖由 草上飞2008 于 2009-7-6 09:35 发表
前段时间讨论了数据备份省钱之道，现在，在2009系统架构师大会召开之前，我们再次展开“数据猛增，如何有效降低数据存储管理成本？”的主题讨论，欢迎大家积极参与。

    话题背景：在当前的经济危机下，企业 ...

转一下：ecloud的发贴，

集群技术中，最令人头痛的就是文件的共享，尤其是那些需要读写操作，并且非常频繁的
当前在这方面的技术很多，包括使用NAS/SAN，NFS等传统的网络共享，或者rsync这种非“实时”的方式等等，以及新兴的“网络文件系统”，具有代表性的就是Google

我认为，在普通的网站、电子商务、BS应用软件等领域，过分的研究网络文件共享是有点南辕北辙了
我们为什么那么执著于通过网络共享某个文件，而不从另一个角度改变我们使用这个文件的方式呢？或许我们原本可以不使用这个文件的呢？
因此我认为，我们应该更加从应用层的角度来设计、优化我们的集群而不是过分追求底层的东西。以前我们的一些观点是错误的，“一个为单机运行设计的程序，使可以直接放在一个集群的环境中得到加倍的效果”，这种观点是非常大的误解。网络环境同单机环境有着很大的不同，只有为集群环境量身定做的程序才能够最大限度发挥出效能，同时也便于管理和使用。
幸运的是我们并不需要自己动手来大量的修改我们的程序，现在已经有许多的现成的应用框架，我们可以直接使用。
比如，Websphere ND就是一个非常好的集群应用服务器，标准的ear或者war包可以不需要任何的修改直接部署在Websphere ND环境中，就可以提供集群化的应用服务，所有的session和数据库连接池的处理都由应用服务器来完成，不需要任何人工的干预。
当然这一切的根本是J2EE内建的技术规范提供的良好支持，同样Weblogic和iPlanet等其他的应用服务企业提供类似的功能。
另外一个开源软件的例子就是Zope，Zope也内建了类似的集群功能，同样有Zope服务器来管理session和数据库连接。比如通常的索引功能，在数据吞吐量不是非常巨大的情况下，我们完全可以直接使用Zope的索引服务，而不用再关心传统索引技术中索引文件的网络共享问题了。

所以我认为，一个好的集群应用方案，首先要对应用编程环境进行正确的选型，这样才能做到事半功倍。另外在程序设计过程当中，尽量使用应用服务器的内建功能，或者把那些需要事务处理的逻辑放入数据库中，利用数据库系统现成的事务处理功能。这样就能够大大简化，甚至是彻底消除网络架构上可能带来的各种麻烦。

而对于那些原有的PHP或者cgi编写的应用程序，我觉得最稳妥简便的方法是进行人工分片+url改写，把整个网站分成www1-www10等多个小块儿，这种方法虽然看上去很土，但是的确非常稳定并且有效。只是需要一定量的前期人工操作。一些很大的专业公司的网站，比如ibm,microsoft等曾经长期使用这种技术，这被证明是非常有效的。

Lingsyser

CFS的几点看法，

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应该发挥了作用。

doep

占位，拜读

xiasanhu

学习一下，公司最近也在弄虚拟化

fssd0131654

看好存储虚拟化

aaaaa5aa

原帖由 Lingsyser 于 2009-7-18 12:02 发表
还有一个牛文件系统不得不提，这就是GFS。在sourceforge上有opengfs，后来sistina被RH拿了之后，
sistina的看家技术GFS顺利成章的成为RH的solution了。……

不错，GFS全局文件系统在技术上的优势不言而喻，它解决了传统一些文件系统的缺点——占用存储空间、
造成数据不一致性的问题。GFS利用廉价普通电脑作为服务器，因此，他可以买很多很多机器来解决存储
容量问题。而至于数据不一致性，Google可能通过“时间戳”给用户提供最新的信息。本身自带的解决方
案也方便了大多数时候日常应用。

但GFS还有一个很大的缺憾，它只能运行在较新的SCSI控制器上，而不能在以前的产品上运行。这直接
导致很多公司企业都放弃用它。而且就其处理较大的块大小，即便是采取了晚分配策略，其缺点依然存
在，而且处理起来很不理想。

vcanb

获奖名单已经发布，在二楼，大家快去看看吧:wink:

jadge

来支持一下啊...呵呵