Архитектура подключения к Управляемому экземпляру SQL Azure

Область применения: Управляемый экземпляр SQL Azure

В этой статье описывается архитектура подключения управляющего экземпляра SQL Azure и то, как компоненты направляют трафик обмена данными для управляемого экземпляра SQL.

Обзор

В Управляемом экземпляре SQL экземпляр помещается в виртуальную сеть Azure и внутри подсети, выделенной для управляемых экземпляров SQL. Развертывание предоставляет следующие возможности:

• Безопасный IP-адрес в пределах локальной виртуальной сети (VNet-local).
• возможность подключения локальной сети к Управляемому экземпляру SQL;
• Возможность подключения управляемого экземпляра SQL к связанному серверу или другому локальному хранилищу данных.
• возможность подключения Управляемого экземпляра SQL к ресурсам Azure.

Высокоуровневая архитектура подключения

Управляемый экземпляр SQL состоит из компонентов службы, размещенных в выделенном наборе изолированных виртуальных машин, сгруппированных по аналогичным атрибутам конфигурации и присоединенных к виртуальному кластеру. Некоторые компоненты службы развертываются в подсети виртуальной сети клиента, а другие службы работают в защищенной сетевой среде, управляемой корпорацией Майкрософт.

Клиентские приложения могут подключаться к Управляемому экземпляру SQL и выполнять запросы, а также обновлять базы данных в виртуальной сети, в одноранговой виртуальной сети или в сети, подключенной через VPN или Azure ExpressRoute.

На следующей схеме показаны сущности, подключающиеся к Управляемому экземпляру SQL. В нем также показаны ресурсы, необходимые для взаимодействия с управляемым экземпляром SQL. Процесс обмена данными в нижней части схемы показывает, как приложения клиента и средства подключаются к Управляемому экземпляру SQL в качестве источников данных.

Управляемый экземпляр SQL — это однотенантная платформа как услуга, которая работает в двух плоскостях: плоскость данных и плоскость управления.

Плоскость данных развертывается в подсети клиента для совместимости, подключения и сетевой изоляции. Плоскость данных зависит от таких служб Azure, как Azure Storage, Microsoft Entra ID (ранее Azure Active Directory) для проверки подлинности, а также от служб сбора данных телеметрии. Вы увидите трафик, исходящий из подсетей, содержащих Управляемый экземпляр SQL, который направляется к этим службам.

Контрольный план выполняет функции развертывания, управления и обслуживания основных служб с помощью автоматических агентов. Эти агенты имеют эксклюзивный доступ к вычислительным ресурсам, которые управляют службой. Для доступа к этим узлам нельзя использовать протокол SSH или удаленный рабочий стол. Все обмены данными уровня управления шифруются и подписываются с помощью сертификатов. Чтобы проверить надежность общения сторон, Управляемый экземпляр SQL постоянно проверяет эти сертификаты с помощью списков отзыва сертификатов.

Общие сведения об обмене данными

Приложения могут подключаться к Управляемому экземпляру SQL с помощью трех типов конечных точек: локальной конечной точки виртуальной сети, общедоступной конечной точкии частных конечных точек. Эти конечные точки демонстрируют различные свойства и поведение, подходящие для различных сценариев.

Локальная конечная точка VNet

Локальная конечная точка виртуальной сети является средством подключения к Управляемому экземпляру SQL по умолчанию. Доменное имя локальной конечной точки виртуальной сети находится в виде<mi_name>.<dns_zone>.database.windows.net. Это доменное имя соответствует IP-адресу из диапазона адресов подсети. Используйте локальную конечную точку виртуальной сети для подключения к управляемому экземпляру SQL во всех стандартных сценариях подключения. Локальная конечная точка виртуальной сети принимает подключения через порт 1433.

Локальная конечная точка виртуальной сети поддерживает типы подключений прокси и перенаправления.

