☰

Kurze Antwort

tag-icon • tag-icon azure-networking
Kurze Antwort

Schauen Sie sich das Folgende an: Bildbeschreibung hier eingeben

Hier sehen wir ein einzelnes AZURE-Unternehmenskonto X. Siehe „azsql1.database.windows.net“. Sie können vor Ort darauf zugreifen.

Was wäre, wenn ich der Argumentation halber eine zweite AZURE-Umgebung hätte, die genau gleich konfiguriert ist – AZURE-Firmenkonto Y, mit „azsql1.database.windows.net“.

Es ist zwar theoretisch, aber ich würde gerne wissen, wie die lokale Umgebung das Problem löst, wenn man versucht, „azsql1.database.windows.net“ für einen Verbindungsbericht in beispielsweise Tableau oder Spotfire zu verwenden?

Ich gehe davon aus, dass Sie irgendwie angeben müssen, welcher DNS-Weiterleiter in welchem ​​AZURE-Firmenkonto verwendet werden soll.

Also verzeihen Sie mir, aber ich verstehe etwas von den grundlegenden Dingen zur DNS-Auflösung im Internet, bla bla bla, bin aber kein Netzwerkexperte.

Antwort1

Für andere Leser mit der gleichen Frage: Siehe auchZu verwendende Adresse für den Zugriff auf die private IP-Adresse für AZURE-Ressourcen vor Ortfür einige Hintergrundinformationen.

Bevor ich anfange zu antworten, eine kleine Korrektur zu Ihrer Frage, da Sie "... denselben DNS-Namen" geschrieben haben. Ich denke, das ist ein Missverständnis, da dieAzure Cosmos DBist ein vollständig verwalteter Service, bedeutetPaaSund hat als solches eindeutige Namen. Mit anderen Worten, es ist unmöglich, dass zwei Azure Cosmos DB-Dienste denselben DNS-Namen haben. Trotzdem möchte ich das in der Frage nicht korrigieren, sondern den Verweis lieber als Teil der Antwort haben, da dies tatsächlich ein häufiges Missverständnis ist. Es läuft alles auf die Art und Weise hinaus, wie die Namensauflösung einer Hybridlösung aufgebaut ist.

Ein solches Szenario lässt sich leicht auflösen, indem Sie eindeutige DNS-Namen verwenden (was kein Problem darstellt, da CosmosDB ein SaaS-System ist und daher eindeutige Namen hat) und sicherstellen, dass alle Ressourcen aufgelöst werden können.

Kurze Antwort

Konfigurieren Sie für jedes Ihrer Abonnements unter einem Firmenkonto, das über ExpressRoute oder VPN mit dem lokalen Computer verbunden ist, einePrivates Azure-DNSund ein DNS-Forwarder, der im selben Subnetz eingesetzt wird. Ein Hub verbindet alles, auch vor Ort.

Lange Antwort

Hypothetisches Beispiel (Missionsdefinition)

Die Funktionsweise lässt sich am besten anhand eines Beispiels erklären.

Angesichts der hypothetischen Unternehmens-"NKOTBINC" hat 3 Abteilungen:

  • Finanzen
  • ES
  • Marketing

Jede Abteilung betreibt zwei Azure-Abonnements, eines für die Entwicklung und eines für die Produktionsarbeitslast. Wir müssen also insgesamt mindestens sechs Abonnements verwalten, um die Anforderungen zu erfüllen.

Die netzwerkbezogenen Anforderungen sind die folgenden:

  • Jedes Abonnement muss über eine Verbindung zum lokalen Standort verfügen.
  • Jedes Abonnement kann Ressourcen verwenden, die über private Links bereitgestellt werden, muss dies aber nicht.
  • Aufgrund rechtlicher Einschränkungen werden derzeit alle Ressourcen in allen Abonnements bereitgestellt innerhalbRegion"Ost der USA".
  • Eine Ausweitung des Geschäftsbetriebs auf weitere Regionen ist geplant und sollte daher bei der Planung berücksichtigt werden.

Implementierungsansatz

In diesem Szenario verfügen Sie möglicherweise über mindestens 7 Abonnements:

  • Dev-Finanzen
  • prd-finanzen
  • Entwickler
  • prd-es
  • Entwickler-Marketing
  • PRD-Marketing
  • Nabedie über VPN oder ExpressRoute eine Verbindung zum Standort herstellt.

Alle sechs Abonnements müssen einen privaten Azure-DNS und einen DNS-Forwarder bereitstellen. Darüber hinaus verwenden alle ein VNET, das mit dem zentralen Hub-Abonnement verbunden ist. Am Ende erhalten Sie also diese sieben internen DNS-Domänen:

  • dev.finance.eastus.azure.nkotb
  • prd.finance.eastus.azure.nkotb
  • dev.it.eastus.azure.nkotb
  • prd.it.eastus.azure.nkotb
  • dev.marketing.eastus.azure.nkotb
  • prd.marketing.eastus.azure.nkotb
  • hub.eastus.azure.nkotb

NKOTB Inc. – Überblick über die Netzwerkkonnektivität auf hoher Ebene

