Сеть с частным доступом (интеграция с виртуальной сетью) для Базы данных Azure для PostgreSQL

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

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

• Частный доступ (интеграция виртуальной сети)
• Общедоступный доступ (разрешенные IP-адреса) и частная конечная точка

В этом документе описывается параметр сети приватного доступа (интеграция с виртуальной сетью).

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

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

Выберите вариант организации сети, если вам нужны перечисленные ниже возможности.

• Подключитесь из ресурсов Azure в той же виртуальной сети к гибкому экземпляру сервера Базы данных Azure для PostgreSQL с помощью частных IP-адресов.
• Используйте VPN или Azure ExpressRoute для подключения из ресурсов, отличных от Azure, к гибкому экземпляру сервера Базы данных Azure для PostgreSQL.
• Убедитесь, что гибкий экземпляр сервера Базы данных Azure для PostgreSQL не имеет общедоступной конечной точки, доступной через Интернет.

На предыдущей схеме показано следующее.

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

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

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

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

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

  Гибкий экземпляр сервера Базы данных Azure для PostgreSQL, интегрированный в виртуальную сеть, должен находиться в делегированной подсети. То есть только гибкие экземпляры сервера базы данных Azure для PostgreSQL могут использовать такую подсеть. Другие типы ресурсов Azure не могут быть делегированы подсети. Чтобы делегировать подсеть, нужно задать для ее свойства делегирования значение Microsoft.DBforPostgreSQL/flexibleServers.

  Наименьший диапазон CIDR, который можно указать для подсети, — /28, который предоставляет 16 IP-адресов. Первый и последний адрес в любой сети или подсети не могут быть назначены любому отдельному узлу. Azure резервирует пять IP-адресов для внутреннего использования сетевыми сетями Azure, включая два IP-адреса, которые не могут быть назначены узлу, как упоминалось. Это оставляет 11 доступных IP-адресов для диапазона CIDR /28. Один гибкий экземпляр сервера Базы данных Azure для PostgreSQL с функциями высокой доступности использует четыре адреса.

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

  Если в подсети есть таблица маршрутов, связанная с правилом, для маршрутизации всего трафика на виртуальное устройство:

  • Добавьте правило с тегом AzureActiveDirectory целевой службы и следующим прыжком Internet.
  • Добавьте правило с таким же диапазоном IP-адресов назначения, что и у подсети гибкого экземпляра базы данных Azure для PostgreSQL, и с следующим прыжком Virtual Network.

  Внимание

  Имена AzureFirewallSubnet, AzureFirewallManagementSubnet, AzureBastionSubnet и GatewaySubnet являются зарезервированными значениями Azure. Не используйте ни одно из этих имен в качестве имени подсети. Кроме того, виртуальные сети не должны перекрывать адресное пространство для создания реплик между регионами.

