RHEL6.6のAMIでEBSを使用する際の注意点

森永です。
弊社はAmazon Linuxでサーバを構築することが多いのですが、たまにRHELを使うことがあります。
RHEL6.6のAMIを使った際にハマったのでまとめておきます。

現象

RHEL6.6のAMI（ID：ami-a15666a0）からインスタンスを立ち上げてRootボリュームの容量を確認したところ、100GのEBSをマウントしているにもかかわらず6Gほどしか認識していないことが判明しました。

 
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 5.8G 1.9G 3.6G 35% /
tmpfs 1.8G 0 1.8G 0% /dev/shm

ちなみに、RHEL6.6以外のAMIではこの現象は起きませんでした。。。（RHEL6.5や7では問題なし）

原因

デフォルトのRootボリューム容量が6Gで、cloud-initで自動拡張が動いてくれないことが原因のようです。 lsblkコマンドで確認したところ、6Gの大きさでパーテーションが切られていました。

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

対処方法

パーテーションの切られ方がおかしいため、resize2fsコマンドを実行するだけでは解決できません。
gdiskを使ってパーテーションを拡張してから、ファイルシステム拡張という流れになります。

作業インスタンスへのアタッチ

そのままのインスタンスでの作業は怖すぎるので、作業用インスタンスを使用することにします。
まず、該当のRHELのインスタンスをStopし、EBSボリュームを取り外します。
この際、大量のEBSボリュームを抱えている場合、対象ボリュームを探すのに一苦労すると思いますので、インスタンス詳細画面から飛ぶことをおすすめします。

また、EBSのNameにインスタンス名などをつけておくと管理が楽です。（デタッチするとどのインスタンスにアタッチされていたかの情報がなくなるため）

EBSボリュームのStatusが「Available」になったら作業用インスタンスにアタッチします。
作業用インスタンスはAmazon Linuxの最小設定で作成すれば事足ります。
ただし、必ず作業用インスタンスはEBSボリュームと同じAZに配置するようにして下さい。（別AZだとアタッチできません。。。）

アタッチの設定はデフォルトのもので構いません。

パーテーションの拡張

この作業ではデータが破損、削除される可能性がありますので、既にボリュームを使用している場合にはSnapshotを取得しておきましょう。（新規インスタンスの場合は必要ありません。）

パーテーションの拡張をするのには、gdiskコマンドを使用します。
Amazon Linuxにはデフォルトでgdiskが入っています。（2015.03現在）

まず、拡張するボリュームを確認するために、lsblkコマンドを実行します。
今回の場合は"/dev/xvdf"が対象のボリュームとなります。

$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0    8G  0 disk
└─xvda1 202:1    0    8G  0 part /
xvdf    202:80   0  100G  0 disk
└─xvdf1 202:81   0    6G  0 part

上記手順で確認したパスを引数にgdiskコマンドを起動します。

$ sudo gdisk /dev/xvdf
GPT fdisk (gdisk) version 0.8.10

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

pコマンドを実行し、パーテーションの情報を表示します。 Disk identifier (GUID)とCodeをメモしておきます。

Command (? for help): p
Disk /dev/xvdf: 209715200 sectors, 100.0 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): C0E76C1A-B601-48A7-A1E0-CC49DEFF6CB4
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 20971486
Partitions will be aligned on 2048-sector boundaries
Total free space is 8388541 sectors (4.0 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048        12584959   6.0 GiB     EF00

空のパーテーションを作成するために、oコマンドを実行します。

Command (? for help): o
This option deletes all partitions and creates a new protective MBR.
Proceed? (Y/N): Y

nコマンドを使用して、パーテーションの設定をします。
今回はボリューム全体を一つのパーテーションとして設定するため、ほぼデフォルトで設定しました。
「Hex code or GUID」の項目については、さきほどメモしておいたCodeの値を使用します。

Command (? for help): n
Partition number (1-128, default 1):
First sector (34-209715166, default = 2048) or {+-}size{KMGTP}:
Last sector (2048-209715166, default = 209715166) or {+-}size{KMGTP}:
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): EF00
Changed type of partition to 'EFI System'

xコマンドでエキスパートコマンドモードに変更してから、gコマンドで識別子を書き換えます。 識別子はさきほどメモしておいたDisk identifier (GUID)を使用します。

Command (? for help): x

Expert command (? for help): g
Enter the disk's unique GUID ('R' to randomize): C0E76C1A-B601-48A7-A1E0-CC49DEFF6CB4
The new disk GUID is C0E76C1A-B601-48A7-A1E0-CC49DEFF6CB4

最後に、wコマンドで設定をデバイスに書き込みます。 "The operation has completed successfully."が表示されたら完了です。

Expert command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): Y
OK; writing new GUID partition table (GPT) to /dev/xvdf.
The operation has completed successfully.

パーテーションの拡張は以上ですが、e2fsckコマンドを使用してエラーがないことを確認しておきましょう。
特にエラーが出力されなければ問題ありません。

$ sudo e2fsck -f /dev/xvdf1
e2fsck 1.42.12 (29-Aug-2014)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/xvdf1: 56645/393216 files (0.1% non-contiguous), 557393/1572864 blocks

ファイルシステムの拡張

ここでようやくresize2fsコマンドを使用できます。
元のインスタンスに戻してからでも出来るのですが、どうせなら作業用インスタンスでやってしまいましょう。

$ sudo resize2fs /dev/xvdf1
resize2fs 1.42.12 (29-Aug-2014)
Resizing the filesystem on /dev/xvdf1 to 26214139 (4k) blocks.
The filesystem on /dev/xvdf1 is now 26214139 (4k) blocks long.

元インスタンスへのアタッチ

マネジメントコンソールへ戻り、作業用インスタンスからEBSボリュームをデタッチします。
デタッチしたボリュームを元のインスタンスに再度アタッチします。 この時、Rootボリュームとしてアタッチする必要が有るため、Deviceのパスは"/dev/sda1"として下さい。

最後に確認としてRHELのインスタンスでdfコマンドを実行してみます。

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       99G  2.0G   92G   3% /
tmpfs           1.8G     0  1.8G   0% /dev/shm

Great!!!
正しく100Gのボリュームとして認識されました！

まとめ

RHELは7が出たとはいえ、6が使われる機会がまだたくさんあると思います。
今回は対策としてRootボリュームのパーテーションを拡張して使用する方法をご紹介しましたが、本来であればRootボリュームを大きくせずにデータボリュームを作成して別にアタッチするという方法で対応したほうがよいでしょう。

そもそものcloud-initがおかしい訳なので、それを修正するのが筋かも。。。

参考文献

Linux パーティションを拡張する - Amazon Elastic Compute Cloud