Azure NetApp Files（ANF）を本番で使っていると、「このボリュームだけ Premium にしたい」「新しく出てきた Flexible プールへ寄せたい」といった要望が必ず出てきます。本記事では、Azure ポータルではなく Azure CLI を使ってボリュームを別容量プールへ移動する方法と、従来の Standard / Premium / Ultra プールから Flexible プールへ安全に移行する手順を、実運用を意識した観点で整理します。
Azure NetApp Files の構造と容量プール変更のイメージ
まずは前提となる ANF のストレージ階層を軽く整理しておきます。Azure NetApp Files は大まかに次の三層構造です。
| レイヤー | 主な役割 | 代表的な制約 |
|---|---|---|
| Azure サブスクリプション | 課金・RBAC の管理単位 | ANF リソースの「移行（migrate）」はサブスクリプションをまたいでサポートされない |
| NetApp アカウント | 容量プールの論理的なコンテナ（リージョン単位） | NetApp アカウント間で容量プールを移動することは不可 |
| 容量プール（Capacity Pool） | サービス レベルと QoS タイプを持つ「容量の箱」 | 1プールにつき 1 つのサービス レベルのみ / 1 つの NetApp アカウントにのみ所属 |
| ボリューム | 実際に NFS / SMB でマウントされるファイル共有 | 1つのボリュームは必ず 1 つの容量プールに所属 |
このうち、ボリュームを別の容量プールへ「動かす」操作が、Azure ポータルの「プールの変更（Change pool）」および Azure CLI の az netappfiles volume pool-change に相当します。
Azure CLI で容量プール変更は可能か？
結論から言うと、Azure CLI で ANF ボリュームを別容量プールへ移動することは可能です。
- コマンド：
az netappfiles volume pool-change（コア CLI に含まれる GA コマンド） - 用途：同一 NetApp アカウント内でボリュームを別容量プールへ移動し、結果としてサービス レベルを変更（Standard ⇔ Premium ⇔ Ultra 等）
- 動作：データの再コピーは行われず、オンラインなままサービス レベルを変更できる（原則として I/O 停止なし）
Microsoft Q&A でも、同コマンドでの容量プール変更が公式に案内されています。
| 項目 | 要件 / 挙動 |
|---|---|
| 移動先プール | 事前に作成済みである必要あり（サイズ・サービス レベル・QoS タイプ・暗号化種別を考慮） |
| アカウント | 同一 NetApp アカウント内のみ移動可能（アカウントをまたぐ移動は不可） |
| リージョン | NetApp アカウントはリージョン単位のため、結果として同一リージョン内の移動のみとなる |
| データ プレーン影響 | 設計上は I/O 継続のままサービス レベルを変更可能。とはいえ、重要ワークロードではメンテナンス枠での実行推奨 |
| Flexible との関係 | 後述の通り、Flexible プールだけはボリュームの移動が禁止されており、pool-change の対象外 |
CLI での容量プール変更手順（Standard / Premium / Ultra 向け）
ここでは、従来プール（Standard / Premium / Ultra / StandardZRS）間でボリュームを移動する手順を CLI ベースで整理します。
1. 前提条件の確認
- 最新の Azure CLI を使用している（
az upgradeまたはクラウドシェルを利用）。 - 実行ユーザーは対象リソース グループ／NetApp アカウントに対する Contributor 以上の権限を持つ。
- 移動先プールに、対象ボリュームのプロビジョニング容量＋スナップショット分の空き容量がある。
- 暗号化種別（Single / Double）やネットワーク機能（Basic / Standard）が互換である。特に暗号化種別が異なるプールへの変更はサポートされません。
2. 容量プール一覧の取得
az netappfiles pool list \
--resource-group MY_RESOURCE_GROUP \
--account-name MY_ANF_ACCOUNT \
-o table
ここで、各プールの serviceLevel（Standard / Premium / Ultra / Flexible など）と size、qosType を確認しておきます。
3. 移動先プールのリソース ID を取得
az netappfiles pool show \
--resource-group MY_RESOURCE_GROUP \
--account-name MY_ANF_ACCOUNT \
--name MY_TARGET_POOL \
--query id -o tsv
出力された値（例：/subscriptions/.../netAppAccounts/.../capacityPools/MY_TARGET_POOL）を控え、NEW_POOL_ID と呼ぶことにします。
4. ボリュームを別プールへ移動
az netappfiles volume pool-change \
--resource-group MY_RESOURCE_GROUP \
--account-name MY_ANF_ACCOUNT \
--pool-name MY_CURRENT_POOL \
--name MY_VOLUME \
--new-pool-resource-id "NEW_POOL_ID"
--pool-name は「現在の」容量プール名である点に注意してください。
バックグラウンドでプール変更が実行されます。大容量ボリュームでは数分程度かかることがあります。
5. 完了確認
az netappfiles volume show \
--resource-group MY_RESOURCE_GROUP \
--account-name MY_ANF_ACCOUNT \
--pool-name MY_TARGET_POOL \
--name MY_VOLUME \
--query "{state:provisioningState, pool:id}" -o json
provisioningState が Succeeded となり、pool が新しいプール ID になっていれば完了です。
なお、プール変更後は 過去のボリューム メトリックやアクティビティ ログは引き継がれず、新しいプール側で新規に計測が開始される点にも注意してください。
よくあるエラーと対処法
公式のトラブルシューティングでは、容量プール変更時の代表的なエラーと対処方法が整理されています。 以下に CLI 利用時に遭遇しやすい内容だけ抜粋した一覧を載せます。
| エラー例 | 原因 | 対処 |
|---|---|---|
| Capacity pool size is too small for total volume size | 移動先プールの空き容量が不足 | プールサイズを拡張するか、より大きいプールを選択して再実行 |
| Pool not available or does not exist | 移動先プールが Succeeded 状態でない / 削除済み | プールの状態を確認し、必要ならタグ追加など軽微な更新を行って状態を復旧 |
| Volume with same name already exists in target pool | 同名ボリュームがすでに移動先プールに存在 | 別のプールを選ぶか、重複ボリュームをリネーム・削除 |
| Cannot change the volume’s pool because the destination pool uses different encryption type | Single / Double 暗号化種別が不一致 | 暗号化種別の同じプールを新規作成し、そちらへ移動 |
Flexible サービスレベルとは？特徴と注意点
Flexible は、従来の Standard / Premium / Ultra と異なり、容量とスループットを独立して調整できる新しいサービス レベルです。
- 対象：新規に作成する Manual QoS の容量プール のみで利用可能（Auto QoS では利用不可）
- スループット：プール全体の最大スループットは
5 × 128 MiB/s × プールサイズ（TiB） - 各ボリュームごとにスループットを個別指定（Manual QoS の特徴）
- Azure Portal / CLI から、プールのスループット値（例：128〜2560 MiB/s）を後から増減可能（減速は 24 時間のクールダウン後）
サービス レベルごとのざっくりした特徴をまとめると次のようになります。
| サービス レベル | 最大スループット/TiB（Auto QoS 時） | 主な用途イメージ |
|---|---|---|
| Standard | ～16 MiB/s | 汎用ファイル共有、開発環境 |
| Premium | ～64 MiB/s | VDI、ミドルレンジ DB |
| Ultra | ～128 MiB/s | 高 IOPS / 低レイテンシが求められる DB |
| Flexible（Manual QoS） | プールサイズと設定スループットに依存（最大は 5 × 128MiB/s × プールサイズ） | SAP HANA / Oracle など、容量とスループットを個別に最適化したいワークロード |
Flexible プールの「動かせない」制約
Flexible プールでは、サービスの設計上、次のような制約が明示されています。
- 既存の容量プールを Flexible に変換することはできない（逆方向も不可）。
- Flexible サービスレベルの容量プールに属するボリュームは、他の容量プールへ移動できない。
- 他の容量プール（Standard / Premium / Ultra 等）から Flexible サービスレベルの容量プールへ、ボリュームを移動することもできない。
つまり、Flexible プールは「ボリュームの pool-change がそもそも許可されない閉じた世界」と理解しておくと安全です。このため、従来プールから Flexible へ切り替えたい場合は、新しい Flexible プールを作成し、データを移行する、というパターン一択になります。Microsoft Q&A の回答でも同様の方針が示されています。
従来プールから Flexible プールへの安全な移行戦略
ここからは、Standard / Premium / Ultra プール上の既存ボリュームを、データ損失なく Flexible プールへ移行するための実践的な手順を整理します。
全体フローのイメージ
- 新しい Flexible 容量プールを作成する（Manual QoS）。
- Flexible プール上に新ボリューム（または一時ボリューム）を作成する。
- 従来ボリュームから新ボリュームへデータを同期する（rsync / robocopy / DB レプリケーション等）。
- 最終差分同期を実行し、短時間のダウンタイムでマウント先を切り替える。
- 旧ボリューム／旧プールを段階的に削除し、コスト最適化する。
| 移行方式 | 対象プロトコル | ダウンタイム | メリット | 注意点 |
|---|---|---|---|---|
| rsync によるファイル コピー | NFS | 短時間（最終差分同期＋マウント切替） | Linux だけで完結しやすく、制御が容易 | 大量小ファイルでは初回同期に時間がかかる |
| robocopy によるミラーリング | SMB | 短時間 | ACL やタイムスタンプを保持しやすい | コマンド オプションを誤ると意図しない削除が発生しうる |
| スナップショットからのボリューム作成 | NFS / SMB | 最小限（差分同期のみ） | コピー量を大きく削減できる | Flexible プール側でのサポート状況や制限を事前確認 |
| アプリケーション レベル レプリケーション | DB / DWH 等 | 数秒〜数分レベルに抑制可能 | アプリ側で一貫性のある切替を実現 | 構成が複雑になりがちで、検証が必須 |
Step 1: Flexible 容量プールの作成（CLI）
Flexible プールは、Manual QoS かつ service-level=Flexible で作成します。必要に応じて --custom-throughput-mibps でプール全体の最大スループットを指定します。
az netappfiles pool create \
--resource-group MY_RESOURCE_GROUP \
--account-name MY_ANF_ACCOUNT \
--name MY_FLEX_POOL \
--location japan-east \
--service-level Flexible \
--qos-type Manual \
--size 4 \
--custom-throughput-mibps 1280
--size：容量プールのサイズ（TiB 単位）。4 TiB 以上・1 TiB きざみが推奨です。--custom-throughput-mibps：Flexible プール全体の最大スループット。プールサイズと前述の「5 × 128MiB/s × TiB」上限を超えない値に設定します。
Step 2: Flexible プール上に新ボリュームを作成
次に、同一 VNet／サブネット上に新ボリュームを作成します。ここでは NFS ボリュームの例を示します。
az netappfiles volume create \
--resource-group MY_RESOURCE_GROUP \
--account-name MY_ANF_ACCOUNT \
--pool-name MY_FLEX_POOL \
--name MY_NEW_VOLUME \
--location japan-east \
--file-path my-new-share \
--usage-threshold 1024 \
--vnet my-vnet \
--subnet my-anf-delegated-subnet \
--protocol-types NFSv4.1 \
--throughput-mibps 256
usage-threshold：ボリューム容量（GiB）。プール容量の範囲内で設定。throughput-mibps：Manual QoS のため、各ボリュームごとにスループットを指定可能（プール全体の上限の範囲内）。
Step 3: データ同期（rsync / robocopy / スナップショット）
NFS の場合：rsync を使った段階同期
Linux クライアントから旧ボリュームと新ボリュームを両方マウントし、複数回の rsync で事前同期 → 最終同期を行うのが王道です。
# 初回フル同期
rsync -avxHAXS \
--numeric-ids \
/mnt/old_anf_volume/ \
/mnt/new_anf_flex_volume/
# 切替前の最終差分同期（サービス停止後）
rsync -avxHAXS \
--numeric-ids --delete \
/mnt/old_anf_volume/ \
/mnt/new_anf_flex_volume/
-x：別ファイルシステムへ跨らない（意図せぬ領域コピーを防止）。-HAXS：ハードリンク／ACL／拡張属性／スパースファイルを維持。--numeric-ids：UID/GID の数値をそのままコピー（NIS や AD 連携環境で有効）。--delete：最終同期時に削除差分も反映し、ミラー状態に揃える。
SMB の場合：robocopy によるミラーリング
Windows ファイルサーバや VDI プロファイルのような SMB ワークロードでは、robocopy を使ったミラーリングが定番です。
robocopy \\old-anf\share \\new-anf-flex\share `
/MIR /COPY:DATS /DCOPY:T /R:1 /W:1 /MT:16 /LOG:C:\logs\anf-migration.log
/MIR：ミラーリング（削除も反映）。/COPY:DATS：データ・属性・タイムスタンプ・セキュリティ（ACL）をコピー。/DCOPY:T：ディレクトリのタイムスタンプを保持。/MT:16：並列コピーでスループットを引き上げ（環境に応じて調整）。
スナップショットを活用した高速移行
ワークロードによっては、既存ボリュームのスナップショットから新しいボリュームを作成し、その後に差分同期だけを行うことでコピー量を大幅に削減できる場合があります。ANF ではスナップショットからのボリューム作成がサポートされており、同一アカウント／リージョン内での運用が前提となります。
ただし Flexible プール固有の制約や、API バージョンによる挙動の違いがあり得るため、本番前に検証環境で手順を検証し、必要に応じて Microsoft サポートの最新ドキュメントを確認してください。
データベースのネイティブ レプリケーション
Oracle、SQL Server、SAP HANA などのデータベースでは、ストレージ コピーに頼らず、DB のネイティブ レプリケーション（Data Guard、Always On、HANA System Replication 等）を使って Flexbile プール側にセカンダリを作り、最終的にフェールオーバーするパターンも有力です。
- ディスク I/O の一貫性やトランザクション整合性をアプリ側で担保できる。
- 十分な帯域と CPU リソースがあれば、ダウンタイムを数秒〜数分まで圧縮可能。
- 構成が複雑になりやすいため、DR テストと同レベルの検証が必須。
Step 4: アプリケーション切替
データ同期が完了したら、あとは マウント先を切り替えるだけです。
- NFS：
/etc/fstabやマウント スクリプトのエクスポートパスを、旧ボリュームから新ボリュームに変更し、マウントし直す。 - SMB：ファイルサーバの共有フォルダ パスを変更するか、新しい共有名を DNS エイリアスでマッピングする。
- DB：新ストレージ上のボリュームで DB を起動し、アプリケーション接続先を更新する。
切替直後は、Flexible プール固有のスループット特性が期待通りかどうか、待ち時間・IOPS・スループットをメトリックで必ず確認しておきましょう。
Step 5: 後片付け（コスト最適化）
- 旧ボリュームを一定期間「読み取り専用」にしておき、想定外アクセスがないことを確認後に削除。
- 旧容量プールのサイズを縮小したり、プール自体を削除してコストを削減。
- 監査ログや CMDB 上のドキュメントを更新して、どのワークロードが Flexible に移行済みかを明確にする。
CLI を使うときの互換性チェックリスト
ここまでの内容を踏まえて、az netappfiles volume pool-change や Flexible への移行前にチェックすべきポイントを一覧にしておきます。
| 観点 | チェック内容 |
|---|---|
| アカウント / リージョン | 同一 NetApp アカウント内・同一リージョン内である（アカウント間・サブスクリプション間移動は不可）。 |
| サービス レベル | Standard / Premium / Ultra 間の変更であれば pool-change 可能。Flexible は pool-change の対象外であり、「新規プール＋データ移行」が必須。 |
| QoS タイプ | Auto ⇔ Manual の混在は可能だが、Manual QoS 側では throughput の再設定が必要な場合がある。 |
| 暗号化種別 | Single / Double の暗号化種別が異なるプール間では pool-change 不可。 |
| 容量・スループット | 移動先プールに十分な容量とスループットの余裕があるか（プールサイズとサービス レベルで最大スループットが決まる）。 |
| 監視 / ログ | プール変更後はメトリック・アクティビティ ログが新規に開始されるため、必要に応じて旧ログをエクスポートしておく。 |
運用上のベストプラクティス
最後に、容量プール変更および Flexible への移行を実運用で行う際のベストプラクティスをまとめます。
- メンテナンス時間帯で実施
pool-change 自体はオンラインで動作するものの、スパイク的な遅延やアプリケーション側のタイムアウトなど、予期せぬ影響の可能性はゼロではありません。クリティカルなワークロードでは、メンテナンス ウィンドウを確保するのが無難です。 - 「事前同期 → 最終差分 → 切替」の 3 段階を徹底
初回フルコピーで時間をかけても、切替前の差分同期を短時間で済ませられれば、ダウンタイムを最小化できます。 - スループットと容量の「頭打ち」を監視
Flexible を含め、プールの容量・スループット上限に近づくと、ボリューム作成／拡張や pool-change が失敗しやすくなります。専用のアラートやダッシュボードを用意しておくと安心です。 - ロールバック プランの準備
切替後に想定外の遅延やアプリケーション エラーが発生した場合、「旧ボリュームへ戻す」ための手順（DNS 戻し・fstab 戻し）をあらかじめドキュメント化しておきましょう。 - コスト検証を小さく始める
Flexible は大きな自由度がある反面、設定次第でコスト構造も変わります。本番前に小さな検証環境で「典型的な 1 日」の負荷パターンを再現し、請求額とパフォーマンスのバランスを確認することをお勧めします。
まとめ
本記事のポイントを整理します。
- CLI で容量プール変更は可能
az netappfiles volume pool-changeにより、同一 NetApp アカウント内でボリュームを別容量プールへ移動できます。Standard / Premium / Ultra など従来プール間のサービス レベル変更は、ポータルの「プールの変更」と同様にオンラインで実行できます。 - Flexible への直接“切り替え”は不可
既存プールを Flexible に変換することも、ボリュームを Flexible プールへ pool-change することもできません。新しい Flexible プールを作成し、データ移行する必要があります。 - 安全な移行の基本パターン
「新プール作成 → 新ボリューム作成 → 事前同期 → 最終差分同期 → マウント切替 → 旧環境の解体」というフローを守れば、大規模ワークロードでもダウンタイムを最小限にできます。 - 互換性・容量・コストを事前に再確認
サービス レベル、QoS タイプ、暗号化種別、容量とスループットの上限を事前にチェックし、必要に応じてプールサイズやスループット設定を見直したうえで段階的に移行しましょう。
Azure NetApp Files の容量プール変更と Flexible への移行は、一見複雑そうですが、要点さえ押さえれば再現性の高い運用フローを組むことができます。まずは小さなボリュームで手順を確認し、自身の環境に合った標準手順書を整備しておくと、将来的なサービス レベル変更やコスト最適化にもスムーズに対応できるようになります。
コメント