关于docker-Engine使用的存储驱动devicemapper的常识

缘起:

今天值班的兄弟找我说PAAS节点扩容后有个 docker-container 创建一直失败,看不懂输出的报文信息。

看值班给出的投屏发现和storage-driver有关,提示信息如下:

Error running DeviceCreate (createSnapDevice) dm_task_run failed

查看了下

docker版本是 docker-Engine 20;

OS 的版本是 centos 6

Kernel的版本是 3.10

又查看了下 /etc/docker/daemon.json 发现storage-driver是devicemapper

再查看docker的log信息,发现有这样一条消息:

statusCode=500 Error running DeviceCreate (createSnapDevice) dm_task_run failed

唔,大概是docker链接的后端存储资源不足了。

因为 http 协议中 产生 500 状态码的一个可能性原因是服务端资源不足,再结合DeviceCreate任务失败,可以确认排查方向应该是 devicemapper驱动下的存储资源状态。

devicemapper本质上是Linux-Kernel级别的块设备存储驱动,依赖于LVM工具包支持。在逻辑卷管理中,除了LVM服务运行异常外,能够影响到数据写操作的就是存储空间和元数据两个item了。

执行 vgdisplay ,可以查看到回显信息说明 LVM服务运行无异常;

执行 dmsetup status 和 dmsetp info,可以查看到有充盈的存储空间;

好吧,看来是扩容完后有人在没有正常stop点docker-Engine的情况下强制对服务器进行了上下电操作,在某种原因下导致 devicemapper的元数据出现了错误。

修复方式:

Step1 systemctl stop docker.service

Step 2 thin_check /var/lib/docker/devicemapper/devicemapper/metadata

或

thin_check --clear-needs-check-flag /var/lib/docker/devicemapper/devicemapper/metadata

Step 3 systemctl start docker.service

Step 4 重新 run 容器

**************************************************

devicemapper已经是一个被放弃的存储驱动了,场内发布的主流生产应用都已经切换到 overlay2存储驱动了,看来打包OS装机镜像的研发又没有更新docker的配置项呀。

docker-devicemapper由RedHat公司联合docker公司开发而成,用于在RHEL系列操作系统上运行docker docker-devicemapper存储驱动出现前,docker只支持运行在以AUFS为存储后端的Debian系列OS上。,是对Linux-Kernel-Device-Mapper的简化。Device Mapper是一种强化Linux中高级卷管理技术的内核级框架,docker-devicemapper集成了它的精简置备、拷写同步和快照功能、依赖于Linux-Kernel的支持。docker-devicemapper使用设备块(block)存储数据,将docker镜像或docker容器数据存储在虚拟块设备上。在operating system (OS)使用docker-devicemapper driver需要安装lvm2等包,当前CentOS、Fedora、SLES 15、Ubuntu、 Debian或RHEL这些发行版都支持Docker Engine使用docker-devicemapper driver作为存储驱动。

docker-devicemapper driver提供两种工作模式:loop-lvm模式和direct-lvm模式。从工作机制上讲,loop-lvm模式本质是上一种文件级别(file level)的存储驱动模式,存在I/O操作缓慢的性能问题。因此在实际业务环境中,建议配置为direct-lvm模式。相比较而言,direct-lvm模式直接读写的是挂载到宿主机OS(Host-OS)中的块设备,读写较高、且可以便捷地按需扩容存储。此外,direct-lvm模式支持多个块设备配置 multiple block devices,也可称之为多存储路径配置。。

docker-devicemapper作为docker的后端存储驱动,已经于 version 18.09中弃用、version 23.0中禁用、将于version 25 中移除掉。

在检查了本次扩容的40台服务器后,发现docker的devicemapper驱动模式竟然是loop-lvm模式,看来天天趾高气昂的产品研发没有做产品封板前的检查呀,真不知道这产品质量测试时怎么通过压力测试的 。。。

世界破破烂烂,草台班子缝缝补补呀。。。

干工作,责任心太强了就只能自我驱动加班了。。。今晚注定又睡不成囫囵觉了。。。

相关推荐
续写烂尾12 分钟前
贴片 SD NAND、eMMC、TF 卡规格怎么定?硬件工程师选型清单
运维·服务器·网络
迪康妍妍18 分钟前
终端管控实操:封堵网盘与IM外发通道的落地思路
运维·网络·安全·架构·安全性测试
sxgzzn22 分钟前
如何选择合适的开关柜在线监测工具?
运维·重构·无人机·开关柜局放在线监测·光伏运维管理系统
zxcvb1531 小时前
运维经验分享:监控网页更新内容的几种思路
运维
云飞云共享云桌面2 小时前
设计师共享单台图形服务器,解决 SolidWorks大装配卡顿难题
运维·服务器·3d·自动化·电脑·制造
张张123y3 小时前
后端第九课:部署上线(把你的 FastAPI 后端真正跑起来给别人用)
python·docker·部署·fastapi
无足鸟ICT3 小时前
【RHCA+】RPM包命名规则
linux·运维·服务器
迪康Defender3 小时前
终端安全运维:浅谈迪康端点安全一体化管理系统工具箱实用能力
运维·安全·信息可视化·自动化·运维开发·学习方法·远程工作
广东帝工智能安防3 小时前
航道数智化升级实战:基于“云-网-数-智“架构的信息化基础设施建设方案
大数据·运维·人工智能
爱吃香菜的初学者3 小时前
十六.Linux——多线程(2)
linux·运维·开发语言