VPSのディレクトリ整備。dockerとelasticsearchのデータディレクトリの変更

Linux

ブログを動かしているVPSのディレクトリ整理をしました。実は使ってないディスク領域があったので、これを使うようにしました。

そういえば、このブログのVPSは200GBプランなんですが、今までrootボリュームしか使っていなかったと。それで足りてたし。さすがに手狭になってきたので、ディスク整理して、elasticsearchとdockerのデータディレクトリを移動しました。

作業前はこんな感じ。77%になって、newrelicがWARNINGを言ってきた。

Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_vx-lv_root
                       18G   13G  3.8G  77% /
tmpfs                 939M     0  939M   0% /dev/shm
/dev/vda1             477M  124M  329M  28% /boot

これはVPSのデフォルト設定のままで、LVMにはなっていますが、varもhomeも分かれていません。LVMの中はSWAPとこのrootボリュームだけです。じゃあ200GBの拡張領域はどこにあるかと言いますと、vdbにあります。

% cat /proc/partitions
...
252       16  188743680 vdb
...

これです。ここにパーティションを切って使います。

まずはfdiskでパーティションを切ります。開始を2048にするのは一種のおまじないです。嘘です。vdaのパーティションテーブルを見ると開始が2048になっており、もしやパーティションフラグメントを踏むかな、と思い踏襲しています。これは自宅サーバーでも散々ハマったポイントですので。

# fdisk /dev/vdb

コマンド (m でヘルプ): u
セクタ数 の表示/項目ユニットを変更します

コマンド (m でヘルプ): p

ディスク /dev/vdb: 193.3 GB, 193273528320 バイト
ヘッド 16, セクタ 63, シリンダ 374491, 合計 377487360 セクタ
Units = セクタ数 of 1 * 512 = 512 バイト
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O size (minimum/optimal): 512 bytes / 512 bytes
ディスク識別子: 0x5d03e176

デバイス ブート      始点        終点     ブロック   Id  システム
/dev/vdb1            2048   377487359   188742656   8e  Linux LVM

コマンド (m でヘルプ):

結果だけですが、こんな感じにします。

そのまま使っても良いのですが、あとでいろいろ分けたくなるかな、とも思い、LVMでVGを作成します。とりあえず64GB割り当て。

# pvcreate /dev/vdb1
# vgcreate vg_disk1 /dev/vdb1
# lvcreate -L 64G -n lv_disk1 vg_disk1
# lvdisplay
  --- Logical volume ---
  LV Path                /dev/vg_disk1/lv_disk1
  LV Name                lv_disk1
  VG Name                vg_disk1
  LV UUID                PTPPgE-qLEI-vE8p-Un2u-UvRY-uJFV-D2Icl1
  LV Write Access        read/write
  LV Creation host, time XXXXXXXXX.myvps.jp, 2015-07-04 21:10:28 +0900
  LV Status              available
  # open                 0
  LV Size                64.00 GiB
  Current LE             16384
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:4

これで64GBのLVができました。

あとはファイルシステムを作ってマウントすれば使えます。inode ratioは、ちょっと考えて64kにしました。おそらく足りなくなることは無いはず、と。ext4はジャーナリングFSなので、定期チェックは無効にします。これは起動時間の安定化（高速化）にもなります。

# mkfs.ext4 -i 65536 -j -m 0 /dev/mapper/vg_disk1-lv_disk1
# tune2fs -i 0 -c 0 /dev/mapper/vg_disk1-lv_disk1

これでマウントできる準備はできました。fstabはUUIDで指定して、/disk1にマウントしておきます。

まずはelasticsearchのデータ移動から。データの移動は、bindマウントで見た目を変えずに実施します。bindマウントとは、既存フォルダツリーに別ツリーをマウントする方法で、こうすることで、プログラムや設定の変更無しに別ボリュームにデータを配置したりすることがあります。メリットは、見た目の変更が無いこと、デメリットはぱっと見で容量が分かりづらいこと。実はあまり受けが良くないこともあるんですが、個人的には好んで使っています。

elasticsearchのデータ領域は/var/lib/elasticsearchです。これをそのままコピーして移動します。ディレクトリのパーミッション等が狂わないよう注意です。elasticsearchのサービスを停止した状態で、移動してマウントしなおします。

# ls -ld /var/lib/elasticsearch
drwxr-xr-x 3 elasticsearch elasticsearch 4096 11月 17 17:09 2014 /var/lib/elasticsearch
# mkdir -p /disk1/var/lib/
# rsync -av /var/lib/elasticsearch /disk1/var/lib

# cd /var/lib/
# mv elasticsearch/ elasticsearch.orig
# chmod -x elasticsearch.orig/
# mkdir elasticsearch
# chown elasticsearch:elasticsearch elasticsearch
# ls -ld elasticsearch*
drwxr-xr-x 2 elasticsearch elasticsearch 4096  7月  4 21:21 2015 elasticsearch
drw-r--r-- 3 elasticsearch elasticsearch 4096 11月 17 17:09 2014 elasticsearch.orig

# echo "/disk1/var/lib/elasticsearch /var/lib/elasticsearch none bind 0 0" >> /etc/fstab

# mount /var/lib/elasticsearch

# df -a
...
/disk1/var/lib/elasticsearch
                      66711292  1098044  65613248   2% /var/lib/elasticsearch
...

これでOK。elasticsearchは新しいディレクトリで元気に動き出しました。

続いてdockerです。同じ手順で行こうと思いましたが、rsyncで失敗しました。

# rsync -av /var/lib/docker /disk1/var/lib

docker/devicemapper/devicemapper/data
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
rsync: write failed on "/disk1/var/lib/docker/devicemapper/devicemapper/data": No space left on device (28)
rsync error: error in file IO (code 11) at receiver.c(301) [receiver=3.0.6]
rsync: connection unexpectedly closed (218 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(600) [sender=3.0.6]

どうにも、このdataファイルのコピーでサイズを間違える？ようで、ファイルシステムフルまでデータを書き続けてしまいます。どうしたものかとググったら、同じように移動している例があったので、これを参考にrsyncのオプションを調整したらうまくいきました。どうにもこのファイル、普通のファイルでは無いようです。また、カーネルも掴んでいる可能性があったので、最終的にはsingle userで実施しました。

# rsync --progress -aXS /var/lib/docker /disk1/var/lib

これでdockerも移動完了。無事動き出しました。

念のため、元ディレクトリのファイルが移動後更新されていないことをfindで確認しておきます。何も更新されていなければ問題ありません。

# find /var/lib/elasticsearch.orig -mmin -10
# find /var/lib/docker.orig -mmin -10

結果、ディスクがすっきりしました。

# df -ah
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_vx-lv_root
                       18G  2.9G   14G  18% /
proc                     0     0     0    - /proc
sysfs                    0     0     0    - /sys
devpts                   0     0     0    - /dev/pts
tmpfs                 939M     0  939M   0% /dev/shm
/dev/vda1             477M  124M  329M  28% /boot
/dev/mapper/vg_disk1-lv_disk1
                       64G   19G   45G  30% /disk1
/disk1/var/lib/elasticsearch
                       64G   19G   45G  30% /var/lib/elasticsearch
/disk1/var/lib/docker
                       64G   19G   45G  30% /var/lib/docker
none                     0     0     0    - /proc/sys/fs/binfmt_misc

次はWordpressの自動バックアップとか仕込みたいと思います。

スポンサーリンク

コメント

タイトルとURLをコピーしました