Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
gäller för:Azure SQL Managed Instance
Den här artikeln beskriver anslutningsarkitekturen för Azure SQL Managed Instance och hur komponenter dirigerar kommunikationstrafik för en SQL-hanterad instans.
Överblick
I SQL Managed Instance placeras en instans i det virtuella Azure-nätverket och inuti det undernät som är dedikerat till SQL-hanterade instanser. Utrullningen innehåller:
- En säker IP-adress för virtuellt nätverk (VNet-lokalt).
- Möjligheten att ansluta ett lokalt nätverk till SQL Managed Instance.
- Möjligheten att ansluta SQL Managed Instance till en länkad server eller till ett annat lokalt datalager.
- Möjligheten att ansluta SQL Managed Instance till Azure-resurser.
Anslutningsarkitektur på hög nivå
SQL Managed Instance består av tjänstkomponenter som finns på en dedikerad uppsättning isolerade virtuella datorer grupperade efter liknande konfigurationsattribut och anslutna till ett virtuellt kluster. Vissa tjänstkomponenter distribueras i kundens virtuella nätverksundernät, medan andra tjänster fungerar i en säker nätverksmiljö som Microsoft hanterar.
Kundprogram kan ansluta till SQL Managed Instance och kan köra frågor mot och uppdatera databaser i det virtuella nätverket, peer-kopplade virtuella nätverk eller nätverk som är anslutna via VPN eller Azure ExpressRoute.
Följande diagram visar entiteter som ansluter till SQL Managed Instance. Den visar också de resurser som behöver kommunicera med en SQL-hanterad instans. Kommunikationsprocessen längst ned i diagrammet representerar kundprogram och verktyg som ansluter till SQL Managed Instance som datakällor.
SQL Managed Instance är en plattform som en tjänst för en enda klient som fungerar i två plan: ett dataplan och ett kontrollplan.
Det dataplanet distribueras i kundens undernät för kompatibilitet, anslutning och nätverksisolering. Dataplanet är beroende av Azure-tjänster som Azure Storage, Microsoft Entra-ID (tidigare Azure Active Directory) för autentisering och telemetriinsamlingstjänster. Du ser trafik som kommer från undernät som innehåller SQL Managed Instance gå till dessa tjänster.
Det kontrollplanet utför distributions-, hanterings- och kärnservicetjänster via automatiserade agenter. Dessa agenter har exklusiv åtkomst till de beräkningsresurser som använder tjänsten. Du kan inte använda SSH eller Remote Desktop Protocol för att komma åt dessa värdar. All kontrollplanskommunikation krypteras och signeras med hjälp av certifikat. För att kontrollera tillförlitligheten hos kommunicerande parter verifierar SQL Managed Instance ständigt dessa certifikat med hjälp av listor över återkallade certifikat.
Kommunikationsöversikt
Program kan ansluta till SQL Managed Instance via tre typer av slutpunkter: VNet-lokal slutpunkt, offentlig slutpunktoch privata slutpunkter. Dessa slutpunkter uppvisar distinkta egenskaper och beteenden som är lämpliga för olika scenarier.
VNet-lokal slutpunkt
Den VNet-lokala slutpunkten är standardmetod för att ansluta till SQL Managed Instance. Det VNet-lokala slutpunktsdomännamnet är i form av <mi_name>.<dns_zone>.database.windows.net. Det här domännamnet matchar en IP-adress från undernätets adressintervall. Använd den VNet-lokala slutpunkten för att ansluta till en SQL Managed Instance i alla standardanslutningsscenarier. Den VNet-lokala slutpunkten accepterar anslutningar på port 1433.
Den VNet-lokala slutpunkten stöder anslutningstyper för proxy och omdirigering.
När du ansluter till den VNet-lokala slutpunkten använder du alltid dess domännamn och tillåter inkommande trafik på de portar som krävs i hela undernätsintervallet, eftersom den underliggande IP-adressen ibland kan ändras.
Så här hittar du det VNet-lokala slutpunktsdomännamnet för en instans:
- Azure-portalen: I översiktsfönstret, i avsnittet Essentials, visar Värd domännamnet för VNet-lokal slutpunktsdomännamn.
-
PowerShell:
Get-AzSqlInstance -ResourceGroupName <resource-group> -Name <mi-name>visar det VNet-lokala slutpunktsdomännamnet somfullyQualifiedDomainNameegenskap. -
Azure CLI:
az sql mi show -g <resource-group> -n <mi-name>visar det VNet-lokala slutpunktsdomännamnet somfullyQualifiedDomainNameegenskap.
För förbättrad säkerhet anger du en krypterad anslutning och litar inte på certifikatet. Mer information finns i Säkerhetsöversikt.
Offentlig slutpunkt
Den offentliga slutpunkten är ett domännamn i form av <mi_name>.public.<dns_zone>.database.windows.net. Det här domännamnet matchar en offentlig IP-adress som kan nås från Internet. Den offentliga slutpunkten är lämplig för scenarier när en SQL-hanterad instans måste vara tillgänglig via det offentliga Internet. När du till exempel ansluter till den från ett annat virtuellt nätverk när peering eller privata slutpunkter inte är tillgängliga. Offentliga slutpunkter transporterar endast klienttrafik och kan inte användas för datareplikering mellan två instanser, till exempel redundansgrupper eller länk för hanterad instans. Offentlig slutpunkt accepterar anslutningar på port 3342.
Offentlig slutpunkt använder alltid anslutningstypen Proxy oavsett inställning för anslutningstyp.
En instans offentliga slutpunktsdomännamn är lika med dess VNet-lokala slutpunktsnamn med etiketten public infogad mellan värdnamnet och resten av domänen: <mi-name>.public.<dns-zone>.database.windows.net.
När du ansluter till den offentliga slutpunkten ska du alltid använda dess domännamn och tillåta inkommande trafik på port 3342 över hela undernätsintervallet, eftersom den underliggande IP-adressen ibland kan ändras.
Lär dig hur du konfigurerar en offentlig slutpunkt i Konfigurera offentlig slutpunkt för Azure SQL Managed Instance.
Privata slutpunkter
En privat slutpunkt är en valfri fast IP-adress i ett annat virtuellt nätverk som dirigerar trafik till din SQL-hanterade instans. En Azure SQL Managed Instance kan ha flera privata slutpunkter i flera virtuella nätverk. Privata slutpunkter transporterar endast klienttrafik och kan inte användas för datareplikering mellan två instanser, till exempel redundansgrupper eller länken Hanterad instans. Den privata slutpunkten accepterar anslutningar på port 1433.
Privata slutpunkter använder alltid anslutningstypen Proxy oavsett inställning för anslutningstyp.
En instans privata slutpunktsdomännamn är lika med dess VNet-lokala domännamn om inte slutpunkten har konfigurerats på ett annat sätt. Detta är fallet när både den privata slutpunkten och den VNet-lokala slutpunkten finns i samma virtuella nätverk. Mer information finns i Konfigurera domännamnsmatchning för privat slutpunkt.
När du ansluter till en privat slutpunkt använder du alltid domännamnet eftersom det inte stöds att ansluta till Azure SQL Managed Instance via dess IP-adress än. IP-adressen för en privat slutpunkt ändras dock inte.
Läs mer om privata slutpunkter och hur du konfigurerar dem i Azure Private Link för Azure SQL Managed Instance.
Arkitektur för anslutning till virtuellt kluster
Följande diagram visar den konceptuella layouten för arkitekturen för virtuellt kluster:
Domännamnet för den VNet-lokala slutpunkten matchar den privata IP-adressen för en intern lastbalanserare. Även om det här domännamnet är registrerat i en offentlig DNS-zon (Domain Name System) och kan matchas offentligt, tillhör ip-adressen undernätets adressintervall och kan endast nås inifrån det virtuella nätverket som standard.
Lastbalanseraren dirigerar trafik till en SQL Managed Instance-gateway. Eftersom flera SQL-hanterade instanser kan köras i samma kluster använder gatewayen värdnamnet SQL Managed Instance som det visas i anslutningssträngen för att omdirigera trafik till rätt SQL-motortjänst.
Värdet för dns-zone genereras automatiskt när du skapar klustret. Om ett nyligen skapat kluster är värd för en sekundär SQL-hanterad instans delar det sitt zon-ID med det primära klustret.
Nätverkskrav
Azure SQL Managed Instance kräver att aspekter av det delegerade undernätet konfigureras på specifika sätt, vilket du kan uppnå med hjälp av tjänststödd undernätskonfiguration. Utöver vad tjänsten kräver har användarna fullständig kontroll över nätverkskonfigurationen för undernätet, till exempel:
- Tillåta eller blockera trafik på vissa eller alla portar.
- Lägga till poster i routningstabellen för att dirigera trafik via virtuella nätverksapparater eller en gateway.
- Konfigurera anpassad DNS-upplösning.
- Konfigurera peering eller ett VPN.
För att uppfylla kriterierna för kompatibel nätverkskonfiguration i serviceavtalet för Microsoft Online Services måste det virtuella nätverket och undernätet där SQL Managed Instance distribueras uppfylla följande krav:
- dedikerat undernät: Undernätet SQL Managed Instance använder kan endast delegeras till SQL Managed Instance-tjänsten. Undernätet kan inte vara ett gatewayundernät och du kan bara distribuera SQL Managed Instance-resurser i undernätet.
-
undernätsdelegering: Undernätet för SQL Managed Instance måste delegeras till
Microsoft.Sql/managedInstancesresursprovider. - Nätverkssäkerhetsgrupp: En nätverkssäkerhetsgrupp måste vara associerad med undernätet SQL Managed Instance. Du kan använda en nätverkssäkerhetsgrupp för att styra åtkomsten till SQL Managed Instance-dataslutpunkten genom att filtrera inkommande trafik på port 1433. Tjänsten etablerar automatiskt regler och håller dem aktuella efter behov för att tillåta oavbrutet flöde av hanteringstrafik.
- Routningstabell: En routningstabell måste associeras med UNDERNÄTET SQL Managed Instance. Du kan lägga till poster i den här routningstabellen, till exempel för att dirigera trafik till en lokal via en virtuell nätverksgateway, eller lägga till standardväg 0.0.0.0/0 dirigera all trafik via en virtuell nätverksinstallation, till exempel en brandvägg. Azure SQL Managed Instance etablerar och hanterar automatiskt nödvändiga poster i routningstabellen.
- Tillräckliga IP-adresser: UNDERnätet för SQL Managed Instance måste ha minst 32 IP-adresser. Mer information finns i Fastställa storleken på undernätet för SQL Managed Instance. Du kan distribuera SQL-hanterade instanser i ett befintligt nätverk när du har konfigurerat det för att uppfylla nätverkskraven för SQL Managed Instance. Annars skapar du ett nytt nätverk och undernät.
-
Tillåts av Azure-principer: Om du använder Azure Policy för att förhindra att resurser skapas eller ändras i ett omfång som innehåller ett SQL Managed Instance-undernät eller ett virtuellt nätverk, får dina principer inte hindra SQL Managed Instance från att hantera sina interna resurser. Följande resurser måste undantas från avslagsprincipens effekter för normal drift:
- Resurser av typen
Microsoft.Network/serviceEndpointPolicies, när resursnamnet börjar med\_e41f87a2\_ - Alla resurser av typen
Microsoft.Network/networkIntentPolicies - Alla resurser av typen
Microsoft.Network/virtualNetworks/subnets/contextualServiceEndpointPolicies
- Resurser av typen
- Lås på virtuellt nätverk: Lås på det dedikerade undernätets virtuella nätverk, dess överordnade resursgrupp eller prenumeration kan ibland störa hanterings- och underhållsåtgärder för SQL Managed Instance. Var särskilt försiktig när du använder resurslås.
- Lösbara offentliga DNS-poster: Om det virtuella nätverket har konfigurerats för att använda en anpassad DNS-server måste DNS-servern kunna lösa offentliga DNS-poster. Användning av funktioner som Microsoft Entra-autentisering kan kräva att du löser mer fullständigt kvalificerade domännamn (FQDN). Mer information finns i Lösa privata DNS-namn i Azure SQL Managed Instance.
-
Nödvändiga DNS-poster: SQL-hanterade instanser är beroende av att vissa domännamn matchas korrekt. Dessa domännamn får inte åsidosättas i sina virtuella nätverk, antingen via privata Azure DNS-zoner eller av en anpassad DNS-server. Annars kan SQL-hanterade instanser inte distribueras eller bli otillgängliga. Följande domäner får inte åsidosättas:
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.netochvault.azure.net. Du kan fortfarande skapa privata slutpunkter i en SQL-hanterad instans virtuella nätverk, även till resurser i ovan nämnda domäner. Privata slutpunkter använder en DNS-mekanism som inte kräver att en lokal DNS-server blir auktoritativ för en hel zon. - AzurePlatformDNS-taggen: Om du använder AzurePlatformDNS -tjänsttaggen för att blockera plattforms-DNS-matchning kan SQL Managed Instance vara otillgängligt. Även om SQL Managed Instance stöder kunddefinierad DNS för DNS-matchning i motorn finns det ett beroende av Azure DNS för plattformsåtgärder.
Tjänststödd undernätskonfiguration
För att förbättra tjänstens säkerhet, hanterbarhet och tillgänglighet använder SQL Managed Instance tjänststödd undernätskonfiguration och en princip för nätverksinsikter i den virtuella Azure-nätverksinfrastrukturen för att konfigurera nätverket, associerade komponenter och routningstabellen för att säkerställa att minimikraven för SQL Managed Instance uppfylls.
Automatiskt konfigurerade regler för nätverkssäkerhet och routningstabeller visas för kunden och kommenteras med något av dessa prefix:
-
Microsoft.Sql-managedInstances_UseOnly_mi-för obligatoriska regler och vägar -
Microsoft.Sql-managedInstances_UseOnly_mi-optional-för valfria regler och vägar
Mer information finns i Konfiguration av tjänststödda undernät.
Mer information om anslutningsarkitektur och hanteringstrafik finns i Arkitektur för högnivåanslutning.
Nätverksbegränsningar
Följande begränsningar för virtuella nätverksfunktioner och trafik gäller:
- Privata undernät: Distribution av SQL-hanterade instanser i privata undernät (där standardutgående åtkomst är inaktiverad) stöds för närvarande inte.
- VNet-kryptering: Distribution och drift av SQL-hanterade instanser i virtuella nätverk där Azure Virtual Network-kryptering är aktiverat stöds för närvarande inte.
- Databaspost till externa SMTP-reläer på port 25: Att skicka databaspost via port 25 till externa e-posttjänster är endast tillgängligt för vissa prenumerationstyper i Microsoft Azure. Instanser av andra prenumerationstyper bör använda en annan port (till exempel 587) för att kontakta externa SMTP-reläer. Annars kan instanser misslyckas med att leverera databasmeddelande. Mer information finns i Felsöka utgående SMTP-anslutningsproblem i Azure.
- Microsoft-peering: Aktivering av Microsoft-peering på ExpressRoute-kretsar som är peer-kopplade direkt eller transitivt med ett virtuellt nätverk där SQL Managed Instance finns påverkar trafikflödet mellan SQL Managed Instance-komponenter i det virtuella nätverket och tjänster den är beroende av. Resultat av tillgänglighetsproblem. SQL Managed Instance-distributioner till ett virtuellt nätverk som redan har Microsoft-peering aktiverat förväntas misslyckas.
- Global peering för virtuella nätverk: Peering-anslutning för virtuella nätverk i Azure-regioner fungerar inte för SQL-hanterade instanser som placeras i undernät som skapades före den 9 september 2020.
- Peering för virtuella nätverk – konfiguration: När du upprättar peering för virtuella nätverk mellan virtuella nätverk som innehåller undernät med SQL-hanterade instanser måste sådana undernät använda olika routningstabeller och nätverkssäkerhetsgrupper (NSG). Om du återanvänder routningstabellen och NSG:n i två eller flera undernät som deltar i peering för virtuella nätverk orsakas anslutningsproblem i alla undernät med hjälp av dessa routningstabeller eller NSG, vilket gör att SQL Managed Instances hanteringsåtgärder misslyckas.
- NAT-gateway: För närvarande stöds inte användning av NAT för virtuella Azure-nätverk för att styra utgående anslutningar med en specifik offentlig IP-adress.
- IPv6 för Azure Virtual Network: Distribution av SQL Managed Instance till virtuella IPv4/IPv6-nätverk med dubbla staplar förväntas misslyckas. Om du associerar en nätverkssäkerhetsgrupp eller en routningstabell med användardefinierade vägar (UDR) som innehåller IPv6-adressprefix till ett SQL Managed Instance-undernät blir SQL Managed Instance otillgängligt. Om du lägger till IPv6-adressprefix i en nätverkssäkerhetsgrupp eller UDR som redan är associerad med ett SQL-hanterat instansundernät blir SQL Managed Instance inte tillgängligt. SQL Managed Instance-distributioner till ett undernät med en nätverkssäkerhetsgrupp och UDR som redan har IPv6-prefix förväntas misslyckas.
- TLS 1.2 tillämpas på utgående anslutningar: Från och med januari 2020 tillämpar Microsoft TLS 1.2 för intratjänsttrafik i alla Azure-tjänster. För SQL Managed Instance resulterade detta i att TLS 1.2 tillämpades på utgående anslutningar som används för replikering och på länkade serveranslutningar till SQL Server. Om du använder en version av SQL Server som är tidigare än 2016 med SQL Managed Instance kontrollerar du att du tillämpar TLS 1.2-specifika uppdateringar.
- Internt tillbakafall till Azure DNS: SQL-hanterade instanser är beroende av fungerande DNS-upplösning i sina virtuella nätverk. Om en SQL-hanterad instanss virtuella nätverk har konfigurerats för att använda anpassade DNS-servrar och en DNS-begäran som utfärdats till anpassade DNS-servrar inte kan slutföras inom ett visst intervall (1–2 sekunder), upprepar SQL-hanterad instans begäran mot Azure DNS i det virtuella nätverket.
Relaterat innehåll
- En översikt finns i Vad är Azure SQL Managed Instance?.
- Mer information finns i:
- Arkitektur för virtuella kluster.
- Tjänststödd undernätskonfiguration.
- Konfigurera ett nytt virtuellt Azure-nätverk eller ett befintligt virtuellt Azure-nätverk där du kan distribuera SQL Managed Instance.
- Beräkna storleken på undernätet där du vill distribuera SQL Managed Instance.
- Lär dig hur du skapar en SQL-hanterad instans:
- Från Azure-portalen.
- Med hjälp av PowerShell.
- Genom att använda en Azure Resource Manager-mall.
- Genom att använda en Azure Resource Manager-mall med en jumpbox och SQL Server Management Studio.