Architektura łączności dla usługi Azure SQL Managed Instance

  • Artykuł
  • Czas czytania: 16 min

Dotyczy: Azure SQL Managed Instance

W tym artykule opisano architekturę łączności w Azure SQL Managed Instance oraz sposób, w jaki składniki kierują ruch komunikacyjny dla wystąpienia zarządzanego.

Omówienie

W SQL Managed Instance wystąpienie jest umieszczane w sieci wirtualnej platformy Azure i wewnątrz podsieci dedykowanej dla wystąpień zarządzanych. Wdrożenie zapewnia:

  • Bezpieczny adres IP sieci wirtualnej (VNet-local).
  • Możliwość połączenia sieci lokalnej z SQL Managed Instance.
  • Możliwość łączenia SQL Managed Instance z serwerem połączonym lub innym lokalnym magazynem danych.
  • Możliwość łączenia SQL Managed Instance z zasobami platformy Azure.

Uwaga

Fala funkcji z listopada 2022 r. wprowadziła zmiany w domyślnej strukturze łączności SQL Managed Instance. Ten artykuł zawiera informacje o bieżącej architekturze i architekturze wystąpień, które nie zostały jeszcze zarejestrowane w fali funkcji. Aby uzyskać więcej informacji, zobacz fala funkcji z listopada 2022 r.

Fala funkcji z listopada 2022 r.

Fala funkcji z listopada 2022 r. wprowadziła następujące zmiany w architekturze łączności SQL Managed Instance:

  • Usunięto punkt końcowy zarządzania.
  • Uproszczone obowiązkowe reguły sieciowej grupy zabezpieczeń (usunięto jedną obowiązkową regułę).
  • Poprawiono obowiązkowe reguły sieciowej grupy zabezpieczeń, aby nie uwzględniały już ruchu wychodzącego do usługi AzureCloud na porcie 443.
  • Uproszczono tabelę tras (zmniejszono liczbę obowiązkowych tras z 13 do 5).

Architektura łączności wysokiego poziomu

Na wysokim poziomie SQL Managed Instance składa się ze składników usługi hostowanych w dedykowanym zestawie izolowanych maszyn wirtualnych, które są przyłączone do klastra wirtualnego. Niektóre składniki usługi są wdrażane wewnątrz podsieci sieci wirtualnej klienta, podczas gdy inne usługi działają w bezpiecznym środowisku sieciowym zarządzanym przez firmę Microsoft.

Diagram przedstawiający architekturę łączności wysokiego poziomu dla Azure SQL Managed Instance po listopadzie 2022 r.

Klaster wirtualny może hostować wiele wystąpień zarządzanych. Klaster automatycznie rozszerza lub kontrakty zgodnie z potrzebami w celu uwzględnienia nowych i usuniętych wystąpień.

Aplikacje klienta mogą łączyć się z SQL Managed Instance i mogą wykonywać zapytania o bazy danych i aktualizować je w sieci wirtualnej, równorzędnej sieci wirtualnej lub sieci połączonej za pomocą sieci VPN lub usługi Azure ExpressRoute.

Na poniższym diagramie przedstawiono jednostki łączące się z SQL Managed Instance. Przedstawia również zasoby, które muszą komunikować się z wystąpieniem zarządzanym. Proces komunikacji w dolnej części diagramu reprezentuje aplikacje i narzędzia klienta, które łączą się z SQL Managed Instance jako źródła danych.

Diagram przedstawiający jednostki w architekturze łączności dla Azure SQL Managed Instance po listopadzie 2022 r.

SQL Managed Instance to jednodostępna platforma jako usługa, która działa na dwóch płaszczyznach: płaszczyznę danych i płaszczyznę sterowania.

