Бөлісу құралы:


Доступ из частной сети с помощью интеграции с виртуальной сетью для Базы данных Azure для MySQL — гибкий сервер

ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных Azure для MySQL — гибкий сервер

В этой статье описан вариант частного подключения для гибкого сервера База данных Azure для MySQL. Вы подробно узнаете о концепциях виртуальной сети для База данных Azure для MySQL гибкого сервера для безопасного создания сервера в Azure.

Частный доступ (интеграция виртуальная сеть)

Azure виртуальная сеть) — это базовый стандартный блок для частной сети в Azure. Интеграция виртуальной сети с гибким сервером База данных Azure для MySQL обеспечивает преимущества сетевой безопасности и изоляции Azure.

Интеграция виртуальной сети для экземпляра гибкого сервера База данных Azure для MySQL позволяет заблокировать доступ к серверу только к инфраструктуре виртуальной сети. Виртуальная сеть может включать все ресурсы приложения и базы данных в одну виртуальную сеть или может растянуться по разным виртуальная сеть в одном регионе или другом регионе. Простое подключение между различными виртуальными сетями можно установить путем пиринга, который использует низкую задержку корпорации Майкрософт, высокоскоростную частную магистральную инфраструктуру. После создания пиринговой связи две виртуальные сети выглядят как одна сеть в плане подключения.

База данных Azure для MySQL гибкий сервер поддерживает подключение клиентов из:

  • Виртуальные сети в одном регионе Azure (локальные пиринговые виртуальные сети)
  • Виртуальные сети в разных регионах Azure (глобальные пиринговые виртуальные сети)

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

Примечание.

Наименьший диапазон CIDR, который можно указать для подсети для размещения База данных Azure для MySQL гибкий сервер— /29, который предоставляет восемь IP-адресов. Однако первый и последний адрес в любой сети или подсети не могут быть назначены любому отдельному узлу. Azure резервирует пять IP-адресов для внутреннего использования сетевыми сетями Azure, включая два IP-адреса, которые не могут быть назначены узлу. Это оставляет три доступных IP-адреса для диапазона CIDR /29. Для База данных Azure для MySQL гибкого сервера необходимо выделить один IP-адрес на узел из делегированной подсети при включении частного доступа. Для серверов с поддержкой высокой доступности требуется два IP-адреса, а для сервера, отличного от высокого уровня доступности, требуется один IP-адрес. Рекомендуется зарезервировать по крайней мере два IP-адреса для каждого экземпляра гибкого сервера База данных Azure для MySQL, так как параметры высокой доступности можно включить позже. База данных Azure для MySQL гибкий сервер интегрируется с зонами Azure Частная зона DNS, чтобы обеспечить надежную, безопасную службу DNS для управления и разрешения доменных имен в виртуальной сети без необходимости добавлять пользовательское решение DNS. Частная зона DNS может быть связана с одной или несколькими виртуальными сетями путем создания каналов виртуальной сети.

Снимок экрана: виртуальная сеть MySQL с гибким сервером.

На приведенной выше диаграмме

  1. Экземпляры гибкого сервера Базы данных Azure для MySQL внедряются в делегированную подсеть — 10.0.1.0/24 виртуальной сети VNet-1.
  2. Приложения, развернутые в разных подсетях в одной виртуальной сети, могут напрямую обращаться к экземплярам гибкого сервера База данных Azure для MySQL.
  3. Приложения, развернутые в другой виртуальной сети виртуальной сети 2, не имеют прямого доступа к База данных Azure для MySQL экземплярам гибкого сервера. Прежде чем получить доступ к экземпляру, необходимо выполнить пиринг виртуальной сети частной зоны DNS.

Основные понятия виртуальной сети

