Skip to content

MS_AzureDiskStorage

Jump to bottom
nishi_74322014 edited this page Aug 19, 2026 · 1 revision

Azureのディスク ストレージ

概要

補足（最新化 / 重要）: 非管理ディスク（アンマネージド ディスク）は
2025 年 9 月末で提供終了しており、現在は管理ディスクのみである。
したがって、以下の「非管理ディスクの方が安い」といった比較や、
後半の「管理ディスク → 非管理ディスクへの切り替え」手順は、
現在は実行できない。当時の記録として読まれたい。

現在のディスク選定は、種類（HDD / SSD / Premium / Ultra）と
サイズ・性能の組み合わせで行う。

unManage Disk (非管理ディスク)

GPv1・GPv2

  • GPv1
    ストレージ層を選択する機能がなく、すべてがホット・ストレージ層扱いになる。

  • GPv2
    GPv1 の Blob にホット/クール/アーカイブのアクセス層とストレージ・イベントなどを追加

  • 差異

    • パフォーマンス：差異なし。
    • 耐障害性：差異なし。
    • 課金体系：差異あり。
      Standard ディスクを使用する場合は費用の差異がある。

Standard HDD/Premium SSD

  • Standard HDD：コスト最小化
  • Premium SSD：高パフォーマンスな SSD ベースのストレージ

Managed Disk (管理用ディスク)

Blob ファイルのページ Blobが適切に隠蔽・自動管理される。
（ストレージ・アカウントを Azure が管理し、ユーザが意識する事が無い）

  • ストレージアカウントの IOPS 上限などを意識する必要はなくなる。

  • バックアップやスナップショット、イメージなど様々な機能があり、UI からの操作性に優れる。

  • LRS ではなく、可用性セットを組み合わせて使用することで、
    可用性セットの VM のディスクが、単一障害点にならないように相互に十分に分離される。

補足（管理ディスクが解決した本質的な問題）: 非管理ディスクでは、
ストレージ アカウント単位に IOPS の上限があった。
複数 VM のディスクを同じアカウントに置くと互いに性能を食い合い、
かつアカウント自体が単一障害点になった。

【非管理】 VM1 ─┐
           VM2 ─┼─▶ 1 つのストレージ アカウント ← ここが上限であり SPOF
           VM3 ─┘

【管理】   VM1 ─▶ 管理ディスク（Azure が配置を自動分散）
           VM2 ─▶ 管理ディスク

本文の「可用性セットの VM のディスクが単一障害点にならないよう
相互に十分に分離される」は、この自動分散を指している。
性能設計と可用性設計から「ストレージ アカウント」という
考慮事項を消したのが、管理ディスク最大の価値である。

Standard HDD

  • バックアップなど、費用対効果に優れた HDD ベース
  • シングル VM だと、95％の SLA
  • 例外的に、地理冗長(GRS/RA-GRS)を使用可能。

Standard SSD

  • Web サーバ、開発など、費用対効果に優れた SSD ベース
  • シングル VM でも、99.5％の SLA

Premium SSD

  • スループットを高める、運用環境向けの SSD ベース
  • シングル VM でも、99.99％の SLA
  • 仮想マシンのシステム・ドライブはコチラを既定で考える。
    • 特に 500 IOPS よりも高い IOPS が必要なシステム
    • 64GB 以下のサイズだと Standard HDD よりも
      パフォーマンスが悪くなる場合がある。
    • 可用性セットを組まなくても SLA の対象となる。

Ultra ディスク

I/O 集約型ワークロード向けの SSD ベース

補足（最新化 / 種類の整理）: 現在は Premium SSD v2 が加わり、
選択肢は次のようになっている。

種類 特徴 向く用途
Standard HDD 最安。IOPS 低 バックアップ、アクセス頻度の低いデータ
Standard SSD 安価で安定 Web サーバ、開発・検証
Premium SSD サイズで性能が決まる（P30 = 5,000 IOPS 等） 一般的な本番 VM
Premium SSD v2 容量と IOPS / スループットを独立に指定できる 本番。過剰なサイズ確保が不要になる
Ultra ディスク 最高性能・低遅延 大規模 DB、SAP HANA

Premium SSD v2 の登場が実務上は大きい。
従来の Premium SSD は「IOPS が欲しいから容量を上げる」という
無駄が発生していたが、v2 ではそれが不要になった。

なお、SLA は現在可用性ゾーンや可用性セットの構成を含めて
評価されるため、上記の数値は当時のものとして読むこと。

課金

補足（「中途半端なサイズでも課金は同じ」）: Premium / Standard SSD の
管理ディスクは P10, P20, P30 ... という階層（Tier）で課金される。
たとえば 200 GiB のディスクを作っても、
256 GiB（P15/E15 相当）の料金が発生する。
したがって、階層の境界を意識してサイズを決めるとコストの無駄が減る。

Premium SSD v2 は指定した容量そのままで課金されるため、
この階層の縛りがない。

unManage Disk (非管理ディスク)

  • Azure Storage 上のディスク形式

  • 課金

    • Standard ディスクを使用する場合は、
      GPv1・GPv2 で、費用の差異がある。

      • GPv1 は、容量確保型、確保容量で課金される。
      • GPv2 は、
        ・使った（書き込んで専有した）容量だけ課金される。
        ・その代わりに、トランザクション（I/O）の課金がある。
        ・また、GRS/RA-GRS のみデータ転送に対する課金がある。

    • Premium ディスクは、容量確保型、確保容量で課金される。

  • VM 作成時に、管理ディスクを使用 [いいえ] を選択する。

  • ID は、URL で、「https://・・・.windows.net/・・・」などとなる。

