使用设备映射器存储驱动程序

预计阅读时间：28分钟

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

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

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

先决条件

  • devicemapper 在Docker Engine上受支持-在CentOS，Fedora，Ubuntu或Debian上运行的社区。
  • devicemapper需要安装lvm2和device-mapper-persistent-data软件包。
  • 更改存储驱动程序将使您已经创建的所有容器在本地系统上均不可访问。使用docker save保存的容器，并推动现有图像多克尔集线器或私人仓库，这样你就不会需要稍后重新创建。

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

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

配置loop-lvm测试模式

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

对于生产系统，请参阅为生产 配置直接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模式运行，生产系统不支持该模式。这可以通过以下事实来表明：Data loop file 和Metadata loop file均位于下方的文件中 /var/lib/docker/devicemapper。这些是环回安装的稀疏文件。对于生产系统，请参阅为生产 配置直接lvm​​模式。

配置Direct-LVM模式进行生产

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

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

警告：更改存储驱动程序将使您已经创建的所有容器在本地系统上均不可访问。使用docker save保存的容器，并推动现有图像多克尔集线器或私人仓库，这样你就不会需要稍后重新创建。

允许Docker配置Direct-LVM模式

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

选项 描述 必需的？ 默认 例子
dm.directlvm_device 要为其配置的块设备的路径direct-lvm。 是的   dm.directlvm_device="/dev/xvdf"
dm.thinp_percent 传入的块设备中用于存储的空间百分比。 不 95 dm.thinp_percent=95
dm.thinp_metapercent 来自传入的块设备的用于元数据存储的空间百分比。 不 1个 dm.thinp_metapercent=1
dm.thinp_autoextend_threshold lvm何时应自动扩展精简池的阈值占总存储空间的百分比。 不 80 dm.thinp_autoextend_threshold=80
dm.thinp_autoextend_percent 触发自动扩展时增加精简池的百分比。 不 20 dm.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的：thin-provisioning-tools，lvm2，和所有的依赖

  4. 使用pvcreate命令在步骤1的块设备上创建物理卷 。将您的设备名称替换为/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_threshold是在lvm 尝试自动扩展可用空间之前使用的空间百分比（100 =禁用，不推荐）。

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

    当磁盘使用率达到80％时，下面的示例将容量增加20％。

    activation {
  thin_pool_autoextend_threshold=80
  thin_pool_autoextend_percent=20
}

    保存文件。

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

    $ 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。

    systemd：

    $ 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 fileandMetadata 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％或接近10％时，操作将失败并显示警告。请参阅《引擎守护程序参考》中的 存储驱动程序选项。

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

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

调整Loop-LVM精简池的大小

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

使用device_tool实用程序

Moby / moby Github存储库中device_tool.go提供了 一个由社区贡献的脚本，称为。您可以使用此工具来调整精简池的大小，从而避免了上述漫长的过程。不能保证此工具可以工作，但是您只能在非生产系统上使用。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. data使用truncate命令将文件的大小增加到200 G，该命令用于增加或减小文件的大小。请注意，减小大小是一种破坏性的操作。

    $ 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精简池。

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

        $ 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

调整直接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存储驱动程序使用专用的块设备，而不是格式化的文件系统，并在写入时复制（全体）操作上以获得最大性能的块级的文件进行操作。

快照

devicemapper快照的另一个功能是使用快照（有时也称为 精简设备或虚拟设备），它们将在每一层中引入的差异存储为非常小的，轻量级的精简池。快照具有许多优点：

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

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

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

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

Devicemapper工作流程

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

  • 所述基部设备是最低级的对象。这就是瘦池本身。您可以使用检查它docker info。它包含一个文件系统。此基本设备是每个图像和容器层的起点。基本设备是Device Mapper实现细节，而不是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。如果您的容器生成大量日志消息，则可能会导致磁盘使用率增加或由于磁盘已满而无法管理系统。您可以配置 日志驱动程序以在外部存储容器日志。

容器，存储，驱动程序，设备映射