Azure Local + External SAN: The Architecture That Actually Matters

Azure Local is evolving into one of Microsoft’s most adaptable hybrid platforms. With external SAN support now fully in play — Fibre Channel generally available and iSCSI in preview — the design conversation has shifted again. This is especially true for organisations running disaggregated environments or those with existing SAN estates they want to keep using.

If you’re planning an Azure Local deployment or advising someone who is, these are the high‑level points that genuinely matter.

1. Azure Local finally supports true disaggregated architectures

Disaggregated means compute‑only nodes paired with external SAN storage.

This isn’t a half‑way “S2D plus SAN” model. It’s SAN‑only, with Azure Local treating external LUNs as first‑class Cluster Shared Volumes.

Key things to know:

• You choose Storage Area Network during deployment — S2D isn’t part of the design.
• Rack‑aware clustering isn’t supported in this mode at the time of writing (expected to come later).
• Deployment requires two SAN LUNs up front:
  • Infrastructure volume (≥250 GB)
  • Cluster performance history volume (≥20 GB)
• Workload LUNs come later, once the cluster is online.

2. External SAN support is genuinely enterprise‑grade

Azure Local integrates with SAN arrays over Fibre Channel (GA) or iSCSI (preview). Supported vendors include Dell PowerStore, Pure FlashArray, NetApp ONTAP, HPE Alletra/3PAR, Hitachi VSP, and Lenovo DM/DS/DG.

Why this matters:

• Protects existing SAN investments
• Keeps familiar zoning, masking, and LUN workflows
• Delivers FC‑class performance
• Lets you run hybrid designs (S2D + SAN) or full SAN‑only deployments

3. SAN LUNs become CSVs — and Azure Local manages them like native storage

Once your LUNs are zoned/masked, visible on all nodes, claimed by MPIO, and formatted NTFS (64K AU), Azure Local:

• Adds them to the cluster
• Converts them to CSVs
• Exposes them as Storage Paths for VM placement

The result is multi‑node access, Azure‑consistent VM lifecycle management, and clean separation of compute and storage scaling.

4. MPIO isn’t optional — and the defaults are already tuned

Azure Local 2604+ ships with:

• MPIO enabled
• Round Robin load balancing
• Vendor‑appropriate timers

Overrides exist for arrays like PowerStore and Pure, but the out‑of‑box configuration is solid.

5. iSCSI requires dedicated NICs — no converged designs

If you’re using iSCSI, the storage network must be physically isolated:

• NICs cannot be part of Network ATC intents
• No vNICs
• No default gateway
• Static /32 routes to each target portal
• Jumbo frames and QoS tagging optional

This is not a converged RDMA design — it’s a dedicated storage fabric.

6. Deployment through the Azure Portal is far cleaner now

The disaggregated deployment wizard handles:

• Machine validation
• Extension installation
• Key Vault creation
• Network intent configuration
• SAN‑only storage selection
• Managed identity authentication

Validation is strict — NICs, OS versions, and extension versions must match.

7. After deployment, you add workload volumes and storage paths

Once the cluster is running:

• Create workload LUNs
• Present them to all nodes
• Add them as CSVs
• Register each CSV path in Azure Local
• Start placing VMs on SAN‑backed storage

This is where disaggregated designs shine: compute and storage scale independently.

8. This is the architecture enterprises have been waiting for

Azure Local + external SAN delivers:

• A hybrid cloud control plane
• Enterprise‑grade SAN performance
• Disaggregated scaling
• Azure‑consistent VM lifecycle
• Vendor flexibility
• Familiar operational workflows for storage teams

It’s the closest thing yet to running “Azure on your SAN.”