Сетевые сценарии для службы миграции в База данных Azure для PostgreSQL

ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных Azure для PostgreSQL — гибкий сервер

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

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

Источник PostgreSQL	Назначение	Поддерживается
Локальная среда с общедоступным IP-адресом	База данных Azure для PostgreSQL — гибкий сервер с общедоступным доступом	Да
Локальная сеть с частным IP-адресом через виртуальную частную сеть (VPN) или Azure ExpressRoute	Интегрированная виртуальная сеть (виртуальная сеть) База данных Azure для PostgreSQL — гибкий сервер	Да
Amazon Relational Database Service (Amazon RDS) для PostgreSQL или Amazon Aurora PostgreSQL с общедоступным IP-адресом	База данных Azure для PostgreSQL — гибкий сервер с общедоступным доступом	Да
Amazon RDS для PostgreSQL или Amazon Aurora PostgreSQL с частным доступом через VPN или ExpressRoute	Интегрированная виртуальная сеть База данных Azure для PostgreSQL — гибкий сервер	Да
Google Cloud SQL для PostgreSQL	База данных Azure для PostgreSQL — гибкий сервер с общедоступным доступом	Да
Google Cloud SQL для PostgreSQL с частным доступом через VPN или ExpressRoute	Интегрированная виртуальная сеть База данных Azure для PostgreSQL — гибкий сервер	Да
PostgreSQL, установленная на виртуальной машине Azure в одной виртуальной сети или в другой виртуальной сети	Интегрированная с виртуальной сетью База данных Azure для PostgreSQL — гибкий сервер в одной виртуальной сети или в другой виртуальной сети	Да
База данных Azure для PostgreSQL — отдельный сервер с открытым доступом	Интегрированная виртуальная сеть База данных Azure для PostgreSQL — гибкий сервер	Да
База данных Azure для PostgreSQL — отдельный сервер с частной конечной точкой	Интегрированная виртуальная сеть База данных Azure для PostgreSQL — гибкий сервер	Да
База данных Azure для PostgreSQL — отдельный сервер с частной конечной точкой	База данных Azure для PostgreSQL — гибкий сервер с частной конечной точкой	Да
Источники PostgreSQL с частным доступом	База данных Azure для PostgreSQL — гибкий сервер с частной конечной точкой	Да
Источники PostgreSQL с частным доступом	База данных Azure для PostgreSQL — гибкий сервер с общедоступным доступом	No

Локальный (общедоступный IP-адрес) на гибкий сервер (общедоступный доступ)

Действия по сети:

1. Убедитесь, что сервер базы данных-источник имеет общедоступный IP-адрес.
2. Настройте брандмауэр, чтобы разрешить исходящие подключения через порт PostgreSQL (порт по умолчанию — 5432).
3. Убедитесь, что сервер базы данных-источник доступен через Интернет.
4. Проверьте настройку, проверяя подключение из целевого экземпляра База данных Azure для PostgreSQL к исходной базе данных. Убедитесь, что служба миграции может получить доступ к исходным данным.

Локальный (частный IP-адрес) для гибкого сервера с виртуальной сетью (ExpressRoute или VPN)

Действия по сети:

1. Настройте VPN типа "сеть — сеть" или экземпляр ExpressRoute для безопасного надежного подключения между локальной сетью и Azure.
2. Настройте виртуальную сеть Azure, чтобы разрешить доступ из локального диапазона IP-адресов.
3. Настройте правила группы безопасности сети, чтобы разрешить трафик через порт PostgreSQL (порт по умолчанию — 5432) из локальной сети.
4. Проверьте настройку, проверяя подключение из целевого экземпляра База данных Azure для PostgreSQL к исходной базе данных. Убедитесь, что служба миграции может получить доступ к исходным данным.

Управляемая служба PostgreSQL (общедоступный IP-адрес) на гибкий сервер (общедоступный или частный доступ)

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

Действия по сети:

• Открытый доступ

  1. Если экземпляр PostgreSQL в Amazon Web Services (AWS), Google Cloud Platform (GCP) или другой управляемой службе PostgreSQL недоступен, измените экземпляр, чтобы разрешить подключения из Azure. В консоли поставщика облачных служб (например, в консоли управления AWS или в консоли Google Cloud) измените параметр, чтобы разрешить общедоступную доступность.
  2. В параметрах безопасности поставщика облачных служб (например, в группах безопасности в AWS или правилах брандмауэра в GCP) добавьте правило входящего трафика, чтобы разрешить трафик из общедоступного IP-адреса или домена База данных Azure для PostgreSQL.

• Частный доступ

  1. Создайте безопасное подключение с помощью ExpressRoute, IPsec VPN или эквивалентной службы частного подключения от поставщика облачных служб (Azure ExpressRoute, AWS Direct Connect, GCP Interconnect) к Azure.
  2. В параметрах безопасности исходного поставщика облачных служб (например, группах безопасности AWS или правилах брандмауэра GCP) добавьте правило входящего трафика, чтобы разрешить трафик из База данных Azure для PostgreSQL общедоступного IP-адреса или домена или из диапазона IP-адресов виртуальной сети Azure на порту PostgreSQL (порт по умолчанию — 5432).
  3. Создайте виртуальную сеть в Azure в том же регионе, что и экземпляр База данных Azure для PostgreSQL. Настройте группу безопасности сети, чтобы разрешить исходящие подключения к IP-адресу экземпляра PostgreSQL исходного поставщика облачных служб на порте по умолчанию 5432.
  4. Настройте правила группы безопасности сети в Azure, чтобы разрешить входящие подключения от поставщика облачных служб (например, от AWS или GCP) к диапазону IP-адресов База данных Azure для PostgreSQL.
  5. Проверьте подключение между экземпляром PostgreSQL в управляемой службе PostgreSQL (например, в AWS, GCP или Heroku База данных Azure для PostgreSQL), чтобы убедиться, что сетевые проблемы не возникают.

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

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

Действия по сети:

1. Настройте пиринг между двумя виртуальными сетями, чтобы включить прямое сетевое подключение.
2. Настройте правила группы безопасности сети, чтобы разрешить трафик между виртуальными сетями на порту PostgreSQL.

Виртуальная машина Azure для База данных Azure для PostgreSQL (та же виртуальная сеть)

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

Действия по сети:

1. Убедитесь, что виртуальная машина и сервер PostgreSQL находятся в одной виртуальной сети.
2. Настройте правила группы безопасности сети, чтобы разрешить трафик в виртуальной сети через порт PostgreSQL.

Единый сервер (общедоступный доступ) к гибкому серверу, интегрированному с виртуальной сетью

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

Ниже приведен краткий обзор действий по настройке этого подключения:

Добавьте правило виртуальной сети на один сервер:

1. В портал Azure перейдите к экземпляру База данных Azure для PostgreSQL — одиночный сервер.

2. Перейдите к параметрам безопасности подключения.

3. В разделе правил виртуальной сети выберите "Добавить существующую виртуальную сеть".

   Укажите, какая виртуальная сеть может подключаться к одному серверу.

   

Настройка параметров правила:

1. В области конфигурации введите имя нового правила виртуальной сети.

2. Выберите подписку, в которой находится гибкий сервер.

3. Выберите виртуальную сеть и конкретную подсеть, связанную с гибким сервером.

4. Нажмите кнопку "ОК ", чтобы подтвердить параметры.

   

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

Отдельный сервер (частная конечная точка) для гибкого сервера, интегрированного с виртуальной сетью

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

Получение сведений о частной конечной точке:

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

2. Перейдите на панель "Сеть " гибкого сервера. Обратите внимание на сведения о виртуальной сети и подсети сервера.

   

   

Оцените требования к пирингу виртуальной сети:

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

Настройте частную зону DNS:

1. Перейдите на панель "Сеть " для гибкого сервера и проверьте, настроена ли частная зона DNS. Если частная зона DNS используется, перейдите в частную зону DNS на портале. На левой панели выберите ссылки виртуальной сети и проверьте, отображается ли виртуальная сеть одного сервера и гибкий сервер в этом списке.

   

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

2. Перейдите к частной конечной точке для одного сервера и выберите область конфигурации DNS. Проверьте, подключена ли частная зона DNS к этой конечной точке. В противном случае подключите частную зону DNS, нажав кнопку "Добавить конфигурацию ".

   

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

