Konnektivitätsarchitektur für Azure SQL Managed Instance

Gilt für: Azure SQL Managed Instance

In diesem Artikel wird die Kommunikation in Azure SQL Managed Instance erläutert, wobei die Konnektivitätsarchitektur und die Weiterleitung des Datenverkehrs an eine verwaltete Instanz durch Komponenten beschrieben werden.

SQL Managed Instance wird im virtuellen Azure-Netzwerk und dem für verwaltete Instanzen dedizierten Subnetz platziert. Diese Bereitstellung bietet:

  • Eine sichere IP-Adresse im lokalen 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.

Hinweis

Im November 2022 wurden mehrere Änderungen an der Standardkonnektivitätsstruktur für SQL Managed Instance eingeführt. Dieser Artikel enthält Informationen zur aktuellen Architektur sowie zur Architektur von Instanzen, die noch nicht für die Featurewelle registriert sind. Weitere Informationen finden Sie unter Featurewelle vom November 2022.

Featurewelle vom November 2022

In der Featurewelle vom November 2022 wurden die folgenden Änderungen an der Konnektivitätsarchitektur für SQL Managed Instance eingeführt:

  • Der Verwaltungsendpunkt wurde entfernt.
  • Obligatorische Regeln für Netzwerksicherheitsgruppen (NSG) wurden vereinfacht. (Eine obligatorische Regel wurde entfernt.)
  • Obligatorische Regeln für Netzwerksicherheitsgruppen enthalten keinen ausgehenden Datenverkehr mehr zu AzureCloud an Port 443.
  • Die Routingtabelle wurde vereinfacht. (Obligatorische Routen wurden von 13 auf 5 verringert.)

Kommunikationsübersicht

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 von Entitäten in der Konnektivitätsarchitektur für Azure SQL Managed Instance.

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

Die Datenebene wird im Subnetz der Kundschaft bereitgestellt, um Kompatibilität, Konnektivität und Netzwerkisolation zu gewährleisten, und der Zugriff erfolgt in der Regel über den lokalen VNET-Endpunkt. Die Datenebene basiert auf Azure-Diensten wie Azure Storage, Azure Active Directory (Azure AD) für die Authentifizierung und Telemetriesammlungsdiensten. Die Kundschaft kann Datenverkehr zu diesen Diensten von Subnetzen erkennen, die SQL Managed Instance enthalten.

Die Steuerungsebene übernimmt die Bereitstellungs-, Verwaltungs- und Kerndienstverwaltungs-Funktionen über automatisierte Agents. Diese Agents haben exklusiven Zugriff auf die Computeressourcen, die den Dienst betreiben: Es ist nicht möglich, ssh oder RDP für diese Hosts zu verwenden. Jegliche Kommunikation der Steuerungsebene ist 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.

Verbindungsarchitektur auf Makroebene

Allgemein besteht SQL Managed Instance aus Dienstkomponenten, die auf dedizierten isolierten VMs in einem virtuellen Cluster gehostet werden. Einige Dienstkomponenten werden im Subnetz des virtuellen Netzwerks der Kundschaft bereitgestellt, während andere in einer sicheren Netzwerkumgebung ausgeführt werden, die von Microsoft verwaltet wird.

Ein virtueller Cluster kann mehrere verwaltete Instanzen hosten. Der Cluster wird bei Bedarf automatisch erweitert oder verkleinert, um neue oder entfernte Instanzen zu berücksichtigen.

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.

Diagramm der Konnektivitätsarchitektur für Azure SQL Managed Instance.

Um Konnektivität mit Kundenanwendungen zu erreichen, bietet SQL Managed Instance zwei Arten von Endpunkten: lokale VNET-Endpunkte und öffentliche Endpunkte.

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 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 von SQL Managed Instance verwendet werden.

Ö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 Endpunkt lässt nur TDS-Datenverkehr an SQL Managed Instance zu und kann nicht für Integrationsszenarien (etwa Failovergruppen, Links für verwaltete Instanzen und ähnliche Technologien) verwendet werden.

Verbindungsarchitektur für virtuellen Cluster

Im Folgenden wird die Konnektivitätsarchitektur für SQL Managed Instance noch genauer untersucht. Im unten abgebildeten Diagramm wird das konzeptionelle Layout des virtuellen Clusters dargestellt.

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