При подключении к локальной конечной точке виртуальной сети всегда используйте его доменное имя и разрешайте входящий трафик на необходимые порты во всем диапазоне подсети, так как базовый IP-адрес может иногда меняться.

Чтобы найти доменное имя локальной конечной точки виртуальной сети для экземпляра, выполните следующие действия.

• Портал Azure: На панели Обзора после выбора управляемого экземпляра SQL в разделе Essentials значение Host показывает доменное имя локальной конечной точки VNet.
• PowerShell: Get-AzSqlInstance -ResourceGroupName <resource-group> -Name <mi-name> отображает доменное имя локальной конечной точки виртуальной сети в качестве fullyQualifiedDomainName свойства.
• Azure CLI: az sql mi show -g <resource-group> -n <mi-name> отображает доменное имя локальной конечной точки виртуальной сети в качестве fullyQualifiedDomainName свойства.

Для повышения безопасности укажите зашифрованное подключение и не доверяйте сертификату. Дополнительные сведения см. в обзоре функций безопасности.

Общедоступная конечная точка

Общедоступная конечная точка — это доменное имя в виде <mi_name>.public.<dns_zone>.database.windows.net. Это доменное имя разрешает общедоступный IP-адрес, доступный из Интернета. Общедоступная конечная точка подходит для сценариев, когда управляемый экземпляр SQL должен быть доступен через общедоступный Интернет. Например, при подключении к нему из другой виртуальной сети, если пиринги или частные конечные точки недоступны. Общедоступные конечные точки обслуживают только клиентский трафик и не могут использоваться для репликации данных между двумя экземплярами, например, группы отработки отказа или связь управляемого экземпляра. Общедоступная конечная точка принимает подключения через порт 3342.

Общедоступная конечная точка всегда использует тип подключения прокси независимо от параметра типа подключения.

Имя домена общедоступной конечной точки экземпляра равно имени локальной конечной точки виртуальной сети с меткойpublic, вставленной между именем узла и остальным доменом: <mi-name>.public.<dns-zone>.database.windows.net

При подключении к общедоступной конечной точке всегда используйте его доменное имя и разрешайте входящий трафик через порт 3342 по всему диапазону подсети, так как базовый IP-адрес может иногда меняться.

Узнайте, как настроить общедоступную конечную точку в Настройка общедоступной конечной точки для Azure SQL Managed Instance.

Частные конечные точки

Частная конечная точка — это необязательный фиксированный IP-адрес в другой виртуальной сети, которая ведет трафик к управляемому экземпляру SQL. Один управляемый экземпляр Azure SQL может иметь несколько частных конечных точек в нескольких виртуальных сетях. Частные конечные точки проводят только клиентский трафик и не могут использоваться для репликации данных между двумя экземплярами, такими как группы аварийного переключения или ссылка управляемого экземпляра. Частная конечная точка принимает подключения через порт 1433.

Частные конечные точки всегда используют тип подключения прокси независимо от параметра типа подключения.

Доменное имя частной конечной точки экземпляра равно имени локального домена виртуальной сети, если конечная точка не настроена по-другому. Это происходит, когда частная конечная точка и локальная конечная точка виртуальной сети находятся в одной виртуальной сети. Дополнительные сведения см. в статье Настройка разрешения доменных имен для частной конечной точки.

При подключении к частной конечной точке всегда используйте доменное имя, так как подключение к Управляемый экземпляр SQL Azure через его IP-адрес еще не поддерживается. Однако IP-адрес частной конечной точки не изменяется.

Дополнительные сведения о частных конечных точках и их настройке в Azure Private Link для Azure SQL Managed Instance.

Архитектура подключения виртуального кластера

На следующей схеме показан концептуальный макет архитектуры виртуального кластера:

Доменное имя локальной конечной точки виртуальной сети разрешает частный IP-адрес внутренней подсистемы балансировки нагрузки. Хотя это доменное имя зарегистрировано в зоне общедоступной системы доменных имен (DNS) и является общедоступным, его IP-адрес принадлежит диапазону адресов подсети и может быть достигнут только из своей виртуальной сети по умолчанию.

