Freigeben über

Herstellen einer Verbindung zwischen einer Anwendung und Azure SQL Managed Instance

  • Artikel

Gilt für: Azure SQL Managed Instance

In diesem Artikel wird beschrieben, wie Sie eine Anwendung in verschiedenen Anwendungsszenarien innerhalb oder zwischen virtuellen Azure-Netzwerken mit Azure SQL Managed Instance verbinden können.

Heutzutage haben Sie mehrere Möglichkeiten bei der Wahl, wie und wo Sie Anwendungen hosten. Beispielsweise können Sie eine Anwendung unter Verwendung von Azure App Service oder einiger der integrierten Optionen des virtuellen Netzwerks (VNET) von Azure (z. B. Azure App Service-Umgebung, Azure Virtual Machines und VM-Skalierungsgruppen) in der Cloud hosten. Alternativ können Sie auch den Hybrid Cloud-Ansatz wählen und Ihre Anwendungen lokal hosten. Wie Sie sich auch entscheiden, Sie können eine Anwendung in verschiedenen Anwendungsszenarien innerhalb oder zwischen virtuellen Azure-Netzwerken mit Azure SQL Managed Instance verbinden.

Darüber hinaus können Sie den Datenzugriff auf Ihre verwaltete Instanz auch von außerhalb eines virtuellen Netzwerks aktivieren, z. B. von mehrinstanzenfähigen Azure-Diensten wie Power BI und Azure App Service oder aus einem lokalen Netzwerk, das nicht über VPN mit Ihren virtuellen Netzwerken verbunden ist. Informationen zu diesen und ähnlichen Szenarien finden Sie unter Konfigurieren eines öffentlichen Endpunkts in Azure SQL Managed Instance.

Diagramm, das hohe Verfügbarkeit veranschaulicht.

Herstellen einer Verbindung innerhalb desselben VNET

Das Verbinden einer Anwendung innerhalb desselben virtuellen Netzwerks wie SQL Managed Instance ist das einfachste Szenario. Zwischen virtuellen Computern innerhalb des virtuellen Netzwerks kann eine direkte Verbindung hergestellt werden, auch wenn sie sich in unterschiedlichen Subnetzen befinden. Zum Herstellen einer Verbindung mit einer Anwendung in einer App Service-Umgebung oder auf einer VM, die im gleichen virtuellen Netzwerk wie SQL Managed Instance bereitgestellt ist, müssen Sie also lediglich die Verbindungszeichenfolge so konfigurieren, dass sie auf ihren lokalen VNet-Endpunkt abzielt.

Herstellen einer Verbindung aus einem anderen VNet

Für das Verbinden einer Anwendung, die sich in einem anderen virtuellen Netzwerk als SQL Managed Instance befindet, ist es zunächst erforderlich, dass die Anwendung Zugriff auf das virtuelle Netzwerk erhält, in dem SQL Managed Instance bereitgestellt ist, oder auf die SQL Managed Instance selbst. Die beiden virtuellen Netzwerke brauchen nicht demselben Abonnement anzugehören.

Es gibt drei Optionen zum Herstellen einer Verbindung mit einer SQL Managed Instance in einem anderen virtuellen Netzwerk:

Von den drei sind private Endpunkte die sicherste und ressourcensparendste Option, da sie:

  • nur die SQL Managed Instance aus ihrem virtuellen Netzwerk verfügbar machen
  • nur unidirektionale Konnektivität zulassen
  • nur eine IP-Adresse im virtuellen Netzwerk der Anwendung erfordern

Wenn private Endpunkte die Anforderungen Ihres Szenarios nicht vollständig erfüllen können, sollten Sie stattdessen das Peering virtueller Netzwerke in Betracht ziehen. Peering verwendet das Azure-Backbone-Netzwerk, sodass keine spürbaren Latenzeinbußen für die Kommunikation über virtuelle Netzwerkgrenzen hinweg auftreten. Das Peering virtueller Netzwerke wird zwischen Netzwerken in allen Regionen unterstützt (globales Peering virtueller Netzwerke), während Instanzen, die in Subnetzen gehostet werden, die vor dem 22. September 2020 erstellt wurden, nur Peering innerhalb ihrer Region unterstützen.

Herstellen einer Verbindung mit einer lokalen Anwendung

Sie können Ihre lokale Anwendung mit dem lokalen VNet-Endpunkt Ihrer Instanz von SQL Managed Instance verbinden. Für den Zugriff darauf in der lokalen Umgebung müssen Sie eine Site-zu-Site-Verbindung zwischen der Anwendung und dem virtuellen Netzwerk von SQL Managed Instance herstellen. Wenn der reine Datenzugriff auf Ihre verwaltete Instanz ausreichend ist, können Sie eine Verbindung mit ihr von außerhalb eines virtuellen Netzwerks über einen öffentlichen Endpunkt herstellen. Weitere Informationen finden Sie unter Konfigurieren eines öffentlichen Endpunkts in Azure SQL Managed Instance.

