Freigeben über

Konnektivitätsarchitektur für Azure SQL Managed Instance

Gilt für:Azure SQL Managed Instance

In diesem Artikel wird die Konnektivitätsarchitektur von Azure SQL Managed Instance beschrieben und erläutert, wie Komponenten den Kommunikationsdatenverkehr für eine verwaltete SQL-Instanz leiten.

Übersicht

In sql Managed Instance wird eine Instanz innerhalb des virtuellen Azure-Netzwerks und im Subnetz platziert, das sql-verwalteten Instanzen zugeordnet ist. Die Bereitstellung bietet Folgendes:

  • Eine sichere IP-Adresse im lokalen virtuellen Netzwerk (VNet).
  • Die Möglichkeit, eine Verbindung von einem lokalen Netzwerk mit SQL Managed Instance herzustellen.
  • Die Möglichkeit, eine Verbindung von SQL Managed Instance mit einem Verbindungsserver oder einem anderen lokalen Datenspeicher herzustellen.
  • Die Möglichkeit, eine Verbindung von SQL Managed Instance mit Azure-Ressourcen herzustellen.

Verbindungsarchitektur auf Makroebene

Die verwaltete SQL-Instanz besteht aus Dienstkomponenten, die auf einer dedizierten Gruppe isolierter virtueller Computer gruppiert werden, die nach ähnlichen Konfigurationsattributen gruppiert und mit einem virtuellen Cluster verbunden sind. Einige Dienstkomponenten werden innerhalb des virtuellen Netzwerksubnetz des Kunden bereitgestellt, während andere Dienste in einer sicheren Netzwerkumgebung arbeiten, die Microsoft verwaltet.

Diagramm: allgemeine Konnektivitätsarchitektur für Azure SQL Managed Instance nach November 2022

Kundenanwendungen können eine Verbindung mit SQL Managed Instance herstellen und Datenbanken innerhalb des virtuellen Netzwerks, des mittels Peering verknüpften virtuellen Netzwerks oder des durch VPN oder Azure ExpressRoute verbundenen Netzwerks abfragen und aktualisieren.

Die folgende Abbildung zeigt Entitäten, die eine Verbindung mit SQL Managed Instance herstellen. Außerdem werden die Ressourcen angezeigt, die mit einer von SQL verwalteten Instanz kommunizieren müssen. Der Kommunikationsvorgang im unteren Diagrammbereich bezieht sich auf Kundenanwendungen und Tools, die eine Verbindung mit SQL Managed Instance als Datenquelle herstellen.

Diagramm: Entitäten in der Konnektivitätsarchitektur für Azure SQL Managed Instance nach November 2022

SQL Managed Instance ist ein PaaS-Angebot (Platform-as-a-Service) mit einem Mandanten, das auf zwei Ebenen funktioniert: einer Datenebene und einer Steuerungsebene.

Die Datenebene wird aus Gründen der Kompatibilität, Konnektivität und Netzwerkisolation im Subnetz des Kunden bereitgestellt. Die Datenebene hängt von Azure-Diensten wie Azure Storage, Microsoft Entra ID (früher Azure Active Directory) für die Authentifizierung und Telemetriesammlungsdienste ab. Aus Subnetzen mit SQL Managed Instance stammender Datenverkehr wird an diese Dienste weitergeleitet.

Auf der Steuerungsebene werden die Funktionen für Bereitstellung, Verwaltung und Kerndienstverwaltung über automatisierte Agents ausgeführt. Diese Agents haben exklusiven Zugriff auf die Computeressourcen, die den Dienst betreiben. Sie können keine SSH- oder Remotedesktopprotokoll verwenden, um auf diese Hosts zuzugreifen. Die gesamte Kommunikation der Steuerungsebene wird mithilfe von Zertifikaten verschlüsselt und signiert. Um die Vertrauenswürdigkeit der Kommunikationspartner sicherzustellen, überprüft SQL Managed Instance diese Zertifikate regelmäßig anhand von Zertifikatsperrlisten.

Kommunikationsübersicht

