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

Dotyczy:Azure SQL Managed Instance

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

Omówienie

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

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

Architektura łączności wysokiego poziomu

Wystąpienie zarządzane SQL składa się ze składników usługi hostowanych w dedykowanym zestawie izolowanych maszyn wirtualnych, które są zgrupowane razem przez podobne atrybuty konfiguracji i 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.

Aplikacje klienckie mogą łączyć się z usługą SQL Managed Instance i wysyłać zapytania do baz danych 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 usługą 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 łączące się z usługą SQL Managed Instance jako źródła danych.

Sql Managed Instance to pojedyncza dzierżawa, platforma jako usługa, która działa w 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, Microsoft Entra ID (dawniej Azure Active Directory) na potrzeby uwierzytelniania i usług zbierania danych telemetrycznych. Zobaczysz ruch pochodzący z podsieci zawierających usługę SQL Managed Instance przechodzący do tych usług.

Płaszczyzna sterowania obsługuje funkcje wdrażania, zarządzania i konserwacji podstawowej usługi za pośrednictwem zautomatyzowanych agentów. Ci agenci mają wyłączny dostęp do zasobów obliczeniowych, które obsługują usługę. Nie można uzyskać dostępu do tych hostów za pomocą ssh protokołu Remote Desktop Protocol 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, usługa SQL Managed Instance stale weryfikuje te certyfikaty przy użyciu list odwołania certyfikatów.

Omówienie komunikacji

Aplikacje mogą łączyć się z usługą SQL Managed Instance za pośrednictwem trzech typów punktów końcowych: lokalnego punktu końcowego sieci wirtualnej, publicznego punktu końcowegoi prywatnych punktów końcowych. Te punkty końcowe wykazują odrębne właściwości i zachowania odpowiednie dla różnych scenariuszy.

Lokalny punkt końcowy sieci wirtualnej

Lokalny punkt końcowy sieci wirtualnej jest domyślnym sposobem nawiązywania połączenia z usługą SQL Managed Instance. Jest to nazwa domeny w postaci <mi_name>.<dns_zone>.database.windows.net. Nazwa domeny odpowiada adresowi IP z zakresu adresów podsieci. Lokalny punkt końcowy sieci wirtualnej może służyć do nawiązywania połączenia z wystąpieniem zarządzanym SQL we wszystkich standardowych scenariuszach łączności. Port lokalnego punktu końcowego sieci wirtualnej to 1433.

Lokalny punkt końcowy sieci wirtualnej obsługuje typy połączeń serwera proxy i przekierowania.

Podczas nawiązywania połączenia z lokalnym punktem końcowym sieci wirtualnej należy zawsze używać nazwy domeny i zezwalać na ruch przychodzący na wymaganych portach w całym zakresie podsieci, ponieważ podstawowy adres IP może się czasami zmieniać.

Publiczny punkt końcowy

Publiczny punkt końcowy to nazwa domeny w postaci <mi_name>.public.<dns_zone>.database.windows.net. Ta nazwa domeny rozwija się do publicznego adresu IP dostępnego z Internetu. Publiczny punkt końcowy jest odpowiedni w sytuacjach, gdy zarządzana instancja musi być dostępna przez publiczny Internet, na przykład przy łączeniu się z nią z innej sieci wirtualnej, gdy peering lub prywatne punkty końcowe są niedostępne. Publiczne punkty końcowe obsługują tylko ruch klienta i nie mogą być używane do replikacji danych między dwoma wystąpieniami, takimi jak grupy awaryjnego przełączania lub łącze wystąpienia zarządzanego. Port publicznego punktu końcowego to 3342.

Publiczny punkt końcowy zawsze używa typu połączenia serwera proxy niezależnie od ustawienia typu połączenia.

Podczas nawiązywania połączenia z publicznym punktem końcowym zawsze używaj nazwy domeny i zezwalaj na ruch przychodzący na porcie 3342 w całym zakresie podsieci, ponieważ podstawowy adres IP może czasami ulec zmianie.

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

Prywatne punkty końcowe

