Поделиться через

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

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

  • База данных 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.
    • Динамическое применение правил к этим виртуальным машинам или удаление правил из этих виртуальных машин.

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

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

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

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

Внимание

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

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

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

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

Внимание

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

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

Внимание

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

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