Für das Hub-Abonnement ist ein zweiter Satz DNS-Server und Weiterleitungen konfiguriert. Nur dieser Satz DNS-Server kennt die anderen sieben DNS-Weiterleitungen, die in den anderen Domänen bereitgestellt werden und für die Namensauflösung der Domäne „eastus.azure.nkotb“ verantwortlich sind. Alle lokalen DNS-Server sind so konfiguriert, dass sie alle DNS-Anfragen für *.eastus.azure.nkotb an diesen Satz DNS-Server weiterleiten.

Beispiel 1: internes DNS zwischen einem Abonnement und vor Ort

Angenommen, das Finanzteam beschließt, innerhalb des Produktionsabonnements eine Datenbank mit dem Namen „Alzheimer“ über einen privaten Link bereitzustellen. Der interne DNS-Name (FQDN) für diese Datenbank wäre also alzheimer.prd.finance.eastus.azure.nkotb. Dank der internen Namensauflösung, die für alle Abonnements und auch vor Ort einheitlich ist, könnte dieser Name überall im Unternehmensnetzwerk aufgelöst werden.

So funktioniert Beispiel 1

  • Ein zufälliger Client vor Ort fordert den dortigen lokalen DNS-Server zur Auflösung auf alzheimer.prd.finance.eastus.azure.nkotb.
  • Der lokale DNS-Server kennt die Antwort nicht, ist aber so konfiguriert, dass er alle Anfragen an *.eastus.azure.nkotbden im Hub-Abonnement bereitgestellten DNS-Forwarder weiterleitet. Dieser DNS-Server ist (netzwerktechnisch) erreichbar, da die lokale Umgebung über ExpressRoute/VPN mit diesem Hub-Abonnement verbunden ist.
  • Der im Hub-Abonnement eingesetzte DNS-Forwarder kennt die Antwort nicht, kennt aber den im Production Finance-Abonnement eingesetzten DNS-Forwarder, sodass die Anfrage in diese Richtung weitergeleitet wird. Dieser DNS-Server ist (netzwerkmäßig) erreichbar, da beide Abonnements über Peering-VNETs verfügen.
  • Der in prd.finance.eastus.azure.nkotb eingesetzte DNS-Server und -Forwarder können die IP-Adresse der Datenbank auflösen und senden die Antwort in der Kette zurück.
  • Die Antwort erhält der Client vor Ort.
  • Jede nachfolgende DNS-Anfrage (innerhalb der TTL des Eintrags) wird sofort vom lokalen DNS-Server beantwortet, da die Antwort zwischengespeichert wurde.

Beispiel 2: Interner DNS zwischen 2 Abonnements

Angenommen, das Marketingteam beschließt, eine Datenbank mit dem Namen „Ballyhoo“ innerhalb des Entwicklungsabonnements bereitzustellen, wäre der interne DNS-Name ballyhoo.dev.marketing.eastus.azure.nkotb. Wie die andere von der Finanzabteilung bereitgestellte Datenbank kann diese Datenbank auch vor Ort aufgelöst werden. In diesem Szenario sammelt das IT-Team jedoch einige Daten innerhalb des IT-Entwicklungsabonnements, die in einer ballyhoo.dev.marketing.eastus.azure.nkotbDatenbank gespeichert werden sollten. Dieses Szenario beschreibt also, wie ein DNS-Eintrag innerhalb von 2 Abonnements aufgelöst werden kann.

So funktioniert Beispiel 2

  • Die im dev-IT-Abonnement bereitgestellte Datensammlungs-App fragt den im selben VNET bereitgestellten lokalen DNS-Resolver nach der IP-Adresse von ballyhoo.dev.marketing.eastus.azure.nkotb.
  • Der lokale DNS-Server kennt die Antwort nicht, ist aber so konfiguriert, dass er alle Anfragen an den im Hub-Abonnement bereitgestellten DNS-Forwarder weiterleitet, also kennt er sie. Dieser DNS-Server ist (netzwerkmäßig) erreichbar, da beide Abonnements über Peering-VNETs verfügen.
  • Der im Hub-Abonnement eingesetzte DNS-Forwarder kennt die Antwort nicht, kennt aber den im Dev-Marketing-Abonnement eingesetzten DNS-Forwarder, sodass die Anfrage in diese Richtung weitergeleitet wird. Dieser DNS-Server ist (netzwerkmäßig) erreichbar, da beide Abonnements über Peering-VNETs verfügen.
  • Der in dev.marketing.eastus.azure.nkotb eingesetzte DNS-Server und -Forwarder können die IP-Adresse der Datenbank auflösen und senden die Antwort in der Kette zurück.
  • Die Antwort erhält die Datenerfassungs-App.
  • Jede nachfolgende DNS-Anfrage (innerhalb der TTL des Eintrags) wird sofort vom lokalen DNS-Server beantwortet, da die Antwort zwischengespeichert wurde.

Anmerkungen

Ihr Business-Kontakt in Azure hilft Ihnen normalerweise bei der Planung solcher Szenarien, sodass Sie nicht alles selbst ausarbeiten müssen. Es gibt noch weitere wichtige Aspekte, die während des Planungsprozesses berücksichtigt werden müssen, aber der Platz reicht hier nicht aus, um sie alle zu skizzieren. Erkenntnis: Es hilft normalerweise, wenn das Netzwerkteam von Anfang an in den Prozess einbezogen wird.

Generell empfehle ich die kostenloseMicrosoft Learn für Azureum die notwendigen Kenntnisse und Fähigkeiten aufzubauen. Für Ihre Fragen wären folgende Kurse geeignet:

verwandte Informationen