Архитектура подключения в Базе данных Azure для MySQL

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

Внимание

База данных Azure для MySQL один сервер находится на пути выхода на пенсию. Настоятельно рекомендуется выполнить обновление до База данных Azure для MySQL гибкого сервера. Дополнительные сведения о миграции на гибкий сервер База данных Azure для MySQL см. в статье "Что происходит с одним сервером База данных Azure для MySQL?"

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

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

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

Overview of the connectivity architecture

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

IP-адреса шлюзов Базы данных Azure для MySQL

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

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

  • Если IP-адреса шлюза жестко заданы в коде в строке подключения приложения. Делать это не рекомендуется. В строке подключения для приложения следует использовать полное доменное имя (FQDN) сервера в формате <servername>.mysql.database.azure.com.
  • Вы можете не обновлять IP-адреса новых шлюзов в брандмауэре на стороне клиента, чтобы обеспечить доступ исходящего трафика к нашим новым кольцам шлюза.

Внимание

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

В следующей таблице перечислены IP-адреса шлюзов для шлюза Базы данных Azure для MySQL для всех регионов размещения данных. Наиболее актуальные сведения об IP-адресах шлюзов для каждого региона см. в таблице ниже. В таблице ниже представлены следующие столбцы:

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

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

Имя региона Текущий IP-адрес шлюза Подсети IP-адресов шлюза
Центральная Австралия 20.36.105.32 20.36.105.32/29, 20.53.48.96/27
Центральная Австралия 2 20.36.113.32 20.36.113.32/29, 20.53.56.32/27
Восточная Австралия 13.70.112.32 13.70.112.32/29, 40.79.160.32/29, 40.79.168.32/29, 40.79.160.32/29, 20.53.46.128/27
Юго-восточная часть Австралии 13.77.49.33 13.77.49.32/29, 104.46.179.160/27
Южная Бразилия 191.233.201.8, 191.233.200.16 191.234.153.32/27, 191.234.152.32/27, 191.234.157.136/29, 191.233.200.32/29, 191.234.144.32/29, 191.234.142.160/27
Юго-Восточная Бразилия 191.233.48.2 191.233.48.32/29, 191.233.15.160/27
Центральная Канада 13.71.168.32 13.71.168.32/29, 20.38.144.32/29, 52.246.152.32/29, 20.48.196.32/27
Восточная Канада 40.69.105.32 40.69.105.32/29, 52.139.106.192/27
Центральная часть США 52.182.136.37, 52.182.136.38 104.208.21.192/29, 13.89.168.192/29, 52.182.136.192/29, 20.40.228.128/27
Восточный Китай 52.130.112.139 52.130.112.136/29, 52.130.13.96/27
Восточный Китай 2 40.73.82.1, 52.130.120.89 52.130.120.88/29, 52.130.7.0/27
Северный Китай 52.130.128.89 52.130.128.88/29, 40.72.77.128/27
Северный Китай 2 40.73.50.0 52.130.40.64/29, 52.130.21.160/27
Восточная Азия 13.75.33.20, 13.75.33.21 20.205.77.176/29, 20.205.83.224/29, 20.205.77.200/29, 13.75.32.192/29, 13.75.33.192/29, 20.195.72.32/27
Восточная часть США 40.71.8.203, 40.71.83.113 20.42.65.64/29, 20.42.73.0/29, 52.168.116.64/29, 20.62.132.160/27
Восточная часть США 2 52.167.105.38, 40.70.144.38 104.208.150.192/29, 40.70.144.192/29, 52.167.104.192/29, 20.62.58.128/27
Центральная Франция 40.79.129.1 40.79.128.32/29, 40.79.136.32/29, 40.79.144.32/29, 20.43.47.192/27
Франция (юг) 40.79.176.40 40.79.176.40/29, 40.79.177.32/29, 52.136.185.0/27
Северная Германия 51.116.56.0 51.116.57.32/29, 51.116.54.96/27
Центрально-Западная Германия 51.116.152.0 51.116.152.32/29, 51.116.240.32/29, 51.116.248.32/29, 51.116.149.32/27
Центральная Индия 20.192.96.33 40.80.48.32/29, 104.211.86.32/29, 20.192.96.32/29, 20.192.43.160/27
Индия (юг) 40.78.192.32 40.78.192.32/29, 40.78.193.32/29, 52.172.113.96/27
Индия (запад) 104.211.144.32 104.211.144.32/29, 104.211.145.32/29, 52.136.53.160/27
Восточная Япония 40.79.184.8, 40.79.192.23 13.78.104.32/29, 40.79.184.32/29, 40.79.192.32/29, 20.191.165.160/27
Западная Япония 40.74.96.6 20.18.179.192/29, 40.74.96.32/29, 20.189.225.160/27
Jio, Центральная Индия 20.192.233.32 20.192.233.32/29, 20.192.48.32/27
Западная Индия Jio 20.193.200.32 20.193.200.32/29, 20.192.167.224/27
Республика Корея, центральный регион 52.231.17.13 20.194.64.32/29, 20.44.24.32/29, 52.231.16.32/29, 20.194.73.64/27
Республика Корея, южный регион 52.231.145.3 52.231.151.96/27, 52.231.151.88/29, 52.231.145.0/29, 52.147.112.160/27
Центрально-северная часть США 52.162.104.35, 52.162.104.36 52.162.105.200/29, 20.125.171.192/29, 52.162.105.192/29, 20.49.119.32/27
Северная Европа 52.138.224.6, 52.138.224.7 13.69.233.136/29, 13.74.105.192/29, 52.138.229.72/29, 52.146.133.128/27
Восточная Норвегия; 51.120.96.0 51.120.208.32/29, 51.120.104.32/29, 51.120.96.32/29, 51.120.232.192/27
Западная Норвегия 51.120.216.0 51.120.217.32/29, 51.13.136.224/27
Северная часть ЮАР 102.133.152.0 102.133.120.32/29, 102.133.152.32/29, 102.133.248.32/29, 102.133.221.224/27
Западная часть ЮАР 102.133.24.0 102.133.25.32/29, 102.37.80.96/27
Центрально-южная часть США 20.45.120.0 20.45.121.32/29, 20.49.88.32/29, 20.49.89.32/29, 40.124.64.136/29, 20.65.132.160/27
Юго-Восточная Азия 23.98.80.12, 40.78.233.2 13.67.16.192/29, 23.98.80.192/29, 40.78.232.192/29, 20.195.65.32/27
Центральная Швеция 51.12.96.32 51.12.96.32/29, 51.12.232.32/29, 51.12.224.32/29, 51.12.46.32/27
Южная Швеция 51.12.200.32 51.12.201.32/29, 51.12.200.32/29, 51.12.198.32/27
Северная Швейцария 51.107.56.0 51.107.56.32/29, 51.103.203.192/29, 20.208.19.192/29, 51.107.242.32/27
Западная Швейцария 51.107.152.0 51.107.153.32/29, 51.107.250.64/27
Центральная часть ОАЭ 20.37.72.64 20.37.72.96/29, 20.37.73.96/29, 20.37.71.64/27
Северная часть ОАЭ; 65.52.248.0 20.38.152.24/29, 40.120.72.32/29, 65.52.248.32/29, 20.38.143.64/27
южная часть Соединенного Королевства 51.105.64.0 51.105.64.32/29, 51.105.72.32/29, 51.140.144.32/29, 51.143.209.224/27
западная часть Соединенного Королевства 51.140.208.98 51.140.208.96/29, 51.140.209.32/29, 20.58.66.128/27
Центрально-западная часть США 13.71.193.34 13.71.193.32/29, 20.69.0.32/27
Западная Европа 13.69.105.208,104.40.169.187 104.40.169.32/29, 13.69.112.168/29, 52.236.184.32/29, 20.61.99.192/27
Западная часть США 13.86.216.212, 13.86.217.212 20.168.163.192/29, 13.86.217.224/29, 20.66.3.64/27
западная часть США 2 13.66.136.192 13.66.136.192/29, 40.78.240.192/29, 40.78.248.192/29, 20.51.9.128/27
Западная часть США — 3 20.150.184.2 20.150.168.32/29, 20.150.176.32/29, 20.150.184.32/29, 20.150.241.128/27

