#背景 一直以来我的业务都是跑在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/