0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@lewip(Lisa Lewis)

AWS FSxN ⇔ GCP GCNV 接続ガイド (第3章: FlexCache作成・NFSマウント編)

0
Last updated at Posted at 2026-11-02

概要

本記事は AWS FSx for ONTAP (FSxN) ⇔ Google Cloud NetApp Volumes (GCNV ONTAP モード) 間で FlexCache を構築する一連の手順の【第3章（最終章）】です。

第2章で確認・依頼したピアリング情報と事前疎通確認を前提として、GCP 側でのルーティング追加（Cloud Router による GCNV CIDR 広報）を実施し、受領したパラメータを用いて gcloud CLI（ONTAP CLI ラッパー）によるピアリング確立および FlexCache ボリュームの作成、さらに GCP 上の Compute Engine (GCE / Linux) からの NFS マウントとキャッシュ動作検証までを解説します。

前提条件

  • 【第2章】までの構成（GCP ファイアウォール、ピアリングパラメータ送付、Ping 疎通確認）が完了していること。
  • **検証用 GCE インスタンス（Linux）**が GCNV と同じ VPC 内にデプロイされていること。

Step 5-1: 【GCP】Cloud Router への GCNV CIDR 広報追加

FSxN (AWS) から GCNV (GCP) の Intercluster IP への通信を可能にするため、Cloud Router toaws の BGP 広報に GCNV 領域（<GCNV_INTERCLUSTER_CIDR> ※例: 10.13.48.0/20 等）を追加します。

  1. 広報更新コマンド（GCP Cloud Shell）

     gcloud compute routers update toaws \
   --region=asia-northeast1 \
   --advertisement-mode=CUSTOM \
   --set-advertisement-groups=ALL_SUBNETS \
   --set-advertisement-ranges=10.13.48.0/20

  2. 広報確認コマンド

     gcloud compute routers describe toaws --region=asia-northeast1

Step 5-2: 【AWS】FSxN 側でのピアリング設定実行（参考情報）

💡 ONTAPにおける「ピアリング（Peering）」とは？

ONTAP 同士でデータをやり取り（FlexCache や SnapMirror）をするための2段階のピアリング設定です。

  1. クラスタピアリング（Cluster Peering）
    FSxN ファイルシステムと GCNV ストレージプール同士の通信経路を開通させ、安全なネットワーク接続と信頼関係を確立する操作です（cluster peer コマンド）。クラスタ間で接続トンネルを開け、ストレージ同士のデータ通信を可能にします。

  2. SVM ピアリング（SVM / Vserver Peering）
    クラスタ内に作成された仮想ストレージ（SVM / Vserver）同士を具体的に紐付ける操作です（vserver peer コマンド）。クラスタ同士を繋いだ後、「どの仮想ストレージとどの仮想ストレージの間で通信を許可するか」を個別に指定します。

第2章で送付した依頼に基づき、AWS 担当者にて FSxN ONTAP CLI よりクラスタピアリング設定および SVM ピア許可を実行してもらいます。

※ ピアリング認証方式の選択（本番推奨 vs PoCクイックスタート）
GCNV の CLI ラッパー環境（gcloud 経由）では対話式プロンプトの入力が難しいため、認証方式に応じて以下のいずれかのアプローチを採用します。

  • 本番環境推奨（パスフレーズ認証あり）
    GCNV 側で先に -generate-passphrase true を実行してパスフレーズを発行し、AWS FSxN 側でそのパスフレーズを用いて cluster peer accept を実行します。この順序であれば、CLI ラッパーの対話制約を回避しつつ安全な暗号化認証ピアリングを確立できます。
  • PoC・検証用（無認証モード）
    手軽に疎通を完了させるため、AWS 側で一時的に無認証ピアを許可（-is-unauthenticated-access-permitted true）し、双方が -no-authentication true で接続します。

(※本検証では「無認証モード」の実行例をベースに進めます。パスフレーズ認証を用いる手順の詳細は後述の補足コラムをご参照ください)

【PoC用】無認証モードでの実行手順

  1. クラスタ全体の無認証アクセス許可

     cluster peer policy modify -is-unauthenticated-access-permitted true

  2. クラスタピアの作成（無認証モード）

     cluster peer create -peer-addrs 10.13.53.178,10.13.53.179 -ipspace Default -no-authentication true

⚠️ -peer-addrs の指定についての注意点
-peer-addrs には自身の IP ではなく、対向側となる GCNV（GCP側）の Intercluster LIF IP アドレス（第2章で取得した 10.13.53.178, 10.13.53.179）を指定します。

  1. SVM Peer パーミッションの作成（※単数形 permission コマンド）

     vserver peer permission create -vserver <FSXN_SVM_NAME> -peer-cluster gcnv-e267088a2eb529b-r04 -applications flexcache

実行完了後、AWS 担当者より接続準備完了の連絡（FSxN Intercluster IP、Cluster 名、SVM 名）を受領します。

Step 5-3: 【GCP】gcloud CLI による FlexCache ボリューム作成

受領した AWS 側のパラメータを指定し、GCNV ONTAP モードの CLI ラッパー（gcloud netapp storage-pools execute）を用いて、ピアリング確立から FlexCache ボリュームの作成までを一括で完了させます。
（※シェルの誤解釈を防ぐため、ONTAP コマンド引数はシングルクォーテーション ' ' で囲みます）

※ 注意：GCNV ONTAP モードにおける必須要件

  1. コンソール（GUI）非対応のため CLI（gcloud）実行が必須
    GCNV ONTAP モードでのピアリング構成および FlexCache ボリューム作成は GCP 管理コンソール画面からは対応していません。gcloud netapp storage-pools execute を使用した CLI 実行が必須です。
  2. IPspace の明示指定と専用コマンドの利用
    GCP 側の Intercluster 通信空間である IPspace: Gcnv を明示指定（-ipspace Gcnv）してピアリングを確立します。また、ボリューム作成には通常の volume create ではなく、アグリゲート（-aggr-list aggr1）を指定した volume flexcache create コマンドを使用します。

1. GCP 側での Cluster Peer 作成

【パターンA：検証用（無認証モード）の場合】

    gcloud netapp storage-pools execute tokyopool \
      --location=asia-northeast1-b \
      'cluster peer create -peer-addrs <FSXN_INTERCLUSTER_IP_1>,<FSXN_INTERCLUSTER_IP_2> -ipspace Gcnv -no-authentication true'

💡 【パターンB：本番推奨（パスフレーズ認証あり）の場合】
本番環境で暗号化パスフレーズ認証を用いる場合は、GCNV 側で以下のようにパスフレーズを自動生成させます：

gcloud netapp storage-pools execute tokyopool \
  --location=asia-northeast1-b \
  'cluster peer create -peer-addrs <FSXN_INTERCLUSTER_IP_1>,<FSXN_INTERCLUSTER_IP_2> -ipspace Gcnv -generate-passphrase true'

出力された文字列（パスフレーズ）を控え、AWS FSxN 側で以下のコマンドを実行して受け入れます：

cluster peer accept -cluster gcnv-e267088a2eb529b-r04
(プロンプトが表示されたら控えたパスフレーズを入力)

2. Cluster Peer 接続状態の確認

    gcloud netapp storage-pools execute tokyopool \
      --location=asia-northeast1-b \
      'cluster peer show'

(※ Availability が Available になっていればクラスタピアリング確立完了です)

3. SVM Peer の作成

    gcloud netapp storage-pools execute tokyopool \
      --location=asia-northeast1-b \
      'vserver peer create -vserver gcnv-e267088a2eb529b-svm-01 -peer-vserver <FSXN_SVM_NAME> -peer-cluster <FSXN_CLUSTER_NAME> -applications flexcache'

4. FlexCache ボリューム (cachedesti) の作成

⚠️ FlexCache のボリュームサイズ（-size）と Tiering（階層化）の制約
FlexCache ボリュームは仕様上、オブジェクトストレージ等への階層化ができません（tiering-policy: none 固定）。そのため、指定した -size は GCNV ストレージプール（本環境では tokyopool: 1024 GiB）の物理 SSD 容量を直接消費します。プールの空き容量を超えたサイズはプロビジョニングできないため、実プールの空き容量上限に留意してサイズを指定してください。

    gcloud netapp storage-pools execute tokyopool \
      --location=asia-northeast1-b \
      'volume flexcache create -vserver gcnv-e267088a2eb529b-svm-01 -volume cachedesti -size 10GB -origin-vserver <FSXN_SVM_NAME> -origin-volume <FSXN_ORIGIN_VOLUME_NAME> -aggr-list aggr1'

5. 作成・バインド状態の確認

    gcloud netapp storage-pools execute tokyopool \
      --location=asia-northeast1-b \
      'volume flexcache show'

(※ Origin-Volume に <FSXN_ORIGIN_VOLUME_NAME> が紐付いて表示されれば作成完了です)

【セキュリティ設定に関する補足（無認証ポリシーの戻し不可について）】
ONTAP の仕様上、無認証ピア（unauthenticated relationship）が 1 つでも存在している間は、AWS 側で cluster peer policy modify -is-unauthenticated-access-permitted false を打ってもエラーとなり、無認証禁止（false）に戻すことができません。
そのため、無認証モードでの運用期間中は「HA VPN の暗号化」と「AWS 側の Security Group で接続元 IP を厳格に制限すること」で安全性を担保し、環境撤去時（ピア関係を削除した後）に false に戻す運用とします（詳細は後述）。

Step 6: GCE インスタンスへの NFS マウントと確認

作成した FlexCache ボリューム（cachedesti）を、同一 VPC 内にある検証用の GCE インスタンス（Linux）から NFSv3 でマウントします。

1. GCNV 側の NFS マウント用 IP（LIF）の確認

Cloud Shell から ONTAP CLI ラッパーを実行し、NAS 用の論理インターフェイス（LIF）の IP アドレスを確認します。

    gcloud netapp storage-pools execute tokyopool \
      --location=asia-northeast1-b \
      'network interface show -vserver gcnv-e267088a2eb529b-svm-01'

実行結果例:

Logical    Status     Network            Current       Current Is
Vserver     Interface  Admin/Oper Address/Mask       Node          Port    Home
----------- ---------- ---------- ------------------ ------------- ------- ----
gcnv-e267088a2eb529b-svm-01
            gcnv-svm-ilbnas-1 up/up 10.13.53.180/32 gcnv-node-01 e0e true
            gcnv-svm-san-1    up/up 10.13.53.181/32 gcnv-node-01 e0e true
            gcnv-svm-san-2    up/up 10.13.53.182/32 gcnv-node-02 e0e true

※ Note: NAS 用インターフェイス（ilbnas-1）に割り当てられている IP アドレス（例: 10.13.53.180）をマウント先として使用します。

2. GCNV 側でのジャンクションパスおよび Export Policy の設定

NFS マウントを正常に受け付けるため、ジャンクションパスのバインドとアクセス許可ルールを設定します。

  1. ジャンクションパスの割り当て

     gcloud netapp storage-pools execute tokyopool \
   --location=asia-northeast1-b \
   'volume mount -vserver gcnv-e267088a2eb529b-svm-01 -volume cachedesti -junction-path /cachedesti'

  2. Export Policy ルールの追加（アクセス許可）

     gcloud netapp storage-pools execute tokyopool \
   --location=asia-northeast1-b \
   'vserver export-policy rule create -vserver gcnv-e267088a2eb529b-svm-01 -policyname default -ruleindex 1 -clientmatch 0.0.0.0/0 -rorule any -rwrule any'

3. GCE インスタンスでの NFS クライアントセットアップ & マウント

閉域環境での注意点
外部 IP を持たない GCE インスタンスで dnf install 等のパッケージ更新がタイムアウトする場合は、一時的に Cloud NAT を作成してアウトバウンド通信を確保してください。

  1. GCE インスタンスへ SSH 接続

     gcloud compute ssh cache --zone=asia-northeast1-b

  2. NFS クライアントツールのインストール (RHEL/Rocky/CentOS系)

     sudo dnf install -y nfs-utils

  3. マウントポイントの作成

     sudo mkdir -p /mnt/cachedesti

  4. NFSv3 マウントの実行

     sudo mount -t nfs -o rw,hard,rsize=65536,wsize=65536,vers=3 10.13.53.180:/cachedesti /mnt/cachedesti

  5. マウント状態の確認

     df -h /mnt/cachedesti

実行結果:

Filesystem                   Size  Used Avail Use% Mounted on
10.13.53.180:/cachedesti     10G  514M  9.5G   5% /mnt/cachedesti

GCNV 側の FlexCache ボリュームが GCE インスタンス上の /mnt/cachedesti に正常にマウントされたことを確認できました。

Step 7: Cross-Cloud FlexCache 動作検証

GCE インスタンスから、AWS FSx for NetApp ONTAP（Origin）側のデータが Google Cloud NetApp Volumes（FlexCache）を経由して透過的に参照・読み書きできるか確認します。

1. GCE インスタンスへ SSH ログイン

Cloud Shell から検証用 GCE インスタンス（cache）に接続します。

    gcloud compute ssh cache --zone=asia-northeast1-b

2. キャッシュされたディレクトリ・ファイル一覧の確認

マウントポイント（/mnt/cachedesti）の中身を表示し、AWS FSxN（Origin）側のディレクトリ構造が透過的に見えているか確認します。

    ls -la /mnt/cachedesti

実行結果:

total 8
drwxr-xr-x. 3 root root 4096 Sep 29 07:23 .
drwxr-xr-x. 3 root root   24 Oct 29 06:43 ..
drwxr-xr-x. 2 root root 4096 Sep 29 08:02 vpic_reference

さらに配下のディレクトリ構造を確認し、AWS 側の実ファイルが存在するか確認します。

    ls -la /mnt/cachedesti/vpic_reference

実行結果:

total 360
drwxr-xr-x. 2 root root   4096 Sep 29 08:02 .
drwxr-xr-x. 3 root root   4096 Sep 29 07:23 ..
-rw-r--r--. 1 root root 305993 Sep 29 07:23 all_makes.csv
-rw-r--r--. 1 root root     27 Sep 29 08:02 gcp_test.txt
-rw-r--r--. 1 root root    202 Sep 29 07:23 README.txt
-rw-r--r--. 1 root root  39284 Sep 29 07:23 vehicle_variable_list.csv

※ Note: AWS 側の Origin ボリューム内に配置されていたディレクトリ・ファイル群（all_makes.csv, gcp_test.txt 等）が、GCP 上の GCE インスタンスから即時に透過参照できることを確認しました。

3. データアクセスによるブロックレベル・オンデマンド引き込み検証

実際にファイルの中身を参照（読み込み）し、AWS から GCP へのデータブロック引き込み（キャッシュ処理）が正常に行われるか確認します。

    cat /mnt/cachedesti/vpic_reference/gcp_test.txt
    cat /mnt/cachedesti/vpic_reference/README.txt

ファイル内容が正常に表示され、Cross-Cloud FlexCache 経由でのオンデマンドキャッシングおよびデータアクセスが完了したことを確認しました。

4. キャッシュ側（GCP）からのファイル書き込み検証

FlexCache は読み取り専用ではなく、キャッシュ側（GCP）から作成・更新したファイルが自動的に発信元（AWS FSxN Origin）へ透過的に反映される機能を備えています。

事前にマウント状態と実行ユーザーの権限を確認します。

    mount | grep cachedesti
    ls -ld /mnt/cachedesti
    id

実行結果:

uid=1000(lisagozuon) gid=1005(lisagozuon) groups=1005(lisagozuon)

(※ 実行ユーザーの UID/GID が、第2章の依頼手順で FSxN Origin 側の所有権に設定した 1000:1005 と一致していることを確認します)

一般ユーザー権限のまま、マウントポイント直下に新規ファイルを作成します。

    echo "FlexCache Write Test Success from GCP" > /mnt/cachedesti/write_test.txt

ファイルが正常に作成され、書き込みが完了したか確認します。

    cat /mnt/cachedesti/write_test.txt

実行結果:

FlexCache Write Test Success from GCP

※ Note: GCP（GCNV）側で作成したファイルがエラーなく保存され、AWS FSxN（Origin）側へ即座に透過的に反映されたことを確認しました。

補足: FlexCache の書き込み要件および ONTAP セキュリティ仕様

  1. FlexCache の書き込み仕様と Permission denied 発生時の改善手順:
    FlexCache はキャッシュ側（GCP）からのファイル書き込みおよび Origin への自動同期をサポートしています。
    GCP クライアントから書き込みを行う際は、GCNV 側の Export Policy（rwrule any）の許可に加え、AWS FSxN Origin ボリューム側の UNIX パーミッション（所有者 UID/GID および Write 権限）がクライアント実行ユーザー（本環境では uid=1000, gid=1005）に適合していることが前提となります。
    ボリューム作成直後はルートディレクトリが root:root (755) となっているため、所有権が一致していない場合や一般ユーザーから書き込んだ場合は、アクセス拒否（Permission denied）となります。

💡 Permission denied が発生した場合の改善方法
もし書き込み時に Permission denied が発生した場合は、以下のいずれかでパーミッションを適合させます：

  • 方法 A（推奨）：AWS FSxN（Origin）側のルート権限を変更する
    AWS 側の管理クライアント（EC2 等）から Origin ボリュームをマウントし、マウントポイント直下（ボリュームルート）の所有者または権限を修正します。
    • グループまたは全員に書き込み権限を与える場合（※暫定対応として実施する場合）：
      sudo chmod 777 /mnt/fsxn_origin
      (※配下に既存ファイル/ディレクトリが存在する場合は必要に応じて -R オプションを付与)
    • 所有者を GCP 側の実行ユーザーに合わせる場合：
      sudo chown 1000:1005 /mnt/fsxn_origin
      (※配下も一括変更する場合は sudo chown -R 1000:1005 /mnt/fsxn_origin)
  • 方法 B：GCP クライアント側の実行ユーザーを Origin の所有者に合わせる
    GCE インスタンス側で、Origin 側の所有者 UID/GID と同じ ID を持つユーザーを作成・切り替えて書き込みを実行します。
    sudo useradd -u <ORIGIN側のUID> user_test
    su - user_test
  1. ONTAP Peer セキュリティ仕様（無認証ピア存在時に false へ戻せない仕様の背景と対策）:
    本構成におけるクラスタピアポリシーの挙動と、運用設計上の注意点は以下の通りです。