4. Для окончательной проверки перейдите к частной зоне DNS частной конечной точки на одном сервере и проверьте, задана ли запись A для одного сервера, указывающего частный IP-адрес.

   

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

Один сервер (частная конечная точка) на гибкий сервер (частная конечная точка)

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

• Сбор сведений о частной конечной точке для одного сервера:

  1. В портал Azure перейдите к экземпляру База данных Azure для PostgreSQL — одиночный сервер.
  2. Запишите сведения о виртуальной сети и подсети, перечисленные в подключении частной конечной точки одного сервера.

  

• Сбор сведений о частной конечной точке для гибкого сервера:

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

  

• Сбор сведений о виртуальной сети для сервера среды выполнения миграции:

  1. В портал Azure перейдите на сервер среды выполнения миграции. То есть перейдите к экземпляру База данных Azure для PostgreSQL виртуальной сети — гибкий сервер.
  2. Запишите сведения о виртуальной сети и подсети, перечисленные в виртуальной сети.

  

• Оцените требования к пирингу виртуальной сети:

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

• конфигурация зоны Частная зона DNS:

  1. Перейдите на панель "Сеть " для гибкого сервера и проверьте, настроена ли частная зона DNS.

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

     

  3. Подключите частную зону DNS к частной конечной точке одного сервера, если она еще не настроена:

     1. Добавьте ссылки виртуальной сети для одного сервера и сервера среды выполнения миграции в частную зону DNS.
     2. Повторите процесс связывания зоны DNS и виртуальной сети для частной конечной точки гибкого сервера.

     

Кроме того, если используется пользовательский DNS-сервер или пользовательские пространства имен DNS, можно использовать настраиваемое полное доменное имя/IP вместо связывания частной зоны DNS. Эта настройка позволяет напрямую разрешать полные доменные имена или IP-адреса без необходимости интеграции частной зоны DNS.

Источник PostgreSQL (частный IP-адрес) на гибкий сервер (частная конечная точка)

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

• Установите сетевое подключение:

  1. Для локальных источников настройте VPN типа "сеть — сеть" или настройте ExpressRoute для подключения локальной сети к виртуальной сети Azure.
  2. Для виртуальной машины Azure или экземпляра Amazon или Google Compute Engine убедитесь, что пиринг между виртуальными сетями, VPN-шлюз или экземпляр ExpressRoute используется для безопасного подключения к виртуальной сети Azure.

• Сбор сведений о виртуальной сети для сервера среды выполнения миграции:

  1. В портал Azure перейдите на сервер среды выполнения миграции. То есть перейдите к экземпляру База данных Azure для PostgreSQL виртуальной сети — гибкий сервер.
  2. Запишите сведения о виртуальной сети и подсети, перечисленные в виртуальной сети.

• Оцените требования к пирингу виртуальной сети:

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

• конфигурация зоны Частная зона DNS:

  1. На панели "Сеть" сервера среды выполнения миграции убедитесь, что частная зона DNS используется.
  2. Убедитесь, что виртуальные сети для источника и целевого гибкого сервера связаны с частной зоной DNS сервера среды выполнения миграции.
  3. Подключите частную зону DNS к частной конечной точке гибкого сервера, если она еще не настроена.
  4. Добавьте ссылки виртуальной сети для гибкого сервера и сервера среды выполнения миграции в частную зону DNS.

Кроме того, если используется пользовательский DNS-сервер или пользовательские пространства имен DNS, можно использовать настраиваемое полное доменное имя/IP вместо связывания частной зоны DNS. Эта настройка позволяет напрямую разрешать полные доменные имена или IP-адреса без необходимости интеграции частной зоны DNS.

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

• Сведения о создании подключения ExpressRoute см. в статье "Что такое Azure ExpressRoute?".
• Сведения о настройке VPN IPsec см. в статье "Сведения о vpn-подключениях типа "точка — сеть".
• См. дополнительные сведения о пиринге виртуальных сетей.
• Сведения о службе миграции.
• Изучите известные проблемы и ограничения.
• Просмотрите проверки предварительной подготовки.