Managed Disk (管理用ディスク)

  • Azure Storage 上で Azure Disk Storage
  • 容量確保型、確保容量で課金される。
  • VM 作成時に、管理ディスクを使用 [はい] を選択する。
  • ID は、リソース ID で、「/subscriptions/・・・」となる。

VM の管理用ディスクを切り替える。

VM で使用している管理用ディスクを
非管理ディスクに切り替える。

移行メモ: 前述のとおり非管理ディスクは提供終了しているため、
以下の手順は現在は実行できない。
ただし、

  • 管理ディスクを VHD としてエクスポートする方法、
  • エクスポートした VHD から VM を作る方法、

という 2 点は、現在もオンプレミスへの持ち出しや
別サブスクリプションへの移動で有用なので、記録として残す。

概要

VM からデタッチした管理用ディスク（インストール・ディスク）を VHD 化、
VHD を非管理ディスク（Azure のディスク ストレージ）に保存して、VM へアタッチ。

  1. 管理ディスクから VHD を取り出す
    1. 下を参考に、管理用ディスクをエクスポート。
    2. URL が表示されるので、仮想マシンと同じリソース・グループに、
      新規にストレージ・アカウント & コンテナを作成して、VHD をコピー。
# azcopy とか
# Start-AzureStorageBlobCopy とか
# az storage blob copy とか
  1. VM を削除して、VHD から作成
    • VHD ができたら、その VHD から、新しい VM を作成。
    • Azure ポータルで、VHD から仮想マシンを作れないので、
      Azure PowerShell か Azure CLI で、スクリプトを少々走らせる必要がある。
  2. 作成した VM に問題なかったら、もとの管理用ディスクを削除

スクリプト

概要

管理ディスクの実容量を確認する

BLOB の SAS トークン URL
を使用して管理ディスクの実容量を確認する。

ps1 ファイル

使用方法

  • Azure ポータルで、管理ディスクをエクスポートして BLOB Url を得る。

    Azure ポータル >>「ディスク」>>「ディスク名」>> [エクスポート] >> [URL の生成]

  • 生成された URL を指定して、実行すると、

.\Get-BlobBytes.ps1 -url 'https://mdxxxxxxx.blob.core.windows.net/・・・'
  • 下の様な表示を確認できる。
BlobName    : xxxxxxxxxxx
BlobLength  : nnnnnnnnnnn   <= 割り当てられたサイズ (GiB)
BlobGB      : nn.nn
ActualBytes : nnnnnnnnnn    <= 実容量のサイズ
ActualGB    : nn.nn            (GB表記)

補足説明

  • Page BLOB の Url

    • 管理ディスクからエクスポートされた Url は、変換された Page BLOB の Url になる。

    • 最後に、Azure ポータルの [x エクスポートのキャンセル] を
      クリックして、SAS トークン URL を取り消す（無駄な共有はしない）。

  • 見積もり

補足（この節が示す設計上の含意）: 「割り当てサイズ」と「実容量」が
異なるという指摘は、非管理ディスク（Page BLOB）の
スパース性に基づくものである。
逆に言えば、管理ディスクは確保した容量で課金されるため、
「1 TB のディスクを作って 50 GB しか使っていない」場合、
当時は非管理ディスクの方が大幅に安かった。
これが本文の「管理ディスクの方が高額になりがち」の根拠である。

現在は非管理ディスクが無いため、
必要なサイズだけ確保し、後から拡張する
（ディスクの拡張は可能。縮小は不可）という運用になる。

VHD に変換する

  • 既存の VHD ファイルを使った VM 作成は、Azure ポータルではできないので、スクリプトが必要。
  • スクリプトでは、管理ディスクの Url を使用して、Azure Storage に VHD ファイルとしてコピーする。

ps1 ファイル

使用方法

以下のように実行する。

  • Azure ポータルから、

    • VM 名
    • リソース・グループ名

    を確認する。

  • サブスクリプション

    • 名前を確認、
Get-AzureRmSubscription
  • 選択し、
Select-AzureRmSubscription -SubscriptionName サブスクリプション名
  • リソース・グループ名、VM 名を指定して実行。
.\rm-convert-vm-manageddisk-to-vhd.ps1 -ResourceGroupName リソース・グループ名 -vmName VM名

補足（最新化）: スクリプト内の AzureRM モジュールは 2024 年 2 月に
提供終了しており、現在は Az モジュールを使う
（Get-AzSubscription、Select-AzSubscription など）。
コマンドレット名は概ね AzureRm → Az の置換で対応する。

補足説明

  • 上記を実行後に表示される管理ディスクを削除する。

    • 非同期操作はポータル表示との整合性が取れず、
      「VM → 管理ディスクの関連付け」が削除されていないように見えることがある。

    • この場合、管理ディスクの「所有者 VM」欄を確認し
      「管理ディスク → VM の関連付け」を確認すると良い。

    • このように、IaC は、
      ポータルでサポートされてない操作を実装するケースが多そうだが、
      そもそもサポートされない操作には非同期である操作が多く、
      実装上の問題（ ≒ ポータル表示との整合性の問題）があるもよう。

移行メモ（表記）: 原文の「IaaC」は
IaC (Infrastructure as Code) の誤記と判断し修正した。

参考

microsoft.com

Microsoft Azure

Microsoft Learn

Tags: 移行, インフラストラクチャ, クラウド, Azure

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally