Delen via

Connectiviteitsarchitectuur voor Azure SQL Managed Instance

van toepassing op:Azure SQL Managed Instance

In dit artikel wordt de connectiviteitsarchitectuur van Azure SQL Managed Instance beschreven en wordt beschreven hoe onderdelen communicatieverkeer voor een met SQL beheerd exemplaar leiden.

Overzicht

In SQL Managed Instance wordt een exemplaar geplaatst binnen het Azure Virtual Network en binnen het subnet dat specifiek is gereserveerd voor SQL Managed Instances. De implementatie biedt:

  • Een beveiligd IP-adres van een virtueel netwerk (VNet-lokaal).
  • De mogelijkheid om een on-premises netwerk te verbinden met SQL Managed Instance.
  • De mogelijkheid om SQL Managed Instance te verbinden met een gekoppelde server of een ander on-premises gegevensarchief.
  • De mogelijkheid om SQL Managed Instance te verbinden met Azure-resources.

Architectuur voor connectiviteit op hoog niveau

SQL Managed Instance bestaat uit serviceonderdelen die worden gehost op een toegewezen set geïsoleerde virtuele machines die zijn gegroepeerd op vergelijkbare configuratiekenmerken en zijn gekoppeld aan een virtueel cluster. Sommige serviceonderdelen worden geïmplementeerd in het subnet van het virtuele netwerk van de klant, terwijl andere services werken binnen een beveiligde netwerkomgeving die Door Microsoft wordt beheerd.

diagram met de architectuur voor connectiviteit op hoog niveau voor Azure SQL Managed Instance na november 2022.

Klanttoepassingen kunnen verbinding maken met SQL Managed Instance en databases in het virtuele netwerk, gekoppeld virtueel netwerk of netwerk dat is verbonden met VPN of Azure ExpressRoute, opvragen en bijwerken.

In het volgende diagram ziet u entiteiten die verbinding maken met SQL Managed Instance. U ziet ook de resources die moeten communiceren met een met SQL beheerd exemplaar. Het communicatieproces onderaan het diagram vertegenwoordigt klanttoepassingen en hulpprogramma's die als gegevensbronnen verbinding maken met SQL Managed Instance.

diagram met entiteiten in de connectiviteitsarchitectuur voor Azure SQL Managed Instance na november 2022.

SQL Managed Instance is een platform als een service met één tenant die in twee vlakken werkt: een gegevensvlak en een besturingsvlak.

Het gegevensvlak wordt geïmplementeerd in het subnet van de klant voor compatibiliteit, connectiviteit en netwerkisolatie. Het gegevensvlak is afhankelijk van Azure-services zoals Azure Storage, Microsoft Entra-id (voorheen Azure Active Directory) voor verificatie- en telemetrieverzamelingsservices. U ziet verkeer dat afkomstig is van subnetten die SQL Managed Instance bevatten naar die services.

Het besturingssysteem omvat de functies voor implementatie, beheer en onderhoud van kernservices via geautomatiseerde agents. Deze agents hebben exclusieve toegang tot de rekenresources die de service gebruiken. U kunt SSH of Remote Desktop Protocol niet gebruiken om toegang te krijgen tot deze hosts. Alle communicatie op het besturingsvlak wordt versleuteld en ondertekend met behulp van certificaten. Sql Managed Instance controleert deze certificaten voortdurend met behulp van certificaatintrekkingslijsten om de betrouwbaarheid van de communicerende partijen te controleren.

Communicatieoverzicht

Toepassingen kunnen verbinding maken met SQL Managed Instance via drie typen eindpunten: VNet-lokaal eindpunt, openbaar eindpunten privé-eindpunten. Deze eindpunten vertonen verschillende eigenschappen en gedragingen die geschikt zijn voor verschillende scenario's.

Diagram dat het bereik van zichtbaarheid laat zien voor VNet-lokale, publieke en private eindpunten naar een Azure SQL Managed Instance.

VNet-lokaal eindpunt

Het VNet-lokale eindpunt is de standaardinstelling om verbinding te maken met SQL Managed Instance. De naam van het VNet-lokale eindpuntdomein heeft de vorm van <mi_name>.<dns_zone>.database.windows.net. Deze domeinnaam wordt omgezet in een IP-adres uit het adresbereik van het subnet. Gebruik het lokale VNet-eindpunt om verbinding te maken met een met SQL beheerd exemplaar in alle standaardconnectiviteitsscenario's. Het lokale VNet-eindpunt accepteert verbindingen op poort 1433.

