Azure共有ディスクのLive ResizeがGA｜Premium SSD v2・Ultraを無停止拡張する手順と注意点

共有Premium SSD v2や共有Ultra Data Diskの容量を増やすために、接続中のすべてのVMを停止したり、ディスクをデタッチしたりする必要はなくなりました。Microsoftは2026年8月、Azure Disk Storageの「Live Resize」を共有Premium SSD v2と共有Ultra Data Diskにも拡大し、一般提供を開始しています。対象構成では、ディスクを複数VMに接続したまま、アプリケーションを停止せずに容量を拡張できます。

ただし、無停止で完了するのはAzureプラットフォーム側のディスク容量変更です。拡張後の領域を実際に利用するには、ゲストOSでディスクを再認識し、パーティションやファイルシステムを拡張する必要があります。また、容量の縮小、OSディスク、ほかの種類の共有ディスク、maxSharesの変更は今回のLive Resizeに含まれません。既存のディスク縮小は現在もサポートされていないため、拡張後に元へ戻す前提では運用できません。(Microsoft Learn)

共有Premium SSD v2・Ultra DiskのLive Resizeで何が変わったのか

今回一般提供された機能の対象と範囲は、次のとおりです。

項目	内容
一般提供時期	2026年8月
対象ディスク	共有Premium SSD v2、共有Ultra Data Disk
対象操作	プロビジョニング済み容量の拡張
VMの停止	対応構成では不要
ディスクのデタッチ	対応構成では不要
アプリケーション停止	Azure側の容量拡張では不要
容量縮小	非対応
ゲストOS側の操作	ディスク再スキャン、パーティション・ファイルシステム拡張が必要
IOPS・スループット	容量とは別に確認・設定が必要

これまでは、共有ディスクを接続した状態でサイズ変更を行うと、LiveResizeSharedDiskNotAllowedなどのエラーが発生し、すべてのVMからデタッチするか、VMを割り当て解除してから拡張する運用が案内されていました。2026年5月時点のMicrosoft Learnにも、この旧制限が記載されています。今回の一般提供は、その制限に対する例外として、共有Premium SSD v2と共有Ultra Data Diskを明示的に対象としたものです。(Microsoft Learn)

そのため、「共有ディスクはLive Resizeできない」という古い説明を、現在のPremium SSD v2とUltra Diskにも一律に当てはめないことが重要です。一方で、Premium SSDやStandard SSDなど、今回の発表で対象に含まれていない共有ディスクまで無停止拡張できると解釈してはいけません。

Azure共有ディスクとLive Resizeの基本

Azure共有ディスクは複数VMから同時に接続できるマネージドディスク

Azure共有ディスクは、1つのマネージドディスクを複数のAzure VMへ同時に接続する機能です。ディスクのmaxSharesを2以上に設定することで共有ディスクとなり、Windows Server Failover ClusterやPacemakerなどのクラスターマネージャーが、ノード間のアクセスや書き込み権限を制御します。Azure共有ディスク自体がSMBやNFSの共有ファイルサービスを提供するわけではありません。(Microsoft Learn)

代表的な利用例は次のとおりです。

SQL Server Failover Cluster Instance
Windows ServerのCluster Shared Volume
高可用性ファイルサーバー
SAP ASCS／SCSクラスター
Pacemakerを利用したLinuxクラスター
GFS2やOCFS2などのクラスターファイルシステム

共有Premium SSD v2と共有Ultra Diskは、どちらもmaxSharesを最大15まで設定できます。ただし、maxSharesの値そのものを変更する場合は、引き続きディスクをすべてのノードからデタッチする必要があります。容量のLive ResizeとmaxSharesの変更は、別の操作です。(Microsoft Learn)

Live ResizeはAzure側とゲストOS側の2段階で考える

ディスク拡張は、次の2段階に分けて考える必要があります。

段階	実施内容	Live Resizeの効果
Azure側	マネージドディスクのプロビジョニング容量を増やす	VMやアプリを止めずに実施可能
ゲストOS側	未割り当て領域をパーティションやファイルシステムへ追加する	OS、クラスター、ファイルシステムごとの手順が必要

Azureポータル上でディスクサイズが大きくなっても、WindowsのボリュームやLinuxのファイルシステムが自動的に広がるとは限りません。Azure側の拡張だけで作業を終えると、課金対象の容量は増えているのに、OSから利用できる容量は以前のままという状態になります。Microsoftの手順でも、Azure側の拡張後にOS内のボリュームを拡張するよう案内されています。(Microsoft Learn)

