Linux VM へのディスクの追加

  • [アーティクル]

適用対象: ✔️ Linux VM ✔️ フレキシブル スケール セット

この記事では、メンテナンスやサイズ変更により VM が再プロビジョニングされる場合でもデータを保持できるように、永続ディスクを VM に接続する方法について説明します。

新しいディスクの VM への接続

VM に新しい空のデータ ディスクを追加する場合は、--new パラメーターを指定して az vm disk attach コマンドを使用します。 VM が可用性ゾーン内にある場合は、VM と同じゾーンで、ディスクが自動的に作成されます。 詳細については、可用性ゾーンの概要に関するページをご覧ください。 次の例では、myDataDisk という名前で、サイズが 50 GB のディスクを作成します。

az vm disk attach \
   -g myResourceGroup \
   --vm-name myVM \
   --name myDataDisk \
   --new \
   --size-gb 50

より短い待機時間

一部のリージョンでは、ディスクのアタッチの待機時間が短縮されたため、最大 15% の改善が見られます。 これは VM 間で計画されたフェールオーバーまたは計画外のフェールオーバーを行ったり、ワークロードをスケーリングしたり、Azure Kubernetes Service などの大規模なステートフル ワークロードを実行したりしている場合に役立ちます。 ただし、この改善は明示的なディスク アタッチ コマンド az vm disk attach に限定されます。 az vm update のようなアタッチを暗黙的に実行する可能性があるコマンドを呼び出す場合は、パフォーマンスが向上しません。 この改善を行うには明示的なアタッチ コマンドを呼び出せばよく、それ以外のアクションは不要です。

現在、以下を除くすべてのパブリック リージョンで待機時間の短縮が可能です。

  • カナダ中部
  • 米国中部
  • 米国東部
  • 米国東部 2
  • 米国中南部
  • 米国西部 2
  • ドイツ北部
  • JIO インド西部
  • 北ヨーロッパ
  • 西ヨーロッパ

既存のディスクの接続

既存のディスクを接続するには、ディスク ID を探し、az vm disk attach コマンドに渡します。 次の例では、myResourceGroup 内の myDataDisk という名前のディスクにクエリを実行し、それを myVM という名前の VM に接続します。

diskId=$(az disk show -g myResourceGroup -n myDataDisk --query 'id' -o tsv)

az vm disk attach -g myResourceGroup --vm-name myVM --name $diskId

ディスクのフォーマットとマウント

Linux VM から使用できるように新しいディスクのパーティション分割、フォーマット、マウントを行うには、SSH で VM に接続します。 詳細については、Azure 上の Linux における SSH の使用方法に関するページをご覧ください。 次の例では、パブリック IP アドレス 10.123.123.25 と、ユーザー名 azureuser を指定して、VM に接続します。

ssh azureuser@10.123.123.25

ディスクの特定

ご利用の VM に接続したら、ディスクを見つけます。 この例では、lsblk を使用してディスクを一覧表示します。

lsblk -o NAME,HCTL,SIZE,MOUNTPOINT | grep -i "sd"

出力は次の例のようになります。

sda     0:0:0:0      30G
├─sda1             29.9G /
├─sda14               4M
└─sda15             106M /boot/efi
sdb     1:0:1:0      14G
└─sdb1               14G /mnt
sdc     3:0:0:0      50G

ここでは、sdc は 50 G であるため、これが目的のディスクです。 複数のディスクを追加する場合で、なおかつサイズだけではどのディスクかわからない場合は、ポータルの [VM] ページにアクセスし、[ディスク] を選択して、[データ ディスク] でディスクの LUN 番号を確認します。 ポータルから確認した LUN 番号と、出力の HTCL 部分にある最後の番号 (LUN) とを比較してください。 もう 1 つの方法として、次を実行して /dev/disk/azure/scsi1 ディレクトリの内容を一覧表示します。

ls -l /dev/disk/azure/scsi1

出力は次の例のようになります。

lrwxrwxrwx 1 root root 12 Mar 28 19:41 lun0 -> ../../../sdc

ディスクのフォーマット

