Azure Storageの「Azure Elastic SAN support for AVS Gen2 Private Cloud」が一般提供になりました。要点は、Azure VMware Solution（AVS）Gen2 Private CloudでElastic SANデータストアを使う際、ExpressRouteゲートウェイに依存しない構成が可能になり、接続設計がシンプルになることです。特に、バックアップ、分析、スキャン、大容量データ読み込みなど、スループットを重視するAVSワークロードでは、ストレージ拡張の選択肢として確認する価値があります。(Microsoft Azure)
一方で、「一般提供だからすぐ本番に入れてよい」と単純に判断するのは危険です。AVS Gen1とGen2ではPrivate EndpointやExpressRouteの考え方が異なり、権限、リージョン、可用性ゾーン、iSCSIセッション数、CRC保護、データストア接続順序を事前に確認する必要があります。この記事では、2026年5月6日に公開または更新されたAzure Storage関連の公式情報をもとに、変更点、影響範囲、管理者・開発者が取るべき確認事項を実務目線で整理します。
Azure Elastic SAN support for AVS Gen2 Private Cloudの概要
今回の更新は、Azure Elastic SANをAzure VMware Solution Gen2 Private Cloudのデータストアとして利用する構成が一般提供になった、という内容です。
Azure Elastic SANは、Azure上で提供されるクラウドネイティブなSANサービスです。AVSでは、Elastic SANボリュームをVMFSデータストアとして作成し、任意のAVSクラスターへアタッチできます。これにより、ストレージ容量を増やすためだけにAVSクラスターをスケールアウトするのではなく、ストレージ側を独立して拡張しやすくなります。(Microsoft Learn)
従来、AVS環境のストレージ拡張では、vSAN容量、ホスト追加、Azure NetApp Files、外部ストレージ構成などを含めて設計する必要がありました。Elastic SANをAVS Gen2で使いやすくなることで、特に「計算リソースは足りているが、ストレージ容量やスループットを増やしたい」というケースで選択肢が広がります。
今回の更新で注目すべきポイントは、主に次の3つです。
| 観点 | 変更点 | 実務上の意味 |
|---|---|---|
| 接続構成 | AVS Gen2ではExpressRouteが不要 | ExpressRouteゲートウェイ帯域に引っ張られにくい |
| Private Endpoint | 1つのPrivate Endpointで構成可能 | Gen1より接続設計がシンプルになる |
| パフォーマンス | Elastic SANでプロビジョニングしたスループットを活用しやすい | 大容量I/Oワークロードで効果を見込みやすい |
何が変わったのか
AVS Gen2ではExpressRouteゲートウェイが不要になる
今回の一般提供で最も分かりやすい変更点は、AVS Gen2 Private CloudでElastic SANデータストアを使う場合、ExpressRouteが不要とされている点です。Microsoft Learnの構成ガイドでも、AVS Gen2ではボリュームグループのPrivate Endpointを作成し、Private Cloud Connectivityを使う構成になっており、iSCSIセッションを拡張するために複数のPrivate Endpointは不要と説明されています。(Microsoft Learn)
これは、設計上かなり大きな違いです。
AVS Gen1では、ExpressRoute仮想ネットワークゲートウェイの帯域がElastic SANデータストアの性能上限に影響する可能性がありました。公式ドキュメントでも、Gen1ではElastic SANの帯域要件に合わせてExpressRouteゲートウェイをサイズ設計する必要があると説明されています。(Microsoft Learn)
AVS Gen2ではこの制約が緩和されるため、Elastic SAN側で確保したスループットをより直接的に活用しやすくなります。
1つのPrivate EndpointでiSCSIセッション構成を扱いやすくなる
AVS Gen1では、性能や冗長性を確保するために複数のPrivate Endpointを使って複数のiSCSIセッションを構成する考え方が重要でした。一方、AVS Gen2では、1つのPrivate EndpointでiSCSIセッションを複製できるため、複数Private Endpointを前提とした複雑な設計が不要になります。(Microsoft Learn)
管理者にとっては、次のようなメリットがあります。
- ネットワーク構成のレビュー項目が減る
- Private Endpointの数を増やす設計ミスを避けやすい
- 接続トラブル時の切り分け対象が少なくなる
- 展開手順を標準化しやすい
ただし、「Private Endpointが1つでよい」という点を、「ネットワーク設計を確認しなくてよい」と誤解してはいけません。Elastic SANはAVS Private Cloudと同じリージョン、同じ可用性ゾーンに配置することが推奨されています。性能と可用性を安定させるには、リージョン、ゾーン、Private Endpoint、ボリュームグループの関係を展開前に確認する必要があります。(Microsoft Learn)
スループット重視のAVSワークロードに向く
公式更新では、AVS Gen2 Private CloudとElastic SANデータストアを組み合わせることで、接続構成を簡素化しつつ、性能面でもメリットがあるとされています。特に、ExpressRouteゲートウェイ帯域によるスループット制限を受けにくくなる点は、バックアップ、スキャン、分析、読み取り中心の大容量処理などで重要です。(Microsoft Azure)
Microsoft Learnの性能検証では、AVS Gen2、AV64ホスト、Elastic SANを同一リージョン・同一可用性ゾーンに配置した構成で、I/O集約型ワークロードとスループット集約型ワークロードのベンチマーク例が示されています。ただし、公式ドキュメントでも、結果は保証値ではなく、実際の性能はワークロード特性、VM構成、Elastic SANのプロビジョニングによって変わると明記されています。(Microsoft Learn)
影響を受ける環境
今回の更新で直接影響を受けるのは、Azure Storage、Azure Elastic SAN、Azure VMware Solutionを組み合わせて利用する環境です。特に、AVS Gen2 Private Cloudを新規展開する、またはAVS上のストレージ拡張を検討している管理者は確認しておくべきです。
| 対象 | 影響 |
|---|---|
| AVS Gen2 Private Cloud利用者 | Elastic SANデータストアをよりシンプルに接続できる |
| AVS Gen1利用者 | 既存のExpressRouteや複数Private Endpoint設計は引き続き確認が必要 |
| ストレージ管理者 | 容量、スループット、iSCSI接続数、可用性ゾーンの設計が重要になる |
| ネットワーク管理者 | Gen2ではExpressRoute前提の設計から見直せる可能性がある |
| VMware管理者 | VMFSデータストア、仮想ディスク形式、vCenter上のAPDイベント監視が関係する |
| 開発・アプリ運用担当者 | 大容量I/Oを行うアプリの配置先検討に影響する |
特に注意したいのは、AVS Gen1とGen2を同じ感覚で扱わないことです。AVS Gen1では、ExpressRouteゲートウェイ、外部ストレージ用アドレスブロック、複数Private Endpoint、iSCSIセッション数の設計が重要です。一方、AVS Gen2ではPrivate Endpoint構成が簡素化されます。既存の運用手順書を流用する場合は、Gen1向けの前提が残っていないか確認しましょう。
管理者が最初に確認すべき設定
対応するAVSホストタイプを確認する
Azure Elastic SANをAVSのバッキングストレージとして使う場合、対応ホストタイプを確認する必要があります。公式ドキュメントでは、AVS Gen1はAV36、AV36P、AV48、AV52、AV64、AVS Gen2はAV64が対象として示されています。(Microsoft Learn)
本番環境で確認すべきポイントは次のとおりです。
| 確認項目 | 見るべき内容 |
|---|---|
| AVS世代 | Gen1かGen2か |
| ホストSKU | 対応ホストタイプか |
| クラスター構成 | 接続先クラスター数、ホスト数 |
| メンテナンス時の余裕 | 追加ノードや一時的な構成変更に対応できるか |
特に複数クラスターへ同じElastic SANデータストアを接続する場合は、iSCSIセッション数と接続数の上限を事前に計算する必要があります。Elastic SANデータストアはクラスターへ接続すると全ノードに自動的にアタッチされるため、ノード数が多い環境では接続数を想定以上に消費しやすくなります。(Microsoft Learn)
リージョンと可用性ゾーンをそろえる
Elastic SANは、AVS Private Cloudと同じリージョン、同じ可用性ゾーンに配置することが推奨されています。これは単なる形式的な条件ではありません。ストレージI/Oの遅延や性能に影響するため、本番ワークロードでは必ず確認すべき項目です。(Microsoft Learn)
展開前には、次の順序で確認するとミスを減らせます。
| 手順 | 確認内容 |
|---|---|
| 1 | AVS Private Cloudが存在するリージョンを確認する |
| 2 | AVSホストが配置されている可用性ゾーンを確認する |
| 3 | Elastic SANを同じリージョン・同じ可用性ゾーンに作成する |
| 4 | ボリュームグループとボリュームを作成する |
| 5 | Private Endpointを構成する |
| 6 | AVS側でElastic SANをデータストアとして接続する |
「同じリージョンならよい」と考えて可用性ゾーンを見落とすと、期待した性能が出ない可能性があります。AVSホストの可用性ゾーンはUIで確認できるため、Elastic SAN作成前に必ず確認しておきましょう。
Elastic SANの基本容量は16TiB以上を確認する
公式ドキュメントでは、AVSでElastic SANを使う前提として、少なくとも16TiBの基本サイズを持つElastic SANを作成することが示されています。ベストプラクティスでも、Elastic SANデータストアで最大性能を得るために基本サイズを16TiB以上にすることが推奨されています。(Microsoft Learn)
ここで重要なのは、容量と性能を別々に考えないことです。Elastic SANは、プロビジョニングした容量や構成によって性能が変わります。単に「必要な容量だけ」を見積もるのではなく、次の観点で設計する必要があります。
- 必要なデータストア容量
- 想定するIOPS
- 必要なスループット
- ピーク時のバックアップ・スキャン処理
- 将来のクラスター拡張
- メンテナンス時の一時的な余裕
バックアップ処理や分析処理が夜間に集中する環境では、平常時のI/Oだけを見て設計すると不足しやすくなります。
CRC保護はAVSでサポートされていない点に注意する
Elastic SANのボリュームグループではCRC保護に関する設定がありますが、Azure VMware Solutionでは現在サポートされていないため、無効にしておく必要があります。(Microsoft Learn)
ここは見落としやすいポイントです。セキュリティやデータ保護の観点から「有効にした方がよさそう」と判断してしまうと、AVS側のサポート条件と合わなくなる可能性があります。設定値は、一般的な感覚ではなく、AVSとの組み合わせでサポートされているかを基準に確認しましょう。
移行・展開前のチェックリスト
Elastic SANをAVS Gen2 Private Cloudに接続する前に、次のチェックリストを使って環境を確認しておくと、展開後の手戻りを減らせます。
| チェック項目 | 確認ポイント | 未確認時のリスク |
|---|---|---|
| AVS世代 | Gen2 Private Cloudか | Gen1向け手順を誤って適用する |
| ホストSKU | AV64か | サポート対象外構成になる |
| リージョン | AVSとElastic SANが同じか | レイテンシや構成不整合の原因になる |
| 可用性ゾーン | AVSホストとElastic SANが同じか | 性能劣化や想定外の設計になる |
| Elastic SAN容量 | 基本サイズが16TiB以上か | 性能要件を満たせない可能性がある |
| Private Endpoint | ボリュームグループに作成済みか | データストア接続ができない |
| CRC保護 | AVS向けに無効か | サポートされない構成になる |
| 権限 | AVSとElastic SAN双方の権限があるか | 作成・削除操作に失敗する |
| 仮想ディスク形式 | eager zeroed thickを使うか | 性能・運用要件と合わない可能性がある |
| 監視 | 容量、I/O、APDイベントを確認できるか | 障害時の切り分けが遅れる |
AVS Gen2では構成がシンプルになったとはいえ、ストレージ基盤として使う以上、権限とネットワークと容量設計は省略できません。PoC環境で接続できた設定をそのまま本番へコピーするのではなく、本番のクラスター数、ホスト数、ピークI/Oに合わせて再確認することが重要です。
権限で確認すべきポイント
2025年11月時点の公式ドキュメントでは、AVSでElastic SANベースのデータストアを作成・削除するには、適切な権限が必要とされています。OwnerやContributorなどの組み込みロールを両サービスに対して使っている場合は大きな変更は不要とされていますが、カスタムロールを使っている場合は権限不足に注意が必要です。(Microsoft Learn)
作成・削除に関係する主な権限は次のとおりです。
| 操作 | 必要な権限の例 |
|---|---|
| データストア作成 | Microsoft.AVS/privateClouds/clusters/datastores/write |
| Elastic SANボリューム操作 | Microsoft.ElasticSan/elasticSans/volumeGroups/volumes/write |
| Elastic SANボリューム参照 | Microsoft.ElasticSan/elasticSans/volumeGroups/volumes/read |
実務では、Azure管理者、ストレージ管理者、VMware管理者が別チームになっていることがあります。その場合、Azure portal上では見えていても、実際の接続や削除操作で権限不足が起きることがあります。
展開前に、次のように役割分担を明確にしておくと安全です。
| 担当 | 主な確認内容 |
|---|---|
| Azure管理者 | サブスクリプション、リソースグループ、ロール割り当て |
| ストレージ管理者 | Elastic SAN、ボリュームグループ、ボリューム、容量設計 |
| ネットワーク管理者 | Private Endpoint、IP範囲、名前解決、接続経路 |
| VMware管理者 | AVSクラスター、データストア接続、仮想ディスク形式、vCenter監視 |
本番展開では、作成権限だけでなく削除権限も確認しておくべきです。検証後にデータストアを外せない、不要なボリュームを削除できない、といった運用上の詰まりを防げます。
接続手順の流れ
AVS Gen2でElastic SANをデータストアとして使う場合、概念的には次の流れで準備します。
| ステップ | 作業内容 |
|---|---|
| 1 | AVS Gen2 Private Cloudのリージョンと可用性ゾーンを確認する |
| 2 | 同じリージョン・可用性ゾーンにElastic SANを作成する |
| 3 | ボリュームグループとボリュームを作成する |
| 4 | ボリュームグループにPrivate Endpointを作成する |
| 5 | AVS Private Cloudのストレージ画面からElastic SANを接続する |
| 6 | データストア名をVMware要件に合わせて設定する |
| 7 | vCenter側でデータストア認識、容量、イベントを確認する |
公式手順では、Azure VMware Solution Private Cloudの左メニューから「Storage」を選び、「Connect Elastic SAN」からサブスクリプション、リソース、ボリュームグループ、ボリューム、接続先クラスターを選択します。(Microsoft Learn)
重要なのは、Private Endpointをデータストア接続前に構成することです。公式ドキュメントでは、ボリュームをデータストアとしてアタッチした後にPrivate Endpointを追加する場合、データストアをいったんデタッチしてクラスターへ再接続する必要があるとされています。(Microsoft Learn)
このため、作業順序は次のように覚えておくと実務でミスを防げます。
Elastic SANを作る → ボリュームを作る → Private Endpointを作る → AVSに接続する
「AVSに接続してからネットワークを調整する」という順序は、手戻りの原因になります。
移行時に注意すべきポイント
既存VMの配置先をいきなり切り替えない
Elastic SANデータストアが利用可能になったからといって、既存の重要VMをすぐ移動するのは避けるべきです。まずは、I/O特性が分かっている検証用VMや、影響範囲を限定できるワークロードで性能と運用を確認しましょう。
確認すべき項目は次のとおりです。
- vCenterでデータストアが安定して認識されるか
- VM作成、起動、停止、削除が問題なく行えるか
- バックアップ処理中のスループットが想定内か
- ピーク時間帯のレイテンシが許容範囲か
- Azure MonitorやvCenterで必要な監視ができるか
- APDイベントやiSCSIセッション断の兆候がないか
Microsoft Learnでは、セッション切断がvCenterのESXi HostイベントでAll Paths Down、つまりAPDイベントとして見える可能性があると説明されています。接続後はAzure側だけでなく、vCenter側のイベントも確認対象に含めるべきです。(Microsoft Learn)
仮想ディスクはeager zeroed thickを検討する
公式ドキュメントでは、仮想ディスク作成時にeager zeroed thick provisioningを使うことが推奨されています。これは、ディスク領域を事前に予約し、初期化しておく方式です。(Microsoft Learn)
実務上は、次のように考えると判断しやすくなります。
| 用途 | 推奨判断 |
|---|---|
| 高I/Oの業務アプリ | eager zeroed thickを優先的に検討 |
| 検証環境 | コストと性能要件を見て判断 |
| 容量効率重視の一時VM | 要件に応じて別方式も検討 |
| 本番DB・基幹系 | 性能、バックアップ、運用ルールを含めて事前検証 |
仮想ディスク形式は、単に「容量をどれだけ使うか」だけでなく、性能、初期展開時間、運用ポリシーに関係します。VMware管理者とストレージ管理者で事前に標準ルールを決めておくと、後からVMごとに設定がばらつくのを防げます。
削除・切り戻し手順も先に決める
Elastic SANベースのデータストアを削除する場合、AVSのStorageからDatastore listを開き、対象データストアのメニューからDeleteを選んでクラスターから切断します。その後、必要に応じてElastic SAN側のボリュームを削除します。(Microsoft Learn)
ただし、Elastic SAN VMFS Datastore上にVMや仮想ディスクが存在する場合、この削除操作は完了できません。(Microsoft Learn)
本番運用では、次のような切り戻し手順を用意しておきましょう。
| 場面 | 事前に決めること |
|---|---|
| 性能が想定に届かない | VMを元のデータストアへ戻す方法 |
| 接続が不安定 | 監視ログ、vCenterイベント、Azure側メトリックの確認手順 |
| 検証を終了する | VM・仮想ディスクの退避、データストア切断、ボリューム削除 |
| 容量が不足する | Elastic SAN側の容量拡張、AVS側のVMFSリサイズ手順 |
切り戻しを考えずに本番VMを移すと、障害時に「VMが残っていてデータストアを外せない」「どのチームが削除権限を持っているか分からない」といった問題が起きやすくなります。
開発者・アプリ運用担当者が見るべきポイント
今回の更新はインフラ寄りの内容ですが、アプリケーション側にも影響があります。特に、AVS上で稼働する業務アプリ、分析基盤、バックアップ処理、ファイルスキャン処理を運用している場合は、ストレージ特性の変化を理解しておくべきです。
向いているワークロード
Elastic SANデータストアは、次のようなワークロードで検討しやすい選択肢です。
| ワークロード | 理由 |
|---|---|
| バックアップ処理 | 大きなシーケンシャルI/Oが発生しやすい |
| データ分析 | 大容量データの読み取りが多い |
| スキャン処理 | 一定時間に大量の読み取りが集中しやすい |
| データベース周辺処理 | IOPSとスループットの設計が重要 |
| ストレージ容量が先に逼迫するVM群 | ホスト追加以外の拡張手段になる |
公式の性能ドキュメントでも、I/O集約型ワークロードとスループット集約型ワークロードが例として扱われており、バックアップ、スキャン、分析、read-aheadのような処理がスループット集約型の例として挙げられています。(Microsoft Learn)
アプリ側で確認すべきこと
アプリ運用担当者は、インフラチームに任せきりにせず、次の点を確認しましょう。
- ピークI/Oが発生する時間帯
- バックアップやバッチ処理の同時実行数
- ストレージ遅延がアプリ応答に与える影響
- 既存vSANデータストアとの性能差
- 移行後に監視するべきアプリメトリック
- 障害時に許容できる復旧時間
特に、複数のVMが同じElastic SANデータストアへ同時に高負荷をかける場合、単一VMのテスト結果だけでは判断できません。実際の本番に近い同時実行条件で検証することが重要です。
AVS Gen1環境ではどう考えるべきか
今回の一般提供はAVS Gen2 Private Cloud向けのメリットが大きい内容です。ただし、AVS Gen1でElastic SANを使う場合も、公式ドキュメント上は引き続きサポートされるホストタイプがあります。(Microsoft Learn)
AVS Gen1では、次の点に注意が必要です。
| 項目 | AVS Gen1での注意点 |
|---|---|
| ExpressRoute | ゲートウェイ帯域をElastic SANの要件に合わせて設計する |
| Private Endpoint | 複数Private EndpointでiSCSIセッションを設計する |
| 外部ストレージ用IPブロック | /24ネットワークを指定し、重複を避ける |
| メンテナンス時の影響 | ExpressRouteゲートウェイメンテナンス時の接続影響を考慮する |
| セッション数 | 128接続上限を意識して設計する |
Gen1環境では、外部ストレージ用アドレスブロックにも注意が必要です。公式ドキュメントでは、/24ネットワークであること、AVS Private Cloud作成時の/22や接続済みVNet、オンプレミスネットワークと重複しないこと、指定後に編集できないことが説明されています。(Microsoft Learn)
既存のAVS Gen1環境でElastic SANを検討する場合は、「Gen2ではExpressRouteが不要」という情報だけを見て設計を簡略化しないようにしましょう。Gen1とGen2では前提が違います。
よくある失敗パターン
Gen1向け手順をGen2にそのまま適用する
AVS Gen2ではPrivate Endpoint構成が簡素化されています。にもかかわらず、Gen1時代の手順書をそのまま使うと、不要に複雑なPrivate Endpoint構成やネットワーク設計になりがちです。
古い手順書を使う場合は、次の記述が残っていないか確認しましょう。
- ExpressRouteゲートウェイ帯域を前提にした性能設計
- 複数Private Endpointを必須とする記述
- Gen1専用の外部ストレージ用アドレスブロック手順
- AV36、AV36P、AV52前提のセッション数設計
Private Endpoint作成前にデータストアを接続する
Private Endpointは、Elastic SANボリュームをデータストアとしてアタッチする前に構成する必要があります。後から追加する場合、データストアのデタッチと再接続が必要になります。(Microsoft Learn)
検証環境ならやり直せますが、本番では停止調整が必要になる可能性があります。手順書では、Private Endpoint作成を「任意」ではなく「データストア接続前の必須作業」として扱いましょう。
接続数を計算せずに複数クラスターへ接続する
Elastic SANデータストアは最大128接続に注意が必要です。クラスターへ接続すると全ノードに自動でアタッチされるため、ホスト数とiSCSIセッション数の掛け算で上限に近づくことがあります。(Microsoft Learn)
複数クラスターで共有する構成を検討する場合は、少なくとも次の式で見積もりましょう。
必要接続数 = クラスター内ホスト数 × 1ホストあたりのiSCSIセッション数 × 接続クラスター数将来のホスト追加やメンテナンス用ノードも考慮し、上限ぎりぎりの設計は避けるべきです。
性能検証を単一VMだけで終える
Elastic SANの性能は、ワークロード、VM構成、プロビジョニング、同時実行数によって変わります。公式のベンチマーク結果も参考値であり、保証値ではありません。(Microsoft Learn)
本番に近い判断をするには、次のパターンを分けて検証しましょう。
| 検証パターン | 目的 |
|---|---|
| 単一VMの読み書き | 基本性能の確認 |
| 複数VMの同時I/O | データストア全体の負荷確認 |
| バックアップ同時実行 | 夜間ピークの再現 |
| 障害・切断イベント確認 | vCenterイベントや監視の確認 |
| 容量拡張・リサイズ | 運用時の変更手順確認 |
今回の更新を受けて次に取るべき行動
AVS Gen2 Private Cloudを利用している、または今後AVS Gen2への移行・新規展開を検討している場合は、Azure Elastic SANをストレージ拡張の候補に入れてよい段階です。特に、計算リソースではなくストレージ容量やスループットがボトルネックになっている環境では、ホスト追加以外の選択肢として検討する価値があります。
まずは、次の順序で確認するとよいでしょう。
| 優先度 | やること |
|---|---|
| 高 | 現在のAVSがGen1かGen2か確認する |
| 高 | ホストSKU、リージョン、可用性ゾーンを確認する |
| 高 | 既存ストレージの容量、IOPS、スループットの課題を整理する |
| 中 | Elastic SANを同一リージョン・同一可用性ゾーンで検証する |
| 中 | Private Endpoint、権限、CRC保護、接続手順を確認する |
| 中 | 本番に近いVM同時実行条件で性能を測る |
| 低 | 既存手順書からGen1前提の記述を分離する |
今回の一般提供は、単なる新機能追加ではなく、AVS Gen2における外部ストレージ設計を簡素化する更新です。管理者は「ExpressRoute不要」「Private Endpointは1つでよい」というメリットだけでなく、対応SKU、可用性ゾーン、権限、接続順序、監視まで含めて確認しましょう。
本番導入の第一歩は、既存AVS環境の世代とストレージ課題を棚卸しすることです。そのうえで、Elastic SANを「容量拡張の手段」として見るのか、「高スループットワークロード向けのデータストア」として使うのかを明確にすると、過不足のない設計にしやすくなります。
コメント