Clients stellen mithilfe des Hostnamens, der in der Form <mi_name>.<dns_zone>.database.windows.net vorliegen muss, eine Verbindung mit SQL Managed Instance her. Dieser Hostname wird in eine private IP-Adresse aufgelöst, obwohl er in einer öffentlichen DNS-Zone (Domain Name System) registriert ist und öffentlich aufgelöst werden kann. Die zone-id 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. Weitere Informationen finden Sie unter Verwenden von Autofailover-Gruppen für ein transparentes und koordiniertes Failover mehrerer Datenbanken.

Diese private IP-Adresse gehört zum internen Lastenausgleich von SQL Managed Instance. 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, um den Datenverkehr an den richtigen SQL-Engine-Dienst weiterzuleiten.

Dienstgestützte Subnetzkonfiguration

Um die Sicherheit, Verwaltung und Verfügbarkeit des Diensts zu verbessern, wendet SQL Managed Instance eine Netzwerkabsichtsrichtlinie auf einige Elemente der Azure-VNET-Infrastruktur an. Diese Richtlinie konfiguriert das Subnetz, die zugeordnete Netzwerksicherheitsgruppe (Network Security Group, NSG) und die Routingtabelle, um sicherzustellen, dass die Mindestanforderungen für SQL Managed Instance erfüllt werden. Dieser Plattformmechanismus kommuniziert transparent Netzwerkanforderungen für Benutzer. Das Hauptziel der Richtlinie besteht darin, Fehlkonfigurationen des Netzwerks zu verhindern und den normalen Betrieb von SQL Managed Instance sowie die SLA-Einhaltung zu gewährleisten. Wenn Sie eine verwaltete Instanz löschen, wird die Netzwerkzielrichtlinie ebenfalls entfernt.

Die dienstgestützte Subnetzkonfiguration baut auf dem Feature Subnetzdelegierung für virtuelle Netzwerke auf, um eine automatische Verwaltung der Netzwerkkonfiguration zu ermöglichen und Dienstendpunkte zu aktivieren.

Dienstendpunkte können zum Konfigurieren von Firewallregeln für virtuelle Netzwerke für Speicherkonten verwendet werden, in denen Sicherungen und Überwachungsprotokolle gespeichert werden. Auch wenn Dienstendpunkte aktiviert sind, wird der Kundschaft empfohlen, Private Link zu verwenden, um auf ihre Speicherkonten zuzugreifen. Private Link bietet zusätzliche Isolation über Dienstendpunkte.

Wichtig

Aufgrund der Besonderheiten der Konfiguration der Steuerungsebene ermöglicht eine dienstgestützte Subnetzkonfiguration keine Dienstendpunkte in nationalen Clouddiensten.

Netzwerkanforderungen

