使用设备映射器存储驱动程序（已弃用）

已弃用

Device Mapper 驱动程序 已被弃用，并在 Docker Engine v25.0 中被删除。如果您使用 Device Mapper，则必须先迁移到受支持的存储驱动程序，然后再升级到 Docker Engine v25.0。请阅读 Docker 存储驱动程序 页面以了解支持的存储驱动程序。

Device Mapper 是一个基于内核的框架，支持 Linux 上的许多高级卷管理技术。 Docker 的devicemapper存储驱动程序利用该框架的精简配置和快照功能来进行映像和容器管理。本文将 Device Mapper 存储驱动程序称为 Device Mapper devicemapper，将内核框架称为Device Mapper。

对于支持它的系统，devicemapperLinux 内核中包含支持。但是，需要特定配置才能将其与 Docker 一起使用。

该devicemapper驱动程序使用 Docker 专用的块设备，并在块级别（而不是文件级别）运行。这些设备可以通过向 Docker 主机添加物理存储来扩展，并且它们的性能比在操作系统 (OS) 级别使用文件系统更好。

先决条件

  • devicemapper在 CentOS、Fedora、SLES 15、Ubuntu、Debian 或 RHEL 上运行的 Docker 引擎 - 社区受支持。
  • devicemapper需要安装lvm2和软件包。device-mapper-persistent-data
  • 更改存储驱动程序会使您已创建的任何容器在本地系统上无法访问。用于docker save保存容器，并将现有镜像推送到 Docker Hub 或私有存储库，这样您以后就不需要重新创建它们。

使用 devicemapper 存储驱动程序配置 Docker

在执行这些过程之前，您必须首先满足所有 先决条件。

配置loop-lvm模式进行测试

此配置仅适用于测试。该loop-lvm模式利用“环回”机制，允许读取和写入本地磁盘上的文件，就像它们是实际的物理磁盘或块设备一样。然而，环回机制的添加以及与操作系统文件系统层的交互意味着 IO 操作可能会很慢并且会占用大量资源。使用环回设备也会引入竞争条件。但是，在尝试启用模式loop-lvm所需的更复杂的设置之前，设置模式可以帮助识别基本问题（例如缺少用户空间包、内核驱动程序等）。因此，模式只能用于在配置之前执行基本测试 。direct-lvmloop-lvmdirect-lvm

对于生产系统，请参阅 为生产配置 direct-lvm 模式。

  1. 停止 Docker。

    $ sudo systemctl stop docker

  2. 编辑/etc/docker/daemon.json。如果它尚不存在，请创建它。假设该文件为空，添加以下内容。

    {
  "storage-driver": "devicemapper"
}

    请参阅守护程序参考文档中每个存储驱动程序的所有存储选项

    daemon.json如果文件包含格式错误的 JSON，则Docker 不会启动。

  3. 启动 Docker。

    $ sudo systemctl start docker

  4. 验证守护程序是否正在使用devicemapper存储驱动程序。使用 docker info命令并查找Storage Driver.

    $ docker info

  Containers: 0
    Running: 0
    Paused: 0
    Stopped: 0
  Images: 0
  Server Version: 17.03.1-ce
  Storage Driver: devicemapper
  Pool Name: docker-202:1-8413957-pool
  Pool Blocksize: 65.54 kB
  Base Device Size: 10.74 GB
  Backing Filesystem: xfs
  Data file: /dev/loop0
  Metadata file: /dev/loop1
  Data Space Used: 11.8 MB
  Data Space Total: 107.4 GB
  Data Space Available: 7.44 GB
  Metadata Space Used: 581.6 KB
  Metadata Space Total: 2.147 GB
  Metadata Space Available: 2.147 GB
  Thin Pool Minimum Free Space: 10.74 GB
  Udev Sync Supported: true
  Deferred Removal Enabled: false
  Deferred Deletion Enabled: false
  Deferred Deleted Device Count: 0
  Data loop file: /var/lib/docker/devicemapper/data
  Metadata loop file: /var/lib/docker/devicemapper/metadata
  Library Version: 1.02.135-RHEL7 (2016-11-16)
<...>

该主机正在以生产系统不loop-lvm支持的模式运行。 和 a位于 下的文件中 这一事实表明了这一点。这些是环回安装的稀疏文件。对于生产系统，请参阅 为生产配置 direct-lvm 模式。Data loop fileMetadata loop file/var/lib/docker/devicemapper

为生产配置 direct-lvm 模式

