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 接続ガイド（第2章：ファイアウォール & ONTAP ピアリング準備編）

0
Last updated at Posted at 2026-11-02

概要

本記事は AWS FSx for ONTAP (FSxN) ⇔ Google Cloud NetApp Volumes (GCNV) 間で FlexCache を構築する一連の手順の【第2章】です。

第1章で開通させた HA VPN / BGP インフラをベースに、GCP 側のファイアウォールルール設定、および GCNV 側の Mode: ONTAP ストレージプールに対する ONTAP ピアリング情報の確認、VPN 環境における双方向 MTU 最適化、AWS 担当者への設定依頼手順を解説します。

前提条件

  • 【第1章】GCP ⇔ AWS の HA VPN および BGP セッションが正常に確立（Established）していること。
  • ONTAP モードのストレージプール作成が完了していること: GCP 側に GCNV ストレージプール（tokyopool、Mode: ONTAP）が作成済みであること。

⚠️【重要解説】なぜ Mode: ONTAP（ONTAPモード）を使用するのか？

1. ONTAP モードとは？
GCNV ストレージプール作成時に指定する設定で、NetApp 独自の標準ストレージ OS「ONTAP」のネイティブ機能・プロトコルスタックをそのまま露出させて動作させるモードです。

2. なぜ今回の構成で ONTAP モードを使うのか？
AWS (FSxN) ⇔ GCP (GCNV) 間で FlexCache（異機種・異クラウド間キャッシュ同期機能） や SnapMirror（ボリュームレプリケーション） を実行するには、GCNV 側が ONTAP ネイティブのピアリングプロトコル（TCP 11104/11105）をサポートしている必要があります。通常モード（Auto/GCPマネージド）ではこれらのプロトコルが制限されるため、ハイブリッドクラウド間での ONTAP ピアリングを確立するために Mode: ONTAP が必須 となります。

3. 運用上の注意点（コンソール非対応・コマンド制限）
Mode: ONTAP が有効なストレージプール内のボリューム管理やピアリング操作は、GCP Web コンソール（GUI）の画面に対応していません。そのため、本手順ではすべて Cloud Shell (gcloud CLI) を使用して操作を行います。
※なお、gcloud netapp storage-pools execute はセキュリティ上ホワイトリスト化された ONTAP コマンドのみが許可されているため、管理系（security）や基盤レイヤー系（aggregate efficiency 等）のコマンドを実行すると unable to parse command エラーで拒否される仕様となっています。

Step 4: GCP ファイアウォールルールの設定・更新

AWS ⇔ GCNV 間の通信（ONTAP クラスタピアリングおよび FlexCache 通信）に必要なインバウンドルールを作成・更新します。

4-1. ファイアウォールルールの新規作成（または事前作成）

クラスタピアリングおよび FlexCache キャッシュ同期通信に必須となるポートを開放します。
現行の ONTAP 9.x では以下のポートを使用します。

  • ICMP: 双方向の疎通確認（Ping）および Path MTU Discovery（フラグメンテーション防止）
  • TCP 11104: クラスタ間ピアリング（双方向セッション確立・制御通信）
  • TCP 11105: クラスタ間データ転送（FlexCache / SnapMirror 複製トラフィック）

(※ポート 10000 は旧世代プロトコル用のため開放不要です。また、TCP 2049/445/139 などのクライアント直接アクセス用ポートは、GCE 等のクライアントからマウントしない限り開放不要です)

  1. GCP コンソールで [Network security] > [Firewall policies] を開き、[+ Create firewall rule] をクリックします。
    image.png

  2. 以下を設定して作成します：

    • 名前: allow-aws-to-gcnv
    • ネットワーク: gcp-vpc-tokyo（第1章作成の VPC）
    • 優先度: 1000
    • トラフィックの向き: インバウンド（受信）
    • 一致したときのアクション: 許可
    • ターゲット: ネットワーク上のすべてのインスタンス
    • ソース IP アドレスの範囲: AWS 側の VPC CIDR（例: 172.xx.0.0/16、事前作成時はダミー CIDR 192.0.2.0/24）
    • プロトコルとポート:
      • 指定したプロトコルとポート:
        • tcp: 11104, 11105
        • Other protocols: icmp にチェック
    • [作成] をクリックします。

image.png

💡 GCP VPC ファイアウォールと GCNV の仕様について
Google Cloud の仕様上、VPC ファイアウォールルールは「自 VPC 内に存在する VM インスタンス（仮想 NIC）」にのみ適用され、VPC ネットワーク ピアリング（PSA: sn-netapp-prod）で接続された別管理基盤（GCNV）宛ての通信には作用しません。
そのため、GCNV の Intercluster LIF 宛ての通信はお客様 VPC 側のファイアウォールでは遮断されません。本手順でルールを作成しているのは、同一 VPC 内に配置する検証用 Linux VM との通信疎通、およびプロジェクト内のセキュリティ統制（意図した通信ポートの明示）の観点によるものです。

4-2. AWS VPC CIDR 確定後のファイアウォールルール更新手順

パラメータ受領後に IP 範囲を変更する場合は以下の手順で修正します。

  1. [Network security] > [Firewall policies] に移動します。

  2. 作成したルール（allow-aws-to-gcnv）をクリックし、上部の [編集] をクリックします。
    image.png

  3. [ソース IPv4 範囲] の項目を受領した確定 CIDR（例: 172.30.0.0/16）に変更します。
    image.png

  4. ページ下部の [保存] をクリックします。

ファイアウォールの Egress 設定について
Google Cloud の VPC ファイアウォールは、デフォルト設定で「すべての Egress トラフィックが許可」されています。明示的に下りを拒否するカスタムルールを作成していない限り、GCNV から AWS（FSxN）向け通信のための追加 Egress 設定は不要です。

Step 5: ONTAP ピアリング情報の確認・AWS 側への設定依頼

Mode: ONTAP のストレージプール操作およびピアリング情報は、gcloud netapp storage-pools execute コマンドを使用して GCNV 内部へ ONTAP コマンドを発行して確認します。

Step 5-1. 【GCP】gcloud CLI による GCNV ピアリング情報の確認・取得

GCP Cloud Shell を開き、以下のコマンドを実行して GCNV 側の接続情報を確認・取得します。
（※シェルの誤解釈を防ぐため、コマンド引数はシングルクォーテーション ' ' で囲みます）

  1. GCNV Cluster 名の確認

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

  2. GCNV SVM 名の確認

     gcloud netapp storage-pools execute tokyopool --location=asia-northeast1-b 'vserver show'

  3. GCNV Intercluster LIF 情報（IP / LIF 名 / 所属 Vserver）の確認

     gcloud netapp storage-pools execute tokyopool --location=asia-northeast1-b 'net int show -role intercluster'

実行結果例:

Logical    Status     Network            Current       Current Is
Vserver     Interface  Admin/Oper Address/Mask       Node          Port    Home
----------- ---------- ---------- ------------------ ------------- ------- ----
gcnv-e267088a2eb529b-r04
            intercluster_lif_1 up/up 10.13.53.178/20 gcnv-node-01  e0d     true
            intercluster_lif_2 up/up 10.13.53.179/20 gcnv-node-02  e0d     true

📋 取得した GCNV パラメータ一覧

  • GCNV Cluster 名: gcnv-e267088a2eb529b-r04
  • GCNV Admin SVM 名: gcnv-e267088a2eb529b-r04（クラスタと同名）
  • GCNV データ用 SVM 名: gcnv-e267088a2eb529b-svm-01
  • GCNV Intercluster IP: 10.13.53.178, 10.13.53.179
  • GCNV Intercluster LIF 名: intercluster_lif_1, intercluster_lif_2

⚠️【VPN接続環境の超重要注意点】MTU 9000/9001 と IPフラグメンテーションの罠

GCNV および FSxN の Intercluster ポートは、初期状態で ジャンボフレーム（MTU 9000〜9001） に設定されているケースがあります。

gcloud netapp storage-pools execute tokyopool --location=asia-northeast1-b \
  'broadcast-domain show'

AWS ⇔ GCP 間を HA VPN 経由 で接続している場合、IPsec の暗号化ヘッダーによるオーバーヘッドがあるためジャンボフレームは通過できません。
このときルーター側でパケットを小さく切り分ける「IP フラグメンテーション（パケット分割）」が発生します。フラグメンテーションはルーターの CPU に極めて高い負荷をかけるだけでなく、分割されたパケットが 1 つでも欠落するとパケット全体が再送となるため、スループットが激減したりセッションがタイムアウトして切断されたりする原因となります。

そのため、両拠点のストレージ側で「最初からルーターに分割処理をさせない適正サイズ（MTU 1350〜1400 程度）」にブロードキャストドメインを設定しておくことが不可欠です。

GCNV 側のブロードキャストドメイン MTU 変更コマンド（必要時）:

gcloud netapp storage-pools execute tokyopool --location=asia-northeast1-b \
  'broadcast-domain modify -ipspace Gcnv -broadcast-domain Intercluster -mtu 1350'

Step 5-2. 【AWS 側作業依頼】AWS 担当者へのパラメータ送付と Peer 設定依頼

※ ONTAP ピアリング構成の重要ルール
CLI ラッパー環境（gcloud 経由）で発生する対話式のパスフレーズ入力制約を回避するため、本検証手順では**無認証ピアリングモード（-no-authentication true）**を採用します。
※本番案件等でパスフレーズ認証を用いる場合は、GCNV 側で -generate-passphrase true を指定してパスフレーズを発行し、FSxN 側で cluster peer accept を実行する順序で構成することで対話制約を回避可能です。

Step 5-1 で取得した GCNV 側の接続情報を AWS 管理担当者へ送付し、FSxN 側でのクラスタピアリング設定（無認証ピアリング設定）および SVM ピアアクセスポリシーの許可設定を依頼します。

✉️ AWS 担当者への送付・依頼テンプレート

【送付する GCNV 情報】

  • GCNV Intercluster IP: 10.13.53.178, 10.13.53.179
  • GCNV Cluster 名: gcnv-e267088a2eb529b-r04
  • GCNV SVM 名: gcnv-e267088a2eb529b-svm-01
  • GCE 書き込み実行ユーザー情報: UID: 1000, GID: 1005

【依頼する作業内容】
FSxN 側で以下の作業をお願いします（※CLI ラッパー環境における対話式パスフレーズ入力の制約を回避するため、無認証ピアリングモードを使用します）。

  1. 事前疎通確認および MTU（フラグメント禁止）テスト
    (1) FSxN の Admin SVM 名および Intercluster LIF 名を確認

     vserver show -type admin
 net int show -role intercluster

    (2) GCNV 宛にフラグメンテーション禁止 Ping を実行（VPN 経路の MTU 適合テスト）

     net ping -vserver <FSXN_ADMIN_SVM> -lif <FSXN_INTERCLUSTER_LIF> -destination 10.13.53.178 -packet-size 1350 -disallow-fragmentation true -show-detail true

    (※もし MTU が原因でパケット落ちが発生する場合は、FSxN 側のブロードキャストドメイン MTU の調整をお願いします)

     broadcast-domain show
 broadcast-domain modify -ipspace Default -broadcast-domain <FSXN_INTERCLUSTER_BD_NAME> -mtu 1350

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

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

  3. クラスタピアの作成（無認証モード・相手側 IP を指定）

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

  4. FSxN SVM に対する GCNV からの FlexCache 接続パーミッションの付与（※単数形 permission コマンド）

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

  5. 【重要】Origin ボリュームの UNIX パーミッション設定
    GCP 側からの書き込み（Writeback）を許可するため、Origin ボリューム直下（および配下ディレクトリ）の所有者を 1000:1005、パーミッションを 755 に設定してください。

【FSxN 側から受領する情報】

  • FSxN 側 Intercluster IP（2つ）
  • FSxN Cluster 名
  • FSxN SVM 名
  • 手順 1〜5 の完了連絡

Step 5-3. 双方向 Ping 疎通と MTU 最適化テスト

💡 なぜ「フラグメント禁止（-disallow-fragmentation true）」で Ping を打つのか？
通常の Ping だと、パケットサイズが経路の上限を超えていてもルーターが親切にパケットを細かく切り分けて届けてしまうため、結果上は「成功（疎通OK）」に見えてしまいます。これでは VPN 経路でパケット分割が発生しているかどうかに気づけません。
そのため、「フラグメント（分割）を絶対に禁止するフラグ（DFビット）」を立てて Ping を打ちます。分割を禁止した状態でエラーにならずに通るパケットサイズを探すことで、VPN ルーターを一切の分割処理なしで素通りできる最大の MTU 値を確実に特定できます。

AWS 側の設定が完了した段階で、GCP 側のピアリング作成（第3章）に進む前に双方向で Intercluster LIF 同士の Ping（ICMP）疎通およびパケット分割テストを確認します。

  1. GCP（GCNV）側から AWS（FSxN）への Ping ＆ MTU 探索
    GCNV 側から FSxN の Intercluster IP へフラグメンテーション禁止 ping を実行し、パケット分割が発生しない適正サイズを確認します。
    ※本検証環境（HA VPN 経由）においては、-packet-size 1350（IPsec ヘッダー等を加味して MTU 換算で約 1380 前後）でパケット分割なしの正常疎通を確認しています。

     gcloud netapp storage-pools execute tokyopool --location=asia-northeast1-b \
   'net ping -vserver gcnv-e267088a2eb529b-r04 -lif intercluster_lif_1 -destination <FSXN_INTERCLUSTER_IP_1> -packet-size 1350 -disallow-fragmentation true -show-detail true'

  2. AWS（FSxN）側から GCP（GCNV）への Ping ＆ MTU 確認
    AWS 担当者側でも、FSxN から GCNV の Intercluster LIF へフラグメンテーション禁止 Ping を実行し、双方向でパケット分割なく通信できることを確認してもらいます。

     net ping -vserver <FSXN_ADMIN_SVM> -lif <FSXN_INTERCLUSTER_LIF> -destination 10.13.53.178 -packet-size 1350 -disallow-fragmentation true -show-detail true

💡 FSxN（AWS 側）のブロードキャストドメイン MTU 調整コマンド
FSxN 側で MTU を調整する場合のコマンド例です（AWS 担当者作業用）：

# ブロードキャストドメインと現在の MTU の確認
broadcast-domain show

# Intercluster ブロードキャストドメインの MTU を VPN に合わせて 1350 に変更
broadcast-domain modify -ipspace Default -broadcast-domain <FSXN_INTERCLUSTER_BD_NAME> -mtu 1350

まとめ

本記事（第2章）では、GCP 側のファイアウォール設定と PSA 仕様の整理、gcloud CLI を用いた GCNV ピアリング情報の確認、IP フラグメンテーションの負荷を回避するための双方向 MTU 最適化（フラグメント禁止テスト）とブロードキャストドメイン設定、そして 3章と整合した無認証ピアリング前提の依頼フローまでを整備しました。

次回の【第3章】では、受領したパラメータを用いてクラスタおよび SVM ピアリングを確立し、FlexCache ボリュームを作成して GCE インスタンスからのマウントと双方向データ検証を実施します。

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?