Подсистема балансировки нагрузки направляет трафик к шлюзу управляющего экземпляра SQL. Так как несколько управляемых экземпляров SQL могут выполняться в одном кластере, шлюз использует имя узла управляемого экземпляра SQL, как показано в строке подключения для перенаправления трафика в правильную службу ядра SQL.

Значение параметра dns-zone создается автоматически при создании кластера. Если только что созданный кластер размещает вторичный управляемый экземпляр SQL, он использует идентификатор зоны с основным кластером.

Требования к сети

Управляемый экземпляр SQL Azure требует настройки делегированной подсети определенными способами, которые можно достичь с помощью конфигурации подсети, предоставляемой службой. Помимо того, что требует служба, пользователи имеют полный контроль над конфигурацией сети подсети, например:

• Разрешение или блокировка трафика на некоторых или всех портах.
• Добавление записей в таблицу маршрутов для маршрутизации трафика через устройства виртуальной сети или шлюз.
• Настройка настраиваемого разрешения DNS.
• Настройка пиринга или виртуальной частной сети (VPN).

Чтобы соответствовать критериям конфигурации сети в соглашении об уровне обслуживания для Microsoft Online Services, виртуальная сеть и подсеть, в которой развернут управляемый экземпляр SQL, должны соответствовать следующим требованиям:

• Выделенная подсеть: Подсеть, используемая Управляемым экземпляром SQL, может быть делегирована только службе Управляемого экземпляра SQL. Подсеть не может быть подсетью шлюза, и в ней можно развертывать только ресурсы управляемого экземпляра SQL.
• Делегирование подсети: Подсеть управляемого экземпляра SQL должна быть делегирована поставщику Microsoft.Sql/managedInstances ресурсов.
• Группа безопасности сети: Группа безопасности сети должна быть связана с подсетью управляемого экземпляра SQL. Группу безопасности сети можно использовать для управления доступом к конечной точке данных управляемого экземпляра SQL, отфильтровав входящий трафик через порт 1433. Служба автоматически подготавливает правила и сохраняет их в актуальном состоянии, чтобы обеспечить непрерывный поток трафика управления.
• Таблица маршрутов: таблица маршрутов должна быть связана с подсетью SQL Управляемый экземпляр. Вы можете добавить записи в эту таблицу маршрутов, например для маршрутизации трафика в локальную среду через шлюз виртуальной сети или добавить маршрут по умолчанию 0.0.0.0/0, направляюющий весь трафик через виртуальное сетевое устройство, например брандмауэр. Управляемый экземпляр SQL Azure автоматически подготавливает и управляет необходимыми записями в таблице маршрутов.
• Достаточное количество IP-адресов. Подсеть Управляемого экземпляра SQL должна иметь по крайней мере 32 IP-адресов. Дополнительные сведения см. в статье об определении размера подсети для Управляемого экземпляра SQL. После настройки управляемого экземпляра SQL можно развернуть управляемые экземпляры SQL в существующей сети , чтобы удовлетворить требования к сети для Управляемого экземпляра SQL. В противном случае создайте сеть и подсеть.
• Разрешено политиками Azure. Если вы используете Политика Azure для предотвращения создания или изменения ресурсов в области, включающей подсеть Управляемый экземпляр SQL или виртуальную сеть, политики не должны препятствовать Управляемый экземпляр SQL управлению внутренними ресурсами. Следующие ресурсы необходимо исключить из эффектов запрета политики для нормальной работы:
  • Ресурсы типа Microsoft.Network/serviceEndpointPolicies, когда имя ресурса начинается с \_e41f87a2\_
  • Все ресурсы типа Microsoft.Network/networkIntentPolicies
  • Все ресурсы типа Microsoft.Network/virtualNetworks/subnets/contextualServiceEndpointPolicies
