Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Dotyczy:
Azure SQL Managed Instance
W tym artykule opisano automatyczne wewnętrzne testy łączności, które są uruchamiane na Azure SQL Managed Instance w celu monitorowania niezawodności usługi i przyspieszania wykrywania problemów.
Te testy są w pełni zautomatyzowane i nie wymagają żadnej akcji od Ciebie. Aktywne monitorowanie połączeń sieci wewnętrznej umożliwia Microsoft szybkie identyfikowanie potencjalnych problemów i utrzymywanie stabilnej kompleksowej łączności.
Testy łączności są uruchamiane z dwóch wewnętrznych adresów IP z zakresu podsieci, w której znajduje się zarządzane wystąpienie SQL. Testy nie wymagają żadnej zewnętrznej łączności przychodzącej ani wychodzącej. Dodatkowe adresy IP są zarezerwowane do testów łączności, a ślady mogą pojawić się w dziennikach obserwowalności.
Począwszy od maja 2026 r., testy łączności są uruchamiane w regularnych odstępach czasu we wszystkich wystąpieniach zarządzanych SQL.
Benefits
Automatyczne testy łączności wewnętrznej zapewniają następujące korzyści:
- Diagnozowanie problemów z wewnętrzną usługą i dostępnością sieci.
- Przyspieszanie odnajdywania problemów i skrócenie czasu ograniczania ryzyka.
- Zwiększ widoczność wewnętrznego stanu sieci SQL Managed Instance.
Wyniki testów są używane wewnętrznie i nie odzwierciedlają ich w usłudze Service Health ani Resource Health.
Wpływ operacyjny
Wewnętrzne testy łączności mają następujący wpływ operacyjny:
- Dla każdej grupy maszyn wirtualnych aprowizowane są dwa dodatkowe adresy IP, zwiększając wymagania dotyczące adresów IP z sześciu do ośmiu. Aby uzyskać więcej informacji, zobacz Określanie rozmiaru i zakresu podsieci.
- Testy są uruchamiane co 10 sekund i mają niewielki wpływ na wydajność sieci i wydajność usługi.
- Nowe podsieci utworzone dla wystąpień zarządzanych SQL automatycznie rezerwują dodatkowe adresy IP wymagane do testów łączności.
- W istniejących podsieciach z wystąpieniami zarządzanymi SQL testy rezerwują dodatkowe adresy IP tylko wtedy, gdy podsieć ma wystarczająco dużo wolnych adresów IP, aby obsługiwać dodatkowe adresy IP wymagane przez testy. Jeśli istniejąca podsieć nie ma wystarczającej liczby wolnych adresów IP, testy nie są uruchamiane.
Zagadnienia dotyczące zabezpieczeń
Następujące zasady zabezpieczeń zawierają wskazówki dotyczące projektowania wewnętrznych testów łączności:
- Testy obejmują pojedynczą zarządzaną instancję SQL i są uruchamiane w delegowanej sieci wirtualnej i podsieci.
- Testy łączności nie mogą uzyskać dostępu do zawartości żadnej bazy danych.
- Wyniki testów nie zawierają danych klienta poza nazwą wystąpienia.
- Tylko Microsoft inżynierowie mogą uzyskiwać dostęp do wyników.
- Systemy inspekcji mogą rejestrować nieudane próby logowania wygenerowane przez testy. Aby uzyskać więcej informacji o tym, jak rozpoznać te wpisy, zobacz Monitorowanie nieudanych prób logowania spowodowanych przez testy end-to-end.
Testy wykonane
Następujące testy łączności są uruchamiane automatycznie:
| Testowanie | Description |
|---|---|
| Łączność modułu równoważenia obciążenia | Weryfikuje łączność z wewnętrznym modułem równoważenia obciążenia. |
| Wewnętrzne rozpoznawanie nazw DNS | Sprawdza, czy wewnętrzne nazwy DNS są prawidłowo rozpoznawane. |
| dostępność zależności infrastruktury Azure | Sprawdza dostępność zależności infrastruktury Azure. |
| Pełna łączność w obrębie podsieci z instancją | Weryfikuje całą ścieżkę połączenia z usługą Azure SQL Managed Instance, podejmując próbę zalogowania przy użyciu poświadczeń, o których wiadomo, że spowodują niepowodzenie (AzureSQLConnectivityChecker). |
Obserwuj nieudane logowania spowodowane przez testy end-to-end
Test łączności kompleksowej celowo wykonuje nieudane logowanie w celu zweryfikowania pełnej ścieżki łączności. Test używa loginu AzureSQLConnectivityChecker, który nie istnieje, i oczekuje, że Azure SQL Managed Instance zwróci błąd 18456. Ten błąd sprawdza, czy cała ścieżka sieciowa do SQL Managed Instance jest funkcjonalna.
Narzędzia do obserwacji SQL mogą wykrywać te nieudane logowania. Użyj następujących podpisów, aby zidentyfikować wpisy testu łączności i odróżnić je od rzeczywistych nieudanych prób logowania.
Następujące narzędzia do obserwacji wykryły nieudane logowania:
Dzienniki inspekcji
Po włączeniu FAILED_LOGIN_GROUP zdarzenia audytu pojawiają się mniej więcej co 10 sekund w AzureDiagnostics:
| Column | Value |
|---|---|
Category |
SQLSecurityAuditEvents |
ResourceType |
MANAGEDINSTANCES |
action_id_s |
LGIF |
server_principal_name_s |
AzureSQLConnectivityChecker |
client_ip_s |
Adres IP w zakresie podsieci |
Zdarzenia rozszerzone
Sesje zdarzeń rozszerzonych, które przechwytują sqlserver.error_reported, w których error_number = 18456 i severity = 14 wyświetlają następujące atrybuty:
| Atrybut | Value |
|---|---|
category |
LOGON |
error_number |
18456 |
severity |
14 |
state |
Zmienna (zależy od konfiguracji uwierzytelniania) |
message |
Zmienna (zależy od konfiguracji uwierzytelniania) |
sqlazure.is_azure_connection |
True |
Jeśli na przykład uwierzytelnianie SQL jest wyłączone w wystąpieniu zarządzanym SQL, stan to 170 , a komunikat wskazuje, że jest włączone uwierzytelnianie tylko Microsoft Entra.
Dzienniki błędów SQL
W sp_readerrorlog nieudane próby logowania z testu łączności pojawiają się jako pary wierszy:
| Column | Value |
|---|---|
ProcessInfo |
Logon |
Text |
Error: 18456, Severity: 14, State: (zmienna) . |
oraz
| Column | Value |
|---|---|
ProcessInfo |
Logon |
Text |
Komunikat zależy od konfiguracji uwierzytelniania |
Na przykład po wyłączeniu uwierzytelniania SQL komunikat informuje, że jest włączone uwierzytelnianie tylko Microsoft Entra i zawiera adres IP podsieci.