Skip to main content
すべてのクラウドプロバイダ
  • Amazon Web Services の
  • Google Cloud
  • Microsoft Azure
  • すべてのクラウドプロバイダ
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

Google CloudでのCloud Volumes ONTAP のネットワーク要件

共同作成者

Cloud Volumes ONTAP システムが正常に動作するように、Google Cloudネットワークをセットアップします。

HA ペアを導入する場合は、を実行します "Google CloudでのHAペアの仕組みをご確認ください"

Cloud Volumes ONTAP の要件

Google Cloudでは、次の要件を満たす必要があります。

シングルノードシステムに固有の要件

シングルノードシステムを導入する場合は、ネットワークが次の要件を満たしていることを確認してください。

1つのVPC

シングルノードシステムにはVirtual Private Cloud(VPC;仮想プライベートクラウド)が1つ必要です。

プライベート IP アドレス

BlueXPは、Google Cloudのシングルノードシステムに3つまたは4つのプライベートIPアドレスを割り当てます。

Cloud Volumes ONTAP を API を使用して導入する場合、 Storage VM ( SVM )管理 LIF の作成をスキップし、次のフラグを指定できます。

'kipsvmManagementLIF : true

メモ LIF は、物理ポートに関連付けられた IP アドレスです。SnapCenter などの管理ツールには、 Storage VM ( SVM )管理 LIF が必要です。

HAペアに固有の要件

HAペアを導入する場合は、ネットワークが次の要件を満たしていることを確認します。

1つまたは複数のゾーン

複数のゾーンまたは単一のゾーンに HA 構成を導入することで、データの高可用性を確保できます。HAペアを作成すると、複数のゾーンまたは単一のゾーンを選択するように求められます。

  • 複数のゾーン(推奨)

    3 つのゾーンに HA 構成を導入することで、ゾーン内で障害が発生した場合の継続的なデータ可用性を確保できます。書き込みパフォーマンスは、単一のゾーンを使用する場合に比べてわずかに低くなりますが、最小のパフォーマンスです。

  • シングルゾーン

    Cloud Volumes ONTAP HA 構成では、単一のゾーンに導入する場合は分散配置ポリシーを使用します。このポリシーにより、 HA 構成がゾーン内の単一点障害から保護されます。障害の切り分けに別々のゾーンを使用する必要はありません。

    この導入モデルでは、ゾーン間にデータ出力料金が発生しないため、コストが削減されます。

4つの仮想プライベートクラウド

HA 構成には、 4 つの Virtual Private Cloud ( VPC ;仮想プライベートクラウド)が必要です。Google Cloudでは各ネットワークインターフェイスを別 々 のVPCネットワークに配置する必要があるため、VPCは4つ必要です。

HAペアを作成するときに、4つのVPCを選択するように要求されます。

  • vPC-0 :データおよびノードへのインバウンド接続

  • vPC-1 、 VPC -2 、および VPC -3 :ノードと HA メディエーター間の内部通信

この概念図は、クラウドボリュームのHAペアと構成に必要な4つのVPCを示したものです。

サブネット

VPC ごとにプライベートサブネットが必要です。

コネクタを VPC 0 に配置する場合は、サブネットで Private Google Access を有効にして API にアクセスし、データの階層化を有効にする必要があります。

これらの VPC 内のサブネットには、個別の CIDR 範囲が必要です。CIDR 範囲を重複させることはできません。

プライベート IP アドレス

BlueXPは、必要な数のプライベートIPアドレスをGoogle CloudのCloud Volumes ONTAP に自動的に割り当てます。ネットワークに十分なプライベートアドレスがあることを確認する必要があります。

Cloud Volumes ONTAP 用に割り当てられるLIFの数は、シングルノードシステムとHAペアのどちらを導入するかによって異なります。LIF は、物理ポートに関連付けられた IP アドレスです。SnapCenter などの管理ツールには、 SVM 管理 LIF が必要です。

  • シングルノード BlueXPでは、1つのノードシステムに4つのIPアドレスが割り当てられます。

    • ノード管理 LIF

    • クラスタ管理 LIF

    • iSCSI データ LIF

      メモ iSCSI LIFは、iSCSIプロトコルを介したクライアントアクセスを提供し、システムがその他の重要なネットワークワークフローに使用します。これらのLIFは必須であり、削除しないでください。
    • NAS LIF

      Cloud Volumes ONTAP を API を使用して導入する場合、 Storage VM ( SVM )管理 LIF の作成をスキップし、次のフラグを指定できます。

    'kipsvmManagementLIF : true

  • * HAペア* BlueXPは、12~13個のIPアドレスをHAペアに割り当てます。

    • ノード管理LIF×2(e0a)

    • クラスタ管理LIF(e0a)×1

    • iSCSI LIF×2(e0a)

      メモ iSCSI LIFは、iSCSIプロトコルを介したクライアントアクセスを提供し、システムがその他の重要なネットワークワークフローに使用します。これらのLIFは必須であり、削除しないでください。
    • NAS LIF(e0a)×1または2

    • クラスタLIF×2(e0b)

    • HAインターコネクトIPアドレス×2(e0c)

    • RSM iSCSI IPアドレス×2(e0d)

      Cloud Volumes ONTAP を API を使用して導入する場合、 Storage VM ( SVM )管理 LIF の作成をスキップし、次のフラグを指定できます。

    'kipsvmManagementLIF : true

内部ロードバランサ

BlueXPでは、Cloud Volumes ONTAP HAペアへの着信トラフィックを管理するGoogle Cloud内部ロードバランサ(TCP/UDP)が自動的に4つ作成されます。セットアップは必要ありませんネットワークトラフィックを通知し、セキュリティ上の問題を緩和するだけで、この要件が満たされることがわかりました。

クラスタ管理用のロードバランサで、 1 つは Storage VM ( SVM )管理用、もう 1 つはノード 1 への NAS トラフィック用、もう 1 つはノード 2 への NAS トラフィック用です。

各ロードバランサの設定は次のとおりです。

  • 共有プライベート IP アドレス × 1

  • グローバル健全性チェック 1 回

    デフォルトでは、ヘルスチェックで使用されるポートは 63001 、 63002 、および 63003 です。

  • 地域 TCP バックエンドサービス × 1

  • 地域 UDP バックエンドサービス × 1

  • 1 つの TCP 転送ルール

  • 1 つの UDP 転送ルール

  • グローバルアクセスは無効です

    グローバルアクセスはデフォルトでは無効になっていますが、展開後に有効にすることができます。クロスリージョントラフィックのレイテンシが大幅に高くなるため、この機能は無効にしました。誤ってリージョン間にマウントすることが原因でマイナスの体験が得られないようにしたいと考えていました。このオプションを有効にすることは、ビジネスニーズに固有のものです。

共有 VPC

Cloud Volumes ONTAP とコネクタは、 Google Cloud の共有 VPC とスタンドアロンの VPC でサポートされます。

シングルノードシステムの場合は、 VPC は共有 VPC またはスタンドアロン VPC のどちらかになります。

HA ペアの場合は、 4 つの VPC が必要です。これらの各 VPC は、共有またはスタンドアロンのどちらかにすることができます。たとえば、 VPC は VPC を共有化し、 VPC は VPC 1 、 VPC は 2 、 VPC は 3 で構成されることになります。

共有 VPC を使用すると、複数のプロジェクトの仮想ネットワークを設定し、一元管理できます。ホストプロジェクト _ で共有 VPC ネットワークをセットアップし、 Connector および Cloud Volumes ONTAP 仮想マシンインスタンスをサービスプロジェクト _ で導入できます。 "Google Cloud のドキュメント:「 Shared VPC Overview"

VPC でのパケットミラーリング

"パケットミラーリング" Cloud Volumes ONTAPを導入するGoogle Cloudサブネットで無効にする必要があります。パケットミラーリングがイネーブルの場合、 Cloud Volumes ONTAP は正常に動作しません。

アウトバウンドインターネットアクセス

Cloud Volumes ONTAP では、ネットアップAutoSupport へのアウトバウンドのインターネットアクセスが必要です。ネットアップは、システムの健常性をプロアクティブに監視し、ネットアップテクニカルサポートにメッセージを送信します。

Cloud Volumes ONTAP が AutoSupport メッセージを送信できるように、ルーティングポリシーとファイアウォールポリシーで次のエンドポイントへの HTTP / HTTPS トラフィックを許可する必要があります。

AutoSupport メッセージの送信にアウトバウンドのインターネット接続が使用できない場合、Cloud Volumes ONTAP システムは自動的にコネクタをプロキシサーバとして使用するように設定されます。唯一の要件は、コネクタのファイアウォールがポート3128上の_INBOUND接続を許可することです。コネクタを展開した後、このポートを開く必要があります。

Cloud Volumes ONTAP に厳密なアウトバウンドルールを定義した場合は、Cloud Volumes ONTAP ファイアウォールがポート3128で_OUTBOUND接続を許可することも必要です。

アウトバウンドのインターネットアクセスが使用可能であることを確認したら、 AutoSupport をテストしてメッセージを送信できることを確認します。手順については、を参照してください "ONTAP のドキュメント:「 AutoSupport のセットアップ"

ヒント HA ペアを使用している場合、 HA メディエーターではアウトバウンドのインターネットアクセスは必要ありません。

AutoSupport メッセージを送信できないことがBlueXPから通知された場合は、 "AutoSupport 構成のトラブルシューティングを行います"

ファイアウォールルール

ファイアウォールルールを作成する必要はありません。BlueXPはファイアウォールルールを作成します。独自のファイアウォールを使用する必要がある場合は、以下のファイアウォールルールを参照してください。

HA 構成には、次の 2 組のファイアウォールルールが必要です。

  • VPC -0 の HA コンポーネントのルールセット。これらのルールにより、 Cloud Volumes ONTAP へのデータアクセスが可能になります。 詳細はこちら。

  • VPC -1 、 VPC -2 、および VPC -3 の HA コンポーネントに関するもう 1 つのルールセット。これらのルールは、 HA コンポーネント間のインバウンド通信とアウトバウンド通信に対してオープンです。 詳細はこちら。

コールドデータを Google Cloud Storage バケットに階層化する場合は、 Cloud Volumes ONTAP が配置されているサブネットをプライベート Google Access 用に設定する必要があります( HA ペアを使用している場合、これは VPC 0 のサブネットです)。手順については、を参照してください "Google Cloud のドキュメント:「 Configuring Private Google Access"

BlueXPでデータの階層化を設定するために必要な追加手順については'を参照してください "コールドデータを低コストのオブジェクトストレージに階層化する"

他のネットワーク内の ONTAP システムへの接続

Google Cloud内のCloud Volumes ONTAP システムと他のネットワーク内のONTAP システムの間でデータをレプリケートするには、VPCと他のネットワーク(たとえば、社内ネットワーク)の間にVPN接続が必要です。

手順については、を参照してください "Google Cloud のドキュメント:「 Cloud VPN Overview"

ファイアウォールルール

BlueXPは、Cloud Volumes ONTAP が正常に動作するために必要なインバウンドとアウトバウンドのルールを含むGoogle Cloudファイアウォールルールを作成します。テスト目的や独自のファイアウォールルールを使用する場合は、ポートを参照してください。

Cloud Volumes ONTAP のファイアウォールルールには、インバウンドとアウトバウンドの両方のルールが必要です。HA 構成を導入する場合は、 VPC 0 の Cloud Volumes ONTAP のファイアウォールルールを以下に示します。

HA 構成には、次の 2 組のファイアウォールルールが必要です。

  • VPC -0 の HA コンポーネントのルールセット。これらのルールにより、 Cloud Volumes ONTAP へのデータアクセスが可能になります。

  • VPC -1 、 VPC -2 、および VPC -3 の HA コンポーネントに関するもう 1 つのルールセット。これらのルールは、 HA コンポーネント間のインバウンド通信とアウトバウンド通信に対してオープンです。 詳細はこちら。

ヒント コネクタに関する情報をお探しですか? "コネクタのファイアウォールルールを表示します"

インバウンドルール

作業環境を作成する場合、展開時に定義済みファイアウォールポリシーのソースフィルタを選択できます。

  • 選択したVPCのみ:インバウンドトラフィックのソースフィルタは、Cloud Volumes ONTAP システムのVPCのサブネット範囲、およびコネクタが存在するVPCのサブネット範囲です。これが推奨されるオプションです。

  • *すべてのVPC *:インバウンドトラフィックのソースフィルタは0.0.0.0/0のIP範囲です。