Płaszczyzna danych jest wdrażana w podsieci klienta w celu zapewnienia zgodności, łączności i izolacji sieciowej. Płaszczyzna danych zależy od usług platformy Azure, takich jak Azure Storage, Azure Active Directory (Azure AD) na potrzeby uwierzytelniania i usług zbierania danych telemetrycznych. Zobaczysz ruch pochodzący z podsieci zawierających SQL Managed Instance przechodzący do tych usług.

Płaszczyzna sterowania obsługuje funkcje wdrażania, zarządzania i podstawowej konserwacji usługi za pośrednictwem agentów automatycznych. Ci agenci mają wyłączny dostęp do zasobów obliczeniowych, które obsługują usługę. Do uzyskiwania dostępu do tych hostów nie można użyć ssh ani protokołu Remote Desktop Protocol. Cała komunikacja płaszczyzny sterowania jest szyfrowana i podpisana przy użyciu certyfikatów. Aby sprawdzić wiarygodność komunikujących się stron, SQL Managed Instance stale weryfikuje te certyfikaty przy użyciu list odwołania certyfikatów.

Omówienie komunikacji

Aplikacje mogą łączyć się z SQL Managed Instance za pośrednictwem trzech typów punktów końcowych. Te punkty końcowe obsługują różne scenariusze i wykazują odrębne właściwości i zachowania sieciowe.

Diagram przedstawiający zakres widoczności dla lokalnych, publicznych i prywatnych punktów końcowych sieci wirtualnej do Azure SQL Managed Instance.

Lokalny punkt końcowy sieci wirtualnej

Lokalny punkt końcowy sieci wirtualnej jest domyślnym sposobem nawiązywania połączenia z SQL Managed Instance. Lokalny punkt końcowy sieci wirtualnej jest nazwą domeny w postaci <mi_name>.<dns_zone>.database.windows.net , która jest rozpoznawana jako adres IP z puli adresów podsieci, w związku z tym sieć wirtualna-lokalna lub punkt końcowy lokalny dla sieci wirtualnej. Lokalny punkt końcowy sieci wirtualnej może służyć do nawiązywania połączenia z SQL Managed Instance we wszystkich standardowych scenariuszach łączności.

Lokalne punkty końcowe sieci wirtualnej obsługują typ połączenia przekierowania.

Podczas nawiązywania połączenia z lokalnym punktem końcowym sieci wirtualnej zawsze używaj jego nazwy domeny, ponieważ podstawowy adres IP może czasami ulec zmianie.

Publiczny punkt końcowy

Publiczny punkt końcowy jest opcjonalną nazwą domeny w postaci <mi_name>.public.<dns_zone>.database.windows.net , która jest rozpoznawana jako publiczny adres IP dostępny z Internetu. Publiczny punkt końcowy umożliwia dostęp do ruchu TDS tylko do SQL Managed Instance na porcie 3442 i nie może być używany w scenariuszach integracji, takich jak grupy trybu failover, łącze wystąpienia zarządzanego i podobne.

Podczas nawiązywania połączenia z lokalnym punktem końcowym sieci wirtualnej zawsze używaj jego nazwy domeny, ponieważ podstawowy adres IP może czasami ulec zmianie.

Publiczny punkt końcowy zawsze działa w typie połączenia serwera proxy.

Dowiedz się, jak skonfigurować publiczny punkt końcowy w temacie Konfigurowanie publicznego punktu końcowego dla Azure SQL Managed Instance.

Prywatny punkt końcowy (wersja zapoznawcza)

Prywatny punkt końcowy, obecnie w wersji zapoznawczej dla Azure SQL Managed Instance, jest opcjonalnym stałym adresem IP w innej sieci wirtualnej, która prowadzi ruch do wystąpienia zarządzanego SQL. Jeden Azure SQL Managed Instance może mieć wiele prywatnych punktów końcowych w wielu sieciach wirtualnych. Prywatne punkty końcowe umożliwiają dostęp do ruchu TDS tylko do SQL Managed Instance na porcie 1433 i nie mogą być używane w scenariuszach integracji, takich jak grupy trybu failover, link wystąpienia zarządzanego i inne podobne technologie.

Podczas nawiązywania połączenia z prywatnym punktem końcowym zawsze używaj nazwy domeny, ponieważ nawiązywanie połączenia z Azure SQL Managed Instance za pośrednictwem jego adresu IP nie jest obsługiwane.

Prywatne punkty końcowe zawsze działają w typie połączenia serwera proxy.

Dowiedz się więcej o prywatnych punktach końcowych i sposobie ich konfigurowania w Azure Private Link dla Azure SQL Managed Instance.

Architektura łączności klastra wirtualnego

W tej sekcji przedstawiono bliżej architekturę łączności klastra wirtualnego SQL Managed Instance. Na poniższym diagramie przedstawiono koncepcyjny układ klastra wirtualnego:

Nazwa domeny lokalnego punktu końcowego sieci wirtualnej jest rozpoznawana jako prywatny adres IP wewnętrznego modułu równoważenia obciążenia. Mimo że ta nazwa domeny jest zarejestrowana w publicznej strefie systemu nazw domen (DNS) i jest publicznie rozpoznawana, jego adres IP należy do zakresu adresów podsieci i można go uzyskać tylko z wewnątrz sieci wirtualnej domyślnie.

Moduł równoważenia obciążenia kieruje ruch do bramy SQL Managed Instance. Ponieważ wiele wystąpień zarządzanych może działać wewnątrz tego samego klastra, brama używa nazwy hosta SQL Managed Instance, jak pokazano w parametrach połączenia, aby przekierować ruch do właściwej usługi aparatu SQL.

Wartość parametru zone-id jest generowana automatycznie podczas tworzenia klastra. Jeśli nowo utworzony klaster hostuje wystąpienie zarządzane pomocnicze, współudzieli identyfikator strefy z klastrem podstawowym.

Konfiguracja podsieci wspomagana przez usługę

Aby zwiększyć bezpieczeństwo usług, możliwości zarządzania i dostępności, SQL Managed Instance stosuje zasady intencji sieci w niektórych elementach infrastruktury sieci wirtualnej platformy Azure. Zasady konfigurują podsieć, skojarzą sieciową grupę zabezpieczeń i tabelę tras w celu zapewnienia spełnienia minimalnych wymagań dotyczących SQL Managed Instance. Ten mechanizm platformy w sposób niewidoczny komunikuje wymagania dotyczące sieci dla użytkowników. Głównym celem zasad jest zapobieganie błędom konfiguracji sieci oraz zapewnienie normalnego SQL Managed Instance operacji i zobowiązania umowy dotyczącej poziomu usług. Po usunięciu wystąpienia zarządzanego zasady intencji sieci zostaną również usunięte.

Konfiguracja podsieci wspomaganej przez usługę jest oparta na funkcji delegowania podsieci sieci wirtualnej w celu zapewnienia automatycznego zarządzania konfiguracją sieci i włączania punktów końcowych usługi.

Za pomocą punktów końcowych usługi można skonfigurować reguły zapory sieci wirtualnej na kontach magazynu, które przechowują kopie zapasowe i dzienniki inspekcji. Nawet w przypadku włączenia punktów końcowych usługi klienci są zachęcani do korzystania z Azure Private Link w celu uzyskania dostępu do kont magazynu. Private Link zapewnia większą izolację niż punkty końcowe usługi.

Ważne

Ze względu na specyfikę konfiguracji płaszczyzny sterowania konfiguracja podsieci wspomaganej przez usługę nie umożliwia punktów końcowych usługi w chmurach krajowych.

Wymagania dotyczące sieci

