Google Cloud NetApp Volumes

解決する課題

• オンプレの NetApp ONTAP / NAS をそのまま GCP へ移行したい（同じ運用感・機能で持ち込みたい）
• NFS と SMB の両方を使うエンタープライズアプリ（Windows ファイル共有・業務系・SAP 等）を 1 つのサービスで集約したい
• 複数の VM・コンテナから同じファイルを同時に読み書きできる共有ストレージが欲しいが、NAS を自前運用したくない
• スナップショット・クローン・複製といった NetApp 由来のデータ管理機能を、フルマネージドで使いたい
• ファイル共有の容量や性能を柔軟に増減しつつ、障害やランサムウェアに備えた復旧手段を持ちたい

主要概念と用語

• ストレージプール: 容量とサービスレベルをまとめてプロビジョニングする入れ物。ボリュームはこのプールから切り出す
• ボリューム: 実際にマウントする共有の単位。NFS なら IP:/<ボリュームパス>、SMB なら UNC パスでアクセスする
• サービスレベル: 性能（スループット）の階層。一般に Standard・Premium・Extreme などがあり、容量あたりの帯域が変わる
• ストレージタイプ / ロケーション: ゾーン単位かリージョン単位かなど、可用性と配置の範囲を決める区分
• プロトコル: NFSv3 / NFSv4.1 / SMB に対応。1 ボリュームで NFS と SMB を併用するデュアルプロトコル構成も取り得る
• スナップショット: 特定時点の読み取り専用コピー。容量効率が高く、誤削除からの復旧やバックアップ起点に使う
• クローン: スナップショットから作る書き込み可能なボリューム。検証・分析用のコピーを素早く用意できる
• 複製（レプリケーション）: 別ロケーションへ非同期にデータを複製し、DR（災害復旧）に使う

仕様・制限・クォータ

• NFSv3 / NFSv4.1 / SMB に対応し、用途に応じてプロトコルを選ぶ。Windows 中心なら SMB、Linux 中心なら NFS
• ストレージプールに容量とサービスレベルを先にプロビジョニングし、その範囲でボリュームを作成する。容量・性能は後から変更できる
• サービスレベルが実効スループットを左右する。同じ容量でも上位レベルほど帯域が高い。要件に合わせてレベルと容量を組み合わせる
• 可用性の範囲はストレージタイプ依存で、ゾーン単位かリージョン内の複数ゾーンかが変わる。重要データはリージョン冗長を選ぶ
• インスタンス（プール/ボリューム）は VPC 内の内部 IP で公開され、インターネットから直接はマウントできない
• Active Directory 連携により SMB の認証やユーザー管理を既存ドメインに統合できる
• 提供リージョンやサービスレベルの対応状況は限定される場合があり、配置前に確認する
• プロジェクト/リージョンごとに容量やプール数のクォータがあり、引き上げ申請が可能
• 容量・性能の最小/最大や刻み、対応リージョンといった変動しやすい数値は公式ドキュメントを参照する

内部の仕組み

Google Cloud NetApp Volumes は、NetApp の ONTAP 技術をベースに Google がマネージドで運用する共有ファイルサービスです。OS パッチ・冗長化・容量管理といった基盤運用は Google 側が担い、利用者はストレージプールとボリュームの設計に集中できます。

• 利用者はまずストレージプールに容量とサービスレベルを確保し、その中からボリュームを切り出してマウントする
• 同じボリュームを複数クライアントが同時に読み書きできるため、ファイルロック・UID/GID・同時更新の扱いはアプリ側で設計する
• スナップショットは ONTAP 由来の容量効率の高い方式で、特定時点を素早く保持し、誤削除からの復旧やクローンの起点になる
• 複製は別ロケーションへ非同期にデータを送り、ゾーンやリージョンの障害に備えた DR 経路を提供する
• 接続は VPC 内の内部経路（Private Service Access など）を通り、同じ VPC または到達可能なネットワークから内部 IP でアクセスする

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

• NetApp 移行のリフト＆シフト: オンプレ ONTAP からの移行で、既存のスナップショット運用やプロトコル構成をできるだけ踏襲する
• マルチプロトコル集約: Windows と Linux が混在する環境では、SMB と NFS を 1 つのサービスに集約して運用を単純化する
• サービスレベルでチューニング: 性能不足なら容量を増やすだけでなくサービスレベルの引き上げも検討する。要件に対し最小構成から始める
• スナップショットスケジュール: 定期スナップショットを設定し、誤削除やランサムウェアからの短時間復旧に備える
• クロスリージョン複製で DR: 重要データは別リージョンへ複製し、RPO/RTO 要件に合わせて複製間隔を設計する
• 同一ロケーション配置: レイテンシ最小化のため、マウントするクライアントとボリュームを近いゾーン/リージョンに置く

運用・監視

• Cloud Monitoring で容量使用率・スループット・IOPS・レイテンシなどを監視し、サービスレベルや容量の見直しにつなげる
• スナップショットと複製の取得状況・遅延・リストア手順を定期的に検証し、DR が実際に機能することを確認する
• マウントできないときは、ファイアウォールルール、接続方式（Private Service Access 等）、割り当て IP、クライアントの NFS/SMB パッケージ、SMB なら Active Directory 連携設定を確認する
• 容量がプール上限に近づいていないか監視し、枯渇前にプール容量またはボリューム容量を拡張する
• SMB 利用時は AD ドメインの可用性にも依存するため、ドメインコントローラ側の監視も併せて行う

コスト

課金は主にプロビジョニング済みのストレージプール容量 × サービスレベル単価 × 時間で決まります。使った分だけではなく確保した容量に対して課金されるため、サービスレベルと容量を要件に合わせて適切に選ぶことがコスト最適化の要点です。

セキュリティ

• 接続は VPC 内の内部 IP に限定され、インターネットへは公開されない
• 保存時の暗号化は既定で有効。鍵管理の要件は公式の対応状況（CMEK など）を確認する
• SMB は Active Directory と連携し、既存ドメインのユーザー/グループで認証・アクセス制御できる
• NFS のファイルアクセス権は POSIX（UID/GID）ベース。NFSv4.1 では Kerberos による認証・完全性・転送時暗号化も利用し得る
• ファイアウォールルールで NFS/SMB の到達元を必要なサブネット/タグに絞る
• IAM でプール/ボリュームの作成・削除・スケール等の管理操作権限を制御する
• スナップショットや複製をランサムウェア対策の復旧手段として位置づけ、保持と復元手順を整備する

関連サービス・比較

ハンズオン / CLI例

# ストレージプールを作成（容量とサービスレベルを指定）
gcloud netapp storage-pools create demo-pool \
  --location=asia-northeast1 \
  --service-level=PREMIUM \
  --capacity=2TiB \
  --network=name=default

# プールからボリュームを作成（NFSv3、共有パス /vol1）
gcloud netapp volumes create demo-vol \
  --location=asia-northeast1 \
  --storage-pool=demo-pool \
  --capacity=1TiB \
  --share-name=vol1 \
  --protocols=NFSV3

# 割り当てられたマウントポイント（内部エンドポイント）を確認
gcloud netapp volumes describe demo-vol \
  --location=asia-northeast1 \
  --format="value(mountOptions)"

# VM 側でマウント（nfs-common 導入済みとする。IP は describe で確認した値）
sudo mkdir -p /mnt/netapp
sudo mount 10.0.0.2:/vol1 /mnt/netapp

# 容量をスケールアップ（例: 2TiB へ）
gcloud netapp volumes update demo-vol \
  --location=asia-northeast1 \
  --capacity=2TiB