GlusterFS数据均衡

数据均衡：

在这里主要是针对缓存服务器，通过对缓存服务器进行访问从而对后台服务器减压或者保护。
glusterFS是分布式文件存储的一种常用方法，如果数据增多，要对系统进行扩容，但是扩容会导致集群内分布不均衡，导致旧节点负载过高，新节点有很多可用空间。

方法：

主要采用一致性哈希算法，[这篇](https://www.cnblogs.com/xhb-bky-blog/p/9095688.html)文章讲得很好。
先说最基础的哈希算法：在这里很简单，就是
**hash(文件名)%（服务器个数）**
举个例子，文件名为a.jpg，经过hash函数，有3个服务器，经过公式计算可以得到0,1,2，就可以将文件随机分到其中之一的服务器上。
但是这个方法存在缺点，当服务器数量增加，公式变为
**hash(文件名)%（服务器个数+1）**
这会导致每个文件的存储服务器改变，当应用无法从缓存服务器获取数据，就会向后端服务器请求。如果服务器数量减少，公式改变，会导致缓存血崩，后端服务器压力增加，系统被压垮。

一致性哈希：

普通哈希是对服务器数量取余，而一致性哈希是对2^32次方取余，

可以将0-2^32看做是一个圆，被称为hash环。
它与普通哈希区别在于，第一个将服务器放在这个环中，服务器地址为
HASH（服务器A的IP地址） % 2^32

同理，将B C服务器放在环上。

接下来和普通hash一样，把文件放在环上。
HASH（文件名） % 2^32
如何对文件进行部署呢？从文件位置顺时针离，部署到离该文件最近的服务器。
假设有四个文件，如图可以将1234部署到ABC。如图如果B失效，对于124没有影响，因此一致性哈希，如果一个服务器故障，只部分缓存失效。

但存在一个问题是如果服务器分布不均匀（hash偏斜），如果故障会导致所有缓存都出现问题。

虚拟节点
虚拟节点是通过再复制几个服务器的虚拟节点，使所有服务器尽量均匀的分布在hash环中，日常取极限嘛如果整个圆都是ABC分布，那随便撒一个点，属于ABC的概率基本是一样的。

如图，ABC都虚拟了一个节点，这样1-A,5-B,3-A,4-B,6-C,2-C。如果不这样，那12346都属于A了。

什么情况下均衡：
扩容缩容，重命名（哈希结果改变，属于不同的服务器了）
扩容要手动触发均衡（扩容不需要立马均衡），缩容自动均衡（缩容不自动均衡，会导致数据丢失诶）。
重命名之后，会在该位置生成一个链接文件，链接文件到存储位置，如果不均衡，会产生很多链接文件。

操作：

//修复目录的哈希分布，但不实际迁移数据，新文件会存储到新增节点上，等系统空闲再迁移

gluster v rebalance VOL_NAME fix-layout start

//开启均衡

gluster v rebalance VOL_NAME start

此命令会考虑容量问题，如果目标容量小于当前容量则不迁移。可强制迁移。

gluster v rebalance VOL_NAME start force

//设置数据均衡迁移速度，因为采用多线程可以设置线程数量。

gluster volume set <VOLNAME> rebal-throttle lazy|normal|aggressive //慢，中，快

//查看数据均衡状态等信息

gluster v rebalance VOL_NAME status

可以查看到数据均衡在每个节点的当前状态（status）、运行了多久（run time）、扫面的文件数量（scanned）、已经迁移的文件数量（rebalanced-files）、已经迁移的数据量（size）、迁移失败的文件数量（failures）和跳过的文件数量（skipped）。

停止数据均衡进程

gluster v rebalance VOL_NAME stop