Podsieć, w której wdrożono SQL Managed Instance, musi mieć następujące cechy:

  • Dedykowana podsieć: podsieć SQL Managed Instance używać można delegować tylko do usługi SQL Managed Instance. Podsieć nie może być podsiecią bramy i można wdrożyć tylko SQL Managed Instance zasoby w podsieci.
  • Delegowanie podsieci: podsieć SQL Managed Instance musi być delegowana do dostawcy Microsoft.Sql/managedInstances zasobów.
  • Sieciowa grupa zabezpieczeń: sieciowa grupa zabezpieczeń musi być skojarzona z podsiecią SQL Managed Instance. Za pomocą sieciowej grupy zabezpieczeń można kontrolować dostęp do punktu końcowego danych SQL Managed Instance, filtrując ruch na porcie 1433 i portach 11000-11999, gdy SQL Managed Instance jest skonfigurowany pod kątem połączeń przekierowania. Usługa automatycznie aprowizuje reguły i utrzymuje je zgodnie z wymaganiami, aby umożliwić nieprzerwany przepływ ruchu zarządzania.
  • Tabela tras: tabela tras musi być skojarzona z podsiecią SQL Managed Instance. Możesz dodać wpisy do tabeli tras w celu kierowania ruchu, który ma lokalne zakresy prywatnych adresów IP jako miejsce docelowe za pośrednictwem bramy sieci wirtualnej lub wirtualnego urządzenia sieciowego. Usługa automatycznie aprowizuje wpisy i utrzymuje je zgodnie z wymaganiami, aby umożliwić nieprzerwany przepływ ruchu zarządzania.
  • Wystarczające adresy IP: podsieć SQL Managed Instance musi mieć co najmniej 32 adresy IP. Aby uzyskać więcej informacji, zobacz Określanie rozmiaru podsieci dla SQL Managed Instance. Wystąpienia zarządzane można wdrożyć w istniejącej sieci po skonfigurowaniu go w celu spełnienia wymagań sieciowych dla SQL Managed Instance. W innym przypadku utwórz nową sieć i podsieć.
  • Dozwolone przez zasady platformy Azure: jeśli używasz Azure Policy, aby zapobiec tworzeniu lub modyfikowaniu zasobów w zakresie obejmującym podsieć SQL Managed Instance lub sieć wirtualną, zasady nie mogą uniemożliwić SQL Managed Instance zarządzania zasobami wewnętrznymi. Następujące zasoby muszą zostać wykluczone z efektów odmowy zasad dla normalnego działania:
    • Zasoby typu Microsoft.Network/serviceEndpointPolicies, gdy nazwa zasobu zaczyna się od \_e41f87a2\_
    • Wszystkie zasoby typu Microsoft.Network/networkIntentPolicies
    • Wszystkie zasoby typu Microsoft.Network/virtualNetworks/subnets/contextualServiceEndpointPolicies
  • Blokady w sieci wirtualnej: blokady sieci wirtualnej dedykowanej podsieci, nadrzędnej grupy zasobów lub subskrypcji mogą czasami zakłócać SQL Managed Instance operacje zarządzania i konserwacji. Należy zachować szczególną ostrożność podczas używania blokad zasobów.
  • Ruch replikacji: ruch replikacji dla grup automatycznego trybu failover między dwoma wystąpieniami zarządzanymi powinien być bezpośredni i nie jest kierowany przez sieć koncentratora.
  • Niestandardowy serwer DNS: Jeśli sieć wirtualna jest skonfigurowana do używania niestandardowego serwera DNS, serwer DNS musi być w stanie rozpoznać publiczne rekordy DNS. Korzystanie z funkcji takich jak uwierzytelnianie Azure AD może wymagać rozpoznawania bardziej w pełni kwalifikowanych nazw domen (FQDN). Aby uzyskać więcej informacji, zobacz Rozpoznawanie prywatnych nazw DNS w Azure SQL Managed Instance.

Obowiązkowe reguły zabezpieczeń z konfiguracją podsieci wspomaganej przez usługę

Aby zapewnić przepływ ruchu przychodzącego zarządzania ruchem, wymagane są reguły opisane w poniższej tabeli. Reguły są wymuszane przez zasady intencji sieci i nie muszą być wdrażane przez klienta. Aby uzyskać więcej informacji na temat architektury łączności i ruchu zarządzania, zobacz Architektura łączności wysokiego poziomu.