Anwendungen können über drei Endpunkttypen eine Verbindung mit SQL Managed Instance herstellen: lokale VNet-Endpunkte, öffentliche Endpunkte und private Endpunkte. Diese Endpunkte weisen unterschiedliche Eigenschaften und Verhaltensweisen auf, die für unterschiedliche Szenarien geeignet sind.

Diagramm, das den Sichtbarkeitsbereich für lokale VNet-, öffentliche und private Endpunkte zu einer Azure SQL Managed Instance-Instanz zeigt

Lokaler VNET-Endpunkt

Der lokale VNET-Endpunkt ist die Standardeinstellung für die Verbindung mit SQL Managed Instance. Der Domänenname des VNet-lokalen Endpunkts befindet sich in Form von <mi_name>.<dns_zone>.database.windows.net. Dieser Domänenname wird aus dem Adressbereich des Subnetzes in eine IP-Adresse aufgelöst. Verwenden Sie den VNet-lokalen Endpunkt, um in allen Standardkonnektivitätsszenarien eine Verbindung mit einer von SQL verwalteten Instanz herzustellen. Der VNet-lokale Endpunkt akzeptiert Verbindungen am Port 1433.

Der VNet-lokale Endpunkt unterstützt Proxy- und Umleitungsverbindungstypen.

Wenn Sie eine Verbindung mit dem VNet-lokalen Endpunkt herstellen, verwenden Sie immer ihren Domänennamen, und lassen Sie eingehenden Datenverkehr für die erforderlichen Ports im gesamten Subnetzbereich zu, da sich die zugrunde liegende IP-Adresse gelegentlich ändern kann.

Um den Domänennamen des VNet-lokalen Endpunkts für eine Instanz zu finden:

  • Azure-Portal: Im Bereich "Übersicht " im Abschnitt "Essentials " zeigt der Hostwert den Domänennamen des lokalen VNet-Endpunkts an.
  • PowerShell: Get-AzSqlInstance -ResourceGroupName <resource-group> -Name <mi-name> Zeigt den Domänennamen des VNet-lokalen Endpunkts als fullyQualifiedDomainName Eigenschaft an.
  • Azure CLI: az sql mi show -g <resource-group> -n <mi-name> Zeigt den Domänennamen des VNet-lokalen Endpunkts als fullyQualifiedDomainName Eigenschaft an.

Geben Sie für eine verbesserte Sicherheit eine verschlüsselte Verbindung an, und vertrauen Sie dem Zertifikat nicht. Weitere Informationen finden Sie in Sicherheitsübersicht.

Öffentlicher Endpunkt

Der öffentliche Endpunkt ist ein Domänenname in Form von <mi_name>.public.<dns_zone>.database.windows.net. Dieser Domänenname wird in eine öffentliche IP-Adresse aufgelöst, die aus dem Internet erreichbar ist. Der öffentliche Endpunkt eignet sich für Szenarien, in dem eine von SQL verwaltete Instanz über das öffentliche Internet zugänglich sein muss. Beispielsweise bei der Verbindung mit einem anderen virtuellen Netzwerk, falls Peering oder private Endpunkte nicht verfügbar sind. Öffentliche Endpunkte übertragen nur Client-Traffic und können nicht für die Datenreplikation zwischen zwei Instanzen verwendet werden, zum Beispiel Failovergruppen oder Verwaltete Instanz-Verknüpfung. Öffentlicher Endpunkt akzeptiert Verbindungen am Port 3342.

Öffentlicher Endpunkt verwendet immer den Proxyverbindungstyp unabhängig von der Verbindungstypeinstellung.

Der Name der öffentlichen Endpunktdomäne einer Instanz entspricht dem VNet-lokalen Endpunktnamen, wobei die Bezeichnung public zwischen dem Hostnamen und dem Rest der Domäne eingefügt wird: <mi-name>.public.<dns-zone>.database.windows.net

Wenn Sie eine Verbindung mit dem öffentlichen Endpunkt herstellen, verwenden Sie immer ihren Domänennamen, und lassen Sie eingehenden Datenverkehr an Port 3342 im gesamten Subnetzbereich zu, da sich die zugrunde liegende IP-Adresse gelegentlich ändern kann.

Informationen zum Einrichten eines öffentlichen Endpunkts finden Sie unter Konfigurieren eines öffentlichen Endpunkts für Azure SQL Managed Instance.