Prywatny punkt końcowy to opcjonalny stały adres IP w innej sieci wirtualnej, który prowadzi ruch do wystąpienia zarządzanego SQL. Jedna usługa Azure SQL Managed Instance może mieć wiele prywatnych punktów końcowych w wielu sieciach wirtualnych. Prywatne punkty końcowe obsługują tylko ruch klienta i nie mogą być używane do replikacji danych między dwoma wystąpieniami, takimi jak grupy przełączania awaryjnego lub połączenie zarządzanego wystąpienia. Port prywatnego punktu końcowego to 1143.

Prywatne punkty końcowe zawsze używają typu połączenia serwera proxy niezależnie od ustawienia typu połączenia.

Podczas nawiązywania połączenia z prywatnym punktem końcowym zawsze używaj nazwy domeny, ponieważ nawiązywanie połączenia z usługą Azure SQL Managed Instance za pośrednictwem adresu IP nie jest jeszcze obsługiwane. Jednak adres IP prywatnego punktu końcowego nie zmienia się.

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

Architektura łączności klastra wirtualnego

Na poniższym diagramie przedstawiono koncepcyjny układ architektury 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 rozpoznawalna, jego adres IP należy do zakresu adresów podsieci i może być domyślnie osiągany tylko z wewnątrz sieci wirtualnej.

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

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

Wymagania dotyczące sieci

Usługa Azure SQL Managed Instance wymaga skonfigurowania aspektów delegowanej podsieci w określony sposób, co można osiągnąć przy użyciu konfiguracji podsieci wspomaganej przez usługę. Poza tym, czego wymaga usługa, użytkownicy mają pełną kontrolę nad konfiguracją sieci podsieci, takimi jak:

• Zezwalanie lub blokowanie ruchu na niektórych lub wszystkich portach
• Dodawanie wpisów do tabeli tras w celu kierowania ruchu przez wirtualne urządzenia sieciowe lub bramę
• Konfigurowanie niestandardowej rozpoznawania nazw DNS lub
• Konfigurowanie komunikacji równorzędnej lub sieci VPN

Aby spełnić kryteria "Zgodna konfiguracja sieci" w umowie dotyczącej poziomu usług dla usług online firmy Microsoft, sieć wirtualna i podsieć, w której wdrożono usługę SQL Managed Instance, muszą spełniać następujące wymagania:

• Dedykowana podsieć: Podsieć używana przez usługę SQL Managed Instance może być delegowana tylko do usługi SQL Managed Instance. Podsieć nie może być podsiecią bramy i można wdrożyć tylko zasoby usługi SQL Managed Instance w podsieci.
• Delegowanie podsieci: podsieć usługi SQL Managed Instance musi być delegowana do dostawcy Microsoft.Sql/managedInstances zasobów.
• Sieciowa grupa zabezpieczeń: sieciowa grupa zabezpieczeń musi być skojarzona z podsiecią usługi SQL Managed Instance. Sieciowa grupa zabezpieczeń umożliwia kontrolowanie dostępu do punktu końcowego danych usługi SQL Managed Instance przez filtrowanie ruchu na porcie 1433 i portach 11000–11999, gdy usługa SQL Managed Instance jest skonfigurowana 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ą usługi SQL Managed Instance. Możesz dodać wpisy do tej tabeli tras, na przykład w celu kierowania ruchu do lokalizacji za pośrednictwem bramy sieci wirtualnej lub dodać domyślną trasę 0.0.0.0.0/0 kierującą cały ruch przez wirtualne urządzenie sieciowe, takie jak zapora. Usługa Azure SQL Managed Instance automatycznie aprowizuje wymagane wpisy w tabeli tras i zarządza nimi.
• Wystarczające adresy IP: podsieć usługi SQL Managed Instance musi mieć co najmniej 32 adresy IP. Aby uzyskać więcej informacji, zobacz Określanie rozmiaru podsieci dla usługi 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 usługi SQL Managed Instance. W innym przypadku utwórz nową sieć i podsieć.
• Dozwolone przez zasady platformy Azure: jeśli używasz usługi Azure Policy do zapobiegania tworzeniu lub modyfikowaniu zasobów w zakresie obejmującym podsieć lub sieć wirtualną usługi SQL Managed Instance, zasady nie mogą uniemożliwić usłudze SQL Managed Instance zarządzania zasobami wewnętrznymi. Następujące zasoby należy wykluczyć 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 w sieci wirtualnej dedykowanej podsieci, nadrzędnej grupy zasobów lub subskrypcji mogą czasami zakłócać zarządzanie usługą SQL Managed Instance i operacje konserwacji. Podczas korzystania z blokad zasobów należy zachować szczególną ostrożność.
• Publiczne rekordy DNS możliwe do rozwiązania: Jeśli sieć wirtualna jest skonfigurowana do używania niestandardowego serwera DNS, serwer DNS musi móc rozpoznawać publiczne rekordy DNS. Korzystanie z funkcji, takich jak uwierzytelnianie firmy Microsoft Entra, może wymagać rozpoznawania w pełni kwalifikowanych nazw domen (FQDN). Aby uzyskać więcej informacji, zobacz Rozpoznawanie prywatnych nazw DNS w usłudze Azure SQL Managed Instance.
• wymagane rekordy DNS: wystąpienia zarządzane zależą od poprawnego rozpoznawania określonych nazw domen. Te nazwy domen nie mogą być zastępowane w sieciach wirtualnych za pośrednictwem stref prywatnych usługi Azure DNS lub niestandardowego serwera DNS. W przeciwnym razie wdrożenia wystąpień zarządzanych nie powiedzie się lub mogą stać się niedostępne. Następujące domeny nie mogą zostać zastąpione: 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.neti vault.azure.net. Należy jednak pamiętać, że nadal można tworzyć prywatne punkty końcowe wewnątrz sieci wirtualnej wystąpienia zarządzanego, nawet do zasobów w powyższych domenach. Prywatne punkty końcowe wykorzystują mechanizm DNS, który nie wymaga, aby lokalny serwer DNS stał się autorytatywny dla całej strefy.
• Tag AzurePlatformDNS: użycie tagu usługi AzurePlatformDNS do blokowania rozpoznawania nazw DNS platformy może spowodować, że usługa SQL Managed Instance będzie niedostępna. Mimo że usługa SQL Managed Instance obsługuje system DNS zdefiniowany przez klienta do rozwiązywania nazw DNS wewnątrz mechanizmu, jest zależna od usługi Azure DNS na potrzeby operacji platformy.