使用存储驱动程序的生产主机devicemapper必须使用direct-lvm 模式。此模式使用块设备创建精简池。这比使用环回设备更快，更有效地使用系统资源，并且块设备可以根据需要增长。然而，比模式下需要更多的设置loop-lvm 。

满足 先决条件后，请按照以下步骤将 Docker 配置为devicemapper在 direct-lvm模式下使用存储驱动程序。

警告：更改存储驱动程序会使您已创建的任何容器在本地系统上无法访问。用于docker save保存容器，并将现有镜像推送到 Docker Hub 或私有存储库，这样您以后就不需要重新创建它们。

允许Docker配置direct-lvm模式

Docker可以为你管理块设备，简化direct-lvm 模式的配置。这仅适用于新的 Docker 设置。您只能使用单个块设备。如果需要使用多个块设备， 请手动配置 direct-lvm 模式。提供以下新配置选项：

选项描述必需的？默认例子
dm.directlvm_device要配置的块设备的路径direct-lvm。是的dm.directlvm_device="/dev/xvdf"
dm.thinp_percent传入的块设备中用于存储的空间百分比。不95dm.thinp_percent=95
dm.thinp_metapercent传入的块设备中用于元数据存储的空间百分比。不1dm.thinp_metapercent=1
dm.thinp_autoextend_thresholdlvm 应自动扩展精简池的阈值（占总存储空间的百分比）。不80dm.thinp_autoextend_threshold=80
dm.thinp_autoextend_percent触发自动扩展时精简池增加的百分比。不20dm.thinp_autoextend_percent=20
dm.directlvm_device_force是否格式化块设备，即使其上已存在文件系统。如果设置为false并且存在文件系统，则会记录错误并且文件系统保持不变。不错误的dm.directlvm_device_force=true

编辑daemon.json文件并设置适当的选项，然后重新启动 Docker 以使更改生效。以下daemon.json配置设置上表中的所有选项。

{
  "storage-driver": "devicemapper",
  "storage-opts": [
    "dm.directlvm_device=/dev/xdf",
    "dm.thinp_percent=95",
    "dm.thinp_metapercent=1",
    "dm.thinp_autoextend_threshold=80",
    "dm.thinp_autoextend_percent=20",
    "dm.directlvm_device_force=false"
  ]
}

请参阅守护程序参考文档中每个存储驱动程序的所有存储选项

重新启动 Docker 以使更改生效。 Docker 调用命令来为您配置块设备。

警告：不支持在 Docker 为您准备好块设备后更改这些值，否则会导致错误。

您仍然需要 执行定期维护任务。

手动配置direct-lvm模式

以下过程创建一个配置为精简池的逻辑卷，以用作存储池的后备。它假设您有一个备用块设备，/dev/xvdf有足够的可用空间来完成任务。您的环境中的设备标识符和卷大小可能有所不同，您应该在整个过程中替换您自己的值。该过程还假设 Docker 守护进程处于该stopped状态。

  1. 确定您要使用的块设备。该设备位于 /dev/（例如/dev/xvdf）下，需要足够的可用空间来存储主机运行的工作负载的映像和容器层。固态硬盘是理想的选择。

  2. 停止 Docker。

    $ sudo systemctl stop docker

  3. 安装以下软件包：

    • RHEL/CentOS：device-mapper-persistent-data、、lvm2以及所有依赖项

    • Ubuntu / Debian / SLES 15：thin-provisioning-tools、、lvm2以及所有依赖项

  4. 使用以下命令在步骤 1 中的块设备上创建物理卷 pvcreate。将 替换为您的设备名称/dev/xvdf。

    警告：接下来的几个步骤具有破坏性，因此请确保您指定了正确的设备！

    $ sudo pvcreate /dev/xvdf

Physical volume "/dev/xvdf" successfully created.

  5. docker使用以下命令在同一设备上创建卷组vgcreate 。

    $ sudo vgcreate docker /dev/xvdf

Volume group "docker" successfully created

  6. 使用 命令创建两个名为thinpool和的逻辑卷。最后一个参数指定可用空间量，以允许在空间不足时自动扩展数据或元数据，作为临时的权宜之计。这些是推荐值。thinpoolmetalvcreate

    $ sudo lvcreate --wipesignatures y -n thinpool docker -l 95%VG

Logical volume "thinpool" created.

$ sudo lvcreate --wipesignatures y -n thinpoolmeta docker -l 1%VG

Logical volume "thinpoolmeta" created.

  7. 使用命令将卷转换为精简池以及精简池元数据的存储位置lvconvert。

    $ sudo lvconvert -y \
