概述
GlusterFS性能调优基本思路主要包括三个部分,分别是硬件调优、操作系统调优和GlusterFS自身参数调优。
正常情况下,当硬件购买之后,已经没有什么可调的空间,最多就是更换一些性能更高的磁盘,当然这对glusterfs来说对性能帮助已经非常大了,gluster对cpu本身要去并不是很高,性能瓶颈往往会出现在网络和磁盘这两块。
操作系统性能调优空间也不是很大,主要还是配合特定的应用场景,如果gluster和其他应用分享计算资源的话,还需要考虑操作系统配置对其他应用的性能影响,从方便运维的角度看,不推荐gluster和其他应用共享计算资源。
glusterfs自身性能调优对性能影响较大,好在默认情况下,gluster性能相关中继器都是打开的,默认都会提供比较高的性能,但是还是会有一些调优的空间,其中一个最主要的原因是gluster默认配置应对的是普通服务器,对于部署在高性能服务器上的gluster来说,可调的空间就更大,原因是高性能服务器会提供更多内存和CPU。
调优说明
对gluster进行性能调优,主要调的是性能相关的中继器,默认情况下,所有的性能中继器都是打开的,给人的感觉就是没法调了,已经是最优了,但实际情况往往不是这样的,还是要根据具体的应用场景,有些性能中继器在特定场合下反而会降低性能,其实对gluster性能影响很大的是gluster集群的部署方案,如果部署比较合理,性能原生就比较好,不需要做过多的配置,这也印证了gluster的简单好用和高性能。
gluster非常适合大文件读写的带宽型应用,诸如视频存储、HPC高性能计算、容器镜像存储、冷数据存储、日志存储、数据备份等应用场景。但gluster并不擅长小文件读写的IOPS型应用,需要综合硬件、软件和系统进行优化。
这里提供一个推荐的配置项供参考:
项目 | 推荐配置 | 说明 |
单个集群规模 | 64节点 | 受集群管理模式限制,大规模集群有压力 |
每卷最大客户端数量 | <= 1000个 | Brick并发连接数量不能太大 |
每节点brick数量 | 4-8个 | Brick进程太多占用系统资源,并且启动时会出现部分brick进程启动失败现象 |
单个brick容量 | <= 100 TB | 平衡容量与性能,本地文件系统限制 |
RAID/LVM | 多盘组成RAID | 单个Brick容量和性能,控制brick数量 |
Brick文件系统 | XFS | 稳定,16TB以上大容量,格式化快 |
卷类型 | 哈希复制卷 | 高可用,条带卷不成熟 |
数据网络 | 10GbE | 内部通信不能有瓶颈,尤其是NAS协议 |
访问协议 | POSIX | 原生高可用,性能 |
其他相关可调参数说明如下:
参数选项 | 参数说明 | 缺省值 | 合法值 |
auth.allow / auth.reject | IP访问授权 | *(allow all) | IP地址 |
cluster.min-free-disk | 剩余磁盘空间阈值,超出将进行数据均衡并记录日志 | 10% | 百分比 |
network.frame-timeout | 请求等待时间 | 1800s | 0-1800 |
network.ping-timeout | 客户端等待时间 | 42s | 0-42 |
nfs.disabled | 关闭NFS服务 | off | off|on |
performance.io-thread-count | IO线程数 | 16 | 0-65 |
performance.cache-refresh-timeout | 缓存校验周期 | 1s | 0-61 |
performance.cache-size | 全局读缓存大小 | io-cahce: 32MB quick-read: 128MB | |
performance.io-thread-count | I/O并发数量 | 16 | 非零整数 |
cluster.stripe-block-size | 条带大小 | 128KB |
参考:http://blog.csdn.net/liuaigui/article/details/50753240