Azure Localの「External storage support for Azure Local」を一言でいうと、オンプレミスの既存SANや新規SANを、Azure Local上のVM、AKS、Azure Virtual Desktop向けブロックストレージとして活用できる機能です。2026年4月のAzure Local 2604では、SANストレージ対応が一般提供として整理され、SANのみを使う分離型デプロイメントも選択肢に入りました。まず確認すべきことは、「既存SANを使えるか」ではなく、「Azure Local 2604以降、対応HBA・ドライバー・FCファブリック・MPIO・CSV・Storage Pathまで一貫して設計できるか」です。Microsoft Learnのリリース情報では、Azure Local 12.2604.1003.209の提供日が2026-04-22、OSビルドが26100.32690とされています。(Microsoft Learn)
「External storage support for Azure Local」は、previewとして追っていたIT管理者にとって、本番検討へ進める材料が増えた更新です。ただし、すべてのSAN構成が無条件に使えるわけではありません。Microsoft Learnの外部ストレージ対応ページでは、Fibre ChannelベースのSAN接続とDell PowerFlexがGenerally availableとして整理され、ラック認識クラスターはハイパーコンバージド構成の外部SANストレージではサポート対象外とされています。(Microsoft Learn)
Azureの最新動向: External storage support for Azure Localで何が変わったか
2026年4月更新のポイントは、Azure Localで外部SANを「例外的な追加ストレージ」ではなく、ワークロードごとのストレージ選択肢として扱いやすくなったことです。Azure Local 2604のWhat’s newでは、SANストレージをAzure Localで利用でき、Storage Spaces Directと並行して使えること、さらにSANストレージのみを使う分離型デプロイメントが追加されたことが示されています。(Microsoft Learn)
| 観点 | 2026年4月更新で押さえること | 実務上の意味 |
|---|---|---|
| 外部SAN対応 | SANストレージをAzure Localに接続して利用可能 | 既存SAN資産を活かしながらAzure Localへ移行しやすい |
| S2Dとの関係 | Storage Spaces Directと外部SANをワークロードごとに選択可能 | すべてを同じストレージ方式に寄せる必要がない |
| 対応構成 | FCベースSAN接続とDell PowerFlexがGAとして整理 | PoCだけでなく本番導入計画に載せやすい |
| 分離型デプロイメント | SANストレージのみの構成が選択肢に追加 | コンピュートとストレージを別々に拡張しやすい |
| 注意点 | ラック認識クラスターなど未対応構成がある | 既存の可用性設計をそのまま流用できるとは限らない |
この更新は、特に次のような組織に向いています。
- 既存のエンタープライズSANを償却途中で、Azure Local移行時にも活用したい
- VM、AKS、AVDなど複数のワークロードでストレージ階層を分けたい
- Storage Spaces Directだけではなく、FC SANやDell PowerFlexを含めた設計にしたい
- 拠点・工場・データセンターでAzureの管理プレーンを使いつつ、データはローカルに置きたい
Azure Localの外部ストレージ対応とは
Azure Localの外部ストレージ対応では、外部のStorage Area Network、つまりSANをAzure Localノードに接続し、VMやAKSクラスター、Azure Virtual Desktopインスタンス向けのブロックストレージとして利用できます。Microsoft Learnでは、複数のSANボリュームをAzure Localノード上のCluster Shared Volumes、CSVとして提示し、各CSVをVM用のStorage Pathにマッピングできると説明されています。(Microsoft Learn)
ここで重要なのは、「外部ストレージ」といってもUSBディスクやNAS共有を追加する話ではないという点です。対象は、Fibre Channel SANやDell PowerFlexのようなエンタープライズ向けブロックストレージです。
できること
Azure LocalのExternal storage supportでできることは、主に次の3つです。
| できること | 説明 |
|---|---|
| 既存SANの活用 | 既存または新規のSANアレイをAzure Localのワークロード用ストレージとして使う |
| S2Dとの使い分け | Storage Spaces Directと外部SANを並行利用し、ワークロードごとに選択する |
| CSV経由の利用 | SANボリュームをCluster Shared Volumesとして扱い、Azure Local VMなどのStorage Pathに割り当てる |
たとえば、一般的な業務VMはStorage Spaces Direct、低レイテンシーが求められるデータベース系VMはFC SAN、拡張性を重視する基盤はDell PowerFlex、というように分けて設計できます。
誤解しやすいポイント
外部ストレージ対応は便利ですが、導入時に誤解しやすい点があります。
| 誤解 | 正しい理解 |
|---|---|
| どのSANでもそのまま使える | 対応構成、HBA、ドライバー、ファームウェア、ベンダー手順の確認が必要 |
| Azure Local導入前にSANを先に見せればよい | FC HBAのWWNゾーニングはAzure Localデプロイ後に行う必要がある |
| 接続すれば自動で使える | MPIO設定、ディスク検出、初期化、NTFSフォーマット、CSV追加、Storage Path作成が必要 |
| S2Dが不要になる | S2Dと外部SANは用途に応じて使い分ける選択肢 |
| ラック認識構成でもそのまま使える | 外部SANストレージを使うハイパーコンバージド構成ではラック認識クラスターはサポートされない |
対応構成はFibre Channel SANとDell PowerFlexが中心
Azure Localの外部ストレージ対応で中心になるのは、Fibre ChannelベースのSANアレイとDell PowerFlexです。Microsoft Learnでは、FC SANの場合、各Azure LocalノードがFabric AとFabric Bの二重FCファブリックに接続し、HBAを使って冗長性と高スループットを確保する構成が説明されています。接続後のSAN-backed volumesはNTFSでフォーマットされたCSVとして統合されます。(Microsoft Learn)
| 構成 | 特徴 | 向いているケース |
|---|---|---|
| Fibre Channel SAN | 既存のFCファブリック、HBA、SANアレイを活用する構成 | 既存SAN運用が成熟しており、低レイテンシーI/Oを重視する環境 |
| Dell PowerFlex | PowerFlex SDCドライバーを各Azure Localノードに導入し、リモートブロックボリュームを利用 | ソフトウェア定義ストレージで拡張性と一貫した性能を重視する環境 |
| Storage Spaces Direct | Azure Local標準のインボックスストレージ | ローカルディスク中心でシンプルに構成したい環境 |
| 分離型デプロイメント | SANストレージのみを使い、コンピュートとストレージを分ける構成 | ストレージ容量とコンピュート能力を別々に拡張したい環境 |
Dell PowerFlexについては、リモートブロックボリュームをAzure Localノードに直接マウントし、VM、AKS pods、AVDインスタンスからローカルストレージのように利用できるとされています。サポート構成は4〜512のPowerFlexノード、3〜16のAzure Localホストに対応し、専用SDSネットワーク、MTU 9014のジャンボフレーム、NICボンディングやチーミングも説明されています。(Microsoft Learn)
導入前に確認すべき実務チェックリスト
External storage support for Azure Localを検討する場合、最初に見るべきなのは機能説明ではなく、既存環境が前提条件を満たせるかです。Microsoft Learnの接続手順では、Azure Localクラスターが2604以降であること、全クラスターNodeにWindows Server 2025認定のFC HBAとドライバーが入っていること、SANアレイがFCファブリック上でアクセス可能で管理アクセスが構成されていることが前提条件として示されています。(Microsoft Learn)
| 確認項目 | 見るべきポイント | 不備がある場合のリスク |
|---|---|---|
| Azure Localのバージョン | 2604以降か、更新パスは適切か | 外部SAN接続手順の前提を満たせない |
| OS・ドライバー | OSビルド26100.32690またはWindows Server 2025対応ドライバーか | HBAやMPIOが正常に動作しない |
| FC HBA | 全ノードに搭載され、ファームウェアとドライバーが揃っているか | ノードごとにLUNの見え方が変わる |
| FCファブリック | Fabric A/Bなど冗長構成を設計しているか | 片系障害でI/O停止につながる |
| ゾーニング | Azure Localデプロイ後にWWNをゾーニングする手順か | デプロイ時にFC LUNが見えて混乱する可能性がある |
| LUNマスキング | すべてのクラスターNodeに同じLUNを提示するか | Test-Cluster失敗やCSV追加失敗の原因になる |
| MPIO | Multipath-IO有効化、MSDSM登録、ポリシー設定、再起動を実施するか | 複数パスを正しく利用できない |
| Storage Path | CSVパスをAzure portalでStorage Pathとして登録するか | VM作成時にSAN-backed領域を選べない |
特に注意したいのは、FC HBAのWWNをAzure Localデプロイ前にゾーニングしないことです。Microsoft Learnでも、FC LUNによるデプロイ混乱を避けるため、WWNのゾーニングはAzure Localデプロイ後に行うよう明記されています。(Microsoft Learn)
実装の流れ: 管理者が押さえる作業順
実装作業は、SANチーム、仮想化チーム、ネットワークチーム、Azure管理者の連携が必要です。手順を分けると、次の流れになります。
| 手順 | 作業 | 補足 |
|---|---|---|
| 1 | Azure Local 2604以降の環境を準備 | 既存環境は更新計画を先に確認 |
| 2 | 各ノードにFC HBAと対応ドライバーを導入 | ファームウェア差分も揃える |
| 3 | Azure Localをデプロイ | この時点ではFC LUNを見せない |
| 4 | FCファブリックでゾーニングを実施 | Azure Localデプロイ後にWWNを登録 |
| 5 | MPIOを有効化してベンダー別設定を適用 | 設定後の再起動をローリングで実施 |
| 6 | SAN側でLUNを作成し、全ノードに提示 | サイズ、LUN数、見え方を全ノードで統一 |
| 7 | 各ノードでディスクを再スキャン | Update-HostStorageCacheで確認 |
| 8 | 1ノードでディスク初期化とNTFSフォーマット | CSVとして使う前提で作業 |
| 9 | Test-Clusterで検証 | 重大なエラーがある場合は進めない |
| 10 | CSVへ追加し、Azure portalでStorage Pathを作成 | VMやワークロードから利用可能にする |
Microsoft Learnの手順では、MPIOの有効化に Add-WindowsFeature -Name 'Multipath-IO' -IncludeManagementTools、ディスク再スキャンに Update-HostStorageCache、クラスター検証に Test-Cluster、CSV追加に Get-ClusterAvailableDisk | Add-ClusterDisk | Add-ClusterSharedVolume が使われています。(Microsoft Learn)
Add-WindowsFeature -Name 'Multipath-IO' -IncludeManagementTools
Update-HostStorageCache
Get-Disk
Test-Cluster
Get-ClusterAvailableDisk | Add-ClusterDisk | Add-ClusterSharedVolumeコマンド自体は短いですが、実際の成否は事前設計で決まります。特に、全ノードから同じディスクが同じ状態で見えるか、MPIOが正しくディスクをclaimしているか、CSVパスがAzure portalで指定できる状態になっているかを確認してください。
どのワークロードで使うべきか
Azure Localの外部SAN対応は、すべてのワークロードに一律で適用するものではありません。Storage Spaces Direct、FC SAN、Dell PowerFlex、分離型デプロイメントを使い分けることで効果が出ます。
| ワークロード | 推奨しやすい選択肢 | 判断基準 |
|---|---|---|
| 一般的な業務VM | S2Dまたは外部SAN | 運用のシンプルさを優先するならS2D、既存SAN統合を優先するなら外部SAN |
| 高I/OのデータベースVM | FC SANまたはDell PowerFlex | 低レイテンシー、冗長パス、既存SAN運用を活かせるか |
| AKS on Azure Local | 外部SANまたはPowerFlex | コンテナ基盤で安定したブロックストレージが必要か |
| Azure Virtual Desktop | 外部SANまたはS2D | ユーザープロファイルやセッションホストのI/O特性を見て判断 |
| 拠点・エッジ環境 | S2Dまたは分離型デプロイメント | 機器点数、運用者のスキル、拡張予定で判断 |
| 大規模・段階拡張 | 分離型デプロイメント | コンピュートとストレージを別々に増やしたいか |
プロダクトオーナーやIT企画担当者は、「SANが使えるか」だけでなく、誰がどこまで運用するかを決める必要があります。SANチームがLUN作成・ゾーニング・ファブリック管理を担い、Azure Local管理者がCSV・Storage Path・VM作成を担う場合、障害時の一次切り分け手順を事前に文書化しておくべきです。
よくある失敗と回避策
外部ストレージ対応で失敗しやすいのは、Azure側の操作よりも、SAN接続とクラスター前提の不整合です。
| 失敗しやすいポイント | 起きる問題 | 回避策 |
|---|---|---|
| Azure Localデプロイ前にLUNを見せる | デプロイ時に想定外のディスクとして認識される | WWNゾーニングはデプロイ後に実施 |
| ノードごとに見えるLUNが違う | Test-Clusterでエラー、CSV追加に失敗 | LUNマスキングを全ノードで統一 |
| MPIO設定後に再起動していない | パス制御が正しく反映されない | ローリング再起動を計画に入れる |
| ベンダー別MSDSM設定を省略する | MPIOがディスクを正しくclaimしない | ストレージベンダーごとの手順を確認 |
| CSVではないパスをStorage Pathに指定 | Azure portalでStorage Path作成に失敗 | C:\ClusterStorage\... 配下の有効なCSVパスを指定 |
| Test-Clusterの警告やエラーを無視する | 本番稼働後にフェールオーバーやI/Oで問題化 | 重大な問題を解消してからCSV追加 |
| ラック認識クラスターで使おうとする | サポート対象外構成になる | 外部SANを使う構成では対応可否を事前確認 |
Microsoft Learnのトラブルシューティングでも、ディスクが見えない場合はFCゾーニング、LUNマスキング、HBAドライバー、FCポート状態を確認すること、MPIOがclaimしない場合はMSDSM登録や複数アクティブパスを確認することが案内されています。(Microsoft Learn)
2026年4月更新であわせて確認したいAzure Local 2604項目
外部ストレージだけを見て導入判断をすると、更新後に別の制約で止まることがあります。Azure Local 2604では、外部SAN以外にもOS、ドライバー、AKS、更新管理に関わる変更があります。
Azure Local 2604では、新規および既存デプロイメントがOSバージョン26100.32690で動作し、このOSまたはWindows Server 2025に対応するドライバーが必要です。また、AKS enabled by Azure ArcではサポートされるKubernetesバージョンが明示され、Kubernetes 1.30はサポート対象外とされています。AKSクラスターを併用する場合は、Azure Local更新前にKubernetesバージョンも確認してください。(Microsoft Learn)
特に既存環境では、Azure Localのサポート期間にも注意が必要です。Microsoft Learnでは、Azure Localは更新されないまま6か月を超えるとサポート対象外になること、OS version 23H2は2026年4月にサポート終了へ向かうことが示されています。(Microsoft Learn)
導入判断の結論
External storage support for Azure Localは、既存SANを持つ企業にとって、Azure Localの導入コストと移行リスクを下げる有力な選択肢です。特に、FC SANやDell PowerFlexをすでに運用している組織では、S2Dだけに寄せるよりも、ワークロードごとにストレージを選ぶ設計が現実的になります。
一方で、導入の成否は「SANを接続できるか」ではなく、「サポート構成として運用できるか」で決まります。Azure Local 2604以降であること、対応HBAとドライバーを揃えること、FCゾーニングを適切なタイミングで行うこと、MPIOとCSVを正しく構成すること、そしてStorage PathとしてAzure portalに登録できることを確認してください。
次に取るべき行動は、既存SANの棚卸しです。対象ワークロード、必要容量、I/O要件、利用中のHBA、ファームウェア、ドライバー、FCスイッチ、LUNマスキング方針を整理し、Azure Local 2604以降の対応条件と照合しましょう。そのうえで、小さな検証用LUNを使ってMPIO、CSV、Storage Path、VM作成までを通しで確認するのが、安全な導入ステップです。
コメント