Konnektivitätsarchitektur für Azure SQL Managed Instance

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.

Hinweis

In der Featurewelle vom November 2022 wurden Änderungen an der standardmäßigen Konnektivitätsstruktur von SQL Managed Instance eingeführt. Dieser Artikel enthält Informationen zur aktuellen Architektur und 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 SQL Managed Instance-Konnektivitätsarchitektur eingeführt:

• Der Verwaltungsendpunkt wurde entfernt.
• Obligatorische Regeln für Netzwerksicherheitsgruppen (NSG) wurden vereinfacht (eine obligatorische Regel wurde entfernt).
• Obligatorische Regeln für Netzwerksicherheitsgruppen wurden überarbeitet: Ausgehender Datenverkehr zu AzureCloud an Port 443 ist nicht mehr enthalten.
• Die Routingtabelle wurde vereinfacht (obligatorische Routen wurden von 13 auf 5 verringert).

Verbindungsarchitektur auf Makroebene

Aktuelle Architektur

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.

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.

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.

Architektur vor November 2022

Allgemein besteht SQL Managed Instance aus einer Reihe von Dienstkomponenten, die auf einer dedizierten Reihe von isolierten virtuellen Computern gehostet werden, die zu einem virtuellen Cluster verbunden sind. Einige Dienstkomponenten werden im Subnetz des virtuellen Netzwerks des Kunden bereitgestellt. Andere Dienste werden in einer sicheren, von Microsoft verwalteten Netzwerkumgebung betrieben.

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.

SQL Managed Instance ist ein PaaS-Angebot (Platform-as-a-Service) mit einem Mandanten. Die Compute- und Netzwerkelemente werden im Subnetz des Kunden bereitgestellt. Der Zugriff auf SQL Managed Instance erfolgt in der Regel über den zugehörigen lokalen VNet-Endpunkt. SQL Managed Instance erfordert Azure-Dienste wie Azure Storage, Microsoft Entra ID, Azure Key Vault, Azure Event Hubs und Telemetriesammlungsdienste. Aus Subnetzen mit SQL Managed Instance stammender Datenverkehr kann an diese Dienste weitergeleitet werden.

Vorgänge zur Bereitstellung, Verwaltung und Kerndienstverwaltung werden ü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 interne Kommunikation 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.

Verwaltungsendpunkt

Verwaltete Instanzen, die nicht an der Featurewelle vom November 2022 teilnehmen, verwenden zur Vereinfachung der Kommunikation zwischen der Steuerungsebene und den im Subnetz der Kundschaft bereitgestellten Komponenten einen Verwaltungsendpunkt. Die Elemente der Infrastruktur des virtuellen Netzwerks können somit den Verwaltungsdatenverkehr beeinträchtigen, indem sie einen Fehler bei der Instanz verursachen, sodass sie nicht mehr verfügbar ist. Verwaltungs- und Bereitstellungsdienste stellen eine Verbindung mit dem Verwaltungsendpunkt von SQL Managed Instance her, der einem externen Lastenausgleich zugeordnet ist. Der Datenverkehr wird nur an die Knoten weitergeleitet, wenn er an einer vordefinierten Gruppe von Ports empfangen wird, die ausschließlich die Verwaltungskomponenten von SQL Managed Instance verwenden. Eine integrierte Firewall auf den Knoten ist so eingerichtet, dass nur Datenverkehr von Microsoft-IP-Adressbereichen zulässig ist. Zertifikate authentifizieren gegenseitig die gesamte Kommunikation zwischen den Verwaltungskomponenten und der Verwaltungsebene.

Hinweis

Datenverkehr an Azure-Dienste innerhalb der SQL Managed Instance-Region wird optimiert. Da der Datenverkehr optimiert ist, wird der Datenverkehr nicht von der Netzwerkadressenübersetzung (Network Address Translation, NAT) an die öffentliche IP-Adresse für den Verwaltungsendpunkt gesendet. Wenn Sie IP-basierte Firewallregeln einsetzen müssen – meist für Speicher –, muss sich der Dienst daher in einer anderen Region als SQL Managed Instance befinden.

Die obligatorischen Eingangssicherheitsregeln von Azure SQL Managed Instance schreiben vor, dass die Verwaltungsports 9000, 9003, 1438, 1440 und 1452 für alle Quellen in der Netzwerksicherheitsgruppe (NSG) offen sind, die SQL Managed Instance schützt. Diese Ports sind zwar auf NSG-Ebene offen, auf Netzwerkebene sind sie jedoch durch die integrierte Firewall geschützt.

Der Endpunkt für die Verwaltung wird durch eine integrierte Firewall auf Netzwerkebene geschützt. Auf der Anwendungsebene wird er durch gegenseitige Zertifikatüberprüfung geschützt. Wenn Verbindungen in SQL Managed Instance starten (wie bei Sicherungen und Überwachungsprotokollen), scheint der Datenverkehr bei der öffentlichen IP-Adresse des Verwaltungsendpunkts zu beginnen.

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.

• Lokaler VNET-Endpunkt
• Öffentlicher Endpunkt
• Private Endpunkte

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:

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.

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:

• 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.
• Private Azure DNS-Zonen mit einem für Microsoft-Dienste reservierten Namen: Die folgenden Domänennamen sind reservierte 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 und vault.azure.net. Die Bereitstellung von SQL Managed Instance in einem virtuellen Netzwerk, das mit einer Azure DNS Private Zone mit einem für Microsoft-Dienste reservierten Namen verknüpft ist, funktioniert nicht. Wenn Sie eine private Azure DNS-Zone mit reserviertem Namen mit einem virtuellen Netzwerk verknüpfen, das eine verwaltete Instanz enthält, ist SQL Managed Instance nicht verfügbar. Informationen zur Private Link-Konfiguration finden Sie unter DNS-Konfiguration für private Azure-Endpunkte.

Zugehöriger Inhalt

• Eine Übersicht finden Sie unter Was ist Azure SQL Managed Instance?.
• Weitere Informationen dazu finden Sie unter
  • Architektur der virtuellen Cluster
  • Dienstgestützte Subnetzkonfiguration
  • Richten Sie ein neues virtuelles Azure-Network oder ein vorhandenes virtuelles Azure-Network ein, in dem Sie SQL Managed Instance bereitstellen können.
  • Berechnen Sie die Größe des Subnetzes, in dem Sie SQL Managed Instance bereitstellen möchten.
• Erfahren Sie, wie Sie eine verwaltete Instanz erstellen:
  • Im Azure-Portal.
  • Mit PowerShell.
  • Mit einer Azure Resource Manager-Vorlage.
  • Mit einer Azure Resource Manager-Vorlage mit einer Jumpbox und SQL Server Management Studio.