Das Subnetz, in dem SQL Managed Instance bereitgestellt wird, muss die folgenden Merkmale aufweisen:

  • Dediziertes Subnetz: Das von SQL Managed Instance verwendete Subnetz kann nur an den SQL Managed Instance-Dienst delegiert werden. Es kann sich nicht um ein Gatewaysubnetz handeln, und Sie können darin nur SQL Managed Instance-Ressourcen bereitstellen.
  • Subnetzdelegierung: Das Subnetz von SQL Managed Instance muss an den Ressourcenanbieter Microsoft.Sql/managedInstances delegiert werden.
  • Netzwerksicherheitsgruppe (NSG) : Eine NSG muss dem Subnetz von SQL Managed Instance zugeordnet werden. Sie können eine NSG verwenden, um den Zugriff auf den Datenendpunkt von SQL Managed Instance zu steuern, indem Sie Datenverkehr an Port 1433 und die Ports 11000 bis 11999 filtern, wenn SQL Managed Instance für Verbindungsumleitungen konfiguriert ist. Der Dienst stellt automatisch die Regeln zur Verfügung, die erforderlich sind, um einen ununterbrochenen Fluss des Verwaltungsdatenverkehrs zu ermöglichen, und hält sie auf dem neuesten Stand.
  • Routingtabelle: Dem Subnetz von SQL Managed Instance muss eine Routingtabelle zugeordnet werden. Sie können der Routingtabelle Einträge hinzufügen, um Datenverkehr mit lokalen privaten IP-Bereichen als Ziel über das virtuelle Netzwerkgateway oder das virtuelle Netzwerkgerät (Network Appliance, NVA) zu leiten. Der Dienst stellt automatisch die Einträge zur Verfügung, die erforderlich sind, um einen ununterbrochenen Fluss des Verwaltungsdatenverkehrs zu ermöglichen, und hält sie auf dem neuesten Stand.
  • Ausreichende IP-Adressen: Das Subnetz von SQL Managed Instance 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 über Azure Policy das Erstellen oder Ändern von Ressourcen in dem Geltungsbereich verweigern, der das Subnetz/virtuelle Netzwerk von SQL Managed Instance einschließt, sollte SQL Managed Instance durch solche Richtlinien nicht an der Verwaltung der internen Ressourcen gehindert werden. Die folgenden Ressourcen müssen von Verweigerungen ausgeschlossen werden, um den 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 für virtuelles Netzwerk: Sperren für das virtuelle Netzwerk, die übergeordnete Ressourcengruppe oder das Abonnement des dedizierten Subnetzes können gelegentlich die Verwaltungs- und Wartungsvorgänge von SQL Managed Instance beeinträchtigen. Seien Sie besonders vorsichtig, wenn Sie solche Sperren verwenden.
  • Replikationsdatenverkehr: Der Replikationsdatenverkehr für Autofailover-Gruppen zwischen zwei SQL Managed Instances sollte direkt und nicht über ein Hubnetzwerk erfolgen.
  • Benutzerdefinierter DNS-Server: Wenn das virtuelle Netzwerk mit einem benutzerdefinierten DNS-Server konfiguriert ist, muss dieser Server in der Lage sein, öffentliche DNS-Einträge aufzulösen. Die Verwendung zusätzlicher Funktionen wie Azure AD Authentication macht unter Umständen auch die Auflösung zusätzlicher vollqualifizierter Domänennamen (FQDNs) erforderlich. Weitere Informationen dazu finden Sie unter Auflösen privater DNS-Namen in Azure SQL Managed Instance.

Obligatorische Sicherheitsregeln mit dienstgestützter Subnetzkonfiguration

Diese Regeln sind erforderlich, um den eingehenden Management-Verkehrsfluss zu gewährleisten. Sie werden von der Netzwerkabsichtsrichtlinie erzwungen und müssen nicht von der Kundschaft bereitgestellt werden. Weitere Informationen zur Konnektivitätsarchitektur und zum Verwaltungsdatenverkehr finden Sie im vorherigen Abschnitt zur allgemeinen Konnektivitätsarchitektur.

Name Port Protocol `Source` Destination Aktion
internal-in Any Any subnet subnet Allow

Diese Regeln sind erforderlich, um den ausgehenden Management-Verkehrsfluss zu gewährleisten. Weitere Informationen zur Konnektivitätsarchitektur und zum Verwaltungsdatenverkehr finden Sie im Absatz oben.

Name Port Protocol `Source` Destination Aktion
AAD-out 443 TCP subnet AzureActiveDirectory Allow
OneDsCollector-out 443 TCP subnet OneDsCollector Allow
internal-out Any Any subnet subnet Allow
StorageP-out 443 Any subnet Storage.primaryRegion Allow
StorageS-out 443 Any subnet Storage.secondaryRegion Allow

Benutzerdefinierte Routen mit dienstgestützter Subnetzkonfiguration

Diese Routen sind erforderlich, um sicherzustellen, dass der Management-Datenverkehr direkt an ein Ziel geleitet wird. Sie werden von der Netzwerkabsichtsrichtlinie erzwungen und müssen nicht von der Kundschaft bereitgestellt werden. Weitere Informationen zur Konnektivitätsarchitektur und zum Verwaltungsdatenverkehr finden Sie im vorherigen Abschnitt zur allgemeinen Konnektivitätsarchitektur.

Name Adresspräfix Nächster Hop
AzureActiveDirectory AzureActiveDirectory Internet*
OneDsCollector OneDsCollector Internet*
Storage.primaryRegion Storage.primaryRegion Internet*
Storage.secondaryRegion Storage.secondaryRegion Internet*
subnet-to-vnetlocal subnet Virtuelles Netzwerk

Hinweis