Het lokale VNet-eindpunt ondersteunt proxy- en omleidingsverbindingstypen.

Wanneer u verbinding maakt met het VNet-lokale eindpunt, gebruikt u altijd de domeinnaam en staat u inkomend verkeer toe op de vereiste poorten in het hele subnetbereik, omdat het onderliggende IP-adres af en toe kan veranderen.

Zoek de VNet-lokale eindpuntdomeinnaam van een instantie:

  • Azure Portal: in het deelvenster Overzicht , in de sectie Essentials , toont de hostwaarde de domeinnaam van het VNet-lokale eindpunt.
  • PowerShell: Get-AzSqlInstance -ResourceGroupName <resource-group> -Name <mi-name> toont de domeinnaam van het VNet-lokale eindpunt als de fullyQualifiedDomainName eigenschap.
  • Azure CLI: az sql mi show -g <resource-group> -n <mi-name> toont de domeinnaam van het VNet-lokale eindpunt als de fullyQualifiedDomainName eigenschap.

Voor een betere beveiliging geeft u een versleutelde verbinding op en vertrouwt u het certificaat niet. Zie Beveiligingsoverzicht voor meer informatie.

Openbaar eindpunt

Het openbare eindpunt is een domeinnaam in de vorm van <mi_name>.public.<dns_zone>.database.windows.net. Deze domeinnaam wordt omgezet in een openbaar IP-adres dat bereikbaar is vanaf internet. Het openbare eindpunt is geschikt voor scenario's wanneer een met SQL beheerd exemplaar toegankelijk moet zijn via het openbare internet. Als u er bijvoorbeeld verbinding mee maakt vanuit een ander virtueel netwerk wanneer peering of privé-eindpunten niet beschikbaar zijn. Openbare eindpunten dragen alleen clientverkeer mee en kunnen niet worden gebruikt voor gegevensreplicatie tussen twee exemplaren, zoals failovergroepen of een koppeling naar het beheerde exemplaar. Openbaar eindpunt accepteert verbindingen op poort 3342.

Het openbare eindpunt gebruikt altijd het verbindingstype Proxy , ongeacht de instelling van het verbindingstype.

De domeinnaam van het openbare eindpunt van een exemplaar is gelijk aan de VNet-lokale eindpuntnaam, met het label public ingevoegd tussen de hostnaam en de rest van het domein: <mi-name>.public.<dns-zone>.database.windows.net.

Wanneer u verbinding maakt met het openbare eindpunt, gebruikt u altijd de domeinnaam en staat u inkomend verkeer toe op poort 3342 in het hele subnetbereik, omdat het onderliggende IP-adres af en toe kan veranderen.

Meer informatie over het instellen van een openbaar eindpunt in Openbaar eindpunt configureren voor azure SQL Managed Instance.

Privé-eindpunten

Een privé-eindpunt is een optioneel vast IP-adres in een ander virtueel netwerk dat verkeer naar uw met SQL beheerde exemplaar leidt. Eén met Azure SQL beheerd exemplaar kan meerdere privé-eindpunten in meerdere virtuele netwerken hebben. Privé-eindpunten dragen alleen clientverkeer en kunnen niet worden gebruikt voor gegevensreplicatie tussen twee exemplaren, zoals failovergroepen of een koppeling naar managed instance. Het privé-eindpunt accepteert verbindingen op poort 1433.

Privé-eindpunten gebruiken altijd het verbindingstype Proxy , ongeacht de instelling van het verbindingstype.

De domeinnaam van een privé-eindpunt van een instantie is gelijk aan de VNet-lokale domeinnaam, tenzij het eindpunt anders is geconfigureerd. Dit is het geval wanneer zowel het privé-eindpunt als het lokale VNet-eindpunt zich in hetzelfde virtuele netwerk bevinden. Zie voor meer informatie Domeinnaamomzetting instellen voor privé-eindpunten.

Wanneer u verbinding maakt met een privé-eindpunt, gebruikt u altijd de domeinnaam, omdat verbinding maken met Azure SQL Managed Instance via het IP-adres nog niet wordt ondersteund. Het IP-adres van een privé-eindpunt verandert echter niet.

