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
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.
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
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 den Umleitungsverbindungstyp.
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 wird immer im Proxyverbindungstyp ausgeführt.
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 werden immer im Proxyverbindungstyp ausgeführt.
Erfahren Sie mehr über private Endpunkte und deren Konfiguration in Azure Private Link für Azure SQL Managed Instance.
Verbindungsarchitektur für virtuellen Cluster
Dieser Abschnitt bietet einen tieferen Einblick in die Konnektivitätsarchitektur virtueller Cluster von SQL Managed Instance. Das folgende Diagramm zeigt das konzeptionelle Layout des virtuellen Clusters:
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.
Dienstgestützte Subnetzkonfiguration
Um die Sicherheit, Verwaltungsfähigkeit und Verfügbarkeit des Diensts zu verbessern, wendet SQL Managed Instance eine Netzwerkabsichtsrichtlinie auf einige Elemente der Azure-VNet-Infrastruktur an. Die Richtlinie konfiguriert das Subnetz, die zugeordnete Netzwerksicherheitsgruppe und die Routingtabelle, um sicherzustellen, dass die Mindestanforderungen für SQL Managed Instance erfüllt sind. 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 Einhaltung von Vereinbarungen zum Servicelevel zu gewährleisten. Wenn Sie eine verwaltete Instanz löschen, wird die Netzwerkzielrichtlinie ebenfalls entfernt.
Eine 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.
Sie können Dienstendpunkte zum Konfigurieren von Firewallregeln für virtuelle Netzwerke in Speicherkonten verwenden, in denen Sicherungen und Überwachungsprotokolle gespeichert werden. Auch wenn Dienstendpunkte aktiviert sind, wird Kunden empfohlen, für den Zugriff auf ihre Speicherkonten Azure Private Link zu verwenden. Private Link bietet eine bessere Isolierung als Dienstendpunkte.
Wichtig
Aufgrund der Besonderheiten der Steuerungsebenenkonfiguration ermöglicht eine dienstgestützte Subnetzkonfiguration keine Dienstendpunkte in nationalen Clouds.
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. 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/managedInstancesfü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
- Ressourcen vom Typ
- 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.
Obligatorische Sicherheitsregeln mit dienstgestützter Subnetzkonfiguration
Um den eingehenden Verwaltungsdatenverkehrsfluss sicherzustellen, sind die in der folgenden Tabelle beschriebenen Regeln erforderlich. Die Regeln werden von der Netzwerkabsichtsrichtlinie erzwungen und müssen nicht vom Kunden bereitgestellt werden. Weitere Informationen zur Konnektivitätsarchitektur und zum Verwaltungsdatenverkehr finden Sie unter Verbindungsarchitektur auf Makroebene.
| Name | Port | Protokoll | Quelle | Ziel | Aktion |
|---|---|---|---|---|---|
| healthprobe-in | Any | Any | AzureLoadBalancer | subnet | Allow |
| internal-in | Any | Any | subnet | subnet | Allow |
Um den ausgehenden Verwaltungsdatenverkehrsfluss sicherzustellen, sind die in der folgenden Tabelle beschriebenen Regeln erforderlich. Weitere Informationen zur Konnektivitätsarchitektur und zum Verwaltungsdatenverkehr finden Sie unter Verbindungsarchitektur auf Makroebene.
| Name | Port | Protokoll | Quelle | Ziel | 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
Die in der folgenden Tabelle beschriebenen Routen sind erforderlich, um sicherzustellen, dass der Verwaltungsdatenverkehr direkt an ein Ziel weitergeleitet wird. Die Routen werden von der Netzwerkabsichtsrichtlinie erzwungen und müssen nicht vom Kunden bereitgestellt werden. Weitere Informationen zu Konnektivitätsarchitektur und Verwaltungsdatenverkehr finden Sie unter Verbindungsarchitektur auf Makroebene.
| 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
*Der Wert Internet in der Spalte Nächster Hop weist das Gateway an, den Datenverkehr außerhalb des virtuellen Netzwerks weiterzuleiten. Wenn die Zieladresse jedoch die eines Azure-Diensts ist, leitet Azure den Datenverkehr direkt über das Azure-Netzwerk und nicht außerhalb der Azure-Cloud an den Dienst weiter. Der Datenverkehr zwischen Azure-Diensten wird nicht über das Internet übertragen. Dies gilt unabhängig davon, in welcher Azure-Region das virtuelle Netzwerk vorhanden oder in welcher Azure-Region eine Instanz des Azure-Diensts bereitgestellt ist. Weitere Informationen finden Sie unter Routing von Datenverkehr für virtuelle Azure-Netzwerke.
Sie können der Routingtabelle auch Einträge hinzufügen, um Datenverkehr mit lokalen privaten IP-Adressbereichen als Ziel über das virtuelle Netzwerkgateway oder die virtuelle Netzwerkappliance zu leiten.
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: 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. 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.netundvault.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.
Nächste Schritte
- Eine Übersicht finden Sie unter Was ist Azure SQL Managed Instance?.
- Weitere Informationen finden Sie unter Virtual Cluster-Architektur
- Erfahren Sie, wie Sie ein neues virtuelles Azure-Network oder ein vorhandenes virtuelles Azure-Network einrichten, 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:
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für