Live Resizeの対象になる構成と対象外の操作

今回の一般提供を適用できるかは、ディスクの種類だけでなく、用途や操作内容も含めて判断します。

構成・操作	今回のLive Resize
共有Premium SSD v2のデータディスクを拡張	対象
共有Ultra Diskのデータディスクを拡張	対象
Premium SSD v2、Ultra DiskのOSディスク	対象外
共有Premium SSDの容量拡張	今回の一般提供には含まれない
共有Standard SSDの容量拡張	今回の一般提供には含まれない
ディスク容量の縮小	非対応
`maxShares`の変更	Live Resizeとは別。デタッチが必要
Premium SSDからPremium SSD v2への種類変更	Live Resizeとは別の変換作業
パーティションやファイルシステムの拡張	ゲストOS側で別途実施

Premium SSD v2とUltra Diskはいずれもデータディスク向けで、OSディスクとしては利用できません。Premium SSD v2は1GiBから64TiB、Ultra Diskは4GiBから64TiBまで、原則として1GiB単位で容量を設定できます。利用できるリージョンや可用性構成はディスクタイプごとに異なるため、対象リージョンとVMサイズの対応状況も事前に確認してください。(Microsoft Learn)

また、Premium SSDやStandard SSDなどからPremium SSD v2へ変換する操作は、既存ディスクの容量を増やすLive Resizeとは異なります。既存の共有ディスクをPremium SSD v2へ変換する場合、Microsoftの現行手順ではすべてのVMからデタッチする必要があります。(Microsoft Learn)

共有ディスクを無停止で拡張する前の確認項目

本番環境では、サイズ変更コマンドを実行する前に、次の項目を確認します。

確認項目	判断基準
SKU	`PremiumV2_LRS`または`UltraSSD_LRS`である
ディスク用途	OSディスクではなくデータディスクである
共有設定	`maxShares`が2以上である
現在の容量	拡張前の値を記録する
目標容量	現在値より大きく、ディスクの上限以内である
クラスター状態	全ノードと共有ディスクリソースが正常である
バックアップ	直近の復元可能なバックアップまたはスナップショットがある
実行中の処理	ディスクコピー、エクスポート、復元などが実行中でない
OS構成	パーティション、LVM、CSV、GFS2、OCFS2などの構成を把握している
性能設定	IOPSとスループットの現在値を記録している

Premium SSD v2とUltra Diskの通常のLive Resizeでは、バックグラウンドコピー中のディスクを拡張できないという制限があります。バックアップ、復元、ディスクコピー、SASによるエクスポートなど、ディスクに対して別の処理が動いている場合は、完了後に実施するのが安全です。(Microsoft Learn)

「無停止の機能だからバックアップは不要」と判断するのも避けてください。Live Resizeはデータを移行せずに容量を増やす機能ですが、その後に行うパーティションやクラスターファイルシステムの操作には、設定ミスのリスクがあります。

Azure CLIで共有ディスクをLive Resizeする手順

現在のSKU、容量、共有数を確認する

最初に、対象ディスクがPremium SSD v2またはUltra Diskであることを確認します。

RG="my-resource-group"
DISK="my-shared-disk"

az disk show \
  --resource-group "$RG" \
  --name "$DISK" \
  --query "{sku:sku.name,sizeGiB:diskSizeGB,maxShares:maxShares,state:provisioningState}" \
  --output table

想定されるSKU名は次のどちらかです。

PremiumV2_LRS
UltraSSD_LRS

Azure CLIでは、PremiumV2_LRSとUltraSSD_LRSが正式なディスクSKU名として使用されます。(Microsoft Learn)

容量を拡張する

次の例では、共有ディスクを3TiB相当の3,072GiBへ拡張します。

NEW_SIZE_GIB=3072

az disk update \
  --resource-group "$RG" \
  --name "$DISK" \
  --size-gb "$NEW_SIZE_GIB"

az disk updateによる容量変更では、必ず現在より大きい値を指定します。対応する共有Premium SSD v2または共有Ultra Diskであれば、この操作のためにVMを停止したり、ディスクをデタッチしたりする必要はありません。通常のマネージドディスク拡張でも、--size-gbを使用して新しい容量を指定します。(Microsoft Learn)