Meer informatie over privé-eindpunten en hoe u deze configureert in Azure Private Link voor Azure SQL Managed Instance.

Connectiviteitsarchitectuur voor virtuele clusters

In het volgende diagram ziet u de conceptuele indeling van de architectuur van het virtuele cluster:

diagram met de connectiviteitsarchitectuur voor virtuele clusters voor Azure SQL Managed Instance.

De domeinnaam van het VNet-lokale eindpunt wordt omgezet in het privé-IP-adres van een interne load balancer. Hoewel deze domeinnaam is geregistreerd in een openbare DNS-zone (Domain Name System) en openbaar kan worden omgezet, behoort het IP-adres tot het adresbereik van het subnet en kan het alleen worden bereikt vanuit het virtuele netwerk.

Met de load balancer wordt verkeer omgeleid naar een sql Managed Instance-gateway. Omdat meerdere met SQL beheerde exemplaren binnen hetzelfde cluster kunnen worden uitgevoerd, gebruikt de gateway de hostnaam van sql Managed Instance, zoals te zien is in de verbindingsreeks om verkeer om te leiden naar de juiste SQL Engine-service.

De waarde voor dns-zone wordt automatisch gegenereerd wanneer u het cluster maakt. Als een nieuw gemaakt cluster als host fungeert voor een secundair met SQL beheerd exemplaar, wordt de zone-id gedeeld met het primaire cluster.

Netwerkvereisten

Voor Azure SQL Managed Instance moeten aspecten van het gedelegeerde subnet op specifieke manieren worden geconfigureerd, wat u kunt bereiken met behulp van de service-ondersteuningssubnetconfiguratie. Naast wat de service vereist, hebben gebruikers volledige controle over hun subnetnetwerkconfiguratie, zoals:

  • Verkeer op sommige of alle poorten toestaan of blokkeren.
  • Vermeldingen toevoegen aan de routetabel om verkeer te routeren via virtuele netwerkapparaten of een gateway.
  • Aangepaste DNS-omzetting configureren.
  • Peering ofwel een VPN instellen.

