Device Mapper ストレージ・ドライバを使う¶

書き込み例¶

devicemapper ドライバで新しいデータをコンテナに書き込むには、オンデマンドの割り当て（allocate-on-demand） を行います。コピー・オン・ライト処理をによって、既存のデータを更新します。Device Mapper はブロック・ベースの技術のため、これらの処理はブロック・レベルで行われます。

例えば、コンテナ内の大きなファイルに小さな変更を加えるとき、 devicemapper ストレージ・ドライバはファイル全体コピーをコピーしません。コピーするのは、変更するブロックのみです。各ブロックは 64KB です。

新しいデータの書き込み¶

コンテナに 56KB の新しいデータを書き込みます。

1. アプリケーションはコンテナに 56KB の新しいデータの書き込みを要求します。

2. オンデマンドの割り当て処理により、コンテナのスナップショットに対して、新しい 64KB のブロックが１つ割り当てられます。

書き込み対象が 64KB よりも大きければ、複数の新しいブロックがコンテナに対して割り当てられます。

3. 新しく割り当てられたブロックにデータを書き込みます。

既存のデータを上書き¶

既存のデータに対して初めて変更を加える場合、

1. アプリケーションはコンテナ上にあるデータの変更を要求します。

2. 更新が必要なブロックに対して、コピー・オン・ライト処理が行われます。

3. 処理によって新しい空のブロックがコンテナのスナップショットに割り当てられ、そのブロックにデータがコピーされます。

3. 新しく割り当てられたブロックの中に、変更したデータを書き込みます。

コンテナ内のアプリケーションは、必要に応じた割り当てやコピー・オン・ライト処理を意識しません。しかしながら、アプリケーションの読み書き処理において、待ち時間を増やすでしょう。

プロダクション用に direct-lvm モードを設定¶

プロダクションへのデプロイに適した設定は direct lvm です。このモードはシン・プールの作成にブロック・デバイスを使います。以下の手順は、Docker ホストが devicemapper ストレージ・ドライバを direct-lvm 設定を使えるようにします。

以下の手順は 90GB のデータ・ボリュームと 4GB のメタデータ・ボリュームを作成し、ストレージ・プールの基礎として使います。ここでは別のブロック・デバイス /dev/xvdf を持っており、処理するための十分な空き容量があると想定しています。デバイスの識別子とボリューム・サイズは皆さんの環境とは異なるかもしれません。手順を勧めるときは、自分の環境にあわせて適切に置き換えてください。また、手順は Docker デーモンが stop （停止）した状態から始めることを想定しています。

1. Docker ホストにログインし、設定対象の Docker デーモンを停止します。

2. 終了したら、 /var/lib/docker ディレクトリに保管されている既存のイメージを削除します。

$ sudo rm -rf /var/lib/docker

3. もう１つのブロックデバイス上で pvcreate コマンドを使い、 LVM 物理ボリューム（PV; Physical Volume）を作成します。

$ sudo pvcreate /dev/xvdf
Physical volume `/dev/xvdf` successfully created

このデバイス識別子は、皆さんの環境によって異なります。このコマンドを実行する時は、適切な値に書き換えてください。

4. 先の手順で作成した物理ボリュームを使い、 vg-docker という名称の新しいボリューム・グループ（VG; Volume Group）を作成します。

$ sudo vgcreate vg-docker /dev/xvdf
Volume group `vg-docker` successfully created

5. vg-docker ボリューム・グループ上の領域に、 data という名所の新しい 90GB の論理ボリューム（LV; Logical Volume）を作成します。

$ sudo lvcreate -L 90G -n data vg-docker
Logical volume `data` created.

このコマンドは data と呼ばれる LVM 論理ボリュームを作成し、 /dev/vg-docker/data にであるブロック・デバイス・ファイルに関連づけます。後の手順で、 devicemapper ストレージ・ドライバがこのブロックデバイスを使い、イメージやコンテナのデータを保管するように指示します。

署名に関する警告が表示される場合は、作業を続ける前に、正しいデバイスが動作しているかどうか確認します。署名の警告が意味するのは、作業対象が LVM によって既に使われているか、あるいは過去に使われていたかです。

6. vg-docker ボリューム・グループ上の領域に、 metadata と呼ばれる新しい論議ボリューム(LV)を作成します。

$ sudo lvcreate -L 4G -n metadata vg-docker
Logical volume `metadata` created.

これは metadata という名称の LVM 論理ボリュームを作成し、 /dev/vg-docker/metadata にあるブロック・デバイス・ファイルに関連づけられます。次のステップで、 devicemapper ストレージ・ドライバがこのブロックデバイスを使い、イメージやコンテナのデータを保管するように指示します。

7. Docker デーモンが devicemapper ストレージ・ドライバを使って起動するため、 --storage-opt フラグを使います。

先ほどの手順で作成した data と metadata デバイスを --storage-opt オプションで指定します。

$ sudo docker daemon --storage-driver=devicemapper --storage-opt dm.datadev=/dev/vg-docker/data --storage-opt dm.metadatadev=/dev/vg-docker/metadata &
[1] 2163
[root@ip-10-0-0-75 centos]# INFO[0000] Listening for HTTP on unix (/var/run/docker.sock)
INFO[0027] Option DefaultDriver: bridge
INFO[0027] Option DefaultNetwork: bridge
<出力を省略>
INFO[0027] Daemon has completed initialization
INFO[0027] Docker daemon commit=0a8c2e3 execdriver=native-0.2 graphdriver=devicemapper version=1.8.2