Azure側の反映を確認する

az disk show \
  --resource-group "$RG" \
  --name "$DISK" \
  --query "{sizeGiB:diskSizeGB,state:provisioningState}" \
  --output table

diskSizeGBが指定した値になり、provisioningStateがSucceededであることを確認してから、ゲストOS側の作業へ進みます。

Azure PowerShellで共有ディスクを拡張する手順

Azure PowerShellを使用する場合は、対象ディスクを取得してDiskSizeGBを更新します。

$resourceGroupName = "my-resource-group"
$diskName = "my-shared-disk"
$newSizeGiB = 3072

$disk = Get-AzDisk `
    -ResourceGroupName $resourceGroupName `
    -DiskName $diskName

$disk.DiskSizeGB = $newSizeGiB

Update-AzDisk `
    -ResourceGroupName $resourceGroupName `
    -DiskName $diskName `
    -Disk $disk

反映後は、次のコマンドで容量と状態を確認できます。

Get-AzDisk `
    -ResourceGroupName $resourceGroupName `
    -DiskName $diskName |
Select-Object Name, DiskSizeGB, ProvisioningState

MicrosoftのWindows向けディスク拡張手順でも、Get-AzDiskで取得したディスクのDiskSizeGBを変更し、Update-AzDiskで反映する方法が案内されています。(Microsoft Learn)

AzureポータルからLive Resizeする手順

Azureポータルを使用する場合は、次の順序で操作します。

Azureポータルで対象の「ディスク」リソースを開く
「サイズとパフォーマンス」を開く
現在より大きい容量を入力する
必要に応じてIOPSとスループットの値を確認する
「サイズ変更」または「保存」を選択する
概要画面で容量とプロビジョニング状態を確認する

対応構成であれば、VMの「停止」や「割り当て解除」は行いません。ポータルがVM停止やデタッチを要求する場合は、そのまま進めず、ディスクSKU、共有設定、対象リージョン、VM構成が今回のLive Resizeに対応しているかを再確認してください。

Windows Server Failover Clusterで拡張領域を反映する

全ノードで新しいディスク容量が見えるか確認する

Azure側のサイズ変更後、ゲストOSへ新しい容量が反映されるまで時間がかかることがあります。Microsoftの現行ドキュメントでは、WindowsとLinuxのVMへ正しいサイズが反映されるまで最大10分程度かかる場合があり、必要に応じて再スキャンを繰り返すよう案内されています。(Microsoft Learn)

Windowsでは、管理者権限のPowerShellからストレージ情報を更新できます。

Update-HostStorageCache
Get-Disk

すべてのクラスターノードで、対象ディスクの容量が新しい値として認識されているか確認します。古い容量のままのノードがある場合は、少し時間を置いて再スキャンします。

CSVの拡張は所有者ノードで行う

Cluster Shared Volumeを拡張する場合、パーティションやボリュームに対するメタデータ操作は、CSVの所有者ノード、つまりコーディネーターノードで実行します。

所有者ノードは、次のようなコマンドで確認できます。

Get-ClusterSharedVolume |
Select-Object Name, State, OwnerNode

ディスク番号とパーティション番号を十分に確認したうえで、利用可能な最大サイズへパーティションを拡張します。

$diskNumber = <対象のディスク番号>
$partitionNumber = <対象のパーティション番号>

$range = Get-PartitionSupportedSize `
    -DiskNumber $diskNumber `
    -PartitionNumber $partitionNumber

Resize-Partition `
    -DiskNumber $diskNumber `
    -PartitionNumber $partitionNumber `
    -Size $range.SizeMax

CSVの拡張を非コーディネーターノードから実行すると、処理自体は成功したように見えても、ディスク管理画面やクラスターGUIの容量表示が古いままになる場合があります。MicrosoftはCSVの拡張を所有者ノードで実施し、非コーディネーターノードからメタデータ操作を行わないよう案内しています。(Microsoft Learn)

通常のクラスター共有ボリュームでは、Disk Management、DiskPart、PowerShellなどを使用して既存パーティションを未割り当て領域へ拡張できます。ただし、アプリケーションやストレージドライバーがオンライン拡張に対応しているかは、事前に検証環境で確認してください。(Microsoft Learn)

Linuxクラスターで拡張領域を反映する

