lsblk が更新されないときに調べること

弊社のサービス クラスメソッドメンバーズ では、お客様の各種お問い合わせのサポートを行っています。お問い合わせ頂いている中からあるあるな感じの事例をご紹介したいと思います。

今回はLinux系OSのEBSのルートデバイスのボリューム拡張についてです。

おもむろにlsblk

$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 8G 0 disk
└─xvda1 202:1 0 8G 0 part /

例えば、マネジメントコンソール「ボリュームの変更」でサイズを 8G から 16GB に増やした場合・・・

通常は lsblk で disk のサイズの変化が確認でき、その後パーティションを拡張するコマンド(growpart等)、ファイルシステムを拡張するコマンド(resize2fs等) を実行する手順になるかと思います。

$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 16G 0 disk
└─xvda1 202:1 0 8G 0 part /

ところが、条件によっては以下のような事象が発生します。

事例1. growpart 実行しても part のサイズが変わらない
事例2. そもそも disk のサイズが変わらない

それぞれ疑うところと対処を書いていきます。

事例1. growpart 実行しても part のサイズが変わらない

疑うところ
  dracut-modules-growroot がインストールされている？
対処
  OS を再起動する

パーティション拡張のコマンドには以下のものがあります。
  - cloud-init の growpart
  - dracut の growroot
dracut の growroot が有効となっている場合、growpart ではなく OS 起動時に growroot によりパーティション拡張する挙動のようです。

以下は Marketplace の AMI を用いて作成した RHEL6.7 の例です。growpart と growroot 両方入っています。

$ yum list installed | grep cloud
cloud-init.x86_64 0.7.5-3.el6 installed
cloud-utils-growpart.noarch 0.27-13.el6 installed

$ yum list installed | grep dracut
dracut.noarch 004-388.el6 installed
dracut-kernel.noarch 004-388.el6 installed
dracut-modules-growroot.noarch 0.23-4.el6 installed

OS 再起動すると /var/log/boot.log に以下のようなメッセージが出力され、パーティションサイズも自動で変更されます。

growroot: CHANGED: disk=/dev/xvda partition=1: start=xxxxx old: size=xxxxx,end=xxxxx new: size=xxxxx,end=xxxxx

余談ですが、Amazon Linux 2 では cloud-init の growpart のみインストールされていますが、growpart コマンドを実行しなくても OS 再起動すると /var/log/cloud-init.log に以下のようなメッセージが出力され、パーティションサイズも自動で変更されます。これはルートデバイスボリュームのみの挙動で、他のボリュームでは growpart を手動実行する必要があります。

cc_growpart.py[INFO]: '/' resized: changed (/dev/xvda, 1) from 8587820544 to 17177755136

事例2. そもそも disk のサイズが変わらない

疑うところ
  Elastic Volume に対応していない？
  (Nitroの場合)カーネルバージョンが古い？
対処
  ボリュームをデタッチしてアタッチする または インスタンスを再起動する

Elastic Volume 対応かどうかの調べ方は、下記の記事に詳細が載っています。
Elastic Volumes サポートの初期化 (必要な場合)

describe-instances コマンドを使い、以下の2点を調べます。この両方に該当する場合は Elastic Volumes 非対応のため対処が必要です。

・2016 年 11 月 1 日以前にインスタンスを起動した
・2016 年 11 月 1 日以前にインスタンスにボリュームをアタッチした

また、上記のチェックをクリアしたとしても、Nitroでカーネルが古い場合は対処が必要です。詳細は下記の記事をご参照ください。
Linux インスタンスの Amazon EBS および NVMe

Linux カーネル 4.2 以降を使用している場合は、NVMe EBS ボリュームのボリュームサイズを変更すると、自動的にインスタンスに反映されます。古い Linux カーネルの場合は、EBS ボリュームをデタッチしてアタッチするか、インスタンスを再起動してサイズ変更を反映させる必要があります。

まとめ

事例別にご紹介しましたが、結論としてはこれにつきます。

困ったときは再起動

以上です。