GlusterFS学习

xywuyiba6

　　performance translaters(高性能转换器)
　　Read Ahead 预读
　　配置文件写法 预读转换器在每次
type performace/read-ahead　　读取操作前就预先抓取数据。这个有利于应用频繁持续性的访问文件，当应用完成当前数据块读取的时候，下一个数据块就已经准备好了。
　　额外的，预读转换器也可以扮演读聚合器，许多小的读操作被绑定起来，当成一个大的读请求发送给服务器
　　预读处理有page-size和page-count来定义，page-size定义了，一次预读取的数据块大小，page-count定义的是被预读取的块的数量
　　预读最好被使用在使用InfiniBand卡（或使用ib-verbs传输）的系统上。在快速以太网或者千兆以太网络环境中，就算不使用预读，Glusterfs也可以达到网卡最大连接的吞吐量，所以使用预读配置就是多余的
　　需要注意的是，预读操作只会发生在读的请求是完全连续的。如果应用访问数据很随机，那使用预读实际上将造成性能的损失，因为预读操作会拿一些应用并不会用到的数据块。
　　Options：
　　page-size  (256KB) #每次预读取的数据块大小
　　page-count  (2) #每次预读取数据块的数量
　　force-atime-update [on|off|yes|no] (off|no)
　　#是否强制在每次读操作时更新文件的访问时间，不设置这个，访问时间将有些不精确，这个将影响预读转换器读取数据时的那一时刻而不是应用真实读到数据的那一时刻。
　　Write Behind（后写）
type performance/write-behind　　后写转换器改善了了写操作的延时。它会先把写操作发送到后端存储，同时返回给应用写操作完毕，而实际上写的操作还正在执行。使用后写转换器就可以像流水线一样把写请求持续发送。这个后写操作模块更适合使用在client端，以期减少应用的写延迟。
　　后写转换器同样可以聚合写请求。如果aggregate-size选项设置了的话，当连续的写入大小累积起来达到了设定的值，就通过一个写操作写入到存储上。这个操作模式适合应用在服务器端，以为这个可以在多个文件并行被写入磁盘时降低磁头动作。
　　aggregate-size选项的默认值是128KB。尽管这个默认值对于大多数的用户来讲已经可以很好的工作了，但还是希望你根据实际环境经过不断调整数值试验，以达到最大的性能。这是因为后写的性能依赖于你的连接情况，RAM的大小以及工作的负载情况
　　aggregate-size  (128KB) #当累积达到这个值才进行实际的写操作
　　flush-behind [on|yes|off|no] (off|no)
　　IO Threads(IO 线程）
type performance/io-threads　　IO线程转换器试图增加服务器后台进程对文件元数据读写I/O的处理能力。由于GlusterFS服务是单线程的，使用IO线程转换器可以较大的提高性能。这个转换器最好是被用于服务器端，而且是在服务器协议转换器后
　　面被加载。
　　IO线程操作会将读和写操作分成不同的线程。同一时刻存在的总线程是恒定的并且是可以配置的
　　thread-cout  (1) #线程使用的数量
　　cache-size  (64MB) #被允许放置在一个线程中的最大数据量
　　IO Cache（IO缓存）
type performance/io-cache　　IO缓存转换器可以缓存住已经被读过的数据。这个对于多个应用对同一个数据多次访问，并且如果读的操作远远大于写的操作的话是很有用的（比如，IO缓存很适合用于提供web服务的环境，大量的客户端只会进行简单的读取文件的操作，只有很少一部分会去写文件）。
　　IO缓存转换器读数据一次读page-size设置的大小的数据，并把读到的数据缓存起来指到cache-size设置的大小。缓存以以最新近被访问的列表来作为优先保持的，cache文件的优先级是可以通过user-specified参数来配置的。
　　当IO缓存转换器检测到有写操作的时候，它就会把相应的文件从缓存中删除。
　　IO缓存转换器会定期的根据文件的修改时间来验证缓存中相应文件的一致性。验证超时时间是可以配置的。
　　page-size  (128KB) #一条记录的大小
　　cache-size (n) (32MB) #可以缓存的最大数据量
　　force-revalidate-timeout  (1) #强制缓存一致性检测超时时间，单位秒
　　priority  (*:0) #文件匹配列表及其设置的优先级
　　Booster（加速器）
type performance/booster　　加速器给应用和GlusterFS间的对写请求提供了一个快速通道。不适用加速器的情况，应用到GlusterFS的所有请求都会先经过FUSE。 使用加速器模块之后使得Glusterfs和加速器的共享库相结合，应用就可以直接把读写的请求发给Glusterfs的子进程而跳过FUSE。
　　Booster结构由两部分组成：Booster translator和booster共享库，bootster translator最好是在客户端加载，通常被配置在translator树的根上。booster共享库被应用以LD_PRELOADed的方式使用。
　　以上翻译均来自Glusterfs user guide，本人水平有限，请参考原文http://www.gluster.org/docs/index.php/User_Guide中相应的部分
　　对于Glusterfs学习也有了几天了，但对于性能上的评价目前关注的比较少，今天主要才测测Glusterfs和NFS的性能比，但由于手头上条件有限，只能通过虚拟机来测试，数据仅供参考，如有人可以在真实环境测试，还希望发出来供大家参考
　　我的环境
　　vmware6.0模拟两个linux
　　linux01 256MB内存，8G硬盘，centos5，ip：192.168.211.128，用作NFSserver端和Glusterfs的server端
　　linux02 256MB内存，8G硬盘，centos5，ip：192.168.211.129，用作client
　　下面就来看下我的测试结果
　　这张图是NFS的读取测试结果

　　下面这张是NFS的写入测试结果

　　然后我把两台虚拟机重启，并启用Glusterfs模式
　　第一张图是Glusterfs的读取结果

　　第二张图是写入的测试结果

　　由上面的结果看，Glusterfs仅仅用于NFS这种模式的情况下，写入速度并不太理想
　　但Glusterfs的功能不仅仅提供共享存储来用，而是一个存储的聚合，当然以上测试结果未必就很准确，毕竟我的测试条件不行，不过也仅仅是给各位一个启示，请有条件的同志继续完成测试工作吧
　　官方的glusterfs和NFS的测试结果请看
　　http://www.gluster.org/docs/index.php/GlusterFS_1.2.1-BENKI_Aggregated_I/O_vs_NFSv4_Benchmark
　　看glusterfs的东西也有段时间了，不过一直一来也是停留在对这个分布式系统的学习，当然对于一个软件的学习不能仅仅停留在对这个软件的熟 悉，还要考虑它所适用的范围。最近就在思考，到底对于我们的什么应用合适，我这边接触的比较多的结构就是N台Web+单个NFS。我就再想，既然 glusterfs是个聚合分布式文件系统，而且支持HA的功能，是不是可以使用glusterfs来替换NFS，既可以达到共享文件的用途，有可以解决 了单点的问题。
　　先来看下我预计的拓扑结构

　　下面来解释一下这个拓扑，前端的web应用，每台web上的应用都放置在glusterfs共享出来的硬盘上，尽管我图上画的是一个 diskpool，但实际的容量大小是几台web中glusterfs共享空间最小的那个大小。而且对于上面这个拓扑的应用，我并不需要独立的NAS来做 共享，完全可以使用每台web服务器上未用的硬盘空间（注：当然你可以选择使用NAS来进行存储，在存储量很大的情况下）。
　　接下来就来看下实现的方式：
　　web01：192.168.220.128 共享出来的地址：/var/app
　　web02：192.168.220.129 共享出来的地址：/var/app
　　两台机器都事先安装好glusterfs和fuse（安装方法可以参考我前几篇文章）
　　首先来配置web01的server端
　　cat /etc/glusterfs/server.vol
volume brick　　type storage/posix # POSIX FS translator
　　option directory /var/app # Export this directory
　　end-volume
　　volume locker
　　type features/posix-locks
　　subvolumes brick
　　end-volume
　　### Add network serving capability to above brick.
　　volume server
　　type protocol/server
　　option transport-type tcp/server
　　option listen-port 6996 # Default is 6996
　　subvolumes locker
　　option auth.addr.brick.allow * # Allow access to “brick” volume
　　option auth.addr.locker.allow *
　　end-volume
web02上的server端配置相同cat /etc/glusterfs/server.volvolume brick　　type storage/posix # POSIX FS translator
　　option directory /var/app # Export this directory
　　end-volume
　　volume locker
　　type features/posix-locks
　　subvolumes brick
　　end-volume
　　### Add network serving capability to above brick.
　　volume server
　　type protocol/server
　　option transport-type tcp/server
　　option listen-port 6996 # Default is 6996
　　subvolumes locker
　　option auth.addr.brick.allow * # Allow access to “brick” volume
　　option auth.addr.locker.allow *
　　end-volume
服务器端配置完毕，接下来就是client端的配置，因为两台机器互为对方的sever又同时是自己的server所以两台上都需要配置client端。首先看下web01上的配置cat /etc/glusterfs/replicate.volvolume client0　　type protocol/client
　　option transport-type tcp/client
　　option remote-host 127.0.0.1 # IP address of the remote brick
　　option remote-port 6996 # default server port is 6996
　　option remote-subvolume locker # name of the remote volume
　　end-volume
　　volume client1
　　type protocol/client
　　option transport-type tcp/client
　　option remote-host 192.168.211.129
　　option remote-port 6996
　　option remote-subvolume locker
　　end-volume
　　volume bricks
　　type cluster/replicate
　　subvolumes client0 client1
　　option read-subvolume client0
　　end-volume
再来看下web02上的配置cat /etc/glusterfs/replicate.volvolume client0　　type protocol/client
　　option transport-type tcp/client
　　option remote-host 127.0.0.1 # IP address of the remote brick
　　option remote-port 6996 # default server port is 6996
　　option remote-subvolume locker # name of the remote volume
　　end-volume
　　volume client1
　　type protocol/client
　　option transport-type tcp/client
　　option remote-host 192.168.211.128
　　option remote-port 6996
　　option remote-subvolume locker
　　end-volume
　　volume bricks
　　type cluster/replicate
　　subvolumes client0 client1
　　option read-subvolume client0
　　end-volume
到此，配置就已经完成了，接下来就可以测试咯，首先两台机器上需要加载fusemodprobe fuse如果没有报错，说明fuse模块加载完毕，然后在两台机器上启动server端和client端web01上执行启动服务端　　glusterfsd -f /etc/glusterfs/server.vol
　　启动client端
　　glusterfs -f /etc/glusterfs/replicate.vol /usr/local/nginx/html/blog
web02上如法炮制然后就可以在web01上的/mnt上放置web的内容了，web02上可以自动的看到相应的内容，并不需要人为的干预，没台机器上都会有一份 web应用的拷贝，这样无论那台web宕机，web的提供的服务是不会中断，也不会受到影响的，从而避免了，单点NFS故障导致服务中断，同时避免了，双 NFS数据同步的问题。同时每台web优先读取自己硬盘上的copy，所以可以减少网络负载。　　但这个方案还不是最完美的，因为这种方案对于写频繁的应用来说是存在问题的，如果出现同时写一个文件的情况，就会造成数据的不一致，所以如果 web应用是读频繁的话，还是很有优势的，而且如果后台人员需要对应用进行更新，只需要更新第一台server的就行，默认情况下replicate的应 用，subvolumes client0 client1 中的一个就是主server，这里只要对于client0上的数据进行更新就可以做到同步了。