glusterFS与ceph哪个更好些，记些东西

network

　　最近研究对云平台的数据存储，究竟哪种方式好，选来选去，落在GFS和CEPH上，但觉得都要修改一些东西，并且从运维方式上做一些改变，记录一些东西如下：
　　GFS
　　1.GlusterFS的安装
1.1.服务器端安装
我们通过rpm编译方式来安装GlusterFS，因为做为群集文件系统，可能需要在至少10台以上的服务器上安装GlusterFS。每台去源码编译安装太费功夫，缺乏效率。在一台编译为rpm包，再复制到其它的服务器上安装是最好的选择。
GlusterFS需要fuse支持库，需先安装:
#yum-yinstallfusefuse-develhttpd-devellibibverbs-devel
下载GlusterFS源码编译rpm包。
#wgethttp://ftp.gluster.com/pub/gluster/glusterfs/2.0/LATEST/glusterfs-2.0.0.tar.gz
#tar-xvzfglusterfs-2.0.0.tar.gz
#cpglusterfs-2.0.0.tar.gz/usr/src/redhat/SOURCES/
#rpmbuild-bbglusterfs-2.0.0/glusterfs.spec
#cp/usr/src/redhat/RPMS/i386/glusterfs*.
#rmglusterfs-debuginfo-2.0.0-1.i386.rpm
#rpm-ivhglusterfs-*.rpm
安装完成，并把编译好的rpm包复制到其它服务器上安装。1.2.客户端安装
客户端和服务器有一点点不同，特别需要注意的是在客户端这边，不但需要fuse库，并且需要一个fuse内核模块。好在DAGRPMRepository内已有用DKMS方式编译好的内核模块包，我们直接安装便可。
DKMS(DynamicKernelModuleSupport)是dell发起的一个项目，目的是希望能在不编译内核的情况下，动态的更新内核模块，最重要的是，通过DKMS方式编译的内核模块，由于是由DKMS管理的，在内核升级后，无需重新编译，仍旧可用。这种方式可大大方便以后的内核更新。
GlusterFS可直接用上面rpm编译后的包安装:
#yum-yinstalldkmsdkms-fusefusefuse-develhttpd-devellibibverbs-devel
#rpm-ivhglusterfs-*.rpm
2.GlusterFS的典型架构图

