关于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模式,看来天天趾高气昂的产品研发没有做产品封板前的检查呀,真不知道这产品质量测试时怎么通过压力测试的 。。。

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

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

相关推荐
大树881 天前
金刚石散热越强,管路越先见顶
大数据·运维·服务器·人工智能·ai
摇滚侠1 天前
Linux CentOS7 rpm 安装 MySQL 5.7
linux·运维·mysql
霸道流氓气质1 天前
领域驱动设计(DDD)在 Spring Boot 微服务中的实践指南
运维·spring boot·微服务
Inhand陈工1 天前
基于台达PLC与映翰通IG502的智慧水产养殖精准投喂与远程运维解决方案
运维·人工智能·物联网·阿里云·信息与通信
Alsn861 天前
等待学习-学习目录:Docker 容器安全攻防
学习·安全·docker
酣大智1 天前
ARP代理--工作原理
运维·网络·arp·arp代理
shushangyun_1 天前
2026年快消品B2B系统推荐:支持终端门店订货、促销政策自动化的工具?
java·运维·网络·数据库·人工智能·spring·自动化
施努卡机器视觉1 天前
SNK施努卡侧滑门锁上滑轮总成自动化装配线,从零件到组件,全流程精密制造方案
运维·自动化·制造
AC赳赳老秦1 天前
用 OpenClaw 搭建服务器故障应急响应系统,自动处理 80% 常见运维故障
android·运维·服务器·python·rxjava·deepseek·openclaw
2601_961875241 天前
决战申论100题2026|最新|范文
linux·容器·centos·debian·ssh·fabric·vagrant