Azure Elastic SAN

解決する課題

ディスクを VM ごとに個別プロビジョニングすると、台数が増えるほど容量・性能の見積もりと管理が煩雑になります。Azure Elastic SAN は、容量と性能を一つの SAN リソースにプールし、そこから複数のサーバーへ iSCSI でボリュームを切り出して供給します。オンプレミスの SAN アプライアンスをクラウドのマネージドサービスに置き換えるイメージです。

• 多数の VM / クラスタへ 共有のブロックストレージ基盤をまとめて供給したい
• ディスクを個別に管理せず、プール単位で容量と性能を集中管理したい
• オンプレの SAN（iSCSI）からのリフト＆シフトで接続方式を変えたくない
• AKS や複数ノードの DB クラスタなど、同じボリュームを複数ノードから使う用途がある

主要概念と用語

• Elastic SAN リソース: 容量と性能（IOPS / スループット）をプールする最上位の単位。ここでスケールを決める
• ベース容量 / 追加容量: 容量は性能込みの「ベース容量」と、容量だけを足す「追加容量」に分かれる。性能はベース容量に比例して増える
• ボリュームグループ: ボリュームをまとめる管理単位。ネットワーク設定（プライベートエンドポイント / サービスエンドポイント）や暗号化キーをここで設定
• ボリューム: 実際にサーバーへ提示される iSCSI のブロックデバイス。ターゲット IQN を持つ
• iSCSI: TCP/IP 上でブロック I/O を運ぶプロトコル。各ボリュームが iSCSI ターゲットとなり、VM 側のイニシエーターから接続する
• 複数セッション接続: 1 ボリュームへ複数の iSCSI セッションを張り、帯域とフェイルオーバー性を高める構成

仕様・制限・クォータ

• 性能（IOPS / スループット）は ベース容量に連動して増減する。容量だけを足したい場合は追加容量を使う
• ボリュームの性能は SAN 全体のプールを共有するため、特定ボリュームへ偏ると他に影響しうる
• 接続は iSCSI 経由。VM 側で iSCSI イニシエーターの設定が必要（Managed Disks のような直接アタッチではない）
• 1 つの Elastic SAN 内に複数の ボリュームグループ、その下に複数の ボリュームを作成できる（個数には上限がある）
• 冗長性は LRS（ローカル冗長） と ZRS（ゾーン冗長） を選択でき、リージョンやゾーンの対応状況に依存する
• サブスクリプション/リージョンごとに作成可能な SAN 数やプール容量の クォータがあり、引き上げ申請ができる

内部の仕組み

Elastic SAN は、Azure 側で冗長化されたブロックストレージのプールを 1 つのリソースとして抽象化したものです。利用者はプールに対して容量を指定し、そこからボリュームグループ→ボリュームと階層を切り出します。各ボリュームは iSCSI ターゲットとして公開され、VM やコンテナのイニシエーターが TCP/IP で接続してブロックデバイスとしてマウントします。

性能は個々のボリュームに固定で割り当てるのではなく、SAN 全体のプール性能を共有する設計です。ベース容量を増やすとプール全体の IOPS / スループット上限が上がり、その範囲内で各ボリュームが I/O を消費します。これにより、台数が増えても個別ディスクごとに性能階層を選ぶ手間が減ります。

冗長性はプール単位で LRS（同一データセンター内で複製） または ZRS（複数の可用性ゾーンへ同期複製） を選べます。ZRS はゾーン障害に強い一方、書き込みレイテンシが増える場合があります。ネットワーク経路はボリュームグループ単位で制御し、プライベートエンドポイントやサービスエンドポイントで閉域化します。

設計パターン / ベストプラクティス

• 多数の VM・クラスタへ供給する 共有ブロック基盤として使い、単発の永続ディスクは Managed Disks に分ける
• 性能はプール共有なので、ベース容量を性能要件から逆算してプロビジョニングする（容量が余っても性能のために確保するケースがある）
• ボリュームグループを ワークロード/テナント単位で分け、ネットワークと暗号化キーを分離する
• 高スループットが必要なボリュームは 複数 iSCSI セッションで接続し、帯域を引き出す
• ゾーン障害に備えるなら ZRS を選ぶ。レイテンシ要件と冗長性のトレードオフを評価する
• AKS から使う場合は対応する CSI ドライバー経由でボリュームを接続し、ノード障害時の再アタッチ手順を確認する

運用・監視

• Azure Monitor のメトリクスで SAN / ボリュームグループ / ボリューム各層の IOPS・スループット・使用容量を監視する
• プール性能の上限に近づいたら ベース容量を引き上げて性能を底上げする。容量だけ不足なら追加容量を足す
• 特定ボリュームへの I/O 偏りがプール全体に影響していないかを確認し、必要ならボリュームグループを分離する
• iSCSI セッションの切断・再接続を監視し、複数セッション構成でフェイルオーバーが効くかを定期確認する

コスト

課金は主に プロビジョニングしたプール容量に対して発生し、ベース容量には性能ぶんが含まれます。容量だけを足す追加容量は性能を伴わないため単価が異なります。VM を停止してもプールを確保している限り課金は継続します。

• 性能要件に対して ベース容量を過剰確保しない。容量が目的なら追加容量を使い分ける
• 使わなくなったボリューム/ボリュームグループを整理し、プールサイズを実需に合わせる
• 多数の小容量ディスクを個別に持つより、プール集約で見積もりと無駄が減るケースを評価する

セキュリティ

• 保存時は サーバー側暗号化（既定のプラットフォームマネージドキー） が有効。要件に応じて カスタマー管理キー（CMK） をボリュームグループ単位で設定できる
• 暗号鍵は Azure Key Vault で管理し、ローテーションを運用する
• ネットワークは プライベートエンドポイントでプライベート IP 接続にし、パブリック経路を閉じる。サービスエンドポイントでサブネットを限定する方式もある
• 管理操作は Microsoft Entra ID + RBAC で最小権限に制御する
• iSCSI 接続は閉域ネットワーク内に閉じ、イニシエーター側のアクセス範囲を絞る

関連サービス・比較

単一 VM の永続ディスクを担う Azure Managed Disks と、位置づけを比較します。

ハンズオン / CLI例

# リソースグループを作成
az group create --name demo-rg --location japaneast

# Elastic SAN を作成（ベース容量と追加容量、冗長性を指定）
az elastic-san create \
  --resource-group demo-rg \
  --name demo-san \
  --location japaneast \
  --base-size-tib 1 \
  --extended-capacity-size-tib 1 \
  --sku '{name:Premium_LRS}'

# ボリュームグループを作成
az elastic-san volume-group create \
  --resource-group demo-rg \
  --elastic-san-name demo-san \
  --name demo-vg

# ボリュームを作成（このボリュームが iSCSI ターゲットになる）
az elastic-san volume create \
  --resource-group demo-rg \
  --elastic-san-name demo-san \
  --volume-group-name demo-vg \
  --name demo-vol \
  --size-gib 100

# 接続用の iSCSI ターゲット情報（IQN など）を確認
az elastic-san volume show \
  --resource-group demo-rg \
  --elastic-san-name demo-san \
  --volume-group-name demo-vg \
  --name demo-vol