Linuxでは、Azure側でディスクを拡張しても、カーネルがすぐに新しい容量を認識しない場合があります。対象デバイスを確認したうえで、必要なノードから再スキャンします。

次の例は、デバイスが/dev/sdcの場合です。

echo 1 | sudo tee /sys/class/block/sdc/device/rescan
sudo fdisk -l /dev/sdc
lsblk

MicrosoftのLinux向け手順でも、/sys/class/block/<device>/device/rescanへ1を書き込み、ディスクの新しいサイズを認識させる方法が案内されています。(Microsoft Learn)

その後の手順は、ストレージ構成によって異なります。

構成	必要な作業
通常パーティション	パーティション拡張後、ファイルシステムを拡張
LVM	物理ボリューム、論理ボリューム、ファイルシステムを順に拡張
GFS2	クラスターファイルシステムのオンライン拡張手順を使用
OCFS2	OCFS2固有の拡張手順を使用
Pacemaker管理	リソース所有ノードやメンテナンスモードを確認して実行

共有ディスク上のGFS2やOCFS2に対して、通常のext4やXFS向けコマンドをそのまま実行してはいけません。また、すべてのノードから同時にパーティション変更コマンドを実行するのも避けます。クラスターマネージャーとファイルシステムが指定する所有ノードやオンライン拡張手順に従ってください。

容量を増やしてもIOPSやスループットは自動的に増えるとは限らない

Premium SSD v2とUltra Diskでは、容量、IOPS、スループットを個別に設定できます。そのため、Live Resizeで容量を2TiBから4TiBへ増やしても、設定済みのIOPSやスループットが自動的に2倍になるとは限りません。(Microsoft Learn)

設定項目	容量拡張時の考え方
容量	Live Resizeで増加する
読み書きIOPS	現在値を確認し、必要なら別途変更する
読み書きスループット	現在値を確認し、必要なら別途変更する
読み取り専用IOPS	共有ディスク固有の設定として確認する
読み取り専用スループット	共有ディスク固有の設定として確認する
VM側のディスク上限	ディスク性能より低くないか確認する

共有Premium SSD v2と共有Ultra Diskでは、通常の読み書き用設定に加えて、読み取り専用接続向けのIOPSとスループット設定が追加されます。合計性能は、読み書き用と読み取り専用の設定を合算して計算されます。(Microsoft Learn)

Azure CLIでは、次のように現在の設定を確認できます。

az disk show \
  --resource-group "$RG" \
  --name "$DISK" \
  --query "{
    sizeGiB:diskSizeGB,
    rwIOPS:diskIOPSReadWrite,
    rwMBps:diskMBpsReadWrite,
    roIOPS:diskIOPSReadOnly,
    roMBps:diskMBpsReadOnly
  }" \
  --output table

容量不足だけが問題なら、IOPSやスループットをむやみに増やす必要はありません。反対に、空き容量は十分でもディスクキューや待機時間が増えている場合は、容量ではなく性能設定やVMサイズ側の上限を見直します。

Live Resize後の料金で注意すること

Premium SSD v2とUltra Diskは、プロビジョニングした容量、IOPS、スループットを基準に課金されます。ディスク容量を拡張すると、実際の使用量ではなく、拡張後のプロビジョニング容量が課金対象になります。(Microsoft Learn)

共有Premium SSD v2では、ディスクをマウントするVMが増えても、VMごとの追加マウント料金は発生しません。ただし、共有ディスク用に設定された読み取り専用IOPSやスループットを含む、合計のプロビジョニング性能が料金に影響します。(Microsoft Learn)

そのため、Live Resizeを使えるからといって、将来必要になりそうな最大容量まで一度に増やすのは得策ではありません。縮小できないことを前提に、予測可能な期間分だけ段階的に拡張する方が、コストを抑えやすくなります。

拡張する容量を決める実務的な計算方法

目標容量は、現在の使用量だけでなく、増加速度と次回見直しまでの期間を使って決めます。

目標容量
= 現在の使用量
+ 月間増加量 × 確保する月数
+ 安全余裕

例えば、現在の使用量が1,600GiB、毎月100GiB増え、次回見直しまで6カ月確保したい場合は、次のように計算できます。

1,600GiB + 100GiB × 6カ月 = 2,200GiB

ここへ20％程度の安全余裕を加えると、必要容量は約2,640GiBです。Premium SSD v2とUltra Diskは1GiB単位で設定できるため、2,700GiB前後へ拡張する判断ができます。

