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

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

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

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

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

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

Вы можете развернуть База данных Azure для PostgreSQL flexible server в вашей виртуальной сети 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, а следующий переход — виртуальная сеть.

    Это важно

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

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

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

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

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

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

    Высокий уровень доступности и другие функции сервера База данных Azure для PostgreSQL требуют возможности отправки и получения трафика в конечный порт 5432 в подсети виртуальной сети Azure, где развертывается База данных Azure для PostgreSQL гибкий сервер и в служба хранилища Azure для архивирования журналов. Если вы создаете NSG (группы безопасности сети), чтобы запретить поток трафика к серверу База данных Azure для PostgreSQL flexible server или от него в подсети, где он развернут, обязательно разрешите трафик к порту назначения 5432 в пределах этой подсети, а также к службе хранилища, используя тег службы 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 Частная зона 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 flexible server, можно указать имя зоны Частная зона 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 Database for PostgreSQL — Flexible Server, иначе при подготовке к развертыванию появится сообщение об ошибке. Для получения дополнительной информации см. обзор частных зон DNS.

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

Это важно

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

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

Это важно

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

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

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

Если вы используете пользовательский DNS-сервер, необходимо использовать DNS-переадресатор для разрешения FQDN гибкого сервера База данных 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 через 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 могут получить доступ к зоне База данных Azure для PostgreSQL гибкого сервера Частная зона DNS. Добавьте ссылку виртуальной сети в зону Частная зона DNS гибкого сервера База данных Azure для PostgreSQL.

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

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

  • После развертывания гибкого сервера База данных Azure для PostgreSQL в виртуальной сети и подсети его нельзя переместить в другую виртуальную сеть или подсеть. Переместить эту виртуальную сеть в другую группу ресурсов или подписку также невозможно.
  • Невозможно увеличить размер подсети (адресные пространства) после того, как ресурсы существуют в подсети.
  • По умолчанию внедренные ресурсы виртуальной сети не могут взаимодействовать с Приватный канал. Если вы хотите использовать Приватный канал для частных сетей, см. статью Сетевые возможности Azure Database для PostgreSQL с Приватный канал.
  • Пользовательские конфигурации сети, которые направляют весь трафик в службу хранилища 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