☰

簡単な回答

tag-icon • tag-icon azure-networking
簡単な回答

以下を見てください: ここに画像の説明を入力してください

ここでは、単一の AZURE 企業アカウント X が表示されます。「azsql1.database.windows.net」を参照してください。オンプレミスからアクセスできます。

議論のために、2 番目の AZURE 環境 (AZURE 企業アカウント Y、"azsql1.database.windows.net") がまったく同じように構成されているとしたらどうなるでしょうか。

理論上の話ですが、Tableau、Spotfire などの接続レポートに「azsql1.database.windows.net」を使用しようとした場合にオンプレミスでこの問題がどのように解決されるのか知りたいです。

何らかの方法で、どの AZURE 企業アカウントでどの DNS フォワーダーを使用するかを指定する必要があると思われます。

申し訳ありませんが、私はインターネットの基本的な DNS 解決については理解していますが、ネットワークの専門家ではありません。

答え1

同じ疑問を持つ他の読者へ：こちらもご覧くださいオンプレミスから AZURE リソースのプライベート IP アドレスにアクセスするために使用するアドレス背景情報についてはこちらをご覧ください。

質問に対するちょっとした訂正に答える前に、あなたが「...同じDNS名」と書いたように、これは誤解だと思います。Azure の Cosmos DB完全に管理されたサービスであるため、パースそのため、名前は一意です。つまり、2 つの Azure Cosmos DB サービスが同じ DNS 名を持つことは不可能です。それでも、質問の中でそれを訂正したくはありません。これは確かによくある誤解なので、回答の一部として参照することを希望します。結局のところ、ハイブリッド ソリューションの名前解決が設計される方法に帰着します。

このようなシナリオを解決するのは簡単です。一意の DNS 名 (CosmosDB は SaaS であり、一意の名前を持っているため、これは問題ではありません) を使用し、すべてのリソースを解決できるようにすることで解決できます。

簡単な回答

ExpressRouteまたはVPN経由でオンプレミスに接続された企業アカウントのサブスクリプションごとに、Azure プライベート DNS同じサブネット内に展開される DNS フォワーダー。ハブはオンプレミスを含むすべてを接続します。

長い回答

仮説例（ミッション定義）

どのように機能するかについては、例を使って説明したほうがよいでしょう。

仮想的な企業「NKOTB さんINCには3つの部門があります。

  • ファイナンス
  • それ
  • マーケティング

各部門は 2 つの Azure サブスクリプションを運用しており、1 つは開発用、もう 1 つは運用ワークロード用です。したがって、要件を満たすには、合計で少なくとも 6 つのサブスクリプションを処理する必要があります。

ネットワーク関連の要件は次のとおりです。

  • すべてのサブスクリプションはオンプレミスに接続できる必要があります。
  • すべてのサブスクリプションは、プライベート リンクを使用してデプロイされたリソースを使用する場合と使用しない場合があります。
  • 法的制限により、すべてのサブスクリプション内のすべてのリソースは現在、地域「米国東部」。
  • 将来的には他の地域にも事業を拡大していく予定なので、計画時にはこの点も考慮する必要があります。

実装アプローチ

このシナリオを使用すると、少なくとも 7 つのサブスクリプションが作成される可能性があります。

  • 開発金融
  • prd-ファイナンス
  • 開発
  • prd-it
  • 開発マーケティング
  • prdマーケティング
  • ハブVPN または ExpressRoute 経由でオンプレミスに接続します。

6 つのサブスクリプションすべてに、Azure プライベート DNS と DNS フォワーダーをデプロイする必要があります。さらに、それらはすべて、中央のハブ サブスクリプションにピアリングされた VNET を使用します。そのため、最終的には次の 7 つの内部 DNS ドメインが作成されます。

  • dev.finance.eastus.azure.nkotb
  • 出典: prd.finance.eastus.azure.nkotb
  • dev.it.eastus.azure.nkotb
  • 翻訳元:
  • dev.marketing.eastus.azure.nkotb
  • 翻訳元:
  • ハブ

NKOTB inc - 高レベルのネットワーク接続の概要

ハブ サブスクリプションには、2 番目の DNS サーバーとフォワーダーのセットが構成されています。この DNS サーバーのセットのみが、他のドメインに展開されている他の 7 つの DNS フォワーダーを認識し、ドメイン "eastus.azure.nkotb" の名前解決を担当します。すべてのオンプレミス DNS サーバーは、*.eastus.azure.nkotb のすべての DNS 要求をこの DNS サーバーのセットに転送するように構成されています。

