Azure NetApp Files のネットワーク計画のガイドライン

ネットワーク アーキテクチャの計画は、あらゆるアプリケーション インフラストラクチャ設計の重要な要素です。 この記事は、お客様のワークロードに有効なネットワーク アーキテクチャを設計し、Azure NetApp Files の豊富な機能からベネフィットを得るために役立ちます。

Azure NetApp Files のボリュームは、Azure Virtual Network 内の委任されたサブネットと呼ばれる特別な目的のサブネットに含まれるように設計されています。 そのため、仮想ネットワーク (VNet) ピアリング経由で Azure 内から、または仮想ネットワーク ゲートウェイ (ExpressRoute または VPN ゲートウェイ) 経由でオンプレミスから、直接ボリュームにアクセスできます。 サブネットは Azure NetApp Files 専用であり、インターネットへの接続はありません。

新しいボリュームに Standard ネットワーク機能を設定したり、既存のボリュームのネットワーク機能を変更したりするオプションは、Azure NetApp Files が有効になっているすべてのリージョンでサポートされています。

構成可能なネットワーク機能

新しいボリュームを作成するか、既存のボリュームを変更して、Standard または Basic ネットワーク機能を使えるようにすることができます。 詳細については、「ネットワーク機能の構成」を参照してください。

• Standard
  この設定を選択すると、より高い IP 制限と、ネットワーク セキュリティ グループやユーザー定義ルートなどの標準 VNet 機能が委任されたサブネット上で有効になり、この記事で説明されているように追加の接続パターンも有効になります。

• Basic
  この設定を選択すると、「考慮事項」セクションで説明されているように、選択的な接続パターンと制限付き IP スケールが有効になります。 この設定では、すべての制約が適用されます。

考慮事項

Azure NetApp Files ネットワークを計画するときは、いくつかの考慮事項を理解している必要があります。

制約

次の表では、各ネットワーク機能構成でサポートされるものについて説明します。

* プライベート リンク サブネット上の Azure ネットワーク セキュリティ グループを Azure Key Vault に適用することは、Azure NetApp Files カスタマー マネージド キーではサポートされていません。 サブネットでプライベート エンドポイント ネットワーク ポリシーが有効になっていない限り、ネットワーク セキュリティ グループは Private Link への接続に影響しません。 このオプションは無効にしておくことをお勧めします。

サポートされているネットワーク トポロジ

次の表では、Azure NetApp Files の各ネットワーク機能構成によってサポートされているネットワーク トポロジについて説明します。

* このオプションでは、仮想ネットワーク ピアリング接続を使用するイングレスおよびエグレス トラフィックに料金が発生します。 詳細については、「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 ピアリングを削除する必要があります。

ユーザー定義ルート (UDR) とネットワーク セキュリティ グループ (NSG)

サブネットに Standard と Basic のネットワーク機能を使用するボリュームの組み合わせがある場合、委任されたサブネットで適用されるユーザー定義ルート (UDR) とネットワーク セキュリティ グループ (NSG) は、Standard ネットワーク機能を使用するボリュームのみに適用されます。

委任されたサブネットのアドレス プレフィックスと NVA としてのネクスト ホップを使用してソース VM サブネットで UDR を構成することは、Basic ネットワーク機能を使用するボリュームではサポートされていません。 そのような設定を行うと、接続の問題が発生します。

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 ボリュームに接続できます。

次のステップ

• サブネットを Azure NetApp Files に委任する
• Azure NetApp Files ボリュームのネットワーク機能を構成する
• 仮想ネットワーク ピアリング
• Azure NetApp Files 用に Virtual WAN を構成する
• クール アクセスを使用する Azure NetApp Files ストレージ
• クール アクセスを使用する Azure NetApp Files ストレージを管理する