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. Diese Endpunkte bedienen verschiedene Szenarien und weisen unterschiedliche Netzwerkeigenschaften und -verhalten auf.

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 lokale VNet-Endpunkt ist ein Domänenname in der Form <mi_name>.<dns_zone>.database.windows.net, der in eine IP-Adresse aus dem Adresspool des Subnetzes aufgelöst wird. Daher ist er lokal im VNet bzw. ein Endpunkt, der für das virtuelle Netzwerk lokal ist. Der lokale VNet-Endpunkt kann in allen Standardkonnektivitätsszenarien für die Verbindung mit einer SQL Managed Instance-Instanz verwendet werden.

Lokale VNet-Endpunkte unterstützen sowohl Proxy- als auch Umleitungsverbindungstypen.

Wenn Sie eine Verbindung mit dem lokalen VNet-Endpunkt herstellen, verwenden Sie immer dessen Domänennamen, da sich die zugrunde liegende IP-Adresse gelegentlich ändern kann.

Öffentlicher Endpunkt

Der öffentliche Endpunkt ist ein optionaler Domänenname in der Form <mi_name>.public.<dns_zone>.database.windows.net, der in eine öffentliche, über das Internet erreichbare IP-Adresse aufgelöst wird. Dieser öffentliche Endpunkt lässt TDS-Datenverkehr nur an SQL Managed Instance auf Port 3342 zu und kann nicht für Integrationsszenarien wie Failover-Gruppen, Managed Instance Link und ähnliche Technologien verwendet werden.

Wenn Sie eine Verbindung zum öffentlichen Endpunkt herstellen, verwenden Sie immer dessen Domänennamen, da sich die zugrunde liegende IP-Adresse gelegentlich ändern kann.

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

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 lassen TDS-Datenverkehr nur an SQL Managed Instance auf Port 1433 zu und können nicht für Integrationsszenarien wie Failover-Gruppen, Managed Instance Link und Ähnliches verwendet werden.

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.

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

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

Das Subnetz, in dem SQL Managed Instance bereitgestellt wird, muss 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.
  • Replikationsdatenverkehr: Der Replikationsdatenverkehr für Failovergruppen zwischen zwei verwalteten Instanzen sollte direkt ausgeführt und nicht über ein Hubnetzwerk geleitet werden.
  • Benutzerdefinierter DNS-Server: Wenn das virtuelle Netzwerk für die Verwendung eines benutzerdefinierten DNS-Servers konfiguriert ist, muss dieser 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.

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

  • 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.

Die folgenden Features von virtuellen Netzwerken werden derzeit von SQL Managed Instance nicht unterstützt:

  • 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.
  • Peering virtueller Netzwerke – global: Die Konnektivität per Peering virtueller Netzwerke über Azure-Regionen hinweg funktioniert für Instanzen von SQL Managed Instance nicht, 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.
  • 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 eine Abhängigkeit vom Plattform-DNS für Plattformvorgänge.
  • 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.
  • DNS-Einträge für reservierte Microsoft-Dienste: Die folgenden Domänennamen sind reserviert und ihre Auflösung gemäß der Definition in Azure DNS darf in einem virtuellen Netzwerk, das verwaltete Instanzen hostet, 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.net und vault.azure.net. Die Bereitstellung einer SQL Managed Instance in einem virtuellen Netzwerk, in dem mindestens ein solcher Domänennamen über Azure DNS Private Zones oder durch einen benutzerdefinierten DNS-Server überschrieben wird, schlägt fehl. Die Außerkraftsetzung der Auflösung dieser Domänen in einem virtuellen Netzwerk mit einer verwalteten Instanz führt dazu, dass diese verwaltete Instanz nicht verfügbar ist. Informationen für die Konfiguration von Private Link-DNS-Datensätzen in einem virtuellen Netzwerk mit verwalteten Instanzen finden Sie unter DNS-Konfiguration für private Azure-Endpunkte.

Zugehöriger Inhalt