Перенаправление подключения

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

Эта функция поддерживается на База данных Azure для MySQL серверах с подсистемой 5.7 и 8.0.

Поддержка перенаправления доступна в расширении PHP mysqlnd_azure, разработанном корпорацией Майкрософт и доступна в PECL. Дополнительные сведения о том, как использовать перенаправление в приложениях, см. в статье Настройка перенаправления.

Внимание

Поддержка перенаправления в расширении PHP mysqlnd_azure в настоящее время доступна в предварительной версии.

Часто задаваемые вопросы

Что необходимо знать об этом плановом обслуживании?

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

Что мы выводим из эксплуатации?

Удаляются только узлы шлюза. Когда пользователи подключаются к своим серверам, подключение сначала устанавливается с узлом шлюза и лишь затем перенаправляется на сервер. Деактивируются старые круги шлюза, а не те круги арендатора, где работает сервер. Дополнительные сведения см. в разделе Архитектура подключения.

Как проверить направление подключений — к старым или новым узлам шлюза?

Выполните проверку связи полного доменного имени вашего сервера, например ping xxx.mysql.database.azure.com. Если возвращенный IP-адрес является одним из IP-адресов, указанных в разделе "IP-адреса шлюзов (вывод из эксплуатации)" выше, это означает, что подключение осуществляется через старый шлюз. Наоборот, если возвращенный IP-адрес является одним из IP-адресов, перечисленных в IP-адресах шлюза, это означает, что подключение проходит через новый шлюз.

Также можно протестировать сервер базы данных, выполняя команду PSPing или TCPPing из клиентского приложения с портом 3306, и убедиться, что возвращаемый IP-адрес не является одним из деактивированных IP-адресов.

Как узнать, что обслуживание завершено? Получу ли я еще одно уведомление, когда старые IP-адреса будут деактивированы?

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

Что делать, если клиентские приложения все еще подключаются к старому серверу шлюза?

Это означает, что приложения подключаются к серверу, используя статический IP-адрес вместо FQDN. Проверьте строки подключения и параметры группировки подключений в пул, параметры AKS и, наконец, исходный код.

Повлияет ли это на подключения моих приложений?

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

Можно ли узнать, когда именно будет проводиться техническое обслуживание?

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

Нет. Выводится из эксплуатации оборудование шлюза. Это не имеет отношения к приватным каналам или частным IP-адресам. Вывод оборудования из эксплуатации повлияет только на общедоступные IP-адреса, указанные в перечне деактивируемых IP-адресов.

Следующие шаги