（备注：以下均为6.3.0版本elasticsearch测试结果）
新建索引 —> 分片划分（按节点均衡分配）—> 存储目录（均衡分配分片）
一 节点对分片均匀分布，若分布不平衡，则会自动迁移
如：新增一节点，则会从迁移分片到新节点 直到重新达到平衡，此过程为集群的再均衡
例：967个分片在三个节点中的分配
导致集群自发再平衡过程的原因如下：
新增节点某一个节点失联，或下线可能会发生如下过程：
Node（节点） 19 在网络中失联了（某个家伙踢到了电源线)Master 立即注意到了这个节点的离线，它决定在集群内提拔其他拥有 Node 19 上面的主分片对应的副本分片为主分片在副本被提拔为主分片以后，master 节点开始执行恢复操作来重建缺失的副本。集群中的节点之间互相拷贝分片数据，网卡压力剧增，集群状态尝试变绿。由于目前集群处于非平衡状态，这个过程还有可能会触发小规模的分片移动。其他不相关的分片将在节点间迁移来达到一个最佳的平衡状态通常情况下，上述过程是需要的，比如新增节点，比如下线一个节点，但在某些情况下，临时失联可以很快恢复的情况下会造成一些麻烦。
比如：
踢到电源线的倒霉管理员，把服务器插好电源线进行了重启，现在节点 Node 19 又重新加入到了集群。不幸的是，这个节点被告知当前的数据已经没有用了， 数据已经在其他节点上重新分配了。所以 Node 19 把本地的数据进行删除，然后重新开始恢复集群的其他分片（然后这又导致了一个新的再平衡）
解决方案：
修改默认等待时间，delayed_timeout为0则为立即分配，5m位等待5分钟
PUT /_all/_settings
{
"settings": {
"index.unassigned.node_left.delayed_timeout": "5m"
}
}
注意：
延迟分配不会阻止副本被提拔为主分片。集群还是会进行必要的提拔来让集群回到 yellow状态。缺失副本的重建是唯一被延迟的过程。
二 同一节点不同数据目录间的平衡
如配置有path.data: /data/es/data,/data1/es/data,/data1/es/data2，即同一节点有三个数据目录
通常情况下，
三个目录均匀写入分片数据不会做再平衡，即目录间数据不会做自发迁移每个目录状态是一致的，都具有本节点所有索引的数据目录和状态信息每个索引目录的名称为该索引的uuid节点在新建分片时将尽可能将分片存储在空闲空间更多的数据目录下，只能重新达到平衡节点数据：
indices 为数据存储目录，_state为节点状态目录
UAQVT_zRRsaStHEmtPAnfg为节点uuid
global-364.st为集群全局状态文件
node.lock文件用于确保一次只能从一个数据目录读取/写入
索引数据：
目录名为索引uuid，uuid可以在kibana的索引管理界面查看，也可以用api查看
GET /_cat/indices?v 可以查看所有索引的信息
此目录为 索引id为6qrebTS8RWa81xxTIaFKRg的分片4存储目录，
_stat为此索引的状态信息
index目录为分片4的索引数据，_state目录为此分片的状态信息，translog目录为此分片的操作日志
目录对应磁盘空间不同时：
如上所示，data目录和data1目录分属不通硬盘
需要注意的是：
依照path.data配置目录，集群尽可能保证各个目录分片分布均衡集群不会自动在目录间迁移数据，只会在新建分片时尽可能往空闲节点分配目录间分配是以分片数计数，也即是不同目录最终达成分片数一致如果各个目录存储空间不同，集群无法自动识别如上所述，如果两个硬盘空间不同，如/data目录 容量是 /data1的一半左右
若不做处理，在每个目录下分配一个es目录，会造成数据分布不平衡
解决方案：在/data1中分配两个es数据目录
此操作仍然会造成一些问题，比如集群在统计剩余容量时，对/data1计算了两次
如：
但实际上剩余容量为：66G+339G~400G,而不是66G+339G+339G~740G
因此尽可能保证不同目录容量空间一致