運用ルールとしては、次のような基準が実用的です。

使用率70％で増加傾向を確認する
使用率80％、または空き容量が運用リードタイムを下回る前に拡張する
一度に確保するのは、次回見直しまでの3～12カ月分を目安にする
季節変動や大量データ投入がある場合は、その予定量を別途加える
拡張後はコスト予測も更新する

無停止で変更できるとはいえ、ゲストOSやクラスター側の操作、動作確認、監視まで含めると一定の運用作業は発生します。容量が限界へ達してから慌てて実行するのではなく、余裕を持ったしきい値を設定してください。

Live Resizeで失敗しやすいポイント

Azure側の変更だけで作業を終える

Azureポータルに新しい容量が表示されても、ゲストOSのボリュームが古いサイズなら、アプリケーションが利用できる空き容量は増えていません。

Azure側、OSのディスク認識、パーティション、ファイルシステム、アプリケーションの順で確認します。

CSVを所有していないノードから拡張する

Windows Server Failover Clusterでは、CSVの所有者ノードからパーティションやボリュームを拡張します。非所有者ノードから実行すると、容量表示が不整合になる可能性があります。(Microsoft Learn)

Live Resizeなら容量を後で戻せると考える

既存のAzureマネージドディスクは縮小できません。誤って大きくしすぎた場合、一般的には小さい新規ディスクを作成し、データを移行して切り替える必要があります。縮小を前提とした一時的な拡張には向いていません。(Microsoft Learn)

容量拡張とmaxShares変更を同時に考える

Live Resizeで変更できるのは容量です。接続可能なノード数を示すmaxSharesは、すべてのノードからディスクをデタッチした状態で変更します。(Microsoft Learn)

容量を増やせば性能問題も解消すると考える

Premium SSD v2とUltra Diskでは、容量と性能が分離されています。空き容量不足とI/O性能不足を切り分け、必要な項目だけを変更します。

ストライプボリュームを通常のボリュームと同じ手順で拡張する

Windows向けのAzureディスク拡張ドキュメントでは、ストライプボリュームは通常の拡張手順の対象外とされています。複数ディスクをストライプしている場合は、各ディスクの容量や性能をそろえる必要があるため、ストレージプールやアプリケーション側の設計を含めて確認してください。(Microsoft Learn)

LiveResizeSharedDiskNotAllowedが表示される場合の確認方法

一般提供後もLiveResizeSharedDiskNotAllowedが表示される場合は、次の順番で確認します。

SKUが正確にPremiumV2_LRSまたはUltraSSD_LRSであるか
対象がデータディスクであるか
指定したサイズが現在値より大きいか
最大容量を超えていないか
ディスクコピー、復元、エクスポートなどが動作していないか
Azure CLIやAzure PowerShellが古くないか
対象リージョン、VMサイズ、ディスク接続構成が対応しているか
Azureポータルでも同じエラーになるか

今回の一般提供より前に更新されたトラブルシューティングページには、共有ディスク全般をLive Resize対象外とする説明が残っている場合があります。しかし、2026年8月の一般提供では、共有Premium SSD v2と共有Ultra Data Diskが明示的に対象となっています。条件を満たしているにもかかわらずエラーになる場合は、安易に本番VMを停止する前に、対象リソースID、SKU、リージョン、エラーコードを整理してAzureサポートへ確認するのが安全です。(Microsoft Learn)

拡張後に確認すべきチェックリスト

作業完了後は、容量だけでなくクラスターとアプリケーションまで確認します。

確認対象	確認内容
Azureディスク	指定した容量、`Succeeded`状態
各VM	新しい物理ディスク容量を認識している
パーティション	未割り当て領域が残っていない
ファイルシステム	Windowsボリューム、LVM、GFS2、OCFS2などが新容量を認識している
クラスター	全ノード、ディスクリソース、CSVがオンライン
アプリケーション	読み書き、トランザクション、フェイルオーバーが正常
性能	IOPS、スループット、待機時間、キューが想定範囲
バックアップ	次回バックアップが正常に完了する
料金	拡張後の容量と性能設定でコスト予測を更新した

特に高可用性構成では、現在の所有者ノードで読み書きできることだけでなく、別ノードへフェイルオーバーした後も、新しい容量が正しく認識されることを確認してください。