3.GlusterFS常用translators(中继)
3.1.1.storage/posix
typestorage/posix
storage/posix的作用是指定一个本地目录给GlusterFS内的一个卷使用。
配置例子：
volumeposix-example
typestorage/posix
optiondirectory/sda4
end-volume
3.1.2.protocol/server(服务器)
typeprotocol/server
服务器中继(protocol/server）表示本节点在GlusterFS中为服务器模式。
配置例子：
volumeserver-example
typeprotocol/server
optiontransport-typetcp
subvolumesbrick#定义好的卷
optionauth.addr.brick.allow*#指定可访问本卷的访问者,*为所有，可对访问者做限制，如192.168.1.*
end-volume
3.1.3.protocol/client(客户端)
typeprotocol/client
客户端中继(protocol/server）用于客户端连接服务器时使用。
配置例子：
volumeclient-example
typeprotocol/client
optiontransport-typetcp
optionremote-host192.168.1.13#连接的服务器
optionremote-subvolumebrick#连接的服务器卷名
end-volume
3.1.4.cluster/replicate(复制)
typecluster/replicate
复制中继(cluster/replicate，前身是AFR）为GlusterFS提供了类似RAID-1的功能。
Replicate会复制文件或者文件夹到各个subvolumes里。如一个卷(volume)内有两个子卷(subvolume)，那就会有两份文件或文件夹的复本。
Replicate只时还有高可用的功能，如果两个子卷中有一个子卷挂了，卷依然可以正常工作。当这个子卷重新启用时，会自动更新丢失的文件或文件夹，不过更新是通过客户端进行的。
配置例子：
volumereplicate-example
typecluster/replicate
subvolumesbrick3brick4
end-volume
3.1.5.cluster/distribute(分布式)
typecluster/distribute
分布式中继(cluster/distribute，前身是unify）为GlusterFS提供了类似RAID-0的功能。
Distribute可把两个卷或子卷组成一个大卷，实现多存储空间的聚合
配置例子：
volumedistribute-example
typecluster/distribute
subvolumesrepl1repl2
end-volume
3.1.6.features/locks(锁)
typefeatures/locks
锁中继(features/locks）只能用于服务器端的posix中继之上，表示给这个卷提供加锁(fcntllocking)的功能。
配置例子：
volumelocks-example
typefeatures/locks
subvolumesposix-example
end-volume
3.1.7.performance/read-ahead(预读)
typeperformance/read-ahead
预读中继(performance/read-ahead）属于性能调整中继的一种，用预读的方式提高读取的性能。
读取操作前就预先抓取数据。这个有利于应用频繁持续性的访问文件，当应用完成当前数据块读取的时候，下一个数据块就已经准备好了。
额外的，预读中继也可以扮演读聚合器，许多小的读操作被绑定起来，当成一个大的读请求发送给服务器。
预读处理有page-size和page-count来定义，page-size定义了，一次预读取的数据块大小，page-count定义的是被预读取的块的数量
不过官方网站上说这个中继在以太网上没有必要，一般都能跑满带宽。主要是在IB-verbs或10G的以太网上用。
配置例子：
volumereadahead-example
typeperformance/read-ahead
optionpage-size256#每次预读取的数据块大小
optionpage-count4#每次预读取数据块的数量
optionforce-atime-updateoff#是否强制在每次读操作时更新文件的访问时间，不设置这个，访问时间将有些不精确，这个将影响预读转换器读取数据时的那一时刻而不是应用真实读到数据的那一时刻。
subvolumes
end-volume
3.1.8.performance/write-behind(回写)
typeperformance/write-behind
回写中继(performance/read-ahead）属于性能调整中继的一种，作用是在写数据时，先写入缓存内，再写入硬盘。以提高写入的性能。
回写中继改善了了写操作的延时。它会先把写操作发送到后端存储，同时返回给应用写操作完毕，而实际上写的操作还正在执行。使用后写转换器就可以像流水线一样把写请求持续发送。这个后写操作模块更适合使用在client端，以期减少应用的写延迟。
回写中继同样可以聚合写请求。如果aggregate-size选项设置了的话，当连续的写入大小累积起来达到了设定的值，就通过一个写操作写入到存储上。这个操作模式适合应用在服务器端，以为这个可以在多个文件并行被写入磁盘时降低磁头动作。
配置例子：
volumewrite-behind-example
typeperformance/write-behind
optioncache-size3MB#缓存大小,当累积达到这个值才进行实际的写操作
optionflush-behindon#这个参数调整close()/flush()太多的情况，适用于大量小文件的情况
subvolumes
end-volume
3.1.9.performance/io-threads(IO线程)
typeperformance/io-threads
IO线程中继(performance/io-threads）属于性能调整中继的一种，作用是增加IO的并发线程，以提高IO性能。
IO线程中继试图增加服务器后台进程对文件元数据读写I/O的处理能力。由于GlusterFS服务是单线程的，使用IO线程转换器可以较大的提高性能。这个转换器最好是被用于服务器端，而且是在服务器协议转换器后面被加载。
IO线程操作会将读和写操作分成不同的线程。同一时刻存在的总线程是恒定的并且是可以配置的。
配置例子：
volumeiothreads
typeperformance/io-threads
optionthread-count32#线程使用的数量
subvolumes
end-volume
3.1.10.performance/io-cache(IO缓存)
typeperformance/io-cache
IO缓存中继(performance/io-threads）属于性能调整中继的一种，作用是缓存住已经被读过的数据，以提高IO性能。
IO缓存中继可以缓存住已经被读过的数据。这个对于多个应用对同一个数据多次访问，并且如果读的操作远远大于写的操作的话是很有用的（比如，IO缓存很适合用于提供web服务的环境，大量的客户端只会进行简单的读取文件的操作，只有很少一部分会去写文件）。
当IO缓存中继检测到有写操作的时候，它就会把相应的文件从缓存中删除。
IO缓存中继会定期的根据文件的修改时间来验证缓存中相应文件的一致性。验证超时时间是可以配置的。
配置例子：
volumeiothreads
typeperformance/io-cache
optioncache-size32MB#可以缓存的最大数据量
optioncache-timeout1#验证超时时间，单位秒
optionpriority*:0#文件匹配列表及其设置的优先级
subvolumes
end-volume
　　3.1.11.其它中继
其它中继还有
cluster/nufa(非均匀文件存取)
cluster/stripe(条带，用于大文件，分块存储在不用服务器)
cluster/ha(集群)
features/filter(过滤)
features/trash(回收站)
path-converter
quota
老的还有：
cluster/unify（和distribute，可定义不同的调度器，以不同方式写入数据）