# Настройка AWS PrivateLink для Postgres

Платформа dbt | Enterprise+

Доступно на определённых уровнях Enterprise

Эта функция доступна на следующих уровнях dbt Enterprise:

* Enterprise+
* Virtual Private

Чтобы узнать больше об этих тарифах, свяжитесь с нами по адресу <sales@getdbt.com>.

База данных Postgres, размещенная либо в AWS, либо в правильно подключенном локальном центре обработки данных, может быть доступна через частное сетевое соединение с использованием AWS Interface-type PrivateLink. Тип группы целей, подключенной к сетевому балансировщику нагрузки (NLB), может варьироваться в зависимости от местоположения и типа подключаемого экземпляра Postgres, как объясняется в следующих шагах.

Конечные точки частного подключения не поддерживают соединения между разными облачными провайдерами (AWS, Azure и GCP). Чтобы частное подключение работало, и dbt, и сервер (например, Postgres) должны быть размещены у одного облачного провайдера. Например, dbt, размещённый в AWS, не может подключаться к сервисам, размещённым в Azure, а dbt, размещённый в Azure, не может подключаться к сервисам, размещённым в GCP.

## Настройка интерфейсного типа PrivateLink для Postgres

### 1. Подготовка ресурсов AWS

Создание соединения Interface VPC PrivateLink требует создания нескольких ресурсов AWS в учетной записи, содержащей или подключенной к экземпляру Postgres:

* **Группа безопасности (только для размещения в AWS)** — Если вы подключаетесь к существующему экземпляру Postgres, это, вероятно, уже существует, однако вам может потребоваться добавить или изменить правила группы безопасности, чтобы принимать трафик от сетевого балансировщика нагрузки (NLB), созданного для этой службы конечной точки.

* **Группа целей** — Группа целей будет прикреплена к NLB, чтобы указать, куда направлять запросы. Для групп целей NLB доступны различные типы целей, поэтому выберите тот, который подходит для вашей настройки Postgres.

  * Тип цели:

    * *[Amazon RDS для PostgreSQL](https://aws.amazon.com/rds/postgresql/)* - **IP**

      * Найдите IP-адрес вашего экземпляра RDS, используя командную строку, такую как `nslookup <endpoint>` или `dig +short <endpoint>` с вашим DNS-адресом RDS

      * *Примечание*: С возможностями отказоустойчивости RDS Multi-AZ IP-адрес вашего экземпляра RDS может измениться, в этом случае ваша группа целей должна быть обновлена. См. [этот блог AWS](https://aws.amazon.com/blogs/database/access-amazon-rds-across-vpcs-using-aws-privatelink-and-network-load-balancer/) для получения более подробной информации и возможного решения.

    * *Локальный сервер Postgres* - **IP**

      * Используйте IP-адрес локального сервера Postgres, связанного с AWS через AWS Direct Connect или соединение VPN "сайт-сайт"

    * *Postgres на EC2* - **Instance/ASG** (или **IP**)

      * Если ваш экземпляр Postgres размещен на EC2, тип группы целей *instance* (или, в идеале, [использование типа instance для подключения к группе автоматического масштабирования](https://docs.aws.amazon.com/autoscaling/ec2/userguide/attach-load-balancer-asg.html)) может быть использован для подключения экземпляра без необходимости в статическом IP-адресе

      * Тип IP также может быть использован, с пониманием того, что IP-адрес экземпляра EC2 может измениться, если экземпляр будет перезапущен по какой-либо причине

  * Протокол группы целей: **TCP**

* **Network Load Balancer (NLB)** — Требуется создать Listener, который будет привязан к только что созданной Target Group для порта `5432`

  * **Scheme:** Internal
  * **IP address type:** IPv4

* **Сопоставление сети:** Выберите VPC, в которой развертываются VPC Endpoint Service и NLB, и выберите подсети как минимум из двух зон доступности.

  * **Группы безопасности:** У балансировщика сетевой нагрузки (NLB), связанного с сервисом конечной точки VPC, либо не должно быть связанной группы безопасности, либо в этой группе должно быть правило, разрешающее запросы из соответствующих **частных диапазонов CIDR** dbt. Обратите внимание: *это не те же диапазоны*, что и статические публичные IP-адреса, перечисленные на странице dbt [Доступ, регионы и IP-адреса](https://docs.getdbt.tech/docs/platform/about-platform/access-regions-ip-addresses.md). Служба поддержки dbt предоставит нужные частные диапазоны CIDR по запросу. При необходимости, пока вы не сможете сузить правило до меньшего диапазона CIDR, предоставленного dbt, разрешите подключение, временно добавив разрешающее правило для `10.0.0.0/8`.
  * **Обработчики подключений:** Создайте по одному обработчику подключений для каждой целевой группы, сопоставив соответствующий входящий порт с нужной целевой группой ([подробнее](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-listeners.html)).

* **Сервис конечной точки VPC** — Подключите его к созданному NLB.

  * Требуется подтверждение (необязательно) — Требует от вас [подтвердить наш запрос на подключение](https://docs.aws.amazon.com/vpc/latest/privatelink/configure-endpoint-service.html#accept-reject-connection-requests) после того, как dbt создаст конечную точку.

Балансировка нагрузки между зонами

Мы настоятельно рекомендуем включить балансировку нагрузки между зонами для вашего NLB или целевой группы (Target Group); для некоторых подключений она может быть необходима. Балансировка нагрузки между зонами также может [улучшить распределение трафика и повысить устойчивость подключений к сбоям](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#cross-zone-load-balancing). Обратите внимание, что подключение между зонами может повлечь дополнительные расходы на передачу данных, хотя для запросов от dbt они должны быть минимальными.

* [Включение балансировки нагрузки между зонами для балансировщика нагрузки или целевой группы](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/edit-target-group-attributes.html#target-group-cross-zone)

### 2. Предоставьте аккаунту AWS dbt доступ к сервису конечной точки VPC

На подготовленной службе конечной точки VPC нажмите вкладку **Разрешить принципалов**. Нажмите **Разрешить принципалов**, чтобы предоставить доступ. Введите ARN корневого пользователя в соответствующей производственной учетной записи AWS и сохраните изменения.

* Принципал: `arn:aws:iam::346425330055:role/MTPL_Admin`

[![Введите ARN](/img/docs/dbt-platform/privatelink-allow-principals.png?v=2 "Введите ARN")](#)Введите ARN

### 3. Получите имя сервиса конечной точки VPC

После создания сервиса конечной точки VPC его имя можно найти в консоли AWS: перейдите в **VPC** → **Endpoint Services** и выберите нужный сервис конечной точки. Скопируйте значение поля с именем сервиса и включите его в обращение в службу поддержки dbt.

[![Получите значение поля с именем сервиса](/img/docs/dbt-platform/privatelink-endpoint-service-name.png?v=2 "Получите значение поля с именем сервиса")](#)Получите значение поля с именем сервиса

### 4. Отправьте запрос в службу поддержки dbt

Добавьте необходимую информацию в приведённый ниже шаблон и отправьте запрос в [службу поддержки dbt](mailto:support@getdbt.com):

 Шаблон письма для обращения в службу поддержки

```text
Subject: New Multi-Tenant PrivateLink Request

- Type: Postgres Interface-type
- dbt platform account URL:
- VPC Endpoint Service Name:
- Postgres server AWS Region (for example, us-east-1, eu-west-2):
- dbt AWS multi-tenant environment (US, EMEA, AU, JP):
```

dbt Labs выполнит настройку приватного подключения от вашего имени. Пожалуйста, заложите 3–5 рабочих дней на завершение этого процесса. Служба поддержки свяжется с вами, когда конечная точка (endpoint) будет доступна.

### 5. Примите запрос на подключение

Когда вы получите уведомление о том, что ресурсы подготовлены в среде dbt, необходимо принять запрос на подключение к конечной точке (если сервис конечной точки VPC не настроен на автоматическое принятие запросов на подключение). Вы можете принимать запросы через консоль AWS, как показано ниже, или через AWS CLI.

[![Примите запрос на подключение](/img/docs/dbt-platform/platform-configuring-dbt-platform/accept-request.png?v=2 "Примите запрос на подключение")](#)Примите запрос на подключение

## Создайте подключение в dbt

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

1. Перейдите в **Account Settings** → **Projects** → **Create new project**.
2. В разделе **Configure your development environment step** выберите **Add new connection**.
3. Вы перейдёте на страницу **Add new connection**. Выберите **PostgreSQL**.
4. В разделе **Settings** выберите **PrivateLink Endpoint**.
5. Выберите частную конечную точку из раскрывающегося списка (поле имени хоста/учётной записи заполнится автоматически).
6. Настройте остальные параметры платформы данных.
7. Проверьте подключение и сохраните его.

## Устранение неполадок

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

### Конфигурация

Начните с конфигурации:

 1. Группа безопасности NLB

Для Network Load Balancer (NLB), связанного с VPC Endpoint Service, либо не должна быть назначена группа безопасности (Security Group), либо в назначенной группе безопасности должно быть правило, разрешающее запросы из соответствующих *частных диапазонов CIDR* dbt. Обратите внимание, что эти диапазоны отличаются от статических публичных IP-адресов, указанных на странице подключения dbt. Служба поддержки dbt может предоставить нужные частные диапазоны CIDR по запросу.

* **Примечание**\*: Чтобы проверить, в этом ли причина проблемы, временно добавьте разрешающее правило для `10.0.0.0/8`: это должно обеспечить подключение, пока правило не будет уточнено до более узкого диапазона CIDR

 2. Слушатель NLB и целевая группа

Убедитесь, что к NLB подключён Listener, порт которого совпадает с портом, к которому пытается подключиться dbt. Для этого Listener должно быть настроено действие перенаправления в Target Group с целевыми ресурсами, указывающими на ваш обслуживающий сервис. Хотя бы один из этих целевых ресурсов (а желательно все) должен иметь статус **Healthy**. Неработоспособные целевые ресурсы могут указывать на то, что обслуживающий сервис действительно неработоспособен или защищён группой безопасности (Security Group), которая не разрешает запросы от NLB.

 3. Балансировка нагрузки между зонами

Убедитесь, что для вашего NLB включена *межзональная балансировка нагрузки (Cross-zone load balancing)* (проверьте вкладку **Attributes** вашего NLB в консоли AWS). Если она отключена и зоны, к которым подключается dbt, не совпадают с зонами, в которых работает сервис, запросы могут маршрутизироваться некорректно. Включение межзональной балансировки нагрузки также повысит устойчивость соединения при переключении на резервные ресурсы в случае сбоя зоны. Межзональное соединение может повлечь дополнительные расходы на передачу данных, однако для запросов от dbt они должны быть минимальными.

 4. Таблицы маршрутизации и ACL

Если все вышеперечисленное проверено, возможно, что запросы неправильно маршрутизируются внутри частной сети. Это может быть связано с неправильной конфигурацией таблиц маршрутизации VPC или списков контроля доступа. Проверьте эти настройки с вашим сетевым администратором, чтобы убедиться, что запросы могут быть маршрутизированы от сервиса конечной точки VPC к поддерживающему сервису и что ответ может быть возвращен к сервису конечной точки VPC. Один из способов проверить это — создать конечную точку VPC в другой VPC в вашей сети, чтобы проверить, что подключение работает независимо от подключения dbt.

### Мониторинг

Чтобы локализовать проблемы с подключением через PrivateLink из dbt, можно использовать несколько источников данных мониторинга для проверки активности запросов. Чтобы в данных мониторинга что-либо появилось, сначала необходимо отправить запросы к конечной точке. Обратитесь в службу поддержки dbt, чтобы узнать, когда проводилась проверка подключения, или запросить новые попытки подключения. Сопоставьте время этих попыток с активностью в следующих источниках данных мониторинга.

 Мониторинг сервиса конечной точки VPC

В консоли AWS перейдите в VPC -> Endpoint Services. Выберите тестируемый сервис конечной точки и нажмите вкладку **Monitoring**. Обновите временной интервал, чтобы включить время, когда были отправлены попытки тестового подключения. Если есть активность в графиках *New connections* и *Bytes processed*, значит, запросы были получены сервисом конечной точки, что предполагает, что конечная точка dbt маршрутизируется правильно.

 Мониторинг NLB

В консоли AWS перейдите в EC2 -> Load Balancers. Выберите тестируемый сетевой балансировщик нагрузки (NLB) и нажмите вкладку **Monitoring**. Обновите временной интервал, чтобы включить время, когда были отправлены попытки тестового подключения. Если есть активность в графиках *New flow count* и *Processed bytes*, значит, запросы были получены NLB от сервиса конечной точки, что предполагает, что слушатель NLB, целевая группа и группа безопасности настроены правильно.

 Логи потоков VPC

Логи потоков VPC могут предоставить различную полезную информацию о запросах, маршрутизируемых через ваши VPC, хотя иногда их может быть сложно найти и интерпретировать. Логи потоков могут записываться либо в S3, либо в CloudWatch Logs, поэтому определите доступность этих логов для вашей VPC и запросите их соответствующим образом. Логи потоков записывают идентификатор сетевого интерфейса (ENI), исходный и целевой IP и порт, а также информацию о том, был ли запрос принят или отклонен группой безопасности и/или сетевым ACL. Это может быть полезно для понимания, прибыл ли запрос на определенный сетевой интерфейс и был ли этот запрос принят, что может выявить чрезмерно ограничительные правила. Для получения дополнительной информации о доступе и интерпретации логов потоков VPC см. соответствующую [документацию AWS](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html).
