しま★りん.blog @ayurina

そこはかとない日常を綴るブログです。主にはゲーム、ガジェットレビュー、ドライブ記録です。

俺のブログサーバーのdockerのstorageをLVMベースに変更した件。

time 2016/02/22

性能改善しましたよ。dockerのストレージをloopback sparseファイルから、LVMベースにマイグレートしてみました。

ってゆっか、罠なんですよ。see /etc/sysconfig/docker-storage(※CentOS 6の場合)

# By default, Docker uses a loopback-mounted sparse file in
# /var/lib/docker.  The loopback makes it slower, and there are some
# restrictive defaults, such as 100GB max storage.

え?え?なんて?って、8.6秒バズーカ並のツッコミを入れたくなる内容がしれっと書いてあります。遅いんだよね。ははは。って。

しかも起動時に、こんなこと言ってくるし。

WARNING: You are running linux kernel version 2.6.32-431.17.1.el6.x86_64, which might be unstable running docker. Please upgrade your kernel to 3.8.0.

だったらfirewalldともっと仲良くしろよ、って言いたいんですが・・・。何この俺様感。

それは置いておいて。公式ドキュメントやネット上の幾つかの検証でも、LVMにすることでかなり速くなるっぽいことが書いてあったので、手順検証してマイグレートしてみました。普通に考えて、ストレージイメージはやっぱりブロックデバイスだよなぁ、って思うし。ちなみに、性能的にはoverlayfsやbtrfs辺りが速そうなんですが、そこまではチャレンジしていません。それこそカーネルが対応していればやってみたいかな。あとbtrfsはまだ普及期じゃないかな、とも思います。

手順は簡単。

  • docker exportで必要なコンテナのイメージを取得
  • LVM領域を作成
  • dockerを再起動して、空のLVMストレージデバイスをつかませる
  • docker importでコンテナのイメージを読み込み
  • docker runでコンテナ起動

ついでに、今回、dockerホストの再起動等でもサービスが自動的に起動してくるように、restartポリシーを付けてdocker runしています。これが正しいサービスの永続化手法なのかどうか分かりませんが、systemdやrcからコンテナを起こすのは「美しくない」と思いましたし。libvertのautostartも、一応「起こしてくれることは起こしてくれる」レベルなので、まぁそこはそんなもんでしょう、と。

まずはexportで必要なコンテナのイメージをエクスポートします。大事なこと。exportの対象はcontainerで、importされる先はimageです。なので、exportするために、commitする必要はありません。

docker export php-fpm.home | gzip > centos7_php7-fpm.tgz

これで、tar(gz)アーカイブにイメージのツリーが保存されます。ただのtarアーカイブです。必要なコンテナについて、これを繰り返して、当方では5個のイメージを収集しました。

dockerストレージ領域は–thinオプション(-T)を付けて作ります。今回は軽く24GBです。

lvcreate -L24G -T -n dockerdata vg_disk1

そうすると、こんな感じでThinpoolが出来ます。

[root@~]# lvs
  LV         VG             Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  dockerdata vg_disk1       twi-a-tz-- 24.00g             0.00   0.54
  lv_disk1   vg_disk1       -wi-ao---- 64.00g

そしたら、dockerサービスを徐ろに停止します。

/etc/init.d/service stop

ここからサービス断です。dockerの設定を変更します。

ここでまた罠というか、なんというか・・・。CentOS 6だと、ストレージオプションの指定は/etc/sysconfig/dockerです。docker-storageってファイルがあるんですが、これをどこからも参照していません(私がfind/grepした限り)。docker-storageのDOCKER_STORAGE_OPTIONSが効きそうなところですが、効かないので、/ets/sysconfig/dockerのother_argsでstorage optionを追加します。

【2016/6/1追記】このファイルはdocker-storage-setupスクリプトが使っているか作っているかしています。CentOS7ではこれが使えた記憶が・・・。

other_args="--storage-driver=devicemapper --storage-opt dm.thinpooldev=vg_disk1-dockerdata"

ちなみに、私が一瞬、ハマったポイントとしては、この「storage-driver」の指定をしないと、「dm.thinpooldevなんて知るか」と言われて、もしやdockerのバージョンが低くてthinpoolに対応していない!?と焦ることになります(焦りました)。いや、loopback sparseでもstorage driverは「devicemapper」なので、デフォルトで通るよね、と思うと、通りません。ちゃんと指定しましょう。

続いて/var/lib/dockerを移動なり削除するなりして、空ディレクトリにします。

その後、普通に起動すると、もうストレージ切り替わってます。

/etc/init.d/docker start

変わったかどうかは、docker infoで分かります。変更前。

Containers: 5
Images: 66
Storage Driver: devicemapper
 Pool Name: docker-253:2-852770-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 15.23 GB
 Data Space Total: 107.4 GB
 Data Space Available: 43.28 GB
 Metadata Space Used: 13.57 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.134 GB
...

変更後はこうなる。

Containers: 0
Images: 0
Storage Driver: devicemapper
 Pool Name: vg_disk1-dockerdata
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file:
 Metadata file:
 Data Space Used: 305.7 MB
 Data Space Total: 25.77 GB
 Data Space Available: 25.46 GB
 Metadata Space Used: 282.6 kB
 Metadata Space Total: 25.17 MB
 Metadata Space Available: 24.88 MB
...

ここまでくればあとはイメージを戻してコンテナ起動するだけです。

gunzip -c centos7_php7-fpm.tgz | docker import - centos7/php7-fpm
docker run -d -h php-fpm.home --name php-fpm.home -v /share/www/html:/var/www/html -v /share/php-fpm.home/var/log:/var/log -v /share/socks:/socks --link mariadb.home:mariadb.home --restart=on-failure:5 centos7/php7-fpm /usr/sbin/php-fpm --nodaemonize

一応、linkの指定等している場合は起動順があります。一応。restartポリシーはここで指定します。こうすることで、例えば、dockerサービス停止、起動した場合に、もともと起動していたコンテナは異常終了状態になるため、自動的に起動してきます。dockerのバージョンが新しいと、また別のポリシーもあるようですが(–restart=unless-stopped辺り)、これで再起動はしてくれるので、まずはこれで様子を見るかな、と。

無事、LVSが消費されているのが分かります。

  LV         VG             Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  dockerdata vg_disk1       twi-aotz-- 24.00g             16.41  10.48
  lv_disk1   vg_disk1       -wi-ao---- 64.00g

lsblkでもブロックデバイスのアサイン状況が見れます。

さて、これでどれくらい速くなったか、ですが、まだ実感はしていないところです。ただ、loopbackデバイスを使っていると、ちょっとファイル操作しただけでもdockerコンテナが「固まる」感覚があったのが低減されているように感じます。あくまで、主観的に。これは別に確認しようかな、と思っています。

まずは、懸念だったloopbackデバイスを脱却できて良かったです。やっぱりファイルシステムはブロックデバイス、だよねぇ、と。

sponsored link

down

コメントする




このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください



sponsored link

アーカイブ