Reboot せずに Linode Block Storage のサイズを増やす

# はじめに

Linode (Akamai のクラウドコンピュートサービス）の仮想マシンはシンプルな構成と価格のパッケージで提供されており、選択したパッケージにはローカルディスクが含まれています。ローカルディスクは ``root`` 含む必要なファイルシステムが構成されています。固定のサイズのローカルストレージに対して、 ブロックストレージはサイズを決めて自由にインスタンスにアタッチし、追加のディレクトリとしてマウントできるストレージです。次のページも参照してください。

https://qiita.com/isss802/items/5313c7a6da1d9ed50a38

https://qiita.com/isss802/items/a2b8cce84f4266b9bf86

本記事はインスタンスをリブートすることなく、アタッチしたブロックストレージのサイズを増やす方法についての説明です。

::: note
ローカルディスクのサイズを変更するためには、インスタンスのパッケージ変更が伴います。つまり、CPU 数、メモリ数なども同時に変更することになります。一方、外付けとなるブロックストレージは、ストレージサイズの変更ができます。
:::

::: note warn
ブロックストレージの変更は増加のみです。縮小はできません。
:::

::: note warn 
ブロックストレージはインスタンスの Backup 機能の対象ではありませんので、別途考慮が必要になります。

https://techdocs.akamai.com/cloud-computing/docs/backup-service
:::

# ブロックストレージを初期設定するフロー
ブロックストレージを利用可能にする初期設定は、一部省略していますが、大枠次のフローです。
```mermaid
---
config:
  theme: neutral;
---
flowchart TB
classDef default stroke:#333,stroke-width:4px,font-size:20pt;
  S(ストレージの作成<BR> API or UI)-->
  Attach(インスタンスにアタッチ<BR> API or UI)--> 
  Mkdir(OS上でマウントの作成)--> 
  Mount(OS上でマウント)
```

<!--
![workflow_attach.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/264188/77e30d21-e55a-df17-2e02-2dd0bbd30019.jpeg)
-->

詳細については、上記に紹介した記事を参照ください。

# ブロックストレージをリサイズするフロー
利用中のブロックストレージのサイズ変更は、次のフローにになります。
```mermaid
---
config:
  theme: neutral;
---
flowchart TB
classDef default stroke:#333,stroke-width:4px,font-size:20pt;
  S(OS上でアンマウント)-->
  Detach(インスタンスからデタッチ<BR> API or UI)
  --> Resize(ストレージをリサイズ<BR> API or UI)
  --> Attach(インスタンスにアタッチ<BR> API or UI)
  --> E2FSCK(OS上でe2fsckの実行)
  --> Resize2fs(OS上でresize2fsの実行)
  --> Mount(OS上でマウント)
```
<!--
![workflow_resize2.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/264188/26660d56-b094-9de9-4de7-49cd78d9098e.jpeg)
-->


::: note 
OS 上の ``resize2fs`` を実行する前に、インスタンスからブロック・ストレージをデタッチしないとリブートが必須になります。もし リブートが許容されるなら、デタッチする必要はありません。
:::

# ブロック・ストレージをリサイズする

ここからリサイズの手順を解説していきますが、リサイズに関するドキュメントも見ながら作業してください。

https://techdocs.akamai.com/cloud-computing/docs/resize-a-volume

このドキュメントにはリブートするフローが書かれていますが、本記事はデタッチすることでリブートを回避する方法を解説します。

必須ではないですが、筆者はクローンをして、不測の事態に備えました。2 TB (95% 利用）のクローン時間は 2 分弱でした。
<!--
```
# df -i /mnt/bs
Filesystem        Inodes   IUsed     IFree IUse% Mounted on
/dev/sdc       167772160 1855822 165916338    2% /mnt/bs
```
-->


## 初期状態 (OS)
ブロック・ストレージを OS 内でマウントした状態です。``/dev/sdc`` として見えています。
```
> df
Filesystem      1K-blocks       Used Available Use% Mounted on
tmpfs               98044        964     97080   1% /run
/dev/sda         25202692    2707536  21194276  12% /
tmpfs              490208          0    490208   0% /dev/shm
tmpfs                5120          0      5120   0% /run/lock
tmpfs               98040          4     98036   1% /run/user/0
/dev/sdc       2112657248 1903482696 101783988  95% /mnt/bs
```
```
# df -h
Filesystem      Size  Used Avail Use% Mounted on
tmpfs            96M  992K   95M   2% /run
/dev/sda         25G  3.7G   20G  16% /
tmpfs           479M     0  479M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs            96M  4.0K   96M   1% /run/user/0
/dev/sdc        2.0T  1.8T   98G  95% /mnt/bs
```

## 初期状態 (UI)
Cloud Manager の画面です。ブロック・ストレージは ``Volumes`` のメニューとなっています。``bs`` とラベル化されたストレージをこれからリサイズしていきます。
![volumes-bs.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/264188/47a89a6f-028e-2d6c-eb97-35ffb617d9c5.jpeg)


## OS 上でアンマウントする
最初に OS 上でアンマウントして、ディスクを切り離します。``/mnt/bs`` は 1.8 TB ほど利用されていたのですが、マウントポイントが外れたあとは、空となっています。

```
> umount /mnt/bs

> df /mnt/bs -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda         25G  3.7G   20G  16% /

> ls -l /mnt/bs
total 0
```
:::note warn
プロセスが対象ディレクトリ上のファイルを使用していた場合はロックされアンマウントできないため、確認の上該当プロセスを終了してください。
:::

## インスタンスからデタッチする
ブロックストレージをインスタンスからデタッチする作業は、API, CLI からもできますが、ここでは Cloud Manager の UI を使って説明します。
Volumes から ``bs`` ラベルをデタッチします（割当済みのインスタンスからを切り離します)。
![bs-edit-detach.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/264188/f34208c5-3a58-6fef-6926-cbc7d51a11fe.jpeg)
確認メッセージを注意深く読んで実行します。
![confirm-detach-bs.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/264188/57ab333b-5a3b-af72-42e1-9db2a095b5d8.jpeg)

![status-unattached.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/264188/88cb16d0-17d4-5a82-fa03-655847a6d13b.jpeg)
デタッチが終了すると、ストレージがどのインスタンスにも紐づけされていない状態となります (Unattached)。

## ブロック・ストレージをリサイズする
``Resize`` を選びます。
![bs-edit-resize.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/264188/904913eb-e95f-87cf-a513-3156d6ea5688.jpeg)

今は ``2048`` GB (2 TB) となっています。
![size-2048.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/264188/b6441505-9fd4-1ce9-a613-658947ab5a33.jpeg)

数字を ``2560`` に変更します。2.5 TB になります。
![size-2560.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/264188/a8d52cc0-3c8a-f972-3748-c58f92becf80.jpeg)

変更はすぐに完了します。数秒です。UI では Status が ``Resizing`` にしばらくなりますが、画面をリロードすると ``Active`` になります。Active になっていれば、通知が届きます。

![show-resizing.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/264188/22378423-d806-8424-c64d-81e7a26f4ed9.jpeg)

通知イベントの例です。

![notification1.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/264188/491e1baf-9068-4221-21b3-870e17a009db.jpeg)

## インスタンスに再アタッチする
ハードウェアを仮想マシンから切り離し、ストレージサイズの変更したあと、再度仮想マシンに接続するようなイメージです。
![reattach-instance.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/264188/a75a1287-ebd6-39c7-c1c6-20ceefabc1e3.jpeg)

![reattach-instance2.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/264188/1fd7690c-400e-b955-62c0-106caceb869a.jpeg)

::: note warn
ブロックストレージは一つのインスタンスにのみアタッチできます。
:::

## OS 上で e2fsck の実行
ファイルシステムのチェックを行います。デバイス名はマウントされていた場所となります。分からなければ、``Show config`` のリンクから確認してください。
```
> e2fsck -f /dev/disk/by-id/scsi-0Linode_Volume_bs
e2fsck 1.46.5 (30-Dec-2021)
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
/dev/disk/by-id/scsi-0Linode_Volume_bs: 1855822/134217728 files (0.0% non-contiguous), 484577274/536870912 blocks
```

::: note alert
``Show config`` で 開くVolume Configration にはデバイス名が表示されますが、最初にある ``mkfs.ext4`` は絶対に実行しないでください。これは初回にディスクを初期化するコマンドであり、リサイズする目的では利用しません。
![Screenshot 2024-08-16 at 4.05.52 PM.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/264188/43c3a7fa-8585-b726-d911-5389ec1f0d1d.jpeg)

![no-mkfs.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/264188/7907e082-c15a-58af-d10d-a35c4918bd95.jpeg)

:::

## OS 上で resize2fs の実行

```
> resize2fs /dev/disk/by-id/scsi-0Linode_Volume_bs
resize2fs 1.46.5 (30-Dec-2021)
Resizing the filesystem on /dev/disk/by-id/scsi-0Linode_Volume_bs to 671088640 (4k) blocks.
The filesystem on /dev/disk/by-id/scsi-0Linode_Volume_bs is now 671088640 (4k) blocks long.
```

## OS 上で mount の実行

```
> mount "/dev/disk/by-id/scsi-0Linode_Volume_bs" "/mnt/bs"
```

```
> df /mnt/bs
Filesystem      1K-blocks       Used Available Use% Mounted on
/dev/sdc       2641097552 1903482696 603380748  76% /mnt/bs

> df -h /mnt/bs
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc        2.5T  1.8T  576G  76% /mnt/bs
```

ディスク容量が増え、使用量が95% から76% になっています。Used のサイズは変わっていません。

これらの作業をしたときに記録された ``dmesg`` のメッセージです。

```
[ 4689.689164] scsi 6:0:0:0: Direct-Access     Linode   Volume           2.5+ PQ: 0 ANSI: 5
[ 4689.691544] sd 6:0:0:0: Power-on or device reset occurred
[ 4689.691590] sd 6:0:0:0: Warning! Received an indication that the LUN assignments on this target have changed. The Linux SCSI layer does not automatical
[ 4689.691950] sd 6:0:0:0: [sdc] 5368709120 512-byte logical blocks: (2.75 TB/2.50 TiB)
[ 4689.691988] sd 6:0:0:0: [sdc] Write Protect is off
[ 4689.691992] sd 6:0:0:0: [sdc] Mode Sense: 63 00 00 08
[ 4689.692060] sd 6:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 4689.694148] sd 6:0:0:0: Attached scsi generic sg2 type 0
[ 4689.770195] sd 6:0:0:0: [sdc] Attached SCSI disk
[ 5341.532369] EXT4-fs (sdc): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
```

# 作業時間

2.5 TB から 3 TB にしたときの ``e2fsck``, ``resize2fs`` の実行時間です。9.7 秒、 13.6 秒費やしています。
```
# time e2fsck -f /dev/disk/by-id/scsi-0Linode_Volume_bs
e2fsck 1.46.5 (30-Dec-2021)
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
/dev/disk/by-id/scsi-0Linode_Volume_bs: 1855822/167772160 files (0.0% non-contiguous), 486684926/671088640 blocks

real	0m9.774s
user	0m6.083s
sys	    0m0.483s
```
```
# time resize2fs /dev/disk/by-id/scsi-0Linode_Volume_bs
resize2fs 1.46.5 (30-Dec-2021)
Resizing the filesystem on /dev/disk/by-id/scsi-0Linode_Volume_bs to 805306368 (4k) blocks.
The filesystem on /dev/disk/by-id/scsi-0Linode_Volume_bs is now 805306368 (4k) blocks long.


real	0m13.628s
user	0m8.248s
sys	    0m0.288s
```

UI からディスクのリサイズは数秒で終わるので、ボリュームを外してリサイズして再アタッチするまでの作業は数分で終了すると思います。

# まとめ
ブロックストレージはローカルストレージよりは遅いですが、他の大手クラウドサービスと比較すると高速です。ローカルストレージが速すぎるとも言えます。今後必要なストレージサイズが増加する可能性があるなら、リサイズが容易なブロック・ストレージの利用がおすすめです。

本記事執筆中に Linode の Doc が Akamai TechDoc に統合されました。TechDoc は Google Translate と統合されていますので、日本語でもドキュメントが読むことできます。

https://techdocs.akamai.com/cloud-computing/docs/getting-started