Private Endpunkte

Ein privater Endpunkt ist eine optionale feste IP-Adresse in einem anderen Virtual Network, das Datenverkehr zu Ihrer SQL Managed Instance leitet. Eine Azure SQL Managed Instance-Instanz kann mehrere private Endpunkte in mehreren virtuellen Netzwerken aufweisen. Private Endpunkte übertragen nur Client-Datenverkehr und können nicht für die Datenreplikation zwischen zwei Instanzen verwendet werden, wie etwa bei Failover-Gruppen oder dem Link für verwaltete Instanzen. Der private Endpunkt akzeptiert Verbindungen am Port 1433.

Private Endpunkte verwenden unabhängig von der Verbindungstypeinstellung immer den Proxyverbindungstyp .

Der Domänenname einer Instanz ist gleich dem VNet-lokalen Domänennamen, es sei denn, der Endpunkt wurde anders konfiguriert. Dies ist der Fall, wenn sich sowohl der private Endpunkt als auch der lokale VNet-Endpunkt im selben virtuellen Netzwerk befinden. Weitere Informationen finden Sie unter Einrichten der Auflösung von Domänennamen für private Endpunkte.

Verwenden Sie beim Herstellen einer Verbindung mit einem privaten Endpunkt immer den Domänennamen, da eine Verbindung mit Azure SQL Managed Instance über die IP-Adresse noch nicht unterstützt wird. Die IP-Adresse eines privaten Endpunkts ändert sich jedoch nicht.

Erfahren Sie mehr über private Endpunkte und deren Konfiguration in Azure Private Link für Azure SQL Managed Instance.

Verbindungsarchitektur für virtuellen Cluster

Das folgende Diagramm zeigt das konzeptionelle Layout der Architektur des virtuellen Clusters:

Diagramm: Konnektivitätsarchitektur des virtuellen Clusters für Azure SQL Managed Instance.

Der Domänenname des lokalen VNet-Endpunkts wird in die private IP-Adresse eines internen Lastenausgleichs aufgelöst. Obwohl dieser Domänenname in einer öffentlichen DNS-Zone (Domain Name System) registriert und öffentlich auflösbar ist, gehört seine IP-Adresse zum Adressbereich des Subnetzes und kann standardmäßig nur aus seinem virtuellen Netzwerk erreicht werden.

Der Lastenausgleich leitet Datenverkehr an das SQL Managed Instance-Gateway weiter. Da mehrere verwaltete SQL-Instanzen innerhalb desselben Clusters ausgeführt werden können, verwendet das Gateway den Hostnamen der verwalteten SQL-Instanz, wie in der Verbindungszeichenfolge zu sehen ist, um Datenverkehr an den richtigen SQL-Moduldienst umzuleiten.

Der Wert für dns-zone wird beim Erstellen des Clusters automatisch generiert. Wenn ein neu erstelltes Cluster eine sekundäre verwaltete SQL-Instanz hostt, teilt er seine Zonen-ID mit dem primären Cluster.

Netzwerkanforderungen

Azure SQL Managed Instance erfordert, dass Aspekte des delegierten Subnetzes auf bestimmte Weise konfiguriert werden, was Sie durch die Verwendung der dienstgestützten Subnetzkonfiguration erreichen können. Über die Anforderungen des Dienstes hinaus haben die Benutzer die volle Kontrolle über die Konfiguration ihres Subnetzes, z. B:

  • Zulassen oder Blockieren des Datenverkehrs für einige oder alle Ports.
  • Hinzufügen von Einträgen zur Routentabelle zum Weiterleiten des Datenverkehrs über virtuelle Netzwerkgeräte oder ein Gateway.
  • Konfigurieren der benutzerdefinierten DNS-Auflösung.
  • Einrichten von Peering oder VPN.

