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

Btrfs の未来¶

Btrfs は将来の Linux ファイルシステムとして、長く認められています。Linux カーネルの主流として完全にサポートされ、安定したオン・ディスク・フォーマットと、安定性に焦点をあてた活発な開発がされていることが、より現実性を高めています。

Linux プラットフォームで Docker を使う限り、多くの人々は btrfs ストレージドライバが devicemapper ストレージ・ドライバを長期的に置き換えるものに見えてしまうでしょう。しかし、これを書いている時点では、 devicemapper ストレージ・ドライバのほうが安全で、より安定しており、より プロダクションに対応している と考えるべきです。 btrfs ドライバを理解し、Btrfs の経験がある場合のみ、プロダクションの開発に btrfs ドライバを検討すべきでしょう。

Btrfs でイメージのレイヤ化と共有¶

ディスク上のイメージの構成物とコンテナ・レイヤを管理するため、Docker は Btrfs の サブボリューム と スナップショット を活用します。Btrfs サブボリュームの見た目は通常の Unix ファイルシステムです。各々が内部にディレクトリ構造を持つのは、幅広い Unix ファイルシステムで見られるものです。

サブボリュームはコピー・オン・ライトにネイティブに対応しており、必要があれば基礎をなすストレージ・プールから領域を割り当てます。又、領域はネスト（入れ子）にすることができ、スナップ化できます。次の図は４つのボリュームを表します。「サブボリューム４」は内部にディレクトリ・ツリーを持っているのに対し、「サブボリューム２」と「サブボリューム３」はネストされたものです。

スナップショットとは、ある時点におけるサブボリューム全体の読み書きをコピーします。既存のディレクトリの下にサブボリュームが作成されます。下図のように、スナップショットのスナップショットも作成できます。

サブボリュームとスナップショットの必要に応じ、Btrfs は基盤をなすストレージ・プールから領域を割り当てます。割り当ての単位は chunk と chunks から参照され、通常は 1GB 以下の大きさです。

スナップショットは Btrfs ファイルシステム上の優秀な機能です。言い換えると、通常のサブボリュームと同じ見た目と、手触りであり、操作が可能です。ネイティブなコピー・オン・ライトの設計のおかげで、Btrfs ファイルシステム内のディレクトリにサブボリュームを構築する時、この技術が必要になります。つまり、Btrfs スナップショットは性能のオーバヘッドが少ない、あるいは無く、効率的に領域を使います。次の図はサブボリュームであり、そのスナップショットが同じデータを共有しているものです。

Docker の btrfs ストレージ・ドライバは各イメージ・レイヤとコンテナを、自身の Btrfs サブボリュームかスナップショットに保管します。イメージのベース・レイヤはサブボリュームとして保管されます。それに対して子イメージ・レイヤとコンテナはスナップショットに保管されます。これを説明したのが下図です。

Docker ホストが btrfs ドライバを使い、イメージとコンテナの作成という高レベルのプロセスは、次のように行います。

1. イメージのベース・レイヤは /var/lib/docker/btrfs/subvolumes 以下の Btrfs サブボリュームに保管されます。

イメージ ID はサブボリューム名として使用されミズ合う。例えば、ベース・レイヤのイメージ ID が「f9a9f253f6105141e0f8e091a6bcdb19e3f27af949842db93acba9048ed2410b」であれば、これが保管されるのは /var/lib/docker/btrfs/subvolumes/f9a9f253f6105141e0f8e091a6bcdb19e3f27af949842db93acba9048ed2410b です。

2. 以降のイメージ・レイヤは、親レイヤのサブボリュームの Btrfs スナップショットとして保存されるか、スナップショットになります。

以下の図は３つのイメージ・レイヤを表しています。ベース・レイヤはサブボリュームです。レイヤ１はベース・レイヤに対するサブボリュームのスナップショットです。レイヤ２はレイヤ１のスナップショットです。

ディスク構造上のイメージとコンテナ¶

イメージ・レイヤとコンテナは Docker ホスト上のファイルシステム /var/lib/docker/btrfs/subvolumes/<イメージ ID> か <コンテナID> で見られます。コンテナ用のディレクトリは、コンテナが停止した状態でも表示されます。ストレージ・ドライバがデフォルトでマウントするのは、 /var/lib/docker/subvolumes のサブボリュームをトップレベルとする場所です。その他すべてのサブボリュームとボリューム名は Btrfs ファイルシステムのオブジェクトとして、個々にマウントするのではなく、この下に存在しています。

以下は、４つのイメージ・レイヤを持つ Docker イメージの例です。