--zero n \
-c 512K \
--thinpool docker/thinpool \
--poolmetadata docker/thinpoolmeta

WARNING: Converting logical volume docker/thinpool and docker/thinpoolmeta to
thin pool's data and metadata volumes with metadata wiping.
THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
Converted docker/thinpool to thin pool.

  8. 通过配置文件配置精简池的自动扩展lvm。

    $ sudo vi /etc/lvm/profile/docker-thinpool.profile

  9. 指定thin_pool_autoextend_threshold和thin_pool_autoextend_percent 值。

    thin_pool_autoextend_thresholdlvm 是尝试自动扩展可用空间之前已使用的空间百分比（100 = 禁用，不推荐）。

    thin_pool_autoextend_percent是自动扩展时添加到设备的空间量（0 = 禁用）。

    下面的示例在磁盘使用率达到 80% 时增加 20% 的容量。

    activation {
  thin_pool_autoextend_threshold=80
  thin_pool_autoextend_percent=20
}

    保存文件。

  10. 使用以下命令应用 LVM 配置文件lvchange。

    $ sudo lvchange --metadataprofile docker-thinpool docker/thinpool

Logical volume docker/thinpool changed.

  11. 确保启用逻辑卷监控。

    $ sudo lvs -o+seg_monitor

LV       VG     Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Monitor
thinpool docker twi-a-t--- 95.00g             0.00   0.01                             not monitored

    如果列中的输出Monitor报告如上所示，卷为 not monitored，则需要显式启用监视。如果没有此步骤，无论应用的配置文件中的任何设置如何，都不会发生逻辑卷的自动扩展。

    $ sudo lvchange --monitor y docker/thinpool

    sudo lvs -o+seg_monitor通过再次运行该命令来仔细检查监控现在是否已启用 。该Monitor列现在应该报告逻辑卷正在运行monitored。

  12. 如果您以前曾在此主机上运行过 Docker，或者如果/var/lib/docker/ 存在，请将其移开，以便 Docker 可以使用新的 LVM 池来存储映像和容器的内容。

    $ sudo su -
# mkdir /var/lib/docker.bk
# mv /var/lib/docker/* /var/lib/docker.bk
# exit

    如果以下任何步骤失败并且您需要恢复，您可以将 /var/lib/docker其删除并替换为/var/lib/docker.bk.

  13. 编辑/etc/docker/daemon.json和配置存储驱动程序所需的选项 devicemapper。如果该文件以前为空，则它现在应包含以下内容：

    {
    "storage-driver": "devicemapper",
    "storage-opts": [
    "dm.thinpooldev=/dev/mapper/docker-thinpool",
    "dm.use_deferred_removal=true",
    "dm.use_deferred_deletion=true"
    ]
}

  14. 启动 Docker。

    系统：

    $ sudo systemctl start docker

    服务：

    $ sudo service docker start

  15. 使用 验证 Docker 是否正在使用新配置docker info。

    $ docker info

Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 17.03.1-ce
Storage Driver: devicemapper
 Pool Name: docker-thinpool
 Pool Blocksize: 524.3 kB
 Base Device Size: 10.74 GB
 Backing Filesystem: xfs
 Data file:
 Metadata file:
 Data Space Used: 19.92 MB
 Data Space Total: 102 GB
 Data Space Available: 102 GB
 Metadata Space Used: 147.5 kB
 Metadata Space Total: 1.07 GB
 Metadata Space Available: 1.069 GB
 Thin Pool Minimum Free Space: 10.2 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: true
 Deferred Deletion Enabled: true
 Deferred Deleted Device Count: 0
 Library Version: 1.02.135-RHEL7 (2016-11-16)
<...>

    如果 Docker 配置正确，则Data file和Metadata file为空，池名称为docker-thinpool。

  16. 确认配置正确后，您可以删除 /var/lib/docker.bk包含先前配置的目录。

    $ sudo rm -rf /var/lib/docker.bk

管理设备映射器

监控精简池

不要单独依赖 LVM 自动扩展。卷组会自动扩展，但卷仍会被填满。您可以使用lvs或监视卷上的可用空间lvs -a。考虑在操作系统级别使用监控工具，例如 Nagios。

要查看 LVM 日志，您可以使用journalctl：

$ sudo journalctl -fu dm-event.service

如果您在使用精简池时反复遇到问题，可以将存储选项设置 dm.min_free_space为 中的一个值（表示百分比） /etc/docker/daemon.json。例如，将其设置为10确保当可用空间达到或接近 10% 时操作失败并发出警告。请参阅 引擎守护程序参考中的存储驱动程序选项。