Um die Kriterien der kompatiblen Netzwerkkonfiguration im Service Level Agreement für Microsoft Online Services zu erfüllen, muss das virtuelle Netzwerk und das Subnetz, in dem SQL Managed Instance bereitgestellt wird, die folgenden Anforderungen erfüllen:

  • Dediziertes Subnetz: Das von SQL Managed Instance verwendete Subnetz kann nur an den SQL Managed Instance-Dienst delegiert werden. Bei dem Subnetz kann es sich nicht um ein Gatewaysubnetz handeln, und Sie können nur SQL Managed Instance-Ressourcen im Subnetz bereitstellen.
  • Subnetzdelegierung: Das SQL Managed Instance-Subnetz muss an den Ressourcenanbieter Microsoft.Sql/managedInstances für delegiert werden.
  • Netzwerksicherheitsgruppe: Dem SQL Managed Instance-Subnetz muss eine Netzwerksicherheitsgruppe zugeordnet werden. Sie können eine Netzwerksicherheitsgruppe verwenden, um den Zugriff auf den SQL Managed Instance-Datenendpunkt zu steuern, indem Sie eingehenden Datenverkehr auf Port 1433 filtern. Der Dienst stellt automatisch Regeln bereit und hält sie auf dem neuesten Stand, um einen unterbrechungsfreien Fluss des Verwaltungsdatenverkehrs zu ermöglichen.
  • Routingtabelle: Dem SQL Managed Instance-Subnetz muss eine Routingtabelle zugeordnet werden. Sie können dieser Routingtabelle Einträge hinzufügen, um beispielsweise den Datenverkehr über ein virtuelles Netzwerkgateway zu den Räumlichkeiten zu leiten oder um die Standardroute 0.0.0.0/0 hinzuzufügen, die den gesamten Datenverkehr über eine virtuelle Netzwerkappliance wie eine Firewall leitet. Azure SQL Managed Instance sorgt automatisch für die Bereitstellung und Verwaltung der erforderlichen Einträge in der Routingtabelle.
  • Ausreichende IP-Adressen: Das SQL Managed Instance-Subnetz muss mindestens 32 IP-Adressen umfassen. Weitere Informationen finden Sie unter Ermitteln der Größe des Subnetzes für SQL Managed Instance. Sie können SQL-verwaltete Instanzen innerhalb eines vorhandenen Netzwerks bereitstellen, nachdem Sie sie konfiguriert haben, um die Netzwerkanforderungen für die verwaltete SQL-Instanz zu erfüllen. Erstellen Sie andernfalls ein neues Netzwerk und Subnetz.
  • Zulässig durch Azure-Richtlinien: Wenn Sie Azure Policy verwenden, um die Erstellung oder Änderung von Ressourcen in einem Geltungsbereich zu verhindern, der das Subnetz oder das virtuelle Netzwerk von SQL Managed Instance einschließt, dürfen diese Richtlinien SQL Managed Instance nicht an der Verwaltung der internen Ressourcen hindern. Die folgenden Ressourcen müssen von den Auswirkungen durch Verweigerungen ausgeschlossen werden, um einen normalen Betrieb zu ermöglichen:
    • Ressourcen vom Typ Microsoft.Network/serviceEndpointPolicies, wenn der Ressourcenname mit \_e41f87a2\_ beginnt
    • Alle Ressourcen vom Typ Microsoft.Network/networkIntentPolicies
    • Alle Ressourcen vom Typ Microsoft.Network/virtualNetworks/subnets/contextualServiceEndpointPolicies
  • Sperren im virtuellen Netzwerk: Sperren im virtuellen Netzwerk des dedizierten Subnetzs, der übergeordneten Ressourcengruppe oder des Abonnements können gelegentlich die Verwaltung und Wartung von verwalteten SQL-Instanzen beeinträchtigen. Lassen Sie besondere Vorsicht walten, wenn Sie Ressourcensperren verwenden.
  • Auflösbare öffentliche DNS-Einträge: Wenn das virtuelle Netzwerk für die Verwendung eines benutzerdefinierten DNS-Servers konfiguriert ist, muss dieser DNS-Server in der Lage sein, öffentliche DNS-Einträge aufzulösen. Die Verwendung von Features wie der Microsoft Entra-Authentifizierung macht unter Umständen auch die Auflösung weiterer vollqualifizierter Domänennamen (Fully Qualified Domain Names, FQDNs) erforderlich. Weitere Informationen dazu finden Sie unter Auflösen privater DNS-Namen in Azure SQL Managed Instance.
  • Erforderliche DNS-Einträge: VON SQL verwaltete Instanzen hängen davon ab, dass bestimmte Domänennamen ordnungsgemäß aufgelöst werden. Diese Domänennamen dürfen in ihren virtuellen Netzwerken weder über Azure DNS Private Zones noch durch einen benutzerdefinierten DNS-Server außer Kraft gesetzt werden. Andernfalls werden von SQL verwaltete Instanzen nicht bereitgestellt oder sind möglicherweise nicht verfügbar. Die folgenden Domänen dürfen nicht außer Kraft gesetzt werden: windows.net, database.windows.net, core.windows.net, blob.core.windows.net, table.core.windows.net, management.core.windows.net, monitoring.core.windows.net, queue.core.windows.net, graph.windows.net, login.microsoftonline.com, login.windows.net, servicebus.windows.netund vault.azure.net. Sie können weiterhin private Endpunkte innerhalb des virtuellen Netzwerks einer SQL-verwalteten Instanz erstellen, auch zu Ressourcen in den oben genannten Domänen. Private Endpunkte verwenden einen DNS-Mechanismus, der nicht erfordert, dass ein lokaler DNS-Server autoritativ für eine gesamte Zone wird.
  • AzurePlatformDNS-Tag: Die Verwendung des AzurePlatformDNS-Diensttags zur Blockierung der DNS-Auflösung der Plattform könnte dazu führen, dass SQL Managed Instance nicht mehr verfügbar ist. SQL Managed Instance unterstützt zwar ein kundenseitig definiertes DNS für die DNS-Auflösung innerhalb der Engine, dennoch besteht für Plattformvorgänge eine Abhängigkeit von Azure DNS.