Om te voldoen aan de criteria voor conforme netwerkconfiguratie in de Service Level Agreement voor Microsoft Online Services, moeten het virtuele netwerk en subnet waarin SQL Managed Instance wordt geïmplementeerd, voldoen aan de volgende vereisten:

  • toegewezen subnet: het subnet dat door SQL beheerd exemplaar wordt gebruikt, kan alleen worden gedelegeerd aan de SQL Managed Instance-service. Het subnet kan geen gatewaysubnet zijn en u kunt alleen SQL Managed Instance-resources in het subnet implementeren.
  • Subnetdelegatie: Het subnet van SQL Managed Instance moet worden gedelegeerd aan de Microsoft.Sql/managedInstances resourceprovider.
  • netwerkbeveiligingsgroep: er moet een netwerkbeveiligingsgroep zijn gekoppeld aan het subnet sql Managed Instance. U kunt een netwerkbeveiligingsgroep gebruiken om de toegang tot het sql Managed Instance-gegevenseindpunt te beheren door binnenkomend verkeer op poort 1433 te filteren. De service provisioneert automatisch regels en houdt ze actueel om een ononderbroken doorstroom van beheerverkeer mogelijk te maken.
  • routetabel: er moet een routetabel zijn gekoppeld aan het subnet sql Managed Instance. U kunt vermeldingen toevoegen aan deze routetabel, bijvoorbeeld om verkeer naar de locatie te routeren via een gateway van een virtueel netwerk of om de standaardroute 0.0.0.0/0 toe te voegen al het verkeer via een virtueel netwerkapparaat, zoals een firewall, door te leiden. Azure SQL Managed Instance richt automatisch de vereiste vermeldingen in de routetabel in en beheert deze.
  • Voldoende IP-adressen: het subnet SQL Managed Instance moet ten minste 32 IP-adressen hebben. Zie De grootte van het subnet bepalen voor sql Managed Instancevoor meer informatie. U kunt SQL Managed Instances binnen een bestaand netwerk implementeren nadat u het hebt geconfigureerd om te voldoen aan de netwerkvereisten voor SQL Managed Instance. Anders maakt u een nieuw netwerk en subnetaan.
  • Toegestaan door Azure-beleid: Als u Azure Policy gebruikt om te voorkomen dat resources worden aangemaakt of gewijzigd binnen een bereik dat een SQL Managed Instance-subnet of virtueel netwerk omvat, mag uw beleid niet voorkomen dat SQL Managed Instance zijn interne resources beheert. De volgende resources moeten worden uitgesloten van de beleidseffecten van weigering voor een normaal functionerende situatie.
    • Resources van het type Microsoft.Network/serviceEndpointPolicies, wanneer de resourcenaam begint met \_e41f87a2\_
    • Alle bronnen van type Microsoft.Network/networkIntentPolicies
    • Alle bronnen van type Microsoft.Network/virtualNetworks/subnets/contextualServiceEndpointPolicies
  • Vergrendelingen in een virtueel netwerk: Vergrendelingen op het virtuele netwerk van het toegewezen subnet, de bovenliggende resourcegroep of het abonnement kunnen af en toe de beheer- en onderhoudswerkzaamheden van SQL Managed Instance belemmeren. Wees extra voorzichtig bij het gebruik van resource locks.
  • Oplosbare openbare DNS-records: Als het virtuele netwerk is geconfigureerd voor het gebruik van een aangepaste DNS-server, moet de DNS-server openbare DNS-records kunnen oplossen. Het gebruik van functies zoals Microsoft Entra-verificatie vereist mogelijk het omzetten van meer volledig gekwalificeerde domeinnamen (FQDN's). Zie Het omzetten van privé-DNS-namen in Azure SQL Managed Instancevoor meer informatie.
  • Vereiste DNS-records: SQL Managed Instances zijn afhankelijk van het correct oplossen van bepaalde domeinnamen. Deze domeinnamen mogen niet worden overschreven in hun virtuele netwerken, hetzij via privézones van Azure DNS of door een aangepaste DNS-server. Anders kunnen beheerde SQL-exemplaren niet worden geïmplementeerd of zijn ze mogelijk niet beschikbaar. De volgende domeinen mogen niet worden overschreven: 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.neten vault.azure.net. U kunt nog steeds privé-eindpunten maken in het virtuele netwerk van een SQL Managed Instance, zelfs naar resources in de bovengenoemde domeinen. Privé-eindpunten maken gebruik van een DNS-mechanisme dat niet vereist dat een lokale DNS-server gezaghebbend wordt voor een hele zone.
  • AzurePlatformDNS-tag: als u de servicetag AzurePlatformDNS gebruikt om DNS-resolutie van het platform te blokkeren, is SQL Managed Instance mogelijk niet beschikbaar. Hoewel SQL Managed Instance ondersteuning biedt voor door de klant gedefinieerde DNS voor DNS-omzetting in de engine, is er een afhankelijkheid van Azure DNS voor platformbewerkingen.

Configuratie van door service ondersteunde subnetten

Om de beveiliging, beheerbaarheid en beschikbaarheid van services te verbeteren, maakt SQL Managed Instance gebruik van servicehulpbeleid voor subnetconfiguratie en netwerkintentie in de infrastructuur van het virtuele Azure-netwerk om het netwerk, de bijbehorende onderdelen en de routetabel te configureren om ervoor te zorgen dat aan de minimale vereisten voor SQL Managed Instance wordt voldaan.

Automatisch geconfigureerde regels voor netwerkbeveiliging en routetabel zijn zichtbaar voor de klant en voorzien van een van deze voorvoegsels:

  • Microsoft.Sql-managedInstances_UseOnly_mi- voor verplichte regels en routes
  • Microsoft.Sql-managedInstances_UseOnly_mi-optional- voor optionele regels en routes

Raadpleeg Service-ondersteunde subnetconfiguratie voor meer informatie.

Voor meer informatie over de connectiviteitsarchitectuur en het beheerverkeer, zie Connectiviteit op hoog niveau.

Netwerkbeperkingen

De volgende beperkingen voor functies en verkeer van virtuele netwerken zijn van kracht:

  • Privésubnetten: het implementeren van met SQL beheerde exemplaren in privésubnetten (waarbij standaard uitgaande toegang is uitgeschakeld) wordt momenteel niet ondersteund.
  • VNet-versleuteling: het implementeren en gebruiken van met SQL beheerde exemplaren in virtuele netwerken waarvoor Azure Virtual Network-versleuteling is ingeschakeld, wordt momenteel niet ondersteund.
  • Database-e-mail naar externe SMTP-relays op poort 25: het verzenden van database-e-mail via poort 25 naar externe e-mailservices is alleen beschikbaar voor bepaalde abonnementstypen in Microsoft Azure. Exemplaren van andere abonnementstypen moeten een andere poort (bijvoorbeeld 587) gebruiken om contact op te maken met externe SMTP-relays. Anders kunnen exemplaren geen database-e-mail leveren. Zie Problemen met uitgaande SMTP-connectiviteit in Azureoplossen voor meer informatie.
  • Microsoft-peering: Het inschakelen van Microsoft-peering op ExpressRoute-circuits die rechtstreeks of transitief zijn gekoppeld aan een virtueel netwerk waarin SQL Managed Instance zich bevindt, is van invloed op de verkeersstroom tussen SQL Managed Instance-onderdelen binnen het virtuele netwerk en services waarvan deze afhankelijk is. Resultaat beschikbaarheidsproblemen. Implementaties van SQL Managed Instance in een virtueel netwerk waarvoor Microsoft-peering al is ingeschakeld, zullen naar verwachting mislukken.
  • Wereldwijde peering van virtuele netwerken: Virtuele netwerkpeering in Azure-regio's werkt niet voor SQL-beheerde exemplaren die zijn geplaatst in subnetten die voor 9 september 2020 zijn gemaakt.
  • Peering van virtuele netwerken – configuratie: Bij het tot stand brengen van peering tussen virtuele netwerken die subnetten met SQL-beheerde instanties bevatten, moeten deze subnetten verschillende routetabellen en netwerkbeveiligingsgroepen (NSG) gebruiken. Het opnieuw gebruiken van de routetabel en NSG in twee of meer subnetten die deelnemen aan peering van virtuele netwerken, veroorzaken connectiviteitsproblemen in alle subnetten met behulp van deze routetabellen of NSG, en veroorzaken dat de beheerbewerkingen van SQL Managed Instance mislukken.
  • NAT-gateway: Het gebruik van Azure Virtual Network NAT om uitgaande connectiviteit met een specifiek openbaar IP-adres te beheren, wordt momenteel niet ondersteund.
  • IPv6 voor Azure Virtual Network: het implementeren van SQL Managed Instance in virtuele IPv4-/IPv6-netwerken met dubbele stack zal naar verwachting mislukken. Als u een netwerkbeveiligingsgroep of een routetabel koppelt aan door de gebruiker gedefinieerde routes (UDR's) die IPv6-adresvoorvoegsels bevat voor een subnet van sql Managed Instance, is SQL Managed Instance niet beschikbaar. Bovendien, als u IPv6-adresvoorvoegsels toevoegt aan een netwerkbeveiligingsgroep of UDR die al is gekoppeld aan een subnet van SQL Managed Instance, wordt SQL Managed Instance niet meer beschikbaar. Implementaties van SQL Managed Instance naar een subnet met een netwerkbeveiligingsgroep en UDR met al IPv6-voorvoegsels zullen naar verwachting mislukken.
  • TLS 1.2 wordt afgedwongen voor uitgaande verbindingen: Vanaf januari 2020 dwingt Microsoft TLS 1.2 af voor intraserviceverkeer in alle Azure-services. Voor SQL Managed Instance werd TLS 1.2 afgedwongen op uitgaande verbindingen die worden gebruikt voor replicatie en op gekoppelde serververbindingen met SQL Server. Als u een versie van SQL Server gebruikt die ouder is dan 2016 met SQL Managed Instance, moet u ervoor zorgen dat u tls 1.2-specifieke updates toepast.
  • Interne terugval naar Azure DNS: SQL-beheerde instanties zijn afhankelijk van werkende DNS-omzetting in hun virtuele netwerken. Als het virtuele netwerk van een met SQL beheerd exemplaar is geconfigureerd voor het gebruik van aangepaste DNS-servers en een DNS-aanvraag die is uitgegeven aan aangepaste DNS-servers niet binnen een bepaald interval kan worden voltooid (1-2 seconden), herhaalt SQL Managed Instance de aanvraag tegen Azure DNS in dat virtuele netwerk.

Verwante inhoud