こんにちはますのです。
Azureの仮想マシンをお触りしています。基本的な考え方はAWSと差は少ないので、IaaSとして使う分にはどちらも使えるなぁと感じております。
強いて言うならば、リソースグループあたりの考え方が少し違うくらいですね。Azureでの検証がひと段落しそうなので、触れるうちにもう少し触っておきたい所存です。
さてさて、今回はLinuxの仮想マシンでAzureVMにディスクを追加する手順のメモです。
おそらくLinuxのOS側の操作に関してはAWSと一緒なのかしら？というところです。少なくともWindowsは同じですね。
Linuxのコマンド…相変わらず覚えられずなのです。
一応参考手順をぺたり。
参考：https://docs.microsoft.com/ja-jp/azure/virtual-machines/linux/attach-disk-portal
やりたいこと
- AzureVMにOSディスクとは別に10GBのディスクをアタッチする
- 対象OS：CentOS 8.2（仮想マシン）
- マウント先：/mnt/test01
Azureポータル上でディスクを作成する
先ずはAzureポータルのGUI上でポチポチします。
- Virtual Machines＞対象の仮想マシン＞ディスクをクリック
- ディスク名やストレージサイズを任意の内容に設定＞保存をクリック
ホストキャッシュの詳細は別記事を作りましたのでそちらをご確認あれです。
【Azureディスク】VMのホストキャッシュ設定「読み取り専用」「読み取り/書き込み」の違い
Linux OS側で新しいディスクをマウントする
続いてAzureのLinux VMにssh接続して新しいディスクを使えるようにします。
新しくアタッチされたディスクを特定する
$ lsblk -o NAME,HCTL,SIZE,MOUNTPOINT | grep -i "sd"出力結果はこんな感じになるかと思います。今回は10GBのディスクをアタッチしたので「sdc」であることが分かります。
また、LUNを「1」と設定していた場合、「HCTL」の値が「3:0:0:1」と変化するので容量ではなく「3:0:0:*」で判断するのも有りのようです。
sda 0:0:0:0 30G
L sda1 500M /boot
L sda2 29G /
L sda14 4M
L sda15 495M /boot/efi
sdb 1:0:1:0 4G
L sdb1 4G /mnt/resource
sdc 3:0:0:0 10G追加ディスクのパーティション分割
続いて「parted」コマンドで追加したディスクのパーティション分割を行います。
今回は「GPTパーティション」、「xfs」形式、10GB全てを「/dev/sdc1」へ設定します。
# sudo parted /dev/sdc --script mklabel gpt mkpart xfs 0% 100%
# sudo mkfs.xfs /dev/sdc1
meta-data=/dev/sdc1 isize=512 agcount=4, agsize=655232 blks
= sectsz=4096 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=1, rmapbt=0
= reflink=1
data = bsize=4096 blocks=2620928, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0, ftype=1
log =internal log bsize=4096 blocks=2560, version=2
= sectsz=4096 sunit=1 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
# sudo partprobe /dev/sdc1ディスクをマウントする
まずはマウント先のフォルダを作成します。
# /mnt/test01では作成したフォルダに先ほどパーティション分割を行ったディスクをマウントします。
# sudo mount /dev/sdc1 /mnt/test01
以上でマウント設定は完了となります。
再起動後も自動マウントするよう「/etc/fstab」へも追記する
mountコマンドでマウントしたものは、OS起動時に再度マウントされない状態です。
OS起動時に自動でマウントするようにするためには「/etc/fstab」へ追記が必要となります。
操作に自信がない場合はスナップショットを取得したり、「/etc/fstab」をバックアップして備えましょう。
# sudo blkid結果はこんな感じのものが返ってきます。
先ほどマウントを実施した「/dev/sdc1」のUUIDを確認します。
/dev/sda1: UUID="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" TYPE="xfs" PARTUUID="a1a2a3a4-4321-juki-mmmm5678ghjk"
/dev/sda2: UUID="bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb" TYPE="xfs" PARTUUID="e1e2e3e4-1234-abcd-cccc9876ghjk"
/dev/sda15: SEC_TYPE="msdos" UUID="D63C-950A" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="d1d2d3d4-5678-cdef-bbbb3456ghjk"
/dev/sdb1: UUID=UUID="cccccccc-cccc-cccc-cccc-cccccccccccc" TYPE="ext4" PARTUUID="a1a2a3a4-01"
/dev/sdc1: UUID="dddddddd-dddd-dddd-dddd-dddddddddddd" TYPE="xfs" PARTLABEL="xfs" PARTUUID="c1c2c3c4-1234-cdef-asdf3456ghjk"/etc/fstabへUUIDでOS起動時のマウント設定をする
# sudo vi /etc/fstab以下の内容を一番下に追記して保存する。
UUID=dddddddd-dddd-dddd-dddd-dddddddddddd /mnt/test01 xfs defaults,nofail 0 0記述が間違えてないかを念のため確認。fstabを即時反映させる。
mount -a
fstabの記述が間違えている場合、この時点でエラーが出るはずなのでfstab内を見直すか切り戻しましょう。
fstabを編集しない状態でデータディスクを削除するとAzureVMは起動しなくなるようで。。。
筆者、いつか絶対やらかすと思います。また、fstab内に記載する「0 0」は起動時にdumpする？fsckする？というオプションです。
dumpはしないので「0：、fsckも今回においては不要なので「0」としてます。
fsck：ルートボリュームの場合「1」、それ以外は「2」を設定すると良いとのことで、Microsoft手順上では「2」となっていますね。
マウント設定後の動作確認
「mount -a」が無事完了した際は「lsblk」でマウントされていることを確認します。
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 30G 0 disk
L sda1 8:1 0 500M 0 part /boot
L sda2 8:2 0 29G 0 part /
L sda14 8:14 0 4M 0 part
L sda15 8:15 0 495M 0 part /boot/efi
sdb 8:16 0 4G 0 disk
L sdb1 8:17 0 4G 0 part /mnt/resource
sdc 8:32 0 10G 0 disk
L sdc1 8:33 0 10G 0 part /mnt/test01手順としては簡単ですが、仮想マシンの致命傷にもなり得るところなので確認してやりたいところになります。
特にfstab記載したままディスク消したらヤバイヨ！っていうのはあまり気にしていなかった箇所なので勉強になりました。
皆さんの参考になれば幸いでございます。