Dienstgestützte Subnetzkonfiguration

Um die Sicherheit, Verwaltbarkeit und Verfügbarkeit des Dienstes zu verbessern, verwendet SQL Managed Instance die dienstgestützte Subnetzkonfiguration und die Netzwerkrichtlinien auf der virtuellen Azure-Netzwerkinfrastruktur, um das Netzwerk, die zugehörigen Komponenten und die Routentabelle zu konfigurieren und sicherzustellen, dass die Mindestanforderungen für SQL Managed Instance erfüllt werden.

Automatisch konfigurierte Netzwerksicherheits- und Routentabellenregeln sind für den Kunden sichtbar und mit einem dieser Präfixe versehen:

  • Microsoft.Sql-managedInstances_UseOnly_mi- für obligatorische Regeln und Routen
  • Microsoft.Sql-managedInstances_UseOnly_mi-optional- für optionale Regeln und Routen

Weitere Details finden Sie unter " Dienstgestützte Subnetzkonfiguration".

Weitere Informationen zur Konnektivitätsarchitektur und zum Verwaltungsdatenverkehr finden Sie unter Verbindungsarchitektur auf Makroebene.

Netzwerkeinschränkungen

Die folgenden Einschränkungen für Funktionen und Datenverkehr im virtuellen Netzwerk gelten:

  • Private Subnetze: Das Bereitstellen von verwalteten SQL-Instanzen in privaten Subnetzen (wobei der standardmäßige ausgehende Zugriff deaktiviert ist) wird derzeit nicht unterstützt.
  • VNet-Verschlüsselung: Bereitstellen und Ausführen von sql verwalteten Instanzen in virtuellen Netzwerken, in denen die Azure Virtual Network-Verschlüsselung aktiviert ist, wird derzeit nicht unterstützt.
  • Datenbank-E-Mails an externe SMTP-Relays auf Port 25: Das Senden von Datenbank-E-Mails über Port 25 an externe E-Mail-Dienste ist nur für bestimmte Subscriptiontypen in Microsoft Azure verfügbar. Instanzen mit anderen Subscriptiontypen sollten für die Kontaktaufnahme mit externen SMTP-Relays einen anderen Port (z. B. 587) verwenden. Andernfalls könnten Instanzen Datenbank-E-Mails nicht übermitteln. Weitere Informationen finden Sie unter Behandeln von Problemen mit ausgehenden SMTP-Verbindungen in Azure.
  • Microsoft-Peering: Die Aktivierung von Microsoft-Peering für ExpressRoute-Leitungen, die direkt oder transitiv mit einem virtuellen Netzwerk verbunden sind, in dem sich SQL Managed Instance befindet, wirkt sich auf den Datenverkehrsfluss zwischen den SQL Managed Instance-Komponenten innerhalb des virtuellen Netzwerks und den Diensten aus, von denen der Dienst abhängt. Dies führt zu Verfügbarkeitsproblemen. Bei SQL Managed Instance-Bereitstellungen in einem virtuellen Netzwerk, in dem Microsoft-Peering bereits aktiviert ist, treten wahrscheinlich Fehler auf.
  • Globales virtuelles Netzwerk-Peering: Virtuelle Netzwerk-Peeringkonnektivität in Azure-Regionen funktioniert nicht für SQL-verwaltete Instanzen, die in Subnetzen platziert wurden, die vor dem 9. September 2020 erstellt wurden.
  • Virtuelles Netzwerk-Peering – Konfiguration: Beim Einrichten eines virtuellen Netzwerk-Peerings zwischen virtuellen Netzwerken, die Subnetze mit VON SQL verwalteten Instanzen enthalten, müssen diese Subnetze unterschiedliche Routentabellen und Netzwerksicherheitsgruppen (Network Security Groups, NSG) verwenden. Die Wiederverwendung der Routingtabelle und des NSG in zwei oder mehr Subnetzen, die am Peering virtueller Netzwerke teilnehmen, führt zu Konnektivitätsproblemen in allen Subnetzen, die diese Routingtabellen oder NSG verwenden, und zum Ausfall der Verwaltungsvorgänge von SQL Managed Instance.
  • NAT-Gateway: Die Verwendung von Azure Virtual Network NAT zum Steuern der ausgehenden Konnektivität mit einer bestimmten öffentlichen IP-Adresse wird derzeit nicht unterstützt.
  • IPv6 für Azure Virtual Network: Bei der Bereitstellung von SQL Managed Instance in virtuellen Netzwerken mit dualem IPv4/IPv6-Stapel wird ein Fehler erwartet. Wenn Sie eine Netzwerksicherheitsgruppe oder eine Routingtabelle, die IPv6-Adresspräfixe für ein SQL Managed Instance-Subnetz enthält, benutzerdefinierten Routen (User-Defined Routes, UDRs) zuordnen, ist SQL Managed Instance nicht verfügbar. Außerdem führt das Hinzufügen von IPv6-Adresspräfixen zu einer Netzwerksicherheitsgruppe oder UDR, die bereits einem SQL Managed Instance-Subnetz zugeordnet ist, dazu, dass die SQL Managed Instance nicht mehr verfügbar ist. Bei der Bereitstellung von SQL Managed Instance in einem Subnetz mit einer Netzwerksicherheitsgruppe und einer UDR, die bereits über IPv6-Präfixe verfügen, wird ein Fehler erwartet.
  • TLS 1.2 wird für ausgehende Verbindungen erzwungen: Seit Januar 2020 erzwingt Microsoft TLS 1.2 für dienstinternen Datenverkehr in allen Azure-Diensten. Bei SQL Managed Instance führte dies dazu, dass TLS 1.2 bei ausgehenden Verbindungen für die Replikation sowie bei Verbindungen mit SQL Server über einen Verbindungsserver erzwungen wird. Wenn Sie eine frühere Version als SQL Server 2016 mit SQL Managed Instance verwenden, stellen Sie sicher, dass Sie TLS 1.2-spezifische Updates anwenden.
  • Interne Fallbacks zu Azure DNS: Von SQL verwaltete Instanzen hängen von der funktionierenden DNS-Auflösung in ihren virtuellen Netzwerken ab. Wenn das virtuelle Netzwerk einer verwalteten SQL-Instanz für die Verwendung von benutzerdefinierten DNS-Servern konfiguriert ist und eine FÜR benutzerdefinierte DNS-Server ausgestellte DNS-Anforderung innerhalb eines bestimmten Intervalls (1 bis 2 Sekunden) nicht abgeschlossen werden kann, wiederholt die verwaltete SQL-Instanz die Anforderung für Azure DNS in diesem virtuellen Netzwerk.

Zugehöriger Inhalt

  • Last updated on