$ sudo docker images -a
REPOSITORY          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
ubuntu              latest              0a17decee413        2 weeks ago         188.3 MB
<none>              <none>              3c9a9d7cc6a2        2 weeks ago         188.3 MB
<none>              <none>              eeb7cb91b09d        2 weeks ago         188.3 MB
<none>              <none>              f9a9f253f610        2 weeks ago         188.1 MB

各イメージ・レイヤは Bitrfs サブボリュームかスナップショットとして存在しています。それぞれイメージ ID と同じ名前を持っており、以下のように btrfs subvolume list で確認できます。

$ sudo btrfs subvolume list /var/lib/docker
ID 257 gen 9 top level 5 path btrfs/subvolumes/f9a9f253f6105141e0f8e091a6bcdb19e3f27af949842db93acba9048ed2410b
ID 258 gen 10 top level 5 path btrfs/subvolumes/eeb7cb91b09d5de9edb2798301aeedf50848eacc2123e98538f9d014f80f243c
ID 260 gen 11 top level 5 path btrfs/subvolumes/3c9a9d7cc6a235eb2de58ca9ef3551c67ae42a991933ba4958d207b29142902b
ID 261 gen 12 top level 5 path btrfs/subvolumes/0a17decee4139b0de68478f149cc16346f5e711c5ae3bb969895f22dd6723751

/var/lib/docker/btrfs/subvolumes ディレクトリの下には、各サブボリュームとスナップショットが 通常の Unix ディレクトリとして見えます。

$ ls -l /var/lib/docker/btrfs/subvolumes/
total 0
drwxr-xr-x 1 root root 132 Oct 16 14:44 0a17decee4139b0de68478f149cc16346f5e711c5ae3bb969895f22dd6723751
drwxr-xr-x 1 root root 132 Oct 16 14:44 3c9a9d7cc6a235eb2de58ca9ef3551c67ae42a991933ba4958d207b29142902b
drwxr-xr-x 1 root root 132 Oct 16 14:44 eeb7cb91b09d5de9edb2798301aeedf50848eacc2123e98538f9d014f80f243c
drwxr-xr-x 1 root root 132 Oct 16 14:44 f9a9f253f6105141e0f8e091a6bcdb19e3f27af949842db93acba9048ed2410b

Btrfs はファイルシステム・レベルで動作するのであり、ブロック・レベルではありません。各イメージとコンテナのレイヤは、通常の Unix コマンドを使って参照できます。次の例は、イメージの最上位レイヤに対して ls -l コマンドを実行した結果を省略したものです。

$ ls -l /var/lib/docker/btrfs/subvolumes/0a17decee4139b0de68478f149cc16346f5e711c5ae3bb969895f22dd6723751/
total 0
drwxr-xr-x 1 root root 1372 Oct  9 08:39 bin
drwxr-xr-x 1 root root    0 Apr 10  2014 boot
drwxr-xr-x 1 root root  882 Oct  9 08:38 dev
drwxr-xr-x 1 root root 2040 Oct 12 17:27 etc
drwxr-xr-x 1 root root    0 Apr 10  2014 home
...表示結果を省略...

Btrfs でコンテナを読み書き¶

コンテナはイメージ領域を効率的に扱うスナップショットです。スナップショットの中のメタデータが示す実際のデータ・ブロックは、ストレージ・プールの中にあります。これはサブボリュームの扱いと同じです。そのため、スナップショットの読み込み性能は、サブボリュームの読み込み性能と本質的に同じです。その結果、Btrfs ドライバの使用による性能のオーバヘッドはありません。

新しいファイルをコンテナに書き込むと、コンテナのスナップショットに新しいデータブロックを割り当てる処理が、必要に応じて発生します。それから、ファイルを新しい領域に書き込みます。必要に応じて書き込む処理は Btrfs によってネイティブに書き込まれ、新しいデータをサブボリュームに書き込むのと同じです。その結果、コンテナのスナップショットに新しいファイルを書き込む処理は、ネイティブな Btrfs の速度になります。

コンテナ内にある既存のファイルを更新すると、コピー・オン・ライト処理（技術的には、書き込みのための転送、という意味です）が発生します。ドライバはオリジナルのデータをそのままに、スナップショットに新しい領域を割り当てます。更新されたデータは新しい領域に書き込みます。それから、ドライバはファイルシステムのメタデータを更新し、スナップショットが新しいデータを示すようにします。元々あったデータはサブボリュームとスナップショットのための更なるツリーの活用場所として維持されます。この動作はコピー・オン・ライトのファイルシステムがネイティブな Btrfs のものであり、非常に小さなオーバヘットとなります。

Btrfs を使うと、沢山の小さなファイルの書き込みと更新は、パフォーマンスの低下を招きます。詳細は後ほど扱います。

