EC2にてDisk枯渇が発生した場合に何が 起きるのかと対応方法 ハンズラボ株式会社ハンズ事業部CRMグループSREチーム 中川皓紘 2023年01月17日 ハンズラボ株式会社 1

自己紹介 2 名前：中川皓紘（Nakagawa Akihiro） 経歴：2020/12 ~ ハンズラボ株式会社勤務 出身地：神奈川県 Twitter：@sam_eng3336 趣味：カメラ, 旅行, 技術検証, 　　　最近リモワで太ったのでダイエット中 etc… ※写真はイメージです

早速本題へ！ 3 皆様はDiskの管理や監視をしていますか！？

障害対応フロー（起動できる場合） 4 EC2へ接続できる場合 ・SSHで接続 ・SystemsManagerで接続 ・シリアルコンソールで接続 EC2へ接続できない場合 ・再起動 ・ユーザーデータによる対応 ・起動できないパターン時の対応など Tips EBSの残容量を増やす方法に拡張という 選択肢があるがAL2の場合コマンドで パーティションを変更する必要があるので こういった場合には使いにくい

障害対応フロー（起動できない場合） 5 Step1 ・起動確認 ・CloudWatchのメトリックス等確認 ・Disk監視等あれば状況確認 Step2 ・障害中EC2インスタンスの停止 ・EBSのデタッチ ・復旧用EC2インスタンスにアタッチ ・復旧作業 Step3 ・復旧させたEBS Aを元のEC2へア　 　タッチし直す ・起動テスト

6 一番汎用的に対応できそうなこのパタ ーンを検証してみた

EC2インスタンスを使って検証 7 これによりDisk枯渇状態を再現できた！ ・現在のDisk残容量を確認 　・約6.5GBの残容量がある ・残容量不足を再現するために 6.6GBのファイルを作成する ・No space left no deviceの警告が出ている ・Disk残容量0%状態になっていることを確認

障害を意図的に起こす 8 Disk枯渇状態から再起動実施 Diskが足りずOSが起動できない or ミドルウェアが立ち上がらない ・起動不可 ・起動はできるがセッションマネージャで接続できない

復旧手順（AWSコンソール上での作業） 9 Step1 障害を起こしたEC2インスタンスからEBSをデタッチ ※EC2は予め停止しておく Step2 復旧用EC2インスタンスに先程デタッチした EBSをアタッ チする Step3 復旧用EC2インスタンスを起動する

復旧手順（EC2内部での作業） 10 dfコマンドにてDisk状態を確認 ↓ 新規でアタッチしたEBSはマウントされない ・「sdf1」でアタッチしたが、インスタンス内部では「xvdf1」でアタッチされている ・そのまま「/dev/xvdf1」を「/mnt/ebs」にマウントを実施 ↓ ・エラーが発生してマウントできない

復旧手順（EC2内部での作業） 11 ・「/var/log/messages」にてエラー原因を確認 ・DiskのUUIDが重複しマウント不可になっている 「blkid」でDiskのUUIDを確認すると競合してることが確認できる

復旧手順（EC2内部での作業） 12 「mount」コマンドのオプション「 -o nouuid」を設定 ※今回は一時的なマウントなので UUIDの競合を無視

復旧手順（EC2内部での作業） 13 ・「du」コマンドで先程マウントした「 /mnt/ebs/*」内部のDiskを精査 ・今回作成したダミーファイルを確認 ・削除後Disk残容量を確認 Disk残容量が危険域から脱したので元の EBSへ再アタッチを実施する

復旧手順（EC2内部での作業） 14 ・復旧用EC2の「停止」を実行 ・復旧用EC2から対象のEBSをデタッチし元のEC2へアタッチ ・障害を起こしていたEC2を起動 ・EC2内部へ接続しDisk残容量を再度確認する

復旧手順（EC2内部での作業） 15 ・「du」コマンドで先程マウントした「 /mnt/ebs/*」内部のDiskを精査 ・今回作成したダミーファイルを確認 ・削除後Disk残容量を確認 無事復旧！

Copyright © All rights reserved. 製作者：中川皓紘 お　わ　り