Ниже приведены некоторые понятия, с которыми можно ознакомиться при использовании виртуальная сеть с экземплярами гибкого сервера База данных Azure для MySQL.

  • Виртуальная сеть -

    Azure виртуальная сеть содержит пространство частных IP-адресов, настроенное для использования. Дополнительные сведения о виртуальных сетях Azure см. в статье Обзор виртуальной сети Azure.

    Виртуальная сеть должна находиться в том же регионе Azure, что и экземпляр гибкого сервера База данных Azure для MySQL.

  • Делегированная подсеть -

    Виртуальная сеть содержит подсети (подсети). Подсети позволяют сегментировать виртуальную сеть в меньшие адресные пространства. Ресурсы Azure развертываются в определенные подсети в виртуальной сети.

    Экземпляр гибкого сервера База данных Azure для MySQL должен находиться в подсети, делегированной только для использования гибкого сервера База данных Azure для MySQL. Это означает, что только экземпляры гибкого сервера База данных Azure для MySQL могут использовать эту подсеть. Другие типы ресурсов Azure не могут быть делегированы подсети. Вы делегируете подсеть, назначив ее свойство делегирования как Microsoft.DBforMySQL/flexibleServers.

  • Группы безопасности сети (NSG)

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

  • Интеграция с Частной зоной DNS

    Интеграция частной зоны DNS Azure позволяет разрешать частные DNS в текущей виртуальной сети или любой одноранговой виртуальной сети, в которой связана частная зона DNS.

  • Пиринг виртуальной сети

    Пиринг между виртуальными сетями позволяет легко подключать две или несколько виртуальных сетей в Azure. После создания пиринговой связи две виртуальные сети выглядят как одна сеть при подключении. Точно так же трафик между виртуальными машинами в одноранговых виртуальных сетях использует магистральную инфраструктуру Майкрософт. Трафик между клиентским приложением и экземпляром гибкого сервера База данных Azure для MySQL в одноранговых виртуальных сетях направляется только через частную сеть Майкрософт и изолирован к этой сети.

Использование зоны Частная зона DNS

  • Если вы используете портал Azure или Azure CLI для создания База данных Azure для MySQL гибких экземпляров сервера с виртуальной сетью, новая частная зона DNS, заканчивающаяся mysql.database.azure.com автоматически на сервер в подписке, используя предоставленное имя сервера. Кроме того, если вы хотите настроить собственную частную зону DNS с помощью экземпляра гибкого сервера База данных Azure для MySQL, ознакомьтесь с документацией по частной документации по DNS.

  • Если вы используете AZURE API, шаблон Azure Resource Manager (шаблон ARM) или Terraform, создайте частные зоны DNS, которые заканчиваются mysql.database.azure.com и используют их при настройке База данных Azure для MySQL гибких экземпляров сервера с частным доступом. Дополнительные сведения см. в обзоре частной зоны DNS.

    Внимание

    Имена частных зон DNS должны заканчиваться на mysql.database.azure.com. Если вы подключаетесь к экземпляру гибкого сервера База данных Azure для MySQL с помощью SSL, и вы используете возможность выполнить полную проверку подлинности (sslmode=VERIFY_IDENTITY) с именем субъекта сертификата, используйте <имя сервера.mysql.database.azure.com> в строка подключения.

Узнайте, как создать экземпляр гибкого сервера База данных Azure для MySQL с частным доступом (интеграция виртуальной сети) в портал Azure или Azure CLI.

Интеграция с настраиваемым DNS-сервером

Если вы используете пользовательский DNS-сервер, необходимо использовать dns-сервер пересылки для разрешения полного доменного имени экземпляра База данных Azure для MySQL гибкого сервера. IP-адрес сервера пересылки должен быть 168.63.129.16. Пользовательский DNS-сервер должен находиться в виртуальной сети или доступен с помощью параметра DNS-сервера виртуальной сети. Дополнительные сведения см. в разделе "Разрешение имен", которое использует DNS-сервер .

Внимание

Для успешной подготовки экземпляра гибкого сервера База данных Azure для MySQL, даже если вы используете пользовательский DNS-сервер, не следует блокировать трафик DNS в AzurePlatformDNS с помощью NSG.

