2020年（3）
2019年（3）
2018年（12）
2017年（13）
2016年（11）
2015年（55）
2014年（74）
2013年（39）
2012年（2）
2011年（18）
分类： LINUX
2014-04-21 14:33:27
(
三
)
其他操作
1.
To quota glusterfs
# gluster volume quota test-volume enable --
激活
quota
功能
# gluster volume quota test-volume disable --
关闭
quota
功能
# gluster volume quota test-volume limit-usage /data 10GB --/exp2/data
目录限制
# gluster volume quota test-volume list --quota
信息列表
# gluster volume quota test-volume list /data --
限制目录的
quota
信息
# gluster volume set test-volume features.quota-timeout 5 --
设置信息的超时时间
# gluster volume quota test-volume remove /data
–删除某个目录的
quota
设置
备注：
1
）
quota
功能，主要是对挂载点下的某个目录进行空间限额。
如
:/mnt/glusterfs/data
目录
.
而不是对组成卷组的空间进行限制，如
:/exp2 /exp3
2
）
gluster volume set test-volume features.quota-timeout
，这个参数，主要用
于客户端，设置客户端何时重新读配置文件。因为相应的
quota
信息是在服务端设置
的，而相应的限额生效，是在挂载点及客户端。所以，必须通知客户端，相应的配置
文件何时从服务端重读。
2.
To expand a volume and rebalance
# gluster peer probe server4 --
向
turst pool
添加新的
server
# gluster volume add-brick test-volume server4:/exp4 --
卷组添加新空间
# gluster volume info --
查看并确认
# gluster volume rebalance test-volume start --
对扩容后的卷组进行
rebalance
# gluster volume rebalance test-volume status
# gluster volume rebalance test-volume stop
# gluster volume rebalance test-volume fix-layout start
# gluster volume rebalance test-volume migrate-data start
3.To tune volume options
# gluster volume set test-volume performance.cache-size 256MB
可以对
glusterfs
的一些相关参数进行设置以及优化
（四）其他信息补充：
1.gluster
拓扑图
2.glusterfs
的弹性
hash
算法
对于分布式系统而言，
元数据处理是决定系统扩展性、
性能以及稳定性的关键。
GlusterFS
另辟蹊径，彻底摒弃了元数据服务，使用弹性哈希算法代替传统分布式文件系统中的集
中或分布式元数据服务。这根本性解决了元数据这一难题，从而获得了接近线性的高扩
展性，同时也提高了系统性能和可靠性。
GlusterFS
使用算法进行数据定位，集群中的
任何服务器和客户端只需根据路径和文件名就可以对数据进行定位和读写访问。换句话
说，
GlusterFS
不需要将元数据与数据进行分离，因为文件定位可独立并行化进行。
GlusterFS
中数据访问流程如下：
1
、计算
hash
值，输入参数为文件路径和文件名；
2
、根据
hash
值在集群中选择子卷（存储服务器）
，进行文件定位；
3
、对所选择的子卷进行数据访问。
GlusterFS
目前使用
Davies-Meyer
算法计算文件名
hash
值，获得一个
32
位整数。
Davies-Meyer
算法具有非常好的
hash
分布性，计算效率很高。假设逻辑卷中的存储服
务器有
N
个，
则
32
位整数空间被平均划分为
N
个连续子空间，
每个空间分别映射到一个
存储服务器。这样，计算得到的
32
位
hash
值就会被投射到一个存储服务器，即我们要
选择的子卷。难道真是如此简单？现在让我们来考虑一下存储节点加入和删除、文件改
名等情况，
GlusterFS
如何解决这些问题而具备弹性的呢？
逻辑卷中加入一个新存储节点，
如果不作其他任何处理，
hash
值映射空间将会发生变化，
现有的文件目录可能会被重新定位到其他的存储服务器上，从而导致定位失败。解决问
题的方法是对文件目录进行重新分布，把文件移动到正确的存储服务器上去，但这大大
加重了系统负载，
尤其是对于已经存储大量的数据的海量存储系统来说显然是不可行的。
另一种方法是使用一致性哈希算法，
修改新增节点及相邻节点的
hash
映射空间，
仅需要
移动相邻节点上的部分数据至新增节点，影响相对小了很多。然而，这又带来另外一个
问题，即系统整体负载不均衡。
GlusterFS
没有采用上述两种方法，而是设计了更为弹
性的算法。
GlusterFS
的哈希分布是以目录为基本单位的，文件的父目录利用扩展属性
记录了子卷映射信息，其下面子文件目录在父目录所属存储服务器中进行分布。由于文
件目录事先保存了分布信息，因此新增节点不会影响现有文件存储分布，它将从此后的
新创建目录开始参与存储分布调度。这种设计，新增节点不需要移动任何文件，但是负
载均衡没有平滑处理，老节点负载较重。
GlusterFS
在设计中考虑了这一问题，在新建
文件时会优先考虑容量负载最轻的节点，在目标存储节点上创建文件链接直向真正存储
文件的节点。另外，
GlusterFS
弹性卷管理工具可以在后台以人工方式来执行负载平滑，
将进行文件移动和重新分布，此后所有存储服务器都会均会被调度。
GlusterFS
目前对存储节点删除支持有限，还无法做到完全无人干预的程度。如果直接
删除节点，那么所在存储服务器上的文件将无法浏览和访问，创建文件目录也会失败。
当前人工解决方法有两个，一是将节点上的数据重新复制到
GlusterFS
中，二是使用新
的节点来替换删除节点并保持原有数据。
如果一个文件被改名，
显然
hash
算法将产生不同的值，
非常可能会发生文件被定位到不
同的存储服务器上，从而导致文件访问失败。采用数据移动的方法，对于大文件是很难
在实时完成的。为了不影响性能和服务中断，
GlusterFS
采用了文件链接来解决文件重
命名问题，在目标存储服务器上创建一个链接指向实际的存储服务器，访问时由系统解
析并进行重定向。另外，后台同时进行文件迁移，成功后文件链接将被自动删除。对于
文件移动也作类似处理，好处是前台操作可实时处理，物理数据迁移置于后台选择适当
时机执行。
弹性哈希算法为文件分配逻辑卷，那么
GlusterFS
如何为逻辑卷分配物理卷呢？
GlusterFS3.1.X
实现了真正的弹性卷管理，如图
4
所示。存储卷是对底层硬件的抽象，
可以根据需要进行扩容和缩减，以及在不同物理系统之间进行迁移。存储服务器可以在
线增加和移除，并能在集群之间自动进行数据负载平衡，数据总是在线可用，没有应用
中断。
文件系统配置更新也可以在线执行，
所作配置变动能够快速动态地在集群中传播，
从而自动适应负载波动和性能调优。
弹性哈希算法本身并没有提供数据容错功能，
GlusterFS
使用镜像或复制来保证数据可
用性，推荐使用镜像或
3
路复制。复制模式下，存储服务器使用同步写复制到其他的存
储服务器，单个服务器故障完全对客户端透明。此外，
GlusterFS
没有对复制数量进行
限制，读被分散到所有的镜像存储节点，可以提高读性能。弹性哈希算法分配文件到唯
一的逻辑卷，而复制可以保证数据至少保存在两个不同存储节点，两者结合使得
GlusterFS
具备更高的弹性。
3.
附加多种分布式文件系统的对比：
MooseFS(MFS)
Ceph
GlusterFS
Lustre
Metadata
server
单个
MDS
。存在
单点故障和瓶
颈。
多个
MDS
，
不存在单
点故障和
瓶颈。
MDS
可以扩展，
不存在瓶
颈
无，
不存在单点故障。
靠
运行在各个节点上的动
态算法来代替
MDS,
不需
同步元数据
,
无硬盘
I/O
瓶颈。
双
MDS(
互相备
份
)
。
MDS
不可以
扩展，存在瓶
颈。
FUSE
支持
支持
支持
支持
访问接口
POSIX
POSIX
POSIX
POSIX/MPI
文件分布
/
数据
分布
文件被分片，
数
据块保存在不
同的存储服务
器上。
文件被分
片，
每个数
据块是一
个对象。
对
象保存在
不同的存
储服务器
上。
Cluster
Translators(GlusterFS
集群存储的核心
)
包括
AFR
、
DHT
（和
Stripe
三
种类型。
可以把大文件
分片并以类似
RAID0
的方式分
散存储在多个
存储节点上。
AFR
相当于
RAID1
，每个
文件都被复制到多个存
储节点上。
Stripe
相当
于
RAID0
，文件被分片，
数据被条带化到各个存
储节点上。
Translators
可以组合，
即
AFR
和
stripe
可以组
成
RAID10
，实现高性能
和高可用。
冗余保护
/
副本
多副本
多副本
镜像
无
数据可靠性
由数据的多副
本提供可靠性。
由数据的
多副本提
供可靠性。
由镜像提供可靠性。
由存储节点上
的
RAID1
或
RAID5/6
提供可
靠性。假如存储
节点失效，则数
据不可用。
备份
提供备份工具。
支持远程备份。
故障恢复
手动恢复
当节点失
效时，
自动
迁移数据、
重新复制
副本。
当节点、
硬件、
磁盘、
网
络发生故障时，
系统会自
动处理这些故障，
管理员
不需介入。
无
扩展性
增加存储服务
器，
可以提高容
量和文件操作
性能。
但是由于
不能增加
MDS
，
因此元数据操
可以增加
元数据服
务器和存
储节点。
容
量可扩展。
文件操作
容量可扩展。
可增加存储节
点，提高容量可
文件操作性能，
但是由于不能
增加
MDS
，因此
元数据操作性
作性能不能提
高，
是整个系统
的瓶颈。
性能可扩
展。
元数据
操作性能
可扩展。
能不能提高，是
整个系统的瓶
颈。
安装
/
部署
简单
简单
简单
复杂。而且
Lustre
严重依
赖内核，需要重
新编译内核。
开发语言
C
C++
C
C
适合场景
大量小文件读
写
小文件
适合大文件。
大文件读写
对于小文件，
无元数据服
务设计解决了元数据的
问题。
但
GlusterFS
并没
有在
I/O
方面作优化，
在存储服务器底层文件
系统上仍然是大量小文
件，
本地文件系统元数据
访问是瓶颈，
数据分布和
并行性也无法充分发挥
作用。
因
此，
GlusterFS
的小文件性能还存在很
大优化空间
产品级别
小型
中型
中型
重型
应用
国内较多
无
较多用户使用
HPC
领域。
优缺点
实施简单，
但是
存在单点故障。
不稳定，
目
前还在实
验阶段，
不
适合于生
产环境。
无元数据服务器，
堆栈式
架构
(
基本功能模块可以
进行堆栈式组合，
实现强
大功能
)
。具有线性横向
扩展能力。
很成熟、很庞
大。
由于没有元数据服务器，
因此增加了客户端的负
载，
占用相当的
CPU
和内
存。
但遍历文件目录时，
则实
现较为复杂和低效，
需要
搜索所有的存储节点。
因
此不建议使用较深的路
径。