例 1: サブスクリプションとオンプレミス間の内部 DNS

財務チームが、プライベート リンクを使用して、運用サブスクリプション内に「Alzheimer」という名前のデータベースを展開することを決定したとします。したがって、このデータベースの内部 DNS 名 (FQDN) は になりますalzheimer.prd.finance.eastus.azure.nkotb。すべてのサブスクリプションとオンプレミスで調整された内部名前解決により、この名前は企業ネットワーク内のどこでも解決できます。

例1の仕組み

  • オンプレミスにあるランダムなクライアントが、ローカル DNS サーバーに解決を要求していますalzheimer.prd.finance.eastus.azure.nkotb。
  • ローカル DNS サーバーは答えを知りませんが、*.eastus.azure.nkotbハブ サブスクリプション内に展開された DNS フォワーダーにすべての要求を転送するように構成されているため、答えがわかります。オンプレミスは ExpressRoute/VPN 経由でこのハブ サブスクリプションに接続されているため、この DNS サーバーは (ネットワーク的に) アクセス可能です。
  • ハブ サブスクリプション内にデプロイされた DNS フォワーダーは答えを知りませんが、運用環境の財務サブスクリプションにデプロイされた DNS フォワーダーを認識しているため、要求はこの方向に転送されます。両方のサブスクリプションがピアリングされた VNET を持っているため、この DNS サーバーは (ネットワーク的に) 到達可能です。
  • prd.finance.eastus.azure.nkotb にデプロイされた DNS サーバーとフォワーダーは、データベースの IP アドレスを解決し、チェーン内で応答を返します。
  • オンプレミスにあるクライアントが回答を受け取ります。
  • 各フォローアップ DNS 要求 (レコードの TTL 内) は、回答がキャッシュされているため、ローカル DNS サーバーからすぐに応答されます。

例 2: 2 つのサブスクリプション間の内部 DNS

マーケティング チームが開発サブスクリプション内に「Ballyhoo」という名前のデータベースを展開することに決めた場合、内部 DNS 名は になりますballyhoo.dev.marketing.eastus.azure.nkotb。財務部門によって展開された他のデータベースと同様に、このデータベースもオンプレミスから解決できます。ただし、このシナリオでは、IT チームが IT 開発サブスクリプション内でいくつかのデータを収集し、それをballyhoo.dev.marketing.eastus.azure.nkotbデータベースを使用して保存する必要があります。したがって、このシナリオでは、2 つのサブスクリプション内で DNS レコードを解決する方法について説明します。

例2の仕組み

  • dev-IT サブスクリプションにデプロイされたデータ収集アプリは、同じ VNET 内にデプロイされたローカル DNS リゾルバーに の IP アドレスを要求します ballyhoo.dev.marketing.eastus.azure.nkotb。
  • ローカル DNS サーバーは答えを知りませんが、ハブ サブスクリプション内に展開された DNS フォワーダーにすべての要求を転送するように構成されているため、答えがわかります。両方のサブスクリプションがピアリングされた VNET を持っているため、この DNS サーバーは (ネットワーク的に) 到達可能です。
  • ハブ サブスクリプション内にデプロイされた DNS フォワーダーは回答を知りませんが、開発マーケティング サブスクリプションにデプロイされた DNS フォワーダーを認識しているため、要求はこの方向に転送されます。両方のサブスクリプションがピアリングされた VNET を持っているため、この DNS サーバーは (ネットワーク的に) 到達可能です。
  • dev.marketing.eastus.azure.nkotb にデプロイされた DNS サーバーとフォワーダーは、データベースの IP アドレスを解決し、チェーン内で応答を返します。
  • データ収集アプリが回答を受け取ります。
  • 各フォローアップ DNS 要求 (レコードの TTL 内) は、回答がキャッシュされているため、ローカル DNS サーバーからすぐに応答されます。

ノート

通常、Azure のビジネス担当者がこのようなシナリオの計画を手伝ってくれるので、すべてを自分で考える必要はありません。計画プロセス中に考慮すべき重要な側面は他にもありますが、スペースの都合上、ここですべてを概説することはできません。実現: 通常、ネットワーク チームが最初からプロセスに含まれていると役立ちます。

一般的に、私は無料のものを使用することを強くお勧めしますAzure 向け Microsoft Learn必要な知識とスキルを身に付けるために、以下のコースが適切でしょう。

関連情報