• Группа безопасности сети (NSG) — правила безопасности в группах безопасности сети позволяют фильтровать тип сетевого трафика, который может передаваться и из подсетей виртуальной сети и сетевых интерфейсов. Дополнительные сведения о группах безопасности сети см. здесь.

  Группы безопасности приложений (ASG) упрощают управление безопасностью уровня 4 с помощью групп безопасности сети для плоских (неструктурированных) сетей. Вы можете быстро:

  • Присоединение виртуальных машин к ASG или удаление виртуальных машин из ASG.
  • Динамическое применение правил к этим виртуальным машинам или удаление правил из этих виртуальных машин.

  Дополнительные сведения о группах приложений сети см. здесь.

  В настоящее время мы не поддерживаем группы безопасности (NSG), где ASG включен в правило для гибких экземпляров сервера Azure Database для PostgreSQL. В настоящее время мы советуем использовать в NSG фильтрацию источника или назначения на основе IP-адресов.

  Высокий уровень доступности и другие функции сервера Базы данных Azure для PostgreSQL требуют возможности отправки и получения трафика на конечный порт 5432 в подсети виртуальной сети Azure, где развернут гибкий экземпляр сервера Базы данных Azure для PostgreSQL и в службе хранилища Azure для архивации журналов. Если вы создаете группы безопасности сети (NSG) для запрета потока трафика в/из вашей базы данных Azure для экземпляра гибкого сервера PostgreSQL в пределах подсети, убедитесь, что разрешен трафик на целевой порт 5432 в подсети, а также в Storage, используя тег службы Storage в качестве назначения. Для обеспечения высокой доступности рекомендуется добавить конечную точку службы Microsoft.Storage, так как она обеспечивает правильную маршрутизацию трафика в учетную запись хранения Azure, которая используется для отправки файлов журнала записи (WAL).

  Вы можете дополнительно отфильтровать это правило исключений, добавив регион Azure в метку, например us-east.storage. Кроме того, если вы решили использовать проверку подлинности Microsoft Entra для входа в гибкий экземпляр базы данных Azure для PostgreSQL, разрешите исходящий трафик для Microsoft Entra ID с помощью тега службы Microsoft Entra.

  При настройке реплик чтения в разных регионах Azure гибкий экземпляр сервера базы данных Azure для PostgreSQL должен иметь возможность отправлять или получать трафик на конечный порт 5432 как для основного, так и для серверов реплик, а также взаимодействовать с хранилищем Azure в регионах, где находятся как основная, так и реплицированная база данных. Обязательный tcp-порт назначения для хранилища — 443.

• интеграция между зонами Частная зона DNS: интеграция с зонами azure Частная зона DNS позволяет разрешать частные DNS в текущей виртуальной сети или любой одноранговой виртуальной сети в регионе, в которой связана зона Частная зона DNS.

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

Azure Частная зона DNS предоставляет надежную и безопасную службу DNS для виртуальной сети. Частная зона DNS Azure управляет доменными именами в виртуальной сети и разрешает их, позволяя обойтись без собственного решения для поддержки DNS.

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

Для создания нового гибкого экземпляра сервера базы данных Azure для PostgreSQL с использованием частного сетевого доступа через API, шаблона Azure Resource Manager (ARM template), Bicep или Terraform, создайте частные зоны DNS. Затем используйте их при настройке гибких экземпляров сервера Базы данных Azure для PostgreSQL с частным доступом. Дополнительные сведения см . в спецификациях REST API для Azure.

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

Если вы используете API Azure, шаблон ARM, Bicep или Terraform, создайте Частная зона DNS зоны, которые заканчиваются.postgres.database.azure.com. Используйте эти зоны при настройке гибких экземпляров сервера Базы данных Azure для PostgreSQL с частным доступом. Например, используйте форму [name1].[name2].postgres.database.azure.com или [name].postgres.database.azure.com. Если вы решили использовать форму [name].postgres.database.azure.com, имя не может быть именем, которое вы используете для одного из экземпляров гибкого сервера Базы данных Azure для PostgreSQL, или вы получите сообщение об ошибке во время подготовки. Дополнительные сведения см. в обзоре зон Частная зона DNS.

При использовании портала Azure, API, Azure CLI или шаблона ARM можно также изменить частную зону DNS, указанную при создании гибкого экземпляра сервера Базы данных Azure для PostgreSQL, в другую частную зону DNS, которая существует для той же или другой подписки.

После создания зоны Частная зона DNS в Azure необходимо связать виртуальную сеть с ней. Затем ресурсы, размещенные в связанной виртуальной сети, могут получить доступ к зоне Частная зона DNS.

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

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

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

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

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

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

Чтобы сопоставить имя сервера с записью DNS, можно выполнить nslookup команду в Azure Cloud Shell с помощью Azure PowerShell или Bash. Замените имя сервера параметром <server_name> в следующем примере:

nslookup -debug <server_name>.postgres.database.azure.com | grep 'canonical name'

Использование проектирования частных сетей с концентраторами и периферийными сетями

