关于docker的存储驱动

#背景
一直以来我的业务都是跑在aufs+ext4的存储驱动结构上，看上去没有什么问题，直到业务报告：
在高并发场景下，aufs因为锁争抢的原因，导致cpu高负载。我才不得不考虑更换docker驱动的事情

#关于外部资料的收集
看了一圈下来，docker的存储驱动目前可以说分为三个流派（可以用在生产环境为标准）：

aufs+ext4

overlay2+xfs

devicemapper

目前没有人大胆用第4个存储驱动，玩玩可以，可要是到生产环境，指不定要修多少内核bug，这对于哪些没有内核和文件系统人才的公司简直是噩梦。
其中aufs的使用门槛最低，内核版本和底层文件系统要求比较少，也经过生产验证，稳定，但是如上所说，高并发场景不合适。aufs在控制到镜像层数的情况下，16M以下的文件读写性能不会太差。

overlay2是为了解决overlay耗尽inode问题的演化版本，overlay要求的Linux内核至少3.18版本之后，Docker1.11前只能使用overlay, 而Overlay2要求内核版本在4.0以上。另外我要声明一下，docker的存储driver都有不同程度的坑，目前比较能接受的是overlayfs+xfs
，我就遇到个bug:

#overlay2+ext4
bash-4.1# mv index.php  kks.php
mv: cannot move `index.php' to a subdirectory of itself, `kks.php'

另外如果你确定你的低版本内核已经支持了overlay，可以用下面的配置跳过内核版本检查

vim /etc/docker/daemon.json
{
"storage-driver": "overlay2",
"storage-opts": [
"overlay2.override_kernel_check=true"
]
}

制作xfs时要加上ftype的参数

mkfs.xfs -f -n ftype=1 /dev/sda4

devicemapper因为和上面两个技术原理上发生了质的变化，从配置上就复杂了一些,还要给docker数据单独分区，相当的麻烦，要求的内核版本（4.0以上）和docker版本（17.06）就更高了。我最后是放弃测试了。

附上测试数据













我认为之所以overlay2比裸硬盘ext4还叼，主要还是因为xfs比ext4要叼，当然overlay从速度上还是和aufs一样都比较接近裸硬盘，（我这不是高并发测试，aufs仅有三层）
aufs从原理上讲镜像层数越多性能越差，如果层数越少，性能就越接近裸硬盘。

测试方法
./iozone -a -n 4k -g 1g -i 0 -i 1 -i 2 -f /root/test.rar -Rb ./iozone.xls

相关的资料
https://docs.docker.com/storage/storagedriver/select-storage-driver/

http://dockone.io/article/1513