AWS 的にはオンライン拡張をサポートしている、というか仕組み的に基本そうなっているので。
そんな感じ！
作業手順
以外だと思われるが、公式にわりとマトモなナレッジベースがある。
なので以下では注意する点のみ書いておく。
Nitro か Xen か
インスタンスタイプ (世代) によって仮想化の方法が異なり、作業手順も違うらしい。
最近のインスタンスはだいたい Nitro を利用しているが、 昔のインスタンスタイプだと Xen を採用している場合がある。 概ね T2 とか M3, M4 あたりが該当する。
❯ aws ec2 describe-instance-types --instance-type t2.micro --query "InstanceTypes[].Hypervisor" [ "xen" ] ❯ aws ec2 describe-instance-types --instance-type m4.large --query "InstanceTypes[].Hypervisor" [ "xen" ]
エフェメラルストレージが付いていたり VPC の区切りが存在しなかった時代、そのあたりを生きていたインスタンスが概ね対象と思えばよさそう。
スナップショットの作成をしておく
公式的には「失敗したらロールバックするよ」と書いているけど、失敗せずに拡張出来たとしてそれは EBS 的に成功しているだけで、内部のファイルシステムやファイル自体が壊れていないとは言ってない、という事らしい。 残当。
なのでスナップショットは作成しておいてね、という話だ。
基本的に作成してから作業はじめて、終わったら SSH 接続やホスティングしているサービス利用して主だったトコでエラーが出ないことを確認できれば、スナップショットは消してもいいと思う。
転ばぬ先の杖理論で。
オンライン拡張
ManagementConsole から EBS 拡大するのも、その後 SSH 接続して growfs や resizefs を実行するのも、プロセス稼働中の環境で実施して問題ない。
想定される問題としては、突然ディスクサイズが増えたので監視系アプリケーションが「何事！？」となって例外を吐くとか、プロセスが掴んでいる inode や fd がズレる (新しく採番するとき、拡張後の値におっつけない) などがありそう。
とはいえ個人的には遭遇したことないし、困ったら大正義 fsck とか実行するしかないのでそんなトコだろうか？
NVMe ストレージの指定
growpart コマンドでパーティションサイズをEBSのディスクサイズに合わせます。 growpart
を引数に指定するのですが、 には数字を指定します。 nvme0n1p1 の p1 は パーティション1 を表しているので には 1 を指定します。 p1 ではありません。紛らわしいですね。
growpart 実行時にエラー出るのでなんでだ、と思ってたらそういうことっぽかった。
sudo growpart /dev/nvme0n1 1
EBS のステータス
EBS のサイズ変更だけにフォーカスすると、ステータスは以下の3つが存在する。
- modifying
- 変更中
- optimizing
- 最適化中
- completed
- 完了済み
各種作業は EBS のステータスが optimizing 以降になってから実施する。
実際に modifying 中に EC2 に接続して lsblk などすると、タイミングによってはディスク拡張が終わっていない時があった。 optimizing になると最低限 lsblk から見えるディスク情報の反映は終わっている。
その他
過去書いたけど、 拡張する時に環境によっては失敗する場合がある。