增加正在运行的设备的容量

您可以增加正在运行的精简池设备上的池容量。如果数据的逻辑卷已满并且卷组已满容量，则这非常有用。具体过程取决于您使用的是 loop-lvm精简池还是 direct-lvm精简池。

调整loop-lvm精简池的大小

调整loop-lvm精简池大小的最简单方法是 使用 device_tool 实用程序，但您也可以 使用操作系统实用程序 。

使用 device_tool 实用程序

moby/mobydevice_tool.go Github 存储库中提供了 一个名为 的社区贡献脚本 。您可以使用此工具调整精简池的大小，从而避免上述漫长的过程。不保证该工具能够正常工作，但您应该只在非生产系统上使用。loop-lvmloop-lvm

如果您不想使用device_tool，则可以 手动调整精简池的大小。

  1. 要使用该工具，请克隆 Github 存储库，更改为 contrib/docker-device-tool，然后按照 中的说明README.md 编译该工具。

  2. 使用该工具。以下示例将精简池大小调整为 200GB。

    $ ./device_tool resize 200GB
使用操作系统实用程序

如果您不想 使用 device-tool 实用程序，可以loop-lvm使用以下过程手动调整精简池的大小。

在loop-lvm模式下，一个环回设备用于存储数据，另一个环回设备用于存储元数据。loop-lvm模式仅支持测试，因为它具有显着的性能和稳定性缺陷。

如果您使用的是loop-lvm模式，则 的输出docker info显示Data loop file和 的文件路径Metadata loop file：

$ docker info |grep 'loop file'

 Data loop file: /var/lib/docker/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/metadata

请按照以下步骤增加精简池的大小。在此示例中，精简池为 100 GB，并增加到 200 GB。

  1. 列出设备的尺寸。

    $ sudo ls -lh /var/lib/docker/devicemapper/

total 1175492
-rw------- 1 root root 100G Mar 30 05:22 data
-rw------- 1 root root 2.0G Mar 31 11:17 metadata

  2. 使用命令将文件大小增加到data200G truncate，该命令用于增加或减少文件的大小。请注意，减小尺寸是一种破坏性操作。

    $ sudo truncate -s 200G /var/lib/docker/devicemapper/data

  3. 验证文件大小已更改。

    $ sudo ls -lh /var/lib/docker/devicemapper/

total 1.2G
-rw------- 1 root root 200G Apr 14 08:47 data
-rw------- 1 root root 2.0G Apr 19 13:27 metadata

  4. 环回文件在磁盘上已更改，但在内存中未更改。列出内存中环回设备的大小（以 GB 为单位）。重新加载它，然后再次列出尺寸。重新加载后，大小为200 GB。

    $ echo $[ $(sudo blockdev --getsize64 /dev/loop0) / 1024 / 1024 / 1024 ]

100

$ sudo losetup -c /dev/loop0

$ echo $[ $(sudo blockdev --getsize64 /dev/loop0) / 1024 / 1024 / 1024 ]

200

  5. 重新加载 devicemapper 精简池。

    A。首先获取池名称。池名称是第一个字段，以 分隔 :。此命令将其提取。

    $ sudo dmsetup status | grep ' thin-pool ' | awk -F ': ' {'print $1'}
docker-8:1-123141-pool

    b.转储精简池的设备映射器表。

    $ sudo dmsetup table docker-8:1-123141-pool
0 209715200 thin-pool 7:1 7:0 128 32768 1 skip_block_zeroing

    C。使用输出的第二个字段计算精简池的总扇区。该数量以 512-k 扇区表示。一个 100G 文件有 209715200 个 512-k 扇区。如果将此数字加倍到 200G，您将获得 419430400 个 512-k 扇区。

    d.使用以下三个命令使用新扇区号重新加载精简池dmsetup。

    $ sudo dmsetup suspend docker-8:1-123141-pool
$ sudo dmsetup reload docker-8:1-123141-pool --table '0 419430400 thin-pool 7:1 7:0 128 32768 1 skip_block_zeroing'
$ sudo dmsetup resume docker-8:1-123141-pool

调整 direct-lvm 精简池的大小

要扩展direct-lvm精简池，您需要首先将新的块设备附加到 Docker 主机，并记下内核分配给它的名称。在此示例中，新的块设备是/dev/xvdg。

