前々回、
今回も引き続きLXCがサポートするストレージバックエンドの紹介をします。今回はLVMをストレージバックエンドとして使った場合のLXCの使い方を紹介します。
前回同様、
実は執筆時点でのLXCのstableリリースの最新である1.
$ sudo add-apt-repository ppa:ubuntu-lxc/daily-stable-1.0 $ sudo apt-get update $ sudo apt-get install lxc $ dpkg-query -s lxc | grep Version Version: 1.0.7+stable~20150225-0206-0ubuntu1~trusty
1.
不具合については後で紹介します。
LXCでLVMをストレージバックエンドとして指定する場合、
- ボリュームグループ上に直接論理ボリュームを作成
- Thin Provisioning用のプール上に論理ボリュームを作成
Thin Provisioning機能はLinux 3.
以下ではまずはThin Provisioning機能を使わない方法を紹介したあと、
LVMをストレージバックエンドとして使う場合の準備
LVMをLXCのストレージバックエンドとして使う場合の特別な準備はありません。普通にLVMを操作するコマンド群があれば使えます。ここでは以降の実行例で使う環境で行った準備を紹介しておきます。
LVMを操作するコマンドはUbuntuでは"lvm2"というパッケージですので、
$ sudo apt-get install lvm2 thin-provisioning-tools
まずはLVM用に設定したパーティションが必要ですね。ここの例では/dev/
をLVM用に作成しています。
$ sudo fdisk -l /dev/vdb Disk /dev/vdb: 8589 MB, 8589934592 bytes 2 heads, 1 sectors/track, 8388608 cylinders, total 16777216 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x8ee21092 Device Boot Start End Blocks Id System /dev/vdb1 2048 16777215 8387584 8e Linux LVM
/dev/
を物理ボリュームとして設定します。
$ sudo pvcreate /dev/vdb1 Physical volume "/dev/vdb1" successfully created
LXCではデフォルトではlxc
という名前のボリュームグループを使います。このボリュームグループ名はlxc-create
コマンド実行時のオプション、/etc/
)
ここではデフォルトで使われる名前を設定しました。
$ sudo vgcreate lxc /dev/vdb1 Volume group "lxc" successfully created
これで準備ができました。
$ sudo pvs (物理ボリュームの確認) PV VG Fmt Attr PSize PFree /dev/vdb1 lxc lvm2 a-- 8.00g 8.00g $ sudo vgs (ボリュームグループの確認) VG #PV #LV #SN Attr VSize VFree lxc 1 0 0 wz--n- 8.00g 8.00g
LVMを使ったコンテナ用のシステム設定と作成時のオプション
LXCのシステム設定でストレージバックエンドとしてLVMを使う際の設定を行えます。これはコンテナ作成時のデフォルト値として使われます。この設定項目が設定されていない場合は表1に示したデフォルト値が使われます。
設定項目 | 設定項目の説明 | デフォルト値 |
---|---|---|
lxc. |
デフォルトのLVMボリュームグループ名 | lxc |
lxc. |
デフォルトのThin Provisioning用プール名 | lxc |
デフォルトではLXCのLVMストレージバックエンドは、lxc.
で設定した値の名前を持つThin Provisioning用のプールが存在する場合には自動的にそのプールに論理ボリュームを作成します。Thin Provisioning用のプールがない場合はlxc.
で設定した値の名前を持つボリュームグループに論理ボリュームを作成します。
表1の設定項目を含め、lxc-create
コマンドに-B lvm
を指定してLVMをストレージバックエンドとして使う場合に指定できるオプションがありますので紹介しておきましょう。指定しなければデフォルト値が使われます。
オプション | オプションの説明 | デフォルト値 |
---|---|---|
--lvname | コンテナ用に使う論理ボリューム名 | コンテナ名 |
--vgname | コンテナ用に使うボリュームグループ名 | lxc. |
--thinpool | Thin Provisioning用のプール名の指定 | lxc. |
--fstype | 論理ボリューム上に作成するファイルシステム名 | ext3 |
--fssize | 作成するファイルシステムのサイズ | 1G |
デフォルト値以外の名前を持つThin Provisioning用プールを使いたい場合は--thinpool
オプションでプール名を指定します。
デフォルト値以外のボリュームグループを使いたい場合は、--vgname
オプションでボリュームグループ名を指定します。Thin Provisioning機能を使う場合でも使用するボリュームグループ名はlxc-create
コマンドが使う値lxc.
の値もしくは--vgname
の設定値)
特に指定しなければ論理ボリューム名はコンテナ名となります。コンテナ名以外の論理ボリュームを使いたい場合は--lvname
で指定します。
あらかじめOS上で作成しておくファイルシステムと違って、
コンテナ作成の際にいろいろなファイルシステムを指定できますので、
LVMを使ったコンテナの作成
まずはボリュームグループ上に直接論理ボリュームを作成するようにコンテナを作成してみましょう。
ここでは論理ボリューム上に2GBのext4ファイルシステムを作成する指定を行ってコンテナを作成してみます。
$ sudo lxc-create -n lvm01 -t download -B lvm --fstype ext4 --fssize 2G \ > -- -d ubuntu -r trusty -a amd64 :(略) Logical volume "lvm01" created :(略) You just created an Ubuntu container (release=trusty, arch=amd64, variant=default) :(略) $ sudo lxc-ls -f NAME STATE IPV4 IPV6 AUTOSTART ------------------------------------- lvm01 STOPPED - - NO
作成が成功しましたね。論理ボリュームの状態を確認してみましょう。
$ sudo lvs LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert lvm01 lxc -wi-a---- 2.00g
以上のようにコンテナ名で論理ボリュームが作成され、
コンテナのディレクトリがどうなっているのか確認してみましょう。
$ sudo ls -F /var/lib/lxc/lvm01 config rootfs/ $ sudo ls -F /var/lib/lxc/lvm01/rootfs $
設定ファイルとrootfs
ディレクトリが存在しており、rootfs
以下は空です。
設定ファイルを確認してみるとlxc.
が論理ボリューム名になっています。それ以外は普通のコンテナと変わりありません。
$ sudo cat /var/lib/lxc/lvm01/config | grep -v "^#" lxc.include = /usr/share/lxc/config/ubuntu.common.conf lxc.arch = x86_64 lxc.rootfs = /dev/lxc/lvm01 lxc.utsname = lvm01 lxc.network.type = veth lxc.network.flags = up lxc.network.link = lxcbr0 lxc.network.hwaddr = 00:16:3e:02:fb:36
ではコンテナを起動してみましょう。
$ sudo lxc-start -n lvm01 -d $ sudo lxc-ls -f NAME STATE IPV4 IPV6 AUTOSTART ------------------------------------------- lvm01 RUNNING 10.0.3.231 - NO
起動しましたのでlxc-attach
コマンドを使ってコンテナ内でマウントの状況を確認するコマンドを実行してみます。
$ sudo lxc-attach -n lvm01 -- cat /proc/mounts | grep lvm01 /dev/lxc/lvm01 / ext4 rw,relatime,data=ordered 0 0 $ sudo lxc-attach -n lvm01 -- df -h / Filesystem Size Used Avail Use% Mounted on /dev/lxc/lvm01 2.0G 383M 1.5G 21% /
/
/dev/
がext4でマウントされており、
このマウントはコンテナのマウント名前空間内で行われていますので、
$ sudo ls -F /var/lib/lxc/lvm01/rootfs (ホストOS上で実行) $ grep lvm01 /proc/mounts (ホストのマウント名前空間からはマウントされていることは見えない)
LVMを使ったコンテナのクローン
それでは引き続いてLVMをストレージバックエンドに使っているコンテナのクローンを試しましょう。実は先に述べたLVMを使う場合の不具合はクローン機能の部分にあります。1.
このバグは1.
今回使っているstable-1.
まずはlxc-clone
で-s
オプションを指定せずにコンテナをクローンしてみましょう。
$ sudo time -p lxc-clone -o lvm01 -n lvm02 Logical volume "lvm02" created Created container lvm02 as copy of lvm01 real 13.48 user 2.23 sys 2.33
上記の例でも表示されているように、
$ sudo lvs LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert lvm01 lxc -wi-a---- 2.00g lvm02 lxc -wi-a---- 2.00g $ sudo grep lxc.rootfs /var/lib/lxc/lvm02/config lxc.rootfs = /dev/lxc/lvm02
それでは-s
オプションを指定してスナップショットによるクローンを実行してみましょう。
$ sudo time -p lxc-clone -o lvm01 -n lvm03 -s -B lvm Logical volume "lvm03" created Created container lvm03 as snapshot of lvm01 real 1.56 user 0.00 sys 0.05 $ sudo lxc-start -n lvm01 -d $ sudo lxc-ls -f | grep lvm03 lvm01 RUNNING 10.0.3.135 - - NO $ sudo lxc-stop -n lvm01
スナップショットなのでlxc-clone
コマンドはすぐに終了しています。ここでクローン元のコンテナを起動して、
lvs
コマンドで論理ボリュームの状態を確認してみましょう。
$ sudo lvs LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert lvm01 lxc owi-a-s-- 2.00g lvm02 lxc -wi-a---- 2.00g lvm03 lxc swi-a-s-- 2.00g lvm01 0.02
lvs
コマンドで確認するとスナップショットによるクローンでできたlvm03
コンテナはLVMのスナップショット機能を使ったlvm01
のスナップショットになっていることがわかります。
また、lvm03
は少し容量が増えていますね。
もちろんlvm03
コンテナも起動できます。
$ sudo lxc-start -n lvm03 -d
$ sudo lxc-ls -f
NAME STATE IPV4 IPV6 GROUPS AUTOSTART
----------------------------------------------------
:(略)
lvm03 RUNNING 10.0.3.68 - - NO
なお、
現時点では、
LVMのスナップショット機能を使ったクローンで作成したコンテナが存在する場合でも、
$ sudo lxc-ls lvm01 lvm02 lvm03 $ sudo lxc-destroy -n lvm01 (スナップショット元のコンテナを削除) :(略) Logical volume "lvm03" successfully removed (スナップショットのボリュームが削除された) Logical volume "lvm01" successfully removed $ sudo lxc-ls lvm02 lvm03 ("lvm03"ボリュームは削除されたがコンテナは表示される)
この例でlvm01
を削除すると、lvm03
用の論理ボリュームであるlvm03
が削除されますので、
この記事を書いている最中に筆者がこの不具合を修正するパッチを送付したところパッチがAckされました。まだマージはされていませんが、
Thin Provisioning機能を使っていない場合で、
Thin Provisioning 機能の利用
Linux kernel 3.
DockerをRHELやCentOS上で使う際には、
LXCのLVMストレージバックエンドもこの機能をサポートしています。また、lxc-clone
を使ってクローンできます。
ここでは簡単にThin Provisioning機能を使ったコンテナの操作を紹介しておきます。Thin Provisioning機能そのものの詳細や、
Thin Provisioning 機能を使う場合の準備
ボリュームグループは先の例で使ったlxc
をそのまま使います。
$ sudo vgs VG #PV #LV #SN Attr VSize VFree lxc 1 0 0 wz--n- 8.00g 8.00g
Thin Provisioning用のプールをlxc
という名前で作成します。データを保存する領域の他にメタデータを保存する領域が必要です。このためボリュームグループlxc
の全部をプールとして確保するわけにはいきませんので、
$ sudo lvcreate -l 90%VG --type thin-pool --thinpool lxc lxc Rounding up size to full physical extent 8.00 MiB Logical volume "lxc" created $ sudo lvs LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert lxc lxc twi-a-tz- 7.20g 0.00
Thin Provisioning 機能を使ったコンテナの作成
ではコンテナを作成してみましょう。ここでは--thinpool lxc
と指定して明示的にThin Provisioning用のプールを指定しています。
LXCはデフォルトではlxc.
で設定した名前のThin Provisioning用のプールがある場合は、--thinpool lxc
は指定しなくても同じ結果となります。
逆にlxc.
で指定したプールがない場合に--thinpool
でプール名を指定せずに実行すると、
$ sudo lxc-create -n thin01 -B lvm --thinpool lxc \ > --fstype ext4 --fssize 8G -t download \ > -- -d ubuntu -r trusty -a amd64 :(略) Logical volume "thin01" created :(略) You just created an Ubuntu container (release=trusty, arch=amd64, variant=default) :(略) $ sudo lxc-ls thin01
作成できました。論理ボリュームの状態を見てみましょう。
$ sudo lvs LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert lxc lxc twi-a-tz- 7.20g 7.13 thin01 lxc Vwi-a-tz- 8.00g lxc 6.41
7.
$ sudo lxc-create -n thin02 -B lvm --thinpool lxc \
> --fstype ext4 --fssize 8G -t download \
> -- -d ubuntu -r trusty -a amd64
:(略)
$ sudo lxc-ls
thin01 thin02
$ sudo lvs
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
lxc lxc twi-a-tz- 7.20g 14.14
thin01 lxc Vwi-a-tz- 8.00g lxc 6.41
thin02 lxc Vwi-a-tz- 8.00g lxc 6.31
7.
Thin Provisioning 機能を使ったコンテナのクローン
lxc-clone
に-s
オプションを指定しないコピーによるクローンの場合は、-s
を指定してクローンしてみましょう。
$ sudo lxc-clone -o thin02 -n thin03 -s Logical volume "thin03" created Created container thin03 as snapshot of thin02 $ sudo lvs LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert lxc lxc twi-a-tz- 7.20g 14.15 thin01 lxc Vwi-a-tz- 8.00g lxc 6.41 thin02 lxc Vwi-a-tz- 8.00g lxc 6.31 thin03 lxc Vwi-a-tz- 8.00g lxc thin02 6.31
以上のようにthin02
コンテナのスナップショットを使ったクローンとしてthin03
コンテナが作成されました。
コンテナを2つ起動して、apt-get update
を実行してみました。
$ sudo lxc-start -n thin02 -d (スナップショット元のコンテナの起動) $ sudo lxc-start -n thin03 -d (スナップショット先のコンテナの起動) $ sudo lxc-ls -f NAME STATE IPV4 IPV6 AUTOSTART ------------------------------------------- thin01 STOPPED - - NO thin02 RUNNING 10.0.3.29 - NO thin03 RUNNING 10.0.3.68 - NO $ sudo lxc-attach -n thin02 -- apt-get update (コンテナ内でapt-get update実行) :(略) $ sudo lxc-attach -n thin03 -- apt-get update (コンテナ内でapt-get update実行) :(略) $ sudo lvs (論理ボリュームの確認) LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert lxc lxc twi-a-tz- 7.20g 18.71 thin01 lxc Vwi-a-tz- 8.00g lxc 6.36 thin02 lxc Vwi-aotz- 8.00g lxc 8.43 thin03 lxc Vwi-aotz- 8.00g lxc thin02 8.31
それぞれのコンテナで使用量が増えていますね。
先に紹介したThin Provisioning機能を使わないLVMでは、
それに対してThin Provisioning機能を使うと、
$ sudo lxc-clone -o thin03 -n thin04 -s -B lvm Logical volume "thin04" created Created container thin04 as snapshot of thin03 $ sudo lvs LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert lxc lxc twi-a-tz- 7.20g 19.02 thin01 lxc Vwi-a-tz- 8.00g lxc 6.36 thin02 lxc Vwi-a-tz- 8.00g lxc 8.50 thin03 lxc Vwi-a-tz- 8.00g lxc thin02 8.50 thin04 lxc Vwi-a-tz- 8.00g lxc thin03 8.50
コンテナの削除を試してみましょう。クローン元のコンテナから削除してみます。
$ sudo lxc-destroy -n thin02 (クローン元のコンテナの削除) :(略) Logical volume "thin02" successfully removed (削除したコンテナ用のボリュームのみ削除されている) $ sudo lxc-ls thin01 thin03 thin04 $ sudo lvs LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert lxc lxc twi-a-tz- 7.20g 16.53 thin01 lxc Vwi-a-tz- 8.00g lxc 6.36 thin03 lxc Vwi-a-tz- 8.00g lxc 8.50 thin04 lxc Vwi-a-tz- 8.00g lxc thin03 8.50 (クローン先のボリュームは残っている) $ sudo lxc-destroy -n thin03 (更にクローン元のコンテナの削除) :(略) $ sudo lvs LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert lxc lxc twi-a-tz- 7.20g 16.52 thin01 lxc Vwi-a-tz- 8.00g lxc 6.36 thin04 lxc Vwi-a-tz- 8.00g lxc 8.50 (クローン先のボリュームは残っている)
Thin Provisioning機能を使った場合、
まとめ
今回はストレージバックエンドとしてLVMを使った場合のコンテナの作成、
Thin Provisioning機能を使わない場合に不具合がある点を除いても、
ストレージバックエンドとしてLVMを使う場合は、
次回もストレージバックエンドを便利に使う方法や、