growpartでRHEL EC2のルートパーティションを自動拡張する

AWS運用自動化サービス「Cloud Automator」
この記事は1年以上前に書かれたものです。
内容が古い可能性がありますのでご注意ください。

こんにちは、サーバーワークス 技術1課の三井です。

EC2インスタンスの運用中に、ルートボリュームのEBSを拡張しなければならない場面、意外とあるんじゃないでしょうか。EBSの拡張方法についてGoogle先生に訪ねてみたところ、概ね以下のような手順が一般的なようでした。

  1. 対象EC2インスタンスにアタッチされているEBSボリュームのスナップショットを作成
  2. 1で作成したスナップショットを元に、大きいサイズのEBSボリュームを作成
  3. 対象EC2インスタンスから、既存EBSボリュームをデタッチ
  4. 2で作成したEBSボリュームを対象EC2インスタンスのルートボリュームとしてにアタッチ

上記の手順自体は問題ないですね。欲を言うとAWS側でEBSをよしなに拡張してくれる機能があったりするとますます我々のゆとり化に拍車が掛かるわけで最高なのですが、なかなかそうも行かないのでしょう。

さて、EBSの拡張には続きがあって、ルートボリュームを拡張したあと、OSからその領域を使うためにはパーティションの拡張・ファイルシステムの拡張が必要になるわけです。これがなかなか曲者です。

Amazon LinuxのAMIを使っているのであれば、上記手順だけで問題ありません。OSの起動時に自動的に新しいEBSのサイズに合わせてパーティションを拡張してくれます。それ以外のAMIから作成しているRHELやCentOSなどのLinuxインスタンスでは、一手間必要になるケースがあります。今回はRHEL6.5を例にして紹介します。

似たような話

少しばかり話は逸れますが、AMIによってはLaunch時にEBSサイズをいくら大きく指定してもパーティションサイズが変わらないものがあります。

上記はRHEL6.5 x86_64のAMIを用いて、ルートボリュームを12GBに変更したインスタンスを起動する例です。

上記で起動したインスタンスにログインして確認してみると、ルートパーティションは6GBしか使われていません。

ディスクデバイスとしては、指定した12GBをきちんと認識しています。

というわけで

話が逸れましたが、「OS側でEBSのサイズを認識し、パーティションを拡張する機能があるかないか」ということで、冒頭のEBSのアタッチ/デタッチの話と繋がってきます。Amazon Linuxにはその仕組みがあるけれど、RHEL6.5のAMIではそういう仕組みがなかった、ということですね。

この件については弊社ブログでも以前、EC2上のLinuxのパーティションを拡張する という記事で紹介しています。

こちらは「OS側でルートボリュームのパーティションサイズを変更できないので、別のインスタンスにEBSをアタッチしてpartedで拡張する」という比較的力技な内容となっています。

が、もう少し楽な方法があるので、ご紹介します。

cloud-init+growpartを使う

cloud-initのモジュールであるgrowpart(cloud-utils-growpart)を導入することで、OS起動時にEBSのサイズに合わせてパーティションサイズを変更できるようになります。

Amazon Linuxには標準でインストール&設定されていて、これのおかげで自動的にルートボリュームのサイズ変更に追従してくれるわけですね。Amazon Linux以外でもAMIによってはデフォルトで構成されているものもあるようです。

インストールと設定

以下はRHEL6.5での手順です。

cloud-utils-growpartはRHELリポジトリには含まれていないので、EPELから拾ってきます。

起動時にパーティションサイズを変更してくれるようにするためには、インストールだけでなくcloud-initの設定ファイルの編集も必要です。

/etc/cloud/cloud.cfgのcloud_init_modulesセクションはデフォルトでは以下のようになっています。

cloud_init_modulesセクション内に以下一行を追記します。

rebootして、どうなったか確認してみます。

パーティションは拡張されましたが、ファイルシステムの拡張は行われていません。

どれどれ、と思って試してみたらresize2fsも効きませんでした。おや。

なんだろうなあ、と思いながらここで2回目の再起動を行ったところ、今度はファイルシステムの拡張もきちんと行われていました。

めでたしめでたし。

さいごに

「めでたしめでたし、じゃねーよ!」とセルフツッコミしながらcloud-init.logを追いかけたところ、1回目の再起動でgrowpartによってパーティションの拡張が行われ、2回目の再起動後に今度はファイルシステムの拡張が行われていました。このあたりのロジックがまだ掴めておらず、ちょっとモヤモヤしますが、他のインスタンスにアタッチしてfdiskする手順と比べると2回再起動するほうが格段に楽なので、そういうものなのだと納得することにして、今回の記事を締めたいと思います。

あ、もしこのあたり詳しく知ってて教えてくれる方いたら以下URLから気兼ねなくお声掛けください!!!

クラウドを操りSIの世界を変えたいエンジニアをWanted!

AWS運用自動化サービス「Cloud Automator」