#はじめに
EC2(Windows)にアタッチされているEBSを拡張する手順を記載します。
〇OS情報
OS名：Microsoft Windows Server 2016 Datacenter
〇EC2インスタンス情報
インスタンスタイプ：r4.4xlarge
拡張するEBS：Cold HDD(sc1) 1.5TBの拡張 (Dドライブ)
Cold HDD(sc1) 1.5TBの拡張 (Eドライブ)
#作業手順
##事前作業
・ボリューム拡張対象のEC2インスタンスの停止 ※オンライン拡張も可能だが、システムバックアップ取得を目的としているため、今作業では停止してから拡張を行う。
・AMI取得 ※必須ではないがロールバックしたい場合に必要。
##本作業
###1.AWSマネジメントコンソール上でボリューム変更
まずは、AWSマネジメントコンソールにログインし、サービス一覧から[EC2]→[インスタンス]の順で移動します。
移動したら、インスタンス一覧が表示されるので拡張対象のインスタンスを選択し、停止していることを確認します。
対象インスタンスを選択し、[ストレージ]タブから拡張対象のボリュームIDを取得します。
取得したら、ナビゲーションペインから[ボリューム]を選択し、取得したボリュームIDでフィルターをかけます。
検索結果から対象ボリュームを選択し、[アクション]→[ボリュームの変更]の順で選択します。
下記画面が表示されるので、ボリュームタイプとサイズを入力し変更を押下します。
[確認画面]が表示されたら、[はい]を選択します。
サイズが変更されたこと、状態が「in-use」「in-use - optimizing(xx%)」もしくは「completed」のいずれかであることを確認します。
※optimizing状態になり数秒でディスク領域は確保されているため、optimizing状態でもファイルシステム拡張に移行しても問題がない。
一方、IOPSの変更には数分から数時間かかるため、optimizing状態の際は変更前と同程度のパフォーマンスが適用される。
参考：ボリューム変更の進行状態のモニタリング
確認がとれたら、EC2インスタンスを起動します。
[インスタンス状態]が[実行中]、[ステータスチェック]が[2/2のチェックに合格しました]となっていることを確認します。
###2.ファイルシステムの拡張
対象のインスタンスに接続します。
[スタートボタン]を右クリックしメニューから[コンピューターの管理]を選択します。
[コンピューター管理画面]が開いたら、[ディスク管理]を選択します。
[ディスク管理画面]が表示されたら左上の[操作]→[ディスクの再スキャン]を選択します。
※再スキャンを行うことで現在のディスク状況が反映されます。
拡張するディスクにカーソルを合わせ、右クリック→［ボリューム拡張］を選択します。
[ボリュームの拡張ウィザード画面]が表示されるので、[次へ]を選択します。
[ディスクの選択画面]が表示されたら、ディスク領域の値を確認し、[次へ]を選択します。
[確認画面]が表示されるので完了を選択します。
無事、ディスク領域が拡張されたことを確認します。
###3.確認
AWSマネジメントコンソールに戻り、対象ボリュームの状態が[in-use]になっていること確認します。
※in-useになるまで時間がかかります。
今回、1.5TBの変更で約1時間半かかりました。
#備忘録
同様手順で約3.7TBのEBS拡張を行いました。
拡張開始から7時間経過してもEBSの状態は[in-use - optimizing(67%)]で[in-use]になるまでかなりの時間を要しました。
※AWS公式では、完全に使用された1TBのボリュームの移行時間は約6時間、最大で24時間かかる場合もあるとのことでした。
(個人メモ)
EBSの増強にかかる時間は単純にボリュームサイズだけでは見積もることができないと学びました。
厳密に作業時間を見積もる必要がある場合は該当サーバのAMIからリストアして、検証する必要があると考える。
また、本番環境と開発環境でAWSアカウントが異なり、本番環境の作業見積もりが必要であれば、本番環境から開発環境へAMIの共有を行い、検証すると良いと思われる。