Automatiska interna anslutningstester för Azure SQL Managed Instance

gäller för:Azure SQL Managed Instance

Den här artikeln beskriver de automatiska interna anslutningstester som körs på Azure SQL Managed Instance för att övervaka tjänstens tillförlitlighet och påskynda problemidentifiering.

Dessa tester är helt automatiserade och kräver ingen åtgärd från dig. Proaktiv övervakning av interna nätverksanslutningar gör att Microsoft snabbt kan identifiera potentiella problem och upprätthålla en stabil anslutning från slutpunkt till slutpunkt.

Anslutningstester körs från ett par interna IP-adresser från undernätsintervallet som är värd för den SQL-hanterade instansen. Tester kräver ingen extern inkommande eller utgående anslutning. Ytterligare IP-adresser är reserverade för anslutningstester och spårningar kan visas i observerbarhetsloggar.

Från och med maj 2026 körs anslutningstester med jämna mellanrum på alla SQL-hanterade instanser.

Benefits

Automatiska interna anslutningstester ger följande fördelar:

  • Diagnostisera problem med intern tjänst- och nätverkstillgänglighet.
  • Påskynda identifiering av problem och minska minskningstiden.
  • Förbättra insynen i det interna nätverkstillståndet för SQL Managed Instance.

Testresultat används internt och återspeglas inte i Service Health eller Resource Health.

Driftseffekter

Interna anslutningstester har följande driftspåverkan:

  • Två extra IP-adresser etableras för varje VM-grupp, vilket ökar IP-adresskravet från sex till åtta. Mer information finns i Fastställa undernätsstorlek och -intervall.
  • Testerna körs var 10:e sekund och har en försumbar prestandapåverkan på nätverkets dataflöde och tjänstprestanda.
  • Nya undernät som skapats för SQL-hanterade instanser reserverar automatiskt de extra IP-adresser som krävs för anslutningstester.
  • I befintliga undernät med SQL-hanterade instanser reserverar testerna endast extra IP-adresser om undernätet har tillräckligt med lediga IP-adresser för att stödja de extra IP-adresser som krävs av testerna. Om ett befintligt undernät inte har tillräckligt med kostnadsfria IP-adresser körs inte testerna.

Säkerhetsfrågor

Följande säkerhetsprinciper vägleder utformningen av interna anslutningstester:

  • Testerna är begränsade till en enda SQL-hanterad instans och körs i dess delegerade virtuella nätverk och undernät.
  • Anslutningstester kan inte komma åt innehållet i någon databas.
  • Testresultaten innehåller inga kunddata utöver instansnamnet.
  • Endast Microsoft tekniker kan komma åt resultaten.
  • Granskningssystem kan registrera misslyckade inloggningsförsök som genererats av testerna. Mer information om hur du identifierar de här posterna finns i Övervaka misslyckade inloggningsförsök som orsakas av end-to-end-tester.

Utförda tester

Följande anslutningstester körs automatiskt:

Test Description
Anslutning för lastbalanserare Verifierar anslutningen till den interna lastbalanseraren.
Intern DNS-namnmatchning Verifierar att interna DNS-namn matchar korrekt.
Tillgänglighet för Azure-infrastrukturberoenden Kontrollerar tillgängligheten för Azure infrastrukturberoenden.
Slutpunkt-till-slutpunkt-anslutning inom undernätet till instansen Verifierar hela anslutningsvägen till Azure SQL Managed Instance genom att försöka logga in med en inloggningsuppgift som är känd för att misslyckas (AzureSQLConnectivityChecker).

Se misslyckade inloggningar orsakade av end-to-end-tester

Anslutningstestet från slutpunkt till slutpunkt utför avsiktligt en misslyckad inloggning för att verifiera den fullständiga anslutningsvägen. Testet använder inloggningenAzureSQLConnectivityChecker, som inte finns, och förväntar sig att Azure SQL Managed Instance returnerar fel 18456. Det här felet bekräftar att hela nätverkssökvägen fram till SQL Managed Instance fungerar.

SQL-observabilitetsverktyg kan identifiera dessa misslyckade inloggningar. Använd följande signaturer för att identifiera anslutningstestposter och skilja dem från misslyckade inloggningsförsök.

Följande observerbarhetsverktyg identifierar misslyckade inloggningar:

Granskningsloggar

När du aktiverar FAILED_LOGIN_GROUPvisas granskningshändelser ungefär var 10:e sekund i AzureDiagnostics:

Column Value
Category SQLSecurityAuditEvents
ResourceType MANAGEDINSTANCES
action_id_s LGIF
server_principal_name_s AzureSQLConnectivityChecker
client_ip_s IP-adress inom undernätsintervallet

Utökade händelser

Extended Event-sessioner som fångar sqlserver.error_reported där error_number = 18456 och severity = 14 visar följande attribut:

Attribute Value
category LOGON
error_number 18456
severity 14
state Variabel (beror på autentiseringskonfiguration)
message Variabel (beror på autentiseringskonfiguration)
sqlazure.is_azure_connection True

Om till exempel SQL-autentisering är inaktiverad på den SQL-hanterade instansen är tillståndet 170 och meddelandet anger att autentisering enbart med Microsoft Entra är aktiverad.

SQL-felloggar

I sp_readerrorlogvisas misslyckade inloggningar från anslutningstestet som par rader:

Column Value
ProcessInfo Logon
Text Error: 18456, Severity: 14, State: (variabel) .

och

Column Value
ProcessInfo Logon
Text Meddelandet beror på autentiseringskonfigurationen

När SQL-autentisering till exempel är inaktiverat anges det i meddelandet att Microsoft Entra-endast autentisering är aktiverat och innehåller en IP-adress för undernätet.

Relaterat innehåll

  • Uppdaterades senast