Nazwa Port Protokół Element źródłowy Element docelowy Akcja
healthprobe-in Dowolne Dowolne AzureLoadBalancer podsieć Zezwalaj
wewnętrzne Dowolne Dowolne podsieć podsieć Zezwalaj

Aby zapewnić przepływ ruchu wychodzącego zarządzania ruchem, wymagane są reguły opisane w poniższej tabeli. Aby uzyskać więcej informacji na temat architektury łączności i ruchu zarządzania, zobacz Architektura łączności wysokiego poziomu.

Nazwa Port Protokół Element źródłowy Element docelowy Akcja
AAD-out 443 TCP podsieć AzureActiveDirectory Zezwalaj
OneDsCollector-out 443 TCP podsieć OneDsCollector Zezwalaj
wewnętrzne wyjście Dowolne Dowolne podsieć podsieć Zezwalaj
StorageP-out 443 Dowolne podsieć Magazynu. primaryRegion Zezwalaj
StorageS-out 443 Dowolne podsieć Magazynu. secondaryRegion Zezwalaj

Obowiązkowe trasy z konfiguracją podsieci wspomaganej przez usługę

Trasy opisane w poniższej tabeli są niezbędne do zapewnienia, że ruch zarządzania jest kierowany bezpośrednio do miejsca docelowego. Trasy są wymuszane przez zasady intencji sieci i nie muszą być wdrażane przez klienta. Aby uzyskać więcej informacji na temat architektury łączności i ruchu zarządzania, zobacz Architektura łączności wysokiego poziomu.

Nazwa Prefiks adresu Narzędzie Następny przeskok
AzureActiveDirectory AzureActiveDirectory Internet*
OneDsCollector OneDsCollector Internet*
Magazynu. primaryRegion Magazynu. primaryRegion Internet*
Magazynu. secondaryRegion Magazynu. secondaryRegion Internet*
podsieć-sieć wirtualnalokalna Podsieci Sieć wirtualna

Uwaga

* Wartość internetowa w kolumnie Następny przeskok powoduje, że brama będzie kierować ruch poza sieć wirtualną. Jeśli jednak adres docelowy dotyczy usługi platformy Azure, platforma Azure kieruje ruch bezpośrednio do usługi za pośrednictwem sieci platformy Azure zamiast poza chmurą platformy Azure. Ruch między usługami platformy Azure nie przechodzi przez Internet, niezależnie od regionu świadczenia usługi Azure, w którym istnieje sieć wirtualna, lub w którym regionie platformy Azure jest wdrażane wystąpienie usługi platformy Azure. Aby uzyskać więcej informacji, zobacz Routing ruchu w sieci wirtualnej platformy Azure.

Możesz również dodać wpisy do tabeli tras w celu kierowania ruchu, który ma lokalne zakresy prywatnych adresów IP jako miejsce docelowe za pośrednictwem bramy sieci wirtualnej lub wirtualnego urządzenia sieciowego.

Ograniczenia sieci

Protokół TLS 1.2 jest wymuszany w przypadku połączeń wychodzących: począwszy od stycznia 2020 r. firma Microsoft wymusza protokół TLS 1.2 dla ruchu wewnątrz usługi we wszystkich usługach platformy Azure. W przypadku SQL Managed Instance spowodowało to wymuszenie protokołu TLS 1.2 na połączeniach wychodzących używanych do replikacji i połączeniach serwera połączonego z SQL Server. Jeśli używasz wersji SQL Server starszej niż 2016 z SQL Managed Instance, upewnij się, że zastosowano aktualizacje specyficzne dla protokołu TLS 1.2.