まず対象ディスクを棚卸しし、検証環境で手順を固める

共有Premium SSD v2と共有Ultra Data DiskのLive Resizeにより、容量不足への対応でクラスター全体を停止する必要がなくなりました。小さい容量から開始し、実際の使用量に応じて段階的に増やせるため、可用性とコストの両方を改善しやすくなります。

一方で、Live Resizeは「Azure側の容量を増やす機能」であり、ゲストOSのボリューム拡張、クラスターファイルシステムの操作、IOPSやスループットの調整まで自動化するものではありません。縮小もできないため、拡張量は将来予測に基づいて決める必要があります。

最初にsku.name、diskSizeGB、maxShares、IOPS、スループットを一覧化してください。その後、検証環境で「Azure側の拡張」「各ノードの再スキャン」「所有者ノードでのボリューム拡張」「フェイルオーバー確認」までを一連の手順として確認し、本番環境の運用手順へ反映することが重要です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Azure共有ディスクのLive ResizeがGA｜Premium SSD v2・Ultraを無停止拡張する手順と注意点

共有Premium SSD v2・Ultra DiskのLive Resizeで何が変わったのか

Azure共有ディスクとLive Resizeの基本

Azure共有ディスクは複数VMから同時に接続できるマネージドディスク

Live ResizeはAzure側とゲストOS側の2段階で考える

Live Resizeの対象になる構成と対象外の操作

共有ディスクを無停止で拡張する前の確認項目

Azure CLIで共有ディスクをLive Resizeする手順

現在のSKU、容量、共有数を確認する

容量を拡張する

Azure側の反映を確認する

Azure PowerShellで共有ディスクを拡張する手順

AzureポータルからLive Resizeする手順

Windows Server Failover Clusterで拡張領域を反映する

全ノードで新しいディスク容量が見えるか確認する

CSVの拡張は所有者ノードで行う

Linuxクラスターで拡張領域を反映する

容量を増やしてもIOPSやスループットは自動的に増えるとは限らない

Live Resize後の料金で注意すること

拡張する容量を決める実務的な計算方法

Live Resizeで失敗しやすいポイント

Azure側の変更だけで作業を終える

CSVを所有していないノードから拡張する

Live Resizeなら容量を後で戻せると考える

容量拡張とmaxShares変更を同時に考える

容量を増やせば性能問題も解消すると考える

ストライプボリュームを通常のボリュームと同じ手順で拡張する

LiveResizeSharedDiskNotAllowedが表示される場合の確認方法

拡張後に確認すべきチェックリスト

まず対象ディスクを棚卸しし、検証環境で手順を固める

この記事を書いた人

コメント

コメントするコメントをキャンセル

Azure共有ディスクのLive ResizeがGA｜Premium SSD v2・Ultraを無停止拡張する手順と注意点

共有Premium SSD v2・Ultra DiskのLive Resizeで何が変わったのか

Azure共有ディスクとLive Resizeの基本

Azure共有ディスクは複数VMから同時に接続できるマネージドディスク

Live ResizeはAzure側とゲストOS側の2段階で考える

Live Resizeの対象になる構成と対象外の操作

共有ディスクを無停止で拡張する前の確認項目

Azure CLIで共有ディスクをLive Resizeする手順

現在のSKU、容量、共有数を確認する

容量を拡張する

Azure側の反映を確認する

Azure PowerShellで共有ディスクを拡張する手順

AzureポータルからLive Resizeする手順

Windows Server Failover Clusterで拡張領域を反映する

全ノードで新しいディスク容量が見えるか確認する

CSVの拡張は所有者ノードで行う

Linuxクラスターで拡張領域を反映する

容量を増やしてもIOPSやスループットは自動的に増えるとは限らない

Live Resize後の料金で注意すること

拡張する容量を決める実務的な計算方法

Live Resizeで失敗しやすいポイント

Azure側の変更だけで作業を終える

CSVを所有していないノードから拡張する

Live Resizeなら容量を後で戻せると考える

容量拡張とmaxShares変更を同時に考える

容量を増やせば性能問題も解消すると考える

ストライプボリュームを通常のボリュームと同じ手順で拡張する

LiveResizeSharedDiskNotAllowedが表示される場合の確認方法

拡張後に確認すべきチェックリスト

まず対象ディスクを棚卸しし、検証環境で手順を固める

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル