Azure NetApp Files のネットワーク計画のガイドライン
ネットワーク アーキテクチャの計画は、あらゆるアプリケーション インフラストラクチャ設計の重要な要素です。 この記事は、お客様のワークロードに有効なネットワーク アーキテクチャを設計し、Azure NetApp Files の豊富な機能からベネフィットを得るために役立ちます。
Azure NetApp Files のボリュームは、Azure Virtual Network 内の委任されたサブネットと呼ばれる特別な目的のサブネットに含まれるように設計されています。 そのため、VNet ピアリング経由で Azure 内から直接、またはオンプレミスから仮想ネットワーク ゲートウェイ (ExpressRoute または VPN Gateway) 経由で、ボリュームにアクセスできます。 サブネットは Azure NetApp Files 専用であり、インターネットへの接続はありません。
構成可能なネットワーク機能
サポートされているリージョンでは、Standard または Basic のネットワーク機能を使用する新しいボリュームを作成したり、いずれかのネットワーク機能を使用するように既存のボリュームを変更したりできます。 Standard ネットワーク機能がサポートされていないリージョンでは、ボリュームは既定で Basic ネットワーク機能を使用します。 詳細については、「ネットワーク機能の構成」を参照してください。
Standard
この設定を選択すると、より高い IP 制限と、ネットワーク セキュリティ グループやユーザー定義ルートなどの標準 VNet 機能が委任されたサブネット上で有効になり、この記事で説明されているように追加の接続パターンも有効になります。Basic
この設定を選択すると、「考慮事項」セクションで説明されているように、選択的な接続パターンと制限付き IP スケールが有効になります。 この設定では、すべての制約が適用されます。
サポートされているリージョン
新しいボリュームに Standard ネットワーク機能を設定したり、既存のボリュームのネットワーク機能を変更したりするオプションは、次のリージョンで使用できます。
- オーストラリア中部
- オーストラリア中部 2
- オーストラリア東部
- オーストラリア南東部
- ブラジル南部
- ブラジル南東部
- カナダ中部
- カナダ東部
- インド中部
- 米国中部
- 東アジア
- 米国東部
- 米国東部 2
- フランス中部
- ドイツ北部
- ドイツ中西部
- 東日本
- 西日本
- 韓国中部
- 韓国南部
- 米国中北部
- 北ヨーロッパ
- ノルウェー東部
- ノルウェー西部
- カタール中部
- 南アフリカ北部
- 米国中南部
- インド南部
- 東南アジア
- スウェーデン中部
- スイス北部
- スイス西部
- アラブ首長国連邦中部
- アラブ首長国連邦北部
- 英国南部
- 英国西部
- US Gov アリゾナ
- US Gov テキサス
- US Gov バージニア州
- 西ヨーロッパ
- 米国西部
- 米国西部 2
- 米国西部 3
考慮事項
Azure NetApp Files ネットワークを計画するときは、いくつかの考慮事項を理解している必要があります。
制約
次の表では、各ネットワーク機能構成でサポートされるものについて説明します。
| 機能 | Standard ネットワーク機能 | Basic ネットワーク機能 |
|---|---|---|
| VNet をホストしている Azure NetApp Files のボリュームにアクセスする、Vnet 内の IP の数 (直ちにピアリングされた Vnet を含む) | VM と同じ標準の制限 | 1000 |
| VNet ごとの委任されたサブネットの Azure NetApp Files | 1 | 1 |
| Azure NetApp Files の委任されたサブネット上のネットワーク セキュリティ グループ (NSG) | はい | いいえ |
| Azure NetApp Files の委任されたサブネット上のユーザー定義ルート (UDR) | はい | いいえ |
| プライベート エンドポイントへの接続 | あり* | いいえ |
| サービス エンドポイントへの接続 | はい | いいえ |
| Azure NetApp Files インターフェイス上の Azure ポリシー (カスタム名前付けポリシーなど) | いいえ | いいえ |
| Azure NetApp Files トラフィック用のロード バランサー | いいえ | いいえ |
| デュアル スタック (IPv4 と IPv6) VNet | なし (IPv4 のみサポート) |
なし (IPv4 のみサポート) |
| ピアリングされた VNet から NVA 経由でルーティングされるトラフィック | はい | いいえ |
* プライベート リンク サブネット上の Azure ネットワーク セキュリティ グループを Azure Key Vault に適用することは、Azure NetApp Files カスタマー マネージド キーではサポートされていません。 サブネットでプライベート エンドポイント ネットワーク ポリシーが有効になっていない限り、ネットワーク セキュリティ グループは Private Link への接続に影響しません。 このオプションは無効にしておくことをお勧めします。
サポートされているネットワーク トポロジ
次の表では、Azure NetApp Files の各ネットワーク機能構成によってサポートされているネットワーク トポロジについて説明します。
| トポロジ | Standard ネットワーク機能 | Basic ネットワーク機能 |
|---|---|---|
| ローカル VNet 内のボリュームへの接続 | はい | はい |
| ピアリングされた VNet 内のボリュームへの接続 (同じリージョン) | はい | はい |
| ピアリングされた VNet 内のボリュームへの接続 (クロス リージョンまたはグローバル ピアリング) | あり* | いいえ |
| ExpressRoute ゲートウェイ経由でのボリュームへの接続 | はい | はい |
| ExpressRoute (ER) FastPath | はい | いいえ |
| ExpressRoute ゲートウェイおよびゲートウェイ トランジットとの VNet ピアリングを経由した、オンプレミスからスポーク VNet 内のボリュームへの接続 | はい | はい |
| VPN ゲートウェイを経由した、オンプレミスからスポーク VNet 内のボリュームへの接続 | はい | はい |
| VPN ゲートウェイおよびゲートウェイ トランジットとの VNet ピアリングを経由した、オンプレミスからスポーク VNet 内のボリュームへの接続 | はい | はい |
| アクティブ/パッシブ VPN ゲートウェイを経由した接続 | はい | はい |
| アクティブ/アクティブ VPN ゲートウェイを経由した接続 | はい | いいえ |
| アクティブ/アクティブ ゾーン冗長ゲートウェイを経由した接続 | はい | いいえ |
| アクティブ/パッシブ ゾーン冗長ゲートウェイを経由した接続 | はい | はい |
| Virtual WAN (VWAN) を経由した接続 | はい | いいえ |
* このオプションでは、仮想ネットワーク ピアリング接続を使用するイングレスおよびエグレス トラフィックに料金が発生します。 詳細については、「Virtual Network の価格」を参照してください。 一般情報については、「仮想ネットワーク ピアリング」を参照してください。
Azure NetApp Files ボリューム用の仮想ネットワーク
このセクションでは、仮想ネットワークの計画に役立つ概念について説明します。
Azure 仮想ネットワーク
Azure NetApp Files ボリュームをプロビジョニングする前に、Azure 仮想ネットワーク (VNet) を作成するか、同じサブスクリプションに既に存在するものを使う必要があります。 VNet はボリュームのネットワーク境界を定義します。 仮想ネットワークの作成について詳しくは、Azure Virtual Network のドキュメントを参照してください。
サブネット
サブネットは、仮想ネットワークを個別のアドレス空間に分割し、それらの中にある Azure リソースから使用できるようにするものです。 Azure NetApp Files のボリュームは、委任されたサブネットと呼ばれる特別な目的のサブネットに含まれています。
サブネットの委任では、サブネットにサービス固有のリソースを作成するための明示的なアクセス許可が Azure NetApp Files サービスに与えられます。 サービスのデプロイには一意識別子を使用します。 この場合、Azure NetApp Files への接続を可能にするためにネットワーク インターフェイスが作成されます。
新しい VNet を使用する場合は、「サブネットを Azure NetApp Files に委任する」の手順に従って、サブネットを作成し、そのサブネットを Azure NetApp Files に委任することができます。 他のサービスに委任されていない、既存の空のサブネットを委任することもできます。
VNet が別の VNet とピアリングされている場合、VNet アドレス空間を拡張できません。 そのため、新しい委任されたサブネットは VNet アドレス空間内に作成する必要があります。 アドレス空間を拡張する必要がある場合、アドレス空間を拡張する前に VNet ピアリングを削除する必要があります。
重要
Azure NetApp Files VNet のアドレス空間サイズが、その委任されたサブネットよりも大きいことを確認してください。
たとえば、委任されたサブネットが /24 の場合、サブネットを含む VNet アドレス空間は /23 以上である必要があります。 このガイドラインに準拠しないと、一部のトラフィック パターンで予期しない問題が発生する可能性があります。すなわち、ネットワーク仮想アプライアンス経由で Azure NetApp Files に到達するハブ アンド スポーク トポロジを通過するトラフィックが正しく機能しません。 また、この構成では、SMB および CIFS ボリュームを作成するときに、それらがハブ アンド スポーク ネットワーク トポロジを介して DNS に到達しようとすると、エラーが発生する可能性があります。
また、委任されたサブネットのサイズを少なくとも SAP ワークロードの場合は /25 に、その他のワークロード シナリオの場合は /26 にすることをお勧めします。
UDR と NSG
サブネットに Standard と Basic のネットワーク機能を使用するボリュームの組み合わせがある場合、委任されたサブネットで適用されるユーザー定義ルート (UDR) とネットワーク セキュリティ グループ (NSG) は、Standard ネットワーク機能を使用するボリュームのみに適用されます。
Note
ネットワーク インターフェイス レベルでの NSG の関連付けは、Azure NetApp Files のネットワーク インターフェイスではサポートされていません。
委任されたサブネットのアドレス プレフィックスと NVA としてのネクスト ホップを使用してソース VM サブネットで UDR を構成することは、Basic ネットワーク機能を使用するボリュームではサポートされていません。 そのような設定を行うと、接続の問題が発生します。
Note
VNet ゲートウェイ (ExpressRoute または VPN) とファイアウォールを介してオンプレミス ネットワークから Azure NetApp Files ボリュームにアクセスするには、VNet ゲートウェイに割り当てられたルート テーブルを構成して、リストされている Azure NetApp Files ボリュームの /32 IPv4 アドレスを含め、ネクスト ホップとしてファイアウォールを指すようにします。 Azure NetApp Files ボリュームの IP アドレスを含む集約アドレス空間を使用すると、Azure NetApp Files トラフィックはファイアウォールに転送されません。
Note
VM VNet で UDR ルートを構成し、リージョンで VNet ピアリングされた Azure NetApp Files 標準ボリューム宛てのパケットのルーティングを制御する場合、UDR プレフィックスは、Azure NetApp Files ボリュームの委任されたサブネット サイズとぴったり同じにする必要があります。 委任されたサブネット サイズより UDR プレフィックスのサイズが大きい場合、有効になりません。
Azure ネイティブ環境
次の図は、Azure ネイティブ環境を示しています。
ローカル VNet
基本的なシナリオでは、同じ VNet 内の仮想マシン (VM) から Azure NetApp Files ボリュームを作成するか、それに接続します。 VNet 2 では、ボリューム 1 は委任されたサブネットに作成され、既定のサブネットの VM 1 にマウントすることができます。
VNET ピアリング
互いのリソースへのアクセスを必要とする他の VNet が同じリージョンにある場合、VNet ピアリングを使用して VNet を接続することで、Azure インフラストラクチャを介した安全な接続を実現できます。
上図の VNet 2 と VNet 3 について考えます。 VM 1 が VM 2 とボリューム 2 に接続する必要がある場合、または VM 2 が VM 1 またはボリューム 1 に接続する必要がある場合は、VNet 2 と VNet 3 の間で VNet ピアリングを有効にする必要があります。
また、同じリージョンで VNet 1 が VNet 2 とピアリングされており、VNet 2 が VNet 3 とピアリングされているシナリオを考えます。 VNet 1 のリソースは VNet 2 のリソースに接続できますが、VNet 1 と VNet 3 がピアリングされていない限り、VNet 3 のリソースには接続できません。
上の図で、VM 3 はボリューム 1 に接続できますが、VM 4 はボリューム 2 に接続できません。 この理由は、スポーク VNet がピアリングされておらず、トランジット ルーティングが VNet ピアリング経由ではサポートされない からです。
グローバルまたはリージョン間 VNet ピアリング
次の図は、リージョン間 VNet ピアリングを使用する Azure ネイティブ環境を示しています。
Standard ネットワーク機能を使用すると、VM はグローバルまたはリージョン間の VNet ピアリングを使用して、別のリージョンにあるボリュームに接続できます。 上の図は、ローカル VNet ピアリング セクションの構成に 2 番目のリージョンを追加します。 この図の VNet 4 の場合、Azure NetApp Files ボリュームは委任されたサブネットに作成され、アプリケーション サブネット内の VM5 にマウントできます。
図では、リージョン 1 にある VM2 は、リージョン 2 にあるボリューム 3 に接続できます。 リージョン 2 にある VM5 は、リージョン 1 とリージョン 2 の間の VNet ピアリングを使用して、リージョン 1 にあるボリューム 2 に接続できます。
ハイブリッド環境
次の図は、ハイブリッド環境を示しています。
ハイブリッド シナリオでは、オンプレミスのデータセンターのアプリケーションが Azure のリソースにアクセスする必要があります。 これは、データセンターを Azure に拡張したいのか、Azure ネイティブ サービスを使用したいのか、それともディザスター リカバリーが目的なのかに関係なく当てはまります。 サイト間 VPN または ExpressRoute 経由でオンプレミスの複数のリソースを Azure のリソースに接続する方法については、VPN Gateway の計画オプションに関するページを参照してください。
ハイブリッド ハブスポーク トポロジでは、Azure のハブ VNet は、オンプレミス ネットワークへの主要な接続ポイントとして機能します。 スポークはハブとピアリングされる VNet であり、ワークロードを分離するために使用できます。
構成によっては、オンプレミスのリソースを、ハブおよびスポーク内のリソースに接続できます。
上に示したトポロジでは、オンプレミス ネットワークは Azure のハブ VNet に接続されており、ハブ VNet とピアリングされているのと同じリージョンに 2 つのスポーク VNet があります。 このシナリオで、Azure NetApp Files ボリュームに対してサポートされている接続オプションは次のとおりです。
- オンプレミス リソース VM 1 および VM 2 は、サイト間 VPN または ExpressRoute 回線経由でハブのボリューム 1 に接続できます。
- オンプレミス リソース VM 1 と VM 2 は、サイト間 VPN とリージョンの VNet ピアリング経由で、ボリューム 2 またはボリューム 3 に接続できます。
- ハブ VNet 内の VM 3 は、スポーク VNet 1 内のボリューム 2 と、スポーク VNet 2 内のボリューム 3 に接続できます。
- スポーク VNet 1 の VM 4 と、スポーク VNet 2 の VM 5 は、ハブ VNet 内のボリューム 1 に接続できます。
- スポーク VNet 1 内の VM 4 は、スポーク VNet 2 内のボリューム 3 に接続できません。 また、スポーク VNet 2 内の VM 5 は、スポーク VNet 1 内のボリューム 2 に接続できません。 これは、スポーク VNet がピアリングされておらず、トランジット ルーティングは VNet ピアリング経由ではサポートされていない からです。
- 上記のアーキテクチャでは、スポーク VNet にもゲートウェイがある場合、ハブのゲートウェイを介して接続しているオンプレミスからの ANF ボリュームへの接続が失われます。 仕様により、スポーク VNet のゲートウェイが優先されるため、そのゲートウェイ経由で接続するコンピューターのみが ANF ボリュームに接続できます。