Частная зона DN и пиринг между виртуальными сетями

Параметры частной зоны DNS и пиринга между виртуальными сетями не зависят друг от друга. Дополнительные сведения о создании и использовании зон Частная зона DNS см. в разделе "Использование Частная зона DNS зона".

Если вы хотите подключиться к экземпляру гибкого сервера База данных Azure для MySQL из клиента, подготовленного в другой виртуальной сети из того же региона или другого региона, необходимо связать частную зону DNS с виртуальной сетью. См. раздел документации о связыванию виртуальной сети.

Примечание.

Связывать можно только имена частных зон DNS, заканчивающиеся на mysql.database.azure.com.

Подключение с локального сервера к экземпляру гибкого сервера База данных Azure для MySQL в виртуальной сети с помощью ExpressRoute или VPN

Для рабочих нагрузок, требующих доступа к База данных Azure для MySQL гибкому экземпляру сервера в виртуальной сети из локальной сети, требуется expressRoute или VPN и виртуальная сеть, подключенная к локальной сети. Для этого необходимо средство пересылки DNS для разрешения имени сервера гибкого сервера База данных Azure для MySQL, если требуется подключиться из клиентских приложений (например, MySQL Workbench), работающих в локальных виртуальных сетях. Этот DNS-сервер пересылки отвечает за разрешение всех запросов DNS с помощью серверной пересылки в предоставленную Azure службу DNS 168.63.129.16.

Чтобы правильно настроить, вам потребуются следующие ресурсы:

  • Локальная сеть.
  • Экземпляр гибкого сервера База данных Azure для MySQL, подготовленный с частным доступом (интеграция виртуальной сети).
  • Виртуальная сеть , подключенная к локальной сети.
  • Dns-сервер пересылки 168.63.129.16 , развернутый в Azure.

Затем можно использовать имя сервера гибкого сервера База данных Azure для MySQL (FQDN) для подключения из клиентского приложения в одноранговой виртуальной сети или локальной сети к экземпляру гибкого сервера База данных Azure для MySQL.

Примечание.

Мы рекомендуем использовать полное доменное имя (FQDN) <servername>.mysql.database.azure.com в строка подключения при подключении к экземпляру гибкого сервера База данных Azure для MySQL. IP-адрес сервера необязательно должен быть статическим. Использование полного доменного имени поможет избежать внесения изменений в строку подключения.

Неподдерживаемые сценарии виртуальной сети

  • Общедоступная конечная точка (или общедоступный IP-адрес или DNS) — экземпляр гибкого сервера База данных Azure для MySQL, развернутый в виртуальной сети, не может иметь общедоступную конечную точку.
  • После развертывания экземпляра гибкого сервера База данных Azure для MySQL в виртуальной сети и подсети его нельзя переместить в другую виртуальную сеть или подсеть. Переместить эту виртуальную сеть в другую группу ресурсов или подписку также невозможно.
  • Частная зона DNS конфигурацию интеграции нельзя изменить после развертывания.
  • Размер подсети (адресные пространства) невозможно увеличить после размещения ресурсов в подсети.

База данных Azure для MySQL гибкий сервер можно перенести с частного доступа (интегрированная виртуальная сеть) на общедоступный доступ, используя Приватный канал. Эта функция позволяет серверам переключаться с виртуальной сети, интегрированной в Приватный канал или общедоступной инфраструктуре, без необходимости изменять имя сервера или переносить данные, упрощая процесс для клиентов.

Примечание.

Это невозможно изменить после перехода. Переход включает время простоя примерно 5–10 минут для серверов, отличных от высокого уровня доступности, и около 20 минут для серверов с поддержкой высокой доступности.

Процесс проводится в автономном режиме и состоит из двух этапов:

  1. Отключение сервера от инфраструктуры виртуальной сети.
  2. Создание Приватный канал или включение общедоступного доступа.