独自のファイアウォールポリシーを使用する場合は、Cloud Volumes ONTAP と通信する必要のあるすべてのネットワークを追加し、内部のGoogleロードバランサが正常に機能するように両方のアドレス範囲を追加してください。これらのアドレスは 130.211.0.0/22 および 35.191.0.0/16 です。詳細については、を参照してください "Google Cloud ドキュメント:ロードバランサファイアウォールルール"

プロトコル ポート 目的

すべての ICMP

すべて

インスタンスの ping を実行します

HTTP

80

クラスタ管理 LIF の IP アドレスを使用した System Manager Web コンソールへの HTTP アクセス

HTTPS

443

コネクタへの接続と、クラスタ管理LIFのIPアドレスを使用したSystem Manager WebコンソールへのHTTPSアクセス

SSH

22

クラスタ管理 LIF またはノード管理 LIF の IP アドレスへの SSH アクセス

TCP

111

NFS のリモートプロシージャコール

TCP

139

CIFS の NetBIOS サービスセッション

TCP

161-162

簡易ネットワーク管理プロトコル

TCP

445

NetBIOS フレーム同期を使用した Microsoft SMB over TCP

TCP

635

NFS マウント

TCP

749

Kerberos

TCP

2049

NFS サーバデーモン

TCP

3260

iSCSI データ LIF を介した iSCSI アクセス

TCP

4045

NFS ロックデーモン

TCP

4046

NFS のネットワークステータスモニタ

TCP

10000

NDMP を使用したバックアップ

TCP

11104

SnapMirror のクラスタ間通信セッションの管理

TCP

11105

クラスタ間 LIF を使用した SnapMirror データ転送

TCP

63001-63050

プローブポートをロードバランシングして、どのノードが正常であるかを判断します ( HA ペアの場合のみ必要)

UDP

111

NFS のリモートプロシージャコール

UDP

161-162

簡易ネットワーク管理プロトコル

UDP

635

NFS マウント

UDP

2049

NFS サーバデーモン

UDP

4045

NFS ロックデーモン

UDP

4046

NFS のネットワークステータスモニタ

UDP

4049

NFS rquotad プロトコル

アウトバウンドルール

Cloud Volumes 用の事前定義済みセキュリティグループ ONTAP は、すべての発信トラフィックをオープンします。これが可能な場合は、基本的なアウトバウンドルールに従います。より厳格なルールが必要な場合は、高度なアウトバウンドルールを使用します。

基本的なアウトバウンドルール

Cloud Volumes ONTAP 用の定義済みセキュリティグループには、次のアウトバウンドルールが含まれています。

プロトコル ポート 目的

すべての ICMP

すべて

すべての発信トラフィック

すべての TCP

すべて

すべての発信トラフィック

すべての UDP

すべて

すべての発信トラフィック

高度なアウトバウンドルール

発信トラフィックに厳格なルールが必要な場合は、次の情報を使用して、 Cloud Volumes ONTAP による発信通信に必要なポートのみを開くことができます。

メモ source は、 Cloud Volumes ONTAP システムのインターフェイス( IP アドレス)です。
サービス プロトコル ポート ソース 宛先 目的

Active Directory

TCP

88

ノード管理 LIF

Active Directory フォレスト

Kerberos V 認証

UDP

137

ノード管理 LIF

Active Directory フォレスト

NetBIOS ネームサービス

UDP

138

ノード管理 LIF

Active Directory フォレスト

NetBIOS データグラムサービス

TCP

139

ノード管理 LIF

Active Directory フォレスト

NetBIOS サービスセッション

TCP および UDP

389

ノード管理 LIF

Active Directory フォレスト

LDAP

TCP

445

ノード管理 LIF

Active Directory フォレスト

NetBIOS フレーム同期を使用した Microsoft SMB over TCP

TCP

464

ノード管理 LIF

Active Directory フォレスト

Kerberos V パスワードの変更と設定( SET_CHANGE )

UDP

464

ノード管理 LIF

Active Directory フォレスト

Kerberos キー管理

TCP

749

ノード管理 LIF

Active Directory フォレスト

Kerberos V Change & Set Password ( RPCSEC_GSS )

TCP

88

データ LIF ( NFS 、 CIFS 、 iSCSI )

Active Directory フォレスト

Kerberos V 認証

UDP

137

データ LIF ( NFS 、 CIFS )

Active Directory フォレスト

NetBIOS ネームサービス

UDP

138

データ LIF ( NFS 、 CIFS )

Active Directory フォレスト

NetBIOS データグラムサービス

TCP

139

データ LIF ( NFS 、 CIFS )

Active Directory フォレスト

NetBIOS サービスセッション

TCP および UDP

389

データ LIF ( NFS 、 CIFS )

Active Directory フォレスト

LDAP

TCP

445

データ LIF ( NFS 、 CIFS )

Active Directory フォレスト

NetBIOS フレーム同期を使用した Microsoft SMB over TCP

TCP

464

データ LIF ( NFS 、 CIFS )

Active Directory フォレスト

Kerberos V パスワードの変更と設定( SET_CHANGE )

UDP

464

データ LIF ( NFS 、 CIFS )

Active Directory フォレスト

Kerberos キー管理

TCP

749

データ LIF ( NFS 、 CIFS )

Active Directory フォレスト

Kerberos V Change & Set Password ( RPCSEC_GSS )

AutoSupport

HTTPS

443

ノード管理 LIF

support.netapp.com

AutoSupport (デフォルトは HTTPS )

HTTP

80

ノード管理 LIF

support.netapp.com

AutoSupport (転送プロトコルが HTTPS から HTTP に変更された場合のみ)

TCP

3128

ノード管理 LIF

コネクタ

アウトバウンドのインターネット接続が使用できない場合に、コネクタのプロキシサーバを介してAutoSupport メッセージを送信する

クラスタ

すべてのトラフィック

すべてのトラフィック

1 つのノード上のすべての LIF

もう一方のノードのすべての LIF

クラスタ間通信( Cloud Volumes ONTAP HA のみ)

構成のバックアップ

HTTP

80

ノード管理 LIF

http://<connector-IP-address> /occm/offboxconfig

構成バックアップをコネクタに送信します。 "構成バックアップファイルについて説明します"

DHCP

UDP

68

ノード管理 LIF

DHCP

初回セットアップ用の DHCP クライアント

DHCP

UDP

67

ノード管理 LIF

DHCP

DHCP サーバ

DNS

UDP

53

ノード管理 LIF とデータ LIF ( NFS 、 CIFS )

DNS

DNS

NDMP

TCP

18600 ~ 18699

ノード管理 LIF

宛先サーバ

NDMP コピー

SMTP

TCP

25

ノード管理 LIF

メールサーバ

SMTP アラート。 AutoSupport に使用できます

SNMP

TCP

161

ノード管理 LIF

サーバを監視します

SNMP トラップによる監視

UDP

161

ノード管理 LIF

サーバを監視します

SNMP トラップによる監視

TCP

162

ノード管理 LIF

サーバを監視します

SNMP トラップによる監視

UDP

162

ノード管理 LIF

サーバを監視します

SNMP トラップによる監視

SnapMirror

TCP

11104

クラスタ間 LIF

ONTAP クラスタ間 LIF

SnapMirror のクラスタ間通信セッションの管理

TCP

11105

クラスタ間 LIF

ONTAP クラスタ間 LIF

SnapMirror によるデータ転送

syslog

UDP

514

ノード管理 LIF

syslog サーバ

syslog 転送メッセージ

VPC -1、VPC -2、およびVPC -3のルール

Google Cloudでは、4つのVPC間にHA構成が導入されます。VPC -0 の HA 構成に必要なファイアウォールルール はです Cloud Volumes ONTAP については上記のリストを参照してください

一方、BlueXPでVPC -1、VPC -2、およびVPC -3のインスタンスに対して作成される定義済みのファイアウォールルールにより、_All_protocolsとポートでの入力通信が可能になります。これらのルールに従って、 HA ノード間の通信が可能になります。

HA ノードから HA メディエーターへの通信は、ポート 3260 ( iSCSI )を介して行われます。

メモ Google Cloudの新しいHAペア環境で高速な書き込み速度を有効にするには、VPC-1、VPC-2、およびVPC-3のMaximum Transmission Unit(MTU;最大伝送ユニット)が8、896バイト以上必要です。既存のVPC-1、VPC-2、およびVPC-3を8、896バイトのMTUにアップグレードする場合は、設定プロセス中にこれらのVPCを使用している既存のHAシステムをすべてシャットダウンする必要があります。

コネクタの要件

コネクタをまだ作成していない場合は、コネクタのネットワーク要件も確認してください。