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

Область применения: гибкий сервер Базы данных 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 и следующим прыжком "Интернет"
  • Добавьте правило с диапазоном IP-адресов назначения так же, как диапазон гибкой подсети сервера База данных Azure для PostgreSQL и следующим прыжком "виртуальная сеть".

  Внимание

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

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

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

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

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

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

  Внимание

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

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

Использование частной зоны DNS

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

При использовании доступа к частной сети с виртуальной сетью Azure предоставление сведений о частной зоне DNS является обязательным для разрешения DNS. Для создания нового База данных Azure для PostgreSQL гибкого экземпляра сервера с помощью доступа к частной сети необходимо использовать частные зоны DNS при настройке База данных Azure для PostgreSQL гибких экземпляров сервера с частным доступом. Для создания нового База данных Azure для PostgreSQL гибкого экземпляра сервера с помощью доступа к частной сети с ПОМОЩЬЮ API, ARM или Terraform создайте частные зоны DNS и используйте их при настройке База данных Azure для PostgreSQL гибких экземпляров сервера с частным доступом. Дополнительные сведения см. в спецификациях REST API для Microsoft Azure. Если вы используете портал Azure или Azure CLI для создания База данных Azure для PostgreSQL гибких экземпляров сервера, вы можете указать имя частной зоны DNS, созданное ранее в той же или другой подписке, или частную зону DNS по умолчанию автоматически создается в подписке.

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

Внимание

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

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

Внимание

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

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

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

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

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

Частная зона 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 подключен через ExpressRoute или Site to Site VPN, подключенный к виртуальной сети концентратора. Периферийные виртуальные сети и концентратор связаны пиринговыми соединениями и могут взаимодействовать с локальными ресурсами. Концентратор и каждый периферийный узел можно реализовать в отдельных подписках или группах ресурсов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внимание

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

Host name

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

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

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

• Узнайте, как создать гибкий экземпляр сервера База данных Azure для PostgreSQL с помощью параметра "Приватный доступ" (интеграция с виртуальной сетью) в портал Azure или Azure CLI.