• Блокировка виртуальной сети: блокировка виртуальной сети выделенной подсети, родительской группы ресурсов или подписки может иногда препятствовать операциям управления управляемым экземпляром SQL и обслуживанию. Обратите особое внимание при использовании блокировок ресурсов.
• Разрешимые общедоступные записи DNS: Если виртуальная сеть настроена для использования пользовательского DNS-сервера, DNS-сервер должен уметь разрешать общедоступные записи DNS. Использование таких функций, как проверка подлинности Microsoft Entra, может потребовать разрешения более полных доменных имен (FQDN). Дополнительные сведения см. в разделе Разрешение частных DNS-имен в Управляемом экземпляре SQL Azure.
• Обязательные записи DNS: управляемые экземпляры SQL зависят от правильного разрешения определенных доменных имен. Эти доменные имена не должны быть переопределены в своих виртуальных сетях ни через частные зоны Azure DNS, ни настраиваемым DNS-сервером. В противном случае управляемые экземпляры SQL не будут развертываться или могут стать недоступными. Следующие домены не должны быть переопределены: 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.netи vault.azure.net. Вы по-прежнему можете создавать частные конечные точки в виртуальной сети управляемого экземпляра SQL, даже для ресурсов в указанных выше доменах. Частные конечные точки используют механизм DNS, который не требует, чтобы локальный DNS-сервер стал доверенным для всей зоны.
• Тег AzurePlatformDNS: использование тега службы AzurePlatformDNS для блокировки разрешения DNS на платформе может сделать Управляемый экземпляр SQL недоступным. Несмотря на то, что Управляемый экземпляр SQL поддерживает определяемый клиентом DNS для разрешения DNS внутри движка, для операций платформы используется Azure DNS.

Конфигурация подсети с помощью сервиса

Для повышения безопасности, управляемости и доступности, для Управляемого экземпляра SQL используется конфигурация подсети, поддерживаемая службами, и политика сетевого намерения в инфраструктуре виртуальной сети Azure для настройки сети, связанных компонентов и таблицы маршрутов, чтобы гарантировать соблюдение минимальных требований к Управляемому экземпляру SQL.

Автоматически настроенные правила безопасности сети и таблицы маршрутов отображаются клиенту и заносятся в одно из этих префиксов:

• Microsoft.Sql-managedInstances_UseOnly_mi- для обязательных правил и маршрутов
• Microsoft.Sql-managedInstances_UseOnly_mi-optional- для необязательных правил и маршрутов

Для получения дополнительной информации см. конфигурацию подсети с поддержкой служб.

Дополнительные сведения об архитектуре подключения и трафике управления см. в разделе "Высокоуровневая архитектура подключения".

Ограничения сети

Ниже приведены ограничения на функции виртуальной сети и трафик.

