Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Van toepassing op:
Azure SQL Managed Instance
In dit artikel worden de automatische interne connectiviteitstests beschreven die worden uitgevoerd op Azure SQL Managed Instance om de betrouwbaarheid van de service te bewaken en de detectie van problemen te versnellen.
Deze tests zijn volledig geautomatiseerd en vereisen geen actie van u. Proactieve bewaking van interne netwerkverbindingen stelt Microsoft in staat om snel potentiële problemen te identificeren en stabiele end-to-end-connectiviteit te onderhouden.
Connectiviteitstests worden uitgevoerd vanaf een paar interne IP-adressen uit het subnetbereik dat als host fungeert voor het beheerde SQL-exemplaar. Voor tests is geen externe inkomende of uitgaande connectiviteit vereist. Aanvullende IP-adressen zijn gereserveerd voor connectiviteitstests en traceringen kunnen worden weergegeven in waarneembaarheidslogboeken.
Vanaf mei 2026 worden connectiviteitstests regelmatig uitgevoerd op alle met SQL beheerde exemplaren.
Benefits
Automatische interne connectiviteitstests bieden de volgende voordelen:
- Interne service- en netwerk beschikbaarheidsproblemen vaststellen.
- Versnel het ontdekken van problemen en verkort de tijd om ze te verhelpen.
- Verbeter de zichtbaarheid van de interne netwerkstatus van SQL Managed Instance.
Testresultaten worden intern gebruikt en worden niet weergegeven in Service Health of Resource Health.
Operationele gevolgen
Interne connectiviteitstests hebben de volgende operationele impact:
- Er worden twee extra IP-adressen ingericht voor elke VM-groep, waardoor de IP-adresvereiste van zes tot acht wordt verhoogd. Zie Grootte en bereik van subnet bepalen voor meer informatie.
- Tests worden elke 10 seconden uitgevoerd en hebben een te verwaarlozen invloed op de prestaties van de netwerkdoorvoer en service.
- Nieuwe subnetten die zijn gemaakt voor met SQL beheerde exemplaren, reserveren automatisch de extra IP-adressen die zijn vereist voor connectiviteitstests.
- In bestaande subnetten met beheerde SQL-exemplaren reserveren de tests alleen extra IP-adressen als het subnet voldoende vrije IP-adressen heeft ter ondersteuning van de extra IP-adressen die vereist zijn voor de tests. Als een bestaand subnet niet voldoende gratis IP-adressen heeft, worden de tests niet uitgevoerd.
Beveiligingsoverwegingen
De volgende beveiligingsprincipes begeleiden het ontwerp van interne connectiviteitstests:
- Tests zijn gericht op één met SQL beheerd exemplaar en worden uitgevoerd binnen het gedelegeerde virtuele netwerk en subnet.
- Connectiviteitstests hebben geen toegang tot de inhoud van een database.
- Testresultaten bevatten geen klantgegevens buiten de naam van het exemplaar.
- Alleen Microsoft technici hebben toegang tot de resultaten.
- Controlesystemen kunnen mislukte aanmeldingspogingen registreren die zijn gegenereerd door de tests. Zie Mislukte aanmeldingen door end-to-endtests herkennen voor meer informatie over hoe u deze items kunt identificeren.
Tests uitgevoerd
De volgende connectiviteitstests worden automatisch uitgevoerd:
| Test | Description |
|---|---|
| Connectiviteit van load balancer | Valideert de connectiviteit met de interne load balancer. |
| Interne DNS-naamomzetting | Controleert of interne DNS-namen correct worden opgelost. |
| Beschikbaarheid van Azure-infrastructuurafhankelijkheden | Controleert de beschikbaarheid van Azure infrastructuurafhankelijkheden. |
| End-to-end-connectiviteit binnen het subnet naar de instantie | Valideert het volledige verbindingstraject naar Azure SQL Managed Instance door te proberen zich aan te melden met bewust onjuiste aanmeldgegevens (AzureSQLConnectivityChecker). |
Bekijk mislukte inlogpogingen veroorzaakt door end-to-end tests
De end-to-end-connectiviteitstest voert opzettelijk een mislukte aanmelding uit om het volledige connectiviteitspad te valideren. De test maakt gebruik van de AzureSQLConnectivityChecker aanmelding, die niet bestaat en verwacht dat Azure SQL Managed Instance fout 18456 retourneert. Deze fout valideert dat het hele netwerkpad naar SQL Managed Instance functioneel is.
Sql-waarneembaarheidshulpprogramma's kunnen deze mislukte aanmeldingen detecteren. Gebruik de volgende handtekeningen om vermeldingen voor connectiviteitstests te identificeren en deze te onderscheiden van legitieme mislukte aanmeldingspogingen.
De volgende waarneembaarheidshulpprogramma's detecteren mislukte aanmeldingen:
Controlelogboeken
Wanneer u inschakelt FAILED_LOGIN_GROUP, worden auditgebeurtenissen ongeveer om de 10 seconden weergegeven in AzureDiagnostics:
| Kolom | Value |
|---|---|
Category |
SQLSecurityAuditEvents |
ResourceType |
MANAGEDINSTANCES |
action_id_s |
LGIF |
server_principal_name_s |
AzureSQLConnectivityChecker |
client_ip_s |
IP-adres binnen het subnetbereik |
Uitgebreide gebeurtenissen
Extended Events-sessies waarin sqlserver.error_reported wordt vastgelegd, waarbij error_number = 18456 en severity = 14 de volgende kenmerken tonen:
| Attribute | Value |
|---|---|
category |
LOGON |
error_number |
18456 |
severity |
14 |
state |
Variabele (afhankelijk van verificatieconfiguratie) |
message |
Variabele (afhankelijk van verificatieconfiguratie) |
sqlazure.is_azure_connection |
True |
Als SQL-verificatie bijvoorbeeld is uitgeschakeld op het beheerde SQL-exemplaar, is 170 de status en geeft het bericht aan dat Microsoft Entra-only-verificatie is ingeschakeld.
SQL-foutenlogboeken
In sp_readerrorlog, mislukte aanmeldingen van de connectiviteitstest worden weergegeven als paren van rijen:
| Kolom | Value |
|---|---|
ProcessInfo |
Logon |
Text |
Error: 18456, Severity: 14, State: (variabele) . |
en
| Kolom | Value |
|---|---|
ProcessInfo |
Logon |
Text |
Bericht is afhankelijk van de verificatieconfiguratie |
Wanneer SQL-verificatie bijvoorbeeld is uitgeschakeld, wordt in het bericht aangegeven dat Microsoft Entra alleen-verificatie is ingeschakeld en een subnet-IP-adres bevat.