Btrfsの Docker 設定¶

btrfs ストレージ・ドライバは、Docker ホストで Bitrfs ファイルシステムとしてマウントされている /var/lib/docker のみを処理します。以下の手順は、 Ubuntu 14.04 LTS 上で Btrfs の設定方法を紹介します。

$ cat /proc/filesystems | grep btrfs`

$ sudo apt-get install btrfs-tools
Reading package lists... Done
Building dependency tree
<出力を省略>

$ sudo mkfs.btrfs -f /dev/xvdb
WARNING! - Btrfs v3.12 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using


Turning ON incompat feature 'extref': increased hardlink limit per file to 65536
fs created label (null) on /dev/xvdb
    nodesize 16384 leafsize 16384 sectorsize 4096 size 4.00GiB
Btrfs v3.12

$ sudo mkdir /var/lib/docker

$ sudo blkid /dev/xvdb
/dev/xvdb: UUID="a0ed851e-158b-4120-8416-c9b072c8cf47" UUID_SUB="c3927a64-4454-4eef-95c2-a7d44ac0cf27" TYPE="btrfs"

/dev/xvdb /var/lib/docker btrfs defaults 0 0
UUID="a0ed851e-158b-4120-8416-c9b072c8cf47" /var/lib/docker btrfs defaults 0 0

$ sudo mount -a
$ mount
/dev/xvda1 on / type ext4 (rw,discard)
<出力を省略>
/dev/xvdb on /var/lib/docker type btrfs (rw)

$ sudo service docker start
docker start/running, process 2315

$ sudo docker info
Containers: 0
Images: 0
Storage Driver: btrfs
[...]

Btrfs と Docker 性能¶

btrfs ストレージ・ドライバ配下では、Docker の性能に影響を与える様々な要素があります。

• ページ・キャシュ ：btrrfs はページ・キャッシュ共有をサポートしていません。つまり、ｎ個のコンテナがキャッシュするために、ｎ個のコピーを必要とします。そのため、 btrfs ドライバは 、PaaS や、その他にも密度を求められる用途には適していません。

• 小さな書き込み ：コンテナに対する沢山の小さな書き込み（Docker ホストが多くのコンテナを起動・停止している場合）は、Btrfs の塊（chunk）を粗く消費します。これにより、停止するまで Docker ホスト上で多くの容量を消費します。これが現時点の Btrfs バージョンにおける主な障害です。

もし btrfs ストレージ・ドライバを使うのであれば、 btrfs filesystem show コマンドで Btrfs ファイルシステム上の空き容量を頻繁に監視してください。 df のような通常の Unix コマンドを信頼しないでください。つまり、常に Btrfs のネイティブ・コマンドを使ってください。

• シーケンシャルな書き込み ：Btrfs はジャーナリングの技術を使ってデータをディスクに書き込みます。この影響により、シーケンシャル書き込みでは、性能が半減します。

• 断片化 ：断片化（fragmentation）とは、Btrfs のようなフィルシステム上でコピー・オン・ライトを行うと生じる自然な副産物です。たくさんの小さなランダムな書き込みが、断片化を引き起こします。SSD メディアを使う Docker ホスト上では CPU のスパイク（突発的な利用）が顕著ですし、回転メディア（HDD）で Docker ホストを動かす場合も、メディアをむち打つものです。いずれの場合も、パフォーマンスに影響の低下を招きます。

Btrfs の最近のバージョンは、 autodefrag をマウント用のオプションに指定できます。このモードによって、断片化せずにランダムに書き込みをします。ただ、Docker ホスト上でこのオプションwの有効化する前に、自分自身で性能評価をすべきです。いくつかのテストは Docker ホスト上に多数の小さなファイルをさくせいしますので、良くない性能に影響与える場合があります（あるいは、システムで沢山のコンテナを停止・起動した場合も）。

• SSD（ソリッド・ステート・ドライブ） ：Btrfs は SSD メディアをネイティブに最適化します。最適化を有効化するには、マウントオプションで -o ssh を指定します。これらの最適化は SSD メディアを使わないというシークの最適化を行いますので、 SSD の性能を拡張します。

また、Btrfs は TRIM/Discard プリミティブもサポートします。しかし、 -o discard マウント・オプションでマウントすると、性能の問題を引き起こします。そのため、このオプションを使う前に、自分自身で性能評価をすることを推奨します。

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

関連情報¶

• イメージ、コンテナ、ストレージ・ドライバの理解
• ストレージ・ドライバの選択
• AUFS ストレージ・ドライバを使う
• Device Mapper ストレージ・ドライバを使う