Konfiguracja podsieci wspomagana przez usługę

Aby zwiększyć bezpieczeństwo usług, możliwości zarządzania i dostępności, usługa SQL Managed Instance używa zasad konfiguracji podsieci wspomaganej przez usługę i intencji sieci w infrastrukturze sieci wirtualnej platformy Azure w celu skonfigurowania sieci, skojarzonych składników i tabeli tras w celu zapewnienia spełnienia minimalnych wymagań dotyczących usługi SQL Managed Instance.

Automatycznie skonfigurowane reguły zabezpieczeń sieci i tabeli tras są widoczne dla klienta i oznaczone adnotacjami z jednym z następujących prefiksów:

• Microsoft.Sql-managedInstances_UseOnly_mi- dla obowiązkowych reguł i tras
• Microsoft.Sql-managedInstances_UseOnly_mi-optional- dla opcjonalnych reguł i tras

Aby uzyskać dodatkowe informacje, zapoznaj się z konfiguracją podsieci wspomaganej przez usługę.

Aby uzyskać więcej informacji na temat architektury łączności i ruchu zarządzania, zobacz Architektura łączności wysokiego poziomu.

Ograniczenia sieci

Obowiązują następujące ograniczenia dotyczące funkcji sieci wirtualnej i ruchu:

• Podsieci prywatne: Wdrażanie wystąpień zarządzanych w podsieciach prywatnych (gdzie domyślny dostęp wychodzący jest wyłączony) nie jest obecnie obsługiwane.
• Poczta bazy danych do zewnętrznych przekaźników SMTP na porcie 25: Wysyłanie poczty bazy danych za pośrednictwem portu 25 do zewnętrznych usług poczty e-mail jest dostępne tylko dla niektórych typów subskrypcji na platformie Microsoft Azure. Wystąpienia innych typów subskrypcji powinny używać innego portu (na przykład 587) do kontaktowania się z zewnętrznymi przekaźnikami SMTP. W przeciwnym razie wystąpienia mogą nie dostarczyć poczty bazy danych. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z łącznością wychodzącą SMTP na platformie Azure.
• 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 znajduje się wystąpienie zarządzane SQL, wpływa na przepływ ruchu między składnikami usługi SQL Managed Instance wewnątrz sieci wirtualnej i usług, od których zależy. Wynik problemów z dostępnością. Wdrożenia usługi SQL Managed Instance 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: komunikacja równorzędna sieci wirtualnych łączności między regionami platformy Azure nie działa w przypadku wystąpień wystąpienia zarządzanego SQL, które zostały umieszczone w podsieciach utworzonych przed 9 września 2020 r.
• Komunikacja równorzędna sieci wirtualnych — konfiguracja: podczas ustanawiania komunikacji równorzędnej sieci wirtualnych między sieciami wirtualnymi, które zawierają podsieci z wystąpieniami zarządzanymi SQL, takie podsieci muszą używać różnych tabel tras i sieciowych grup zabezpieczeń. Ponowne użycie tabeli tras i sieciowej grupy zabezpieczeń w co najmniej dwóch podsieciach uczestniczących w komunikacji równorzędnej sieci wirtualnej spowoduje problemy z łącznością we wszystkich podsieciach przy użyciu tych tabel tras lub sieciowej grupy zabezpieczeń i spowodować niepowodzenie operacji zarządzania usługi SQL Managed Instance.
• Brama translatora adresów sieciowych: używanie translatora adresów sieciowych platformy Azure do kontrolowania łączności wychodzącej z określonym publicznym adresem IP powoduje, że usługa SQL Managed Instance jest niedostępna. 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 usługi Azure Virtual Network.
• Protokół IPv6 dla usługi Azure Virtual Network: wdrażanie wystąpienia zarządzanego SQL w dwóch sieciach wirtualnych IPv4/IPv6 powinno zakończyć się niepowodzeniem. Kojarzenie sieciowej grupy zabezpieczeń lub tabeli tras z trasami zdefiniowanymi przez użytkownika (UDR), które zawiera prefiksy adresów IPv6 do podsieci usługi SQL Managed Instance, renderuje wystąpienie zarządzane SQL 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, powoduje, że wystąpienie zarządzane SQL jest niedostępne. Wdrożenia usługi SQL Managed Instance w podsieci z sieciową grupą zabezpieczeń i trasa zdefiniowana przez użytkownika, które mają już prefiksy IPv6, powinny zakończyć się niepowodzeniem.
• Protokół TLS 1.2 jest wymuszany na połączeniach 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 usługi SQL Managed Instance spowodowało to wymuszanie protokołu TLS 1.2 na połączeniach wychodzących używanych do replikacji i połączeniach serwera połączonego z programem SQL Server. Jeśli używasz wersji programu SQL Server starszej niż 2016 z usługą SQL Managed Instance, upewnij się, że zastosowano aktualizacje specyficzne dla protokołu TLS 1.2.
• wewnętrzny powrót do usługi Azure DNS: wystąpienia zarządzane zależą od działającego rozpoznawania nazw DNS w sieciach wirtualnych. Jeśli sieć wirtualna wystąpienia zarządzanego jest skonfigurowana do używania niestandardowych serwerów DNS, a żądanie DNS skierowane do niestandardowych serwerów DNS nie powiedzie się w określonym przedziale czasowym (1–2 sekundy), to wystąpienie zarządzane ponowi żądanie względem usługi Azure DNS w tej sieci wirtualnej.

Powiązana zawartość

• Aby zapoznać się z omówieniem, zobacz Co to jest usługa Azure SQL Managed Instance?.
• Aby dowiedzieć się więcej, zobacz
  • Architektura klastra wirtualnego
  • Konfiguracja podsieci wspomaganej przez usługę
  • Skonfiguruj nową sieć wirtualną platformy Azure lub istniejącą sieć wirtualną platformy Azure, w której można wdrożyć usługę SQL Managed Instance.
  • Oblicz rozmiar podsieci , w której chcesz wdrożyć wystąpienie zarządzane SQL.
• Dowiedz się, jak utworzyć wystąpienie zarządzane:
  • W witrynie Azure Portal.
  • Za pomocą programu PowerShell.
  • Za pomocą szablonu usługi Azure Resource Manager.
  • Za pomocą szablonu usługi Azure Resource Manager z serwerem przesiadkowym i programem SQL Server Management Studio.