parted を使用してディスクをフォーマットします。ディスクのサイズが 2 テビバイト (TiB) 以上の場合は、GPT パーティション分割を使用する必要があります。2 TiB 未満の場合は、MBR または GPT のパーティション分割を使用することができます。

Note

ご利用のディストリビューションで入手可能な最新バージョンの parted を使用することをお勧めします。 ディスク サイズが 2 テビバイト (TiB) 以上の場合は、GPT パーティション分割を使用する必要があります。 ディスク サイズが 2 TiB 未満の場合は、MBR または GPT のどちらのパーティション分割でも使用できます。

次の例では、/dev/sdc にある parted を使用します。これは、通常、ほとんどの VM 上で最初のデータ ディスクが置かれる場所です。 sdc を、ご利用のディスクに適したオプションに置き換えます。 また、XFS ファイル システムを使用してフォーマットしています。

sudo parted /dev/sdc --script mklabel gpt mkpart xfspart xfs 0% 100%
sudo partprobe /dev/sdc
sudo mkfs.xfs /dev/sdc1

partprobe ユーティリティを使用して、カーネルが新しいパーティションとファイルシステムを認識できるようにしています。 partprobe を使用しないと、blkid または lsblk コマンドで、新しいファイル システムの UUID がすぐに返されない可能性があります。

ディスクのマウント

次に、mkdir を使用して、ファイル システムをマウントするディレクトリを作成します。 次の例では、 /datadrive にディレクトリを作成します。

sudo mkdir /datadrive

mount を使用して、ファイル システムをマウントします。 次の例では、 /dev/sdc1 パーティションを /datadrive マウント ポイントにマウントします。

sudo mount /dev/sdc1 /datadrive

マウントの永続化

再起動後にドライブを自動的に再マウントするために、そのドライブを /etc/fstab ファイルに追加する必要があります。 ドライブを参照する場合に、デバイス名 (/dev/sdc1 など) だけでなく、UUID (汎用一意識別子) を /etc/fstab で使用することもお勧めします。 UUID を使用すると、OS が起動中にディスク エラーを検出した場合に、間違ったディスクが特定の場所にマウントされるのを防ぐことができます。 その後、残りのデータ ディスクは、その同じデバイス ID に割り当てられます。 新しいドライブの UUID を確認するには、blkid ユーティリティを使用します。

sudo blkid

出力は次の例のようになります。

/dev/sda1: LABEL="cloudimg-rootfs" UUID="11111111-1b1b-1c1c-1d1d-1e1e1e1e1e1e" TYPE="ext4" PARTUUID="1a1b1c1d-11aa-1234-1a1a1a1a1a1a"
/dev/sda15: LABEL="UEFI" UUID="BCD7-96A6" TYPE="vfat" PARTUUID="1e1g1cg1h-11aa-1234-1u1u1a1a1u1u"
/dev/sdb1: UUID="22222222-2b2b-2c2c-2d2d-2e2e2e2e2e2e" TYPE="ext4" TYPE="ext4" PARTUUID="1a2b3c4d-01"
/dev/sda14: PARTUUID="2e2g2cg2h-11aa-1234-1u1u1a1a1u1u"
/dev/sdc1: UUID="33333333-3b3b-3c3c-3d3d-3e3e3e3e3e3e" TYPE="xfs" PARTLABEL="xfspart" PARTUUID="c1c2c3c4-1234-cdef-asdf3456ghjk"

Note

/etc/fstab ファイルを不適切に編集すると、システムが起動できなくなる可能性があります。 編集方法がはっきりわからない場合は、このファイルを適切に編集する方法について、ディストリビューションのドキュメントを参照してください。 編集する前に、/etc/fstab ファイルのバックアップを作成することもお勧めします。

次に、テキスト エディターで /etc/fstab ファイルを開きます。 前の手順で作成した /dev/sdc1 デバイスの UUID 値と /datadrive のマウントポイントを使用して、ファイルの末尾に行を追加します。 この記事の例を使用すると、新しい行は次のようになります。

UUID=33333333-3b3b-3c3c-3d3d-3e3e3e3e3e3e   /datadrive   xfs   defaults,nofail   1   2

