# はじめに
初投稿です！
最初の投稿何にしようか悩みましたが、直近中島が対応した事案から一つ。
(一般的にこのような対応に迫られることはあまりないでしょうが、案件によっては可能性もありますのでいつか誰かの役に立ちますように。。）
※本記事はAmazonLinux1/CentOS系での作業実績を元に記載しています。
# 概要
* 案件で使用しているサーバのインスタンスタイプは旧世代
* 旧世代のインスタンスタイプは(おそらく)AWS側で割り当て台数を減らされていて、AWSメンテナンスによる再起動や開発環境の夜間停止プロセスの起動、ASGによる自動スケールインの際にinsufficient capacityエラーによる起動失敗が度々発生
* そこでインスタンスタイプの新世代以降を検討するが、現行サーバの仮想化方式が **paravirtual (準仮想化方式)** であった。新世代のインスタンスタイプは **HVM (完全仮想化方式)** のみをサポートしておりそのままでは変更できないことが判明
* EC2にアタッチされているボリュームをHVMに対応できるボリュームに変換(コピー&boot領域のセッティング)を実施し、新たにAMI作成の上新世代インスタンスタイプでのサーバ再構成を実施する

![変更不可画面](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/f457247e-963c-40f9-a470-e87308822908.webp)

**insufficient capacity**
アベイラリティゾーンにおけるAWS側物理ホストにおける、対象インスタンスタイプのキャパシティ不足。
例えば、ある大企業が大規模な分散処理などによって１アベイラリティゾーンで大量のインスタンスを同タイプで起動していた際などに発生。
※大本を辿れば物理的なホスト上でリソースが稼働するわけで、不足の発生は防げません。

一般的な対象方法としては
* 間隔を開けて起動を再実施

&emsp;リソース状況は当然ながらリアルタイム変動のため、タイミングが合えば普通に立ち上がります
&emsp;(運用者が手作業で実施している場合は問題ないのですが、自動起動などにおいてはちと難あり）

* オンデマンドキャパシティ予約

&emsp;物理ホスト上に設定した容量をあらかじめ確保
&emsp;(その範囲内であれば上記エラーに遭遇しなくなる、が別途コストが必要)
[Insufficient instance capacity](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html#troubleshooting-launch-capacity)

# 前提
## インスタンスタイプについて
基本的にはどのインスタンスファミリーにおいても世代が最新化されるにつれて、性能・費用対効果は向上する。しかしながら世代間の互換性が完全に担保されているわけはないため仕様変更によって単純に変更できないこともある。
[インスタンスタイプ](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/instance-types.html)


## 仮想化方式について
PV (paravirtual、準仮想化方式)/HVM (完全仮想化方式)の２種存在。
従来は性能面からしてもPV方式が主流であったが、HVMの進化に伴い性能面でも優位性が逆転し現在の主流はHVMとなっている。
例えば、汎用タイプのインスタンスであれば第四世代以降はHVMのみしかサポートしていない。
[Linux AMI 仮想化タイプ](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/virtualization_types.html)
# PV→HVMへの変換手順
## 作業概要
1.対象のPVインスタンスよりボリューム複製
2.移行先のボリューム作成
3.作業用インスタンス(AL1)を用意、①②のボリュームをアタッチ
4.ボリューム間コピーを実施
5.移行先ボリュームでのboot領域設定
6.AMI作成の上新世代タイプでのインスタンス起動確認
## 移行元ボリュームの複製
1.AMC上で移行元ボリュームのスナップショット詳細画面へ遷移
　※スナップショットが存在しない場合はサーバを停止しAMIを取得
2.スナップショットよりボリュームを作成(サイズは元と同じ）
　※この際タグで判別のつきやすい名称を用意すること推奨

2.SS
※作成
![スナップショット詳細画面](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/cef6e7dd-cd7c-4d34-b60e-ac898edcc2ad.webp)
※タグ設定
![タグ設定](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/a2ca2dc2-2682-4f94-9455-5f57331d1d9e.webp)

## 移行先ボリュームの新規作成
1.「EC2」→「ボリューム」より新規にボリュームを作成
　※サイズ/タイプ/AZに関しては移行元同等に
　※こちらもタグで判別のつきやすい名称を用意すること推奨

1.SS
※作成
![ボリューム作成画面](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/f0934c69-ba95-4b36-b864-28a2413c2e76.webp)
※タグ設定
![タグ設定](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/477c1de7-91d5-42c2-989c-0d6f8e282566.webp)
## 作業用インスタンスの用意
1.EC2コンソールより、AMI( **ami-0b7620baf68f72866** /AL1)を指定してインスタンスを起動
　※ボリュームを作成したAZで起動すること
2.「EC2」→「ボリューム」より先ほど作成したボリューム選択肢し、右上アクションから下記デバイス名指定で作成したインスタンスにアタッチ
|ボリューム|デバイス名|
|---|---|
|移行元|/dev/xvdm|
|移行先|/dev/xvdo|

2.SS
※アタッチ遷移画面
![アタッチ遷移画面](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/253d9e32-568d-4bbc-8334-34a33ce28fd8.webp)
※アタッチ設定画面
![アタッチ設定画面](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/f300f457-4d87-45f0-a4e7-95372d04f2d4.webp)
※アタッチ確認
![アタッチ確認](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/3437828e-4c41-46c5-9808-41ffe8ad2117.webp)
## ボリューム間コピー
1.作業用インスタンスへSSH、rootユーザへ移動
```
sudo su
```
2.移行先ボリュームについてパーティションを作成
```
#必要PKGのインストール
yum -y install parted resize2fs
#パーティション作成
parted /dev/xvdo --script 'mklabe msdos mkpart primary 1M -1s print quit'
partprobe /dev/xvdo
udevadm settle
```
3.移行元ボリュームの検査・リサイズ(最適化）
　※リサイズ結果出力よりブロックサイズ/ブロック数を控えておく(次手順で使用)
```
#検査
e2fsck -f /dev/xvdm
#リサイズ
resize2fs -M /dev/xvdm
#リサイズ結果出力例
esize2fs 1.43.5 (04-Aug-2017)
Resizing the filesystem on /dev/xvdm to 248935 (4k) blocks.
The filesystem on /dev/xvdm is now 248935 (4k) blocks long.
```
4.③で控えたブロックサイズ/ブロック数で下記コマンドを書き換えデータコピー実施
```
dd if=/dev/xvdm of=/dev/xvdo1 bs='控えたブロックサイズ' count='控えたブロック数'
```
5.以下のコマンドで移行元/移行先のデータサイズが一致していることを確認
```
#移行元
e2fsck -f /dev/xvdm
#移行先
e2fsck -f /dev/xvdo1
#出力例
##移行元
e2fsck -f /dev/xvdm
e2fsck 1.43.5 (04-Aug-2017)
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
/: 17204/65536 files (0.2% non-contiguous), 176807/248935 blocks
##移行先
e2fsck -f /dev/xvdo1
e2fsck 1.43.5 (04-Aug-2017)
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
/: 17204/65536 files (0.2% non-contiguous), 176807/248935 blocks
```
6.コピー後の移行先最適化
```
resize2fs -f /dev/xvdo1
```
## 移行先ボリュームでのboot領域設定
1.移行先ボリュームを/mntにマウント
```
mount /dev/xvdo1 /mnt/ && mount -o bind /dev/ /mnt/dev && mount -o bind /sys /mnt/sys && mount -o bind /proc /mnt/proc
```
2./mntにルートディレクトリを変更
```
chroot /mnt
```
3.grub導入
```
#grubの存在確認
which grub
#存在する場合再インストール
yum reinstall grub -y
#存在しない場合インストール
yum install gtub -y
#シンボリック作成
ln -s /boot/grub/menu.lst /boot/grub/grub.conf
ln -s /boot/grub/grub.conf /etc/grub.conf
#grubインストール(エラーが出たとしても仕様のため気にせず）
grub-install /dev/xvdo
#設定更新
cat <<EOF | grub --batch
device (hd0) /dev/xvdo
root (hd0,0)
setup (hd0)
EOF
#下記のように出力されえれば成功
Probing devices to guess BIOS drives. This may take a long time.
Unknown partition table signature


    GNU GRUB  version 0.97  (640K lower / 3072K upper memory)

 [ Minimal BASH-like line editing is supported.  For the first word, TAB
   lists possible command completions.  Anywhere else TAB lists the possible
   completions of a device/filename.]
grub> device (hd0) /dev/xvdo
grub> root (hd0,0)
 Filesystem type is ext2fs, partition type 0x83
grub> setup (hd0)
 Checking if "/boot/grub/stage1" exists... yes
 Checking if "/boot/grub/stage2" exists... yes
 Checking if "/boot/grub/e2fs_stage1_5" exists... yes
 Running "embed /boot/grub/e2fs_stage1_5 (hd0)"...  29 sectors are embedded.
succeeded
 Running "install /boot/grub/stage1 (hd0) (hd0)1+29 p (hd0,0)/boot/grub/stage2 /boot/grub/grub.conf"... succeeded
Done.
```
4./boot/grub/menu.lstの更新(grub.confに関してはシンボリックされているためmenu.lstを更新すればOK）
```
sed -i 's/root\ (hd0)/root (hd0,0)/g' /boot/grub/menu.lst
sed -i 's/console=hvc0/console=ttyS0/g' /boot/grub/menu.lst
#更新後のmenu.lst
#root/kernelのconsoleが下記のようになっているか確認
# created by imagebuilder
default=0
fallback=1
timeout=0
hiddenmenu

title Amazon Linux 2018.03 (4.14.275-142.503.amzn1.x86_64)
root (hd0,0)
kernel /boot/vmlinuz-4.14.275-142.503.amzn1.x86_64 root=LABEL=/ console=ttyS0 selinux=0 
initrd /boot/initramfs-4.14.275-142.503.amzn1.x86_64.img
```
4.マウント解除
```
#chrootから抜ける
exit
#マウント解除
umount /mnt
```
5.インスタンスを停止
## AMI作成
1.「EC2」→「ボリューム」より移行先ボリューム選択肢し、右上アクションからスナップショットを作成
2.「EC2」→「スナップショット」より作成したスナップショットを選択肢、右上アクションよりイメージを作成
※仮想化タイプについては「ハードウェアアシストの仮想化」を選択(その他デフォルトでOK）

2.SS
※作成遷移画面
![作成遷移画面](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/e90cd9be-7fe6-4229-95f5-0413478a783d.webp)
※詳細設定画面
![詳細設定画面](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/1ed0d118-0a0d-499b-be69-968df593d87f.webp)
## 起動確認
1.EC2コンソールより、作成したAMIを指定してインスタンス起動
※インスタンスタイプは新世代とすること
※ここではt2.microを選択
2.起動後以下を確認
* ステータスチェックの成功
* ssh可否
* コンソール上の仮想化タイプがhvmであること

2.SS
※ステータスチェックOK
![ステータスチェック](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/5ed3b7e4-d9e1-443f-adff-3d6b1a9d6aff.webp)
*コンソール上の仮想化タイプ
![仮想化タイプ](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/49da096c-6a2f-48c4-9e3e-183d8398ca38.webp)

上記成功すれば変換完了です！！

# おわりに
実際の中島作業ではyumの向き先をアーカイブにしなければならなかったり、自前でカーネル構築しなくてはならなかったりと諸々他の問題も起きていましたが、大抵の場合は上記で対応可能かと思います！
当該事象のケースに陥った場合、継続運用を考慮し通常はOSなどもアップデートし新たなサーバにリプレースしていくことがベストプラクティスかなと思います。
しかしながら案件状況によっては、サービス自体のEOLが決まっていて追加コストがとれない、エンハンス等は停止しておりドラスティックな変更は入れたくない。。。等々様々な要因からこのような対応を取らざるを得ないこともあるかと思います。

AWS公式の対応ドキュメントがすでに消されている、かつあまり記事も見受けられないことからこちらに備忘もかねて投稿させていただきました。
いつか誰かのお役に立つことを願います。

次回はより一般的なことを投稿したいと思います(笑)
ご精読ありがとうございました！！

Amazon EC2