Сеть с частным доступом (интеграция с виртуальной сетью) для Базы данных 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.

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

  • Гибкие экземпляры сервера Базы данных 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): Правила безопасности в NSG позволяют фильтровать тип сетевого трафика, который может поступать в и из подсетей виртуальной сети и сетевых интерфейсов. Дополнительные сведения см. в разделе Обзор NSG.

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

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

    Для получения дополнительной информации смотрите обзор ASG.

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

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

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

    Конечная точка службы Microsoft.Storage автоматически настраивается в делегированной подсети при подготовке первого сервера в этой подсети. Эта конфигурация обеспечивает надежную маршрутизацию трафика в учетные записи хранения Azure, используемые для отправки файлов журнала Write-Ahead (WAL). Удаление этой конечной точки может нарушить подключение и может привести к непредвиденным последствиям для основных операций службы.

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

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

Используйте частную зону DNS

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

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

Это важно

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

Для новых экземпляров гибкого сервера базы данных Azure для PostgreSQL, созданных с помощью доступа к частной сети с помощью API, шаблона Azure Resource Manager (шаблона ARM), 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 для PostgreSQL в другую частную зону DNS в настоящее время отключена для серверов с включенной функцией высокой доступности.

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

Это важно

Мы больше не проверяем наличие виртуальной сети при создании гибких серверных экземпляров Azure Database для PostgreSQL с частными сетями. При создании сервера на портале мы предоставляем клиенту возможность связать частную зону DNS с вашей виртуальной сетью с помощью флажка "Связывание частной зоны DNS с вашей виртуальной сетью в портале Azure".

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

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

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

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

Это важно

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

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

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

Замечание

Вы можете связать только имена частных зон DNS, которые заканчиваются postgres.database.azure.com. Имя вашей зоны DNS не может совпадать с именами экземпляров гибких серверов базы данных Azure для PostgreSQL. В противном случае разрешение имен завершается неудачей.

Чтобы сопоставить имя сервера с записью 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-туннели между периферийными виртуальными сетями, чтобы обеспечить прямое подключение без обхода виртуальной сети концентратора.
  • Спицы взаимодействуют через сетевое оборудование: каждая спицевая виртуальная сеть имеет пиринг с виртуальной глобальной сетью (WAN) или с виртуальной сетью концентратора. Устройство направляет трафик от узла к узлу. Устройство может управляться корпорацией Майкрософт (как с виртуальной глобальной сетью) или вами.
  • Шлюз виртуальной сети подключен к центральной сети и использует пользовательские маршруты: позволяет обмениваться данными между спицами.

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

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

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

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

Такое подключение можно достичь несколькими способами, в том числе:

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

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

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

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

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

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

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

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

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

  • После развертывания гибкого экземпляра базы данных Azure для PostgreSQL в виртуальной сети и подсети его нельзя переместить в другую виртуальную сеть или подсеть. Переместить эту виртуальную сеть в другую группу ресурсов или подписку также невозможно.
  • Невозможно увеличить размер подсети (адресные пространства) после того, как ресурсы существуют в подсети.
  • По умолчанию внедренные ресурсы виртуальной сети не могут взаимодействовать с Private Link. Если вы хотите использовать Private Link для частных сетей, см. статью Сетевые возможности Azure Database для PostgreSQL с Private Link.
  • Пользовательские конфигурации сети, которые направляют весь трафик в службу хранилища Microsoft Azure через виртуальное сетевое устройство (NVA), не поддерживаются. Например, использование маршрута catch-all (0.0.0.0/0 → NVA) для принуждения всего исходящего трафика через NVA может мешать необходимому подключению к платформе. Это может привести к непредвиденным сбоям в критически важных операциях, включая сценарии высокой доступности. По умолчанию служба добавляет конечную точку службы Micosoft.Storage при подготовке первого сервера в делегированной подсети, которая обеспечивает безопасное и прямое подключение к службе хранилища Azure через магистральную сеть Azure. Удаление этой конечной точки может привести к непредвиденным последствиям для основных операций службы.

Это важно

Azure Resource Manager поддерживает возможность блокировки ресурсов в качестве элемента управления безопасностью. Блокировки ресурсов применяются к ресурсу и эффективны для всех пользователей и ролей. Существует два типа блокировки ресурсов: CanNotDelete и ReadOnly. Эти типы блокировки можно применять либо к частной зоне DNS, либо к отдельному набору записей.

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

Имя хоста

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

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

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

  • Last updated on