Azure Elastic SAN AV64 SKU対応の結論は、Azure VMware Solution（AVS）のAV64環境で、Azure Elastic SANデータストアを本番向けに使える選択肢が広がったという点です。AV64を使うAVS環境では、ホスト追加だけに頼らず、ストレージ容量や性能をより柔軟に拡張しやすくなります。MicrosoftのAzure Updatesでは、この更新が「Generally Available」「Launched」として扱われており、Azure Updates上のLaunchedは実稼働向けに完全リリースされた状態を指します。(Microsoft Azure)
ただし、これは「既存VMが自動的にElastic SANへ移行される」という意味ではありません。管理者は、AV64のリージョン・可用性ゾーン、Azure Elastic SANの作成条件、プライベートエンドポイント、iSCSIセッション数、RBAC権限、移行手順を事前に確認する必要があります。本記事では、Azure StorageのAzure Elastic SANに関する今回の更新を、AVS管理者・インフラ担当者・開発者が実務で確認すべき観点に絞って整理します。
Azure Storageの今回の更新で何が変わるのか
今回の更新は、Azure Storage全般のAI/Copilot機能追加ではなく、Azure Elastic SANとAzure VMware Solutionのストレージ連携に関する一般提供です。具体的には、Azure Elastic SANデータストアがAV64 SKUをサポートし、AV64を使うAVS展開で、より大規模・高性能なストレージ構成を取りやすくなりました。(Microsoft Azure)
Azure VMware Solutionでは、永続ストレージの選択肢としてiSCSIデータストアのアタッチをサポートしています。Azure Elastic SANボリュームからVMFSデータストアを作成し、任意のクラスターにアタッチできるため、クラスターを増やしてvSAN容量を確保するだけでなく、ストレージ側を個別に拡張する設計が可能です。(Microsoft Learn)
| 観点 | 変更点 | 実務上の意味 |
|---|---|---|
| 対象 | AVSのAV64 SKUでAzure Elastic SANデータストアを利用可能 | AV64クラスターでも外部データストア設計を検討しやすくなる |
| ステータス | Generally Available / Launched | プレビュー前提ではなく、本番利用を前提に検討できる |
| ストレージ設計 | Elastic SANボリュームをVMFSデータストアとして接続 | コンピュート追加とストレージ追加を分けて計画できる |
| 運用 | 既存vSANの置き換えではなく、追加のデータストア選択肢 | 移行・配置・監視設計は管理者側で必要 |
| 注意点 | リージョン、可用性ゾーン、ネットワーク、権限の条件がある | 「GAだからどこでも即利用可能」と判断しない |
影響が大きい環境
今回の更新で特に影響を受けるのは、AV64を使ってAzure VMware Solutionを拡張している、または今後AV64を採用する予定がある環境です。Microsoft Learnでは、Azure Elastic SANをAVSのバッキングストレージとして使う場合の対応ホストとして、Gen1ではAV36、AV36P、AV48、AV52、AV64、Gen2ではAV64が示されています。(Microsoft Learn)
| 対象環境 | 影響 | 確認すべきこと |
|---|---|---|
| AV64クラスターを利用中 | Elastic SANデータストアを追加候補にできる | 既存ワークロードの容量・IOPS・スループット要件 |
| AV64への拡張を計画中 | ストレージ拡張をホスト追加と分けて設計できる | AV64のリージョン/AZ、クォータ、ネットワーク |
| vSAN容量が逼迫しているAVS環境 | ホスト追加以外の容量拡張案を検討できる | どのVMをElastic SAN側へ配置するか |
| バックアップ、分析、スキャン系のI/Oが多い環境 | スループット重視のデータストア設計を検討しやすい | 実ワークロードでの性能検証 |
| 一般的なBlob StorageやAzure Files利用者 | 直接的な影響は限定的 | AVSを使っていない場合は対応不要 |
注意したいのは、AV64自体にも利用条件があることです。Azure VMware Solutionの価格ページでは、AV64 Gen1は追加前提となる既存プライベートクラウド条件があり、AV64 Gen2も利用可能リージョンが限定されるため、リージョンと可用性ゾーンの確認が必要とされています。(Microsoft Azure)
管理者が最初に確認すべき設定
Azure Elastic SANをAV64のAVS環境で使う場合、最初に見るべきポイントは「作れるか」ではなく「安定して運用できるか」です。特に、リージョン、可用性ゾーン、権限、ネットワーク、接続数の確認を後回しにすると、データストア接続や性能検証の段階で手戻りが発生しやすくなります。
| 確認項目 | 判断基準 | 見落としやすいポイント |
|---|---|---|
| リージョン/AZ | AVSプライベートクラウドとElastic SANを同じリージョン・可用性ゾーンで用意する | AV64、AVS、Elastic SANの提供状況を別々に確認する必要がある |
| RBAC権限 | 組み込みの所有者・共同作成者以外のカスタムロール利用時は権限を確認 | データストア作成・削除に必要なAVS/Elastic SAN双方の権限が不足しやすい |
| Elastic SAN基本サイズ | 少なくとも16TiBの基本サイズが必要 | 小さく作ってから後で調整する前提だと初期構成で詰まる可能性がある |
| CRC保護 | ボリュームグループのCRC保護は無効にする | AVSでは現在サポートされていないため、作成時に確認が必要 |
| プライベートエンドポイント | データストア接続前に必要数を構成する | 接続後に追加する場合、データストアのデタッチと再接続が必要 |
| iSCSIセッション | ホスト数、プライベートエンドポイント数、接続数を設計する | Elastic SANデータストアは最大128接続の制約がある |
| Gen1/Gen2差分 | Gen1とGen2でネットワーク構成の考え方が異なる | Gen2ではiSCSIセッションのスケーリングに複数プライベートエンドポイントは不要とされる |
Microsoft Learnでは、2025年11月時点で、AVSでElastic SANベースのデータストアを作成・削除するには適切な権限が必要と説明されています。カスタムロールを使う場合は、少なくとも Microsoft.AVS/privateClouds/clusters/datastores/write、Microsoft.ElasticSan/elasticSans/volumeGroups/volumes/write、Microsoft.ElasticSan/elasticSans/volumeGroups/volumes/read を確認してください。(Microsoft Learn)
ネットワークでは、AVS Gen1の場合、ExpressRouteゲートウェイのサイズがボトルネックになり得ます。Microsoft Learnでは、Elastic SANの帯域幅機能を処理できるようExpressRouteゲートウェイをサイズ設定する必要があり、例としてUltra Performance ExpressRoute Gatewayの帯域幅が1,280Mbpsであることが示されています。(Microsoft Learn)
展開前に決めておくべき設計方針
Azure Elastic SANをAV64のAVS環境へ追加する場合、いきなり本番VMを移すのではなく、まずデータストアの役割を明確にすることが重要です。
| 設計テーマ | 推奨される考え方 | 具体例 |
|---|---|---|
| 配置対象 | すべてのVMではなく、要件が合うVMから段階的に配置 | 大容量データを持つDB、分析用VM、バックアップ関連VM |
| 性能要件 | IOPS重視かスループット重視かを分ける | 小さなランダムI/Oが多いDB、連続読み書きが多いバックアップ |
| 可用性 | 既存vSANとElastic SANの役割を分ける | 基幹VMは既存設計を維持し、増加データ領域をElastic SANに配置 |
| 運用 | 監視、アラート、変更手順を事前に作る | 容量使用率、遅延、接続状態、APDイベントの確認 |
| コスト | ホスト追加とElastic SAN追加の両方で試算する | vSAN容量目的のホスト追加を避けられるか検討 |
特に大切なのは、Elastic SANを「安価な追加ディスク」とだけ見ないことです。AVSではVMFSデータストアとして扱うため、VM配置、移行計画、バックアップ、監視、障害時の切り分けまで含めて設計する必要があります。
移行・展開の進め方
既存のAVS環境にAzure Elastic SANデータストアを追加する場合は、次の順序で進めると手戻りを減らせます。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 現状把握 | AV64クラスター、vSAN使用量、VMごとのI/O傾向を棚卸しする | 容量不足なのか、性能不足なのかを分ける |
| 前提確認 | AV64、Elastic SAN、AVSのリージョン/AZ、クォータを確認する | 営業担当・パートナー確認が必要なケースもある |
| 権限確認 | 管理者ロール、カスタムロール、操作担当者を確認する | 作成権限だけでなく削除・変更権限も確認 |
| ネットワーク設計 | Gen1/Gen2に応じて接続方式、プライベートエンドポイント、アドレスブロックを設計する | Gen1では外部ストレージ用の/24アドレスブロックも確認 |
| Elastic SAN作成 | 同一リージョン/AZでElastic SAN、ボリュームグループ、ボリュームを作る | CRC保護、基本サイズ、命名規則を確認 |
| データストア接続 | AVSのストレージ画面からElastic SANを接続する | 接続前にプライベートエンドポイント構成を完了させる |
| 検証 | 非重要VMやテストVMで遅延、IOPS、スループットを測定する | 公式ベンチマークではなく自社ワークロードで判断 |
| 段階移行 | 対象VMを小さく分けて移行する | メンテナンスウィンドウ、バックアップ、戻し手順を用意 |
| 運用化 | 監視、アラート、容量管理、変更管理に組み込む | 75%超過など容量アラートの運用ルールを決める |
Elastic SANベースのデータストアを削除する場合、対象データストア上に仮想マシンまたは仮想ディスクが存在すると削除操作は完了できません。撤去時は、VMの移動、バックアップ、依存関係の確認を先に済ませておく必要があります。(Microsoft Learn)
パフォーマンス設計で見るべきポイント
Azure Elastic SANをAV64環境で使う最大のメリットは、高性能なAVSホストと外部データストアを組み合わせ、ストレージをより柔軟に拡張できる点です。ただし、公式のベンチマーク値をそのまま自社環境の保証値として扱うのは危険です。
Microsoft Learnのパフォーマンス記事では、ベンチマーク結果は保証された性能目標ではなく参考値であり、実際の性能はワークロード特性、VM構成、Elastic SANのプロビジョニングによって変わると説明されています。掲載例では、Gen2の3台のAV64ホスト、100TiBのElastic SAN基本容量、20TiBのデータストアバッキングボリュームなどの条件が示されています。(Microsoft Learn)
実務では、次のように分類して検証すると判断しやすくなります。
| ワークロード | 主なI/O傾向 | 検証ポイント |
|---|---|---|
| データベース | 小さなランダムI/O、読み取り多めになりやすい | 平均遅延、ピーク時遅延、トランザクション処理時間 |
| VDI/業務VM | 時間帯によるI/O集中 | 始業時・ログオン時のスパイク |
| バックアップ | 大きなシーケンシャルI/O | スループット、バックアップ時間、他VMへの影響 |
| 分析・スキャン | 連続読み取りが多い | 読み取り帯域、ジョブ完了時間 |
| 移行ステージング | 一時的に大量I/Oが発生 | 移行時間、同時実行数、ネットワーク帯域 |
公式情報にある最大IOPSやスループットの例だけで判断せず、必ず本番に近いVMサイズ、ディスク構成、同時実行数、バックアップ処理を含めて検証してください。特にExpressRouteやプライベートエンドポイント、iSCSIセッション設計が絡む場合、ストレージ単体の性能より接続経路が先に制約になることがあります。
AV64特有の移行リスクも確認する
AV64を使う場合、ストレージだけでなくクラスター間移行の互換性にも注意が必要です。Microsoft Learnでは、AV64ノードを既存のAVSプライベートクラウドへ追加すると異種環境になり、AV64クラスターとAV36/AV36P/AV52などのベースSKUクラスター間でEVCに起因するvMotion上の課題が発生する場合があると説明されています。(Microsoft Learn)
特に、ベースSKUクラスターからAV64クラスターへのvMotionは動作する一方、AV64側で作成されたVMや、AV64側で電源オフされたVMをベースSKU側へ戻すライブvMotionでは互換性エラーが発生するケースがあります。回避策としては、VMレベルのEVCモード設定やコールドvMotionが案内されています。(Microsoft Learn)
この点は、Elastic SANデータストアの接続可否とは別問題です。AV64環境でストレージを拡張する計画では、VMの配置先、戻し方、メンテナンス時の移動経路もセットで確認してください。
よくある失敗と対策
| 失敗しやすい判断 | なぜ問題になるか | 対策 |
|---|---|---|
| GAなので全リージョンで使えると思い込む | AV64、AVS、Elastic SANはリージョン/AZ条件が絡む | 計画段階でリージョン、AZ、クォータを確認する |
| 既存VMが自動的にElastic SANへ移ると思う | Elastic SANは追加データストアであり、自動移行ではない | 移行対象VMと移行手順を明確にする |
| プライベートエンドポイントを後から増やす | 接続後の追加ではデタッチと再接続が必要になる | データストア接続前に必要数を設計する |
| iSCSI接続数を計算しない | ホスト数とセッション数で接続上限に達する可能性がある | クラスター単位で接続数を計算する |
| 公式ベンチマークを性能保証として扱う | 実性能はワークロードと構成に依存する | 本番相当のテストを行う |
| 削除時にVMや仮想ディスクを残す | データストア削除が完了しない | 事前にVM移動、ディスク確認、バックアップを行う |
| AV64と既存SKU間の移動を軽視する | EVC差分でライブvMotionに制約が出る場合がある | VMレベルEVCやコールド移行を計画に入れる |
開発者・アプリ担当者が確認すべきこと
開発者やアプリ担当者にとって、今回の更新はアプリコードを直接変更する話ではありません。ただし、データストア配置が変わると、アプリの応答時間、バッチ処理時間、バックアップ時間、障害時の復旧手順に影響する可能性があります。
確認すべきことは次の3つです。
- ピーク時のI/Oパターンを管理者へ共有する
例として、月次締め処理、夜間バッチ、バックアップ、検索インデックス再構築などは、通常時より大きなI/Oを発生させます。 - 移行テストではアプリの正常性も確認する
VMが起動するだけでなく、DB接続、ログ出力、ファイル読み書き、バッチ完了時間、監視アラートまで確認します。 - IaCや運用スクリプトの固定値を見直す
データストア名、リソースグループ名、タグ、監視対象を固定している場合、Elastic SANデータストア追加後に監視漏れや自動化ミスが起きやすくなります。
まず取るべき次のアクション
今回のAzure Elastic SAN AV64 SKU対応は、AVSのストレージ設計を見直すよいタイミングです。特に、AV64を使っている環境、AV64への拡張を検討している環境、vSAN容量のためだけにホスト追加を検討している環境では、Elastic SANを選択肢に入れる価値があります。
最初に行うべきことは、次の5点です。
- 利用中または計画中のAVSがAV64対象か確認する
- AV64、Azure Elastic SAN、AVSのリージョン・可用性ゾーンを確認する
- カスタムロール、ネットワーク、プライベートエンドポイント、iSCSI接続数を設計する
- 重要度の低いVMでElastic SANデータストアの検証を行う
- 性能、容量、移行手順、戻し手順を文書化してから本番展開する
Azure Elastic SANは、AVSのストレージを単純に増やすためだけの機能ではありません。AV64の高性能なホストと組み合わせて、コンピュート、ストレージ、コスト、運用を分けて最適化するための選択肢です。導入判断では「使えるか」だけでなく、「どのワークロードを、どの性能要件で、どの運用体制で載せるか」まで決めてから展開しましょう。
コメント