Freigeben über

Konnektivitätsarchitektur für Azure SQL Managed Instance

  • Artikel

Gilt für:Azure SQL Managed Instance

In diesem Artikel wird die Konnektivitätsarchitektur in Azure SQL Managed Instance und die Art und Weise beschrieben, in der Komponenten den Kommunikationsdatenverkehr für eine verwaltete Instanz leiten.

Übersicht

Bei SQL Managed Instance wird im virtuellen Azure-Netzwerk und dem für verwaltete Instanzen dedizierten Subnetz eine Instanz platziert. 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

SQL Managed Instance besteht aus Servicekomponenten, die auf einer Reihe isolierter virtueller Computer gehostet werden, die durch ähnliche Konfigurationsattribute gruppiert und zu einem virtuellen Cluster verbunden sind. Einige Dienstkomponenten werden im Subnetz des virtuellen Netzwerks der Kundschaft bereitgestellt, während andere Dienste in einer sicheren Netzwerkumgebung ausgeführt werden, die von Microsoft verwaltet wird.

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. Sie zeigt auch die Ressourcen, die mit einer 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. Für den Zugriff auf diese Hosts kann weder ssh noch das Remotedesktopprotokoll verwendet werden. 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. Es handelt sich um einen Domänennamen 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. Der lokale VNet-Endpunkt kann in allen Standardkonnektivitätsszenarien für die Verbindung mit einer SQL Managed Instance-Instanz verwendet werden. Der Port des lokalen VNet-Endpunkts lautet 1433.

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

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

Ö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 über das Internet erreichbar ist. Öffentlicher Endpunkt eignet sich für Szenarien, in denen über das öffentliche Internet auf eine verwaltete Instanz zugegriffen werden muss, z. B. beim Herstellen einer Verbindung mit einem anderen virtuellen Netzwerk, wenn Peering oder private Endpunkte nicht verfügbar sind. Über öffentliche Endpunkte wird ausschließlich Clientdatenverkehr geleitet. Sie können nicht für die Datenreplikation zwischen zwei Instanzen wie Failovergruppen oder Verknüpfung verwalteter Instanzen verwendet werden. Der Port des öffentlichen Endpunkts ist 3342.

Der öffentliche Endpunkt verwendet unabhängig von der Einstellung des Verbindungstyps immer den Proxyverbindungstyp.

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. Über private Endpunkte wird ausschließlich Clientdatenverkehr geleitet. Sie können nicht für die Datenreplikation zwischen zwei Instanzen wie Failovergruppen oder Verknüpfung verwalteter Instanzen verwendet werden. Der Port des privaten Endpunkts lautet 1143.

Private Endpunkte verwenden unabhängig von der Einstellung des Verbindungstyps immer den Proxyverbindungstyp.

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 virtuellen Cluster-Architektur:

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 Instanzen in demselben Cluster ausgeführt werden können, nutzt das Gateway den Hostnamen von SQL Managed Instance gemäß der Verbindungszeichenfolge, um den Datenverkehr an den richtigen SQL-Engine-Dienst weiterzuleiten.

Der Wert für dns-zone wird beim Erstellen des Clusters automatisch generiert. Wenn in einem neu erstellten Cluster eine sekundäre verwaltete Instanz gehostet wird, verwendet diese die Zonen-ID gemeinsam 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, um den Datenverkehr über virtuelle Netzwerk-Appliances oder ein Gateway zu leiten
  • Konfigurieren der benutzerdefinierten DNS-Auflösung oder
  • Einrichten von Peering oder VPN

Um die Kriterien "Kompatible 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 Datenverkehr an Port 1433 und den Ports 11000–11999 filtern, wenn SQL Managed Instance für die Umleitung von Verbindungen konfiguriert ist. 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 verwaltete Instanzen im vorhandenen Netzwerk bereitstellen, nachdem Sie dieses entsprechend den Netzwerkanforderungen für SQL Managed Instance konfiguriert haben. 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, in der übergeordneten Ressourcengruppe oder in der Subscription des dedizierten Subnetzes können gelegentlich die Verwaltungs- und Wartungsvorgänge von SQL Managed Instance stören. 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: 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 tritt bei der Bereitstellung verwalteter Instanzen ein Fehler auf, oder sie sind möglicherweise nicht mehr 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. Beachten Sie jedoch, dass Sie weiterhin private Endpunkte innerhalb des virtuellen Netzwerks einer verwalteten Instanz erstellen können, auch für 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 Instanzen in privaten Subnetzen (bei denen der standardmäßige ausgehende Zugriff deaktiviert 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 Peering virtueller Netzwerke: Die Konnektivität über Peering virtueller Netzwerke in Azure-Regionen funktioniert nicht für SQL Managed Instance-Instanzen, die in vor dem 9. September 2020 erstellten Subnetzen platziert sind.
  • Peering virtueller Netzwerke – Konfiguration: Wenn Sie ein virtuelles Netzwerk-Peering zwischen virtuellen Netzwerken einrichten, die Subnetze mit SQL Managed Instances enthalten, müssen diese Subnetze unterschiedliche Routingtabellen und Netzwerksicherheitsgruppen (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 zur Steuerung der ausgehenden Konnektivität mit einer bestimmten öffentlichen IP-Adresse führt dazu, dass SQL Managed Instance nicht verfügbar ist. Der SQL Managed Instance-Dienst ist aktuell auf die Verwendung eines Basislastenausgleichs beschränkt, der keine gleichzeitigen eingehenden und ausgehenden Datenverkehrsflüsse für Azure Virtual Network NAT zulässt.
  • 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. Wenn Sie IPv6-Adresspräfixe einer Netzwerksicherheitsgruppe oder einer UDR zuordnen, die bereits einem Subnetz einer verwalteten Instanz zugeordnet ist, ist SQL Managed Instance ebenfalls nicht verfügbar. 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.
  • Interner Fallback auf Azure DNS: Verwaltete Instanzen hängen davon ab, dass die DNS-Auflösung in ihren virtuellen Netzwerken funktioniert. Wenn das virtuelle Netzwerk einer verwalteten Instanz für die Verwendung benutzerdefinierter DNS-Server konfiguriert ist und eine an benutzerdefinierte DNS-Server ausgegebene DNS-Anforderung innerhalb eines bestimmten Intervalls (1 bis 2 Sekunden) nicht abgeschlossen werden kann, wiederholt die verwaltete Instanz die Anforderung an Azure DNS in diesem virtuellen Netzwerk.

Zugehöriger Inhalt