• Частные подсети: управляемые экземпляры SQL могут работать в частных подсетях. Тем не менее, развертывания в частных подсетях, как ожидается, завершаются неудачей в следующих регионах: Центральная Катар, Центральная Израиль,Северо-Запад Израиля, Центральная ОАЭ и Север ОАЭ. Чтобы развернуть управляемый экземпляр SQL в одном из этих регионов, включите исходящий доступ по умолчанию для подсети, разверните экземпляр и измените подсеть на частную (отключите исходящий доступ по умолчанию). Сведения о настройке частных подсетей см. в статье об исходящем доступе по умолчанию в Azure.
• Шифрование виртуальной сети. Развертывание и эксплуатация управляемых экземпляров SQL в виртуальных сетях, где шифрование виртуальной сети Azure в настоящее время не поддерживается.
• Почта базы данных во внешние ретрансляторы SMTP через порт 25: Отправка почты базы данных через порт 25 внешним службам электронной почты доступна только для определенных типов подписок в Microsoft Azure. Экземпляры других типов подписок должны использовать другой порт (например, 587) для связи с внешними ретрансляторами SMTP. В противном случае экземпляры могут не доставлять сообщения для базы данных. Подробные сведения см. в статье Устранение проблем с исходящими SMTP-подключениями в Azure.
• Пиринг Майкрософт: Включение пиринга Майкрософт в каналах ExpressRoute, которые напрямую или опосредованно подключены к виртуальной сети, где находится Управляемый экземпляр SQL, влияет на поток трафика между компонентами Управляемого экземпляра SQL внутри виртуальной сети и службами, от которых они зависят. Результат проблем с доступностью. Развертывания управляемых экземпляров SQL в виртуальной сети, в которой уже включены пиринги Microsoft, ожидается, что завершатся сбоем.
• Пиринг глобальной виртуальной сети: подключение к пирингу между виртуальными сетями в регионах Azure не работает для управляемых экземпляров SQL, размещенных в подсетях, созданных до 9 сентября 2020 г.
• Пиринг между виртуальными сетями — конфигурация. При установке пиринга между виртуальными сетями, содержащими подсети с управляемыми экземплярами SQL, такие подсети должны использовать разные таблицы маршрутов и группы безопасности сети (NSG). Повторное использование таблицы маршрутов и группы безопасности сети в двух или более подсетях, участвующих в пиринге виртуальной сети, приведет к проблемам с подключением во всех подсетях, использующих эти таблицы маршрутов или группы безопасности сети, и вызовет сбой операций управления SQL Managed Instance.
• Шлюз NAT. Использование NAT виртуальной сети Azure для управления исходящим подключением с определенным общедоступным IP-адресом в настоящее время не поддерживается.
• IP версии 6 для виртуальной сети Azure: Вероятно, при развертывании Управляемого экземпляра SQL в виртуальных сетях с двойным стеком IPv4/IPv6 произойдет сбой. Связывание группы безопасности сети или таблицы маршрутов с определяемыми пользователем маршрутами, содержащими префиксы IPv6, с подсетью Управляемого экземпляра SQL делает Управляемый экземпляр SQL недоступным. Кроме того, добавление префиксов IPv6-адресов в группу безопасности сети или UDR, которая уже связана с подсетью управляемого экземпляра SQL, делает управляемый экземпляр SQL недоступным. Развертывания управляемых экземпляров SQL в подсеть с группой безопасности сети и UDR, у которых уже есть префиксы IPv6, скорее всего завершатся с ошибкой.
• Протокол TLS 1.2 применяется к исходящим подключениям: начиная с января 2020 года корпорация Майкрософт применяет TLS 1.2 для трафика внутри службы Azure. Для управляемого экземпляра SQL это привело к принудительному применению TLS 1.2 для исходящих подключений, используемых для репликации, а также подключений связанных серверов к SQL Server. Если вы используете версию SQL Server до 2016 года с SQL Managed Instance, убедитесь, что вы применяете специфические обновления TLS 1.2.
• Внутренний резервный механизм Azure DNS: экземпляры SQL Managed Instance зависят от функционирования разрешения DNS в своих виртуальных сетях. Если виртуальная сеть управляемого экземпляра SQL настроена на использование пользовательских DNS-серверов и dns-запроса, выданного пользовательским DNS-серверам, не выполняется в течение определенного интервала (1–2 секунд), управляемый экземпляр SQL повторит запрос к Azure DNS в этой виртуальной сети.

Связанный контент

• Обзор см. в статье Что такое управляемый экземпляр SQL Azure?.
• Дополнительные сведения см. в следующем разделе:
  • Архитектура виртуального кластера.
  • Конфигурация подсети с поддержкой служб.
  • Настройте новую виртуальную сеть Azure или существующую виртуальную сеть Azure, где можно развернуть Управляемый экземпляр SQL.
  • Вычислите размер подсети, где будет развернут Управляемый экземпляр SQL.
• Узнайте, как создать управляемый экземпляр SQL:
  • На портале Azure.
  • с помощью PowerShell;
  • с помощью шаблона Azure Resource Manager;
  • С помощью шаблона Azure Resource Manager с jumpbox и SQL Server Management Studio.