*Internet: Dieser Wert im Feld „Nächster Hop“ weist das Gateway an, den Datenverkehr außerhalb des virtuellen Netzwerks weiterzuleiten. Wenn die Zieladresse jedoch die Adresse eines der Azure-Dienste ist, leitet Azure den Datenverkehr direkt über das Azure-Backbonenetzwerk an den Dienst weiter, und nicht außerhalb der Azure-Cloud. Der Datenverkehr zwischen Azure-Diensten wird nicht über das Internet übertragen, unabhängig davon, in welcher Azure-Region das virtuelle Netzwerk vorhanden ist oder für welche Azure-Region eine Instanz des Azure-Diensts bereitgestellt wird. Weitere Informationen finden Sie auf der Seite zum Routing des Datenverkehrs in virtuellen Netzwerken durch Azure.

Darüber hinaus können Sie der Routingtabelle Einträge hinzufügen, um Datenverkehr mit lokalen privaten IP-Bereichen als Ziel über ein virtuelles Netzwerkgateway oder ein virtuelles Netzwerkgerät (Network Appliance, NVA) zu leiten.

Netzwerkeinschränkungen

TLS 1.2 wird für ausgehende Verbindungen erzwungen: Seit Januar 2020 erzwingt Microsoft in sämtlichen Azure-Diensten TLS 1.2 für den dienstinternen Datenverkehr. Für SQL Managed Instance führte dies dazu, dass TLS 1.2 für ausgehende Verbindungen für die Replikation sowie für verknüpfte Serververbindungen mit SQL Server erzwungen wird. Wenn Sie ältere Versionen von SQL Server als Version 2016 mit SQL Managed Instance verwenden, stellen Sie sicher, dass TLS 1.2-spezifische Updates angewandt wurden.

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

  • Microsoft-Peering: Das Aktivieren von Microsoft-Peering für ExpressRoute-Verbindungen, die direkt oder transitiv mit einem virtuellen Netzwerk verbunden sind, in dem sich SQL Managed Instance befindet, wirkt sich auf den Datenverkehrsflow zwischen den Komponenten von SQL Managed Instance innerhalb des virtuellen Netzwerks und den erforderlichen Diensten aus und verursacht dadurch Verfügbarkeitsprobleme. SQL Managed Instance-Bereitstellungen im virtuellen Netzwerk mit bereits aktiviertem Microsoft-Peering schlagen wahrscheinlich fehl.
  • Globales Peering virtueller Netzwerke: Konnektivität per Peering virtueller Netzwerke über Azure-Regionen hinweg funktioniert nicht für SQL Managed Instances in Subnetzen, die vor dem 22.09.2020 erstellt wurden.
  • AzurePlatformDNS: Die Verwendung des AzurePlatformDNS-Diensttags zur Blockierung der DNS-Auflösung der Plattform würde dazu führen, dass SQL Managed Instance nicht mehr verfügbar ist. Obwohl SQL Managed Instance kundenspezifisches DNS für die DNS-Auflösung innerhalb der Engine unterstützt, 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 würde dazu führen, dass SQL Managed Instance nicht erreichbar ist. Der SQL Managed Instance-Dienst ist aktuell auf die Verwendung eines Basislastenausgleichs beschränkt, der keine parallelen eingehenden und ausgehenden Flows für 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. Das Zuordnen von Netzwerksicherheitsgruppen (NSG) oder Routingtabellen (UDR) mit IPv6-Adresspräfixen zu einem SQL Managed Instance-Subnetz oder das Hinzufügen von IPv6-Adresspräfixen zu einer NSG oder UDR, die bereits dem Managed Instance-Subnetz zugeordnet ist, würden dazu führen, dass SQL Managed Instance nicht verfügbar ist. Bei der Bereitstellung von SQL Managed Instance in einem Subnetz mit einer NSG und UDR, die bereits über IPv6-Präfixe verfügen, wird ein Fehler erwartet.
  • Azure DNS private Zonen mit Namen, die für Microsoft-Dienste reserviert sind: Es folgt die Liste der reservierten Namen: 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, vault.azure.net. Die Bereitstellung von SQL Managed Instance in einem virtuellen Netzwerk mit zugehöriger Azure DNS Private Zone mit einem für Microsoft-Dienste reservierten Namen würde fehlschlagen. Wenn Sie eine private Azure-DNS-Zone mit reserviertem Namen mit einem virtuellen Netzwerk mit einer Instanz verknüpfen, ist SQL Managed Instance nicht mehr verfügbar. Bitte folgen Sie der Azure Private Endpoint DNS Konfiguration für die richtige Private Link Konfiguration.

Nächste Schritte