⚠️【実機検証で判明した仕様】無認証ポリシーの戻し不可とセキュリティ対策

  • なぜこの手順になったのか（背景）
    Cluster peer を作成する際、GCNV（CLI ラッパー）側では対話式のパスフレーズを手入力することができません。そのため、検証クイックスタートでは AWS 側で無認証のクラスタピア作成を許可する以下の設定を一時的に投入しました。
    cluster peer policy modify -is-unauthenticated-access-permitted true
  • 実機検証で起きた挙動（エラーの発生）
    無認証を許可したままだと他の ONTAP からの接続も許可してしまう懸念があるため、GCNV とのピア接続が完了した段階で、セキュリティ担保のために設定を戻そうとしました。
    cluster peer policy modify -is-unauthenticated-access-permitted false
    しかし、「すでにアクティブな無認証クラスタピアが存在するため、false への変更は拒否されました」 というエラー（ONTAP の仕様）が発生し、変更できませんでした。
  • 運用上の対策（どうやって安全性を担保するか？）
    • 本番運用の場合: GCNV 側で -generate-passphrase true を実行し、FSxN 側で cluster peer accept を用いる「パスフレーズ認証方式」を採用することで、無認証許可ポリシー自体を有効化せずに運用可能です。
    • 無認証方式で運用する場合: 稼働中は ONTAP レイヤーで無認証接続を塞ぐことができないため、ネットワークレイヤー（HA VPN の暗号化および AWS 側の Security Group で通信元 IP を厳格に絞り込むこと）でアクセスを制限する必要があります。
  • 撤去時の手順（ポリシーを戻すタイミング）
    無認証モードで検証を行い、終了や環境撤去時に安全に false へ戻したい場合は、必ず先に GCP 側の FlexCache ボリュームおよび Cluster Peer 関係を削除（解体）してから、AWS 側でポリシーを false に戻す必要があります。

検証の成果とポイント

本検証では、AWS FSx for NetApp ONTAP（Origin）と Google Cloud NetApp Volumes（Cache）間における、パブリッククラウドを跨いだ「Cross-Cloud FlexCache」の構築・疎通・データキャッシング検証を実施しました。

1. 得られた検証結果

  • 実体は AWS 側のデータ: GCE 上から参照できたファイル群（all_makes.csv, gcp_test.txt 等）は、すべて AWS FSxN 側の Origin ボリュームに存在する実データです。
  • 双方向アクセスの完全動作: AWS（Origin）側のデータオンデマンド引き込み（Read）だけでなく、GCP（Cache）側で作成したファイル（write_test.txt）がブロックされることなく AWS 側へ透過的に書き込まれること（Write）を実証しました。
  • 閉域ハイブリッド通信の成立: HA VPN 経由での ONTAP ピアリングから、GCE による NFSv3 マウント、オンデマンドデータ同期まで、全レイヤーが意図通り正常に動作しました。

2. ネットワーク・セキュリティ設計の要点

  • トランスポート層での保護: 通信は HA VPN（IPsec トンネル）で暗号化されており、Security Group（10.13.48.0/20、TCP 11104-11105 / ICMP）によって送信元を厳格に制限しています。
  • ピアリング設計の選択肢: PoC 用の「無認証モード」だけでなく、CLI ラッパーの非対話制約をパスフレーズ自動生成（-generate-passphrase）で回避する「本番推奨の認証モード」を設計に組み込めることを確認しました。

まとめ

全3章にわたり、AWS FSxN と Google Cloud NetApp Volumes（Mode: ONTAP）を組み合わせた Cross-Cloud FlexCache の構築手順を解説しました。

  • 第1章: HA VPN および BGP によるマルチクラウド閉域ネットワークインフラの開通、および PSA カスタムルート伝播の有効化
  • 第2章: ファイアウォール設計（PSA 挙動の考慮）、GCNV 接続情報の確認、双方向 MTU 最適化（フラグメント禁止テスト）、AWS 担当者へのピアリング依頼
  • 第3章: Cloud Router 経路広報、認証・無認証に対応したピアリング確立、FlexCache ボリューム作成、NFS マウントおよび双方向キャッシュ読み書き検証

異種クラウド間であっても、ONTAP ネイティブの通信プロトコルと適切なパーミッション設計を組み合わせることで、単なる参照用キャッシュにとどまらない「双方向データ連携基盤」として FlexCache を安全かつ実用的に運用できることが実証できました。マルチクラウド環境でのデータ共有や移行、拠点間データ連携を検討する際の参考になれば幸いです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?