Архитектура подключения в Базе данных Azure для PostgreSQL
Область применения:
отдельный сервер Базы данных Azure для PostgreSQL
Внимание
База данных Azure для PostgreSQL — одиночный сервер находится на пути выхода на пенсию. Настоятельно рекомендуется выполнить обновление до База данных Azure для PostgreSQL — гибкий сервер. Дополнительные сведения о миграции на База данных Azure для PostgreSQL — гибкий сервер см. в статье "Что происходит с одним сервером База данных Azure для PostgreSQL?".
В этой статье описана архитектура подключения для Базы данных Azure PostgreSQL, а также представлены сведения о направлении трафика в вашу БД Azure для экземпляра Базы данных PostgreSQL от клиентов, которые подключаются как из, так и извне Azure.
Архитектура подключения
Подключение к Базе данных Azure для PostgreSQL устанавливается через шлюз, отвечающий за маршрутизацию входящих подключений к физическому расположению вашего сервера в наших кластерах. На следующей схеме показан поток трафика.
При подключении клиента к базе данных, строка подключения к серверу разрешается в IP-адрес шлюза. Шлюз прослушивает IP-адрес порта 5432. В кластере баз данных трафик перенаправляется в соответствующую базу данных Azure для PostgreSQL. Поэтому для подключения к серверу, например, из корпоративных сетей, необходимо открыть брандмауэр на стороне клиента, чтобы исходящий трафик получил доступ к нашим шлюзам. Ниже приведен полный список IP-адресов, используемых нашими шлюзами по регионам.
IP-адреса шлюза Базы данных Azure для PostgreSQL
Служба шлюза размещается в группе вычислительных узлов без отслеживания состояния, расположенных за IP-адресом. Это адрес, к которому клиент будет обращаться сначала при попытке подключиться к серверу База данных Azure для PostgreSQL.
В рамках текущего обслуживания обслуживания мы периодически обновляем вычислительное оборудование, на котором размещаются шлюзы, чтобы обеспечить наиболее безопасный и высокий уровень подключения. При обновлении оборудования шлюза сначала создается новое кольцо для таких вычислительных узлов. Это новое кольцо служит трафиком для всех созданных База данных Azure для PostgreSQL серверов и имеет другой IP-адрес от старых кругов шлюза в том же регионе, чтобы отличить трафик. Старое оборудование шлюза продолжит обслуживание существующих серверов, однако в будущем планируется его списание. Перед выводом оборудования шлюза клиенты выполняют свои серверы и подключаются к старым кольцам шлюза, уведомляются по электронной почте и в портал Azure, три месяца перед выводом из эксплуатации. Вывод шлюзов из эксплуатации может повлиять на подключение к серверам в случаях, описанных ниже.
- Если IP-адреса шлюза жестко заданы в коде в строке подключения приложения. Не рекомендуется. В строке подключения для приложения следует использовать полное доменное имя (FQDN) сервера в формате
<servername>.postgres.database.azure.com. - Вы можете не обновлять IP-адреса новых шлюзов в брандмауэре на стороне клиента, чтобы обеспечить доступ исходящего трафика к нашим новым кольцам шлюза.
Внимание
Если стек подключений клиентов должен напрямую подключаться к шлюзу вместо рекомендуемого подхода к DNS-имени или шлюзу разрешенного списка в правилах брандмауэра для подключений к инфраструктуре клиентов, мы настоятельно рекомендуем клиентам использовать подсети IP-адресов шлюза и жесткое шифрование статических IP-адресов, чтобы не влиять на это действие в регионе, который может привести к изменению IP-адресов в диапазоне подсети .
В следующей таблице перечислены подсети IP-адресов шлюза шлюза База данных Azure для PostgreSQL для всех регионов данных. Наиболее актуальные сведения об IP-адресах шлюзов для каждого региона см. в таблице ниже. В таблице ниже представлены следующие столбцы:
- Имя региона. Этот столбец содержит имя региона Azure, где предлагается База данных Azure для PostgreSQL — отдельный сервер.
- Подсети 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 | 3.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 |
Часто задаваемые вопросы
Что нужно знать об этом плановом обслуживании
Изменения затрагивают только DNS-сервера, что обеспечивает их прозрачность для клиентов. Хотя IP-адрес для полного доменного имени изменяется на DNS-сервере, локальный кэш DNS обновляется в течение 5 минут, и он автоматически выполняется операционными системами. После обновления локального кэша DNS все новые подключения будут устанавливаться к новому IP-адресу, а все существующие подключения останутся установленными к старому IP-адресу без прерывания до тех пор, пока старые IP-адреса не будут полностью выведены из эксплуатации. Старый IP-адрес занимает примерно три–четыре недели, прежде чем вывести из эксплуатации; таким образом, он не должен влиять на клиентские приложения.
Что мы выводим из эксплуатации?
Удаляются только узлы шлюза. Когда пользователи подключаются к своим серверам, подключение сначала устанавливается с узлом шлюза и лишь затем перенаправляется на сервер. Выводятся из эксплуатации старые кольца шлюза, а не те клиентские кольца, где работает сервер. Дополнительные сведения см. в разделе Архитектура подключения.
Как проверить направление подключений — к старым или новым узлам шлюза?
Выполните проверку связи полного доменного имени вашего сервера, например ping xxx.postgres.database.azure.com. Если возвращенный IP-адрес является одним из IP-адресов, указанных в разделе "IP-адреса шлюзов (вывод из эксплуатации)" выше, это означает, что подключение осуществляется через старый шлюз. Напротив, если возвращенный IP-адрес является одним из IP-адресов, перечисленных в IP-адресах шлюза, это означает, что подключение проходит через новый шлюз.
Вы также можете протестировать сервер базы данных psPing или TCPPing из клиентского приложения с портом 5432 и убедиться, что возвращаемый IP-адрес не является одним из списанных IP-адресов.
Как узнать, что обслуживание завершено? Получу ли я еще одно уведомление, когда старые IP-адреса будут деактивированы?
Вы получите сообщение электронной почты, чтобы сообщить вам о начале работы по обслуживанию. Обслуживание может занять до одного месяца в зависимости от количества серверов, которые будет необходимо перенести во всех регионах. Подготовьте клиент для подключения к серверу базы данных с помощью FQDN или нового IP-адреса из приведенной выше таблицы.
Что делать, если клиентские приложения все еще подключаются к старому серверу шлюза?
Это означает, что приложения подключаются к серверу, используя статический IP-адрес вместо FQDN. Проверьте строки подключения и параметры группировки подключений в пул, параметры AKS и, наконец, исходный код.
Повлияет ли это на подключения моих приложений?
Эти изменения затрагивают только DNS, поэтому являются прозрачными для клиентов. После обновления кэша DNS в клиенте (автоматически выполняется системой операций), все новые подключения подключаются к новому IP-адресу и все существующие подключения по-прежнему будут работать нормально, пока старый IP-адрес не будет полностью выведен из эксплуатации, что составляет несколько недель спустя. В этом случае логика повторных попыток не требуется, но хорошо, если она настроена в приложении. Используйте полное доменное имя для подключения к серверу базы данных в строка подключения приложения. Проводимое техническое обслуживание не приведет к деактивации существующих соединений. Оно затронет только новые подключения: они станут обращаться к новому кольцу шлюза.
Можно ли узнать, когда именно будет проводиться техническое обслуживание?
Поскольку миграция должна быть прозрачной и не должна влиять на подключение клиента, предполагается, что у большинства пользователей не возникнет проблем. Заранее проанализируйте приложение и убедитесь, что для подключения к серверу базы данных используется полное доменное имя, или добавьте список новых IP-адресов шлюза в строку подключения приложения.
Я использую приватный канал. Будут ли мои подключения затронуты?
Нет. Выводится из эксплуатации оборудование шлюза. Это не имеет отношения к приватным каналам или частным IP-адресам. Вывод оборудования из эксплуатации повлияет только на общедоступные IP-адреса, указанные в перечне деактивируемых IP-адресов.