按照此过程扩展direct-lvm精简池，替换块设备和其他参数以适合您的情况。

  1. 收集有关您的卷组的信息。

    使用该pvdisplay命令查找精简池当前正在使用的物理块设备以及卷组的名称。

    $ sudo pvdisplay |grep 'VG Name'

PV Name               /dev/xvdf
VG Name               docker

    在以下步骤中，根据需要替换块设备或卷组名称。

  2. vgextend使用上一步中的命令以及新VG Name块设备 的名称来扩展卷组。

    $ sudo vgextend docker /dev/xvdg

Physical volume "/dev/xvdg" successfully created.
Volume group "docker" successfully extended

  3. 扩展docker/thinpool逻辑卷。此命令立即使用 100% 的音量，而不自动扩展。要扩展元数据精简池，请使用docker/thinpool_tmeta.

    $ sudo lvextend -l+100%FREE -n docker/thinpool

Size of logical volume docker/thinpool_tdata changed from 95.00 GiB (24319 extents) to 198.00 GiB (50688 extents).
Logical volume docker/thinpool_tdata successfully resized.

  4. Data Space Available使用的输出中的字段验证新的精简池大小docker info。如果您扩展了docker/thinpool_tmeta逻辑卷，请查找Metadata Space Available.

    Storage Driver: devicemapper
 Pool Name: docker-thinpool
 Pool Blocksize: 524.3 kB
 Base Device Size: 10.74 GB
 Backing Filesystem: xfs
 Data file:
 Metadata file:
 Data Space Used: 212.3 MB
 Data Space Total: 212.6 GB
 Data Space Available: 212.4 GB
 Metadata Space Used: 286.7 kB
 Metadata Space Total: 1.07 GB
 Metadata Space Available: 1.069 GB
<...>

重启后激活devicemapper

如果重新启动主机并发现docker服务无法启动，请查找错误“不存在设备”。您需要使用以下命令重新激活逻辑卷：

$ sudo lvchange -ay docker/thinpool

devicemapper存储驱动程序如何工作

警告：不要直接操作其中的任何文件或目录 /var/lib/docker/。这些文件和目录由 Docker 管理。

使用以下lsblk命令从操作系统的角度查看设备及其池：

$ sudo lsblk

NAME                    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda                    202:0    0    8G  0 disk
└─xvda1                 202:1    0    8G  0 part /
xvdf                    202:80   0  100G  0 disk
├─docker-thinpool_tmeta 253:0    0 1020M  0 lvm
│ └─docker-thinpool     253:2    0   95G  0 lvm
└─docker-thinpool_tdata 253:1    0   95G  0 lvm
  └─docker-thinpool     253:2    0   95G  0 lvm

使用mount命令查看 Docker 正在使用的挂载点：

$ mount |grep devicemapper
/dev/xvda1 on /var/lib/docker/devicemapper type xfs (rw,relatime,seclabel,attr2,inode64,noquota)

当您使用 时devicemapper，Docker 将图像和图层内容存储在 Thinpool 中，并通过将它们挂载在 的子目录下将它们公开给容器/var/lib/docker/devicemapper/。

磁盘上的映像和容器层

该/var/lib/docker/devicemapper/metadata/目录包含有关 Devicemapper 配置本身以及有关存在的每个映像和容器层的元数据。存储devicemapper驱动程序使用快照，并且此元数据包括有关这些快照的信息。这些文件采用 JSON 格式。

该/var/lib/docker/devicemapper/mnt/目录包含每个存在的映像和容器层的安装点。镜像层挂载点是空的，但容器的挂载点显示了容器的文件系统，就像它在容器内出现的那样。

图像分层和共享

存储devicemapper驱动程序使用专用块设备而不是格式化文件系统，并在块级别对文件进行操作，以在写时复制 (CoW) 操作期间获得最大性能。

快照

另一个特点devicemapper是它使用快照（有时也称为 精简设备或虚拟设备），它将每一层中引入的差异存储为非常小的、轻量级的精简池。快照有很多好处：

  • 容器之间共享的层仅在磁盘上存储一次，除非它们是可写的。例如，如果您有 10 个不同的图像，它们都基于alpine，则该alpine图像及其所有父图像仅在磁盘上存储一次。

  • 快照是写时复制 (CoW) 策略的实现。这意味着给定的文件或目录仅在被容器修改或删除时才会复制到容器的可写层。

  • 由于devicemapper在块级别操作，因此可以同时修改可写层中的多个块。

  • 可以使用标准操作系统级备份实用程序来备份快照。只需复制一份/var/lib/docker/devicemapper/.