Es gibt zwei Optionen, um eine Verbindung einer lokalen Anwendung mit einem virtuellen Azure-Netzwerk herzustellen:

Wenn Sie eine lokale Verbindung mit Azure hergestellt haben und keine Verbindung mit SQL Managed Instance herstellen können, prüfen Sie, ob für die Firewall eine geöffnete ausgehende Verbindung an SQL-Port 1433 und der Portbereich 11000–11999 für die Umleitung festgelegt sind.

Herstellen einer Verbindung mit einer Dev-Box

Es ist auch möglich, Ihre Dev-Box mit SQL Managed Instance zu verbinden. Um von der Dev-Box aus über das virtuelle Netzwerk darauf zugreifen zu können, müssen Sie zunächst eine Verbindung zwischen Ihrer Dev-Box und dem virtuellen Netzwerk der SQL Managed Instance herstellen. Konfigurieren Sie hierfür eine Point-to-Site-Verbindung mit einem virtuellen Netzwerk unter Verwendung der nativen Azure-Zertifikatauthentifizierung. Weitere Informationen finden Sie unter Konfigurieren einer Point-to-Site-Verbindung von einem lokalen Computer zu einer Azure SQL Managed Instance-Instanz.

Informationen zum Datenzugriff auf Ihre verwaltete Instanz von außerhalb eines virtuellen Netzwerks finden Sie unter Konfigurieren eines öffentlichen Endpunkts in Azure SQL Managed Instance.

Herstellen einer Verbindung mit einem Spoke-Netzwerk

Ein weiteres häufiges Szenario liegt vor, wenn ein VPN-Gateway in einem von dem virtuellen Netzwerk, in dem SQL Managed Instance gehostet ist (Hub-Netzwerk), separaten virtuellen Netzwerk (und möglicherweise Abonnement) installiert ist (Spoke-Netzwerk). Die Konnektivität mit SQL Managed Instance aus dem Spoke-Netzwerk wird über eine der unter Herstellen einer Verbindung aus einem anderen VNet aufgeführten Optionen konfiguriert: private Endpunkte, VNet-Peering oder ein VNet-zu-VNet-Gateway.

Das folgende Beispielarchitekturdiagramm zeigt das VNet-Peering:

Diagramm zu Peering virtueller Netzwerke.

Achten Sie beim Peering von Hub-and-Spoke-Netzwerken darauf, dass das VPN-Gateway die IP-Adressen aus dem Hub-Netzwerk sieht. Nehmen Sie dazu unter Peeringeinstellungen die folgenden Änderungen vor:

  1. Navigieren Sie in dem virtuellen Netzwerk, das das VPN-Gateway hostet (Spoke-Netzwerk), zu Peerings. Wechseln Sie zu der Verbindung, die mittels Peering zwischen SQL Managed Instance und dem virtuellen Netzwerk hergestellt wurde, und wählen Sie Gatewaytransit zulassen aus.
  2. Navigieren Sie in dem virtuellen Netzwerk, das die SQL Managed Instance hostet (Hub-Netzwerk), zu Peerings. Wechseln Sie zu der Verbindung, die mittels Peering zwischen dem VPN-Gateway und dem virtuellen Netzwerk hergestellt wurde, und wählen Sie Remotegateways verwenden aus.

Herstellen einer Verbindung mit Azure App Service

Sie können auch eine Verbindung mit einer von Azure App Service gehosteten Anwendung herstellen, wenn sie in Ihr virtuelles Netzwerk integriert ist. Wählen Sie hierzu einen der unter Herstellen einer Verbindung aus einem anderen VNET aufgeführten Mechanismen aus. Informationen zum Datenzugriff auf Ihre verwaltete Instanz von außerhalb eines virtuellen Netzwerks finden Sie unter Konfigurieren eines öffentlichen Endpunkts in Azure SQL Managed Instance.

Ein Sonderfall beim Herstellen einer Verbindung zwischen Azure App Service mit SQL Managed Instance besteht, wenn Sie Azure App Service in ein Netzwerk integriert haben, das mittels Peering mit dem virtuellen Netzwerk von SQL Managed Instance verbunden ist. In diesem Fall muss die folgende Konfiguration eingerichtet werden:

  • Das virtuelle Netzwerk von SQL Managed Instance darf KEIN Gateway aufweisen.
  • Für das virtuelle Netzwerk von SQL Managed Instance muss die Option Use remote gateways festgelegt sein.
  • Für das virtuelle Netzwerk mit Peering muss die Option Allow gateway transit festgelegt sein.

Dieses Szenario ist in der folgenden Abbildung dargestellt:

Diagramm zum Peering von integrierten Apps.

Hinweis