ファイルの編集が完了したら、エディターを保存して閉じます。

または、次のコマンドを実行して、ディスクを /etc/fstab ファイルに追加することもできます。

echo "UUID=33333333-3b3b-3c3c-3d3d-3e3e3e3e3e3e   /datadrive   xfs   defaults,nofail   1   2" >> /etc/fstab

Note

この後、fstab を編集せずにデータ ディスクを削除すると VM は起動できません。 ほとんどのディストリビューションでは、nofail または nobootwait fstab オプションが提供されています。 これにより起動時にディスクのマウントが失敗しても、システムを起動できます。 これらのパラメーターの詳細については、使用しているディストリビューションのドキュメントを参照してください。

nofail オプションを使用すると、ファイル システムが壊れているか、ブート時にディスクが存在しない場合でも VM が起動されるようになります。 このオプションを指定しない場合、「Cannot SSH to Linux VM due to FSTAB errors (FSTAB エラーが原因で Linux VM に SSH 接続できない)」で説明されているような動作が発生します。

fstab の変更が原因で起動エラーが発生した場合は、VM へのコンソール アクセスに Azure VM シリアル コンソールを使用できます。 詳細については、シリアル コンソールのドキュメントを参照してください。

Azure における Linux の TRIM/UNMAP サポート

一部の Linux カーネルでは、ディスク上の未使用ブロックを破棄するために TRIM/UNMAP 操作がサポートされます。 この機能は主に、削除されたページが無効になり、破棄できることを Azure に通知するのに役立ちます。 この機能を使用すると、非管理対象 Standard ディスクやディスク スナップショットなど、消費されたストレージの量に基づいて課金されるディスクのコストを節約できます。

Linux VM で TRIM のサポートを有効にする方法は 2 通りあります。 通常どおり、ご使用のディストリビューションで推奨される方法をお問い合わせください。

  • 次のように、/etc/fstab で discard マウント オプションを使用します。

    UUID=33333333-3b3b-3c3c-3d3d-3e3e3e3e3e3e   /datadrive   xfs   defaults,discard   1   2

  • 場合によっては、discard オプションがパフォーマンスに影響する可能性があります。 または、 fstrim コマンドを手動でコマンド ラインから実行するか、crontab に追加して定期的に実行することができます。

sudo apt install util-linux
sudo fstrim /datadrive

トラブルシューティング

データ ディスクを Linux VM に追加するときに、LUN 0 にディスクが存在しないと、エラーが発生することがあります。 az vm disk attach -new コマンドを使用して手動でディスクを追加していて、Azure プラットフォームに適切な LUN を判定させるのではなく、LUN を指定する (--lun) 場合は、LUN 0 にディスクが既に存在するようにするか、今後存在するようにしてください。

lsscsiからの出力のスニペットを示す次の例を考えてみましょう。

[5:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sdc 
[5:0:0:1]    disk    Msft     Virtual Disk     1.0   /dev/sdd

2 つのデータ ディスクは LUN 0 と LUN 1 に存在します (lsscsi の出力詳細の最初の列は [host:channel:target:lun] です)。 両方のディスクには、VM 内からアクセスできる必要があります。 LUN 1 で追加対象の最初のディスク、LUN 2 で 2 番目のディスクを手動で指定した場合は、VM 内からこれらのディスクを正しく見ることはできません。

Note

これらの例では Azure の host 値は 5 ですが、選択したストレージの種類によっては変わる可能性があります。

このディスクの動作は Azure の問題ではなく、Linux カーネルが SCSI の仕様に従う仕組みです。 Linux カーネルが接続されているデバイスの SCSI バスをスキャンするときに、デバイスが LUN 0 で検出される必要があります。システムが他のデバイスのスキャンを続行できるようにするためです。 そのため、次のようにしてください。

  • データ ディスクを追加した後に lsscsi の出力を確認し、LUN 0 にディスクがあることを確認します。
  • ディスクが VM 内に正しく表示されない場合は、ディスクが LUN 0 に存在することを確認します。

次のステップ