设备映射器工作流程

当您使用存储驱动程序启动 Docker 时devicemapper，与映像和容器层相关的所有对象都存储在 中 /var/lib/docker/devicemapper/，该文件由一个或多个块级设备（环回设备（仅测试）或物理磁盘）支持。

  • 基础设备是最低级别的对象。这是精简池本身。您可以使用检查它docker info。它包含一个文件系统。该基础设备是每个镜像和容器层的起点。基础设备是设备映射器实现细节，而不是 Docker 层。

  • /var/lib/docker/devicemapper/metadata/有关基础设备和每个映像或容器层的元数据以 JSON 格式存储 。这些层是写时复制快照，这意味着它们在与父层分离之前是空的。

  • 每个容器的可写层都安装在 /var/lib/docker/devicemapper/mnt/.每个只读映像层和每个停止的容器都存在一个空目录。

每个图像层都是其下方层的快照。每个映像的最低层是池中存在的基本设备的快照。当您运行容器时，它是容器所基于的映像的快照。以下示例显示了具有两个正在运行的容器的 Docker 主机。第一个是ubuntu 容器，第二个是busybox容器。

Ubuntu 和 busybox 图像层

容器如何使用 devicemapper 进行读写

读取文件

对于devicemapper，读取发生在块级别。下图显示了0x44f在示例容器中读取单个块 ( ) 的高级流程。

使用 devicemapper 读取块

0x44f应用程序对容器中的块发出读取请求。由于容器是图像的精简快照，因此它没有该块，但它有一个指向该块所在的最近父图像上的块的指针，并且它从那里读取该块。该块现在存在于容器的内存中。

写入文件

写入新文件：使用devicemapper驱动程序，将新数据写入容器是通过按需分配操作完成的。新文件的每个块都被分配在容器的可写层中，并且该块被写入那里。

更新现有文件：从文件存在的最近层读取文件的相关块。当容器写入文件时，只有修改的块才会写入容器的可写层。

删除文件或目录：当您删除容器的可写层中的文件或目录时，或者当镜像层删除其父层中存在的文件时，devicemapper存储驱动程序会拦截对该文件或目录的进一步读取尝试，并响应文件或目录不存在。

写入然后删除文件：如果容器写入文件然后删除该文件，则所有这些操作都发生在容器的可写层中。在这种情况下，如果您使用direct-lvm，则块将被释放。如果您使用loop-lvm，则可能无法释放块。这是不在loop-lvm生产中使用的另一个原因 。

设备映射器和 Docker 性能

  • allocate-on demand性能影响：

    存储devicemapper驱动程序使用一个allocate-on-demand操作将新块从精简池分配到容器的可写层中。每个块为 64KB，因此这是用于写入的最小空间量。

  • 写时复制性能影响：容器第一次修改特定块时，该块将被写入容器的可写层。由于这些写入发生在块级别而不是文件级别，因此对性能的影响最小化。但是，写入大量块仍然会对性能产生负面影响，并且devicemapper在这种情况下，存储驱动程序实际上可能比其他存储驱动程序表现更差。对于写入密集型工作负载，您应该使用数据卷，它完全绕过存储驱动程序。

性能最佳实践

使用存储驱动程序时请记住这些事项，以最大限度地提高性能devicemapper 。

  • 使用direct-lvm：该loop-lvm模式不具有高性能，切勿在生产中使用。

  • 使用快速存储：固态驱动器 (SSD) 提供比旋转磁盘更快的读取和写入速度。

  • 内存使用：devicemapper比其他一些存储驱动程序使用更多的内存。每个启动的容器都会将其文件的一个或多个副本加载到内存中，具体取决于同时修改同一文件的块数。由于内存压力，devicemapper存储驱动程序可能不是高密度用例中某些工作负载的正确选择。

  • 将卷用于写入密集型工作负载：卷为写入密集型工作负载提供最佳且最可预测的性能。这是因为它们绕过存储驱动程序，并且不会产生精简配置和写时复制带来的任何潜在开销。卷还有其他好处，例如允许您在容器之间共享数据，甚至在没有正在运行的容器使用它们时也能保留数据。

  • 注意：使用日志驱动程序时devicemapper，json-file容器生成的日志文件默认仍存储在 Docker 的 dataroot 目录中/var/lib/docker。如果您的容器生成大量日志消息，这可能会导致磁盘使用量增加或由于磁盘已满而无法管理系统。您可以配置 日志驱动程序以在外部存储容器日志。