Następujące funkcje sieci wirtualnej nie są obecnie obsługiwane w przypadku SQL Managed Instance:

  • Komunikacja równorzędna firmy Microsoft: włączenie komunikacji równorzędnej firmy Microsoft w obwodach usługi ExpressRoute, które są bezpośrednio lub przechodnio za pomocą sieci wirtualnej, w której SQL Managed Instance znajduje się, wpływa na przepływ ruchu między składnikami SQL Managed Instance wewnątrz sieci wirtualnej i usług, od których zależy. Wynik problemów z dostępnością. SQL Managed Instance wdrożenia w sieci wirtualnej, która ma już włączoną komunikację równorzędną firmy Microsoft, powinny zakończyć się niepowodzeniem.
  • Globalna komunikacja równorzędna sieci wirtualnych: łączność komunikacji równorzędnej sieci wirtualnych między regionami platformy Azure nie działa w przypadku wystąpień SQL Managed Instance, które zostały umieszczone w podsieciach utworzonych przed 9 września 2020 r.
  • AzurePlatformDNS: użycie tagu usługi AzurePlatformDNS do blokowania rozpoznawania nazw DNS platformy spowoduje, że SQL Managed Instance niedostępne. Mimo że SQL Managed Instance obsługuje system DNS zdefiniowany przez klienta na potrzeby rozpoznawania nazw DNS wewnątrz aparatu, istnieje zależność od systemu DNS platformy dla operacji platformy.
  • Brama translatora adresów sieciowych: używanie translatora adresów sieciowych platformy Azure Virtual Network do kontrolowania łączności wychodzącej przy użyciu określonego publicznego adresu IP jest renderowane SQL Managed Instance niedostępne. Usługa SQL Managed Instance jest obecnie ograniczona do korzystania z podstawowego modułu równoważenia obciążenia, który nie zapewnia współistnienia przepływów przychodzących i wychodzących z translatorem adresów sieciowych platformy Azure Virtual Network.
  • Protokół IPv6 dla usługi Azure Virtual Network: Wdrażanie SQL Managed Instance w dwóch sieciach wirtualnych IPv4/IPv6 stosu powinno zakończyć się niepowodzeniem. Kojarzenie sieciowej grupy zabezpieczeń lub tabeli tras z trasami zdefiniowanymi przez użytkownika (UDR), które zawierają prefiksy adresów IPv6 do podsieci SQL Managed Instance renderuje SQL Managed Instance niedostępne. Ponadto dodanie prefiksów adresów IPv6 do sieciowej grupy zabezpieczeń lub trasy zdefiniowanej przez użytkownika, która jest już skojarzona z podsiecią wystąpienia zarządzanego, jest renderowana SQL Managed Instance niedostępna. SQL Managed Instance wdrożenia w podsieci z sieciową grupą zabezpieczeń i trasa zdefiniowana przez użytkownika, które mają już prefiksy IPv6, powinny zakończyć się niepowodzeniem.
  • Strefy prywatne usługi Azure DNS o nazwie zarezerwowanej dla usług firmy Microsoft: Następujące nazwy domen to nazwy zarezerwowane: windows.net, , database.windows.netblob.core.windows.netmanagement.core.windows.netmonitoring.core.windows.netqueue.core.windows.nettable.core.windows.netcore.windows.netlogin.microsoftonline.comlogin.windows.netgraph.windows.netservicebus.windows.net, , i .vault.azure.net Wdrażanie SQL Managed Instance w sieci wirtualnej, która ma skojarzona prywatną strefę usługi Azure DNS, która używa nazwy zarezerwowanej dla usług firmy Microsoft, kończy się niepowodzeniem. Skojarzenie strefy prywatnej usługi Azure DNS korzystającej z nazwy zarezerwowanej z siecią wirtualną zawierającą wystąpienie zarządzane renderuje SQL Managed Instance niedostępne. Aby uzyskać informacje na temat konfiguracji Private Link, zobacz Konfiguracja usługi DNS prywatnego punktu końcowego platformy Azure.

Następne kroki