Bei der von einem Gateway abhängigen VNET-Integration wird eine App nicht in ein virtuelles Netzwerk mit einem ExpressRoute-Gateway integriert. Auch wenn das ExpressRoute-Gateway im Koexistenzmodus konfiguriert ist, funktioniert die VNET-Integration nicht. Wenn Sie über eine ExpressRoute-Verbindung auf Ressourcen zugreifen müssen, können Sie dazu eine App Service-Umgebung nutzen, die in Ihrem virtuellen Netzwerk ausgeführt wird.

Informationen zur Problembehandlung des Azure App Service-Zugriffs über ein virtuelles Netzwerk finden Sie unter Problembehandlung für virtuelle Netzwerke und Anwendungen.

Behandeln von Konnektivitätsproblemen

Überprüfen Sie zur Behandlung von Konnektivitätsproblemen die folgenden Punkte:

  • Wenn Sie innerhalb des gleichen virtuellen Netzwerks, aber in einem anderen Subnetz, keine Verbindung zwischen einer Azure-VM und SQL Managed Instance herstellen können, prüfen Sie, ob im VM-Subnetz eine Netzwerksicherheitsgruppe festgelegt ist, die möglicherweise den Zugriff blockiert. Beachten Sie außerdem, dass Sie ausgehende Verbindungen an SQL-Port 1433 sowie Ports im Bereich von 11000–11999 öffnen müssen, da diese zum Herstellen einer Verbindung per Umleitung innerhalb der Azure-Begrenzung benötigt werden.

  • Stellen Sie sicher, dass die Verteilung von Gatewayrouten für die Routingtabelle, die dem virtuellen Netzwerk zugeordnet ist, deaktiviert ist.

  • Wenn Sie ein Point-to-Site-VPN verwenden, überprüfen Sie, ob in der Konfiguration im Azure-Portal Zahlen zu Eingehend/Ausgehend angezeigt werden. Zahlen ungleich 0 geben an, dass Datenverkehr von Azure in bzw. aus lokalen Umgebungen weitergeleitet wird.

    Screenshot mit Zahlen für Eingehend/Ausgehend im Azure-Portal.

  • Stellen Sie sicher, dass der Clientcomputer (auf dem der VPN-Client ausgeführt wird) für alle virtuellen Netzwerke Routingeinträge enthält, auf die Sie zugreifen müssen. Die Routen werden in %AppData%\Roaming\Microsoft\Network\Connections\Cm\<GUID>\routes.txt gespeichert.

    Screenshot der Datei „route.txt“.

    Wie in dieser Abbildung gezeigt wird, gibt es zwei Einträge für jedes beteiligte virtuelle Netzwerk und einen dritten Eintrag für den VPN-Endpunkt, der im Portal konfiguriert ist.

    Eine weitere Möglichkeit, die Routen zu überprüfen, bietet der folgende Befehl. Die Ausgabe zeigt die Routen zu den verschiedenen Subnetzen:

    C:\ >route print -4
===========================================================================
Interface List
14...54 ee 75 67 6b 39 ......Intel(R) Ethernet Connection (3) I218-LM
57...........................rndatavnet
18...94 65 9c 7d e5 ce ......Intel(R) Dual Band Wireless-AC 7265
1...........................Software Loopback Interface 1
Adapter===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
        0.0.0.0          0.0.0.0       10.83.72.1     10.83.74.112     35
       10.0.0.0    255.255.255.0         On-link       172.26.34.2     43
       10.4.0.0    255.255.255.0         On-link       172.26.34.2     43
===========================================================================
Persistent Routes:
None

  • Stellen Sie beim VNET-Peering sicher, dass Sie die Anweisungen für die Einstellung „Gatewaytransit zulassen“ und „Remotegateways verwenden“ befolgt haben.

  • Wenn Sie das VNET-Peering zum Verbinden einer in Azure App Service gehosteten Anwendung verwenden und das virtuelle Netzwerk von SQL Managed Instance über einen öffentlichen IP-Adressbereich verfügt, stellen Sie sicher, dass die Einstellungen Ihrer gehosteten Anwendung das Weiterleiten des ausgehenden Datenverkehrs an öffentliche IP-Netzwerke zulassen. Befolgen Sie die Anweisungen unter Regionale Integration des virtuellen Netzwerks.

Zwar funktionieren ältere Versionen möglicherweise, in der folgenden Tabelle sind jedoch die empfohlenen Mindestversionen der Tools und Treiber für Verbindungen mit SQL Managed Instance aufgeführt:

Treiber/Tool Version
.NET Framework 4.6.1 (oder .NET Core)
ODBC-Treiber v17
PHP-Treiber 5.2.0
JDBC-Treiber 6.4.0
Node.js-Treiber 2.1.1
OLEDB-Treiber 18.0.2.0
SSMS 18.0 oder höher
SMO 150 oder höher

Zugehöriger Inhalt