また、 --storage-driver と --storage-opt フラグは Docker の設定ファイルか、デーモンの起動に使う service や systemd コマンドでも指定できます。

8. docker info コマンドを使い、デーモンが先ほど作成した data と metadata デバイスが使われていることを確認します。

$ sudo docker info
INFO[0180] GET /v1.20/info
Containers: 0
Images: 0
Storage Driver: devicemapper
 Pool Name: docker-202:1-1032-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: xfs
 Data file: /dev/vg-docker/data
 Metadata file: /dev/vg-docker/metadata
[...]

このコマンドの出力から、ストレージ・ドライバが devicemapper であることが分かります。最後の２行から、適切なデバイスが Datafile と Metadata file を使っていることも分かります。

ホスト上の devicemapper 構造の例¶

lsblk コマンドを使うと、先ほど作成したデバイス・ファイルと、その上に devicemapper ストレージ・ドライバによって作られた pool （プール）を確認できます。

$ 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   10G  0 disk
├─vg--docker-data          253:0    0   90G  0 lvm
│ └─docker-202:1-1032-pool 253:2    0   10G  0 dm
└─vg--docker-metadata      253:1    0    4G  0 lvm
  └─docker-202:1-1032-pool 253:2    0   10G  0 dm

下図は、先ほどの例で使ったイメージの更新を、 lsblk コマンドの詳細で表しています。

この図では、プールは Docker-202:1-1032-pool と名付けられ、先ほど作成した data と metadata デバイスに渡っています。この devicemapper のプール名は、次のような形式です。

Docker-MAJ:MIN-INO-pool

MAJ 、 NIN 、 INO は、デバイスのメジャー番号、マイナー番号、inode 番号です。

Device Mapper はブロック・レベルで処理を行うため、イメージ・レイヤとコンテナ間の差分を見るのは、少し大変です。しかしながら、２つの鍵となるディレクトリがあります。 /var/lib/docker/devicemapper/mnt ディレクトリには、イメージとコンテナのマウント・ポイントがあります。 /var/lib/docker/devicemapper/metadata ディレクトリには、それぞれのイメージとコンテナのスナップショットを格納する１つのファイルがあります。このファイルには、各スナップショットのメタデータが JSON 形式で含まれています。

オンデマンドの割り当てが性能に与える影響¶

devicemapper ストレージ・ドライバは、オンデマンドの割り当て処理時、コンテナに対して新しいブロックを割り当てます。この処理が意味するのは、コンテナの中でアプリケーションが何かを書き込みをするごとに、プールから１つまたは複数の空ブロックを探し、コンテナの中に割り当てます。

全てのブロックは 64KB です。64KB より小さな書き込みの場合でも、64Kb のブロックが１つ割り当てられます。これがコンテナの性能に影響を与えます。特にコンテナ内で多数の小さなファイルを書き込む場合に影響があるでしょう。しかしながら、一度ブロックがコンテナに対して割り当てられたら、以降の読み込みは対象のブロックを直接処理できます。

コピー・オン・ライトが性能に与える影響¶

コンテナ内のデータを初めて更新するたびに、毎回 devicemapper ストレージ・ドライバがコピー・オン・ライト処理を行います。このコピーとは、イメージのスナップショット上のデータを、コンテナのスナップショットにコピーするものです。この処理が、コンテナの性能に対して留意すべき影響を与えます。

コピー・オン・ライト処理は 64KB 単位で行われます。そのため、1GB のファイルのうち 32KB を更新する場合は、コンテナのスナップショット内にある 64KB のブロックをコピーします。これはファイル・レベルのコピー・オン・ライト処理に比べて、著しい性能をもたらします。ファイルレベルであれば、コンテナ・レイヤに含まれる 1GB のファイル全体をコピーする必要があるからです。

しかしながら、現実的には、コンテナが多くの小さなブロック（64KB以下）に書き込みをするのであれば、 devicemapper は AUFS を使うよりも性能が劣ります。

Device Mapper の性能に対するその他の考慮¶

devicemapper ストレージ・ドライバの性能に対して、他にもいくつかの影響を与える要素があります。

• モード ：Docker が devicemapper ストレージ・ドライバを使用する時、デフォルトのモードは loop-lvm です。このモードはスパース・ファイル（space files；薄いファイル）を使うので、性能を損ないます。そのため、 プロダクションへのデプロイでは推奨されません 。プロダクション環境で推奨されるモードは direct-lvm です。これはストレージ・ドライバが直接 raw ブロック・デバイスに書き込みます。

• 高速なストレージ ：ベストな性能を出すためには、 データ・ファイル と メタデータ・ファイル を、 SSD のような高速なストレージ上に配置すべきです。あるいは、 SAN や NAS アレイといった、ダイレクト・アタッチ・ストレージでも同様でしょう。

• メモリ使用量 ： devicemapper は Docker ストレージ・ドライバのなかで、最も悪いメモリ使用効率です。同じコンテナのｎ個のコピーを起動するとき、ｎ個のファイルをメモリ上にコピーします。これは、Docker ホスト上のメモリに対して影響があります。このため、 PaaS や他の高密度な用途には、devicemapper ストレージ・ドライバがベストな選択肢とは言えません。

最後に１点、データ・ボリュームは最上かつ最も予測可能な性能を提供します。これは、ストレージ・ドライバを迂回し、シン・プロビジョニングやコピー・オン・ライト処理を行わないためです。そのため、データ・ボリューム上で重たい書き込みを行うのに適しています。