Концентратор и периферийный сервер — это популярная сетевая модель для эффективного управления общими требованиями к обмену данными или безопасностью.

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

Периферийные модули также являются виртуальными сетями в Azure, которые используются для изоляции отдельных рабочих нагрузок. Поток трафика между локальной штаб-квартирой и Azure подключен через Azure ExpressRoute или VPN типа "сеть — сеть", подключенный к виртуальной сети концентратора. Виртуальные сети из периферийных узлов в концентратор пиринговые и обеспечивают обмен данными с локальными ресурсами. Концентратор и каждый периферийный узел можно реализовать в отдельных подписках или группах ресурсов.

Существует три основных шаблона подключения периферийных виртуальных сетей друг к другу:

• Периферийные узлы напрямую подключены друг к другу: пиринги виртуальных сетей или VPN-туннели создаются между периферийными виртуальными сетями, чтобы обеспечить прямое подключение без обхода виртуальной сети концентратора.
• Периферийные серверы взаимодействуют через сетевое устройство: каждая периферийная виртуальная сеть имеет пиринг между виртуальной глобальной сетью или виртуальной сетью концентратора. Устройство направляет трафик от периферийной к периферийной. Устройство может управляться корпорацией Майкрософт (как с виртуальной глобальной сетью) или вами.
• Шлюз виртуальной сети подключен к центральной сети и использует определяемые пользователем маршруты: включает обмен данными между периферийными устройствами.

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

Взаимодействие с частными сетевыми клиентами в разных регионах

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

Существует несколько способов обеспечения такого подключения, в том числе:

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

Репликация между регионами Azure и виртуальными сетями с помощью частных сетей

Репликация базы данных — это процесс копирования данных с центрального или первичного сервера на несколько серверов, известных как реплики. Сервер-источник принимает операции чтения и записи, но реплики служат только для чтения транзакций. Сервер-источник и реплики совместно формируют кластер базы данных. Цель репликации базы данных — обеспечить избыточность, согласованность, высокий уровень доступности и доступность данных, особенно в высокопроизводительных критически важных приложениях.

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

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

По умолчанию разрешение DNS-имен распространяется на виртуальную сеть. Любой клиент в одной виртуальной сети (VNET1) не может разрешить полное доменное имя экземпляра гибкого сервера Базы данных Azure для PostgreSQL в другой виртуальной сети (VNET2).

Чтобы устранить эту проблему, необходимо убедиться, что клиенты в VNET1 могут получить доступ к экземпляру гибкого сервера базы данных Azure для PostgreSQL в частной зоне DNS. Добавьте ссылку виртуальной сети в частную зону DNS для гибкого экземпляра сервера базы данных Azure для PostgreSQL.

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

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

• После развертывания гибкого экземпляра сервера Базы данных Azure для PostgreSQL в виртуальной сети и подсети его нельзя переместить в другую виртуальную сеть или подсеть. Переместить эту виртуальную сеть в другую группу ресурсов или подписку также невозможно.
• Размер подсети (адресные пространства) невозможно увеличить после размещения ресурсов в подсети.
• По умолчанию внедренные ресурсы виртуальной сети не могут взаимодействовать с Приватный канал. Если вы хотите использовать Private Link для частных сетей, см. статью Сетевые возможности Azure Database для PostgreSQL с Private Link.

Имя хоста

Независимо от выбранного параметра сети рекомендуется всегда использовать полное доменное имя в качестве имени узла при подключении к гибкому экземпляру сервера Базы данных Azure для PostgreSQL. IP-адрес сервера не гарантируется оставаться статическим. Использование полного доменного имени помогает избежать внесения изменений в строка подключения.

Пример, где в качестве имени узла используется полное доменное имя: hostname = servername.postgres.database.azure.com. По возможности избегайте использования адресов hostname = 10.0.0.4 (частный) и hostname = 40.2.45.67 (общедоступный).

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

• Портал Azure
• Azure CLI